Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
AI 코딩 도구 사용이 개발 방식을 혁신했지만, 임의 기능 추가, 자체 리뷰 신뢰성 저하 등 새로운 위험을 초래했습니다. 필자는 이러한 문제를 해결하기 위해 '자신을 멈추게 하는 규칙'을 제도화하는 방법론 STIT+IRG를 제시합니다. 이는 사양 확정, 독립적 리뷰, 결정 기록화를 원칙으로 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Claude Code로 대표되는 AI 코딩 도구는 우리의 개발 스타일을 극적으로 변화시켰습니다. 저 역시 예외가 아니어서, 일상적인 개발에서 AI의 힘을 빌리지 않는 날은 없게 되었습니다.
하지만 그 강력함 때문에 새로운 위험이 생겼다는 사실에 저는 한동안 깨닫지 못했습니다.
저는 현재 AI 개발 환경으로 Claude Code를 활용하고 있습니다. Claude Code는 성능이 뛰어나지만, 사용 비용의 문제가 있었습니다. 그래서 저는 비용 최적화 노력의 일환으로 GLM이나 MiniMax 같은 대체 모델을 활용하는 구성을 구축하고 있습니다.
이 환경에서 매일 개발을 진행하면서, 점차 문제가 눈에 보이는 형태로 나타나기 시작했습니다.
AI 코딩을 계속하다 보면, 반드시 동일한 유형의 실수를 반복하게 됩니다. 저의 경우 주로 다음과 같은 4가지였습니다.
이 문제들은 모두 'AI가 강력하다는 것'이 원인입니다. 인간에게는 '정말 이게 괜찮을까?'라고 의심하며 진행할 수 있는 제동 장치가 있습니다. 하지만 AI에는 그 제동 장치가 없습니다—적어도 지금의 AI에는요.
이 4가지 문제를 해결하기 위해 제가 도달한 결론은 '자신을 멈추게 하는 규칙을 제도화하는 것'이었습니다.
여기서 중요한 것은, 'AI를 믿지 않는다'가 아니라 'AI의 힘을 빌리면서도 안전망을 구축한다'는 자세입니다. AI 코딩 자체를 멈출 생각은 없습니다. 다만, 그 강력함으로부터 자신을 보호하기 위한 틀이 필요했던 것입니다.
구체적으로 다음과 같은 3가지를 원칙으로 삼았습니다.
이러한 원칙들을 템플릿화하고 재현 가능한 형태로 정리한 것이 바로 STIT+IRG입니다.
STIT+IRG는 Spec & Test Driven Iteration + Independent Review Gate의 약자입니다. 이름에서 알 수 있듯이, 두 개의 기둥으로 구성되어 있습니다.
| # | 원칙 | 의미 |
|---|---|---|
| 1 | Specification before implementation | 구현보다 사양을 먼저 확정한다 |
| ... | ||
| 특히 원칙 3은 당연해 보이지만 지키기 어려운 규칙입니다. Cursor나 GitHub Copilot 같은 AI 어시스턴트가 '코드를 리뷰할까요?'라고 물어오지만, 그것은 리뷰가 아닙니다. 어디까지나 '자가 점검'일 뿐입니다. |
STIT+IRG에서는 개발을 다음과 같이 단계 분할하고 순서를 강제합니다.
Phase 0: Project Specialization（프로젝트 고유의 전제 고정）
↓
Phase 1: Spec & Test Definition（사양과 테스트의 정의）
...
Phase 1에서 구현 코드 출력을 금지하고 있다는 점이 중요합니다. AI에게 사양을 해석하게 하고 '이 사양을 만족하는 코드를 작성해 달라'고 부탁하고 싶은 충동을 억제하기 위함입니다. 사양서는 텍스트로 확정되며, 그 텍스트 자체가 결과물의 일부가 됩니다.
STIT+IRG 중에서 가장 중요하다고 제가 생각하는 것이 Phase 3의 Independent Review Gate입니다.
이 단계에서는 다음과 같은 엄격한 규칙이 적용됩니다.
즉, 원래 세션의 문맥을 끊음으로써 '그때 내가 그렇게 말했으니까'라는 전제 지식을 배제한 객관적인 리뷰를 실현하는 것입니다.
이는 물리적인 제약이 아니라 심리적인 제약으로 작용합니다. 만약 원래 세션을 계속 사용하게 되면, '저 코드를 보면 알겠지'라는 전제가 리뷰에 개입해 버립니다. 새로운 세션에서 '여기에 문제가 있습니다'라고 지적받아야 비로소 진정한 문제점을 깨닫게 됩니다.
또한, 저는 이 리뷰 결과를 Obsidian을 활용한 Single Source of Truth (SSOT)에 축적하고 있습니다. 이를 통해 결정의 경위를 검색 가능한 형태로 남길 수 있습니다.
STIT+IRG는 GitHub의 Template Repository로 공개되어 있습니다.
리포지토리: https://github.com/fukukei23/stit-irg-template
사용 방법은 매우 간단합니다.
디렉터리 구조는 다음과 같습니다.
ARCHITECTURE.md # Governance Gate Entrypoint (SSOT)
GOVERNANCE/ # 프로토콜 및 AI용 규칙
AI_INSTRUCTIONS.md # 구현 AI용 지침서
...
중요한 점은 ARCHITECTURE.md가 Single Source of Truth (SSOT)라는 것입니다. 여기에 Governance Gate의 정의를 기재하고, 프로젝트 멤버 전원이 이를 참조합니다.
AI_INSTRUCTIONS.md에는 구현 AI를 위한 지침서가 포함되어 있습니다. 주요 제약 사항은 다음 3가지입니다.
마지막 점은 특히 중요합니다. 침묵하며 진행하는 것이 최악의 위반입니다. AI가 '여기는 분명 이럴 거야'라고 추측하여 진행해 버린 경우, 나중에 그 가정을 찾아내기가 매우 어렵습니다. '불명'이라고 명시되어 있다면, 리뷰어나 프로젝트 리더가 판단할 수 있습니다.
이 템플릿을 실제 프로젝트에 적용하며 몇 가지 깨달음을 얻었습니다.
Phase 1 단계에서 구현 코드가 나오지 않는 것에 익숙해지는 데 시간이 걸렸습니다. '여기서 코드 보여줘'라고 입으로 내뱉는 것을 의식적으로 억제할 필요가 있었습니다.
새로운 세션을 시작하여 제로(zero)부터 코드를 설명하는 작업은 귀찮게 느껴질 때가 있습니다. 하지만 바로 이 '수고로움'이 있기 때문에 품질 보증이 확실해집니다.
DECISION_LOGS에 기록된 결정은 시간이 지나도 참조 가치가 있습니다. 신규 참여자가 프로젝트의 역사를 이해하는 데 효과적인 자료가 됩니다.
이러한 규칙들은 '가능하면 지키도록 합시다'가 아니라 '반드시 지켜야 합니다'로 설정되어 있습니다. 이 차이가 운영의 성패를 갈랐습니다. '권장'이라면 언젠가는 확실하게 지켜지지 않고 잊혀집니다. '강제'이기 때문에 프로젝트 기록으로 남는 것입니다.
AI 구동 개발은 여전히 과도기에 있습니다. 강력한 도구이지만, 그 강력함 때문에 위험하기도 합니다. 주저 없이 앞으로 나아가는 AI를 멈추게 하는 것은 인간뿐입니다. 그리고 그 '스스로를 멈추게' 하기 위한 규칙을 제도화하고 템플릿으로 만들어 놓음으로써, 더욱 확실한 개발을 실현할 수 있습니다.
STIT+IRG는 그 첫 번째 시도입니다. 사용하면서 조금씩 개선되어 갈 것을 예상합니다. 관심이 있으시다면 GitHub 리포지토리를 확인해 주십시오. 피드백을 기다리겠습니다.
AI 구동 개발의 성숙을 위해, 함께 걸어 나갑시다.
📖 Claude Code CLI를 GLM/MiniMax로 대체한 이야기 — 이 거버넌스 설계를 지탱하는 AI 개발 환경 구축 방법을 비용 관점에서 해설
📖 Claude Code의 기억을 Obsidian으로 SSOT화(Single Source of Truth)하는 설계 — 거버넌스 설계에서 '결정 기록'을 Obsidian SSOT으로 실천하는 방법
📖 playwright-stealth가 개발 중단되어 Python 버전을 직접 제작해 PyPI에 공개한 이야기 — STIT+IRG의 거버넌스 하에 AI 구동 개발한 실전 예시
📖 14개의 AI 에이전트가 협조하는 자율형 개발 프레임워크 설계 및 구현 — STIT+IRG를 내포하는 멀티 에이전트 프레임워크 'NexusCore'의 아키텍처 해설. 페이즈 구동 개발・품질 게이트・거버넌스 자동화의 실제 소개
본 기사는 개인 Zenn에서도 공개하고 있습니다.