AI로 코딩을 처음 시작했을 때 가장 어려운 것은 코딩 자체보다 AI에게 어떻게 요청해야 하는지였습니다.
Codex를 열어놓고도 막상 무엇을 입력해야 할지 고민하게 됩니다.
"이 기능 만들어줘."
"이 오류 고쳐줘."
처음에는 저도 이런 짧은 질문이면 충분하다고 생각했습니다.
물론 간단한 작업은 이렇게 요청해도 결과가 나올 수 있습니다.
하지만 기존 프로젝트를 분석하거나 새로운 기능을 추가하고, 오류를 수정하고, 테스트까지 해야 하는 상황에서는 조금 더 구체적으로 요청하는 것이 좋습니다.
특히 비개발자라면 Codex에게 무조건 코드를 작성하게 하기보다,
프로젝트 분석 → 관련 코드 찾기 → 변경 방법 확인 → 코드 수정 → 테스트
순서로 진행하면 훨씬 이해하기 쉽습니다.
이번 글에서는 제가 비개발자의 입장에서 유용하다고 생각하는 Codex 프롬프트 20개를 상황별로 정리해봤습니다.
필요한 프롬프트를 그대로 복사한 뒤 [ ] 부분만 자신의 프로젝트에 맞게 변경해서 사용할 수 있습니다.
1. 프로젝트 전체 구조 분석하기
처음 보는 프로젝트라면 바로 코드를 수정하기보다 전체 구조부터 파악하는 것이 좋습니다.
Codex 프롬프트
현재 프로젝트의 전체 구조를 분석해줘.
주요 폴더와 파일이 어떤 역할을 하는지 설명하고 Frontend, Backend, Database, API 등으로 구분할 수 있다면 구분해서 알려줘.
프로젝트가 어떤 순서로 실행되는지도 설명해줘.
나는 개발자가 아니기 때문에 전문적인 개발 용어는 최대한 쉽게 설명해줘.
아직 코드는 수정하지 마.
처음 프로젝트를 열었는데 파일이 너무 많아서 어디부터 봐야 할지 모를 때 유용합니다.
2. 특정 기능이 어디에 있는지 찾기
프로젝트 전체를 이해했다면 특정 기능의 위치를 찾을 수 있습니다.
Codex 프롬프트
현재 프로젝트에서
[기능 이름]기능을 담당하는 코드를 찾아줘.관련된 파일을 모두 알려주고 각각 어떤 역할을 하는지 설명해줘.
사용자가 이 기능을 실행했을 때 어떤 순서로 코드가 실행되는지도 쉽게 설명해줘.
아직 코드는 변경하지 마.
예를 들어 [기능 이름]에 Excel Download, Login, Approval, Invoice Search 등을 넣을 수 있습니다.
3. 특정 버튼이 어떻게 작동하는지 분석하기
화면에 있는 버튼 하나가 실제로 어떤 코드와 연결되어 있는지 알고 싶을 때 사용할 수 있습니다.
Codex 프롬프트
[버튼 이름]버튼을 클릭했을 때 실행되는 코드를 찾아줘.버튼 클릭부터 최종 결과가 화면에 나타날 때까지 어떤 함수와 파일을 거치는지 순서대로 설명해줘.
각 단계에서 어떤 데이터가 전달되는지도 설명해줘.
코드는 수정하지 마.
이런 질문은 기존 시스템의 작동 방식을 이해하는 데 도움이 됩니다.
4. 이해하기 어려운 코드를 쉽게 설명하기
Codex는 코드를 만드는 것뿐 아니라 기존 코드를 이해하는 데도 활용할 수 있습니다.
Codex 프롬프트
이 코드를 개발자가 아닌 사람도 이해할 수 있도록 설명해줘.
- 이 코드의 목적
- 입력되는 데이터
- 처리 과정
- 결과
- 다른 코드와 연결되는 부분
순서로 설명해줘.
전문 용어를 사용해야 한다면 용어의 의미도 함께 설명해줘.
코드를 공부하려는 목적이 아니더라도 현재 시스템이 어떻게 작동하는지 파악할 때 유용합니다.
5. 새로운 기능을 추가하기 전에 구현 방법 확인하기
새로운 기능이 필요하다고 바로 코드를 작성하게 하기보다 먼저 구현 방법을 확인할 수 있습니다.
Codex 프롬프트
현재 프로젝트에
[추가할 기능]기능을 추가하고 싶어.먼저 현재 프로젝트 구조를 분석해서 비슷한 기존 기능이 있는지 찾아줘.
기존 기능을 재사용할 수 있는지도 확인해줘.
그리고 어떤 파일을 수정해야 하는지와 구현 방법을 설명해줘.
아직 코드는 변경하지 마.
개인적으로 이런 **"먼저 분석하고 아직 수정하지 마"**라는 조건은 처음 Codex를 사용할 때 특히 유용하다고 생각합니다.
6. 기존 코드를 최대한 유지하면서 기능 추가하기
구현 방법을 확인했다면 실제 수정을 요청할 수 있습니다.
Codex 프롬프트
[추가할 기능]을 구현해줘.기존 프로젝트 구조와 코딩 방식을 최대한 유지해줘.
비슷한 기존 기능이 있다면 새로 만들지 말고 최대한 재사용해줘.
필요한 파일만 최소한으로 수정하고 관련 없는 코드는 변경하지 마.
작업이 끝나면 변경한 파일과 변경 이유를 정리해줘.
기존 업무 시스템을 수정할 때는 새로운 기능만큼 기존 기능을 건드리지 않는 것도 중요합니다.
7. 화면에 버튼 추가하기
실제 바이브코딩을 하면서 자주 사용할 수 있는 프롬프트입니다.
Codex 프롬프트
[화면 이름]화면에[버튼 이름]버튼을 추가해줘.현재 화면에서 사용하고 있는 버튼의 디자인과 동일한 스타일을 사용해줘.
버튼은
[원하는 위치]에 배치해줘.버튼을 클릭하면
[실행할 기능]이 실행되어야 해.기존 화면의 다른 기능은 변경하지 마.
화면을 수정할 때는 기존 디자인을 유지해달라는 조건도 함께 주는 것이 좋습니다.
8. 새로운 필드 추가하기
ERP나 사내 업무 시스템에서는 새로운 입력 필드를 추가해야 하는 경우가 많습니다.
Codex 프롬프트
[화면 이름]에 새로운[필드 이름]필드를 추가해줘.필드 타입은
[Text / Date / Number / Select]이고[필수 / 선택]항목이야.저장할 때 기존 데이터 저장 방식과 동일하게 처리해줘.
기존 화면 구조와 데이터에는 영향을 주지 않도록 구현해줘.
변경해야 하는 파일을 먼저 확인하고 작업해줘.
9. 검색 기능 추가하기
Codex 프롬프트
[화면 이름]List 화면에[검색할 항목]검색 기능을 추가해줘.현재 프로젝트에 기존 검색 또는 Filter 기능이 있다면 같은 방식을 사용해줘.
검색 결과가 없을 때도 오류가 발생하지 않도록 처리해줘.
기존 Filter 기능은 그대로 유지해줘.
이런 식으로 요청하면 단순히 "검색 기능 만들어줘"라고 하는 것보다 원하는 결과를 명확하게 전달할 수 있습니다.
10. Excel Download 기능 추가하기
업무 시스템에서 활용도가 높은 예입니다.
Codex 프롬프트
현재
[화면 이름]에 Excel Download 기능을 추가해줘.현재 화면에 표시되는 데이터를 Excel 파일로 다운로드할 수 있어야 해.
사용자가 Filter를 적용했다면 Filter가 적용된 데이터만 다운로드되어야 해.
기존 프로젝트에 Excel Export 기능이 있다면 같은 방식을 재사용해줘.
데이터가 없을 때도 오류가 발생하지 않도록 처리해줘.
11. 오류의 원인만 먼저 분석하기
오류가 발생했다고 바로 수정하게 할 필요는 없습니다.
Codex 프롬프트
현재 다음 오류가 발생하고 있어.
[오류 메시지]먼저 오류의 원인을 분석해줘.
어떤 파일과 코드에서 문제가 발생하는지 찾아주고 왜 이런 오류가 발생했는지 개발자가 아닌 사람도 이해할 수 있도록 설명해줘.
아직 코드는 수정하지 마.
저는 비개발자에게 특히 이런 접근 방법을 추천합니다.
12. 오류를 최소한의 변경으로 수정하기
원인을 확인했다면 수정을 요청합니다.
Codex 프롬프트
방금 분석한 오류를 수정해줘.
기존 기능에 영향을 주지 않는 범위에서 가장 작은 변경으로 해결해줘.
관련 없는 코드는 수정하거나 리팩터링하지 마.
수정 후 왜 문제가 해결되는지도 설명해줘.
**"가장 작은 변경"**이라는 조건을 넣는 것도 기존 시스템을 다룰 때 유용합니다.
13. 같은 오류가 다시 발생할 가능성 확인하기
오류를 고쳤다고 끝내지 않고 비슷한 문제가 다른 곳에 있는지도 확인할 수 있습니다.
Codex 프롬프트
방금 수정한 오류와 동일하거나 비슷한 문제가 프로젝트의 다른 부분에서도 발생할 가능성이 있는지 확인해줘.
비슷한 코드를 찾아서 문제가 발생할 수 있는 위치를 알려줘.
바로 수정하지 말고 확인 결과만 먼저 보여줘.
14. 내가 수정한 코드 검토하기
직접 수정한 코드가 있다면 Codex를 코드 리뷰 용도로 사용할 수도 있습니다.
Codex 프롬프트
내가 수정한 코드를 검토해줘.
다음 항목을 중심으로 확인해줘.
- 오류 가능성
- 기존 기능에 미치는 영향
- 중복 코드
- 성능 문제
- 보안상 문제가 될 수 있는 부분
문제가 있다면 바로 수정하지 말고 먼저 문제와 이유를 설명해줘.
15. 기존 기능이 영향을 받는지 확인하기
기능을 추가한 뒤에는 Regression 문제가 없는지 확인해야 합니다.
Codex 프롬프트
이번 변경으로 인해 기존 기능에 영향을 줄 가능성이 있는지 분석해줘.
변경된 코드와 연결된 기존 기능을 찾아서 어떤 기능을 다시 테스트해야 하는지 알려줘.
위험도가 높은 항목부터 정리해줘.
16. 테스트 항목 만들기
기능은 만들었는데 무엇을 테스트해야 할지 모를 때 유용합니다.
Codex 프롬프트
방금 구현한
[기능 이름]에 대한 테스트 항목을 만들어줘.정상적인 사용뿐 아니라 다음 상황도 포함해줘.
- 데이터가 없는 경우
- 잘못된 값이 입력된 경우
- 필수값이 없는 경우
- 권한이 없는 경우
- 중복 데이터가 있는 경우
- 예상하지 못한 입력값
테스트 항목과 예상 결과를 표로 정리해줘.
17. 자동 테스트 작성하고 실행하기
Codex는 테스트 코드 작성과 실행에도 활용할 수 있습니다.
Codex 프롬프트
[기능 이름]에 대한 테스트 코드를 작성해줘.현재 프로젝트에서 사용하고 있는 기존 테스트 방식과 Framework를 먼저 확인하고 같은 방식을 사용해줘.
정상 Case와 Edge Case를 모두 포함해줘.
테스트를 실행하고 실패하는 항목이 있다면 원인을 알려줘.
테스트를 통과시키기 위해 기존 기능의 동작을 임의로 변경하지 마.
18. 변경된 파일 전체 정리하기
여러 번 수정하다 보면 어떤 파일을 변경했는지 헷갈릴 수 있습니다.
Codex 프롬프트
이번 작업에서 변경된 내용을 전체적으로 정리해줘.
파일별로 다음 내용을 알려줘.
- 파일 이름
- 변경한 내용
- 변경한 이유
- 기존 기능에 미칠 수 있는 영향
- 테스트가 필요한 부분
개발자가 아닌 사람도 이해할 수 있도록 설명해줘.
19. 불필요한 변경이 있는지 확인하기
AI와 여러 번 코드를 수정하다 보면 처음에는 필요하지 않았던 변경이 생길 수도 있습니다.
Codex 프롬프트
현재 변경된 코드를 최초 요구사항과 비교해서 검토해줘.
요구사항을 구현하는 데 필요하지 않은 변경이나 과도한 리팩터링이 있는지 찾아줘.
삭제하거나 원래대로 돌려도 되는 변경이 있다면 이유와 함께 알려줘.
아직 코드는 수정하지 마.
20. 최종 배포 전 전체 검토하기
마지막으로 사용할 수 있는 프롬프트입니다.
Codex 프롬프트
현재 작업을 최종 배포 전 상태라고 생각하고 전체적으로 검토해줘.
다음 항목을 확인해줘.
- 최초 요구사항이 모두 구현되었는지
- 빠진 기능이 있는지
- 기존 기능에 영향을 줄 가능성이 있는지
- 오류가 발생할 가능성이 있는지
- 보안상 확인해야 할 부분이 있는지
- 테스트가 충분한지
- 배포 전에 사람이 직접 확인해야 할 부분
문제가 발견되면 바로 수정하지 말고 우선순위와 함께 알려줘.
기능 하나를 완성한 뒤 마지막 체크 용도로 저장해두기 좋은 프롬프트입니다.
Codex 프롬프트는 길다고 무조건 좋은 것이 아니다
20개의 예제를 보면 프롬프트가 상당히 구체적입니다.
그렇다고 해서 Codex 프롬프트는 무조건 길게 작성해야 한다는 의미는 아닙니다.
OpenAI의 최신 모델 가이드에서도 불필요하게 반복되는 지시를 제거하고, 필요한 지시를 명확하고 간결하게 전달하는 방식을 권장하고 있습니다.
제가 생각하는 핵심은 프롬프트의 길이보다 AI가 무엇을 해야 하는지 명확하게 전달하는 것입니다.
예를 들어,
"오류 고쳐줘."
보다,
"오류의 원인을 먼저 분석하고 관련 파일을 알려줘. 아직 수정하지 마."
가 조금 더 구체적입니다.
그리고,
"이 시스템 개선해줘."
보다,
"현재 List 화면에 Vendor Name 검색 기능을 추가하고 싶어. 기존 Filter 방식을 먼저 찾아서 같은 구조로 구현할 수 있는지 확인해줘."
라고 요청하면 작업 범위가 훨씬 명확해집니다.
비개발자가 기억하면 좋은 Codex 프롬프트 공식
20개를 모두 외울 필요는 없습니다.
저는 Codex에 작업을 요청할 때 아래 다섯 가지를 생각하면 프롬프트를 만들기 쉽다고 봅니다.
Context → Goal → Constraints → Process → Verification
Context
현재 어떤 프로젝트와 기능을 다루고 있는가?
Goal
무엇을 만들거나 수정하고 싶은가?
Constraints
무엇을 변경하면 안 되는가?
Process
어떤 순서로 작업해야 하는가?
Verification
작업이 제대로 되었는지 어떻게 확인할 것인가?
예를 들어 이 공식을 이용하면 다음과 같은 프롬프트를 만들 수 있습니다.
현재 Invoice Management 프로젝트에서 작업하고 있어.
Invoice List 화면에 Excel Download 기능을 추가하고 싶어.
기존 Filter와 UI 구조는 변경하지 말고 기존에 Excel Export 기능이 있다면 재사용해줘.
먼저 관련 코드를 찾아서 수정해야 할 파일과 구현 방법을 설명해줘.
내가 확인한 뒤 기능을 구현하고 테스트 항목도 만들어줘.
개발 전문 용어를 많이 사용하지 않아도 원하는 작업을 꽤 명확하게 전달할 수 있습니다.
처음 Codex를 사용한다면 이 5개부터 저장해두자
20개를 한꺼번에 사용하기 어렵다면 저는 먼저 다음 프롬프트부터 익히는 것을 추천합니다.
① 프로젝트 분석
"이 프로젝트 구조를 개발자가 아닌 사람도 이해할 수 있게 설명해줘."
② 기능 찾기
"이 프로젝트에서 ○○ 기능을 담당하는 코드를 찾아줘."
③ 수정 전 확인
"○○ 기능을 추가하려면 어떤 파일을 수정해야 하는지 알려줘. 아직 수정하지 마."
④ 오류 분석
"이 오류의 원인을 찾아서 쉽게 설명해줘. 아직 수정하지 마."
⑤ 최종 검토
"이번에 변경한 내용을 검토하고 기존 기능에 영향을 줄 가능성과 테스트해야 할 항목을 알려줘."
이 다섯 개만 익숙해져도 Codex를 단순히 코드를 만들어주는 AI가 아니라 프로젝트를 이해하고 개발 작업을 도와주는 AI로 활용하기 쉬워집니다.
마무리｜좋은 Codex 프롬프트는 개발 용어가 어려운 프롬프트가 아니다
비개발자가 AI 코딩을 시작하면 프롬프트부터 전문적으로 작성해야 할 것 같은 부담이 생길 수 있습니다.
하지만 꼭 어려운 개발 용어를 사용해야 하는 것은 아닙니다.
오히려 중요한 것은 내가 원하는 것을 정확하게 설명하는 것입니다.
무엇을 만들고 싶은지
어떤 부분은 변경하면 안 되는지
바로 수정할지 먼저 분석할지
완성 후 무엇을 확인해야 하는지
이 네 가지만 명확하게 이야기해도 Codex가 작업을 이해하는 데 도움이 됩니다.
Codex는 현재 코드베이스 이해, 기능 개발, 버그 수정, 코드 리뷰, 테스트 같은 다양한 개발 작업에 활용할 수 있습니다.
하지만 AI가 코드를 수정할 수 있다는 것과 그 결과가 항상 정확하다는 것은 다른 문제입니다.
특히 실제 회사 시스템에서는 AI가 만든 코드를 사람이 검토하고 테스트한 뒤 적용하는 과정이 필요합니다.
처음부터 큰 프로그램을 만들어달라고 하기보다,
프로젝트 분석 → 작은 기능 하나 수정 → 결과 확인 → 테스트
순서로 시작해보는 것을 추천합니다.
이 글에 있는 20개의 프롬프트 중 자신의 상황에 맞는 것을 하나 복사해서 [ ] 부분만 바꿔보면 Codex를 처음 사용하는 사람도 훨씬 쉽게 시작할 수 있습니다.
0 Comments