2년간 스타트업 퇴사 회고

공부는 혼자하는 거·2024년 5월 27일

잡담

목록 보기

12/14

멘탈이슈로 회사에 얘기해 당분간 일을 그만두고 프리랜서로서 작업을 하고 싶다고 얘기했다. 그래서 그동안의 회고를 짤막하게 기록할려고 한다.

첫 직장은 SI 외주 회사였다. 흔히 낮추어 말하는 좆소라는 단어의 대표적인 케이스로 딱 알맞는 것 같다. 임금체불, 잦은 야근, 열악한 근무환경, 가족 경영 회사, 사실상 인수인계 과정 X, 사수 X, 중구난방 업무체계와 같은 대한민국 IT 소기업의 극단을 달리는 회사 중 하나였다. 나는 거기서 자바 + 스프링 기반의 벡엔드 개발자로 입사하였지만, 정말 다양한 업무를 경험하게 되었다. xml 기반의 스프링 레거시 + Mybatis + JSP + Jquery로 이루어진 오래된 웹 사이트 유지보수 및 기능 추가부터, Express.js + React.js + MobX로 이루어진 다소 힙한 사이트 유지보수, IOS 웹뷰 기능 추가 및 HTTP 레이어가 아닌 TCP 단위의 소켓 프로그래밍을 통해서, 파이썬 QT로 만들어진, IOT와 통신하는 컨트롤러 제작 및, 역시 소켓 프로그래밍을 활용한 로우레벨 전기자전거 컨트롤러를 스프링으로 구현하거나 등등.. JSON이 아닌 생전 처음 보는 비트 단위 프로토콜을 따라서 데이터를 구현해야 되는데 영어로 된 PDF 문서가 전부였다.

단순 웹 API 개발도 많이 했지만, 중소 외주 회사답게 다양한 일을 떠안아 왔고, 거기서 어떻게든 길을 찾아내서 개발을 완료하는 게 내 목적이었다. 여기서 일을 할 때 가장 큰 스트레스는, 중구난방인 개발업무도 있었지만, 내가 유지보수해야할 프로젝트들의 코드 퀄리티였다. SI 개발은 필연적으로 코드 퀄리티가 낮아질 수 밖에 없다. 일단 어떻게든 개발을 완료하고 떠 넘기면 유지보수는 남의 일이 된다. 개발 담당자는 그 사이 다른 곳으로 이직하면 끝이다. 그래서 정말 상상도 하지 못할 코드베이스들을 많이 발견하게 된다. 수백줄이 넘는 쿼리문이라든가, 32중 if 문 중첩이라든가, 모든 파라미터를 HashMap으로 받고 HashMap으로 리턴해주든가 등등..

물론 같은 개발자로서 화도 나지만, 이해도 간다. 중간에 누가 남기고 간 똥덩어리를 맡아서 한다면, 대충 휴지조각으로 덮고 다른 데 Run할 생각을 하지. 내가 사서 고생을 하며 똥덩어리를 치울 생각은 안 하니까. 나조차도 화를 내면서 대충 치울 생각을 하지. 이걸 갱생시켜서 다시 만들 생각은 안 한다. 그래서 오래된 코드베이스일 수록 임시방편 코드들이 쌓여가며 누적떼기가 되고, 나중에는 더 이상 돌이킬 수 없는 지경으로 빠지는 거다. 필자는 이런 환경에서 업무를 하면서 한가지 생각이 확고해졌다. 자체 솔루션 회사로 들어가자. 거기를 가면 더 이상 누적떼기 같은 코드베이스를 안 보아도 되고, 설령 보게 되더라도 그 프로젝트만 보면 되니까, 리팩토링도 즐겁게 시도할 수 있을 것 같았다.

그럼 그런 회사로 쉽게 가려면? 답은 스타트업이었다. 크든 작든 상관없었다. 오히려 작으면 내 권한이 세지므로 더 나쁘지 않겠다는 생각까지 했다. 1년간의 개발 경력은 경력이라 치기에는 짧지만, 그동안 산전수전을 다 겪었다고 생각했다. 나름 자신이 있었다. 그래서 친구의 추천으로 스타트업에 들어가게 되었다. 개발 상주 인원 4명정도의 전 직장보다도 개발팀 규모가 더 작은 회사였다. 그 중 벡엔드 개발자는 나와 다른 한 명이었다. 작은 규모였지만 나름대로 최소한의 소프트웨어 인프라는 갖춰져 있었다. 개인 계정 깃허브를 돌려쓰면서 코드를 공유하고 있었고, 정기적인 회의와 지라를 통해 업무내역을 공유하고 있었다. 서버 인프라는 AWS 클라우드 위에 조그맣게 갖춰져 있었다.

