비전공 개발자가 흔히 하는 고민

지난 주에 30대 초반에 부트 캠프를 통해 엔지니어로 전직한 분과 이야기해보는 시간이 있었다. 30대 중반이 되어 주니어 개발자로 일하고 있는데 대학을 졸업한지 2-3년차 동료들과 비교하며 힘들어 하고 있었다. 부트캠프부터 치면 3년이 되어가는데 아직도 잘 모르겠다고 하면서 어떻게 살아야할지 길을 잃은 것 같다고 고민을 털어놓았다. 30-40대 경력 전환 주니어 개발자들과 이야기하다보면 항상 나오는 패턴이다.20대로 돌아가면 어떻게 살것 같냐고 했더니 조금 생각하더니 술술 잘 이야기하길래 지금부터 그렇게 살면 된다고 조언해주었다. 앞에 시간이 많기에 (이분은 앞으로 적어도 40년은 일해야한다 ^^) 늦은 것 같지만 늦은 게 아니다. 나이가 주는 강박관념과 과거에 보낸 시간이 물경력이 아닐까 하는 후회, 그러다보니 나보다 어리지만 사실은 그 분야에서 더 오랜 시간을 보낸 사람들과 비교하기 쉽다.개발에 들어온지 3년만에 잘 할 수 있다면 그건 천재다. 오랜 시간이 걸리며 디버깅은 다들 아주 사소한 걸로 몇 시간부터 며칠 보내는 일이 허다하다. 마음이 조급하다보면 회사 일을 열심히 해서 실력을 늘리기 보다는 회사 일은 회사 일이고 업무 시간 밖에서 아직은 너무 어려운 다른 공부를 하며 스트레스 받기 쉽다 (방정식을 배우는 단계에서 미분을 배우려고 하는 듯 한 느낌). 처음은 기본기다.길게 바라보며 나만의 길을 찾고 내가 있는 곳에서 잘 하려고 최선을 다 해보는 것이 커리어를 발전시키는 가장 쉬운 길이다. "나"와 "현재"에 집중해보자.커리어 멘토링에 관심있다면 https://www.inflearn.com/mentors?mentor_id=1823 :)

성장하는 조직의 기술 부채는 언제 갚을까?

