인공지 Intelligence (AI)는 우리가 소프트웨어를 구축하는 방식을 근본적으로 변화시켰습니다.

오늘날에는 AI 어시스턴트와 대화하는 것만으로 전체 REST API, React 대시보드, 또는 완전한 SaaS 애플리케이션까지 생성하는 것이 가능합니다. 몇 번의 프롬프트(Prompt)를 거치고 나면 인증(Authentication), 데이터베이스(Database), 테스트(Tests), 그리고 배포 스크립트(Deployment scripts)가 갖춰지게 됩니다.

이러한 워크플로우(Workflow)는 Vibe Coding*로 알려지게 되었습니다.
그것은 빠르고, 즐거우며, 솔직히 말해서 믿기지 않을 정도로 인상적입니다.

하지만 AI로 프로덕션 시스템(Production systems)을 구축하며 몇 달을 보낸 후, 저는 흥미로운 점을 발견했습니다. 이제 과제는 코드를 생성하는 것이 아닙니다. 과제는 프로젝트가 성장함에 따라 일관성(Coherent)을 유지하는 것입니다.

이것이 바로 AWS Kiro에 의해 대중화된 Spec Coding이 등장하는 지점입니다. AI를 단순한 코드 생성기로 취급하는 대신, AI를 소프트웨어 엔지니어(Software engineer)로 취급합니다. 즉, 어떻게(How) 구축할지 결정하기 전에 **무엇(What)**을 구축해야 하는지를 먼저 이해하는 엔지니어 말입니다.

왜 이러한 변화가 중요한지 살펴보겠습니다.

Vibe Coding이란 무엇인가?

Vibe coding은 소프트웨어가 거의 전적으로 AI와의 대화를 통해 구축되는 비공식적인 개발 스타일입니다. 워크플로우는 보통 다음과 같은 형태를 띱니다:

"사용자 관리를 위한 REST API를 생성해줘."

AI가 프로젝트를 생성합니다. 그다음:

"JWT 인증을 추가해줘."

몇 초 후:

"SQLite 대신 PostgreSQL을 사용해줘."

그다음:

"React 관리자 대시보드를 생성해줘."

이런 식으로 계속됩니다. 프로젝트는 프롬프트를 통해 자연스럽게 진화하며, 당신은 본질적으로 코드를 작성할 줄 아는 AI와 브레인스토밍(Brainstorming)을 하고 있는 것입니다.
프로토타입(Prototypes)을 만드는 데 있어서 이는 거의 마법과 같습니다.

왜 모두가 이를 좋아하는가

vibe coding이 이토록 인기를 얻게 된 데에는 타당한 이유가 있습니다. 아이디어에서 작동하는 애플리케이션(Application)에 이르는 시간을 극적으로 단축해주기 때문입니다.

프로젝트 구조(Project structures), 의존성 주입(Dependency injection), 인증(Authentication), Docker, CI/CD, 또는 인프라(Infrastructure)를 설정하는 데 몇 시간을 소비하는 대신, 단순히 요청하기만 하면 몇 분 내에 만질 수 있는 결과물을 얻게 됩니다.

이러한 점 때문에 vibe coding은 특히 다음과 같은 경우에 효과적입니다:

• MVP (Minimum Viable Products)
• 새로운 프레임워크 학습 (Learning new frameworks)
• 개념 증명 (Proof of Concepts)
• 내부 도구 (Internal tools)
• 개인 프로젝트 (Personal projects)

피드백 루프 (Feedback loop)가 믿을 수 없을 정도로 짧습니다: 생각하고, 프롬프트(prompt)를 입력하고, 테스트하고, 개선합니다. 실험을 위해서는 이보다 더 나은 방식은 찾기 어렵습니다.

당신의 아키텍처가 채팅 속에 존재합니다

6개월 뒤에 프로젝트에 합류한다고 상상해 보세요.
아키텍처는 어디에 문서화되어 있습니까? 왜 다른 대안 대신 DynamoDB를 선택했습니까? 왜 이벤트는 비동기(asynchronously)로 발행됩니까? 왜 어떤 서비스는 CQRS를 사용하고 다른 서비스는 사용하지 않습니까?

