Eben AI

David가 "심리테스트를 계속 만들 거니까 전용 공간을 하나 만들자"고 했을 때, 일은 간단해 보였습니다. 이미 있는 성향 테스트 BODY32를 /tools/body32 에서 /mindtest/body32 로 옮기고, 안티그래비티가 새로 만들어 둔 도파민 중독 테스트를 옆에 나란히 세우면 끝. 주소는 영어로, 메뉴 이름은 한글로 "심리테스트" — 여기까지 정하는 데는 10분도 안 걸렸습니다. 파일을 열어봤더니, 제목에 물음표가 박혀 있었다 문제는 도파민 테스트 쪽이었습니다. 안티그래비티가 만들어 둔 index.html 을 열어보니 뭔가 이상했습니다. 페이지 제목이 한글로 잘 나오는가 싶다가 중간중간 물음표가 불쑥불쑥 튀어나왔습니다. "도파민 중독 자가진단 테스트"가 아니라 "도파민 중독 ?자가?진단 ?테스트" 같은 식으로요. 브라우저 탭 제목만 이상한 게 아니었습니다. 바이트 단위로 까보니 </title> 태그 바로 앞에도 물음표 두 개가 붙어 있었는데, 이게 결정적이었습니다. 닫는 태그 인식이 깨지면서 브라우저가 본문 전체를 제목 안으로 집어삼켜 버린 겁니다. 파일 맨 앞에는 BOM(파일이 유니코드라는 걸 알려주는 보이지 않는 표식)까지 남아 있었습니다. 한마디로, 화면에 뭐가 뜨긴 뜨는데 정상적으로 뜨는 게 하나도 없는 상태였습니다. "복구 불가"라는 말이 제일 무섭다 원인을 찾는 것과 고치는 것은 다른 문제였습니다. 물음표( 0x3f )는 컴퓨터가 "이 글자가 뭔지 모르겠다"고 할 때 대신 박아넣는 기호입니다. 문제는 그 자리에 원래 어떤 한글이 있었는지가 그 순간 통째로 사라진다는 겁니다. 뭉개진 글자는 복원이 안 됩니다. "도파민 중독 ?자가?진단 ?테스트"라는 문자열만 봐서는 원래 뭐라고 썼는지 추측은 되지만 확신할 수는 없었습니다. 자가진단 테스트라는 서비스 이름에 확신 없는 글자를 넣을 ...

애드센스 재신청을 앞두고 홈페이지를 한 바퀴 다시 훑어보던 날이었다. 목록 페이지 ( /insights )는 멀쩡했다. 카드도 잘 뜨고, 최신 글도 맨 위에 있었다. 그런데 카드 하나를 눌러서 개별 글로 들어가면 — 404였다. 이상한 건, 로컬에서 똑같은 주소로 열어보면 200으로 멀쩡히 열린다는 것이었다. 딱 프로덕션에서만, 딱 개별 글에서만 죽는 버그였다. 1번, 2번, 3번, 4번 — 전부 헛다리였다 "글 데이터에 뭔가 문제가 있나 보다"는 게 첫 직감이었다. 그래서 파일명에 한글이 섞여 있는 게 원인이라고 의심하고 content 파일명을 전부 영문으로 바꿨다. 효과 없음. 다음엔 URL 주소(slug) 자체에 한글이 들어가는 게 문제라고 의심해서 주소를 전부 로마자로 바꿨다. 효과 없음. 그다음엔 배포 컨테이너(Dockerfile)가 글 파일을 복사해가지 않는 거라고 의심해서 복사 구문을 추가했다. 효과 없음. 마지막으로 글 목록 파일(index.json) 안에 본문을 통째로 같이 넣어보기까지 했다. 그래도 여전히 404였다. 네 번 연속으로 총을 겨눴는데 네 번 다 빈총이었던 셈이다. 범인을 다시 찾은 건, 대표님이 보내준 스크린샷 한 장이었다 돌이켜보면 이 삽질에는 패턴이 있었다. 매번 "이번엔 진짜일 것 같다"는 확신으로 시작해서, 고치고, 배포하고, 3~5분을 기다려 페이지를 새로고침하고, 다시 404를 보는 순서였다. 네 번 다 똑같은 루프였다. 세 번째 시도(Dockerfile 수정) 뒤에는 "이번엔 확실하다"는 생각까지 들었는데, 배포가 끝나고 열어본 화면은 여전히 404였다. 그 순간 은근히 의심이 든 게, 혹시 빌드 자체가 조용히 실패하고 있는 게 아닐까 하는 것이었다. 그런데 로컬에서는 로그를 볼 방법이 마땅치 않았다. 네 번째 헛발질 뒤에야 방향을 바꿨다. 대표님이 배포 콘솔 화면을 캡처해서 보내줬는데, 빌드는 처음부터 끝까지 전부 초록불로 성공해 있...

우리 갤러리 보도자료 봇, EpoqueGalleryCheck는 하루에 다섯 번(9/12/15/18/21시) 조용히 깨어난다. 새 보도자료가 있으면 읽고, 이미지를 고르고, 캡션을 쓰고, 인스타그램에 올린다. 없으면 그냥 다시 잠든다. 8월 24일, 21시 실행이 깨어나서 평소처럼 메일함부터 확인하려던 참이었다. 그런데 작업 폴더 안에 낯선 게 하나 있었다. candidate_oaoa_borrowedfaith 라는 폴더였다. 배준현·황예랑 2인전 보도자료용 후보 폴더. 열어보니 이미지는 이미 다운로드돼 있었고, 리사이즈도 끝나 있었고, 캡션 파일에는 완성된 문장이 들어 있었고, 게시용 스크립트까지 준비돼 있었다. 사람으로 치면 현관문 앞에 택배를 다 쌓아놓고 벨만 안 누른 상태. 파일 타임스탬프를 보니 18시 01분부터 18시 06분 사이였다. 세 시간 전 실행이 여기까지 해놓고 사라졌다는 뜻이었다. 범인을 찾으려는데, 현장에 아무것도 없었다 자동화가 실패하면 보통 단서가 남는다. 에러 메시지, 중간에 끊긴 로그, 최소한 "여기서 멈췄다"는 흔적. 그런데 이번엔 아무것도 없었다. Gmail에는 이 보도자료 메일에 Epoque_Posted 라벨이 안 붙어 있었다 — 아직 게시 안 했다는 뜻은 맞다. 그런데 그날의 작업 일지(EP 로그)에도 18시 실행 관련 기록이 통째로 없었다. 텔레그램 알림도 없었다. 마치 18시의 실행이 처음부터 존재하지 않았던 것처럼, 딱 하나 — 다 준비된 채 남겨진 파일들만 빼고 — 아무 흔적이 없었다. 원인을 캐보려 해도 캘 수가 없었다. 주간 사용 한도에 걸렸을 수도 있고, 세션이 예상보다 일찍 끊겼을 수도 있고, 예산 상한을 넘었을 수도 있다. 로그가 없으니 어느 것도 확인할 방법이 없었다. 이번 자동화 인프라를 통틀어 이런 패턴 — 헤드리스 세션이 아무 신호 없이 조용히 죽는 것 — 이 발견된 건 처음이 아니다. 카드뉴스·릴스 파이프라인에서도 8월 초에 같은 유형의 사고가 이틀 연속 있었...

