서론

학부 졸업을 앞둔 취업 준비생으로서 최근 업계에 먼저 나가신 분들께 자주 듣는 말이 "요즘 코드는 다 AI가 쳐 준다."이다. 주변에서도 AI 주도 개발을 맛 보고 여러 프로젝트에 도입하려고 시도하시는 분들이 계신다. 무엇보다도, 여러 기업들이 이미 입사 전형에서 AI 사용 경험을 묻는 것을 볼 때, AI 주도 개발은 어떤 시도라기보다는 실체가 있는 흐름이라고 보는 게 적절해 보인다. (당장 이번 봄에만 해도 Toss와 기아의 지원서 작성 화면에서 AI 경험을 직접적으로 묻는 질문을 봤다)

그런데 AI 주도 개발을 해 본 적 없는 입장에서 AI와 관련한 저런 소식들을 들어 보아도 그 실체가 정확히 무엇인지 파악하기가 어려웠다. AI가 코드를 쳐 준다고 하는데 도대체 어떻게 쳐 주는지, 기존 프로젝트 컨벤션은 어떻게 가르쳐줘야 하는지, 더 나아가 코드 작성도 리뷰도 AI가 해 준다면 사람이 해야 하는 일은 무엇일지... 이런 모든 궁금증은 단편적인 소식과 블로그 게시물로는 해결하기 어려웠다.

그래서 이번에는 AI를 활용한 개발, 정확히는 '스펙 주도 개발'의 실체는 무엇인지, 어떤 과정을 통해 이루어지는지, 그리고 궁극적으로 인간은 그 변화의 흐름에서 어떤 역할을 담당하게 될지를 학습 차 정리해보고자 한다.

정의

스펙 주도 개발(이하 SDD)은 'AI로 코딩하기 전에 명세(spec)을 먼저 쓰고, 그것이 인간과 AI의 공통 기준점(source of truth)이 되는 방식'이다.

확실하게 짚고 넘어갈 점은, 위에 적어 둔 SDD의 뜻은 어떤 공식적인 정의로 보기는 어렵다는 것이다. 단어 자체가 AI 도입에 따라 업계에서 자연스럽게 통용되기 시작한 용어이기 때문이다. 중요한 점은 전 과정에서 AI가 깊게 또는 얕게라도 빠짐없이 관여한다는 점이다. 코딩은 대부분 AI가 하고, 이젠 설계와 테스트도 돕기 시작했다. 이 점 때문에 신입 개발자 취업이 어려워졌고, "AI가 개발자를 모조리 대체할 것이다"라는 패닉에 가까운 전망도 어느 정도 확산되고는 있다.

그렇다면 인간은 이제 정말 필요하지 않을까? 현업자도 아니고 졸업도 안 한 내가 쉽사리 단정짓는 것이 이상하게 보일 수도 있다고는 생각하지만, 난 인간의 역할은 분명 여전히 남아 있고 앞으로도 그럴 것이라 전망한다.

왜 인간이 여전히 중요한가

개인적으로 인간이 방향을 잡아주는 게 왜 정의에 반드시 포함되어야 하냐고 생각하냐면, 첫 번째 이유로는 책임과 의사결정 권한은 여전히 인간에게 남아 있기 때문이다.

AI의 발전 속도는 눈부시다. 과거에는 오류만 잡고 방향은 판단하지 못한다는 게 정설이었다. 이제는 방향에 대한 의견도 낸다. 작업이 주어졌을 때, 제한 조건을 고려하고 프로젝트나 개발자의 성향 및 컨벤션까지 따져서 어떤 아키텍처를 선택해야 할지 제안해준다. 중요한 것은 AI는 '제안'만 주며, 더 나아가 AI의 제안은 최선의 선택이 아니라는 점이다. 소프트웨어 개발은 공학이고, 공학에는 트레이드오프가 반드시 따르기 때문이다. 최선의 선택 같은 허상은 없으며, 가치 판단만 있다. 따라서 AI가 정해준 방향을 따를지 말지를 결정하는 것은 대체 불가능하며 고유한 인간의 책임이다.