작은 회사에서 속도에 초점을 맞추고 주니어 중심으로 개발을 하면 당연히 기술 부채가 쌓인다. 워낙 숨 가쁜 일정으로 돌아가다 보니 유닛 테스트를 만드는 건 꿈도 꿀 수 없고 최종 QA(Quality Assurance)도 대충 하고 프로덕션에서 실제 고객들이 테스트 아닌 테스트를 하는 일도 다반사다. 자잘한 버그가 자주 보고되는 것은 물론 가끔 사고도 터지며, 이런 기술 부채로 인해 생긴 누더기 같은 코드로 인해 새로운 기능 개발도 지연되기 시작한다. 그렇다고 내일도 살아있을지 아무도 모르는 작은 회사에서 항상 깔끔하고 완벽하게 테스트된 코드만 지향하거나 무모하게 새로운 프레임워크를 사용해 볼 수도 없는 노릇이다. 시작하는 단계의 스타트업이 빠른 속도와 무결점 중 꼭 하나만 선택해야 한다면 속도를 선택하는 편이 유리하다는 게 내 생각이다. 그 대신 아래의 내용을 참고하면 돈이 더 생기고 더 경험 있는 사람을 뽑기 전까지 리스크를 최소화할 수 있을 것이다. 어느 시점부터는 슬슬 사고의 빈도가 늘며 정도도 심해지기 시작할 때 그 때부터는 아래를 고민해보는 것이 좋은 듯 하다.서비스 모니터링 프로세스를 만든다. 서비스에 문제가 생기면 빨리 인지하고 해결하는데 초점을 맞추는 것이다. 이 것도 상당한 노력과 시간을 필요로 할 수 있는데 기술 부채를 많이 안고 가는 상황에서 모니터링에 대한 노력을 먼저 기울이는 것이 맞다고 본다. 어떤 지표를 바탕으로 서비스의 안정성을 측정할 것인지 그리고 서비스에 문제가 생겼을 경우 어떻게 escalate하고 문제해결을 할지 점진적으로 개선해가며 프로세스를 만드는 것이다. 또한 사고의 심각성에 따라 재발을 막을 방법을 찾아봐야 하는데 이건 뒤 문단에서 이어서 더 이야기해보겠다. 2. 매주 엔지니어링 미팅 등에서 지난 한 주간의 버그와 사고를 리뷰하고 이유를 파악한다. 유닛 테스트 코드를 붙이지는 못하고 QA를 충분히 하지 못하더라도, 이미 발견된 버그와 사고가 재발하는 것을 방지하기 위한 테스트는 붙이는 것이 필요하다고 본다. 서비스 모니터링 프로세스가 어느 정도 자리잡혀있다면 사고 리뷰는 상대적으로는 쉬워진다. 만일 버그와 사고의 빈도가 점점 높아진다면 새로운 기능 개발뿐 아니라 기존 코드의 리팩토링에도 시간을 써야 한다. 유데미 시절 데이터 엔지니어링 팀은 이슈가 늘어나면서 그러다가 대형 사고를 한번 겪고 난 뒤 최대 40%의 시간을 리팩토링에 할애했다. 3. 훌륭한 개발자는 자신이 만든 결과물이 실제 사용자들에 의해 어떻게 사용되는지 관심이 많고 실제 사용자의 피드백에 귀를 기울이는 사람이다. ‘개발 다 했으니 내 업무는 끝!’이 아니라 어떻게 쓰이는지 보고 개선하려는 의지가 있다는 말이다. 인정받는 개발자 혹은 좋은 개발 팀의 매니저가 되고 싶다면, CS/CX 팀과의 협업 채널을 만들고 주기적인 미팅을 통해 고객의 소리를 들어보고 사람이 되자. SDD(Support Driven Development)라는 말을 들어봤는가? Y Combinator 스타트업 스쿨에서 강조하는 원칙 중의 하나이다. 몇 가지 상대적으로 쉽게 붙여볼 수 있는 중요한 성능 모니터링이 있는데 첫 번째는 백엔드 데이터베이스의 오래 걸리는 쿼리를 모니터링하고 문제 되는 부분을 찾아 미리 최적화하는 것이고 두 번째는 서비스 홈페이지나 중요 API의 실행시간 (latency) 모니터링을 해보는 것이다. 이를 기술 부채를 해결하기 위해 단기적 관점에서 해볼 수 있는 일이다. 물론 위와 같은 방법을 동원해도 사고는 터진다. 그중 몇 건은 대형 사고일지도 모른다. 그럴 때 중요한 것은 사고를 바라보는 경영진의 관점인데, 특정인이나 팀을 향해 손가락질하기보다는 사고 경위서를 작성해서 사고의 원인을 이해하고 재발 방지 대책을 세운 뒤 사내에 공유하는 과정에 집중해야 한다. 여기서 포인트는 경위서 작성 자체가 아니라, 밝혀진 문제의 재발을 막기 위한 조치들이 경위서의 내용에 포함되고 이런 조치들이 실제로 구현되어야 한다는 점이다. 온라인 서비스에서 사고는 언제 일어나느냐의 문제지 피해갈 수는 없다. 회사가 망할 정도의 사고만 아니라면 조직 구성원 모두가 기술 부채 등의 다양한 이슈를 체감하고 이를 줄이기 위해 노력할 수 있는 기회가 된다는 사실을 잊지 말자. 모든 위기는 기회가 될 수 있다. 모든 사람들이 기술 부채 문제를 체감하는 회사가 망할지 않을 정도의 대형 사고를 내가 사랑하는 이유다 🙂 What doesn’t kill you makes you stronger!