출발점: 성공한 팀들은 단순했다

Anthropic은 지난 1년간 여러 산업에서 LLM 에이전트를 만드는 수십 개 팀과 협업했다. 그 결과 가장 성공한 팀들은 복잡한 프레임워크나 에이전트 전용 라이브러리를 쓰지 않았다고 한다. 대신 단순하고 조합 가능한 패턴(simple, composable patterns)으로 시스템을 만들었다.

처음엔 이 "단순함"을 각 에이전트나 도구를 작게 만들라는 SRP 같은 이야기로 읽었다. 하지만 글을 따라가 보면 SRP보다는 KISS나 YAGNI에 가깝다. 처음부터 복잡하게 만들지 말고, 효과가 증명될 때만 복잡도를 더하라는 것이다.

먼저 용어부터: agentic system, workflow, agent

"에이전트"는 사람마다 다르게 쓰는 말이다. 오랜 시간 혼자 동작하며 여러 도구로 복잡한 작업을 해내는 완전 자율 시스템을 떠올리는 사람도 있고, 정해진 절차를 따르는 구현을 에이전트라고 부르는 사람도 있다.

Anthropic은 이 모두를 agentic system이라는 하나의 범주로 묶고, 그 안에서 둘을 구조적으로 구분한다.

• Workflow: LLM과 도구가 미리 정해진 코드 경로를 따라 움직이는 시스템
• Agent: LLM이 작업 과정과 도구 사용을 스스로 결정하고, 작업을 어떻게 끝낼지에 대한 통제권을 가진 시스템

여기서 헷갈리기 쉬운 점이 있다. LLM을 여러 번 호출한다고 에이전트가 되는 것도 아니고, 도구를 쓴다고 에이전트가 되는 것도 아니다. workflow도 LLM 호출을 여러 번 조합하고 도구도 쓴다. 둘을 가르는 기준은 흐름의 통제권을 누가 갖느냐 하나다.

그리고 LLM을 쓰는 앱이 모두 agentic system인 것도 아니다. 포함 관계로 그리면 이렇다.

LLM 애플리케이션 ⊃ agentic system ⊃ { workflow, agent }

에이전트 설계의 세 가지 단순함

1. 무엇을 만들까: 복잡도의 사다리

원문은 가장 단순한 해법부터 찾고, 필요할 때만 복잡도를 높이라고 권한다. 그리고 그게 agentic system을 아예 만들지 않는 것일 수도 있다고 말한다. 많은 애플리케이션은 검색(retrieval)과 프롬프트 속 예시(in-context examples)로 LLM 단일 호출을 다듬는 것만으로 충분하다는 것이다.

이걸 사다리로 그려 보면 이렇다.

LLM 단일 호출(+ 검색, 예시) → workflow → agent

중요한 건 이 "단순하게"가 agent에만 적용되는 말이 아니라는 점이다. agentic system에는 workflow도 포함된다. workflow조차 없이 단일 호출로 해결된다면 그게 최선이다.

같은 기능도 구조에 따라 사다리의 어느 칸에든 놓일 수 있다. 사내 문서를 검색해서 답하는 RAG(Retrieval-Augmented Generation, LLM이 답하기 전에 관련 문서를 찾아 프롬프트에 넣어 주는 방식)를 예로 들면 이렇다.

검색 자체는 LLM 호출이 아니라 코드가 하는 전처리다. 그래서 "RAG를 쓰니까 workflow다"라고 말할 수는 없다. RAG는 패턴이라기보다 사다리의 어느 칸에서든 쓸 수 있는 부품에 가깝다.

2. 언제 한 칸 올라갈까: 비용과 성능의 거래

원문은 agentic system이 보통 지연 시간과 비용을 내주고 더 나은 성능을 얻는다고 말한다. 처음 읽을 때는 "비용이 드니까 조심하라"는 말로 읽었다. 다시 읽어 보니 원문이 따지라는 건 비용 자체가 아니라 이 거래(tradeoff)다. 시간과 비용을 더 쓰는 만큼 성능이 좋아지는지를 저울에 올려 봐야 한다.

