ChatGPT에게 '고쳐줘'라고 말하는 것을 멈췄습니다. 대신 사용하는 4가지 구성 요소의 프롬프트입니다.

약 1년 동안 저는 AI를 슬롯머신처럼 코딩하는 데 사용했습니다.

코드 벽을 붙여넣고, "fix it" 또는 "make this better."라고 입력합니다. 레버를 당깁니다. 가끔은 제가 이겼습니다. 보통은 질문했던 것을 해결한 듯 자신감 있는 답변을 받았지만, 동시에 제가 의도하지 않은 두 가지를 조용히 망가뜨리기도 했습니다.

저는 문제가 모델에 있다고 가정했습니다. 그래서 모델을 바꿨습니다. 슬롯머신 자체는 같았지만, 그래픽만 더 나은 것이었죠.

문제는 모델이 아니었습니다. 제가 작업할 재료를 거의 주지 않고 마음을 읽기를 기대했다는 것입니다. 구조화된 프롬프팅을 시작하자마자, 그 차이는 제가 본 어떤 모델 업그레이드보다도 컸습니다.

여기에 그 구조가 있습니다. 저는 이것을 **C.O.R.E.**라고 부릅니다. 왜냐하면 밤 11시에 실제로 기억할 수 있는 것이 필요했기 때문입니다.

C — Context (상황)

AI는 당신이 아는 것을 모릅니다. 당신의 언어 버전, 프레임워크, 또는 코드가 무엇을 해야 하는지조차 모릅니다. 알려주지 않으면 추측하게 되고—자신감 있는 추측은 겉보기에는 그럴듯하지만 실제로는 그렇지 않은 코드를 만들어냅니다.

그러므로 다른 어떤 것보다 먼저: 언어와 프레임워크를 버전과 함께 언급하고, 이 코드가 무엇을 하는지 한 문장으로 설명해야 합니다.

"저는 Python 3.11과 FastAPI로 작업하고 있습니다. 이 엔드포인트는 사용자의 최근 주문 내역을 반환합니다."

이 한 줄만으로도 잘못된 답변의 절반가량을 사전에 제거할 수 있습니다.

O — Objective (목표)

"개선해 줘(Improve this)"는 목표가 아닙니다. AI는 당신에게 "더 좋다(better)"가 무엇을 의미하는지—더 빠를까요? 더 짧을까요? 더 안전할까요?—전혀 알지 못하기 때문에, 무작위로 하나를 선택합니다.

하나의 구체적인 목표를 제시하세요:

"이 함수는 시그니처(signature)를 변경하지 않고, 날짜순으로 최신 순서대로 주문 내역을 반환하도록 만드세요."

마치 주니어 개발자에게 코드를 건네주기 전에 지시하듯이 한 가지 작업을 명확히 진술하세요.

R — Rules (규칙)

이것은 거의 모든 사람이 건너뛰는 부분이며, 바로 이것이 당신을 구원합니다. 규칙은 일종의 가드레일입니다:

• "관련 없는 것은 리팩토링하지 마세요."
• "새로운 의존성(dependencies)을 추가하지 마세요."
• "읽기 쉽게 유지해 주세요. 제가 아직 배우는 중이거든요."
• 그리고 마법 같은 규칙: "불분명한 점이 있다면 추측하는 대신 저에게 물어보세요."

그 마지막 규칙 하나만으로도 저의 환각 (hallucination) 문제 대부분이 해결되었습니다. 공백을 채우도록 내버려 두면 모델은 지어냅니다. 질문하라고 명령하면, 질문합니다.

E — 기대 출력 (Expected output)

결과물이 어떤 모습이어야 하는지 알려주지 않으면, 모델은 자신이 원하는 대로 내놓을 것입니다. 보통 세 줄을 원할 때 600단어짜리 에세이를 내놓곤 하죠.

"변경된 줄만 보여주고, 그 다음 두 문장으로 설명해 주세요."

차이점(Diff)만 보여줄지 전체 파일(full file)을 보여줄지, 설명을 먼저 할지 코드를 먼저 할지, 특정 형식을 지정하세요. 그냥 말하면 됩니다.

완성된 모습

