스타트업에서 대기업으로..

서문

나는 스타트업을 두군데 거치고 큰 회사로 옮긴 개발자이다. 소위 말하는 네카라쿠배 중 한군데에 입사하였다. 대세는 큰회사에서 스타트업으로 가는거라는데.. 거꾸로 역행했다. 스타트업에서 근무하면서 코드 퀄리티가 짱이야 짜릿해! 개발자라면 무릇 클린한 코드를 지향해야지! 라는 생각에 휩싸여있었고, 주변 환경도 그러한 가치를 지향하는 개발자들 밖에 없었다.

그런데 큰 회사로 오며 다른 관점과 시야를 가지게 되었다. 정확히 말하자면 원래 머릿속으로 알고있던 관점들을 몸소 느끼게 되었다. 스타트업에서 큰 회사로 옮기려는 사람들이 조금이나마 참고할 수 있도록 내 경험을 작성해보려고 한다.

스타트업에서

나의 근무 환경은 빡쎘다. 내가 근무했던 회사는 리뷰가 상당히 엄격하고 빡빡했는데, 코드의 구조와 설계는 물론이고 코드 스타일과 가독성 if문을 쓰는 방식 주석을 다는 위치 및 방식 등등 꼼꼼하게 리뷰 받았다. (프로젝트의 규모와 일정과 리소스와는 전혀 상관없이 말이다.)

이런 근무 환경은 갓 주니어 개발자로 입사한 나에게는 너무나도 좋은 환경이었다. 나는 보통 지식을 습득하고 확장할때 기본적인 베이직한 틀을 갖추고 거기에 살을 붙이고 나에게 맞게 커스텀하게 지식을 변형시켜나가는 스타일이다. 그런 나에게 좋은 코드와 설계 그리고 내가 작성하는 코드를 하나하나 섬세하게 뜯어보고 교정해주는 리뷰는 돈내고도 못할 값진 경험이었다.

엄격한 환경에서 3년간 일하다보니 일하는게 점점 익숙해지고 리뷰가 줄어들어 거의 없을 정도로 코드를 작성할 수 있는 수준이 되고있었다. 물론 더 수행이 필요하긴 했지만 내가 다음 스텝으로 나아가기 위해선 어떤걸 해야하는지 고민되기 시작했다. 나의 경쟁력 까지는 모르겠고 주니어에서 시니어로 넘어가려면 어떤 역량이 필요할지가 너무 궁금했다.

• 코드를 더 잘 짜는 일?
  • 나는 방망이 깎는 노인이 아니다.
  • 자본을 적게 투자하여 빠르게 시도해보고 실험해보는 IT 업계에서 없어질 코드에 시간만 많이 쓰는 개발자는 필요하지 않을것이다.
  • 나는 무슨 게임 엔진을 만들거나 AI 모델을 창조하는 사람이 아니다.
  • 서비스 개발을 하는 개발자이고 비즈니스에 맞는 적정 수준의 서비스를 일정에 맞게 개발해 내는것이 더 중요하다.
• 뭔가 큰 경험이 필요하다!
  • 대량의 데이터 또는 대량의 트래픽을 경험하고 감당해보는 경험은 앞으로 데이터가 중요하게 다뤄지는 개발씬에서 차별점을 가져갈 수 있는 요소 중 하나라고 생각된다.
  • 여러 개발자가 투입되어왔던 서비스를 경험하고싶다. 그래야 내가 클린하게 코드를 짜면서 아 이렇게 짜면 변경이 어렵다 확장이 어렵다를 나의 머리가 아닌 감각으로 알 수 있도록 하고싶다.
• 다른 성향의 업무 환경이 필요하다.
  • 내가 만난 분들은 개발적으로 아주 뛰어났다.
  • 내가 생각하는 좋은 시니어는 항상 클린하고 이상적인 코드를 만들어 내며, 진짜 원인을 알 수 없는 버그를 척척 고쳐내는 사람이었다.
  • 하지만 사람은 혼자서 다 할 수 없고, 코드를 혼자 다 작성할 수 없으며 한명이 가용가능한 업무 시간은 한계가 있다.
  • 따라서 다른 업무환경을 경험하며 시니어로써 가져야하는 역량을 더 찾아보고싶다.
• 막연한 큰 회사에 대한 로망
  • 대외적으로 보여지기에 멋져보이는 저 큰회사에는 어떤 개발자들이 어떻게 일하고있을까?
  • 어떤 업무 프로세스를 가질까?
  • 스타트업에서만 일했던 내가 실제로 큰 회사에서도 같이 일하고 싶어할 가치를 가지고 있을까?
  • 큰회사에 가면 톱니바퀴가 된다는데.. 그래도 경험을 한것과 안한것의 차이는 크고, 해보고 판단해서 영 아니면 나오자!

