5장. 프롬프트 엔지니어링 기초

1. 프롬프트는 AI에게 일을 시키는 요청문이다

AI를 사용할 때 가장 먼저 익숙해져야 하는 개념이 프롬프트다.

프롬프트는 쉽게 말해 AI에게 입력하는 요청문이다.

우리가 ChatGPT 같은 AI에게 질문을 입력하면 그 문장이 프롬프트가 된다.

React에서 useEffect가 계속 실행되는 이유를 알려줘.

이것도 프롬프트다.

아래 코드를 보고 보안상 문제가 있는지 검토해줘.

[코드 붙여넣기]

이것도 프롬프트다.

프롬프트는 단순한 질문일 수도 있고, 역할, 목적, 조건, 예시, 출력 형식까지 포함한 작업 지시문일 수도 있다.

AI는 사용자가 입력한 내용을 바탕으로 답변을 만든다.
그래서 프롬프트가 모호하면 결과도 모호해지고, 프롬프트가 구체적이면 결과도 구체적일 가능성이 높아진다.

예를 들어 다음 두 요청을 비교해보자.

보고서 써줘.

이 요청은 너무 넓다.

무슨 보고서인지,
누구에게 보여줄 보고서인지,
어떤 내용을 포함해야 하는지,
어떤 문체로 써야 하는지 알 수 없다.

반면 다음 요청은 훨씬 명확하다.

개발팀 주간 보고서 초안을 작성해줘.

대상은 CTO이고,
이번 주 주요 작업은 로그인 API 개선, 장애 대응, 배포 자동화 정리야.

형식은 다음 순서로 작성해줘.

1. 이번 주 진행 사항
2. 주요 이슈
3. 다음 주 계획
4. 지원이 필요한 사항

문체는 간결하고 보고용으로 작성해줘.

두 번째 요청이 더 좋은 결과를 얻을 가능성이 높다.

AI가 해야 할 일, 보고 대상, 포함할 내용, 출력 형식, 문체가 구체적으로 들어 있기 때문이다.

프롬프트는 단순히 “질문을 잘 쓰는 기술”이 아니다.
AI에게 업무를 맡기기 위한 작업 지시서에 가깝다.

프롬프트는 AI에게 입력하는 요청문이다.
질문뿐 아니라 역할, 목적, 배경, 조건, 출력 형식까지 포함할 수 있다.

2. 프롬프트가 중요한 이유

AI는 사용자의 의도를 완벽히 읽을 수 없다.

사람끼리는 대충 말해도 상황을 보고 알아듣는 경우가 있다.

예를 들어 회사에서 팀원이 이렇게 말할 수 있다.

그거 아까 말한 내용으로 정리해줘.

같은 회의에 있었던 사람이라면 “그거”가 무엇인지 알 수 있다.
하지만 AI는 사용자가 알려주지 않은 회의 분위기, 내부 사정, 이전 맥락을 완벽히 알 수 없다.

그래서 AI에게는 더 명확한 지시가 필요하다.

오늘 회의에서 나온 회원 API 개선 논의 내용을 정리하려고 해.

목적:
- 개발그룹장에게 공유할 회의 요약 작성

포함할 내용:
- 결정된 사항
- 추가 검토가 필요한 사항
- 담당자별 후속 작업

문체:
- 간결한 보고용 문체

이렇게 요청하면 AI가 훨씬 정확한 방향으로 답변할 수 있다.

프롬프트가 중요한 이유는 AI가 똑똑하지 않아서가 아니다.
AI가 똑똑해도, 사용자가 원하는 결과를 알기 위해서는 충분한 지시가 필요하기 때문이다.

개발 업무도 마찬가지다.

이 코드 고쳐줘.

이렇게만 말하면 AI는 무엇을 기준으로 고쳐야 할지 추측해야 한다.

아래 코드는 로그인 API야.

문제:
- 로그인 실패 시 계정이 존재하지 않는지, 비밀번호가 틀렸는지 구분해서 응답하고 있어.
- 이 방식은 보안상 계정 존재 여부를 노출할 수 있어.

