AI 용어 최신 지도
프롬프트에서 루프로

관통하는 관점 하나: "AI에게 정답을 한 번에 묻지 말고, 정답을 찾을 때까지 고치게 시켜라." 아래 5개는 전부 이 문장의 부품이다.

루프 = 5개 부품 + 기억 1개

2025년까지는 루프를 만들려면 bash 스크립트 더미를 직접 짜고 평생 관리해야 했다. 지금은 부품이 제품 안에 그냥 들어 있다. 그래서 "어느 도구를 쓸까"를 싸울 필요가 없다 — 어느 쪽에 앉아도 같은 모양의 루프를 설계하면 된다.

왼쪽 점선 = 다음 실행이 상태 파일에서 이어받는 경로. 여기가 끊기면 매번 처음부터 시작한다.

부품별 해설

① 오토메이션 — 루프를 '루프'로 만드는 것

이게 없으면 그냥 한 번 돌린 실행이지 루프가 아니다. 주기를 정해 두면 AI가 어제의 CI 실패, 열린 이슈, 최근 커밋을 스스로 훑어서 할 일을 트리아지 인박스에 쌓아둔다. 찾은 게 없는 실행은 알아서 사라진다.

/loop와 /goal의 차이 — 시험에 나온다:

/loop은 주기가 있고, /goal은 끝이 있다. 초보자가 가장 많이 헷갈리는 한 쌍.

② 워크트리 — 병렬이 아수라장이 되지 않게

에이전트를 두 대 이상 돌리는 순간 파일이 충돌한다. 두 사람이 같은 줄을 서로 말없이 고치는 것과 정확히 같은 문제다. git worktree는 같은 저장소 히스토리를 공유하면서 별도 작업 디렉터리 + 별도 브랜치를 주기 때문에, 한쪽 에이전트의 수정이 다른 쪽 체크아웃을 물리적으로 건드릴 수 없다.

③ 스킬 — 매번 프로젝트를 다시 설명하지 않으려고

에이전트는 모든 세션을 차가운 상태로 시작하고, 의도에 구멍이 있으면 자신 있게 추측으로 메운다. 이게 의도 부채(Intent Debt)다. 스킬은 그 의도를 바깥에 한 번 적어 두는 것 — 관례, 빌드 절차, "그 사건 때문에 우리는 이렇게 안 한다" 같은 것. 스킬이 없으면 루프는 매 사이클마다 프로젝트를 맨바닥에서 재추론한다. 있으면 누적된다.

스킬 vs 플러그인: 스킬은 작성 형식, 플러그인은 배포 방법. 저장소 여러 곳에 나눠주고 싶으면 스킬을 플러그인으로 묶는다.

④ 플러그인·커넥터 — 루프가 실제 세계를 만진다

파일 시스템밖에 못 보는 루프는 작은 루프다. MCP 위에 세워진 커넥터가 이슈트래커를 읽고, DB에 질의하고, 스테이징 API를 치고, 슬랙에 메시지를 남긴다. "여기 고치는 법입니다"라고 말하는 에이전트와 PR을 열고 티켓을 연결하고 CI 초록불 뜨면 채널에 알리는 루프의 차이가 여기서 갈린다.

⑤ 서브에이전트 — 만든 놈과 검사하는 놈 떼어놓기

루프에서 구조적으로 가장 쓸모 있는 한 수. 루프는 당신이 안 보는 동안 돈다. 그래서 자리를 뜰 수 있는 유일한 근거는 믿을 만한 검증자다. 서브에이전트는 각자 모델과 도구를 돌리므로 토큰을 더 태운다 — 두 번째 의견이 값어치 있는 곳에만 쓴다.

⑥ 상태 — 루프의 척추

마크다운 파일 하나, 또는 이슈 보드. 대화 밖에 살면서 뭐가 끝났고 뭐가 남았는지 붙잡고 있는 것. 이게 있어야 내일 아침 실행이 오늘 멈춘 자리에서 이어진다.

루프 하나의 실제 모양

매일 아침 09:00  [오토메이션 발동]
  └─ 트리아지 스킬 호출
       ├─ 어제 CI 실패 읽기
       ├─ 열린 이슈 읽기
       └─ 최근 커밋 읽기
  └─ 발견 사항을 progress.md 에 기록          ← ⑥ 상태

  각 항목마다:
    ├─ 격리된 워크트리 생성                    ← ② 충돌 방지
    ├─ 서브에이전트 A: 수정안 작성             ← ⑤ 생성자
    └─ 서브에이전트 B: 프로젝트 스킬 + 기존 테스트 기준으로 검수  ← ⑤ 평가자

  통과 시 → 커넥터가 PR 생성 + 티켓 갱신 + 슬랙 알림   ← ④
  실패 시 → 트리아지 인박스에 남겨 사람에게              ← 에스컬레이션

  [종료] 내일 아침 실행이 progress.md 부터 이어받음

