바이브코딩의 다음 단계는 스펙코딩이다

2026.09.19

#바이브코딩 #스펙코딩 #AI코딩 #명세 #AI리터러시 #에이전틱AI

바이브코딩의 다음 단계는 스펙코딩이다 블로그 커버 이미지 — AI가 실행을 잘할수록, 사람의 일은 더 선명한 명세를 쓰는 쪽으로 이동한다.

바이브코딩이라는 말이 처음 퍼졌을 때, 나는 꽤 좋은 표현이라고 생각했다.

코드를 아주 정확히 모르는 사람도 만들고 싶은 것을 말하면 AI가 화면을 만들고, 함수를 만들고, 오류를 고치고, 배포까지 도와준다. 머릿속에 있던 감각이 바로 산출물로 바뀐다. 예전에는 개발 환경을 세팅하다가 지치고, 프레임워크 문서 앞에서 멈췄던 사람이 이제는 “일단 만들어보는” 단계까지 갈 수 있다.

이 변화는 작지 않다. 특히 비개발자에게는 더 그렇다. 기획자, 컨설턴트, 교육 담당자, 연구자, 행정 실무자가 작은 대시보드나 자동화 도구를 직접 만들어볼 수 있게 됐다. 내가 요즘 관심 있게 보는 지점도 여기다. AI 코딩은 개발자만의 문제가 아니라, 일하는 사람이 자기 업무를 도구로 바꾸는 문제다.

그런데 여기서 한 단계 더 가야 한다.

바이브코딩은 시작으로는 좋다. 하지만 조직에서 쓰기에는 부족하다. 감으로 만들고, 눈으로 확인하고, 되는 것 같으면 넘어가는 방식은 프로토타입에는 잘 맞는다. 문제는 업무에 붙는 순간부터다. 누가 써도 같은 결과가 나와야 하고, 예외가 처리되어야 하고, 개인정보가 새면 안 되고, 권한이 나뉘어야 하고, 나중에 다른 사람이 고칠 수 있어야 한다.

이때 필요한 것은 더 멋진 프롬프트가 아니다.

명세다.

그래서 나는 바이브코딩의 다음 단계가 스펙코딩이라고 본다.

바이브코딩은 감각을 실행으로 바꿨다

바이브코딩의 장점은 분명하다. 만들고 싶은 느낌을 빠르게 실행으로 바꾼다.

“이런 대시보드를 만들고 싶어.”

“학생 데이터를 넣으면 위험 신호를 보여주는 화면이 필요해.”

“강의 평가 결과를 요약하고, 개선 과제를 뽑아주는 도구를 만들고 싶어.”

예전에는 여기서 바로 개발 언어, DB, API, 배포 환경 이야기가 나왔다. 비개발자는 대부분 그 앞에서 멈췄다. 지금은 다르다. AI에게 말하면 초안이 나온다. 처음부터 완벽하지는 않아도, 볼 수 있는 무언가가 생긴다. 이건 굉장히 중요하다. 추상적인 아이디어가 화면과 동작으로 바뀌면 대화의 수준이 달라진다.

하지만 바이브코딩은 그 이름 그대로 감각에 기대는 방식이다. 사용자가 “이런 느낌”을 말하고, AI가 그럴듯한 결과를 만든다. 문제는 그럴듯함과 맞음이 다르다는 데 있다.

버튼이 눌린다고 맞는 시스템은 아니다. 차트가 그려진다고 맞는 분석은 아니다. 로그인 화면이 있다고 안전한 서비스는 아니다. 글자가 예쁘게 정리됐다고 올바른 판단 근거가 생긴 것도 아니다.

AI는 감각을 산출물로 바꾸는 데 강하다. 하지만 그 산출물이 조직의 요구와 제약을 만족하는지는 별도의 문제다.

AI가 코드를 잘 짤수록, 명세를 못 쓰는 조직은 더 위험해진다

예전에는 요구가 흐릿하면 개발 속도가 느려졌다. 개발자가 다시 물어봤고, 회의가 길어졌고, 일정이 밀렸다. 느리다는 것은 답답했지만, 동시에 일종의 안전장치이기도 했다. 애매한 요구는 쉽게 실행되지 않았다.

AI 코딩 시대에는 이 안전장치가 약해진다.

