기획자가 없는 개발

내가 소속한 팀은 2024년에 신규로 생성된 팀이다. 팀은 현재 7명으로 구성되어있는데 이중 개발을 담당하는 사람은 팀장을 제외하여 총 2명이다. 1년차 이하 신입개발자 2명이 각각 프론트엔드와 백엔드를 담당하고 있다. 나는 우리팀에서 백엔드 개발을 담당하고 있다. 팀장의 포지션운 도메인에 더 가깝다. 보통의 개발 요구사항들은 팀장을 통해서 전달되는데 주로 UI 예시로 PPT로 전달받는다. 기능에 대한 설명을 슬라이드 노트에 이런 저런 설명을 적거나 구두로 전달해주는 편이다. 전달받는 기획서로는 개발을 하기에는 디테일이 아쉬운 부분이 많은데 팀장은 개발이 아니라 운영을 주로 맡고 있고 사업을 비롯한 여러 업무를 관장해야해서 그럴 여력이 부족하다. 우리팀은 따로 기획자가 없기 때문에 다소 “애자일”하게 프론트, 백엔드 개발자가 그 요구사항을 함께 듣고 나서 요구사항을 분석하고 화면, 기능, 로직 등을 구현해 나가는 방식으로 개발을 하는 편이다.

나는 의도적으로 그러는 것은 아니지만 팀장의 PPT에 설명이 부족한 것이 있거나, 도메인 엔티티의 라이크 사이클이 제대로 설명되지 않거나, 워크플로우나 유즈케이스가 끊기는 등의 설계적 문제가 있을 때마다 팀장에게 적극적으로 피드백을 하는 편이다. 개발하기 전에 요구사항을 최대한 구체화하는 편이 설계를 하기 좋고 좋은 설계로 좋은 코드를 작성할 수 있다고 나는 생각하기 때문이다. 동료 프론트 개발자는 다소 수동적인데, 함께 요구사항에 대해 전달받게 되는 자리에서도 좀처럼 입을 열지 않는다. 뒤늦게 프론트 개발자는 팀장이나 나에게 회의에서 결정한 사항에 대해서 다시 물어 보는 뒷북을 치는 편이 많았다.

그래서 나는 입사이레 프론트 개발자와 협업에서 개발 과제에 대한 동기화가 이뤄지지 않아서 답답함을 느껴왔다. 그러다 보니 조별과제 팀장처럼 혼자 이런 저런 일을 하며 개발 업무를 끌고 가고 있었다.

프론트 개발자는 요구사항이 잘 정리되고 정책이 잘 정의된 상태에서는 개발을 잘하시는 것 같았다. 그러나 문제는 우리팀에는 잘 정리된 기획서를 전달해줄 기획자가 없다는 사실이다. 외부 요구사항은 구체적인 내용 없이 팀장에게 전달되는 경우가 많았다. 따라서 구체적인 내용은 팀장, 나, 프론트엔드 개발자 이렇게 셋이서 정해야할 경우가 많았다. 프론트 개발자는 의견을 내는 일, 무엇을 판단하고 결정을 짓는 일, 선택한 것에 책임을 지는 일에 두려움을 느끼는 듯 했다. 나는 그런 프론트 개발자를 이해하지 못하고 프론트 개발자가 의견을 내거나 결정을 해줘야할 사안을 내게 미루고 있다고 느꼈던 것 같다.

내게 프론트 개발자에 대한 부정적인 감정이 쌓였고 지치기 시작했다. 그러다가 얼마전 회의가 끝나고나서 프론트 개발자에게 다소 감정적으로 다음과 같은 의사를 전달했다.

• 앞으로 팀장이나 다른 팀에서 전달받는 요구사항에 관련한 문서를 절저하게 읽고 잘못된 것이 있으면 빠르고 적극적으로 피드백을 해달라.
• 프론트 개발을 함에 있어서 필요한 API에 대한 상의는 백엔드 개발자가 API를 만드는 시점보다 먼저 요청하셨으면 한다. 먼저 상의해야할 것이 있으면 일찍 요청해달라.
• 우리 팀에는 기획자가 없으니 각 개발자가 영역을 가리지 않고 요구사항 회의에 적극인 자세로 참여해서 기획과 설계를 맡았으면 한다.

나는 그 얘기를 하면서도 마음이 편하지 않았다. 내 말을 듣는 프론트 개발자가 목석같이 반응을 했기 때문이다.