여기서 당신이 프롬프트를 친 단계가 하나도 없다. 한 번 설계했을 뿐이다. 그게 루프 엔지니어링이다.

0. 지도 먼저 — AI · 머신러닝 · LLM의 관계

초보자가 가장 먼저 헷갈리는 것은 새 용어가 아니라 낡은 용어들끼리의 관계다. 포함 관계 하나면 정리된다.

"AI가 발전했다"는 말의 99%는 맨 안쪽 칸 이야기다.

1강. LLM은 무엇인가 — "다음 단어를 맞히는 기계"

"오늘 날씨가 참 ___" 다음에 뭐가 올까? '좋다'가 높은 확률, '자동차'는 낮은 확률. 이걸 한 단어씩 반복하면 문장이 되고 문서가 된다. 이 한 줄을 이해하면 아래 세 가지 문제가 전부 자동으로 설명된다.

학습(Training) vs 추론(Inference) — 초보자가 가장 많이 섞는 둘

"제가 AI를 학습시켰어요"라고 말하는 사람의 99%는 추론 단계에서 프롬프트를 잘 준 것이다.

여기서 파생되는 3가지 — 전부 같은 뿌리

2강. 토큰과 컨텍스트 윈도우 — 기억력이자 요금

토큰 (Token)

AI가 글을 세는 단위. 글자도 단어도 아닌 그 중간이다. 영어는 대략 4글자 ≈ 1토큰, 한글은 1글자 ≈ 1~2토큰이라 같은 내용이라도 한글이 더 많이 든다. 요금은 글자 수가 아니라 토큰 수로 계산된다.

컨텍스트 윈도우 (Context Window)

한 번에 책상 위에 펼칠 수 있는 종이의 양. 이걸 넘으면 오래된 종이부터 책상에서 밀려난다. "아까 말했잖아"가 안 통하는 순간이 바로 이때다. AI가 까먹은 게 아니라 애초에 안 보이는 상태가 된 것이다.

대화가 길어질수록 같은 질문도 요금이 비싸진다. 파란 칸(새 질문)은 그대로인데 회색 칸이 계속 자라기 때문.

초보자가 오늘 바로 쓸 규칙 3개

• 주제가 바뀌면 새 대화를 연다. 긴 대화를 이어가는 게 미덕이 아니다. 요금과 정확도 둘 다 나빠진다.
• 필요한 부분만 붙여넣는다. 파일 전체를 넣으면 중간 내용이 무시되기 쉽다(Lost in the Middle).
• 넘어갈 땐 요약을 들고 간다. "지금까지 결정된 것만 5줄로 정리해줘" → 그걸 새 대화에 붙인다.

3강. 프롬프트 — 말 거는 법의 기본

좋은 프롬프트 4요소

# 프롬프트 기본 틀

역할:   너는 ______________ 다.
목표:   ______________ 를 해라.
제약:   ______________ 는 하지 마라. 모르면 모른다고 해라.
형식:   ______________ 형태로 출력해라.

[자료 붙여넣기]

4강. 모델 이름 읽는 법

모델 이름은 대체로 [제품군] + [등급] + [세대] 구조다. Claude의 Opus·Sonnet·Haiku, 다른 회사의 Pro·Flash·mini 같은 이름이 등급이고, 붙은 숫자가 세대다.

5강. 내 정보를 AI에 넣는 3가지 방법

초보자 질문 1순위: "우리 회사 문서를 AI가 알게 하려면요?" 답은 셋 중 하나다.

①②는 컨텍스트에 들어간다(임시). ③만 가중치를 건드린다(영구). 대부분의 문제는 ①②로 끝난다.

6강. 챗봇에서 에이전트로 — 앞 탭과 이어지는 지점

여기까지가 "AI와 대화하기"다. 그런데 2026년의 주제는 "AI에게 일 시키기"다. 둘을 가르는 선은 딱 하나 — 도구를 쓸 수 있는가.

도구를 쥐여준 순간 AI는 말하는 존재에서 행동하는 존재가 된다. 하네스와 루프가 필요해진 이유가 정확히 이것이다 — 행동에는 안전벨트와 정지 버튼이 필요하니까.

