여름휴가 뒤 AI 코딩 프로젝트는 어디부터 다시 시작할까?

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

며칠간 여름휴가를 보내고 저장소를 다시 열었는데 브랜치는 늘었고, 의존성 업데이트 알림과 리뷰 요청까지 쌓여 있다면 곧바로 AI 코딩 에이전트부터 실행하고 싶어집니다. 하지만 기억이 흐릿한 상태에서 “남은 작업을 전부 처리해 줘”라고 지시하면 이미 완료된 기능을 다시 만들거나, 다른 개발자의 변경을 덮어쓰거나, 보안상 민감한 파일을 컨텍스트에 포함하는 문제가 생길 수 있습니다.

휴가 복귀 후 필요한 것은 빠른 코드 생성이 아니라 프로젝트 상태를 안전하게 복원하는 순서입니다. 특히 8월에는 휴가 일정이 서로 엇갈려 담당자가 없는 경우가 많으므로, AI가 제안한 내용을 바로 반영하기보다 저장소의 사실과 사람의 판단을 분리해야 합니다.

코드를 고치기 전에 프로젝트의 현재 시각부터 맞춥니다

기억이 아니라 저장소를 기준으로 복귀 지도를 만드세요

휴가 전 마지막으로 만졌던 파일부터 여는 방식은 익숙하지만 정확하지 않습니다. 그사이 병합된 커밋, 변경된 API 명세, 새로 등록된 이슈가 있을 수 있기 때문입니다. 먼저 기본 브랜치의 최신 상태, 열린 풀 리퀘스트, 최근 배포 기록, 실패한 자동화 작업을 읽고 현재 상태와 내가 기억하는 상태의 차이를 찾아야 합니다.

AI 코딩 도구에는 처음부터 수정 권한을 주지 말고 요약 역할만 맡기는 편이 안전합니다. “최근 10영업일의 커밋을 기능·버그 수정·설정 변경으로 분류하고, 근거가 된 커밋 번호를 함께 표시해 줘”처럼 범위와 출처를 지정해 보세요. 답변에 근거가 없으면 그 항목은 사실이 아니라 추정으로 취급합니다.

• 기본 브랜치: 마지막 휴가 전 커밋과 현재 HEAD 사이의 변경 범위를 확인합니다.
• 풀 리퀘스트: 병합 완료, 리뷰 대기, 충돌 발생 상태를 나눠 봅니다.
• 배포 기록: 코드가 병합됐더라도 실제 운영에 반영됐는지 따로 확인합니다.
• 이슈와 문서: 요구사항이 수정됐거나 작업 우선순위가 바뀌지 않았는지 살핍니다.
• CI 결과: 휴가 중 새로 실패하기 시작한 테스트와 기존의 간헐적 실패를 구별합니다.

복귀 첫 프롬프트의 목적은 작업 수행이 아니라 상황 재구성입니다. AI가 제시한 모든 문장에 커밋, 파일 경로, 이슈 번호 중 하나를 근거로 붙이게 하면 환각을 훨씬 쉽게 발견할 수 있습니다.

30분 안에 읽을 정보의 우선순위를 정합니다

알림을 시간순으로 모두 읽으면 중요한 변경이 사소한 대화에 묻힙니다. 운영 장애와 롤백, 보안 관련 수정, 데이터 구조 변경을 먼저 보고 그다음 외부 API와 공용 인터페이스 변경을 확인하세요. UI 문구나 코드 스타일 변경은 실제 작업에 영향을 줄 때까지 뒤로 미뤄도 됩니다.

1. 운영 장애·긴급 수정·롤백 여부를 확인합니다.
2. 데이터베이스 스키마와 인증·권한 변경을 찾습니다.
3. 내가 담당한 모듈의 공개 인터페이스 변경을 읽습니다.
4. 진행 중인 브랜치와 최신 기본 브랜치의 차이를 계산합니다.
5. 오늘 처리할 항목을 하나만 골라 작은 작업 단위로 바꿉니다.

휴가 전 브랜치는 합치기보다 생존 여부부터 판별합니다

계속 작업할 브랜치와 버릴 브랜치를 구분하세요

오래된 브랜치를 발견했다고 무조건 최신 기본 브랜치를 병합하면 충돌의 의미를 파악하기 어려워집니다. 먼저 그 브랜치의 목적이 아직 유효한지, 같은 기능이 다른 풀 리퀘스트에서 구현되지 않았는지, 요구사항이 변경되지 않았는지 확인해야 합니다. 작업 가치가 사라진 브랜치라면 충돌 해결에 시간을 쓰는 것보다 변경 내용을 기록하고 닫는 편이 낫습니다.

