요즘IT » 피드

AI 오피스: 24시간 깨어 있는 에이전트에게 영혼 불어넣기

[My Office AI Town 제작기 1회]
심즈의 AI 버전? 24시간 깨어 있는 AI 오피스의 매력과 에이전트에게 영혼 불어넣기

시리즈 소개: Flutter, Supabase, Gemini LLM을 활용해 1인 개발로 'AI 오피스 시뮬레이션'을 구축한 과정을 총 4회에 걸쳐 공유합니다. 기획부터 비용 폭탄, 픽셀 UI, 수익화까지 삽질의 기록을 가감 없이 담았습니다.

미리 요점만 콕 집어보면?

My Office AI Town은 AI 직원(에이전트)들이 고정된 스크립트 없이 실시간으로 판단하고 대화하는 오피스 시뮬레이션입니다.
직원(에이전트)의 레이어별 페르소나 구조 설계 - 기억(Memory) 시스템이 에이전트를 사람답게 만드는 핵심입니다.
AI가 아무리 발전해도 결코 사람을 대체할 수 없는 것, 그것은 바로 무엇을 어떻게 할지를 결정하는 의사결정의 '판단력'입니다.

‘My Office AI Town’을 만들다

<출처: 작가>

다들 '심즈(The Sims)'를 아시나요? 나를 닮은, 혹은 내가 원하는 페르소나를 가진 캐릭터들이 자율적으로 행동하는 것을 지켜보는 것만으로도 묘한 도파민이 뿜어져 나오는 그 게임 말입니다.

제가 만든 ‘My Office AI Town’은 이 고전적인 재미에 최신 LLM(대규모 언어 모델) 기술을 얹었습니다. 기존 시뮬레이션 게임들이 미리 짜인 스크립트에 따라 움직였다면, My Office AI Town의 AI 직원(에이전트)들은 매 순간 실시간으로 변화하는 맥락(Context) 속에서 스스로 판단하고 대화를 나눕니다.

각본 없는 AI 에이전트들의 사내 드라마

My Office AI Town의 사무실에서는 현실에서 일어나는 것과 같은 다양한 일들이 일어납니다.

은근한 썸과 로맨스: 탕비실에서 마주친 두 에이전트 사이에 핑크빛 기류가 흐르고, 이는 스트레스 수치를 낮추는 긍정적인 효과로 이어집니다.
날 선 갈등과 뒷담화: 프로젝트 마감을 앞두고 팀장과 팀원 사이에 팽팽한 긴장감이 흐릅니다. 단체 메신저 방에는 상사의 업무 스타일에 대한 은밀한 뒷담화가 올라오기도 하고요.
사용자의 개입: 사용자는 이 모든 과정을 지켜보다가 가장 힘들어하는 직원(에이전트)에게 '아이스 아메리카노'를 선물합니다. "아, 누가 커피를? 정말 감사합니다!"라는 반응과 함께 스트레스 수치가 깎이는 모습을 보는 것, 이게 바로 이 시뮬레이션의 진짜 재미지 않을까요?

이 아이디어는 스탠퍼드-구글 연구진이 발표한 '제너레이티브 에이전트(Generative Agents)' 논문에서 시작됐습니다. 25명의 AI 캐릭터가 '스몰빌'이라는 마을에서 파티를 열고, 선거를 치르고, 자발적으로 대화하는 모습은 그 자체로 충격이었죠. 그때 저는 생각했습니다. 이걸 '사무실'이라는 좁고 밀도 높은 공간에 적용한다면? 훨씬 더 현실적이고 재미있는 오피스 드라마가 나오지 않을까?

비개발자인 저에게 에이전트 시뮬레이션은 거대한 도전이었습니다. 2D 픽셀 맵 렌더링, 경로 계산 알고리즘, 수천 개의 대화 로그 실시간 처리까지. 혼자서는 도무지 엄두가 나지 않는 작업이었습니다. 그래서 AI 친구들과 함께(Vibe Coding) 만들어 보기로 했습니다.

데모 사이트

(*해당 서비스 특성상 PC 환경에서 확인 부탁드립니다. 모바일에서는 기능이 제한되어 있습니다.)

Vibe Coding: 코드가 아닌 '맥락'을 설계하는 기획법

Vibe Coding은 단순히 "AI에게 코드 짜달라고 하는 것"이 아닙니다. 나의 아이디어와 의도를 가장 효율적으로 AI에게 전달하는 협업 방식입니다. 핵심은 'What'이 아니라 'Why와 Context'를 전달하는 거죠.

AI와 아이디어를 구체화하는 법: TMI 컨텍스트의 힘

바이브 코딩(Vibe Coding)을 처음 접하면 많은 분들이 이렇게 시작합니다. “AI 에이전트들이 사무실에서 대화하는 시뮬레이션을 만들고 싶어. 어떤 기능이 있으면 좋을까?”

그러면 AI는 그럴듯하지만 너무 뻔한 답을 줍니다. 로그인, 채팅, 알림... 누구나 생각할 수 있는 리스트죠. 이건 AI가 부족해서가 아닙니다. 제가 맥락(Context)을 너무 조금만 줬기 때문입니다. 맥락(Context)이 중요하다고는 다들 알고 있지만, 실제로 사용하는 형태를 보면 AI에게 충분한 배경 설명과 하고자 하는 것을 전달하지 않는 경우가 많은 것 같습니다.

그래서 저는 TMI처럼 머릿속에 있는 생각이 정리되지 않아도 일단 다 쏟아내는 편입니다.

“나는 심즈 같은 게임을 좋아하는데, 거기서 재미있는 포인트가 캐릭터가 알아서 움직이는 걸 ‘구경’하는 거거든. 그런데 거기에 내가 살짝 개입해서 흐름을 바꾸면 더 재미있어. 그래서 AI 에이전트들을 사무실에 넣고 싶은데, 그냥 일하는 게 아니라 진짜 직장 생활에서 느껴지는 눈치, 갈등, 썸 같은 걸 LLM으로 구현하고 싶어.

그런데 내가 걱정하는 게 있어. 그냥 대화 로그를 보여주는 앱이 되면 금방 질릴 것 같거든. 사람들이 계속 들어오게 하려면 뭔가 ‘끼어들고 싶다’는 욕구가 생겨야 한다고 생각하는데, 어떻게 설계하면 좋을까?”

이렇게 던졌더니 결과가 달라졌습니다. AI는 단순한 기능 리스트 대신, 제가 말한 “구경하다가 끼어들고 싶은 욕구”를 핵심 재미 루프로 잡아주고, 그걸 만들어내기 위한 구조를 제안해줬습니다. 에이전트 간 관계 수치, 스트레스가 쌓이면 터지는 갈등 이벤트, 사용자가 선물을 줄 수 있는 개입 시스템. 이 모든 게 하나의 대화에서 나왔습니다.

핵심은 이겁니다. 내가 무엇을 만들고 싶은지, 왜 만들고 싶은지, 무엇이 재미있다고 느끼는지, 무엇이 걱정되는지를 전달할수록 AI는 훨씬 더 내 생각을 잘 이해하게 됩니다. 정리되지 않은 생각도, 감정적인 표현도, 심지어 걱정이나 두려움도 모두 AI에게는 유효한 컨텍스트가 될 수 있습니다.

그리고 AI와 아이디어를 구체화할 때 주의해야 하는 부분이 있습니다. 처음부터 AI에 너무 의존하면 어느 순간 AI가 주는 그럴듯한 제안대로 움직이게 됩니다. 그 결과물은 내가 생각했던 핵심이 어느 순간 사라지고, 그냥 일반적인 결과물이 되어버리는 경우가 많습니다.

AI가 제안하는 내용이 안 좋다거나 활용하면 안 된다는 이야기가 아닙니다. 다만 AI에 익숙해질수록 나도 모르게 사고의 주도권까지 AI에게 넘겨버리는 상황을 경계해야 한다는 의미입니다.

AI의 제안을 무조건 정답으로 받아들이기보다, 내 기획 의도를 기준으로 끊임없이 판단하고 취사선택해야 합니다. 그래야 AI의 압도적인 생산성에 사람의 주관이 더해져 훨씬 밀도 있는 결과물이 탄생하게 됩니다.결국 AI와 함께하는 작업에서 성패를 가르는 건, AI에게 어떤 맥락을 쥐여줄 것인가를 결정하는 사람의 판단력입니다.AI가 아무리 발전해도 결코 사람을 대체할 수 없는 것, 그것은 바로 무엇을 어떻게 할지를 결정하는 의사결정의 ‘판단력’이지 않을까 생각합니다.

에이전트에게 영혼 불어넣기

그럼 이제 본격적으로 My Office AI Town의 핵심인 오피스 페르소나 구조가 어떻게 구성되어 있는지 설명해 보겠습니다.

<출처: 작가>

My Office AI Town에서 에이전트가 말을 하기 전에, 시스템은 먼저 이 오피스의 페르소나 구조를 순서대로 조합해 적용합니다.

<출처: 작가>

이걸 왜 하나로 합치지 않고 4개의 레이어로 나눴을까요?

앞서 언급한 Generative Agents 논문에서 힌트를 얻었습니다. 논문 속 AI 캐릭터들이 자연스럽게 행동할 수 있었던 이유는 “나는 누구인가(정체성)”와 “지금 무슨 일이 벌어지고 있는가(상황)”를 별개의 레이어로 분리해 관리했기 때문입니다. 두 정보를 하나의 덩어리로 넣었다면, 상황이 바뀔 때마다 캐릭터의 정체성까지 흔들렸을 거예요.

저도 같은 원리를 적용했습니다. 회사 페르소나와 그라운드룰은 오피스의 정체성, 즉 잘 바뀌지 않는 DNA입니다. 프로젝트 페르소나는 현재 상황, 다시 말해 스프린트가 끝나면 바뀌는 맥락이죠. 직원(에이전트) 페르소나는 개인의 성격으로, 10명이 각자 다른 값을 갖습니다.

이렇게 분리해두면 프로젝트가 바뀔 때 프로젝트 페르소나 한 줄만 수정하면 됩니다. 나머지 직원(에이전트)의 성격과 성향은 유지되면서, 새로운 프로젝트에 적응하는 모습을 볼 수 있는 거죠. 이렇게 변하는 것과 변하지 않는 것을 레이어로 분리하는 것. 이것이 멀티 에이전트 프롬프트 설계에서 제가 얻은 가장 중요한 교훈이었습니다.

그리고 가장 중요한 각 직원(에이전트)에게는 개인 페르소나가 있습니다. My Office AI Town의 에이전트 페르소나는 사용자가 직접 넣을 수 있지만, 편의를 위해 기본적으로 네 가지 타입을 선택할 수 있게 했습니다.

예를 들어, 팀장이 갑자기 야근을 통보한다면, 네 명의 에이전트는 아래와 같이 서로 다른 반응을 보일 것입니다.

워커홀릭(WORKER): "알겠습니다. 몇 시까지 하면 될까요?"
농땡이(SLACKER): "에이~ 또요? 오늘 치킨 먹으려 했는데. 뭐, 어쩔 수 없죠 ㅋㅋ"
사교가(SOCIALITE): "물론이죠 팀장님. (속으로: 또 이러시네. 오늘 약속 어떡하지?)"
MZ 신입(MZ_NEWBIE): "넵! (단톡에 조용히: 저 오늘 또 야근이에요...)"

저는 사용자들이 만들어보고 싶은 다양한 상황을 위해 전체적인 구조를 설계했을 뿐, 어떤 페르소나를 어떻게 사용할지는 오로지 사용자의 상상력에 맡겼습니다. 그래야 본인만의 사무실을 만들어볼 수 있고, 더 나아가 자기 주변 사람들의 성격을 대입해 재미있는 상황을 연출할 수도 있으니까요. 이게 바로 My Office AI Town이 가진 진짜 재미가 아닐까 싶습니다.

그런데 여기서 한 가지 문제가 생겼습니다. 이런 페르소나 주입만으로는 직원(에이전트)이 진짜 사람처럼 느껴지지 않았습니다. 왜냐 하면 대화 하면서 생성되는 관계, 추억, 기억이 없었기 때문입니다. 직원(에이전트)들은 항상 일정 부분 지나고 나면 서로 처음 만나서 대화를 나누는 것 처럼 행동했습니다.

하지만 사람은 그렇지 않습니다. 지난주에 팀장에게 야근을 강요당한 기억을 갖고 있는 사람과 그렇지 않은 사람은, 오늘 같은 야근 통보를 받았을 때 전혀 다르게 반응합니다. 사람다운 반응의 핵심은 성격 타입에 쌓인 경험, 즉 '기억'이 더해질 때 만들어지는 게 아닐까요?

그래서 ‘기억(Memory)’ 시스템을 추가하기로 했습니다. 에이전트들은 대화를 나누면서 서로에 대한 기억을 쌓아갑니다. 고백, 갈등, 화해, 비밀 공유 같은 사건들이 모두 기억으로 저장되고, 다음 대화에 영향을 미칩니다. 오늘 처음 만난 에이전트와 3개월을 함께 일한 에이전트는 같은 상황에서도 다르게 반응하며, 더욱 재미있는 오피스 라이프가 펼쳐지는 거죠.

‘기억(Memory)’ 시스템은 단순히 과거 대화 내용을 요약·축약해 반복적으로 주입하는 형태가 아닙니다. 기억의 조각처럼 직원(에이전트)이 기억할 내용을 데이터로 실제 저장하도록 했습니다.

1) 더 현실적인 시뮬레이션을 위한 시간 개념 적용

이 가상의 에이전트 세계에 시간이라는 개념을 적용하면, 시간에 따라 직원(에이전트)들의 행동도 달라지지 않을까 하는 생각이 들었습니다. 그래서 한 번 더 시스템을 확장해야겠다고 생각했습니다. My Office AI Town의 시간은 다섯 단위로 나눴습니다. 현실과 동일한 시간으로 흐르면 너무 지루할 수 있고, 그렇다고 너무 빠르게 진행돼도 몰입감이 떨어질 수 있기 때문입니다. 그래서 적절한 시간 간격을 두었습니다.

또한 접속 중에만 시간이 흐르고, 앱을 끄면 멈추도록 설계했습니다. 다시 켜면 멈췄던 시각부터 이어지게 했습니다.

<출처: 작가>

시간 단위가 바뀜에 따라 직원(에이전트)들은 해당 시간 단위에 맞는 대화를 하게 됩니다. 오전에는 업무 시작 이야기가, 점심에는 뭐 먹을지 고민이, 저녁이 되면 퇴근 이야기가 나오는 거죠. 시간대마다 완전히 다른 오피스 분위기가 연출되는 이유입니다.

2) 귓속말(Whisper): 둘만 아는 채널

My Office AI Town을 만들다 보니 점점 더 현실에서 일어날 수 있을 법한 기능들을 계속 추가하고 싶은 욕심이 생기기 시작했습니다. 시스템은 점점 더 복잡해지고 있다는 것을 느끼고 있었지만, 멈출 수가 없더라고요. 조금 더 현실적인 느낌을 주기 위해 결국 저는 ‘귓속말’ 기능을 추가했습니다. 다른 직원(에이전트)들은 알지 못하는, 오직 둘만 공유하는 비밀 채널이죠.

예를 들어,

박지훈 → 이서연(귓속말): “나 사실 팀장님한테 좀 화났어. 오늘 왜 너한테만 그러는 거야?”

이서연 → 박지훈(귓속말): “ㅋㅋㅋ 그냥 넘어가. 우리 사귀는 거 팀장님은 모르잖아.”

뒷담화, 비밀 연애, 사내 정치까지. 겉으로 드러나지 않는 날것의 드라마가 이 귓속말 채널에서 펼쳐지도록 구현한 겁니다. 귓속말을 누구와 어떤 이야기를 할지 선택하는 것은 모두 직원(에이전트)의 자율적 판단입니다. 단, 사용자는 이 모든 비밀 대화를 엿볼 수 있습니다. 그 순간 “아, 이 둘 사이에 이런 일이 있었구나!” 하며 내막을 알아가는 과정이 꽤 중독적입니다.

3) 모든 맥락이 한 번에 LLM에게 전달되는 순간

자, 이제 실제로 에이전트가 한마디를 내뱉기 직전에 LLM에게 전달되는 컨텍스트를 보겠습니다.

[회사 페르소나] 스타트업 분위기의 IT 개발사. 야근이 잦다.

[프로젝트 페르소나] 다음 달 앱 출시를 앞두고 막바지 스프린트 중.

[회사 그라운드 룰] 존댓말 기반, 친한 사이는 반말 OK. 한국어.

[직원 에이전트] 이서연 — 사교가 타입, 26세, 워커홀릭, MBTI: ENFP...

[대화 상대] 박지훈

[관계 상태] 비밀 연애(호감 88/100)

[이서연의 기억]

“박지훈이 내 생일을 기억하고 커피를 사줬다.”(중요도 8)

“우리 사귀는 거 팀장님은 모른다.”(중요도 7)

[현재 시각] D+5일 저녁, 퇴근 30분 전

[현재 공간] 자기 자리(박지훈 자리 근처)

이 맥락을 받은 LLM은 이서연의 입장에서, 저녁 퇴근 30분 전 비밀 연인인 박지훈 옆자리에서 할 만한 말을 생성합니다. 뻔한 AI 어시스턴트 말투가 아니라, 퇴근 전 설레고 약간 피곤한 26살 사무직의 말이 나오는 거죠.

이 한마디가 나오기까지의 전체 흐름을 정리하면 이렇습니다.

<출처: 작가>

에이전트당 최대 50개의 기억을 유지하고, 초과하면 중요도가 낮은 기억부터 자동으로 삭제됩니다. 기억의 중요도는 사건의 감정 태그에 따라 자동으로 결정됩니다.

<출처: 작가>

그런데 50개의 기억을 LLM에 전부 넣지는 않습니다. Generative Agents 논문에서 에이전트가 자연스럽게 행동할 수 있었던 핵심 이유가 이것입니다. 기억을 무조건 다 가지고 있는 게 아니라, 그 순간에 필요한 기억만 선별해서 꺼낸다는 거죠. 논문에서는 최신성, 중요도, 관련성, 이렇게 세 가지 기준으로 기억을 추출합니다.

