목적 조직에서 개발자로 살아남기

목적 조직에서 2년 간을 일하며 느꼈던 바를 기록하고자 한다. 당연히 목적 조직이냐 기능 조직이냐에 대한 답을 내리는 등의 담론을 다루고자 함은 아니며 목적 조직에 몸담으며 느낀 개발자의 역할에 대해 이야기려고 한다. 또한, 우연히 다른 블로거분이 기획자 관점에서 쓰신 개발팀과 개발팀장이 사라져야 하는 이유라는 글을 보았는데, 몇 가지는 동의하지만 몇 가지는 그렇지 않기에 이 글을 통해 반박해보고 싶다.

비즈니스 vs 시스템

기획자, 데이터분석가, 개발자로 구성되어 있는 조직에서의 2년을 요약해본다면 비즈니스 vs 시스템이라는 두 가지 목표의 충돌이었다. 이게 무슨 해괴한 소린가. 결국 회사 모든 조직의 목표는 돈을 버는 것인데 조직 내부에서 추구하는 바가 다를 수가 있을까? (혹은 달라서야 되겠는가?)

실제로 그런 일의 연속이었다. 우선 우리 팀은 스플린트라고 하는 단위 기간의 반복을 통해 점진적으로 서비스를 개선해가는 애자일 프로세스를 추구하고 있었고, 2~3주마다 스플린트에서 진행할 과제를 논의하는 플래닝을 하곤 했다. 거기서 논의되는 과제는 기능적인 요구사항 또는 시스템적인 요구사항이다(가끔은 두 가지를 포괄하는 성격의 과제도 있다). 당연하게도 기획자는 신규 기능 추가/개선 등의 기능적 요구사항을 발의하며 개발자들은 시스템 안정성이나 자동화 등에 관련된 시스템적인 개선 과제를 발의한다.

이 둘은 본질적으로 목적이 같다. 적어도 나는 그렇게 본다. 기능을 추가하는 것과 안정적인 시스템을 만드는 것의 목표는 결국 '좋은 서비스'를 만드는 것이다. 사용자 경험을 개선하고, 더 많은 사용자가 모여 더 많은 돈을 쓰게 하기 위함이다. 하지만 지난 2년 동안 기획자와 개발자가 생각하는 과제의 우선순위가 어긋나왔으며 결과적으로 합의점을 찾아 오기는 했지만, 기획자와 개발자의 입장 차이에 대한 근본적인 의문이 생길 수 밖에 없었다.

건설 사고와 소프트웨어 장애

한 가지 비유를 해보자. 건설 현장에서 사고가 나면 어떻게 될까? 아주 작은 실수로 인해 벽돌 하나가 떨어져도 주위 지나가는 사람이 맞는다면 대참사로 이어진다. 반면 소프트웨어는 어떨까? 최악의 사고가 나더라도 잠시 서비스가 중단될 뿐이지 않은가.

하지만 실제로는 소프트웨어의 장애 상황 역시 대참사로 이어질 수 있다. 실제 돈이 오가는 뱅킹/결제 관련 서비스는 말할 것도 없고, 스트리밍 플랫폼이라면 예정되어있던 여러 라이브 방송이 취소되고 그로인해 수 많은 업체들이 피해를 볼 것이다. 게임이라면? 게임을 하기 위해 돈을 지불한 수 많은 사용자가 게임을 이용하지 못하는 시간 동안 피해를 보는 것이다.

물론 개발자가 아니라고 해서 이에 관해 모르는 것은 아니다. 하지만, 지금 이 순간에 시스템을 개선하는 과제가 서비스 안정성, 향후 시스템 확장성과 관련해 어떤 의미가 있는지를 설명하고 설득하는 것은 오롯이 개발자의 몫이다.

개인적 성과와 Reputation

서두에서 언급한 개발팀과 개발팀장이 사라져야 하는 이유라는 글에서 필자는 개발팀이 사라져야 하는 이유 중 하나로 개발자들이 매출에 대해 관심을 가지지 않고 개발 그 자체에 목적을 두기 때문이라고 했다. 일부 동의한다. 개발자는 매출보다는 대량의 트래픽에도 버틸 수 있는 안정적인 시스템 구조나 빠른 서비스 응답 속도를 신경쓴다. 그러나 이 또한 결국 '좋은 서비스'를 만들기 위한 공동의 목표 아래에 있는 하위 목표이며, 매출과 관계가 없다고 볼 수 없다.

반면 기획자의 입장은 어떤가? 끊임없이 발생하는 비즈니스 요구사항을 취합하여 신규 서비스/기능, 또는 개선 기능을 기획하는 것이 기획자의 역할이다. 또 그것이 비즈니스 임팩트가 있기 때문에 결국 서비스 성장과 매출에 도움이 된다. 때문에 해당 과제의 우선순위를 높이자고 요구하는 것이 기획자의 역할인 것이다. 개발자 입장에서 보면 기획자는 시스템 안정성이나 유지보수성은 고려도 하지 않고 비즈니스 요구사항만 밀어붙이는 사람들로 비춰질 수 있다.

또, 개발팀과 개발팀장이 사라져야 하는 이유에서 필자는 개발 기술이 좋아지면 매출이 좋아지는게 아니라 그 개발팀 혹은 개발자의 몸값이 올라가는 것이라고 했다. 우선 앞선 건설현장 예시로써 기술적으로 안정적인 서비스를 만드는 것이 매출과 전혀 관계가 없다는 주장은 설득력이 없음을 지적하고 싶지만, 결국 고오급 기술을 도입해서 더 빠르고 안정적인 서비스를 만들고자 하는 목표가 개발자가 기술 역량을 향상시키고자 하는 개인적 목표와 Reputation으로 이어진다는 것은 인정한다.

