"코딩 1도 몰라도 된다"는 말이 가장 무섭다: 모아이 ADK 발표 후기

최근 구름에서 열린 에이전트 코딩 세션에 다녀왔다. 발표자는 모아이(Moai) ADK라는 에이전트 개발 키트를 만든 분이었다. 세션은 본인의 실패 경험에서 시작해, 그 실패를 줄이기 위해 어떤 도구와 작업 방식을 만들었는지 설명하는 흐름이었다.

2시간 정도 들었고, 끝나고 나니 몇 가지는 기록해두는 게 좋겠다고 생각했다.

---

1. "AI한테 다 맡겼다가 500달러 날렸습니다"

발표는 2024년 말의 실패 이야기로 시작됐다. 발표자는 와디즈에서 LLM 기반 사주 분석 서비스를 크라우드펀딩했다. 1차는 성공했지만 2차에서 문제가 터졌다.

Cursor에 500달러를 썼는데, AI가 기존 코드를 마음대로 바꿔버렸다고 했다. 분명히 잘 돌아가는 것을 확인했는데 PDF 라이브러리가 어느 순간 교체되어 있었다. LangChain은 마이너 버전만 올라가도 기존 기능이 깨졌다. 70시간 동안 작업했지만 결국 고객에게 100% 환불했고, 1차 프로젝트는 절반의 성공으로 정리했다고 한다.

이 이야기를 들으면서 최근 AI 코딩 도구의 "다 맡기면 된다"는 식의 메시지가 꽤 위험하다고 느꼈다. AI가 코드를 빨리 만들 수 있다는 것과, 서비스 운영 책임까지 대신 져준다는 것은 완전히 다른 문제다.

---

2. LLM보다 하네스가 결과를 더 많이 바꾼다

세션에서 오래 남은 말은 "LLM은 다 고만고만하다"는 표현이었다.

발표자는 OpenAI, Claude, Gemini를 모두 써봤고, 세 모델을 동시에 브레인스토밍시켜 테스트까지 해봤다고 했다. 그의 결론은 단일 LLM의 차이보다 어떤 하네스, 즉 어떤 작업 프레임워크를 얹느냐가 결과를 더 크게 바꾼다는 쪽이었다.

Codex, Gemini, Claude Code의 공식 매뉴얼을 비교해보라는 말도 있었다. 도구마다 제공하는 기능 범위가 다르기 때문이다. Claude Code는 최대 10개 태스크까지 동시에 병렬 수행할 수 있는데, 멀티 에이전트 작업에서는 이 차이가 꽤 크게 느껴진다고 했다.

---

3. 스펙 문서: 에이전트와 사람이 같이 보는 문서

발표자가 실패를 분석하며 찾은 해답은 스펙 문서였다.

PRD는 보통 사람을 위한 문서에 가깝다. 에이전트에는 절차적 지시, 현재 상황, 목표, 제약이 한 장의 마크다운 안에 정리된 문서가 더 잘 맞는다고 했다.

이 부분은 바로 이해됐다. "웹 게임을 만들어라"라고 하면 AI가 서버 배포까지 포함한 게임을 만들 수도 있다. "웹 브라우저에서 돌아가는 클래식 오목 게임"이라고 써야 원하는 방향에 가까워진다. 목적어가 빠지면 AI는 부족한 부분을 확률적으로 채운다.

스펙 문서의 진행 상황을 커밋과 함께 계속 기록해야 한다는 말도 있었다. 이렇게 하면 세션이 끊겨도 어디까지 했는지 파악할 수 있고, 같은 설명을 다시 반복할 일이 줄어든다.

---

4. 신규는 TDD, 기존은 DDD

프로젝트 유형별로 접근을 달리해야 한다는 설명도 실용적이었다.

• 신규 프로젝트 -> TDD (테스트 주도 개발)
• 기존 프로젝트 -> DDD (도메인 주도 개발)

기존 프로젝트를 코드 배경 없이 수정하면 단면만 보고 코어를 건드릴 수 있다. 그래서 먼저 전체 코드 분석, 코드 맵 생성, 기술 스택 고정을 거친 뒤 개발을 시작해야 한다고 했다.

"AI가 분석과 기록은 사람보다 잘한다. 이걸 인정해야 한다"는 말도 기억에 남았다. 사람은 판단과 책임을 맡고, AI에는 문서화와 반복 검증을 맡기는 쪽이 현실적인 분업처럼 보였다.

---

5. 모아이 ADK: 4단계 워크플로우

발표 후반부는 모아이 ADK 소개였다. 발표자가 본인이 쓰려고 만든 에이전트 개발 키트이고, 기본 흐름은 4단계로 구성되어 있다.