그리고 그 판단은 감이 아니라 측정으로 한다. 원문 결론부도 복잡도는 결과가 개선된다는 게 증명될 때만 더하라고 말한다.

1. 가장 단순한 구조로 만든다.
2. 평가해서 성능이 부족한지 확인한다.
3. 부족하면 한 칸 올린다. 흐름을 미리 정할 수 있으면 workflow, 정할 수 없으면 agent.
4. 올린 뒤에도 늘어난 지연 시간과 비용만큼 좋아졌는지 다시 확인한다.

3. 어떻게 만들까: 프레임워크와 거리 두기

agentic system을 쉽게 만들게 해 주는 프레임워크는 많다. 원문은 Claude Agent SDK, AWS의 Strands Agents SDK 같은 SDK와 Rivet, Vellum 같은 GUI 도구를 예로 든다. 이런 도구는 LLM 호출, 도구 정의와 파싱, 호출 연결 같은 저수준 작업을 대신해 줘서 시작을 쉽게 만든다.

문제는 두 가지다. 첫째, 추상화 계층이 실제로 오가는 프롬프트와 응답을 가려서 디버깅을 어렵게 만든다. 둘째, 단순한 구성으로 충분한데도 복잡도를 더하고 싶게 만든다. 첫 번째 단순함인 사다리를 거스르게 되는 셈이다.

그래서 원문은 LLM API를 직접 쓰는 것부터 시작하라고 권한다. 많은 패턴은 코드 몇 줄이면 된다. 프레임워크를 쓴다면 그 아래에서 돌아가는 코드를 반드시 이해해야 한다. 내부 동작을 잘못 가정하는 것이 흔한 실수의 원인이라고 한다.

앱 개발자에게는 익숙한 이야기다. ORM이 실제로 실행되는 SQL을 가려서 N+1 문제를 늦게 발견하는 것과 같은 구조다. 추상화는 편하지만, 그 아래를 모르면 문제가 생겼을 때 어디를 봐야 할지 모른다.

내 프로젝트에 대어 보면

이 표를 동아리 운영 도우미에 대어 보니 내가 만들고 있던 게 무엇인지 선명해졌다.

처음에는 에이전트로 설계하려고 했다. 그런데 단순한 LLM 앱(단일 호출 + 검색)으로는 부족해 보였다. 질문이 FAQ로 바로 답할 수 있는 건지, 운영 가이드나 1:1 가이드, 개인정보 처리방침 중 어느 문서를 봐야 하는 건지 먼저 가려야 했기 때문이다. 그래서 지금은 이런 흐름으로 구현하고 있다.

START → check_faq ─(FAQ에 있음)──────────────────────────→ generate_answer → END
                  └(없음)→ get_document_name → retrieve_document ↗

글을 읽고 나서 보니 이건 에이전트가 아니라 workflow다. 갈림길에서 어느 쪽으로 갈지는 LLM이 판단하지만, 갈 수 있는 길 자체는 내가 코드로 미리 그려 뒀다. 그리고 이 구조가 지금 문제에는 더 잘 맞는다.

• 비용과 지연 시간이 예측된다. FAQ로 답하면 LLM 호출 2번, 아니면 3번이다. 에이전트였다면 질문마다 호출 횟수가 달라졌을 것이다.
• 값싼 판단은 값싼 모델에 맡긴다. 문서 분류처럼 단순한 판단은 작은 모델로 처리한다. 무거운 모델은 최종 답변에만 쓴다.
• 실패해도 흐름이 무너지지 않는다. 분류 결과가 이상하면 기본 문서로 보낸다. 에이전트가 엉뚱한 판단을 이어 가며 오류를 쌓을 여지가 없다.

참여자와 운영자를 구분하는 기능도 고민하고 있는데, 이것도 같은 관점으로 보게 됐다. 누가 운영자인지는 LLM이 대화를 보고 추측할 일이 아니라, 코드가 권한 정보로 확인하고 분기할 일이다. 권한처럼 틀리면 안 되는 판단일수록 흐름의 통제권을 코드에 두는 workflow가 맞다.

