처음 AI로 코딩을 시작했을 때는 프롬프트를 길게 작성해야 한다고 생각하지 않았습니다.
원하는 기능만 이야기하면 AI가 알아서 만들어줄 것 같았습니다.
예를 들면 이런 식입니다.
"Excel Download 기능 만들어줘."
또는
"이 오류 수정해줘."
간단한 작업이라면 이런 요청만으로도 원하는 결과가 나올 수 있습니다.
하지만 기존 프로젝트를 수정하거나 여러 기능이 연결된 시스템을 다루게 되면 이야기가 달라집니다.
어느 파일을 수정해야 하는지, 기존 기능을 유지해야 하는지, 어떤 방식으로 구현해야 하는지, 수정 후 무엇을 테스트해야 하는지까지 고려해야 하기 때문입니다.
Codex를 사용할 때도 마찬가지입니다.
OpenAI의 Codex는 코드베이스를 탐색하고 코드를 수정하며 명령어와 테스트를 실행하는 등의 개발 작업을 수행할 수 있는 코딩 에이전트입니다.
그래서 단순히 질문을 잘하는 것보다 어떤 작업을 어떤 조건으로 수행해야 하는지 명확하게 전달하는 것이 중요합니다.
이번 글에서는 비개발자가 Codex로 바이브코딩을 할 때 활용하기 좋은 프롬프트 작성 방법 10가지를 정리해보겠습니다.
1. 바로 수정하지 말고 먼저 프로젝트를 분석해달라고 한다
제가 가장 먼저 추천하고 싶은 방법입니다.
기존 프로젝트에서 작업한다면 처음부터
"이 기능 만들어줘."
라고 요청하기보다 먼저 현재 구조를 파악하도록 하는 것이 좋습니다.
예를 들어 다음과 같이 요청할 수 있습니다.
현재 프로젝트의 구조를 먼저 분석해줘.
주요 폴더와 파일이 어떤 역할을 하는지 설명하고, 이 기능과 관련된 파일이 어디에 있는지 찾아줘.
아직 코드는 수정하지 마.
여기서 중요한 문장은 **"아직 코드는 수정하지 마."**입니다.
특히 프로젝트가 익숙하지 않을 때는 바로 수정하는 것보다 Codex가 어떤 파일을 관련 파일이라고 판단하는지 먼저 확인하는 편이 좋습니다.
저처럼 개발자가 아니라면 이 과정 자체가 프로젝트를 이해하는 데도 도움이 됩니다.
2. 수정하기 전에 어떤 파일을 변경할지 물어본다
관련 기능을 찾았다면 다음에는 수정 범위를 확인합니다.
예를 들어 Excel Download 기능을 추가한다고 가정해보겠습니다.
단순하게,
"Excel Download 기능 추가해줘."
라고 요청하는 대신,
Excel Download 기능을 추가하려고 해.
현재 프로젝트를 확인해서 어떤 파일을 수정해야 하는지 먼저 알려줘.
각 파일을 왜 수정해야 하는지도 설명해줘.
내가 확인하기 전에는 코드를 변경하지 마.
라고 요청할 수 있습니다.
이렇게 하면 AI가 바로 여러 파일을 변경하는 것을 막고 변경 범위를 먼저 확인할 수 있습니다.
회사에서 사용하는 기존 시스템을 수정할 때는 특히 유용한 방법이라고 생각합니다.
3. 기존 코드를 최대한 유지하라고 명확하게 말한다
AI에게 새로운 기능을 요청하면 기능을 구현하는 데 집중하면서 기존 구조를 필요 이상으로 변경할 수도 있습니다.
그래서 저는 프롬프트에 이런 조건을 추가하는 것을 추천합니다.
기존 프로젝트 구조와 코딩 방식을 최대한 유지해줘.
새로운 구조를 만들기보다 기존에 비슷한 기능이 있다면 그것을 먼저 찾아서 재사용해줘.
필요한 부분만 최소한으로 수정해줘.
예를 들어 이미 다른 화면에 Excel Export 기능이 있다면 새로운 방식을 처음부터 만드는 것보다 기존 기능의 패턴을 활용하는 것이 더 적절할 수 있습니다.
특히 기존 시스템을 유지보수하는 상황에서는 새로운 코드를 만드는 능력만큼 기존 코드를 이해하는 능력도 중요합니다.
4. 원하는 결과뿐 아니라 '하지 말아야 할 것'도 알려준다
프롬프트를 작성하면서 의외로 중요한 것이 있습니다.
원하는 것만 설명하는 것이 아니라 원하지 않는 것도 알려주는 것입니다.
예를 들어,
기존 Approval Logic은 변경하지 마.
Database 구조는 변경하지 마.
기존 API는 그대로 사용해줘.
UI 디자인은 현재 화면과 동일하게 유지해줘.
필요한 부분 이외에는 리팩터링하지 마.
처럼 조건을 줄 수 있습니다.
저는 이런 조건을 일종의 **가드레일(Guardrail)**이라고 생각합니다.
AI에게 자유롭게 코딩하도록 하는 것보다 변경할 수 있는 범위를 명확하게 정해주는 것입니다.
5. 큰 기능은 작은 작업으로 나눠서 요청한다
처음 바이브코딩을 하면 이런 프롬프트를 작성하기 쉽습니다.
"Invoice Management System 만들어줘."
하지만 실제 업무 시스템은 하나의 기능처럼 보여도 내부적으로 여러 작업으로 나뉩니다.
그래서 큰 작업은 작은 단위로 나누는 것이 좋습니다.
예를 들어,
Step 1 — 기존 Invoice 관련 코드 찾기
Step 2 — 현재 데이터 구조 분석
Step 3 — Invoice List 화면 만들기
Step 4 — 검색 기능 추가
Step 5 — Excel Download 기능 추가
Step 6 — 권한 확인
Step 7 — 테스트
이런 식입니다.
Codex에는 다음과 같이 요청할 수도 있습니다.
이 기능을 바로 구현하지 말고 먼저 작은 작업 단위로 나눠줘.
각 작업의 목적과 수정해야 할 파일을 정리해줘.
내가 확인한 뒤 첫 번째 작업부터 하나씩 진행해줘.
작업을 작게 나누면 오류가 발생했을 때 어느 단계에서 문제가 생겼는지 찾기도 쉬워집니다.
6. 오류가 나면 "고쳐줘"보다 원인을 먼저 물어본다
AI 코딩을 하다 보면 오류를 자주 만나게 됩니다.
이때 가장 쉬운 요청은,
"이 오류 고쳐줘."
입니다.
하지만 이렇게 하면 오류는 해결되어도 왜 발생했는지 이해하지 못할 수 있습니다.
그래서 다음처럼 요청하는 편이 좋습니다.
아래 오류의 원인을 먼저 분석해줘.
어떤 파일과 코드에서 문제가 발생하는지 찾아줘.
개발자가 아닌 사람도 이해할 수 있도록 원인을 설명해줘.
아직 수정하지 말고 가능한 해결 방법을 먼저 알려줘.
해결 방법을 확인한 뒤,
가장 안전한 방법으로 수정해줘.
기존 기능에 영향을 줄 가능성이 있다면 먼저 알려줘.
라고 이어갈 수 있습니다.
이렇게 하면 Codex를 단순한 오류 수정 도구가 아니라 코드를 이해하는 도구로도 사용할 수 있습니다.
7. 모르는 부분은 추측하지 말라고 한다
업무 시스템을 개발할 때 특히 중요한 부분입니다.
AI가 모르는 업무 규칙을 임의로 판단하면 안 되기 때문입니다.
예를 들어 Approval 시스템을 수정한다고 가정해보겠습니다.
담당자가 누구인지, 어떤 상태에서 수정이 가능한지, 누가 승인할 수 있는지는 회사마다 다릅니다.
따라서 프롬프트에 이런 문장을 추가할 수 있습니다.
요구사항에서 명확하지 않은 부분은 임의로 판단하지 마.
업무 규칙이나 데이터 구조가 불분명하면 코드를 작성하기 전에 나에게 질문해줘.
이 한 문장을 추가하는 것만으로도 AI가 그럴듯한 가정을 기반으로 기능을 만드는 것을 줄이는 데 도움이 됩니다.
특히 Accounting, Approval, Contract처럼 업무 규칙이 중요한 시스템에서는 유용합니다.
8. 수정 후 변경된 내용을 설명해달라고 한다
Codex가 코드를 수정한 뒤 바로 다음 작업으로 넘어가기보다 무엇이 변경됐는지 확인하는 것이 좋습니다.
저는 이런 프롬프트를 추천합니다.
방금 수정한 내용을 정리해줘.
- 변경한 파일
- 각 파일에서 변경한 내용
- 변경한 이유
- 기존 기능에 영향을 줄 가능성
- 내가 테스트해야 할 항목
개발자가 아닌 사람도 이해할 수 있게 설명해줘.
이렇게 요청하면 단순히 코드 변경 결과만 보는 것보다 전체적인 변경 내용을 이해하기 쉽습니다.
나중에 오류가 생겼을 때 어느 부분을 수정했는지 다시 확인하는 데도 도움이 됩니다.
9. 테스트까지 하나의 작업으로 요청한다
기능이 화면에서 한 번 정상적으로 작동했다고 해서 개발이 끝난 것은 아닙니다.
예를 들어 Excel Download 기능이라면,
데이터가 없을 때는 어떻게 되는지,
검색 결과만 다운로드되는지,
특수문자가 있는 데이터도 정상적으로 저장되는지,
권한이 없는 사용자는 어떻게 되는지
등을 확인해야 할 수 있습니다.
그래서 기능 구현 후에는,
이 기능에서 발생할 수 있는 정상 케이스와 예외 케이스를 분석해줘.
테스트해야 할 항목을 체크리스트로 만들어줘.
자동으로 실행할 수 있는 테스트가 있다면 실행하고 결과를 알려줘.
라고 요청할 수 있습니다.
Codex의 장점 중 하나는 코드 작성뿐 아니라 테스트와 검증 과정에도 활용할 수 있다는 점입니다.
OpenAI 역시 Codex를 코드 작성, 디버깅, 테스트, 코드 이해와 같은 소프트웨어 개발 작업에 활용할 수 있는 도구로 설명하고 있습니다.
10. 마지막에는 전체 변경사항을 다시 검토하게 한다
작업을 여러 번 반복하다 보면 처음 요구사항과 최종 결과가 조금씩 달라질 수 있습니다.
그래서 기능 개발이 끝나면 마지막으로 전체 검토를 요청하는 것이 좋습니다.
제가 추천하는 마지막 프롬프트는 다음과 같습니다.
지금까지 이 작업에서 변경한 내용을 전체적으로 다시 검토해줘.
최초 요구사항과 현재 구현 결과를 비교하고 다음 항목을 확인해줘.
- 빠진 요구사항이 있는지
- 불필요하게 수정된 코드가 있는지
- 기존 기능에 영향을 줄 가능성이 있는지
- 보안상 문제가 될 부분이 있는지
- 추가로 테스트해야 할 항목이 있는지
문제가 발견되면 바로 수정하지 말고 먼저 나에게 알려줘.
특히 마지막 문장이 중요합니다.
검토를 요청했는데 AI가 또 코드를 수정하기 시작하면 새로운 변경사항이 생길 수 있기 때문입니다.
먼저 문제를 확인하고 그다음 수정하는 방식이 관리하기 쉽습니다.
같은 기능도 프롬프트에 따라 결과가 달라진다
예를 들어 두 개의 프롬프트를 비교해보겠습니다.
단순한 프롬프트
Excel Download 기능 만들어줘.
조금 더 구체적인 프롬프트
현재 프로젝트에서 기존 Excel Export 기능이 있는지 먼저 찾아줘.
현재 List 화면에 같은 방식의 Excel Download 기능을 추가하고 싶어.
기존 프로젝트 구조와 UI는 최대한 유지하고 필요한 파일만 최소한으로 수정해줘.
검색 필터가 적용되어 있다면 현재 화면에 표시되는 데이터만 다운로드되어야 해.
먼저 수정해야 할 파일과 구현 방법을 설명하고 내가 확인하기 전에는 코드를 변경하지 마.
요구사항이 불분명하면 추측하지 말고 질문해줘.
두 프롬프트 모두 같은 기능을 요청하고 있습니다.
하지만 두 번째 프롬프트에는 현재 상황, 기존 기능, 원하는 결과, 제한 조건, 작업 순서가 들어 있습니다.
AI 코딩을 하면서 중요한 것은 프롬프트를 무조건 길게 쓰는 것이 아니라 AI가 판단해야 하는 불확실성을 줄여주는 것이라고 생각합니다.
제가 Codex 프롬프트를 작성할 때 생각하는 5가지
프롬프트를 작성할 때 저는 다음 구조로 생각하면 편하다고 봅니다.
Context → Goal → Constraints → Process → Verification
예를 들어,
Context
현재 어떤 프로젝트에서 작업하고 있는가?
Goal
무엇을 만들거나 수정하고 싶은가?
Constraints
변경하면 안 되는 것은 무엇인가?
Process
분석부터 할 것인가, 바로 수정할 것인가?
Verification
수정 후 무엇을 테스트하고 확인해야 하는가?
이 다섯 가지가 들어가면 상당히 구체적인 개발 요청을 만들 수 있습니다.
비개발자가 바로 사용할 수 있는 Codex 프롬프트 템플릿
마지막으로 제가 가장 추천하는 형태를 하나로 합쳐보겠습니다.
현재 프로젝트를 먼저 분석해줘.
목표:
[추가하거나 수정하고 싶은 기능]요구사항:
[구체적인 기능 설명]조건:
- 기존 프로젝트 구조를 최대한 유지해줘.
- 기존에 비슷한 기능이 있다면 먼저 찾아서 재사용해줘.
- 필요한 파일만 최소한으로 수정해줘.
- 기존 기능에 영향을 줄 수 있는 변경은 먼저 알려줘.
- 요구사항이 불분명하면 임의로 판단하지 말고 질문해줘.
작업 순서:
- 관련 코드를 찾아줘.
- 수정해야 할 파일을 알려줘.
- 구현 방법을 설명해줘.
- 내가 확인한 후 코드를 수정해줘.
- 수정 후 변경사항을 정리해줘.
- 테스트해야 할 항목을 알려줘.
나는 개발자가 아니기 때문에 설명은 최대한 쉽게 해줘.
이 템플릿을 하나 저장해두고 목표와 요구사항만 바꿔가면서 사용하는 방법도 좋습니다.
마무리｜Codex에게 좋은 질문을 한다는 것
처음 AI 코딩을 접했을 때는 AI가 얼마나 좋은 코드를 만들어주는지가 가장 중요하다고 생각하기 쉽습니다.
하지만 실제 프로젝트에서는 무엇을 만들어달라고 요청하는지만큼 어떤 조건에서 어떻게 작업해야 하는지 알려주는 것도 중요합니다.
특히 Codex처럼 프로젝트의 코드를 살펴보고 실제 개발 작업을 수행할 수 있는 Coding Agent를 사용할 때는 더욱 그렇습니다.
제가 생각하는 좋은 Codex 프롬프트는 어려운 개발 용어가 가득한 프롬프트가 아닙니다.
현재 상황을 설명하고, 원하는 결과를 알려주고, 변경하면 안 되는 부분을 정하고, 작업 순서와 검증 방법을 명확하게 알려주는 것.
이 정도만 기억해도 충분합니다.
그리고 개발자가 아니라면 처음부터 완벽한 프로그램을 만들려고 하기보다,
분석 → 작은 수정 → 확인 → 테스트 → 다음 수정
순서로 진행하는 것이 좋습니다.
결국 바이브코딩에서도 중요한 것은 AI에게 모든 것을 맡기는 것이 아니라 AI가 올바른 방향으로 작업할 수 있도록 요구사항을 명확하게 전달하고 결과를 확인하는 것이라고 생각합니다.
0 Comments