코드는 저렴해졌지만, 우리의 관습은 눈치채지 못했다

현대 소프트웨어 개발 생명주기 (Software Development Lifecycle)의 상당 부분은 코드가 비싸고 변경하기 어렵다는 점을 바탕으로 구축되었습니다. 그래서 우리는 누군가 코드를 작성하기 전에 무엇을 만들지 결정하기 위한 의식 (Ceremonies), 관습 (Rituals), 그리고 전체적인 철학을 만들어냈습니다. 엔지니어가 코드를 작성하기 훨씬 전부터 모든 스토리 (Story)를 계획했습니다. 제품 관리자 (Product Managers)들은 엔지니어링 리소스가 투입되기를 기다리는 방대한 백로그 (Backlog)를 관리했습니다. 디자이너들은 구현 (Implementation)보다 목업 (Mockup)을 만드는 것이 훨씬 빠르기 때문에 목업을 제작했습니다. 우리는 매주 몇 시간씩 앉아 각 변경 사항에 적합한 Fibonacci 수(Fibonacci number)가 무엇인지 토론했습니다. 왜냐하면 빌드 시간 (Build time)은 복잡성에 따라 몇 시간에서 몇 달까지 걸릴 수 있었기 때문입니다. 그중 많은 부분은 타당했습니다. 소프트웨어를 구축하는 것이 느린 단계였을 때, 다음에 무엇을 만들지, 어떤 형태를 취해야 할지를 논의하기 위해 6명 정도의 사람들과 회의를 갖는 것은 합리적이고 거의 필수적인 것처럼 느껴졌습니다.

관습이 교조주의 (Dogma)가 될 때
우리의 현실은 근본적으로 변화했습니다. 이제 코드를 작성하는 것이 빠른 단계가 되었거나, 적어도 예전보다는 훨씬 빨라졌습니다. 문제는 소프트웨어를 출시 (Shipping)하는 것과 관련된 나머지 관행들이 아직 따라잡지 못했다는 점입니다. 프로세스의 다른 모든 부분에서 우리는 여전히 코딩이 기계의 가장 느린 부분인 것처럼 행동하고 있습니다. AI는 소프트웨어를 쉽게 만든 것이 아닙니다. AI는 병목 현상 (Bottlenecks)이 발생하는 위치를 바꾸어 놓았습니다. 이제 비용이 많이 드는 부분은 코드를 타이핑하는 것이 아니라, 무엇이 존재해야 하는지 결정하고, 적절한 컨텍스트 (Context)를 제공하며, 결과를 검증하고, 그 주변의 인간들을 조율하는 일입니다. 이 새로운 현실에 적응하기 위해서 우리는 모든 의식, 모든 관습, 소프트웨어 개발의 모든 단계를 의심해야 합니다. 우리는 이 각각의 단계가 어떤 문제를 해결하기 위해 존재하는지, 그리고 그 문제가 여전히 같은 방식으로 해결할 가치가 있는지, 혹은 그 문제 자체가 여전히 존재하는지 스스로에게 물어야 합니다. 대부분의 팀은 아주 오랫동안 이러한 도약을 하지 못할 것입니다. 많은 팀이 수년간 주변을 맴도는 "좀비 (Zombies)"들에 갇혀 있는 자신을 발견하게 될 것입니다. 가장 잘 적응하는 팀은 무자비하게 과거를 버리고 새로운 것을 기꺼이 시도하는 팀이 될 것입니다.

이것이 계획 (planning)이 죽었다거나, 디자인 (design)이 쓸모없어졌다거나, 혹은 엔지니어가 에이전트 (agent)가 생성하는 것은 무엇이든 배포해야 한다는 의미는 아닙니다. 이는 시스템의 비용이 많이 드는 부분이 이동했음을 의미합니다. 병목 현상 (bottleneck)은 점점 더 판단 (judgment)의 영역으로 옮겨가고 있습니다. 즉, 무엇이 중요한지 결정하고, 그것을 잘 형성하며, 주의 깊게 검토하고, 빠르게 학습하는 일입니다.

더 많이 해야 할 일들

