[Claude Code + SpecKit] AI로 개발한 프로그램으로 지속 운영 가능할까?

[Claude Code + SpecKit] AI로 개발한 프로그램으로 지속 운영 가능할까?

한줄 요약

올해 초부터 SpecKit으로 프로그램을 개발하며 이 질문을 붙들고 있었습니다. 반년쯤 지나 답은 "가능하다" 로 굳었는데, 중요한 건 제가 뭘 더 잘해서가 아니라는 점입니다. 스펙 정의 전에 AI와 충분히 대화하고, 스펙 만들 때 물어오는 것에 답하는 것 — 제가 하는 건 이 둘뿐이고 나머지는 프로세스가 합니다.

이런 분들께 도움돼요

• AI로 뭔가 만들긴 했는데 "이걸 계속 굴릴 수 있나" 가 미덥지 않은 분

• "딸깍"이 편해서 스펙 쓰는 방식은 번거롭게만 느껴지는 분

• SpecKit을 들어는 봤지만 specify·plan·tasks·implement까지만 쓰고 계신 분

소개: 시도하고자 했던 것과 그 이유

문제 상황 (Before)

제 궁금증은 처음부터 "AI로 개발할 수 있나" 가 아니었습니다. 그건 이미 되니까요.

진짜 질문은 이거였습니다.

AI로 개발한 프로그램으로 지속 운영이 가능할까?

만드는 건 하루면 됩니다. 문제는 한 달 뒤입니다. 그때도 고칠 수 있나, 기능을 더할 수 있나, 다른 사람이 이어받을 수 있나. 만드는 속도와 운영 가능성은 전혀 다른 문제인데, 대부분의 AI 개발 이야기는 앞쪽에서 끝납니다.

시작하게 된 계기

올해 초 지피터스 오프라인 모임에서 SpecKit을 소개한 적이 있습니다.

SpecKit은 GitHub이 공식적으로 내놓은 스펙 주도 개발(Spec-Driven Development) 방법론을 구현한 툴킷입니다. 요구사항을 문서로 먼저 확정하고, 그 문서를 기준으로 계획과 태스크를 만들어 개발합니다.

반응은 미지근했습니다. 다들 "딸깍"을 좋아하시더군요. 프롬프트 한 줄 넣고 결과물 받는 그 맛. 저도 압니다. 그 옆에서 "스펙부터 쓰자"는 말은 확실히 번거롭게 들립니다.

그래도 저는 올해 초부터 계속 SpecKit 기반으로 개발해 왔고, 그러면서 "이 방식이면 AI로도 충분히 운영 가능하겠다"는 신뢰가 생겼습니다.

최근 SpecKit이 업데이트되면서 검수 스킬이 보완됐습니다.

이번 AI 결과물 검수 스터디를 하면서, 제가 반년간 얻은 "운영 가능하다"는 신뢰가 사실은 이 검수 단계들 위에 서 있었다는 걸 알았습니다. 그런데 저는 그중 절반은 건너뛰고 있었더군요.

진행 방법: 어떤 도구를 사용했고, 어떻게 활용했나요?

사용한 도구

• 도구: Claude Code + SpecKit (GitHub 공식 SDD 툴킷)

• 스터디 자료: SpecKit_AI_Engineering_Blueprint

제가 실제로 하는 일은 두 가지뿐입니다

먼저 이걸 분명히 하고 싶습니다. 아래에 AI가 어긋나는 방식 8가지가 나오는데, 저는 그걸 하나하나 잡으려고 뭘 따로 하지 않습니다.

제 작업은 이렇게 흘러갑니다.

① 스펙을 정의하기 전에 AI와 충분히 대화한다
        ↓
② 스펙을 만들 때 AI가 물어오는 것에 답한다   ← clarify
        ↓
③ 나머지는 프로세스대로 진행한다             ← checklist → plan → tasks → analyze → converge
        ↓
④ 최종 사용자 화면 테스트만 내가 직접 한다

①과 ②만 사람 몫이고, ③은 프로세스가 합니다. 제가 검수 항목을 외워서 매번 던지는 게 아닙니다. 순서대로 돌리면 그 안에서 걸립니다.

④는 아직 자동화 못 했습니다. 마지막에 실제 화면을 눌러보는 건 여전히 제가 합니다. 정직하게 적어둡니다.