거기서 보게 된 벡엔드 개발자도 역시 나와 비슷한 연차의 주니어 개발자였다. Node.js + TypeScript 기반의 벡엔드 개발스택을 보유한 친구였는데 사람 참 좋은 친구였다. 다만 코드적으로는 아쉬운 부분이 많았는데, 일단 비대한 함수들이 많았고, 중복된 코드들도 상당히 많이 존재했다. 클래스를 쓰면서 클래스를 활용하지 않고, 리터럴 객체와 클래스 객체의 차이점을 구분하지 않고 있으며 적극적인 조인과 인덱스를 통한 쿼리 최적화가 안 되어있고, 여러개의 쿼리를 나눠서 호출하는 등 비효율적으로 짜져있었다. 마음같아서는 내가 다 갈아엎고 새로 API를 짜고 싶었지만, 그동안 이 친구가 1년동안 해온 게 있는데 존중해야 된다고 생각했다.

더군다나 나와 다른 기술스택을 가지고 있는지라 함부로 뭐라 말도 못 꺼내겠고, AWS 인프라는 나도 여기 직장에서 처음 실무로 접하는 거라, 배워야 될 부분도 있겠다 싶었다. 그래서 나는 어드민 같은 서브 루틴으로 빠지고, 이 친구를 보좌하면서, 새로운 프로젝트는 내 담당으로 아예 분리를 해서 개발을 진행하는 게 마음 편하다고 생각했다. 처음 ADMIN을 분리하고 개발을 진행하면서 답답한 부분이 많았다. 서로 개발계 데이터베이스를 공유하면서, 작업을 진행하는데, 상대방 쪽이 DB 쪽 칼럼 구조나 호스트 주소를 바꾸면 내 쪽에서 에러가 터지는 거다. 아무래도 이건 나와 상대방 모두 협업에 대한 개념이 약하다 보니, 서로 명확히 정보를 공유하고 진행해야 되는 부분도 생략하는 부분도 있기에 발생하는 문제였다.

마음 같아서는 DB 테이블 구조나 이런 것 들 내가 다 새로 짜고 싶은데, 선을 넘는 행위라는 생각이 들었다. 상대방의 코드베이스가 마음에 안 들어도, 최대한 맞춰가면서 진행하기로 마음을 먹었다. 내 쪽 어드민 대시보드는 당시엔 프론트 인원도 배정되어있지 않아서, 앞으로 올 프론트 개발자를 위해 React로 내가 작업을 했다. 지금 생각하면 후회스럽다. 그냥 내가 혼자 개발하기 편한 타임리프 + SpringBoot 조합으로 전적으로 개발을 하는 게 맞았다. 익숙치 않은 react 를 조합해서 쓰는라 생산성도 낮아지고, 나중에는 담당 개발자가 결국 배정되지 않아서 아예 프론트엔드를 다른 프레임워크로 새로 만들게 되었으니.

그러다가 회사의 신규 프로덕트를 담당으로 맡게 되었다. 기존 프로덕트와 완전히 분리된 새로운 프로덕트이고, 그래서 이 작업의 벡엔드를 먼저 맡아서 진행하기로 했다. 신규 프로덕트에는 코프링 + JPA 조합을 사용하기로 결정했다. 둘 다 예전부터 쭉 사용해보고 싶은 기술스택이었는데, 전 직장에서는 여러가지 요건 상 실무에 적용시킬 수 없었는데, 여기서는 내 재량껏 선택할 수 있었다. 사실 요런 점들이 소규모 스타트업 개발자로서의 장점이라고 할 수도 있다. 일을 열심히 했다. 아무래도 온전히 내 담당으로 개발을 진행하다보니 애정이 안 생길 수가 없다. 클라우드 인프라 시스템도 루트계정부터 기존 프로덕트와 분리해서 새로 만들어 제로부터 구축하였다. 삽질이 많았다. 당시에는 ChatGpt 도 없어서, 관련 키워드를 알아낼 수단도 변변치 않았다. 열심히 구글링하면서 맨땅에 헤딩하는 식으로 부딪치고 알아보는 법 밖에 없었다.

맨땅에 헤딩하는 것은 사실 내 주특기이기도 하고, 익숙하기 때문에 별 스트레스 거리는 아니었다. 초기, 업무에서 오는 스트레스는 개발에서 오는 스트레스는 아니었다. 내가 담당한 프로덕트가 별 조명을 받지 못하고, 방치된 느낌이라서 오는 스트레스가 컸다. 회사입장에서 별로 마케팅을 태우고 싶지 않은 서비스 하나를 대충 하나 잡아서 나한테 던져준 느낌이랄까? 그래도 내가 온전히 맡아서 진행할 프로젝트라 생각하기 때문에, 혼자서라도 열심히 해보려 했다. 시간이 한참 지나고 나서야 프론트엔드 개발자도 따로 배정이 되고, 동료개발자가 퇴사를 함으로서 내가 맡은 프로덕트가 회사의 주요 서비스로 떠올랐다. 그렇게 되기까지 나름 2년동안 열심히 재밌게 개발했다고 생각한다. 그 과정에서 격은 개발과 관련된 삽질과 개선과정은 따로 생각나는 것들만 글로 정리해서 올려보도록 하겠다.

