1. 배경 — 스타트업의 속도와 생산성의 간극
히로인스는 4060세대 엄마들을 위한 버티컬 소셜 플랫폼입니다. 일상 기록과 응원 커뮤니티로 시작해, 현재는 커머스까지 확장하고 있습니다.
저희는 아직 초기 단계의 스타트업입니다. 하루에도 수많은 가설을 세우고, 실험하고, 실패합니다. 그 속도는 생존과 직결되지만, 리소스는 늘 부족하죠.
그래서 개발 리더로서 가장 많이 했던 고민은 이겁니다.
"이 작은 팀에서, 어떻게 팀 전체의 생산성을 끌어올릴 수 있을까?"
LLM 시대가 열리면서 그 고민은 자연스럽게 이렇게 바뀌었습니다.
"AI를 통해, 개발 프로세스 자체를 자동화할 수는 없을까?"
2. Cursor Composer 시절 — 자동화의 첫 시도와 한계
AI 코딩툴이 막 등장하던 시절, 저희는 Cursor의 Composer 기능을 활용해 첫 번째 실험을 시작했습니다. 동시에 여러 파일을 수정할 수 있었죠.
그래서 저희는 백엔드 E2E 자동화를 시도했습니다. 명확한 패턴이 있는 영역이라 성공 가능성이 높아 보였지만, 결과는 성공도, 실패도 아닌 어중간한 상태였습니다.
코드는 나오지만, 결국 리뷰는 사람이 해야 했습니다. 팀원들은 이렇게 말했죠.
"결국 내가 짜는 거랑 뭐가 달라요?"
그래서 Agent를 공부하기 시작했습니다.
3. ReAct 프레임워크 — 자동화의 본질은 'Planning'이었다
이후 Agent 아키텍처를 공부하다가, ReAct(Reasoning + Acting) 프레임워크를 접했습니다.
ReAct Agent architecture
ReAct의 기본 원리는 다음과 같습니다.
- 유저의 입력이 들어오면, 모델은 먼저 Reasoning을 하며 Planning을 세운다.
- 그 계획에 따라 Action(도구 호출)을 수행한다.
- 그 결과(Observation)를 기반으로 다시 Reasoning Loop를 돈다.
직접 구축도 시도해보고 했지만, 이미 만들어진 바퀴를 다시 발명할 필요는 없어보였습니다
초기 Planning만 잘 설정하면 원하는 flow를 만들 수 있다고 생각했습니다.
"Tool calling은 이미 충분히 잘 되어 있다. 내가 통제해야 할 건, 바로 이 Planning 단계다."
4. Cursor Agent 실험 — Todo-list 기반 Planning 제어
그래서 Cursor Agent가 출시되자마자, 저는 Todo-list 기반 Planning 제어 실험을 시작했습니다.
핵심 아이디어는 이겁니다.
"AI에게 계획을 추론하게 하지 않는한다. 내가 준 계획표대로 진행하며 한 번에 모든 걸 시키지 말고, 단계별로 필요한 문서만 읽게 하고, 각 단계마다 context를 유지시키자."
이를 위해
- Todo-list를 작업 단위(step)로 쪼개고,
- 각 단계가 실행될 때마다 필요한 문서만 로드,
- 실행 후에는 결과를 요약해 다음 단계로 전달했습니다.
- 단계 종료후 해당 Todo-list를 다시 읽어 전체 흐름을 유지하게 했습니다.
이 구조를 통해 모델은 전체 맥락을 한 번에 다루지 않아도 일관된 논리 흐름을 유지하며 일할 수 있었습니다.
지금 돌이켜보면, 이게 바로 초기형 Context Engineering이었습니다. 다만 한계도 명확했습니다.
- context가 길어지면 checkbox 리마인드를 놓침
- 이전 단계에서 생긴 오류가 누적되어 모델이 길을 잃음
- 결국 사람이 개입해야 루프가 정리됨
즉, 자동화의 뼈대는 완성됐지만, 스스로 자가복구할 수는 없는 구조였습니다.
5. Claude Code의 등장 — 구조화된 반자동화로
이후 Claude Code를 만나면서 전환점이 생겼습니다. Max 요금제 덕분에 토큰 걱정 없이 테스트할 수 있었고, 무엇보다 Todo-list 기능이 기본 내장되어 있었습니다. 게다가 CLI 기반이라서, 이제 IDE가 아닌 워크플로우 레벨에서 제어 가능한 모듈형 자동화를 만들 수 있었습니다.
그때의 목표는 명확했습니다.
"AI가 코드를 대신 짜는 게 아니라, 우리가 매일 하는 개발 워크플로우를 반자동화 가능한 시스템으로 만든다."
6. Claude Code팀에서 말한 Vibe Coding
Claude Code 팀은 "Vibe Coding in Production" 발표에서 아래 내용들을 이야기했습니다.
① 신뢰의 방향을 바꿔라
LLM 할루시네이션은 막을 수 없지만, "신뢰할 수 있는가?"가 아니라 "어떻게 하면 책임감 있게 신뢰할 수 있는 시스템을 만들까?"로 질문을 바꿔야 한다.
② 격리하라 — 리프 노드에서 코딩하라
AI가 실패하는 이유는 대부분 사이드이펙트 관리 실패 때문이다. 따라서 트리 구조상 리프 노드(Leaf Node)에서만 코딩하라.
7. 우리의 해석 — 책임감 있는 신뢰 시스템 : Spec
개발은 본질적으로 요구사항에 담긴 수많은 암묵적 컨텍스트를 개발 레이어에서 기계어 레이어까지 차례로 풀어내는 과정이라고 보았습니다. 업이 성숙해지면서 추상화 레이어는 계속 위로 올라갔고, 이제는 어셈블리를 몰라도 개발에 지장이 없으며 과거의 성능 이슈도 대체로 치명적이지 않게 되었습니다.
그렇다면 앞으로 지수적으로 증가할 코드 복잡도를 감당하려면 코드 레이어보다 한 단계 위의 추상화가 필요하다고 판단했습니다. 그래서 저희는 Spec을 중심에 두었습니다. 요구사항의 암묵지를 Spec으로 명시화했고, 코드는 그 Spec의 구현체로 다루었습니다. 다시 말해, “Spec이 곧 코드”인 시스템을 지향했습니다.
코드 위에 Spec 레이어를 팀의 단일 진실(Single Source of Truth)로 세우고, 설계→구현→검증의 루프를 Spec 중심으로 돌립니다.
8. 우리의 해석 — 모든 것을 리프화하라
저희는 AI 시대에는 AI를 중심으로한 아키텍쳐가 재 설계되어야한다고 생각합니다. 그래서 클로드팀에서 말한 리프노드 바이브 코딩의 생각을 뒤집어 봤습니다.
"리프 노드에서만 바이브 코딩해야 한다면, 차라리 모든 걸 리프 단위로 만들면 어떨까?"
즉, 코어 인프라를 제외한 모든 기능을 리프 단위로 분리하고, 사이드 이펙트없이 독립적인 구조로 설계했습니다. 물론 사이드 이펙트가 필요한 영역도 있기에 그 부분도 따로 설계하여 구조를 잡았습니다.
이렇게 하면 AI는 각 기능을 독립적으로 이해하고 실행할 수 있게 됩니다. 결국 AI가 다루는 단위가 "맥락이 완결된 최소 기능 단위"가 되는 셈이죠. 아키텍쳐 단에서도 Context 엔지니어링, 즉 Context 압축을 고려해야한다고 판단했습니다.
9. Spec Driven Development (SDD) — 자동화를 위한 언어
이 구조를 정리한 것이 바로 Spec Driven Development(SDD)입니다. 저희는 개발 문서를 세 가지로 구분해 Git에서 관리합니다.
SDD Document
- Task 문서: 주어진 요구사항을 정의하고, 설계하고, 엣지케이스를 정리합니다.
- Feature 문서: 기능의 정체성을 유지하기 위한 단일 소스입니다.
- Dev 문서: 코드 수준의 논리 흐름을 mermaid, 테스트 케이스 등으로 상세화합니다.
이제 저희는 자연어로 된 문서조차 코드의 일부로 취급합니다.
10. 회고 — 고통에서 확신으로
처음엔 솔직히 힘들었습니다. 개발자들은 문서 작업을 싫어하고, 초기에는 문서 구조화도 없으니 매일 시도와 수정의 연속이었죠.
하지만 한 사이클이 돌고 나니, 팀의 반응은 완전히 달라졌습니다.
1️⃣ 안정감: QA에서 논리 불일치가 줄고, 설계 실수도 감소 2️⃣ 속도: 3명 3주 걸리던 작업을 1명이 1주 내에 완성 3️⃣ 이해도: 프론트 개발자도 백엔드 구조를 이해할 수 있게 됨
즉, 문서를 통한 구조화가 속도를 늦춘 게 아니라, 오히려 개발 전체를 가속화시킨 결과였습니다.
11. 다음 단계 — 자동화의 완성으로
현재 저희는 세 가지 방향으로 실험을 확장 중입니다.
1️⃣ Spec 문서 반자동화 — 설계서 생성 및 업데이트 자동화 2️⃣ 프론트엔드 E2E 자동화 — 백엔드 수준의 피드백 루프 확장 3️⃣ 서버 기반 병렬 Claude 워크플로우 — 개발자 PC가 아닌 서버에서 다중 작업 처리
이 세 단계를 완성하면 "설계 → 코드 → 테스트 → 리뷰"의 전체 루프가 자동화될 것입니다.
12. 우리가 꿈꾸는 개발 문화
우리가 꿈꾸는 세상은 단순히 '딸깍 배포'가 아닙니다.
"AI가 반복을 줄이고, 개발자는 진짜 어려운 문제에 집중하는 환경을 만든다."
AI가 문서화, 코드 생성, 테스트를 도와주면 신입 개발자도 빠르게 기여할 수 있고, 시니어 개발자는 인프라, 최적화, 아키텍처 같은 더 높은 수준의 문제 해결에 집중할 수 있습니다.
결국 Spec Driven Development는 단순한 자동화 전략이 아니라, 팀 전체의 기술 허들을 낮추는 시스템 설계 철학입니다.
13. 마무리
히로인스의 자동화 여정은 아직 초입 단계입니다. 하지만 확실히 느낍니다.
"AI가 코드를 짜는 게 아니라, 개발자가 더 잘 일할 수 있는 구조를 만든다."
이게 저희가 말하는 Spec Driven Development의 핵심 가치입니다.