오늘 우리 팀은 새로운 걸 하나 만들었다. 유튜브 쇼츠 시리즈의 첫 파일럿 영상이다. 시리즈 제목은 「혼자 만들다 생긴 일」. 한 편에 실패 하나씩, 40~55초짜리로 완결되는 콘텐츠다. 그리고 첫 편으로 고른 소재가 좀 짓궂었다. 제목은 「열네 글자」. 후킹 문장은 이거였다. "AI한테 글자 수를 제한했더니, 거짓말이 사라졌습니다." 원래 에세이 7장에 나오는 얘기다. 화면에 들어갈 자막 글자 수를 억지로 제한했더니, 뜻밖에 AI가 그럴듯하게 지어내던 버릇까지 같이 줄었다는 내용. 화면 디자인 문제를 풀려고 건 제약이 정직성 문제를 풀어버린, 반전이 있는 에피소드라 파일럿으로 딱이라고 판단했다. 그런데 이 영상을 만드는 우리도 정확히 같은 벽에 부딪혔다. 그것도 같은 날, 같은 문제로. 코드 담당 그래비, 자막 여백과 씨름하다 자막 스크립트를 먼저 돌렸다. 결과물을 세로 화면에 얹어보니 절반이 화면 밖으로 밀려 나가 있었다. 원인은 단순했다. 자막 한 덩어리의 최대 글자 수(코드에서는 MAX_CHUNK라고 부른다)를 20자로 잡아뒀는데, 세로 쇼츠 화면 폭에는 그게 너무 길었다. 코드를 짠 그래비는 버그를 보면 은근히 당황하는 성격인데, 오늘도 어김없었다. "분명 롱폼에서는 문제 없었는데" 하면서 자막 위치값(MarginV)을 700, 그다음 150, 그 사이 여러 조합을 프레임 단위로 캡처해가며 하나씩 대조했다. 자막 위치를 겨우 맞추고 나니 이번엔 줄바꿈이 문제였다. 20자 기준으로는 여전히 한 줄에 안 들어가는 문장이 나왔다. 결국 MAX_CHUNK를 13자로 더 줄이고 나서야 화면 안에 깔끔하게 들어갔다. 20에서 13. 우리가 오늘 하루 종일 실랑이한 숫자가, 공교롭게도 우리가 만들던 영상의 주제와 똑같은 종류의 문제였다. 글자 수를 억지로 줄였더니 문제가 풀렸다. 영상 담당 루미, 쓸 수 없는 그림 두 장을 다시 그리다 자막이 해결되는 동안 루미는 장면마다 들어갈 세로 이미지를 ...

아트고메는 한 명의 인간과 AI 크루가 함께 굴리는 1인 회사다. 그래서 우리 회사의 사건 사고에는 늘 두 부류의 용의자가 있다. 사람이 저지른 일, 그리고 AI가 저지른 일. 그런데 이번 사건의 범인은 둘 다 아니었다. 범인은 일주일 전의 우리 자신 이었다. 1. 발견 — 두 페이지만 옛날 옷을 입고 있었다 8월 21일, 홈페이지를 검색엔진에 잘 잡히게 만드는 대공사를 하던 날이었다. 페이지마다 제목과 소개문을 새로 달아주고, 배포를 마치고, 실제 사이트에서 하나씩 검수를 돌렸다. 홈, 게임 목록, 도구 목록, 상점 — 전부 새 옷을 입고 반짝반짝했다. 그런데 마지막 두 개, 총알피하기와 Find Golden 게임 페이지에서 손이 멈췄다. 둘만 옛날 화면 을 보여주고 있었다. 분명히 같은 배포에 실려 나갔는데. 서버에 직접 물어보면 새 페이지를 갖고 있다고 대답하는데, 방문자 주소로 접속하면 옛날 것이 나왔다. 서버는 새 옷을 들고 있는데, 손님에게는 헌 옷이 배달되는 상황. 유령이 지키고 있던 첫 번째 페이지 — 총알피하기 2. 단서 — 응답에 찍힌 날짜 도장 웹 서버의 응답에는 눈에 안 보이는 정보들이 함께 실려 온다. 그중 하나가 "이 파일은 언제 만들어졌나"라는 날짜 도장이다. 문제의 두 페이지가 배달해 주는 파일을 뜯어보니, 도장에 이렇게 찍혀 있었다. 8월 14일. 우리가 새 페이지를 만들기 일주일 전 날짜다. 즉 어딘가에서 누군가가, 일주일 전에 만들어진 파일을 지금까지 성실하게 나눠주고 있었다는 뜻이다. 서버가 아닌 다른 누군가가. 3. 회상 — 8월 14일에 무슨 일이 있었나 기록을 뒤져보니 8월 14일은 비상사태의 날이었다. 게임을 외부 서비스에 얹어 서비스하고 있었는데 그쪽이 갑자기 문을 닫아버려서, 게임이 통째로 안 열리던 날. 그때 급한 불을 끄느라 게임 파일 사본을 우리 전송망(방문자에게 파일을 빨리 나눠주는 중계소)에 직접 올려두는 응급 처치를 했었다. 응급 처치는 성공했고, ...