My Office AI Town도 대화 상대가 누구냐에 따라 관련 기억만 추출합니다. 이서연이 박지훈과 대화할 때는 박지훈과 얽힌 기억이 올라오고, 팀장과 대화할 때는 전혀 다른 기억이 올라오는 구조입니다. ‘박지훈이 내 생일을 기억하고 커피를 사줬다’(중요도 8)는 기억이 선택된 건, 지금 그 대화 상대가 박지훈이기 때문이죠.

결국 AI 시뮬레이션의 성패는 얼마나 정교한 삶의 무대를 만드느냐에 달려 있습니다.

그런데, 이걸 대화마다 하면?

지금까지 설명한 구조를 보셨으면 아마 눈치채셨을 겁니다. 에이전트 한 명이 한마디를 할 때마다 이 컨텍스트를 조립하고, LLM API를 한 번씩 호출해야 합니다. 에이전트는 10명입니다. 각자 수십 번씩 대화를 나눕니다. 대화 히스토리가 쌓일수록 입력 토큰도 기하급수적으로 불어납니다. 거기에 JSON 형식으로 응답을 받아 파싱하는 과정에서 발생하는 출력 토큰도 상당하죠.

이게 하루 이틀이 아니라, 시뮬레이션이 돌아가는 내내 계속됩니다. 저는 처음에는 대수롭지 않게 생각했습니다. 그런데 며칠이 지나고 AI 비용 대시보드를 열었을 때… 어떤 일이 벌어졌을까요?

2회에서 계속됩니다.

다음 회차 예고

[2회: 기술vs비용] 과금 폭탄 맞고 배운 것들: 프롬프트 보안·토큰 압축·프로세스로 비용 90% 절감한 삽질기

API 호출 수가 분당 제한에 걸리고, 출력 토큰이 300K를 넘어가고, 사용자가 프롬프트 입력란으로 AI를 해킹하려는 시도까지 있었는데요. 다음 2편에서는 돈 없는 1인 비개발자가 생존하기 위해 선택한 것들을 공개하겠습니다.

]]>

Figma Weave 리뷰: 피그마의 잘못된 선택

정식으로 출시된 Figma Weave

작년 10월, Figma가 Weavy를 인수했다는 소식이 나왔을 때 이건 단순히 기능 하나가 추가되는 이야기로 보이진 않았다. 이미지나 영상 같은 생성형 미디어를 다루는 기술이 피그마 안으로 들어온다는 건 피그마가 어디까지 확장될 수 있는지를 보여주는 것 같았다. 인수 당시에는 단순한 생성 도구에 머물지 않고, UX 설계나 프로토타이핑, 그리고 디자인 시스템과 연결된 형태로 제품 제작 과정 안에 자연스럽게 녹아들 것이라고 예상했다.

그렇게 생각한 이유는 당연하게도 피그마가 그동안 맡아왔던 역할 때문이다. 화면을 그리는 도구를 넘어 협업을 중심으로 디자인 시스템을 관리하고 제품 제작 과정 전체를 책임지는 캔버스로 발전하고 있었기 때문에 새로운 기술이 들어온다면 결국 그 흐름 안으로 들어올 것이라고 생각했다. 단순히 결과를 만들어주는 기능이 아니라 기존의 설계 흐름을 더 빠르게 만들거나 더 정교하게 다듬는 방향으로 확장될 거란 기대였다.

Figma의 Weavy 인수 소식은 피그마의 새로운 기능을 기대하게 만들었다. <출처: Figma>

그리고 반년이 지난 지금, Figma Weave라는 이름으로 실제 제품을 제대로 확인할 수 있는 시점이 됐다. 결론만 이야기해 본다면, 공개된 지금의 Weave는 당시 예상했던 모습과는 조금 다른 위치에 놓여 있다. 피그마 파일 안에서 바로 사용하는 것이 아닌 별도의 웹 환경에서 동작하는 독립적인 도구고, 역할 역시 UX 설계나 프로토타이핑과 연결된 게 아닌 이미지나 영상 같은 생성형 미디어를 다루는 쪽이다.

공개된 Figma Weave <출처: Figma>

그래서 이 기회를 통해 단순히 새로운 도구를 소개한다기보다는, 반년 전 기대했던 방향과 지금의 Weave의 방향이 어떻게 다른지를 비교해보고자 한다. 당시 피그마에게 기대했던 것이 실제 제품으로 구현되면서 어떤 형태로 나타났는지, 그리고 그 사이에 제품 시장이 어떻게 바뀌었는지를 현재를 기준으로 정리해본다.

Figma Weave 간단 리뷰

피그마와 유사한 워크스페이스 구조를 가지고 있다. <출처: 작가>

Figma Weave를 열었을 때 가장 먼저 눈에 들어오는 건 익숙한 피그마의 캔버스 형태다. 파일 안에서는 각각의 노드가 프레임처럼 만들어져 있고, 이 프레임을 프로토타입처럼 연결하면서 결과를 만들어가는 방식으로 구성되어 있다. 프롬프트, 영상 처리, 이미지 처리, 텍스트 입력, 필터 같은 단계나 작업들이 각각 독립적인 프레임처럼 존재하고, 이 노드들을 이어 붙이면 된다.

피그마가 화면을 설계하는 도구라면, Weave는 결과가 만들어지는 과정을 구성하는 데 더 가깝다. 무엇을 만들지보다 어떻게 만들어질지를 먼저 정의하는 방식이다. 하나의 프롬프트로 완성된 결과를 얻고 끝나는 것이 아니라, 중간 결과를 계속 이어가며 수정하고 확장한다. 그래서 워크플로우 자체가 중요한 단위로 작동한다.

튜토리얼을 따라 텍스트 프롬프트를 하나 생성하고, 이미지를 만들어볼 수 있다. <출처: 작가>

프로젝트 안으로 들어가면 코치마크와 함께 기본적인 튜토리얼이 시작된다. 이 튜토리얼을 따라 프롬프트로 이미지를 생성해보면, 이후 그 결과물을 하나의 끝난 결과로 다루지 않는다. 다음 노드로 계속 연결해 나갈 수 있다.

예를 들어, 하나의 이미지를 만든 뒤, 여기에 동영상 노드를 연결할 수 있다. 캐릭터가 어떻게 움직일지를 프롬프트로 설명하면, 동일한 이미지 에셋을 영상으로 확장할 수 있다. 동시에 같은 이미지를 3D 오브젝트로 추출하는 것도 가능하다. 즉, 하나의 소스를 두고 여러 방향으로 결과를 병렬적으로 발전시킬 수 있다는 점이 핵심이다.

만든 이미지를 기반으로 3D 오브젝트나 영상으로 바로 확장할 수 있다는 장점이 있다. <출처: 작가>

또 하나 흥미로운 부분은 프롬프트 자체도 하나의 자산처럼 관리할 수 있다는 점이다. 영상에 넣어야 하는 텍스트 같은 자주 치환되는 요소들은 피그마의 변수처럼 따로 지정해둘 수 있다. 이를 통해 표현 일부만 교체하면서 전체 프롬프트 구조를 유지하는 방식도 가능하다.

피그마의 변수 기능처럼 특정 표현을 교체하면서 사용할 계획이라면, 표현을 변수로 만들 수도 있다. <출처: 작가>

기존 생성형 도구들은 하나의 스레드 안에서 순차적으로 프롬프트를 입력하고 결과를 수정하는 선형 구조에 가깝다. 반면 Weave는 프롬프트와 결과, 그리고 그 과정 자체를 만드는 도구다. 즉, Weave는 생성 과정을 설계하고, 이를 재사용 가능한 형태로 관리하는 미디어 중심의 워크플로우 도구라고 볼 수 있다.

이런 구조 덕분에 Weave의 강점도 비교적 분명하게 드러난다. 하나의 소스를 여러 갈래의 결과로 확장하는 데 강하고, 생성 이후의 편집과 변형을 자연스럽게 이어갈 수 있다. 이전에 만든 프롬프트와 작업 구조를 다시 연결해 재사용하기에도 유리하다. 이미지와 영상 같은 시각 콘텐츠를 생성하고, 이를 편집·확장하는 흐름에 집중되어 있다는 점도 특징이다. 그런 면에서 단순한 이미지 생성 도구보다 훨씬 정교하고, 더 넓은 범위를 다루고 있다.

하지만 막상 기대했던 부분은 보이지 않는다. 피그마와 통합될 거라고 생각했던 핵심 영역과 맞닿아 있는 기능은 아직 보이지 않는다. 마이크로 인터랙션을 정의하는 기능이나, 브랜드 에셋을 기반으로 모션으로 확장하는 기능 등 UI 디자인을 더 강화하는 영역은 다뤄지지 않는다.

정리하자면, 현재의 Weave는 영상과 이미지 영역에서 생성형 작업을 구성하고 재사용하기 위한 별도의 캔버스에 가깝다. 강점은 분명하지만, 동시에 피그마라는 이름 안에서 기대하게 되는 역할과 실제 맡고 있는 역할 사이에는 분명한 간극이 존재하게 됐다.

생성형 AI 시장은 지독한 전쟁 중이다

생성형 AI 시장은 현재 엄청난 영토 전쟁 중이다. <출처: 작가, ChatGPT>

한편 현재 생성형 AI 도구의 흐름은 단순한 결과 생성을 넘어, 제품 제작 방식 자체를 바꾸는 방향으로 빠르게 확장되고 있다. 영상 생성 영역에서는 Runway, Pika 같은 도구들이 이미 실사용 가능한 수준의 결과물을 만들어내고 있다. UI 생성 영역에서는 Cursor, Claude, Gemini 같은 도구들이 코드와 구조를 포함한 인터페이스 생성까지 다루기 시작했다.

여기에 Google의 Stitch, Paper, Claude Design까지 등장하면서, 점점 UI를 직접 만지는 디자이너의 수요가 줄어들고 있다. 텍스트만으로 UI 구조와 시각 결과를 동시에 만들어내는 프로세스가 탄생한 것이다.

중요한 변화는 생성형 AI가 더 이상 디자인 결과물만 만드는 도구가 아니라는 점이다. 기획과 디자인, 개발 사이의 경계를 완전히 흔들면서, 선형적인 개발 구조가 아닌 설계와 구현을 동시에 만들어내고 있다. 결국 지금 시장에서 경쟁이 일어나는 지점은 단순히 결과물을 잘 만드는 생성 기능이 아니다. 제품 제작의 전체 흐름을 누가 가져가느냐가 싸움의 관건이다.

생성형 AI들은 전통적인 기획-디자인-개발이 아니라, 통합된 워크플로우를 만들어내고 있다. <출처: 작가, ChatGPT>

그 관점에서 보면 Weave는 분명 흥미로운 방향을 제시하고 있다. 대부분의 생성형 AI는 프롬프트 입력 → 결과 생성 → 재수정의 선형 구조를 반복한다. 반면, Weave는 프롬프트와 결과를 독립적인 노드로 분리하고, 이를 연결하는 방식으로 구성한다. 이 구조에서는 하나의 프롬프트를 여러 결과로 동시에 확장할 수 있다. 또한 동일한 입력을 바탕으로 서로 다른 결과를 병렬적으로 발전시킬 수도 있다.

결국 Weave의 강점은 결과 자체보다, 생성 과정을 구조화하고 재사용 가능하게 만든 데 있다. 이것만 보면 Weave가 선택한 전략은 워크플로우 통합이라는 점에서 유효한 것처럼 보인다.

흔들리고 있는 Figma의 독점적 지위

문제는 피그마 그 자체다. Weave를 못 만들어서 아쉬운 게 아니다. 오히려 너무 잘 만들어서 더 아쉽다. 지금 피그마가 가장 중요하게 선택했어야 하는 방향은 Weave까지 통합된 제품 제작 흐름의 중심축이다. 그런데 Weave는 그 축을 보강하는 방식이 아니라, 별도의 미디어 워크플로우 도구로 등장했다.

지금 생성형 AI가 바꾸고 있는 것은 제품을 만드는 순서 자체다. 텍스트로 UI를 만들고, 그 결과를 바로 코드로 연결하고, 다시 제품 수준까지 끌어올리는 흐름이 더 이상 예외적인 방식이 아니게 됐다. 예전에는 디자인이 먼저 있고, 그다음 구현이 따라오는 구조였다. 하지만 지금은 설계와 구현이 동시에 일어나는 구조가 점점 더 일반적인 흐름이 되고 있다.

피그마의 상장도 디자인과 기획, 개발이 모두 협업할 수 있는 캔버스의 힘이었다. <출처: 피그마>

이 변화가 더 크게 느껴지는 이유는, 그동안 피그마가 차지하고 있던 자리가 바로 그 중간 지점이었기 때문이다. 피그마는 단순히 화면을 그리는 툴이 아니라, 아이디어를 구체화하고, 팀이 기준을 맞추고, 디자인 시스템을 정리하는 도구였다. 제품으로 넘어가기 직전까지의 흐름을 모두 관장하는 협업 캔버스에 가까웠다.

그런데 지금은 그 구간 자체를 우회할 수 있는 도구들이 너무나 빠르게 늘어났다. 디자인을 거치지 않고도 바로 제품으로 가는 경로가 현실적인 선택지가 되면서, 피그마는 자신들이 협업의 중심에 있어야 하는 이유를 다시 시장에 설명해야 하는 상황이 된 것이다.

실제 개인 작업을 진행해보면서 이 변화를 더 생생하게 경험했다. 개인적으로 준비 중인 서비스를 만들면서, 처음으로 피그마를 거의 사용하지 않았다. 대부분의 작업은 생성형 AI를 통해 구현했고, 설명이 복잡한 화면이나 스타일을 정교하게 통제해야 하는 부분에서만 피그마를 보조적으로 사용했다. 피그마가 기존에 차지하고 있던 위치가 더 이상 당연하지 않게 됐다는 사실이다.

기능의 효용성은 타이밍이 만들어준다

이런 상황에서 피그마가 가장 먼저 했어야 하는 일은 협업 공간으로서의 아이덴티티를 다시 정의하는 것이라고 본다. UX 설계, 디자인 시스템, 협업, 그리고 Weave로 대표되는 미디어 생성형 워크플로우까지 통합하는 방향이다. 기획부터 모션과 인터랙션까지 하나의 흐름 안에서 연결하는 통합 워크플로우를 강화했어야 했다.

피그마 사이트(위)와 피그마 메이크(아래). 노코드 웹 빌더와 AI 프로토타이핑 기능이 핵심이다. <출처: 피그마>

피그마 메이크, 피그마 사이트, MCP 지원 같은 피그마 자체의 시도들이 없었던 것은 아니다. 효과도 제법 있고, 분명히 좋은 기능이다. 문제는 속도와 우선순위다. 대응은 느렸고, 그사이 시장은 훨씬 빠르게 움직였다.

개발자와의 협업을 위한 데브 모드를 따로 판매하고, 코드 커넥트를 더 높은 요금제의 기능으로 나누는 동안, 훨씬 낮은 비용으로 그 모든 설계와 구현을 동시에 처리할 수 있는 생성형 AI 도구들이 등장했다. 결과적으로 피그마는 역설적으로 피그마 안에 갇힌 채, 제품 제작 흐름 전체를 장악하려는 경쟁에서 계속 늦은 선택을 이어가고 있다.

잘 만든 Weave, 그래서 더 걱정이다

Weavy 인수 당시의 방향성 자체는 틀리지 않았다. 생성형 미디어를 디자인 도구 안으로 끌어들이려는 시도는 자연스러운 흐름이고, Weave 자체도 실제로 잘 만든 도구다. 선형적인 기존의 미디어 생성 구조를 노드 기반으로 재설계한 것은 분명히 좋은 시도다. 실제로 잠깐 써봤을 때도 재사용성이 매우 마음에 들었다. 동시에 같은 품질과 수준의 다양한 에셋을 만들 수 있다는 점에서도 분명한 강점이 있다.

Weave는 분명히 좋은 도구다. 하지만 지금 문제는 도구의 완성도가 아니다. 피그마가 현재 처한 상황이 문제다. Weave가 이 시점에, 이 방식으로 등장했으면 안 됐다. 지금처럼 별도의 제품으로 먼저 분리되어 나오는 방식은 피그마가 가장 시급하게 지켜야 했던 통합 워크플로우와 협업 중심축을 강화하는 선택과는 정반대의 선택이다.

지금 시장은 결과를 더 잘 만드는 도구를 기다리는 것이 아니다. 설계와 구현, 협업을 다시 하나의 흐름으로 묶어줄 중심축을 기다리고 있다. 그런데 피그마는 총력을 다해 그 중심축을 강화하는 대신, 체력을 반으로 쪼개 생성형 미디어 AI계의 피그마를 하나 더 추가해버렸다.

피그마의 지배력이 날이 갈수록 떨어지고 있는 상황이다. <출처: 작가, ChatGPT>

그래서 Weave를 보고 느끼는 아쉬움은 기능적인 부족함에서 오지 않는다. 오히려 너무 잘 만들었기 때문에 더 선명해진다. 피그마는 지금 가장 중요하고, 가장 위협받고 있는 자기 자리를 지켰어야 했다. 그런 점에서 Weave는 좋은 제품이면서도, 동시에 피그마가 선택한 우선순위가 얼마나 불안한지 보여주는 신호이기도 하다. 이제 피그마에게 필요한 것은 또 하나의 잘 만든 도구가 아니라, 다시 제품 제작의 중심이 될 수 있다는 설득인지도 모른다.

]]>

GEO 시대의 글쓰기, SEO와 무엇이 같고 무엇이 다른가

온라인에서 비즈니스 접점을 갖는 기업, 그곳을 이끄는 리더와 IT 실무자에게 GEO(Generative Engine Optimization)는 더 이상 마케터만의 문제가 아닙니다. SNS만큼이나 중요한 노출 채널이 바뀌고 있기 때문입니다. SEO에 이어 등장한 GEO는, AI가 사용자 질문에 답할 때 우리 브랜드와 콘텐츠를 어떻게 인용하게 만들 것인가를 다룹니다. 실제로 요즘IT에는 한 엔지니어 작가가 GEO 자동화 아키텍처에 관한 글을 기고하기도 했습니다.

그런데 시장에 나와 있는 GEO 정보를 훑다 보면 혼란스럽습니다. 모든 상황을 한 번에 해결해 줄 실버불렛 같은 플레이북이 없기 때문입니다. 요즘IT 역시 블로그 에이전트를 만들면서 GEO의 중요성과 정보의 혼란을 함께 체감했습니다. 그래서 정확한 정보를 가려내고 스스로 실행할 가이드를 찾는 리더와 실무자를 돕기 위해 <GEO 팩트체크 세미나>를 기획했습니다.

