승인 두 번이면 나머지는 에이전트가 짓는다

개발자 한 명이 클로드 코드(Claude Code)만으로 아이오에스(iOS) 앱을 출시 단계까지 굴린 작업 방식이 오픈소스로 공개됐다. 프라그마(Pragma)라는 이름의 이 저장소는 슬래시 명령 15개, 깃허브 액션(GitHub Actions) 워크플로 3개, 보조 스크립트를 한 묶음으로 프로젝트에 설치해 준다. 저장소가 내건 문구는 짧다 — 사람은 두 번만 승인하고, 나머지는 에이전트가 처리한다.

무슨 일인가 / 배경

공개된 저장소는 커밋 121개가 쌓인 MIT 라이선스 프로젝트다. 눈에 띄는 것은 데모가 아니라 실물이 딸려 있다는 점이다. 만든 사람은 파이낸스트래커(FinanceTracker)라는 가계부 성격의 앱을 스위프트UI(SwiftUI)와 스위프트데이터(SwiftData)로 만들면서, 첫 커밋부터 끝까지 이 파이프라인만 썼다고 밝혔다. 저장소 설명 기준으로 이 방식에서 나온 병합된 풀 리퀘스트는 80건이 넘고, 커뮤니티에 소개될 때는 94건으로 집계됐다.

에이전트로 코드를 짜는 사례는 이미 흔하다. 이 프로젝트가 다른 지점은 코드를 짜는 방법이 아니라 '어디까지 사람이 보고 어디부터 기계가 밀어붙이는가'를 못 박았다는 데 있다.

핵심 짚어보기

작업 흐름은 이렇게 흐른다. 아이디어를 넣으면 /spec 명령이 명세를 만들고 여기서 사람이 한 번 승인한다. 이어 /plan이 구현 계획을 세우고 여기서 두 번째 승인을 받는다. 그 뒤로는 /feature가 실제 코드를 쓰고, /gates가 자체 검사를 돌리고, 풀 리퀘스트가 열리면 /review와 /test가 붙는 동시에 CI가 PR 검사와 UI 테스트를 돌린다. 통과하면 develop 브랜치로 병합되고, /release가 태그를 찍으면 릴리스 빌드와 배포물 생성까지 이어진다. 버그가 들어오면 /bugfix로 시작하는 짧은 갈래가 따로 있다.

설치되는 것은 세 층이다. 명령 층, CI 층, 보조 스크립트 층인데 각각 독립적이라 필요한 것만 골라 쓸 수 있다. 보조 스크립트는 테스트용 시뮬레이터를 고르고 커버리지 기준 미달을 막는 역할을 한다.

세부 설계 중 눈여겨볼 것은 초기화 방식이다. 플러그인으로 설치한 뒤 초기화 명령을 실행하면 아키텍처와 핵심 제약을 질문으로 물어보고, 그 답을 프로젝트 지침 파일과 불변 규칙 파일에 함께 채워 넣는다. 빈 템플릿을 남겨 두면 아무도 채우지 않는다는 사실을 설계에 반영한 것이다.

1인기업 실전 적용 포인트

• 자기 업무의 승인 지점을 두 개로 줄여 보라. 콘텐츠라면 '주제 확정'과 '구성안 확정'까지만 직접 보고, 초안 작성·검수·발행 준비는 정해진 순서대로 자동으로 흐르게 둔다. 매 단계 확인하는 습관이 실은 가장 큰 병목이다.
• 반복 지시는 문서가 아니라 명령으로 굳혀라. 매번 같은 설명을 프롬프트에 다시 쓰고 있다면 그건 명령으로 만들 신호다. 이 프로젝트가 명령 15개로 개발 전 주기를 덮은 것처럼, 자기 업무도 대여섯 개 명령이면 대부분 덮인다.
• 검사는 사람이 아니라 게이트에 맡겨라. 커버리지 기준, 필수 항목 누락, 형식 오류처럼 판단이 필요 없는 확인은 자동 검사로 내려 두면 사람은 판단이 필요한 곳에만 개입하게 된다.
• 첫 프로젝트부터 파이프라인 위에서 시작하라. 이 저장소가 설득력을 갖는 이유는 완성된 앱을 나중에 자동화한 게 아니라, 첫 커밋부터 같은 흐름으로 쌓았기 때문이다. 기록이 곧 증거가 된다.

전망 / 주의점

한계도 분명하다. 공개 직후라 별과 포크가 거의 없는 신생 프로젝트이고, 검증 사례도 만든 사람 본인의 앱 하나다. 아이오에스 전용이라 엑스코드(Xcode)와 시뮬레이터 환경을 전제로 하며, 다른 분야에 그대로 옮겨 쓸 수는 없다. 실속 있는 활용법은 코드를 가져다 쓰는 쪽이 아니라 구조를 베껴 자기 업무의 순서로 옮기는 쪽이다. 그리고 잊지 말아야 할 전제가 있다. 검사 게이트가 없는 자동화는 속도만 올리고 품질은 떨어뜨린다.

출처: 깃허브 akshaypimprikar/pragma (https://github.com/akshaypimprikar/pragma)