에이전틱 코딩이 개발 생산성을 높여준다는 건 이제 누구도 부정하지 않는다. 문제는 그 다음이다. 프로젝트가 커지고, 컨텍스트가 복잡해지고, AI가 만들어내는 코드가 수천 줄을 넘어가면 — 환각이 슬금슬금 파고든다. 카카오페이 AI 플랫폼 팀이 최근 기술 블로그에 올린 SDD 실전기는 정확히 이 지점을 찌른다.

spec-kit이라는 프레임

카카오페이 팀이 도입한 건 GitHub의 오픈소스 도구 spec-kit을 기반으로 한 SDD(Spec-Driven Development) 워크플로우다. 핵심 아이디어는 단순하다: AI한테 코드를 시키기 전에, 스펙을 먼저 확정한다.

구체적으로 네 단계를 밟는다.

  1. Constitution — 시스템의 최상위 규칙을 정의한다. 아키텍처 원칙, 코딩 컨벤션, 금지 패턴 같은 것들.

  2. Specify — 개발할 기능의 구체적인 명세를 작성한다. 입출력, 엣지 케이스, 의존성까지.

  3. Plan — constitution과 specify를 먹여서 개발 계획을 생성한다.

  4. Tasks — 계획을 실행 가능한 개별 작업으로 쪼갠다.

왜 이게 환각 문제에 효과적인가. AI가 코드를 생성할 때 가장 위험한 순간은 맥락이 모호한 순간이다. "이거 알아서 잘 만들어줘"라고 시키면 AI는 합리적으로 보이는 코드를 만들어내지만, 그게 팀의 아키텍처 원칙과 맞는지, 기존 모듈과 충돌하지 않는지는 보장할 수 없다. Constitution과 Specify가 그 모호함을 좁혀준다. AI가 추측할 여지 자체를 줄이는 셈이다.

카카오페이 팀의 표현을 빌리면, 개발자의 역할이 "코드를 작성하는 사람"에서 "스펙을 검증하고 테스트를 설계하는 사람"으로 이동했다. 코드 리뷰의 초점도 바뀌었다. 라인 바이 라인으로 로직을 뜯는 게 아니라, 스펙 대비 결과물이 맞는지를 검증하는 방향으로.

직방은 숫자로 증명하고 있다

비슷한 맥락에서 직방도 움직였다. 2025년 하반기에 AI-SDD를 전사 도입한 직방은 올해 3월 주주총회에서 구체적 성과를 공개했다. 서비스 구현 기간이 23주에서 23일로 줄었고, 상반기 기준 개발 생산성 3배 향상. 연말까지 4배 가속을 목표로 잡았다.

물론 이 숫자를 액면 그대로 받아들이긴 어렵다. "생산성 3배"가 정확히 뭘 측정한 건지 — 코드 라인 수인지, 배포 빈도인지, 기능 완성 속도인지에 따라 의미가 완전히 달라진다. 하지만 주주총회 IR 자료로 꺼낸 만큼, 어느 정도 유의미한 임팩트가 있었다고 보는 게 합리적이다.

카카오 본사는 좀 다른 방향이다

흥미로운 건, 같은 카카오 계열인데 접근이 다르다는 점이다. 카카오페이가 spec-kit이라는 도구 체인에 집중했다면, 카카오 본사는 "에이전틱 코딩 가이드북"과 "표준 룰셋 공유 시스템"을 만들었다. AI 협업 치트 시트라는 것도 배포했다.

방향성의 차이가 보인다. 카카오페이는 워크플로우 자체를 구조화하는 쪽(spec → plan → tasks)이고, 카카오 본사는 가이드라인과 룰셋을 공유해서 조직 전체의 기준선을 맞추는 쪽이다. SDD가 "어떻게 만들 것인가"에 대한 방법론이라면, 룰셋 공유 시스템은 "무엇을 지킬 것인가"에 대한 거버넌스다. 서로 다른 레이어를 건드리고 있고, 결국 합류할 가능성이 높다.

코드를 안 쓰는 개발자

SDD 논의에서 빠지지 않는 질문이 있다. 코드를 직접 안 쓰는 개발자가 여전히 개발자인가?

솔직히, 이 질문 자체가 좀 구식이다. 이미 시니어 엔지니어 대부분은 코드 작성보다 설계, 리뷰, 의사결정에 더 많은 시간을 쓴다. SDD는 그 패턴을 주니어 레벨까지 당기는 것에 가깝다. 주니어도 명세를 이해하고, 테스트를 설계하고, AI가 뱉은 결과물을 제대로 평가할 역량이 필요해진다.

카카오페이의 실험이 의미 있는 건, 한국 대형 테크 기업에서 SDD를 단순히 "도입 검토" 단계가 아니라 실전에 넣고, 구체적인 워크플로우까지 기술 블로그에 공개했다는 점이다. 직방의 숫자가 보여주듯 성과도 나오기 시작했다. 바이브 코딩이 재미있는 장난감에서 엔터프라이즈 도구로 넘어가는 이 시점에, 스펙이라는 안전장치 없이 달리는 건 점점 무모해 보인다.