이 글은 세미나에서 콘텐츠 전략을 강의할 이소연 빌더블 대표가 사전 가이드로 보내온 원고입니다. "기존에 써둔 글은 다 버려야 하는지", "SEO를 잘하면 GEO는 자동으로 되는지" 현장에서 가장 자주 받는 두 질문에 실제 사례로 답합니다. 자세한 세미나 정보는 여기에서 확인하실 수 있습니다.

GEO (Generative Engine Optimization, 생성형 엔진 최적화)는 SEO (Search Engine Optimization, 검색 엔진 최적화)와 다르게 써야 한다? 반은 맞고, 반은 틀립니다.
by 이소연 (빌더블 대표)

글쓴이이소연(데니스)은 SEO/GEO 교육 회사 빌더블의 대표로,GEO/AEO/SEO 올인원 강의, 맞춤형 기업 강의 등 AI 시대의 콘텐츠 전략과 브랜드 노출 설계를 도와드리고 있습니다.

클라이언트에게 GEO(Generative Engine Optimization, 생성형 엔진 최적화) 콘텐츠 전략을 설명하다 보면, 자주 받는 두 가지 질문이 있습니다.

기존에 써둔 글들은 다 버려야 하나요?

혹은 반대로

SEO (Search Engine Optimization, 검색 엔진 최적화) 잘 하면 GEO는 자동으로 되는 거죠?

이 글을 읽으시는 분들 중에도 위 두 가지 의문이 드는 분들이 계실 것 같은데요. 둘 다 아닙니다.

이 글에서는 제가 그동안 다양한 고객을 만나며 정리한 내용을 바탕으로 GEO 콘텐츠가 SEO와 무엇이 어떻게 다른지, 실무자가 당장 무엇부터 바꿔야 하는지를 이야기해보려 합니다. GEO가 무엇인지는 들어봤지만, 실제로 글쓰기를 어떻게 바꿔야 하는지 감이 안 잡히는 마케팅 실무자라면 이 글과 세미나가 도움이 될 것입니다.

AI 검색은 내 글을 어떻게 읽고 있을까요?

먼저 GEO 글쓰기란, AI가 사용자 질문에 답할 때, 우리 콘텐츠를 인용 출처로 선택하도록/우리 브랜드를 추천하도록 구조, 내용, 신뢰 신호를 설계하는 콘텐츠 전략입니다. GEO 글쓰기가 왜 달라야 하는지를 이해하려면, AI 검색이 내부적으로 어떻게 작동하는지를 먼저 알아야 하는데요. 그 이야기를 먼저 해보겠습니다.

AI는 사용자의 질문을 어떻게 다룰까요? 사용자가 ChatGPT나 Perplexity, Gemini에 질문을 하나 던지면, AI는 그 질문을 그대로 검색하지 않습니다. 내부적으로 여러 개의 서브 쿼리로 분해해 검색한 뒤 결과를 종합해 최종 답변을 생성하죠. 이걸 '쿼리 팬아웃(Query Fan-Out)'이라고 부릅니다.

쿼리 팬아웃 예시 이미지 <출처:빌더블이소연>

이 쿼리 팬아웃 때문에 우리 콘텐츠가 특정 키워드에서 구글 랭킹 1위를 하고 있더라도, AI가 쪼갠 서브쿼리 중 하나에 잡히지 않으면 인용이 어렵습니다. Surfer SEO 리서치에 따르면, 2025년에 약 10,000만 개 키워드와 17만 3,902개 URL을 분석한 결과, AI 오버뷰에 인용된 페이지 중 약 68%가 구글 상위 10개 결과에 없었습니다.

그렇다면, 우리는 이 수십 개의 서브쿼리를 모두 예측하고 대응할 수 있을까요?

현재 Otterly, LLMrefs 같이 쿼리 팬아웃 분석을 도와주는 툴들이 존재합니다. 그러나, 구글, Open AI 등이 공개한 팬아웃 로직은 없기 때문에 실제 내부 로직 그대로 재현하는 실측값이라기보단 통계, 패턴 기반의 예측값에 가깝습니다.

<출처:Otterly>

그렇다면, 우린 지금 당장 어떤 액션을 해야 할까요?

여기서 SEO와 GEO 글쓰기의 가장 근본적인 차이가 시작됩니다.

SEO는 사람이 검색창에 치는 단어(=키워드)를 분석합니다.
GEO는 사람이 AI에게 털어놓는 맥락(=프롬프트)을 분석합니다.

예를 들어볼게요. ‘가족 간 계좌이체 세무조사’라는 키워드로 SEO 글을 기획하면 소제목이 이렇게 나옵니다.

SEO 방식 소제목 예시

가족간 계좌이체 세무조사란?
가족간 계좌이체 세무조사 기준
가족간 계좌이체 세무조사 대응 방법

키워드 중심이죠. 검색창에 칠 단어를 그대로 소제목으로 가져왔습니다.

GEO는 조금 다릅니다.

먼저 검색하는 사람이 AI에게 어떤 상황에서 어떤 질문을 할지 먼저 생각해볼게요.

GEO 방식 소제목 예시 (맥락 기반)

"부모님께 생활비를 매달 현금으로 보내고 있는데 세무조사 나올 수 있나요?"
"결혼 자금으로 부모한테 N천만 원 받았는데 증여세 내야 하나요?"
"가족 계좌로 사업 자금 빌렸다가 세무조사 받은 사례 있나요?"
"배우자한테 생활비 이체하는 것도 증여세 대상인가요?"

이 질문들을 소제목으로 배치하고, 각 소제목 아래에 그 상황에 직접 답하는 단락을 씁니다. AI가 '배우자 계좌이체 증여세' 관련해서 검색할 때, 우리 콘텐츠가 인용될 가능성이 훨씬 올라갑니다. 이것이 맥락(Context) 설계입니다. 키워드에 머무르지 않고, 고객이 AI에게 질문을 던지는 상황과 맥락을 먼저 그리는 것입니다.

맥락을 찾았다면, 글은 어떻게 달라져야 할까요?

맥락을 설계했다면, 그다음은 글의 구조와 내용에 검증 가능한 정보가 있는지, 우리 사이트가 신뢰성이 있는지를 살펴봐야 합니다. 그중에서도 먼저 우리가 설계한 맥락이 실제로 AI에게 인용될 수 있는 구조로 글을 쓰는 것이 중요합니다.

구조: AI는 흐름이 아니라 문장, 문단을 가져갑니다

AI는 글을 처음부터 끝까지 읽지 않습니다. 필요한 단락을 잘라서 인용합니다. Search Engine Land 아티클에 따르면 ChatGPT 인용의 약 44%가 글의 첫 1/3 구간에서 나왔다고 합니다. 그리고, AI에 인용된 블로그 포스트의 72.4%에는 맥락 없이도 단독으로 이해되는 단락, 즉 'Information Island'가 존재했습니다.

SEO와 GEO 글쓰기의 네 가지 차이. SEO 방식은 "이 글에서는 ~을 알아보겠습니다"로 시작해 키워드 중심 소제목을 쓰고 결론을 글 후반부에 배치하는 반면, GEO 방식은 결론과 수치로 시작해 맥락·질문 중심 소제목을 쓰고 단독으로 이해 가능한 단락(Information Island) 구조로 작성한다. <출처: 이소연>

예를 들어볼게요.

[Before] SEO 방식

강남 레이어드 컷 잘하는 미용실

00과 같은 연예인들 덕분에 요즘 레이어드 컷이 트렌드로 떠오르고 있습니다. 강남 00 미용실에는 실력 있는 디자이너들이 많아 많은 분들이 찾고 있는데요. 이 글에서는 강남에서 레이어드 컷을 잘하는 미용실을 선택할 때 고려해야 할 사항들을 알아보겠습니다.

이 내용을 AI가 잘라서 인용하면 어떻게 될까요? "요즘 트렌드로 떠오르고 있습니다"와 "알아보겠습니다"만 남습니다. 구체적이거나 수치적인 정보가 없죠.

[After] GEO 방식

강남에서 레이어드 컷 처음 받을 때, 예약 전에 확인해야 할 것

왜 다들 예쁘게 하는데 나만 레이어드 컷 실패할까요? 마음에 들지 않은 커트의 가장 흔한 원인은 디자이너 실력뿐만 아니라 분석과 상담입니다. 모발 굵기와 두상 모양에 따라 레이어 각도가 달라져야 하는데, 상담 없이 시술에 들어가면 원하는 결과가 나오기 어렵습니다.

예약 시 확인할 것: 시술 전 상담이 별도로 진행되는지, 레퍼런스 사진을 보면서 함께 조율하는 과정이 있는지.

가격 외에 봐야 할 지표: 디자이너당 네이버 리뷰가 N개 이상이거나 평점 N점 이상인 매장인지 체크해보세요.

추가로, 표와 리스트를 적극적으로 활용하는 것도 중요합니다. Discovered Labs리서치에 따르면, 표와 리스트로 구조화된 콘텐츠는 그렇지 않은 콘텐츠보다 AI 인용률이 상당히 높아지며, 일부에서는 인용 확률이 약 40% 수준까지 증가했다고 합니다.

내용: 내 글에 검증 가능한 정보가 있나요?

글의 구조만이 아닙니다. 내 글의 내용이 검증 가능한 정보가 있는지도 살펴봐야 합니다. Princeton University와 IIT Delhi가 KDD 2024에서 발표한 GEO 연구는 콘텐츠 최적화 전략 9가지를 실험했습니다. 그중 가장 효과가 높았던 3가지는 아래와 같습니다.

통계 추가: 데이터·수치 삽입 (최대 +37%)
권위 있는 출처 인용:신뢰 가능한 레퍼런스 추가 (+9%)
전문가 인용문 삽입:직접 인용문 포함 (+22%)

공통점이 보이시나요? 맞습니다. AI는 검증 가능한 정보를 선호합니다. '많은 기업들이 도입하고 있다'보다 '2025년 기준 미국 마케터의 54%가 GEO를 6개월 내 도입할 계획이다 (Averi.ai, 2025)'와 같은 문장이 인용될 확률이 훨씬 높습니다.

신뢰: 우리 웹사이트 말고 우리 브랜드는 어디서 어떻게 언급되고 있나요?

SEO에서 제일 빼놓을 수 없었던 핵심 요소 중 하나는 백링크였습니다. 그러나, GEO에서 백링크는 가장 중요한 요소라고 보긴 어렵습니다. 대신 브랜드 언급(brand mention)이 훨씬 중요해졌죠. Ahrefs가 7만 5천 개의 브랜드를 분석한 결과, 브랜드 언급(brand mention)은 AI Overview 인용과 0.66~0.71 수준의 높은 상관 관계를 보였고, 백링크와 AI의 인용 가능성은 0.2~0.3 사이였습니다.

AI 오버뷰 인용과의 상관관계

이제 다른 콘텐츠에서도 우리 브랜드가 언급되느냐가 중요해졌습니다. 우리 브랜드 웹사이트 안에서 글을 아무리 잘 써도, 외부에서 내 브랜드가 전혀 언급되지 않는다면 AI는 신뢰할 근거가 부족하기 때문이죠.

GEO 글쓰기는 발행하고 끝이 나는 게 아니라 외부 노출 전략을 동시에 설계해야 비로소 힘을 발휘합니다.

그리고 외부 노출의 형태는 블로그에 국한되지 않습니다. AI는 유튜브 디스크립션, 뉴스 기사, 커뮤니티 게시글, SNS 콘텐츠도 인용합니다. Profound 리서치에 따르면 같은 주제라도 질문의 형태가 바뀌면 AI가 참고하는 정보의 종류가 달라집니다. 짧은 키워드 중심 검색에서는 위키피디아나 일반 정보형 웹사이트를 주로 인용하지만, 자연어로 길게 작성된 질문이나 구체적인 맥락이 포함된 질문에서는 커뮤니티, 리뷰, 경험 기반 콘텐츠를 더 많이 참고합니다.

우리 브랜드가 어떤 채널에서 어떤 형태로 언급되는지를 다각도로 설계해야 한다는 의미입니다.

그래서 GEO는 효과가 얼마나 빨리 나타날까요?

구조와 내용을 바꿔도 결과가 언제 나타날지는 실무자에게 가장 현실적인 질문입니다. 검색엔진과 AI 검색은 콘텐츠 반영 속도에서 차이가 큽니다.

SEMrush 리서치에 따르면, 구글의 AI Overviews(검색 결과에 노출되는 AI 요약 기능)는 콘텐츠를 매우 빠르게 반영합니다. 게시 후 24시간 내 약 36%가 인용되고, 7일 내에는 약 56%까지 증가했습니다.

반면 ChatGPT는 초기 인용 속도는 느리지만 시간이 지날수록 누적되는 구조를 보입니다. 1일 기준 약 8%에서 시작해 30일 후에는 약 42%까지 증가했습니다.

즉 단기 노출은 구글 AI Overviews에서, 장기 누적 효과는 ChatGPT에서 기대할 수 있다는 뜻입니다. 어느 한쪽에만 의존하지 않고 두 채널을 모두 고려해 콘텐츠를 설계해야 하는 이유입니다.

SEO는 이제 끝인가요?

SEO를 9년째 하고 있는 제 경험상 SEO를 잘하는 사람은 GEO에서도 유리합니다.

SEO의 본질은 "이 사람이 왜 이 키워드를 검색했을까"를 파악하는 것입니다. 검색 의도를 읽고, 그 의도에 정확히 답하는 콘텐츠를 준비하는 것이죠. 이 능력은 GEO에서 요구하는 맥락 설계와 매우 유사합니다. 보다 디테일해진 것 뿐이죠. 즉 키워드나 프롬프트 뒤에 있는 사람의 맥락을 읽어내는 것은 SEO에서도, GEO에서도 본질이라고 할 수 있습니다.

그런 측면에서는 GEO 콘텐츠는 SEO 콘텐츠와 다르게 써야 한다는 말은 틀린 것이죠.

GEO를 위해 당장 무엇부터 시작해야 할까요?

GEO 콘텐츠의 핵심은 ‘키워드’가 아니라 ‘맥락’이라는 점에서 SEO와 다릅니다. 또 구조, 검증 가능한 정보, 신뢰의 측면에서도 SEO와 금 다르죠. 하지만 고객의 의도를 파악해야 한다는 점에서는 본질적으로 같습니다. 그렇다고 기존에 써둔 글을 모두 새로 쓸 필요는 없습니다. 트래픽이 있는 기존 글의 첫 단락을 결론 중심으로 리라이팅하고, 소제목을 고객 상황 기반으로 교체하는 것만으로도 GEO 인용 가능성은 충분히 올라갑니다. 처음부터 다시 쓰는 것보다 기존 자산을 손보는 것이 훨씬 효율적이라는 의미입니다.

하지만 너무 어렵거나 걱정할 일은 아닙니다. SEO나 GEO를 잘 모르시거나 GEO 전략에 대해 아직 시도해보지 않으신 분들도 당장 실행해보실 수 있는 네 가지 액션을 제안드립니다.

1. AI 검색엔진에 직접 검색해보세요.

ChatGPT나 Perplexity, Gemini에 우리 제품과 관련된 질문을 던져보세요. (예: "인스타그램 게시물에 댓글을 달면 자동으로 DM 보내주는 툴 추천해줘")

우리 브랜드가 인용되고 있는지, 경쟁사가 인용되고 있는지 확인하세요. 어떤 프롬프트에서 브랜드와 제품을 추천하는지도 함께 확인하세요. 지금 어떤 맥락에서 내 카테고리가 검색되는지를 파악하는 것이 맥락 설계의 시작점입니다.

2. 1번에서 찾은 프롬프트로 쿼리 팬아웃을 시뮬레이션해보세요.

AI에게 이렇게 물어보세요.

"나는 '[첫째에서 찾은 프롬프트]'라고 검색하는 사람을 위한 글을 쓸 거야. 이걸 검색하는 사용자의 10가지 하위 질문으로 분해(Fan-out)해줘."

실제 AI 내부 로직과 완전히 일치하지 않지만, 지금 당장 툴 없이 할 수 있는 가장 현실적인 시뮬레이션입니다. 나온 질문들을 글의 소제목으로 배치하고, 각 소제목 아래 그 질문에 직접 답하는 문장으로 시작하세요.

무작정 따라하는 것이 아닌 우리 고객이 정말 이런 맥락에서 질문할까를 고려해 글의 소제목으로 사용하셔야 합니다.

3. 글 안에 검증 가능한 정보를 넣으세요.

"많은 분들이 찾고 있습니다" 같은 문장이 있다면 바로 지우세요. 대신 수치, 출처, 전문가 인용 등으로 교체해서 AI 가시성을 높여보세요.

4. 내 브랜드가 외부에서 언급되고 있는지 확인하세요.

우리가 콘텐츠를 아무리 잘 써도 외부에서 브랜드가 언급되지 않으면 AI는 신뢰할 근거가 너무나도 부족합니다. 협업 콘텐츠, 인터뷰, 외부 기고, 리뷰 등 우리 브랜드 이름이 다른 곳에서 언급될 수 있는 접점을 하나씩 설계해보세요.

AI 검색이 주류가 되기 전, 지금 해야 할 GEO 전략

GEO 시대에 콘텐츠 전략을 고민하는 분들은 늘 고민일 겁니다.

"어떻게 써야 AI에 노출되나요?"
하지만 이보다 더 중요한 질문이 있습니다.
"우리 고객은 어떤 순간에 AI에게 우리 브랜드를 묻고 있을까?"

SEO 글쓰기 스킬이 어떠하고 GEO 글쓰기는 어떠하냐는 그 다음 문제입니다. 고객이 AI에게 질문을 던지는 그 맥락을 모르면, 아무리 잘 쓴 글도 엉뚱한 질문의 답이 될 수 있습니다. 반대로 그 맥락을 정확히 알면, 구조도 소제목도 첫 문장도 자연스럽게 따라오게 될 것입니다. 어쩌면 GEO 덕분에 브랜드는 고객에 대해 더 이해할 수 있는 기회를 찾은 게 아닐까 싶습니다.

GEO 콘텐츠 전략에 대해 더 깊이 있게 다룬 사례와 실습은 5월 21일 GEO 팩트체크 세미나에서 이어집니다.

GEO 팩트체크 세미나 자세히 보기

