260120 [ Day 16 ] - AI (5)

시작하며

오늘은 어제에 이어 LLM에 대한 내용을 배운 뒤, AI를 더 잘 활용할 수 있도록 프롬프트 엔지니어링을 배웠다.

Transformer Architecture(The Core Modules)

• Encoder : 전역적 문맥 분석 및 특징 추출
  • Attention Score : 문장 내 토큰 간의 연관성을 수치화한 표현(가중치)
  • Self-Attention을 통해 문맥적 좌표 생성
• Decoder : 자기회귀적 문장 생성
  • Encoder가 생성한 문맥 정보와 현재까지 생성된 토큰을 결합(Autoregressive, 자기회귀)하여 다음 토큰을 예측

Encoder와 Decoder는 각각의 독립적인 모듈로 이해

Self-Attention이 문맥을 계산하는 방법

• Query(질문) : 지금 찾고자 하는 정보의 주체는 누구인지
• Key(검색 대상) : 비교할 대상들이 가진 특징은 무엇인지
• Value(정보 내용) : 관계가 확인되었을 때 가져올 실제 데이터값

Query와 Key를 대조해서 Attention Score를 구하고, 이를 Value에 곱해 최종 문맥정보를 산출

Multi-Head Attention

• Multi-Head : 하나의 시선이 아닌 여러 개의 어텐션 헤드가 동시에 작동
• Parallel Perspective : 주어-동사 관계, 대명사 관계, 수식 관계 등을 각기 다른 헤드가 분석
• Ensemble 효과 : 다양한 문맥적 정보를 병렬로 처리하여 정보의 누락 방지

Positional Encoding

• 트랜스포머는 문장을 한꺼번에 읽기 때문에 단어의 위치 정보를 알 수 없음
• 각 토큰의 좌표에 위치정보가 담긴 특수한 값을 더해줌
• 무낵을 구분할 수 있는 질서 부여

Masking

• Padding Mask : 의미 없는 [PAD] 토큰에 시선이 분산되는 것을 방지
• Causal Mask(인과관계) : 디코더가 미래의 단어를 미리 보고 컨닝하지 못하도록 가림

Transformer와 LLM

• RNN의 순차적 한계를 극복하고 데이터 전체를 동시에 연산(병렬 처리)
• 하드웨어(GPU) 가속에 최적화되어 데이터와 파라미터를 무한히 늘릴 수 있음
• 문장이 아무리 길어져도 전역적 문맥을 놓치지 않는 강력한 기억력(어텐션)
• 규모의 법칙 확인 : 데이터를 많이 넣었더니 성능이 대폭 증가

Transformer로 LLM 만들기

• MLM(Masked Language Modeling)
  • 문장 중간의 구멍을 생성하고 앞뒤 문맥으로 맞히기
  • 독해 능력 증가
  • BERT = 인코더 사용
• CLM(Causal Language Modeling)
  • 이전 단어들을 보고 다음 단어를 순차적으로 예측
  • 작문 능력 증가
  • GPT = 디코더 사용

Fine Tuning

• 모델의 가중치를 직접 수정하는 과정
• 이미 학습된 기초 모델(Pre-trained Model)에 특정 데이터를 추가로 학습시켜 모델 뇌 구조 자체를 변화
• 도메인 특화 성능 극대화
• 학습을 위한 양질의 데이터셋과 GPU 연산 비용 발생

Prompting

• In-context Learning(ICL, 문맥 내 학습)
  • 모델이 추가적인 가중치 업데이트 없이, 입력된 프롬프트의 문맥만 보고 즉석에서 태스크를 이해하고 수행
• Shot Learning : ICL을 구현하는 구체적인 기법 중 하나
  • 프롬프트에 2~5개 정도의 예시(Shot)를 포함시켜 모델에게 가이드를 주는 방식
  • Zero-shot : 예시 0개(지시만 진행)
  • One-shot : 예시 1개 보여줌
  • Few-shot : 예시 2~5개 보여줌

Instruction Tuning(명령어 조정)

• 지시사항(Instruction)과 답변 쌍을 학습시키는 과정
• 단순히 다음 단어를 맞히는 것(CLM)을 넘어, 명령의 의도를 파악하게 함
• SFT(Supervised Fine-Tuning) : 사람이 장성한 [명령어-정답]세트를 대량으로 학습시켜 모델의 행동 양식을 교정