요구가 애매해도 AI는 뭔가 만든다. 제약이 빠져도 AI는 합리적인 척 채운다. 예외 조건을 말하지 않아도 기본값을 상상한다. 조직의 규정, 팀의 암묵지, 보안 기준, 승인 절차를 모르면 모르는 대로 일반적인 패턴을 가져온다.

그래서 AI가 코드를 잘 짤수록 위험해지는 조직이 있다. 개발 역량이 부족한 조직이 아니라, 명세 역량이 부족한 조직이다.

명세가 없으면 AI는 추측한다. 추측이 빨라지면 산출물도 빨라진다. 산출물이 빨라지면 검토할 것이 늘어난다. 검토 기준이 없으면 사람은 결국 화면을 보고 판단한다.

“돌아가네.”

이 말이 가장 위험하다.

업무 시스템에서 중요한 것은 돌아가는지가 아니라, 어떤 조건에서 어떻게 돌아가야 하는지다. 누구에게 보여야 하고, 누구에게 보이면 안 되는지. 어떤 데이터는 저장하고, 어떤 데이터는 저장하지 말아야 하는지. 오류가 나면 재시도할지, 멈출지, 사람에게 넘길지. 결과가 맞다는 것을 무엇으로 확인할지.

이런 것들이 명세다.

스펙코딩은 코드를 쓰는 일이 아니라 조건을 쓰는 일이다

스펙코딩이라는 말을 코드 작성법처럼 이해하면 조금 빗나간다.

내가 말하는 스펙코딩은 코드를 잘 쓰는 기술이 아니다. AI가 코드를 쓰기 전에 사람이 무엇을 명확히 해야 하는지 정리하는 기술이다.

스펙에는 최소한 이런 것들이 들어가야 한다.

사용자는 누구인가
어떤 문제를 해결해야 하는가
성공한 상태는 무엇인가
입력 데이터는 어디서 오고 어떤 형식을 갖는가
어떤 예외가 반드시 처리되어야 하는가
어떤 권한과 보안 제약이 있는가
어떤 결과는 절대 자동 실행하면 안 되는가
완료 여부를 무엇으로 검증할 것인가
나중에 누가 유지보수할 것인가

이건 개발자만의 언어가 아니다. 오히려 기획자, 컨설턴트, 교육과정 개발자, 행정 실무자가 더 잘해야 하는 언어다. 왜냐하면 이들은 업무의 목적과 제약을 알고 있기 때문이다.

컨설팅 보고서도 비슷하다. 보고서 작성 자체보다 더 중요한 것은 앞단의 요구정의다. 이 기관이 진짜 묻고 있는 것이 무엇인지, 표면의 요청과 실제 문제가 어떻게 다른지, 어떤 제약 안에서 실행 가능한 대안을 내야 하는지 정리해야 한다. 교육과정 개발도 마찬가지다. 교과목 목록을 만드는 것보다 먼저 해야 할 일은 학습자, 역량, 성취기준, 평가 방식, 운영 조건을 맞추는 일이다.

AI 시대의 스펙코딩은 이런 능력을 소프트웨어 작업으로 확장한 것이다.

Spec-driven development가 다시 주목받는 이유

이 흐름은 이미 개발 쪽에서도 나타나고 있다.

GitHub는 Spec Kit을 소개하면서, coding agent를 검색엔진처럼 대하면 안 되고 “literal-minded pair programmer”처럼 다뤄야 한다고 설명한다. AI는 패턴 인식에는 강하지만 마음을 읽지는 못한다. 그래서 모호한 프롬프트 대신 specification, plan, tasks, implementation으로 이어지는 구조가 필요하다는 것이다.

Microsoft도 Spec-Driven Development를 AI-native engineering의 접근으로 설명한다. 핵심은 단순하다. 요구, 제약, 수용 기준, 엣지 케이스를 먼저 명시하고, AI가 그 공유된 맥락 위에서 코드와 테스트, 산출물을 만들게 하자는 것이다. 프롬프트를 먼저 던지고 나중에 맞추는 방식이 아니라, 먼저 맞춘 뒤 실행을 가속하는 방식이다.

Thoughtworks도 spec-driven development를 2025년에 떠오른 AI-assisted engineering practice로 다룬다. 여기서 중요한 대목은 spec이 단순한 PRD가 아니라는 점이다. 좋은 spec은 비즈니스 요구만 적은 문서가 아니다. 목표 시스템의 동작, 제약, 도메인 언어, 검증 기준까지 담아야 한다.