페어 프로토타이핑 (Pair Prototyping)
이것은 불과 몇 년 전에는 존재하지 않았던 정말 흥미로운 기회입니다. 역사적으로 우리는 제품 관리자 (product manager)가 요구 사항을 수집하러 가고, 이를 디자이너 (designer)에게 전달하면 디자이너가 이를 디자인으로 번역하려고 시도하는 프로세스를 가져왔습니다. 그런 다음 엔지니어 (engineer)가 그것의 어떤 버전을 구축하러 갔습니다. 그리고 이 프로세스의 마지막 단계에 이르러서야 무엇이 작동하지 않는지, 그리고 다른 어떤 기회들이 존재하는지를 발견하곤 했습니다. 이제 동일한 두세 명의 인원이 통화에 참여하여 AI의 도움을 받는 거친 "바이브 코딩 (vibe-coded)" 프로토타입을 함께 페어로 작업할 수 있습니다. 기능이 실제로 어떻게 보이는지, 그 복잡성과 한계가 무엇인지 실제로 확인할 수 있으며, 실시간으로 다양한 시도를 해볼 수 있습니다. 한 시간 안에 PM은 예외 케이스 (edge cases)를 볼 수 있고, 디자이너는 상호작용 (interaction)이 어디서 깨지는지 볼 수 있으며, 엔지니어는 어떤 부분이 실제로 어려운지 확인할 수 있습니다. 그런 다음 세션이 끝나면 코드는 버리고, 여러분의 경험을 바탕으로 실제로 무엇을 구축하고 싶은지에 대한 정보를 얻으십시오. 코드 작성은 빠르기 때문에, 더 이상 코드에 얽매일 필요가 없습니다.

연결 시간 (Connection Time)
이전 팀에서 스탠드업 (standup) 미팅을 없애자고 제안했을 때 깨달은 한 가지는, 매일 팀원들과 함께 시간을 갖는 것이 실제로 중요한 사회적 목적을 수행한다는 점입니다. 함께 일하는 사람들과 연결될 수 있는 것은 결속력 (cohesion)과 사기 (morale)에 중요합니다. 다만 스탠드업 미팅이 그 목적에 적합한 장소는 아닐 뿐입니다. 대신, 팀이 의도적으로 연결될 수 있도록 주중에 시간을 따로 마련하십시오. 선택 사항으로 만들고, 부담을 주지 않으며, 즐겁게 만드십시오. Jira 보드에 있는 내용을 로봇처럼 읊는 대신, 서로 어울리고 서로에 대해 알아가는 명확한 목적을 위해 모이십시오.

보여주고 말하기 (Show n' Tell) 우리는 그 어느 때보다 더 많은 것을 구축하고 프로토타이핑 (Prototyping)하고 있습니다. 이제 실험의 마찰 (Friction)이 낮아졌으며, 단지 가능한지 확인하기 위해서라도 무언가를 만들 수 있습니다. 지금이 바로 그것을 뽐낼 때입니다. 순수하게 분위기에 따라 코딩된 (Vibe-coded) 프로토타입을 포함하여, 여러분이 실험해 본 것들을 보여주십시오. 이는 팀 전반에 걸쳐 새로운 아이디어를 생성하고 가능성을 싹틔우는 데 유용합니다.

회고 (Retro) 소프트웨어 개발은 제가 커리어에서 본 것보다 더 빠르게 진화하고 있습니다. 저는 Rails의 부상, 수많은 JS 프레임워크, 그리고 기억할 수 없을 만큼 많은 유행을 지켜볼 만큼 충분히 오래 일해 왔습니다. 발밑의 지면이 계속 변하고 있는 상황에서, 정기적인 팀 회고 (Retrospectives)는 더욱 중요합니다. 회고는 특정 팀에서 무엇이 작동하고 무엇이 작동하지 않는지를 식별하고 그에 따라 피벗 (Pivot)할 수 있는 좋은 방법이었습니다. 이러한 새로운 도구들의 트레이드오프 (Trade-offs)는 아직 명확하지 않으며, 그 기능은 매달 성장하고 있습니다. 무엇이 잘 되고 있는지, 무엇이 그렇지 않은지, 그리고 우리 앞에 어떤 기회들이 있는지 팀과 함께 시간을 내어 성찰하는 것은 더욱 공을 들일 가치가 있습니다.

조정할 사항들 (Things to Tweak)
백로그 그루밍 (Backlog Grooming), 셰이핑 (Shaping), 그리고 리파인먼트 (Refinement) 무엇이라 부르든, 이 루틴은 두 가지 이유로 존재합니다: 1) 팀은 바로 가져다 쓸 수 있도록 잘 정의된 작업 백로그 (Backlog)가 필요하며, 2) 백로그는 방대하기 때문에 가장 가치 있는 것들이 먼저 구축되도록 우선순위를 정해야 합니다. 첫 번째 문제는 여전히 존재할 뿐만 아니라 그 어느 때보다 중요해졌습니다. 실행 가능한 작업을 확보하는 것은 이제 소프트웨어 개발에서 가장 큰 병목 현상 (Bottlenecks) 중 하나입니다. 두 번째 문제는 사라지지 않았지만 형태가 변했습니다. 팀에는 여전히 방향성이 필요합니다. 덜 중요한 것은 아주 작은 티켓 (Tickets)들을 완벽하게 스택 순위 (Stack-ranked)로 유지하는 것입니다. 핵심적인 변화는 초점이 우선순위 선정 (Prioritization)에서, 작업이 출시될 수 있도록 작업을 형성하는 셰이핑 (Shaping)으로 이동한다는 점입니다. 우선순위 선정은 여전히 일어날 수 있지만, 모든 사소한 스토리 (Story)의 정확한 스택 순위를 두고 고민하는 것이 아니라 매우 대략적인 틀 안에서 이루어져야 합니다.