제가 이 방식의 신봉자가 되게 만든 전후 비교 사례입니다.

이전 (Before):

여기 내 함수인데 느려. 고쳐줘.

[200 lines pasted]

이후 (After):

저는 Python 3.11 환경에서 작업하고 있습니다. 이 함수는 사용자 기록 리스트를 저장하기 전에 중복을 제거합니다.

목적: 대규모 입력값에서 속도가 느립니다. 반환값(return value)을 변경하지 않으면서 더 빠르게 만들어 주세요.

규칙: 외부 라이브러리를 사용하지 말고, 가독성을 유지하며, 코드를 수정하기 전에 현재 버전이 왜 느린지 저에게 알려주세요.

출력: 설명을 먼저 하고, 그 다음에 다시 작성된 함수를 보여주세요.

"이전" 방식은 무작위로 다시 작성된 코드를 얻게 됩니다. 반면 "이후" 방식은 왜 이것이 O(n²)이었는지에 대한 설명과 해결책, 그리고 코드 리뷰에서 충분히 방어할 수 있을 정도로 잘 이해되는 코드를 얻게 됩니다. 같은 모델이지만, 결과는 완전히 다릅니다.

몇 가지 빠른 활용법

C.O.R.E.가 체득되면, 모든 것에 이를 적용하기 시작하게 됩니다.

디버깅 (Debugging): "무엇을 변경하기 전에, 무엇이 이 에러를 일으키고 어디에서 발생하는지 쉬운 언어로 설명해 주세요. 그다음 증상이 아닌 근본 원인에 대한 가장 작은 수정 사항을 알려주세요."

학습 (Learning): "실제 변수명을 사용하여, 마치 제가 1학년 학생인 것처럼 이 코드를 설명해 주세요. 그다음 제가 직접 이 코드를 작성하기 위해 필요한 개념 3가지를 나열해 주세요." — 이는 AI를 단순한 정답 기계에서 튜터(tutor)로 바꿔 놓습니다.

리팩터링 (Refactoring): "가독성을 위해 리팩터링해 주세요. 동작과 시그니처(signatures)는 정확히 동일하게 유지하세요. 각 변경 사항을 한 줄로 설명해 주세요." "동일한 동작 + 시그니처" 조항은 결과물을 신뢰할 수 있게 만드는 핵심입니다.

안티 패턴 (Anti-patterns) (이것들은 단지 글자가 빠진 것뿐입니다)

이제 답변이 실망스러울 때, 저는 다시 생성(re-roll)하며 기도하지 않습니다. 대신 제가 어떤 글자를 빠뜨렸는지 질문합니다:

• 결과가 나쁘고 요청이 모호함 → O를 빠뜨렸습니다.
• 잘못된 프레임워크 버전에 대한 답변 → C를 빠뜨렸습니다.
• 파일의 절반을 다시 작성함 → R을 빠뜨렸습니다.
• 자신 있게 거짓말을 함(환각) → "나에게 물어보라"는 R을 빠뜨렸습니다.
• 차이점(diff)을 원했는데 에세이를 작성함 → E를 빠뜨렸습니다.

빠진 조각을 추가하여 다시 보냅니다. 문제는 거의 언제나 모델의 탓이 아닙니다.

이것이 전부입니다

500개의 항목이 담긴 프롬프트 라이브러리는 필요 없습니다. 기억 속에서 불러와 즉석에서 적용할 수 있는 하나의 구조만 있으면 됩니다. Context (맥락), Objective (목표), Rules (규칙), Expected output (기대 출력). 그게 전부입니다.

저는 구루(guru)가 아니라 학생일 뿐입니다. 그저 슬롯머신과 싸우는 것에 지쳤을 뿐이죠. 만약 이 글이 제가 깨닫기까지 들였던 시간 중 일부라도 여러분의 시간을 아껴준다면, 제 역할은 다한 것입니다.

저는 C.O.R.E.와 복사-붙여넣기용 마스터 템플릿을 하나의 무료 치트 시트(cheatsheet)로 만들었습니다. 작업 중에 바로 옆에 두고 싶다면 여기에서 가져가세요. (물론, 필요한 모든 내용은 이미 이 포스트에 들어 있습니다. 함정은 없습니다.)