이건 과거로 돌아가자는 말이 아니다. 두꺼운 요구사항 문서를 만들고 개발을 늦추자는 이야기도 아니다.

오히려 반대에 가깝다. AI가 실행을 빠르게 만들었기 때문에, 명세도 더 작고 자주 업데이트되는 방식으로 바뀌어야 한다. 긴 문서 하나가 아니라, AI와 사람이 함께 계속 갱신하는 살아 있는 작업 기준이어야 한다.

명세는 AI에게 주는 프롬프트가 아니라 조직의 약속이다

여기서 중요한 구분이 있다.

명세를 AI에게 잘 말하기 위한 프롬프트 정도로 보면 부족하다. 명세는 AI를 위한 입력이면서 동시에 사람들 사이의 약속이다.

기획자는 무엇을 원한다고 말한다. 개발자는 그것이 어떤 구조로 가능한지 말한다. 운영자는 어떤 예외가 실제로 많이 생기는지 말한다. 보안 담당자는 어떤 데이터가 위험한지 말한다. 사용자는 어떤 흐름에서 막히는지 말한다.

이 대화가 정리된 결과가 명세다.

AI는 그 명세를 읽고 실행한다. 하지만 명세의 주인은 AI가 아니다. 사람이다. 그래서 좋은 스펙코딩은 프롬프트를 예쁘게 쓰는 일이 아니라, 사람들의 머릿속에 흩어진 기준을 밖으로 꺼내는 일이다.

Anthropic은 effective context engineering을 설명하면서, AI 에이전트에게 필요한 맥락을 어떻게 선별하고 유지할지 강조한다. 프롬프트 한 번 잘 쓰는 문제가 아니라, 어떤 정보를 언제 모델에게 줄 것인지 설계하는 문제라는 뜻이다. OpenAI Agents SDK가 instructions, tools, guardrails, handoffs, tracing을 에이전트 구성 요소로 두는 것도 같은 방향이다. 실행하는 AI가 강해질수록 맥락, 가드레일, 넘김 조건, 추적 가능성이 중요해진다.

명세는 이 모든 것의 출발점이다.

기획자는 사라지는 게 아니라 명세 편집장이 된다

AI가 코드를 잘 쓰면 기획자는 사라질까.

나는 반대로 본다. 기획자는 더 중요해진다. 다만 역할이 바뀐다. 화면을 그리는 사람, 요구사항을 전달하는 사람, 회의록을 정리하는 사람에 머물면 위험하다. 그런 일은 AI가 빠르게 가져간다.

대신 기획자는 명세 편집장이 되어야 한다.

명세 편집장은 모든 요구를 받아 적는 사람이 아니다. 요구를 정리하고, 충돌을 드러내고, 빠진 조건을 묻고, 검증 기준을 세우고, AI가 실행 가능한 단위로 쪼개는 사람이다.

“이 기능 만들어줘”라고 말하는 사람이 아니라, 이렇게 묻는 사람이다.

이 기능의 사용자는 누구인가
성공 조건은 무엇인가
실패하면 어떻게 멈출 것인가
어떤 예외를 반드시 처리해야 하는가
어떤 판단은 사람이 승인해야 하는가
이 결과가 맞다는 것을 무엇으로 검증할 것인가
이번 버전에서 하지 않을 것은 무엇인가

이 질문들이 좋아질수록 AI의 결과도 좋아진다. 반대로 이 질문들이 없으면 AI는 열심히 틀린 방향으로 달린다.

대학 행정과 교육과정 개발에도 같은 문제가 온다

나는 이 논의가 개발 조직에만 머문다고 보지 않는다.

대학 행정에 AI를 붙인다고 해보자. 장학 상담, 민원 응대, 학사 경고 예측, 비교과 추천, 성과지표 대시보드, 보고서 초안 작성 같은 업무는 모두 AI와 잘 맞아 보인다. 실제로 많은 부분이 자동화될 수 있다.

하지만 여기서도 핵심은 산출물이 아니다.

장학 상담 봇을 만든다면, 어떤 학생 정보를 사용할 수 있는가. 어떤 정보는 절대 보여주면 안 되는가. 상담 결과가 학생에게 불이익을 줄 수 있는가. 특정 조건에서는 사람이 확인해야 하는가. 규정이 바뀌면 누가 업데이트하는가. 학생이 이의를 제기하면 로그를 추적할 수 있는가.