다만 경계가 생각보다 미묘하다는 점도 짚고 싶다. check_faq에서는 LLM이 Yes/No를 판단하고, 그 결과에 따라 흐름이 갈린다. 그러면 LLM이 흐름을 정하는 것 아닌가 싶었다. 정리해 보면 차이는 이렇다. workflow의 LLM은 코드가 준비한 갈림길 중 하나를 고르고, agent의 LLM은 다음에 무엇을 할지 자체를 만들어 낸다. 선택지가 코드로 닫혀 있느냐 열려 있느냐의 차이다.

그렇다고 언젠가 에이전트로 가지 않겠다는 건 아니다. 여러 문서를 오가며 확인해야 하는 질문이 많아져서 정해진 흐름으로 답하지 못하는 경우가 늘어난다면, 그때가 한 칸 올라갈 때다. 그 판단도 감이 아니라 실제 질문으로 평가해서 내리려고 한다.

마치며

내가 이해한 이 글의 한 줄 요약은 이렇다.

복잡도는 기본값이 아니라, 효과가 증명됐을 때 지불하는 비용이다.

에이전트는 가장 강력한 선택지이지만, 가장 먼저 꺼낼 선택지는 아니다.

출처: Anthropic - Building effective agents

LLM만으로는 왜 부족할까?

출발점은 LLM의 한계다. LLM은 학습한 데이터를 기반으로 응답을 만든다. 학습이 끝난 시점에 지식이 멈춘다는 뜻이다. 오늘 날씨, 회사 내부 문서, 내가 지난번에 했던 대화처럼 학습 데이터에 없는 정보는 알 수 없다.

또 LLM은 기본적으로 질문 하나에 답 하나를 내놓는 구조다. "내년에 그리스에서 서핑하기 가장 좋은 주를 알려줘" 같은 요청은 여러 단계의 조사와 판단이 필요한데, 한 번의 응답으로는 그럴듯한 추측밖에 할 수 없다.

AI 에이전트는 이 빈틈을 메우기 위해 등장했다. IBM은 에이전트를 "가용 도구를 사용해서 워크플로를 설계하고 작업을 자동으로 수행하는 시스템"이라고 정의한다. 핵심에는 여전히 LLM이 있다. 달라지는 건 LLM 주변에 무엇을 붙였느냐다.

챗봇과 에이전트를 가르는 세 가지 기준

1. 도구: 모르는 걸 스스로 찾아오는가

비에이전틱 챗봇은 내부 지식만으로 답한다. 모르면 모르는 대로, 혹은 틀린 채로 답한다.

에이전트는 정보가 부족하다고 판단하면 외부 데이터베이스, 웹 검색, API, 심지어 다른 에이전트까지 호출해서 정보 격차를 메운다. 서핑 예시라면 지난 몇 년간의 그리스 일기 예보 DB를 조회하고, 서핑 전문 에이전트에게 좋은 서핑 조건이 무엇인지 물어본다.

2. 메모리: 지난 경험을 기억하는가

챗봇은 메모리가 없어서 응답이 만족스럽지 않아도 실수로부터 배우지 못한다. 매번 처음 만나는 사람처럼 대화한다.

에이전트는 과거 상호작용과 사용자 피드백을 저장한다. 그래서 시간이 지날수록 사용자 선호에 맞춰지고, 한 번 해결한 문제의 해법을 다음에 다시 꺼내 쓸 수 있다.

3. 계획: 다음 단계를 스스로 정하는가

챗봇은 사용자가 계속 입력을 줘야 움직인다. 다음에 뭘 할지는 사용자가 정한다.

에이전트는 복잡한 목표를 하위 작업으로 쪼개고, 실행하면서 얻은 정보로 계획을 다시 평가하고 수정한다. 서핑 예시에서 날씨 데이터만으로 결론을 내리지 못하자 "서핑 조건 알아보기"라는 하위 작업을 스스로 만든 것이 바로 이 부분이다.

내 개발 경험에 대어 보면

