AI의 원리에서 Hermes까지, 다음 단어를 맞히는 확률 기계가 어떻게 팀처럼 일하게 되는가
2026년 8월 28일 | SKYWARE ACADEMY
2026년 8월 28일 사내 AI 강의를 열었습니다. 개발자뿐 아니라 기획 · 운영 구성원도 함께 들을 수 있도록 LLM이 답을 만드는 원리에서 출발해, API로 호출하는 법, 일을 잘 시키는 법, 그리고 여러 에이전트가 역할을 나눠 일하는 멀티 에이전트 구성 ‘Hermes’까지 네 단계로 정리했습니다. 23쪽 강의 자료를 간추립니다.
01. AI의 원리 · 다음 단어를 확률로 고른다
LLM은 문장 전체를 읽고 다음에 올 단어 후보마다 확률을 매긴 뒤 하나를 고르는 일을 반복합니다. “오늘 날씨가” 뒤에 ‘좋네요’ 41%, ‘흐리네요’ 33%, ‘어때’ 26%처럼 후보가 나오고, 하나를 고르면 그 단어까지 포함해 다시 처음부터 계산합니다. 문맥이 길어질수록 확률이 재조정되는 것이 핵심입니다.
전체 입력 읽기다음 단어 후보 나열문맥 반영해 확률 재조정단어 하나 결정처음부터 반복
- temperature · top-k후보 가운데 상위 k개만 남기고(top-k), 0~1 값으로 무작위성을 조절(temperature)한다. 낮추면 늘 비슷한 답, 높이면 다양하지만 흔들리는 답.
- 학습 방법정답이 들어 있는 문장에서 다음 토큰을 가리고 → 확률을 예측하게 하고 → 정답과의 오차가 줄도록 파라미터를 조정한다. 이 네 단계를 수없이 반복한 것이 모델이다.
- 답변 품질을 올리는 법파라미터 수가 큰 모델(7B → 70B)을 쓰거나, 최종 답 전에 내부 추론 토큰을 생성(reasoning)하게 한다. 대신 시간과 비용이 함께 늘어난다.
- 한계검증 장치 없이 확률로 움직이므로 할루시네이션이 생기고, 한 번에 다룰 수 있는 문맥(context window)에 한도가 있어 길어지면 연산량이 급증한다.
02. LLM API 사용법 · JSON 한 덩어리로 부른다
API 호출은 결국 JSON 요청 하나입니다. 어떤 모델을 부를지, 지금까지의 대화를 어떻게 넘길지, 답의 무작위성과 길이를 어디까지 허용할지, 답을 어떤 구조로 받을지를 파라미터로 적습니다. 강의에서 다룬 여덟 가지를 쓰임새별로 묶었습니다.
주요 요청 파라미터
| 구분 | 파라미터 | 하는 일 |
|---|---|---|
| 무엇을 · 무슨 대화로 | model · messages | 호출할 모델 이름과, user · assistant 역할이 번갈아 쌓인 대화 내용 |
| 얼마나 자유롭게 | temperature · top_p · top_k | 후보 선택의 무작위성, 누적 확률로 후보 제한, 상위 후보 개수 제한 |
| 얼마나 깊고 길게 | reasoning_effort · max_output_tokens | 내부 추론 수준(low · medium · high)과 출력 토큰 상한 |
| 어떤 모양으로 | response_format · json_schema | 답을 정해진 JSON 구조로 강제, 프로그램이 바로 읽을 수 있게 |
실무 포인트는 두 가지였습니다. 토큰이 곧 비용이므로 messages에 쌓이는 대화를 무한정 넘기지 말 것, 그리고 시스템에 붙일 때는 json_schema로 응답 구조를 고정해 파싱 오류를 없앨 것.
03. LLM 활용법 · 질문을 되묻게 하고, 명령어로 흐름을 잡는다
- 역질문법“~를 하기 위해 필수적인 핵심 질문을 해 주세요.” 바로 답을 받지 않고, 모델이 먼저 빠진 조건을 묻게 한다. 요구사항이 흐릿할 때 가장 효과가 크다.
- / 명령어/goal로 최종 목표를 제시하고, /plan으로 사전 계획을 세워 검토한 뒤 실행한다. 목표 → 계획 → 실행을 분리하면 중간에 엇나가는 일이 줄어든다.
- 프롬프트 엔지니어링 → 루프 엔지니어링한 번의 좋은 프롬프트보다 목표(Goal) → 행동(Act) → 관찰(Observe) → 조정(Adjust)을 돌리는 루프가 결과를 더 안정적으로 만든다.
- 하네스 엔지니어링명확한 지침과 규칙으로 AI를 통제하는 틀을 만든다. 무엇을 할 수 있고 없는지, 어떤 순서로 확인하는지를 미리 정해 두는 일이다.
04. Hermes · 한 명의 에이전트에서 역할을 나눈 팀으로
강의의 마지막은 하나의 에이전트가 모든 일을 하는 구조와, 총괄(오케스트레이터)이 요청을 읽고 전문 역할에 일을 나눠 주는 구조의 비교였습니다. 후자를 강의에서는 Hermes라고 불렀습니다.
Single Agent vs Hermes
| 구분 | Single Agent | Hermes |
|---|---|---|
| 역할 구조 | 한 에이전트가 전부 수행 | 총괄과 전문 역할을 분리 |
| routing | 다음 행동만 선택 | 요청에 맞는 역할과 순서를 선택 |
| 실행 | 한 세션에서 주로 순차 처리 | 독립 세션에서 병렬 · 순차 처리 |
| 검토 | 자체 검토 | 독립 reviewer가 검토 |
Hermes 구조, 오케스트레이터 아래 세 역할
- 1Researcher출처와 사실을 모은다. 추측 대신 근거를 가져오는 역할
- 2Implementer코드와 테스트를 만든다. 실제로 손을 움직이는 역할
- 3Reviewer결함과 위험을 찾는다. 만든 사람과 분리된 독립 검토
역할 분리+병렬 세션+독립 검토=품질이 뚜렷하게 올라간다
장점은 품질 향상, 독립 reviewer, 자동 세션 관리, 자가 학습, 병렬 작업 다섯 가지였고, 단점은 하나, 토큰 사용량이 늘어난다는 점입니다. 비용을 감수할 만큼 중요한 작업에 쓰는 것이 결론이었습니다. (참고: Anthropic, How we built our multi-agent research system, 2025)
이 강의는 스카이웨어가 사내에서 AI를 ‘써 보는 단계’에서 ‘일하는 방식에 넣는 단계’로 옮겨 가기 위한 첫 시간이었습니다. 다음 시간에는 실제 프로젝트에 하네스를 붙여 본 사례를 다룹니다.