그래서 여전히 대부분의 개발자들은 AI를 검증의 대상으로 보고 있다. 널리 알려진 StackOverflow의 2025년 설문에 따르면 84%의 개발자가 AI를 사용하거나 계획 중임에도 불구하고 AI 출력의 정확성에 대해 46%의 개발자가 불신하고, 33%만이 신뢰한다고 답했다. AI의 신뢰성에 대해 대부분이 신중하게 접근하고 있다는 뜻이다. 이 지점에서 우리는 중요한 단어 2개를 구분해야 한다: 바로 '방향'과 '오류'이다. AI는 오류를 잡는 건 잘 한다. 예를 들어 우리가 학부 시절 과제할 때 자주 놓쳤던 C/C++ 포인터 오류 같은 것들 말이다. 반면, AI는 어떤 방향을 갈지 결정하진 못한다. 나는 이 뷰 모델이 그렇게 복잡하지 않아서 추상화 수준이 높은 MVI 대신 간단한 MVVM으로 작업하려고 했지만, 이걸 안 말해주면 AI는 MVI로 작업할지 모를 일이다. 인간이 개입하는 지점이 바로 여기다. AI가 이런 저런 방향으로 갈 수 있다고 읊어주면, 그 중 여기로 가자고 결정하는 게 인간인 것이다.

향후 개발자의 역할은

AI는 분명 코드를 잘 친다. 설계도 잘 한다. 그러나 여전히 의사결정 권한은 인간에게 있으며, 비즈니스적 특징이나 코드 외 범위에서 정해진 컨벤션 등 인간에게 더 가까운 정보는 직접 알려주지 않으면 모른다. 따라서 인간이 AI의 작업을 디렉팅해주지 않으면 오히려 잘못된 코드를 칠 가능성이 높다. 오히려 AI 없는 개발에 비해서 효율이 더 떨어질 가능성이 있는 것이다.

정리하면, SDD 시대에서 AI가 반복적 작업 등 일부 맥락에서 인간에 비해 효율적이고, 따라서 인간이 하던 작업을 일부 대체하는 것은 지극히 자연스러운 일이다. 그러나 책임 소재와 의사결정의 책임이 여전히 남아 있는 만큼, 인간의 역할이 ‘직접 모든 코드를 쓰는 사람’에서 ‘문제를 정의하고, 맥락을 제공하고, 결과를 승인하는 사람’으로 이동하고 있다는 점도 분명히 짚고 넘어가야 할 것이다.

과정

과거와의 차이

보통 무언가를 개발한다고 하면 아래와 같은 과정을 거치곤 한다:

• 기획에 따른 설계
• 구현
• 테스트
• 리뷰
• 병합 요청

일반적으로 AI가 없던 시절에는 위 과정을 대부분 사람이 맡아 진행했다. 그러나 AI가 도입된 이후에는 다르다. 기존에 인간이 맡던 작업을 오히려 주도하거나, 아니면 인간과 함께 작업을 분담하게 되었다:

• 기획에 따른 설계 (인간이 주로, AI가 보조)
• 구현 (AI가 주로)
• 테스트 (인간과 AI가 함께)
• 리뷰 (인간이 주로, AI가 보조)
• 병합 요청 (인간이 주로)

AI가 맡는 작업들이 많아진 만큼, 우리 인간이 해야 할 일은 AI가 우리가 원하는 방향대로 작업을 끌고 갈 수 있게 명확한 방향을 제시해주고 이를 벗어나지 못하게 통제하는 것이다. 따라서 고전적인 작업 과정은 이제는 아래와 같이 변화하게 된다:

일반적인 SDD 개발 과정

일반적인 SDD 개발 과정은 '문제 정의 > 탐색 및 설계 > 검토 및 승인 > 구현 > 기계적 검증 > 결과 평가 > 마무리' 정도로 요약할 수 있다.

