좋은 엔지니어링 기회 자체가 불평등하다

3월 1일에 toss 10 to 100 행사에서 진행된 토스팀 Head of Frontend 박서진님의 세션에 초청받아 다녀왔다. 본인께서 토스에서 커리어를 시작하시게 된 경위와, 어떻게 토스 프론트엔드 챕터, 제품, 문화를 어떻게 발전시키고 지금에 이르게 되었는지에 대한 이야기를 흥미롭게 들었다.

세션을 듣다가 꽂힌 부분 중 하나는 "장인정신 없이 일을 하는 것은 1년차의 경험을 계속 반복하는 거라고 생각합니다." 라고 말씀하신 부분이었다. 장표에 쓰여진 글씨는 "1년차 6번 반복하기 vs 매년 새롭게 일하기"였었다. 어떤 개발자는 경력에서 "1년차 경험을 6번 반복"할 수도 있다는 사실을 상기시켰다.

좋은 엔지니어링 기회는 불평등하다. 모든 개발자가 어떤 회사를 가던지 성장의 정도 같은 것을 걷고 시간이 지남에 따라 숙련된, 좋은 경험을 쌓은 엔지니어가 될 수 있는 것은 아니다. 밀도있는 경험은 중요하다. 서진님은 경험의 밀도가 중요함을 알고 이것을 설명하며, 토스가 밀도 높은 엔지니어링 경험을 제공할 수 있음을 이야기한다. 토스가 좋은 엔지니어링 팀임을 느꼈다.

나도 개인적인 차원에서 밀도있는 엔지니어링 경험을 쌓기 위해서 중요하다고 생각하는 것들을 이야기 해보고 싶어졌다. 좋은 엔지니어가 무엇인지는 무척이나 상대적이므로 엔지니어로서의 이상형을 먼저 밝히면, "제품과 비즈니스의 어떤 스테이지에서도 적절한 엔지니어링을 통해 제품과 팀의 성장에 도움이 되는 엔지니어" 정도겠다. 이 기준은 누구에게는 "매출을 100배 올릴 수 있는 엔지니어"일 수도 있고, "함께 성장하는 팀을 만드는 엔지니어" 일수도 있다. 다 멋진 목표다.

언급할 모든 좋은 엔지니어링 경험의 요소들은 매우 유기적으로 연관되는 면이 있다. 그래서 아래와 같은 한 줄 요약으로 시작할 수 있다.

제품이 잘 되면, 운영을 해야 하고, 그러다 보면 확장 수요가 생기고, 채용이 되면 같은 코드베이스에서 작업하는 사람들이 많아지고, 난이도 있는 기술들의 도입들이 필요하고 문제들이 점점 어려워지며, 코드들의 수명이 길어지고, 그러한 과정을 온전히 경험하고 회고할 수 있다면, 어떤 엔지니어링 선택들이 맞고 틀렸는지에 대한 배움을 아주 잘 쌓을 수 있다.

의사 결정의 피드백 주기가 수 번 이상 순환해야 한다. 일을 하면서 스스로가 개입한 엔지니어링 선택들이 좋은 결과로 이어졌는지 그렇지 않은지에 대해 알아야 한다. 어떤 엔지니어링 선택들은 결과를 보기까지 수개월에서 수년이 걸리므로 근속 기간이 짧다면 내 선택이 얼마나 맞고 틀렸는지에 대한 감각이 쌓이기 어렵다.

단순히 오래 다닌다고 그런 경험을 할 수 있는 것은 아니다. 조직 문화가 어떤 일을 가장 잘 할 수 있는 사람에게 위임하고, 과정을 온전히 경험할 수 있게 하고, 실패를 용인하고 더 나은 발전을 꾀할 수 있게 회고할 수 있는 환경을 제공해야 한다. 그런 조직문화 안에서는 기술 부채를 엄격하게 인지하고 회고하며, "그때는 맞았지만 지금은 틀렸다"며 뭉뚱그리는 말을 쉽게 허용하지 않는다. 그때는 틀린 결정에 대해, 현재 틀렸다고 말한다.

무조건 제품 운영을 해봐야 한다. 제품을 맨 처음부터만 만들고 계속 떠나보냈던 엔지니어는 성숙하고 오래 영속하는 소프트웨어의 운영 이슈들을 잘 알기 힘들다. 내 코드가 제품 안에서 몇 년이고 살아있을 가능성을 전제로 엔지니어링을 하지 못한다. 인터뷰어로 채용에 참여했을 때, 가장 확인하고 싶었던 인터뷰이의 경험 중 하나는 "프로덕트를 꽤 오랜 기간 운영해본 경험이 있냐는 것"이었다. 그런 경험이 없다면 코드 안에 너무 많은 암묵지를 만들어내고, 흑마법을 쉽게 사용하고, 은연중에 더 위험한 코드를 작성하게 될 가능성이 높아지리라는 우려가 있다.

그런데 망한 제품은 아무도 운영하지 않기 때문에 제품 운영을 하려면 제품이 잘 되야 한다. 좋은 비즈니스가 아니면 좋은 엔지니어링 경험에 한계가 있다. 잘 될 제품에 대해서 나만의 기준 비스무레한 것이 있지만, 내가 무슨 창업해서 대표가 되본 것도 아니고 사실상 잘 아는 것이 없어서 어디다 말할 수 있는 정도는 아니다.

제품이 잘 되면 제품에 대한 확장 수요가 생긴다. 운영을 하다보면 VoC를 제품에 반영하고 더 좋은 비즈니스 기회를 위해 제품을 발전시켜야 한다. 채용을 하고 엔지니어가 많아진다. 코드가 작성되는 속도와 복잡도가 증가하는 속도도 빨라진다. 이 과정에서 특정 스테이지에서는 필요 없는 기술을 사용해야할 여지가 높아진다. 오버 엔지니어링이었던 것들이 적정 엔지니어링으로 바뀐다.

조직과 제품 스케일에 따라 점진적으로 더 어려운 문제를 해결해야 한다. 마이크로 프론트엔드를 무지 오버엔지니어링이라고 여길 수 밖에 없는 팀이 존재한다. 하지만 플렉스팀의 웹 제품에는 적정 엔지니어링이다.

내가 일하는 플렉스팀은 이러한 조건들에 어느 정도 이상씩은 부합한다. 그렇기에 나는 팀에서 지속적으로 즐겁게 일할 수 있으며 정신과 시간을 소모해 문제를 해결하고 보람을 얻을 수 있다. 또한 밀도 있는 엔지니어링 경험을 다른 엔지니어들도 수월하고 재미있게 경험할 수 있게 하는데 기여하고 있다.

위에서 설명한 요소들은 근속 기간 정도를 제외하면 대부분 나에게 달린 것이 아니다. 어떤 시기에 어떤 경험을 할 수 있다는 것 자체가 운이 무지막지하게 작용한다. 그래서 사실상 뭘 하라거나, 혹은 누군가가 하는 것이 잘못되었다는 조언 같은 것을 할 수 없다. 그런 조언을 들었다면 무지개 반사해야 한다.

회사가 갑자기 망한다거나, 조직이 구리거나 구려진다거나, 내가 아무리 뭔가를 원해도 할 수 없는 상황에 온다고 하면 다 쓸모 없다. 앞에서 이야기한 밀도 있는 경험들을 제공받을 수 없는 환경에 처하거나 내가 쌓을 수 없는 시기에 진입한다면 그만두고 다른 직장이나 다른 일을 알아볼 것이다.