"우리 팀 개발자는 진짜 코딩만 할까요?"

우리 개발 팀의 김 대리, 혹은 제임스의 하루는 어떨까요? 며칠을 투자한 덕분에 어제까지 문제가 되었던 버그를 드디어 잡았습니다. 오늘 드디어 새로운 기능을 개발할 차례입니다. 그는 코드 에디터와 여러 툴을 열고, 열심히 서칭도 하고 키보드를 두드리면서 작업을 시작합니다. ...라고 생각했지만, 현실은 좀 다르죠.

실상 개발자들은, 슬랙을 열어 기획팀에게 보낼 질문을 입력했다 지웠다 반복하면서 어떻게 질문해야 하는지 고민하고, 노션에서 기획서와 회의록을 찾아 헤매고, 다른 개발자에게 "이 버튼 UX 혹시 아세요? 이거 버튼 누르면 새 화면으로 이동하는 거예요, 모달을 띄우는 거예요?"라고 물어보고... 코딩하는 시간보다 이런 일에 시간을 쓰는 경우가 많지 않나요? 결국 답을 찾지 못해 "음... 일단 이렇게 만들어보고 나중에 수정하지 뭐"라고 생각하며 모호한 부분은 임의로 결정하고 작업을 시작할 수도 있습니다.

저는 이런 일이 저희 개발 팀에서만 벌어지는 일은 아니라고 생각합니다(제발요). 우리는 개발자에게 개발을 기대하지만, 실제로는 그들의 귀한 시간을 보이지 않는 '기획 잡무'에 허비하고 있습니다. 오늘은 이 숨겨진 비용, 그리고 그 비용을 줄여 개발 생산성을 극대화하는 방법에 대해 이야기해보려 합니다.

1. 우리 팀의 '숨겨진 공장'을 아시나요?

제조업에서는 생산 공정 중 불량이 발생하여 이를 고치기 위해 추가로 투입되는 비효율적인 자원을 '숨겨진 공장(Hidden Factory)'이라고 부릅니다. 이 숨겨진 공장은 생산성에 막대한 손실을 입히지만, 눈에 잘 보이지 않기 때문에 관리자들은 그 존재조차 모르는 경우가 많습니다.

소프트웨어 개발에서도 마찬가지입니다. 우리의 숨겨진 공장은 바로 '불명확하고 파편화된 기획'을 해독하고, 질문하고, 추론하고, 때로는 잘못 만들었다가 재작업하는 모든 비효율적인 시간입니다. 이 시간은 쥐도 새도 모르게 팀원들의 귀한 역량을 갉아먹습니다.

알게 모르게 개발자들이 하고 있는 이 기획 잡무들은 누가 해야 할까요? 어떤 기획자는, 개발자가 기획서를 봤으면 알아서 센스껏 할 수 있는 일인데 그걸 물어보고 있다고 짜증스럽게 생각하고, 어떤 개발자는 자신이 생각할 필요가 없는 일이고 기획자가 구체적으로 명시를 했어야 하는 일이라고 짜증스럽게 생각합니다. 그러다 보니 결국 급해진 누군가가(대체로 개발자가), 체계 없이, 비효율적으로 이 일을 하게 되는 것이죠.

2. 누가, 얼마나 많은 시간을 훔쳐 가는가?

그래서 사실 이 숨겨진 공장의 가장 큰 피해자는 바로 개발자라고 생각할 수 있습니다. 그들은 하루에도 수많은 기획성 잡무에 시달리고 있습니다. 예를 들면 다음과 같습니다.

상황 1: 개발자는 복잡한 노션 문서와 슬랙 채팅창을 보면서 고민한다. "이 정책... 대체 뭘 의미하는 거야? 이런 방식으로 만들라는 게 맞나?"라고 혼잣말한다.
상황 2: 개발자가 슬랙으로 기획자에게 질문을 보낸다. 기획자는 다른 회의 중이라 답장이 늦어진다. 개발자는 답장을 기다리면서 멍하니 앉아 있거나, 답답한 마음에 "일단 이렇게..."라고 생각하며 코딩을 시작한다.
상황 3: 개발된 기능을 보고 기획자가 "어…? 회의에서 이 부분은 다르게 처리하기로 얘기하지 않았나요?."라고 말한다.

그러나 기획자의 입장에서도 할 말이 있습니다. 많은 경우, 기획자들은 자신이 이미 모든 것을 설명했다고 생각하고, 만일 개발자들이 이해하지 못한 게 있었다면 회의에서 질문이 나왔을 것이라 생각합니다. 결국 개발 도중에 개발자들이 질문을 하게 되면, 혹은 개발자들이 만들어 놓은 기능을 보면서, 많은 기획자들은 개발자들의 질문을 듣고 ‘아니, 내 말을 도대체 어디서부터 이해를 못한 거지?’라고 생각하곤 합니다.

결국 기획자와 개발자 사이에서, 다음과 같은 문제들이 발생하게 됩니다.