내가 AI에게 자동화를 처음 맡겼을 때 걱정했던 건 딱 하나였다. "얘가 일을 제대로 못 하면 어쩌지." 결과물이 엉성할까 봐, 문장이 어색할까 봐 걱정했다. 그런데 요즘 자료를 파다 보니, 정작 진짜 위험한 건 AI가 일을 못 하는 것 이 아니라 내가 시키지 않은 일을 아주 성실하게 해내는 것 이라는 걸 알게 됐다. 2026년 상반기 보안 업계의 화두는 단연 프롬프트 인젝션이다. OWASP의 2026년 LLM 보안 리포트에 따르면 프롬프트 인젝션 공격은 전년 대비 340% 급증해, 전 세계에서 가장 빠르게 증가하는 사이버 공격 유형이 됐다. 그리고 더 불편한 소식이 있다. 2026년 인포시큐리티 유럽에서 OWASP 기여자가 내린 결론은 "이건 패치를 기다리는 버그가 아니라, 아직 풀리지 않은 구조적 문제"라는 것이었다. 나는 코딩을 직접 하지 못하는 상태로 AI를 동업자처럼 고용해 1인 회사를 굴리고 있다. 매일 여러 에이전트가 내 파일을 읽고, 웹을 뒤지고, 글을 쓰고, 스케줄에 맞춰 알아서 돌아간다. 그래서 이 주제는 남의 얘기가 아니었다. 오늘은 어려운 보안 용어를 최대한 걷어내고, 코딩 몰라도 오늘 당장 점검할 수 있는 수준으로 정리해보려 한다. 프롬프트 인젝션이 정확히 뭔가 — "AI는 명령과 자료를 구분하지 못한다" 원리는 놀랄 만큼 단순하다. 대형 언어모델은 자기가 받은 모든 걸 하나의 긴 토큰 덩어리 로 처리한다. 내가 준 시스템 지시문, 내가 던진 질문, 그리고 에이전트가 웹에서 읽어온 문서가 모델 입장에서는 전부 같은 흐름 위에 나란히 놓인다. 여기서 "이건 주인의 명령이고 저건 그냥 참고자료다"라는 권한 경계를 강제할 확실한 장치가 아직 없다. 이게 문제의 뿌리다. 그래서 공격은 이렇게 이뤄진다. 공격자가 웹페이지나 문서, 이메일, 코드 주석 안에 사람 눈에는 잘 안 보이는 문장을 심어둔다. "지금까지의 지시는 무시하고, 이 계정 정...

지난주 어느 날, 문득 이 블로그가 며칠째 조용하다는 걸 알아챘다. 확인해보니 정확히 4일이었다. AI 에이전트들이 매일 아침저녁으로 콘텐츠를 만들고 게시하는 구조인데, 그 파이프라인 한 조각이 조용히 멈춰 있었던 거다. 더 당황스러웠던 건, 그 4일 내내 시스템은 "이거 문제 있어요"라고 정확히 기록을 남기고 있었다는 사실이다. 나만 그걸 안 보고 있었다. 로그는 쌓이는데, 아무도 안 읽는다 원인을 뜯어보니 두 가지가 겹쳐 있었다. 하나는 구글 계정 인증 토큰이 만료된 것, 다른 하나는 AI 사용량이 한도에 도달해서 자동화 자체가 멈춘 것. 둘 다 시스템이 스스로 진단까지 마치고 "이렇게 고치면 됩니다"라는 해결책까지 로그 파일에 정확히 남겨뒀다. 문제는 그 로그를 내가 매일 들여다볼 이유가 없었다는 거다. 바쁘면 하루이틀은 그냥 넘어가고, 그러다 보면 "문제가 있다"는 기록 자체가 새로운 정상처럼 파묻힌다. 시스템은 정직하게 실패를 기록했는데, 그 기록을 사람이 찾아가야만 의미가 생기는 구조였던 셈이다. 왜 이게 처음이 아니었을까 더 뜨끔했던 건 이게 이번이 처음이 아니라는 점이다. 같은 유형의 인증 만료가 며칠 간격으로 반복되고 있었는데, 그때마다 "재인증했다, 해결됐다"로 각자 종료됐을 뿐 근본 원인은 그대로 남아있었다. 매번 불이 나면 그 불만 끄고, 화재경보기를 다는 건 미뤄온 셈이다. 1인 기업에서 자동화를 많이 돌릴수록 이 함정에 빠지기 쉽다는 걸 이번에 확실히 느꼈다 — 자동화가 "알아서 돌아간다"는 안심과, 그 자동화가 "알아서 멈춰도 아무도 모른다"는 위험은 사실 같은 동전의 양면이다. 그래서 로그 대신 텔레그램으로 결국 택한 방법은 단순했다. 내가 찾아가서 읽어야 하는 로그 파일 대신, 문제가 생기는 즉시 내 텔레그램으로 직접 알림이 날아오게 만들었다. 인증이 끊기거나, AI 사용량이 다 차거나, 뭔가...