앞에서 SDD의 정의에 대해 언급했듯, 위 과정 역시 국제 표준처럼 공식적인 것은 분명 아니다. 그러나 어느 정도 위와 비슷한 형태로 통용되고 있다는 점에서 저렇게 정리해 두었다. 또한, 이 과정은 작업의 크기나 중요도에 따라 일부 생략되거나 합쳐져 진행될 수 있다는 점도 인지해두도록 하자. 즉, 중요한 점은 대략 이런 느낌으로 작업이 진행된다는 것이며, 환경에 따라 얼마든지 유연성 있게 재구성할 여지가 충분하다는 점이다.

차례로 각 단계에 대해 정리해보자:

문제 정의

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | (추상적인 수준에서) 작업의 목표, 제약 조건, 완료 조건을 설정
• AI | 인간의 요구 사항에 대한 일부 수정 제안

작업 목표를 설정하는 것은 당연하다. 필요에 따라 제약 조건을 걸기도 한다. 회사 내에 디자인 시스템이 이미 존재하는 경우 그걸 사용하라고 강제하는 등. 완료 조건이 조금 생소할 수 있는데, CLI는 단순 채팅만 하는 웹 기반 서비스와는 다르게 파일을 수정하고 MCP 서버에 접속하는 등 할 수 있는 일과 볼 수 있는 자료가 매우 많다. 따라서 어떤 파일과 디렉터리를 수정할 수 있는지, 어떤 명령은 금지되는지, 어떤 테스트를 반드시 통과해야 하는지 등을 명시해줘야, CLI의 작업 정확도를 올릴 수 있다.

또한 필요하다면 이슈를 생성하거나 티켓을 발행하고 브랜치를 빼는 작업도 AI가 대신 진행하도록 할 수도 있다.

탐색 및 설계

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | (구체적인 수준에서) 참고할 디렉터리, 사전에 정해진 아키텍처 등을 안내
• AI | 코드베이스 탐색, 파일 읽기, 계획서 작성, 설계 방향 설정

'문제 정의' 단계에서 구체화된 목표에 따라, AI는 필요한 코드를 읽고 분석하여 어떻게 작업할지 계획을 짠다. 이 과정에서 계획서에 해당하는 임시 Markdown 문서가 생성되기도 한다.

검토 및 승인

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | AI의 설계를 검토하고 승인 또는 반려
• AI | 반려 시 반려 사유에 따라 계획 수정

이 단계는 특히 대규모 또는 위험한 작업에서 매우 중요한데, 일반적인 채팅 기반 LLM에 비해 할 수 있는 일이 많은 CLI가 검토 없이 작업을 섣불리 시작할 경우 코드에 의도하지 않은 변경 또는 삭제가 일어날 수 있기 때문이다. 더 나아가 개발 환경이 MCP 서버 등 외부 환경과 연결되어 있을 경우, 실제로 프로덕션 또는 서비스 환경에 문제가 생길지도 모를 일이다. 따라서 '문제 정의' 단계에서 개발자가 의도한 방향대로 설계가 이루어졌는지 컨센서스를 한 번 더 짚고 넘어가야만, 혹시 모를 문제를 예방할 수 있다.

구현

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | (필요한 경우) 제약 사항의 추가 또는 추가 수정 요청
• AI | 승인된 설계안에 따라 기능 구현

이 과정은 많은 설명이 필요하진 않다. AI가 설계안에 따라 코드를 치는 과정이다.

기계적 검증

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 또는 AI | LLM 기반 작업이 아닌 테스트, 빌드, 린팅, 포매팅 등 기계적 검증의 '호출'

전통적인 개발 과정에서도 유닛 및 통합 테스트, 빌드 테스트, 린팅 및 포매팅 검사 등은 반드시 진행했다. SDD에서도 이 과정은 대체로 유지된다. 검증 자체는 인간, CI 스크립트, CLI 등 누구라도 호출할 수 있지만, 테스트 자체는 시스템 명령어 등으로 정의되어 결정적(deterministic)으로 진행된다.