RLHF(Reinforcement Learning from Human Feedback)

• 인간의 가치간과 선호도를 모델에 반영하는 최종 단계
• AI가 내놓은 여러 답변 중 사람이 더 좋은 답변을 선택하면 그 방향으로 모델을 강화

프롬프트 엔지니어링

정의

• 프롬프트 엔지니어링은 생성형 AI가 원하는 결과를 내도록, 입력(지시/맥락/데이터/예시/제약/형식)을 설계하고 반복 개선하는 기술
  • 테스트와 결과확인 반복 수행

필요성

• 모호한 요청 → 모호한 결과
• 추측 채우기 : 정보가 부족하면 그럴듯하게 메움
• 형식 불안정 : 출력 포맷을 강제하지 않으면 재사용 어려움
• 일관성/재현성 문제 : 같은 요청이어도 결과가 흔들릴 수 있음

“좋은 프롬프트”는 문장력이 아닌 명세(스펙) + 예시 + 검증(테스트)로 만들어짐

LLM이 답을 만드는 방식

핵심 직관

• 지시를 따르려 하지만, 충돌하는 지시가 있으면 우선순위를 자체적으로 정함
• 문맥(컨텍스트)이 곧 전부 : 제공한 정보의 범위가 답의 범위를 만듦
• 형식은 명시해야 유지 : 원하는 출력 구조를 “구체적으로”주면 안정

LLM에 대한 오해

• 모델이 항상 사실을 말한다 → No, 주어진 정보 + 패턴으로 생성
• 길게 시키면 더 똑똑해진다 → 길이는 경우에 따라 도움이 될 수도, 노이즈가 될 수도 있음
• 좋은 프롬프트는 멋진 문장 → No, 명세 + 예시 + 검증

표준 프롬프트 구조

프롬프트는 “요청”이 아닌 요구사항 명세서

표준 구성요소

요소	무엇을 결정하나	실무 효과
역할(Role)	관점/전문성	답변 톤/전개가 안정
목표(Objective)	결과물 정의	결과의 방향이 고정
맥락(Context)	대상/사용처	불필요한 설명 감소
입력(Input)	원문/데이터	추측(환각) 감소
출력 형식(Output format)	표/JSON/섹션	재사용/자동화 용이
제약(Constraints)	길이/금지/근거	품질 흔들림 감소
평가 기준(Evaluation)	체크리스트/루브릭	“좋은 답” 정의
불확실성 처리(Clarify)	질문/근거 없음	안전성/정확성 개선

템플릿 예시

너는 [역할]이다.
목표 : [결과물]을/를 [성공 기준]에 맞게 만든다.
맥락:

- 대상 :
- 사용처 :
- 톤/문체 :

입력 :
<<<
[데이터/원문/요구사항]

>>>

제약 :

- 반드시 포함 :
- 금지 :
- 길이 :
- 근거 규칙 : 입력에 없는 내용은 추측하지 말고 "근거 없음"이라고 표기

출력 형식 :

- (예: 마크다운 섹션 / 표 / JSON 스키마)

불확실하면 :

- 진행 전 확인 질문 최대 3개

측정 가능하게 “성공 기준”을 예시로 들어줘야 함

지시 설계 원칙

• 모호한 형용사를 측정 가능한 기준으로 바꿔라
• 대상/사용처를 명시하라(임원/신입/고객/개발자 등)
• 출력 형식을 고정하라(표/JSON/섹션)
• 금지/제약을 먼저 설계하라(과장, 단정, 길이 등)
• 근거 제한을 걸어라(“문서에 있는 내용만”)
• 요청이 불완전하면 확인 질문을 강제하라
• 예시 1개가 설명 20줄을 이긴다(샘플 출력)
• 한 번에 끝내지 말고 루프를 설계하라(초안→비평→개선)
• 충돌 지시를 제거하고 우선순위를 명시하라(짧음 vs 자세함)
• 테스트 케이스로 재현성을 확보하라(정상/엣지)

빠른 자기점검
- [ ] 출력 포맷이 고정돼 있다(표/JSON/md/섹션)
- [ ] “없으면 근거 없음” 규칙이 있다
- [ ] 금지/제약이 있다(길이/톤/표현)
- [ ] 평가 기준(체크리스트)이 있다
- [ ] 테스트 케이스가 있다