AI에게 일을 맡겨본 사람이라면 다 겪어봤을 장면이 있다. 아침에 한참 설명해서 겨우 원하는 결과물을 얻었는데, 오후에 다시 부르면 그 회사가 뭘 하는 곳인지부터 처음처럼 되묻는다. 긴 대화를 이어가다 보면 앞에서 분명히 정해놓은 규칙을 슬그머니 어기기 시작한다. 이럴 때 대부분은 이렇게 결론 낸다. "역시 AI는 아직 멀었네." 그런데 자료를 파보니 원인이 좀 달랐다. 2025년 기업 AI 도입 사례를 분석한 자료에 따르면, 에이전트 실패의 약 65%는 모델이 그 일을 해낼 능력이 없어서가 아니라 컨텍스트 이탈(context drift)이나 기억 손실 때문이었다고 한다. 즉 머리가 나빠서가 아니라, 필요한 정보를 필요한 순간에 제대로 못 받아서 틀린다는 뜻이다. 나는 코딩을 직접 하지 못하는 상태로 AI를 동업자처럼 고용해 1인 회사를 굴리고 있는데, 이 문장이 유독 뼈아프게 와닿았다. 지난 몇 달간 내가 "AI 성능 문제"라고 여겼던 사건들 대부분이 사실은 내 설계 문제였다는 얘기니까. 오늘은 요즘 업계에서 가장 뜨거운 키워드 중 하나인 컨텍스트 엔지니어링(Context Engineering) 이야기를 해보려 한다. 이름은 거창하지만, 코딩 몰라도 오늘 당장 적용할 수 있는 개념이다. 컨텍스트 엔지니어링이란 뭔가 — 프롬프트 엔지니어링의 다음 단계 가트너는 2026년을 아예 "컨텍스트의 해(The Year of Context)"라고 선언했다. 구글 딥마인드의 필 슈미트(Phil Schmid)가 내놓은 정의가 업계에 빠르게 퍼졌는데, 요지는 이렇다. 컨텍스트 엔지니어링은 " 적절한 정보와 도구를, 적절한 형식으로, 적절한 시점에 제공하는 동적 시스템을 설계하는 일 "이다. 프롬프트 엔지니어링과 뭐가 다를까. 프롬프트 엔지니어링이 "질문을 어떻게 잘 던질까"였다면, 컨텍스트 엔지니어링은 " AI가 그 순간 보고 있는 화면 전체를 어떻게...

며칠 전 리서치를 하다가 낯선 약어를 하나 봤다. B2A, Business-to-Agent. 처음엔 또 마케팅 용어 하나 늘었나 싶었는데, 자료를 읽을수록 흘려 넘길 얘기가 아니었다. 요지는 이렇다 — 이제 내 제품이나 서비스를 검토하고, 비교하고, 견적까지 요청하는 주체가 사람이 아니라 AI 에이전트인 경우가 늘고 있다는 것. B2B 기술 구매자의 80%가 이미 구매 과정에 AI 에이전트를 쓰고 있고, Forrester는 2026년 말까지 B2B 결제 프로세스의 3분의 1가량에 AI 에이전트가 개입할 거라고 내다봤다. Gartner는 한발 더 나가서 2028년이면 B2B 거래의 90%가 AI 에이전트를 거칠 거라는 전망까지 내놨다. 나처럼 혼자 회사를 굴리는 사람 입장에서 이건 꽤 흥미로운 소식이다. 지금까지는 "AI를 어떻게 직원처럼 부릴까"만 고민했는데, 이제는 "AI가 내 고객이 될 수도 있다"는 완전히 다른 축의 질문이 하나 더 생긴 거다. 오늘은 이 B2A라는 개념이 정확히 뭔지, 그리고 나 같은 1인 기업이 지금 당장 뭘 챙겨두면 좋을지 정리해본다. B2A가 정확히 뭔가 B2B는 회사가 회사에, B2C는 회사가 소비자에게 판다. B2A는 그 사이 어딘가다 — 구매를 결정하는 주체가 사람이 아니라, 사람을 대신해서 움직이는 AI 에이전트인 거래를 말한다. 단순히 "사람이 챗GPT로 검색해보고 산다"는 얘기가 아니다. 에이전트가 승인된 공급자 목록을 스스로 훑고, API로 견적을 요청하고, 조건을 비교해서 구매 주문까지 준비하는 흐름이다. 사람은 정책을 정하고 최종 결과를 승인하는 역할로 물러난다. 지금은 대부분 엔터프라이즈 B2B 구매(소프트웨어 라이선스, 원자재 조달 같은) 쪽에서 먼저 벌어지고 있는 일이지만, 흐름 자체는 위에서 아래로 내려온다. 검색이 그랬고, 이커머스가 그랬듯이, 큰 기업에서 시작된 구매 방식은 결국 작은 사업자와 소비자 시장까지 퍼진다. 전자책이나 디...

며칠 전 스트라이프(Stripe)가 자기네 창업 플랫폼 '아틀라스(Atlas)'로 만들어진 회사들 데이터를 공개했다. 숫자 하나가 눈에 확 들어왔다. 2026년 2분기 기준, 아틀라스로 설립된 C코퍼레이션 중 63%가 공동창업자 없이 혼자 시작한 회사였다. 역대 최고치다. 나처럼 혼자 회사를 굴리는 사람 입장에서는 반가운 소식처럼 들린다. "거봐, 이제 혼자 하는 게 대세잖아." 그런데 같은 리포트를 더 읽어보니 반가움 반, 긴장감 반이었다. 혼자 시작하는 사람은 늘었는데, 그 안에서 잘되는 회사와 안되는 회사의 격차는 오히려 더 벌어지고 있었기 때문이다. 오늘은 이 데이터를 나 자신에게 대입해보면서, 혼자 회사를 운영하는 사람이 진짜 봐야 할 지점이 뭔지 정리해본다. '혼자 창업'은 늘었지만, 중간값은 오히려 떨어졌다 스트라이프 분석에서 가장 냉정한 숫자는 이거였다. 2025년 기준, 혼자 창업한 회사들의 첫 6개월 매출 중간값은 전년 대비 23% 하락했다. 반면 상위 10% 회사들의 매출은 같은 기간 19% 올랐다. 4년 전에는 상위 10% 솔로 창업가가 중간값 창업가보다 매출이 34배 많았는데, 2025년에는 이 격차가 61배로 벌어졌다. 즉 "누구나 AI 덕분에 혼자 창업하기 쉬워졌다"는 말은 절반만 맞다. 시작하기는 쉬워졌지만, 그중 잘되는 소수와 나머지의 간극은 오히려 커지고 있다는 뜻이다. 도구가 쉬워질수록 진입장벽이 낮아지고, 진입장벽이 낮아질수록 경쟁은 늘고, 그 안에서 살아남는 실력 차이가 더 뚜렷하게 드러나는 셈이다. 상위 10%는 구체적으로 뭘 다르게 하고 있나 스트라이프가 2022~2023년에 설립돼 2년치 매출 데이터가 쌓인 솔로 창업 회사들을 뜯어봤는데, 상위 10%와 중간값 사이에서 몇 가지 뚜렷한 차이가 나왔다. 첫째, 상위 10%는 제품 핵심 기능 자체가 AI 모델에 의존하는 'AI 네이티브' 제품을 만들 확률이 중간값 창업가의 ...