이 표를 내 개발 경험에 대어 보면 차이가 꽤 선명하다.

Claude Code나 Codex가 나오기 전에는 ChatGPT에 코드를 붙여넣고 기능 구현이나 코드 리뷰를 요청했다. 문제는 챗봇이 내 프로젝트를 전혀 모른다는 점이었다. 프로젝트 상황을 매번 직접 설명해 줘야 했고, 그래도 프로젝트에 맞지 않는 일반적인 답이 돌아와서 채팅을 몇 번씩 주고받으며 다듬어야 했다. 비슷한 작업을 할 때마다 이 과정이 반복됐다. 돌아보면 도구, 메모리, 계획의 역할을 전부 내가 대신하고 있었던 셈이다.

지금은 Claude Code와 Codex로 개발한다. 한번은 코드 리뷰와 검증을 요청했더니 에이전트가 작업을 나눠 서브 에이전트들에게 맡겼다. 하나는 코드와 테스트 코드를 기준으로 검증하고, 다른 하나는 ADB로 실제 디바이스에서 기능을 직접 써 보며 테스트했다. 흥미로운 건 결과였다. 실물 테스트는 성공했는데, 리뷰 에이전트가 테스트 코드의 잘못된 부분을 지적했다. 기능은 제대로 동작하지만 테스트가 그걸 제대로 검증하지 못하고 있었던 것이다. 덕분에 검증 체계 자체를 더 단단하게 만들 수 있었다.

이건 IBM의 서핑 예시와 같은 구조다. 목표를 하위 작업으로 쪼개고(계획), 각 작업에 맞는 수단을 골라 다른 에이전트에게 맡기고(도구), 결과를 종합해 판단했다. 챗봇 시절 내가 직접 하던 일을 에이전트가 가져간 것이다.

물론 전부 맡겨 둘 수는 없었다. 테스트 코드를 검증하던 에이전트가 테스트를 통과시키려고 프로덕션 코드까지 고치려 한 적이 있었는데, 그건 이번 작업 범위 밖이라 내가 막았다. 에이전트가 스스로 계획을 세우더라도 어디까지 손대도 되는지는 사람이 정해 줘야 한다. IBM이 말하는 HITL(Human-in-the-Loop)이 왜 필요한지 체감한 순간이었다.

다만 경계가 생각보다 흐릿하다는 점도 짚고 싶다. 지금의 ChatGPT나 Claude 웹도 웹 검색, 메모리 같은 기능이 붙으면서 예전보다 에이전트 쪽으로 많이 다가왔다. 그래서 "ChatGPT는 챗봇, Claude Code는 에이전트"처럼 제품 이름으로 나누기보다는, 세 가지 능력을 얼마나 갖췄느냐의 정도 문제로 보는 게 맞다고 생각한다. IBM이 챗봇은 하나의 "양식"이고 에이전시는 "기술 프레임워크"라고 구분한 것도 같은 맥락이라고 이해했다.

그렇다고 모든 걸 에이전트로 만들 필요는 없다. IBM도 간단한 작업이라면 계획 단계 없이 응답을 반복해서 다듬는 것만으로 충분하다고 말한다.

마치며

내가 이해한 한 줄 정의는 이렇다.

AI 에이전트는 LLM에 도구, 메모리, 계획을 더해, 사용자가 일일이 지시하지 않아도 목표까지 스스로 나아가는 시스템이다.

출처: IBM - AI 에이전트란 무엇인가?

Web Server란?

Web Server는 HTTP 요청에 응답하며, 정적 파일 제공이나 다른 서버로 요청 전달 등을 담당하는 서버 소프트웨어다. 대표적으로 Nginx, Apache HTTP Server가 있다.

정적 파일은 서버에 저장된 내용을 그대로 전달하는 HTML, CSS, JavaScript, 이미지 등을 말한다.

브라우저 → /index.html 요청
Web Server → 저장된 HTML 파일 응답

브라우저는 전달받은 HTML·CSS로 화면을 구성하고 JavaScript를 실행한다. 따라서 정적 파일을 제공한다고 해서 화면이 고정되거나 코드 실행이 불가능한 것은 아니다. 이때 코드는 서버가 아닌 브라우저에서 실행된다.

