과거 스타트업에서 엔지니어 10명으로 일할 때, 회사는 큰 기능을 4주 안에 내놓으려 했다. 출시는 했지만 뒤이어 2주 동안 대부분 버그를 고쳤다. 팀을 이끈 사람은 주마다 버그와 작업 수를 측정했고, 촉박한 일정이 고객에게 가치를 더 빨리 전하기보다 품질을 떨어뜨렸다고 봤다.
이 글은 인공지능(AI)으로 코드 작성과 시제품 제작이 빨라져도 소프트웨어 제품을 고객에게 전달하는 속도가 함께 빨라지는 것은 아니라는 주장이다. 제품·엔지니어링 팀을 이끄는 사람이라면 코드 생산량보다 고객이 새 기능에서 가치를 얻기까지의 전체 흐름을 살펴야 한다는 제안이다.
속도보다 전체 흐름을 봐야 하는 이유
제품 개발의 가치 흐름은 코드를 만드는 일에 그치지 않는다. 고객의 필요를 이해하고, 해결책을 구상하고, 다른 선택지와 비교해 우선순위를 정한 뒤, 설계와 엔지니어링을 거쳐 기능을 내놓는 과정이다. 각 단계에서는 앞선 판단을 확인하는 피드백이 생긴다. 사용자 인터뷰는 코드를 만들기 전에 설계를 검증하고, 코드 검토는 배포 전에 코드가 올바른지 확인하는 식이다.
하지만 팀원마다 동기와 의견이 다르고, 제품이 커질수록 복잡성과 문제가 생길 여지가 늘어난다. 실제 회사는 한 번에 기능 하나만 만드는 곳도 아니다. 여러 아이디어와 변경 사항이 동시에 진행된다. 여기에 AI로 모든 작업의 속도를 높여도 전체 전달이 빨라진다고 보장할 수 없다. 오히려 코드는 빠르게 바뀌는데 고객이 새 기능을 써서 가치를 얻는 과정은 제자리일 수 있다.
속도가 높아지면 품질이 낮아지거나 구성원들이 서로 다른 방향으로 움직일 수 있다. 에이전트를 계속 돌리는 데 집중하다 보면 의사결정이 얕아질 수도 있다. 과거 스타트업 팀에서도 엔지니어들은 더 빨리 일을 끝내려고 지름길을 찾았고, 때로는 의도치 않게 이를 택했다. 그러나 경영진은 가치가 전달되고 있다고 봤다. 고객에게 결과물이 나오는 동안 팀이 치르는 대가는 눈에 잘 띄지 않았기 때문이다.
그 차이는 4주 안에 큰 기능을 내놓으려 한 일정에서 드러났다. 팀은 주마다 처리 중인 버그와 작업 수를 확인했다. 기능을 ‘성공적으로’ 출시한 1~4주 차의 속도전 뒤에는 버그 수정이 대부분을 차지하는 2주가 이어졌다. 팀을 이끈 사람은 이 자료를 최고경영자에게 보여주며, 빠른 출시를 요구해도 이후 문제를 고치는 데 시간을 쓰면 속도 이점이 생기지 않는다고 설명했다. 버그를 겪는 고객의 경험도 나빠지고, 이는 실제 사업 성과에도 영향을 준다는 점을 함께 짚었다.
무엇을 더 빠르게 해야 할까?
속도가 부족해 보이면 평가나 A/B 테스트를 더해 여러 시제품 중 나은 것을 고르고, 코드 변경으로 버그가 늘면 에이전트를 투입해 바로 고치자는 대응이 떠오를 수 있다. 하지만 버그 수정도 코드 변경을 하나 더 만들고, 그 변경이 다시 문제를 일으킬 가능성을 낳는다. 움직임과 선택지를 늘리는 일이 시스템을 복잡하게 만들 수 있다. 그 부담은 나중에 제품의 잦은 변화와 선택지에 지친 고객에게 돌아갈 수도 있다.
한 부분의 속도가 나머지 부분을 압도하면 피드백 과정도 제 기능을 잃는다. 코드 검토가 한 사례다. 검토자가 감당할 수 있는 것보다 더 많은 요청을 받으면 내용을 살피지 않고 승인할 수 있다. 서류상 검토 절차는 남아 있어도 오류를 잡아내지 못한다.
글쓴이는 과거 팀에서 경영진과 자료를 정기적으로 살펴본 뒤 품질이 훼손되지 않도록 주간 리더십 회의에서 같은 지표를 확인했다고 말한다. 그 결과 팀은 더 지속 가능한 절차를 갖췄고 회사와 고객에게도 더 나은 결과를 얻었다고 평가한다. 이는 당사자의 경험과 평가이며, 모든 팀에서 같은 결과가 난다는 뜻은 아니다.
팀의 흐름을 어떻게 관리할까?
첫째, 팀의 목표를 소프트웨어 산출물이 아니라 고객 가치로 정의한다. 프로젝트는 사업 결과를 기준으로 정하고, 작업 항목도 사용자 스토리처럼 고객이 얻는 가치로 표현해야 한다. 그러면 목표가 풀 리퀘스트의 수가 아니라 결과라는 점이 분명해진다.
둘째, 팀의 작업이 시작부터 고객에게 도달할 때까지 이어지는 흐름을 파악하고 관리한다. 목표를 정한 뒤에는 실행도 그 목표에 맞춰 살핀다. 각 변경이나 기능이 실제 서비스에 도달하는 데 걸리는 시간을 보고 개선할 곳을 정한다. 예를 들어 계획 단계가 개발보다 오래 걸린다면 코딩 에이전트를 더 돌리기보다 계획을 빠르게 하는 데 집중해야 한다. 목표는 각자 바쁘게 일하는 것이 아니라 아이디어가 고객 가치로 이어지는 시간을 줄이는 것이다.
셋째, 개인 생산성이 아니라 팀 생산성을 기준으로 본다. 엔지니어 한 명이 에이전트 100개를 동시에 돌려도 그 결과가 이후 담당자에게 100배의 일을 만들어 전달 시간을 늘린다면 팀 전체는 빨라지지 않는다. 제품과 디자인 결정에도 같은 원칙이 적용된다. 목표는 각 개인이 따로 최대한 빨리 움직이는 것이 아니라 팀이 함께 결과를 내는 것이다.
팀을 하나의 시스템으로 관리하면 그 안에서 어떤 방식을 쓸지 실험하고 판단할 수 있다. 코드 검토를 생략하는 편이 나은지는 팀의 상황에 달려 있다. 고객에게 어떤 결과를 내야 하는지 알고 있다면 그 선택을 근거를 갖춰 평가할 수 있다. 원문은 각 단계의 병목을 어떤 지표와 방법으로 측정할지 구체적으로 제시하지 않는다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요