콘텐츠로 이동

AI 네이티브 시대 개발자 생존 전략: 앱 세 개를 AI 에이전트와 만들며 바뀐 내 역할

"AI가 코드를 다 짜면 개발자는 무엇을 하나요?" 이 질문에 일반론 대신 기록으로 답해 보려 합니다. 올해 혼자서 서비스 세 개를 Claude Code와 함께 만들고 운영했습니다. 그 사이 제 손이 가장 적게 간 곳은 코드였고, 가장 많이 간 곳은 문서와 검사와 판정이었습니다. 이 글은 그 이동을 세 저장소에 남은 파일과 날짜로 따라가 봅니다.

이 글의 기준

2026년 4월에 올린 같은 제목의 글은 인터뷰 영상 한 편을 요약한 것이었습니다. 2026-10-24에 직접 운영 중인 세 프로젝트의 저장소 기록(CLAUDE.md, 에이전트 정의, 체인지로그, git 기록)과 이 블로그에 쓴 프로젝트 소개 글을 근거로 전면 다시 썼습니다. 각 앱의 이야기 자체는 소개 글에 있고, 여기서는 개발자의 역할만 따로 떼어 봅니다.

1. 세 프로젝트, 한 명의 개발자

프로젝트 무엇인가 기록 기간 커밋 수
운동 기록 앱 Flutter + 애플워치 운동 기록 앱, App Store 출시 2026-07-19 ~ 729
On Pocket News 내 상황에 맞는 정책 소식을 골라 주는 웹 서비스 2026-02-16 ~ 571
모닝 브리핑 관심 토픽 뉴스를 요약해 아침에 보내는 앱 2026-10-05 ~ 36

커밋 수는 2026-10-24 기준 git 기록입니다. 세 저장소 모두 코드의 대부분은 에이전트가 썼습니다. 그렇다면 사람이 한 일은 무엇이었을까요. 기록을 다시 읽으며 네 가지로 묶었습니다.

2. 첫 번째 일 — 범위를 정하고, 그 권한을 구조로 나눈다

운동 기록 앱은 Claude Code에 여섯 역할을 정의하고 시작했습니다. 흥미로운 것은 각 역할에 준 도구 목록입니다.

역할 모델 파일을 고칠 수 있나
어드바이저(설계·범위 판단) Fable 아니요 (읽기·검색·웹 조회만)
앱 개발자 Opus 예
UI 개발자 Sonnet 예
QA 리뷰어 Sonnet 아니요
테스터 Haiku 아니요
릴리스 매니저 Sonnet 예

"어드바이저는 코드를 쓰지 않는다"는 규칙을 프롬프트로만 적은 것이 아니라, 어드바이저 정의에서 편집 도구를 아예 뺐습니다. 어드바이저의 판단 기준도 우선순위로 적었습니다. 1순위는 "3초 안에 기록한다"는 요구사항, 2순위는 문서와의 정합, 3순위는 범위 절제입니다. GPS 트래킹·랭킹·서버 푸시처럼 하지 않기로 한 기능은 다시 들여오지 않게 하고, 새 기능은 어느 마일스톤에 속하는지부터 정하게 했습니다.

이 표를 짜는 데 들인 시간은 코드 한 줄도 만들지 않았지만, 이후 700개가 넘는 커밋이 모두 이 표 위에서 만들어졌습니다.

교훈: 구현을 맡기는 순간 개발자에게 남는 가장 큰 일은 "무엇을 만들지 않을지"를 정하는 일입니다. 그리고 그 결정을 누가 바꿀 수 있는지까지 구조로 정해야 결정이 지켜집니다.

3. 두 번째 일 — "완료"의 뜻을 정의한다

10월 5일, 운동 기록 앱 1.5.3을 준비하던 날의 기록입니다. 워치 화면 레이아웃을 고친 변경이 이미 main에 머지됐고, 게이트 검사와 Android 빌드까지 끝난 상태였습니다. 그런데 QA 리뷰어가 머지된 변경을 다시 보다가 블로커를 찾았습니다. 40mm 워치에서 긴 종목명과 세 자리 카운트가 겹치면 가운데 숫자가 "9…"로 잘려 보였습니다.