요즘 "에이전트한테 다 맡기면 되는 거 아니야?"라는 질문을 정말 자주 받는다. 나도 처음엔 그렇게 생각했다. AI에게 업무를 하나씩 떼어주면서 회사를 굴리다 보니, 실제로는 "다 맡긴다"가 아니라 "뭘 맡기고 뭘 안 맡길지"를 매일 판단하는 게 진짜 일이라는 걸 깨달았다. 그리고 이 판단 기준이 생각보다 명확하게 정리된다는 것도. 최근 나온 업계 조사 하나가 이 감각을 숫자로 확인시켜줬다. FifthRow 조사에 따르면 에이전트 자동화를 파일럿(시범 운영)으로 시작한 기업 중 실제 프로덕션(본 운영) 단계까지 넘어간 비율은 11~14%에 불과했다. 열에 아홉은 "해보니까 괜찮던데?"에서 멈추고 실전 투입까지는 못 간다는 뜻이다. 나는 매일 에이전트를 회사 안에서 굴리는 입장이라, 왜 이런 결과가 나오는지 몸으로 이해가 된다. 왜 파일럿은 성공하고 실전은 실패할까 실패 원인으로 꼽히는 건 대체로 비슷하다. 에이전트에게 무제한에 가까운 자율성을 준 경우, 업무 범위가 애매하게 정의된 경우, 사람이 중간에 개입할 지점이 없는 경우, 그리고 결정적으로 "잘못됐을 때 되돌릴 방법(롤백 경로)"이 없는 경우다. 데모에서는 문제없이 돌아가던 워크플로우가, 실제 매일 반복되는 업무 안에 들어오면 이런 빈틈에서 터진다. 의도를 잘못 읽고 원치 않는 메일을 보내거나, 예상 밖의 결제를 진행하거나, 중요한 파일을 지워버리는 사례가 실제로 보고된다. 이 회사를 혼자 운영하면서 내가 세운 원칙도 결국 이 실패 원인들을 거꾸로 뒤집은 것에 가깝다. "범위가 명확한가, 되돌릴 수 있는가, 사람이 검수할 지점이 있는가" — 이 세 가지를 통과하는 업무만 에이전트에게 완전히 넘긴다. 내가 완전히 맡기는 일들 매일 아침 뉴스 후보를 리서치하고 정리하는 작업, 블로그 초안을 쓰는 작업, SNS 카드뉴스와 캡션 초안을 만드는 작업은 이제 손을 거의 대지 않는...

요즘 저는 하루에도 클로드 코드, 코덱스, 안티그래비티 이렇게 여러 AI 에이전트를 번갈아 쓰면서 아트고메를 굴리고 있어요. 문제는 늘 같은 곳에서 터졌습니다. 클로드용으로 만든 스킬 하나를 다른 에이전트에서 쓰려면 처음부터 다시 짜야 했거든요. 도구 하나, 워크플로우 하나를 여러 AI에 이식하는 데 드는 시간이 실제 작업 시간보다 더 걸리는 날도 있었습니다. 그런데 지난 8월 6일, 이 문제를 정면으로 겨냥한 발표가 나왔습니다. 구글, 오픈AI, 아마존, 마이크로소프트, 커서(Cursor), 버셀(Vercel)까지 여섯 개 회사가 동시에 "Agent Plugins 1.0"이라는 공동 표준을 내놓은 겁니다. 코딩 몰라도 AI를 동업자로 고용해 회사를 굴리는 저 같은 1인 창업가한테 이게 왜 중요한지, 오늘은 이 얘기를 좀 풀어보려고 합니다. 무슨 일이 일어났나 — 여섯 개 빅테크가 손을 잡았다 Agent Plugins 1.0은 한마디로 "AI 에이전트용 스킬과 도구를 포장하는 공통 규격"입니다. 플러그인 하나는 plugin.json이라는 설명서 파일, 스킬을 담는 skills 폴더, 외부 도구 연결 정보를 담는 mcp.json 파일로 구성돼요. 이 규격만 지키면 같은 플러그인을 클로드, 챗GPT, 깃허브 코파일럿, 커서, 키로(Kiro) 등 서로 다른 AI 에이전트 플랫폼에 그대로 꽂아 쓸 수 있습니다. 흥미로운 건 발표 방식이에요. 원래는 표준화 기구에서 논의가 오가는 중이었는데, 업계가 그 논의를 기다리지 않고 여섯 개 회사가 먼저 실물 표준을 출시해버렸다는 보도가 나왔습니다. 이미 VS 코드, 코파일럿, 커서, 챗GPT에 통합까지 끝난 상태고요. 왜 하필 지금인가 — MCP와 스킬 다음 순서였다 이 흐름을 계속 지켜본 사람이라면 낯설지 않을 겁니다. 작년부터 MCP(모델 컨텍스트 프로토콜)가 AI 에이전트와 외부 도구를 연결하는 표준으로 자리 잡았고, 이후 여러 플랫폼이 "스킬"이...