보통 이 단계를 거치는 이유는 AI의 자의적 판단에 맡기는 것보다는 테스트, 빌드와 린트를 결정적인 명령으로 강제하는 편이 더 신뢰할 만하기 때문이다. 만약 이 기계적 검증의 시작을 AI가 호출할 경우, 다음 과정인 '결과 평가'에서 반드시 AI가 의도한 대로 검증을 시도했는지 평가에 포함하는 것도 잊어서는 안 될 것이다.

결과 평가

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | AI의 작업물을 여러 방면으로 평가 및 향후 작업 방향 개선
• AI | 평가 결과에 따른 전역 규칙 등 개발 환경 수정 제안

SDD에서 테스트라고 하면 보통 아래의 2가지로 구분이 가능하다:

• 코드 및 산출물 검토 | 빌드, 통합 테스트 등으로 '기계적 검증' 과정에서 진행함
• 에이전트에 대한 평가 | 여기서 진행

위에 적힌 대로 이 과정은 코드 자체에 대한 평가가 아니라, AI 자체에 대한 평가다. AI가 개발자가 요청한 일을 잘 처리했는지 정성적, 정량적 기준을 마련하여 평가하는 것이다. 나는 처음에 LLM 기반으로 동작하는 AI의 작업을 정량적 기준으로 평가할 수 있는지가 의문이었다. 그런데 사람이 사람을 평가하는 거라고 생각해보니 사실 꽤나 자연스러운 일이더라.

이 과정에서는 다음과 같은 항목들을 따진다. 특히, 이 중 반복해서 사용하는 것들은 지표를 점수화하는 편이 유용하다:

• 스킬 및 커맨드 적중률 | 의도한 스킬이 잘 트리거되었는지
• 요구사항 충족률 | 요구한 사항들이 얼마나 충족되었는지
• 금지 규칙 위반률 | 금지한 제한 사항이 얼마나 위반되었는지

특히 AI의 작업은 여러 개의 스킬 또는 커맨드로 구성되는데, AI가 LLM 기반인 만큼 내가 '이런 저런 스킬을 사용해서 작업해줘'라고 요청해도 그렇지 않을 가능성이 있다. 이러한 LLM 특유의 변동성 및 비결정성을 이 과정을 통해 평가하는 것이다. 그리고 평가 결과 문제가 있었다면, 규칙을 수정하는 등의 방안을 통해 향후 작업 정확도를 개선할 수 있다.

따라서, 이 과정은 에이전트 워크플로의 적합성을 돌아보고, 반복 작업의 정확도를 높이기 위한 개선점을 찾는 과정이라는 점에서 향후 지속 가능한 SSD 유지를 위해 매우 중요한 단계이다.

마무리

위 단계에서 인간과 AI의 역할은 아래와 같다:

• 인간 | PR 다듬기 및 병합 요청
• AI | (필요한 경우) PR 본문 작성 시 코드 변경 내용 요약

AI의 작업물에 큰 문제가 없다고 판단되면, 이 과정까지 발생한 임시 파일을 정리하고 GitHub에 PR을 올리는 등의 과정을 진행하면 된다. GitHub 상에서 코드 리뷰도 진행할 것이고, 모든 제반 작업이 끝나면 병합을 진행하면 된다.

논의 사항

다음은 이 순서를 보면서 내가 가졌던 궁금증이다. 애초에 SSD라는 컨셉 자체가 공식적이지 않고 일종의 '국룰'로 통하고 있는 만큼, 나의 질문과 답변 역시 공식적인 성격을 가진다기보다는 개인의 의견이 많이 섞여 있다는 점을 감안하고 보면 좋을 것이다.

왜 이 순서가 통용되는가

먼저 주요 CLI가 승인 및 통제와 관련된 기능을 여럿 제공하고 있기 때문이다. Codex는 Approval modes를, Claude Code는 Permission 등을 제공하여 개발자가 승인한 작업만 실행할 수 있게 하거나, 자율적으로 작업 범위를 조절하도록 하는 등 다양한 권한을 제공하고 있다.