AI와 협업한 과정

1. "딸깍은 왜 운영이 안 되는가"를 언어화했다

상황: 딸깍이 아쉽다고 말하긴 쉬운데 왜 아쉬운지는 저도 설명을 못 했습니다. 결과물만 보면 멀쩡하거든요.

이렇게 요청했어요:

이 문서 기준으로, AI가 어긋나는 방식을 "언제 발생하는가" 로 묶어줘. 그리고 각 묶음이 운영 단계에서 어떤 증상으로 나타나는지 알려줘.

결과: 문제가 두 덩어리로 갈렸습니다.

개발자가 겪는 AI 문제 = 모델 자체의 한계(축1) + 운영/관리의 한계(축2)

축 1 — 결과물의 문제:모델 자체의 한계

축 2 — 방식의 문제:운영/

관리의 한계

느낀 점: 여기서 제 원래 질문의 답이 나왔습니다.

"AI로 만들 수 있나"는 축 1의 문제고, "AI로 운영할 수 있나"는 축 2의 문제다.

딸깍은 축 2를 전혀 다루지 않습니다. 결정도, 제약도, 버린 대안도 전부 채팅창에 있고 그건 세션이 끝나면 사라집니다. 그래서 딸깍으로 만든 건 만들어지긴 하는데 운영이 안 됩니다. 한 달 뒤 열어보면 왜 이렇게 짰는지 아는 사람이 없습니다.

반대로 제 신뢰의 정체도 분명해졌습니다. SpecKit이 특별히 똑똑해서가 아니라, 맥락이 채팅창이 아니라 파일에 있기 때문입니다.

2. 8개 문제를 프로세스 위에 얹어봤다

상황: 스터디 자료에는 문제 8개와 해결 원리가 있고, 제 손엔 제가 매일 돌리는 순서가 있었습니다. 둘을 맞춰보고 싶었습니다.

이렇게 요청했어요:

이 8개 문제 각각이 프로세스의 어느 단계에서 처리되는지 짚어줘. 사람이 추가로 해야 하는 게 있으면 그것도 구분해서.

결과: 이렇게 정리됐습니다.

느낀 점: 두 가지가 눈에 들어왔습니다.

첫째, 제 몫으로 남는 건 위의 두 줄뿐입니다. 나머지 여섯은 프로세스를 순서대로 돌리기만 하면 따라옵니다. 검수 항목을 외워야 하는 게 아니라, 순서를 지키면 그 안에 이미 들어 있습니다.

둘째, 축 2 네 개는 아예 "내가 할 일" 칸이 비어 있습니다. 이건 노력의 문제가 아니라 형식의 문제이기 때문입니다. 맥락을 파일에 적는 순간 휘발성·사일로·종속성·토큰 비용이 한꺼번에 해결됩니다. 열심히 해서 되는 게 아니라 형식을 바꿔서 되는 것입니다.

그래서 딸깍은 아무리 열심히 해도 축 2를 못 넘습니다. 열심의 문제가 아니니까요.

3. 왜 clarify·checklist를 건너뛰면 안 되는지 알았다

상황: 솔직히 저는 이 둘을 그동안 거의 건너뛰었습니다. 스펙만 잘 쓰면 되지, 스펙을 또 검사하는 건 과하다고 생각했거든요.

결과: 위 표를 보면 답이 나옵니다. 제 몫으로 남은 두 줄이 정확히 clarify와 checklist 단계입니다.

앞의 둘은 우리 규칙을 문서에 심는 단계이고, 뒤의 analyze·converge는 심어둔 것과 대조하는 단계입니다. 앞을 건너뛰면 뒤가 대조할 원본이 없어서 헛돕니다.

특히 평균수렴이 그렇습니다. "우리 방식이 아니다"를 판단하려면 우리 방식이 어딘가에 적혀 있어야 하는데, 그걸 적는 단계가 바로 앞의 둘입니다.

느낀 점: 검수는 뒤에만 붙이는 게 아니라 앞뒤로 붙는 것이었습니다. 그리고 앞쪽이 더 중요합니다.

4. 평균수렴이 왜 제일 무서운지 캐물었다

상황: 문서는 8개 중 평균수렴을 "가장 발견하기 어려운 치명적 오류"로 꼽습니다. 처음엔 과장 같았습니다.