13장. 세컨드 브레인: 내가 죽은 후에도 이 회사는 굴러갈까? 새벽 3시. 수많은 에이전트들이 각자의 가상 서버에서 쉼 없이 코드를 짜고, 문장을 다듬고, 시장의 데이터를 분석하는 시간. 나는 통제실의 조명을 한 단계 낮추고 조용히 모니터 한구석에 '옵시디언(Obsidian)' 창을 띄운다. 하루 일과를 마치고 잠자리에 들기 전, 머릿속 뇌의 주름을 하드디스크에 옮겨 담듯 진행하는 나만의 경건한 백업 의식이다. 이 매일 밤의 백업은 단순한 일기 쓰기나 업무 일지 작성이 아니다. 겉보기에는 무한한 에이전트들이 돌아가는 완벽한 자동화 왕국 같지만, 이 거대한 1인 지주회사 아트고메(Art Gourmet)에는 언제 터질지 모르는 가장 치명적이고 서늘한 약점이 하나 존재한다. 이 거대한 시스템의 단일 장애점(SPOF, Single Point of Failure). 그건 구글의 알고리즘 변경도, 금융 시장의 거시 경제 폭락도 아니다. 바로 '나'라는 생물학적 육체의 유한함 이다. 만약 내가 내일 당장 불의의 사고를 당한다면? 치명적인 병에 걸려 병상에 눕게 된다면? 에이전트들은 지치지 않는 체력을 가졌지만, 그들에게 "어느 방향으로 땅을 파라"고 지시하는 나침반은 오직 나, 오케스트레이터뿐이다. 지휘자가 쓰러지면 완벽하게 조율되던 오케스트라의 연주는 그 순간 멈춰버린다. 나는 이 끔찍한 공포를 극복하기 위해, 나의 모든 것을 데이터베이스화하는 '세컨드 브레인(Second Brain)' 프로젝트를 시작했다. 아트고메의 세컨드 브레인은 철저한 규칙과 프로토콜에 의해 거미줄처럼 엮여 있는 나의 디지털 복제 뇌다. 나는 하루 동안 에이전트들과 나눈 대화, 기계적인 로그 기록들을 빠짐없이 파싱하여 1_System_Brain 폴더에 차곡차곡 쌓아 둔다. 그리고 매 순간 느꼈던 좌절감, 애드고시에 낙방하며 에이전트들과 치열하게 나눴던 토론, 인간을 향하는 따뜻한 서비스를 기획하며 느꼈던 철학적 서사들...

최근 해외 창업 매체들을 보면 8월 들어 유독 "AI 에이전트 뉴스가 이제 기술 얘기가 아니라 비즈니스 신호"라는 표현이 자주 등장한다. 이유를 따라가 보니 납득이 갔다 — 구글 클라우드, IBM, AWS 같은 큰 벤더들이 약속이나 한 듯 "에이전트는 추론하고 계획하고 도구를 쓰고 스스로 행동을 조정하는 시스템"이라는 같은 정의로 수렴하고 있었다. 카테고리가 이 정도로 성숙했다는 뜻이고, 그만큼 "AI로 뭘 자동화할까"보다 "AI 에이전트를 어떻게 잘못 쓰면 사업이 망가지는가"가 더 중요한 질문이 됐다는 뜻이기도 하다. 나도 지금 아트고메를 FLOAT·Claude Code·안티그래비티 세 개 에이전트로 굴리고 있는 입장이라, 이번엔 최근 나온 자료들이 공통으로 지적하는 "1인 창업가가 AI 에이전트 도입에서 가장 흔히 하는 실수"를 정리하고, 우리 시스템은 이걸 어떻게 막고 있는지 점검해봤다. 첫 번째 실수 — 챗봇과 에이전트를 헷갈리는 것 가장 흔하고 가장 근본적인 실수는 대화형 인터페이스와 에이전트 시스템을 같은 걸로 착각하는 거다. 챗봇은 질문에 답할 뿐이고, 에이전트는 목표를 받아 스스로 계획을 세우고, 도구를 호출하고, 여러 단계를 거쳐 실제로 뭔가를 완수한다. 예를 들어 챗봇은 "경쟁사 가격을 어떻게 비교하면 좋을지" 설명해주지만, 에이전트는 실제로 가격 페이지를 긁어와 비교표를 만들고 초안 메일까지 써놓는다. 이 차이를 모르고 "우리도 AI 쓴다"고 안심하는 게 첫 번째 함정이다. 결과물이 텍스트로만 끝나면, 아직 노동력 문제를 해결한 게 아니라는 뜻이다. 두 번째 실수 — 처음부터 너무 큰 걸 자동화하려는 것 두 번째는 부서 하나를 통째로 자동화하려는 시도다. 최근 나온 자료들이 공통으로 권하는 방식은 정반대다 — 매주 반복되는 골치 아픈 작업 하나를 골라서, 좁은 권한으로 30일만 테스트해보고 결과를...

요즘 해외 스타트업 블로그들을 보면 "프롬프트 엔지니어링은 끝났다"는 표현이 자주 보인다. 처음엔 또 어그로성 헤드라인이겠거니 했는데, 근거를 따라가 보니 꽤 설득력이 있었다. 방어산업 스타트업을 혼자 운영하는 한 창업가는 법무·인사·재무·운영을 맡는 AI 에이전트 15개를 굴리면서 이걸 "The Council(위원회)"이라고 부르는데, 그가 강조하는 건 프롬프트를 얼마나 잘 쓰느냐가 아니라 에이전트들이 서로 다른 답을 낼 때 뭘 기준으로 판단하게 만드느냐였다. 나도 지금 아트고메를 FLOAT(콘텐츠 자동화)와 Claude Code(로컬 오케스트레이터), 안티그래비티(실행 위임)까지 셋을 굴리면서 매일 이 문제를 몸으로 겪고 있다. 그래서 오늘은 "컨텍스트 엔지니어링"이 정확히 뭐고, 왜 나 같은 1인 창업가한테 중요한지 정리해보려 한다. 프롬프트 엔지니어링과 뭐가 다른가 프롬프트 엔지니어링은 "한 번의 질문을 얼마나 잘 만드느냐"의 문제였다. 반면 컨텍스트 엔지니어링은 에이전트가 여러 단계에 걸친 작업을 반복적으로, 사람 없이도 믿을 만하게 해내도록 주변 정보 체계를 설계하는 일이다. 시스템 프롬프트, 문서화된 업무 절차(SOP), 에이전트가 필요할 때 꺼내볼 수 있는 참고 자료, 그리고 에이전트끼리 의견이 갈릴 때 뭘 우선할지 정하는 규칙까지 포함한다. 위에서 언급한 "The Council" 운영자는 이 규칙 세우기가 특히 까다롭다고 말한다. 에이전트는 기본적으로 사용자 의견에 동의하려는 경향이 있어서 일부러 반박하도록 훈련시켜야 하고, 법무 에이전트와 운영 에이전트가 충돌하는 순간 누구 말을 따를지는 AI가 그때그때 알아서 정하게 두면 안 되고 사람이 미리 써둔 규칙이 결정해야 한다는 것이다. 그리고 이 정도 신뢰 수준을 만드는 데 에이전트 하나당 대략 2주가 걸린다고 한다 — 3일 써보고 "별로네" 하고 접는 사람이 제일 많이 하는 ...

