제품 정의하기
Source: Dev.to
“지혜의 시작은 용어 정의이다” - 소크라테스. 아마도.
인류가 고대 메소포타미아의 시날 평원에 도시와 탑을 세우려 했다는 초기 성경 이야기는 “바벨탑”을 공통된 언어 없이 공동 목표를 이루려는 어려움을 상기시키는 영원한 상징으로 만들었다. 익숙하지 않은 사람들을 위해 HPV(Highlights Package Version)는 이렇게 시작한다:
이제 온 세상이 한 언어와 공통된 말을 가졌다…
그들은 서로에게 말했다. “오라, 우리 스스로 도시를 짓고, 하늘에 닿는 탑을 세워 우리 이름을 남기자…”
그러나 주님께서 그들이 짓고 있던 도시와 탑을 보시러 내려오셨다.
주님이 말씀하시길, “같은 언어를 쓰는 한 민족이 이렇게 시작한다면, 그들이 계획하는 일은 무엇이든 불가능하지 않을 것이다. 이제 내려가서 그들의 언어를 혼란스럽게 하여 서로 이해하지 못하게 하자.”
그래서… 그들은 도시 건설을 멈췄다. 그래서 그곳을 바벨이라 부른다—그곳에서 주님이 온 세상의 언어를 혼란스럽게 했기 때문이다.
그 후 주님은 그들을 온 땅에 흩어 놓으셨다.
흥미롭게도, 주님이 “온 세상의 언어를 혼란스럽게” 하셨을 때 무슨 일이 일어났는가? 그들은 건설을 멈췄다!
원칙을 약간 늘려 보면, 소프트웨어 개발도 제품 관리자와 개발자 사이에 “무엇을 만들 것인가”에 대한 정의가 부족한 비슷한 단절을 오래 겪어왔다. 최선일 때는 개발 노력을 방해하고, 최악일 때는 바벨처럼 사업이나 소프트웨어 생산이 멸망에 이를 정도로 중단될 수 있다—성경적 규모의 오류다.
마케팅에서는 “콘텐츠가 왕이다”. AI에서는 “컨텍스트가 왕이다”. 우리는 그것을 들어봤고, 경험했으며, 모두가 좋은 컨텍스트를 해결하려고 애쓰고 있다. 메모리 시스템, 최적화된 검색, 임베딩, 늘어난 컨텍스트 윈도우 등등.
좋은 컨텍스트 관리가 없으면, 에이전트는
(a) 작업을 제대로 수행할 충분한 정보를 전혀 갖지 못하거나,
(b) 완전한 제품 정의가 에이전트가 활용할 수 있는 훌륭한 추가 컨텍스트가 된다.
하지만 AI 에이전트는 수십 년간 소프트웨어 개발에서 조용히 존재했거나, 오히려 존재하지 않았던 문제를 드러낸다: 대부분의 조직은 실제로 일관된 제품 정의를 유지하지 않는다.
대신 제품 정의는 Jira 티켓, Slack 대화, 온보딩 콜, 오래된 문서, 채팅 세션, 회의 결과, 그리고 가장 중요한 장소라 할 수 있는 Git 커밋과 오랜 기간 근무한 엔지니어들의 기억에 흩어져 있다.
인간은 이를 놀라울 정도로 잘 보완한다. 문제조차 없다고 느낄 정도다. 우리는 질문을 잘하고, 의도를 추론하며, 빈틈을 메우는 데 능숙하다. AI 에이전트는 그리 관대하지 않다.
AI 에이전트는 보통 인간보다 열등하게 다음을 구분한다:
- 현재 아키텍처와 옛 아키텍처,
- 실제 비즈니스 규칙과 폐기된 규칙,
- 원하는 프로세스와 “임시”(3년 된!) 우회책.
정의되지 않은 제품은 정의되지 않은 AI 행동을 만든다. 그리고 AI 에이전트는 느리지 않다. 제품 정의가 모호하고, 일관성이 없으며, 파편화돼 있으면 에이전트는 그 혼란을 개발자가 “내 컴퓨터에서는 동작한다”라고 말하기도 전에 실행한다.
인간 개발자는 요구사항을 오해해 하루를 잃을 수 있다. 컨텍스트가 불분명한 자율 에이전트는 아름답게 작성된, 자신감 넘치는 잘못된 구현을 대량으로 생성할 수 있다. 인간이 나중에 이를 잡아내긴 하지만, 우리는 여전히 토큰, 시간, 비용, 그리고 정신 건강을 낭비한다.
역사적으로 모호함은 생산성을 떨어뜨렸다. AI 시대에는 이 역학이 더욱 심화된다고 주장하고 싶다.
많은 소프트웨어 조직은 문서보다는 축적된 구전(전승)에 의존한다.
- “Sarah에게 배포가 어떻게 되는지 물어봐.”
- “청구 서비스는 월말에 이상해.”
- “그 Terraform 모듈은 절대 건드리지 마.”
- “위키 페이지가 대부분 맞아.”
- “우리는 2022년에 그걸 시도했는데 보고서가 깨졌어.”
수년간 소프트웨어 팀은 인간이 놀라울 정도로 적응력이 뛰어나고, 무엇보다도 사회화 능력이 있기 때문에 이를 용인해 왔다. “이 청구 이슈는 Dan에게 물어볼게—그는 이 분야 전문가야.” 하지만 AI 시스템은 ‘전화 친구’가 될 수 없다. 전적으로 받는 컨텍스트의 품질과 일관성에 달려 있다.
즉, 우리 사랑하는 소프트웨어 산업은 새로운 제약에 직면하고 있다: AI 에이전트가 신뢰성 있게 소프트웨어를 만들기 위해서는, 조직이 먼저 제품을 신뢰성 있게 정의해야 한다.
최근 의도 문제에 대한 흥미로운 대응 중 하나는 “Spec Driven Development”(SDD)의 부상이다.
핵심 아이디어는 탄탄하다: 구현을 시작하기 전에 인간과 AI 에이전트 모두가 같은 이해를 공유할 수 있을 정도로 의도된 동작을 명확히 정의한다. “우리가 원하는 것”을 막연히 지시하는 대신, 명시적인 사양을 먼저 만들고 그 위에 구축한다. 이는 순수한 “감각에 의존한” 개발보다 의미 있는 개선이다.
좋은 사양은 모호성을 줄이고 정렬을 개선하며, 파편화된 채팅 기록이나 반쯤 기억나는 회의 논의보다 훨씬 안정적인 기반을 AI 에이전트에 제공한다.
하지만 여전히 문제가 있다.
많은 SDD 구현에서 사양 자체가 일시적이다. 사양은 생성되고, 다듬어지고, 구현에 반영되고, 코드 리뷰 때 언급될 수도 있지만, 그 뒤 조용히 버려진다. 6개월 후 코드는 진화하고, 비즈니스는 변하고, 아키텍처는 바뀌지만 사양은 그대로 남는다. 의도는 구전으로 다시 사라진다.
사양은 인프라라기보다 비계에 가깝다: 건설 중엔 유용하지만 건물이 완성되면 버려진다.
그 결과 조직과 AI 에이전트는 같은 이해를 반복해서 재구축하게 된다:
- 요구사항을 다시 설명하고,
- 가정을 다시 발견하고,
- 컨텍스트를 다시 구축하고,
- 의도를 다시 학습한다.
여기서 영구적인 제품 정의가 흥미로워진다. 사양을 일시적인 구현 산출물이 아니라 지속적으로 운영되는 자산으로 유지한다. 개별 구현, 인력 교체, 아키텍처 재작성, AI가 생성한 코드 물결을 견뎌낼 만큼 내구성이 있는 것이다. 실제로 그런 변화들을 살아남을 뿐 아니라, 적극적으로 방향을 제시한다.
에이전트가 점점 더 많은 세상을 만들고 있는 지금, 이러한 내구성 있는 제도적 기억은 기계가 읽을 수 있으면서도 인간이 읽을 수 있어야 할 필요가 있다.
이것이 DefProd의 아이디어다. 나는 제품 정의를 일시적인 문서가 아니라 영구적인 인프라로 취급하는 시스템을 구축하고 있다. 그리고 바로 그걸 기준으로 구축한다.
요구사항과 의도가 서로 연결되지 않은 시스템과 인간 기억에 흩어져 있는 대신, 제품 자체가 제품 관리자, 개발자, AI 에이전트가 공유하는 지속적으로 유지되는 정의가 된다. 구축되는 대상에 대한 내구성 있고 진화하는, 기계가 읽을 수 있는 정의다.
소프트웨어 산업은 수십 년 동안 소스 컨트롤, CI/CD 파이프라인, 클라우드 인프라, 관측성을 개선해 왔다. 이러한 시스템이 강력해진 이유는 공유된 운영 진실을 확립했기 때문이다.
AI 개발도 제품 의도 자체에 대해 같은 전환이 필요할 수 있다. AI 능력이 향상될수록 모호함의 비용도 함께 증가하기 때문이다. 더 좋은 모델과 프롬프트가 에이전트 개발에서 큰 변화를 만들 수 있지만, 성공적인 조직은 더 명확한 정의를 갖게 될 것이다. 공유된 정의, 공유된 의도, 공유된 컨텍스트가 바로 그 열쇠다.
실제로 구축하기
왜냐하면 인간과 AI 에이전트가 같은 것을 만들려면, 그 같은 것에 대한 강력하고 공유된 의미가 필요하기 때문이다.
공유되고 명시적인 제품 정의는 소프트웨어 바벨 문제에 대한 유망한 해결책으로 떠오르고 있다. 하지만 AI 에이전트가 산업을 얼마나 더 진지하게 제품 정의에 집중하도록 만들지는 아직 확실치 않다…