Lucathree.com

부끄럽지만 굉장히 오랜만의 포스팅이다.

변명을 하자면 업무에 집중하며 지내느라 바빴고 나쁘게 말하자면 일만 했다.

그렇게 일에만 집중하며 지냈는데 어쩌다보니 인생 전체에서 세 번째 직장이자 개발자로서는 두번째 회사였던 포자랩스를 떠나게 되었다.

경영악화로 인한 권고사직… 갓 투자를 받고 한참 성장중이던 회사에 합류해 기존에 있던 인원의 세 배로 규모가 커지고 독립된 사무실이 생기는 모습까지 봤는데 추진력을 잃은 로켓은 빠르게 올라갔던 만큼 빠르게 추락해버렸다.

두 번의 선행된 권고사직을 보며서도 ‘나는 아직 이 회사에 필요하구나’라는 안도감과 ‘나도 곧 떠나야하게 되겠구나’하는 양가적인 감정들이 들었지만 회사에 애정이 있었기에 끝까지 가보고 싶다는 생각이 있었고 마지막까지 어떻게든 내가 할 수 있는 일을 찾아 하기위해 노력했다. 하지만 아무래도 개발자의 업무만으로는 비즈니스를 다시 일으키기에 역부족이었나보다.

아쉽게도 애정했던 회사의 끝을 보게 된 지금, 포자랩스에서의 마지막 회고를 남겨본다.

—

포자랩스는 회사의 전반적인 비즈니스 역량 부족과는 별개로 개발자로서는 정말 좋은 곳이었다.

파이썬 백엔드로서는 최신 기술 스택을 경험해볼 수 있었고 뛰어난 CTO와 팀원들 덕분에 많은 피드백을 주고 받으며 공부만으로는 얻기 힘든 더 좋은 코드, 더 좋은 시스템을 만드는 법을 자연스럽게 터득할 수 있었다.

특히 1년차 때 주니어 개발자로서 DDD를 도입하며 객체 간 책임분리를 명확하게 하는 법이나 불필요한 문서화나 주석 대신에 코드만으로도 동료 개발자들을 이해시킬 수 있는 방법들을 배운 게 성장에 큰 도움이 됐다. 지금도 코드를 작성할 때 뿐만 아니라 PM이 신규 기능을 위한 기획안을 들고오거나 요구사항 구현을 위한 설계를 할 때면 주어진 책임이 무엇인지를 가장 먼저 바라보고 이 책임을 어떻게 분배할 것인가를 중점적으로 사고하게 된다. 책임이 명확하게 정의되고 분리되면 깨끗하고 확장 가능한 구조는 자연스럽게 따라오는 것 같다.

—

개발 문화도 배울점들이 많았다.

요즘은 그래도 코드 리뷰가 많이 보편화된 것 같은데 이전 직장만해도 코드 리뷰가 형식적으로만 이루어졌던 것에 비해 포자랩스에서는 모두가 꼼꼼하게 코드를 같이 보고 퀄리티를 높이기 위해 노력했다. 드문 케이스이긴 하지만 어떤 때는 PR 하나에 코멘트가 90개 가까이 붙을 정도로 적극적으로 의견을 달고 토론했었다.

매번 그랬다면 업무 블락이 되었겠지만 다행히 그러지는 않았고, 많은 개발자들이 코드 리뷰 과정에서 기싸움을 한다는 외부 개발 커뮤니티의 소문과는 다르게 포자랩스에서는 건전하게 토론하는 방법들을 터득할 수 있었다.

그리고 장애가 발생했을 때 대응하는 방법에 대해서도 장애를 일으킨 사람이나 원인을 찾아 질타하는 대신 포스트모템을 진행하고 다음에 같은 문제가 발생하지 않을 방법을 함께 고민하여 시스템을 고치는 노력들이 이루어져서 좋았다. 개인적으로 실수를 하지 않기 위한 노력은 당연히 수반되어야 하지만 실수를 해도 그 잘못을 개인에게만 돌리지 않고 외부의 요인들을 파악해 같은 실수를 방지할 수 있는 안전망을 만드는 문화는 다른 곳을 가더라도 꼭 도입시키고 싶다.

—

그 외에도 이 곳에서 한 업무들이나 업무 외 활동 중에 기억나는 부분들이 많다.

입사하고 제일 먼저 했던 django와 celery 기반의 음원 생성 시스템을 AWS SQS를 활용한 서버리스 이벤트 기반 아키텍처로 변경했던 작업이나 결합도가 강했던 전체 음원 생성 프로세스를 각 단계 별로 분리해서 활용 가능하도록 리팩토링 했던 작업, 그리고 개발자로서 생각을 명확하게 정리하고 성장하기 위한 회고 작성 활동 등.

거의 3년의 시간을 이 곳에서 보냈는데 여전히 각 작업들이 생생하게 생각날 정도로 배움의 경험들이 뚜렷하게 기억난다. 회고들은 회사 내부 기밀 사항일 수도 있는 부분들이 많아서 블로그에 조금씩 올리다가 멈추긴 했지만 앞으로도 회고도 지속적으로 이어나가고 싶다.

—

물론 회사에서의 업무가 이렇게 마무리되어 버려서 아쉬운 부분들도 많고 또 여기서 단순 개발자를 벗어나 IT 혹은 벤처 스타트업계의 일원으로서 배운 부분들도 있다.

어떤 비즈니스던(기술 스타트업이라 할지라도) 명확한 매출 구조를 갖고 있는 것은 중요하다. (물론 입사 당시에는 B2B로 명확한 고객들이 있었지만 이후 잘못된 방향으로 비즈니스를 틀어버린 것은 할많하않…)

회사의 무리한 확장은 즐길 부분이 아니라 경계 해야할 부분이다.

회사의 규모가 작으나 크나 목표와 비전은 통일되어야 하며 직원 모두가 공감할 수 있어야 한다.

업무 체계나 서면으로 이루어지는 커뮤니케이션도 중요하지만 결국 사람이 하는 일이란 감정적 교류와 non-verbal 커뮤니케이션도 중요하다. 때론 회식이나 함께 휴식을 취하는 활동들은 조직원들이 경직되지 않게 해주는 윤활제로서 반드시 필요하다.

비슷한 성향의 사람들을 모은다고 해서 문화가 생기고 통일감이 생기는 것이 아니다. 회사나 사회나 다양한 사람들이 모임으로써 더 다채롭고 풍부한 문화를 만들게 된다. 관리해야 할 것은 사람들의 성향이 아니라 다양한 의견들을 비효율 없이 조합하기 위한 규칙이다.

—

망했다는 제일 크고 치명적인 단점만 빼면 나에게는 너무 좋은 회사였다. 성장의 기회와 그에 대한 보상, 음악이라는 흥미로운 도메인과 인공지능의 접목에서 오는 도전적인 과제들, 결국엔 사라졌지만 그럼에도 좋은 업무 환경을 제공하기 위해 보장되었던 복지 등.

개발자 취업시장이 그리 좋지는 않은 지금, 나는 이보다 더 만족스러운 다음 직장을 찾을 수 있을지 조금 걱정이 되기도 한다.

LUCATHREE.COM

세 번째 퇴사