Web Server는 정적 파일 제공 외에도 다음 역할을 맡을 수 있다.

• 리버스 프록시: 요청을 WAS로 전달하고 응답을 클라이언트에 전달
• HTTPS 처리: TLS 연결과 암호화·복호화 처리
• 부하 분산: 요청을 여러 애플리케이션 서버로 분산

WAS란?

WAS는 서버 측 애플리케이션 코드를 실행하여 요청을 처리하고 응답을 생성하는 환경이다.

로그인 검증, 상품 구매, DB 조회처럼 서버에서 수행해야 하는 작업을 담당한다.

클라이언트 → 주문 조회 요청
WAS → 사용자 권한 확인 → DB 조회 → HTML 또는 JSON 응답

이처럼 요청과 데이터 상태에 따라 응답을 생성하는 것을 동적 처리라고 한다. 동적이라는 말은 화면이 움직인다는 뜻은 아니다.

Java 환경에서 배우는 Servlet과 JSP는 서버에서 요청을 처리하고 응답을 만드는 기술이다. Tomcat은 이를 실행하는 서블릿 컨테이너이며, 현업에서는 흔히 WAS라고 부른다.

다른 생태계에서는 Node.js나 Python으로 비슷한 역할을 구현하면서 '애플리케이션 서버' 또는 'API 서버'라고 부르기도 한다.

Web Server vs WAS 비교

DNS(Domain Name System)는 도메인 이름에 대응하는 IP 주소를 찾아주는 시스템이다. 사용자는 숫자로 된 IP 주소를 외우지 않고도, 기억하기 쉬운 도메인 이름으로 서비스에 접속할 수 있다.

전화번호부로 이해하기

우리는 다른 사람의 전화번호를 모두 외우는 대신, 연락처에 이름과 전화번호를 함께 저장한다. 전화를 걸 때는 이름으로 검색하지만, 실제 연결에는 전화번호가 사용된다.

DNS도 이와 비슷하다. 도메인 이름은 연락처 이름, IP 주소는 전화번호에 해당한다.

실제 동작 흐름

브라우저에 도메인 이름을 입력하면 다음과 같은 과정을 거친다.

1. DNS를 통해 도메인에 대응하는 IP 주소를 조회한다.
2. 조회한 IP 주소로 웹 서버에 접속한다.
3. 웹 서버에 웹 페이지를 요청하고 응답을 받는다. DNS로 조회한 도메인과 IP 주소의 연결 정보가 캐시에 남아 있으면, DNS 서버에 다시 조회하지 않고 해당 정보를 재사용할 수 있다.

HTTP란?

HTTP(Hypertext Transfer Protocol)는 클라이언트와 서버가 요청과 응답을 주고받을 때 사용하는 통신 규칙(protocol)이다. 웹 페이지, 이미지, API 데이터 등을 주고받는 데 사용한다.

URL과 HTTP의 관계

http://example.com/hello

• http: HTTP로 통신하겠다는 스킴
• example.com: 접속할 서버의 도메인 이름
• /hello: 요청할 대상의 경로 URL이 어디에 어떤 방식으로 요청할지 나타낸다면, HTTP는 요청과 응답을 어떤 형식과 의미로 주고받을지 정한다.

HTTP 통신 규칙

HTTP는 메서드, 헤더, 본문 등으로 요청을 구성하고, 상태 코드, 헤더, 본문 등으로 응답을 구성하는 규칙이다. 또한 GET은 조회, 200은 성공처럼 공통으로 해석할 의미를 정의한다.

예를 들어 HTTP/1.1 요청은 이런 모습을 가질 수 있다.

GET /hello?name=kim HTTP/1.1
Host: example.com
Accept: application/json

• GET-메서드: 해당 대상의 데이터를 조회하겠다는 의미
• /hello-Path: 요청할 대상의 경로
• name=kim-Query Parameter: URL에 포함된 추가 정보
• Host, Accept-Header: 대상 호스트, 받고 싶은 데이터 형식 등의 부가 정보
• Body: 전달할 데이터가 들어가는 부분. (위 요청에는 없다)

