<div id="readability-page-1" class="page"><section data-astro-cid-4eu74nwj=""> 2025년 8월 회사에 합류했다.
합류 후 10월까지는 다른 프로덕트의 TF 업무를 진행했고 2025년 10월부터 본격적으로 AstraGo 팀을 맡기 시작했다.
그로부터 약 1년이 지났다.
지난 1년 동안 AstraGo는 1.0에서 2.0으로 전환했고 팀은 약 20명 규모로 성장했다. 제품과 조직 모두 크게 달라졌지만 돌이켜보면 내가 가장 많은 시간과 에너지를 쏟은 대상은 기능이나 기술만은 아니었다.
가장 바꾸고 싶었던 것은 팀이 일하는 방식이었다.
<h2 id="서로-다른-맥락을-하나의-제품으로">서로 다른 맥락을 하나의 제품으로</h2>
내가 팀을 맡았을 당시에는 1.0이 운영되고 있었다.
1.0은 실제 고객에게 제공되는 제품이었지만 개발 방식에는 여러 한계가 있었다. 개발자들은 각자의 영역에서 열심히 일했지만 서로 무엇을 왜 만드는지는 충분히 공유되지 않았다.
코드 리뷰와 공통된 개발 기준도 부족했고 중요한 정보와 의사결정은 일부 사람의 기억과 경험에 기대는 경우가 많았다.
그렇다고 단순히 프로세스가 부족한 것이 문제라고 생각하지는 않는다.
나는 모든 업무를 규칙과 절차로 통제해야 한다고 생각하지 않는다. 불필요한 프로세스는 판단을 느리게 하고 실제 일보다 형식을 앞세우게 만들기도 한다.
문제의 핵심은 팀이 같은 맥락과 방향을 공유하지 못한다는 점이었다.
2.0 개발은 내가 팀을 맡기 전부터 정해져 있었다. 하지만 진행 상황을 살펴보니 여러 개발자가 서로 다른 전제와 맥락 위에서 저마다의 2.0을 만들고 있었다.
모두가 열심히 개발했지만 결과가 하나의 제품으로 모이지 못한 채 점점 다른 방향으로 가고 있었다.
결국 기존의 2.0 개발을 초기화하고 소규모 TF를 새로 구성했다.
먼저 제품의 핵심 구조와 개발 기준을 맞추고 기존 1.0 개발자들은 이후 점진적으로 합류하도록 했다. 이미 만들어진 결과물을 되돌리기란 쉽지 않은 결정이었지만 당시에는 더 많은 코드를 쌓는 것보다 모두가 같은 제품을 만들고 있다는 확신을 회복하는 일이 중요했다.
짧은 기간 동안 1.0 운영과 2.0 개발을 함께 진행해야 했고 팀원들의 많은 노력이 필요했다.
그 결과 약 4개월 뒤인 2026년 2월 2.0을 출시했고 기존 고객 환경의 업데이트와 마이그레이션도 함께 진행했다.
이후에는 2.0을 기반으로 제품의 기능과 안정성, 운영 경험을 계속 확장하고 개선하고 있다.
<h2 id="제품보다-더-바꾸고-싶었던-것">제품보다 더 바꾸고 싶었던 것</h2>
2.0 출시는 중요한 목표였지만 내가 더 근본적으로 바꾸고 싶었던 것은 팀 문화와 개발 문화였다.
합류 당시 팀은 전반적으로 경직되어 있었고 구성원 사이의 소통도 충분하지 않았다. 회사의 공식 메신저인 Slack은 거의 쓰이지 않았고 업무 진행 상황과 의사결정은 개인적인 대화나 구두 전달에 기대는 경우가 많았다.
태스크를 관리하는 도구도 실제 업무와 연결되어 있지 않았고 문서는 잘 작성되지도 않았고 작성된 뒤로는 갱신되지 않았다.
결과적으로 정보는 일부 사람에게 집중됐다. 누가 무엇을 아는지에 따라 업무의 속도와 품질이 달라졌고 맥락이 공유되지 않으면서 오해와 불신도 생겼다.
그래서 가장 먼저 소통 방식을 바꾸기 시작했다.
Slack을 단순한 메신저가 아니라 팀이 일하는 공간으로 만들고자 했다.
업무를 시작할 때는 목적과 계획을 공유하고 진행 중에는 문제와 변경 사항을 알리며 완료한 뒤에는 결과를 남기도록 꾸준히 유도했다.
잘된 일만이 아니라 막혀 있는 일과 실패한 시도도 가능한 범위에서 드러내도록 했다.
여기서 투명성은 감시가 아니다. 누가 일하고 있는지 확인하려는 것이 아니라, 서로의 상황을 이해하고 필요할 때 도우며 같은 실수를 되풀이하지 않으려는 것이다.
나 역시 예외가 되어서는 안 된다고 생각했다.
팀원에게 투명하게 일하기를 요구하려면 나부터 판단과 고민, 진행 상황을 공유해야 했다. 모두가 과정을 드러낼 때 신뢰는 개인적인 친분이 아니라 업무의 구조 위에 선다고 생각했다.
<h2 id="같은-방향을-위해-함께-판단할-기준을-만들다">같은 방향을 위해 함께 판단할 기준을 만들다</h2>
지난 1년 동안 Slack, Linear, Notion, 코드 리뷰, 페어 시스템과 DRI 등 여러 방식을 도입하고 운영했다.
겉으로 보면 새로운 도구와 프로세스를 계속 추가한 것처럼 보일지도 모른다.
하지만 규칙을 잔뜩 늘리려던 것은 아니었다.
팀을 운영하면서 점점 분명해진 것이 있다. 같은 방향으로 일하려면 함께 판단할 기준이 필요하다는 점이다.
무엇을 먼저 할지, 언제 공유할지, 어디까지 되어야 업무가 끝난 것인지, 어떤 결정은 혼자 내리고 어떤 결정은 함께 논의할지를 가르는 기준이다.
같은 방향으로 일한다고 해서 모두가 같은 답을 내야 하는 것은 아니다.
각자의 전문성과 경험에 따라 서로 다른 의견을 낼 수 있어야 한다. 다만 그 판단들이 공통된 제품 목표에서 완전히 벗어나지 않도록 출발점이 되는 맥락과 기준만큼은 공유되어야 한다.
기준이 없으면 각자는 자신의 경험에 따라 최선을 다한다.
하지만 서로 다른 기준으로 최선을 다하면 그 결과가 하나의 제품과 팀으로 모이지 않는다. 초기 2.0에서 겪은 문제도 여기에 가까웠다.
그래서 원칙은 방향을 제시하고 기준은 판단을 돕게 하되 규칙은 꼭 필요한 최소한으로만 두려고 했다.
모든 상황을 통제하는 규칙보다 구성원이 스스로 더 나은 결정을 내릴 수 있는 기준을 만들고 싶었다.
<h2 id="업무와-경험을-팀의-자산으로-옮기다">업무와 경험을 팀의 자산으로 옮기다</h2>
CTO 유진님의 추천으로 태스크 관리 도구인 Linear를 적극 사용했다.
당시에는 많은 업무가 사람의 기억과 대화 속에 있었다. 누군가 요청을 기억하면 그 일이 진행됐고 급한 일이 생기면 우선순위가 바뀌었다. 진행 상황을 확인하려면 담당자에게 직접 물어봐야 했다.
팀이 작을 때는 개인의 책임감과 기억력으로 어느 정도 유지할 수 있다.
하지만 팀과 프로젝트가 늘어나면 업무를 사람의 머릿속에만 둘 수 없다.
Linear에 티켓을 만드는 것은 할 일을 적어 두는 데서 그치지 않았다. 대화 속 요청을 팀의 공식적인 약속으로 바꾸고, 업무의 목적과 범위, 담당자와 우선순위를 모두가 같은 공간에서 확인하게 하는 일이었다.
업무가 멈췄을 때도 그 원인을 이전보다 구체적으로 살필 수 있게 됐다. 담당자의 실행 문제인지, 요구사항이 불명확한 것인지, 다른 업무를 기다리는 것인지, 리더의 결정이 병목이 된 것인지 구분할 수 있었다.
Linear는 사람을 관리하는 도구라기보다 업무의 상태와 약속을 관리하는 도구였다.
Notion은 팀의 경험을 축적하는 공간으로 사용했다.
제품 구조와 개발 방법뿐 아니라 주요 의사결정, 검토했던 선택지, 프로젝트에서 얻은 경험과 실패한 시도를 남기려고 했다.
결론만 기록하면 같은 논쟁이 반복된다. 어떤 제약 속에서 무엇을 선택했는지가 남아 있어야 상황이 달라졌을 때 기존 결정을 유지할지 다시 검토할지 판단할 수 있다.
Linear가 현재와 앞으로 할 일을 관리한다면 Notion은 지나온 경험을 팀의 기억으로 남기는 역할을 했다.
물론 도구를 도입했다고 모든 것이 해결된 것은 아니다.
티켓이 실제 진행 상황을 따라가지 못하거나 문서가 오래돼 다시 믿기 어려운 경우도 있다. 도구를 쓰는 것과 도구로 일하는 것은 별개의 문제였다.
그래서 지금도 실제 업무와 도구의 상태를 일치시키기 위한 기준을 계속 개선하고 있다.
<h2 id="약-20명의-목적-조직으로">약 20명의 목적 조직으로</h2>
지난 1년 동안 AstraGo 팀은 약 20명 규모로 성장했다.
하지만 사람이 늘었다는 것만으로 팀이 성장했다고 생각하지는 않는다.
인원이 많아지면 할 수 있는 일도 늘지만 소통해야 하는 관계와 업무 간 의존성도 함께 늘어난다. 공통된 목표와 기준이 없으면 오히려 더 느려진다.
우리가 만들고자 한 것은 여러 직군이 같은 조직도 아래 모여 있는 팀이 아니라 AstraGo라는 하나의 제품과 목적을 중심으로 움직이는 목적 조직이었다.
그래서 내부 페어 시스템을 운영하기 시작했다.
여기서 페어는 두 사람이 같은 화면에서 코드를 짜는 전통적인 페어 프로그래밍만 뜻하지 않는다.
기능 개발, 설계, 인프라 구축, 고객 대응과 프로젝트 운영 등 다양한 업무에서 최소 두 사람이 핵심 맥락을 공유하고 중요한 판단을 함께 검증하는 방식이다.
한 사람만 모든 맥락을 아는 구조는 장기적으로 큰 비용이 든다. 담당자가 자리를 비우면 업무가 멈추고 경험은 개인에게만 남으며 잘못된 방향을 뒤늦게 발견한다.
페어로 일하면 리뷰 시점이 앞당겨지고 경험과 판단이 팀에 퍼진다. 일을 중복해서 하려는 방식이 아니다.
동시에 주요 업무와 프로젝트에는 DRI를 두었다.
페어로 함께 일하더라도 최종적으로 누가 업무를 이끌고 결과를 책임지는지는 명확해야 하기 때문이다.
DRI는 모든 일을 혼자 처리하는 사람이 아니다. 목표와 범위를 이해하고 필요한 사람을 연결하며 문제를 공유하고 결과가 나오도록 책임지는 사람이다.
DRI를 둔 이유는 리더의 일을 나누려는 데 그치지 않는다. 구성원이 하나의 기능이나 프로젝트를 처음부터 끝까지 이끌며 판단과 책임을 경험하고 성장할 기회를 얻게 하려는 것이었다.
<h2 id="ai를-개인의-도구에서-팀의-시스템으로">AI를 개인의 도구에서 팀의 시스템으로</h2>
AI 시대가 되면서 개발자 한 명이 만들어 내는 결과물의 양이 크게 늘었다.
하지만 개인이 코드를 더 많이 쓴다고 팀의 생산성이 반드시 높아지지는 않는다. 잘못된 방향으로도 더 빨리 갈 수 있고 각자 AI와 함께 서로 다른 방향으로 움직이면 통합과 검증 비용만 더 커진다.
그래서 AI를 개인의 코딩 도구로만 쓰지 않고 팀의 AX와 DX를 개선하는 수단으로 활용하고 있다.
코드 리뷰, 티켓 작성과 정리, 반복적인 문서 작업과 개발 검증 등에 AI 자동화를 적용하고 있다.
이 일을 꾸준히 고민하고 개선하는 Developer Productivity 역할도 팀 안에 두었다.
DP 담당자는 새로운 개발 도구를 들여오는 데 그치지 않는다. 개발자가 제품 개발에 더 집중하도록 반복과 대기 시간을 줄이고 팀이 합의한 기준을 실제 도구와 워크플로우에 반영하는 역할을 맡는다.
코드 리뷰 자동화의 목적도 사람을 완전히 대체하는 데 있지 않다. 반복적으로 확인하는 항목과 기본적인 오류는 AI가 먼저 검토하고 사람은 제품 맥락과 구조, 중요한 트레이드오프에 더 집중하도록 하는 것이 목적이다.
AX와 DX는 문화 개선과 별개의 활동이 아니다. 팀이 합의한 기준을 사람이 매번 기억하고 확인하는 데서 그치지 않고 실제 쓰는 도구와 자동화에 심는 다음 단계라고 생각한다.
<h2 id="팀을-성장시키면서-나도-성장했다">팀을 성장시키면서 나도 성장했다</h2>
지난 1년 동안 팀을 바꾸고 키우려 했지만 그 과정에서 가장 많이 바뀌어야 했던 사람 중 하나는 나 자신이었다.
팀에 투명성을 요구하려면 나부터 판단과 고민을 공개해야 했다. 팀원에게 오너십을 요구하려면 내가 쥐고 있던 결정 권한을 내려놓아야 했다. 스스로 판단하기를 기대한다면 정답만 건네서는 안 되고 어떤 기준으로 판단해야 하는지를 설명해야 했다.
개발자로 일할 때는 어려운 문제를 직접 해결하는 것이 가장 분명한 성과였다.
하지만 팀 규모가 커질수록 내가 직접 해결하는 방식은 한계를 드러냈다. 내가 결정을 많이 내릴수록 팀은 나에게 더 기댔고 나는 더 큰 병목이 됐다.
리더에게 필요한 성장은 문제를 더 많이 직접 푸는 능력이 아니었다. 적절한 사람에게 문제를 맡기고 판단에 필요한 맥락과 기준을 건네며, 필요할 때 돕되 대신 해결하지 않고 기다리는 능력이었다.
물론 여전히 잘하지 못한다.
일정이 급할 때 직접 개입하고 싶은 순간이 있고 충분히 설명했다고 여겼지만 실제로는 맥락이 부족했던 경우도 있다. 장기적인 성장을 기다리기보다 단기 결과를 앞세운 순간도 있었다.
팀의 일하는 방식을 바꾸는 과정에서 내 역할과 판단 방식도 함께 바뀌어야 했다.
<h2 id="다음은">다음은</h2>
지난 1년은 2.0을 출시하고 제품의 기반을 다시 세운 시간이자, 약 20명의 팀이 같은 방향으로 일할 수 있는 기준과 구조를 만들어 온 시간이었다.
다음 1년에는 지금까지 만든 방식이 특정 리더의 계속된 개입 없이도 돌아가도록 하는 데 집중하려 한다.
팀원들이 공통된 방향과 기준 위에서 더 많은 결정을 내리고, DRI가 자기 영역을 이끌며, 페어를 통해 경험과 판단이 팀 안에 퍼지는 구조를 강화하고 싶다.
Linear와 Notion도 쓰는 것 자체보다 실제 업무와 팀의 기억을 얼마나 정확히 반영하는지를 중심으로 개선할 것이다.
AX와 DX도 일부 개인의 생산성 향상에 머무르지 않고 팀 전체의 개발 경험과 제품 품질을 높이는 시스템으로 키우고자 한다.
이러한 시도를 이어 올 수 있었던 데에는 CTO 유진님의 적극적인 지원도 컸다. 새로운 AI 도구를 단순한 비용으로 보기보다 팀의 생산성과 개발 방식을 개선하기 위한 투자로 바라봐 주셨고, 여러 도구를 직접 사용하고 실험할 수 있도록 꾸준히 지원해 주셨다.
새로운 도구가 항상 기대한 결과를 만드는 것은 아니다. 실제 업무에 맞지 않아 중단한 시도도 있었고, 도입 이후 사용 방식을 다시 설계해야 했던 경우도 있었다. 그럼에도 시행착오를 허용하고 계속 실험할 수 있는 환경이 있었기에, AI를 일부 개인의 활용에 그치지 않고 팀의 AX와 DX로 확장할 수 있었다.
지난 1년 동안 만들고 싶었던 것은 규칙이 많은 팀이 아니었다. 공통된 목적과 방향 위에서 각자가 판단하고, 과정과 결과를 투명하게 공유하며, 서로의 성장을 돕는 팀이었다.
이 변화는 나 혼자 만든 것이 아니다. 새로운 방식에 적응하고 부족한 기준을 함께 채우며 짧은 기간에 제품 전환을 완수한 팀원들의 노력이 있었고, 새로운 방식을 시도할 수 있도록 믿고 지원해 준 리더십이 있었기에 가능했다.
다만 그 과정에서 내가 맡은 역할과 책임까지 과도하게 낮춰 말하고 싶지는 않다.
서로 다른 방향으로 흘러가던 2.0을 다시 정렬해 출시하고, 익숙한 업무 방식을 실제로 바꾸고, 약 20명의 팀이 함께 판단하고 성장할 기반을 만드는 일은 결코 쉽지 않았다.
때로는 불편한 결정을 내려야 했고, 같은 내용을 여러 번 설명하고 설득해야 했으며, 그 결과의 책임도 감수해야 했다.
완벽한 팀을 만든 것은 아니다.
하지만 1년 전보다 더 투명하게 소통하고, 더 많은 사람이 맥락을 공유하며, 개인의 기억보다 팀의 기준과 자산 위에서 제품을 만드는 조직이 됐다는 점에는 분명한 자부심이 있다.
2.0을 출시한 것 못지않게 이 제품을 꾸준히 발전시킬 팀의 기반을 만든 일이 지난 1년 동안 내가 이룬 가장 의미 있는 성과라고 생각한다.
이제는 그 기반 위에서 더 높은 수준의 제품과 더 강한 팀을 만들어 보고 싶다. </section></div>

lannex

Shin, SJ

AstraGo 팀을 맡아 2.0 전환과 함께 팀이 일하는 방식을 바꿔 온 1년의 회고

같은 방향으로 일하는 팀을 만들어 온 1년

댓글