<GEO 팩트체크 세미나: 실제 사례로 보는 GEO, 오해와 진실> 안내. 일시는 5월 21일 목요일 19시, 오프라인과 온라인 동시 진행이다. 연사는 빌더블 이소연 대표, 라이너 김윤기 머신러닝 엔지니어, 서치 나인 양용준 대표 세 명이다. 요즘IT가 주최하고 라이너가 후원한다. <출처: 요즘IT>

]]>

디자인 AI 워크플로에 ‘고삐’를 채워줄 기술 8가지

‘하네스 엔지니어링’ 관점에서 본 디자인 AI 워크플로

생성형 AI의 폭발적인 발전으로 프롬프트 몇 줄이면 수십 개의 UI 시안이 쏟아져 나오고, 코드 한 줄 몰라도 그럴듯한 프로토타입을 손에 쥘 수 있는 시대가 왔습니다. 생산의 효율이 무한대에 가까워진 지금, 역설적으로 우리 앞에는 새로운 문제가 놓였습니다. 바로 ‘쏟아지는 결과물 가운데 무엇이 정답인가?’를 가려내는 일입니다.

과거 자동차나 항공 공학에서는 복잡한 전기 배선을 묶고 보호하며 제어하는 장치를 와이어 하네스(Wire Harness)라고 불렀습니다. 거대한 엔진의 힘을 각 부품에 안전하게 전달하고 통제하는 핵심 장치였죠. 지금 IT 업계의 키워드는 이러한 제어를 AI에 적용하는 ‘하네스 엔지니어링(Harness Engineering)’입니다. 야생마처럼 날뛰는 AI의 생산력에 디자인 원칙이라는 고삐를 채워, 우리가 원하는 미래의 사용자 경험으로 정확히 인도하는 기술의 중요성이 커지고 있습니다.

그렇기에 디자이너와 기획자의 역할 역시 제작에서 점검으로 중심축이 이동하고 있습니다. AI가 만든 수많은 초안 속에서 미세한 결함을 찾아내고, 브랜드의 영혼을 불어넣어 최종 완성도를 결정하는 심판관으로서의 역량이 새로운 생존 전략이 된 것입니다. 이번 글에서는 이러한 하네스 엔지니어링의 관점에서 변화한 디자인 AI 워크플로우와 우리가 주목해야 할 지능형 점검 기술들을 짚어보려 합니다.

일관성 있는 디자인 시스템을 설계하기

예전에는 디자인 시스템을 점검할 때, 디자이너와 개발자가 서로 화면을 맞춰보며 “이 컬러 값이 가이드와 맞나요?”라고 묻는 식의 수동적인 과정이었습니다. 하지만 AI의 등장은 일관성 점검의 주도권이 인간에서 시스템으로 옮겨가고 있습니다.

실시간 동기화의 혁신: 클로드 코드와 피그마 MCP

수천 개의 화면에 새로운 컬러 토큰을 적용해야 하는 상황에서, 디자이너는 클로드 코드에게 MCP를 통해 피그마 디자인 시스템 라이브러리에 직접 접근할 권한을 부여할 수 있습니다. AI는 곧 단순히 코드를 생성하는 데 그치지 않고, 현재 작업 중인 코드베이스와 피그마의 디자인 토큰을 실시간으로 비교합니다. 예를 들어, AI가 생성한 컴포넌트의 여백이 피그마에 정의된 16px(spacing-04)가 아닌 임의의 15px로 작성됐다면, AI는 이를 스스로 인지하고 즉시 교정합니다.

즉, 디자이너는 이제 “시스템을 제대로 따랐는가?”를 확인하는 반복 업무에서 벗어나, 시스템 자체의 논리 구조를 개선하는 시스템 아키텍트 관점의 점검에 집중하게 됩니다.

<출처: 작가, AI로 생성한 피그마 디자인 시스템>

자율 운영형 디자인 거버넌스: Supernova

디자인 시스템의 가장 큰 적은 방치입니다. 관리되지 않는 시스템은 결국 코드와 디자인이 따로 움직이는 파편화를 초래합니다. 슈퍼노바(Supernova)는 바로 이 지점에서 자율 운영형 디자인 거버넌스라는 새로운 가치를 만들어냅니다.

기존의 디자인 가이드는 문서를 업데이트하는 순간부터 이미 과거의 기록이 되기 일쑤였습니다. 피그마에서 바뀐 것들이 개발 환경에 반영되기까지는 누군가의 정성적인 보고와 수정 과정이 반드시 필요했고, 그 사이에서 수많은 레이어 명명 규칙 오류나 사용되지 않는 스타일이 디자인과 개발의 부채로 남았습니다.

슈퍼노바 AI는 디자인과 코드 사이의 ‘진실의 원천(Source of Truth)’을 실시간으로 감시하는 파수꾼 역할을 수행합니다. 피그마의 레이어 구조와 명명 규칙, 스타일 적용 현황을 실시간으로 스캔하고, 시스템 원칙에 어긋나는 요소가 발견되는 즉시 차단합니다. 이러한 자동화된 점검 체계는 디자이너가 단순히 픽셀을 정렬하고 가이드를 맞추는 수고를 덜어줍니다.

진실의 원천(Single Source of Truth, SSOT)이란?

데이터 아키텍처 내에서 특정 정보의 무결성을 보장하기 위해, 모든 데이터 요소를 오직 하나의 공식적인 마스터 데이터베이스에서만 생성하고 편집하도록 강제하는 관리 원칙입니다.

대신 디자이너는 컴포넌트 간의 고도화된 상관관계나 데이터 기반의 확장 가능한 아키텍처가 올바르게 작동하는지 점검하는, 보다 고차원적인 디렉터 역할을 맡게 됩니다. 하네스 엔지니어링의 관점에서 보면, 이는 기술이 기술을 스스로 검수하게 함으로써 디자인 품질을 보장하는 가장 완성도 높은 형태의 고삐라고 할 수 있습니다.

<출처: Supernova>

접근성과 사용성을 지키는 기술의 그물망

제작 속도가 아주 빨라질수록, 우리가 미처 챙기지 못한 곳들의 결함도 기하급수적으로 늘어납니다. 하네스 엔지니어링은 인간의 인지적 한계를 겸허히 인정하고, AI라는 정교한 렌즈로 서비스의 기술적·윤리적 결점을 촘촘하게 걸러내도록 돕습니다.

WCAG 표준 자동화 검수: Stark

접근성을 고려하는 일은 단순히 법적 규제를 준수하는 차원을 넘어, 모든 사용자에게 평등한 경험을 제공해야 하는 디자이너의 고귀한 의무입니다. 특히 복잡한 금융 지표나 데이터 서비스에서 색약 사용자를 고려하지 않은 차트는 정보 전달의 불평등을 만드는 치명적인 결함이 됩니다.

Stark와 같은 AI 기반 도구는 디자인 결과물을 업로드하는 즉시, 수만 가지의 웹 콘텐츠 접근성 지침(WCAG) 규정을 시뮬레이션합니다. “이 차트의 파란색과 녹색은 적색맹 사용자에게 동일한 명도로 보입니다.” 같은 내용을 담은 분석 리포트를 1초 만에 받아볼 수 있다면, 디자이너는 자신의 시각적 편향을 인식하고, 즉각적으로 디자인을 교정할 수 있습니다.

<출처: 작가, Stark Auto Scan&Fix 캡처>

데이터로 증명하는 시각적 위계와 사용성: Clueify

디자인 검증 현장에서 가장 소모적인 논쟁은 “제 눈에는 이게 더 잘 보여요”와 같은 주관적인 의견 충돌입니다. Clueify는 이런 주관성을 배제하고, AI Vision 기술로 인간의 시각 시스템을 정교하게 모방합니다.

Clueify는 수백만 건의 실제 아이 트래킹 데이터를 학습한 AI 모델을 활용합니다. 그 덕분에 디자이너가 작업물을 업로드하면 AI는 사용자의 시선이 가장 먼저 머무는 지점과 시선이 이동하는 경로를 예측한 히트맵(Heat Map)을 생성할 수 있습니다. 이 과정에는 디자인의 복잡도와 인지 부하를 계산하는 어텐션 맵(Attention Map) 아키텍처가 쓰입니다.

히트 맵(Heatmap)이란?

데이터의 밀도를 온도로 표현하는 시각화 방식입니다. 사용자들이 많이 머문 지점은 ‘뜨거운 색(빨간색)’, 적게 머문 지점은 ‘차가운 색(파란색)’으로 표시합니다.

어텐션 맵(Attention Map)이란?

딥러닝 모델이 데이터를 처리할 때 어느 부분에 집중했는지, 특정 픽셀에 부여한 가중치를 보여주는 기술 지표입니다. 인간의 뇌가 시각 정보를 처리하는 방식을 모방한 AI 알고리즘이 이미지 내의 대비, 색상, 형태 등을 분석하여 시선이 쏠릴 가능성이 높은 지점을 계산합니다.

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

이를 통해 디자이너는 실제 사용자 테스트를 진행하지 않고도, 사용자의 시선이 가장 먼저 머무는 핫스팟(Hot Spot)을 1초 만에 확인하며 시각적 위계를 객관적으로 점검할 수 있습니다. 예를 들어 서비스의 핵심인 ‘결제하기’ 버튼보다 주변의 화려한 광고 배너에 시선 점수가 더 높게 나왔다면, AI는 이를 ‘심각한 사용성 저해 요소’로 리포트합니다.

이는 디자이너가 의도한 시각적 위계가 실제 사용자의 인지 과정에서 어떻게 작동하는지 사전에 점검하게 함으로써, 단순한 체크리스트 수준을 넘어선 맥락 기반의 오류 검수를 가능하게 합니다.

<출처: Behance 텀블벅 리디자인>

포용적인 스토리텔링: Alt Text Generator

접근성을 고려한 사용성 설계에서 이미지에 대체 텍스트(Alt Text)를 부여하는 일은 간과할 수 없는 요소입니다. 여기서 대체 텍스트는 단순히 이미지 제목을 입력하는 수준의 작업이 아닙니다. 이는 시각 장애 사용자가 스크린 리더를 통해 디지털 생태계를 탐색할 때, 이미지가 담고 있는 상징적 의미를 전달받고 브랜드의 서사에 온전히 참여할 수 있도록 돕는 의미론적 접근성의 핵심입니다.

나아가 이는 검색 엔진 최적화(Search Engine Optimization, SEO)와도 직결됩니다. 검색 엔진이 이미지의 맥락을 더욱 정교하게 이해하도록 만들어, 서비스의 발견 가능성을 크게 높여주기 때문입니다.

과거에는 수백, 수천 개의 에셋에 대체 텍스트를 일일이 붙이는 일 자체가 막대한 물리적 노동력을 요구하는 병목 구간이었습니다. 하지만 최신 멀티모달 AI, 특히 시각-언어 모델(VLM, Vision-Language Model)을 활용한 생성기들은 이제 객체를 단순히 나열하는 수준을 넘어선 결과물을 보여주고 있습니다. 이를테면 전에는 “강아지가 한 마리 있습니다”처럼 평면적인 묘사에 머물렀다면, 이제 AI는 “포근한 거실 창가에서 오후의 햇살을 받으며 낮잠을 자는 골든 리트리버”처럼 이미지의 정서적 분위기와 서사적 맥락까지 포착해 제안합니다.

시각-언어 모델(VLM, Vision-Language Model)이란?

VLM은 이름 그대로 시각 정보(Vision)와 언어 정보(Language)를 통합적으로 처리하는 AI 모델입니다. 컴퓨터 비전 기술이 이미지 속 사물을 ‘강아지’, ‘햇살’처럼 개별 객체로 분류하거나 위치를 찾는 데 그쳤다면, VLM은 이미지 전체의 서사와 감정적 맥락을 인간의 언어 체계와 유기적으로 연결하여 이해합니다. “무엇이 있는가?”를 넘어 “어떤 분위기 속에서 어떤 일이 일어나고 있는가?”를 서술할 수 있게 된 것입니다.

이러한 혁신적인 변화의 핵심은 공통 잠재 공간(Shared Latent Space)에서의 데이터 정렬 기술에 있습니다. AI는 이미지를 단순히 픽셀의 집합으로 보는 것이 아니라, 픽셀의 패턴(예: 따스한 조명의 각도, 부드러운 피사체의 질감)을 추출하여 이를 인간의 추상적인 언어 개념인 ‘포근함’이나 ‘평화로운 낮잠’이라는 단어와 일치시킵니다. 이렇게 픽셀 데이터가 언어적 의미를 획득하게 됩니다.

여기서 디자이너의 하네스는 AI가 생성한 텍스트가 브랜드 고유의 보이스&톤, 그리고 철학적 일관성과 맞아떨어지는지 최종 검수하는 역할을 수행합니다.

기술적 복잡성에 매몰되지 않으면서도 콘텐츠의 포용성을 확보하고, 서비스의 품격을 결정짓는 마지막 디테일을 지켜내는 것. 이것이 바로 지능형 도구를 다루는 현대 디자이너의 진화된 책무입니다.

<출처: 작가, tailwindapp 캡처>

엣지 케이스에 대응하는 시뮬레이션

완벽하다고 믿었던 디자인이 실제 환경에서 무너지는 순간이 있습니다. 이런 엣지케이스는 디자이너와 개발자에게 예상치 못한 불청객처럼 찾아옵니다. 그러나 이를 대응하지 못하면 프로라고 말하기 어렵습니다.

이제 우리는 AI를 활용해 인간의 상상력이 미처 닿지 못했던 극단적인 상황, 즉 엣지 케이스를 시뮬레이션하고 이를 선제적으로 방어할 수 있습니다.

시각적 완결성의 자동 검증: Applitools

과거에는 다양한 디바이스와 환경에 대응하기 위해 화면을 일일이 복제하고 대조하는 수작업이 필요했습니다. 특히 텍스트 길이가 극단적으로 길어지는 언어(독일어 등)나, 오른쪽에서 왼쪽으로 읽는 RTL(아랍어·히브리어 등) 환경은 디자이너에게 상당한 부담이었습니다.

이를 위해 Applitools AI는 인간의 눈처럼 화면을 인지하고 분석합니다. 수백 개의 가상 브라우저와 디바이스 환경에서 디자인을 실시간으로 렌더링하며 다양한 엣지 케이스를 찾아냅니다.

예를 들어 사용자 이름이 지나치게 길어 버튼 밖으로 튀어나가거나, 상품명이 세 줄 이상으로 늘어났을 때 레이아웃이 겹치는 문제 같은 동적 데이터 이슈를 탐지합니다. 또한, 아랍어 환경에서 프로필 이미지가 왼쪽에 있어야 하지만 오른쪽에 그대로 남아 있는 등 RTL 미러링 오류도 잡아냅니다. 여기에 더해 노치 디자인이 있는 기기에서 상단 바 아이콘이 가려지거나, 저사양 기기에서 폰트 렌더링이 뭉개지는 미세한 픽셀 단위의 오차까지 탐지하며 디바이스 파편화를 방지합니다.

이러한 엣지 케이스 오류를 발견하면 Applitools는 즉시 디자이너에게 확인을 요청하는 시각적 회귀 테스트를 수행합니다. 그 덕분에 디자이너는 수작업 기반의 전수 조사에서 벗어나, 시스템의 시각적 안정성을 높이는 데 집중할 수 있습니다.

<출처: applitools 자동 테스팅>

사용자 시나리오 맞춤 대응: Synthetic Users

기술적 결함을 넘어 사용자의 심리나 상황의 변수까지 선제적으로 점검하는 일은 서비스의 성패를 좌우하는 핵심 과업입니다. 최근 주목받는 Synthetic Users 같은 AI 에이전트 서비스는 가상의 페르소나를 디지털 환경에 주입해 디자인의 실질적인 사용성을 실시간으로 검증합니다. 이는 디자이너가 하나하나 통제할 수 없었던 사용자의 주관적 영역에 정교한 고삐를 채우는 과정이기도 합니다.

예를 들어 고령 사용자 페르소나인 ‘70대 알렉스’는 디지털 리터러시가 낮고 시각적 인지 능력이 다소 떨어지는 사용자입니다. AI는 이 페르소나를 통해 추상적인 아이콘 의미를 이해하지 못하거나, 작은 텍스트 크기 때문에 정보 구조 안에서 길을 잃는 지점을 정확히 짚어냅니다.

또 다른 예로 상황적 제약을 가진 페르소나인 ‘바쁜 직장인 브라이언’은 멀티태스킹 상황에서 극도의 시간 압박을 느끼는 사용자입니다. 이 경우 AI는 정보 계층 구조가 지나치게 복잡하거나, 불필요한 팝업 인터럽트가 발생할 때 사용자가 느끼는 피로도와 즉각적인 이탈 구간을 시뮬레이션합니다.

AI 에이전트는 이러한 특성을 반영해 서비스를 직접 탐색하고, 사용자가 어디서 행동을 멈추고 어디서 결정을 망설이는지에 대한 마찰 지점 데이터를 리포트합니다. 이제 우리는 “사용자가 왜 여기서 멈췄을까?”를 머릿속으로 추측하는 가설 단계에 머물지 않습니다. 대신 AI가 점검해온 객체화된 행동 데이터를 바탕으로 서비스 고도화와 개선 의사결정에 집중하게 됩니다.

결국 이러한 지능형 도구의 활용은 우리를 단순한 검수자의 역할에서 해결책을 설계하는 전략가의 영역으로 끌어올립니다. “무엇이 틀렸는가?”를 찾는 수동적 태도에서, “어떻게 완성도를 높일 것인가?”를 고민하는 능동적 태도로의 전환. 이것이 바로 AI 시대의 하네스 엔지니어링이 선사하는 진짜 묘미입니다.

<출처: syntheticusers 유저 생성과 인터뷰 진행>

최종 심미안을 갖춘 정서적 공명과 브랜드 철학의 관점

지금까지 기술적 결함을 제거하고 시스템 효율을 극대화하는 하네스의 역할을 소개했다면, 마지막으로는 그 고삐를 쥔 기수, 즉 디자이너의 본질적인 감각에 대한 이야기를 해볼까 합니다. AI가 시스템적으로 무결하고 기술적으로 완벽한 디자인을 만들어냈다고 해도, 그것이 정말 사용자의 마음을 움직이는 좋은 디자인인가에 대한 문제는 또 다른 차원의 영역이기 때문입니다.

바로 이 지점에서 디자이너만의 독보적인 가치인 심미안이 발휘됩니다. 이는 단순히 시각적 아름다움을 넘어, 브랜드의 영혼과 사용자의 감성을 잇는 정서적 점검까지 포함합니다.