AI에게 브랜치 차이를 설명시킬 때는 파일 수만 세지 말고 행동 변화를 중심으로 비교하게 하세요. 예를 들어 “결제 실패 시 재시도 횟수, 사용자에게 보이는 메시지, 로그에 남는 필드가 기본 브랜치와 어떻게 다른가”라고 묻는 방식입니다. 이렇게 해야 단순 문법 충돌과 제품 동작의 충돌을 구별할 수 있습니다.

• 마지막 커밋 메시지만 보지 말고 실제 diff와 테스트를 함께 읽습니다.
• 자동 생성 파일과 잠금 파일의 충돌은 원본 설정 변경을 먼저 확인합니다.
• 충돌 해결 후에는 기존 테스트 통과만으로 끝내지 않고 변경된 요구사항을 새 테스트로 추가합니다.
• 폐기할 브랜치도 결정 이유와 재사용 가능한 커밋을 이슈에 남깁니다.

AI가 만든 충돌 해결안을 작은 단위로 검증합니다

충돌 파일 전체를 한 번에 수정하게 하면 정상 코드까지 재작성될 수 있습니다. 파일별로 충돌 원인을 설명하게 하고, 해결 패치를 먼저 diff 형태로 검토한 다음 적용하세요. 하나의 커밋에는 가능한 한 한 가지 의도만 담아야 문제가 생겼을 때 되돌리기 쉽습니다.

특히 인증, 결제, 개인정보 처리 코드에서는 “빌드 성공”이 안전을 뜻하지 않습니다. 코드 보호 개념을 다시 확인할 필요가 있다면 코드 보안 관련 지식백과 설명을 참고하고, 변경 전후의 입력 검증과 권한 검사를 별도 항목으로 비교하는 것이 좋습니다.

1. 충돌이 난 두 변경의 의도를 각각 한 문장으로 적습니다.
2. 유지해야 할 테스트와 새로 필요한 테스트를 구분합니다.
3. AI가 제안한 최소 패치를 사람이 diff로 확인합니다.
4. 단위 테스트, 통합 테스트, 실제 사용 흐름 순으로 검증합니다.

8월의 의존성 알림은 업데이트와 보안 대응을 나눠 처리합니다

버전 숫자가 아니라 위험의 성격을 읽으세요

휴가 중 쌓인 의존성 업데이트를 모두 한 풀 리퀘스트에 넣으면 장애 원인을 찾기 어려워집니다. 보안 취약점 수정, 런타임 호환성 확보, 기능 추가, 단순 유지보수 업데이트를 분리하세요. 긴급 보안 수정은 작은 패치로 먼저 처리하되, 메이저 버전 변경이나 프레임워크 전환은 별도의 검증 일정으로 옮기는 편이 안정적입니다.

월 구독형 AI 도구를 쓰더라도 비용보다 먼저 확인할 것은 외부 전송 범위입니다. 환경 변수 파일, 운영 로그, 고객 데이터 샘플, 비공개 패키지 주소가 프롬프트나 첨부 컨텍스트에 들어가지 않도록 제외 규칙을 점검하세요. 비밀값을 가린 로그와 재현에 필요한 최소 코드만 제공해도 대부분의 의존성 오류는 충분히 분석할 수 있습니다.

• 즉시 처리: 실제 사용 경로에 영향을 주는 고위험 취약점과 배포 차단 오류
• 이번 주 처리: 지원 종료가 임박한 런타임, 반복적으로 실패하는 빌드 도구
• 별도 계획: 메이저 버전 상승, 설정 형식 변경, 데이터 마이그레이션 동반 업데이트
• 보류 가능: 사용하지 않는 개발 보조 패키지의 경미한 변경과 단순 문서 업데이트

취약점 경고의 심각도만 보고 순서를 정하지 마세요. 해당 패키지가 운영 번들에 포함되는지, 취약한 함수가 실제 호출되는지, 외부 입력이 그 경로에 도달하는지까지 확인해야 실질적인 우선순위가 보입니다.

업데이트 한 건마다 되돌릴 길을 남깁니다

AI에게 여러 패키지를 동시에 올리게 하기보다 직접 의존성 하나와 관련 잠금 파일 변경을 한 묶음으로 관리하세요. 설치, 빌드, 테스트, 스테이징 확인 결과를 풀 리퀘스트에 기록하면 담당자가 다시 휴가를 가더라도 다음 사람이 판단을 이어갈 수 있습니다.