지식 공유 및 문서화 (Knowledge Sharing & Documentation) 이러한 회의와 산출물 (Artifacts)은 지식 사일로 (Knowledge Silos)가 발생하는 것을 방지하고 팀 전체에 지식을 전파하기 위해 존재합니다. 이러한 산출물들이 코드를 작성하는 에이전트 (Agents)들에게 보이는 어떤 형태로든 존재하도록 만드는 것이 중요합니다. 과거에 문서화 (Documentation)는 주로 인간을 위한 것이었습니다. 이제는 우리가 소프트웨어를 구축하는 것을 돕는 시스템들의 컨텍스트 윈도우 (Context Window)의 일부이기도 합니다. 회의는 종종 일시적 (Ephemeral)이기 때문에, 회의록을 기록하고 이를 사용할 수 있도록 만들어야 합니다. 문서화는 시간이 지남에 따라 구식이 되기 쉬우며, 가장 쉽게 생략되는 부분 중 하나입니다. 이를 해결하기 위한 한 가지 전략은 문서 소스를 대상으로 실행되며, 제기할 수 있는 모순점을 찾아내는 에이전트 작업 (Agent Job)을 생성하는 것입니다. 결정은 여전히 인간이 내리지만, 에이전트가 힘든 작업 (Grunt Work)을 수행합니다.

코드 리뷰 (Code Review) 이것은 항상 중요해 왔으며, 코드를 빠르게 생성할 수 있게 된 지금은 더욱 중요해졌습니다. 핵심은 우리가 작성한 코드가 작성자가 믿는 대로 실제로 작동하는지, 보안성 (Secure), 성능 (Performant)을 갖추어 작동하는지, 그리고 향후 소프트웨어를 변경할 수 있는 팀의 능력을 저하시키지 않는지 확인하는 것입니다. 구체적인 주제(예: 보안, 성능, 접근성, 정확성 등)를 부여받은 전문화된 AI 하위 에이전트 (Sub-agents)는 변경 사항에 대해 가치 있는 심층 분석을 추가할 수 있습니다. 저는 프런티어 모델 (Frontier Models)이 인간 리뷰어가 흔히 놓치는 것들을 잡아낼 수 있다는 것을 발견했습니다. 전문가의 인간 리뷰는 여전히 필요하지만, AI와 결합하면 우리는 리뷰 초능력을 갖게 됩니다. 코드 품질이 저하되지 않을 뿐만 아니라, 이전에는 놓쳤을 가능성이 높은 문제들을 잡아냄으로써 실제로 이전보다 더 나은 코드를 작성할 수 있게 되었습니다.

