AI 코딩을 처음 시작하면 새로운 코드를 만드는 것부터 생각하기 쉽습니다.
"이 기능을 만들어줘."
"이런 화면을 만들어줘."
하지만 실제 업무에서 개발 관련 작업을 하다 보면 새로운 프로그램을 처음부터 만드는 것보다 이미 만들어진 코드를 수정해야 하는 경우가 훨씬 많습니다.
저도 기존 시스템의 기능을 보면서 작은 부분을 변경하거나 새로운 기능을 추가해야 하는 상황을 자주 접합니다.
이럴 때 가장 걱정되는 부분은 새로운 기능 자체가 아닙니다.
"이 부분을 수정하면 기존 기능에 문제가 생기지 않을까?"
개발자가 아니라면 더욱 그렇습니다.
그래서 Codex를 이용해 기존 코드를 수정할 때는 단순히
"이 코드 수정해줘."
라고 요청하기보다 기존 구조를 먼저 분석하고 → 변경 범위를 확인하고 → 최소한으로 수정하고 → 마지막으로 테스트하는 방식으로 접근하는 것이 좋습니다.
이번 글에서는 기존 프로젝트를 수정할 때 사용할 수 있는 Codex 프롬프트 작성법을 실제 업무 시스템을 예로 들어 정리해보겠습니다.
새로운 코드를 만드는 것과 기존 코드를 수정하는 것은 다르다
새로운 프로그램을 만드는 경우에는 비교적 자유롭게 구조를 결정할 수 있습니다.
하지만 이미 운영되고 있는 시스템은 다릅니다.
하나의 버튼이 다른 함수와 연결되어 있을 수도 있고, 화면에서 입력한 데이터가 API를 거쳐 Database에 저장될 수도 있습니다.
Approval이나 Accounting 관련 시스템이라면 하나의 상태값 변경이 다음 프로세스에 영향을 줄 수도 있습니다.
그래서 기존 코드를 수정할 때 제가 중요하다고 생각하는 것은 "원하는 기능이 작동하는가?"만 확인하는 것이 아닙니다.
"기존 기능이 그대로 작동하는가?"
까지 확인해야 합니다.
이 차이를 Codex에게도 명확하게 알려주는 것이 좋습니다.
1. 처음부터 "수정해줘"라고 하지 않는다
기존 코드를 수정할 때 가장 먼저 할 일은 현재 코드가 어떻게 작동하는지 파악하는 것입니다.
예를 들어 기존 화면에 Excel Download 기능을 추가하고 싶다고 가정해보겠습니다.
바로 이렇게 요청할 수도 있습니다.
Excel Download 기능 추가해줘.
하지만 저는 먼저 다음과 같이 요청하는 방식을 추천합니다.
현재 프로젝트를 분석해서 이 화면과 관련된 코드를 찾아줘.
화면이 어떤 파일에서 만들어지고 데이터를 어디에서 가져오는지 설명해줘.
관련된 Frontend, Backend, API 파일이 있다면 함께 알려줘.
아직 어떤 코드도 수정하지 마.
나는 개발자가 아니기 때문에 최대한 쉽게 설명해줘.
핵심은 마지막 두 문장입니다.
아직 수정하지 말 것.
쉽게 설명할 것.
먼저 Codex가 프로젝트를 어떻게 이해하고 있는지 확인한 다음 실제 수정으로 넘어가는 것입니다.
2. 비슷한 기존 기능부터 찾아달라고 한다
기존 프로젝트에는 내가 만들려는 기능과 비슷한 기능이 이미 있을 수 있습니다.
예를 들어 A 화면에는 이미 Excel Download가 있는데 B 화면에는 없다고 생각해보겠습니다.
이런 경우 새로운 Excel 기능을 처음부터 만드는 것보다 기존 구현 방식을 재사용하는 편이 나을 수 있습니다.
Codex에는 이렇게 요청할 수 있습니다.
현재 프로젝트 전체에서 Excel Download 또는 Excel Export 기능이 이미 구현되어 있는지 찾아줘.
있다면 어떤 파일에서 어떤 방식으로 구현되어 있는지 설명해줘.
현재 화면에도 동일한 패턴을 적용할 수 있는지 검토해줘.
아직 코드는 변경하지 마.
이 방법은 특히 오래된 프로젝트나 여러 개발자가 함께 만든 프로젝트를 수정할 때 유용합니다.
AI에게 무조건 새로운 코드를 생성하게 하는 것이 아니라 기존 프로젝트가 사용하는 방식을 먼저 찾게 하는 것입니다.
3. 어떤 파일을 수정할 것인지 먼저 확인한다
다음으로 확인하고 싶은 것은 변경 범위입니다.
Codex에게 다음과 같이 요청할 수 있습니다.
이 기능을 구현하기 위해 수정해야 하는 파일을 먼저 정리해줘.
각 파일별로 다음 내용을 알려줘.
- 파일 이름과 경로
- 현재 역할
- 수정해야 하는 이유
- 예상 변경 내용
- 기존 기능에 영향을 줄 가능성
아직 실제 코드는 변경하지 마.
예를 들어 Codex의 분석 결과가 다음과 같다고 생각해보겠습니다.
invoice_list.js — 버튼 추가
invoice.py — Excel 데이터 생성
invoice_api.py — Download API 연결
이렇게 먼저 범위를 확인하면 갑자기 관련 없는 파일까지 수정되는 것을 발견하기 쉽습니다.
4. "최소한으로 수정해줘"라는 조건을 넣는다
기존 프로젝트에서는 이것도 중요한 프롬프트라고 생각합니다.
기존 코드를 최대한 유지하고 이번 기능을 구현하는 데 필요한 부분만 최소한으로 수정해줘.
관련 없는 코드는 리팩터링하지 마.
변수명이나 함수명도 특별한 이유가 없다면 변경하지 마.
현재 프로젝트에서 사용하는 기존 패턴을 최대한 따라줘.
예를 들어 버튼 하나를 추가하려고 했는데 AI가 관련 코드를 전부 새로운 구조로 바꿔버리면 나중에 변경 내용을 검토하기가 어려워질 수 있습니다.
특히 비개발자는 변경된 코드가 많아질수록 무엇이 중요한 변경인지 판단하기 어렵습니다.
그래서 저는 Small Change를 기본 원칙으로 잡는 것이 좋다고 생각합니다.
5. 변경하면 안 되는 부분도 알려준다
AI에게 무엇을 해야 하는지만 알려주는 것보다 무엇을 하면 안 되는지도 알려주는 것이 중요합니다.
예를 들어 Approval 화면을 수정한다고 생각해보겠습니다.
다음과 같이 요청할 수 있습니다.
Approval 화면에
[새로운 기능]을 추가해줘.단, 다음 부분은 변경하지 마.
- 기존 Approval Logic
- 기존 Status 값
- Database 구조
- 기존 API Response 형식
- 사용자 권한 로직
위 항목 중 변경이 반드시 필요한 부분이 있다면 임의로 변경하지 말고 먼저 이유를 설명해줘.
이렇게 하면 Codex가 작업할 수 있는 범위를 더 명확하게 정할 수 있습니다.
6. 모르는 업무 규칙은 추측하지 말라고 한다
AI가 코드를 잘 작성하더라도 회사의 업무 규칙까지 모두 알고 있는 것은 아닙니다.
예를 들어,
Draft → Submitted → Approved → Completed
라는 Status가 있다고 가정해보겠습니다.
Codex는 코드 구조를 보고 관계를 어느 정도 분석할 수 있지만,
누가 Approved 상태로 변경할 수 있는지
Approved 이후 수정이 가능한지
Completed 상태에서 파일을 변경할 수 있는지
같은 회사의 정책을 임의로 판단해서는 안 됩니다.
그래서 다음 문장을 프롬프트에 자주 넣어두면 좋습니다.
업무 규칙이 명확하지 않은 부분은 임의로 추측하지 마.
기존 코드에서도 규칙을 확인할 수 없다면 구현하기 전에 나에게 질문해줘.
비개발자가 AI 코딩을 할 때 상당히 중요한 조건입니다.
7. 한 번에 여러 기능을 수정하지 않는다
예를 들어 이런 요구사항이 있다고 생각해보겠습니다.
Invoice 화면을 수정하고 검색 기능을 추가하고 Excel Download를 만들고 Approval 기능도 추가해줘.
한 번에 요청할 수도 있지만 저는 작은 작업으로 나누는 방식을 추천합니다.
먼저 Codex에게 작업을 나눠달라고 요청합니다.
이 요구사항을 바로 구현하지 말고 독립적으로 테스트할 수 있는 작은 작업 단위로 나눠줘.
작업 순서를 추천하고 각 단계에서 어떤 파일을 수정해야 하는지 알려줘.
아직 코드는 변경하지 마.
그다음,
Task 1 완료 → 테스트 → Task 2 → 테스트 → Task 3
형태로 진행합니다.
문제가 발생했을 때 어느 변경에서 문제가 시작되었는지 확인하기 쉬워집니다.
8. 오류가 발생하면 바로 다시 수정하지 않는다
코드를 수정한 뒤 오류가 발생했다고 가정해보겠습니다.
이때,
오류 났어. 고쳐줘.
라고 요청하기보다 원인을 먼저 확인하는 편이 좋습니다.
방금 변경한 코드 이후 다음 오류가 발생했어.
[ERROR MESSAGE]바로 코드를 수정하지 말고 먼저 원인을 분석해줘.
이번 변경과 관련된 오류인지 확인하고 문제가 발생한 파일과 코드를 알려줘.
기존 코드 문제인지 이번 변경으로 발생한 문제인지도 구분해줘.
가능한 해결 방법을 설명한 뒤 내가 확인할 때까지 수정하지 마.
이렇게 요청하면 오류를 해결하기 위해 또 다른 변경이 계속 추가되는 것을 줄이는 데 도움이 됩니다.
9. 수정이 끝나면 Diff 관점으로 설명해달라고 한다
코드를 수정한 다음에는 무엇이 달라졌는지 확인해야 합니다.
Codex에 이렇게 요청할 수 있습니다.
이번 작업에서 변경된 내용을 정리해줘.
변경 전과 변경 후를 비교해서 설명해줘.
파일별로 다음 내용을 알려줘.
- 어떤 코드가 변경되었는지
- 왜 변경했는지
- 새로운 기능이 어떻게 작동하는지
- 기존 기능에 영향을 줄 가능성이 있는지
- 내가 직접 확인해야 하는 부분
개발자가 아닌 사람도 이해할 수 있게 설명해줘.
코드 한 줄 한 줄을 모두 이해하지 못하더라도 변경 목적과 범위는 파악할 수 있어야 합니다.
10. 마지막에는 반드시 기존 기능까지 테스트한다
새로운 기능이 정상적으로 작동한다고 작업을 끝내면 안 됩니다.
예를 들어 Excel Download 버튼을 추가했다면 Excel 파일이 다운로드되는 것만 확인하기 쉽습니다.
하지만 실제로는 기존의
검색
Filter
Pagination
권한
화면 이동
등이 그대로 작동하는지도 확인해야 할 수 있습니다.
Codex에는 다음과 같이 요청할 수 있습니다.
이번 변경으로 영향을 받을 가능성이 있는 기존 기능을 찾아줘.
새로 추가한 기능뿐 아니라 기존 기능을 포함해서 테스트해야 할 항목을 정리해줘.
정상 Case와 Edge Case를 포함하고 각 테스트의 예상 결과도 알려줘.
자동으로 실행할 수 있는 기존 테스트가 있다면 먼저 어떤 테스트인지 알려줘.
Codex는 코드 작성뿐 아니라 테스트 작성과 실행 같은 개발 작업에도 활용할 수 있습니다.
기존 코드 수정할 때 제가 추천하는 Codex 프롬프트
위 내용을 하나의 프롬프트로 합치면 다음처럼 사용할 수 있습니다.
현재 프로젝트에
[추가/수정할 기능]을 구현하려고 해.목표
[원하는 결과를 구체적으로 설명]작업 원칙
- 먼저 현재 프로젝트와 관련 코드를 분석해줘.
- 기존에 비슷한 기능이 있다면 먼저 찾아줘.
- 기존 프로젝트 구조와 코딩 패턴을 최대한 유지해줘.
- 필요한 부분만 최소한으로 수정해줘.
- 관련 없는 코드는 리팩터링하지 마.
- 기존 업무 로직과 권한은 변경하지 마.
- 명확하지 않은 업무 규칙은 추측하지 말고 나에게 질문해줘.
작업 순서
- 관련 파일을 찾아줘.
- 현재 코드가 어떻게 작동하는지 설명해줘.
- 수정해야 할 파일과 이유를 알려줘.
- 기존 기능에 미칠 수 있는 영향을 알려줘.
- 아직 코드를 변경하지 말고 내가 확인할 때까지 기다려줘.
내가 구현을 요청한 후에는 필요한 부분만 수정하고 변경된 파일과 테스트해야 할 항목을 정리해줘.
나는 개발자가 아니기 때문에 설명은 최대한 쉽게 해줘.
이 프롬프트를 기본 템플릿으로 저장해놓고 [ ] 안의 내용만 바꿔 사용하면 편리합니다.
Bad Prompt와 Good Prompt를 비교해보면
예를 들어 기존 시스템에 Excel Download 기능을 추가한다고 해보겠습니다.
Bad Prompt
Excel Download 기능 추가해줘.
간단하지만 Codex 입장에서는 판단해야 할 것이 많습니다.
어느 화면인지,
어떤 데이터를 다운로드해야 하는지,
기존 Export 기능이 있는지,
Filter가 적용되어야 하는지,
어떤 파일 형식이어야 하는지 알 수 없습니다.
Good Prompt
현재 Invoice List 화면에 Excel Download 기능을 추가하고 싶어.
먼저 프로젝트 전체에서 기존 Excel Export 기능이 있는지 찾아줘.
기존 기능이 있다면 같은 방식을 최대한 재사용해줘.
현재 Invoice List에 적용된 Filter가 있다면 Filter 결과만 다운로드되어야 해.
기존 UI, Filter Logic, Database 구조는 변경하지 마.
먼저 관련 파일과 수정 방법을 알려주고 아직 코드는 변경하지 마.
요구사항이 불명확한 부분이 있다면 추측하지 말고 질문해줘.
두 프롬프트 모두 "Excel Download"라는 같은 기능을 요청하고 있습니다.
차이는 Codex가 스스로 판단해야 하는 부분을 얼마나 줄였는가입니다.
좋은 AI 코딩 프롬프트는 어려운 개발 용어를 많이 쓰는 프롬프트가 아니라 내가 원하는 것과 원하지 않는 것을 명확하게 알려주는 프롬프트라고 생각합니다.
비개발자에게 Codex가 유용한 이유
개발자가 아닌 입장에서 기존 코드를 수정할 때 가장 어려운 부분은 직접 코드를 작성하는 것만은 아닙니다.
어느 파일을 봐야 하는지
이 코드가 왜 필요한지
어떤 기능과 연결되어 있는지
수정하면 어디에 영향을 주는지
를 파악하는 것도 어렵습니다.
그래서 Codex를 단순히 코드를 대신 작성하는 도구로만 사용하기보다 기존 프로젝트를 이해하는 도구로 활용하는 방법도 좋습니다.
저는 이런 식의 질문이 특히 유용하다고 생각합니다.
"이 기능이 어디에서 시작되는지 찾아줘."
"이 버튼을 누르면 어떤 코드가 실행되는지 알려줘."
"이 코드를 수정하면 어떤 기능에 영향을 줄 수 있는지 알려줘."
"수정하기 전에 내가 알아야 할 내용을 설명해줘."
비개발자에게는 코드를 만들어주는 것만큼 이런 설명이 중요할 수 있습니다.
기존 코드 수정에서 중요한 것은 '많이 바꾸는 것'이 아니다
AI를 사용하면 짧은 시간 안에 많은 코드를 생성하고 수정할 수 있습니다.
하지만 실제 운영 시스템에서는 얼마나 많은 코드를 바꿨는지가 중요한 것이 아닙니다.
필요한 기능을 구현하면서 기존 시스템에 미치는 영향을 최소화하는 것이 더 중요합니다.
그래서 저는 기존 코드를 수정할 때 다음 흐름으로 접근하는 방법을 추천합니다.
기존 코드 분석 → 비슷한 기능 찾기 → 변경 범위 확인 → 작은 단위로 수정 → 변경사항 검토 → 기존 기능 포함 테스트
Codex가 코드를 빠르게 작성해줄 수 있다고 해도 이 과정 자체를 생략해서는 안 됩니다.
마무리｜Codex에게 바로 코드를 고치게 하지 않는 이유
Codex를 처음 사용하면 가장 신기한 부분은 AI가 실제 코드를 수정할 수 있다는 점일 수 있습니다.
하지만 기존 프로젝트를 다룰수록 저는 "얼마나 빨리 코드를 수정하는가"보다 "무엇을 수정하는지 알고 있는가"가 중요하다고 생각합니다.
특히 개발자가 아닌 사람이라면 처음부터 Codex에게 모든 것을 맡길 필요가 없습니다.
먼저,
"이 코드가 어떻게 작동하는지 설명해줘."
그다음,
"어디를 수정해야 하는지 알려줘."
그리고,
"기존 기능을 유지하면서 필요한 부분만 수정해줘."
마지막으로,
"무엇이 바뀌었고 무엇을 테스트해야 하는지 알려줘."
라고 요청하는 것입니다.
이런 방식으로 한 단계씩 진행하면 Codex를 단순한 코드 생성기가 아니라 기존 프로젝트를 분석하고 수정하는 AI 코딩 파트너로 활용할 수 있습니다.
AI 코딩과 바이브코딩을 처음 시작한다면 새로운 프로그램 전체를 만드는 것보다 기존 프로젝트의 작은 기능 하나를 이해하고 수정해보는 것부터 시작하는 것도 좋은 방법입니다
0 Comments