그럼 왜 퇴사를 결심했느냐? 어느 순간부터 장작이 다 타버린듯이 내게 일을 지속할 동기도 의욕도 사라져버렸다고 느꼈기 때문이다. 타성적으로 일을 하고, 회사에서 시간만 때우다 집에 빨리 가길 바란다. 어느 순간부터는 회사에 있는 순간이 회사에게도 나에게도 시간낭비라는 느낌이 강해졌다. 스스로 생각해보았다. 무엇 때문에 열정이 다 식어버렸을까? 돌이켜보면 몇가지 계기는 분명히 있다.

업무간 소통에 대한 답답함

회사의 초장기부터 함께한 인원으로서 대표님의 소통방식에 대해서는 늘 답답한 면이 있었다. 상주 인원 20명이 채 안 되는 소규모 회사에서 뭐가 그리 비밀이 많고 숨겨야 될 게 많은지. 주에 한 번씩 팀 대표들끼리 정기 회의를 통해 대표님이 일정을 보고받는 식으로 진행되었는데, 그 과정에서 무슨 얘기가 오갔는지 파악할 길이 없다. 기획에 대해서도 들리는 얘기가 이랬다, 저랬다 해서 내가 어느 장단에 맞춰서 개발을 해야될지 분간이 채 안 간다. 개인적으로 스타트업의 장점이라고 하면, 직접적인 업무 소통과 그로 인한 빠른 수행능력이라고 생각하는데, 어째 하는 꼴은 점점 그 반대를 추구하는 것 같아서 영 불만이었다. 단독진입적으로 무엇을 원하고 어디까지 됐고 어느정도를 생각하고 있는지 다이렉트로 나한테 소통했으면 하는데, 이렇게 작은 규모의 회사가 꼭 중간관리자를 하나두고 보고를 받는 식으로 할려고 굳이 굳이 할려는 이유를 납득을 못하겠다. 어차피 일은 내가 하고, 업무도 내가 가장 잘 아는데 정보를 알려면 내가 가장 많이 알아야 되고, 내가 판단해야 된다. 그래야 대응이 된다. 근데 이건 내 잘못도 있다. 내가 원래 그렇게 소통을 즐기는 스타일이 아니고, 여러번 회사에 실망을 하다 보니, 일부러 거리를 스스로 둔 셈이기도 하다.

채용방식에 대한 스트레스

채용방식에 대한 불만도 늘 존재했다. 예전부터 회사는 계속해서 개발자를 추가모집하려고 했다. 그런데 그 과정에서 왜 채용공고를 안 내는지 모르겠다. 공개된 이력서를 보고 스카우트하는 식으로 진행을 하는데, 스카웃을 누가 담당할까. 대표님은 개발과는 무관한 사람이고, 현재 회사에 벡엔드 개발자 포지션을 뽑는다면 자문을 구할 사람이 나랑 동료 개발자 2명만이 전부다. 그러면 우리가 이력서를 계속 보면서 검증을 해야하는데, 공개 이력서만 가지고는 감도 안 잡히고, 업무도 바쁜데 이거 때문에 업무에 대해서 지장이 생기고 스트레스만 더 받게 된다. 차라리 공고를 내면, 회사에 필요한 기술스택을 적고 원하는 사람이 우리 회사에 지원을 하면 면접을 다 같이 보는 식으로 하면 서로가 다 좋을텐데, 죽어도 그렇게 안 한다. 사실 채용과정 프로세스에 대해서는 내 권한이 아니기 때문에 가타부타 아무 말도 안 했지만, 속으로는 불만이 쌓여갔다.

업무 지원에 대한 열악함

