[나의 앱개발기] AI에게 코드 요청할 때 "부분 수정" 대신 "전체 파일 교체"를 시키는 이유
새벽 한 시였습니다. 사내에서 쓰는 회계 정산 웹앱에 기능 하나만 붙이면 되는 상황이었죠. AI가 알려준 답은 이랬습니다. "기존 함수 아래에 이 코드를 추가하세요." 코드 열다섯 줄. 간단해 보였습니다.
그런데 30분을 헤맸습니다. '기존 함수 아래'가 대체 어디냐는 겁니다. 비슷하게 생긴 함수가 세 개였고, 저는 코드를 읽을 줄 모르는 사람이거든요. 결국 감으로 붙여넣었고, 웹앱은 열리지 않았습니다.
비개발자로서 AI와 프로그램을 만들어온 지 꽤 됐습니다. 그 사이에 요청 방식이 한 번 크게 바뀌었는데, 그게 오늘 얘기하려는 겁니다. "이 부분만 고쳐줘"를 완전히 버리고, "수정된 파일 전체를 처음부터 끝까지 다시 줘"로 갔습니다.
* 부분 수정이 비개발자에게 통하지 않는 이유.
처음엔 저도 부분 수정이 당연히 효율적이라고 생각했습니다. 파일 전체를 다시 받는 건 낭비 같았거든요. 그런데 실제로 부딪힌 문제는 세 가지였습니다.
1. '어디에' 넣는지를 내가 모릅니다.
개발자에게 "이 함수 안에"는 명확한 지시입니다. 하지만 저 같은 사람에겐 좌표가 없는 지도예요. 중괄호 하나를 잘못 닫으면 파일 전체가 죽는데, 어디서 죽었는지 찾을 방법이 없습니다. 붙여넣는 위치를 고민하는 시간이, 파일 전체를 다시 받아 통째로 갈아끼우는 시간보다 훨씬 길었습니다.
2. 대화가 길어지면 AI도 내 파일을 모릅니다.
이게 진짜 함정입니다. 스무 번쯤 주고받다 보면 AI가 기억하는 파일 상태와 제 화면에 있는 실제 파일이 슬금슬금 어긋나요. 중간에 제가 직접 손댄 부분이 있으면 더 심해집니다. AI는 자기가 마지막으로 준 버전을 기준으로 "여기 아래에"라고 말하는데, 제 파일엔 그 '여기'가 없는 상황. 이걸 저는 "파일이 두 사람 사이에서 서로 다르게 늙어가는 문제"라고 부릅니다.
3. 되돌릴 방법이 마땅치 않습니다.
구글 앱스 스크립트로 만든 도구들은 깃허브 같은 버전 관리를 안 씁니다. 부분 수정을 5번 연달아 하다가 깨지면, 어느 수정에서 깨졌는지 되짚을 수가 없어요. 반면 파일을 통째로 받으면 이전 파일을 그냥 텍스트로 저장해두면 됩니다. 그게 곧 백업이죠.
* 두 방식을 실제로 비교하면.
| 기준 | 부분 수정 | 전체 파일 교체 |
|---|---|---|
| 적용 시간 | 위치 찾느라 오래 | 복사 → 붙여넣기 끝 |
| 실수 가능성 | 높음 | 거의 없음 |
| 파일 상태 동기화 | 계속 어긋남 | 매번 초기화됨 |
| 백업 | 사실상 불가 | 받은 파일이 곧 백업 |
| 응답 시간 | 짧음 | 길어짐 |
| 기능 누락 위험 | 낮음 | 있음 (대응 필요) |
보시면 아시겠지만 전체 교체가 모든 면에서 우월한 건 아닙니다. 아래 두 칸은 명백히 손해예요. 다만 저에게는 위의 네 칸이 훨씬 비쌌던 겁니다. 코드를 읽는 사람이라면 계산이 반대로 나올 수도 있죠.
* 전체 교체를 하면 반드시 겪는 문제 두 가지.
1. AI가 중간을 생략합니다.
가장 짜증나는 지점입니다. 파일을 다 달라고 했는데 중간에 "// 이하 기존 코드와 동일" 같은 주석을 박아놓는 경우가 있어요. 그대로 붙여넣으면 그 기능이 통째로 사라집니다. 심지어 붙여넣은 직후엔 멀쩡해 보여서, 며칠 뒤에야 "어? 이 버튼 왜 안 되지" 하고 발견하게 되죠.
그래서 요청할 때 이 문장을 고정으로 넣습니다.
"생략이나 축약 없이, 첫 줄부터 마지막 줄까지 전체 코드로 주세요."
2. 파일이 커지면 애초에 불가능해집니다.
파일이 1,500줄을 넘어가면 전체 교체 자체가 버거워집니다. 응답이 끊기거나, 생략 확률이 급격히 올라가요. 이때 답은 하나입니다. 파일을 쪼개는 것.
제 도구들은 대부분 이런 식으로 나뉘어 있습니다. 백엔드 로직 파일, 데이터 재구축 전용 파일, 화면 파일, 스타일 파일. 처음부터 이렇게 설계한 건 아니고, 전체 교체를 계속 하다 보니 "한 번에 통째로 교체 가능한 크기"가 곧 파일 분리의 기준이 되더라고요. 개발 이론서에 나오는 이유가 아니라, 순전히 제 작업 방식 때문에 생긴 구조인 셈이죠.
* 그래서 지금은 이렇게 요청합니다.
지금 파일 전체를 먼저 붙여넣고
무엇을 바꿀지 한 문장으로 말하고
생략 없는 전체 파일로 돌려받기!
여기에 하나 더. 붙여넣기 전에 기존 파일을 메모장에 복사해둡니다. 3초면 되는데, 이거 안 해서 밤새 만든 기능을 날린 적이 두 번 있습니다. 두 번째에 배웠어요.
* 이 방식이 정답이냐 하면.
1. 전체 교체가 나은 쪽.
코드를 읽지 못하거나, 버전 관리 도구를 안 쓰거나, 파일이 서너 개로 끝나는 작은 도구를 만드는 경우. 대부분의 1인 개발자가 여기 해당한다고 봅니다.
2. 부분 수정이 나은 쪽.
깃을 쓰고 변경 이력을 추적할 수 있는 사람이라면 얘기가 완전히 다릅니다. 어디가 바뀌었는지 한눈에 보이니까요. 파일이 수십 개인 프로젝트에서 매번 전체를 받는 건 그냥 낭비입니다.
저는 개인적으로, 이건 실력의 문제가 아니라 안전장치의 문제라고 봅니다. 되돌릴 수단이 있으면 부분 수정을 해도 되고, 없으면 전체 교체가 그 역할을 대신해주는 거죠. 제가 깃을 배웠다면 아마 지금과 다르게 일하고 있었을 겁니다. 그런데 배울 시간에 도구를 하나 더 만들었고, 후회는 없습니다.
* 마무리 정리.
부분 수정은 '어디에 넣을지 아는 사람'을 전제로 한 방식입니다. 그 전제가 없으면 시간도 더 걸리고 사고도 더 납니다. 전체 파일 교체는 느리고 비효율적으로 보이지만, 매번 파일 상태를 초기화해준다는 점에서 비개발자에게는 오히려 가장 안전한 선택이었습니다.
대신 생략 방지 문장과 사전 백업, 이 두 가지는 습관으로 붙여야 합니다. 그리고 파일이 감당 안 될 만큼 커졌다면, 그건 코드가 문제가 아니라 파일을 쪼갤 때가 됐다는 신호입니다.
코드를 못 읽어도 프로그램은 만들 수 있습니다. 다만 못 읽는다는 사실에 맞춰 작업 방식을 설계해야 하더라고요. 저는 그 답을 한 문장으로 정리했습니다. 전체를, 생략 없이, 매번.