교육과정 추천 시스템도 마찬가지다. 학생에게 과목을 추천하는 일은 단순한 추천 알고리즘 문제가 아니다. 학과의 교육목표, 전공역량, 선수과목, 졸업요건, 교원 수급, 지역 산업 수요, 학생의 진로 희망이 얽힌다. 이걸 명세하지 않으면 AI는 그럴듯한 추천을 할 뿐이다.

조직에서 AI를 제대로 쓰려면 “AI가 무엇을 만들 수 있나”보다 먼저 “우리는 무엇을 기준으로 맞다고 볼 것인가”를 정해야 한다.

스펙코딩은 비개발자의 AI 리터러시다

그래서 스펙코딩은 개발자만의 방법론이 아니다.

비개발자에게 더 중요한 AI 리터러시가 될 수 있다. AI에게 일을 맡긴다는 것은 결과를 받는다는 뜻이 아니다. 요구를 구조화하고, 제약을 명시하고, 검증 기준을 세우고, 책임 경계를 정한다는 뜻이다.

바이브코딩이 “나도 만들 수 있다”는 감각을 열었다면, 스펙코딩은 “조직에서 쓸 수 있게 만든다”는 단계다.

전자는 가능성의 언어다. 후자는 운영의 언어다.

전자는 빠르게 보여준다. 후자는 오래 버티게 한다.

전자는 개인에게 힘을 준다. 후자는 조직에 기준을 남긴다.

이 차이를 이해하지 못하면 AI 도입은 산출물은 많은데 남는 것이 없는 일이 된다. 대시보드는 생기지만 지표 정의가 없다. 자동화는 생기지만 예외 처리 기준이 없다. 챗봇은 생기지만 책임자가 없다. 보고서는 빨라지지만 판단 기준은 더 흐려진다.

바이브에서 스펙으로 넘어가야 할 때

모든 작업에 무거운 명세가 필요한 것은 아니다. 작은 실험, 개인용 도구, 하루짜리 프로토타입은 바이브코딩으로 충분하다. 오히려 처음부터 명세를 과하게 잡으면 속도가 죽는다.

하지만 다음 조건 중 하나라도 해당하면 스펙코딩으로 넘어가야 한다.

다른 사람이 반복해서 사용할 도구다
개인정보나 민감한 업무 데이터를 다룬다
결과가 의사결정에 영향을 준다
여러 부서의 기준이 얽혀 있다
실패했을 때 책임 소재가 생긴다
나중에 유지보수해야 한다
AI 에이전트가 파일, DB, 외부 시스템을 직접 건드린다

이 순간부터는 “일단 만들어줘”가 아니라 “이 조건을 만족하는 방식으로 만들어줘”가 되어야 한다.

그리고 그 조건은 채팅창 어딘가에 흘러가면 안 된다. 문서로 남아야 한다. 버전이 있어야 한다. 바뀌면 함께 바뀌어야 한다. 테스트와 연결되어야 한다. 검증 기준과 연결되어야 한다.

앞으로 중요한 능력은 산출물 작성이 아니라 요구 편집이다

AI가 좋아질수록 산출물 작성 능력의 희소성은 줄어든다. 글 초안, 코드 초안, 이미지 초안, 보고서 초안은 더 빨리 나온다.

대신 희소해지는 것은 요구를 편집하는 능력이다.

모호한 요청을 실행 가능한 조건으로 바꾸는 능력. 충돌하는 이해관계를 드러내는 능력. 빠진 제약을 묻는 능력. 검증 가능한 성공 기준으로 바꾸는 능력. AI가 해도 되는 일과 사람이 승인해야 하는 일을 나누는 능력.

이건 개발에서도, 컨설팅에서도, 교육과정 개발에서도 같은 구조다.

AI 시대에는 기획자가 사라지는 게 아니다. 산출물 전달자였던 기획자는 약해진다. 하지만 명세를 편집하는 기획자는 더 중요해진다.

바이브코딩은 우리에게 “만들 수 있다”는 자신감을 줬다.

이제 다음 질문으로 가야 한다.

무엇을 만들 것인가.

어떤 조건에서 맞다고 볼 것인가.

누가 승인하고, 무엇을 검증하고, 어디서 멈출 것인가.

그 질문에 답하는 일이 스펙코딩이다.