하지만 반대로 생각해보자. 신규 기능을 추가하는 것은 기획자의 개인적 목표와 연관이 없는가? 기획자의 개인적 성과는 결국 돈이 되는, 즉 비즈니스 임팩트가 있는 기능이나 서비스를 추가했는지 여부에 달려있다. 신규 기능 추가 과제의 우선순위를 높이려는 것은 기획자의 개인적인 목표 달성과 관련이 없는가?

물론 그것이 잘못됐다는 뜻은 아니지만 개발자들은 공동(회사)의 목표보다는 개인의 목표를 위해 공동 목표와 배치되는 방향으로 일을 한다는 식의 주장은 받아들이기 어렵다. 기획자도, 개발자도 결국 공동과 개인의 목표를 동시에 추구하고 있다.

또, 개발자가 단순히 몸값을 높이려고 구글에서 발표한 신기술을 도입하고 멀쩡한 시스템 아키텍쳐를 갈아엎는 것이 아니다. 신기술이 왜 탄생했겠는가? 기존 기술로는 특정 문제를 해결할 수 없기 때문이다. 신기술을 개발한 사람들은 단순히 그게 재밌다거나 시간이 남아돌아서 그것을 만들어내지는 않았고(물론 예외적인 1%가 있긴하다), 그것을 도입하는 입장에서도 재미나 개인적 목표를 위해서 업무 시간을 할애하는 것이 아니다. 개발자가 더 안정적이고 빠른 시스템을 만들기 위해 여러가지 시도를 하는 것을 단순히 '본인 몸값을 놓이기 위한' 행위로 보는 것은 다소 편협하고 아쉬운 시각이다.

장애를 내더라도 임팩트가 있으면 좋은게 아닌가요

기획자와 개발자가 결국 좋은 서비스를 만들자는 궁극적인 목표는 같지만 추구하는 바가 다르다. 기획자는 기능/서비스의 추가를 원하고 개발자는 그 전에 시스템 아키텍쳐를 개선하기를 원한다. 이 입장 차이를 단적으로 보여주는 사례가 있었다.

당시 다른 팀이 제공 중인 사내 API를 우리가 활용해서 개발을 진행해야 하는 상황이었다. 그런데, 해당 API가 안정적이지 못해 이슈가 있었고 시스템 개선 등을 담당 팀에 요청해보았지만 일정을 이유로 거절을 당했다. 우리 팀도 해당 API를 활용하지 않고는 방법이 없는 상황이지만 개선없이 그대로 쓸 경우에는 장애 발생까지 우려되었다. 그때 팀장님(기획자 출신)이 하신 말씀이다.

장애가 난다는건 그만큼 트래픽이 많이 발생했다는 건데, 그렇다면 비즈니스 임팩트가 있다는 거니까 좋은거 아닐까요? 결국 해당 API 개선 건에 대한 우선순위가 올라갈 테니까요

이 코멘트가 인상깊었던 이유는 엔지니어로서 예견가능한 장애는 절대, 절대로 내서는 안되는 것이 당연하다고 믿어왔는데(반박할 여지조차 없는) 그 믿음에 정면으로 반하는 발언이었기 때문이다. 하지만 곰곰히 생각해본 끝에 그래서는 안된다는 결론에 도달했고, 해당 발언 덕분에 개발자의 역할이 무엇인지에 대해 확실히 정리해볼 수 있었다.

우리는 확실히 좋은 서비스를 만들고자 하는 공동의 목표를 가지고 있었다. 팀장님의 코멘트는 장애를 내더라도 비즈니스 임팩트를 내는 것이 결국 좋은 서비스를 만드는 데도 도움이 될 것이라는 주장이었다. 하지만 시스템 장애의 영향이 전사 범위까지 퍼질 수 있으며, 불안정한 서비스를 그대로 오픈한다면 향후 운영 중인 상태의 서비스 아키텍쳐를 뜯어고치는데 결국 더 많은 비용이 들 것임을 고려한다면 반대로 설득을 해야만 했다. 그렇게 설득하는 것이 개발자의 본분이며 책임이다.

목적 조직에서 개발자로 살아남기

목적 조직에서 개발자의 역할은 시스템 관점에서의 결점을 끊임 없이 찾아내서 더 좋은 시스템을 만들기 위해 개선하자고 설득하는 것이다. 기능 조직이라면 이것이 개발팀 자체의 역할이 될 것이다. 그렇다면 기획자는? 서비스 요구사항을 취합하여 더 좋은 서비스를 만들기 위해 기능이나 서비스를 추가하자고 끊임없이 요구해야한다. 그리고 건설적 토론을 통해 둘 사이의 간극을 좁혀가며 균형을 잡고, 결과적으로 좋은 서비스를 만들어가는데 도움이 될 방향을 결정하면 되는 것이다.

물론 현실적으로는 경력이나 직급의 차이가 있을 경우 설득하기보다는 번번히 설득 당해버리기 때문에 균형을 맞춰가기란 쉬운 일이 아니다. 때문에 목적 조직을 빌딩한다면 구성원의 밸런스를 잘 고려해야한다. 내가 경험했던 목적 조직은 초창기부터의 밸런스가 좋지는 않았던 것 같고, 내가 더 설득을 잘 했더라면 지금보다 더 안정적이고 완성도 있는 서비스를 만들 수 있었을 거라는 아쉬움이 들기도 한다. 그럼에도, 그냥 개발 조직에 쭉 있었다면 고민조차 안해봤을 고민들을 많이 해볼 수 있었고 그것이 결국 더 좋은 개발자가 되기 위한 양분이 되리라 굳게 믿는 수밖에 없다.

참고
https://seokjun.kim/no-reason-for-dev-team/

개발팀과 개발팀장이 사라져야 하는 이유