다음으로는 리스크 관리가 용이하기 때문이다. 돌아보면 알겠지만 검증 및 승인 절차를 상당히 많이 포함하고 있다. 설계 과정에서 코드를 변경하지 않는 읽기 전용 계획 수립, 구현 후의 정적 테스트, 그리고 AI의 전반적인 작업을 평가하는 과정까지, 모두 개발자의 의도와 일치하고 있는지를 반복하여 물음으로써 AI가 탈선하지 않게 확인하고 있다. 그리고 구현 이전에 반드시 읽기 전용 설계를 포함함으로써, 시간과 토큰을 소비한 구현을 애써 되돌리는 일이 없게 미리 예방하는 목적도 있다.

소규모 작업에는 이 중 일부만 진행해도 되는가

그렇다고 볼 수도 있지만 아닌 것 같기도 하다.

아무래도 그냥 버튼 디자인이나 간단한 로직 리팩터링에 7단계 과정을 다 거치기에는 좀 복잡해 보이는 것도 사실이다. 그래서 만약 조직 내에서 유연성을 좀 확보하고 싶다면, 1단계 '문제 정의' 과정에서 볼륨이 크지 않을 때 바로 4단계 '구현'으로 넘어가는 것도 가능은 하겠다. 다만 엄밀히 말하면 1단계에서 4단계로 넘어간 게 아니라, 1단계부터 3단계를 좀 축약하여 진행한 것이라고 보는 게 맞을 것이다.

아무튼 일은 유연하게 진행하는 게 중요하겠다.

CLI 스킬 테스트는 코드 테스트와 뭐가 다른가

코드 테스트는 코드가 주어진 입력에 의도한 결과를 내는지, 즉 로직대로 돌아가는지 평가한다. 그러나 CLI 스킬 테스트는 아래와 같은 것들을 평가한다:

• 이 작업에서 사용자가 의도한 스킬이 트리거되었는가
• 기대한 명령이 실행되었는가
• 금지된 변경을 실행하였는가
• 최종 결과가 초기 설계와 전역 공통 규칙을 만족하는가

이런 것들은 입력대로 출력이 반드시 나올 것을 기대하는 결정적(deterministic)인 코드 테스트와 다르다. LLM 기반 AI는 같은 입력을 넣어도 답변이 다르게 나오는 비결정적(non-deterministic)인 특징을 지니기 때문이다. 비결정적인 만큼 검증과 통제를 확실하게 해야만, 부작용과 문제를 사전에 확실히 방지할 수 있다.

과정 중 생성되는 임시 문서도 영구적으로 보존해야 하는가

AI가 일련의 과정을 진행하면서 상당히 많은 Markdown 문서가 생성된다. 읽기 전용 설계 단계에서 발생하는 계획서 등이 대표적인 사례다. 그렇다면 이 문서들을 PR 또는 Git 저장소에 영구적으로 포함해야 할까?

상황에 따르지만 보통은 '아니다'로 결론을 내릴 수 있는 듯하다. 보통 영구적으로 보존하는 것은 코드 컨벤션과 같은 언제 어느 상황에서도 모든 코드베이스에 적용되는 전역 규칙들이다. 반면, 위에서 말한 임시 문서들은 특정 작업에만 종속되어 있기 때문에 전역적이라고는 보기 어렵다. 이런 지역적 문서들을 전부 다 저장소에 포함하게 되면, 변경 사항이 매우 많아져서 코드 리뷰하는 사람이 보기에 매우 불편하며, 향후 다시 재사용될 가능성도 높지 않다.

따라서 이 문서들은 작업 중에만 사용하고, 가능하면 PR을 준비할 때 본문 작성에 활용하는 것을 마지막으로, PR에는 포함하지 않는 게 좋다는 것이 나의 결론이다.

GitHub에서 코드 리뷰를 하는데 CLI에서도 또 해야 하나