보안 검토의 범위를 잡을 때는 코드 보안 요약 자료처럼 기본 개념을 확인한 뒤, 프로젝트의 위협 모델에 맞춰 질문을 구체화하세요. “안전한가?”보다는 “업데이트 후 인증되지 않은 요청이 관리자 API에 도달할 새 경로가 생겼는가?”가 검증 가능한 질문입니다.

1. 현재 버전과 목표 버전의 변경 기록을 읽습니다.
2. 직접 의존성과 간접 의존성의 변화를 분리합니다.
3. 잠금 파일에서 예상 밖의 대규모 변경이 있는지 확인합니다.
4. 기능 테스트뿐 아니라 권한, 입력 검증, 오류 로그를 점검합니다.
5. 문제가 생겼을 때 되돌릴 커밋과 배포 절차를 기록합니다.

쇼핑몰 결제 브랜치를 되살리는 복귀 첫날을 따라가 봅니다

오전 9시부터 배포 후보를 만들기까지

개발자 서윤은 여름휴가 전 ‘쿠폰 적용 후 결제 금액 재계산’ 브랜치를 남겨 두었습니다. 복귀한 월요일 오전 9시, 바로 코드를 이어 쓰는 대신 AI에게 최근 7영업일의 커밋과 열린 풀 리퀘스트를 읽고 결제 모듈에 영향을 준 변경만 근거와 함께 표로 만들게 했습니다. 그 결과 휴가 중 세금 계산 함수의 반환 형식이 숫자에서 객체로 바뀌었고, 다른 개발자가 결제 실패 로그의 필드를 추가했다는 사실을 확인했습니다.

오전 10시에는 자신의 브랜치와 기본 브랜치를 비교했습니다. AI는 충돌 파일 세 개를 제시했지만 서윤은 자동 해결을 승인하지 않았습니다. 대신 각 충돌이 문법 차이인지 동작 차이인지 설명하게 했고, 쿠폰 테스트가 예전 반환 형식을 가정한다는 점을 찾아냈습니다. 그는 새 세금 계산 함수를 먼저 반영하고 테스트 기대값을 수정한 뒤, 쿠폰 계산 코드만 별도 커밋으로 재적용했습니다.

• 09:00 최근 변경을 읽기 전용으로 요약하고 커밋 번호를 대조했습니다.
• 10:00 브랜치의 유효성을 확인하고 충돌을 세 가지 원인으로 분류했습니다.
• 11:30 반환 형식 변경을 반영한 테스트를 먼저 작성했습니다.
• 14:00 쿠폰 계산 패치를 작은 커밋으로 적용하고 전체 결제 테스트를 실행했습니다.
• 16:00 스테이징에서 일반 쿠폰, 최대 할인, 만료 쿠폰 시나리오를 직접 재현했습니다.

한 번의 실패를 배포 근거로 바꾸는 과정

오후 테스트에서는 최대 할인 쿠폰을 적용할 때 화면 금액은 맞지만 서버 로그의 할인액이 0으로 남는 문제가 발견됐습니다. AI는 화면 계산 결과를 로그 객체에 복사하는 수정을 제안했지만, 서윤은 로그가 결제 승인 전 값을 기록하도록 설계됐다는 사실을 문서에서 확인했습니다. 제안을 그대로 적용하면 감사 기록의 의미가 달라질 수 있었던 상황입니다.

서윤은 로그 구조를 억지로 바꾸지 않고 승인 전 금액과 승인 후 금액을 서로 다른 필드로 남기는 새 요구사항을 팀에 확인했습니다. 이후 타입 정의, 로그 생성 함수, 개인정보 마스킹 테스트를 차례로 수정했습니다. 일반적인 코드 개념과 표현을 팀원에게 설명할 때는 코드 관련 지식백과 자료도 참고하되, 실제 판단 근거는 저장소의 명세와 테스트에 두었습니다.

1. AI 제안이 기존 로그의 의미를 바꾸는지 문서와 대조했습니다.
2. 제품 담당자에게 승인 전후 금액을 분리해도 되는지 확인했습니다.
3. 민감 정보가 새 로그 필드에 포함되지 않는지 마스킹 테스트를 추가했습니다.
4. 풀 리퀘스트에 휴가 중 변경점, 버린 접근, 수동 검증 결과를 기록했습니다.
5. 당일 자동 배포는 피하고 다음 날 담당자 두 명의 리뷰 후 배포하도록 예약했습니다.

오후 5시 30분, 서윤의 결과물은 거대한 기능 추가가 아니라 검토 가능한 네 개의 작은 커밋과 재현 가능한 테스트 기록이었습니다. 복귀 첫날의 속도는 작성한 코드 줄 수가 아니라, 흐릿했던 프로젝트 상태를 얼마나 정확한 근거로 바꾸었는지에서 드러납니다.