1. /project로 전체 코드를 읽고 코드 맵을 만든다. 기술 스펙, 버전, 보안 이슈까지 정리한다. 신규 프로젝트라면 질문을 통해 기술 스택도 추천한다.
2. 요구사항을 기반으로 마크다운 스펙 문서를 만들고, 뼈대 디렉토리 구조와 기술 스택 버전 고정까지 처리한다.
3. 복잡도를 예측해 병렬 또는 순차 전략을 정한다. LSP 서버로 에러를 줄이고 테스트 커버리지 85% 달성을 목표로 둔다.
4. Sync로 코드와 스펙 문서를 맞춘다. 개발 중 정책이 바뀌어도 문서와 코드가 따로 놀지 않게 하는 기능이다.

여기에 Fix와 Loop도 붙는다. Fix는 버그 메시지를 넣으면 포팅, 타입, 보안 이슈를 찾아주는 기능이고, Loop는 반복 검증을 최대 100회까지 돌리는 기능이라고 했다. 발표자는 퇴근할 때 "오늘 코딩한 거 보안 체크해라"라고 걸어두고, 다음 날 결과를 확인하는 식으로 쓴다고 했다.

---

6. 언어 선택: TypeScript -> Python -> Go

모아이를 어떤 언어로 만들지 고른 과정도 흥미로웠다.

처음에는 TypeScript로 시작했지만 Claude가 npm을 제거하고 Bun으로 전환하면서 환경이 꼬이기 시작했고, Windows에서 버그가 많이 났다고 했다. Python은 의존성 문제가 컸다.

최종 선택은 Go였다. 런타임 에러가 적고, 설치가 간단하고, Windows에서도 안정적이라는 이유였다. 발표자 본인은 Rust를 더 좋아하지만, 개발자가 좋아하는 기술보다 사용자에게 좋은 기술을 골랐다고 했다. 이 판단은 제품을 쓰는 사람 입장에서 설득력이 있었다.

Go로 전환하면서 기존 코드를 전부 새로 썼고, Codex, Gemini, Claude 세 개를 브레인스토밍시켜 하루 반나절 동안 교차 검증했다고 한다. 도구를 만든 과정 자체가 발표 내용과 맞물려 있었다.

---

7. 모아이 vs Spec Kit: 같은 문제를 다른 방식으로 푸는 도구

세션을 들으면서 GitHub에서 봤던 Spec Kit가 떠올랐다. 둘 다 스펙 기반 개발(Spec-Driven Development)을 다루고, Claude Code 같은 에이전트 코딩 도구와 연결해 쓰며, 에이전트가 읽을 수 있는 마크다운 문서를 중시한다.

다만 두 도구의 사용 장면은 꽤 달라 보였다.

공통점

모아이와 Spec Kit 모두 코드를 바로 짜기보다 스펙 문서를 먼저 만든다. 에이전트가 읽을 수 있는 설계서를 만들고, 그 설계서를 기준으로 코드를 생성한다는 점에서는 출발점이 같다.

워크플로우 구조

Spec Kit는 specify -> plan -> tasks -> implement -> review -> merge의 6단계 파이프라인이 명확하다. 각 단계가 독립된 명령어로 분리되어 있고, Kanban 대시보드에서 워크 패키지 상태를 추적할 수 있다. 검수, 승인, 머지 전략까지 들어가 있어 여러 명이 협업하는 환경에 더 잘 맞아 보였다.

모아이는 상대적으로 유연하다. /project로 분석하고 스펙을 만든 뒤, 복잡도에 따라 병렬 또는 순차 전략을 정한다. 발표자가 "코드 안 보고 코딩하는 게 아니라, 스펙과 DB 스키마만 보면 된다"고 했던 것처럼 사람이 직접 봐야 할 지점을 줄이는 데 초점이 있다. 중간에 정책이 바뀌면 Sync 기능으로 코드와 스펙을 맞춘다는 점도 다르다.

병렬 처리

Spec Kit는 git worktree 기반으로 각 실행 레인마다 독립적인 작업 디렉토리를 만든다. .worktrees/001-auth-lane-a/처럼 물리적으로 분리되어 있어 충돌을 줄이는 구조다.

모아이는 Claude Code의 멀티 에이전트 팀 기능을 활용해 최대 10개 태스크를 동시에 실행한다. Opus가 팀 리더 역할을 하고, Sonnet이 서브 에이전트로 작업하며 서로 통신할 수 있다고 했다. git worktree가 아니라 에이전트 레벨에서 병렬을 잡는 방식이다.

사용자