버려야 할 것들 (Things to Drop)

추정 및 스프린트 계획 (Estimation and Sprint Planning) 이것들은 애자일 (Agile) 인접 팀들이 수행하는 가장 비용이 많이 드는 의식 (Ceremonies) 중 일부입니다. 이들은 모두 "이 시간 단위 동안 얼마나 많이 구축할 수 있는가?"라는 질문에 답하는 것에 관한 것이며, 여기서 시간 단위는 보통 1~2주입니다. 저는 매주 이를 위해 몇 시간을 할애하는 팀에 속해 있었습니다.

어떤 작업들을 추정(estimate)하고 논쟁하는 데 걸리는 시간 동안, 이제 우리는 그 작업을 끝낼 수도 있습니다. 이러한 자원들은 이제 어떤 Fibonacci 수(Fibonacci number)를 부여해야 할지 논쟁하는 것보다, 작업을 구체화(shaping work)하고 즉시 실행 가능한 상태(shovel-ready)로 만드는 데 더 효과적으로 배치됩니다. 탐구할 가치가 있는 많은 대안들(Kanban, Shape Up 등)이 있습니다. 혹은 아마도 답은 완전히 새로운 무언가일 수도 있습니다.

스탠드업 (Standup)
어제 무엇을 했고 오늘 무엇을 할 계획인지에 대한 일일 정보 덤프(info dump)입니다. 이는 조정 드리프트 (coordination drift), 작업 가시성 (visibility into work), 그리고 차단 요소 제거 (removing blockers)와 같은 팀의 문제들을 해결하기 위한 것입니다. 이 회의는 항상 이러한 문제들을 해결하는 가장 비용이 많이 드는 방법 중 하나였습니다. 조정 드리프트는 페어 프로그래밍 (pair programming)이나 테크 리드 (tech leads)와 같은 관행을 통해 더 잘 처리될 수 있습니다. 가시성은 팀이 사용하는 어떤 작업 관리 시스템 (task management system)에 의해서도 처리되어야 합니다. 그리고 그 누구도 자신의 차단 요소를 해결하기 위해 다음 스탠드업까지 기다려서는 안 됩니다.

전통적인 스탠드업 대신, 의제가 열려 있는 시간을 따로 확보하세요. 팀원들이 논의하고 싶은 항목을 의제에 추가할 수 있도록 허용하세요. 시간이 되면, 의제에 따라 적절한 팀원들이 참석하면 됩니다. 의제에 아무것도 없다면, 회의를 할 필요가 없습니다. 신호 대 잡음비 (signal-to-noise ratio)가 갑자기 매우 높아지며 비용은 크게 줄어듭니다. 이것은 사실 AI와는 별 상관이 없으며, 우리가 오래전에 없앴어야 했을 유물일 뿐입니다. 그리고 이건 제 블로그니까 제가 원하면 울 수도 있어서 슬쩍 끼워 넣어 보는 것입니다.

모든 것에 의문을 제기하세요 (Question Everything)
세상에는 많은 의식(rituals)들이 있고, 서로 다른 문화를 가진 다양한 조직들은 저마다 셀 수 없이 많은 견해를 가지고 있습니다. 만약 이 글에서 단 한 가지만 얻어간다면, 그것은 이것이어야 합니다: 주기적으로 팀의 패턴을 재검토하고 '왜'라고 물으세요. 우리가 해결하려는 문제는 무엇인가? 그 문제는 여전히 해결할 가치가 있는가? 이것이 여전히 문제를 해결하는 최선의 방법인가? 만약 문제가 명확하고 그 의식 (ceremony)이 대안들보다 문제를 더 잘 처리한다면, 좋습니다. 계속하세요. 하지만 그렇지 않다면, 후세를 위해 그것을 계속 매달고 있지 마세요.

더 나은 것이 있다면 그것을 찾아내어 받아들이세요. 어쩌면 당신은 다른 이들에게 하나의 의식 (ritual)이 될 길을 개척하게 될지도 모릅니다. Originally published at https://joshsaintjacque.com/blog/code-got-cheaper-our-rituals-didnt-notice .