한 번 동작했던 앱에 나중에 기능을 추가할 때, AI에게 대충 부탁하면 「기존 코드를 통째로 다시 작성한 버전」이 돌아와서, 동작하고 있던 부분까지 망가지는 경우가 있습니다.

이 기사에서는 미경험자가 기존 코드에 대한 기능 추가를 AI에게 부탁할 때, 변경 범위를 최소한으로 억제하기 위한 의뢰 방법과 안전하게 테스트하기 위한 git 운용을 정리합니다.

AI는 주어진 정보의 범위 내에서만 상황을 판단할 수 있습니다. 기존 코드의 구조나 「왜 이렇게 작성되었는지」를 전달하지 않고 「검색 기능을 달아줘」라고만 부탁하면, AI는 자신이 생각하는 "깔끔한 완성형"을 처음부터 제시하기 쉽습니다. 그 결과, 기존의 변수명·상태 관리(state management)·스타일 등이 통째로 바뀌어, 동작하고 있던 부분까지 영향을 받게 됩니다.

❌ 「검색 기능을 달아줘」

✅ 「아래가 현재의 목록 표시 코드입니다 (코드 첨부). 
이 기존의 구조·변수명·state의 방식은 가급적 바꾸지 말고, 
검색으로 필터링하는 기능만 추가하고 싶어. 
...

포인트는 3가지입니다.

기존 코드를 실제로 붙여넣기 (AI에게 현황을 전달) -
「바꾸지 않았으면 하는 범위」를 명시하기 (구조·변수명·state 등) -
「차분(diff) 형태로」라고 출력 형식을 지정하기 (전체 다시 쓰기 방지)

「검색과 정렬(sort)과 페이지네이션(pagination)을 달아줘」라고 한꺼번에 부탁하면 변경 범위가 넓어져 리뷰도 힘들어집니다. 먼저 검색만, 동작하면 정렬, 이런 순서로 하나씩 부탁하는 편이 각 단계에서 동작 확인을 할 수 있고 문제 분리도 간단합니다.

기능 추가 전에 작업용 브랜치(branch)를 만들어 두면, 기존의 동작하고 있는 상태(main)를 더럽히지 않고 테스트할 수 있습니다.

# 동작하고 있는 상태를 반드시 커밋(commit)한 후
git add .
git commit -m "search 기능 추가 전의 상태"
...

잘 되었다면 main에 가져옵니다.

git switch main
git merge feature/search # 머지(merge)되었으므로, 뒷정리는 git branch -d feature/search 로 OK

만약 도중에 「역시 이 구현은 실패였다」라고 된다면, 그 변경을 버리고 나서 main으로 돌아가면 동작하고 있던 상태로 순식간에 돌아갈 수 있습니다.

⚠️ 이 부분이 미경험자가 빠지기 쉬운 함정입니다. feature/search에서 편집한 내용을 커밋(commit)도 파기(discard)도 하지 않은 채 git switch main을 하면, 그 변경 사항이 main 측으로 넘어오거나, 충돌(conflict)이 발생하는 경우 error: Your local changes would be overwritten 메시지와 함께 전환 자체가 거부됩니다. 「실패했으니까 방치하고 돌아가자」라고 그대로 두면, 돌아온 줄 알았는데 변경 사항이 남아 있는 사고가 발생합니다.

실패한 변경을 버리고 되돌아갈 경우에는 먼저 변경을 파기합니다.

git restore . # 커밋되지 않은 변경을 버림 (남겨두고 싶다면 git stash)
git switch main # 이것으로 안전하게 돌아갈 수 있음
git branch -D feature/search # 실패한 브랜치를 삭제 (머지되지 않았으므로 대문자 -D로 강제 삭제)

브랜치는 "실패해도 되돌릴 수 있는 작업장"으로 사용할 수 있으므로, 기능 추가와 같이 「망가뜨리는 것이 두려운 작업」과 특히 궁합이 좋습니다. 포인트는, 브랜치를 전환하기 전에 「커밋할 것」인지 「버릴 것(restore/stash)」인지를 확실히 하는 것입니다.

차분(diff)을 받아서 적용했다면, 반드시 스스로 동작시켜 확인합니다. AI의 제안이 기존 코드와 맞지 않아 에러가 날 수도 있습니다. 그 경우에는 에러 메시지를 그대로 전달하면 고쳐지지만, 「AI가 냈으니까 맞을 것이다」라며 확인을 스킵하면 망가진 채로 다음 단계로 넘어가 버리게 됩니다.

기존 코드에 대한 기능 추가를 AI에게 부탁할 때는, (1) 기존 코드를 붙여넣기, (2) 바꾸지 않을 범위를 명시하기, (3) 차분 형태로 부탁하기, (4) 한 번에 한 기능씩 부탁하기, 이 4가지 점으로 변경 범위를 최소화할 수 있습니다. 나아가 작업용 브랜치를 만들어 두면 실패해도 동작하고 있던 상태로 돌아갈 수 있습니다 (단, 전환하기 전에 변경을 커밋할지 버릴지를 반드시 확실히 할 것). 「망가뜨리는 것이 두렵다」를 시스템으로 해소하는 것이 요령입니다.

※ Qiita 독자분들에게는 너무 쉬운 내용이므로, 프로그래밍 미경험 지인에게 소개하거나, 사내 연수·후배 육성의 참고용으로 활용해 주세요.

미경험 상태에서 Next.js + Supabase + Claude Code로 웹 앱을 만들어 공개하기까지를 체계화한 교재가 있습니다.

• 우선 무료로 체험하기 (교재 체험판 · 첫 몇 세션은 무료로 체험 가능합니다) → https://github.com/ayies128/next-ai-camp-trial
• 교재 완전판 + 월 5,500엔의 멘토링 (총 20세션 + 채팅 질문 무제한) → https://menta.work/plan/20251?ref=qiita
• YouTube 『AI 엔지니어 정보국』 (AI × 개발 뉴스를 영상 1개당 5분 만에 파악할 수 있는 별도 운영 채널 · 무료) → https://www.youtube.com/channel/UC1rXVD9WYsQPQEWZyd-A1KA/?ref=qiita