인프랩에 합류하고 난뒤부터 일기를 조금씩 쓰고 있다.
시리즈 A 확정 일주일전 (실제 통장에 돈 들어오기 한달전) 에 합류한 시니어 개발자가 겪는 경험들을 남겨두면 좋겠다는 생각이 들었기 때문이다.
다음에 또 비슷한 일이 있으면 같은 실수를 하지 않도록 하기 위해
합류한 이후부터 여러 회사의 개발자분들과 이야기를 나누다보면 "이정도는 그래도 처음부터 해뒀으면 나중에 부채가 쌓여도 해결하기 편할텐데" 라는 지점들을 보게 된다.
흔히들 스타트업의 기술 부채에 대해 많이들 이야기한다.
전직장도, 현직장도 기술 부채를 많이 보고 갚았다.
전직장에서 PHP 프로젝트를 Java / Spring으로 개편하는 프로젝트에 참여했었다.
당시에 4000 라인 동적 쿼리 문자열을 팀장님이 퇴사전까지 문자열 SQL을 해체하다가 욕하셨던게 기억 난다.
그래서 기술 부채 자체에 대해 부정적인 마음은 없다.
스타트업에서 당연히 가져가야하는 부분이니깐.
다만, 부채에도 이율은 다를 수 있다.
똑같이 천만원을 빌려도 제 1금융권에서 빌리느냐, 제 3금융권에서 빌리느냐에 따라 "이후에 갚아야할 총 금액이 달라지는것" 처럼 말이다.
예를 들면 이런것인데,
테이블의 PK를 auto_increment 로 잡았음에도 bigint 대신에 int 를 선언해서 사용하는 것 말이다.
한번 PK를 int 로 선언하면 이와 연관된 테이블 역시 조인 컬럼을 모두 int 로 선언해야한다.
이후에 비지니스가 커지면 한 테이블이라도 int 사이즈에 위협될만큼 쌓이는 속도가 가파라지면 수많은 테이블들의 컬럼 타입을 교체해야하는데 엄청난 부채가 된다.
물론 특정 생태계의 ORM들은 bigint 를 모두 문자열로 반환하기 때문에 int 로 해야만 숫자로 결과가 반환되서 사용하기 편한게 있다.
다만, 이는 ORM의 Transform 구성을 해두면 충분히 불편함 없이 해소 가능하다.
이를 모르면 int 로 두다가 이후에 큰 부채가 된다.
이것들 외에도 미리 알고만 있었다면 충분히 저렴한 이자에 대출할 기술 부채들이 있다.
그래서 이 부분들을 잘 기록해두었다가, 공유해도 좋겠다는 생각이 들었다.
큰 기업과 작은 기업은 전략이 같을 순 없겠지만, 그래도 큰 기업이 하는 것 중에서도 작은 기업이 쓰기에 좋은 전략들이 꽤나 많고, 이는 적용하는데 크게 어려운게 아닌것들이다.
이런 부분들을 알고 해놓으면 이후에 갚아야할 부채 이자도 충분히 작다.
스타트업에 합류하고 나서 경험하고, 듣는 많은 이야기들이 있다.
이번처럼 기술적인 부분도 있고, 채용, 매니징,커뮤니케이션 등 여러 부분에서 균형감을 가지고 성장하게 만들어 된다.
이 경험들을 잊지 않고 남기고 공유해야지.