요청:
- 사용자에게는 동일한 실패 메시지를 내려줘.
- 서버 로그에는 실패 원인을 남겨줘.
- 기존 응답 형식은 최대한 유지해줘.

코드:
[코드 붙여넣기]

이렇게 요청하면 AI는 단순히 문법을 고치는 것이 아니라, 보안 목적에 맞게 코드를 수정할 수 있다.

좋은 프롬프트는 AI가 추측해야 하는 영역을 줄여준다.

3. 좋은 프롬프트는 모호하지 않다

좋은 프롬프트의 첫 번째 조건은 모호하지 않은 것이다.

AI에게 원하는 답변을 얻지 못하는 가장 흔한 이유는 요청이 너무 추상적이기 때문이다.

예를 들어 다음 표현은 모호하다.

좋게 바꿔줘.

여기서 “좋게”는 사람마다 다르게 해석될 수 있다.

더 정중하게 바꾸라는 뜻일 수도 있고,
더 짧게 줄이라는 뜻일 수도 있고,
더 전문적인 표현으로 바꾸라는 뜻일 수도 있다.

다음 표현도 마찬가지다.

깔끔하게 정리해줘.

“깔끔하게”가 표로 정리하라는 뜻인지,
문장을 줄이라는 뜻인지,
중복 내용을 제거하라는 뜻인지 알 수 없다.

모호한 요청은 구체적인 기준으로 바꿔야 한다.

프롬프트를 작성할 때는 다음 질문을 스스로 해보면 좋다.

AI가 이 요청을 보고 무엇을 해야 하는지 바로 알 수 있는가?
AI가 지켜야 할 조건이 명확한가?
결과물이 어떤 형태로 나와야 하는지 알 수 있는가?

AI는 모호한 부분을 스스로 채우려고 한다.
하지만 그 추측이 사용자의 의도와 다르면 원하는 결과가 나오지 않는다.

좋은 프롬프트는 AI가 추측하지 않아도 되게 만드는 것이다.

4. 프롬프트의 기본 구조

실무에서 사용할 프롬프트는 보통 다음 요소로 구성하면 좋다.

역할
→ 목적
→ 배경
→ 입력 데이터
→ 조건
→ 출력 형식

모든 요청에 이 요소를 전부 넣어야 하는 것은 아니다.

간단한 요청이라면 짧게 써도 된다.
하지만 중요한 작업일수록 이 구조를 갖추는 것이 좋다.

예를 들어 코드 리뷰 프롬프트를 이 구조로 작성하면 다음과 같다.

역할:
너는 10년 차 백엔드 개발자이자 코드 리뷰어야.

목적:
아래 코드를 운영 환경에 배포하기 전에 위험 요소를 점검하려고 해.

배경:
이 코드는 회원 로그인 API이고,
사용자 인증과 JWT 발급을 담당해.

입력 데이터:
[코드 붙여넣기]

조건:
- 보안 문제를 우선적으로 봐줘.
- 계정 존재 여부 노출 가능성을 확인해줘.
- SQL Injection 가능성을 확인해줘.
- 비밀번호나 토큰이 로그에 남을 가능성이 있는지 봐줘.
- 단순 스타일 취향은 제외해줘.

출력 형식:
1. 핵심 요약
2. 위험도 높은 문제
3. 개선 제안
4. 수정 코드 예시
5. 추가 확인 필요 사항

이렇게 작성하면 AI는 무엇을 해야 하는지, 어떤 관점으로 봐야 하는지, 어떤 형식으로 답해야 하는지 알 수 있다.

이제 각 요소를 하나씩 살펴보자.

5. 역할: 어떤 관점으로 답할지 정한다

역할은 AI가 어떤 관점에서 답변해야 하는지 정해주는 요소다.

같은 내용을 보더라도 역할에 따라 답변 방향이 달라진다.

예를 들어 같은 API 코드를 보고도 백엔드 개발자와 보안 담당자의 관점은 다르다.