이에 대한 서버 응답은 다음과 같을 수 있다.

HTTP/1.1 200 OK
Content-Type: application/json

{
    "message": "Hello, Kim"
}

• 200 OK-상태 코드: 요청 성공을 나타내며, 200은 상태 코드
• Content-Type-Header: 응답 데이터가 Json이라는 의미
• Body: 실제 응답 데이터

다만 /hello가 어떤 기능인지, name이 무엇을 뜻하는지, JSON에 어떤 필드를 넣을지는 개발자가 정한다. HTTP는 이를 주고받는 공통 규칙을 제공하는 거다.

실제 동작 흐름

1. 브라우저가 DNS를 통해 도메인에 대응하는 IP 주소를 찾는다.
2. 서버에 연결하고 HTTP 요청을 보낸다.
3. 서버는 요청을 처리하고 HTTP 응답을 보낸다. 예를 들어 브라우저는 GET이라는 요청 메서드로 페이지를 요청하고, 서버는 200 OK라는 상태 코드와 페이지 내용을 응답할 수 있다.

HTTP vs HTTPS

HTTPS는 HTTP에 TLS(Transport Layer Security)라는 보안 기술을 적용한 통신 방식이다. HTTP 요청과 응답을 주고받으면서, TLS로 암호화·변조 탐지·서버 인증을 제공한다.

1. 암호화 - 통신 내용을 다른 사람이 읽지 못하게 한다

클라이언트와 서버는 통신을 시작할 때 TLS 핸드세이크라는 준비 과정을 거친다. 이 과정에서 암호화 방식을 정하고, 키 교환을 통해 통신에 사용할 비밀 키를 만들어낸다. 비밀 키 자체를 그대로 전송하는 것은 아니다.

이후 HTTP 데이터를 해당 키로 암호화해서 보내고, 받는 쪽에서 복호화한다. 실제 데이터 암호화에는 AES 같은 대칭 키 암호화 방식을 사용한다.

HTTP 데이터 -> 암호화 -> 네트워크로 전송 -> 복호화 -> HTTP 데이터

헤더와 본문뿐 아니라 경로와 쿼리 파라미터도 암호화 대상이다. 다만 접속 대상 IP 주소 같은 네트워크 정보까지 모두 숨겨지는 것은 아니다.

2. 변조 탐지 - 중간에서 데이터가 바뀌었는지 확인한다

TLS는 데이터를 암호화하면서, 비밀 키와 데이터를 이용한 인증 태그라는 검증값도 생성한다.

받는 쪽은 이 검증값을 확인한다. 중간에서 데이터가 바뀌면 검증에 실패하고, 해당 데이터를 받아들이지 않고 연결을 종료한다. 공격자는 비밀 키를 모르기 때문에 바꾼 데이터에 맞는 검증값을 만들기 어렵다.

3. 서버 인증 - 접속한 서버가 요청한 도메인의 서버인지 확인한다

일반적인 HTTPS 연결에서 서버는 도메인 이름과 공개 키 등이 담긴 인증서를 제시한다. 브라우저는 다음을 확인한다.

• 인증서가 접속하려는 도메인에 유효한가?
• 인증서의 유효기간이 지나니 않았는가?
• 신뢰하는 인증기관(CA)으로 이어지는 서명 체인이 유효한가?

또한 서버는 인증서의 공개 키에 대응하는 개인 키를 보유했다는 사실을 암호학적으로 증명한다. 따라서 인증서 파일만 복사해서 제시하는 것으로는 서버를 사칭할 수 없다.

여기서 확인하는 것은 해당 도메인의 서버라는 사실이지, 그 사이트의 콘텐츠나 운영자가 무조건 믿을 만하나다는 뜻은 아니다.

4. HTTP만 사용할 때와의 차이

여러분의 마지막 면접은 언제였나요?