Spec Kit는 "진지한 소프트웨어 개발자"를 타겟으로 명시하고 있다. 프로젝트 오너, 테크 리드, 아키텍트 등 역할별 가치 제안이 정의되어 있고, C4 다이어그램과 ADR 추적까지 지원한다. 기업 환경이나 다수 인원이 협업하는 프로젝트에 더 적합해 보였다.

모아이는 발표자 본인이 쓰려고 만든 도구라 그런지 개인 개발자나 소규모 팀에 더 친화적인 인상을 줬다. "비개발자도 2일 만에 앱을 만든다"는 실전 사례에서 알 수 있듯, 진입 장벽을 낮추는 쪽에 더 가까웠다. 1인 개발자가 대규모 커뮤니티 사이트를 혼자 운영하는 상황에 잘 맞는다고도 했다.

비교

모아이 (Moai ADK) Spec Kit

핵심 철학	에이전트 코딩 하네스	스펙 기반 개발 파이프라인
워크플로우	분석 -> 스펙 -> 생성 -> 동기화	specify -> plan -> tasks -> implement -> review -> merge
병렬 처리	에이전트 팀 (최대 10개 동시)	git worktree (레인별 독립 디렉토리)
동기화	코드-스펙 자동 Sync	스펙 산출물 중심
대시보드	없음 (터미널 기반)	Kanban 대시보드 내장
지원 AI	Claude Code 전용	12개 AI 도구 지원 (Claude, Cursor, Gemini 등)
구현 언어	Go	Python
타겟	1인~소규모, 비개발자 포함	개발자, 팀/기업 환경

내가 정리한 차이

두 도구는 경쟁 제품이라기보다 쓰임새가 다르다. Spec Kit는 작업을 어떻게 관리하고 승인할지에 강점이 있고, 모아이는 에이전트를 어떻게 굴릴지에 더 많은 비중을 둔다.

발표자가 "Codex, Gemini, Claude 중 뭐가 좋냐? 다 좋은데 프롬프트가 안 좋은 거다"라고 했던 것도 이 맥락에서 이해됐다. 첫 번째 프롬프트의 품질, 특히 스펙 문서의 품질이 결과를 크게 바꾼다. 어떤 도구를 쓰든 목적어를 빼먹지 않고 구체적으로 지시해야 한다.

---

8. Q&A

스펙 문서가 오히려 LLM을 헷갈리게 하지 않느냐는 질문이 나왔다. 한번 쓰고 버리는 식으로 스펙을 관리하는 프로젝트들도 있다는 이야기였다.

발표자의 답변은 분명했다. 스펙 문서 안에 사용자의 요구, 변경 이유, 과거 기록이 연결돼 있어야 AI가 맥락을 갖고 추론할 수 있다고 했다. 맥락을 제공하지 않으면 AI가 엉뚱한 방향으로 갈 가능성이 높아진다.

토큰 비용에 대한 질문도 있었다. 발표자는 Mac 2대를 쓰고 있고, 설계는 Opus, 실행은 Sonnet으로 나눠 쓴다고 했다. Pencil MCP가 가장 토큰을 많이 잡아먹는다고 하면서, 비싼 모델을 쓰는 것보다 불필요하게 소모되는 토큰을 줄이는 게 더 중요하다고 했다.

팀 단위 협업에서 스펙 싱크를 어떻게 맞추느냐는 질문에는 모아이 자체가 팀 에이전트 구조로 설계돼 있다고 답했다. Board 플로 기반으로 작업하면 스펙 변경이 자동으로 동기화되고, 개인 모드보다 팀 모드가 더 잘 돌아간다고 했다.

---

9. 세션을 들으며 느낀 것

"코딩 1도 몰라도 코딩할 수 있다"는 말이 가장 무섭다는 발표자의 말이 계속 생각난다. MVP까지는 바이브 코딩으로 가능할 수 있다. 하지만 서비스를 운영하려면 보안을 피할 수 없다. 인증과 인가를 허술하게 만들었다가 한번 털리면 수습하기 어렵다.

시니어 개발자가 지금 가장 필요한 시기라는 말에도 공감했다. AI는 텍스트를 많이 학습했지만, 실제 환경에서 문제가 발생했을 때 처리하는 경험은 부족하다. 각자의 도메인에서 쌓은 경험과 직관은 여전히 필요하다.

발표자가 하신 말이 오래 남는다.

"Codex, Gemini, Claude 중에 뭐가 좋냐고요?
다 좋습니다. 다 좋은데 여러분의 프롬프트가 안 좋은 겁니다."

스펙 문서 하나를 제대로 쓸 수 있는 환경을 갖추면, 어떤 LLM을 쓰더라도 지금보다 생산적으로 일할 수 있을 것 같다.