vibe coding 환경에서는 이러한 답변들이 종종 이전 대화 속에만 존재합니다. 만약 그 채팅들이 사라진다면, 소프트웨어 뒤에 숨겨진 논리(reasoning)도 함께 사라집니다.

프롬프트 엔지니어링 (Prompt Engineering)이 프로젝트 관리가 됩니다

애플리케이션이 성장함에 따라, 프롬프트는 점점 더 복잡해집니다.

다음과 같이 요청하는 대신:

OAuth 인증을 추가해줘.

당신은 다음과 같이 프롬프트를 작성하기 시작합니다:

기존의 계층형 아키텍처 (layered architecture)를 보존하고, 우리의 리포지토리 패턴 (repository pattern)을 준수하며, 현재의 DTO 컨벤션을 사용하고, 기존 API와의 하위 호환성 (backward compatibility)을 유지하면서, Terraform 모듈을 업데이트하고, 테스트를 생성하며, 변경 사항을 문서화하면서 OAuth 인증을 추가해줘.

결국, 당신은 더 이상 기능을 설명하는 것이 아니라, 매번 프로젝트의 전체 컨텍스트 (context)를 재구성하고 있는 것입니다.

Spec Coding의 등장

Spec Coding은 완전히 다른 접근 방식을 취합니다.
코드를 즉시 생성하는 대신, **지식 (knowledge)**을 생성하는 것부터 시작합니다.

AI는 먼저 다음 사항들을 정의합니다:

• 무엇을 구축해야 하는가
• 그것이 왜 존재해야 하는가
• 어떻게 설계되어야 하는가
• 어떻게 구현될 것인가

그다음에야 비로소 코드 작성을 시작합니다.
이 방식이 더 느리게 들릴 수도 있지만, 장기적으로는 대규모 프로젝트를 훨씬 더 빠르게 움직이게 만듭니다.

Kiro의 철학

Kiro는 **명세 기반 개발 (Specification-Driven Development)**을 중심으로 구축되었습니다.
단순히 대화 기록에만 의존하는 대신, 프로젝트 지식을 버전 관리되는 아티팩트 (artifacts)로 저장합니다.

AI에게 모든 것을 "기억"하라고 요청하는 대신, 코드베이스와 함께 진화하는 구조화된 문서 (structured documentation)를 제공합니다.
이 명세 (specification)는 프로젝트의 단일 진실 공급원 (single source of truth)이 됩니다.

실질적인 예시

AWS Dead Letter Queue (DLQ) Redrive 애플리케이션을 구축한다고 가정해 보겠습니다.

전통적인 Vibe Coding 방식에서는 단순히 다음과 같이 작성할 수 있습니다:

사용자가 SQS Dead Letter Queue에서 메시지를 검사하고 다시 드라이브 (redrive)할 수 있는 대시보드를 구축해줘.

그러면 AI는 즉시 코딩을 시작할 것입니다.

Kiro를 사용하면 워크플로우가 매우 다르게 나타납니다.

1단계 — 요구사항 (Requirements)

코드를 생성하기 전에, Kiro는 기능적 요구사항 (functional requirements)을 정의합니다.

예를 들어:

기능적 요구사항 (Functional Requirements)

• 사용 가능한 DLQ 보기
• 실패한 메시지 검사
• 메시지 검색
• 선택한 메시지 다시 드라이브 (redrive)
• 모든 메시지 다시 드라이브 (redrive)
• CloudWatch 메트릭 (metrics) 표시
• 처리 이력 표시

비기능적 요구사항 (Non-functional Requirements)

• IAM 인증
• 감사 로깅 (Audit logging)
• 멀티 계정 지원
• 반응형 UI
• 고가용성 (High availability)

모든 것이 명시적입니다. 프롬프트 (prompts) 내부에 숨겨진 것은 아무것도 없습니다.

2단계 — 설계 (Design)

다음은 아키텍처 (architecture) 단계입니다. 구현 과정에서 아키텍처를 즉흥적으로 만들어내는 대신, Kiro는 사전에 기술 설계 (technical design)를 제안합니다:

Frontend
├── React
├── Material UI
...

이제 향후 모든 구현은 동일한 아키텍처 비전을 공유하게 됩니다.

3단계 — 작업 (Tasks)

명세 (specification)가 검증되면, 구현은 다음과 같이 관리 가능한 작업 단위로 분해됩니다:

• REST API 생성
• SQS 서비스 구현
• CloudWatch 통합 생성
• React 대시보드 구축
• 인증 구현
• 단위 테스트 (unit tests) 작성
• 문서 생성

각 작업은 하나 이상의 요구사항을 참조하므로, 추적성 (traceability)이 자동으로 확보됩니다.

4단계 — 코드 생성 (Code Generation)

이제서야 Kiro는 코드를 생성합니다.
차이점은 미묘하지만 매우 중요합니다. AI는 더 이상 즉흥적으로 행동하는 것이 아니라, 승인된 설계를 구현하는 것입니다.

온보딩 (Onboarding)이 더 쉬워집니다

새로운 개발자가 당신의 프로젝트에 합류하는 상황을 상상해 보세요. Slack 메시지나 오래된 AI 대화 기록을 뒤지는 대신, 그들은 단순히 요구사항(requirements), 아키텍처(architecture), 작업(tasks), 그리고 그 이면에 담긴 결정 사항들을 열어보기만 하면 됩니다. 한 시간도 채 되지 않아 그들은 프로젝트를 이해하게 됩니다. 이는 매우 귀중한 가치입니다.

문서화 (Documentation)가 사후 작업이 아닌 과정이 됩니다

가장 큰 이점 중 하나는 문서화가 더 이상 마지막에 작성하는 것이 아니라, 구현(implementation)이 시작되기도 전에 생성된다는 점입니다. 그 결과, 요구사항은 동기화된 상태를 유지하고, 아키텍처는 문서로 남으며, 구현은 명세(specification)를 따르게 됩니다. 문서화는 나중에 덧붙여지는 별개의 활동이 아니라 개발의 일부가 됩니다.

두 접근 방식의 비교

권장하는 워크플로우 (Workflow)

두 방식 중 하나를 선택하는 대신, 두 방식을 결합하세요.

1단계 — 탐색 (Explore). Vibe coding을 사용하여 다음과 같은 질문에 빠르게 답하세요: 이 아이디어가 실행 가능한가? 어떤 기술을 사용해야 하는가? 이것을 구축할 수 있는가? 트레이드오프 (trade-offs)는 무엇인가? 이 단계에서는 속도가 중요합니다.

2단계 — 공식화 (Formalize). 개념이 가치 있다고 증명되면, 요구사항을 작성하고, 아키텍처를 정의하며, 제약 사항(constraints)을 식별하고, 구현 작업(implementation tasks)을 생성하세요. 이것이 프로젝트의 기반이 됩니다.

3단계 — 구축 (Build). 이제 AI가 기억(memory)이 아닌 명세(specification)로부터 코드를 생성하게 하세요. 그러면 더 일관되고, 리뷰하기 쉬우며, 유지보수하기 쉽고, 확장하기 쉬운 코드를 얻을 수 있습니다.

마치며

AI는 소프트웨어 개발 속도를 극적으로 높였지만, 소프트웨어 엔지니어링 (software engineering)은 결코 코드 작성만을 의미하지 않았습니다. 그것은 요구사항을 이해하고, 아키텍처 결정을 내리며, 팀원들과 협업하고, 의도를 문서화하며, 시스템을 수년간 유지보수하는 것에 관한 것입니다.

그것은 탐색을 위한 바이브 코딩 (Vibe Coding)이고, 엔지니어링을 위한 스펙 코딩 (Spec Coding)입니다. AI는 단순히 우리가 코드를 더 빨리 작성하도록 돕는 것에 그치지 않고, 더 나은 소프트웨어를 구축할 수 있도록 도와야 하며, 바로 그 지점이 Kiro와 같은 도구들이 업계를 앞으로 나아가게 만드는 곳입니다.

Photo by Yaroslav Muzychenko on Unsplash