너는 백엔드 개발자야.
아래 API 코드를 읽고 구조적으로 개선할 부분을 알려줘.

이 경우 AI는 함수 분리, 예외 처리, 응답 구조, 유지보수성 등을 중심으로 볼 가능성이 높다.

너는 보안 담당자야.
아래 API 코드를 읽고 보안상 위험한 부분을 알려줘.

이 경우 AI는 인증, 권한, 입력값 검증, 로그 노출, 민감 정보 처리 등을 더 중점적으로 볼 가능성이 높다.

역할은 문서 작성에서도 유용하다.

너는 CTO에게 보고하는 개발팀장이야.
아래 내용을 임원 보고용 문장으로 정리해줘.

또는 이렇게 쓸 수 있다.

너는 신입 개발자를 교육하는 멘토야.
아래 개념을 처음 듣는 사람도 이해할 수 있게 설명해줘.

역할을 줄 때 중요한 것은 직함 자체가 아니다.
AI에게 어떤 관점으로 답해야 하는지 알려주는 것이 중요하다.

역할 예시는 다음과 같다.

- 백엔드 개발자
- 프론트엔드 개발자
- 보안 담당자
- 인프라 엔지니어
- DBA
- 코드 리뷰어
- 기술 문서 작성자
- 신입 개발자 교육 담당자
- 임원 보고서를 작성하는 개발팀장

다만 역할만 주고 나머지 조건을 생략하면 부족하다.

너는 최고의 개발자야.
이 코드 고쳐줘.

이 요청은 역할은 있지만 목적과 조건이 부족하다.

더 좋은 요청은 다음과 같다.

너는 10년 차 백엔드 개발자야.

아래 코드는 결제 콜백 처리 로직이야.
중복 콜백이 들어와도 주문이 중복 처리되지 않도록
문제점을 찾고 개선 방향을 제안해줘.

역할은 답변의 관점을 잡아주고, 목적과 조건은 답변을 구체화한다.

6. 목적: 이 작업을 왜 하는지 알려준다

목적은 AI가 결과물을 어떤 용도로 만들어야 하는지 알려주는 요소다.

같은 요약이라도 목적에 따라 결과가 달라진다.

예를 들어 다음 요청은 목적이 없다.

아래 내용을 요약해줘.

이 경우 AI는 일반적인 요약을 할 가능성이 높다.

반면 다음 요청은 목적이 있다.

아래 회의 내용을 개발팀장이 임원에게 보고할 수 있도록 요약해줘.

이렇게 요청하면 AI는 세부 대화보다 결정 사항, 이슈, 후속 작업을 중심으로 요약하려고 한다.

장애 내용도 마찬가지다.

아래 장애 내용을 고객 공지문으로 작성하기 전에,
내부 원인과 외부에 공개 가능한 내용을 나눠서 정리해줘.

이 요청은 단순 요약이 아니다.

고객에게 공개 가능한 내용과 내부 검토용 내용을 나누는 것이 목적이다.

개발 작업에서도 목적은 중요하다.

아래 코드를 리팩토링해줘.

이 요청보다 다음 요청이 더 좋다.

아래 코드는 방송 시작 API의 일부야.

현재 조건문이 많아서 유지보수가 어렵기 때문에,
동작은 유지하면서 읽기 쉽게 리팩토링해줘.

목적이 들어가면 AI는 어떤 방향으로 결과를 만들어야 하는지 이해할 수 있다.

목적이 없는 프롬프트는 방향이 흔들릴 수 있다.
목적이 있는 프롬프트는 결과물이 실제 업무에 더 가까워진다.

7. 배경: 현재 상황을 설명한다

배경은 AI가 상황을 이해할 수 있도록 도와주는 정보다.

AI는 회사 내부 사정이나 서비스 구조를 기본적으로 알지 못한다.
그래서 필요한 배경은 사용자가 제공해야 한다.

예를 들어 다음 요청은 부족하다.

이 장애 원인 정리해줘.

어떤 서비스인지,
어떤 장애인지,
누구에게 보고할 것인지 알 수 없다.