기초 용어 30 — 한 줄 사전

위 6강에 나온 것들의 요약. 수강생 배포용으로 이 표만 잘라 써도 된다.

모델·구조

동작·한계

쓰는 법

심화 용어 24 — 앞 탭에서 쓰는 말들

여기서부터는 「핵심 키워드 5」 탭을 들은 뒤 읽는다. 층별로 묶었다.

루프 층

하네스 층

컨텍스트 층

사람 쪽 용어 — 사실 이게 제일 중요하다

실습 설계 원칙

이 강좌의 실습은 코드 작성이 아니다. 루프를 글로 정의하는 연습이다. 루프 엔지니어링에서 실제로 사람이 하는 일이 그것이기 때문이다.

개발자비개발자 트랙을 나눠 표기했다. 실습 4-2는 공통 필수.

변수 — 여기부터 채운다

실습 전체가 변수 치환식이다. 아래 5개를 정하면 나머지 프롬프트는 복사만 하면 된다. 주제를 바꿔 다시 돌릴 때도 이 표만 갈아끼운다.

실습 4-1 · 루프 6부품 채우기 개발자비개발자

내가 반복하는 업무 하나를 {주제}에 넣고 빈칸을 채운다. 도구는 아직 안 건드린다.

# {주제} 루프 설계서

목표(Goal):     {주제}
발동 주기:      □ 매일 __:__   □ 커밋할 때마다   □ 수동 실행
{도구}:         ______________________________________

① 오토메이션:  무엇을 스스로 찾아오게 할 것인가?
   → ____________________________________________

② 격리:        동시에 돌 작업이 서로 충돌하는가? (Y/N)
   → ____________________________________________

③ 스킬(지식):  매번 다시 설명하기 싫은 프로젝트 규칙 3개
   1. __________  2. __________  3. __________

④ 연결(도구):  루프가 만져야 하는 외부 시스템
   → ____________________________________________

⑤ 검증자:      누가 "잘 됐다"를 판정하는가? (생성자와 달라야 함)
   → ____________________________________________

⑥ 기억:        진행 상황을 어디에 적을 것인가?
   → ____________________________________________

실습 4-2 · 종료 조건 쓰기 개발자비개발자 ★ 핵심

같은 목표를 나쁜 종료 조건과 좋은 종료 조건 두 벌로 쓴다.

템플릿:

[{주제}] 종료 조건

성공 시 정지:   {검증도구} 가 ______________ 이면
실패 시 정지:   ______________ 를 ___회 반복해도 안 되면
사람 호출:      ______________ 상황이 오면
비용 상한:      {상한} — 토큰 ______ / 금액 $______ / 시간 ______분 / 건수 ______

자가 검사:

• 성공 조건을 사람 눈 없이 판정할 수 있는가?
• 실패 종료가 따로 있는가? (성공 조건만 있으면 무한 루프)
• 사람 호출 조건이 있는가?
• 상한이 최소 하나 숫자로 적혔는가?

실습 4-3 · 생성자 / 평가자 갈라보기 개발자비개발자

같은 AI에게 세 번 시킨다. B와 C의 차이가 오늘의 결론이다.

프롬프트 A — 생성자 (1차)

{주제} 를 수행해줘.

산출물: {산출물}
제약:   (있으면 여기 적기)

프롬프트 B — 자기평가 (2차, 같은 대화창)

방금 네가 만든 결과물 어때? 문제 있어?

십중팔구 "잘 만들어졌습니다"가 나온다. 이 답을 그대로 복사해 둔다. 비교 대상이다.

프롬프트 C — 회의적 평가자 (3차, 반드시 새 대화창)

너는 깐깐한 리뷰어다.
아래는 "{주제}" 작업의 결과물이다.

[결과물 붙여넣기]

이 결과물이 실패할 이유 3가지를 찾아라.
- 판정 기준: {검증도구}
- "문제가 없다"고 답하는 것은 허용되지 않는다.
- 추측 금지. 결과물 안의 구체적 위치를 인용해라.

실습 4-4 · 실행 기록 개발자비개발자 ★ 강의 자료가 되는 곳

실제로 적용해 본 것만 강의한다면, 이 칸이 실습의 본체다. 4-1~4-3은 안 채우면 그냥 설계도이지 강의 자료가 아니다.

# {주제} 실행 기록

| 회차 | 날짜 | 입력 | 결과 | 정지 이유 | 비용 |
|---|---|---|---|---|---|
| 1 |  |  |  |  |  |
| 2 |  |  |  |  |  |
| 3 |  |  |  |  |  |