불확실한 요구사항 해석 및 추론: 기획서에 명확히 정의되지 않은 사용자 시나리오나 정책이 수두룩합니다. 아무리 완벽한 기획서도 모든 것을 써놓을 수는 없습니다. 개발자는 결국 작업을 하기 위해 정책을 추론해내거나, 최악의 경우 임의로 결정할 수밖에 없습니다. 하지만 개발자의 주된 역할은 '기획'이 아니라 '개발'입니다. 개발자가 이러한 기획 업무에 매진하는 시간은 필연적으로 비효율적이고 오류를 유발할 가능성이 높습니다.
끊임없는 소통과 재확인: 추론한 내용이 맞는지, 변경된 정책이 있는지 기획자, PM, 디자이너에게 끊임없이 질문합니다. 슬랙, 지라 댓글, 회의 등 다양한 채널에서 같은 질문이 반복되고, 답변을 기다리는 시간은 고스란히 개발 속도 저하로 이어집니다.
잘못된 기획으로 인한 재작업: 임의로 해석했거나, 나중에 변경된 기획 때문에 이미 작성한 코드를 뜯어고치는 재작업은 개발자의 사기를 꺾고 프로젝트 일정을 뒤흔드는 주범입니다. 이 재작업 비용은 기획 단계에서 1시간만 더 투자했다면 막을 수 있었을 수십, 수백 시간의 개발 비용으로 돌아옵니다.
그 외 팀원들의 숨겨진 기획 잡무: 디자이너는 기획 의도를 재확인하느라, QA는 기획서에 명시되지 않은 예외 케이스를 확인하느라 각자의 숨겨진 기획 잡무를 처리합니다.

3. 해결책: '문서'가 아닌 '시스템'으로 기획하기

그럼 이 막대한 숨겨진 공장을 어떻게 없앨 수 있을까요? 이번에도 역시, 저는 개발의 역사에서 그 힌트를 찾을 수 있다고 생각합니다. 과거 개발자들이 메모장에 코딩하던 시절엔, 버그 하나를 잡기 위해 수천 줄의 코드를 눈으로 훑어야 했죠. 그랬던 그들이 이제는 똑똑한 IDE(통합개발환경)와 GitHub Copilot 같은 AI 코딩툴을 사용합니다. 단순히 코드를 빨리 치게 된 것이 아니라, 코드를 관리하고, 검증하고, 협업하는 방식 자체가 바뀐 것입니다.

기획도 마찬가지입니다. 이제는 기획자의 맨파워에만 의존하며 “더 꼼꼼하게 기획 문서를 쓰자”고 다짐만 할 것이 아닙니다. 기획이라는 행위 자체를 바라보는 관점을 바꿔야 합니다. 바로, 기획을 흩어지는 ‘문서’가 아닌, 살아있는 '시스템'으로 만드는 것입니다.

첫째, 기획을 '구조화된 데이터'로 전환해야 합니다.

가장 큰 문제는 우리가 기획을 Notion이나 PPT 같은 자유로운 형식의 글과 그림으로 다루는 데 있습니다. 사실 많은 경우에는 아예 종이에 그림을 그려서 소통을 하기도 합니다. 이런 비정형적인 정보는 사람이 만들어 내고 읽기엔 편할지 몰라도, 일관성을 유지하고 변경 이력을 추적하며, 누락된 부분을 찾아내기엔 최악의 방식입니다.

이제는 모든 요구사항, 모든 정책을 하나의 구조화된 데이터로 바라봐야 합니다. 각각의 요구사항이 고유한 ID를 갖고, '상태(status)', '담당자(owner)', '상위 목표(parent goal)'와 같은 속성을 갖는 데이터베이스처럼 말이죠. 이렇게 기획이 구조화되면, 개발자는 더 이상 기획자의 표현을 해석하느라 시간을 낭비할 필요가 없습니다. 명확한 데이터를 기반으로 명확한 결과물을 만들 수 있게 되죠.

둘째, 기획의 '맥락'을 투명하게 동기화해야 합니다.

개발자가 받는 지라 티켓에는 '무엇을(What)' 만들어야 하는지만 남아있는 경우가 많습니다. '왜(Why)' 이 기능이 필요한지, 어떤 논의를 거쳐 이런 결정이 내려졌는지에 대한 맥락은 슬랙 대화나 회의록 어딘가에 흩어져 사라져 버리죠.

따라서 기획 시스템은 결정의 '역사(History)'와 '대화(Conversation)'를 요구사항 데이터에 투명하게 연결해줘야 합니다. 개발자가 하나의 요구사항을 볼 때, 그 결과물뿐만 아니라 그것이 탄생하기까지의 모든 맥락을 함께 볼 수 있어야 합니다. 그래야만 개발자는 수동적인 코드 생산자가 아니라, 맥락을 이해하고 더 나은 대안을 제시하는 능동적인 파트너가 될 수 있습니다.

셋째, 개발자의 워크플로우에 기획을 통합해야 합니다.

가장 이상적인 모습은 개발자가 기획 정보를 찾으러 다니는 것이 아니라, 필요한 기획 정보가 개발자의 작업 환경 안으로 자연스럽게 흘러 들어오는 것입니다. 개발자가 VS Code나 IntelliJ에서 코드를 작성할 때, 관련 기능의 요구사항이나 정책이 마치 코드의 주석처럼 옆에 표시되는 모습을 상상해보세요. 개발자는 더 이상 컨텍스트를 전환하며 시간을 낭비할 필요가 없습니다.

결국, 기획의 생산성을 높이는 것은 기획자 한 명을 위한 것이 아닙니다. 기획을 구조화된 데이터로 만들고, 그 맥락을 투명하게 동기화하며, 팀원의 워크플로우에 통합시키는 것. 이것이 바로 개발자의 숨겨진 기획 잡무를 없애고, 팀 전체의 생산성을 끌어올리는 가장 근본적인 해결책이 될 것입니다. 그리고 이러한 원칙들을 사람의 노력만으로 지키는 것은 거의 불가능하기에, 우리는 자연스럽게 똑똑한 시스템과 도구의 필요성에 도달하게 되는 것이죠.