배경을 추가하면 훨씬 좋아진다.

우리는 라이브 방송 플랫폼을 운영하고 있어.

어제 특정 시간대에 일부 방송방 입장이 지연되는 장애가 있었고,
원인은 Redis 응답 지연으로 추정돼.

아래 로그와 메모를 바탕으로
개발팀 내부 공유용 장애 원인 초안을 작성해줘.

배경은 길 필요가 없다.

AI가 판단하는 데 필요한 정도만 있으면 된다.

개발 질문에서 유용한 배경은 다음과 같다.

- 서비스 종류
- 사용 언어
- 프레임워크
- DB 종류
- 실행 환경
- 현재 문제
- 최근 변경 사항
- 제약 조건
- 결과물을 사용할 대상

예를 들어 SQL 검토를 요청할 때도 배경이 중요하다.

아래 SQL은 관리자 페이지에서 회원 목록을 조회할 때 사용돼.

상황:
- 회원 수는 약 500만 명
- 최근 가입자 순으로 정렬
- 검색 조건으로 닉네임, 이메일, 상태값이 들어올 수 있음
- 현재 페이지 로딩이 5초 이상 걸림

요청:
- 성능 문제가 될 수 있는 부분을 찾아줘.
- 필요한 인덱스 후보를 제안해줘.
- MySQL 8 기준으로 설명해줘.

SQL:
[SQL 붙여넣기]

배경이 없으면 AI는 일반적인 답변을 할 수밖에 없다.
배경이 있으면 현재 상황에 맞는 답변을 만들 수 있다.

8. 입력 데이터: AI가 처리할 대상을 명확히 준다

입력 데이터는 AI가 실제로 작업할 대상이다.

코드, 로그, SQL, 문서, 회의록, 에러 메시지, 메일 원문 등이 입력 데이터가 될 수 있다.

예를 들어 다음처럼 요청할 수 있다.

아래 에러 로그를 보고 원인 후보를 정리해줘.

[에러 로그]

아래 SQL의 성능 문제를 찾아줘.

[SQL]

아래 회의록에서 결정 사항과 액션 아이템을 뽑아줘.

[회의록]

입력 데이터가 길다면 지시사항과 데이터를 구분해주는 것이 좋다.

다음은 에러 로그야.

--- 로그 시작 ---
[로그 내용]
--- 로그 끝 ---

이 로그를 기준으로 원인 후보를 정리해줘.

이렇게 경계를 표시하면 AI가 어디까지가 분석 대상이고, 어디부터가 지시사항인지 구분하기 쉽다.

코드도 마찬가지다.

다음은 분석할 코드야.

--- 코드 시작 ---
[코드 내용]
--- 코드 끝 ---

요청:
- 전체 흐름을 설명해줘.
- 보안상 위험한 부분을 찾아줘.
- 수정 예시를 제안해줘.

입력 데이터가 여러 개인 경우에는 이름을 붙여주는 것이 좋다.

아래에는 두 가지 정보가 있어.

1. 장애 당시 로그
2. 운영자가 남긴 메모

이 두 내용을 함께 보고 장애 원인 후보를 정리해줘.

--- 장애 로그 ---
[로그]

--- 운영 메모 ---
[메모]

입력 데이터가 명확하면 AI 답변도 더 안정적이 된다.

9. 조건: 반드시 지켜야 할 기준을 정한다

조건은 AI가 답변을 만들 때 반드시 지켜야 할 기준이다.

조건은 매우 중요하다.

조건이 없으면 AI는 그럴듯한 방향으로 자유롭게 답변한다.
하지만 실무에서는 자유로운 답변보다 조건을 지킨 답변이 더 중요할 때가 많다.

예를 들어 코드 수정 요청에서는 다음 조건이 필요할 수 있다.

조건:
- 기존 함수명은 유지해.
- 외부 라이브러리는 추가하지 마.
- Node.js 20 기준으로 작성해.
- TypeScript 타입을 명확히 작성해.
- 기존 API 응답 형식은 유지해.

