요즘IT » AI » 피드

개인용 AI 에이전트 ‘openhuman’ 직접 써본 후기

요즘 챗봇은 대화를 기억하는 능력은 좋아졌지만, 이메일이나 코드 저장소처럼 내 실제 작업 맥락까지는 알지 못하는 경우가 종종 있습니다. 결국 새 도구를 사용할 때마다 내 상황을 다시 설명하거나 자료를 직접 붙여 넣어야 했습니다.

그렇다면 에이전트가 처음부터 내 맥락을 알고 시작하면 어떻게 될까요? 이 질문을 정면으로 붙든 오픈소스 프로젝트가 ‘openhuman’입니다.

<출처: openhuman 공식 깃허브 문서>

openhuman은 사용자가 연결한 계정의 데이터를 주기적으로 동기화해 개인 메모리를 쌓는 구조입니다. 스스로 ‘개인용 AI 슈퍼 인텔리전스’라고 부르는 이 도구를 며칠간 직접 설치해 써보며, 공식 소개에서 내세우는 ‘몇 주 걸릴 맥락을 몇 분 만에’라는 말이 실제로 맞는지 확인해 보았습니다.

미리 요점만 콕 집어보면?

openhuman은 Gmail·GitHub 등 연결한 데이터를 로컬 메모리(SQLite)에 축적하고 SuperContext로 새 대화에서도 이전 맥락을 자동으로 이어가는 개인용 AI 에이전트입니다.
직접 사용해 보니 프로젝트·이메일 맥락을 이어받는 능력과 다양한 서비스의 쉬운 연동은 인상적이었지만, 비공개 GitHub 접근과 응답 속도, 안정성에는 한계가 있었습니다.
‘설정 없이 똑똑한’ 도구보다 ‘쌓을수록 똑똑해지는’ 도구에 가까웠으며, 베타 버전인 만큼 반복 프로젝트에는 시도해 볼 만하지만 속도와 안정성을 중시한다면 정식 버전을 기다리는 편이 적합합니다.

openhuman이란 무엇인가

openhuman은 내 컴퓨터에서 도는 개인용 AI 에이전트입니다. 겉으로는 여느 챗봇과 비슷한 데스크톱 앱이지만, 설계의 무게 중심이 완전히 다른 곳에 있습니다. 대화를 잘하는 것보다 나를 기억하는 것을 먼저 풀려고 만든 도구입니다.

핵심은 로컬 메모리입니다. openhuman은 내 데이터를 마크다운 트리 형태로 압축 및 정리해 내 컴퓨터의 로컬 데이터베이스(SQLite)에 저장하고, 같은 내용을 옵시디언(Obsidian)과 같은 앱에서 열어 직접 확인할 수도 있습니다. 여기에 Gmail과 GitHub 같은 서비스를 연결해 두면, 일정 주기로 데이터를 자동으로 가져와 이 메모리를 스스로 채웁니다. 정리하면, 내 활동이 곧 에이전트의 기억이 되는 구조입니다.

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

이 발상은 갑자기 나온 것이 아닙니다. openhuman은 안드레이 카파시(Andrej Karpathy)가 말한 ‘LLM 지식베이스’ 개념에서 출발합니다. 안드레이 카파시는 오픈AI 초기 멤버이자 테슬라 AI를 총괄한 딥러닝 연구자로, AI 업계에서 널리 알려진 인물입니다. 모델 자체를 키우는 대신, 모델 옆에 개인의 맥락을 붙여 두어 매번 처음부터 시작하지 않게 하자는 접근입니다.

왜 ‘개인 메모리’가 핵심일까

openhuman을 이해하려면 먼저 에이전트의 오래된 약점을 짚어야 합니다. 여기서는 이 도구가 왜 메모리에 그렇게 공을 들였는지, 그 배경부터 살펴보겠습니다.

1) 매번 처음인 에이전트의 문제

대부분의 AI 도구는 대화가 끝나면 맥락도 함께 사라집니다. 다음에 다시 열면 나에 대해 아무것도 모르는 상태로 돌아갑니다. 이를 흔히 콜드 스타트(cold start), 즉 아무 맥락 없이 차갑게 시작하는 문제라고 부릅니다. 사용자는 매 대화를 프롬프트로 데우는 일을 반복하게 됩니다.

2) openhuman의 해법

openhuman은 이 문제를 뒤집습니다. 대화를 시작할 때 맥락을 채우는 대신, 평소에 맥락을 쌓아 두었다가 대화가 시작되는 순간 자동으로 꺼내 옵니다. 새 대화의 첫 턴에 관련 맥락을 알아서 붙여 주는 기능을 이 도구는 SuperContext라고 부릅니다. 사용자가 “지난번 그 프로젝트”라고만 해도, 그 프로젝트가 무엇인지 이미 알고 있는 상태에서 답이 시작되는 것을 목표로 합니다.

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

3) 연결이 곧 기억이 되는 구조

이 메모리는 손으로 채우는 것만은 아닙니다. openhuman은 100개가 넘는 서비스와 원클릭으로 연동되고, 연결해 둔 데이터를 일정 주기로 동기화해 메모리에 반영합니다. 이메일이나 문서가 쌓일수록 에이전트가 아는 내 맥락도 함께 늘어나는 셈입니다.

직접 설치하고 써봤습니다

지금까지는 openhuman이 어떤 도구인지 살펴봤습니다. 이제부터는 제가 직접 설치해 며칠간 써보면서 느낀 점을 이야기해보겠습니다.

1) 설치와 첫 실행

먼저 openhuman을 내려받습니다. openhuman은 오픈소스로 공개돼 있어, 공식 배포처의 릴리즈 페이지에서 자신의 운영체제에 맞는 설치 파일을 받으면 됩니다.

<출처: 작가, 공식 사이트 캡처>

openhuman은 러스트(Rust)와 타입스크립트로 만든 타우리(Tauri) 기반 데스크톱 앱입니다. 위 화면처럼 macOS는 dmg, 윈도우는 exe나 msi, 리눅스는 AppImage 형태의 설치 파일이 제공됩니다.

<출처: 작가, openhuman 캡처>

첫 실행에서는 몇 가지를 고르는 온보딩을 거칩니다. 먼저 에이전트를 어디에서 돌릴지(런타임)를 정하고, 이어서 실행 방식을 선택합니다.

<출처: 작가, openhuman 캡처>

설치하면서 특별히 막힌 지점은 없었습니다. 굳이 팁을 더하자면, 첫 실행 온보딩에서 ‘추천’이라고 표시된 선택지를 그대로 고르면 별다른 고민 없이 빠르게 설치를 마칠 수 있었습니다. 로그인은 이후 GitHub 연동을 조금 더 편리하게 하려고 GitHub 계정으로 처리했습니다.

2) 서비스 연동과 자동 동기화

첫 실행을 끝내면 어떤 서비스를 연결할지 정하게 됩니다. 연결한 데이터가 곧 에이전트의 기억이 되다 보니, 무엇을 연결하느냐에 따라 쓸모가 꽤 달라졌습니다.

<출처: 작가, openhuman 캡처>

저는 개발자들에게 익숙한 GitHub와 자주 쓰는 이메일인 Gmail을 연동해봤습니다. 방법은 어렵지 않았는데요, 사이드바의 ‘연결’을 누른 뒤 검색창에 Gmail과 GitHub를 각각 입력하면 됩니다.

앞서 GitHub 계정으로 로그인해 두었기 때문에 GitHub 연동은 버튼 한 번으로 끝납니다. Gmail도 크롬을 쓰고 있다면 로그인된 이메일로 자동 연결돼, 버튼 한 번, 10초 남짓이면 연동이 마무리됩니다.

연동할 때 권한을 확인하는 화면이 뜨는데, 이때 필요한 권한만 골라서 선택할 수 있습니다.

<출처: 작가, openhuman 캡처>

3) 메모리와 SuperContext는 실제로 통했을까

가장 궁금했던 부분은 결국 이것이었습니다. 미리 쌓아 둔 맥락을 정말 제때, 제대로 꺼내오는가?

맥락을 이어받는 능력은 꽤나 괜찮았습니다. 한 대화에서 ‘예전에 만든 특정 리포지토리를 수정하려 한다’고만 적어둔 뒤, 완전히 새 대화를 열어 ‘내가 수정하려는 리포지토리를 설명해줘’라고 물었더니, 앞 대화에서 언급했던 그 리포지토리를 곧바로 찾아냈습니다. 새로운 대화인데도 이전 맥락을 스스로 끌어온 것입니다. 메일도 마찬가지로, 받은 메일뿐 아니라 보낸 메일까지 근거로 삼아 내가 누구와 무엇을 주고받았는지 잘 짚어 주었습니다.

물론 모든 경우에 통하지는 않았습니다. GitHub의 비공개 리포지토리 정보는 잘 읽어 오지 못했고, 뒤에서 이야기할 속도와 요청 제한 때문에 맥락을 아예 가져오지 못하는 경우도 있었습니다. 성공과 실패를 가른 건 대체로 ‘데이터에 실제로 접근할 수 있느냐’였습니다. 공개된 활동이나 메일처럼 바로 읽히는 데이터는 잘 잡았지만, 접근이 막히거나 요청이 몰려 제한에 걸리면 맥락을 놓치게 되었습니다.

<출처: 작가, openhuman 채팅 목록 캡처>

4) 기존 도구와 비교하면

평소에는 유료로 쓰는 Claude Code를 주력으로 삼고, 간단한 질문은 무료인 ChatGPT로 처리해 왔습니다. 이 둘과 비교하면 openhuman은 어땠을까요?

맥락을 잡는 감각만 놓고 보면 openhuman이 꽤 좋았습니다. 다만 비교를 위해 다른 도구도 같은 방식으로 시험해 보니 결과가 생각보다 팽팽했습니다.

ChatGPT는 평소에 주제가 바뀌면 새 채팅을 열어 쓰다 보니 이전 맥락을 얼마나 기억하는지 가늠하기 어려웠는데, 이번에 새 채팅을 열고 ‘내가 저번에 너한테 무슨 말 했었지?’라고 단순하게 물어보니 이전 대화를 꽤 잘 기억하고 있었습니다. 한두 달, 길게는 석 달 전 내용까지도 무리 없이 떠올렸습니다. Claude Code는 결이 조금 다른데, 스킬과 훅으로 요구사항이나 작업 흐름을 미리 기록해 두는 방식이라 맥락을 놓쳤다고 느낀 적이 드물었습니다.

그래서 맥락 이해 하나만으로 openhuman이 앞선다고 말하기는 조심스러웠습니다. 오히려 openhuman의 강점은 다른 곳에 있었습니다. 바로 ‘연결’ 탭이었습니다. 다양한 서비스를, 그것도 아주 손쉽게 붙일 수 있다는 점은 터미널이나 설정 파일에 익숙하지 않은 비개발자가 쓰기에 특히 좋아 보였습니다. 기존 도구들이 대화 자체의 똑똑함으로 승부한다면, openhuman은 내 여러 서비스를 한데 모아 맥락으로 삼는다는 점에서 결이 달랐습니다.

위의 내용을 아래에 표로 정리해 보았는데요. 객관적인 지표라기보다 제 나름의 기준으로 매겨 본 주관적인 평가라는 점을 감안해 주세요.

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

실무에서 쓸 때의 활용법과 주의점

써본 경험을 실무 관점으로 정리하면, openhuman은 몇 가지 조건에서 특히 쓸모가 있었습니다.

첫째, 맥락이 길게 이어지는 작업일수록 이점이 컸습니다. 하루짜리 단발적인 질문보다는, 며칠에 걸쳐 이어지는 긴 프로젝트에서 ‘매번 다시 설명하지 않아도 되는’ 효과가 두드러졌습니다.

둘째, 로컬 우선 설계이기 때문에 민감한 데이터를 다룰 때 부담이 상대적으로 덜했습니다.

1) 이렇게 쓰면 더 좋습니다

특히 Slack이나 Discord와 같은 실무에서 쓰는 채팅 도구도 손쉽게 연동된다는 점이 눈에 들어왔습니다.

바빠서 미처 못 읽었거나 잔뜩 쌓인 대화를 openhuman에 요약해 두면 흐름을 한눈에 정리할 수 있고, 그 내용을 openhuman이 기억하기 때문에 이후 어떤 질문을 던져도 앞선 대화와 이어서 답해 줄 수 있습니다. 매번 상황을 다시 설명하지 않아도 된다는 점에서, 채팅으로 협업하는 팀일수록 쓸모가 클 것으로 보입니다.

물론 감수해야 할 점도 있었습니다.

우선 전반적으로 응답이 느렸습니다. 간단한 질문이라도 응답 속도가 다른 AI들에 비해 눈에 띄게 느렸죠. 또 GitHub에서는 비공개 리포지토리 정보를 잘 읽어오지 못했고, 요청이 몰리면 데이터를 가져오지 못하는 경우도 종종 있었습니다. GitHub 관련 작업에서는 접근해도 되는지 매번 승인을 다시 물어봐서 번거롭기도 했습니다. 도입을 고민한다면 이 속도와 안정성, 그리고 반복되는 승인 절차는 미리 감안하는 편이 좋습니다.

<출처: 작가, openhuman 캡처>

정리하면, openhuman은 ‘설정 없이 똑똑하다’기보다 ‘쌓을수록 똑똑해지는’ 도구에 가까웠습니다. 초기에 어느 정도 연결과 사용을 쌓아 두는 투자가 필요했고, 그 투자를 한 뒤에야 콜드 스타트를 줄여 주는 효과가 드러났습니다.

마치며

openhuman을 써보며 확인한 것은, 개인 AI 에이전트의 승부처가 모델의 똑똑함만이 아니라 나에 대한 맥락을 어떻게 다루느냐로 옮겨 가고 있다는 점이었습니다. openhuman은 ‘내 맥락을 아는 개인 비서’라는 방향성만큼은 분명하게 보여 주었고, 여러 서비스를 손쉽게 연결해 두면 새 대화에서도 내 상황을 알아서 짚어 주는 경험은 꽤 매력적이었습니다.

이번엔 하루에 여섯 시간 가까이 붙잡고 써봤지만, 이 도구의 진짜 강점까지는 확인하기 어려웠습니다. 공식 설명과 여러 사용기가 공통으로 꼽는 핵심은, openhuman이 20분마다 내 계정을 자동으로 따라잡아 다음 날 아침이면 밤사이에 쌓인 메일이나 팀원의 커밋까지 이미 알고 있다는 점입니다. 내가 말해 준 것만 기억하는 ChatGPT·Claude와 달리 시간이 지날수록 내 실제 데이터를 스스로 최신 상태로 유지한다는 것인데, 이 효과는 며칠에 걸쳐 써야 드러나는 특성이기 때문에 장시간 써 봐야 체감할 수 있을 것 같습니다.

다만 속도와 안정성, 비공개 데이터 접근과 같은 부분은 아직 다듬어질 여지가 있어, 지금은 가능성을 확인하는 단계에 가깝다고 느꼈습니다. 무엇보다 아직 베타 빌드 버전이기 때문에 미흡한 부분이 있다는 점도 감안할 필요가 있습니다. 뒤집어 말하면, 정식 버전으로 배포된다면 충분히 기대해 볼 만하다는 뜻이기도 합니다. 반복적인 프로젝트에서 맥락을 이어가는 것이 중요하다면 지금도 충분히 시도해 볼 만하고, 속도와 안정성이 더 중요하다면 정식 버전을 기다리는 편이 나아 보입니다.

<참고>

openhuman 공식 GitHub 저장소

]]>

클로드 채널, 이렇게까지 쓸 수 있다

지난 5월 27일과 6월 10일, 요즘IT는 ‘클코나잇 2’ 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 “고수의 경험을 나눠 받을 수 있는 기회”, “찐 실무자의 현장감 넘치는 사례”, “다음에 또 오고 싶은 웨비나” 등의 반응을 보였습니다. 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이 발표는 클코나잇 2 웨비나의 ‘클로드 코드, 채널 기반으로 쓰는 방법’으로 “6월 15일부터 Agent SDK와 헤드리스 모드가 별도 크레딧으로 전환된다”는 앤트로픽 공지를 전제로, 구독 사용량을 따라가는 라이브 세션을 우회 런타임으로 활용하는 방법을 다뤘습니다. 그런데 발표 다음 날인 6월 16일, 앤트로픽은 해당 전환을 철회하고 기존 정책을 유지한다고 안내했습니다.

따라서 지금은 이 글에 담긴 우회 구현을 직접 만들 이유가 없으며, Agent SDK를 그대로 가져다 쓰면 됩니다. 그럼에도 이 기록을 남기는 건, 리서치 프리뷰 기능인 Claude Channel을 실무자가 실제 자동화에 어디까지 활용했는지 보여주는 구현 사례이고, 여기 담긴 에이전트 간 대화 설계나 권한 분리 같은 접근은 이 정책 변경과 무관하게 참고할 만하다고 봤기 때문입니다.

클코나잇을 두 시즌 운영하며, 여기서 소개된 사례가 모델 개발사의 기능 추가로 금세 빛이 바래는 경우를 여러 번 지켜봤습니다. 믿었던 것과 공들여 만든 것이 하루아침에 무너지기도 하는 환경이지만, 그 속에서 현장 실무자가 쌓아온 시도를 기록하는 일에는 그 자체로 가치가 있다고 생각합니다.

발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요, 교보DTS 정보보안센터에서 일하는 이용학입니다. 오늘은 조금 교육적으로 가보려고 합니다. 제가 발표할 주제는 클로드 코드 자동화를 헤드리스 모드에서 채널 기반 세션으로 옮기게 된 이야기이고, 그 과정에서 클로드 코드의 기본적인 개념도 함께 다뤄볼 생각입니다.

아젠다는 총 5개입니다. claude -p 기반 자동화를 왜 채널 기반으로 바꿨는지, MCP와 채널의 기본 개념, 실제로 채널로 돌아가는 작업 한 바퀴, 채널을 이용해 코딩 에이전트를 오케스트레이션하는 방법, 그리고 스크린샷 데모로 진행하겠습니다.

헤드리스 모드(claude -p)는 왜 자동화에 좋았을까?

먼저 클로드 헤드리스 모드, 그러니까 claude -p가 어떤 건지부터 간단하게 짚고 넘어갈게요. 이 명령어는 한마디로 터미널에서 실행하는 명령어입니다. -p 플래그를 통해 뒤에 프롬프트를 입력하면, 사람 승인 없이 프롬프트가 전달돼 터미널의 표준 출력(standard output)으로 결과가 나오고, 그 세션은 종료됩니다.

이게 왜 자동화에 좋았냐면요.

스크립트로 만들 수 있습니다. 터미널에서 입력할 수 있는 명령어는 스크립트, 즉 명령어가 모인 파일로 만들 수 있거든요.
배치로 실행할 수 있습니다. 만든 스크립트를 cron 같은 스케줄러에 등록해 두면 매일 규칙적으로 도는 배치 작업으로 만들 수 있어요.
API처럼 호출할 수 있습니다. claude -p 명령어를 API 호출하듯 쓸 수 있었어요.

다만, 단점도 있습니다. 헤드리스 모드는 기본적으로 스테이트리스(stateless)합니다. 물론 이어가기 옵션이 있긴 하지만, 기본적으로 매 호출이 독립적이고 세션과 맥락이 초기화된다는 단점이 있었습니다.

미국 증시 브리핑을 자동화했더니 생긴 문제

예시를 하나 들자면, 제가 요즘 투자에 관심이 많아서 미국 증시 브리핑 같은 걸 만들었었어요. 미국 증시의 현재 지수와 여러 지표, 핵심 테마와 해석, 그리고 제가 관심 있어 하는 개별 종목까지 클로드 헤드리스 모드 하나로 다 자동화를 해놨었습니다.

그런데 문제가 생겼습니다.

첫 번째 문제는 상당히 비효율적인 토큰 소모량이었습니다. 한 번 돌릴 때마다 맥스 5x 플랜 기준 23% 정도를 사용했어요.

두 번째는 제가 발표 자료를 준비하면서 알게 된 건데, 헤드리스 모드가 별도 크레딧으로 분리된다*는 점입니다. 이전에는 구독 사용량에서 차감이 됐다면, 6월 15일부터는 별도 크레딧으로 전환돼요. 크레딧이 플랜에 따라 지급될 거고요. 첫 번째 단점과도 굉장히 연관되는 게, 한 번 돌릴 때마다 꽤 먹는 작업이 크레딧을 소모하게 된다면 그렇게 많이 돌릴 수가 없겠죠.

*발표자 주: 지난 6월 16일, 앤트로픽에서 “Agent SDK와 헤드리스 모드는 크레딧 사용으로 전환되는 것이 아닌, 기존 정책(클로드 구독 사용량을 따라가는 방식)을 유지한다”라는 메일을 보냈습니다. 해당 정책 변경이 철회됨에 따라, 이 문제는 유효하지 않습니다. 따라서 Claude Agent SDK, 혹은 헤드리스 모드를 사용하면 발표 자료와 같이 복잡한 구현을 진행하지 않아도 됩니다. 추상화가 잘 되어 있어 사용자들은 가져다 쓰기만 하면 되니까요. 다만, “리서치 프리뷰 기능인 클로드 채널을 이렇게도 쓸 수 있구나”하는 관점에서 좋은 활용사례 자료로 볼 수 있다고 생각합니다.

이 문제를 풀어보려다 클로드 채널이라는 것을 발견하게 됩니다. 그 전에 핵심을 말씀드리면, 대화형 세션( CMD나 파워셸에서claude를 입력해 접속한 세션)은 구독 사용량을 따라가지, 크레딧이 별도로 차감되는 형태가 아닙니다. 기본적으로 추가 사용량을 과금하지 않는 선에서요. 이게 이번 구조의 핵심적인 통찰이자 가정입니다.

MCP는 풀(Pull), 채널은 푸시(Push)

본격적으로 채널 활용을 설명하기 전, 알아야 할 기본 개념이 있습니다.

바로 MCP입니다. MCP는 모델 컨텍스트 프로토콜(Model Context Protocol)이라고 하는데, 말 그대로 표준이에요. 프로토콜은 규약, 약속, 규칙을 의미하거든요. 클로드에 MCP 서버를 갖다 물리면, MCP 서버가 도구나 리소스를 가지고 있습니다. 여기서 데이터는 그 MCP 서버만 바라보고 있는 외부 URL이 될 수도 있고, 정적인 데이터가 될 수도 있겠죠. 핵심은 기본적으로 풀(Pull), 당기는 구조라는 겁니다. 클로드가 필요에 따라 MCP 서버를 호출하는 구조예요.

클로드 채널은 MCP를 뒤집은 거예요. MCP는 기본적으로 풀하는 구조라고 했잖아요. 그런데 채널은 클로드 세션에 푸시(Push)를 할 수 있습니다. 클로드가 풀하는 게 아니라, 외부 이벤트나 작업과 같은 것들을 클로드 코드 세션에 푸시를 하는 구조입니다. 클로드로 푸시를 하는 구조입니다.

예시를 들면, 외부에서 이벤트가 발생한 거예요. 채팅을 입력할 수도 있고, CI/CD 과정에서 CI가 실패해 웹훅으로 연동됐다거나, 모니터링 서비스에서 알림이 발생했을 때, 이걸 채널로 보내면 실행 중인 클로드 세션에 알림(notification) 형태로 푸시가 되는 구조예요. 단방향도 지원하고 양방향도 지원합니다. 단방향은 말 그대로 푸시만 하고 클로드가 받아들이기만 하는 거고, 양방향은 클로드가 푸시된 알림을 받았을 때 다시 되돌려줄 수 있는 방법이 있어요. 뒤에서 ‘리플라이 툴(reply tool)’이라고 언급할 겁니다.

최종적으로 비교 아닌 비교를 해보자면 이렇습니다.

MCP는 프로토콜이고, 채널은 그 프로토콜을 구현한 기능
MCP는 풀 구조로 동작하고, 채널은 푸시이지만 양방향도 가능
서로 대립 관계가 아니며, MCP가 조금 더 상위 개념

헤드리스 모드와도 한 번 더 비교해 보면, 클로드 헤드리스 모드는 이어가기 옵션은 있으나 일회성 세션이고, 표면은 에이전트 SDK 쪽으로 병합되면서 별도 크레딧이 부과될 거고요. 채널은 터미널에서 claude를 입력하는 방식으로 동작하는 인터랙티브 클로드 세션이기 때문에 구독풀로 추정되지만, 확정은 아닙니다. 채널이라는 기능 자체가 리서치 프리뷰, 그러니까 실험실 기능 같은 맥락이거든요.

전체 구조: 컨트롤러 → 세션 런처 → MCP 서버 → 클로드 코드 세션

이제 제가 이걸 어떻게 구현했는지, 인터페이스 관점에서 말씀드릴게요. 총 4개의 계층이 있어요. 컨트롤러, 세션 런처, MCP 서버, 그리고 클로드 코드 세션입니다.

처음에는 작업을 만드는 과정이 필요합니다. 이 작업은 정말 뭐든 될 수 있어요. 미국 증시를 분석한다든가, 클로드 코드를 코덱스(Codex)와 대화시킨다든가, 알림 이벤트를 읽게 한다든가 하는 작업이 있겠죠. 이 작업에 채팅 ID를 붙여서 만들고, 세션 런처가 클로드 코드를 PTY 형태로 실행합니다.

PTY는 의사 터미널(pseudo-terminal)인데요. ‘슈도 터미널(의사 터미널)’라고, 가짜 터미널을 실행해서 그 위에 클로드 코드 세션을 띄우는 겁니다. 그리고 그 가짜 터미널 안에 띄워진 세션 안에 브릿지를 통해 알림 형태로 작업을 넣고, 클로드 코드가 그걸 읽고 리플라이 툴로 다시 컨트롤러에게 반환하는 과정이에요.

조금 더 디테일하게 보겠습니다. 컨트롤러의 ‘작업’은 거창한 오케스트레이터 같은 게 아니에요. 그냥 작업입니다. 말 그대로 “오늘 6월 10일 미국 증시 브리핑을 할 거고, 분석 항목은 이런 것들이고, 산출물은 한국어로 핵심 소식 4가지, 그리고 불장·베어장인 이유를 담고, 리플라이 툴을 호출해라”라고 지시하는 거고, 이게 진입점입니다.

세션 런처는 MCP Config를 넘겨서 채널을 실행하게 합니다.

이때 ‘--dangerously-load-development-channels’ 플래그를 쓰는데요. 채널 기능 자체가 리서치 프리뷰 기능이다 보니 외부 MCP 채널을 기본적으로 허용하지 않아요. 지금 허용하는 게 아마 텔레그램이나 슬랙, 디스코드 이런 쪽일 텐데, 저는 자체적으로 개발한 서버를 열고 싶기 때문에 이 플래그를 사용해 주는 거고요. 네임은 세션 네임이라고 보시면 됩니다.

이렇게 띄운 클로드 코드 세션 안에 채팅 ID와 함께 알림을 넘기게 됩니다. 채팅 ID를 왜 넘기냐면, 이것도 앤트로픽이 정의한 하나의 인터페이스이고, 여러 개의 작업을 병렬로 돌릴 때 채팅 ID로 구분하기 위해서라고 합니다. 채팅 ID와 완료 규칙(리플라이 툴을 통해 답을 회수해야 하니까 적은 규칙), 그리고 지시가 들어가게 됩니다.

이런 알림이 클로드 세션에 들어가면, 클로드 세션은 작업을 이어받아 시작합니다. ‘미국 증시 분석할 건데, 시장 데이터 수집하고, 매크로 뉴스 확인.’ 그리고 끝나면 리플라이 툴을 호출합니다. 리플라이 툴도 기본적으로 답변에 채팅 ID를 물고, 텍스트에 결과(result) 형태로 반환하게 됩니다.

컨트롤러는 그걸 보고 채팅 ID를 한 번 더 확인하고, 뭔가 깨지진 않았는지, 파싱이 잘 되는지, 필수 키가 들어있는지 검사하는 과정을 거치게 했어요.

채널로 클로드와 코덱스 대화시키기

저는 클로드와 코덱스를 둘 다 결제하고 있고, 개발할 때 두 개를 같이 많이 사용해요. 둘 다 강점이 달라서 서로의 강점을 살리게 되는데요. 이 둘을 실제로 대화할 수 있는 브릿지로 이어서 자동화할 수 없을까 하는 니즈가 있었습니다. 개발뿐만 아니라, 미국 증시 같은 제 관심사도 AI끼리 토론시키는 경우가 많거든요. 그래서 클로드 채널을 활용하면 되겠다는 생각으로 구현을 시작했습니다.

핵심부터 말씀드리면, 직접 대화를 하는 게 아니에요. 클로드와 코덱스는 컨트롤러 계층을 라우터 삼아, 매개로 대화를 하는 겁니다. 클로드 코드가 메시지를 컨트롤러에 넣어주면 컨트롤러가 그걸 받아 코덱스에 넣어주고, 코덱스가 그걸 다시 컨트롤러에 넣고, 클로드에는 채널을 통해 브릿지 형태로 넣어주는 구조예요. 각자는 컨트롤러만 바라보는 형태고, 컨트롤러가 중앙에 있습니다.

그리고 각각 대화가 언제 끝났는지 알아야 하기 때문에 ‘turn complete’ 신호를 받아야 합니다. 메시지를 넣고, 청크로 답 조각을 받은 다음, 턴 끝 신호를 받으면 종료하는 구조입니다.

핵심은 답변 수신과 완료 신호, 이 두 가지만 거의 보시면 되는데요. 클로드 코드를 가짜 터미널 안에 라이브 세션 형태로 띄우니까, 답변 수신과 완료 신호를 리플라이 툴 호출로 구현했고요. 코덱스는 방법이 두 가지가 있는데, 저처럼 codex exec 명령어를 사용하는 방법도 있고, 코덱스 앱 서버(라이브 서버)를 이용하는 방식도 있습니다. 저는 codex exec을 --json 옵션으로 실해해서 결과를 JSON 라인으로 받았어요. 그래서 답변 수신은 JSON으로 받고, 완료 신호는 턴 컴플리트라는 이벤트로 받습니다.

세 가지 대화 모드와 토큰 폭증을 막는 장치

대화에는 모드가 있습니다.

릴레이(Relay): 그냥 서로 건조하게 대화가 오고 가는 모드입니다.
콜라보레이티브(Collaborative): 클로드가 말한 내용이 ‘클로드’라는 태그로 묶인 텍스트로 상대에게 들어가는 모드입니다.
디베이트(Debate): 콜라보레이티브 뒤에 “이 주장에 반박을 해보세요”라는 신규 프롬프트 인자가 넘어가는 모드입니다.

그리고 이런 브릿지 형태를 구현하다 보면 토큰 폭증이 정말 많아요. 턴이 무한정 이어지면서 서로 무한정 대화를 한다든가, 답변 길이가 어마무시하게 길어진다든가 하는 문제가 있어서, 턴에 대한 제한이나 핸드오프 문자 수 제한, 그리고 인간이 개입할 수 있는 장치를 만드는 게 좋습니다.

또한 보안이나 권한 측면에서도, 둘 다 대화를 하는 만큼 쓰기 권한은 아무에게도 안 주거나 한 에이전트에만 주는 식으로 권장을 드리고 싶어요.

스크린샷으로 보는 작업 한 바퀴

이제 스크린샷으로 실제 동작을 보여드리겠습니다. 시작점은 클로드가 될 수도 있고 코덱스가 될 수도 있는데, 이건 클코나잇 세션이기도 하니까 클로드 코드 기준으로 말씀드릴게요.

처음에 클로드 코드 세션을 켜서, 제가 만든 채널 MCP인 ‘AI 다이얼로그 MCP’를 사용해 특정 피처에 대해 리뷰를 해달라고 하면, 선택지를 줍니다. 첫 번째로는 앞서 말씀드렸던 콜라보레이티브·릴레이·디베이트 모드, 두 번째는 최대 대화 턴 수와 핸드오프 문자 제한, 그리고 쓰기 권한을 묻게끔 했고요. 이걸 다 선택하면 대화가 시작됩니다.

저는 웹으로 연동해서 클로드와 코덱스의 턴을 동시에 볼 수 있는 화면도 만들어놨어요. 이게 필수는 아닙니다. 다만 클로드 내부에서 서브 프로세스로 스폰되는 구조다 보니 가시적이지가 않아서, 가시성을 위해 만든 거라고 보면 됩니다.

실제로 이렇게 서로 대화를 진행합니다. 특정 기능에 대해 코덱스가 리뷰를 해주면, 클로드가 그걸 실제 디스크에 있는 코드와 대조해서 확인해 주고, 추가로 보완도 해줍니다. 서로가 서로를 보완해 주는 구조죠.

이런 대화는 특정 기능에 대해 최소한의 합의가 되었다는 결론으로 도출되고, 대화가 종료되면 최초의 대화를 시작했던 부모 클로드 세션으로 전달됩니다. “레이어 1 계층에는 이런 확실한 버그가 존재하고, 잠재적인 버그는 이게 있고, 설계 취약점은 이런 게 있다”라고 띄워주고, 이 내용을 토대로 리팩토링을 한다든가 새로운 기능을 개발한다든가 하고 있습니다.

마치며: 살아 있는 세션을 자동화 런타임으로

정리하면, 저는 살아 있는 라이브 클로드 세션을 PTY로 띄워서 자동화 런타임으로 사용한 겁니다. 채널 MCP를 이용해 메시지를 밀어 넣고, 리플라이 툴로 답을 회수하는 구조라고 보면 될 것 같아요. 사실 앤트로픽 API를 사용해도 정말 쉽게 구현되는 구조이지만, 그런 래퍼를 사용한 게 아니라 채널이라는 리서치 프리뷰 기능을 사용해서 구현했다고 보시면 됩니다.

개인적으로 말씀드리고 싶은 건, 이런 작업을 할 때는 앤트로픽 공식 문서를 많이 보시는 걸 추천합니다. 앤트로픽 공식 문서나 오픈AI 공식 문서, 더 나아가면 중국 개발자들이 만든 오픈소스도 많거든요. 그런 걸 보면서 아이디어를 얻었던 것 같습니다.

이상 발표를 마치겠습니다. 감사합니다.

▶ 발표 영상 유튜브에서 보기

]]>

Opus 5부터는 클로드를 다르게 써야 한다?

클로드 오푸스 5(Claude Opus 5)가 나왔습니다. 페이블 5와 소넷 5에 이은 5세대 클로드의 세 번째 모델이에요. 그런데 앤트로픽피셜, 이 모델은 전에 클로드 쓰듯 쓰면 별로라고 합니다. 프롬프트와 하네스를 짜는 방식이 달라져야 한다는 거죠.

일단 오푸스 5가 어떤 모델인지 짚고 5세대에서 무엇이 달라졌는지, 그래서 뭘 바꿔야 하는지 순서로 알아보겠습니다. 말미에는 공식 가이드를 기반으로 지금 당장 점검할 6가지도 정리했습니다.

<출처: 앤트로픽>

페이블 5 보다는 별로지만 매일 쓰는 오푸스 5

오푸스 5의 출시일은 7월 24일입니다. 6월 9일 페이블 5, 6월 30일 소넷 5, 7월 24일 오푸스 5. 이렇게 8주 사이 앤트로픽이 여러 모델들을 발표하며, 5세대 클로드를 완성했습니다.

오푸스 5의 핵심은 “매일 쓰라고 만든” 모델이라는 거예요. 대상은 엔터프라이즈와 일상 업무, 그중에서도 에이전트에게 맡기는 코딩 작업이 중심입니다.

[핵심 특징]

적당한 가격: 입력 $5·출력 $25(100만 토큰 기준). 최상위 페이블 5의 정확히 절반
일상·엔터프라이즈 지향: “매일 쓰라고 만든” 모델. Claude Max의 새 기본
에이전틱 코딩 초점: 시키지 않은 검증까지 알아서 하는 에이전트 작업이 중심

오푸스 5 성능 표 <출처: 작가>

앤트로픽이 함께 배포한 파트너 인용도 ‘일상 업무’를 강조합니다. 커서(Cursor) 공동창업자는 “페이블 5 근처 지능을 오퍼스의 속도와 비용에” 얻었다고 했고, 러버블(Lovable)은 가장 어려운 태스크에서 오퍼스 4.7 대비 22% 개선에 실행 간 편차도 훨씬 적었다고 했어요.

그럼 페이블 5와는 뭐가 다르지?

앤트로픽은 이렇게 말합니다. 페이블 5는 “가장 야심찬 작업”과 며칠 걸리는 자율 프로젝트용, 오푸스 5는 매일 쓰는 모델. 그래서 대놓고 “오푸스 5는 우리의 최상위 일반 접근 모델인 페이블 5보다 전체적으로 더 능력 있지는 않다.”고까지 말합니다.

실제로 페이블 5에 익숙해진 사람들은 좀 아쉽다고 합니다. 한 주 동안 코딩·글쓰기·지식 업무 전반을 테스트해 본 Every 창업자 댄 시퍼(Dan Shipper)는 “사랑하기 어려운 모델”이었다고 말했습니다. 지시에 토를 달았고 일이 끝나기 전에 멈췄다는 겁니다. 대표적인 커뮤니티 해커뉴스도 같습니다. 가장 많은 답글이 붙은 반응은 “좋다, (페이블 5가 있는데) 그러면 이게 존재하는 이유가 뭐냐?”였죠.

기존에 선보인 모델보다 한참 모자란 모델. 대체 왜 존재하는 걸까요?

그 이유는 의외로 간단합니다. 최상위 모델 하나만 골라 쓰는 시대가 끝나버렸기 때문이에요.

5세대 클로드는 무엇이 다른가

지금까지 클로드를 비롯해 AI 모델을 쓰는 방식은 대체로 정해져 있었습니다.

제일 좋은 모델 하나로 모든 일을 처리하기, 벤치마크를 보고 모델 고르기, 프롬프트에 규칙 쌓기. 이 방식이 클로드 5세대에서는 전부 통하지 않을지도 모릅니다.

순서대로 오푸스 5, 페이블 5, 소넷 5 출시 이미지 <출처: 앤트로픽>

1. 비싸진 최상위 모델

구독제에 익숙해진 사용자들은 습관처럼 제일 좋은 모델을 골라두고 모든 일을 시키죠. 그런데 페이블 5는 오푸스 5의 두 배 가격입니다. 간단한 코드 리뷰까지 페이블 5로 돌리는 건 동네 마트 가는데 매번 비행기 표를 끊는 셈이에요. 6월 페이블 5 출시 뒤 토큰이 너무 빨리 닳는다는 불만이 이어지기도 했습니다.

그런 맥락에서 올해 중반부터 최상위 모델 경쟁의 판정 기준은 “누가 최고인가?”에서 “달러당 얼마나 해주는지”로 옮겨가고 있습니다. 앤트로픽만이 아니라 오픈AI, 최근 Kimi로 떠오른 중국기업 문샷(Moonshot)도 가격 메시지를 발표 전면에 내세우고 있어요.

구독 사용량 한도가 앞으로 어떻게 움직일지도 지켜봐야 합니다. 언제 어떻게 “생각해 보니 추론 비용이 너무 비싸서 페이블 5 사용량 줄이겠습니다”할지 모르는 일이니까요.

2. 흔들리는 벤치마크

한편 모델의 성능을 확인할 때, 가장 객관적인 지표로 동작하던 벤치마크가 이제 모델의 성능을 완전히 알려주지 못합니다. 특히, 오푸스 5는 페이블 5와 벤치마크 차이가 작습니다. 심지어 몇 개는 앞서기도 합니다. 다만, 실사용 평은 반대였죠.

개발자 Kun Chen은 “오푸스 5는 실사용에서 페이블 근처도 못 온다. 그런데 벤치마크 다수에서는 오푸스가 페이블을 이긴다”며 이제 유명 벤치마크보다 자기 데이터셋으로 만든 도메인 벤치마크를 훨씬 신뢰한다고 했어요. 즉, 이제 모델 성능은 내 작업으로 직접 돌려봐야 안다는 거죠. 도메인과 상황이 워낙 다양해졌기 때문이고요. 그래서 더욱 다양한 모델 라인업이 필요합니다. 어떤 업무에 무슨 모델이 가장 좋은지 확신하기 어려워졌습니다.

3. 하네스가 가르는 성능

마지막으로, 같은 모델인데 하네스, 그러니까 모델을 감싼 스킬·워크플로 구성에 따라 평가가 뒤집힐 수 있습니다. 앞서 악평을 내린 댄 시퍼의 평가에는 뒷부분이 있습니다. 팀이 기존 스킬과 워크플로를 다 지우고 처음부터 다시 시작하자 “오푸스 5는 극적으로 나아졌고 번뜩이는 순간까지 보여줬다”는 거예요.

검증이나 반복처럼 하네스가 맡던 일이 모델 안으로 들어온 정황도 있습니다. 앤트로픽이 소개한 사례에서는 한 트레이딩 회사 엔지니어가 오푸스 5로 신규 거래소용 시장 데이터 피드를 한 세션에 만들었는데 검증할 라이브 피드가 없자 모델이 자기 코드를 확인할 테스트 하네스를 스스로 만들었다고 해요. 4세대에는 검증 단계를 프롬프트와 하네스에 쌓는 게 정석이었다면 5세대에서는 그게 이중 작업이 됩니다.

정리해 보겠습니다. 모델이 발전하며, 에이전트에게 일을 맡기는 방식이 기본이 되었습니다. 토큰 소모는 이전과 비교할 수 없이 커졌고 맡기는 일의 종류도 훨씬 다양해졌습니다.

최상위 모델 하나로 전부 돌리기에는 지갑에 구멍이 뚫리는 시점이 온 겁니다. 그래서 “매일 쓸 수 있는 값의 상위 모델”이라는 필요가 생겼고, 그 자리를 채우러 나온 게 오푸스 5입니다.

앤트로픽의 새 사용법 안내

이 흐름을 가장 잘 아는 건 앤트로픽 자신입니다. 그래서 오푸스 5와 같은 날 사용법 문서 두 건을 냈어요.

하나는 오푸스 5 전용 프롬프트 가이드로 자주 재튜닝이 필요한 행동 패턴을 직접 목록으로 만든 문서입니다. 다른 하나는 기술 스태프가 쓴 “클로드 5세대 모델용 컨텍스트 엔지니어링 규칙 문서”이에요. 오푸스 5와 페이블 5에 똑같이 적용되는 규칙 6개입니다.

오푸스 5 전용 프롬프트 가이드 <출처: 앤트로픽>

가이드의 대표 규칙은 의외로 소박합니다. 간결하게 쓸 것을 직접 요청하라는 거예요. 오푸스 5의 기본 응답은 이전 모델보다 깁니다. effort는 말의 양이 아니라 생각의 양을 조절하는 장치라 낮춰도 응답이 짧아지지 않고요. 그래서 더할 항목보다 지우라는 항목이 먼저 나옵니다. 오푸스 5는 시키지 않아도 자기 작업을 검증하니 “마지막에 꼭 검증 단계를 넣어” 같은 지시는 과잉 검증과 토큰 낭비만 만든다는 식입니다. 앤트로픽 발표 기준으로 클로드 코드의 시스템 프롬프트를 80% 넘게 지웠는데 측정 가능한 손실이 없었다고 합니다. 공들여 쌓은 지시문 대부분이 5세대에서는 없어도 되는 짐이었다는 얘기죠.

그럼 구체적으로 뭘 바꾸면 될까요?

5세대 맞춤형 클로드 사용 규칙

1. 일의 크기에 맞춰 모델 정리하기

기준은 앤트로픽이 이미 나눠뒀습니다. 며칠 굴려둘 자율 프로젝트면 페이블 5, 오늘 안에 끝낼 매일의 일이면 오푸스 5부터. 그 아래 가벼운 작업은 소넷 5의 몫입니다.

모델을 정했다면 effort 설정 역시 다시 체크해 보세요. 앤트로픽 가이드는 이전 모델에서 가져온 effort 기본값을 자기 평가로 다시 측정하라고 권합니다. 품질이 유지되는 구간에서는 low와 medium을 넉넉히 쓰고 까다로운 코딩·에이전트 작업에만 xhigh로 올리라는 거예요.

2. 프롬프트 재검증

권장하는 건 프롬프트에서 이런 항목들을 빼는 겁니다.

1. 검증 지시: 4세대 시절에는 모델을 못 믿어서 “끝나면 꼭 검증해”를 프롬프트마다 붙였잖아요. 오푸스 5는 시키지 않아도 자기 작업을 검증하기 때문에 이 지시는 검증을 두 번 시키는 비용이 됩니다.

2. 재확인 지시: 마찬가지입니다. “답을 다시 확인해”·”응답 전에 재검증해”는 모델이 이미 하는 행동과 겹쳐서 결과 개선 없이 비용만 더해요.

3. subagent 남발 금지: 오푸스 5는 이전 모델보다 subagent에 쉽게 위임합니다. 그래서 작은 태스크까지 위임하면 비용과 시간이 몇 배로 뜁니다. 어떤 상황에 위임할지 명시하거나 띄울 수 있는 에이전트 수에 상한을 두세요.

3. 더 많이 위임하기

컨텍스트를 주입하는 방식도 전과는 좀 다릅니다. 이제 좀 더 많은 자유를 주는 편이 낫다고 합니다. 그만큼 똑똑해졌기 때문이죠.

컨텍스트 엔지니어링 규칙 문서 <출처: 앤트로픽>

첫째, 규정형 규칙 대신 판단 위임하기: “여러 문단 docstring 절대 쓰지 말라”라고 규정하는 대신 “주변 코드처럼 써라. 주석 밀도·네이밍·관용구를 맞춰라”라고 판단을 넘기는 식입니다. 새 모델은 명시적 제약 없이도 뉘앙스 판단을 더 잘 처리하거든요.

둘째, 점진적 공개: 상세 지침을 미리 몽땅 밀어 넣지 말고 필요할 때 불러오는 Skill로 옮기고 CLAUDE.md는 가볍게 유지하는 식입니다.

셋째, 자동 메모리 활용: 수동으로 관리하던 CLAUDE.md는 이제 복잡성을 모두 대변하지 못합니다.

권장 아키텍처는 네 가지 층입니다. 시스템 프롬프트에는 제품 지침만, CLAUDE.md는 가볍게, 팀의 견해는 Skill로, 깊은 스펙은 코드 위주의 레퍼런스. 결국, 지시문 유지보수에 쓰던 시간을 스펙과 레퍼런스 품질에 쓰라는 거죠.

모델 선택 기준 + 당장 수정할 6가지

지금까지 본 내용을 토대로, 오푸스 5를 더해 어떤 모델을 언제 쓸지와 지금 당장 수정하면 좋을 프롬프트+하네스 사용법을 정리했습니다.

<출처: 작가>

[6가지 수정 제안]

“끝나면 꼭 검증해”· “다시 한번 확인해” 같은 검증·재확인 지시
조건 없는 subagent 위임 피하기(위임 기준과 개수 상한으로 교체)
“절대 ~하지 말라”식 규정형 규칙 피하기(판단 위임형으로 교체)
응답 길이·간결성을 명시해서 지시
thinking은 켠 채 effort를 낮추는 식의 비용 관리 지시
이전 모델에서 가져온 effort 기본값을 내 태스크에 맞춰 재구성

마치며

이러한 변화는 비단 클로드 5세대만의 이야기도 아닙니다. 사실 GPT도, 또 다른 모델들도 마찬가지죠. 모델 골라 쓰기가 산업이 되고 각자 자기 업무에 맞춰 직접 평가하는 흐름은 이미 번지고 있어요.

그러니 갈수록 “어떤 모델이 제일 좋아요?”는 크게 의미 없는 질문이 될 겁니다. 이 일에는 어떤 모델을 어떻게 써야 할지 알아보세요. 그 답은 벤치마크 표보다 내 프로젝트 폴더에 먼저 있을 테고요. 자, 그럼 저는 이제 오푸스 5 돌리러 가볼게요. 뭘 더 잘하는지 찾아봐야겠습니다.

]]>

우리 개발자들, 이제 어떻게 해야 해?

인공지능 시대 앞에 선 주니어 개발자의 기록

<출처: 작가, AI로 제작>

까만 화면 위로 문장이 한 글자씩 떠오른다.

나는 그 앞에 앉아 요구사항을 적었다가 지우기를 반복한다. 원하는 동작을 설명하고, 예외 상황을 덧붙이고, 기존 코드의 맥락을 알려준다. 그러면 에이전트가 코드를 작성한다. 눈으로 결과물을 훑고, 또 다른 에이전트로 검수한 다음, 부족한 부분을 다시 요구사항으로 정리해 요청한다.

이제 이런 방식은 내게 낯선 실험이 아니라 일상이다.

2026년에 소프트웨어 엔지니어로 일한다는 것은 참 이상한 경험이다. 우리는 오랫동안 예측 가능한 세계에서 일한다고 믿어왔다. 코드는 입력에 따라 정해진 결과를 내고, 버그에는 원인이 있으며, 그런 시스템은 논리적으로 설명될 수 있어야 한다고 배웠다.

그런데 지금 우리 손에는 비결정론적인 도구가 쥐어져 있다. 같은 요청에도 매번 조금씩 다른 결과를 내놓는 도구, 정확히 어떤 답을 줄지 알 수 없지만 놀라운 속도로 결과물을 만들어내는 도구. 마치 어떤 마법이 나올지 모르는 지팡이를 들고, 각자의 주문을 외우며 무언가를 만들어내는 기분이다.

우리는 이제 어떻게 해야 할까. AI가 코드를 쓰고, 도구가 판단을 돕고, 어제의 상식이 오늘 흔들리는 시대에 개발자는 어디에 서 있어야 할까. 여전히 우리에게 필요한 자리는 어디일까.

흔들린 믿음

불과 1, 2년 전만 해도 이런 방식으로 일할 줄은 상상하지 못했다. 예전 같았으면 직접 파일을 열고, 코드를 읽고, 한 줄씩 수정했을 것이다. 하지만 지금은 먼저 요구사항을 쓴다. 직접 작성하기보다, 코드가 만들어지도록 지시하고 검토하는 시간이 더 많아졌다.

이제 막 이 업계로 들어오려는 후배들에게 나는 무엇을 조언할 수 있을까. 자료구조와 알고리즘을 공부하라고 말해야 할까. 운영체제와 네트워크, 데이터베이스 같은 컴퓨터 과학의 기본기를 깊게 익히라고 말해야 할까. 물론 이 모두가 여전히 중요하다고 믿고 싶다. 그러나 예전처럼 확신에 차서 말하기는 어려워졌다. “AI를 제대로 쓰려면 개발자도 그만큼의 지식을 갖춰야 한다”는 전제가 우리 사이를 이어줬지만, 시간이 지날수록 그 전제마저 흔들리고 있다.

이제는 한두 줄의 프롬프트만으로도 보안 취약점을 점검하고, 테스트 코드를 만들고, 리팩터링 방향을 제안받을 수 있다. 고급 해커 수준의 지식을 갖추지 않아도 AI의 도움을 받아 코드의 보안을 살필 수 있는 시대가 온 것이다. 물론 그 결과를 이해하고 책임지는 일은 여전히 사람에게 남아 있다. 하지만 적어도 “깊은 지식이 있어야만 AI를 제대로 활용할 수 있다”는 말은 더 이상 절대적인 방어선처럼 느껴지지 않는다.

고용주들의 기대도 달라지고 있다. AI를 통한 생산성 향상은 이미 업계 전반에서 눈에 보이는 성과로 나타났고, 적은 시간에 더 많은 결과물을 요구하는 분위기는 점점 강해지고 있다. 이런 상황에서 “Back to Basic”을 외치며 다시 모든 코드를 한 줄씩 직접 작성하던 시절로 돌아가자 말할 수 있을까. 쉽지 않다. 이미 AI 도구는 우리 일의 방식 안으로 깊숙이 들어와 버렸다.

사람이 짠 코드는 다르다고, 복잡한 맥락을 이해하고 책임질 수 있는 것은 결국 인간 엔지니어뿐이라고 믿고 싶다. AI가 코드를 만들 수는 있어도, 진짜 엔지니어링은 쉽게 대체되지 않을 것이라고도. 그러나 이 믿음도 점점 흔들리고 있다.

돌이켜보면 인간이 작성한 코드가 언제나 훌륭했던 것은 아니었기 때문이다. 모든 개발자가 좋은 코드를 썼던 것도 아니고, 모든 시스템이 아름다운 설계 위에 세워졌던 것도 아니다. “작동하면 건드리지 마라”는 말이 있었고, “레거시에는 이유가 있다”는 말도 있었다. 그 말들 뒤에는 수많은 타협과 임시방편, 그리고 누구도 쉽게 설명하지 못하는 코드들이 숨어 있었다.

그렇다면 사람의 코드와 AI의 코드는 정말 얼마나 다른가. AI가 만든 결과물을 그대로 믿을 수는 없다. 검토도 필요하고, 책임도 결국 사람에게 남는다. 하지만 적어도 “사람이 만들었기 때문에 더 낫다”는 말은 더 이상 충분한 방어선이 되지 않는 듯하다. 인간의 코드도 애초에 불완전했고, AI는 빠르게 그 불완전함의 영역을 침범하고 있다.

어떻게든 살아남아야지

이 격랑의 시대에서, 고작 주니어 엔지니어인 나는 어떤 선택을 해야 했을까.

얼마 전, 나는 이직을 했고, 백엔드 엔지니어에서 인공지능을 다루는 풀스택 엔지니어로 직무를 전환했다.

그것이 정답이었다고 말할 수는 없다. 다만 한 가지는 분명했다. 가만히 있을 수는 없었다. 세상이 바뀌는 속도는 너무 빨랐고, 나는 그 변화가 지나가길 기다릴 만큼 여유롭지 않았다. AI가 개발자의 일을 대체할지도 모른다는 불안, 내가 쌓아온 개발 경험이 어느 순간 낡은 기술이 될지도 모른다는 두려움, 지금 공부하는 것들조차 몇 년 뒤에는 의미를 잃을지도 모른다는 허무함이 계속 나를 흔들었다.

전통적인 웹 서비스 산업의 포지션에 그대로 머물러 있다면, 앞으로의 변화 속에서 오래 살아남기 어렵겠다는 생각이 컸다. 물론 웹 서비스 자체가 사라진다고 본 것은 아니다. 여전히 세상의 많은 문제는 웹의 형태로 사용자에게 전달된다. 사람들은 미래에도 로그인하고, 데이터를 저장하고, 결제하고, 검색하고, 알림을 받을 것이다. 그 모든 흐름에는 앞으로도 여전히 백엔드가 필요할 것이다.

하지만 이 문제들을 푸는 방식은 급격히 달라지고 있다. 예전에는 기능을 정의하고, API를 만들고, 데이터베이스를 설계하고, 서버를 운영하는 능력이 중시되었다. 그러나 이제는 요청을 단순히 처리하는 것을 넘어, 사용자의 의도를 해석하고, 적절한 도구를 호출하고, 여러 시스템을 연결해 결과를 만들어내는 흐름이 점점 중요해지고 있다. 그 변화의 중심에 인공지능이 있다고 느꼈다.

그래서 제대로 공부해야겠다고 생각했다. 단순히 도구를 잘 쓰는 사람이 아니라, 인공지능이 전통적인 서비스와 어떻게 상호작용하는지, 어떤 한계를 가지고 있는지, 어떻게 안전하게 쓰일 수 있는지 이해하는 사람이 되고 싶었다. 그 연장선에서 대학원 지원도 준비하고 있다. 회사에서 마주하는 문제만으로는 부족하다고 느꼈고, 조금 더 깊게 이 분야를 들여다보고 싶었다.

그렇다고 두려움이 사라진 것은 아니었다. 학생 때부터 꿈꿔왔던 백엔드 분야의 스페셜리스트가 되겠다는 목표를 포기하는 것이 맞을까. 다양한 분야를 다루는 제너럴리스트가 되겠다는 새로운 목표는 몇 년 뒤에도 의미가 있을까. 나는 여전히 이런 생각들 앞에서 자주 멈춰 선다.

막연한 미래 너머

학생 시절의 나는 개발자의 미래를 꽤 단순하게 상상했다. 회사에 들어가 좋은 선배에게 배우고, 실력을 쌓고, 언젠가는 능숙한 시니어 개발자가 되는 것. 새로운 기술이 나오더라도 기본기를 잘 다져두면 따라갈 수 있을 것이라고 믿었고, 이 믿음은 오랫동안 나를 지탱해주었다.

하지만 지금은 이 믿음이 조금은 부서졌다.

몇 년 전만 해도 직접 코드를 작성하는 것이 성장의 중요한 증거처럼 느껴졌다. 어려운 버그를 해결하고, 복잡한 로직을 구현하고, 성능을 개선하는 경험이 실력의 기반이라고 생각했다. 그런데 이제 나는 이 일들의 상당 부분을 인공지능과 함께 처리한다. 전이었다면 하루 종일 붙잡고 있었을 문제를 인공지능이 몇 분 만에 풀어내는 모습을 볼 때면, 짜릿하면서도 이상하게 허무하다.

분명 생산성은 높아졌다. 하지만 생산성이 높아진 만큼, 나의 역할에는 더 자주 의문이 든다.

이제 우리는 무엇을 잘해야 할까. 코드를 빠르게 작성하는 능력, 인공지능에게 좋은 지시를 내리는 능력, 서비스 전체를 설계하는 능력이 전부일까. 혹은 도메인을 이해하고, 사용자 문제를 정의하는 능력이 최고일까.

답은, 아마도 전부를 잘해내야 한다는 것이다.

그래서 더 어렵다. 예전에는 공부해야 할 것이 많아도 어느 정도 순서가 있었다. 예컨대 언어를 배운 다음에는 프레임워크를 익히고, 데이터베이스를 공부하고, 배포와 운영을 경험하는 식이었다. 그런데 지금은 모든 것이 순서 없이 쏟아져 들어오는 것 같다. 백엔드도 해야 하고, 클라우드도 알아야 하고, 인공지능도 알아야 하고, 보안도 알아야 하고, 제품 감각도 필요하다고 한다. 여기에 매주 새로운 도구와 프레임워크가 등장한다.

무언가를 놓치고 있다는 생각. 지금 따라가지 않으면 영영 뒤처질 것 같다는 두려움. 이런 생각들은 나를 계속 움직이게 하지만, 동시에 갉아먹기도 한다.

하지만 요즘은 다르게 생각하려 한다. 미래를 막연하다고 느끼는 것이 꼭 내가 무능하다는 뜻은 아닐지도 모른다. 시대가 정말로 예측하기 어려워졌다는 말일 수도 있다. 지금 공부하는 기술이 5년 뒤에도 같은 형태로 남아 있을지는 아무도 모른다. 지금 유망해 보이는 직무가 몇 년 뒤에도 같은 이름으로 존재할지도 확실하지 않다. 그러니 불안한 것은 자연스러운 일일지 모른다.

기술은 계속 바뀐다. 도구도 계속 바뀐다. 어쩌면 지금 우리가 열심히 익히는 많은 것들이 몇 년 뒤에는 다른 이름으로 불릴지도 모른다. 하지만 문제를 정의하고, 맥락을 이해하고, 결과에 책임지려는 태도는 쉽게 사라지지 않을 것이다.

나는 이 믿음만은 아직 놓고 싶지 않다.

마치며

우리는 이제 어떻게 해야 할까?

이 질문에 자신 있게 답할 수 있는 사람은 많지 않을 것이다. 새 시대에 대해 말하는 사람은 많지만, 아직 그 시대를 정확히 살아본 사람은 없다. 모두가 변화의 한복판에 서 있고, 각자의 방식으로 살아내고 있다.

나 역시 그렇다. 백엔드 엔지니어에서 풀스택 엔지니어로 방향을 틀었지만, 이 선택이 완벽한 답이라고 말할 수는 없다. 대학원에 지원하고, 인공지능을 공부하고, 새로운 도구를 익히려 하지만, 이 길이 어디로 이어질지 확신하지 못한다.

그래도 되뇌인다. 변화를 외면하지 말자. 하지만 내가 쌓아온 것을 버리지도 말자. 대신 그것을 새로운 시대와 연결해보자.

백엔드를 해왔으니, 나는 그 경험 위에 인공지능을 얹을 수 있다. 어쩌면 인공지능 시대의 개발자에게 필요한 것은 자기 경험을 잃지 않고, 변화하는 기술과 연결해 다시 쓸 수 있는 능력일지 모른다 믿고 말이다. 인공지능이 코드를 쓰는 시대에도, 결국 누군가는 문제를 정의해야 한다. 누군가는 결과를 책임져야 한다. 누군가는 이용자의 불편함을 발견하고, 기술을 통해 상상을 현실로 만들어내야 한다. 나는 그 자리에 우리가 여전히 필요하다고 믿고 싶다.

지금의 나 역시 할 수 있는 말은 대단치 않지만, 그래도 전하고 싶다.

사라질까 두려워 멈추기보다, 변화하는 세상 속에서 우리가 다시 쓰일 자리를 찾아가자고. 우리 모두 결국에는 그 일을 함께 해낼 것이라고.

]]>

가재와 고블린은 왜 AI 프론티어의 상징이 됐을까

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

AI 업계는 왜 갑자기 밈과 캐릭터에 빠졌을까

한때 기술 업계의 언어는 꽤 단순했습니다. 누가 더 빠른지, 누가 더 정확한지, 벤치마크 숫자가 얼마나 높은지가 거의 전부였죠. 그런데 요즘 AI 업계를 보면 분위기가 조금 다릅니다. 모델 성능 이야기를 하다가도 어느새 가재, 고블린, 이상한 별명, 너드한 말투 같은 것이 따라붙습니다. 얼핏 보면 그저 인터넷 농담 같지만, 실제로 이 현상은 꽤 파장이 큽니다.

OpenAI는 아예 공식 글을 통해 모델이 ‘고블린(goblin)’ 같은 표현을 과하게 쓰게 된 이유를 설명했습니다. 로이터(Reuters) 역시 OpenClaw 계열 에이전트를 둘러싸고 ‘가재(lobsters)’, ‘가재 키우기(raising lobsters)’ 같은 표현이 커뮤니티 안에서 퍼지고 있다 전했습니다.

저는 이 현상이 AI 업계가 유난히 가벼워져서 생긴 일이라고 보지 않습니다. 오히려 그 반대에 가깝습니다. AI는 본질적으로 텍스트 위에서 움직이는 산업입니다. 프롬프트도 텍스트고, 사용 경험 공유도 텍스트입니다. 그렇게 깃허브 이슈와 리드미(README), X 포스트, 디스코드 대화, 튜토리얼까지 전부 텍스트 중심으로 흘러갑니다. 이런 환경에서는 길고 어려운 기술 설명보다 짧고 반복하기 좋은 상징이 훨씬 빨리 퍼집니다. OpenAI가 말한 고블린도, OpenClaw 주변의 가재라는 밈도 결국 성능 수치보다 먼저 기억하기 좋은 일종의 문화적 인터페이스가 된 셈이죠.

하나 더, 주목해야 할 지점이 있습니다. AI 도구는 다른 소프트웨어보다 훨씬 강하게 “같이 쓰는 느낌”을 줍니다. 혼자 설치해서 조용히 쓰고 끝나는 툴이 아니라는 뜻이죠. 누군가는 프롬프트를 공유하고, 누군가는 워크플로를 자랑하고, 또 누군가는 실패담을 밈으로 바꿔 퍼뜨립니다. 사람들은 도구를 쓰는 데서 멈추지 않고, 그 도구를 둘러싼 말투와 문화까지 함께 소비하고 있습니다. 그러니 AI 업계에서 밈은 장식이 아닙니다. 사용 경험을 더 쉽게 설명하게 만들고, 같은 도구를 쓰는 사람들 사이에 묘한 동질감을 만들어주는 장치에 가깝습니다.

결국, AI 업계가 밈과 캐릭터에 ‘빠진’ 게 아닙니다. 밈과 캐릭터가 AI 업계에 ‘빠진’ 것에 가깝습니다. 기술이 복잡할수록 사람들은 이해하기 쉬운 상징을 찾게 됩니다. 그리고 그 상징이 반복되기 시작하면, 어느 순간부터 기능보다 이 상징이 주는 뉘앙스를 먼저 기억합니다. 그런 맥락에서 가재와 고블린이 단순한 농담을 넘어, AI 생태계를 설명하는 언어가 되기 시작했다고 봅니다.

왜 하필 ‘가재’와 ‘고블린’이었을까

물론 AI 업계라고 아무 말에나 밈이 붙어 커진 건 아닙니다.

우선 고블린은 귀엽기만 한 캐릭터는 아니죠. 좀 장난스럽고, 살짝 엉뚱하고, 어딘가 너드한 느낌이 있습니다. OpenAI도 공식 글에서 이 goblin이란 표현이 특정 시기 모델 출력에서 늘어났다고 밝혔습니다. 특히 “Nerdy” 성격 설정과 연결돼 있었다고 설명했죠. 그러니까 이건 우연히 한두 번 튀어나온 말이 아니라, AI에 의도적으로 “이상하게 재밌는 말투”를 요구하다 함께 퍼진 표현이었던 셈입니다.

가재도 마찬가지입니다. OpenClaw 쪽 커뮤니티에서는 에이전트를 ‘가재’라고 부릅니다. 곧 에이전트를 돌리고 키우는 일을 ‘가재 키우기’라고 표현할 정도로 널리 퍼졌죠. 이 표현이 재밌는 이유는 AI 에이전트를 그냥 설치형 프로그램이 아니라, “계속 돌보고, 학습시키고, 잘 굴러가게 만들어야 하는 존재”처럼 느끼게 하기 때문입니다. 한마디로 설명하기 어려운 에이전트라는 기술의 성격을, 가재라는 말이 훨씬 쉽게 전달해주는 거죠.

이처럼 두 상징은 기술을 딱딱한 프로그램이 아니라, 뭔가 살아 있는 존재처럼 느끼게 만듭니다. 그냥 "에이전트"라고 하면 솔직히 좀 차갑고 어렵게 들리잖아요. 그런데 여기에 가재나 고블린 같은 표현이 붙으면 느낌이 확 달라집니다. 갑자기 이 기술이 설명서 속 기능이 아니라, 성격이 있고 반응도 제각각인 무언가처럼 보이기 시작합니다.

저는 이 점이 꽤 중요하다고 생각합니다. 사람들은 어려운 기술 설명보다 이미지가 잡히는 말을 더 오래 기억하거든요. 모델 구조나 시스템 아키텍처는 금방 잊어도, “그 고블린 같은 말투”나 “까다로운 가재를 키우는 느낌”은 머리에 남습니다. 그러니까 이 표현들은 그냥 웃긴 별명이 아닙니다. 복잡한 기술을 사람들이 쉽게 받아들이도록 돕는 일종의 번역 장치에 가깝습니다.

결국 가재와 고블린은 어렵고 낯선 AI를, 개발자들이 자기들 언어로 더 쉽고 재밌게 바꿔 부르며 밈이 되었습니다. 그렇게 생긴 말이 커뮤니티 안에서 반복되다 보니 어느 순간부터는 기술보다 그 분위기와 캐릭터가 먼저 기억되기 시작한 거죠.

밈은 어떻게 커뮤니티를 키우고 생태계를 넓히나

밈의 진짜 힘은 사람을 구경꾼에서 참여자로 바꾸는 데 있습니다. 기능만 좋은 도구는 한 번 써본 다음 “좋더라”하고 끝날 수 있습니다. 그런데 밈이 붙고 커뮤니티가 커지면 달라집니다. 사람들이 그 도구를 설명하고 싶어하며, 써본 경험을 자랑하고 싶어집니다. 나아가 자기 식으로 해석해서 또 다른 이야기를 만들기 시작합니다.

예를 들어 누군가 새로운 AI 에이전트를 써봤다고 해보겠습니다. 기능만 이야기하면 “자동화가 잘 된다”, “속도가 빠르다” 정도에서 끝납니다. 그런데 여기에 “우리 가재를 키웠다” 같은 표현이 붙는 순간, 그 경험은 갑자기 남에게 말하고 싶은 이야기가 됩니다. 훨씬 쉽게 기억되고, 보다 빨리 퍼지며, 더 쉽게 따라 하게 되죠. 복잡한 기술이 짧고 재밌는 한 문장으로 바뀌기 때문입니다.

기술은 원래 입소문 내기가 쉽지 않습니다. 아무리 좋아도 설명이 복잡하면 남에게 전하기 귀찮아집니다. 반면 밈은 그 복잡한 설명을 확 줄여줍니다. 일종의 압축 파일처럼 핵심 감각만 남겨서 전달해주는 거죠. 그래서 처음 보는 사람도 "그게 정확히 뭔진 모르겠는데, 좀 재밌어 보이네?"라며 반응합니다. 이 반응이 좋은 트리거입니다. 기술은 원래라면 먼저 이해한 다음에야 움직이는데, 밈은 이해보다 관심을 먼저 만들어주니까요.

그다음부터는 커뮤니티가 알아서 커집니다. 누군가 밈을 보고 흥미가 생겨 처음 써보고, 누군가는 사용 후기를 올립니다. 또 누군가는 그걸 패러디해 또 다른 글이나 이미지를 만들고, 다른 누군가가 그걸 보고 "나도 한번 해봐야겠다"면서 들어옵니다. 이 흐름이 이어지면 사람들은 더 이상 그 도구를 혼자 쓰지 않습니다. 같이 쓰고, 같이 떠들고, 같이 실험하는 분위기가 만들어집니다. 바로 그때부터 제품은 단순한 기능 묶음이 아니라 커뮤니티의 중심이 됩니다.

모두 밈의 힘입니다. 좋은 밈은 사람을 웃기는 데서 그치지 않습니다. 사람을 모이게 하고, 계속 머무르게 하고, 자기도 뭔가 얹어보고 싶게 만듭니다. 그래서 밈이 한번 제대로 붙은 제품은 단순히 “좋은 툴”에서 끝나지 않습니다. 점점 더 많은 사용자가 자기 경험을 보태는 생태계로 커지게 됩니다.

그러니 밈은 마케팅 문구보다 강할 때가 많습니다. 회사가 일방적으로 던지는 문장이 아니라, 사용자들이 스스로 꺼내 쓰고 퍼뜨리는 언어이기 때문입니다. 그래서 가재든 고블린이든 이런 표현이 커뮤니티 안에 자리 잡기 시작하면, 그건 그냥 유행어가 아니라 생태계를 키우는 연료가 됩니다. 기술은 회사가 만들지만, 문화는 사용자들이 키웁니다. 그리고 AI 업계에서는 밈을 업고 그런 문화가 생각보다 훨씬 빠르게 퍼지고 있습니다.

이런 너드한 브랜딩은 왜 ‘해자’가 될 수 있을까

밈이 재밌고, 커뮤니티가 활발해지는 것까지는 많은 분이 쉽게 이해하실 겁니다. 그런데 그 다음, 정말 중요한 단계가 있습니다. 이렇게 자리 잡은 문화와 그로 인한 커뮤니티는 제품의 해자가 되기 시작합니다.

보통 해자라고 하면 기술력, 데이터, 자본, 유통 같은 걸 먼저 떠올리잖아요. 물론 그것들도 여전히 중요합니다. 그런데 AI 시장은 생각보다 기능 격차가 빨리 좁혀집니다. 오늘 대단해 보이던 기능이 몇 달 뒤에는 다른 서비스에도 비슷하게 들어 있는 경우가 많습니다. 성능 차이도 계속 따라잡히고요. 그러다 보니 “기능이 더 좋다”만으로는 오래 버티기 점점 어려워집니다. 이럴 때 강하게 남는 것이 바로 사람들이 그 제품을 둘러싼 문화에 얼마나 익숙해졌는가입니다.

예를 들어 어떤 도구를 오래 쓴 사람은 단순히 그 기능만 익히지 않습니다. 그 도구를 쓰는 사람들 특유의 말투를 알고, 어디서 정보를 얻어야 하는지도 알고, 커뮤니티 안에서 무슨 이야기가 오가는지도 압니다. 쉽게 말해 제품 하나를 쓴 게 아니라, 그 제품이 속한 세계에 적응한 상태가 되는 거죠. 이 상태까지 오면 다른 대안이 나와도 쉽게 옮기지 않습니다. 기능이 조금 더 좋아 보여도, 이미 익숙한 언어와 분위기, 사람들, 참고할 자료가 있는 쪽이 훨씬 편하거든요.

그래서 너드한 브랜딩이 강한 제품은 생각보다 단단한 팬층을 보유합니다. 사람들은 겉으로는 기능 때문에 쓰는 것처럼 보이지만, 실제로는 그 제품을 둘러싼 분위기까지 함께 쓰고 있는 경우가 많습니다. “이 툴을 쓰는 사람들은 이런 농담을 한다”, “이 생태계에서는 이런 표현이 통한다”, “여기서는 이런 방식으로 공유한다” 같은 기억이 쌓이면, 이 시간들은 그냥 사용 경험이 아니라 소속감에 가까워집니다. 그리고 소속감은 생각보다 잘 깨지지 않습니다.

저는 그래서 가재나 고블린 같은 밈을 가볍게만 보지 않습니다. 이런 표현은 웃기려고만 존재하는 게 아니라 “우리끼리는 이걸 이렇게 이해한다”는 공통의 언어를 만들어줍니다. 공통 언어가 생기면 사람은 더 오래 남고, 더 많이 공유하고, 더 쉽게 다른 사람을 데려옵니다. 그렇게 들어온 사람도 다시 그 언어를 배우고 따라 쓰게 되고요. 이 과정이 반복되면 브랜드는 광고비를 많이 쓰지 않아도 점점 더 강한 생태계를 가지게 됩니다.

결국 해자는 꼭 거창한 기술 장벽으로만 만들어지지 않습니다. 사람들이 떠나기 아까운 문화, 익숙해서 벗어나기 어려운 분위기, 들어오면 괜히 계속 머물게 되는 언어도 충분히 해자가 될 수 있습니다. AI 업계에서 너드한 브랜딩이 무서운 이유가 바로 여기에 있습니다. 그냥 재밌어서 퍼지는 게 아니라, 퍼질수록 더 강한 락인을 만드는 구조를 갖고 있기 때문입니다.

AI 시대 브랜딩은 앞으로 어떻게 달라질까

그래서 더욱 앞으로 AI 제품은 “성능이 좋은 도구”만으로 브랜딩하기 점점 어려워질 겁니다. 물론 모델 성능은 여전히 중요합니다. 속도, 정확도, 가격, 안정성 같은 건 기본이니까요. 그런데 기본이 어느 정도 비슷해지고 나면, 결국 사람들이 오래 기억하는 건 숫자보다 느낌인 경우가 많습니다. “이 서비스는 똑똑하다”보다 “이 생태계는 재밌다”, “여긴 계속 들어가 보고 싶다”, “이 툴 쓰는 사람들 분위기가 좋다” 같은 게 더 오래 남는다는 뜻입니다.

예전 테크 브랜딩은 조금 더 정제된 방향을 추구했습니다. 차갑고, 똑똑하고, 믿을 만하고, 빈틈없어 보이는 이미지가 강했죠. 그런데 AI는 조금 다릅니다. 사용자가 단순히 결과물만 받는 소비자가 아니기 때문입니다. 직접 프롬프트를 넣고, 결과를 다듬고, 워크플로를 만들고, 그 경험을 공유하는 참여자에 가깝죠. 그러니 이제는 기업이 완성된 이미지를 보여주는 것만으로는 부족합니다. 사용자가 그 안에 들어와 같이 놀고, 실험하고, 자기 식으로 해석할 여지를 만들어줘야 합니다.

그래서 앞으로 강력한 AI 브랜드는 더 인간적으로 보일 가능성이 높습니다. 꼭 친절하고 따뜻할 거라는 뜻은 아닙니다. 그보다는 좀 더 캐릭터성이 있고, 말투도 있으며, 사람들이 자기들끼리 놀 수 있는 여백이 있는 브랜드가 될 겁니다. 너무 반듯하고 완벽해 보이는 브랜드보다, 약간의 장난기와 개성을 가진 브랜드가 더 강하게 기억될 수도 있습니다.

특히 개발자 생태계에서는 이런 차이가 더 크게 작용할 겁니다. 어차피 개발자들은 기능만 쓰는 사람이 아니라, 도구에 대해 떠들고 비교하고 밈을 만들어 자기 경험을 덧붙이는 사람들이니까요.

앞으로는 문서나 예제, 데모 영상, 커뮤니티 글, 밈까지 전부 합쳐져 하나의 브랜드 경험이 될 가능성이 큽니다. 예전에는 브랜딩과 제품 경험이 어느 정도 나뉘어 있었다면, AI 업계에서는 둘이 거의 붙어버렸습니다. 제품을 쓰는 과정 자체가 곧 브랜드를 체험하는 과정이 되고, 커뮤니티에서 오가는 농담과 표현까지도 브랜드의 일부가 되는 거죠. 그러니 이제 AI 기업은 단순히 좋은 모델을 만드는 것만으로는 부족합니다. 사람들이 계속 머물고 싶어지는 문화까지 함께 설계해야 하는 시대를 맞았다고 봅니다.

결국 가재와 고블린 같은 사례가 보여주는 것도 같은 흐름입니다. 이건 그냥 인터넷 유행어가 아닙니다. AI 업계가 어떤 식으로 사람을 모으고, 묶어두고, 자기 생태계 안으로 끌어들이는지를 보여주는 단면입니다. 앞으로도 AI 시장에서는 성능 경쟁이 이어지겠지만, 그 못지않게 중요한 싸움이 하나 더 남아 있습니다. 누가 더 강한 세계관을 만들고, 누가 더 오래 기억할 문화를 갖느냐의 싸움입니다. 저는 그 경쟁이 생각보다 훨씬 중요해질 거라고 봅니다.

]]>

커서 ‘Automations’으로 프로젝트 개선한 후기

커서 ‘Automations’으로 사이드 프로젝트를 개선하는 방법과 한 달 사용기

AI와 코딩하면 속도는 빨라집니다. 대신 다른 부담이 생겼습니다. PR이 늘고, 에이전트가 만든 코드를 사람이 다시 리뷰하는 시간이 늘었습니다. 그리고 릴리즈 노트, 버전업, 중복 정리 같은 반복 유지보수는 점점 뒤로 밀리게 됩니다. 한동안 저는 이걸 ‘skills’를 만들어서 틈틈이 정리해 왔습니다. 그런데 이것을 챙기는 것도 꽤 버거운 일이더군요.

그런 와중에 책 ‘아주 작은 습관의 힘(Atomic Habits, 제임스 클리어 저)’를 읽으면서, 반복에 중요한 점은 구체적이고, 자동화된 시스템이라는 것을 알게 되었습니다. 그래서 커서의 Automations 기능을 활용하여, 구체적이고 자동화된 시스템을 만들었습니다. 프로젝트를 반복적으로 개선하는 저만의 워크플로우를 만든 거죠. 이번 글에서는 이 경험을 나누고자 합니다.

AI 에이전트의 피로감, 그리고 Automations

AI 에이전트로 코딩하면 속도는 빨라집니다. 이건 논의할 여지가 없는 현실입니다. 물론 그 빨라짐이 유용한지에 대한 논의는 여전히 활발합니다. 하지만 여기서는 유용함은 잠시 뒤로 두고, 속도감과 피로감에 대해 집중해 보겠습니다.

최근에 저는 동료에게 이런 말을 자주 합니다.

“OO님, 이거 다음 주까지 리뷰해 드려도 될까요?”
“OO님 이거 중복코드인데 AA 코드 확인해 보면 좋겠어요.”
“OO님 이 코드 의도가 무엇인가요?”

이런 말을 자주 하게 되는 근본적인 원인은 아직까지 AI 에이전트의 한계이기도 함과 동시에 속도가 빨라졌기 때문에 발생한다고 생각합니다. 이전에도 일정이 바빠 리뷰가 밀릴 때도 종종 있었고, 중복 코드이니 확인해 달라는 말이나, 코드 의도를 물어보는 말 또한 코드 리뷰할 때 많이 했던 코멘트이기도 합니다.

다만 속도가 빨라짐에 따라 더 자주 발생할 뿐입니다. 그리고 “AI 에이전트의 가장 큰 병목은 사람이다”라는 말이 어느덧 온몸으로 체감되기 시작했죠. 이를 해결하기 위해서 다양한 방법이 시도되고, 사람이 병목이기 때문에 사람의 간섭을 최대한 적게 하는 식으로 프로젝트의 설계가 변경되기도 합니다. 그리고 그 핵심에는 Automations, 즉 자동화가 있습니다.

이전에는 자동화하는 작업은 꽤 고된 작업이었습니다. 별도로 시스템을 띄워서 프로젝트를 연결하고, 관련된 프로그램까지 세팅해야 했죠. 그리고 이 방법조차 학습해야 했습니다. 하지만 각 제품에서 점차 편리한 자동화 기능이 나왔고, 오늘 소개할 커서의 Automations 또한 사용해 보니 매우 편리한 자동화 도구였습니다.

커서의 Automations

<출처: Cursor 공식 홈페이지>

커서 공식 홈페이지에 따르면, Automations는 일정이나 이벤트에 맞춰 클라우드 에이전트를 자동 실행해 주는 기능입니다.

구성은 단순합니다.

Cursor Automations 생성 화면 <출처: 작가 캡처>

그리고 만들기도 아주 편하고 직관적입니다. 그중에 만족스러운 부분은 이미 연동한 Tools는 바로 사용할 수 있다는 점이었습니다.

Automations 한 달 활용기

이번에는 제가 한 달 동안 사용했던 Automations를 리뷰해 보겠습니다.

버전업을 자동화하기

이건 Automations이 나오자마자 제가 바로 생성한 Automation입니다. 전문을 공유하는 것은 크게 의미가 없어, 어떤 목적의 지침인지만 정리해 보겠습니다.

main 브랜치에 머지된 변경 사항을 분석하여 릴리즈 노트를 생성한다.
dev 브랜치에만 추가된 변경 사항은 무시한다.
Semantic versioning 기준으로 버전업을 하고, 릴리즈 노트를 생성한다.
릴리즈 노트에 넣을 항목과 제외할 항목을 토대로 릴리즈 노트에 생성한다.
릴리즈 노트는 Major, Minor까지만 생성한다.

그리고 이 로직을 바탕으로 3주 동안 버전업을 진행해 보았습니다.

3주 동안 만들어진 릴리즈 노트 PR <출처: 작가>

우선 확인해 보면 사이드 프로젝트이지만, AI를 최대한 사용하고 있기 때문에 생각보다 변경 사항이 꽤 됩니다. 그래서 1.2.0에서 1.3.0으로 올리는 MINOR 업데이트를 제안했습니다. 그리고 MERGE 버튼을 딸깍하게 되면 배포가 되고 바로 다음과 같은 변경 사항이 배포됩니다.

1.3에 대한 릴리즈 노트 <출처: 작가>

이에 대한 디자인도 AI한테 적당히 만들어 달라고 요청했습니다. 적당한 카테고리 기준으로 깔끔한 디자인 시스템을 활용해서 만들어주는 것을 확인할 수 있었습니다.

릴리즈 노트 공유하고 칭찬받기 <출처: 작가>

공통 로직을 추출하기

다음으로는 공통 로직을 추출해서 리팩토링하는 Automation입니다. 제가 요새 리팩토링 2판(마틴 파울러 저)을 다시 읽으면서, 저만의 리팩토링 스킬을 만들려고 노력 중입니다. 그리고 이를 조금씩 활용해 보는 차원에서 이 공통 로직 자동화를 해보고 있습니다.

이것도 간략한 지침을 살펴보겠습니다.

코드베이스에 중복된 로직, UI, 스키마 등을 찾아, 프로젝트 규칙에 맞게 공용 로직 혹은 모듈로 추출하는 리팩토링 PR을 생성한다.
PR은 단순히 하나의 논리적인 목적 단위로만 만들어야 한다. (number formatting 통합과 UI 통합은 하나의 PR에 들어갈 수 없다)
사전 읽기 규칙으로 해당 마크다운 파일들을 활용한다.
리팩토링을 실행하기 앞서 테스트 코드가 부족하다면 테스트 코드를 생성하고, 리팩토링 전후의 동작은 테스트 코드를 동일하게 통과한다.

그리고 이 Automation은 일주일에 한 번씩 돌고 있습니다. 매일 돌면 좋은데, 매일 리팩토링 PR을 리뷰할 자신이 없어서요. 따라서 한 주에 하나씩 개선하는 것만으로 우선 만족하며 사용 중입니다.

공통 로직을 추출하는 PR <출처: 작가>

첫 번째 주를 보낸 뒤 생성된 PR을 확인해 보니, 6곳에서 중복 사용되던 로직을 공통 로직으로 추출하는 내용이었습니다. 히스토리를 살펴보니 특정 숫자가 입력되면 '○○만원' 형태로 포맷팅하는 간단한 로직이었는데, 이 기능이 개별 파일마다 직접 구현되어 있던 상황이었습니다.

다음 주 후보와 Test plan <출처: 작가>

그리고 자동으로 동작을 확인할 수 있도록 타입 체크, 린트, 테스트 코드가 정상 실행되었음을 보여주는 내용도 포함되어 있었습니다. 특히 고무적인 점은 다음 주 작업 후보에 대한 내용도 명시되어 있었다는 사실입니다. 실제로 코드를 살펴보니 바로 리팩토링할 대상이었습니다. 그래서 다음 주까지 기다리지 않고, 후속 PR을 만들어 즉시 처리해 버리기로 했습니다.

Sentry 버그를 자동으로 수정하기

Sentry 버그 자동 수정은 개발자들의 오랜 꿈인데요. 저 역시 '이슈 자동 생성'에서 '자동 해결'로 이어지는 흐름을 매번 꿈꿔왔지만, 수많은 시행착오와 장애물에 막혀 단 한 번도 완성하지 못했던 목표이기도 합니다. (이번에 과연 성공할 수 있을지는 아직 모르겠습니다.)

방법은 간단합니다.

Automations의 Triggers <출처: 작가>

Triggers 부분에 프로젝트를 연결하고, 아직 unresolved된 이슈가 있다면 Automations를 돌리겠다고 만들면 됩니다. 그리고 이건 다른 Automations와 달리 Tools를 여러 개 붙여주었습니다.

Automations의 Tools <출처: 작가>

그리고 한번 돌려보았습니다. 이 글을 쓰는 시점에서는 실제로 에러로그가 쌓이지 않아, 로컬에서 강제로 에러를 발생시키는 식으로 동작 방식을 확인했습니다.

Sentry Bug Automation 실사용 <출처: 작가>

실제로 돌려본 결과, 제가 사전에 정의한 Skip 기준에 맞춰 자연스럽게 무시한 것을 확인할 수 있었습니다. 다만 Sentry의 로깅 방식으로 하나의 에러에 대해 2가지 방식의 에러 로그가 쌓였고, 그 결과 중복된 Automation이 돌았습니다.

Sentry Bug Automation이 같은 에러에 대해서 도는 이슈 <출처: 작가>

추가로 저는 이 자동화는 생각보다 위험할 수도 있겠다고 생각했습니다. 현재 연결한 프로젝트는 사이드 프로젝트라서, 일 방문자 수가 아직은 몇 백 명 수준입니다. 따라서 아직까지 Sentry 에러가 많이 발생하지 않았죠. 하지만 실제로 활발히 운영되는 프로젝트라면, Sentry 로그가 무지막지하게 쌓이는 모습을 볼 수 있을 겁니다. 실제로 에러인지 에러가 아닌지, 그 여부에 따지기 전에 모수가 많으면 어디선가는 에러가 터지기 마련이거든요.

그래서 Automations의 실행 주기를 조절할 수 있는 기능이 있으면 좋겠다고 생각했습니다. 맨 처음에는 Trigger에 Scheduled를 붙여 Hourly로 돌리면 가능하지 않을까 했습니다. 하지만 찾고 보니 해당 조건은 AND가 아닌 OR라고 합니다. 따라서 아직까진 제한 방법이 없다고 알고 있는데요. 자칫하다 토큰을 녹이는 대참사가 발생할 수 있으니, 조심해야겠습니다.

만들어진 것을 가져다 쓰자

오랜 격언 중에 “Don't reinvent the wheel(바퀴를 다시 발명하지 마라)”이 있습니다. 이미 누군가 검증하고 완성해 놓은 기존 기술이나, 라이브러리를 처음부터 다시 만들려고 하지 말라는 개발 격언입니다.

이 격언에 따라, 가장 좋은 방법은 이미 누군가 만들어놓은 Automations를 가져다 사용하는 겁니다.

커서 marketplace 내 Automation 항목 <출처: 작가>

그리고 이런 잘 만들어진 Automation를 보면서 어떤 식으로 작성하는지, 어떤 식으로 연결하는지 확인하고 이젠 바퀴가 아닌 진정으로 필요한 것을 만들 때 적절하게 활용할 수 있습니다.

Automation 중 Assing PR reviewers <출처: 작가>

제가 알기로는 PR reviewers를 적절하게 할당하는 것은 꽤 어렵습니다. 따라서 일반적으로 그룹을 지정해 놓고 해당 그룹 내에 랜덤으로 분배하는 식으로 많이 합니다.

하지만 이 Automation를 보고, git history를 통해 해당 PR에서 어떤 사람이 가장 많은 연관성을 가지고 있는지 식별할 수 있겠다고 느꼈습니다. 그리고 그 개발자에게 바로 할당하면 굳이 reviewer를 신경 쓰지 않아도, 적합한 사람에게 할당이 될 겁니다. (안타깝게도 제가 하는 사이드 프로젝트는 저 혼자라 reviewer가 필요 없긴 합니다.) 아무튼 이런 방식으로 다른 사람이 만들어둔 Automation를 통해 간단히 시도해 볼 수도 있습니다.

Cursor Automations 후기

한 마디로 정리하면, 커서 Automations는 “매우 편리하니 실무에 바로 적용하자”라고 할 수 있습니다. 요즘 회사에서 많은 시간을 쏟는 부분은 반복되는 업무를 추출하여 자동화하는 일입니다. 하지만 이런 식의 자동화는 결국엔 우리가 직접 호출해야 하는 반자동화에 가깝습니다.

하지만 Cursor Automations는 다릅니다. Instructions를 한 번 써두면, 스케줄이나 이벤트에 맞춰, Cloud Agent가 알아서 실행됩니다. 그리고 사이드 프로젝트에서 한 달 동안 사용해 보니, 그 수준은 이미 충분히 합리적입니다. 또한 위에서 본 Reviewer 할당 예시를 보면, 우리가 평소에 제한적으로 사용했던 자동화를 실용적인 수준으로 확실히 끌어올릴 수 있습니다.

저는 한 달 동안 릴리즈 노트 PR 4개와 중복 코드 추출 PR 3개를 처리했습니다. 월요일마다 버전 업되는 코드와 자동으로 리팩토링을 제안해 주는 PR를 보면서 한 주를 시작합니다. 그리고 머지않아 Sentry 버그 PR을 읽고 나서, PR을 검증해 보고 이슈 해결을 하는 날도 생길 겁니다.

마치며: 진정한 의미의 페어 프로그래밍의 시대

저는 분명히 혼자 사이드프로젝트를 하고 있는데, 자꾸 누군가와 협업하는 느낌이 납니다. 제가 모르는 이슈와 리팩토링 해야 하는 부분을 찾아와, 같이 코드를 살펴보자고 말하는 동료 개발자가 어딘가 숨어있는 느낌입니다. 이전에 40년 차 프린시펄 개발자가 말하기를, 본인은 요새 AI와 페어프로그래밍을 하고 있다는 말을 했습니다. 저는 이번 Automations를 활용해 보면서 그 말에 공감했습니다.

단순히 코드 라인 단위의 페어프로그래밍을 벗어나, 진정한 의미의 협업, 페어 프로그래밍 이젠 가능한 시대가 되었습니다. 어찌 보면 ‘개발자가 말하지 않아도 코드베이스가 개선된다’라는 건, 개발자 자리를 위협하는 것처럼 들릴 수 있습니다.

하지만 저는 이 부분을 다르게 봅니다. 원래 개발자들은 그런 사람들입니다. 가장 귀찮았던 일을 찾아내고, 자동화하고, 더 단순하게 만들려는 욕심이 가득한 사람들이죠. 릴리즈 노트 정리, 중복 유틸 추출, 문서화 정리, 버전 업데이트 등 솔직하게 재미없는 일이지만, 꼭 해야 하는 일이기도 했습니다. (Sentry 이슈 해결은 논외입니다. 이건 무조건 해야 하는 일입니다.)

Automations는 그 귀찮은 구간을 백그라운드로 밀어냅니다. 그리고 그렇게 만들어진 소중한 시간을, 개발자는 원래 하고 싶었던 일에 쏟아낼 수 있습니다. 이 변화는 제가 평소에 생각하는 개발 철학인 “편리함을 추구하는 개발”에 가장 근접한 모습이기도 합니다.

AI로 인해 제 개발 철학에 가장 가까워진 지금, AI는 축복일까요? 아니면 저주일까요? 적어도 저는 요새 행복하다고 느낍니다.

]]>

클로드 코드, 42주 동안 사용한 팀의 워크플로우는 어떨까?

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

이번 글에서는 글로벌 알람 앱 ‘알라미’를 서비스하는 딜라이트룸이 알라미 iOS 프로젝트에서 클로드 코드(Claude Code)로 10x 생산성을 향상시킨 방법을 공유합니다.

‘Alarmy iOS 프로젝트’ 소개

매일 400만 명 이상이 사용하는 글로벌 1위 알람 앱 프로젝트입니다. SwiftUI, TCA기반이며, SPM을 이용해 모듈화 되어 있습니다. 단일 아키텍처가 아니고, TCA, MVVM, Clean Architecture를 하이브리드로 사용 중이죠. 여기에 40개 이상의 언어 지원하고 있으며, 팀에서 사용하는 디자인 툴은 피그마이고, Notion, Linear, Fireabse를 사용중입니다.

왜 클로드 코드(Claude Code)인가?

2024년 10월 22일, 처음엔 커서(Cursor)가 좋다고 떠들었던 팀 슬랙을 발견했습니다. 개발자들이 커서를 사용하기 시작하면서부터, 에이전틱 코딩의 부흥기가 시작됐죠. 그렇게 저희는 한동안 커서에 빠져 있었습니다. iOS 팀에서는 MCP, Cursorrules, Workflow 자동화, Scripting 등 AI 와 함께 개발하는 워크플로우를 도입하기 시작했습니다.

처음엔 커서를 사용했다

사실 이때까지 커서는 진화된 코파일럿이었고, 클로드 코드가 나오면서부터 에이전틱 코딩이 시작되었다고 봅니다. 단순히 자동 완성 툴이 아니라, 로컬 파일 시스템 접근 + Unix 커맨드를 조합해서 테스트 실행, 빌드, 린트, 스크립트 실행 등을 코딩 에이전트가 직접 돌릴 수 있게 됐습니다. 복잡한 작업을 하나의 워크플로우 안에서 쉽게 해결하게 됐고, 이슈 등록, 브랜치 생성, PR 생성, 내용 작성 등 반복되는 작업을 자동화할 수 있게 되었습니다. 코드베이스를 진짜로 이해하는 개발자 동료가 생긴 느낌이었죠.

최초로 클로드 코드를 사용해 iOS 리포지토리에 병합된 커밋 히스토리를 찾았습니다.

- 최초 Claude 언급: cd569c422 (PR #4617 첫 커밋, 스쿼시 전)
- 작성 시각: 2025-06-26 10:58:30 KST
- 작성자: ***** (Co-authored-by: Claude)
- 메시지: refactor: AppDelegate didFinishLaunchingWithOptions 메서드 가독성 개선
- main 병합: 같은 날 14:54 (스쿼시 커밋 1558281b7)

그럼 이제 iOS 팀에서 클로드 코드를 실제 어떻게 세팅하고 사용하는지 공유해 볼게요.

CLAUDE.md

CLAUDE.md는 팀에서 가장 중요하게 생각하고 개선하고 있는 코드입니다. 단순한 프로젝트 설명서가 아니라, 클로드 코드를 위한 팀 전체의 워크플로우를 자동화하는 진입점이죠.

CLAUDE.md는 모든 문서를 포함하지 않습니다. 대신 특정 키워드를 감지하면, 해당 워크플로우 문서를 읽도록 설계되어 있습니다. “PR 만들어줘”라고 한국어로 말해도, “pull request”라고 영어로 말해도 동일한 워크플로우가 실행됩니다.

...

pr_creation:
    patterns: [PR, 피알, 풀리퀘, 작업 완료, 올려줘 ...]
    action: READ .claude/workflows/create-pr.md
...

...
- AB 테스트 생성/정리 (실험, 베이스라인)
- PR 생성 (피알, 머지, 작업 완료)
- Firebase / TestFlight 배포
- Figma → SwiftUI 변환 (MCP 도구 호출 시 자동)
- Linear 이슈 생성 (리니어, 티켓)
...
특히 Figma MCP 도구(mcp__figma__*)를 호출하면 figma-to-swiftui 스킬이 자동 활성화되어, 하드코딩된 색상/폰트/간격 없이
   AlarmyUI 디자인 토큰으로만 코드가 생성됩니다

iOS팀에서 사용하는 CLAUDE.md 파일의 일부를 가져왔습니다. 트리거 조건들은 가장 상단에 배치했고, 자주 사용되는 워크플로우에 대한 명세를 작성했습니다. 그 다음은 가장 중요한 내용의 워크플로우를 배치했고, 각각의 워크플로우와 트리거는 매칭됩니다. 만약 팀으로 작업 중이라면, team-configuration.md을 한번 꼭 사용해 보시길 추천합니다. 가장 하단 부분에는 강조해야 하는 내용을 추가해, 클로드 코드가 중요하게 인식할 수 있도록 했습니다.

워크플로우 자동화

자동화 워크플로우의 상세 가이드라인은 .claude/workflows 폴더에 자세히 정리되어 있습니다. “core-qa 채널로 firebase 배포해 줘.”와 같이 자연어로 배포를 트리거하고, CI/CD와의 통합이 자연스럽게 작동하도록 구성했습니다. iOS 프로젝트의 CI/CD는 맥미니를 이용해, self hostred github actions 로 구성되어 있는데요. 반복으로 발생하는 브랜칭/배포 프로세스 작업들에 대해 github actions를 통해 자동화합니다.

예를 들어, release/26.11.0이 생성되면 bump-up-version/26.12.0이 생성되는 워크플로우 체인을 구성해, Human-in-the-loop (HITL)를 최소화했습니다.

클로드 코드 스킬

baseline (A/B 테스트 베이스라인 스킬, 오류 감지 및 엣지 케이스 처리)
figma-to-swiftui (팀에서 공유하는 디자인에 최적화된 스킬)
slack (API를 이용하도록 커스텀 스킬로 사용)
swiftui-tca-skill (TCA 사용을 위한 스킬)

팀에서는 자주 사용되는 스킬만 리포지토리에 커밋하고 공유하고 있습니다. 개인마다 사용하는 스킬들이 다양하고 자주 바뀌기 때문에, 항상 공유가 필요한 스킬만 추가되어 있죠. 팀원들은 codex, swift-concurrency, commit, learn, ios-design 등 50개 정도의 스킬들을 사용 중입니다. superpowers 같은 스킬도 사용 중인데요. 팀원 모두 50개 내외의 스킬들을 사용하지만, 많은 스킬을 사용하는 것은 중요하지 않았습니다. 적절한 스킬을 클로드 코드가 잘 선택하는 것이 훨씬 중요했죠. 한번 만들어진 스킬을 개선해 나가고, 스킬 체인을 구성해 프로세스 자체를 자동화하는 것이 생산성 향상에 도움이 됐습니다.

learn

자주 사용하는 /learn이라는 스킬이 있습니다. 특정 개념이나 기술에 대해 상세한 자료를 조사 한 후에 /skill-creator 플러그인을 이용해 스킬을 생성하는 체인을 구성했습니다.

/learn anything

agent-device

자동화를 위해 가장 많이 사용되는 스킬이 하나 있는데요. callstackincubator/agent-device 스킬입니다. Android와 iOS UI 자동화를 위한 CLI 툴입니다. 앱을 세션 단위로 열고 접근성 트리(Accessibility Tree)를 압축된 스냅샷 형태로 읽어, 에이전트가 현재 화면 상태를 토큰 효율적으로 파악하게 합니다. 일회성 자동화가 아니라 결정론적이고, 재현 가능한 E2E 테스트 툴로 활용할 수 있는 게 핵심입니다.

https://github.com/callstackincubator/agent-device

MCP

프로젝트 루트에 .mcp.json 파일을 사용해 팀에서 공유하고 있습니다. 스킬과 동일한 원칙으로 최소한만 사용하고 있습니다. Xcode26.4부터 공식 지원하기 시작한 MCP를 사용하면, DocumentationSearch 툴을 이용해 공식 도큐먼트 검색을 쉽게 할 수 있습니다. 검색 실패확률이 많이 줄어들죠. 현재 켜져 있는 xcode를 조작하는 방식이어서, 증분 빌드로 빠른 피드백 루프를 가질 수 있습니다. 상세한 가이드는 여기를 참고해 보세요.

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.linear.app/sse"
      ]
    },
    "xcode": {
      "command": "xcrun",
      "args": ["mcpbridge"]
    },
    "XcodeBuildMCP": {
      "command": "npx",
      "args": ["-y", "xcodebuildmcp@latest", "mcp"]
    },
     "figma": {
      "url": "https://mcp.figma.com/mcp",
      "type": "http"
    }
  }
}

최적화된 에이전트(서브 에이전트), 스킬&커맨드, MCP를 사용하고 github actions을 이용해 CI/CD를 워크플로우 기반으로 자동화했습니다. Linear, Slack을 이용한 커뮤니케이션 및 이슈관리 프로세스로, 명확한 버그 수정/이벤트 로그 추가 같은 작은 단위의 작업은 원샷으로 배포 및 QA까지 완료되도록 구성했습니다. 반복되는 작업을 자동화하고 인지 부하를 줄였죠. 대신 많아진 터미널 탭에 두뇌 토큰을 더 사용하게 됐습니다.

클로드 코드가 바꾼 iOS 개발 워크플로우

이미 모든 게 빠르게 변화하고 있습니다. 어제는 불가능했던 자동화가 오늘은 가능해졌고요. 특히 직접 복잡한 시스템을 만들어 자동화하려는 노력보다, 에이전트 모델의 발전을 기다리는 것이 더 현명한 판단이었죠. 전 iOS 개발자로서 이제 더 이상 Xcode로 직접 빌드를 돌리지 않습니다.

<오늘의 내용 요약>

알라미 iOS 팀은 클로드 코드를 메인 에이전트로 사용함
Agents/Skills/MCP는 최소한으로 팀과 공유함
반복되는 작업을 확인하면 워크플로우로 자동화함
Xcode MCP를 이용해 작업 생산성 향상시킴
스프린트에서 더 이상 개발이 병목이 되지 않음

<원문>

Claude Code를 42주 동안 사용한 팀의 워크플로우

]]>

데이터 웨어하우스의 아버지가 말하는 AI 데이터 관리법 5가지

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

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

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

써볼 것: opencodex - Codex와 Claude Code에서 아무 AI 모델이나 바꿔 끼우는 도구
참고할 것: Supabase State of Startups 2026 - 창업자 2,000명 조사로 본 요즘 스타트업의 진짜 고민
적용해볼 것: 데이터 웨어하우스의 아버지가 정리한 AI 시대 데이터 관리법 5가지

<출처: lidge-jun/opencodex, GitHub>

1. 써볼 것: Codex와 Claude Code에서 아무 AI 모델이나 바꿔 끼우는 도구

opencodex는 오픈AI의 Codex나 앤트로픽의 Claude Code에서, 원래 정해진 모델 대신 다른 AI 모델을 골라 쓸 수 있게 해주는 도구입니다. lidge-jun이라는 개발자가 만들어 GitHub에 공개했고, 스타 3,700개를 넘기며 개발자들 사이에서 주목받고 있어요. 개인 개발자가 만든 오픈소스라 공식 도구는 아니고, MIT 라이선스로 공개돼 있습니다.

원래 Codex는 오픈AI 모델로, Claude Code는 클로드 모델로 돌아갑니다. 그런데 opencodex를 끼우면 같은 Codex 화면에서 클로드나 Gemini, Grok, DeepSeek, 로컬 모델까지 골라 쓸 수 있어요. 도구는 손에 익은 걸 그대로 두고, 그 안에서 도는 모델만 바꾸는 겁니다.

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

AI 코딩 도구를 쓰다 보면 이 작업은 다른 모델이 더 잘할 텐데 싶을 때가 있습니다. 그런데 도구마다 쓸 수 있는 모델이 정해져 있어서, 모델을 바꾸려면 도구 자체를 갈아타야 했어요. Codex를 쓰다가 클로드를 쓰고 싶으면 Claude Code로 옮기고, 익숙해진 설정과 작업 흐름을 다시 맞추는 식이죠.

opencodex는 이 사이에 얇은 중개 프로그램을 하나 끼웁니다. Codex가 보내는 요청을 중간에서 받아, 사용자가 지정한 다른 모델에게 전달하고 답을 되돌려주는 방식이에요. 그래서 도구는 그대로 둔 채 모델만 바꿀 수 있습니다.

지원하는 AI는 40개가 넘습니다. 주요한 것만 추려보면 이렇습니다.

익숙한 모델: 앤트로픽 Claude, 구글 Gemini, xAI Grok, 그리고 Codex의 원래 모델인 오픈AI
중국 오픈소스 모델: DeepSeek, Kimi, Qwen, GLM
추론 서비스: OpenRouter, Groq, Fireworks, Mistral 등
내 컴퓨터나 서버에서 직접 돌리는 로컬 모델: Ollama, vLLM, LM Studio

스트리밍이나 이미지 인식 같은 기능도 모델을 바꿔도 그대로 작동합니다.

어떻게 쓰나요?

터미널에서 명령어 몇 개로 시작합니다. npm install -g @bitkyc08/opencodex로 설치하고, ocx init으로 기본 설정을 잡은 뒤, ocx start로 중개 프로그램을 켜면 됩니다. 그다음부터는 Codex를 평소처럼 쓰되, 요청이 opencodex를 거쳐 원하는 모델로 가요. (실행에는 Bun이라는 자바스크립트 실행 환경이 필요합니다.)

모델을 지정할 때는 공급자와 모델을 함께 정하는 방식입니다. 예를 들어 앤트로픽의 클로드 Opus를 고르면, Codex 화면에서 그 모델로 작업하게 돼요. 대시보드(localhost:10100)를 열면 공급자를 추가하고 API 키를 넣을 수 있고, 앤트로픽·xAI·Kimi는 로그인만으로 연결할 수도 있습니다. 다만 각 모델을 쓰려면 그 모델의 계정이나 API 키는 따로 있어야 해요. opencodex는 없던 모델을 공짜로 주는 게 아니라, 이미 가진 계정을 Codex에서 쓰게 연결해주는 도구입니다.

한 가지 눈에 띄는 기능은 작업마다 다른 모델을 지정해두는 겁니다. 복잡한 추론이 필요한 작업은 강력한 모델로, 빠르게 처리하면 되는 작업은 싸고 빠른 모델로 미리 나눠둘 수 있어요. Codex의 서브에이전트 목록에 모델을 최대 다섯 개까지 등록해두는 방식입니다.

누구에게 좋을까요?

Codex나 Claude Code를 쓰는데, 다른 모델도 같이 써보고 싶은 사람. 도구를 갈아타지 않고 모델만 바꿀 수 있어요.
여러 모델을 비교하며 쓰는 사람. 같은 작업을 클로드, Gemini, Grok에 각각 시켜보고 결과를 견줘볼 수 있습니다.
로컬 모델을 쓰는 사람. 자기 컴퓨터에서 도는 Ollama 같은 모델도 Codex에 연결할 수 있어요.
반대로 지금 쓰는 도구와 모델 조합에 만족한다면 굳이 필요하진 않습니다. 이건 여러 모델을 오가고 싶을 때 쓸모가 커지는 도구예요.

<출처: Supabase, State of Startups 2026>

2. 참고할 것: 창업자 2,000명 조사로 본 요즘 스타트업의 진짜 고민

프로덕트를 만들다 보면 다들 어떻게 일하고 있나 궁금할 때가 있죠. Supabase(수파베이스)가 창업자와 개발자 2,000명 넘게 조사한 State of Startups 2026이 그 궁금증에 참고가 됩니다. 어떤 기술을 쓰고, 어떻게 파는지, AI를 어떻게 쓰는지를 정리한 조사예요.

다만 이 조사는 Supabase가 직접 진행했고, 데이터베이스·인증·호스팅에서 Supabase 관련 선택지가 1위로 나옵니다. 인증 72%, 호스팅 65%처럼 유독 높은 걸 보면, 조사에 참여한 사람 중에 원래 Supabase를 쓰던 사람이 많았을 가능성이 커요. 그러니 특정 도구의 점유율보다 도구와 무관한 흐름을 보는 쪽으로 참고하면 되겠습니다.

무엇이 달라졌나요?

가장 큰 변화는 창업자 구성입니다. 1인 창업이 61%로 가장 많아졌고, 40세 이상 창업자가 25%로 늘었어요. 코드를 직접 짜지 않는 비기술 창업자도 22%를 차지했고요. 조사는 이걸 경험 많은 사람들이 AI를 손에 쥐고 다시 창업에 나선다고 표현했습니다.

AI로 코드를 짜는 건 이제 예외가 아니라 기본이 됐습니다. 코드베이스의 절반 이상을 AI가 작성한 곳이 62%, 76~100%를 AI로 만든 곳도 40%였어요. AI를 전혀 안 쓰는 곳은 2%뿐이었고요. 흥미로운 건 나이가 많을수록 AI를 더 많이 쓴다는 점입니다. 50대 창업자 중에서는 코드의 76~100%를 AI로 만든 비율이 60%까지 올라갔어요.

<출처: Supabase, State of Startups 2026>

어떤 도구를 쓰나요?

도구 지형도 크게 움직였습니다. 꼭 필요한 개발 도구를 자유롭게 적어달라는 질문에서는 Claude가 32%로 가장 많이 꼽혔고, Cursor 12%, ChatGPT/Codex 10%가 뒤를 이었어요. 쓰는 AI 코딩 도구를 모두 고르라는 질문에서는 Claude Code가 63%로 1위였고, Visual Studio Code 44%, Cursor 31% 순이었습니다. Cursor는 작년보다 19%포인트 떨어졌고요.

모델 공급자를 묻는 항목에서는 앤트로픽 클로드가 작년 38%에서 64%로 뛰며 오픈AI(69%에서 52%로 하락)를 처음 앞질렀습니다. 유료 구독에서도 클로드에 돈을 내는 곳이 28%에서 59%로 늘어, 오픈AI(57%에서 39%로 하락)를 넘어섰어요. 나온 지 1년 된 MCP는 프로덕션에서 쓰거나 실험 중인 곳을 합쳐 57%에 이르렀고요.

물론 이건 Supabase 조사라 클로드나 MCP 쪽에 기울었을 수 있으니 수치 그대로 받기보다 방향만 참고하면 됩니다. 그래도 오픈AI가 오래 지키던 모델 공급자 1위 자리를 클로드가 넘어섰다는 흐름은 눈여겨볼 만해요.

만들기는 쉬워졌는데, 파는 건 어렵다

이 조사에서 가장 눈에 띄는 변화가 하나 있습니다. 사업의 가장 큰 어려움으로 기술적 복잡성을 꼽은 비율이 작년 24%에서 올해 11%로 반토막 났어요. 조사 전체에서 가장 큰 변동입니다. AI가 만드는 일의 어려운 부분을 상당히 덜어준 거죠.

그럼 그 자리를 뭐가 채웠을까요. 고객 확보(32%)가 가장 큰 과제로 올라섰고, 번아웃과 AI 경쟁에 대한 불안이 새로 등장했습니다. 특히 1~10인 팀에서는 번아웃이 이미 기술적 복잡성을 넘어 두 번째로 큰 과제가 됐어요. 만드는 건 쉬워졌는데 파는 것과 버티는 게 어려워진 거죠. 조사에 인용된 한 창업자의 말이 이 분위기를 잘 보여줍니다.

“만드는 건 쉬운 부분이고, 유통이 가장 어렵다. 요즘은 경쟁이 너무 많아서 더는 독창적인 제품이 없다시피 하다”

무엇을 얻어가야 하나요?

이 조사가 프로덕트 메이커에게 주는 메시지는 분명합니다. AI 덕에 만드는 장벽은 낮아졌지만, 그래서 오히려 만든 다음이 더욱 중요해졌습니다. 누구나 만들 수 있으니 어떻게 알리고 어떻게 파느냐에서 갈리는 거죠.

조사에서 또 하나 눈에 띄는 건, 창업팀이 영업·분석·모니터링 같은 운영 도구를 점점 안 산다는 점입니다. 정식 CRM이 없는 곳이 53%로 늘었고, 관측 도구를 안 쓰는 곳도 56%였어요. 대신 필요하면 직접 만들거나 그냥 안 쓰는 쪽으로 갔습니다. AI로 웬만한 건 직접 만들 수 있게 되면서, 도구를 사는 대신 만드는 흐름이 생긴 거죠. 도구를 파는 입장이라면 곱씹어볼 대목이고, 도구를 쓰는 입장이라면 남들은 뭘 직접 만들어 쓰는지 참고할 만합니다.

<출처: William Inmon, Data Management in the Age of AI>

3. 적용해볼 것: 데이터 웨어하우스의 아버지가 정리한 AI 시대 데이터 관리법 5가지

AI에게 자료를 주고 일을 시켰는데 뭔가 애매한 느낌의 결과물을 받으신 적이 있으실 겁니다. 이는 보통 넣은 자료가 부실해서인 경우가 많습니다. 이 문제를 데이터 관리라는 오래된 분야의 눈으로 짚은 글이 있어서 소개합니다.

글을 쓴 William Inmon(윌리엄 인먼)은 데이터 웨어하우스라는 개념을 만든 사람으로, 데이터 업계에서 데이터 웨어하우스의 아버지로 불립니다. 이 글은 40년 넘게 기업 데이터를 다뤄온 사람이 생성형 AI 시대에 데이터 관리가 어떻게 달라지는지 정리한 내용이죠. (참고로 인먼은 LLM에 넣을 텍스트를 정제해주는 회사를 운영하고 있어서, 데이터를 걸러야 한다는 주장이 본인 사업과 맞닿아 있다는 점은 감안하고 보면 됩니다.)

요즘 많은 사람이 회사 문서로 챗봇을 만들거나, GPTs에 자료를 올리거나, AI에 사내 자료를 물려 씁니다. 그리고 나온 결과가 신통찮으면 대개 모델부터 바꾸려고 하죠. 인먼은 그전에 넣은 자료부터 보라고 말합니다. 이 글은 기업의 데이터 담당자를 위해 쓰였지만, 핵심 원칙은 AI에 자료를 넣어 쓰는 누구에게나 적용될만한 것들입니다. 전문 용어를 빼고 실제 적용할 수 있는 원칙 다섯 가지로 정리했습니다.

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

인먼의 출발점은 간단합니다. AI가 믿을 수 없는 데이터로 돌아가면, AI가 내놓는 분석도 믿을 수 없다는 거예요. 예전에는 데이터 담당자가 데이터베이스를 직접 열어 고쳤지만, AI 시대에는 AI 자체를 그렇게 뜯어고칠 수 없습니다. 대신 AI에 무엇을 넣을지를 관리해서 결과를 다스려야 하죠. 그래서 넣는 자료를 어떻게 다루느냐가 핵심이 됩니다.

적용해볼 원칙 다섯 가지

좋은 자료를 넣어야 좋은 답이 나옵니다. 아무리 뛰어난 모델도 부실한 자료를 주면 부실한 답을 내놓습니다. 새 모델을 찾기 전에, 지금 AI에 주는 자료부터 살펴보는 게 먼저입니다.
넣기 전에 거릅니다. 업무와 상관없는 자료를 미리 걷어내면 두 가지가 좋아집니다. AI가 처리할 양이 줄어 비용이 내려가고, AI가 무엇을 다루는지도 분명해져요. 회사 문서 100개를 통째로 넣기보다 지금 물어볼 것과 관련된 20개만 골라 넣으면, 답이 더 정확하고 비용도 줄어듭니다. 인먼은 데이터 담당자가 다른 건 몰라도 이것 하나는 꼭 해야 한다고 강조했습니다.
표와 글은 다루는 법이 다릅니다.숫자와 표로 된 자료는 정해진 틀로 관리하지만, 회의록이나 문서 같은 글은 주제별로 묶어 정리하는 게 맞습니다. 표 다루던 방식을 글에 그대로 쓰면 별 효과가 없다는 게 인먼의 지적입니다. 표는 표대로, 문서는 주제별로 정리해두면 AI가 훨씬 잘 찾는다고 하죠.
이제 데이터는 고치는 게 아니라 고르는 겁니다. 예전엔 문제가 있으면 데이터베이스를 직접 수정했지만, LLM은 그렇게 고칠 수 없습니다. 대신 무엇을 넣을지 골라서 결과를 조절하죠. 인먼은 이걸 꼭두각시 인형에 비유했습니다. 직접 손대는 대신 줄을 당겨 움직이는 거죠.
한 번 정리하고 끝이 아닙니다. 업무도 세상도 계속 바뀌니, 무엇을 넣을지 정하는 기준도 그때그때 갱신해야 해요. 지금 잘 맞춰둔 자료도 반년 뒤엔 낡을 수 있습니다.

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

지금 AI에 자주 시키는 작업을 하나 골라서, 거기 넣는 자료에 업무와 상관없는 게 섞여 있는지 살펴보세요. 빼는 것만으로 답이 또렷해지는 경우가 많습니다.
회사 자료를 AI에 넣어 쓴다면, 표로 된 것과 글로 된 것을 나눠서 정리해보세요. 섞어둘 때보다 AI가 필요한 자료를 더 잘 찾아냅니다.
한번 정리한 자료라도 몇 달에 한 번은 다시 보고, 낡았거나 안 맞는 걸 걷어내세요.

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

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

AI 도구 26개를 직접 만들며 알게 된 자동화 노하우

지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이번 글은 클코나잇 시즌 2의 'AI 도구 26개를 직접 만들며 알게 된 자동화 노하우'를 정리한 것입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. '게임업계 제너럴리스트의 AX 도전기'를 주제로 발표를 맡은 김현민입니다. 저는 지난 3개월간 여러 AI 도구를 만들면서 알게 된, 비개발자로서의 자동화 꿀팁들을 몇 가지 말씀드리겠습니다.

우선 제 소개부터 간략히 드리면, 저는 2021년에 팀스파르타에 조인해 여러 신사업을 담당했고, 지금은 산하 게임 스튜디오인 스파르타 게임즈에서 마케팅, 사업, 피플, 제작 지원까지 중앙 운영을 전체적으로 담당하고 있습니다. 제가 제너럴리스트인 것도 있고, 게임업계라서 AX에 더 일찍 눈을 뜨게 된 것도 있는데요. 예를 들어 저희는 1년에 제작하는 게임이 대략 30개 정도 됩니다. 여러 파트를 담당하고 있기도 하고 템포가 빠른 게임업계이다 보니, AX를 더 열심히, 빠르게 하게 된 것 같습니다.

오늘 발표를 한 줄로 요약하면 이겁니다. 결국 AI는 도구이고, 문제 정의 역량이 중요하다. 제가 지난 3개월간 깨달은 것이기도 한데요. 발표가 끝날 즈음에는 이게 무슨 의미였는지 다 이해하실 수 있을 거라 생각합니다.

스테이크엔 스테이크 나이프, 과일엔 과도: 적합한 도구부터

조금 터프한 이야기일 수도 있지만, 적합한 도구를 선택해야 한다는 이야기를 가장 먼저 드리고 싶어요. 스테이크를 자를 때는 과도를 쓰지 않고, 과일을 자를 때는 과도를 쓰는 것과 유사한 이치인데요. 사실 앱스크립트(Apps Script)나 n8n으로도 충분한 자동화가 많이 있습니다. 저도 앱스크립트부터 시작해서 젠스파크, 마누스, n8n을 거쳐 클로드 코드를 사용하고 있는데요. 실무에 빠르게 적용하는 것이 목표라면, 문제 정의부터 올바르게 시작하고 그걸 토대로 적합한 도구를 선택하시길 추천드립니다.

저는 이 과정에서 작업 능률을 더 올리고 싶을 때 비로소 클로드 코드가 필요하다고 느꼈습니다. 예를 들어, n8n으로 자동화할 것들이 되게 많고 저도 많이 해왔지만, 프로젝트가 늘어나기 시작할 때 처음으로 한계를 느꼈어요. 여러 게임을 만들다 보니 프로젝트도 그만큼 늘어날 수밖에 없는데, 동일한 환경 변수를 게임마다 세팅해 줘야 할 때 가장 귀찮고 시간이 많이 들더라고요. 복잡도가 증가하면 그만큼 자율성에 대한 갈증이 생기고, 이는 실제 작업 능률과 연관됩니다.

다만 여러 툴을 써본 경험으로 보자면, 언젠가는 반드시 클로드 코드로 넘어가실 수밖에 없을 것 같긴 해요. 그래도 목적과 상황에 따라 적절히 고민해 보시면 좋겠고, 클로드 코드로 이동하실 때도 '기존에 잘 돌아가고 있는 것을 꼭 클로드 코드로 다시 만들어야 할까'라는 고민도 한 번씩 해보시면 좋겠습니다.

팀에 전파하며 특히 의미 있었던 두 가지

그럼에도 클로드 코드를 쓰는 이점은 어떤 것이 있는지, 이어서 말씀드리겠습니다. 제가 여러 직무를 담당하다 보니 마케팅, 사업, 피플 쪽에서 여러 도구를 만들었는데요. 이 도구들은 '각 직무에서 이런 것들도 만들 수 있구나' 하는 아이디에이션의 예시로 봐주시면 가장 좋을 것 같습니다. 하나씩 다 이야기하지는 않고, 팀에 전파하는 관점에서 특히 의미가 있었던 것 두 가지만 꼽아보겠습니다.

첫 번째는 '로켓 브리프'라는 서비스입니다. 업계와 무관하게 대부분 루틴하게 동종업계나 시장 트렌드를 서치하는 경우가 많으실 텐데요. 저희도 마찬가지로 게임업계 뉴스, 크리에이티브 소재 트렌드, 실제 바이럴되고 있는 영상 트렌드를 여러 채널에서 매일 일정 시간을 들여 보다 보니, 시간이 많이 소요될뿐더러 '자동화해 볼 수 없을까'라는 생각에서 시작하게 됐습니다.

이 서비스는 여러 뉴스와 트렌드를 서치·분석하고, 매일 오전 9시에 팀 슬랙으로 발송하는 기능까지 포함돼 있습니다. 신규 출시 예정인 게임들도 포함되고요. 저뿐만 아니라 팀원분들이 사용하실 수 있게 배포해 두어서, 월 기준으로 많은 시간이 절감되고 있다고 판단하고 있습니다.

콘텐츠 업로드 자동화 알림

게임별 CVR 벤치마크 대비 & 증감 추이 알림

두 번째는 제작한 것들의 결과를 슬랙 알림으로 발송해 팀의 루틴으로 추가한 것입니다. 결국 팀원분들이 모두 사용하려면 서비스로 배포하든, 스킬을 만들어 배포하든, 누구나 볼 수 있게 알림을 발송하든 해야 합니다. 슬랙에서 알림으로 발송하는 대표적인 예시 두 가지를 가져왔습니다. 크리에이티브 캠페인 집행을 위해 각 매체에 업로드되는 프로세스를 자동화한 것, 그리고 여러 지표 중 CVR(전환율)의 증감 추이 알림을 발송하는 것입니다.

이 두 가지를 말씀드린 이유는, 개인의 AX도 좋지만 회사에서 하시는 분들이라면 팀의 AX에도 도움이 되는 방향으로 잡아보시면 좋겠다는 생각 때문입니다. 특히 팀 AX 관점에서는, 팀원들이 여러 툴을 새로 학습하지 않도록 팀에 이미 녹아 있는 프로그램을 최대한 활용해 보시면 좋겠습니다.

기획이 8할이다: 문제 정의, PRD, 클로드 MD

여러 가지를 만들면서 임팩트가 컸던 것과 어려웠던 것들도 정리해 봤는데요. 임팩트는 당연하게도 월간 절감 시간 기준입니다.

절감 시간은 기존에 소요되던 시간에서 개선 버전의 소요 시간을 뺀 값에, 사용 주기와 실제 사용자 수를 곱해 산정했습니다. 앞서 말씀드렸던 로켓브리프는 월 15시간을 절감할 수 있었던 것으로 나타났습니다. 그밖에 에어브릿지 데이터를 분석해서 슬랙으로 자동발송해주는 시스템을 만들었던 것은 월 45시간 절감했습니다.

반대로 주요 시행착오들은 주로 기획과 관련된 것들이었습니다. 저도 PM이어서 그런지, 기획이 8할이라는 이야기를 드리고 싶은데요. 시행착오를 겪고 나서는 이 세 가지 스텝을 꼭 기획 단계에서 챙기고 있습니다.

문제 정의: 내가 지금 어떤 문제를 겪고 있고, 어떤 솔루션이 필요한가에 대한 페인 포인트를 한 줄 정도로 정리합니다.
PRD(제품 요구사항 문서): 문제 정의를 토대로 제품 요구사항 문서를 만듭니다.
클로드 MD(CLAUDE.md): PRD가 제작되었다면, 이를 토대로 CLAUDE.md를 제작해 달라고 하면 됩니다.

사실 이 문서들도 클로드 코드가 다 잘 만들어줍니다. 다만 시간과 시행착오를 줄이는 관점에서 먼저 사고해 보시면 좋다는 이야기고요. 한 가지 다른 팁을 드리자면, CLAUDE.md는 최종적으로 영어로 작성하시는 것을 추천합니다. 여러 아티클에서 나왔듯 한국어는 영어 대비 토큰을 3~5배 정도 더 쓴다는 리서치가 있는데요. 작업할 때마다 자주 참조하는 CLAUDE.md는 특히 영어로 작성하면 토큰 절감에 조금이나마 도움이 될 겁니다.

그리고 이 세 가지를 아무리 신경 썼다 한들, 메이커분들은 잘 아시겠지만 기획은 늘 바뀝니다. 기획은 바뀔 수밖에 없지만, 결국 코어 로직, 즉 판단 기준 이 흔들리지 않도록 최소한의 기능으로 만드는 것을 추천드리고, 이게 바로 MVP로 이어집니다.

비개발자 사내 자동화의 세 가지 체크포인트: 접근성, 확장성, 보안

다음으로 비개발자분들이 사내 자동화를 하실 때 챙겨야 할 세 가지를 말씀드려보겠습니다. 접근성, 확장성, 보안입니다.

접근성

접근성은 MVP와 연결되는 맥락인데, 자주 바뀌는 만큼 수정도 용이해야 합니다. CRUD의 관점이기도 한데, 자주 바뀌고 자주 접근하는 만큼 꼭 멋들어진 데이터베이스일 필요는 없는 것 같아요. 예를 들어, 저도 왕왕 스프레드시트 기반으로 처리하고 있는데, 제가 수정하거나 나중에 인수인계할 때, 혹은 제가 자리를 비웠을 때 팀원분들이 접근하기도 되게 용이합니다. MCP로 연동하면 즉시 반영도 되기 때문에, 데이터베이스로는 스프레드시트를 추천드립니다.

확장성

아무리 MVP라고 해도, 점차적으로 기능을 늘려나가야 할 텐데요. 제작해야 할 기능이 1부터 10까지라고 했을 때, 핵심 기능이 3번까지라면 MVP는 3번까지만 만들고 검증한 다음 4, 5, 6번으로 나아가는 건데요. 그렇다고 4번부터 10번을 아예 배제해도 된다는 건 아닙니다. 3번까지만 만들더라도 뒤가 앞으로 어떻게 굴러갈지에 대한 염두가 이미 되어 있어야, 나중에 검증되었을 때 갈아엎는 불상사가 생기지 않습니다.

보안

사내 프로젝트는 대부분 대외비이기 때문에 신경 써주시면 좋습니다. 클로드 코드에 내장된 시큐리티 리뷰(security review) 스킬이 있기도 하고, 꼭 배포해야 하는 상황이라면 기본적인 OAuth는 꼭 챙겨주시면 좋겠습니다.

보안과 관련해서는 프롬프트를 하나 준비했습니다.

# 아래 코드를 배포 전 보안 리뷰해줘.

[코드 붙여넣기]
스택: [프레임워크] + [배포 환경] + [DB/Auth 스택]

# 15개 항목을 현재 코드 기준으로 진단
01. CORS
02. CSRF
03. XSS + CSP
04. SSRF
05. AuthN/AuthZ
06. RBAC · 테넌트
07. 최소권한
08. Input + SQLi
09. Rate Limit
10. 쿠키 · 세션
11. Secret . Rotation
12. HTTPS · 보안헤더
13. Audit Log
14. 에러 노출
15. 의존성 취약점

# 출력 형식
| 항목 | 상태 | 위험도 | 수정 방향 |
상태: ☑ 구현 / A 부분 / × 없음 / - 해당없음
위험도: High / Med / Low

저는 이 프롬프트를 꼭 돌려서 우선순위 '중' 이상은 반드시 반영하고 있습니다. 물론 제가 이 모든 항목을 알고 있는 건 당연히 아닙니다. 다만 배포했을 때 개발자 도구를 켜면 콘솔에 이슈들이 쭉 나오는데, 콘솔 이슈가 최소한으로 안 보이게끔 하는 걸 목표로 하고 있고, 최소한의 OAuth를 붙이고 있습니다.

그럼에도 외부인에게 배포되어야 하는 서비스라면 저도 사내 개발자분들께 도움을 구합니다. 비개발자 관점에서는 엄청난 대형 서비스가 아닌 이상, 이 정도까지만 우선 챙기셔도 충분하지 않을까 싶습니다.

모방에서 커스텀으로

이렇게 제작 과정에서 많이 챙기셨어도, 어떻게 하면 더 잘 쓸 수 있을까에 대한 이야기인데요. 결론적으로는 모방에서 커스텀으로 차차 넘어가시는 것을 가장 추천합니다.

클로드 코드를 쓰는데 '내가 어디서부터 시작해야 하지?'라는 고민이 되게 많으실 것 같아요. 그럴 때는 외부의 훌륭하신 분들이 이미 제작해 두신 플러그인이 엄청 많습니다. 그런 것들을 먼저 써보고 구조를 어느 정도 이해해 본 다음, 내 상황에 맞춰 커스텀하는 게 학습 시간을 최소화하면서 잘 쓰는 방법이라고 생각합니다.

저도 시작할 때는 링크드인이나 스레드에 훌륭하신 분들이 남겨주신 것들을 먼저 써보면서 제 케이스에 적용해 봤습니다. AI 관련 포스팅을 몇 번 보다 보면 알고리즘에 의해 계속 보실 수밖에 없을 거예요. 그런 것들을 스크랩해 두시고, 나중에 선별적으로 사용해 보시길 추천드립니다.

팀 AX가 빠르려면, 리더가 먼저 만들어야 한다

마지막은 리더분들을 위해 준비한 이야기입니다. 팀 AX도 동일한 것 같아요. 반복되는 업무나 AX로 개선하고 싶은 문제 정의부터 시작하게 되고, 그다음 반복 시스템으로 확장되는데요. 팀 AX는 특히 초반 과정에서부터 시니어분들의 암묵지가 필요하다고 생각합니다.

결론은, 팀 AX가 빠르게 되려면 리더분들이 먼저 제작해 주시는 편이 가장 좋습니다. 웬만한 팀원분들은 당장 실무를 쳐내기에도 버겁고, 경험과 역량이 상대적으로 부족하다 보니 문제 정의 단계에서부터 어려움을 겪는 경우가 꽤 많아요. 그래서 문제 정의는 같이 해보되, 어느 정도의 스코프에서는 리더분들이 먼저 제작하시고, 배포해서 팀원분들이 사용하게끔 하는 과정이 더 효율적이라고 생각합니다.

이건 앞서 말씀드린 모방에서 커스텀으로 넘어가는 영역과 일맥상통합니다. 리더 분들이 먼저 사용해 보면서 관심을 가지면, 팀원분들이 그다음부터는 착착 이것저것 제작하시더라고요. 적어도 SNS에서 내가 본 포스팅을 공유해 주시는 것만으로도 충분하다고 생각합니다.

직무 무관, 문제 정의 역량이 가장 중요하다

제가 3개월간 삽질하면서 얻은 결론은 이렇습니다. 직무와 무관하게 문제 정의 역량이 가장 중요하다. 그리고 직무 전문성이 있는 사람이 AI를 잘 쓰는데, 이건 당연히 클로드 코드도 마찬가지다. 여러분들도 모방하고 커스텀하면서, 개인과 팀의 AX에 성공하시길 진심으로 바랍니다.

마지막으로, '해커톤 6시간 MVP 스킬'이라는 걸 만들어 뒀는데요. 기획 과정의 중요성을 느끼고, 기획 직무가 아니신 분들도 문제 정의, PRD, CLAUDE.md를 손쉽게 쓰실 수 있게끔 만든 스킬입니다. 이걸 통해 기획 과정에서의 시행착오를 줄이실 수 있으면 좋겠습니다. 이상으로 발표 마치겠습니다. 감사합니다. (참고: 김현민 AI 대시보드)

▶발표 영상 유튜브에서 보기

]]>

언러닝: 이제 그만 좀 배우고, 버리세요

요즘 뭔가를 배우는 방식이 예전과는 꽤 달라졌다는 걸 느낍니다. 새로운 기술과 도구가 쉴 새 없이 쏟아지다 보니, 다들 이것저것 빠르게 찍먹하듯 익히고 넘어가는 듯 하죠. AI까지 더해지면서, 일단 써보고 익히는 게 어느 때보다 쉬워졌고요. 그 어느 때보다 많은 걸 빠르게 주워 담고 있는 셈입니다.

그런데 이상한 일이 있습니다. 그렇게 쉴 새 없이 배우는데도, 사람들의 불안은 줄기는커녕 더 커지고 있는 모습입니다. 저만해도 ‘이 정도면 잘 따라가고 있는 것 같은데, 왜 자꾸 뒤처지는 느낌이지?’라는 생각이 듭니다.

저는 그게 덜 배워서 생기는 불안은 아니라고 봅니다. 오히려 열심히 주워 담은 것들이 너무 빨리 낡아버리는 탓이 크죠. 그러니 더 부지런히 채워봐도, 불안이 좀처럼 가시질 않는 거예요. 그래서 이제는 얼마나 더 채우느냐보다, 무엇을 덜어내느냐가 더 큰 질문이 됐습니다. 오늘은 바로 그 지점, AI 시대에 버리는 법, 언러닝(unlearning)이 점점 더 중요해지는지 이야기해보려고 합니다.

<출처: 작가, 클로드 생성>

더 공부하는데, 더 불안한 사람들

배운 내용들이 이전보다 빠르게 낡는다는 건 숫자로도 드러나는데요. 직업 스킬에는 ‘반감기’라는 게 있거든요. 이는 가지고 있는 역량의 시장 가치가 절반으로 떨어지는 데 걸리는 시간을 말합니다. 원래 방사성 물질이 절반으로 붕괴하는 시간을 가리키던 표현인데, 이걸 사람의 역량에 빌려 쓴 거죠.

이 반감기가 2010년만 해도 10~15년쯤 됐습니다. 이전에는 한 번 잘 배워두면 십 년 넘게 우려먹을 수 있었다는 뜻입니다. 그런데 2025년 기준으로는 기술 스킬의 반감기가 5년 미만으로 짧아진 것으로 전망됩니다(IBM·WEF 추정 정리). 특히 AI 같은 디지털 분야는 2년 안팎까지 떨어진다는 추정도 있고요.

이전보다 더 많이 배워도 계속 불안한 건 우리가 느려서가 아니라는 말입니다. 우리가 쌓는 속도보다 상하는 속도가 빨라진 거죠. 그렇다면 결론이 좀 이상해집니다. 더 부지런히 배우는 것만으로는 이 불안이 풀리지 않는다는 뜻이 되니까요.

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

우리는 평생 쌓는 법만 배웠다

그럼 우리는 그동안 뭘 배운 걸까요. 학교, 시험, 입시, 스펙, 자격증. 가만 보면 이전까지는 더 많이 담는 사람이 유리한 구조였습니다. 이곳저곳에서 머릿속 창고를 누가 더 빽빽하게 채웠는지로 줄을 세웠죠. 그래서 우리 몸에 밴 공부의 기본기는 쌓기입니다. 비우는 칸은 애초에 배운 적이 없죠.

이게 틀린 전략이었던 건 아닙니다. 지식이 수십 년씩 버티던 시절엔, 많이 배워둔 사람이 곧 유능한 사람이었으니까요.

문제는 앞서 본 것처럼, 애써 배운 것들이 점점 더 빨리 낡는다는 데 있죠. 배우는 속도는 그대로인데 낡는 속도가 빨라지니, 어느 순간부터는 배우면 배울수록 이미 낡아버린 것들이 늘어나는 셈입니다. 분명 열심히 배웠는데, 손에 남는 건 자꾸 뒤처진다는 감각뿐이고요. 그래서 요즘의 불안은 충돌의 신호입니다. 세상은 바뀌었는데 우리는 여전히 쌓으면 이긴다는 낡은 방식을 그대로 고집하고 있으니, 머릿속이 자꾸 삐걱댈 수밖에요.

판이 바뀌었다면 우리도 패를 바꿔야합니다

여기서 잠깐 가위바위보를 떠올려 보면 좋겠습니다. 상황을 좀 더 이해하려고 드는 예시이니 가볍게 따라와 주세요. 가위는 보자기를 이깁니다. 천을 싹둑 자르니까요. 이건 누구나 아는 규칙입니다. 그리고 우리는 가위를 아주 잘 낼 수 있는 사람이죠.

그런데 어느 날, 보자기의 재질이 천에서 탄소섬유로 바뀐다면 어떨까요? 이제 아무리 날카로운 가위를 내도 그 보자기는 잘리지 않습니다. 가위가 약해진 게 아니라, 상대의 재질이 바뀐 거죠.

이는 요즘 우리가 느끼는 막막함의 원인입니다. 보자기가 탄소섬유로 바뀌었는데 우리는 자꾸 가위를 손보고 있죠. 날마다 가위를 더 날카롭게 갈고 또 갈아, 가위를 강화시키려고 합니다. 그게 우리가 아는 유일한 해법이니까요. 하지만 재질이 바뀐 보자기 앞에서, 날카로운 가위는 더 애처로운 헛수고일 뿐입니다.

<출처: 작가, 클로드 생성>

이제는 의심을 한번 해볼만 하죠. 우리가 교과서에서, 강의에서, 성공담에서 주워 담는 가르침의 상당수는 이미 천 시절의 가위질 요령일지도 모른다고요. 그러니 지금 필요한 건 가위를 더 잘 가는 일이 아닙니다. 게임의 규칙이 바뀌었다는 걸 먼저 알아채는 일, 그리고 내가 쥔 패 자체를 바꾸는 일이죠. 그런데 패를 바꾸려면 손에 꽉 쥔 가위부터 일단 내려놓을 줄 알아야 합니다. 바로 이 내려놓는 능력을 우리는 한 번도 배운 적이 없습니다.

아무도 가르쳐주지 않은, 언러닝

흔히 학습이라고 하면 새 걸 머리에 넣는 한 방향만 떠올립니다. 그런데 사실 그 옆에는 낡은 걸 덜어내는 반대 방향이 나란히 있어야 하죠. 들이는 칸과 비우는 칸이 한 쌍인 거예요. 생각해보면 우리는 배우는 법을 정말 오래 훈련받았습니다. 초등학교부터 대학까지, 길게는 16년이 넘죠. 그런데 그 긴 시간 동안 낡은 걸 버리는 법을 가르쳐준 수업은 없었습니다. 노트 필기하는 법은 배웠어도, 노트를 버리는 법은 아무도 안 가르쳐줬죠.

그렇습니다. 이제 우리가 배워야할 것은 언러닝(unlearning)입니다.

언러닝, 요즘 나온 말 같지만 사실 무려 50여 년 전에 나온 통찰입니다. 미래학자 앨빈 토플러(Alvin Toffler)는 1970년 저서 『미래쇼크(Future Shock)』 18장에서 이런 말을 했습니다.

“By instructing students how to learn, unlearn and relearn, a powerful new dimension can be added to education.”
학생들에게 배우고 버리고 다시 배우는 법, 런·언런·리런을 가르치면 교육에 강력한 새 차원을 더할 수 있다.

토플러가 반세기 전에 남긴 이 말이 요즘 다시 회자되는 데는 이유가 있습니다. 스킬 반감기가 급격하게 짧아지면서, 언러닝은 지금 당장의 문제가 됐기 때문입니다.

<출처: 작가, 클로드 생성>

버리는 법: 언러닝 → 리러닝 → 뉴러닝

그럼 버린다는 게 구체적으로 뭘 하라는 걸까요. 막연히 “비워라” 하면 감이 잘 안오니까 세 칸으로 쪼개보겠습니다. 언러닝, 리러닝, 뉴러닝. 버리고, 다시 보고, 새로 엮는 순서입니다.

첫 단계는 언러닝, 낡은 걸 버리는 겁니다. 여기서 버린다는 건 아는 걸 지우는 것과는 좀 다릅니다. '원래 이런 거야' 하고 당연하게 여기던 생각의 틀에서 한 발 빠져나오는 거죠. 사실 이게 제일 어렵습니다. 틀린 지식이야 틀렸다고 인정하면 그만인데, 당연해 보이는 전제는 의심할 생각조차 들지 않죠. 이를테면 '많이 아는 사람이 유능하다'는 오래된 믿음, 그 당연하던 전제부터 손에서 놓아보는 거예요.

두 번째는 리러닝, 본질을 다시 보는 겁니다. 틀에서 한 발 빠져나와 빈자리가 생기면, 그제야 대상을 새로 정의할 수 있어요. '유능함'을 다시 본다면? '얼마나 아느냐'가 아니라 '무엇을 골라내고 어떻게 엮느냐'로요. 같은 단어여도 의미가 달라지죠. 통념을 내려놓아야 이렇게 새 정의가 들어설 틈이 생길 수 있습니다.

세 번째는 뉴러닝, 새로 만들어내는 겁니다. 다시 본 정의를 이 시대가 준 도구 위에서 실제 결과로 옮기는 거예요. 아는 것이야 이제 AI가 얼마든지 채워주니, 나는 거기에 내 판단과 안목을 실으면 되죠. 그러면 예전 같으면 엄두도 못 냈을 일을 만들어낼 수 있고요. 결국 핵심은 도구가 아니라, 거기에 무엇을 실을지 아는 사람입니다.

<출처: 작가, 클로드 생성>

'무엇을 실을지 아는 사람'이란 건, 결국 판단과 취향, 맥락으로 이어집니다. 일의 미래를 짚는 많은 글들이, 입을 모아 지식이 흔해질수록 오히려 취향의 값이 오른다고 말합니다.GitHub도 공식 블로그에서 이런 말을 남겼죠 "병목은 결국 판단이고, 그래도 괜찮다. (…) 당신이 지고 다니는 맥락이야말로 리뷰를 가치 있게 만드는 것이고, 그건 자동화되지 않는 부분이다"

이런 것들이 사람 몫으로 남는 이유는, AI가 아직 서툴러서가 아닙니다. AI가 더 똑똑해져도 마찬가지일 거라 생각합니다. AI는 '가장 그럴듯한 답'을 내놓는 데는 뛰어나지만, 그중 무엇이 좋은지, 무엇이 지금 우리에게 중요한지는 정답이 없는 물음이기 때문이죠. 그건 능력이 아니라 '무엇을 원하는가'를 정하는 일이라, 애초에 남에게 맡길 수도 없죠.

그렇기 때문에 버린다고 끝이 아닙니다. 버리고, 다시 보고, 새로 만드는 데까지가 한 묶음이죠. 그 끝에 손에 쥐는 건 더 많은 지식이 아니라, 무엇을 고르고 무엇을 버릴지 아는 눈입니다.

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

오늘 당장 버릴 한 가지

여기까지 왔다면 처음의 그 불안이 조금 다르게 보일지도 모르겠습니다. 결국 더 쌓는다고 풀릴 일이 아니라면, 오늘 더 쌓지 못한 나를 채찍질할 필요는 없어졌으니까요. 대신 비우고, 다시 채워야 합니다.

그런데 이 결론이 또 하나의 거창한 결심으로 번지면 곤란합니다. “이제부터 다 갈아엎겠다”는 다짐만큼 작심삼일에 어울리는 것도 없으니까요.

그러니 오늘은 딱 하나만 비워보면 어떨까요. 머릿속 어딘가, 한때는 분명히 옳았지만 지금도 정말 맞는지 슬쩍 의심스러운 통념이 하나쯤 있을 겁니다. “이 일은 원래 이렇게 하는 거야”라고 당연히 받아들이던 것이요. 책상에 쌓인 메모 중에 ‘이건 작년 얘기였지’ 싶은 한 장을 쓱 빼보세요. 언러닝의 첫 칸은 그만큼 작아도 된다고 생각합니다.

당장은 그 한 장을 뺀 자리가 어디로 이어질지 안 보일 수 있습니다. 그래도 괜찮습니다. 스티브 잡스(Steve Jobs)는 2005년 스탠퍼드 졸업식 연설에서 이런 말을 남겼습니다. “앞을 보며 점을 이을 수는 없다. 점은 뒤돌아볼 때만 이어진다.” 오늘 비운 한 칸이 어떤 그림이 될지는, 한참 지나 돌아볼 때라야 보일 겁니다.

버리는 기술은 한 번의 결심이 아니라, 천천히 몸에 드는 습관입니다.
여러분은 오늘, 어떤 통념 하나를 비워보시겠어요?

]]>

AI가 다 만드는데, 왜 자꾸 기획을 말할까?

AI 코딩 시대, 가짜 속도에 현혹되지 않고 기획의 주도권을 지키는 법

며칠 전 한 후배에게서 메시지가 왔습니다. “선배님, 주말에 AI로 앱 하나 만들었는데 가능성이 있을지 한번 봐주세요.” 반나절 만에 만든 앱이라더군요. 물론 반나절 만에 만들었으니 오류도 있고, 모든 기능이 깔끔하게 돌아가지는 않았지만, 후배가 어떤 서비스를 만들고자 했는지는 충분히 알 수 있었습니다. 불과 2~3년 전엔 기획서를 쓰고 디자인 시안을 잡고, 개발자 통해 만들기까지 최소 몇 주, 길게는 몇 달이 걸렸을 일입니다. 그게 토요일 오후 한나절로 줄었죠.

요즘은 AI와 몇 시간 대화하면 그럴싸한 서비스 하나가 뚝딱 나옵니다. 아이디어를 실제 화면으로 옮기는 데 드는 시간과 돈이 거의 공짜에 가까워진 셈입니다. 이렇게 만드는 비용이 확 낮아지자, 시장의 룰도 함께 바뀌고 있습니다. 꼼꼼한 사전 기획보다는 얼마나 빨리 만들어 시장에 던지고 피드백을 받느냐는 ‘속도’가 비즈니스의 생존을 결정하게 됐죠. 책 'AI 시대의 설계자들'의 내용을 빌리면, AI시대의 ‘속도의 경제학’이 시작된 것입니다.

속도의 경제학은 대량 생산을 통해 비용을 낮추는 '규모의 경제'를 넘어, 시장 변화를 빠르게 읽고 실행하여 경쟁 우위를 확보하는 전략을 뜻합니다. 여기서 비용을 낮추는 역할은 AI가 확실하게 해주고 있는 셈입니다. 숫자로 보면 더 와닿습니다. Enlight Lab에 따르면, 작은 서비스의 MVP(프로토타입) 개발 비용이 5만 달러에서 5천 달러 수준으로 내려왔고, 앤트로픽(Anthropic)이 정리한 자료를 봐도, 기획부터 배포까지 몇 주가 걸리던 개발 사이클이 이제 몇 시간 단위로 줄어들고 있다고 합니다.

그렇다면 만드는 비용이 거의 공짜가 된 지금, 우리는 무엇을 고민해야 할까요? 단순한 속도 경쟁을 넘어, 진짜 쓸모 있는 가치를 만드는 방법을 살펴보고자 합니다.

왜 우리는 만들기 전부터 기획 회의에 진을 뺐을까?

AI가 나오기 전에는 새로운 아이디어를 한번 실험해 보고 싶어도, 동작하는 프로토타입을 구경하는 것 자체가 일이었습니다. 기획서를 다듬고, 디자인 시안 피드백을 주고받고, 개발 스프린트에 일정을 태워 실제로 굴러가는 화면을 보기까지는 적게는 몇 주에서 길게는 몇 달의 시간이 훌쩍 지나갔죠. 사실 담당자들 입장에서는 만들어보고 버려질 수도 있는 프로젝트에 선뜻 힘을 쏟기가 어려운 심리적 저항도 컸습니다. 결국 이렇게 여러 단계를 거쳐, 어렵사리 만든 MVP를 시장에 냈다가 반응이 없으면, 그동안 쏟아부은 여러 부서의 시간과 노력이 통째로 매몰 비용이 되어 사라지곤 했죠.

그래서 사람들은 만들기 전에 판단하는 일에 에너지를 쏟았습니다. 시장 조사를 하고, 경쟁사를 분석하고, 내부 검토를 거치고, PPT를 만들어 회의실에서 갑론을박을 벌이고, 임원 보고를 통해 의사결정을 받았습니다. 이 과정에서 멀쩡한 아이디어가 만들어지기도 전에 회의실에서 사장되는 일이 흔했죠. 비합리적이어서가 아닙니다. 그냥 만들어보는 비용이 더 비쌌으니까, 미리 따져보는 게 그 이전엔 더 합리적이었던 겁니다.

그런데 여기서 또 간과하는 맹점이 있습니다. 바로 만들기 전에 검토하는 시간 역시 공짜가 아니라는 사실입니다. 아이디어를 검증하겠다며 시장 조사를 하고, 기획서를 만들고, 수정하고를 반복하는 동안, 수많은 실무자와 의사결정권자의 인건비와 시간이 소리 없이 녹아내립니다. 결국 진짜 제품은 시작도 하지 않은 상태에서, 이미 엄청난 기획 리소스가 매몰되고 마는 셈입니다.

시도하는 비용이 너무 비싸다 보니 시도 대신 사전 판단에 매달릴 수밖에 없었고, 결과적으로는 만들어보지도 못한 채 기획 단계에서 이미 에너지가 소진되는 모순에 갇혀 있었죠. 실패를 피하고자 돌다리만 두드리다가, 정작 다리를 건너기도 전에 지쳐버리는 상황이 반복된 겁니다. 그리고 이 전제가 지금은 완전히 무너졌습니다.

목업 하나가 PPT 백 장보다 훨씬 강력하다

제가 앞서 말한 후배가 만든 앱이 딱 그 증거입니다. 대화 반나절이면 MVP가 나옵니다. 매몰 비용이 확 줄어들었다는 건, 게임의 룰 자체가 바뀌었다는 뜻인데요.

비용이 낮아지면 우리가 일하는 방식과 논리도 통째로 바뀝니다. 예전에는 “이 아이디어가 성공할 확률은 몇 %일까?”를 증명하기 위해 수많은 분석 장표를 썼습니다. 이제는 “일단 만들어보고, 아니면 다른 걸 시도해보자”가 정답입니다. 머리로 상상하고 시뮬레이션하는 비용보다, 빠르게 만들어서 눈으로 보고 체감해보는 것이 훨씬 이득이기 때문이죠.

여기서 핵심은 ‘실패를 마음껏 해볼 수 있는 기회’를 얻었다는 점입니다. 예전에는 한 번 실패하면 한 달짜리 부서 리소스가 통째로 날아갔지만, 이제는 아침에 뚝딱 만든 화면이 반응이 없으면 점심때 갈아엎고, 오후에 새로운 버전을 시도하면 됩니다. 매몰되는 비용이 극단적으로 줄었기 때문에 그만큼 부담도 줄어들었습니다. 이렇게 실패의 빈도가 늘어날수록, 자연스럽게 보다 유용하고 완성도 높은 결과물로 이어지게 됩니다. 그 과정에서 배우는 속도(학습의 밀도)도 기하급수적으로 올라가고, 이것이 속도의 경제학이 가져다준 진짜 혁신이죠.

<출처: 작가>

이 변화가 가장 극적으로 드러나는 자리가 바로 기획입니다. 예전 흐름은 ‘아이디어 → PPT → 개발팀 → 최소 몇 주 뒤 결과물’이었습니다. 지금은 ‘아이디어 → AI와 대화 → 하루 만에 동작하는 화면’입니다. 말로 백 장을 설명하는 기획서보다, 눈앞에서 실제로 작동하는 화면 하나가 가장 완벽한 기획 명세서가 된 겁니다.

여기엔 또 하나의 이점이 있습니다. 그건 바로 소통 비용의 극적인 감소입니다. 도형과 텍스트로 가득한 PPT 화면 기획서만 보고 회의를 하면, 백 명이면 백 명 머릿속에 다 다른 그림을 그립니다. 당연히 커뮤니케이션 미스가 생길 수밖에 없습니다. 하지만 마우스로 클릭하면 다음 페이지가 열리고 눈으로 화면을 직접 볼 수 있고, 눌러볼 수 있는 실제 MVP(프로토타입) 앞에 모이면 오해의 여지가 사라집니다. 구구절절 설명할 필요 없이, “자, 이거 클릭해서 살펴봐 주세요” 한마디면 사람들의 각각의 상상이 하나로 정리되기 시작합니다.

저 역시 비슷한 변화를 경험했습니다. 아이디어를 긴 문서로 설명하는 대신, 바이브코딩으로 하루 만에 동작하는 MVP(프로토타입)을 만들어 회의에 들어갔습니다. 마이크 버튼을 눌러 음성 인식을 직접 테스트해 보거나, 클릭 한 번으로 분석 결과를 띄워주는 등 실제로 구동시켜 볼 수 있는 가벼운 프로토타입이었습니다.

회의실의 반응은 즉각적이었습니다. 설명만 듣던 사람들이 직접 동작시켜 보고 체험해 보는 참여자로 바뀌었습니다. 구체적인 화면이 눈앞에 있으니 옥신각신할 필요 없이 본질적인 의견이 오갔죠. 흥미롭게도 어떤 프로토타입은 보여주자마자 그 자리에서 즉시 거절당하기도 했습니다. “우리가 생각한 방향이 전혀 아니네요.”라는 솔직한 피드백을 단 하루 만에 얻은 겁니다.

그럼에도 전혀 아쉽거나 후회되지 않았습니다. 만드는 데 쏟은 시간이 고작 하루였기에 심리적 타격도 크게 없었습니다. 오히려 “이 방향은 확실히 정답이 아니구나”라는 사실을 즉시 파악하고, 다음 날 바로 보완책을 세우는 값진 소득을 얻었습니다. 시도하는 비용이 극도로 낮아지면서, 기민한 실패와 피드백의 수용이 다음 성공을 위한 가장 안전한 디딤돌이 된 거죠.

정리해 보면, AI 시대의 속도의 경제학은 단순히 개발 시간을 단축한 것을 넘어, 기획 단계에서부터 지지부진하게 흐르던 의사결정의 병목을 효과적으로 해결했습니다. 상상 속 아이디어를 반나절 만에 동작하는 화면으로 증명하고, 회의실의 상상을 하나로 싱크를 맞추고, 프로젝트의 가능성을 초고속으로 검증할 수 있게 해주니까요.

그렇다면 반나절 만에 동작하는 프로토타입을 척척 찍어낼 수 있게 되었다고 해서, 모든 고민이 끝난 걸까요? 진짜 고민은 여기서부터 시작됩니다.

우리가 끝까지 지켜야 할 ‘의도의 방향성’

물론 만들기가 쉬워졌다고 해서 성공의 문턱까지 낮아진 것은 아닙니다. 손가락만 움직이면 그럴듯한 화면이 뚝딱 나오니, 뚜렷한 목적 없이 막연한 아이디어만 일단 쏟아내고 보는 시도도 늘어났습니다. 그러나 이렇게 만든 MVP는 아무리 빠르게 만들어도 쓸모가 없습니다. 검증하려는 명확한 가설이 없다 보니, 실패를 겪어도 무엇을 고쳐야 할지 배울 수 없기 때문입니다.

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

이렇게 생각 없이 AI를 통해 속도만 올릴 때의 문제는 그럴싸해 보이지만, 쓸모없는 결과물이 만들어진다는 겁니다. 명확한 의도 없이 AI에 의존해 뚝딱 만들어낸 화면은 겉보기엔 그럴듯해 보여도, 정작 사용자의 진짜 문제를 해결해 주지 못하는 무용지물이 되기 쉽습니다. AI는 사용자의 요청을 받아들이는 과정에서, 요청하는 사람의 지시가 모호할수록 그 빈틈을 엉뚱한 기능이나 작위적인 논리로 채워 넣는 특성이 있기 때문입니다.

결국 정교한 디렉션과 꼼꼼한 사후 검증, 그리고 최종적인 사람의 판단이 뒷받침되어야 비로소 가치 있는 제품이 만들어집니다. 그렇다면 AI를 활용해 진짜 쓸모 있는 제품을 잘 만들려면 어떻게 해야 할까요? 실무에서 즉시 적용해 볼 수 있는 세 가지 규칙을 정리해 봤습니다.

첫째, 한 번에 완벽한 결과물을 기대하지 마세요.
처음부터 수십 장짜리 기획서를 AI에 집어넣어 완성본을 한 번에 뽑아내려 하면 십중팔구 엉뚱한 결과가 나옵니다. 핵심 기능 한 페이지, 또는 가장 중요한 핵심 모듈 하나씩 점진적으로 고도화하는 것이 훨씬 빠르고 정확합니다.
둘째, 검증하려는 문제를 최대한 작고 뾰족하게 정의하세요.
해결하려는 범위를 넓게 잡을수록 AI의 기획과 설계 방향도 흩어지게 됩니다. “마이크 버튼을 눌러 음성 인식을 시도할 때, 오인식 없이 자연스럽게 정보가 입력되는가?”처럼, 단 하나의 명확한 가설에만 초점을 맞추는 것이 시도의 비용을 극단적으로 낮추는 방법입니다.
셋째, AI의 결과물을 반드시 주도적으로 검증하고 제어하세요.
AI는 사람의 지시가 모호할수록 그 빈틈을 엉뚱한 기능이나 작위적인 논리로 채워 넣는 특성이 있습니다. AI가 뱉어낸 화면 설계나 기능이 원래 풀려고 했던 비즈니스 핵심 문제와 진정으로 맞닿아 있는지 날카롭게 검증해야 합니다.

예전에는 컴퓨터가 알아듣는 개발 언어 문법(Syntax) 즉 프로그래밍을 잘 짜는 사람이 실력자였습니다. 하지만 코드를 AI가 짜주는 지금, 진짜 실력은 ‘무엇을 왜 만드는가’라는 의도(Intent)를 얼마나 또렷하게 정의할 수 있느냐로 옮겨갔습니다.

그래서 저는 AI에 무언가를 던지기 전에 다섯 가지를 점검하는 습관이 생겼습니다.

무엇을 만드는가: 목표를 딱 한 줄로 적어본다
누구를 위한 것인가: 사용자가 머릿속에 그려지는가
왜 만드는가: 이게 풀리면 그 사람에게 무엇이 달라지나
무엇으로 성공을 판단하나: 실패와 성공을 가를 숫자나 신호
무엇을 하지 않을 것인가: 경계와 제외. 이걸 안 정하면 AI 폭주의 시작이 된다

이 다섯 개가 흐릿한 상태로 AI에 던지면, 빠르지만 무의미한 결과물이 나옵니다. 반대로 이게 또렷하면, 같은 AI로 같은 시간 안에 훨씬 정교한 결과물을 만들어 낼 수 있습니다.

여기서 한가지 더 의도를 정리한 후 실제 MVP를 만들어 가는 과정에서 주의할 사항은 무엇일까요? 제품을 만드는 사이에 이 의도가 너무나 쉽게 흐려질 수 있다는 것입니다. 특히 AI가 그럴듯한 화면을 단숨에 뽑아내면, 사람은 “오, 이거 꽤 멋진데?” 하고 넋을 잃기 쉽습니다. 정작 원래 해결하려던 본질적인 문제는 뒤로 밀려나고, AI가 뱉어낸 매력적인 화면에 끌려다니는 주객전도가 발생하죠.

이 함정에서 벗어나 의도를 끝까지 유지하기 위해서는 아주 단순하지만 강력한 장치가 필요합니다. 바로 작업 화면 한구석에 내가 풀려는 단 하나의 문제를 항상 메모로 띄워놓는 것입니다.

<출처: Unsplash / Patrick Perkins>

AI와 실시간으로 대화를 주고받으며 결과물을 다듬다 보면, 생각의 곁가지가 계속해서 뻗어 나가며 길을 잃기 십상입니다. 그때마다 화면 옆에 적어둔 원래의 목적을 흘끗 쳐다보고 방향을 다잡아야 합니다. “이 멋진 기능이 정말 우리가 처음에 정의했던 사용자의 문제를 해결해 주는가?”라고 끊임없이 스스로 질문을 던지는 것, 이 단순한 버릇 하나가 AI에게 휩쓸리지 않고 주도권을 지키는 가장 확실한 방법입니다.

마치며

결국 AI 시대의 진정한 경쟁력은 단순히 MVP를 더 빨리 만들어내는 속도 경쟁을 넘어, 그 빠른 시도 속에 담긴 ‘의도의 방향성’을 끝까지 잃지 않는 데 있습니다. 방향을 잃은 MVP는 쓸모없는 결과물 더미가 될 뿐이지만, 또렷한 의도와 가설이 실린 시도는 비록 실패하더라도 다음 단계를 향한 가장 귀중한 단서(학습)기 때문이죠.

AI는 앞으로도 더 빠르고 강력하게 진화할 겁니다. 그 빠른 시도들을 조율하고, 진짜 쓸모 있는 결과물로 이끄는 건 사람의 의도에서 나올 거고요. 속도에 주도권을 빼앗기지 않고 기획의 중심을 지키는 힘이야말로, AI 시대에 우리가 쥘 수 있는 가장 확실한 무기 아닐까요?

<참고>

]]>

클로드 코드로 5일 만에 웹 포털 런칭한 방법

지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나에서 '클로드 코드로 5일 만에 웹 포털 런칭한 방법'을 정리한 것입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 클코나잇 2 두 번째 연사로 함께하게 된 이현입니다. 오늘 발표할 주제는 비개발자 기획자였던 제가 어떻게 현업에서 돌아가는 웹 포털을 5일 만에 런칭하고 운영할 수 있었는가에 대한 이야기입니다.

간단히 제 소개를 먼저 드리면, 저는 이전에 IT 기업 DX 전략팀을 거쳐 현재는 교육기업에서 AX 전략팀 기획자로 근무하고 있습니다. 주로 스레드나 뉴스레터로 간간이 AX에 대한 생각과 경험을 공유하고 있습니다. 오늘 전해드릴 이야기는 크게 클로드 코드로 웹 시스템을 만드는 것, 운영하는 것, 그리고 지속 가능하게 하는 것, 이 세 가지 파트로 나눠 말씀드리려고 하는데요.

그중에서도 만드는 것을 넘어 운영 단계에서 마주친 어려움과, 그 이슈 또한 클로드 코드로 해결해 나간 이야기를 중점적으로 전달드리고자 합니다.

첫 AX 과제: 슬랙 기반 정산 비효율

먼저 이 프로젝트의 배경이 궁금하실 텐데요. 이 일은 제가 AX 전략팀에서 일하고 있다 보니 첫 AX 과제로 진행하게 된 일이었습니다. 제가 해결해야 했던 과제는 슬랙 기반의 정산 비효율을 해결하는 것이었는데요. 이 배경을 더 깊게 설명드리기 전에, 제가 생각하는 AI 활용의 스펙트럼을 먼저 언급할 필요가 있을 것 같습니다. 저는 개인적으로 이 스펙트럼을 세 단계로 구분하고 있습니다.

1단계, 채팅형 활용: 챗봇 형태로 쓰면서 업무에 간헐적인 도움을 받는 단계입니다.
2단계, 에이전트 활용: 클로드 코드 같은 에이전트로 조직이 함께 쓸 수 있는 업무 시스템을 만들거나 자동화해 보는 단계입니다.
3단계, 동료로서의 AI: 궁극적인 단계로, AI가 조직의 맥락 전체를 아는 상태에서 회사의 업무 흐름에 얼라인되어 정말 저희의 동료로서 역할할 수 있는 단계라고 생각합니다.

이번 프로젝트는 이 중 두 번째 단계, 즉 바이브 코딩을 통해 AI 코딩 에이전트로 문제를 해결해 보는 접근이었다고 이해해 주시면 됩니다.

그러면 슬랙 기반의 정산 업무 비효율이 어떤 문제이길래, 클로드 코드로 해결하려고 생각하게 됐을까요? 저희 회사는 전국적으로 30개 이상의 캠퍼스를 운영하고 있는데요. 분기마다 정산 업무가 돌아오는데, 그게 업무의 병목이 많이 되는 형태였습니다.

전체 현황 파악 불가: 캠퍼스마다 슬랙 채널을 따로 운영하고 있어 전체 현황을 한눈에 파악할 수 없었습니다.
수동 계산의 오류 위험: 사람이 직접 계산하다 보니 오류 위험이 상존했습니다.
반복적인 이의제기: 정산 결과를 두고 이의제기가 반복적으로 발생했습니다.
진행 상태 추적 어려움: 히스토리로 관리되지 않다 보니 진행 상태를 추적하기 어려웠습니다.

진짜 병목은 워크플로우 그림 밖에 있었다

가장 먼저 진행한 일은 피그잼(FigJam)으로 as-is 워크플로우를 그리면서 병목 구간을 발견해 보는 것이었는데요. '정산 자동화니까 간단하게 AI로 해볼 수 있지 않을까' 싶은 업무도, 실제로 업무 플로우를 뜯어보면 그렇지 않은 경우가 더 많았습니다. 발표에서 제가 피그잼으로 분석한 워크플로우 화면을 캡처해 보여드렸는데, 화면 자체를 설명드리려는 목적이라기보다는 하나의 업무가 AI 전환을 하기 위해서는 얼마나 복잡하게 얽혀 있는지, 이걸 분석하고 파악하는 게 얼마나 중요한지에 대한 예시로 봐주시면 좋겠습니다.

다만 이렇게 플로우 차트로 업무 병목 파악이 용이해지더라도, 여전히 알 수 없는 것이 하나 있었는데요. 바로 '이 프로세스에서 정말 문제가 되는 핵심 병목은 무엇인가'였습니다.

저는 이걸 현장의 데이터를 확인하는 과정을 통해 파악할 수 있었습니다. 데이터 확인 결과, 핵심 병목은 본사가 통보한 정산 결과값에 대한 이의제기와 확인 절차였습니다. 혹시 사내에서 AX를 시도하고 계신 분들이 있다면, 업무 프로세스 맵 그리기 자체에 몰두하시기보다는 현장의 목소리와 데이터를 면밀히 들여다보시길 추천하고 싶습니다.

그래서 제가 기획적으로 해결을 시도한 부분이 '정산 미리 보기' 기능이었는데요. 이의제기 자체가 생길 수 없는 구조를 만든 겁니다. 가맹점주가 데이터를 직접 입력하고 납부 예정 금액을 미리 볼 수 있게 했죠. 본인이 입력하고, 납득하고, 제출하는 구조로 바뀌면 '왜 이런 정산값이 나왔는지' 본사에 이의제기하기 어려운 구조가 됩니다.

정리하자면, 클로드 코드 같은 AI 툴로 무언가를 빠르게 구현해 보는 것은 이제 쉬운 일이 된 것 같은데요. 하지만 올바른 문제에 겨냥하고 그 AI 툴로 문제를 풀어나가는 것은 여전히 사람의 몫이라는 점을 꼭 짚어드리고 싶습니다. 또 하나 더 말씀드리면, 기술적으로 무언가를 실험해 보겠다는 게 아니라, 일반 비개발자 입장에서 내 업무를 AI로 바꿔보고 싶다는 목적이라면, 저는 기획의 중요성을 너무나도 강조하고 싶습니다.

두 번의 피벗이 만든 5일 런칭

다음은 두 번째 파트로, 클로드 코드로 포털을 만들면서 어떤 과정을 거쳤는지 그 여정에 대한 이야기입니다. 저는 사내 AX를 진행할 때 항상 염두에 두는 것이 있는데요. 시스템을 만들기 전에 MVP를 먼저 찾는 것입니다. 이번에도 MVP를 찾는 과정을 진행했습니다.

1차 시도, 슬랙 안에서 해결: 슬랙 기반의 정산 비효율이다 보니 슬랙 안에서 해결하고자 가설을 세웠습니다. 그런데 막상 현장 반응을 보니 슬랙을 공지나 DM 용도로 쓰는 분들이 많았고, 어려워 보인다는 피드백이 있었습니다. 이를 통해 '웹 기반의 단일 채널이 필요하구나'라는 걸 알게 되었습니다.
2차 시도, 노코드 툴 조합: 노코드 툴을 조합해 연결하면 되지 않을까라는 가설이었는데요. 진행해 보니 툴 간 의존성이 생기고 하드코딩 이슈가 생기는 등 UI 흐름 제어에 한계가 있었습니다. 나중에 미납금 관리 같은 기능 추가를 고려했을 때도 노코드로는 풀 수 없는 한계가 보였습니다.
최종 피벗, 클로드 코드: 마지막으로 클로드 코드로 만들기로 결정했습니다.

사실 앞선 두 번의 피벗 덕분에 오히려 '무엇을 만들어야 하는지' 기획 단계를 정확하게 다질 수 있었고, 이것이 5일 만에 런칭하게 된 기반이 되었습니다. 이 경험을 기반으로 마스터 PRD 프롬프트를 작성하고, 클로드 코드에 주입해 5일 만에 런칭을 시도할 수 있게 되었습니다.

실제로 이 5일을 어떻게 썼는지도 궁금하실 것 같은데요. 첫째 날은 마스터 프롬프트로 첫 결과물을 뽑는 데 썼습니다. 기존 피벗 경험으로 무엇을 만들어야 할지가 명확해지다 보니 빌드에는 하루면 충분했습니다. Day 2부터는 검증하고 리뷰하는 단계를 진행했고, Day 4에 사용자 교육까지 진행한 뒤, 마지막 검토를 완료하고 5일째에 배포하게 된 케이스입니다.

이 프로젝트를 진행하면서 하나 더 깨달은 부분이 있습니다. AI가 낮춰준 건 기술 장벽만이 아니라, 전환을 결정하는 심리적 비용도 낮춰줬다는 점입니다. 실패해도 빠르게 다시 시도할 수 있다는 생각이, 매몰 비용에 빠지기보다 새로운 기술 스택을 시도해 볼 수 있는 토대가 되어주었습니다.

실제로 만든 화면도 간략하게 소개드리면, 사용자 화면으로는 정산을 입력하는 가맹점주분들이 보는 대시보드가 있고요. 정산 입력 상세 페이지에서는 자동 계산 값이 추출되면 마지막으로 확인 체크를 하고 정산 최종 값을 제출하는 프로세스로 구성했습니다. 관리자 화면에서는 가맹점주분들이 제출한 데이터를 대시보드 형태의 리스트 하나로 확인할 수 있게 했습니다.

만드는 것과 운영하는 것은 다르다

마지막 세 번째 파트는, 만드는 것과 운영하는 것은 다르다는 걸 깨달은 시행착오에 대한 이야기입니다. 배포 다음 날, "로그인이 많이 느린 것 같다"라는 피드백이 하나 들어왔습니다. 처음에는 '네트워크 문제겠지'라고 생각했는데, 원인은 인프라의 기본값에 있었습니다.

수파베이스(Supabase)를 사용했는데 데이터베이스 리전이 한국이 아니었고, 버셀(Vercel) 네트워크 리전도 북아메리카가 기본값으로 설정되어 있었습니다. 로그인 인증을 거치면서 여러 리전을 경유하느라 수 초씩 걸리는 이슈가 생긴 것이었고, 이 부분을 보완하는 과정을 거치게 되었는데요.

여기서 깨달은 점은, AI가 작성한 코드에는 문제가 없어도 문제는 코드 밖 인프라 설정의 기본값에 있을 수 있다는 것이었습니다. 이 부분은 비개발자분들이라면 더욱 함정에 빠지기 쉬운 내용 같은데요. '작동하는 것이 꼭 완성된 것은 아니구나'라는 점을 시행착오를 통해 깨닫게 되었습니다.

관련 내용을 찾아보니 이미 만들어진 DB 서버의 리전을 옮길 수는 없었고, 새로운 DB를 만들어 마이그레이션해야 하는 이슈로 부상하게 되었는데요. 이걸 해결하는 과정도 흥미로웠습니다. 클로드 코드와 함께 토론하며 명확한 방향을 정할 수 있었는데요. 처음 클로드 코드에게 물어봤을 때는 "이번 분기를 지나 서비스 사용이 안정적일 때 시스템 공지 후 진행하자"라는 답변을 받았습니다.

하지만 제가 알고 있는 도메인 지식과 DB에 대한 지식을 기반으로 역제안을 해볼 수 있었습니다. 새 리전 DB로 데이터를 옮긴 뒤 무중단 마이그레이션하는 방법을 제안했고, 클로드 코드가 이를 검증해 주면서 이 방법으로 진행하게 되었습니다. 결과적으로 API를 통해 새 리전 DB로 이관했고, 로그인 속도가 80% 개선되는 결과를 얻었습니다.

마지막으로, 클로드 코드로 만든 결과물을 지속 가능하게 운영하기 위해 문서화 부분도 빼먹지 않도록 클로드 코드와 같이 진행했습니다. 최종적으로 분기당 업무 시간 절감, 연간 시간 절감, 로그인 속도 개선까지, 운영 단계 이슈를 해결한 것까지 포함해 결과값이 나오면서 AX 과제를 잘 마무리할 수 있었습니다.

올바른 문제에 겨냥하는 것은 여전히 사람의 몫이다

이 경험에서 배운 세 가지를 말씀드리면서 마무리하겠습니다.

올바른 문제에 겨냥하는 것은 여전히 사람의 몫입니다. AI는 잘못된 문제도 빠르게 풀어주고, 방향이 틀렸어도 그럴싸한 결과물이 나옵니다. 그만큼 사람이 그 강력한 도구를 올바른 문제에 겨냥하는 것이 중요하다고 생각했고, 이것이 AI 시대의 빌더이자 기획자의 역할이라고 생각합니다.
탐색은 낭비가 아닙니다. 각 피벗은 실패가 아니라 MVP를 좁혀나가는 과정이었습니다. AI는 잘못된 선택의 비용을 낮춰주기 때문에, 매몰 비용에 빠지기보다 전환을 시도하는 과감한 결정이 과거보다 수월해졌다는 것을 깨달았습니다.
만드는 것과 운영하는 것은 다릅니다. 배포 기본값 문제로 로그인이 느려진 이슈를 해결하면서, 운영을 위해서는 인프라에 대한 파악과 판단도 여전히 사람이 해야 하는 부분이라는 점을 깨달았습니다.

이상으로 발표 마치겠습니다. 저처럼 비개발자임에도 촉박한 시간 내에 AI로 프로젝트를 진행시켜야 하는 분들에게 도움이 되길 바랍니다. 감사합니다.

▶발표 영상 유튜브에서 보기

]]>

AI 시대 프로덕트팀 재설계법(feat. 보리스 체르니)

직함은 그대로인데 하는 일이 달라지기 시작했다는 얘기를 요즘 자주 듣습니다. 분명 PM인데 요즘 하는 일은 3년 전 PM이 아니고, 디자이너라면서 코드를 만지고 있고, 백엔드 개발자인데 제품 기획 회의에 앉아 있고요. 저도 비슷한 위화감이 들었는데, 한동안 이름 붙이지 못한 채 지나쳤습니다. 그런데 앤트로픽에서 클로드 코드(Claude Code)를 총괄하는 보리스 체르니(@bcherny)가 그 변화를 트윗 한 장으로 꽤 깔끔하게 정리해줬더라고요.

지난 6월 28일에 올린 이 트윗은 이틀 만에 좋아요 1만 9천, 리트윗 2천을 넘겼습니다. 답글만 856개가 달렸고요. 그는 "엔지니어링, 프로덕트, 디자인, 데이터 사이언스 같은 직군이 새로운 종류의 역할로 녹아드는 지금(melt into a new kind of role), 앞으로 역할이 어떤 모습일지 생각해봤다"며 자기 팀에서 관찰한 다섯 가지 유형, 그러니까 아키타입을 제시합니다.

보리스 체르니의 X

이 아키타입을 먼저 살펴보고, 이것이 어떤 의미인지 어떻게 활용하면 좋을지 생각해본 내용을 공유해보겠습니다.

체르니가 본 다섯 가지 유형

체르니가 꼽은 다섯은 프로토타이퍼, 빌더, 스위퍼, 그로워, 메인테이너입니다.

프로토타이퍼는 완전히 새로운 아이디어를 쏟아냅니다. 대부분은 출시되지 않고 버려지죠. 국내로 옮기면 해커톤 이틀 만에 데모 세 개를 뚝딱 만들어 오는 그 사람입니다. 빌더는 그 프로토타입을 실제 프로덕션급 제품·인프라로 빠르게 옮깁니다. "돌아가는 데모"를 "고객이 쓰는 서비스"로 만드는 역할이고요. 스위퍼는 UI를 정리하고 코드와 시스템을 단순화하고 안 쓰는 기능을 걷어내고 성능을 최적화합니다. 리팩터링과 기술 부채 청소를 즐기는 사람이 여기 해당됩니다.

그로워는 이미 만든 제품을 반복해서 개선하며 PMF, 그러니까 제품-시장 적합성을 끌어올립니다. 지표 보고 A/B 테스트 돌리고 리텐션을 파는 그로스 담당이 떠오르죠. 마지막으로 메인테이너는 성숙한 시스템을 안전하고 안정적이고 빠르게 유지합니다. 대규모 트래픽을 몇 년째 사고 없이 떠받치는 인프라·SRE 쪽이고요.

<출처: 작가, ChatGPT로 제작>

체르니는 이와 같은 아키타입을 소개하며 두 가지 내용을 덧붙였습니다.

먼저, 많은 사람들이 이중 2~3가지 역할을 하고 있으며, 이 역할들이 직무와 크게 연결되지 않는다고 합니다. 앤트로픽만 봐도 어떤 디자이너는 프로토타이퍼(유형 1)에, 어떤 디자이너는 빌더(유형 2)에, 또 어떤 디자이너는 스위퍼(유형 3)에 해당하고, 엔지니어도 PM도 데이터 사이언티스트도 마찬가지라는 것입니다.

두 번째로, 건강한 프로덕트 팀은 프로덕트의 단계에 따라 이 아키타입의 사람들이 섞여 있어야 한다고 말합니다. PMF 이전 초기 제품은 프로토타이퍼·빌더·스위퍼의 힘이 필요하고 PMF를 잡고 성장하는 제품은 빌더·스위퍼·그로워에 유지보수를 조금 얹은 조합이 필요하다고 제안합니다. 성숙한 제품은 스위퍼·그로워·메인테이너에 약간의 빌더로 돌아간다고 하고요. 같은 사람이라도 초기 스타트업에서는 딱 맞다가 성숙기 조직에 가면 상황이 다를 수 있다는 뜻이기도 합니다.

앤트로픽 블로그에 따르면 클로드 코드 팀은 애초에 ‘Member of Technical Staff’라는 하나의 직무 타이틀 아래서 프로덕트·디자인·인프라·리서치를 다 다루는 구조로 굴러간다고 하는데요. 역할 별로 직함을 나누지 않으니, ‘모두가 다 한다’는 것이 기본 전제가 되는 것입니다. 보리스 체르니가 다섯 가지 아키타입을 제안하게 된 배경도 직함이 없는 팀에서 사람들이 실제로 어떻게 일하는지를 관찰한 결과가 아닐까 합니다.

이미 시작된 변화

사실 이같은 이야기를 하는 것이 체르니만은 아닙니다. 이미 직군이 ‘녹는’ 현상은 업계 곳곳에서 나타나고 있고, 새로운 이야기도 아닙니다. 세일즈를 하는 개발자, 개발을 하는 디자이너에 대한 이야기가 주변에서도 종종 들려오고요. 운영팀이 기존에 개발자에게 요청할 업무들을 직접 하게 됐다는 이야기도 심심치 않게 들리죠. 얼마 전 레니의 뉴스레터에는코덱스 앱 리드가 출연해 팀에서도 역할이 많이 붕괴되고 있다고 말했습니다. PM이 기술 용어를 쓰고 코드를 짜거나 디자이너도 엔지니어링을 말한다는 것이죠.

Shopify CEO 토비 뤼트케는 지난해 사내 메모에서 "반사적인 AI 사용은 이제 Shopify의 기본 기대"라고 선언했습니다. 인력을 더 요청하기 전에 왜 AI로는 그 일을 못 하는지부터 증명하라는 규칙까지 붙였고요. 샘 올트먼은 앞으로 회사가 1인 혹은 소규모 팀으로 굴러갈 거라고 봅니다. 한 사람짜리 10억 달러 회사가 나오는 것도 가능하다고요. AI를 활용해 회사를 위한 목표를 달성하는 것이 중요하지, 어떤 직군에서 어떤 성과를 내느냐의 구분은 중요하지 않게 된 것입니다.

한국도 마찬가지입니다. 토스는 매주 금요일을 'AI Surf Day'로 두고 AI 실험 시간을 제도화했습니다. AI Surf Club이라는 자발적 모임이 200개 가까이 생겼고 팀 워크숍을 이끄는 에반젤리스트가 142명이라고 하고요. 토스의한 마케팅 팀은 아예 직무를 Builder·Curator·Operator·Scouter라는 역할로 나눠 일합니다. 마케터라는 직함이 아니라 지금 무슨 실행을 하느냐로 팀을 짠 거죠. 체르니의 아키타입과 다른 이름, 같은 발상입니다.

잡코리아는 미국에서 소프트웨어 개발자 채용공고가 1년 새 35% 줄었다는 인디드 집계를 인용하며, 국내에도 곧 비슷한 흐름이 올 거라 보고 '한 분야는 깊게, 여러 분야는 넓게' 아는 T자형 개발자를 생존 전략으로 제시했고요. 카카오는 AI 조직을 목적형 스튜디오 구조로 바꿔 배포 주기를 한 달로 당겼다고 합니다. 더 이상 기존의 기능적으로 분리된 프로덕트 팀이 일하던 방식은 AI 시대에 맞지 않게 된 것이죠.

직군이 오히려 분화된다?

그런데 반대로 직군이 오히려 분화된다는 주장도 있습니다. 대표적으로 앤드루 응은 AI 엔지니어라는 직군이 성숙하면 오히려 다시 쪼개진다고 합니다. 수십 년 전 소프트웨어 엔지니어가 프론트·백엔드·모바일·데브옵스로 갈라졌던 것처럼, AI FDE·LLMOps·Evals·Data·Harness 엔지니어 같은 전문 직군으로 세분화될 거라고 봅니다.

하지만 이 주장도 사실 같은 방향을 향하고 있다고 생각합니다. "전통적인 소프트웨어 엔지니어 타이틀은 유효기간이 지났다"는 것이죠. 녹아서 하나가 되든 새롭게 여럿으로 갈라지든, 예전 그 직함 그대로 머물지는 않는다는 것은 전제로 하고 있습니다.

이러한 직군이 녹는 현상이 정말 AI 효과냐는 의문도 제기됩니다. 체르니 트윗의 상위 답글에서 가장 많은 지지를 받은 게 동의가 아니라 반박이었다는 점이 흥미롭습니다. 모뎀 창업자이자 전 센트리 소속인 벤 비니거는 트위터에 이렇게 적었습니다. "사람들이 소프트웨어 조직이 원래 어떻게 굴러가는지를 이제야 배우는 것 같은데, 그걸 그냥 정상적인 팀 동학인데 AI 탓으로 잘못 돌리고 있다." 프로토타이퍼든 메인테이너든, 잘 돌아가던 팀엔 예전부터 다 있던 역할이라는 거죠. AI가 새로 만든 게 아니라 원래 있던 걸 AI라는 이름표에 갖다 붙였을 뿐이라는 반박입니다.

또 레니의 팟캐스트에 출연한 코덱스 앱 리드 앤드류 앰브로시노는 그렇다고 직군이 아예 사라진다고 딱 잘라 생각하는 것은 아닙니다. 넓이로나 깊이로나 한 사람이 모든 걸 할 수는 없고, 그동안 제품을 만들기 위해 쌓아 올린 모범 사례가 있으며, 그 모범사례를 가진 전문 영역이란 건 여전히 중요하다는 것입니다. 다만 역할을 바꾸기가 쉬워질 거라고 보고 있죠.

그래서 실무자인 나는 무엇을 하나

사실 직군이 정말로 녹냐, 아니냐 그 자체는 중요하지 않은 것 같습니다. 소속 직군에 상관 없이 우리가 우리의 일을 어떻게 정의할지는 언제나 중요했던 것 같습니다. 같은 직함을 갖고 있어도 일하는 방식이나 일에 대한 태도는 모두 다르니까요.

다만 아무래도 일에서 AI를 점점 더 적극적으로 활용하게 되는 만큼, 기존의 일하는 방식이 달라지고 있는 것도 사실이고요. 개발자가 하는 일도 이미 코드 작성이 아니라 판단과 검수라는 프레임으로 변하게 된 지도 꽤 됐습니다. 변화가 현실로 다가오고 있으니, 보리스 체르니가 제시한 아키타입으로 지금 시점의 내 일의 변화를 한번 짚어보는 것도 좋다고 생각합니다. 다른 의견도 있을 수 있지만, 저는 현재의 변화를 바라보는 한 가지 좋은 프레임워크가 아닐까 합니다.

이 아키타입을 저는 이렇게 활용해보았습니다.

먼저, 내 아키타입을 이해합니다. 직함 말고 실행 방식으로 나를 다시 보는 것입니다. 나는 새 아이디어를 쏟아낼 때 신나는 사람인가, 남이 벌여놓은 걸 실제 제품으로 완성할 때 몰입하는 사람인가, 지저분한 코드를 걷어낼 때 제일 개운한 사람인가. 직함은 'PM'이나 '프론트엔드'라고 하나로 찍혀 있어도, 실제로 일하는 방식은 두세 유형에 걸쳐 있을 겁니다. 그 조합이 지금의 나예요.

저의 경우에는 프로토타이퍼 성향이 아주 강한 편입니다. 빠르게 뭔가를 만들어보고 일단 돌아가면 만족하는 편이라서, 오히려 그걸 꾸준이 유지하고 개선하는 역량이 좀 약합니다.

그다음으로, 내 제품이 어느 단계인지 살펴봤습니다. 체르니 말대로 PMF 이전이냐, 성장 중이냐, 성숙기냐에 따라 지금 팀이 필요로 하는 아키타입 조합이 다릅니다. 내가 프로토타이퍼 성향이 강한데 회사 제품은 이미 성숙기에 접어들어 스위퍼·메인테이너를 원한다면, 그 간극이 바로 요즘 느끼는 위화감의 정체일 수 있어요. 내 성향과 팀이 요구하는 조합을 나란히 놓고 보면 그 어긋남이 눈에 들어옵니다. 제가 딱 그렇습니다. 다만 요즘엔 회사에서도 AI로 이런저런 새로운 시도를 하게 되다 보니 그나마 프로토타이퍼적인 성향이 만족되고 있는 것 같습니다.

이런 분석에만 멈추면 달라지는 게 없을 것입니다. 마지막으로 한 발 더 나아가서, 그렇다면 지금 내가 약한 부분은 어떤 부분인지, 그걸 보강하려면 어떻게 해야 하는지를 생각해보는 것이 중요한 것 같습니다. 특히나 요즘 시대에는 약한 부분은 AI로 보강할 수 있습니다. 저같은 경우에는 한 가지 아이디어를 실행하는 중간에 그다음 아이디어를 실행할 생각에 막 들뜰 때가 있습니다. 그래서 저는 제가 클로드코드랑 이야기하다가 갑자기 딴 길로 샐 때 실행을 멈추라는 명령을 심어뒀습니다.

이런 프레임워크는 팀을 짜는 리더에게도 유용할 것 같습니다. 지금 우리 제품이 어느 단계고, 그 단계에 필요한 아키타입 조합이 뭔지, 팀에 어떤 유형이 비어 있는지를 직함 대신 실행 방식으로 그려보는 거죠.

아키타입에 갇히지는 마세요

마지막으로 체르니 트윗 답글 중에 인상 깊은 트윗을 소개하려합니다. "자기를 특정 아키타입으로 분류하는 건 종종 사람이 야망을 넓히는 걸 가로막는다. 유연하게 있고, 목표 달성에 중요한 것에 몰두하고, 시간이 지나며 계속 흐려질 역할 경계에는 덜 신경 써라."

아키타입은 지금 이 순간의 내 상태를 읽어보는 프레임일 뿐, 나를 가둬두는 상자 같은 건 아닙니다. 사실 중요한 건 내 일을 통해 가치를 만들어내는 것이지, 내가 어떤 유형인지 이해하는 것 자체가 어떤 가치를 만들어내지는 않으니까요. 프로젝트가 바뀌면 나도 다른 아키타입의 역량을 펼쳐보일 수도 있습니다. 위에 소개한 말이 기우처럼 보이는 측면도 있지만, 한번쯤 생각해봐야 할 지점 같습니다. 일을 하다보면 종종 나도 모르게 주어진, 정해진 틀 안에서만 일하려 하기도 하니까요.

AI로 인한 변화가 너무 빨라 기존의 프레임워크로는 변화를 읽기가 어려워졌습니다. 그러다 보니 이런 앞서가는 사람들이 제안하는 프레임워크를 참고해보는 것도 지금의 위치를 이해하기에 좋은 방법이 아닐까 합니다. 지금 내가 어디에 서 있는지 한번 짚어보고, 내 제품이 그자리를 원하는지, 그렇지 않다면 내가 어느 쪽으로 조금 움직여야 할지를 한번 진단해보고, 또 다음에 프로덕트가 혹은 프로젝트가 바뀌면 다시 이 아키타입으로 내 상황을 바라보는 것도 앞을 모르는 세상에서 나름대로 좋은 길잡이가 되지 않을까 합니다.

]]>

AI로 작성하셨나요? 'Im-not-ai'로 AI 티 지우기

이미 많은 분들이 AI로 기획서, 보고서, 블로그 초안 작성 등에 활용하실 텐데요. 그러나 진짜 업무는 AI가 준 작업물을 우리가 검토하는 순간부터라고 생각합니다. 저 역시 AI로 생성한 5,000자 분량의 기획서 초안을 보고, 어색하고 불편하다고 느꼈습니다. AI가 생성한 글에는 문장마다 번역투의 흔적, 기계적인 관용구가 빼곡했거든요.

예를 들어, "~에 대해 논의를 진행하고자 합니다", "매우 핵심적인 요소라고 볼 수 있습니다", "결론적으로 이는 시사하는 바가 큽니다"와 같은 표현들인데요. 오히려 AI가 써준 초안의 어색함을 지우려고, 윤문과 후편집에 더 많은 시간을 쏟는 거죠.

<출처: 나노 바나나 2, 작가 제작>

AI로 글 작성 시간을 줄이려다가, 수정의 늪으로 빠진 겁니다. 이 어색하고 기계적인 'AI 어투'를 기술적으로 걷어낼 순 없을까요? 이번 글에서는 문맥의 기계적 패턴을 식별해 교정하는 오픈소스 프로젝트 “im-not-ai”로, 그 원리와 문제점을 짚어보고 최적화 전략까지 살펴보겠습니다.

'im-not-ai'는 어떻게 AI를 탐지하고 교정할까?

오픈소스 프로젝트 “im-not-ai”는 글 생성 후 진행하는 윤문, 후편집의 비효율을 통제하기 위해 등장한 도구입니다. 이 프로젝트는 특정 단어를 기계적으로 치환하여, 한글에서 특정 표현이 반복되는 AI의 구조적 결함과 번역학적 오류를 줄이는 프레임워크를 제공합니다.

우선 im-not-ai의 ‘ai-tell-taxonomy.md’는 AI 한글 텍스트의 미세한 흔적들을 10대 대분류와 40개 이상의 세부 패턴으로 정밀하게 분류합니다. 수많은 사용자의 피드백, 깃허브 Contributors 히스토리([Issue #1]를 집약해 구축했는데요. 이 규칙판은 AI 특유의 번역투(A), 기계적인 구조화와 불릿 남용(C), '결론적으로'나 '시사하는 바가 크다' 같은 시그니처 관용구(D), 문장 길이의 단조로운 리듬 균일성(E), 완곡한 회피 표현(G) 등을 심각도(S1 결정적, S2 강함, S3 약함)에 맞춰 스캔합니다.

이후 에이전트는 한국어 윤문 처방집인 ‘rewriting-playbook.md’에 근거해, 사실과 고유명사 등의 핵심 데이터는 100% 보존하면서, 어색한 격조사와 불필요한 정도부사를 한국어 고유의 능동형 서술어와 다양한 종결어미로 재작성하는 작업을 진행합니다.

<출처: 나노 바나나 2, 작가 제작>

흥미로운 점은 이 오픈소스의 진단 도구가 깊이 있는 국제 번역학 이론에 뿌리를 두고 있다는 건데요. 1990년대 번역학자 Mona Baker가 정립한 '번역 보편소(Translation Universals)' 이론에 따르면, 번역문은 원문보다 어휘와 통사가 단순해지는 단순화(simplification)와 목표 언어의 전형적 관습에 기계적으로 고착되는 표준화(normalisation) 경향을 띱니다. AI가 영어 중심의 거대 말뭉치(LLM 데이터셋)를 학습해, 한국어 텍스트를 출력하는 메커니즘도 이와 같죠.

특히 스페인 번역학자 Antonio Toral(2019)은 기계번역 결과물을 사람이 어설프게 교정하는 과정에서 발생한 기형적 문체를 'Post-editese(후편집투)'라고 정의했는데요. 어휘의 다양성이 결여되고, 원문 언어의 간섭 법칙(Toury 1995)에 의해 문장이 꼬여버리는 현상입니다.

결국 우리가 AI 글을 읽으며 느낀 묘한 불쾌감은 역사적으로 오랜 연구 대상이었던 '번역투의 악화된 형태'였던 겁니다. `im-not-ai`는 이러한 번역학적 진단을 규칙화해, 텍스트에 축적된 기계적 간섭의 흔적들을 도려내는 방식을 택했습니다.

<출처: GPT Image 2, 작가 제작>

실전 A/B 테스트: im-not-ai가 만든 결과

이번엔 im-not-ai를 통한 윤문의 효용성을 검증하기 위해, 실제 비즈니스 텍스트로 A/B 테스트를 진행해 봤습니다.

교정에 따른 독자들의 평가가 어떤지 보기 위해, 2~30대의 다양한 직군(PM, 개발자, 디자이너, HR, 마케터 등)을 대상으로 블라인드 테스트를 진행했는데요.

설문 평점(5점 만점)을 분석한 결과,

자연스러움(A안 2.70점 vs B안 4.40점)
명료성(A안 3.15점 vs B안 4.40점)
가독성(A안 2.45점 vs B안 4.35점)
기고문 적합성(A안 2.50점 vs B안 4.25점)

전 영역에서 B안이 압도적인 점수를 받았습니다. 최종 선호도 역시 B안이 85%(17명)의 지지를 얻었고요. 대부분은 B안이 쓸데없는 포장어, 기계적 접속부사가 없어, 정보를 빠르게 파악할 수 있었다고 답했습니다.

<출처: 나노 바나나 2(시각화), 작가(설문, 데이터 분석)>

그러나 흥미로운 결과는 A안에 있었습니다. A안에 높은 점수와 선호도를 보인 15%(3명)은 HR 담당자, 재무 담당자, 브랜드 컨설턴트였는데요. B안이 읽기는 편했지만, 공적인 칼럼으로서는 어조가 다소 단조롭고 가볍다고 평가했습니다. 이들은 오히려 수동 표현이 섞이더라도, 정중하고 격식을 갖춘 A안의 고전적 톤앤매너가 글의 권위와 신뢰성을 높여준다고 응답했죠.

이 결과는 매우 중요한 비즈니스 시사점을 던집니다. AI 번역투를 완전히 제거하는 기계적 미니멀리즘이 늘 최선은 아니라는 점인데요. 가독성을 높이기 위해 문장을 수정하되, 글의 격식과 신뢰가 필요한 상황이라면 독자의 타깃에 맞는 ‘어조의 미세 조정’이 필요하단 거죠.

<출처: 나노 바나나2(시각화), 작가(설문, 데이터 분석)>

현업 도입 전 짚어야 할 한계점은?

윤문 프로세스가 독자에게 주는 영향은 긍정적이지만, 실무에 ‘im-not-ai’를 도입할 때 고려해야 할 두 가지 한계가 있습니다.

첫 번째는 무거운 에이전트 협업 구조에 따르는 API 비용(토큰)의 폭증입니다. 이 오픈소스는 클로드의 고성능 추론 모델인 Opus를 기반으로 동작합니다. 단순히 비싼 모델이라서가 아니라, 정밀 검증(Strict) 모드로 구동할 때 5인의 개별 에이전트(분류학자, 탐지기, 윤문가, 내용 감사관, 자연스러움 리뷰어 등 - 에이전트명 직역 표현)가 다단계 루프를 돌며, API를 수차례 반복 호출하는 무거운 파이프라인 구조가 API 비용을 발생시킵니다.

특히 글자 수가 많은 원고를 처리할 땐, 한 번에 10달러가 훌쩍 넘는 비용이 발생할 수 있습니다. 실제로 개발자는 v1.5에서 단일 호출 monolith Fast 모드가 추가된 것이 비용과 시간을 절감하기 위함이라 밝혔습니다.

<출처: 나노 바나나 2, 작가 제작>

두 번째는 또 다른 템플릿화의 부작용입니다. 제공되는 윤문 규칙이 다소 도식적이고 획일적이라, "몇 번 쓰다 보면 결국 툴 고유의 기계적인 수정 패턴이 또다시 들통나 독자에게 피로를 유도할 것 같다"는 우려죠.

가이드라인이 특정 스타일(단문 위주의 기계적 단순화)에만 다소 편향되어 있어, 실무 도메인이나 필자의 본래 개성을 살리지 못하고, 글을 단조롭게 만드는 또 다른 AI 투를 유발한다는 역설입니다.

마치며

<출처: 나노 바나나 2, 작가 제작>

오픈소스 ‘im-not-ai’는 기술을 활용해 한글 문체 속 AI 어투를 덜어내는 가능성을 증명했습니다. 그러나 현업에서 오픈소스를 도입할 때는 외부 도구의 자동화 규칙을 맹목적으로 신뢰해서는 안 됩니다. 지속 가능한 비즈니스 원가 구조를 설계하듯, 기업 고유의 브랜드 가이드라인과 톤앤매너를 직접 정의하고 이를 프롬프트 단계부터 치밀하게 설계해야 합니다.

결국 비즈니스 글쓰기는 전달력과 신뢰성 사이에서 균형점을 찾는 일입니다. AI라는 거대한 기술 인프라 속에서 여러분은 요즘 어떻게 쓰고 계신가요? 나도 모르게 너무 AI에 의존하고 있진 않나요?

<출처>

(im-not-ai 긍정 평가) 박성철님 링크드인
(im-not-ai 부정 평가) im-not-ai 글에서 ai티 줄이는 스킬인데 괜찮은듯?, AI 웹소설 연재 갤러리, ‘26.05.24
(Mona Baker (1993) – 번역 보편소) Baker, M. (1993). Corpus linguistics and translation studies: Implications and applications. In M. Baker, G. Francis, & E. Tognini-Bonelli (Eds.), Text and Technology: In Honour of John Sinclair (pp. 233–250). John Benjamins.
(Gideon Toury (1995) – 원문 언어의 간섭) Toury, G. (2012). Descriptive Translation Studies and Beyond. John Benjamins.
(Antonio Toral (2019) – 후편집투(Post-editese)) Toral, A. (2019). Post-editese: An exacerbated translationese. Proceedings of the 17th Machine Translation Summit (MT Summit XVII), 273–281.

]]>

클로드 코드, 폰에서도 간편하게 개발할 수 있나요?

지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

이 글은 클코나잇 2 웨비나의 ‘손바닥 위의 개발 환경: AI 에이전트를 폰에서 이어가기’를 정리한 것입니다. 지난 2월 클로드 코드에 공식 기능 '리모트 컨트롤(Remote Control)'이 출시되면서 VPN이나 SSH 세팅 없이도 휴대폰에서 로컬 세션을 이어갈 수 있게 됐고, 6월에는 전 요금제로 확대 적용됐습니다. 한두 개의 클로드 코드 세션을 쓴다면 지금은 공식 기능이 가장 편한 선택입니다.

다만 발표자는 클로드 코드 외 다른 AI CLI까지 연동되고, 사전 설정 없이 여러 세션을 한 화면에 띄워 볼 수 있다는 차별점에 주목해 세션 캐스트를 만들었습니다. 다중 에이전트를 병렬로 돌리는 사용자라면 이 접근은 지금도 유효하며, 개발사의 기능 추가로 개인의 시도가 금세 빛이 바래는 환경에서도 현장 실무자의 기록에는 그 자체로 가치가 있다고 생각합니다.

발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 오늘 '손바닥 위의 개발 환경'이라는 주제로 발표를 맡은 노성현이라고 합니다. 오늘 발표를 한 문장으로 요약하면, PC에서 돌고 있는 AI를 핸드폰에서 그대로 이어서 쓰는 도구를 만들었던 이야기입니다. 제가 직접 만든 '세션 캐스트'라는 도구를 소개할 건데요. 이걸 어떻게 만들었고 어떻게 런칭했는지, 그 과정을 편하게 이야기하는 세션이라고 생각해 주시면 될 것 같아요.

간단하게 소개를 드리면, 저는 와탭랩스에서 일하고 있고, 세션 캐스트라는 서비스를 혼자 만들고 운영하는 1인 메이커입니다. 오늘 이야기는 크게 세 막으로 준비했습니다. 1막은 지금까지 제가 에이전트를 어떻게 쓰고 있었는지, 왜 노트북의 AI를 핸드폰에서 보려고 했는지 등 기존에 제가 활용한 방식들을 소개합니다. 2막은 세션 캐스트가 어떤 문제를 풀려고 하는지, 특히 설치 없이 돌고 있는 세션에 어떻게 붙는지를 소개하고, 3막은 모바일 기능을 만들고 나서 제가 에이전트를 쓰는 방식이 어떻게 바뀌었는지, 런칭 회고까지 짧게 이야기해 보려고 합니다.

미어캣처럼 터미널만 쳐다보던 나날들

본론에 들어가기 전에, 제가 평소에 클로드 코드를 어떻게 쓰고 있었는지부터 말씀드리는 게 좋을 것 같아요. 저는 작년 클코나잇 시즌 1에서 'AI 에이전트 오케스트레이션'이라는 주제로 발표를 했었는데요. 그때 핵심은 tmux를 이용해 여러 개의 클로드 코드 에이전트를 동시에 띄우고, 자기들끼리 대화하면서 일하게 만드는 거였습니다. PM 에이전트가 전체 흐름을 관리하고, 데브 에이전트가 코드를 짜면 QA 에이전트가 테스트하고, 독(Doc) 에이전트가 문서를 쓰고, 디플로이 에이전트가 배포하는 것까지 만들어 소개했죠.

사람은 시작 쪽만 처리하고 뒤는 에이전트들이 알아서 진행하는 구조였습니다. 요즘은 서브 에이전트가 잘 나와서 너무 당연할 수도 있는데, 그때는 그런 게 없었을 때라 그런 발표를 했던 기억이 있습니다. 실제로 지금도 이렇게 깊게 쓰고 있고요.

다만 여기에는 몇 가지 문제점이 있었습니다. 되게 자율적이고 자동화된 것 같지만, 항상 제가 노트북 앞에 있어야 했어요. 시킨 게 의도대로 진행되지 않거나 방향이 안 맞는 경우, 빨리 취소하고 다른 방향으로 다시 코멘트를 줘야 했거든요. 그러다 보니 여러 터미널이 떠 있을 때 미어캣처럼 터미널들만 쳐다보고 있는 나날들이 있었습니다.

설치 가이드를 안 만들고 간 날, 폰이 절실해졌다

이렇게 매번 노트북 앞에서 에이전트들이 돌아가는 걸 쳐다보고 있어야만 하나, 이런 문제의식을 갖고 있었는데요. 특히 핸드폰으로 이런 것들을 보고 싶다고 절실하게 느꼈던 날이 있습니다.

어느 날 밤새 작업을 하고, 다음 날 아침 제가 만든 라이브러리를 들고 고객사 미팅을 갔는데요. 가면서 아차 싶었던 게, 개발은 열심히 다 해놓고 설치 가이드를 안 만들어 온 걸 그제서야 알았어요. 개발까지 에이전트들이 다 했다면, 문서는 사무실 PC의 에이전트한테 "설치 가이드 만들어줘"라고 한마디만 던지면 되는데, 그날따라 원격도 꺼져 있었고 미팅 시간은 다가오고, 되게 어려운 상황이었죠. 밤새 만들어놓고 정작 다음 날 제대로 하지 못했던 경험이었는데요. 딱 그날이었습니다. '폰에서 명령을 날릴 수 있는 방법을 찾아봐야겠다'고 생각하게 된 날이요.

기존 방법: VPN, 터미널 앱, SSH… 네 단계의 벽

구글이나 SNS에서 폰에서 사용할 수 있는 방법을 찾아보면, 대부분 이런 식으로 가이드를 해주고 있습니다.

VPN 연결: 테일스케일(Tailscale)이나 와이어가드(WireGuard) 같은 도구를 설치해서, 내 PC에 연결하기 위한 VPN을 엽니다.
터미널 앱 설치: 안드로이드냐 iOS냐에 따라 조금 다를 수 있지만, 터먹스(Termux)나 터미너스(Termius) 같은 앱을 설치합니다.
SSH 발급: 앱을 깐 후에 SSH를 발급합니다. 참고로 테일스케일 같은 걸 쓰면 SSH는 자동으로 발급해 주기도 합니다.
연결 유지: 노트북을 닫아도 연결이 유지되도록 하는 도구들을 설치합니다.

이 네 단계를 다 해야만 핸드폰에서 내가 작업하던 클로드 코드에 그대로 연결할 수 있었는데요. 시도해 보신 분들은 알겠지만 5분, 10분 내로 끝나는 작업도 아니고, VPN 연결도 생각보다 빠르지 않고, 세팅하다 보면 삐끗하는 부분이 굉장히 많았습니다. 저도 개발을 오래 해봤지만 이 세팅은 항상 어려웠던 것 같아요.

만족하시는 분들도 있겠지만, 실제로 돌려보면 한글이 잘 안 쳐진다거나, 키보드가 안 올라온다거나, 스크롤이 안 된다거나, 권한이나 포맷이 안 맞아 깨진다거나, 폰이 한 번 잠기면 세션이 끊긴다거나 하는 문제가 있었습니다. 많은 분들이 추천하는 방법이었지만 100% 만족스러운 느낌은 아니었고, 저도 마찬가지였습니다.

그래서 만들었습니다: 설치 한 줄, 명령 하나

그래서 제가 만들었습니다. 세션 캐스트라는 서비스고요. 앞서 있었던 복잡한 단계를 최소화해서, 클로드 코드를 쓰던 그대로, 그게 PC든 핸드폰이든, 내가 하고 있던 작업을 이어서 할 수 있도록 하는 서비스입니다.

물론 저도 설치를 한 번은 해야 합니다. 다만 설치 명령 한 줄만 입력해서 에이전트를 설치하면, 그 뒤부터는 세션 캐스트 명령을 딱 한 번만 날리면 에이전트가 자동으로 올라갑니다. VPN이나 터미널 앱 없이 바로 사용할 수 있어요.

작동 원리: 이미 돌고 있는 세션을 '중계'한다

작동 원리는 생각보다 단순한데요. 크게 세 가지 포인트로 설명드릴 수 있습니다.

우선 여러분의 PC에서 돌고 있는 클로드 코드를 캡처해 오는 CLI 에이전트가 하나 돕니다. 아까 설치하는 코드 한 줄이 그거고요. 요즘 많이 쓰시는 CMUX 같은 도구든, 제가 예전에 발표했던 tmux든, 맥에서 많이 쓰는 iTerm이든, 그런 곳에서 띄운 클로드 코드를 캡처해서 그 내용을 릴레이 서버로 전송합니다. 그러면 여러분이 접속하는 브라우저(PC일 수도, 모바일일 수도 있고, PWA도 지원해서 앱처럼 설치해 쓸 수도 있는데요)에서 릴레이를 통해 PC에서 돌아가고 있는 클로드를 확인하는 겁니다. 반대로 브라우저에서 명령을 날리면, CLI를 통해 여러분의 클로드에 명령을 치거나 프롬프트를 날릴 수도 있는 양방향 통신입니다.

이 중간에서 릴레이 서버가 하는 일을 세 가지로 정리하면 이렇습니다.

세션을 새로 만드는 게 아닙니다. 이미 돌고 있는 tmux나 터미널 툴의 내용을 그대로 확인할 수 있습니다. 흐름을 끊지 않고 옆에서 계속 보는 방식이에요.
명령이 그대로 배달됩니다. 명령을 날리면 지금 여러분의 터미널 툴에 그대로 전달돼서, 세션 캐스트 화면과 터미널에 똑같은 화면이 나옵니다.
보기만 하는 게 아니라 입력도 되는 양방향입니다. 폰에서 한 글자를 입력해도 노트북의 AI에게 그대로 전송됩니다.

로그인은 한 번만 하면 됩니다. 에이전트 설치 후 어떤 곳에서든 한 번만 로그인하면 같은 세션에 접근할 수 있어요. 회사 데스크톱에서 에이전트를 올리면 핸드폰에서 이어서 할 수도 있고, 퇴근해서 집 PC에서도 이어서 할 수 있습니다.

라이프 사이클이 바뀌었다: 자기 전에 던지고, 아침에 확인한다

실제 제 라이프 사이클이 이런 식으로 많이 바뀌었어요. 아침에 일어나거나 출근할 때, 어젯밤에 실행시켰던 게 어디까지 진행됐는지 확인합니다. "진행하시겠습니까?"라는 물음이 나오면 예스를 눌러줘야 하는 경우도 처리하고요. 밥 먹으러 갈 때 주문을 넣기도 하고, 자기 전에 "테스트 돌려줘", "문서 만들어줘", "고객 분석해줘" 같은 걸 하나 딱 날려놓고 자면, 다음 날 아침에 핸드폰으로 확인할 수 있는 거죠.

그런데 여기서부터가 제가 많이 고민했던 내용인데요. 처음에는 답답함을 풀려고 만든 도구인데, 정작 바뀐 건 제가 평소에 에이전트를 부리는 방식 그 자체였어요.

예전에는 노트북을 닫으면 끊길까 봐 긴 작업도 중간에 잠깐 멈춰놓고 나가서 이어서 진행하곤 했는데, 이제는 그냥 노트북을 사무실에 놓고 핸드폰으로 확인하니까, 긴 장시간 작업을 끝까지 돌리면서 볼 수 있게 됐습니다.

특히 최근에는 하네스 같은 무거운 에이전트들이 많이 생겨서 에이전트를 오래 돌려야 하는 경우도 있는데, 그런 것들도 끝까지 지켜볼 수 있었고요. 예전에는 에이전트가 다 돌아갔나 계속 노트북을 확인해야 했는데, 뭐가 끝나면 알림도 와서 그런 것도 줄었습니다. 그리고 병렬로 돌리면서 다양한 에이전트를 더 많이 확인할 수 있게 됐어요. 저는 클로드 코드뿐만 아니라 GLM도 돌리고 제미나이(Gemini)도 돌리는데, 그런 것들까지 함께 어떻게 돌아가고 있는지 확인할 수 있었습니다.

개인 프로젝트의 신뢰성: 프로덕트헌트 16등, 가입자 7,000명

오늘 세션 캐스트라는 서비스를 당장 쓰시라는 얘기는 아니고요. SNS를 보면 아직도 "핸드폰에서 돌리려면 어떻게 해요?"라는 질문이 굉장히 많이 올라오고, 아까 같은 도구들이 소개되곤 하는데, 설치가 어렵다, 한글이 안 된다, 하다가 끊긴다 등 불만이 너무 많으셔서 꼭 한번 소개해 드리고 싶어 들고 왔습니다.

개인 프로젝트여서 과연 신뢰성이 있겠는가 물어보시는 분들도 있어요. 저 같은 경우 스타트업들이 처음 제품을 홍보하는 사이트인 프로덕트헌트(Product Hunt)에 올렸는데, 첫날 16등 정도까지 갔고, 첫날 가입자가 약 1,000명 정도 들어왔습니다.

처음 오픈한 게 명절 전 주였는데, "고향 가실 때 세션 캐스트 켜놓고, 장애가 나면 접속해서 해결하시라"는 마케팅을 조금 했었고요. 오늘 기준으로는 가입자가 7,000명 정도입니다. 다만 라이브로 쓰시는 분은 그렇게 많지 않아서, 지금 가입하시면 무료로 사용하실 수 있습니다.

손바닥 위에서, 하던 작업을 그대로

정리하면, 오늘 보여드린 건 노트북에서 에이전트로 하던 작업을 자리를 떠나서도 핸드폰에서 그대로 이어가는 도구를 만들었던 이야기입니다. 지금 베타 오픈은 거의 끝났고 실 서비스가 되고 있고요. 지금 가입하시면 계속 무료로 사용하실 수 있으니, 관심 있으시면 구글에 세션 캐스트라고 검색해서 한번 사용해 보셔도 좋을 것 같습니다.

오늘 자리가 노트북의 AI를 손바닥 위에서 그대로 이어가시길 원하는 분들에게 도움이 됐으면 좋겠습니다. 발표 마치겠습니다. 감사합니다.

▶발표 영상 유튜브에서 보기

]]>

AI와 200만 줄의 코드를 작성하며 깨달은 것들

저는 25년 경력의 소프트웨어 아키텍트로, 현재 스타트업에서 CTO로 재직 중입니다. 그리고 지난 몇 달간, AI와 단둘이서 200만 줄이 넘는 코드를 짰습니다. 수십 개의 서비스, 여러 개의 AI 에이전트, 여러 개의 모바일 앱까지, 단 몇 시간 만에 서비스가 올라가고, 하룻밤 사이에 API가 생겨났습니다. 코드 리뷰를 하면 구조가 그럴듯했고, 모든 점검을 통과했습니다. 누가 봐도 “제품 출시 준비 완료”처럼 보였죠.

그런데 막상 돌려보니, 단 5분도 자율적으로 작동하지 못했습니다. 여기서 ‘작동한다’는 건 데모가 한 번 돌아간다는 뜻이 아닙니다. 사람이 지켜보지 않아도, 예외와 재시도와 동시 요청 속에서, 의도한 일을 끝까지 같은 결과로 해내는 것이죠. 그게 제가 말하는 ‘작동’입니다. 반대로 ‘껍데기’는 시연에서는 완벽하지만, 그 조건이 조금만 어긋나면 무너지는 결과물이 됐고요.

AI의 속도는 진짜였습니다. 하지만 엔지니어링은 아니었습니다. 이번 글은 ‘AI로 빠르게 만든 결과물이 왜 껍데기가 되는지’, 그리고 ‘AI에게 무엇을 다르게 줘야, 그 껍데기가 진짜가 되는지’에 대한 현장 기록입니다. 제품을 만드는 사람, 그리고 ‘AI를 도입하면 생산성이 오른다’는 말을 믿고, 의사결정을 내려야 하는 분들을 위해 썼습니다.

미리 요점만 콕 집어보면?

AI에게 ‘무엇을(what)’과 ‘어떻게(how)’만 주면, 그럴듯하지만 작동하지 않는 코드가 나옵니다. 빠진 변수는 ‘왜(why)’입니다.
AI의 헛소리(환각)를 막으려고 규칙을 늘리면, 헛소리와 함께 창의성까지 사라집니다. 규칙은 둘을 동시에 누르기 때문입니다.
모델을 바꾸지 않고도, ‘왜’를 담은 맥락만 바꿔주면 같은 AI가 전혀 다른 품질의 결과물을 냅니다. 더 좋은 모델이 아니라 더 좋은 맥락이 필요합니다.

필자의 클로드 작업 창: 보통 맥북에 터미널 4~5개, 맥 미니에 2개 정도 띄워서 작업합니다. <출처: 작가>

빠르게 만든 것의 청구서

처음 몇 달간 저는 AI를 ‘코딩 기계’로 썼습니다. 만들고 싶은 것(명세)과 만드는 방법(패턴, 규칙)을 주면, AI는 놀라운 속도로 코드를 뽑아냈죠. 생산성 지표만 보면 환상적이었습니다. 문제는 그 지표가 거짓말을 하고 있었다는 겁니다.

어느 날, 그동안 만든 AI 에이전트들을 하나하나 점검했습니다. 결과는 충격적이었죠. 운영 검증을 통과한 에이전트가 단 하나도 없었습니다. 전부 같은 증상이었습니다. 인터페이스는 멀쩡한데 속은 비어 있었거든요. 쓰는 쪽(write-side)은 wiring이 돼 있는데, 읽는 쪽(read-side)이 죽어 있었습니다.

이벤트는 발행되는데 구독해서 처리하는 핸들러가 한 번도 트리거되지 않고, 상태 머신에는 어떤 입력으로도 도달할 수 없는 전이(transition)가 그려져 있었습니다. 컴파일은 되고 구조도 그럴듯한데, 정작 런타임에 아무 일도 일어나지 않는 코드였죠. 제가 만들고 있는 플랫폼이 비동기식 분산 시스템을 코어로 삼다 보니 증상이 더욱 심했습니다.

비유하자면 스위치는 다 달려 있는데, 그 어느 것도 전선에 연결돼 있지 않은 집이었죠. 도면상으로는 완공된 주택이고 준공 검사도 통과하는데, 막상 스위치를 올리면 아무 불도 켜지지 않았거든요. 저는 이걸 ‘에이전트 시어터(agent theater)’라고 부릅니다. 무대 세트처럼 정면에서 보면 완벽하지만, 뒤로 돌아가면 합판으로 받쳐둔 가짜 건물 말입니다.

흥미로운 건, 이게 저만의 문제가 아니라는 점입니다. 시장 조사기관 가트너(Gartner)는 2025년 발표에서 “2027년 말까지 기업의 에이전트 AI 프로젝트 40% 이상이 폐기될 것”이라고 예측했습니다. 그 원인으로는 비용 증가, 불명확한 비즈니스 가치, 부족한 위험 통제를 꼽았죠. 같은 발표에서 가트너는 ‘agent washing(에이전트 워싱)’이라는 표현도 썼습니다. 실질적인 자율 기능 없이 기존 챗봇이나, 자동화 도구를 ‘에이전트’라고 재포장하는 관행을 가리키는 말입니다.

제가 현장에서 ‘에이전트 시어터’라 부른 것과, 가트너가 시장에서 ‘agent washing’이라 부른 것은 사실상 같은 현상이었습니다. 그럴듯한 껍데기와 텅 빈 속이었죠. 여기서 한 가지를 짚고 싶습니다. 가트너가 지목한 실패 원인은 ‘AI 모델이 무능해서’가 아니었습니다. AI를 배치하는 사람이 잘못된 결정을 내렸기 때문이었죠. 이 진단은 제 경험과 정확히 일치합니다. 몇 달간의 무대 세트는 AI의 실패가 아니라, 제가 AI에게 무언가를 빠뜨린 결과였으니까요.

빠진 변수는 ‘왜’였다

그 ‘무언가’가 무엇인지 한참을 고민했습니다. 결론은 의외로 단순했는데요.

제가 AI에게 주던 것은 두 가지뿐이었습니다. 하나는 무엇을(what) 만들지, 다른 하나는 어떻게(how) 만들지입니다. 이 둘만 주면 AI는 문법적으로 완벽하고 구조적으로 그럴듯하면서, 기능적으로는 텅 빈 코드를 만들어냅니다.

빠진 것은 왜(why)였습니다. 왜 이 기능은 부분 실패를 견뎌야 하는가, 왜 이 처리 과정은 중간에 끊겨도 다시 시작할 수 있어야 하는가, 왜 이 지점에서 과부하를 막아야 하는가. 이런 ‘왜’가 없으면 AI는 완성도의 ‘실제’가 아니라 완성도의 ‘겉모습’을 향해 달려갑니다.

엔지니어라면 이 대목이 익숙할 겁니다. 신입에게 “이 결제 화면 만들어줘”라고만 하면 화면은 나오지만, 엣지 케이스에서 와르르 무너지죠. “이건 결제 실패 후 재시도 흐름이라, 네트워크가 중간에 끊겨 같은 요청이 두 번 들어와도 결제는 한 번만 일어나야 한다”까지, 즉 멱등성(idempotency)이 왜 필요한지를 말해줘야 비로소 진짜가 됩니다. AI도 똑같았습니다. 다만 AI는 신입보다 백 배 빠르게, 백 배 많은 양의 그럴듯한 껍데기를 만들어낼 뿐이었죠.

AI로 코딩해 보신 분들은 잘 아실 겁니다. 저는 이런 결과물을 ‘이쁜 장난감’이라고 부르기도 합니다. 요새 흔히 얘기하는 바이브 코딩으로 나오는 제품들이 대부분 이런 모습입니다. 데모는 그럴듯한데, 프로덕션에 배포하면 제대로 동작하지 않거나, 버그가 쏟아지는 그런 제품들이죠.

추상적인 이야기로 들릴 수 있으니, 실제 경험 하나를 들려드리겠습니다. 저는 코딩 AI인 클로드 코드(Claude Code)에게 제 작업 환경을 설명하면서, 한 가지 맥락을 덧붙였습니다. “나는 팀이 아니라 혼자 일한다”고요. 단순한 상황 설명 한 줄이었죠.

저는 보통 클로드 코드 터미널을 네다섯 개씩 띄워놓고 병렬로 작업합니다. 처음엔 작업 공간 구조를 여러 저장소로 나눈 멀티 레포로 구성했었는데요. 한 번은 동시에 너무 많은 작업을 벌이다 git이 꼬여버렸습니다. 그래서 클로드 코드에게 한 달 치 작업 히스토리와 git 이력을 분석해 제 개발 패턴을 찾아보게 했죠. 그런데 제 개발 습관을 너무 잘 짚어내서 놀랐습니다.

그 분석을 토대로 클로드 코드는 한 가지를 역제안했습니다. 혼자서도 여러 작업을 병렬로 굴릴 수 있도록, 하나의 저장소를 여러 작업 공간으로 동시에 펼치는 구조(git worktree)로 가자는 것이었죠. 제가 ‘1인 솔로 개발’이라는 맥락을 명시했기에 나온 제안이었습니다. 그냥 “코드를 짜라”고 했다면 나오지 않았을, 제 작업 방식에 꼭 맞는 구조였죠. (덧붙이자면, 여러분도 한 달쯤 개발한 뒤 AI에게 자신의 행동 패턴을 분석시켜 보길 권합니다. 꽤 놀라운 결과가 나올 겁니다.)

그 덕에 저는 터미널 여러 개를 큰 충돌 없이 동시에 띄워 놓고, 각 화면에서 서로 다른 작업을 나란히 진행하게 됐습니다. 혼자라는 제약을 병렬성으로 상쇄하는 셈이었죠. (물론 대가도 있었습니다. 동시에 돌리던 세션들이 같은 작업 공간을 건드리며 충돌해 하루치 작업이 꼬인 적도 있었고, 그 사고 이후 “작업 공간 하나당 작업 줄기 하나”라는 규칙을 못 박았습니다.)

더 흥미로운 건 그 다음이었습니다. 혼자 개발하면 git이 사치처럼 느껴질 때가 있습니다. 되돌릴 일도, 협업할 사람도 없으니 커밋 메시지를 대충 쓰고 싶어지죠. 하지만 이력을 꼬박꼬박 남겨둔 게 뜻밖의 보상으로 돌아왔습니다. 나중에 클로드 코드가 어떤 코드를 고칠 때, git 이력을 뒤져 “이 부분이 과거에 왜 이렇게 바뀌었는지”를 읽고 그 맥락에 맞게 판단하기 시작한 겁니다. 제가 남긴 커밋 이력이 일종의 설계 결정 기록(ADR, Architecture Decision Record)처럼 작동한 거죠. 사람에게 코드 리뷰를 받을 수 없는 1인 개발에서, 과거의 내 결정이 담긴 커밋 이력은 AI에게 또 하나의 ‘왜’가 되어주었습니다.

핵심은 이겁니다. “혼자 일한다”는 맥락 한 줄, 그리고 그 맥락이 쌓인 커밋 이력이 없었다면, AI는 그저 코드만 뱉었을 겁니다. 맥락을 주자, AI는 내가 일하는 방식 자체를 다시 설계하고, 내 과거 판단까지 읽어내기 시작했습니다.

규칙을 늘릴수록 AI는 멍청해졌다

처음 개발할 때는 가장 상식적인 개발 가이드만 내렸습니다. 규칙을 늘렸죠. “이렇게 해라, 저렇게 하지 마라, 이 패턴을 따라라.”

절반은 맞았습니다. 헛소리는 줄었거든요. 그런데 예상 못 한 일이 벌어졌습니다. 규칙을 잔뜩 걸어둔 영역에서, AI가 다른 곳에선 우아하게 풀던 문제를 갑자기 풀지 못하기 시작한 겁니다. 규칙이 거의 없던 영역에서는 제가 생각지도 못한 방식으로 멋지게 해결하던 그 AI가요.

이유를 깨닫는 데는 시간이 좀 걸렸습니다. AI의 ‘환각’과 ‘창의성’은 같은 뿌리에서 나옵니다. 내가 생각 못 한 구조를 제안하는 능력과 그럴듯하지만 작동 안 하는 코드를 쏟아내는 성향은 정확히 같은 생성 메커니즘의 양면이죠. 그래서 규칙으로 출력 공간을 좁히면 헛소리가 나올 자리도 막히지만, 좋은 아이디어가 나올 자리도 똑같이 막힙니다. 규칙은 대칭적이라, 한쪽만 골라 누를 수가 없거든요.

제가 규칙으로 만든 것은 헛소리는 안 하지만 똑똑하지도 않은, 그냥 빠른 코딩 기계였습니다. 환각을 잡으려다 AI와 일할 이유 자체를 죽인 셈이죠.

모델이 아니라 맥락을 바꾸다

돌파구는 엉뚱한 데서 나왔습니다. 규칙을 더 거는 대신, ‘왜’를 담은 문서를 한 편 써서 AI의 작업 컨텍스트에 상시 물려둔 겁니다. 요즘 많이들 쓰는 규칙 파일과 형식은 비슷하지만, 담는 내용이 달랐습니다. ‘이렇게 짜라’는 코딩 컨벤션이 아니라, 코드는 한 줄도 없이 오직 판단 기준만 담았습니다. “이 영역에서 ‘작동한다’는 것은 무엇을 의미하는가”, “무엇을 절대 해서는 안 되는가” 같은 것들이요.

결과는 분명했습니다. 같은 모델, 같은 코드베이스, 같은 개발자였는데 결과물의 품질이 달라졌습니다. 파인튜닝도, 모델 업그레이드도 없었습니다. 가중치(weight)는 단 하나도 바뀌지 않았죠. 바뀐 건 오직 추론 시점(inference time)에 모델이 참조하는 컨텍스트뿐이었습니다. 일종의 소프트 파인튜닝이었던 셈입니다. 학습 파이프라인 없이 즉시 적용되고, 컨텍스트를 빼면 효과도 사라지고, 영역마다 다른 문서를 끼울 수 있는 거죠.

핵심은 이겁니다. 규칙이 “헛소리하지 마”라고 출력을 제약하는 것이라면, ‘왜’는 “네가 만든 게 진짜인지 이렇게 판단해 봐”라고 분별의 기준을 쥐여주는 것이었습니다. 전자는 창의성까지 빼앗지만, 후자는 창의성을 남겨둔 채 분별력만 더합니다.

비유하자면 규칙은 드레스 코드입니다. “파란 셔츠를 입어라.” 나쁜 선택도 창의적인 선택도 똑같이 사라집니다. 반면 ‘왜’는 안목입니다. “네 옷차림은 고객에게 신뢰감을 줘야 한다.” 목적에 맞기만 하면 참신한 선택이 살아남죠. 그 뒤로 AI는 여전히 새로운 구조를 제안했지만, 아무것도 처리하지 않는 껍데기 처리기는 더 이상 만들지 않았습니다. ‘왜’가 “아무것도 안 함”을 눈에 보이는 실패로 만들어줬으니까요.

이것의 의미는 더 좋은 모델을 기다릴 필요가 없다는 겁니다. 필요한 건 더 좋은 맥락이고, 그 맥락의 핵심은 ‘왜’입니다. 그리고 ‘왜’는 도구를 새로 사거나, 예산을 더 태운다고 생기지 않습니다. 그 도메인을 깊이 아는 사람의 머릿속에서 나오죠.

구체적으로 어떤 ‘왜’를 적었는지 하나만 예로 들어보겠습니다. 제 철학 문서에는 이런 원칙이 있습니다. “혼자 운영하는 시스템은, 팀이 운영하는 시스템보다 더 엄격해야 한다.”

얼핏 반대처럼 들립니다. 1인 솔로 개발이니 적당히, 간단하게 가야 할 것 같죠. 하지만 팀에는 사람으로 이뤄진 안전망이 있습니다. 동료가 코드 리뷰에서 잘못된 설정값을 잡아내고, 누군가 배포 전에 스테이징에서 한 번 더 확인하고, 새벽에 프로세스가 폭주하면 온콜 담당자가 달려갑니다. 혼자라면 이 그물망이 통째로 없습니다. 잘못된 환경 변수를 잡아줄 리뷰어도, 무한 루프에 빠진 워커를 새벽에 조치해 줄 사람도 없죠.

그래서 저는 문서에 못 박았습니다. 사람이 메워주던 자리를 시스템이 대신 메우도록, 가드레일은 더 촘촘하게, 킬스위치는 모든 장기 실행 작업에 빠짐없이, 배포에는 반드시 롤백 레시피를 미리 붙였죠. 줄여야 하는 건 시스템의 엄격함이 아니라, ‘여러 명이 일할 때만 필요한 의식(ceremony)’, 멀티 환경 승인 체인이나 스프린트 의례 같은 것들이었습니다. 이런 판단들이 코드 한 줄 없는 문서에 쌓였고, AI는 그 ‘왜’를 읽고 나서야 비로소 무엇이 진짜 위험인지 알아보기 시작했습니다.

CI/CD 파이프라인 자동화를 위해 별도 프로젝트를 만들어서 작업합니다. <출처: 작가>

세 가지 힘의 줄다리기: CHP(Creative-Hallucination-Principles)

이쯤에서 제가 겪은 걸 한 장의 그림으로 정리해 보겠습니다. AI와 일하다 보면 세 가지 힘이 늘 맞물려 움직입니다. 첫째는 창의성(Creative)입니다. 제가 생각지도 못한 구조나 해법을 내놓는 힘이죠. 둘째는 환각(Hallucination)입니다. 그럴듯하지만 작동하지 않는 결과물을 내놓는 성향이고요. 셋째는 원칙(Principles)입니다. 규칙과 가이드로 출력을 묶는 제약입니다. 저는 이 셋의 줄다리기를 머리글자를 따 CHP라고 부릅니다.

핵심은, 이 세 가지를 동시에 다 가질 수 없다는 겁니다. 설계를 좀 해보신 분들은 트레이드오프(tradeoff)라는 단어를 많이 들어 보셨을 겁니다. 개발하다 보면 어느 한쪽을 택하고, 다른 한쪽을 포기해야 하는 일이 늘 생기죠. 창의성을 풀어주면 환각이 같이 따라옵니다. 앞서 말했듯 둘은 같은 뿌리에서 나오니까요. 그렇다고 원칙으로 꽉 묶으면 이번엔 환각과 함께 창의성까지 죽습니다. 규칙은 대칭적이라 한쪽만 누를 수 없거든요. 결국 한쪽을 당기면 다른 쪽이 끌려오는, 삼각형의 줄다리기인 셈입니다.

제가 찾은 ‘왜’는 이 삼각형에서 유일한 우회로였습니다. 원칙처럼 환각은 누르되, 창의성은 건드리지 않는 길. 출력을 막는 대신 분별의 기준을 주기 때문에 가능한 일이었죠. 그런데 이 우회로를 쓰더라도, 창의성과 원칙의 적절한 균형점은 무엇을 만드느냐에 따라 달라집니다. 그래서 CHP는 하나의 고정된 설정이 아니라, 영역마다 다시 맞추는 ‘다이얼’이 됩니다.

다이얼은 영역마다 다르게

그렇다면 이 다이얼을 실제로 어떻게 돌릴까요? 모든 영역에 ‘왜’만 잔뜩 주거나, 모든 영역에 창의성을 똑같이 풀어주는 게 정답은 아닙니다. 제가 찾은 답은, 창의성과 원칙의 균형을 만드는 제품마다 다르게 맞춰야 한다는 것이죠.

프론트엔드나 UX처럼 시각적 혁신이 중요하고 실패해도, 즉시 눈에 보이며 롤백이 싼 영역은 창의성 쪽으로 다이얼을 한껏 돌립니다. 반대로 메시지 브로커나 데이터 파이프라인, 인프라처럼 신뢰성이 생명인 영역은 원칙 쪽으로 끝까지 돌리죠. 메시지 브로커에서의 창의성은 그냥 장애니까요. 통신 프로토콜을 구현하는 영역이라면 더합니다. 거기서의 창의성은 곧 규격 위반이거든요. 가장 까다로운 건 그 중간, 자율적으로 판단하되 엄격한 운영 경계 안에 머물러야 하는 영역입니다. 에이전트가 바로 여기에 속하죠.

그리고 여기서 깨달았습니다. 혼자서 AI와 일하는 사람의 진짜 병목은 코드를 짜는 것도, 시스템을 설계하는 것도 아니었습니다. 이 다이얼을 모든 영역에서 동시에, 매번 다시 맞추는 일이었죠. 아침엔 프론트엔드를 보며 “더 과감하게”, 점심엔 프로토콜 핸들러를 보며, “한 바이트도 규격에서 벗어나지 마”, 오후엔 에이전트 로직을 보며 “창의적으로 풀되 안전 경계는 넘지 마”. 이 사이를 오가며 머릿속 다이얼을 매번 다시 세팅하는 게 진짜 노동이었습니다.

역설적이게도 이 노동은 AI가 똑똑해질수록 줄지 않고 늘어납니다. 유능한 AI일수록 더 그럴듯한 선택지를 더 많이 쏟아내고, 그걸 분별하려면 더 정교한 판단이 필요하니까요.

클로드 코워크로 QA 테스트 에이전트를 만들어 테스트를 자동화했습니다. <출처: 작가>

마치며: AI는 거울이다

돌이켜보면 처음의 제 실수는 질문이 틀린 데 있었습니다. 저는 “어떻게 AI가 헛소리를 덜 하게 만들까”를 물었죠. 진짜 질문은 “어떻게 AI가 헛소리와 좋은 아이디어를 스스로 구분하게 할까”였어야 했습니다. 규칙으로 입을 막으면 둘 다 사라집니다. ‘왜’라는 판단 근거를 쥐여주면, AI는 비로소 자기 결과물을 스스로 평가하기 시작합니다. 창의성은 살리고 헛것만 걸러내는 길은 더 많은 규칙이 아니라, 더 분명한 ‘왜’에 있었습니다.

이 경험은 AI와 일하는 방식에 대한 제 생각을 바꿔놓았는데요. AI는 자신에게 주어진 맥락을 거울처럼 비춥니다. 제가 명확한 ‘왜’를 주면 그 명확함을 비추고, 모호한 채로 두면 그 모호함을 그대로 증폭해 비춥니다. 몇 달간의 무대 세트는 AI가 제 의도를 구현하는 데 실패한 게 아니라, 검증되지 않은 제 생각을 완벽한 충실도로 구현해 낸 결과였습니다.

그래서 AI 도입을 고민하는 분들께 드리고 싶은 말은 더 좋은 모델이나, 더 많은 예산을 먼저 떠올리기 전에 이 질문에 답할 수 있는지 보라는 겁니다. 나는 이것을 왜 만드는가, 이 결정이 왜 옳은가, 이 실패가 왜 용납될 수 없는가. 가트너가 40%의 프로젝트가 폐기될 거라 본 이유, 그리고 그 실패가 모델이 아니라 사람의 결정에서 온다고 본 이유가 바로 여기에 있거든요.

이 ‘왜’에 답할 수 있다면 AI는 놀라운 역량의 파트너가 됩니다. 답하지 못하면, 빠르고 그럴듯하지만 텅 빈 무대 세트를 짓게 되죠. 결국 코딩 기계의 함정은 AI의 한계가 아니란 사실을, 이번 글을 통해 한 번 더 전하고 싶었습니다.

]]>

바이브 코딩을 하기 전에 꼭 알아야 할 7가지 개념 정리

바이브 코딩으로 무언가를 만들다 보면 누구나 한 번쯤 비슷한 순간을 만납니다. "AI가 자신 있게 알려준 대로 했는데 왜 안 되지?", "분명 잘 되던 화면이 수정 한 번에 망가졌는데 되돌릴 방법이 없네?", "내 컴퓨터에선 멀쩡한데 다른 사람 폰에선 왜 안 보이지?" 같은 질문들입니다. 이런 막힘은 대부분 '코딩 실력'이 부족해서가 아니라, 몇 가지 기본 개념을 몰라서 생깁니다.

지난 글 ‘바이브 코딩으로 나만의 프로필 링크 페이지 만들기’에서 프로필 링크 페이지를 직접 만들어보며, 저는 바로 그 '기본 개념'이 필요한 자리를 확인할 수 있었습니다. 그래서 이번 글에서는 개발자인 제가 직접 부딪혀보며 추린, 비전공자가 바이브 코딩 전에 최소한 알아두면 좋은 개념 일곱 가지를 정리해 봤습니다. 어디서 막힘이 생기는지, 왜 알아두면 좋은지를 함께 살펴보겠습니다.

미리 요점만 콕 집어보면?

AI는 확률 기반 생성이라 항상 옳다고 보장할 수 없으며, 결과를 직접 실행·검증하고 최종 판단은 사람이 맡아야 합니다.
프롬프트를 구체적으로 나누어 요청하고, HTML·CSS·JavaScript·터미널·컨텍스트를 이해하면 수정과 문제 해결이 훨씬 쉬워집니다.
Git으로 되돌릴 수 있는 저장 지점을 만들고, 로컬과 배포의 차이를 이해해야 바이브 코딩 결과물을 안정적으로 완성·공유할 수 있습니다.

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

AI는 만능이 아닙니다

AI를 잘 활용하기 위해 가장 먼저 이해해야 할 것은, AI가 '정답을 아는 존재'가 아니라는 점입니다.

1) 확률 기반 생성의 한계

우리가 쓰는 AI(LLM)는 방대한 글을 학습한 뒤, 어떤 단어 다음에 어떤 단어가 올 확률이 높은지를 계산해 문장을 한 단어씩 생성합니다. 내용을 이해해서 답한다기보다, 가장 그럴듯한 말을 이어 붙이는 방식에 가깝습니다. 그래서 존재하지 않는 기능이나 사실과 다른 정보를 자신 있게 내놓기도 하는데, 이를 '환각(할루시네이션)'이라고 부릅니다. 다만 'AI는 자주 틀린다'는 뜻으로 받아들이면 오해가 생길 수 있습니다. 대체로 꽤 정확하지만 '항상 옳다고 보장할 수는 없다'는 쪽이 더 정확한 표현입니다. 문제는 그 '틀릴 수 있는 부분'이 겉보기에는 멀쩡한 문장 속에 섞여 있다는 점입니다. 그래서 결과를 눈으로만 훑고 넘어가면 놓치기 쉽습니다. 중요한 부분일수록 AI의 답을 한 번 더 의심하고 직접 확인하는 편이 안전합니다.

2) 왜 알아야 할까요?

이 원리를 알면 AI의 답을 결과로 검증하는 습관이 생기기 때문입니다. 코드를 실제로 실행해보고 의도대로 동작하는지 확인하는 과정이 자연스럽게 따라옵니다. AI를 유능한 조수로 활용하되 최종 판단은 사람이 맡는다는 태도, 그것이 바이브 코딩의 출발점입니다. 반대로 이 전제를 모르면 그럴듯해 보이는 답을 그대로 받아들였다가, 한참 뒤에야 문제를 발견하게 됩니다.

프롬프트 작성법

같은 AI라도 어떻게 요청하느냐에 따라 결과물의 질이 크게 달라집니다. 핵심은 두 가지입니다.

1) 구체적으로 말할수록 결과가 달라진다

"예쁘게 만들어줘" 같은 막연한 요청은 AI가 의도를 짐작하게 만듭니다. 반면 "카드를 흰 박스로, 모서리는 둥글게, 글씨는 가운데 정렬"처럼 원하는 모습을 구체적으로 적으면 결과가 의도에 훨씬 가까워집니다. 사람에게 일을 맡길 때와 같은 원리로, 조건이 분명할수록 결과도 정확해집니다. 모호한 표현 하나가 전혀 다른 결과를 부르기도 하므로, 구체성은 곧 시간 절약으로 이어집니다. 원하는 결과의 예시나 참고할 대상을 함께 제시하면, AI가 방향을 잡기가 한결 쉬워집니다.

2) 작게 나눠서 요청하기

한 번에 여러 가지를 요청하면 어디서 어긋났는지 파악하기 어렵습니다. "먼저 배경색", 그 다음 "버튼 그림자"처럼 단계를 나눠 요청하고 확인하면, 문제가 생겨도 원인을 빠르게 좁힐 수 있습니다. 단계를 쪼개면 매 단계의 결과를 눈으로 확인하게 되어, 잘못된 방향으로 멀리 가기 전에 바로잡을 수 있습니다.

3) 왜 알아야 할까요?

프롬프트를 다루는 법은 비전공자가 AI를 쓰며 가장 즉각적으로 효과를 보는 기술이기 때문입니다. 잘 정리된 요청 하나가 수십 번의 시행착오를 줄여줍니다. 나아가 잘 만든 요청을 문서로 남겨 재사용하면, 비슷한 작업마다 같은 품질을 더 빠르게 얻을 수 있습니다.

웹 페이지의 구조 이해하기

웹 페이지가 무엇으로 이루어지는지 큰 그림만 알아도, AI에게 건네는 요청이 한층 정확해집니다.

1) 세 가지 역할 구분하기

웹 페이지는 크게 세 요소로 구성됩니다. HTML은 뼈대(구조), CSS는 디자인, JavaScript는 동작인데요. 글의 내용과 배치는 HTML이, 색·크기·여백 같은 꾸밈은 CSS가, 버튼 클릭 같은 움직임은 JavaScript가 담당합니다. 집에 비유하면 HTML은 골조, CSS는 인테리어, JavaScript는 전등을 켜고 문을 여는 기능에 해당합니다. 세 가지가 각자 맡은 일을 나눠 하나의 화면을 완성하는 구조입니다.

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

2) 왜 알아야 할까요?

세 역할을 구분할 수 있으면 수정 요청이 정확해집니다. "글씨가 작다"는 막연한 말 대신 "글씨 크기(CSS)를 키워달라"고 하면, AI가 손볼 영역이 분명해집니다. 용어를 외울 필요는 없고, '구조·디자인·동작'이라는 세 갈래가 있다는 감각만으로 충분합니다. 이 감각이 있으면 AI가 내놓은 결과물을 받아, 어느 부분을 어떻게 고쳐야 할지도 스스로 가늠할 수 있습니다. 막연한 요청과 구체적인 요청의 차이도, 바로 이 구분에서 시작됩니다.

터미널 활용하기

검은 화면 때문에 어렵게 느껴지지만, 실제로 필요한 것은 많지 않습니다.

<출처: 위키백과>

1) 알아야 하는 최소한의 명령어

터미널은 명령어를 입력해 컴퓨터에 지시를 내리는 창입니다. 폴더로 이동하는 cd, 폴더 안의 파일을 확인하는 ls 정도면 AI가 안내하는 과정을 따라가기에 충분합니다. 한 가지, 터미널은 '현재 위치한 폴더'를 기준으로 동작하므로, 작업을 시작하기 전에 위치를 한 번 확인해두면 파일이 엉뚱한 곳에 생기는 일을 줄일 수 있습니다. 이 작은 습관만으로도 초반에 겪는 혼란의 상당 부분을 피할 수 있습니다.

2) 왜 알아야 할까요?

바이브 코딩 도구의 상당수가 터미널 위에서 동작하기 때문입니다. 명령어를 외우기보다, 모르는 명령이 나왔을 때 그 자리에서 AI에게 의미를 물어보는 편이 더 효율적입니다. 한번 익숙해지면, 같은 작업도 마우스로 메뉴를 찾는 것보다 빠르고 정확하게 처리할 수 있습니다. 결국 터미널은 ‘넘어야 할 벽’이라기보다, 익숙해지면 작업 속도를 높여 주는 도구에 가깝습니다.

컨텍스트

AI와 대화가 길어지면, 앞서 정한 내용을 잊은 듯 행동하는 순간이 옵니다. 이는 AI가 기억하는 방식과 관련이 있습니다.

1) 컨텍스트 윈도우의 존재

AI가 한 번에 참고할 수 있는 대화의 양에는 한계가 있고, 이 범위를 '컨텍스트 윈도우'라고 부릅니다. 대화가 길어질수록 초반에 정한 규칙이나 설정이 이 범위 밖으로 밀려나면서 흐려질 수 있습니다. 예를 들어 처음에 '버튼 색은 파란색'이라고 정해두었는데, 한참 뒤에는 다른 색으로 바뀌어 있는 식입니다.

2) AI의 기억을 도와주는 방법

그래서 중요한 요구사항은 다시 정리해 알려주거나, 파일로 정리해 통째로 전달하는 방식이 유용합니다. 지난 글에서 다룬 prompt.md에 요구사항을 적어 @prompt.md로 불러오는 방법이 그 대표적인 예입니다. 요구사항이 문서로 남아 있으면, 대화가 아무리 길어져도 같은 기준을 반복해서 일러줄 수 있다는 점이 든든합니다.

3) 왜 알아야 할까요?

AI가 갑자기 엉뚱하게 동작할 때, 그것이 ‘오류’가 아니라 ‘기억의 한계’ 때문임을 알면 대응이 달라집니다. 핵심 규칙을 간단히 다시 짚어주는 것만으로 결과가 안정되는 경우가 많습니다. 원인을 알면 대응법은 의외로 단순해집니다.

버전 관리

AI는 코드를 한 번에 크게 바꾸기도 합니다. 그래서 언제든 되돌릴 수 있는 안전장치가 중요해집니다.

1) 저장과 되돌리기의 개념

Git은 작업 내용을 단계별로 저장해두고, 필요할 때 과거 시점으로 되돌릴 수 있게 해주는 도구입니다. 게임의 세이브 포인트와 비슷합니다. 잘 동작하던 상태를 저장해두면, 이후 수정이 잘못되더라도 그 지점으로 안전하게 복귀할 수 있습니다. 한 줄 한 줄 직접 백업하지 않아도, 도구가 그 기록을 대신 관리해 줍니다.

2) 버전 관리 없는 바이브 코딩의 위험

저장 지점이 없는 상태에서 AI가 멀쩡하던 부분까지 바꿔버리면, 되돌릴 방법이 없어 처음부터 다시 작업해야 할 수 있습니다. 작업 규모가 커질수록 이 위험은 빠르게 커집니다. 특히 한 번에 여러 파일을 동시에 바꾸는 작업일수록, 저장 지점이 있고 없고의 차이가 결정적입니다.

3) 왜 알아야 할까요?

모든 명령어를 익힐 필요는 없습니다. "지금 상태를 저장", "이전으로 되돌리기" 정도를 AI에게 맡길 수 있다는 것만 알아도, 더 과감하게 시도할 수 있는 여유가 생깁니다. 되돌릴 수 있다는 사실 하나가, 새로운 시도의 부담을 크게 덜어 줍니다.

배포하기

다 만들어도 내 컴퓨터 안에만 있으면 다른 사람은 볼 수 없습니다. 그 마지막 단계가 배포입니다.

1) 로컬과 배포의 차이

내 컴퓨터에서만 열리는 상태를 '로컬', 인터넷에 올려 누구나 접속할 수 있게 만드는 것을 '배포'라고 합니다. 배포를 하면 '서버'가 페이지를 대신 보관합니다. 서버는 인터넷에 연결된 컴퓨터라고 이해하면 충분한데, 누군가 주소로 접속하면 서버가 저장된 파일을 전달해 화면을 띄워줍니다. 그래서 내 컴퓨터를 꺼도 페이지는 유지되고, 어떤 기기에서든 같은 주소로 접속할 수 있습니다. 덕분에 완성한 결과물을 주소 하나로 어디서든 보여줄 수 있게 됩니다. 배포 이후에는 수정한 내용을 다시 올리기만 하면 모두에게 곧바로 반영된다는 점도 편리합니다.

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

2) 왜 알아야 할까요?

'내 화면에서 되는 것'과 '모두에게 공개된 것'은 다르기 때문입니다. 이 차이를 이해하면 "왜 다른 기기에서는 안 보이지?" 같은 상황을 파악하고, 완성한 결과물을 실제로 공유할 수 있습니다. 직접 만든 결과물을 누군가에게 보여줄 수 있다는 점은, 다음 작업을 이어갈 좋은 동기가 되기도 합니다.

마치며

지금까지 일곱 가지 개념을 살펴봤습니다. 정리하고 보면 바이브 코딩은 '코딩을 대신해 주는 마법'이라기보단, '코딩의 진입 장벽을 낮춰주는 도구'에 가깝습니다. AI가 코드를 만들어주더라도, 그 결과가 적절한지 판단하고 방향을 정하는 일은 여전히 사람의 몫이기 때문입니다. 도구가 아무리 똑똑해져도, 그 도구를 어디로 끌고 갈지는 사람이 정해야 하는 영역입니다.

그래서 이 개념들은 'AI 시대에 필요 없어진 지식'이 아니라, 오히려 'AI를 제대로 활용하기 위해 더 챙겨두면 좋은 기본기'에 가깝습니다. 오늘 다룬 일곱 가지를 큰 그림으로 이해해 두면, 바이브 코딩을 처음 시작하는 분도 같은 자리에서 덜 막히고, 막히더라도 원인을 한결 빠르게 좁힐 수 있을 겁니다.

결국 중요한 것은 모든 것을 미리 통달하는 일이 아니라, 막혔을 때 '어디를 봐야 할지' 아는 감각인데요. 그 감각은 한 번에 완성되지 않지만, 직접 만들어보는 경험 속에서 분명히 자랍니다. 그 출발점은 거창한 학습이 아니라, 오늘 살펴본 개념들을 한 번씩 떠올려 보는 작은 습관 아닐까요?

<참고>

바이브 코딩 핸드북

]]>

클로드 코드에서 스킬을 묶어 워크플로우 자동화하기

지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나의 세 번째 발표였던 '스킬을 다루는 스킬'입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 저는 스킬을 묶어서 워크플로우를 자동화하는 방법에 대해 발표할 프리랜서 개발자 김규동입니다. 저는 대학교 재학 중에 3인 팀으로 외국인 유학생을 위한 앱을 만들었고, 졸업 후에 그 앱을 유지 보수하면서 클로드 코드와 코덱스를 활용해 매주 개발을 하고 있습니다. 그 과정에서 스킬을 직접 만들고 관리하며, 얻은 경험들을 공유하고자 합니다.

첫 번째로 스킬을 생성, 조회, 수정, 삭제하는 기본적인 관리법에 대해 설명드리고, 두 번째로 자주 반복되는 스킬들을 하나의 마스터 스킬로 묶어 워크플로우를 자동화하는 방법에 대해 발표하겠습니다.

스킬은 '투창'이다: 긴 프롬프트를 한 단어로

우선 스킬(Skill)이 무엇인지부터 정리하겠습니다. 클로드 코드 공식 문서에 따르면, 스킬은 지침, 지식, 또는 클로드의 도구 키트에 추가하는 워크플로우를 포함하는 SKILL.md 파일입니다. 사실 저는 이 정의만으로는 잘 이해가 되지 않았습니다.

그래서 스킬을 사용하면서 제가 느낀 스킬의 정의는 다음과 같습니다. 저는 게임 스킬로 비유해서 이해했습니다. '적에게 창을 던져 물리 피해를 입힙니다'라는 게임 스킬이 있다고 해보죠. 이 게임 스킬을 클로드 코드에서 사용한다면, 프롬프트로 "적에게 창을 던져 물리 피해를 입힙니다"라고 적을 수 있습니다. 게임에서 스킬을 사용할 때마다 매번 모든 스킬 설명을 말하면 힘드니까 짧게 '투창'이라고 줄여서 사용하듯이, 매번 긴 프롬프트를 입력하는 대신 '스피어샷'이라는 한 단어만 입력해도 동일한 결과가 나오게 만드는 것. 저는 스킬을 이렇게 이해했습니다.

스킬 크리에이터로 만들고, 검증까지 한다

다음으로 스킬을 만드는 방법입니다. 스킬을 만들 때 그냥 "OO 스킬 만들어줘"라고 해도 클로드가 잘 만들어주지만, 품질을 위해 추천하는 도구가 있습니다. 앤트로픽에서 만든 공식 플러그인인‘스킬 크리에이터(Skill Creator)’입니다. 만약 이 플러그인이 설치되지 않았다면, 클로드 코드에게 "앤트로픽 공식 플러그인인 스킬 크리에이터 설치해줘"라고 하면 잘 설치해 줄 겁니다.

기존에는 그냥 스킬을 만들어달라고 하면 스킬 만들고 끝이고, 나중에 그 스킬을 사용했을 때 원하지 않는 결과가 나온 경우가 있었습니다. 하지만 이 플러그인을 이용해 "OO 스킬 만들어줘"라고 요청하면 제 요구 사항에 대한 인터뷰가 진행됩니다. 그리고 서브 에이전트들을 이용해 스킬을 사용한 에이전트와 사용하지 않은 에이전트를 병렬로 돌려서, 그 스킬을 사용했을 때와 사용하지 않았을 때를 비교해 줍니다. 그래서 만들어진 스킬이 정말 의미 있는지 확인할 수 있습니다.

안 쓰는 스킬은 과감히 정리할 것

이렇게 스킬을 여러 개 만들어두고 쓰게 되면, 사실 만들어 두고 쓰지 않는 스킬들도 꽤 많이 쌓입니다. 그럴 땐 "스킬 사용 횟수를 출력해줘"라고 클로드 코드에 입력하면, 내가 가진 스킬들이 각각 몇 번 호출됐는지 확인할 수 있습니다. 이 중에서 쓰지 않는 스킬들은 과감히 정리하는 것이 좋습니다.

토큰이 낭비됩니다. 클로드 코드를 실행할 때 쓰지 않는 스킬까지 전부 컨텍스트에 포함되기 때문입니다.
비슷한 스킬이 여러 개 있으면 AI가 어떤 걸 써야 할지 혼동합니다. 예를 들어 제가 "코드베이스를 파악해줘"라고 입력했을 때, 익스플로어(Explore)라는 기본 스킬도 있고 제가 따로 만든 '코드베이스 분석'이라는 스킬도 있다면, 클로드는 둘 중 어떤 걸 써야 할지 매번 다른 선택을 할 수 있습니다. 어떤 날은 익스플로어로, 어떤 날은 제가 만든 스킬로요. 그러면 같은 프롬프트를 넣어도 결과 품질이 매번 달라질 수 있습니다.

그러므로 쓰지 않는 스킬들은 자주 정리하는 것이 좋습니다.

"한 번에 다 해줘"의 배신: 했다고 보고하지만, 안 했다

저도 반복되는 작업이 많아서 여러 스킬을 만들어 쓰고 있습니다. 예를 들어, 회의 후 회의록을 작성하는 스킬도 만들었고, 팀 일정 관리에 리니어(Linear)를 사용하는데 회의록 기반으로 리니어에 이슈를 등록하는 스킬도 있습니다. 랄프 플랜(ralph-plan), 랄프(ralph)처럼 '오 마이 클로드 코드(oh-my-claude-code)' 플러그인에 들어있는 스킬들도 자주 사용합니다. 이 플러그인도 굉장히 유용하니 설치해서 사용하시길 추천드립니다.

이렇게 쓰다 보니 제 스킬 사용에도 어느 정도 패턴이 생겼습니다. 그러다 보니 매번 "회의록 작성해줘", "리니어 이슈 만들어줘"라고 부르기보다는, 그냥 "한 번에 다 해줘"라고 클로드에게 시키게 됐습니다.

그런데 이렇게 한 번에 많이 시키면, 클로드는 다 했다고 보고는 하지만 실제로는 리니어에 이슈가 안 들어가 있거나, 구현 완료라고 했는데 계획 문서 대비 기능이 누락된 부분이 되게 많았습니다. 실제 사례로, 클로드는 "이슈 등록 완료했습니다"라고 보고하지만 실제로는 등록이 안 됐고, "리니어에 안 들어왔는데?"라고 하면 "아, 죄송합니다" 하는 식으로, 안 했는데 했다고 보고하는 환각이 자주 발생했습니다. "한 번에 해줘"라고 프롬프트를 넣으면 실수가 잦았고, 특히 매번 이렇게 프롬프트를 입력하는 것도 너무 귀찮았습니다.

그래서 이렇게 매번 길게 프롬프트를 쳐야 하고 자주 반복되는 작업이라면, 이런 것들도 스킬로 묶을 수 있지 않을까? 생각하게 됐죠.

메이플스토리 매크로처럼: 스킬을 묶는 '마스터 스킬'

메이플스토리에는 기존 스킬들을 1번, 2번, 3번 칸에 묶어 매크로 스킬 하나로 여러 스킬을 실행하게 하는 기능이 있습니다. 이것처럼 저도 가지고 있는 스킬들을 묶어보면 어떨까 하고, 앞서 말씀드린 스킬 크리에이터 플러그인을 이용해 묶어봤습니다.

제가 묶어본 스킬은 이렇습니다. 우선 draw.io 그림을 그려주는, 제가 만든 스킬이 있습니다. 슬라이드를 주고 "그림으로 만들어줘"라고 하면 다이어그램이 나옵니다. 두 번째로 가끔 카드 뉴스를 만들 일이 있어서 카드 뉴스를 생성하는 스킬도 있습니다. 마찬가지로 "이 슬라이드를 카드 뉴스로 만들어줘"라고 하면 카드 뉴스가 생깁니다.

이 두 스킬을 하나의 스킬로 감싸는 과정은 이렇게 진행됩니다. 스킬 크리에이터를 사용하면 처음에 인터뷰가 진행되는데요. 이 인터뷰를 통해 본인의 요구사항을 상세히 정리할 수 있습니다. 요구사항이 정리된 뒤에는 스킬을 사용하는 에이전트와 사용하지 않는 에이전트를 서브 에이전트로 각각 돌립니다.

이제는 클로드 코드가 업데이트돼서 서브 에이전트들이 어떻게 활동하고 있는지도 확인할 수 있습니다. 각 서브 에이전트의 작업이 끝나면 결과에 대한 평가도 진행되고, 평가가 끝나면 클로드 코드가 자동으로 HTML 파일을 만들어 결과를 띄워줍니다. 이 결과를 보고 피드백이 있다면 피드백을 작성하고, 없다면 제출 버튼으로 제출하면 스킬 생성이 완료됩니다.

2~3일 걸리던 일이 6시간으로: 걱정이 사라졌다

이렇게 여러 스킬을 묶는 스킬을 '마스터 스킬'이라고 부른다면, 저는 마스터 스킬을 사용하면서 지시사항이 누락되는 경우가 크게 줄었다고 느꼈습니다. 자연스레 스킬의 정확도가 높아졌고, 매번 "이거 했었나? 빼먹은 거 없나? 클로드야 잘했어?" 이렇게 감독할 필요가 줄어들어서 일에 대한 집중도가 많이 높아졌습니다.

AI를 사용하기 전의 저와 지금의 저를 비교하면, 정말 생산성이 10배 정도 차이 나는 것 같습니다. 실제로 이전에는 회의록 작성부터 PR 생성까지 2~3일 정도 걸리던 일이, 마스터 스킬로 워크플로우를 고정하고 나니 6시간 만에 끝났거든요. 이 과정에서 '다음에 뭐 해야지', '빼먹은 거 없나?'라는 걱정 자체가 사라졌습니다.

게다가 단순히 일하는 시간만 줄어든 게 아니라 집중력이 많이 남게 됐습니다. 그 남은 집중력으로 제가 진짜 집중해야 할 것들, 예를 들어, 기획이나 UI처럼 유저에게 직접 맞닿아 있는 부분에 더 깊게 파고들 수 있었죠.

이렇게 본인에게 맞게 AI 사용 방법을 깎으면 깎을수록 하루하루 자산처럼 남습니다. 어제 깎은 게 오늘 도움이 되어 시간을 줄이고, 또 줄어든 시간을 이용해 또 줄이다 보니, '아, 이게 속도가 복리처럼 쌓이는구나'라고 느꼈습니다. 만약 AI를 잘 모르는 채로 있었다면 어땠을까? 그런 생각을 하니 많이 무섭더라고요.

오늘 바로 따라해 볼 세 가지

마지막으로 저는 AI 관련 영상을 보고 나면, '어? 근데 내가 뭘 들었지?' 하고 머릿속에 남기기 힘들었던 적이 많아서, 간단히 오늘 발표 내용을 요약하며 마무리하겠습니다.

클로드 코드에 스킬 크리에이터 플러그인이 없다면 설치하세요.
내가 만든 스킬들을 조회해서, 안 쓰는 스킬이 있다면 한번 깔끔하게 정리하세요.
본인의 스킬 사용에 어느 정도 패턴이 잡혀 있다면, 스킬 크리에이터를 이용해 스킬들을 감싸는 마스터 스킬을 만드시길 추천드립니다.

이상으로 '스킬을 감싸는 스킬'에 대한 발표를 마치겠습니다. 감사합니다.

▶발표 영상 유튜브에서 보기

]]>

페이블, 앤트로픽 엔지니어가 알려주는 활용 가이드

6월 9일 출시된 페이블 5(Fable 5)는 지난 한 달간 롤러코스터 같은 시간을 보냈습니다. 출시 사흘 만인 6월 12일, 미국 상무부의 지시로 서비스가 전면 차단되는 위기를 맞았지만, 6월 30일 규제가 풀리면서 7월 1일 유료 플랜 서비스를 재개했죠.

현재 기존 유료 구독자라면, 주간 사용량 제한의 최대 50%까지 페이블 5를 이용할 수 있는데요. 원래는 7월 7일에 이 구독제 이용도 끝날 예정이었지만, 앤트로픽이 기간을 5일 더 연장했습니다. 변경된 만료일은 7월 12일. 오늘이 7월 10일이니, 이제 딱 이틀 남았습니다.

*7월 말, 페이블 5는 여전히 구독제로도 쓸 수 있습니다. 이럴 줄 알았어요!

저도 어떻게든 알차게 써보려고 사내에서 이것저것 돌려보는 중인데요. 마침 앤트로픽 클로드 코드(Claude Code) 팀의 타리크 시히파(Thariq Shihipar)가 AI Engineer World Fair에서 발표한 "Field Guide to Fable" 키노트에 좋은 내용이 있어 공유합니다. 개발에 직접 참여한 엔지니어의 활용법이라, 남은 이틀 동안 실무에서 바로 써먹을 수 있도록 핵심 가이드 형태로 정리해봤습니다.

모델이 아니라 우리가 발목을 잡고 있다

타리크의 발표는 네 부분(unhobbling Claude · finding your unknowns · dealing with the grief · being unreasonable)인데 첫 부분 제목이 좀 셉니다. unhobbling, 우리말로 하면 ‘발목에 채운 족쇄를 푼다’는 뜻인데요. 그가 말하는 요지는 이렇습니다. 모델은 설계된(designed) 게 아니라 길러진(grown) 것이고, 그걸 가두는 건 결국 우리라는 거죠. 우리가 씌운 하네스와 프롬프트가 클로드를 이해한 만큼만 성능을 열어준다는 얘기예요.

예시가 재밌습니다. 포켓몬 이야기인데요. "이름이 aw로 끝나는 포켓몬은?"이라고 물으면 일반적인 챗 모델은 못 맞힙니다. 천 마리 중에 Croconaw랑 Drednaw 딱 둘인데 말이죠. 그런데 클로드 코드한테 시키면 맞힙니다. 포켓몬 목록을 전부 긁어와서 aw로 끝나는 걸 거르는 스크립트를 짜버리거든요. 능력이 없던 게 아니라 도구를 쥐여주니 드러난 겁니다. 타리크는 이걸 “capability overhang, 아직 안 꺼내 쓴 능력”이라고 부릅니다.

그래서 프롬프트를 짜는 방식도 바뀝니다. 최근에 클로드 코드 시스템 프롬프트의 80%를 걷어냈다는데, 페이블급 새 모델은 오히려 짧은 프롬프트를 원한다는 겁니다. 예시를 잔뜩 주면 그 예시가 오히려 상상력을 가둡니다. 모델이 우리가 준 예시보다 더 창의적이거든요. 그래서 "이건 하지 마" 식 제약(constraint) 대신 맥락(context)을 주는 쪽으로 갔다고 합니다. 저도 이 얘기 듣고 사내 프롬프트에서 "하지 마" 목록부터 지워봤는데, 확실히 결과가 나아졌습니다.

<출처: 타리크 X>

지도는 영토가 아니다: 결과물의 병목은 나의 'unknowns'

두 번째 파트가 실전에서 가장 쓸모 있었는데요. 타리크는 "지도는 영토가 아니다(map is not the territory)"라는 말을 꺼냅니다. 내가 프롬프트나 스펙에 적은 건 지도일 뿐이고 실제 영토, 그러니까 코드베이스와 요구사항과 현실은 훨씬 넓다는 거죠. 페이블은 자율성이 커서 이 넓은 영토를 혼자 돌아다닙니다. 그러다 내 지도에 없는 지점을 자꾸 만나죠. 그가 "페이블을 쓰면서 처음으로 내 unknown을 진짜 찾아내야겠다고 느꼈다"고 말한 이유입니다.

이 unknown을 네 칸으로 나눠볼게요. 내가 알고 있고 프롬프트에 적는 것(known knowns), 아직 못 풀었다고 아는 것(known unknowns), 너무 당연해서 안 적지만 보면 아는 것(unknown knowns), 아예 고려조차 못 한 것(unknown unknowns). 사고를 치는 건 주로 오른쪽 아래 두 칸이고요. 아래 기법들은 전부 이 안 보이는 칸을 비싸지기 전에 미리 끄집어내려는 장치입니다.

<출처: 타리크 X>

구현 전: 비싸지기 전에 모르는 것을 찾아라

페이블은 토큰을 빨리 태웁니다. 한참 달린 뒤에 "아, 그건 내가 원한 게 아닌데" 하면 그 비용이 다 날아가죠. 그래서 코드를 짜기 전에 모르는 걸 먼저 터는 게 이득입니다. 발표와 공식 블로그에 나온 다섯 가지를 복붙용 한국어 프롬프트로 옮겨봤습니다.

블라인드 스팟 패스

내가 뭘 모르는지조차 모를 때 씁니다(unknown unknowns).

이 코드베이스에 새 인증(auth) 프로바이더를 붙이려는데, 나는 여기 auth 모듈을 하나도 몰라.
blind spot pass 해줘. 내가 놓치고 있는 unknown unknowns를 찾아서 내가 프롬프트를 더 잘 쓰도록 도와줘.

타리크는 이걸 코드뿐 아니라 새 분야를 배울 때도 쓴다고 합니다. 익숙한 코드베이스에 낯선 모듈을 붙일 때 특히 요긴하고요.

브레인스토밍·프로토타이핑

내 안에 있지만 말로 못 꺼내는 취향(unknown knowns)을 끌어내는 용도예요. 시각적인 결정이 특히 그렇죠.

나는 시각적인 취향이 딱히 없어. 완전히 다른 방향의 디자인 4개를 한 HTML 페이지에 만들어줘.
내가 보고 반응할 수 있게.

말로 스펙을 쓰는 것보다 눈앞에 4개 놓고 "이건 별로, 저건 좋아"하는 게 훨씬 빠릅니다.

역인터뷰

이번엔 클로드가 나를 인터뷰하게 합니다.

애매한 부분에 대해 한 번에 하나씩 나를 인터뷰해줘.
내 대답으로 아키텍처를 바꿀 만한 질문을 우선적으로 해줘.

"아키텍처를 바꿀 질문 우선"이 핵심이죠. 사소한 질문 백 개보다 판을 뒤집을 질문 세 개가 더 낫습니다.

레퍼런스

클로드에 지도를 주는 가장 좋은 방법은 다른 지도를 주는 거라고 합니다. 스펙을 장황하게 쓰는 대신, 참조 코드나 목업을 던지는 거죠. 언어가 달라도 됩니다.

vendor/rate-limiter에 있는 이 Rust 크레이트가 내가 원하는 backoff 동작을 정확히 구현하고 있어.
읽고 나서 같은 동작을 우리 TypeScript API 클라이언트에 그대로 다시 구현해줘.

만약 React 컴포넌트를 만들 거면 HTML 목업 하나가 스펙 열 줄보다 낫습니다.

거꾸로 배우기

앞의 블라인드 스팟 패스를 응용해, 아예 새 분야를 클로드에게 배우는 방식입니다. 타리크는 최근 영상 편집의 컬러 그레이딩을 이렇게 익혔다고 합니다.

나는 컬러 그레이딩을 하나도 몰라. 이걸 처음 배우는 사람 기준으로,
내가 뭘 모르는지부터 짚어주고 핵심 개념을 순서대로 가르쳐줘.

내가 잘 모르는 영역일수록 그냥 "가르쳐줘"보다 "내가 뭘 모르는지 짚어줘"가 잘 먹힙니다.

<출처: 타리크 X>

구현 중: 클로드가 내린 결정을 기록하게 하라

이제 실행 단계입니다. 페이블이 오래 달리다 보면 내 지도에 없던 갈림길에서 혼자 결정을 내립니다. 문제는 나중에 결과만 보면 "왜 이렇게 했지?"를 알 수가 없다는 거죠. 그러니 결정을 남기게 시킵니다.

작업하다가 내 지시에 없는 판단을 내려야 하면 일단 보수적인 쪽을 택하고 계속 진행해.
대신 어떤 지점에서 뭘 왜 그렇게 결정했는지 implementation-notes.md에 로그로 남겨줘.

공식 문서도 비슷한 얘기를 합니다. 페이블은 이전 실행에서 배운 걸 markdown에 적어두고, 다시 참조할 때 특히 잘 굴러간다고요. 한 파일에 교훈 하나씩, 맨 위에 한 줄 요약, 그리고 왜 중요했는지까지 적으라고 권합니다. 진행 상황을 보고할 때도 "이번 세션 도구 실행 결과에 각 주장을 대조해서, 검증 안 된 건 검증 안 됐다고 명시해."라고 시키면 없는 성공을 지어내는 일이 줄어듭니다.

구현 후: 퀴즈를 통과하기 전엔 머지하지 않는다

마지막은 검증입니다. 페이블이 다 만들었다고 그대로 PR 올리면 안 됩니다. 정작 내가 그 변경을 설명하지 못 하면 리뷰에서 막히거든요. 그래서 타리크는 끝나고 나서 클로드에게 퀴즈를 내게 시킵니다.

이번 변경사항을 내가 맥락·직관·무엇을 왜 했는지까지 이해할 수 있게 HTML 리포트로 정리해줘.
맨 아래엔 이 변경에 대한 퀴즈를 붙여줘. 내가 반드시 풀어서 통과해야 하는 걸로.

앞서 나온 컬러 그레이딩이 이 전 과정을 잘 보여줍니다. 문외한인 분야를 블라인드 스팟 패스로 배우고(발견 전), 작업 중엔 결정을 로그로 남기고(구현 중), 끝나선 퀴즈로 자기 이해를 확인한 뒤 머지합니다(구현 후). 만드는 속도는 빨라졌지만, 그 결과를 내가 책임지고 설명할 수 있느냐는 여전히 사람의 몫이라는 거죠.

<출처: 타리크 X>

커뮤니티에서도 검증된 활용 패턴

발표 말고 커뮤니티에서도 비슷한 내용이 반복됩니다. 가장 자주 보이는 게 싼 모델로 계획하고 페이블로 실행하는 구성인데요. Wavect의 케빈 리들(Kevin Riedl)은 작업을 Explore·Plan·Execute 세 단계로 쪼갭니다. 탐색은 저렴한 모델로, 설계 판단은 페이블로, 실제 구현은 오퍼스나 소넷으로 나누는 거죠. 페이블을 오케스트레이터로 두고, 나머지를 서브 에이전트로 부리는 구성입니다. 문법 고치기 같은 타이핑 노동이 아니라, 아키텍처·마이그레이션·디버깅·리뷰 같은 판단에는 페이블을 아끼라는 조언입니다.

또 페이블이 정리해둔 걸 자산으로 남겨두는 것도, 남은 이틀을 생각하면 아까운 장사가 아닙니다. 7월 12일에 페이블이 닫혀도, 그 안에서 페이블이 만든 스킬 파일이나, 메모리 노트는 그 뒤에도 남아 있죠. 지금 페이블로 팀 관례나 반복 작업을 마크다운으로 정리해 두면, 나중에 더 싼 모델로 돌려도 그 자산은 계속 쓸 수 있습니다. 저는 개인적으로 이게 제일 이득이라고 봅니다.

무엇보다 페이블은 크고 어려운 일감에 몰아 쓰는 게 맞습니다. 공식 문서도 대놓고 페이블은 사람이 몇 시간, 며칠, 몇 주 걸릴 end-to-end 작업에 붙일 때 진가를 발휘하고, 쉬운 일로 테스트하면 능력을 저평가하게 된다고 말합니다. 프로그래머 사이먼 윌리슨(Simon Willison)은 페이블을 두고 "relentlessly proactive(집요하게 알아서 움직인다)"라고 표현했는데요. 시키지도 않은 Playwright·CORS 서버·pyobjc까지 스스로 조합해 버그를 잡았다고 합니다(그 세션 비용이 $12.11).

국내 사례도 비슷합니다. 한국의 워프센스는 개인용 로컬 앱 만들기, 코드베이스 전체에서 버그 찾기, 브라우저 게임 만들기, 주식 투자 기법 검증하기, 문서 기반 전문가 조언 받기 등을 페이블 5의 활용법으로 꼽았습니다. 또 주식 투자 기법 검증에서는 "이런 기법으로 투자하는데, 이를 증명하거나 박살내 주세요."처럼 확증 편향을 깨는 프롬프트를 추천했습니다.

하지만 페이블 5의 한계점도 있습니다. 바로 공격적인 사이버보안 기법이나 생물학·생명과학 관련 쿼리(실험 방법, 분자 메커니즘 등)를 감지하면 안전 분류기가 작동해 Opus로 넘긴다는 건데요. 실제로 생물다양성에 대한 프로젝트를 하던 한 개발자는 "생물학이랑 관련됐다고 전부 오퍼스로 보내서 페이블이 쓸모없어졌다"고 말했습니다. 만약 이런 태스크를 다룬다면, 굳이 무리해서 페이블을 고집할 필요가 없겠죠.

마치며: 남은 이틀, 달려봅시다

시계를 다시 볼게요. 만료는 7월 12일 밤 11시 59분 59초(태평양시), 한국 시간으로는 7월 13일 오후 4시쯤입니다. 딱 이틀 남짓 남았습니다. 오늘의 팁을 정리하면 다음과 같습니다.

코드를 짜기 전에 블라인드 스팟 패스·인터뷰·레퍼런스로 내 unknown부터 먼저 털어내세요.
실행 중엔 결정을 implementation-notes.md에 남기게 하고, 끝나면 퀴즈로 내 이해를 확인한 다음 머지하세요.
이 아까운 며칠은 자잘한 일 대신 대규모 리팩터·전체 버그 스캔·긴 문서 분석 같은 큰 일감에 몰아 쓰세요.

물론 7월 12일 이후에도 페이블 5가 완전히 사라지는 건 아닙니다. usage credit으로는 계속 쓸 수 있어요. 다만 입력 100만 토큰당 $10, 출력 100만 토큰당 $50으로 Opus 4.8의 딱 두 배라 실사용엔 부담이 큽니다. 서브스크립션으로 돌아올지는 앤트로픽이 "용량이 되면"이라고만 말했고요. 그러니 지금이 마음 편히 달려볼 때입니다.

타리크의 마지막 말을 빌리자면, “탐험하세요. 실제로 만드세요. 그리고 조금 덜 합리적으로 굴어보세요.” 남은 이틀, 달려봅시다.

*페이블 5는 여전히 구독제로도 쓸 수 있습니다. 이럴 줄 알았어요!

<출처>

[AI Engineer] Field Guide to Fable — Thariq Shihipar, Anthropic
[Thariq, X] A Field Guide to Fable: Finding Your Unknowns

]]>

회사에서 아무것도 안 하기

본문은 요즘IT가 션 고데크(Sean Goedecke)의 글 <Doing nothing at work>를 번역한 글입니다. 필자는 GitHub의 스태프 소프트웨어 엔지니어(Staff Software Engineer)로, GitHub Copilot 관련 개발을 담당하고 있습니다. 수학 학사와 도덕철학 석사라는 이색적인 배경을 지닌 엔지니어로, Zendesk를 거쳐 2021년 GitHub에 합류했으며, 소프트웨어 엔지니어링과 대기업 조직의 역학을 주제로 한 인기 블로그를 운영하고 있습니다.

이 글은 '뛰어난 엔지니어일수록 오히려 일을 덜 해야 한다'는 도발적인 주장을 담고 있습니다. 필자는 기술 회사에서의 성과가 대형 계약, 장애 대응, 주목도 높은 기능 출시 같은 예외적인 사건들에 좌우된다고 봅니다. 그리고 이런 임팩트 큰 기회를 잡으려면 평소 가동률을 80%로 낮춰 여유를 남겨 둬야 한다고 말합니다. 글루 워크(glue work) 피하기, 보상 없는 노동 요구에 역압 걸기, 사라질 가능성이 큰 일에 투자하지 않기 등 '의도적으로 아무것도 하지 않는' 구체적인 전략을 함께 제시합니다.

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

많은 엔지니어가 지금보다 일을 덜 해야 합니다. 코드를 덜 짜거나, 변경을 줄이라는 뜻이 아닙니다. 말 그대로 하루에 일하는 시간을 줄이라는 이야기입니다. 그리고 일할 때도 좀 더 느긋한 속도로 일하는 게 좋습니다. 저는 특별히 압박이 큰 프로젝트가 없는 한, 기본적으로 가동률 80%를 목표로 삼습니다. 하루 업무 시간의 20%는 컴퓨터에서 떨어져 있는 셈이죠.

임팩트가 큰 기회는 따로 있다

왜 그럴까요? 기술 회사에서의 성과는 예외적인 사건들이 좌우하기 때문입니다. 제가 지금까지 만든 변화 중 가장 임팩트가 컸던 것들을 떠올려 보면, 놀랄 만큼 사소한 작업이었던 경우가 많습니다. 소프트웨어 개발에는 '노력 점수' 같은 게 없습니다. 중요한 건 올바른 문제를, 올바른 시점에 푸는 것입니다.

규모가 큰 엔지니어링 조직에는 마음만 먹으면 할 수 있는 아주 사소한 작업인데도, 회사에 수천만에서 수억 달러를 벌어다 줄 수 있는 일들이 늘 존재합니다. 흔한 예시를 세 가지만 들어 보겠습니다.

첫째, 회사가 큰 규모의 엔터프라이즈 계약을 성사시키려 할 때, 기능 하나나 버그 수정 하나로 그 계약을 성사시킬 수 있습니다. 그 기능이 굳이 훌륭할 필요도 없습니다. 그저 구체적인 변경을 기꺼이, 그리고 실제로 만들어 낼 수 있다는 걸 보여 주는 것만으로 충분할 때도 있습니다.
둘째, 장애를 초기에 막거나 완화하면(그저 어떤 기능 플래그를 꺼야 하는지 아는 것만으로도) 막대한 비용을 아낄 수 있습니다. 장애가 진행되는 동안 당장 날아가는 매출은 물론, 그 일로 거래를 끊거나 검토 중이던 계약을 거절했을 고객에게서 미래에 잃었을 매출까지 아끼는 셈입니다.
셋째, 회사가 주목도 높은 기능을 출시하려 할 때, 그 성패는 사소하지만 아무도 잘 모르는 변경에 달려 있는 경우가 많습니다(예를 들어, 사용자 설정에 새 필드를 재빨리 추가하는 능력, 혹은 몇 년째 아무도 손대지 않은 낡은 엔터프라이즈 데이터 내보내기 기능을 업데이트하는 능력이 그렇습니다). 시스템에 익숙한지 아닌지에 따라, 이런 변경이 몇 시간짜리 일이 되기도 하고 일주일짜리 일이 되기도 합니다.

이 예시들의 공통점은 무엇일까요? 모두 시점에 달려 있다는 것입니다. 아침에 로그인해서 "자, 오늘은 큰 계약을 풀어 볼까" 하거나, 장애를 완화하거나, 주목도 높은 기능의 개발 속도를 끌어올리겠다고 마음먹는다고 되는 일이 아닙니다. 그러면 그저 운 좋게 적절한 때 적절한 자리에 있으면 되는 문제일까요? 꼭 그렇지만은 않습니다. 여기에 더해, 당신이 이미 바쁘지 않아야 합니다.

여유를 남겨 두기

몇 년 전에 저는 이 주제를 다룬 글을 쓴 적이 있습니다. 늘 100% 가동률로 우선순위 낮은 일을 끊임없이 처리하고 있다면(예를 들어, 백로그에서 티켓을 하나 집어 쳐내고, 또 하나 집어 쳐내기를 반복한다면), 두 가지 방식으로 임팩트가 큰 일을 할 기회를 놓치게 됩니다.

첫째, 너무 바빠서 그런 기회를 알아차리지도 못합니다. 다른 일을 하는 사람들과 이야기를 나누거나, 팀 업데이트를 읽거나, 진행 중인 장애를 눈여겨볼 여유가 없기 때문입니다. 그래서 임팩트가 큰 일에 발을 들이는 가장 좋은 방법, 즉 자기 전문성을 자발적으로 내미는 기회를 날려 버리게 됩니다.

둘째, 늘 바빠 보이면 매니저도 당신을 끌어들이려 하지 않습니다. 이것이 임팩트 큰 일에 참여하는 두 번째로 좋은 방법인데요. 매니저나 프로덕트 매니저가 "아, 이건 션이 도와줄 여력이 있겠네. 불러 볼까" 하고 말해 주는 것 말입니다. 이 방법이 왜 더 좋을까요? 매니저와 프로덕트 매니저는 지금 어떤 임팩트 큰 일이 벌어지고 있는지 대체로 훨씬 잘 파악하고 있기 때문입니다. 그들은 당신이 들어가지 않는 회의에 들어가 있습니다.

아무것도 안 하기

임팩트 큰 일을 위해 시간을 비워 둬야 하고, 그렇다고 티켓만 갈아 넣어서도 안 된다면, 분 단위로 도대체 무엇을 하고 있어야 할까요? 그냥 아무것도 안 하고 있어야 할까요? 그렇습니다. 아무것도 안 하는 건 사실 좋은 일입니다. 소프트웨어 엔지니어링은 스트레스가 큰 직업일 수 있지만, 대개 그 스트레스가 지속적이지는 않습니다. 스트레스는 이따금 터지는 장애나, 압박이 큰 급한 작업, 혹은 (요즘이라면) 정리해고 같은 데서 옵니다. 비교적 압박이 적은 일까지 급박한 강도로 밀어붙인다면, 정작 압박이 큰 일을 다뤄야 할 때는 이미 지치고 신경이 곤두선 상태일 겁니다.

압박이 큰 일을 할 때조차 아무것도 안 하는 게 좋을 수 있습니다. 온콜을 처음 맡는 엔지니어에게 제가 권하는 것 하나는 서두르지 말라는 겁니다. 통화에 참여하기 전이나 입을 열기 전에 숨을 몇 번 고르고, 전반적으로 "슬로모션으로 생각하기"를 시도해 보시기 바랍니다. 대부분의 장애는 알아서 해결됩니다. 그리고 장애가 진행되는 동안 다급하게 던지는 "이러면 나아질지도" 식의 변경은 대부분 상황을 낫게 하기는커녕 악화시킵니다. 원칙적으로, 그저 패닉에 빠지지 않는 것만으로도 당신은 이미 대다수 엔지니어보다 장애 대응을 잘하고 있는 셈입니다.

'아무것도 아닌 것(nothing)'은 무언가가 일어날 수 있는 공간입니다. 뇌에 쉴 틈을 주면, 새로운 아이디어가 떠오를 가능성이 더 커집니다. 누군가 중요한 일을 맡기면, (뒤에서 돌리고 있던 다른 세 가지 일과 저글링하는 대신) 온전히 집중해서 그 일에 달려들 수 있습니다. 바쁘지 않을 때, 그저 이것저것 바라보며 새로운 정보를 받아들일 시간이 생깁니다.

어떤 일은 일부러 하지 않기

많은 엔지니어가 해야 할 일이 눈앞에 보이는데도 하지 않는 상태를 불편해합니다. 저도 그렇습니다. “나는 쓸모 있는 사람이 되는 것에 중독됐다”라는 글에서 이 이야기를 쓴 적이 있는데요. 많은 소프트웨어 엔지니어가 공유하는 심리적 특성인데, (어느 정도까지는) 바로 그 특성 덕분에 이 직업에 잘 맞기 때문입니다. 아무것도 안 하는 시간을 보내려면, 때로는 나서지 않도록 스스로를 억눌러야 합니다.

예를 들어, 저는 엔지니어가 대체로 글루 워크(glue work, 조직이 원활하게 굴러가도록 돕는 필수적이지만 눈에 잘 띄지 않는 업무)를 피해야 한다고 믿습니다. 사람들이 서로 대화하도록 챙기고, 자기가 이끌지도 않는 일의 문서를 업데이트하고, 기술 부채를 해결하겠다고 자원하는 것 같은 접착 작업 대부분은, 조직이 그 일을 명시적으로 우선순위에 두지 않았다는 사실을 반영합니다.

정말 중요하게 여겼다면 당신이 자원할 필요도 없었을 것입니다. 이 상황은 둘 중 하나입니다. 그래도 괜찮은 상황이거나, 아니면 큰 실수이거나. 괜찮은 상황이라면, 나서서 그 일을 해서는 안 됩니다. 시간을 낭비하고 매니저를 성가시게 할 뿐이니까요. 반대로 큰 실수라면, 그래도 그 일을 해서는 안 됩니다. 당신의 커리어와 정신 건강을 대가로, 회사가 자기 실수의 결과를 느끼지 못하도록 감싸 주는 꼴이 되기 때문입니다.

그건 당신에게 손해인 거래일뿐더러, 후배들에게 나쁜 본보기가 되고, 당신이 결국 번아웃으로 쓰러졌을 때 누군가 똑같은 자리에 뛰어들도록 만드는 나쁜 선례가 됩니다. 결과가 정말로 심각하다면, 그냥 벌어지게 두시기 바랍니다. 그래야 조직이 그 고통을 느끼고 방침을 바꿉니다. (왜 필연적일까요? 제 생각에 번아웃은 보상받지 못하는 고된 노동이고, 직장에서 신경 쓰지 않는 사적인 대의를 위해 나서는 것은 보상받지 못하는 일을 많이 하게 되는 지름길이기 때문입니다.)

또한 저는 너무 도움이 되려 하면 포식자에게 취약해진다고 믿습니다. IT 회사에는 소프트웨어 엔지니어에게서 보상 없는 노동을 뽑아내려는 사람들이 넘쳐납니다. (이 주제에 대한 참고 글) 이것은 정상적인 경로로 들어와 승진과 보너스(그리고 그냥 당신의 정규 급여)로 보상받는 일과는 다릅니다. 제가 말하는 것은 뒷경로로 들어오는 일, 즉 그 작업을 당신 이름으로 공식 기록에 남길 능력도 의향도 없는 사람들에게서 오는 일입니다.

예를 들어, 다른 조직의 프로덕트 매니저가 "데이터 쿼리 정말 잘하시던데, X에 대한 통계 좀 뽑아 주실 수 있을까요?"라고 메시지를 보내는 경우, 혹은 다른 팀 엔지니어가 "페어로 같이 하자"고 청하지만 결국 코드는 당신이 다 짜고 변경은 그 사람이 조용히 자기 이름으로 제출하는 경우입니다.

이런 일을 어느 정도 하는 건 괜찮습니다. 도울 수 있을 때 남을 돕는 것도 나쁘지 않으니까요. 하지만 역압(backpressure)을 걸 줄 알아야 합니다. 거절하든지, 아니면 그냥 답을 몇 시간이나 며칠 미루든지 하는 식으로 말입니다.

어차피 사라질 가능성이 큰 일에 너무 많이 투자하지 않는 것도 좋은 자세입니다. 예를 들어, 무엇을 원하는지 실시간으로 정해 가는 프로덕트 디자이너와 일한다고 해 보겠습니다. 오전 9시에 페이지 헤더를 이렇게 해 달라고 하고, 10시에 손을 좀 보고, 11시에 또 바꾸고, 계속 이런 식입니다. 이럴 때 매시간 페이지를 처음부터 다시 짜는 데 몸을 던지면 안 됩니다. 대신 아무것도 하지 말고(산책을 다녀오거나), 오후에 가장 최근 디자인을 기준으로 페이지를 한 번만 다시 짜야 합니다.

또 비슷한 경우로는 "밀어붙일 영향력은 없는 매니저의 거창한 아이디어"가 있는데요. 이럴 땐 그 프로젝트가 결국 취소될 때까지 그냥 시간을 흘려보내면 됩니다. (물론 이 전략을 사용할 때는 주의해야 합니다. 만약 이 전략을 시도했는데 프로젝트에 대한 영향력 수준에 대해 잘못 판단했다면, 게으른 사람처럼 보일 거고, 결국에는 급하게 결과물을 내놓아야 할 겁니다.)

마치며

소프트웨어 엔지니어링에 관한 조언과 도구들은 대부분 기술적 노력을 확장하는 능력을 키우는 데 초점을 맞춥니다. 동시에 더 많은 일을 하거나, 더 큰 범위의 프로젝트를 맡고, 그냥 코드를 더 많이 짜는 능력 말이죠. 하지만 소프트웨어 엔지니어링의 성공은 이런 것들로 결정되지 않습니다. 성공은 적절한 시기에 적절한 일을 해내는 능력으로 결정되며, 그러려면 평소 업무에서는 자기 역량의 일부를 의도적으로 아껴둬야 합니다.

제 경험상, 80%의 노력만으로도 여전히 "뛰어난 성과를 내는 엔지니어"가 되는 것은 가능합니다. 오히려 더 쉽습니다. 스트레스 때문에 어이없는 실수를 저지를 가능성이 줄고, 큰 보상을 주는 임팩트 있는 업무에 더 적극적으로 참여할 수 있기 때문이죠.

그렇다고 100%의 노력을 절대 하지 말라는 뜻은 아닙니다. 저도 1년에 두세 번쯤은 낼 수 있는 최대한으로 열심히 일합니다. 긴 시간 일하고, 온 힘을 다해 집중하며, 눈뜰 때부터 잠들 때까지 그 문제에 대해 생각하죠. 다만 저는 이런 방식은 보상이 정말로 클 때만 사용합니다. 나머지 기간에는 비교적 여유롭게 일하고요.

덧붙임: 이 글은 해커뉴스(Hacker News)에서 몇 가지 댓글을 받았습니다. 댓글에서는 여유 시간을 확보할 때 매니저와 문제가 생기지 않으려면 어떻게 해야 하는지(제 경험상 대체로 생산적이기만 하면 괜찮지만, 매니저마다 편차가 큽니다), 그리고 엔지니어가 정말로 자기 업무량을 통제할 수 있는지 등을 논의했습니다. 참고해 보세요!

저에게 큰 영향을 준 것 중 하나는 리치 히키(Rich Hickey)의 강연 ‘해먹 중심 개발(Hammock Driven Development)’입니다. 이 글은 어느 정도 히키가 말한 것과 비슷합니다. 다만 히키는 평범한 기술 회사에서 강한 엔지니어가 되는 법보다는, 정말 어려운 문제의 해법을 설계하는 데 무엇이 필요한지를 이야기합니다. 그래서 컴퓨터에서 떨어진 시간을 그저 긴장을 풀고, 머릿속에서 해법이 굳어지도록 두는 데 쓰라는 게 아니라, 어려운 문제에 집중하는 데 쓰라고 권합니다. 또한 이 글은 즈비 모쇼위츠(Zvi Mowshowitz)가 "여유(slack)"에 관해 쓴 글과도 닮았습니다.
저는 ‘글루 워크는 해롭다(Glue work considered harmful)’라는 글에서 이 주제에 대해 훨씬 자세히 다뤘으니, 참고해 보세요.

<원문>

Doing nothing at work

]]>

중소기업 AI 도입률 23.4%, 왜 나중으로 미룰까?

"AI를 이용하면 사원들의 업무 효율이 크게 올라갑니다." 영업사원들이 고객사에 흔히 말하는 세일즈 멘트입니다. 하지만 의외로 많은 기업 담당자들은 "저희는 아직 그런 게 필요한 단계가 아니에요.", "일단 급한 것부터 처리하고, AI는 좀 더 검토해 봐야겠습니다."라며 미적지근한 반응을 보일 때가 많습니다.

B2B AI·SaaS 제품을 판매하는 사람이라면 이 장면이 낯설지 않을 겁니다. 기업에선 분명 AI를 원한다고 말합니다. 그런데 정작 계약서 앞에서는 "나중에"가 됩니다. 왜 그럴까요? 이에 일본 시장의 데이터가 이 질문에 명확한 답을 줍니다. 도쿄상공리서치(TSR)가 2025년 8월 6,645개사를 대상으로 한 ‘생성 AI에 관한 설문’ 조사에 따르면, 생성형 AI를 조직적으로 활용하는 기업은 대기업이 43.3%인 반면, 중소기업은 23.4%에 그쳤습니다. 약 20%포인트, 1.9배의 격차입니다. 이 수치는 B2B AI 솔루션 기업들이 중소기업 시장에서 마주하는 진입 장벽과 저항감을 그대로 보여줍니다.

이번 글에서는 이러한 저항의 구조를 3가지로 분석하고, 일본 시장에서 실제로 이 장벽을 넘은 AI SaaS 기업 “LegalOn Technologies”의 사례를 통해, 고객을 설득하는 제품 설계 전략을 살펴보겠습니다. (이 글에서 중소기업은 IT업계가 아닌 일반적인 기업을 지칭한 점, 참고 부탁드립니다.)

미리 요점만 콕 집어보면?

중소기업이 AI를 거부하는 핵심 이유는 자원 부족이 아니라, "우리 업무에 맞지 않을 것"이라는 리스크 인식입니다.
일본에서 성공한 AI SaaS 기업은 범용 AI가 아닌 '한 가지 업무의 완벽한 자동화'로 시작해 신뢰를 쌓은 뒤 확장했습니다.
B2B AI 판매자는 기술 판매자가 아니라, '도입 설계자(Onboarding Architect)'로 포지셔닝해야 중소기업 시장을 열 수 있습니다.

중소기업이 AI 도입을 주저하는 진짜 이유

"AI? 대기업이나 쓰는 거 아니에요?"

이 반응의 본질은 예산 문제가 아닙니다. 라그자스가 2026년 4월, 일본 전국 비즈니스 퍼슨 3,000명을 조사한 결과, 중소기업(종업원 1~300명)의 59.0%가 "AI 도입 예정이 없고 필요성도 느끼지 못한다"고 답했습니다. 절반이 훌쩍 넘는 비율이 '돈이 없어서'가 아니라, '필요를 못 느껴서' 멈춰 있는 겁니다.

<출처: 라그자스(ラグザ스, PR TIMES 조사 결과)>

흥미로운 건 미도입 기업의 우려와 도입 기업의 현실적 과제가 닮아있다는 점입니다. 데이코쿠데이터뱅크(TDB)가 일본의 1만 312개사를 대상으로 실시한 「생성 AI에 관한 기업 동향조사」(2026년 3월 실시)에 따르면, 이미 AI를 활용 중인 기업들은 과제로 "전문 인재·노하우 부족"(55.13%), "장단점 평가가 어려움"(43.8%)을 가장 많이 꼽았습니다.

먼저 도입한 기업들조차 인력 부족과 효과 측정에 애를 먹고 있다면, 인프라가 취약한 미도입 중소기업이 지레 겁을 먹고 돌아서는 것은 당연한 수순입니다. 이 데이터와 현장의 장벽을 종합해 보면, 중소기업이 AI 도입을 주저하는 진짜 이유는 크게 세 가지 구조로 요약됩니다.

첫째, 필요성 인식의 부재입니다. "지금 업무가 돌아가고 있는데 왜 바꿔야 하나"라는 질문에 AI 판매자가 명확한 답을 주지 못합니다. 대기업은 경쟁사 도입 현황, 업계 트렌드, 이사회 보고 등 외부 압력이 도입 결정을 밀어줍니다. 중소기업은 그런 압력이 약합니다. "남들이 한다"는 논리가 통하지 않습니다.

둘째, 현장 적응에 대한 불안입니다. AI를 도입하면 기존 업무 방식이 바뀝니다. 직원들이 새 시스템을 배워야 합니다. "배우는 시간 동안 업무가 밀리면 어떡하지?" "잘못 쓰면 오히려 문제가 생기는 거 아냐?" 이런 불안은 ROI 계산표로 해결되지 않습니다. 중소기업일수록 한 사람이 여러 업무를 겸하기 때문에, 업무 방식 변화의 영향 범위가 더 넓습니다.

셋째, 실패 리스크에 대한 민감도입니다. 대기업은 AI 프로젝트가 실패해도 다른 프로젝트로 만회할 수 있습니다. 중소기업은 다릅니다. 한 번 실패하면 "그것 봐라, AI는 우리한테 안 맞는다"가 됩니다. 의사결정권자 입장에서는 "안 해서 잃는 것"보다 "해서 잃는 것"이 더 크게 느껴집니다.

<출처: 데이코쿠데이터뱅크(TDB, 조사 결과 바로가기)>

데이코쿠데이터뱅크(TDB)의 「생성 AI에 관한 기업 동향조사」(2026년 3월 실시, 5월 14일 발표)에서도 흥미로운 데이터가 나옵니다. 생성형 AI를 활용 중인 기업 중 "대단히 효과가 있다"고 답한 비율은 소규모 기업이 29.7%로 대기업(20.8%)보다 높았습니다. 즉, 실제로 도입한 중소기업은 AI의 효과를 더 크게 체감했다는 거죠.

<출처: https://www.tdb.co.jp/report/economic/20260514-genai/>

여기서 핵심은 앞의 세 가지가 모두 '도입 전'에 작동하는 장벽이라는 점입니다. 도입한 기업일수록 효과를 크게 체감한다는 사실은 제품의 효용은 이미 증명이 됐고, 막혀 있는 것은 '쓰기 시작하는 순간'까지의 거리임을 보여줍니다.

그래서 B2B AI 솔루션 판매자가 "기능이 좋다"를 아무리 강조해도 중소기업은 움직이지 않습니다. 효과가 의심스러워서가 아니라, 그 효과를 확인하기 전에 넘어야 할 장벽이 높기 때문입니다. 필요한 것은 기술 설명이 아니라, 필요성을 납득시키고(첫째), 변화의 부담을 줄이고(둘째), 실패의 두려움을 덜어주는(셋째) 진입 설계입니다.

저 역시 일본에서 일하면서, B2B 영업 현장에서 "AI 기능이 경쟁력을 만듭니다"라는 메시지가 중소기업 앞에서 번번이 막히는 경험을 했고, 그 원인이 바로 이 3가지 구조임을 깨달았습니다.

일본의 AI SaaS 기업이 선택한 '한 걸음' 전략

LegalOn Technologies 사례 분석

LegalOn Technologies(리걸온 테크놀로지스)는 2017년 도쿄에서 두 명의 기업 변호사가 창업한 일본발(發) 법률 AI 기업인데요. 현재는 도쿄와 샌프란시스코에 거점을 둔 글로벌 기업으로 성장했습니다.

2019년 4월 일본 최초의 AI 계약 검토 서비스 'LegalForce'를 출시하며 시작해, 2026년 3월 말 기준 전 세계에서 8,500개 이상의 조직이 유료로 사용하고 있죠. 일본 상장사의 30% 이상이 고객입니다. 2025년 10월에는 ARR(연간반복매출) 100억엔을 돌파했는데요. 제품 출시 6년 반 만의 달성이자, 일본에서 창업한 AI 기업으로서는 최초의 사례입니다.

다만 짚어둘 점이 있습니다. LegalOn이 정량적으로 검증한 침투처는 상장사(대기업)입니다. 규모별 고객사수 내역은 공개하지 않았으며, "일본 국내 중소기업 N개사 도입" 같은 수치도 따로 발표하지 않습니다. 그럼에도 이 사례를 중소기업 공략 관점에서 볼 가치가 있는 이유는, 진입 방식 자체가 규모의 장벽을 낮추도록 설계됐기 때문입니다.

LegalOn은 자사 서비스가 "변호사 한 명이 법무를 전담하는 1인 법무·소규모 법무"부터 "중규모·대규모 법무팀"까지 폭넓게 쓰인다고 밝혔고, 실제 한 중소기업 경영자는 "계약 리스크를 생각하면 매우 저렴해 곧바로 도입을 결정했다"고 평가했습니다(LegalOn 영업 파트너 매칭 코멘트).

즉, 이 글에서 LegalOn을 보는 관점은 "중소기업을 다 점령했다"가 아니라, 대기업에서 쌓은 신뢰를 어떻게 작은 조직까지 내려보냈는가입니다. 그 진입 설계를 세 가지로 분석합니다.

1) 범용 AI가 아닌 '한 가지 업무'에 집중

LegalOn은 처음부터 "AI로 법무 전체를 혁신합니다"라고 말하지 않았습니다. 계약서 검토 한 가지에 집중했습니다. 그것도 "계약서를 AI가 작성합니다"가 아니라 "심사·수정 시간을 줄여드립니다"였습니다.

왜 이 선택이 중요할까요? 계약서 검토는 법무팀의 반복 업무 중 가장 시간이 많이 드는 작업입니다. 동시에 "틀리면 큰일 나는" 고위험 업무이기도 합니다. LegalOn은 이 업무에서 AI가 검토를 하고, 최종 판단은 사람이 하는 구조를 설계했습니다. AI가 위험 조항을 찾아주고, 변호사가 승인하는 방식입니다.

이 설계가 중소기업의 불안을 낮췄습니다. "AI가 실수하면 어떡하지?"라는 질문에 "최종 판단은 당신이 합니다"라고 답할 수 있었습니다. AI를 "대체자"가 아닌 "보조자"로 포지셔닝한 것입니다.

2) PoC(개념 검증) 단계에서 성공 경험 설계

LegalOn의 진입 방식은 거창한 "전사 혁신"이 아니라 단일 업무에서 작게 시작하는 데 있습니다. 법무팀의 계약서 검토라는 한 가지 업무에서 먼저 효과를 증명하고, 그 성공 경험을 바탕으로 확장하는 방식입니다.

LegalOn의 도입 흐름도 같은 맥락입니다. 무료 온라인 상담과 실제 제품 데모로 시작해, 영업 담당이 고객의 업무를 듣고 맞춤 플랜을 제안하며, 계약 후에는 커스터머 석세스 담당이 운용 정착까지 지원하는 구조입니다(LegalForce 공식 도입 흐름). 가능성이 아니라 "실제로 쓸 수 있는가"를 먼저 확인시키는 방식입니다. 그 결과 LegalForce 사용자 223사를 대상으로 한 자체 조사(2024년 3월)에서 심사·수정에 걸리던 시간이 평균 40% 줄어든 것으로 나타났고, 도입 사례에 따라서는 검토 시간이 절반으로 단축된 곳도 있었습니다.

작은 조직 입장에서 이 접근법은 리스크를 낮춥니다. "전사 도입"은 실패하면 큰일이지만, 한 업무에서 시작하는 작은 범위의 트라이얼은 실패해도 손실이 제한적입니다. 그리고 트라이얼에서 효과를 체감하면, 내부 설득이 쉬워집니다. "우리 팀이 써봤는데 진짜 좋더라"는 말이 어떤 영업 자료보다 강력합니다.

3) 수직 확장: 한 업무에서 인접 업무로

LegalOn은 계약서 검토에서 시작해 점진적으로 영역을 확장했습니다. 계약서 검토(LegalForce) → 전자계약·계약 관리 → 법무 상담 관리(Matter Management) → 기업 거버넌스(2025년 Fides 인수) 순서입니다.

이 확장 경로의 핵심은 기존 고객의 인접 업무라는 점입니다. 계약서 검토를 쓰던 고객이 "계약 관리도 한 곳에서 하면 편하겠다"고 느끼면 자연스럽게 확장됩니다. LegalOn은 이 흐름을 "Legal Operations Platform"이라는 비전으로 묶었습니다.

왜 이 순서가 작은 조직까지 확장하는 데 유효했을까요? 첫째, 확장 비용이 최소화됩니다. 이미 계약서 검토로 신뢰를 쌓은 고객에게 인접 업무를 제안하면, 별도의 영업 비용 없이 재계약(업셀)이 일어납니다. 둘째, 자원이 부족한 조직일수록 "새로운 공급자"를 찾기보다 "이미 쓰는 공급자의 다음 제품"을 선호하는 경향이 강합니다. LegalOn은 이 심리를 정확히 공략했습니다.

2025년 7월 시리즈 E에서 5,000만 달러를 추가 조달하면서 발표한 방향은 "AI 에이전트"입니다. 단순 검토를 넘어 계약 업무의 자동 분류(Triage Agent), 초안 작성, 승인 워크플로우까지 AI가 처리하는 구조입니다. 하지만 이 확장도 "계약서 검토"라는 핵심 업무에서의 신뢰가 기반입니다.

일본 사례에서 배우는 B2B AI 고객 확장 전략

LegalOn의 사례에서 B2B AI 판매자가 가져갈 수 있는 전략적 시사점을 정리합니다.

1) AI 도입의 당위성보다 '고객의 작은 성공'을 먼저 설계하세요

중소기업 고객에게 "AI 시대에 뒤쳐지면 안 됩니다"는 설득력이 약합니다. 대신 "이 업무에서 주 5시간이 2시간으로 줄어듭니다"가 통합니다. 추상적인 미래보다 구체적인 현재의 개선을 보여줘야 합니다.

LegalOn이 "심사·수정 시간 평균 40% 단축"이라는 숫자를 전면에 내세운 이유입니다. 이 숫자는 고객이 자신의 업무에 대입해 볼 수 있습니다. "우리 팀이 계약서 검토에 쓰는 시간이 주 10시간이면, 6시간으로 줄어든다는 거네."

2) 전사 도입이 아닌 부서·업무 단위의 미니 PoC를 제안하세요

"전사 도입 시 할인해 드립니다"는 대기업 전략입니다. 중소기업에게는 "한 팀에서 한 달만 써보세요"가 더 효과적입니다. 진입 장벽을 낮추는 것이 확장의 시작입니다.

미니 PoC의 핵심은 성공 기준을 미리 정의하는 것입니다. "효과가 있으면 도입합니다"가 아니라 "검토 시간이 50% 이상 줄면 도입합니다"처럼 구체적인 기준을 함께 설정합니다. 기준이 명확하면 고객 내부에서 의사결정이 빨라집니다.

3) 현장 사용자가 수용 가능한 업무 흐름을 함께 설계하세요

AI 도입이 실패하는 가장 흔한 이유는 "기존 업무 방식과 충돌"입니다. 아무리 좋은 AI라도 현장 직원이 쓰지 않으면 의미가 없습니다. LegalOn이 "AI가 검토하고, 사람이 최종 판단"이라는 구조를 선택한 이유가 여기 있습니다. 기존 업무 흐름(변호사가 계약서를 검토한다)을 그대로 유지하면서, 검토 속도만 높입니다. 직원 입장에서는 "새로운 방식"이 아니라 "빠른 도구"로 느껴집니다.

B2B AI 판매자는 제품 시연을 할 때 "이 기능이 있습니다"가 아니라 "당신의 업무가 이렇게 바뀝니다"를 보여줘야 합니다. 고객의 현재 업무 흐름을 먼저 파악하고, 그 흐름 안에서 AI가 어떤 역할을 하는지를 설계해야 합니다.

4) 기술 판매자를 넘어 '도입 설계자'로 포지셔닝하세요

중소기업 고객은 AI 제품을 사는 것이 아니라 문제 해결을 삽니다. "이 AI가 좋습니다"보다 "당신의 이 문제를 이렇게 해결합니다"가 더 설득력 있습니다. 이 관점에서 B2B AI 판매자의 역할은 "기술 판매자"에서 "도입 설계자(Onboarding Architect)"로 확장됩니다. 도입 설계자는 제품을 파는 것이 아니라 고객이 성공하는 경로를 설계합니다. 어떤 업무에서 시작할지, 누가 먼저 쓸지, 성공을 어떻게 측정할지, 확장은 어떤 순서로 할지 말이죠.

LegalOn의 영업 조직이 단순 세일즈가 아니라 "Customer Success"를 강조하는 이유도 여기 있습니다. 계약을 따내는 것보다 고객이 실제로 효과를 보는 것이 더 중요합니다. 효과를 본 고객이 다음 고객을 데려옵니다.

B2B AI 영업을 위한 "도입 설계자" 실전 체크리스트

고객에게 제품 기능을 나열하기 전, 아래 체크리스트를 통해 고객의 성공 경로를 먼저 설계해 보세요.

1. 문제 발굴 단계 (Discovery)

고통 지점 확인: 고객이 가장 많은 시간을 쏟고 있는 "반복적이고 고위험인 업무"를 하나 찾았는가? (AI가 "좋은 것"이 아니라 "필수적인 것"이 되는 지점)
수치화 가능성: 도입 전후의 변화를 증명할 수 있는 정량 지표(시간, 비용, 오류율)를 고객과 미리 합의했는가?
현상 유지 위험성: "지금 안 바꾸면 잃게 될 것"이 무엇인지 고객이 인지하게 했는가? (ROI보다 리스크 관리 차원)

2. 제안 및 PoC 단계 (Proposal & PoC)

범위의 최소화: 전사 도입이 아닌, 특정 부서/팀의 "단일 업무"만 개선하는 미니 PoC를 제안했는가?
성공 기준 정의: "효과가 있으면 도입한다"는 모호한 기준이 아닌, "검토 시간이 X% 줄면 도입한다"는 구체적 기준을 세웠는가?
인간 중심 설계: AI를 업무 "대체자"가 아닌, 사람의 판단을 보조하는 "비서"로 포지셔닝했는가? (최종 결정권은 인간에게 있음을 명시)

3. 온보딩 및 정착 단계 (Implementation)

워크플로우 동기화: 기존 업무 프로세스를 최대한 건드리지 않고, 자연스럽게 녹아들 수 있는 동선을 설계했는가?
성공 전파(Internal Advocacy): PoC에서 작게 성공한 사례를 내부에서 자랑할 수 있도록 데이터와 근거를 함께 제공했는가?
사후 지원 체계: 초기 시행착오를 즉각 해결할 수 있는 커스터머 석세스 채널(문의 창구 등)이 확보되었는가?

마치며: 23.4%는 장벽이 아니라 기회입니다

마지막으로 위 체크리스트는 단순히 한 번 읽고 넘어가는 것이 아니라, 고객과 첫 미팅을 잡을 때마다 책상 위에 올려두고 확인하는 '영업의 나침반'으로 활용해 보시길 바랍니다. 기술은 변해도, 고객의 성공을 돕겠다는 '도입 설계자'의 마음가짐은 변하지 않습니다. 오늘 바로 한 명의 고객에게, 기능 대신 '성공 경로'를 제안해 보는 것은 어떨까요?

일본 중소기업의 AI 도입률 23.4%는 "시장 가능성이 없다"는 의미가 아닙니다. 아직 도입하지 않은 약 76%의 시장이 그대로 남아 있고, 접근 방식의 전환에 따라 그 점유율을 얼마든지 가져올 수 있는 기회의 장이라는 의미입니다.

저 역시 비슷한 고민을 겪은 적이 있습니다. 스마트폰 도입 초기, 모바일 앱 솔루션을 제안하던 시절이었는데요. 엔지니어 중심 조직이었던 저희는 기술의 우수성만을 내세우며 "이 기술이 얼마나 뛰어난가"를 설명하는 데 급급했습니다. 하지만 결과는 냉담했습니다. 도입률은 저조했고, 어렵게 계약한 고객들조차 제품을 제대로 활용하지 못해 만족도가 낮았습니다.

변화는 관점을 완전히 바꾼 뒤에야 시작되었습니다. '우리 기술이 얼마나 대단한가' 대신, 고객의 업무 프로세스를 옆에서 지켜보고 그들의 고민을 뜯어보았습니다. 고객의 실제 업무 흐름에 맞춰 앱 구성을 재설계하고, 언제든 손을 내밀 수 있는 파트너십을 구축하자 상황은 180도 바뀌었습니다. 기술적 우수함을 증명하는 것은 개발자의 몫이지만, 그 기술이 고객의 성공으로 이어지게끔 경로를 설계하는 것은 우리의 몫 아닐까요?

<출처>

도쿄상공리서치(TSR), 「생성 AI에 관한 앙케트」 2025년 8월 18일 발표 (유효응답 6,645개사, 자본금 1억엔 기준 / 생성 AI 활용 추진: 대기업 43.3% vs 중소기업 23.4%) —
라그자스(ラグザス), 「기업의 AI 활용 격차 조사」 2026년 5월 25일 발표 (전국 비즈니스 퍼슨 3,000명, 2026년 4월 조사 / 중소기업 59.0%가 'AI 도입 예정 없음·필요성 못 느낌', 대기업 64.7% vs 중소기업 23.7%)
데이코쿠데이터뱅크(帝国データバンク), 「生成AIに関する企業の動向調査(2026年3月)」 2026년 5월 14일 발표 (1만 312사 유효응답, 전체 활용률 34.5%, 대기업 46.5%·중소기업 32.4%·소규모 28.0%, '대단히 효과 있다' 소규모 29.7% vs 대기업 20.8%), (PDF)
TechCrunch, "SoftBank-backed LegalOn lands $50M to streamline legal workflows with AI", 2025년 7월 (LegalOn 7,500+ 고객, 일본 상장사 25%, $200M funding, OpenAI 협력)
LegalOn Technologies 보도자료, 「ARR100억엔 돌파」 2025년 10월 14일 (2019년 4월 출시 후 6년 반, 일본 창업 AI 기업 최초)
LegalOn Technologies 보도자료, 「유료 도입 8,500사 돌파」 (2026년 3월말 기준 글로벌 8,500사, 일본 상장사 30% 이상 도입)
LegalForce 공식 사이트, (심사·수정 시간 평균 40% 단축 / 2024년 3월 사용자 223사 자체 조사, 도입 흐름)
LegalOn Technologies 공식 발표, Fides 인수 보도자료, 2025년 10월
LegalOn Technologies 블로그, "We Built AI Agents to Do the Work That Slows Legal Teams Down", 2025년

]]>

AI 답변 복붙이 우리 팀을 피곤하게 만드는 이유

본문은 요즘IT와 번역가 Yuna가 함께 웨슬리 웨이(Wesley Wei)의 글 〈AI Slop Is Becoming a Workplace Tax〉를 번역한 글입니다. 필자는 Go 언어와 엔지니어링 실무를 주로 다루는 소프트웨어 엔지니어로, AI가 개발자의 업무 환경에 미치는 영향에 관한 글을 써왔는데요. Medium을 중심으로 활동하며, AI 기술을 비판적 시각으로 살피는 퍼블리케이션 Ai-Ai-OH에도 꾸준히 기고하고 있습니다.

AI 도구가 일상적인 업무 곳곳에 자리를 잡으면서, 직장 내 소통의 방식도 조용히 달라지고 있습니다. 짧은 질문 하나에도 AI가 생성한 장문의 답변이 돌아오는 일이 점점 흔해졌지만, 그 과정에서 정작 필요했던 판단과 맥락은 빠져 있는 경우가 많습니다. 이 글은 AI가 생성한 콘텐츠가 직장 내 커뮤니케이션에 드리우는 보이지 않는 비용, 즉 구성원 모두가 치르게 되는 '소음의 세금'으로서 AI 슬롭 문제를 살펴봅니다.

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

<출처: Swello / Unsplash>

한 팀원이 슬랙에 이렇게 물었습니다. “이 서비스에는 Redis가 맞을까요, Memcached가 맞을까요?” 그러면 5초 뒤, 스레드에는 소제목과 트레이드오프, 각종 주의사항, 그리고 지나치게 균형만 잡느라 정작 결론을 내리지 못한 결론까지 붙은 번듯한 에세이가 올라왔죠. 아무도 문헌 리뷰를 부탁한 게 아니었습니다. 우리에게 필요했던 건 결정 하나였습니다.

이건 AI 시대에 생긴 꽤 낯선 마찰 중 하나입니다. 문제는 AI로 글을 쓰는 일 자체가 아니었죠. 저도 AI를 씁니다. 이 글도 AI의 도움을 받아 초안을 만들고, 거기에 제 문장과 판단을 덧대어 다듬었습니다. 앞으로는 대부분의 사람들이 비슷하게 일하게 될 겁니다. 문제는 무엇을 말해야 하는지 판단하는 일까지 AI에 넘겨버릴 때 시작됐습니다.

2026년 5월 22일, 이런 행동을 다룬 작은 페이지 하나가 Hacker News에 올라왔고 활발한 토론을 불러왔습니다. 제가 그 스레드를 읽었을 때 이미 400포인트를 넘겼고 댓글도 수백 개가 달려 있었죠. 그 페이지는 정말 짧았습니다. 거의 일부러 그렇게 만든 것처럼 보일 정도였죠. 그런데 사람들의 반응은 특정 웹사이트 하나 때문이 아니었습니다. 이미 많은 사람들이 직장에서 익숙하게 겪고 있던 장면이었기 때문입니다. 사람의 짧은 판단이면 충분했을 대화에, 누군가 AI가 쓴 긴 답변을 통째로 붙여 넣는 습관 말입니다.

그 원문이 생산성 손실이나 도입률, 통제된 실험 결과를 제시하는 건 아니었습니다. 그러니 마치 그런 근거가 있는 것처럼 말할 필요는 없었습니다. 다만 이 피로감 자체는 충분히 현실적이었고, 기존의 정보 과부하 연구와도 자연스럽게 이어졌습니다. Microsoft의 2023 Work Trend Index에 따르면, 조사 대상 직장인 중 64%가 “업무를 해낼 시간과 에너지가 부족하다”고 답했습니다. 68%는 “방해받지 않고 집중할 시간이 충분하지 않다”고 했죠. Asana의 2023 Anatomy of Work 보고서에서는 직장인들이 하루의 58%를 핵심 업무보다 조율 업무에 쓰고 있다고 분석했습니다.

여기에 손쉽게 찍어낼 수 있는 AI 장문 답변까지 더해보면 어떨까요? 축하할 일은 아니었습니다. 새로운 사무 노동 하나가 생겼을 뿐이니까요. 바로 누군가가 AI에 돌려받은 답변을 대신 읽어주는 일이었습니다.

1. 새로운 세금은 주의력으로 치러집니다

직장 내 커뮤니케이션은 원래도 의례가 너무 많았습니다. 상태 공유 회의가 있고, 사전 미팅이 있고, 회의 뒤에는 요약 메일이 따라왔습니다. 정렬 문서가 있었고, 의사결정 로그가 있었고, 티켓 코멘트와 Slack 스레드도 있었죠. 가끔은 안건도 없는 캘린더 초대까지 날아왔는데, 이쯤 되면 거의 조직적인 시간 낭비 아닌가 싶을 때도 있었습니다. AI가 이 혼란을 만든 건 아니었습니다. 다만 속도 제한을 없애버렸죠.

AI 이전에는 단순한 질문에 900단어짜리 답변을 쓰려면 그만한 수고가 필요했습니다. 그 수고가 일종의 마찰로 작동했죠. 정말 중요하게 생각하거나, 정말 헷갈리지 않으면 그 정도로 길게 쓰지 않았습니다. 이제는 텍스트를 생산하는 비용이 거의 0에 가까워졌지만, 읽는 비용은 여전히 그대로였습니다.

이 비대칭이 핵심이었습니다. 제가 20초 만에 답변을 생성해 올렸는데, 그걸 다섯 명이 각자 4분씩 읽어야 한다면 어떻게 될까요? 저는 생산적인 기분이 들 수 있었겠지만, 실제로는 제 일을 팀 전체에 떠넘긴 셈이었습니다. 팀은 총 20분의 주의력 세금을 낸 거죠.

주의력은 추상적인 가치가 아니었습니다. 개발팀에서 주의력은 장애를 디버깅하는 데 쓰였고, 아키텍처를 검토하는 데 쓰였고, 보안 가정을 의심해보는 데 쓰였습니다. 나중에 더 큰 비용으로 돌아올 제품 트레이드오프를 미리 포착하는 데도 결국 주의력이 필요했죠. 그런데 모든 대화가 AI가 뽑아낸 신중한 문장과 경고 문구로 가득한 스크롤 지옥이 되면, 사람들은 점점 꼼꼼히 읽지 않게 됐습니다.

그러면 정말 중요한 경고 한 줄이 일곱 단락짜리 “상황에 따라 다릅니다” 사이에 묻혀버렸죠. 팀 안에서는 텍스트가 많아질수록 오히려 공유된 이해가 줄어들 수 있었습니다.

2. AI는 부족한 판단도 그럴듯하게 포장합니다

이건 조금 불편한 이야기였습니다. AI가 만든 장문 답변은 얼핏 보면 꽤 인상적이었죠. 구조가 잘 잡혀 있었고, 불릿도 정리돼 있었고, 표현도 매끄러웠습니다. 누가 봐도 뭔가 공을 들인 결과물처럼 보였죠.

하지만 직장에서 글이 가치 있는 이유는 길어서가 아니었습니다. 현재 시스템이 어떤 상태인지, 마감이 얼마나 촉박한지, 우리 팀이 어느 정도의 리스크를 감수할 수 있는지, 질문한 사람이 지금 무엇을 결정해야 하는지 알고 있기 때문이었습니다. Redis와 Memcached를 일반론으로 비교하는 건 AI도 잘했습니다. 하지만 실제로 도움이 되는 답변은 “이 프로젝트에서는 무엇을 써야 하고, 왜 그래야 하는가”까지 말해주는 답변이었죠.

예를 들어, 팀 채팅에서 이런 답변은 도움이 되지 않았습니다.

Redis와 Memcached는 모두 널리 쓰이는 인메모리 데이터 저장소였습니다.
Redis는 풍부한 자료구조, 영속성, 복제, pub/sub, 스트림, Lua 스크립팅 등을 지원했습니다.
Memcached는 더 단순했고, 주로 기본적인 캐시 워크로드에 사용됐습니다.
어떤 선택이 맞는지는 지연 시간 요구사항, 운영 복잡도, 메모리 사용량, 영속성 필요 여부, 클러스터링 전략, 팀의 익숙함 등에 따라 달라졌습니다.

이런 답변이 더 도움이 됐습니다.

이 서비스에는 Redis를 쓰는 게 맞았습니다.
이유: 다음 분기에는 워커 간 캐시 무효화를 위해 pub/sub가 필요했고, 우리는 이미 운영 환경에서 Redis를 돌리고 있었습니다.
Memcached도 단순 키-값 캐시만 놓고 보면 가능했겠지만, 로드맵 관점에서 보면 얻는 것보다 관리해야 할 서비스만 하나 더 늘어나는 셈이었습니다.

두 번째 쪽이 더 짧았지만, 오히려 더 많은 판단이 담겨 있었습니다. 결정이 있었고, 이유가 있었고, 제약이 있었고, 앞으로의 시사점도 있었습니다. 팀원들이 반박하거나 보완할 출발점이 생겼죠. 반대로 첫 번째 답변은 모두에게 숙제를 던질 뿐이었습니다.

이 차이가 중요했습니다. AI는 성실해 보이는 결과물을 빠르게 만드는 데 탁월했죠. 균형 잡힌 비교도 순식간에 써냈습니다. 하지만 직장에서 정말 필요한 건 대개 더 좁고 더 어려운 일이었습니다. 맥락을 판단으로 바꾸는 일이었죠.

3. 진짜 문제는 형식이 어긋난다는 데 있습니다

저는 이걸 일종의 프로토콜 문제라고 봤습니다. 모든 커뮤니케이션 채널에는 그 채널에 맞는 응답의 크기와 형식이 있었습니다. PR 리뷰 코멘트는 아키텍처 의사결정 문서가 아니었고, 장애 대응 채널은 브레인스토밍 문서가 아니었습니다. Slack 한 줄 질문은 벤더 중립적인 백서를 요청한 게 아니었죠.

그런데 여기에 AI가 만든 긴 답변을 그대로 붙여 넣으면 프로토콜이 어긋났습니다. 그 부담은 읽는 사람이 떠안게 됐죠.

그래서 읽는 사람은 이런 걸 하나하나 다시 해석해야 했습니다.

어디까지가 실제 답변인가
어떤 내용이 우리 시스템 맥락에서 나온 것인가
보낸 사람은 실제로 무엇을 믿고 있는가
이 사람은 결정을 원하는 건가, 리뷰를 원하는 건가, 아니면 칭찬을 원하는 건가
여섯 번째 문단쯤에 숨은 리스크가 있는 건 아닐까

그래서 AI 장문 답변은 사람의 장황함보다 더 피곤하게 느껴졌습니다. 사람이 길게 말하면 적어도 의도가 드러나는 경우가 많았죠. 불확실해서 길어졌는지, 집착하고 있는지, 급한지, 혼란스러운지 어느 정도는 읽혔습니다. 반면 AI 문장은 지나치게 매끈했습니다. 톤은 자신감 있어 보이는데 내용은 애매할 때가 많았죠. 이 조합이 사람을 지치게 했습니다.

유용한 엔지니어링 체크리스트는 의외로 단순했습니다.

AI의 도움을 받은 문장을 보내기 전에는, 이렇게 물어봐야 했습니다.

이 메시지로 어떤 결정이나 행동이 가능해지는가
첫 문장만 읽어도 핵심이 전달되는가
나만 알고 있는 현장 맥락에 의존하는 부분은 무엇인가
결과를 바꾸지 않으면서 덜어낼 수 있는 문장은 무엇인가
내가 이 문장을 직접 하나하나 쳤어도 정말 이 길이로 보냈을까

마지막 항목이 가장 뼈아프기에 더 효과적입니다.

4. 전후를 비교해보면 차이가 더 분명해집니다

현실적인 직장 예시를 하나 떠올려보죠.

나쁜 버전은 이랬습니다.

OAuth callback 이슈 때문에 출시를 미뤄야 하는지 AI 도구에 물어봤습니다.
도구는 고려할 점이 여러 가지라고 했습니다.
한편으로는, 알려진 인증 버그를 안고 출시하면 사용자 신뢰를 해치고, 지원 부담을 늘리며, 보안 우려를 만들 수 있다고 했습니다.
다른 한편으로는, 출시를 미루는 일이 이해관계자의 신뢰와 로드맵 약속에 영향을 줄 수도 있다고 했습니다.
따라서 팀은 심각도, 사용자 영향, 롤백 가능성, 모니터링, 커뮤니케이션 계획을 검토한 뒤 결정해야 한다고 했습니다.

책임감 있어 보였죠. 하지만 막상 읽고 나면 남는 건 별로 없었습니다.

더 나은 버전은 이랬습니다.

출시는 24시간 미루는 게 좋겠습니다.
이유: Safari에서 기존 세션이 있는 사용자에게 OAuth callback이 실패하고 있었고, 지원팀은 아직 로그만으로는 어떤 계정이 영향을 받는지 식별할 수 없었습니다.
계획: 오늘 패치하고, callback 실패를 보는 대시보드를 추가한 뒤, 내일 아침 30분 검증을 돌리고, 오류율이 0.5% 아래로 유지되면 그때 배포하겠습니다.

두 번째 메시지가 AI를 쓰지 말자는 뜻은 아니었습니다. 원한다면 AI로 초안을 잡아도 됐습니다. 메모를 압축하는 데 써도 됐고, 빠진 리스크를 점검하는 데 써도 됐고, 최종 문장을 더 명확하게 다듬는 데 써도 됐죠. 다만 생각의 거품까지 그대로 방에 쏟아놓고, 그걸 협업이라고 부르지는 말자는 얘기였습니다.

바람직한 워크플로는 이렇습니다.

정리된 맥락
AI 보조 압축
인간의 판단
요청이 분명한 짧은 메시지

반대로 좋지 않은 워크플로는 이렇습니다.

정리되지 않은 맥락
AI 확장
나머지 모두가 뒷정리

한쪽은 팀이 다음 단계로 나아가게 만들었고, 다른 한쪽은 아무도 맡기로 한 적 없는 집단 편집 작업만 남겼죠.

5. 물론 길게 써야 할 때도 있습니다

반론도 진지하게 들어볼 필요가 있었습니다. 어떤 질문은 실제로 깊이 있는 답변이 필요했죠. “Redis가 맞나요, Memcached가 맞나요?” 같은 질문도 어떤 시스템에서는 단순했지만, 다른 시스템에서는 매우 중요한 결정일 수 있었습니다. 마이그레이션 계획, 개인정보 검토, 장애 회고, 데이터베이스 일관성 같은 주제는 충분히 긴 문서가 필요할 수 있었죠.

그러니까 원칙은 “짧을수록 무조건 좋다”가 아니었습니다. 그 또한 다른 종류의 단순화였죠.

원칙은 답변의 크기를 결정의 크기에 맞추는 것이었습니다.결정이 작다면 답을 먼저 주고, 필요하면 링크나 부록을 뒤에 붙이면 됐습니다. 결정이 크다면 담당자, 제약 조건, 선택지, 피드백 기한이 있는 구조화된 문서를 써야 했죠. 탐색적인 대화라면 그것부터 분명히 밝혀야 했습니다. 길더라도 목적이 분명한 글은 문제가 아니었습니다. 답인 척하지만 실제로는 답을 미루는 긴 글이 문제였죠.

그리고 장황한 메시지를 무조건 게으르다고 볼 수도 없었습니다. 문화, 언어, 연차, 성향이 다를 수 있으니까요. 어떤 사람은 정확하게 쓰려고 애쓰느라 길어졌고, 어떤 사람은 자신감이 부족해서 더 많이 설명하게 됐습니다. 어떤 사람은 언어와 직장 문화 사이를 두 번 번역하듯 글을 쓰기도 했죠.

다만 AI 이후에는 전제가 달라진 것도 사실이었습니다. 예전에는 긴 답변이 적어도 시간을 썼다는 신호였는데, 이제는 버튼 한 번 눌렀다는 뜻일 수도 있게 됐으니까요. 그래서 발신자에게는 새로운 책임이 생겼습니다. 판단한 부분을 직접 드러내는 책임이었죠.

이럴 때는 한 문장만으로도 충분했습니다.

AI로 메모를 정리해봤고, 제 판단은 이번에는 Redis를 쓰는 게 맞습니다.

이 정도면 충분했습니다. 도구를 썼다는 사실은 드러내되, 판단과 책임은 여전히 사람에게 있다는 점을 분명히 해줬으니까요.

6. 장황함을 줄이는 것도 제품의 역할입니다

이건 에티켓의 문제만은 아니었습니다. 제품 설계의 문제이기도 했죠.

요즘 협업 도구들은 곳곳에 AI 버튼을 붙이고 있었습니다. 그런데 그 버튼의 기본값이 전부 “생성하기”여야 할까요. 저는 꼭 그렇지는 않다고 봤습니다. 오히려 더 자주 필요한 건 “요약하기”, “결정만 추리기”, “열린 질문 정리하기”, “3문장 답변으로 압축하기” 같은 기능이었죠. 제품은 규범을 만들었습니다. 크고 화려한 작성 버튼은 사람들에게 계속 더 많이 생산하라고 가르쳤죠. 하지만 좋은 협업 도구는 줄이는 방향으로도 사용자를 도와야 했습니다.

이런 장치가 있다면 어떨까요?

활발한 스레드에서 긴 답변을 쓰려 할 때 “결정을 먼저 적어보세요”라고 안내하기
생성된 답변이 질문보다 지나치게 길면 경고하기
“추천안으로 압축하기” 같은 원클릭 기능 제공하기
바쁜 채널에 올리기 전에 “내가 실제로 원하는 것”을 먼저 입력하게 하기
스레드 요약에서 사실, 의견, 결정, 미해결 질문을 구분해서 보여주기

물론 트레이드오프는 있었습니다. 제약이 지나치면 사람들은 금방 피로해졌죠. 글을 쓴다고 혼내는 도구를 좋아할 사람은 없었습니다. 하지만 이런 기본 설정은 분명 도움이 됐습니다. 좋은 인터페이스는 사용자를 민망하게 만들지 않았습니다. 대신 꼭 필요한 말이 먼저 나오도록 도와줬죠.

AI 벤더들은 흔히 글의 양을 생산성으로 포장했습니다. 하지만 협업에서는 분량이 잘못된 지표인 경우가 많았죠. 진짜 중요한 건 적절한 사람들이 충분한 맥락을 공유한 상태에서, 다음 행동에 얼마나 빨리 합의할 수 있느냐였습니다.

7. 결국 직접 말해야 합니다

직장에 필요한 건 더 그럴듯한 문단이 아닙니다. 더 분명한 책임감이었죠. 내가 팀원에게 추천을 물었다면, 중립을 흉내 내달라는 뜻이 아니었습니다. 그 사람이 가진 현장 맥락을 써달라는 뜻이었죠. 본인 생각을 말해달라는 뜻이었습니다. 어떻게 보는지 말해주고, 왜 그렇게 판단하는지 설명해주고, 딱 하나 놓치면 안 되는 주의사항을 짚어주고, 어디까지는 확신하고 어디부터는 불확실한지 보여주면 됐습니다. 그리고 거기서 멈추면 됐죠.

AI는 분명 커뮤니케이션을 더 좋게 만들 수 있었습니다. 하지만 그건 결과물을 부풀릴 때가 아니라, 의도를 더 또렷하게 만들 때만 가능합니다. 제가 바라는 미래는 모든 채팅 메시지가 미니 컨설팅 보고서가 되는 세상이 아니었습니다. 잘 다듬어진 군더더기 속에서 의미를 발굴하느라 시간을 쓰는 대신, 원래 하려던 일을 더 많이 할 수 있는 환경이었죠.

다음에 AI가 뽑아준 답변을 그대로 붙여 넣고 싶어질 때, 기준은 이 정도면 충분했습니다. 내가 직접 판단하지 않은 말로, 다른 사람의 시간을 쓰게 하는 건 옳지 않으니까요.

<원문>

AI Slop Is Becoming a Workplace Tax

]]>

990원이 찍혔다: 바이브 코딩이 유료 서비스가 되기까지

지난 글 “바이브 코딩으로 7일간 900커밋, 디자이너의 앱 출시기”에서는 디자이너가 바이브 코딩으로 '문채'라는 앱을 7일 만에 세상에 내놓은 이야기를 들려드렸습니다. 감사하게도 많은 분들이 관심을 가져주셨는데요. 사실 그 글에서 슬쩍 언급했던 제 첫 번째 프로젝트가 하나 더 있습니다. 바로 카카오톡 대화를 AI로 분석해 주는 ‘톡시그널(Toksignal)’이라는 웹 서비스입니다.

저는 톡시그널을 아이디어부터 웹 제작까지 단 3일 만에 완성했습니다. 그러나 진짜 현실은 웹을 다 만들고, 이 서비스를 '유료'로 전환하겠다고 마음먹은 순간부터였습니다. '990원'을 받기 위해 결제 심사, 복잡한 서류 작업, 개인정보 보호, 보안 규정 같은 현실의 벽을 마주해야 했죠. 서비스 완성도와 신뢰 구조를 갖추는 과정이 가장 큰 도전이었는데요. 웹을 만드는 것보다 더 어려운 건 990원을 받는 거였습니다. 이번 글은 그 여정에 대해 전해드리려고 합니다.

<출처: 작가>

시작은 사소한 호기심에서

카카오톡 대화에서 설정 창을 열어보면, ‘대화 내보내기’ 기능이 있습니다. 버튼을 누르면 텍스트 파일(txt)이 다운로드 되는데요. 어느 날 이걸 AI한테 던져봤습니다. “이 대화 분석해 줘.” 그런데 결과가 생각보다 너무 흥미진진했습니다. 누가 먼저 연락하는지, 대화의 온도는 어떤지, 관계 패턴이 어떤지, 숫자로 보니까 느낌이 아니라 신호가 보였습니다. “이거 나만 재밌는 게 아닐 것 같은데?”라고 생각했죠.

<출처: 작가>

처음에는 단톡방 분석기로 시작했습니다. 누가 어떤 말을 많이 하는지 분석할 용도로 만들었죠. 그런데 사용해 보니 2인 대화가 훨씬 재밌었습니다. 연인, 썸, 친구 등 두 사람 사이의 대화에는 관계의 온도가 고스란히 담겨 있었거든요.

<출처: 작가>

이름은 여러 후보가 있었는데 ‘톡시그널(Toksignal)’로 확정했습니다. 카카오톡과 시그널을 합친 단어로 “대화 속에 숨어 있는 관계의 신호”라는 뜻입니다. 2월 27일에 아이디어를, 다음 날인 2월 28일에 동작하는 웹까지 하루 만에 만들었습니다. 여기까지는 빠릅니다. 바이브 코딩이니까요. 문제는 그다음부터 시작이었죠.

호기심에서 웹까지

<출처: 작가>

이전 글에서 소개한 문채(문장 채집 앱)는 제가 필요해서 만든 앱이었지만, 톡시그널은 방향이 조금 달랐습니다. 제가 필요해서 만들었다기보단, 카카오톡 대화를 내보내기 해서 직접 분석해 봤을 때 “이거 재밌겠는데?”라는 생각이 먼저였죠. UX/UI 개선, 코드 오류 수정, 베타 테스트까지 3일 만에 끝냈습니다. 그다음 지인에게 실제 카카오톡 대화를 올려보라고 부탁했더니, 피드백이 쏟아졌습니다. “분석 결과가 이상하다”, “글씨가 잘린다”, “이 버튼이 뭔지 모르겠다”, “후킹이 아쉽다” 등의 의견울 줘서 하나씩 고쳐나갔습니다.

여기까지는 수정을 반복하는 과정이 문채와 비슷했습니다. 코드를 만드는 건 바이브 코딩으로 충분했으니까요. 그런데 톡시그널은 결정적으로 다른 점이 하나 있었습니다. 바로 사용자에게 돈을 받기로 했다는 겁니다.

“돈을 받겠다”고 결정한 순간

이날부터 모든 게 달라졌습니다. 저는 바로 도메인을 샀습니다. 그리고 결제 시스템은 토스페이먼츠(Toss Payments)를 골랐죠. 심사를 넣고 직접 결제를 붙이는 것은 바이브 코딩으로 그냥 웹사이트를 만드는 것과는 완전히 다른 일이었습니다. 결제를 붙이려면 사업자등록증, 통신판매업 신고, 개인정보 처리방침이 사이트에 노출되어야 하고, 환불 정책도 명시해야 합니다. 코드로 결제창을 띄우는 것까진 클로드가 해줬습니다. 그런데 서류 준비, 심사 자료 정리, 법적 요건 등은 AI가 대신해 줄 수 없었죠.

<출처: 작가>

같은 날 저는 카카오 소셜 로그인, 구글 소셜 로그인, 분석 결과 저장, 어드민 대시보드까지 넣었습니다. 보안 PR도 4개를 머지했습니다. 결제가 들어가니까 누군가 결제를 조작하면 어쩌지라는 생각이 들고, 보안이 걱정됐습니다. 그래서 클로드에게 보안 전문가 역할을 시켜 하나씩 점검했고, 결제 관련 코드는 직접 동작을 확인하며 일일이 테스트했습니다. 돈을 받는 순간, 버그는 버그가 아니라 사고가 됩니다. 990원이든 99,000원이든, 돈을 낸 사용자에게 오류는 신뢰의 문제였습니다.

코드를 안 쓴 날

<출처: 작가>

토스페이먼츠에 심사를 넣고 기다리는 동안, 법적 리스크도 검토했습니다. 카카오톡 대화를 분석하는 서비스다 보니 민감한 지점이 많았거든요. 가장 오래 고민한 질문이 있었습니다. “대화 상대방의 동의 없이 대화를 분석해도 되는 걸까?” 결론부터 말씀드리면, 카카오톡 ‘대화 내보내기’는 본인이 참여한 대화만 추출할 수 있습니다. 타인의 대화를 몰래 가져오는 게 아닙니다. 그래서 대화의 패턴과 관계 흐름만 분석할 뿐, 누가 무슨 말을 했는지 원문이 그대로 타인에게 공개되는 구조가 아닙니다.

그래도 충분하지 않다고 생각했습니다. 이용 약관에 AI 활용 표기를 넣었고, 분석 전 동의 절차를 추가했습니다. “상대방의 동의를 권고한다”라는 안내 문구도 포함했습니다. 물론 이게 완벽한 답은 아닐 수 있습니다. 하지만 이 문제를 무시하고 그냥 넘어가는 것과 고민 후 최선의 장치를 마련하는 것은 다르다고 생각했죠.

그리고 데이터 구조 자체를 저장되지 않게 설계했습니다. 사용자가 대화 파일을 업로드하면 서버에서 AI 분석이 돌아가고, 분석이 끝나는 즉시 원본 파일은 삭제됩니다. 서버에 남는 건 분석 결과 요약뿐이고, 원문 대화 내용은 어디에도 저장되지 않습니다. 운영자인 저조차도 볼 수 없는 구조입니다. “안 보겠습니다”가 아니라 “볼 수 없습니다”를 만들고 싶었거든요.

기다림, 그리고 디테일의 늪

<출처: 작가>

그래서 토스페이먼츠 심사를 기다렸습니다. 그리고 분석 실패 시에 자동 복구되는 기능도 넣었습니다. 990원을 냈는데 제대로 분석이 안 되면 그건 사고니까요. AI가 가끔 이상한 걸 주거나, 타임아웃이 나서 자동으로 재시도하는 로직을 만들었습니다.

다음으로 PG사마다 요구하는 게 달라서, 카카오페이 심사 자료를 정리했습니다. 디자인도 많은 수정을 거쳤는데요. 이모지를 제거하고 넘버링으로 교체했습니다. 공유 카드 헤드라인은 고정 문구 대신 매번 다른 헤드라인이 나오도록 동적으로 바꿨습니다. 데이터를 저장하지 않는 부분에 대한 강조 문구도 추가하고, 히어로 섹션 최상단에 신뢰 배너도 넣었습니다.

마지막으로 가트맨의 관계 이론과 로버트 스턴버그의 삼각형 이론을 AI 분석 근거로 적용했습니다. AI가 학술적 프레임워크에 기반해 분석한다는 걸 보여주고 싶었거든요.

인앱 브라우저에 대한 이슈도 이때 잡았습니다. 카카오톡에서 링크를 열면 카카오 인앱 브라우저가 뜨는데, 여기서 분석 결과 카드가 저장되지 않았거든요. 명색이 카카오톡 기반 서비스인데, 카카오 인앱 브라우저에서 저장이 안 된다면 치명적이라 생각했습니다.

가격 정책: 990원의 무게

<출처: 작가>

서비스의 가격, 어떻게 정해야 할까요? 너무 저렴하면 가치를 못 느끼고, 또 너무 비싸면 재미로 해보는 사용자가 오지 않습니다. “한번 사용해 볼까?” 할 수 있는 심리적 허들이 필요했습니다.

지금은 매달 50명 한정으로 로그인하면 첫 1회 분석을 무료로 제공하고 있습니다. 맛보기 프리뷰와는 다릅니다. 맛보기는 결과 일부만 보여주는 거고, 1회 무료는 전체 분석을 그대로 경험할 수 있습니다. 서비스의 가치를 직접 느낀 다음에 990원이라는 가격을 판단하게 하고 싶었습니다. “한번 써보고 결정하세요.”가 가장 정직한 설득이라고 생각했거든요.

PG 수수료, 서버비, AI API 호출 비용 등을 빼면 솔직히 건당 남는 건 별로 없습니다. 그래도 내가 만든 서비스에 누군가 돈을 냈다는 경험 자체가 중요했죠. 요즘 바이브 코딩으로 서비스를 만드는 사람은 정말 많아졌습니다. 그런데 결제를 붙이고, PG 심사를 통과하고, 법적 요건을 갖추고, 진짜 돈을 받는 과정까지 가는 사람은 많지 않습니다. 저는 그 사이가 생각보다 멀다고 느꼈습니다.

혼자 삽질하며 배운 것들

코드보다 서류 심사가 더 오래 걸린다: PG 심사가 영업일 기준 7일, 카드사 심사가 또 7일이나 걸립니다. 코드는 하루면 되는데 심사는 2주를 기다려야 합니다.
돈 받는 순간 기준이 달라진다: 무료일 때는 괜찮았던 버그가 유료에서는 사고가 됩니다. 에러 처리, 자동 복구, 환불 정책 이 세 가지는 결제 전에 반드시 갖춰야 합니다.
개인정보를 과소평가하지 마라: 개인정보 처리방침, 데이터 삭제 정책, 동의 절차는 나중에 하면 안 되고 처음부터 해야 합니다. 특히 대화 데이터를 다루는 서비스라면, “저장하지 않는다”를 약속이 아니라, 구조로 만들어야 합니다.
무료 체험은 필수다: 990원이라도 직접 써본 다음에 결제해야 납득이 됩니다. 맛보기 프리뷰와 1회 무료 분석, 이 두 단계가 전환율을 만들었습니다.
인앱 브라우저를 반드시 테스트해라 : 카카오톡, 인스타그램에서 링크를 열면 인앱 브라우저로 열립니다. 여기서 안 된다면 주요 유입 경로가 막힌 겁니다.

그래서 지금은?

<출처: 작가>

톡시그널은 지금도 서비스되고 있습니다. 아이디어에서 결제까지 만드는 건 며칠이면 되지만, 사용자에게서 돈을 받는 건 다른 차원의 일이었는데요. 이전 글에서 “바이브 코딩이 마법의 ‘딸깍’은 아니다”라고 말씀드렸는데, 이번에도 같은 이야기를 하게 됐습니다.

직접 경험해 보니 바이브 코딩의 진짜 도전은 코드를 생성하는 일이 아니었습니다. 그 코드를 온전한 서비스로 탈바꿈하는 것이었죠. 그리고 그 서비스로 수익을 창출하는 건 또 다른 과제였습니다. 여러분도 바이브 코딩을 하며, 비슷한 고민을 해보셨나요?

<참고>

]]>

같은 주에 나온 GPT-5.6과 Grok 4.5, 정부가 먼저 검토한 모델은

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

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

써볼 것: Grok 4.5 - 커서와 함께 만든 SpaceXAI의 새 모델, 지금 써볼 수 있어요
참고할 것: 오픈AI의 GPT-Live와 GPT-5.6 소개, 그리고 정부 승인 이야기 (내용이 좀 깁니다)
적용해볼 것: 클로드코드 팀이 정리한 루프 사용법 - AI에게 어디까지 맡길지 정하는 법

<출처: x.ai, Introducing Grok 4.5>

1. 써볼 것: 커서와 함께 만든 SpaceXAI의 새 모델, 지금 써볼 수 있어요

Grok 4.5는 SpaceXAI가 7월 8일 공개한 새 모델입니다. 코딩과 에이전트 작업은 물론 데이터 분석이나 문서 작업 같은 지식 노동까지 겨냥했는데요. 이미 커서나 Grok Build(SpaceXAI의 코딩 에이전트 도구)를 쓰고 있다면 지금 바로 Grok 4.5를 써볼 수 있습니다. 커서는 전 요금제에 포함돼 첫 주 사용량을 두 배로 주고, Grok Build는 SuperGrok이나 X Premium+ 구독자에게 한시적 무료로 제공됩니다.

SpaceXAI는 이 모델을 코딩 에이전트 커서와 함께 훈련했습니다. SpaceXAI는 일론 머스크가 이끄는 회사로, 원래 xAI였다가 SpaceX가 2026년 2월 흡수하면서 이름이 바뀌었습니다. 6월 중순 SpaceX가 커서를 600억 달러에 인수하겠다고 발표했으며, 이 딜은 올해 3분기에 마무리될 예정입니다. 오늘 소개할 Grok 4.5는 그 둘의 협력에서 나온 첫 모델입니다.

기존 커서 모델과 무엇이 다른가요?

커서에는 이미 Composer라는 자체 코딩 모델이 있었습니다. 코딩만 빠르고 싸게 처리하도록 좁게 다듬은 모델이었고, 중국 Moonshot AI의 오픈 모델 Kimi를 이어 학습해 만들었죠. Grok 4.5는 처음부터 더 크고 넓게 학습했습니다. 코딩뿐 아니라 데이터 분석, 금융, 법률 같은 지식 노동까지 다루도록요. SpaceXAI는 법률 작업 성능을 재는 Harvey Legal Agent Benchmark에서 1위를 기록했다고 밝혔고요.

훈련에는 수조 개 토큰 분량의 실제 커서 사용 기록이 들어갔습니다. 개발자가 코드베이스를 어떻게 다루는지, 에이전트가 도구를 어떻게 쓰는지가 담긴 데이터죠. 코딩 에이전트 회사와 손잡았기에 확보할 수 있던 데이터입니다.

<출처: cursor, grok-4-5>

실제 성능은 어떤가요?

성능은 발표만 보고 판단하기 어렵습니다. 항목마다 성적이 다르거든요. SpaceXAI는 다른 주요 모델보다 낫다고 했지만, 자기네가 공개한 벤치마크 차트를 봐도 앞서는 항목이 있고 뒤처지는 항목이 있습니다. 명령줄 작업을 재는 Terminal-Bench 2.1에서는 83.3%로, GPT-5.5(83.4%)와 거의 같고 Fable 5(84.3%)에 1점 차로 따라붙습니다. 반면 어려운 소프트웨어 문제를 모은 SWE-Bench Pro에서는 64.7%에 그쳐, Opus 4.8(69.2%)이나 Fable 5(80.3%)에 뒤처집니다. 네 개 벤치마크를 놓고 보면 대체로 Fable 5가 앞서고요.

그래서 이 모델의 강점은 벤치마크 순위가 아니라 작업 하나를 끝내는 데 드는 비용입니다. Grok 4.5는 100만 토큰 기준 입력 $2, 출력 $6에 초당 80토큰 속도로 제공됩니다. Opus 4.8이 입력 $5, 출력 $25인 걸 보면 꽤 저렴한 편이죠. SpaceXAI는 토큰 효율도 최신 선도 모델의 약 두 배라고 밝혔습니다. 같은 작업을 더 적은 토큰으로 끝내니, 실제로 드는 비용 차이는 가격표보다 더 벌어지는 셈입니다. 더 빠른 응답이 필요하면 입력 $4, 출력 $18짜리 빠른 변형도 있고요.

블룸버그는 코딩을 넘어 법률·금융까지 겨냥한 이번 모델을, 머스크의 회사가 두 경쟁자(앤트로픽·오픈AI)와 같은 시장에서 붙어보려는 신호로 읽습니다. 뒷이야기도 하나 있는데요. 여러 보도에 따르면 SpaceXAI는 앤트로픽과 구글에도 연산 자원, 즉 AI 훈련에 쓰는 대규모 컴퓨팅 설비를 빌려주는데, Grok 4.5도 그 일부에서 훈련됐다고 합니다. 경쟁사끼리 같은 설비를 나눠 쓰는 셈이죠.

누구에게 좋을까요?

이미 커서를 쓰고 있는 사람. 쓰던 환경에서 모델만 Grok 4.5로 바꿔 부담 없이 성능을 가늠해볼 수 있어요.
코딩 외에 문서 작업까지 AI에 맡기고 싶은 사람. Grok Build는 웹 조사와 여러 시트 수식이 들어간 엑셀, 파워포인트, 워드 작업도 다룹니다.
작업량이 많아 토큰 비용이 부담인 사람. 벤치마크 최상위보다 작업당 비용이 중요한 상황이라면 잘 맞습니다.
반대로 순수 코딩 성능이 최우선이거나 EU에서 쓰려는 사람에게는 아직 이릅니다. EU는 7월 중순 지원 예정이고, 코딩 성능만 놓고 보면 Fable 5나 GPT-5.5가 앞서는 항목이 많으니까요.

<출처: OpenAI>

2. 참고할 것: 오픈AI의 GPT-Live와 GPT-5.6 소개, 그리고 정부 승인 이야기

새 AI 모델이 나오면 보통 언제 써볼 수 있나부터 궁금해지죠. 그런데 오픈AI의 새 모델 GPT-5.6은 나올 때부터 아무나 쓸 수 없었습니다. 누가 먼저 쓸지를 미국 정부가 정했거든요.

사정은 이렇습니다. 오픈AI는 6월 26일 GPT-5.6을 공개하면서, 미국 정부와 협의한 결과 정부에 명단을 공유한 소수의 신뢰 파트너에게만 먼저 열겠다고 밝혔습니다. 여러 매체는 이를 대략 20개 조직이 개별 승인된 사례로, 미국 AI 기업이 정부 관리 명단 아래 프런티어 모델을 처음 출시한 일로 전했어요. 배경에는 6월 2일 나온 사이버보안 관련 행정명령이 있습니다. 가장 강력한 모델을 공개 전에 정부 검토에 올리도록 한 조치인데요. 지난 주 요즘 프로덕트 메이커에서 다룬 앤트로픽 Fable 5의 수출 통제도 같은 맥락입니다.

오픈AI는 자사 발표문에서 이 방식에 선을 그었습니다. 이런 정부 접근 절차가 장기적인 기본값이 돼선 안 된다고 밝혔거든요. 필요한 사람에게서 최선의 도구를 떼어놓는 일이라는 이유였습니다. 그러면서도 지금은 더 넓은 공개로 가는 가장 확실한 길이라 따른다고 했고요.

이 이야기는 사실 마무리됐습니다. 오픈AI가 7월 8일, 다음 날인 9일부터 GPT-5.6 Sol과 Terra, Luna를 일반에 공개한다고 밝혔거든요. 미국 상무부가 추가 검토와 협의를 거쳐 넓은 공개를 승인하면서, 2주 남짓 이어지던 정부 게이팅도 풀렸습니다. 이제는 누구나 쓸 수 있게 된 겁니다.

GPT-5.6은 어떤 모델인가요?

앞서 정부 게이팅에 관심이 쏠렸는데, 모델 자체는 어떨까요. GPT-5.6은 세 등급으로 나뉩니다. 플래그십 Sol, 일상 작업용 Terra, 빠르고 저렴한 Luna죠. 숫자는 세대를, Sol·Terra·Luna는 성능 등급을 뜻해요. 오픈AI 발표에 따르면 Terra는 GPT-5.5급 성능에 절반 가격입니다. 가격은 100만 토큰 기준 Sol이 입력 $5·출력 $30, Terra가 $2.50·$15, Luna가 $1·$6이고요.

오픈AI는 코딩·생물학·사이버보안에서 나아졌다고 밝혔는데, 이 수치들은 자체 평가라는 점을 감안해서 봐야 합니다. 특히 사이버보안이 정부가 주목한 대목이에요. 오픈AI 발표에 따르면 GPT-5.6 Sol은 취약점을 찾고 고치는 데는 강하지만, 테스트 조건에서 자율적으로 완전한 공격을 끝까지 수행하지는 못했고, 회사가 정한 위험 문턱은 넘지 않았습니다. 그래서 모델에 학습된 거부, 실시간 오용 분류기, 계정 검토 같은 여러 겹의 안전장치를 함께 붙였다고 해요.

<출처: openai.com, introducing-gpt-live>

대화는GPT-Live가, 어려운 생각은 뒤에서

GPT-5.6과 같은 주, 7월 8일에 오픈AI가 GPT-Live도 공개했습니다. ChatGPT의 새 음성 모델인데요. 오픈AI 발표에 따르면 매주 1억 5천만 명 넘게 음성으로 ChatGPT와 대화할 만큼, 음성은 이미 많은 사람이 쓰는 기능입니다. 이전 음성 기능은 사용자가 말을 멈출 때까지 기다렸다가 답을 해주는 쪽이었습니다. GPT-Live는 여기서 듣기와 말하기를 동시에 합니다. 대화 도중 음, 그래처럼 사람이 흔히 넣는 맞장구를 치기도 하고, 사용자가 생각하느라 잠깐 말을 멈춰도 끼어들지 않고 기다려준다고 합니다.

또 GPT-Live는 사용자와 말을 주고받는 데만 집중하고, 웹 검색이나 복잡한 추론처럼 시간이 걸리는 일은 뒤에 있는 더 똑똑한 모델(출시 시점엔 GPT-5.5)에 맡깁니다. 사용자가 어려운 걸 물으면 뒤 모델이 답을 찾는데, 그동안에도 GPT-Live가 대화를 이어가서 끊기는 느낌이 없죠. VentureBeat는 이 점을 두고, 더 똑똑해진 게 아니라 더 사람처럼 느껴지게 만든 것이라고 짚었습니다. 성능 경쟁과 별개로, 음성 대화에서 사용자가 실제로 느끼는 건 모델이 얼마나 똑똑한가보다 말이 얼마나 자연스럽게 오가는가라는 걸 짚은 접근이죠.

무엇을 얻어가야 하나요?

OpenAI는 이번 주에만 발표를 두 개 내놨습니다. 하나는 사람과 자연스럽게 대화하는 GPT-Live, 다른 하나는 어려운 추론을 더 잘하는 GPT-5.6입니다. 이 둘은 따로 쓰이는 모델이지만, 함께 맞물리기도 합니다. GPT-Live가 앞에서 사용자와 대화하다가 어려운 건 뒤에 있는 더 강력한 모델에 넘기는데, 지금은 그 자리에 GPT-5.5가 쓰이고 앞으로 GPT-5.6 같은 모델이 들어갈 수도 있죠. 이렇게 대화하는 쪽과 깊이 생각하는 쪽을 나눠두면, 둘을 따로 손볼 수 있습니다. 뒤에서 추론하는 모델만 더 좋은 걸로 바꿔도, 앞에서 대화하는 방식은 그대로 두고 답만 똑똑해지니까요.

프로덕트에 AI를 넣을 때, 우리는 흔히 가장 좋은 모델 하나를 골라 모든 일을 시킵니다. 그런데 OpenAI는 빠르게 답해야 하는 일과 오래 생각해야 하는 일을 처음부터 나눠, 서로 다른 모델에 맡겼습니다. 모든 걸 최고 모델에 몰면 느린 데다 비용 부담도 크니까요. 요청을 성격별로 갈라 쉬운 건 싸고 빠른 모델에, 어려운 것만 강력한 모델에 넘기면, 같은 결과를 훨씬 싸고 빠르게 낼 수 있습니다.

개발자라면 요청마다 다른 모델을 호출하도록 짜는 방식이고, 직접 개발하지 않더라도 적용할 원리는 같습니다. 단순 반복 작업은 빠른 모델에 맡기고, 판단이 필요한 작업만 가장 좋은 모델로 돌리는 거죠. 사실 우리가 AI에 시키는 일을 돌아보면, 굳이 비싼 모델이 필요 없는 작업에도 습관적으로 제일 좋은 모델을 부르는 경우가 꽤 있죠.

<출처: ClaudeDevs>

3. 적용해볼 것: 클로드코드 팀이 정리한 루프, AI에게 어디까지 맡길지 정하는 법

요즘 X에서는 프롬프트를 하나하나 넣는 대신 루프를 설계하라는 말이 자주 보입니다. 그런데 막상 루프가 뭔지 찾아보면 사람마다 정의가 조금씩 다르죠. 클로드 코드 팀이 이 개념을 정리한 글을 냈습니다. 6월 30일 블로그에 올라왔고, 7월 7일 X에서 공유되며 현재는 조회수 550만을 넘겼죠.

이 글은 루프를 무엇을 AI에 넘기느냐로 풀어냅니다. 클로드코드 전용 기능 이야기가 섞여 있지만, 핵심이 되는 관점은 어떤 AI 도구를 쓰든 그대로 옮겨 쓸 수 있죠. 여기서는 그 관점 위주로 정리해봅니다.

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

AI에게 일을 시킬 때 우리는 대개 매번 지시하고 결과를 확인합니다. 시키고, 보고, 다시 시키고요. 이걸 반복하다 보면 사람이 계속 붙어 있어야 합니다. 그런데 반복되는 일일수록, 지시하는 사람이 매번 개입하지 않아도 되는 부분이 생기죠. 클로드코드 팀은 이 개입을 어디까지 줄일 수 있는지를 네 단계로 정리했습니다.

루프를 네 단계로 나누면

클로드코드 팀은 루프를 멈춤 조건이 충족될 때까지 작업을 반복하는 에이전트로 정의합니다. 그리고 무엇을 사람이 넘기느냐에 따라 네 가지로 나눴어요.

턴 기반: 넘기는 건 검사입니다. 사용자가 시킬 때마다 AI가 작업하고, 다 됐다고 판단하면 멈춥니다. 짧은 작업에 맞는 방식입니다. 확인 방법을 지침 문서로 정리해두면 AI가 스스로 더 많이 점검합니다.
목표 기반: 넘기는 건 멈춤 조건입니다. 무엇이 됐을 때 끝인지를 정해주면 AI가 그 조건을 채울 때까지 반복합니다. 테스트 통과 개수처럼 명확히 잴 수 있는 기준일 때 잘 통합니다.
시간 기반: 넘기는 건 트리거입니다. 정해진 간격으로 AI가 알아서 돌게 합니다. 매일 아침 메시지를 요약하거나, PR 상태를 주기적으로 확인하는 식이죠.
능동: 넘기는 건 지시 자체입니다. 사람이 실시간으로 개입하지 않고, 이벤트나 일정에 따라 AI가 알아서 돕니다. 버그 리포트 분류나 마이그레이션처럼 잘 정의된 반복 작업에 맞아요.

핵심은 뒤로 갈수록 사람이 손 대지 않는 부분이 늘어난다는 겁니다. 처음엔 결과가 제대로 됐는지 확인하는 일을 넘기고, 다음엔 언제 멈출지, 그다음엔 언제 시작할지를 맡깁니다. 마지막엔 무엇을 시킬지까지 AI가 알아서 정하게 두고요. 넘기기 쉬운 일부터 맡기고, 큰 판단일수록 나중에 넘기는 거죠. 지금 가장 손이 많이 가는 일을 하나 떠올려보세요. 지금 가장 손이 많이 가는 일을 하나 떠올려보세요. 그 일의 어디까지 AI에 맡길 수 있을지, 이를테면 결과를 확인하는 일부터 넘겨볼 수 있을지 등을 가늠해보면 루프의 시작점이 보일 겁니다.

품질과 비용은 어떻게 지키나요?

넘기는 범위를 늘리다 보면 걱정이 생깁니다. AI가 알아서 도는데 결과가 엉망이면, 비용이 줄줄 새면 어쩌나 싶죠. 여기에 대한 클로드코드 팀의 답은 이렇습니다. 결과가 나쁠 때 그것만 고치고 끝내지 마세요. 내가 결과를 어떻게 확인하는지를 지침 문서로 적어두면, AI가 다음부터 그 방법대로 스스로 점검하니 같은 실수가 줄어듭니다. 검토는 그 작업을 한 AI 말고, 내용을 모르는 새 AI에게 따로 맡기는 게 좋아요. 앞선 작업을 안 봤으니 더 냉정하게 짚어주거든요. 비용은 일에 맞게 규모를 맞추면 됩니다. 사소한 일에까지 복잡한 루프를 쓸 필요는 없습니다. 값싸고 빠른 모델로 되는 일은 그쪽에 맡기고, 크게 돌리기 전에 작은 부분으로 먼저 돌려보면 됩니다.

콘텐츠가 마음에 드셨다면, 꼭꼭 작가 알림 설정과 좋아요를 부탁드립니다!

]]>

담당자 퇴사하면 업무 못 하는 회사를 위한 AX는?

스마일게이트인베스트먼트 '미래전망 컨퍼런스' 패널토크 정리 | 박우범 위시켓 대표 · 이동건 마이리얼트립 대표 · 정윤호 해빗팩토리 대표

기업용 AI 시장은 지금 그 어느 때보다 뜨겁습니다. AI 전환, 이른바 'AX(AI Transformation)'를 내걸지 않는 IT 기업을 찾기 어렵고, 도입하려는 기업도 제조부터 금융까지 업종을 가리지 않아요. 컨설팅펌, SI(시스템 통합) 업체, 솔루션 기업이 저마다 AX 해법을 들고 나옵니다. 그런데 정작 'AX가 무엇을 하는 일인지'는 또렷하게 정의된 적이 없어요. 파는 쪽도 사는 쪽도 서로 다른 걸 떠올립니다.

성과도 마찬가지입니다. 맥킨지가 2025년 11월 내놓은 'The State of AI' 보고서를 보면, 전 세계 조직의 88%가 최소 한 개 업무에서 AI를 쓴다고 답했습니다. 그런데 그 AI가 회사 손익에 측정 가능한 영향을 줬다고 답한 곳은 39%에 그쳤어요. 도입은 거의 다 했는데, 실제로 돈이 되는 성과를 봤다는 곳은 절반도 안 되는 셈입니다. 도구는 넘쳐나는데 왜 성과 앞에서는 이렇게 자주 멈춰 설까요?

그 답의 실마리를, B2B 현장에서 일하는 위시켓 박우범 대표에게서 들을 수 있었습니다. 박 대표는 2025년 11월AX 전환 전문 사업부 AIDP를 출범한 이후 제조, 유통, 물류, 의료 기업을 매주 20~30곳씩 만나며 이들이 AI 도입에서 정확히 어디서 걸려 넘어지는지를 들여다보고 있습니다. 2026년 6월 19일 스마일게이트인베스트먼트가 연 '미래전망 컨퍼런스'의 패널토크에서 그는 김솔해 수석팀장의 진행에 답하며, B2B IT 시장이 왜 AX 앞에서 멈춰 서는지를 진단했습니다. 같은 자리에 오른 이동건 마이리얼트립 대표, 정윤호 해빗팩토리 대표는 소비자 서비스를 운영하면서도 내부를 어떻게 AX했는지, B2B의 눈으로 볼 만한 사례를 함께 나눴고요.

이 글은 그날 오간 이야기를 토대로, 기업 AX가 어디서 막히고 시장이 어디로 향하는지를 정리했습니다.

2026년 6월 19일 스마일게이트인베스트먼트가 연 '미래전망 컨퍼런스'의 패널토크. 왼쪽부터 김솔해 수석팀장, 위시켓 박우범 대표, 마이리얼트립 이동건 대표, 해빗팩토리 정윤호 대표. <출처: 위시켓>

AX란 무엇인가: 도구가 아니라 '일하는 방식'을 바꾸는 일

많은 기업이 AX를 챗봇 도입이나 생성형 AI 툴 구독쯤으로 여깁니다. 하지만 박우범 대표가 현장에서 내린 결론은 결이 다릅니다. 그는 AX를 "기업이 일하는 방식을 자산화하는 일"이라고 정의했습니다.

이 정의의 배경에는 중소·중견기업이 오래 안고 온 구조적 약점이 있습니다. "많은 기업의 일하는 방식은 일 잘하는 사람의 머릿속 암묵지에 기반해 있었어요. 그 사람이 퇴사하면 암묵지도 함께 사라지는 구조였죠." 회사가 10년을 굴러도 그 10년 치 노하우가 조직에 쌓이지 않고 개인과 함께 빠져나가는, 익숙한 풍경입니다. AX는 이 흩어진 암묵지를 회사의 자산으로 바꾸는 작업이라는 겁니다.

박 대표는 그 과정이 대체로 네 단계를 거친다고 설명했습니다.

첫 번째는 데이터화입니다. 문서, 메일, 현장 기록처럼 정리되지 않은 비정형 데이터를 기계가 읽을 수 있는 형태로 만드는 단계예요. 두 번째는 워크플로우(업무 흐름) 정리입니다. 누가 언제 무엇을 어떤 순서로 하는지, 흩어진 일의 흐름을 정돈하는 단계죠. 이 두 단계가 받쳐줘야 비로소 세 번째, 챗봇이나 사내 문서 검색 같은 AI 애플리케이션이 제대로 작동합니다. 그리고 마지막 네 번째가 AI 에이전트, 즉 사람이 시키지 않아도 여러 단계를 스스로 수행하는 AI가 그 자산들을 학습해 움직이는 단계입니다.

핵심은 순서입니다. 데이터와 워크플로우라는 앞 두 단계가 정리되지 않은 채 애플리케이션이나 에이전트부터 얹으면, AI는 부실한 토대 위에 놓이게 됩니다. 박 대표가 "데이터도, 워크플로우도, 시스템도 자산화되면 의사결정의 질과 속도가 매우 좋아진다"고 말한 것도, 이렇게 여러 층의 자산이 순서대로 쌓였을 때의 이야기입니다.

그렇다면 실제 기업들은 이 네 단계의 어디쯤에서 움직이고 있을까요. 박 대표가 현장에서 확인한 답은, 상당수가 아직 앞의 첫 단계에서 멈춰 있다는 것이었습니다.

B2B 현장은 어디서 막히나

박 대표는 AI 도입을 시도하는 기업이 대체로 두 부류로 나뉜다고 했습니다.

첫 번째는 이미 쓴맛을 본 쪽입니다. "2년 전쯤 챗봇이 유행한다길래 붙여보고, 추천 엔진이 좋다길래 도입해본 분들이에요." 문제는 그다음이었습니다. 앞단의 데이터와 워크플로우가 정리되지 않은 상태에서 도구부터 얹다 보니, 그게 실제 손익에 잡히지 않더라는 겁니다. 도입은 했는데 성과는 없는, 앞서 맥킨지 수치가 보여준 그 간극을 몸으로 겪은 집단이죠.

두 번째는 탑다운(Top-down)으로 결정되는 쪽입니다. 대표나 임원이 직접 챗GPT나 클로드를 써보고 "이거 우리도 도입하자"며 지시하는 경우입니다. 의지는 분명한데, 정작 무엇을 어디서부터 손대야 할지는 실무진도 알기 어렵습니다.

두 부류의 사정은 달라 보이지만, 막히는 지점은 놀랄 만큼 비슷했습니다. 앞서 짚은 AX 네 단계 가운데 대부분이 데이터화와 워크플로우 정리에서 멈춰 있었다는 겁니다. 어떤 기업은 데이터화 자체가 병목이었고, 어떤 기업은 법인마다 공장마다 다른 ERP(전사적 자원관리 시스템)를 써서 흩어진 업무 흐름을 통합하는 데서 막혔습니다. 화려한 AI 애플리케이션이나 에이전트를 얹기 한참 전, 가장 기초적인 정리 단계에서 멈춰 있었던 거죠.

문제는 '멈춰 있다'는 진단만으로는 다음 발을 뗄 수 없다는 점입니다. 내가 선 자리를 알아야 다음 걸음이 보이니까요. 위시켓 AIDP는 비IT 기업이 AI 전환에서 지나는 길을 다섯 단계로 나눠, 고객사가 지금 어디에 있는지부터 진단합니다. 박 대표가 짚은 4단계가 '무엇을 해야 하는가(전환 작업)'라면, 이 5단계는 그에 앞서 '지금 어디에 서 있는가(현재 상태)'를 가리키는 지도인 셈입니다.

위시켓 AIDP가 자사 진단 데이터를 바탕으로 정의한 비IT 기업 AX 5단계. '지금 필요한 것'은 각 단계에 대응해 편집부가 정리했다.

그런데 여기서 더 근본적인 문제가 드러납니다. 이 앞 단계를 함께 풀어줄 상대를 시장에서 찾기가 어렵다는 것입니다.

끝까지 책임질 곳이 없다: 30년간 파편화된 IT 시장

기업이 앞 단계에서 멈추는 게 순전히 그 기업 탓만은 아닙니다. 막상 도움을 구하려 해도, 처음부터 끝까지 함께 갈 상대가 시장에 없기 때문입니다. 박 대표는 그 뿌리를 IT 시장의 오랜 구조에서 찾았습니다.

"AI를 제대로 도입하려면, 진단, 전략, 구축, 운영, 그리고 운영에서 나온 데이터로 다시 전략을 수정하는 과정이 하나의 닫힌 순환으로 돌아가야 합니다." 이른바 클로즈드 루프(closed loop), 곧 진단에서 시작해 개선까지 갔다가 다시 진단으로 되돌아오는 순환 구조입니다. 한 번 구축하고 끝나는 게 아니라, 돌리면서 계속 다듬어야 성과가 난다는 뜻이죠. 박 대표는 "이 전 과정을 온전히 수행할 수 있는 업체가 시장에 없다"고 잘라 말했습니다.

이유는 지난 30년간 IT 시장이 잘게 쪼개져 온 데 있습니다. IT 교육, 컨설팅펌, SI(시스템 통합), BPO(업무 위탁), 인프라로 각자의 영역이 갈라져 굳어졌다는 겁니다. 문제는 이렇게 나뉜 사업자들이 저마다 순환의 한 토막씩만 담당한다는 데 있습니다. 박 대표의 설명은 이렇습니다. 컨설팅펌은 진단과 보고서까지만 주고 실행은 손대지 않습니다. SI 회사는 정해진 요구사항을 받아 소스코드를 납품하면 계약이 끝나는 구조고요. 솔루션이나 SaaS는 이미 만들어진 제품이라 개별 기업의 워크플로우에 딱 맞아떨어지기 어렵습니다.

그러니 기업 입장에서는 진단은 이 회사, 구축은 저 회사, 운영은 또 다른 회사에 맡기고 그 사이를 직접 꿰매야 합니다. 클로즈드 루프가 돌기는커녕, 단계마다 끊긴 토막들을 발주처가 손으로 이어 붙이는 셈이죠. AX는 한 번 구축하고 끝나는 게 아니라 계속 돌려보면서 개선해야 하기 때문에, 이렇게 진단, 구축, 운영이 끊겨 있다면 AX가 제대로 진행되지 않습니다.

이 대목은 앞서 두 부류의 기업이 공통으로 토로한 답답함과 맞닿아 있습니다. 도구를 붙여도 손익에 안 잡히고, 위에서 지시는 내려오는데 실행할 상대가 마땅치 않다는 그 막막함의 상당 부분이, 사실은 개별 기업의 역량 문제가 아니라 시장이 통째로 파편화돼 있다는 구조의 문제였던 겁니다.

파편화에서 ‘번들링’으로: IT 시장의 다음 장면

그렇다면 이 파편화된 시장은 앞으로 어떻게 될까요. 박 대표는 지난 30년간 잘게 쪼개져 온 IT 서비스가 AI 시대에 다시 하나로 묶이는 '번들링'이 일어날 것으로 내다봤습니다. 교육, 컨설팅, 구축, 운영으로 나뉘어 있던 영역이, 진단부터 운영까지 한 곳에서 책임지는 형태로 통합된다는 전망입니다.

위시켓 AIDP의 행보가 그 방향을 보여주는 한 예입니다. AIDP는 위시켓이 13년간 쌓은 IT 프로젝트 데이터를 학습해 일종의 운영 체계(OS)를 만들었고, 여기에 기업의 상황과 요구사항을 넣으면 시스템 구축까지 이어지도록 했다고 합니다. 이 방식으로 기존 SI 시장에서 9개월씩 걸리던 400여 기능 규모의 제조업 ERP를 훨씬 짧은 시간에 구축해 납품하고 있다는 겁니다. 박 대표는 이 사업을 두고 시장의 반응이 제각각이라고 했습니다. 컨설팅펌은 "컨설팅을 한다"고, SI 회사는 "SI를 한다"고, 아웃소싱 회사는 "BPO를 한다"고 본다는 거죠. 한 회사가 예전 같으면 서로 다른 업종으로 나뉘었을 일을 한꺼번에 하고 있다는 뜻입니다.

박 대표는 이 통합이 단순한 사업 확장이 아니라 AI 시대의 필연이라고 봤습니다. 그는 AI 에이전트를 기업에 도입하는 일을 "그 회사의 의사결정과 규칙을 다 아는 10년 차 시니어 여러 명을 납품하는 것"에 비유했는데요. 그렇게 깊이 들어간 에이전트는 그 회사의 일하는 방식에 맞물려 돌아가기 때문에, 자연히 그걸 납품하고 운영하는 회사로 종속이 이어진다는 겁니다. 실제로 위시켓도 시스템을 넘어 AI 교육, 나아가 임원 대상 'AI 과외'로까지 서비스를 넓히고 있다고 했습니다.

이 지점에서 박 대표가 던진 개념이 '오퍼레이팅 파트너'입니다. 앞으로는 AI 에이전트를 만드는 회사가 진단, 컨설팅, 구축, 운영, 교육을 한 묶음으로 제공하며 기업의 AI 전환을 곁에서 계속 운영해 주는 형태로 시장에 자리 잡으리라는 전망이죠. 파편화된 벤더들 사이에서 길을 잃던 기업 입장에서는, 끊긴 토막을 직접 이어 붙이는 대신 처음부터 끝까지 함께 가는 파트너를 찾게 된다는 이야기입니다. 앞서 짚은 '끝까지 책임질 곳이 없다'는 병목이, 바로 이 번들링 흐름 속에서 풀려나가는 셈입니다.

한국형 AX는 '감축'이 아니라 '집중'이다

여기까지가 시장이 어디로 향하는가에 대한 이야기라면, 이제 시선을 기업 안쪽으로 돌려볼 차례입니다. 무엇을 위해 AX를 하는가, 그 목표 말이죠. AI 도입을 이야기할 때 빠지지 않는 게 인력 감축입니다. 아마존과 메타가 창사 이래 최대 규모로 감원했고, 클라우드플레어 같은 미국 기업이 1,100명을 줄였다는 소식이 AI 효율화의 상징처럼 오르내립니다. AI를 도입하면 사람을 줄이고, 그만큼 이익률이 올라간다는 공식이죠. 그렇다면 한국 기업도 같은 길을 갈까요. 박 대표의 대답은 분명한 '아니오'였습니다.

"한국은 고용이 유연하지 않습니다. 사람을 쉽게 내보낼 수 없죠." 그래서 현장에서 만나는 기업들의 목적은 인력 감축과는 결이 다르다고 했습니다. 미국식 사례처럼 'AI로 몇 명을 줄여 이익률을 얼마 높였다'는 접근이 아니라, 잡다한 업무를 걷어내 구성원이 본질에 집중하게 만드는 쪽이 대부분이라는 겁니다.

그가 그린 그림은 구체적입니다. 영업 담당자는 서류 작업에 뺏기던 시간을 영업에 쓰고, 생산 관리자는 일정 조율 대신 진짜 공정 관리에 집중하며, 경영진은 보고를 듣는 데 쓰던 시간을 실제 의사결정에 쓰도록 만드는 것. 사람을 빼는 게 아니라, 사람이 원래 잘해야 할 일에 집중하도록 나머지를 AI가 떠맡는 구조입니다.

박 대표는 이를 한 문장으로 정리했습니다. "한국의 AX는 효율을 높여 이익률을 개선하기보다, 본질에 집중해 매출을 올리는 형태의 목적을 가진 곳이 대부분입니다." 비용을 줄이는 수비형 AX가 아니라, 매출을 키우는 공격형 AX라는 이야기입니다.

흥미로운 건, 이 흐름이 한국만의 특수성은 아니라는 점입니다. 미국 뉴욕 연방준비은행이 2025년 8월 데이터로 내놓은 조사를 보면, AI 도입이 여러 산업으로 번지는 와중에도 대부분의 기업은 직원을 대체하기보다 재교육하는 쪽을 택하고 있었습니다. 세계경제포럼(WEF)의 '2025 일자리의 미래' 보고서도 비슷한 그림을 그립니다. 전 세계 노동자를 100명으로 압축하면 2030년까지 59명이 재교육을 필요로 하는데, 그중 29명은 지금 자리에서 역량을 키우고 19명은 조직 안 다른 자리로 재배치될 것으로 봤죠. 물론 감원 신호가 전혀 없는 건 아닙니다. 같은 뉴욕 연준 조사에서 일부 서비스 기업은 향후 AI로 인한 감원을 예상했고, 그 여파는 주로 대졸 사무직에 몰렸습니다. 그럼에도 큰 방향은 박 대표의 현장 관찰과 겹칩니다. 적어도 지금까지 AI 도입의 무게는, 사람을 덜어내는 쪽보다 사람을 다른 일로 옮기고 다시 훈련시키는 쪽에 실려 있습니다.

이 차이는 단순한 관점의 문제가 아니라, 도입을 설득하는 논리 자체를 바꿉니다. AI 도입을 감원과 묶으면 조직 내부의 반발을 부르지만, '잡무를 덜어 본질에 집중하게 하는 일'로 제시하면 구성원을 우군으로 만들 수 있기 때문입니다. 한국 시장에서 AX가 자리 잡는 방식은, 감축의 언어가 아니라 집중의 언어에 가깝습니다.

실제 일하는 방식을 바꾼 AX 사례들

그렇다면 본질에 집중해 내부의 AX를 해낸 모습은 어떤 모습일까요? 이 자리에 함께 참가한 기업들의 AX 사례를 통해 가늠해볼 수 있었습니다. 여행 스타트업 마이리얼트립과 핀테크 스타트업 해빗팩토리가 함께했는데요. 두 회사 모두 일하는 방식 자체를 AI로 다시 구성한 이야기를 들려줬습니다.

이동건 마이리얼트립 대표는 고객센터를 사례로 들었습니다. 마이리얼트립은 4년 전 외주로 돌리던 고객센터를 자회사로 내재화했습니다. 고객의 목소리를 최전선에서 듣는 것이 회사 성장에 중요하다는 판단에서였죠. 그리고 2년 전 AI를 만나면서, 이 고객센터야말로 AI가 가장 크게 바꿀 영역이라고 봤습니다. 지금은 상담 녹취를 들어도 사람인지 AI인지 구별하기 어려운 수준이라고 합니다. 오히려 너무 사람 같아 나중에 고객이 기만당했다고 느낄 정도라, 일부러 모델을 'AI답게' 낮추기도 했다는 겁니다.

주목할 점은 그다음입니다. 마이리얼트립은 이 역량을 자사에만 두지 않고 외부에 팔기 시작했습니다. 이 대표는 아마존이 자사용으로 만든 AWS를 나중에 같은 고민을 가진 기업들에 제공한 것에 빗댔는데요. 대부분의 B2C 회사에 고객센터는 중요하지만 잘 풀기 어려운 영역이고, 마이리얼트립은 그 문제를 이미 풀어봤다는 겁니다. 올해 1월 타사 일감을 수주하기 시작해, 지금은 20곳가량의 고객사를 두고 있다고 했습니다. 내부 AX로 쌓은 역량이 그 자체로 B2B 상품이 된 사례입니다.

정윤호 해빗팩토리 대표는 상담 조직의 표준화를 이야기했습니다. 해빗팩토리는 마이데이터(개인이 자기 금융 정보를 모아 활용하는 제도)를 기반으로 보험 상담을 하는데, 하루 신규 상담이 2천 건을 넘어 사람이 품질을 일일이 관리할 수 없었습니다. 지금은 AI가 모든 상담을 실시간으로 센싱하고, 코칭 AI가 상담사에게 "지금 그 방향으로 가면 안 된다"고 실시간으로 제안합니다. 상담의 질이 개인 역량에 따라 들쭉날쭉하던 것을, AI가 1차로 정보를 분류하고 방향을 잡아주는 방식으로 표준화한 겁니다.

미국 주택담보대출(모기지) 사업에서는 그 효과가 숫자로 드러났습니다. 한 고객이 갈 수 있는 대출 상품의 경우의 수가 4천 가지에 이르고, 이 판단이 전부 담당자의 암묵지에 담겨 있었다고 합니다. 해빗팩토리는 이를 알고리즘으로 옮겨, AI가 먼저 서류를 읽고 기본 가이드라인을 만들도록 했습니다. 그 결과 보통 35일에서 40일 걸리던 대출 실행을 7일 수준으로 줄이고 있다고 했습니다.

두 회사 모두 사람을 더 투입해 문제를 덮는 대신, 일하는 방식 자체를 다시 설계했습니다. 앞서 말한 '감축이 아니라 집중'으로서의 AX가, 두 현장에서 각기 다른 모습으로 구현된 셈입니다.

다시, 우리 회사는 어디에 있나

지금까지 2026년 6월 19일 스마일게이트인베스트먼트가 연 '미래전망 컨퍼런스' 패널토크에 오른 B2B IT 시장 이야기를 정리했습니다. 현장에서 AX의 병목이 어떤 모습으로 나타나는지, 또 함께 참여한 기업들이 그 병목을 어떻게 넘었는지를 구체적으로 짚어봤습니다.

AI 도입이 현장에서 자꾸 멈춰 서는 건 도구가 부족해서가 아닙니다. 그 도구를 얹기 한참 전, 데이터와 일하는 방식을 정리하는 단계에서 멈추기 때문입니다.

그래서 AI 도입을 앞둔 기업이 가장 먼저 던져야 할 질문은 '어떤 AI 도구를 살까'가 아닙니다. '우리는 지금 어디에 있는가'입니다. 우리 회사의 데이터는 모여 있는가, 부서마다 흩어진 업무 흐름은 정돈돼 있는가. 앞서 살펴본 AX 5단계 진단에서 우리가 선 자리를 냉정하게 짚는 데서 출발해야 합니다. 데이터부터 흩어져 있다면 화려한 에이전트를 논하기 전에 데이터화가 먼저고, 데이터는 있는데 시스템이 제각각이라면 워크플로우 정리가 먼저입니다.

관점도 함께 점검할 필요가 있습니다. AI 도입을 인력 감축의 도구로 볼 것인가, 아니면 구성원이 본질적인 일에 집중하도록 잡무를 걷어내는 일로 볼 것인가. 전자는 조직의 반발을 부르지만, 후자는 구성원을 우군으로 만듭니다. 앞서 두 회사가 보여준 것도 바로 그 후자의 길이었습니다. 목적을 어디에 두느냐가 도입의 성패를 가릅니다.

AI 시대의 진짜 경쟁력은 얼마나 최신 도구를 빨리 들이느냐가 아니라, 자기 회사가 어디서 막혀 있는지를 정확히 아는 데서 시작됩니다.

]]>

사람마다 다른 썸네일이 나온다? GenUI의 빛과 어둠

GenUI 시대의 명암과 AI 시대에 주목할 비즈니스 가치

한때 우리는 잘 만든 화면 하나를 모두에게 똑같이 보여주는 것을 좋은 디자인이라 불렀습니다. 그러나 AI는 이 전제를 흔들고 있습니다. 이제 같은 정보라도 누가, 언제, 어떤 맥락에서 받느냐에 따라 화면과 메시지를 통째로 다시 짜고는 합니다. 원래 디자이너가 색과 패턴, 배치를 고민하는 이유가 메시지를 가장 잘 전달하기 위해서 였다면, AI는 그 전달의 형태를 사람마다 다르게 만드는 시대로 우리를 데려가는 중입니다.

이 글에서는 세 가지를 차례로 살펴보려 합니다. 첫째, 이미 우리 곁에 와 있는 생성형 UI 상용 사례입니다. 둘째, 그것을 가능하게 만드는 원천 기술과 우리가 놓치면 안 되는 주의점이고요. 셋째, 왜 지금 이 변화에 주목해야 하는지, 즉, 비즈니스 가치를 말해보려고 합니다.

우리 일상에서 만나는 생성형 UI

사실 이러한 생성형 UI는 우리 주변에서 흔하게 만날 수 있습니다. 먼저 그 사례들을 짚어보며 어떠한 변화가 일어나고 있는지 보겠습니다.

쇼핑: 저번주에 산 콩나물이 할인 중입니다

가장 익숙한 예시는 아마 쇼핑의 영역일 것입니다. 요즘은 같은 앱을 열어도 메인 홈의 진열과 ‘오늘 당신을 위한 추천’ 상품이 사람마다 다릅니다.

아마존은 개인의 행동·검색·구매 습관에 맞춰 추천 상품과 맞춤 혜택, 홈 화면 구성을 실시간 데이터 기반으로 끊임없이 바꿉니다. 국내에서도 마켓컬리처럼 구매 이력에 따라 첫 화면의 큐레이션이 달라지는 서비스가 익숙해졌습니다.

넷플릭스는 이 흐름을 가장 극적으로 보여 주는 사례입니다. 같은 영화라도 시청 이력에 따라 노출되는 썸네일 이미지가 달라집니다. 로맨스를 즐겨 본 사람과 액션을 즐겨 본 사람은 같은 작품에서도 전혀 다른 포스터를 보게 되죠. 화면 레이아웃 역시 시청 패턴에 따라 재배치됩니다. 그 결과는 숫자로도 확인됩니다. 넷플릭스 보고서에 따르면 전체 시청의 약 80%가 검색이 아닌 추천에서 발생한다고 합니다. ‘무엇을 보여줄지’를 사람마다 다르게 고르는 것만으로도 서비스의 핵심 행동이 바뀌는 셈입니다.

마켓컬리의 ‘내가 본 상품과 관련 제품’, 뱅크샐러드의 ‘보험료 자동이체 및 절약 안내’ <출처: 작가, 각 앱 캡처>

금융: 바로 실행할 자산관리 도와드릴게요

금융은 어떻게 전달할지 그 변화가 가장 민감하게 동작하는 영역입니다. 같은 자산·거래 정보라도 사용자의 소비 패턴과 관심사, 역할에 맞춰 홈 화면과 알림, 리포트 구성이 달라집니다. 특히 토스나 뱅크샐러드 유저라면 앱에서 사람마다 다른 홈 화면과 맞춤 알림을 받아 본 경험이 있으실 거예요.

이로 인한 매출 규모 차이도 작지 않습니다. 맥킨지글로벌연구소는 생성형 AI가 은행 산업에서만 연간 약 2,000억~3,400억 달러의 가치를 더할 수 있다고 추산했습니다. 다만 금융은 규제 산업이라는 점을 기억해야 합니다. 화면을 개인화하는 힘이 강할수록 데이터 보안과 컴플라이언스가 전제되어야 하며, 이는 뒤에서 다룰 주의점과도 연결됩니다.

<출처: The economic potential of generative AI, 맥킨지>

헬스케어: 건강 패턴을 읽고 해석해 드려요

헬스케어에서는 맞춤 전달이 곧 사용자의 안전과 직결됩니다. AI는 환자 데이터를 분석해 개인에게 맞는 치료와 복약 리마인더를 제공합니다. ‘약을 드세요’라는 간단한 메시지도 환자의 상태와 복용 이력에 맞춰 전달 시점과 표현이 달라집니다.

이런 흐름은 이제 막 본격화되는 단계입니다. 딜로이트에 따르면 선도 의료기업·기관의 약 75%가 생성형 AI를 서비스에 실험하거나 전사적 확산을 계획하고 있습니다. 정보를 정확한 사람에게, 적절한 형태로 전달하는 일이 의료 현장에서 빠르게 주류로 자리 잡아 가는 중입니다.

그 예로 삼성전자 스핀오프 디지털 치료제 기업 웰트(WELT)가 CES 2026에서 공개한 ‘슬립큐(SleepQ)’는 같은 수면제를 사람마다 다른 시점에 복용하도록 안내합니다. AI가 개인의 행동 패턴을 분석해 불면이 찾아올 시점을 몇 시간 전에 예측하고, 몸이 가장 잘 반응하는 순간에만 약을 권하는 방식이죠. 약은 그대로지만 안내가 사람마다 달라지면서, 같은 처방이 더 안전하고 정밀한 치료로 바뀌는 겁니다.

에듀테크: 제발 공부 좀 해주세요

교육 업계는 이러한 전달 방식의 변화가 가장 흥미롭게 드러나는 분야입니다. 최근 화제가 된 AI 언어 학습 앱 LingoTok은 개인 AI 튜터와 실시간 음성으로 대화하는 방식인데, 이때 학습자의 수준과 선호에 맞춰 진도와 속도를 조정합니다. 특히 까칠하게 직언하는 튜터의 말투가 틱톡과 인스타그램에서 밈처럼 퍼지며 큰 화제가 됐죠(관련 틱톡 영상). 같은 학습이라도 전달되는 톤과 피드백 방식까지 사람과 모드에 맞춰 재구성된다는 점을 보여 준 사례입니다.

다른 예로 듀오링고는 사용자의 수행 수준에 따라 난이도를 실시간으로 조정합니다. 어려워하면 속도를 늦추고 해당 개념을 더 자주 보여 주며, 잘 따라오면 지루하지 않게 진도를 앞당깁니다. 심지어 사용자가 며칠째 학습을 거르면 앱 아이콘 속 마스코트 ‘듀오’가 우는 표정이나 녹아내린 모습, 화난 모습 등으로 바뀝니다. 이른바 동적 앱 아이콘인데, 같은 알림이라도 사용자의 상태에 따라 죄책감을 자극하는 형태로 전달되는 셈이죠.

<출처: 작가, 듀오링고 앱 아이콘 모음>

이를 가능하게 만든 원천 기술, 생성형 UI

이 모든 사례를 하나로 묶는 기술이 바로 생성형 UI(Generative UI, GenUI)입니다. 생성형 UI는 사용자의 필요와 맥락에 맞는 경험을 제공하기 위해 AI가 실시간으로 동적으로 생성하는 인터페이스를 뜻합니다. 과거에는 화면을 모두 미리 설계해 누구에게나 똑같이 보여줬다면, 이제는 AI가 사용자의 의도를 읽고 그 자리에서 화면을 조립합니다.

기존의 반응형 디자인과 혼동하기 쉽지만, 결이 다릅니다. 반응형이 기기 화면 크기에 맞춰 레이아웃을 늘리고 줄였다면, 생성형 UI는 사용자의 의도와 맥락에 맞춰 화면 구성 자체를 다시 짭니다. 비유하자면 반응형은 같은 옷을 사이즈에 맞게 내주는 것이고, 생성형 UI는 사람마다 다른 옷을 그 자리에서 맞춰 지어 주는 것에 가깝습니다.

GenUI 원리와 화면을 미리 만드는 시대의 종말

그렇다면 GenUI는 어떻게 실시간으로 화면을 조립할까요? AI가 매번 코드를 새로 작성해 화면을 렌더링하는 방식은 아닙니다. 핵심은 구조화된 데이터인 JSON 기반 출력과 프론트엔드의 컴포넌트 매핑을 결합하는 데 있습니다. 사용자가 앱에 진입하거나 명령을 내리면 AI는 사용자 프로필과 과거 행동 이력, 현재 의도를 실시간으로 분석합니다. 이후 이에 맞는 구조화된 데이터를 생성하죠. 곧 프론트엔드는 AI가 전달한 JSON을 받아 앱 안에 미리 만들어 둔 원자 단위 UI 컴포넌트를 화면에 즉시 매핑해 동적으로 결합해 줍니다.

이러한 변화는 디자이너와 기획자의 일하는 방식도 근본적으로 바꾸고 있습니다. 가트너는 2028년까지 디지털 워크플레이스 애플리케이션의 20% 이상이 AI 기반 개인화 알고리즘을 활용해 적응형 경험을 제공할 것으로 내다봤습니다. 또, 2026년 말까지는 기업용 앱의 40%가 특정 작업에 특화된 AI 에이전트와 결합될 것으로 전망했습니다.

과거에는 피그마에서 완성된 화면 단위로 설계를 정적으로 배치했다면, GenUI 시대의 실무자는 화면을 직접 그리지 않습니다. 대신 원자 단위의 컴포넌트를 설계하고, 사용자의 데이터와 맥락에 따라 이 컴포넌트가 어떻게 유기적으로 결합되고 해체될지 그 조건과 규칙(Rule-based)을 정의하는 일이 디자이너의 핵심 역량이 됩니다. 화면을 만드는 권한을 AI에 위임하는 대신, AI가 움직일 프레임워크를 짜는 시스템 디자이너로 진화해야 하는 시점입니다.

Generative UI and Outcome-Oriented Design <출처: 닐슨노먼그룹>

생성이 멈출 때와 개인화의 그림자

그러나, 화면을 실시간으로 생성한다는 것은 기술적 실패나 중단의 리스크를 언제나 안고 있다는 뜻이기도 합니다. 미리 설계된 화면은 안전하게 떠 있지만, AI가 그 자리에서 만드는 화면은 응답이 지연되거나 예상과 다른 구성을 내놓을 수 있습니다.

따라서 이를 실무에 적용하려면 기획과 개발 초기 단계부터 부드러운 기능 저하(Graceful Degradation) 전략을 반드시 합의해야 합니다. AI 엔진의 응답이 기준 시간 이상 지연되거나 오류가 발생했을 때, 사용자에게 무한 로딩이나 깨진 화면을 노출하지 않아야 합니다. 이를 위해 가장 안전하고 보수적인 정적 기본 템플릿을 상시 대기시키는 폴백(Fallback) 구조를 프론트엔드단에 촘촘히 심어두는 것이 현재 가장 현실적인 기술 방어선입니다.

문제는 기술적 실패보다 더 큰 그림자가 성공적인 개인화 뒤에 숨어 있다는 점입니다. 사람마다 화면을 다르게 구성하는 GenUI의 강력한 힘은 양날의 검입니다. 이는 사용자의 구매를 압박하기 위해 실시간으로 레이아웃을 바꾸는 다크 패턴(기만적 설계)의 유혹으로 흐르거나, 스크린 리더 같은 보조 기술과 충돌해 누군가의 정보 접근을 막는 접근성 문제를 낳기도 있습니다.

실제로 2018년 넷플릭스가 개인화 썸네일을 도입했을 때도 논란이 있었습니다. 당시 백인 배우가 주연인 영화임에도 일부 흑인 이용자에게는 단 몇 분만 등장하는 흑인 조연 배우가 포스터 전면에 노출되면서 인종 프로파일링과 기만 논란이 제기됐습니다. 넷플릭스는 이용자의 인종 정보를 수집하지 않으며 오직 시청 이력만 반영한다고 설명했지만, 이는 결과적으로 알고리즘이 '흑인 이용자에게 흑인 조연이 등장하는 썸네일을 보여주는 것이 클릭률을 높인다'는 패턴을 학습해 나타난 역효과였습니다. AI 기반 초개인화가 의도치 않게 인종적 편향을 학습하고 기만적 UX를 만들 수 있음을 보여준 대표적인 사례입니다.

실제 주연인 백인 커플 대신 조연 테이 디그스(흑인)와 루시 리우(동양인)를 전면에 내세워 두 사람이 주연인 영화처럼 착각하게 만든 넷플릭스의 개인화 썸네일 예시 <출처: 가디언>

“같은 말이라도 어떻게 전하느냐에 따라 좋은 언어도, 나쁜 언어도 될 수 있다”는 말이 있습니다. 이처럼 전달 방식을 사람마다 바꾸는 기술은 그 자체로 선하지도 악하지도 않습니다. 이를 어떻게 설계하느냐가 결과를 바꿀 뿐입니다.

시스템 오류를 막는 폴백 구조는 코드 몇 줄로 구현할 수 있습니다. 하지만 한 번 무너진 사용자의 신뢰를 되돌릴 ‘경험의 폴백’ 구조는 존재하지 않습니다. 기술이 화려해질수록 실무자에게 필요한 진짜 방어선은 우리가 설계한 알고리즘이 사용자를 진정으로 돕고 있는지, 아니면 교묘하게 조종하고 있는지를 끊임없이 점검하는 윤리적 프레임워크입니다.

40% 매출 상승과 ‘인간 개런티’의 역설

개인화는 더 이상 있으면 좋은 기능이 아닙니다. 이제는 실제 시장 규모로 그 가치가 증명되는 영역입니다.

AI가 생성하는 개인화 뉴스레터 시장만 봐도 그렇습니다. Rasa.io 같은 도구는 구독자 한 명 한 명의 관심사와 참여 이력을 분석해, 하나의 캠페인 안에서도 사람마다 다른 기사 구성으로 뉴스레터를 발송합니다. 모두에게 똑같은 정적 메일을 보내는 것이 아니라, 각자에게 맞춘 버전을 전달하는 것이죠. 시장조사기관 The Business Research Company는 이와 같은 초개인화 뉴스레터 시장이 2025년 약 20억 달러에서 2026년 약 25억 달러 규모로 성장하고, 2030년에는 67억 달러를 넘어설 것으로 전망했습니다.

고객 응대도 마찬가지입니다. CS 챗봇은 더 이상 단순한 텍스트 봇이 아닙니다. 텍스트·음성·이미지·영상이 하나의 상담 흐름으로 연결되는 형태로 진화하고 있습니다. 가트너는 2026년까지 대화형 AI가 콜센터 상담 인력 비용을 약 800억 달러 절감하고, 상담 10건 중 1건이 자동화될 것으로 내다봤습니다. 같은 답변이라도 받는 사람과 채널, 맥락에 맞춰 전달 방식이 재구성되는 일이 이미 대규모로 벌어지고 있는 셈입니다.

매출 수치로 증명되는 개인화

수치는 더 직접적입니다. 맥킨지에 따르면 빠르게 성장하는 기업은 그렇지 않은 기업보다 개인화 활동으로 약 40% 더 많은 매출을 만들어 냅니다. 또한 소비자의 71%는 개인화된 상호작용을 기대하고, 76%는 그것이 제공되지 않을 때 불만을 느낀다고 합니다. 이제 개인화는 이탈과 전환, 매출에 직결되는 경쟁력이 된 것입니다.

비즈니스 관점에서 개인화의 가치는 매출 상승에만 머물지 않습니다. 내부 운영 리소스를 줄이는 측면에서도 폭발적인 효율을 가져옵니다. 기존에는 기획자와 마케터, 디자이너가 대규모 프로모션을 진행할 때마다 타깃 세그먼트별로 수십, 수백 개의 배너와 맞춤형 상세 페이지를 수작업으로 찍어야 했습니다. 하지만 GenUI 기반의 초개인화가 자리 잡으면 콘텐츠의 조합과 변형을 AI가 실시간으로 처리하므로 시장 변화에 대응하는 시간이 획기적으로 줄어듭니다. 즉, 반복적인 운영 업무에서 벗어나 서비스의 본질적인 온보딩 경험이나 핵심 기능 개선에 더 많은 역량을 집중할 수 있는 것이죠.

“그래도 직접 써야합니다”

여기서 흥미로운 역설이 등장합니다. AI가 메시지를 사람마다 다른 형태로 정교하게 재구성할수록, 정반대 방향의 가치도 함께 떠오릅니다. 바로 재구성되지 않은, 날것 그대로의 인간이 쓴 메시지입니다.

AI가 완성도 높은 콘텐츠를 빠르고 손쉽게 만들어 내면서, 가치의 기준이 ‘얼마나 잘 만들었는가’에서 ‘정말 사람이 만들었는가’로 옮겨 가는 분야도 생겨나고 있습니다. 인스타그램의 수장 아담 모세리는 진정성이 빠르게 희소 자원이 되고 있다며, 그 기준은 ‘만들 수 있는가’에서 ‘오직 당신만 만들 수 있는가’로 이동하고 있다고 말했는데요. 이는 역시 짧고 거친 텍스트, 다듬지 않은 영상이 오히려 사람이 존재한다는 증거로 더 잘 통하는 이유입니다.

오디오 기업 아이하트미디어는 AI가 만든 인물이나 음악을 사용하지 않는다는 ‘휴먼 개런티드(Guaranteed Human)’ 태그라인을 내걸었습니다. 이들에 따르면 AI를 사용하는 소비자는 70%에 달하지만, 사람이 만든 콘텐츠를 원한다고 답한 비율은 90%에 이른다고 합니다.

메타가 운영하는 스레드(Threads)가 전 세계적으로 빠르게 성장하는 현상도 궤를 같이 합니다. 정교하게 보정된 이미지와 AI가 만든 듯한 광고성 피드에 피로감을 느낀 사용자들이, 오히려 가공되지 않은 한두 줄의 거친 생각 조각과 댓글 중심 소통에 열광하는 것이죠. 완벽하게 정제된 AI 콘텐츠의 홍수 아래, 사람들은 결점이 있더라도 진짜 사람 냄새가 나는 텍스트 기반 플랫폼에서 위안과 신뢰를 찾고 있습니다.

<출처: 작가, 스레드 캡처>

정리하면, 이제 메시지 전달은 두 개의 축으로 나뉘고 있습니다. 한쪽에서는 AI가 받는 사람에 맞춰 형태를 재구성하고, 다른 한쪽에서는 사람이 다듬지 않은 날것의 메시지가 희소가치를 얻습니다.

흥미롭게도 이 둘은 충돌하기보다 서로의 가치를 키웁니다. AI가 콘텐츠 작성에서 물러난 대신 무엇이 나에게 도달할지는 여전히 알고리즘이 정할 테니까요. 사람은 콘텐츠를 되찾고, AI는 분배를 가져간 셈입니다.

마치며: AI가 잘할수록, 사람이 귀해지기에

이제 모든 사용자에게 똑같은 말을 건네는 시대는 완연히 저물고 있습니다. AI는 받는 사람에게 어울리는 최적의 형태로 말을 건네며, 인터페이스의 경계까지 허물고 있습니다.

그 변화의 끝에서 우리는 흥미로운 역설과 마주하게 됩니다. AI가 정교해질수록 우리는 더 맥락에 맞고 편리한 경험을 누리겠지만, 바로 그렇기 때문에 가공되지 않은 진짜 사람의 메시지가 더욱 귀한 희소자원이 될 것입니다. 기계가 완벽하게 재조립한 초개인화 화면과 사람이 다듬지 않은 채 건네는 투박한 진정성. 이 두 극단 사이에서 균형을 잡는 일은 결코 쉽지 않은 과제가 될 것입니다.

어쩌면 AI 시대의 가장 강력한 전달 방식은 기술의 완성도가 아닌 그 틈새에 인간적인 불완전함을 얼마나 영리하게 남겨두느냐에 달려 있지는 않을까요. 여러분이 지금 만들고 있는 서비스는 AI의 영리한 분배와 사람의 날것 사이에서, 어느 쪽을 향해 움직이고 있나요?

]]>

1인 빌더, 클로드 코드로 프로젝트 9개 동시 운영한 방법

지난 5월 27일과 6월 10일, 요즘IT는 '클코나잇 2' 웨비나를 개최했습니다. 지난해 진행한 클코나잇 시즌 1에 이어, 이번 웨비나에서는 개발자와 비개발자를 포함한 다양한 직군의 실무자들이 클로드 코드(Claude Code)를 업무에 활용한 경험을 공유했는데요. 참가자들은 "고수의 경험을 나눠 받을 수 있는 기회", "찐 실무자의 현장감 넘치는 사례", "다음에 또 오고 싶은 웨비나" 등의 반응을 보였습니다. 이번 글에서는 아쉽게도 참석하지 못한 분들을 위해, 웨비나의 핵심 내용만 모아 콘텐츠로 정리했습니다.

클코나잇 2 웨비나의 두 번째 발표였던 '1인 빌더가 9개 프로젝트를 Claude Code로 동시 운영하는 법'입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요. 클코나잇 시즌 2 발표를 맡은 김상욱입니다. 오늘 저는 '1인 빌더가 9개 프로젝트를 클로드 코드로 동시에 운영하는 법'을 이야기하려고 합니다. 어쩌다 혼자서 아홉 개나 되는 프로젝트를 동시에 굴리게 됐는지, 그 배경부터 살펴보겠습니다.

백엔드 개발자가 해고 뒤 클로드 코드를 켜기까지

저는 작년 1월, 한 스타트업에 백엔드 개발자로 입사했습니다. 그런데 프론트엔드 채용이 안 돼서, 결국 프론트엔드 업무까지 혼자 다 맡게 됐습니다. 그때는 커서(Cursor)로 개발했는데, 처음으로 플러터(Flutter)를 써서 IoT 앱도 만들어 봤습니다. 쉽진 않았지만 강의를 보며 따라 만들다 보니, 한 가지 확신이 생겼는데요. AI와 함께라면 혼자서도 프로젝트 하나는 충분히 굴릴 수 있겠다는 확신이었습니다.

그렇게 업무에 막 익숙해지던 차에, 갑작스럽게 해고됐습니다. 당황스러웠지만, 제 앞에는 두 갈래 길이 있었습니다. 다시 취업 준비를 하거나, 뭐라도 혼자 만들어 보거나였죠. 저는 후자를 선택했고, 그때 처음 클로드 코드를 켰습니다. 올해 2월의 일입니다.

혼자서 해보니 개발에서의 차이는 곧바로 드러났습니다. 작년만 해도 프론트엔드·백엔드를 오가며 MVP 하나를 만드는 데 보통은 1~2주, 길게는 3~4주를 잡았는데요. 그런데 클로드 코드를 쓰기 시작하니 MVP가 단 몇 시간 만에 나오기 시작했습니다. 그러헥 신이 나서 프로젝트를 계속 찍어냈죠. 그런데 진짜 문제는 그 다음에 벌어졌습니다.

빠르게 만들수록 빠르게 무너졌다: '9개의 폐허'

만드는 속도가 빨라지자 손에 쥔 프로젝트가 순식간에 아홉 개로 불어났습니다. 이 중 일부는 도메인을 띄워 실제로 운영 중인 것들입니다.

대표적인 사례 몇 개만 소개해 보겠습니다.

클래스코인(ClassCoin): 초등학교 학급 경영 관리 서비스로, 2024년부터 초등 교사인 지인과 함께 만들어 운영하고 있습니다.
패티션(petition): 진정서를 자동으로 작성해 주는 서비스인데요. 제가 해고되며 직접 진정서를 쓰게 됐는데, 여러 AI를 번갈아 쓰며 작성하다 보니 관리도, 작성 자체도 까다로웠습니다. 이 경험이 정리돼 있으면 누군가에게 도움이 되겠다 싶어 만들었습니다. 여기엔 RAG(검색 증강 생성)로 법률 정보를 끌어왔는데, 프론트엔드·백엔드를 합쳐 쓸 만한 서비스를 만드는 데 사흘밖에 걸리지 않았습니다. 이때 클로드 코드의 가능성이 정말 무궁무진하다고 느꼈죠.
던전 버디(dungeon-buddy): '데스크톱 컴패니언'이라는 새 장르의 게임입니다. 방치형 RPG로 만들어 스팀(Steam)에 출시도 해 봤습니다.
바바리안(barbarian): 웹소설 '게임 속 바바리안으로 살아남기'의 팬 위키입니다. 주인공의 성장 스토리를 정리하면 재밌겠다 싶어 만들었는데, 팬들 반응이 좋아서 이를 기반으로 게임까지 만들어 운영하게 됐습니다.

문제는 MVP까지는 순식간인데 막상 운영을 시작하면, 고도화해야 할 것이 끝없이 쏟아진다는 점이었습니다. 그러면서 세 가지 통증이 한꺼번에 터졌죠.

"내가 어디까지 했더라?" - 세션을 켤 때마다 진행 상황을 다시 더듬어야 했습니다.
같은 지시를 매번 다시 입력 - 예를 들어, 게임 스프라이트를 만들 때 "스프라이트는 이렇게 만들어 줘" 같은 지시를 프로젝트마다 반복해야 했습니다.
같은 실수를 반복 - 어제 바로잡은 실수를 오늘 또 저지르곤 했습니다.

이걸 가장 아프게 확인시켜 준 사례가 바로 '톡비서'였습니다. 가장 먼저 상용화에 도전한 프로젝트인데요. 카카오톡과 연동한 1:1 AI 비서였습니다. 당시 채팅 기반 AI 에이전트 서비스가 흥행하기 시작했는데, 텔레그램이나 왓츠앱(WhatsApp)은 비전공자가 쓰기엔 진입 장벽이 있다고 봤습니다. 그래서 우리에게 더 친숙한 카카오톡과 연동하면, 일반 사용자가 쉽게 쓰지 않을까 싶었고요.

다만 카카오톡은 텔레그램·왓츠앱과 구조가 많이 달라, 에이전트를 만드는 것도 쓰는 것도 진입 장벽이 있더군요. 만들어 둔 게 아까워서, 스토어 기반 서비스와 일대일로 연동해 스토어에 들어오는 FAQ를 1인 사업자가 쉽게 세팅할 수 있도록 방향을 틀었습니다. 기획하고 MVP를 만들어, 직접 상가를 찾아가 사장님들과 미팅하며 한 건 계약까지 했고요.

하지만 결국 접었습니다. 여러 개를 만드는 건 쉬운데, 여러 개를 영업하고 파는 건 전혀 다른 일이었거든요. 만드는 건 클로드가 해 줬지만, 파는 건 결국 제 몫이었습니다. 아홉 개를 동시에 만들면서 아홉 개를 동시에 영업할 수는 없었죠. 그때 깨달았습니다. “만드는 건 쉬워졌지만, 여기서 끝이 아니구나.”라는 사실을요.

한 사람이 13개 프로젝트를 굴리려면: 다섯 가지 장치

저는 만드는 일보다 운영하는 일이 더 어렵다는 걸 깨닫고, 이를 하나씩 시스템으로 해결하기 시작했습니다. 지금 저는 혼자서 한 컴퓨터로, 13개의 프로젝트를 굴리고 있습니다. 그 바탕이 된 다섯 가지 장치를 소개합니다.

① 중앙 허브 한 장: home/CLAUDE.md

가장 먼저 모든 프로젝트의 목차와 공용 워크플로우를 한 문서에 담았습니다. home 디렉터리에 둔 CLAUDE.md입니다. 진행 중인 프로젝트마다 설명을 충분히 달아 두고, 태스크는 어떻게 관리할지, 리서치나 아이디어 검증은 어떤 절차로 할지를 마크다운에 적어 하나씩 정리해 나갔습니다. 어느 프로젝트로 들어가든 클로드가 이 파일을 가장 먼저 읽기 때문에, 매번 맥락을 처음부터 설명할 필요가 없어집니다.

② 핸드오프: 세션 전환 비용을 0으로

"어디까지 했더라"라는 통증은 핸드오프(Handoff) 시스템으로 해결했습니다. 세션을 끝낼 때 '핸드오프'라고 한마디만 치면, 클로드가 HANDOFF.md에 오늘 한 일·현재 상태·다음에 할 일을 정리해 둡니다. 다음 세션을 켜면 그 파일을 자동으로 읽고 곧장 이어서 작업하죠.

이게 중요한 이유는 따로 있습니다. 맥락을 압축하는 컴팩트(/compact)를 쓰면 정리되는 내용이 워낙 길어 세션이 멈춰 있는 시간이 길어지고, 저는 바바리안 같은 프로젝트는 같은 터미널 세션을 한 번에 세 개씩 동시에 켜기도 하거든요. 핸드오프 덕분에 이 프로젝트 전환 비용이 거의 0에 가깝게 줄었습니다.

핸드오프의 사용법(규칙)을 CLAUDE.md에 적어두면 클로드가 매 세션 그대로 따릅니다.

③ 병렬은 클로드가 알아서

동시에 여러 개를 굴리는 일도 한결 가벼워졌습니다. 예전에는 tmux 멀티세션으로 기획자·프론트엔드·백엔드 에이전트를 따로 띄워 병렬로 작업했는데요. 어떤 에이전트가 무슨 일을 하는지 눈으로 확인하고 싶었기 때문입니다. 그런데 이제는 작업 방식이 어느 정도 보편화돼서, 굳이 멀티세션을 쓰지 않고 한 세션에서 그냥 던져두면 백그라운드로 알아서 돌아갑니다.

④ 스킬: 만든 것 + 받아서 쓰는 것

"같은 지시를 매번 다시 입력하는" 병목은 스킬(Skill)로 풀었습니다. 멘토 스킬, 리서치 스킬, 이사회(board of advisors)처럼 에이전트로 구성한 스킬을 특히 많이 썼죠. 외부에서 유명하다는 스킬도 받아서 써 봤는데, 어떤 건 큰 도움이 됐고 어떤 건 너무 무거워 오히려 방해되기도 했습니다.

회사에서 일할 때는 CI/CD를 직접 구축해야 해서 깃허브 액션이나 젠킨스(Jenkins)로 세팅하곤 했는데요. 지금은 그런 일도 배포(deploy) 스킬 하나를 만들어 간단히 처리합니다. 필요할 때마다 원하는 스킬을 만들어 쓰는 셈이죠.

⑤ 메모리: 같은 실수를 반복하지 않도록

같은 실수를 반복하는 건 메모리로 막았습니다. 우선 제가 하는 프로젝트에 대한 정보를 클로드에게 충분히 주입했습니다. 프로젝트에서 중요하게 보는 것, 잊으면 안 되는 것은 무조건 메모리에 기억하게 했더니, 자주 되풀이되던 실수가 눈에 띄게 줄었습니다.

지금은 이렇게 씁니다: 한 주에 2개만 집중

지금의 작업 방식은 꽤 단순합니다. 백로그(backlog)를 정리해 그 주에 할 일을 정하고, 집중할 프로젝트 두 개를 고릅니다. 세션을 켤 때는 핸드오프를 먼저 읽고 시작하며, 끝낼 때는 핸드오프를 갱신하며 마무리합니다.

여기서 발표 이후에 살짝 업데이트된 내용이 있다면, 발표 땐 루틴을 수동으로 돌렸지만, 지금은 /schedule로 "매주 월요일 아침 backlog 정리" 같은 작업을 클라우드 크론으로 예약해 둡니다. 덕분에 자리에 없어도 자동으로 실행할 수 있죠. (세션을 켜둔 채 반복시키는 /loop과는 별개입니다.)

그렇다면 왜 프로젝트를 두 개로 제한할까요? 여러 프로젝트를 운영에 올리고 CS까지 받으며 굴려 보니, 사람이 풀스택으로 한 서비스를 끌고 가는 것만으로도 버거웠습니다. AI의 도움을 받아도 운영까지 동시에 감당하는 데는 분명한 한계가 있었죠. 아홉 개를 한꺼번에 굴렸더니 어느 것도 진전이 없었거든요. 그래서 한 주에 진짜로 손대는 건 두 개까지로 못 박고, 나머지는 동결했습니다.

실제 운영 사례도 살펴볼게요. 클래스코인은 버셀(Vercel) 애널리틱스로 보면, 초등 교사 80명 정도가 사용하고, 교사당 학생이 20명쯤이니 약 1천 명 이상이 쓰는 서비스입니다. 방문자 수가 폭발적이진 않지만, 작년부터 이어 온 이 프로젝트에 클로드 코드를 도입하자 기능 추가와 개선 속도가 확연히 빨라졌습니다. 저는 비전공자인 형과 함께하다 보니 소통이 매끄럽지 않을 때가 많았는데요. 이런 간극도 클로드 코드가 많이 메워줬습니다.

다음으로 바바리안 게임의 경우, 고도(Godot) 엔진으로 처음 만들어 본 프로젝트입니다. 오픈하고 한 달 동안 약 4만 7천 회 조회에 2만 9천여 회 플레이됐고, 거의 매일 업데이트하며 하루에 열 개씩 배포하고 있습니다.

이렇게 활발하게 굴러가는 프로젝트에는 공통점이 하나 있습니다. 바로 오픈채팅으로 건의를 받아, 곧바로 반영한다는 점인데요. 팬 커뮤니티를 만들어 유저들이 원하는 방향과 건의를 받고, 즉시 업데이트해 주니, 유저분들도 훨씬 재밌어하고 좋아하시더라고요.

프로젝트 9개를 굴린 진짜 이유는 ‘도구’가 아니다

여러 프로젝트를 거치며 제가 내린 결론은 이렇습니다. 아홉 개를 동시에 굴릴 수 있게 된 진짜 이유는 클로드 코드가 다 해줬기 때문이 아닙니다. 사실 허브, 핸드오프, 병렬, 스킬, 메모리 같은 장치는 마음만 먹으면 누구나 금방 따라 만들 수 있으니까요.

정작 중요한 건 AI와 친숙해지는 과정, 즉 클로드를 동료처럼 다루는 일입니다. 잘 못하면 알려주고, 잘하면 칭찬하며 다음에도 그렇게 해 달라고 말하고, 같은 실수를 반복하면 메모리나 마크다운 파일로 줘서 다시는 그러지 않게 다잡습니다. 마치 사람을 대하듯 다루는 거죠.

작업을 시킬 때도 마찬가지입니다. AI에게 "이거 해 줘"라고 정답을 던지면, 딱 그 정답만큼만 돌아옵니다. 그래서 저는 정답 대신 제가 가진 고민과 배경, 컨텍스트를 전부 풀어 놓습니다. 그러고는 "이건 아닌 것 같다", "다른 방법은 없을까?" 하며 브레인스토밍하듯 함께 답을 찾습니다. 그러면 제가 미처 생각하지 못한 답이 돌아옵니다.

예전에는 새 프로젝트를 시작하거나, 새 언어를 배울 때 늘 책을 사고 강의부터 들었는데요. 이번에 고도 엔진을 쓸 때는 강의도 책도 없이 맨땅에서 시작했습니다. 모르는 건 클로드에게 묻고, 더 나은 방법이 있는지도 체크하며 진행했죠.

그래서 마지막으로 제가 드리고 싶은 말은 하나입니다. “AI에게 정답을 주지 말고, 가진 컨텍스트를 다 풀어 놓은 다음에 같이 답을 찾으세요.”라는 거죠. 발표 들어주셔서 감사합니다.

▶발표 영상 유튜브에서 보기

]]>

이벤트 기반 MSA, AI 시대엔 더 비싸진다고요?

이벤트 기반 MSA(Microservice Architecture)를 운영하다 보면 처음엔 꽤 잘 나눴다고 느낍니다. 주문, 결제, 재고, 알림이 각자 맡은 일을 처리하고, 한쪽 장애가 곧바로 전체 장애로 번지지 않는 장점도 분명히 보입니다. 그런데 AI 에이전트에게 유지보수를 맡기기 시작하면, 그 느슨한 연결이 갑자기 흐름을 다시 찾아야 하는 비용으로 돌아옵니다.

주문 상태가 바뀌지 않는 버그를 고친다고 해보겠습니다. 겉으로 보면 주문 서비스 안의 상태 전이 조건만 확인하면 될 것처럼 보입니다. AI 에이전트도 비슷하게 접근합니다. 현재 작업 중인 저장소에서 관련 코드를 찾고, 조건문을 수정하고, 테스트를 추가합니다. 코드만 보면 꽤 그럴듯한 수정안이 나옵니다.

하지만 이벤트 기반 MSA에서는 그걸로 충분하지 않았습니다. 주문 서비스에서 이벤트가 실제로 발행됐는지, 결제나 재고 서비스의 컨슈머(이벤트를 받아 처리하는 쪽)가 어떤 값을 기대하는지, 배송 서비스가 같은 이벤트를 다른 의미로 쓰고 있지는 않은지 함께 봐야 했습니다. 증상은 “주문 상태가 안 바뀐다” 하나지만, 실제 원인은 주문 서비스 안이 아니라 여러 서비스 사이의 이벤트 흐름 어딘가에 숨어 있을 수 있기 때문입니다.

<출처: 작가, ChatGPT로 제작>

실무에서는 이런 흐름을 감으로만 처리하지 않습니다. 이벤트 이름, 페이로드, 컨슈머별 처리 규칙을 팀 컨벤션이나 문서, 대시보드, GUI 도구로 확인하면서 수정합니다. 그런데 AI 에이전트는 기본적으로 현재 열어준 코드와 문서 안에서 판단합니다. 다른 서비스 도메인의 이벤트 흐름이나 이벤트 맵을 함께 넘기지 않으면, AI는 현재 서비스 안에서만 맞는 수정을 만들 수 있습니다. 그 결과 작은 필드 정리나 이벤트 이름 변경이 다른 서비스의 이벤트 계약(이벤트 이름과 데이터 구조에 대한 서비스 간 약속)을 깨뜨릴 수 있습니다.

제가 이 글에서 말하는 비용은 “MSA는 복잡하다”는 일반론이 아닙니다. 이벤트 기반 MSA를 운영하면서 이벤트 흐름을 다시 이해하고 검증하는 데 드는 비용입니다. AI가 수정안을 빠르게 만들수록 PR은 빨리 올라오지만, 사람이 다시 이벤트 발행자와 소비자, 스키마, 로그, 테스트를 확인해야 한다면 전체 개발 비용은 줄지 않습니다. 수정은 빨라졌지만, 그 변경을 안전하다고 판단하는 데 드는 비용은 그대로 남기 때문입니다.

그래서 이벤트 기반 MSA를 AI와 함께 운영하려면 더 긴 프롬프트만으로는 부족합니다. 사람과 AI가 같은 이벤트 흐름을 보고, 같은 변경 기준을 따라야 합니다. 이 글은 이벤트 기반 MSA를 버리자는 이야기가 아닙니다. AI 시대에도 이 구조를 계속 운영하려면, 나뉜 흐름을 다시 확인할 수 있는 기준과 변경을 안전하게 검증하는 절차를 함께 설계해야 한다는 이야기죠.

미리 요점만 콕 집어보면?

이벤트 기반 MSA는 장애 격리와 도메인별 책임 분리에 도움이 되지만, 시간이 지날수록 이벤트 이름, 페이로드, 컨슈머, 처리 규칙을 계속 맞춰봐야 하는 비용이 쌓입니다.
AI 에이전트는 현재 저장소 안에서는 코드를 빠르게 고칠 수 있지만, 다른 서비스가 그 이벤트를 어떻게 소비하는지 모르면 현재 서비스 안에서만 맞는 수정을 만들 수 있습니다.
이벤트 기반 MSA를 AI와 함께 운영하려면 더 긴 프롬프트보다, 이벤트 흐름을 볼 수 있는 기준과 변경 전후 확인 절차가 필요합니다. 사람과 AI가 같은 맥락을 보고 같은 기준으로 검증할 수 있어야 합니다.

1. 이벤트 기반 MSA는 왜 AI에게 더 높은 컨텍스트 비용을 만드는가

느슨한 연결은 맥락을 없애지 않고 흩어놓는다

이벤트 기반 MSA를 운영할 때 처음 보이는 장점은 분명합니다. 주문은 주문 서비스가, 결제는 결제 서비스가, 재고는 재고 서비스가 맡습니다. 알림이나 배송은 이벤트를 받아 각자 처리합니다. 덕분에 한쪽 장애가 곧바로 전체 요청을 막지 않고, 배포할 때도 책임 범위를 도메인 단위로 나눠볼 수 있습니다.

<출처: 작가, ChatGPT로 제작>

문제는 시간이 지나면서 의존성이 다른 형태로 남는다는 점입니다. 직접 호출은 줄었지만, 연결은 사라지지 않습니다. 주문 생성 이벤트(OrderCreated)를 누가 발행하는지, 어떤 컨슈머가 어떤 값을 기대하는지, 실패하면 어디서 재처리하는지로 옮겨갈 뿐입니다. 코드에서 호출 관계가 보이지 않는다고 해서, 서비스들이 서로 독립적으로 움직인다는 뜻은 아닙니다.

그래서 실무에서는 이벤트 하나를 바꿀 때 코드만 보지 않습니다. 팀 컨벤션, 이벤트 스키마, 대시보드, 운영 로그를 함께 확인합니다. 이벤트를 수정한다면 이 이벤트가 어떤 조건에서 발행되는지, 결제와 배송 쪽에서 어떤 값을 기대하는지, 실패했을 때 어디서 재처리되는지까지 맞춰봅니다. 코드 한 줄은 현재 저장소에 있지만, 그 코드가 지켜야 할 약속은 여러 서비스와 운영 도구에 흩어져 있기 때문입니다.

결국 이벤트 기반 MSA의 느슨한 연결은 양면성을 가집니다. 장애를 격리하고 서비스 책임을 나누는 데는 도움이 되지만 변경을 검토할 때는 흩어진 연결을 다시 모아야 합니다. 이 구조를 운영하려면 “이벤트 흐름을 다시 추적할 수 있는가?”가 더 중요해집니다.

AI가 만든 수정은 빠르지만, 영향 범위는 사람이 다시 확인해야 한다

AI 에이전트를 유지보수 흐름에 넣으면 이 차이가 더 선명해집니다. AI는 작업 범위로 제공된 저장소와 문서 안에서는 빠르게 수정안을 만듭니다. 조건문을 고치고, 타입을 맞추고, 테스트도 붙입니다. 하지만 같은 이벤트를 받는 결제, 재고, 배송 서비스의 처리 방식까지 함께 아는 것은 아닙니다. 대시보드에서만 확인되는 흐름, 장애 대응 중 정해진 재처리 규칙, 문서화되지 않은 운영 약속은 별도로 넘기지 않으면 작업 맥락에 들어오지 않습니다.

그래서 AI가 만든 수정안은 현재 서비스 안에서는 자연스러워 보여도, 다른 서비스가 기대하던 이벤트 계약을 깨뜨릴 수 있습니다. 예를 들어 이벤트의 필드 하나를 정리하는 변경도, 결제 서비스나 배송 서비스가 그 값을 기준으로 분기하고 있다면 단순한 정리가 아닙니다. 현재 저장소에서는 작은 수정이지만, 전체 이벤트 흐름에서는 계약 변경이 됩니다.

결국 문제는 AI가 코드를 못 고치는 데 있지 않습니다. AI가 보지 못한 연결을 사람이 다시 이어 붙여야 한다는 데 있습니다. PR은 빨리 만들어지지만, 리뷰어는 다시 이벤트 문서와 로그, 대시보드, 다른 저장소를 오가며 “이 이벤트가 어디까지 영향을 주는가”를 확인해야 합니다.

이 확인 절차를 따로 설계하지 않으면, 이벤트 기반 MSA의 장점은 AI 시대에 리뷰 비용으로 돌아옵니다. 느슨한 연결은 서비스 운영에는 유리하지만, 변경 검증까지 자동으로 해결해주지는 않습니다. AI가 빠르게 코드를 바꿀수록, 그 변경이 전체 이벤트 흐름 안에서 안전한지 확인하는 기준도 함께 준비되어야 합니다.

2. 코드가 맞아 보이는 것과 실제로 동작하는 것은 다르다

이벤트 변경은 기능 수정이 아니라 계약 변경이다

이벤트 기반 MSA에서 조심해야 할 지점은 변경의 크기보다 변경의 성격입니다. 주문 서비스 안에서 보면 단순한 기능 수정처럼 보이는 일이, 다른 서비스 입장에서는 계약 변경이 될 수 있습니다. 주문 생성 이벤트의 필드명을 정리하거나, 상태 값을 조금 더 명확하게 바꾸거나, 이벤트 버전을 올리는 작업이 대표적입니다. 현재 저장소 안에서는 작은 수정입니다. 하지만 그 이벤트를 결제, 재고, 배송, 알림 서비스가 함께 보고 있다면 이야기는 달라집니다.

<출처: 작가, ChatGPT로 제작>

이벤트는 단순한 알림이 아니라, 서비스 사이의 약속입니다. 주문 서비스는 “주문이 생성됐다”는 사실을 이벤트로 발행하고, 다른 서비스는 그 이벤트 안의 값을 믿고 자기 일을 시작합니다. 결제 서비스는 주문 ID와 결제 금액을 읽고, 재고 서비스는 상품 ID와 수량을 기준으로 재고를 예약합니다. 배송 서비스는 주소나 배송 가능 상태를 보고 후속 처리를 준비할 수 있습니다. 이때 이벤트에 담긴 페이로드가 조금만 달라져도, 컨슈머 입장에서는 기대하던 입력이 바뀐 셈입니다.

AI 에이전트는 이런 변경을 꽤 그럴듯하게 처리합니다. 주문 생성 이벤트에 누락된 필드를 추가하고, 이름이 모호한 필드를 정리하고, 테스트가 깨지지 않도록 타입도 맞춥니다. 현재 서비스의 코드만 보면 변경은 깔끔해 보입니다. 단위 테스트가 통과하고, CI의 기본 검증도 통과할 수 있습니다. 그러나 그 검증이 모든 컨슈머의 기대값까지 보장한다는 뜻은 아닙니다. 주문 서비스 안에서는 작은 정리였지만, 다른 서비스 입장에서는 입력 계약이 바뀐 변경일 수 있습니다.

이 관점이 없으면 리뷰도 잘못된 기준으로 흘러갑니다. 코드가 깔끔한지, 타입이 맞는지, 테스트가 통과하는지만 보게 됩니다. 물론 이 기준은 필요합니다. 하지만 이벤트 기반 MSA에서는 한 가지 질문이 더 필요합니다. “이 변경이 어떤 컨슈머의 기대값을 바꾸는가?” 이 질문에 답하지 못하면 코드 품질은 좋아졌지만 제품 흐름은 깨질 수 있습니다.

이벤트의 문제는 보낸 쪽보다 받는 쪽에서 드러난다

REST API에서는 요청과 응답이 같은 흐름 안에 있습니다. 주문 서비스가 결제 API를 호출했고 200 응답을 받았다면, 호출한 쪽은 최소한 요청이 대상 서비스에 도달했고 정상 응답이 돌아왔다는 사실을 바로 알 수 있습니다. 실패도 비교적 명확합니다. 응답 코드, 타임아웃, 예외를 기준으로 재시도하거나 롤백하거나 사용자에게 실패를 알릴 수 있습니다.

이벤트 기반 구조에서는 이 기준이 그대로 통하지 않습니다. 발행자 입장에서 이벤트를 정상적으로 내보냈다는 사실은 전체 흐름의 성공을 의미하지 않습니다. 이벤트가 브로커에 적재됐는지, 컨슈머가 가져갔는지, 핸들러가 기대한 값으로 처리했는지, 처리 결과가 각 서비스의 상태에 반영됐는지는 별도의 검증 대상입니다. 이벤트 기반 MSA에서 발행 성공은 완료가 아니라 시작에 가깝습니다.

<출처: 작가, ChatGPT로 제작>

주문 생성 이벤트의 페이로드에서 결제 금액 필드를 정리했다고 해보겠습니다. 주문 서비스 로그에는 이벤트가 정상 발행된 것으로 남을 수 있습니다. 발행자 기준에서는 문제가 없어 보입니다. 하지만 결제 컨슈머가 이전 필드명을 기준으로 결제 대기 상태를 만들고 있었다면, 이벤트는 도착했어도 처리 흐름은 멈춥니다. 이때 문제는 주문 서비스의 발행 로그가 아니라, 이벤트를 받은 쪽의 기대값에서 드러납니다.

그래서 이벤트 기반 MSA의 검증은 발행자 쪽에서 끝나면 안 됩니다. 이벤트가 발행됐는지 확인한 뒤에는 페이로드 변경이 기존 컨슈머와 맞는지, 브로커에 메시지가 적재됐는지, 컨슈머가 실제로 처리했는지까지 이어서 봐야 합니다. 실패했다면 재시도 횟수, 실패 로그, DLQ(Dead Letter Queue, 처리 실패 메시지를 따로 모아두는 큐) 적재 여부도 확인해야 합니다. 마지막으로 주문 상태나 결제 상태처럼 사용자가 보거나 운영자가 확인하는 결과가 기대한 값으로 바뀌었는지 확인해야 합니다. 발행 로그만으로는 전체 흐름이 성공했다고 말하기 어렵기 때문입니다.

AI 에이전트가 만든 수정안에서는 이 검증의 빈틈이 더 쉽게 생깁니다. AI는 발행자 서비스 안에서 타입을 맞추고 테스트를 붙이는 데는 빠릅니다. 하지만 어떤 컨슈머가 해당 이벤트를 읽는지, 어떤 필드를 기준으로 분기하는지, 실패 메시지가 어느 DLQ로 빠지는지는 별도 맥락을 주지 않으면 알 수 없습니다. 결국 코드만 보면 완성된 PR처럼 보여도, 리뷰할 때는 받는 쪽의 기대값과 처리 결과를 다시 확인해야 합니다.

결국 이벤트 기반 MSA에서 코드가 맞아 보이는 것과 실제로 동작하는 것은 다릅니다. REST API에서는 호출 성공이 중요한 단서가 되지만, 이벤트 기반 구조에서는 발행 성공만으로 전체 흐름의 성공을 대신할 수 없습니다. 이 기준이 없으면 AI가 줄여준 작성 시간은 리뷰어가 컨슈머, 로그, 대시보드, 다른 저장소를 다시 확인하는 시간으로 바뀝니다.

3. AI에게 맡기기 전에, 이벤트 흐름부터 공유해야 한다

이벤트 계약은 AI가 읽을 수 있는 기준으로 남겨야 한다

AI 에이전트에게 이벤트 기반 MSA를 맡길 때 먼저 정리해야 할 질문은 “AI가 얼마나 많은 코드를 볼 수 있느냐”가 아닙니다. 더 중요한 질문은 “AI가 무엇을 기준으로 변경할 수 있느냐”입니다. AI가 어떤 이벤트 계약을 지켜야 하는지, 그 이벤트가 어떤 서비스로 흘러가는지, 수정 이후 무엇을 확인해야 하는지 읽을 수 있어야 합니다. 이 기준이 없으면 AI는 현재 저장소 안에서 가장 그럴듯한 답을 만듭니다. 그래서 이벤트 계약은 사람이 읽는 문서이면서, AI가 작업 전에 참고할 수 있는 기준으로 남아 있어야 합니다.

다만 이 글은 특정 도구의 설치 방법이나 세부 설정을 깊게 설명하는 글은 아닙니다. 스키마 레지스트리(Schema Registry), 비동기 API 명세인 AsyncAPI, 이벤트 카탈로그(EventCatalog) 외에도 좋은 선택지는 많습니다. 여기서는 이벤트 기반 MSA를 운영하는 팀이 비교적 검토하기 쉬운 오픈소스 몇 가지를 예로 들어, AI에게 어떤 이벤트 맥락을 넘겨야 하는지에 초점을 맞춥니다. 중요한 것은 도구의 기능을 비교하는 것이 아니라, AI가 이벤트 계약과 흐름을 확인할 수 있는 기준을 어디에 둘 것인가입니다.

<출처: 컨플루언스 공식 문서>

카프카(Kafka) 환경이라면 스키마 레지스트리(Schema Registry)는 페이로드 변경을 먼저 걸러내는 기준이 됩니다. 이벤트에 담기던 값이 사라지거나, 값의 형식이 바뀌거나, 항상 들어오던 값이 어느 순간 비어 있을 수 있게 바뀌면 기존 컨슈머는 같은 이벤트를 받아도 다르게 동작할 수 있습니다.

AI가 보기에는 불필요한 값을 정리한 것처럼 보여도, 컨슈머 입장에서는 약속된 입력이 바뀐 셈입니다. Confluent Schema Registry 문서는 스키마가 시간이 지나며 바뀔 수 있고, 새 스키마 버전을 기존 버전과 비교해 호환성 규칙을 적용한다고 설명합니다. 스키마 레지스트리는 이런 변경을 리뷰어의 감각이 아니라 시스템 기준으로 먼저 확인하게 만듭니다.

<출처: AsyncAPI 공식 문서>

AsyncAPI는 이벤트 계약을 문서와 명세로 남기는 기준이 됩니다. REST API에서 OpenAPI를 보고 요청과 응답의 약속을 확인하듯, 이벤트 기반 구조에서도 어떤 채널로 어떤 메시지가 오가고, 누가 보내고 누가 받는지 확인할 기준이 필요합니다.

AsyncAPI 공식 문서는 AsyncAPI를 메시지 기반 API를 기계가 읽을 수 있는 형태로 설명하는 명세라고 설명하며, Kafka, MQTT, WebSocket 같은 여러 프로토콜에 적용할 수 있다고 안내합니다. AI에게 “이 이벤트를 수정해줘”라고 맡기는 것과 “이 메시지 구조와 수신자 기대값을 지키면서 수정해줘”라고 맡기는 것은 다릅니다. AsyncAPI는 후자의 기준을 남기는 데 가깝습니다.

<출처: EventCatalog 공식 문서>

EventCatalog는 이벤트 흐름과 소유권을 함께 보는 기준이 됩니다. 스키마는 이벤트에 어떤 데이터가 담기는지 알려주지만, 그 이벤트가 어떤 도메인에서 시작해 어느 서비스로 이어지고 누가 책임지는지까지 설명하지는 않습니다.

EventCatalog 공식 문서는 도메인, 서비스, 이벤트, 스키마를 문서화하고 OpenAPI, AsyncAPI, 스키마 레지스트리와 동기화할 수 있다고 설명합니다. 또한 이벤트 기반 시스템에서 무엇이 존재하고 어떻게 연결되는지 찾고, 시각화하고, 안전하게 변경하도록 돕는다는 점을 강조합니다. 이 지점이 이번 글의 핵심과 맞닿아 있습니다. AI에게 필요한 것은 긴 설명이 아니라, 현재 저장소 밖의 이벤트 관계를 확인할 수 있는 기준입니다.

이 세 가지는 서로 대체 관계가 아닙니다. 스키마 레지스트리는 페이로드 호환성을 확인하고, AsyncAPI는 이벤트 계약을 명세로 남기고, EventCatalog는 이벤트 흐름과 소유권을 보여줍니다. 팀이 이 모든 것을 한 번에 갖출 필요는 없습니다. 다만 AI 에이전트를 유지보수 흐름에 넣겠다면, 최소한 어떤 방식으로 이벤트 계약과 흐름을 AI에게 넘길지 정해야 합니다.

이 기준이 없으면 AI는 현재 저장소 안에서 가장 자연스러운 수정을 만듭니다. 하지만 이벤트 기반 MSA에서 자연스러운 수정과 안전한 수정은 다를 수 있습니다. 페이로드 호환성이 확인되고, 메시지 계약이 남아 있고, 이벤트 흐름과 소유권이 보일 때 리뷰어는 영향 범위를 더 빨리 판단할 수 있습니다. 결국 이벤트 계약을 구조화하는 일은 문서를 늘리는 일이 아닙니다. AI가 만든 변경을 제품 흐름 안에서 검토할 수 있게 만드는 일입니다.

먼저 정해야 할 것은 팀의 검증 기준이다

앞에서 몇 가지 선택지를 예로 들었지만, 결국 중요한 것은 특정 도구를 사용하느냐가 아닙니다. 팀이 이벤트 변경을 어떤 기준으로 판단하고, 그 기준을 사람과 AI가 함께 볼 수 있는 형태로 남겨두는지가 더 중요합니다. 처음부터 완성된 체계를 만들 필요는 없습니다. 특정 이벤트가 어디서 발행되고, 어떤 서비스에서 소비되며, 페이로드가 바뀔 때 무엇을 확인해야 하는지 정리하는 것부터 시작할 수 있습니다. 문서, 대시보드처럼 팀이 계속 꺼내볼 수 있는 형태면 충분합니다.중요한 것은 형식이 아니라, 같은 변경을 검토할 때마다 같은 기준을 꺼내볼 수 있느냐입니다.

이 기준은 복잡할 필요가 없습니다. 이벤트를 바꾸기 전에 최소한 몇 가지 질문에 답할 수 있으면 됩니다. 이 이벤트는 어느 서비스에서 발행되는가. 어떤 서비스가 이 이벤트를 소비하는가. 페이로드에서 다른 서비스가 기대하는 값은 무엇인가. 이벤트 이름, 상태 값, 필드 의미가 바뀌었을 때 영향을 받는 컨슈머는 누구인가. 수정 후에는 어떤 테스트와 로그, 최종 상태를 확인해야 하는가. 이 질문들이 매번 리뷰어의 머릿속에서만 반복되면 비용은 줄지 않습니다.

<출처: 작가, ChatGPT로 제작>

AI 에이전트를 사용할 때는 이 기준이 작업 범위를 잡아주는 역할을 합니다. “이 버그를 고쳐줘”라고만 맡기면 AI는 현재 저장소 안에서 가장 자연스러운 수정을 만듭니다. 하지만 팀 내 이벤트 규칙을 함께 넘기면 결과가 달라집니다. 예를 들어 이벤트를 수정할 때 발행자와 주요 컨슈머를 함께 확인해야 한다는 규칙, 페이로드 변경 여부를 표시해야 한다는 규칙, 수정 후 확인해야 할 테스트와 로그를 남겨야 한다는 규칙이 있다면, AI는 그 기준 안에서 움직입니다. AI가 모든 맥락을 스스로 추론하는 것이 아니라, 팀이 정한 검증 기준을 따라 작업하게 되는 것입니다.

이 기준은 변경 전과 변경 후로 나눠두면 더 다루기 쉽습니다. 변경 전에는 이벤트의 발행자, 컨슈머, 페이로드, 소유 도메인을 확인합니다. 변경 후에는 주요 컨슈머가 같은 값을 읽을 수 있는지, 대표 흐름의 테스트가 통과하는지, 실패 로그나 DLQ에 메시지가 쌓이지 않는지, 최종 상태가 기대한 대로 바뀌었는지 확인합니다. 이 기준을 문서에만 남겨두지 않고 팀 규칙이나 CI 파이프라인에 연결해두면, AI가 만든 검증되지 않은 변경도 배포 전에 걸러낼 수 있습니다. 코드가 깔끔한지보다 먼저, 이벤트 흐름이 유지되는지 확인할 수 있기 때문입니다.

중요한 것은 기준을 한 번 정리해두는 데서 끝내지 않는 것입니다. 이벤트 흐름과 운영 방식은 계속 바뀝니다. 새로운 컨슈머가 붙고, 더 이상 쓰지 않는 이벤트가 남고, 페이로드의 의미도 조금씩 달라집니다. 그런데 기준이 오래된 문서에만 남아 있으면 사람도 AI도 잘못된 맥락을 기준으로 판단하게 됩니다. 그래서 이벤트 규칙은 팀이 계속 갱신할 수 있고, AI도 작업 전에 읽을 수 있는 위치에 있어야 합니다.

이 기준이 없으면 AI를 붙인 뒤에도 리뷰어는 같은 일을 반복합니다. 이 이벤트가 어디서 발행되는지 찾고, 누가 소비하는지 확인하고, 페이로드가 바뀌었는지 보고, 실패하면 어디서 재처리되는지 다시 확인합니다. AI가 코드를 빠르게 고쳐도 이 확인이 매번 사람에게 남으면 전체 비용은 줄지 않습니다. 오히려 PR이 빨리 올라오는 만큼 승인해야 할 변경은 늘어나고, 리뷰어는 더 자주 같은 맥락을 복원해야 합니다.

반대로, 팀의 이벤트 규칙이 정리되어 있으면 AI가 만든 수정안을 보는 방식이 달라집니다. 리뷰어는 처음부터 이벤트 흐름을 다시 그리지 않아도 됩니다. 어떤 이벤트가 영향을 받았는지, 어떤 컨슈머를 확인해야 하는지, 어떤 테스트와 로그가 있어야 안전하다고 볼 수 있는지 바로 판단할 수 있습니다. 이때 AI는 단순히 코드를 빨리 쓰는 도구가 아니라, 팀이 정한 기준 안에서 변경을 수행하는 실행자가 됩니다.

결국 AI 시대의 이벤트 기반 MSA에 필요한 것은 더 많은 선택지가 아니라, 사람과 AI가 함께 따를 수 있는 검증 기준입니다. 비용은 서비스를 나눴다는 사실보다, 나뉜 흐름을 매번 다시 확인하는 과정에서 커집니다. 이 과정을 팀 규칙으로 고정하고 배포 전 검증 과정에 연결해두면, 검증되지 않은 이벤트 변경을 더 일찍 걸러낼 수 있습니다. 서비스를 나눌 수 있는가보다 중요한 질문은, 나눈 뒤에도 변경을 끝까지 검증할 수 있는가입니다.

마치며: 나눌 수 있는가보다, 검증할 수 있는가

이벤트 기반 MSA는 버려야 할 구조가 아닙니다. 장애를 격리하고, 도메인별 책임을 나누고, 후속 작업을 독립적으로 확장하는 데 여전히 유효한 선택입니다. 다만 AI 에이전트가 개발 과정에 들어오면 이 구조의 비용이 더 선명하게 드러납니다. AI는 코드를 빠르게 바꿀 수 있지만, 보이지 않는 이벤트 흐름까지 자동으로 책임지지는 않습니다.

그래서 이벤트 기반 MSA를 선택하기 전에 확인해야 할 질문은 달라져야 합니다. “이 기능을 서비스로 나눌 수 있는가”보다 “나눈 뒤에도 변경 영향을 추적할 수 있는가”를 먼저 물어야 합니다. 이벤트의 소유권, 페이로드 변경 기준, 컨슈머 영향 범위, 실패 시 재처리 경로, 로그와 추적 기준이 없다면 서비스 분리는 운영 비용을 줄이는 선택이 아니라 검토 비용을 키우는 선택이 됩니다.

AI 시대의 아키텍처 선택은 구현 가능성보다 검증 가능성에 가까워집니다. 느슨한 연결을 선택했다면, 그 흐름을 다시 볼 수 있는 기준도 함께 설계해야 하죠. 사람과 AI가 같은 이벤트 맥락을 보고, 같은 규칙으로 변경을 검토하고, 같은 기준으로 배포를 승인할 수 있을 때, 이벤트 기반 MSA는 비용이 아니라, 속도와 신뢰를 함께 만드는 구조가 될 겁니다.

]]>

“이 정도면 직접 만들겠는데?” 바이브 코딩으로 유료 앱 대체하기

저는 평소 루틴 관리를 위해 유료 앱을 하나 쓰고 있었습니다. 기능 자체는 꽤 만족스러웠습니다. 돈이 아깝다는 생각이 들 정도도 아니었고, 오히려 “이 정도면 잘 만든 앱이지” 쪽에 가까웠죠.

그런데 요즘 들어 쓰면 쓸수록 작은 아쉬움들이 계속 쌓였습니다. 이를테면 루틴마다 제가 중요하게 생각하는 무게가 다른데, 이 앱은 모든 체크를 똑같이 취급한다는 점이 그랬습니다. 이를테면 운동 1시간과 물 마시기 한 번을 같은 체크로 두기 아쉬웠습니다. 또, 이번 달을 내가 어떤 흐름으로 보내고 있는지, 나아가 연 단위로 얼마나 꾸준히 해왔는지를, 제 방식대로 보고 싶다는 생각도 점점 커졌습니다.

예전 같았으면 그냥 아쉽다 하고 넘어갔을 것 같습니다. 그런데 요즘은 좀 다릅니다. AI 덕분에 무언가를 직접 만들어보는 진입장벽이 확실히 낮아졌으니까요. 예전에는 개인용 도구 하나 만들자고 해도 괜히 구조부터 고민해야 했습니다. 파일 구조는 어떻게 잡을지, 상태 관리는 어떻게 할지, 나중에 확장하려면 어떤 방식이 좋을지. 만들기도 전에 피곤해졌죠. 반면 지금은 필요한 기능만 머릿속에 있으면 일단 시작해볼 수 있습니다. 완벽한 설계보다 빠른 구현이 더 자연스러운 시대가 된 느낌이랄까요.

이번 작업도 그런 흐름으로 시작했습니다. 어느 날 오후에 문득 “이 정도면 직접 만들 수 있겠는데?”라는 생각이 들었고, 그 생각을 바로 테스트해보기로 한 겁니다. 거창하게 기획 문서를 쓰지도, 화면 설계를 하지도 않았습니다. 기획을 위해 정말 필요한 것만 적었습니다. 루틴 체크가 되어야 하고, 모바일과 데스크톱에서 둘 다 써야 하고, 월간 진행 현황과 연간 히트맵 정도는 보고 싶고, 메모도 붙일 수 있었으면 좋겠다. 딱 그 정도였습니다. 그리고 바로 Obsidian과 Claude를 붙여서 만들기 시작했습니다.

특히 재밌었던 건, 서비스를 개발한다기보다 “내가 쓰고 싶은 도구를 만든다”는 생각으로 시작했다는 점입니다. 직접 만들다 보니 이 차이가 생각보다 크게 다가왔습니다. 남들이 다 써야 하는 제품을 만들 때는 고려해야 할 게 정말 많지만, 개인용 도구는 기준이 명확하니까요. 제가 매일 쓰면 성공입니다. 제가 보기 편하면 잘 만든 겁니다. 그래서 오히려 더 빠르게 결정할 수 있었고, 훨씬 덜 부담스러웠습니다. 아마 이게 바이브 코딩의 가장 큰 매력 중 하나 아닐까 싶습니다. 완성도 높은 제품을 목표로 하기보다, 일단 내가 만족할 결과물을 빠르게 만드는 데 정말 잘 맞는 방식이니까요.

Obsidian + Claude Code로 구현한 핵심 기능

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

이번에 이걸 만들면서 제게 가장 중요했던 건 내가 매일 부담 없이 쓸 수 있는지였습니다. 개인용 도구는 이 기준이 정말 중요합니다. 남들에게 보여주기 위한 서비스가 아니라, 제가 아침에 열고 밤에 다시 보는 도구니까요. 그래서 처음부터 기술적인 화려함보다는, 익숙한 환경 안에서 빠르게 만들어 계속 손이 갈만한 쪽을 택했습니다.

Obasidian과 Claude Code를 선택한 이유

그 기준에서 Obsidian은 꽤 자연스러운 선택이었습니다. 원래도 자주 쓰던 작업 환경이었고, 무엇보다 텍스트 기반으로 데이터를 직접 관리할 수 있다는 점이 좋았습니다. 루틴 기록이라는 게 결국 매일 쌓이는 생활 데이터인데, 이걸 특정 서비스 안에만 가두기보다 제가 원하는 구조로 쌓아두고 싶다는 마음이 있었거든요. Obsidian은 노트, 메모, 템플릿, 데이터 조회가 한 공간 안에서 이뤄지니까 이런 용도에 잘 맞았습니다. 즉, 앱을 하나 새로 만든다기보다, 원래 쓰던 작업 공간을 제 생활 데이터에 맞게 확장한다는 느낌이 더 강했습니다.

Claude Code를 사용한 이유도 비슷합니다. 이번 작업은 정교한 제품 설계보다, 필요한 기능을 빠르게 붙이고 바로 써보는 흐름이 훨씬 중요했습니다. 그럴 때는 코드 한 줄 한 줄을 처음부터 직접 치는 방식보다 제가 원하는 동작을 설명하고 결과를 보면서 바로 수정해나가는 방식이 훨씬 잘 맞았습니다. 특히 이번에는 단순히 텍스트를 정리하는 수준을 넘어 대시보드나 시각화처럼 손이 더 많이 가는 부분이 있었는데요. 그런 부분을 Claude Code가 JavaScript로 빠르게 구현해주니까 개발 속도가 확실히 빨랐습니다. 예전 같았으면 나중에 시간 나면 붙이자고 넘겼을 기능들을 이번엔 흐름이 끊기기 전에 바로 붙일 수 있었던 거죠.

활용한 Obasidian 플러그인 3가지

플러그인도 소수만 쓰기로 했습니다. 이번에 실제로 사용한 건 Git 플러그인, Templater, Dataview 정도였고, 나머지 핵심 인터랙션이나 대시보드 같은 부분은 Claude Code가 JavaScript로 구현해줬습니다. 그리고 이 방식이 꽤 마음에 들었습니다. Obsidian 플러그인을 이것저것 많이 얹어서 복잡하게 만드는 방식보다, 기본적인 데이터 흐름은 단순하게 가져가고, 진짜 필요한 부분만 직접 구현하는 쪽이 더 제 스타일에 맞았거든요.

역할도 명확했습니다. Git 플러그인은 여러 기기에서 데이터를 이어 관리하는 데 큰 도움이 됐습니다. 회사 PC, 개인 맥북, 모바일을 오가며 써야 했기 때문에, 기록이 한 군데에만 있으면 의미가 없었거든요. 저는 원래도 개인용 비공개 저장소를 관리하고 있었기에, 기기별 작업 환경은 분리하며 데이터는 자연스럽게 이어갈 수 있었습니다. 루틴 앱처럼 매일 쓰는 도구에 정말 중요한 접근성은 이처럼 Git 플러그인이 해소해줬습니다.

Templater는 반복 입력을 줄이는 데 유용했습니다. 루틴 기록은 하루 이틀 쓸 땐 괜찮은데, 며칠만 지나도 포맷이 흐트러지기 쉽습니다. 메모 형식이 조금씩 달라지고, 항목 순서가 바뀌고, 그러다 보면 나중에 조회할 때도 애매해지죠. 이를 마고자 Templater를 붙여두니 기본 구조를 일정하게 유지하기가 훨씬 쉬웠습니다. 매일 같은 틀 안에서 기록할 수 있으니 입력 부담도 줄고, 뒤에서 데이터를 다룰 때도 훨씬 편해졌습니다. 별거 아닌 것 같지만, 이런 반복 입력 자동화가 있어야 오래 쓸 것이라고 생각했습니다.

Dataview는 이 기록들을 다시 봐야할 때 쓰기 좋았습니다. 루틴 데이터는 쌓이는 것만으로 별 의미가 없습니다. 결국 중요한 건 내가 이걸 어떻게 다시 읽어낼까 하는 거죠. Dataview 덕분에 루틴별 기록을 조회하거나, 특정 기간의 흐름을 정리하거나, 메모를 모아서 다시 보는 작업이 꽤 수월해졌습니다. 기본적으로는 이 플러그인이 데이터 조회 레이어를 맡아준 셈이고, 그 위에서 필요한 시각화나 대시보드 성격의 기능은 Claude Code가 JavaScript로 붙여준 구조에 가깝습니다.

핵심 기능 개발하기

1. 가중치를 더한 루틴 체크

기능 측면에서는 가장 먼저 루틴 체크부터 만들었습니다. 다만 단순히 체크만 하는 구조로 끝내고 싶진 않았습니다. 기존 루틴 앱을 쓰면서 가장 아쉬웠던 게, 모든 루틴이 똑같은 1회 체크로 처리된다는 점이었거든요.

실제 삶에서는 루틴마다 무게가 다릅니다. 물 마시기 한 번과 1시간 운동을 같은 일로 취급할 수는 없죠. 그래서 루틴별로 가중치를 둘 수 있게 만들었고, 제가 생각하는 “충만한 하루”를 제 기준대로 다시 설계했습니다.

<출처 : 작가>

이 부분은 만들고 나서도 꽤 만족스러웠습니다. 남이 정의한 하루가 아니라, 내가 납득하는 하루의 기준을 직접 만들었다는 느낌이 들었거든요.

2. 월/연간 대시보드

그다음은 대시보드였습니다. 사실 이 부분이 기존 서비스 대비 가장 차별점이 컸던 것 같습니다. 저는 단순히 오늘 루틴을 몇 개 완료했는지보다, 이번 달 전체 흐름이 어떤지, 연간으로 보면 어떤 패턴이 보이는지가 더 궁금한 사람이거든요. 그래서 월간 진행 현황과 연간 히트맵을 볼 수 있는 대시보드를 붙였습니다.

<출처 : 작가>

여기서 중요한 건, 이걸 Obsidian 플러그인만으로 해결하려고 하지 않았다는 점입니다. 조회는 Dataview로 하고, 진짜 보고 싶은 화면은 Claude Code가 JavaScript로 구현해주는 식으로 갔더니 훨씬 유연했습니다. 덕분에 원래 있는 기능에 나를 맞추는 게 아니라, 내가 보고 싶은 화면을 직접 만드는 쪽으로 갈 수 있었습니다.

3. 루틴 메모

루틴별 메모 기능도 넣었습니다. 이건 사소해 보여도 의외로 중요했습니다. 루틴은 결국 맥락의 영향을 많이 받는데요. 왜 오늘은 잘 됐는지, 왜 어제는 실패했는지, 이런 맥락은 단순 체크만으로는 잘 안 보입니다.

그럴 때는 짧게라도 메모를 남겨두는 것이 좋습니다. “회의가 길어져서 운동을 못 했다”, “아침 기상에 성공했더니 다른 루틴도 연쇄적으로 잘 됐다” 같은 기록을 쌓으면, 그때부터는 앱이 체크 로그가 아니라 생활 데이터가 됩니다. 나중에 돌아보면 오히려 체크 횟수보다 이런 메모가 더 많은 걸 알려줄 때도 있었습니다.

<출처 : 작가>

그리고 여기서 한 단계 더 갔습니다. 루틴 데이터와 메모가 이미 쌓이고 있으니, 이걸 기반으로 Claude에게 다시 내 생활 패턴을 물어볼 수 있게 만든 겁니다. 예를 들면 어떤 루틴이 다른 루틴과 같이 성공하는 경향이 있는지, 이번 달 흐름이 무너진 시점이 언제인지, 메모에서 반복적으로 등장하는 패턴이 뭔지 같은 걸 질문하는 식이었죠. 결과는 따로 insights 폴더에 모아두도록 했고요.

이 기능을 붙이고 나니까, 단순히 기록하는 앱을 만든 게 아니라 기록을 다시 읽고 해석하는 도구를 만든 느낌이 들었습니다.

<출처 : 작가>

결과적으로 이번 구성은 Obsidian 플러그인을 잘 조합해서 만든 루틴 앱이라기보다, Obsidian을 데이터 기반으로 삼고, Git·Templater·Dataview 같은 플러그인으로 뼈대를 세운 다음, 부족한 부분은 Claude Code가 JavaScript로 직접 메운 개인용 도구에 더 가까웠습니다.

이 방식이 꽤 마음에 들었습니다. 플러그인에 너무 많이 기대지 않으면서도, 필요한 건 빠르게 구현할 수 있었거든요. 만들수록 제가 원했던 건 그냥 루틴 체크 앱이 아니었구나 싶었습니다. 체크를 넘어서, 제 하루를 제가 원하는 구조로 기록하고 다시 해석할 수 있는 도구가 필요했던 거죠.

가장 큰 난관이었던 데이터 마이그레이션

물론 즐거운 일만 있었던 건 아니었습니다. 이번 작업에서 가장 어려웠던 건 의외로 구현이 아니었습니다. 루틴 체크 기능을 만들고, 대시보드를 붙이고, 메모 구조를 잡는 것까지는 생각보다 순조로웠으니까요. 진짜 문제는 그다음부터였습니다.

제가 기존에 쓰던 유료 루틴 앱에는 이미 아주 많은 데이터가 쌓여 있었습니다. 올해 기록만 해도 적지 않았고, 단순 체크만 있는 것도 아니었습니다. 날짜별 체크 이력에 메모들도 붙어 있었죠. 새로 만든 도구가 아무리 마음에 들어도, 이 데이터를 못 옮기면 결국 다시 원래 서비스로 돌아갈 가능성이 높았습니다. 시작은 재밌게 했는데, 정작 갈아타는 데 실패하는 가장 흔한 패턴이 딱 이런 경우니까요.

<출처 : 작가>

문제의 본질을 챙기기

처음엔 뭐, 조금씩 손으로 옮기면 되지 않을까 하는 생각도 해봤는데요, 바로 포기했습니다. 이런 종류의 수작업은 시작하는 순간 끝이 보입니다. 하루 이틀은 할 수 있겠죠. 하지만 월별로 쌓인 체크 기록과 메모를 계속 다시 입력하는 건, 프로젝트에 대한 애정을 증발시키기 아주 쉽습니다. 특히 루틴 데이터는 건수가 많기에, 얼핏 단순해 보여도 날짜 하나만 틀리면 흐름이 다 망가집니다. 저 역시 이걸 하다가 원래 앱으로 돌아갈 생각을 할 게 너무 뻔했습니다.

그래서 방향을 바꿨습니다. 입력 노동으로 문제를 두면 답이 없지만, 데이터 추출로 보면 얘기가 달라질 거라 생각했거든요. 그렇게 두고 보니 아주 단순한 해결책이 떠올랐습니다. “이거 스크린샷으로 읽히면 되는 거 아닌가?”

기존 앱에는 월별 통계 화면이 있었고, 여기에는 루틴 체크 달력과 메모가 함께 나타납니다. 사람 눈으로 봐도 이미 정보가 거의 다 정리돼 있는 화면이었던 거죠. 그런 데이터를 굳이 제가 하나씩 다시 입력할 이유가 없었습니다. 필요한 건 화면을 잘 정리해서 넘기는 일, 그 화면을 새 포맷으로 변환해주는 일뿐이었습니다.

방법은 꽤 단순했습니다. 먼저 기존 앱의 월별 통계 화면을 캡처했습니다. 이걸 월별로 Migration 폴더에 정리해두고, Claude에게 각 루틴이 어떤 기준으로 체크되는지 설명했습니다. 예를 들어 어떤 기호가 체크 완료인지, 메모는 어떤 식으로 읽어야 하는지, 결과를 어떤 형식으로 정리하면 되는지 같은 규칙을 먼저 잡아준 거죠. 그다음엔 그 스크린샷을 읽고, 제가 쓰는 Obsidian 구조에 맞게 마이그레이션해달라고 요청했습니다.

코드를 잘 짜기보다 지시를 잘 내리기

이 과정이 재밌었던 이유는 코드를 짜는 느낌보다 작업자에게 지시를 잘 내려 문제를 해결한 느낌에 가까웠단 점입니다. 예전에는 이런 작업을 하려면 OCR을 붙이거나, 데이터를 긁어오거나, 포맷 파서를 따로 짜는 쪽으로 생각했을 겁니다.

그런데 이번에는 공학적으로 접근하기보다, 쉬운 방식으로 접근했습니다. 화면을 보여주고, 규칙을 설명하고, 결과를 검수하는 방식을 쓴 거죠. 어떻게 보면 개발이라기보다 작업 파이프라인을 설계한 셈입니다. 바이브 코딩이 재밌는 이유도 이런 데 있는 것 같습니다. 예전 같으면 “기술적으로 어떻게 풀지?”부터 고민했을 일을 지금은 “가장 덜 귀찮고 빨리 끝나는 방식이 뭘까?”로 접근하게 되니까요.

결과는 솔직히 기대 이상이었습니다. 몇 분 안에 대부분의 데이터가 정리됐고, 정확도도 꽤 높았습니다. 저는 중간에 날짜가 꼬이거나, 메모가 엉뚱한 곳에 붙거나, 체크 기준을 잘못 읽는 일이 많이 생길 줄 알았습니다. 그런데 물론 100% 완벽하다고 하긴 어렵지만, 체감상으로는 충분히 쓸만한 수준으로 데이터가 옮겨졌습니다. 무엇보다 이 정도면 손으로 다시 입력하는 것보다 압도적으로 낫다는 확신이 빨리 들었습니다. 이 확신이 굉장히 중요했습니다. 이번 마이그레이션 작업은 완벽함보다도, 내가 이 일을 끝까지 밀고 갈 수 있을지가 더 중요하니까요.

중간에 퍽 인상 깊은 일도 있었습니다. 제가 월별 데이터를 잘못 넣은 적이 있었는데, Claude가 그걸 읽다가 “이건 이전 달 데이터로 보인다”는 식으로 먼저 걸러낸 겁니다. 사람이 대충 넣은 걸 모델이 맥락으로 잡아내는 걸 보니 단순 추출을 넘어 꽤 실용적인 작업 보조라는 생각이 들었습니다. 보통은 제가 AI가 만든 결과물을 의심하면서 검수하는 그림을 생각하는데, 그 반대로 제가 대충 넘긴 걸 오히려 AI가 한 번 더 걸러준 거니까요.

결국 올해 제가 쌓아온 8개 루틴의 체크 데이터와 메모를 거의 다 옮길 수 있었습니다. 전체 작업 시간도 아주 길지 않았습니다. 솔직히 이 마이그레이션이 수작업이었으면, 아마 중간에 포기했을 가능성이 높습니다. 루틴 앱을 새로 만든 성취감과 데이터를 옮기는 지루함은 완전히 다른 문제니까요. 그런데 이번에는 귀찮고 반복적인 이전 작업을 꽤 현실적인 수준으로 줄일 수 있었고, 덕분에 “만든다”에서 끝나는 게 아니라 “갈아탄다”까지 갈 수 있었습니다.

생성형 AI를 반정형 데이터 마이그레이션에 쓰기

이번 경험으로 크게 느낀 게 하나 있습니다. 많이들 생성형 AI를 코드 작성 도구로 먼저 떠올리는데, 실제로는 이런 반정형 데이터 마이그레이션에서 더 큰 효율을 체감할 수도 있겠다는 점입니다.

이미 화면 형태로 정리된 정보, 사람이 보면 금방 이해할 수 있지만 손으로 옮기기 너무 귀찮은 정보, 규칙은 있지만 완전히 정형화돼 있지는 않은 정보들 말이죠. 이런 작업은 원래 애매하게 사람 시간을 많이 먹는 영역이었는데, 지금은 꽤 높은 수준으로 위임할 수 있게 된 것 같습니다.

마찬가지로 이번 마이그레이션은 단순히 데이터를 옮긴 작업을 넘어 제가 이 프로젝트를 진짜로 실사용 단계까지 밀고 갈 수 있게 만든 핵심 과정이었습니다. 새 도구를 만드는 건 재밌습니다. 하지만 기존 도구를 떠나는 건 완전히 다른 문제입니다. 적어도 이번 프로젝트에서 그 간극을 잡아준 건 스크린샷과 생성형 AI를 이용한 마이그레이션 방식이었습니다.

직접 유료 앱을 대체하고 얻은 결론

모든 작업이 끝나고, 기존에 쓰던 유료 루틴 앱의 구독을 해지했습니다. 물론 연 3만 원대 금액이 아주 부담이 큰 건 아니었습니다. 사실 그 정도면 잘 만든 서비스를 편하게 쓰는 비용으로 충분히 낼 수 있는 돈이죠. 그만큼 괜찮은 앱이라 처음엔 굳이 이걸 직접 만들어야 하나 싶은 마음도 있었습니다. 그런데 막상 만들어 며칠 써보니까 생각이 꽤 달라졌습니다. 단순히 돈을 아낀 것보다 이제야 진짜 제 방식에 맞는 도구를 가졌다는 만족감이 훨씬 컸거든요.

진짜 내 방식에 맞는 도구

제 입장에서 가장 큰 변화는 대시보드 활용입니다. 기존 서비스의 대시보드도 충분히 괜찮았지만, 어디까지나 그건 서비스가 정의한 방식으로 보여주는 정보였습니다. 반면 이번에는 제가 궁금한 흐름을, 제가 보고 싶은 방식으로 바로 볼 수 있었습니다. 어떤 루틴이 제 일상에서 더 중요한지, 이번 달에 루틴이 무너진 시점은 언제였는지, 연간 기준으로 보면 어떤 패턴이 반복되는지 같은 것들이 훨씬 더 직관적으로 보였습니다. 남이 잘 만들어준 도구를 쓰는 것과 내가 정말 보고 싶던 화면을 직접 구현한 도구를 쓰는 건 생각보다 차이가 컸습니다.

데이터를 제가 직접 관리하는 점도 만족스럽습니다. 이건 써보기 전에는 생각보다 덜 중요한 느낌인데, 막상 경험해보니 무시하기 어렵더라고요. 특정 서비스에 제 중요한 기록이 종속되지 않고, 제가 이해할 수 있는 구조로 쌓아, 필요하면 가공해 다시 읽고, Claude에게 질문까지 던질 수 있다는 점이 좋았습니다. 이 프로그램이 어느 순간부터는 기록 도구라기보다 생활 데이터 실험실 같은 느낌도 들기 시작했습니다.

작고, 빠르고, 바로 쓸 수 있는 실험

물론 모두에게 이 방식을 그대로 추천하긴 어렵습니다. 비개발자 입장에서는 여전히 진입장벽이 있습니다. Obsidian을 다룰 줄 알아야 하고, Git으로 동기화하는 흐름도 이해해야 하고, 중간에 꼬이면 직접 고쳐야 하니까요. 누군가에게는 그냥 월 구독료나 연 구독료를 내고 검증된 서비스를 계속 쓰는 편이 훨씬 합리적일 수 있습니다. 실제로도 그 선택이 더 맞는 사람은 많을 겁니다.

그런데 이런 게 익숙한 개발자라면 또 다릅니다. 저는 이런 개인용 도구 제작이 개발자에게 꽤 좋은 실험이라고 생각합니다. 작고, 빠르고, 바로 쓸 수 있기 때문입니다. 거창한 사이드 프로젝트는 시작부터 부담이 큽니다. 기획도 해야 하고, 화면도 만들어야 하고, 중간에 지치기도 쉽죠. 반면 개인용 도구는 문제 정의가 명확합니다. 내가 불편하면 시작하고, 내가 만족하면 끝입니다. 게다가 완성 후 바로 실사용으로 이어지기 때문에, 작은 개선이 곧바로 체감됩니다. 이게 생각보다 중독성이 있습니다.

낮아진 진입장벽만큼 중요한 것

이번 일을 하면서 저는 요즘 제품 개발의 진입장벽이 정말 많이 낮아졌다는 걸 다시 느꼈습니다. 적어도 대규모 서비스가 아니라면, 이제 개발할 수 있는지 없는지 여부는 예전만큼 큰 문제가 아닐 수도 있겠다는 생각이 들었습니다. 물론 여전히 잘 만드는 건 어렵고, 안정적으로 운영하는 건 더 어렵습니다. 하지만 적어도 작게 만들어서 직접 써보는 단계까지 가는 건 훨씬 쉬워졌습니다. 예전에는 아이디어가 있어도 머릿속에만 남아 있던 것들이, 지금은 꽤 높은 확률로 실제로 작동하는 무언가가 됩니다.

그래서 오히려 더 중요해진 건 개발 자체보다 무엇을 만들지, 왜 그걸 만들어야 하는지, 계속 쓰게 만들려면 어떤 구조여야 하는지 같은 문제인 것 같습니다. 만드는 건 점점 쉬워지고 있습니다. 대신 아무거나 만들면 안 되고, 진짜 내 문제를 해결해 줄 영역을 골라야 합니다.

그와 함께 이제 제품 영역의 진짜 싸움은 아이디어와 활용 방식, 더 나아가 마케팅 쪽으로 넘어가고 있다는 생각도 들었습니다. 개인용 도구는 내가 쓰면 그만이지만, 그걸 제품으로 만들고 누군가에게 쓰게 만드는 건 또 완전히 다른 문제니까요. 대규모 서비스가 아니면 개발 자체는 예전보다 훨씬 덜 위협적인 장애물이 됐습니다. 대신 이제는 “무엇을 왜 만들 것인가”가 훨씬 더 중요합니다.

마치며

이제 저는 전보다 가볍게 무언가 만들어 볼 생각을 합니다. 꼭 앱을 새로 출시하겠다는 거창한 목표가 아니어도 괜찮습니다. 내가 매일 반복하는 귀찮은 일, 기존 도구를 쓰면서 계속 아쉬웠던 부분, 내 방식대로 하고 싶었던 지점들. 그런 것들이 전부 작은 프로젝트의 출발점이 될 수 있겠다고 느낍니다. 바이브 코딩의 진짜 재미도 거기에 있는 것 같습니다.

이번에 유료 루틴 앱 하나를 대체해본 건, 어쩌면 아주 작은 사례일 뿐입니다. 그런데 저는 오히려 그래서 더 의미가 있다고 느꼈습니다. 세상을 바꿀 서비스를 만든 것도 아니고, 대단한 SaaS를 출시한 것도 아닙니다. 그냥 제가 매일 쓰는 도구 하나를 제 손에 맞게 다시 만든 것뿐이죠. 그런데 그것 하나만으로도, 지금 개발자에게 열린 가능성이 전보다 훨씬 많다는 걸 분명히 느낄 수 있었으니까요.

]]>

로컬 LLM, 나를 위한 작은 AI 작업대 만들기

ChatGPT, Claude, Gemini 같은 클라우드 AI 도구는 이미 개발자들 작업 방식 안에 들어와 있습니다. 코드 예시를 물어보고, 에러 메시지를 해석하고, 문서나 학습 자료를 정리하는 일도 이제 별로 특별하지 않죠. 그런데 모든 작업을 클라우드 AI에 던지는 게 늘 편한 건 아닙니다. 비용도 들고, 사용량 제한도 있습니다. 인터넷 연결이 필요하다는 점도 은근히 걸립니다. 개인 프로젝트 로그나 메모를 외부 서비스에 그대로 넣는 것도 상황에 따라 찝찝하고요.

예전에는 로컬에서 LLM을 돌린다는 말만 들어도 피곤했습니다. 모델 파일부터 실행 환경, GPU 설정까지 줄줄이 떠올랐으니까요. 요즘은 그 장벽이 많이 낮아졌습니다. Ollama 같은 도구를 쓰면 명령어 몇 줄로 모델을 내려받고 바로 실행합니다.

이쯤 되면 로컬 LLM을 다시 보게 됩니다. ChatGPT를 대체하는 무언가라기보다는, 개인 개발자가 자기 작업 흐름 옆에 붙여두는 작은 AI 작업대에 가깝습니다. 이번 글에서는 로컬 LLM을 어디에 쓰면 괜찮고, 어디서부터는 기대를 접어야 하는지 그 기준을 잡아보려고 합니다.

미리 요점만 콕 집어보면?

로컬 LLM은 ChatGPT, Claude, Gemini를 대신할 만능 도구가 아닙니다. 그 기대를 갖고 시작하면 꽤 빨리 실망합니다.
쓸 곳을 잘 고르면 의외로 편합니다. 코드 한 덩어리 설명하기, README 문장 다듬기, 로그 요약하기, 커밋 메시지 후보 뽑기처럼 사람이 바로 확인하는 작업에서는 충분히 쓸 만합니다.
그러니까 이 글에서 말하는 로컬 LLM은 무료 GPT라기보다, 내 컴퓨터 안에 올려두는 작은 작업대에 더 가깝습니다.

로컬 LLM 설치는 이미 너무 쉬워졌다

로컬 LLM을 처음 생각하면 설정부터 막막해 보입니다. 모델은 어디서 받고, 실행은 뭘로 하고, 그래픽카드 설정은 어떻게 맞춰야 하는지부터 떠오릅니다. 이때 Ollama를 쓰면 첫 단계가 꽤 짧아집니다.

“ollama run qwen3”

이 명령 하나로 Qwen 계열 모델을 내려받아 대화형으로 실행합니다. 다른 모델도 방식은 비슷합니다. 모델 이름만 바꾸면 됩니다. 다운로드와 실행은 Ollama가 맡습니다.

<출처: 작가>

여기까지는 정말 쉬워졌습니다. 문제는 그다음입니다. 모델이 돌아간다고 해서 바로 쾌적한 건 아닙니다. 작은 모델은 빠르지만 복잡한 질문에서 금방 흔들립니다. 큰 모델은 답변 품질이 낫지만, 내 컴퓨터에서는 느리거나 아예 제대로 안 돌기도 합니다. 설치 난이도와 써본 느낌은 다른 문제입니다.

처음부터 유명한 모델, 큰 모델을 고르는 식으로 접근하면 삽질하기 쉽습니다. 나한테 필요한 건 가장 센 모델이 아니라, 내 컴퓨터에서 돌아가고 내가 맡길 작업을 버틸 정도의 모델입니다.

이때 볼만한 오픈소스가 ‘whicllm’입니다.

https://github.com/Andyyyy64/whichllm

whichllm은 내 컴퓨터 사양에서 실제로 돌릴 만한 로컬 LLM을 추천해 주는 CLI 도구인데요. VRAM만 보고 끝내지 않습니다. Hugging Face 모델 정보, 벤치마크, 최신성, 속도 같은 요소를 섞어 모델을 랭킹합니다. “내 노트북에서는 뭘 돌려야 하지?”라는 질문에 꽤 현실적으로 답합니다.

<출처: 작가>

그러나 로컬 LLM은 무료 GPT가 아닙니다. 이걸 인정하고 시작하는 게 편합니다. 큰 판단은 여전히 대형 모델 쪽이 낫고, 로컬 LLM은 작고 반복적인 일을 옆에서 처리하는 보조 작업자에 더 잘 맞습니다.

로컬 LLM을 붙여볼 작업은 '틀려도 바로 검증 가능한 일'

로컬 LLM을 어디에 붙일지는 “얼마나 똑똑한가”보다 “틀렸을 때 얼마나 빨리 잡히나”로 보는 게 낫습니다. 결과를 사람이 바로 확인하는 작업이면 부담이 작습니다. 틀리면 고치면 됩니다. 마음에 안 들면 버리면 됩니다. 틀렸을 때 피해가 커지는 작업은 아직 조심해야 합니다. 복잡한 개발 판단, 큰 설계, 긴 코드베이스 이해 같은 작업은 로컬 LLM에 바로 맡기기 어렵습니다. ChatGPT나 Claude 같은 대형 모델도 조심해서 써야 하는 영역이라, 작은 로컬 모델에 던지면 더 쉽게 흔들립니다.

출발점은 작은 작업입니다. 문서 한 문단, 함수 하나, 로그 한 덩어리 정도의 크기에서 로컬 LLM은 꽤 쓸모가 있습니다.

문서와 글쓰기 보조

그래서 가장 만만한 일이 바로 문서와 글쓰기입니다. README 문장을 조금 다듬거나, 글 제목 후보를 뽑거나, 커밋 메시지 후보를 만드는 일은 로컬 LLM에 잘 맞습니다. 틀려도 치명적이지 않고, 사람이 바로 판단할 수 있습니다.

완성된 글을 한 번에 뽑게 하는 건 별로입니다. 차라리 후보를 여러 개 던지게 한 뒤, 사람이 그중 쓸 만한 방향을 고르는 편이 낫습니다.

예를 들어, 이렇게 물어보는 거죠.

“로컬 LLM을 개인 개발자가 활용하는 글을 쓰려고 해. 제목 후보 5개만 만들어줘.”

제가 Qwen으로 받은 결과는 이런 식입니다.

1. 내 노트북에 들이는 작은 AI 동료, 로컬 LLM 시작하기
클라우드 없이도 충분하다 - 로컬 LLM 실전 활용기
무료 GPT가 아니라 개인용 작업대로 쓰는 로컬 LLM
Ollama로 시작하는 나만의 로컬 AI 환경
로컬 LLM, 어디까지 맡길 수 있을까

그대로 가져다 쓸 만한 제목은 많지 않습니다. 그래도 3번처럼 방향을 잡아주는 후보가 하나 나오면 충분합니다. 로컬 LLM한테 기대할 건 완성본보다 출발점에 가깝습니다.

Gemma나 Qwen 같은 모델은 짧은 글쓰기, 문장 정리, 요약에서는 생각보다 괜찮습니다. 물론 문체가 뻣뻣하거나 설명이 흐려질 때도 있지만, 사람이 바로 고치는 작업이라면 그 정도는 감수할 만합니다.

<출처: 작가>

코드 이해 보조

코드에서는 범위를 좁히는 게 거의 전부입니다. 프로젝트 전체를 분석해달라고 하면 금방 애매해집니다. 함수 하나, 파일 하나, 에러 로그 한 덩어리처럼 입력을 작게 자르면 훨씬 쓸 만해집니다.

처음 보는 TypeScript 함수가 있을 때는 이렇게 물어봅니다.

“아래 TypeScript 함수가 어떤 역할을 하는지 설명해줘. 입력, 처리 과정, 반환 값으로 나눠서 정리해줘.”

로그도 비슷합니다. 긴 빌드 로그나 테스트 실패 로그를 다 읽기 전에 원인 후보만 추려보게 합니다.

“다음 로그에서 실제 에러 원인으로 보이는 부분만 요약해줘. 추측은 따로 구분해서 적어줘.”

이런 요청은 입력 범위가 좁고, 사람이 원본과 바로 대조할 수 있습니다. 틀려도 잡기 쉽습니다. 여러 모듈에 걸친 리팩터링 방향을 정하게 하거나 프로젝트 전체 구조를 이해시키는 일은 아직 어렵습니다. 문맥이 길어질수록 중요한 정보를 놓치고, 실제 코드 흐름과 맞지 않는 설명도 쉽게 나옵니다.

로컬 LLM에 코드를 맡길 때는 “이 프로젝트를 분석해줘”보다 “이 함수가 무슨 역할인지 설명해줘”가 낫습니다. “이 로그에서 실패 원인을 요약해줘” 정도가 훨씬 현실적입니다.

로컬 에이전트와 자동화

로컬 LLM은 대화창에만 묶어둘 필요가 없습니다. 다른 개발 도구나 자동화 도구와 연결하면 작은 로컬 AI 흐름으로 만들 수 있습니다.

OpenClaw나 OpenCode처럼 Ollama와 연동되는 도구를 쓰면 로컬 모델을 코딩 보조 흐름에 붙입니다. 클라우드 모델을 쓰기에는 아까운 간단한 코드 설명, 파일 요약, 반복 텍스트 변환 같은 일을 로컬 모델에 넘기는 식입니다.

n8n 같은 자동화 도구와 Ollama를 연결하면 쓸 곳이 조금 더 넓어집니다. 폴더에 쌓이는 로그 파일을 요약하거나, 메모 앱에 쌓인 내용을 일정한 형식으로 정리하거나, 반복적으로 들어오는 텍스트를 분류하는 흐름을 만들기 좋습니다.

여기서도 선은 분명합니다. “AI가 알아서 프로젝트를 개선한다” 같은 쪽으로 가면 위험합니다. “오늘 생성된 로그를 5줄로 요약해줘”, “새 메모를 주제별로 나눠줘”, “커밋 메시지 후보 3개 만들어줘”처럼 결과가 작고 확인 가능한 요청이 훨씬 안전합니다. 로컬 LLM 자동화의 장점은 대단한 지능이 아닙니다. 내 컴퓨터 안에서 내가 정한 방식으로 반복 작업을 계속 돌릴 수 있다는 점입니다.

아직 ChatGPT 같은 대형 모델의 대체재는 아니다

여기서 기대치를 한 번 낮춰야 합니다. 로컬 LLM은 매력적입니다. 하지만 ChatGPT나 Claude를 완전히 대체하긴 어렵습니다.

가장 큰 차이는 문맥과 판단입니다. 긴 코드베이스를 읽고, 요구사항을 정리하고, 여러 선택지를 비교해서 설계 방향을 잡는 일은 여전히 대형 클라우드 모델이 강합니다. 개발에서는 코드를 몇 줄 생성하는 능력보다 맥락을 버티는 능력이 더 중요할 때가 많습니다. 하드웨어 제약도 피하기 어렵습니다. 모델 크기와 응답 속도는 CPU, RAM, GPU, VRAM에 따라 달라집니다. 좋은 장비에서는 더 큰 모델이 돌아가지만, 사양이 낮은 노트북에서는 작은 모델이 현실적입니다.

성능이 낮은 모델일수록 환각도 더 거슬립니다. 없는 명령어를 말하거나 코드 동작을 잘못 설명하거나 로그 원인을 과하게 찍기도 합니다. 로컬 LLM의 답은 항상 확인해야 하고, 코드 수정이나 보안, 데이터 처리, 배포 쪽에서는 특히 그렇습니다.

로컬 실행이 곧 완전한 보안이라는 뜻도 아닙니다. 클라우드로 데이터를 보내지 않는다는 장점은 있지만, 도구가 대화 기록이나 캐시를 어디에 저장하는지는 봐야 합니다. 다른 도구와 엮으면 데이터가 생각하지 못한 위치에 남기도 합니다. 로컬 LLM은 모든 일을 대신 해주는 완전 무료 AI가 아닙니다. 내가 통제하는 범위 안에서 작은 작업을 처리하는 개인용 보조 도구입니다.

마치며

개인 개발자에게 로컬 LLM은 꽤 괜찮은 도구입니다. ChatGPT나 Claude를 대체하긴 어렵지만, 내 환경 안에서 작은 작업을 처리하는 용도로는 충분히 쓸모가 있습니다. 처음부터 거창하게 시작할 필요는 없습니다. README 문장 다듬기, 에러 로그 요약, 커밋 메시지 후보 만들기 정도면 됩니다. 결과를 바로 확인하는 일부터 붙여보는 게 좋습니다.

로컬 LLM의 가치는 최고 성능이 아닙니다. 내 컴퓨터 안에서 내가 통제하는 방식으로 반복 작업을 처리하고, 내 흐름에 맞게 실험할 수 있다는 데 더 가깝습니다. 한 번쯤 가볍게 찍먹해볼 만합니다. 단순한 장난감으로 끝날 때도 있겠지만, 맞는 일을 찾으면 약간 미숙해도 꽤 안전한 도우미가 됩니다. ChatGPT 흉내를 기대하면 실망할 수 있으니, 나만의 작은 작업대 하나를 만든다고 생각해 보면 어떨까요?

]]>