위와 같은 요소로 인해 새로운 관점과 경험을 위해선 큰 회사로 한번 가보는게 필요했다고 판단했고 우연히 좋은 기회로 큰 회사에서 경력을 쌓을 기회를 얻었다.

큰 회사에서

처음 큰 회사에 합격하고, 로망이었던 큰 회사에 합격했다는 기쁨과 내가 시니어로 넘어가려면 어떻게 해야하는지에 대한 목마름을 해결할 수 있겠다는 설레임으로 첫 프로젝트를 맡아 업무를 진행하게 되었다.

그런데 뭔가 생각과 달랐다. 코드의 퀄리티, 설계에 엄격하게 집착하던 환경에서 와서 그런진 모르겠으나 리뷰도 짧았고 같이 의논할 시니어도 없었다. 심지어 시니어의 코드의 퀄리티가 내가 보던것과 달라 당황스럽기도 했다. 또 유지보수 되고 있는 서비스의 코드도 이 스타일 저 스타일이 섞여 분석하여 새로운 기능을 추가하기 쉽지 않았다.

내가 너무 무턱대고 이직을 생각했나? 라는 생각도 들고, 앞으로 내가 여기서 성장이라는걸 할 수 있을까? 라는 의문이 쌓이며 시간은 흘러갔다. 팀 특성상 변화가 많았고 이런 저런 프로젝트를 진행하게 되었는데, 그러면서 운좋게 이 회사에서 오래 근무한 좋은 시니어분과 일하게 되었고 점점 이곳을 이해하게 되었다.

성과가 중요하다

어떤 프로젝트에 리소스가 투입되고 그 결과로 돈을 벌기 위해선 성과가 중요하다. 성과를 내려면 어떻게 해야할까? 성과가 뭘까? 내가 진행하는 프로젝트가 조직의 목표와 어떻게 부합되는지, 그리고 조직은 그걸로 어떻게 돈을 벌어서 다음 스텝으로 나아갈지 이해할 수 있어야 한다.

또한 프로젝트가 어떤 성격을 띄는지도 중요하다. 단순히 시장성을 시험해보기 위한 데모의 성격인지, 아니면 시장성이 검증된 요소를 기반으로 여러 기술을 조합하여 돈을 벌 목적의 서비스를 만들것인지, 여러팀의 생산성을 증폭시키기 위해서 어떤 기능을 플랫폼화 할 것인지, 그 플랫폼을 외부에 팔아서 돈을 벌것인지 여부 등등이 있다.

그리고 이런 프로젝트의 성격에 따라 또는 리소스에 따라 코드의 작성 방식도 달라진다. 빠른 시장성 검증을 위해서 일회성 코드를 작성할것인지, 여러 동시에 진행하는 프로젝트가 있기 때문에 각 프로젝트에 얼마만큼의 리소스만 사용할것인지, 그에 따라 버그를 근본적으로 해결할 수 없다면 work around로 해결할것인지 등등 각 상황에 따른 trade off를 분석해서 기회비용이 적은 방식으로 리소스를 사용해야한다.

뭐가 중요한지 이해가 되기 시작하자 내가 큰 회사로 이직해서 마주했던 아쉬웠던 점이 이해되기 시작했다. 합리화랑은 다르다. 충분히 필요한 상황이 된다면 나는 엄격하게 코드를 작성하고 가독성과 확장성, 변경에 대응 가능하도록 코드를 작성할 것이고 이미 좋은 케이스를 경험했고 항상 고민하기 때문에 충분히 가능하다.

결론

이러한 경험을 하고나자 내가 원했던 "시니어는 어떤 역량을 가져야 할까"에서 새로운 관점의 요소들이 추가되었고, 이 부분을 제대로 성장시켜 나아가려는 노력을 할 것이다.

• 조직과 나를 위해 성과가 필요하다. 조직과 얼라인이 맞는 프로젝트, 비즈니스적으로 돈을 벌 수 있는 프로젝트를 볼 수 있는 눈을 기른다.
• 리소스는 한정 되어있다. 나와 나의팀 모두. 프로젝트의 종류에 따라 개발 인력과 리소스가 적절히 활용될 수 있도록 리딩한다.
• 내가 만든 성과들을 기록하고, 지속적으로 리더와 소통하여 조직의 방향과 얼라인이 맞는지 점검한다.

현실적인 요소들을 정확하게 고려하자. 조직을 리딩하고 회사와 얼라인을 맞춰 개발 인력과 리소스를 활용하여 비즈니스적으로 성과를 내자.

Reference

• 메인 이미지: https://yalechurch.org/v3/joy-column-03-10-2018/