작업 유형별 패턴

요약(Summary)

아래 문서를 [대상/목적]용으로 요약해라.
출력: 한줄 결론 / 핵심 3개 / 리스크 2개 / 다음 액션 1개
각 항목은 1문장.
문서:
<<<
...
>>>

추출(Extraction)

아래 텍스트에서 정보를 추출해 JSON으로 출력해라.
스키마:
{
"title": "",
"date": "",
"owner": "",
"action_items": [],
"risks": []
}
없는 값은 null로 두고 추측 금지.
텍스트:
<<<
...
>>>

분류(Classification)

너는 분류기다.
라벨은 아래 중 하나만 선택:
- 결제
- 환불
- 계정
- 버그
- 기타
라벨 정의:
... (각 라벨의 경계를 1~2문장으로)
출력: [입력 | 라벨 | 근거 1줄]

생성(카피/기획/문서)

너는 [직무]다.
목표: [채널]용 결과물 [N개].
제약:
- 톤:
- 금지어:
- 길이:
출력: 결과물 | 의도 | 타겟

변환(Rewrite/Transform)

너는 전문 편집자다.
내가 주는 초안을 먼저 "진단"하고, 그 다음 "개선안"을 제시해라.

규칙:
- 1단계: 문제점 7개(명확성/논리/중복/근거/톤/구조/독자 적합성).
- 2단계: 개선한 글을 제시.
- 3단계: 다음에 더 좋아지려면 어떤 정보 3개가 추가로 필요한지 질문.

초안:
<<<
[여기에 아무 글이나]
>>>

평가/검증(재현성 만들기)

루브릭(채점기준표) 예시

항목	1점	3점	5점
정확성(근거)	추측/단정	일부 근거	근거 명확/제한 준수
형식 준수	자주 깨짐	대체로 준수	완전 준수
누락	핵심 빠짐	일부 포함	핵심 완전
명확성	모호함 많음	보통	모호성 최소
톤/브랜드	부적합	대체로 적합	매우 적합
실행 가능성	액션 없음	일부 있음	다음 단계 명확

테스트 케이스 템플릿(정상4/엣지4)

| 구분 | 입력 요약 | 기대 조건(형식/포함/금지) |
|---|---|---|
| 정상1 | | |
| 정상2 | | |
| 정상3 | | |
| 정상4 | | |
| 엣지1 | | |
| 엣지2 | | |
| 엣지3 | | |
| 엣지4 | | |

회귀(regression) 방지
프롬프트를 고쳤으면 반드시 테스트 케이스 8개를 다시 실행해서 더 나빠지지 않았는지 확인한다.

디버깅(실패를 고치는 루틴)

디버깅의 핵심
”프롬프트를 크게 갈아엎기”보다 스펙을 1~2줄 추가하는 게 효과가 큰 경우가 많음

디버깅 절차

• 증상 한 줄로 기록 : 무엇이 마음에 안 들었나(형식/톤/누락/길이/근거)
• 원인 1개만 선택 : 제약 부족, 입력 부족, 포맷 미고정
• 프롬프트에 1~2줄만 추가 : 금지/형식/체크리스트/근거 제한/질문 규칙

디버깅 체크리스트(프롬프트에 붙이기 좋은 문장)
- [ ] “출력 형식은 표/JSON/섹션으로 고정한다.”
- [ ] “입력에 없는 내용은 추측하지 말고 ‘근거 없음’으로 표기한다.”
- [ ] “불확실하면 확인 질문 최대 3개를 먼저 한다.”
- [ ] “제출 전 체크리스트를 만족하는지 점검하고, 위반 시 스스로 수정한다.”

마치며

영어로 접근하니까 헷갈리는 용어들이 너무 많아서 자격증 시험이 끝나면 용어 모음집을 만들어서 정리를 해둬야 될 것 같다.
프롬프트 엔지니어링은 클로드 코드 커스텀 커맨드를 만드는 것과 매우 비슷해서 다음 커맨드를 만들 때 오늘 배운 내용들을 활용하면 더 완성도 있는 커맨드를 만들 수 있을 것 같다.