이 조건이 없으면 AI는 새로운 라이브러리를 추가하거나, 최신 문법을 사용하거나, 기존 응답 형식을 바꿔버릴 수 있다.

문서 작성에서도 조건이 중요하다.

조건:
- 원문에 없는 내용은 추가하지 마.
- 추측이 필요한 부분은 "추정"이라고 표시해.
- 문장은 짧게 작성해.
- 기술적인 내용은 개발자가 이해할 수 있는 수준으로 유지해.

고객 안내문에서는 이런 조건이 필요할 수 있다.

조건:
- 내부 시스템명은 노출하지 마.
- 장애 원인을 단정하지 마.
- 고객에게 불편을 드린 점에 대한 사과를 포함해.
- 보상 여부는 언급하지 마.
- 문체는 정중하게 작성해.

조건은 AI의 자유도를 줄이는 역할을 한다.

자유도가 줄어들면 답변이 덜 창의적일 수는 있다.
하지만 실무에서는 오히려 그게 장점이다.

특히 코드, 보안, 장애 보고, 고객 공지, 법무 검토처럼 책임이 따르는 작업에서는 조건을 명확히 주는 것이 중요하다.

10. 출력 형식: 결과물을 어떤 모양으로 받을지 정한다

출력 형식은 AI 답변을 어떤 구조로 받을지 정하는 요소다.

출력 형식을 지정하지 않으면 AI가 매번 다른 구조로 답할 수 있다.

예를 들어 다음 요청은 결과가 들쭉날쭉할 수 있다.

장애 원인 정리해줘.

더 좋은 요청은 다음과 같다.

아래 형식으로 정리해줘.

## 장애 개요
## 발생 시간
## 영향 범위
## 원인
## 조치 내용
## 재발 방지 대책
## 추가 확인 필요 사항

코드 리뷰에서는 표 형식이 유용할 수 있다.

아래 표 형식으로 코드 리뷰 결과를 정리해줘.

| 구분 | 문제점 | 영향 | 개선 방향 | 우선순위 |
| --- | --- | --- | --- | --- |

의사결정 자료에서는 다음 형식이 좋다.

다음 순서로 답변해줘.

1. 결론
2. 선택지 비교
3. 추천 이유
4. 리스크
5. 다음 액션

AI 응답을 프로그램에서 처리해야 한다면 JSON 형식이 유용하다.

아래 JSON 형식으로만 응답해줘.

{
  "summary": "",
  "riskLevel": "low | medium | high",
  "items": [
    {
      "type": "",
      "description": "",
      "suggestion": ""
    }
  ]
}

JSON으로 받으면 서버에서 결과를 파싱해 저장하거나 후속 로직에 연결하기 쉽다.

다만 AI에게 JSON으로 답하라고 했다고 해서 항상 완벽한 JSON이 나온다고 보장할 수는 없다.
서비스 코드에서는 JSON 파싱과 필드 검증이 반드시 필요하다.

JSON은 데이터를 주고받기 위한 대표적인 형식이다.
AI 응답을 JSON으로 받으면 프로그램에서 결과를 처리하기 쉽다.

11. 예시를 주면 원하는 스타일을 맞추기 쉽다

AI가 원하는 스타일을 잘 맞추지 못할 때는 예시를 주는 것이 좋다.

예시는 AI에게 “이런 식으로 답해달라”고 보여주는 기준이다.

예를 들어 문장 다듬기를 한다고 해보자.

아래 문장을 임원 보고용으로 다듬어줘.

원문:
서버가 좀 불안정해서 문제가 생겼습니다.

AI가 어느 정도 다듬어주겠지만, 원하는 톤과 다를 수 있다.

이럴 때 예시를 주면 좋다.

아래 예시와 같은 스타일로 문장을 다듬어줘.

예시:
원문: 서버가 좀 불안정해서 문제가 생겼습니다.
개선: 특정 시간대에 서버 응답 지연이 발생했으며, 원인 분석 및 재발 방지 조치를 진행 중입니다.

원문:
배포하다가 문제가 생겨서 일부 기능이 안 됐습니다.