예를 들어 저는 ‘따뜻함’과 ‘인간 중심의 직관’이라는 디자인 철학을 가지고 일합니다. 이를 실제 서비스 환경에 적용해보면 어떨까요?

AI가 설계한 보험 서비스의 ‘사고 접수 완료’ 화면은 정보 구조 측면에서 매우 효율적이고 명확할 것입니다. 하지만 예기치 못한 사고로 당혹감과 불안을 느끼는 사용자가 이 화면을 마주한다면 상황은 달라집니다. AI가 제안한 경직된 시스템 폰트와 차가운 원색의 체크 아이콘, 그리고 “접수가 완료되었습니다”라는 건조한 문구는 사용자에게 기능적인 편리함은 줄지언정, 정서적인 안도감까지 줄 수는 없습니다.

바로 이 순간, 디자이너의 하네스가 다시 작동합니다. AI가 내놓은 매끈한 정답지에 인간의 온도를 불어넣는 일입니다. 버튼 모서리의 곡률을 미세하게 조정해 시각적 긴장감을 완화하고, 마이크로 카피에 브랜드 철학이 담긴 다정한 위로의 톤 앤 매너를 입히는 과정입니다.

<출처: 작가>

이렇게 기술이 복잡성을 삼켜 인터페이스 뒤편으로 사라질수록, 마지막까지 남아 사용자의 삶을 어루만지는 것은 결국 사람의 상황을 깊이 이해하려는 디자이너의 태도입니다. AI가 99%의 논리적 완결성을 구축하더라도, 사용자와 서비스가 깊게 공명하도록 만드는 마지막 1%의 울림은 오직 인간 디자이너의 예민한 점검을 통해서만 완성됩니다.

마치며

AI 덕분에 생산력이 상향 평준화된 지금, 누가 더 많이 그리고 더 빠르게 만드느냐는 더 이상 변별력이 되지 않습니다. 그 영역은 이미 AI가 가져갔습니다. 이제 우리가 스스로에게 던져야 할 질문은 하나입니다.

“우리는 무엇을 점검할 수 있는가?”

브랜드의 일관성이 흔들리는 순간을 알아채는 감각, 기술적 결함이 사용자 경험을 갉아먹기 전에 먼저 막아내는 판단력, 그리고 AI가 완성한 화면에 사람의 온도를 불어넣는 태도. 이런 역량은 프롬프트 한 줄로 만들어지지 않습니다. 수백 번의 시행착오와 사용자의 표정을 직접 목격한 경험, 그리고 사람을 향한 진심 어린 시선이 쌓여야 비로소 만들어지는 능력입니다. 그것이 바로 하네스 엔지니어링의 본질이며, AI가 결코 대체할 수 없는 디자이너만의 데이터셋입니다.

기술이 평준화될수록 경험의 깊이가 차별점이 됩니다. 생산은 AI에게 맡기더라도, 그 고삐(Harness)만큼은 절대 놓지 마십시오. 여러분이 현장에서 쌓아온 모든 경험이야말로, 가장 귀한 자산이기 때문입니다.

]]>

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

본문은 요즘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 같은 기계용 인터페이스가 있는지 확인하는 것부터 시작할 수 있습니다.
내가 속한 산업에서 수십 년간 바뀌지 않은 소프트웨어가 뭔지 떠올려보기. 그게 아직도 스프레드시트로 관리되고 있다면 기회일 수 있습니다.

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

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

]]>

스프링 부트(Spring Boot)는 왜 아직도 살아남았을까?

유행은 빨리 바뀌는데, 왜 현장은 아직도 스프링일까요?

<출처: 작가>

기술 세계는 정말 빨리 바뀝니다. 어제까지 뜨겁던 기술이 몇 년 뒤에는 조용해지고, 또 다른 이름의 프레임워크가 등장합니다. 그래서 백엔드를 처음 공부하는 분들은 종종 이렇게 생각합니다. “스프링은 너무 오래된 거 아닌가?” 저도 처음에는 비슷했습니다. 처음 스프링 프로젝트를 열었을 때 느낀 인상은 솔직히 무겁고, 복잡하고, 파일도 많고, 구조도 딱딱하다는 쪽에 가까웠습니다. Controller, Service, Repository, DTO, Entity가 한꺼번에 보이면 괜히 숨이 턱 막히기도 했습니다.

그런데 이상하게도 한국에서 일할 때도 스프링을 봤고, 일본에서 일할 때도 또 스프링을 봤습니다. 더 흥미로웠던 건 단순히 예전부터 쓰던 기술이라서 남아 있는 게 아니라는 점이었습니다. 회의에서 기술을 고를 때도 “요즘 유행해서”가 아니라 “운영하기 편해서”, “인수인계가 쉬워서”, “기존 시스템과 잘 맞아서”, “장애가 나도 추적이 쉬워서” 같은 이유로 선택되는 장면을 자주 봤습니다.

한 번은 일본 프로젝트에서 이런 말을 들은 적이 있습니다. “새로운 기술도 좋지만, 이건 5년 뒤에 다른 사람이 들어와도 이해할 수 있어야 합니다.” 그 말을 듣고 조금 뜨끔했습니다. 저는 기술을 볼 때 얼마나 새롭고 멋진가를 먼저 봤는데, 현장은 얼마나 오래 버틸 수 있는가를 먼저 보고 있었기 때문입니다. 그때부터 스프링을 보는 눈이 조금 달라졌습니다. 이건 단순히 오래된 기술이 아니라, 오래 굴려도 쉽게 무너지지 않도록 정리된 구조일 수 있겠다고 느꼈습니다.

그래서 이번 글에서는 스프링 부트 아키텍처를 교과서처럼 설명하기보다, 왜 이 구조가 한국과 일본의 실무 현장에서 여전히 살아남고 있는지 이야기해 보려고 합니다. 중요한 건 “옛날 기술인가?”가 아니라 “왜 아직도 선택되는가?”였기 때문입니다.

처음 보면 복잡한데, 왜 이 구조를 계속 쓸까요?

<출처: 작가>

스프링 부트를 처음 배우면 가장 먼저 드는 생각은 아마 이것일 겁니다. “왜 이렇게 나눠놨지?” 간단한 기능 하나를 만들 뿐인데도 Controller가 생기고, Service가 생기고, Repository가 생깁니다. 거기에 Entity와 DTO까지 붙으면 작은 기능 하나가 제법 큰 구조처럼 보입니다. 처음 배우는 입장에서는 솔직히 부담스럽습니다.

그런데 흐름만 놓고 보면 구조 자체는 단순합니다. 사용자가 요청을 보내면 Controller가 받고, 비즈니스 로직은 Service가 처리하고, 데이터 저장과 조회는 Repository가 맡습니다. 이걸 어렵게 느끼게 만드는 건 구조의 개수보다도 아직 역할 감각이 익숙하지 않기 때문입니다. 어떤 코드는 어디에 두는 게 맞는지 감이 안 잡히니까 모든 레이어가 다 비슷해 보이고, 그래서 괜히 복잡해 보이는 겁니다.

하지만 프로젝트가 조금만 커지면 이 분리가 왜 필요한지 서서히 보이기 시작합니다. 회원가입 기능 하나만 생각해 봐도 입력값 확인, 중복 검사, 암호화, 저장 로직이 전부 한 파일에 들어가면 처음엔 빨라도 나중엔 수정이 무섭습니다. 결국 스프링의 계층형 구조는 멋있게 나누기 위한 구조가 아니라, 나중에 덜 엉키기 위해 미리 나눠두는 구조에 가깝습니다. 저는 예전엔 이걸 정석이라서 따라야 하는 규칙처럼 받아들였는데, 실무를 겪고 나니 헷갈림을 줄이기 위한 약속에 더 가깝다는 걸 알게 됐습니다.

혼자 만들 때는 귀찮은데, 팀 개발에서는 왜 갑자기 강해질까요?

<출처: 작가>

개인 프로젝트에서는 스프링 구조가 꽤 답답하게 느껴질 수 있습니다. 간단한 API 하나를 추가하려고 해도 파일이 늘어나고, 손이 많이 갑니다. “그냥 한 파일에 다 넣으면 더 빠른데?”라는 생각이 드는 것도 이상한 일이 아닙니다. 그런데 사람이 늘어나는 순간 상황이 완전히 달라집니다.

프론트엔드 개발자가 요청 형식을 바꿔 달라고 할 수 있고, 기획자가 조건을 수정할 수도 있고, DB 구조가 바뀌는 일도 생깁니다. 이때 코드가 한곳에 뒤엉켜 있으면 수정 범위를 찾는 것부터 오래 걸립니다. 반대로 계층이 나뉘어 있으면 길을 잡기가 쉽습니다. 요청과 응답 모양이 바뀌면 Controller를 보면 되고, 업무 규칙이 바뀌면 Service를 보면 되고, 저장 방식이 바뀌면 Repository를 보면 됩니다. 이건 단순히 코드 스타일의 문제가 아니라 협업 비용이 줄어드는 문제입니다.

누가 어느 부분을 맡아야 하는지가 보이고, 서로 건드리는 범위가 줄고, 변경 영향도 파악이 쉬워집니다. 팀 프로젝트에서 이 차이는 생각보다 엄청 큽니다. 저는 일본 프로젝트에서 이 장면을 꽤 자주 봤습니다. 설계서가 먼저 나오고, 담당이 나뉘고, 테스트 담당이 따로 붙는 흐름이 많았는데, 구조가 명확하면 문서와 코드가 서로 잘 맞아떨어졌습니다. 반대로 구조가 애매하면 설명도 길어지고, 인수인계도 어려워졌습니다.

중간에 투입된 개발자 한 분이 프로젝트를 보더니 “아, 흐름이 보이네요”라고 말한 적이 있었습니다. 그 한마디가 오래 남았습니다. 좋은 구조는 지금 쓰는 사람보다 다음에 들어올 사람이 길을 잃지 않게 해주는 구조라는 뜻처럼 들렸기 때문입니다.

한국에서 스프링이 쉽게 사라지지 않는 이유

<출처: 작가>

한국에서 스프링이 여전히 강한 이유를 “익숙해서”라고만 설명하면 조금 부족합니다. 익숙함은 분명한 이유 중 하나지만, 그것만으로 이렇게 오래 버티기는 어렵습니다. 한국의 실무 환경에서는 여전히 안정성과 표준화가 중요한 영역이 많습니다. 공공, 대기업, SI, 장기 운영 시스템처럼 실패 비용이 큰 프로젝트일수록 “새롭다”보다 “검증됐다”가 더 중요해집니다.

실제 프로젝트에서 자주 나오는 질문도 비슷합니다. 정말 안정적으로 돌아가는가, 기존 시스템과 잘 붙는가, 사람을 구하기 쉬운가, 문서와 사례가 충분한가. 이 기준에서 보면 스프링은 꽤 강합니다. 이미 많은 시스템이 Java와 스프링 기반으로 운영되고 있고, 관련 경험을 가진 개발자도 많습니다. 교육 자료도 많고, 문제 해결 사례도 풍부합니다. 즉, 기술 하나만 있는 게 아니라 운영 경험까지 같이 쌓여 있는 기술입니다.

여기에 레거시 시스템도 큰 이유가 됩니다. 이미 잘 돌아가고 있는 시스템이 스프링 기반이라면, 그걸 완전히 다른 기술로 갈아타는 건 생각보다 큰일입니다. 비용도 들고, 리스크도 크고, 연동 문제도 따라옵니다. 그래서 실무에서는 전부 새로 만드는 것보다 기존 구조를 유지하면서 확장하는 쪽이 더 현실적인 선택이 됩니다. 저는 이걸 한국 실무의 특징 중 하나라고 느꼈습니다. 새 기술을 싫어해서가 아니라, 망가지지 않는 기술을 더 높게 평가하는 분위기가 있다는 점입니다. 스프링은 바로 그 기준에서 오래 점수를 받아온 기술이었습니다.

일본에서는 왜 더 잘 맞아 보였을까요?

<출처: 작가>

일본에도 스프링이 자주 보입니다. 다만 제가 현장에서 느낀 이유는 한국과 조금 결이 달랐습니다. 한국이 검증된 운영 경험을 중요하게 본다면, 일본은 거기에 더해 예측 가능한 절차를 아주 중요하게 보는 느낌이 있었습니다. 특히 문서 기반 개발 문화가 강한 현장일수록 이 차이가 더 크게 보였습니다.

일본에서는 설계서가 먼저 나오고, 그 설계서를 기준으로 개발이 이어지는 경우가 많았습니다. 이때 Controller, Service, Repository처럼 역할이 구분된 구조는 문서와 코드가 잘 맞습니다. 요청은 어디서 받고, 규칙은 어디서 처리하고, 저장은 어디서 하는지가 비교적 명확하기 때문입니다. 반대로 구조가 너무 자유롭거나 작성자 취향이 강하면 문서와 실제 구현 사이가 멀어집니다. 그러면 개발도 어렵지만 유지보수는 더 어려워집니다. 결국 설명 비용이 커지고, 인수인계 비용도 커집니다.

일본에서 긴 프로젝트를 많이 본 것도 인상적이었습니다. 1년 안에 끝나는 일보다 3년, 5년 이상 이어지는 프로젝트가 적지 않았고, 그동안 담당자가 바뀌는 일도 많았습니다. 이런 환경에서는 지금 만든 사람이 제일 잘 아는 구조보다 다음 사람이 빨리 파악할 수 있는 구조가 훨씬 중요합니다. 그 점에서 스프링은 일본 실무와 잘 맞았습니다. 화려하진 않지만 익숙하고, 설명하기 쉽고, 예측하기 좋기 때문입니다.

처음 보는 프로젝트의 백엔드 흐름을 따라가야 했던 적이 있었는데, 구조가 익숙해서 생각보다 빨리 읽혔습니다. 그때 좋은 구조는 천재적인 구조가 아니라 낯선 사람도 들어올 수 있는 구조일 수 있겠구나 싶었습니다.

실무에서 느낀 진짜 장점은 ‘멋짐’보다 ‘안정감’

<출처: 작가>

스프링 부트의 장점을 말할 때 흔히 생산성, 생태계, 확장성을 이야기합니다. 전부 맞는 말입니다. 하지만 현업에서 오래 보다 보면 조금 더 현실적인 장점이 눈에 들어옵니다. 첫 번째는 길을 잃지 않게 해준다는 점입니다. 프로젝트가 커질수록 새 기능을 만드는 시간보다 기존 기능을 수정하거나 버그를 추적하는 시간이 더 길어집니다. 이때 구조가 정리되어 있으면 어디서부터 봐야 할지가 보입니다.

두 번째는 팀의 대화가 쉬워진다는 점입니다. “이건 Controller에서 처리할까요?”, “이건 Service 책임 같아요”, “DB 쪽은 Repository에서 보면 되겠네요” 같은 말이 통하기 시작하면 회의가 짧아지고 오해도 줄어듭니다. 세 번째는 시간이 지날수록 진가가 드러난다는 점입니다. 신규 프로젝트는 사실 어떤 기술로도 그럴듯하게 만들 수 있습니다. 문제는 2년 뒤, 3년 뒤입니다. 요구사항이 쌓이고, 예외 처리가 늘고, 담당자가 바뀌기 시작하면 구조의 체력이 드러납니다.

제가 봤던 프로젝트 중에는 처음엔 정말 세련돼 보였지만, 시간이 지나자 작성자만 이해하는 코드가 되어버린 경우도 있었습니다. 반대로 아주 화려하지는 않아도 구조가 일정해서 오래 읽히는 프로젝트도 있었습니다. 그 경험 이후로는 저도 코드의 첫인상보다 “이거 3년 뒤에도 읽힐까?”를 더 자주 보게 됐습니다. 어쩌면 실무에서 중요한 건 가장 멋진 기술이 아니라 가장 덜 놀라게 하는 기술일지도 모르겠습니다. 스프링은 꽤 자주 그 역할을 해줬습니다.

단점은 처음 배울 때 지치기 쉽다는 것

<출처: 작가>

여기까지 보면 스프링이 거의 정답처럼 느껴질 수도 있습니다. 하지만 당연히 단점도 있습니다. 그리고 그 단점은 특히 주니어에게 꽤 크게 다가옵니다. 가장 먼저 느끼는 건 무게감입니다. 작은 기능 하나에도 구조가 커지고, 어노테이션(Annotation)도 많고, 설정도 많습니다. 화면에서 바로 결과가 보이는 프론트엔드와 달리 처음에는 손이 많이 가는데 성과는 천천히 보입니다.

코드가 장황해지기 쉽다는 점도 있습니다. 정석만 의식하다 보면 간단한 기능까지 과하게 분리하게 되고, 오히려 읽기 어려워지는 경우도 있습니다. 구조가 있다고 해서 자동으로 좋은 코드가 되는 건 아닙니다. 또 많이 겪는 문제가 Service 비대화입니다. 처음에는 Controller를 가볍게 만들겠다고 시작했는데, 나중에는 모든 조건문과 예외 처리, 외부 API 호출이 Service 하나에 몰립니다. 결국 복잡함이 사라진 게 아니라 자리를 옮긴 것뿐인데도 초반에는 이걸 잘 못 느끼기도 합니다.

저 역시 처음에는 Controller, Service, Repository를 그냥 외웠습니다. 그런데 어느 순간 제 코드에서 “왜 이 로직이 여기에 있지?”라는 질문에 스스로 답을 못 하겠더라고요. 그때부터 생각이 조금씩 바뀌었습니다. 스프링은 외울 구조가 아니라, 왜 나누는지를 이해해야 하는 구조였습니다. 그걸 깨닫고 나서야 조금 덜 답답해졌습니다.

주니어 개발자라면 이 다섯 가지만 꼭 기억하기

<출처: 작가>

스프링 부트를 공부하거나 실무에서 막 쓰기 시작한 분들에게는 거창한 원칙보다 바로 적용할 수 있는 감각이 더 중요합니다. 제가 실제로 부딪히며 느낀 기준을 다섯 가지로 정리해 보겠습니다.