그 얘기를 하고 시간이 지나 다음 주가 되었고 프론트 개발자가 먼저 얘기를 꺼내기에 이런 저런 얘기를 하면서 그날에 대한 얘기가 나왔고 나는 내가 지나치게 감정적으로 얘기한 것을 사과했다. 그리고 거기서 프론트 개발자에게 알게된 사실이 있었다. 프론트 개발자는 회의에서 나와 팀장이 상의하고 결정한 내용의 반절은 이해하지 못하는 것 같았다. 그러다보니 회의에서 말수가 없었던 것이다. 그리고 이해를 못한 프론트 개발자는 우선 시안대로 UI 퍼블리싱을 먼저 한 후 팀장에게 이해하지 못한 부분을 물어보면서 요구사항과 개발과제를 이해하는 것 같았다. 프론트 개발자는 그래서 그렇게 퍼블리싱을 그리고 요구사항을 좀 이해한 후에야 어떤 API가 필요하고 어떤 상의가 필요한지 조금 알게 되는 듯 했다.

그에 비해서 나는 상대적으로 요구사항에 대한 이해가 빨라서 프론트 개발자가 일부러 일을 미루는 것이라고 생각한 것 같다. 이번 기회에 어느 정도 개인의 성향 차이에 대해서 이해하게 된 것 같아서 조금 다행이었다. 하지만 중요한 것은 앞으로 이런 일이 생겼을 때는 어떻게 할 것인지에 대해서다. 나는 나의 업무적인 속도를 조금 느슨하게 가져가서 프론트 개발자의 갭을 줄여야 겠다고 생각했다.

애자일 방식은 각 분야의 팀원이 모두 함께 참여하여 고객지향적인 제품을 만들어 낸다. 애자일의 중요한 속성은 속도, 전원 참여 같은 것들이고 나는 지금껏 전원이 업무 영역을 초월하며 빠른 템포로 역할을 수행하는 것만이 이상적이라고 생각했던 것 같다. 애자일 방식의 반대는 워터폴 방식인데 문뜩 완전한 애자일 방식도 없고 완전한 워터폴 방식도 없다는 것을 깨닫게 되었다. 그보다는 현실적으로 어떤 타입의 업무방식이 현재 팀원과 팀의 업무 포텐셜을 높게 가져갈 수 있는지가 더 중요한 것 같다고 생각했다. 어떤 방식이 나에게는 맞을지 몰라도 팀원에게 맞지 않는다면 그것은 팀워크가 아니라고 생각이 들었다. 프론트 개발자는 앞서 나와 얘기하며 이렇게 제안했다.

“(이해가 될 때까지) 어느 정도 퍼플리싱이 끝난 후에 API 등 업무 전반에 대해서 상의하면 좋겠어요.”

팀원이 그렇게 해야 퍼포먼스를 잘 발휘할 수 있다고 하니 실현 불가능한 이상은 내려놓고 실현가능한 현실에 좀더 집중해야겠다고 생각했다.

내가 그렇게 프론트 개발자의 방식을 받아들인 후에 조금 문제가 될 수 있는 부분이 개발일정에 대한 것이다. 아무래도 프론트 개발자가 원하는 방식은 개발일정에 딜레이가 발생할 수밖에 없다. 또한 이번에 내가 다소 감정적으로 프론트 개발자에게 얘기했던 사건은 다음주부터 UAT를 했어야 했기에 단 일주일만에 개발이 완료되어야 했던 주변 상황과 연관되어 있었다. 앞으로는 프론트 개발자가 퍼블리싱을 하고 요구사항에 대해 조금 이해를 하는 시간을 감안해서 팀장이 이런 일정이 가능한지 문의하는 것에 대해 잘 답변해야겠다고 생각했다. 그러니까 프론트 개발자에게 그게 가능할지 먼저 물어봐야겠다.

한기용님의 영상을 요즘 보고 있는데 깨닫는 바가 많다. 좋은 영향력을 키우고 장기적인 관점에서 복리가 되는 행동을 선택하고 매사에 여유를 가질 것. 요즘 무리한 일정을 소화하느라 스트레스풀해 있던 나 자신을 돌아 보게 하는 좋은 얘기였다.

그래서 나는 초점을 “나와 잘 맞지 않는 성향의 프론트 개발자”에 대해서가 아니라 “어떻게 하면 이런 조건에서 회사에서 주어지는 과제를 잘 수행할 수 있을지”에 맞춰야겠다고 생각했다. 이에 더불어 내가 일을 잘할 수 있는 환경에 대해서 고민했다.