스타트업의 환경
스타트업은 작은 인원으로 불필요한 절차들을 줄이고 유연화된 의사 결정을 통해, 외부의 요구를 빠르게 반영할 수 있는 장점을 가지고 있습니다. 이를 위해 팀원들간 수평적인 소통을 지향하고 팀원 각각의 상황에 적합한 업무환경을 위해 자율 출퇴근, 코어 타임, 재택 근무와 같은 제도를 운영합니다. 나아가 개개인이 선호하는 다양한 업무 스타일을 존중하고, 형식적인 과정을 최소화해서 지속적으로 성장할 수 있는 문화를 만드는 것이 권장되어야 합니다. 이를 위해서는 서로에게 피해를 주지 않도록, 따를 수 있고 예상할 수 있는 업무 방법이 있어야 합니다. 본 아티클에서는 만족스러운 업무 환경을 위해 팀원들간 공유될 수 있는 최소한의 규칙들과 권장될 수 있는 협업 방법을 작성했습니다.
기획팀, 디자인팀과의 협업
업무 프로세스
팀간 업무 프로세스를 통해, 팀원들은 하나의 기능이 시작부터 완성되기 까지 어떤 단계에 있는지 파악할 수 있습니다. 이는 단계에 따라 업무를 미리 준비하고, 기능이 완료되는 현실적인 시점을 가능한 정확히 예측할 수 있게 합니다. 결국 안정적인 프로덕트를 만들 수 있도록 해주며 팀 전체의 실력과 업무 만족도에도 영향을 줍니다.
기획팀은 사용자들의 피드백과 내부 테스트 등을 통해 새로운 기능이나 보완이 필요한 부분을 정리 후 디자인팀과 개발팀에 간단히 공유합니다. 처음 공유되는 사항인 만큼 해당 비즈니스 로직을 이해하고 필요성에 공감하는 것에 집중합니다. 이후 기획팀에서 구체화된 기능 명세서를 전달하면, 디자인팀은 화면 설계서 작업을 시작하고 개발팀은 high level에서 기존 기능과 충돌이 되는 것은 없는지, 개발이 된다면 어느 부분에 작업이 필요한지 등을 예측하고 실무에 참여할 개발자를 정합니다. 디자인팀의 화면 설계서가 완료되면 기획팀과 개발팀과 함께 공유하고, 각 팀원들이 기능에 대해 이해하고 있는 바를 다시 한 번 확인하며 싱크를 맞춥니다. 개발팀은 기능 명세서와 화면 설계서를 바탕으로 업무를 세분화하고 개발이 완료될 것으로 예상되는 날짜를 각 팀에 공유합니다. 동시에 기획팀은 기능 명세서를 세부적으로 보완을 하고 디자인팀은 구현될 화면 디자인을 진행합니다. 개발팀의 입장에서는 완전히 fix된 기능 명세서와 디자인이 나온 다음에 작업을 시작하는 것이 이상적이지만, 개발이 가능한 부분들 부터 순차적으로 시작하고 개발 중간에 수정이 필요한 부분에도 유연하게 대처합니다. 개발이 완료되면 기획팀, 디자인팀과 함께 리뷰를 하고 피드백을 반영 후 기능을 완성하게 됩니다.
업무의 성격과 크기 등에 따라 업무 프로세스에서 어떤 과정들은 생략되거나 더 추가될 수 있습니다. 다만 이때 실무에 참여하는 기획자, 디자이너, 개발자는 업무가 어느 단계에 있고 내일 또는 다음주에 어떤 것이 진행될지 알 수 있도록 소통이 필요합니다. 태스크 자체가 방대해서 업무 프로세스의 단계가 너무 많아지면, 실제로 진행되는 것 없이 미팅만 반복되는 것처럼 느껴져 피로감을 느끼게 되는 것 같습니다. 각 팀은 내부 상황을 고려해 예상되는 로드를 바탕으로, 작은 태스크로 나누어 여러 번의 테스트를 통해 빠르게 개선할 수 있도록 하는 것을 지향합니다.
팀 미팅
팀원들이 소통하는 방법은 서로의 생각을 적절히 표현할 수 있다면 어느 것이든 좋습니다. Notion에 페이지를 작성하거나 코멘트를 남길 수 있고, Slack에서 공유된 채널이나 DM으로 연락할 수 있고, Google Meet이나 Gather Town에서 화면 공유를 하고 얼굴을 보며 이야기할 수 있습니다. 만약 공유가 필요한 자료가 있으면 미팅 전에 전달을 하고, 질문을 미리 준비하는 것도 도움이 됩니다. 미팅이 예상한 시간보다 길어지는 경우가 종종 있습니다. 설명을 듣는 입장에서는 미팅을 빨리 끝내고 싶을 수 있지만, 설명을 하는 입장에서는 며칠 동안 고민하고 정리한 내용을 압축해서 전달하는 것이기 때문에, 그 시간을 최대한 집중해서 한 번에 이해하려는게 필요합니다. 물론 서로 이해한 내용이나 목적이 달라서 논점이 너무 많아지고 결정하기 어려운 이슈라 결론 없이 이야기가 빙글빙글 돈다면, 미팅을 멈추고 각자 생각을 정리한 뒤 다시 이야기하는 것이 필요합니다.
피곤하고 스트레스가 생기는 미팅에서는 다른 팀원의 실수나 잘 못한 점이 크게 보이기 마련입니다. 어렵지만 한 발짝 물러서서 상황을 다시 객관적으로 판단하고, 지적이 아니라 개선할 수 있는 방법을 제안할 수 있는 태도가 필요한 것 같습니다. 나아가 팀원이 그렇게 생각하는 이유를 유추하려고 노력하고, 상대방이 이해할 수 있는 언어로 의견을 전달하는 것이 필요합니다. 마찰이 생겼을 때 “왜 저런 틀린 생각을 하지”보다는 “우리가 원하는 목적지는 같은데 어느 지점부터 생각이 달리진 거지”를 고민했을 때 실마리가 풀리는 것 같습니다. 그 과정에서 문제점이 왜 발생을 했고, 어떤 점이 팀원을 힘들게 하고, 어떻게 함께 해결할 수 있는지 고민하는 것이 필요합니다. 회사는 일을 하기 위해 모인 곳이고 팀원과의 관계는 업무적인 것이라고 생각하기 때문에 자주 중요한 것을 놓치는 것 같습니다. 나와 팀원의 감정은 중요합니다. 전체 팀의 분위기도 중요합니다. 높은 집중력을 필요로 하는 업무를 하고 밀접한 협업을 하기 때문에 결과에 드러날 수밖에 없습니다. 때문에 메시지가 중요한 것 만큼 전달 방법도 중요합니다.
개발팀의 협업
업무 분배
기능 명세서와 화면 설계서가 나오면 개발팀은 대략적인 타임라인을 생각할 수 있습니다. 보통 이전에 작업이 되었던 것과 관련이 있는 경우에는 해당 작업을 담당했던 개발자가 맡는 것이 일반적입니다. 그렇지 않은 경우에는 비즈니스 로직이나 그에 필요한 기술 스택에 관심이 있는 개발자가 주도해서 맡는 것이 바람직합니다. 만약 기능이 커서 여러 명의 개발자가 협업을 해야하면 업무를 큰 덩어리들로 나누고 서로 연결된 지점에 대해 논의합니다. 데이터가 어떻게 넘어오는지, 어떤 함수들이 공유되어야 하는지 등을 정합니다. 전체적인 설계와 세부 부분에 대한 스펙이 정리가 되면, 각 단계에 필요한 시간과 완료될 수 있는 일정을 조율하고 기획팀과 디자인팀에도 공유를 합니다.
데일리 미팅
개발자 스스로 고민하고 해결 방법을 찾으려 노력하는 것은 무엇보다 중요하지만, 혼자 풀기 어려운 경우에는 스스럼없이 다른 개발팀원의 도움을 받아 함께 문제를 해결할 수 있는 문화가 필수적입니다. 이를 위해 데일리 미팅에서 모든 개발팀원이 참여해 각자 진행 중인 업무를 간단히 공유합니다. 기술적으로 논의가 깊게 필요한 이슈는 간단하게라도 지금 겪고 있는 문제가 무엇이고, 이런 방법들을 찾아봤지만 해결할 수 없었다는 점을 미리 공유합니다. 다른 개발팀원들은 미리 이슈를 인지한 상태로 미팅에 참여해서 논의가 효율적으로 이루어질 수 있도록 합니다. 개발팀원이 많아질 수록 데일리 미팅이 길어지기 때문에 각자 어떤 업무를 했는지 요약해서 전달하고, 개발팀에 어떤 영향을 줄 것인지를 중점으로 공유합니다. 새로운 라이브러리를 설치했다면 다른 개발자가 현재 작업 중인 기능에 관련이 있는지 확인 후 어떻게 반영이 필요한지 설명하는 것이 필요합니다.
코드 리뷰
코드 리뷰는 기능 개발 못지않게 개발팀의 가장 중요한 업무이자 소통 방법입니다. 코드 레벨에서 개발팀원이 작업한 내용을 이해하고 피드백을 통해 기술적으로 성장할 수 있도록 합니다. 이를 위해 리뷰어가 일방적으로 작성자에게 수정을 요구하는 것이 아니라, 다른 방법을 제안하는 이유를 작성해 작성자와 리뷰어가 기술적으로 논의할 수 있는 기회가 되도록 합니다. 코드 리뷰에는 작업된 기능과 관련된 팀원들이 최대한 많이 참여할 수 있도록 합니다. GitHub PR을 올릴 때 작성자는 개발 내역과 그렇게 구현한 이유, 테스트 방법 등을 리뷰어가 이해하기 쉽도록 설명합니다. 때문에 코드 작성 전에 태스크를 나누는 단계에서 PR이 너무 커지지 않고 이해하기 용이한 크기로 만드는 것이 중요합니다. 리뷰어는 코멘트를 남길 때 수정이 필요한 이유를 작성자에게 설득시킬 수 있어야 합니다. 그것이 단순한 지식의 부족으로 인한 것이면 적합한 함수나 방법을 알려주고, 설계 방법에 문제가 발생할 것으로 판단되는 것이면 다른 방법을 제안하고, 코딩 스타일이 맞지 않는 것이면 개발팀의 컨벤션을 상기시켜주는 것이 필요합니다. 좋은 코드를 만드는 것이 공통의 목적이기 때문에 개발자들은 ‘좋은’에 대해 코드로 대화합니다.
마치며
개발팀은 기획팀과 디자인팀과 밀접하게 협업할 수 있어야 합니다. 이를 위해 업무가 어떻게 진행되고 있는지 팀원들에게 공유되어야 합니다. 또한 각 팀이 정확한 정보를 효율적인 방법으로 전달하고, 서로를 배려한 소통이 바탕이 되어야 합니다. 능력있는 개발팀은 개발자 개개인의 성장과 넓고 깊은 소통을 할 수 있는 개발 문화 두 가지로 만들어진다고 생각합니다. 이를 위해 개발 전 단계에서 업무를 팀에 맞게 분배하고, 개발 중 데일리 미팅에서 과정을 공유하고, 개발 마지막 단계에서 코드 리뷰를 통해 함께 발전합니다.
스타트업의 상황과 각 팀원들의 성향 등에 따라 협업의 방법과 우선해야 하는 지향점들이 달라질 수 있을 것입니다. 그럼에도 모든 팀원이 언제나 공유하고 있을, 함께 성장과 성공을 목표로 한다는 점을 바탕으로 한다면 팀에 맞는 방법을 찾을 수 있을 것입니다.