빌드는 그 자리에서 멈췄습니다. 이미 만든 산출물은 올리지 않고 폐기 폴더로 옮겼고, 앱 개발자가 숫자 크기를 정하는 지점을 하나로 모아 잘림 경로 자체를 없앴습니다. 기기 크기와 자릿수 조합 18장을 다시 확인한 뒤에야 빌드를 새로 만들었습니다.

이 판단이 가능했던 것은 QA 리뷰어의 정의에 이런 규칙이 있었기 때문입니다.

리뷰 통과 기준: 블로커 0건 + 신규 로직 테스트 존재.
확실하지 않은 지적은 코드를 실제로 실행·테스트해 확인한 뒤 보고한다 (추측 금지).

On Pocket News에서는 같은 문제를 다른 방향에서 만났습니다. 단위 테스트가 모두 통과한 상태에서 화면 증적을 찍다가, 알림 수신에 동의하지 않은 회원에게 알림이 켜져 있는 버그가 나왔습니다. 그 뒤로 이 프로젝트는 테스트 통과가 아니라 화면 증적까지를 완료로 봅니다.

교훈: 에이전트는 "끝났다"고 말할 줄 압니다. 무엇이 끝인지는 사람이 정해야 하고, 그 정의가 구체적일수록 머지 뒤에도 멈출 수 있습니다.

4. 세 번째 일 — 사고를 규칙으로 바꾼다

On Pocket News의 CLAUDE.md에는 "절대 금지"라는 말이 여러 번 나옵니다. 그 대부분 옆에는 사고 이력이 붙어 있습니다.

날짜 사고 남은 규칙
2026-04-12 감수 대기 기사 384건을 스크립트로 일괄 처리, 쓰레기 글 약 280건이 감수 완료로 노출 감수와 사이트 분석은 한 건씩, 일괄 처리 금지
2026-04-22 개정 초기의 자동 LLM 분류·감수 경로가 비용과 품질 양쪽에서 부담 서버는 LLM을 자동 호출하지 않음, 추천·매칭은 규칙 기반
날짜 미기재 로컬 빌드를 직접 배포해 개발용 API 주소가 운영에 올라감 운영 배포는 git push와 CI로만

규칙을 쓸 때 원칙이 하나 있습니다. 왜 금지인지를 함께 적는 것입니다. 이유가 없는 금지는 세션이 바뀐 에이전트가 "이번에는 괜찮겠지" 하고 넘어서기 쉽고, 사람도 몇 달 뒤에는 왜 막았는지 잊습니다. 사고 이력은 그 규칙이 지켜야 할 이유를 다음 세션에 전해 줍니다.

교훈: 에이전트와 일하는 개발자의 회고는 회의록이 아니라 규칙 파일의 diff로 남아야 합니다. 같은 사고가 두 번 나지 않게 하는 곳은 사람의 기억이 아니라 다음 세션이 읽는 파일입니다.

5. 네 번째 일 — 반복의 끝을 정한다

가장 최근에 시작한 모닝 브리핑은 앞의 두 프로젝트에서 배운 것을 첫날부터 CLAUDE.md에 넣었습니다. 작업 하나마다 계획, 구현, 검증, 반성의 루프를 돌리되 끝나는 조건을 미리 정했습니다.

같은 작업 단위에서 수정-검증을 5회 반복해도 실패 → 중단하고 원인, 시도한 방법, 막힌 지점을 보고
테스트를 통과시키려고 테스트를 약화·삭제·skip 처리하지 않는다.
완료 기준, prompts/ 디렉터리 파일, 이 CLAUDE.md를 스스로 수정하지 않는다. 변경이 필요하면 제안만 한다.

세 번째 줄이 특히 중요했습니다. 에이전트가 검증을 통과하는 가장 쉬운 방법은 검증 기준을 고치는 것이기 때문입니다. 기준 파일은 사람만 바꿀 수 있게 하고, Phase가 끝날 때마다 멈추고 승인을 받게 했습니다.

