기능 추가를 요청할 때 기존 코드를 망치지 않게 하는 법
1. 기능 추가가 기존 코드를 깨뜨리는 이유
AI에게 새 기능을 요청할 때 가장 흔한 문제는 “원하던 기능은 들어갔는데 기존 기능이 망가졌다”는 상황입니다. 이런 회귀 버그는 보통 AI가 나빠서 생기는 게 아니라, 요청 범위가 넓고 제약이 없어서 생깁니다. “검색 기능 추가해줘”처럼 목표만 주면 AI는 구현 편의를 위해 기존 구조를 크게 바꾸기도 합니다. 그 결과 기존 이벤트 흐름이나 상태 관리 규칙이 무너질 수 있습니다.
특히 프론트엔드에서는 작은 변경이 연쇄 영향을 만들기 쉽습니다. 필터 하나를 추가했는데 렌더링 조건이 바뀌고, 그 과정에서 정렬 로직이 깨지는 식입니다. 따라서 기능 추가 요청의 핵심은 “무엇을 만들지”보다 “무엇은 절대 건드리면 안 되는지”를 명확히 하는 데 있습니다. 안전한 요청은 구현 지시가 아니라 변경 계약에 가깝습니다.
2. 안전한 기능 추가 요청의 핵심 원칙
첫째, 변경 범위를 파일 단위로 제한하세요. “`search.ts`와 `SearchBar.tsx`만 수정”처럼 명시하면 불필요한 수정이 줄어듭니다. 둘째, 유지 조건을 적어야 합니다. 예: 기존 API 응답 타입 유지, 기존 테스트 통과, 기존 UI 동작 동일. 셋째, 기능 명세를 행동 단위로 작성해야 합니다. “검색 기능”보다 “엔터 또는 버튼 클릭 시 제목 기준 포함 검색, 대소문자 무시”처럼 구체화해야 오해가 줄어듭니다.
넷째, 출력 형식을 고정하면 검토가 쉬워집니다. “변경 파일 목록 → 코드 → 변경 이유 → 영향도” 순서로 요청하면 리뷰 속도가 빨라집니다. 다섯째, 단계별 반영을 권장합니다. 1차는 최소 기능(MVP), 2차는 예외 처리, 3차는 성능 개선으로 나누면 리스크를 통제할 수 있습니다.
| 요청 요소 | 없을 때 발생하는 문제 | 권장 문장 |
|---|---|---|
| 변경 범위 제한 | 관련 없는 파일까지 대규모 수정 | 수정 가능 파일은 `A.ts`, `B.tsx`로 제한 |
| 유지 조건 | 기존 기능 동작 회귀 | 기존 필터/정렬 동작은 동일하게 유지 |
| 명세 구체화 | 의도와 다른 동작 구현 | 입력 2글자 이상일 때만 검색 실행 |
| 출력 형식 지정 | 리뷰 어려움, 누락 확인 불가 | 변경 이유와 영향도 3줄 요약 포함 |
| 완료 기준 | 완성 여부 판단 불명확 | 타입 에러 0개, 기존 테스트 전부 통과 |
3. 복붙해서 쓰는 실전 요청 템플릿
실전에서 바로 쓸 수 있는 요청 문장은 다음과 같습니다. “기존 프로젝트에 [기능명]을 추가해줘. 수정 가능 범위는 [파일 목록]만 허용. 아래 항목은 유지: [기존 기능/타입/API/스타일 규칙]. 새 기능 명세: [입력-처리-출력 규칙]. 출력은 1) 변경 파일 목록 2) 코드 3) 변경 이유 4) 회귀 위험 포인트와 검증 방법 순서로 제공.” 이 구조는 단순 기능 추가가 아니라 품질 관리까지 함께 요구합니다.
여기에 “기존 코드 스타일 우선, 새로운 라이브러리 도입 금지”를 붙이면 코드베이스 일관성이 좋아집니다. 초보자가 놓치기 쉬운 부분은 “테스트 관점 요청”입니다. “기능 동작 확인용 테스트 시나리오 3개 제시”를 추가하면 배포 전 검증 품질이 크게 높아집니다.
4. 적용 후 회귀 버그를 막는 점검법
기능을 반영한 뒤에는 반드시 3단계로 확인하세요. 첫째, 기존 핵심 시나리오 재실행(로그인, 목록 조회, 저장 등). 둘째, 새 기능 경계값 테스트(빈 입력, 긴 입력, 중복 데이터). 셋째, 콘솔/네트워크 에러 확인. 이 과정을 짧게라도 고정하면 “동작은 되는데 숨은 버그가 남는” 문제를 크게 줄일 수 있습니다.
추가로 AI에게 후속 요청할 때는 결과를 피드백 데이터로 반환하세요. 예: “기존 시나리오 2번에서 실패, 에러는 401, 재현 단계는 …”처럼 전달하면 다음 수정 정확도가 올라갑니다. 결국 안전한 기능 추가는 뛰어난 코드를 한 번에 받는 것이 아니라, 변경 범위를 통제하고 검증 루프를 반복하는 운영 방식입니다.
5. 자주 묻는 질문
Q1. 작은 기능도 범위를 이렇게 엄격히 제한해야 하나요?
작은 기능일수록 범위 제한이 효과적입니다. 수정 범위가 명확하면 리뷰와 롤백이 쉬워지고, 예기치 않은 부작용이 줄어듭니다.
Q2. 기존 코드가 이미 복잡한데 기능 추가부터 해도 될까요?
가능하지만 위험합니다. 먼저 영향 파일을 식별하고, 최소 변경으로 동작하는 버전을 만든 뒤 점진 리팩터링하는 방식이 안전합니다.
Q3. AI가 자꾸 구조를 크게 바꾸려 하면 어떻게 해야 하나요?
“구조 변경 금지, 패치 방식으로 수정”을 명시하고 변경 허용 범위를 줄이세요. 필요하면 두 단계 요청으로 나눠 적용하는 것이 좋습니다.