엔지니어가 코드 소유권을 어떻게 바라봐야 하는지, 기술 부채·속도·품질 사이의 의사결정에서 회사와 매니저를 신뢰하며 일하는 법을 다룬 글
엔지니어는 종종 자신이 작성한 코드에 강한 소유감을 느낀다. 어느 정도는 당연하다. 그 코드는 부분적으로는 그들의 창작물이기도 하고, 동시에 그들의 업무 공간이기도 하므로, 그곳이 일하기 좋은 공간이었으면 하는 직접적인 이해관계가 있다.
이 때문에 엔지니어들은 “급한 땜질”을 내보내거나, 기술 부채를 유발할 수 있는 기능을 서둘러 출시하려는 시도에 강하게 반발하곤 한다. 그들에게는 자신들이 애써 예쁘게 만들어 놓은 코드베이스가 훼손되고 있다는 느낌이 든다. 마치 누군가 자기 집에 들어와서 온 집안에 진흙을 잔뜩 묻히고 다니는 것처럼 느껴지는 것이다.
하지만 그런 감정이 이해할 만하다고 해서, 그게 그대로 사실이라는 뜻은 아니다. 그 코드는 당신 것이 아니다. 코드는 회사의 자산이다. 당신은 그 위에서 일하도록 고용된 전문가일 뿐이고, 회사가 더 이상 당신이 그 코드에서 일하지 않는 것이 자사 이익에 부합한다고 판단하는 순간, 당신은 더 이상 그 코드에서 일하지 않게 된다.
대부분의 똑똑한 엔지니어가 자신이 다루는 코드베이스를 진짜로 자기 소유라고 믿는다고 생각하지는 않는다. 하지만 행동 양식을 보면 그렇게 믿는 것처럼 보일 때가 많다. 예를 들어, 회사가 뭔가를 서둘러 내보내려 할 때, 많은 엔지니어들이 코드베이스의 품질을 지키겠다는 명목으로 적극적으로 저항한다. 물론 이렇게 행동할 만한 합리적인 이유는 있다.
하지만 나는, 위 조건들 어느 것도 충족되지 않는데도 강하게 반발하는 똑똑하고 헌신적인 엔지니어들을 많이 봐왔다. 내가 내릴 수 있는 유일한 결론은, 이들이 코드베이스를 외부의 부정적 영향으로부터 지켜야 할 책임이 자기에게 있다고 생각한다는 것이다. 다시 말해, 코드베이스는 자기 것이고, 회사의 목표는 외부의 간섭이라고 여기는 셈이다. 실제로는, 코드베이스는 오직 회사의 목표를 달성하기 위해 존재할 뿐이다. 엔지니어인 우리가 오히려 그 코드베이스에 가해지는 외부 영향이다.
당신의 매니저들은 코드 한 줄 한 줄 수준의 구체적인 기술적 결정을 내릴 만한 맥락은 충분히 갖고 있지 않을 수 있다. 그러나 당신과는 달리, 속도와 품질 사이의 큰 트레이드오프를 정할 수 있을 정도의 맥락은 가져야 한다. 예를 들어, 회사가 어떤 재무적 압박을 받고 있는지, 대형 연례 컨퍼런스에서 신기능 X를 발표하는 것이 얼마나 중요한지에 대해서는 그들이 더 잘 알고 있을 가능성이 크다. 엔지니어들은 이런 이야기를 들으면 비웃기 쉽다. “장기적인 품질이 중요한 거지, 컨퍼런스에서 한 번 떠들어 보겠다고…” 라고 말이다. 하지만 이런 것들은 실제로 정말로 중요하다2.
이에 대한 고전적인 엔지니어 측 반론을 내가 최선으로 요약해 보자면 다음과 같다.
맞아요, 이론적으로는 회사가 얼마나 많은 기술 부채를 감수할지 결정할 권리가 있죠. 하지만 각 개별 엔지니어링 매니저의 이해관계를 보면, 자기 재임 기간 안에 성과를 내기 위해 기술 부채를 최대한 끌어올리고 기능을 최대한 빨리 출시하는 쪽으로 기울어질 수밖에 없어요3. 후폭풍을 겪을 때쯤이면 이미 떠나고 없을 테니까요.
그러니 엔지니어들은 이런 행태에 맞서 싸워야 합니다. 자기들 코드베이스를 부숴 가며 일하고 싶지 않은 건 엔지니어들의 이해관계이기도 하고, 개별 매니저 일부의 생각과 달리, 회사 전체의 장기적 이익 또한 더 건강한 코드베이스를 유지하는 데 있으니까요.
이런 일이 실제로 일어나는 경우도 있다. 하지만 이런 시각은 당신의 일을 매우 냉소적인 관점에서 바라보는 것이다. 내가 함께 일해 본 매니저나 프로덕트 매니저들 중에는 단기적인 이익에만 관심 있는 사람들도 있었다. 그러나 그와 반대로, 진심으로 올바른 일을 하고 싶어 하고, 실제로 강한 이유가 있을 때에만 단기적 이익을 밀어붙이는 사람들도 있었다.
내 경험으로는, 신뢰의 부재는 종종 자기 충족적 예언이 된다. 어떤 엔지니어가 기술 부채를 쌓는 일에 항상 강하게 반대한다면, 매니저는 그 엔지니어가 정말 중요한 순간을 구분해서 말해 줄 거라고 믿지 못하게 된다. 그래서 어디에 얼마만큼의 기술 부채를 쌓을지 스스로 결정해 버리려 한다. 그러면 엔지니어는 자신이 배제되고 있다고 느끼며 “거 봐, 이 매니저는 품질에는 1도 관심이 없어.”라고 생각한다. 실제로 벌어진 일은 신뢰와 소통의 붕괴일 뿐인데 말이다.
코드베이스를 내 것이 아닌 것처럼 다룬다는 건 어떤 의미일까? 그것은 가만히 있으면서 들어오는 대로 기술 부채를 무한정 쌓으라는 말이 아니다. 여전히 당신에게는 리스크와 그 결과를 매니저에게 설명할 의무가 있으며, 진짜로 파국적인 결과가 예상될 때는 요구를 거부하고 버티는 것도 필요하다. 다만, 어떤 리스크를 감수할지에 대한 최종 결정은 매니저에게 맡긴다는 뜻이다.
마찬가지로, 어떤 기술 스택을 쓸지에 대한 최종적인 기술적 결정 또한 회사가 내리도록 둔다는 뜻이기도 하다. 회사가 React로 전환하고 있다면, 당신의 일은 당신의 코드베이스를 React로 옮기는 것이다. 회사가 Postgres 중심의 조직이라면, 가능한 곳에서는 Postgres를 사용하는 것이 당신의 일이다. 회사가 때때로 잘못된 기술적 결정을 내릴 수도 있다. 당신은 그들을 설득하려고 노력할 수는 있지만, 결국 자기 시스템에 대한 결정을 내리는 것은 그들의 권한이다.
또한 이는 다른 엔지니어들을 위해 최적화한다는 뜻이기도 하다. 당신이 어떤 코드베이스를 만들어 놓았고, 팀의 다른 엔지니어가 리팩터링을 제안했다고 하자. 그 리팩터링을 정당화하려면, 기존 상태보다 어느 정도나 더 좋아져야 할까? 사실, 그 리팩터링이 코드베이스를 아주 조금 더 나쁘게 만들더라도, 그 리팩터링을 허용하는 편이 여전히 더 나을 가능성이 크다. 리팩터링을 수행한 그 엔지니어가 해당 부분의 도메인 전문가가 되기 때문이다. 시간이 흐르면서 더 많은 사람을 코드베이스 안으로 끌어들이는 것은, 작은 품질 저하를 상쇄하고도 남을 장기적 이점을 만들어 낸다.
어느 정도의 코드 소유감은 피할 수 없고, 아마 건강한 것이기도 하다. 당신이 만든 것에 신경을 쓰는 것은 좋은 일이다! 하지만 그렇다고 해서 당신이 그 코드에 대한 실질적인 소유권을 갖고 있다는 뜻은 아니다. 당신이 일터에서 시간을 보내는 그 코드베이스는 회사의 코드베이스이며, 회사는 그것을 가지고 무엇이든 할 수 있다. 당신은 결정이 가져올 리스크와 결과를 설명해야 하지만, 궁극적으로는 그 결정권이 당신에게 있지 않다는 점을 인정해야 한다.
이 글이 마음에 들었다면, 새 글이 올라올 때 이메일로 받아볼 수 있도록 구독을 고려해 보거나, Hacker News에 공유해 주길 바란다. 이 글과 태그를 공유하는 연관 글의 프리뷰는 아래와 같다.
힘든 시기를 지나고 있는 엔지니어들을 위한 실질적인 조언
2023년 이후, 금리 상승은 소프트웨어 회사들이 엔지니어를 대하는 방식에 대변화를 일으켰다. 지난 10년 어느 때보다 지금이 소프트웨어 엔지니어로 일하기 힘든 시기다. 적어도 당분간은, 테크 업계의 좋았던 시절은 끝났다. 힘든 것은 구직 시장만이 아니다. 이미 일하고 있는 소프트웨어 엔지니어들에게도 환경이 험난해졌다. 우리는 여기에 어떻게 대응할 수 있을까?