요즘 GitHub에서 작업을 하는 경우, 많은 분들이 Gemini Code Assist나 CodeRabbit과 같은 리뷰 전문 에이전트를 파트너로 활용하고 계실 것이다. 그런데 위 과정에서는 로컬 환경에서도 빡빡하게 리뷰 및 검증을 진행하고 있다. 그럼 이런 궁금증이 들 수 있다: "로컬 CLI와 GitHub 양쪽에서 굳이 중복으로 리뷰를 해야 하나?"

이에 대한 개인적인 결론은 "중복 리뷰 할 만하나 필수는 아니다"이다. 로컬 리뷰와 PR 리뷰는 아래와 같은 차이를 가진다:

• 개발 직후 로컬에서 리뷰 vs. PR 올라간 후에 리뷰
• 커밋되지 않은 변경 사항 위주 리뷰 vs. 저장소, 브랜치, PR 문맥을 고려하여 리뷰
• 로컬 개발 환경 사용 vs. GitHub Actions 등 CI/CD 환경 사용

차이가 아주 크다고 보기는 어렵지만 완전히 동일한 과정도 아니므로, 작업 볼륨이 크지 않다면 둘 중 하나만 진행해도 무방할 수 있다.

이슈 및 브랜치 생성, PR 요청도 모두 AI가 할 수 있는가

그럴 가능성이 높다. (물론 사용하는 CLI 서비스나 환경에 따라 다를 순 있다.) 애초에 이론적으로 코드 수정도 할 수 있고 변경 내용을 요약해 자연어로 정리할 수도 있으며 MCP 서버를 통해 외부에서 명령 수행도 되는 CLI 에이전트가 브랜치 하나 파고 PR 요청 쓰는 건 전혀 어려운 일이 아니다.

다만 팀 내에서 자동화를 어디까지 할지 합의하는 게 과제일 것이다. 어떤 팀은 그래도 PR 요청은 각자가 변경 내용에 책임을 질 수 있게 직접 검토하고 작성하자고 합의할 수 있는 일이고, 효율을 중시하는 팀이라면 PR 요청까지 자동화할 수 있을 것이다.

마무리

최근 개인적으로 절실히 느끼는 점 중 하나는 어떤 도구를 쓰더라도 그걸 왜 써야 하는지를 잘 알아야 한다는 것이다.

이 라이브러리를 왜 썼는지, 이 기능을 구현할 때 왜 코드를 이렇게 쳤는지, 다른 방식은 왜 선택하지 않았는지 등... 그리고 이러한 접근 - 명확한 근거에 기반하여 결정하는 것 - 은 사실 어떻게 보면 굉장히 당연하고 자연스러운 마음가짐이며 무엇보다도 프로그래밍이 아닌 다른 업무를 볼 때에도 반드시 지켜야 한다.

예를 들어, 내가 어떤 회사에 입사했다고 쳤을 때, 그 회사에서 그렇게 해 왔으니까 나도 그렇게 해야 겠다고 생각하는 게 아니라, 그 방식이 현 시점에서도 여전히 적절한지 그 근거를 찾으며 생각해보고, 그렇지 않다면 워크플로의 개선을 요구할 수 있다는 거다. 그리고 보통 이렇게 먼저 문제를 찾아 개선을 이루는 사람들을 '주인 의식이 있다'고 표현하는 것 같다. 실제로도 보통 이러한 문제들은 기존 관행을 그대로 유지하는 경우에 자주 발생하기도 하고...

아무튼 결론은 이유 없이 행동하지 말자는 것이다. 에이전트와 일할 때에도 왜 에이전트를 사용하면 더 효율적인지, 에이전트에게 왜 이렇게 일을 시켜야 하는지 그 이유를 알아야 그만큼 에이전트를 더 잘 다룰 수 있을 것이다.

<손자병법>에서 유래한 '지피지기 백전불태'라는 말이 괜히 나온 게 아닐 것이다. 잊지 말자.

참고 문헌

• StackOverflow. 2025 Stack Overflow Developer Survey. 링크.