요즘IT » AI » 피드

바이브 코딩의 진짜 시작은 이제부터다

본문은 요즘IT와 번역가 Yuna가 함께 아메드 하프디(Ahmed Hafdi)님의 글 <Vibe Coding Is Over. What Comes Next Is Much Harder.>를 번역한 글입니다. 필자는 모로코 라바트(Rabat)를 기반으로 활동하는 소프트웨어 엔지니어이자 데이터 사이언티스트로, 풀스택 개발과 머신러닝, AI 분야에 관심을 가지고 다양한 글을 발표해 왔습니다.

이 글은 안드레 카파시(Andrej Karpathy)가 명명한 바이브 코딩(vibe coding)이 불과 14개월 만에 한계를 드러낸 과정을 담고 있습니다. 수치와 실제 사례를 바탕으로 AI가 생성한 코드가 실제 프로덕션 환경에서 어떤 문제를 만들어냈는지 짚고, 이제 개발자들이 AI를 어떻게 다뤄야 하는지 구체적인 방향을 제시합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

"설명만 하면 배포"의 시대, 한동안 잘 굴러갔습니다. 무엇이 그 시대를 끝냈고, 지금 진짜 판은 어떻게 돌아가는지 정리했습니다.

꽤 그럴듯한 환상이었습니다. 아이디어를 설명하면 AI가 코드를 만들어줍니다. 프로젝트에 붙여 넣고 브라우저를 새로고침하면, 앱이 돌아갑니다. CS 학위도, Stack Overflow를 뒤질 일도, 새벽 2시에 디버깅할 일도 없었죠. 바이브만 있으면 됐습니다.

이 환상에는 이름도 있었습니다. OpenAI 공동 창업자이자 전 테슬라 AI 총괄이었던 안드레이 카파시(Andrej Karpathy)가 2025년 2월에 붙인 이름, 바이브 코딩(vibe coding)이었는데요. 모든 줄을 이해하지 못해도 AI가 생성한 코드를 그대로 받아들이는, "바이브에 완전히 몸을 맡기는" 개발 방식을 뜻했습니다. Collins 사전은 이 단어를 2025년 올해의 단어로 선정하기도 했죠.

그리고 14개월이 지난 지금, 후폭풍이 오고 있습니다.

이 꿈을 만든 숫자들

먼저 이 흐름이 얼마나 빨랐는지부터 짚어보겠습니다.

Y Combinator 2025년 윈터 배치에서는 스타트업의 25%가 코드베이스의 95% 이상을 AI로 만들었습니다. GitHub에 따르면 지금 커밋되는 신규 코드의 46%가 AI 생성 코드입니다. 한 분석에서는 미국 개발자의 92%가 매일 AI 코딩 도구를 쓰는 것으로 나타났죠. Cursor, Replit, Bolt, Lovable 같은 도구들은 수십억 달러의 벤처 투자를 받았고, 시장 규모는 2026년 기준 47억 달러, 내년에는 123억 달러에 이를 전망입니다.

일시적인 유행이 아니었습니다. 개발자들은 AI의 도움을 받아 25~55% 더 빠르게 일을 끝냈습니다. AI 결과물을 제대로 평가할 수 있는 시니어 엔지니어들은 생산성이 최대 81%까지 올랐다고 보고했고요. 비개발자들도 예전에는 만들 수 없었던 앱을 만들어냈습니다. 소프트웨어 제작의 민주화라는 약속은, 어느 정도 실제로 지켜지고 있었던 거죠.

그런데 뭐가 잘못된 걸까요?

아무도 꺼내고 싶어 하지 않던 이야기

2025년 12월, 한 리서치 회사가 오픈소스 GitHub 풀 리퀘스트 470건을 분석했습니다. 결과는 꽤 당혹스러웠습니다. AI가 공동 작성한 코드에는 사람이 쓴 코드보다 주요 이슈가 1.7배 더 많았습니다. 로직 오류는 더 자주 나왔고, 설정 오류는 75% 더 많았으며, 보안 취약점은 사람이 쓴 코드의 2.74배에 달했죠.

그리고 Lovable 사건이 터졌습니다. Lovable은 가장 인기 있는 바이브 코딩 플랫폼 중 하나입니다. 비개발자도 프롬프트만으로 실제 웹 앱을 만들 수 있게 해주는 서비스죠. 보안 연구자들이 Lovable로 만든 앱 1,645개를 조사한 결과, 170개(10%가 넘는 수치)의 데이터베이스 설정에 치명적인 Row-Level 보안 결함이 있었습니다. 테스트용 앱이 아니라, 실제 사용자 데이터를 다루는 앱들이었습니다. 기본적인 공격 스킬만 있어도 누구나 접근할 수 있는 상태였죠.

이 취약점에는 CVE-2025–48757이라는 번호까지 부여됐습니다. 바이브 코딩 업계의 첫 메이저 보안 위기가 온 겁니다.

예외는 아니었습니다. 보안 회사 Tenzai는 별도 테스트에서 많이 쓰는 바이브 코딩 도구 다섯 개(Claude Code, OpenAI Codex, Cursor, Replit, Devin)로 동일한 앱 15개를 만들어봤는데요. 결과는 취약점 69개, 그중 6개는 치명적인 수준이었습니다.

코드 변경 빈도는 41% 늘었습니다. 코드 중복은 4배로 증가했고요. 코드베이스를 건강하게 유지해주던 꼼꼼한 리팩터링은 무너졌습니다. 2021년에는 변경된 라인의 25%가 리팩터링이었지만, 2024년에는 10% 아래로 떨어졌죠. 2026년 1월에 나온 한 학술 논문은 바이브 코딩이 핵심 인프라를 지탱하는 메인테이너들과 개발자들의 접점을 줄이면서 오픈소스 생태계를 조용히 무너뜨리고 있다고까지 주장했습니다.

속도는 얻었습니다. 대신 품질과 보안, 장기적인 유지보수 가능성을 내줬죠.

"바이브 코딩이 끝났다"는 말의 진짜 의미

이 지점에서 오해가 가장 많이 생기니 정확히 짚고 넘어가죠. 카파시가 원래 정의했던 의미의 바이브 코딩, 즉 AI 결과물을 검토 없이 받아들이고 넘어가는 방식은, 실무에서 쓸 수 있는 방식으로는 수명을 다했습니다. 도구가 나빠져서가 아니라, 현실이 그 한계를 드러냈기 때문이죠.

프로덕션에 올리자 앱이 터졌습니다. 보안 구멍이 발견됐고요. 코드베이스는 유지보수가 불가능해졌습니다. 엔지니어링 지식이 전혀 없어도 스타트업이 주말 안에 프로토타입을 띄울 수는 있습니다. 하지만 실제 사용자가 들어와 예상치 못한 행동을 하기 시작하면, AI가 만들어놓은 뼈대는 대부분 버텨주지 못했습니다.

이 흐름을 한 줄로 압축한 표현이 있습니다.

바이브 코딩은 제품을 만들 수는 있지만, 제품을 유지할 수는 없다.

끝나는 건 AI 보조 개발이 아닙니다. AI 보조 개발은 앞으로도 남을 거고, 오히려 더 강력해지는 중이죠. 끝나는 건 "이해 없이 바이브만으로 밀어붙일 수 있다"는 생각입니다. 지금 상황을 가장 정직하게 요약하면 이렇습니다. 거대한 프롬프트 하나로 밀어붙이던 시대는 끝났습니다. 이제는 작업을 잘게 쪼개 설계하는 시대죠.

새로운 판의 시작, 바이브를 설계하기

2026년에 실제로 잘나가는 개발자들은 이 사실을 이미 파악했습니다.

개발자라는 역할은 사라지지 않았습니다. 바뀌었을 뿐이죠. 지금 가장 가치 있는 엔지니어는 가장 많은 줄의 코드를 짜는 사람이 아닙니다. AI를 효과적으로 지휘하고, 그 결과물을 평가할 수 있는 사람입니다. 아키텍처에 대한 판단력, 보안에 대한 직관, 복잡한 시스템을 AI가 건드리기 전에 검토 가능한 단위로 분해하는 능력 같은 것들이죠.

반복해서 나오는 비유가 있습니다. 이제 당신은 조각가고, AI는 점토라고요. 실제로 현장에서는 이런 모습입니다.

프롬프트 전에 설계부터 합니다

2026년에 안정적으로 소프트웨어를 출시하는 팀들은 Cursor를 열고 "SaaS 하나 만들어줘"를 치지 않습니다. AI에 뭔가 넘기기 전에 먼저 기술 PRD(제품 요구사항 문서)를 쓰는데요. 데이터 모델, 연동 포인트, 보안 가드레일을 정의해둡니다. 맥락이 충분히 주어졌을 때 AI는 훨씬 빨라지거든요.

AI 코드는 검증되지 않은 코드로 취급합니다

대부분의 바이브 코더들이 거부했던 불편한 인식 전환이죠. AI가 만든 코드는 기본적으로 안전하지 않습니다. 출처를 알 수 없는 코드와 똑같이 보안 스캔, 코드 리뷰, 테스트를 거쳐야 합니다. Snyk, Semgrep 같은 도구가 AI 보조 개발의 필수 관문으로 자리 잡은 이유도 바로 이겁니다.

한 번에 다 만들지 말고, 조금씩 붙여나갑니다

한 컴포넌트를 만들고, 테스트하고, 이해한 다음, 다음으로 넘어갑니다. "프롬프트 한 번으로 앱 전체 만들기" 식 접근은 아무도, 심지어 만든 개발자 본인조차 이해하지 못하는 시스템을 만들어냅니다. 이해하지 못하는 시스템은 망가졌을 때 고칠 수 없죠.

비개발자들에게는 더 쓴 진실

바이브 코딩의 원래 약속은 민주화였습니다. 누구나 소프트웨어를 만들 수 있다는 것. 이 약속은 어느 정도 지켜졌습니다. 하버드 교육대학원의 카렌 브레넌(Karen Brennan) 교수는 2025년 말에 바이브 코딩을 주제로 강의를 진행했는데요. 바이브 코딩의 핵심 가치는 "실험해 보는 비용을 확 낮춘 것"이라고 짚었습니다. 일단 만들어봐야 이해할 수 있는 것들이 있는데, 그걸 빠르게 해볼 수 있게 됐다는 거죠.

이건 정말로 앞으로 계속될 일입니다. 하지만 아무리 AI 성능이 좋아져도 메우지 못한 간극이 하나 있습니다. 데모에서 돌아가는 프로토타입과, 실제 데이터를 가진 실제 사용자들을 대상으로 프로덕션에서 안정적으로 돌아가는 소프트웨어 사이의 간극이죠. 이 간극을 메우려면 코드가 뭘 하고 있는지 이해하는 사람이 필요합니다. 모든 줄을 직접 쓴 사람일 필요는 없습니다. 다만 그 줄들을 읽고, 평가하고, 책임질 수 있는 사람이어야 하죠.

개발자 커뮤니티에서 존경받는 사이먼 윌리슨(Simon Willison)은 이렇게 정리했습니다.

"LLM이 코드를 한 줄 한 줄 다 썼다고 해도, 그걸 전부 리뷰하고, 테스트하고, 이해했다면, 제 기준에서 그건 바이브 코딩이 아닙니다. LLM을 타이핑 도우미로 쓴 거죠."

이 차이가 중요합니다. AI를 타이핑 도우미로 쓰거나, 초안 뽑아주는 도구로 쓰거나, 빠르지만 가끔 실수하는 페어 프로그래머로 쓰는 건 전혀 문제가 없습니다. 오히려 제대로 된 활용법이죠. 반면 AI가 내놓은 결과물을 이해도 하지 않은 채 그대로 배포하는 건 전혀 다른 이야기입니다. 2025년이 우리에게 가르쳐준 건, 바로 그 다른 이야기를 그만해야 한다는 겁니다.

결국 남는 건?

만약 개발자라면, 일자리 걱정은 안 하셔도 됩니다. 역할이 달라지고 있을 뿐이죠. 지금 힘들어하는 엔지니어는 AI 도구를 아예 거부하거나, 아무 생각 없이 갖다 쓰는 사람들입니다. 잘나가는 쪽은 안목을 키운 사람들이고요. AI 결과물을 언제 믿고 언제 의심해야 하는지 아는 사람, 복잡한 시스템을 AI가 풀 수 있는 작은 문제들로 쪼갤 줄 아는 사람들이죠.

Cursor나 Bolt로 뭔가 만들어본 비개발자라면, 그 경험은 분명 가치 있었습니다. 배운 게 있으실 테니까요. 문제는 그다음입니다. 실제 사용자에게 서비스를 배포할 생각이라면, 코드를 직접 리뷰할 실력을 갖추거나, 대신 해줄 동료가 필요합니다.

바이브 코딩 도구에 투자하거나 직접 개발하는 입장이라면, 로드맵은 명확합니다. 속도 문제는 이미 풀렸습니다. 앞으로 10년은 AI가 만든 코드를 기본적으로 믿을 수 있게 만드는 사람들의 시대가 될 겁니다. 나중에 덧붙이는 기능이 아니라, 첫 프롬프트부터 설계에 녹아 있는 형태여야 합니다.

바이브 코딩은 끝나지 않았습니다. 다만 어려운 부분을 건너뛰어도 됐던 시절은 끝났죠. 어려운 부분은 결국 돌아오게 되어 있습니다. 늘 그래왔듯이요.

<참고>

여러 연구에서 반복적으로 확인되는 패턴은 같습니다. AI는 개발 속도를 높이지만, 제대로 된 리뷰 없이는 훨씬 더 많은 보안 리스크를 만들어냅니다.

여러분의 경험은 어떠셨나요? 여전히 바이브 타는 중이신가요, 아니면 좀 더 의도적인 방식으로 넘어오셨나요?

<원문>

Vibe Coding Is Over. What Comes Next Is Much Harder.

]]>

YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지

안녕하세요, 요즘 프로덕트 메이커입니다.

프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: GPT-5.5 Instant - 어제와 다른 오늘의 ChatGPT
참고할 것: YouMind - X에서 화제인 AI 프롬프트를 실시간으로 모아보는 곳
적용해볼 것: YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지 (내용이 좀 깁니다)

<출처: openai>

1. 써볼 것: GPT-5.5 Instant - 어제와 다른 오늘의 ChatGPT

GPT-5.5 Instant는 OpenAI가 5월 5일에 ChatGPT의 기본 모델로 교체한 새 모델입니다. 기본 모델이라는 건, ChatGPT를 열었을 때 따로 뭘 고르지 않아도 자동으로 대화하게 되는 그 모델을 말합니다. 교체 직후부터 답변이 짧아졌다, 이모지가 줄었다는 반응들이 나왔는데요. OpenAI에 따르면 의료·법률·금융 같은 민감한 주제에서 할루시네이션이 52.5% 줄었고, 과거 대화와 파일에서 맥락을 끌어오는 Memory Sources라는 기능이 함께 추가됐습니다.

무슨 문제를 해결해 주나요?

GPT-5.5 Instant는 기존 ChatGPT를 쓰면서 반복적으로 겪던 불편함 세 가지를 건드린 업데이트입니다.

지어내는 문제: AI가 그럴듯하게 틀린 정보를 내놓는 할루시네이션은 ChatGPT의 오래된 약점이었습니다. GPT-5.5 Instant는 내부 테스트 기준으로, 의료·법률·금융처럼 틀리면 안 되는 주제에서 할루시네이션이 52.5% 줄었다고 합니다. 사용자들이 직접 사실 오류로 신고한 대화에서도 부정확한 답변이 37.3% 감소했고요. 눈에 띄는 변화 하나는 실시간 자기 교정인데요. 이전 모델은 수학 문제 같은 걸 풀다 틀려도 자신 있게 밀어붙였다면, 이제는 중간에 스스로 틀린 걸 알아채고 다시 풀어봅니다.
장황한 답변: 같은 질문에 대해 이전 모델보다 단어 수가 약 30% 줄었습니다. 굳이 안 해도 되는 후속 질문, 반복되는 서식, 과한 이모지가 빠졌고요. 2개월 전 GPT-5.3 Instant를 내놓으면서 오글거리는 톤을 줄이겠다고 했는데, 이번에는 거기서 한 발 더 나아가서 간결함 자체를 전면에 내세우고 있습니다.
매번 맥락을 새로 설명해야 하는 문제: Memory Sources라는 기능이 추가됐습니다. ChatGPT가 이전 대화 내용, 업로드한 파일, 연결된 Gmail 계정에서 맥락을 끌어와서 답변에 반영할 수 있게 된 건데요. 예를 들어 지난주에 마케팅 전략 관련으로 긴 대화를 했다면, 이번 주에 새 대화를 시작해도 그 내용을 참고합니다. ChatGPT가 어떤 과거 대화나 파일을 참고했는지 확인할 수도 있고, 잘못된 정보는 삭제하거나 수정할 수 있습니다. 다만 이 기능은 현재 Plus와 Pro 유료 사용자의 웹 버전에서만 쓸 수 있고, 무료 사용자와 모바일은 순차 확대 예정입니다.

어떻게 쓰나요?

사용을 위해 따로 설정할 건 없습니다. ChatGPT를 열면 이미 GPT-5.5 Instant로 바뀌어 있을테니까요. Memory Sources를 쓰고 싶다면 설정에서 메모리 기능이 켜져 있는지 확인하면 되고요. 누군가에게 채팅을 공유해도 메모리 소스는 상대방에게 보이지 않습니다.

이전 모델인 GPT-5.3 Instant는 유료 사용자에 한해 3개월간 유지됩니다. 설정에서 모델을 직접 선택하면 쓸 수 있고, 3개월 뒤에는 완전히 퇴장할 예정입니다. 참고로 OpenAI는 작년에 GPT-4o를 없앴을 때 상당한 반발을 겪은 적이 있습니다. 당시 사용자들이 청원까지 올렸지만, 결국 올해 2월에 폐지됐고요. 이번에도 약 2개월 주기로 기본 모델을 교체하는 패턴이 이어지고 있어서, 특정 모델에 워크플로를 맞춰놓은 사람이라면 이 주기를 염두에 둘 필요가 있습니다. API로 ChatGPT를 연동해 쓰는 개발자라면, GPT-5.5 Instant가 chat-latest라는 이름으로 API에도 올라가 있으니 확인해보세요.

+ 보너스: Claude Code 한도가 2배로 늘었습니다

같은 주에 Anthropic에게도 변화가 있었는데요. SpaceX의 Colossus 1 데이터센터 전체 용량을 사용하는 계약을 맺고, Claude Code와 API 한도를 대폭 상향시켰다는 내용입니다. 5월 6일부터 적용된 변경 사항은 세 가지입니다.

Claude Code의 5시간 기준 사용 한도가 Pro, Max, Team, Enterprise 플랜에서 2배로 늘었습니다.
Pro와 Max 사용자에게 적용되던 피크 시간대 한도 축소가 사라졌습니다.
API에서는 Opus 모델의 요청 한도가 상향되었습니다.

<출처: youmind>

2. 참고할 것: X에서 화제인 AI 프롬프트를 실시간으로 모아보는 곳

YouMind는 X(Twitter)에서 화제가 되는 AI 프롬프트를 매일 추적해서 모델별로 정리해주는 프롬프트 라이브러리입니다. 이미지, 비디오, 웹페이지 생성 프롬프트가 중심이고, GPT Image 2, Nano Banana Pro, Seedance 2.0, Gemini 3 Pro 등 주요 모델별로 분류되어 있습니다. 현재 2만 개 이상의 프롬프트가 모여 있고, X에서 반응이 좋은 프롬프트를 골라서 하루 두 번 자동으로 업데이트하는 구조입니다.

기존 프롬프트 모음집과 무엇이 다른가요?

한동안 프롬프트 템플릿 모음집이 유행했습니다. 용도별로 잘 정리된 프롬프트를 모아놓고, 필요할 때 복사해서 쓰는 방식이었죠. 그런데 요즘은 AI 모델의 버전이 빠르게 바뀌고, 새로운 기법이 거의 매일 나오다시피 합니다. 몇 달 전에 잘 되던 프롬프트가 모델 업데이트 하나로 잘 안 먹히기도 하고, 반대로 새 모델에서만 가능한 기법이 갑자기 등장하기도 하죠.

YouMind는 지금 이 순간 X에서 사람들이 공유하고 반응하고 있는 프롬프트를 계속 수집합니다. 사이트에는 지난 7일간 가장 영향력 있는 프롬프트라는 섹션이 있어, 최근 관심 받고 있는 프롬프트가 무엇인지 빠르게 트렌드를 확인할 수도 있습니다.

어떻게 작동하나요?

YouMind의 프롬프트는 대부분 X의 공개 게시물에서 수집됩니다. AI로 이미지나 비디오를 만들어서 올린 사람들의 게시물 중에서, 반응이 좋고 결과물이 괜찮은 것들을 골라서 프롬프트와 생성 결과물을 함께 보여주는 구조입니다.

사용 방식은 단순합니다. 모델별 페이지에서 프롬프트를 둘러보고, 마음에 드는 걸 복사해서 해당 모델에 그대로 붙여넣으면 됩니다. YouMind 자체에서 모델을 선택해 바로 실행할 수도 있고요. 각 프롬프트에는 실제 생성된 이미지나 비디오가 샘플로 붙어 있어서, 결과물을 미리 확인하고 고를 수 있습니다.

개발자라면 오픈소스 스킬도 참고할 만합니다. Claude Code, OpenClaw, Cursor 같은 AI 어시스턴트에 YouMind의 프롬프트 라이브러리를 연결하는 스킬이 GitHub에 공개되어 있어요. 사이버펑크 스타일 아바타 프롬프트 찾아줘라고 말하면 1만 개 중에서 맞는 걸 3개 골라서 샘플 이미지와 함께 보여주는 식입니다.

무엇을 얻어가야 하나요?

YouMind는 이미지 / 비디오 생성 프롬프트 도구로만 사용해도 충분히 유용하지만, 더 유용하게 쓰고 싶다면 실사용자의 흐름을 살펴보시길 추천드립니다. 지금 어떤 모델의 어떤 기법이 화제인지, 사람들이 AI 이미지 생성을 어떤 용도로 쓰고 있는지, 일주일 단위로 트렌드가 어떻게 바뀌는지를 한눈에 볼 수 있기 때문입니다. 예를 들어 지금은 GPT Image 2로 일부러 MS 그림판 스타일의 조잡한 이미지를 만드는 프롬프트가 X에서 500만 뷰 이상을 기록하며 유행하고 있는데, 이런 흐름을 빠르게 잡을 수 있습니다.

<출처: 작가, ChatGPT 제작>

무료이고, 별도 가입 없이 프롬프트를 복사해서 쓸 수 있습니다
이미지·비디오 생성 프롬프트가 중심이며, AI로 시각적 결과물을 만드는 사람에게 유용합니다
프롬프트 자체보다 지금 사람들이 AI를 어떻게 활용하고 있는지, 그 흐름을 보는 도구로 쓰면 더 유용합니다

<출처: ycombinator>

3. 적용해볼 것: YC가 이번 여름에 투자하고 싶은 스타트업 아이디어 15가지

Y Combinator가 2026년 여름 배치를 앞두고 Request for Startups(RFS)를 공개했습니다. RFS는 YC가 창업자들에게 이런 분야에 도전해봤으면 좋겠다고 공개적으로 밝히는 일종의 관심 목록인데요. 보통 반기에 한 번씩 나오고, 3개월 전 봄 배치에서는 8개 분야를 제시했습니다.

이번 여름 목록은 봄의 거의 두 배인 15개입니다. 그리고 방향이 많이 달라졌습니다. 봄에는 AI 에이전시, AI PM 도구, 스테이블코인처럼 소프트웨어만으로 시작할 수 있는 아이디어가 중심이었는데, 이번에는 농업 로봇, 드론 방어 시스템, 우주용 칩, 반도체 공급망까지 포함되어 있으며, YC 역사상 가장 하드테크 쪽으로 기울어진 목록이라는 평가도 나오고 있습니다.

무슨 문제를 해결하려 하나요?

AI 도구가 쏟아지고 있지만, 대부분은 기존 업무를 돕는 수준에 머물러 있습니다. YC가 이번 RFS에서 찾는 건 그 다음 단계예요. AI로 기존 산업의 구조 자체를 바꾸거나, AI 시대에 새로 필요해진 인프라를 만드는 스타트업입니다. 15개를 하나씩 보면 흩어져 보이지만, 묶어서 보면 몇 가지 방향이 보입니다. 프로덕트 메이커와 가까운 영역부터 정리하겠습니다.

YC가 공개한 15가지

소프트웨어가 다시 만들어지는 영역

SaaS 챌린저:AI 코딩으로 소프트웨어 생산 비용이 10~100배 줄면서, 수십 년간 수백만 줄의 코드로 쌓아온 레거시 SaaS의 진입 장벽이 무너지고 있다는 게 YC의 판단입니다. 기존 제품을 복제해서 1/10 가격에 파는 것, AI 네이티브로 워크플로를 처음부터 다시 설계하는 것, 여러 포인트 솔루션을 하나로 묶는 것, 고가 제품의 오픈소스 대안을 만들고 서비스로 수익을 내는 것 등 공격 방법도 여러 가지를 제시하고 있습니다. YC가 특히 강조하는 건, 프로젝트 관리 같은 쉬운 타겟이 아니라 칩 설계 소프트웨어, ERP, 산업 제어 시스템처럼 수십 년간 건드리기 어려웠던 영역을 노리라는 겁니다.
에이전트를 위한 소프트웨어: 인터넷의 다음 1조 사용자는 사람이 아니라 AI 에이전트라는 관점입니다. 지금 에이전트는 사람이 쓰도록 만든 소프트웨어 위에서 버튼을 클릭하며 느리게 동작하고 있는데, 에이전트에게 필요한 건 폼이나 대시보드 같은 시각적 인터페이스가 아니라 API, MCP, CLI 같은 기계가 읽을 수 있는 인터페이스입니다. 기존 소프트웨어의 모든 카테고리가 에이전트를 위해 다시 만들어져야 하고, 이건 기존 기업이 에이전트 지원을 추가하는 방식이 아니라 처음부터 에이전트를 중심에 놓고 설계하는 스타트업에서 나올 거라고 보고 있습니다.
동적 소프트웨어 인터페이스: 지금 소프트웨어는 모든 사용자에게 같은 화면을 보여줍니다. Netflix조차 추천 콘텐츠는 달라도 레이아웃 자체는 똑같죠. YC는 코딩 에이전트가 사용자 개인에 맞게 인터페이스를 바꿔주는 미래를 보고 있는데요. 같은 이메일 앱이 한 사용자에게는 할 일 목록으로, 학생에게는 일정 캘린더로 보이는 식입니다. 이걸 실현하려면 소프트웨어를 전달하는 방식 자체가 바뀌어야 해서, 프론트엔드만 바꿀 수 있게 할 건지 소스 코드를 통째로 열 건지 같은 문제가 남아 있습니다.

AI가 서비스와 기업 운영을 바꾸는 영역

AI 네이티브 서비스 기업: 2023~2025년 대부분의 AI 스타트업이 사람의 업무를 돕는 도구를 만들었다면, 다음 단계는 소프트웨어가 아니라 서비스 자체를 파는 AI 기업이라는 겁니다. 서비스 시장의 총 지출이 소프트웨어 시장보다 몇 배 크고, 이미 외부에 맡기고 있는 업무가 많기 때문에 AI로 대체하기가 오히려 쉽다는 논리입니다. YC가 특히 관심을 보이는 분야는 보험 중개, 회계·세무·감사, 컴플라이언스, 의료 행정입니다.
Company Brain: AI 자동화의 가장 큰 장벽이 모델 성능에서 도메인 지식으로 옮겨가고 있다는 관찰입니다. 기업마다 환불을 어떻게 처리하는지, 가격 예외를 어떻게 결정하는지, 장애 대응을 어떻게 하는지 같은 핵심 노하우가 있는데, 이게 이메일, 슬랙, 지원 티켓, 데이터베이스 등에 흩어져 있습니다. 이걸 한곳에 모아서 AI가 실행할 수 있는 형태로 정리하는 것, 그러니까 기업 운영 방식의 살아 있는 지도를 만드는 게 Company Brain이라는 아이디어입니다.
기업용 AI 운영 체제: 모든 회의를 녹화하고, 모든 티켓을 추적하고, 모든 고객 상호작용을 기록해서 기업 전체를 검색 가능하게 만드는 겁니다. YC에 따르면 이걸 적용한 팀은 스프린트 시간을 절반으로 줄이고 출시량을 두 배로 늘렸다고 합니다. 현재는 Slack, Linear, GitHub, Notion 등을 커스텀 코드로 일일이 연결해야 하는데, 이걸 하나의 레이어로 통합하는 제품이 아직 없다는 게 YC의 관찰입니다.

하드웨어, 인프라, 특화 산업

나머지 아이디어들은 프로덕트 메이커의 일상 업무와는 거리가 있지만, AI가 소프트웨어를 넘어 어디까지 확장되고 있는지를 보여줍니다.

에이전트 워크플로우용 추론 칩: 현재 AI 칩은 프롬프트를 넣으면 응답이 나오는 방식에 맞춰 설계되어 있는데, 에이전트는 도구를 호출하고 분기하고 역추적하는 루프 구조로 동작합니다. 현재 GPU는 이런 작업에서 활용률이 30~40% 수준이라고 합니다. 에이전트의 작동 방식에 맞는 칩을 새로 설계해야 한다는 아이디어입니다.
반도체 공급망 2.0: AI 칩 하나가 약 1,400개 공정 단계를 거치고 12개국 이상을 경유하는데, 이 공급망이 아직도 스프레드시트와 전화로 관리되고 있다는 문제의식입니다. 실시간 추적, 리스크 모니터링, 수출 규제 대응 같은 기본적인 도구가 거의 없는 상태라고 합니다.
하드웨어 공급망: 중국 선전에서는 부품 설계부터 제작까지 하루면 되지만 미국에서는 같은 과정에 수 주가 걸립니다. 이 격차를 줄이는 스타트업에 관심을 보이고 있습니다.
우주 전자부품: SpaceX의 재사용 로켓으로 우주에 물건을 보내는 용량이 크게 늘면서, 우주 환경에 맞게 질량·열·방사선을 최적화한 추론 칩 시장이 열리고 있다는 아이디어입니다.
우주 산업 역량: 달 표면의 레골리스에서 실리콘, 알루미늄, 철, 티타늄 같은 원자재를 추출하고, 이를 3D 프린팅으로 구조물을 만드는 방향입니다. 달에서는 중력이 약해 지지 구조물이 필요 없어서 지구보다 오히려 효율적일 수 있다고 합니다.
AI 기반 저농약 농업: AI가 개별 잡초와 해충을 실시간으로 식별하고, 로보틱스가 밭 전체가 아닌 식물 단위로 정밀 처리해서 농약 사용을 90%까지 줄이는 방향입니다.
AI 맞춤형 의료: 유전체 시퀀싱 비용이 급격히 하락하면서, 환자 개인에 맞춘 진단과 치료가 가능해지고 있다는 관점입니다.
대드론 군집 방어: 패트리어트 미사일 한 발이 300만 달러인데 FPV 드론 한 대는 500달러입니다. 비용이 완전히 공격자 쪽으로 기울어 있는 상황에서, YC는 이 문제가 무기 운용보다 실시간 분산 시스템 운영에 가깝다고 보고 있습니다.

시장 접근 방식의 변화

거대 기업에 판매하고 싶은 스타트업: 기존에는 스타트업이 스타트업에게 파는 게 정석이었지만, AI 이후로 Fortune 100 규모의 기업에도 바로 접근할 수 있게 됐다는 관찰입니다. YC에 따르면 최근 3년간 배치 중이거나 첫해에 수백만 달러 규모 계약을 체결한 사례가 나오고 있고, 2~3명 팀이 법인 설립 전에 Fortune 10 기업이 쓰는 제품을 출시한 경우도 있다고 합니다.

15가지가 공통으로 가리키는 것

15개 아이디어를 관통하는 방향이 몇 가지 보입니다.

첫 번째는 AI가 기능에서 기반으로 바뀌고 있다는 것입니다. 2023~2025년의 AI 스타트업이 기존 제품에 AI를 얹는 방식이었다면, YC가 지금 찾는 건 AI 위에서 서비스, 소프트웨어, 하드웨어를 처음부터 다시 만드는 기업입니다.
두 번째는 에이전트가 새로운 사용자라는 것입니다. 에이전트를 위한 소프트웨어, 에이전트용 추론 칩, 동적 인터페이스 모두 같은 전제 위에 있습니다. 소프트웨어의 사용자가 사람만이 아니게 되면, 인터페이스부터 인프라까지 다시 설계해야 한다는 거죠.
세 번째는 레거시를 교체하는 것이 가장 큰 기회라는 것입니다. SaaS 챌린저, 반도체 공급망, 하드웨어 공급망 모두 수십 년간 바뀌지 않았던 것들입니다. AI가 소프트웨어 생산 비용을 크게 줄이면서, 이전에는 규모 때문에 건드릴 수 없었던 영역이 열리고 있습니다.

적용을 위해 실행해볼 수 있는 것

지금 내가 만들고 있는 제품이 사람을 돕는 도구인지, 서비스 자체를 대체하는 것인지 구분해보기. YC는 도구의 다음 단계가 서비스라고 보고 있습니다.
내 제품의 사용자가 사람만인지, 에이전트도 쓸 수 있는 구조인지 점검해보기. API, MCP, CLI 같은 기계용 인터페이스가 있는지 확인하는 것부터 시작할 수 있습니다.
내가 속한 산업에서 수십 년간 바뀌지 않은 소프트웨어가 뭔지 떠올려보기. 그게 아직도 스프레드시트로 관리되고 있다면 기회일 수 있습니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다. 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

GEO에 시간·비용 쓰기 전에 알아야 할 것들: 팩트체크 세미나

제로클릭 시대, GEO에 다들 어떻게 대응하고 계시나요?

요즘 IT는 최근 기업 블로그 에이전트를 만들며 GEO 최적화를 적용해 봤습니다. 기업 블로그에 발행할 콘텐츠를 기획하고 생성하는 에이전트인데요. 최근 기업의 GEO에 대한 관심을 고려하면, 이 에이전트도 GEO에 최적화된 구조로 글을 쓰는 것이 중요했습니다. 그래서 최종 산출물에는 글 자체뿐 아니라 GEO 대응을 위한 JSON-LD 구조화 데이터까지 함께 출력되도록 설계했죠.

이 과정에서 GEO 스터디를 하게 됐습니다. 그런데 들여다볼수록 의문이 쌓였습니다.

첫째, GEO 성과를 측정하고 개선하는 '단 하나의 플레이북'이 없었습니다. 더 근본적으로는, '무엇을 성과로 볼 것인가'부터 정의가 합의되어 있지 않았습니다. 어떤 곳은 LLM 답변에 인용된 횟수를, 어떤 곳은 거기서 유입된 트래픽을, 또 어떤 곳은 브랜드 멘션 빈도를 성과라 부릅니다. 성과 정의가 흐릿하니 schema.org 마크업이든, 인용 가능한 통계 삽입이든, 백링크든 주요 액션으로 언급되는 것들 중 무엇을 우선해야 할지 판단할 기준이 서지 않았습니다.

둘째, GEO 성과를 높여준다는 서비스는 이미 시장에 많은데, 무엇을 목표로 어떤 도구를 왜 선택해야 하는지가 불확실했습니다. 트래킹 툴마다 측정 방식이 다르고, 컨설팅마다 접근 방식이 다릅니다. 의사결정자 입장에서 '뭘 사야 하나'보다 더 어려운 건 '뭘 기준으로 골라야 하나'입니다.

셋째, 단순히 여러 LLM에 쿼리를 던져 인용 빈도를 높이는 것만이 능사는 아니라는 의심이 들었습니다. 인용이 곧 비즈니스 성과로 직결되는 건 아니니까요. 측정 가능한 것에만 매달리다 보면, 정작 중요한 걸 놓칠 수 있습니다.

이 질문을 안고 현장 전문가들을 만났습니다. 그런데 같은 의문을 갖는 것이 저희만은 아니었습니다. 전문가들도 요즘 모두가 겪는 문제라고 입을 모았습니다. 그래서 같은 고민을 하는 대표와 실무 리더들을 위해, 정확한 사실들을 짚어볼 수 있는 시간을 마련했습니다.

GEO 팩트체크, 전문가·실무 리더·엔지니어 한자리에

요즘 IT는 AI 스타트업 라이너와 함께 5월 21일(목) 저녁 7시 라이너 오피스에서 'GEO 팩트체크: 시간·비용을 쓰기 전에 알아야 할 것들' 세미나를 엽니다. 시장에 만연한 GEO에 대한 오해를 전면으로 내세워 전문가의 생각과 사례를 들어보는 시간을 마련했습니다.

이 세미나에 모신 분들은 두 부류입니다.

한 축은 연구와 컨설팅을 병행하며 다양한 사례를 축적해 온 GEO 전문가들입니다. 시장에서 떠도는 'GEO 베스트 프랙티스' 중 무엇이 검증된 사실이고, 무엇이 추측에 가까운지 실제 클라이언트의 고민을 해결하며 축적해온 사례들을 기반으로 GEO의 오해와 진실을 다룹니다.

다른 한 축은 AI 검색 엔지니어입니다. 검색 로직 자체를 이해해야 사실에 더 가까운 전략을 세울 수 있다고 봤습니다. 시장의 통념이 기술적 현실과 어디서 맞고 어디서 어긋나는지, 엔지니어의 시점에서 직접 듣는 자리는 흔치 않습니다.

간단한 강연 이후, GEO에 관해 흔히 오해하는 명제 5가지를 던지고, 그에 대해 이야기 나누는 패널 토크 세션도 마련했습니다.

세션 1. GEO 성과 측정, 어떻게 접근할까 (양용준 서치나인 대표)

GEO가 중요하다는 말은 넘쳐나지만, 막상 "잘 되고 있는지" 측정하는 방법은 막막하죠. 실행을 하고 계신 분들도 이게 맞는지조차 확신하기 어려운 상황입니다. 안랩, 메트라이프 생명 등 다양한 기업의 GEO 문제를 해결해온 서치나인 양용준 대표도 비슷한 고민을 돌파해왔습니다.

첫 번째 세션에서는 양 대표가 다양한 연구와 고객 사례를 바탕으로 GEO를 실무에 적용하는 방식을 공유합니다. 내 사이트에 기반한 AI 가시성을 판단할 프롬프트는 어떻게 설정해야 하는지, GEO 툴의 성과를 지표로 삼는 게 아니라 간접적으로 활용하는 방법은 무엇인지, 간접적으로 전환을 파악하는 방안은 어떤 것이 있는지를 이야기합니다.

“안녕하세요, SEO/GEGO 컨설턴트 양용준입니다. 규모와 산업군에 상관없이 다양한 직종에서 7년간 SEO 컨설팅을 해왔습니다. 현재는 SEO에 기반한 GEO에 어떻게 하면 내 브랜드가 인용되는지 여러 가설을 세워 테스트하고 있습니다. 특히 AI에 잘 인용되는 방식에 대한 인사이트는 많지만 GEO에 대한 실제 성과 측정은 모호합니다. 아직 정답은 없지만 이번 세션에서 저의 경험과 사례를 공유해보려 합니다”

세션 2. GEO 시대의 콘텐츠 전략 (이소연 빌더블 대표)

GEO 시대에 글쓰기는 어떻게 달라져야 할까요? 30개 이상의 고객사에 직접 적용해 평균 3배 이상의 트래픽과 성장을 만들어낸 경험을 바탕으로, 이소연 빌더블 대표가 SEO와 GEO 글쓰기의 핵심 차이인 구조, 내용, 신뢰 신호 3가지를 중심으로, AI가 실제로 인용하는 콘텐츠는 어떻게 만들어지는지 살펴봅니다. 마지막엔 지금 바로 적용할 수 있는 액션 4가지도 제안되어, 세션 이후 실습해 볼 수 있습니다.

“안녕하세요, AI 검색 시대의 SEO·GEO 전략을 알려드리는 이소연입니다. 이론이 아닌 실무에 적용 가능한SEO/GEO 전략을 쉽게 풀어 드리고 있습니다. GEO 시대에 글쓰기가 왜, 어떻게 달라져야 하는지를 이번 세션을 통해 다뤄보려 합니다. 마지막에 제공되는 액션 4가지를 꼭 실습해보시면 좋겠습니다”

세션 3. AI 검색의 기술적 사실 (라이너 검색 엔진 전담 엔지니어)

AI 검색 엔진이 콘텐츠를 선택하고 인용하는 메커니즘을 라이너의 검색 엔지니어가 직접 설명합니다. 시장에서 'GEO 핵심'이라고 떠도는 이야기들 중 어떤 것들이 근거 없는 이야기이고, 어떤 것들이 가능성이 있는 이야기인지를 AI 검색 엔진의 동작 원리를 통해 짚어드립니다. 기술을 잘 모르는 분들도 따라올 수 있는 눈높이로 진행됩니다.

패널토크: GEO 오해와 진실

시장에서 흔히 도는 GEO 관련 통념을 주제별로 꺼내놓고, 두 컨설턴트가 함께 팩트체크합니다. 라이너에서 GEO 전략을 수행하고 있는 공다솜 콘텐츠 리드가 진행하며, 실제 현장의 생생한 고민을 풀어낼 계획입니다.

패널토크 주요 아젠다

SEO만 잘해도 GEO 성과를 얻을 수 있을까요?
GEO에 예산과 리소스를 얼마나 써야 할까요?
인용 횟수가 늘면 GEO를 잘하고 있다고 봐도 될까요?
사전 FAQ : 참가자들이 사전에 공유한 질문들을 추가로 다룹니다.

이런 분들께 권합니다

제로클릭 시대에 우리 비즈니스의 대응 방향이 아직 잡히지 않은 대표·마케팅 리더
GEO를 시작하려는데 전략과 성과 측정이 막막한 실무 리더
GEO 예산 편성을 앞두고 판단 근거가 부족한 의사결정자
GEO 정보는 많이 봤는데, 뭐가 맞는지 몰라 검색 엔지니어에게 직접 확인하고 싶은 SEO 담당자

행사 정보

일시: 2026년 5월 21일(목) 오후 7시
장소: 라이너 오피스 (서울 동교동)
참가비: 무료
모집 인원: 오프라인 25명, 온라인 200명
주최: 요즘IT(위시켓)
후원: 라이너

오프라인 세션에서는 패널 토크가 끝난 뒤 업계 전문가들과 함께 네트워킹할 수 있는 시간이 마련됩니다. 소규모의 전문적이고 밀도 높은 교류를 위해 오프라인 초대 인원은 25명으로 제한됩니다. 더 현장감 있는 교류를 원하는 분들께서는 아래 링크에서 신청 폼을 작성해 주세요. 신청자 중 25명을 추첨해 초청해 드립니다. 무료 행사인 만큼 자리가 빠르게 마감될 수 있으니 관심 있는 분은 서둘러 신청해 주세요.

➡️온라인 등록은 여기에서!

]]>

AI가 코드 짜는 시대, 버전 관리도 바뀐다 (feat. Entire AI)

<출처: 작가, Gemini로 생성>

예전에는 누가 작성한 코드인지를 알면, 왜 그렇게 짰는지도 대충 감을 잡을 수 있었습니다. 혹시 확실하지 않다 해도 직접 타이핑한 사람이 있었기에 그 사람에게 맥락을 물어볼 수라도 있었습니다. 그런데 지금은 다릅니다. AI가 순식간에 만들어낸 결과물 앞에서 우리는 점점 더 자주, “이거 대체 왜 이렇게 된 거지?”라는 질문을 하게 되었습니다.

Copilot, Cursor, Claude Code 같은 도구 덕분에 초안은 정말 빠르게 만들어집니다. 예전 같으면 반나절은 붙잡고 있어야 했을 작업이 몇 분 만에 끝나기도 하죠. 생산성만 놓고 보면 분명 놀라운 변화입니다. 그런데 이상하게도 실무는 마냥 편해지지 않았습니다. 코드는 빠르게 늘어나지만, 그 코드가 어떤 판단과 시도를 거쳐 여기까지 왔는지는 오히려 더 흐려졌기 때문입니다.

문제는 바로 그 지점에서 시작됩니다. 실무에서는 코드를 빠르게 만드는 것보다, 그 코드를 팀이 이해하고 리뷰하며 유지보수할 수 있게 만드는 일이 훨씬 더 중요하거든요. 특히 AI가 개입한 작업은 결과물만으로는 설명이 되지 않는 경우가 많습니다. 어떤 프롬프트에서 시작했는지, 중간에 어떤 선택지를 버렸는지, 어디까지가 에이전트의 판단이고 어디서부터 사람이 개입했는지 알 수 없다면, 나중에 장애가 나거나 인수인계가 필요할 때 곧바로 골치 아픈 상황이 벌어집니다.

저는 그래서 요즘 개발에서 진짜 중요한 변화는 “AI가 코드를 얼마나 잘 짜주느냐”는 데에만 있지 않다고 생각합니다. 이제 더 중요한 건, “AI가 만든 결과물을 얼마나 설명할 수 있도록 남기느냐”입니다. 다시 말해, 버전 관리의 대상 자체가 바뀌고 있는 셈이죠. 이번 글에서는 그 변화의 흐름을 제대로 보여주는 서비스 사례인 ‘Entire AI’와 함께, 왜 지금 개발자들에게는 ‘코드’보다 ‘맥락’을 관리하는 능력이 더 중요해지고 있는지 이야기해보려 합니다.

AI가 코드를 대신 짜주는데, 왜 개발은 더 쉬워지지 않을까

AI 코딩 도구를 쓰면 확실히 체감되는 변화가 있습니다. 예전 같으면 한참 붙잡고 있어야 했던 작업이 훨씬 빨라졌다는 점이죠. 초안 생성, 테스트 코드 작성, 반복 로직 정리, 간단한 리팩토링까지. 이제 사람이 처음부터 끝까지 손으로 짜기보다, 방향을 잡아주고 결과를 검토하는 느낌에 더 가까워졌습니다. 생산성만 놓고 보면 분명 놀라운 변화입니다.

그런데 이상하게도 실무에서의 개발은 기대만큼 쉬워지지 않았습니다. 오히려 어떤 부분은 더 어려워졌다고 느끼는 분들도 많을 겁니다. 특히 리뷰, 복기, 인수인계 같은 순간에서요. 코드는 빠르게 나왔지만, 정작 그 코드가 어떤 판단과 시도를 거쳐 여기까지 왔는지는 설명하기 어려운 경우가 많아졌기 때문입니다. 이런 코드는 얼핏 보면 잘 돌아가고, 겉으로 보기에도 그럴듯합니다. 그런데 며칠 뒤 다시 보면 낯설게 느껴집니다. “이거 왜 이렇게 했지?”라는 질문이 따라 생깁니다.

AI가 개입한 작업이 기존 작업 방식과 다르기 때문입니다. 프롬프트 몇 개로 방향이 바뀌고, 그 사이에는 여러 시도가 오가다, 그중 일부만 결과물로 남습니다. 결국 Git에는 마지막 코드만 남는데, 정작 중요한 ‘왜 그랬는지’란 정보는 사라지는 경우가 많습니다. 어떤 선택지를 검토했는지, 왜 그 방식이 채택됐는지, 사람은 어디서 개입했고 어디까지가 에이전트의 판단이었는지 같은 맥락 말이죠.

문제는 실무에서 정말 중요한 게 바로 그 맥락이라는 점입니다. 개발은 단순히 코드를 생성하는 일로 끝나지 않습니다. 팀원이 코드를 리뷰해야 하고, 나중에는 다른 사람이 이어받아야 하며, 장애가 나면 다시 거슬러 올라가 원인을 파악해야 하죠. 그대신 이때 과정이 빠진 결과물만 덩그러니 남아 있다면, 코드를 읽는 일이 아니라 의도를 추리하는 일이 되어버립니다. 생산성은 올라갔지만, 팀 전체의 이해 비용은 오히려 커지는 셈입니다.

바로 이 지점에서 새로운 문제의식이 등장합니다. AI가 만든 결과물 자체보다, 그 결과물이 만들어진 흐름과 맥락을 함께 남겨야 한다는 문제의식이죠. 결국 지금 개발이 더 쉬워지지 않는 이유는 AI가 코드를 못 짜서가 아니라, 코드 뒤에 있던 맥락이 너무 쉽게 사라지기 때문입니다.

이제 병목은 ‘생성’이 아니라 ‘맥락 관리’입니다

많은 개발자가 AI 코딩 도구를 이야기할 때, 여전히 “얼마나 결과를 잘 만들어주느냐”에 초점을 맞춥니다. 물론 중요한 부분입니다. 예전보다 훨씬 빠르게 초안을 만들고, 반복 작업도 크게 줄었기 때문이죠. 그런데 실무에서 진짜 시간을 잡아먹는 구간은 생성이 끝난 다음입니다. 누군가는 그 코드를 리뷰해야 하고, 또 누군가는 이어받아 수정해야 합니다. 문제가 생기면 다시 거슬러 올라가 원인을 찾아야 할 때도 있죠. 결국 팀 단위로 일이 돌아가는 순간부터 중요한 것은 코드 그 자체보다, 그 코드가 어떤 맥락에서 나왔는가입니다.

여기서 병목이 생깁니다. AI는 코드를 빠르게 만들어내지만, 그 과정은 휘발됩니다. 프롬프트를 어떻게 줬는지, 어떤 방향으로 몇 번 수정했는지, 중간에 어떤 선택지를 검토했다가 버렸는지, 어디서부터 사람의 판단이 들어갔는지 같은 정보는 대부분 사라지기 쉽습니다. 결과물만 남고 과정은 사라지는 구조인 셈이죠. 그러다 보니 PR을 열어도 난감한 때가 있습니다. 변경량은 많은데 왜 이런 설계를 택했는지 설명이 없고, 리뷰어는 코드만 붙잡고 의도를 역추적해야 합니다. 생성 속도는 빨라졌지만, 리뷰 속도는 오히려 더 느려지는 이유가 바로 여기에 있습니다.

예전에 코드 리뷰는 비교적 단순했습니다. 사람이 직접 짠 코드라면, 최소한 작성자가 어떤 생각으로 접근했는지 대화로 빠르게 되돌릴 수 있었기 때문이죠. 하지만 AI가 깊게 개입한 작업은 다릅니다. 작성자조차 며칠만 지나면 흐름을 모두 기억하지 못하는 경우가 많습니다. “대충 이렇게 하라고 시켰어요” 정도만 남는 경우도 흔하죠. 이런 상태에서는 리뷰가 검토가 아니라 추리에 가까워집니다. 코드 스타일을 보는 것이 아니라 이 변경이 어디서부터 잘못됐는지를 탐정처럼 따라가야 하는 상황이 오는 것이죠.

인수인계도 마찬가지입니다. 원래 인수인계가 어려운 이유는 코드가 복잡해서만은 아닙니다. 그 코드 뒤에 있는 판단과 맥락이 충분히 문서화되지 않아서 그렇습니다. AI가 작업 속도를 더 끌어올릴수록 이 문제는 더 커집니다. 팀원 입장에서는 결과물의 양은 갑자기 늘어난 반면, 그 결과물을 이해할 단서는 오히려 줄어들었기 때문입니다. 결국 실무에서는 “생성”보다 “맥락 관리”가 훨씬 더 비용이 큰 일이 되어버립니다. 잘 만든 코드보다, 왜 그렇게 만들었는지를 설명할 수 있는 코드가 더 중요해지는 거죠.

그래서 저는 지금 개발팀의 핵심 역량이 조금씩 바뀌고 있다고 생각합니다. 예전에는 빠르게 구현하는 사람이 눈에 띄었다면, 이제는 AI가 만든 결과물을 팀이 이해할 수 있는 형태로 정리하고 남기는 사람이 더 중요해지고 있습니다. 맥락을 남기지 못하면 생산성 향상은 개인의 순간적인 속도로 끝나버립니다. 반대로 맥락을 잘 남기면 그 결과물은 팀의 자산이 됩니다.

Entire AI는 이 문제를 어떻게 제품으로 풀고 있나

새로운 AI 서비스, Entire가 전면에 내세우는 문제의식도 정확히 이 지점에 있습니다. 이제 개발의 병목은 생성이 아니라, 생성 이후의 맥락을 어떻게 다루느냐에 달려 있다는 겁니다.

Entire는 깃허브의 전 CEO 토마스 돔케(Thomas Domke)가 만든 회사입니다. 2026년 2월 10일 공식 출범 글에서 토마스 돔케는 Entire를 “에이전트 시대의 다음 개발 플랫폼”으로 소개하며, 같은 날 첫 제품으로 Entire CLI를 오픈소스로 공개했습니다. 흥미로운 건 “우리가 더 똑똑한 AI를 만들겠다”가 아니라, 이미 여러 에이전트가 코드를 쏟아내는 현실에서 그 결과물을 어떻게 관리할지 손을 댔다는 점입니다. 그들의 방향은 명확합니다. AI가 만들어낸 코드와 그 맥락을 Git 흐름 안에 붙여놓겠다는 것이었죠.

핵심 개념은 Checkpoints입니다. 이 기능은 AI 코딩 세션을 Git 커밋과 연결해 남기는 방식으로 동작합니다. 공식 문서 기준으로 사용자나 에이전트가 git commit을 실행하면 세션 데이터가 커밋에 붙고, 커밋 메시지에는 Entire-Checkpoint 트레일러가 추가됩니다. 이어 세션 로그와 메타데이터는 entire/checkpoints/v1 브랜치에 저장됩니다. 쉽게 말하면 코드 변경만 남기는 게 아니라, 그 변경이 만들어진 대화와 흐름까지 버전 관리의 일부로 삼겠다는 접근입니다.

이 구조가 꽤 영리한 이유는 Git 히스토리를 지저분하게 만들지 않기 때문입니다. Entire는 작업 중에는 로컬의 shadow branch에 임시 상태를 잡아두고, 실제로는 사용자가 원래 하던 커밋만 히스토리에 남깁니다. 즉 “도구를 쓰기 위해 새로운 방식으로 일하라”가 아니라, 늘 해오던 Git 워크플로우에 자연스럽게 끼어드는 방식인 셈이죠. 공식 문서에서도 “추가 커밋 없이”, “기존 브랜치에서 안전하게”, “리와인드와 재개를 지원하는” 구조 등을 장점으로 설명합니다.

또 하나 눈에 띄는 건 특정 에이전트 하나에 올인하지 않았다는 점입니다. 현재 공식 문서와 사이트 기준으로 Entire CLI는 Claude Code, Gemini CLI, Cursor, OpenCode, GitHub Copilot CLI를 지원하고, Codex는 프리뷰 상태로 제공됩니다. 자동 캡처가 실패한 세션은 entire attach로 나중에 연결할 수 있게 해뒀고, 4월에는 직접 원하는 에이전트를 붙일 수 있는 플러그인 방식까지 공개했습니다. 처음부터 “최고의 코딩 에이전트” 경쟁에 들어가기보다 여러 에이전트가 섞여 쓰이는 실제 개발 환경을 전제로 설계한 느낌이 강합니다.

확장 속도도 꽤 빠릅니다. 3월에는 GitHub Copilot CLI 지원이 추가됐고, 3월 말에는 Codex 프리뷰, Windows 호환성, 플러그인 시스템이 소개됐습니다. 4월에는 Codex 사용 가이드와 외부 에이전트 연결 방식까지 연달아 나왔습니다. 그러니까 Entire는 아직 초기 제품이긴 하지만, 적어도 비전만 존재하는 회사는 아닙니다. 실제로 지금 당장이라도 설치하면 기존 Git 기반 프로젝트에 붙여볼 수 있는 형태로 계속 다듬어지고 있으니까요.

저는 그래서 Entire를 단순한 AI 코딩 도구라기보다, AI 시대에 맞는 새로운 기록 계층을 만들려는 시도로 봅니다. 코드 생성은 이미 충분히 빨라졌습니다. 이제 필요한 건 그 결과물을 팀이 이해하고, 검토하고, 되짚을 수 있게 만드는 장치인데요. Entire가 바로 그 지점을 제품으로 풀어내려는 꽤 본격적인 첫 시도로 보입니다. 아직 정답이라고 단정하긴 이르지만, 최소한 문제를 바라보는 방향만큼은 상당히 정확하다는 생각이 듭니다.

실제 개발자들은 이 방향을 어떻게 보고 있을까

Entire AI가 던진 문제의식은 분명 흥미롭습니다. 그런데 좋은 문제를 짚어 제품을 만드는 일과 시장이 그 제품을 곧바로 받아들이는 건 또 다른 이야기입니다. 실제로 출시 후 몇 달 사이 반응을 보면 평가가 갈립니다.

한쪽에서는 “지금 AI 코딩에서 진짜 빠져 있는 조각을 잘 짚었다”는 평가가 나오는 반면 다른 한쪽에서는 “문제는 인정하지만, 이 방식이 얼마나 강력한 해답인지는 아직 모르겠다”는 반응도 있습니다. 저는 이 양면성이 오히려 Entire를 더 흥미롭게 만든다고 봅니다.

먼저 호의적으로 보는 쪽에서는 Entire가 겨냥한 문제가 정말 현실적이라는 점에 공감합니다. AI가 만들어낸 코드는 점점 늘어나는데, 그 코드가 어떤 프롬프트와 시도, 툴 호출을 거쳐 나왔는지는 쉽게 사라지기 때문입니다. 이런 상황에서 Checkpoints처럼 세션의 흔적을 Git과 함께 남기겠다는 발상은 단순히 “예쁘다”를 넘어 “실무에 필요하다”는 반응을 끌어냅니다. 공식 사이트와 GitHub 저장소 기준으로도, CLI 프로젝트는 빠르게 주목받아온 느낌입니다. 적어도 문제의식 자체에는 많은 개발자가 동의하고 있다는 뜻입니다.

특히 요즘처럼 여러 에이전트를 섞어 쓰는 환경이 발전하며, 이런 반응이 더 커지고 있습니다. Claude Code로 초안을 만들고, Cursor에서 다듬고, Codex나 Copilot CLI로 보조 작업을 붙이는 흐름이 점점 흔해지고 있기 때문입니다. 그럴수록 팀 입장에서 진짜 필요한 건 “최종 코드가 무엇인가”보다는 “그 코드가 어떤 맥락에서 나왔는가”가 더 중요해질 겁니다. Entire가 출시 직후부터 Codex 지원, 플러그인 시스템, 다양한 CLI 연동을 빠르게 확장한 것도 이런 환경이 실제로 퍼진다는 전제를 반영한 움직임으로 볼 수 있습니다.

반대로 회의적인 반응도 만만치 않습니다. 해외 커뮤니티 반응을 보면 가장 많이 나오는 질문은 두 가지 정도입니다. “이게 정말 새로운 해자인가?”, 그리고 “이 문제를 굳이 Entire 같은 별도 레이어로 풀어야 하나?”입니다. 즉, 세션 데이터와 메타데이터를 남기는 아이디어 자체는 이해하지만, 그것이 장기적으로 독립 플랫폼이 될 만큼 큰 가치인지에 대해서는 의문이 간다는 겁니다. 오히려 협업 도구라기보다 나중에 학습용 데이터로 더 가치 있다는 말도 나옵니다. 결국 이들이 짚어낸 문제가 좋은 것과 별개로 그 문제를 가장 잘 푸는 방식인지 아직 모르겠다는 겁니다.

이 회의론도 충분히 이해가 갑니다. 개발자들은 원래 새로운 도구에 쉽게 감동하지 않습니다. 특히 Git, PR, 코드 리뷰처럼 이미 굳어진 습관 위에 무언가를 얹는 제품이라면 더 그렇습니다. ‘좋아 보이는데, 그래서 우리 팀이 진짜 이걸 깔고 쓸까?’라는 질문을 반드시 넘어서야 합니다. 실제로 개인 개발자 차원에서는 흥미로운 실험처럼 보일 수 있어도, 팀 단위 도입으로 넘어가려면 보안, 저장 방식, 운영 부담, 워크플로우 충돌, 실제 리뷰 생산성 개선 같은 훨씬 현실적인 검증이 필요하기 때문입니다.

지금 Entire가 받고 있는 시선은 이쯤 와 있다고 볼 수 있습니다. 물론 저는 이런 반응을 단순히 부정적이라고 보지는 않습니다. 오히려 시장이 “이 문제는 진짜다. 다만 해법은 더 지켜보자”라고 말하고 있는 것에 가깝다고 보입니다. 정말 별로인 제품은 논쟁조차 생기지 않으니까요. 적어도 Entire에 회의적인 쪽도 문제 자체는 인정합니다. 논쟁의 중심이 “문제가 있느냐 없느냐”가 아니라 “이 방식이 그 문제를 풀 수 있느냐”에 있다는 점은 꽤 중요한 신호입니다.

그 때문이라도 이 문제, 그리고 Entire AI를 계속 지켜볼 이유는 있다고 생각합니다.

앞으로 바뀌는 건 코딩이 아니라 개발팀의 운영 방식일지 모릅니다

AI 시대의 개발 변화를 이야기할 때, 대부분 가장 먼저 생산성을 떠올립니다. 얼마나 빨라졌는지, 몇 명이 하던 일을 몇 분 만에 끝내는지, 개발자 수요가 앞으로 얼마나 줄어들지 같은 이야기들이죠. 그런데 저는 진짜 변화가 그런데만 있지는 않다고 생각합니다. 오히려 더 크게 바뀌는 건 개발팀이 일하는 방식, 조금 더 정확히 말하면 결과물에 대한 책임을 나누고 신뢰를 쌓는 방식일 가능성이 큽니다. Entire가 처음부터 Git과 연결된 Checkpoints, 팀 가시성, 검색과 복기 같은 주제를 전면에 둔 것도 같은 맥락으로 읽힙니다.

예전에는 코드 작성자와 의사결정자가 거의 같은 사람이었습니다. 누가 만들었는지 알면 왜 그렇게 만들었는지도 대략 따라갈 수 있었죠. 리뷰어도 작성자와 대화하면 빠르게 맥락을 복원할 수 있었고, 인수인계도 “이 부분은 왜 이렇게 구현했는지”를 사람의 기억에 기대어 넘어가는 경우가 많았습니다. 그런데 AI가 깊게 개입하는 순간 이 구조는 달라져야 합니다. 프롬프트를 던진 사람, 중간 결과를 선택한 사람, 최종 머지를 승인한 사람, 이후 운영을 맡는 사람이 서로 달라질 수 있기 때문입니다. 이때부터는 단순히 코드만 남겨서는 책임과 판단을 제대로 설명하기 어려워집니다.

그래서 다시 한 번, 앞으로 중요한 건 “누가 빨리 짰느냐”보다 “누가 설명할 수 있게 남겼느냐”가 될 가능성이 큽니다. AI가 만든 초안을 가져다 쓰는 일 자체는 누구나 할 수 있게 될 것입니다. 하지만 그 결과물을 팀이 이해할 수 있는 형태로 정리하고, 나중에 문제가 생겼을 때 다시 추적할 수 있게 만들고, 리뷰어가 불필요한 추리를 하지 않도록 맥락을 남기는 일은 여전히 사람의 몫입니다. Entire가 제품 차원에서 붙들고 있는 문제도 결국 여기에 있습니다. 코드 생성 경쟁보다, 생성 이후의 기록과 검증, 복기와 감사 가능성에 더 큰 가치를 두고 있는 것이죠.

이 변화는 특히 팀 운영에서 더 크게 다가올 겁니다. 코드 리뷰 방식이 바뀔 수 있고, 온보딩 방식도 달라질 수 있습니다. 예전에는 신입이나 새 팀원이 코드베이스를 읽고 질문하면서 맥락을 익혔다면, 앞으로는 “이 변경이 어떤 세션에서 어떤 판단 끝에 나왔는지”까지 함께 훑는 흐름이 자연스러워질 수 있습니다. 장애 대응도 비슷합니다. 예전에는 커밋 로그와 담당자의 기억을 조합해 원인을 복기했다면, 앞으로는 AI 세션 기록과 결정 흐름까지 함께 보는 방식이 더 익숙해질 수 있죠. 특히 규제 산업과 보안이 중요한 환경에서의 투명성, 팀 단위 검색과 가시성 같은 주제를 반복해서 Entire가 강조하는 이유도 이런 맥락으로 이해할 수 있습니다.

저는 Entire가 정말 이러한 문제의 해답이 될지는 아직 모른다고 생각합니다. 실제 팀 도입과 장기적인 경쟁력은 더 지켜봐야 하니까요. 다만 한 가지는 분명해 보입니다. AI가 코드를 쓰는 시대에 버전 관리의 대상은 더 이상 코드만이 아니라는 점입니다. 그리고 그 변화는 생각보다 훨씬 빠르게, 개발자의 손끝이 아니라 개발팀의 운영 방식부터 바꿔놓게 될지도 모릅니다.

그 아래 살아남는 개발자의 기준도 조금씩 바뀔 것 같습니다. 단순히 AI를 잘 쓰는 사람보다, AI와 함께 만든 결과물을 팀의 자산으로 바꿀 수 있는 사람이 더 중요해질 가능성이 큽니다. 설명할 수 있게 만들고, 협업할 수 있게 만들고, 나중에 다시 꺼내 쓸 수 있게 만드는 능력 말입니다.

]]>

기획부터 실행까지 돕는 크리에이티브 에이전트 ‘Luma AI’

최근 크리에이티브를 돕는 AI 도구는 정말이지 폭발적으로 늘어났습니다. 텍스트 한 줄을 입력하면 이미지가 나오고, 프롬프트 몇 문장이면 거대한 스케일의 영상도 빠르게 제작할 수 있습니다. 물론 딸깍 한 번으로 모든 결과를 만들어낼 순 없지만, 이제는 전문 디자이너나 영상 편집자가 없어도 그럴듯한 비주얼 소재를 만드는 일이 이전보다 훨씬 가깝게 다가온 것이 사실입니다. 하지만, 실제 작업을 진행하다 보면 여전히 해소되지 않는 불편이 존재하는데요.

바로 ‘개별 소재는 빠르게 만들어지는데, 크리에이티브 전체를 조율하는 건 여전히 사람의 몫’이라는 점입니다. 예를 들어, 캠페인 전체의 톤앤매너를 어떻게 일관되게 유지할 것인지, 채널마다 달라야 하는 포맷과 메시지를 누가 정리할 것인지, A/B 테스트용 배리에이션은 어떻게 빠르게 뽑아낼 것인지 등이 포함됩니다.

아무래도 아직까지는 AI 크리에이티브 도구가 '소재 생성'에 집중하고 있을 뿐, 실제 크리에이티브 운영의 핵심인 '기획과 조율'을 충분히 다루지 못하는 경우가 많기 때문입니다. (올해 우리가 집중해서 살펴봐야 할 내용이기도 합니다.)

<출처: Luma AI, 작가 캡처>

오늘 소개할 서비스는 이런 한계를 보완하기 위해 우리가 어떤 접근 방식을 취해야 하는지를 보다 상세히 확인할 수 있는Luma AI입니다. Luma AI는 AI 크리에이티브 에이전트 플랫폼입니다. 별도 앱 설치 없이 웹 브라우저에서 바로 시작할 수 있습니다.

크게 브레인스톰과 생성 모드를 지원하는데요. 두 모드 모두 에이전트가 중심이 되어 대화를 주고받으며, 크리에이티브 작업을 진행할 수 있습니다. 텍스트, 이미지, 영상, 오디오가 하나의 워크플로우로 연결되어 있어, 아이디어를 입력하면 에이전트가 필요한 모달리티를 알아서 선택하고 조율합니다. 사용자는 결과물의 방향에만 집중하면 됩니다.

초기에는 스마트폰 영상과 사진으로 3D 모델을 생성하는 것으로 시작했지만, 현재는 AI 영상 생성 모델 Dream Machine과 에이전트 기반 크리에이티브 협업 도구 Luma Agents를 주요 기능으로 제공하고 있습니다. 자체 생성 모델을 꽤 오래전부터 운영, 에이전트 내에서도 자체 모델을 활용하고 있어, 보다 자연스러운 워크플로우를 경험할 수 있습니다. 이번 글에서 Luma AI의 주요 기능과 사용 팁을 살펴보겠습니다.

주요 기능 살펴보기

서비스에서 새로운 프로젝트를 생성하면, 크게 2가지 모드로 에이전트를 활용할 수 있습니다. 첫 번째는 브레인스톰이며, 두 번째는 생성입니다. 어떤 모드를 선택하든 에이전트와의 대화를 기본으로 하며, 요청하는 내용에 따라 에이전트가 계속해서 질문을 던지기 때문에 간단한 아이디어만 있어도 범위를 좁히고, 아이디어를 구체화하며 작업을 진행할 수 있습니다.

<출처: Luma AI, 작가 캡처>

위 이미지는 브레인스톰 모드를 선택한 뒤, 여름 컬러 티셔츠 콘텐츠 기획에 대한 대화를 주고 받는 모습입니다. 이를 통해 캔버스에 첫 내용이 등록되었는데, 저는 온라인 쇼핑몰에 활용할 콘텐츠를 선택했기에 상세 페이지는 물론, 배너와 룩북, 예상 산출물과 제작 순서 등이 포함된 상세 기획안을 확인할 수 있었습니다.

<출처: Luma AI, 작가 캡처>

선택에 따라 캔버스에 적용되는 내용이 달라지는데요. 저는 기획안을 바탕으로 컬러 팔레트를 먼저 제안해달라고 요청했습니다. 이렇게 무언가 ‘만들기 위한’ 밑그림이 완성되면 브레인스톰 모드를 벗어나 만들기 모드로 자연스럽게 전환이 가능하며, 이는 사용자의 선택에 따라 진행됩니다.

중요한 건 모드의 자유로운 전환도 그렇지만, 이 정도 결과를 확인하기까지 걸린 시간입니다. 3분도 채 걸리지 않았습니다. 게다가 첫 요청 외 모든 과정은 에이전트가 알아서 판단하고, 필요한 선택지를 제공합니다. 제가 한 것은 생성된 결과를 확인하고, 단계별로 어떤 결정을 하면 좋을지 생각하는 것이 전부였죠.

<출처: Luma AI, 작가 캡처>

이제 본격적인 만들기(생성) 모드로 전환된 모습입니다. 앞선 기획안과 컬러 팔레트를 바탕으로 무드보드를 생성한 뒤, 다시 다섯 가지 컬러로 티셔츠 이미지를 만든 모습입니다. 사실, 이런 티셔츠 이미지는 나노바나나는 물론 최근 출시된 GPT 이미지 2.0 정도로도 만들 수 있는데요.

중요한 건 제가 캔버스 하나에서 티셔츠를 뽑아낸 과정입니다. 어떤 의도로, 어떤 분위기에 따라 제가 바라는 티셔츠가 만들어졌는지를 논리적이고 시각적으로 확인할 수 있기 때문입니다. 기본적으로 공유 및 협업 기능을 제공하기에 팀원들과 전체 작업 과정을 빠르게 동기화하고, 의견을 주고받으며 의사결정을 할 수 있는 좋은 환경이 될 수 있습니다. 이 자체가 누군가를 설득하기 위한 좋은 참고 자료가 될 수 있고요.

<출처: Luma AI, 작가 캡처>

또 다른 결과물을 확인할 수 있는 모습입니다. 앞서 생성한 다섯 가지 컬러의 티셔츠 중 일부 컬러를 가상의 모델이 착장한 모습으로 만들었고 티셔츠를 강조, 쇼핑몰에서 활용할 수 있는 메인 배너도 완성했습니다. 상품 상세에 필요한 디테일 클로즈업도 다양하게 뽑아냈습니다. 이후에도 저는 컬러 단위의 서브 배너는 물론 룩북과 그룹 컬러샷, 컬러 스와치 라인업 등 혼자서도 매우 넓고 다양한 범위의 작업을 진행할 수 있었습니다.

물론 디자이너나 실제 크리에이터가 느끼기에는 부족한 수준이라고 생각할 수 있습니다. 조금 더 세부적인 작업이 필요할 수 있겠죠. 그러나 1인 사업을 운영하거나, 과정을 빠르게 훑어보기 위한 목적과 상황이라면, 정말 활용도가 높다고 생각했습니다. 단계별로 확인 가능한 결과/산출물 또한 퀄리티가 일정 수준 보장된다는 장점도 있고요.

<출처: Luma AI, 작가 캡처>

에이전트와 대화 도중, 다른 작업을 요청하는 것 또한 가능합니다. 위 이미지에서 가장 상단 영역을 보면, 영상이 만들어진 모습을 살펴볼 수 있는데요. 제가 티셔츠를 효과적으로 홍보할 수 있는 숏폼 영상 제작을 중간에 요청했고, 이를 바탕으로 에이전트가 3가지 스타일의 쇼츠 영상을 제안해 줬습니다. 그중 제품 자체가 움직이는 감각적인 영상 생성을 원했는데요. 5분 후 여섯 개의 영상을 확인할 수 있었습니다.

영상 자체도 마음에 들었는데, 일련의 작업 과정이 이미 존재하고 그 과정에서 만들어진 결과들을 다른 콘텐츠 제작에 지속적으로 활용할 수 있다는 점이 좋았습니다. 만약 제가 티셔츠 이미지를 몇 장 가지고 유사한 영상을 만들어야 했다면, 영상 제작이 가능한 AI 서비스를 찾고 학습하는 과정이 필요했을 겁니다. 또 추가로 결제가 필요한 상황도 생길 수 있으니, 한곳에서 맥락을 유지한 채 다양한 결과를 뽑아낼 수 있다는 점이 좋았습니다.

<출처: Luma AI, 작가 캡처>

Luma AI는 디스커버 메뉴를 통해 다른 사용자들이 작업 후 공개한 프로젝트를 제공합니다. 단순히 이미지나 영상을 생성하는 작업이 아니라, 맥락과 배경이 탄탄한 프로젝트들이 많습니다. 시작 전 한 번씩 둘러보면, 어떤 식으로 작업하면 좋을지에 팁을 얻을 수 있습니다. 카테고리만 봐도 알 수 있듯, 정말 다양한 형태의 크리에이티브 작업이 이뤄지는 편입니다.

한 번은 꼭 써봐야 하는 이유

크리에이티브와 관련된 작업을 꽤 넓은 범위까지 커버한다는 점이 가장 큰 매력이라고 생각합니다. 브레인스토밍을 거쳐 몇 가지 시안을 던져주는 수준이 아니라, 사용자가 요청한 작업을 기획부터 실제 결과까지 만들어낼 수 있습니다. 결과 역시 패션 아이템, 배너, 상세 페이지 구성, 디테일 샷, 스타일링컷 등 맥락에 따라, 자유롭게 확인하고 수정할 수 있고요.

<출처: Luma AI, 작가 캡처>

캔버스 내에서는 개별적인 영상, 이미지, 오디오 생성 기능을 지원하며 메모나 섹션 생성 등 개인 작업과 협업을 위한 기능까지 제공하고 있어 에이전트 외 환경도 충분히 고려한 느낌이 들었습니다. 또 에이전트와의 대화의 끝은 늘 다음 작업에 대한 제안과 추천이 떠서, 무엇을 어떻게 진행해야 하는지 안내해 주는 게 많은 도움이 됐습니다.

물론 아쉬운 점이 없는 건 아닙니다. 아무래도 노드 기반의 상관관계를 따져가며 유사한 서비스를 사용했던 터라, 캔버스에 대화를 바탕으로 결과를 하나씩 띄워주는 방식이 조금 낯설게 다가왔는데요. 이건 적응의 문제일 수 있고, 최근에는 서비스들이 이런 방향으로 전환 중인 걸 알고 있습니다. 다만 최소한 각 결과가 어떻게 연결됐고, 어떤 맥락을 갖고 있는지를 조금 더 시각적으로 안내해 주면 좋겠다는 생각이 들었습니다.

모든 결과가 선으로 연결되는 것까진 필요 없지만, 이 영상은 이전의 이런 이미지를 바탕으로 생성되었다던가, 이 이미지는 이런 리서치를 바탕으로 만들어졌다거나 하는 안내가 제공되면, 협업의 관점에서 특히 배경을 파악하는 데 도움이 될 거라 생각합니다.

<출처: Luma AI, 작가 캡처>

Luma AI는 무료로 일정 크레딧을 활용한 사용이 가능합니다. 저도 오늘 소개한 내용들을 모두 무료 계정 기준으로 진행했습니다. 크레딧을 모두 소모한 뒤에는 연 결제 기준 월 25달러에 플러스 계정을 활용할 수 있으며, 75달러 기준 프로 계정과 250달러 기준 울트라 계정을 활용할 수 있습니다. 처음에는 무료 버전으로 충분히 테스트해본 뒤, 활용 빈도와 작업 규모에 맞춰 검토해 보셔도 좋겠습니다.

<참고>

https://lumalabs.ai/app

]]>

두 달 꼬박 기업용 에이전트 만들며 배운 것: 콘텐츠 AX 실험기 ③

콘텐츠 AX 실험기 ① 12분 49초 만에 한 달치 기획이 나왔다
콘텐츠 AX 실험기 ② 콘텐츠 AX, '프롬프트' 말고 '파일'을 보세요
콘텐츠 AX 실험기 ③ 두 달 꼬박 기업용 에이전트 만들며 배운 것: (현재 글)

4월 17일 금요일 저녁 7시, 기업 블로그 에이전트에 관심 있는 현업 콘텐츠 담당자, 마케터, 기획자, 개발자, 리더 분들이 한자리에 모였습니다. 요즘IT가 두 달 동안 만든 블로그 에이전트 파이프라인을 처음으로 외부에 공개하는 자리였거든요.

기업 블로그에 쓸 콘텐츠의 기획부터 생성까지 이어지는 파이프라인, 그 개발 과정에서의 시행착오와 현실적인 조언들, 그리고 아직 풀지 못한 한계들을 모두 공개했습니다. 시작부터 끝까지 한 시간이면 될 거라 생각했는데, 경험과 시행착오를 전부 꾹꾹 눌러 담다 보니 발표만 50분이었고, 구체적이고 다양한 질문도 계속 이어져 질의응답만 35분을 더 했습니다. 그만큼 밀도 높은 시간이었습니다.

후기에서 누군가는 “현업에서 겪은 시행착오와 그 과정에서 얻은 지식을 아낌없이 공유하는 대인배 세미나"라고 평하기도 했습니다. 다른 분들도 이렇게 표현해주셨습니다.

"본질에 다시 집중하게 된 계기."
"서비스 도입 사례로 시작했는데 업무의 본질까지 터치한 양질의 세미나."
“회사에서 어떻게 적용할지 고민이 많았는데, 방향이 잡혔어요”
“경험자가 풀어주는 콘텐츠 에이전트 구축 찐후기”

후기를 남겨주신 분 중 92%가 만족했던 그날의 이야기를 정리해, 자리에 함께하지 못하셨던 분들께도 전해드리려 합니다.

기업을 위한 블로그 에이전트 파이프라인

요즘IT는 지난 2026년 2월부터 기업 블로그용 콘텐츠를 기획하고 생성하는 에이전트를 만들어보는 실험을 시작했습니다. 4년 넘게 콘텐츠 플랫폼을 운영해온 콘텐츠 전문성과 요즘IT의 운영사인 위시켓의 기업 데이터, IT 매거진으로서 확보한 에이전트 관련 지식을 결합하면 ‘기업 블로그 에이전트’를 만들어볼 수 있겠다 싶었기 때문입니다. 변수가 많은 매거진의 콘텐츠보다는 정형화된 형식으로 만들 수 있는 기업 블로그 자동화가 더 쉽게 도전할 영역이라고 생각했고요. (물론 이는 잘못된 생각이었습니다)

이 파이프라인을 직접 만든 것은 요즘IT 팀원으로, 그로스파트 리드 장대청입니다. 그는 문예창작을 전공했고, 흔히들 말하는 ‘문과 직무’만 겪어왔죠. 그렇게 개발자가 아닌 도메인 전문가의 입장에서 에이전트를 만들어보는 것도 의미가 있을 것 같았습니다.

에이전트 파이프라인 데모

결론부터 말하면, 저희가 만든 건 담당자가 ‘조금만 고치면 쓸만한 초안’을 만드는 에이전트를 만들었습니다. 이 초안이 나오기 위해 필요한 건 진짜로 버튼 몇 개와 판단 몇 개뿐입니다. 실제로 요즘IT가 만든 파이프라인의 데모를 살짝 보여드리겠습니다. 아래 링크를 통해 보시면 더 이해가 쉽습니다.

파이프라인은 담당자가 “위시켓 블로그를 찾아올 만한 독자가 던질 법한 질문 하나”를 Slack 봇에게 던지는 것에서 출발합니다. 물론 단순해 보이는 이 입력 구조도 다양한 고민 끝에 나왔습니다. 콘텐츠의 주제, 방향, 목적, 그리고 독자가 누구인지를 담을 입력을 찾다 발견한 구성이죠.

위시켓은 IT 외주가 필요한 사람과 이를 개발할 수 있는 사람들을 연결하는 플랫폼인데요, 따라서 데모에서는 그러한 고객들을 고려해 “사내에 개발자가 없는 중소기업인데, 사업에 필요한 웹서비스를 외주로 만들려면 어디서부터 시작해야 하나요?”라는 질문을 던졌습니다.

요즘IT 기업 블로그 에이전트 시작 화면

약 15분 가량이 지나면 Slack 스레드에 응답과 함께 전략 보고서가 도착합니다.

URL로 어디서나 접근할 수 있는 이 전략 보고서에는 세 가지 탭으로 이뤄지는데, 각 탭에는 아래 내용이 나옵니다.

첫째, 리서치 결과: 입력한 질문에서 뽑아낸 키워드를 바탕으로 한 네이버와 구글 검색 결과, 검색량과 연관 키워드, 그리고 실제 ChatGPT·Claude·Gemini가 같은 질문에 어떻게 답했는지 정리한 GEO/SEO 전략
둘째, 컨텍스트: AI가 글을 쓸 때 참고할 회사·시장·고객 정보가 정리된 가드레일
셋째, 콘텐츠 기획안: 독자 페르소나와 그 독자가 단계별로 무엇을 궁금해하고 어떤 흐름으로 답을 찾아가는지가 정리된 유저 저니맵 형식의 기획안

요즘IT 기업 블로그 에이전트로 만든전략 보고서

이 전략 보고서 초안을 보고 마음에 들지 않는 부분이 있다면 Slack 스레드에서 그대로 수정 요청을 하고, 수정할 것이 없다면 승인을 합니다.

사람의 승인이 떨어져야만, 담당 에이전트가 글쓰기에 착수합니다. 그렇게 만들어진 결과물은 메인 콘텐츠 1편과 서브 콘텐츠 3편, 총 4편의 초안입니다.

글은 일반적인 기업 블로그와 똑같은 구조입니다. H2/H3 구조를 지키며, 본문에는 내용 이해를 도울 표, 체크리스트, 인용 박스가 들어 있습니다. 글의 흐름과 이어지는 CTA 배너, 사고 흐름을 돕는 FAQ까지 들어가 있습니다.

그뿐만이 아닙니다. 위시켓이 사용하는 CMS인 Webflow에 그대로 붙여 넣을 수 있도록 메타데이터와 HTML 임베드 코드, 그리고 GEO 대응을 위한 JSON-LD 구조화 데이터까지 함께 출력됩니다.

요즘IT 기업 블로그 에이전트로 만들어진 글

Slack에 질문 하나를 던진 것뿐인데, 한 시간여 만에 네 편의 초안과 발행에 필요한 거의 모든 자료가 준비된 것입니다.

에이전트 파이프라인 구조

이 결과물을 만든 파이프라인 구조는 다음과 같습니다.

요즘IT 기업 블로그 에이전트 파이프라인 구조

이 파이프라인은 하나의 에이전트가 아닌, 리서처, 컨텍스트 빌더, 저니맵, 라이터, 어셈블러, 이렇게 총 5개의 에이전트로 구성되어 있습니다. (각각의 에이전트가 어떤 순서로 어떤 일을 하는지, 왜 이렇게 구성하게 되었는지, 만들면서 알게 된 것들은 무엇인지는 웨비나에서 소개합니다.)

꽤 괜찮은 파이프라인과 결과라고 생각하지만, 지금 시점에는 이 결과 자체가 중요한 건 아니라고 느꼈습니다. 더 중요한 건 그 결과물에 도달하기까지 8주간 일하며 겪어온 생생한 시행착오와 한계였습니다. 요즘 흔히 말하듯 “‘딸깍’하면 이렇게 나옵니다!”가 아니라 일상의 업무를 위한 에이전트를 만들 때 고려해야 할 것들, 특히 더 신경써야 할 것들, 만드는 과정에서 부딪히는 현실의 문제들을 더 중요하게 다루고자 했습니다.

가장 강조하고 싶은 건 하나입니다. AI한테 잘 시키려면, 내 일을 ‘분해’할 줄 알아야 한다는 것이었죠.

"에이전트를 만드는 작업이라는 게, 코드를 짜는 게 아니었습니다. 우리가 하는 일을 분해해서 글로 쓰는 것 그 자체였어요."

우리가 하는 일의 과정부터 그렇게 해서 얻고자 하는 결과까지, ‘일의 본질’을 낱낱이 분해할 수 있어야 에이전트의 성능이 더 올라간다는 사실, 하지만 그 분해가 그렇게 쉽지만은 않다는 것. 이 메시지가 더 중요한 부분이었습니다.

블로그 에이전트를 만들 때 가장 중요한 3가지

웨비나가 끝나고 후기 설문에서 "가장 도움이 된 부분"을 물었습니다. 응답을 모아보니 두 항목이 압도적이었습니다. 파이프라인 전체 구조, 그리고 시행착오와 해결 과정. 이 두 키워드가 거의 모든 응답에 등장했습니다. 이 키워드가 가장 잘 드러난 내용을 정리하니, 3가지 포인트가 나왔습니다. 실제로 모두 "어떻게 일을 분해할 것인가"에 대한 답의 일부이기도 합니다.

1. 에이전트 구조를 3번 갈아엎으며 배운 것

처음에는 에이전트 하나에 모든 일을 맡겼습니다. 리서치도, 기획도, 글쓰기도, 검수까지도. 다만, 지금의 에이전트는 역할이 복잡해질수록 멍청해집니다. 그래서 단순한 일을 시키기 위해 에이전트를 여러 개로 분리했죠. 첫 번째 전환이었고요.

에이전트를 늘렸는데도, 여전히 결과물은 아쉬웠습니다. 그럴 때마다 에이전트가 지켜야 할 규칙을 추가했습니다. "톤은 이렇게 잡아라", "구조는 이렇게 짜라". 규칙이 늘어날수록 에이전트는 그 규칙을 위반하지 않는 것에 모든 힘을 기울였습니다. 그러니 규칙을 위반하지는 않는 글이 나왔는데요, 좋은 글은 아니었습니다. 그렇게 위시켓 콘텐츠 마케터에게 결국 "이건 고쳐서도 못 쓸 것 같아요. 처음부터 제가 하는 게 나아요"라는 피드백을 받았죠. 여기까지 걸린 시간이 4주였습니다.

포기할까 하다가, 처음으로 돌아가 다시 물었습니다. "기업은 콘텐츠를 왜 만들까?" 답은 이랬습니다. “고객에게 우리가 전하고자 하는 바를 전달해서, 알게 하고, 고려하게 하고, 선택하게 하기 위해서.” 이 정의에서 출발해 일을 다시 분해했습니다. 분해 과정에서는 3가지 질문을 던졌습니다. 누구를 위해, 무엇을 줄 수 있는가, 어떻게 전달하는가. 이 질문의 끝에서 5개의 에이전트 구조가 자연스럽게 나왔습니다.

특히, 이 분해 과정에서 발견한 흥미로운 도구는 ‘유저 저니맵’입니다. 프로덕트 팀이 사용자 흐름을 설계할 때 쓰는 그 저니맵을 콘텐츠 기획에 그대로 끌어왔습니다. 기존에는 이 단계에서 마케팅 퍼널을 중심으로 적용했는데, 한계가 있다고 생각한 겁니다.

이제 사람들은 정보를 AI한테서 얻고는 합니다. 가장 먼저 나의 상황에 기반한 질문을 던져 검색의 선택지를 좁히죠. 그 선택지 안에 들지 못하면 후보에 들기조차 어렵습니다. 고객에게 우리가 전하고자 하는 바를 전하려면, 우선 그 답변 안에 들어야 합니다. 당연히 가장 먼저 고려해야 하는 것은 사용자의 상황과 그에 따른 질문 흐름입니다. 고객이 취하는 행동 단위로 정의된 마케팅 퍼널은 이러한 상황과 의도를 잡기 어려웠습니다. 그래서 더 세밀하게 사용자 흐름을 정의한 저니맵을 가져왔습니다. 그 덕분에 훨씬 자연스러운 맥락이 나왔죠.

2. 헤밍웨이가 원고를 100번 고쳤다는 말에서 시작된 3-pass 구조

기획을 받아 실제로 글을 쓰는 라이터 에이전트는 한 번에 글을 완성하지 않습니다. 세 번에 나눠 씁니다. 1pass에서는 구성을 잡아 초안을 쓰고, 2pass에서는 처음부터 다시 쓰되 데이터를 더 단단히 채우고, 3pass에서는 또 한 번 처음부터 다시 쓰되, 톤을 가다듬습니다. 핵심은 부분별로 수정하는 것이 아니라 앞선 글을 참조하되, 매번 새로 쓰며, 그때마다 다른 관점으로 쓰는 방식입니다.

이 구조는 다른 사람이 만든 에이전트 레퍼런스나 어떤 프로그램의 코드에서 온 것이 아닙니다. 에이전트를 만든 장대청 리드의 글쓰기 경험에서 출발한 구조입니다.

"헤밍웨이가 원고를 100번씩 고쳤다는 말이 있어요. 저도 이전에 글을 쓸 때는 매번 퇴고만 30번씩은 했거든요. 돌이켜 보니 그때도 통째로 잡고 앉아서 처음부터 다시 읽으며 썼어요. 특정 부분마다 훑어보며 쓰지 않고요. 대신 이번에는 어떤 관점으로 보자, 어떤 매체로 보자, 그렇게 컨셉만 바꿔가면서 했죠."

처음부터 이런 방식을 떠올린 건 아닙니다. 흔히 자료에서 찾아볼 수 있는 방식대로 리뷰 에이전트를 만들어 완성된 글에 점수를 매기게도 해봤습니다. 작동이 쉽지 않아 오류를 지적하는 에이전트를 만들고, 그렇게 지적받은 특정 부분만 골라 수정하게도 해봤습니다.

모두 만족스럽지 않았습니다. 결국 사람이 글을 다듬는 방식으로 돌아갔고, 기억을 살려 통째로 다시 쓰는 방식을 적용했습니다. 가장 나은 결과가 나오더군요. 이처럼 사람이 하는 작업을 정교하게 분해해서 옮겨놓는 게, 어떤 평가 시스템을 만들어 붙이는 것보다 효과가 좋다는 걸 두 달 사이 여러 번 확인했습니다.

3. 마크다운 파일로 검수받지 않는 이유

사실 에이전트가 만든 글은 마크다운(.md) 형식으로 출력됩니다. 처음에는 그 .md 파일을 그대로 동료에게 넘겨 피드백을 받았습니다. 그런데 묘한 일이 벌어졌습니다.

피드백을 요청받은 마케터가 그 파일을 그대로 클로드에 넣은 겁니다. ‘비판적으로 검토해달라’는 프롬프트와 함께요. 그렇게 나온 결과물의 95% 정도가 본인의 의견과 비슷하다고 피드백했습니다. 그 순간 이런 생각이 들었습니다. ‘이건 결국 내 클로드와 동료의 클로드가 의견을 주고 받는 게 아닌가?’

그래서 검수 환경을 다시 손봤습니다 .md 파일을 보여주는 대신, 위시켓 블로그에 실제로 발행되는 화면과 거의 똑같이 생긴 환경에서 글을 보게 만들었습니다. 표는 표대로, CTA 배너는 배너대로, 본문 폰트와 단락 간격까지 실제 발행 환경 그대로요.

사람은 글을 이해할 때 글자만 보지 않습니다. 단락의 크기, 줄 간격, 폰트, UI 구성에 따라 같은 내용도 다르게 인지합니다.

그리고 무엇보다, 결과가 실물로 존재할 때 사람은 책임감을 느낍니다. 그래서 마크다운 파일이 아니라 실제 발행 화면 위에서 글을 검토할 때 비로소, 사람이 자기 이름을 걸고 그 작업물을 관리한다는 감각이 생긴다고 가정했습니다. 이런 가정으로 파이프라인에서는 사람이 작업을 시작하는 ‘입구’와 ‘출구’, 마지막으로 사람이 개입할 지점을 신경 써서 디자인했습니다. 결국 나 혼자 쓸 파이프라인이 아니라 동료와 함께 쓰는 파이프라인이기 때문입니다.

왼쪽은 요즘IT 기업 블로그 에이전트가 만든 글의 출력 화면, 오른쪽은 위시켓 블로그 화면

블로그 에이전트로 끝까지 풀지 못한 것

이렇게 해서 ‘딸깍’하면 만족할 만한 글이 나오는 완벽한 파이프라인이 나왔다면 좋았겠지만, 그런 건 없었습니다. 여전히 풀지 못한 것이 많았고, 그건 혼자서는 풀 수 없는 일이었습니다. 한계는 두 가지였습니다.

도메인 지식이라는 천장

위시켓이 다루는 IT 아웃소싱 시장에는 단순한 정보로 환원되지 않는 미묘한 결이 있습니다.

예를 들어, 이런 외주 프로젝트에서 비용은 가장 많이 검색되는 주제이고, 의사결정의 큰 축이 됩니다. 그러나 실제 현장에서 오로지 비용만으로 의사결정을 내리면 프로젝트가 제대로 가기 어렵다고들 말합니다. 게다가 비용은 클레임이 나오는 가장 강력한 원인이 되기도 하죠. 그렇다고 사람들이 가장 궁금해 하는 정보를 무시할 수는 없습니다. 그러니 사례 기반으로 정보를 주면서도 균형은 갖추는 방향으로, 기업 블로그에서 매우 조심스럽게 다뤄야 합니다.

이런 미묘한 균형을 정확히 분해해서 알려주지 않으면 AI는 그대로 길을 잃습니다. 검색에서 가장 많이 나오는 정보인 ‘비용’을 그대로 기준으로 삼아 쓰기 마련이니까요. 두 달 동안 가이드 문서를 다듬어왔지만, 이 균형을 완전히 담아내지는 못했다고 느낍니다.

이에 실패한 가장 큰 이유는 에이전트를 만든 사람이 아웃소싱 시장을 모조리 이해하지 못하기 때문입니다. 위시켓 매니저들이 몇 만 건 넘는 프로젝트를 직접 연결하며 쌓은 지식은 그들의 머릿속에 있습니다. 그러니 이 분해 작업은 결국 한 사람의 머리에서 나올 수 있는 게 아닙니다. 마케팅, 영업, 운영, 고객지원처럼 여러 부서에 흩어져 있는 도메인 지식이 체계적으로 정리되어야 하는, 개인의 작업이 아니라 조직의 작업이었죠. 콘텐츠뿐만 아니라 모든 AX의 진짜 천장은 모델 성능이 아니라 이 ‘조직 차원의 도메인 지식 정리’에 있다는 것이 가장 크게 배운 것입니다.

AI 글쓰기 자체의 한계

이 한계를 얘기하기 전에, 발표 후반부에 참가자 분들에게 물은 질문을 그대로 다시 던져보겠습니다.

"아래 두 문단, 어떤 게 AI가 쓴 것 같나요?"

어떤 게 AI가 쓴 것 같나요?

위의 글은 사람이 AI의 도움을 받아 쓴 것, 아래 글은 AI 에이전트가 쓴 날것 그대로입니다. 채팅창에는 “모두 AI다”, “1번이 AI다”, “2번이 AI다” 같은 답이 모두 비등하게 올라왔습니다.

저희는 콘텐츠를 오랫동안 만들어 온 사람들입니다. 그러니 “이 글이 이상하다” 같은 생각은 합니다. 다만 AI가 쓴 글에서 ‘정확히 무엇이 부족한가’를 손가락으로 짚어 말하기는 어렵습니다. 특히 한글은 영어와 흐름과 사용 구조가 꽤 다른 탓에, 해외에 알려진 정보를 그대로 쓰기도 어려웠습니다. 에이전트를 직접 구축한 장대청 리드도 AI가 생성한 글을 500개 정도 읽고 나서야 패턴을 더듬더듬 짚어볼 수 있었다고 합니다.

결국 내린 결론은 이런 영역은 사람이 마지막에 손을 대야 한다는 겁니다. 그리고 그 ‘마지막 작업’이 만들어내는 차이는 한동안 사라지지 않을 것 같습니다. 저희가 만든 파이프라인이 콘텐츠 마케터를 대체하는 도구가 아니라, 그분들이 더 본질적인 일에 집중할 수 있도록 돕는 도구라고 얘기하는 이유이기도 합니다.

블로그 에이전트 웨비나 다시보기

웨비나 발표와 Q&A를 녹화한 다시보기 영상, 발표에 사용한 슬라이드 PDF를 함께 다시 정리했습니다.

이 글에 다 풀어내지 못한 디테일이 많습니다. 정확히 무엇을 시도하고 무엇을 버렸는지, 5개의 에이전트의 동작은 어떠하며 각각 어떤 컨텍스트를 참고하는지, 도메인 지식을 분해하며 부딪힌 진짜 문제들까지.

이런 분께 권합니다

콘텐츠 AX 시리즈 1편과 2편을 읽고 "구체적으로 어떻게 시작해야 할지" 막연했던 분이라면, 이번 다시보기가 그 막연함을 꽤 좁혀줄 듯합니다. 팀에 콘텐츠 자동화를 제안해야 하는데 근거가 필요한 분, 비개발자가 만든 에이전트의 가능성과 한계를 한 번에 검증해보고 싶은 분들에게도 도움이 됩니다.

다만 이 영상이 처음부터 끝까지 따라할 수 있는 단계별 매뉴얼은 아닙니다. 이 한 시간 반짜리 웨비나는 두 달 사이 요즘IT가 부딪힌 질문들을 함께 따라가는 자리에 가깝습니다.

더 자세한 추천 대상과 구성, 가격은 아래 페이지에서 확인하실 수 있습니다.

장대청 리드가 발표를 시작하면서 한 말이 있습니다.

"AI의 가능성만 얘기하면 과대광고, 한계만 얘기하면 의미가 없다."

이번 웨비나는 AX라는 거대한 흐름 아래에서 살아남으려고 노력한 그 솔직한 좌표를 남기는 일이었습니다. 모든 질문에 대한 답을 드리지도 못했고, 후기에 적힌 어떤 분의 표현처럼 아직도 "공부를 더 하고 와야 알아들을" 부분도 있을 지 모릅니다.

하지만 한 가지는 분명합니다. 에이전트를 만드는 작업은 우리를 ‘분해’하는 작업이라는 겁니다. 그 분해 과정이 복잡하지 않다면 충분히 나누지 않았는지 고민해야 합니다. 그간 사람이 쌓아온 시간은 결코 작지 않으니까요. 그럼에도 이를 나눌 수만 있다면, 말 그대로 정말 뛰어난 생산성을 얻을 수 있다는 확신도 함께 생겼습니다.

앞으로도 요즘IT는 우리 스스로를 분해해 AI에게 일을 시키는 실험을 계속 해나갈 것입니다. 콘텐츠 기획부터 생성, 매거진과 SNS 운영까지 이어질 AX 이야기를 공유드리도록 하겠습니다. 기대해 주세요!

다시보기 + 발표 슬라이드 PDF 보기 →

]]>

AX 한다면서 왜 다들 그대로 일할까?

국내 IT 기업은 한국을 넘어 세계를 무대로 할 정도로 뛰어난 기술과 아이디어를 자랑합니다. 이들은 기업 블로그를 통해 이러한 정보를 공개하고 있습니다. 요즘IT는 각 기업의 특색 있고 유익한 콘텐츠를 소개하는 시리즈를 준비했습니다. 이들은 어떻게 사고하고, 어떤 방식으로 일하고 있을까요?

이번 글은 사용자 데이터를 통해 디지털 프로덕트와 서비스 전략을 설계하는 ‘pxd’에서 AX의 진정한 의미에 대해 소개합니다.

하루가 다르게 발전하는 AI, 모든 조직이 빠르게 도입해서 업무 효율을 높이고 싶어 합니다. 구성원들도 기대가 크겠죠. 그런데 AI의 성능과 별개로 사용 경험에 대한 반응이 시큰둥합니다. 왜 그럴까요?

너 자신을 알라

세상에 다시 없을 너무나 훌륭한 성분의 화장품이 있다고 칩시다. 상당히 높은 가격입니다. ‘최근 푸석해진 내 피부를 아기 피부처럼 되살려 주겠지’라는 기대로 발라 봤는데… 어라? 반응이 없습니다. 트러블도 생깁니다. 그 좋은 성분들은 딱히 힘을 발휘하지 못했습니다. 내 피부 상태를 제대로 알고 필요한 성분의 화장품을 발랐더라면 적어도 트러블은 없었겠죠.

조직에 AI를 도입할 때도 마찬가지입니다. 화장품을 고를 때 내 피부 상태를 잘 알아야 하듯이, AI를 도입하기 위해서는 조직을 잘 알고 이해하는 것이 중요합니다. 그래서 2500년 전부터 소크라테스가 ‘너 자신을 알라’라고 강조했었죠.

AI를 도입하는 것에 앞서 우리 조직이 어떻게 일하고 있는지 알아야 조직의 니즈에 찰떡같은 도움이 된다는 말입니다. 그럼, 무엇을 어떻게 알아야 할까요?

사람들은 어떻게 일하고 있을까?

여러분이 새로운 조직에 합류했을 때를 떠올려 보세요. 어떤 업무를 하게 될지, 어떤 사람들과 같이 일하게 될지, 또 여기서는 어떤 방식으로 일하는 분위기인지 빠르게 파악해야 합니다. 그 조직의 언어와 리듬을 익히는 게 중요하다는 것을 본능적으로 알고 있기 때문이에요.

최근 진행한 몇몇 프로젝트를 기반으로 AI가 우리 조직의 구성원과 시너지를 내기 위해서 무엇을 알려주면 좋을지, 크게 4가지 주제로 정리해 보려고 합니다.

AI와 시너지를 내기 위해 알아야 할 4가지 주제

1. 어떤 업무인가

우리 조직에서 하는 업무가 무엇인지, 업무의 결과는 주로 어떤 유형인지, 그 업무를 하려면 어떤 방식으로 접근하는 게 좋은지 알아야 합니다.

1.1 업무 구조 (구조적인가 Structured ↔ 비구조적인가 Unstructured)

우리 업무는 명확한 규칙을 기반으로 진행되는지, 다양한 해석이 중요한지 살펴보세요. 명확한 답이 필요한데 AI가 본인의 해석을 자꾸 덧붙이거나, 다양한 관점을 알고 싶은데 AI는 자꾸 결론을 제시하고자 한다면 서로 일을 잘하고 있다는 느낌을 받지 못할 것입니다.

스스로 몇가지 질문을 던져 보세요. 우리 업무는,

명확한 절차나 규칙에 따라 반복적으로 수행되는가?
표준화된 입력(양식, 템플릿, 데이터 포맷 등)이 존재하는가?
업무가 상황에 따라 다른 형태로 진행되는가?
업무 결과의 품질 기준이 명확히 정의되어 있는가?
아니면, 주관적인 평가가 가능한가?

AI는 구조화된 업무는 에이전트로 자동화하여 업무 속도를 높이고, 비구조적 업무(디자인, 기획 등)에는 추론 모델을 강화하여 해석이나 판단의 품질을 높이는데 도움을 줄 수 있습니다.

1.2 업무 결과 (예상 가능한가 Predictable ↔︎ 예상하기 힘든가 Uncertain)

우리 업무의 결과물은 얼마나 예측 가능한 형태인가요? 예를 들어, 비용 정산과 같은 예측 가능한 업무 프로세스는 AI가 패턴을 학습해 스스로 결과를 도출하기 쉽습니다. 반면, 위기 대응이나 협상과 같은 일은 상황에 따라 크게 달라지기 때문에 AI는 결과물까지 가는 과정에서 도움을 많이 주는 게 효과적일 수 있습니다.

이런 질문을 해볼 수 있어요.

업무가 일정한 패턴을 따르는가?
업무 중 실수나 실패할 때 즉각적으로 수정이 가능한가?
업무 중 실수나 실패할 때 연결되어 있는 업무가 많은가?
상황이나 외부 변수에 따라 결과가 달라지는가?

예상 가능한 업무에서 AI는 빠른 실행, 오차 최소화와 같은 방식으로 업무를 돕고, 예상하기 힘든 업무에서 AI는 다양한 시나리오 분석, 비교, 인사이트 제공 등 주도적으로 아이디어를 도출하게 하여 의사결정을 도와야 합니다.

2. 어떻게 이야기를 나누는가

어떤 일을 하는지 알았다면, 어떤 스타일로 커뮤니케이션하는지 알아야 합니다. 자세하고 디테일을 살려서 공유하는 조직 문화와, 요점만 간단히 공유하는 조직 문화에서 구사하는 언어 스타일은 다를테니까요.

2.1 협업 방식 (공동 작업을 주로 하는지 Collaborative ↔ 개인 작업을 주로 하는지 Individual)

업무를 할 때 동료와의 협업이 중요한지, 혼자 업무를 진행하는지에 따라서도 AI의 역할이 달라질 수 있습니다.

우리는 일할 때 동료 의존도가 높은가?
우리 업무는 부서 간 협력이 잦고 중요한가?
의사 결정 과정에 여러 사람이 참여하는가?

AI는 업무를 하다가 커뮤니케이션이 필요한 시점을 추천하는 등 원활한 협업을 도와줄 수 있습니다. 반대로 개인의 업무 히스토리나 업무 맥락을 깊이 있게 관리하여 개인 작업을 지원할 수도 있습니다.

2.2 조직의 언어 (통일된 Shared ↔ 다양한 Divergent)

조직에서 자주 사용하는 용어, 약어도 빠르게 학습해야 이질감 없는 커뮤니케이션을 할 수 있습니다. 예를 들어 "인사이트"도 회사마다 의미하는 바가 다른 것 처럼요. AI가 이런 맥락을 제대로 이해하지 못하면 엉뚱한 답변을 내놓게 됩니다.

한번 자세히 들여다 봅시다.

우리 조직에서 쓰는 용어는 어떤 것들이 있는가?
우리 조직의 언어는 어떤 톤앤 매너를 가졌는가?
문서, 회의, 보고 등에서 표현 방식이 표준화되어 있는가?

더 나아가 임원, 팀원, 외부 고객, 유관 부서 등 대상에 따른 말투(톤 앤 매너), 전문성 수준, 워딩의 차이를 AI가 반영하여 커뮤니케이션을 지원할 수도 있습니다. 예를 들면, “상무님이 검토할 예정인데 상무님 기준에 맞춰 검토해 줘.”와 같이 말이에요.

결국 조직의 고유 용어와 다양한 표현 방식을 학습해야 맥락에 맞는 자연스러운 커뮤니케이션을 할 수 있어 업무를 좀 더 명확하고 자연스럽게 도울 수 있습니다.

3. 어떤 정보를 학습하는가?

조직에 따라 업무에 필요한 정보와 학습해야 할 내용도 다릅니다. 또, 조직에 따라 더 신뢰하는 소스가 존재하기도 합니다. 팀에 합류했을 이런 내용을 잘 몰랐다면 혼자 엉뚱한 곳에서 에너지를 쏟을 가능성이 있습니다.

3.1 정보 소스 (내부 정보 Internal ↔︎ 외부 정보 External)

어떤 업무는 조직 내부에 아카이브된 정보를 참고하는 것으로 충분합니다. 그렇다면 잘 쌓인 데이터를 AI가 학습하여 정확하게 제공하는 것이 중요할 것입니다. 어떤 업무는 외부 정보를 다양하게 찾아봐야 합니다. 이때 AI는 최대한 다양하고 신뢰 있는 정보를 찾아야 업무에 도움이 될 것입니다.

아래 질문에 답을 해 보면 됩니다.

업무에서 특정 문서(사내 DB, 사내 보고서, 특정 기관 자료)를 참고하는가, 다양한 외부 자료를 참고하는가?
내부 정보가 잘 정제되어 축적되어 있는가?

AI는 내부 정보는 오차 없이 참조할 수 있도록 하고, 쌓이는 정보와 쓰이는 정보 사이의 피드백 루프가 원활하게 돌아가도록 지원해야 합니다. 외부 정보는 최신의 다양한 그러나 신뢰도 높은 정보를 탐색할 수 있도록 지원해야 합니다.

3.2 지식 유형 (명시적인 Explicit ↔ 암묵적인 Tacit)

조직에는 일반적인 정보와 함께 조직만이 가진 찐 지식이 따로 있죠. 우리 조직의 진짜 알짜 지식을 AI가 학습하게 하는 것이 중요합니다. 잘 정리되어 클라우드에 존재할 수도, 아니면 능숙한 동료의 머릿속에 있을 수도 있습니다. 우리 팀을 관찰해 봅시다.

조직의 찐 지식을 알기 위해서는,

누군가에게 물어봐야 하는가? 즉, 찐 지식은 비공식 네트워크에 존재하는가?
조직 내 암묵지나 약어, 관행이 많은가?
개인의 노하우나 경험이 중요하게 작용하는가?

AI는 문서화된 명시적 정보 뿐만 아니라 사례, 관행 같은 암묵지까지 학습해, 실제 업무 맥락에 가장 적합한 결과 제공할 수 있어야 합니다. 암묵지가 정보화될 수 있는 경험을 설계하는 것도 중요할 것입니다.

4. 어떤 속도로 일하는가?

4.1 업무 병목 구간 (Bottlenecks)

일을 하다가 왠지 모르게 진척이 더딘 부분은 어디인가요? 업무의 비효율은 어디에서 나올까요? 반복적으로 오류가 나거나 지연되는 구간을 파악해 봅시다.

업무 과정을 돌이켜 본다면,

가장 시간이 많이 걸리는 단계는 어디인가?
오류가 자주 발생하는 구간은?
병목 상황이 특정 사람이나 상황에서 발생하는가?

생산성을 떨어뜨리는 병목 구간에서 AI의 지원으로 업무 흐름을 최적화 할 수 있습니다.

4.2 업데이트 리듬 (틈날 때 자주 Agile ↔ 고정된 일정에 Rigid)

자주 보고하고 업데이트 하는 조직과 모든 게 정리되면 한 번에 업데이트하는 조직이 있습니다. 이런 업무 리듬에 따라 AI가 어떤 시점에 어떻게 개입할 것인지에 대한 계획을 세울 수 있습니다.

업무를 진행할 때,

업무 기준/정책이 자주 업데이트되는가? 또는 거의 고정되어 있는가?
업무를 틈틈이 계속 보고하는가? 또는 정해진 일정에 보고하는가?

AI가 조직의 업데이트 속도와 정책 변경 주기를 학습해, 필요한 시점에 자동으로 지식을 보정하거나 확장하고, 수정하거나 제안할 수 있습니다.

위 내용을 종합해 보면 아래와 같습니다.

AX의 첫 질문은?

AI 전환(AX)은 기술 프로젝트가 아니라, 사람이 일하는 방식을 다시 설계하는 프로젝트입니다. 아무리 좋은 AI라도, 우리 조직의 업무 구조, 커뮤니케이션 방식, 지식 흐름, 일의 리듬을 이해하지 못하면 결국 '비싼 화장품'이 되고 맙니다.

위에서 살펴본 4가지 주제(업무 성격, 소통 방식, 정보의 질, 일의 속도)를 우리 조직에 맞춰 파악해 봤다면 이제 그에 맞는 AI 활용 전략을 설계할 차례입니다. 구조화된 업무에는 자동화의 날개를 달아주고, 비구조적인 고민에는 추론을 강화시켜 깊이를 더합니다. 조직의 언어를 학습시키고 병목 구간을 AI로 메우는 과정, 그것이 바로 진정한 의미의 AX입니다. '사람'을 아는 만큼 AI는 유능해질 것입니다.

사람을 정확히 이해한 조직은 AI를 단순한 도구가 아니라 동료처럼, 파트너처럼 사용하게 될 것입니다. 그래서 AX의 첫 질문은 언제나 이것이어야 합니다.

“우리는 지금, 어떻게 일하고 있는가?”

<원문>

AX, 사람과 일을 이해하는 여정

]]>

AI를 잘 쓰는 기획자는 왜 질문부터 다를까?

낯선 도메인에 던져진 서비스 기획자가 실무에서 배운 프롬프트 업그레이드

한때는 AI를 많이 쓸수록 일이 빨라질 줄 알았다. 그런데 실제로는 반대인 순간이 많았다. 답을 받는 시간보다 그 답을 고치고, 의심하고, 다시 묻는 시간이 더 길어졌다. 여러 AI를 병렬로 돌려보면서 내린 결론은 단순했다. 문제는 AI의 성능이 아니라, 내가 처음 던진 질문의 전제에 있었다.

서비스 기획자가 AI를 써도 실무 품질이 쉽게 올라가지 않는 이유도 여기에 있다. 많은 경우 우리는 AI에게 더 좋은 답을 요구한다. 하지만 정작 바꿔야 하는 것은 답변 품질이 아니라 질문 설계다. 특히 어느 정도 경력이 쌓인 이후에는 정보를 모르는 문제가 아니라, 무엇을 먼저 물어야 하는지 잘못 잡는 문제가 더 자주 생긴다. AI는 대답을 빠르게 내놓지만, 질문이 잘못되면 그 답변은 오히려 기획을 틀린 방향으로 더 빨리 밀어붙인다.

이 사실을 가장 크게 배운 건 광고 플랫폼 관련 업무에 긴급 투입됐을 때였다. 데이터 시각화는 오래 해왔지만 광고 도메인은 처음이었다. 그런데 어느 날 갑자기 광고 플랫폼 기획을 맡게 됐고, C레벨 보고까지 준비해야 했다. 낯선 시장 구조를 빠르게 이해하고, 경쟁 구도를 정리하고, 차별화 포인트까지 말해야 하는 상황이었다.

그때 나는 아주 전형적인 방식으로 AI를 썼다. 역할을 부여하고, 주요 플레이어를 지정하고, 비교해달라고 했다.

“너는 10년 차 광고 플랫폼 기획자야. CTV 광고 시장의 주요 플레이어를 경쟁사 관점에서 비교해줘. Roku, Amazon, Google의 사업 구조와 점유율을 정리해주고, 밸류체인별 차이도 설명해줘.”

AI를 정리 모드로 만드는 프롬프트 예시 <출처: 작가>

지금 보면 꽤 그럴듯한 프롬프트였고, AI도 성실하게 답했다. 시장 구조는 깔끔하게 정리됐고, 플레이어 비교도 무난했다. 나는 그 내용을 바탕으로 보고서를 정리했고, 큰 무리 없이 초반 보고를 마쳤다.

문제는 그다음에 나왔다. 다른 회의에서 동료의 발표를 들었는데, 내가 정리한 방향과 다른 이야기가 나온 것이다. 나는 기존 밸류체인을 정리하고 있었는데, 동료는 그 밸류체인 자체가 이미 흔들리고 있다고 말했다. 예를 들어 Roku는 모든 영역을 자체적으로 쥐는 방향이 아니라, 파트너십 중심으로 오픈하는 전략을 이야기였다. 내가 보고서에 넣었던 핵심과는 다른 이야기였다.

그 순간 깨달았다. AI가 틀린 답을 준 게 아니었다. 내가 AI에게 시킨 일이 이미 틀린 방향이었다. 내 질문에는 두 개의 전제가 숨어 있었다.

첫째, 이 밸류체인은 지금도 유효하고 비교적 안정적이라는 전제.

둘째, 내가 해야 할 일은 이 구조를 잘 이해하고 정리하는 것이라는 전제. 하지만 실제 시장은 그 구조 자체를 재편하는 중이었다. 내가 봐야 했던 것은 “무엇이 무엇과 다른가”가 아니라 “무엇이 왜 뒤집히고 있는가”였다. 그런데 나는 정리형 질문을 던졌고, AI는 아주 성실하게 정리형 답변을 내놓았다. 정확한 답이었지만 방향은 틀렸다.

서비스 기획 실무에서 더 위험한 것은 AI의 오답보다 이런 순간이다. 정리형 질문이 변화형 질문을 밀어내는 순간. 구조를 묻기 전에 변화를 보지 못하고, 설명을 요구하느라 전제를 점검하지 못하는 순간이다. 특히 낯선 시장을 이해해야 하거나, 새로운 서비스를 정의해야 하거나, 경쟁사 프레임을 다시 짜야 하는 업무에서는 이 차이가 치명적이다. 초반 질문이 잘못되면 이후 산출물 전체가 그 방향을 따라가기 때문이다.

나는 답을 구하기 전에 사각지대부터 묻기 시작했다

이 경험 이후로 나는 프롬프트를 바꾸기 시작했다. 예전에는 “정리해줘, 비교해줘, 설명해줘”로 시작했다면, 지금은 먼저 이렇게 묻는다.

“네가 이 도메인을 맡은 서비스 기획자라면 지금 무엇부터 물어보겠어? 내가 지금 어떤 접근으로 이 문제를 보고 있는지 먼저 짚고, 그 접근에 깔린 전제가 무엇인지 말해줘. 그리고 최근 변화가 기존 구조를 어떻게 흔들고 있는지부터 설명해줘.”

답을 바로 요구하지 않고, 사각지대를 먼저 드러내는 프롬프트 예시 <출처: 작가>

겉보기엔 작은 차이 같지만 실무에서는 결과가 완전히 달라진다. 이 질문은 답을 바로 달라고 하지 않는다. 대신 내 사각지대를 먼저 드러내달라고 요구한다. 그러면 AI는 “이 구조를 누가 우회하고 있는가?”, “지금 비교 프레임이 이미 낡은 것은 아닌가?”, “당신이 당연하다고 보는 질서가 실제로는 해체되는 중인 것은 아닌가?” 같은 질문을 던져온다. 바로 그 지점에서 기획이 달라진다.

좋은 프롬프트는 정보를 더 많이 가져오는 프롬프트가 아니다. 내가 무엇을 당연하게 보고 있는지 먼저 드러내는 프롬프트다. 서비스 기획자에게 AI는 답변 엔진이기 전에, 전제 점검 도구가 되어야 한다.

늘 무엇이 빠져있는지 확인하는 프롬프트 설계가 필수다. <출처: 작가>

이 방식은 특히 서비스 기획 초반 업무에서 강하게 작동한다. 시장 구조를 파악할 때, 경쟁사를 비교할 때, 신규 서비스를 정의할 때, 정책을 설계할 때, 이해관계자 간 관점을 정리할 때 그렇다. 이 단계에서는 답을 빨리 받는 것보다 질문의 방향을 틀리지 않는 것이 훨씬 중요하다. 초반 질문이 틀리면, 나중에 문장을 아무리 잘 다듬어도 결국 엇나간 답안을 예쁘게 정리하는 데 그치기 쉽다.

그래서 요즘 내가 가장 자주 쓰는 프롬프트 구조는 네 단계다.

첫째, AI의 역할을 지정한다.
둘째, 내가 현재 어떤 방식으로 접근하고 있는지 드러낸다.
셋째, 놓친 관점과 숨어 있는 전제를 먼저 짚어달라고 한다.
넷째, 최근 변화가 기존 구조를 어떻게 흔들고 있는지 묻는다.

예를 들면, 이렇게 쓴다.

“네가 [내 역할]을 맡은 서비스 기획자라면, 지금 이 문제에서 무엇부터 확인하겠어? 내가 현재 [내 접근 방식]으로 접근하고 있는데, 이 접근의 전제와 사각지대를 먼저 짚어줘. 특히 최근 [업계 변화/주요 사건]가 기존 [구조/관행]을 어떻게 흔들고 있는지 중심으로 정리해줘.”

이 프롬프트의 장점은 답변보다 질문 목록을 먼저 가져오게 만든다는 데 있다. AI가 나 대신 결론을 내리기보다, 내가 어떤 순서로 생각해야 하는지를 보여준다. 그 결과 회의 전에 준비해야 할 질문이 달라지고, 보고서 첫 장에 놓이는 문제 정의도 달라진다. “무엇을 정리할 것인가”보다 “무엇을 의심할 것인가”가 먼저 정해진다.

한 가지 더 유용했던 방식은 여러 AI를 병렬로 쓰는 것이었다. 같은 주제를 GPT, Gemini, Claude에 동시에 던져본 뒤, 한 모델의 답변을 다른 모델에게 넘겨 전제를 해부하게 했다.

“다음은 [다른 AI]가 정리한 분석이야. 이 분석의 전제 세 가지를 짚어줘. 그리고 그 전제들이 지금 시점에 흔들리고 있다면 결론이 어떻게 달라지는지 반박해줘.”

여기서 중요한 건 단순한 팩트 체크가 아니다. 더 중요한 건 프레임 차이다. 어떤 모델은 구조의 안정성을 전제하고 답하고, 다른 모델은 구조의 해체 가능성을 전제한다. 두 답을 나란히 놓고 보면 내가 어떤 질문 프레임 안에 갇혀 있었는지가 보인다. 실무에서 이 차이는 생각보다 크다. 같은 시장 데이터, 같은 사례, 같은 키워드를 보고도 누군가는 정리만 하고 끝나고, 누군가는 변화의 방향까지 짚는다. 차이는 정보량보다 질문의 각도에서 난다.

출처 확인은 링크를 받는 일이 아니라, 제목과 날짜를 검증하는 일이다

<출처: 작가>

그런 다음에야 팩트로 내려간다. 많은 사람들이 AI 답변을 검증할 때 사실관계부터 확인하려 한다. 시장 구조나 전략 방향 같은 문제에서는 사실 여부만으로는 부족하다. 어떤 전제를 깔고 그 사실을 배열했는지를 봐야 한다. 그래야 같은 정보로도 왜 다른 결론이 나오는지 이해할 수 있다.

물론 핵심 문장은 결국 공식 출처로 다시 확인해야 한다. 특히 전략 변화, 시장 방향, 사업 구조 같은 문장은 더 그렇다. 예전에는 “출처를 알려줘”라고만 물었는데, 그러면 AI가 그럴듯한 링크를 붙이는 경우가 있었다. 그래서 지금은 이렇게 묻는다.

“이 내용의 근거가 되는 공식 블로그 포스트, IR 자료, 컨퍼런스 발표의 제목과 발행일을 알려줘. 내가 직접 검색해서 실존 여부를 확인할 수 있어야 해.”

이렇게 하면 검증 방식도 달라진다. 링크를 믿는 게 아니라, 제목과 날짜를 기준으로 내가 직접 확인하게 된다. 실무에서는 이 과정이 번거로워 보여도, 보고서 한 장을 잘못 쓰고 다시 뒤집는 비용에 비하면 훨씬 싸다. 나에게는 그 이후 이 확인 과정이 선택이 아니라 기본 루틴이 됐다.

정리 단계에서는 AI를 넓게 쓰지 말고 오히려 좁혀야 한다

<출처: 작가>

탐색 단계에서 AI를 넓게 쓰는 것만큼 중요한 게 하나 더 있다. 정리 단계에서는 반대로 AI를 좁게 써야 한다는 점이다.

이것저것 많이 조사한 뒤 마지막에 “지금까지 내용을 정리해줘”라고 던진다. 그러면 AI는 친절하게 답하지만, 정작 그 결과물은 기획서 초안으로 바로 쓰기 어렵다. 문장은 그럴듯한데 공허하고, 예쁘지만 추상적이며, 산출물 형식과도 잘 맞지 않는다. AI는 형식이 없으면 빈칸을 채우려 하고, 금지 조건이 없으면 익숙한 표현으로 빠져나간다.

그래서 정리 단계에서는 질문을 여는 대신 제약을 준다. 형식을 주고, 금지 조건을 박는다.

예를 들어, 사용자 시나리오를 정리할 때는 이렇게 묻는다. “사용자 시나리오 3개를 작성해줘. 각 시나리오는 상황, 동기, 행동, 감정 변화 순서로 정리하고, 각 항목은 실제 사용 맥락이 드러나야 해. 각 시나리오는 3문장 이내로 압축해줘.”

UX 개선안을 정리할 때는 이렇게 묻는다. “스마트홈 앱의 UX 개선안을 제시해줘. 단, 원론적 해결책 금지, 기술 난이도를 무시한 아이디어 금지, 단순히 예쁘게 바꾸자는 디자인 제안 금지. 각 개선안은 ‘어떤 사용자의, 어떤 상황에서, 왜 필요한가’로 시작해줘.”

형식과 금지 조건을 동시에 걸면 AI는 “뭐라도 채우자” 모드에서 벗어난다. 그리고 그때부터 결과물은 탐색용 답변이 아니라 실제 산출물에 가까운 초안이 된다. 탐색 단계에서는 넓게 묻고, 정리 단계에서는 오히려 좁혀야 한다. AI를 잘 쓰는 기획자는 많이 묻는 사람이 아니라, 언제 넓히고 언제 좁힐지 아는 사람이다.

결국 기획자의 경쟁력은 답변량이 아닌 질문의 방향에서 나온다

가장 의외였던 변화도 있다. AI를 많이 쓸수록 오히려 사람의 보고를 더 잘 듣게 됐다는 점이다. 예전에는 동료의 발표를 들을 때 “어차피 나도 gpt, gemini 쓰는데 서로 비슷한 자료를 찾았겠지”라고 생각한 적이 많았다. 지금은 다르게 본다. 더 중요한 것은 정보 자체가 아니라, 그 사람이 어떤 질문에서 출발했는가다. 왜 나는 같은 AI를 쓰고도 저 관점을 못 봤을까. 무엇을 먼저 물었기에 저 사람은 구조 변화부터 봤을까. 회의에서 진짜 배워야 할 것은 종종 답이 아니라 질문의 출발점이다.

서비스 기획자의 역할도 점점 그쪽으로 이동하고 있다고 느낀다. 정보는 넘치고, 답도 넘친다. 하지만 어떤 질문을 먼저 세울지는 여전히 사람의 몫이다. 특히 AI가 너무 매끄럽게 답할수록 더 조심해야 한다. 매끄러운 답은 종종 틀린 방향을 가리키고, 성실한 정리는 변화의 징후를 지워버린다. AI가 화려하고 논리적으로 답할수록, 기획자의 경쟁력은 그 답을 그대로 받아들이지 않는 데서 생긴다. 남들이 결론부터 쓰려 할 때, 변화의 방향을 의심하고 전제부터 점검하는 태도가 더 중요해지는 셈이다.

그래서 요즘 나는 AI에게 답을 받기 전에 꼭 한 번 더 묻는다. 내가 지금 당연하게 보고 있는 전제는 무엇인지, 이 구조는 정말 안정적인지, 내가 정리하려는 순간 놓치고 있는 변화는 없는지. 이 질문을 먼저 던지면 프롬프트가 달라지고, 프롬프트가 달라지면 기획의 방향이 달라진다.

이번 주 업무에서 한 번만 바꿔봐도 좋다. “정리해줘” 대신, “내가 놓친 전제를 먼저 짚어줘”라고 말이다. 프롬프트 하나를 바꾸는 일은 표현을 다듬는 일이 아니다. 결국 기획의 방향을 바꾸는 일이다.

]]>

DESIGN.md: 파일 하나로 Apple 디자인 시스템을 적용하는 법

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: DESIGN.md + getdesign.md - AI에게 우리 디자인 규칙을 알려주는 파일
참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준
적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

<출처: getdesign.md>

1. 써볼 것: AI에게 우리 디자인 규칙을 알려주는 파일

DESIGN.md는 Google이 자사 디자인 도구 Stitch에서 만들어 오픈소스로 공개한 마크다운 파일 규격입니다. 4월 21일 Apache 2.0 라이선스로 공개되자마자 개발자 커뮤니티에서 큰 반응을 얻었는데요. 공식 GitHub 레포는 공개 72시간 만에 스타 5,000개를 넘겼고, 커뮤니티에서 이 규격을 활용해 만든 awesome-design-md 레포는 한 달 만에 스타 6.8만 개를 돌파했습니다.

프로젝트 루트에 DESIGN.md 파일을 넣어두면, AI 코딩 에이전트가 그 파일을 읽고 우리 브랜드에 맞는 UI를 만들어주는 방식입니다. 매번 색상 코드, 폰트, 간격 규칙을 프롬프트로 설명하지 않아도 되죠.

무슨 문제를 해결해 주나요?

Claude Code, Cursor, Copilot 같은 AI 코딩 에이전트로 UI를 만들어본 적이 있다면 이런 경험이 있을 겁니다. 기능적으로는 잘 작동하는데, 결과물이 어딘가 범용적이에요. 우리 브랜드 색상도 아니고, 폰트도 다르고, 버튼 모양도 우리 제품과 안 맞죠. 그래서 매번 프롬프트에 이렇게 써야 합니다. 우리 메인 색상은 #1A73E8이고, 본문 폰트는 Inter 16px, 버튼은 border-radius 8px로 해줘. 프로젝트를 새로 열 때마다, 대화가 길어질 때마다 이걸 반복해야 하고요.

DESIGN.md는 이 반복을 없앱니다. README.md가 프로젝트를 사람에게 설명하듯, DESIGN.md는 디자인 시스템을 AI 에이전트에게 설명하는 파일입니다. 한 번 만들어 프로젝트 루트에 넣어두면, 에이전트가 매 작업마다 이 파일을 자동으로 읽고 반영하죠.

우선, 파일 구조는 두 부분으로 나뉩니다. 앞쪽에 YAML로 정확한 디자인 토큰 값(색상 코드, 폰트 크기, 간격 등)을 적고, 뒤쪽에 마크다운으로 그 값들이 왜 존재하는지, 어떤 맥락에서 써야 하는지를 설명합니다. 토큰은 에이전트에게 정확한 숫자를 주고, 마크다운 설명은 그 숫자를 언제 어떻게 쓸지 판단하게 해주는 구조입니다.

어떻게 쓰나요?

DESIGN.md를 만드는 방법은 세 가지입니다.

방법 1. Google Stitch에서 자동 생성하기

가장 쉬운 방법입니다. stitch.withgoogle.com에 접속해서 프로젝트를 만들거나 기존 디자인을 가져오면, Stitch가 디자인 시스템을 분석해서 DESIGN.md를 자동으로 생성해줍니다. 기존 웹사이트 URL만 넣어도 그 사이트의 디자인 규칙을 추출할 수 있고요. Stitch는 무료이고, 구글 계정만 있으면 월 550회까지 생성할 수 있습니다.

방법 2. getdesign.md에서 브랜드 디자인 시스템 가져오기

여기가 사실상 우리에게 가장 실용적인 부분일 수 있는데요. VoltAgent라는 팀이 만든 getdesign.md에 가면, Apple, Notion, Figma, Spotify, Vercel 등 70개 브랜드의 DESIGN.md 파일이 정리되어 있습니다. GitHub의 awesome-design-md 레포에서도 같은 파일들을 받을 수 있고요. (링크는 아래에 모아두었습니다)

사용법은 간단합니다. 마음에 드는 브랜드의 DESIGN.md 파일을 다운로드하고, 내 프로젝트 루트에 넣은 뒤, AI 코딩 에이전트에게 작업을 시키면 됩니다. 예를 들어 핀터레스트(Pinterest)의 DESIGN.md를 넣고 이미지 갤러리 페이지를 만들어달라고 하면, 핀터레스트 특유의 둥근 모서리와 깔끔한 카드 레이아웃이 적용된 결과물이 나오는 식이죠.

<출처: getdesign.md>

물론 이 파일들은 해당 브랜드의 공개된 CSS 값을 기반으로 추출한 것이라, 그대로 쓰기보다는 출발점으로 활용하는 게 좋습니다. 마음에 드는 브랜드의 파일을 기반으로 색상과 폰트를 내 브랜드에 맞게 수정하면 됩니다. 마크다운 파일이니까 아무 텍스트 에디터에서 편집할 수 있고요.

방법 3. 직접 작성하기

이미 디자인 시스템이 잡혀 있는 팀이라면 직접 쓰는 것도 어렵지 않습니다. Figma에 정리된 디자인 토큰이나 Tailwind 설정 파일이 있다면, 그 값들을 DESIGN.md 포맷으로 옮기면 됩니다. 공식 스펙 문서가 GitHub에 공개되어 있고, 공식 스펙 문서가 GitHub에 공개되어 있고, CLI 도구도 함께 제공됩니다. 터미널에서 명령어 한 줄로 파일이 제대로 작성됐는지 검증할 수 있고, WCAG 접근성 기준에 맞는지까지 자동으로 확인 받을 수 있습니다.

어떤 에이전트에서 쓸 수 있나요?

DESIGN.md는 마크다운 파일이기 때문에 특정 도구에 종속되지 않습니다. 프로젝트 파일을 읽을 수 있는 에이전트라면 어디서든 작동합니다. 현재 Claude Code, Cursor, GitHub Copilot, Kiro, Windsurf, 그리고 Google Stitch에서 호환이 확인됐고요. 별도 플러그인이나 설정 없이, 프로젝트 루트에 파일만 넣으면 됩니다.

누구에게 좋을까요?

AI 코딩 에이전트로 UI를 자주 만드는데, 매번 디자인을 설명하는 게 번거로운 사람
디자이너 없이 사이드 프로젝트를 진행하면서, 그래도 일관된 디자인을 유지하고 싶은 사람
팀 내 디자인 시스템을 AI 에이전트에게 전달할 표준 포맷이 필요한 팀
프로토타입이나 MVP를 빠르게 찍어내야 하는데, 범용적인 UI에서 벗어나고 싶은 사람

반대로 이미 Figma 기반 디자인 시스템이 잘 갖춰져 있고 AI 에이전트를 쓸 계획이 없다면 당장 필요하지는 않겠습니만, DESIGN.md 규격 자체가 아직 알파 단계이고, Google이 업계 표준으로 만들려는 움직임을 보이고 있어서 흐름은 지켜볼 만합니다.

DESIGN.md 공식 문서: stitch.withgoogle.com/docs/design-md/overview
DESIGN.md GitHub 레포: github.com/google-labs-code/design.md
getdesign.md (브랜드별 DESIGN.md 모음): getdesign.md
awesome-design-md GitHub 레포: github.com/VoltAgent/awesome-design-md

<출처: Jordan Lord>

2. 참고할 것: 10년차 빌더가 제품을 만들기 전, 확인하는 세 가지 기준

10년간 여러 제품을 만들어온 개발자 Jordan Lord가 자신의 블로그에 올린 글입니다. 이 글은 해커뉴스에 공유되며 나름의 화제가 됐는데요. 제품을 만들기 전에 반드시 통과해야 하는 세 가지 제을 제시하고, 하나라도 통과하지 못하면 만들지 않는다는 원칙을 공유합니다.

이 글이 반응을 얻은 건 아마 많은 빌더들이 겪는 공통적인 문제를 건드렸기 때문일 겁니다. 뭔가 만들고 싶은 아이디어는 많은데, 만들다 보면 범위가 커지고, 정체성이 흐려지고, 결국 아무도 안 쓰는 제품이 되는 경험. 이 글은 그 문제를 만들기 전 단계에서 잡는 방법을 이야기합니다.

기존 제품 판단 방식과 무엇이 다른가요?

보통의 사람들은 제품 아이디어를 평가할 때는 시장 크기, 경쟁자 분석, 사용자 니즈 같은 요소를 따집니다. 하지만 Jordan Lord의 접근은 방향이 조금 다릅니다. 아이디어가 좋은지 나쁜지를 판단하는 게 아니라, 만들 준비가 됐는지 안 됐는지를 판단하는 필터입니다. 그래서 세 가지 제약 모두 아이디어의 가치가 아니라 아이디어의 상태를 봅니다. 충분히 정리됐는가, 누적 가능한 구조인가, 정체성이 있는가. 같은 것들입니다.

세 가지 제약은 무엇인가요?

제약 1. 한 페이지를 넘기면 만들지 않는다

모든 아이디어는 한 장짜리 문서(one pager)로 정리해야 합니다. 이 문서가 north star(제품의 방향을 잡아주는 기준점) 역할을 하고요. 투자자한테도, 팀원한테도, 친구한테도 같은 문서를 보여줄 수 있어야 합니다.

핵심은 양쪽 극단을 모두 필터링한다는 점입니다. 한 페이지를 채우지 못했다면 아직 만들 준비가 안 된 거라고 하죠. 더 조사하고, 간단하게라도 만들어보고, 다시 써야 한다고요. 반대로 한 페이지를 넘어갈 정도라면 너무 복잡한 거라고 하죠. 협업에서도 이 문서가 기준이 됩니다. 의견 충돌이 생겼을 때, one pager에 없는 내용이라면 싸울 가치가 없고, 정말 중요하다면 문서를 수정해서 반영하면 된다고요.

제약 2. 핵심 기술은 제품과 분리되어야 한다

제품 자체와 별개로, 그 제품을 떠받치는 core tech(제품이 바뀌어도 남는 핵심 기술 자산)를 함께 만들어야 합니다. 이 core tech는 현재 제품이 없어져도 살아남을 수 있어야 하고요.

왜 이게 중요한지는 예시를 보면 바로 이해됩니다. Linus Torvalds가 Linux 커널 개발 워크플로를 개선하려고 만든 게 git이에요. Linux가 아니더라도 git은 살아남잖아요. HashiCorp의 HCL, Google의 Kubernetes도 마찬가지고요.

꼭 이런 대규모 프로젝트일 필요는 없습니다. 코드베이스에서 분리한 라이브러리, 계속 다듬어가는 방법론도 core tech가 될 수 있어요. 요점은 제품이 방향을 바꾸더라도 축적이 끊기지 않는 구조를 만들라는 겁니다. 피봇은 흔한 일이지만, 피봇할 때마다 모든 걸 처음부터 다시 시작하면 누적의 이점이 사라지니까요.

제약 3. 하나의 결정적 제약이 제품을 규정해야 한다

제품의 중심에 사용자가 항상 마주치는 하나의 defining constraint(제품의 정체성을 규정하는 핵심 제약)가 있어야 합니다. 이 제약이 제품의 정체성을 만들고, 사용자 경험 전반에 스며드는 거죠.

Minecraft는 블록만으로 세상을 만들 수 있습니다. IKEA는 납작한 상자에 담긴 자가 조립 가구죠. 이 제약을 들으면 제품의 느낌이 바로 떠오르잖아요. 잘 설계된 제약이 있으면 디자인은 그 제약에서 자연스럽게 따라 나온다는 게 Jordan Lord의 주장입니다.

해커뉴스 댓글에서 한 사용자는 이걸 product primitives(제품 전체를 구성하는 가장 작은 기본 단위)라는 개념으로 연결했는데요. Notion의 블록, Figma의 프레임과 레이어, Twitter의 트윗, Excel의 셀이 모두 같은 구조라는 거예요. 제품의 중심에 있는 하나의 기본 단위가 전체 경험을 규정한다는 점에서 맥이 닿습니다. 반대로 이 제약을 정하지 않거나 잘못 정하면, 모든 걸 하려는 비대한 제품이 된다고 합니다.

무엇을 얻어가야 하나요?

이 글의 가치는 프레임워크 자체보다 태도에 있다고 봅니다. 세 가지 제약 중 하나라도 통과하지 못하면 만들지 않는다는 원칙이요. AI 덕분에 만드는 속도가 빨라진 만큼, 만들지 말아야 할 것을 거르는 기준도 더 중요해지고 있으니까요.

모든 제품에 이 프레임워크가 딱 맞는 건 아닐 수 있습니다. 특히 core tech 분리는 초기 탐색 단계에서는 과한 요구일 수 있고, B2B SaaS처럼 범위가 넓어질 수밖에 없는 제품에서는 defining constraint가 좁은 게 오히려 제약이 될 수도 있습니다. 해커뉴스 댓글에서도 이런 반론이 나왔고요. 그래도 만들기 전에 세 가지 질문을 스스로에게 던지는 습관은 가져갈 만합니다.

한 페이지로 정리할 수 있는가? 피봇해도 살아남는 게 있는가? 이 제품의 정체성을 한 문장으로 말할 수 있는가?

원문: jordanlord.co.uk/blog/3-constraints
해커뉴스 토론: news.ycombinator.com/item?id=47903541

<출처: 유튜브, Lenny's Podcast>

3. 적용해볼 것: 앤트로픽 Claude Code 제품 총괄이 말하는, AI 시대 PM의 희소 능력

Cat Wu는 앤트로픽에서 Claude Code와 Co-work의 프로덕트를 이끌고 있는 제품 총괄입니다. 최근 Lenny's Podcast에 출연해서 앤트로픽 프로덕트 팀이 어떻게 일하는지, AI 시대에 PM에게 필요한 능력이 무엇인지를 공유했는데요. 이 에피소드는 현재 Lenny's Podcast의 최근 영상 중 가장 빠르게 조회수가 올라가고 있는 영상 중 하나입니다.

흥미로운 건 인터뷰 전반을 관통하는 메시지가 하나라는 점인데요. 코드가 싸지면, 무엇을 만들지 결정하는 능력의 가치가 올라간다. Cat Wu는 이걸 product taste라고 부릅니다.

무슨 문제를 해결하려 하나요?

AI 덕분에 만드는 속도가 올라갔습니다. 그건 모두가 체감하고 있죠. 그런데 속도가 올라간 세계에서 PM은 뭘 해야 하는 건지, 엔지니어와 PM의 경계가 흐려지면 PM의 존재 이유가 뭔지, 이런 질문에는 아직 명확한 답이 없습니다.

Cat Wu는 실제로 수백 명의 PM을 인터뷰하고 있다고 합니다. 그리고 많은 지원자들이 AI 시대의 PM 역할을 잘못 이해하고 있다고 느낀다고요. 기존처럼 6~12개월 로드맵을 짜고, 팀 간 조율에 시간을 쓰는 방식으로 접근하는 사람들이 많다는 겁니다.

속도는 어떻게 만들어졌나요?

앤트로픽 프로덕트 팀의 출시 속도는 이례적입니다. Cat Wu에 따르면, 피처 출시 타임라인이 6개월에서 1개월로, 다시 1주로, 때로는 하루로 줄었다고 합니다. 이 속도를 가능하게 만든 건 세 가지 구조입니다.

첫째, 거의 모든 피처를 Research Preview로 먼저 출시합니다. 사용자에게 이건 초기 제품이고, 피드백을 받기 위한 단계라는 걸 명확히 알린 뒤 출시하는 거예요. 이렇게 하면 출시에 대한 부담이 줄어들어서, 1~2주 만에 뭔가를 내보낼 수 있게 됩니다.
둘째, 엔지니어링-마케팅-문서화 사이의 프로세스가 매우 타이트합니다. 엔지니어가 내부 테스트를 마친 피처를 evergreen launch room이라는 채널에 올리면, 마케팅과 문서 팀이 바로 다음 날 발표를 준비하는 구조라고 해요. PM의 역할은 이 흐름이 막히지 않도록 만드는 것이고요.
셋째, 팀 전체가 공유하는 원칙 문서가 있습니다. 핵심 사용자가 누구인지, 왜 그들이 핵심인지, 어떤 트레이드오프를 감수할 수 있는지가 적혀 있어서, 팀원 누구나 PM에게 물어보지 않고도 스스로 판단할 수 있게 만들었다고 합니다.

빠른 세계에서 뭐가 더 중요해졌나요?

그런데 이 속도에는 비용이 따릅니다. Cat Wu가 직접 인정한 부분인데요. 제품 일관성이 떨어집니다. 기능끼리 겹치는 경우도 생기고, 새로운 사용자 입장에서는 어떤 기능을 써야 할지 헷갈릴 수 있다고요. 사용자들도 매일 트위터를 확인해야 최신 기능을 놓치지 않는다는 느낌을 받는다고 합니다.

Cat Wu는 이 맥락에서 product taste를 이야기합니다. 코드가 싸지면, 뭘 만들지 결정하는 능력이 더 중요해진다고요. GitHub 이슈에 수만 개의 요청이 쌓여 있는데, 그중 어떤 것을 만들 가치가 있는지, 만든다면 어떤 방식이 맞는지를 판단하는 능력이 가장 희소하다는 겁니다.

현재는 엔지니어링 배경이 도움이 된다고 합니다. 이걸 만드는 게 얼마나 어려운 일인지 감이 있으면, 토론 대신 그냥 한 시간 만에 만들어보는 판단을 내릴 수 있으니까요. 다만 Cat Wu는 이 역시 몇 달 뒤에는 달라질 수 있다고 덧붙였습니다. 모델 역량이 올라갈 때마다 가치 있는 스킬셋도 바뀌고 있어서, 너무 먼 미래를 예측하는 건 어렵다고요.

앤트로픽이 PM보다 product taste가 있는 엔지니어를 적극적으로 뽑고 있다는 점도 눈여겨볼 만합니다. Cat Wu 본인도 엔지니어 출신이고, 팀의 PM 대부분이 엔지니어 경험이 있으며, 디자이너들도 프론트엔드 엔지니어 출신이라고 합니다. 역할이 합쳐지는 흐름이 이미 실행되고 있는 셈이죠.

어떻게 기르나요?

Cat Wu가 인터뷰에서 공유한 방법들을 정리해보면 이렇습니다.

모델에게 실수 이유를 물어보세요.

Cat Wu가 가장 과소평가된 AI 스킬이라고 부른 방법입니다. 모델이 예상과 다르게 행동했을 때, 왜 그렇게 했는지 모델에게 직접 물어보는 거예요. 예를 들어 모델이 프론트엔드를 수정하고 테스트는 돌렸는데 실제 UI는 확인하지 않았다면, 왜 UI 확인을 안 했는지 물어보는 겁니다. 그러면 시스템 프롬프트에서 헷갈리는 부분이 있었다든지, 서브 에이전트에게 검증을 맡겼는데 그쪽에서 빠뜨렸다든지 하는 이유가 나온다고요. 이런 피드백이 쌓이면 어떤 부분을 고쳐야 모델이 더 잘 작동하는지 파악할 수 있게 됩니다.

피드백을 잘하는 5명을 찾으세요.

모든 사용자의 피드백이 같은 무게를 가지는 건 아닙니다. Cat Wu는 모델이나 제품의 품질을 정확하게 짚어내는 사람이 따로 있다고 합니다. 그런 사람 5명 정도를 찾아서 빠른 피드백 루프를 만드는 게 중요하다고요. 앤트로픽 내부에서도 새 모델이 나오면 팀 점심 시간에 한 명씩 돌아가며 모델에 대한 인상을 물어보고, 그 피드백을 기반으로 데이터에서 검증할 가설을 세운다고 합니다.

AI의 결과물을 테스트하는 기준(eval)을 만드세요.

eval은 "이 프롬프트를 넣으면 이런 결과가 나와야 한다"는 테스트 케이스입니다. 백 개를 만들 필요 없이, 10개만 잘 만들어도 충분하다고 합니다. 좋은 eval은 목표를 구체적으로 정의하고, 진행 상황을 측정하게 해주고, 부족한 부분을 보여줍니다. Cat Wu는 eval이 PM과 엔지니어 모두에게 과소평가된 스킬이라고 강조했어요.

자동화를 95%에서 멈추지 마세요.

95% 정확도의 자동화는 자동화가 아니라고 합니다. 나머지 5%를 사람이 매번 확인해야 한다면, 그건 여전히 수작업이니까요. Cat Wu 본인도 Co-work로 이메일을 자동 분류하는 워크플로를 만들고 있는데, 아직 100%에 도달하지 못해서 계속 다듬고 있다고요. 자동화를 만드는 건 직접 하는 것보다 느릴 수 있지만, 100%에 도달하면 진짜 레버리지가 생긴다는 점을 강조합니다.

프로토타입이 아니라 매일 쓰는 앱을 만드세요.

AI로 뭔가를 만들어보고 대단하다 하고 넘어가는 건 배움도 레버리지도 제한적입니다. Cat Wu는 실제로 매일 쓰는 도구를 만들어야 진짜 학습이 일어난다고 합니다. 앤트로픽 내부에서도 영업팀이 고객 맞춤 덱을 자동 생성하는 웹앱을 직접 만들어 쓰고 있고, Applied AI 팀은 Co-work로 다음 날 고객 미팅 브리핑을 자동으로 만들어둔다고요. 이런 도구들이 계속 쓰이면서 점점 더 나아지는 구조입니다.

이 인터뷰가 가리키는 한 가지 방향

이 인터뷰에서 나온 이야기들을 모아보면 하나의 패턴이 보입니다. 앤트로픽은 속도를 높이기 위해 프로세스를 줄이고, 역할 경계를 없애고, 출시 부담을 낮추는 쪽으로 움직이고 있습니다. 그리고 그 결과 더 중요해진 건 도구를 잘 쓰는 능력이 아니라, 무엇을 만들고 무엇을 만들지 않을지 판단하는 능력입니다.

Cat Wu의 좌우명도 이 맥락과 맞닿아 있는데요. Just do things. 역할에 갇히지 말고 필요한 일을 하라는 뜻이라고 합니다. 다만 아무거나 하라는 게 아니라, 제약 조건을 이해하고, 첫 번째 원칙에서 출발해서, 올바른 행동 방향을 스스로 도출한 뒤 바로 실행하라는 의미에 가깝다고요.

적용을 위해 실행해볼 수 있는 것

이번 주에 AI 에이전트가 예상과 다르게 행동한 순간이 있었다면, 왜 그렇게 했는지 모델에게 직접 물어보기. 시스템 프롬프트나 지시가 어떻게 해석됐는지 확인하면, 다음에 같은 실수를 줄일 수 있습니다.
지금 만들고 있는 자동화 중에 90~95%에서 멈춰 있는 게 있다면, 이번 주에 시간을 내서 100%를 향해 한 단계 더 밀어보기. 되는 만큼만 쓰는 것과 완전히 맡기는 건 레버리지가 전혀 다릅니다.
AI로 만든 프로토타입 중에 한 번 써보고 끝낸 게 있다면, 그중 하나를 골라 매일 쓰는 도구로 키워보기. 매일 쓰면서 부딪히는 문제를 고치는 과정이 가장 빠른 학습입니다.

영상: Lenny's Podcast - 앤트로픽의 제품 팀이 다른 어떤 팀보다 빠르게 움직이는 비결 | 캣 우

정리

이번 주 세 소재를 관통하는 키워드는 구조화된 판단입니다.

DESIGN.md는 디자인 규칙을 파일 하나로 구조화해서 AI가 매번 추측하지 않게 만듭니다. 3 Constraints는 만들기 전에 세 가지 필터를 거는 구조로 복잡하거나 정체성 없는 제품을 걸러냅니다. Cat Wu가 말하는 product taste는 만들 수 있는 것이 넘쳐나는 세계에서 무엇을 만들지 판단하는 구조를 자기 안에 갖추라는 이야기고요.

AI가 실행 속도를 올려줄수록, 우리에게 판단의 구조가 없으면 빠르게 잘못된 방향으로 빠질 수 있습니다. 도구는 계속 바뀌겠지만, 무엇을 만들지, 왜 이 규칙인지, 어디서 멈출지를 정하는 건 여전히 사람의 몫이니까요.

이렇게 적용해보세요

DESIGN.md를 한 번 만들어보세요. getdesign.md에서 마음에 드는 브랜드 파일을 가져와 내 프로젝트에 맞게 수정하는 것부터 시작할 수 있습니다. 매번 디자인을 설명하는 시간이 줄어드는 걸 체감하게 됩니다.
지금 진행 중인 프로젝트를 one pager로 정리해보세요. 한 페이지 안에 담기는지, 이 제품의 defining constraint가 뭔지 써보는 것만으로도 범위가 잡히는 경우가 많습니다.
내가 반복적으로 하고 있는 작업 중 하나를 골라 AI 자동화를 시작해보세요. 90%에서 멈추지 말고 100%를 향해 밀어보는 게 핵심입니다.

]]>

클로드 코드에서 코덱스까지: 클코나잇 시즌 2

최근까지만 해도 "AI 코딩 도구 뭐 써요?"라는 질문에 대부분 클로드 코드를 꼽았습니다. 개발자 커뮤니티, 링크드인 등에서 클로드 코드 활용기가 압도적으로 많았고, "클로드 코드 없이 어떻게 일했지?"라는 말이 나올 정도였습니다. 그런데 요즘 분위기가 달라지고 있습니다.

앤트로픽의 보안 이슈와 토큰 비용 증가 논란이 겹치면서, 개발자 커뮤니티를 중심으로 "클로드 코드에서 코덱스로 갈아탔다"라는 표현이 나올 정도인데요. 그 사이 OpenAI는 GPT-5.5를 코덱스에 탑재하며 "더 적은 토큰으로 더 나은 결과"를 내세웠습니다. 클로드 코드를 향한 불만이 커지는 시점에 정반대의 방향으로 치고 나온 셈이죠.

클로드 코드 vs 코덱스?! 혹은 둘 다 써야 할지… 두 도구가 동시에 빠르게 진화하고 있는 지금, 현업에서 실제로 써본 사람들의 이야기가 그 어느 때보다 필요한 시점이라고 생각했습니다. 그래서 이번 클코나잇 시즌 2 발표 주제도 클로드 코드에서 코덱스까지 넓혀보기로 했습니다.

➡️ 발표자 신청하기(마감 5/5일 23:59까지)

코덱스, 왜 다시 주목받고 있나요?

코덱스는 2025년 4월, 처음 출시됐을 때만 해도 "아직 쓸 만하진 않다"는 반응이 많았습니다. 그런데 그 이후 반년 사이 완전히 달라졌습니다. GPT-5.1 Codex, GPT-5.2 Codex, GPT-5.3 Codex까지 연달아 버전업되며, 단순히 코드를 생성하는 도구에서 태스크를 직접 실행하고 PR까지 올리는 에이전트로 진화했습니다.

그리고 이달 공개된 GPT-5.5와도 관련이 있습니다. GPT-5.5는 같은 코덱스 작업을 더 적은 토큰으로 처리하면서도 더 나은 결과를 내는 것이 핵심인데요. 마침 "클로드 코드는 토큰을 너무 많이 쓴다"는 불만이 개발자 커뮤니티에서 커지고 있는 시점이라, 코덱스가 정반대의 방향으로 치고 나온 셈입니다. OpenAI에 따르면 현재 내부 직원 85% 이상이 매주 코덱스를 사용하고 있으며, 재무팀은 7만 페이지 분량의 세금 서식 검토를 코덱스로 처리해 2주를 단축했다고 합니다.

클로드 코드와 코덱스는 접근 방식이 다릅니다. 강점도 다르고, 각자의 방식으로 쓰면서 발견한 것들도 다릅니다. 누군가는 클로드 코드에서 코덱스로 옮겨가기도, 또 누군가는 두 도구를 병행하고 있죠. 그 다양한 경험을 클코나잇 시즌 2에서 나눠주시면 좋겠습니다.

클코나잇이 처음이신 분들께

클코나잇은 요즘IT가 기획하는 AI 코딩 도구 실사용자 세미나입니다. 완성된 강연이 아니라, 현업에서 직접 써보고 부딪힌 사람들이 날것의 경험을 나누는 자리입니다.

지난 시즌 1은 총 3회, 10인의 발표자가 참여하여, 콘텐츠 평균 조회수 1만 뷰를 넘겼는데요. 발표 내용은 『클로드 코드로 일하기: 10인 실제 사례집』으로 엮여 판매되기도 했습니다.

이번 시즌 2는 그보다 한 걸음 더 들어갑니다. 써보다 막히면 다시 시도하면서 만들어낸 진짜 경험담을 듣는 자리가 될 예정입니다.

이런 이야기라면 클로드 코드든, 코덱스든 모두 좋아요!

두 도구를 모두 써봤는데, 이런 점이 달랐다
클로드 코드에서 코덱스로, 또는 코덱스에서 클로드 코드로 옮겨간 이유
용도에 따라 두 도구를 나눠 쓰는 나만의 기준과 사용 팁
CLAUDE.md·AGENTS.md, Skills, 서브에이전트, 훅 등을 파고들어 내 워크플로우에 맞게 길들인 이야기
팀에 도입했다가 "쓰는 사람만 쓰는" 양극화를 풀어낸 정착기
비개발자(PM·기획자·마케터·편집자 등)로서 AI 코딩 도구로 업무 방식을 바꾼 고군분투기
토큰 폭망, 컨텍스트 관리 실패 등으로 아팠던 실패담
코덱스 또는 클로드 코드로 이런 짓까지 해봤다 싶은 극단적 사례

완벽한 사례 아니어도 됩니다. 지금도 진행 중인 실험이어도 괜찮습니다.

개인 또는 팀(2인 이상) 참여 모두 가능합니다.

발표자에겐 어떤 혜택이 있나요?

요즘IT 기사·뉴스레터·SNS 공식 소개됩니다. (개인 블로그·링크드인 링크 포함)
발표 내용은 요즘IT 공식 유튜브 영상으로 기록됩니다.
발표 내용은 사례집(PDF)으로 엮여 판매될 수 있으며, 판매 수익은 배분됩니다.
요즘IT Speaker 공식 배지(PNG/SVG)를 제공합니다.
후속 인터뷰나 다음 세미나로 이어질 기회도 열려 있습니다.

신청 안내

발표 길이: 15분 내외
진행 방식: 온라인(Zoom)
세미나 일정: 5월 중순 예정 (추후 협의)
신청 방법: 신청 링크를 통해 발표 주제와 간단한 소개를 제출해주세요. 개인 또는 팀(2인 이상) 단위 모두 신청 가능합니다.
신청 마감: 5월 5일(화) 23:59
진행 절차: 신청서 접수 → 서류 검토 → 개별 온라인 인터뷰 → 발표자 선정 및 안내
최종 결과 안내: 5월 6일(수) 개별 연락

클로드 코드든 코덱스든, AI 코딩 도구와 제대로 씨름해본 경험이 있다면 어떤 이야기든 기다리고 있습니다. 많은 관심 부탁드려요!

➡️클코나잇2 발표 신청하기

]]>

프로덕트 디자이너 혼자 DAU 28만 서비스를 만든 방법

[바이브코더스] 동시접속 800명, DAU 28만 ‘온라인 담타’를 만든 고서진 님 인터뷰

디자이너 혼자 서비스를 런칭하고, DAU(일일 활성 사용자 수) 28만 명 규모로 성장시켜 직접 운영까지 하고 있다면 믿어지시나요? 오늘 바이브코더스 인터뷰에서 만나볼 고서진 님은 일명 담타(담배 타임)를 온라인으로 옮긴 서비스, ‘온라인 담타’를 만든 분입니다. “온라인에서 담배를 피운다”는 기발한 아이디어에서 시작해 동시 접속자 수 800명, DAU 28만 명을 기록하며 많은 사람들의 관심을 받았는데요.

최근까지도 링크드인에서 뜨거운 반응을 얻었고, 현재는 야구장, 지구 밖 등 다양한 테마로 공간을 확장하며 꾸준히 업데이트를 이어가고 있습니다. 디자이너 혼자서 어떻게 많은 사람이 방문하는 서비스를 구축하고, 운영할 수 있었는지 그 특별한 비결을 듣기 위해 고서진 님과 이야기를 나눠봤습니다.

고서진 님 <출처: 고서진 님 LinkedIn>

Part 1. 프로덕트 디자이너의 사이드 프로젝트

Q. 안녕하세요! 요즘IT 독자분들을 위해 자기소개 부탁드립니다.

안녕하세요. GBIKE에서 프로덕트 디자이너로 일하고 있는 고서진입니다. 요즘은 온라인 담타 운영자 ‘고 대리’로도 활동하고 있어요. 학부 졸업 후 7년째 디자인을 하고 있습니다. 제 커리어를 간단히 소개드리면, AI 덴탈 회사 이마고웍스에서 B2B 소프트웨어 디자이너로 시작했습니다. 이후 미세미세를 만든 라이프오버플로우에서 B2C 서비스도 경험했고요. 당시 저는 미세먼지를 담은 날씨 앱 ‘날씨날씨’를 주로 맡았습니다. 현재는 GBIKE에서 소프트웨어와 하드웨어를 넘나드는 UX를 디자인하며, 흥미롭게 일하고 있습니다.

Q. 링크드인에서 온라인 담타 사이트가 화제였어요. 이 프로젝트는 어떻게 시작하게 되셨나요?

그동안 사이드 프로젝트에 대한 생각은 많이 했어요. 재미있는 아이디어가 순간순간 떠오르면 여기저기 적어두곤 했지만, 회사 업무에 몰두하다 보니 실행에 옮길 여력은 없었거든요. 사실 온라인 담타 서비스 아이디어도 1년 넘게 묵혀둔 아이디어였어요. 그러다 작년에 피그마 메이크(Figma Make)가 발표되면서 “이제 시간이 없어서 못 만든다는 말은 못 하겠다”는 생각이 들었습니다. 그래서 그냥 한번 시도해 본 프로젝트가 온라인 담타였어요.

Part 2. 온라인 담타, 아이디어에서 런칭까지

Q. ‘담타’를 소재로 삼은 점이 흥미로웠어요. 이 아이디어는 어떻게 떠올리셨나요?

저는 비흡연자인데, 회사 생활을 하면서 담타하러 나가시는 분들이 어떤 대화를 나누는지 너무 궁금했어요. 사실 일부러 흡연 부스에 들어간 적도 여러 번 있을 정도였으니까요. 그러다 ‘비흡연자들도 온라인에서 잠깐 쉴 수 있는 공간이 있으면 재밌지 않을까’ 하는 생각이 들었어요. 여기에 직장 생활에 대한 풍자적인 요소도 담아 보자는 아이디어가 더해지면서 만들어진 서비스입니다.

온라인 담타 사이트 화면 <출처: damta.world>

Q. 처음 서비스를 공개했을 때 반응이 굉장히 뜨거웠는데요. 어떠셨어요?

솔직히 정말 얼떨떨했어요. 처음에는 도메인을 따로 연결하지 않고, 피그마 기본 도메인 그대로 링크드인에 공유했거든요. 그런데 반응이 예상을 훌쩍 넘어서, 의견 보내기 채널도 열고 도메인도 구매해 연결하는 식으로 하나씩 추가해 나갔어요. 동시 접속자는 최고 800명까지 들어왔고, 하루 접속자 수도 최고 28만 명을 찍었죠. 지금은 조금 안정되서 하루 1~2만 명 정도가 꾸준히 들어오고 있고요.

서버는 초기에 Supabase를 사용하다가, 동시 접속자가 급증하면서 오라클 클라우드(Oracle Cloud)로 이전했어요. 마침 남편이 서버 개발자라 그 부분에서 도움을 많이 받았습니다.

처음 링크드인에 소개한 온라인 담타 <출처: 고서진 님 링크드인 포스트>

Q. 온라인 담타가 단순한 재미를 넘어, 일종의 소셜 공간같기도 해요. 이런 반응은 어떻게 보셨나요?

저도 그런 점이 흥미로웠어요. 온라인 담타는 익명성이 있고, 채팅도 그때 보지 않으면 스크롤해서 다시 볼 수 없잖아요. 올라갔다가 사라지는 구조이다 보니, 오히려 사람들이 마음 편하게 이야기할 수 있었던 것 같아요. 너무 무겁게 기록으로 남는 공간이 아니라, 잠깐 들어와서 이야기하고 흘려보낼 수 있는 공간이 된 거죠. 그런 휘발성이 온라인 담타의 분위기를 만드는 데 꽤 중요한 역할을 했다고 생각해요.

Part 3. 프로덕트 디자이너의 개발 도전기

Q. 혼자 서비스를 만들면서 가장 어려웠던 점은 무엇이었나요?

개발하며 중간중간 막히는 지점들이 있었어요. 특히 애니메이션이 제 뜻대로 구현되지 않아 토큰만 계속 소모되는 상황이 반복됐는데요. 그때는 단순히 프롬프트만 다시 입력하는게 아니라, AI가 생성한 코드를 직접 들여다보면서 “지금 얘가 opacity를 이렇게 정의하고 있구나, z-index를 재조정해줘야겠다”라는 식으로 원인을 파악하고, 더 구체적으로 지시했어요.

이런 방식이 가능했던 건 프로덕트 디자이너로서 기획자, 프론트엔드 개발자들과 오래 협업해 온 경험 덕분인 것 같아요. 프로덕트 디자이너는 개발에 대한 기본적인 이해가 어느 정도 필요하다 보니, 그런 경험들이 장점으로 작용했던 것 같아요.

Q. 디자이너로서의 경험이 도움이 됐던 부분도 있나요?

디자이너로서 느끼는 장점도 많았어요. 예를 들어, “조금 더 작게 해줘”라고 말할 수도 있지만, 디자이너는 “하단에서 몇 픽셀 올려줘”, “최소·최대 두께를 이렇게 조정해줘”처럼 더 구체적으로 말할 수 있잖아요. AI는 픽셀 단위로 생각하지 않고, rem 단위로 구현할 때도 있거든요. 그래서 그런 부분은 코드를 보면서, 필요하면 코드 자체를 직접 수정하기도 했어요. 결국 AI에게 잘 맡기는 것도 중요하지만, AI가 어떤 기준으로 만들고 있는지 파악하는 게 중요하다고 느꼈죠.

Q. 런칭 이후에도 업데이트가 계속되고 있는데, 그 원동력은 무엇인가요?

아무래도 가장 큰 원동력은 “찾아주시는 분들을 실망시키고 싶지 않다”는 마음이에요. 작년 말에 하이닉스나 삼성처럼 비흡연 사업장에 계신 분들이 한꺼번에 많이 들어오신 적이 있었는데요. 그분들을 실망시키고 싶지 않더라고요.

그리고 솔직히 바이브 코딩 자체가 너무 재밌어요. 프로덕트 디자이너로 일하다 보면 아이디어 하나를 구현하기 위해 윗분을 설득하고, 개발자와 소통하는 과정이 계속 이어지잖아요. 그런데 이건 제가 꿈꾸는 대로 직접 실현해 볼 수 있으니까요. 유저 피드백은 지금까지 ‘의견 보내기’ 채널에 600개 넘게 쌓였는데요. 엑셀로 정리한 뒤 AI에게 분류를 맡기고, 많이 언급됐거나 재밌어 보이는 의견을 골라 업데이트하는 방식으로 운영하고 있어요. ASMR 기능이나, 화면에서 담배 모양을 안 보이게 하는 ‘스텔스 모드’ 같은 기능도 그렇게 탄생했습니다.

온라인 담타 릴리즈노트 <출처: 업데이트 노트>

Q. 유저 피드백 중에 실제로 만들어봤지만 넣지 않은 기능도 있었나요?

전자담배 아이디어도 있었어요. 실제로 만들어보기도 했는데, 생각보다 기능의 복잡성이 많이 올라가더라고요. 그래서 배포까지 가진 못했어요. 제 생각에 온라인 담타 유저분들은 담배를 선택하거나 조작하는 것보다, 그 안에서 채팅하고 분위기를 즐기는 데 더 재미를 느끼는 것 같았거든요. 그래서 지금은 기능을 많이 늘리기보다, 사람들이 편하게 대화하고 쉬는 경험에 더 집중하려고 해요.

Part 4. 바이브 코딩과 디자이너의 역할 변화

Q. 직접 바이브 코딩을 경험해보신 만큼, 디자이너의 역할 변화도 체감하셨을 것 같아요. 어떻게 보고 계신가요?

이미 주변에서도 커서(Cursor)나 클로드(Claude)를 활용해 디자인부터 프론트엔드 개발까지 혼자 맡는 분들이 생겼어요. 예전에는 웹플로우(Webflow)나 프레이머(Framer) 같은 노코드 툴이 그런 역할을 했다면, 지금은 그 자리를 커서와 클로드가 대체하고 있다고 봐요.

이 방식의 가장 큰 강점은 초안을 빠르게 만들 수 있다는 점이에요. 또 디자인 QA와 커뮤니케이션 비용이 거의 사라진다는 것도 큰 장점이고요. 물론 아직은 AI스러움이 남아 있어서, 디자이너의 손을 거쳐야 하는 부분도 있습니다. 다만 그 범위는 확실히 줄어들고 있고, 이제는 한 명이 두세 명 몫의 일을 할 수 있는 시대가 되어 가고 있는 것만은 분명한 것 같습니다.

Figma Make를 활용한 온라인 담타 <출처: 바이브코더스 인터뷰 화면>

Q. 실제 회사 업무에서도 AI를 활용하는 방식이 달라지고 있나요?

현재 근무 중인 GBIKE에서는 특히 신사업부 팀이 AI로 업무 프로세스 자체를 크게 바꾸고 있고요. 기존 사업부에서도 UX 허점을 찾거나, 내부 설득 근거를 만드는 데 AI를 활용하는 식으로 변화가 생기고 있어요.

MCP를 활용해 어노테이션을 빠르게 달거나, 레이어를 정리하는 작업에도 쓰고 있고요. 이미지 생성 AI도 많이 활용하고 있습니다. 앞서 이야기한 견인 구역 안내 이미지도 AI로 만들어서, 사용자분들이 더 쉽게 알아볼 수 있도록 제공하고 있어요. 아직은 모든 걸 AI가 대체한다기보다, 각자의 역량을 높이는 방향으로 함께 가고 있는 것 같습니다.

Part 5. 바이브 코딩으로 얻은 새로운 기회

Q. 온라인 담타를 앞으로 어떻게 발전시켜 나갈 계획인가요? 수익화도 고민하고 계신가요?

수익화 관점에서도 계속 고민하고 있는데요. 사용자 경험을 놓치지 않으면서, 어떻게 수익화를 할 수 있을지가 가장 충돌되는 부분인 것 같아요. 저는 온라인 담타라는 서비스의 단순함이 가장 큰 매력이라고 생각해요. 그래서 무언가를 추가하거나 광고를 붙일 때도, 그 단순한 매력을 해치지 않는 게 가장 중요한 기준입니다.

전 직장에서 배운 것처럼, 광고가 꼭 나쁜 경험일 필요는 없거든요. ‘마침 내가 필요로 하던 게 여기 있네’ 하고 자연스럽게 연결되는 광고라면, 오히려 좋은 경험이 될 수 있다고 생각해요. 그래서 온라인 담타에 어울리는 방식이 무엇인지 계속 고민하고 있습니다.

또 업데이트로 지구 밖, 야구장 같은 다양한 방을 운영하는 것도 단순한 콘텐츠 확장만은 아니에요. 이용자분들의 관심사를 모아서, 앞으로 어떤 콘텐츠를 보여드릴 수 있을지 파악하기 위한 목적도 있습니다. 결국 수익화와 사용자 경험 사이에서 균형을 찾아가는 과정에 있다고 생각해요.

Q. 마지막으로, “나도 뭔가 만들어보고 싶다”는 독자분들에게 한마디 해주신다면요?

지금은 정말 생각을 실현하기 좋은 시대인 것 같아요. 주변을 보면 친구들과 일상 사진을 공유하는 앱이나, 걸음 수를 캐릭터로 보여주는 만보기 앱처럼, 별것 아닌 아이디어처럼 보이는 서비스들이 정말 많은 분들의 공감을 얻고 있거든요.

온라인 담타도 마찬가지예요. 사실 온라인에서 담배를 피우는 척하는 서비스인데, 여기에 어떤 콘셉트와 재미를 담느냐가 핵심인 것 같아요. IT 직군에 계신 분들은 재미있는 아이디어를 정말 많이 갖고 계시거든요. 그런데 이제는 “시간이 없어서”, “몰라서”라는 핑계를 대기 어려운 시대가 됐어요. 저도 1년 넘게 아이디어만 품고 있다가, 피그마 메이크(Figma Make) 덕분에 시작하게 됐는데요. 너무 부담 갖지 말고 편하게 한 번 시작해 보시면 좋겠습니다. 저처럼 갑자기 빵 터져서 생각지도 못한 소중한 경험을 하실 수도 있으니까요.

마치며

지금까지 프로덕트 디자이너로서 Figma Make를 활용해 온라인 담타를 만들고, DAU 28만 명 규모의 서비스로 키워낸 고서진 님의 이야기를 들어봤습니다. 디자이너 혼자 시작한 작은 아이디어가 많은 사람의 공감을 얻고, 지금도 꾸준히 업데이트되며 하나의 서비스로 운영되고 있다는 점이 인상적이었는데요.

서진 님이 거듭 강조한 지점은 단순히 AI 도구를 잘 쓰는 기술이 아니었습니다. 사용자를 실망시키고 싶지 않은 마음, 서비스의 단순한 매력을 지키려는 기준, 그리고 아이디어를 더 이상 미루지 않고 직접 실행해보는 태도에 가까웠습니다. 이런 관점은 Figma Make가 아니더라도, 앞으로 어떤 AI 도구를 쓰게 되든 오래 유효하겠다는 생각이 들었습니다.

이제 더 이상 ‘코딩을 몰라서’라는 핑계가 통하지 않는 시대입니다. 마음속에만 품고 있던 아이디어가 있다면, 지금 가장 먼저 만들어보고 싶은 것은 무엇인가요?

]]>

하네스 엔지니어링으로 AI 에이전트를 길들여봤습니다

나는 AI 에이전트를 실제 프로젝트에 붙여 쓰는 과정을 반복하면서, 프롬프트가 아니라 워크플로우를 설계해야 한다는 인사이트를 얻었다. (참고) 그래서 14개 에이전트, 6단계 사고 모델, /start → /done 워크플로우까지 만들어 실제 프로젝트에서 돌렸다. 분명 잘 돌아갔는데, 문제가 있었다.

"git add -A 쓰지 마"라고 써놨는데 썼다.
"rm -rf는 위험하니까 실행하지 마"라고 했는데 실행했다.

프롬프트에 굵은 글씨로 절대 하지 말라고 적어놔도, 에이전트는 가끔 그냥 한다. 이게 프롬프트 엔지니어링의 한계다. 아무리 정교하게 써도, 결국 “부탁”일 뿐이다. 그래서 나는 부탁하는 걸 그만뒀다. 대신 에이전트가 실행되는 환경 자체를 설계하기 시작했다. 프롬프트가 아니라 시스템으로 통제하는 거다.

나중에 보니 업계에서는 이를 ‘하네스 엔지니어링’이라고 부르고 있었다. 하네스는 모델 바깥에서 에이전트가 어떻게 실행되고, 어떤 도구를 쓰며, 어디서 멈춰야 하는지를 통제하는 구조를 뜻한다. OpenAI가 올해 2월에 이 개념을 소개했고, 소프트웨어 아키텍처와 리팩토링 분야의 권위자 마틴 파울러도 이 주제를 다뤘다. 이 글은 그 여정에 대한 기록이다.

규칙이 많으면 에이전트가 오히려 못 따른다

6단계 사고 모델은 인지적 도제 이론에서 출발했다. 대장간에서 장인이 견습생을 가르치는 과정에서 착안했다. 시연하고, 코칭하고, 보조를 줄여가며, 독립시키는 흐름을 에이전트에 적용해 본 것이다. 읽고, 반응하고, 분석하고, 재구조화하고, 구조화하고, 성찰하는 흐름이다. 이론적으로는 깔끔했다.

근데 실무에서 세 가지가 터졌다.

토큰 낭비: 버튼 색상 바꾸는 건데 “현재 구조를 분석합니다...” 이러고 있더라. 이전에 “100개 규칙보다 1개의 올바른 원칙이 더 강력하다”고 느꼈는데, 사고 모델도 마찬가지였다.
경계 모호: READ와 REACT의 차이가 뭔가. 나도 설명이 애매한데, 에이전트가 구분할 수 있을까. 모호한 단계를 두면 “어디에 속하는지 판단하느라” 토큰을 써버린다.
실패 루프 없음: 검증에서 lint가 터지면? 처음부터 6단계를 다시 밟아야 하나. 실패했을 때 어디로 돌아갈지가 정의되어 있지 않았다.

4단계로 줄였더니

<출처: 작가, 제미나이로 생성>

GROUND → APPLY → VERIFY
  ↑                 ↓
  └─── ADAPT ←──────┘
       (실패 시만)

GROUND: 먼저 코드를 읽는다. 기억에서 추론하지 않는다. 이게 가장 중요하다.
APPLY: 관찰한 패턴대로 구현한다. 5가지 불변 제약이 있다. 읽기 우선, 패턴 준수, 정책 보존, 최소 변경, 스코프 준수.
VERIFY: lint/tsc/테스트를 돌린다. 사람 눈이 아니라 도구로 확인한다.
ADAPT: 여기가 핵심이다. 6단계 모델에는 없던 것이다. VERIFY에서 실패하면 “왜 실패했는지”를 분석하고 GROUND로 돌아간다. 같은 원인으로 2번 실패하면 접근법을 바꾸고, 3번 실패하면 사람에게 판단을 넘긴다.

4개 파일 수백 줄이 1개 파일 99줄이 됐다. 에이전트는 오히려 더 잘 따랐다. 이 경험이 이후 모든 설계의 기준이 됐다. 복잡해지면 줄여라. 줄였는데도 잘 된다면, 원래 그만큼만 필요했던 거다.

팀에서 쓰려니까 전부 다 문제였다

사고 모델을 단순화하니까 더 큰 문제가 보였다. Emotion 패턴, Next.js Pages Router 가정, Jotai 컨벤션이 규칙 파일에 하드코딩되어 있었다.나 혼자 쓸 때는 괜찮았다. 하지만 팀에서 쓰려면 이야기가 달라진다. A 프로젝트는 Zustand를 쓰고, B 프로젝트는 Redux를 쓰며, 새 프로젝트는 Tailwind를 쓴다. Jotai 컨벤션이 박혀 있는 설정을 줘봐야 의미가 없다.

하드코딩을 모듈로 쪼갰다

그래서 스택 컨벤션을 modules/ 디렉터리로 추출했다. React, Vue, Jotai, Zustand, Emotion, Tailwind를 각각 독립된 파일로 분리하고, 프리셋으로 조합하는 구조로 바꿨다.

{
  "modules": {
    "framework": "react-nextjs-app",
    "state": "zustand-tanstack",
    "styling": "tailwind",
    "testing": "vitest"
  }
}

현재 13개 모듈이 있다. 프레임워크 3종, 디자인 시스템 2종, 상태 관리 3종, 스타일링 3종, 테스팅 2종이다. 목록에 없는 라이브러리가 감지되면 옵션에 자동으로 추가되고, 직접 입력도 가능하다. 에이전트와 사고 모델은 동일하게 두고, 스택만 바꾸면 된다.

그런데 배포가 문제였다

모듈을 분리하니까 이번엔 “어떻게 전파하지?”가 문제였다. 처음에는 에이전트 설정을 별도 Git 레포로 관리했다. 팀원들에게 “이 레포 주소 줄 테니까 클로드한테 주고, 지금 프로젝트에 맞게 설정해달라고 하면 됩니다”라고 했다.

당연히 사람마다 설정이 달라졌다. 그리고 더 큰 문제는 동기화였다. 설정 레포에서 에이전트 규칙을 업데이트해도, 이미 각 프로젝트에 복사해 놓은 파일은 구버전 그대로였다. “설정 레포 최신 커밋 읽어서 지금 프로젝트에 반영해줘”를 매번 해야 했다. PR 트리거나 GitLab 훅으로 자동 동기화까지 고민했지만, 근본적인 해결은 아니었다.

플러그인이라는 해결책

그러던 중 Claude Code가 플러그인을 공식 지원하기 시작했다. claude plugin install로 한 번 설치하면 끝이다. session-init.sh라는 SessionStart 훅이 세션을 열 때마다 리모트 버전을 확인하고, 변경이 있으면 자동으로 pull해서 업데이트한다. 배포 문제가 한 방에 해결된 거다.

그래서 모든 걸 플러그인으로 전면 교체했다. 이게 code-forge, AI 대장간의 시작이다. 기존 프로젝트에서 /setup을 실행하면 package.json을 읽어 스택을 자동 감지하고, profile.json에 기록한 뒤 그에 맞는 CLAUDE.md를 생성한다. 새 프로젝트라면 프리셋을 선택해 처음부터 세팅해준다.

에이전트를 "컴파일"하다: 대장장이의 탄생

컨벤션을 모듈로 분리하면서 동시에 떠오른 생각이 있었다. “모듈로 분리할 수 있다면, 에이전트도 조합하고 컴파일할 수 있지 않을까?”당시 읽고 있던 클린 아키텍처와 동료와의 대화에서 아이디어를 얻었다. 에이전트를 STATE(이 에이전트가 아는 것)와 ACT(이 에이전트가 하는 것)로 나누는 거다.

기존에는 에이전트 하나에 모든 걸 다 써야 했다. 14개 에이전트에 “React를 안다”, “TypeScript를 안다” 같은 내용이 중복으로 들어가 있었다. 하나를 바꾸려면 14개를 다 바꿔야 한다. 이건 앞서 컨벤션이 하드코딩되어 있었던 문제와 똑같은 구조였다.

STATE/ACT로 분리하면 이렇게 조합할 수 있다.

code-reviewer = lang.typescript + framework.react + quality.review
implementor   = lang.typescript + framework.react + dev.implement

이 조합 시스템을 Smith(대장장이)라고 이름 붙였다. 대장장이가 재료(STATE)와 기법(ACT)을 조합해 도구를 만들듯, Smith는 지식과 행동을 조합해 에이전트를 만든다. 만들어진 에이전트는 Anvil(작업대) 위에서 사용자와 함께 코드를 단조한다.

처음에는 런타임 해석 방식이었다. 매 세션마다 규칙 파일을 주입하고, spawn할 때마다 STATE 체인을 재귀적으로 재계산했다. 28개 파일을 이중으로 관리해야 했고, 권한(permissionMode)이 심링크에서 동작하지 않는 버그까지 발생했다.

그때 떠오른 생각이 단순했다.

TypeScript를 매번 런타임에 해석하는 사람은 없다. tsc로 .js를 만들어 놓고 쓰는 거지.

에이전트도 빌드타임에 컴파일하면 되는 거였다. /smith-build로 STATE+ACT 체인을 미리 계산해 정적 .md 파일로 만들어 두는 방식이다.

<출처: 작가, 제미나이로 생성>

런타임 인프라를 전부 삭제했다. “복잡성을 제거”한 게 아니라, “복잡성을 빌드타임으로 옮긴” 것이다.

단일 진입점

“로그인 페이지 만들어줘”라고 하면 만들어준다. 그런데 문제는 매번 다르게 만든다는 거다. 어떤 때는 코드 분석부터 하고, 어떤 때는 바로 파일을 생성하고, 어떤 때는 테스트를 쓰고, 어떤 때는 안 쓴다. 워크플로우를 스킬로 만들어 놓으면 어떤 입력이 들어와도 같은 순서로 진행된다.

/start feature-login.md

MD 파일 하나면 된다. 이걸 주면 /start가 분석 → 디자인 확인 → 구현 → 테스트 → 린트 → 커밋 → PR까지 수행한다. 중간에 사용자가 확인하는 건 딱 두 번이다. “구현할까요?”, “커밋할까요?”

<출처: 작가, 제미나이로 생성>

입력 형태도 가리지 않는다. MD 파일이든 Figma URL이든 이미지 캡처든, 같은 진입점으로 들어와 같은 워크플로우를 탄다. 여기까지가 프롬프트 레벨의 이야기다. 규칙을 만들고, 모듈로 나누고, 에이전트를 컴파일하고, 워크플로우를 정의했다. 그런데 이 모든 것이 “부탁”이라는 본질적 한계를 넘지는 못했다.

하네스 엔지니어링: 진짜 문제는 여기였다

여기서부터가 이번 글의 핵심이다. 워크플로우를 아무리 잘 만들어도, 프롬프트를 아무리 정교하게 써도, 에이전트가 “그냥 무시”하는 경우가 생긴다. 프롬프트는 결국 자연어다. 자연어로 된 지시는 강제력이 없다. 프롬프트가 쓸모없다는 게 아니다. 프롬프트만으로는 부족하다는 것이다.

그래서 하네스 엔지니어링으로 전환했다. 하네스(harness)는 원래 말에 씌우는 마구(馬具)라는 뜻이다. AI 에이전트의 출력을 원하는 방향으로 강제하는 전체 시스템 설계 기법이다. 프롬프트를 잘 쓰는 게 아니라, 에이전트가 실행되는 환경 자체를 설계하는 것이다.

핵심 주장은 하나다.

“프롬프트 엔지니어링만으로는 AI 출력을 강제할 수 없다. hooks라는 시스템 레벨 이벤트 핸들러로 무조건 실행되도록 강제해야 한다.”

Claude Code의 hooks는 에이전트의 생명주기(세션 시작, 도구 실행 전/후, 응답 완료 등)에 셸 스크립트나 LLM 판단을 끼워 넣을 수 있는 메커니즘이다. 에이전트가 Bash를 실행하려 할 때 guard.sh가 먼저 실행되어 위험한 명령을 차단하고, 파일 수정 후에는 lint-fix.sh가 자동으로 포맷을 맞추는 식이다.

하네스 3층 구조

code-forge의 하네스는 3층으로 구성된다.

Layer 1이 핵심이다. Claude든 Codex든 Cursor든, 어떤 모델이 코드를 작성하더라도 같은 시스템 레벨 가드레일이 적용된다. 프롬프트는 무시할 수 있어도 hooks는 무시할 수 없기 때문이다.

<출처: 작가, 제미나이로 생성>

비유하자면 이렇다.

Layer 1(hooks): 건물의 소방 스프링클러. 누가 불을 질러도 자동으로 동작한다.
Layer 2(프롬프트): 건물 내 “금연” 표지판. 대부분은 따르지만 강제력은 없다.
Layer 3(에이전트): 각 방의 출입 카드. 권한이 없으면 들어갈 수 없다.

exit 0 스텁 5개에서 실동작 11개까지

솔직히 말하면, 처음에 hooks는 껍데기에 불과했다.

# guard.sh (Before)
#!/bin/bash
exit 0

4줄짜리 스텁 5개였다. “나중에 채우자”고 해놓고 몇 달을 그냥 뒀다. 하네스를 설계한다고 했지만, 실제로는 프롬프트 레벨에만 의존하고 있었던 것이다.

리팩터링을 하면서 기존 5개를 채우고, 6개를 더 만들었다.

guard.sh는 52줄이다. Claude Code 훅은 에이전트가 도구를 실행하기 직전에 JSON 형태로 입력을 넘긴다. 처음에는 단순 문자열 매칭으로 처리했지만, 리팩터링하면서 JSON을 파싱해 명령어를 정확히 추출하도록 바꿨다.

# guard.sh (After) — JSON 파싱 + 9개 위험 패턴 차단
COMMAND=$(echo "$HOOK_INPUT" | python3 -c "import sys,json; print(json.load(sys.stdin).get('tool_input',{}).get('command',''))")

# 차단 패턴 예시
if echo "$COMMAND" | grep -qE "git add \.|git add -A"; then
  echo "BLOCKED: git add . / -A 금지. 파일을 명시적으로 지정하세요."
  exit 2
fi

Prompt 핸들러: regex로 못 잡는 걸 LLM이 잡는다

여기서 흥미로운 게 하나 있다. 정규표현식으로 위험 명령을 차단하는 건 결국 “내가 생각한 패턴”만 막는다는 뜻이다. rm -rf /는 막는데 find / -delete는? git push --force는 막는데, 한국어로 “강제 푸시해줘”라고 하면?

Claude Code 훅에는 command 타입 말고, prompt 타입이 있다. 훅 자체를 LLM 호출로 처리하는 방식이다.

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [
        { "type": "command", "command": "guard.sh" },
        { "type": "prompt", "prompt": "이 Bash 명령이 되돌리기 어려운 파괴적 작업인지 판단해라. 그렇다면 차단해라." }
      ]}
    ]
  }
}

command 훅은 속도가 빠르고 확실하다. 알려진 패턴은 즉시 차단한다. prompt 훅(haiku 기반)은 느리지만 의미를 이해한다. 두 개를 레이어로 쌓았다. regex가 놓치는 부분을 LLM이 잡는다.

새로운 이벤트 타입들: SubagentStop, PreCompact

SubagentStop은 서브 에이전트가 작업을 마쳤을 때 발생하는 이벤트다. 여기에 tsc를 걸었다.

왜 Stop이 아니라 SubagentStop인가. /start 워크플로우는 implementor, assayer 같은 서브 에이전트를 순차적으로 spawn한다. Stop은 세션 전체가 끝날 때 발생하는데, 그 시점에 tsc를 돌리면 이미 다음 단계가 진행 중일 수 있다. 각 에이전트가 끝날 때마다 타입 체크를 돌려야 오류를 즉시 잡을 수 있었다.

PreCompact는 컨텍스트 압축 직전에 발생한다. 긴 세션에서 Claude가 컨텍스트를 압축하면 작업 중간 상태가 날아가는 경우가 있었다. 여기에 pre-compact.sh를 달아 현재 브랜치, 미커밋 파일, 스테이지 상태를 스냅샷으로 주입한다. 압축 후에도 복귀 지점이 남는다.

lint-fix.sh도 채웠다. 파일 수정 후 exit 0으로 그냥 넘기던 것을, ESLint --fix + Prettier --write를 자동으로 실행하고 오류가 남으면 경고를 출력하도록 바꿨다.

Stop hook의 quality-gate.sh는 응답이 완료될 때마다 eslint --quiet와 tsc --noEmit를 실행한다. 에이전트가 아무리 “잘 됐다”고 해도 린터가 최종 확인하는 구조다.

이런 식으로 5개 스텁에서 11개 실동작으로 늘었고, 총 441줄이 됐다.

AGENTS.md: 멀티모델 컨벤션

hooks로 시스템 레벨을 잡았다면, AGENTS.md는 멀티모델 컨벤션을 담당한다. Claude Code만 쓰던 프로젝트에 Codex CLI를 투입하면 어떨까. 기존에는 CLAUDE.md를 읽지 못해서, 컨벤션을 모르는 상태로 코드를 작성했다. 그러면 린터가 터지거나 스타일이 달라지기도 했다.

AGENTS.md는 AAIF(Agentic AI Foundation) 표준에 맞춘 파일이다. OpenAI와 Anthropic이 2025년 12월 Linux Foundation에 공동 기증한 에이전트 설정 표준으로, Codex CLI와 Cursor가 네이티브로 읽는다.

CLAUDE.md (Claude 전용)
  └── @AGENTS.md 임포트

AGENTS.md (공용, AAIF 표준)
  └── Codex CLI ← 네이티브로 읽음
  └── Cursor   ← 네이티브로 읽음

/setup이 2개 파일을 동시에 생성한다. AGENTS.md에는 스택, 명령어, 컨벤션, 금지 규칙이 들어가고, CLAUDE.md는 이를 임포트한 뒤 Claude 전용 설정을 추가한다.

결과적으로 클로드를 쓰든, 코덱스를 쓰든, 커서를 쓰든 같은 하네스를 따르면 같은 아웃풋이 나온다.프롬프트 레벨(AGENTS.md)에서 안내하고, 시스템 레벨(hooks)에서 강제하는 구조다.

하나의 모델만 쓰면 맹점이 생긴다

하네스 엔지니어링과 함께 2026년의 핫 키워드가 하나 더 있다. 멀티모델이다. 혼자 만든 시스템에는 맹점이 생긴다. 같은 Claude 모델끼리는 비슷한 편향을 공유하기 때문이다. 나는 이걸 실제로 느꼈다. code-forge를 만들면서 가장 많이 쓰는 기능이 Agent Teams로 계획을 세울 때 Codex(GPT)에게 함께 검증을 맡기는 부분이었다.

Claude가 짠 구현 계획을 Codex에게 보여주면, 다른 시각에서 허점을 찾아낸다. 그것도 부족하다 싶으면 Critic 에이전트를 세워 심판을 보게 한다. 루프를 돌며 3라운드 토론을 붙이기도 한다. 경험적으로 확실했다. 하나의 모델이 혼자 결정할 때보다, 비판적 의견이 들어갔을 때 더 좋은 결과가 나온다.

그래서 멀티모델 지원이 필수라고 판단했다. Codex도 이 프로젝트의 사고 모델을 적용받고, 같은 하네스 안에서 돌아간다면 더 좋은 결과로 이어질 수 있지 않을까. 그게 앞서 말한 AGENTS.md가 나온 이유다. Claude만 읽는 CLAUDE.md가 아니라, 어떤 모델이든 읽을 수 있는 공용 표준이 필요했다.

실제 토론 사례

구조 검증 토론: Codex에게 프로젝트를 보여줬더니 CONDITIONAL REJECT가 왔다. “참조 파일 2개가 중복이고, @참조 매트릭스가 과도하다.” Critic(Claude Opus)이 반론했다. “무조건 줄이는 게 답이 아니다.” 이 토론으로 중복은 정리하되, 역할별 참조는 유지하는 균형을 찾았다.
v3.0 방향성 토론: Builder(실용) vs Visionary(비전) vs Critic(비판)의 3라운드였다. Critic의 한마디가 방향을 잡았다. “새로 만들 것은 최소한으로. 있는 것을 채우고 다듬는다.”

이 말이 hooks 실구현으로 이어졌다. “새로 만들 것”(새 기능)보다 “있는 것을 채우는 것”(스텁을 실동작으로)이 우선이었기 때문이다.

AI와의 토론도 사람과의 토론과 같은 구조를 따른다: 입장이 다른 참여자가 있어야 하고, 비판자가 있어야 하며, 최종 판단은 사람이 해야 한다.

이 멀티모델 협업도 결국 하네스의 한 층이다. 모델마다 다른 시각을 갖되, 같은 규칙 안에서 움직이게 만들어야 한다.

대장간 체계

대장간 메타포는 처음부터 의도한 것이 아니었다. 사고 모델을 설계할 때 떠올렸던 인지적 도제 이론을 시스템 전체로 확장하다 보니, 각 구성 요소에도 자연스럽게 이름이 붙었다.

<출처: 작가, 제미나이로 생성>

Forge (대장간)     = code-forge 전체
Smith (대장장이)   = 에이전트 빌드 시스템 — 재료(STATE)와 기법(ACT)을 조합해서 도구(에이전트)를 단조
Blueprint (설계도) = 사고모델, 규칙 — 모든 작업의 기준이 되는 도면
Assayer (감정사)   = 테스트 생성/검증 — 결과물의 품질을 판별
Bellows (풀무)     = 사용량 로깅 + 통계 — 불의 온도를 감지하듯 사용 패턴을 관찰하여 개선 방향을 제시
Whetstone (숫돌)   = 코딩 연습 — 개발자의 실력을 갈고닦는 도구

컨셉이 먼저는 아니었다. “이 기능은 대장간의 어디에 해당하지?”라고 물으면 불필요한 기능이 걸러졌다. 네이밍이 설계 도구가 된 셈이었다.

코딩 근육은 따로 단련해야 한다

AI가 코드를 잘 짜주는 건 좋은데, 문득 불안해졌다. Copilot을 켜놓고 Tab만 누르다 보면 직접 코드를 치는 감각이 무뎌지기 마련이다.

Whetstone(숫돌)은 이 문제에 대한 답이다. 4단계 힌트 시스템으로, 처음에는 힌트를 많이 주고 점진적으로 줄이면서 독립 해결까지 끌어올린다. 이것도 하네스의 일종이다. 힌트라는 보조 장치를 점진적으로 제거하면서 개발자의 독립적인 문제 해결력을 키우는 구조다. 지금은 별도 플러그인으로 분리해 발전시키고 있다.

대장간이 완성되기까지

<출처: 작가, 제미나이로 생성>

돌아보면 가장 큰 효과를 준 건 두 가지였다.

하나는 단순화다. 6단계 → 4단계. 수백 줄 → 99줄. 런타임 해석 → 빌드타임 컴파일.
다른 하나는 실동작이다. 껍데기를 실제 동작으로 채우는 것이다. exit 0 스텁을 9개 패턴을 차단하는 가드레일로 바꾸고, 문서에만 있던 Stop hook을 quality-gate.sh로 구현했다.

이 두 가지가 합쳐져 하네스 엔지니어링이 됐다. 단순하게 설계하고, 단순하게 채운다.

아직 만들고 있다

대장간은 한 번 지으면 끝이 아니다. 새로운 재료가 들어오면 도구도 바뀌고, 공정도 바뀐다. 나는 결국 나를 닮은 대장간을 만들고 싶었던 것 같다. 새로운 서비스를 만들 때도, 기존 서비스를 분석하고 유지보수할 때도, 어떤 재료가 들어와도 같은 품질의 결과물이 나오는 곳. 분석하고, 단조하고, 검증하고, 다듬는 모든 동작이 하나의 공정 안에서 돌아가는 곳이 필요했다.

글의 초반에도 말했듯이 프롬프트로 부탁하는 건 한계가 있다. 대장간의 답은 단순하다. 부탁하지 않는다. 환경이 강제한다. 화로에 불은 넣었다. 아직 꺼질 생각은 없다. 풀무도 더 키우고, 보안 스캔도 붙이고, 숫돌도 계속 갈아야 한다. 더 좋은 재료가 있다면 대장간 문은 항상 열려 있다.

<참고>

code-forge GitHub

<원문>

프롬프트 엔지니어링은 끝났다 — 하네스 엔지니어링으로 AI 에이전트를 길들인 이야기

]]>

개발자의 커서 3 후기, 그들은 왜 따라가기 바쁠까?

Cursor 3 런칭 후 2주 동안 써봤습니다

들어가기에 앞서, 저는 Cursor(이하 커서)를 약 2년 동안 사용해 왔습니다. 회사에서 비용을 지원해 주지 않을 때도 개인 비용으로 결제해 쓸 만큼, 커서를 좋아하는 편입니다.

특히 커서의 Tab 자동완성 기능을 인상 깊게 사용했는데요. 제가 작성하려던 코드의 흐름을 자연스럽게 이어주기도 하고, 때로는 미처 생각하지 못한 로직이나 수정이 필요한 지점을 먼저 짚어주기도 했습니다. 커서가 해당 라인으로 이동해 Tab 입력을 기다리고 있을 때면, 매번 감탄하며 즐겁게 코딩하곤 했습니다. 그런 점에서 저에게 커서는 단순한 개발 도구가 아니었습니다. 개발 멘토이자 동반자였고, 저보다 한발 먼저 코드를 읽고 길을 알려주는 선지자(Fast Mover)같은 존재였습니다.

이처럼 기대와 믿음을 주던 커서가 이번에 커서 3를 출시했습니다. 개인적으로는 커서가 다른 도구와 무엇으로 경쟁할지, 어떤 차별점을 내세울지 궁금했습니다. 그래서 2주가량 클로드 코드를 잠시 내려놓고, 커서 3만 사용해 사이드 프로젝트를 구현해 보았습니다.

테스트 조건은 다음과 같습니다.

클로드 코드와 달리 별도의 세부 설정은 하지 않았고, 커서 자체가 기본으로 제공하는 기능만 사용했습니다.
최근 AI 구독 비용이 빠르게 오르고 있어, 커서는 여전히 애정하지만 현재는 20달러 요금제를 사용하고 있습니다.

커서 3의 새로운 기능

이번 메인은 바로 Agent Window입니다. 기존 IDE에서 벗어나, Agent만을 위한 새로운 인터페이스를 만들었다는 의미로 보입니다.

커서3 Agent Window <출처: 작가>

1) 전반적으로 깔끔한 UI

개발자는 개인 성향에 따라 CLI(Command-Line Interface) 혹은 GUI(Graphical User Interface)를 선호합니다. 특히 젊은 연차이거나 프론트엔드에 가까울수록, 따로 명령어를 배워야 하는 CLI보다 단순하고 직관적인 GUI를 좋아한다고 생각합니다.

그런 기준에서 클로드 코드의 터미널 사용 경험은 저에게 상당히 거칠게 느껴졌습니다.

커서3(왼쪽)와 클로드 코드(오른쪽) 비교 <출처: 작가>

물론 클로드 코드 앱이나 다른 플러그인을 붙인다면 얘기가 달라질 수 있지만, 우선 가장 근본이 되는 기본 설정을 기준으로 비교하고자 합니다.

커서3의 /(slash) 인터페이스 <출처: 작가>

커서3의 Diff 인터페이스 <출처: 작가>

위 이미지를 보면 UI가 깔끔하다는 말이 절로 나옵니다. 전반적으로 무난하면서도 부드럽고 정돈된 UI입니다. 다만 제가 확인한 바로는 아직 3개의 테마만 지원하고 있습니다. VS Code의 테마를 그대로 가져와 다양한 테마를 사용할 수 있을 거라 기대했는데, 이 부분은 조금 아쉬웠습니다.

그리고 마지막으로, IDE 모드에서 생성한 대화는 Agent Window 모드에서도 확인이 가능합니다. 하지만 반대로 Agent Window에서 시작한 대화는 IDE 모드에서는 노출되지 않습니다.

커서3의 채팅 공유 <출처: 작가>

2) 페어프로그래밍 인터페이스의 초안

지난 글 ‘코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일’에서 40년차 빅테크 개발자 분은 AI와 함께 페어 프로그래밍을 하고 있다고 말하며, 페어 프로그래밍의 중요성을 강조했습니다. 저 역시 그 의견에 매우 공감했는데요. 한 달 뒤 커서 3에서 비슷한 느낌의 인터페이스가 등장했습니다.

커서3의 인터페이스 <출처: 작가>

아직은 페어 프로그래밍이라고 하기엔 간단한 Diff만 보여주는 UI에 가깝지만, 저는 개인적으로 근시일 내에 해당 인터페이스에서 Agent Review가 적절한 단위로 수행될 것이라고 생각합니다. AI가 엄청나게 많은 코드를 쏟아내는 만큼, 특정 라인의 코드 변경 사항에 대해 AI가 짧게나마 리뷰해 준다면, 전체 변경 사항을 이해하지 않더라도 해당 라인만 작은 PR Review를 하는 느낌을 줄 수 있기 때문입니다.

게다가 커서가 내세우는 장점 중 하나인 “우리 모델은 빠르고 코딩에 특화되어 있다”라는 점은, 곧 코드 리뷰도 꽤 잘해줄 것이라는 의미와도 통한다고 봅니다. 그래서 저는 개인적으로 커서의 자동완성 Tab에 이은 새로운 매력적인 기능이 바로 여기에 있지 않을까 하고, 혼자만의 상상을 해보았습니다.

3) 커서의 타일형 레이아웃

커서에서 ‘타일형 레이아웃’이라고 부르는 이 기능은, IDE에서 기본적으로 제공하는 창 분할 기능입니다.

커서3의 타일형 레이아웃 <출처: 작가>

전통적인 IDE의 창 분할 기능을 기본으로 제공해, 에이전트를 위한 인터페이스이면서도 아직 IDE의 모습을 유지하고 있다는 점이 좋았습니다. 게다가 저는 클로드 코드나 Agent Window를 사용할 때 모니터 하나를 전부 할당해 쓰고 있습니다.

그리고 기존에 클로드 코드와 cmux 조합을 사용하던 저에게는 익숙하면서도, 당연히 있어야 하는 기능처럼 느껴졌습니다.

<출처: https://cmux.com/ko>

커서 3 실제 사용기

그럼 이제 직접 사용해 보면서 디테일한 부분을 체크해 보겠습니다. 이번 글을 위해 “SEO에 대해 무작정 개선 포인트를 찾아서 수정하라”는 명령을 던져보았습니다.

<출처: 작가>

이전 IDE 모드와 비교하면 대화와 결과가 확연히 달라졌습니다. 전보다 플랜 모드에서 각자의 역할이 더 선명해 보였고, 플랜 모드의 결과물은 “Plans > 결과물”로 표시되어 어떤 프로젝트에서 작성된 문서인지 바로 확인할 수 있었습니다. 이전에는 플랜 모드를 여러 개 돌려놓으면 직관적으로 보기 어려웠는데, 이런 부분이 개선되어 좋았습니다.

그다음으로 눈에 띈 점은 현재 진행 중인 채팅들의 결과입니다. 많은 개발자가 불편함을 느끼는 부분은 바로 채팅 결과가 어떻게 진행되고 있는지 추적할 방법이 없다는 점입니다. 커서팀에서도 이 부분을 염두에 두었는지, 완료된 대화, 처리 중인 대화, 혹은 워크트리로 분기된 대화, push까지 된 대화까지 한눈에 보고 알 수 있도록 개선되었습니다.

커서의 사이드바 <출처: 작가>

그다음으로는 커밋과 푸시하기가 매우 편해졌다는 점입니다. 일반적으로 큰 작업이 아닌 이상, 현재 작업을 위해 하위 브랜치를 만들거나 워크트리를 생성하기에는 애매합니다.

그래서 특정 기능을 위한 채팅을 병렬로 돌리게 되면, 커밋 단위로 구분이 필요한 경우가 종종 생깁니다. 저는 이 번거로움 때문에 “/grouped-commits”라는 skills를 만들어 관리했었습니다.

<출처: 작가>

그렇지만 이제는 코드 수정이 마무리되면, 해당 대화에서 수정된 파일들만 따로 커밋하고 푸시할 수 있도록 별도의 UI가 제공됩니다.

<출처: 작가>

커서 3 vs 클로드 코드

커서 3에 특별한 것은 없었다

2주가량 커서 3를 사용해 본 감상은 “특별한 것은 없다”라고 말할 수 있습니다. 위에서 말한 내용을 보면 기존에 불편함이 있었고, 이를 다른 방식으로 해결해 왔는데, 커서에서도 이를 이렇게 해결했다는 식으로 논리가 전개되고 있습니다.

그렇습니다. 이번 커서 3에는 딱히 특별한 것이 없습니다. 기존의 날것들이 다양한 방식으로 진화를 거듭하는 와중에, 저 멀리서 “내가 정통이오!” 하며 정리한 느낌이 강했습니다. 즉, 개성은 사라지고 기능 그 자체만 남게 된 셈입니다.

다만 그게 전부라면 질문의 답은 하나로 수렴합니다.

“커서 3 계속 사용할래?”

“커서 3를 위해 플랜 업그레이드할래?”

저는 이 두 가지 질문에 No라고 답하겠습니다. 또 이미 현업에서는 모든 에이전트가 클로드 코드 기준으로 돌아가고 있습니다. 공유되는 문서와 사용법, 심지어 팁까지 클로드 코드를 중심이라, 굳이 커서로 옮겨야 하나 싶은 생각이 듭니다.

커서 vs 클로드 코드 비교표 <출처: 작가>

제 기준에 맞춰 간단히 커서와 클로드 코드의 여러 가지 특성을 비교해 보았습니다. 무승부 1, 승리 3, 패배 3으로 최종 결과는 무승부처럼 보이지만, 실제로 커서가 승리한 3가지는 개인적인 선호도 차이에서 비롯된 것입니다. 반면, 실질적인 코딩 능력을 결정하는 확장성, 대중성, 협업 용이성 등에서는 클로드 코드가 압도적으로 우위에 있습니다.

그렇다면 코딩을 처음 하는 입장에서도 커서가 좋을까요? 이미 시중에는 바이브 코딩 툴(Lovable, Base44) 등이 강력하게 자리 잡고 있습니다. 따라서 현재 커서는 상당히 애매한 위치에 있습니다. IDE와 조화롭게 동작한다는 점을 제외하면 더더욱 그렇습니다. 이런 압도적인 차이와 함께, 현재 커서의 위치는 VS Code, Windsurf처럼 IDE에 가깝습니다. 물론 커서 입장에서는 위기감을 느끼고, 클로드 코드와 같은 레벨로 도약을 꿈꾸는 방향성도 이해합니다.

하지만 클로드 코드, 코덱스 앱 등이 범람하고 있는 에이전트판에서 커서의 영향력이 얼마나 될지는 모르겠습니다. 오히려 다른 서비스들이 IDE에서 벗어나는 스탠스를 취하고 있는 이 시기에, IDE 본연의 기능에 더 집중했으면 어땠을까라는 생각도 들었습니다.

해커뉴스나, 제 주위만 봐도 커서 20달러 플랜과 클로드 코드 200달러 플랜 조합을 쓰는 경우가 많습니다. 저 또한 그렇습니다. 특히 해커뉴스의 반응은 사뭇 공격적입니다. 커서를 쓰는 이유는 IDE스러움에 있는데, 이번 업데이트는 원하지 않는 방향으로 나아간다는 겁니다. 개발자들이 커서를 쓰는 이유는 IDE스러움과 바이브 코딩이 아니라, 실제로 코딩하고 싶은 욕구에 있다고 말합니다.

마치며

우리가 커서를 쓰는 이유는 에이전트 때문이 아닙니다. 그냥 커서가 개발하기 편하기 때문입니다. 이미 에이전트는 클로드 코드와 다른 툴을 병행해서 쓰고 있습니다. 우리가 느끼는 불편함이 에이전트 그 자체에 있지 않다는 말입니다.

ChatGPT와 코딩하기 위해 전체 코드를 복사하고 붙여넣으며 불편함을 느꼈고, 커서는 그 불편함을 VS Code 포크라는 방식으로 멋지게 풀어냈습니다. 다시 “바이브 코딩”으로 불편함이 커지는 지금, 커서의 다음 해결책은 무엇인지 궁금해지는데요. 적어도 지금처럼 Fast Follower 같은 기능은 아니면 좋겠습니다.

그리고 이 글을 쓰고 난 뒤, 우주 탐사 기업 스페이스X가 커서와 전략적 파트너십을 맺었다는 소식을 접했는데요. 계약에는 연말까지 커서를 인수할 수 있는 옵션까지 포함됐다고 합니다. 아직은 이르지만, 커서가 스페이스X를 만나 또 어떤 방향으로 진화할지는 지켜봐야 할 것 같습니다.

]]>

당신의 사고까지 AI에 외주화하지 마라

세계 최초의 웹 브라우저 ‘모자이크(Mosaic)’를 개발하고 넷스케이프와 안드레센 호로위츠를 공동 창업한 마크 안드레센은, 2011년 <월스트리트 저널>에 ‘소프트웨어가 세상을 먹어 치우는 이유(Why Software Is Eating The World)’라는 글을 기고했다. 소프트웨어가 산업의 경계를 허물며 세상을 재편하는 과정을 설명한 이 글은 큰 반향을 일으켰다.

세월이 흘러 이제 인공지능(AI)의 시대, 엔비디아의 젠슨 황 CEO는 이제 AI가 그 소프트웨어마저 집어삼키고 있다고 선언했다. 실제로 AI 기술은 과거 인터넷 보급 시기보다 7배나 빠른 속도로 확산하며 인류 역사상 가장 가파른 변화를 이끌고 있다.

<출처: Financial Times>

AI는 이미 인간의 업무를 상당 부분 대체하고 있다. 데이터 분석, 시각 자료 제작, 각종 문서 및 발표 자료 작성 등 반복적이고 복잡한 과업들을 AI가 도맡아 수행한다. 이러한 기술적 밀착은 인간과 AI 사이의 심리적 장벽을 허물었고, 그 결과 단순 업무 지원을 넘어 정서적 교감을 나누는 상담 창구의 역할로까지 확장되고 있다.

에이전틱(Agentic) AI는 이러한 흐름을 더욱 가속하고 있다. 에이전틱 AI란 한마디로 인간처럼 주체적으로 행동하는 AI를 뜻한다. OpenAI가 ChatGPT를 세상에 공개한 지 수년이 흐른 지금, 거대언어모델(LLM)이 내놓는 답변에 경탄하던 시대는 지났다. 이제 AI는 수동적인 대답에 머물지 않고, 능동적인 개체로서 스스로 정보를 수집하며 목표 달성을 위한 최적의 수단을 선택해 실행한다. 실제로 세계 최대 전자제품 위탁 생산(EMS) 기업인 대만 폭스콘은 전 세계 200여 개 공장의 생산 스케줄링 권한을 숙련된 전문가로부터 거두어 AI에게 위임했다고 한다.

이처럼 AI는 복잡한 판단을 넘어 인간의 고유 영역이라 믿었던 창의성마저 대체하기 시작했다. 데카르트는 “나는 생각한다, 고로 존재한다”라고 말했다. 깊은 사유 없이 말 한마디로 결과물을 ‘딸깍’ 만들어내는 이 시대에, 당신의 생각은 과연 안녕(安寧)한가?

2023년 5월 타임지 표지 ‘THE END OF HUMANITY(인류의 종말) <출처: time>

누가 사고의 주도권을 가지는가

나는 소프트웨어 업계에서 18년 가까이 종사하며 수많은 이들의 결과물(즉, 코드)을 지켜봐 왔다. AI가 대중화된 몇 년 전부터 뚜렷한 변화가 나타났는데, 경력에 상관없이 전반적인 결과물의 질이 비약적으로 향상된 것이다. 그러나 구체적인 질문을 던졌을 때의 반응은 대개 두 가지로 수렴되었다. 설계의 이유를 명확히 설명하는 사람과 그렇지 못한 사람이다. 후자는 대개 AI가 생성한 코드라 잘 모르겠다고 솔직하게 고백했다. 두 부류 모두 AI를 활용했고 결과물 수준도 비슷했지만, 누가 더 빠르게 성장할지는 명약관화(明若觀火)하다.

이유를 답하지 못한 이들은 사고의 주도권을 AI에 넘겼을 가능성이 크다. 이른바 ‘사고의 외주화’다. MIT 미디어 랩의 연구에 따르면, AI에 대한 과도한 의존은 단기적 효율을 높일지언정 장기적으로는 비판적 사고와 학습 능력을 저하시킨다. 주관 없는 AI와의 상호작용은 일방적인 강의와 같다. 지식을 수동적으로 전달받을 때는 당시에는 이해한 듯 착각하지만, 시간이 지나면 휘발되어 버린다.

학습과 문제 해결의 가장 효과적인 방법은 역설적이게도 ‘수많은 시행착오’다. 인간은 실수와 실패를 교정하는 과정에서 지식의 깊이를 더한다. 드라이퍼스(Dreyfus) 모델에 따르면 전문가의 핵심 역량인 ‘직관’은 경험 속 패턴 인식에서 비롯되며, 이는 경험의 양보다 질에 좌우된다. 즉, 전문성이란 다양한 시행착오를 거치며 자신만의 해법을 구축해가는 과정이다. 반면 AI는 기술로 매개된 ‘매끄러운 간접 경험’을 선사한다. 질문 몇 마디에 주어지는 그럴듯한 답안지는 배움에 필수적인 시행착오를 최소화한다.

<출처: casenews>

누군가는 AI가 전문가의 영역을 위협하는 것을 보고 ‘전문가의 시대’가 막을 내렸다고 말한다. 하지만 AI가 전문가를 대체하는 흐름과 내가 전문성을 갖추는 문제는 전혀 별개의 사안이다. AI가 기존 일자리를 빠르게 재편하는 상황일수록, 새롭게 창출되는 직무는 오히려 고도의 전문성을 요구할 가능성이 크기 때문이다.

인터넷에는 AI 활용법이 범람하지만, 분명한 사실은 도구의 기법보다 사용자의 지적 수준에 따라 결과물의 수준이 판이하게 달라진다는 점이다. 사고를 AI에 외주화하는 방식으로는 자신만의 지적 토대와 전문성을 구축하는 일이 요원할 수밖에 없다.

당신이 사고의 주도권 쥐고 AI에게 코치 역할을 부여하라

유발 노아 하라리(Yuval Noah Harari)는 저서 《21세기를 위한 21가지 제언》에서 “인간은 도구를 현명하게 사용하는 것보다 발명하는 데 훨씬 뛰어났다”고 통찰했다. 우리는 시간을 절약하고자 이메일과 스마트폰을 발명했지만, 역설적으로 그 도구들 탓에 24시간 업무에 예속된 더 분주한 삶을 살게 되었다. AI를 적극적으로 활용하는 이들이 늘어난 지금도 대다수의 현대인이 여전히 시간에 쫓기는 이유도 이와 다르지 않다.

그렇다면 AI라는 도구를 현명하게 사용한다는 것은 무엇을 의미할까? 마이크로소프트 리서치 케임브리지(Microsoft Research Cambridge)의 Tools for Thought 팀 시니어 연구원인 어드베이트 사카르(Advait Sarkar)는 TED 강연 <How to Stop AI from Killing Your Critical Thinking>에서 이 문제를 정면으로 다루었다. 그는 인간이 AI에 사고를 외주화(Outsource)하는 현상을 경고하며 우리에게 근본적인 질문을 던진다.

여러분 대신 생각하는 도구인가요?
아니면 여러분을 생각하게 만드는 도구인가요?

앞서 강조했듯, AI에게 사고의 주도권을 내어준다면 진정한 전문성을 달성하기 어렵다. 내가 사유의 주체가 되고 AI는 그 과정을 돕는 ‘생각을 위한 도구(Tool for Thought)’로 활용할 때에만, 인간 고유의 비판적 사고와 창의성을 강화할 수 있다. 이때 AI는 우리 곁의 유능한 ‘코치’와 같은 역할을 수행한다. 구글의 전 CEO 에릭 슈미트(Eric Schmidt)는 자신이 받은 최고의 조언(Best advice I ever got)을 회고하며, 코치의 존재 이유에 대해 다음과 같이 설명했다.

2001년에 “코치를 두라는 조언을 드리고 싶습니다.”라고 말한 존 도어의 조언이 기억에 남습니다.

(중략)

처음에는 그 조언이 마음에 들지 않았습니다. 왜냐하면 저는 CEO였기 때문입니다. 저는 꽤 경험이 많았거든요. 코치가 왜 필요할까요? 제가 뭔가 잘못하고 있는 걸까요? 제가 이 분야에서 세계 최고인데 코치가 어떻게 조언을 해줄 수 있겠어요? 하지만 코치는 그런 일을 하지 않아요. 코치는 여러분만큼 스포츠를 잘할 필요는 없습니다.

(중략)

코치는 다른 시각으로 무언가를 바라보고, 자신의 말로 설명하며, 문제에 접근하는 방법에 대해 논의하는 사람입니다.

-Erick Schmidt: Best advice I ever got

즉, 코치는 당신을 대신해 생각하거나 일하는 사람이 아니다. 제삼자의 관점에서 당신이 미처 인식하지 못한 사각지대를 깨닫게 해주는 조력자다. 건강을 위해 하는 운동이 결국 본인의 몫이듯, 코치에게 대신 운동을 시키는 사람은 없다.

인간의 뇌는 단순히 정보를 입력받을 때보다 스스로 무언가를 생성(말하기, 쓰기, 가르치기)할 때 훨씬 더 강하게 각인된다.* 그러니 AI에게 의존하기 전, 먼저 스스로 문제를 해결하려 애쓰는 과정에서 충분한 시행착오를 겪으며 ‘직접 경험’을 축적하라. 그 후에 당신의 생각이 더 나은 방향으로 나아갈 수 있도록 AI에게 ‘코치’의 역할을 부여하라.

*이를 생성 효과라고 한다.

마치며

우리 뇌는 가소성(Plasticity)을 지닌다. 생각하고 행동하는 방식에 따라 뇌의 물리적 구조 자체가 재편된다는 뜻이다. 근육과 마찬가지로 뇌 역시 쓰지 않으면 퇴화한다. AI가 세상을 집어삼키고 있는 지금, 당신은 여전히 사고의 주도권을 쥐고 있는가?

<원문>

당신의 사고까지 AI에게 외주화하지 마라

]]>

클로드 코드 소스 유출에서 배우는 에이전트 구조

쏟아지는 AI 정보 속에서 자칫 겉핥기식으로만 따라가게 되는 요즘, 오히려 더 중요해지는 것은 정의와 본질인 것 같습니다. 특히 에이전트 경쟁은 이제 더 이상 ‘누가 더 똑똑한 모델을 붙였는가’만으로 설명되지 않습니다.

지난 3월 31일, 앤트로픽의 AI 코딩 도구 클로드 코드에서 소스맵 파일이 함께 배포되는 사고가 있었는데요. 이로 인해 외부에 드러난 클로드 코드의 내부 구조는, 오히려 에이전트의 완성도와 디테일이 어디에서 갈리는지를 꽤 선명하게 보여줍니다. 오픈AI도 에이전트를 planning, tool calling, specialist ownership, state, guardrails, observability 관점에서 설명하고 있고, 앤트로픽 역시 Claude Agent SDK를 “same tools, agent loop, and context management that power Claude Code”라고 정의했죠.

결국 에이전트는 모델을 단순히 소비하거나 활용하는 데서 끝나는 개념이 아니라, 모델이 실제로 일을 수행하도록 만드는 실행 구조에 가깝습니다. 이번 글에서는 클로드 코드 소스 유출 사례를 통해, 에이전트 구조가 어떻게 설계되어 있는지 살펴보겠습니다.

미리 요점만 콕 집어보면?

이제 완성도는 오케스트레이션, 역할 분리, 도구 계층, 상태 관리, 안전장치, 관측 가능성에서 갈립니다.
결국 중요한 건 “어떤 모델을 썼나”보다 “그 모델이 어떤 루프와 상태 위에서 움직이나”입니다.
그래서 Agent의 차이는 “얼마나 똑똑한가”보다 “어떻게 나누고, 잇고, 통제하느냐”에서 납니다.

에이전트란 무엇인가

에이전트(agent)란 말은 중세 라틴어 agens/agent-에서 왔습니다. 더 거슬러 올라가면 라틴어 agere에서 나옵니다. 뜻은 대체로 “움직이게 하다, 이끌다, 행하다, 수행하다”에 가깝습니다.

<출처: Merriam-Webster>

원래의 핵심은 “행동하는 존재”라기보다, 무언가를 일으키거나 대신 수행하는 것에 더 가깝습니다. 그래서 약간 비밀요원 같은 뉘앙스가 있었죠. AI 시대에 들어오면서 “환경을 보고 행동하는 주체”라는 기술적 의미가 중심이 됐습니다.

Russell and Norvig의 AIMA(초판 95년), Artificial Intelligence: A Modern Approach는 agent를 “환경을 센서로 지각하고, 액추에이터로 그 환경에 작용하는 것”으로 정의합니다. 또한 에이전트 연구자인 Wooldridge와 Jennings는 1995년에 이미 “agent라는 개념이 AI와 주류 컴퓨터 과학에서 중요해졌다”고 쓰면서도, 동시에 보편적으로 합의된 하나의 정의는 없다고 말합니다.

에이전트가 처음부터 하나의 단일한 정의로 쓰였다기보단, agent, intelligent agent, software agent, softbot 같은 표현이 먼저 퍼진 뒤, 이를 나중에 ‘AI Agent’라는 이름 아래 묶어 부르게 된 흐름에 더 가깝습니다. 그리고 요즘은 이 개념을 정의하는 쪽이 자연스럽게 주류처럼 보이는 분위기도 있는 것 같습니다.

1) 빅테크의 에이전트 정의

그렇다면 빅테크에서는 에이전트를 어떻게 정의할까요? 우선 OpenAI는 Agent를 runtime loop, orchestration, handoffs, guardrails, results and state, observability까지 포함한 애플리케이션으로 설명합니다. Anthropic도 Claude Agent SDK를 Claude Code와 같은 tools, agent loop, context management를 프로그래밍할 수 있게 만든 형태로 소개합니다.

runtime loop는 “한 번 답하고 끝”이 아니라, 모델이 도구를 호출하고 그 결과를 다시 받아 다음 행동을 이어가는 반복 구조를 뜻합니다.
orchestration은 이 전체 흐름을 조율하는 layer입니다. 어떤 순서로 무엇을 하고, 어떤 agent를 부르고, 언제 멈출지를 정합니다.
handoffs는 작업을 다른 agent나 사람에게 넘기는 절차입니다.
guardrails는 위험한 행동을 막거나 제한하는 안전장치입니다.
state는 작업을 이어가기 위해 남겨두는 진행 상태와 맥락입니다.
results는 각 단계에서 나온 실제 산출물입니다.
observability는 이 시스템이 왜 그렇게 행동했는지 나중에 로그, 메트릭, 트레이스로 추적할 수 있게 해주는 장치입니다.
tools는 검색, 파일 읽기, 코드 수정, API 호출처럼 모델이 바깥 세계에 실제로 작동할 때 쓰는 기능입니다.
context management는 모델에게 어떤 정보를 보여주고, 어떤 정보를 숨기며, 무엇을 다음 단계로 넘길지를 다루는 방식입니다.

결국 중요한 건 “어떤 모델을 썼나”보다 “그 모델이 어떤 루프와 상태 위에서 움직이나”입니다.

<출처:작가,ChatGPT 생성>

2) 코드 리뷰 자동화를 만든다면

예를 들어, 모델 하나에 “PR 읽고 문제 찾고, 필요하면 수정까지 해”라고 던질 수는 있습니다. 데모는 그럴듯하게 나올 수 있습니다. 하지만 운영 단계로 들어가 몇 번 반복하면 원래 목표가 흐려집니다.

왜 그 파일을 위험하다고 봤는지, 왜 그 수정이 나왔는지, 누가 쓰기 권한을 가졌는지, 실패하면 어디서 멈춰야 하는지가 모두 섞이기 때문입니다. 그래서 보통은 아래와 같이 나눕니다.

manager -> diff 요약 -> review specialist -> 승인 후 수정 agent

여기서 중요한 건 “쪼갠다”는 사실 자체가 아니라, 각 단계의 [입력, 출력, 권한]이 좁고 분명하다는 점입니다.

manager가 orchestration 역할을 하고,
diff 요약 agent는 변경 의도와 리스크 파일 목록만 반환하며,
review specialist agent는 근거 라인과 치명도만 남기고,
수정 agent는 승인 전까지 쓰기 권한을 갖지 못합니다.

Anthropic의 Claude Code subagent 문서도 각 subagent는 “자기 context window, 별도 system prompt, specific tool access, independent permissions를 가질 수 있다”고 설명합니다. 결국 잘 만든 Agent는 “여러 명이 협업하는 느낌”보다, 누가 무엇을 읽고 무엇을 쓸 수 있는지가 분명한 구조에 가깝습니다.

Claude Code 유출에서 배워야 할 것

1) Agent의 핵심은 엄청난 프롬프트보다 agent loop

공개된 분석들과 Anthropic 문서를 함께 보면, Claude Code의 본질은 결국 [입력 → 컨텍스트 결합 → 모델 호출 → tool_use 감지 → 툴 실행 → 결과 재주입 → 반복] 구조입니다. 그들만 가지고 있는 마법 같은 비밀이라기보다, 엉망인 코드라고 놀림받을지언정 예상보다 훨씬 명시적인 실행 루프에 가까웠습니다.

# Claude Code류 agent loop를 공식 문서 기준으로 재구성한 의사코드
# 핵심: 프롬프트 안에 다 우겨넣지 말고, 루프/권한/승인/중단 조건을 런타임으로 뺀다.

def run_agent(user_prompt, system_prompt, tools, state, policy):
    turn = 0
    max_turns = policy.max_turns
    max_failures = policy.max_failures
    failures = 0

    messages = []
    messages.append({"role": "system", "content": system_prompt})
    messages.extend(state.load_history())
    messages.append({"role": "user", "content": user_prompt})

    # 1) 프롬프트 제출 시점 전처리
    prompt_signals = inspect_user_prompt(user_prompt)  
    # 예: frustration, profanity, urgency, risky intent
    … # 생략

    while turn < max_turns:
        turn += 1

        # 2) 모델 호출 전 컨텍스트 압축 / 결합
        runtime_context = build_runtime_context(
            messages=messages,
            memory=state.memory,
            task_state=state.task_state,
            compact_if_needed=True,
        )

        # 3) 모델 호출
        llm_response = model.generate(runtime_context, available_tools=tools)

        # 4) 답변 종료 조건
        if llm_response.type == "final":
            state.log_event("run_complete", {
                "turn": turn,
                "reason": "final_answer",
            })
            state.save_history(messages + [llm_response.to_message()])
            return llm_response.text

        # 5) tool_use 요청 감지
        if llm_response.type == "tool_use":
            requested_tools = llm_response.tool_calls

            for call in requested_tools:
                # 5-1) 권한 정책 평가
                decision = policy.check(call)
                # allow / ask / deny / escalate

                if decision == "deny":
         … # 생략

                if decision == "ask":
                    approved = human_review(call, state.snapshot())
        … # 생략
                    if not approved:
                        … # 생략
                        continue

                # 5-2) timeout / retry / circuit breaker 포함한 실제 실행
                try:
                    … # 생략

                except TimeoutError:
                    failures += 1
                    … # 생략

                except Exception as e:
                    failures += 1
                    … # 생략

        # 6) 실패 누적 중단 조건
        if failures >= max_failures:
            … # 생략
            return "중단: 연속 실패가 임계치를 넘었습니다."

    # 7) turn budget 소진
    state.log_event("run_stopped", {
        "reason": "max_turns_exceeded",
        "turn": turn,
    })
    return "중단: 최대 반복 횟수를 초과했습니다."

최대 반복 횟수, 실패 시 중단 조건, tool timeout, 재시도 횟수, human review 진입 조건은 런타임 레벨에서 따로 둬야 합니다. 그래야 시스템이 무너지지 않습니다. OpenAI도 workflow가 복잡해질수록 runtime loop, human review, guardrails를 별도 설계 대상으로 두라고 안내합니다.

유출된 실제 흐름은 아래와 같았습니다.

<출처: 작가>

모든 대화는 단 하나의 함수를 통과 - submitMessage()
System Prompt 결합
내부적으로 최소 42개 도구 동적 배치
context가 너무 커진다? -> 이전 메시지 자동 요약, 압축
프로젝트 -> 사용자 -> 글로벌 메모리 계층적 로딩

2) 잘 만든 Agent는 결국 “툴을 얼마나 잘 쓰느냐”에서 갈린다

구조 자체는 단순하지만, 그 단순한 루프 안에서 검색, 터미널, 파일 수정, 외부 시스템 연결을 얼마나 정확하게 실행하느냐가 완성도를 좌우합니다. Anthropic 공식 문서도 Claude Code를 파일 읽기, 명령 실행, MCP를 통한 외부 연동 중심의 agentic coding tool로 설명하고, OpenAI 역시 built-in tools, function calling, remote MCP servers를 통해 실제 기능을 확장하라고 안내합니다.

그래서 실전에서는 툴을 기능별로 나누는 것보다, 위험도별로 나누는 편이 더 유용하다고 합니다. read-only, external-read, write, exec, destructive처럼 등급을 나누고, 각 등급마다 승인 정책을 다르게 두는 방식입니다. “툴을 붙였다”보다 “어떤 툴을 어떤 조건에서 열었나”가 훨씬 중요합니다.

# 핵심만 남긴 툴 실행 정책 의사코드

def run_tool(tool_name, args, approved=False):
    risk = classify(tool_name)

    if risk == "read":
        return execute(tool_name, args)

    if risk in ["write", "exec"] and not approved:
        return "HUMAN_REVIEW_REQUIRED"

    if risk == "destructive":
        return "BLOCKED"

    return execute(tool_name, args)


def classify(tool_name):
    if tool_name in ["search_docs", "read_file", "grep_code"]:
        return "read"
    if tool_name in ["edit_file", "create_draft"]:
        return "write"
    if tool_name in ["run_bash", "run_python"]:
        return "exec"
    if tool_name in ["git_push", "delete_file", "deploy_prod"]:
        return "destructive"
    return "blocked"

3) “만능 한 명”이 아니라 “역할이 나뉜 팀형 구조”

멀티에이전트 스폰과 메시지 전달 구조, Anthropic 공식 문서는 subagent를 독립된 context window, 별도 system prompt, tool access, permissions를 가진 전문 역할로 정의합니다.

이는 곧 좋은 Agent가 거대한 단일 프롬프트보다 [리드 에이전트 + 전문 에이전트 구조]로 가고 있다는 신호입니다. 다만 여기서도 핵심은 “팀처럼 나눠라”가 아니라, “누가 최종 응답의 책임을 지는지”, “누가 도구를 직접 호출할 수 있는지”, “누가 읽기만 하고 누가 쓰기까지 가능한지”를 분명히 정하라는 뜻입니다.

예를 들어, retrieval specialist는 근거 ID만 넘기고, answering specialist는 그 근거 없이는 답을 못 하게 하며, mutation agent는 manager 승인 없이는 실행 자체가 안 되게 설계해야 합니다. 역할 분리는 예쁜 구조도가 아니라 책임 분리입니다.

# 역할 분리만 보여주는 가장 단순한 의사코드

def manager(question):
    evidence_ids = retrieval_agent(question)   # 읽기만 가능
    answer = answering_agent(question, evidence_ids)  # 근거 없으면 답변 금지

    if needs_change(answer):
        return mutation_agent(answer, approved=False)  # 승인 없으면 실행 금지

    return answer

def retrieval_agent(question):
    # Read-only tools만 허용
    return ["doc_12", "doc_48"]

def answering_agent(question, evidence_ids):
    if not evidence_ids:
        return "근거 부족: 추가 탐색 필요"
    return f"근거 {evidence_ids} 기준으로 답변 생성"


def mutation_agent(payload, approved=False):
    # Write / Edit / Exec는 승인 전 차단
    if not approved:
        return "HUMAN_REVIEW_REQUIRED"
    return "변경 실행 완료"

4) 진짜 경쟁력은 모델보다 컨텍스트 운영 능력

<출처: bits-bytes-nn.github>

[프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링 → 에이전틱 엔지니어링]의 흐름으로 진화하는 트렌드, 사실 각 단계의 진화라기보다 이 모든 것이 중요해진 게 더 맞는 것 같습니다.

CLAUDE.md, auto memory, subagent context 분리 같은 공식 기능을 보면, Claude Code는 단순히 답변을 잘하는 도구가 아니라 “무엇을 기억하고”, “무엇을 넘기고”, “무엇을 버릴지”를 구조적으로 다루는 방향으로 가고 있습니다. 컨텍스트는 많이 넣는다고 좋아지지 않습니다. 오히려 지속 규칙, 작업 상태, 근거 자료, 이번 턴 임시 정보를 분리해야 품질이 안정됩니다.

CLAUDE.md 같은 지속 규칙은 짧게 핵심만 두고, 작업 중간 산출물은 “session state”로만 들고 가며, specialist에게 넘길 때는 전체 대화가 아니라 요약된 작업 카드만 넘기는 편이 낫습니다. 결국 컨텍스트 운영은 기억력이 아니라 압축력의 문제입니다.

나아가 이 부분은 안드레 카파시(Andrej Karpathy)가 제안한 LLM 위키 개념이나, graphify를 적용하는 것도 매우 좋은 시도로 보입니다.

5) Claude Code는 사용자의 “짜증 신호”를 그냥 흘려보내지 않는다

<출처: 작가, ChatGPT 생성>

Claude Code는 단순히 질문만 받는 것이 아니라, 사용자의 프롬프트 안에서 욕설·분노·좌절 같은 신호를 별도로 읽어내는 계층을 갖고 있었습니다. 내 짜증 신호는 도대체 몇 개일까 너무 궁금해지는 대목입니다.

// 실제 코드는 아니고 유출된 코드 기반으로 재구성
const NEGATIVE_REGEX = /wtf|wth|ffs|omfg|...|so frustrating|this sucks|damn it/i

function processUserPrompt(prompt: string) {
  const isNegative = NEGATIVE_REGEX.test(prompt.toLowerCase())
  analytics.track("tengu_input_prompt", {
    is_negative: isNegative,
  })

  return prompt
}

userPromptKeywords 계열 로직과 관련한 보도에 따르면, profanity·frustration 신호를 정규식 기반으로 감지하는 흐름이 알려졌고, Scientific American도 이 감지를 “regex 기반 frustration detector”로 설명했습니다.

중요한 건 이 포인트가 의외로 굉장히 실무적이라는 점입니다. 감정 신호 감지는 거대한 추론보다 regex 같은 값싼 규칙 처리로 이루어지며, 이유도 단순합니다. 빠르고, 비용이 낮으며, 운영 지표로 쓰기 좋기 때문입니다. 최첨단(?) Agent 안에도 여전히 고전적인(?) 규칙 엔진이 섞여 있습니다.

그래서 무엇을 하느냐! 욕설을 감지했다고 해서 무조건 답변 톤을 바꾸는 것이 핵심은 아닙니다. 오히려 이 신호를 위험 작업 일시 중지, UI 단순화, 재질문 유도, human handoff 후보, 운영 지표 기록에 활용하는 편이 훨씬 낫습니다.

Anthropic 공식 문서도 UserPromptSubmit 같은 훅 이벤트에서 사용자 입력을 받을 수 있고, data usage 문서에는 Statsig와 Sentry를 통한 운영 메트릭 및 에러 로깅이 명시돼 있습니다. 다시 말해 “짜증 신호 감지”는 실행 전에 개입할 수 있는 운영 레버입니다. 이 기능을 시스템 프롬프트에 묻어두기보다, 프롬프트 제출 시점의 별도 전처리와 로깅 계층으로 분리하는 편이 실제 운영에 훨씬 유리합니다.

완성도 높은 Agent의 공통 구조

잘 만든 Agent는 대개 하나의 거대한 뇌보다, 오케스트레이터, 전문 역할, 툴 계층, 상태 관리, 가드레일, 관측 가능성으로 나뉜 구조입니다. 결국 이것이 “하네스(Harness) 엔지니어링”이라는 이름으로 불리게 되었다고 보입니다.

OpenAI는 orchestration, specialists, tools, approvals, state를 에이전트 설계의 중심에 놓고 있고, Anthropic은 subagent별 tool access와 independent permissions를 분리합니다.

MCP 역시 외부 데이터와 도구를 연결하는 표준 인터페이스로 정의되며, 사용자의 명시적 동의와 도구 실행 안전성이 중요해집니다. 이제 경쟁력은 자율성 그 자체보다, 무엇을 누구에게 맡기고 어떤 도구를 어떤 경계 안에서 연결하느냐에 더 가깝습니다.

실제로는 오케스트레이터가 “다음 행동 결정”, specialist가 “좁은 문제 해결”, tool layer가 “행동 실행”, guardrail이 “차단과 승인”, state가 “작업 이어 붙이기”, trace가 “사후 설명”을 맡는 식으로 기능을 분리해야 합니다. 각각의 책임이 겹치면 디버깅이 헬입니다.

예를 들어, 사내 문서 검색 Agent를 만든다면,

manager agent는 질문을 분류하고,
retrieval specialist는 파일과 검색만 담당하고,
answering specialist는 답변 생성만 담당하게 나누는 식입니다.

그런데 여기서 한 단계만 더 가야 합니다.

retrieval specialist는 원문 전체가 아니라 근거 snippet + 문서 ID + 신뢰도만 반환하게 하고,
answering specialist는 그 근거가 없으면 답변 대신 추가 탐색을 요청하게 해야 합니다.

외부 SaaS나 사내 시스템 연결은 MCP나 function calling으로 붙이되, 결재·삭제·배포 같은 작업은 반드시 approval step 뒤에서만 실행되게 막아두는 편이 안전합니다. trace/log에는 최소한 run_id, selected specialist, tool name, approval 여부, failure reason 정도는 남겨야 나중에 사고를 재현할 수 있습니다.

OpenAI도 tools와 remote MCP 서버를 통한 확장, server-owned orchestration, state, approvals, observability를 SDK 핵심 사용 방식으로 설명합니다. 구조를 잘 나누는 것보다, 재현 가능한 구조를 만드는 것이 더 중요합니다.

마치며

그래서 Agent의 차이는 “얼마나 똑똑한가”보다 “어떻게 나누고, 잇고, 통제하느냐”에서 갈립니다. 누가 흐름을 잡을지, 어떤 specialist를 둘지, 어떤 도구를 어떤 권한으로 열지, 상태를 어디에 남길지, 어디서 사람 승인을 받을지를 먼저 정하는 일에 가깝습니다. OpenAI와 Anthropic의 공식 문서를 나란히 보면, 결국 오래 가는 Agent는 답변 품질 하나가 아니라 구조의 안정감에서 나온다는 점이 반복해서 강조됩니다. 더 현실적으로 말하면, 품질은 모델이 올려주지만 신뢰는 구조가 만듭니다. 신뢰의 판단 근거는 결국 “인간”인 거죠.

지금 당장 시작한다면, 거대한 만능 Agent 하나를 만들기보다 manager 1개 + specialist 2~3개 + tool layer + approval + trace/log 정도로 작게 나눠 설계해 보는 게 좋습니다. 각 specialist의 출력 스키마를 고정하고, tool 권한을 위험도별로 나누며, 루프 예산과 중단 조건을 두고, 사용자 짜증 신호 같은 운영 힌트도 전처리 계층에서 잡을 수 있게 Agent의 구조를 구성하는 방식으로 말이죠.

<출처:작가, ChatGPT 생성>

<출처>

https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
https://code.claude.com/docs/en/overview
https://code.claude.com/docs/en/sub-agents
https://code.claude.com/docs/en/hooks
https://code.claude.com/docs/en/memory
https://code.claude.com/docs/en/data-usage
https://developers.openai.com/api/docs/guides/agents
https://developers.openai.com/api/docs/guides/tools
https://platform.claude.com/docs/en/agent-sdk/overview
https://www.scientificamerican.com/article/anthropic-leak-reveals-claude-code-tracking-user-frustration-and-raises-new/
https://www.theregister.com/2026/03/31/anthropic_claude_code_source_code/
https://www.pcworld.com/article/3104748/claude-code-is-scanning-your-messages-for-curse-words.html

]]>

ChatGPT 이미지 2.0과 Claude Design의 등장

아마 다들 AI에게 “이런 이미지 만들어줘”라고 한 번쯤 시켜본 적이 있을 겁니다. 그런데 예전에는 “카페 메뉴판을 만들어줘”라고 하면 ‘아메리카노’는 ‘아메맄카노’가 되고, ‘딸기 라떼’는 ‘딿기 랃떼’되는 등 정체를 알 수 없는 글자로 뭉개지곤 했죠. 한국어 간판이나 포스터를 부탁해도 결과는 비슷했습니다. 결국 텍스트는 빼고 만들거나, 나중에 사람이 다시 얹어야 했습니다. 그런데 이제는 꽤 달라졌습니다. 같은 프롬프트를 넣어도, 카페에 바로 걸어둘 수 있을 만큼 자연스러운 한글 메뉴판이 나옵니다.

이는 최근 한 달 사이에 AI 업계에 많은 일이 벌어졌기 때문인데요. 하나씩 살펴보면,

3월 24일 오픈AI(OpenAI)가 Sora를 닫았습니다.
4월 4일 아레나 AI(Arena AI)에 정체불명의 이미지 모델 세 개가 나타났다가 곧 사라졌습니다.
4월 17일 앤트로픽(Anthropic)이 클로드 디자인(Claude Design)을 출시했습니다.
4월 21일, 오픈AI가 챗GPT 이미지 2.0을 공식 발표하면서 아레나 AI의 정체불명 모델이 자사 것이었음을 확인했습니다.

AI가 코딩을 넘어, 디자인 영역에 본격적으로 들어오려는 움직임을 볼 수 있었는데요. 이번 글에서는 이 흐름을 살펴보고, 실무 관점에서 이야기해 보려고 합니다.

Sora 가고, 새로운 게 왔다

이야기는 오픈AI의 Sora 셧다운에서 시작됩니다.

오픈AI는 3월 24일 AI 영상 생성 도구 Sora를 운영 종료를 결정했습니다. 이에 샘 올트먼은 "차세대 제품에 컴퓨팅 자원과 역량을 집중하기 위해"라고 밝혔죠. 동영상은 접되, 이미지는 계속 개발하겠다는 건데요. 또 다른 오픈AI 관계자는 "이미지 생성은 궁극적인 개인 비서를 만드는 데 핵심적인 요소"인 반면 "동영상에 대한 수요는 아직 그 정도가 아니었다"고 덧붙여 설명했습니다.

Sora가 닫힌 지 11일 뒤인 4월 4일, 아레나 AI에 낯선 이름 세 개가 공개됐습니다. 마스킹테이프-알파, 가퍼 테이프, 팩킹 테이프. 이는 우리가 ‘덕트테이프’라 알고 있는 모델의 코드 네임입니다.

아레나 AI는 두 개의 익명 AI 모델이 같은 프롬프트로 이미지를 만들면, 사용자가 블라인드로 투표하는 비교 플랫폼입니다. 2026년 4월 기준 54개 모델이 등록돼 있고, 체스의 엘로(Elo) 레이팅 방식으로 순위가 매겨지죠.

세 모델은 얼마 지나지 않아 사라졌지만, 수백 장의 비교 스크린샷은 이미 퍼진 뒤였습니다. 이 패턴은 처음이 아니었거든요. 지난해 12월에도 익명 모델이 아레나 AI에 잠깐 떴다가 사라졌고, 몇 주 뒤 GPT 이미지 1.5가 출시됐습니다. 구글의 제미나이 2.5 플래시 이미지(Gemini 2.5 Flash Image) 모델도 "나노바나나"라는 코드네임으로 아레나 AI에 먼저 등장했었죠.

결국 4월 21일, 오픈AI가 챗GPT 이미지 2.0을 공식 발표하면서 덕트테이프의 정체가 확인됐습니다.

챗GPT 이미지 2.0의 등장, 무엇이 달라졌나

OpenAI는 이 모델을 이미지 생성의 새로운 시대라고 소개했습니다. 제가 생각하는 핵심 변화는 세 가지는 아래와 같습니다.

첫째, 텍스트 렌더링이 잘된다. 이전 모델들의 가장 큰 약점이 텍스트 렌더링이었습니다. 포스터에 글자를 넣으면 뭉개지고, 한국어는 특히 처참했죠. 챗GPT 이미지 2.0은 OpenAI 스스로 "텍스트 처리에서 전작 대비 큰 진전"이라고 밝힐 만큼 개선됐습니다. 한국어, 일본어, 중국어, 힌디어, 벵골어 등 비라틴 문자 렌더링이 대폭 개선됐고, 벤처비트가 공개한 샘플에는 한글로 물의 순환을 설명하는 교육 다이어그램에서 복잡한 한글 텍스트가 레이아웃 안에 자연스럽게 들어가 있었습니다.

<출처: venturebeat>

둘째, "생각"하고 그린다. 인스턴트(Instant) 모드와 씽킹(Thinking) 모드 두 가지가 있습니다. 인스턴트는기존처럼 빠르게 결과를 내놓고, 씽킹은 OpenAI의 추론 기능을 결합해 웹 검색을 하고, 자기가 만든 결과물을 검증하고, 한 프롬프트에서 최대 8장의 이미지를 캐릭터 일관성을 유지하면서 생성할 수 있습니다. 만화 시퀀스나 브랜드 캠페인처럼 여러 장에 걸쳐 인물이 일관되게 나와야 하는 작업에 써봄직한 기능입니다. 참고로 씽킹 모드는 ChatGPT Plus($20/월)~Pro($200/월) 등 유료 구독자에게만 제공되며, Instant 모드는 무료 사용자를 포함한 모든 사용자가 이용할 수 있습니다.

<출처: ChatGPT, 직접 제작>

셋째, 무료 사용자도 쓸 수 있다. 인스턴트 모드는 무료 계정을 포함한 모든 ChatGPT 사용자에게 공개되어 있습니다. API(gpt-image-2)로도 접근할 수 있고, 2K 해상도와 3:1에서 1:3까지의 유연한 비율을 지원합니다.

다만 한계도 지적되는 점도 있는데요. 와튼스쿨의 AI 연구자 Ethan Mollick은 "1~2번 정도의 수정은 잘 되지만, 그 이후부터는 진전이 멈추는 전형적인 이미지 생성 모델의 문제"가 있다고 지적했습니다. 그의 우회법은 이미지를 새 대화창에 넣어 맥락을 리셋하는 것이라고 합니다. 그리고 모델의 지식 기준일이 2025년 12월이라, 최신 브랜드 로고나 제품 디자인을 정확히 재현하는 데는 한계가 있다고 하는데 이 부분은 금방 해결될 거라 봅니다.

같은 시각, Anthropic은 다른 문을 열었다

한편 OpenAI가 이미지 품질로 디자인 영역에 들어오는 동안, 앤트로픽은 다른 방향을 택했습니다.

<출처: Claude>

4월 17일 공개된 Claude Design은 AI와 대화하면서 프로토타입, 슬라이드, 랜딩 페이지 같은 시각물을 만드는 도구입니다. Claude Opus 4.7이 구동하며, 유료 구독자에게 리서치 프리뷰로 제공됩니다.

챗GPT 이미지 2.0과 클로드 디자인은 디자인이라는 같은 영역에 진입하면서도 다른 곳을 겨냥합니다. 챗GPT 이미지 2.0은 명령에 따른 더 정확한 이미지를 만드는 데 집중하지만, Claude Design은 비디자이너가 디자인 결과물을 만드는 워크플로우에 집중합니다. 팀의 코드베이스와 디자인 파일에서 디자인 시스템(색상, 타이포그래피, 컴포넌트)을 자동으로 추출하고, 이후 프로젝트에 자동 적용합니다. 디자인이 끝나면 클로드 코드(Claude Code)로 넘겨서 바로 코드로 만들 수 있습니다. 머릿속 아이디어를 시안으로 뽑고, 그 시안을 코드로 옮기는 과정을 전부 자사 생태계 안에서 완결시키려는 구조입니다.

앤트로픽은 "기존 디자인 도구를 대체하려는 게 아니라 보완하려는 것"이라고 했습니다. 하지만 아이디어 탐색부터 시안, 프로덕션 코드까지 하나의 생태계 안에서 끊기지 않고 이어지는 도구는 지금까지 없었죠. 보완이라고 말하기엔, 기존 도구들이 담당하던 영역을 꽤 넓게 건드리는 구조라고 생각합니다.

한국어 타이포가 깨지지 않는다는 것

Claude Design이 바꾸는 건 디자인 도구가 아니라, 디자인을 할 수 있는 사람의 범위입니다. 그리고 챗GPT 이미지 2.0은 그 사람들이 만드는 결과물의 품질 천장을 끌어올리고 있죠. 한국 디자이너에게 그 품질 변화 중 가장 체감이 큰 부분이 따로 있습니다. 바로 텍스트 렌더링인데요.

그동안 AI 이미지 모델에 한국어를 넣으면 결과가 처참했습니다. 도입부의 카페 메뉴판이 단적인 예죠. 글자가 뭉개지거나 자모가 뒤섞여서, AI가 만든 이미지에 한글이 들어가면 텍스트를 전부 다시 얹는 후보정이 당연한 절차였습니다. AI 결과물은 레퍼런스가 아니라 "위에 다시 작업할 밑판" 정도의 수준이었죠.

챗GPT 이미지 2.0에서 그 부분이 눈에 띄게 개선되었습니다. OpenAI는 공식적으로 한국어를 포함한 비라틴 문자 렌더링의 개선을 발표했고, Arena 테스트 단계에서 커뮤니티는 텍스트 렌더링 정확도가 99%를 넘는다고 보고했습니다. 공식 벤치마크는 아니지만, 이전 모델과 차원이 다른 결과죠.

솔직히 이 모델이 실무에서 바로 최종 결과물로 쓸 수 있는 수준인지는 아직 모르겠습니다. 브랜드 가이드라인이 엄격한 에이전시나 대기업 디자인팀이라면 자간, 서체 규정, 컬러 코드까지 맞춰야 하니 아직 한참 부족할 수 있습니다. 하지만 디자인 인력이 없는 자영업자가 카페 메뉴판을 만들거나, 소규모 스타트업이 SNS 광고 소재를 빠르게 돌려야 하는 상황이라면 그냥 쓸 수도 있겠다는 생각입니다.

또, 프로토타입이나 초기 시안 단계에서는 충분히 쓸 수 있는 수준 정도도 된 것 같습니다.

그래서 실무자는 뭘 하면 되나요?

지금까지 AI가 디자인 영역으로 이동하는 움직임을 함께 살펴봤습니다. 그러면 실무자들은 지금 뭘 하면 될까요? 거창한 커리어 전략대신, 당장 실천해볼 수 있는 것들을 정리해봤습니다.

1) 무엇이 바뀌었고, 안 바뀌었는지 직접 확인하세요

챗GPT 이미지 2.0은 무료입니다. ChatGPT에 접속해서 본인이 실무에서 하는 작업. 포스터 레이아웃, 앱 UI 목업, 인포그래픽, 광고 배너를 프롬프트로 넣어보세요. 남이 정리해준 기사를 읽는 것과 직접 프롬프트를 넣어보는 건 해상도가 전혀 다릅니다.

구체적으로 테스트해볼 만한 것들: 한글 텍스트가 포함된 포스터, UI 요소가 복잡한 앱 화면, 인포그래픽, 캐릭터가 여러 장에 걸쳐 일관되어야 하는 시퀀스(Thinking 모드)

2) AI가 만든 결과물의 "검수자"가 되지 말고, "디렉터"가 되세요

글로벌 IT 리뷰 매체인 Tom's Guide는 챗GPT 이미지 2.0 리뷰에서, "디자이너가 실제로 쓸 수 있는 첫 번째 AI 이미지 모델"이라고 평가했습니다. 하지만 AI가 초안을 뽑아주고, 나는 그걸 다듬는 편집자 역할에 안주하면 AI 성능이 올라갈 때마다 내 가치가 줄어듭니다. 대신 나의 프로젝트에서 풀어야 할 시각적 문제가 무엇인지 정의하고, AI에게 방향을 지시하고, 결과물이 브랜드·사용자 맥락에 맞는지 판단하는 "디렉터" 역할을 가져가야 합니다. AI가 속도를 내고, 디자이너가 방향을 잡는 구조가 지금 가장 현실적인 협업 형태입니다.

3) 디자인 시스템 역량을 키우세요

Claude Design의 핵심 기능이 코드베이스에서 디자인 시스템을 자동 추출하는 것이라는 점이 시사하는 바가 있습니다. 앤트로픽 자체 가이드에서도 "디자인 시스템 없이 Claude Design을 쓰면 기능적이지만 범용적인 결과물이 나온다"고 명시하고 있죠. AI가 아무리 발전해도, 디자인 시스템을 처음 설계하고 유지하는 건 사람의 몫입니다. 색상, 타이포그래피, 컴포넌트 패턴, 스페이싱 규칙을 체계적으로 만들고 관리할 수 있는 디자이너는 AI 시대에 오히려 더 필요해집니다. AI가 빠르게 결과물을 찍어낼수록, 일관성을 잡아주는 시스템의 가치는 올라가니까요.

4) 이미지 생성과 디자인 워크플로우, 양쪽을 모두 경험하세요

챗GPT 이미지 2.0과 Claude Design은 같은 AI 디자인"이라는 이름 아래 전혀 다른 도구입니다. 하나는 더 정확한 이미지를 만들고, 하나는 비디자이너도 디자인 결과물을 만들 수 있게 합니다. 둘 다 써보면 각각의 강점과 한계가 보이고, 어떤 작업에 어떤 도구를 쓸지 판단할 수 있게 됩니다. 이 판단력을 기르는 것이 스스로의 경쟁력이 되어줄 거라 생각합니다.

5) 고객과 비즈니스 맥락에 더 가까이 다가가세요

AI가 아직 못 하는 걸 정확히 짚어보면 이렇습니다. 이 화면이 왜 이렇게 디자인 되어야 하는지를 설명하는 일. 사용자가 이 버튼을 누른 뒤 어떤 감정을 느낄지 예측하는 일. 브랜드가 이 시장에서 어떤 인상을 남겨야 하는지 판단하는 일. 이는 우리 서비스의 고객과 비즈니스를 깊이 이해해야만 가능한 영역입니다. AI가 실행 속도를 올려주는 만큼, 디자이너가 "무엇을 만들 것인가"의 판단에 더 많은 시간을 쓸 수 있게 되는 건 오히려 기회입니다.

마치며: 도구가 바뀔 때, 남는 건 판단이다

최근 몇 주 사이에 AI 디자인 모델에 많은 변화가 있었습니다만, 결국 도착점은 같습니다. 더 많은 사람이 더 빠르게 시각물을 만들 수 있는 세계. 그 세계에서 만드는 속도의 가치는 내려갈 수밖에 없습니다. 도구가 평준화되면 누구나 비슷한 퀄리티의 시안을 뽑을 수 있으니까요. 이를 대신해 올라가는 것은, 만들어진 열 개 중에서 맞는 하나를 고르는 능력(판단력). 나머지 아홉 개가 왜 안 되는지를 설명할 수 있는 능력(도메인 지식)입니다.

사용자가 화면을 어떤 순서로 훑는지 아는 건, 사용성 테스트를 수없이 지켜본 사람이 아는 겁니다. 이 레이아웃이 전환율을 깎아먹을 거라는 직감은, 비슷한 실수를 직접 겪어본 사람에게서 나오죠. 앞으로 도구는 계속 바뀔 겁니다. 3개월 뒤면 지금보다 더 좋은 모델이 나오겠죠. 하지만 이 능력이 있는 사람은 도구가 바뀌어도, 하는 일은 변하지 않을 겁니다.

<출처>

]]>

10년 차 디자이너의 바이브 코딩 실험기

플로우차트를 피그마 밖으로 꺼내보자

제품을 만들다 보면, 완성된 화면을 흐름으로 보고 싶다는 니즈는 생각보다 흔하다. 피그마에서 협업을 좀 해본 팀이라면 다들 한 번쯤은 느낀다. 화면은 잘 만들어졌는데, 그래서 이게 전체적으로 어떻게 이어지는데? 라는 질문이 꼭 나온다. 하나하나 프레임만 보고 있으면 분명 잘 만든 것 같은데, 전체 유저 플로우로 놓고 보면 갑자기 길을 잃는다. 그래서 플로우차트가 필요해진다. 이건 새로운 욕망도 아니다. 이미 피그마 플러그인도 많고, 피그잼도 있다. 문제는 늘 그렇듯 된다와 쓸 만하다는 다르다는 데 있다.

항상 플로우차트에 대한 수요가 존재한다. <출처: 피그마>

플러그인은 처음엔 꽤 솔깃하다. 피그마 안에서 바로 선을 잇고 흐름을 볼 수 있으니까. 그런데 조금만 프로젝트가 커지면 금방 숨이 찬다. 디자인 프레임과 플로우차트가 한 파일 안에 같이 있다 보니 일단 보기부터 불편해진다. 화면 정리하려고 열었는데 선이 여기저기 깔려 있고, 연결선도 결국 파일 안에 생성되는 요소라 프레임 수가 슬금슬금 몇 배로 불어난다. 처음엔 괜찮은데, 나중엔 파일이 약간 다이어트 실패한 겨울 패딩처럼 부해진다. 더 큰 문제는 수정이다. 디자인이 바뀌면 연결선도 다시 손봐야 한다. 화면 하나 움직였더니 선이 다 삐뚤어지고, 프레임 구조가 바뀌면 사실상 전면 재시공에 가까워진다. 한 번은 편한데 계속 쓰기엔 피로가 쌓이는 방식이다.

플로우차트를 만들 때 도와주는 피그마 플러그인들 <출처: 피그마 커뮤니티, 각 플러그인 상세 페이지>

피그잼은 또 다르다. 아이데이션하거나 짧은 유저 패스를 설명할 때는 확실히 좋다. 여기는 오히려 플로우를 그리라고 만든 동네니까 그런 쪽은 편하다. 그런데 제품 전체 흐름을 보기 시작하면 갑자기 일이 커진다. 피그마 디자인을 다시 복사해서 가져와야 하고, 그걸 정리하고, 붙이고, 또 맞춰야 한다. 무엇보다 원본 디자인이 업데이트돼도 피그잼에 가져다 놓은 결과물은 그걸 따라가지 않는다. 다시 말해 복붙한 순간부터 이미 사본 인생이 시작된다. 이게 짧은 회의용 보드라면 괜찮은데, 계속 살아 움직이는 제품 플로우를 다루기엔 점점 버거워진다.

피그마 프레임을 붙여 넣는 건 좋은데, 디자인을 바꾸거나 화면을 바꾸면 다시 연결을 다 해줘야 한다. <출처: 작가>

그래서 결론은 꽤 빨리 났다. 플로우차트는 피그마 밖으로 꺼내야 한다는 것. 같이 있으면 편할 것 같지만, 실제로는 분리하는 편이 더 낫겠다는 판단이었다. 다만 그냥 밖으로만 나가면 안 됐다. 제품 원칙은 아주 분명해야 했다.

첫째, 피그마 디자인과 동기화될 것. 둘째, 수정이나 삭제 같은 변경 내역을 따라갈 것. 셋째, 피그마와 사용 경험이 비슷해서 적응 비용이 낮을 것. 낯선 툴에 입사 교육받는 느낌이 아니라, 피그마 쓰던 사람이 아 이 정도면 바로 쓰겠네 싶어야 했다. 그렇게 직접 만들기 시작한 게 피그마플로우였고, 지금은 약 2달 반 정도 작업한 끝에 베타 런칭을 준비하고 있다. 이번 글은 그 과정에 대해 소개하고자 한다.

‘해줘’로 시작한 바이브 코딩

완전 초기 아이데이션 단계에선 프레이머도 후보에 있었다. <출처: 작가>

초기 기획은 전형적인 바이브 코딩식으로 갔다. 먼저 ChatGPT와 계속 대화를 주고받으면서 아이데이션과 기획 초안을 만들었다. 이건 어떤 서비스여야 하는지, 왜 기존 방식이 별로였는지, 어떤 경험은 꼭 지켜야 하는지, 사용자는 어디서 편해야 하는지를 계속 말로 밀고 당기면서 정리했다. 이 단계에서는 정갈한 기획서 한 장보다, 머릿속에 떠다니는 생각을 자꾸 언어로 꺼내는 게 더 중요했다.

쉽게 말하자면, 처음엔 해줘로 시작하면 된다. 이거 대충 이런 서비스면 좋겠는데, 이런 문제 해결해주는 거 있으면 좋겠는데, 정도로 말을 던진다. 그런데 그렇게 던지면 결과물이 나오긴 나온다. 다만 내가 생각한 토스 같은 매끈한 무언가가 아니라, 어딘가 시중은행 이벤트 페이지에서 굴러다니다 주워 온 포인트 적립 앱 같은 느낌으로 나오기 쉽다. 짜잔 하고 열어봤는데 결과물이 누더기면, 그때부터 치졸해질 순간이다.

이건 왜 이런지, 저건 어디에 쓰는지, 어떤 상황에서 필요한지, 어떤 식으로 동작해야 하는지 하나씩 설명이 붙는다. 결국 처음부터 맥락을 많이 깔아두는 쪽이 훨씬 낫다는 걸 알게 된다. 원래 좋은 스토리텔러가 도입부에서 빌드업을 탄탄하게 쌓듯, 바이브 코딩도 앞단 설명이 허술하면 뒤가 계속 삐걱거린다.

본격적으로 아이데이션을 진행한 뒤, 클로드 코드로 작업을 이전할 준비까지 마쳤다. <출처: 작가>

어느 정도 얼개가 잡힌 뒤에는 그 대화 내용을 바탕으로 실제 개발에 필요한 제품 설계 문서를 만드는 단계로 넘어갔다. 여기서는 역할을 좀 나눴다. 먼저 GPT에 지금까지의 대화를 바탕으로 제품 개발에 필요한 문서를 한 장 정리해달라고 하고, 그걸 다시 제미나이에게 가져가서 조금 더 개발 친화적인 설계서 형태로 정리하게 했다. 쉽게 말하면 GPT랑은 방향과 논리를 맞추고, 제미나이한테는 그걸 좀 더 개발 문서처럼 써달라고 한 셈이다.

그리고 그렇게 정리된 설계서를 들고, 클로드 코드로 갔다. 사실 이 과정도 처음에는 GPT에서 기획과 코드 구축까지 다 진행했었는데, 뭔가 마음에 안 들어서 다른 AI들에게 똑같이 다 시켜보고 얻은 나름의 방법이다.

코덱스 등장 전엔 클로드 코드가 유일한 선택지나 다름없었다. <출처: 작가>

개발 환경도 같이 세팅했다. GitHub 저장소를 만들고, Vercel 배포를 연결하고, 저장소와 배포 환경을 붙였다. 다행히 이전에 저장소를 만드는 것과 Vercel 배포는 해본 적이 있어서 문제는 없지만, 처음 해보는 사람이라면 왜 그래야 하는지 의문이 들 법하다. 만약 그런 부분이 있다면 작업하면서 그냥 물어보면 된다. 왜 그렇게 하는지 설명해달라고 하면 또 설명해준다. 그 다음엔 클로드 코드가 작업한 결과물을 보면서 수정 사항을 전달하고, 그걸 다시 고치고, 또 확인하는 방식으로 고도화를 이어갔다. 여기까지만 보면 요즘 말하는 바이브 코딩 성공담처럼 보인다. 대화로 기획하고, 문서로 정리하고, AI한테 코드를 맡기고, 배포까지 금방 연결하는 흐름 말이다. 실제로 초반 속도는 꽤 좋았다.

A를 고치면 B가 터지고, B를 고치면 C가 안 됐다

개발자분들이 이런 환경에서 일하고 계셨다는 게 놀랍다. <출처: 작가, ChatGPT로 생성>

기본적인 기능을 만들어두는 것까진 됐는데 그 다음이 이제 문제였다. 클로드 코드로 작업을 계속하다 보니 전형적인 꼬임이 시작됐다. A를 고치면 B에서 문제가 터지고, B를 고치면 C가 안 된다. 또 C가 안 되는 상황이랑 B를 고치다가 A가 고장 났다는 걸 다시 설명하면, 이번엔 셋 다 비슷하게 무너져 있거나 갑자기 D에서 오류가 나기 시작한다.

약간 두더지 잡기인데 두더지가 한 마리씩 나오는 게 아니라 집단으로 튀어나오는 느낌이다. 그래서 뒤늦게 작업 히스토리를 저장해서 맥락을 공유하는 스킬도 붙여보고, 작업 전후를 분석하는 스킬도 써봤다. 그래도 한 번에 여러 작업을 동시에 안정적으로 굴리기엔 한계가 있었다. 계속 요약본을 주고받다 보니 결과물이 아주 미세하게 다른 방향으로 완성되고, 나는 그걸 다시 설명해서 미세하게 교정하고, 그러다 또 다른 데가 어긋나는 식이었다. 빠르게 만들 수는 있는데, 전체 제품 맥락을 일관되게 유지하는 건 또 다른 문제라는 걸 여기서 아주 찐하게 배웠다.

슬슬 인내심의 한계를 시험하는 클로드 코드 <출처: 작가>

1시간 만에 끝나버린 일간 사용량 한도는 덤이다. <출처: 작가>

이쯤에서 등장한 게 코덱스였다. 체감상 제일 컸던 차이는, 이쪽은 하나의 GitHub 저장소를 기준으로 프로젝트 전체를 같이 보고 작업한다는 점이었다. 같은 프로젝트 안에서 여러 작업이 동시에 돌아가도, 각각을 따로따로 보는 느낌이 아니라 위에서 전체를 내려다보는 컨트롤 타워가 있는 느낌에 더 가까웠다.

뭔가 답답한 속을 시원하게 뚫어주는 것 같은 코덱스의 분석 <출처: 작가>

예를 들어, A를 고쳤더니 B에서 문제가 생겼다 싶으면, 그냥 B만 급하게 막는 게 아니라 A의 어떤 변화가 B에 영향을 줬는지를 같이 분석하고, 필요하면 B 구조를 다시 설계하는 식으로 접근했다. 물론 AI인 이상 클로드 코드에서 겪었던 문제가 코덱스에는 아예 없다고 할 수는 없다. 다만 대응 퀄리티와 맥락 유지 측면에서는 확실히 만족도가 높았다. 클로드 코드로 몇 주를 붙잡고 씨름하던 파트가, 코덱스로 넘어간 뒤 며칠 만에 매끄럽게 돌아간 순간도 있었다. 드디어 말이 통하는 외주 개발팀 PM을 만난 느낌에 가까웠다.

만들고 싶은 기능보다 먼저 정해야 하는 것

그다음부터는 무턱대고 기능을 늘리기보다, 어디까지를 베타 제품 범위로 볼지 먼저 정하는 게 중요해졌다. 이걸 안 정하면 일정도 안 나온다. 그래서 내가 생각한 최종 제품 형태를 먼저 전달하고, 이걸 전부 구현하려면 어떤 기능과 기술이 필요한지를 역으로 정리해달라고 했다. 그리고 그 목록을 보고 다시 최소 가치 형태를 좁혔다. 결국 핵심은 하나였다. 피그마에서 디자인을 동기화해서 가져오고, 그걸 연결선으로 이을 수 있어야 한다는 것. 다른 기능은 없어도 이건 반드시 제대로 되어야 했다. 코덱스가 우선순위를 정리해주면, 나는 그걸 조정하거나 그대로 받아서 순차적으로 작업을 진행했다. 스타일 수정이나 UI 조정처럼 영향 범위가 작은 것들은 병렬로 돌리기도 했다.

이 과정에서 꽤 유용했던 제안이 플래그였다. 전후 비교가 필요하거나, 혹시 롤백이 필요할 수도 있으니 개선 전후 디자인 코드를 둘 다 유지한 상태에서 특정 URL 파라미터로 새 버전을 볼 수 있게 하자는 방식이었다. 예전에는 한 번 업데이트하면 배포되기를 기다렸다가 확인하고, 이전 버전을 기억 속에서 더듬으면서 이 부분이 달라졌다고 설명하거나 다시 롤백을 요청해야 했다. 말 그대로 인간 비교 툴로 살고 있었다. 그런데 플래그를 도입한 뒤에는 QA 시간과 품질이 눈에 띄게 좋아졌다.

URL에 임시 주소를 붙여 A/B 테스트하듯 전후를 비교하는 플래그 방식 <출처: 작가>

이전 버전과 개선 버전을 바로 비교할 수 있고, 위험한 변경도 훨씬 덜 불안하게 볼 수 있었다. 바이브 코딩이 빠를수록 이런 장치가 더 중요해진다는 걸 여기서 실감했다. 바꾸는 건 빨라졌는데 비교가 느리면 결국 사람만 고생한다.

물론 제품은 생각보다 자꾸 커졌다. 대표적인 사례가 삭제 처리였다. 프로젝트 파일을 지웠는데, 다른 브라우저에서 접속해보니 삭제가 안 되어 있었다. 왜 삭제한 게 계속 보이냐고 물었더니, 삭제 정보를 클라우드가 아니라 브라우저 쪽에 저장하고 있던 거였다. 여기서 바로 일이 커졌다. 클라우드에 올라간 파일이면 어디서 접속하든 삭제 상태가 일관되어야 하지 않느냐는 질문이 생겼기 때문이다.

그런데 이걸 진짜 그렇게 만들려면 생각보다 경우의 수가 많다. 브라우저 A와 브라우저 B가 같은 파일을 보고 있을 때 A에서 지우면 B에선 어떻게 보여야 하는지, A에서 지웠는데 B에서 동시에 편집하면 삭제가 우선인지 편집이 우선인지, 편집이 우선이면 삭제는 취소되는 건지 같은 문제들이다. 여기서 다시 확인하게 됐다. 기획 단계에서 엣지 케이스를 최대한 먼저 찾아내고, 이럴 땐 이렇게 처리한다는 제품 정책을 세우는 일이 얼마나 중요한지 말이다.

어디에 집중하고, 어디에 집중하지 않아야 하는지 판단할 수 있는 좋은 기회였다. <출처: 작가, ChatGPT>

그리고 그 정책은 화려할수록 좋은 게 아니었다. 오히려 단순하고 일관될수록 훨씬 좋았다. 이유는 너무 현실적이다. 이럴 땐 이렇게, 저럴 땐 저렇게를 다 코드로 써야 하는데, 예외가 많아질수록 구조가 빠르게 복잡해진다. 구조가 복잡해지면 A를 고치다가 B가 꼬이고, B를 고치다가 다른 곳이 터지는 일이 자꾸 생긴다. 결국 제품 정책이 단순할수록 코드도 덜 꼬이고, AI가 구현할 때도 덜 흔들린다. 정리하면 멋진 기능보다 먼저 중요한 건 단순한 규칙이었다. 서비스가 똑똑해 보이는 건 예외를 많이 처리해서가 아니라, 애초에 예외를 적게 만드는 방식으로 설계됐을 때가 많다.

SaaS가 아닌, IaaS(Individual as a Solution)

개인의 힘만으로도 솔루션을 구축해 낼 수 있다. 소프트웨어가 아닌 개인이 솔루션의 단위가 되는 것이다. <출처: 작가, ChatGPT>

그렇게 두 달 이상 코덱스와 계속 주고받으면서 고도화를 반복한 끝에, 베타 오픈을 시작했다. 사전 신청 사용자도 100명 이상 확보했다. 그리고 이 과정에서 예상보다 더 흥미로웠던 건 일반 사용자용 제품 그 자체보다, 그 옆에서 어드민과 내부 도구를 만드는 경험이었다. 어드민에는 생각보다 많은 걸 넣을 수 있었다. 구글 애널리틱스를 연결해서 유입 데이터를 가공해 보여주는 대시보드, 클릭과 스크롤 이벤트를 붙여 UI별 행동 로그를 보는 분석 도구, 홍보용 URL 관리와 그 URL로 들어와 신청한 사람 수 추적, 사용자 관리와 사전 신청자 관리 같은 것들 말이다. 예전 같으면 외부 SaaS를 당연하게 붙였을 기능들이, 이제는 필요한 모양대로 꽤 빠르게 구현된다.

이벤트 로그를 달아 사용자 행동 데이터를 수집할 수 있게 만든 내부 도구 <출처: 작가>

이 지점에서 어드민과 내부 도구 구축 쪽의 잠재력을 확실히 봤다. 요즘 SaaS 제품들이 왜 점점 더 생존하기 어려워진다고 하는지 조금은 알 것도 같았다. 예전에는 믹스패널이나 앰플리튜드가 당연한 선택지처럼 느껴졌다면, 지금은 필요한 기능만 콕 집어 직접 만들 수도 있다는 감각이 생긴다. 말만 하면 다 만들어주는데? 같은 순간이 실제로 온다.

다만 여기서 가장 중요했던 건, AI가 구현을 대신해 준다고 해서 제품 판단까지 대신해 주지는 않는다는 점이었다. 실제로 코덱스가 제안한 방식이나 코드를 훑어보다가 내가 먼저 지적한 문제들이 꽤 있었다. 예를 들어, 피그마 로그인을 붙였으면, 그 순간부터 개인정보 처리방침이 필요하다. 피그마 이메일 주소와 사용자명은 개인정보이기 때문이다.

그런데 코덱스는 로그인 기능을 붙이는 데까지는 아주 매끄럽게 가도, 그다음 운영 요소까지는 알아서 챙기지 않았다. 내가 로그인한 유저들을 어드민에서 관리해야 하지 않느냐고 물어야 사용자 관리가 붙고, 사용자 관리를 한다면 개인정보 처리방침도 있어야 하지 않느냐고 물어야 그제서야 관련 문서가 따라왔다. AI는 정말 뚝딱 잘 만든다. 그런데 그 뚝딱 뒤에 따라와야 하는 정책, 운영, 책임 같은 것들은 사람이 계속 옆에서 봐줘야 한다.

AI 시대의 디자이너는 디렉터가 되어야 한다

결국 이번 작업을 하면서 더 확실해진 건, 바이브 코딩이 디자이너에게 엄청 강력한 도구라는 사실과 동시에 그래서 디자이너의 역할도 바뀐다는 사실이었다. 이제 UI 배경색이 어떻고 폰트 크기가 어떻고를 일일이 붙잡고 첨삭하는 사람에 머무르면 안 된다는 생각이 더 강해졌다. 그런 일은 앞으로 더 빠르게 자동화되거나 보조될 가능성이 크다.

대신 중요한 건 어떤 규칙으로 제품을 설계할지, 어떤 정책으로 예외를 처리할지, 무엇을 베타 범위에 넣고 무엇을 뒤로 미룰지, 어떤 운영 장치가 반드시 필요한지를 판단하는 능력이다. 쉽게 말하면 디자이너 개인이 AI 부사수를 거느린 작은 디렉터처럼 일할 수 있어야 한다는 뜻이다. 손으로 픽셀을 만지는 시간은 줄어들 수 있지만, 구조를 정하고 기준을 세우는 책임은 오히려 더 커진다.

디자이너 개인이 디렉터가 되어야 한다. <출처: 작가, ChatGPT>

피그마플로우를 바이브 코딩으로 만든 지난 2달 반은 그래서 단순히 서비스를 하나 만든 경험이라기보다, 디자이너의 일이 어디로 이동하고 있는지를 확인한 시간에 더 가까웠다. 아이디어를 실제 제품으로 빠르게 옮길 수 있는 환경은 분명 혁신적이다. 프로토타입을 넘어 베타 수준까지 밀어붙일 수 있다는 점도 예전과는 다르다. 그런데 그럴수록 더 중요해지는 건 디자인 그 자체보다 디자인을 가능하게 만드는 정책과 구조와 운영이다.

바이브 코딩은 분명 마법처럼 느껴질 때가 있다. 하지만 그 마법은 혼자 알아서 굴러가지 않는다. 옆에서 계속 질문하고, 방향을 바로잡고, 빠진 걸 챙기고, 예외를 줄여주는 사람이 있어야 한다. 그 역할이 앞으로 디자이너에게 점점 더 중요해질 것이다. 이제 디자이너는 예쁘게 만드는 사람을 넘어, AI 부사수들을 데리고 제품을 끝까지 끌고 가는 작은 디렉터가 되어야 한다. 그걸 못하면 솔직히 앞으로 꽤 힘들어질 것 같다는 생각이다.

]]>

[릴리즈 노트] ‘더 적은 토큰으로 더 나은 결과’ 내는 GPT 5.5 공개

※ 본문은 OpenAI의 <Introducing GPT‑5.5>를 신속하게 전달하기 위해 AI 번역 및 요약을 사용했습니다. 요즘IT 실무자에게 필요한 정보 전달을 위해 내용을 일부 생략하고 배치를 조정했습니다. Opus 4.7을 활용해 번역 및 요약했습니다.

[GPT-5.5 공개 핵심 요약]

한눈에 보기
오픈AI가 지금까지 내놓은 모델 가운데 가장 똑똑하고 직관적인 GPT-5.5 공개
GPT-5.4 대비 지능은 한 단계 높이면서도 토큰당 지연 시간(latency)은 동일
같은 코덱스(Codex) 작업을 더 적은 토큰으로 처리해 효율성도 개선
에이전트형 코딩, 컴퓨터 조작, 지식 노동, 초기 과학 연구 네 영역에서 성능 향상이 두드러짐

실제 사용 사례 (오픈AI 내부)
직원 85% 이상이 매주 코덱스 사용
재무팀: 24,771건(71,637쪽) 의 K-1 세금 서식 검토를 작년 대비 2주 단축
세일즈·마케팅 직원: 주간 리포트 자동화로 주당 5~10시간 절약
내부 인프라 개선: 코덱스가 트래픽 패턴을 분석해 휴리스틱 알고리즘을 작성, 토큰 생성 속도 20% 이상 향상

이용 범위와 요금
[챗GPT]
GPT-5.5 싱킹(Thinking): 플러스, 프로, 비즈니스, 엔터프라이즈 사용자
GPT-5.5 프로: 프로, 비즈니스, 엔터프라이즈 사용자 (더 어려운 문제·높은 정확도 작업용)
[코덱스]
플러스, 프로, 비즈니스, 엔터프라이즈, 에듀(Edu), 고(Go) 요금제 / 400K 컨텍스트 윈도
패스트(Fast) 모드: 토큰 1.5배 빠르게 생성, 비용 2.5배

누구에게 유용한가
소프트웨어 엔지니어: 거대한 코드베이스 전반의 맥락 유지, 모호한 오류 추론, 대규모 리팩터 작업에 특히 강점; 시니어 엔지니어 테스트에서 클로드 오퍼스 4.7(Claude Opus 4.7)보다 추론·자율성 면에서 뛰어나다는 평가
지식 노동자: 문서·스프레드시트·슬라이드 작성, 운영 리서치, 컴퓨터 조작 자동화가 필요한 실무자
연구자·전문직: 논문 비평, 기술 논거 시험, 데이터 분석 파트너; 특히 비즈니스·법률·교육·데이터 사이언스 영역에서 GPT-5.4 프로 대비 응답 품질 향상 보고
사이버 방어 담당자: '사이버용 신뢰 접근(Trusted Access for Cyber)' 프로그램을 통해 검증된 방어 업무에는 제한 완화

지금까지 내놓은 모델 가운데 가장 똑똑하고 직관적으로 쓸 수 있는 GPT-5.5를 공개합니다. 이번 공개는 컴퓨터로 일하는 새로운 방식을 향한 다음 걸음이기도 합니다.

GPT-5.5는 사용자가 무엇을 하려는지 더 빠르게 파악하고, 더 많은 일을 스스로 처리할 수 있습니다. 코드 작성과 디버깅, 온라인 조사, 데이터 분석, 문서와 스프레드시트 작성, 소프트웨어 조작은 물론, 작업이 끝날 때까지 여러 도구를 오가며 일하는 데에도 뛰어납니다. 모든 단계를 일일이 챙길 필요 없이, 여러 단계가 뒤얽힌 복잡한 작업을 GPT-5.5에 맡겨 두면 스스로 계획을 세우고, 도구를 쓰고, 작업 내용을 점검하고, 모호한 상황을 헤쳐 나가면서 일을 이어 나갑니다.

성능 향상이 특히 두드러진 분야는 에이전트형 코딩, 컴퓨터 조작, 지식 노동, 초기 단계 과학 연구입니다. 맥락을 가로지르며 추론하고 시간에 걸쳐 행동해야 성과가 나는 영역들이죠. GPT-5.5는 이런 지능 향상을 이루면서도 속도를 포기하지 않았습니다. 보통 모델이 커지고 성능이 좋아질수록 응답이 느려지기 마련이지만, GPT-5.5는 실제 서비스 환경에서 토큰당 지연 시간이 GPT-5.4와 같은 수준을 유지하면서 훨씬 높은 지능을 보여 줍니다. 또한 같은 코덱스(Codex) 작업을 끝내는 데 쓰는 토큰의 양이 눈에 띄게 줄었기 때문에, 성능뿐 아니라 효율성 측면에서도 한 단계 올라섰습니다.

이번 GPT-5.5는 지금까지 마련한 것 가운데 가장 강력한 안전장치와 함께 공개됩니다. 이는 유익한 작업에 대한 접근성은 그대로 유지하면서 오용은 줄이기 위한 장치입니다. 오픈AI는 자체 안전·대비 평가 체계 전반에 걸쳐 이 모델을 점검했고, 사내외 레드팀과 협력했으며, 고도화된 사이버 보안 및 생물학 분야 역량에 대한 표적 테스트를 추가했습니다. 또한 공개에 앞서 믿을 수 있는 얼리 액세스 파트너 약 200곳에서 실제 사용 사례에 관한 피드백을 모았습니다.

오늘부터 GPT-5.5는 챗GPT와 코덱스의 플러스(Plus), 프로(Pro), 비즈니스(Business), 엔터프라이즈(Enterprise) 사용자에게 차례로 배포되며, GPT-5.5 프로는 챗GPT의 프로, 비즈니스, 엔터프라이즈 사용자에게 배포됩니다. API 배포에는 또 다른 안전장치가 필요하기에, 대규모 서비스를 위한 안전 및 보안 요건을 놓고 파트너사 및 고객과 긴밀히 협의하고 있습니다. GPT-5.5와 GPT-5.5 프로는 머지않아 API로도 만나 볼 수 있습니다.

모델 성능

오픈AI는 에이전트형 AI를 위한 세계적 인프라를 구축하고 있습니다. 전 세계 개인과 기업이 AI로 일을 해낼 수 있게 하기 위해서입니다. 지난 1년 사이 AI는 소프트웨어 엔지니어링의 속도를 극적으로 끌어올렸습니다. 이제 코덱스와 챗GPT에 GPT-5.5가 들어가면서, 같은 변화의 물결이 과학 연구와 사람들이 컴퓨터로 하는 폭넓은 업무로 번져 나가기 시작했습니다.

여러 분야에 걸쳐 GPT-5.5는 단지 더 똑똑해진 데 그치지 않습니다. 문제를 풀어 나가는 방식 자체가 더 효율적이어서, 더 적은 토큰과 더 적은 재시도만으로도 수준 높은 결과를 내놓는 경우가 많습니다. 아티피셜 애널리시스가 산출하는 코딩 지수에서, GPT-5.5는 경쟁하는 최상위 코딩 모델의 절반 비용으로 최고 수준의 지능을 보여 줍니다.

이용 범위와 요금

오늘부터 GPT-5.5는 챗GPT와 코덱스의 플러스, 프로, 비즈니스, 엔터프라이즈 사용자에게 차례로 배포되며, GPT-5.5 프로는 챗GPT의 프로, 비즈니스, 엔터프라이즈 사용자에게 배포됩니다. GPT-5.5와 GPT-5.5 프로는 머지않아 API로도 만나 볼 수 있습니다.

챗GPT에서 GPT-5.5 싱킹은 플러스, 프로, 비즈니스, 엔터프라이즈 사용자가 쓸 수 있습니다. 더 어려운 질문과 더 높은 정확도를 요구하는 작업을 위해 설계된 GPT-5.5 프로는 프로, 비즈니스, 엔터프라이즈 사용자에게 제공됩니다.

코덱스에서는 GPT-5.5가 플러스, 프로, 비즈니스, 엔터프라이즈, 에듀(Edu), 고(Go) 요금제에서 제공되며, 400K 컨텍스트 윈도를 지원합니다. GPT-5.5는 패스트(Fast) 모드로도 쓸 수 있습니다. 이 모드는 토큰을 1.5배 빠르게 생성하는 대신, 비용이 2.5배로 책정됩니다.

API 개발자에게는 곧 Responses API와 Chat Completions API에서 gpt-5.5를 사용할 수 있게 됩니다. 요금은 입력 토큰 100만 개당 5달러, 출력 토큰 100만 개당 30달러이며, 컨텍스트 윈도는 100만 토큰입니다. 배치 및 플렉스 요금은 표준 API 요금의 절반이며, 우선 처리 요금은 표준 요금의 2.5배입니다. 더 높은 정확도가 필요한 작업을 위해 gpt-5.5-pro도 API로 공개될 예정이며, 요금은 입력 토큰 100만 개당 30달러, 출력 토큰 100만 개당 180달러입니다. 자세한 내용은 요금 페이지를 참고하시기 바랍니다.

GPT-5.5는 GPT-5.4보다 요금이 높게 책정되었지만, 지능도 더 뛰어나고 토큰 효율도 훨씬 좋습니다. 오픈AI는 코덱스에서 대다수 사용자가 GPT-5.4보다 더 적은 토큰으로 더 좋은 결과를 얻을 수 있도록 경험을 세심하게 다듬었으며, 구독 등급별로 넉넉한 이용량을 계속 제공합니다.

에이전트형 코딩

GPT-5.5는 오픈AI가 지금까지 선보인 에이전트형 코딩 모델 가운데 가장 강력합니다. 계획 수립, 반복 수행, 도구 조율 능력을 평가하는 복잡한 명령줄(command-line) 워크플로우 테스트인 터미널-벤치 2.0에서 GPT-5.5는 82.7%라는 최고 수준의 정확도를 기록했습니다. 실제 깃허브(GitHub) 이슈 해결 능력을 평가하는 SWE-Bench Pro에서는 58.6%를 달성해, 이전 모델보다 더 많은 과제를 한 번의 시도로 끝까지 해결해 냈습니다. 사람이 작업을 끝내는 데 드는 시간의 중앙값이 20시간에 이르는 장기 코딩 과제를 다루는 오픈AI의 내부 최상위 평가인 Expert-SWE에서도, GPT-5.5는 GPT-5.4보다 앞선 성적을 냈습니다.

세 가지 평가 모두에서 GPT-5.5는 GPT-5.4보다 더 적은 토큰을 쓰면서도 더 높은 점수를 받았습니다.

이 모델의 코딩 역량은 코덱스에서 특히 또렷하게 드러납니다. 코덱스 환경에서 GPT-5.5는 구현과 리팩터(refactor)부터 디버깅, 테스트, 검증에 이르기까지 폭넓은 엔지니어링 작업을 맡아서 처리할 수 있습니다. 초기 테스트 결과를 보면, GPT-5.5는 실제 엔지니어링 업무의 바탕이 되는 여러 행동—예컨대 거대한 시스템 전반에 걸쳐 맥락을 유지하기, 원인이 뚜렷하지 않은 오류를 두고 논리적으로 추론하기, 도구를 써서 가정을 점검하기, 주변 코드베이스 전체에 변경 사항을 이어서 반영하기—에서 더 나은 모습을 보여 줍니다.

GPT 5.5로 구현한 던전 게임

벤치마크 수치를 떠나, 얼리 테스터들은 GPT-5.5가 시스템의 구조를 이해하는 능력이 한층 뛰어나다고 말합니다. 무엇이 왜 실패하고 있는지, 수정은 어디에 들어가야 하는지, 이 변경이 코드베이스의 어디에 또 영향을 미치는지를 꿰뚫어 본다는 뜻입니다.

"지금까지 써 본 코딩 모델 가운데, 진정한 의미의 개념적 명료함을 갖춘 첫 모델입니다."

Every의 창업자이자 CEO인 댄 십퍼(Dan Shipper)는 GPT-5.5를 두고 "지금까지 써 본 코딩 모델 가운데, 진정한 의미의 개념적 명료함을 갖춘 첫 모델"이라고 표현했습니다. 그는 앱을 출시한 뒤 생긴 문제를 며칠 동안 디버깅하다가, 결국 소속 최정예 엔지니어 한 명을 투입해 시스템의 일부를 다시 짜게 했다고 합니다. 그는 GPT-5.5를 시험해 보려 사실상 시계를 되감아 보았습니다. 망가진 상태를 모델에 보여 주고, 엔지니어가 끝내 택했던 것과 같은 방향의 재작성을 이 모델도 내놓을 수 있을지 확인해 본 것입니다. GPT-5.4는 해내지 못했지만, GPT-5.5는 해냈습니다.

"정말로 저보다 높은 지능과 함께 일하고 있다는 느낌이 들었고, 거의 경외에 가까운 감정마저 생겼습니다."

MagicPath의 CEO인 피에트로 스키라노(Pietro Schirano) 역시 비슷한 도약을 목격했습니다. GPT-5.5가 수백 건의 프론트엔드 변경과 리팩터가 담긴 브랜치를, 그 사이 크게 바뀌어 있던 메인 브랜치로 병합해 냈고, 이 작업을 단 한 번에 약 20분 만에 마무리했기 때문입니다.

이 모델을 시험해 본 시니어 엔지니어들은, 추론 능력과 자율성 측면에서 GPT-5.5가 GPT-5.4와 클로드 오퍼스 4.7(Claude Opus 4.7)보다 눈에 띄게 뛰어나다고 입을 모았습니다. 별도의 지시가 없어도 문제를 미리 잡아내고, 앞으로 어떤 테스트와 검토가 필요할지를 내다본다는 것입니다. 한 사례에서는 어느 엔지니어가 협업형 마크다운 편집기의 댓글 시스템을 다시 설계해 보라고 맡긴 뒤, 돌아와 보니 거의 완성 단계에 이른 12개짜리 변경(diff) 묶음이 준비돼 있었다고 합니다. 다른 테스터들은 놀라울 만큼 구현을 고쳐 줄 일이 적었으며, GPT-5.4와 비교해 GPT-5.5가 내놓은 계획에 대한 신뢰도가 더 높았다고 이야기했습니다.

일찌감치 이 모델을 써 본 엔비디아(NVIDIA) 소속의 한 엔지니어는 이렇게까지 말했습니다. "GPT-5.5를 더는 쓸 수 없게 된다면, 마치 신체 일부가 잘려 나간 기분일 겁니다."

지식 노동

GPT-5.5를 코딩에 강하게 만드는 능력들은, 컴퓨터로 하는 일상 업무에서도 그대로 힘을 발휘합니다. 사용자의 의도를 더 잘 파악하기 때문에, 지식 노동의 전 과정—정보를 찾고, 무엇이 중요한지 판단하고, 도구를 쓰고, 결과물을 점검하며, 원재료를 쓸모 있는 무언가로 다듬어 내는 흐름—을 한층 매끄럽게 오갈 수 있습니다.

코덱스에서 GPT-5.5는 문서, 스프레드시트, 슬라이드 자료를 만들어 내는 능력이 GPT-5.4보다 뛰어납니다. 알파 테스터들은 운영 리서치, 스프레드시트 모델링, 뒤엉킨 비즈니스 자료를 계획으로 빚어내는 작업 등에서 GPT-5.5가 이전 모델보다 더 좋은 결과를 냈다고 전했습니다. 여기에 코덱스의 컴퓨터 조작 기능이 더해지면, "모델이 나와 함께 컴퓨터를 쓴다"는 감각에 한 걸음 더 가까워집니다. 화면에 무엇이 있는지 살피고, 클릭하고, 입력하고, 인터페이스를 넘나들고, 여러 도구를 정교하게 오가는 일을 모두 해낸다는 뜻입니다.

GPT 5.5 기반 업무 온보딩

오픈AI 내부 팀들은 이 강점을 이미 실제 업무 흐름에 녹여 쓰고 있습니다. 오늘날 오픈AI 직원의 85% 이상이 매주 코덱스를 사용하며, 소프트웨어 엔지니어링, 재무, 커뮤니케이션, 마케팅, 데이터 사이언스, 제품 관리 등 다양한 직군에 두루 걸쳐 있습니다. 커뮤니케이션 팀은 GPT-5.5를 코덱스에 얹어 6개월치 강연 요청 데이터를 분석했고, 평가 점수 체계와 위험도 판별 틀을 설계한 뒤, 위험도가 낮은 요청은 자동으로 처리하고 높은 요청은 사람 검토로 넘기도록 하는 슬랙 자동 에이전트를 검증했습니다. 재무 팀은 총 71,637쪽에 달하는 24,771건의 K-1 세금 서식(K-1 tax form)을 코덱스로 검토하면서, 개인 정보를 제외하는 작업 흐름을 짜 작년보다 2주 앞당겨 일을 마무리했습니다. 세일즈·마케팅(Go-to-Market) 팀에서는 한 직원이 주간 비즈니스 리포트 작성을 자동화해, 매주 5~10시간을 아낀 사례도 있습니다.

챗GPT에서 GPT-5.5 싱킹(Thinking)은 어려운 문제를 더 빠르게 풀어냅니다. 더 똑똑하면서도 더 간결한 답을 내놓기 때문에, 복잡한 일을 더 효율적으로 끝낼 수 있게 도와줍니다. 코딩, 리서치, 정보 종합과 분석, 문서 기반의 업무 같은 전문적인 작업에서 특히 뛰어나며, 플러그인을 함께 쓰는 상황에서 진가를 발휘합니다.

GPT-5.5 프로의 경우, 얼리 테스터들은 챗GPT가 감당할 수 있는 작업의 난이도와 결과물의 품질이 한 단계 올라섰다고 평가합니다. 더욱이 응답 지연 시간이 줄어들어, 까다로운 작업에 실질적으로 쓰기 훨씬 수월해졌습니다. GPT-5.4 프로와 비교했을 때 GPT-5.5 프로의 답변은 훨씬 포괄적이고, 구조가 잘 짜여 있으며, 정확하고, 관련성 높고, 쓸모 있다는 평가를 받았습니다. 특히 비즈니스, 법률, 교육, 데이터 사이언스 영역에서 성능이 두드러졌습니다.

GPT-5.5는 이런 작업을 대표하는 여러 벤치마크에서 최고 수준의 성능에 올라섰습니다. 44개 직업군에 걸쳐 명확한 요구 사항을 갖춘 지식 노동을 에이전트가 수행하는 능력을 평가하는 GDPval에서 GPT-5.5는 84.9%를 기록했습니다. 모델이 실제 컴퓨터 환경을 스스로 조작할 수 있는지 측정하는 OSWorld-Verified에서는 78.7%를, 복잡한 고객 응대 업무 흐름을 다루는 Tau2-bench Telecom에서는 프롬프트 튜닝 없이 98.0%를 달성했습니다. 이 외에 다른 지식 노동 벤치마크에서도 좋은 성적을 냈습니다. FinanceAgent에서 60.0%, 내부 투자은행 모델링 과제에서 88.5%, OfficeQA Pro에서 54.1%를 기록했습니다.

과학 연구

GPT-5.5는 과학·기술 연구 작업 흐름에서도 눈에 띄는 발전을 보여 줍니다. 이런 작업은 어려운 질문 하나에 답하는 것으로 끝나지 않습니다. 연구자는 아이디어를 탐색하고, 근거를 모으고, 가정을 시험하고, 결과를 해석하고, 다음에 무엇을 시도할지 결정해야 합니다. GPT-5.5는 이 반복 과정을 다른 모델보다 더 끈질기게 이어 갑니다.

특히 GPT-5.5는 유전학과 정량 생물학 영역의 다단계 과학 데이터 분석에 초점을 맞춘 새로운 평가인 GeneBench에서 GPT-5.4보다 또렷한 개선을 보였습니다. 이런 문제를 풀려면, 모델은 관리·감독이 거의 없는 환경에서 모호하거나 오류를 품은 데이터를 놓고 추론할 줄 알아야 하고, 숨은 교란 변수나 품질 관리(QC) 실패처럼 현실적인 난관을 다룰 줄 알아야 하며, 최신 통계 기법을 올바르게 구현하고 해석해 내야 합니다. 이런 과제가 과학 전문가에게도 여러 날이 걸리는 프로젝트에 해당한다는 점을 감안하면, 이 모델의 성능은 더욱 놀랍게 다가옵니다.

마찬가지로, 실제 생물정보학 및 데이터 분석을 바탕으로 설계된 벤치마크인 BixBench에서도 GPT-5.5는 점수가 공개된 모델들 가운데 가장 앞선 성능을 기록했습니다. 이 모델의 과학적 역량은 이제 생물의학 연구의 최전선에서 연구 속도를 실질적으로 끌어올릴 만큼, 명실상부한 공동 연구자로 기능할 수 있는 수준에 올라섰습니다.

또 다른 사례로, 맞춤형 하네스를 적용한 GPT-5.5의 내부 버전은 조합론의 핵심 대상 중 하나인 램지 수에 관한 새로운 증명을 발견하는 데 기여했습니다. 조합론은 그래프, 네트워크, 집합, 패턴처럼 서로 떨어져 있는 대상들이 어떻게 맞물리는지를 연구하는 분야입니다. 램지 수는 거칠게 말해, 어떤 네트워크가 얼마나 커져야 일정한 종류의 질서가 반드시 나타나게 되는지를 묻는 값입니다. 이 영역의 성과는 드물고, 기술적으로도 까다로울 때가 많습니다. 그런데 이번에 GPT-5.5는 비대각 램지 수에 관한 오랜 점근적 사실을 뒷받침하는 증명을 찾아냈고, 이는 이후 린으로 검증되었습니다. 이 결과는 GPT-5.5가 단순히 코드를 짜거나 설명을 덧붙이는 데 그치지 않고, 핵심 연구 분야에서 예상치 못한 유용한 수학적 논증까지 기여할 수 있다는 구체적인 예시입니다.

얼리 테스터들은 챗GPT의 GPT-5.5 프로를 한 번에 답을 내주는 엔진처럼 쓰기보다는, 연구 파트너처럼 활용하는 모습을 보였습니다. 여러 차례 원고를 비평해 나가거나, 기술적 논거를 시험해 보거나, 분석 방안을 제안하게 하거나, 코드·메모·PDF 자료를 함께 다루는 식입니다. 공통점은 하나입니다. GPT-5.5가 연구자의 작업을 질문에서 실험으로, 실험에서 결과물로 더 매끄럽게 이끌어 준다는 것입니다.

잭슨 유전체 의학 연구소의 면역학 교수이자 연구자인 데리야 우누트마즈(Derya Unutmaz)는, 62개 표본과 약 2만 8천 개 유전자로 이뤄진 유전자 발현 데이터셋을 GPT-5.5 프로로 분석했습니다. 그 결과 그는 단순히 발견 사항을 요약하는 데 그치지 않고, 핵심 질문과 통찰까지 짚어 주는 상세한 연구 보고서를 받아 들었습니다. 본인 말로는 자신의 팀이 해냈다면 몇 달은 걸렸을 작업이라고 합니다.

폴란드 포즈난(Poznań)의 아담 미츠키에비치 대학교 수학과 조교수인 바르토시 나스크렝키(Bartosz Naskręcki)는 GPT-5.5를 탑재한 코덱스로, 단 한 번의 프롬프트만으로 11분 만에 대수기하학 앱을 만들어 냈습니다. 이 앱은 두 이차 곡면이 만나는 교선을 시각화한 뒤, 그로부터 얻어진 곡선을 바이어슈트라스 모델로 변환했습니다.

이후 그는 더 안정적인 특이점 시각화 기능과, 후속 연구에 재활용할 수 있는 정확한 계수 표기를 덧붙여 앱을 확장했습니다. 그에게 더 큰 변화는, 이전에는 전용 도구가 있어야 가능했던 맞춤형 수학 시각화와 컴퓨터 대수 작업 흐름을, 이제 코덱스가 함께 구현해 준다는 점입니다. 이 사례들은, GPT-5.5가 전문가의 의도를 실제로 작동하는 연구 도구와 분석 결과로 바꿔 낼 수 있음을 보여 줍니다.

바르토시 나스크렝키가 만든 대수학 앱

차세대 추론 효율성

GPT-5.5를 GPT-5.4와 같은 지연 시간으로 서비스하려면, 추론(inference)을 개별 최적화의 묶음이 아닌 하나의 통합 시스템으로 새롭게 바라봐야 했습니다. GPT-5.5는 엔비디아 GB200 및 GB300 NVL72 시스템에 맞춰 함께 설계되고, 그 위에서 학습되고, 그 위에서 서비스됩니다. 오픈AI가 목표한 성능 수준에 도달하는 과정에서 코덱스와 GPT-5.5가 핵심 역할을 했습니다. 코덱스는 팀이 아이디어에서 벤치마크 가능한 구현까지 더 빠르게 나아가도록 도왔고, 접근 방식을 스케치하고, 실험을 구성하고, 어떤 최적화 방안에 더 깊이 투자할 가치가 있는지 가려내는 일을 함께 해냈습니다. GPT-5.5는 스택 자체에 담아야 할 핵심 개선점을 찾아내고 구현하는 과정에도 기여했습니다. 간단히 말해, 이 모델은 자기 자신을 서비스하는 인프라의 개선에 힘을 보탠 셈입니다.

그런 개선 중 하나가 부하 분산과 분할 휴리스틱입니다. GPT-5.5 이전에는 하나의 가속기에 들어오는 요청을 미리 정해진 개수의 덩어리로 쪼개서 여러 연산 코어에 고르게 나눴습니다. 큰 요청과 작은 요청이 같은 GPU에서 함께 돌아갈 수 있게 하기 위해서입니다. 그러나 미리 정해 둔 고정 개수의 덩어리가 모든 트래픽 모양에 맞는 것은 아니었습니다. GPU를 더 잘 쓰기 위해, 코덱스는 몇 주치 실제 운영 트래픽 패턴을 분석한 뒤, 작업을 최적으로 나누고 분배하는 맞춤형 휴리스틱 알고리즘을 직접 짰습니다. 이 노력은 기대를 웃도는 효과로 돌아왔고, 토큰 생성 속도를 20% 넘게 끌어올렸습니다.

모두의 안전을 위한 사이버 보안 발전

보안 취약점을 찾아내고 메우는 일에 매우 능한 AI가 등장할 세상을 준비하는 일은 혼자 해낼 수 없는 과제입니다. 생태계 전체가 함께 회복탄력성을 쌓아 올려야 합니다. 이를 위해서는 모델 접근의 보편화와 반복적인 배포를 통해 새로운 사이버 방어 시대를 열어 나가야 합니다.

최전선 모델은 사이버 보안 영역에서 점점 더 강력해지고 있습니다. 이 역량은 앞으로 폭넓게 퍼져 나갈 것이기에, 오픈AI는 이 힘을 사이버 방어의 속도를 높이고 생태계를 탄탄하게 만드는 방향으로 쓰이게 하는 것이 가장 올바른 길이라고 믿습니다.

GPT-5.5는 사이버 보안처럼 세상에서 가장 어려운 과제 중 일부를 풀어낼 수 있는 AI로 향해 가는, 점진적이지만 중요한 한 걸음입니다. 지난 12월 GPT-5.2를 공개하면서 오픈AI는 이미 모델이 사이버 영역에서 오용될 여지를 줄이기 위해 필요한 안전장치를 선제적으로 마련했습니다. 이번 GPT-5.5에서는 사이버 위험 가능성을 걸러 내는 분류기를 한층 엄격하게 적용합니다. 시간을 두고 이 분류기를 조정해 나가는 동안, 일부 사용자는 처음에는 다소 불편함을 느낄 수 있습니다.

오픈AI는 모델이 점진적으로 발전해 온 지난 수년 동안 사이버 보안을 준비 태세 프레임워크의 한 범주로 다뤄 왔고, 그 사이 완화 조치를 반복적으로 개발하고 보정해 왔습니다. 의미 있는 사이버 보안 역량을 갖춘 모델을 책임감 있게 내놓을 수 있도록 준비해 온 셈입니다.

오픈AI는 이 정도의 사이버 역량에 걸맞은 업계 최고 수준의 안전장치를 배포합니다. 지난해 GPT-5.2에서 사이버 보안 전용 안전장치를 처음 도입한 이래, 이를 꾸준히 시험하고 다듬으며 이후 배포 때마다 확장해 왔습니다. GPT-5.5에서는 위험도가 더 높은 활동과 민감한 사이버 요청에 한층 촘촘한 통제 장치를 설계했고, 반복적인 오용을 겨냥한 보호 장치도 덧붙였습니다. 폭넓은 접근성은 모델 안전성, 인증된 사용, 금지된 용도에 대한 모니터링 영역에 꾸준히 투자한 덕에 가능해졌습니다. 외부 전문가들과 여러 달에 걸쳐 협력하며 이 안전장치의 견고함을 개발하고, 시험하고, 다듬어 왔습니다. GPT-5.5와 함께라면 개발자는 자신의 코드를 한결 수월하게 지킬 수 있고, 동시에 악의적 행위자에 의해 피해가 커질 가능성이 가장 높은 사이버 작업 흐름에는 더 강한 통제가 걸리게 됩니다.

모든 층위에서 사이버 방어 속도를 끌어올리기 위해 접근 범위를 넓힙니다. 오픈AI는 사이버 허용 모델을 '사이버용 신뢰 접근' 프로그램을 통해 제공하며, 그 첫 출발을 코덱스로 시작합니다. 여기에는 출시 시점에 특정 신뢰 신호를 충족한 검증된 사용자에게 적용되는 제한 완화와 함께, GPT-5.5의 고급 사이버 보안 역량에 대한 확장된 접근 권한이 포함됩니다. 중요 기반시설 방어를 책임지는 조직은, 엄격한 보안 요건을 충족한다는 전제 아래 내부 시스템 보호를 위해 GPT-5.4-Cyber 같은 사이버 허용 모델을 쓰기 위한 신청을 할 수 있습니다. 이를 통해, 폭넓은 범위의 검증된 방어 담당자들이 정당한 보안 업무에 필요한 더 강력한 도구를, 불필요한 마찰 없이 쓸 수 있게 됩니다. 중요한 방어 역량에 대한 접근을 보편화하겠다는 뜻입니다. 사용자는 chatgpt.com/cyber에서 신뢰 접근을 신청할 수 있으며, 검증된 방어 업무에 GPT-5.5를 쓸 때 불필요한 거부가 줄어듭니다.

공공의 이익을 위해 중요 기반시설을 지키고자 정부 파트너들과 협력하고 있습니다. 오픈AI는 정부 파트너들과 함께, 사람들의 삶을 지탱하는 시스템—납세자의 중요한 데이터를 지키는 디지털 시스템부터 지역사회의 전력망과 상수도에 이르기까지—을 책임지는 믿을 만한 공직자들의 방어 업무를 고도화된 AI가 어떻게 뒷받침할 수 있을지 모색하고 있습니다.

오픈AI는 GPT-5.5의 생물학·화학 및 사이버 보안 역량을 준비 태세 프레임워크상 '높음(High)' 등급으로 다룹니다. GPT-5.5가 사이버 보안 역량의 '치명적(Critical)' 수준에는 이르지 않았지만, 평가와 테스트 결과는 GPT-5.4보다 한 단계 올라선 역량을 갖고 있음을 보여 주었습니다.

여기에 더해 GPT-5.5는 공개 전 오픈AI의 안전 및 거버넌스 절차 전 과정을 거쳤습니다. 준비 태세 평가, 도메인별 테스트, 고도화된 생물학 및 사이버 보안 역량을 겨냥한 새로운 평가, 그리고 외부 전문가와 함께한 충실한 테스트가 모두 포함됩니다.

이러한 움직임은, 모델의 역량이 커져 갈수록 필요하다고 판단되는 오픈AI의 'AI 회복탄력성' 접근 방식을 보여 줍니다. 오픈AI는 시스템과 기관과 공공을 지키는 일을 하는 사람들의 손에 강력한 AI가 들어가기를 바랍니다. 이를 위해 가야 할 현실적인 길은 신뢰 접근, 역량 확장에 맞춰 함께 확장되는 견고한 안전장치, 그리고 심각한 오용을 감지하고 대응할 수 있는 운영 역량입니다.

]]>

소버린 AI와 자체 생태계를 가진 IT 강대국, 러시아를 가다

모스크바의 4월은 계절의 경계가 무색할 만큼 가혹합니다. 저는 작년 이맘때쯤 모든 것이 막혀 있는 이곳 러시아에 주재원으로 처음 넘어왔습니다. 올해의 4월 역시, 눈이 오기도 비가 오기도 하며 많은 사람이 아직 두꺼운 패딩을 입고 다닙니다. 그런 나라에서 개발자로 하루하루를 살아가며 경험한 다양한 것들을 공유하고자 펜을 들었습니다.

모스크바의 4월 <출처: 작가 촬영>

러시아에서는 인터넷이 잘 안되거나, 메신저가 막히는 경우가 참 많습니다. 그뿐만 아니라 우리가 당연하게 여기는 구글의 검색창, 유튜브의 알고리즘, 인스타그램의 피드는 이곳에서 접근할 수 없습니다.

하지만 그 빈자리에 들어선 것은 기술의 퇴보가 아닙니다. 오히려 외부의 간섭 없이 스스로 진화하기 시작한 기묘하고도 강력한 자생적 생태계가 자라나고 있었습니다. 러시아 정부의 강력한 지원과 열정이 넘치는 개발자들의 손에서 다양한 IT시스템과 AI 서비스들이 만들어졌습니다. 국제 표준을 따르지는 않지만, 독립국가연합(CIS) 시장을 기반으로 자체 IT 생태계를 추구하며, 결제나 피지컬 AI 부문에서도 강력한 서비스를 가지고 있습니다.

무엇보다 AI 서비스 분야에서는 얀덱스GPT(YandexGPT), 기가챗(Gigachat) 등 서비스가 활발하게 쓰이고 있으며, 다양한 AI 결합 서비스들도 마찬가지로 나오고 있습니다. 이 모든 변화는 글로벌 외산 AI 시스템 없이 독자적인 개발로 이루어져, 앞으로 이어질 AI 패권 전쟁에서도 러시아는 강력한 경쟁력을 가질 수 있을 것입니다.

우리나라 또한 글로벌 서비스 대비 뛰어난 서비스를 가진 영역도 많지만, 열약한 부분도 분명히 있습니다. 러시아의 사례를 발판으로 삼아 한국 또한 독자 개발을 통해 더 강력한 경쟁력을 가질 수 있는 방향으로 갈 수 있으면 좋겠다는 생각이 커졌습니다. 오늘은 그런 이야기를 전해보려고 합니다.

1. 구글 없는 모스크바의 아침과 러시아의 IT 생태계

러시아가 실리콘밸리 표준을 버리고 독자 노선을 걷게 된 배경에는 생존을 향한 처절한 의지가 자리하고 있습니다.

러시아의 주요 BigTech 기업 <출처: 작가>

러시아가 글로벌 표준 대신 독자 노선을 택한 이유

시작은 서방의 경제 제재였습니다. 그로 인해 글로벌 빅테크 기업들이 하루아침에 서비스를 중단했을 때, 러시아 사회가 직면한 것은 단순한 불편함이 아닌 국가 시스템 전체가 마비될 가능성이었습니다. 러시아는 이 거대한 위기를 기회로 보고 국가 IT 기업에 투자했습니다. 외부 기술에 종속되는 것이 곧 데이터 주권과 국가 안보를 타인에게 양도하는 것임을 뼈저리게 실감한 이들은 자국만의 기술 요새를 쌓기 시작했습니다.

이제 모스크바에서 ‘글로벌 표준’은 더 이상 선망의 대상이 아닌 언제든 무기로 돌변할 수 있는 과거의 유물로 취급됩니다. 그 자리를 대신한 것은 러시아산 코드로 촘촘하게 짜인 내수용 소프트웨어들이며, 이들은 빠르게 현지인들의 삶 속에서 떼어낼 수 없는 유기적 결합체가 되었습니다. 얀덱스(Yandex), 카스퍼스키(Kaspersky) 등 이미 글로벌 수준의 앱이 모든 서비스를 제공하고 있습니다.

챗GPT 접근 금지가 불러온 ‘로컬 AI’의 반격

러시아의 AI <출처: 작가, gemini로 제작>

오픈AI의 챗GPT를 필두로 한 글로벌 생성형 AI 모델들이 러시아 IP를 차단하자, 러시아인들은 당황하는 대신 자신들의 언어와 문화적 맥락에 최적화된 로컬 AI로 시선을 돌렸습니다. 애초에 영어 중심 사고방식과 서구권의 윤리적 가이드라인이 투영된 글로벌 모델들은 러시아어의 복잡한 굴절과 슬라브 민족 특유의 정서를 담아내는 데 한계가 있었습니다.

반면, 러시아의 얀덱스, 스베르(Sber)가 개발한 모델들은 도스토옙스키와 톨스토이의 문장을 학습하고, 러시아인들만이 이해할 수 있는 역사적 상징과 은유를 이해합니다. 이는 기술적 소외를 극복하는 차원을 넘어 오히려 자국 문화에 가장 적합한 ‘맞춤형 지능’을 소유하게 되는 역설적인 기회를 제공했습니다. 접근 금지라는 장벽이 오히려 러시아만의 독창적인 AI 학습 데이터셋을 구축하는 강력한 동력이 된 셈입니다.

이제 이런 모델은 전 세계가 획일화된 AI 표준을 따라갈 때 러시아만이 가질 수 있는 독보적인 문화적 경쟁력이 되었습니다. 그 어떤 AI보다도 러시아어에 최적화되었으며, 구글 검색이 어려운 러시아 내부 사이트까지 모두 학습의 대상으로 삼아 전체 내용을 아우르는 AI 서비스가 러시아 자국민들에게 제공되고 있습니다.

우리가 모르는 러시아인들의 필수 앱 리스트

러시아 필수 앱 목록 <출처: RuStore>

이러한 변화는 스마트폰 홈 화면에서 가장 명확하게 드러납니다. 우리에게 익숙한 앱들은 없지만, 그들이 제공하는 기능은 로컬 슈퍼 앱들이 대신하고 있습니다. 물론 러시아에서도 구글이나 애플의 앱스토어를 이용할 수는 있습니다. 그러나 대부분은 루스토어(RuStore)라는 자국 앱스토어로 앱들을 관리합니다. 또, 러시아에서 필수로 통하는 앱들은 모두 전화번호 하나로 가입하고 관리할 수 있어, 사용 편의성에 있어서는 한국 앱들보다 더 뛰어난 측면도 있습니다.

러시아의 국민 메신저를 넘어 사회적 소통의 중심이 된 ‘VK’는 이제 SNS 그 이상의 기능을 수행합니다. 메일 서비스에서 시작한 플랫폼 '메일루(Mail.ru)'는 러시아 비즈니스의 혈관 역할을 수행합니다. ‘얀덱스 고(Yandex Go)’란 앱은 택시 호출, 음식 배달, 물류 배송, 심지어는 공과금 결제까지 하나의 앱 안에서 해결하는 거대한 플랫폼으로 성장했습니다. ‘텔레그램(Telegram)’ 역시 단순 메신저의 기능을 넘어 정부 행정 서비스와 금융 채널의 핵심 플랫폼으로 기능하며 러시아의 디지털 주권을 공고히 하고 있습니다.

모두 외부인에게는 낯설고 폐쇄적으로 보일지 모르지만, 이 내수용 앱들은 이미 현지인들의 일상을 완벽하게 지탱할 수 있을 만큼 성숙해졌습니다. 특히 이 모든 앱이 러시아 전화번호 하나로 인증할 수 있으니, 한국이나 미국에서 했던 인증 방식보다 더 편하다고 느끼고 있습니다.

2. 일상을 점령한 러시아표 AI와 핀테크

알리사(Alisa): 얀덱스가 탄생시킨 러시아판 ‘AI 페르소나’

Alisa AI <출처: yandex image>

러시아 AI의 정체성을 가장 상징적으로 보여주는 존재는 얀덱스의 AI 비서 ‘알리사(Alisa)’입니다. 실리콘밸리의 AI 비서들이 기계적이고 가치 중립적인 답변을 내놓는 데 주력하는 것과 달리, 알리사는 마치 살아있는 러시아인처럼 행동합니다. 때때로 고집스럽게 의견을 피력하거나, 러시아 특유의 냉소적인 유머를 섞어 대답하기도 하며 사용자에게 당혹감과 친밀감을 동시에 선사합니다. 이러한 '인격적 페르소나'는 러시아인들에게 단순한 비서 이상의 유대감을 주며 문화적 동질성을 확인시켜 줍니다.

또한, 알리사는 러시아 내부에 특화된 서비스와 이어집니다. 앱들과의 연계는 자연스러우며, 서비스 속도 역시 자국 내에서 월등히 뛰어납니다. 가격 또한 챗GPT나 제미나이(Gemini)에 대비하여 저렴합니다. 물론 한글 학습량이 절대적으로 부족해 제가 한글을 입력하면 알아듣지 못하는 경우가 많지만, 러시아 자국민만을 놓고 본다면 절대적인 강점을 지닌 AI 서비스임이 틀림없습니다.

미르 페이(Mir Pay): 제재 속에서 꽃피운 독자적 결제 시스템의 생존법

미르 페이 <출처: yandex image>

금융 영역에서의 자립은 더욱 극적입니다. 국제 결제망인 SWIFT에서 퇴출당했을 때, 러시아 경제가 순식간에 붕괴할 것이라는 서구권의 예측은 보기 좋게 빗나갔습니다. 러시아는 이미 수년 전부터 준비해 온 독자 결제 시스템 ‘미르(Mir)’를 전면에 내세웠습니다.

요즘 모스크바의 식당이나 지하철역에서 사람들은 비자나 마스터카드 대신 스마트폰의 '미르 페이(Mir Pay)'를 태그합니다. 외부의 금융 압박이 심해질수록 이 시스템은 더욱 정교하게 진화했고, 이제는 실물 카드 없이도 전국 어디서나 경제 활동이 가능한 수준에 이르렀습니다. 곧 미르 페이는 애플 페이, 삼성 페이 등 페이 시스템의 빈자리를 훌륭하게 극복했습니다. 나아가 사용자 편의성을 추구하여 ATM에서 돈을 찾을 때나, 지하철 탑승 시에는 안면 인식을 통한 활용까지도 제공하고 있습니다.

로버: 모스크바 길거리를 누비는 자율주행 배달 로봇

배달하는 로버 <출처: yandex image>

거리의 풍경 또한 이곳 러시아가 자율주행 기술의 최전선임을 보여줍니다. 모스크바 도심의 무릎 높이까지 차오른 눈길을 얀덱스의 배달 로봇 ‘로버’들이 묵묵히 헤쳐 나가는 모습은 보고 있으면 경이롭기까지 합니다. 영하 20도의 혹한과 빙판길이라는 가혹한 환경은 자율주행 알고리즘에게는 최악의 난제이지만, 러시아의 로봇들은 이를 극복해 냈습니다.

센서와 알고리즘의 결합체인 이 로봇들은 단순한 기술 과시용이 아니라, 만성적인 인력 부족과 가혹한 기후 조건을 해결하기 위한 실용적인 해답으로 자리 잡고 있습니다. 모스크바 시내에서 돌아다니는 이 조그마한 배달 로봇들은 제재와 테러 등의 위험으로 비싸진 노동력을 대신하고 있는 것입니다. 점점 학습이 나아짐에 따라 더 빠르고 정확하게 상품을 배달하고 있습니다.

3. 철의 장막 뒤에서 진화하는 소버린 AI의 실체

얀덱스 vs 기가챗: 러시아 AI의 양대 산맥, 그들의 기술적 차별점

러시아 최대 IT 기업과 그들의 AI 서비스 <출처: 작가>

러시아 소버린 AI의 내부를 들여다보면 얀덱스의 '얀덱스GPT'와 스베르의 '기가챗'이라는 두 거대 산맥이 존재합니다. 민간 기술력의 정점에 서 있는 얀덱스가 방대한 검색 데이터와 정교한 소비자 맞춤형 서비스에 강점을 보인다면, 국영 금융 그룹인 스베르는 국가적인 컴퓨팅 자원과 금융 인프라를 바탕으로 공공 영역의 지능화를 주도합니다.

이들은 서로 경쟁하면서도 외산 AI의 빈자리를 훌륭히 메우며 러시아 기술 생태계를 지탱하는 양대 기둥 역할을 수행합니다. 각기 다른 배경에서 탄생한 두 모델의 기술적 차별성은 러시아 AI 생태계를 더욱 풍성하게 만들고 있으며, 국가가 주도한 기술 발전이 민간의 창의성과 결합했을 때 나타나는 시너지를 잘 보여준다고 느껴집니다.

러시아가 오픈소스에 진심인 이유: 고립된 땅에서 혁신을 지속하는 법

러시아의 개발자들 <출처: 작가>

러시아가 기술적 고립 속에서도 혁신의 끈을 놓지 않는 비결은 바로 ‘오픈소스’에 대한 집요한 접근에 있습니다. 러시아의 개발자들은 전 세계의 오픈소스 프로젝트를 실시간으로 분석하고 흡수하여 자신들의 폐쇄된 네트워크 안에서 완전히 새로운 형태로 재조립합니다. 외부와의 공식적인 기술 협력 통로는 차단되었을지 몰라도, 공개된 코드를 해체하고 최적화하는 과정을 통해 전 세계의 지능을 자신들의 주권 아래로 끌어들이고 있는 것입니다.

이러한 전략은 고립된 환경이 어쩌면 외부 의존도를 낮추고 기술적 자생력을 키울 자양분이 될 수 있음을 시사합니다. 그들에게 오픈소스는 단순한 참조 도구가 아니라 생존 도구에 가깝습니다. 따라서 늘 오픈소스를 학습하고 개발하는 개발자라면 배워야 할 자세를 가지고 있습니다.

폐쇄적 개발 환경의 역설: 외부 의존도를 0%로 만드는 극한의 최적화 전략

더불어 하드웨어 수급의 한계는 러시아 개발자들에게 소프트웨어의 ‘극한 최적화’라는 과제를 안겨주었습니다. 최신 고성능 GPU를 마음껏 사용할 수 없는 환경은 오히려 독이 아닌 득이 되었습니다. 제한된 연산 자원 내에서 거대 언어 모델을 구동하기 위해 그들은 알고리즘의 군더더기를 깎아내고 메모리 효율을 극대화하는 사투를 벌였습니다. 그 결과 가벼우면서도 강력한 러시아만의 독자적 모델들이 탄생했습니다.

풍요로운 환경에서는 결코 시도하지 않았을 이 결핍의 연금술이 러시아 기술진의 실력을 상향 평준화시켰다고 보입니다. 외부 의존도를 0%로 수렴시키려는 이들의 노력은 결국 기술적 한계가 어떻게 창의적인 혁신으로 변모하는지를 보여주는 역설적인 장면을 연출합니다.

4. ‘AI 배제 시대’를 준비하는 우리의 자세

소버린 AI는 선택이 아닌 생존: 러시아 사례가 던지는 지정학적 메시지

러시아의 지정학적 위험 <출처: foreignpolicy>

모스크바 현지에서 몸소 느낀 소버린 AI는, 단순한 기술 자립을 넘어선 국가의 명운을 건 사투 그 자체였습니다. 그러다 보니 특정 국가나 거대 빅테크 기업에 기술의 주도권을 완전히 넘겨주는 것은 앞으로 발생할 어떤 위기 상황에서도 스스로를 방어할 수 있는 수단을 포기하는 것과 같다고 느껴졌습니다.

러시아는 비록 강제적인 방식이었지만, 자신들의 데이터와 지능을 스스로 통제함으로써 외부의 압력에 쉽게 굴하지 않을 디지털 요새를 구축하는 데 성공했습니다. 이 사례는 우리에게 AI 주권이 더 이상 선택의 문제가 아니라 국가 안보와 직결된 생존의 필수 조건임을 경고하고 있지는 않을까요?

글로벌 종속과 독자 기술 사이: 한국형 소버린 AI가 나아갈 방향

우리나라 역시 이제 글로벌 빅테크가 제공하는 편리함이라는 달콤한 유혹과 독자 기술 개발이라는 고단한 길 사이에서 냉정한 선택을 내려야 할 시점에 서 있습니다. 이제는 국가 차원에서 네이버나 카카오 같은 로컬 기업들이 수십 년간 쌓아온 데이터 영토를 보호하고, 한글을 비롯해 한국의 가치를 온전히 반영한 '한국형 소버린 AI'를 국가적 인프라로 육성해야 할 때입니다.

기술의 주권이 흔들릴 때 우리의 일상이 얼마나 쉽게 타인의 손에 의해 좌우될 수 있는지를 러시아란 나라는 명확히 보여줍니다. 모스크바의 매서운 눈바람을 뚫고 묵묵히 길을 찾아가는 배달 로봇처럼, 우리 역시 우리만의 기술적 해자를 구축하여 다가올 AI 패권 전쟁의 거센 파고를 당당히 넘어서야 합니다. 그것만이 디지털 대항해 시대에 대한민국이 자존감을 지키며 생존할 수 있는 유일한 길이기 때문입니다.

러시아 개발 생태계는 정부가 스스로 막은 것들도, 다른 국가에서 막은 것들도 많다 보니 늘 신기술에 대한 목마름이 넘쳐납니다. 그렇게 자체적으로 여러 세미나를 여는 등 기술 공부의 자리를 만들며 이를 키워 가고 있습니다. 저 또한 러시아에서 많은 것을 배우고 있습니다. 이 글을 읽고 있는 분들을 비롯해 한국 개발자에게 더 넓은 시야와 지식을 전파할 수 있을지 고민하며, 다시 새로운 것을 전달하러 찾아오겠습니다.

]]>

전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Opus 4.7, 무엇이 달라졌을까?
참고할 것: Claude Mythos 무단 접근 사건
적용해볼 것: 전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

1. 써볼 것:Claude Opus 4.7, 무엇이 달라졌을까?

Claude Opus 4.7은 앤트로픽이 4월 16일에 출시한 최신 플래그십 모델입니다. 출시 직후부터 코딩 커뮤니티에서 큰 관심을 받았는데요. 커서(Cursor)의 CEO는 자체 벤치마크에서 Opus 4.6 대비 12%p 향상됐다고 밝혔고, 데빈(Devin)의 CEO는 몇 시간 동안 일관되게 작동하며 어려운 문제를 끝까지 밀어붙인다고 평가했습니다. 다만 출시 이틀 만에 코딩은 확실히 좋아졌지만 그 외에는 오히려 퇴보했다는 반응이 나오기 시작했습니다.

무슨 문제를 해결해 주나요?

Opus 4.6까지의 Claude는 복잡한 코딩 작업을 맡기면 중간에 맥락을 잃거나, 여러 파일에 걸친 리팩토링에서 사람이 계속 확인해줘야 하는 경우가 있었습니다. 특히 길게 돌리는 에이전트 작업에서 안정성이 아쉽다는 피드백이 많았고요. Opus 4.7은 이 부분을 집중적으로 개선한 모델입니다. 앤트로픽은 이전에 밀착 감독이 필요했던 가장 어려운 코딩 작업을 이제 Opus 4.7에 맡길 수 있게 됐다고 설명합니다.

무엇이 달라졌나요?

코딩 벤치마크부터 보면 도약이 뚜렷합니다. 소프트웨어 엔지니어링 벤치마크 SWE-bench Pro에서 64.3%(Opus 4.6은 53.4%), SWE-bench Verified에서 87.6%(Opus 4.6은 80.8%)를 기록했고요. GPT-5.4나 제미나이 3.1 프로도 앞섰습니다. 코딩 외에도 몇 가지 주목할 변화가 있습니다.

비전 해상도 3배 향상: 이미지를 최대 2,576픽셀(약 375만 화소)까지 처리할 수 있게 됐습니다. 이전은 1,568픽셀(약 115만 화소)이었으니 3배 이상이고요. 차트, 코드 스크린샷, 디자인 시안 같은 걸 분석할 때 체감이 달라진다는 반응이 있습니다. 자율 보안 테스트 회사 XBOW의 비주얼 정확도 벤치마크에서 98.5%를 기록했는데, Opus 4.6은 54.5%였습니다.
추론 단계 xhigh 추가: 기존에 low, medium, high, max 4단계였는데, high와 max 사이에 xhigh가 추가됐습니다. Claude Code에서는 이 xhigh가 기본값으로 설정되어 있고요. 앤트로픽은 코딩과 에이전트 작업에는 high나 xhigh로 시작하라고 권장합니다.
/ultrareview 명령어: Claude Code에서 쓸 수 있는 코드 리뷰 전용 명령어입니다. 변경 사항을 읽고 버그나 설계 이슈를 찾아 리뷰하는 별도 세션을 띄우는 방식인데요. 프로와 맥스 사용자에게 3회 무료 제공됩니다.
파일 기반 장기 메모리 개선: 여러 세션에 걸쳐 작업할 때 메모를 기억하고 활용하는 능력이 좋아졌다고 합니다. 여러 세션에 걸친 작업이 안정적으로 이어진다는 테스터 보고가 있고요.
사이버 보안 장치 탑재: 지난주 소개한 Mythos의 사이버보안 능력이 너무 강력해서 일반 공개하지 않았는데, Opus 4.7에는 금지되거나 위험도 높은 사이버보안 요청을 자동으로 감지하고 차단하는 보안 기능이 처음으로 적용됐습니다.

토큰 소모와 범용 품질 논란

출시 후 커뮤니티 반응이 갈리고 있습니다. AI타임스는 성능 퇴보 논란이라는 기사를 냈고, 레딧에서는 Opus 4.7은 업그레이드가 아니라 심각한 퇴보라는 게시물이 추천 3200개, 댓글 800개를 넘기며 화제가 되기도 했습니다.

주요 논란 포인트를 정리하면 이렇습니다.

토큰 소모 증가: 새 토크나이저(텍스트를 토큰으로 쪼개는 방식)가 바뀌면서 같은 텍스트에 토큰이 1.0~1.35배 더 듭니다. 여기에 xhigh 기본 설정까지 겹치면, 실질 사용량이 Opus 4.6 대비 2배 가까이 빨라진다는 보고가 나오고 있습니다. 요금 자체는 Opus 4.6과 동일하지만(입력 100만 토큰당 $5, 출력 $25), 같은 작업에 토큰을 더 쓰니까 실질 비용은 올라가는 거죠.
긴 문맥 회수 능력 하락: 긴 대화에서 앞쪽 정보를 다시 꺼내오는 능력을 측정하는 벤치마크에서, 78.3%에서 32.2%로 크게 떨어졌다는 분석이 있습니다. 긴 문서 분석이나 대규모 코드 리뷰에서 체감이 나빠질 수 있다는 뜻이고요.
일반 대화 품질 체감 하락: 코딩 특화 쪽으로 굉장히 뾰족하다는 평가가 나왔고, 맥락이 덜 주어질 때 소통 능력이 떨어진다는 보고가 있습니다. 적응적 사고 기능에 대한 원성이 심해서 롤백된 이력도 있고요.

정리하면, 에이전트 코딩 작업에서는 확실한 업그레이드입니다. 여러 파일에 걸친 리팩토링, 장시간 자율 작업, 이미지 분석이 주 용도라면 바로 전환할 가치가 있고요. 반면 글쓰기, 긴 문서 분석, 일반 대화가 주 용도라면 Opus 4.6을 유지하는 게 나을 수 있습니다.

누구에게 좋을까요?

Claude Code나 커서에서 장시간 에이전트 코딩 작업을 자주 하는 개발자
여러 파일에 걸친 리팩토링, 코드 아키텍처 설계 같은 복잡한 코딩 작업이 필요한 팀
이미지 분석이 중요한 작업을 하는 사람 (차트, 스크린샷 분석 등)

추론 단계 조절이 핵심입니다. Claude Code에서 기본 xhigh를 쓰되, 단순 작업에서는 high로 내리면 토큰 소모를 줄일 수 있습니다. 앤트로픽 공식 블로그에서는 첫 메시지에 의도, 제약 조건, 완료 기준을 한 번에 넘기라고 권장하고 있고요. 대화를 여러 턴에 나눌수록 추론 비용이 붙어서 토큰을 더 쓰게 된다고 합니다. 가격은 Opus 4.6과 동일하게 입력 100만 토큰당 $5, 출력 $25이고, Claude.ai와 각종 클라우드 플랫폼에서 쓸 수 있습니다.

<출처: techcrunch>

2. 참고할 것:Claude Mythos 무단 접근 사건

앤트로픽이 최근 발표한 Claude Mythos는 사이버보안 취약점 탐지에 특화된 AI 모델입니다. 능력이 너무 강력해서 앤트로픽이 일반 공개하지 않기로 하고, 프로젝트 글래스윙이라는 이름으로 애플, 마이크로소프트 등 극소수 파트너에게만 제한 제공한 모델인데요. 그런데 4월 21일, Bloomberg와 TechCrunch가 보도한 소식에 따르면, Mythos 공개 당일 외부인이 무단으로 접근하는 일이 벌어졌습니다.

어떻게 뚫렸나요?

Bloomberg에 따르면, 미공개 AI 모델을 추적하는 디스코드 기반 그룹이 Mythos에 접근하는 데 성공했다고 합니다. 접근 경로가 두 가지였는데요. 하나는 앤트로픽의 서드파티 업체에 근무하는 사람의 접근 권한을 이용한 것이었고, 다른 하나는 앤트로픽이 기존 모델에 쓰던 URL 패턴을 유추해서 모델의 위치를 찾아낸 것이었다고 합니다. 정교한 해킹이 아니라 패턴 추측으로 접근에 성공한 거죠. 이 그룹은 공개 당일부터 Mythos를 사용해왔고, 실제 접근 증거로 Bloomberg에 사용 화면과 실시간 시연까지 보여줬다고 합니다. 다만 그룹 측은 새로운 모델을 가지고 놀아보는 것에 관심이 있었을 뿐, 피해를 주려는 의도는 아니었다고 밝혔죠.

왜 문제인가요?

앤트로픽은 조사 중이며 자사 시스템에 영향을 미친 증거는 없다고 밝혔습니다. 그룹의 의도도 악의적이지 않았다고 하고요. 하지만 이 사건이 문제가 되는 이유는 맥락에 있습니다. 앤트로픽은 Mythos의 사이버보안 능력이 악용될 경우 전 세계 인프라에 위협이 될 수 있다는 이유로, 1억 달러 상당의 크레딧과 함께 50개 이상의 파트너에게만 제한 제공하는 방식을 택했습니다. 안전하고 책임감 있는 AI를 내세우며 가장 신중한 배포 방식을 선택한 건데, 그 모델이 URL 패턴 추측으로 접근 가능했다는 건 보안 인프라가 모델의 능력을 따라가지 못하고 있다는 신호로 읽힐 수 있습니다.

무엇을 얻어가야 하나요?

이 사건은 프로덕트 메이커에게 두 가지를 짚어줍니다.

하나는, AI 모델의 성능만큼 접근 제어도 중요하다는 점입니다. Mythos는 모델 자체는 압도적이었지만, 그걸 담는 그릇은 그만큼 단단하지 못했습니다. AI 프로덕트를 만들 때 모델 성능에만 집중하기 쉬운데, 누가 어떤 경로로 접근할 수 있는지를 같은 수준으로 설계해야 한다는 걸 보여주는 사례입니다.

다른 하나는, 외부 협력사가 보안의 가장 약한 고리가 될 수 있다는 점입니다. 앤트로픽 자체 시스템이 뚫린 건 아닙니다. 서드파티 업체 직원의 권한과 URL 패턴 유추를 조합해서 접근한 건데, 결국 AI 모델을 외부에 제공하는 순간 파트너사의 보안 수준까지 내 보안의 범위가 되는 거죠. 모델을 잘 만드는 것만큼, 모델을 누구에게 어떻게 열어주는지를 설계하는 일이 중요해지고 있습니다.

<출처: 유튜브 Lenny's Podcast>

3. 적용해볼 것:전 메타·구글 임원이 말하는, PM 절반이 어려워지는 이유

Nikhyl Singhal은 메타와 구글을 거쳐, 크레딧 카르마의 CPO를 지낸 사람입니다. 지금은 시니어 프로덕트 리더 125명이 모인 Skip이라는 커뮤니티를 운영하면서, 프로덕트 업계에서 무슨 일이 벌어지고 있는지를 가장 가까이서 관찰하고 있는 사람 중 한 명이죠. Lenny's Podcast에 최근 출연해서 인터뷰한 내용이 프로덕트 커뮤니티에서 주목받고 있습니다.

무슨 문제를 해결하려 하나요?

AI 때문에 PM이 사라질 거라는 이야기는 요즘 흔하게 들립니다. 그런데 실제로 현장에서 무엇이 바뀌고 있는지를 구체적으로 설명해주는 사람은 많지 않죠. Singhal은 125명의 프로덕트 리더를 매달 만나면서 관찰한 내용을 토대로, 무엇이 달라졌고 누가 잘되고 있으며 누가 어려운지를 직설적으로 이야기합니다.

무엇이 달라졌다고 말하나요?

Singhal의 핵심 진단은 이렇습니다. 3년 전까지 PM의 하루는 정보를 정리하고 전달하는 일이 대부분이었다고요. 내 팀이 만든 내용을 상사가 이해하게 정리하고, 상사가 그 윗사람에게 다시 전달하는 구조. 그는 이걸 권한 없는 책임이라고 불렀는데, 직장 스트레스의 가장 큰 원인이라고 했습니다. 지금은 이 정보 전달자 역할이 빠르게 사라지고 있다고 합니다. 대신 남는 게 두 가지인데, 판단력과 직접 만드는 능력이라는 겁니다.

판단력이라는 게 추상적으로 들릴 수 있는데, Singhal은 이렇게 설명합니다. 변경 사항이 좋은지 나쁜지 평가하는 것, 100개 커스텀 버전 대신 지속 가능한 하나를 설계하는 것, 만들 가치가 있는지 출시할 가치가 있는지 결정하는 것. 테스트 비용이 거의 0에 가까워지면서 변화의 속도가 10배 이상 빨라지고 있고, 그 속도에서 무엇을 바꾸고 무엇을 지킬지 결정하는 게 판단력이라고요.

빌더 쪽은 더 직접적입니다. 그가 운영하는 125명 프로덕트 리더 모임에서 최근 쇼앤텔을 했는데, 모두 노트북을 열고 자기가 만든 걸 보여주면서 서로 더 나은 걸 만들었다고 경쟁하더라고요. 3년 전만 해도 프로덕트 리더 모임에서 코드를 보여주는 건 상상하기 어려운 일이었죠.

좋은 소식과 나쁜 소식

좋은 소식부터 하면, 빌더 성향의 PM은 역대 최고의 시기를 보내고 있다고 합니다. 보상은 사상 최고치이고, 제안도 그 어느 때보다 많고, 다음 직장으로 창업자나 CEO를 고려하는 사람도 늘고 있다고요. 실제로 Singhal의 커뮤니티에서 지난 12개월 동안 14명이 창업자로 전환했다고 합니다. 125명 중 14명이면 적지 않은 숫자죠.

나쁜 소식은, PM의 절반 정도가 빌더가 아닌 정보 전달자 유형이라는 겁니다. 이 사람들에게 Singhal은 꽤 직설적이었습니다. 만드는 걸 좋아하지 않는다면 위기에 처해 있다고요. 앞으로 12~24개월 안에 대규모 구조조정이 벌어질 거라는 게 그의 예측인데, 3만 명을 자르고 8천 명을 뽑는 상황이 벌어질 수 있고, 그 8천 명은 전부 AI를 기본으로 쓰는 인재가 될 거라고 했습니다.

이력서의 회사 이름보다 지금 일하는 방식을 본다고 합니다

Singhal이 강조한 또 다른 변화가 있습니다. 이전에는 이력서에 메타, 구글 같은 회사 이름이 있으면 그것만으로 실력을 인정받을 수 있었지만 지금은 인터뷰에서 어떤 도구를 쓰는지, 판단을 어떻게 내리는지를 묻는다고요. 이전 회사에서 뭘 출시했는가보다, 지금 어떻게 일하고 있는가가 더 중요해졌다는 겁니다. 흥미로운 관찰은, 정보 전달 중심의 일하는 방식에 가장 능숙했던 사람이 오히려 전환이 가장 어렵다는 부분입니다. 지금 방식으로도 잘하고 있으니까 바꿀 이유를 못 느끼는 건데, Singhal은 이 지점이 함정이라고 하죠.

그래서 어떻게 해야 하나요?

Singhal의 핵심 조언은 하나입니다. 만드는 일에서 기쁨을 찾아라. 문장 자체는 추상적으로 들리겠지만, 그가 말하는 맥락은 구체적입니다.

AI 도구로 뭔가를 직접 만들어보면, 어느 순간 재미를 느끼는 첫 번째 순간이 온다고 합니다. 집안 조명을 제어하는 앱을 만들었거나, 자기 업무용 비서 앱을 만들었거나, 파트너와 함께 쓰는 도구를 만들었거나. 내용은 사람마다 다르지만, 그 순간이 오면 두려움에서 기쁨으로 전환이 일어난다고요. 그리고 기쁨은 번아웃의 가장 강력한 해독제라고 했습니다.

동시에 그는 이 혼란이 영원하지는 않을 거라고도 했습니다. 인터넷이 등장했을 때도 기존 PM의 일하는 방식이 완전히 뒤집혔지만, 몇 년 지나니 새로운 기준이 잡혔죠. 지금도 2년 정도면 어느 정도 안정될 거라는 게 그의 관측입니다. 다만 그 2년이 결정적이라는 게 메시지죠. 업계가 안정됐을 때 살아남아 있으려면, 지금 변화해야 한다고요.

어렵죠. 배워야 할 건 매일 늘어나고, 따라가야 할 속도는 점점 빨라지는데, 정작 내가 지금 뭘 해야 하는지는 더 흐릿해지는 느낌이 들 때가 있습니다. Singhal의 이야기를 정리하면서도, 이걸 읽는 분들이 또 하나의 압박으로 받아들이면 어쩌나 하는 걱정이 됩니다. 그래서 이 말을 남기고 싶습니다. 지금 당장 커리어를 재설계하거나, 뭔가를 완성할 필요는 없습니다. 다만 자기 일에서 반복되는 작업 하나를 골라서, AI 도구로 바꿔보는 건 해볼 만하죠. 회의 요약이든, 데이터 정리든, 간단한 자동화든. 변화가 두렵지 않아지는 건, 공부를 많이 해서가 아니라 직접 만들어본 경험이 한 번이라도 있기 때문인 것 같습니다.

적용해볼 질문

내 하루 중 정보를 정리하고 전달하는 데 쓰는 시간과, 직접 무언가를 만들거나 판단하는 데 쓰는 시간의 비율은 어떤가?
AI 도구로 무언가를 직접 만들어본 경험 중, 재미를 느낀 순간이 있었는가? 없었다면, 그 첫 경험을 만들 수 있는 가장 작은 프로젝트는 무엇인가?
지금 나는 스스로 현재 어떻게 일하는지를 설명할 수 있는가?

실행해볼 수 있는 것

이번 주 회의 중 하나를 골라서, 그 회의에서 정리·전달하는 데 쓰는 시간을 AI 도구로 자동화할 수 있는지 실험해보기. 상태 보고서, 이슈 정리, 회의 요약 같은 것부터 시작해보기.
가장 작은 빌드 프로젝트 하나를 정해서, 이번 주 안에 작동하는 결과물을 만들어보기. 업무용이든 개인용이든, 동작하는 무언가를 만드는 경험 자체가 중요합니다.
자기 역할에서 판단이 필요한 순간을 명시적으로 기록해보기. 일주일간 어떤 결정을 내렸는지, 그 결정이 왜 AI에게 맡길 수 없는 것이었는지 정리해보기 (이를 바탕으로 내 역할의 핵심이 어디에 있는지 생각해보기)

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

왜 지금 다시 클로드 코드인가: 클코나잇 시즌 2

클로드 코드가 처음 등장했을 때를 기억하시나요? “이게 진짜 되네?” 하고 놀라워하던 순간이 있었죠. 이제는 개발자뿐만 아니라, PM, 기획자, 마케터까지 클로드 코드를 활용해 문제를 직접 해결하고 있습니다. 팀 단위로 도입하거나, 조직 전체의 워크플로우를 바꾼 사례도 하나둘 늘어나고 있고요. 그 흐름을 보며 자연스럽게 한 가지 질문이 떠올랐습니다.

“현업에서 이 도구를 매일 써온 사람들은, 실제로 어떻게 활용하고 있을까?”

잘 작동했던 경험뿐 아니라, 잘 되다가 막혔던 순간, 여러 번 시도했지만 기대만큼 풀리지 않았던 경험, 그럼에도 다시 방법을 찾아 나섰던 과정까지. 거창하게 정리된 성공담보다, 실사용자들의 솔직하고 생생한 이야기를 듣고 싶었습니다. 그래서 요즘IT는 ‘클로드 코드 나잇(일명 클코나잇)’을 기획했고, 시즌 1을 통해 그 이야기들을 직접 들어 볼 수 있었습니다.

그리고 2026년 클코나잇 시즌 2를 준비하며, 이번 여정을 함께 만들어갈 발표자분들을 찾고 있습니다.

클코나잇 시즌 1, 어떤 자리였나요?

2025년 10월부터 12월까지 총 3회에 걸쳐, 진행한 클코나잇 1은 현업에서 직접 부딪히며 시행착오를 겪은 사람들이 날것의 경험을 나누는 자리였는데요.

1회 ‘실제 사례 공유회’: 스타트업 자동화 도전기, 서브에이전트 활용법, 컨텍스트 엔지니어링으로 바이브 코딩을 표준화한 사례, 엔터프라이즈 웹앱 구축기까지 다양한 이야기가 이어졌습니다. 클로드 코드와 씨름하며 각자의 방식으로 문제를 풀어낸 개발자들의 생생한 경험이 오간 밤이었습니다.
2회 ‘딥다이브’: DB 마이그레이션 자동화, AI 에이전트 간 대화 설계, 실시간 시스템 장애를 클로드 코드와 함께 3일 만에 극복한 사례 등 한층 더 깊고 구체적인 기술 경험담을 다뤘습니다.
3회 ‘The 비개발자들’: “AI는 개발자만의 도구”라는 인식을 뒤집는 자리였습니다. 코딩을 몰라도 클로드 코드로 월 300만 원 규모의 외주 개발을 시작한 직장인, 75편의 영상을 9개 국어로 번역하는 과정에서 직접 웹앱을 만든 영상 PD, 그리고 PM이 직접 크롬 익스텐션을 만든 이야기까지, 비개발자들의 실전 경험이 이어졌습니다.
번외: 추가로 번외 세션에서는 클로드 코드 토큰 사용량으로 전 세계 1위를 찍은 개발자,박진형 님의 생생한 경험담도 들어봤습니다.

클코나잇에서 나눈 이야기들은 이후 『클로드 코드로 일하기: 10인 실제 사례집』으로 엮여 판매됐으며, 관련 콘텐츠 또한 평균 조회수 1만 뷰를 넘기며 많은 관심을 받았습니다.

지금, 클로드 코드를 둘러싼 흐름은 또 한 번 달라지고 있습니다

올해 초에는 비개발자도 에이전트 방식으로 업무를 자동화할 수 있는 Claude Cowork가 출시됐고, 4월에는 대화 한 줄만으로 프로토타입과 슬라이드를 만드는 Claude Design도 등장했습니다. 코드에서 문서, 디자인까지. 이제 클로드가 조직 안에서 다루는 업무의 범위는 더 빠르게 넓어지고 있습니다.

클로드 디자인 <출처: 클로드, 작가 캡처>

AI Business Weekly에 따르면, Fortune 100 기업의 70%가 이미 클로드를 도입했고, 연간 10만 달러 이상을 지출하는 기업 고객 수도 전년 대비 7배 증가했습니다. 클로드 코드는 이제 개인의 생산성을 높이는 도구를 넘어, 조직 전체의 워크플로우를 바꾸는 도구로 자리 잡아가고 있는 셈이죠.

그렇다면 지금 이 도구를 가장 깊이 활용하고 있는 사람들은, 실제로 어떤 방식으로 일하고 있을까요?

클코나잇 시즌 2는 바로 그 이야기를 직접 들어보는 자리입니다.

시즌 2에서 기대하는 이야기

직접 써보며 막히기도 했고, 다시 시도해보기도 했고, 그 과정 끝에 자신만의 활용 방식을 만들어낸 사람들의 경험을 기다립니다. 개인의 시행착오부터 팀 차원의 도입과 정착 과정까지, 이미 정리된 성공 사례뿐 아니라 지금도 진행 중인 실험과 고민 역시 모두 환영합니다!

개인 참여는 물론, 팀 단위(2인 이상)로도 신청하실 수 있습니다.

➡️ 발표자 신청하기

발표자에겐 어떤 혜택이 있나요?

요즘IT 기사·뉴스레터·SNS 공식 소개됩니다. (개인 블로그·링크드인 링크 포함)
발표 내용은 요즘IT 공식 유튜브 영상으로 기록됩니다.
발표 내용은 사례집(PDF)으로 엮여 판매될 수 있으며, 판매 수익은 배분됩니다.
요즘IT Speaker 공식 배지(PNG/SVG)를 제공합니다.
후속 인터뷰나 다음 세미나로 이어질 기회도 열려 있습니다.

신청 안내

발표 길이: 15분 내외
진행 방식: 온라인(Zoom)
세미나 일정: 5월 중순 예정 (추후 협의)
신청 방법: 신청 링크를 통해 발표 주제와 간단한 소개를 제출해주세요. 개인 또는 팀(2인 이상) 단위 모두 신청 가능합니다.
신청 마감: 4월 28일(화) 23:59
진행 절차: 신청서 접수 → 서류 검토 → 개별 온라인 인터뷰 → 발표자 선정 및 안내
최종 결과 안내: 5월 6일(수) 개별 연락

AI와 함께 일하는 여정에는 아직 정답이 없다고 생각합니다. 클로드 코드와 함께한 시행착오의 이야기라면 그 자체로 충분합니다.

너무 고민하지 마시고, 지금 바로 지원해보세요!

➡️클코나잇 2 발표자 신청하기

]]>

막힐 때마다 직접 만들었더니, AI 풀스택 기업이 된 사연

이 글은 엘리스그룹과 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

왜, 지금 AI 모델보다 인프라일까?

최근 AI 시장에서 일어나고 있는 변화가 있습니다. 바로 경쟁의 축이 '모델'에서 '인프라'로 이동하고 있다는 겁니다. 여기서 핵심은 ‘AI 에이전트’입니다. 에이전트는 단순 챗봇과 달리, 복잡한 태스크를 스스로 분해하고, 여러 툴을 호출하고, 결과를 추론하여 다음 단계를 결정합니다.

문제는 이 과정에서 토큰 소비량이 기하급수적으로 증가한다는 건데요. AI 풀스택 기업 엘리스에 따르면, 단순 챗봇에 비해 5~30배 정도, 추론이 깊어지면 최대 83배까지도 늘어납니다. 여기서 중요한 변화가 생깁니다. AI 개발 초기엔 비용의 대부분이 모델을 학습시키는 데 들었습니다. 방대한 데이터를 모아 GPU로 훈련시키는 과정이죠. 그런데 에이전트가 확산되면서, 이제는 그 훈련된 모델을 매일 작동시켜 답을 만들어내는 비용, 즉 추론 비용(Inference Cost)이 더 커졌습니다.

쉽게 말하면 AI를 만드는 비용보다, AI를 매일 쓰는 비용이 더 많이 드는 시대가 된 거죠. 그러다 보니 GPU를 얼마나 효율적으로 확보하고, 운영하느냐가 곧 기업의 경쟁력이 됩니다.

그러나 이런 인프라 문제를 두고, 쉽게 결정을 내리긴 어렵습니다. 해외 클라우드를 쓰자니 비용과 데이터 주권이 걸리고, 직접 구축하자니 초기 자본과 운영 부담이 따릅니다. 어떤 인프라를 써야 하는지, 보안 조건을 충족하면서 GPU를 쓸 수 있는 구조가 있는지, 무엇보다 PoC(Proof of Concept)에서 전사 확장으로 어떻게 넘어갈지 등이 현실적으로 다가옵니다.

그래서 요즘IT는 이 흐름을 가장 가까이서 지켜본 팀을 만나보기로 했습니다. 바로 GPU 클라우드를 직접 구축하고 운영해 온 AI 풀스택 기업, 엘리스입니다. 학습에서 추론으로 수요가 이동하는 변화를 현장에서 체감해 왔고, 국내 CSP 최초로 GPU Spot 요금제를 출시한 것도 그 흐름의 일부였고요.

이들이 직접 겪어온 이야기를 듣기 위해, 엘리스 박정국 CTO와 김시완 클라우드 전략이사를 만나 인터뷰를 진행했습니다. 그리고 실전에서 기업들의 AX 전환이 막히는 이유와 체크리스트도 함께 정리해 봤습니다.

요즘IT 단어 사전
AI 풀스택 기업이란? 소프트웨어 개발에서 풀스택 개발자가 프론트엔드부터 백엔드까지 전 영역을 다루듯, AI 풀스택 기업은 인프라, 플랫폼, 모델, 서비스까지 전 레이어를 직접 운영하는 회사를 말합니다. 이번 글에서는 엘리스그룹의 비전을 설명하는 핵심 키워드로 등장합니다.

[인터뷰] 에이전트 시대, GPU 수요는 어떻게 달라지고 있나

에이전트 시대를 살아가는 지금, GPU 수요 패턴도 빠르게 바뀌고 있습니다. 학습 중심에서 추론 중심으로, IT 기업에서 전통 기업으로 말이죠. 그렇다면 실제 현장에서는 어떤 변화가 일어나고 있을까요?

엘리스 박정국 CTO(왼쪽), 김시완 클라우드 전략이사(오른쪽) <출처: 요즘IT>

Q. 1년 전과 비교했을 때, 기업이 GPU를 활용하려는 수요가 어떻게 달라지고 있나요? 그 변화의 기준으로는 무엇이 작용할까요?

김시완 클라우드 전략이사: 예전에는 GPU를 학습용으로 문의하시는 분들이 많았는데, 요즘에는 모델을 직접 올려서 추론용으로 써보고 싶어 하는 수요가 많이 늘었습니다. 2년 전 온디맨드 서비스를 처음 내놨을 때와 비교하면, GPU를 직접 쓰는 분들이 훨씬 많아졌고요. 확실히 대중화되고 있다는 느낌이 많이 듭니다.

박정국 CTO: GPU를 직접 구축해보겠다고 시작하면, 생각보다 쉽지 않다고 다들 느끼십니다. GPU는 다루기 어렵고, 전기도 많이 먹고, 초기 자본도 크기 때문이죠. 시행착오로 낭비하는 시간도 결국 다 비용이고요. 만약 2년을 쓴다고 가정했을 때, 직접 사서 운영하는 비용과 클라우드 서비스를 쓰는 비용을 TCO(Total Cost of Ownership, 초기 구매 비용뿐 아니라 운영·유지보수·인력까지 포함한 총소유비용) 기준으로 비교해 보시는 걸 추천합니다.

Q. 기업의 GPU 교체 주기와 요금제 부담도 달라지고 있는데요. 실제 GPU를 공급하는 입장에서 어떻게 대응하고 있나요?

김시완 클라우드 전략이사: 요즘은 새 AI 모델이 출시되어도 일주일이 지나면 바로 구식이 되는 시대입니다. GPU도 마찬가지예요. 빌딩형 데이터센터를 직접 구축하면 3~5년이 걸리는데, 완공 시점에 이미 설계가 구식이 되는 경우가 있습니다. 보안이나 데이터 주권 때문에 자체 구축이 꼭 필요하다면, PMDC처럼 3개월 안에 구축 가능한 모듈형 방식이 현실적인 대안이 될 수 있어요.

엘리스의 AI PMDC(Portable Modular Data Center) 구축 타임라인 <출처: 엘리스>

박정국 CTO: GPU 사업을 하다 보면 항상 발생하는 패턴이 있습니다. 100% 가동이 사실상 불가능하다는 건데요. 학습을 돌리다가도 데이터 준비를 하는 동안 GPU가 쉬게 되거든요. 저희는 그 유휴 시간이 짧게 쓰는 워크로드 패턴과 맞아떨어진다는 걸 발견했습니다. 그래서 유휴 자원을 수요에 맞게 제공하자는 게 스팟 요금제의 출발점이었죠.

Q. 그렇다면 기업은 어떤 요금제를 선택하는 게 유리할까요? 또 아직 인프라를 갖추지 못한 기업이라면 무엇부터 시작해야 할까요?

박정국 CTO: 요금제는 워크로드 성격에 따라 다릅니다. 장기간 안정적으로 GPU를 써야 한다면 약정형(Reserved)이 맞고, 개발이나 PoC처럼 필요할 때 바로 쓰고 싶다면 온디맨드(On-demand)가 적합합니다. 실험, 배치 학습, 에이전트 추론 테스트처럼 중간에 잠깐 끊겨도 괜찮은 워크로드라면 스팟(Spot)이 가장 효율적이고요. 세 가지 모두 같은 인프라에서 같은 가상화 솔루션으로 제공되기 때문에 품질의 차이는 없고, 정책적인 부분만 다릅니다.

또 아직 인프라를 갖추지 못한 기업이라면, 먼저 2년 치 TCO(Total Cost of Ownership, 초기 구매 비용뿐 아니라 운영·유지보수·인력까지 포함한 총소유비용)를 계산해 보시길 권장합니다. 클라우드 서비스로 시작해서 워크로드를 파악한 다음, 필요하면 확장하는 방식이 현실적인데요. 보안이나 데이터 주권 때문에 자체 구축이 필요하다면, AI PMDC를 고객사 현장에 연결하는 하이브리드 방식도 함께 고려해 볼 수 있습니다.

클라우드 요금제 비교표 <출처: 엘리스>

인터뷰에 나온 것처럼, GPU 인프라 도입은 단순히 하드웨어를 사는 문제가 아닙니다. 비용 구조를 어떻게 설계하느냐, 보안을 어디서 통제하느냐, 어떤 요금제를 조합하느냐까지 함께 고민해야 하죠. 엘리스도 이 답을 찾기까지는 여러 시행착오를 거쳤다고 합니다. 이제 교육 플랫폼이 어쩌다 데이터센터까지 직접 만들게 됐는지, 그 과정이 어떻게 고객사의 AX 전환을 돕는 경험으로 이어졌는지 따라가 보겠습니다.

왜 교육 플랫폼이 데이터센터까지 만들게 됐을까?

많은 분들이 엘리스를 교육 플랫폼으로 알고 계실 텐데요. 엘리스는 원래 코딩 교육 플랫폼으로 시작했습니다. 그래서 학생들이 브라우저에서 바로 코드를 실행할 수 있어야 했고, 그러려면 컨테이너 기반 클라우드 실습 환경이 필요했습니다. 처음엔 AWS나 GCP를 썼지만, 이후 AI 교육에 대한 수요가 늘면서 GPU가 필요해졌습니다. 그런데 당시 대형 클라우드 회사들의 GPU 서비스가 AI 워크로드에 맞게 최적화되어 있지 않았다고 합니다.

<출처: 엘리스>

그래서 "빌리는 것보다 직접 만드는 게 낫겠다"라는 결론을 내린 게 2021년이었습니다. 그때부터 엘리스는 GPU 클라우드를 직접 구축하기 시작했고, 2022년에는 컨테이너 한 대에 A100 GPU를 넣은 첫 번째 모듈형 데이터센터(AI PMDC)를 만들었습니다.

엘리스 김재원 대표는 기자간담회를 통해 "단순히 1~2년 내에 갑자기 클라우드를 하겠다고 선언한 게 아니라, 10년 전부터 복잡한 교육 환경의 실습 클라우드를 제공하다가 직접 GPU를 구축하게 된 것"이라고 설명했는데요.

엘리스그룹 김재원 대표 <출처: 엘리스>

그렇게 GPU 클라우드를 운영하기 시작하니 다음 문제가 보였습니다. 고객사 교육을 진행하다 보니, 기업들이 AI를 실제 업무에 쓰려면 내부 문서를 AI가 읽을 수 있어야 한다는 걸 알게 된 것이죠. 범용 AI 모델은 복잡한 표 구조가 들어간 계약서, 한글로 작성된 보고서, 기업마다 다른 양식의 PDF 앞에서 자주 막혔습니다. 그 다음엔 보안 문제도 뒤따랐습니다. 고객사 내부 데이터를 외부 서버로 보내는 걸 허용하지 않는 기업들이 많았고, 금융·의료·공공기관은 법적 제약까지 있었습니다.

결국 이런 문제들도 직접 풀 수밖에 없었습니다. 문서 문제는 특화 모델을 개발해 대응하고, 보안 문제는 고객사 데이터센터와 엘리스 인프라를 직접 연결하는 하이브리드 구조를 만드는 방식으로요. 막힐 때마다 직접 만드는 쪽을 택하다 보니, 어느새 인프라부터 모델까지 전 레이어를 직접 운영하는 구조가 된 겁니다.

엘리스 AI 풀스택 구조

서비스: AI 헬피챗(생성형 AI 솔루션), AX 교육
플랫폼: 엘리스LXP(AI 교육 실습 플랫폼)
모델: Helpy Vision(문서·표 구조 분석 특화 AI), Helpy Pro
인프라: AI PMDC(모듈형 AI 데이터센터, 하드웨어), ECI(GPU·스토리지·네트워크를 가상화해 클라우드 서비스로 제공하는 소프트웨어 스택)

AX 전환, 왜 실전에선 어려울까?

이 과정에서 엘리스는 수백 곳의 고객사가 AI 전환을 추진하며, 공통으로 막히는 지점들을 반복해서 목격하게 됩니다. 그 문제들은 엘리스가 먼저 겪어온 것들이기도 했죠. 그래서 실전에서 왜 어려운지, 그 해결 방법이 무엇인지도 제안했습니다.

CHECK 1. 우리 내부 데이터를 AI가 읽을 수 있는가?

AI 도입의 첫 번째 관문은 모델 선택이 아니라, 데이터 준비입니다. 범용 AI 모델은 한글 PDF, 복잡한 표 구조가 들어간 보고서, 기업마다 다른 양식의 문서를 제대로 처리하지 못하는 경우가 많습니다. 글로벌 모델이 한국 기업 특유의 문서 포맷을 학습하지 않았기 때문이죠.

이때 확인 방법은 간단합니다. 실제로 쓰려는 AI 모델에 우리의 핵심 문서를 넣어보는 겁니다. 표가 많은 계약서, 한글로 작성된 내부 보고서, 그룹웨어에서 뽑은 PDF 등 실제 업무에서 가장 자주 쓰는 포맷 10개 정도를 테스트해 보면 어디서 막히는지 바로 나옵니다. 여기서 못 읽는다면 선택지는 두 가지로 나뉩니다. 해당 포맷에 맞는 전처리 파이프라인을 별도로 구축하거나, 그 포맷에 특화된 모델을 따로 검토할 수 있습니다.

복잡한 문서를 파싱하는 엘리스의 ‘Helpy Vision’ 모델 <출처: 엘리스>

CHECK 2. 데이터를 어디서 처리할 것인가?

기업 내부 데이터를 외부 AI API로 보내는 것에 대한 부담은 업종을 가리지 않습니다. 금융·의료·공공기관의 경우 법적 제약이 있고, 일반 기업도 영업 기밀·인사 정보는 외부로 보내기 어렵습니다. 그래서 외부 AI API를 쓸지, 자체 인프라에서 돌릴지는 기술 문제이기 전에, 보안과 법적 요건의 문제인데요. 도입 전, 아래 세 가지를 먼저 확인해야 합니다.

첫째, 우리 업종에 데이터 처리 위치에 대한 법적 제약이 있나요?
둘째, AI에 입력할 데이터에 개인정보·영업 기밀이 포함되나요?
셋째, 외부 유출 시 어떤 리스크가 발생하나요?

세 질문에 하나라도 "그렇다"가 나오면 외부 API 단독 방식은 재검토가 필요합니다. 구조적으로 보면 외부 API, 온프레미스, 하이브리드 세 가지 선택지가 있는데요. 외부 API는 빠르게 시작할 수 있지만 데이터 통제권이 약하고, 온프레미스는 통제권이 높지만 초기 비용과 운영 부담이 큽니다. 그래서 하이브리드 방식은 민감 데이터는 내부에서, 나머지는 외부 클라우드에서 처리하기 때문에, 절충점이 될 수 있습니다.

CHECK 3. PoC 이후 전사 확장을 처음부터 설계했는가?

사실 기업에서 PoC를 성공해도 전사 확장에는 실패하는 경우가 굉장히 많습니다. 가장 흔한 원인은 두 가지인데요.

첫째, 의사결정권자가 AI로 무엇을 할 수 있는지 모르면 예산 승인이 나지 않습니다. PoC 결과를 나중에 보고하는 방식으로는 부족합니다. 기획 단계부터 의사결정권자가 함께 참여해서 어떤 문제를 어떻게 풀 것인지를 같이 설계해야 이후 확장이 수월해집니다.

둘째, 전사 확장을 담당할 내부 AI 챔피언이 없으면 PoC 성공이 그 팀에서 멈춥니다. AI 리터러시가 조직 전체에 고르게 없으면 확산 속도가 느려지기 때문입니다. PoC를 시작할 때부터 "이게 성공하면 다음 팀으로 어떻게 넘길 것인가"를 미리 설계해두고, 그 전파를 담당할 사람을 지정해두는 것이 전제 조건입니다.

엘리스가 AX 교육에서 임원 교육을 가장 먼저 진행하는 이유도 여기 있습니다. 엘리스 김재원 대표는 "임원들이 교육을 듣고 나온 아이디어들이 프로젝트 개발로 이어지고, 그것이 다시 인프라를 활용하는 방향으로 가고 있다"고 설명했습니다.

고객사, 리더 수준별 맞춤형 커리큘럼 <출처: 엘리스>

CHECK 4. GPU를 직접 살 것인가, 빌릴 것인가?

기업에서 GPU가 필요한 단계가 되면 이 질문이 반드시 나올 겁니다. 직접 구매가 저렴하게 느껴질 수도 있지만, 실제 TCO를 계산해보면 다른 경우가 많습니다. TCO(Total Cost of Ownership)는 단순 구매가가 아닌 운영 기간 전체에 걸친 총 소유 비용인데요. GPU의 경우 하드웨어 구매비 외에도 전기, 냉각, 네트워크 인프라 구축비, 운영 인력, 장애 대응 비용, 그리고 처음에 필연적으로 발생하는 시행착오 비용까지 포함해서 계산해야 합니다.

엘리스의 경우, GPU 클라우드를 직접 구축하고 운영하면서 이 비용 구조를 누구보다 잘 알게 됐는데요. 그래서 가격 정책을 잡을 때, 2년 치 TCO 기준으로 직접 구매보다 클라우드가 더 유리하게끔 포지셔닝했습니다.

결국 AX 전환은 기술이 아닌 설계의 문제

지금까지 살펴본 것과 같이 AI 도입에 실패하는 기업들을 보면 공통점이 있습니다. 바로 기술보다는 설계의 문제라는 건데요. 무엇을, 어떤 순서로, 어떤 구조로 할지를 미리 설계하지 않은 채 시작했기 때문입니다. 이렇게 되면 좋은 AI 모델을 골랐는데 우리 문서를 못 읽고, 에이전트를 만들었는데 보안 검토에서 막히고, PoC는 됐는데 전사 확장이 안 되는 상황이 벌어집니다.

엘리스가 10년간 겪어온 것도 같은 문제였습니다. 클라우드가 필요할 때 어떻게 구축할지, GPU가 필요할 때 빌릴지 직접 만들지, 고객사 데이터가 외부로 나가면 안 될 때 어떤 구조로 풀지, 매번 설계의 문제였지만, 직접 답을 찾아갔습니다.

만약 우리 팀이 현재 AX 전환을 고민하고 있다면, 이번 글에서 다룬 네 가지 질문에 먼저 답해보시길 바랍니다. 어떤 도구를 쓸지보다, 어떤 구조로 시작할지를 먼저 그려보는 일이 더 중요합니다. 또 우리 조직에 맞는 전략을 아직 찾지 못했다면, 이미 그 과정을 경험한 곳의 도움을 받는 것도 좋은 방법입니다. 여러분의 조직은 지금 어느 단계에 와 있나요?

AI 인프라부터 교육까지, AX 전환을 어디서부터 시작할지 고민이라면
엘리스와 시작해 보세요.

[엘리스에 문의하기]

]]>

2개의 스쿼드를 AI와 함께 이끌어봤습니다

이번 글에서는 글로벌 알람 앱 ‘알라미’를 서비스하는 딜라이트룸이 2개의 스쿼드를 각각 주니어 AI에게 맡긴 과정에 대해 소개합니다.

올해 들어 제품 내에서 살펴야 할 피처의 넓이와 깊이가 모두 깊어졌고, 인수한 제품의 특성상 우리가 아직 모르는 동작도 훨씬 많아졌습니다. 그 와중에 2개의 스쿼드의 PO 역할을 담당하려다 보니, 물리적으로 혼자 감당할 수 있는 범위를 이미 넘어선 상황이었죠. 그래서 두 주니어 AI를 통해 빈자리를 단단하게 채워보려고 했습니다. 그 과정을 지금부터 소개하겠습니다.

Devin은 코드베이스를 꿰뚫는 주니어 Dev입니다.
Claude는 제품 로드맵 구축부터 백로그 배포 이후의 후속 기획까지 함께 뛰는 주니어 PO입니다.

Devin: 코드 및 데이터베이스를 꿰뚫는 주니어 Dev

Devin에게 부여하는 역할은 크게 네 가지입니다.

1) Reader

“이 기능 지금 어떻게 동작해?” 하고 물으면 코드를 읽고 플로우를 정리해 주고, 관련 수치까지 뽑아줍니다. 복잡한 코드를 대신 읽고 구조화해 주기 때문에, 기획 단계에서 많은 리소스를 아낄 수 있습니다. 인수한 제품이라 우리가 모르는 동작이 훨씬 많은 환경에서는 특히 유용합니다.

2) Debugger

문제가 터졌을 때 원인을 함께 디깅 합니다. 영향을 줄 수 있는 코드 내 다양한 변인을 같이 검토해 주고, 과거 커밋 히스토리까지 알고 있기 때문에 “이전에는 어떻게 동작했는지”도 추적할 수 있습니다.

3) Developer

간단한 코드 수정은 직접 해주기도 합니다. 물론 더 대단한 개발도 해주기야 하겠지만, 아직은 그 결과물을 온전히 신뢰하기 어려운 단계입니다. (그가 책임을 지지는 못하기 때문에…) 운영상의 불편함을 한 번의 코딩으로 갈음해 주는 역할도 해주곤 합니다. 사실 이 역할을 더 많이 활용해야 하는데, 이번 분기에는 미진했네요. 다음 분기를 기약해 봅니다. 아무래도 백로그가 잔뜩 쌓여있을 때 더 빛을 발할 것 같네요.

4) DA

예상 임팩트 계산, 코호트 분석, 교차 분석도 수행합니다. 매출 데이터만 해도 웹 결제냐 앱 결제냐에 따라 참고해야 할 소스가 다르고, 유저 액티비티 값 역시 서버값과 클라이언트값을 잘 교차해서 써야 합니다. Devin은 AMP, Stripe, Qonversion 등 여러 데이터 소스를 넘나들며 이걸 해주고, taxonomy도 이미 파악하고 있어서 매번 설명할 필요가 없습니다.

또한 때로는 무의미해 보일 수 있을 정도로 세세한 데이터 분석을 해보고 싶을 때가 있는데, (간혹 그 속에서 좋은 시드를 찾을 때가 있긴 하니까) 그럴 때도 데빈이는 묵묵히, 또 빠르게 결과 값을 가져다주어 속 시원함을 제공해 주기도 합니다.

Claude: 제품 전략부터 기획까지 함께하는 주니어 PO

Claude가 맡은 메인 역할은 세 가지입니다.

1) Discussion Partner

가장 많이 쓰는 역할입니다. 문제 정의가 틀어졌을 때, 더 나은 대안이 있을 때, 논리에 구멍이 있을 때, 리스크를 놓쳤을 때, 대화를 통해 잡아냅니다. 실제로 백로그 검토 및 쟁점 정리, 온보딩 이후 문제 정의와 솔루션 기획, 스쿼드 회고 정리, 온보딩 플로우 재구성 등 다양한 국면에서 이 역할을 활용했습니다.

2) Document Editor

저는 맥락을 최대한 주기 위해 raw data를 통째로 던지는 편입니다. 두서없이 적어 내려간 사고 흐름, 유저 인터뷰 원문, 서베이 응답 같은 날것의 데이터를 문서 목적에 맞게 정리해 줍니다. 대부분의 PRD와 분석 문서 등 주요 문서들은 클로드가 작성해 주죠. 특히 이번 분기는 영어권 국가 유저 인터뷰를 진행하느라 영어 <> 한국어 간 넘나듦이 문서상에서도 빈번했는데, 알아서 어련히 깔끔하게 잘해주니 이보다 든든할 수 없었죠.

3) DA

주어진 데이터와 기획 의도, 맥락을 기반으로 가설을 검증하고 후속 액션 아이템을 뽑아줍니다. 데빈이가 실제 코드 베이스와 데이터베이스를 넘나들 수 있는 역량이 있다면, 클로드는 그걸 읽고 해석하는 두뇌가 더 명석합니다. 둘의 합작으로 유의미한 분석 결과들을 내주고 있습니다.

데빈이가 필요한 데이터 뽑아주고, 클로드가 전체 맥락에서 정리해 줍니다.

이보다 마이너한 활용도 있습니다.

Visualizer로서 그래프, 다이어그램, 발표 자료 같은 것들을 빠르게 만들어주고, Copywriter로서 완벽한 카피는 아니더라도 시드를 발산하는 데 도움을 줍니다. 반면, Researcher로는 거의 쓰지 않습니다. 그 이유는 보통 레퍼런스 리서치를 할 때는 실제 그 앱들을 직접 만져보며, 화면과 플로우를 확인해야 제대로 알 수 있는 영역이라, AI가 대체하기 어렵습니다.

잠시 희망을 가졌지만, 결국 직접해야 하는 부분입니다.

마치며: 주니어를 다루듯이

여기까지 읽으면 “딸깍” 한 번이면 AI가 다 해주는 것처럼 들릴 수 있습니다. 하지만 이 둘은 결국 주니어입니다. 그것도 성향이 좀 다른 주니어들입니다. 그래서 기대치를 어느 정도 낮추고, 적절하게 위임해야 합니다.

Devin은 부지런하지만 좀 덜렁거리는 타입입니다.

참고해야 할 코드베이스나 데이터 소스를 착각하는 경우가 종종 있어서, 결과물은 반드시 크로스 체크해야 합니다. 또한 조사해야 할 영역을 명확히 좁혀주지 않으면, 꽤 멀리 엄한 곳까지 헤매다 돌아오기도 합니다. 그래서 스코프를 잘 잡아주는 게 중요합니다.

Claude는 더 똑똑하지만, 다른 종류의 주의가 필요합니다.

전체 맥락을 다 품지 못하기 때문에 우선순위를 혼자 잘못짚을 때가 있고, 불필요한 내용을 과하게 담아서 오히려 가독성을 떨어뜨리기도 합니다. 없어도 전체 이해에 지장 없는 건 과감히 쳐내는 게 좋습니다. 임팩트 추정에서는 여러 변수에 가정치를 넣는 경우가 있는데요. 그 가정치가 적절한지는 PO의 직관으로 반드시 검증해야 합니다. 정리된 결과물의 직접 검수하는 건 필수입니다.

둘 다 결국 같은 원칙이 적용됩니다.맥락을 나보다는 잘 알 수가 없습니다. 가장 상위에서의 머리 역할은 제가 수행해줘야 합니다.

다만, 주니어를 다루듯이 대한다는 건 한계만 인식하라는 뜻은 아닙니다.맥락을 잘 넘겨주고, 역할을 명확히 정의하고 피드백을 주면, 똑똑한 주니어답게 점점 더 일의 합이 잘 맞습니다. 가르쳐주면 가르쳐줄수록 일을 더 잘하는 친구들이니까요.

AI 기술이 워낙 빠르게 발전하고 있으니, 다음 분기에는 아마도 이 둘의 직급을 올려줄 수 있지 않을까 기대하고 있습니다. 그리고 느낌상 둘이 직접 소통할 수 있게 해 두면 더 수월할 것 같은데, 그건 다음 분기에 다뤄보겠습니다. 읽어주셔서 감사합니다!

<원문>

AI와 함께 이끌어온 2개의 스쿼드

]]>

에이전트 하네스 완전 해부

본문은 요즘IT가 Vivek Trivedy(비벡 트리베디) 님의 글<The Anatomy of an Agent Harness>를 번역한 글입니다. 필자는 LangChain의 프로덕트 매니저로, 에이전트·하네스·평가(Evals)를 담당하며 오픈소스 에이전트 프레임워크 개발을 이끌고 있습니다. 이전에는 AWS에서 과학자(Scientist)로 근무하며 Temple University에서 컴퓨터 과학 박사 학위를 취득했습니다.

이 글은 AI 에이전트 시스템에서 모델을 감싸는 인프라, 즉 '하네스(Harness)'의 개념을 정의하고, 파일시스템·샌드박스·메모리·컨텍스트 관리 등 핵심 구성 요소를 모델의 한계에서 역추적하여 도출하는 과정을 담고 있습니다. LangChain이 자사 코딩 에이전트의 하네스만 변경하여 Terminal Bench 2.0에서 Top 30에서 Top 5로 끌어올린 사례를 포함해, 하네스 엔지니어링의 현재와 미래를 구체적으로 소개합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

누가 "하네스"를 좀 정의해줄래요?

에이전트 = 모델 + 하네스(harness)

모델이 아닌 모든 것이 하네스입니다. 하네스란 모델 그 자체가 아닌 모든 코드, 설정, 실행 로직을 말합니다. 날것의 모델(raw model)은 에이전트가 아닙니다. 하지만 하네스가 모델에게 상태(state), 도구 실행, 피드백 루프, 강제 가능한 제약 같은 것들을 부여하는 순간, 모델은 에이전트가 됩니다.

구체적으로 하네스는 다음과 같은 것들을 포함합니다.

시스템 프롬프트
도구(Tools), 스킬(Skills), MCP와 그 설명들
번들링된 인프라(파일시스템, 샌드박스, 브라우저)
오케스트레이션 로직(서브에이전트 생성, 핸드오프, 모델 라우팅)
결정론적 실행을 위한 훅/미들웨어(compaction, continuation, lint check)

에이전트 시스템에서 모델과 하네스의 경계를 나누는 방법은 여러 가지고, 꽤 지저분합니다. 하지만 제 생각에 위 정의가 가장 깔끔합니다. 왜냐하면 이 정의는 모델의 지능(intelligence)을 중심에 두고 시스템을 설계하도록 강제하기 때문입니다.

이 글의 나머지 부분에서는 하네스의 핵심 구성 요소들을 하나씩 살펴보면서, 모델이라는 핵심 프리미티브(primitive)에서 출발해 각 구성 요소가 왜 존재해야 하는지를 역으로 도출해보겠습니다.

왜 하네스가 필요한가: 모델의 관점에서

우리가 에이전트에게 시키고 싶은 일들 중에는, 모델이 그 자체로는 할 수 없는 것들이 있습니다. 바로 이 지점에서 하네스가 등장합니다. 모델은 (대체로) 텍스트, 이미지, 오디오, 비디오 같은 데이터를 입력받아 텍스트를 출력합니다. 그게 전부입니다. 모델은 기본적으로 다음을 할 수 없습니다.

상호작용 간에 지속 가능한 상태 유지
코드 실행
실시간 지식 접근
작업 완수를 위한 환경 세팅 및 패키지 설치

이것들은 모두 하네스 레벨의 기능입니다. LLM이라는 구조 자체가, 유용한 일을 시키려면 모델을 감싸는 어떤 기계 장치를 필요로 합니다.

예를 들어, "대화하기"라는 제품 UX를 만들려면 이전 메시지들을 추적하고 새 사용자 메시지를 덧붙이기 위해 모델을 while 루프로 감싸야 합니다. 이 글을 읽고 있는 분이라면 이미 이런 종류의 하네스를 써본 셈입니다. 핵심은, 우리가 원하는 에이전트의 행동을 하네스의 실제 기능으로 변환한다는 것입니다.

원하는 에이전트 행동에서 하네스 엔지니어링으로 역산하기

하네스 엔지니어링은 인간이 에이전트의 행동을 유도하기 위한 유용한 사전 지식(prior)을 주입하는 일입니다. 그리고 모델이 더 똑똑해질수록, 하네스는 이전에는 불가능했던 작업을 완수하도록 모델을 정교하게 확장하고 교정하는 용도로 쓰이고 있습니다.

모든 하네스 기능을 빠짐없이 다루지는 않을 겁니다. 목표는 "모델이 유용한 일을 하게 돕는다"는 출발점에서 일련의 기능들을 도출해보는 것입니다. 다음과 같은 패턴을 따라가 보겠습니다.

우리가 원하는(또는 고치고 싶은) 행동 → 모델이 그것을 달성하게 돕는 하네스 설계

지속적 저장과 컨텍스트 관리를 위한 파일시스템

우리는 에이전트가 실제 데이터와 상호작용하고, 컨텍스트에 담기지 않는 정보를 덜어내고, 세션을 넘나들며 작업을 지속하도록 하고 싶습니다.

모델은 컨텍스트 윈도우 안의 지식에 대해서만 직접 작업할 수 있습니다. 파일시스템이 도입되기 전에는 사용자가 모델에게 내용을 복사·붙여넣기 해야 했습니다. UX가 번거롭고, 자율 에이전트에는 적용할 수도 없습니다. 세상은 이미 작업을 위해 파일시스템을 쓰고 있었고, 덕분에 모델은 파일시스템 사용법을 수십억 토큰으로 자연스럽게 학습한 상태였습니다. 그래서 자연스러운 해결책은 이것이 됐습니다.

하네스는 파일시스템 추상화와 파일 시스템 작업(fs-ops)용 도구를 기본 탑재합니다. 파일시스템은 아마도 가장 근본적인 하네스 프리미티브일 것입니다. 다음과 같은 것들을 가능하게 하기 때문입니다.

에이전트에게 데이터, 코드, 문서를 읽을 수 있는 작업 공간이 생깁니다.
모든 것을 컨텍스트에 붙들고 있는 대신, 작업을 점진적으로 더하거나 덜어낼 수 있습니다. 중간 산출물을 저장하고, 한 세션을 넘어서는 상태를 유지할 수 있습니다.
파일시스템은 자연스러운 협업 표면입니다. 여러 에이전트와 인간이 공유된 파일을 통해 협업할 수 있습니다. 에이전트 팀(Agent Teams) 같은 아키텍처가 이 위에서 돌아갑니다.
Git을 더하면 파일시스템에 버전 관리가 붙어, 에이전트가 작업을 추적하고, 에러를 롤백하고, 실험을 브랜치로 나눌 수 있게 됩니다.

파일시스템은 뒤에서 다시 등장합니다. 알고 보면 이것이 다른 여러 기능의 기반이 되는 핵심 하네스 프리미티브이기 때문입니다.

범용 도구로서의 Bash와 코드

우리는 인간이 모든 도구를 미리 설계하지 않아도 에이전트가 자율적으로 문제를 해결하기를 원합니다.

오늘날 에이전트 실행의 주류 패턴은 ReAct 루프입니다. 모델이 추론하고, 도구 호출로 행동하고, 결과를 관찰하고, 이를 while 루프 안에서 반복하는 방식입니다. 하지만 하네스는 자기가 로직을 갖고 있는 도구만 실행할 수 있습니다. 사용자에게 가능한 모든 행동에 대한 도구를 일일이 만들라고 요구하는 건 좋은 해결책이 아닙니다. 더 나은 방법은 에이전트에게 bash 같은 범용 도구를 주는 것입니다.

하네스는 bash 도구를 기본 탑재해, 모델이 코드를 작성하고 실행하며 자율적으로 문제를 풀 수 있게 합니다. Bash와 코드 실행은 모델에게 컴퓨터를 쥐여주고 나머지는 알아서 하게 하는 방향으로 가는 큰 도약입니다. 모델은 미리 설정된 고정된 도구 세트에 갇히지 않고, 코드를 통해 즉석에서 자신만의 도구를 설계할 수 있습니다.

하네스는 여전히 다른 도구들도 함께 제공하지만, 코드 실행은 자율적 문제 해결의 기본 전략으로 자리 잡았습니다.

작업을 실행하고 검증하기 위한 샌드박스와 도구

에이전트는 안전하게 행동하고, 결과를 관찰하며, 진전을 이룰 수 있는 적절한 기본 환경이 필요합니다. 모델에게 저장 공간과 코드 실행 능력을 줬지만, 이 모든 것이 어딘가에서 일어나야 합니다. 에이전트가 만든 코드를 로컬에서 그대로 실행하는 건 위험하고, 단일 로컬 환경은 대규모 에이전트 워크로드에는 적합하지 않습니다.

샌드박스는 에이전트에게 안전한 실행 환경을 제공합니다. 로컬 대신, 하네스가 샌드박스에 연결해 코드를 실행하고, 파일을 살펴보고, 의존성을 설치하고, 작업을 완료합니다. 이 방식은 격리된 안전한 코드 실행을 가능하게 합니다. 보안을 더 강화하려면, 하네스에서 허용 명령어를 화이트리스트로 지정하고 네트워크 격리를 강제할 수도 있습니다. 샌드박스는 확장성도 열어줍니다. 필요할 때 환경을 생성하고, 여러 작업에 병렬로 뿌리고, 끝나면 정리할 수 있기 때문입니다.

좋은 환경은 좋은 기본 도구들과 함께 옵니다. 하네스는 에이전트가 유용한 일을 할 수 있도록 도구를 구성할 책임이 있습니다. 언어 런타임과 패키지 사전 설치, git과 테스트용 CLI, 웹 상호작용 및 검증용 브라우저 등이 여기 포함됩니다.

브라우저, 로그, 스크린샷, 테스트 러너 같은 도구는 에이전트가 자기 작업을 관찰하고 분석할 수 있게 해줍니다. 이를 통해 에이전트는 자기 검증 루프를 만들 수 있습니다. 애플리케이션 코드를 작성하고, 테스트를 돌리고, 로그를 살펴보고, 에러를 고치는 식으로요.

모델은 기본적으로 자기 실행 환경을 스스로 구성하지 않습니다. 에이전트가 어디서 동작할지, 어떤 도구를 쓸 수 있을지, 무엇에 접근할 수 있을지, 어떻게 작업을 검증할지는 모두 하네스 수준의 설계 결정입니다.

지속적 학습을 위한 메모리와 검색

에이전트는 이전에 본 것을 기억해야 하고, 학습 시점에는 존재하지 않았던 정보에도 접근할 수 있어야 합니다. 모델은 가중치와 현재 컨텍스트에 담긴 것 외에는 추가 지식이 없습니다. 모델 가중치를 수정할 수 없는 상황에서, "지식을 추가"하는 유일한 방법은 컨텍스트 주입입니다.

메모리 측면에서도 파일시스템이 다시 핵심 프리미티브로 등장합니다. 하네스는 AGENTS.md 같은 메모리 파일 표준을 지원하고, 에이전트 시작 시 이를 컨텍스트에 주입합니다. 에이전트가 이 파일을 추가하고 수정하면, 하네스는 업데이트된 내용을 다음 컨텍스트에 불러옵니다. 이는 일종의 지속적 학습입니다. 에이전트가 한 세션에서 얻은 지식을 지속 가능하게 저장하고, 그 지식을 이후 세션에 주입하는 방식이죠.

지식 컷오프(knowledge cutoff) 때문에, 모델은 사용자가 직접 제공하지 않는 한 새로 업데이트된 라이브러리 버전 같은 데이터에 직접 접근할 수 없습니다. 최신 지식을 위해서는 웹 검색과 Context7 같은 MCP 도구들이 에이전트가 학습 이후에 등장한 정보, 예컨대 최신 라이브러리 버전이나 최신 데이터에 접근하도록 도와줍니다.

웹 검색과 최신 컨텍스트 조회 도구는 하네스에 내장할 만한 유용한 프리미티브들입니다.

컨텍스트 부패와 싸우기

작업이 진행될수록 에이전트 성능이 나빠져서는 안 됩니다. 컨텍스트 부패(context rot)는 컨텍스트 윈도우가 채워질수록 모델이 추론과 작업 수행에서 나빠지는 현상을 말합니다. 컨텍스트는 귀중하고 희소한 자원이기 때문에, 하네스는 이를 관리할 전략이 필요합니다.

오늘날의 하네스는 사실상 좋은 컨텍스트 엔지니어링을 전달하는 수단입니다.

Compaction은 컨텍스트 윈도우가 가득 차려 할 때 무엇을 할지의 문제를 다룹니다. compaction이 없으면 대화가 컨텍스트 윈도우를 초과했을 때 어떻게 될까요? 한 가지 선택지는 API가 에러를 내는 것입니다. 좋지 않죠. 하네스는 이런 상황을 위한 전략이 필요합니다. compaction은 기존 컨텍스트를 똑똑하게 덜어내고 요약해서, 에이전트가 계속 작업할 수 있게 해줍니다.

도구 호출 오프로딩(Tool call offloading)은 큰 도구 출력이 유용한 정보 없이 컨텍스트를 어지럽히는 문제를 줄여줍니다. 하네스는 일정 토큰 수 이상인 도구 출력에 대해 앞뒤 토큰만 남기고, 전체 출력은 파일시스템에 옮겨두어 필요할 때만 모델이 접근할 수 있게 합니다.

스킬(Skills)은 에이전트 시작 시 너무 많은 도구나 MCP 서버가 컨텍스트에 로드되어, 일을 시작하기도 전에 성능이 떨어지는 문제를 해결합니다. 스킬은 점진적 공개(progressive disclosure)를 통해 이 문제를 푸는 하네스 수준의 프리미티브입니다. 모델이 시작 시 스킬의 front-matter를 컨텍스트에 싣겠다고 선택한 건 아니지만, 하네스가 이를 지원함으로써 모델을 컨텍스트 부패로부터 보호할 수 있습니다.

장기 자율 실행

우리는 에이전트가 복잡한 작업을, 자율적으로, 정확하게, 긴 시간에 걸쳐 완수하기를 원합니다. 자율적인 소프트웨어 생성은 코딩 에이전트의 성배입니다. 하지만 오늘날의 모델들은 조기 종료(early stopping), 복잡한 문제 분해의 어려움, 여러 컨텍스트 윈도우를 넘어갈 때의 일관성 붕괴 같은 문제들을 겪습니다. 좋은 하네스는 이 모든 것을 설계에 반영해야 합니다.

여기서부터는 앞서 다룬 하네스 프리미티브들이 복리처럼 작동하기 시작합니다. 장기 작업은 여러 컨텍스트 윈도우를 넘어 작업을 지속하기 위해 지속 가능한 상태, 계획, 관찰, 검증을 모두 필요로 합니다.

세션을 가로지르는 작업 추적을 위한 파일시스템과 git

에이전트는 긴 작업 동안 수백만 토큰을 만들어내기 때문에, 파일시스템이 작업을 지속 가능하게 담아 시간에 따른 진전을 추적합니다. 여기에 git을 더하면, 새로 시작한 에이전트가 프로젝트의 최신 상태와 히스토리를 빠르게 따라잡을 수 있습니다. 여러 에이전트가 함께 일할 때도 파일시스템은 공유된 작업 원장(ledger) 역할을 합니다.

작업을 이어가기 위한 Ralph Loop

Ralph Loop은 모델이 종료하려는 시도를 훅으로 가로채, 깨끗한 컨텍스트 윈도우에 원래 프롬프트를 다시 주입해 완료 목표를 향해 계속 일하게 하는 하네스 패턴입니다. 이 패턴이 가능한 건 파일시스템 덕분입니다. 각 반복은 새 컨텍스트로 시작하되, 이전 반복의 상태를 파일에서 읽어오기 때문입니다.

궤도를 유지하기 위한 계획과 자기 검증

계획(planning)은 모델이 목표를 여러 단계로 분해하는 일입니다. 하네스는 좋은 프롬프트와, 파일시스템의 계획 파일 사용법에 대한 리마인더 주입을 통해 이를 지원합니다. 각 단계를 완료한 뒤, 에이전트는 자기 검증(self-verification)을 통해 작업의 정확성을 점검할 때 더 잘 동작합니다. 하네스의 훅이 사전 정의된 테스트 스위트를 실행하고, 실패 시 에러 메시지를 담아 모델로 다시 루프를 돌릴 수도 있고, 모델이 스스로 자기 코드를 평가하도록 프롬프트를 설계할 수도 있습니다. 검증은 해결책을 테스트에 뿌리내리게 하고, 자기 개선을 위한 피드백 신호를 만들어냅니다.

하네스의 미래

모델 학습과 하네스 설계의 결합

오늘날 Claude Code나 Codex와 같은 에이전트 제품들은 모델과 하네스가 루프 안에 포함된 상태로 사후 학습(Post-trained)됩니다. 이를 통해 모델은 하네스 설계자가 의도한 동작(파일 시스템 조작, Bash 실행, 계획 수립, 하위 에이전트 병렬화 등)을 기본적으로 더 잘 수행하게 됩니다.

이 과정에서 유용한 프리미티브가 발견되어 하네스에 추가되고, 이는 다시 다음 세대 모델 학습에 사용되는 피드백 루프가 형성됩니다. 이 사이클이 반복되면서, 모델은 자기가 학습된 하네스 안에서 점점 더 유능해집니다.

하지만 이 공진화(co-evolution)는 일반화 측면에서 흥미로운 부작용을 낳습니다. 도구 로직을 바꾸면 모델 성능이 떨어지는 현상 같은 것들이죠. 좋은 예가 Codex-5.3 프롬프팅 가이드에 나오는, 파일 편집용 apply_patch 도구 로직에 관한 내용입니다. 진정으로 지능적인 모델이라면 패치 방식을 바꾸는 정도로 문제를 겪을 리 없지만, 하네스를 루프에 넣은 학습은 이런 식의 과적합을 만듭니다.

그렇다고 해서 모델이 사후 학습될 때 사용된 하네스가 반드시 여러분의 작업에 최적인 것은 아닙니다. Terminal Bench 2.0 리더보드가 좋은 예입니다. Claude Code 안에서의 Opus 4.6은 다른 하네스에서의 Opus 4.6보다 한참 낮은 점수를 받습니다. 이전 글에서 저희는 코딩 에이전트의 Terminal Bench 2.0 순위를 하네스만 바꿔 Top 30에서 Top 5로 끌어올린 과정을 공유한 적이 있습니다. 여러분의 작업에 맞게 하네스를 최적화하는 일에는 아직 짜낼 수 있는 즙이 많이 남아 있습니다.

하네스 엔지니어링은 어디로 가는가

모델이 더 유능해질수록, 지금 하네스에 있는 일부 기능은 모델 안으로 흡수될 것입니다. 모델은 기본적으로 계획 수립, 자기 검증, 장기 일관성 유지 등을 더 잘하게 될 것이고, 결과적으로 컨텍스트 주입과 같은 필요성은 줄어들 것입니다.

이는 시간이 흐를수록 하네스의 중요성이 낮아질 것임을 시사합니다. 하지만 프롬프트 엔지니어링이 지금도 여전히 가치 있는 것처럼, 하네스 엔지니어링도 좋은 에이전트를 만드는 데 계속 유용할 가능성이 큽니다.

하네스는 모델의 부족한 점을 보완하기도 하지만, 무엇보다 모델의 지능을 중심으로 시스템을 설계하여 효율성을 극대화하기 때문입니다. 잘 구성된 환경, 적절한 도구, 영구적인 상태, 그리고 검증 루프는 모델의 기초 지능 수준과 상관없이 더 효율적인 에이전트를 만듭니다.

하네스 엔지니어링은 저희가 LangChain에서 하네스 구축 라이브러리 deepagents를 개선하며 계속 연구하고 있는 매우 활발한 영역입니다. 아래는 저희가 현재 탐색하고 있는 문제들입니다.

공유 코드베이스 위에서 수백 개의 에이전트가 병렬로 일하도록 오케스트레이션하기
자기 트레이스를 분석해 하네스 수준의 실패 패턴을 찾아내고 고치는 에이전트
미리 설정해두는 대신, 주어진 작업에 맞춰 적절한 도구와 컨텍스트를 적시에(just-in-time) 동적으로 조립하는 하네스

이 글은 하네스가 무엇인지 정의하고, 우리가 모델에게 원하는 작업에 따라 하네스가 어떻게 형성되는지 고찰해 보는 과정이었습니다. 모델은 지능을 품고, 하네스는 그 지능을 유용하게 만드는 시스템입니다. 더 나은 하네스, 더 나은 시스템, 더 나은 에이전트를 향해.

<원문>

The Anatomy of an Agent Harness

]]>

‘사고 근육’을 지켜주는 AI 글쓰기 방법 5가지

AI가 쓴 글에서 보편적으로 드러나는 몇 가지 특징이 있다.

현란한 이모지
특정 단어 강조를 위한 **스마트 따옴표**
반복적인, 쉼표, 사용
추가 설명은 엠-대시(—)
…

이러한 언어적 패턴을 검출하여 AI가 쓴 보고서를 판별한 사례도 있다. 최근에는 그 레이더를 피하기 위해 AI로 작성한 글을 사람의 글처럼 바꾸는 프롬프트나 방법론도 등장하고 있다. 어떻게든 AI로 편하게 글을 쓰려는 쪽과 이를 걸러내려는 쪽의 대립이 마치 창과 방패의 싸움과 같다.

하지만 이로 인해 생겨날 수 있는 문제들은 단순히 AI 특유의 문체를 자연스럽게 고치거나 탐지를 피하는 방식으로 해결될 종류의 것이 아니다. 더 중요한 점은 AI로 글을 쓰는 과정에서 인간의 사고력과 인지 능력이 저하될 수 있다는 점이다. 마치 운동을 하지 않으면 근력이 저하되듯, 생각하지 않으면 사고력과 인지 능력 역시 약해질 수 있다. 오클라호마 주립대의 수비시 카크 교수는 이를 ‘인지적 위축(cognitive atrophy)’ 현상이라고 설명한다.

그렇다고 해서 AI를 사용하지 않는 것만이 답은 아니다. 인간의 신체 활동이 줄어들었다고 자동차를 금지할 수 없는 것처럼, AI 역시 효율적으로 활용하되 사고력과 인지 능력을 어떻게 보존할 것인지에 대한 고민이 필요하다. 따라서 이 글에서는 글을 쓰는 과정에서 사고력을 유지하고 강화하는 방향으로 AI를 활용하는 다섯 가지 방법을 소개한다.

비판적 사고 능력을 보존하면서 AI로 글쓰기

Why do some people like talking to a therapist? Would you like to try therapy?
왜 어떤 사람들은 심리 치료사와 이야기하는 것을 좋아할까요? 당신도 심리 치료를 받아보시겠어요?

여러 방법에 대한 적절한 예시를 제시하기 위해, 글에서는 위의 질문에 대해 개인의 의견을 서술하는 상황을 가정하려고 한다. 이 질문은 최근 내가 참여한 화상 영어 수업에서 다뤄진 토론 주제로, 일반적인 주제이면서도 개인의 배경이나 관심사에 따라 답변의 방향이 크게 달라질 수 있어 예시로 선정했다.

따라서 이처럼 질문이 정해진 자기소개서나 인터뷰 질의응답, 또는 특정 사회 현상에 대한 자신의 관점을 설명해야 하는 칼럼이나 에세이를 작성할 때, 아래와 같은 방법을 더욱 잘 적용해 볼 수 있다.

1. 사고·관점 확장을 위한 질문부터 시작하기

먼저 질문의 의미와 의도를 톺아보는 것에서 출발한다. 여기서 핵심은 질문에 곧바로 답하려 하기보다, 브레인스토밍을 하듯 다양한 방향과 가능한 해석의 여지를 충분히 검토하는 데 있다. 이를 위해 다음과 같은 프롬프트를 활용할 수 있다.

사고 확장을 위한 프롬프트 입력 <출처: 작가>

이 프롬프트는 질문을 어떻게 해석할지, 그리고 어떤 방향으로 생각을 확장할 수 있을지에 대한 단서를 요구하고 있다. 또한 AI 상담에 대한 경험을 정리한 칼럼 자료를 함께 제공했는데, 질문 자체는 ‘심리 상담’에 대한 일반적인 주제이지만, AI와의 상호작용을 연구한다는 배경과 글의 목적을 반영하기 위함이었다.

이때 쓸 참고 자료는 상황에 따라 달라질 수 있다. 예를 들어 자기소개서를 작성할 때는 인재상이나 직무 설명 등이 질문의 의도를 해석하는 데 필요하다. 반면 인터뷰 질의응답이나 에세이를 작성할 때는 자신의 경험이나 생각을 정리한 글을 첨부할 수도 있다.

생각을 확장할 수 있는 관점들 <출처: 작가>

클로드에 프롬프트를 입력하니, 두 문장으로 이뤄진 질문을 각각 나누어 해석하기 시작했다. ‘왜 사람들이 심리 상담사를 찾는가’라는 질문은 일반적으로 인간에게 적용되는 심리적 메커니즘을 묻는 것이고, ‘상담을 받아보고 싶은가’라는 질문은 공감이나 편견 등 개인의 관점을 묻는 것으로 분석했다.

특히 첫 번째 질문에 대해서는 세 가지 관점을 제시했다. 말하는 대상과 행위 중 무엇이 더 중요한지, 단순한 정보 획득을 넘어 상담은 어떤 효과가 있는지, AI와 인간 상담을 어떻게 비교할 수 있는지에 대한 서로 다른 관점을 주었다. 이처럼 하나의 주제와 질문에 대해서도 생각의 방향은 무궁무진하게 확장될 수 있다. 그때 AI를 활용하면 질문을 다양한 각도에서 검토할 수 있어, 혼자 사고할 때보다 훨씬 넓은 범위로 사고를 확장할 수 있다.

강조했듯, 이 방법의 효과는 즉각적인 답변을 요구하지 않는다는 데에서 나온다. 실제로 이는 OECD가 교육용 AI와 일반 AI를 구분하는 가장 본질적인 차이로 언급한 특징이기도 하다.

예를 들어, 학생이 "피타고라스 정리가 뭐예요?”라고 질문했을 때 챗GPT는 바로 정의와 공식을 제시한다. 반면 교육용으로 개발된 ‘소크라테스 놀이터’와 같은 AI는 정답을 제시하는 대신, "직각삼각형의 세 변 사이에는 무슨 관계가 있을까?", "정사각형의 넓이는 어떻게 구하지?"와 같은 질문으로 사고를 자극하고, 학생이 스스로 답을 찾도록 유도한다. 이와 같은 원리를 글쓰기에 적용한 것이다.

2. 다른 성격을 지닌 AI 모델 함께 사용하기

여러 대화형 AI를 사용하다 보면 저마다 말투나 답변 방식이 다르다는 점을 느낄 수 있다. 마치 인간 고유의 특성인 성격과 성향을 지닌 것처럼 보이기도 한다.

최근 연구에서는 AI를 위한 성격 테스트 프레임워크도 등장했다. 우리가 흔히 알고 있는 MBTI와 같은 성격 검사를 AI에 맞게 확장한 것이다. 인간의 성격이 다양한 것처럼, 전략적이고 분석적인 AI가 있는가 하면 감성적이고 상상력이 풍부한 AI도 존재한다. 이러한 차이를 고려해, 앞서 작성한 프롬프트를 여러 LLM에 입력하고 아이디어를 비교·검토하는 방식을 시도해볼 수 있다.

챗GPT의 답변(왼쪽)과 제미나이의 답변 <출처: 작가>

클로드에 입력했던 프롬프트를 각각 챗GPT와 제미나이에 입력한 결과다. 챗GPT는 심리 상담에 대한 질문을 ‘어떤 결핍을 어떤 방식으로 채우는가’라는 관점에서 해석했다. 또한 클로드의 답변에서 한 걸음 더 나아가, 상담 기간에 따른 치료 효과까지 확장해 생각해 볼 수 있다고 제안했다. 한편 제미나이는 다른 AI가 상대적으로 간과했던 두 번째 질문에 대한 해석도 함께 제시했다.

혼자만 생각하면 자신의 관점에 갇히기 쉬운 것처럼, AI 역시 각자의 특성에 따라 사고의 방향이 좁아질 수 있다. 이러한 한계를 보완하며 관점을 한 번 더 확장할 수 있는 점이 두 번째 방법의 핵심이다.

3. 다양한 관점에서 피드백 주고받기

앞선 두 가지 방법으로 사고를 확장하다 보면 전달하고자 하는 메시지가 어느 정도 정리된다. 처음 생각을 자유롭게 풀어낸 다음에는 점차 다듬어 나가는 과정을 거쳐야 하는데 이때 필요한 것이 세 번째 방법이다.

앞서 언급했듯 AI마다 서로 다른 특성을 지닌다. 따라서 어떤 AI의 피드백을 반영하느냐에 따라 글을 고치는 방향도 달라질 수 있다. 무작정 모든 피드백을 수용하다 보면, 초안은 본인이 작성했더라도 점차 AI 특유의 문체로 변질될 위험이 있다. 따라서 각 피드백이 실제로 필요한 수정인지 비판적으로 검토해야 한다. 예를 들어 “제미나이는 이렇게 수정하라고 하는데, 이에 대해 어떻게 생각하는가?”와 같은 방식으로 다른 AI의 의견을 교차 검토할 수 있다. 아래는 실제로 클로드가 답변한 내용이다.

제미나이의 피드백을 지적하는 클로드 <출처: 작가>

이 방법을 썼을 때, 챗GPT와 클로드는 자신이 처음 제시한 피드백을 고수하는 반면, 제미나이는 반박할 경우 빠르게 의견을 수정하는 경향이 두드러졌다. 특히 클로드는 다른 AI의 피드백에 동의하면서도 ‘GPT 말도 맞아. 근데 나도 내 입장 유지할게.’라고 말하는 등, 비교적 고집스러운 면모를 보였다.

그렇다고 언제나 완강한 것은 아니다. 때로는 ‘GPT가 더 자세히 분석했네.’라거나 ‘제미나이가 나보다 잘 답했어.’라고 하며 다른 AI의 답변을 인정하기도 했다.

여기서 중요한 점은 어떤 피드백을 최종적으로 반영할지 결정하는 주체는 글쓴이 자신이라는 사실이다. 특정 표현이나 메시지를 반드시 유지하고 싶다면, 이를 끝까지 가져가는 것이 글의 고유한 톤을 지키는 방법이 될 수 있다.

4. 새로운 대화창에서 검토하기

마지막 단계에서는 전체 글을 점검하는 과정이 필요하다. 하나의 대화창에서 사고의 확장과 수정 과정을 모두 거치면, 대부분의 맥락과 판단 근거가 그 안에 쌓인다. 그러니 이 상태에서 최종 검토를 요청하면 기존 맥락에 의존한 피드백이 이루어져 놓친 부분을 발견하기 어려울 수 있다.

따라서 새로운 대화창을 열고 질문과 최종 원고를 다시 입력한 다음 전체 검토를 요청하는 것이 효과적이다. 이때 필요한 참고 자료가 있다면 함께 제공하는 것이 좋다. 즉, 첫 번째 단계에서 사용했던 자료와 프롬프트를 그대로 포함하되, 명령문만 ‘질문 해석을 도와줘’가 아니라 ‘이 글을 검토해줘’로 바꿔주는 방식이다.

물론 새 채팅창을 열더라도 AI의 장기 기억 정보가 들어갈 수 있으므로 완전히 새로운 상태는 아니다. 그럼에도 불구하고 글에 대한 피드백을 받는 것은 충분히 가능하다. 오히려 더 높은 관련성을 가진 피드백이 나올 수도 있다.

이 방법의 핵심은 이전 대화의 맥락에서 살짝 벗어나는 데 있다. AI는 앞선 대화에서 나온 특정 핵심 피드백에 집중하면서 그 문제에 매몰됐을 가능성이 큰데, 대화창을 전환하는 것만으로도 보다 객관적인 시각에서 놓쳤던 부분을 다시 점검할 수 있다.

5. 확장 모델로 추가 검토하기

네 번째 방법으로 기본적인 검토를 마쳤다면, 확장 모델을 활용해 한 번 더 정밀하게 점검할 수 있다. 일반적으로 채팅형 웹 서비스는 빠른 응답을 제공하는 모델을 사용한다. 그러나 최종 단계에서는 보다 깊이 있는 분석을 제공하는 확장 모델을 활용하는 것이 효과적이다.

클로드(왼쪽), 제미나이(가운데), 챗GPT(오른쪽)의 확장 모델 선택 칸 <출처: 작가>

모드는 프롬프트 입력창에서 선택할 수 있다. 클로드는 ‘확장 사고’, 제미나이는 ‘사고 모델’, 챗지피티는 ‘잘 생각하기’라는 명칭을 사용한다. 이를 설정하고 네 번째 방법에서 작성했던 프롬프트와 최종 원고를 그대로 입력하면 된다. 각 모드에서는 사고 과정을 기반으로 보다 정교한 피드백이 제시되며, 이를 바탕으로 글을 한층 더 정밀하게 다듬을 수 있다.

마치며

수렵·채집 시대에는 삶 자체가 곧 신체 활동이었고, 그 과정에서 자연스럽게 근육이 단련되었다. 그러나 기술이 발전하면서 인간은 최소한의 움직임으로 이동하고 일을 처리할 수 있게 되었기에, 이제는 헬스장과 같은 별도의 공간에서 의도적으로 운동해야 신체 건강을 유지할 수 있다.

사고의 근육도 마찬가지다. AI의 발전으로 우리는 직접 깊이 생각하지 않고도 문제를 해결하고 의사결정을 내릴 수 있게 되었다. 그러나 이러한 편리함에만 의존할 경우 사고력은 점차 약해질 수밖에 없다. 따라서 인지 능력을 유지하고 강화하기 위한 의도적인 노력이 필요하다.

신체 근육을 단련하는 방법이 계속 발전해 왔듯, AI와 협업하며 인지 능력을 강화하는 방법 또한 지속적으로 발전할 것이다. 어떤 방법을 선택하든 시작을 결정하는 것은 결국 개인의 몫이다. 정답을 수동적으로 얻는 대신, 사고를 자극하고 스스로 답을 찾아가는 과정이 필요하다. 무엇보다 중요한 것은 스스로 생각하려는 의지다. 아무리 좋은 방법과 환경이 갖춰져 있어도 이를 활용하려는 의지가 없다면, 빨래 건조대로 전락한 러닝머신만 남을 뿐이다. 이 글이 사고력을 단련하는 출발점이 되기를 바란다.

]]>

AX 하기 전에 DX부터: 리더가 지금 점검해야 할 세 가지

에이전트, 자동화, AX 같은 키워드가 쏟아지지만, 막상 현장에서 "우리 조직은 AI를 제대로 쓰고 있는가"라는 질문에 자신 있게 답하는 리더는 많지 않습니다. 툴은 도입했는데 데이터는 꺼낼 수 없고, 보고서는 여전히 데이터 팀에 요청해야 하며, 조직이 커질수록 사일로는 깊어집니다. 최근 열린 한 발표에서, B2B SaaS 채널톡을 만드는 채널코퍼레이션의 사업개발 리드 문희철 님이 이 문제를 '극단적 경영 가시성'이라는 개념으로 풀어냈습니다.

특정 툴에 종속되지 않는 데이터 주권, 데이터가 흐르는 IT 인프라, 그리고 AI의 역할 범위를 설계하는 사람과 조직. 이 세 가지 관점을 중심으로, 빅쿼리 기반 데이터 웨어하우스 구축부터 MCP로 연결한 엔터프라이즈 영업 에이전트 설계까지 실제 실험 사례를 함께 공유했는데요. AX 이전에 무엇을 먼저 점검해야 하는지 고민하는분들께 참고가 되실 겁니다.

*이 발표는 2026년 4월 8일 채널톡이 후원한 <AX 리얼 비즈 케이스 스터디 라운드 테이블 1회>에서 진행됐습니다.

안녕하세요, 채널톡을 만드는 채널코퍼레이션의 사업개발 리드 문희철입니다. 오늘 말씀드리고 싶은 주제는 "극단적 경영 가시성"입니다. 하나하나 단어의 의미를 정의하면서 쌓아가는 방식으로 이야기하겠습니다.

문희철 채널코퍼레이션 사업개발 리드 <출처: 채널톡>

예를 하나 들겠습니다. 리테일 기업에 물류 창고가 있습니다. 창고에 과일이 있는데, 그 과일이 썩었습니다. 그런데 이미 박스 단위, 트럭 단위로 팔려 나갔습니다. 오너는 이 일을 모릅니다. 리테일과 F&B를 다루는 곳에서 이런 케이스는 실제로 빈번했고, 이것은 곧 큰 경영 리스크가 됩니다.

우리의 고객이 지금 어떤 상태인지, 우리 조직은 어떻게 움직이고 있는지, 매출과 비용은 어떻게 쓰이고 있는지. 세일즈든 파이낸스든 비용이든, 조직의 모든 디비전과 모든 하이어라키에서 목적에 부합하게 즉시, 충분히 알 수 있는 상태. 저는 이것을 극단적 경영 가시성이라고 정의하겠습니다.

그런데 왜 이게 어려웠을까요. 경영에 필요한 매출, 비용, 고객 행동, 그리고 이를 가공해 만든 보고서. 이런 데이터의 축적 자체가 어려웠습니다. 파편화돼 있었고요. IT 인프라와 소프트웨어, ERP를 포함해서 데이터를 입력하는 것도 어려웠고, 출력은 더 어려웠습니다. 출력할 때마다 우리는 데이터 팀에 물어봅니다. "이번 달 매출 데이터 좀 뽑을 수 없을까요?" "인천 지역에 이상징후가 있을까요?" 현지 창고 관계자한테 물어보거나, 데이터 담당자들한테 일일이 확인해야 합니다. 이 과정에서 하루가 일주일이 되고, 한 달이 금방 갑니다.

그리고 이걸 활용하는 사람들은 툴 기반 사고에 갇혀 있습니다. "세일즈포스가 최고야", "SAP이 너무 좋아." 물론 좋겠죠. 하지만 모든 문제를 해결할 수는 없습니다. 조직이 커질수록 사일로는 심화되고, 탑과 바텀의 지식·정보 차이도 커집니다.

이 문제를 풀기 위해서는 세 가지 축에 대한 관점이 필요합니다.

AI를 바라보는 관점
데이터가 흐를 수 있는 IT 인프라
그리고 이것을 실행하는 사람과 조직

이 세 가지를 하나씩 말씀드리겠습니다.

AI 도입 전, 데이터 주권과 일의 정의가 먼저다

툴이 아니라 데이터가 먼저다

첫 번째 관점, AI에 대한 이야기를 하겠습니다. 먼저 특정 솔루션에 갇히지 말아야 합니다. 채널톡에 갇히지 마시고, 세일즈포스에 갇히지도 마세요. 특정 소프트웨어를 도입하면 그 안에 데이터가 축적되고, 결국 해당 소프트웨어에 대한 데이터 디펜던시(의존성)가 형성됩니다. 저희 같은 B2B SaaS 회사 입장에서는 그것이 오히려 유리한 구조이기도 합니다. 하지만 기업 경영의 관점에서 진정으로 중요한 것은 자사가 직접 통제할 수 있는 데이터를 확보하고 있느냐입니다.

데이터를 통제한다는 것은 이 세 가지 조건을 충족하는 것입니다. 첫째, 비즈니스에 관련된 모든 데이터를 자사가 보유하고 있을 것. 둘째, 그 데이터를 통해 어떤 의사결정을 내려야 하는지 알고 있을 것. 셋째, 데이터 간의 연결이 가능할 것. 이 세 가지가 AI 활용의 출발점입니다.

AI를 못 쓰는 진짜 이유: 일의 과정이 정의되지 않았다

그런데 데이터를 보유하고 연결할 수 있다 해도, 그것으로 무슨 일을 해야 하는지 정의되지 않으면 의미가 없습니다. 여기서 저한테 큰 영감을 주신 분의 인사이트를 하나 공유하겠습니다. 그 분은 이렇게 말씀하셨어요. "딸깍에 이르는 과정은 딸깍이 아니다." 그리고 "모든 일의 과정에는 인풋(투입), 트랜스폼(변환), 아웃풋(산출물)이 있다." 단순하지만 핵심을 찌르는 정의였습니다.

모든 일은 투입과 변환과 산출의 과정입니다. 리소스와 시간과 사람과 데이터를 투입하고, 모종의 과정을 거쳐 변환하고, 산출물이 나옵니다. 데스크 리서치를 수행하든, 사람을 직접 만나 휴민트를 확보하든, 구조는 동일합니다.

문제는 이 구조가 대부분의 조직에서 정의되어 있지 않다는 점입니다. AI에게 일을 위임하기 전에, 자기 조직이 무슨 일을 하고 있는지, 어떤 목적을 추구하는지 파악하지 못하고 있습니다. 자기가 어떻게 효과적으로 일하고 있는지 모르면, 그 일을 다른 주체에게 시킬 수가 없습니다. 일이란 어떤 목적을 이루기 위해 전방 업무, 중간 업무, 후처리 업무가 연결된 것인데, 그 연결 구조 자체를 파악하지 못하고 있는 겁니다. AI를 잘 활용하지 못하는 근본적인 이유가 여기에 있습니다.

모든 일은 투입, 변환, 산출의 반복이며 AI 도입이 잘 되려면 일의 과정을 정의하고 그렇게 정의한 일의 과정이 연결되어야 한다는 주장. <출처: 채널코퍼레이션 문희철 사업개발 리드 발표자료>

그래서 우리는 잘 작동하고 있는 일들을 리버스 엔지니어링해야 합니다. 카페24 사례를 들겠습니다. 카페24 pro라는 ‘자사몰 생성 - 판매 - 운영 모두 자동화’하는 인상적인 기획이 있습니다. 쉽게 말하면 "제품만 있으면 알아서 팔아줄게"라는 것인데요. 주목할 점은 자사몰 하나를 구축하기 위해 900개가 넘는 세부 태스크가 존재한다는 것을 정의해냈다는 겁니다. 기획자들은 그 태스크들을 하나하나 정의하고, 사람이 반드시 수행하지 않아도 되는 항목을 분리한 뒤, 최대한 AI를 통해 자동화했습니다. 하지만 딸깍은 없었습니다. 900개의 태스크를 정의하는 과정 자체가 딸깍이 아니었던 겁니다.

AI가 유효한 데이터에 접근하여 생성, 조회, 수정, 삭제를 수행할 수 있다면, 사람이 담당했던 단순 반복 업무는 대부분 대체될 것입니다. 물론 이상적인 상태입니다. 하지만 그 이상에 도달하려면 변환과 가공의 과정에 매몰되지 말고, 지금 우리가 무엇을 원하는지 목적을 명확히 해야 합니다. 목적을 해석하고 변환하는 것은 AI의 영역입니다. 우리는 어떤 데이터로 어떤 목적을 추구할 것인지만 정의하면 됩니다.

데이터 파이프라인이 먼저다

두 번째 관점, IT 인프라에 대한 이야기입니다. 앞서 데이터 주권의 중요성을 말씀드렸는데, 현실에서는 그 주권이 확보되지 않은 상태에서 솔루션부터 도입하는 경우가 많습니다.

IT를 담당하시는 분들이라면 익숙한 장면일 겁니다. 어떤 팀에서 이런 이야기를 합니다. "이 솔루션 도입하면 잘 될 것 같은데요. 성공 사례가 이렇다는데요." 물론 좋을 수 있습니다. 하지만 앞에서 말씀드린 문제가 여기서 구체적으로 발생합니다. 솔루션 안에 데이터가 쌓이기 시작하면, 그 데이터를 꺼내 쓰는 것 자체가 어려워집니다.

실제 사례를 들겠습니다. 어떤 CX 솔루션을 사용하고 있는데, 데이터를 요청하니 API가 없습니다. 요청을 넣으면 2~3주 후에 전달되거나, 데이터 로우가 깨진 상태로 넘어옵니다. 또 다른 경우, 고객의 구독 정보와 렌탈 정보가 특정 ERP에 있는데 자사에서 직접 접근하거나 유지보수할 수가 없습니다. 해당 ERP 업체에 요청하면 CSV나 엑셀 파일로 월 1회 전달해줍니다. 담당자가 부재하면 그마저도 지연됩니다. 이런 상태에서는 AI가 접근할 수 있는 데이터 자체가 존재하지 않는 셈입니다.

그렇기 때문에 툴 중심으로 흩어져 있는 데이터 사일로를 해체해야 합니다. 핵심은 데이터가 흐르는 구조를 만드는 것입니다.

AX를 위해서는 데이터가 흐르는 구조가 필요하고, 이를 뒷받침할 IT 인프라가 있어야 한다는 주장. <출처: 채널코퍼레이션 문희철 사업개발 리드 발표자료>

이를 위해서는 하나의 원천, 소스 오브 트루스(Source of Truth)가 필요합니다. 데이터레이크라고도 합니다. 채널톡에 쌓인 데이터, 세일즈포스의 데이터, SAP의 데이터, 오라클의 데이터를 한곳으로 가져와 가공할 수 있어야 합니다. 중심은 소프트웨어가 아니라 데이터 그 자체입니다.

저희 채널코퍼레이션에서는 이 원칙에 따라 데이터 웨어하우스를 구축하기 시작했습니다. 회사 내 경영 관련 데이터를 하나로 통합하자는 것이 출발점이었습니다. 시장에는 데이터브릭스, 스노플레이크, 구글 빅쿼리 등 여러 선택지가 있었는데, 저희는 비용이 가장 낮고 수작업이 많이 수반되는 빅쿼리를 선택했습니다. 그리고 LLM이 데이터를 효과적으로 읽을 수 있도록, 각 데이터 필드의 의미와 맥락을 주석으로 기록했습니다. 이 작업을 반복한 결과, 단순 쿼리 요청을 데이터 팀에 의뢰하지 않아도 되는 환경이 만들어졌습니다. LLM이 데이터 웨어하우스를 직접 읽을 수 있게 된 겁니다.

데이터 소스는 세일즈, 매출, 비용, 고객 등 다양하며, 웨어하우스에 적재된 데이터를 AI 어시스턴트가 호출하는 방식입니다. 비용 분석, 매출 분석, 고객 분석은 물론이고, 내부 이슈에 대한 정성적 분석까지 수행합니다.

예를 들어 "특정 고객사의 MRR(월간 반복 매출) 추이를 알려달라"고 요청하면, AI 어시스턴트가 데이터를 기반으로 차트를 생성해 제시합니다. "이 고객사에 헨리라는 분이 기여한 매출이 얼마나 되는지 알려달라"고 이어서 질문하면, 로우 데이터까지 참조해 구체적인 숫자를 찾아줍니다. "채널톡 상위 100개 고객사를 차트로 만들어달라"는 요청에도, "원형으로 만들어달라", "3D로 바꿔줄 수 있느냐"는 후속 요청까지 자연어 대화만으로 모두 처리됩니다.

채널코퍼레이션의 AI 어시스턴트 활용 예시 <출처: 채널코퍼레이션 문희철 사업개발 리드 발표자료>

생성된 결과물은 팀 메신저로 자동 전달되고, 구성원들은 링크를 따라 들어가 확인한 뒤 논의를 이어갑니다. 자연어로 질문하면 되기 때문에 별도의 학습 비용이 거의 들지 않습니다. 저도 이 데모를 세미나 직전 오후 4시쯤에 가볍게 요청해본 것이었는데, 그 수준의 결과물이 즉시 나올 만큼 일상적인 도구가 되어 있습니다.

한 가지 강조하겠습니다. 저희가 어떤 애플리케이션을 사용했는지는 중요하지 않습니다. 데이터 원장에 접근할 수 있다면, MCP와 같은 연결 표준이 이미 존재하기 때문에 어떤 앱이든 연결하여 활용할 수 있습니다. 앱은 상황에 맞는 것을 선택하면 됩니다. 진짜 중요한 것은 앱이 아니라 데이터 파이프라인입니다. 목적이 정의되고 데이터에 접근할 수 있으면, 산출물 도출은 빠릅니다.

AI 에이전트의 역할 범위 설계: 감지, 실행, 연결

세 번째는 사람에 대한 관점입니다. 앞에서 일의 정의 이야기를 했는데, 결국 같은 맥락입니다. AI를 활용하는 우리 조직이, 오너가, 나 자신이 어떤 데이터를 활용해서 어떤 결과물을 만들어내는지 알아야 합니다. 그 위에서 AI의 역할을 어디까지 부여할 것인지를 설계해야 합니다.

AI를 활용하는 조직에서 어떤 데이터를 활용해 어떤 결과물을 만들어내는지를 알아야 AI 에이전트의 역할 범위를 설계할 수 있는데, 그 데이터의 활용 범위나 목표는 조직 내 역할별로 다르다는 주장. <출처: 채널톡 문희철 사업개발 리드 발표자료>

가장 수동적인 단계는 감지입니다. 이상 데이터를 감지하는 것, 예를 들어 특정 패턴에서 이상징후가 발견됐다는 것을 알려주는 수준입니다. 여기까지만 돼도 의미가 있습니다.

두 번째는 위임된 범위 안에서의 실행입니다. 이메일을 보내는 등 사람 대신 특정 액션을 수행하는 것. 사람이 판단한 범위 안에서 AI가 직접 움직이는 겁니다.

세 번째는 적절한 의사결정권자에게 연결하는 것입니다. 지금 문제 상황이 이렇고, 이슈는 이런데, 제안은 이렇습니다. A, B, C 선택지 중 어떻게 하시겠습니까. AI가 여기까지 해줄 수 있다면, 조직의 의사결정 속도는 근본적으로 달라집니다.

AI의 3단계 역할은 감지, 실행, 연결로, AI 에이전트에게 위임해야 할 업무의 기준이다. <출처: 채널톡 문희철 사업개발 리드 발표자료>

실제로 저희 CX팀은 이 원칙에 따라 움직이고 있습니다. 채널톡의 오픈 API를 통해 고객 응대 데이터가 축적돼 있고, 거기서 데이터를 가져와 후처리하거나, 반복되는 형태의 업무는 자체적으로 버티컬 앱을 만들어 처리합니다. 단순 반복 업무는 거의 사라졌습니다. 보안도 고려했습니다. 해당 앱에는 사내 VPN에서만 접근이 가능하도록 설계해두었습니다. 별도의 대규모 개발 프로젝트가 아니라, 목적 조직이 자기 업무의 범위와 권한을 정의하고, 그 안에서 AI의 역할을 직접 설계한 결과입니다.

이 세 단계를 조직 안에서 설계하는 게 핵심입니다. 데이터를 얼마나 열어줄 것인지, CRUD(Create 생성, Read 조회, Update 수정, Delete 삭제)의 어디까지 허용할 것인지를 용도와 권한에 따라 나눠야 합니다.

앞서 말씀드린 세 가지 전제를 다시 정리하겠습니다. AI에 대한 관점, 데이터가 흐르는 IT 인프라에 대한 관점, 그리고 이것을 활용하는 사람에 대한 관점. 이 세 가지가 갖춰졌을 때 비로소 구체적인 것을 만들 수 있습니다.

채널 코퍼레이션의 엔터프라이즈 영업 AI 구축 사례

저희 채널코퍼레이션에서 실제로 했던 이야기를 하겠습니다. 채널톡이 아니라, 채널톡을 제공하는 채널코퍼레이션의 이야기입니다.

저희 사업개발 팀은 목적 조직입니다. 전사적으로 세일즈 관점에서 엔터프라이즈 시장을 제대로 파고들자는 목적이 있었습니다. 그런데 우리 원장 데이터에 유의미한 것이 없었습니다. '딸깍'하고 싶어도 AI가 참조할 데이터 자체가 없었던 것이죠.

데이터가 없다면, AI에게 학습시킬 판단 로직부터 확보해야 했습니다. 그래서 먼저 사람에게 물어보기로 했습니다. 대기업과 외국계에서 영업 기획을 담당하시는 분들 중에서도 정말 탑이라 불리는 분들을 찾아가, "몇천억, 몇백억 규모의 매출을 어떻게 만드십니까"를 직접 여쭤봤습니다.

<출처: 채널톡 문희철 사업개발 리드 발표자료>

답변은 이랬습니다. 과거에 수주했거나 실주했던 히스토리, 갱신 여부 등을 종합해서 가중치를 매긴 뒤 일정 기준 이상의 건을 선별한다. 영업사원 한 명의 연봉 대비 몇 배수 이상의 ROI가 나와야 하는데, 모든 건을 다룰 수는 없기 때문에 우선순위를 정한다. 본질은 그게 전부라는 것이었습니다.

여기서 중요한 깨달음이 있었습니다. 이 접근을 AI 에이전트가 수행할 수 있도록 설계하면 되겠다는 것이었습니다.

그 다음으로 한 일은 유토피아를 정의하는 것이었습니다. 실현 가능성과 무관하게, 구현된다면 이상적일 방향을 먼저 그려보는 작업입니다. 크게 보면 필요한 데이터 소스는 세 가지였습니다. 첫째, 데스크 리서치로 확보할 수 있는 공개 정보. 둘째, 휴민트. 사람을 통해서만 얻을 수 있는 정보로, 비용이 가장 큰 영역입니다. 셋째, 우리 내부 데이터 웨어하우스에 축적된 데이터. 이 세 가지를 모아 정제하고 에이전트에 연결할 수 있다면, 앞서 영업 기획 임원이 말씀해주신 기준에 따라 우선순위와 전략을 도출할 수 있겠다는 큰 로직을 설계했습니다. 여기까지의 과정에 기술적인 이야기는 하나도 포함되지 않았습니다.

영업 AI 구축을 위한 도식 <출처: 채널톡 문희철 사업개발 리드 발표자료>

이후에는 본격적인 노가다 단계로 들어갑니다. 결국 가장 효과적인 방법은 ‘트라이얼 앤 에러(trial and error)’입니다. 산업공학이나 경영을 공부하신 분들은 아시겠지만, 최적해를 찾는 방법 중 가장 상위에 있는 것이 시행착오법입니다. 쉽게 말해 직접 부딪히며 패턴을 찾는 접근입니다.

저희는 고객사 중 가장 성공적이었던 탑 케이스를 전부 분해해봤습니다. 피터 드러커의 "뜻밖의 성공에 집중하라"는 원칙에 따라, 그 성공을 복제하고 재연하기 위해 원장 데이터를 분석하기 시작했습니다. 이 과정에서 데이터가 어떤 방식으로 축적되어야 하는지, 성공의 이면에 어떤 요인이 작동했는지를 체득하게 됐습니다.

그런데 데이터베이스에서 찾을 수 없는 정보도 있었습니다. 형지패션그룹을 예로 들어보겠습니다. 큰 지주사 형태의 그룹으로, 산하에 여러 계열사와 브랜드가 있고, 일부는 채널톡을 사용하고 일부는 사용하지 않습니다. 우리가 여기서 그룹 산하의 작은 브랜드 하나만 바라보면, 그룹 전체에 대한 매핑 지도를 그릴 수 없습니다. 영업 CRM에 길들여진 사고방식은 "저기 웹사이트가 있네, 저 브랜드를 공략해야겠다"는 방향으로 접근합니다. "형지패션그룹이라는 법인 단위로 전체 영업 계획을 설계하자"는 관점으로는 잘 넘어가지 못합니다. 이것이 툴을 잘못 도입했을 때의 위험입니다. 툴을 익힌다는 건 그 툴이 강요하는 사고방식을 내면화하는 일이기 때문입니다.

그래서 법인 단위 전체로 영업을 전개에 유용한 설계와 실험을 시작했습니다. 우리 팀원들의 리멤버 데이터를 CSV로 다운로드하고, 전사적으로 쓰는 세일즈포스 원장 데이터에 영향을 주지 않도록 (또 다른 영업 CRM 툴인) 에어테이블을 팀용으로 별도 구독한 뒤 그곳에 전부 넣어봤습니다. 솔직히 저는 에어테이블을 다룰 줄 모릅니다. 그런데 팀원이 초안을 만들고, 클로드에 MCP 접근 권한을 부여하니 테이블 구조를 알아서 설계해주더라고요.

클로드로 테이블 구조를 설계하고 대화 내용을 정리한 과정 <출처: 채널톡 문희철 사업개발 리드 발표자료>

한 가지 실험을 더 진행했습니다. 영업 CRM에 일일이 수기로 입력하는 방식이 비효율적이었기 때문에, 고객을 만나고 돌아온 뒤 그날의 대화 내용을 자연어로 클로드에 전달해봤습니다. 그러자 해당 내용에 맞는 필드를 스스로 구성해 입력해두는 모습을 확인했습니다. 혹시 음성으로도 가능할까 싶어 직접 말로 전달해보았고, 동일하게 작동했습니다. 데이터의 축적과 출력이 자동화되는 시대가 이미 현실이 되고 있다는 것을 체감한 순간이었습니다.

그렇다면 각 팀, 각 기능 조직이 자기 목적에 맞는 도구를 직접 만들어 쓸 수 있겠다는 생각이 들었습니다. 실제로 저희 사업개발 팀원이 앱을 하나 만들었는데, 솔직히 말씀드리면 그 앱 자체는 반드시 필요하지 않습니다. 클로드에 직접 물어봐도 동일한 결과를 얻을 수 있기 때문입니다. 앱이라는 도구적 프레임에 갇힐 필요가 없다는 점을, 이 실험을 통해 다시 한번 확인하게 됐습니다.

AX를 위한 DX, 리더가 지금 해야 할 일

지금까지 AI로 극단적 경영 가시성을 만들기 위한 세 가지 관점을 말씀드렸습니다. AI에 대한 관점, IT 인프라에 대한 관점, 그리고 이것을 활용하는 사람에 대한 관점. 이 관점들이 통합됐을 때, 리더는 AI를 통한 변화 관리와 혁신을 만들어낼 수 있습니다.

그런데 채널 팀이 앞선 AX 실험을 빠르게 실행할 수 있었던 배경이 있습니다. 저희의 환경은 중견이나 대기업 환경과는 다릅니다. 저희는 원래부터 SI를 하지 않았고, 온프레미스를 쓰지 않았습니다. 처음부터 AWS 퍼블릭 클라우드 기반으로 채널톡을 만들었고, 오픈 API를 운영해왔습니다. 그 환경이 있었기 때문에 빠르게 움직일 수 있었던 겁니다.

달리 말하면, 지금 해야 하는 건 AX일 수도 있지만, AX를 위한 DX가 먼저입니다. 예를 들어 저는 먼저 기존 온프레미스에 구축했던 데이터는 지금 어디에 있고, 어떻게 활용되고 있는지 묻고 싶습니다. 보통 이렇게 답하십니다. "데이터 많이 갖고 있어요." 다시 여쭤보겠습니다. “그 데이터를 극단적 경영 가시성을 위해, AI를 통해 지금 활용이 가능하십니까.” 대부분 안 될 겁니다.

이런 부분을 돕기 위해서 채널톡 또한 통합적인 ax의 관점을 제공하는 제품으로 거듭날 계획입니다.

극단적인 경영 가시성을 위해 AX 관점으로 제작중인 채널톡의 AI COS(chief of staff), notebook

30년치 데이터가 있다면, 좋은 겁니다. 하지만 그 데이터가 그 자체로 가치를 갖지는 않습니다. 사금을 캐고, 흔들고, 녹여야 금이 됩니다.

투입과 변환과 산출이라는 일의 전체 과정에서 봤을 때, 기획과 산출물 가공에 들어가는 시간은 체감상 30% 수준으로 줄었습니다. 그리고 그 시간에 저는 고객을 더 만나게 됐습니다. AI가 하지 못하는 일, 사람을 만나는 일에 집중할 수 있게 된 겁니다.

결국 돌아오는 건 같은 이야기입니다. AI에 대한 관점, IT 인프라에 대한 관점, 그리고 목적 조직의 사람에 대한 관점. 이 세 가지가 정립돼야 합니다. 감사합니다.

]]>

클로드 코드 제대로 써보신 분! '클코나잇 2' 발표자 모집

클로드 코드 현업 경험담을 나눠주실 발표자를 찾습니다!

콘텐츠 평균 조회수 1만 뷰 이상! 지난 2025년 10월부터 12월까지 요즘IT는 개발자와 비개발자의 클로드 코드 활용 사례를 알아보는 ‘클코나잇’ 세미나를 진행했습니다.

그리고 10인의 발표자분들과 함께한 경험담을 『클로드 코드로 일하기: 10인 실제 사례집』으로 엮어 많은 독자분들의 관심을 받았습니다. 저희도 이렇게 큰 관심은 예상치 못했던 만큼, 한 번으로 끝내기 아쉽다는 생각이 들었습니다.

여전히 클로드 코드에 대한 니즈는 계속되고 있기도 하고요. 그래서 요즘IT ‘클코나잇’이 시즌 2로 돌아옵니다!

시즌 2는 시즌1보다 한 걸음 더 들어갑니다. 시즌 1이 처음 써본 분들의 놀라움이었다면, 이번엔 클로드 코드와 제대로 씨름하며 만들어낸 진짜 노하우를 다룹니다. 개인 또는 팀(2인 이상)으로도 참여할 수 있고, 클로드 코드를 치열하게 써본 경험이라면, 어떤 이야기든 환영합니다.

오늘부터, 발표자로 합류하실 분을 모집합니다!

➡️발표자 신청하기

클로드 코드, 지금 어디까지 왔나요?

클로드 코드가 세상에 나온 지도 거의 1년이 됐습니다. 처음엔 "이게 되네?" 하며 신기해하던 시절이 있었죠. 그런데 지금은 분위기가 달라졌습니다. 하네스(Harness) 같은 도구가 엔지니어링 워크플로우의 표준처럼 자리를 잡아가고, 클로드 코드를 포함한 AI 코딩 도구는 이제 '써볼까'의 영역이 아니라 '어떻게 제대로 쓸까'의 영역으로 넘어왔습니다.

개발자뿐 아니라 PM, 기획자, 마케터도 클로드 코드로 자기 업무의 문제를 직접 해결하기 시작했고, 팀 단위로 도입하거나 조직 전체의 워크플로우를 바꾼 사례도 나오고 있습니다. 놀라움은 이미 지나갔습니다.

현실적으로

클로드 코드와 씨름하며 제대로 써본 사람이 할 수 있는 이야기
개인의 삽질기부터 팀 도입기
성공담뿐 아니라, 실패담과 현재 진행 중인 실험기

를 ‘클코나잇 시즌 2’에서 들어보려고 합니다.

이런 이야기 환영해요

잘 작동하는 에이전트 하나 만들겠다고 자기 도메인 지식을 쪼개고 쪼개본 비개발자(PM·기획자·마케터·편집자 등)의 분투기
팀 skill / 공용 커맨드 만들겠다고 회사 곳곳을 휩쓸고 다니며 표준을 세워본 이야기
바이브코더들을 위한 도구를 직접 만들어서 주변의 클로드 코드 사용을 매끄럽게 바꾼 이야기
내 업무 하나를 통째로 에이전트에게 넘겨본 이야기: 매일 하던 루틴을 완전히 대체해버린 경험담
내 업무를 에이전트가 빼앗아갈 줄 알았는데 현실은 그렇지 않다는 걸 깨닫게 된 이야기
CLAUDE.md, Skills, 서브에이전트, 훅, 컨텍스트 관리까지 파고들어 Claude Code를 내 워크플로우에 맞게 길들인 이야기
토큰 폭망, 컨텍스트 관리 실패, 엉뚱한 파일 삭제 등 진짜 아팠던 실패담
팀 도입 후 "쓰는 사람만 쓰는" 양극화를 풀어낸 정착기
클로드 코드로 이런 짓까지 해봤다! 싶은 극단적 사례

➡️ 클로드 코드로 부딪히고 깨지면서 만들어낸 여러분만의 방식을, 이제 나눠주세요!

발표 안내

발표 길이: 15분 내외
방식: 온라인 (Zoom)
날짜: 5월 중순쯤(협의 예정)

신청 방법

신청 기한: 4/17(금) ~ 4/28(화) 23:59분 마감
신청 방법: 신청 폼 작성 후 제출
신청자 중 서류 검토 후 간단한 개별 인터뷰(온라인)를 진행합니다.
최종 선정되신 분께는 5/6(수)에 개별 연락드립니다.

발표자에게 드리는 것

공식 소개: 요즘IT 웹사이트, 뉴스레터, SNS에서 발표자와 주제를 소개합니다. (개인 블로그·링크드인 등 링크도 함께)
기록 자산: 발표 내용은 영상·아티클로 제작되어, 발표자가 이후에도 공유·포트폴리오에 활용할 수 있습니다.
사례집 수익 배분: 발표 내용은 클코 나잇 사례집(PDF)으로 엮여 판매합니다. 판매 수익은 발표자분들과 함께 나눕니다.
디지털 배지: 요즘IT Speaker 배지(PNG/SVG)를 드립니다.
다음 기회 연결: 발표가 좋은 반응을 얻으면 후속 인터뷰나 다음 세미나로 이어집니다.

클코나잇은?

완벽한 강연이 아니라, 실무에서 써본 리얼 경험담을 나누는 자리예요.
클코나잇 시즌 1이 많은 관심을 받았고, 클로드 코드에 대한 궁금증과 수요는 계속되고 있습니다.
부담 갖지 말고, 편하게 “써본 자들의 밤”에 합류해주세요!

지원 TIP!
이 글을 '스크랩'해두시면 마이페이지에서 바로 확인할 수 있어요.
지금은 발표할 내용이 떠오르지 않아도, 클로드 코드를 쓰다 보면 아이디어가 분명 생길 겁니다.
글을 저장해두셨다가 생각이 정리되면, 마감일 전에 꼭 지원하세요! (로그인하면 스크랩 가능합니다.)

]]>

“이걸 누가 관리하나요?” GEO 자동화가 필요한 이유

GEO가 필요한데, 어떻게 적용할 것인가?

최근 GEO(Generative Engine Optimization)는 AI 검색 시대의 핵심 전략으로 빠르게 자리 잡고 있습니다. ChatGPT, Gemini, Perplexity와 같은 생성형 AI 서비스는 더 이상 단순히 웹 페이지 링크를 나열하지 않습니다. 대신 사용자의 질문에 대해 직접 “답변 문장”을 생성하며, 이 과정에서 특정 웹 콘텐츠를 인용하여 재구성합니다.

이로 따라 많은 기업이 기존의 SEO(Search Engine Optimization)뿐만 아니라, GEO를 위한 구조화 정보, 특히 JSON-LD 기반 태그를 활용해 자사 콘텐츠가 AI 답변에 포함되도록 최적화를 시도하고 있습니다. 그러나 실제 서비스 환경에서는 곧 하나의 근본적인 질문과 마주하게 됩니다.

“이걸 누가, 어떻게 계속 관리할 것인가?”

정적인 웹 사이트라면 한 번의 작업으로도 어느 정도 유지가 가능하겠지만 포털, 뉴스, 전자상거래, 커뮤니티, SaaS 문서 플랫폼처럼 콘텐츠가 지속적으로 생성되고 수정되며, 때로는 삭제되는 환경에서 웹 페이지마다 지속적으로 구조화 데이터를 관리하는 것이 사실상 불가능합니다.

이 글에서는 이러한 문제를 해결하기 위해 현재 사내에서 실험 중인 GEO 자동화 아키텍처를 기반으로, 다음 내용을 알아보고자 합니다.

GEO는 더 이상 전략 문제가 아니라 운영 문제이며, 자동화를 통해 확장할 수 있습니다.
AI를 활용하면 콘텐츠 분석부터 구조화 데이터 생성까지 전 과정을 자동화할 수 있습니다.
CDN 엣지와 서버리스(Serverless)를 결합하면 서비스 수정 없이 GEO를 적용할 수 있습니다.

GEO 전략을 실제 서비스에 적용할 때 마주하는 문제

GEO 개념 자체는 비교적 명확합니다. AI가 이해하기 쉬운 구조로 콘텐츠를 제공하고, 이를 통해 인용 가능성을 높이는 것입니다. 그러나 이를 실제 서비스에 적용하는 순간, 문제의 본질은 기술이 아니라 운영으로 이동합니다.

첫 번째 문제는 콘텐츠 규모입니다. 하루 수십, 수백 개의 페이지가 생성되는 서비스에서는 페이지마다 적절한 구조화 데이터를 작성하는 것이 불가능합니다. 특히 전자상거래 상품 페이지나 뉴스 기사처럼 데이터가 지속적으로 업데이트되는 환경에서는 메타데이터의 최신성을 유지하는 것 자체가 큰 비용으로 이어집니다.

두 번째 문제는 콘텐츠의 다양성입니다. 단순 블로그 글이 아니라 상품, 리뷰, FAQ, 기술 문서 등 다양한 형태의 콘텐츠가 존재할 때, 각각에 맞는 스키마 구조를 설계하고 유지하는 것도 쉽지 않습니다. 이는 단순 반복 작업이 아니라 도메인 이해를 요구하는 작업이기 때문입니다.

세 번째 문제는 조직 구조입니다. 대부분의 엔터프라이즈 환경에서는 웹 애플리케이션 코드 수정이 매우 엄격하게 통제됩니다. JSON-LD를 추가하는 단순 작업조차도 배포 승인 프로세스를 거쳐야 하며, 이로 따라 GEO 적용 속도는 조직 구조에 의해 제한됩니다.

네 번째 문제는 효과 측정입니다. 기존 SEO는 클릭 수, 클릭 확률, 순위 등 명확한 지표가 존재했습니다. 그러나 GEO는 “인용”이라는 새로운 지표를 중심으로 움직이며, 이는 정량화하기 어렵고 플랫폼별로 측정 방식도 다릅니다.

결국 GEO는 “어떻게 잘 만들 것인가”보다 “어떻게 지속적으로 운영하고 개선할 것인가”가 더 중요한 문제로 전환됩니다.

AI 기반 구조화 데이터 생성 파이프라인

위에서 언급한 문제의 해결을 위해 사내에서는 AI를 활용한 GEO 자동화 파이프라인을 실험적으로 구축하고 있습니다. 핵심 아이디어는 사람이 직접 GEO 태그를 작성하는 대신, AI가 콘텐츠를 읽고 구조화 데이터를 자동으로 생성하도록 만드는 것입니다.

GEO를 위한 태그 생성 및 제공 프로세스 <출처: 작가>

먼저 GEO 태그 생성 프로세스는 크게 네 단계로 구성됩니다.

첫 번째는 콘텐츠 수집 단계입니다. CMS, 내부 API, 혹은 HTML 크롤링을 통해 웹 페이지의 본문 자료를 수집합니다. 이때 중요한 것은 단순 HTML이 아니라 “의미 있는 텍스트”를 추출하는 것입니다.

두 번째는크롤링한 콘텐츠의 클렌징 및 MD 형식으로의 변환 단계입니다. HTML 내의 광고, 내비게이션, 불필요한 태그 등을 제거하고 LLM이 이해하기 쉬운 형태로 데이터를 변환합니다. 이 단계는 결과 품질에 매우 큰 영향을 미치면서도 사용하는 사용할 소비 토큰을 줄여주는 효과도 있습니다.

세 번째는 AI 분석 단계입니다. AI 모델은 MD 파일을 분석하여 제목, 작성자, 발행일, 핵심 주제, 키워드, 엔티티 등을 추출합니다. 특히 엔티티 추출은 GEO에서 매우 중요한 역할을 하며, 이는 AI가 콘텐츠를 “지식 단위”로 이해하는 데 도움을 줍니다.

네 번째는 구조화 데이터 생성 단계입니다. 추출된 정보를 기반으로 schema.org 표준에 맞는 JSON-LD를 생성하고, 이를 CDN 엣지 플랫폼 내의 KV 스토어 데이터베이스에 저장합니다.

다음은 특정 페이지 내용을 태그 생성 프로세스를 통해 저장한 JSON-LD의 예제 일부입니다.

{
  "@context": "https://schema.org",
  "@graph": [

    {
      "@type": "WebSite",
      "@id": "https://learn-ai.brandonkang.org/#website",
      "url": "https://learn-ai.brandonkang.org/",
      "name": "Learn AI",
      "description": "Learn AI is a practical knowledge hub covering AI fundamentals, large language models, GPU infrastructure, inference optimization, and Kubernetes-based AI systems.",
      "inLanguage": "en",
      "publisher": {
        "@id": "https://learn-ai.brandonkang.org/#person"
      }
    },

    {
      "@type": "Person",
      "@id": "https://learn-ai.brandonkang.org/#person",
      "name": "Brandon Kang",
      "url": "https://learn-ai.brandonkang.org/",
      "jobTitle": "Technical Solutions Architect",
      "knowsAbout": [
        "Artificial Intelligence",
        "Large Language Models",
        "GPU Computing",
        "AI Inference",
        "Kubernetes",
        "Cloud Infrastructure"
      ]
    },
…

여기서 중요한 사항은 “완벽성”이 아니라 “일관성”입니다. 일부 필드가 완벽하지 않더라도, 모든 페이지에 일정 수준의 구조화 데이터가 지속적으로 제공되는 것이 GEO 관점에서는 훨씬 더 중요합니다. 또한 이 파이프라인은 이벤트 기반 혹은 주기적 배치 방식으로 동작하여, 콘텐츠가 업데이트될 때 자동으로 메타데이터가 재생성됩니다. 이는 GEO를 단발성 작업이 아닌 데이터 파이프라인으로 전환하는 핵심 요소입니다.

CDN 엣지 기반 GEO 자동 삽입 아키텍처

이제 위에서 생성한 데이터를 실제 사용자에게 전달되는 HTML에 포함하는 GEO 태그 제공 프로세스가 필요합니다. 많은 기업에서는 원본 웹 서버나 CMS를 자주 수정하는 것이 쉽지 않습니다. 최종 테스트 및 검수와 배포 프로세스를 지켜야 하기 때문입니다. 그래서 CDN 플랫폼을 활용한 쉬운 배포 방식을 선택했습니다. 사실 이 방식 때문에 동일한 CDN의 엣지에 배포된 KV 스토어를 사용하여 데이터 이동 시간을 최소화한 것입니다.

AI 에이전트가 웹 페이지를 요청하면 CDN 엣지 서버에서 구동하는 서버리스 함수는 원본 HTML 응답을 가로채고, 사전에 생성된 JSON-LD 데이터를 가져와 해당 페이지의 <head> 태그 내 삽입하여 최종 전달합니다. 아래는 그 과정을 수행하는 함수 예제입니다.

#rewrite.js
import { HtmlRewritingStream } from 'html-rewriter';
import { httpRequest } from 'http-request';
import { createResponse } from 'create-response';
import { EdgeKV } from 'edgekv';

export async function responseProvider(request) {

  // 1. 원본 HTML 요청
  let htmlResponse = await httpRequest(request);
  if (!htmlResponse.ok) {
    return createResponse(500, {}, `Failed to fetch doc: ${htmlResponse.status}`);
  }

  // 2. EdgeKV 초기화
  const edgeKv = new EdgeKV({
    namespace: "geo",
    group: "jsonld"
  });

  // 3. URL → key
  const url = new URL(request.url);
  const key = url.pathname.replace(/\/$/, "") || "/";

  let jsonLd = null;

  try {
    jsonLd = await edgeKv.getText({ item: key });
  } catch (e) {
    jsonLd = null;
  }

  let rewriter = new HtmlRewritingStream();
  let injected = false;

  // 4. 기존 JSON-LD 체크 (중복 방지)
  rewriter.onElement('script[type="application/ld+json"]', el => {
    injected = true;
  });

  // 5. <head>에 GEO 블록 삽입
  rewriter.onElement('head', el => {
    if (!injected && jsonLd) {
      el.append(`
        <!-- GEO / Structured Data -->
        <script type="application/ld+json">${jsonLd}</script>
      `);
    }
  });

  // 6. 응답 반환
  return createResponse(200, {}, htmlResponse.body.pipeThrough(rewriter));
}

이렇게 수정된 HTML은 짧은 주기 동안 CDN 캐시에 저장되어 다음 AI 에이전트의 요청부터는 별도의 삽입 과정 없이 빠르게 전달됩니다. 원본 콘텐츠가 변경되는 경우 어차피 웹 사이트 관리자는 CDN 캐시를 무력화하는 명령을 수행하기에 새로운 GEO 태그가 적용될 것입니다.

최종적으로 페이지에 적용된 JSON-LD 태그<출처: 작가>

이 방식의 가장 큰 장점은 원본 시스템을 전혀 수정하지 않고, 사용자 주변에 가장 가까운 곳에 위치한 CDN에서 모든 작업을 수행한다는 점입니다. 결과적으로 원본 서버의 애플리케이션 코드, CMS, 데이터베이스에 영향을 주지 않으면서 GEO를 적용할 수 있습니다. 오히려 사용자와 가까운 위치에서 캐싱된 응답이 전달되기에 체감 성능이 개선되는 경우도 있습니다.

이 접근은 GEO를 “콘텐츠 레벨”이 아니라 “플랫폼 레벨”에서 적용하는 방식이라고 볼 수 있습니다. 즉, 웹 사이트 개발팀이 아니라 인프라팀에서 GEO 태그를 통제할 수 있게 되는 것입니다.

GEO 적용 이후 무엇을 확인해야 하는가?

GEO를 적용한 이후 가장 중요한 질문은 “그래서 효과가 있는가?”입니다.

GEO 적용 이후 구글 사이트에서의 테스트 예제 <출처: 작가>

현재 프로토타입에서는 이를 검증하기 위해 세 가지 관점에서 자료를 수집하고 있습니다.

첫 번째는 크롤링 패턴입니다. AI 에이전트들이 어떤 페이지에 얼마나 자주 접근하는지를 CDN 로그 기반으로 분석합니다. 이는 AI가 어떤 콘텐츠를 “관심 있게 보는지”를 간접적으로 보여줍니다.

두 번째는 인용 여부입니다. 특정 질문에 대해 AI가 자사 콘텐츠를 실제로 인용하는지를 반복적으로 테스트합니다. 이는 기존 SEO의 순위 확인과 유사하지만, 훨씬 더 실험적인 접근이 필요합니다.

세 번째는 사용자 행동 변화입니다. AI 기반 유입이 실제 트래픽 증가나 브랜드 인지도 향상으로 이어지는지를 분석합니다. 특히 AI 답변을 통한 간접 유입은 기존 분석 도구로는 포착하기 어려운 경우도 많아, 새로운 지표 설계가 필요합니다.

JSON-LD가 전부는 아니다

한 가지 중요한 사항은 GEO 태그가 적용되었다고 해서 반드시 AI 검색 결과에 바로 반영되는 것은 아니라는 점입니다. 구조화 데이터는 중요한 정보지만, 실제 AI 답변 생성 과정에서는 그것만으로 인용 여부가 결정되지 않습니다.

특히 많은 조직에서 GEO를 “JSON-LD를 잘 넣는 작업”으로 이해하는 경우가 있는데, 구조화 데이터는 콘텐츠의 의미를 명확하게 전달하는 데 도움을 주는 보조적인 신호일 뿐이며, AI가 실제로 인용할지를 결정하는 핵심 요소는 결국 콘텐츠 자체입니다. 검색 엔진의 AI는 구조화 데이터보다도 본문에 포함된 정보의 명확성, 질문과의 직접적인 연관성, 그리고 문장의 재사용 가능성을 더 중요하게 판단합니다.

반대로 생각해 보면, 구조화 데이터가 다소 부족하더라도, 특정 질문에 대해 명확하게 답하는 문장이 잘 정리되어 있고, 콘텐츠의 구조가 논리적으로 구성되어 있다면 AI는 해당 콘텐츠를 충분히 활용할 수 있습니다.

AEO, GEO 적용을 위한 모범 사례 <출처: 작가>

결국 중요한 것은 “AI가 이해하기 쉬운 콘텐츠를 만드는 것”입니다. 구조화 데이터는 그 과정을 돕는 도구일 뿐이며, 이를 과도하게 의존하기보다는 콘텐츠 자체의 품질과 구조를 먼저 설계하는 접근이 필요합니다. 이러한 구조를 고려하면, GEO에서 구조화된 메타데이터는 “필수 조건”이 아니라 “가속 장치”에 가깝습니다. 구조화 데이터가 잘 되어 있으면 AI가 콘텐츠를 더 빠르고 정확하게 이해할 수 있지만, 결국 인용 여부를 결정하는 것은 콘텐츠 자체의 품질과 맥락 적합성입니다.

결과적으로 GEO는 더 이상 엔지니어링 팀만의 영역이 아닙니다. 구조화 데이터를 적용하는 기술적인 작업을 넘어, 웹 콘텐츠를 기획하고 작성하는 단계부터 AI가 이해하기 쉬운 형태로 정보를 구성하는 것이 중요해졌습니다. 즉, 콘텐츠 제작자 역시 GEO가 선호하는 정보 구조와 서술 방식, 그리고 문맥(Context)을 고려해야 하는 시대가 된 것입니다.

이는 단순히 키워드를 잘 배치하는 수준을 넘어, 질문에 직접적으로 답할 수 있는 문장 구조, 명확한 정보 단위, 그리고 AI가 재사용하기 쉬운 콘텐츠 형태를 만드는 방향으로 콘텐츠 전략 자체가 변화하고 있음을 의미합니다. 좀 더 자세한 내용은 기존 요즘IT 글 “AI 시대 콘텐츠 생존 전략: GEO를 위한 SIFT 프레임워크”를 참고하시기 바랍니다.

GEO는 이제 콘텐츠 전략을 넘어선 플랫폼 전략

AI 검색 환경에서는 어떤 콘텐츠가 “검색되는가”가 아니라, 어떤 콘텐츠가 “인용되는가”가 더 중요한 시대가 되었습니다. 콘텐츠 규모가 커질수록 이를 수작업으로 관리하는 방식은 한계를 가질 수밖에 없습니다. 따라서 앞으로 기업이 고민해야 할 질문은 GEO를 어떻게 자동화하고 운영할 것인가로 바뀔 것입니다.

본문에서 소개한 AI 기반 콘텐츠 분석, 서버리스 컴퓨팅, CDN 엣지 아키텍처를 결합한 접근은 이러한 문제를 해결할 수 있는 현실적인 방법 중 하나입니다. 이러한 흐름에 맞춰 구조화 데이터 생성, 콘텐츠 최적화, AI 인용 분석을 자동화하는 전문 도구와 서비스들이 속속 등장하고 있으며, GEO를 하나의 운영 체계로 관리하려는 시도도 점점 늘어나고 있습니다. 앞으로는 단순히 콘텐츠를 잘 만드는 것을 넘어, AI가 이해하고 활용하기 좋은 형태로 콘텐츠를 설계하고 이를 지속적으로 최적화하는 역량이 기업 경쟁력의 중요한 기준이 될 겁니다.

]]>

16년 된 백준(BOJ)이 문을 닫습니다

안녕하세요, 요즘 프로덕트 메이커입니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: Claude Code Routines - 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능
참고할 것: BOJ(백준 온라인 저지) - 16년간 한국 개발자와 함께한 백준이 문을 닫습니다
적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

<출처: claude.ai>

1. 써볼 것: 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능

Claude Code에 Routines라는 기능이 추가됐습니다. 프롬프트, 레포지토리, 커넥터를 한 번 설정해두면 스케줄이나 GitHub 이벤트에 맞춰 자동으로 실행되는 기능인데요. Anthropic 클라우드에서 돌아가기 때문에 노트북을 닫아도 작업이 계속됩니다. 아직 research preview 단계이지만, Claude Code를 쓰는 개발자들 사이에서 관심을 받고 있습니다.

무슨 문제를 해결해 주나요?

코딩 에이전트는 지금까지 사람이 앉아서 지시하고 결과를 확인하는 방식이었습니다. Claude Code든 Cursor든, 내가 대화창에 뭔가를 입력해야 일이 시작되죠. PR이 올라올 때마다 리뷰를 시키려면 그때마다 직접 세션을 열어야 했고, 매일 아침 이슈를 정리하려면 매번 같은 프롬프트를 붙여넣어야 했습니다. Routines는 이 반복을 자동화하는 기능이죠. 한 번 설정해두면 정해진 시간에, 또는 특정 이벤트가 발생할 때 알아서 실행됩니다.

어떻게 쓰나요?

claude.ai/code/routines에서 만들 수 있고, Claude Code CLI에서 /schedule 명령어로도 생성할 수 있습니다. 설정할 때 필요한 건 세 가지입니다. 실행할 프롬프트, 작업할 GitHub 레포지토리, 그리고 트리거 조건입니다.

트리거는 세 종류를 지원합니다.

스케줄: 매시간, 매일, 평일, 매주 등 주기를 정할 수 있습니다. 커스텀 cron 표현식도 가능하고요. 최소 간격은 1시간입니다.
GitHub 이벤트: PR이 열리거나, 릴리스가 생성되거나 할 때 자동으로 실행됩니다. PR 작성자, 제목, 라벨, 드래프트 여부 등으로 필터링도 가능합니다.
API 호출: HTTP POST 요청으로 실행할 수 있어서, 모니터링 도구나 배포 파이프라인과 연결할 수 있습니다.

하나의 Routine에 트리거를 여러 개 붙일 수도 있습니다. 예를 들어 PR 리뷰 Routine을 만들어서, 새 PR이 열릴 때도 실행되고 매일 밤에도 실행되게 설정할 수 있죠. 실행 결과는 일반 Claude Code 세션처럼 열어볼 수 있습니다. 뭘 했는지 확인하고, 변경 사항을 리뷰하고, PR을 만들 수도 있고요.

공식 문서에서 제시하는 활용 예시를 보면, 어떤 작업에 쓸 수 있는지 감이 옵니다. 매일 밤 이슈 트래커를 읽고 라벨을 붙이고 담당자를 배정한 뒤 Slack으로 요약을 보내는 백로그 관리, 모니터링 알림이 오면 스택 트레이스를 분석하고 최근 커밋과 연결해서 수정 PR 초안을 만드는 알림 분류, 병합된 PR을 스캔해서 API가 바뀐 문서를 찾아내고 업데이트 PR을 여는 문서 관리 같은 것들입니다.

다만 Routines는 완전 자율 모드로 실행됩니다. 중간에 승인 프롬프트가 뜨지 않아요. 셸 명령어를 실행하고, 레포에 커밋된 스킬을 쓰고, 연결된 커넥터(Slack, Linear 등)를 통해 외부 서비스에도 접근합니다. 그래서 필요한 레포와 커넥터만 연결하는 게 중요합니다. 그리고 아직 research preview라서 동작 방식이나 한도가 바뀔 수 있습니다. Pro, Max, Team, Enterprise 플랜에서 쓸 수 있고, 계정당 일일 실행 횟수에 제한이 있습니다.

누구에게 좋을까요?
Claude Code를 이미 쓰고 있으면서, PR 리뷰나 이슈 정리 같은 반복 작업을 자동화하고 싶은 개발자
CI/CD 파이프라인에 AI 코드 리뷰나 배포 후 검증을 붙이고 싶은 팀
매일 아침 또는 매주 돌아오는 정형화된 코드 작업이 있는 사람

<출처: BOJ(백준 온라인 저지)>

2. 참고할 것: 16년간 한국 개발자와 함께한 백준이 문을 닫습니다

BOJ(백준 온라인 저지)가 4월 28일자로 서비스를 종료합니다. 운영자 최백준 님이 직접 게시판에 올린 공지인데요. 한국 개발자 커뮤니티에서 즉시 화제가 됐습니다. 2010년부터 16년간 운영된 이 사이트는 3만 4천 개 이상의 프로그래밍 문제와 73개 언어 채점을 지원하며, 한국에서 알고리즘을 공부하는 사람이라면 거의 다 거쳐갔다고 보아도 무방한 곳입니다. 많은 개발자의 성장을 도운 BOJ가 이제는 추억 속의 사이트가 된다고 합니다.

운영자에게 인사를 남기는 사용자들
<출처: BOJ(백준 온라인 저지)>

BOJ가 어떤 곳이었나요?

한국 IT 업계에 있는 사람이라면 백준을 한 번쯤은 들어봤을 겁니다. 개발자가 아니더라도, 코딩 테스트를 준비하는 후배나 동료가 있다면 백준이라는 이름은 익숙하죠. 알고리즘 문제를 풀고 온라인으로 채점받는 사이트인데, 단순히 문제만 있는 건 아니었습니다. 단계별 학습, 문제집, 그룹, 대회, 게시판까지 알고리즘을 중심으로 한 학습 생태계가 만들어져 있었습니다.

solved.ac라는 서드파티 서비스가 문제 난이도와 사용자 티어를 매기면서 게이미피케이션 요소까지 더해졌고요. 백준 티어가 개발자들 사이에서 실력의 지표처럼 쓰이기도 했습니다. 한국 기업의 코딩 테스트 문화와 함께 성장한 플랫폼이라고 볼 수 있습니다.

무엇이 남고, 무엇이 사라지나요?

종료 공지에 따르면, 서비스 종료 시점에 문제 데이터, 제출 기록, 대회 정보는 보존됩니다. 나머지 데이터는 삭제될 예정이고요. 최백준 님은 완전히 사라지기보다는 문제만이라도 다시 볼 수 있는 형태로 돌아올 수 있도록 고민하고 있다고 밝혔습니다. 상황이 달라지면 서비스를 재개할 가능성도 열어두고 있다고요. 서비스 종료 전까지는 정상 이용이 가능하지만, 문제집이나 그룹 생성 같은 일부 기능은 제한될 수 있다고 합니다.

무엇을 얻어가야 하나요?

한 사람이 시작한 사이드 프로젝트가 16년간 업계 인프라 역할을 했다는 것 자체가 큰 의미가 있는 사례라고 생각합니다. 마지막까지 문제 데이터와 제출 기록은 보존하는 결정을 내린 부분에서, 운영자가 생각하는 핵심 가치를 엿볼 수 있을 것 같습니다.

종료 소식을 접한 커뮤니티 반응도 인상적이었는데요. 시대가 바뀌었고 코딩 테스트의 의미가 예전 같지 않다는 목소리가 꽤 있었습니다. AI 코딩 에이전트가 알고리즘 문제를 풀 수 있는 시대에, 알고리즘 문제 풀이 능력이 개발자 역량의 기준이 될 수 있느냐는 질문이죠. 반면에 코드가 무엇을 하는지 이해하는 기초 체력은 여전히 필요하다는 반론도 있었고요. 정답이 있는 논쟁은 아니지만, 이번 주 적용해볼 것에서 다루는 사례를 보면 이 질문이 왜 중요한지 조금 더 구체적으로 느껴질 겁니다.

<출처: tobru.ch>

3. 적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

스위스의 보안 엔지니어 Tobias Brunner가 3월 28일 블로그에 올린 글입니다. 자기가 직접 겪은 바이브 코딩 호러 스토리라는 제목인데요. 보안 커뮤니티에서 바이브 코딩의 실제 위험을 보여주는 사례로 공유되고 있습니다. AI 코딩 도구로 앱을 만드는 사람이 늘어나는 지금, 무엇이 빠지면 어떤 일이 벌어지는지를 보여주는 글입니다.

무슨 일이 벌어졌나요?

Tobias Brunner가 병원에 갔는데, 접수 담당자가 요즘 AI로 누구나 소프트웨어를 만들 수 있다는 영상을 봤다고 하면서 직접 환자 관리 시스템을 만들었다고 했다고 합니다. 기존에 쓰던 환자 데이터를 전부 가져와서 새 앱에 넣고, 인터넷에 배포하고, 진료 중 대화를 녹음해서 AI 서비스 두 곳으로 보내 자동 요약하는 기능까지 만들었다고요.

Brunner가 며칠 뒤 이 앱을 살펴봤더니, 30분 만에 전체 환자 데이터에 읽기·쓰기 권한을 확보할 수 있었다고 합니다. 모든 데이터가 암호화 없이 인터넷에 열려 있었던 거죠. 바로 담당자에게 알렸더니, 돌아온 답변은 AI가 자동 생성한 감사 메시지였다고 합니다. 기본 인증을 추가하고 접근 키를 교체했다는 내용이었는데, Brunner는 이 사람이 자기가 뭘 만들었는지 이해하지 못하고 있다고 봤습니다.

기술적으로 무엇이 빠져 있었나요?

Brunner가 설명하는 기술적 구조를 보면, 앱 전체가 HTML 파일 하나였다고 합니다. JavaScript, CSS, 모든 구조가 인라인으로 들어가 있는 단일 파일이었고요.

백엔드는 접근 제어가 전혀 설정되지 않은 관리형 데이터베이스 서비스를 썼다고 합니다. 행 수준 보안(row-level security)도 없었고요. 접근 제어 로직이라고 할 수 있는 건 클라이언트 측 JavaScript에만 있었는데, 이건 브라우저에서만 작동하는 거라 curl 명령어 한 줄이면 데이터에 바로 접근 가능한 상태였다고요.

음성 녹음 파일은 외부 AI API로 직접 전송되어 전사와 요약 처리가 됐고, 데이터는 미국 서버에 저장되어 있었는데 데이터 처리 계약(DPA) 없이 운영되고 있었다고 합니다. 환자에게 이런 데이터 처리에 대한 사전 고지도 없었고요. Brunner는 이 행위가 스위스 데이터 보호법(nDSG)과 직업상 비밀 유지 의무를 여러 조항에서 위반했을 가능성이 높다고 판단했습니다.

왜 이런 일이 생기는 건가요?

이 사례에서 빠진 건 코딩 능력이 아닙니다. AI 코딩 에이전트가 코드를 만들어주는 건 잘 했으니까요. 앱은 돌아갔고, 기능도 잘 작동했을 겁니다. 빠진 건 코드가 어떻게 작동하는지에 대한 이해였습니다. 클라이언트 측 접근 제어가 왜 보안이 아닌지, 데이터베이스에 접근 권한을 왜 설정해야 하는지, 환자 데이터를 외부 서비스로 보낼 때 어떤 법적 요건이 필요한지. 이런 판단은 AI 코딩 에이전트가 알아서 해주지 않습니다. 코드를 생성하는 것과 그 코드가 안전한지 판단하는 것은 완전히 다른 영역이죠.

Brunner 본인도 AI 코딩 에이전트를 쓴다고 밝혔습니다. 다만 자기는 코드를 읽을 수 있고, 소프트웨어 아키텍처를 이해하고 있기 때문에 쓸 수 있는 거라고요. 분위기에 취해서 만드는 것(vibing away)만으로는 안전한 결과가 나오지 않는다는 게 그의 결론입니다.

적용해볼 질문

내가 AI 코딩 도구로 만든 코드에서 접근 제어가 서버 측에 있는가, 클라이언트 측에만 있는가?
외부 API로 데이터를 보내고 있다면, 어떤 데이터가 어디로 가는지 파악하고 있는가?
AI가 만들어준 코드의 아키텍처를 내가 설명할 수 있는가?

실행해볼 수 있는 것

AI 코딩 에이전트로 만든 프로젝트가 있다면, 백엔드 접근 제어가 제대로 설정되어 있는지 확인해보기. 클라이언트 측 JavaScript에만 의존하고 있다면 서버 측 인증을 추가하기.
외부 API를 쓰고 있다면, 어떤 데이터가 어디로 전송되는지 한 번 정리해보기. 민감한 데이터가 포함되어 있다면 데이터 처리 계약이 필요한지 확인하기.
AI가 생성한 코드를 배포하기 전에, 최소한 보안 체크리스트 하나를 통과시키는 습관 만들기. 인증, 암호화, 접근 권한, 데이터 흐름

이 네 가지만 확인해도 이 사례 같은 사고는 막을 수 있습니다.

오늘 내용, 이렇게 적용해보세요

AI 에이전트에게 반복 작업을 맡기되, 맡기는 작업의 범위와 권한을 명확히 정해두기. Routines처럼 자동으로 돌아가는 작업일수록 어떤 레포에 접근하고 어떤 서비스에 연결되는지 꼭 확인하기.
AI가 만든 코드를 배포하기 전에, 보안 관점에서 한 번 훑어보는 습관 만들기. 인증이 서버 측에 있는지, 데이터가 어디로 가는지, 접근 권한이 적절한지. 이 세 가지만 확인해도 많은 사고를 막을 수 있습니다. (AI 시대에도 코드를 읽는 능력은 여전히 기반입니다. AI가 생성한 코드가 무엇을 하는지 설명할 수 없다면, 그건 아직 배포할 준비가 안 된 겁니다)

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정을 부탁드립니다!

]]>

왜 개인 위키는 실패할까? 안드레 카파시의 ‘LLM 위키’

‘LLM 위키’로 지식을 복리로 쌓는 방법

여러분도 뭔가를 읽고 나서, "어? 이거 나중에 써먹어야지"라고 생각한 적이 있을 겁니다. 아티클, 뉴스레터, 팟캐스트, 어딘가에 적어둔 메모 등 말이죠. 그런데 나중이 되면 어디 있는지 모르거나, 찾아도 맥락이 기억나지 않습니다. 그래서 이걸 해결하고자 개인 위키를 만드는 사람들이 있습니다. 개인 위키는 말 그대로 개인 지식의 디지털 저장소로, 내가 읽고 배운 것들을 한 곳에 쌓아두는 문서 공간입니다. 노션이나 옵시디언 같은 툴에 주제별 페이지를 만들고, 내 지식들을 한 곳에 정리해 두는 방식이죠.

저도 몇 번이나 개인 위키 제작을 시도해 봤는데요. 처음엔 꽤 공들여 세팅해서 그럴듯했습니다. 페이지 만들고, 태그를 붙이고, 데이터베이스도 구성했죠. 그런데 한두 달쯤 지났을까, 같은 자리에서 막히기 시작했습니다. 새 정보를 넣으려고 열면 이 내용이 어떤 태그에 붙어있는지부터 기억해 내야 했고, 정보 업데이트를 위해선 이전에 적어둔 것들과 어떤 부분이 겹치는지 확인해야 했습니다.

또 새로 추가할 때마다 기존 내용을 업데이트하고, 교차 참조도 달아야 했죠. 이 과정이 30분을 넘어가기 시작하면, 그냥 어느 순간부터 안 쓰게 되고 그렇게 제 위키는 조용히 멈춰졌습니다. 언제부턴가 열지도 않게 됐죠. 결국 작심삼일처럼 스스로의 의지가 부족한 거라고 생각했습니다. 그런데 안드레 카파시(Andrej Karpathy, OpenAI 창립 멤버)가 최근 공개한 LLM 위키 아이디어 문서를 읽으면서, 다른 생각이 들었습니다. 걸림돌은 게으름이 아니라, 정리를 계속 유지하는 데 들어가는 비용이 너무 컸던 겁니다.

부담이 쌓이면 위키는 멈춘다

안드레 카파시는 최근 "코드보다 개인 지식 저장소 구축에 더 많은 AI 토큰을 쓰고 있다"고 말하며, 자신이 실험 중인 LLM-Wiki를 공개했습니다.

<출처: karpathy/llm-wiki.md>

그는 사람들이 위키를 포기하는 건 지식이 부족해서가 아니라, 유지 관리 비용이 가치보다 빠르게 증가하기 때문이라고 말했는데요. 보통 교차 참조 업데이트, 요약 최신화, 수십 페이지에 걸친 일관성 유지를 ‘북키핑(bookkeeping)’이라고 부릅니다. 우리가 읽고 생각하고 연결하는 것까진 즐거워하는데, 이미 적어둔 내용과 새 내용이 어디서 겹치는지 찾고, 기존 페이지를 하나하나 업데이트하는 건 다른 종류의 일이기 때문이죠. 그 지루한 일이 쌓이면, 결국 위키 관리를 포기하게 되고요.

그러나 인간과 달리 LLM은 지루함을 모릅니다. 교차 참조 업데이트를 잊지 않고, 새 소스 하나를 넣으면 관련된 15개 페이지를 한 번에 처리할 수 있습니다. 북키핑 비용이 거의 0에 가까워진다면, 위키를 유지할 수 있는 조건이 됩니다.

그런데 이 아이디어는 우리가 AI를 활용하는 일반적인 방식과 꽤 다릅니다. 보통 ChatGPT에 파일을 올리거나, NotebookLM을 쓸 때는 RAG(Retrieval-Augmented Generation) 방식을 사용합니다. 이건 질문할 때마다 원문에서 관련 내용을 다시 찾아 답하는 방식인데요. 예를 들어, 도서관 사서에 비유하면, 매번 서가에서 책을 꺼내 읽어주는 것과 비슷합니다. 찾아주긴 하지만 지식이 어딘가에 정리되어 쌓이지는 않습니다.

LLM-Wiki는 다릅니다. 내가 읽은 것들을 직접 요약·정리해 주는 비서에 가깝습니다. LLM이 원문을 읽고 마크다운 위키를 직접 쓰고, 새 소스가 들어올 때마다 기존 위키를 업데이트하면서 지식이 쌓입니다. 카파시의 표현을 빌려 표현하자면 "복리 축적형 결과물"인 셈이죠.

내가 소스를 넣으면 LLM이 위키를 쌓는다

<출처: 작가 제작, notebooklm>

구조는 다음과 같은 세 레이어로 이루어집니다.

첫 번째는 원문 소스입니다. 내가 모은 아티클, 논문, 이미지, 데이터 파일이죠. LLM이 읽기만 하고 수정하지 않는 레이어로, 진실의 원천이 됩니다.
두 번째는 위키입니다. LLM이 직접 생성하고 관리하는 마크다운 파일 모음입니다. 요약, 개념 정리, 비교/분석이 여기 쌓이고, 옵시디언 같은 도구로 열어두면 LLM이 편집하는 내용을 실시간으로 볼 수 있습니다. 카파시는 옵시디언은 IDE, LLM은 프로그래머, 위키는 코드베이스라고 비유했습니다.
세 번째는 스키마(schema)입니다. LLM에게 위키의 구조와 컨벤션, 워크플로를 알려주는 설정 문서인데, 이 파일이 있어야 LLM이 일반 챗봇이 아닌 체계적인 위키 관리자로 동작합니다. 처음엔 짧아도 되고, 사용자와 LLM이 쓰면서 함께 다듬어가는 문서이기도 합니다.

그리고 실제 작업은 인제스트(Ingest), 쿼리(Query), 린트(Lint) 세 가지로 나뉩니다. 먼저 소스를 새로 추가할 때 LLM이 읽고 위키를 업데이트하는 인제스트, 위키를 대상으로 질문하면 관련 페이지를 찾아 답을 만들어주는 쿼리, 주기적으로 페이지 간 모순이나 고립된 페이지를 점검하는 게 린트입니다. 쿼리에서 잘 만들어진 답변은 위키에 새 페이지로 저장되기도 합니다. 탐색 자체가 쌓이는 거죠.

제가 이 구조에서 가장 마음에 든 건 데이터 소유권입니다. "쓸수록 알아서 좋아진다"는 AI 개인화 방식의 경우, 내 데이터가 어디에 어떻게 저장되는지 보이지 않습니다. 반면, LLM-Wiki는 로컬 파일로 존재해서 AI가 무엇을 알고 모르는지 사람이 직접 확인하고 수정할 수 있는데요. Claude든 다른 모델이든 원하는 걸 연결할 수 있고, 특정 업체에 묶이지도 않습니다.

AI가 정리까지 해주면, 생각은 누가 하지?

여기까지 글을 쓰다 보니, 문득 이런 생각이 들었습니다. AI가 정리까지 해주면, 내가 해야 할 생각도 AI에게 넘기는 건 아닐까요? 처음 안드레 카파시의 LLM 위키가 Hacker News에 공유됐을 때, 댓글에서 비슷한 경험을 털어놓은 사람이 있었습니다. 그는 번아웃으로 집중력이 떨어졌을 때 많은 작업을 에이전트에 위임했는데, 새로운 형태의 기술 부채가 생겼고, "뇌의 일부가 비어 있는 느낌"이 든다고 말했습니다.

그는 왜 그런 느낌을 받았을까요? 직접 정리하는 과정에는 LLM이 대신할 수 없는 게 있습니다. 이 개념이 저 개념과 어떻게 닿는지 깨닫는 순간, 예전에 읽은 내용이 지금 읽는 것과 어떻게 연결되는지 느끼는 순간, 저는 그 순간들이 학습의 본체에 가깝다고 생각하는데요. 이렇게 스스로 사고하는 과정이 빠지면, 위키는 쌓여도 내 머릿속은 비어가는 역설이 생길 수 있습니다.

물론 카파시가 LLM에게 맡기자는 건, 사고의 과정이 아닙니다. 북키핑과 합성은 다르거든요. 교차 참조를 업데이트하고 모순을 표시하고 파일을 일관성 있게 유지하는 건 행정 작업이고, 여러 소스를 읽고 그것들이 무엇을 의미하는지 스스로 연결하는 건 사고 작업입니다. LLM에게 위임하는 건 전자죠. 무엇을 읽을지, 무엇을 물을지는 여전히 사람이 결정해야 합니다.

위키 관리 작업이 쌓이다 보면, 정작 읽고 연결하고 이해하는 데 쓸 시간과 에너지가 남지 않습니다. 따라서 LLM-Wiki는 그 관리를 LLM에 넘겨, 사람은 생각에만 집중할 수 있게 하는 시도에 가깝습니다.

물론 현실적인 위험도 있습니다. 위키가 커질수록 LLM이 전체를 일관성 있게 유지하기 어려워지고, 스키마가 잘 설계되지 않으면 어느 순간부터 LLM도 사람도 전체 구조를 파악하지 못하게 되거든요. 해커 뉴스 댓글에는 "일정 복잡도를 넘으면 에이전트가 위키를 유지하지 못한다"는 경고도 있었습니다.

결국 처음부터 모든 걸 담으려 하지 말고, 좁은 도메인부터 시작하는 것이 이 위험을 줄일 수 있는 현실적인 방법입니다.

1) 하나의 주제를 정합니다

만약 여러분이 AI와 지식 관리를 공부하고 있다면 그 주제만, 특정 기술 영역을 파고 있다면 그 영역만 팝니다. 처음부터 모든 지식을 담으려 하면 스키마 설계가 복잡해지고, 일관성을 유지하기 어려워집니다. 좁게 시작해서 구조를 익히는 게 먼저입니다.

2) 스키마 파일을 먼저 씁니다

LLM에게 "이 위키는 어떤 구조로 쓸 건지, 어떤 형식의 페이지를 만들 건지, 새 소스가 들어왔을 때 무엇을 업데이트해야 하는지"를 설명하는 파일입니다. 처음엔 짧아도 되고, 쓰면서 함께 다듬어가면 됩니다.

3) 아티클 하나를 넣어보세요

LLM에게 읽고 위키를 만들어달라고 하면서, 어떤 페이지들이 생기는지 보고 스키마를 다듬는 과정이 진짜 세팅입니다. 이 과정에서 꼭 옵시디언 같은 툴이 필요하진 않습니다. 마크다운 파일이 생기는 폴더 아무 데서나 시작할 수 있고, 위키가 수십 페이지를 넘어가면 그때 옵시디언 그래프 뷰가 연결 구조를 파악하는 데 유용합니다. 웹 기사를 마크다운으로 바꿔주는 브라우저 확장(Obsidian Web Clipper)을 쓰면, 소스를 빠르게 추가하는 루틴도 잡을 수 있습니다.

마치며: 유지 관리 비용이 낮아지면 지식은 복리로 쌓인다

카파시는 이 아이디어가 1945년 Vannevar Bush가 제안한 Memex에서 이어진다고 했습니다. Memex는 개인이 직접 큐레이션하고, 문서 간 연결이 문서 자체만큼 가치 있는 지식 저장소였습니다. 그런데 Bush가 끝내 풀지 못한 문제가 하나 있었습니다. 바로 “이걸 누가 유지 관리하느냐”에 대한 것이죠. 이제 80년이 지나, 그 자리에 LLM이 들어왔습니다.

카파시가 말한 “에이전트 활용 능력은 21세기의 핵심 스킬”은 단순히 에이전트를 쓰는 능력만을 뜻하지는 않는다고 생각합니다. 오히려 중요한 것은 무엇을 에이전트에게 맡기고, 무엇을 스스로 판단할지 가르는 능력입니다. 북키핑은 맡기더라도, 무엇을 읽고 무엇을 물을지는 내가 결정해야 합니다. 결국 그 판단의 질이 위키의 깊이로 이어질 거고요. 이 글을 쓰고 나니 오랜만에 노션 위키를 다시 열어봐야겠다는 생각이 드는데요. 여러분도 나만의 위키를 갖고 계신가요?

<참고>

]]>