첫째, 처음부터 완벽한 구조를 만들려고 하지 않아도 됩니다. 작은 프로젝트에서는 단순함이 더 중요하고, 나중에 분리할 수 있게만 작성해 두면 충분합니다.
둘째, Controller는 최대한 얇게 두는 편이 좋습니다. 요청받고 응답을 내보내는 역할에 집중시키면 흐름이 훨씬 깔끔해집니다.
셋째, Service에 모든 걸 몰아넣지 마세요. 정말 흔한 실수이고, 로직이 커지기 시작하면 기능별로 쪼개고 책임을 다시 나누는 습관이 필요합니다.
넷째, Repository는 DB 접근에 집중시키는 게 좋습니다. 비즈니스 판단까지 Repository에 들어가기 시작하면 나중에 로직 추적이 힘들어집니다.
다섯째, 디버깅할 때는 요청 흐름을 손으로 적어보세요. 요청이 어디로 들어와서 어디를 거쳐 저장되는지 그려보면, 머릿속에서는 복잡하던 것도 생각보다 단순하게 보입니다.

이 다섯 가지는 대단한 비법은 아닙니다. 하지만 실무에서는 이런 기본기가 오래 갑니다. 특히 스프링 같은 구조형 프레임워크는 많이 안다고 잘 쓰는 게 아니라, 책임을 헷갈리지 않게 둘 줄 알아야 잘 쓴다고 느꼈습니다.

그래서 지금도 배워야 할까요?

제 대답은 분명합니다. 여전히 배울 가치가 충분합니다. 그 이유는 단순히 아직도 많이 쓰이기 때문만은 아닙니다. 더 중요한 이유는 스프링을 배우는 과정에서 백엔드의 기본 감각을 함께 익히게 되기 때문입니다. 요청 처리와 비즈니스 로직, 데이터 접근을 어떻게 나눌지 고민하는 과정은 특정 프레임워크를 넘어 계속 남습니다. 나중에 다른 언어를 쓰더라도, 다른 구조를 만나더라도 이 감각은 분명히 도움이 됩니다.

처음에는 누구나 “어떻게 빨리 만들지?”를 먼저 생각합니다. 그런데 어느 순간부터는 “이걸 어디에 둬야 나중에 안 힘들지?”, “바뀌면 어디를 수정해야 하지?”를 생각하게 됩니다. 그 질문이 생기기 시작하면 개발자는 조금 달라집니다. 바로 그때부터 단순히 코드를 짜는 사람에서 구조를 고민하는 사람으로 넘어가기 시작합니다. 그래서 저는 스프링 부트를 평생 이것만 써야 하는 기술이라기보다, 백엔드 사고방식을 익히게 해주는 좋은 훈련장에 가깝다고 느꼈습니다.

중요한 건 최신 기술이냐가 아니라, 왜 선택되는가입니다

스프링 부트는 가장 새롭고, 가장 가볍고, 가장 화려한 기술은 아닐 수 있습니다. 하지만 한국과 일본의 실무 현장에서는 여전히 꽤 현실적인 선택지로 남아 있습니다. 그 이유는 생각보다 단순합니다. 협업하기 좋고, 설명하기 쉽고, 유지보수에 유리하기 때문입니다.

우리는 기술을 볼 때 자주 “최신인가, 오래됐는가”를 먼저 묻습니다. 하지만 실무는 조금 다른 질문을 던집니다. 이걸 오래 굴릴 수 있는가, 누가 들어와도 이해할 수 있는가, 문제가 생겼을 때 빨리 찾을 수 있는가. 그리고 바로 그 질문 앞에서 스프링 부트는 아직 꽤 강합니다.

그래서 지금 스프링을 공부하고 계신다면, 단순히 문법이나 어노테이션을 외우는 데서 멈추지 않으셨으면 합니다. 왜 Controller와 Service를 나누는지, 왜 이 로직을 이 위치에 두는지, 왜 이런 구조가 팀에 유리한지까지 생각해 보면 좋겠습니다. 그 질문에 대한 답을 스스로 설명할 수 있게 되는 순간, 스프링은 외워야 할 기술이 아니라 이해할 수 있는 구조가 됩니다. 그리고 그때부터는 단순히 코드를 쓰는 개발자가 아니라, 기술이 왜 선택되는지를 말할 수 있는 개발자로 한 단계 올라갈 수 있죠.

스프링 부트가 아직도 쓰이는 이유는 결국 하나입니다. 낡아서 남은 것이 아니라, 버틸 수 있어서 남았습니다.

]]>

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명을 추첨해 초청해 드립니다. 무료 행사인 만큼 자리가 빠르게 마감될 수 있으니 관심 있는 분은 서둘러 신청해 주세요.

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

]]>

플랫폼은 어떻게 가짜 신규 고객을 걸러낼까?

국내 주요 이커머스 플랫폼들은 신규 가입자를 유치하기 위해 강력한 웰컴 후킹 정책을 운영합니다. 100원 딜이나 고액 쿠폰이 대표적입니다. 그러나 이런 혜택은 신규 고객 확보에 효과적인 만큼, 이를 악용하는 ‘체리피커’를 불러들이기도 합니다.

체리피커는 단순히 혜택만 받아 가는 고객에 그치지 않는데요. 고객 획득, 전환율 같은 핵심 지표를 오염시키고, 막대한 마케팅 비용 손실까지 초래할 수 있습니다. 따라서 플랫폼은 먼저 ‘고객’을 어떻게 정의할 것인지부터 명확히 해야 합니다. 이후 고객의 특성을 진단하고, 순도 높은 고객을 확보하기 위한 데이터 전략을 세워야 합니다.

이번 글에서는 가입 정책을 ‘비즈니스 필터’의 관점에서 살펴봅니다. 본인인증(CI/DI)과 기기 식별(Device ID)이 중복 가입과 체리피커를 막고, 데이터 무결성을 지키는 방식을 짚어봅니다. 또한 법적 휴면제 폐지 이후 데이터 정책이 ‘보유’ 중심에서 ‘수익성 기반 타겟팅’으로 어떻게 전환되어야 하는지도 함께 살펴보겠습니다.

플랫폼은 어떻게 ‘한 사람 이상의 실체’를 찾아내는가?

다음은 국내 이커머스 플랫폼의 실제 사례를 바탕으로 한 리서치입니다.

1) 마켓컬리(Market Kurly)의 '100원 딜'과 배송지 정제

마켓컬리의 성장을 견인한 ‘100원 딜’은 체리피커의 주요 타깃이 되기 쉬운 정책입니다. 초기에는 가족 명의의 휴대폰 번호를 여러 개 확보한 뒤, 한 집으로 여러 개의 100원 상품을 주문하는 사례가 빈번했습니다. 당시에는 본인인증 제도가 적용되지 않았기 때문이죠.

실무 대응: 이에 마켓컬리는 휴대폰 번호 중복 체크뿐만 아니라, ‘배송지 주소 정제(Normalization)’ 로직을 도입했습니다. 동일한 배송지 주소에서 단기간에 여러 신규 가입자가 혜택을 신청할 경우, 시스템이 이를 이상 징후로 판단해 승인을 거절하거나 추가 본인인증을 요구하는 방식입니다. 이는 온라인 가입 정보만으로 고객을 판단하지 않고, 물리적 거주지를 기준으로 실사용자를 검증하는 오프라인 기반 방어책입니다.

본인인증이 없었던 컬리 100원딜 정책 <출처: 한겨레 기사>

이후 수정된 마켓컬리 약관 <출처: 마켓컬리>

2) 무신사(Musinsa)의 기기 식별(Device ID) 기반 차단

무신사는 커뮤니티 기반의 강력한 팬덤을 보유한 플랫폼입니다. 그러나 팬덤이 강한 만큼, 신규 가입 혜택이나 프로모션 정책의 허점이 사용자들 사이에서 빠르게 공유되기도 합니다.

실무 대응: 무신사는 앱 실행 시 기기 고유 식별자인 ‘Device UUID’를 수집해 계정 정보와 매칭합니다. 사용자가 다른 명의의 휴대폰 번호로 가입하더라도, 동일한 스마트폰에서 로그아웃과 재가입을 반복하며 ‘990원 딜’ 등을 이용하려 하면 구매를 제한하는 방식인데요. 예를 들어, “이미 혜택을 받은 기기입니다”와 같은 메시지를 노출해, 동일 기기에서의 반복 혜택 수령을 막을 수 있습니다. 이는 계정 팜(Account Farm)을 통한 마케팅 예산 탈취를 차단하는 핵심 수단입니다.

무신사 개인정보 수집 및 이용 동의 화면 < 출처: 무신사>

3) 알바몬(Albamon)의 이벤트 순도 관리

알바몬과 같은 채용 플랫폼은 단순 가입자 수보다 ‘이력서 작성’이라는 유효 행동이 더 중요합니다. 즉, 가입 자체가 아니라, 실제 구직 의사가 있는 사용자인지를 판단해야 합니다.

실무 대응: 알바몬은 가입 직후 경품을 지급하는 대신, ‘본인인증 완료 + 이력서 1회 저장’과 같은 복합 조건을 설정합니다. 단순 가입이 아니라, 실제 서비스 이용 의지를 확인할 수 있는 행동까지 요구하는 방식입니다. 이때 본인인증 API에서 활용하는 CI 값을 통해 과거 탈퇴 이력이 있는 사용자가 재가입 후 다시 경품만 받아가는 행위를 차단할 수 있습니다. 이는 이벤트 참여자의 순도를 높이고, 마케팅 비용이 실제 전환 가능성이 있는 사용자에게 쓰이도록 만드는 장치입니다.

4) 쿠팡이츠의 네트워크 식별

쿠팡은 앱 곳곳에 배너와 팝업을 배치해 와우 멤버십 가입, 쿠팡이츠 첫 주문 등을 적극적으로 유도합니다. 이처럼 마케팅 집행 규모가 큰 플랫폼일수록, 혜택이 실제 신규 고객에게 쓰이고 있는지 검증하는 장치가 중요합니다.

실무 대응: 동일한 명의가 아니더라도, 같은 와이파이(Wi-Fi)나 IP 주소(IP Address) 환경에서 짧은 시간 안에 복수의 신규 가입과 주문이 발생하면 시스템은 이를 ‘동일 환경’에서 발생한 행동으로 판단할 수 있습니다. 특히 첫 주문 할인 혜택이 큰 플랫폼에서는 동일 네트워크에서 반복 가입과 주문을 시도하는 작업장(Farm)을 막기 위해 이러한 식별 로직이 필요합니다. 이는 실명 인증만으로 걸러내기 어려운 비정상 패턴을 보완하는 방어책입니다.

CI/DI 수집, 가입창에 번호만 받으면 끝일까?

가장 중요한 포인트는 여기입니다. 가입창에 휴대폰 번호 입력 필드를 만드는 것만으로는 비즈니스 로직을 보호할 수 없기 때문인데요. 현실적으로 사용자가 직접 입력한 휴대폰 번호는 검증된 식별값이 아니라, 단순한 ‘텍스트’에 가깝습니다. 예를 들어, 010-1234-5678로 가입한 사용자가 탈퇴한 뒤, 010-1234-5679로 다시 가입하는 것을 막기는 어렵습니다.

1) 기획자가 도입해야 하는 진짜 정책

CI와 DI
가입 정책에서 중요한 것은 휴대폰 번호 입력이 아니라, 사용자를 식별할 수 있는 검증된 값을 수집하는 것입니다. 이때 핵심이 되는 값이 CI와 DI입니다.

CI(Connecting Information): 주민등록번호를 기반으로 생성되는 88바이트 고유값입니다. 통신사나 휴대폰 번호를 바꿔도 변하지 않는 ‘디지털 지문’에 가깝습니다. 따라서 타 서비스와의 연동이나, 평생 1회 혜택 제한처럼 강한 중복 방지 정책에 활용됩니다.
DI(Duplication Information): 해당 웹사이트 안에서만 유효한 고유값입니다. 서비스 내부에서 동일 사용자의 중복 가입 여부를 판단하는 데 쓰입니다.

본인인증 API 연동

이를 위해서는 NICE나 KCB 같은 본인인증 서비스를 연동해야 합니다. 사용자가 [인증하기] 버튼을 누르고 통신사 인증을 완료하면, 인증사는 우리 서버로 CI와 DI 값을 전달합니다. 여기서 중요한 점은 CI가 사용자가 직접 입력한 휴대폰 번호와 다르다는 것입니다. CI는 사용자가 개명을 하거나, 휴대폰 번호를 바꾸거나, 통신사를 옮겨도 변하지 않는 값입니다.

데이터의 흐름과 해결

데이터 흐름은 단순합니다. 사용자가 [인증하기] 버튼을 클릭하고 통신사 인증을 완료하면, 인증사가 우리 서버로 CI(88바이트 고유값)와 DI(사이트별 고유값)를 전달합니다. 이후 가입 완료 버튼을 누르기 직전, 서버는 우리 데이터베이스에 같은 CI 값을 가진 사용자가 이미 있는지 확인합니다.만약 같은 CI로 가입한 이력이 있거나, 이미 혜택을 받은 기록이 있다면 추가 혜택 지급을 제한할 수 있습니다. 이 과정은 0.1초 만에 처리되어야 하며, 바로 이 지점이 마케팅 예산을 지키는 ‘기획자의 기술적 방어선’입니다.

2) 추가 응용 아이디어

앞서 살펴본 것처럼 CI/DI는 중복 가입을 막는 핵심 식별값입니다. 이미 많은 글에서도 CI/DI의 개념과 필요성을 설명하고 있지만, 실제 서비스에서는 CI/DI만으로 모든 문제를 해결하기 어렵습니다.

먼저 본인인증 과정 자체가 고객 전환의 허들이 될 수 있습니다. 사용자가 가입 초반부터 인증 절차를 부담스럽게 느끼면, 혜택을 받기 전에 이탈할 가능성이 생깁니다. 또한 마켓컬리 사례처럼 ‘가족 단위’의 사용자를 필터링해야 하는 상황에서는 CI/DI만으로 한계가 있죠. 플랫폼에서 마케팅 대상은 언제나 ‘한 사람’이 아닙니다. 때로는 ‘한 가구’, ‘한 기기’, ‘한 결제 수단’처럼 다르게 정의되어야 합니다.

따라서 먼저 우리 서비스에서 ‘고객’을 어떻게 정의할 것인지 정하고, 그다음 그 정의에 맞는 보조 식별 정책을 함께 설계해야 합니다.

Device ID (ADID/IDFA):

광고 식별자인 ADID/IDFA나 기기 고유값(UUID)을 수집해 ‘기기당 1회 혜택’ 정책을 설계할 수 있습니다. 이는 본인인증을 우회하려는 부정 사용자를 막는 2차 방어선이 됩니다.

배송지 주소 정규화 및 거리 기반 로직(Address Normalization)

배송지 주소를 정규화해 동일 주소 여부를 판별하는 방식입니다. 상세 주소의 띄어쓰기, 특수문자, 표기 차이를 정리해 같은 주소를 같은 값으로 인식하도록 만듭니다.
예를 들어, ‘홍길대로 123 101호’와 ‘홍길대로123, 101호’는 사용자가 다르게 입력했지만, 실제로는 같은 주소일 수 있습니다. 이런 값을 동일 주소로 판단하면, 같은 가구에서 반복적으로 혜택을 받는 패턴을 걸러낼 수 있습니다.

결제 수단 지문(Payment Fingerprinting)

본인인증 명의가 다르더라도 결제 수단이 같다면 동일 사용자나 동일 가구일 가능성이 있습니다. 따라서 결제에 사용된 카드번호 일부 마스킹값이나 계좌번호의 해시값을 대조하는 방식도 활용할 수 있습니다.
이때는 약관과 안내 문구가 중요합니다. 예를 들어, “본 혜택은 결제 수단별 1회에 한해 제공됩니다”와 같은 기준을 명확히 고지해야 합니다. CI/DI가 달라도 결제 수단이 같다면 동일 혜택 적용을 제한할 수 있는 근거가 필요합니다.

기기 및 브라우저 지문(Device/Browser Fingerprinting)

Device UUID뿐만 아니라 접속한 브라우저 설정, 운영체제(OS) 버전, 화면 해상도 등을 조합해 고유한 식별값을 생성하는 방식입니다. 사용자가 본인인증을 우회하거나 브라우저를 초기화하더라도, 기기 고유의 특성을 통해 동일 기기 여부를 추정할 수 있습니다.
이는 단독 기준으로 사용하기보다는, 다른 식별 정책과 함께 활용하는 2차 방어선으로 설계하는 것이 적절합니다. 가입 정책의 목적은 사용자를 과도하게 막는 것이 아니라, 혜택의 대상을 더 정확히 정의하고 마케팅 예산이 새는 지점을 줄이는 데 있기 때문입니다.

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

비즈니스 성과, 마케팅 지표와 정책의 연결점

이러한 기술적 방어선은 단순한 보안 장치가 아닙니다. 마케팅 핵심 지표인 CPA(고객 획득 비용)와 LTV(고객 생애 가치)에 직접적인 영향을 미치는 비즈니스 정책입니다.

[마케팅 지표 의사결정 가이드]

<출처: 작가>

지표 연결점: 가입 정책에서 CI/DI 필터링을 강화하면, 단기적으로는 CPA가 상승하는 것처럼 보일 수 있습니다. 신규 가입자 수가 줄어들고, 인증 과정에서 이탈하는 사용자도 생기기 때문입니다. 하지만 이는 ‘가짜 회원’에게 쓰이던 매몰 비용이 제거되는 과정에 가깝습니다.

혜택만 받고 이탈하는 사용자를 걸러내면, 실제 활동 유저를 기준으로 한 Active CPA(실제 활동 유저당 비용)는 오히려 최적화됩니다. 결과적으로 마케팅 예산이 더 순도 높은 고객에게 집중되고, 전체 마케팅 ROI 개선으로 이어질 수 있습니다.

데이터 보유의 시대에서 '정제된 활용'의 시대로

2024년 개인정보 보호법 개정으로 휴면 회원 분리 보관 의무가 사라졌습니다. 이제 기획자와 마케터는 데이터를 ‘어떻게 보관할 것인가’보다, ‘어떻게 수익성 있게 분류하고 활용할 것인가’에 더 집중해야 하는데요. 무분별한 전체 메시지 발송은 비용 낭비일 뿐만 아니라, 브랜드 피로도까지 높일 수 있기 때문입니다. 법적 의무가 사라진 지금, 비즈니스 관점에서 ‘휴면’의 기준을 다시 정의해야 하죠.