이렇게 요청했어요:

할루시네이션은 없는 걸 지어내는 거고 평균수렴은 흔한 걸 고르는 건데, 왜 후자가 더 위험해? 검수하는 사람 입장에서 설명해줘.

결과: 한 줄로 정리됐습니다.

나머지 셋은 검수에서 걸린다. 평균수렴은 검수를 통과한다.

• 할루시네이션 → 없는 API라서 실행하면 깨집니다

• 지시 무시 → 시킨 것과 다르니 비교하면 보입니다

• 맥락 오염 → 앞뒤가 안 맞으니 읽으면 걸립니다

• 평균수렴 → 정상 작동합니다. 코드는 돌고, 문서는 말이 되고, 화면은 무난합니다

문서는 이 힘을 이렇게 씁니다.

AI 출력 ≈ 학습 데이터의 평균 패턴(Gravity)
          + 제공된 컨텍스트의 보정값(Thrust)

컨텍스트를 약하게 주면 가장 흔하고 무난한 방식으로 끌려 내려갑니다(Gravity Well). 벗어나려면 우리 규칙을 컨텍스트로 밀어 올려야 합니다(Upward Thrust).

느낀 점: 제가 스펙 정의 전에 AI와 충분히 대화하는 이유가 바로 이거였습니다. 그때 하는 대화가 Thrust입니다. 그 대화를 건너뛰고 바로 스펙을 뽑으면, 스펙 자체가 이미 평균으로 끌려간 상태로 나옵니다. 그 뒤 단계는 전부 그 스펙을 충실히 따르니 아무도 이상하다고 안 합니다.

그리고 이건 운영 문제입니다. 평균수렴은 출시일엔 아무 문제도 안 일으키고, 한참 뒤 "우리 서비스가 왜 남들과 똑같아졌지" 할 때 드러납니다. 제 원래 질문과 정확히 맞물리는 지점입니다.

인상적이었던 순간

스터디 자료의 통합 표를 보다가, 8개 해결책이 전부 같은 뿌리라는 걸 알았습니다.

전부 "말로 하지 말고 파일로 남겨라" 하나입니다. 검수 관점으로 옮기면 이렇게 됩니다.

검수할 수 있는 건 파일뿐이다. 대화는 검수 대상이 아니라 증발 대상이다.

딸깍이 검수가 안 되는 이유가 여기 있습니다. 검수를 안 해서가 아니라 검수할 물건이 안 남아서입니다.

막혔던 순간과 해결

문제: 이 정리를 "그러니 SpecKit 쓰세요"로 마무리하려다 멈췄습니다. 그건 도구 홍보고, 이미 한 번 그렇게 소개했다가 미지근했으니까요.

해결: 관점을 바꿨습니다. "뭘 더 해야 한다"가 아니라 "뭘 안 해도 되는가" 로요.

위의 표에서 제 몫은 두 줄뿐이었습니다. 나머지 여섯은 순서만 지키면 따라옵니다. 딸깍이 매력적인 이유가 덜 하는 것이라면, 이쪽도 결국 덜 하는 이야기입니다. 시점이 다를 뿐입니다 — 앞에서 조금 더 말하고 뒤에서 훨씬 덜 고생하는 쪽입니다.

결과와 배운 점

Before vs After

⚠️ 시간 단축 수치는 넣지 않았습니다. 이번 건 속도 사례가 아니라 반년간 쌓인 신뢰의 근거가 뭐였는지 확인한 사례입니다.

결과물 — 프로세스가 대신 답해주는 질문 8개

아래는 제가 매번 던지는 체크리스트가 아닙니다. 프로세스를 돌리면 그 안에서 처리되는 것들입니다. 다만 SpecKit을 안 쓰신다면 이 8개를 직접 물으셔야 합니다.

① 결과물 자체 (축 1 — "만들 수 있나")

1. 맥락 오염 — 대화 초반에 준 제약이 이 결과물에도 살아 있나?

2. 할루시네이션 — 여기 나온 라이브러리·API·규칙이 실제로 존재하나?

3. 지시 무시 — 내가 지정한 경로 그대로인가? "더 나은 방식"이라며 갈아탄 곳은 없나?

4. 평균수렴 — 작동은 하는데, 우리만의 규칙 대신 일반 관행을 택한 곳은 없나?