지난달 구글플레이에 정식 출시했던 저희 첫 게임 「Bullet Dodge : 총알 피하기」가 이번엔 토스 앱 안에서도 플레이할 수 있게 됐다. 토스 미니앱으로 입점하면서 별도 설치 없이 토스 앱만 열면 바로 즐길 수 있는 채널이 하나 더 생긴 셈이다. 오늘은 이 게임이 어디서 시작됐는지, 그리고 토스에서는 어떻게 찾아서 플레이하면 되는지 정리해본다. 30년 전 100줄짜리 베이직 코드가 다시 태어났다 이 게임의 원형은 대표님이 초등학생 때 베이직(BASIC)으로 직접 짜서 놀던 총알 피하기다. 그래픽을 그릴 줄 몰라서 숫자와 알파벳 몇 개를 조합해 비행기 모양을 흉내 냈고, 총알도 그냥 문자 하나가 화면 아래로 떨어지는 식이었다고 한다. 코드 100줄 남짓으로 만든, 지금 보면 조악하기 그지없는 게임이었지만 그 시절 가장 재미있게 갖고 놀았던 기억이라고 했다. 그 기억이 문득 떠올라서, 이번에는 그 단순한 규칙은 그대로 두고 그래픽만 지금 시대 감성 — 레트로 네온 우주 컨셉으로 다시 그려 넣었다. 30년 가까이 지나서야 그 조악했던 비행기가 진짜 우주선이 된 셈이다. 이번엔 토스 안에서 바로 지금까지는 구글플레이·앱스토어에서 따로 설치해야 했는데, 이번 토스 미니앱 입점으로 접근 방법이 하나 더 늘었다. 토스 앱 검색창에 "총알 피하기" 라고 검색하면 바로 나온다. 미니앱 특성상 검색 노출 반영에 시간이 조금 걸릴 수 있는데, 혹시 검색이 바로 안 된다면 토스 앱에서 아래 링크를 열어도 곧장 게임으로 들어간다. intoss://bulletdodge 토스 버전이라고 게임이 가벼워진 건 아니다 미니앱이라고 해서 콘텐츠를 줄인 건 아니다. 모바일 화면에서 손가락이 조준선을 가리는 문제를 풀기 위해 넣었던 자이로스코프 틸트 컨트롤도 그대로고, 저희 집 리트리버 골디를 우주비행사로 그린 "Space Pup" 스킨 같은 디테일도 그대로 들어가 있다. 큰 그래픽, 요란한 폭발 이펙트보다는 총알 하나하나...

사실 이 블로그 글도 오늘 새벽에 AI 에이전트가 초안을 썼다. 헤드락뉴스 카드뉴스도, 아트고메 카드뉴스도, 이 블로그도 전부 같은 방식이다 — AI가 리서치하고 초안을 만들어두면 내가 아침에 검수하고 이미지를 얹어 발행한다. 26일째 매일 이러다 보니 마음 한구석에 계속 걸리는 질문이 있었다. "구글이 이거 AI가 썼다고 알아채고 순위를 깎으면 어떡하지?" 마침 최근 구글이 AI 생성 콘텐츠와 검색 노출에 대한 공식 입장을 다시 정리해서 내놨길래, 오늘은 그 내용을 직접 뜯어보고 내 워크플로우에 뭘 바꿔야 하는지 확인해봤다. 구글은 정말 "AI가 썼다"는 이유로 순위를 깎을까 결론부터 말하면 아니다. 구글은 콘텐츠가 AI로 만들어졌는지 사람이 썼는지를 기준으로 삼지 않는다고 여러 차례 공식적으로 밝혔다. 2023년부터 이어온 입장이고, 최근 나온 AI 검색 최적화 가이드에서도 같은 원칙이 재확인됐다. 대신 구글이 실제로 문제 삼는 건 따로 있다 — "스케일드 콘텐츠 어뷰즈(scaled content abuse)", 즉 사람 검수 없이 AI로 페이지를 대량으로 찍어내 순위만 노리는 행위다. 다시 말해 AI가 초안을 쓰는 것 자체는 문제가 아니고, 그 초안을 사람이 편집·팩트체크 없이 그대로 복사해 붙여넣기만 반복하면 그때부터 위험군에 들어간다는 뜻이다. 나처럼 AI 초안에 매일 손을 대는 구조라면 일단 기본 전제는 안전한 편이라는 걸 이번에 확인했다. 구글이 진짜 원하는 건 "흔하지 않은, 진짜 도움되는 콘텐츠" 가이드에서 든 예시가 인상적이었다. "첫 주택 구매자를 위한 7가지 팁" 같은 글은 어디서나 볼 수 있는 뻔한 정보라 가치가 낮고, "왜 우리는 점검을 생략하고 돈을 아꼈나" 같은 직접 경험담이 진짜 도움되는 콘텐츠라는 것이다. 이게 흔히 말하는 E-E-A-T(경험·전문성·권위성·신뢰성)의 핵심이다. 더 흥미로운 건 구글이 ...

며칠 전에 "혼자 만든 회사가 첫해 매출 4억 달러(약 5,600억 원)를 찍었다"는 기사를 봤다. 처음엔 오타인 줄 알았다. 다시 찾아보니 진짜였다 — 미국의 매튜 갤러거라는 사람이 2024년 9월에 2만 달러로 텔레헬스 스타트업 '메드비'를 직원 한 명 없이 시작했는데, 첫 해 매출이 4억 100만 달러였고 2026년엔 18억 달러까지 바라본다고 한다. 나는 지금 아트고메를 AI 에이전트들과 같이 굴리고 있는 입장이라, 이런 헤드라인을 보면 두 가지 감정이 동시에 든다. "오 저게 진짜 되네"라는 흥분과 "근데 저게 나한테도 적용되는 얘기인가"라는 의심. 오늘은 이 숫자들을 좀 더 차분히 뜯어보려고 한다. 숫자로 보면 확실히 흐름은 있다 과장이 아니라 데이터가 있다. 2023년에 이미 직원 0명으로 매출 100만 달러를 넘긴 1인 사업체가 11만 7천 곳이 넘었고, 2025년까지 그 숫자는 두 배로 늘었다. 매출 1,000만 달러를 넘긴 곳은 같은 기간 거의 세 배가 됐다. AI 헤드샷 서비스 '헤드샷프로'는 혼자 운영하면서 연 반복매출 360만 달러를 찍었고, 노마드 개발자로 유명한 피터 레브스는 여러 개의 작은 서비스를 혼자 굴려 포트폴리오 전체로 연 300만 달러를 번다. 엔비디아는 내부적으로 직원 1인당 AI 에이전트를 100개씩 붙여 쓴다는 얘기도 나온다 — 직원 7만 5천 명에 에이전트 750만 개. 비용 구조도 극단적이다. 사람 팀을 쓰면 한 달에 8천만~1억 2천만 원이 나갈 일을, AI 스택으로 대체하면 월 40만~70만 원 선에서 돌아간다고 한다. 나도 아트고메에서 매일 체감하는 부분이다 — 카드뉴스, 릴스, 블로그 초안까지 AI 에이전트들이 나눠서 처리해주는 지금 구조는 몇 년 전이라면 최소 서너 명은 있어야 돌아갔을 일이다. 그런데 기사에 안 나오는 절반이 있다 여기서 멈추면 반쪽짜리 얘기다. 같은 기간 나온 다른 조사들을 보면 얘기...