예를 들어, 프로덕트가 글로벌 서비스이면 해외 결제 모듈을 테스트해야 된다. 그래서 요구사항으로 국내에서도 해외결제가 가능한 테스트 카드를 하나 발급해달라 요청을 하면, 무조건 지원해준단다. 사실은 회사 측에서도 방법이 없다. 그냥 해외에 있는 지인들에게 연락해서 그때 그때마다 결제 해달라고 요청하면서 확인하는 수 밖에 없다. 만약 프로덕트를 중국에 진출하고 싶다. 그러면 중국 쪽 법인과 관련해서 여러가지 계약과 행정적 절차가 필요한데, 그런 게 아무것도 없이 그냥 중국에 서비스할 프로덕트를 만들어달라는 식이다. 결국은 스스로 방법을 찾아야 된다. 이 과정이 재밌긴 하지만 점점 지쳐간다. 초기에 아무것도 없이 구축하다보니, 클라우드 비용부터 해서 어떻게 아키텍처를 짜고 비용을 절감할 것인지 스스로 고민해보고 설정해야 한다. MSP 계약도 없던 시절이라, MSP 계약 및 행정적인 절차, 구글 프로덕션 심사, 깃허브 스타트업 엔터프라이즈 플랜 신청, 슬랙 스타트업 할인혜택 신청 등 스스로 알아보고 비용을 절감할 수 있으면 신청하고 최대한 혜택을 받도록 노력했다. 열정이 있는 시기에는 이 모든 게 재밌는 과정이었지만, 열정이 식어가자 점점 더 귀찮고 짜증나는 과정으로 변모했다.

비즈니스 모델에 대한 의구심

현재 프로덕트가 관련되어있는 도메인이 내가 전혀 관심도 없었고, 알지도 못했던 도메인이였고 이로 인해 어떤 수요층이 있을까 하는 의구심이 늘 있었다. 그런 것과 상관없이 내가 하고싶은 기술스택으로 개발하는 게 좋았기 때문에, 쭉 진행하는 것이었지만, 근본적으로 관심이 없는 도메인이었기에 가지는 열정의 한계와, 매출에 대한 압박이 있었다. 나는 뭔가 효용이 발생해야 개발에 재미가 붙는데, 내 쪽 프로덕트는 가입자수는 만명이 넘지만, 유료구독 유저는 100명이 채 안 된다. 매달 발생하는 서버비용을 챙기기에도 모자라며, 회사는 매출과 상관없이 투자금과 정부과제산업으로 연명을 하고 있는데, 그러다 보니 실제 프로덕트보다 그 쪽 관련 업무 쪽으로 관심이 집중될 수 밖에 없다. 슬슬 떠나야 하는 타이밍이라고 느낀다.

점점 사라지는 자유도

그럼에도 불구하고 회사의 장점들이 확실히 있었다. 일단 대표님이 나를 믿고 존중해준다는 느낌이 있었고, 실제로 내 쪽 편의를 많이 봐주기도 했다. 유연한 출퇴근제와, 하고싶은 개발쪽 업무나, 일들이 있을 때 비용적인 면에서 믿고 나한테 맡겨주었다. 그래서 더 열심히 일을 하기도 했다. 나쁘지 않은 업무 환경이었다. 다른 잡무를 시키지도 않고, 개발 쪽 업무에 집중할 수 있도록 세팅해주었다. 대표님에 대해서는 안 좋은 생각도 있지만 고마운 점도 많이 있다. 하지만 점점 이런 자유도가 사라지고 눈치를 준다는 느낌이 들었다. 문제는 회사가 성장하면서 자유도를 낮추는 건 좋은데, 합리적인 이유가 아니라는 생각이 들어서다. 이건 다음 이유에서 나오는데..

좋은 동료에 대한 갈망

사실 가장 큰 이유는 여기에 있다. 새로 뽑은 시니어 개발자가 자꾸 되도 않는 얕은 수작을 부린다는 인상이 드니까 일을 하는 데 있어서 현타가 온다. 내가 제일 싫어하는 유형의 사람이

모르는데 아는 척
같은 말 두 번, 세 번 반복하게 하는 것
대화를 제대로 듣지 않는 사람 + 쓸데없는 고집 및 기싸움
갑자기 감정적 급발진

팀장 직으로 왔으면, 먼저 팀원들에게서부터 신뢰를 얻고 통제권을 가져야 되는데, 그런 거 없이 팀장 노릇부터 할려고 하니, 그 꼬라지가 보기가 힘들다. 가만히 있으면 알아서 모셔줄텐데, 자꾸 뭐해볼려고 불필요한 절차를 만들려고 한다. 무엇보다 침착하지 않고 안절부절 어쩔 줄 모른다. 속으로는 그럴지라도 상급자라면 겉으로는 내색을 하면 안 되는데, 그게 전부 느껴지니까, 짜증이 치솟는다. 도움도 안 되는데 이런 감정적인 스트레스까지 받아줘야 되나? 회사도 이해가 안 간다. 경력이 십수년이 넘은 개발자들을 찾아서, 중요한 담당자를 뽑는 자리에 검증절차가 없이 대충 아무나 뽑고 자리에 앉힐려고 하는 느낌이 있다. 뭐 상관은 없다. 어차피 개발은 혼자 하는 거고, 원래도 내가 도움은 안 바래는 성격이다. 근데 일을 하는데 있어서 방해는 안 되야 되는 게 아닌가 하는 생각이 든다. 뭐가 중요한지 판단이 안 되는 건지, 아니면 기싸움을 할려는 건지.