결국 중요한 것은 보유한 데이터를 모두 활용하는 것이 아닙니다. 반응 가능성이 높은 사용자에게 마케팅 리소스를 집중할 수 있도록, 세그먼트 정책을 설계하는 것이 핵심이죠. 기획자가 촘촘하게 설계한 가입·회원 정책은 마케팅 비용의 누수를 막고, 회사의 재무 건전성을 지키는 강력한 도구가 될 수 있음을 기억해 두세요.

]]>

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

]]>

열심히 공부하는 당신이 서류조차 못 넘는 이유

오늘도 퇴근하고 지친 몸으로 다시 모니터 앞에 앉았습니다. 하루가 다르게 쏟아지는 새로운 기술 사이에서 도태되지 않으려고 유명한 강의를 결제하고 주말까지 반납해 가며 스터디에 참여합니다. 이력서에 한 줄이라도 더 쓰고자 여러 활동을 기웃거리고 기술 블로그까지 운영하는 등 남들이 하는 건 다 해봅니다.

하지만 정작 가고 싶은 회사의 서류 전형 결과는 또다시 ‘불합격’입니다. “귀하의 뛰어난 역량에도 불구하고…”로 시작하는 차가운 메시지를 볼 때마다 억울함과 막막함이 밀려옵니다. ‘여기서 더 노력해야 하는 건가?’, ‘더 어려운 기술을 공부해야 하나?’라는 자책이 꼬리에 꼬리를 물고 이어집니다.

최근 진행한 멘토링에서 이런 고민들을 마주했습니다. 한 멘티는 AI 시대를 맞아 신입과 주니어의 자리가 점점 좁아지는 현실을 불안해하며, 자신의 경력이 보잘것없게 느껴진다고 이야기했습니다. 10~20군데를 지원해도 돌아오는 답은 없고, 어떻게 개선해야 할지조차 모를 단순한 업무만 나열된 이력서가 주는 막막함. 이런 상황은 결코 한 사람만의 이야기가 아닐 겁니다.

하지만 냉정하게 말해보자면, 서류 합격에 실패하는 이유가 성실함이 부족하기 때문만은 아닙니다. 오히려 그동안 쌓아온 다양한 지식이 회사의 가려운 곳에 단 한 번도 닿지 못했기 때문일지도 모릅니다.

많은 사람이 채용을 실력순으로 줄 세우는 오디션처럼 생각하지만, 실제 채용 시장은 비어 있는 자리에 가장 잘 맞는 조각을 찾는 ‘퍼즐 맞추기’에 가깝습니다. 아무리 화려하고 단단한 조각이라도, 회사의 빈틈을 채울 수 있는 모양이어야 합니다.

<출처: 작가, Gemini 생성>

잠깐 사장의 입장이 되어보자

이 매칭 게임의 원리를 이해하기 위해, 아주 직관적인 비유를 들어보려고 합니다.

고깃집에서 고기 굽는 스킬보다 중요한 것

우리가 ‘고기 맛’에 자부심을 가진 숙성 고깃집 사장님이라고 가정해 봅시다. 입소문이 나고 손님이 몰려들어, 고기를 정성스럽게 구워줄 직원을 한 명 뽑아야 한다고요. 공고를 올리니 세 명의 지원자가 찾아왔습니다.

지원자 A: 솔직히 돈 벌려고 왔습니다. 시키는 건 무엇이든 하겠습니다.
지원자 B: 고기 굽는 스킬에 자신 있습니다. 이미 유명한 대형 고깃집에서 화려한 기술을 배워왔습니다.
지원자 C: 저는 평소 이 집의 숙성 방식이 너무 훌륭하다고 생각했습니다. 제 고기 굽는 실력으로 이 집 고기만의 풍미를 손님들에게 최대로 전달해 보고 싶습니다.

누구를 면접에 부르고 싶으신가요? 아마도 B와 C가 좀 끌릴 겁니다. 물론 당장 화려한 퍼포먼스가 급하다면 B도 좋지만, 그래도 ‘최고의 고기 맛’이라는 정체성을 유지하고 싶어 할수록 C를 선택할 가능성이 더 높아질 겁니다.

실력(B)보다 공감(C)이 매력적인 구조

사장님이 B를 선택하기 주저하는 이유는 그 아래 불안함이 있기 때문입니다. 이는 단순히 그가 고집 센 사람일지 모른다는 의심에 그치지 않습니다. 그의 기술이 우리 가게만의 맥락과 충돌할 때 발생하는 조율 비용에 대한 우려가 더 큽니다.

지원자 B와 온보딩 리스크

훌륭한 기술을 가졌지만, 그 기술은 다른 환경(대형 고깃집)에 최적화되어 있습니다. 사장님 입장에서는 B가 우리 방식에 자연스럽게 녹아들도록 설득하고 조율하는 데 에너지를 써야 할 수도 있습니다. 온보딩 리스크를 안게 된 겁니다. 이처럼 각자 방식이 충돌할 때 이를 바로잡는 과정에서 발생하는 유무형의 비용은 생각보다 큽니다.

지원자 C와 검증된 적합도

이미 가게의 지향점을 동경하며 지원했기 때문에, C는 사장님의 철학을 빠르게 흡수하고 발전시킬 준비된 파트너에 가깝습니다. 가르치는 사람과 배우는 사람의 관점이 일치할 때, 시너지가 가장 크게 일어납니다.

기술은 도구일 뿐, 비즈니스가 목적인 채용

기업의 채용 역시 이 고깃집의 상황과 같습니다. 많은 개발자는 자신의 고기 굽는 스킬(=기술 스택)이 얼마나 화려한지만을 증명하려 애씁니다. 하지만 회사는 그 스킬로 우리 회사의 맛(=비즈니스 가치)을 어떻게 구현할 것인지를 알고 싶어 합니다.

그러니 이력서를 제출하는 행위는 단순히 “내 실력을 사라”는 외침보다 “당신들이 추구하는 가치를 위해 내 기술을 이렇게 쓰겠다”라는 기술 제안서여야 합니다. 실력은 입장권에 불과합니다. 합격을 결정짓는 요소는 결국 회사가 정의한 문제와 나의 해결 관점이 얼마나 맞닿아 있는지, 즉 ‘적합성’에 달려 있습니다.

채용 공고는 ‘요구사항’이 아닌 ‘문제 정의서’

그렇다면 고깃집 사장의 ‘숙성과 맛’이란 철학은 실제 채용 현장에서 어떻게 찾아낼까요? 바로 당신이 무심코 지나쳤던 채용 공고(JD)에 그 철학이 있습니다.

JD의 행간 읽기

많은 개발자가 채용 공고를 볼 때 스크롤을 내려 ‘자격 요건’과 ‘우대 사항’에 적힌 기술 스택 목록을 먼저 훑어봅니다. 하지만 정작 중요한 정보는 공고의 가장 윗부분인 ‘조직 소개’와 ‘업무 내용’에 숨어 있습니다. 대부분의 문서는 처음이나 끝이 가장 중요하며, 채용공고는 특히 상단에 배치된 내용이 그 팀이 지금 가장 해결하고 싶어 하는 ‘아픈 지점’인 경우가 많습니다.

예를 들어, 어떤 회사가 채용 공고 상단에 영상까지 활용해 팀 문화를 설명한다면, 그것은 단순히 멋있어 보이기 위한 연출이 아닙니다. 그만큼 해당 메시지가 팀의 정체성을 유지하는 데 중요하다고 판단했기 때문입니다.

회사가 “실시간 데이터 처리에 진심인 분”을 찾는다고 말한다면, 그들은 지금 쏟아지는 데이터를 제때 화면에 뿌려주지 못해 사용자들의 불만을 듣고 있을 가능성이 큽니다. 이때 내가 해야 할 일은 “나는 리액트를 할 줄 안다”고 강조하는 것이 아닌 “나는 이런 상황을 해결하는 방법을 알고 있다”라고 남기는 것입니다. 바로 이런 행간을 읽어내야 합니다.

<출처: 작가, Gemini 생성>

로그 대신 해법을 던지는 이력서 전략

행간을 읽었나요? 이제 이력서는 내 과거를 기록한 단순 로그(Log)여서는 안 됩니다. 사람들은 “나는 이런 기술을 써봤고 이런 사람인데, 나를 데려갈 곳 있나요?”라는 공급자 중심 태도로 이력서를 뿌립니다. 특히 대다수의 주니어~미들급 개발자에게 로그만 나열된 이력서는 아무런 의미가 없는 문서일 뿐입니다.

하지만 채용 담당자가 매력을 느끼는 지원자는 다릅니다. 이들은 “당신들이 현재 겪고 있는 그 문제를, 내가 예전에 이런 방식으로 해결해 본 경험이 있으니 도와주겠다”라는 관점으로 접근합니다. 우리에게 이력서는 회사가 현재 겪고 있는 문제를, 내가 어떤 기술과 경험으로 해결할 수 있는지 보여주는 기술 제안서여야 합니다.

효과적인 제안서는 주장 → 근거 → 경험의 순서를 따릅니다. 단순히 프로젝트를 나열하기 전에, “나는 어떤 문제를 해결할 수 있는 개발자인가”라는 정체성을 먼저 주장하세요. 그리고 그 주장을 뒷받침할 수 있는 핵심 역량 키워드를 채용 공고의 요구에 맞춰 선별하고 배치해야 합니다.

채용 담당자는 수많은 이력서를 빠르게 훑어봅니다. 그러니 문서의 윗부분에 회사가 원하는 ‘적합성’이 드러나지 않는다면, 공들여 작성한 상세 경험으로 가지도 못한 채 휴지통에 들어갈 지도 모릅니다. 내 이력서가 매번 거절당하고 있다면, 혹시 ‘나’라는 사람을 설명하는 데만 집중한 나머지 ‘회사의 문제’를 외면하고 있었던 것은 아닌지 돌아볼 필요가 있습니다.

<출처: 작가, Gemini 생성>

로그가 그 자체로 힘을 발휘하는 상황

물론 과거의 기록인 로그가 그 자체로 강력한 힘을 발휘하는 예외적인 경우도 있습니다.

첫째, 동일한 도메인으로 수직 상승하는 경우입니다. 커머스에서 커머스로, 금융에서 금융으로 이직할 때는 자신의 로그 자체가 즉시 전력감임을 증명하는 보증서가 됩니다. 이전 직장에서 겪은 비즈니스 로직과 기술적 난제가, 새 회사의 고민과 거의 1:1로 맞닿아 있기 때문입니다.

둘째, 압도적으로 뛰어난 이력을 갖춘 경우입니다. 업계가 모두 인정하는 기업 출신이거나, 누구나 알 만한 오픈소스의 메인테이너라면 이름 자체가 하나의 제안서가 됩니다. 이 경우 기업은 과거 기록만으로도 ‘우리 문제를 해결해 줄 사람’이라는 확신을 갖고 먼저 러브콜을 보내기도 합니다.

적합성 매칭의 기술

“왜 우리 회사에 지원하셨나요?”라는 질문을 받으면, 흔히 “성장 가능성이 커 보여서”, “기술 스택이 마음에 들어서” 같은 칭찬 위주의 답변을 내놓기 쉽습니다. 하지만 기업이 진짜로 듣고 싶은 답은 회사에 대한 찬사가 아니라 ‘우리 회사의 문제’와 ‘나의 실력’ 사이의 교집합입니다.

적합성 매칭은 단순히 내 기술을 나열하며 일어나지 않습니다. 채용 공고에서 발견한 키워드와 나의 경험 사례를 1:1로 대응시키는 과정에서 비로소 완성됩니다. 이런 세 가지 단계를 써볼 수 있습니다.

1. 기업의 페인 포인트 추출

채용 공고 상단이나 영상에서 반복되는 단어를 찾아 보세요. 만약 “예측할 수 있는 코드의 중요성”이나 “변경에 유연한 아키텍처”를 강조한다면, 그 팀은 현재 코드 복잡도로 인해 유지보수에 어려움을 겪고 있을 가능성이 큽니다.

2. 내 경험을 키워드와 직렬화

만약 공고가 ‘주도적인 인재’를 원한다면, 단순히 코드를 잘 짠 경험만으로는 부족합니다. 대신 “전담 인력이 부재한 환경에서 기술 리딩을 주도해 프로젝트를 완수한 사례”를 전면에 내세워야 합니다. 같은 에러를 수정한 경험이라도, 회사의 관심사에 따라 ‘사용성 개선’이 될 수도 있고 ‘CS 대응 비용 절감’으로 해석될 수도 있습니다.

3. “오직 나만이 이 문제를 풀 수 있다”는 서사

“왜 이 회사여야 하는가”에 대한 답은 결국 “내가 가진 A라는 역량이 당신들이 겪고 있는 B라는 문제를 해결하는 데 가장 적합하기 때문”이라는 논리로 귀결되어야 합니다. 이 연결이 선명할수록, 채용 담당자는 나를 단순한 실력자가 아니라 ‘우리 팀에 꼭 필요한 조각’으로 인식하게 됩니다.

결국 적합성 매칭이란, 기업이 던진 질문(JD)에 대해 나의 과거 경험을 재료로 삼은 가장 적합한 해답, 즉 이력서를 제출하는 기술입니다. 이 매칭의 밀도가 높아질수록 면접 제안이 따라오게 됩니다.

경험을 재해석하자

그렇다면, 이러한 적합성을 최대로 잘 보여주려면 이력서에는 무슨 내용을 어떻게 담아야 할까요?

물경력을 구원해 줄 상황의 힘

‘물경력’이라며 스스로를 자책하는 개발자들의 이력서를 보면 공통적인 특징이 하나 있습니다. 바로 맥락 없이 결과 수치에만 과도하게 집착한다는 점입니다. 예를 들어 “10초 걸리던 로딩 속도를 1초로 줄였다”는 성과는 겉보기에는 인상적입니다. 하지만 이게 전부는 아닙니다. 여기에 상황에 대한 설명이 빠져 있다면, 채용 담당자에게는 그저 알맹이 없는 자랑처럼 비칠 뿐입니다.

왜 이런 결과가 알맹이 없는 자랑으로 보일까요? 수치 그 자체만으로는 나의 엔지니어링 수준을 온전히 설명할 수 없기 때문입니다. 다음의 두 사례를 비교해 보겠습니다.

케이스 A: 렌더링 최적화가 전혀 이루어지지 않은 환경에서, 단순히 n초마다 렌더링을 제한하는 라이브러리를 추가해 10초를 1초로 단축
케이스 B: 이미 대부분의 최적화가 적용된 복잡한 로직 안에서 미세한 비효율을 발견하고 데이터 구조 자체를 개선해 1초를 0.5초로 단축

단순히 수치 변화의 폭만 보면, 10초를 1초로 만든 A가 더 극적으로 보일 수 있습니다. 그러나 실제 엔지니어링 난이도와 사고의 깊이는 B가 훨씬 높습니다. A는 검색 한 번으로도 해결할 수 있는 ‘일단 동작하게 만드는’ 수준에 가깝습니다. 반면 B는 시스템 구조를 깊이 이해하고 판단해야 나오는 수준의 일입니다.

결국 상황을 포함하지 않은 수치는 자신의 실력을 드러내지 못하며, 우연히 운으로 얻은 결과처럼 보일 위험이 큽니다.

당신을 주니어로 가두는 결과 나열

무엇보다 개발자의 경력이 ‘단순 업무’로 평가절하받는 이유는 스토리가 빠진 결과만 나열되기 때문입니다.

“앱 초기 아키텍처 설계 및 스토어 배포”라는 한 줄은 크게 와닿지 않습니다. 하지만 여기에 “앱 전담 인력이 전무한 환경에서”라는 상황이 더해지는 순간, 이야기는 완전히 달라집니다. 이는 단순한 앱 배포를 기술 리딩과 문제 해결의 과정으로 확장해 주기 때문입니다.

스토어 배포 과정에서 겪었던 수많은 실패와 이를 해결하기 위해 아키텍처를 뒤엎으며 고민했던 시간들, 그리고 그 과정에서 내린 판단들이야말로 내가 ‘물경력’이 아님을 증명하는 진짜 알맹이입니다. 채용 담당자가 보고 싶은 것은 단순한 결과 수치가 아니라 그 결과에 도달하기까지 지나온 상황의 무게입니다.

문제 해결 정의의 확장

우리는 ‘문제 해결’을 지나치게 거창하게 생각하는 경향이 있습니다. 기술적으로 난도가 높은 알고리즘을 푸는 일만이 문제 해결은 아닙니다.

비즈니스 문제 해결: 운영팀의 요청에 따라 복잡한 기능을 새로 개발하는 대신, 텍스트 앞에 이모지 하나를 추가해 가독성을 높여 문제를 해결했다면, 이는 최고의 문제 해결 사례입니다. 개발 비용을 거의 들이지 않으면서도 사용자의 목적을 달성했기 때문입니다.
구조 문제 해결: 단순히 에러를 수정하는 데서 그치지 않고, 상황에 맞는 안내 메시지를 출력하도록 개선해 CS 대응 시간을 줄였다고 해봅시다. 이 또한 뛰어난 엔지니어링 판단입니다.

이처럼 작아 보이는 시도들도 이력서에는 ‘상황-판단-결과’의 구조로 드러나야 합니다. “무엇을 만들었다”보다는 “어떤 제약 속에서 무슨 맥락으로 문제를 해결했는가”가 중요합니다. 이 관점이 드러날 때, 비로소 나는 단순한 ‘코더’가 아니라 문제를 해결하는 ‘해결사’로 보이게 됩니다.

+ AI 시대의 생존법: 설계와 판단

인공지능(AI)은 개발 현장의 풍경을 완전히 바꾸어 놓았습니다. 이제 단순한 기능 구현이나 템플릿 형태의 코드를 작성하는 일은 AI가 인간보다 훨씬 빠르고 정확하게 수행합니다. 개발자들이 내 자리가 사라지는 건 아닌지 불안해하는 이유도 여기에 있습니다.

하지만 AI는 “초당 1,000명의 트래픽을 견디는 채팅 서버를 설계해달라”는 요청에는 즉각적인 답을 내놓지만, “우리 회사의 현재 예산과 비즈니스 상황에서, 지금 이 채팅 서버 설계가 최선인가?”라는 질문에는 답하지 못합니다. 그렇기 때문에 개발자의 ‘설계’와 ‘판단’ 능력은 그 어느 때보다 중요해졌습니다.

이처럼 진정한 실력은 정답이 정해진 코드를 작성하는 데서 드러나지 않습니다. 오히려 복잡한 맥락 아래 가장 적절한 선택지를 고르는 과정에서 드러납니다.