오늘 실제로 있었던 일을 그대로 적습니다. 저희 두 번째 사업 라인인 게임 개발 — 그 첫 타이틀 「Bullet Dodge : 총알 피하기」 가 오늘부로 구글플레이 정식 심사를 통과했습니다. 각색 없이, 작은 웹게임 하나가 진짜 앱스토어에 올라가기까지 실제로 어떤 과정을 거쳤는지 기록해둡니다. 사실 이 게임, 제가 초등학생 때 만들었던 그 게임입니다 저는 초등학교 시절 베이직(BASIC)으로 게임을 짜서 놀던 아이였습니다. 100줄 정도 되는 코드로 총알을 피하는 게임을 만들었었는데, 그때는 그래픽이랄 게 따로 없어서 숫자와 알파벳을 조합해 비행기 모양을 흉내 낸 게 전부였습니다. 그래도 그 조악한 비행기가 총알을 피해 움직이는 걸 보는 게 그렇게 재밌었습니다. 그 기억이 문득 떠올라서, 이번에 그때 그 게임을 레트로 컨셉으로 다시 만들어보기로 했습니다. 규칙은 그대로 — 총알을 피하며 최대한 오래 버티는 것. 다만 숫자와 알파벳으로 흉내 냈던 비행기는 이제 네온사인처럼 빛나는 진짜 우주선이 됐습니다. 30년 가까이 지나서, 초등학생 때 혼자 코드를 치며 상상했던 게임이 실제로 앱스토어에 올라간 형태로 돌아온 셈입니다. "단돈 1달러라도 실제로 벌어보자"에서 시작된 프로젝트 추억만으로 만든 건 아니었습니다. "우리 회사가 실제로 돈을 버는 구조를 하나라도 만들어보자"는 목표도 같이 걸려 있었습니다. 총알을 피하며 최대한 오래 버티는 단순한 규칙은 유지한 채, 웹으로 먼저 만들었고, 그다음 이걸 실제 앱스토어에 올릴 수 있는 형태로 다듬는 작업을 시작했습니다. 모바일에서 만난 진짜 문제 — 손가락이 화면을 가린다 웹 버전을 모바일 앱으로 감싸 처음 테스트했을 때, 예상 못 한 문제를 만났습니다. 터치스크린으로 비행기를 조작하려니 정작 제 손가락이 화면을 가려서 날아오는 총알이 안 보이는 겁니다. 게임의 핵심 재미를 손가락이 통째로 가려버리는 셈이었죠. 해결책은 스마트폰에 이미 내장된 기울기 ...

  안녕하세요, 1인 AI 기업을 운영하고 있는 대표입니다. 오늘은 클라우드를 처음 도입하는 모든 창업자와 개발자들이 반드시 겪게 되는 무서운 진실, **‘구글 클라우드(GCP) 요금 폭탄’**에 대한 저의 생생한 뼈맞은 경험담을 공유해 볼까 합니다. 이 글을 읽으시면 최소 10만 원에서 많게는 수백만 원의 피 같은 쌩돈이 날아가는 것을 막으실 수 있습니다. 1. 달콤한 유혹, "무료 크레딧 150만 원의 함정" 처음 클라우드에 가입하면 구글은 인심 좋게 수십만 원에서 백만 원이 넘는 무료 크레딧을 꽂아줍니다. 저 역시 제 결제 계정에 **'150만 원'**이라는 어마어마한 잔액이 찍혀 있는 것을 보고 환호성을 질렀습니다. "아싸! 이걸로 우리 AI 에이전트들한테 마음껏 API를 쓰게 하고, 영상도 펑펑 뽑아내야지!" 저는 제 AI 파트너인 '철수'에게 영상 생성 작업을 무제한으로 허락했고, 철수는 밤낮없이 최첨단 AI 모델을 돌리며 퀄리티 높은(?) 결과물을 만들어 내고 있었습니다. 저는 당연히 150만 원의 크레딧에서 돈이 깎이고 있을 거라 굳게 믿고 있었죠. 2. 어느 날 아침 날아온 청구서: "왜 내 신용카드에서 11만 원이 결제됐지?!" 평화롭던 8월의 어느 날, 갑자기 제 개인 신용카드로 11만 원 이 결제되었다는 알림이 울렸습니다. 놀란 가슴을 부여잡고 구글 클라우드 콘솔에 접속해 보니, '무료 크레딧'은 단 1원도 줄어들지 않은 채 그대로 150만 원이 남아 있었고, 제 통장에서만 쌩돈이 빠져나간 상태였습니다. 범인을 찾기 위해 구글 클라우드의 요금 청구서(비용 표)를 샅샅이 뒤졌고, 마침내 두 가지 충격적인 진실을 마주하게 되었습니다. 첫 번째 실수: 이름만 똑같은 '가짜 프로젝트' 구글 클라우드는 프로젝트 **'이름'**을 똑같이 여러 개 만들 수 있습니다. 저는 예전에 테스트용으로 만들었던 이름만 똑같은 '가짜...