1. 들어가기 앞서
만약 내가 백엔드 팀 리더가 된다면, 우리 팀이 나아가야 할 방향과 핵심 가치를 어떻게 설정하고 공유할까 고민해보았다. 팀을 더 단단하고 효율적으로 만들기 위해, 그리고 궁극적으로 '함께 자라기'라는 목표를 달성하기 위해 다음과 같은 운영 방향을 구상해보았다. 이 방향은 크게 체계적인 프로세스, 타협 없는 개발 문화, 그리고 서로를 지지하는 팀 문화라는 세 가지 축을 중심으로 한다.
2. 팀 운영방향
2.1. 계획과 절차를 통해 예측 가능하고 효율적인 업무 환경을 만들기
2.1.1. 업무 관리
모든 업무의 시작과 끝은 Jira를 통해 투명하게 관리되어야 한다고 생각한다. 팀 리더는 스크럼 마스터로서, 계획된 에픽과 태스크뿐만 아니라 예상치 못한 Ad hoc 작업까지 모두 기록하여 우리가 무엇을 하고 있는지 명확히 파악할 수 있도록 도와야 한다. 리소스 산정은 스토리 포인트를 기반으로 좀 더 현실적으로 접근하는 것이 좋다고 본다.
단순히 개발 시간만을 고려하는 것이 아니라, 플래닝 포커와 같은 활동을 통해 에픽 담당자와 리더가 충분히 소통하며 컨텍스트 스위칭, 미팅 참여, 커뮤니케이션 등 실제 업무 환경에서 발생하는 숨겨진 비용까지 고려하여 일정을 계획해야 한다. (예를 들어, 하루 6포인트와 같이 현실적인 기준을 설정할 수 있다.)
2.1.2. 팀 미팅
소통은 우리 팀의 핵심 동력이다. 때로는 비효율적으로 느껴질 수 있겠지만, 우리는 더 자주 만나고 이야기하며 서로의 생각과 작업 방식을 맞춰나가야 한다.
매주 진행되는 위클리 미팅에서는 지난주의 성과와 이번 주의 계획을 공유하고, 팀 전체에 알려야 할 공지사항을 전달한다. 또한, 기술적인 도전 과제나 해결 사례, 개선 아이디어 등 깊이 있는 논의가 필요한 주제들을 다루어야 한다. 이러한 논의가 생산적으로 이루어지기 위해, 참여자들은 미리 관련 내용을 문서로 정리하여 공유하는 노력이 필요하다.
매일 아침 짧게 진행되는 데일리 스탠드업 미팅은 어제 완료한 일, 오늘 집중할 작업, 그리고 혹시 발생한 어려움(Blocker)을 신속하게 공유하고 함께 해결책을 찾는 자리가 되어야 한다.
2.1.3. DX 개선
개발자 경험(DX) 개선에도 힘써야 한다. 계정 관리, 결제 이슈 대응, 권한 설정 등 개인에게 의존된 업무들을 없애고 시스템적으로 최소화하여, 우리 팀원들이 오롯이 가치 있는 개발 활동에 집중할 수 있는 환경을 만들어야 한다. One Password나 Cursor와 같은 생산성 도구를 적극적으로 탐색하고 도입하여 일의 효율을 높여야 한다.
또한, 개인적인 DM을 통한 업무 요청이나 논의보다는, 팀 전체가 공유하는 채널에서의 소통을 기본 원칙으로 삼아 정보의 투명성을 높이고 누락되는 내용이 없도록 해야 한다.
2.1.4. 개발 프로세스 개선
개발 프로세스의 견고함은 품질과 직결된다. 따라서 모든 주요 기능 개발(에픽)은 시작하기 전에 반드시 설계 리뷰를 거치도록 해야 한다. 이는 단순히 절차를 위한 절차가 아니라, 개발 초기 단계에서 잠재적인 문제를 발견하고 최적의 방향을 함께 고민하기 위한 필수적인 과정이다.
코드 리뷰 없이는 메인 브랜치로 코드가 통합될 수 없도록 브랜치 전략을 강화하고, 예기치 못한 긴급 상황 발생 시에는 명확하게 정의된 핫픽스 프로세스를 준수하여 서비스 안정성을 최우선으로 확보해야 한다.
2.1.5. 장애 대응
예상치 못한 장애는 언제든 발생할 수 있다. 시스템 사용에 심각한 영향을 미치는 장애가 발생하면, 가능한 모든 팀원이 힘을 합쳐 신속하게 대응하는 것을 원칙으로 한다. 모든 장애는 상세한 리포트 작성을 통해 철저히 원인을 분석하고, 동일한 문제가 반복되지 않도록 구체적인 개선 방안을 마련하고 실행해야 한다. 장기적으로는 주 단위 등으로 장애 대응 책임자를 지정하여, 더욱 체계적이고 예측 가능한 대응 시스템을 구축하는 것을 목표로 한다.
2.1.6. 기술부채 및 백로그 관리
마지막으로, 기술 부채나 백로그는 더 이상 방치되어서는 안 된다. 발견된 기술 부채는 명확하게 문서화하여 관리하고, 그것이 비즈니스에 미치는 리스크와 영향도를 객관적으로 평가하여 우선순위를 결정해야 한다. 주기적으로 개발 리소스의 일정 부분(예: 20%)을 이러한 기술 부채를 해소하는 데 사용할 수 있도록, 다른 팀 및 리더들과 적극적으로 소통하고 설득해나가야 한다.
2.2. 개발 과정에서 타협하지 않는 퀄리티를 추구
2.2.1. 설계 리뷰
품질은 설계에서 시작된다. 우리는 엄격하면서도 협력적인 설계 리뷰 프로세스를 운영해야 한다. 개발자는 요구사항을 깊이 이해하고, 이를 바탕으로 자신이 생각하는 최적의 설계 방향을 담은 초안 문서를 작성해야 한다.
설계 문서 초안은 완벽할 필요는 없다. 중요한 것은 리뷰 미팅에서 동료들에게 자신의 아이디어를 명확히 설명하고 함께 논의할 수 있는 수준이면 충분하다. 리뷰 과정에서 설계 방향이 크게 바뀔 수도 있다는 열린 마음을 갖는 것이 중요하다. 설계 리뷰는 최소 1명 이상의 지정된 리뷰어의 승인을 받아야 하며, 다른 팀원 누구나 언제든 참여하여 의견을 제시할 수 있다.
리뷰를 위해서는 요구사항에 대한 명확한 정리(핵심 용어 정의, 사용자 관점의 유즈케이스, 시스템이 유지해야 할 불변 조건 등)와 이를 해결하기 위한 고수준의 설계(아키텍처 도식, 다양한 다이어그램, 가능하다면 바운디드 컨텍스트 정의 등)가 문서에 담겨 있어야 한다.
리뷰 과정에서 나온 모든 피드백과 코멘트는 삭제하지 않고 기록으로 남겨, 결정 과정의 투명성을 확보하고 미래에 참고할 수 있도록 해야 한다. 물론, 이러한 리뷰 과정에는 시간이 소요된다. 어느 정도의 시간은 리소스 계획에 반영되겠지만, 리뷰가 끝없이 길어진다고 해서 프로젝트 일정을 무한정 늘릴 수는 없다. 때로는 일정 준수를 위해 빠른 결정과 집중이 요구될 수도 있다.
2.2.2. 기술적 논의
기술적인 논의나 방향 결정이 필요할 때, 우리의 판단 기준은 오직 '기술적 근거'여야 한다. 각자의 주장을 뒷받침할 수 있는 명확하고 논리적인 근거를 제시해야 하며, 더 타당하고 견고한 논리를 가진 의견이 채택되어야 한다. 목소리의 크기나 직책이 아닌, 기술적 합리성이 의사결정의 핵심이다.
격렬한 토론 끝에 결정이 내려졌다면, 우리는 'disagree and commit'의 원칙을 따라야 한다. 개인적인 의견과 최종 결정이 다르더라도, 일단 결정된 사항에 대해서는 팀 전체가 한 방향으로 나아가기 위해 최선을 다해 헌신하고 협력해야 한다. 물론, 최종적인 판단의 책임은 팀 리더에게 있다.
2.2.3. 성장: 의도적인 수련
기술적 성장은 저절로 이루어지지 않는다. 우리는 '의도적인 수련'을 통해 끊임없이 역량을 갈고 닦아야 한다. CQRS, 효과적인 모니터링 시스템 구축, 스프링과 코틀린의 깊이 있는 활용, 도메인 주도 설계(DDD), 이벤트 기반 아키텍처(EDA), 캐시 무효화 전략, GraphQL Federation 등 우리가 지향하는 기술 스택과 아키텍처에 대한 꾸준한 학습과 탐구가 필요하다. 이러한 학습은 책상 앞에서만 이루어지는 것이 아니다. 실제 업무 과제를 수행하고, 예상치 못한 장애나 이슈를 해결하는 과정에서 마주치는 기술적 도전들을 깊이 파고들어 내 것으로 만들고, 그 과정에서 얻은 지식과 경험, 때로는 실패 사례까지도 팀 내에 적극적으로 공유하는 문화가 중요하다. 이를 위해 책 스터디, 온라인 강의 공동 수강, 외부 컨퍼런스나 밋업 참여 및 후기 공유, 기술 블로그 작성, 팀 채널을 통한 정보 전파 등 다양한 방법을 시도하고 장려해야 한다. 팀 차원에서도 개인의 성장을 위한 다양한 자극과 기회를 제공할 것이며, 각자 스스로 성장 계획을 세우고 꾸준히 실천해나가기를 기대한다.
2.3. 팀 문화 만들어가기
2.3.1. 책임감과 주도성
우리 팀에서는 수동적인 자세를 지양한다. 동료의 일이 곧 나의 일이라는 생각으로 서로를 적극적으로 돕고 백업하며, 맡은 일에 대해서는 책임감을 가지고 주도적으로 해결해나가는 문화를 만들어가야 한다. 팀의 성공은 곧 나의 성공이라는 '원팀(One Team)' 정신을 바탕으로 협력해야 한다. 누군가 어려움을 겪고 있다면 먼저 다가가 손을 내밀고, 특히 자신이 기여한 부분과 관련된 문제라면 더욱 적극적으로 지원하는 자세가 필요하다.
2.3.2. 성장과 피드백
성장은 피드백을 통해 이루어진다. 우리는 서로에게 솔직하고 건설적인 피드백을 편안하게 주고받을 수 있는 문화를 정착시켜야 한다. 가능하다면 회사 전체 시스템을 활용하겠지만, 여의치 않다면 팀 내부적으로라도 분기별 동료 리뷰(리더 포함)와 같은 제도를 마련하여 서로의 강점과 개선점을 공유하고 성장을 지원해야 한다.
이를 위한 구체적인 방식(템플릿 등)은 함께 만들어가야 한다. 기술적으로 새롭게 배운 점, 문제를 해결하며 겪었던 어려움과 극복 과정(삽질기), 프로젝트를 진행하며 느꼈던 아쉬움 등을 스스럼없이 공유하고, 이를 통해 팀 전체가 함께 배우고 발전하는 기회를 만들어야 한다.
정기적인 회고를 통해 잘한 점은 서로 칭찬하고 격려하며, 개선이 필요한 부분에 대해서는 구체적인 실행 계획(Action Item)을 도출하고, 이것이 실제로 실행되고 있는지 꾸준히 추적하며 변화를 만들어가야 한다.
2.3.3. 신뢰와 존중
신뢰는 모든 협업의 기반이다. 우리는 서로를 존중하는 태도를 바탕으로 솔직하게 소통하는 것을 무엇보다 중요하게 생각한다. 동료 앞에서 할 수 없는 말은 뒤에서도 하지 않는 건강한 문화를 만들어가야 한다. 업무 과정에서 의견 충돌이나 갈등은 자연스러운 일이며, 이를 피하기보다는 건설적으로 논의하고 해결해나가는 과정을 통해 더 단단한 관계를 구축할 수 있다. 업무 관련 논의는 가능한 모든 팀원이 접근할 수 있는 공개 채널에서 진행하여 정보의 투명성을 확보하고 오해의 소지를 줄여야 한다.
또한, 동료가 어떤 생각과 가치관(멘탈 모델)을 가지고 세상을 바라보는지 이해하려고 노력하는 것이 중요하다. 각자의 배경과 경험이 다르기에 세상을 이해하는 방식 또한 다를 수 있음을 인정하고, 그 다름을 존중하며 공통의 목표를 향해 나아가는 방법을 찾아야 한다. 결국, 더 자주 이야기하고, 서로의 입장에서 생각해보려 노력하며, 작은 약속들을 지켜나가는 과정을 통해 깊은 신뢰를 쌓아가는 것이 우리 팀 문화의 핵심이 되어야 한다.
결국, 모든 결정과 관계의 중심에는 사람이 있다. 아무리 논리적이고 객관적인 자료를 제시한다 해도, 상대방의 마음을 얻지 못하면 진정한 의미의 설득은 어렵다. 의사결정 과정에는 우리가 인지하지 못하는 감정적이고 직관적인 요소들이 큰 영향을 미친다. 따라서 누군가를 설득하고 함께 나아가기 위해서는, 단순히 논리만 내세울 것이 아니라 자주 만나 관계를 형성하고 신뢰를 쌓으며, 그 사람이 무엇을 중요하게 생각하고 어떤 방식으로 소통하는 것을 선호하는지 깊이 이해하려는 노력에서부터 시작해야 한다.
3. 함께 자라기 라는 하나의 목표
우리가 꿈꾸는 이상적인 팀의 모습이 하루아침에 이루어지지는 않을 것이다. 중요한 것은 완벽한 결과가 아니라, '함께 자라기'라는 공동의 목표를 향해 나아가는 과정 그 자체이다. 우리는 한 팀으로서 서로에게 배우고, 부족한 부분은 채워주며, 끊임없이 더 나은 방향을 함께 고민하고 개선해나가야 한다.
이 운영 방향이 우리 백엔드 팀이 기술적으로 탁월함을 추구하는 동시에, 서로에게 긍정적인 에너지를 불어넣으며 함께 성장하는 건강하고 생산적인 공동체로 발전하는 데 든든한 기반이 되기를 바란다. 이 여정에 팀원 모두의 적극적인 참여와 헌신적인 기여를 기대하며, 함께 멋진 팀을 만들어갈 수 있기를 소망한다.