그 떨리는 순간을 떠올려보세요. 문 앞에서 손에 땀을 쥐며 서 있던 그 순간, "이런 질문이 나오면 어떻게 대답하지?"라며 머릿속이 하애졌던 그 경험 말이에요. 만약 그때 미리 연습할 상대가 있었다면 어땠을까요? 그것도 여러분이 지원하는 회사의 면접관처럼 행동하는 상대가 말이죠.

이선 몰릭 《듀얼 브레인》 4장 '사람으로서의 AI'를 읽다가 무릎을 쳤습니다. AI를 단순한 검색 도구가 아니라 ' 사람처럼'활용할 수 있다는 통찰이 마치 새로운 세계의 문을 열어준 것 같았거든요.

《듀얼 브레인》이 보여준 AI의 숨겨진 얼굴

이선 몰릭은 와튼 스클 교수님이자 'AI 분야 최고 영향력 인물'입니다. 교수님 《듀얼 브레인》 에서 제시하는 핵심 아이디어는 간단하면서도 혁신적입니다. AI를 기술로만 보지 말고, 때로는 '사람처럼'대해보라는 것이죠.

기술적으로는 말이 안 될 수도 있지만,실용적으로는 게임 체인저가 될 수 있다는 교수님의 말이 계속 머릿속을 맴돌았습니다.

세 가지 핵심 깨달음: AI는 이미 사람보다 사람 같다

1. 페르소나의 마법 - AI는 정말로 역할을 '연기'한다

책에서 가장 인상깊었던 부분은 AI가 특정 페르소나를 부여받으면 실제로 그 역할에 맞게 행동한다는 사실이었습니다. 단순히 답변 스타일만 바뀌는 게 아니라, 소득 수준, 구매 행동, 심지어 가치관까지 반영해서 대답한다는 거에요.

이를 좀 더 와닿게 이야기하면, AI는 마치 천재 배우와 같다는 겁니다. 어떤 캐릭터든 완벽하게 소화해내는 메서드 배우인거죠. 몰릭 교수님은 실제로 창업 수업 학생들에게 AI와 고객 인터뷰 연습을 시켰다고 합니다. 실제 고객을 만나기 전 리허설용으로 말이에요.

2. 도덕성의 거울 - AI는 우리의 편견을 그대로 투영한다.

더욱 흥미로운 건 AI가 인간과 비슷한 선입견과 도덕적 판단을 내린다는 점이었습니다. MIT의 존 호튼 교수님는 AI에게 '독재자 게임'을 시켰을 때, AI는 인간과 놀랍도록 유사한 패턴을 보였다고 했습니다.

AI 자체에는 도덕성이 없지만, 인간의 도덕적 지시를 해석하고 따를 수 있다는 것. 특별한 지시가 없으면 기본적으로 '효율성'을 추구한다는 것. 이는 마치 Ai가 우리 사회의 도덕적 DNA를 고스란히 흡수한 디지털 거울 같다는 생각이 들었습니다.

3. 무한 변신 가능성 - 개발자와 사용자가 함께 만드는 캐릭터

가장 중요한 통찰은 AI가 다양한 페르소나를 쉽게 취할 수 있으며, 이 때 개발자와 상요자 모두의 역할이 중요하다는 점입니다. 즉, 우리가 어떠헥 요청하느냐에 따라 AI는 완전히 다른 존재가 될 수 있다는 거죠.

실전 적용 아이디어: AI 면접관

이런 내용들을 읽고 나서 떠오른 아이디어가 있었습니다. 이직 또는 구직자들이 면접을 준비할 때 AI를 '면접관'으로 활용하는 것이었어요.

상상해보세요. 여러분이 지원하는 회사의 문화와 인재상을 학습한 AI 면접관들과 연습할 수 있다면? 마치 다양한 스타일의 실제 면접관들과 미리 만나보는 것처럼 말이에요.

면접관 페르소나 사용 예시

시나리오 1: 압박 면접관 만들기