예시가 있으면 AI는 문체, 길이, 표현 방식을 더 잘 맞춘다.

분류 작업에서도 예시는 유용하다.

아래 고객 문의를 유형별로 분류해줘.

유형:
- 결제
- 로그인
- 방송
- 환불
- 기타

예시:
문의: 결제가 두 번 됐어요.
분류: 결제

문의: 비밀번호를 잊어버렸어요.
분류: 로그인

문의: 방송이 자꾸 끊겨요.
분류: 방송

이제 아래 문의를 분류해줘.

문의:
하트를 충전했는데 반영이 안 돼요.

예시가 없으면 AI가 “하트”라는 표현을 일반적인 감정 표현으로 오해할 수 있다.

하지만 예시와 도메인 문맥을 함께 주면,
하트가 서비스 내 결제 또는 후원 단위라는 것을 더 잘 이해할 수 있다.

Few-shot은 몇 개의 예시를 보여준 뒤 같은 방식으로 답하게 하는 방법이다.
분류, 문장 변환, 보고서 작성, 데이터 추출 작업에서 특히 유용하다.

12. 복잡한 작업은 단계별로 요청한다

복잡한 작업을 한 번에 요청하면 AI가 놓치는 부분이 생길 수 있다.

예를 들어 다음 요청을 보자.

아래 코드를 분석하고 문제점을 찾고 리팩토링하고 테스트 코드까지 만들어줘.

AI가 어느 정도 처리할 수는 있다.

하지만 작업 범위가 넓기 때문에 일부 내용이 얕아질 수 있다.
분석이 부족한 상태에서 바로 코드를 수정하거나, 테스트 코드가 실제 문제를 반영하지 못할 수 있다.

이럴 때는 작업을 단계별로 나누는 것이 좋다.

1단계:
아래 코드의 전체 흐름을 먼저 설명해줘.

2단계:
흐름을 바탕으로 문제점을 찾아줘.

3단계:
문제점 중 우선순위가 높은 것부터 개선 방향을 제안해줘.

4단계:
개선된 코드 예시를 작성해줘.

5단계:
해당 코드에 대한 테스트 케이스를 만들어줘.

문서 작성도 마찬가지다.

1단계:
아래 회의록에서 핵심 쟁점을 뽑아줘.

2단계:
쟁점을 기준으로 임원 보고용 목차를 만들어줘.

3단계:
목차를 바탕으로 보고서 초안을 작성해줘.

4단계:
문체를 더 간결하게 다듬어줘.

단계별 요청의 장점은 중간 결과를 확인할 수 있다는 것이다.

AI가 초반에 방향을 잘못 잡았을 때 바로 수정할 수 있다.
그래서 최종 결과도 더 좋아진다.

AI를 잘 쓰는 사람은 한 번에 완성된 결과를 요구하기보다,
작업을 작은 단위로 나누고 결과를 보면서 다음 요청을 이어간다.

13. 실무에서 자주 쓰는 프롬프트 패턴

이제 실무에서 바로 사용할 수 있는 프롬프트 패턴을 정리해보자.

이 패턴들은 그대로 외울 필요는 없다.
필요한 상황에 맞게 바꿔서 사용하면 된다.

13.1 요약 패턴

긴 문서, 회의록, 메일 내용을 정리할 때 사용한다.

아래 내용을 요약해줘.

목적:
- 개발팀 내부 공유용

조건:
- 핵심 결정 사항 중심
- 후속 작업은 담당자 기준으로 정리
- 확인이 필요한 내용은 별도 표시

출력 형식:
1. 핵심 요약
2. 결정 사항
3. 후속 작업
4. 확인 필요 사항

내용:
[문서 또는 회의록]

13.2 코드 리뷰 패턴

코드를 검토할 때 사용한다.

너는 백엔드 코드 리뷰어야.

아래 코드를 리뷰해줘.

관점:
- 버그 가능성
- 보안 문제
- 예외 처리
- 성능 문제
- 유지보수성

