AI 코딩 에이전트는 빠르다. 너무 빠르다. JWT 인증 모듈을 30분 만에 뽑아내고, 테스트 케이스를 자동으로 생성하고, PR 설명까지 써준다. 문제는 그 다음이다. 다음 날 새 세션을 열면 에이전트는 어제의 결정을 기억하지 못한다. Redis 블랙리스트를 쓰지 않기로 했던 결정도, 파일 네이밍 컨벤션도, 에러 클래스 구조도—전부 리셋된다. 그리고 에이전트는 다시 '합리적인 추측'으로 코드를 채우기 시작한다.
이것이 AI-First 팀이 지금 직면한 역설이다. 속도는 올라갔지만 예측 가능성은 떨어졌다. dev.to에 공개된 OpenSpec 통합 가이드는 이 문제를 정면으로 겨냥한다. OpenSpec은 Claude Code에 '버저닝된 스펙 레이어'를 삽입하는 오픈소스 CLI다. 핵심 아이디어는 단순하다: 에이전트가 프롬프트가 아니라 스펙 문서를 읽고 일하게 만든다. project.md에 스택, 컨벤션, 폴더 구조를 명문화해두면 Claude Code는 새 세션에서도 그 컨텍스트를 그대로 로드한다. 'any 타입 금지', '에러는 AppError 클래스로 통일'—이런 팀의 암묵지가 코드베이스에 주입된 규칙이 된다.
워크플로우 자체도 설계되어 있다. /openspec-proposal로 기획 모드를 열면 에이전트가 feature에 대해 먼저 질문한다. 개발자가 답변하면 proposal.md(설계 결정), tasks.md(원자적 작업 목록), spec.md(delta 마커)를 생성한다. 여기서 중요한 단계가 하나 있다—구현 전 리뷰다. OpenSpec 가이드가 명시하듯, 에이전트가 Redis 블랙리스트를 가정했는데 프로젝트에 Redis가 없다면, 이 시점에 proposal.md를 수정하면 된다. 코드를 건드리기 전에 말이다. /openspec-apply로 구현을 시작하면 에이전트는 스펙 범위 밖의 결정을 내리지 않고, 판단이 필요한 순간에는 묻고 진행한다.
그런데 왜 이 접근이 지금 더 중요해졌는가. dev.to의 또 다른 분석 'Technical debt and AI: is it gone?'은 그 이유를 냉정하게 정리한다. AI가 만든 기술부채는 기존 부채와 성질이 다르다. 전통적 기술부채는 '알려진 미지수(known-unknown)'였다. 어떤 모듈이 엉망인지 알고 있고, 왜 그렇게 됐는지도 안다. 반면 AI 생성 코드는 시맨틱 부채(semantic debt)를 만든다. 코드는 깔끔하고 테스트도 통과한다. 그런데 새벽 3시에 장애가 나면 그 로직을 이해하는 팀원이 아무도 없다. 디버깅 비용이 직접 작성 코드 대비 3~5배라는 추정치는 과장이 아니다.
더 까다로운 문제는 '부채의 전파 속도'다. 전통적 기술부채는 특정 모듈에 국소적으로 머문다. AI 기술부채는 다르다. 코드베이스에 나쁜 패턴이 존재하면, 에이전트의 컨텍스트 윈도우가 그 패턴으로 오염된다. 오염된 컨텍스트로 다음 코드를 생성하면 나쁜 패턴이 전파된다. 자기강화 사이클이다. 인간이 천천히 누적한 부채를 AI가 빠른 속도로 복제하고 증폭시킨다. 같은 분석이 지적하듯, 'AI를 마법 지팡이로 쓰면 부채를 없애는 게 아니라 고금리 단기 대출을 코드베이스에 박아 넣는 것'이다.
두 글의 교점에서 실용적인 결론이 나온다. 컨텍스트 설계가 상류(upstream) 품질 관리다. 에이전트에게 좋은 컨텍스트를 먹이면 생성 결과의 품질 분산이 줄어든다. OpenSpec의 project.md가 하는 일이 정확히 이것이다—팀의 명문화된 결정을 에이전트의 출발점으로 만든다. proposal→리뷰→apply의 사이클은 '구현 전 설계 검토'를 워크플로우에 강제로 삽입한다. 빠른 코드 생성과 설계 의도 보존이 동시에 가능해지는 구조다.
팀 리더 관점에서 즉시 적용 가능한 체크포인트를 짚으면 이렇다. 첫째, CLAUDE.md나 OpenSpec의 project.md에 '절대 하지 말 것' 목록을 먼저 채워라. 컨벤션, 금지된 패턴, 승인된 라이브러리 목록—이것이 에이전트가 읽는 첫 번째 문서가 되어야 한다. 둘째, feature 단위를 작게 쪼개라. OpenSpec 가이드가 '작업 목록이 12~15개를 넘으면 두 개 제안으로 분리하라'고 권고하는 이유는 에이전트의 컨텍스트 유지 능력에 현실적인 한계가 있기 때문이다. 셋째, openspec/ 디렉토리를 git에 커밋하라. 스펙 문서는 '실행 가능한 문서'다. 변경 이력이 코드 변경 이력과 나란히 추적되어야 한다.
전망은 분명하다. AI 코딩 에이전트의 자율성은 계속 높아진다. 더 빠르게, 더 많은 코드를 생성할 것이다. 그 속도가 올라갈수록 스펙 문서화와 컨텍스트 설계의 ROI도 함께 올라간다. 2026년의 기술부채 문제는 '코드가 지저분하다'가 아니라 '시스템을 이해하는 사람이 없다'로 이동하고 있다. AI가 빠를수록 Spec이 먼저인 이유가 여기 있다. 에이전트가 일하기 전에 팀이 먼저 합의해야 할 것—그게 설계 문서다.