이제부터 당신(AI)은 A회사의 시니어 개발자 면접관입니다.
당신은 15년 경력의 베테랑으로, 실력 없는 지원자를 걸러내는 것으로 유명합니다.
질문할 때는 날카롭고 직설적이며, "이 정도는 당연히 알아야 하는 거 아닌가요?"라는 식으로 압박을 줍니다.
지금부터 3년차 백엔드 개발자를 면접하는 상황입니다.
[지원서] 파일 기반으로 면접을 시작해주세요.

시나리오 2: 신입 채용 담당자 역할

당신은 스타트업 B회사의 HR 담당자입니다.
회사는 빠르게 성장하는 스타트업이고, 자율성과 책임감을 중시합니다.
신입 개발자를 뽑는 면접에서 기술보다는 성장 가능성과 열정을 더 중요하게 봅니다.
따뜻하지만 예리한 질문으로 지원자의 진정성을 파악하려고 합니다.
이제 막 컴퓨터공학과를 졸업한 학생을 면접하는 상황입니다.
[지원서] 파일 기반으로 질문 3개 순서대로 만들어주세요.

시나리오 3: 기술 중심 면접관 체험

당신은 대기업 C회사의 테크리드입니다.
10년 경력으로 시스템 아키텍쳐 설계 전문가이며, 기술적으로 깊이를 중시합니다.
면접에서는 구체적인 기술 구현 방법, 성능 최적화, 확장성을 주로 묻습니다.
"실제 프로젝트에서는 어떻게 해결했나요?"라는 식의 경험 기반 질문을 선호합니다.
5년차 Android 개발자와 기술 면접을 진행해주세요.

책을 덮고 든 생각

사실 이 책을 읽기 전에도 막연히 "AI에게 특정 역할을 맡겨보면 어떨까?라는 상상은 해봤었어요. 하지만 구체적으로 어떻게 적용해야 할지, 어떤 식으로 페르소나를 설정해야 하는지는 모르고 있었죠.

더 아쉬운 건 주변 사람들이 AI를 사용하는 모습을 봤을 때였어요. 대부분이 "AI야, 이것 좀 알려줘"라는 식으로 구글을 대체하는 검색 엔진 정도로만 활용하더라고요. 페르소나를 주입하거나 상황을 구체화하는 경우는 거의 보지 못했어요.

《듀얼 브레인》을 일고 나서야 비로소 실전 활용법을 배웠습니다. 몰릭 교수님의 구체적인 사례들 - 창업 수업에서 AI로 고객 인터뷰 연습을 시킨 이야기, 페르소나에 따라 AI가 완전히 다른 반응을 보인다는 연구 결과들 - 이 모든 것이 "아, 이렇게 사용하는 거구나!"라는 깨달음을 주었어요.

이제는 AI는 단순한 정보 제공자가 아니라 '연습 상대'가 될 수 있다는 걸 알게 되었습니다. 어려운 대화를 앞두고 있을 때, 새로운 역할을 맡게 되었을 때, 낯선 상황에 대비해야 할 때 AI를 이용해서 실패 부담 없이 무한정으로 연습할 수 있게 된 것 같습니다.

여러분의 AI에 페르소나를 주입해보는 건 어떨까요?

이 글을 읽고 있는 여러분도 혹시 면접을 앞두고 있나요? 면접이든, 프레젠테이션이든, 어려운 대화든 말이에요.

한번 시도해보세요. AI에게 구체적인 페르소나를 부여해서, 여러분이 마주할 상대방처럼 행동하도록 만들어보는 거에요. 그리고 미리 연습해보는 거죠.

기술적으로는 여전히 AI일 뿐이지만, 실용적으로 여러분의 가장 든든한 연습 파트너가 될 수 있을 거예요.

혹시 이미 비슷한 방식으로 AI를 활용해본 경험이 있다면 댓글로 공유해주세요. 아니면 상상의 나래를 펼쳐서 "이런 페르소나도 재밌을 것 같은데?"라는 아이디어가 있다면 그것도 좋고요.

개인적으로라도 페르소나를 적용해서 AI를 더 잘 활용해보시기를 바랍니다. 분명 지금까지와는 완전히 다른 경험을 하게 될 거예요!