조건:
- 실제 문제가 될 가능성이 높은 것부터 정리
- 단순 취향은 제외
- 수정 예시가 있으면 함께 제시

코드:
[코드]

13.3 에러 분석 패턴

에러 로그를 분석할 때 사용한다.

아래 에러 로그를 분석해줘.

상황:
- Node.js API 서버에서 발생
- 최근 배포 이후 에러 증가
- 특정 API에서만 발생하는 것으로 보임

요청:
- 가능한 원인 후보를 우선순위로 정리
- 추가로 확인해야 할 로그를 제안
- 임시 대응과 근본 대응을 나눠서 제안

로그:
[에러 로그]

13.4 문장 다듬기 패턴

보고 문장, 메일, 공지문을 다듬을 때 사용한다.

아래 문장을 임원 보고용으로 다듬어줘.

조건:
- 핵심이 먼저 나오게 작성
- 책임 회피처럼 보이지 않게 작성
- 기술적인 표현은 필요할 때만 사용
- 문장은 간결하게 작성

원문:
[문장]

13.5 비교 분석 패턴

기술 선택지를 비교할 때 사용한다.

아래 두 방식을 비교해줘.

비교 대상:
1. AWS Lambda
2. ECS Fargate

상황:
- 관리자용 AI 요약 기능을 만들 예정
- 요청량은 많지 않음
- 초기 개발 속도와 운영 부담이 중요

비교 기준:
- 개발 난이도
- 운영 부담
- 비용
- 확장성
- 장애 대응
- 추천 상황

출력은 표와 결론으로 정리해줘.

13.6 체크리스트 생성 패턴

배포 전 점검이나 보안 검토에 사용할 수 있다.

아래 기능을 운영 배포하기 전에 확인해야 할 체크리스트를 만들어줘.

기능:
- AI 기반 고객 문의 요약 기능

관점:
- 보안
- 개인정보
- 비용
- 장애 대응
- 로그
- 관리자 UX

출력 형식:
| 구분 | 체크 항목 | 확인 방법 | 중요도 |

14. 프롬프트 작성 시 피해야 할 표현

프롬프트를 작성할 때는 피해야 할 표현도 있다.

대표적으로 너무 추상적인 표현이다.

좋게 해줘.
알아서 해줘.
적당히 정리해줘.
깔끔하게 만들어줘.
괜찮게 바꿔줘.

이런 표현은 사람끼리는 어느 정도 통할 수 있다.

하지만 AI에게는 기준이 불명확하다.

대신 다음처럼 구체적으로 바꾸는 것이 좋다.

좋게 해줘
→ 임원 보고용으로 간결하고 객관적인 문체로 바꿔줘.

알아서 해줘
→ 비용, 운영 부담, 보안 기준으로 우선순위를 판단해줘.

정리해줘
→ 핵심 요약, 결정 사항, 후속 작업으로 나눠 정리해줘.

깔끔하게 만들어줘
→ 중복 표현을 제거하고 표 중심으로 정리해줘.

또 하나 피해야 할 것은 너무 많은 요구를 한 번에 넣는 것이다.

이거 분석하고 수정하고 테스트 코드 만들고 문서도 써주고 배포 전략도 알려줘.

이런 요청은 결과가 얕아질 수 있다.

작업이 크다면 단계별로 나누는 것이 좋다.

프롬프트는 AI에게 주는 작업 지시서다.
작업 지시서가 모호하면 결과도 모호해진다.

15. 프롬프트와 보안

프롬프트를 작성할 때는 보안도 고려해야 한다.

AI에게 질문하면서 무심코 민감 정보를 넣을 수 있다.

예를 들어 다음 정보는 그대로 입력하지 않는 것이 좋다.

- 실제 사용자 이름
- 이메일
- 전화번호
- 주민등록번호
- 결제 정보
- API Key
- Access Token
- DB 접속 정보
- 내부 서버 IP
- 비공개 계약 내용

에러 로그를 분석할 때도 주의해야 한다.

로그에는 생각보다 많은 민감 정보가 들어갈 수 있다.