## 실제로 부딪힌 것
- 예상과 달랐던 것:
- 종료 조건이 안 먹힌 순간:
- 비용이 튄 지점:
- 평가자가 잡아낸 것 중 나도 못 본 것:

## 한 줄 결론
> {주제} 에서 루프는 ______________ 였다.

도구 실습 — 개발자 트랙 개발자

Codex 앱을 쓴다면 이름만 다르고 모양은 같다: Automations 탭 / 스레드별 워크트리 / .codex/agents/*.toml / Connectors.

도구 실습 — 비개발자 트랙 비개발자

코드 없이 루프의 모양을 만져보는 쪽. 셋 중 하나만 골라도 충분하다.

루프가 좋아질수록 더 날카로워지는 문제 3가지

루프는 일을 바꾸지, 당신을 지우지 않는다. 아래 셋은 루프가 매끄러울수록 쉬워지는 게 아니라 심해진다.

비용 함정

• 토큰 부자와 토큰 빈자의 사용 패턴은 완전히 다르다. 남이 자랑하는 루프를 그대로 따라 하기 전에 내 예산부터 본다.
• 서브에이전트는 각자 모델을 돌린다 → 에이전트 수 × 토큰. 두 번째 의견이 값어치 있는 곳에만 붙인다.
• 종료 조건에 비용 상한을 반드시 넣는다. 시간·횟수만으로는 안 막힌다.
• 하네스 사례 수치: Solo $9(20분, 작동 불가) vs Harness $200(6시간, 동작). 비쌀 값어치가 있는지는 만들 물건에 따라 매번 다시 판단한다.

루프 설계 체크리스트

• 종료 조건이 기계 판정 가능한가? ("좋아 보이면"은 조건이 아니다)
• 실패 종료와 에스컬레이션이 따로 있는가? (성공 조건만 있으면 무한 루프)
• 비용 상한이 있는가? (토큰·금액·시간 중 최소 하나)
• 생성자와 평가자가 분리돼 있는가? (같은 대화창 = 자기 채점)
• 평가자가 회의적으로 튜닝됐는가? ("문제없음" 답변을 금지했는가)
• 완료의 정의를 시작 전에 합의했는가? (스프린트 계약)
• 상태를 디스크에 적는가? (컨텍스트에만 있으면 다음 실행 때 증발)
• 병렬 실행이 워크트리로 격리됐는가? (아니면 파일 충돌)
• 기획자가 기술 세부에 너무 일찍 매몰되지 않았는가? (연쇄 오류)
• 모델이 좋아져서 이제 필요 없어진 구조물은 없는가? (스캐폴딩 철거)
• 루프가 만든 결과물을 내가 읽었는가? (이해 부채)

마무리 한 줄

루프 설계가 프롬프트 엔지니어링보다 쉬워진 게 아니다. 지렛대의 받침점이 옮겨간 것이다.

0교시 · AI 기초 30분 (조건부)

수강생이 토큰·컨텍스트 윈도우·할루시네이션을 모르면 본 강의는 성립하지 않는다. 사전 확인 질문 4개를 던져 보고, 막히면 아래를 먼저 돌린다. → 「AI 기초」 탭

90분 진행표 (강사용)

대상: 기초 용어가 되는 초보자(0교시 통과자). 개발·비개발 혼합 가능. 실습 4-2와 4-3은 빼지 말 것.

대상별 조정

기존 커리큘럼과의 접속

이 강좌는 사내 세미나 자료의 Part 7·8을 초보자용으로 앞당겨 묶은 것이다. 심화로 넘길 때 연결점:

• Part 2. 프롬프트 엔지니어링 → 4층 구조 맨 아래층. 여전히 유효하되 루프 안에서 자동 생성된다는 점만 갱신.
• Part 3. 컨텍스트 엔지니어링 → 키워드 ⑤ 동적 컨텍스트로 이어짐. 리셋 vs 압축 전략은 여기서 심화.
• Part 4. Skills / Part 5. SubAgent → 루프 6조각 중 ③ ⑤. 이 강좌는 왜 필요한지만, 심화는 어떻게 쓰는지.
• Part 6. 오케스트레이션 → 키워드 ③ 에이전틱 워크플로우의 확장.
• Part 7. 하네스 엔지니어링 → 키워드 ②의 심화. 평가자 보정, Playwright 기반 동적 테스트, 3-에이전트 아키텍처.
• Part 8. Loop 엔지니어링 → 키워드 ①의 원문. 5 primitives 표의 출처.