② 일하는 방식 (축 2 — "운영할 수 있나")

5. 컨텍스트 휘발성 — 이 세션이 지금 끝나면, 왜 이렇게 결정했는지가 파일로 남나?

6. 지식 사일로 — 이 해결책이 내 채팅창에만 있나, 남이 찾을 수 있는 곳에 있나?

7. 모델 종속성 — 다른 모델·다른 도구로 옮겨도 이 지시가 그대로 통하나?

8. 토큰 비용 — 다음 세션에 같은 배경 설명을 또 해야 하나?

1~4번에 답할 수 있으면 만든 것이고, 5~8번에 답할 수 있어야 운영할 수 있습니다.

배운 점과 나만의 꿀팁

효과적이었던 것

1. 스펙을 뽑기 전에 충분히 대화하기 — 이게 제 작업의 8할입니다. 여기서 맥락을 제대로 안 넣으면 스펙 자체가 평균으로 끌려간 채 나오고, 이후 단계는 그 스펙을 충실히 따르기만 합니다.

2. 물어오면 성의껏 답하기 — clarify가 되묻는 건 AI가 모르는 걸 추측하지 않겠다는 신호입니다. 여기서 대충 답하면 그 대충이 그대로 코드가 됩니다.

3. 나머지는 순서를 믿기 — 단계마다 뭘 봐야 할지 고민하지 않습니다. 순서대로 돌리는 게 검수입니다.

이렇게 하면 안 돼요 (주의사항)

1. clarify·checklist를 건너뛰지 마세요. 제가 반년 동안 그랬습니다. 스펙도 AI가 쓴 결과물입니다. 검수 대상에서 뺄 이유가 없고, 여기서 심어놓은 게 없으면 뒤의 analyze·converge가 대조할 게 없습니다.

2. 축 2 문제를 모델 탓으로 돌리지 마세요. "AI가 자꾸 까먹는다"는 성능 문제가 아니라 맥락을 파일로 안 남긴 형식 문제입니다. 모델을 바꿔도 안 고쳐집니다.

3. 마지막 화면 테스트는 아직 사람 몫으로 남겨두세요. 저도 여기까지는 자동화하지 못했습니다. 프로세스를 믿되, 마지막에 직접 눌러는 봅니다.

과정 중 시행착오

가장 크게 헤맨 건 평균수렴을 "AI 성능이 아직 부족해서 생기는 일"로 이해했던 것입니다.

그렇게 보면 해결책은 "더 좋은 모델을 기다린다"가 됩니다. 그런데 반대였습니다. 평균수렴은 성능 부족이 아니라 성능이 작동하는 방식 그 자체입니다. 모델이 좋아지면 "흔한 답을 더 잘 만들 뿐" 입니다.

그래서 기다려서 해결되는 문제가 아니고, 스펙 전 대화에서 내가 밀어 올려야만(Thrust) 벗어납니다. 운영 가능성이 모델이 아니라 초반 30분에 달려 있다는 뜻입니다.

또 하나. 올해 초 모임에서 SpecKit을 소개할 때 저는 "이렇게 하면 잘 만들어집니다" 로 말했습니다. 지금이라면 "이렇게 해야 나중에 고칠 수 있습니다" 로 말하겠습니다. 딸깍과 겨룰 지점은 만드는 속도가 아니었습니다.

앞으로의 계획

다음 단계

• 검수 과정을 더 세세하게 뜯어보고 워크플로에 정식으로 넣기 — 지금까지는 생각날 때 돌렸는데, 어느 단계에서 어떤 검수를 거는지 고정하려 합니다.

• clarify·checklist를 건너뛸 수 없게 순서에 박아 넣기

• 최종 사용자 화면 테스트를 어디까지 자동화할 수 있을지 확인하기 — 지금 유일하게 남은 수동 구간입니다.

다른 업무에 적용한다면?

8개 질문에는 개발 용어가 거의 없습니다. "우리만의 규칙 대신 무난한 방식을 택했나" 는 보고서·기획서·카피·디자인 어디에나 그대로 던질 수 있습니다.

오히려 개발이 아닌 영역이 더 위험할 수 있습니다. 코드는 안 돌면 티라도 나지만, 무난한 카피는 그냥 무난하게 지나가니까요.

도움이 필요한 부분