user_email=real-user@example.com
access_token=eyJhbGciOi...
db_password=...

AI에게 전달하기 전에 마스킹하는 습관이 필요하다.

user_email=[USER_EMAIL]
access_token=[ACCESS_TOKEN]
db_password=[DB_PASSWORD]

회사에서 AI를 사용할 때는 팀 단위의 규칙을 정하는 것이 좋다.

- 외부 AI에 입력 가능한 데이터 기준
- 입력 금지 데이터 목록
- 로그 마스킹 방법
- 코드 입력 허용 범위
- 고객 정보 처리 기준
- AI 답변 검토 절차

프롬프트 엔지니어링은 단순히 좋은 답을 얻는 기술만이 아니다.

AI에게 어떤 데이터를 입력해도 되는지 판단하는 보안 습관도 포함된다.

마스킹은 민감한 값을 그대로 노출하지 않도록 일부 또는 전체를 가리는 것이다.
예를 들어 실제 이메일 대신 [USER_EMAIL], 실제 토큰 대신 [ACCESS_TOKEN]처럼 바꿔서 입력할 수 있다.

16. 좋은 프롬프트의 기본 공식

지금까지 내용을 정리하면 좋은 프롬프트는 다음 공식으로 만들 수 있다.

역할 + 목적 + 배경 + 입력 데이터 + 조건 + 출력 형식

예를 들어 다음과 같은 구조다.

역할:
너는 10년 차 백엔드 개발자야.

목적:
운영 배포 전에 로그인 API의 위험 요소를 점검하려고 해.

배경:
이 API는 사용자 로그인과 세션 발급을 담당해.
로그인 실패 횟수를 기록하고,
관리자와 일반 사용자가 같은 API를 사용하고 있어.

입력 데이터:
[코드 붙여넣기]

조건:
- 보안 문제를 우선적으로 봐줘.
- 계정 존재 여부 노출 가능성을 확인해줘.
- SQL Injection 가능성을 확인해줘.
- 비밀번호나 세션 값이 로그에 남을 가능성을 확인해줘.
- 단순 코드 스타일 취향은 제외해줘.

출력 형식:
1. 핵심 요약
2. 위험도 높은 문제
3. 개선 제안
4. 수정 코드 예시
5. 추가 확인 필요 사항

모든 프롬프트를 이렇게 길게 쓸 필요는 없다.

간단한 작업은 짧게 요청해도 된다.

아래 문장을 더 자연스럽게 다듬어줘.

조건:
- 의미는 바꾸지 마.
- 문장은 짧게 유지해.

중요한 것은 AI가 추측해야 할 영역을 줄이는 것이다.

프롬프트가 명확할수록 AI 답변도 실무에 가까워진다.

17. 정리

프롬프트는 AI에게 일을 시키는 요청문이다.

AI는 사용자가 입력한 요청을 바탕으로 답변을 만든다.
그래서 프롬프트가 모호하면 결과도 모호해지고, 프롬프트가 구체적이면 결과도 구체적일 가능성이 높아진다.

좋은 프롬프트에는 보통 역할, 목적, 배경, 입력 데이터, 조건, 출력 형식이 들어간다.

역할은 답변의 관점을 정하고,
목적은 작업의 이유를 알려주고,
배경은 현재 상황을 설명하고,
입력 데이터는 AI가 처리할 대상을 제공하고,
조건은 지켜야 할 기준을 정하고,
출력 형식은 결과를 사용하기 쉽게 만든다.

프롬프트를 잘 쓴다는 것은 단순히 예쁜 질문을 쓰는 것이 아니다.

AI가 제대로 일할 수 있도록 업무 지시를 명확하게 하는 것이다.

개발자는 앞으로 AI에게 일을 맡기는 일이 많아질 것이다.
그럴수록 프롬프트 작성 능력은 중요한 개발 역량이 된다.

이 장에서 기억해야 할 핵심은 하나다.

AI에게 좋은 답을 얻으려면, 먼저 좋은 작업 지시를 해야 한다.

5장 핵심 요약