비즈니스 맥락의 이해: 1년 뒤 대형 고객사 유입 계획이나 회사의 자금 상황을 함께 고려해, 과도한 설계를 피하면서도 확장할 수 있는 구조를 선택하는 능력
도메인 특화 지식: 특정 산업군(금융, 커머스 등)이 가진 고유한 제약과 사용자 행동 패턴을 이해하고, 이를 기술 설계에 부드럽게 녹여내는 능력

AI가 대체하기 어려운 지점은 바로 이 ‘의사결정’의 영역입니다. 그러니 이력서에서 보여줘야 하는 건 AI도 짤 수 있는 코드가 아니라, 그 코드를 쓰기까지 내렸던 “수많은 판단의 근거”입니다.

채용은 경쟁이 아니라 매칭이다

우리는 지금까지, 열심히 공부하고도 서류 전형에서 고배를 마시는 개발자가 가진 구조적인 문제를 살펴보았습니다. 결국 모든 이야기는 하나의 길로 통합니다. 채용이 누가 더 뛰어난지를 가리는 ‘실력 경쟁’이 아닌 회사의 빈틈을 누가 가장 잘 채울 수 있는지를 확인하는 ‘적합성 매칭’ 게임이라는 점입니다.

이 진실 아래 채용을 준비할 때 반드시 염두해야 할 4가지 핵심을 정리했습니다.

1. 나는 ‘파트너’인가?

지원자들은 흔히 ‘내 경험 중 가장 잘난 것이 무엇인가’를 고민하며 이력서를 채웁니다. 하지만 채용 담당자의 시선은 전혀 다릅니다. 그들은 ‘우리 회사에 가장 잘 맞는 조각이 누구인가’를 찾고 있습니다. 회사가 나에게 맞추길 기대하기보다 내가 회사의 문제에 어떻게 기여할 수 있는지를 먼저 증명해야 합니다.

이력서에 쓰인 수많은 기술 스택보다 중요한 것은, 그 기술로 회사의 비즈니스를 어떻게 성장시킬 수 있는지 보여주는 ‘파트너십 관점’입니다.

2. 나열이 아닌 설득을 하고 있는가?

이력서는 단순히 정보를 나열하는 문서가 아닙니다. 수많은 지원자 사이에서 채용 담당자의 시선을 붙잡아 기준 필터를 통과할 때 쓸 전략적인 도구입니다.

자바스크립트에서 filter 함수를 사용해 원하는 데이터를 골라내듯, 채용 담당자 역시 “우리 회사에 맞는 사람인가”를 기준으로 이력서를 걸러냅니다. 이 필터를 통과하려면 이력서 상단에 강력한 주장이 먼저 배치되어야 합니다. “나는 이런 사람이며, 당신들의 이런 문제를 해결할 수 있다”는 정체성을 분명히 드러내세요. 그 뒤는 이를 입증하는 구체적인 근거와 경험이 자연스럽게 따라와야 합니다.

예를 들어, 주도적인 인재를 원하는 공고라면 단순히 “주도적이다”라고 쓰는 것만으로는 부족합니다. 대신 “인력 부재 상황에서 기술 리딩을 맡아 프로젝트를 완수한 경험”을 전면에 내세워야 합니다. 이러한 구조는 채용 담당자에게 내가 단순한 기술자가 아니라 회사의 미래를 함께 고민할 수 있는 사람이라는 신뢰를 전달합니다.

3. 해석과 이정표로 이뤄내는 성장

‘물경력’이라는 말로 대표되는 경력의 불안함은 사실 경험 그 자체보다 회고가 부족할 때 나옵니다. 프로젝트가 중단되거나 실패했더라도, 왜 그런 결과가 나왔는지를 분석하고 “어떻게 했으면 유지할 수 있었을까”를 고민하는 과정 자체가 실력이 됩니다. 이러한 회고는 블로그나 이력서를 통해 성장 가능성을 어필할 중요한 자산이 됩니다.

또한 개발자로서 방향을 잃지 않기 위해서는 앞으로 나아갈 ‘이정표’도 필요합니다. 당장 10년 뒤의 목표가 거창하지 않아도 괜찮습니다. 지금 시점에서 상상할 수 있는 최선의 방향을 설정하는 것만으로도, 공부의 효율과 이력서의 서사가 크게 달라집니다. 목표는 언제든 바뀔 수 있습니다. 하지만 이정표가 있을 때야말로 내 성실함이 ‘누구나 하는 일’이 아닌 ‘나만이 할 수 있는 전문성’이란 길로 이어집니다.

4. 로그가 아닌 제안서를 쓰세요

본인의 이력서가 여전히 과거만을 기록한 ‘로그(Log)’에 머물러 있지는 않나요? 기업은 여러분의 과거를 사지 않습니다. 문제를 해결하며 함께 도착할 기업의 미래를 삽니다.

이제 지식을 쌓는 데만 머무는 공부를 멈추고 회사가 마주한 문제를 풀기 위한 고민을 시작해 보세요. 관점이 바뀌는 순간, 성실하기만 한 학생을 벗어나 회사가 간절히 원하는 대체 불가능한 ‘파트너’로 나아갈 수 있습니다.

]]>

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 발표자 신청하기

]]>

한국에서 인기 있는 앱이 왜 영국에선 통하지 않을까?

현재 영국에 지내다 보니 국가에 따라 앱 서비스 사용하는 상황에 차이가 있다는 걸 알게 됐다. 그 예시로 스타벅스 사이렌 오더가 주문이 익숙한 한국과 달리, 영국은 매장에서 직접 주문하는 경우가 많다. 오히려 앱 주문을 어색해하고 앱 사용에 어려움을 겪는 것이다. 서비스 측에서도 앱 사용을 이끌기 위한 프로모션을 시행하는 것도 드물었다. 이처럼 같은 서비스여도 나라마다 앱 사용률의 차이를 체감하니, 타 국가에 서비스를 안착시키기 위해선 어떤 접근 방식을 따를지 고민하게 된다.

또 다른 예로 당근이 당근마켓 서비스를 영국, 캐나다에 확장하는 과정에서 ‘매너 온도’ 기능에 대해 국내 고객과 이해 차이가 극명히 드러났던 사례가 있다. 국내 사용자는 36.5도를 정상 체온이라 이해하는 것과 달리 캐나다, 영국에서 만난 사용자는 정상 체온의 표현 방식이 달랐다. 심지어 5점 만점의 별점으로 점수 매기는 방법처럼 누구나 익숙하고 쉽게 이해할 방법이 있는데, 왜 어려운 방식을 고수하냐는 의견이 있었다고 한다. (출처)

그래서 결국 체온에 대한 컨셉을 제외하고 score 점수 형태로 수정했다. 이는 다른 국가에 서비스를 출시할 경우 서비스를 이용하는 고객을 새롭게 이해해야 하며, 나아가 서비스가 해결해야 할 문제, 페인 포인트가 다르다는 점을 시사한다.

‘문제 정의’는 서비스를 다른 국가에 출시하는 것이 아니더라도, 프로덕트를 운영하는 입장에서 항상 주목하는 부분이다. 이때 문제로서 검증 가치가 있는가를 생각하여 가설을 세우게 되는데, 만약 새로운 고객을 타깃으로 서비스를 출시할 때, 어떻게 가설을 세우고 어떤 가설을 우선으로 검증해야 할까? 타국가에 출시해야 할 경우처럼 참고할 데이터가 없다면, 고객을 어떻게 이해할 수 있을까? 완전히 새로운 시장에서 새로운 고객을 타겟하는 서비스라면 어떨까.

이번 글에서는 Customer Journey Shadowing 방법을 활용하여, 고객을 이해하고 보다 유의미한 가설을 세우는 접근 방식에 관해 이야기하고자 한다.

<출처: 구글>

Customer Journey Shadowing이란?

고객의 여정(Customer Journey)을 그림자처럼 따라다니며 관찰하는 리서치 방법으로, 사용자가 실제로 무엇을 하는지 행동 중심으로 분석하는 방법이다. 단순 인터뷰나 설문과 달리 실제 행동, 맥락, 감정, 문제점을 현장에서 발견할 수 있다는 점이 핵심이다.

예시로, 카페 주문하는 행동을 리서치 하면, ‘ 고객이 매장에 들어와서 메뉴 탐색 → 주문 → 결제 → 픽업 → 좌석 이용’까지 전 과정을 관찰하는 것이며, 서비스 UX의 경우 ‘사용자가 상품 탐색 → 비교 → 장바구니 → 결제 → 배송 확인 과정’을 실제로 사용하는 모습을 관찰하는 것이다.

왜 Customer Journey Shadowing을 하는가

그렇다면 왜 Customer Journey Shadowing을 해야 할까? 인터뷰, 설문만으로는 사용자의 실제 행동과 차이가 생기기 때문이다. 예로 사용자를 구두로 인터뷰할 경우, ‘저는 항상 리뷰를 확인해요’ 라 답하지만, 실제로 리뷰를 거의 보지 않을 경우가 있고, ‘앱 사용이 어렵지 않았어요.’라 답하지만, 특정 화면을 여러 번 왔다 갔다 하기도 한다. 그래서 요즘 업계에서는 A/B Test를 시행해, 사용자의 의견이 아닌 실제 상황에서 나타난 행동을 검증하는 것이 보편화되고 있기도 하다.

대표적으로 Customer Journey Shadowing을 많이 사용하는 브랜드에는 IKEA 가 있다. UX 리서처들은 매장에서 ‘고객이 어떤 경로로 이동하는지’, ‘어떤 제품 앞에서 오래 머무는지’, ‘언제 직원을 찾는지’, ‘어떤 순간에 쇼핑을 포기하는지’ 분석했고, ‘고객이 제품 사진을 찍어둔다.’, ‘제품 위치를 나중에 찾지 못한다.’, ‘매장이 너무 커서 동선이 헷갈린다.’, 등의 페인 포인트를 발견했다. 이에 IKEA 앱에 ‘제품 위치 찾기’, ‘쇼핑 리스트’, ‘매장 지도’를 추가했다. 이는 Customer Journey Shadowing 리서치 인사이트를 디지털 서비스 개선으로 이어진 사례로 언급된다.

다음은 한 사례를 보여주는 자료다. IKEA의 Customer Journey Shadowing을 활용한 서비스 개선 기회 발견 과정을 알 수 있다. 가로축은 ‘고객 여정 전체’ 과정, 세로축은 차례대로 ‘고객 행동’, ‘터치 포인트(고객이 제품/서비스를 인지하고 구매, 사후 서비스에 이르기까지 기업과 접촉하는 모든 물리적·디지털·인적 상호작용 지점)’, ‘고객 경험/감정’, ‘기회 영역(개선할 수 있는 영역 또는 아이디어)’을 나타낸다.

특히 ‘고객 경험/감정’을 표시하는 두 선은 서비스 개선 지점을 나타낸다. 빨간 선은 문제가 발생하는 지점, 즉 페인 포인트(Pain Point)로 고객이 불편함을 느끼는 순간, 감정 그래프가 떨어지는 지점, 행동이 끊기거나 멈추는 순간을 의미한다. 초록 선은 개선 기회 또는 긍정적 경험 지점, 문제를 해결할 수 있는 지점, 새로운 기능/서비스 도입 가능함을 표시한다. 두 선의 차이가 발생하는 지점에 고객의 불편을 해결하는 기회 영역을 발견할 수 있다.

<출처:구글>

이처럼 Customer Journey Shadowing은 사용자가 명확하게 불편하다고 인식하지 못하지만, 행동을 방해하거나 경험을 나쁘게 만드는 요소를 알 수 있다. 즉, 실제 행동 기반으로 문제 발견하고 고객 경험 전체 흐름 이해할 수 있게 된다.

Customer Journey Shadowing 진행 방법

리서치 과정은 ‘리서치 목표를 정의 - 관찰 대상 사용자 선정 - 고객 여정 정의 - 실제 행동 관찰 - 인사이트 도출’ 순서로 진행된다. 해당 글에서는 스타벅스 앱 서비스 영국 현지화를 가정하여, 고객 행동의 특징과 페인 포인트를 이해하는 것을 목표로 설정했다.

리서치 목표 정의 : 고객이 음료를 주문하며 카페를 이용하는 전 과정을 분석한다.
관찰 대상 사용자 선정 : 스타벅스 방문 고객
고객 여정 정의 : 매장 입장 - 메뉴 탐색 - 주문 대기 – 주문 – 결제 - 음료 대기 - 음료 픽업 - 좌석 이용 / 픽업
실제 행동 관찰
인사이트 도출

인사이트 도출

고객을 관찰하며 인사이트를 도출할 때 염두에 둬야 할 것은 ‘해결해야 할 문제가 무엇인가’이다. 자칫 관찰을 하다보면 고객의 특징이나 차별점이 중요하다는 함정에 빠질 수 있다. 중요한 것은 Product Market Fit (이하 ‘PMF’) 으로서 검증할 만한 특징을 발견해야 한다는 점이다.

다음은 필자가 PMF에 유의미한 방향을 고려하여 스타벅스 고객을 관찰 및 정리한 인사이트다.

<출처: 구글, 작가 편집>

1) 앱 주문 보다 현장 주문을 선호한다.

행동 관찰: 앱 주문 보다 현장 주문이 높다. 줄을 서면서도 앱 사용을 하지 않는다.
문제: 앱이 “시간 절약 가치”를 제공하지 못한다.
PMF 인사이트: 앱 주문 경험 가치가 “빠름”이 아닌, 다른 가치가 필요하다. “경험을 방해하지 않는 주문 방식”이 필요하다.

2) 리워드/보상에 대한 인식 차이

행동 관찰 : 리워드 적립을 하지 않는다.
문제 : 리워드가 앱 사용을 유도하는 장치로 작동하지 않는다.
PMF 인사이트 : “즉각적이고 체감되는 가치”가 필요하다.

3) 결제 방식 차이

행동 관찰 : 앱 결제를 하지 않는다
문제 : 컨택리스(비접촉 결제 서비스로, 카드를 대기만 하면 결제되는 방식)로 현장 결제가 더 빠르다.
PMF 인사이트 : 앱이 기존 결제보다 확실히 더 편해야만 사용된다.

4) 온라인 바우처(예)기프트콘) 문화 차이

행동 관찰 : 온라인 바우처 선물 사용이 낮다.
문제 : 실물 기프트 카드 중심 문화로, 온라인 바우처 문화가 생활 방식에 없다.
PMF 인사이트 : 미리 준비하는 선물보다는, 자연스럽게 발생하는 선물 순간에 맞춰야 한다.

가설 세우기: 인사이트에서 가설 세우기

고객 행동 관찰을 통해 얻은 네 가지 인사이트 중, 두 가지를 예시로 가설과 검증 지표를 설정했다. 먼저‘앱 주문 보다 현장 주문을 선호’하는 고객 행동으로 알 수 있는 것은 ‘앱 주문 경험 가치가 “빠름”이 아닌, 다른 가치가 필요하다는 점’이다. 이때 서비스는 ‘더 좋은 경험을 주는 것’으로 접근해야 한다. 고객이 커피 주문하는 경험을 방해하는 것은 무엇일까. 그것을 제거하여 더 좋은 경험을 제공할 수 있을 것이다.

고객은 항상 마시는 음료가 있거나 간혹 새로운 메뉴를 시도해 보는 경우로 나뉜다. 그렇다면 개인화를 통해 두 가지 가설을 검증할 수 있겠다. 첫째 가설은 ‘주로 주문하는 음료를 원클릭으로 재주문할 수 있다면, 앱 주문율이 증가할 것이다.’이며, 또 다른 가설로는 ‘선호하는 음료 스타일에 따라 새로운 메뉴 3가지 추천하여 앱이 대신 선택을 줄여주면, 앱 주문율이 증가할 것이다.’이다. 이에 대한 검증 지표로 ‘같은 음료 재주문 비율’, ‘추천 메뉴 클릭률’, ‘전체 앱 주문 전환율’ 등으로 측정할 수 있겠다.

<출처: 구글, 작가 편집>

다음으로, ‘리워드/보상에 대한 인식 차이’를 통해 알 수 있는 것은 리워드가 앱을 사용하는 행동 유도 장치로 작동하지 않는다는 점이다. 이 경우 고객에게는 “즉각적이고 체감되는 가치”가 필요하다. 그렇다면 다음 가설을 설정할 수 있겠다. ‘고객은 단순 포인트 적립보다 “즉각적 보상”이 있을 때 앱 사용 빈도가 증가한다.’를 가설로 두고, 즉각적 보상을 주는 경험을 설계해 가설 검증을 할 수 있겠다. 예로 ‘주문 즉시, 무료 사이즈 업 혹은 즉시 할인 쿠폰을 제공하면 앱 사용 빈도가 증가할 것이다.’를 가설로 두어 실행하여, 검증 지표로 리워드 페이지 접속률, 앱 주문 전환율로 측정할 수 있을 것이다.

<출처: 구글, 작가 편집>

마치며

해외 시장에서 앱 서비스를 성공적으로 정착시키기 위해, 혹은 새로운 타깃 고객으로 새로운 시장을 개척하려 할 때, 중요한 것은 단순한 기능이나 UX가 아닌 타깃 고객이 가진 문제를 이해하는 것이다. 이러한 환경에서는 기존 시장에서 검증된 가설이나 데이터에 의존하기 어렵기 때문에, 문제 정의의 출발점부터 다시 고객을 이해하는 과정이 필요하다. 이번 글에서 다룬 Customer Journey Shadowing은 바로 이러한 상황에서 유용한 방법으로, 사용자의 말이 아닌 실제 행동을 기반으로 숨겨진 문제를 발견할 수 있게 한다.

결국 중요한 것은 “이 시장의 고객은 어떤 문제를 중요하게 느끼는가”를 먼저 정의하는 것이다. Customer Journey Shadowing을 통해 얻은 행동 기반 인사이트는 단순한 관찰에 그치지 않고, PMF 관점에서 의미 있는 가설로 전환될 때 실행 가능한 전략이 된다. 따라서 새로운 국가나 시장에서 제품을 확장할 때는 기능 중심이 아니라, 고객 여정 기반의 ‘문제 재정의 → 행동 관찰 → 가설 수립 → 검증’의 반복 구조가 필수일 것이다.

]]>

막힐 때마다 직접 만들었더니, 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 전환을 어디서부터 시작할지 고민이라면
엘리스와 시작해 보세요.

[엘리스에 문의하기]

]]>