딸깍으로 만든 걸 실제로 몇 달 이상 운영해 보신 분 이야기가 궁금합니다. 어디서 막히셨는지, 아니면 안 막히셨는지. 제 결론이 제 방식에만 맞는 답일 수도 있어서요.

재사용 가능한 프롬프트

SpecKit을 쓰신다면 아래 1번만 쓰시면 됩니다. 나머지는 프로세스가 합니다. 안 쓰신다면 2·3번을 직접 던지셔야 합니다.

프롬프트 1: 스펙 정의 전 대화 (제가 실제로 하는 일)

아직 스펙을 만들지 마.
먼저 내가 만들려는 걸 이해하는 데 필요한 걸 물어봐.

내가 하려는 건 [무엇]이고, [누가] 쓸 거야.
우리 [프로젝트/팀]의 기존 방식은 [여기에 기재]야.

한 번에 다 묻지 말고, 애매한 것부터 하나씩 물어봐.
"보통 이렇게 합니다"로 넘어가지 말고,
우리가 어떻게 하는지 모르겠으면 그냥 물어봐.

💡 [여기에 기재] 칸이 이 프롬프트의 전부입니다. 여기가 비면 AI는 가장 흔한 방식으로 채웁니다(평균수렴). 그리고 마지막 두 줄이 clarify가 하는 일을 미리 흉내 내는 부분입니다.

프롬프트 2: 결과물 4종 통합 검수 (SpecKit을 안 쓸 때)

[결과물]을 아래 4가지 관점으로 각각 나눠서 검수해줘.
한 덩어리로 뭉쳐서 말하지 말고, 항목별로 구분해서.

1. 맥락 오염 — 이 대화 초반에 내가 준 제약이
   결과물에도 그대로 살아 있는지.
2. 할루시네이션 — 여기 등장하는 도구/API/규칙 중
   실제로 존재하지 않거나 확인 안 된 게 있는지.
3. 지시 무시 — 내가 지정한 방식 대신
   "더 낫다고 판단해서" 다른 경로를 택한 곳이 있는지.
4. 평균수렴 — 작동은 하지만 우리 고유 규칙 대신
   일반적인 관행을 택한 곳이 있는지.

해당 없는 항목은 "해당 없음"이라고 명시해줘.
그냥 넘어가지 말고.

💡 마지막 두 줄이 중요합니다. "해당 없음"을 명시하게 하면 안 본 것과 봤는데 깨끗한 것을 구분할 수 있습니다. 이게 없으면 침묵이 통과인지 누락인지 알 수 없습니다.

프롬프트 3: 세션 끝나기 전 맥락 고정 (SpecKit을 안 쓸 때)

이 세션을 마무리하기 전에, 다음 세션의 나(또는 다른 사람)가
같은 설명을 반복하지 않아도 되게 파일로 남겨줘.

담을 내용:
- 이번에 무엇을 결정했는지 (결론만 말고 **왜 그렇게 정했는지**까지)
- 검토했다가 **버린 대안과 버린 이유**
- 다음 사람이 지켜야 할 제약조건

조건:
- 마크다운 파일 하나로. 특정 도구/모델 이름에 의존하지 않게.
- 이 대화를 안 본 사람이 읽어도 이해되게.

💡 "버린 대안과 버린 이유" 를 꼭 넣으세요. 이게 없으면 다음 세션의 AI가 버린 대안을 다시 제안합니다. 그게 컨텍스트 휘발성의 실제 증상이고, 딸깍으로 만든 프로그램이 운영 단계에서 무너지는 지점입니다.

SpecKit을 쓰면 이건 스펙 파일이 알아서 합니다.

도움 받은 글

참고한 자료

• SpecKit_AI_Engineering_Blueprint — 지피터스 23기 AI결과물검수 스터디 자료

  • 이 글의 8대 문제 분류, Gravity/Thrust 모델, 통합 해결 매트릭스는 모두 이 문서에 근거합니다.
    

    SpecKit_AI_Engineering_Blueprint.pdf

    7.54MB

• GitHub Spec Kit — 스펙 주도 개발(SDD) 툴킷. clarify·checklist·analyze·converge 등 검수 스킬 제공
  

작성일: 2026-08-05 작성자: 황금호랑이 스터디: 지피터스 23기 · AI결과물검수