목록으로
업무 생산성 개선을 위한 AI 활용
AI 코딩 에이전트를 활용한 1인 개발 형제 앱 간 개선 사항 이식과 변경 금지 항목 사전 명세
혼자 운영하는 안드로이드 앱 두 개 사이의 개선 이식을 Claude Code에 맡겼습니다. 결제와 광고 키는 변경 금지로 적어 두었고, 에이전트가 원본 앱에 남은 개발용 설정을 찾아 묻자 원래 판정을 되살려 구독자에게 광고가 다시 뜨는 일을 막았습니다.
🤖 활용 AI 도구
Claude Code(Anthropic의 코딩 에이전트)
① 어떤 상황에서 AI를 활용했나요?
하나를 먼저 고친 뒤 같은 틀로 만든 여러 벌에 옮기는 일은 개발자가 아니어도 합니다. 본사 공지를 지점별 안내문 여러 장에 옮기거나 지난해 보고서 틀에 올해 숫자를 채울 때, 옮겨야 할 내용과 장마다 달라야 할 지점명·전화번호·담당자가 한 문서 안에 섞여 있습니다. 옮기다가 섞이면 다른 지점 전화번호가 적힌 안내문이 나갑니다. 혼자 일하면 이 대조는 고스란히 자기 몫이 되는데, 1인 창조기업만 해도 2023년 기준 116만 곳이 넘습니다(중소벤처기업부 「2025년 1인 창조기업 실태조사」).
제게 그 일은 앱이었습니다. 저는 구글 플레이에 안드로이드 앱 여러 개를 올려 두고 혼자 운영합니다. 그중 두 앱은 뼈대가 같은 형제 앱이라, 한쪽을 먼저 고치고 같은 개선을 다른 쪽에 옮겨 심는 방식으로 관리해 왔습니다. 2026년 10월 19일에 확인한 플레이 스토어 공개 페이지 기준으로 먼저 고치는 앞선 앱은 100만 회, 뒤따르는 앱은 10만 회 넘게 설치됐습니다.
2026년 7월 6일, 뒤따르는 앱은 1.9.0판에 머물러 있었습니다. 지난번에 옮겨 온 뒤로 앞선 앱에만 변경 묶음 19개가 쌓였고(작업한 날 기준 10일), 채널 화면 구조, 광고를 불러오고 보여 주는 방식, 결제 화면, 자주 묻는 질문 화면이 모두 바뀌어 있었습니다. 이 변경 묶음을 개발에서는 커밋이라고 부르고, 아래에서도 그렇게 적습니다.
옮기다가 앱마다 달라야 하는 값이 섞이면 사고는 세 가지로 납니다.
1. 스토어 주소나 앱 이름이 섞이면 사용자가 다른 앱의 스토어 페이지로 가거나 다른 앱 이름을 봅니다.
2. 광고 단위와 키가 섞이면 광고 수익이 엉뚱한 계정으로 잡힙니다.
3. 결제·구독 판정이 섞이면 돈을 낸 사용자가 손해를 봅니다.
사람이 하면 두 프로젝트를 나란히 놓고 파일마다 대조해야 하는 일이라, 혼자 하는 개발자에게는 시간이 많이 들고 실수도 나기 쉬운 업무였습니다.
② 어떤 AI를 어떻게 활용했나요?
Claude Code를 썼습니다. 에이전트가 프로젝트 파일을 직접 읽고 고치고 빌드까지 돌리는 도구라, 파일 수십 개를 대조해야 하는 이식에 맞았습니다. 진행은 네 단계였습니다.
1단계, 지시문과 작업지시서. 19시 2분에 처음 넣고 19시 6분에 다듬은 지시문에는 할 일보다 지킬 일을 길게 적었습니다. 민감한 부분은 시험하기 전에 허락을 받을 것, 애매하면 임의로 판단하지 말고 물을 것, 뒤따르는 앱 폴더 안에서만 작업할 것, 병합은 제가 직접 한다는 것입니다. 해당 줄의 원문은 ⑤에 옮겨 두었습니다. 에이전트는 결제와 광고를 '민감'으로 표시한 영역별 사전 분석 4건을 나눠 돌린 뒤 질문 3개를 던졌고, 제 답을 받아 19시 11분 저장소에 작업지시서(이슈, 저장소에 붙여 두는 할 일 문서)를 세웠습니다. 칸은 넷입니다.
- 옮길 것: 채널 구조, 자주 묻는 질문 화면, 부가 화면, 결제 화면 정리, 광고 흐름, 일본어 추가, 버전 올림까지 7항목
- 변경 금지: 광고 단위 ID와 키, 광고 품질 서비스 키, 앱 식별자와 앱 이름, 테마 색, 서명 키. 결제 화면은 문구와 코드 정리만 하고 상품·가격·자동 갱신 로직은 그대로 둔다
- 광고 검증 계획: 이식할 때는 시험용 광고 ID로 두고 실기기 확인이 끝난 뒤 실제 ID로 바꾸는 일은 별도 커밋으로 한다
- 병합 전 실기기 점검 목록: 채널 탭, 자주 묻는 질문, 고객센터 메일, 구매 화면, 시작 흐름, 구독자 광고 미노출, 일본어 화면까지 7항목
광고 검증 계획 칸은 제 답에서 나왔습니다. 에이전트는 새 광고 로직에 실제 광고 ID를 바로 붙이자고 권했지만, 저는 시험용 ID로 먼저 검증하는 쪽을 골랐습니다.
2단계, 영역별 이식. 에이전트가 영역별 커밋 8개를 올렸습니다. 첫 커밋부터 여덟 번째 커밋까지 18분이 걸렸습니다. 중간인 19시 27분에 에이전트가 다시 물었습니다. 앞선 앱의 광고 대상 판정이 개발용으로 '항상 광고 표시'에 고정돼 있어 그대로 옮기면 구독자에게도 광고가 나간다는 내용이었고, 저는 원래 판정 로직을 되살리라고 답했습니다. 그대로 복사했다면 돈을 내고 광고를 없앤 사용자에게 광고가 다시 떴을 것입니다.
3단계, 변경 요청서 읽기. 변경 요청서(풀 리퀘스트, 바꾼 내용을 원본에 합쳐 달라고 올리는 문서)에는 '의도적으로 앞선 앱과 다르게 한 부분' 5가지가 따로 정리돼 있었고, 구독자 광고 판정도 그 안에 있었습니다. 광고 키, 앱 식별자, 서명 키가 바뀌지 않았음을 확인한 '변경 없음 확인' 절도 있었습니다.
4단계, 사람의 실기기 확인과 병합. 요청서 끝에는 이슈의 7항목을 바탕으로 앱 공유 링크, 업데이트 안내의 스토어 이동, 앱 정보 화면을 더해 다시 정리한 실기기 점검 8항목이 체크 목록으로 붙어 있었습니다. 실기기에서 시험용 광고를 띄워 보던 21시 9분, 광고가 설치 뒤 첫 실행에만 뜬다고 알렸습니다. 에이전트는 2분 뒤 스토어 밖에서 설치한 앱을 걸러 내는 기존 보호 장치가 개발 기기에서 작동한 것이라고 원인을 짚었습니다. 그 설명을 듣고 21시 13분에 시험용 ID를 실제 ID로 바꾸라고 지시했고 전환은 21시 14분 별도 커밋으로 들어갔습니다. 전환을 이때 한 것은 출시용 빌드를 앞두고서였습니다. 20시 57분에 출시용으로 빌드할 때는 광고만 시험용에서 실제 ID로 바꾸면 되는지 먼저 물어 두었고, 21시 13분 지시에도 바꾸고 나면 제가 빌드해서 최종 병합하겠다고 덧붙였습니다. 21시 22분에 알린 두 번째 문제는 동영상 광고가 화면을 가로로 돌릴 때 뒤에 있던 본 화면이 새로 만들어지는 결함이었습니다. 광고 ID와는 관계없는 화면 문제여서 21시 26분 수정 커밋으로 고쳤습니다. 마지막 검수(21시 51분)에서 에이전트는 급하지 않은 결함 5건을 찾아 지금 고치자고 권했지만, 저는 출시를 먼저 하고 결함은 기능별 변경 요청으로 따로 올리게 했습니다. 출시용 빌드(설치 파일 만들기)를 마친 다음 작업 갈래(브랜치)를 원본에 합치는 병합을 했습니다. 체크 목록 8칸은 제가 확인하며 한 칸씩 채웠습니다.
③ 활용 결과 어떤 변화가 있었나요?
- 이식하는 도중에 기존 버그 3건이 나왔습니다. 업데이트 안내가 앞선 앱의 스토어 주소로 연결되던 문제, 영어·태국어·중국어 화면의 공유 링크가 앞선 앱 주소였던 문제, 결제 문의 메일 제목에 앞선 앱 이름이 들어가던 문제로, 모두 ①의 1번 사고였습니다. 셋 다 예전에 앞선 앱을 따라 만들 때 딸려 온 흔적이었습니다. 2번은 광고 키 무변경 확인과 실제 ID 전환 별도 커밋으로, 3번은 구독자 광고 판정 복원으로 막았습니다.
- 변경 금지로 적은 항목 가운데 광고 키와 광고 품질 서비스 키, 앱 식별자, 서명 키는 하나도 바뀌지 않았습니다. 어떻게 확인했는지는 ④에 적었습니다.
- 에이전트가 원본과 다르게 처리한 곳을 요청서의 한 절에 모아 두어, 제가 먼저 읽을 곳이 바뀐 파일 151개에서 5가지로 줄었습니다.
- 첫 지시를 넣은 19시 2분부터 병합한 22시 16분까지 3시간 14분이 걸렸습니다. Claude Code 작업 기록을 사건 시각으로 나눠 보면 에이전트가 파일을 읽고 고치고 빌드한 시간이 71분, 에이전트가 제 답이나 실기기 확인을 기다린 시간이 101분, 마지막 응답부터 제가 병합하기까지가 22분입니다. 그동안 제가 입력한 것은 메시지 13개(공백 빼고 1,169자)와 질문 7개에 대한 답입니다. 앱 버전은 1.9.0에서 1.10.0이 되었습니다.
- 변경 요청 한 건에 커밋 14개, 파일 151개가 들어갔습니다. 코드는 1,743줄이 늘고 2,981줄이 줄었습니다. 앞선 앱에서 정리한 구조를 그대로 받아 오면서 중복이 빠진 결과입니다.
- 출시용 설치 파일(APK) 용량이 12.03MB에서 11.01MB로 줄었습니다. 쓰지 않는 리소스를 빌드에서 빼고 이미지 36종을 무손실 WebP로 바꾼 결과입니다.
- 저장소 기본 브랜치의 커밋 18개 가운데 12개에 Claude 공동 작성 표시가 남아 있습니다. 어떤 변경을 AI가 만들었고 어떤 변경을 제가 직접 했는지 나중에 구분할 수 있습니다.
같은 앱의 이전 팔로우 기록과도 견주었습니다. 2025년 가을 팔로우는 AI 표시가 없는 커밋 하나로 남아 있고 작업지시서와 변경 요청서, 점검 목록은 없습니다. 코드 7,179줄 증가와 5,079줄 감소, 파일 364개가 한 커밋에 들어갔는데 그중 50개는 빌드 캐시와 개발 도구 설정 파일이었습니다. 이번 변경 요청의 151개 파일에는 그런 파일이 없습니다. 이번에 찾은 기존 버그 3건도 그 커밋 뒤로 이번 작업 전까지 남아 있던 것들입니다. 걸린 시간은 같은 잣대로 견줄 수 없습니다. 그때는 사람이 손댄 시간을 남긴 기록이 없고, 제 컴퓨터의 저장소 기록에는 저장소를 내려받은 10월 28일 1시 58분부터 커밋한 10월 31일 22시 36분까지, 3일 20시간 38분이라는 시작과 끝의 간격만 남아 있습니다. 그래서 둘째 그림에는 점검 기록과 결과를 위에 두고 시간은 맨 아래 참고 줄로 내렸습니다.
다음 날 새벽에는 언어 24개를 더하는 작업도 맡겼습니다. 이슈를 올리고 12분이 안 돼 변경 요청이 올라왔습니다. 문자열 137개가 24개 언어 모두 빠짐없이 채워졌고 빌드도 통과했습니다. 그런데 요청서에는 「기계번역 초안입니다. 출시 전 원어민 검수를 권장합니다」라는 문장이 굵게 적혀 있었고 틀린 번역이 스토어 평점에 영향을 줄 수 있다는 경고도 붙어 있었습니다. 이 변경은 지금도 병합하지 않은 상태입니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요?
옮길 것보다 옮기지 말 것이 먼저. 이번에 나온 기존 버그 3건은 모두 예전에 앞선 앱을 따라 만들 때 함께 딸려 온 코드에 있었습니다. 변경 금지 항목을 지시서에 적어 두니 에이전트가 요청서에 그 항목의 무변경 확인을 따로 적었고, 제가 확인할 대상도 그 목록으로 정리됐습니다.
애매한 곳에서 에이전트가 멈춘 횟수는 일곱 번. 지시문에 '애매하면 묻고, 민감한 부분은 허락을 받으라'고 적어 두었더니 에이전트는 광고 ID, 버전 번호, 구독자 광고 판정, 구매 버튼, 결함 수정 시점을 스스로 정하지 않고 물었습니다. 저는 일곱 번 가운데 세 번은 권장안을 받았고 네 번은 다른 쪽을 골랐습니다.
실제 광고 ID 전환은 한 커밋에 따로. 시험용 광고 ID를 실제 ID로 바꾸는 일은 광고 수익과 직결됩니다. 그래서 이식 커밋에 섞지 않고 한 커밋으로 떼어 냈고 그 커밋 설명에는 시험용 ID를 참조하는 곳이 한 군데도 남지 않았는지 확인한 결과가 적혀 있습니다.
권한과 키는 작업 범위 밖에 두었습니다. 지시문으로 작업 폴더를 뒤따르는 앱 하나로 묶고 병합은 제 몫으로 남겼습니다. 에이전트는 작업 브랜치에만 커밋했고 기본 브랜치 병합은 제가 했습니다. 병합 뒤에 Claude Code 작업 기록을 다시 훑어 에이전트가 한 일을 셌습니다. 파일을 고친 32번 가운데 28번은 뒤따르는 앱 폴더 안이었고 4번은 Claude Code가 자기 작업 메모를 적은 것이었습니다. 앞선 앱 폴더나 키 설정·서명 키 파일을 고친 일은 없었고 터미널 명령 111개 가운데 기본 브랜치로 올리거나 병합한 명령도 없었습니다. 변경 요청이 바꾼 151개 파일은 앱 소스와 화면 리소스 149개, 빌드 설정 1개, 출시용 APK 1개였고 광고 키를 담은 설정 파일과 서명 키 파일은 하나도 바뀌지 않았습니다. 에이전트는 코드 안에 키 값을 직접 적은 곳이 없는지도 확인해 요청서에 남겼습니다. 저장소에는 사용자 정보를 담은 데이터 파일이 없습니다. 새로 들인 외부 라이브러리는 아파치 2.0 라이선스로 공개된 안드로이드 공식 라이브러리 1개이고 나머지 코드는 제가 만든 앞선 앱에서 옮겨 온 것입니다. 과학기술정보통신부 「국가 인공지능 윤리기준」(2020)은 책임성 요건에서 개발자·서비스 제공자·사용자 사이의 책임 소재를 분명히 하라고 합니다. 이 작업에서 AI의 몫과 제 몫을 가른 선은 병합이었고, 병합은 제가 했습니다. 같은 기준의 안전성 요건은 오류가 생기면 사용자가 작동을 제어할 수 있어야 한다고 적고 있습니다. 실제 광고 ID 전환은 코드 한 곳만 바꾼 커밋이어서, 문제가 생기면 그 커밋 하나를 되돌려 시험용 ID 상태로 돌아갈 수 있습니다.
검증할 수 없는 번역은 보류. 코드는 빌드와 실기기 점검으로 확인할 수 있지만 24개 언어 번역은 제가 읽고 확인할 수 없고, 빌드 통과와 누락 0건도 번역이 맞는지는 보여 주지 않습니다. 이 다국어 작업에도 같은 틀이 쓰였습니다. 변경 요청서의 방침 절에는 번역하지 않는 문자열 6개와 채널명·회사명·이메일·URL을 그대로 둔다는 변경 금지 줄이, 검증 절에는 키 누락 0과 빌드 성공이 적혀 있습니다.
⑤ 다른 사람도 따라 할 수 있나요?
따라 할 수 있습니다. 저장소를 읽고 빌드를 돌릴 수 있는 코딩 에이전트와 이슈 한 장이 필요합니다. 지시문에는 제가 넣은 다음 네 줄을 그대로 써도 됩니다. 앱 이름만 가렸습니다.
- 「광고, API 키 등 민감한 부분은 매우 주의를 기울여 테스트 할 것. 테스트 하기 전에 나에게 질문을 통해 허락을 받을 것」
- 「애매한 사항이 있으면 임의로 판단하지 말고 나에게 질문 하여 확인 받은 후 작업을 진행할 것.」
- 「[뒤따르는 앱] 프로젝트 폴더 내에서만 작업할 것.」
- 「이 과정에서 연결된 원격저장소 GitHub에 새로운 이슈와 브랜치를 파고, 해당 브랜치에서 작업한 후 PR까지 작성한다. 머지는 내가 직접 할 예정이다.」
그리고 이슈에 네 칸을 채우면 됩니다.
1. 옮길 것: 원본에서 가져올 변경 목록
2. 변경 금지: 식별자, 키, 결제, 브랜드처럼 대상마다 달라야 하는 것
3. 되돌리기 어려운 전환의 순서: 무엇을 확인한 뒤 바꿀지(코드라면 어떤 커밋으로)
4. 병합 전 확인 목록: 사람이 직접 눌러 볼 항목
형제 앱이 아니어도 됩니다. 지점별 홈페이지 여러 개, 같은 틀로 만든 사내 도구 여러 벌처럼 하나를 먼저 고치고 나머지에 옮겨야 하는 업무라면 같은 지시서를 쓸 수 있습니다. 코드가 아닌 문서도 같습니다. 본사 휴무 안내를 지점 안내문 다섯 장에 옮기는 일을 AI에 맡긴다면 네 칸은 이렇게 채웁니다.
1. 옮길 것: 휴무 일정 문단, 문의 방법 문단
2. 변경 금지: 지점명, 지점 전화번호, 영업시간, 담당자 이름
3. 되돌리기 어려운 전환의 순서: 고객 문자 발송은 다섯 장을 사람이 모두 읽은 뒤에
4. 병합 전 확인 목록: 장마다 지점명과 전화번호가 그 지점 것인지 원본 명단과 대조
이때도 변경 금지 목록과 병합 전 확인 목록은 사람이 씁니다.
첨부한 그림은 네 장입니다. 첫째는 7월 6일 저녁부터 7일 새벽까지의 기록과 작업지시서의 네 칸, 둘째는 이전 팔로우와 이번 이식의 기록 비교, 셋째는 작업지시서와 변경 요청서의 해당 절 발췌, 넷째는 네 칸 지시서 양식입니다. 그림과 본문의 시각·건수는 제 저장소의 이슈, 변경 요청, 커밋 기록과 제 컴퓨터에 남은 저장소 기록, Claude Code 작업 기록에서 옮겼고 설치 수는 플레이 스토어 공개 페이지에서 옮겼습니다. 공개 게시판에 올라가는 글이라 앱 이름과 코드, 키 값은 싣지 않았습니다. 발췌에서도 앱 이름, 파일 이름, 키 이름은 가렸습니다.
하나를 먼저 고친 뒤 같은 틀로 만든 여러 벌에 옮기는 일은 개발자가 아니어도 합니다. 본사 공지를 지점별 안내문 여러 장에 옮기거나 지난해 보고서 틀에 올해 숫자를 채울 때, 옮겨야 할 내용과 장마다 달라야 할 지점명·전화번호·담당자가 한 문서 안에 섞여 있습니다. 옮기다가 섞이면 다른 지점 전화번호가 적힌 안내문이 나갑니다. 혼자 일하면 이 대조는 고스란히 자기 몫이 되는데, 1인 창조기업만 해도 2023년 기준 116만 곳이 넘습니다(중소벤처기업부 「2025년 1인 창조기업 실태조사」).
제게 그 일은 앱이었습니다. 저는 구글 플레이에 안드로이드 앱 여러 개를 올려 두고 혼자 운영합니다. 그중 두 앱은 뼈대가 같은 형제 앱이라, 한쪽을 먼저 고치고 같은 개선을 다른 쪽에 옮겨 심는 방식으로 관리해 왔습니다. 2026년 10월 19일에 확인한 플레이 스토어 공개 페이지 기준으로 먼저 고치는 앞선 앱은 100만 회, 뒤따르는 앱은 10만 회 넘게 설치됐습니다.
2026년 7월 6일, 뒤따르는 앱은 1.9.0판에 머물러 있었습니다. 지난번에 옮겨 온 뒤로 앞선 앱에만 변경 묶음 19개가 쌓였고(작업한 날 기준 10일), 채널 화면 구조, 광고를 불러오고 보여 주는 방식, 결제 화면, 자주 묻는 질문 화면이 모두 바뀌어 있었습니다. 이 변경 묶음을 개발에서는 커밋이라고 부르고, 아래에서도 그렇게 적습니다.
옮기다가 앱마다 달라야 하는 값이 섞이면 사고는 세 가지로 납니다.
1. 스토어 주소나 앱 이름이 섞이면 사용자가 다른 앱의 스토어 페이지로 가거나 다른 앱 이름을 봅니다.
2. 광고 단위와 키가 섞이면 광고 수익이 엉뚱한 계정으로 잡힙니다.
3. 결제·구독 판정이 섞이면 돈을 낸 사용자가 손해를 봅니다.
사람이 하면 두 프로젝트를 나란히 놓고 파일마다 대조해야 하는 일이라, 혼자 하는 개발자에게는 시간이 많이 들고 실수도 나기 쉬운 업무였습니다.
② 어떤 AI를 어떻게 활용했나요?
Claude Code를 썼습니다. 에이전트가 프로젝트 파일을 직접 읽고 고치고 빌드까지 돌리는 도구라, 파일 수십 개를 대조해야 하는 이식에 맞았습니다. 진행은 네 단계였습니다.
1단계, 지시문과 작업지시서. 19시 2분에 처음 넣고 19시 6분에 다듬은 지시문에는 할 일보다 지킬 일을 길게 적었습니다. 민감한 부분은 시험하기 전에 허락을 받을 것, 애매하면 임의로 판단하지 말고 물을 것, 뒤따르는 앱 폴더 안에서만 작업할 것, 병합은 제가 직접 한다는 것입니다. 해당 줄의 원문은 ⑤에 옮겨 두었습니다. 에이전트는 결제와 광고를 '민감'으로 표시한 영역별 사전 분석 4건을 나눠 돌린 뒤 질문 3개를 던졌고, 제 답을 받아 19시 11분 저장소에 작업지시서(이슈, 저장소에 붙여 두는 할 일 문서)를 세웠습니다. 칸은 넷입니다.
- 옮길 것: 채널 구조, 자주 묻는 질문 화면, 부가 화면, 결제 화면 정리, 광고 흐름, 일본어 추가, 버전 올림까지 7항목
- 변경 금지: 광고 단위 ID와 키, 광고 품질 서비스 키, 앱 식별자와 앱 이름, 테마 색, 서명 키. 결제 화면은 문구와 코드 정리만 하고 상품·가격·자동 갱신 로직은 그대로 둔다
- 광고 검증 계획: 이식할 때는 시험용 광고 ID로 두고 실기기 확인이 끝난 뒤 실제 ID로 바꾸는 일은 별도 커밋으로 한다
- 병합 전 실기기 점검 목록: 채널 탭, 자주 묻는 질문, 고객센터 메일, 구매 화면, 시작 흐름, 구독자 광고 미노출, 일본어 화면까지 7항목
광고 검증 계획 칸은 제 답에서 나왔습니다. 에이전트는 새 광고 로직에 실제 광고 ID를 바로 붙이자고 권했지만, 저는 시험용 ID로 먼저 검증하는 쪽을 골랐습니다.
2단계, 영역별 이식. 에이전트가 영역별 커밋 8개를 올렸습니다. 첫 커밋부터 여덟 번째 커밋까지 18분이 걸렸습니다. 중간인 19시 27분에 에이전트가 다시 물었습니다. 앞선 앱의 광고 대상 판정이 개발용으로 '항상 광고 표시'에 고정돼 있어 그대로 옮기면 구독자에게도 광고가 나간다는 내용이었고, 저는 원래 판정 로직을 되살리라고 답했습니다. 그대로 복사했다면 돈을 내고 광고를 없앤 사용자에게 광고가 다시 떴을 것입니다.
3단계, 변경 요청서 읽기. 변경 요청서(풀 리퀘스트, 바꾼 내용을 원본에 합쳐 달라고 올리는 문서)에는 '의도적으로 앞선 앱과 다르게 한 부분' 5가지가 따로 정리돼 있었고, 구독자 광고 판정도 그 안에 있었습니다. 광고 키, 앱 식별자, 서명 키가 바뀌지 않았음을 확인한 '변경 없음 확인' 절도 있었습니다.
4단계, 사람의 실기기 확인과 병합. 요청서 끝에는 이슈의 7항목을 바탕으로 앱 공유 링크, 업데이트 안내의 스토어 이동, 앱 정보 화면을 더해 다시 정리한 실기기 점검 8항목이 체크 목록으로 붙어 있었습니다. 실기기에서 시험용 광고를 띄워 보던 21시 9분, 광고가 설치 뒤 첫 실행에만 뜬다고 알렸습니다. 에이전트는 2분 뒤 스토어 밖에서 설치한 앱을 걸러 내는 기존 보호 장치가 개발 기기에서 작동한 것이라고 원인을 짚었습니다. 그 설명을 듣고 21시 13분에 시험용 ID를 실제 ID로 바꾸라고 지시했고 전환은 21시 14분 별도 커밋으로 들어갔습니다. 전환을 이때 한 것은 출시용 빌드를 앞두고서였습니다. 20시 57분에 출시용으로 빌드할 때는 광고만 시험용에서 실제 ID로 바꾸면 되는지 먼저 물어 두었고, 21시 13분 지시에도 바꾸고 나면 제가 빌드해서 최종 병합하겠다고 덧붙였습니다. 21시 22분에 알린 두 번째 문제는 동영상 광고가 화면을 가로로 돌릴 때 뒤에 있던 본 화면이 새로 만들어지는 결함이었습니다. 광고 ID와는 관계없는 화면 문제여서 21시 26분 수정 커밋으로 고쳤습니다. 마지막 검수(21시 51분)에서 에이전트는 급하지 않은 결함 5건을 찾아 지금 고치자고 권했지만, 저는 출시를 먼저 하고 결함은 기능별 변경 요청으로 따로 올리게 했습니다. 출시용 빌드(설치 파일 만들기)를 마친 다음 작업 갈래(브랜치)를 원본에 합치는 병합을 했습니다. 체크 목록 8칸은 제가 확인하며 한 칸씩 채웠습니다.
③ 활용 결과 어떤 변화가 있었나요?
- 이식하는 도중에 기존 버그 3건이 나왔습니다. 업데이트 안내가 앞선 앱의 스토어 주소로 연결되던 문제, 영어·태국어·중국어 화면의 공유 링크가 앞선 앱 주소였던 문제, 결제 문의 메일 제목에 앞선 앱 이름이 들어가던 문제로, 모두 ①의 1번 사고였습니다. 셋 다 예전에 앞선 앱을 따라 만들 때 딸려 온 흔적이었습니다. 2번은 광고 키 무변경 확인과 실제 ID 전환 별도 커밋으로, 3번은 구독자 광고 판정 복원으로 막았습니다.
- 변경 금지로 적은 항목 가운데 광고 키와 광고 품질 서비스 키, 앱 식별자, 서명 키는 하나도 바뀌지 않았습니다. 어떻게 확인했는지는 ④에 적었습니다.
- 에이전트가 원본과 다르게 처리한 곳을 요청서의 한 절에 모아 두어, 제가 먼저 읽을 곳이 바뀐 파일 151개에서 5가지로 줄었습니다.
- 첫 지시를 넣은 19시 2분부터 병합한 22시 16분까지 3시간 14분이 걸렸습니다. Claude Code 작업 기록을 사건 시각으로 나눠 보면 에이전트가 파일을 읽고 고치고 빌드한 시간이 71분, 에이전트가 제 답이나 실기기 확인을 기다린 시간이 101분, 마지막 응답부터 제가 병합하기까지가 22분입니다. 그동안 제가 입력한 것은 메시지 13개(공백 빼고 1,169자)와 질문 7개에 대한 답입니다. 앱 버전은 1.9.0에서 1.10.0이 되었습니다.
- 변경 요청 한 건에 커밋 14개, 파일 151개가 들어갔습니다. 코드는 1,743줄이 늘고 2,981줄이 줄었습니다. 앞선 앱에서 정리한 구조를 그대로 받아 오면서 중복이 빠진 결과입니다.
- 출시용 설치 파일(APK) 용량이 12.03MB에서 11.01MB로 줄었습니다. 쓰지 않는 리소스를 빌드에서 빼고 이미지 36종을 무손실 WebP로 바꾼 결과입니다.
- 저장소 기본 브랜치의 커밋 18개 가운데 12개에 Claude 공동 작성 표시가 남아 있습니다. 어떤 변경을 AI가 만들었고 어떤 변경을 제가 직접 했는지 나중에 구분할 수 있습니다.
같은 앱의 이전 팔로우 기록과도 견주었습니다. 2025년 가을 팔로우는 AI 표시가 없는 커밋 하나로 남아 있고 작업지시서와 변경 요청서, 점검 목록은 없습니다. 코드 7,179줄 증가와 5,079줄 감소, 파일 364개가 한 커밋에 들어갔는데 그중 50개는 빌드 캐시와 개발 도구 설정 파일이었습니다. 이번 변경 요청의 151개 파일에는 그런 파일이 없습니다. 이번에 찾은 기존 버그 3건도 그 커밋 뒤로 이번 작업 전까지 남아 있던 것들입니다. 걸린 시간은 같은 잣대로 견줄 수 없습니다. 그때는 사람이 손댄 시간을 남긴 기록이 없고, 제 컴퓨터의 저장소 기록에는 저장소를 내려받은 10월 28일 1시 58분부터 커밋한 10월 31일 22시 36분까지, 3일 20시간 38분이라는 시작과 끝의 간격만 남아 있습니다. 그래서 둘째 그림에는 점검 기록과 결과를 위에 두고 시간은 맨 아래 참고 줄로 내렸습니다.
다음 날 새벽에는 언어 24개를 더하는 작업도 맡겼습니다. 이슈를 올리고 12분이 안 돼 변경 요청이 올라왔습니다. 문자열 137개가 24개 언어 모두 빠짐없이 채워졌고 빌드도 통과했습니다. 그런데 요청서에는 「기계번역 초안입니다. 출시 전 원어민 검수를 권장합니다」라는 문장이 굵게 적혀 있었고 틀린 번역이 스토어 평점에 영향을 줄 수 있다는 경고도 붙어 있었습니다. 이 변경은 지금도 병합하지 않은 상태입니다.
④ 나만의 방식 또는 개선 포인트는 무엇인가요?
옮길 것보다 옮기지 말 것이 먼저. 이번에 나온 기존 버그 3건은 모두 예전에 앞선 앱을 따라 만들 때 함께 딸려 온 코드에 있었습니다. 변경 금지 항목을 지시서에 적어 두니 에이전트가 요청서에 그 항목의 무변경 확인을 따로 적었고, 제가 확인할 대상도 그 목록으로 정리됐습니다.
애매한 곳에서 에이전트가 멈춘 횟수는 일곱 번. 지시문에 '애매하면 묻고, 민감한 부분은 허락을 받으라'고 적어 두었더니 에이전트는 광고 ID, 버전 번호, 구독자 광고 판정, 구매 버튼, 결함 수정 시점을 스스로 정하지 않고 물었습니다. 저는 일곱 번 가운데 세 번은 권장안을 받았고 네 번은 다른 쪽을 골랐습니다.
실제 광고 ID 전환은 한 커밋에 따로. 시험용 광고 ID를 실제 ID로 바꾸는 일은 광고 수익과 직결됩니다. 그래서 이식 커밋에 섞지 않고 한 커밋으로 떼어 냈고 그 커밋 설명에는 시험용 ID를 참조하는 곳이 한 군데도 남지 않았는지 확인한 결과가 적혀 있습니다.
권한과 키는 작업 범위 밖에 두었습니다. 지시문으로 작업 폴더를 뒤따르는 앱 하나로 묶고 병합은 제 몫으로 남겼습니다. 에이전트는 작업 브랜치에만 커밋했고 기본 브랜치 병합은 제가 했습니다. 병합 뒤에 Claude Code 작업 기록을 다시 훑어 에이전트가 한 일을 셌습니다. 파일을 고친 32번 가운데 28번은 뒤따르는 앱 폴더 안이었고 4번은 Claude Code가 자기 작업 메모를 적은 것이었습니다. 앞선 앱 폴더나 키 설정·서명 키 파일을 고친 일은 없었고 터미널 명령 111개 가운데 기본 브랜치로 올리거나 병합한 명령도 없었습니다. 변경 요청이 바꾼 151개 파일은 앱 소스와 화면 리소스 149개, 빌드 설정 1개, 출시용 APK 1개였고 광고 키를 담은 설정 파일과 서명 키 파일은 하나도 바뀌지 않았습니다. 에이전트는 코드 안에 키 값을 직접 적은 곳이 없는지도 확인해 요청서에 남겼습니다. 저장소에는 사용자 정보를 담은 데이터 파일이 없습니다. 새로 들인 외부 라이브러리는 아파치 2.0 라이선스로 공개된 안드로이드 공식 라이브러리 1개이고 나머지 코드는 제가 만든 앞선 앱에서 옮겨 온 것입니다. 과학기술정보통신부 「국가 인공지능 윤리기준」(2020)은 책임성 요건에서 개발자·서비스 제공자·사용자 사이의 책임 소재를 분명히 하라고 합니다. 이 작업에서 AI의 몫과 제 몫을 가른 선은 병합이었고, 병합은 제가 했습니다. 같은 기준의 안전성 요건은 오류가 생기면 사용자가 작동을 제어할 수 있어야 한다고 적고 있습니다. 실제 광고 ID 전환은 코드 한 곳만 바꾼 커밋이어서, 문제가 생기면 그 커밋 하나를 되돌려 시험용 ID 상태로 돌아갈 수 있습니다.
검증할 수 없는 번역은 보류. 코드는 빌드와 실기기 점검으로 확인할 수 있지만 24개 언어 번역은 제가 읽고 확인할 수 없고, 빌드 통과와 누락 0건도 번역이 맞는지는 보여 주지 않습니다. 이 다국어 작업에도 같은 틀이 쓰였습니다. 변경 요청서의 방침 절에는 번역하지 않는 문자열 6개와 채널명·회사명·이메일·URL을 그대로 둔다는 변경 금지 줄이, 검증 절에는 키 누락 0과 빌드 성공이 적혀 있습니다.
⑤ 다른 사람도 따라 할 수 있나요?
따라 할 수 있습니다. 저장소를 읽고 빌드를 돌릴 수 있는 코딩 에이전트와 이슈 한 장이 필요합니다. 지시문에는 제가 넣은 다음 네 줄을 그대로 써도 됩니다. 앱 이름만 가렸습니다.
- 「광고, API 키 등 민감한 부분은 매우 주의를 기울여 테스트 할 것. 테스트 하기 전에 나에게 질문을 통해 허락을 받을 것」
- 「애매한 사항이 있으면 임의로 판단하지 말고 나에게 질문 하여 확인 받은 후 작업을 진행할 것.」
- 「[뒤따르는 앱] 프로젝트 폴더 내에서만 작업할 것.」
- 「이 과정에서 연결된 원격저장소 GitHub에 새로운 이슈와 브랜치를 파고, 해당 브랜치에서 작업한 후 PR까지 작성한다. 머지는 내가 직접 할 예정이다.」
그리고 이슈에 네 칸을 채우면 됩니다.
1. 옮길 것: 원본에서 가져올 변경 목록
2. 변경 금지: 식별자, 키, 결제, 브랜드처럼 대상마다 달라야 하는 것
3. 되돌리기 어려운 전환의 순서: 무엇을 확인한 뒤 바꿀지(코드라면 어떤 커밋으로)
4. 병합 전 확인 목록: 사람이 직접 눌러 볼 항목
형제 앱이 아니어도 됩니다. 지점별 홈페이지 여러 개, 같은 틀로 만든 사내 도구 여러 벌처럼 하나를 먼저 고치고 나머지에 옮겨야 하는 업무라면 같은 지시서를 쓸 수 있습니다. 코드가 아닌 문서도 같습니다. 본사 휴무 안내를 지점 안내문 다섯 장에 옮기는 일을 AI에 맡긴다면 네 칸은 이렇게 채웁니다.
1. 옮길 것: 휴무 일정 문단, 문의 방법 문단
2. 변경 금지: 지점명, 지점 전화번호, 영업시간, 담당자 이름
3. 되돌리기 어려운 전환의 순서: 고객 문자 발송은 다섯 장을 사람이 모두 읽은 뒤에
4. 병합 전 확인 목록: 장마다 지점명과 전화번호가 그 지점 것인지 원본 명단과 대조
이때도 변경 금지 목록과 병합 전 확인 목록은 사람이 씁니다.
첨부한 그림은 네 장입니다. 첫째는 7월 6일 저녁부터 7일 새벽까지의 기록과 작업지시서의 네 칸, 둘째는 이전 팔로우와 이번 이식의 기록 비교, 셋째는 작업지시서와 변경 요청서의 해당 절 발췌, 넷째는 네 칸 지시서 양식입니다. 그림과 본문의 시각·건수는 제 저장소의 이슈, 변경 요청, 커밋 기록과 제 컴퓨터에 남은 저장소 기록, Claude Code 작업 기록에서 옮겼고 설치 수는 플레이 스토어 공개 페이지에서 옮겼습니다. 공개 게시판에 올라가는 글이라 앱 이름과 코드, 키 값은 싣지 않았습니다. 발췌에서도 앱 이름, 파일 이름, 키 이름은 가렸습니다.
