AI 프롬프트, 문법보다 ‘결과’로 소통하는 법
많은 사람이 AI에게 일을 시킬 때 ‘마법의 프롬프트 공식’을 찾는다. 특정 역할이나 제약, 출력 형식을 강박적으로 적용해야 좋은 결과가 나온다고 믿는다. 그러나 실제로는 특별한 문법보다 원하는 결과를 명료하게 설명하는 능력이 더욱 중요하다. 이 글은 복잡한 AI 작업을 효과적으로 지시하는 원칙과 실전 활용법을 설명한다.
프롬프트는 ‘결과’를 설명하는 말이다
AI와 대화할 때 프롬프트는 질문, 지시, 또는 목표가 될 수 있다. 기술적인 문법이나 엄격한 공식에 얽매일 필요는 없다. 그저 원하는 내용을 말하고, AI의 답을 확인한 뒤 후속 메시지로 다듬는 방식이 효과적이다. 대부분의 경우 짧은 프롬프트만으로도 충분하다.
하지만 “이번 캠페인 회고를 임원 보고용으로 작성해줘”와 같은 크고 중요한 작업은 한 줄 지시로 원하는 결과가 나오기 어렵다. 이럴 때만 필요한 핵심 요소를 포함하면 된다.
복잡한 작업을 지시하는 GOCB 프레임워크
복잡한 AI 작업을 위한 프롬프트는 네 가지 뼈대로 구성할 수 있다. 이를 GOCB라고 부른다.
이 프레임워크는 AI에게 무엇을 시키고 어떤 정보를 제공하며 어떤 결과물을 원하는지, 그리고 무엇을 건드려서는 안 되는지를 명확히 한다.
| 요소 | 역할 | 실무 예시 |
|---|---|---|
| Goal(목표) | AI가 무엇을 해야 하는지? | “이 회의록을 팀용 짧은 업데이트로 만들어줘.” |
| Context(맥락) | 어떤 정보나 출처가 도움 되는지? | “첨부한 3분기 리포트를 근거로 작성해줘.” |
| Output(산출) | 결과물의 형식, 길이, 상세도는? | “결정사항과 다음 단계를 맨 앞에, 한 페이지로.” |
| Boundaries(경계) | 바뀌면 안 되는 것, 먼저 확인할 것? | “승인된 날짜나 예산 숫자는 건드리지 마.” |
GOCB 프레임워크의 핵심은 “도움이 되는 정보만 넣는다”는 태도이다. 모든 칸을 억지로 채울 필요는 없으며, 정해진 순서를 지킬 필요도 없다. 간단한 질문은 Goal 하나로 충분하며, 산출물이 복잡할수록 나머지 요소를 추가한다.
‘절차’보다 ‘결과’를 명시하는 이유
많은 사람이 AI에게 “이렇게 하고, 저렇게 해달라”는 절차를 나열하려 한다. 그러나 AI에게는 결과부터 말하는 편이 대개 더 나은 결과로 이어진다.
| 지시 방식 | 예시 | 설명 |
|---|---|---|
| 절차 중심 (지양) | “먼저 데이터를 정렬하고, 그다음 필터를 걸고, 그다음 평균을 내고, 표로 만들어줘.” | AI의 자율적인 최적화 경로를 제한한다. |
| 결과 중심 (권장) | “이 지출 내역을 계획 대비 실제와 비교한 표로 만들고, 차이가 10% 넘는 항목을 강조해줘.” | AI가 스스로 데이터를 검색하고 비교하며, 접근법을 조정할 여지를 남겨둔다. 이는 더 유연하고 효율적인 결과로 이어진다. 절차 자체가 중요한 경우(예: 규정된 워크플로)에만 과정을 설명한다. |
청중이나 형식이 결과물을 바꾼다면, 그 정보도 함께 알려준다. 누가 읽는지가 무엇을 만들지를 좌우하기 때문이다.
맥락 정보는 ‘선택적 지시’로 첨부한다
맥락 정보를 제공할 때는 결과에 영향을 미칠 수 있는 정보만 선택하여 “이 자료에서 뭘 가져가라”고 구체적으로 짚어준다. 단순히 파일을 첨부하는 것과 “이 스프레드시트에서 3분기 전환율만 봐”라고 지시하는 것은 결과가 다르다.
AI에게 맥락을 제공하는 주요 방법은 다음과 같다.
| 맥락 제공 방법 | 설명 | 구체적 지시 |
|---|---|---|
| 파일 첨부 | 요약, 비교, 변환, 파일 생성이 필요할 때 문서, 시트, 발표자료, PDF 등을 첨부한다. | 특정 파일에서 특정 정보만 참조하도록 지시한다. |
| 이미지 | 시각적 맥락이 중요할 때 스크린샷, 도표 등을 넣되, 핵심 부분을 짚어준다. 이미지 하나에 의존하지 않는다. | 이미지 내 특정 영역이나 데이터 포인트에 집중하도록 지시한다. |
| 웹 검색 | 최신 정보가 필요한 경우 웹 검색을 요청하고, 정보 확인을 위해 출처를 요구한다. | “최신 데이터를 검색하여 ~에 대한 정보를 찾아줘. 출처도 함께 알려줘.” |
| 연결된 소스 | Drive, Slack, Gmail, GitHub 등에 접근 권한이 있을 때, 특정 위치에서 무엇을 찾을지 지정한다(@ 명령어 사용). | “Drive에서 3분기 프로젝트 보고서를 찾아 ‘A’ 섹션 내용을 참조해줘.” 모든 검색을 일일이 지시할 필요는 없다. |
개인의 말투나 기본 형식 등 여러 대화에 두루 적용될 취향은 AI의 ‘개인화 설정(custom instructions)’에 입력한다. 반면, 현재 작업에만 필요한 세부 지시는 프롬프트에 직접 넣는다. 매번 반복 설명을 피하기 위함이다.
‘경계’ 설정으로 AI의 오류를 막는다
AI가 엉뚱한 부분을 변경하여 결과물이 쓸모없어지는 경우가 종종 발생한다. 승인된 예산 숫자를 반올림하거나, 초안만 원했는데 메일을 보낼 것처럼 작성하는 식이다. Boundaries(경계)는 이러한 사고를 막는 몇 안 되는 필수 지시이다.
경계 설정의 실전 예시는 다음과 같다.
- “승인된 날짜와 예산 수치는 그대로 둘 것.”
- “제공한 자료만 사용하고, 빠진 정보는 지어내지 말고 표시할 것.”
- “추천은 명시된 예산 안에서만.”
- “메시지는 초안으로만 준비하고, 보내지 말 것.”
핵심은 한두 개의 가장 중요한 경계에 집중하는 것이다. AI의 모든 단계를 통제하려 들면 프롬프트가 복잡해진다. “잘못되면 결과물 전체를 버려야 하는 지점”과 “사람에게 영향이 가기 전에 내가 검토하고 싶은 지점”만 경계로 명시하면 된다.
원하는 결과물을 바로 얻는 방법
AI에게 결과물을 어떻게 사용할지 알려주면, AI가 길이, 상세도, 구성을 스스로 맞춘다.
- “임원이 회의 전에 훑어볼 수 있는 한 페이지 요약으로 만들어줘. 결정과 다음 단계를 맨 앞에.”
- “이 메모를 결정사항, 담당자, 기한이 담긴 후속 메일로.”
- “계획 대비 실제 지출 표로, 10% 넘는 차이는 강조.”
중요한 작업일수록 마지막 점검을 시킨다. “모든 액션 아이템에 담당자와 기한이 있는지 확인해줘”, “검증 못한 정보는 표시해줘”와 같이 지시한다. 물론 그 뒤에는 사용자의 최종 검토가 필요하다. AI의 자가 점검은 사람의 검토를 대체하는 것이 아니라, 검토 부담을 줄여주는 역할이다.
첫 프롬프트는 완벽할 필요가 없다
첫 프롬프트를 완벽하게 작성하려 애쓰지 않는다. 결과를 보고 원하는 변경 사항만 콕 집어 후속 메시지로 전달한다.
“도입부를 더 직설적으로, 근거는 그대로 두고, 추천을 배경 설명 위로 올려줘.”
이처럼 빠진 출처를 추가하거나, 방향을 변경하거나, 다른 대안을 요청하거나, 상세도를 바꾸는 작업을 처음부터 다시 시작하지 않고 할 수 있다.
작업 중 개입하는 두 가지 방식, 스티어링과 큐잉
Codex처럼 이미 작업 중인 AI 에이전트에게는 작업이 끝나기를 기다리지 않고 메시지를 추가로 보낼 수 있다. 여기에는 두 가지 방식이 있다.
| 방식 | 설명 | 사용 시점 |
|---|---|---|
| Steer(스티어) | 현재 실행 중인 작업에 메시지를 즉시 반영한다. | 작업의 방향을 바꾸거나, 빠뜨린 세부 정보를 추가하거나, 새로운 정보를 줄 때. |
| Queue(큐) | 다음 실행을 위해 메시지를 저장해둔다. 현재 작업이 끝난 뒤에 처리된다. | 현재 작업이 완료된 후 처리되어야 할 후속 지시일 때. |
데스크톱 앱에서는 이 기본 동작을 설정에서 선택할 수 있으며, 큐에 쌓인 메시지는 보내기 전에 편집, 재정렬, 삭제가 가능하다.
작업 유형별 AI 도구 활용
프롬프팅 원리는 같지만, 작업의 성격과 무게에 따라 사용하는 AI 도구의 인터페이스가 달라진다.
| 도구 | 작업 유형 | 예시 프롬프트 |
|---|---|---|
| Chat | 즉답, 가벼운 글, 아이디어, 비교 | “투자 경험 없는 사람에게 복리를 설명해줘. 구체적 예시 하나로, 금융 용어는 정의해가며.” “두 요금제를 국제출장이 잦은 1인 기준으로 표로 비교하고, 하나 추천 + 트레이드오프 설명.” |
| Work | 여러 소스 결합, 큰 산출물 제작 | “첨부한 분기 리포트로 임원용 브리프와 6장 슬라이드를 만들어줘. 결정 세 가지를 앞에, 사실과 내 분석을 구분하고, 각 숫자를 출처 파일에 매어줘. 브리프와 슬라이드가 서로 어긋나지 않는지 확인해줘.” |
| Codex | 코드, 코드베이스, 개발 도구 | “선택한 코드로 요청이 어떻게 흐르는지 설명해줘. 각 모듈 책임 요약 + 어디서 뭘 검증하는지 + 바꿀 때 주의할 함정 한두 개. 그다음 흐름을 번호 매긴 단계로, 관련 파일 목록도.” (코드베이스 이해 프롬프트) |
Work는 여러 소스를 엮고, 여러 단계를 거치며, 정보를 변환하거나 큰 산출물을 만들 때 특히 유용하다. 시간 소모적인 반복 작업이나 재사용할 완성 파일을 만들 때 가치가 크다. Codex는 코드 동작을 이름 붙여 설명하고, 관련 코드나 재현 절차를 짚으며, 지켜야 할 제약을 남기고, 검증 방법을 명시한다. Codex는 /plan 명령어를 활용해 편집 전에 접근법을 제안받고 검토하는 것이 안전하다.
종합 예시로 보는 GOCB 템플릿
다음은 GOCB를 자연스럽게 결합한 ‘완성형 프롬프트’ 예시이다.
- [Goal]: 월요일 리더십 회의용 한 페이지 프로젝트 현황 업데이트를 만들어줘.
- [Context]: Drive의 최신 프로젝트 계획과 Slack 채널의 결정, 업데이트를 참고해서.
- [Output]: 리더십이 내려야 할 결정과 다음 단계를 맨 앞에, 진행상황, 리스크, 담당자, 기한을 요약해서.
- [Boundaries]: 승인된 날짜, 예산 수치는 그대로 두고, 상충하거나 빠진 정보는 표시하고, 아무것도 발행하거나 전송하지 말 것.
- [Check]: 끝내기 전에 모든 다음 단계에 담당자와 기한이 있는지 확인해줘.
이 템플릿은 GOCB를 활용하고 모든 단계를 시시콜콜 지시하지 않으며 마지막 점검까지 요청한다. 결국 프롬프팅 실력은 문법을 외우는 것이 아니라, 원하는 결과를 정확하고 솔직하게 그리는 능력에서 나온다. AI에게 잘 설명하는 연습은 자신의 머릿속 결과물을 명확하게 만드는 연습과 같다.
생태학·먹이그물 이론의 시선으로 보면
AI 프롬프트의 GOCB 프레임워크는 생태계의 작동 원리와 유사하다. 생태계 내 특정 개체군(AI)이 목표(Goal)를 수행하기 위해 주변 환경(Context)에서 자원을 얻고, 일정한 형태(Output)로 결과를 내놓는다. 이때 생태학적 한계(Boundaries)는 개체군 활동이 시스템 전체를 교란하지 않도록 제한한다. 즉, 프롬프트가 AI의 생태적 지위와 역할을 규정하여 균형 잡힌 결과물을 유도하는 과정과 닮아 있다.