같은 원칙이 제품 안에도 들어가 있습니다. 요약 배치의 모든 루프는 시도 횟수와 상한을 갖고, 실행 하나가 20단계를 넘으면 강제로 실패 처리됩니다. 개발 과정의 루프와 제품의 루프를 같은 사람이 같은 원칙으로 설계한 셈입니다.

교훈: 반복 자체는 에이전트가 잘합니다. 언제 멈추고 사람에게 넘길지, 그리고 무엇은 절대 스스로 바꾸지 못하게 할지가 개발자가 설계할 부분입니다.

그래도 사람 손이 꼭 필요했던 자리

규칙과 에이전트로 대신할 수 없었던 일도 기록에 남아 있습니다.

자리 기록에 남은 장면
실기기와 실사용 시뮬레이터에서는 보이지 않던 화면 자동 잠금, 큰 글씨에서 꺾이는 버튼 라벨이 손에 쥐고 나서야 나옴
스토어 심사 대응 iOS 첫 심사가 정보 요청으로 돌아와 스크린 레코딩과 영문 회신을 직접 준비
스토어 콘솔 Play가 이미 쓰인 버전 코드를 거부해 다시 빌드, 비공개 테스트는 옵트인 10/12로 프로덕션 관문 미충족
계정과 업로드 업로드와 콘솔 작업은 사람이 한다는 규칙을 전역 설정에 명시

이 자리들의 공통점은 결과에 책임을 지는 주체가 필요하다는 것입니다. 심사 회신에 서명하는 사람, 테스터를 모으는 사람, 출시 버튼을 누르는 사람은 에이전트가 될 수 없었습니다.

역할 이동 한눈에 보기

예전에 시간을 쓰던 곳 지금 시간을 쓰는 곳 근거가 된 파일
기능 구현 범위와 Non-goal 결정, 역할별 권한 설계 .claude/agents/*.md
내 코드 디버깅 완료 기준과 리뷰 통과 기준 정의 QA 리뷰어 정의, 체인지로그
장애 회고 회의 사고 이력을 붙인 금지 규칙 프로젝트 CLAUDE.md
끝날 때까지 붙잡기 반복 상한과 멈춤 지점 설계 개발 루프 프로토콜
혼자 테스트 실기기 확인, 심사·콘솔 대응 출시 런북

💡 원스의 인사이트: 살아남는 기술은 '거절하는 장치'를 만드는 기술이다

세 프로젝트를 돌아보면 제가 가장 공들인 산출물은 코드를 만드는 장치가 아니라 코드를 거절하는 장치였습니다. 편집 도구가 없는 어드바이저, 블로커 0건 규칙, 사고 이력이 붙은 금지 조항, 5회 상한과 기준 파일 수정 금지가 모두 그렇습니다.

그래서 AI 시대의 개발자 역량을 묻는 질문에는 이렇게 답합니다. 좋은 결과를 알아보는 눈, 그리고 그 눈을 다음 세션도 쓸 수 있게 파일과 검사로 옮기는 손입니다. 이 둘은 결국 설계와 테스트, 코드 리뷰라는 오래된 개발 역량에서 나옵니다. 도구가 바뀌어도 그 역량의 쓰임새가 구현 쪽에서 판정 쪽으로 옮겨 갔을 뿐입니다.

체크리스트 — 내 일은 구현에서 판정으로 옮겨 가고 있는가

  • [ ] 프로젝트에 "하지 않을 것" 목록이 문서로 있다
  • [ ] 판단하는 역할과 구현하는 역할의 권한이 도구 수준에서 나뉘어 있다
  • [ ] "완료"의 기준이 테스트 통과 이상으로 구체적으로 적혀 있다
  • [ ] 사고가 나면 이유와 함께 규칙 파일에 한 줄이 추가된다
  • [ ] 자동 반복에는 상한이 있고, 에이전트가 검증 기준을 스스로 바꿀 수 없다
  • [ ] 실기기 확인과 출시 판단처럼 사람이 책임질 자리가 정해져 있다

참고 자료 및 출처