사람들이 저에게 자주 다가와서 묻습니다. "Codex가 이런 것도 할 수 있나요?"
그러고는 2~3분 동안 그 "이런 것"이 정확히 무엇인지 설명합니다. 해결하고 싶은 문제, 애플리케이션이 해야 할 일, 좋은 결과가 무엇인지 말이죠. 때로는 이미 시도해 본 것, 잘 통했던 것, 통하지 않았던 것까지 공유하기도 합니다.
그러면 저는 이런 생각이 듭니다. 그 설명을 그냥 Codex에게 하면 되는 거잖아.
그 전체 설명이 이미 프롬프트였던 겁니다.
프롬프트 엔지니어링은 죽었습니다. 그리고 죽지 않았습니다.
프롬프트 엔지니어링이 도움을 요청하기 전에 비밀 언어를 배워야 하는 것이라면, 저는 그것이 대부분 죽었다고 생각합니다. 특히 추론 모델의 경우, 정답을 찾는 마법의 키워드는 대개 존재하지 않습니다. 완벽한 프롬프트를 만들기 위해 빈 화면 앞에 한 시간 동안 앉아 있어야 한다고 생각하지 않습니다.
하지만 완전히 죽은 것도 아닙니다. 명확성은 여전히 중요하기 때문입니다. 모호함은 다른 사람에게 그렇듯 Codex의 작업도 더 어렵게 만듭니다. 만약 제가 이 글의 단락들을 뒤섞거나 여러분이 이해하지 못하는 언어로 바꾼다면, 따라가기가 더 어려울 것입니다. 심지어 시제도 중요합니다. "내가 이걸 해봤어"와 "네가 이걸 해봐줬으면 좋겠어"는 다릅니다.
당신이 실제로 원하는 것은 무엇인가요? 어떤 맥락이 중요할까요? Codex가 알아야 할 제약 조건은 무엇인가요? 좋은 결과는 어떤 모습일까요?
함께 일하는 사람에게 말하듯이 Codex에게 말하세요.
저는 결과부터 시작하는 것을 좋아합니다. 내 목표가 무엇인가? 이것이 에이전트와 함께하는 더 큰 변화이기도 합니다. 모든 단계를 스크립트로 작성하고 중간 결과물을 하나하나 요청하는 대신, 내가 달성하고자 하는 바를 설명하고, 경계를 설정하고, Codex가 경로를 찾도록 도울 수 있습니다.
지저분한 버전을 말하세요
대부분의 아이디어는 깔끔한 명세서 형태로 도착하지 않습니다. 대개는 이렇게 들리죠.
"자, 파일들이 좀 있어요. 형식이 조금씩 다릅니다. 금요일까지 보고서가 필요해요. 데이터는 대부분 있는 것 같은데, 이번 export 파일 하나가 좀 이상하네요..."
괜찮습니다. 그냥 말하세요.
횡설수설할 때, 종종 Codex에 더 많은 신호를 제공하게 됩니다. 다듬은 프롬프트에서는 제거했을 세부 사항을 언급하게 됩니다. 중간에 마음이 바뀝니다. "아니야, 그건 원하지 않아"라고 말하게 됩니다.
마음이 바뀌면 무엇을 원하지 않는지 드러납니다. 우회로는 숨겨진 제약 조건을 드러낼 수도 있습니다. 소리 내어 생각하는 것은 여러분과 Codex 모두가 작업을 이해하는 데 도움이 됩니다.
음성 받아쓰기를 사용하면 마이크 버튼을 누르고, 브리핑을 말하고, 대본을 확인한 후 전송하면 됩니다.
사용 환경에서 가능하다면, Voice 모드는 더 나아갑니다. 후속 질문을 하거나, 중단하거나, 방향을 바꾸거나, 새로운 생각을 시작할 수 있습니다. 또한 작업을 조정하는 데 사용할 수 있습니다. 다른 작업을 시작하거나, 기존 작업을 확인하거나, 막힌 부분이 무엇인지 묻거나, 이미 실행 중인 작업을 조정할 수 있습니다.
솔직히 말하면, 컴퓨터와 대화하는 것은 여전히 조금 이상하게 느껴집니다. 사무실에서는 DJI 마이크를 손에 쥐고 있습니다. 헤드폰에 달린 마이크도 괜찮습니다.
하지만 완벽하게 적어낼 방법을 찾지 못해 좋은 아이디어가 머릿속에 갇혀 있는 것보다는 낫습니다.
터무니없는 질문을 하세요
익숙한 밈 버전이 있습니다.
"Codex, 나한테 10억 달러짜리 B2B SaaS를 만들어 줘. 실수하지 말고. 한 번에 끝내."
한 번에 10억 달러짜리 회사를 만들 수는 없습니다. 하지만 그 대화는 실제로 의미 있는 무언가를 발견하게 해줄 수 있습니다. 당신이 이해하는 문제, 그 문제를 가진 사람, 그리고 취할 가치가 있는 첫 번째 단계 같은 것들 말이죠. 이는 고전적이고 건전한 문제 해결 방식입니다. 복잡한 문제를 더 작고 달성 가능한 단계로 나누는 것입니다.
가치는 대화 자체에 있습니다. 터무니없는 질문에서 오늘 실제로 출시할 수 있는 무언가로 이끌어 줄 수 있습니다.
시작하는 몇 가지 실용적인 방법
아이디어가 아직 불명확하다면, Codex에게 당신을 인터뷰해 달라고 요청하세요.
"아직 정리가 안 됐어요. 한 번에 하나씩 질문해 주세요. 모호한 부분은 짚어주고, 구체적인 것으로 바꾸는 걸 도와주세요."
또는 아주 직접적으로 물어보세요.
- 내가 놓치고 있는 점은 무엇일까?
- 무엇이 이것을 실패하게 만들까?
- 내가 너무 복잡하게 생각하는 것은 무엇일까?
- 가장 작은 유용한 버전은 무엇일까?
- 당신이 시작하기 전에 알아야 할 것은 무엇일까?
더 많은 구조가 필요할 때는 Codex의 Plan 모드가 유용합니다. 명확한 질문을 하고, 옵션을 제시하며, 구현 전에 접근 방식을 검토할 수 있습니다.
하지만 모든 아이디어가 거기서 시작되어야 한다고 생각하지는 않습니다. 때로는 개방형 대화가 더 잘 흘러갑니다. 우리는 동료와의 모든 대화를 계획과 실행으로 나누지 않습니다. 먼저 이야기하세요. 문제의 형태가 드러나도록 두세요. 작업에 계획이 필요할 때 계획으로 넘어가세요.
Codex에게 Codex에 대해 물어보세요
"Codex와 대화하기"에는 또 다른 의미가 있습니다. Codex 자신에 대한 질문을 하는 것입니다.
무엇을 볼 수 있는지 물어보세요. 어떤 모드가 적합한지 물어보세요. 어떤 도구를 사용할 수 있는지 물어보세요. 작업을 어떻게 검증할 계획인지 물어보세요.
OpenAI Docs 스킬을 사용할 수 있다면, Codex에게 문서를 확인해 달라고 요청하세요. 공개된 Codex 저장소를 살펴보거나, 클론한 후 Codex에게 어떻게 작동하는지 설명해 달라고 요청할 수도 있습니다.
Codex가 목표를 빗나갔다면, 이유를 물어보세요
"당신은 이렇게 했는데, 나는 사실 저걸 원했어요. 어디서 잘못된 걸까요?"
아마도 당신의 요청이 모호했을 수 있습니다. AGENTS.md 파일이나 스킬이 작업을 다른 방향으로 이끌었을 수도 있습니다. 플러그인, 권한 또는 도구를 사용할 수 없었을 수도 있습니다. Codex가 잘못된 가정을 했을 수도 있습니다.
Codex가 무엇을 이해했는지, 어떤 지침을 따랐는지, 무엇이 실패했는지, 그리고 당신이 무엇을 더 명확히 할 수 있었는지 물어보세요. Codex는 종종 여전히 사용 가능한 컨텍스트를 활용하여 협업 자체를 감사하는 데 도움을 줄 수 있습니다.
가능한 경우, Codex가 실행되는 동안 메인 채팅을 방해하지 않고 /side로 사이드 채팅을 열 수 있습니다. 무엇이 완료되었는지, 무엇이 남았는지, 무엇이 막혔는지, 그리고 당신이 어떻게 도울 수 있는지 물어보세요. 당신은 기본적으로 데일리 스탠드업 미팅에서 Codex의 매니저인 셈입니다.
무언가를 평범한 영어로 설명해주길 원한다면, 대화록에서 텍스트를 선택하고 "사이드 채팅으로 질문"을 선택하세요.
아이디어를 머릿속에서 꺼내세요
로드트립 중에 저는 Codex에게 프레젠테이션에 대해 이야기하기 시작했습니다. 그 이야기가 이 강연과 이 글의 구조가 되었습니다. 대략적인 아이디어를 말로 풀어내고, 몇 번 마음을 바꾸고, 계속 진행했습니다.
종종 가장 큰 장애물은 모델이 아닙니다. 바로 우리 자신입니다. 아이디어가 준비되지 않았다고 생각합니다. 올바른 프롬프트를 모릅니다. 제대로 설명하지 못할까 봐 걱정합니다.
인터페이스는 더 나아질 것입니다. 그리고 Codex와의 대화가 어떻게 느껴져야 하는지에 대한 아이디어가 있다면, 진심으로 듣고 싶습니다.
그냥 Codex에게 물어보세요.
