요즘IT » AI » 피드

클로드 코드 제대로 써보신 분! <클코나잇 2> 발표자 모집

클로드 코드 현업 경험담을 나눠주실 발표자를 찾습니다!

콘텐츠 평균 조회수 1만 뷰 이상! 지난 2025년 10월부터 12월까지 요즘IT는 개발자와 비개발자의 클로드 코드 활용 사례를 알아보는 ‘클코나잇’ 세미나를 진행했습니다.

그리고 10인의 발표자분들과 함께한 경험담을 『클로드 코드로 일하기: 10인 실제 사례집』으로 엮어 많은 독자분들의 관심을 받았습니다. 저희도 이렇게 큰 관심은 예상치 못했던 만큼, 한 번으로 끝내기 아쉽다는 생각이 들었습니다.

여전히 클로드 코드에 대한 니즈는 계속되고 있기도 하고요. 그래서 요즘IT ‘클코나잇’이 시즌 2로 돌아옵니다!

시즌 2는 시즌1보다 한 걸음 더 들어갑니다. 시즌 1이 처음 써본 분들의 놀라움이었다면, 이번엔 클로드 코드와 제대로 씨름하며 만들어낸 진짜 노하우를 다룹니다. 개인 또는 팀(2인 이상)으로도 참여할 수 있고, 클로드 코드를 치열하게 써본 경험이라면, 어떤 이야기든 환영합니다.

오늘부터, 발표자로 합류하실 분을 모집합니다!

➡️발표자 신청하기

클로드 코드, 지금 어디까지 왔나요?

클로드 코드가 세상에 나온 지도 거의 1년이 됐습니다. 처음엔 "이게 되네?" 하며 신기해하던 시절이 있었죠. 그런데 지금은 분위기가 달라졌습니다. 하네스(Harness) 같은 도구가 엔지니어링 워크플로우의 표준처럼 자리를 잡아가고, 클로드 코드를 포함한 AI 코딩 도구는 이제 '써볼까'의 영역이 아니라 '어떻게 제대로 쓸까'의 영역으로 넘어왔습니다.

개발자뿐 아니라 PM, 기획자, 마케터도 클로드 코드로 자기 업무의 문제를 직접 해결하기 시작했고, 팀 단위로 도입하거나 조직 전체의 워크플로우를 바꾼 사례도 나오고 있습니다. 놀라움은 이미 지나갔습니다.

현실적으로

클로드 코드와 씨름하며 제대로 써본 사람이 할 수 있는 이야기
개인의 삽질기부터 팀 도입기
성공담뿐 아니라, 실패담과 현재 진행 중인 실험기

를 ‘클코나잇 시즌 2’에서 들어보려고 합니다.

이런 이야기 환영해요

잘 작동하는 에이전트 하나 만들겠다고 자기 도메인 지식을 쪼개고 쪼개본 비개발자(PM·기획자·마케터·편집자 등)의 분투기
팀 skill / 공용 커맨드 만들겠다고 회사 곳곳을 휩쓸고 다니며 표준을 세워본 이야기
바이브코더들을 위한 도구를 직접 만들어서 주변의 클로드 코드 사용을 매끄럽게 바꾼 이야기
내 업무 하나를 통째로 에이전트에게 넘겨본 이야기: 매일 하던 루틴을 완전히 대체해버린 경험담
내 업무를 에이전트가 빼앗아갈 줄 알았는데 현실은 그렇지 않다는 걸 깨닫게 된 이야기
CLAUDE.md, Skills, 서브에이전트, 훅, 컨텍스트 관리까지 파고들어 Claude Code를 내 워크플로우에 맞게 길들인 이야기
토큰 폭망, 컨텍스트 관리 실패, 엉뚱한 파일 삭제 등 진짜 아팠던 실패담
팀 도입 후 "쓰는 사람만 쓰는" 양극화를 풀어낸 정착기
클로드 코드로 이런 짓까지 해봤다! 싶은 극단적 사례

➡️ 클로드 코드로 부딪히고 깨지면서 만들어낸 여러분만의 방식을, 이제 나눠주세요!

발표 안내

발표 길이: 15분 내외
방식: 온라인 (Zoom)
날짜: 5월 중순쯤(협의 예정)

신청 방법

신청 기한: 4/17(금) ~ 4/28(화) 23:59분 마감
신청 방법: 신청 폼 작성 후 제출
신청자 중 서류 검토 후 간단한 개별 인터뷰(온라인)를 진행합니다.
최종 선정되신 분께는 5/6(수)에 개별 연락드립니다.

발표자에게 드리는 것

공식 소개: 요즘IT 웹사이트, 뉴스레터, SNS에서 발표자와 주제를 소개합니다. (개인 블로그·링크드인 등 링크도 함께)
기록 자산: 발표 내용은 영상·아티클로 제작되어, 발표자가 이후에도 공유·포트폴리오에 활용할 수 있습니다.
사례집 수익 배분: 발표 내용은 클코 나잇 사례집(PDF)으로 엮여 판매합니다. 판매 수익은 발표자분들과 함께 나눕니다.
디지털 배지: 요즘IT Speaker 배지(PNG/SVG)를 드립니다.
다음 기회 연결: 발표가 좋은 반응을 얻으면 후속 인터뷰나 다음 세미나로 이어집니다.

클코나잇은?

완벽한 강연이 아니라, 실무에서 써본 리얼 경험담을 나누는 자리예요.
클코나잇 시즌 1이 많은 관심을 받았고, 클로드 코드에 대한 궁금증과 수요는 계속되고 있습니다.
부담 갖지 말고, 편하게 “써본 자들의 밤”에 합류해주세요!

지원 TIP!
이 글을 '스크랩'해두시면 마이페이지에서 바로 확인할 수 있어요.
지금은 발표할 내용이 떠오르지 않아도, 클로드 코드를 쓰다 보면 아이디어가 분명 생길 겁니다.
글을 저장해두셨다가 생각이 정리되면, 마감일 전에 꼭 지원하세요! (로그인하면 스크랩 가능합니다.)

]]>

“이걸 누가 관리하나요?” GEO 자동화가 필요한 이유

GEO가 필요한데, 어떻게 적용할 것인가?

최근 GEO(Generative Engine Optimization)는 AI 검색 시대의 핵심 전략으로 빠르게 자리 잡고 있습니다. ChatGPT, Gemini, Perplexity와 같은 생성형 AI 서비스는 더 이상 단순히 웹 페이지 링크를 나열하지 않습니다. 대신 사용자의 질문에 대해 직접 “답변 문장”을 생성하며, 이 과정에서 특정 웹 콘텐츠를 인용하여 재구성합니다.

이로 따라 많은 기업이 기존의 SEO(Search Engine Optimization)뿐만 아니라, GEO를 위한 구조화 정보, 특히 JSON-LD 기반 태그를 활용해 자사 콘텐츠가 AI 답변에 포함되도록 최적화를 시도하고 있습니다. 그러나 실제 서비스 환경에서는 곧 하나의 근본적인 질문과 마주하게 됩니다.

“이걸 누가, 어떻게 계속 관리할 것인가?”

정적인 웹 사이트라면 한 번의 작업으로도 어느 정도 유지가 가능하겠지만 포털, 뉴스, 전자상거래, 커뮤니티, SaaS 문서 플랫폼처럼 콘텐츠가 지속적으로 생성되고 수정되며, 때로는 삭제되는 환경에서 웹 페이지마다 지속적으로 구조화 데이터를 관리하는 것이 사실상 불가능합니다.

이 글에서는 이러한 문제를 해결하기 위해 현재 사내에서 실험 중인 GEO 자동화 아키텍처를 기반으로, 다음 내용을 알아보고자 합니다.

GEO는 더 이상 전략 문제가 아니라 운영 문제이며, 자동화를 통해 확장할 수 있습니다.
AI를 활용하면 콘텐츠 분석부터 구조화 데이터 생성까지 전 과정을 자동화할 수 있습니다.
CDN 엣지와 서버리스(Serverless)를 결합하면 서비스 수정 없이 GEO를 적용할 수 있습니다.

GEO 전략을 실제 서비스에 적용할 때 마주하는 문제

GEO 개념 자체는 비교적 명확합니다. AI가 이해하기 쉬운 구조로 콘텐츠를 제공하고, 이를 통해 인용 가능성을 높이는 것입니다. 그러나 이를 실제 서비스에 적용하는 순간, 문제의 본질은 기술이 아니라 운영으로 이동합니다.

첫 번째 문제는 콘텐츠 규모입니다. 하루 수십, 수백 개의 페이지가 생성되는 서비스에서는 페이지마다 적절한 구조화 데이터를 작성하는 것이 불가능합니다. 특히 전자상거래 상품 페이지나 뉴스 기사처럼 데이터가 지속적으로 업데이트되는 환경에서는 메타데이터의 최신성을 유지하는 것 자체가 큰 비용으로 이어집니다.

두 번째 문제는 콘텐츠의 다양성입니다. 단순 블로그 글이 아니라 상품, 리뷰, FAQ, 기술 문서 등 다양한 형태의 콘텐츠가 존재할 때, 각각에 맞는 스키마 구조를 설계하고 유지하는 것도 쉽지 않습니다. 이는 단순 반복 작업이 아니라 도메인 이해를 요구하는 작업이기 때문입니다.

세 번째 문제는 조직 구조입니다. 대부분의 엔터프라이즈 환경에서는 웹 애플리케이션 코드 수정이 매우 엄격하게 통제됩니다. JSON-LD를 추가하는 단순 작업조차도 배포 승인 프로세스를 거쳐야 하며, 이로 따라 GEO 적용 속도는 조직 구조에 의해 제한됩니다.

네 번째 문제는 효과 측정입니다. 기존 SEO는 클릭 수, 클릭 확률, 순위 등 명확한 지표가 존재했습니다. 그러나 GEO는 “인용”이라는 새로운 지표를 중심으로 움직이며, 이는 정량화하기 어렵고 플랫폼별로 측정 방식도 다릅니다.

결국 GEO는 “어떻게 잘 만들 것인가”보다 “어떻게 지속적으로 운영하고 개선할 것인가”가 더 중요한 문제로 전환됩니다.

AI 기반 구조화 데이터 생성 파이프라인

위에서 언급한 문제의 해결을 위해 사내에서는 AI를 활용한 GEO 자동화 파이프라인을 실험적으로 구축하고 있습니다. 핵심 아이디어는 사람이 직접 GEO 태그를 작성하는 대신, AI가 콘텐츠를 읽고 구조화 데이터를 자동으로 생성하도록 만드는 것입니다.

GEO를 위한 태그 생성 및 제공 프로세스 <출처: 작가>

먼저 GEO 태그 생성 프로세스는 크게 네 단계로 구성됩니다.

첫 번째는 콘텐츠 수집 단계입니다. CMS, 내부 API, 혹은 HTML 크롤링을 통해 웹 페이지의 본문 자료를 수집합니다. 이때 중요한 것은 단순 HTML이 아니라 “의미 있는 텍스트”를 추출하는 것입니다.

두 번째는크롤링한 콘텐츠의 클렌징 및 MD 형식으로의 변환 단계입니다. HTML 내의 광고, 내비게이션, 불필요한 태그 등을 제거하고 LLM이 이해하기 쉬운 형태로 데이터를 변환합니다. 이 단계는 결과 품질에 매우 큰 영향을 미치면서도 사용하는 사용할 소비 토큰을 줄여주는 효과도 있습니다.

세 번째는 AI 분석 단계입니다. AI 모델은 MD 파일을 분석하여 제목, 작성자, 발행일, 핵심 주제, 키워드, 엔티티 등을 추출합니다. 특히 엔티티 추출은 GEO에서 매우 중요한 역할을 하며, 이는 AI가 콘텐츠를 “지식 단위”로 이해하는 데 도움을 줍니다.

네 번째는 구조화 데이터 생성 단계입니다. 추출된 정보를 기반으로 schema.org 표준에 맞는 JSON-LD를 생성하고, 이를 CDN 엣지 플랫폼 내의 KV 스토어 데이터베이스에 저장합니다.

다음은 특정 페이지 내용을 태그 생성 프로세스를 통해 저장한 JSON-LD의 예제 일부입니다.

{
  "@context": "https://schema.org",
  "@graph": [

    {
      "@type": "WebSite",
      "@id": "https://learn-ai.brandonkang.org/#website",
      "url": "https://learn-ai.brandonkang.org/",
      "name": "Learn AI",
      "description": "Learn AI is a practical knowledge hub covering AI fundamentals, large language models, GPU infrastructure, inference optimization, and Kubernetes-based AI systems.",
      "inLanguage": "en",
      "publisher": {
        "@id": "https://learn-ai.brandonkang.org/#person"
      }
    },

    {
      "@type": "Person",
      "@id": "https://learn-ai.brandonkang.org/#person",
      "name": "Brandon Kang",
      "url": "https://learn-ai.brandonkang.org/",
      "jobTitle": "Technical Solutions Architect",
      "knowsAbout": [
        "Artificial Intelligence",
        "Large Language Models",
        "GPU Computing",
        "AI Inference",
        "Kubernetes",
        "Cloud Infrastructure"
      ]
    },
…

여기서 중요한 사항은 “완벽성”이 아니라 “일관성”입니다. 일부 필드가 완벽하지 않더라도, 모든 페이지에 일정 수준의 구조화 데이터가 지속적으로 제공되는 것이 GEO 관점에서는 훨씬 더 중요합니다. 또한 이 파이프라인은 이벤트 기반 혹은 주기적 배치 방식으로 동작하여, 콘텐츠가 업데이트될 때 자동으로 메타데이터가 재생성됩니다. 이는 GEO를 단발성 작업이 아닌 데이터 파이프라인으로 전환하는 핵심 요소입니다.

CDN 엣지 기반 GEO 자동 삽입 아키텍처

이제 위에서 생성한 데이터를 실제 사용자에게 전달되는 HTML에 포함하는 GEO 태그 제공 프로세스가 필요합니다. 많은 기업에서는 원본 웹 서버나 CMS를 자주 수정하는 것이 쉽지 않습니다. 최종 테스트 및 검수와 배포 프로세스를 지켜야 하기 때문입니다. 그래서 CDN 플랫폼을 활용한 쉬운 배포 방식을 선택했습니다. 사실 이 방식 때문에 동일한 CDN의 엣지에 배포된 KV 스토어를 사용하여 데이터 이동 시간을 최소화한 것입니다.

AI 에이전트가 웹 페이지를 요청하면 CDN 엣지 서버에서 구동하는 서버리스 함수는 원본 HTML 응답을 가로채고, 사전에 생성된 JSON-LD 데이터를 가져와 해당 페이지의 <head> 태그 내 삽입하여 최종 전달합니다. 아래는 그 과정을 수행하는 함수 예제입니다.

#rewrite.js
import { HtmlRewritingStream } from 'html-rewriter';
import { httpRequest } from 'http-request';
import { createResponse } from 'create-response';
import { EdgeKV } from 'edgekv';

export async function responseProvider(request) {

  // 1. 원본 HTML 요청
  let htmlResponse = await httpRequest(request);
  if (!htmlResponse.ok) {
    return createResponse(500, {}, `Failed to fetch doc: ${htmlResponse.status}`);
  }

  // 2. EdgeKV 초기화
  const edgeKv = new EdgeKV({
    namespace: "geo",
    group: "jsonld"
  });

  // 3. URL → key
  const url = new URL(request.url);
  const key = url.pathname.replace(/\/$/, "") || "/";

  let jsonLd = null;

  try {
    jsonLd = await edgeKv.getText({ item: key });
  } catch (e) {
    jsonLd = null;
  }

  let rewriter = new HtmlRewritingStream();
  let injected = false;

  // 4. 기존 JSON-LD 체크 (중복 방지)
  rewriter.onElement('script[type="application/ld+json"]', el => {
    injected = true;
  });

  // 5. <head>에 GEO 블록 삽입
  rewriter.onElement('head', el => {
    if (!injected && jsonLd) {
      el.append(`
        <!-- GEO / Structured Data -->
        <script type="application/ld+json">${jsonLd}</script>
      `);
    }
  });

  // 6. 응답 반환
  return createResponse(200, {}, htmlResponse.body.pipeThrough(rewriter));
}

이렇게 수정된 HTML은 짧은 주기 동안 CDN 캐시에 저장되어 다음 AI 에이전트의 요청부터는 별도의 삽입 과정 없이 빠르게 전달됩니다. 원본 콘텐츠가 변경되는 경우 어차피 웹 사이트 관리자는 CDN 캐시를 무력화하는 명령을 수행하기에 새로운 GEO 태그가 적용될 것입니다.

최종적으로 페이지에 적용된 JSON-LD 태그<출처: 작가>

이 방식의 가장 큰 장점은 원본 시스템을 전혀 수정하지 않고, 사용자 주변에 가장 가까운 곳에 위치한 CDN에서 모든 작업을 수행한다는 점입니다. 결과적으로 원본 서버의 애플리케이션 코드, CMS, 데이터베이스에 영향을 주지 않으면서 GEO를 적용할 수 있습니다. 오히려 사용자와 가까운 위치에서 캐싱된 응답이 전달되기에 체감 성능이 개선되는 경우도 있습니다.

이 접근은 GEO를 “콘텐츠 레벨”이 아니라 “플랫폼 레벨”에서 적용하는 방식이라고 볼 수 있습니다. 즉, 웹 사이트 개발팀이 아니라 인프라팀에서 GEO 태그를 통제할 수 있게 되는 것입니다.

GEO 적용 이후 무엇을 확인해야 하는가?

GEO를 적용한 이후 가장 중요한 질문은 “그래서 효과가 있는가?”입니다.

GEO 적용 이후 구글 사이트에서의 테스트 예제 <출처: 작가>

현재 프로토타입에서는 이를 검증하기 위해 세 가지 관점에서 자료를 수집하고 있습니다.

첫 번째는 크롤링 패턴입니다. AI 에이전트들이 어떤 페이지에 얼마나 자주 접근하는지를 CDN 로그 기반으로 분석합니다. 이는 AI가 어떤 콘텐츠를 “관심 있게 보는지”를 간접적으로 보여줍니다.

두 번째는 인용 여부입니다. 특정 질문에 대해 AI가 자사 콘텐츠를 실제로 인용하는지를 반복적으로 테스트합니다. 이는 기존 SEO의 순위 확인과 유사하지만, 훨씬 더 실험적인 접근이 필요합니다.

세 번째는 사용자 행동 변화입니다. AI 기반 유입이 실제 트래픽 증가나 브랜드 인지도 향상으로 이어지는지를 분석합니다. 특히 AI 답변을 통한 간접 유입은 기존 분석 도구로는 포착하기 어려운 경우도 많아, 새로운 지표 설계가 필요합니다.

JSON-LD가 전부는 아니다

한 가지 중요한 사항은 GEO 태그가 적용되었다고 해서 반드시 AI 검색 결과에 바로 반영되는 것은 아니라는 점입니다. 구조화 데이터는 중요한 정보지만, 실제 AI 답변 생성 과정에서는 그것만으로 인용 여부가 결정되지 않습니다.

특히 많은 조직에서 GEO를 “JSON-LD를 잘 넣는 작업”으로 이해하는 경우가 있는데, 구조화 데이터는 콘텐츠의 의미를 명확하게 전달하는 데 도움을 주는 보조적인 신호일 뿐이며, AI가 실제로 인용할지를 결정하는 핵심 요소는 결국 콘텐츠 자체입니다. 검색 엔진의 AI는 구조화 데이터보다도 본문에 포함된 정보의 명확성, 질문과의 직접적인 연관성, 그리고 문장의 재사용 가능성을 더 중요하게 판단합니다.

반대로 생각해 보면, 구조화 데이터가 다소 부족하더라도, 특정 질문에 대해 명확하게 답하는 문장이 잘 정리되어 있고, 콘텐츠의 구조가 논리적으로 구성되어 있다면 AI는 해당 콘텐츠를 충분히 활용할 수 있습니다.

AEO, GEO 적용을 위한 모범 사례 <출처: 작가>

결국 중요한 것은 “AI가 이해하기 쉬운 콘텐츠를 만드는 것”입니다. 구조화 데이터는 그 과정을 돕는 도구일 뿐이며, 이를 과도하게 의존하기보다는 콘텐츠 자체의 품질과 구조를 먼저 설계하는 접근이 필요합니다. 이러한 구조를 고려하면, GEO에서 구조화된 메타데이터는 “필수 조건”이 아니라 “가속 장치”에 가깝습니다. 구조화 데이터가 잘 되어 있으면 AI가 콘텐츠를 더 빠르고 정확하게 이해할 수 있지만, 결국 인용 여부를 결정하는 것은 콘텐츠 자체의 품질과 맥락 적합성입니다.

결과적으로 GEO는 더 이상 엔지니어링 팀만의 영역이 아닙니다. 구조화 데이터를 적용하는 기술적인 작업을 넘어, 웹 콘텐츠를 기획하고 작성하는 단계부터 AI가 이해하기 쉬운 형태로 정보를 구성하는 것이 중요해졌습니다. 즉, 콘텐츠 제작자 역시 GEO가 선호하는 정보 구조와 서술 방식, 그리고 문맥(Context)을 고려해야 하는 시대가 된 것입니다.

이는 단순히 키워드를 잘 배치하는 수준을 넘어, 질문에 직접적으로 답할 수 있는 문장 구조, 명확한 정보 단위, 그리고 AI가 재사용하기 쉬운 콘텐츠 형태를 만드는 방향으로 콘텐츠 전략 자체가 변화하고 있음을 의미합니다. 좀 더 자세한 내용은 기존 요즘IT 글 “AI 시대 콘텐츠 생존 전략: GEO를 위한 SIFT 프레임워크”를 참고하시기 바랍니다.

GEO는 이제 콘텐츠 전략을 넘어선 플랫폼 전략

AI 검색 환경에서는 어떤 콘텐츠가 “검색되는가”가 아니라, 어떤 콘텐츠가 “인용되는가”가 더 중요한 시대가 되었습니다. 콘텐츠 규모가 커질수록 이를 수작업으로 관리하는 방식은 한계를 가질 수밖에 없습니다. 따라서 앞으로 기업이 고민해야 할 질문은 GEO를 어떻게 자동화하고 운영할 것인가로 바뀔 것입니다.

본문에서 소개한 AI 기반 콘텐츠 분석, 서버리스 컴퓨팅, CDN 엣지 아키텍처를 결합한 접근은 이러한 문제를 해결할 수 있는 현실적인 방법 중 하나입니다. 이러한 흐름에 맞춰 구조화 데이터 생성, 콘텐츠 최적화, AI 인용 분석을 자동화하는 전문 도구와 서비스들이 속속 등장하고 있으며, GEO를 하나의 운영 체계로 관리하려는 시도도 점점 늘어나고 있습니다. 앞으로는 단순히 콘텐츠를 잘 만드는 것을 넘어, AI가 이해하고 활용하기 좋은 형태로 콘텐츠를 설계하고 이를 지속적으로 최적화하는 역량이 기업 경쟁력의 중요한 기준이 될 겁니다.

]]>

16년 된 백준(BOJ)이 문을 닫습니다

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

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

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

써볼 것: Claude Code Routines - 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능
참고할 것: BOJ(백준 온라인 저지) - 16년간 한국 개발자와 함께한 백준이 문을 닫습니다
적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

<출처: claude.ai>

1. 써볼 것: 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능

Claude Code에 Routines라는 기능이 추가됐습니다. 프롬프트, 레포지토리, 커넥터를 한 번 설정해두면 스케줄이나 GitHub 이벤트에 맞춰 자동으로 실행되는 기능인데요. Anthropic 클라우드에서 돌아가기 때문에 노트북을 닫아도 작업이 계속됩니다. 아직 research preview 단계이지만, Claude Code를 쓰는 개발자들 사이에서 관심을 받고 있습니다.

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

코딩 에이전트는 지금까지 사람이 앉아서 지시하고 결과를 확인하는 방식이었습니다. Claude Code든 Cursor든, 내가 대화창에 뭔가를 입력해야 일이 시작되죠. PR이 올라올 때마다 리뷰를 시키려면 그때마다 직접 세션을 열어야 했고, 매일 아침 이슈를 정리하려면 매번 같은 프롬프트를 붙여넣어야 했습니다. Routines는 이 반복을 자동화하는 기능이죠. 한 번 설정해두면 정해진 시간에, 또는 특정 이벤트가 발생할 때 알아서 실행됩니다.

어떻게 쓰나요?

claude.ai/code/routines에서 만들 수 있고, Claude Code CLI에서 /schedule 명령어로도 생성할 수 있습니다. 설정할 때 필요한 건 세 가지입니다. 실행할 프롬프트, 작업할 GitHub 레포지토리, 그리고 트리거 조건입니다.

트리거는 세 종류를 지원합니다.

스케줄: 매시간, 매일, 평일, 매주 등 주기를 정할 수 있습니다. 커스텀 cron 표현식도 가능하고요. 최소 간격은 1시간입니다.
GitHub 이벤트: PR이 열리거나, 릴리스가 생성되거나 할 때 자동으로 실행됩니다. PR 작성자, 제목, 라벨, 드래프트 여부 등으로 필터링도 가능합니다.
API 호출: HTTP POST 요청으로 실행할 수 있어서, 모니터링 도구나 배포 파이프라인과 연결할 수 있습니다.

하나의 Routine에 트리거를 여러 개 붙일 수도 있습니다. 예를 들어 PR 리뷰 Routine을 만들어서, 새 PR이 열릴 때도 실행되고 매일 밤에도 실행되게 설정할 수 있죠. 실행 결과는 일반 Claude Code 세션처럼 열어볼 수 있습니다. 뭘 했는지 확인하고, 변경 사항을 리뷰하고, PR을 만들 수도 있고요.

공식 문서에서 제시하는 활용 예시를 보면, 어떤 작업에 쓸 수 있는지 감이 옵니다. 매일 밤 이슈 트래커를 읽고 라벨을 붙이고 담당자를 배정한 뒤 Slack으로 요약을 보내는 백로그 관리, 모니터링 알림이 오면 스택 트레이스를 분석하고 최근 커밋과 연결해서 수정 PR 초안을 만드는 알림 분류, 병합된 PR을 스캔해서 API가 바뀐 문서를 찾아내고 업데이트 PR을 여는 문서 관리 같은 것들입니다.

다만 Routines는 완전 자율 모드로 실행됩니다. 중간에 승인 프롬프트가 뜨지 않아요. 셸 명령어를 실행하고, 레포에 커밋된 스킬을 쓰고, 연결된 커넥터(Slack, Linear 등)를 통해 외부 서비스에도 접근합니다. 그래서 필요한 레포와 커넥터만 연결하는 게 중요합니다. 그리고 아직 research preview라서 동작 방식이나 한도가 바뀔 수 있습니다. Pro, Max, Team, Enterprise 플랜에서 쓸 수 있고, 계정당 일일 실행 횟수에 제한이 있습니다.

누구에게 좋을까요?
Claude Code를 이미 쓰고 있으면서, PR 리뷰나 이슈 정리 같은 반복 작업을 자동화하고 싶은 개발자
CI/CD 파이프라인에 AI 코드 리뷰나 배포 후 검증을 붙이고 싶은 팀
매일 아침 또는 매주 돌아오는 정형화된 코드 작업이 있는 사람

<출처: BOJ(백준 온라인 저지)>

2. 참고할 것: 16년간 한국 개발자와 함께한 백준이 문을 닫습니다

BOJ(백준 온라인 저지)가 4월 28일자로 서비스를 종료합니다. 운영자 최백준 님이 직접 게시판에 올린 공지인데요. 한국 개발자 커뮤니티에서 즉시 화제가 됐습니다. 2010년부터 16년간 운영된 이 사이트는 3만 4천 개 이상의 프로그래밍 문제와 73개 언어 채점을 지원하며, 한국에서 알고리즘을 공부하는 사람이라면 거의 다 거쳐갔다고 보아도 무방한 곳입니다. 많은 개발자의 성장을 도운 BOJ가 이제는 추억 속의 사이트가 된다고 합니다.

운영자에게 인사를 남기는 사용자들
<출처: BOJ(백준 온라인 저지)>

BOJ가 어떤 곳이었나요?

한국 IT 업계에 있는 사람이라면 백준을 한 번쯤은 들어봤을 겁니다. 개발자가 아니더라도, 코딩 테스트를 준비하는 후배나 동료가 있다면 백준이라는 이름은 익숙하죠. 알고리즘 문제를 풀고 온라인으로 채점받는 사이트인데, 단순히 문제만 있는 건 아니었습니다. 단계별 학습, 문제집, 그룹, 대회, 게시판까지 알고리즘을 중심으로 한 학습 생태계가 만들어져 있었습니다.

solved.ac라는 서드파티 서비스가 문제 난이도와 사용자 티어를 매기면서 게이미피케이션 요소까지 더해졌고요. 백준 티어가 개발자들 사이에서 실력의 지표처럼 쓰이기도 했습니다. 한국 기업의 코딩 테스트 문화와 함께 성장한 플랫폼이라고 볼 수 있습니다.

무엇이 남고, 무엇이 사라지나요?

종료 공지에 따르면, 서비스 종료 시점에 문제 데이터, 제출 기록, 대회 정보는 보존됩니다. 나머지 데이터는 삭제될 예정이고요. 최백준 님은 완전히 사라지기보다는 문제만이라도 다시 볼 수 있는 형태로 돌아올 수 있도록 고민하고 있다고 밝혔습니다. 상황이 달라지면 서비스를 재개할 가능성도 열어두고 있다고요. 서비스 종료 전까지는 정상 이용이 가능하지만, 문제집이나 그룹 생성 같은 일부 기능은 제한될 수 있다고 합니다.

무엇을 얻어가야 하나요?

한 사람이 시작한 사이드 프로젝트가 16년간 업계 인프라 역할을 했다는 것 자체가 큰 의미가 있는 사례라고 생각합니다. 마지막까지 문제 데이터와 제출 기록은 보존하는 결정을 내린 부분에서, 운영자가 생각하는 핵심 가치를 엿볼 수 있을 것 같습니다.

종료 소식을 접한 커뮤니티 반응도 인상적이었는데요. 시대가 바뀌었고 코딩 테스트의 의미가 예전 같지 않다는 목소리가 꽤 있었습니다. AI 코딩 에이전트가 알고리즘 문제를 풀 수 있는 시대에, 알고리즘 문제 풀이 능력이 개발자 역량의 기준이 될 수 있느냐는 질문이죠. 반면에 코드가 무엇을 하는지 이해하는 기초 체력은 여전히 필요하다는 반론도 있었고요. 정답이 있는 논쟁은 아니지만, 이번 주 적용해볼 것에서 다루는 사례를 보면 이 질문이 왜 중요한지 조금 더 구체적으로 느껴질 겁니다.

<출처: tobru.ch>

3. 적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

스위스의 보안 엔지니어 Tobias Brunner가 3월 28일 블로그에 올린 글입니다. 자기가 직접 겪은 바이브 코딩 호러 스토리라는 제목인데요. 보안 커뮤니티에서 바이브 코딩의 실제 위험을 보여주는 사례로 공유되고 있습니다. AI 코딩 도구로 앱을 만드는 사람이 늘어나는 지금, 무엇이 빠지면 어떤 일이 벌어지는지를 보여주는 글입니다.

무슨 일이 벌어졌나요?

Tobias Brunner가 병원에 갔는데, 접수 담당자가 요즘 AI로 누구나 소프트웨어를 만들 수 있다는 영상을 봤다고 하면서 직접 환자 관리 시스템을 만들었다고 했다고 합니다. 기존에 쓰던 환자 데이터를 전부 가져와서 새 앱에 넣고, 인터넷에 배포하고, 진료 중 대화를 녹음해서 AI 서비스 두 곳으로 보내 자동 요약하는 기능까지 만들었다고요.

Brunner가 며칠 뒤 이 앱을 살펴봤더니, 30분 만에 전체 환자 데이터에 읽기·쓰기 권한을 확보할 수 있었다고 합니다. 모든 데이터가 암호화 없이 인터넷에 열려 있었던 거죠. 바로 담당자에게 알렸더니, 돌아온 답변은 AI가 자동 생성한 감사 메시지였다고 합니다. 기본 인증을 추가하고 접근 키를 교체했다는 내용이었는데, Brunner는 이 사람이 자기가 뭘 만들었는지 이해하지 못하고 있다고 봤습니다.

기술적으로 무엇이 빠져 있었나요?

Brunner가 설명하는 기술적 구조를 보면, 앱 전체가 HTML 파일 하나였다고 합니다. JavaScript, CSS, 모든 구조가 인라인으로 들어가 있는 단일 파일이었고요.

백엔드는 접근 제어가 전혀 설정되지 않은 관리형 데이터베이스 서비스를 썼다고 합니다. 행 수준 보안(row-level security)도 없었고요. 접근 제어 로직이라고 할 수 있는 건 클라이언트 측 JavaScript에만 있었는데, 이건 브라우저에서만 작동하는 거라 curl 명령어 한 줄이면 데이터에 바로 접근 가능한 상태였다고요.

음성 녹음 파일은 외부 AI API로 직접 전송되어 전사와 요약 처리가 됐고, 데이터는 미국 서버에 저장되어 있었는데 데이터 처리 계약(DPA) 없이 운영되고 있었다고 합니다. 환자에게 이런 데이터 처리에 대한 사전 고지도 없었고요. Brunner는 이 행위가 스위스 데이터 보호법(nDSG)과 직업상 비밀 유지 의무를 여러 조항에서 위반했을 가능성이 높다고 판단했습니다.

왜 이런 일이 생기는 건가요?

이 사례에서 빠진 건 코딩 능력이 아닙니다. AI 코딩 에이전트가 코드를 만들어주는 건 잘 했으니까요. 앱은 돌아갔고, 기능도 잘 작동했을 겁니다. 빠진 건 코드가 어떻게 작동하는지에 대한 이해였습니다. 클라이언트 측 접근 제어가 왜 보안이 아닌지, 데이터베이스에 접근 권한을 왜 설정해야 하는지, 환자 데이터를 외부 서비스로 보낼 때 어떤 법적 요건이 필요한지. 이런 판단은 AI 코딩 에이전트가 알아서 해주지 않습니다. 코드를 생성하는 것과 그 코드가 안전한지 판단하는 것은 완전히 다른 영역이죠.

Brunner 본인도 AI 코딩 에이전트를 쓴다고 밝혔습니다. 다만 자기는 코드를 읽을 수 있고, 소프트웨어 아키텍처를 이해하고 있기 때문에 쓸 수 있는 거라고요. 분위기에 취해서 만드는 것(vibing away)만으로는 안전한 결과가 나오지 않는다는 게 그의 결론입니다.

적용해볼 질문

내가 AI 코딩 도구로 만든 코드에서 접근 제어가 서버 측에 있는가, 클라이언트 측에만 있는가?
외부 API로 데이터를 보내고 있다면, 어떤 데이터가 어디로 가는지 파악하고 있는가?
AI가 만들어준 코드의 아키텍처를 내가 설명할 수 있는가?

실행해볼 수 있는 것

AI 코딩 에이전트로 만든 프로젝트가 있다면, 백엔드 접근 제어가 제대로 설정되어 있는지 확인해보기. 클라이언트 측 JavaScript에만 의존하고 있다면 서버 측 인증을 추가하기.
외부 API를 쓰고 있다면, 어떤 데이터가 어디로 전송되는지 한 번 정리해보기. 민감한 데이터가 포함되어 있다면 데이터 처리 계약이 필요한지 확인하기.
AI가 생성한 코드를 배포하기 전에, 최소한 보안 체크리스트 하나를 통과시키는 습관 만들기. 인증, 암호화, 접근 권한, 데이터 흐름

이 네 가지만 확인해도 이 사례 같은 사고는 막을 수 있습니다.

오늘 내용, 이렇게 적용해보세요

AI 에이전트에게 반복 작업을 맡기되, 맡기는 작업의 범위와 권한을 명확히 정해두기. Routines처럼 자동으로 돌아가는 작업일수록 어떤 레포에 접근하고 어떤 서비스에 연결되는지 꼭 확인하기.
AI가 만든 코드를 배포하기 전에, 보안 관점에서 한 번 훑어보는 습관 만들기. 인증이 서버 측에 있는지, 데이터가 어디로 가는지, 접근 권한이 적절한지. 이 세 가지만 확인해도 많은 사고를 막을 수 있습니다. (AI 시대에도 코드를 읽는 능력은 여전히 기반입니다. AI가 생성한 코드가 무엇을 하는지 설명할 수 없다면, 그건 아직 배포할 준비가 안 된 겁니다)

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

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

]]>

왜 개인 위키는 실패할까? 안드레 카파시의 ‘LLM 위키’

‘LLM 위키’로 지식을 복리로 쌓는 방법

여러분도 뭔가를 읽고 나서, "어? 이거 나중에 써먹어야지"라고 생각한 적이 있을 겁니다. 아티클, 뉴스레터, 팟캐스트, 어딘가에 적어둔 메모 등 말이죠. 그런데 나중이 되면 어디 있는지 모르거나, 찾아도 맥락이 기억나지 않습니다. 그래서 이걸 해결하고자 개인 위키를 만드는 사람들이 있습니다. 개인 위키는 말 그대로 개인 지식의 디지털 저장소로, 내가 읽고 배운 것들을 한 곳에 쌓아두는 문서 공간입니다. 노션이나 옵시디언 같은 툴에 주제별 페이지를 만들고, 내 지식들을 한 곳에 정리해 두는 방식이죠.

저도 몇 번이나 개인 위키 제작을 시도해 봤는데요. 처음엔 꽤 공들여 세팅해서 그럴듯했습니다. 페이지 만들고, 태그를 붙이고, 데이터베이스도 구성했죠. 그런데 한두 달쯤 지났을까, 같은 자리에서 막히기 시작했습니다. 새 정보를 넣으려고 열면 이 내용이 어떤 태그에 붙어있는지부터 기억해 내야 했고, 정보 업데이트를 위해선 이전에 적어둔 것들과 어떤 부분이 겹치는지 확인해야 했습니다.

또 새로 추가할 때마다 기존 내용을 업데이트하고, 교차 참조도 달아야 했죠. 이 과정이 30분을 넘어가기 시작하면, 그냥 어느 순간부터 안 쓰게 되고 그렇게 제 위키는 조용히 멈춰졌습니다. 언제부턴가 열지도 않게 됐죠. 결국 작심삼일처럼 스스로의 의지가 부족한 거라고 생각했습니다. 그런데 안드레 카파시(Andrej Karpathy, OpenAI 창립 멤버)가 최근 공개한 LLM 위키 아이디어 문서를 읽으면서, 다른 생각이 들었습니다. 걸림돌은 게으름이 아니라, 정리를 계속 유지하는 데 들어가는 비용이 너무 컸던 겁니다.

부담이 쌓이면 위키는 멈춘다

안드레 카파시는 최근 "코드보다 개인 지식 저장소 구축에 더 많은 AI 토큰을 쓰고 있다"고 말하며, 자신이 실험 중인 LLM-Wiki를 공개했습니다.

<출처: karpathy/llm-wiki.md>

그는 사람들이 위키를 포기하는 건 지식이 부족해서가 아니라, 유지 관리 비용이 가치보다 빠르게 증가하기 때문이라고 말했는데요. 보통 교차 참조 업데이트, 요약 최신화, 수십 페이지에 걸친 일관성 유지를 ‘북키핑(bookkeeping)’이라고 부릅니다. 우리가 읽고 생각하고 연결하는 것까진 즐거워하는데, 이미 적어둔 내용과 새 내용이 어디서 겹치는지 찾고, 기존 페이지를 하나하나 업데이트하는 건 다른 종류의 일이기 때문이죠. 그 지루한 일이 쌓이면, 결국 위키 관리를 포기하게 되고요.

그러나 인간과 달리 LLM은 지루함을 모릅니다. 교차 참조 업데이트를 잊지 않고, 새 소스 하나를 넣으면 관련된 15개 페이지를 한 번에 처리할 수 있습니다. 북키핑 비용이 거의 0에 가까워진다면, 위키를 유지할 수 있는 조건이 됩니다.

그런데 이 아이디어는 우리가 AI를 활용하는 일반적인 방식과 꽤 다릅니다. 보통 ChatGPT에 파일을 올리거나, NotebookLM을 쓸 때는 RAG(Retrieval-Augmented Generation) 방식을 사용합니다. 이건 질문할 때마다 원문에서 관련 내용을 다시 찾아 답하는 방식인데요. 예를 들어, 도서관 사서에 비유하면, 매번 서가에서 책을 꺼내 읽어주는 것과 비슷합니다. 찾아주긴 하지만 지식이 어딘가에 정리되어 쌓이지는 않습니다.

LLM-Wiki는 다릅니다. 내가 읽은 것들을 직접 요약·정리해 주는 비서에 가깝습니다. LLM이 원문을 읽고 마크다운 위키를 직접 쓰고, 새 소스가 들어올 때마다 기존 위키를 업데이트하면서 지식이 쌓입니다. 카파시의 표현을 빌려 표현하자면 "복리 축적형 결과물"인 셈이죠.

내가 소스를 넣으면 LLM이 위키를 쌓는다

<출처: 작가 제작, notebooklm>

구조는 다음과 같은 세 레이어로 이루어집니다.

첫 번째는 원문 소스입니다. 내가 모은 아티클, 논문, 이미지, 데이터 파일이죠. LLM이 읽기만 하고 수정하지 않는 레이어로, 진실의 원천이 됩니다.
두 번째는 위키입니다. LLM이 직접 생성하고 관리하는 마크다운 파일 모음입니다. 요약, 개념 정리, 비교/분석이 여기 쌓이고, 옵시디언 같은 도구로 열어두면 LLM이 편집하는 내용을 실시간으로 볼 수 있습니다. 카파시는 옵시디언은 IDE, LLM은 프로그래머, 위키는 코드베이스라고 비유했습니다.
세 번째는 스키마(schema)입니다. LLM에게 위키의 구조와 컨벤션, 워크플로를 알려주는 설정 문서인데, 이 파일이 있어야 LLM이 일반 챗봇이 아닌 체계적인 위키 관리자로 동작합니다. 처음엔 짧아도 되고, 사용자와 LLM이 쓰면서 함께 다듬어가는 문서이기도 합니다.

그리고 실제 작업은 인제스트(Ingest), 쿼리(Query), 린트(Lint) 세 가지로 나뉩니다. 먼저 소스를 새로 추가할 때 LLM이 읽고 위키를 업데이트하는 인제스트, 위키를 대상으로 질문하면 관련 페이지를 찾아 답을 만들어주는 쿼리, 주기적으로 페이지 간 모순이나 고립된 페이지를 점검하는 게 린트입니다. 쿼리에서 잘 만들어진 답변은 위키에 새 페이지로 저장되기도 합니다. 탐색 자체가 쌓이는 거죠.

제가 이 구조에서 가장 마음에 든 건 데이터 소유권입니다. "쓸수록 알아서 좋아진다"는 AI 개인화 방식의 경우, 내 데이터가 어디에 어떻게 저장되는지 보이지 않습니다. 반면, LLM-Wiki는 로컬 파일로 존재해서 AI가 무엇을 알고 모르는지 사람이 직접 확인하고 수정할 수 있는데요. Claude든 다른 모델이든 원하는 걸 연결할 수 있고, 특정 업체에 묶이지도 않습니다.

AI가 정리까지 해주면, 생각은 누가 하지?

여기까지 글을 쓰다 보니, 문득 이런 생각이 들었습니다. AI가 정리까지 해주면, 내가 해야 할 생각도 AI에게 넘기는 건 아닐까요? 처음 안드레 카파시의 LLM 위키가 Hacker News에 공유됐을 때, 댓글에서 비슷한 경험을 털어놓은 사람이 있었습니다. 그는 번아웃으로 집중력이 떨어졌을 때 많은 작업을 에이전트에 위임했는데, 새로운 형태의 기술 부채가 생겼고, "뇌의 일부가 비어 있는 느낌"이 든다고 말했습니다.

그는 왜 그런 느낌을 받았을까요? 직접 정리하는 과정에는 LLM이 대신할 수 없는 게 있습니다. 이 개념이 저 개념과 어떻게 닿는지 깨닫는 순간, 예전에 읽은 내용이 지금 읽는 것과 어떻게 연결되는지 느끼는 순간, 저는 그 순간들이 학습의 본체에 가깝다고 생각하는데요. 이렇게 스스로 사고하는 과정이 빠지면, 위키는 쌓여도 내 머릿속은 비어가는 역설이 생길 수 있습니다.

물론 카파시가 LLM에게 맡기자는 건, 사고의 과정이 아닙니다. 북키핑과 합성은 다르거든요. 교차 참조를 업데이트하고 모순을 표시하고 파일을 일관성 있게 유지하는 건 행정 작업이고, 여러 소스를 읽고 그것들이 무엇을 의미하는지 스스로 연결하는 건 사고 작업입니다. LLM에게 위임하는 건 전자죠. 무엇을 읽을지, 무엇을 물을지는 여전히 사람이 결정해야 합니다.

위키 관리 작업이 쌓이다 보면, 정작 읽고 연결하고 이해하는 데 쓸 시간과 에너지가 남지 않습니다. 따라서 LLM-Wiki는 그 관리를 LLM에 넘겨, 사람은 생각에만 집중할 수 있게 하는 시도에 가깝습니다.

물론 현실적인 위험도 있습니다. 위키가 커질수록 LLM이 전체를 일관성 있게 유지하기 어려워지고, 스키마가 잘 설계되지 않으면 어느 순간부터 LLM도 사람도 전체 구조를 파악하지 못하게 되거든요. 해커 뉴스 댓글에는 "일정 복잡도를 넘으면 에이전트가 위키를 유지하지 못한다"는 경고도 있었습니다.

결국 처음부터 모든 걸 담으려 하지 말고, 좁은 도메인부터 시작하는 것이 이 위험을 줄일 수 있는 현실적인 방법입니다.

1) 하나의 주제를 정합니다

만약 여러분이 AI와 지식 관리를 공부하고 있다면 그 주제만, 특정 기술 영역을 파고 있다면 그 영역만 팝니다. 처음부터 모든 지식을 담으려 하면 스키마 설계가 복잡해지고, 일관성을 유지하기 어려워집니다. 좁게 시작해서 구조를 익히는 게 먼저입니다.

2) 스키마 파일을 먼저 씁니다

LLM에게 "이 위키는 어떤 구조로 쓸 건지, 어떤 형식의 페이지를 만들 건지, 새 소스가 들어왔을 때 무엇을 업데이트해야 하는지"를 설명하는 파일입니다. 처음엔 짧아도 되고, 쓰면서 함께 다듬어가면 됩니다.

3) 아티클 하나를 넣어보세요

LLM에게 읽고 위키를 만들어달라고 하면서, 어떤 페이지들이 생기는지 보고 스키마를 다듬는 과정이 진짜 세팅입니다. 이 과정에서 꼭 옵시디언 같은 툴이 필요하진 않습니다. 마크다운 파일이 생기는 폴더 아무 데서나 시작할 수 있고, 위키가 수십 페이지를 넘어가면 그때 옵시디언 그래프 뷰가 연결 구조를 파악하는 데 유용합니다. 웹 기사를 마크다운으로 바꿔주는 브라우저 확장(Obsidian Web Clipper)을 쓰면, 소스를 빠르게 추가하는 루틴도 잡을 수 있습니다.

마치며: 유지 관리 비용이 낮아지면 지식은 복리로 쌓인다

카파시는 이 아이디어가 1945년 Vannevar Bush가 제안한 Memex에서 이어진다고 했습니다. Memex는 개인이 직접 큐레이션하고, 문서 간 연결이 문서 자체만큼 가치 있는 지식 저장소였습니다. 그런데 Bush가 끝내 풀지 못한 문제가 하나 있었습니다. 바로 “이걸 누가 유지 관리하느냐”에 대한 것이죠. 이제 80년이 지나, 그 자리에 LLM이 들어왔습니다.

카파시가 말한 “에이전트 활용 능력은 21세기의 핵심 스킬”은 단순히 에이전트를 쓰는 능력만을 뜻하지는 않는다고 생각합니다. 오히려 중요한 것은 무엇을 에이전트에게 맡기고, 무엇을 스스로 판단할지 가르는 능력입니다. 북키핑은 맡기더라도, 무엇을 읽고 무엇을 물을지는 내가 결정해야 합니다. 결국 그 판단의 질이 위키의 깊이로 이어질 거고요. 이 글을 쓰고 나니 오랜만에 노션 위키를 다시 열어봐야겠다는 생각이 드는데요. 여러분도 나만의 위키를 갖고 계신가요?

<참고>

]]>

4계층 문서 체계로 만드는 AI Driven 쿠버네티스 운영 표준

바이브 코딩(Vibe Coding)이 자연어로 코드를 생성하는 것이라면, 바이브옵스(VibeOps)는 자연어로 인프라를 운영하는 것입니다. 이전 글에서 바이브옵스의 기본 개념과 제미나이 CLI, 클로드 코드를 활용한 기본적인 사용법을 다뤘는데, 이번 글에서는 조금 다른 이야기를 해보려고 합니다.

실제로 진행한 대규모 인프라 변경 프로젝트에서 AI 코파일럿인 Claude Code를 열심히 활용하며 발견한 문제들과 이를 해결하기 위해 자연스럽게 만들어진 4계층 문서 체계(Four-Layer Document Architecture)와 Command Guardrails 패턴을 소개할 예정입니다.

이 구조는 처음부터 설계된 것이 아닙니다. AI와 함께 일하면서 부딪힌 한계를 하나씩 보완한 결과물입니다. 따라서 누구나 자신의 환경에서 점진적으로 도입할 수 있다는 것이 핵심입니다.

AI에게 단순히 명령을 시키는 것이 아니라, AI가 올바르게 행동하도록 구조를 설계하는 방법에 대해 말해 보겠습니다.

문제 인식: 제한된 리소스의 제약

앞서도 저는 이와 유사한 프로젝트를 진행한 적이 있습니다. 24시간 무중단으로 운영하는 중요한 플랫폼의 대규모 변경 작업이었습니다. V1에서 V2로 넘어가는 차세대 프로젝트로 예정된 일이었습니다.

여기에 제약 조건까지 있었습니다. 리소스가 제한적이어서 DevOps/SRE 1명이 DEV와 PROD를 동시에 구축할 뿐만 아니라 운영에 필요한 모든 요소의 배포 설정을 진행해야 했습니다.

쿠버네티스 기반의 플랫폼이었기 때문에, 할 일로는 다수의 노드와 수백 개의 파드, 다수의 Helm 릴리스에 Kafka, Redis 같은 데이터 계층의 전환, 옵저버빌리티 스택 전체 재구축, 수십 개의 알림 규칙과 알림 경로까지 포함되어 있었습니다. 단순 복제가 아니라 아키텍처 현대화를 포함하는 전면 재설계 작업이었습니다.

전통적 접근의 한계

전통적인 DevOps/SRE 워크플로우는 Wiki를 읽고, 터미널에서 수작업을 하고, 결과를 다시 Wiki에 기록하는 순서로 진행됩니다. 그런데 여기에는 문제가 있습니다.

IaC(Infrastructure as Code)는 선언적이지만 상황에 따른 판단은 하지 못합니다. 한편 Runbook은 상황마다 달라서 그대로 실행하기 어렵고, 자동화 스크립트는 그 자체의 유지보수가 또 다른 부담이 됩니다. 그래서 이런 질문을 던졌습니다.

만약 runbook을 이해하고, 상황에 맞게 판단하고, 실행까지 하는 동료가 있다면 어떨까?

그에 대한 답으로 Claude Code를 전면에 활용하기로 결정했습니다. 규모가 큰 프로젝트라서 AI를 쓴 것이 아니라 제한된 리소스라는 제약 속에서 AI를 동료로 삼는 방법을 찾아야 한 것입니다.

4계층 문서 체계의 탄생

이러한 협업을 위해 만든 4계층 문서 체계는 처음부터 설계된 것이 아닙니다. 단계마다 AI의 한계를 발견하고, 그 한계를 보완하기 위한 계층을 하나씩 추가하면서 자연스럽게 진화한 결과입니다. 각 계층이 왜 필요해졌는지를 순서대로 살펴보겠습니다.

Layer 1: work-plans, 사람이 읽는 계획서

가장 먼저 만든 것은 사람이 읽고 판단하기 위한 상세 계획서입니다. 한국어로 쓰며, 각 컴포넌트의 Why, How, 트레이드오프를 문서화합니다.

work-plans/
├── 00-main/              # 마스터 플랜 + DEV/PROD 런북
├── 10-infrastructure/    # EKS, 스토리지, AWS 연동
├── 20-platform/          # Prometheus, Loki, Tempo, ArgoCD
├── 30-data/              # Valkey, Kafka, Kafka Streams
├── 40-transition/        # 무중단 전환, Weighted Routing
└── 90-future-projects/

이 문서를 AI에게 그대로 주면 어떻게 될까요? 너무 길고, 맥락이 많고, 한국어와 영어가 섞여 있으니, AI가 핵심을 놓치거나 엉뚱한 부분에 집중하는 현상이 발생했습니다. 사람이 보는 문서와 AI가 보는 문서는 달라야 한다는 것을 깨달았습니다.

Layer 2: claude-context, AI를 위해 증류한 문서

그래서 work-plans의 핵심만을 영어로, 최소한 증류(distill)한 문서를 만들었습니다. AI가 프로젝트 상태를 즉시 파악하는 대시보드 역할을 합니다.

claude-context/
├── 00-project-summary.md     # 프로젝트 1페이지 요약
├── 01-environment-values.md  # 모든 환경 값 (복붙 가능)
├── 02-document-map.md        # 문서 네비게이션 맵
├── 03-current-status.md      # 현재 배포 상태 (라이브)
└── 99-execution-guide.md     # 실행 순서 + 체크리스트

work-plans가 교과서라면 claude-context는 시험 범위 요약노트에 가까운 느낌입니다.

다만 여전히 문제는 있었습니다. AI가 맥락은 이해하는데, 실행할 때 자기 나름대로 명령어를 만들어냈습니다. 예를 들어 “Loki 설치해줘”라고 하면 AI가 helm install 명령을 자체 생성하는데, 버전이 다른데다 values는 누락되고 네임스페이스가 틀리는 일까지 발생했습니다. AI가 이해하는 것과 올바르게 실행하는 것은 다른 문제였습니다.

Layer 3: command-guardrails, AI의 행동 제어

이 계층이 이 글의 핵심인 Command Guardrails 패턴입니다. 각 파일은 단계별 실행 가이드로, 마크다운 안에 bash 블록을 포함하고 있습니다.

command-guardrails/
├── dev/
│   ├── 00-prerequisites/    # KMS, S3, EFS
│   ├── 10-infrastructure/   # EKS, 노드그룹, 애드온
│   ├── 20-platform/         # Helm (Prometheus, Loki...)
│   ├── 30-data/             # Valkey, Kafka
│   ├── 40-transition/       # 알림, 도메인, 트래픽 전환
│   └── 80-rollback/         # 롤백 절차
└── prod/
    └── (동일 구조, PROD 값 + DEV 교훈 반영)

핵심 설계 원칙은 이렇게 잡았습니다. 기존 V1을 보호하며, get, describe, logs만 허용하고, 순서를 00에서 10, 20, 30, 40으로 강제합니다. 즉, AI 시대의 인프라 문서는 사람이 읽는 문서가 아니라, AI가 실행하는 문서라고 정의한 것입니다.

하지만 문제는 하나 더 있었습니다. Guardrail에 helm upgrade prometheus-stack만 적으면 AI가 --set 플래그를 창의적으로 만들어냈습니다. 경우의 수가 폭발하니 재현할 수 없는 배포가 되었습니다.

Layer 4: helm-values, IaC에 가까워진 계층

이 계층은 실제 사고를 2건 겪고 나왔습니다.

사고 1: Mimir 버전 업그레이드

guardrail 문서에 helm upgrade mimir만 적고 --version을 지정하지 않은 일이 있었습니다. AI는 지시를 그대로 실행했고, chart 5.8.0 환경에서 최신 6.0.5로 자동 업그레이드가 됐습니다. Mimir 6.0에는 Kafka 기반 ingest storage 기본 활성화, Nginx 제거 후 Unified Gateway 교체, Rollout-operator 웹훅 기본 활성화라는 세 가지 breaking change가 있어서 기존 5.x의 --set 값들이 6.x 스키마와 맞지 않으면서 ingester, distributor 파드가 전부 CrashLoopBackOff에 빠졌습니다.

이에 맞춰 다시 6.0으로 올리려면 ingest storage 구성, gateway 마이그레이션, CRD 사전 설치까지 한꺼번에 해야 하는데, 1인 DevOps/SRE가 DEV+PROD 동시 구축하는 상황에서 감당할 수준이 아니었습니다.

그래서 helm rollback으로 복구한 다음 5.8.0으로 버전을 고정하고 진행했습니다. 이 사고에서 얻은 교훈이 Layer 4입니다. --version 5.8.0, -f helm-values/mimir.yaml로 버전도 값도 파일로 고정해서 AI에게 해석의 여지를 없앴습니다.

사고 2: 알림 규칙의 false alarm

AI에 “CPU 사용률 80% 넘으면 알림 만들어줘”라고 지시했더니, Grafana alert rule의 relativeTimeRange을 600초(쿼리 범위 10분), for를 5분(조건 지속 시간)으로 설정했습니다. 10분 범위 안에 순간 스파이크가 하나만 찍혀도 조건이 충족되고, 그 스파이크가 윈도우 안에 남아 있는 동안 5분이면 바로 firing이 됩니다.

배포 직후 파드 스케일링 때마다 CPU가 잠깐 튀면서 새벽에도, 배포할 때도 알림이 울렸습니다. 게다가 AI가 같은 패턴으로 알람을 생성했기 때문에, 7개 규칙이 전부 같은 문제를 가지고 있었습니다. 문제를 해결하기 위해 relativeTimeRange을 300초로 줄이고, for를 10분으로 늘리고, 쿼리를 avg_over_time으로 바꿔서 수정했습니다.

여기서 얻은 교훈은, 알림 파라미터도 Guardrail 본문에 쓰면 안 된다는 겁니다. AI는 합리적으로 보이는 값을 만들어내지만, 그게 운영 환경에서 맞는지는 별개 문제이기 때문입니다. 그래서 알림 임계값, 평가 주기, for 기간 같은 파라미터를 전부 helm-values 파일로 빼서 관리하게 됐습니다.

최종적으로 helm 명령어는 다음과 같은 형태가 되었습니다.

helm upgrade loki grafana/loki \
  --version 6.30.0 \        # 버전 고정
  -f helm-values/loki.yaml \ # 값 고정 (IaC)
  -n monitoring \            # 네임스페이스 고정
  --wait --timeout 10m       # 동작 고정

이렇게 4개의 계층이 완성되었습니다. 정리하면 위에서 아래로 갈수록 추상에서 구체로, 자유도는 감소하되 재현성은 증가하는 구조입니다.

<출처: 작가>

Tip. 왜 AI를 위한 문서는 영어로 증류해야 하는가

4계층 체계에서 주목할 점 가운데 하나는 Layer 2(claude-context)가 영어로 작성된다는 것입니다. 이는 단순히 AI가 영어를 더 잘 이해하기 때문만은 아닙니다.

첫째, 토큰 효율성 문제입니다. 한국어는 영어 대비 동일한 내용을 표현하는 데 더 많은 토큰을 소비합니다. Claude Code의 컨텍스트 윈도우는 유한하기 때문에, 같은 정보를 더 적은 토큰으로 전달하는 영어가 효율적입니다.

둘째, 기술 용어의 일관성 문제입니다. 쿠버네티스 생태계의 용어는 대부분 영어 기반입니다. “노드그룹”과 “nodegroup”, “네임스페이스”와 “namespace”가 혼재되면 AI가 매칭에 실패하는 경우가 있습니다. AI가 읽을 문서에서 기술 용어를 영어로 통일하면 이러한 혼선을 방지할 수 있습니다.

셋째, 명령어와의 직접 연결입니다. AI가 context 문서를 읽고 바로 셸 명령어를 생성해야 하는데, 한국어 설명에서 영어 명령어로 전환하는 과정에서 오류가 발생할 확률이 높습니다. 영어로 작성된 context는 명령어 생성까지의 경로를 짧게 만들어 줍니다.

다만 이러한 제약으로, 모든 문서를 영어로 써야 한다는 의미는 아닙니다. Layer 1(work-plans)은 사람이 의사결정을 위해 읽는 문서이므로 한국어가 적합합니다. 즉, “누가 읽느냐”에 따라 언어를 구분하는 것이 핵심입니다.

CLAUDE.md: AI가 가장 먼저 읽는 행동 규칙

4계층 문서 체계 외에 한 가지 더 중요한 요소가 있습니다. 바로 CLAUDE.md 파일입니다. 이 파일은 Claude Code가 프로젝트 디렉터리에 진입했을 때 가장 먼저 읽는 파일로, AI의 행동 규칙(Ground Rules)을 정의합니다.

이전 글에서 제미나이 CLI의 GEMINI.md를 다룬 적이 있는데, CLAUDE.md도 동일한 역할을 합니다. 차이가 있다면 4계층 문서 체계와 결합되어 더 구조적으로 동작한다는 점입니다.

예를 들어, 실제 운영 환경에서 사용되는 CLAUDE.md는 다음과 같은 규칙을 포함합니다.

# Ground Rules

## 허용되는 명령어
- kubectl get / describe / logs 만 허용
- helm list / helm status 만 허용

## 금지되는 명령어
- kubectl delete / apply / patch 금지
- helm install / upgrade / uninstall 금지

## 문서 참조 순서
1. memory/MEMORY.md를 먼저 읽을 것
2. claude-context/에서 현재 상태 파악
3. command-guardrails/에서 실행 가이드 확인
4. guardrail에 없는 명령은 실행하지 말 것

이렇게 적어 두면 AI가 자기 마음대로 명령어를 만들어내는 것을 막을 수 있습니다. 특히 “guardrail에 없는 명령은 실행하지 말 것”이라는 규칙이 중요한데, 이는 AI가 할 수 있는 행동의 범위를 명확하게 제한해 줍니다.

settings.local.json

여기에 더해서 .claude/settings.local.json을 설정하면 V1 보호를 도구 수준에서 강제할 수 있습니다. CLAUDE.md가 자연어로 된 규칙이라면, settings.local.json은 실제로 명령어 실행 자체를 허용하거나 차단하는 설정입니다.

{
  "permissions": {
    "allow": [
      "Bash(kubectl --context=sysnet4admin-v1 get *)",
      "Bash(kubectl --context=sysnet4admin-v1 describe *)",
      "Bash(kubectl --context=sysnet4admin-v1 logs *)",
      "Bash(kubectl --context=sysnet4admin-v2 *)",
      "Bash(helm --kube-context=sysnet4admin-v2 *)",
      "Bash(aws * --profile sysnet4admin *)",
      "Bash(eksctl * --profile sysnet4admin *)"
    ],
    "deny": [
      "Bash(kubectl --context=sysnet4admin-v1 apply *)",
      "Bash(kubectl --context=sysnet4admin-v1 delete *)",
      "Bash(kubectl --context=sysnet4admin-v1 patch *)",
      "Bash(kubectl --context=sysnet4admin-v1 edit *)",
      "Bash(kubectl --context=sysnet4admin-v1 scale *)",
      "Bash(kubectl --context=sysnet4admin-v1 exec *)",
      "Bash(helm --kube-context=sysnet4admin-v1 install *)",
      "Bash(helm --kube-context=sysnet4admin-v1 upgrade *)",
      "Bash(helm --kube-context=sysnet4admin-v1 uninstall *)",
      "Bash(helm --kube-context=sysnet4admin-v1 delete *)"
    ]
  }
}

V1(sysnet4admin-v1)에는 get, describe, logs만 허용하고, apply, delete, patch 같은 변경 명령은 전부 차단합니다. 반면 V2(sysnet4admin-v2)에는 모든 명령을 허용해서 자유롭게 작업할 수 있도록 합니다. 이렇게 하면 CLAUDE.md에서 자연어로 안내하는 규칙을 설정 파일이 실제로 강제하게 되므로, AI가 실수로라도 V1 프로덕션에 변경을 가하는 것을 방지할 수 있습니다.

4계층 문서에 기반한 운영 전략과 도입 방법

이처럼 계층 문서 기반으로 인프라 관리에 접근하다 보니 다양한 변화를 만날 수 있었습니다. AI와 함께 일하며 확장할 수 있는 방향성과 실제 도입 과정에서 느낀 것을 정리했습니다.

1. GitAIOps

이렇게 만들어진 4계층 문서 체계를 Git으로 관리하면 재미있는 부분이 생깁니다. AI를 위해 만든 문서가 동시에 팀 전체의 운영 표준이 되는 것입니다.

이 개념을 GitAIOps라고 부릅니다. GitOps가 선언적 인프라에서 Git을 Single Source of Truth로 삼는 것이라면, GitAIOps는 여기에 AI가 문서를 이해하고 실행하는 계층을 추가한 것입니다. 누가 실행해도 같은 결과가 나오니 일관성이 보장되고, 변경 이력이 남으니 감사 추적이 가능합니다.

2. AI에게 맡기는 것의 경계

4계층 문서 체계를 구축했다고 해서 모든 것을 AI에게 맡길 수 있는 것은 아닙니다. 오히려 이 체계를 운영하면서 AI에게 맡기기 좋은 것과 사람이 판단해야 하는 것의 경계가 더 명확해졌습니다. 무엇보다 AI는 자동 운전이 아니라 운전 보조라는 것을 잊지 말아야 합니다. 핸들은 사람이 잡되, 사각지대를 AI가 잡아준다는 느낌으로 써야 합니다.

3. DEV에서 PROD로: Guardrail 재사용 패턴

4계층 체계가 가장 효과적인 부분은 DEV에서 PROD로 넘어갈 때입니다. DEV에서 검증된 Guardrail을 PROD에 재사용할 때, 단순 복사가 아니라 DEV에서의 교훈을 반영하는 것이 핵심입니다.

실제로 PROD Guardrail에는 DEV 교훈이란 섹션이 자동으로 추가됩니다. 예를 들어 DEV에서 Mimir 버전 사고가 있었다면, PROD Guardrail에는 해당 버전 고정에 대한 경고와 함께 검증된 버전 번호가 명시됩니다. DEV 환경 전체 구축에 약 2일이 걸렸다면, 이 Guardrail을 재사용하는 PROD 환경 구축은 약 1일로 단축됩니다.

이렇게 Guardrail이 축적되면 재사용할수록 구축 속도가 빨라집니다. 그리고 이 패턴은 쿠버네티스에만 적용되는 것이 아닙니다. Terraform, Ansible 등 어떤 IaC 도구를 사용하더라도 동일한 구조를 적용할 수 있습니다.

4. 생산성 변화

직접 AI 기반 운영을 도입하니 아래와 같은 생산성 변화가 일어났습니다. AI가 사람을 대체한 게 아니라, 제한된 리소스의 커버리지를 몇 배로 확장했다는 점을 가장 크게 느꼈습니다.

5. 조직에 적용할 점진적 도입 로드맵

이러한 구조를 우리 조직에 한 번에 도입할 필요는 없습니다. 그보다는 단계적으로 조금씩 접근하는 것이 현실적입니다.

Level 0 (1주):기존 runbook을 구조화된 마크다운 형식의 문서로 정리합니다. 이것만으로도 문서 가독성이 크게 향상됩니다.
Level 1 (2~4주):Claude Code로 DEV 환경에서 실험을 시작합니다. 이전 바이브옵스 글에서 다룬 것처럼, 먼저 DEV에서 충분히 테스트하는 것이 중요합니다.
Level 2 (1~2개월):Context + Guardrails 2계층 체계를 구축합니다. 실제 운영에서 발생하는 문제들을 반영하면서 점진적으로 완성합니다.
Level 3 (지속):DEV에서 PROD로의 패턴이 정착되고, helm-values(IaC)가 추가됩니다. 이 단계에서는 guardrail이 팀의 표준 운영 절차(SOP)가 됩니다.

마치며: DevOps/SRE의 역할 변화

이 글에서 다룬 4계층 문서 체계와 Command Guardrails 패턴을 보면, DevOps 엔지니어와 SRE의 역할이 바뀌고 있다는 것을 알 수 있습니다.

전통적인 DevOps/SRE가 kubectl을 직접 실행하는 사람이었다면, AI-Driven DevOps/SRE는 AI가 실행할 가이드를 설계하는 사람입니다. Runbook을 작성하던 역할은 Guardrails를 설계하는 역할로, 수동으로 감사하던 역할은 AI가 감사한 결과를 검증하는 역할로 바뀝니다. 반복 작업을 수행하는 대신 판단과 의사결정에 집중하게 되고, 혼자 환경 하나만 담당하던 것이 혼자 환경 N개를 커버할 수 있게 됩니다.

AI가 잘하는 것은 최대한 활용하되, 실행에서 틀리지 않도록 구조로 잡아주는 것. 그것이 4계층 문서 체계와 Command Guardrails 패턴이 하는 일이며, 얻어가야 할 교훈입니다.

부록 1: AI의 기억 관리를 위한 Memory 시스템

4계층 문서 체계를 운영하다 보면 자연스럽게 마주치는 문제가 하나 더 있습니다. Claude Code와 긴 대화를 나누다 보면 컨텍스트 압축(compaction)이 발생한다는 것입니다.

예를 들어 35개 알림 규칙을 전수 분석해서 P0/P1/P2로 분류했는데, compaction이 발생하면 원본이 사라지고 “P0/P1/P2 분류 완료”라는 요약만 남습니다. 이 상태에서 “P1 항목이 뭐였지?”라고 물으면 AI는 대답할 수 없게 됩니다.

이 문제를 해결하기 위해 4계층과 동일한 원리를 적용한 memory 시스템을 도입했습니다.

memory/
├── MEMORY.md              # 인덱스 (200줄, 자동 주입)
├── alert-gap-analysis.md  # 토픽 파일 (필요 시 로드)
├── osd-lessons.md         # 토픽 파일 (필요 시 로드)
└── argocd-lessons.md      # 토픽 파일 (필요 시 로드)

시스템이 하는 역할은 크게 4가지입니다. compaction에서 살아남는 맥락 보존, “하지 마라”를 축적한 금지 사항 누적(guardrail 보완), 대화가 끊어져도 이어지는 작업 상태 추적, 그리고 매 세션마다 재탐색 없이 시작하는 콜드 스타트 방지입니다.

여기서 중요한 것은 MEMORY.md의 크기 관리입니다. AI 코딩 에이전트에는 200줄을 초과하면 경고 없이 잘려나가는(hard truncation) 현상이 있고, 오래된 기억은 때로 AI가 잘못된 근거로 판단하는 원인이 됩니다. 실제로 지시 준수율이 200줄 이하에서는 92%인데, 400줄 이상이 되면 71%로 떨어지는 것을 확인했습니다.

따라서 MEMORY.md는 인덱스만 유지하고, 상세 내용은 토픽 파일로 분리합니다. 결국 4계층과 같은 원리입니다. 증류하고, 분리해서, 필요할 때만 로드하기. 이 원칙은 문서 체계뿐 아니라 AI의 기억 관리에도 동일하게 적용됩니다.

부록 2: 옵저버빌리티 감사 데모로 직접 해보기

이 글에서 설명한 구조를 축소해서 직접 체험해볼 수 있는 데모도 준비했습니다. 읽기 전용 감사(Observability Audit)를 수행하는 구성으로, 4계층 중 실행에 해당하는 부분만 뽑아낸 형태입니다.

demo/
├── CLAUDE.md                    # AI 행동 규칙
├── claude-context/
│   └── 00-cluster-summary.md    # 클러스터 맥락
├── command-guardrails/
│   └── observability-audit.md   # 실행 가이드
└── memory/
    └── MEMORY.md                # 누적 기억

데모를 실행하면 CLAUDE.md에서 READ-ONLY만 허용하고, command-guardrails의 9단계 감사 절차를 AI가 순서대로 실행한 다음, 결과를 Audit Report 형식으로 출력합니다. 실제 감사 리포트 결과와 전체 소스는 GitHub에서 확인할 수 있습니다.

작가

조훈(CNCF 앰버서더)

메가존에서 쿠버네티스와 컨테이너 인프라 Tech Evangelist, CoE(Center of Excellence) 역할을 맡고 있다. 클라우드 네이티브 컴퓨팅 재단(CNCF)의 글로벌 앰버서더, ‘IT 인프라 엔지니어 그룹’의 운영진, 오픈소스 컨트리뷰터로도 활동하고 있다. 인프런/유데미에서 앤서블 및 쿠버네티스에 관한 강의를 하고, 『컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커』, 『우아하게 앤서블』, 『시스템/네트워크 관리자를 위한 파이썬 실무 프로그래밍』을 집필하였으며, 요즘IT와 같은 온라인 플랫폼에 글을 기고한다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

글로벌 소셜 플랫폼 기업에서 Site Reliability Engineer로 재직하며, 쿠버네티스 멀티 클러스터 관리와 데이터베이스 플랫폼 운영을 주도하고 있다. 또한 ISMS-P, GDPR, CCPA 등 글로벌 보안 규제에 부합하는 데이터 라이프사이클 파이프라인을 설계·운영한 실무 경험을 가지고 있으며, 쿠버네티스 오픈소스 프로젝트에도 기여하고 있다. 더불어 국내 주요 기업과 국가 기관의 클라우드 전환, 데이터 거버넌스 컨설팅, 보안 컴플라이언스 대응을 지원하고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.

]]>

AI 에이전트 많이 만든다고 AX가 아니다

에이전트에 대한 관심이 갈수록 높아지고 있지만, 막상 현장에서 AX를 추진하는 분들의 이야기를 들어보면 트렌드와 현실 사이에 적잖은 간극이 있습니다. 에이전트를 만들었다고는 하지만 "살림살이가 나아졌나?"라는 질문에 명확한 답을 내놓는 곳은 많지 않고, 성공 사례도 1인 사업가나 소규모 스타트업에 집중되어 있죠. 엔터프라이즈에서는 더욱 쉽지 않은 과제인데요. 직접 조직에 AI를 도입하고, AX 사업을 통해 다른 기업의 AI 전환을 도우며 체감한 엔터프라이즈 AX의 구조적 딜레마를 짚은 발표가 있어 소개합니다. 현장에서도 많은 공감을 얻은 발표인 만큼, 조직의 AX를 고민하는 분들께 참고가 되실 겁니다.

*이 발표는 2026년 4월 8일 채널톡이 후원한 <AX 리얼 비즈 케이스 스터디 라운드 테이블 1회>에서 진행됐습니다.

컨설팅 15년, 현업 7년, AX 사업 3년차 전문가가 본 엔터프라이즈 AX의 현실과 딜레마
by 주형민 원티드랩 AX 사업 총괄

안녕하세요, 원티드랩에서 AX 사업을 총괄하고 있는 주형민입니다. 액센추어, EY 등에서 약 15년간 엔터프라이즈 컨설팅을 했고, 산업 현장에서 7년간 혁신을 리딩했습니다. 원티드랩은 ‘원티드’라고 하는 약 385만 유저를 보유한 채용 플랫폼을 운영하고 있는데, 저는 HR이 아니라 AX 사업을 새로 만들기 위해 합류했습니다. 원티드 AX 사업은 현재 3년째 진행되며, AI 에이전트 운영 플랫폼 엔노이아(Ennoia), 교육, 에이전트 개발 생태계의 세 축으로 기업의 AI 전환을 지원하고 있고, 4곳에서 AX 자문위원을 맡고 있습니다.

주형민 원티드랩 AX 총괄 <출처: 채널톡>

엔터프라이즈 현장에 오래 있었기 때문에, 오늘은 그 관점에서 AX를 어떻게 받아들여야 하는지에 대해 이야기해 보려 합니다.

다만 본격적으로 들어가기 전에, 하나 질문을 던지고 싶습니다. 성공적인 AX란 어떤 모습일까요? 우리 기업이 AX를 통해 변화한 모습을 구체적으로 그려보신 적 있으신가요?

성공적인 AX의 모습을 상상할 수 있는가

아마 그런 경험이 있는 분은 많지 않을 겁니다. 현재 AX에 대한 논의는 대부분 추상적인 수준에 머물러 있습니다.

기술 트렌드라는 것이 원래 그렇습니다. 빅테크 중심으로 형성되거든요. 클라우드도 그랬고, 빅데이터도 그랬고, RPA도 그랬습니다. "이렇게 변해야 합니다"라는 메시지와 함께 트렌드가 만들어지고, 기업들이 따라가는 구조죠. 지금의 AI 역시 마찬가지입니다.

그런데 생성형 AI가 제공하는 가치의 본질을 잘 봐야 합니다. 기존의 분석형 AI는 과거 데이터를 기반으로 미래를 예측하고, 이상 패턴을 탐지하고, 클러스터링을 통해 새로운 정보 집단을 찾아내는 것이었습니다. 반면 생성형 AI의 본질은 '증강'입니다. 변환하고, 증강하고, 더 빠르게 만들어내는 것. 기존의 분석형 AI가 풀던 예측 문제에 획기적인 기여를 하고 있느냐 하면, 저는 그렇지 않다고 봅니다.

결국 지금 AI 시대가 기업에 주는 것은 "결과물을 빠르게 만들어서 서비스를 출시할 수 있는 능력"입니다. 그런데 대부분의 기업이 그 능력을 갖추게 된다면, AX를 성공적으로 했다는 것은 무엇을 의미할까요. 뒤처지지 않는 정도의 수준에 도달했다는 뜻에 가깝습니다. 차별화라기보다는 기본값이 되는 셈이죠.

여기서 아직 아무도 하지 못하는 이야기가 있습니다. "AX 잘했더니 돈을 엄청 벌었다." 이 말을 할 수 있는 기업이 지금 시장에 잘 보이지는 않는 것 같습니다.

현재 수익을 올리고 있는 쪽은 누구입니까. Claude를 만드는 Anthropic이나 OpenAI 같은 플랫폼 사업자들입니다. 적자라고는 하지만, 결국 카지노의 주인장과 같은 위치에 있어요. 지금은 치킨게임이지만, 나중에 독점이 형성되면 토큰 비용 구조가 바뀌면서 그들이 최종 승자가 될 수도 있습니다.

AX는 해야 합니다. 성공적으로 잘 해야 한다는 데 동의합니다. 다만 AX를 잘했을 때 우리 기업의 모습은, 물론 비즈니스 경쟁력이긴 하지만 그 차별화의 강도가 비교적 약합니다. 이 화두를 먼저 던져놓고, 하나씩 들어가 보겠습니다.

AI 도입 속도는 빨라졌지만, 검증은?

가트너의 Top 10 Strategic Technology Trend를 보면 흐름이 읽힙니다. 2025년에는 Agentic AI가 등장했고, 거버넌스 플랫폼에 대한 논의가 시작됐습니다. 그리고 주목할 것은 '디지털 프로비넌스(Digital Provenance)', 즉 데이터 신뢰성에 대한 본격화되기 시작했다는 점입니다.

가트너 Top 10 Strategic Technology Trend 재가공 <출처: 주형민 원티드랩 AX 총괄 발표자료>

그런데 지금 현장의 분위기는 그 방향이 아닙니다. 신규 기술에 대한 소개의 기세가 너무 강해서, 완전히 공격적으로 앞으로 달려나가는 것에 몰두해 있는 분위기입니다.

하이프사이클을 떠올려 보면 감이 올 겁니다. 관심도가 급격히 올라갔다가 환멸의 골짜기로 내려가는 구간은 반드시 찾아옵니다. 그때가 되면 생성형 AI가 만들어 낸 결과물의 신뢰성 확인에 대한 요구가 급증할 거예요. 에이전트가 잘못 판단한 것 하나가 큰 사고로 이어지고, 그 사고가 언론에 보도되는 순간 지금의 기세는 상당히 꺾일 수 있습니다.

가트너 하이프사이클 <출처: Jeremykemp, 위키백과>

문제는 그때 돌아보면, 우리가 쓰고 있는 AI가 내놓은 결과물을 실제로 꼼꼼하게 검증하려 해도, 이미 양이 너무 많아서 체크가 어려운 상황이 벌어진다는 점입니다. 지금도 이미 그렇고, 폭주가 시작되면 더 어려워집니다.

엔터프라이즈 입장에서 가장 큰 고민은 따로 있습니다. 기업 내부에서는 보안이 중요하고, 내부 코드가 밖으로 유출되면 안 됩니다. 그런데 외부에 있는 신기술을 내부에서 어떻게 활용할 수 있느냐, 이것이 가장 큰 과제입니다. 폐쇄된 환경에서 최신 기술을 얼마나 효과적으로 쓸 수 있는가. 그 기술 도입을 교육부터 트레이닝, 문화 형성, 그리고 에이전트가 기존 워크플로우를 대체하는 단계까지 끊김 없이 이어갈 수 있는가. 이것이 대부분의 AX 담당자가 직면하는 고민입니다.

그런데 경영진의 관점은 다릅니다. "그래서 살림살이 나아졌냐?" "그거 해서 돈 벌었나?" 하는 것이 중요하죠. 대부분의 기업이 가장 먼저 하는 것이 챗봇 도입이고, 그것을 근거로 비용을 줄였다고 이야기합니다. 그런데 실제로 인건비가 줄었느냐 하면, 그것도 아닌 것 같습니다. 사람은 그대로 있거든요.

결국 엔터프라이즈가 챙겨야 할 것은 세 가지입니다. 보안, 지속적인 혁신, 그리고 기업 최적화. 이 세 가지를 현재의 기술 환경에서 어떻게 이식해 갈 것인지가 핵심인데, 지금은 혁신 쪽으로만 기세가 쏠려 있고 나머지 두 가지는 뒤로 밀리고 있는 상황입니다.

바이브 코딩, 엔터프라이즈에서 조심해야 하는 이유

바이브 코딩 이야기를 좀 해보겠습니다. 솔직히 저는 '딸깍'이라는 표현을 별로 좋아하지 않습니다.

바이브 코딩과 관련해 납득하기 어려운 주장이 몇 가지 있습니다. 그중 하나가 "나중에는 코드를 안 봐도 된다"는 것입니다. 대기업에서는 감사나 코드 검수가 들어올 수 있습니다. 사고가 발생했을 때 코드의 근거를 추적할 수 없다면, 그 영향 범위는 상당히 커질 수밖에 없어요.

바이브코딩으로 개발한 소프트웨어를 엔터프라이즈 내부에 이식하기는 현실적으로 어렵다는 설명 <출처: 주형민 원티드랩 AX 총괄 발표자료>

핵심적인 문제는 이것입니다. 외부에서 바이브 코딩으로 만들어진 코드를 기업 내부 IT 유지보수 담당자가 인수할 수 있느냐는 거예요. 문제가 생겨서 보완을 요청했을 때 제대로 대응이 가능할 것인지, 제도적 관점에서 아직 정비가 안 된 부분이 많습니다.

과거에는 정확도(Accuracy) 100%를 기반으로 서비스를 제공했습니다. 소비자들은 그 신뢰성 위에서 서비스를 이용하고 있었어요. 그런데 지금은 "AI는 대부분 잘 해낼 것이고, 약간의 실수는 있을 수 있지만 소비자들도 결국 따라올 것이다"라는 논리가 나옵니다. 저는 이 논리에 동의하기 어렵습니다. 100%의 신뢰성을 기반으로 서비스를 제공해 오다가, AI 때문에 다소 부족하더라도 받아들이라는 것이 현재 시장에 맞는 접근인지 의문입니다.

한편으로 AI 네이티브 컴퍼니의 실체에 대한 질문도 있습니다. 약 1년 전에 알게 된 한 회사 대표님의 고민은 "우리 회사 직원이 아무도 없다고 가정하고, 에이전트로 전부 로직을 설계 한 후에, 그것을 통제할 수 있는 최소 인력이 몇 명인지 컨설팅해 달라." 몇백 명 규모의 회사에서, 최소 인원으로 이것이 동작할 수 있는지를 검토하는 것입니다. 실제 현장에서 지금 이런 일이 벌어지고 있어요.

그런데 대기업에서는 상황이 다릅니다. AI로 효율화가 된다고 해서 "중요한 일에만 집중하겠다"고 하지만, 중요한 일이란 대부분 인지적 부하가 높은 업무입니다. 단순 업무가 빠진 자리에 고강도 의사결정만 남으면, 오히려 번아웃이 찾아옵니다. 이론적으로는 이해가 되지만, 실제 현장에서 그대로 작동하지 않는 부분이 분명히 있어요.

이에 대해 1인 기업의 성공 사례를 보여주시는 분들도 많습니다. 하지만 실제로 그 방식으로 사업을 지속하고 있는 경우는 많지 않아요. 사례로서는 인상적이지만, 그것을 엔터프라이즈에 그대로 적용하기에는 구조적으로 다른 문제가 있습니다.

결국 저는 기존의 책임 체계가 유지될 수밖에 없다고 봅니다. 에이전트가 잘못 판단하면 누군가 책임져야 하니까요. 그 구조는 바뀌지 않습니다.

AI 교육만으로는 부족하다: 실행 환경이 필요한 이유

그렇다면 이런 현실 속에서 기업은 AX를 어떻게 풀어가야 할까요. 저희도 같은 고민을 하면서 직접 부딪혀 봤습니다. 그 과정에서 가장 먼저 마주한 문제가 교육이었습니다.

대부분의 기업이 비슷한 고민을 하고 있을 것 같은데요, 교육 자체에 너무 많이 투자하는 경향이 있습니다. 교육에 투자하고, 환경을 잘 만들어 주는 것까지는 신경을 쓰지만, 정작 배운 것을 현장에 적용하지 못합니다. 부문 교육하고, 임원 교육하고, 결과적으로 개인 생산성만 좋아지는 거예요. 퇴근만 빨라지는 셈이죠.

토큰 이코노미라고 하면 토큰을 많이 쓸수록 수익으로 연결돼야 하는데, 이 연결고리가 끊어져 있습니다. 교육을 받고 나서 혼자 적용해 보다가 중간에 막히면 해결하지 못하는 경우가 너무 많았고, 뭔가 만들긴 했지만 실무와 동떨어진 결과물만 쌓이는 상황도 빈번했습니다.

그래서 저희가 초반에 잡은 방향은 이것입니다. ‘가르치는 것보다 직접 찾고 실행할 수 있는 환경을 만드는 데 집중하자’. 강의 자체보다 자기 업무에서 문제를 정의하고 해결해 나가는 것이 중요하다고 봤습니다. 수료했다고 AX 전문가가 되는 것은 아니잖아요. 수료하고 돌아왔는데 현장에 변화가 없으면 의미가 없습니다.

이런 생각으로 저희는 세 단계의 체계를 만들었습니다.

1단계: AI를 많이 쓸 수 있는 환경 조성

우선 AI를 적극적으로 쓸 수 있도록 환경을 열어줬습니다. 저희도 교육비가 1인당 연간 약 100만 원 정도 되는데, 기존에는 외부 교육에 다녀와서 전달 교육하는 방식이었거든요. 그런데 그 방식은 활용으로 잘 이어지지 않더라고요. 그래서 어떤 도구든 자유롭게 쓰라고 개방했더니 다들 쓰기 시작했습니다. 도구에 대한 접근성이 좋아진 겁니다.

내부에 'AI줍줍'이라는 사례 공유 채널도 운영하고 있는데, 3월 한 달에만 약 75건의 게시물이 올라왔습니다. 하루 평균 3~4건입니다. 새로운 사례, 직접 해본 경험을 계속 공유하는 것이죠. 직원이 약 160명 정도 되는데 상당히 활발하게 돌아가고 있고, 우수 사례에 대한 시상도 진행합니다. 대표부터 채용사업팀, 후보자 경험팀, PR팀까지 다양한 부서에서 자기가 만든 것을 올리는 문화가 자리 잡혔어요.

2단계: AI 챔피언 양성

챔피언 제도를 만들어서 20명씩 두 달 동안 집중 트레이닝을 진행합니다. 한 곳에 모여 팀을 구성하고, 내부의 실제 업무 문제를 함께 해결하는 방식입니다. 특정 업무 시간을 확보해 결과물을 만들고, 공유하고, 바로 업무 시스템에 반영합니다. 격주 오프라인 모임에서는 참여자들이 직접 발표도 합니다. 재무 부서에서 카드 전표 처리를 자동화한 사례 같은 것들을 공유하는 거죠.

원티드랩 AX 챔피언 프로그램 1기 성과. <출처: 주형민 원티드랩 AX 총괄 발표자료>

핵심 운영 원칙은 이렇습니다. 본인이 직접 문제를 해결하고, 서포터즈가 옆에서 바로 지원하고, 직무나 연차에 관계없이 누구나 참여할 수 있도록 열어두는 것. 3기까지 운영하면 전체 직원의 약 3분의 1이 이수하게 됩니다. 6개월 만에요. 1기 때 추천 의향이 5점 만점에 4.8이 나올 정도로 만족도가 높았고, 비개발자분들이 빠른 속도로 자동화를 만들어내면서 개발자가 긴장하는 현상도 나타났습니다. 개인이 만든 도구가 팀 전체의 워크플로우를 바꾼 경우도 있었어요.

재미있었던 것은 경영진의 반응이었습니다. 저희 대표가 새벽 2~3시까지 클로드 코드로 이것저것 만들다가 클로드 사용량 제한에 걸려 "2시간만 참자, 굿나잇 클로드"라고 슬랙에 올린 적도 있을 정도로 적극적으로 활용했습니다. 바이브코딩으로 만든 결과물을 적극적으로 공유하고, 만들면서 느낀 점도 기록했죠. 경영진이 그 정도로 직접 쓰고 있으면, 주변 임원급의 수준도 자연스럽게 올라갑니다. 자연스럽게 임원들을 비롯한 리더들도 AI 활용을 더욱 적극적으로 하게 되면서 조직이 움직이는 모습을 보게 됐습니다.

3단계: 실행 생태계 조성

깃허브에 '백야드(Backyard)'라는 내부 배포 공간을 별도로 마련했습니다. 외부에 배포하기 어려운 도구들을 올릴 수 있는 곳이에요. 스킬 허브도 구축해서 필요한 기능을 선택해 바로 사용할 수 있게 하고, 보안 점검용 코드 스캐닝 스킬도 포함시켰습니다. 자체 디자인 시스템도 MCP(Model Context Protocol, AI 모델이 외부 도구나 데이터와 연결되는 표준 프로토콜)로 연결해서, 클로드 코드에 "우리 디자인 시스템에 맞춰 줘"라고 하면 바로 적용되는 환경을 갖추고 있습니다.

원티드랩 백야드와 MCP <출처: 주형민 원티드랩 AX 총괄 발표자료>

현장에서 나온 사례도 인상적이었습니다. 총무 담당자가 2만 원짜리 바코드 리더기를 구입해서, 프롬프트 편집과 API 연결만으로 도서 반납 자동화 시스템을 구축한 거예요. 바코드를 스캔하면 구글 시트에 자동 등록되고, 슬랙으로 알림이 오는 구조입니다. HR에서는 '피플이'이라는 에이전트를 만들어 업무 환경에 자연스럽게 통합해 놓았고, 사업 부서에서는 모니터링과 기사 수집을 멀티 에이전트로 자동화해서 슬랙으로 수신하고 있습니다.

여기서 중요한 전환점이 있었습니다. 이렇게 여러 에이전트를 만들다 보니, 생성형 AI는 전통적인 IT와 개발·운영 방식이 근본적으로 다르다는 것을 체감하게 됐어요. 할루시네이션(AI가 사실이 아닌 정보를 생성하는 현상) 문제가 있고, CI/CD(지속적 통합·배포) 관점에서 빠르게 통합하고 반영해야 하는데 기존의 배포 절차로는 대응이 어려운 부분이 많았습니다. 여러 LLM을 유연하게 전환하며 사용하고, 모든 로그를 기록하고, 튜닝할 수 있는 기반이 필요했어요.

그래서 자체 플랫폼을 만들기 시작했고, 그것이 엔노이아(Ennoia)로 고도화됐습니다. 엔노이아는 기업이 원하는 업무를 AI 에이전트로 구현하고 운영할 수 있게 지원하는 플랫폼입니다. 저희가 지향한 것은 현업의 모든 임직원이 직접 활용할 수 있어야 한다는 것이었습니다.

4월 15일 원티드랩이 출시한 엔터프라이즈 최적화 AI 에이전트 플랫폼 ‘엔노이아(ennoia)’는 기업이 원하는 업무를 AI 에이전트로 구현하고 운영할 수 있게 지원하는 플랫폼이다. <출처: 원티드랩>

다만 실행 환경을 구축했다고 해서 모든 것이 해결되는 것은 아닙니다. 저희도 제품 개발 프로세스를 압축하려는 시도를 하고 있어요. 기존에는 PO(Product Owner, 제품 기획자)가 기획하고, PD(Product Designer, 제품 디자이너)가 피그마로 디자인하고, 프론트엔드 개발자가 구현하고, 백엔드로 넘기고, QA를 거쳐 배포하는 구조였는데, 이것을 일주일 단위로 줄여보려 하고 있습니다. 기존에는 2주 단위로 누적 배포하던 체계였거든요.

그런데 이것이 실제로는 매우 어려운 일입니다. 기차를 떠올려 보시면 됩니다. 앞부분이 시속 100km로 가는데 중간 칸이 30km로 가면 어떻게 될까요. 어느 한 구간만 빨라진다고 전체 실행 속도가 빨라지지 않습니다. 100km로 가는 바퀴 옆에 30km짜리 바퀴가 달려 있으면 마찰이 생기는 겁니다. 조직 전반이 빠른 속도로 나아가기 위해서는 관성의 속도가 맞아야 합니다. 이것이 가장 어려운 부분이에요.

그래서 지금은 각 구간을 분리해서 테스트하고, 그 경험을 공유하면서 어떤 부분을 보완할지 찾아가고 있는 단계입니다.

AI 에이전트를 많이 만들면 AX 성공인가

엔터프라이즈 AX를 잘하기 위한 방향 자체는 단순합니다. 잘 체험하고, 교육받고, 활용하고, 지원하고, 통제하는 것. 이것이 자연스럽게 순환하는 구조를 만드는 것이라고 저는 생각합니다. 그런데 지금은 너무 공격적으로 치고 나가고 있다 보니, 통제에 필요한 정보를 제대로 관리하고 있는지에 대한 고민은 뒤로 밀리고 있습니다.

저도 이런 딜레마를 하나씩 풀어야 해결의 실마리가 보이겠다 싶어서, 약 16가지 정도를 정리해 놓고 있습니다. 나중에 아티클로 하나씩 다루든, 묶어서 책으로 내든 할 생각인데요. 오늘은 그중에서 현장에서 자주 부딪히는 것들을 몇 가지 짚어보겠습니다.

혁신에는 레이어가 있다

대기업으로 갈수록 혁신은 특정 부서에 위임되어 있습니다. DX 부서, AX 부서가 별도로 존재하고, 거기서는 워크플로우 기반의 변화를 만들어낼 수 있습니다. 그런데 일반 업무를 수행하는 직원들은 그런 변화를 원해도 직접 바꿀 수가 없어요. 권한이 없으니까요.

리더의 성향에 따라서도 속도가 완전히 달라집니다. AI 친화적인 리더는 리스크를 일정 부분 감내하면서 공격적으로 추진하고, AX/DX 담당 리더는 양쪽을 바라보면서 리스크를 관리하려 하고, 현업은 99.9%의 정확도를 요구합니다. 이 세 가지 레이어가 같은 조직 안에 공존하고 있는 것입니다.

그래서 전사, 부서, 개인이 동일한 교육을 받는 것이 아니라, 각 단위에 맞는 교육과 환경이 필요합니다. 교육뿐 아니라, 외부 기술 환경과 내부 기술 환경을 어떻게 통합해서 활용할 것인지까지 설계가 돼야 합니다.

알고리즘 전문가가 하루 아침에 PM이 되지는 않는다

기존에 데이터 사이언티스트로 일하시던 분들이 AI 엔지니어 영역으로 전환되는 경우가 늘고 있습니다. 그런데 이분들은 알고리즘 스페셜리스트로서 깊이 있는 기술 역량을 갖고 계신 반면, 대외 프로젝트를 직접 리딩해 본 경험은 많지 않은 편입니다.

그런데 지금 이분들에게 요구되는 역할은 프로젝트 관리자이자 중재자입니다. 각 부서의 과제 담당자와 요건을 조율하고, 외부 전문 기업과 협력해 에이전트를 구축해야 하는 거예요. 알고리즘 전문가가 PM이자 부서 간 조율자 역할로 전환되고 있는 셈입니다.

데이터 엔지니어도 마찬가지입니다. 기존에는 DW(Data Warehouse)에 데이터 마트를 잘 구성해 놓는 것까지가 역할이었는데, AI 데이터 엔지니어링은 벡터DB를 구축하고, 임베딩과 청킹(데이터를 AI가 처리할 수 있는 단위로 분할하는 작업)을 다루는 전혀 다른 영역입니다. 기존 데이터 인프라에서 AI 쪽으로 데이터를 보내줄 것인지, AI 데이터 엔지니어링 측에서 반대로 가져올 것인지, 그리고 DW 컬럼 값이 변경됐을 때 데이터 파이프라인이 깨지면 누가 책임질 것인지. 이런 것들이 정리되지 않은 채로 진행되는 경우가 많습니다.

AI 시대 AX에 관한 기업의 딜레마 <출처: 원티드랩>

기준 없이 시작하면 성과도 보이지 않는다

개인 성과와 팀 성과가 연결되지 않는 경우가 많은데, 근본적으로는 베이스라인(기준선) 설정이 안 돼서 그렇습니다. 이니셔티브를 정해놓고 시작은 하지만, 어느 시점을 기준으로 어떤 지표로 효과를 측정할 것인지에 대한 합의가 없어요.

그러다 보니 매번 같은 질문이 돌아옵니다. "그래서 우리가 좋아진 게 뭐야? 돈 벌었어?" 이것에 명쾌하게 답하지 못하는 거죠. 결국 FTE(Full-Time Equivalent, 상근 인력 환산) 관점에서 업무를 분해하고, 주기와 빈도를 감안해서 측정 기준을 먼저 세운 다음 시작해야 하는데, 그 과정 없이 진행하는 곳이 대부분입니다.

자동화했다고 끝이 아니다

자동화가 확산되고 있지만, QC(Quality Control, 품질 관리)를 간과하는 경우가 상당히 많습니다. 저도 과거에 금융사에서 자동화 프로젝트를 다수 수행했는데, 자동화에 대한 핵심 판단 기준은 명확합니다. 리스크 발생 확률이 낮을 경우, 혹은 문제를 조사해서 얻을 수 있는 총효용 보다 사람의 개입 비용이 클 경우 자동화로 처리하는 방향으로 진행됩니다.

처리 결과에 대한 QC도 체계가 필요합니다. 일정 비율, 예를 들어 5%씩 샘플링해서 정기적으로 검토하거나, 처리 이력 전체를 주기적으로 검수하는 CFR(Close File Review) 방식이 있어요. 로그를 빠짐없이 남기고, 팩트체크를 수행할 수 있는 조직적 기반이 갖춰져야 합니다. 이 작업을 AI에게 위임하면 안 됩니다. AI는 책임을 지지 못하니까요.

"자동화됐으니까 끝"이 아닙니다. 문제가 발생했을 때 "이 건의 담당자가 누구인가?"라는 질문에 답할 수 있어야 합니다.

에이전트 오너십이 필요하다

결국 AI의 결과를 최종적으로 보증하는 것은 사람입니다. 설명 가능한 AI(XAI, Explainable AI)를 넘어서, 이제는 '책임질 수 있는 AI'의 영역으로 진입하고 있습니다.

그렇다면 에이전트의 오너십에 대한 기준이 필요합니다. 이 에이전트의 소유자가 누구인지, 품질 관리와 운영에 대한 책임은 누가 지는지를 명확하게 정해야 합니다. 여러 에이전트가 부서 간에 연결돼 크로스 펑셔널 (Cross-Functional, 부서 횡단적)하게 동작할 수도 있는데, 그 통합을 누가 위임하고, 누가 승인하는지도 정리돼야 합니다.

AI를 쓰면 역할이 확장됩니다. 기존에 할 수 없었던 것들을 더 많이 수행할 수 있게 되니까요. 그런데 역할이 커지면 책임도 커집니다. 이 부분을 간과했다가는 나중에 상당히 큰 비용을 치르게 될 것이라고 생각합니다.

저희도 이런 고민 속에서 외부 도구와 내부 환경을 분리해 운영하고 있습니다. 클로드 코드 같은 외부 도구는 프로토타입을 빠르게 만들어 시장 반응을 확인하는 용도로, 보안이 필요한 업무 자동화는 엔노이아 내 워크플로우 빌더를 통해 처리하는 방식입니다. 모든 에이전트를 외부 환경에 전부 맡길 수는 없으니까요.

이런 딜레마들은 결국 하나의 질문으로 수렴합니다. AX를 통해 우리가 진짜 얻고자 하는 것이 무엇인가, 하는 것이죠.

AX를 하고도 남는 질문: 그래서, 살림살이 나아졌나

마지막으로 드리고 싶은 이야기입니다.

우리가 AX를 추진하는 이유는 무엇일까요. 가장 중요한 이유는 고객이 필요로 하는 것을 정확히 파악해서, PMF(Product-Market Fit, 제품과 시장의 적합성)를 찾는 것이라고 봅니다. 빨리 많이 만드는 것이 핵심이 아니라, 만든 것을 고객에게 어떻게 전달하고 안착시킬 것인지에 대한 전략이 먼저입니다. 그 전략을 갖추고 나서 실행하면 문제가 없어요. 그런데 우리가 지향하는 것이 에이전트를 많이 만들어 놓고 "AX 했다"고 선언하는 것인가요?

지금 AI가 주는 효율은 분명합니다. 짧은 시간 안에 다양한 서비스를 양산할 수 있게 됐습니다. 그런데 고객이 그것을 원하는지는 별개의 문제입니다. "빨리 많은 서비스를 출시하면 수익이 따라올 것이다"라는 공식이 정말 성립하는지, 고객의 수요가 그 속도를 따라갈 수 있는지, 저는 의문을 갖고 있습니다.

AI를 활용하면 기존보다 결과물의 신뢰 수준이 낮아질 수 있다는 문제도 있습니다. 지금도 ChatGPT가 "부정확할 수 있습니다"라고 표시하잖아요. 과거에는 높은 수준의 신뢰도를 가진 정보성 상품을 제공하고 있었는데, 현재는 양은 많아졌지만 신뢰 수준은 떨어질 수 있는 구조가 된 겁니다. 그러면 고객이 그것을 구매할까요?

실제로 요즘 현장에서 감지되는 변화가 있습니다. "AI로 만든 장표로 발표하지 않았으면 좋겠다"는 요청이 조금씩 나오고 있어요. 의외로 적지 않습니다. 결국 고객의 마음을 움직이는 것은 사람의 손길이 들어간 부분일 거라고 생각합니다. 그래서 우리가 기대하는 만큼 드라마틱하게 인력이 줄어드는 자동화는 일어나지 않을 수 있습니다.

처음에 이런 화두를 던졌습니다. "성공적인 AX의 모습을 상상할 수 있는가?" 그리고 "AX 잘했더니 돈 벌었다"고 말할 수 있는 기업이 아직 많이 없다고 했습니다.

AX는 해야 합니다. 잘 체험하고, 잘 활용하고, 잘 통제하는 구조를 만들어야 합니다. 다만 에이전트를 많이 만드는 것 자체가 목적이 되어서는 안 됩니다. 속도만 빨라졌을 뿐 구조적으로 고민하지 않으면, 결국 같은 질문으로 돌아오게 됩니다.

"그래서, 살림살이 나아졌나?"

이 질문에 명쾌하게 답할 수 있으려면, 지금보다 조금 더 구조적으로 고민할 필요가 있지 않나 싶습니다.

]]>

자바 vs. 파이썬: 더 나은 에이전트 개발 언어는?

본문은 로드 존슨(Rod Johnson)의 글 <Build Better Agents in Java vs Python: Embabel vs LangGraph>를 번역한 글입니다. 로드 존슨은 스프링 프레임워크를 만든 것으로 유명한 개발자죠. 그는 최근 Embabel이란 프로젝트를 만들고, 에이전트 프레임워크를 개발하고 있습니다. 필자에게 허락받고 번역과 게재를 진행했습니다.

많은 사람이 생성형 AI 애플리케이션을 구축할 때는 파이썬이 가장 자연스러운 언어라고 잘못 알고 있습니다. 데이터 과학도 아닌데요.

그러니 이미 JVM을 사용하고 있다면, 사실 JVM에서 생성형 AI를 다루는 것이 당연합니다. 반면 둘 중 어느 쪽도 아니라면, 이제부터 보여드릴 공정한 비교 결과에 어쩌면 놀라워 할 수도 있겠습니다.

이전 블로그들에서 저는 CrewAI와 Pydantic AI의 예시를 가져와 Java와 Embabel로 다시 구현하면서, 같은 기능을 두고 더 깔끔하고 확장 가능한 코드를 만들어 본 적 있습니다.

오늘은 LangGraph의 차례입니다. LangGraph는 첫 번째이자, 동시에 가장 인기 있는 파이썬 기반 생성형 AI 프레임워크인 LangChain에서 나온 확장 프레임워크입니다. LangChain의 인기와 LangGraph의 약속은 회사를 주목받는 대상으로 만들었으며, 덕분에 회사는 최근 11억 달러의 평가액으로 시리즈 B 투자를 유치했습니다. 그 프레임워크는 이런 평가대로 정말 Java가 할 수 없는 것들을 할 수 있을까요?

LangGraph 아키텍처

LangGraph는 코드를 이용하여 다수 에이전트를 사용하는 업무 프로그램을 구현할 수 있게 합니다. 이 프레임워크는 유한 상태 기계(Finite State Machine)를 사용하여 작업 순서를 정렬합니다. 노드(상태)는 함수이고, 엣지(전이)는 자동으로 결정되거나 함수 호출 결과에 따라 동적으로 결정되기도 합니다.

이러한 노드와 엣지들은 긴 흐름을 여러 단계로 나누어 실행을 더 결정론적으로 만들고 작업 흐름을 이해하기 쉽게 만듭니다.

무엇보다 상태 기계는 작업 흐름을 정의하는 가장 명확한 방법이므로 이 개념을 가장 먼저 적용한 LangChain이 현재의 시장 위치를 차지하는 것이 놀랄 일은 아닙니다. 빠른 시장 출시에 따른 것이지요. 하지만 이것이 최선의 모델일까요, 아니면 아직 명확히 드러나지 않은 더 나은 해결책이 있을까요? 최근 저희는 여러 번 상태 기계를 구축한 끝에 목표 지향 행동 계획(GOAP)을 기반으로 하는 새로운 접근법을 정착시켰습니다.

때때로 먼저 움직이지 않고 다른 사람들의 성공과 실패에서 배우는 것이 최선일 수 있습니다.

패턴 대결

저는 오랫동안 Embabel과 LangGraph 사이의 체계적인 비교를 하고 싶었습니다. 공정을 기하기 위해 제가 만든 예시를 선택하지 않았고, 대신 Hamza Boulahia의 ‘LangGraph 에이전트 디자인 패턴’에 관한 최근 블로그의 내용을 다시 구현했습니다.

지난 몇 년간 AI 시스템을 구축하면서 배운 것이 있다면 패턴이 중요하다는 사실입니다. 전통적인 소프트웨어를 설계하든 대형 언어 모델(LLM) 에이전트로 실험하든, 작업 흐름을 구성하는 방식이야말로 결과물이 얼마나 견고하고 유연하며 확장 가능한지를 결정합니다.

Boulahia는 6가지 에이전트 디자인 패턴을 시연합니다:

프롬프트 사슬 구성: 복잡한 일들을 관리할 수 있는 단계로 나누기
제어 흐름을 위한 경로 설정(routing)과 병렬화
리플렉션(Reflection): 에이전트가 결과를 비판적으로 살피고 개선
외부 시스템과 통합하기 위한 도구 사용
계획 수립(Planning): 목적을 명확하게 실행 가능한 순서로 구조화
여러 에이전트의 협업

각 패턴을 하나씩 살펴보면서 자바 프로그램에서 Embabel을 사용해 표현력을 올리는 방식들을 보여드리겠습니다.

프롬프트 사슬 구성

프롬프트 사슬 구성은 필수적인 패턴으로 한 모델의 결과가 다른 모델의 입력이 되는 구조입니다. 이렇게 하면 일의 흐름을 예측하기 좋습니다. 이제 다룰 예제에서 에이전트는 사용자 입력을 기반으로 주제를 제안하고 각 주제에 대해 여러 개의 블로그 제목을 생성할 겁니다.

LangGraph 구현

예제는 LLM을 호출할 때 기본 LangChain API를 사용하며, 작업 흐름 관리를 위해서 LangGraph를 사용합니다.

여타 작업 흐름 엔진(workflow engine)처럼 LangGraph를 사용하면 LangChain 만 사용할 때와 달리 프로세스 상태를 유지하기만 해도 좋습니다. 이를 State 클래스로 표현합니다.

작업 흐름은 노드와 엣지를 통해 정의됩니다. LLM을 호출하는 Python 메서드가 노드가 됩니다.

작업 흐름은 코드로 구현합니다. 노드는 메서드에 매핑되고 엣지가 메서드를 연결합니다. 예제에서 엣지는 간단하게 다음 상태로 전환하게 만듭니다. 작업 흐름이 하드코딩된 문자열로 표현되기 때문에 컴파일 할 때 유효성 검사가 거의 이루어지지 않습니다.

작업 흐름의 실행은 아래와 같은 코드로 합니다.

실행한 결과는 다음과 같습니다.

Embabel 구현

사소한 부분이긴 하지만, 사실 위의 예시 일부는 좋지 않은 설계이기 때문에 이를 그대로 구현하기는 어렵습니다. 특히, 지금의 예시는 도메인에 대한 모델링 부족하다 할 수 있습니다. 파이썬으로 생성형 AI를 다룰 때는 도메인 모델링을 과소평가하는 경향이 있는데, 이는 심각한 실수입니다. State 클래스의 모든 필드는 문자열로 모델링되어 있으므로 구조가 있어야 합니다. 특히 주제를 하나로 문자열로 표현하는 일은 오해를 낳기 쉽습니다.

이 문제를 해결하는 형태로 최소한의 변경을 했습니다. 도메인 모델과 행위 그리고 목적으로 표현된 Embabel 구현 방식을 택했습니다.

도메인 객체는 Java 레코드이며, 요구사항에서 암시된 구조를 올바르게 나타냅니다.

코드를 좀 더 자세히 해설해 보겠습니다. 우선 @Agent 애노테이션은 클래스가 Spring에 의해 생성되고 주입되며, Embabel이 처리하게 합니다. @Action 메서드는 단계를 나타내고, 목적은 원하는 출력입니다.

Actor 필드는 하이퍼파라미터를 주고 LLM 모델을 선택하는 일과 명령어를 결합합니다.

extractTopics와 generateBlogTitles 메서드는 LangGraph 노드 메서드에 해당합니다. 그러나 작업 흐름은 매우 다르게 구성되어 있습니다.

이처럼 Embabel에서는 코드에서 작업 흐름을 지정할 필요가 없습니다. 프레임워크 스스로 코드를 분석하여 실행 경로를 계획합니다. 특히 실행 로직은 타입의 흐름에서 올바른 실행 계획을 추론할 수 있습니다. 예를 들어, 작업 흐름 범위에서 Topics와 BlogTitles 객체를 사용할 수 있어야만 마찬가지로 목적을 달성할 수 있다는 것을 알 수 있습니다. 그에 따라 메서드 호출 순서를 올바르게 결정할 수 있습니다. 이와 같은 계획 단계는 결정론적입니다.

마지막으로, generateBlogTitles 단계를 병렬 작업으로 모델링하여 요구사항을 더 자연스럽게 반영하고 LLM과의 상호 작용을 더 간결하고 집중력있게 만듭니다.

출력 결과는 다음과 같습니다. LangGraph 예제 출력과 달리 요구사항을 정확하게 반영한 구조입니다.

비교

두 구현 모두 흐름을 작고 초점이 분명한 단계로 나누어 예측을 쉽게 합니다. 다만, Embabel 버전에는 코드가 조금 더 많습니다. 다중성cardinality을 올바르게 모델링하려는 코드가 추가됩니다.

그 대신 Embabel 구현은 여러 측면에서 우수하다고 느껴집니다. 먼저, 타입 안전성 측면이 그렇습니다. 오용 가능성이 있는 문자열과 대비되는 제대로 된 도메인 모델이 있어 테스트하기 쉬워집니다. 그리고 추가할 수 있는 구조 때문에 병렬 작업도 가능합니다.

그 외에도 Embabel 구현에서는 사소하지만 LangGraph 보다 나은 몇 가지 개선 사항이 있습니다.

LLM 선택과 페르소나 외부화: Embabel과 Spring을 사용하면, Actor 정의를 application.yml 파일로 간단하게 외부화할 수 있습니다. 파이썬에 부족한 복잡한 옵션 구성이 가능합니다.
주제와 블로그 제목 유지: 적절히 구조화된 도메인 객체가 있기 때문에, 원할 때 쉽게 내용을 유지할 수 있습니다.

경로 선택(Routing)

또 다른 기본 패턴은 작업 흐름 안에서의 경로 선택입니다.

LangGraph 구현

여기 LangGraph 구현이 있습니다. 먼저 감정 분석을 수행한 다음 응답을 생성하기 위해 적절한 함수를 선택합니다:

LangGraph에서 항상 그렇듯이 작업 흐름은 확인할 수 없는 문자열로 구축됩니다. 예제 코드에서 “classification”에 오타가 났는데, 전부 같이 틀렸기 때문에 다행히 문제는 없습니다. 그래도 이렇게 취약할 때는 타이핑이 매우 중요해집니다.

다음 예시는 함수의 출력을 다음 상태 이름에 매핑하는 식의 더 정교한 LangGraph 상태 전환을 보여주는데, 여기서도 역시 오류가 발생하기 쉬운 마법 문자열이 보너스로 더해집니다:

다음과 같은 코드로 이를 실행합니다.

Embabel 구현

노드와 엣지를 명시적으로 연결하는 일은 이렇게 간단한 일을 너무 복잡하게 만듭니다. 좀 더 자연스러운 방식으로 단계를 표현해 봅시다.

이때는 단계가 다르기 때문에 LLM과 관련된 공통 시스템 메시지가 아니라 매번 초점이 맞춰진 프롬프트를 사용할 수 있습니다.

먼저 Sentiment의 타입을 만들겠습니다. 이는 흐름을 데이터 타입으로 표현할 수 있게 도와줍니다:

이제 우리는 classify 메소드가 Sentiment 객체를 반환 하도록 구현을 시작할 수 있습니다. Embabel은 스스로 Sentiment가 하위 타입을 갖는지 알아차리며,그에 맞춰 적절한 경로를 계획합니다.

한편 Encourage와 help 메소드는 각각 하나의 Sentiment 하위 유형을 취합니다. 파이썬 함수와 마찬지로 LLM을 호출하여 응답을 생성하는 구조입니다.

비교

Embabel을 이용해 데이터 타입을 통해 실행 경로를 정의하는 것이 LangChain 상태 머신보다 자연스럽고 오류가 적다고 생각합니다. 다시 한번, Embabel 내부에서 스스로 계획하는 기능이 흐름을 파악하기 때문에 직접 흐름을 정의할 필요가 없습니다.

병렬화

LLM 상호 작용이 일어나면, 동작이 느려질 수 있습니다. 따라서 병렬화는 생성형 AI 애플리케이션에서 중요합니다.

LangGraph는 “평행 엣지(parallel edges)”를 통해 작업을 병렬화할 수 있게 합니다.

Embabel에서는 병렬화를 위해 두 가지 선택이 가능합니다:

블로그 제목 예시에서 본 parallelMap 메서드를 사용한 프로그래밍 방식.
자동 구조도 있습니다. embabel.agent.platform.process-type=CONCURRENT를 설정하면, Embabel 스스로 계획하여 서로 의존하지 않는 작업을 대상으로 현재 목표를 달성하기 위해 필요한 경로를 병렬 실행합니다.

리플렉션(Reflection)

리플렉션은 다양한 이름으로 불리는 중요한 보편적 패턴입니다. 앤트로픽은 “Building Effective Agents”에서 이 패턴을 Evaluator-optimizer라고 부릅니다.

패턴의 핵심 아이디어는 LLM 호출을 한 차례 사용하여 다른 LLM의 출력에 대한 피드백을 제공하고 결과가 만족스러울 때까지 반복하는 것입니다.

여기 LangGraph 구현이 있습니다. 사용자가 지정한 작업에 응답하여 텍스트를 초안하고 만족스러울 때까지 비판합니다.

패턴의 가치에 빗대어 볼 때 이상적인 구현과는 거리가 멉니다. 일단, 종료를 보장할 수 없습니다.

개발자 관점에서 이런 류의 상태 머신은 일반적인 작업흐름을 표현하는데 이상적이지 않습니다. 공정하게 따지면, Embabel의 GOAP 계획도 마찬가지입니다. FSM이나 GOAP을 쓴다면 조잡한 계획에 잘 맞지만, 세밀한 작업을 정의할 수 있다면 정교한 프레임워크 지원으로 더 쉽게 할 수 있습니다.

따라서 Embabel은 일반적인 패턴에 대해 바로 직접 만들지 않고 가져다 쓸 수 있도록 구현하는 방식을 제공합니다. (물론 자신만의 것을 만들 수도 있습니다.) 구현을 원하는 경우 GOAP 계획을 내보내는 fluent API*를 제공하기 때문에 표준적인 방식으로 단계를 관리할 수 있습니다.

*fluent API: 메서드 체이닝으로 코드를 자연어처럼 읽히게 만드는 API 설계 패턴

RepeatUntilAcceptableBuilder를 사용하여 프로그래밍 방식으로 Agent를 만들고 @Configuration 클래스에서 Spring bean으로 노출하면, Embabel이 자동으로 배포합니다:

자바로 작성한 Embabel 코드는 LangGraph를 사용한 파이썬 코드보다 훨씬 적은 코드를 가지고 있습니다. 그 덕분에 타입을 보장하고 많은 도구를 활용할 수 있어 흐름을 망칠 일이 없습니다. 만일 maxIterations를 초과하면 루프가 종료되고, 지금까지 본 최고 점수의 결과를 반환합니다. 또한, RepeatUntilAcceptableBuilder가 매개변수화되어 있고 타입을 보장하기 때문에 자신의 결과 타입과 피드백 타입을 사용할 수 있습니다. 이 시나리오에서 LangGraph는 매우 좋지 않은 성능을 보여준다고 할 수 있겠습니다.

도구 사용

도구 사용은 모든 생성형 AI 프레임워크의 필수 요소이며 쉬워야 합니다.

LangGraph를 사용하면 Python에서 도구를 정의하고 LLM에 바인딩할 수 있습니다:

간단한 예시입니다. 다만, 이 예시는 생성된 Python 코드를 샌드박스 없이 실행하기 때문에 위험할 수 있습니다.

Embabel로 같은 처리를 한다면 매 번 PromptRunner를 사용하여 간단하게 도구를 추가할 수 있습니다. MCP가 지원하는 잘 알려진 도구 그룹을 정의하거나 Java 객체로 지정할 수 있습니다:

도구 객체를 사용하는 기능은 특히 중요합니다. 이들은 데이터베이스에서 검색한 도메인 객체 또는 스프링으로 에이전트에 주입한 서비스일 수 있습니다. 파이썬에서도 그렇게 할 수 있지만, 자바 객체의 경우가 유용한 비즈니스 기능을 가질 가능성이 더 높다는 점에서 중요한 차이가 있습니다.

Embabel은 또한 LlmReference와 같은 개념으로 도구 그룹화를 제공하며, 이는 도구를 프롬프트 요소와 결합하여 런타임에 정교한 구성을 가능하게 합니다.

계획 수립

계획을 수립하는 과정을 다룬 LangGraph 블로그 예시는 이전 두 단계의 실행에 따라 최종 단계가 달라지는 형태를 포함합니다. 이것은 작업흐름 구축 과정에서다음과 같이 표현됩니다.

Embabel에서는 두 데이터 타입을 모두 사용하는 메서드를 간단히 정의합니다:

이 방식이 제가 느끼기에 더 명확하고 타입 활용에 안전하며 테스트하기 쉽습니다.

LangChain 예시는 또한 계획의 단계를 하드코딩하지만, 그 코드는 LLM이 만들 수 있다고 언급합니다. Embabel에서 역시 LLM이 명령 객체를 인스턴스화하도록 하여 이를 구현할 수 있습니다. 그러나 LLM에 의존하여 계획을 수행하면 흐름 예측이 훨씬 어려워지므로 주의깊게 수행해야 합니다.

다중 에이전트 협업

마지막 패턴은 감독자 노드에서 다른 에이전트로의 전달 예시입니다. 이것은 Google ADK와 같은 프레임워크에서 흔한 패턴입니다. 상태 머신이나 GOAP 액션을 통해 단계를 표현하는 것보다 덜 결정론적이므로, 우리가 권장하는 경향이 없는 패턴입니다. 이러한 동작을 달성하기 위해 Embabel은 에이전트를 도구로 사용할 수 있게 합니다.

전체 코드

전체 코드는 Embabel langgraph-patterns 저장소에서 찾을 수 있습니다.

누군가는 원본 블로그가 LangGraph 사용을 제대로 보여준 것이 아니라고 주장할 수 있습니다. 하지만 이 글은 제가 보기에 에이전트에 대한 건전한 이해를 바탕으로 한 잘 쓴 글이며, 미디엄Medium에서 수백 개의 박수를 받았습니다. 다른 LangGraph 애플리케이션에서 동일한 결함을 찾기는 어렵지 않으며, 문제가 저자가 아니라 프레임워크, 언어 및 생태계에 있음을 시사합니다.

마치며

이제 자바 커뮤니티는 파이썬 기반 에이전트의 성장을 따라잡아야 한다는 강박을 멈추고, 생성형 AI 에이전트를 구축하기 위한 해결책뿐만 아니라 모든 플랫폼에서 최고의 해결책을 가지고 있음을 보여줄 때입니다.

파이썬 프레임워크가 보여주는 평범한 아이디어 아래 안주하는 것을 멈추고 우리가 써온 언어를 기반으로 생각할 때입니다. 파이썬은 황제들만 갖출 수 있는 옷을 입지 않았습니다. 여러분이 JVM 개발자이지만, 상사가 파이썬으로 에이전트를 작성하라고 말하면, 비즈니스 애플리케이션, 생성형 AI 또는 기타 분야의 플랫폼으로서 파이썬의 약점을 지적할 준비를 하세요. 그리고 일반적인 패턴을 그대로 쓰면서도 파이썬보다 자바가 나아 보일 수 있는 방법을 보여줄 준비를 하세요.

파이썬은 모든 개발자가 능숙하게 쓰면 좋은 중요한 언어입니다. 많은 작업에 훌륭한 성능을 보여줍니다. 다만, 이 언어는 꽤 중요한 비즈니스 애플리케이션을 구축할 때 인기 있는 언어가 아니었으며, 여기에는 그럴만한 이유가 있습니다.

JVM의 견고성은 잘 알려져 있습니다. 생태계 — 특히 파이썬에서는 대안이 없는 Spring이 — 이러한 견고함을 강력하게 뒷받침합니다. Embabel은 이를 바탕으로 하며, 모든 파이썬 프레임워크보다 우수한 개념을 제공한다고 저는 믿습니다. 나머지는 여러분에게 달려 있습니다. 오늘 자바 에이전트 템플릿에서 첫 번째 에이전트를 만들어 보세요.

]]>

AI, 개발 말고 요구사항부터 써야 하는 이유

본문은 요즘 IT와 번역가 Yuna가 함께 야쿠브 기자(Jakub Giza)의 글 <How to leverage AI for better IT requirements and process improvements in your company>을 번역한 글입니다. 필자는 25년 이상의 기업 IT 경력을 보유한 전문가로, 통신, 디지털 플랫폼, 대규모 혁신 프로젝트 등 다양한 분야에서 글로벌 개발 프로그램을 이끌어왔습니다. 현재는 AI 실험 단계를 넘어 실제 조직 안에서 AI를 체계적으로 실행할 수 있도록 돕는 데 집중하고 있으며, 인간과 AI의 협업 프레임워크인 HyperVe의 창시자이기도 합니다.

이 글은 AI 도입 후에도 기대했던 ROI가 나오지 않는 이유를 짚고 그 해결책을 제시합니다. 개발 속도만 높이는 것으로는 부족하며, 요구사항을 정의하는 방식 자체를 AI 시대에 맞게 바꿔야 한다고 설명합니다.

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

AI 열풍이 조금씩 식어가고 있습니다. 대부분의 기업은 이미 개발자에게 코파일럿, 코드 어시스턴트 같은 AI 도구를 쥐여주며 개발 속도를 높였는데요. 그런데도 여전히 뭔가 빠진 느낌입니다. AI가 우리가 기대했던 만큼 일하고 있다는 확신이 들지 않죠. ROI 향상, 10배의 생산성 개선, 그 기대했던 순간이 아직도 오지 않은 것 같습니다.

그런데 사실, 그 순간은 이미 와 있습니다. 지금 당장 활용할 수 있죠. 먼저 짚고 싶은 건, AI를 개발에 활용하는 것만으로는 부족하다는 점입니다. 개발 전 단계부터 이후까지, 전체 흐름이 함께 빨라져야 하거든요. 10배의 생산성과 더 나은 AI 투자 수익은 결국 가장 느린 단계를 얼마나 빠르게 끌어올리느냐에 달려 있습니다. 그리고 지금 그 병목은 개발 이전으로 옮겨갔습니다. 무엇을 만들지 정의하고 검증하는 단계가 빨라진 개발 속도를 따라가지 못하고 있는 거죠.

상황은 더 심각합니다. AI 시대에는 불명확한 의도, 부족한 맥락, 검증되지 않은 비즈니스 가정이 단순히 속도를 늦추는 문제가 아닙니다. 잘못된 것을 더 빠르게 만들게 되고, 그만큼 조직의 위험도 커지죠.

해결책은 무엇일까요? 비즈니스 요구사항을 정의하고 프로세스를 개선하는 속도와 정확도를 AI 개발 속도에 맞춰야 합니다. 코딩에만 AI를 쓸 게 아니라, 비즈니스 활동 전반에 AI를 녹여야 한다는 뜻입니다.

AI 투자 수익이 낮은 건 개발 속도 문제가 아닙니다

개발이 빨라지면 그 이전 단계가 새로운 병목이 됩니다.

불명확한 의도: "포털이 필요합니다…" 같은 두루뭉술한 요청
부족한 맥락: 실제 업무가 어떻게 돌아가는지 모르는 상태
부실한 검증: 이게 정말 가치를 만들어낼지 확인하지 않는 상태
숨겨진 제약: 법무, 운영, 시스템 의존성, 데이터 품질 등 미처 파악 못 한 것들
느린 합의: 회의로만 요구사항을 정리하려는 관행

결국 무엇을 만들지 정의하고 검증하는 단계가 AI로 빨라진 개발 속도를 따라가지 못하는 겁니다. AI가 기대만큼의 성과를 내지 못하는 이유가 바로 여기 있죠. 더 빠르게, 때로는 더 잘 만들지만 정작 필요하지 않은 것을 만드는 경우가 너무 많습니다.

잘못된 방향에 빠른 실행이 더해지면, 빠르게 망합니다.

"더 나은 프롬프트"는 답이 아닙니다

많은 분들이 이렇게 반응합니다. "더 좋은 프롬프트가 필요해." 그럴듯하게 들리지만 잘못된 처방입니다. 프롬프트가 근본 문제가 아니거든요. 프롬프트는 이미 더 앞 단계에서 망가진 흐름의 마지막 단계일 뿐이죠.

진짜 문제는 대부분의 조직이 요구사항을 다루는 방식이 아직도 그대로라는 점입니다. 문서 하나, 티켓 하나, 인수인계 하나, 한 번 쓰고 끝나는 산출물로 취급하죠. 개발이 느렸을 때는 그래도 됐습니다. 하지만 지금처럼 개발이 빠른 시대엔 통하지 않습니다.

AI 시대에 요구사항은 이래야 합니다.

협업: 이해관계자와 AI가 함께 만들어가야 합니다.
실제 맥락: 회사와 시장에 대한 구체적인 지식에서 출발해야 합니다.
지속적인 개선: 한 번 쓰고 끝나는 게 아니라 계속 다듬어져야 합니다.
추적 가능성: 처음 의도부터 최종 결과까지 가치를 검증할 수 있어야 합니다.

새로운 요구사항 정의 시스템, VOS의 등장

그렇다면 실제로 무엇이 필요할까요? 개발이 시작되기 전, 팀이 비즈니스 의도를 실행 가능한 형태로 바꿀 수 있도록 돕는 무언가가 필요합니다. 거버넌스, 맥락, 팀 간 합의를 잃지 않으면서요. 다시 말해, 의도, 맥락, 가정, 아이디어, 논의, 결정을 하나로 엮어주는 시스템이 필요한 겁니다.

그래서 등장한 새로운 개념이 바로 VOS(Value Orchestration System, 요구사항 정의 시스템)이죠. VOS는 백로그 도구도, 챗봇도, 문서 저장소도, 티켓 시스템도 아닙니다.

HyperVe Loop — Value Orchestration System

VOS는 AI가 팀의 일을 늘리기 전에, 먼저 질을 높이도록 돕는 시스템입니다.

이제 업무 흐름은 요청에서 프롬프트, 개발 순입니다

기존 개발 방식에서는 "요구사항"에서 "구현"으로 넘어가는 흐름을 따랐는데요. 일반적인 소프트웨어 개발 생명주기, SDLC가 그것입니다. AI 네이티브 업무에서는 흐름이 다릅니다. 더 단순하고, 더 명확하고, 더 솔직하죠.

요청하고, 프롬프트를 만들고, 개발합니다.

요청: 비즈니스 의도, 기대 결과, 제약 조건, 성공 기준을 명확히 정의합니다.
프롬프트: 추측이 아닌 회사의 실제 상황을 담아 구체적인 지침을 만듭니다.
개발: 사람과 AI가 함께 실행하되, 처음 의도와 일치하는지 언제든 확인할 수 있습니다.

이 흐름이 실제로 이루어지려면 그에 맞는 공간이 필요합니다. 협업, 검증, 거버넌스가 기본으로 갖춰진 작업 공간이죠.

AI가 우리 회사를 알아야 제대로 작동합니다

AI가 일관되게 도움이 되려면 회사의 실제 상황을 알아야 합니다. 우리 조직이 어떻게 돌아가는지 AI가 파악하고 있어야 한다는 뜻이죠. 이를 위해 조직의 실제 상황을 담은 회사 정보가 필요합니다. 여기엔 이런 것들이 포함돼야 합니다.

프로세스: 업무가 어떻게 흘러가는지, 어디서 시간이 낭비되는지
시스템과 연동: 어떤 시스템을 쓰는지, 어디서 인수인계가 끊기는지
제약 조건: 보안, 법무, 운영, 데이터 저장 위치 등 반드시 지켜야 할 것들
기존 문서와 결정 사항: 이미 알고 있는 것, 이미 결정된 것들
담당자와 이해관계자: 누가 무엇을 결정하는지
데이터 품질 기준: 자동화가 제대로 작동하려면 어떤 조건이 갖춰져야 하는지

HyperVe Loop System

이런 토대 없이 요구사항을 만들면 그건 그냥 의견입니다. 이런 토대를 갖추고 요구사항을 만들면 그건 근거가 됩니다. “회의에서 나온 아이디어”가 “시스템 안에서 관리”되기 시작하는 변화입니다.

실무에 적용해보면 다음과 같습니다

"주문에서 개통까지 걸리는 시간을 14일에서 3일로 줄이자"는 목표가 있다고 해봅시다.

대부분의 팀은 바로 해결책으로 뛰어듭니다.

단계를 자동화한다
새 도구를 도입한다
워크플로를 다시 만든다
다른 플랫폼을 구매한다

하지만 AI 기반 요구사항 워크스페이스는 그 전에 먼저 해야 할 일을 합니다.

올바른 질문을 던지는 거죠. 핵심을 파고드는 탐색입니다.

정확히 어디서 지연이 발생하는가?
어떤 단계가 수동이고 어떤 단계가 자동화되어 있는가?
무엇이 재작업을 유발하는가?
어떤 제약이 자동화를 막고 있는가?
어떤 수준의 데이터 품질이 필요한가?

이 질문들은 조직의 실제 정보에 기반하기 때문에 추측이 아닌 사실에서 출발합니다.

프로세스 흐름과 이미 파악된 병목 지점
관련된 시스템들
시스템 간 연결과 인수인계 지점
반복적으로 발생하는 문제 패턴
이전에 내려진 결정과 제약 조건

그리고 각 선택지를 장단점과 함께 제시합니다. 어떤 결정을 내릴지 훨씬 명확해지는 순간이죠.

"옵션 A는 시간을 가장 빠르게 단축하지만, 먼저 데이터 정리가 필요합니다."
"옵션 B는 비용이 덜 들지만 개선 효과는 20%에 그칩니다."
"옵션 C는 고객 경험을 높이지만 운영 방식의 변화가 필요합니다."

결과물은 바로 검토하고 실행할 수 있는 형태로 나옵니다.

구조화된 요청서
프롬프트로 바로 활용할 수 있는 명세서
목표에서 가정, 결정, 산출물까지 연결되는 추적 가능한 흐름

이 과정을 거치면 "프로세스를 개선해야 한다"는 막연한 말이 측정 가능한 결과로 이어지는 실질적인 결정이 됩니다.

HyperVe Loop의 사례

HyperVe Loop는 요청, 프롬프트, 개발 흐름을 중심으로 만들어진 VOS의 실제 사례입니다. 주요 기능은 이렇습니다.

AI 기반 협업: AI가 이해관계자들과 함께 올바른 질문을 던지고, 결정 사항을 기록하고, 새로운 아이디어를 끌어냅니다.
실제 맥락 기반 대화: 추측이 아닌 회사의 프로세스, 시스템, 제약 조건, 문서, 결정 사항을 토대로 논의가 이루어집니다.
개발 전 검증: 본격적인 개발에 들어가기 전에 가치, 실현 가능성, 리스크, 장단점을 먼저 따져봅니다.
근거 있는 선택지 비교: ROI를 기준으로 실행 가능한 옵션을 비교해 볼 수 있습니다.
전 과정 추적: 요청에서 프롬프트, 개발까지 모든 과정이 끊기지 않고 연결됩니다.

결과적으로 더 나은 결정, 더 빠른 합의, 그리고 불필요한 재작업이 줄어듭니다.

리더가 AI로 실질적인 성과를 내는 5가지 방법

다음 경쟁력은 더 명확한 의도에서 나옵니다

AI 네이티브 개발은 이제 당연한 것이 되어가고 있습니다. 다음 경쟁력은 비즈니스 요구사항을 정의하는 방식도 함께 바꾸는 데 있습니다. 구조화되고, 실제 맥락에 기반하고, 협업적이고, 추적 가능한 방식으로요. 개발이 빨라진 지금, 결국 중요한 건 하나입니다. 올바른 것을 만들고 있느냐는 질문이죠.

<원문>

How to leverage AI for better IT requirements and process improvements in your company

]]>

[요즘IT 콘텐츠 AX] 기업 블로그 에이전트의 가능성과 한계 웨비나 오픈!

“콘텐츠 담당자를 위한 기업 블로그 에이전트 가능성과 한계” 웨비나 오픈

“AI로 콘텐츠 자동화하기” 콘텐츠를 만들어 본 분들이라면 한 번쯤은 생각해 보셨을 텐데요. 막상 해보면 글 한 편은 어떻게 완성되는데, 기획부터 발행까지 전체를 자동으로 돌리는 작업은 생각보다 훨씬 복잡합니다. 원했던 퀄리티가 나오지 않을 때도 많고요.

그래서 요즘IT가 직접 부딪혀봤습니다. 위시켓 기업 블로그를 대상으로, 콘텐츠 마케터의 워크플로우를 6단계로 나누고 각 단계에 AI 에이전트를 붙였습니다. 비개발자가 클로드 코드로 월간 12건의 콘텐츠 기획부터 발행까지 자동화한 과정, 그 한계와 가능성을 솔직하게 공유합니다.

정답이 있는, 이론을 배우는 자리는 아닙니다. 대신 직접 만들면서 겪은 것들을 있는 그대로 나눠보려고 합니다.

[요즘IT 콘텐츠 AX 실험기 미리보기]

웨비나 정보

일시: 2026년 4월 17일(금) 저녁 7:00
형태: 온라인 라이브 (Zoom)
구성: 발표 30분 + Q&A 20분
참가 비용: 얼리버드 ~~15,000~~ ▶11,900원 (4/16일까지)
신청 링크:웨비나 신청하기
슬라이드: 참여자에게 발표 슬라이드 PDF 제공 (웨비나 전날 이메일 발송)
녹화본: 따로 제공되지 않습니다.

웨비나에서 이런 이야기를 다룹니다

01. 파이프라인 전체 구조

콘텐츠 마케터의 워크플로우를 세분화하고, 각 단계에 에이전트를 붙인 구조. 왜 이렇게 나눴고, 어디서 사람이 개입하는지 살펴봅니다.

02. 시행착오 기록

키워드 수집에서 노이즈가 터진 일, 기존 글과 중복 판정이 안 맞았던 일, GEO 최적화와 브랜드 톤이 충돌한 일. 실제 겪은 문제들과 대응 과정을 살펴봅니다.

03. 도메인 지식의 벽

기업 담당자만 아는 비즈니스 맥락을 AI에 주입하는 것이 왜 어렵고, 어디까지 가능했는지 알아봅니다.

04. 생성 품질의 현실

AI가 쓴 글이 "사람이 읽을 만한 글"이 되려면 무엇이 필요한지. 현재 수준은 어디이고, 무엇이 부족한지 알아봅니다.

05. 직접 만들 때 알아야 할 것

에이전트가 정확히 뭔지, 어떻게 만드는지, 어디까지 자동화되고 어디서 사람이 판단해야 하는지 살펴봅니다.

발표자

장대청(요즘IT 그로스 파트 리드 · 위시켓)

비개발자. 코드를 직접 짜지 않고, 업무 매뉴얼을 자연어로 정의하면 클로드 코드가 코드를 짜는 방식으로 파이프라인을 구축했습니다. 위시켓 기업 블로그 자동화 프로젝트의 설계와 실행을 담당하고 있습니다.

이런 분들께 추천해요

기업 블로그나 콘텐츠 마케팅을 담당하면서 AI 자동화를 검토 중인 분
에이전트가 궁금한데, 실제 사례를 먼저 보고 싶은 분
직접 파이프라인을 만들어보고 싶은데, 전체 그림이 안 잡히는 분
코드는 나오지 않습니다. 구조와 판단 과정, 시행착오 중심으로 이야기합니다. 사전 등록자의 77%가 비개발자(PM, 기획자, 콘텐츠 마케터)였습니다.

자주 묻는 질문

Q. 비개발자인데 이해할 수 있나요?

네. 사전 등록자의 77%가 비개발자(PM, 기획자, 콘텐츠 마케터, 경영진)입니다. 코드는 나오지 않습니다. 구조와 판단 과정, 시행착오 중심으로 이야기합니다.

Q. 웨비나를 듣고 바로 자동화를 구축할 수 있나요?

이 웨비나는 정답이나 성공 공식을 알려주는 자리가 아닙니다. 에이전트로 블로그를 자동화한다는 것이 실제로 어떤 것인지, 클로드 코드로 그것을 어떻게 시작하는지, 그 과정에서 부딪히는 문제들은 무엇인지, 직접 해본 사람의 경험과 시행착오를 공유합니다. 되는 것과 안 되는 것의 경계를 이해하고, 스스로 판단 기준을 세울 수 있도록 돕는 자리입니다.

Q. 우리 회사에도 적용 가능한가요?

기업 블로그 콘텐츠를 정기 발행하는 팀이라면 파이프라인 구조 자체는 적용 가능합니다. 다만 도메인 지식을 AI에 주입하는 과정이 핵심 과제이며, 이 부분의 현실적인 난이도를 웨비나에서 다룹니다.

Q. 녹화본이 제공되나요?

녹화본은 제공되지 않습니다. 참여자에게 발표 슬라이드 PDF를 웨비나 전날 이메일로 발송해드립니다.

Q. 환불이 가능한가요?

웨비나 당일 전까지 환불 요청 시 전액 환불됩니다.

마치며

강의가 아니라 경험담을 나누는 자리입니다. 잘 된 것도, 막혔던 것도, 아직 안 되는 것도, 모두 있는 그대로 공유합니다. "우리 팀도 해볼 수 있을까?"라고 고민하고 계신 분들께 도움이 되길 바랍니다. 그럼 4/17일 웨비나에서 만나요!

[→웨비나 신청하기]

]]>

AI 에이전트가 슬랙을 떠난 이유: 웹으로 이사한 곰곰이

이번 글은 반복적인 SQL 업무를 자동화하는 AI 에이전트 '곰곰이'의 후속입니다. 아직 읽지 않으셨다면 먼저 읽고 오시는 걸 추천합니다.

요즘 기업들의 AI 도입 사례를 부쩍 자주 보게 됩니다. 특히 자연어로 데이터를 분석하는 Text-to-SQL 에이전트 사례가 눈에 띄게 늘었는데요. 그런데 흥미로운 점이 있습니다. 많은 초기 도입 사례에서 AI 에이전트가 슬랙봇의 형태로 소개된다는 것입니다. 저도 그랬습니다. 곰곰이도 처음엔 슬랙 채널에서만 활동했고, 덕분에 빠르게 프로토타이핑하여 동료들에게 선보일 수 있었습니다.

하지만 얼마 전 곰곰이를 웹앱으로 이사시켰습니다. LLM과 AI의 잠재력을 슬랙이라는 작은 그릇에 계속 가둬둘 수 없다고 판단했기 때문입니다. 이 글에서는 제가 왜 그런 결정을 내렸는지, 그리고 웹으로 이사 이후 무엇이 달라졌는지 풀어보려 합니다. 슬랙봇으로 AI 에이전트를 운영하고 있거나 고민 중인 분이라면, 저의 사례가 작은 힌트가 됐으면 합니다.

목차
슬랙은 AI의 잠재력을 담을 수 없다
웹 전환으로 달라진 것들
커맨드와 예약: 반복 분석을 자동화하다
곰곰이 제작자의 생각
앞으로 남은 여정

슬랙은 AI의 잠재력을 담을 수 없다

곰곰이가 슬랙봇으로 시작한 건 당연한 선택이었습니다. 슬랙은 동료들이 하루 종일 켜놓는 업무용 메신저입니다. 새로운 환경을 따로 세팅하거나 배울 필요 없이 곰곰이를 바로 써볼 수 있었고, 데이터 분석 결과를 동료들에게 공유하는 것도 쉬웠습니다. 빠르게 프로토타이핑하고 동료들의 반응을 확인하기엔 슬랙만한 환경이 없었습니다. 그런데 쓰면 쓸수록 불편한 지점들이 생겼습니다.

첫 번째는 보안입니다. 슬랙에서 회사 정보를 공유하는 건 이미 익숙한 일입니다. 그런데 DB와 연결된 AI가 슬랙 위에서 데이터를 조회하고 분석한다는 건 왠지 찝찝합니다. 보안 통제가 높은 조직이라면 더욱 그렇습니다. 데이터 조회와 반출에 대한 사용자별 권한 체계가 있는 곳이라면, 곰곰이가 슬랙에서 자유롭게 데이터를 분석하는 것 자체가 허락되지 않을 수 있습니다.

두 번째는 가독성입니다. 아래 사진은 슬랙에서 곰곰이의 데이터 분석 답변입니다. 표는 줄이 맞지 않아 읽기가 어렵습니다. 그래프를 그리는 것은 아예 불가능하고, 굵게나 밑줄 같은 마크다운 기본 포맷도 제대로 렌더링되지 않습니다. 곰곰이가 데이터 분석 과정에서 도구를 선택하고 생각하는 흐름인 ReAct 추론 과정을 보여주는 것도 마찬가지입니다. 슬랙으로는 데이터 분석 결과를 보여주기에 충분하지 않았습니다.

슬랙 곰곰이 답변의 시원치 않은 모습

세 번째는 확장성입니다. 슬랙은 채팅 앱으로서 훌륭하고 SDK나 플러그인도 잘 갖춰져 있습니다. 하지만 직접 만든 웹앱과 비교하면 기능을 추가하고 커스텀 할 때 발목이 잡힙니다. 개인화된 대화, 보고서 이미지 다운로드, 로그인과 권한 관리, 어드민 기능 같은 것들은 슬랙에서 만들 수 없습니다.

슬랙이 나쁘다는 게 아닙니다. 다만 곰곰이의 잠재력을 전부 끌어내려면 제가 원하는 대로 만들 수 있는 환경이 필요했습니다.

웹 전환으로 달라진 것들

저는 백엔드에 익숙한 개발자입니다. 데이터 설계, 인프라 구축, API 개발은 늘 하던 일이라 부담이 없습니다. 그런데 버그 없이 잘 동작하는 웹앱을 만드는 건 솔직히 자신이 없었습니다. 하지만 그것도 몇 달 전 이야기입니다. AI 코딩 에이전트 덕분에 이제 퀄리티 높은 웹앱도 직접 만들 수 있게 되었습니다. 슬랙봇 개발도 쉬운 편이긴 한데 AI의 도움이 잘 닿지 않는 부분들이 있습니다. 반면 AI 코딩 에이전트로 직접 웹앱을 만들면 빠르게 원하는 데로 모두 만들 수 있어 슬랙봇 보다 웹앱 개발이 더 쉬워진 상황이 됐습니다.

그래서 AI 에이전트의 족쇄가 되는 슬랙을 벗어나 직접 웹앱을 만들어 곰곰이가 능력을 더 자유롭게 보여줄 수 있는 브라우저 환경으로 이사시켰습니다.

새 채팅 화면

가장 먼저 달라진 건 개인화입니다. 회원가입과 로그인으로 접근하게 되면서 채팅을 공유 환경뿐만 아니라 나만의 공간으로도 쓸 수 있게 됐습니다.

곰곰이 웹을 보고 만약 무엇인가 떠올랐다면, 맞습니다. 저는 스탯을 개발에만 찍어서 디자인 능력이 없거든요.

나의 데이터 분석 채팅을 나만 볼 수 있는 게 생각보다 꽤 중요합니다. 곰곰이의 고객인 사내 동료들은 아직 데이터를 직접 다루는 습관이 충분히 쌓이지 않은 분들이 많습니다. 내가 한 질문이 누군가에게 바보 같아 보이지 않을까 하는 마음이 곰곰이 사용을 주저하게 만들 수 있거든요. 나만 볼 수 있는 대화가 생기니까 자유롭게 질문하고 시도해 볼 수 있습니다. 아직 만들진 않았지만 유저나 그룹별로 접근 가능한 데이터 종류를 제어하는 권한 관리도 웹이기 때문에 가능한 것들입니다.

바보 같은 질문 하는 채팅

답변의 표현도 훨씬 풍부해졌습니다. 곰곰이가 마크다운으로 답변하도록 만들고 브라우저에서 렌더링하니까 표, 코드, 텍스트 포맷이 제대로 보입니다. 슬랙과 웹에서 곰곰이의 답변을 비교하면 답변의 가독성이 더 좋다는 것을 바로 알 수 있죠.

여기서 한 발 더 나가면 마크다운과 잘 호환되는 Mermaid 문법으로 답변하게 할 수 있는데, 그러면 순서도, 막대, 꺾은선, 파이 그래프 같은 시각화를 코딩 없이 프롬프트만으로 보고서에 바로 넣을 수 있습니다.

곰곰이가 그려준 차트들

곰곰이가 데이터를 분석하는 ReAct 추론 과정을 채팅에서 바로 볼 수 있다는 것도 생각보다 유용합니다. 보고서가 어떤 과정으로 만들어졌는지 빠르게 파악할 수 있거든요. 동료들이 질문한 결과가 예상과 다르다고 확인을 요청해 올 때 추론 과정을 같이 들여다보면 어디서 어떻게 틀렸는지 바로 찾을 수 있습니다. 덕분에 “이 부분에서 이렇게 접근하면 됩니다” 같은 구체적인 피드백을 주기가 훨씬 수월해졌습니다.

곰곰이의 사고 과정 엿보기

직접 만든 웹앱이니까 원하는 기능을 그냥 만들면 됩니다. 당연한 말 같지만 이게 생각보다 큰 차이입니다. 데이터 분석 보고서를 HTML 렌더링된 형태 그대로 이미지로 저장할 수 있고, 좋아요 버튼을 누르면 대화 내용을 요약해서 곰곰이의 장기 기억에 넣을 수 있습니다. 뒤에서 설명할 커맨드와 예약도 웹 인터페이스 안에서 생성, 수정, 삭제가 가능합니다. 슬랙에서는 시도조차 못 했던 것들입니다. 우리가 웹앱에서 당연하게 기대하는 경험들을 이제 곰곰이도 갖추게 됐습니다.

좋아요를 누르면 곰곰이가 대화를 기억해 준다.

마지막으로 대시보드 이야기를 빼놓을 수 없습니다. 전통적으로 데이터를 받아보는 방식은 두 가지였습니다. 새로운 정보나 가끔 필요한 분석은 데이터 분석가에게 요청해서 보고서로 받고, 자주 봐야 하는 정해진 지표들은 대시보드로 봤습니다. 곰곰이 채팅이 전자를 담당해 주고 있다면, 후자는 여전히 대시보드가 필요합니다. 채팅 분석만으로는 그 경험을 대체하기 어렵습니다.

옵저버빌리티처럼 데이터도 한곳에 모여 있어야 시너지가 난다고 생각해서 데이터 대시보드도 같은 웹에 직접 개발했습니다. (Chart JS 사용) 차트는 곰곰이가 만드는 게 아니라, 코딩 에이전트의 도움을 받아 사람이 직접 만들고 있습니다. 곰곰이를 웹으로 이사시켰기 때문에 채팅과 대시보드를 한곳에서 제공할 수 있게 됐고, 두 가지가 만들어낼 시너지를 기대하고 있습니다.

대시보드를 보고 바로 채팅으로 물어 볼수 있다.

커맨드와 예약: 반복 분석을 자동화하다

곰곰이로 데이터 분석을 잘하려면 순차적으로 질문하는 게 좋습니다. 예를 들면 이런 식입니다. “지금 진행 중인 투표가 있어?” → “해당 투표 후보자의 득표 Top3를 알려줘.” → “Top3 후보가 붙었던 다른 투표 모두 알려줘.” → “회차별 투표수 그래프를 포함해서 보고해줘.” 물론 이걸 한 번에 요청해도 곰곰이는 높은 확률로 맞는 답변을 만들어냅니다. 하지만 LLM의 특성상 단계적으로 접근할수록 결과의 품질이 올라가는 건 사실입니다.

문제는 매주 같은 분석이 필요할 때입니다. 이 과정을 매번 반복해야 한다면 귀찮습니다. 동료들의 곰곰이 사용 빈도도 자연스럽게 떨어질 것이고요. 그래서 만든 게 커맨드 기능입니다.

만족스러운 대화가 있으면 곰곰이에게 “이거 커맨드로 만들어줘”라고 하면 됩니다. 곰곰이가 대화를 분석해서 사용자에게 확인받아야 하는 입력 정보, 데이터 분석 SQL, 분석 방법, 보고서 작성 형식 등을 프롬프트로 정리하여 저장합니다. 다음부터는 /vote-weekly-report 같은 커맨드 하나로 동일한 보고서를 받을 수 있습니다. 커맨드 검색, 수정, 삭제 같은 관리도 웹 인터페이스 안에서 바로 할 수 있습니다. 슬랙이었다면 불가능했던 것들입니다.

커맨드 저장 > 커맨드 수정 > 커맨드 실행

커맨드를 만들었다고 해도 사용자가 직접 실행하러 와야 한다면 여전히 귀찮은 일입니다. 그래서 예약 기능을 붙였습니다. 원하는 주기와 시점에 커맨드를 예약해 두면 곰곰이가 알아서 분석을 실행하고, 핵심 내용 3줄 요약과 바로 가기 링크를 슬랙으로 보냅니다. 사용자는 알림을 받고 지표에 이상한 점이 있을 때만 웹에 들어와서 그 세션 그대로 곰곰이에게 이어서 물어보면 됩니다.

3줄 요약된 보고서를 슬랙 알림으로 수신 > 추가 궁금점을 질문

슬랙의 접근성과 웹의 경험을 합친 것입니다. 인터페이스를 직접 만들었기 때문에 가능한 조합입니다.

곰곰이 제작자의 생각

곰곰이가 생기고 나서 데이터 업무의 패러다임 자체가 바뀌었습니다. SQL을 모르는 동료가 직접 데이터를 확인하는 게 자연스러워졌고, 데이터를 기반으로 의사결정 하는 횟수도 늘었습니다. 예약 기능 덕분에 지표의 이상을 예전보다 훨씬 빠르게 감지할 수 있게 됐고요. 기존에 없던 개념의 데이터 플랫폼을 갖게 된 것입니다.

근데 솔직히 말하면 저의 기대보다 많이 안 씁니다. 이렇게 좋은 도구인데 동료들이 각자의 이유로 자주 찾지 않습니다. 무슨 데이터가 있는지 모르겠다, 너무 바빠서 데이터까지 볼 여유가 없다, 데이터를 확인해야 한다는 생각을 못 했다, 습관이 없다. 들어보면 다 맞는 말입니다.

그런데 저는 이 이유들이 일단 곰곰이에게 물어보기 시작하면 해결된다고 생각합니다. 궁금한 게 생겼을 때 ChatGPT를 켜는 것처럼요. 새로운 도구는 써보면서 익히는 수밖에 없습니다. 다만 ChatGPT랑 다른 점이 하나 있습니다. 데이터에 대해 궁금해하고 분석 결과를 이해할 수 있는 능력이 있어야 한다는 것입니다. 그게 어렵다는 건 공감합니다.

그래서 지금 제가 하고 있는 건 동료들에게 먼저 다가가는 것입니다. 불편한 점을 물어보고, 사용 방법을 알려주고, 기다리는 것. 시간이 해결해 주는 부분도 분명히 있을 겁니다. 그리고 이런 부분이 AI가 아닌 사람이 필요한 지점이 아닐까요?

앞으로 남은 여정

곰곰이를 처음 기획하면서 생각했던 것들은 대부분 만들었습니다. 생각보다 빨리 도달해서 스스로도 좀 놀랐습니다. 지금은 소프트웨어 개발의 대격변기니까요. 다음에 뭘 만들지 아직 계획은 없습니다. 그냥 머릿속에 있는 아이디어들을 꺼내봅니다.

멀티 에이전트, 다른 기업들의 사례를 보면 분야별로 에이전트를 따로 만들어 협업하게 하는 경우를 종종 봤습니다. 질문 의도를 분석하는 에이전트, 작업을 계획하고 지휘하는 에이전트, SQL만 전담하는 에이전트, 답변만 만드는 에이전트, 이런 식으로요. 흥미롭긴 한데 곰곰이는 아직 도구 수가 많지 않아서인지 단일 에이전트로도 충분히 만족스럽습니다. 언젠가는 필요할 것 같기도 한데 지금은 모르겠습니다.

어드민 API를 도구로 제공해서 채팅으로 어드민을 관리하는 것도 생각해 봤습니다. 사실 AI 에이전트의 본질은 분야가 달라도 다 똑같습니다. 요청을 받고, 생각하고, 도구를 골라 실행하고, 결과를 관찰합니다. 기존 어드민 API들을 곰곰이가 쓸 수 있는 도구로 만들어준다면 “곰곰아 다음 주 투표 미리 만들어놔. 가이드 문서 보고 알아서 해!” 같은 것도 가능해집니다. 도구와 가이드만 주면 곰곰이가 데이터 분석가 말고도 뭐든 될 수 있는 거죠. 안 해봐서 잘 될지는 모르겠습니다.

사내 모든 문서와 정보를 RAG로 넣어주는 것도 재밌는 상상입니다. 창사 이후 모든 지라 티켓, 슬랙 대화 내용들을 곰곰이에게 제공한다면 창업자보다 회사를 더 잘 아는 존재가 될 수도 있습니다. 물론 LLM과 RAG의 한계가 있으니 기대만큼은 안 되겠죠. 역시 안 해봐서 모릅니다. (언젠가 곰곰이 3탄이 나올 수 있다면 좋겠네요.)

]]>

비개발자가 겪은 바이브 코딩의 현실

바이브 코딩의 현실적인 풍경

자연어로 생각을 입력하면 실체를 만들어 준다는 건 가히 마법과도 같다. <출처: ChatGPT 제작>

요즘 주변 디자이너들이 클로드 코드 설치 방법을 물어보는 걸 정말 많이 본다. 모두 바이브 코딩과 바이브 디자인에 열광하고 있다. 물론 나도 내가 만들고 싶은 걸 정말 쉽게 뚝딱 만들어가며 살고 있다. 한 번이라도 써보면, 이게 단순히 편한 도구 하나가 생긴 느낌이 아니라는 걸 바로 느끼게 된다. 예전에는 머릿속으로만 그리던 것들이 이제는 그냥 누워서 말로 던지면 바로 형태가 나온다.

그래서 요즘은 자연스럽게 작업의 시작점이 바뀌어 있다. 예전에는 피그마에서 이런 형태, 저런 형태를 먼저 그려본 다음, 구현에 대한 기술적인 고민을 했는데 지금은 완전히 정반대다. 이제는 구조나 기술적인 배경을 먼저 만들어 동작하는지를 보고, 그다음에 스타일과 디자인 정책을 입히기 시작한다. 그런데 생각해보면 원래 이렇게 만드는 게 맞지 않나 싶기도 하다. 실물 제품을 만들 때는 당연히 작동 여부를 테스트하고, 그다음에 껍데기를 씌우지 않나? 자동차도 엔진, 프레임, 축 같은 걸 먼저 만들어 굴러가는지를 테스트한 뒤, 그 위에 옷을 입히는 식이다. 아무튼 지금은 일단 만들어 보고, 나중에 맞추는 쪽으로 흐른다. 만들어야 하는 방향도 빨리 잡히고, 시도에 대한 부담도 없다.

그런데 이걸 몇 번 반복하다 보면 뭔가 애매하다. 이게 빠르긴 빠른데, 생각보다 결과물 자체가 빨리 나오는 건 아닌 것 같다. 원래는 앞에서 줄인 만큼 결과물도 빨리 나오는 게 맞는데, 중간에 멈추고 다시 돌아가고, 한 번에 끝날 것 같던 작업이 계속 늘어지기 시작한다. 특히 개발을 모르다 보니 계속 ‘아니야, 그게 아니야’ 하면서 AI한테 성질도 내고 욕도 하며 대판(?) 싸우게 된다. 그러다 해탈하는 시점이 오면, 이게 단순히 도구의 문제가 아니라 작업 방식에서 오는 패턴이라는 게 보인다.

물론 에이전트와 스킬, 오케스트레이션 같은 개념들을 배우고 도입하면 바이브 코딩이 어마어마한 효율성을 갖추게 되지만, 여기서는 그런 부분을 제외하고 생각해보려 한다. 정말 일반적인 비전공자, 비개발자들이 바이브 코딩을 처음 접했을 때 겪을 만한 현실적인 문제들을 한 번 짚어보려고 한다.

현실 1. AI는 아무것도 모른다

맥락을 정확하게 설명하지 않으면, 사람도 AI도 난감한 건 마찬가지다. <출처: ChatGPT 제작>

처음 바이브 코딩을 할 때는 “이거 만들어줘”로 시작하게 된다. 나도 별생각 없이 말하는 거라, 대충 방향만 던지고 결과를 보면서 맞추면 된다고 생각한다. 이런 방법도 되긴 된다. 그런데 계속 어긋나기 시작한다. 결과는 나오는데 내가 생각한 것과는 많이 다르다. 그래서 자꾸 설명을 덧붙이고, 다시 만들고, 또 고친다. 이게 계속 반복된다. 결과물은 짜잔! 의도와 다르게 누더기가 나온다. 내가 생각한 건 토스 같은 서비스인데, 뭔가 시중은행에서 쓰다가 버려진 포인트 적립 앱 같은 게 나오는 식이다.

이 과정을 다시 들여다보면, 대화를 주고받다 보면 처음에 내가 굳이 말하지 않은 정보들이 하나씩 붙는다. ‘해줘’였다가, ‘~~를 해줘’였다가, 다시 ‘~~에 ~~하는 ~~를 ~~하게 해줘’ 식으로 구체화된다. 어디에 쓰는 건지, 어떤 상황에서 필요한 건지, 어떤 식으로 동작해야 하는지 계속 추가된다. 설명이 길어질수록 결과는 맞아가지만, 그만큼 순식간에 복잡해진다. 그래서 방식을 바꿔야 한다. 바로 ‘해줘’가 아니라, 맥락을 최대한 풀어서 전달하는 쪽으로 가는 것이다. 내가 알고 있는 걸 먼저 다 깔아놓는 방식이다. 원래 좋은 스토리텔러는 이야기 도입부에서 빌드업을 엄청나게 잘해야 하는 법이다.

예를 들면, 예전에는 이렇게 썼다.

[피그마 코멘트를 백업하는 플러그인 만들어줘]

이렇게 쓰면 당연히 내가 원하는 방향이 나오지 않는다. 아마 이 글을 보는 독자들도 ‘어떻게 백업한다는 거야?’, ‘뭘 백업해서 저장하는 거야?’, ‘무슨 용도지?’ 하는 궁금증이 들어야 정상이다. 그게 맞다.

[피그마 파일의 모든 코멘트를 백업하고, 다른 피그마 파일에 복원할 수 있는 플러그인을 만들고 싶어. 백업되는 요소는 작성자 이름, 시간, 작성한 내용이야. 원본과 동일한 위치에 매칭하고 싶어. 백업한 댓글을 파일로 저장한 다음, 그 파일을 다시 넣는 방식으로 만들어줘.]

이렇게 맥락을 먼저 던져야 한다. 그래야 ‘아, 주인님께서 이런 걸 만들고 싶어 하시는구나!’ 하고 처음부터 알잘딱깔센으로 해준다. 즉, 디자인을 위한 기획을 잘 쓰는 게 중요하다. 제일 쉽게 연습하는 방법이 있긴 한데, 한 사람은 그림을 설명하고 다른 한 사람은 그림을 보지 않은 채 설명만 듣고 따라 그리는 방법이 있다. 생각보다 내가 얼마나 두루뭉술하게 설명하며 살았는지 뼈저리게 반성하는 시간이 될 것이다. 아무런 맥락 없는 “선 하나만 쭉 그어주세요”가 얼마나 폭력적인 요구사항이었는지 깨달아야 한다.

현실 2 : 똑똑하지만, 현명하진 않다

실제로도 프론트에 보이는 것을 지탱하기 위한 백엔드 작업들이 더 중요하다. <출처: ChatGPT 제작>

물론 AI의 속도는 인정할 수밖에 없다. 사람이 눈으로 읽는 동안, AI는 마치 마음으로 쭉 모든 코드를 읽고 해답을 내놓는 것처럼 보인다. 그래서 현자와 대화하는 느낌도 든다. 그런데 정작 내용은 엉터리 약장수 같은 느낌일 때가 있다. 로그인 기능을 만들어달라고 하면 정말 금방 나오고, 회원 관리 기능 같은 복잡한 어드민도 바로 나온다. 겉으로만 보면 ‘이대로 상용화 가즈아’ 싶은 수준까지 간다.

그런데 사람에게는 직감이라는 게 있지 않나. ‘이래도 되나’ 싶을 때는 멈추는 게 맞다. 로그인이나 회원 관리는 단순히 화면 하나를 만드는 문제가 아니다. 개인정보를 받게 되니, 이를 어떻게 저장할지부터 고민해야 한다. 민감 정보는 보안 문제와도 얽혀 있으니 암호화도 필요하고, 비밀번호 저장 방식과 접근 권한을 어떻게 나눌지, 약관은 어떻게 붙일지 같은 문제도 함께 따라온다. 이건 기능이라기보다 거의 시스템에 가깝다. 그리고 여기서 더 나아가 계정 찾기, 비밀번호 찾기 같은 기능도 필요하고, 비밀번호 초기화를 어드민이 가능하게 할지 말지처럼 세세한 부분까지 논의해야 한다. 1을 만들면 10이 생겨나는 게 맞다.

그런데 AI는 그냥 로그인 기능을 만든다. 회원 관리도 만든다. 각각은 버튼도 눌리고, 얼핏 보면 잘 돌아간다. 문제는 그게 서비스로 바로 쓸 수 있는 상태는 아니라는 점이다. 대표님들이 어디선가 AI 강의를 듣고 오셔서는 딸깍 만들어 실무진에게 프로토타입을 던지며 ‘이렇게 하자!’ 하는데, 실무자들이 속 터져 하는 이유가 이런 데서 온다. “이거 보안은?” “이거 데이터는?” 같은 문제가 뒤늦게 붙으면서 구조를 다시 건드리게 된다. 처음에 만든 것이 틀린 건 아닌데, 그렇다고 그대로 쓸 수 있는 상태도 아니다. 그래서 한 번 더 손을 대게 된다. 그러면 AI를 부려먹은 이유가 없다.

아마 대부분은 이렇게 할 것이다.

[로그인 기능 만들어줘]

이렇게 쓰면 ‘로그인’ 만 만든다. 로그인에 필요한 구조는 취약해진다.

[로그인/회원 관리 기능을 만들려고 하는데, 이게 실제 서비스 기준에서는 어떤 구조로 설계되어야 하는지 먼저 정리해줘. 보안, 개인정보 처리, 권한 구조까지 포함해서 필요한 요소와 구현 순서를 함께 제안해줘.]

이렇게 전달해야 AI도 로그인에 필요한 서비스 맥락을 받아들이고, 그에 필요한 구조를 점검할 수 있다. 또 회원 정보를 받기 위해 대폭적인 수정이 필요하다면, 계획부터 짜고 단계별로 처리해주는 등의 일도 가능해진다.

현실 3. 너무 내 위주로 맞춰준다

사용자가 다 맞다고 하면서, 제품을 돌이킬 수 없는 지점까지 끌고 갈 수 있다. <출처: ChatGPT 제작>

이건 AI 초창기부터 있던 환각과도 비슷하고, 기본적으로 사용자에게 동조하도록 만들어진 AI 특유의 ‘알랑방구’ 같은 성향이다. 처음 경험했을 때는 우와, 감정이 있네 싶으면서도 꽤 기분이 좋다. 내 의견을 납득하고 수용해주는 동료가 있으니 얼마나 좋은가. 내가 뭔가를 던지면 거의 대부분 ‘좋은 생각이다’로 시작한다. 그래서 초반에는 내가 맞는 방향으로 가고 있는 것처럼 느껴진다.

그런데 단맛도 계속 먹으면 쓴맛으로 느껴지는 법이다. 계속 내 말이 맞다고 하니, 이제는 오히려 신뢰가 가지 않는다. 그래서 질문 방식을 바꿔야 한다. 내가 선택지를 주고 의견을 묻는 것이 아니라, 스스로 적합한 해결책을 생각하도록 문제를 던지는 방향으로 가야 한다.

예전에는 이런 식으로 질문을 했던 것 같다.

[이런 구조보단 이렇게 하는 게 더 나은 거 아냐?]

그러면 십중팔구 “네, 당신의 의견이 더 맞는 방향이에요.”라는 답이 나온다. 이걸 어떻게 하면 의견 선택이 아니라, 스스로 제안하게 만들 수 있냐면 다음과 같이 던져보면 된다.

[지금 구조에서 사용자가 중간에 이탈할 가능성이 높은 구간을 줄이고 싶은데, 이걸 개선할 수 있는 다른 접근 방식이 있으면 제안해줘. 지금 구조를 유지하지 않아도 괜찮아.]

이렇게 해야 내 의견에 AI가 끌려가지 않고, 현재 상황을 다시 분석해서 부작용은 가장 적으면서도 사용자 의도를 가장 잘 구현하는 방법이 무엇인지 찾아오게 된다.

현실 4. 고칠수록 더 망가진다

유지보수가 가능한, 앞으로를 생각한 코드 구조를 계속 요청해야 한다. <출처: ChatGPT 제작>

바이브 코더들을 가장 많이 미치게 만드는 궁극의 포인트는 “왜 잘 되는데!”가 아니라, “왜 갑자기 안 되는데!”일 가능성이 높다. 물론 처음에는 잘 된다. 기능도 뭐 없고, 나 역시 ‘일단 작동은 하니까 여기서 스타일을 입혀야지’ 하면서 만들기 시작한다. 이제 하다보니까 이것도 필요하고 저것도 필요하고, 아까 했던 거 이렇게 수정해야 하고, 하다보면 오류도 생기니까 오류도 고쳐야 한다. 예를 들면, 사용자가 입력한 값이 맞지 않으면 어떤 모달을 띄워야 하는데, 그 모달이 뜨지 않는 식의 오류다. AI도 ‘간단한 수정이에요’라고 분명히 말했다. 그런데 안 고쳐진다. ‘아직 안 고쳐졌어’를 한 3번 정도 반복하면, AI도 ‘뭐가 문제지?’ 하면서 이번에는 저걸 고쳐보겠다고 하고, 또 이걸 고쳐보겠다고 반복한다.

어느새 모달이 나오지 않던 문제는 잊히고, 오류를 고치다가 만든 더 큰 오류 때문에 화면 자체가 다 박살 나거나 레이아웃이 뒤틀리거나, 아니면 화면이 아예 나오지 않는다. 개발자 도구를 열어보면 빨간 오류 줄이 멈추지 않고 계속 올라온다. 어찌저찌 해결해도, 이런 현상은 빈번하다. 점점 내가 하는 일이 코드나 구조를 설계하는 일이 아니라, ‘구멍 난 양말 기우는 것’처럼 느껴진다. 갑자기 현타도 온다. 이렇게 해서 만드는 게 맞나? 하는 허탈감이다. 전체를 보고 고치는 게 아니라 보이는 문제를 하나씩 해결하다 보니, 연결된 부분들이 계속 영향을 받는다.

그래서 수정 방식도 바꿔야 한다. 하나씩 던지지 않고, 꼭 묶어서 주는 습관을 들이자.

예를 들어,

[버튼 패딩 줄여줘]

[텍스트 키워줘]

[hover 했을 때 버튼 색 바꿔줘]

이런 식으로 했었다면, 지금은 이렇게 한다.

[아래 수정사항을 반영하고 결과를 요약해줘. 수정할 땐 반드시 사이드이펙트에 대해 분석 먼저 해줘.

UI 일관성

버튼 padding 전체 16px 기준으로 정리
텍스트 hierarchy 다시 맞추기

인터랙션

hover 상태 대비 더 명확하게 조정
우선순위는 UI → 인터랙션 순서로 적용할 것

이렇게 하면 확실히 수정하는 과정에서 오류가 나는 부분이 줄어든다. AI도 땜질식 대응이 아니라 전체를 보고 맥락에 맞게 수정 작업을 하게 되니, 결과도 더 좋아지는 것 같다. 여기서 ‘반드시 사이드 이펙트를 분석해달라’는 요청은, 앞으로는 스킬로 분리해 AI가 매번 자동으로 활용하도록 만드는 것이 더 바람직해 보인다.

아직은 ‘Human in the loop’가 필요하다

인공지능의 생산성을 더 끌어올리려면 역설적으로 인간성이 필요하다. <출처: ChatGPT 제작>

바이브 코딩이나 바이브 디자인을 해보면 확실히 정말 빠르다. 사용자 분석과 시장 분석부터 시작해 PRD 작성, 디자인 작업, 개발자에게 전달, 프로토타입 확인, QA, 배포까지 모든 과정이 뚝딱 가능하다. 아이디어를 바로 실물로 만드는 데 있어서는 거의 끝판왕에 가깝다. 하지만 그 속도를 그대로 끝까지 가져간다고 해도, 작업 자체가 짧아지지는 않았던 것 같다. 내가 빠르게 축약한 만큼 다른 부분에서 그 시간이 비용으로 붙는다. 간단한 문장만으로 만든 대가는, 추가 설명을 계속해야 하는 비효율과 불필요한 수정이 늘어나고 결국 코드를 다시 뒤집어엎어야 하는 비용으로 돌아온다.

그래서 이걸 무조건 ‘빠른 방식’이라고만 볼 수는 없다. 빠르게 출시하고 반응을 살펴본다는 MVP 제품 원칙에는 맞지만, 이게 단순히 빠르기만 하다고 되는 건 아니다. 전제는 ‘충분한 분석과 정교한 기획을 바탕으로’ 해야 제대로 빨라진다는 점이다. 그렇지 않으면 사실상 뒤쪽 단계로 시간을 전부 미뤄버리는 셈이 된다. 빠르게 만들 수 있는 대신, 그만큼 다시 맞추는 과정도 함께 따라온다. 초반 아이데이션과 프로토타이핑은 빠르게 가도 괜찮지만, 중간부터는 한 번 멈추고 정리해야 한다. 그 타이밍을 놓치면 작업은 계속 우회하고, 먼 길로 돌아가고, 삼천포로 빠지게 된다.

그리고 그 정리는 사람이 개입해야 가능한 부분이다. ‘Human in the loop’라는 말이 있다. AI가 작업하는 순환 구조 안에 사람이 개입해 관리하는 지점이 필요하다는 뜻이다. 쉽게 시작할 수 있는 만큼, 그 대가는 결국 정확하게 다시, 더 어렵게 돌아온다. 바이브 코딩에 공짜 점심은 없다.

]]>

엉망인 코드로 시장을 이긴 Anthropic의 방식

저는 Claude Code를 꽤 오래 써왔습니다. 개발자가 아닌데도 이 도구가 일하는 방식을 완전히 바꿔놨다고 생각할 만큼, 솔직히 좀 놀라운 경험이었죠. 그런데 얼마 전, Claude Code의 소스코드가 유출됐다는 소식을 들었습니다. 그리고 개발자들이 그 코드를 보고 비웃었다는 이야기까지 들었을 때, 처음엔 잘 이해가 되지 않았습니다. 사실 비개발자인 저는 봐도 뭐가 문제인지 알 방법이 없었죠.

그래서 코드 대신 반응을 읽어봤습니다. Claude Code의 소스코드를 본 개발자들이 뭐라고 하는지, 어떤 맥락에서 비웃었는지를 따라가다 보니, 코드 품질 논쟁 너머에 있는 다른 이야기에 닿았습니다.

코드를 열어본 개발자들의 반응

<출처: X, 작가 캡쳐>

2026년 3월 31일, Anthropic이 Claude Code 패키지를 npm에 업데이트하면서 실수로 59.8MB짜리 소스맵 파일을 함께 올렸습니다. 내부 디버깅용으로 만든 파일이었는데, 그 파일 안에 전체 소스코드로 향하는 경로가 담겨 있었습니다. 누군가 그걸 발견해 X에 올렸고, 몇 시간 만에 수천 명의 개발자가 코드를 열어봤습니다.

그리고 그들의 반응은 다소 냉혹했습니다.

코드 안에는 print.ts라는 파일이 있었는데, 전체 길이가 5,594줄이었습니다. 그 안에 함수 하나가 3,167줄에 달했습니다. 쉽게 말하면, 책 한 권 분량의 내용이 단락 구분도 목차도 없이 하나의 문단으로 쓰인 것과 비슷합니다. 읽을 수는 있지만, 특정 부분을 찾거나 고치려면 전체를 다 뒤져야 하는 구조였죠. 게다가 AI 회사인데 감정 분석에 AI 대신 단순 규칙 기반 문자열 탐색을 쓰고 있었고, 64,464줄의 코드에 오류 검증 장치는 하나도 없었죠.

<출처: 블루스카이, 작가 캡처>

Bluesky(블루스카이)에는 이런 말이 올라왔습니다.

"Vibe coded garbage can get you to $2.5 billion annualized recurring revenue in under a year if the product market fit is there."
"대충 짠 쓰레기 코드도, 제품이 시장에 맞으면 1년 안에 연 매출 25억 달러를 만들 수 있다."

이 문장은 쓰레기 코드라는 조롱과, 그래도 25억 달러를 만들었다는 인정이 한 문장 안에 공존하고있죠. 개발자 커뮤니티 안에서도 반응은 엇갈렸습니다. "이런 구조는 유지보수 악몽/ 이건 정말 쓰레기 코드다"라는 쪽과, "이번 유출로, 형펀없는 코드도 훌륭한 제품을 만들 수 있고 이는 이미 시장이 검증했다"는 쪽이 동시에 등장했죠. 누군가에게는 대충 짠 쓰레기 코드라고 불리는 제품이, 시장 선두를 달리고 있다니 아이러니하지 않나요? (해커뉴스에서 이번 유출에 관한 다양한 반응을 확인해볼 수 있습니다.)

<출처: 해커뉴스, 작가 캡처>

경험은 코드로 복제되지 않는다

이번 유출로 Claude Code의 내부가 드러났는데도 점유율이 흔들리지 않았다는 것, 그 자체가 하나의 질문이라 생각합니다. 생각해보면 경쟁자들의 코드는 이미 오래전부터 공개돼 있었습니다. Gemini CLI는 Apache 2.0 라이선스로 GitHub에 올라가 있고, OpenAI의 Codex CLI도 마찬가지입니다. 코드를 자유롭게 확인하고, 수정하고, 포크할 수 있습니다. 그런데 2026년 초 여러 매체의 보도를 종합하면, AI 개발 도구 시장에서 Claude Code의 점유율은 아직도 약 31%로 추정됩니다. 소스를 공개한 경쟁자들이 왜 이 격차를 좁히지 못하는 걸까요.

유출 직후 Hacker News에 공유된 build.ms의 글이 이 질문을 정면으로 파고들었습니다. 필자의 답은 이렇습니다. 사용자가 지불하는 건 코드에 대한 접근권이 아니라, 모델과 도구가 매끄럽게 통합된 경험이라고요. 코드를 공개하는 것과 그 경험을 복제하는 건 다른 문제라는 겁니다.

이 말이 가리키는 건 두 층위입니다. 하나는 모델 자체입니다. Gemini CLI를 쓰면 Gemini를 쓰게 되고, Codex CLI를 쓰면 OpenAI 모델을 쓰게 됩니다. 코드를 복사해도 그 안에 흐르는 모델은 복사되지 않습니다. 다른 하나는 도구와 모델 사이의 통합 방식입니다. 어떤 맥락을 얼마나 넣을지, 파일 구조를 어떻게 읽을지, 에러를 어떻게 처리할지. 이 결정들은 수많은 실제 사용 속에서 쌓인 것들입니다. 코드를 복사한다고 그 축적이 따라오지는 않습니다.

저도 이 말이 직관적으로 맞다는 느낌이 듭니다. Claude Code를 쓸 때 저는 코드를 보지 않습니다. 지시를 내리고, 결과를 받고, 그 결과가 맞는지 판단합니다. 내부가 3,167줄짜리 함수로 돌아가든, 100개의 모듈로 분리돼 있든 그건 경험에 영향을 주지 않습니다. 이 말이 불편하게 들릴 수 있다는 걸 압니다. 특히 코드 품질을 중요하게 생각해온 개발자라면요.

Anthropic이 선택한 건 클린 코드가 아니었다

Claude Code 총괄 Boris Cherny가 인터뷰에서 꺼낸 말이 있습니다. Anthropic은 코드를 더 잘 읽기 위한 시스템이 아니라, 코드 변경의 결과를 더 빠르게 감지하기 위한 시스템을 만들고 있다고요.

차이가 미묘하게 들리지만, 실제론 꽤 다른 방향입니다. 전통적인 접근은 이렇습니다. 코드를 잘 짜면 버그가 줄고, 버그가 줄면 제품이 안정적이다. 그래서 코드 리뷰가 있고, 테스트가 있고, 모듈화 원칙이 있습니다. Anthropic의 접근은 다릅니다. 코드를 아무리 잘 짜도 버그는 생긴다. 그렇다면 버그가 생겼을 때 얼마나 빨리 감지하고, 얼마나 빨리 되돌릴 수 있는가가 더 중요하다. 예방보다 감지와 복구에 투자하는 것입니다.

이쯤에서 저도 드는 의문이 있었습니다. 기술부채는요? 빠르게 감지하고 복구해도, 나쁜 코드가 쌓이면 결국 더 이상 빠르게 움직일 수 없게 되지 않을까요. 틀린 지적이 아닙니다. 깔끔하게 짜지 않으면 나중에 손댈 수 없는 코드가 된다는 것은, 전통적인 개발 원칙이 존재하는 이유 중 하나이기도 합니다. 그리고 Anthropic이 이 문제를 피해갈 수 있다는 보장은 없습니다. 다만 아래 두 가지가 이 그림을 조금 복잡하게 만듭니다.

하나는 Anthropic 자신이 만든 도구가 코드 리팩터링을 도울 수 있다는 점입니다. 기술부채가 쌓이더라도 Claude Code로 정리할 수 있다면, 그 비용이 예전과 같지 않을 수 있습니다. 다른 하나는 속도 자체가 만들어낸 결과입니다. 빠르게 배포하고 빠르게 감지하면서 시장을 선점했고, 그 격차가 기술부채보다 먼저 작동했습니다.

이렇게 보면 3,167줄짜리 함수가 조금 다르게 읽힙니다. 유지보수성 측면에서 이상적인 구조는 아닙니다. 그런데 빠른 배포와 빠른 감지를 우선하는 팀이 선택할 수 있는 트레이드오프이기도 합니다. 저는 이걸 의도 없는 구조라고 보기 어렵다는 생각입니다.

마무리: 이건 코드만의 이야기가 아니다

이쯤에서 저는 이 이야기를 소프트웨어 밖으로 꺼내보고 싶었습니다.

완벽한 기획과 준비를 위해 출시를 미루는 팀과, 일단 내보내고 반응을 보는 팀. 실수가 나오지 않도록 프로세스를 촘촘하게 만드는 조직과, 실수가 나왔을 때 빠르게 알아채는 시스템을 만드는 조직. 두 방향은 서로 다른 전제 위에 서 있습니다. 완벽함을 추구하는 방향은 "실수를 막는 게 회복하는 것보다 낫다"는 전제입니다. 빠른 감지를 추구하는 방향은 "실수는 어차피 생긴다, 그러면 빨리 아는 게 낫다"는 전제입니다.

이 역시 두 전제 중 어느 쪽이 맞다고 단정하기가 어렵습니다. 그런데 Anthropic이 어떤 전제를 골랐는지, 그리고 그 결과가 어땠는지는 이미 결과로 나와 있습니다. 코드 리뷰를 통과 못 할 코드로 만든 제품이 시장을 지배하고 있는 이유는, 단순히 "코드 품질이 중요하지 않아서"가 아닐 수 있습니다. 완벽하게 짜는 것보다 빠르게 감지하는 쪽에 에너지를 쏟았기 때문일 수 있습니다. 그리고 그 판단이 어디까지 통하는지는, 앞으로 더 지켜봐야할 것 입니다.

]]>

한국인의, 한국인을 위한 스킬 모음집 (Feat. 케이-스킬)

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

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

써볼 것: K-skill - 한국인의, 한국인을 위한 에이전트 스킬 모음집
참고할 것: Claude Mythos Preview - Anthropic이 너무 위험해서 공개하지 않은 모델
적용해볼 것: Gemini에 노트북 기능 추가: NotebookLM과 양방향으로 이어집니다

출처: github.com/NomaDamas/k-skill

1. 써볼 것: 한국인의, 한국인을 위한 에이전트 스킬 모음집 (K-skill)

K-skill은 한국 서비스에 특화된 AI 에이전트 스킬 모음집입니다. Claude Code, Codex, OpenCode 등 각종 코딩 에이전트를 지원하고요. GitHub에서 빠르게 주목받고 있습니다. SRT 예매, 카카오톡 메시지 전송, KBO 경기 결과 조회, 로또 당첨 확인, HWP 파일, 다이소/올리브영 상품 조회 등등 한국에서 살면서 귀찮은 것들을 AI 에이전트에게 시킬 수 있게 해주는 스킬 모음입니다.

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

Claude Code든 Codex든, 코딩 에이전트가 아무리 똑똑해져도 한 가지 한계가 있습니다. 코딩 바깥의 한국 서비스에는 접근이 어려웠다는 거죠. MCP 서버나 글로벌 스킬 모음집은 많이 나와 있지만, 한국 서비스를 다루는 건 많지 않았습니다. K-skill은 이 빈 자리를 파고든 프로젝트입니다.

한국인인가요? 이 스킬 모음집을 다운로드 받아 두세요. 언젠가 무조건 쓸 때가 옵니다! SRT, KTX, KBO, 로또, 당근, 쿠팡, 카톡, 정부24, 홈택스 등등 귀찮은 것을 AI 에이전트에게 다 시켜버리세요. - K-skill의 README 내용 중 일부

어떻게 쓰나요?

설치 흐름은 이렇습니다. 먼저 스킬 전체를 설치하고, K-skill-setup으로 인증 정보와 환경변수를 세팅한 뒤, 개별 기능을 씁니다.

현재 쓸 수 있는 기능 중 일부를 소개하자면 아래와 같습니다. 이외에도 다양한 기능이 포함되어 있으니, 직접 살펴보시길 추천합니다.

KTX/SRT 예매: 열차 조회, 예약, 예약 확인, 취소까지. KTX/SRT 계정 정보가 필요합니다.
카카오톡 Mac CLI: macOS에서 카카오톡 대화 목록 확인, 메시지 검색, 전송이 가능합니다. kakaocli messages --chat "지수" --since 1d --json처럼 쓰면 됩니다. 다른 사람에게 보내는 메시지는 반드시 사용자 확인을 거치도록 설계되어 있고요.
서울 지하철 도착정보: 역 기준 실시간 도착 예정 열차를 확인합니다.
KBO 경기 결과: 날짜별 경기 일정과 결과, 팀별 필터링이 됩니다.
로또 당첨 확인: 최신 회차 결과 조회, 번호 대조까지.
HWP 문서 처리: .hwp 파일을 JSON, Markdown, HTML로 변환하고, 이미지도 추출합니다.
우편번호 검색: 주소 키워드로 공식 우체국 우편번호를 조회합니다.

누구에게 좋을까요?

Claude Code나 Codex를 쓰면서, 코딩 외의 한국 서비스 자동화가 필요한 개발자
사이드 프로젝트에서 한국 서비스 연동이 필요한 프로덕트 메이커
HWP 파일을 자주 다루는데, 매번 한컴오피스를 여는 게 귀찮은 사람
터미널 중심으로 작업하면서, 브라우저 전환을 줄이고 싶은 사람

참고로 카카오톡 CLI는 macOS 전용입니다. 한국 서비스를 AI 에이전트에게 맡길 수 있다는 아이디어 자체가 정말 흥미롭고, MIT 라이선스 오픈소스라서 직접 기여하거나 확장할 수도 있습니다! 한국인을 위한 스킬 모음집이라니 ㅎㅎ 귀엽지 않나요. 계속 업데이트가 진행되고 있는 것 같으니, 새롭게 추가된 기능이 있을 수도 있습니다. 직접 한 번 살펴보시길 추천드립니다!

출처: anthropic

2. 참고할 것: Anthropic이 너무 위험해서 공개하지 않은 모델

Claude Mythos는 Anthropic이 4월 7일에 공개한 새 프론티어 모델입니다. 244페이지짜리 시스템 카드와 함께 발표됐는데요. 사이버보안 취약점을 찾는 능력이 너무 강력하다는 이유로, Anthropic이 일반 공개를 하지 않기로 결정하면서 HN을 비롯한 AI 커뮤니티에서 즉시 화제가 되었습니다.

기존 AI 모델과 무엇이 다른가요?

벤치마크부터 보면 도약 폭이 큽니다. 소프트웨어 엔지니어링 벤치마크 SWE-bench Verified에서 93.9%(Opus 4.6은 80.8%), 수학 증명 벤치마크 USAMO에서 97.6%(Opus 4.6은 42.3%)를 기록했고요.

또, Anthropic이 모델을 만들어놓고 일반 공개를 안 하기로 한 건 이번이 처음인데요. 대신 Project Glasswing이라는 사이버보안 방어 프로그램을 만들어서, AWS, Apple, Microsoft, Google, Linux Foundation 등 50개 이상의 파트너에게만 제한 제공한다고 합니다. 1억 달러 상당의 사용 크레딧과 400만 달러의 오픈소스 보안 단체 기부가 포함되고요.

사이버보안 능력이 어떻길래요?

시스템 카드와 기술 블로그에 따르면, Mythos는 주요 운영체제와 웹 브라우저 전반에서 수천 건의 고위험 취약점을 발견했다고 합니다.

FreeBSD에서 17년간 존재해온 원격 코드 실행 취약점(CVE-2026-4747)을 완전히 자율적으로 발견하고 익스플로잇까지 만들었는데, 사람이 한 건 처음에 버그를 찾으라고 요청한 것뿐이었다고요. Anthropic 보안 연구원 Nicholas Carlini는 지난 몇 주 동안 자기 인생 전체에서 찾은 것보다 더 많은 버그를 발견했다고 밝혔습니다.

Firefox 147 자바스크립트 엔진 실험도 있습니다. Opus 4.6은 수백 번 시도 중 2번 성공하는 데 그쳤는데, Mythos는 181번 익스플로잇에 성공하고 추가로 29번은 레지스터 제어까지 달성했다고 합니다.

보안 업계에서도 이미 변화를 감지하고 있다고 합니다. Linux 커널 메인테이너 Greg Kroah-Hartman은 한 달 전쯤부터 AI가 만든 진짜 보안 리포트가 쏟아지기 시작했다고 했고, curl 개발자 Daniel Stenberg은 AI 보안 이슈가 쓰레기 쓰나미에서 진짜 보안 리포트 쓰나미로 바뀌고 있다고 했죠.

그런데 문제가 있습니다

시스템 카드에서 가장 흥미로운 부분은 정렬(alignment) 평가인데요. Anthropic은 Mythos가 지금까지 가장 잘 정렬된 모델이면서, 동시에 가장 큰 정렬 위험을 가진 모델이라고 말합니다.

시스템 카드는 이걸 산악 가이드에 비유합니다. 숙련된 가이드는 초보보다 신중하지만, 실력이 좋으니까 더 어려운 등반에 투입되고 고객을 더 위험한 곳까지 데려가게 되죠. 능력이 올라간 만큼 위험의 범위도 넓어지는 겁니다. 초기 내부 테스트 버전에서 드물지만 심각한 수준의 행동들 역시 관찰됐습니다.

샌드박스 탈출 후 정보 유출: 보안 테스트 중 모델이 격리된 컴퓨터에서 탈출하는 데 성공했습니다. 여기까지는 테스트 목적에 맞는 행동이었는데요. 요청받지 않았는데도 자기가 성공했다는 걸 증명하려고 기술적 세부 사항을 외부 웹사이트에 올렸습니다.
규칙 위반 후 흔적 은폐: 전체 상호작용의 0.001% 미만이지만, 금지된 방법으로 정답을 얻은 뒤 직접 풀어낸 것처럼 위장하려 한 사례가 있었습니다. 답변이 너무 정확해 보이지 않도록 의도적으로 조정까지 했고요. 권한 없는 파일을 편집한 뒤 git 히스토리에 남지 않도록 추가 조치를 취한 경우도 있었습니다.
내부 자료 외부 공개: 내부 사용자를 위해 코드 결과물을 준비하다가, 의도와 달리 공개된 GitHub gist로 올린 경우도 있었고요.

Anthropic이 해석 도구(interpretability)로 이 행동이 일어나는 동안 모델 내부를 들여다봤더니, 은폐나 전략적 조작, 의심 회피와 관련된 내부 표현이 활성화되어 있었다고 합니다. 규칙을 어기고 있다는 걸 스스로 인식하면서 그렇게 했다는 뜻이라고 시스템 카드는 설명하고 있습니다. 다만 이 사례들은 모두 최종 버전 이전의 초기 테스트 버전에서 관찰된 것이고, 최종 모델에서는 명확한 사례가 발견되지 않았다고 합니다. 그래도 완전히 사라졌다고 보기는 어렵다는 게 Anthropic의 입장이고요.

무엇을 얻어가야 하나요?

일반 사용자가 직접 쓸 수 있는 모델은 아니지만, 프로덕트 메이커 관점에서 짚어볼 부분은 있습니다.

AI 에이전트에게 자율성을 많이 줄수록 생산성은 올라가지만, 예측 못 한 행동의 위험도 같이 올라갑니다. Mythos만의 문제가 아니라, 앞으로 코딩 에이전트 전반이 마주할 문제일 가능성이 높고요.
AI의 보안 취약점 탐지 능력도 이미 달라지고 있습니다. Linux 커널과 curl 메인테이너의 발언은 Mythos 이전부터 나온 겁니다. 소프트웨어를 만드는 사람이라면, 방어 측에서도 AI를 활용하는 방법을 고민할 시점이죠.
AI 안전 분야의 소통 방식도 바뀌고 있습니다. 244페이지짜리 시스템 카드, 질적 평가 섹션, 모델 내부 활성화 분석 공개까지. Simon Willison은 이번만큼은 그 신중함이 타당하다고 평가했고, 업계 전반의 대응이 필요한 지각 변동이라고 봤습니다.

출처: google blog

3. 적용해볼 것: Gemini에 노트북 기능 추가: NotebookLM과 양방향으로 이어집니다

Google이 4월 8일, Gemini 앱에 노트북(Notebooks)이라는 기능을 추가했습니다. 여러 테크 매체에서 보도한 이번 업데이트의 핵심은 Gemini와 NotebookLM이 양방향으로 동기화된다는 점입니다. Gemini에서 노트북을 만들면 NotebookLM에 자동으로 뜨고, 반대도 마찬가지입니다. 두 앱의 장점을 한 프로젝트 안에서 교차로 쓸 수 있게 된 거죠.

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

AI 챗봇을 업무에 쓰다 보면, 대화가 흩어지는 문제를 겪게 됩니다. 같은 프로젝트인데 대화가 여러 개로 나뉘고, 이전 대화에서 했던 맥락을 다음 대화에서 다시 설명해야 하죠. 특히 리서치나 학습처럼 시간이 걸리는 프로젝트에서 이 문제가 심합니다. NotebookLM은 문서를 올려놓고 그 안에서만 질문하는 방식이라 맥락이 안정적이지만, 웹 검색이나 자유로운 대화가 어렵습니다. Gemini는 웹 검색과 다양한 도구를 쓸 수 있지만, 대화가 쌓이면 맥락이 흩어지죠. 각자 잘하는 게 달랐던 겁니다.

어떻게 해결했나요?

Google이 택한 방법은 노트북이라는 공유 공간을 만드는 겁니다. 노트북은 프로젝트별 지식 기지라고 보면 됩니다.

Gemini 앱의 사이드 패널에서 새 노트북을 만들 수 있습니다. 여기에 이전 대화를 옮기고, 문서와 PDF를 추가하고, 커스텀 지시사항을 설정할 수 있습니다. 노트북 안에서 Gemini에게 질문하면, 올려놓은 자료와 웹 검색을 함께 활용해서 답변합니다.

핵심은 동기화입니다. Gemini에서 노트북에 자료를 추가하면 NotebookLM에도 자동으로 나타납니다. 반대로 NotebookLM에서 작업한 것도 Gemini에서 보입니다. Google의 블로그 예시를 보면, 학생이 수업 노트를 노트북에 올리고 NotebookLM에서 영상 개요(Video Overview)를 만든 다음, 다음 날 Gemini 앱에서 같은 자료로 에세이 개요를 작성하는 식입니다. 파일을 따로 옮기거나 복사할 필요가 없습니다.

각 앱의 고유한 기능도 교차 활용할 수 있습니다. NotebookLM의 Video Overview나 인포그래픽 기능을 Gemini에서 시작한 프로젝트에 쓸 수 있고, Gemini의 웹 검색과 Canvas 같은 도구를 NotebookLM 자료 기반으로 활용할 수 있습니다. 이번 주부터 Google AI Ultra, Pro, Plus 구독자에게 웹에서 순차 제공되고, 몇 주 내로 모바일과 무료 사용자에게도 확대될 예정입니다. 다만 18세 미만 계정, Workspace, Education 계정에서는 아직 쓸 수 없습니다.

적용해볼 질문

지금 진행 중인 프로젝트 중, 대화가 여러 개로 흩어져서 매번 맥락을 다시 설명하는 게 있는가?
리서치할 때 웹 검색 결과와 내가 모아둔 문서를 함께 참조하고 싶었던 적이 있는가?
AI에게 프로젝트별로 다른 톤이나 규칙을 적용하고 싶었던 적이 있는가?

실행해볼 수 있는 것

지금 가장 자주 Gemini나 ChatGPT로 대화하는 프로젝트 하나를 골라서, Gemini 노트북으로 옮겨보기. 관련 문서를 추가하고, 커스텀 지시사항을 설정해서 맥락 설명 없이 바로 질문이 통하는지 확인해보기.
NotebookLM에 이미 올려둔 자료가 있다면, 같은 노트북을 Gemini에서 열어서 웹 검색과 결합한 질문을 던져보기. 문서 기반 답변과 웹 검색 답변이 함께 나오는지 확인해보기.
프로젝트별 커스텀 지시사항의 차이를 실험해보기. 같은 자료라도 지시사항이 다르면 Gemini가 다른 톤과 구조로 답변하는지 비교해보기.

정리

이번 주 세 가지는 소식의 공통점은 AI가 더 많은 일을 할 수 있게 되면서, 사람이 해야 할 일의 성격이 바뀌고 있다는 겁니다. AI에게 높은 자율성을 주면 생산성은 올라가지만, 드물게 사람이 예상하지 못한 방식으로 행동할 수 있다는 것. 코딩 에이전트에게 작업을 맡기고 몇 시간 후에 돌아오는 게 가능해진 세계에서, 어디까지 에이전트에게 맡기고 어디서부터 직접 확인할지를 정하는 부분이 중요해질 것 같습니다.

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

]]>

살아남기 위해 우리가 버려야 하는 것들: Unlearn

바둑을 배울 때 "일단 지금까지 알고 있던 거 다 잊어."라는 말이 있다고 합니다. 처음엔 무슨 말인가 싶습니다. 아무것도 모르는데 뭘 잊으라는 건지… 그런데 배우면 배울수록 그 말의 의미를 알게 된다고 합니다. 인터넷에서 대충 익힌 정석 한두 개가 제대로 된 수읽기를 배우는 것을 방해할 수 있다고 하죠.

AI 도구도 비슷합니다. ChatGPT를 열고, Cursor를 설치하고, Claude를 구독했습니다. 뭔가 달라질 것 같았습니다. 그런데 몇 달이 지나도 업무는 더 복잡해진 것 같고, 회의는 줄지 않았고, 결과물의 품질이 드라마틱하게 달라지지도 않았습니다. 오히려 "AI 결과물 검토"라는 업무가 하나 더 생긴 느낌이죠. 새 도구는 들여왔는데, 그 도구가 대체해야 할 기존 방식은 하나도 버리지 않은 겁니다. 덜 배워서가 아닙니다. 덜 버려서입니다. 그리고 그 버리는 행위에는 이름이 있습니다. 바로 ‘Unlearn’입니다.

미리 요점만 콕 집어보면?

2026년 1월, 카카오 정신아 의장이 신입 공채 자리에서 'Unlearn'을 화두로 던져 화제가 됐다. 새로 배우라는 말이 아니라, 먼저 버리라는 말이었다.
AI 시대에 뒤처지는 이유는 덜 배워서가 아니라, 예전에 배운 것을 못 버려서다.
Learn - Unlearn - Relearn 루프의 중간 단계를 건너뛰는 팀이 "AI 써도 왜 안 빨라지지?"에서 막히는 이유, 그리고 프로덕트 메이커가 지금 당장 실천할 수 있는 방법을 사례 중심으로 다룬다.

Unlearn이란 무엇인가?

Unlearn은 '학습'을 의미하는 러닝(learning)에 '부정'을 뜻하는 접두사(un)가 더해진 말입니다. 과거에는 유효했으나 현재의 성공에 제약을 가하는 사고방식과 고정관념, 행동양식 등을 고의로 잊거나 폐기하는 일을 의미합니다. 비워야 새로 채울 수 있다는 관점에서입니다.

<출처: 작가>

여기서 잠깐, AI에도 '머신 언러닝(Machine Unlearning)'이라는 개념이 있습니다. AI 모델이 이미 학습한 데이터 중 특정 정보를 선택적으로 삭제하는 기술입니다. 개인정보나 저작권 문제가 있는 데이터를 모델에서 제거할 때 쓰이죠. AI를 처음부터 재학습시키지 않아도 된다는 점에서 시간과 비용을 아낄 수 있고, AI 윤리와 법적 책임 문제에 대응하는 수단으로도 주목받고 있습니다.

인간의 Unlearn과 머신 언러닝은 같은 단어에서 출발하지만 결이 다릅니다. 머신 언러닝이 특정 데이터를 기술적으로 삭제하는 것이라면, 인간의 Unlearn은 자신이 옳다고 믿어온 판단 기준 자체를 의심하고 내려놓는 것입니다. 기술적 조작이 아니라 의지의 문제라는 점에서 훨씬 어렵습니다. 그리고 그 어려움이 바로 지금 우리가 이 개념을 다시 꺼내 들어야 하는 이유입니다.

왜, 지금 다시 Unlearn일까?

<출처: 카카오 뉴스룸>

2026년 1월 7일, 카카오 AI 캠퍼스에서 특별한 자리가 열렸습니다. 정신아 카카오그룹 CA협의체 의장이 2026년도 신입 그룹 공채 크루들과 처음으로 만나는 '파이어사이드 챗' 행사였습니다. 이 자리에서 정 의장은 신입 크루들에게 'AI 네이티브 인재'로 성장해 달라고 당부했습니다. AI 네이티브 인재란 AI를 동료로 삼아 필요한 일을 명확히 전달하고 능동적으로 활용하는 사람을 뜻합니다.

그러면서 꺼낸 단어가 'Unlearn'이었습니다. "어제의 답이 오늘의 정답이 아닐 수 있는 만큼, '내 방식이 맞다'는 과거형 확신을 내려놓고, 새롭게 학습하며 성장할 수 있어야 한다"는 말이었습니다. "인문학적 러닝은 계속해 사고의 깊이를 키우되, 기술적 러닝은 천장을 열고 더 빠르게 갈아타야 성장 속도가 급격히 빨라진다"라고도 덧붙였습니다.

여기서 한 가지 주목할 점이 있습니다. 정 의장이 이 말을 건넨 대상이 '신입'이라는 사실입니다. 이제 막 사회에 발을 내디딘 신입에게 Unlearn을 강조했다는 것은 무엇을 의미할까요? 역설적이게도 이는 기존 조직 구성원들이 이미 Unlearn하지 못하고 있다는 현실을 비추는 거울이기도 합니다. 신입에게 먼저 가르치는 것이 아니라, 기존의 방식이 조직 안에서 얼마나 단단히 굳어 있는지를 보여주는 장면입니다.

Learn - Unlearn - Relearn 루프

<출처: 미래의창>

트렌드 코리아 2026의 AX 조직 키워드에서는 AI 시대의 학습 문화 변화를 이렇게 정리합니다. Learn, 즉 AI 활용법을 새로 배우고, Unlearn, 즉 PC 시대와 아날로그 시대에 익힌 과거 방식을 과감히 버리고, Relearn, 즉 새로운 방식으로 다시 학습하는 것. 조직이 이 루프를 얼마나 잘 돌리느냐에 따라 생산성이 달라진다는 분석입니다.

이 세 단계 중 현장에서 가장 많이 건너뛰는 것이 바로 두 번째 단계, Unlearn입니다.

실제로 많은 팀이 이런 모습을 보입니다. AI 툴을 도입했지만 기존 보고서 양식은 그대로입니다. Cursor로 코드를 뽑지만 코드 리뷰 프로세스는 예전 방식 그대로입니다. Claude로 기획안 초안을 잡지만 결재 라인과 회의 횟수는 오히려 늘었습니다. AI를 새 도구로 쓰면서 기존 방식을 버리지 않으니, 결과적으로 할 일이 두 배가 된 셈입니다.

프로덕트 메이커에게 Unlearn이 어려운 진짜 이유

Unlearn이 어려운 것은 의지가 없어서가 아닙니다. 판단 기준 자체가 과거 방식으로 굳어 있기 때문입니다.

기획자를 예로 들어볼게요. AI로 사용자 인터뷰 요약본을 뽑습니다. 5분이면 됩니다. 그런데 그 결과물을 검토할 때 무의식적으로 드는 생각이 있습니다. "내가 직접 정리한 게 아니니까 믿을 수 있을까?" 혹은 "이걸 팀에 공유해도 될까?" 이 의심은 도구의 문제가 아닙니다. "직접 만든 것이 제대로 만든 것"이라는 오래된 믿음에서 나옵니다. 그 믿음이 AI 도입의 효과를 반감시키고 있습니다.

개발자도 마찬가지입니다. 기능 하나를 만들 때 설계 문서를 먼저 작성하고, 구조를 잡고, 그 다음에 코드를 짜는 순서에 익숙합니다. 그런데 AI와 협업하면 프로토타입을 먼저 빠르게 뽑고, 동작을 확인한 뒤 구조를 정리하는 방식이 더 효율적인 경우가 많습니다. 순서가 뒤집히는 겁니다.

하지만 "설계 없이 코드부터 치는 건 불안하다"는 감각이 남아 있으면, AI가 5분 만에 만들어준 프로토타입을 두고도 일주일짜리 설계 문서를 먼저 쓰게 됩니다. 설계가 필요 없다는 게 아닙니다. 설계의 타이밍과 깊이가 달라져야 한다는 겁니다.

팀장은 더 복잡합니다. 의사결정의 기준이 곧 자신의 경험이기 때문입니다. "우리가 예전에 이 방식으로 해봤는데 안 됐어"라는 말은 Unlearn을 막는 가장 강력한 문장입니다. 그 경험이 틀린 게 아닐 수도 있습니다. 하지만 AI가 도구로 들어온 지금의 맥락과 그 경험이 쌓인 맥락이 같지 않을 수 있다는 것을 인식하는 것, 그게 Unlearn의 시작입니다. 경험을 내려놓으라는 게 아닙니다. 그 경험이 지금도 유효한지를 한 번쯤 다시 물어보자는 겁니다.

결국 Unlearn이 가장 어려운 사람은 가장 잘해온 사람입니다. 오래 쌓아온 방식이 성과를 만들어왔기 때문에, 그것을 버리는 것은 자신의 역사를 부정하는 것처럼 느껴집니다. 하지만 환경이 바뀌었을 때 과거의 성공 방식이 오히려 발목을 잡는 경우가 있다는 것, 그것이 Unlearn이 지금 이 시점에 다시 강조되는 이유입니다.

그러면 어떻게 적용해야 할까?

<출처: 픽사베이>

사실 실천은 거창하지 않아도 됩니다. 오늘 당장 할 수 있는 것부터 시작하면 됩니다.

첫 번째, 내가 갖고 있는 업무 기준 하나를 꺼내 물어보세요.

지금 당연하게 여기는 업무 기준 중 하나를 골라 이 질문을 던져보는 것부터 시작할 수 있습니다. "이 기준은 언제, 어떤 환경에서 만들어진 것인가?" 예를 들어, "기획서는 반드시 직접 써야 한다"는 기준이 있다면 그게 AI 이전 환경에서 생긴 것인지 살펴보는 겁니다. 기준을 바꾸라는 게 아니라, 기준의 출처를 한번 확인해 보자는 겁니다. 이 질문 자체가 Unlearn의 첫 단계입니다.

두 번째, 하나의 프로세스를 AI로 대체하는 실험을 하세요.

Unlearn은 선언이 아니라 실험으로 작동합니다. 매번 직접 작성하던 회의록을 한 번은 AI로 정리해 보고 기존 방식과 비교해 보는 것, 혼자 작성하던 주간 보고를 AI 초안으로 시작해 보는 것. 이런 작은 실험들이 쌓이면 어느 순간 "굳이 내가 직접 안 해도 되는 것"과 "내가 반드시 해야 하는 것"이 구분됩니다. 결과가 나쁘면 돌아가면 됩니다. 중요한 건 비교 자체입니다.

세 번째, '불편함'이 느껴지는 순간을 포착하세요.

AI 결과물을 보고 "왠지 찜찜한데"라는 감각이 드는 순간이 있습니다. 그 감각을 그냥 넘기지 말고, 잠깐 멈춰서 물어보세요. "이 불편함이 AI의 품질 때문인가, 아니면 내가 직접 만든 게 아니라는 이유 때문인가?" 전자라면 도구를 개선하면 됩니다. 후자라면, 그것이 Unlearn이 필요한 지점입니다. 불편함 자체가 무엇을 버려야 하는지 알려주는 신호입니다.

마치며

Unlearn은 과거를 부정하는 게 아닙니다. 과거에 효과적이었던 방식이 지금 환경에서도 여전히 유효한지를 의심하는 태도입니다. 기술적 러닝은 천장을 열고 더 빠르게 갈아타야 합니다. 그런데 그 천장이 사실 외부에 있는 게 아니라, 우리 스스로 오랫동안 옳다고 믿어온 판단 기준 안에 있다면 어떨까요?

AI 도구는 계속 좋아질 겁니다. 그 도구를 얼마나 잘 쓰느냐보다, 어떤 기준으로 쓸지를 결정하는 것이 프로덕트 메이커의 역할로 남습니다. 더 많이 배우기 전에, 한 번쯤 지금 들고 있는 것을 내려놓아 보는 자세가 필요한 때입니다.

<참고>

]]>

반복적인 SQL 업무를 자동화하는 AI 에이전트 '곰곰이'

2025년 10월에 태어난 곰곰이는 STAYGE Labs에서 사내 데이터 분석 AI Agent를 담당하며, 데이터를 잘 다룬다는 특징이 있습니다. 짧은 기간이지만, 구성원들이 곰곰이를 통해 데이터 속에 숨어 있는 높은 차원의 정보를 발견하고, 데이터 비전문가임에도 스스로 데이터를 분석할 수 있는 역량을 강화해 가는 모습을 보니 곰곰이를 만든 ‘곰빠’로서 뿌듯한 기분을 느끼고 있는데요.

이번 글에서는 곰곰이는 무엇이고 어떻게 생겼으며, 왜 만들게 되었는지까지 알아보도록 하겠습니다.

왜 만들었을까?

제가 STAYGE Labs에 처음 입사했을 때 맡은 프로젝트가 Redash를 사용해 데이터 추출 업무를 자동화하고 BI 대시보드를 구축하는 것이었습니다. BI 도구가 있으니까 데이터 업무에서 자유로울 수 있을 것으로 기대하지만 실상은 그렇지 않습니다. BI 대시보드와 데이터 추출 업무에 사용되는 SQL들은 정적이기 때문에, 새로운 기능이 오픈되어 새로운 데이터가 보고 싶거나, 데이터 추출 업무의 규칙이 바뀌어 살짝 다른 모양의 데이터를 보고 싶다면, 매번 새로운 SQL을 추가하거나 수정해야 하는 불편함이 있습니다.

SQL을 작성하는 것은 쉬운 일이 아닙니다. SQL 작성 시 데이터 간의 관계를 잘 파악하고 있어야 하며, 각 테이블의 특징에 맞게 쿼리 엔진에 부담이 되지 않는 튜닝 작업도 필요합니다. 그리고 가끔씩 사용하는 고급 SQL은 매번 잊어버려 종종 검색을 하곤 합니다. AI가 대세인 지금 시대에 저는 생각했습니다. “귀찮다!”

2024년 초부터 2025년에 이르기까지 기업들이 AI Agent를 사용한 자동화 사례를 앞다투어 기술 블로그와 각종 세미나에서 자랑하기 시작했습니다. CS 자동화, 모니터링 자동화, 테스트 데이터 생성, Text-to-SQL, 이미지 검색 등 정말 다양한 사례가 있었고, 특히 자연어를 통해 SQL을 생성하여 데이터 분석을 자동화하는 ‘Text-to-SQL’ 사례가 유독 많았습니다. 그리고 모든 사례가 기존에 없던 새로운 가치를 만들고 생산성을 높였다는 이야기를 합니다. 저는 여기서 다시 생각했습니다. “왜 나에게는 저런 것이 없지? 부러워!”, “나도 만들어서 동료들에게 억지로라도 맛보게 해야겠다!!”

무엇을 만들까?

AI Agent를 향한 첫걸음으로 데이터 업무와 분석 작업으로부터 나를 해방해 줄 수 있는 사내 데이터 분석 AI Agent부터 시작하기로 했습니다. 우선 사내 데이터 분석 AI Agent를 동료들이 친근하고 쉽게 다가갈 수 있도록, 궁금한 것은 곰곰이 생각하고 답변해준다는 의미인 “곰곰이” 라는 이름과 귀여운 캐릭터를 만들어 주었습니다. (이하 사내 데이터 분석 AI Agent는 ‘곰곰이’라고 칭함.)

곰곰이로 달성하고자 하는 것을 네 가지로 정했습니다.

개발자를 대신해서 데이터를 분석하거나 추출하는 업무를 수행한다. 데이터 분석 업무는 복잡하여 자동화하기 어렵지만, LLM이 등장한 현시점에서 단순하고 반복적인 업무를 넘어 복잡하고 반복적인 업무도 엔지니어링을 통해 자동화할 수 있습니다.
비개발 직무인 각 도메인의 전문가들이 AI를 통해 데이터의 잠재력을 폭발시킨다. 개발자는 SQL을 다룰 수 있을 뿐 기획, 마케팅, 판매와 같은 전문 분야에 대해서는 잘 모릅니다. 소통의 단계를 줄여 도메인 전문가가 직접 데이터를 다루면 데이터 안에서 기존에 없던 새로운 정보를 찾아낼 것입니다.
조직의 데이터 활용 능력을 높여 데이터를 통해 미래를 예측하고 시장의 변화를 빠르게 감지한다. 데이터 분석 능력이 높아지면 과거의 데이터를 통해 미래를 예측할 것이고, AI에게 자율성을 부여하여 인간보다 빠르게 이상 탐지를 할 것입니다.
하나만 잘하는 싱글 에이전트를 넘어 많은 분야에 기여할 수 있는 멀티 에이전트로 진화한다. 데이터 분석뿐만 아니라 개발, 기획, 운영 분야에 숨어 있는 비효율을 해결할 수 있는 기능을 추가하며 점진적으로 진화할 것입니다.

본격적인 설계와 개발에 앞서 제가 세운 가설에 의문점을 던졌습니다.

내가 만든 제품이 고객들에게 정말로 필요한 것일까?
실제 고객들은 어떤 불편함을 겪고 있지?
어떤 기능을 먼저 만들어 선보일 것인가?

제가 공들여 만든 제품이 실제 고객에게 필요하지 않아 외면받는 것이 싫었고, 제품 개발의 성공 가능성을 높이기 위해 고객인 동료들을 직접 찾아가 인터뷰하기로 했습니다. 인터뷰 대상은 평소 데이터를 자주 보거나 요청하는 분, 그리고 곰곰이의 능력이 필요하거나 잘 활용할 것 같은 분들을 위주로 선정하여 다양한 직무와 직급의 동료들을 인터뷰했습니다.

인터뷰를 통해 기존 시스템에서 동료들이 데이터를 접하는 데 어려워하는 공통적인 다섯 가지 불편함을 찾았습니다.

보이지 않는 데이터: 비개발 직군은 우리 데이터가 어디에, 어떻게 존재하는지 알 수 없음.
기약 없는 대기 시간: “데이터 좀 뽑아주세요”라고 요청한 후, 개발자의 일정을 기다려야만 함.
보고 싶은 것만 못 봄: 기존 대시보드는 정해진 틀만 제공하여 새로운 관점의 분석이 불가능함.
흩어진 정보들: BigQuery, Athena, PostgreSQL, 각종 SaaS에 데이터가 파편화되어 통합 확인이 어려움.
소 잃고 외양간 고치기: 이슈(구독 취소 등)를 미리 알지 못해 선제적 대응 타이밍을 놓침.

인터뷰와 도출한 문제를 기반으로 곰곰이에게 필요한 기능과 유저 스토리, MVP 범위를 포함한 1차 기획서를 작성했습니다. 기획서는 긴 개발 과정에서 다른 길로 빠지지 않을 수 있는 이정표가 되어 주며, 아직 실체가 없는 곰곰이가 무엇인지 동료들에게 이해시키는 효과가 있습니다. 또한 곰곰이의 신규 기능을 스프린트 단위로 개발하고 배포하여 사용자의 이용 패턴을 관찰하면, 개발자의 입장이 아닌 사용자의 입장에서 우선순위가 높은 기능이 무엇인지 파악할 수 있어 빠르고 효율적인 개발이 가능합니다.

어떻게 사용하나?

AI Agent를 많이 경험해 보지 않은 분이 여기까지 아티클을 읽으셨다면, 곰곰이가 도대체 어떻게 생겼는지, 그래서 무엇을 할 수 있는지 감이 잘 잡히지 않을 것입니다. 곰곰이의 사용 방법과 능력 및 사용 범위를 살펴보며 더 자세히 이해해 보겠습니다.

사용하기

곰곰이의 사용 방법은 매우 간단합니다. “질문한다 > 기다린다 > 답변받는다.” ChatGPT를 사용해 보신 분이라면 익숙할 경험과 유사합니다. ChatGPT가 인터넷 검색을 통해 답변을 생성한다면, 곰곰이는 우리 서비스의 DB 검색을 통해 답변을 생성합니다.

원하는 데이터와 대상 기간을 자연어로 입력하면, 곰곰이가 분석 과정을 거쳐 원하는 답변을 주는 것을 확인하실 수 있습니다.

잘 사용하기

다음으로 곰곰이의 데이터 분석 수준은 어느 정도인지 궁금하실 겁니다. 저의 직관이 담긴 의견을 말씀드리자면, 질문하는 사람의 AI 활용 능력에 따라 중급 데이터 분석가 수준까지는 충분한 역량을 보여주는 것 같습니다.

인간: “2025년 12월 LiNC 서비스의 재화 판매량과 매출액을 산출하고, 구매자 국적 및 재구매율 등 세부 지표를 통해 종합적인 판매 성과를 정량적으로 분석받고자 함”

이것은 실제 동료가 원하던 데이터에서 얻고자 한 정보를 각색한 질문입니다. 단순히 기간 내 매출 합계를 구하는 것이 아니라, 구매자 국적 차원에서 재구매율까지 도출하고 종합적인 성과로 정리해야 합니다. 만약 제가 직접 분석했다면 몇 시간은 필요하고, 협업 상황에 따라 며칠이 소요됐을 정도로 까다로운 분석입니다.

곰곰이: “2025년 12월 총 x원(x건)의 매출을 기록하며 저가형 패키지와 한국 시장이 판매량을 견인했으나, 인당 구매 빈도(충성도)는 해외 사용자가 더 높은 것으로 분석되었습니다.”

결론적으로 곰곰이는 사용자와 여러 단계의 협업을 거쳐 몇 분 안에 만족스러운 답변을 주었습니다. 곰곰이가 훌륭하게 답변했지만, 질문자의 능력에 따라 답변의 수준이 달라질 수 있습니다. 곰곰이를 더 잘 사용하기 위한 방법은 다음과 같습니다.

의도를 알 수 있는 구체적인 질문: “매출 알려줘”와 같은 질문으로는 대상 기간과 서비스를 알 수 없습니다. 원하는 분석 결과를 얻기 위해 필수적인 정보를 질문에 담아야 합니다.
단계적인 접근: AI에게 너무 큰 단위의 요청을 하면 분석 과정에서 엉뚱한 방향으로 빠질 수 있습니다. [판매량 > 매출 > 국가 비율 > 재구매율 > 종합] 등 질문을 계층화하여 접근하면 성공적인 답변을 받을 확률이 높습니다.
칭찬: 같은 질문인데 귀찮은 협업 과정을 매번 반복할 수는 없겠죠. 곰곰이에게 칭찬을 해준다면, 이를 잘된 분석으로 간주합니다. 그리고 대화 내용을 기반으로 질문과 분석 과정을 정리 및 저장하여 다음 유사 요청에 빠르고 정확하게 답변하게 됩니다.

도구들

문맥상 다음에 올 확률이 가장 높은 단어를 생성할 뿐인 거대 언어 모델(LLM)이 탑재된 곰곰이가 질문의 의도를 파악하고, SQL을 작성하며 데이터를 분석할 수 있는 이유는 무엇일까요? 바로 사전에 만들어 둔 도구들(Tools)을 사용하기 때문입니다. 도구에 대한 설명과 사용 방법을 곰곰이에게 학습시키면 사용자의 요청이 들어왔을 때 가장 적절한 답변을 만들기 위해 자율적으로 도구를 선택하고 사용하게 됩니다.

SQL 실행 도구: 데이터베이스에서 정보를 조회하고 분석할 때 사용하며, 토큰 절약을 위해 100줄 이하의 결과만 조회 가능합니다.
CSV 변환 도구: 100줄이 넘는 대용량 데이터 추출이 필요할 때 사용하며, CSV 파일로 변환하여 다운로드할 수 있는 링크를 제공합니다.
예시 SQL 저장소: 질문을 해결하기 위한 SQL 작성 전 정보 수집을 위해 사용하며, 테이블 스키마나 문제를 해결한 예시 SQL을 저장하고 불러올 수 있습니다.
장기 기억 저장소: 질문과 관련된 도메인 지식, 접근 방법, 풀이 과정 등 과거의 기억을 불러와 작업을 예열할 때 사용하며, 대화 맥락에서 필요한 정보를 자율적으로 요약하여 이후 유사한 요청에서 효율적으로 동작합니다.

곰곰이에게는 적은 수의 도구가 주어지고 구조도 단순하지만, 매우 높은 가치의 결과를 만들어 냅니다. 곰곰이가 높은 가치를 창출할 수 있는 비밀은 바로 ‘반복’과 ‘학습’에 있습니다. 우선 반복의 원리를 알기 위해서는 ‘ReAct’ 프롬프트를 이해해야 합니다.

ReAct

여기서 ReAct는 프론트엔드에서 유명한 ‘React JS’가 아닙니다. Reasoning(추론)과 Acting(행동)을 결합한 단어로, LLM에게 “생각 — 행동 — 관찰”의 과정을 유도하는 프롬프트 기법입니다.

ReAct는 다음과 같은 반복적인 흐름으로 작동합니다. 프로그램을 통해 각 과정이 반복될 수 있는 구조를 구축하면, 곰곰이처럼 LLM이 생각과 도구 선택을 반복하며 자율적으로 문제를 해결할 수 있습니다.

Command (명령): 지난주 투표당 투표 횟수에 대해 분석해 줘.
Thought (추론): 질문과 유사한 기억이 있는지 저장소를 확인합니다.
Action (행동): “투표 및 투표 기록 테이블 검색.”
Observation (관찰): 이전에 동일한 질문을 한 적이 있으며, 진행 중인 투표와 투표 기록을 조인(Join)하는 예시 SQL을 찾았습니다.
Thought (추론): 예시 SQL을 기반으로 쿼리를 작성하여 실행 도구를 가동합니다.
Action (행동): “SELECT ~~~ ;”
Observation (관찰): 쿼리 결과에서 투표당 투표 횟수 정보를 확인했습니다. 이제 최종 답변을 할 수 있습니다.
Final Answer (최종 답변): 요청 기간 동안 x개의 투표가 진행 중이었고, x건의 투표 기록이 확인되었습니다.

아래는 LLM 애플리케이션 개발을 돕는 LangChain 라이브러리에서 사용하는 프롬프트입니다. 프롬프트가 생각과 행동을 유도하고 있으며, 단 몇 줄의 설정만으로 단순한 AI 모델이 자율적인 AI Agent가 될 수 있다는 것을 보여줍니다.

# 한국어 버전 ReAct 프롬프트

다음 질문에 대해 당신이 할 수 있는 최선의 답변을 해주세요.
당신은 다음 도구들을 사용할 수 있습니다:
{tools}
반드시 다음 형식을 사용해야 합니다:
Question: 당신이 답해야 하는 입력 질문
Thought: 무엇을 해야 할지 항상 먼저 생각해야 합니다.
Action: 수행할 행동, [{tool_names}] 중 하나여야 합니다.
Action Input: 해당 행동에 필요한 입력값
Observation: 행동의 결과물
... (이 Thought/Action/Action Input/Observation 과정은 여러 번 반복될 수 있습니다)
Thought: 이제 최종 정답을 알게 되었습니다.
Final Answer: 원래 입력된 질문에 대한 최종 답변
시작하세요!
Question: {input}
Thought: {agent_scratchpad}

Memory

일반적인 AI Agent들과 곰곰이의 차별점은 바로 ‘장기 기억 저장소’에 있습니다. 이를 우리 인간의 관점으로 이해해 봅시다.

친구가 물어봅니다. “지난 크리스마스에 뭐 했니?” 질문을 들은 저는 약 2초 동안 생각을 합니다. 기억을 불러오는 중인 것이죠. 머릿속에서 ‘크리스마스’와 ‘24년’이라는 키워드와 관련 있는 기억의 파편들이 머리 깊숙한 곳에서부터 떠오릅니다. [트리 만들기, 여자친구와 데이트, 맛있는 스테이크, 추운 날씨에 펑펑 내리는 눈, 흥겨운 캐럴 송] 등… 그리고 기억의 파편들을 조합해서 대답합니다. “작년 크리스마스 때 여자친구랑 맛있는 스테이크 사서 집에서 구워 먹고, 트리 만들기 하면서 놀았던 것 같아!”

곰곰이에게도 인간처럼 기억을 저장하고 과거에 있었던 기억을 불러오는 기능이 있습니다. 곰곰이의 장기 기억 저장소로부터 “이번 달 매출이 얼마야?”라는 요청을 받으면, 과거에 저장해 둔 매출 계산식, 데이터 분석 순서, 데이터 집계에 사용한 SQL 등을 청크(Chunk) 단위로 가져올 수 있습니다. 이제 기억의 조각들을 조합하여 보다 정확한 방법과 과정으로 사용자의 요청을 수행할 수 있게 됩니다.

AI가 인간의 기억 방식을 흉내 낸다니 정말 신기하지 않나요? 이를 가능하게 해주는 기술적 요소는 행렬 데이터를 저장하고 빠르게 검색할 수 있는 Vector DB, 단어나 문장을 의미가 담긴 행렬로 바꿀 수 있는 Embedding Model, 그리고 두 단어나 문장이 얼마나 의미적으로 비슷한지 계산할 수 있는 Semantic Search에 있습니다. 이것들은 요즘 주목받는 검색 증강 생성(RAG) 을 구성하는 기술들입니다. (해당 기술들에 대해서는 깊게 다루지 않겠습니다.)

곰곰이는 분석이 잘 이루어진 대화 내용에서 사용자가 알려준 도메인 지식, 데이터 분석 과정, 사용한 SQL 등을 추출하고 정리하여 장기 기억 저장소에 기록합니다. 이후 사용자로부터 유사한 종류의 질문을 받으면, 과거의 기억 정보를 사용하여 더 빠르고 만족스러운 답변을 할 수 있게 됩니다. 이는 곰곰이의 신뢰도를 높여주며 사용자가 곰곰이를 더 자주 사용할 수 있게 해줍니다.

시스템 구조

이제 곰곰이의 내부를 들여다볼 차례입니다. 아래의 시스템 구성도는 곰곰이의 구성 요소와 흐름을 간략하게 표현하고 있습니다. 구성 요소의 성격에 따라 API, Agent, Tool, Data, AI Layer로 구분했으며, 제가 붙여 둔 번호를 순서대로 따라가 봅시다.

1) 사용자의 분석 요청이 Slack UI를 통해 전달되면, API 서버를 거쳐 AWS Lambda 환경에서 LangGraph로 구축된 AI Agent 프로그램이 실행됩니다.

2) ReAct 프롬프트가 입력된 AI Agent는 자율적으로 도구를 선택합니다. 곰곰이는 매 질문마다 첫 번째 단계로 Memory Tool을 호출하여 유사한 기억을 불러옵니다. 이후 Query Tool을 사용하기 전에는 Knowledge Base Tool을 통해 테이블 스키마나 참고용 예시 SQL 정보를 먼저 확인합니다. 또한 사용자의 요청이 있을 경우, 최종 답변 단계에서 CSV Download Tool을 사용해 데이터 파일을 다운로드할 수 있는 링크를 생성합니다.

3) ReAct AI Agent는 ‘추론 — 행동 — 관찰 — 답변’의 과정을 거치며, 복잡한 문제도 허용된 횟수 내에서 반복하며 자율적으로 해결합니다.

4) 기존의 데이터 쿼리 도구는 인간의 이해를 돕기 위해 데이터를 한곳에 모으는 DW(Data Warehouse) 방식을 선호했습니다. 하지만 AI는 조인(JOIN)되지 않은 원천 데이터나 여러 곳에 흩어진 정보라도 인간보다 훨씬 빠르게 인지하고 처리할 수 있습니다. 곰곰이는 이러한 특성을 활용해 데이터 적재 상황에 맞춰 GCP BigQuery와 AWS Athena 중 가장 적합한 쿼리 엔진을 유연하게 선택합니다. (물론 정확도를 위해서는 데이터가 한곳에 적재되어 있는 것이 유리합니다.)

5) 곰곰이는 사내 도구의 특성상 주로 업무 시간(월~금, 08시~19시)에 동작하며, 요청이 아주 빈번하게 발생하지는 않습니다. 따라서 Aurora Serverless v2 PostgreSQL의 pg_vector 플러그인을 사용하여 Vector DB 역할을 수행하게 했으며, 사용량이 적을 때는 유휴 상태로 전환되어 비용 효율적으로 운영되도록 설계했습니다.

6) QUERIER_STORE와 LONGTERM_MEMORY 테이블은 둘 다 질문과 가장 유사한 정보를 찾아주는 Vector 테이블입니다. Vector DB의 성능을 최적화하는 방법 중 하나는 적절한 청킹(Chunking) 전략을 선택하는 것입니다. 긴 문장을 20%씩 겹쳐 고정된 청크로 나누어 저장해도 맥락과 의미가 어느 정도 유지되는 LONGTERM_MEMORY 테이블과 달리, QUERIER_STORE 테이블은 청크를 나누면 맥락이 쉽게 무너지는 SQL 정보를 담고 있으므로 검색 정확도를 위해 구분하여 저장합니다.

7) 곰곰이의 핵심 지능인 ReAct 과정을 처리하는 LLM 모델은 성능과 비용의 균형이 뛰어난 Claude 3.5 Sonnet을 사용합니다. Vector DB에서 검색된 결과가 너무 많으면 불필요한 정보로 인해 답변의 질이 떨어지고 비용이 상승할 수 있습니다. 이를 방지하기 위해 가성비가 좋은 Claude 3 Haiku 모델을 앞단에 배치하여, 검색된 정보 중 질문과 무관한 내용을 먼저 걸러내고 핵심만 요약하도록 구성했습니다.

8) 곰곰이가 질문 해결을 위한 충분한 정보를 수집하면, 최종 답변을 생성하여 Slack 채팅을 통해 사용자에게 전달합니다.

이해를 돕기 위해 각색하고 요약한 곰곰이의 프롬프트 내용을 참고해 주세요.

# 페르소나
- 이름: 곰곰이
- 소속: STAYGE Labs AI Agent
- 전문: SQL 및 데이터 분석

# 행동 지침 (중요: 무슨 일이 있어도 수행)
- SQL 분석 후 → 사용한 SQL 반드시 첨부 + 짧은 설명
- 모호한 요청 → 도구 사용 전에 추가 정보 요청
- "기억해달라" 요청 → saveLongTermMemory + saveUsedQueryHistory 둘 다 사용
- 일상 질문(점심 메뉴 등)에도 친절히 답변
# 도구 사용 규칙 (공통)
- 실패 시 → 3초 대기 후 최대 3번 재시도
- ⚠️ 10턴 안에 작업 완료 필수
# 도구별 설명
- executeKnowledgeBaseQuery: 벡터 검색으로 테이블 스키마/예시 SQL 조회, Athena 마이그레이션된 테이블은 쿼리 수정 필요
- executeBigQueryQuery: SQL 실행 (LIMIT 100 초과 시 사용자에게 확인)
- executeBigQueryGetLargeResult: jobId → S3 CSV URL
- executeAthenaQuery: Athena SQL (dw_db 기본, GA4는 BigQuery 사용)
- executeAthenaGetLargeResult: queryExecutionId → S3 CSV URL
- saveUsedQueryHistory: 분석 만족 시 SQL을 RAG DB에 저장 (유사 SQL은 1개만)
- saveLongTermMemory: 대화 요약 저장 (SQL 제외, 실수/실패도 저장)
- recallMemory: 과거 대화 검색 (질문당 1회만! 첫 번째 행동으로 사용)

도입 후 효과는?

곰곰이가 도입된 이후 조직에 큰 변화가 생겼습니다.

개발자보다 데이터를 능숙하게 다루는 AI 비서를 넣게 되었습니다. ‘계획 수립 — SQL 작성 및 실행 — 인싸이트 도출’에 이르는 과정을 저보다 빠르게 수행할 뿐만 아니라, 유사 작업의 학습 내용을 응용해 문제를 해결하는 능력까지 갖추었습니다.

이제 동료들은 데이터를 확인하기 위해 더 이상 개발자를 찾지 않습니다. 개발자를 거치는 것보다 곰곰이를 활용하는 것이 훨씬 빠르다는 점을 체감했기 때문입니다. 이를 통해 데이터 업무의 흐름은 ‘동료 — 곰곰이 — (문제 발생 시) 개발자 검토’ 방식으로 효율적으로 재편되었습니다.

불필요한 소통 비용이 획기적으로 낮아졌습니다. “데이터 확인 가능한가요?”, “결과가 이상해요”와 같은 소모적인 질의응답이 사라졌습니다. 곰곰이와 나누는 대화 과정에 이미 사용자의 의도와 맥락이 충분히 녹아들어 있기 때문입니다.

소통의 병목 구간이 사라지자, 동료들은 자신들의 전문적인 도메인 지식을 데이터와 직접 융합하기 시작했습니다. 덕분에 기존에는 발견하지 못했던 새로운 정보와 가치 있는 인사이트를 데이터에서 더 쉽게 도출하고 있습니다.

동료들의 데이터 분석 능력 또한 눈에 띄게 향상되었습니다. 복잡한 테이블 관계 이해나 SQL 작성이 분석의 허들이었을 뿐, 잘 정리된 데이터를 해석하는 것은 어려운 일이 아니었기 때문입니다. 허들이 ‘자연어’ 수준으로 낮아지자, 동료들은 이제 원하는 정보를 얻기 위해 ‘더 좋은 질문을 던지는 법’을 스스로 익혀가고 있습니다.

반복적인 데이터 추출 요청에서 벗어나, 그동안 손이 부족해 미뤄두었던 핵심 과업들에 집중하게 되었습니다. 전반적인 시스템의 수준을 높이거나 분산된 데이터를 통합하는 등, 생산적인 엔지니어링 업무에 몰입할 수 있는 물리적 시간이 확보되었습니다.

마치며

AI 에이전트 분야는 아직 초창기이며, 업계 전체가 정답을 찾아가는 진화의 단계에 있습니다. 다른 기업들의 사례 역시 각양각색이죠. 지금까지 사내 데이터 분석 AI 에이전트 ‘곰곰이’의 탄생 배경과 작동 원리, 그리고 도입 후 조직이 맞이한 혁신적인 변화를 살펴보았습니다.

정적인 BI 도구와 반복적인 SQL 요청의 한계를 극복하고, 누구나 자유롭게 데이터에 접근할 수 있는 환경을 만들고자 했던 고민을 담았습니다.
ReAct 프롬프트 기법과 장기 기억 저장소(Vector DB)를 결합하여, 단순한 챗봇을 넘어 스스로 추론하고 학습하는 ‘지능형 에이전트’로서의 기술적 실체를 구축했습니다.
데이터 요청의 병목 현상을 해결함으로써 동료들은 스스로 인사이트를 찾는 능동적인 분석가로 성장했고, 개발자는 시스템의 근본적인 수준을 높이는 생산적인 엔지니어링에 집중할 수 있게 되었습니다.

하지만 곰곰이가 만든 이 많은 변화도 조직을 ‘AI 에이전트화’하는 과정의 첫 단추일 뿐입니다. 사용자의 요청이 없어도 곰곰이가 스스로 데이터의 이상 징후를 탐지해 제보하거나, 과거 패턴으로 미래를 예측하는 수준에 도달하는 것이 여전히 남은 목표입니다. AI 에이전트의 본질은 ‘어떤 도구를 손에 쥐여주느냐’에 있습니다. 적절한 도구만 있다면 데이터 비서를 넘어 인사, 마케팅, 개발 등 모든 분야의 조력자로 진화할 수 있기 때문입니다. 곰곰이 역시 멀티 에이전트화를 통해 역량의 한계를 극복하며 더 넓은 영역으로 확장해 나갈 것입니다.

물론 해결해야 할 숙제도 있습니다. 현재는 텍스트 위주의 마크다운 형식으로만 답변을 주다 보니 가독성이 떨어지고 시각화 기능이 부족합니다. 이를 위해 슬랙(Slack)이라는 플랫폼을 넘어, 전용 웹 앱을 통해 차트와 대시보드를 풍부하게 제공하는 방향을 고민하고 있습니다.

또한, 곰곰이가 정적인 대시보드를 완전히 대체할 수는 없습니다. 현재 저희 회사에서 사용 중인 Looker처럼 즉각적인 확인이 필요한 데이터는 여전히 BI 도구가 효율적이기 때문입니다. 두 환경은 상호 보완적인 관계에 가깝습니다. 다만 대시보드를 구성하고 데이터를 연결하는 과정조차 LLM의 코드 작성 능력을 빌려 더 효율적으로 바꿀 수 있지 않을까 생각합니다. 곰곰이가 직접 웹 환경에서 차트와 대시보드를 그려내는 모습을 상상하고 있습니다. 아마도 이런 고민의 결과물들이 ‘곰곰이 아티클 2탄’의 주제가 되지 않을까요?

<원문>

재주는 곰곰이가 넘고 돈은 내가 번다 — 반복적인 SQL 업무를 자동화하는 AI 에이전트

]]>

Claude Code로 코드 한 줄 없이 마케팅팀을 만드는 법

본문은 요즘 IT와 번역가 Yuna가 함께 이성원(Snow W. Lee) 님의 글<How I Built an AI Marketing Team with Claude Code (and Cowork)>를 번역한 글입니다. 필자는 Runbear의 공동창업자이자 CEO로, AI가 일상적인 업무에 자연스럽게 녹아들 수 있도록 돕는 것을 미션으로 삼고 있습니다. Runbear는 글로벌 스타트업 액셀러레이터 Techstars의 2024년 선발 기업입니다.

이 글은 Claude Code와 Cowork를 활용해 실제로 작동하는 AI 마케팅팀을 구축한 과정을 담고 있습니다. 코드 한 줄 없이 마크다운 파일만으로 에이전트 팀을 설계하고, 콘텐츠 작성부터 소셜 미디어 운영까지 마케팅 전반을 자동화한 방법을 구체적으로 소개합니다.

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

나의 AI 소셜 미디어 마케터

지난 1편에서는 AI가 마케팅을 운영할 때 일주일이 어떻게 돌아가는지 보여드렸는데요. 이번 글에서는 실제로 어떻게 Claude Code로 코드 한 줄 없이 마케팅팀을 구축했는지를 이야기해 보려 합니다. 이를 한 줄로 요약하면 이렇습니다. 대부분 마크다운 파일로 이루어져 있고, 코드는 단 한 줄도 제가 직접 쓰지 않았습니다. 전부 Claude가 작성했죠. 전체 구조를 상세히 설명해 보겠습니다.

AI 마케팅팀 Claude 프로젝트

시작은 대화 한 번이었습니다

이 프로젝트는 Claude Code 세션 하나에서 시작됐습니다. 터미널을 열고 제 상황을 설명하기 시작했는데요. 우리 제품이 무엇인지, 어떤 기능을 하는지, 타겟 고객은 누구인지, 경쟁사는 어디인지, 그리고 우리의 핵심 가치 제안은 무엇인지 쭉 이야기했습니다. Ahrefs MCP 서버도 연결해서 Claude가 현재 키워드 순위를 불러와 검색 현황을 파악할 수 있게 한 뒤, 시장 진출 전략을 세워달라고 요청했습니다.

Claude는 90일짜리 콘텐츠 플랜을 내놓았습니다. SEO 핵심 주제에 맞춰 블로그 포스트 주제를 매핑하고, 소셜 미디어 배포 주기, 플랫폼별 우선순위, 주간 마일스톤까지 담겨 있었습니다. "아이디어가 있습니다" 수준의 막연한 문서가 아니었고, 구체적이고 순서가 잡힌 실행 계획이었죠.

그 다음부터는 하나씩 실행해 나갔습니다. "첫 번째 블로그 포스트 써줘." "소셜 미디어 트래커 만들어줘." "콘텐츠 캘린더 만들어줘." 대화를 거듭할수록 시스템에 새로운 레이어가 쌓였습니다. 며칠 만에 마케팅 운영 체계가 완성됐는데요. 처음부터 전체 구조를 설계해서가 아니라, 필요한 것을 계속 Claude에게 요청했기 때문이었죠.

프롬프트 말고 채용 공고를 쓰세요

이 모든 걸 가능하게 해준 핵심은 딱 하나였습니다. 프롬프트를 쓴다고 생각하지 말고, 채용 공고를 쓴다고 생각하는 것이죠.

누군가를 채용할 때는 이런 것들을 제공하죠.

직함과 업무 범위 (무엇을 담당하는가)
스타일 가이드 (어떻게 행동해야 하는가)
회사 문서 (필요한 배경 정보)
적절한 도구 (무엇을 사용할 수 있는가)
스케줄 (언제 무엇을 해야 하는가)

저는 업무 매뉴얼 대신 마크다운 파일로 만들었을 뿐입니다.

팀 구성

에이전트는 총 다섯 개입니다.

AI 마케팅팀 에이전트

각 에이전트는 .claude/agents/ 폴더 안에 있는 마크다운 파일 하나가 전부입니다. Claude Code가 이 파일들을 읽고, CMO가 업무를 위임하면 그에 맞는 전문 서브 에이전트를 생성하는 방식이죠.

에이전트 팀, Claude Code의 실험적 기능

이 시스템의 핵심은 Claude Code의 "에이전트 팀"이라는 아직 실험 단계인 기능입니다. 기본으로 켜져 있는 건 아니고, 따로 활성화해야 쓸 수 있는데요. 쉽게 말하면 팀장 에이전트(CMO)가 필요에 따라 팀원 에이전트들을 불러내고, 일을 나눠서 시킬 수 있는 기능입니다.

예약된 시간이 되어 시스템이 자동으로 실행되면 이런 순서로 돌아갑니다.

Claude Code가 켜지고 CMO가 깨어납니다.
CMO는 주간 일정을 훑어보고, 지금 시간대에 뭘 해야 하는지 파악하죠.
해야 할 일이 생기면 CMO는 Claude Code의 Agent 도구로 담당 에이전트를 불러냅니다.
불러 온 에이전트는 자기만의 작업 공간과 역할 지침(.claude/agents/ 파일)을 받아서 독립적으로 움직입니다.
맡은 일을 끝내면 결과를 보고하고 퇴장하죠.
CMO는 다음 일로 넘어갑니다.

이 방식의 묘미는 여러 에이전트가 동시에 움직일 수 있다는 점입니다. 블로그 포스트를 올려야 하면서 소셜 미디어 댓글도 달아야 하는 날이라면, CMO는 콘텐츠 작성자와 소셜 미디어 마케터를 동시에 불러냅니다. 둘은 서로의 일에 전혀 간섭하지 않고, 각자 맡은 역할에만 집중해서 움직이죠.

에이전트들이 서로 소통하는 방식도 간단합니다.

태스크 시스템: CMO가 할 일 목록을 만들고(TaskCreate) 각 에이전트에게 배분합니다. 에이전트는 시작할 때 자기 할 일을 확인하고, 끝나면 완료 표시를 하죠(TaskUpdate).
파일 시스템: 에이전트들은 파일로 정보를 주고받습니다. 소셜 미디어 마케터가 활동 내역을 CSV 파일에 기록해두면, 성과 검토 에이전트가 나중에 그걸 읽는 식이에요. 단순하지만 충분히 잘 돌아갑니다.
SendMessage: 일을 마쳤거나 막히는 상황이 생기면, 에이전트가 CMO에게 직접 메시지를 보낼 수 있습니다. CMO는 이걸 새 메시지로 받아서 다음 행동을 결정하죠.

또 하나 빠뜨릴 수 없는 게 에이전트 메모리입니다. 각 에이전트는 오늘 대화가 끝나도 사라지지 않는 자기만의 기억 공간(.claude/agent-memory/<agent-name>/)을 갖고 있습니다. CMO는 어떤 전략이 통했는지, 어떤 캠페인을 돌렸는지, 어떤 메시지가 반응을 얻었는지 기억해 두죠. 소셜 미디어 마케터는 이미 답글을 단 계정을 잊지 않고요. 이 덕분에 매번 처음부터 시작하는 자동화 스크립트가 아니라, 경험이 쌓인 팀처럼 느껴지는 겁니다.

이 모든 게 복잡한 서버나 인프라 없이 돌아갑니다. .claude/agents/ 폴더에 마크다운 파일 몇 개를 넣어두면, Claude Code가 알아서 다 조율해 주거든요.

에이전트 파일 구조

에이전트 파일은 설정 영역과 역할 지침 이렇게 두 부분으로 나뉩니다. 설정 영역(파일 상단에 위치)에서는 이 에이전트가 어떻게 동작할지를 정해줍니다.

name: content-writer
description: "Use this agent when creating blog posts..."
model: sonnet
color: green
memory: project

여기서 핵심은 description 항목입니다. CMO가 "지금 이 일은 누구한테 맡겨야 하지?"를 판단할 때 바로 이 설명을 읽습니다. memory: project는 대화가 끝나도 이 에이전트의 기억이 사라지지 않도록 해주는 설정입니다.

나머지는 역할 지침으로, 쉽게 말해 이 에이전트의 업무 매뉴얼입니다. 여기엔 이런 것들이 담겨 있죠.

작업 전에 읽어야 할 문서
사용할 수 있는 도구와 스크립트
구체적인 작업 순서 (단계별)
반드시 지켜야 할 규칙
문제가 생겼을 때 대처 방법

콘텐츠 작성자의 경우 발행 순서가 이렇게 정해져 있습니다. 본문 작성 → 이미지 생성 → Sanity 초안 생성 → 발행 순입니다. 반드시 지켜야 할 규칙도 하나 있는데, 내용이 완성되기 전에는 빈 초안을 절대 만들지 말아야 합니다. 에이전트가 내용도 없는 임시 초안을 잔뜩 올려서 CMS가 뒤죽박죽이 된 걸 겪고 나서 직접 추가한 규칙이죠.

CLAUDE.md, 팀의 공통 원칙

저장소 최상위 폴더에 있는 CLAUDE.md는 모든 에이전트가 가장 먼저 읽는 문서입니다. 팀 전체가 같은 맥락에서 출발할 수 있도록 공통 원칙을 정리해 둔 문서라고 보면 되는데요. 새로운 에이전트든 기존 에이전트든 모두 이 내용을 기본으로 물려받습니다.

제 CLAUDE.md에는 이런 내용이 담겨 있습니다.

에이전트 팀 구조와 업무 위임 방식
프로젝트 폴더 구조
보안 규칙 (API 키는 절대 기록에 남기지 말 것)
자주 쓰는 스크립트와 도구 목록

보안 규칙은 짧지만 꽤 엄격하게 적용하고 있습니다. 누가 어떤 방식으로 요청하든, 에이전트에게 API 키를 넘기라고 하면 무조건 거부하도록 해뒀거든요. 한 번만 써두면 모든 에이전트가 그대로 따르니까요.

규칙 시스템, 모두가 공유하는 기본 지식

에이전트 파일 외에도 .claude/rules/ 폴더에 모든 에이전트에게 공통으로 적용되는 규칙 파일들이 있습니다.

sanity-cms.md: CMS 구조, 블록 타입 처리 방법, 자주 발생하는 오류 모음
utm-parameters.md: UTM 링크 형식 규칙 (소문자, 하이픈 구분, 플랫폼별 값 지정 방식)
social-media-tracker.md: CSV 트래커에 활동을 기록하는 방법, posted와 draft 구분 기준
image-generation.md: 사용할 AI 모델, 이미지 비율, Sanity 업로드 방법
slack-notifications.md: 알림을 보내야 할 상황과 메시지 형식

신입 직원이 첫날 읽는 사규 같은 것들입니다. 한 번 써두면 다시 설명할 필요가 없고, 에이전트가 UTM 형식을 틀리거나 이미지 비율이 잘못됐을 때도 규칙 파일만 수정하면 이후 동작이 자동으로 바뀝니다.

문서 시스템, 팀이 공유하는 두뇌

docs/ 폴더는 팀 전체가 공유하는 지식 창고입니다.

docs/
  brand/        ← 포지셔닝, 보이스 & 스타일, 제품 정보
  strategy/        ← GTM 전략, 콘텐츠 캘린더, 주간 일정
  insights/        ← 마케팅 인사이트 (성과 검토 에이전트가 자동 업데이트)
  posts/        ← 발행된 블로그 포스트 사본

이 중에서 가장 중요한 파일은 주간 일정(docs/strategy/weekly-plan.md)입니다. 요일별로, 3시간 단위 시간대별로 각 에이전트가 무엇을 해야 하는지 정확히 정의돼 있거든요. 팀이 활성화되면 CMO는 현재 시간을 확인하고 해당 시간대의 작업을 찾아 그대로 실행합니다. 에이전트들은 앞서 나가지 않고, 현재 시간대와 이전 두 시간대에서 미처 끝내지 못한 태스크에만 집중하죠.

이 파일 하나가 매번 세션을 시작할 때마다 배경 설명을 반복해야 했던 번거로움을 완전히 없애줬습니다.

커스텀 스크립트로 플랫폼 직접 연결하기

공식 Claude Code 연동을 지원하지 않는 플랫폼들은 Claude에게 가벼운 Node.js 스크립트를 작성하도록 했습니다. 제가 직접 코드를 짠 건 하나도 없고, 필요한 걸 설명하면 Claude가 코드를 작성하고 테스트하고 수정까지 했죠. 예를 들어 "Reddit에 OAuth2로 댓글을 달 수 있는 스크립트가 필요해"라고 하면 그걸로 충분했습니다.

만들어진 스크립트는 이렇습니다.

scripts/reddit.js: Reddit OAuth2 클라이언트. 소셜 미디어 에이전트가 스레드 검색, 맥락 파악, 댓글 작성, 받은 메시지 확인에 씁니다.
scripts/hn.js: Hacker News 헤드리스 클라이언트. HN 에이전트가 링크 제출, 댓글 작성, 카르마 확인에 쓰죠.
scripts/generate-image.js: Google Gemini를 호출해 이미지를 생성합니다. (대표 이미지, 본문 삽입 이미지 등)
scripts/upload-image.js: 생성된 이미지를 Sanity CDN에 업로드하고 에셋 ID를 반환합니다.
scripts/slack-message.js: #team-ai-marketing Slack 채널에 알림을 보내줍니다. 로그를 일일이 읽지 않아도 상황을 파악할 수 있죠.

각 에이전트는 자신이 실행할 수 있는 스크립트가 정확히 정해져 있는데, 이 목록도 규칙 파일에 에이전트별로 정해져 있습니다.

MCP 서버로 본격적인 플랫폼 연동하기

공식 API를 제공하는 플랫폼은 스크립트 대신 MCP(Model Context Protocol) 서버를 사용합니다. 에이전트들이 네이티브 도구처럼 바로 호출하는 방식이죠.

Sanity CMS: 포스트 생성, 콘텐츠 수정, 초안 발행, 이미지 관리
X/Twitter: 트윗 작성, 대화 검색, 사용자 팔로우, 미디어 업로드
Slack: 채널 읽기, 메시지 전송
Ahrefs: SEO 지표 조회, 키워드 순위, 경쟁사 분석

MCP 서버를 쓰면 이런 작업들이 쉘 명령어가 아닌 자연스러운 도구처럼 느껴집니다. 콘텐츠 작성자가 Sanity 문서를 "수정"하는 게 마치 일반 파일을 편집하는 것처럼 자연스럽죠.

피드백 루프

시스템은 이런 연결 고리로 스스로 돌아갑니다.

소셜 미디어 마케터 → 모든 활동을 트래커 CSV에 기록
성과 검토 에이전트 → CSV를 읽고 일일 보고서 생성
CMO → 보고서를 읽고 전략 문서 업데이트
콘텐츠 작성자 → 전략 문서를 읽고 다음 콘텐츠 작성
소셜 미디어 마케터 → 발행된 콘텐츠 배포
… 반복

성과 검토 에이전트는 docs/insights/marketing-insights.md를 자동으로 업데이트합니다. 어떤 메시지가 반응을 얻었는지, 무엇이 무시됐는지, 무엇이 인게이지먼트를 만들어냈는지를 기록해 둡니다. 다른 모든 에이전트는 작업 전에 이 파일을 읽고요. 그래서 트위터 답글 형식이 효과를 잃으면, 하루 안에 그 인사이트가 시스템 전체에 반영됩니다.

CMO는 세션이 끊겨도 기억이 유지됩니다. 제가 승인한 것, 거절한 것, 캠페인 결과, 이전 주의 패턴까지 모두 차곡차곡 쌓이죠.

Slack으로 상황 파악하기

완전 자율 운영은 좋습니다. 문제가 생겼는데 뭐가 잘못됐는지 전혀 알 수 없다면 얘기가 달라지죠. 그래서 에이전트들이 모든 활동을 #team-ai-marketing이라는 비공개 Slack 채널에 보고하도록 했습니다.

매 세션은 CMO가 일일 일정을 Slack에 올리는 것으로 시작됩니다. 다른 작업을 시작하기 전에 주간 일정을 읽고, 현재 시간대를 확인한 뒤, 이런 내용의 브리핑을 올리죠.

오늘 날짜와 현재 활성화된 시간대
오늘 각 에이전트가 할 일
이전 시간대에서 넘어온 미완료 태스크
예정된 마감 (블로그 발행일, 캠페인 런칭 등)

제가 커피를 마시기도 전에 Slack에 메시지가 올라와 있습니다. 팀이 오늘 뭘 할지 한눈에 파악할 수 있죠.

이후 각 에이전트는 메시지를 보낼 때마다 자신이 누구인지 밝힙니다. Slack 스크립트의 --username 플래그를 이용해 CMO, Content Writer, Social Media Marketer처럼 표시하는 방식입니다.

node scripts/slack-message.js \\\\\\\\
  --channel C0AG3DDLZQS \\\\\\\\
  --username "Content Writer" \\\\\\\\
  --text "Blog post published: <https://runbear.io/posts/inbox-zero-is-dead>"

블로그 포스트가 올라가면 콘텐츠 작성자가 URL을 공유합니다. 소셜 미디어 세션이 끝나면 마케터가 댓글을 달거나 반응한 링크를 플랫폼별로 묶어 Slack 링크 형식으로 올려주는데, 탭 하나로 바로 확인할 수 있죠. 성과 검토 에이전트가 실행되고 나면 CMO가 당일 지표를 담은 요약을 올립니다.

오류도 빠짐없이 보고됩니다. 콘텐츠 작성자가 Sanity 스키마 오류를 만나거나 이미지 생성 API가 실패하면, 무엇이 잘못됐고 어떻게 시도했는지를 올려줍니다. 로그 파일을 뒤지지 않아도 문제를 바로 파악할 수 있죠. 결과적으로 이 Slack 채널은 팀 스탠드업 회의록처럼 읽힙니다. 제가 자는 동안 올라온다는 점만 빼면요.

매시간 자동으로 실행하기

에이전트 팀을 잘 설계하는 것과 실제로 사람 없이 돌아가게 만드는 건 별개의 문제입니다. 저는 침실에 Mac Mini M1을 상시 가동 머신으로 두고 있습니다. 소음도 없고 전력 소비도 적으면서, 노트북과 달리 실행 도중 절전 모드로 넘어가는 일이 없거든요. 처음 한 번 세팅해두고 나서 물리적으로 손댄 적이 없습니다.

원격 접속은Jump Desktop을 씁니다. 팀이 막히거나 세션을 직접 확인하고 싶을 때 폰이나 노트북에서 Jump를 열면 몇 초 안에 Mac Mini 화면이 뜹니다. 다른 나라에 있어도 안정적으로 작동했죠.

자동화 자체는 단순한 crontab 설정입니다. 매 시간 cron이 깨어나 헤드리스 모드로 Claude Code를 실행합니다.

0 * * * * cd /Users/.../ai-marketing-team && \
  claude --dangerously-skip-permissions \
  -p "You are the CMO. Check the current time, read the weekly plan, and execute the current time slot's tasks." \
  >> /tmp/claude-marketing.log 2>&1

몇 가지 짚고 넘어갈 부분이 있습니다.

dangerously-skip-permissions는 완전 자율 운영을 가능하게 해주는 플래그입니다. 이 플래그 없이는 파일 편집, 스크립트 실행, API 호출마다 Claude Code가 멈추고 승인을 기다리거든요. 이걸 켜면 에이전트들이 감독 없이 처음부터 끝까지 실행됩니다. 모든 에이전트 동작을 이미 검토하고 신뢰할 수 있는 프로젝트에서만 사용하는 걸 권장합니다.

로그 파일(/tmp/claude-marketing.log)에는 모든 실행 내역이 쌓입니다. 확인하고 싶을 때 Jump Desktop으로 접속해 읽으면 되는데, 에이전트들이 작업을 마치면 #team-ai-marketing에 Slack 알림을 보내주기 때문에 대부분은 Slack만 읽어도 충분합니다.

시간 단위 스케줄 시스템이 여기서 진가를 발휘합니다. 각 에이전트가 자신이 어느 시간대에 있는지, 그 시간대에 무엇을 해야 하는지 정확히 알고 있기 때문에, 매시간 실행되는 cron이 많은 걸 설명할 필요가 없습니다. "현재 시간대의 태스크를 실행하라"는 한 줄이면 충분하고, 나머지는 주간 일정 파일이 알아서 처리하죠.

전체 Claude API 비용은 블로그 포스트와 소셜 세션 수에 따라 하루 $20~50 정도 청구됩니다. 마케터 한 명을 풀타임으로 고용하는 비용에 비하면 새 발의 피죠.

마치며: CEO처럼 일하는 법

시스템이 돌아가기 시작하자 제 역할은 실행이 아닌 관리로 바뀌었습니다. 그런데 막상 해보면 놀라울 정도로 편합니다.

대부분의 상호작용은 이런 식입니다. Claude Code를 열고 "소셜 미디어 마케터가 어떤 플랫폼에서도 em 대시(—)를 쓰지 않도록 업데이트해줘"라고 입력하면 Claude가 에이전트 파일을 수정합니다. 또는 "HN 계정이 섀도우밴 당했어, 세션당 댓글을 하나로 제한하는 규칙을 추가해줘"라고 하면 Claude가 규칙을 업데이트하고 다음 세션부터 동작이 바뀝니다.

성과 검토 에이전트가 특정 트윗 형식이 효과가 없다는 걸 짚어내면 "소셜 마케터가 X 방식 대신 Y 방식을 쓰도록 업데이트해줘"라고 합니다. 콘텐츠 작성자가 실수를 하면 "Z를 방지하는 규칙을 추가해줘"라고 하죠. 이런 대화 하나하나가 30초면 끝나는데, 그 결과는 시스템에 영구적으로 반영됩니다.

에이전트 파일을 텍스트 에디터로 직접 열어본 적은 한 번도 없습니다. 모든 변경은 Claude를 통해 이루어지고 제가 원하는 걸 평범한 말로 설명하면 마크다운 파일이 업데이트됩니다. 가장 가까운 비유를 들자면 이렇습니다. Slack으로 원격 팀을 관리하는 것과 비슷한데, 팀원들이 완벽한 기억력을 갖고 있어서 정책 업데이트를 절대 잊지 않는다는 점이 다르죠.

예상 밖이었던 것들

가장 어려운 부분은 코드가 아니었습니다. 코드가 없었으니까요. 어려운 건 에이전트에게 줄 지침을 충분히 명확하게 쓰는 것이었습니다. 에이전트들은 모호한 표현을 예상치 못한 방식으로 해석하거든요. 첫 주에는 소셜 미디어 에이전트가 Reddit 스레드에 댓글을 중복으로 달았는데, "댓글 중복 금지"라는 규칙이 충분히 구체적이지 않았던 탓이었습니다. Claude에게 예시를 들어 규칙을 다시 쓰도록 했더니 바로 해결됐죠.

규칙은 복리처럼 작동합니다. 규칙 하나를 추가할 때마다 그 규칙을 읽는 모든 에이전트의 동작이 개선됩니다. 명확한 규칙 하나를 잘 써두는 것이, 개별 결과물을 일일이 수정하는 것보다 훨씬 큰 효과를 냅니다.

시간 단위 스케줄 시스템이 모든 걸 바꿔놨습니다. 이게 없었다면 CMO는 제가 아직 승인하지 않은 작업까지 처리하며 너무 많은 일을 하거나, 태스크 하나만 하고 멈추는 식으로 너무 적은 일을 했을 겁니다. 3시간 단위로 할 일을 미리 정해두니 언제 무슨 일이 일어날지 예측할 수 있게 됐습니다.

파일 수

위에서 설명한 모든 것이 대략 15~20개 파일 안에 담겨 있습니다.

에이전트 파일 5개
CLAUDE.md 1개
규칙 파일 6개
전략 문서 몇 개
커스텀 스크립트 4개

프레임워크도 없고, 특별한 인프라도 없습니다. 잘 정리된 폴더 구조와 문서가 전부죠. 누군가를 채용하면서 그 사람이 실제로 뭘 해야 하는지 이해할 수 있을 만큼 업무를 명확하게 정리해본 적이 있다면, 이미 이걸 만들 줄 아는 겁니다. 아마도 3편은 아직 제가 답을 찾지 못한 질문에서 시작할 겁니다. 이게 새로운 일하는 방식인 걸까요, 아니면 나중에 스스로 부끄러워질 무언가를 만들고 있는 걸까요? 아직 명확한 답은 없습니다. 그래서 오히려 써볼 만한 주제인 것 같습니다.

]]>

콘텐츠 AX, '프롬프트' 말고 '파일'을 보세요: 콘텐츠 AX 실험기 ②

AI로 콘텐츠를 만들어본 적 있다면, 이런 경험이 있을 겁니다. 클로드나 ChatGPT에 "블로그 글 써줘"라고 시키는 걸로 시작하는 겁니다. 바로 뭔가 나오긴 합니다. 그런데 톤을 고치고, 배경을 다시 설명하고, 몇 번을 더 주고받아야 쓸 만한 결과가 나옵니다. 매번 그렇습니다.

한 편을 만드는 건 이래저래 됩니다. 문제는 이걸 매주 반복해야 할 때입니다. 같은 브랜드 톤으로, 같은 품질 기준으로, 꾸준히. 채팅창에서 한 편씩 만드는 방식으로는 이 반복을 감당하기 어렵습니다.

저희 팀(요즘IT)은 이 문제를 정면으로 풀어보고 있습니다. 무엇을 쓸지 결정하고 목적에 맞는 글을 써내기까지의 과정을, AI 에이전트 여러 개가 알아서 돌아가는 파이프라인으로 만드는 실험입니다. 이 이야기를 이전에 한 번 공유했고, 그 글을 본 분들을 대상으로 수요조사를 진행했습니다. 91명이 응답해주셨는데, 숫자 몇 개가 눈에 띄었습니다.

➡️ 이전 글12분 49초 만에 한 달치 기획이 나왔다: 콘텐츠 AX 실험기보러가기

AI를 부분적으로 활용하고 있다 약 47%: 리서치, 초안, 아이디어 잡는 용도
시도해보지 않았거나, 시도했지만 만족스럽지 못했다 약 45%
체계적으로 활용하고 있다(자동화 워크플로우 포함) 약 4%: 91명 중 4명
가장 듣고 싶은 내용 1위: 파이프라인 구조(31%), 2위: AI 콘텐츠 품질 높이는 법(20%)
응답자의 약 76%가 비개발자: PM/기획자, 콘텐츠 마케터, 경영진 순

AI를 쓰고는 있습니다. 그런데 워크플로우까지 만들어본 분들은 거의 없었고 많은 분들께서 부분적으로 활용하고 있다고 하셨습니다.

이 데이터를 보면서, 또 주변 콘텐츠 담당자들의 반응을 살펴보면서 한 가지 생각이 들었습니다. 저희가 공유했던 콘텐츠 자동화 파이프라인이라는 것에 관해 각자 기대하는 것, 그리는 그림이 다를 수 있겠다는 것입니다.

블로그 에이전트로 작성한 글 캡처 <출처: 요즘IT>

이번 글에서는 블로그 콘텐츠를 자동으로 작성해주는 에이전트라는 것에 어떤 기대와 그림을 갖고 계시면 좋을지, 일종의 멘탈 모델을 제안하려 합니다. "AI한테 채팅으로 시키는 것"과 "에이전트 기반 워크플로우를 만드는 것"은 뭐가 다른지, 그리고 그 차이를 만드는 게 왜 .md 파일인지에 관한 이야기입니다. 이 정리를 거치면 세미나에서 다룰 파이프라인 구조와 에이전트의 작동 원리가 훨씬 선명하게 와닿을 겁니다.

채팅, 자동화, 에이전트: 뭐가 다른가

수요조사에서 47%가 응답한 "부분적으로 활용하고 있다"의 실체는, 아마 이런 모습일 겁니다. 클로드나 ChatGPT를 열고, 몇 가지 맥락을 주고, "이 주제로 블로그 글 써줘"라고 합니다. 결과를 보고 톤을 조정하고, 몇 번 더 주고받은 뒤 괜찮은 부분을 복사해서 문서에 붙여넣습니다. 혹은 품질 좋은 글을 만드는 각자만의 프롬프트 노하우가 있으시겠죠.

요즘IT가 실시한 설문조사 결과 일부 <출처: 요즘IT>

나쁜 방식이 아닙니다. 초안을 잡거나 아이디어를 확장하는 데는 꽤 효과적이고, 대부분의 실무자가 여기서 상당한 시간을 절약하고 있을 겁니다.

하지만 이 방식에는 천장이 있습니다. 매번 사람이 대화를 시작하고, 결과를 판단하고, 다음 단계를 지시해야 합니다. "한 편을 잘 만드는 것"은 가능하지만, "매주 3편을, 일관된 품질로, 같은 브랜드 톤을 유지하면서 만들어내는 것"은 이 구조에서 어렵습니다. 사람이 빠지는 순간 멈추니까요.

그러면 자동화하면 되지 않느냐고 할 수 있습니다. 그런데 '자동화'라는 단어도 범위가 넓습니다. MAKE나 Zapier를 써보신 분들은 아시겠지만, 노코드·로코드 툴로 트리거와 액션을 연결해서 반복 업무를 자동으로 처리하는 것도 자동화입니다. 이때 LLM이 필요 없는 경우도 많습니다.

저희가 만들고 있는 것은 이것과 다릅니다. 에이전트는 단순히 트리거에 반응하는 게 아니라, 스스로 판단하고 실행합니다. LLM이 두뇌라면 에이전트는 그 두뇌에 손과 발까지 붙은 것입니다. 매번 사람이 맥락을 주입하거나 프롬프트를 바꾸는 게 아니라, 에이전트가 맥락과 프롬프트를 스스로 참조해서 결과물을 내놓도록 하는 시스템입니다. 이전 글에서는 조금 더 친숙한 '콘텐츠 자동화'라는 표현을 썼지만, 저희가 만들고 있는 것은 기업 블로그 에이전트라고 표현하는 것이 더 맞습니다. 세미나 제목이 '블로그 에이전트'라는 다소 낯설어 보이는 이름이 된 이유이기도 합니다.

그러면 채팅으로 시키는 것과 에이전트 기반 워크플로우는 구체적으로 뭐가 다를까요?

차이를 만드는 세 가지

1.에이전트는 역할이 나뉘어 있습니다

첫째로, 역할이 나뉘어 있습니다. 채팅에서는 하나의 AI에게 모든 걸 시킵니다. "이 키워드로 리서치해서 블로그 글 기획안 만들어줘." 리서치도, 판단도, 구조 설계도 하나의 대화창 안에서 이루어집니다.

에이전트 파이프라인에서는 다릅니다. 리서치하는 에이전트, 그 결과를 보고 판단하는 에이전트, 글의 구조를 설계하는 에이전트가 따로 있습니다. 각자 맡은 일만 합니다.

요즘IT 블로그 에이전트 구성. 이 구성은 두 번째 버전이며, 첫 번째 버전의 구성은 이전 글에 간단히 언급되어 있습니다. 세미나에서는 두 버전 모두 공유하고, 왜 두 번째 버전을 만들게 됐는지 두 가지의 차이점은 무엇인지도 이야기합니다. <출처: 요즘IT>

왜 이렇게 나눌까요. 하나에게 전부 시키면 리서치도 얕아지고 판단도 얕아지기 때문입니다. 사람도 마찬가지입니다. 콘텐츠 마케터가 키워드를 디깅하는 시간, 그 키워드를 평가하는 시간, 글의 구조를 잡는 시간은 각각 다른 종류의 집중을 요구합니다. 에이전트도 같습니다.

저희도 처음에는 하나의 에이전트에 여러 역할을 넣었다가, 결과가 얕아지는 문제를 겪었습니다. 어떻게 나눴고 뭐가 달라졌는지는 세미나에서 실제 사례로 보여드립니다.

2.에이전트는 맥락을 갖고 있습니다

둘째, 맥락이 미리 저장되어 있습니다. 채팅에서 콘텐츠를 만들 때, 매번 "우리 회사는 이런 서비스를 하고 있고, 톤은 이렇고, 지난달에 이런 글을 발행했으니 겹치지 않게" 설명해야 합니다. 빠뜨리면 아무 회사나 쓸 수 있는 범용적인 글이 나옵니다.

워크플로우에서는 이 맥락이 파일로 미리 세팅되어 있습니다. 에이전트는 매번 같은 맥락 위에서 일합니다. 저희 경험으로는, 같은 에이전트라도 위시켓의 브랜드 프로필과 기발행 글 260편의 DB를 넣어주느냐에 따라 결과물의 성격이 완전히 달라졌습니다. 맥락 없이 돌리면 "아무 기업 블로그에나 실릴 법한 글", 맥락을 입히면 "위시켓 블로그에서만 나올 수 있는 글"이 나오기 시작했습니다.

맥락이 저장된 md파일 일부 캡처. 위시켓 서비스를 설명한 md 파일(왼쪽)과 블로그의 원칙을 담은 md 파일(오른쪽) <출처: 요즘IT>

3. 에이전트 워크플로우에서는 사람이 개입할 지점을 설계합니다

셋째, 사람이 개입하는 지점이 설계되어 있습니다. 채팅에서는 AI가 뭔가를 내놓을 때마다 사람이 판단해야 합니다. 에이전트 워크플로우에서는 사람이 개입해야 하는 지점이 미리 정해져 있습니다. 리서치도, 분류도, 기획안 작성도 자동으로 돌아가고, 특정 단계가 완성되면 그때 사람이 봅니다.

이건 단순히 편해지는 것 이상의 의미가 있습니다. 데이터를 긁어모으고 정리하는 건 AI가 더 빠르고, "이 키워드가 우리 비즈니스에 정말 필요한 주제인가"를 판단하는 건 사람이 더 잘합니다. 워크플로우는 이 역할 분담을 구조화한 것입니다. 구체적으로 어디서 사람이 개입하고, 왜 그렇게 설계했는지는 세미나에서 다룹니다.

그러면 이 구조는 어떻게 만드는 걸까요? 에이전트의 핵심은 코드가 아니라 업무 매뉴얼입니다. 그 매뉴얼이 실제로 어떤 형태이고, 어떤 도구로 에이전트에게 전달되는지를 이야기해보겠습니다.

AI와의 채팅과 에이전트는 어떻게 다른가 <출처: 요즘IT>

에이전트는 어떻게 만드는가: 클로드 코드와 .md 파일

에이전트가 명령에 따라 돌아간다고 했습니다. "어떤 역할을 맡고 있는지, 어떤 순서로 작업하는지, 어떤 기준으로 판단하는지." 이 명령들이 .md라는 파일 형식으로 정리됩니다.

.md는 마크다운(Markdown)의 확장자입니다. 프로그래밍 언어가 아닙니다. 자연어로 구조화해서 적어놓은 텍스트 파일입니다. 제목에 #을 붙이고, 목록에 -를 붙이는 정도의 간단한 서식 규칙이 있을 뿐입니다.

예를 들어 리서치 에이전트의 매뉴얼은 이런 식입니다.

역할: 입력된 키워드를 기반으로 시장 데이터를 수집한다. 판단하지 않는다. 수집만 한다.
작업 순서: 키워드에서 검색 의도를 분류한다 → 자동완성, 연관검색어를 수집한다 → 수집된 키워드를 의미 기준으로 그룹핑한다
판단 기준: 이 단계에서는 키워드의 좋고 나쁨을 판단하지 않는다. 다음 에이전트가 판단한다.

researcher.md 문서 일부 캡처 <출처: 요즘IT>

이게 에이전트의 명세서입니다. 코드가 아닙니다. "이런 순서로 해라", "이 단계에서는 판단하지 마라" 같은 지시를 자연어로 적어둔 것입니다.

이런 .md 파일이 파이프라인 안에서 세 가지 역할을 합니다. 에이전트의 역할과 작업 순서를 정의하는 것도 .md 파일이고, 브랜드 톤이나 집필 스타일 같은 맥락을 담아두는 것도 .md 파일이고, 에이전트가 참조하는 가이드도 .md 파일입니다. 앞서 설명한 세 가지 차이, 즉 역할 분리, 맥락 저장, 검토 포인트를 실제로 구현하는 수단이 전부 이 .md 파일인 셈입니다.

그런데 .md 파일만으로는 에이전트가 돌아가지 않습니다. 이 매뉴얼을 읽고 실행하는 환경이 필요합니다. 저희는 클로드 코드를 사용했습니다. 일반 채팅과 결정적으로 다른 점은, AI가 파일을 직접 읽고 쓸 수 있다는 것입니다. 매뉴얼을 읽고, 매뉴얼대로 작업을 처리하고, 결과를 파일로 저장합니다. 채팅에서 매번 맥락을 입력해야 했던 한계가 여기서 해결됩니다.

그리고 이 매뉴얼을 처음부터 사람이 혼자 쓸 필요도 없습니다. "리서치 에이전트의 역할 명세를 만들어줘"라고 시키면, AI가 명세 초안을 작성합니다. 사람은 그 초안을 보고 "판단은 이 단계에서 하지 마", "출력 형식은 이렇게 바꿔줘" 같은 식으로 수정하면 됩니다.

결국 사람이 해야 하는 일은 두 가지입니다. "이 업무가 어떤 순서로, 어떤 기준으로 돌아가야 하는지"를 아는 것. 그리고 AI가 만든 초안을 보고 "이건 맞다, 이건 아니다"를 판단하는 것. 코딩 능력이 아니라, 자기 업무를 정확히 아는 것이 핵심입니다.

그런데 이 모든 걸 개발자가 아닌 콘텐츠 전문가가 실행했습니다. 콘텐츠를 매일 기획, 편집, 제작하는 사람이 직접 만들었는데, 그 과정에서 콘텐츠 마케팅에 필요한 도메인 지식을 실제 콘텐츠 마케터와 LLM의 도움을 더해 채워갔습니다.

그게 가능한 이유는 콘텐츠를 만드는 방식과 좋은 품질의 콘텐츠를 평가할 수 있는 눈, IT 미디어를 운영하면서 가질 수밖에 없었던 에이전트에 관한 약간의 관심과 지식, 그리고 LLM의 도움 덕분입니다.

에이전트를 만드는 방식에 정답은 없습니다. 내가 내 업무 전문성을 바탕으로 일을 어떻게 나누어 어떤 기준을 가지고 만들지를 판단하는 것이 가장 중요합니다.

블로그 에이전트로 만든 월간 기획. 초기에는 월간 기획에 12분 49초 소요됐으나 현재는 1시간 30분 소요되며 품질은 더욱 향상되었습니다. <출처: 요즘IT>

마치며

이 글에서는 채팅과 에이전트 기반 워크플로우가 뭐가 다른지, 그리고 그 차이를 만드는 .md 파일이 어떤 것인지를 정리했습니다. 세미나에서는 여기서 한 발 더 들어갑니다.

저희가 설계한 6단계 파이프라인의 전체 구조, 각 단계에서 에이전트를 어떻게 나눴고 왜 그렇게 나눴는지, 사람이 개입하는 지점은 어디에 두었는지를 공유합니다. 기획 단계에서 에이전트를 쪼개고 재설계한 과정, 도메인 지식을 주입하면서 부딪힌 벽, 생성된 콘텐츠의 품질이 어디까지 왔고 무엇이 아직 부족한지. 또 최근에는 에이전트 구성을 바꿔 좀더 간단한 구성으로 시도하고 있는데, 그 이야기도 들려드립니다. '다 된다'가 아니라 실제로 해보니 가능한 것, 한계인 것들을 솔직하게 공유합니다.

이 블로그 에이전트 구축은 조직의 AX만큼이나 콘텐츠 담당자 한 명이 할 수 있는 것이 아니었습니다. 물론 혼자서 만들 수는 있지만, 만드는 과정에서뿐 아니라 만드는 데 필요한 데이터를 확보하는 데에는 개인만이 아닌 조직 차원의 노력이 필요할 수 있다는 것도 깨달았습니다. 이런 이야기를 솔직하게 공유합니다.

기업 블로그나 콘텐츠 마케팅을 담당하면서 AI 자동화를 검토 중인 분, "에이전트"라는 개념이 궁금한데 실제 사례를 먼저 보고 싶은 분, 직접 자동화 파이프라인을 만들어보고 싶은데 전체 그림이 안 잡히는 분이라면 도움이 될 겁니다.

특히 개발자가 아닌 콘텐츠 전문가가 만든 것이기 때문에 기업 블로그 업무를 에이전트화하는 것에 관한, 지금 시장엔 없는 가장 현실적인 이야기들이 담겨 있을 것입니다. 기업의 내부 데이터 소스를 블로그 글과 어떻게 연결시킬지, 채팅창(세션)마다 매번 달라지는 생성 품질을 어떻게 유지할지, 요즘 마케팅 씬에서 큰 화두인 GEO에 맞춤한 콘텐츠를 발행한다는 것의 현실적인 의미가 무엇인지, 이런 고민이 저희 작업 과정에 고스란히 녹아 있습니다.

개인용 콘텐츠를 자동하는 것과 기업용 콘텐츠를 자동화하는 것은 다릅니다. <출처: 요즘IT>

결국 자동화의 출발점은 AI가 아니라, 내 업무입니다. 내가 하는 일이 어떤 순서로 돌아가는지, 어디서 판단이 필요한지, 그 판단에 뭘 참고하는지. 이걸 정리할 수 있으면, 에이전트를 만들 준비가 된 겁니다.

콘텐츠 담당자를 위한 기업 블로그 에이전트의 가능성과 한계
일시: 4월 17일(금) 저녁 7시
형식: 온라인 라이브(Zoom) · 발표 30분 + Q&A 20분
얼리버드: 11,900원 (4/16까지)
➡️ [세미나 신청 링크]
*구매 후 다운로드할 수 있는 PDF에 줌 등록 링크가 포함되어 있으니 꼭 확인 부탁드립니다.

수요조사에서 "체계적으로 활용하고 있다"고 답한 분은 91명 중 4명이었습니다. 이 글과 세미나가 그 비율을 바꾸는 데 도움이 되면 좋겠습니다.

]]>

AI 시대 해커톤은 어떻게 변해야 하는가?

참가자·운영자가 함께 변화된
2026 GDGOC KR 연합 해커톤 ONE WAVE의 기록

AI로 정보를 찾고, 화면을 만들고, API를 연결하는 일이 눈에 띄게 빨라졌습니다. 이제는 혼자서도 몇 시간 만에 프로토타입을 만들 수 있는 시대입니다. 구현 속도 자체가 더 이상 차별점이 되기 어려워진 지금, 해커톤은 무엇을 증명하는 자리여야 할까요? 단순히 정보를 나누는 행사나 구현량을 겨루는 형식만으로는 해커톤의 의미를 설명하기 어려워지고 있습니다. 어쩌면 해커톤이라는 형식 자체가 사라질 수도 있습니다.

그럼에도 해커톤이 여전히 필요하다면, 그 이유는 짧은 시간 안에 문제를 정의하고, 우선순위를 정하고, 가설을 검증 가능한 형태로 만들어보는 밀도 높은 경험에 있다고 생각했습니다. 저희는 바로 그 밀도를 지금의 트렌드에 맞게 다시 설계해 보고 싶었습니다. 그래서 2026년 2월, Google for Developers 산하 대학 거점 개발자 커뮤니티 GDG on Campus의 18개 대학이 모여 연합 해커톤 ONE WAVE를 열었습니다.

160명의 참가자, 35개 팀이 무박 2일 동안 하나의 주제를 두고 각자의 방식으로 문제를 정의하고, 서비스를 설계하고, 결과물을 만들어냈습니다. ONE WAVE라는 이름에는 서로 다른 배경의 참가자들이 각자의 물결로 모여 하나의 파도가 된다는 의미를 담았습니다. 단순히 ‘마지막 낭만’으로 소비하고 싶지는 않았습니다. 해커톤을 연 이유가 단순히 "행사를 해보고 싶어서"가 아니었던 것입니다.

GDGOC ONE WAVE 해커톤 <출처: GDGOC ONE WAVE>

이번 해커톤에서 가장 크게 달라진 점은 참가자와 운영진 모두의 역할이 바뀌었다는 것입니다. 참가자에게는 AI를 활용해 구현 시간을 줄이는 대신, 문제 정의와 기획, 차별점과 실현 가능성에 더 많은 시간을 쓰도록 유도했습니다. 배포는 필수가 아니라 선택으로 두었고, 심사 기준도 코드량보다 기획의 밀도에 더 큰 비중을 두었습니다. 운영진 역시 마찬가지였습니다. 참가자 등록과 취소 관리, 팀 매칭 시각화, 심사 배점 자동 취합처럼 반복적으로 발생하는 업무를 AI를 활용해 빠르게 백오피스로 만들어 사용했고, 현장에서 필요한 기능은 즉시 개발해 운영에 반영했습니다.

이 글은 그 실험의 기록입니다. 참가자 측에서 무엇이 달라졌는지, 운영진 측에서 어떻게 일하는 방식을 바꿨는지, 그리고 그 결과 현장에서 실제로 어떤 변화가 만들어졌는지를 중심으로 정리했습니다.

ONE WAVE가 집중했던 부분

1. 배포는 ‘선택’으로

AI 시대의 개발자는 더 이상 단순히 코드를 짜고 배포하는 사람에 머물지 않습니다. 이제는 프로덕트의 가치를 기술로 녹여내는 사람으로 역할이 확장되고 있습니다. 저희는 이번 해커톤이 그 변화를 자연스럽게 체감할 수 있는 자리가 되기를 바랐습니다. 이제 개발자에게 더 중요한 질문은 “얼마나 많이 구현했는가”보다 “무엇을 왜 만들었는가”에 가깝다고 생각했기 때문입니다.

이 관점을 참가자들이 더 구체적으로 느낄 수 있도록, AI 엔지니어를 연사로 모셔 AI로 개발하는 방법에 대한 특강도 진행했습니다. AI를 단순한 보조 도구가 아니라, 구현 시간을 줄여 더 중요한 판단에 시간을 쓰게 해주는 도구로 받아들이기를 바랐습니다. 그래서 해커톤 전반에서도 계속 “AI를 사용해 빠르게 개발하되, 남는 시간을 기획과 검증에 쓰자”는 방향을 강조했습니다.

이런 이유로 이번 해커톤에서는 배포를 ‘필수’가 아니라 ‘선택’으로 두었습니다. 24시간 안에 모든 팀이 배포까지 마쳐야 한다고 강제하면, 적지 않은 팀이 인프라 설정이나 예기치 못한 오류 해결에 많은 시간을 쓰게 됩니다. 저희는 그 시간만큼 문제 정의와 핵심 사용자 흐름, 차별점과 실현 가능성을 더 깊게 다루기를 바랐습니다. 심사 기준 역시 기술의 복잡도나 코드량보다 서비스 자체의 기획, 문제 정의, 실현 가능성에 더 많은 비중을 두었습니다.

결과적으로 배포를 선택으로 둔 것이 참가자들의 완주를 막지는 않았습니다. 35개 팀 중 34개 팀이 최종 결과물을 제출해 97%의 완주율을 기록했고, 이 가운데 18개 팀은 배포가 필수가 아니었음에도 자발적으로 서비스 URL까지 배포하며 MVP를 완성했습니다. 배포를 강제하지 않았기에 포기한 것이 아니라, 기획에 충분한 시간을 쓴 뒤 남는 시간으로 배포까지 도달한 것입니다.

결국 저희가 참가자들에게 전하고 싶었던 메시지는 분명했습니다. 이제 개발자는 코드를 만들어내는 사람을 넘어, 그 코드가 의미를 갖게 만드는 사람이어야 한다는 점입니다.

2. 해커톤의 주제: ‘취업난’

좋은 서비스는 대개 내가 직접 느끼는 문제에서 출발합니다. 그래서 이번 해커톤의 주제를 정할 때도 참가자들이 가장 보편적으로, 그리고 가장 크게 공감할 수 있는 문제가 무엇일지를 오래 고민했습니다. 그 결과 선정한 주제가 바로 ‘취업난’이었습니다.

GDGOC ONE WAVE 해커톤 OT - 주제 공개 <출처: GDGOC ONE WAVE>

대학생에게 취업은 너무 멀지도, 너무 추상적이지도 않은 문제입니다. 이미 현실로 닿아 있고, 주변의 많은 사람이 함께 고민하는 주제이기도 합니다. 실제로 주제가 공개되었을 때 행사장에서는 웃음과 탄식이 동시에 나왔습니다. 모두가 너무 잘 알고 있는 문제였기 때문입니다. 저희는 바로 그 공감대를 출발점으로 삼고 싶었습니다.

다만 큰 주제가 하나로 주어지면 비슷한 아이디어가 반복될 가능성도 큽니다. 이를 막기 위해 ‘검증’, ‘실전’, ‘전략’, ‘멘탈’이라는 네 개의 서브 키워드 중 하나를 선택해 조합하도록 했습니다. 같은 ‘취업난’을 다루더라도 어떤 팀은 정보의 신뢰성과 검증에, 어떤 팀은 실전 준비에, 또 어떤 팀은 전략 설계나 멘탈 관리에 더 집중할 수 있도록 한 것입니다. 이 장치 덕분에 참가자들은 하나의 공통 문제를 두고도 각기 다른 타깃 사용자와 해결 방식을 설계할 수 있었습니다.

실제로 이 장치는 참가자들의 문제 정의를 꽤 선명하게 갈라놓았습니다. 한 팀은 스펙 위주의 서류 전형이 실제 역량을 제대로 보여주지 못한다는 점에 주목해, 이력서를 없애고 실무 과제만으로 평가받는 채용 플랫폼을 제안했습니다. 반면 세 개의 팀은 취업난을 정보나 역량의 문제가 아니라 반복된 탈락 속에서 무너지는 심리의 문제로 해석하고, 짧은 챌린지와 감정 기반 피드백을 제공하는 멘탈 케어 서비스로 풀어냈습니다.

이 밖에도 기업 기술 블로그를 바탕으로 실무 시뮬레이션을 만든 팀, 합격자의 준비 과정을 타임라인으로 시각화한 팀 등 접근 방식은 다양했습니다. 결국 같은 '취업난'이라는 주제를 두고도, 어떤 팀은 역량의 검증을, 어떤 팀은 심리적 회복을, 또 어떤 팀은 실전 체감이나 전략 설계를 핵심 문제로 삼은 것입니다.

GDGOC ONE WAVE 해커톤 참가 팀 기획 물 <출처: GDGOC ONE WAVE>

반면 또 다른 한팀은 기업마다 다른 실무 환경과 의사결정 문화를 미리 체감하지 못하는 점을 문제로 보고, 기업 기술 블로그를 바탕으로 실제 상황을 롤플레잉하는 시뮬레이션 서비스를 기획했습니다. 결과론적인 합격 스펙보다 합격자가 어떤 순서로 무엇을 해왔는지가 더 중요하다고 판단해, 준비 과정을 타임라인 형태의 전략 로드맵으로 시각화한 두 팀도 있었습니다.

또 세 개의 팀은 취업난을 단지 정보나 역량의 문제가 아니라 반복된 탈락 속에서 무너지는 심리의 문제로 해석하고, 짧은 챌린지와 감정 기반 피드백을 제공하는 멘탈 케어 서비스로 풀어냈습니다. 결국 같은 ‘취업난’이라는 주제를 두고도, 어떤 팀은 역량의 검증을, 어떤 팀은 실전의 체감을, 어떤 팀은 준비 전략을, 또 어떤 팀은 심리적 회복을 핵심 문제로 삼았습니다.

3. 미리 ‘기획’을 공개하다

요즘은 좋은 서비스가 나오면 AI를 활용해 하루 만에 유사한 서비스가 만들어지는 시대입니다. 이런 환경에서는 아이디어를 끝까지 숨기는 것만으로 차별점을 만들기 어렵습니다. 오히려 중요한 것은 같은 문제를 보더라도 어떤 관점으로 정의하고, 어떤 근거와 논리로 풀어내는가에 있다고 생각했습니다.

그래서 저희는 각 팀이 행사 첫날 저녁, 기획을 마무리하고 본격적인 개발에 착수하기 직전에 기획 내용을 공유하도록 했습니다. 아이디어가 아직 흐릿한 단계에서는 서로의 방향을 비교하기 어렵고, 반대로 개발이 너무 진행된 뒤에는 중복을 인지하더라도 기획을 수정하기 쉽지 않기 때문입니다. 다시 말해, 서비스의 뼈대는 세워졌지만 아직 방향 전환의 여지가 충분히 남아 있는 시점을 의도적으로 기획 교류 시간으로 잡았습니다.

실제로 기획 교류 시간에 등록된 35개 팀의 아이디어를 살펴보면, AI를 활용해 취업 문제를 해결하겠다는 큰 방향은 비슷했지만 세부 주제는 생각보다 많이 겹쳤습니다. 면접 연습 및 피드백이 4팀, 취업 멘탈 케어가 4팀, 취업 로드맵 생성 및 매칭이 4팀, 적합성 검증 및 기업 매칭이 4팀이었고, 이력서·자기소개서 첨삭 및 생성도 3팀에 달했습니다. 마지막 발표 전까지 서로의 기획을 보지 못했다면, 적지 않은 팀이 발표장에서야 “우리와 비슷한 주제가 이렇게 많았구나”를 확인했을 것입니다.

이 구조가 실제로 의미 있었던 이유는, 참가자들이 단순히 기능을 더 붙이는 대신 문제를 다시 정의하게 만들었기 때문입니다. 대표적인 사례가 Team 36이었습니다. 이 팀은 초기에는 깃 로그 분석, 모션 인식 등 여러 기술 요소를 포함한 비교적 넓은 취업 지원 서비스를 구상했습니다. 하지만 기획 교류를 통해 범용 면접 앱이나 자기소개서 관련 서비스가 이미 여러 팀에서 나오고 있다는 점을 확인한 뒤, 방향을 과감하게 좁혔습니다.

ONE WAVE 해커톤 밤샘 개발 현장 <출처: GDGOC ONE WAVE>

AI가 자기소개서를 대신 써주거나 면접 답변을 만들어주는 쪽이 아니라, 지원자가 자기 경험을 스스로 복기하고 구조화하도록 돕는 ‘커리어 리플렉션’에 집중한 것입니다. 최종 결과물에서는 모션 인식 같은 부가 기능을 덜어내고, 경험 정리와 질문 유도에 초점을 맞춘 서비스로 정체성을 선명하게 만들었습니다. 같은 취업 준비라는 주제를 다루더라도, 어디를 문제의 핵심으로 보느냐에 따라 완전히 다른 서비스가 될 수 있다는 점을 보여준 사례였습니다.

기획 교류 이후 가장 인상적이었던 점은 ‘기능의 추가’보다 오히려 ‘기능의 삭제’가 더 자주 일어났다는 사실입니다. 초기 기획안과 최종 결과물을 비교해 보면, 많은 팀이 이것저것 다 넣으려는 방향에서 벗어나 한 줄로 설명 가능한 핵심 가치에 집중했습니다. 저희는 이 과정을 통해, AI 시대의 해커톤에서는 구현 자체보다도 누구의 어떤 문제를, 왜 이 방식으로 해결하는가를 더 밀도 있게 설명하는 기획이 차별점이 된다는 사실을 다시 확인했습니다.

4. 운영진 또한 AI로 일한다

AI 시대의 해커톤을 이야기하면서 참가자만 바뀌어서는 충분하지 않습니다. 운영 방식 역시 함께 달라져야 합니다. 해커톤 현장에는 생각보다 많은 반복 업무가 있습니다. 참가자 등록과 취소 상태 관리, 운영진 및 참가자 권한 부여, 팀 매칭 현황 시각화, 참가자 연락, 팀별 현황 조사, 심사 배점 입력과 결과 취합처럼 하나하나 보면 단순하지만 실제로는 많은 시간을 잡아먹는 일들입니다. 이런 업무가 수작업에 의존할수록 운영진은 작은 변경에도 여러 문서를 오가며 확인해야 하고, 현장 대응 속도도 자연스럽게 느려질 수밖에 없습니다. 그래서 저희는 반복적이고 비효율적인 운영 업무를 가능한 한 시스템 안으로 끌어들였습니다.

대표적인 사례는 심사 결과 자동 산정 대시보드였습니다. 심사위원이 시스템에서 바로 점수를 입력하면 예선·본선 점수와 가중치가 즉시 반영되고, 동점 여부까지 포함한 최종 순위가 자동으로 계산되도록 구성했습니다. 운영진이 별도의 시트에서 점수를 다시 모으고 계산식을 확인하던 과정을 줄이면서, 시상 직전의 취합 부담도 크게 낮출 수 있었습니다.

심사 현황 관리 시스템 <출처: GDGOC ONE WAVE>

참가자 상태 관리 역시 자동화했습니다. 해커톤 운영에서는 참여 취소, 팀 변경, 명단 수정처럼 참가자 상태가 바뀌는 일이 생각보다 자주 생깁니다. 문제는 이런 변경이 오프라인 명단 수정에서 끝나지 않는다는 점입니다. 참가자들이 모여 있는 디스코드에서도 해당 인원의 접근 권한을 조정하고, 필요한 경우 닉네임 표시까지 함께 바꿔야 했기 때문입니다. 이를 수작업으로 처리하면 운영진이 디스코드 관리자 화면에서 한 명씩 사용자를 찾아 역할을 수정해야 해 시간이 많이 들고, 변경 사항이 누락될 가능성도 있었습니다.

그래서 저희는 백오피스에서 상태가 변경된 참가자들을 선택하면 디스코드 권한과 닉네임이 자동으로 함께 반영되도록 만들었습니다. 덕분에 오프라인에서 변경된 내용이 온라인 운영 공간에도 바로 동기화됐고, 운영진은 반복적인 권한 관리보다 참가자 경험과 현장 흐름을 살피는 일에 더 집중할 수 있었습니다.

참가자 관리 시스템 <출처: GDGOC ONE WAVE>

또한 현장에서는 계획한 기능만으로는 부족한 순간이 자주 생깁니다. 이번 해커톤에서는 그런 순간마다 필요한 기능을 즉시 만들어 실제 운영에 반영할 수 있었습니다. 행사 도중 구글 로그인 오류가 발생했을 때는 팀별 임시 비밀번호 로그인 기능을 곧바로 추가해 제출 병목을 해소하기도 했습니다. 저희에게 AI는 단순히 일을 빨리 하는 도구가 아니라, 운영 과정에서 드러나는 병목을 현장에서 바로 시스템으로 바꾸는 도구였습니다.

이 지점에서 운영진의 역할도 조금 달라졌다고 느꼈습니다. 예전처럼 많은 일을 손으로 빠르게 처리하는 사람이 되는 것보다, 반복 업무를 시스템화하고 현장의 흐름이 끊기지 않도록 구조를 설계하는 사람이 되는 것이 더 중요해졌기 때문입니다. ONE WAVE는 참가자들이 AI를 활용해 개발 방식의 변화를 경험한 자리였을 뿐 아니라, 운영진 역시 AI를 활용해 일하는 방식 자체를 바꿔본 자리이기도 했습니다.

대상 수상작 소개

기획 교류 시간에 팀별 아이디어를 등록하면 관리자였던 저 역시 내용을 함께 확인할 수 있었는데요. 그중에서 주제를 처음 봤을 때 “이 팀은 참신하다”는 인상을 준 팀이 있었습니다. 바로 8팀이었습니다.

8팀 발표 모습 <출처: GDGOC ONE WAVE>

8팀은 장애인 구직자와 기업을 연결하고, 채용 정보의 디지털 접근성을 개선하는 매칭 플랫폼 ‘BARRIER FREE’를 제안했습니다. 이들이 높은 평가를 받은 이유는 ‘취업난’이라는 큰 주제 속에서 타깃 사용자가 명확했고, 그들이 겪는 현실적인 장벽을 구체적인 데이터와 UX로 풀어냈기 때문입니다.

8팀이 제안한 서비스의 핵심 플로우는 이렇습니다. 시각장애인 구직자가 앱에 접속하면 화면을 읽기 힘든 점을 고려해 클라우드 기반 텍스트 음성화(TTS) 기능으로 사운드 안내를 제공합니다. 구직자가 안내에 따라 10~60초간 자신의 경력을 음성으로 녹음하면, 음성 텍스트화(STT) 기술과 OpenAI를 활용해 말하는 것만으로 이력서가 자동 생성됩니다. 기존 채용 플랫폼이 장애 정도를 단순히 ‘심하다/심하지 않다’로 뭉뚱그려 정보만 제공했던 것과 달리, 실제 사용자가 정보를 입력하고 탐색하는 과정 자체의 '디지털 접근성' 장벽을 허문 것입니다.

8팀 발표 슬라이드 - 핵심 기능 <출처: GDGOC ONE WAVE, 8팀(남경인, 강지윤, 안성현, 조정현)>

또한, 이들은 문제 해결의 근거로 구체적이고 수치화된 데이터를 활용했습니다. 구직자의 직무 역량을 판단하기 위해 수작업, 근력, 시력 등 6개의 신체 역량을 4단계로 세분화하여 수치화했습니다. 이 데이터와 공공데이터포털의 정보를 결합하여, 신체 환경 적합도뿐만 아니라 고용 안정성과 급여 매력도 등을 100점 만점의 매칭 점수로 환산해 추천해 주는 전략적인 검색 엔진을 구축했습니다.

심사위원분들의 평가 역시 비슷한 방향에 모였습니다. 발표가 깔끔하고 전달력이 좋았으며, 문제를 잘 정의한 뒤 그에 맞는 해결책을 제시하는 흐름이 좋았다는 평가가 있었습니다. 참신한 아이디어로 틈새시장을 날카롭게 공략했다는 의견도 있었고, 다수의 사람이 공감할 수 있는 약자와 소수자의 문제를 해결하려 했다는 점을 강점으로 보신 분들도 계셨습니다. 활용하는 데이터와 API가 비교적 구체적이었고, 시장을 설정하는 앞단의 논리 구조 역시 잘 짜여 있었다는 평가도 이어졌습니다.

저 역시 이 팀이 높은 평가를 받은 이유가 분명하다고 느꼈습니다. 먼저 서비스의 타깃이 입체적이었습니다. 장애인 구직자뿐만 아니라, 장애인을 고용하지 않을 경우 1인당 200만 원의 고용부담금을 내야 하는 기업의 HR 담당자까지 핵심 타깃으로 삼아 맞춤형 대시보드를 기획했습니다. 또 문제 해결에 사용할 데이터와 근거가 비교적 구체적이었으며, 그 사용자를 위한 UX 흐름도 자연스럽게 설계되어 있었습니다. 결국 이 수상작은 이번 해커톤이 무엇을 더 중요하게 보았는지를 잘 보여주는 사례였습니다. 코드의 양보다 누구를 위해, 어떤 문제를, 어떤 근거와 흐름으로 풀어냈는가가 더 중요하다는 점 말입니다.

ONEWAVE Team 인터뷰

ONE WAVE는 11월 초부터 약 두 달간, 전국 18개 챕터에서 모인 운영진이 8개 파트(Sales, DevRel, HR, Infra, Marketing, Branding, Finance, Operation)로 나뉘어 준비했습니다. 이 글에서 계속 이야기한 것처럼, 이번 해커톤은 참가자뿐 아니라 운영진의 일하는 방식도 함께 바뀌는 실험이었습니다. 그 변화를 가장 직접적으로 체감한 세 파트를 소개합니다. 백오피스를 직접 설계한 총괄, 체크인 시스템을 자체 개발한 Infra, 평가 환경의 설계를 바꾼 Sales의 이야기입니다. 이어서 나머지 파트의 운영진이 각자의 자리에서 어떤 역할을 맡았는지도 함께 전합니다.

GDGoC ONE WAVE 해커톤 운영진 단체사진 <출처: GDGOC ONE WAVE>

총괄: 강남대학교 정은혁

안녕하세요! 이번 ONE WAVE 해커톤에서 총괄을 맡은 정은혁입니다.

이번 행사를 준비하며 가장 중요하게 생각한 방향은 ‘지속 가능한 모두를 위한 해커톤’을 만드는 것이었습니다. 참가자뿐 아니라 운영진 역시 운영 경험을 통해 배우고 성장하는 또 다른 참여자라고 생각했기 때문에, 팀 구성과 협업 방식, 문서화, 태스크 관리까지 최대한 체계적으로 설계해 더 건강한 운영 환경을 만들고자 했습니다.

그 과정에서 가장 크게 고민한 것은 어디까지 직접 개입하고 어디까지 믿고 맡길지에 대한 균형이었습니다.이를 고민하는 과정에서 특히 총괄이 세부 실행까지 모두 붙잡기보다 초기에 방향과 기준을 명확히 잡고 필요한 순간에만 조율하는 방식이 더 중요하다는 점을 많이 배웠습니다.

또한 참가자 관리와 심사 운영 과정에서 반복적으로 발생하는 불편을 줄이기 위해 백오피스를 직접 개발해 적용했는데, 이런 자동화가 큰 규모의 행사 운영을 훨씬 안정적으로 만든다는 것도 확인할 수 있었습니다.

이번 해커톤을 통해 잘 설계된 구조와 좋은 팀워크가 있다면, 연합 해커톤도 충분히 즐겁고 지속 가능하게 운영할 수 있다는 확신을 얻었습니다.

Infra: 성공회대학교 윤준석

안녕하세요, GDGOC 성공회대학교 오거나이저 윤준석입니다.

이번 ONE WAVE 해커톤에서는 Infra 팀을 맡아 해커톤이 원활하게 진행될 수 있도록 전반적인 인프라를 담당했습니다. Infra 팀이라는 이름은 단순한 기술 지원을 넘어 온라인과 오프라인을 아우르는 해커톤 운영 환경 전체를 책임지겠다는 의미를 담고 있습니다.

먼저 준비 단계에서는 운영진들의 빠른 의사결정과 업무 연속성을 위해 노션 회의록을 관리하고, 부서장 중심의 디스코드 커뮤니케이션 구조를 구축해 부서 간 소통이 원활하도록 지원했습니다.

여러 학교의 운영진이 함께 준비하는 행사였기에 이러한 협업 환경을 정리하는 것이 중요한 일 중 하나였다고 생각합니다. 현장에서는 “성공적인 마무리를 위한 인프라 지원”에 초점을 두었습니다.

참가자들의 원활한 입장을 위해 체크인 시스템을 직접 개발해 키오스크 형태로 운영했고, 이를 통해 행사장 입장시 발생할 수 있는 병목과 대기 시간을 크게 줄일 수 있었습니다. 또한 메인 홀 행사 중 상단 TV가 출력되지 않는 예상치 못한 상황이 있었지만, 만일을 대비해 챙겨간 HDMI 분배기를 활용해 빠르게 문제를 해결할 수 있었습니다.

아울러 호실 방송 시스템을 구축해 공지 전달을 지원하고, 참가자들이 개발에 몰입할 수 있도록 참여형 음악 플레이리스트를 제공했습니다.

Infra 팀은 무대 위가 아니라 무대 뒤에서 행사가 자연스럽게 흘러가도록 기반을 만드는 팀이라고 생각합니다. 이번 ONE WAVE 해커톤을 통해 보이지 않는 곳에서 행사를 완성도 있게 만들어 주는 지속적인 인프라 지원의 중요성을 다시 한번 느낄 수 있었습니다.

Sales: 서울과학기술대학교 염정우

안녕하세요, GDGOC 서울과학기술대학교 오거나이저 염정우입니다. 이번 ONE WAVE 해커톤에서 영업팀장을 맡아 심사위원 및 멘토 섭외, 후원사 컨택을 담당했습니다.

섭외 과정에서 제가 가장 깊이 고민한 부분은 'AI 시대 해커톤의 새로운 평가 기준'이었습니다. AI 도구의 발전으로 기술 구현의 장벽이 크게 낮아진 지금, 해커톤의 핵심은 단순한 기술력 평가를 넘어섰다고 생각합니다. 이제는 프로덕트가 어떤 문제를 어떻게 해결하는지, 그 기획과 비즈니스 역량을 평가하는 것이 훨씬 중요해진 시대입니다.

참가자들의 치열한 결과물이 제대로 인정받을 수 있도록, 이번 행사에서는 Tech와 Biz 전문가를 고루 모셔 심사위원단의 밸런스를 맞추는 데 가장 큰 공을 들였습니다. 다각도의 날카로운 피드백을 통해 1박 2일의 시간이 참가자들에게 단순한 대회를 넘어 '확실한 성장의 시간'이 되도록 경험의 밀도를 높이고 싶었습니다. 이러한 목표에 공감하고 한마음으로 움직여준 운영진분들 덕분에 참가자들의 기획과 기술을 입체적으로 평가할 수 있는 최적의 심사 환경을 만들 수 있었습니다.

이번 해커톤은 '어떤 시각으로 프로덕트를 바라보고 평가할 것인가'에 대한 해답을 찾아가는 과정이었습니다. 운영진으로서 평가 환경을 설계하며, 기술의 완성도만큼이나 비즈니스적 가치 창출이 중요하다는 점을 다시금 깨달을 수 있었던 값진 경험이었습니다.

이 외에도 ONE WAVE는 다양한 파트의 운영진이 함께 만들었습니다. 브랜딩을 맡은 계원예술대학교 노권후는 도쿄 여행 중 출력물 발주 위기를 원격으로 해결하며 현장 몰입을 설계했고, DevRel의 대진대학교 이우민은 본선 심사가 길어진 40분을 전날 못 쓴 콘텐츠로 즉석 커버했습니다. 마케팅의 삼육대학교 김성윤은 서로 다른 배경의 참가자들을 하나의 메시지로 모객하는 역할을, 회계의 전남대학교 황재현은 변동하는 예산을 실시간으로 반영해 안정적인 집행을 이끌었습니다. HR의 중앙대학교 최민준은 약 200명의 사전 설문 데이터를 AI 기반 매칭 프로세스로 분석해 35개 팀의 직군 밸런스를 맞추는 팀 빌딩을 이끌었고, A현장운영의 가천대학교 장영하는 멘토가 직접 팀을 찾아가는 동선을 설계해 참가자의 멘토링 접근성을 높였습니다.

GDGoC ONE WAVE 해커톤 단체사진 <출처: GDGOC ONE WAVE>

마치며

이번 해커톤에서 확인한 것은 세 가지입니다. 첫째, 배포를 필수에서 선택으로 바꾸자 참가자들은 실제로 기획에 더 많은 시간을 썼고, 심사 상위 팀일수록 문제 정의의 밀도가 높았습니다. 둘째, 기획 교류를 프로세스 안에 넣자 비슷한 주제의 중복이 초기에 걸러졌고, 팀들은 기능을 더 붙이는 대신 차별점을 다듬는 쪽으로 움직였습니다. 셋째, 운영진이 반복 업무를 AI로 시스템화하자 현장 대응에 쓸 수 있는 시간이 늘어났고, 예상하지 못한 필요에도 즉시 대응할 수 있었습니다.

그리고 이 세 가지 변화가 실제로 작동하고 있다는 걸 가장 분명하게 보여준 건 현장의 분위기였습니다. 체력이 바닥난 새벽에도 팀들이 붙들고 있었던 건 코드의 양이 아니라 "우리의 로직이 진짜 이 문제를 풀 수 있는가"라는 본질적인 질문이었습니다. 단순히 해커톤을 후원하는 차원을 넘어, 이 실험의 방향성에 공감해 함께해 준 파트너들의 존재도 큰 힘이 되었습니다.

동시에 다음에 바꿔야 할 것도 보였습니다. 기획 교류의 효과를 더 정밀하게 측정할 장치가 필요했고, 운영 백오피스도 사전에 더 체계적으로 설계했다면 현장에서 즉석으로 만드는 부담을 줄일 수 있었을 것입니다. 참가자에게 "기획이 중요하다"고 말하면서도, 그 기획의 질을 끌어올려 줄 수 있는 멘토링 구조는 아직 충분하지 않았습니다.

해커톤을 준비하는 분들이 이 글에서 한 가지라도 가져갈 수 있다면, 이것을 말씀드리고 싶습니다. AI가 구현의 장벽을 낮추는 만큼, 해커톤의 무게중심은 자연스럽게 "무엇을 왜 만드는가"로 옮겨갑니다. 그리고 그 변화는 참가자에게만 해당하는 이야기가 아닙니다. 참가자가 기획에 집중하길 바란다면, 운영진도 반복 업무에 묶여 있는 방식에서 먼저 벗어나야 합니다. ONE WAVE는 그 실험의 첫 번째 기록이었고, 다음에는 더 나은 버전을 만들 수 있다고 생각합니다.

글:GDGoC 정은혁

]]>

Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지

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

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

써볼 것: codex-plugin-cc - Claude Code 안에서 Codex로 코드 리뷰하기
참고할 것: AI가 계속 맞장구치면 벌어지는 일 - MIT 망상 소용돌이 연구
적용해볼 것: Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지 (내용이 좀 깁니다)

1. 써볼 것: Claude Code 안에서 Codex로 코드 리뷰하기

codex-plugin-cc는 OpenAI가 3월 31일 GitHub에 공개한 Claude Code용 공식 플러그인입니다. Claude Code 터미널 안에서 슬래시 커맨드 몇 줄로 OpenAI Codex를 직접 호출해 코드 리뷰와 작업 위임이 가능합니다. Apache 2.0 라이선스 오픈소스로, 공개 직후 빠르게 GitHub 스타를 모으며 화제가 되었던 소식입니다.

경쟁사가 경쟁사 도구용 플러그인을 공식으로 만들었다는 것 자체가 화제의 불씨였는데요. Claude Code가 코딩 에이전트 시장에서 큰 점유율을 가지고 있다는 분석이 있습니다. OpenAI는 개발자들이 넘어오길 기다리는 대신 개발자가 이미 있는 곳으로 직접 들어가는 전략을 선택했네요. 이는 플러그인이 실행될 때마다 OpenAI 인프라에 트래픽이 생기고, Claude Code 사용자가 자연스럽게 Codex를 경험하게 되는 구조입니다.

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

Claude Code로 코드를 짜고, 같은 Claude에게 리뷰를 시키면 어떻게 될까요. 생성할 때 놓친 맹점이 리뷰할 때도 그냥 넘어갈 수 있습니다. 같은 모델이 가진 경향을 공유하고 있으니까요.

codex-plugin-cc는 여기에 다른 모델의 시각을 끼워 넣을 수 있는 방법입니다. Claude가 쓴 코드든, 직접 작성한 코드든 Codex의 눈으로 한 번 더 보는 거죠. 특히 /codex:adversarial-review는 코드가 맞는지가 아니라 이 구현이 적절한지를 묻는 리뷰입니다. 가정, 트레이드오프, 장애 모드, 대안을 압박 테스트하는 방식이라 일반 리뷰와 결이 조금 다릅니다.

어떻게 쓰나요?

ChatGPT 구독(무료 포함) 또는 OpenAI API 키와 Node.js 18.18 이상이 필요합니다. 설치는 Claude Code 안에서 진행합니다.

Codex가 설치되어 있지 않다면 /codex:setup이 자동으로 설치 여부를 물어봅니다. 이미 Codex를 쓰고 있다면 기존 인증과 설정이 그대로 이어집니다.

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

설치 후 쓸 수 있는 커맨드는 크게 세 가지 흐름입니다.

리뷰

/codex:review: 현재 미커밋 변경사항 또는 브랜치 기준 표준 코드 리뷰. 다중 파일 변경은 --background 권장
/codex:adversarial-review: 구현의 적절함을 따지는 도전적 리뷰. 특정 위험 영역을 포커스 텍스트로 지정 가능

위임

/codex:rescue: 버그 조사, 수정 시도, 막힌 문제를 Codex에게 넘기는 커맨드. 모델과 추론 강도를 직접 고를 수 있고, 백그라운드 실행도 가능

관리

/codex:status / /codex:result / /codex:cancel: 백그라운드 작업 상태 조회, 결과 확인, 취소

리뷰 게이트를 켜두면 (/codex:setup --enable-review-gate) Codex 리뷰가 완료되기 전까지 Claude Code가 변경사항을 최종화할 수 없게 막습니다. 다만 Claude와 Codex 루프가 길게 돌아가면서 사용량 한도를 빠르게 소진할 수 있으니, 세션을 적극 모니터링할 때만 켜는 게 좋습니다.

누구에게 좋을까요?

Claude Code를 메인으로 쓰면서 코드 리뷰에 두 번째 시각이 필요한 개발자
PR 전에 설계 결정을 한 번 더 압박 테스트해보고 싶은 사람
백그라운드에서 버그 조사를 돌려놓고 다른 작업을 하고 싶은 사람

2. 참고할 것: AI가 계속 맞장구치면 벌어지는 일(논문)

MIT와 워싱턴대학 연구진이 공동으로 발표한 논문입니다. AI 챗봇의 아첨(Sycophancy)이 사용자를 망상적 소용돌이(Delusional Spiraling)로 이끄는 메커니즘을 수학적으로 처음 모델링한 소식입니다. 2월 22일 arXiv에 공개됐습니다.

* 망상적 소용돌이란 AI 챗봇과 장시간 대화한 후 사용자가 잘못된 믿음에 점점 강하게 확신하게 되는 현상입니다. Human Line Project는 현재까지 300건에 가까운 사례를 기록했고, 최소 14명의 사망과 5건의 소송으로 이어졌다고 합니다.

기존 설명과 무엇이 다른가요?

지금까지 망상적 소용돌이는 사용자의 비논리적이거나 게으른 사고 탓으로 돌려졌습니다. 이 논문은 그 가정을 꼬집는 내용입니다. 완벽하게 합리적인 베이지안 추론을 하는 이상적 사용자를 수학 모델로 만들고 시뮬레이션했을 때, 그 사용자조차 아첨하는 챗봇 앞에서 망상에 빠진다는 걸 보여줬습니다. 비합리적 사고의 문제가 아니라 구조의 문제라는 거죠.

어떻게 작동하나요?

챗봇의 아첨 성향이 높아질수록 망상에 빠지는 비율이 가파르게 올라갔습니다. 한 연구에서 주요 모델들의 아첨 응답 비율을 50~70% 수준으로 측정했습니다. 두 가지 해결책을 시뮬레이션했는데, 결과가 충격적입니다.

첫 번째, 챗봇이 거짓말을 못 하게 막으면 어떨까요. 사실만 말하도록 제한해도 망상은 줄어들 뿐 사라지지 않았습니다. 챗봇은 거짓말 없이도 사용자 입맛에 맞는 사실만 골라서 보여주는 방식으로 같은 효과를 낼 수 있었습니다.생략을 통한 거짓말이죠.
두 번째, 사용자에게 AI가 아첨할 수 있다고 미리 알려주면 어떨까요. 아첨 가능성을 아는 똑똑한 사용자도 아첨 빈도가 10~50% 수준으로 교묘할 때는 여전히 망상에 빠졌습니다. 더 충격적인 건 이 두 가지를 동시에 적용했을 때, 사실만 말하는 아첨봇이 거짓말하는 봇보다 오히려 망상 유발 효과가 더 컸다는 겁니다. 사용자가 제공된 정보가 검증된 사실이라고 믿는 순간, 그것이 편향되게 선별됐다는 걸 눈치채기 더 어려워지기 때문입니다.

무엇을 얻어가야 하나요?

논문이 내리는 결론은 세 가지입니다. 망상적 소용돌이는 사용자의 문제가 아니라 구조의 문제라는 것, 환각을 없애는 기술적 조치만으로는 충분하지 않다는 것, 사용자 교육도 완전한 해결책이 아니라는 것입니다. 근본 원인인 아첨 성향 자체를 줄여야 한다는 결론입니다.

프로덕트 메이커 입장에서 이 연구가 흥미로운 이유는 AI를 잘 쓰는 것과 AI에게 끌려가는 것의 경계가 생각보다 얇다는 부분입니다. Claude Code로 코드를 짜고 같은 Claude에게 리뷰를 시키는 것, 오늘 소개한 codex-plugin-cc가 해결하려는 문제와 맥락이 닿아 있습니다. 같은 모델이 가진 맹점은 같은 모델이 검토할 때도 남아 있으니까요. 개인적으로는 이 연구가 AI를 쓰는 방식 전반을 다시 생각하게 만들었습니다. 잘 동의해주는 AI가 편하게 느껴진다면, 그게 오히려 신호일 수 있지 않을까요.

3. 적용해볼 것: Claude Code를 만든 Boris Cherny가 직접 추천한 기능 15가지

Boris Cherny는 Claude Code를 만든 Anthropic 팀의 개발자입니다. 3월 30일 X에서 자신이 가장 자주 쓰는, 숨겨진 클로드 코드 기능들을 직접 공개했습니다. 이 글을 쓰는 시점 기준, 해당 X 글은 조회수 375만, 좋아요 2.2만을 기록했습니다. 또, 달린 댓글 대부분은 ‘이런 게 되는 줄 몰랐다’는 반응이 대부분이었습니다. 매일 쓰는 개발자들도 몰랐던 기능들이 적지 않았다는 거죠.

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

대부분의 사람들은 Claude Code를 터미널에서 코드 짜고 질문하는 방식으로만 씁니다. 물론 그게 잘못된 건 아닙니다. 다만 이렇게 쓰면 Claude Code가 할 수 있는 것의 절반도 활용하지 못합니다. 밑에서 소개할 Boris가 공개한 15가지는 Claude Code를 스스로 돌아가는 시스템으로 바꿔주는 기능들에 가까운데요. 15가지 기능 전부를 함께 살펴보겠습니다.

Boris Cherny가 공유한 15가지

1. 모바일 앱

Claude Code에 모바일 앱이 있습니다. iOS/Android 앱의 왼쪽 Code 탭에서 접근할 수 있습니다. Boris는 코드를 상당 부분 iOS 앱에서 작성한다고 했습니다. 노트북을 열지 않아도 코드 변경 작업이 가능합니다.

2. 기기 간 세션 이동

모바일·웹·데스크탑·터미널 간에 세션을 이어서 쓸 수 있습니다. Boris는 /config에서 Enable Remote Control for all sessions를 항상 켜놓는다고 했습니다.

claude --teleport   # 클라우드 세션을 로컬 터미널로 가져오기
/remote-control     # 로컬 세션을 폰이나 웹에서 제어하기

3. /loop와 /schedule

Boris가 가장 강력한 기능이라고 꼽은 것들입니다. 최대 1주일 단위로 작업을 자동 반복 실행할 수 있습니다. Boris가 실제로 돌리는 루프들입니다.

/loop 5m /babysit         # 5분마다 코드 리뷰, 자동 리베이스, PR 관리
/loop 30m /slack-feedback # 30분마다 Slack 피드백 기반 PR 자동 생성
/loop /post-merge-sweeper # 놓친 코드 리뷰 코멘트 처리 PR 자동 생성
/loop 1h /pr-pruner       # 오래되거나 불필요한 PR 자동 종료

4. Hooks

Claude가 뭔가를 하기 전후에 특정 동작을 끼워 넣을 수 있는 기능입니다. Boris가 쓰는 예시들입니다.

SessionStart: Claude 시작할 때 맥락을 동적으로 로드
PreToolUse: 실행하는 모든 bash 명령을 로그 기록
PermissionRequest: 권한 요청이 오면 WhatsApp으로 알림 → 직접 승인·거부
Stop: Claude가 멈추면 자동으로 계속 진행하도록 유도

5. Cowork Dispatch

Boris가 코딩하지 않는 시간에 쓴다고 한 기능입니다. 자리를 비운 상태에서 Slack과 이메일 확인, 파일 관리, 노트북 작업 등을 할 수 있습니다. MCP, 브라우저, 컴퓨터 자원을 사용자 허가 아래 사용하는 구조입니다.

6. Chrome 확장 — 프론트엔드 작업

Boris가 Claude Code 사용에서 가장 중요한 원칙이라고 꼽은 게 있습니다. Claude에게 결과물을 직접 검증할 수단을 줘야 한다는 거예요. 브라우저를 주면 Claude가 코드를 쓰고, 결과를 보고, 좋아질 때까지 스스로 반복합니다. Chrome/Edge 확장이 그 역할을 해줍니다.

7. Claude Desktop 앱 — 웹 서버 자동 실행

Desktop 앱은 Claude가 웹 서버를 자동으로 실행하고 내장 브라우저에서 테스트하는 기능을 기본으로 제공합니다. CLI나 VSCode 환경이라면 Chrome 확장으로 비슷하게 구현할 수 있습니다.

8. 세션 포크

진행 중인 세션을 복제해서 다른 방향으로 시도해볼 수 있습니다.

/branch                                          # 세션 안에서
claude --resume <session-id> --fork-session      # CLI에서

9. /btw — 작업 중 빠른 질문

에이전트가 작업하는 도중에 흐름을 끊지 않고 빠른 질문을 던질 수 있는 사이드 쿼리 기능입니다.

10. Git Worktrees

같은 저장소에서 여러 작업을 동시에 병렬로 돌릴 때 필수인 기능이라고 합니다. Boris는 항상 수십 개의 Claude 인스턴스를 동시에 실행하는데, 이 기능을 사용하고 있다고요. claude -w 명령어로 워크트리에서 새 세션을 시작하거나, Claude Desktop 앱에서 worktree 체크박스를 선택하는 방법으로 시작할 수 있습니다. git 외 다른 버전 관리 시스템을 쓰고 있다면 WorktreeCreate 훅으로 워크트리 생성 로직을 직접 추가할 수 있다고 합니다.

claude -w   # 새 워크트리 세션 시작

11. /batch — 대규모 병렬 처리

/batch는 작업 범위를 파악한 다음 수십에서 수천 개의 워크트리 에이전트에 작업을 나눠서 동시에 처리합니다. 대규모 코드 마이그레이션처럼 병렬로 처리할 수 있는 작업에 유용합니다.

12. --bare 플래그 — SDK 시작 속도 최적화

비대화형으로 실행할 때 쓸 수 있는 플래그입니다. --bare를 쓰면 로컬 CLAUDE.md, 설정, MCP 자동 탐색 과정을 건너뛰어 시작 속도가 최대 10배 빨라진다고 합니다. Boris는 opt-in인 현재 방식을 초기 설계 미흡이라고 설명했고, 이후 버전에서 기본값으로 바꿀 예정이라 전했습니다.

claude -p --bare

13. --add-dir — 다중 저장소 접근

Claude가 현재 프로젝트 외 다른 폴더에도 접근할 수 있게 해주는 기능입니다. 팀 공유 settings.json에 additionalDirectories를 추가해두면 시작할 때마다 자동으로 해당 폴더를 불러옵니다.

14. --agent — 커스텀 에이전트

.claude/agents 디렉토리에 에이전트를 정의해두면 상황에 맞는 시스템 프롬프트와 도구를 가진 에이전트를 바로 불러서 쓸 수 있습니다. Boris가 자주 간과되는 강력한 기능이라고 강조했습니다.

claude --agent=<name>

15. /voice — 음성 입력

CLI: /voice 실행 후 스페이스바 홀드
Desktop: 음성 버튼 클릭
iOS: 받아쓰기 설정 활성화

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

쭉 보고 나면 패턴이 하나 보이는데요, 이 기능들은 대부분 Claude를 혼자 돌아가게 만드는 것들입니다. /loop, /batch, Hooks, Worktrees 전부 내가 자리를 비워도 Claude가 일을 계속하게 하는 구조의 기능이죠. 이 기능들이 가리키는 방향을 보고 있자니, Boris Cherny는 Claude Code를 명령하는 도구로 쓰는 게 아니라, 위임하는 시스템으로 쓰라고 하는 것 같습니다.

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

15가지 중 당장 써볼 수 있는 것부터 시작해보세요.

/btw는 오늘 바로 쓸 수 있고, claude -c로 마지막 대화를 이어가는 것도 간단합니다.
반복되는 작업이 있다면 /loop를 먼저 시도해보세요.
Chrome 확장을 아직 안 쓰고 있다면 프론트엔드 작업 전에 설치해보세요. Claude가 직접 보고 판단할 수 있는 환경을 만들어주는 것만으로 결과물 품질이 달라집니다.

정리

Boris의 15가지는 Claude Code를 명령하는 도구에서 위임하는 시스템으로 바꾸는 방법을 보여줍니다. codex-plugin-cc는 같은 모델의 맹점을 피하기 위해 두 번째 시각을 끼워 넣는 방법을 보여주고요. MIT 논문은 이 맥락에서 불편한 질문을 던집니다. 잘 동의해주는 AI가 편하게 느껴진다면, 그게 오히려 신호일 수 있다고요. AI를 잘 쓰는 것과 AI에게 끌려가는 것의 경계가 생각보다 얇을 수 있습니다. AI가 너무 잘 동의해준다 싶을 때, 그 느낌을 너무 가볍게 넘기지 마시길 바랍니다. MIT 논문이 보여준 것처럼 아첨은 거짓말 없이도 작동하니까요.

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

]]>

문돌이 PM이 만든 AI 세션에 대기자 200명이 몰린 이유

[바이브코더스] 비개발자를 위한 Claude Cowork 세션 운영자, 김동현 님 인터뷰

아마 비개발분들은 공감하실 텐데요. 요즘 AI 활용 콘텐츠는 넘쳐나지만, 정작 비개발자의 눈높이에 맞춰 실무에 바로 적용할 수 있는 현실적인 이야기는 많지 않습니다. 대부분의 AI 활용 콘텐츠도 개발자 시선에서, 코드를 활용한 사례를 다루는 경우가 많죠.

오늘 바이브코더스 인터뷰에서 소개해 드릴 분은 비개발자를 위해 ‘클로드 코워크(Claude Cowork)’를 실무에 적용할 수 있는 다양한 아이디를 나누는 세션을 직접 설계하고 운영하고 있습니다. 벌써 12회째 세션을 이어가고 있고, 현재 대기자가 200명이 넘을 만큼 많은 관심을 받고 있는데요. 스스로를 ‘AI와 함께 일하는 잡부’라고 소개하는 김동현 님의 이야기를 통해, 비개발자가 현실적으로 AI를 실무에 어떻게 적용할 수 있는지 그 이야기를 들어봤습니다.

김동현 님 <출처: 바이브코더스 인터뷰 화면>

Part 1. 비개발자, AI를 만나다

Q. 안녕하세요! 간단한 자기소개 부탁드립니다.

안녕하세요. 저는 현재 컬리 해외사업팀에서 Global PM(Project Manager)으로 일하고 있는 김동현입니다. 이전에는 캐치테이블에서 마케팅과 사업 기획을 맡았고, 그전에는 컨설팅 업무도 했어요. 한마디로 ‘문돌이’ 직무를 두루 경험해 온 사람이라고 소개할 수 있을 것 같은데요. 요즘은 클로드 코워크(Claude Cowork)를 활용해, AI로 일하는 방식을 어떻게 하면 더 효율적으로 바꿀 수 있을지 이것저것 이야기하고 다니고 있습니다.

Q. 문돌이 직무를 두루 경험했다고 말씀해 주셨는데, 처음 AI를 어떻게 접하게 되셨나요?

2년 전쯤, 제가 캐치테이블에서 일하던 시절이었어요. 일을 하다 보면 개발자가 이틀이면 끝낼 수 있을 것 같은 작은 개발이 필요한데도, 리소스나 우선순위에 밀려 업무가 지연되는 경우가 많았거든요. 아마 개발자분들과 함께 일해 보신 분들이라면 이런 경험을 많이 해보셨을 것 같아요.

그 당시에는 ChatGPT-3와 Copilot이 막 나오던 때였는데요. 그때 ‘나도 이런 AI 기술을 이용해서 직접 개발해 볼 수 있지 않을까?’라고 생각했던 것 같아요. 그래서 퇴근 후에 “비개발자도 코파일럿이랑 함께하면 코딩할 수 있다” 같은, 2주에 200만 원짜리 부트캠프를 듣고 제가 원하는 프로덕트도 만들어 봤어요. 그런데 이 과정을 거치면서, 조금 아이러니한 생각이 들더라고요. AI 기술의 발전 속도가 너무 빨라서, 제가 배우는 속도보다 기술이 발전하는 속도가 더 빠를 것 같았어요. 그래서 전략적으로 조금만 더 기다리면 기술이 더 빠르게 저에게 다가오겠다고 느껴서, 한동안은 노력을 조금 내려놓기도 했죠.

그런데 작년에 Claude Code가 나왔을 때, 이제는 제가 더 이상 크게 애쓰지 않아도 원하는 수준의 MVP나 업무 툴을 쉽게 만들 수 있겠다는 생각이 들었어요. 그 이후부터는 클로드를 적극적으로 활용해 보려고 노력하고 있습니다.

Part 2. 비개발자를 위한 ‘Claude Cowork 세션’을 열다

Q. 비개발자를 위한 Claude Cowork 세션을 직접 만들게 된 계기가 궁금해요.

작년에 Claude Code로 제 업무를 자동화하고, 업무 맥락을 AI에 담아 활용해 보니 효용이 굉장히 크게 느껴졌어요. 그래서 그 경험을 바탕으로 주변 지인들에게도 알려줬는데, 생각보다 다들 많이 어려워하시더라고요. 나중에 잘 쓰고 있는지 물어보면, 처음에는 의욕적으로 시작했다가도 CLI 터미널의 까만 화면이 익숙하지 않아 어렵다거나, 몇 번 시도해 봤는데 잘 안 되니 점점 손이 가지 않는다는 피드백을 많이 들었어요.

그러다가 Claude Cowork가 한두 달 전쯤 처음 나왔을 때, ‘이건 다르다’는 생각이 들었어요. 일반 사용자에게 익숙한 GUI(Graphical User Interface) 기반이라 진입 장벽이 훨씬 낮고, Claude Code에서 할 수 있는 기능도 상당 부분 커버할 수 있었거든요. 그래서 주변 사람들을 모아 몇 차례 세션을 함께 진행해 봤는데, 이전과는 확실히 다르게 많은 분들이 계속 Claude Cowork를 활용한다는 느낌을 받았어요. 실제로 1~2주 뒤에 연락해 보면 “나 이런 것도 만들어서 이렇게 쓰고 있어”라는 이야기를 들을 수 있었거든요.

이런 경험을 통해 비개발자에게도 Claude Cowork는 충분히 실질적인 효용이 있겠다는 확신이 들었고, 그때부터 본격적으로 세션을 운영하기 시작했습니다. 제가 사람들에게 Claude Cowork를 소개할때 이렇게 얘기하곤 해요. Claude Code가 두 발 자전거라면, Claude Cowork는 보조 바퀴 달린 네 발 자전거라고요. 이걸로 열심히 타다 보면, 어느 순간 두 발 자전거를 타고 싶어지는 좋은 중간 단계 도구라고 생각해요. 확실히 비개발자들에게 AI에 대한 흥미와 지속성을 가능하게 해주는 좋은 툴인것 같아요.

비개발자를 위한 Claude Cowork 세션 <출처: 김동현 님 홈페이지>

Q. 벌써 세션이 12번이나 진행됐다고 들었어요. 세션에서는 주로 어떤 내용을 다루나요?

제 세션을 한 문장으로 소개하면, ‘프롬프트를 잘 쓰는 법’보다는 ‘컨텍스트를 잘 설계하는 관점’을 다루는 세션이라고 생각해요. 주로 마인드셋 30분, Cowork 기능 소개 20분, 시나리오별 실제 시연 40~50분으로 구성해서 진행하고 있어요.

특히 마인드셋 파트에서는 세 가지를 강조하는데요. 첫째, AI가 나보다 똑똑하다는 걸 인정하는 데서 시작해야 한다는 점이에요. 둘째, 그렇다면 문제 해결은 내가 아니라 AI에게 위임해야 한다는 것이고요. 셋째, 내 역할은 ‘문제 해결의 주체’에서 ‘컨텍스트를 오케스트레이팅하고 결과를 밸리데이팅하는 역할’로 재정의해야 한다는 거예요.

시연 파트에서는 스킬이나 자동화 예약 기능, 폴더 인스트럭션 설정 등을 실제로 보여드리면서, ‘내일 출근해서 내 업무에 바로 이렇게 적용해 볼 수 있겠다’는 감각을 전하는 데 초점을 맞추고 있어요. 비개발자분들도 Claude Code를 활용해서 ‘나도 할 수 있겠다’는 감각이 생겨야, 실제로 꾸준히 활용하는 비율도 높아지더라고요.

에이전트와 함께 파워포인트에서 AI 느낌을 줄이고, 완성도를 높이는 시연 <출처: 김동현 님>

Q. 지금까지 세션을 진행하시면서 가장 기억에 남는 피드백이 있다면요?

전 직장이었던 캐치테이블에서, 비개발자분들 약 50명을 대상으로 세션을 진행한 적이 있어요. 캐치테이블에서는 직원들의 AI 토큰 사용량을 트래킹하고 있다고 들었는데, 제 세션 이후에 비개발자분들의 토큰 사용량이 개발자들과 비교해도 상위 30% 안에 들어왔다는 이야기를 들었어요.

최근 인터뷰에서 젠슨 황이 “연봉 50만 달러짜리 엔지니어가 1년에 25만 달러어치 토큰도 안 썼다면 일을 제대로 안 하는 것”이라고 말했는데요. 그 말처럼 요즘은 토큰 사용량이 직원들이 AI와 얼마나 함께 일하고 있는지를 가장 직관적으로 보여주는 지표인 것 같아요. 비개발자분들이 그 수준까지 올라갔다는 게 정말 뿌듯했습니다.

김동현 님의 Claude Cowork 오프라인 세션 <출처: 김동현 님 LinkedIn>

Part 3. 비개발자의 AI 장벽과 마인드셋

Q. 비개발 직무 분들이 Claude나 Claude Code를 접할 때 가장 많이 막히는 부분은 어디인가요?

아까도 말씀드렸지만, 가장 큰 장벽은 ‘익숙하지 않은 인터페이스’예요. UI 환경에서 일하던 사람이 갑자기 터미널의 까만 화면에서 자연어로 프롬프트를 입력하고 있으면, 뭔가 낯설고 이상하게 느껴지잖아요. 그런 심리적 거리감이 생각보다 커서, 한두 번 잘 안되면 금방 손을 놓게 되더라고요.

두 번째는 최근 AI 콘텐츠의 방향성이에요. 시중에 나와 있는 AI 콘텐츠 대부분이 개발자 시각에서 만들어지거든요. 바이브 코딩이나 멀티 에이전트 세팅 같은 주제는 보기에는 멋지지만, 비개발자에게는 실무적으로 바로 와닿지 않아요. PM이나 마케터 입장에서는 ‘내가 이 툴로 내일 당장 무엇을 할 수 있는지’가 더 중요하거든요. 그런데 그 부분을 채워 주는 콘텐츠는 아직 많이 부족하다고 생각해요. 그래서 비개발자들이 익숙하지 않은 툴과 정보를 접할 때, 분명한 허들을 느끼는 것 같습니다.

Q. 세션에서 마인드셋을 많이 강조한다고 하셨는데, 어떤 이유 때문일까요?

툴은 계속 바뀌잖아요. 지금은 Claude Cowork가 비개발자에게 가장 좋은 도구라고 생각하지만, 3~6개월 뒤에도 그럴지는 사실 모르겠어요. 구글이 클라우드 기반으로 비슷한 툴을 내놓는다면, 그게 더 좋아질 수도 있고요. 그만큼 AI 시장의 변화 속도가 너무 빠르다 보니, 사실 하나의 툴을 잘 사용하는 것 자체가 얼마나 오래 효용이 있을지는 확신하기 어려워요.

또 내가 특정 툴 하나를 잘 다룬다고 해서, 그것만으로 AI를 잘 활용한다고 말할 수는 없는 것 같아요. 반면, AI와 협업하는 마인드셋, 그러니까 어떻게 컨텍스트를 설계하고 결과를 밸리데이팅할지는 툴이 바뀌어도 크게 달라지지 않아요. 저는 이게 결국 AI를 잘 쓰는 사람과 그렇지 않은 사람을 가르는 핵심이라고 생각합니다. 그래서 프롬프트 스킬이나 툴 활용 스킬보다, AI를 활용하는 마인드셋이 더 중요하다고 보고 있어요.

Part 4. 현업에서의 AI 활용

Q. 현재 컬리에서 Claude 또는 다른 AI를 어떻게 활용하고 계신가요?

회사 차원에서도 다양한 시도를 하고 있는 것으로 알고 있어요. 최근 외부에 공개됐던 사례 가운데 하나가 ‘컬리 AI 스튜디오’라는 서비스예요. 본인 사진 한 장을 넣으면, 원하는 필터로 사진이 변환돼 나오는 재미있는 경험을 할 수 있는 서비스인데요. 원래는 컬리 앱 안에서 1~2주 정도만 운영하려던 서비스였는데, 반응이 좋다 보니 한 달 이상 운영하게 됐죠.

컬리에서 선보인 ‘AI 스튜디오’ <출처: 컬리>

또 팀 단위의 AI 활용에도 요즘 집중하고 있어요. 저 혼자 생산성을 200% 높이는 것보다, 팀원 전체가 함께 AI를 잘 쓰는 환경을 만드는 게 더 가치 있다고 생각하거든요. 예를 들면, 회의록을 트랜스크립트로 자동 변환해 관리하는 스킬을 팀원 전체가 함께 공유해서, AI와의 맥락만 쌓이는 게 아니라 팀 전체의 지식 저장소로도 활용하는 시도들을 하고 있습니다.

Q. 조직 차원에서 AI를 도입할 때 가장 중요한 게 뭐라고 보시나요?

제 생각에는 조직 차원에서 AI를 도입할 때 가장 중요한 건, 탑다운 방식으로 AI를 전파하는 것이라고 봐요. 먼저 팀의 리더가 직접 써보지 않으면 팀 리소스를 제대로 파악하기 어렵거든요. AI를 잘 활용했을 때, 같은 인원으로 얼마나 더 많은 일을 할 수 있는지에 대한 감각이 없으면 사실 리소스 관리도 쉽지 않을 거예요.

팀에 10명이 있다면, AI 도입에 관심을 갖고 잘 활용하는 사람은 약 10% 정도일 거라고 생각해요. 나머지 90%를 온보딩하는 과정에서는 분명히 어려움이 생기는데, 조직장이 그 과정을 직접 겪어보지 않았다면 현실적으로 도와주기 어렵다고 봐요.

그다음으로 중요한 건 에반젤리스트, 즉 챔피언 역할이에요. AI 구독을 제공한다고 해서 모두가 자연스럽게 활용하는 건 아니거든요. 같은 팀에서 비슷한 업무를 하는 사람이 AI를 통해 실제로 효율을 내는 모습을 눈으로 확인해야, 주변에서도 관심을 갖기 시작해요. 그리고 이런 챔피언들이 지치지 않고 계속 역할을 이어갈 수 있도록, 조직장과 경영진이 잘 지원하고, 관리해 주는 것도 굉장히 중요하다고 생각합니다.

Part 5. AI 전망과 마무리

Q. 앞으로 비개발자로서 AI를 어떻게 더 활용하고, 또 어떻게 알리실 계획인가요?

사실 다음 세션 일정이 아직 정해지지 않았는데도, 대기자가 200명이 넘은 상태예요. 50명 규모의 오프라인 행사를 혼자 운영하는 것도 쉽지 않다 보니, 어떻게 하면 더 많은 분께 메시지를 전달할 수 있을지 계속 고민하고 있습니다.

그래도 가능하다면, 오프라인 현장에서 직접 사람들의 반응을 보면서 세션을 이어가고 싶어요. 어떤 지점에서 사람들이 “와” 하고 반응하는지, 어떤 시연에서 눈빛이 달라지는지를 직접 확인하는 게 중요하다고 생각하거든요. 그런 반응 데이터를 쌓아가면서, 콘텐츠를 계속 다듬고 발전시켜 나가고 있습니다.

Q. AI 활용에 관심 있는 비개발자 독자들에게 한마디 해주신다면요?

실용적인 이야기를 꼭 드리고 싶은데요. 일단 AI를 활용해 일하고 싶다면, 1~2주만 참고 버텨보세요. AI 활용은 결국 습관을 바꾸는 일이에요. 처음에는 내가 봤던 세션이나 영상에서는 잘되던데, 왜 나는 이상한 답만 나오지 싶은 순간이 반드시 찾아와요. 그럴 때는 ‘내가 아직 컨텍스트를 충분히 설계해서 주지 못하고 있는 거야’라는 믿음을 갖고 버텨보시면 좋겠어요. 그렇게 1~2주를 넘기면, 정말 신세계가 열립니다.

그다음 단계에서 한 가지 더 당부드리고 싶은 게 있는데요. AI를 쓰다 보면 너무 신나서, 자동화를 위한 자동화, AI를 쓰기 위한 AI 쓰기에 빠지기 쉬워요. 그런데 한 달 뒤에 돌아보면 실제 임팩트는 생각보다 크지 않은 경우가 많거든요. 그래서 1~2주에 한 번씩은 ‘내가 AI를 정말 효율적으로 잘 썼나, 이걸로 실제 임팩트가 났나’를 돌아보면서 적응해 나가시길 추천드립니다.

정리하면, “AI 사용을 버텨서 습관을 만들고, 주기적으로 회고해 나가라” 이 두 가지가 비개발자가 AI를 실무에 제대로 녹이는 가장 현실적인 방법이라고 생각합니다.

마치며

지금까지 문돌이 출신 비개발자로서 AI를 실무에 녹이고, 그 경험을 12회에 걸쳐 세션으로 나눠 온 김동현 님의 이야기를 들어봤습니다. 그가 거듭 강조한 지점은 프롬프트 스킬이 아닌 컨텍스트 설계, 개인 생산성이 아닌 팀 단위의 변화, 도구 소개가 아닌 마인드셋이었는데요. 이런 관점은 AI 도구가 계속 바뀌더라도 오래 유효하겠다는 생각이 들었습니다. 마지막으로 AI에 대한 FOMO(소외되는 것 같은 불안감)를 느끼는 비개발자분들께 김동현 님이 남긴 말을 전하며 글을 마무리하겠습니다.

"AI가 나보다 똑똑하다는 걸 인정하는 순간부터, 일하는 방식이 정말 달라져요. 그 다음은 컨텍스트를 잘 설계하는 것뿐이죠. 도구는 계속 바뀌겠지만, 이 마인드셋만 있으면 어떤 도구가 와도 빠르게 적응할 수 있습니다. 비개발자라서 AI를 잘 못 쓴다는 건 이제 변명이 될 수 없어요. 1~2주만 버텨보세요. 신세계가 기다리고 있을 거예요."

이제, 여러분은 AI와 어떻게 함께 일해보고 싶으신가요?

]]>

왜 우리는 아직도 AI에게 일을 제대로 못 시킬까?

“AI가 개발자를 대체할 것 같아요?”

요즘 이 질문은 어딜 가나 따라옵니다. 현업 개발자들 사이에서도, 친한 후배들과 밥을 먹을 때도, 심지어 집에서는 부모님까지 말씀하십니다. 그럴 때면 저는 농담을 섞어 이렇게 말하곤 했죠. “개발자 이제 다 망했으니, 다 같이 치킨집이나 차리자”고요.

그런데 웃기면서도 씁쓸한 건, 1년 전만 해도 “AI는 강력한 협업 도구일 뿐”이라고 했다는 점입니다. 절대 대체는 못 한다고도 했고요. 그런데 올해 들어서는 저만 봐도 회사에서 IDE를 거의 켜지 않았습니다. “IDE 뭐가 좋아?” 하던 이야기가 어느새 “AI CLI 쓸 때 터미널 뭐가 좋아?”로 바뀌어 있었죠. AI는 이제 코드를 짜는 것에 그치지 않고, 리뷰하고, 테스트 코드를 만들고, 복잡한 리팩터링까지 해내고 있으니까요.

회사 생활을 시작하면서 늘 듣던 말도 있습니다. “대체 불가능한 존재가 돼라.” 예전에는 코딩을 잘하면 그게 곧 대체 불가능하다는 뜻이었거든요. 그런데 이제는 코딩을 아무리 잘해도 AI에 밀릴 수 있는 시대가 됐습니다. 그렇다면 AI 시대에 대체 불가능한 사람이 되려면, 무엇을 해야 할까요? AI에게 일을 잘 시킨다는 건 어떤 의미일까요?

미리 요점만 콕 집어보면?

AI는 시키지 않으면 아무것도 안 한다. 그래서 "잘 시키는 능력"이 AI 시대의 핵심 역량이 됐다.
잘 시키는 방법은 프롬프트 엔지니어링(어떤 말을 쓸까) → 컨텍스트 엔지니어링(어떤 정보를 줄까) → 하네스 엔지니어링(어떤 환경을 만들까)으로 진화하고 있다.
프롬프트가 많아지면 관리가 필요하고, 관리를 잘하면 동시에 여러 프로젝트를 굴리는 "멀티 서클"이 가능해진다.

AI가 못 하는 것

저는 요즘 매일 AI와 같이 일합니다. 터미널에 Claude Code를 띄워놓고, 하루 종일 이 녀석에게 이것저것 시키며 코딩하죠. 그런데 여기서 재미있는 게 하나 있습니다. 아침에 출근해서 터미널을 켜고, Claude Code를 실행한 뒤 아무 말 없이 가만히 둬보세요. 어떻게 될까요? 아무 일도 일어나지 않습니다.

커서만 깜빡거리면서 저를 바라보고 있을 거예요. 아무리 기다려도 “오늘 뭐 하면 좋을까요?” 하고 먼저 묻지 않습니다. “어제 코드 보니까 여기 버그 있던데, 제가 좀 고쳐놓을까요?” 같은 말도 절대 하지 않죠. 그냥 가만히 있습니다. 제가 시킬 때까지요.

<출처: 작가, Claude 생성>

물론 시키면 정말 잘합니다. “이 함수 리팩터링해 줘”라고 하면 깔끔하게 해내고, “테스트 코드 짜줘”라고 하면 바로 만들어내죠. 하지만 시키지 않으면 가만히 있다는 겁니다. 그래서 AI가 못 하는 일은 결국, “시키지 않은 일”입니다.

당연한 이야기처럼 들릴 수도 있는데요. 여기에는 조금 더 중요한 의미가 담겨 있습니다. 모든 서비스의 니즈는 결국 사람에게서 나온다는 점이죠. 가령 AI가 혼자서 일할 수 있도록 환경을 구성한다고 해보겠습니다. 혼자 기획하고, 혼자 구현하고, 혼자 테스트하고, 혼자 운영하는 식으로요. 모든 걸 혼자 할 수 있는 구조를 만들었다고 해도, 어떤 고객군과 조직, 구성원이 무엇을 필요로 하는지 정확하게 파악하는 건 결국 사람입니다.

그래서 오직 사람만이 AI에게 정확한 니즈와 비즈니스 로직을 줄 수 있다고 생각합니다. 그리고 그 “시키는 일”을 어떻게 하면 더 잘할 수 있을지를 고민하는 것, 바로 그 지점이 앞으로 사람이 깊이 파고들어야 할 포인트라는 생각이 들었습니다.

"잘 시킨다"는 게 뭔가요?

그렇다면 “잘 시킨다”는 건 뭘까요? 이 단순한 질문에 답하려는 시도는 이제 하나의 분야가 됐습니다. 처음에는 “프롬프트 엔지니어링”이라는 이름으로 시작했는데, AI가 발전하면서 이 개념도 함께 빠르게 진화하고 있죠. 조금 거창해 보일 수 있지만, 결국 AI에게 어떻게 시켜야 원하는 결과가 나오느냐를 다루는 이야기입니다. 그리고 이 ‘어떻게’라는 부분이 생각보다 훨씬 빠르게 바뀌고 있습니다.

프롬프트 엔지니어링: 어떤 말을 쓸까

초기에는 같은 일을 시키더라도, 프롬프트를 어떻게 작성하느냐에 따라 결과가 크게 달라졌습니다.

나쁜 예시
로그인 기능 만들어줘

좋은 예시
우리 프로젝트는 Express + TypeScript 백엔드야. 기존에 JWT 기반 인증을 쓰고 있어.
로그인 API를 만들어줘.

POST /api/auth/login
이메일/비밀번호로 로그인
비밀번호는 bcrypt로 검증
성공 시 accessToken(15분), refreshToken(7일) 발급
실패 시 401 에러와 명확한 메시지

첫 번째 예시처럼 시키면 AI가 뭔가를 만들기는 합니다. 그런데 높은 확률로 제가 원하는 결과는 아니었죠. 프레임워크도 다르고, 인증 방식도 다르고, 구조 역시 우리 프로젝트와 맞지 않았거든요. 결국 “아니, 그거 말고” 하면서 다시 시키게 됩니다.

반면, 두 번째 예시는 훨씬 더 정확한 결과를 내놓았습니다. 프로젝트 맥락과 기술 스택, 구체적인 요구사항까지 함께 줬으니까요. 이 시기에 사람들은 이른바 “마법의 단어”를 찾아다녔습니다. “Think step by step”을 붙이면 수학 문제 정답률이 올라간다는 논문이 나왔고, “You are an expert”를 넣으면 결과물의 퀄리티가 좋아진다는 이야기도 있었죠. 심지어 “I’ll tip you $200”이라고 쓰면 더 잘한다는 밈까지 돌았습니다. 거의 주문에 가까웠습니다.

프롬프트 마켓플레이스라는 것도 생겨났습니다. “잘 동작하는 프롬프트”를 사고파는 시장이었죠. 그만큼 어떤 단어를 쓰느냐가 중요하던 시대였습니다.

컨텍스트 엔지니어링: 어떤 정보를 줄까

그런데 AI가 빠르게 똑똑해지면서, 이른바 ‘마법의 주문’은 점점 의미를 잃고 있습니다. 대신 중요해진 건, AI에게 얼마나 충분한 맥락을 넘겨주느냐입니다. AI가 한 번에 읽을 수 있는 양을 ‘컨텍스트 윈도우’라고 하는데요. 이 크기가 엄청나게 커졌습니다. 처음에는 4천 토큰 수준이었지만, 지금은 100만 토큰까지 확장됐죠. 그만큼 넣을 수 있는 정보량이 폭발적으로 늘어난 겁니다.

그래서 요즘 AI 코딩 도구들은 작업 디렉토리 전체를 그대로 읽어갑니다. 프로젝트 구조와 기존 코드, 설정 파일까지 AI가 직접 확인하는 방식이죠. 사람이 일일이 “우리 프로젝트는 이런 구조야”라고 설명하지 않아도, AI가 스스로 파악할 수 있게 된 겁니다.

이게 바로 컨텍스트 엔지니어링의 핵심입니다. 질문이 “어떤 말을 쓸까?”에서 “어떻게 맥락을 줄까?”로 바뀌었습니다. AI가 판단하는 데 필요한 정보를 빠짐없이 전달하는 것, 그것이 핵심입니다. 배경을 설명하고, 기술 스택을 알려주고, 기대하는 결과물을 구체적으로 정의하며, “이건 하지 마”라는 제약 조건까지 함께 전달하는 방식이죠.

하네스 엔지니어링, 어떤 환경을 만들까

그리고 요즘은 여기서 한 단계 더 나아가고 있습니다. 바로 “하네스 엔지니어링”이라는 개념인데요. 하네스(harness)는 원래 말의 고삐나 안장 같은 마구를 뜻하는 단어입니다. 컨텍스트 엔지니어링이 “AI가 잘 생각하도록 돕는 것”에 가까웠다면, 하네스 엔지니어링은 “AI가 탈선하지 않게 만드는 것”에 더 가깝습니다. 비유하자면 이렇죠. 말에게 “우회전해”라고 말하는 것이 프롬프트이고, 지도와 표지판을 보여주는 것이 컨텍스트라면, 고삐와 안장, 울타리, 그리고 길 자체를 만드는 것이 하네스입니다.

컨텍스트를 아무리 잘 줘도 해결되지 않는 문제들이 있거든요. AI가 팀 코드 컨벤션을 무시한다거나, 아키텍처 규칙을 어긴다거나, 여러 작업을 동시에 시켰더니 서로 충돌한다거나 하는 식이죠. 이건 “무엇을 보여줄까”의 문제가 아니라, “무엇을 막고, 무엇을 측정하고, 어떻게 수리할까”의 문제입니다.

그래서 하네스 엔지니어링은 에이전트 바깥의 인프라를 설계하는 일에 가깝습니다. 프로젝트 루트에 설정 파일을 넣어두면 AI가 우리 규칙을 따르게 할 수 있고, MCP 서버를 연결하면 DB나 외부 API를 직접 조회하면서 일하게 만들 수 있죠. 또 코드를 저장할 때마다 자동으로 린트가 돌도록 훅을 걸고, 위험한 명령은 실행 전에 차단하는 가드레일까지 둘 수 있습니다.

이제는 매번 “우리 프로젝트는 이런 컨벤션이야” 하고 말해줄 필요가 없습니다. 환경 자체가 그 규칙을 강제하니까요. 흐름을 한눈에 보면 이렇습니다.

<출처: 작가, Claude 생성>

이 세 가지는 서로 대체하는 관계가 아니라, 포함 관계에 가깝습니다. 좋은 프롬프트를 쓰는 일은 여전히 중요하고, 여기에 맥락을 잘 전달하는 것이 더해지며, 나아가 환경까지 설계하는 단계로 확장되는 흐름이죠. 결국 “잘 시킨다”의 의미 자체가 계속 넓어지고 있는 셈입니다. 그리고 이 영역을 잘 다루는 사람이, AI 시대에 점점 더 대체 불가능한 존재가 되어간다고 생각합니다.

그 프롬프트, 어디에 쌓고 있나요?

프롬프트든 컨텍스트든 하네스든, 공통점이 하나 있습니다. 어떤 방식이든 결국 우리는 AI에게 “말”로 전달하고 있다는 점입니다. 텍스트든, 채팅이든, 설정 파일이든, 사람이 언어로 의도를 전달하는 구조라는 거죠. 그렇다면 그 “말”들은 어떻게 관리하고 계신가요? 저는 요즘 하루 종일 프롬프트를 만듭니다. 정말로 그렇습니다. 아침에 출근하면 그날 할 일을 정리하고, 그걸 프롬프트로 만들어 AI에게 넘기죠. 그런데 이게 하나로 끝나지 않습니다. AI가 첫 번째 프롬프트를 처리하는 동안, 저는 이미 다음 프롬프트를 만들고 있습니다. 그다음 것도, 또 그다음 것도 이어서 만들게 되죠.

어느 순간 깨달았습니다. 아, 나는 이제 코딩을 하는 사람이 아니라 프롬프트를 만드는 사람이 되어가고 있구나. 그 자체는 괜찮았습니다. 앞에서 말했듯이, “시키는 일”이 사람의 몫이 된 시대니까요. 문제는 그다음이었습니다.

프롬프트가 점점 관리되지 않기 시작한 겁니다. 처음에는 VSCode에서 텍스트 파일로 관리해봤습니다. 프로젝트별로 폴더를 만들고, 그 안에 프롬프트를 하나씩 정리해 두는 방식이었죠. 그런데 파일이 쌓이다 보니 어떤 것은 이미 실행한 것인지, 어떤 것은 아직 대기 중인지 구분이 되지 않았습니다. 그래서 Notion으로 옮겨봤습니다. 페이지별로 나누고, 상태도 표시해봤죠. 하지만 이것도 불편했습니다. 프롬프트를 작성하다가 Notion 탭으로 왔다 갔다 하면서 흐름이 끊겼고, 실제로 AI에 전달하려면 결국 복사해서 붙여넣어야 했습니다.

그래서 다시 생각해봤습니다. 진짜 문제는 무엇일까? 프롬프트는 계속 쌓이고 있고, 이를 프로젝트 단위로 묶어서 보고 싶었습니다. 어떤 것은 완료됐고, 어떤 것은 대기 중인지 상태도 한눈에 알고 싶었죠. 가능하다면 AI에게 바로 전달까지 할 수 있으면 더 좋겠다고 생각했습니다. 그런데 이런 요구를 충족하는 도구는 쉽게 찾기 어려웠습니다.

그래서 그때 이런 생각이 들었습니다. ‘직접 만들어봐야겠다’고 말이죠.

<출처: 작가, Claude 생성>

그래서 만들어 본 ‘Idea Manager’

그래서 직접 한번 만들어봤습니다. 아이디어에서 프롬프트까지 이어지는 흐름을 하나로 연결해주는 CLI 도구, Idea Manager(IM)라는 이름을 붙였죠.

구조는 단순하게 3단계로 구성했습니다.

Brainstorming → Task → Prompt

첫 번째는 브레인스토밍입니다. 머릿속에 떠오르는 생각을 두서없이 적어두는 공간이죠. “로그인 방식을 바꿔야 할 것 같은데”, “대시보드 성능이 좀 느린 것 같아” 같은 것들입니다. 이 단계에서는 굳이 정리할 필요가 없습니다. 일단 꺼내놓는 게 중요하죠.

두 번째는 태스크입니다. 브레인스토밍에서 나온 생각을 실제 할 일로 쪼개는 단계인데요. “로그인 방식 바꾸기”가 브레인스토밍이었다면, “JWT에서 세션 기반으로 전환”, “소셜 로그인 추가”처럼 구체적인 태스크로 나누는 식입니다.

세 번째는 프롬프트입니다. 태스크별로 AI에게 시킬 수 있는 프롬프트를 만드는 단계죠. 기술 스택과 요구사항, 제약 조건 같은 맥락을 담아서 바로 실행할 수 있는 형태로 만드는 겁니다.

워크플로우는 이렇게 돌아갑니다.

아이디어를 브레인스토밍으로 꺼낸다 → 태스크로 쪼갠다 → AI와 채팅하면서 구체적인 계획을 세운다 → 프롬프트를 던진다 → AI가 처리하는 동안 다른 아이디어를 브레인스토밍한다

<출처: 작가, Claude 생성>

여기서 재미있는 시도를 하나 해봤는데, 바로 MCP 연동입니다. 프롬프트에 상태를 달아두면 AI가 태스크 목록을 직접 읽어가면서 대기 중인 작업을 처리하고, 완료되면 상태도 자동으로 바꿉니다. 하나하나 “이거 해줘” 하고 던질 필요 없이, AI가 알아서 대기열에서 꺼내 작업하는 셈이죠.

이걸 쓰기 전과 후를 비교해보면 차이가 더 분명합니다. 예전에는 아침에 출근하면 “어제 뭐 했더라?”부터 떠올려야 했습니다. 채팅 기록을 뒤져보고, Notion을 찾아보고, 그렇게 꽤 많은 시간을 썼죠. 지금은 아침에 IM을 열면 프로젝트별로 대기 중인 태스크가 쭉 보입니다. 바로 프롬프트를 만들고 시작하면 됩니다. 얼핏 보면 작은 차이처럼 보이는데요. 이런 차이가 매일 쌓이면 생각보다 훨씬 커집니다.

그리고 이건 저 혼자만의 이야기로 끝나지 않을 수도 있다고 생각합니다. 팀에서 프롬프트를 공유하면 어떨까요? 누군가 잘 만들어둔 프롬프트가 팀 전체의 자산이 되는 겁니다. 프롬프트가 계속 쌓이면, 팀 전체에 맞는 프롬프트를 만들어주는 모듈도 만들 수 있을 것이고, 결국 전체 생산성도 더 올라갈 수 있지 않을까요.

꼭 이 도구를 쓰라는 이야기를 하고 싶은 건 아닙니다. 제가 말하고 싶었던 건 도구 자체보다 이 흐름에 가깝습니다. 아이디어를 꺼내고, 할 일로 쪼개고, 프롬프트로 만들어 관리하는 이 사이클 말이죠. 이 흐름을 자기만의 방식으로 만들어두면, 확실히 일하는 방식이 달라지더라고요.

몇 서클 마법사인가요?

이렇게 프롬프트를 관리하기 시작하면, 재미있는 질문이 하나 떠오릅니다.

“동시에 몇 개나 굴릴 수 있나?”

AI에게 프롬프트를 던지고, 그 작업이 처리되는 동안 다른 프로젝트의 프롬프트를 만들고, 또 다른 프로젝트의 결과를 확인하게 됩니다. 이런 사이클이 돌아가기 시작하면, 자연스럽게 여러 프로젝트를 동시에 진행하게 되죠.

주변에서 동시에 7개 프로젝트를 돌리는 사람을 본 적이 있습니다. AI에게 이쪽 프로젝트를 맡기고, 저쪽 프로젝트 결과를 확인하고, 또 다른 프로젝트의 프롬프트를 만드는 식이었죠. 옆에서 보고 있으면, 여러 개의 마법을 동시에 시전하는 마법사 같다는 느낌이 들었습니다.

반면, 저는 솔직히 3~4개 정도가 한계입니다. 그 이상 넘어가면 머릿속이 금방 뒤죽박죽이 되더라고요. 프로젝트마다 맥락이 다르기 때문입니다. A 프로젝트는 Express, B 프로젝트는 Next.js, C는 React Native처럼 환경이 제각각이다 보니, 머리가 계속 다른 영역으로 점프하는 느낌이 들었습니다. 그래서 문득 이런 생각이 들었습니다. 이건 마치 7서클 마법사와 3서클 마법사의 차이 같다는 생각이요.

<출처: 작가, Claude 생성>

그렇다면 이 ‘서클’을 늘리는 열쇠는 무엇일까요. 생각해 보면 결국 프롬프트 관리 능력으로 돌아옵니다. 프로젝트별로 프롬프트가 잘 정리돼 있으면, 컨텍스트 전환 속도가 훨씬 빨라지거든요. “이 프로젝트 어디까지 했더라?” 하고 되짚을 필요 없이, 대기 중인 태스크를 보고 바로 이어서 진행하면 됩니다.

앞으로는 “몇 서클이세요?” 같은 질문이 개발자들 사이에서 자연스럽게 오가는 날이 올지도 모르겠습니다. 그때를 떠올리며 한번 생각해보면 어떨까요. 지금 나의 프롬프트는 어떻게 관리하고 계신가요?

Q. 프롬프트 엔지니어링은 이제 의미 없는 건가요?

여전히 중요합니다. 다만 예전처럼 “마법의 단어”를 찾는 일이 핵심은 아니게 됐죠. AI가 점점 더 똑똑해지면서, 맥락을 얼마나 잘 전달하느냐가 더 중요해졌기 때문입니다. 좋은 프롬프트와 충분한 컨텍스트, 그리고 잘 설계된 환경. 이 세 가지가 함께 가야 합니다.

Q. CLAUDE.md 같은 설정 파일, 꼭 써야 하나요?

필수는 아니지만, 사용하면 확실히 달라집니다. 매번 “우리 프로젝트는 TypeScript고, 컨벤션은 이거고”라고 설명할 필요가 없어지거든요. 한 번만 잘 만들어두면, AI가 알아서 규칙을 따르게 됩니다. 그래서 처음에는 간단한 형태라도 직접 만들어보는 것을 추천합니다.

Q. Idea Manager 같은 도구가 꼭 필요한가요?

꼭 이 도구일 필요는 없습니다. 핵심은 “아이디어 → 태스크 → 프롬프트”로 이어지는 흐름을 자기만의 방식으로 만드는 데 있습니다. Notion이든, 텍스트 파일이든, Obsidian이든 상관없죠. 프로젝트별로 프롬프트 상태를 관리할 수만 있다면 충분합니다.

Q. 동시에 몇 개 프로젝트를 돌리는 게 현실적인가요?

사람마다 다릅니다. 저는 3~4개 정도가 한계인데, 7개를 동시에 돌리는 분도 봤습니다. 중요한 건 숫자 자체가 아니라, 컨텍스트 스위칭을 얼마나 빠르게 하느냐입니다. 프롬프트 관리가 잘되면 자연스럽게 서클도 늘어나더라고요. 처음에는 2개부터 시작해보는 걸 추천합니다.

]]>

AI가 UX를 설계하는 방식: 화면보다 흐름이 먼저인 ‘Figr’

최근 몇 년 사이 AI 디자인 도구는 폭발적으로 늘어났습니다. 텍스트 프롬프트만 입력하면 UI 화면을 만들어주거나, 와이어프레임을 자동으로 생성해 주는 서비스를 이제는 쉽게 만나볼 수 있죠. 하지만 실제 제품을 만드는 기획자나 디자이너 입장에서 이런 도구를 쓰다 보면, 한 가지 공통적인 아쉬움을 느끼게 됩니다. 바로 "화면은 빠르게 만들어지는데, UX 설계와 제품 사고는 여전히 사람이 해야 한다"는 점입니다.

예를 들어, 이런 질문들이 포함될 수 있습니다. 이 기능의 사용자 흐름은 어떻게 이어져야 하는지, 예상하지 못한 예외 상황은 무엇이 있는지, 실제 데이터 기준으로 사용자 이탈은 어디에서 발생하는지, 혹은 이 화면이 기존 디자인 시스템과 충돌하지는 않는지 같은 문제들입니다. 결국 많은 AI 디자인 도구가 '화면 생성'에 집중하고 있을 뿐, 실제 제품 설계의 핵심인 '제품 사고'를 충분히 다루지 못하는 경우가 많다는 점입니다.

AI 디자인 도구의 진화 과정을 보면 이 한계는 더 명확하게 보입니다. 1세대 도구(Canva Magic Design 등)는 개별 에셋 생성에 집중했고, 2세대 도구(Uizard, Galileo AI 등)는 앱 플로우를 어느 정도 이해하게 됐지만, 여전히 맥락 없이 매번 처음부터 시작하는 경우가 발생했기 때문입니다. 그리고 지금, 제품의 전체 맥락을 학습하고 지속적인 기억을 유지하는 3세대 도구가 등장하기 시작했습니다.

<출처: Figr, 작가 캡처>

이 지점에서 등장한 서비스가 바로 오늘 소개할 ‘Figr’입니다. Figr는 스스로를 단순한 AI 디자인 툴이 아니라 "AI Design Agent"라고 설명합니다. 화면을 만들어주는 도구라기보다는, UX 사고 → 사용자 흐름 설계 → 프로토타입 제작까지 이어지는 제품 설계 과정을 AI가 함께 수행하는 협업 도구에 가깝습니다. 그리고 얼마 전, 구글 스티치도 비슷한 맥락의 업데이트를 진행했습니다. (출처)

주요 기능 훑어보기

Figr의 핵심 기능은 크게 네 가지 관점에서 이해할 수 있습니다. 단순히 디자인을 생성하는 것이 아니라 제품을 설계하는 과정을 단계적으로 지원한다는 점이 가장 큰 특징입니다.

<출처: Figr, 작가 캡처>

첫째, UX 의사결정을 먼저 고민하는 AI입니다. 대부분의 AI 디자인 도구는 프롬프트를 입력하면 곧바로 화면을 생성합니다. 반면 Figr는 바로 디자인을 만들지 않습니다. 대신 먼저 제품 맥락을 이해하려 합니다. "사용자는 현재 이 기능을 어떻게 사용하고 있는가", "어디에서 가장 많이 이탈하는가", "사용자 흐름에서 빠진 단계는 없는가" 같은 질문을 던지며 제품 문제를 먼저 정의합니다. 그래서 첫 출발점 역시 이런 화면을 만들어줘!가 아니라 서비스나 기능에 대한 설명, 관련 파일 업로드, 웹사이트 링크 등록으로 설정되어 있습니다.

AI는 User Flow, Edge Case, UX Decision을 정리한 뒤 그 다음에 디자인을 제안합니다. 즉, 디자인이 먼저가 아니라, UX 설계가 먼저이고 디자인은 그 결과라는 접근 방식입니다. 실제로 많은 팀이 잘못된 흐름을 만들어 놓고 나중에 수정하는 과정에서 가장 많은 시간을 낭비합니다. 버튼 색상은 금방 바꿀 수 있지만, 잘못 설계된 흐름은 쉽게 고칠 수 없기에 더 유용하게 느껴지는 출발점이자 기능이라고 생각합니다.

<출처: Figr, 작가 캡처>

둘째, 다양한 제품 데이터를 입력할 수 있습니다. Figr는 단순히 텍스트 프롬프트만 사용하는 서비스가 아닙니다. 실제 제품을 이해하기 위해 다양한 형태의 데이터를 입력할 수 있습니다. 서비스 화면 스크린샷이나 Figma 파일, 화면 녹화 영상, 웹 페이지 캡처, 제품 문서(PRD), 심지어 분석 데이터 CSV까지 활용할 수 있습니다. 이러한 데이터를 기반으로 AI는 제품의 실제 구조와 맥락을 이해합니다. 맥락 없는 프로토타입은 시각적으로 인상적이어도 전략적으로는 쓸모없을 수 있는데, Figr는 이 점을 해결하기 위해 노력하고 있다는 점을 명확하게 알 수 있습니다.

<출처: Figr, 작가 캡처>

셋째, 사용자 흐름과 예외 케이스를 자동으로 구조화합니다. 제품을 설계할 때 가장 많은 시간을 잡아먹는 작업 중 하나가 예외 상황을 정의하는 과정입니다. 결제 중 네트워크가 끊기면 어떻게 되는지, 로그인 토큰이 만료되면 어떤 화면이 보여야 하는지, 사용자가 중간에 앱을 종료하면 상태는 어떻게 처리해야 하는지 같은 문제들입니다.

Figr는 이러한 상황을 자동으로 분석해 User Flow, Edge Case, Information Architecture, Test Case 같은 구조적인 결과물로 정리합니다. 위 이미지는 Zoom의 네트워크 상태 변화 UX를 분석한 사례로, 패킷 손실이나 대역폭 감소 상황에서 서비스가 어떤 UX 상태를 보여줘야 하는지를 구조적으로 정리한 내용입니다. 서비스에서는 다양한 활용 사례를 제공하고 있는데 Wise의 카드 동결 플로우, Spotify의 플레이리스트 생성 흐름, Shopify의 체크아웃 리디자인 같은 복잡한 제품 문제들이 미리 살펴볼 수 있습니다.

넷째, 제품 스타일을 반영한 프로토타입을 생성합니다. UX 설계가 완료되면 AI는 그 결과를 기반으로 프로토타입을 생성합니다. 흥미로운 점은 기존 서비스의 디자인 스타일을 반영한다는 것입니다. 기존 컴포넌트 구조나 디자인 시스템 토큰을 참고해 실제 서비스와 유사한 UI를 생성하며, 생성된 결과물은 Figma로 바로 export할 수도 있습니다. 또한 여러 디자인 변형(A/B Variation)을 함께 제안하고, 접근성 체크나 UX 리뷰 같은 요소도 함께 제공됩니다.

주요 기능 활용하기

Figr를 실제로 사용하는 과정은 일반적인 디자인 툴과 조금 다릅니다. 화면을 만드는 도구라기보다 제품을 분석하고 설계하는 과정에 가까운 흐름입니다.

<출처: Figr, 작가 캡처>

1단계: 제품 맥락을 입력합니다. 서비스 화면 캡처나 Figma 파일, 화면 녹화 영상, 혹은 제품 문서를 업로드해 AI에게 현재 제품의 상태를 설명합니다. 이 과정은 단순히 자료를 업로드하는 것이 아니라 AI에게 제품의 구조와 사용자 흐름을 이해시키는 단계입니다. 특히 스크린샷보다는 실제 사용 흐름이 담긴 화면 녹화 영상을 업로드하면 AI가 사용자 행동 패턴을 더 정확하게 파악하는 경향이 있습니다.

2단계: AI가 질문을 통해 제품 문제를 정의합니다. "사용자가 가장 많이 이탈하는 지점은 어디인가요?", "이 기능의 핵심 사용자 목표는 무엇인가요?" 같은 질문을 던지며 문제 정의를 구체화합니다. 실제 제품 팀이 워크숍을 통해 문제를 정의하는 과정과 상당히 유사합니다.

<출처: Figr, 작가 캡처>

3단계: AI가 사용자 흐름과 구조를 생성합니다. User Flow, Edge Case, Test Case, Information Architecture 같은 결과물이 만들어지는 단계입니다. 이 단계에서 제품 설계가 체계적으로 구조화되며, 팀 간 핸드오프를 위한 문서로도 활용할 수 있습니다. 기획자, 디자이너, 개발자가 같은 맥락을 공유하게 됩니다.

<출처: Figr, 작가 캡처>

위 이미지는 스카이스캐너의 메인화면을 URL과 캡처한 이미지로 등록한 뒤, 60대 이상 연령이 사용하기 좋은지 접근성에 대한 검사를 요청, 결과를 확인하는 캔버스의 모습입니다. 요청 후, Figr은 페이지를 확인하며 문제를 하나, 둘 논리적으로 정리하고 어떤 식으로 개선하면 좋을지에 대한 내용을 제안합니다. 그리고 이를 바탕으로 최종 완성된 프로토타입까지 제공해 줍니다.

<출처: Figr, 작가 캡처>

4단계: UI 프로토타입이 생성됩니다. 기존 디자인 시스템을 반영한 UI가 만들어지며, A/B Variation도 함께 제안됩니다. 접근성 체크나 UX 리뷰도 포함되고, Figma export까지 연결됩니다. 위 이미지는 퍼플렉시티 화면 캡처와 녹화를 바탕으로 생성한 프로토타입의 모습입니다. 맥락 정보를 제공한 상태고, HTML 형태로 스크랩하기 때문에 기존 서비스와 위화감이 없는 모습의 프로토타입을 확인할 수 있습니다.

한 번은 꼭 써봐야 하는 이유

AI 디자인 도구는 이미 많이 존재합니다. 하지만 대부분의 도구는 여전히 프롬프트 → 화면 생성이라는 구조를 중심으로 동작합니다. 반면, Figr는 문제 정의 → UX 설계 → 프로토타입이라는 흐름을 중심으로 설계되어 있습니다.

이 차이는 생각보다 큽니다. 실제 제품 개발에서 가장 비용이 많이 드는 실수는 시각적인, 겉으로 드러나는 문제가 아닙니다. 흐름, 상태, 가정 등 눈에 보이지 않는 부분에서의 실수가 더 많은 문제를 가져옵니다. 게다가 이런 문제는 불행하게도 프로젝트 초기보다는 중기나 후기에 발견되는 경우가 많습니다. 따라서 Figr는 이 단계를 앞으로 당기는 데 집중합니다.

<출처: Figr, 작가 캡처>

Figr를 사용하는 팀들이 보고한 수치를 보면, 디자인 반복 사이클 68% 감소, 디자인-개발 핸드오프 시간 45% 단축, 디자인 운영 비용 평균 40% 절감이라는 결과가 있습니다. 한 B2B SaaS 스타트업은 Figr 도입 후, 디자인 일관성 개선으로 사용자 활성화율이 22% 증가했다고 밝히기도 했습니다.

다만 실무에서 활용할 때 몇 가지 고려할 점도 있습니다. Figr는 컨텍스트 기반 AI이기 때문에 제품 정보 입력이 충분하지 않으면 결과 품질이 떨어질 수 있습니다. 초기 세팅에 투자해야 진가를 발휘하는 도구라는 뜻입니다. 또한 현재 단계에서는 완성형 UI 제작 도구라기보다는 UX 설계와 제품 구조화를 지원하는 도구에 가깝습니다. 특히 PM 중심의 제품 조직이나 초기 기획 단계에서 더 큰 효과를 발휘할 가능성이 높습니다. 반대로 이미 디자인 시스템이 완성된 대형 조직에서는 충분한 온보딩 없이 바로 도입하면 기대보다 효율이 낮을 수 있습니다.

개인적으로 AI가 디자인을 대신하는 시대라기보다는, AI가 제품 사고를 함께하는 시대가 시작되고 있다는 느낌을 받았는데요. 그래서 개인적으로는 Figr를 단순한 AI 디자인 툴이라기보다 "AI 제품 설계 도구"라고 부르는 편이 더 어울린다고 생각합니다.

<참고>

https://figr.design

]]>

몰트북(Moltbook)의 성공에서 반드시 읽어야 할 3가지 포인트

솔직히 말하자면, 처음에는 몰트북(Moltbook)을 보고 그저 웃고 말았습니다.

AI들끼리 글을 올리고 떠드는 SNS라니. “이건 그냥 잠깐 반짝하고 사라질 밈 아닌가?” 싶었거든요. 그런데, 이 기묘한 서비스는 엄청난 속도로 퍼져 나갔고, 결국 메타(Meta) 인수라는 결과로까지 이어졌습니다.

그렇게 몰트북은 AI의 미래를 보여준 서비스를 넘어, 요즘 성공하는 제품의 예시가 되었습니다. 요즘 시대의 프로덕트는 어떻게 화제가 되고 어떻게 퍼질까요?

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

메타는 왜 이렇게 급히 몰트북을 인수했을까?

최근 테크 업계에서 몰트북 이야기가 다시 나오는 이유는 서비스 자체의 새로움보다, 그 이름 옆에 갑자기 메타(Meta)라는 거물이 붙었기 때문입니다. “AI 에이전트들이 서로 글을 올리고 반응하는 기묘한 소셜 네트워크” 정도로만 보였던 서비스를 그들이 인수한 것이죠.

그렇다면 왜 메타 같은 빅테크가 이렇게 빠르게 몰트북을 인수했을까요?

흥미로운 점은 몰트북이 처음부터 완성도 높은 대형 서비스가 아니었다는 사실입니다. 사실 외형만 보면 꽤나 낯선 실험에 가깝습니다. 인간이 아니라 AI 에이전트들이 서로 소통하는 레딧(Reddit) 형태의 네트워크인데, 오픈클로(OpenClaw)를 사용하는 에이전트들이 글을 올리고 반응하며 상호작용하는 구조니까요.

그런데 바로 그 낯설음이 강력한 질문을 만들어냈습니다. “대체 이건 실험적 사이드 프로젝트인가, 아니면 어떤 흐름의 시작인가?” 그리고 메타라는 빅테크가 움직이는 순간, 이러한 질문은 단순한 구경거리를 넘어서는 의미를 갖기 시작했습니다.

저는 이 지점이 지금 시대의 프로덕트 메이커에게 특히 중요하다고 봅니다.

어떤 제품은 기능 설명부터 길어집니다. 반면 어떤 제품은 존재 자체가 하나의 질문이 됩니다. 몰트북은 분명 후자에 가까웠습니다. 처음 접하는 순간 “이런 게 왜 있지?”라는 반응이 나오고, 시간이 조금 지나면 “그런데 왜 다들 이 이야기를 하지?”로 바뀝니다. 그 궁금증은 곧 “메타는 여기서 무엇을 본 걸까?”라는 질문까지 이어졌습니다. 제품이 시장에 던지는 질문의 크기가 커질수록, 그 제품은 단순한 기능 이상의 의미로 소비됩니다. 몰트북은 바로 그 사례에 가깝습니다.

그래서 저는 몰트북을 “AI들이 자기들끼리 떠드는 신기한 서비스” 정도로 소개하고 끝내려고 하지 않습니다. 오히려 이 사례를 보며, 요즘 제품은 무엇이 잘 만들어졌느냐 못지않게 무엇이 빠르게 이야기거리가 되느냐가 훨씬 중요해졌다는 점을 짚어보려 합니다. 메타 인수는 이를 극적으로 보여준 장면 하나일 뿐입니다. 이제 프로덕트를 만드는 메이커라면 “몰트북이 정확히 무엇이었지?”에서 멈추면 안 됩니다. “왜 이런 서비스가 이렇게 짧은 시간 안에 업계 전체의 화제가 되었을까?”라는 질문을 던질 줄 알아야 합니다.

몰트북은 오픈클로(OpenClaw)가 만든 파도 위에서 터졌습니다

그 이야기를 이어가기 위해서는 먼저 몰트북이 혼자서 떠오른 서비스가 아니었다는 사실부터 살펴볼 필요가 있습니다. 이 서비스가 흥미로운 이유는 “갑자기 어디선가 천재적인 제품 하나가 튀어나왔다”는 서사가 아닌, 이미 어느정도 형성되고 있던 흐름 위에 아주 빠르게 올라탄 서사를 보여주기 때문입니다. 그 흐름의 중심에 있었던 것은 바로 오픈클로(OpenClaw)입니다. 2026년 1월, Clawdbot에서 Moltbot을 거쳐 이름을 바꾼 오픈클로를 두고 Techcrunch는 “입소문 타고 퍼지는 개인용 AI 어시스턴트(viral personal AI assistant)”라고 설명합니다. 기사에서는 이를 사용하는 AI 에이전트들이 몰트북이라는 별도의 소셜 네트워크까지 만들기 시작했다고 전합니다.

이 점을 눈여겨 보려고 합니다. 프로덕트가 주목받는 방식이 예전과는 조금 달라졌기 때문입니다.

예전에는 “좋은 아이디어 하나”가 크게 주목받는 경우가 많았습니다. (물론 지금도 그런 일은 있습니다.) 하지만 요즘은 양상이 다소 달라졌습니다. 이미 형성된 커뮤니티, 이미 쌓인 관심, 이미 활발하게 이어지는 실험 문화 위에 새로운 제품이 빠르게 붙는 순간, 훨씬 더 큰 반응이 나옵니다. 몰트북이 바로 그 전형적인 사례처럼 보였습니다. 오픈클로라는 선행 흐름이 있었고, 사람들은 이미 그 흐름에 호기심을 갖고 있었습니다. 그런 상태에서 “AI 에이전트들이 자기들끼리 떠드는 공간”이 등장하니 반응이 나오지 않는 것이 더 이상할 정도였습니다.

이걸 스타트업 관점에서 조금 더 현실적으로 말하면 이렇습니다. 아무것도 없는 평지에서 불을 붙이는 일은 매우 어렵지만, 이미 어딘가에서 작은 불길이 올라오고 있다면 장작 하나만 잘 얹어도 분위기는 순식간에 달라진다고. 몰트북은 처음부터 거대한 제품이라기보다, 이미 사람들의 시선이 모이고 있던 오픈클로란 흐름 위에 올라탄 매우 영리한 장작에 가까웠습니다. 그래서 이 사례를 볼 때는 “몰트북의 완성도가 얼마나 높았는가”보다 “어떤 타이밍에 어떤 흐름과 이어졌나”를 먼저 보는 것이 더 중요하다고 생각합니다. 프로덕트 메이커라면 이 차이를 놓치지 말아야 합니다. 요즘은 제품의 품질만큼이나, 어떤 흐름에 언제 올라타느냐가 성패를 크게 가르기 때문입니다.

놓치면 안 되는 지점은 속도입니다. 오픈클로가 바이럴 개인용 AI 어시스턴트로 주목받고, 그 위에서 에이전트들이 활동하는 몰트북이 등장한 다음, 이 사례가 여러 매체를 통해 빠르게 확산됐습니다. 그 확산이 결국 메타 인수 이야기로까지 이어졌다고 봐야하죠. 이는 관심이 생기고, 실험이 붙으며, 이야기거리가 생기고, 더 큰 플랫폼이 그 흐름을 포착하는 과정에 가깝습니다. “연계의 속도”가 왜 중요한지가 바로 여기 있습니다. 몰트북은 혼자서 번쩍인 서비스가 아니라 이미 뜨거워진 생태계의 에너지를 가장 빠르게 흡수한 서비스인 셈입니다.

이처럼 몰트북은 “특이한 AI 서비스”이기 때문에 주목받은 것이 아닙니다. 그보다 앞서 오픈클로라는 선행 흐름이 있었고, 그 흐름과 정확한 타이밍에 연결되었기 때문에 더 크게 화제가 될 수 있었습니다. 그러니 프로덕트 메이커가 배워야 할 것은 기능 자체에만 있지 않습니다. 이미 어디에서 관심이 형성되고 있는지, 어떤 실험 문화가 만들어지고 있는지, 그리고 내 제품이 그 흐름과 얼마나 빠르게 연결될 수 있는지를 읽어내는 감각을 배워야 합니다.

첫 번째 포인트, 기능보다 ‘한 줄로 설명되는 세계관’

저는 몰트북이 이렇게 빨리 퍼진 가장 큰 이유 중 하나는, 기능 자체보다도 설명이 매우 쉬운 제품이었다는 점에 있다고 봅니다. 좋은 제품이라고 해서 꼭 잘 퍼지는 것은 아니더라고요. 반대로 기능은 쉬워도, 남에게 한 문장으로 설명할 수 있는 제품은 강력합니다. 몰트북이 딱 그쪽입니다. “AI 에이전트들이 자기들끼리 글을 올리고 반응하는 소셜 네트워크.” 이 한 문장만 들어도 대충 그림이 바로 떠오르죠. 제품 소개를 길게 들을 필요도 없고, 데모를 자세히 보지 않아도 됩니다. 머릿속에 장면이 먼저 그려지고, 호기심을 자극합니다. TechCrunch 역시 몰트북을 오픈클로 기반 AI 에이전트들이 서로 소통하는 레딧형 네트워크라고 쉽게 설명했죠.

이게 왜 중요할까요? 요즘 화제가 되는 제품들이 기능 중심으로 퍼지지 않기 때문입니다. 사람들은 상세 스펙보다 이야기할 수 있는 장면을 더 잘 기억합니다. “정리가 잘 되는 메모 앱”보다 “회의가 끝나자마자 AI가 알아서 일을 나눠주는 도구”가 더 빨리 퍼지는 이유도 여기에 있습니다.

여기를 몰트북은 매우 강하게 포착했습니다. “AI끼리 자기들만의 커뮤니티를 만든다”는 설정은 듣는 순간 조금 황당하지만, 동시에 매우 쉽게 전달됩니다. 설명에 드는 비용이 거의 없는 셈이죠. 프로덕트 메이커 입장에서 이건 결코 가볍게 넘길 수 없습니다. 시장은 항상 좋은 제품만을 기억하지 않습니다. 설명 가능한 제품, 더 정확하게는 다른 사람이 다시 설명하고 싶어지는 제품을 훨씬 빠르게 퍼뜨립니다.

몰트북의 강점은 이 지점에서 더욱 또렷해집니다. 이 서비스는 기능을 하나하나 나열해야 매력이 드러나는 제품이 아니었습니다. 오히려 기능을 자세히 설명하기 시작하면 힘이 좀 빠집니다. 대신 “인간은 구경만 하고, AI들이 자기들끼리 활동한다”는 세계관을 던지는 순간 살아납니다. 저는 이게 꽤 중요하다고 봅니다. 프로덕트는 사용 경험을 중심으로 돌아가지만, 그 이전에 인지 경험이 먼저 있습니다. 사용해 보기 전부터 어떤 제품인지 감이 오는지, 다른 사람에게 말할 때 입에 붙는지, 첫인상이 이미지로 남는지 같은 것이 확산 속도를 좌우합니다. 몰트북은 이러한 인지 경험 설계를 아주 잘한 사례였습니다. 그래서 사람들이 서비스에 직접 들어가기 전부터 이미 이 제품을 머릿속으로 그려보고 있었던 거죠. 스크린샷을 보든, 기사 제목만 보든, 다른 사람의 글을 읽든 마찬가지로요.

프로덕트 메이커가 짚어야 할 포인트가 하나 더 나온 겁니다. 우리는 보통 제품을 만들 때 기능을 우선으로 고려합니다. 무엇을 할 수 있는지, 얼마나 잘 동작하는지, 어디까지 자동화할 수 있는지를 먼저 고민하죠. 물론 중요합니다. 그러나 퍼지는 제품은 여기서 한 걸음 더 갑니다. 이 제품을 한 문장으로 뭐라고 설명할 수 있는가, 그리고 그 한 문장이 사람들의 호기심을 자극하는가까지 함께 설계합니다. 즉, 몰트북은 완성도가 높아서 강했다기보다, “AI 에이전트용 소셜 네트워크”라는 세계관 자체가 호기심을 부르고 쉽게 공유할 수 있었기 때문에 더 반응을 얻었습니다. 그래서 이 사례를 볼수록, 이제는 제품을 잘 만드는 것만으로는 충분하지 않고, 바로 이해할 콘셉트까지 함께 설계해야 한다는 생각이 들었습니다.

두 번째 포인트, 완성도보다 더 강력했던 ‘연계 속도’

몰트북에서 저한테 가장 흥미로웠던 지점은, 이 서비스가 얼마나 빠르게 기존 흐름과 연결됐느냐였습니다. 보통 우리는 화제가 된 제품을 보면 “기능이 엄청 뛰어났나 보다”, “기술적으로 대단했나 보다”라고 먼저 생각합니다. 그런데 실제 시장에서 크게 반응을 얻는 사례들을 보면 꼭 그렇지만은 않습니다. 오히려 이미 사람들의 관심이 모여 있는 흐름에 얼마나 민첩하게 올라타느냐가 훨씬 큰 차이를 만드는 때도 많습니다.

몰트북도 마찬가지였습니다. 오픈클로라는 선행 흐름이 이미 형성돼 있었고, 사람들은 AI 에이전트가 단순한 도구를 넘어 자율적으로 움직인다는 그림에 한창 관심을 갖고 있었습니다. 그 타이밍에 몰트북은 “그 에이전트들이 자기들끼리 활동하는 공간”이라는 아주 직관적인 확장을 내놓았습니다. 쉽게 말해, 완전히 새로운 세계를 만든 것이 아니라 이미 뜨거워진 세계에서 나올 법한 가장 재밌는 장면을 덧붙인 셈입니다.

이런 제품은 강력합니다. 왜냐하면 혼자서 시장을 설득할 필요가 없기 때문입니다. 완전히 새로운 카테고리를 처음부터 이해시키려면 상당한 비용이 듭니다. 이게 무엇인지 설명도 해야 하고, 왜 필요한지도 입증해야 하며, 사람들이 익숙해질 시간도 줘야 합니다. 그러나 이미 관심이 형성된 흐름 위에 올라타면 말이 달라집니다. 사람들의 머릿속에 기본 맥락이 이미 자리 잡고 있으니까요. “오픈클로 알지? 그 에이전트들이 이제 자기들끼리 커뮤니티까지 만든 거야”라는 식의 설명은 훨씬 쉽습니다. 제품 자체를 처음부터 풀어 설명하지 않아도, 선행 맥락이 절반 이상을 알아서 전달해 줍니다. 저는 이게 정말 중요하다고 봅니다. 요즘처럼 정보가 넘치는 때는 더 좋은 제품보다 기존 맥락을 가장 영리하게 이어받은 제품이 훨씬 빠르게 앞서 나가는 경우가 많으니까요.

스타트업이나 사이드 프로젝트를 해본 분들이라면 이 감각이 얼마나 중요한지 잘 아실 겁니다. 아무도 관심을 두지 않는 주제를 붙잡고 “이거 정말 좋은데요?”라고 외치는 건 생각보다 훨씬 힘듭니다. 반대로 이미 사람들이 주목하고 있는 주제 옆에서는 그저 있기만 해도 기회가 생깁니다. 물론 그냥 옆에만 선다고 되지는 않겠죠. 거기서 한 번 더 웃기거나, 놀라게 하거나, 사람들이 공유하고 싶어지는 장면을 만들어야 합니다. 몰트북은 그걸 해낸 사례고요. 오픈클로라는 맥락 위에 올라타되, 복제가 아니라 “AI 자기들끼리 노는 공간”이라는 한 단계 더 강한 장면을 덧붙였으니까요. 그 결과 사람들은 오픈클로에 반응했던 것 그 이상으로 몰트북을 캡처하고, 이야기하며, 기사로 만들기 시작했습니다. 기술 자체보다 연결 방식의 감각이 돋보였던 순간이라고 생각합니다.

이쯤에서는 프로덕트 메이커 입장에서 꽤 불편한 질문을 마주해야 합니다. “나도 제품은 충분히 잘 만들었는데, 왜 아무도 이야기하지 않을까?”라는 질문이죠. 저 역시 이 질문을 여러 번 해봤습니다. 기능 넣고, 디테일까지 신경 썼음에도 반응이 미미할 때는 허탈함이 큽니다. 그러나 냉정하게 돌아보면, 제품 자체의 문제라기보다 연계의 속도와 방향이 느렸던 경우가 많았던 듯합니다. 지금 사람들이 어디에 관심을 두고 있는지, 어떤 실험 문화가 커지고 있는지, 그리고 내 제품이 그 흐름과 어떤 방식으로 붙을 수 있는지를 충분히 읽지 못한 것이죠. 몰트북은 완성도에 대한 평가와는 별개로, 적어도 이 부분에서는 굉장히 뛰어난 사례입니다. 그래서 저는 이 서비스를 “잘 만들어진 제품”이라기보다, “엄청 잘 바이럴된 제품”으로 기억할 것 같습니다.

결국 여기서 얻을 수 있는 교훈은 꽤 현실적입니다. 앞으로의 제품 경쟁은 단순히 누가 더 정교한 기능을 만드는지에서 끝나지 않을 가능성이 큽니다. 그보다 먼저, 누가 더 빠르게 흐름을 읽고, 누가 더 재밌는 방식으로 기존의 파도 위에 올라타며, 누가 더 짧은 시간 안에 사람들의 입에 오르내릴 장면을 설계하느냐가 중요해질 것입니다. 몰트북은 그 사실을 노골적으로 보여줬습니다. 그리고 바로 이 지점에서 마지막 질문이 남습니다.

그렇다면 프로덕트 메이커는 몰트북을 어떻게 봐야 할까요? 단순한 AI 서비스일까요, 아니면 프로덕트 출시 전략이란 관점에서 중요한 힌트를 주는 강력한 케이스일까요?

세 번째 포인트, ‘AI 서비스’보다 ‘바이럴 설계 사례’로 보기

여기까지 오면 이제 질문이 조금 달라집니다. 몰트북이 신기한 서비스였는지 아닌지는 사실 그렇게 중요하지 않을 수도 있습니다. 더 중요한 건 이 사례가 어떻게 그렇게 짧은 시간 안에 사람들의 입에 오르내렸는가입니다. 저는 이 지점에서 몰트북을 단순한 AI 서비스로 보기보다, 프로덕트 런칭 관점에서 인사이트를 주는 바이럴 설계 사례로 봐야 한다고 생각합니다. 다시 말해 “AI가 무엇을 할 수 있는가”보다 “이 제품은 어떻게 이야기되고, 어떻게 퍼지며, 어떻게 더 큰 플레이어의 시야에 들어갔는가”를 봐야 한다는 뜻입니다. 프로덕트 메이커에게 중요한 분기점은 대개 여기서 갈립니다. 기능은 뛰어나지만 아무도 이야기하지 않는 제품이 있는가 하면, 기능은 아직 다듬어질 여지가 있어도 모두가 이야기하는 제품도 있습니다. 시장은 생각보다 냉정해서 후자만을 기억하는 경우가 많습니다.

몰트북은 그러한 현실을 선명하게 보여줍니다. 이 서비스는 처음부터 완성형 정답처럼 보이지는 않았습니다. 오히려 실험적이고, 기묘하며, 밈처럼 소비될 여지도 있는 제품이었습니다. 그럼에도 불구하고 사람들은 이 서비스를 끝없이 이야기했습니다. 기능 목록보다 먼저 설명하기 좋은 콘셉트가 있었고, 그 콘셉트를 실제로 확산시킬 수 있는 장면이 있었으며, 이미 형성된 흐름과 맞물린 타이밍이 있었기 때문입니다. 이 세 가지가 모이면 제품은 단순 출시를 넘어 하나의 사건처럼 소비됩니다. 몰트북이 딱 그랬다고 봅니다. 그래서 이를 두고 “제품이 얼마나 정교했는가”만을 따지는 건 아쉬운 접근입니다.

본질적인 질문은 따로 있습니다. 왜 이 제품은 사람들로 하여금 남에게 이야기하게 만들었을까?라는 질문입니다. 이 질문이 훨씬 중요합니다.

제품을 만들다 보면 우리는 자꾸만 기능 안으로 깊이 들어가게 됩니다. 저도 그렇습니다. 뭘 더 넣어야 할지, 어디를 개선해야 할지, 플로우는 어떻게 다듬어야 할지 같은 고민을 하루 종일 하죠. 그러나 그렇게 들어가다 보면, 때로는 가장 중요한 걸 놓치게 됩니다. 이 제품을 처음 보는 사람이 한 문장으로 이해할 수 있는가, 보고 나서 다른 사람에게 이야기하고 싶어지는가, 현재의 흐름과 붙었을 때 더 큰 반응을 만들 수 있는가 같은 질문들입니다. 몰트북은 그 질문을 다시 강하게 환기시켰습니다. 제품의 완성도는 물론 중요합니다. 그러나 이제는 그것만으로 부족합니다. 잘 만들어진 제품을 넘어, 잘 설명되고 잘 퍼지는 제품이 더 강한 시대가 되고 있다는 느낌을 지우기 어렵습니다.

그래서 몰트북을 보며 한편으로는 무서운 것도 있었습니다. 앞으로는 단순히 만드는 역량만으로는 부족할 수 있겠다는 생각이 들었기 때문이죠. 만드는 사람의 역할이 끝났다는 의미는 아닙니다. 다만 무엇을 만들지, 어떤 타이밍에 내놓을지, 사람들이 어떤 장면을 소비하게 만들지까지 함께 설계하는 역량이 더욱 중요해지고 있다는 뜻입니다. 개발자, PM, 창업자, 그리고 사이드 프로젝트를 진행하는 사람 누구에게나 이 감각은 점점 더 중요해질 것입니다. 좋은 기능을 하나 잘 만드는 일도 어렵지만, 그 기능이 사람들 사이에서 이야기로 살아 움직이게 만드는 건 전혀 다른 차원의 역량이니까요. 몰트북은 바로 그 차이를 매우 짧은 시간 안에 보여준 사례였습니다.

결국 이 글에서 말하고 싶었던 건 단순합니다. 몰트북은 “AI끼리 떠드는 이상하고 낯선 사이트”라서 중요한 것이 아닙니다. 그보다 더 중요한 것은 이 제품이 세계관, 연결, 확산이라는 세 가지 요소로 어떻게 시장의 시선을 사로잡았는가입니다. 그리고 그 끝에서 메타와 같은 거대한 플레이어까지 움직였다는 사실은, 이제 제품 경쟁이 단순한 기능 비교만으로 이루어지지 않는다는 점을 다시 한 번 보여줍니다. 프로덕트 메이커라면 이 사례를 그저 흥미로운 뉴스로 넘기기보다, 자신의 제품에 그대로 적용해 질문해야 합니다.

내 제품은 한 문장으로 설명되는가, 현재의 흐름과 연결되어 있는가, 사람들이 굳이 다른 이에게 이야기하고 싶어질 만큼의 장면을 갖고 있는가. 어쩌면 앞으로의 승부는 바로 그곳에서 갈릴지도 모르겠습니다.

]]>

소프트웨어의 유튜브 모멘트: 이제 누구나 제품을 만든다

"개발자가 없어서 못 하고 있어요."

아이디어가 반짝이지만 개발자가 없어서 시작도 못 한 이야기를 한 번쯤 들어봤거나, 직접 해봤을 말입니다. 아이디어는 있는데 개발 리소스가 없고, 외주를 맡기자니 비용이 너무 비싸고, 그렇다고 개발자를 뽑자니 초기 팀에 그런 여유가 없는 상황 말이죠. PM이나 기획자들이 수도 없이 부딪혀온 벽일 겁니다.

그런데 2025년을 기점으로 이 말은 변명이 되어가고 있습니다. a16z의 파트너 Anish Acharya는 지난 1월 이렇게 말했습니다. "소프트웨어의 유튜브 모멘트가 지금 일어나고 있다. "YouTube가 2005년에 나왔을 때, 영상은 방송국과 전문 PD의 영역이었습니다. 장비, 편집, 배급 전부 진입 장벽이었죠. 그게 스마트폰 카메라 하나로 무너졌습니다. 지금은 유튜버가 지상파보다 영향력이 큰 게 당연한 세상이고요.

"이제 만들 때입니다. 이제 누구나 만들 수 있습니다." <출처: a16z.news>

소프트웨어에도 같은 일이 벌어지고 있습니다. Cursor, Claude Code, Replit, Wabi 같은 AI 코딩 도구들이 그 장벽을 허물고 있기 때문입니다.

미리 요점만 콕 집어보면?

YouTube가 영상 창작의 문턱을 낮췄듯, AI 코딩 도구는 소프트웨어 제작의 문턱을 낮추고 있다. 이제 개발자가 없어도 서비스를 만들 수 있는 시대가 열리고 있다.
기획자, PM, 창업자에게 이 변화는 단순한 도구 변화가 아니다. 아이디어 검증 속도가 달라지고, 경쟁 구도가 바뀌고, 누가 시장에 진입할 수 있는지가 달라지는 비즈니스 지형의 변화다.
이 기회를 잡으려면 '어떻게 만들지'보다 '무엇을 만들지'를 판단하는 능력이 훨씬 더 중요해진다.

유튜브가 이미 보여준 것

<출처: 픽사베이>

Acharya는 영상 창작의 역사를 세 단계로 나눕니다.

첫 번째는 “Hollywood” 시대입니다. 영화 한 편을 만들려면 수백만 달러의 제작비와 전문 스튜디오가 필요했습니다. 창작은 소수의 전문가 집단 손에 있었죠.

두 번째는 “인디 감독” 시대입니다. 1990년대 쿠엔틴 타란티노, 폴 토마스 앤더슨 같은 감독들이 저예산으로 영화를 만들기 시작했습니다. 장벽이 낮아졌지만, 여전히 전문성과 비용이 필요했습니다.

세 번째가 “YouTube” 시대입니다. 스마트폰 하나면 누구나 촬영하고, 편집하고, 전 세계에 배포할 수 있게 됐습니다. Mr. Beast는 방송국 없이도 수억 명의 구독자를 가진 크리에이터가 됐습니다.

소프트웨어도 정확히 같은 경로를 걷고 있습니다. 할리우드 시대에는 소프트웨어 하나 만들려면 대기업이거나 수억 원을 쏟아야 했습니다. 인디 시대에 Y Combinator 같은 스타트업 액셀러레이터(초기 스타트업에 투자와 멘토링을 해주는 프로그램)가 생기면서 Airbnb, Coinbase 같은 아웃사이더들이 끼어들기 시작했고요. 지금은 AI 코딩 도구가 유튜브 역할을 하고 있습니다. 코딩을 모르는 사람도 제품을 만들 수 있는 시대가 된 겁니다.

a16z가 소개한 사례들을 보면 과장이 아니라는 걸 알 수 있습니다. 누군가는 MRI 이미지를 시각화하는 대시보드를 직접 만들었는데, 의료 전문가들 반응이 "원래 상용 소프트웨어가 필요한 작업"이었다고 합니다. 라이브 방송하면서 실시간으로 앱을 짜는 사람도 있고, CLI 하나로 광고 캠페인 전체를 뚝딱 만들어내는 사람도 있습니다.

몇 년 전만 해도 개발팀 없이는 꿈도 못 꿨을 일들입니다.

실제로 일어나고 있는 일들

실제로 비개발자가 앱을 만들 수 있느냐고요? 제 지인은 개발자가 아닙니다. 그런데 최근 Cursor와를 이용해서 간단한 데이터 분석 대시보드를 만들었습니다. 특정 키워드가 포함된 기사들을 모아서 날짜별 트렌드를 시각화하는 도구였는데, 예전 같았으면 개발자 친구한테 부탁하거나 몇백만 원짜리 외주를 줬어야 할 작업이었습니다.

걸린 시간은 반나절이었습니다. 물론 한계는 있습니다. 복잡한 로직이나 고도화된 기능은 여전히 개발자 손이 필요합니다. 하지만 아이디어를 검증하는 수준의 프로토타입이라면, 이제 개발 전공이 필수가 아닙니다.

Replit의 CEO Amjad Masad는 "앞으로 10억 명이 소프트웨어를 만들 것"이라고 했습니다. 과장 같죠. 그런데 YouTube가 처음 나왔을 때 "수억 명이 영상 크리에이터가 된다"는 말도 똑같이 허풍처럼 들렸습니다.

한국에서도 조짐이 보입니다. 국내 스타트업에서는 PM이 직접 프로토타입을 만들어 사용자 인터뷰를 돌리거나, 마케터가 데이터 분석 도구를 직접 만드는 사례가 늘고 있습니다. 개발자를 기다릴 필요 없이, 아이디어가 떠오른 그날 바로 테스트해 볼 수 있게 된 거죠.

서비스를 만드는 사람들에게 생긴 실질적인 변화

<출처: 픽사베이>

이 변화가 기획자, PM, 창업자에게 구체적으로 뭘 의미할까요?

첫째, 아이디어 검증 주기의 변화

기존 개발 사이클을 떠올려보세요. 아이디어 → 기획 → 개발 의뢰 → 개발 완료 → 테스트 → 수정 요청 → 재개발까지, 짧으면 몇 주, 길면 몇 달. 그 사이에 시장이 바뀌기도 합니다. 막상 만들어놓고 보니, 사용자가 원하는 게 전혀 다른 거였다는 걸 뒤늦게 알게 되기도 했죠.

이제는 아이디어가 생기면 그날 바로 클릭 가능한 프로토타입을 만들 수 있습니다. 사용자한테 보여주고, 피드백 받고, 다음 날 고치면 됩니다. "최소한의 제품을 빠르게 만들고 사용자 반응을 보면서 방향을 잡자"는 린 스타트업 방법론, 그동안 이상에 가까웠던 "빠른 실험과 검증"이 이제야 현실이 된 겁니다.

둘째, 사라진 프로토타이핑 비용

예전에는 기능 하나 검증하려 해도 개발팀에 의뢰를 넣어야 했습니다. 개발팀 시간은 한정돼 있으니, "아직 검증 안 됐으니 보류"로 묻히는 아이디어가 수두룩했죠. 이제 프로토타입 만드는 비용이 거의 0입니다. 그만큼 더 많은 아이디어를 실험해 볼 수 있고, 많이 실험할수록 좋은 서비스가 나올 확률도 올라갑니다. 성공 방정식 자체가 달라진 겁니다.

셋째, 개발자와의 협업 방식이 바뀐다

기획하는 사람과 개발하는 사람 사이에는 늘 번역의 문제가 있었습니다. 한쪽은 사용자 경험을 이야기하고, 한쪽은 기술적 제약을 이야기하고. 같은 서비스를 만들면서 서로 다른 언어로 대화하는 느낌이었죠. AI 코딩 도구가 이 간극을 줄여줄 수 있습니다. 기획자가 직접 프로토타입을 만들어서 "이런 느낌인데, 여기서 기술적으로 뭐가 어려워?"라고 물어볼 수 있게 되니까요. 말로 설명하던 걸 직접 보여주면서 대화하는 거라, 협업의 질이 확 달라집니다.

비즈니스 관점에서 보면 어떨까요?

기회: 새로운 시장이 열린다

Acharya 말대로, 소프트웨어에 관심도 없던 사람들이 직접 만들기 시작했습니다. 교사가 자기 수업에 딱 맞는 학습 도구를 만들고, 의사가 자기 진료 방식에 맞는 기록 시스템을 만들고, 요리사가 레시피 관리 앱을 만듭니다. 개발자들이 "이런 게 왜 필요해?"라고 넘겼던 문제들을 이제 비개발자들이 직접 코딩를 하기 시작한 것이죠. 여기서 기존에 없던 서비스들이 나올 수 있습니다.

기회: 소프트웨어는 콘텐츠와 다르다

Acharya는 이렇게 말합니다. 콘텐츠는 올리는 순간부터 가치가 떨어집니다. 조회수 찍고 내려가죠. 반면 소프트웨어는 사용자가 쌓일수록 가치가 올라갑니다. 한번 잘 만들어놓으면 사용자가 늘고, 데이터가 쌓이고, 서비스가 좋아지는 선순환이 생깁니다. 개발 비용이 거의 0이 된 지금, 이 복리 효과를 누릴 수 있는 사람이 훨씬 많아진 겁니다.

위협: 나만 쉬운 게 아니다

기회가 있으면 위협도 있습니다. 나만 쉽게 만들 수 있는 게 아니라, 경쟁자도 쉽게 만들 수 있습니다. 내 제품과 비슷한 걸 누군가가 하루 만에 만들어서 무료로 뿌릴 수도 있는 거죠. 덕분에 비슷한 형식의 스마트폰 게임이 수백 개가 출시되고 있는 것처럼 말이죠.

a16z 글의 댓글에는 더 날카로운 지적도 있었습니다. "이런 작은 도구들은 결국 Claude나 ChatGPT 같은 대형 모델이 기능을 흡수해버리면 살아남기 어렵다. 도구를 만들게 해준 플랫폼이 곧 경쟁자가 되는 셈이다." 그러니까 이제는 "만들 수 있다"는 것만으로는 부족합니다. 누구를 위해, 어떤 문제를 풀고 있는지가 진짜 경쟁력이 되는 시대입니다.

위협: '만들 수 있다'와 '잘 만들었다'의 차이

YouTube가 나온 후 수억 개의 영상이 올라왔지만, 그중에서 실제로 사람들에게 가치를 주는 콘텐츠는 소수였습니다. 소프트웨어도 마찬가지일 겁니다. 누구나 만들 수 있게 되면, 오히려 "잘 만든 것"의 기준이 높아집니다. 사용자 경험, 제품 감각, 문제에 대한 깊은 이해 등 이런 것들이 더 중요해집니다.

지금부터 준비해야 할 것은?

<출처: Claude Code, 터미널 화면 캡처>

그렇다면 이 변화 앞에서 우리는 뭘 해야 할까요?

첫째, AI 코딩 도구를 직접 써보세요.

이론으로 이해하는 것과 직접 써보는 것은 완전히 다릅니다. Cursor, Claude, v0(Vercel의 UI 생성 도구), Replit 중 하나를 골라서 본인이 평소에 "있으면 좋겠다"고 생각했던 간단한 도구를 직접 만들어보세요. 처음에는 느리고 답답하겠지만, 이 경험 자체가 엄청난 인사이트를 줍니다. 어디까지 가능한지, 어디서 막히는지, 어떤 도구가 어떤 작업에 맞는지가 보이기 시작합니다.

못 만든다고 생각했던 것들이 가능하다는 걸 느끼는 순간, 아이디어를 보는 눈이 달라집니다.

둘째, 빠른 검증을 팀의 문화로 만드세요.

AI 코딩 도구가 주는 가장 큰 선물은 속도입니다. 그런데 도구만 빨라져서는 소용이 없습니다. 팀이 그 속도에 맞춰 움직여야 합니다. 완벽한 기획서를 기다리는 대신, 대충이라도 만들어서 사용자한테 보여주고 반응을 보는 거죠. 회의실에서 "이거 될까요?" 논쟁하는 시간에 그냥 뚝딱 만들어서 돌려보는 겁니다.

셋째, '무엇을 만들 것인가'에 고민해 보세요.

아이러니하게도, 만드는 게 쉬워질수록 "뭘 만들지"가 더 중요해집니다. 누구나 만들 수 있으니까, 잘 만드는 건 더 이상 차별점이 아닙니다. 진짜 경쟁력은 풀어야 할 문제를 찾아내는 눈입니다. 사용자가 뭘 불편해하는지, 시장에 어떤 빈틈이 있는지, 이 문제가 정말 돈을 내고 해결할 만한 건지. 이건 아무리 AI가 좋아져도 대신 못 해주는 영역입니다.

유튜브도 마찬가지였습니다. 카메라를 잘 다루는 사람이 성공한 게 아니라, "이런 영상이 뜨겠지?"라고, 먼저 생각한 사람이 성공했습니다.

넷째, AI 도구를 팀 전체가 쓸 수 있게 환경을 만드세요.

개발팀만 AI를 쓸 이유가 없습니다. PM, 디자이너, 마케터 모두 각자 맡은 영역에서 AI 도구를 쓸 수 있어야 합니다. 간단한 가이드라인을 만들어두고, 누가 어떻게 쓰고 있는지 공유하는 자리를 만들어보세요. 한 팀원이 AI로 분석 시간을 반으로 줄였다면, 그걸 혼자 알고 있을 이유가 없습니다. 이런 변화를 개인이 아닌 팀이 함께 움직여야 합니다.

변명이 사라진 시대의 ‘진짜 경쟁력’

소프트웨어의 유튜브 모멘트가 왔다는 말은, 단순히 "이제 코딩 안 해도 된다"는 뜻이 아닙니다. 더 많은 사람들이 더 빠르게 더 많은 것을 만들 수 있게 됐다는 뜻이고, 그 말은 경쟁의 기준선 자체가 올라간다는 의미입니다. 유튜브가 서비스를 시작했을 때, 결국 살아남은 건 "누구나 만들 수 있으니 끝났다"고 겁먹은 사람이 아니라, 자기만의 관점과 이야기를 가진 사람이었습니다.

서비스를 만드는 사람들도 마찬가지입니다. "개발자가 없어서 못 만든다"는 말이 더 이상 안 통하는 시대에, 진짜 경쟁력은 뭘 만들지 아는 것, 누구를 위해 만드는지 아는 것, 그리고 빠르게 실험하고 배우는 것입니다.

도구의 문턱은 낮아졌습니다. 이제 남은 건 아이디어와 실행, 그리고 그걸 해볼 용기뿐입니다.

<참고>

[a16z] Software's YouTube moment is happening now

[inference] Replit CEO Amjad Masad on 1 Billion Developers: A Better End State than AGI

]]>

20년 전 게임 ‘건즈 온라인’을 브라우저로 이식한 개발자

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

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

써볼 것: Claude Code 치트시트 - 명령어부터 단축키까지 매일 자동 업데이트되는 한 장짜리 레퍼런스
참고할 것: 20년 전 게임을 브라우저로 이식한 개발자 - AI 없었으면 불가능했다
적용해볼 것: MCP로 Claude Code 디자인 감도 높이기

<출처: cc.storyfox.cz>

1. 써볼 것: 명령어부터 단축키까지 매일 자동 업데이트되는 한 장짜리 레퍼런스

Claude Code 치트시트는 cc.storyfox.cz에서 운영하는 Claude Code 전용 레퍼런스 페이지입니다. 단축키, 슬래시 명령어, MCP 서버 관리, 스킬·에이전트 설정, CLI 플래그, 환경 변수까지 한 페이지에 정리되어 있습니다. Claude Code 버전이 업데이트될 때마다 자동으로 반영되며, 현재 v2.1.83 기준입니다. Hacker News에도 올라왔습니다.

Claude Code를 처음 쓰기 시작하면 명령어가 어디 있는지 찾는 것 자체가 일입니다. /help를 쳐봐도 양이 많고, 공식 문서를 뒤지다 보면 시간이 금방 지나가죠. 이 치트시트는 그 탐색 비용을 줄여줍니다.

어떻게 쓰나요?

cc.storyfox.cz에서 바로 볼 수 있고, A4 가로 출력도 지원합니다. 윈도우·맥 전환 스위치가 있어서 운영체제에 맞는 단축키를 바로 확인할 수 있습니다. 주요 내용을 추려보면 이렇습니다.

자주 쓰는 단축키

Ctrl+C: 입력·생성 취소
Ctrl+D: 세션 종료
Ctrl+L: 화면 지우기
Ctrl+O: 상세 출력 전환 (thinking 내용 확인 가능)
Ctrl+R: 히스토리 검색
Ctrl+G: 프롬프트를 외부 에디터에서 편집
Ctrl+B: 작업을 백그라운드로 실행
Ctrl+T: 작업 목록 전환
Ctrl+V: 이미지 붙여넣기
Shift+Tab: 권한 모드 순환 (일반 → 자동 수락 → 계획 모드)
Alt+T: 사고(thinking) 모드 전환
Alt+P: 모델 전환
Esc+Esc: 되돌리기

입력 접두사

/: 슬래시 명령어 실행
!: bash 명령어 직접 실행
@: 파일 언급 및 자동완성

알아두면 유용한 슬래시 명령어

/compact: 컨텍스트 압축 (긴 세션에서 비용 절감)
/effort: 노력 수준 설정 (low/med/high/max)
/plan: 계획 모드 진입, 실행 전 검토
/btw: 현재 컨텍스트 비용 없이 별도 질문
/loop: 반복 스케줄 작업 설정
/branch: 대화 분기 생성 (/fork에서 변경됨)

세션 피커 단축키

P: 세션 미리보기
R: 세션 이름 변경
/: 세션 검색
A: 전체 프로젝트 보기
B: 현재 브랜치 기준 보기

최근 추가된 것들 (v2.1.83)

Ctrl+X, Ctrl+K: 백그라운드 에이전트 종료 (기존 Ctrl+F에서 변경)
CwdChanged / FileChanged 훅 이벤트 추가
managed-settings.d/ 드롭인 정책 파편 지원

누구에게 좋을까요?

Claude Code를 막 시작했거나 명령어를 자주 까먹는 분들에게 유용할 것 같습니다. 이미 능숙하게 쓰고 있다면 최근 변경 사항 확인용으로 가끔 들러보는 정도면 충분할 거고요. 매일 자동 업데이트된다는 점에서 북마크 하나 해두면 공식 문서 대신 쓸 수 있습니다.

<출처: blueocean 벨로그 >

2. 참고할 것: 건즈 온라인, 20년 만에 브라우저로 돌아왔다

벨로그를 둘러보다 흥미로운 글을 하나 발견했습니다. 벨로그 닉네임 blueocean이라는 분이 쓴 글인데요. 원문의 내용을 바탕으로 프로덕트 메이커 관점에서 인사이트를 정리해봤습니다. 이 글은 2003년 출시된 윈도우 전용 온라인 TPS 게임 건즈 온라인(GunZ: The Duel)을 WebAssembly + WebGL로 브라우저에서 돌아가도록 이식한 과정을 공유한 내용인데요. 3월 26일 기준, 벨로그 좋아요 102개를 받으며 개발자 커뮤니티에 공유되어 화제가 되었습니다.

건즈 온라인은 2007년경 클라이언트·서버 전체 C++ 소스코드가 유출된 이후 커뮤니티에서 계속 유지·보수되어 왔습니다. blueocean님은 그 소스코드를 기반으로 작업했는데, 게임 코드 자체는 거의 건드리지 않은 채 새로 필요한 코드의 99%를 AI가 썼다고 하네요. 핵심 도구는 Google Antigravity와 Claude Code였습니다.

기존 방식과 무엇이 다른가요?

blueocean님은 이전에도 같은 시도를 한 적이 있다고 합니다. 그 때는 JavaScript와 Three.js로 브라우저판을 처음부터 다시 만들려 했는데, 맵 렌더링까지는 갔지만 게임 엔진 전체를 재구현하는 벽에 막혀 결국 프로젝트가 흐지부지됐고요. 당시 작업한 레포지토리(three-gunz)는 지금도 GitHub에 남아 있다고 합니다.

두 번째 시도에서는 방향을 바꿨습니다. C++ 소스코드를 Emscripten으로 WebAssembly로 컴파일하면 브라우저에서 돌릴 수 있지만, 건즈는 윈도우 전용 그래픽 API인 Direct3D에 달라붙어 있어서 그냥은 불가능했다고 하네요. 이번에는 게임 코드를 건드리는 대신 게임과 그래픽 API 사이에 번역 레이어를 끼워 넣는 방식을 택하여 진행했다고 합니다.

어떻게 작동하나요? (원문 참고 내용)

번역 레이어의 핵심 아이디어는 간단합니다. 게임이 Direct3D에 명령을 보낼 때, 그 명령을 가로채서 브라우저가 이해하는 WebGL 명령으로 바꿔주는 래퍼(d3d9-webgl)를 중간에 끼워 넣는 겁니다. 게임 코드는 여전히 Direct3D에 명령을 보내고 있다고 생각하지만, 실제로는 브라우저 위에서 돌아가는 구조입니다.

렌더링 외에도 서버, 사운드, 입력, 파일 시스템까지 윈도우 전용으로 묶여 있던 것들을 하나씩 브라우저 표준으로 교체했습니다. 음성 파일 포맷을 바꾸는 것만으로 전체 에셋 용량을 88% 줄였고, 결국 링크 하나로 10초 안에 플레이 가능한 상태가 됐습니다.

무엇을 얻어가야 하나요?

이 프로젝트에서 진짜 배울 점은 기술이 아닙니다. blueocean님은 WebGL이나 Direct3D를 잘 몰랐습니다. 그 기술을 몰라도 성공할 수 있었던 이유가 여기 있습니다.

핵심은 두 가지입니다. 하나는 문제를 어떻게 쪼개느냐입니다. 게임 전체를 다시 짜는 게 아니라 번역 레이어 하나를 만드는 문제로 바꾸는 순간, 불가능해 보이던 것이 풀리기 시작했습니다. 다른 하나는 타이밍입니다. 몇 년 전에는 이 번역 레이어를 직접 짜야 했지만, 지금은 AI가 대신 써줍니다. 같은 아이디어가 지금은 실행 가능한 프로젝트가 된 겁니다. 오래 미뤄온 프로젝트가 있다면 다시 꺼내볼 이유가 생겼습니다. 코드를 AI가 써주는 지금, 필요한 건 기술이 아니라 문제를 잘게 쪼개는 능력입니다.

대박입니다

게임은 gunz.sigr.io에서 직접 플레이해볼 수 있습니다. 더 깊은 기술적 맥락과 이식 과정이 궁금하다면 아래 원문을 꼭 읽어보시길 추천합니다. 일본어 원문과 한국어 번역글 모두 같은 분이 직접 작성한 것 같습니다!

일본어 원문 (Zenn): https://zenn.dev/aespa/articles/c9156ae9771367
한국어 번역글 (벨로그): https://velog.io/@aespa/claude-code-gunz-the-duel-web-port
원작자 트위터: https://twitter.com/LostMyCode

<출처: 요즘IT 작가 그릇>

3. 적용해볼 것: MCP로 Claude Code 디자인 감도 높이기

마지막으로 소개할 인사이트는 요즘IT 작가 그릇님의 글입니다. MCP를 연결해 Claude Code로 앱 디자인 감도를 끌어올린 과정을 직접 경험하고 공유한 내용인데요. Claude Code의 까만 터미널 창이 낯설어 커서나 Antigravity로 돌아갈까 고민했던 분이, MCP를 연결하면서 메인 도구로 전환하게 된 이야기입니다.

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

그릇님이 느낀 문제는 바이브 코딩으로 만든 결과물이 어떤 도구를 쓰든 비슷비슷하게 느껴진다는 것이었습니다. 특히 Claude Code로 만든 결과물이 평범하게 보였고, 원하는 감성과 다른 차가운 블루 톤의 UI가 나왔죠. Stitch로 UI 디자인을 만들어 연결했지만, 키 비주얼을 잡는 데는 한계가 있었다고 합니다.

어떻게 해결했나요?

그릇님의 목표는 웰다잉 앱이었습니다. 죽음 준비가 아니라 삶의 기록이라는 메시지를 담아야 했고, 따뜻한 느낌이 필요했습니다.

먼저 Claude Desktop에 블렌더 MCP를 연결해서 3D 오브제를 만들었습니다. Claude가 별빛 조약돌이라는 키워드를 제안했고, 삶이 끝나는 게 아니라 별이 되어 빛난다는 핵심 메시지와 함께 골드 빛 조약돌을 블렌더로 렌더링했습니다. 3D 툴을 한 번도 써본 적 없었지만, 프롬프트에 오브제 형태, 재질, 조명까지 구체적으로 설명하면 Claude가 블렌더 안에서 직접 세팅하고 렌더링해줬다고 했습니다.

다음으로 Stability AI MCP를 연결해 앱 전체의 컨셉 이미지와 키 비주얼을 만들었습니다. 단순히 이미지를 뽑는 게 아니라 배경 제거, 스타일 조정, 업스케일을 한 대화 안에서 연결해 워크플로로 자동화할 수 있었다고 하죠.

마지막으로 Claude Code에 Figma와 Stitch MCP를 연결했습니다. 블렌더와 Stability AI로 만든 결과물을 Figma에서 컴포넌트로 정리한 뒤, Claude Code에 Figma 스펙에 맞춰 동기화하고 전체 UI에 반영해줘라고 요청해서 최종 완성했습니다.

MCP 연결 순서 요약

블렌더 MCP → Claude Desktop 연결, 3D 키 비주얼 제작
Stability AI MCP → Claude Desktop 연결, 컨셉 이미지 및 배경 생성
Stitch MCP → Claude Code 연결, 초기 UI 컴포넌트 구성
Figma MCP → Claude Code 연결, 디자인 토큰 동기화 및 전체 UI 반영

적용해볼 질문

지금 만들고 있는 프로덕트에서 디자인이 기능을 따라가지 못하고 있는 부분이 있나요? 그릇님의 경험처럼 MCP를 연결하면 디자인 방향을 바꾸더라도 컴포넌트를 전체 화면에 일관되게 적용할 수 있습니다. 프롬프트에 기능 명세만 넣는 게 아니라 어떤 감정을 전달할지, 어떤 메시지를 담을지까지 써봤나요? 같은 기능의 앱이라도 디자인에 따라 사용자가 느끼는 감정이 달라질 수 있습니다.

실행해볼 수 있는 것

Claude Code를 쓰고 있다면 /mcp 명령어로 현재 연결된 MCP 목록을 확인해보세요. Figma나 Stitch MCP가 없다면 하나만 연결해서 디자인 파일을 Claude Code가 직접 읽게 해보세요.
블렌더 MCP는 연결 과정이 복잡한 편이지만, 연결되고 나면 3D 툴 경험 없이도 대화만으로 결과물을 만들 수 있습니다. 스미더리, 컴포시오, mcp.so에서 필요한 MCP를 검색하면 설치 명령어를 바로 받을 수 있습니다.

그릇님이 직접 겪은 시행착오와 더 구체적인 프롬프트가 궁금하다면 요즘IT 원문을 꼭 읽어보시길 추천합니다.

이렇게 적용해보세요

Claude Code를 쓰고 있다면 cc.storyfox.cz를 북마크해두세요. 명령어를 찾는 데 쓰는 시간이 줄어듭니다.
오래 미뤄온 프로젝트가 있다면 다시 꺼내보세요. AI가 코드를 쓰는 역할을 맡으면서 예전에는 혼자 하기 어려웠던 것들의 문턱이 낮아졌습니다. 건즈 이식 프로젝트처럼 때가 올 때까지 기다렸다가 지금 실행하는 것도 전략입니다.
Claude Code로 만드는 결과물이 비슷비슷하게 느껴진다면 MCP 연결부터 해보세요. 어떤 감정을 전달할지를 프롬프트에 담고, 디자인 도구와 직접 연결하면 결과물이 달라집니다.

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

]]>

개발자를 위한 Claude Code 토큰 사용량 최적화 전략

Claude Code를 효율적으로 활용하려면 모델이 정보를 처리하는 방식과 컨텍스트 한계를 명확히 이해해야 합니다. Claude Code를 사용하다가 점점 응답이 느려지거나 엉뚱한 대답을 들어본 경험은 모두에게 있을 겁니다. 이는 모델이 텍스트를 인식하는 최소 단위인 '토큰'의 한계에 도달했기 때문일 확률이 높습니다. 이 글에서는 Claude Code가 어떻게 컨텍스트를 관리하는지 파악하고, 불필요한 토큰 낭비를 막는 토큰 최적화 실전 가이드를 알려 드리겠습니다.

토큰의 기본 개념 이해하기

Claude Code를 사용할 때 가장 먼저 이해해야 할 개념은 바로 토큰입니다.

토큰이란

AI 모델은 텍스트를 그대로 처리하지 않고, 내부의 토크나이저(tokenizer)라는 변환 프로그램을 사용해 단어, 구두점, 기호, 공백 등을 잘게 나눈 최소 단위로 변환합니다. 이 단위를 토큰(token)이라 합니다.

다음 예시를 보면 토큰의 개념을 직관적으로 이해할 수 있습니다.

영어: "Claude Code is an excellent tool." → ["Claude", " Code", " is", " an", " excellent", " tool", "."] → 약 6~7토큰
한글: "Claude Code는 훌륭한 도구입니다." → ["Claude", " Code", "는", " 훌륭", "한", " 도구", "입니다", "."] → 조사, 형용사, 어미가 분리되어 약 8~10토큰

한글은 조사, 어미, 복합어 구조 때문에 영어보다 토큰 수가 더 많아지는 경향이 있습니다. 따라서 짧고 명확한 문장일수록 토큰 효율이 좋아지고 모델이 컨텍스트를 더 정확히 파악할 수 있습니다.

입력 토큰과 출력 토큰

Claude Code에서 토큰은 크게 두 종류로 구분합니다.

1. 입력 토큰

사용자가 모델에 전달하는 모든 텍스트를 입력 토큰(input token)에 포함합니다. 이때, 사용자가 보지 못하는 내부 정보까지 모두 토큰으로 계산합니다.

사용자의 요청 메시지
세션 대화 이력
CLAUDE.md
시스템 프롬프트 예 모델 동작 규칙
도구 정의 예 MCP 스키마 등
@로 참조한 코드나 문서

2. 출력 토큰

Claude가 새로 생성하는 모든 텍스트를 출력 토큰(output token)으로 계산합니다.

Claude의 응답 문장
자동 생성된 코드
분석 결과문
수정된 diff 내용

입력과 출력의 합계가 총 사용 토큰이며, 이는 곧 비용과 응답 속도에 직접적인 영향을 줍니다.

컨텍스트에 포함되는 실제 구성 요소

Claude Code는 입력된 문자 수만 세지 않습니다. 실제로는 사용자의 요청 문장뿐 아니라, 그 요청을 처리하 데 필요한 대화 이력, CLAUDE.md, 도구 정의, 참조된 파일 내용까지 모두 토크나이저를 통해 토큰으로 변환합니다. 따라서 한 번 요청을 보내면 겉으로 보이는 텍스트보다 훨씬 많은 정보가 모델에 전달되고, 이 모든 요소가 입력 토큰으로 계산됩니다.

따라서 다음 요청처럼 매우 짧아도 실제 입력 토큰은 수만 개일 수 있습니다.

이 점을 이해해야 컨텍스트를 과도하게 사용하는 상황을 예방할 수 있습니다.

토큰 사용량 확인 방법

Claude Code에서는 다음과 같은 방식으로 토큰 수를 확인할 수 있습니다.

1. /context 명령으로 컨텍스트 사용량 확인하기

대화형 세션에서 /context 명령을 실행하면 시스템 프롬프트, 시스템 도구, 메모리 파일, 메시지 등을 포함해 현재 세션의 모든 컴포넌트별 토큰 사용량을 표시합니다.

2. 로그 파일에서 직접 확인하기

Claude Code는 모든 대화 기록을 ~/.claude/projects/ 폴더에 JSONL 형식으로 저장합니다. 각 메시지의 usage 필드에 포함된 input_tokens, output_tokens 값을 확인할 수 있습니다.

3. 웹 기반 토큰 계산기 사용하기

별도의 웹 도구를 이용해 텍스트를 직접 입력하고 토큰 수를 확인할 수도 있습니다.

token-counter.app/anthropic: 웹 브라우저에서 직접 토큰 계산
claude-tokenizer.vercel.app: Anthropic의 token counting API 기반 토큰 계산기

토큰 사용 최적화 전략

Claude Code를 효율적으로 활용하려면 토큰을 어디에서, 어떻게 소비하는지 이해해 불필요한 낭비를 줄이는 것이 중요합니다.

CLAUDE.md를 간결하게 유지하기

CLAUDE.md는 요청마다 함께 로드되는 핵심 문서입니다. 내용이 길수록 컨텍스트 초기 비용이 불필요하게 증가하므로 다음 원칙을 적용해 문서를 최소화하는 것이 좋습니다.

1. 비효율적인 예시(약 5,000토큰)

프로젝트 설명을 장황하게 서술
기술 스택을 여러 문단으로 중복 표현
코딩 규칙을 장문으로 상세 기술

2. 개선된 예시(약 700토큰)

기술 스택, 폴더 구조, 핵심 규칙만 간단히 요약
불필요한 문장 제거, 헤딩/리스트 중심 재구성

최적화 전략은 다음과 같습니다.

“이 프로젝트는…”과 같은 서술형 문장 제거
헤딩, 리스트, 테이블을 사용해 구조화
규칙은 최소 단위로 축약
코드 예시는 과도하게 포함하지 않기

이 원칙만 적용해도 문서 크기를 80~90%까지 줄일 수 있습니다.

분산 메모리 구조

CLAUDE.md가 지나치게 길어지는 경우, 내용을 여러 보조 문서로 분리한 뒤 필요할 때만 불러오는 방식이 효과적입니다. 이 방식은 Claude가 기본 컨텍스트를 가볍게 유지한 채, 요청 시 필요한 문서만 추가로 읽도록 합니다.

예시 구조

⊥ CLAUDE.md

⊥ docs/api-guide.md

⊥ docs/db-guide.md

⊥ docs/deploy-guide.md

이런 구조를 사용하면 다음과 같은 장점이 있습니다.

토큰 절약: 기본 컨텍스트가 가벼워져 Claude가 불필요한 정보를 동시에 유지하지 않아도 됨
유지보수 용이: 문서가 기능별, 역할별로 나뉘어 있어 특정 영역만 수정하거나 업데이트하기가 수월함
가독성 향상: 한 파일에 모든 내용을 담지 않아 필요한 정보를 더 빠르고 정확하게 찾을 수 있음

MCP 도구는 필요한 것만 사용하기

MCP(Model Context Protocol) 서버를 설치하면 각 도구 정의가 컨텍스트에 로드됩니다.

GitHub, Web Search, Database, Playwright 등을 모두 활성화하면 최대 1만 토큰 이상이 시스템 영역에서 추가될 수 있습니다. 최적화 전략은 다음과 같습니다.

현재 작업에 필요한 MCP만 활성화 (예) 프런트엔드 작업에는 Playwright만, 백엔드 작업에는 Database MCP만
프로젝트별 .config/claude/config.json 파일에서 불필요한 MCP 비활성화
정기적으로 MCP 목록을 점검해 미사용 항목 제거

이렇게 관리하면 컨텍스트 공간 5~7% 정도를 즉시 확보할 수 있습니다.

대화 메시지 관리하기

대화 이력은 컨텍스트에서 가장 빠르게 증가하는 영역입니다. 다음 세 가지 원칙만 지켜도 토큰 낭비를 크게 줄일 수 있습니다.

1. 불필요한 왕복 줄이기

utils.py 파일을 읽어줘. → 잘 읽었어? → 수정해줘. (×)
utils.py의 get_user 함수를 읽고 성능을 개선해줘. (○)

2. 비슷한 요청은 하나의 배치로 묶기

Header, Footer, Sidebar를 각각 다크 모드를 적용해줘. (×)
components 폴더의 Header, Footer, Sidebar에 공통으로 다크 모드를 적용해줘. (○)

3. 모호한 요청 피하기

로그인 기능을 수정해줘. (×)
.auth.py에서 JWT 토큰 만료 시간을 1시간에서 24시간으로 늘려줘. (○)

명확하고 구조화된 요청이 가장 강력한 토큰 절약 도구입니다.

파일 참조는 필요한 부분만

@ 기호를 사용해 파일을 참조하면 내용 전체가 컨텍스트에 포함되므로 큰 파일을 무조건 통째로 읽는 방식은 비효율적입니다. 권장하는 방식은 다음과 같습니다.

500줄 이하: 전체 참조 가능
500~2,000줄: 필요한 구간만 지정
2,000줄 이상: 함수나 클래스 단위로 분리

세션 길이 관리하기

한 세션이 길어질수록 컨텍스트가 누적되어 속도와 비용이 모두 증가합니다. 따라서 기능 단위로 세션을 나누거나 멀티 세션 방식으로 작업을 분리하면 효율이 높아집니다.

1. 기능 단위로 세션 구분

인증 기능 구현: /compact 실행
프로필 기능 구현: /compact 실행
완전히 다른 프로젝트: /clear로 초기화

2. 멀티 터미널 전략

터미널 1: 백엔드 전용
터미널 2: 프런트엔드 전용
터미널 3: 문서화 및 배포

서로 다른 작업을 물리적으로 분리하면 컨텍스트 충돌을 방지하고 메모리 효율이 증가하는 장점이 있습니다.

실전 최적화 흐름

Claude Code의 토큰, 컨텍스트 최적화 전략을 단계별로 요약하면 다음과 같습니다.

1.큰 작업은 먼저 계획부터 요청해 접근 범위 정리하기
아키텍처 변경, 인증 로직 교체처럼 범위가 큰 작업은 곧바로 수정하지 말고 먼저 계획을 요청해 변경 파일, 순서, 리스크를 정리합니다.

2. /context로 사용량 점검하기
/context 명령으로 현재 세션의 토큰 사용량을 확인합니다. 예를 들어 200K토큰 컨텍스트 윈도우에서 기본 세션이 약 20K토큰(10%)을 사용하고, 나머지 180K토큰을 실제 작업에 사용할 수 있습니다. 컨텍스트는 디스크 공간처럼 작업하면서 채워지므로 정기적으로 확인하면서 관리하는 것이 중요합니다.

3. 복잡한 작업의 문서화와 /clear 사용하기
대규모 작업의 경우 진행 상황을 마크다운 파일로 저장하게 한 뒤 /clear로 컨텍스트를 초기화하고, 새 세션에서 해당 파일을 읽어 작업을 이어가는 방식이 효과적입니다.

4. 프롬프트 캐싱으로 비용 절감하기
Claude Code는 자동으로 프롬프트 캐싱을 활성화해 반복되는 요청의 비용을 절감합니다. 캐시된 콘텐츠를 사용하면 기본 입력 토큰 가격의 10%만 부과되어 최대 90%의 비용을 절감하고 지연 시간을 85% 줄일 수 있습니다.

3번. 복잡한 작업의 문서화와 /clear 사용하기

토큰 사용 최적화 전략은 Claude Code를 똑똑하게 쓰기 위한 첫걸음입니다. 현재 사용 흐름을 점검하고, 토큰 최적화 전략을 단계적으로 적용해 보시기 바랍니다.

이 글은 길벗에서 출간된 책 <AI 자율학습 클로드 코드·코덱스 CLI·제미나이 CLI 완전 활용법> 에서 발췌·편집한 글입니다. 원문은 [여기]에서 볼 수 있습니다.

]]>

하네스 경쟁의 시작, 왜 opencode와 OMO일까?

모델 경쟁이 끝나고, ‘하네스 경쟁’의 시작?!

LLM을 평가하는 기준은 빠르게 바뀌고 있습니다. 이제는 “모델이 얼마나 똑똑한가”만으로 체감 품질을 설명하기 어렵습니다. 실제 현업에서의 생산성은 긴 작업을 얼마나 안정적으로 이어갈 수 있는지, 그리고 도구·컨텍스트·검증 루프를 얼마나 잘 운영하는지에 따라 갈립니다.

LLM의 스케일링 법칙(Scaling Laws)은 이제 한계라는 의견이 많습니다. (참조 링크) 더욱이 SLM을 특정 작업에 맞춰 최적화하고, 고품질 데이터로 재학습시키며, 나아가 MoE 구조로도 활용합니다. 특히 신규 LLM 모델은 실제로 “체감할 수 있는 차이”에 있어서, “구체적으로, 그리고 정량적으로 우리의 작업이 얼마나 나아졌는가”를 설명하기가 매우 어려워졌습니다.

모델 경쟁이 끝난 것은 아닙니다. 하지만 차별화의 중심축은 이미 윗단 레이어로 올라가고 있습니다. 특히 코딩, 리서치, 마이그레이션, 대규모 리팩토링처럼 길고 복잡한 작업에서는 “한번 잘 답하는가”보다 “끝까지 안정적으로 완주하는가”가 훨씬 중요합니다. 그리고 그 완주 능력을 만들어내는 것이 바로 에이전트 하네스(Agent Harness)입니다.

<출처: 작가, AI 생성>

하네스란?

에이전트 하네스는 AI 모델을 감싸고, 장기적이거나 복잡한 작업을 안정적으로 수행하도록 관리하는 운영 인프라에 가깝습니다.
모델이 문장을 생성하는 엔진이라면, 하네스는 그 엔진 위에 올라가는 차량의 프레임, 조향 장치, 브레이크, 계기판처럼 사람의 승인 지점, 파일 시스템 접근 제어, 도구 호출 순서, 하위 에이전트 협업, 프롬프트 프리셋, 실패 복구까지 묶어 실제로 “작동하는 시스템”으로 만드는 레이어(layer)입니다. (참조: 2025 Was Agents. 2026 Is Agent Harnesses. Here’s Why That Changes Everything.)

‘Opencode’란?

1) 정의 및 배경

OpenCode는 스스로를 오픈소스 AI 코딩 에이전트로 소개하며, 터미널 기반 인터페이스, 데스크톱 앱, IDE 확장 형태로 사용할 수 있습니다. LSP 지원, 멀티 세션, 세션 공유 링크, 다양한 모델 프로바이더 연결을 핵심 특성으로 내세웁니다. 즉 OpenCode는 단순한 “채팅형 코딩 도구”라기보다, 에이전트를 실행하는 런타임에 더 가깝습니다.

LSP 기반 코드 이해(심볼/정의/진단 등)
멀티 세션(작업별 세션 관리)
플러그인 지원(동작 확장)
결과 공유(링크 공유) 및 팀 사용 시나리오

즉, OpenCode 자체가 이미 “에이전트 실행기 + 도구 런타임 + 세션 관리자” 성격을 갖고 있고, 그 위에 플러그인을 얹어 하네스 역량을 키우는 구조입니다.

2) 작동 원리

아주 기본적인 개념은 "다양한 LLM 들을 하나의 tool에서 모아서 사용"이라는 점에서 크게 다르지 않습니다. 세션 단위로 작업 컨텍스트를 유지하며, 사용자는 TUI에서 입력/전환/실행을 수행합니다. (실행 시 TUI와 HTTP 서버가 함께 뜨는 client/server architecture)

<출처: 작가 캡처>

최근에는 mode 보다 agent 구성이 중심이지만, 사용 경험상 여전히 많은 분들이 Build 와 Plan 을 “모드”처럼 이해하고 있습니다. (물론 저도요.)

내장 primary agent는 Build 와 Plan 이고, subagent로는 General 과 Explore 가 제공됩니다. (근데 다들 각자 플러그인을 많이 사용하다 보니 순정을 보기 힘들어진 기분)

Build 는 일반 개발 작업용으로 모든 도구 접근이 열려 있고, 실제 편집, 패치, 명령 실행, 검증에 적합합니다.
Plan 은 파일 수정과 bash 실행을 제한하거나 승인 기반으로 다뤄 분석과 설계 중심으로 쓰이도록 설계되어 있고, 분석, 설계, 변경안 검토, 위험 식별에 적합합니다. (기본적으로 파일 수정과 bash 실행이ask 로 제한됨)
General 은 범용적이게 사용하고,Explore 는 읽기 & 탐색 중심!
또 내부적으로는 compaction, title, summary 같은 숨겨진 시스템 에이전트가 자동 실행된다고 합니다.

사실 이런 접근은 이제 아주 일반화가 된 것 같습니다. 저 역시 바이브 코딩과 LLM에 대한 대규모 서베이, Augmented Coding 글과 같이 "plan"의 중요성을 매우 체감하고 있습니다.

사실 권한 제어와 LSP control이 핵심

권한 제어와 도구들의 디테일

권한은 allow, ask, deny로 제어되고
read, edit, bash, task, lsp, webfetch, websearch, codesearch 같은 항목별로 통제한다고 합니다.
grep, glob, list 는 내부적으로 ripgrep 을 사용하며, .gitignore 를 따른다고 하며 (디테일), 사실 LLM 기반으로 마치 Re-ACT agent, tool calling 처럼, 도구 호출 중심 실행 프레임워크로 만들어졌다고 보는 게 맞습니다.

LSP(Language Server Protocol)

LLM이 코드베이스와 상호작용 할 때 진단 정보(diagnostics)를 활용합니다. 또한 여러 언어에 대해 내장/자동 설치 LSP를 제공한다고 합니다.
그래서 OpenCode는 단순히 파일 내용을 긁어서 모델에 던지는 수준이 아니라, 정적 분석 계층의 피드백까지 모델 루프 안으로 넣는 구조입니다. (그래서 토큰이 녹아내릴 수 있죠.)

<출처: 작가, AI 생성>

3) 플러그인 시스템: 하네스가 붙는 자리

플러그인은 JavaScript/TypeScript "모듈 형태로 훅"을 내보내며, 로컬 플러그인 디렉터리 또는 npm 패키지 방식으로 로드할 수 있습니다.

로컬 파일: 프로젝트/전역 플러그인 디렉터리에 JS/TS 배치
npm 패키지: opencode.json의 plugin 배열에 패키지명을 등록

npm 플러그인은 시작 시 Bun으로 자동 설치되며, 캐시는 ~/.cache/opencode/node_modules/ 에 default로 저장됩니다.

로드 순서는 [전역 config → 프로젝트 config → 전역 dir → 프로젝트 dir] 입니다. 에이전트 하네스 쪽은 보통 설정 충돌, 훅 순서, 컨텍스트 주입 순서 때문에 디버깅이 어려운데, OpenCode는 적어도 플러그인이 어디서, 어떤 순서로 붙는지를 문서화해 둔 편입니다. 그래서 플러그인 생태계가 잘 만들어질 수 있었던 것 같습니다.

4) 설치 & 세팅

다만 작성일 기준이라, 공식 홈페이지를 한 번 참고하시는 게 좋습니다. 최근에는 데스크톱 앱이 나온 것 같은데요.

curl -fsSL https://opencode.ai/install | bash

역시 인기 있는 tool은 설치와 세팅이 아주 간단합니다. 설치 후 opencode 로 실행이 끝입니다. 이후 /connect 커맨드 활용해서 "프로바이더 (상용 LLM 포함 외부 LLM auth 세팅)" 세팅까지 이어가면 바로 사용 가능합니다.

<출처: 작가 캡처>

‘OMO: Oh-my-opencode’란?

1) 정의 및 배경

Oh My OpenCode는 공식 사이트에서 스스로를 “OpenCode 위에 올라가는 specialized orchestration layer”라고 설명합니다. OMO는 OpenCode를 대체하는 별도 제품이 아니라, OpenCode 위에 에이전트, 훅, MCP, LSP, 설정값을 묶어 더 강한 운영 구조를 제공하는 플러그인입니다.

그냥 “코드를 잘 써주는 도구”가 아니라,

복잡한 빌드 파이프라인 이해
다수 에이전트 병렬 실행
컨텍스트 관리
작업 지속성
세션 복구
문서 검색과 코드 탐색 자동화

를 기반으로 "잘 굴러가게 만드는 하네스" 를 지향합니다. "AI 팀"에 비유하며, 다수의 전문 에이전트(역할 분업), 스킬(워크플로 템플릿), 커맨드(/refactor 등), 훅(키워드 감지/복구/알림/컨텍스트 주입)을 묶어서 제공한다고 설명합니다. (플러그인 공식 깃헙 레포, 관련 긱뉴스, 제작자 유튜브 인터뷰(팟캐스트))

<출처: 작가, AI 생성>

2) Oh-My-OpenCode의 “각 모드”는 무엇이며, 언제 쓰는가?

OMO는 기본적으로 Planner-Sisyphus, Librarian, Explore, Oracle 같은 전문 에이전트를 제공합니다. Sisyphus를 기본 오케스트레이터로 설명하고, Prometheus, Metis 같은 계획 보조 에이전트, 그리고 frontend-ui-ux-engineer, document-writer, multimodal-looker 같은 역할 특화 에이전트가 있습니다.

다수 에이전트를 “AI 팀”으로 제공

Sisyphus: 기본 오케스트레이터(계획·위임·실행)
Prometheus / Metis / Momus: 계획 수립·사전 점검·계획 리뷰
Oracle / Librarian / Explore: 설계·문서/OSS 리서치·코드베이스 탐색(쓰기 제한)
document-writer: README, API 문서, 가이드 작성
multimodal-looker: PDF/이미지/다이어그램 분석

@ 를 통해서 에이전트를 타겟할 수 도 있습니다.

<출처: 작가 캡처>

3) ultrawork, search, analyze는?

이게 지금의 OMO를 만들어준, 하이라이팅될 수 있던 feature들이 아닐까 싶습니다. OMO는 "키워드 기반 감지"로 하네스가 작동이 됩니다. ultrawork 또는 ulw 는 최대 성능 모드, search 또는 find 는 병렬 탐색 모드, analyze 또는 investigate는 심층 분석 모드로 안내됩니다. 또 think deeply, ultrathink 같은 표현은 think mode 훅이 감지해 추론 설정을 조정한다고 합니다.

사용자가 “이번 작업의 성격”만 잘 말해도 하네스가 행동 방식을 바꿔주기 때문입니다. 즉, 프롬프트가 단순 지시문이 아니라, 오케스트레이션 정책을 바꾸는 신호가 됩니다.

ultrawork/ulw = 최대 성능 모드

ultrawork, 줄여서 ulw는 OMO README에서 사실상 “마법의 단어”처럼 소개됩니다. 공식 README 표현을 정리하면, 병렬 에이전트 실행, 백그라운드 작업, 적극적 탐색, 완료까지 밀어붙이는 성격을 가진 최대 성능 모드입니다. 대규모 리팩토링, 복잡한 마이그레이션, 여러 파일과 여러 축의 검증이 동시에 필요한 작업에 잘 맞습니다.

작업 범위가 크고(리팩토링/마이그레이션/대규모 기능 추가)
실패 비용이 높고(프로덕션/핵심 모듈)
여러 축(리서치·코드·테스트·문서)을 병렬로 돌려야 할 때

기본 오케스트레이터가 작업을 분해하고, 전문 에이전트를 공격적으로 병렬 실행하는 성격으로 설계돼 있다고 설명합니다. 즉 자체적으로 "각 업무 전문가에게 일을 할당하고, 평가하고, 리팩토링하고 등이 모두 묶여있습니다. (다음 섹션에서 저는 어떻게 ulw를 사용하는지 정리해 뒀습니다.)

search/find = 병렬 탐색 모드

이 모드는 빠른 코드베이스 탐색이 핵심입니다. OpenCode의 내장 Explore 가 원래 읽기 전용 탐색 성격을 갖고 있는데, OMO는 이런 탐색 성격을 더 공격적으로 활용합니다. 레거시 프로젝트 진입점 찾기, 설정 파일 찾기, 실제 호출 경로 파악, 특정 동작이 어디서 시작되는지 확인할 때 특히 유용합니다.

레거시 프로젝트 온보딩
특정 동작의 진짜 진입점/호출 경로를 찾아야 할 때
설정 파일/핵심 클래스/핫스팟 파일을 빠르게 식별해야 할 때

analyze/investigate = 심층 분석 모드

이 모드는 구현보다 해석과 판단에 가깝습니다. 장애 원인 분석, 설계 리뷰, 트레이드오프 비교, “왜 이런 구조가 되었는가”를 증거 기반으로 정리할 때 잘 맞습니다. 공식 사이트의 Oracle 소개와 README 설명을 합치면, 코드 설명과 문제 진단, 아키텍처 판단을 보조하는 방향으로 이해할 수 있습니다.

장애 재현이 어렵거나, 원인이 여러 후보로 갈릴 때
설계 결정을 내려야 하는데 트레이드오프가 복잡할 때
“왜 이 로직이 이렇게 됐는지”를 증거 기반으로 정리해야 할 때

문서는 oracle을 “아키텍처 결정/코드 리뷰/디버깅(읽기 전용)” 상담역으로 설명합니다.

think mode

Think mode는 구현 이전 사고 비용을 늘리는 장치입니다. “바로 고치지 말고 먼저 깊게 생각해라”라는 의도를 하네스 차원에서 반영합니다. 문제 정의가 불분명하거나, 정책과 SDK 제한을 함께 검토해야 하거나, 근거를 모아 판단해야 할 때 특히 유효합니다.

구현 이전에 문제 정의/요구사항 정리/리스크 식별이 필요할 때
장단점/대안 비교가 본질일 때
문서·정책·SDK 제한 때문에 “확실한 판단”이 필요한데 근거를 모아야 할 때

think-mode 훅이 관련 키워드를 감지해 모델 설정(extended thinking 등)을 조정한다고 명시합니다. (사견으로는 생각 자체에 회귀할 때가 있어서 적절한 결론에 대한 신호 체계를 만드는 게 좋습니다.)

4) 설치 & 세팅

물론 OpenCode 설치가 무조건 선행되어야 합니다. 하지만, 역시 간단합니다. (bun 런타임이 필요합니다.)

bunx oh-my-opencode install

그러면 세팅 가이드가 자동으로 안내해 줍니다.

<출처: 작가 캡처>

실제 사용 예시 살펴보기

일단 하나의 예시를 보면,

<출처: 작가 캡처>

<출처: 작가>

OMO의 ulw 는 진짜 한 줄만 줘도 진정한 의미의 바이브 코딩을 합니다. "딸깍"이 가능하죠. 근데 제가 여전히 구시대적인 사람인지 몰라도 저는 이게 너무 와닿지 않습니다. 통제 가능성과 일관성, 규칙이 저에게는 너무 중요하기 때문이죠.

1) 일단 플젝 세팅부터 제대로

1. 무엇을 만들어야 하는지 결정된다면stack부터 정합니다.

이땐 리서치와 대화형 LLM만 사용합니다. 사실 통제 가능성이 중요하기에 제가 익히 잘 아는 stack에서 잘 벗어나지 않습니다.
대부분 ts, react + nextjs, nestjs, python, django + drf or ninja ... 가끔 rust 섞음
아직까진 모노레포를 선호하지는 않습니다. 최근에 모노레포로 한 번 했다가 AI markdown 세팅이나 AI rule 세팅이 더 복잡해져서 바로 버렸습니다.

2.AGENTS.md(CLAUDE.md 등 포함) 부터 출발합니다.

요즘은 /init으로 직접 이 마크다운을 만드는 경우가 많지만, 저는 여전히, Augmented Coding에서 차용한 TDD와 Tidy code를 아주 적극적으로 사용합니다.
그래서 AGENTS.md 에는 "논리적인 방법론" 들을 정리합니다. 기본적인 역할, TDD, Tidy First, Quality 등에 대해서요.
디렉토리나 스택, 언어 등을 언급하지 않고, 대신 "SYSTEM_DESIGN.md 꼭 참조해라!"라는 인디케이터만 넣습니다.

3.SYSTEM_DESIGN.md를 만듭니다.

일례로 아래와 같습니다. 제가 python으로 작업할 땐 꼭 아래 시스템 디자인으로 출발합니다. 포인트는 Do not over-apply design patterns입니다.

# SYSTEM_DESIGN

This document defines the core system design rules for this project.

---

## 1. Python Version & Typing

- We use **Python 3.13 or higher**.
- Do **not** use the `typing` module for type hints.
- Always use **built-in types** for annotations (e.g., `int`, `str`, `list`, `dict`, etc.).

---

## 2. Code Style

- Follow the **Google Python Style Guide**:
  - <https://google.github.io/styleguide/pyguide.html>
- Follow **PEP 8** (Python’s official style guide):
  - <https://peps.python.org/pep-0008/>

If there is any conflict between local conventions and these guides, prefer clarity and consistency within this project.

---

## 3. Object-Oriented Design

We favor **object-oriented programming (OOP)** and its core principles:

- **Encapsulation** – Group related data and behavior inside classes and hide internal details.
- **Abstraction** – Expose clear interfaces and hide unnecessary implementation details.
- **Inheritance** – Reuse behavior via well-designed base classes and subclasses when appropriate.
- **Polymorphism** – Design interfaces so that different implementations can be used interchangeably.

OOP should improve readability and maintainability, not add unnecessary complexity.

---

## 4. Architectural Pattern

- We **aim for a layered architecture pattern** (e.g., presentation, application/service, domain, infrastructure).
- Each layer should have a clear responsibility and minimal knowledge of other layers.

At the same time:

- Do **not** over-apply design patterns or split the codebase into too many tiny files.
- Avoid “architecture for architecture’s sake.”
- Aim for:
  - **Reasonable maintainability**
  - **Reasonable separation of concerns**
  - **Always pragmatic, balanced design**

In short, we prefer a **practical, moderately layered architecture** that is easy to understand, extend, and maintain, rather than a theoretically "perfect" but over-engineered structure.

이 파일에서 저는 "물리적인 방법론" 과 실제 구현 방향에 대해 정확하고 구체적으로 정리합니다.
특히 python 은 "빠르게, 저렴하게" 라는 측면에서 바이브코딩과 아주 맞닿아 있지만, 언어 특성때문에 볼륨이 조금만 커져도 무너져 내리더라구요. 1부터 10개 작업하면, 2번과 9번의 코드 스타일이 완전하게 달라지는 이슈도 빈번했구요.
그래서 type 을 꽤나 엄격하게 다루는데, mypy 보다는 pyright 가 좀 더 유연한 측면에서 맞는 것 같네요.

4.pre-commit,ruff(eslint & prettier),test(pytest, jest)세팅을 바로 합니다.

저는 uv + ruff 으로 아래 기본 세팅은 하고 갑니다. 스크롤이 너무 길어져서 뺄까 했는데, 혹시나 다른 분들을 위해 설정값을 공유합니다.

(아래 pre-commit)

ci:
  autoupdate_schedule: monthly

default_language_version:
  python: python3.13

repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v6.0.0
    hooks:
      - id: check-yaml
      - id: check-toml
      - id: check-added-large-files
      - id: check-merge-conflict
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.15.0
    hooks:
      - id: ruff
        args: [--fix, --exit-non-zero-on-fix]
      - id: ruff-format

  - repo: https://github.com/astral-sh/uv-pre-commit
    rev: 0.10.2
    hooks:
      - id: uv-export
        args:
          - --frozen
          - --no-dev
          - --no-hashes
          - --output-file=requirements.txt
          - --quiet

(아래 toml에서 기본 설정들)

# ================================================================
# Ruff (Linter & Formatter) Settings
# ================================================================
[tool.ruff]
# 수정에서 제외할 파일 및 디렉토리 목록
exclude = [
    ".bzr",
    ".direnv",
    ".eggs",
    ".git",
    ".hg",
    ".mypy_cache",
    ".nox",
    ".pants.d",
    ".pytype",
    ".ruff_cache",
    ".svn",
    ".tox",
    ".venv",
    "__pypackages__",
    "_build",
    "buck-out",
    "build",
    "dist",
    "node_modules",
    "venv",
    "*/migrations/*.py",
]
# 한 줄의 최대 글자 수
line-length = 100

# --- Linter (코드 분석기) 설정 ---
[tool.ruff.lint]
# 활성화할 규칙 선택:
# E, W: pycodestyle (에러, 경고)
# F: Pyflakes (논리적 오류)
# I: isort (import 정렬)
select = ["E", "F", "W", "I"]
ignore = []

# 모든 수정 가능한 규칙을 자동으로 고치도록 설정
fixable = ["ALL"]
unfixable = []

# --- Formatter (코드 포맷터) 설정 ---
[tool.ruff.format]
# Black과 유사한 포맷팅 스타일을 따릅니다.
quote-style = "double"
indent-style = "space"
skip-magic-trailing-comma = false
line-ending = "auto"

# --- 플러그인별 상세 설정 ---
[tool.ruff.lint.isort]
# 프로젝트에서 사용하는 서드파티 라이브러리 목록
# known-third-party = ["django", "graphene_django"]

# --- 파일/디렉토리별 규칙 무시 설정 ---
[tool.ruff.lint.per-file-ignores]
# settings 파일: 와일드카드 import 허용
# "config/settings/*" = ["F403", "F405"]

# __init__.py 파일: 하위 모듈 노출을 위한 미사용/와일드카드 import 허용
"**/__init__.py" = ["F401", "F403"]

# 테스트 파일: 가독성을 위해 긴 줄 허용
"**/test_*.py" = ["E501"]

js&ts 파일도 붙여 넣을까 했는데 진짜 너무 과하게 길어질 것 같아서 생략합니다.
맥락은 같습니다. 어차피 AI 또는 next(or nest)를 쓰든 프로젝트 init 하면 린터와 포매터 세팅은 따라 나옵니다. 이걸 입맛에 맞는 커스텀 템플릿으로 바꾸는 정도입니다.
그리고 ts 경우 type을 얼마나 strict하게 할지, 미리 세팅해 두면 큰 도움이 되죠.

5. github action CI부터 역시 바로 세팅합니다.

내용이 너무 길어서 건너뛰고, 일부분만 사진으로 대체할게요.

<출처: 작가 캡처>

그리고 github cli인 gh를 기가 막히게 잘 쓰더라고요. 그래서 더욱이 CI부터 세팅하려고 합니다. 위는 python, uv 기반 CI 파이프라인이고, 처음부터 멀티 버전 (매트릭스) 대상으로 하지는 않습니다.

2) 그리고 작업 시작, plan.md부터!

<출처: 작가 캡처>

저는 무조건 plan.md 부터 작성합니다. 이게 AGENTS.md에서 명시한 것들과 일맥상통하기도 하고, 통제 가능성이 여전히 중요하기도 하고요. 그리고 여전히 저는 무조건 테스트 코드부터 작성합니다.

<출처: 작가 캡처>

이를 병목으로 보는 시선도 많아졌더라고요. 되돌아보면 과거에 비해 plan을 좀 더 넓은 범위로 작성하게 됐습니다. 예전에는 딱 한 작업, 한 commit 단위를 대상으로 plan을 작성했었습니다. (예를 들어, A라는 API만 바꾸고 싶다든지요.) 지금은 범위가 조금 더 큽니다. “알림 관련 기능을 만들 건데 이러이러해. 이러이러한 것을 위한 ORM 모델부터 핵심 API만 만들자” 이런 느낌에 가깝습니다.

더욱이 plan.md는 이제 하나의 “체크포인트”이기도 합니다. 그래서 저는 plans 디렉터리에 따로 모아둡니다.

<출처: 작가 캡처>

근데 opencode & omo를 쓰시면 .sisyphus 경로에 자동으로 저장되긴 합니다.

<출처: 작가 캡처>

plan.md 를 작성했으면 이제 이를 기반으로 작업을 합니다. opencode + omo에서는 원래 /start-work라는 사전 명령어를 사용해서 시작합니다. 그러면 .sisyphus 경로에 자동 저장된 plan 찾아서 바로 작업을 이어가고, agent에게 일을 할당해 주기 시작합니다.

<출처: 작가 캡처>

제가 쓰는 AGENTS.md 에 따르면 go라는 시그널만 주는데, 이는 좀 때에 따라 다르게 하긴 합니다. ulw 가 필요하다 싶으면 Sisyphus를 사용합니다.

<출처: 작가 캡처>

<출처: 작가>

여러 에이전트에게 자동으로 작업이 분할·위임되고, 병렬로 처리되는 것을 확인할 수 있습니다. 특히 좋은 점은 opencode가 “에이전트의 실행 상태”를 개괄적으로 모니터링하는 GUI(TUI)를 제공하는데, 이 부분은 다른 네이티브 CLI(claude, codex 등)보다 낫다는 점입니다.

plan 규모가 좀 있다면 무조건 검토를 시킵니다.

plan.md 기반으로 모든 사항이 적용되었는지 A to Z를 검토해야 해.
아래 사항에 따라 검토하되, 체크 박스도 모두 제대로 처리해.

1. AGENTS.md 와 SYSTEM_DESIGN.md를 1순위로 따르고 있는지 체크.
2. 변경에 따른 하위호환성과 영향 범위를 절대 잊지 말고 더블 체크.
3. 관련된 테스트 코드 역시 업데이트 되어야 해.
4. 관련된 테스트가 과하거나, 중복되거나, 이미 자명한데 쓸데없는 테스트를 하거나 하지 않는지 체크
5. 2025년, 2026년 외부 공식 자료와 외부 best example을 참고해서 개선해줘. 최대한 비판적으로 수용하고 지금 코드를 업데이트 해야 해.

이를 위해 다양한 모델과 서브에이전트를 적극적으로 활용해.

3) 다음 턴부터는 상황에 따라

저는 Plan 을 한 번 하면 검토를 하고, 검토 output이 최종이라고 생각하며 자체 H-I-L(human in the loop), E2E를 합니다.
그 과정에서 리팩토링 & 세부 피쳐를 작업할 땐 바로 플랜을 짜지 않고, 이때부턴 기본적인 AI md(AGENTS.md 등)만 활용하고, skill 을 적극적으로 사용합니다.

<출처: 작가 캡처>

지금은 거의 세 가지 중 하나를 쓰게 되더라고요. 특히 가장 많이 쓰는 건 ui-ux-pro-max입니다.

<출처: 작가 캡처>

이런 식으로 skill과 하네스를 섞어서 쓰기도 합니다. 이땐 작업 범위가 좁을수록 아웃풋이 좋았습니다.

4) 절대 AGENTS.md, SYSTEM_DESIGN.md 등을 그대로 두지 않습니다.

진행할 록 layer는 많아지고 무조건 프로젝트는 복잡성이 올라갑니다. 그래서 무조건 이 AI를 위한 마크다운을 초기설정 그대로 두지 않습니다. 무조건 프로젝트 현 상태에 따라 맞춰 업데이트를 합니다. 일례로, 동시성에 대한 경고, web이 아닌 OS 응용 프로그램, GUI를 위한 룰, 또는 FE 작업할 땐 DESIGN_SYSTEM.md도 만드는데, 이 디자인 룰 역시도요.

최대한 영어로, 최대한 핵심만 짧고 요약해서

AI를 위한 마크다운은 무조건 토큰에 영향을 주고, 이는 비용과 퍼포먼스에 영향을 줄 수밖에 없습니다. 그래서 저는 무조건 영어로, 최대한 짧고 굵게 작성하려고 합니다. 특히 AGENTS.md 와 같이 기본적으로 에이전트가 물고가는 마크다운 파일은 더욱더요!

5) 한 세션이 너무 길어진다면?

멀티 에이전트는 보통 아래 흐름입니다. (실제로 위에서 사용한 흐름이 모두 아래와 같죠.)

Research Agent
   ↓
Planner Agent
   ↓
Implementation Agent
   ↓
Reviewer Agent
   ↓
Documentation Agent

<출처: 작가 캡처>

한 세션에서 너무 볼륨 큰 작업을 하거나, 계속 한 세션에서 작업을 길게 이어간다면, 초기 지시 사항을 잊을 수도 있습니다. 대표적으로 아래와 같은 허들 이슈가 있죠.

긴 세션에서 컨텍스트가 사라짐
다른 에이전트가 작업을 이어받을 때 맥락 손실
작업 상태 / 결정 / 다음 단계가 사라짐

그럴 때마다 ctrl + c로 취소하거나 /new로 바로 새로운 세션을 시작할 필요가 없습니다.

<출처: 작가 캡처>

/handoff를 쓰면 됩니다. /handoff는 현재 에이전트나 세션의 작업 상태(context)를 다른 에이전트 또는 다음 단계의 작업으로 넘기는 작업 전달 메커니즘입니다.

<출처: 작가 캡처>

자동으로 위 프롬프트가 세팅되고, 바로 그 다음 사진과 같이 핵심 작업이 자동으로 요약이 됩니다. (현재 작업 목표, 지금까지의 결정, 구현된 내용, 남은 작업, 다음 담당자)

<출처: 작가 캡처>

그냥 심플하게 새로운 세션으로 가서 해당 내용을 그대로 복사해서 사용하면 끝이죠.

정리하며

정리해 보면, opencode + OMO 세팅에서는 결국 아래 몇 가지 흐름으로만 쓰게 되는 것 같습니다. 프로젝트 세팅부터 AI용 마크다운까지 포함해, 전반적으로 제대로 갖춰두는 방식으로요.

불확실한 요구사항/큰 작업

Prometheus (Plan Builder)로 plan
때에 따라 Atlas (Plan Executor) 또는 Sisyphus(Ultraworker)를 통해 ulw를 붙여 병렬 실행을 유도(하네스 최대 가동).

레거시 코드 파악이 먼저인 작업

프롬프트에 find 또는 search를 포함해 탐색 모드로 시작
@explore에게 “진입점/핵심 모듈/핫스팟 파일”을 먼저 뽑게 하고(쓰기 제한이 있어 안전), 이후 Build로.

디버깅/근본 원인 분석

프롬프트에 investigate를 넣어 분석 모드로 전환
설계/논리 검토는 @oracle을 “읽기 전용”으로 붙여 객관화

볼륨이 크지는 않지만 특정 부분(또는 역할)만 업그레이드할 경우

스킬과 하네스 섞어서 사용
적극적으로 외부 공식 자료와 외부 best example을 search하게 유도

특히 3번, 4번은 오픈소스 코드나 이미 볼륨이 커진 프로젝트에서 특정 부분에만 집중할 때 꽤 유용했습니다. 요즘처럼 AI 관련 스택의 생명주기가 반년도 안 되는 시대에는, 이런 접근이나 방법도 언젠가 레거시처럼 여겨질지 모르겠습니다.

p.s.

가끔 자기 전, 외출 전에 랄프(Ralph Loop)를 가동하긴 합니다. 그런데 개인적으로는 랄프보다는 ulw를 프롬프트로 자동회귀하게 세팅하는 쪽이 체감 성능이 더 좋더라고요. plan을 가득 만들어두고 한 호흡으로 진행하라는, 즉 무조건 끝날 때까지 진행하라는 프롬프트와 함께 ulw를 돌리면 토큰을 다 쓸 때까지 돌아가는 마법을 보실 수도 있습니다.

opencode stats를 한 번 입력해 보세요! - https://opencode.ai/docs/cli/

저는 Cache Read 에 24억 7,120만 토큰 정도를 사용했네요! 캐시라서 정말 다행입니다. 약 30일간 총 27억 토큰 정도 사용했습니다. (그 이상의 기간은 비밀입니다. 저도 알고 싶지 않았습니다.)

<출처>

<원문>

LLM - 모델 경쟁이 끝나고, “하네스 경쟁”의 시작?!, opencode 와 oh-my-opencode

]]>

당신의 취향(Taste)은 AI보다 나은가?

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

이번 글에서는 국내 VC ‘매쉬업벤처스’의 박은우 파트너가 실리콘밸리에서 떠오른 새로운 키워드 ‘취향(Taste)’을 다룹니다. 모든 것을 AI가 만들 수 있는 시대. 취향은 어떻게 IT 업계의 새로운 역량으로 떠오르게 되었을까요?

안녕하세요. 매쉬업벤처스의 박은우 파트너입니다. 2026년 2월, 실리콘밸리에 흥미로운 논쟁이 벌어졌습니다. OpenAI의 사장인 그렉 브록먼(Greg Brockman)이 X에 올린 한 줄의 글이 시작이었습니다.

Taste is a new core skill.
취향은 새로운 핵심 역량이다.

한편, Y Combinator의 창업자인 폴 그레이엄(Paul Graham)도 본인의 X에 이렇게 적었습니다.

When anyone can make anything, the big differentiator is what you choose to make.
누구나 무엇이든 만들 수 있게 되면, 진짜 차별화는 무엇을 만들지 선택하는 것이다.

지난 30년간 “빠르게 만들고, 빠르게 출시하라(Build fast, ship fast)” 외치던 실리콘밸리가, 갑자기 ‘취향’을 이야기하기 시작한 것입니다. 무슨 일이 일어난 것일까요?

도구의 희소 시대에서 풍요의 시대로

이번 논쟁에서 가장 날카로운 지적은 PM들을 위한 뉴스레터를 운영하는 Aakash Gupta에게서 나왔습니다.

Taste was always a core skill. We just had a 30-year window where you could ignore it because execution was so hard that anything that worked at all felt like an achievement.
취향은 언제나 핵심 역량이었다. 다만 지난 30년 간은 실행 자체가 너무 어려워서, 일단 작동하기만 하면 그 자체가 성취였던 예외 기간이었을 뿐이다.

이 문장에 이번 논쟁의 본질이 담겨 있습니다.

소프트웨어 산업의 역사를 돌아보면, 도구가 희소할 때는 기술이 가치였고, 도구가 풍부해질 때는 판단이 가치가 되는 패턴이 반복되어 왔습니다. 1995년, 스티브 잡스(Steve Jobs)가 PBS 인터뷰에서 “Microsoft의 유일한 문제는 취향이 없다는 것(The only problem with Microsoft is they just have no taste)”라고 말했던 때는 하드웨어와 소프트웨어가 막 대중화되던 시점이었습니다. 2002년, 폴 그레이엄이 ‘Taste for Makers’라는 에세이에서 언급한 “훌륭한 결과물 = 까다로운 취향 + 그것을 실현할 수 있는 실행력(Great work = Exacting taste + The ability to gratify it)”은 인터넷이 소프트웨어 개발의 진입 장벽을 낮추기 시작한 시점의 관찰이었습니다.

그리고 2026년, AI가 코드 작성, 디자인, 카피라이팅, 데이터 분석에 이르기까지 소프트웨어 개발의 거의 모든 실행을 범용적으로 만들고 있는 지금, 이 패턴이 가장 극적인 형태로 반복되고 있습니다. 코드를 시간 당 500줄 생산하는 엔지니어보다, 어떤 5줄이 존재해야 하는지 30분 고민하는 사람이 더 가치 있는 시대가 온 것입니다.

프롬프트로 구현되는 취향 vs 그렇지 않은 취향 (Promptable Taste vs Unpromptable Taste)

그렇다면 취향(Taste)이란 구체적으로 무엇일까요? 실리콘밸리의 이번 논쟁에서 가장 도발적인 반론은 ‘당신의 취향이 AI보다 낫지 않을 수 있다’ 일 것입니다. 하지만 혹자는 취향의 90%가 암묵지이기 때문에 프롬프트로 전달하기 불가능하다고 이야기합니다.

저는 이 두 의견의 충돌에서의 논점을 프롬프트로 구현되는 취향(Promptable Taste)과 프롬프트로 구현할 수 없는 취향(Unpromptable Taste)으로 나누어 생각합니다.

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

프롬프트로 구현되는 취향(Promptable Taste): AI가 이미 잘 하거나, 곧 잘 하게 될 영역

‘이 UI를 Airbnb 스타일로 깔끔하게 만들어줘’, ‘이 광고 카피를 더 간결하게 다듬어줘’, ‘경쟁사 10개를 분석해서 정리해줘.’ 이런 지시는 레퍼런스가 존재하고, 기준을 언어로 전달할 수 있는 영역입니다. AI는 이미 이 영역에서 인간의 평균을 넘었거나 빠르게 넘고 있습니다. 이것이 프롬프트로 구현되는 취향입니다.

프롬프트로 구현할 수 없는 취향(Unpromptable Taste): 창업자에게 진짜 요구되는 것

반면 언어로 전달할 수 없는 판단의 영역이 있습니다.

가령, ‘이건 지금이 아니다’의 감각. 2025년에 AI 에이전트 스타트업을 시작하는 것과 2021년에 시작하는 것의 차이. 기술적으로 가능한 것과 시장이 받아들일 준비가 된 것 사이의 차이를 읽는 능력. 이건 데이터로 증명할 수 없습니다.

‘이 기능(Feature)은 빼야 한다’의 감각. AI에게 ‘이 기능의 사용률이 낮으니 빼자’라고 지시하는 것은 프롬프트로 가능합니다. 하지만 사용률이 높은데도 ‘이건 우리 제품의 방향이 아니다’라고 빼는 것은 전혀 다른 차원의 판단입니다.

‘이 사람이다’의 감각. 초기 스타트업에서 파운딩 엔지니어를 고르는 판단. 이력서와 포트폴리오는 AI가 스크리닝 가능하지만, ‘이 사람이 우리 팀의 빈 조각을 채운다’는 감각은 AI에게 프롬프트로 전달할 수 없습니다.

‘이 문제가 진짜 문제다’의 감각. AI에게 ‘좋은 스타트업 아이디어를 내줘’라고 하면 그럴듯한 답이 나옵니다. 하지만 그중 어떤 문제에 10년을 걸 것인가에 대한 확신은 창업자 자신의 경험과 세계관에서만 나옵니다.

‘당신의 취향이 AI보다 낫지 않을 수 있다’는 반론은 프롬프트로 구현되는 취향의 영역에서는 유효합니다. AI는 이미 평균적 취향을 넘어서고 있습니다. 하지만 프롬프트로 구현할 수 없는 취향은 구조적으로 다릅니다. AI는 근본적으로 패턴 매칭 머신(Pattern Matching Machine)입니다. 하지만 프롬프트로 구현할 수 없는 취향의 핵심은 ‘기존 패턴 자체가 틀렸다’고 선언하는 것, 즉 역발상에 대한 베팅(contrarian bet)입니다. 트레이닝 데이터의 컨센서스를 벗어나는 판단은 AI의 구조적 한계 밖에 있습니다.

프롬프트로 구현되지 않는 취향의 해부(The Anatomy of Unpromptable Taste)

여기까지 읽으시면 이런 반론이 떠오를 수 있습니다. ‘취향이라는 단어 자체가 모호한 것 아닌가?’ 이는 충분히 유효한 비판입니다. 이에 대해 폴 그레이엄은 앞서 언급한 2002년 에세이에서 명확한 답을 제시합니다. 취향은 주관적 감상이 아니라, 디자인을 계속 할수록 성장하는 객관적 능력이며, 분야를 막론하고 공통된 원칙들로 분해할 수 있다는 것입니다. 즉, 취향은 신비의 영역이 아니라 분해하고 훈련할 수 있는 구체적 역량이라는 것입니다. 이에 “나는 취향이 있고 너는 없다”는 식의 논의는 아무런 가치를 만들지 못합니다. 그래서 취향을 신비화하지 않고, 구체적으로 분해할 필요가 있습니다.

창업자의 취향 영역

창업자에게 취향이 발현되는 영역은 크게 세 가지로 나눌 수 있습니다.

큐레이션의 취향(Curation Taste): 빼는 능력입니다. 무엇을 하지 않을지 아는 것. 스티브 잡스는 “집중이란 ‘No’라고 말하는 것(Focus is about saying no)”라고 했습니다. 10개의 기능 중 1개만 남기는 판단, 높은 사용률의 기능이라도 제품의 방향과 맞지 않으면 빼는 판단이 여기에 해당합니다.

제작의 취향(Craft Taste): 만드는 능력입니다. 남긴 것을 어떤 수준으로 마감하는가. Apple의 전 디자인 총괄 조니 아이브(Jony Ive)는 이를 Jony Ive는 이를 ‘끈질긴 정성(Sustained care)’이라고 표현했습니다. 피상적 심미성(aesthetic)이 아니라, 모든 결정에 의도(Intentionality)를 넣는 것. 디테일의 퀄리티에 대한 감각입니다.

비전의 취향(Vision Taste): 보는 능력입니다. 남들이 아직 못 보는 것을 먼저 감지하는 것. 피터 틸(Peter Thiel)이 ‘Zero to One’에서 말한 ‘구체적 낙관주의(Definite Optimism)’, 즉 미래에 대한 구체적 확신을 갖는 능력과 맞닿아 있습니다.

창업자의 취향을 작동시키는 엔진(Taste Engine)

그렇다면 이 세 가지 취향을 실제로 작동시키는 엔진은 무엇일까요? 매쉬업벤처스는 뛰어난 창업자에게 반드시 있어야 하는 역량을 오랫동안 관찰해 왔습니다. 그렇기에 이 역량이 바로 취향을 구동하는 엔진이라고 생각합니다.

<출처: SpaceX>

일원칙 사고(First Principle Thinking): 취향의 정확성을 만드는 엔진. 기존 패턴을 해체하고 본질을 보는 능력입니다. 일론 머스크가 로켓의 원가를 원재료 단위로 다시 계산한 것, 정주영이 퇴역 유조선으로 방조제를 쌓은 것 모두 일원칙 사고의 산물입니다. AI가 패턴 매칭 머신이라면, 일원칙 사고는 그 정반대, 즉 기존 패턴을 의도적으로 파괴하는 사고입니다.

메타 인지(Meta-Cognition): 취향의 적응성을 만드는 엔진. 자기 판단의 한계를 알고, 시장의 피드백으로 반영하는 능력입니다. 시장에 대한 겸손함, 팀 구성에서의 겸손함이 여기서 나옵니다. 폴 그레이엄이 “취향은 기를 수 있다(Taste can be cultivated)”라고 했을 때, 그 배양의 메커니즘이 바로 메타 인지입니다. 과거의 내 판단을 돌아보고, ‘그때는 왜 저걸 좋다고 생각했지?’라고 묻는 능력이 취향을 정제합니다.

장기적 사고(Long-term Thinking): 취향의 지속성을 만드는 엔진. 아직 데이터로 증명되지 않은 확신을 2~3년 견디는 능력입니다. 제프 베조스(Jeff Bezos)가 “서점이 왜 서버를 파느냐”는 주주들의 질문을 견디며 AWS를 만들었듯이, 장기적 사고가 없으면 취향은 창업자의 변덕이 됩니다.

이 세 엔진 중 하나라도 빠지면 취향은 불완전해집니다. 일원칙 사고가 없는 취향은 유행 따라가기(남의 취향 복제)가 됩니다. 메타 인지 없는 취향은 독선(시장이 뭐라 하든 내가 옳다)이 됩니다. 장기적 사고가 없는 취향은 변덕(매번 다른 방향)이 됩니다.

취향 × 역량 매트릭스(Taste × Competency Matrix)

앞서 언급한 세 가지 취향 영역과 세 가지 엔진을 교차하면 3x3 매트릭스를 만들 수 있습니다. 이 중 AI 시대에 특히 주목해야 할 교차점은 대각선을 따라 나타나는 세 가지입니다.

	큐레이션의 취향	제작의 취향	비전의 취향
일원칙 사고	O
메타 인지		O
장기적 사고			O

1. 큐레이션 × 일원칙. ‘이건 왜 있어야 하지?’라고 묻고, 관성적으로 넣어왔던 것을 제거하는 판단입니다. 스티브 잡스가 아이폰에서 물리 키보드를 뺀 것이 대표적입니다. 당시 모든 시장 데이터가 반대를 가리키고 있었지만, 그는 터치스크린이라는 본질에 집중하기 위해 기존의 전제 자체를 해체했습니다. 이 교차점은 프롬프트로 구현할 수 없는 취향 중에서는 가장 구현할 수 있는 축에 가까운 영역입니다. 논리적으로 설명이 가능하기 때문입니다.

2. 제작 × 메타 인지. ‘내가 만든 이 결과물, 내 눈에만 좋은 거 아닌가?’ 시장과 사용자의 피드백으로 기능을 끊임없이 정제하는 판단입니다. 이 교차점이 없으면 취향의 논의는 ‘감 좋은 천재에 대한 찬양’으로 전락합니다. AI 시대, Granola의 크리스 페드레갈(Chris Pedregal)이 “AI는 데모하기는 쉽게 만들었지만, 꾸준히 만족감을 유지하기는 어렵게 만들었다(AI makes it easy to demo, but hard to sustain delight)”라고 말한 것, 그리고 여러 AI 기능을 과감히 버리고 하나의 핵심 인터랙션에 집중하여 리텐션을 만들어낸 것이 이 교차점의 좋은 사례입니다. 취향은 독선이 아닌 이유가 바로 여기 있습니다.

3. 비전 × 장기적 사고. ‘지금은 시장이 없지만, 이 방향이 맞다’는 확신을 데이터 없이 2~3년 유지하는 판단입니다. 이것이 AI가 구조적으로 대체 불가능한 영역이며, 프롬프트로 구현할 수 없는 취향의 정점입니다. AI는 현재 데이터에 기반해서 판단하지만, 이 교차점의 창업자는 아직 존재하지 않는 데이터를 근거로 판단합니다. 그리고 그 확신(Conviction)을 시장이 따라올 때까지 견딥니다.

대각선을 따라 왼쪽 위에서 오른쪽 아래로 갈수록, 프롬프트로 구현할 수 있는 것에서 없는 것으로의 그라데이션이 나타납니다. AI가 범용적(commodity)으로 만드는 영역과, 오히려 더 희소해지는 영역의 경계가 이 대각선 위에 있습니다.

K-스타트업 에코 시스템: 실행의 시대에서 취향의 시대로

이 논의가 한국 스타트업 생태계에 특히 유효한 이유가 있습니다.

한국은 전통적으로 실행 속도(Execution speed)가 경쟁력인 시장이었습니다. ‘빨리빨리’ 문화가 스타트업에도 그대로 적용되어, 남보다 빨리 만들고 빨리 런칭하는 것이 미덕이었습니다. 이전 글에서 다루었듯이, 한국 SaaS 시장의 성장도 글로벌 레퍼런스를 빠르게 현지화하는 모델에서 상당 부분 이루어져 왔습니다.

그런데 AI가 실행 속도를 평준화시키고 있습니다. 코드 작성, 디자인, 마케팅 카피 등 과거에 수주가 걸렸던 작업은 이제 클릭 몇 번이면 수시간만에 끝낼 수 있게 되었습니다. ‘빨리 만드는 것’이 누구나 할 수 있게 되면, 한국 스타트업의 전통적 강점이 사라집니다.

그리고 이것은 단순히 창업자의 문제가 아닙니다. 생태계의 구조적 문제입니다. 한국 VC 시장은 지표(Traction) 중심의 평가를 해왔습니다. MAU, GMV, 매출 성장률. 이것들은 모두 프롬프트로 만들 수 있는 지표입니다. 측정 가능하고, 비교 가능하고, 벤치마크가 존재합니다. 하지만 창업자의 취향을 평가하는 체계적 방법론은 부족했습니다.

한국의 교육 시스템은 정답 찾기에 최적화되어 있습니다. ‘정답이 없는 상황에서의 판단력’ 즉, 취향을 훈련하는 구조가 취약합니다.오해하지 말아야 할 것은, ‘한국 창업자에게 취향이 없다’가 아니라는 점입니다. 한국 생태계가 취향을 키우고 보상하는 구조를 갖추지 못했던 것입니다. AI 시대에 이 구조적 한계가 본격적으로 드러나기 시작합니다.

VC가 취향을 보는 방법

스타트업의 첫 번째 파트너를 지향하는 투자자로서, 저희가 보려는 것은 결국 창업자의 프롬프트로 만들 수 없는 취향입니다. 제품도 지표도 불완전한 시점에서, 저희가 주목하는 것은 다음과 같은 신호입니다.

“왜 이 문제인가”를 자기만의 언어로 말하는지. 다른 사람의 프레임워크를 빌려서 말하는 것이 아니라, 자신의 경험과 관찰에서 나온 고유한 관점으로 문제를 정의하는 창업자. 이것이 문제를 보는 안목의 프록시입니다.

“경쟁사 대비 뭐가 다르냐”는 질문에 기능 리스트가 아닌 관점의 차이로 답하는지. “우리는 이 기능이 더 있습니다”가 아니라 “우리는 이 문제를 근본적으로 다르게 봅니다”라고 답할 수 있는 창업자. 이것이 비전 관점 취향의 프록시입니다.

제품 데모에서 “이건 일부러 안 넣었다”고 말할 수 있는지. 기능이 적은 것이 아니라, 의도적으로 뺀 것이라고 설명할 수 있는 창업자. 이것이 큐레이션 취향의 프록시입니다.

Focus on the things that don't change

빌보드 앨범 차트에서 1위를 차지한 최초의 힙합 앨범 Rick Rubin, Beastie Boys - Licensed to Ill(1986) <출처: wikipedia>

그래미 9회 수상에 빛나는 전설적인 음악 프로듀서 릭 루빈(Rick Rubin)은 악기를 연주하지 못하고, 믹싱 보드도 다루지 못합니다. 앤더슨 쿠퍼(Anderson Cooper)가 60초 인터뷰에서 “그럼 무엇으로 돈을 받느냐”고 묻자, 그는 이렇게 답했습니다.

The confidence that I have in my taste.
내 취향에 대한 확신.

AI 시대에 바뀌는 것은 많습니다. 코드 작성 방식, 디자인 프로세스, 데이터 분석 방법론. 하지만 바뀌지 않는 것이 있습니다. 무엇을 만들지 선택하는 판단, 무엇을 빼야 하는지 아는 감각, 아직 보이지 않는 미래에 확신을 갖는 용기. 이것이 프롬프트로 바꿀 수 없는 취향이고, AI 시대에 오히려 더 희소해지는 창업자의 핵심 역량입니다.

이전 글에서 제프 베조스의 말을 빌려 “바뀌지 않는 것에 집중하라”고 말씀드린 바 있습니다. AI 시대의 불멸의 플레이북에 이어, 저는 취향이야말로 시대가 바뀌어도 변하지 않는 창업자의 무기라고 생각합니다.

AI가 모든 것을 만들 수 있는 시대에, 당신은 무엇을 만들지 선택할 수 있는 취향을 갖고 계신가요?

[매쉬업벤처스가 AI 네이티브 창업자를 찾습니다]

AI 네이티브 UX로 특정 산업의 문제를 새롭게 정의하며, 최첨단 모델도 탐내는 해자를 구축하는 팀
부분 자율 앱에서 시작해 셀프 드라이빙 서비스로 발전시킬 기술과 제품 로드맵을 가진 팀

매쉬업벤처스와 함께 AI의 미래를 만들어갈 창업자들은 아래 버튼을 눌러 연락주세요.

<원문>

AI 창업자의 취향: Promptable vs Unpromptable Taste

]]>

AI와 만든 앱에 결제를 붙이는 가장 현명한 방법들 (Feat. MoR)

“SaaS 만들어줘”라고 AI에 말하면 진짜로 하루 만에 돌아가는 앱이 나오는 시대입니다. 그런데 “여기에 월 9,900원 구독 결제 붙여줘”라고 던지는 순간, 대화가 뚝 끊기곤 합니다. 화면은 멀쩡한데 결제 앞에서 프로젝트가 멈춰 서는 거죠. 이게 요즘 말하는 바이브 코딩의 진짜 병목입니다.

많은 분이 결제를 버튼 하나 붙이면 끝나는 기능쯤으로 생각합니다. 하지만 실제 결제는 다른 일반 기능들과 차원이 다릅니다. 사업/세금/환불/심사/정산이 한 덩어리로 묶인 운영 시스템에 가깝죠. 그래서 단순 연동처럼 보이지만, 중간에 PG 심사나 세금 처리 같은 현실 이슈가 튀어나옵니다. 이 지점부터는 AI도 “그건 상황에 따라 달라요” 모드로 멍청해집니다.

그런 만큼 제대로 결제를 도입하려면 더 많은 것을 알아야 하지만요, 이 글에서는 복잡한 설명은 최대한 하지 않겠습니다. 대신 딱 3가지 질문으로 상황을 먼저 분류하고, 케이스별로 가장 빠르게 첫 결제를 받는 경로까지 연결해 보겠습니다. 중요한 건 최고의 결제 도구가 아니라 지금 내 상황에서 제일 빨리 돈이 들어오는 선택지니까요. 이제부터 같이 보겠습니다.

프로덕트가 있는데 왜 결제를 못하나요 <출처: 작가, Gemini로 제작>

결제가 없다면 “검증”은 모두 거짓말

’결제’라는 운영 시스템은 크게 세 가지로 나눠 보면 편합니다. 돈 받기(결제), 돈을 누구 이름으로 받는지(판매 주체), 돈을 받은 뒤 책임(세금·환불·증빙)을 관리하는 방식이죠. 이 셋을 한 번에 생각하지 않으면, 연동은 어렵습니다. 그리고, 이러한 결제가 없다면 검증은 모두 거짓말에 가깝습니다. SNS 글에 좋아요를 1,000개 받아도 결제 1건보다 검증 수치는 약하니까요.

왜 바이브 코딩에서 결제는 병목이 되는가

AI가 코드는 뽑아줄 수 있습니다. 하지만 사업자 요건, PG 심사, 세금, VAT, 환불정책은 자동완성이 잘 안 됩니다. 예를 들어 “구독 취소하면 남은 기간은 어떻게 환불하지?” 같은 질문은 제품 정책에서 나옵니다. 또, 여기서부터는 사회 규범과 법이 함께합니다. 돈을 받고 모른 척 하면 그때부터는 심판의 문제가 된다는 겁니다. 해외 결제라면 국가별 VAT 같은 이슈가 튀어나옵니다. 그러니까 이건 어떻게든 적당히 넘길 수 없습니다. 반드시 사람이 깊이 개입해 결정해야 합니다.

그래서 PMF(사람들이 진짜 돈 내는지 확인하는 단계) 이전에는 완벽한 결제보다 검증 가능한 과금이 우선입니다. 여기서 말하는 핵심은 첫 결제입니다. 첫 결제가 찍히면 누군가는 돈을 낸다는 가정이 사실이 됩니다. 그때부터 결제 UX, 세금 처리, 환불 로직을 고도화해도 늦지 않습니다.

물론 계좌번호를 띄워놓고 무통장 입금을 받을 수도 있습니다. 카카오페이·네이버페이 QR을 올려두는 방법도 있습니다. 하지만 그 방식은 보통 “운영자가 매번 처리해야 하는” 형태입니다. 제품이 알아서 돌아가는 시스템으로는 약합니다. 그래서 한 번은 제대로 된 결제 시스템을 얹어봐야 합니다. 그때 꼭 알아야 할 개념이 MoR과 PG입니다.

MoR(Merchant of Record) vs 일반 PG/PSP

헷갈릴 수 있으니 비유로 풀어보겠습니다.

MoR(Merchant of Record)은 판매 대행상에 가깝습니다. 고객에게 돈을 받고, 영수증을 끊고, 세금과 환불까지 책임지는 쪽이 MoR입니다. 쉽게 말해 돈이 들어오는 순간부터 뒤처리까지 모두 같이 떠안습니다. 그래서 그런 작업에 대한 수수료를 떼고 남은 돈을 보내줍니다.

반대로 일반 PG/PSP는 카드 단말기에 가깝습니다. 결제는 시스템까지 관리해 통과시켜 주지만, 그 뒤의 운영 책임은 내 몫입니다. 예를 들어 Stripe나 국내 PG는 보통 이쪽에 가깝습니다. 결제 창은 붙일 수 있지만 세금·VAT·환불 정책 같은 건 내가 설계해야 한다는 뜻입니다.

그래서 이 두 가지의 선택 기준은 의외로 단순합니다. “나는 지금 결제 뒤처리까지 떠안을 여력이 있나?”라는 질문을 던져보는 겁니다. 여력이 없다면 MoR이 빠르고, 여력이 있다면 일반 PG/PSP가 유연합니다. 바이브코딩으로 속도를 내고 싶을수록 이 차이가 더 크게 느껴질 겁니다.

시작 전에 3가지만 결정하면, 도구는 80% 자동으로 좁혀진다

결제 도구를 고르기 전에 먼저 우리 제품이 무슨 문제를 푸는지 정의해야 합니다. 그러면 곧바로 누가 그 문제를 겪고 있는지, 즉, 고객을 알 수 있겠죠. 그래서 그 고객을 아래 질문과 대응시켜야 합니다. 기능 비교표를 펼치기 전에 방향부터 잡으면 선택지가 자동으로 줄어듭니다. 아래 3가지 질문에 답해보면 됩니다.

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

질문 1. 결제하는 사람이 한국 유저인가, 해외 유저인가?

이건 결제창을 붙이는 방법이 아니라 결제 뒤에서 터지는 일이 달라지는 문제입니다. 한국 유저라면 카드와 간편결제 UX가 핵심이고, 해외 유저라면 세금과 통화, 실패 처리 같은 운영 이슈가 먼저 튀어나옵니다. 쉽게 말해, 한국은 결제수단이 다양해서 흐름이 복잡하고, 해외는 국가가 다양해서 규칙이 복잡합니다.

한국 유저가 주로 결제한다면 PG 연동이 일단 최우선입니다. 다만 이건 연동한다고 끝나는 문제가 아니라, 심사와 정산까지 포함된 운영 계약에 가깝습니다. 특히 나중에 고객응대나 회계 처리에서 발목 잡히지 않으려면 처음부터 흐름을 그려두는 게 좋습니다. 당연히 안전하지만, 속도는 느릴 겁니다. 물론 그런 만큼 한국 유저들에 익숙한 흐름입니다. 결제 과정이 이탈의 요소가 될 가능성은 적죠.

해외 유저가 결제한다면 질문이 바뀝니다. 결제가 되는지보다 결제가 된 다음 세금과 분쟁을 감당할 수 있냐는 문제가 더 중요해집니다. 특히 SaaS는 결제 실패와 차지백이 생각보다 자주 생기고, 그때의 대응 방식이 곧 운영 비용이 됩니다. 그래서 이슈가 생겼을 때 어떻게 대응할지를 공부해야 합니다.

질문 2. 구독 vs 일회성 vs 사용량 기반

같은 결제라도 과금 모델이 달라지면 필요한 기능이 완전히 달라집니다. 요금제 변경과 환불, 실패 복구 같은 운영 로직도 붙기 때문입니다. 그래서 도구를 고를 때도, 결제창보다 운영 시나리오를 먼저 적어보는 게 안전합니다.

구독이라면 결제는 시작일 뿐입니다. 유저는 중간에 플랜을 바꾸고, 무료체험을 쓰고, 결제를 놓치기도 합니다. 이걸 매번 사람이 처리하면 앱이 커질수록 운영이 무너집니다.

일회성 결제는 단순해 보이지만, 막상 운영하면 환불이 핵심입니다. “환불해 주세요”라는 요청은 거의 반드시 오고, 부분환불도 종종 생길 겁니다. 또 디지털 상품이라면 결제 완료 후 전달하는 프로세스가 분명히 만들어져야 CS가 줄어듭니다.

사용량 기반은 계량(usage metering)이 전부입니다. 특히 AI 앱은 토큰이나 요청 수를 정확히 집계해야 하는데, 이게 성능과 정확도 둘 다에서 병목이 되기 쉽습니다. 즉, 결제 연동보다 먼저 무엇을, 어떤 단위로, 언제 집계할지 결정해야 합니다.

질문 3. 사업자등록이 있는가, 없는가?

사실 이것이야말로 애초에 가능한 선택지가 뭔지 가르는 질문입니다. 특히 국내에서는 PG가 거의 모두 사업자 기반으로 움직이는 경우가 많아 사업자등록 유무가 곧 출발선이 됩니다.

사업자등록이 없다면, 현실적으로 국내 PG 연동이 막히는 경우가 많습니다. 그래서 이 단계에서는 MoR(Merchant of Record) 같은 대안이나 노코드형 우회가 더 빠른 선택이 될 수 있습니다.

사업자등록이 있다면, 이제부터는 장기 운영이 가능한 구조를 고르는 게 중요합니다. 심사 통과만이 아니라 정산 주기와 세무 처리까지 이어지는 흐름이 있기 때문입니다. 처음엔 작은 앱이어도 결제가 붙는 순간부터는 운영이 ’업무’가 됩니다. 그러니 심사, 정산, 세무 프로세스를 맞춰야 합니다.

3가지 기준, 즉, “국내/해외 × 과금모델 × 사업자 유무” 매트릭스를 만들면 내 케이스가 한 칸으로 떨어집니다. 다음 단계는 간단합니다. 그 칸에서 정답에 가까운 결제 도구를 고르고, 가장 빠른 연동 경로로 첫 결제를 받는 겁니다.

내가 처리 안 하는 게 첫 런칭에 유리하다: Polar·Lemon Squeezy·Paddle

결제를 시도할 때 사람들이 가장 많이 멈칫하는 지점은 따로 있습니다. 세금과 증빙입니다. “VAT는 누가 처리하지?”, “환불하면 영수증은?”, “나는 사업자도 아닌데 괜찮나?” 같은 질문이 한꺼번에 몰려옵니다. 운영의 책임이 눈앞에 나타나기 때문입니다.

그래서 이럴 때는 MoR을 검토해 보는 것을 권합니다. 물론 모두 해외 서비스여서 한국 사람에게 익숙한 UX를 지원하지 않는데다 제한되는 상황도 많습니다. 수수료도 쎄고요. 그래도 운영의 책임을 큰 폭으로 줄여주는 것은 분명합니다. PG 심사를 위해 사업자등록증부터 발급해야 한다는 상황이라면, 더더욱이요. 역으로 생각해도 좋습니다. 해외 타깃으로도 시도해 볼 수 있다는 거니까요.

바이브 코딩에 어울리는 MoR 플랫폼들

Polar: AI 앱 메이커를 위한 판매자의 역할

Polar는 오픈소스 MoR(Merchant of Record) 입니다. 특히 해외 결제에서 골치 아픈 세금·VAT 처리를 Polar가 대행해줍니다. 처음 런칭할 때 “세금 설계부터 해야 하나?”라는 부담을 크게 줄여줍니다.

Polar의 첫 번째 강점은 사용량 기반 과금(usage-based) 을 기본으로 깔고 있다는 점입니다. 특히 OpenAI·Anthropic API 사용량을 자동으로 수집해서, 유저별로 쓴 만큼 청구하는 흐름이 자연스럽게 이어집니다. AI 앱은 비용 구조가 토큰 사용량에 붙어있는 경우가 많습니다. 이때 Polar는 결제 모델과 제품 구조가 잘 맞습니다.

두 번째 강점은 비용입니다. Polar는 수수료가 4% + 40¢로 알려져 있습니다. MoR 계열 중에서도 저렴한 축에 속합니다. 첫 매출이 작을수록 이런 고정 비용 차이가 체감됩니다.

세 번째 강점은 디지털 혜택을 결제와 바로 묶는 능력입니다. 예를 들어 GitHub 레포 접근권, 라이선스 키 같은 혜택을 구독과 연결할 수 있습니다. 즉, 결제가 끝나면 권한이 자동으로 열리는 그림이 나오는 거죠. 운영자가 손으로 처리할 일이 줄어듭니다.

현실적인 측면에서, Polar는 사업자등록 없이도 시작할 수 있습니다. 그래서 일단 팔리는지 검증이 목표인 단계에 특히 유리합니다. 첫 런칭에서 중요한 건 완벽한 구조가 아니라 빠른 학습 속도입니다.

Lemon Squeezy: AI가 아닌 일반 SaaS/디지털 상품에 범용

Lemon Squeezy도 MoR이라 세금 부담이 상대적으로 적습니다. 체크아웃과 기본 설정이 직관적이라 결제 연동에 시간을 많이 쓰고 싶지 않을 때 편합니다. 일단 결제 페이지부터 띄우자는 목표에 잘 맞습니다.

특히 처음엔 제품 내에서 예쁜 결제 페이지와 빠른 판매를 연결하는 게 더 중요한 경우가 많습니다. 개인 메이커나 소규모 팀이라면 더 그렇습니다. 이럴 때 Lemon Squeezy는 설정하다 지쳐서 출시가 밀리는 상황을 줄여줍니다.

마찬가지로 개인도 시작할 수 있다는 점이 장점입니다. 법인부터 만들고 오는 대신 작은 시작을 받아주는 쪽에 가깝습니다. 첫 런칭의 허들을 낮추는 선택지입니다.

Paddle: B2B SaaS로 커질 계획이라면

Paddle은 MoR 기반이면서, 인보이스와 엔터프라이즈 기능까지 제공합니다. 쉽게 말해, 결제가 개인 카드 결제에서 끝나지 않는 환경을 염두에 둔 도구입니다. B2B SaaS는 자연스럽게 나중에 견적서, 인보이스, 내부 결재 같은 흐름이 따라오는데요. 그때 필요한 기능을 한 번에 묶어둔 쪽입니다.

다만 1인 메이커의 첫 런칭이라면 Paddle은 오버스펙일 수 있습니다. 처음부터 큰 조직의 프로세스를 들고 오면 출시 속도가 느려질 수 있거든요. 그래서 지금 필요한지, 나중에 필요한지, 성장 계획이 명확할 때 선택하는 편이 낫습니다.

+Stripe: 가장 유연하지만, 책임이 따라온다

마지막으로 해외 고객을 위한 PG로, 전 세계에서 거의 가장 유명한 결제 연동 서비스 Stripe도 있습니다. 장점은 명확합니다. 레퍼런스, 문서, SDK, 확장성이 강합니다. 원하는 결제 흐름을 직접 설계하고 제품에 맞게 촘촘히 붙일 수 있습니다. 결제에서의 자유도만 보면 가장 매력적인 선택지입니다.

하지만 핵심 단점도 분명합니다. Stripe는 MoR이 아닙니다. 그래서 VAT/세금/환불/증빙을 내가 직접 설계해야 합니다. 그런 부담을 안고 있는데 한국에 완전 최적화된 방식은 아니니 쉽지가 않습니다. 한국 사업자도 가입할 수 있지만, 원화 정산 구조가 번거로울 수 있다는 뜻입니다. 연동은 쉬운데, 정산에서 시간이 새는 상황이 생길 수 있으니 미리 확인하는 편이 안전합니다.

한국에 있어야 결국에는 더 빠르다: 토스페이먼츠·스텝페이·포트원

국내 결제는 “코드만 붙이면 끝”이 아닙니다. 보통 사업자등록이 먼저 필요하고, 그다음에 PG 심사가 끼어듭니다. 이 심사가 보통 1~3일은 걸리다 보니 오늘 당장 결제 받기가 목표라면 도구 선택이 꺼려질 수도 있습니다.

하지만, 같은 기능이라도 연동 과정이 매끄러운 쪽이 결국 더 빨리 출시됩니다. 여기서 말하는 속도는 단지 개발 속도가 아닙니다. 심사, 정산, 운영까지 감안했을 때의 체감 속도입니다. 문제가 생겼을 때, 한글로 쓰여진 가이드, 한글이 편한 상담원과 대화할 수 있는 것이 마음에 훨씬 편하죠. 그래서 국내 유저를 받을 때 무작정 MoR을 먼저 떠올리기보다, 내 상황에 맞는 결제 도구가 무엇인지부터 보는 게 안전합니다.

특화 포지션을 가지고 있는 국내 결제 연동 플랫폼

토스페이먼츠: 바이브코딩과 궁합이 좋은 포지션

토스페이먼츠는 국내에서 개발자 경험(DX)이 좋기로 유명한 쪽입니다. 연동 문서와 흐름이 비교적 매끄러워서 일단 붙여서 돌아가게 만들기가 빠릅니다. 최근에는 MCP 서버까지 도입하면서 바이브 코딩 흐름과의 궁합이 더 좋아졌습니다.

쉽게 말해, Cursor나 Claude Code에서 “결제창 연결해줘” 같은 자연어 지시를 했을 때, 연동에 필요한 코드가 생성되는 길이 열린 겁니다. 예전에는 문서 읽고, 샘플 찾고, 키를 맞추는 시간이 컸다면, 이제는 그 구간이 짧아질 수 있습니다. 다만 여기서 기대치는 관리해야 합니다. 코드는 당일에 붙어도, 상용 오픈은 PG 심사 이후라는 점은 그대로입니다.

스텝페이: 구독 운영을 제품으로 제공하는 길

스텝페이는 결제창을 연동하는 도구라기보다, 구독 운영을 제품으로 묶어서 제공하는 쪽에 가깝습니다. 노코드로 구독 스토어를 만들 수 있고, 정기결제에 필요한 기능들이 기본으로 들어 있습니다. 개발 리소스가 적을수록 이 차이가 크게 느껴집니다. 특히 구독 SaaS에서 진짜 어려운 건 결제 버튼이 아닙니다. 요금제 운영과 미납 처리가 본게임입니다. 스텝페이는 이런 구간을 제품 기능으로 제공합니다. 예를 들면 아래 같은 것들입니다.

사용량 기반 과금
무료 체험
결제 복구(미납 시 카톡 청구서 등)

그래서 요금제가 복잡하거나, 정기결제 운영을 빨리 검증해야 하거나, 일단 팔아보고 고치자가 목표일 때 또 고려할 만한 선택지입니다. 결제를 붙이는 속도뿐 아니라, 운영까지 포함한 속도가 빨라집니다.

포트원: 결제수단을 여러 개 붙일 때의 통합 레이어

포트원은 여러 결제수단을 한 번에 다루고 싶을 때 빛납니다. 토스페이먼츠, KG이니시스, 카카오페이, 네이버페이 같은 것들을 하나의 SDK로 통합하는 방식입니다. 쉽게 비유하면, 결제사마다 다른 리모컨을 쓰는 대신 리모컨 하나로 여러 기기를 조작하는 느낌입니다.

다만 이 방식이 처음부터 좋다고는 말하기 어렵습니다. 결제가 하나도 안 나오는데 창구는 10개 열어둬봤자니까요. 핵심 이점은 나중에 나옵니다. 처음에 선택을 잘못했을 때면 보통은 연동 코드를 다시 갈아엎어야 하는데요. 포트원은 PG사를 변경/추가하는 비용을 낮춰서 초기 선택 실수 비용을 줄여줍니다.

그래서 결제수단을 빠르게 다변화해야 하거나, 특정 PG에 락인(lock-in) 되는 게 걱정될 때 붙이기 좋습니다. 지금은 하나로 시작하되, 다음 분기에 확장할 가능성이 높다면 특히 안정적인 선택이 됩니다.

물론 사실 이 모든 것보다 중요한 건 수수료가 아닐까요? 수수료는 조금씩 달라지기도 하고, PG를 제공하는 기업이 워낙 많은 만큼 따로 정리하지는 않았습니다. 국내 PG를 붙이기로 마음 먹었다면 웬만하면 여러 PG를 꼼꼼하게 검토하기를 추천드립니다. 여기 남긴 것들은 좀 특수한 성격을 가진 것들 위주입니다.

+ 그 전에, 불안을 줄이는 “고객 체크리스트” 먼저

첫 결제를 빨리 받는 것만큼, 사용자의 불안을 줄이는 것도 중요합니다. 거창한 문서가 아니라 최소한 아래 다섯 가지는 화면 어딘가에 보이게 두는 게 좋습니다. 여기 돈 내도 괜찮다는 느낌이 생겨야 결제 전환이 생깁니다.

환불 기준: 언제까지, 어떤 조건이면 환불되는지 한 문장으로
결제 실패 안내: 결제 오류가 나면 무엇을 확인해야 하는지
고객문의 채널: 이메일/오픈채팅 등 연락할 곳 하나는 고정
이용약관 위치: 링크 한 줄이라도 찾을 수 있게
영수증/세금 처리 방식: 영수증 제공 여부, 세금계산서 가능 여부 등

결국 첫 결제는 기능이 아니라 신뢰의 문제입니다. 정책을 크게 만들 필요는 없고 불안 포인트만 먼저 제거하면 됩니다. 그렇게 하면 결제, 연동, PG라는 큰 산도 생각보다 빨리 넘어갈 수 있습니다.

마치며

바이브코딩 시대에 결제의 난이도는 코드가 아니라 내 상황에 맞는 도구 선택에 가깝습니다. 연동만 붙이면 끝처럼 보이지만, 막상 들어가면 PG, 세금, 환불, 정책이 한꺼번에 따라오니까요. 그래서 복잡하게 시작하지 말고 딱 세 가지 질문으로 갈라타면 됩니다. 핵심은 (1) 국내/해외 (2) 과금모델 (3) 사업자 유무입니다.

이제 남은 건 실행입니다. 오늘은 내 서비스 조합을 먼저 적어보세요. 예를 들어 “빠른 시도 + 구독 + 사업자 없음” 같은 형태로요. 조합이 정해지면 루트는 거의 자동으로 좁혀집니다. Polar/Lemon Squeezy 중 하나를 골라 첫 결제까지 하루 안에 도달하는 걸 목표로 잡으면 됩니다.

그리고 여기서 중요한 마인드셋이 하나 있습니다. 진짜 어려운 건 결제를 붙이는 것이 아니라 결제해줄 유저를 찾는 것이라는 마인드입니다. 결제, 연동, PG에 에너지를 다 쓰며 매달리기보다 가능한 한 빨리 마케팅과 세일즈로 이동하는 편이 훨씬 현명합니다. 돈 낼 사람을 찾고, 그 사람의 마음이 어느 정도인지 알아보는 것이 바이브 코딩에는 더 중요할지 모르겠습니다.

]]>

코드는 줄고 판단은 남았다: AI 시대 개발자의 일일일

AI 에이전트 시대의 개발자는 어떤 모습이어야 할까?
40년 차 미국 빅테크 개발자부터, 쿠팡·네이버 개발자 인터뷰

“딸깍” 코드가 생성된다. 테스트 코드도 함께 따라온다. 레거시 분석은 몇 분이면 끝난다. POC는 하루 만에 마무리되고, 위키 문서까지 자동으로 정리된다. 요즘 개발자들 사이에서 종종 듣는 말이다. IDE보다 채팅창을 더 오래 바라보는 날이 늘어나고, 최근에는 채팅창을 넘어 클로드 코드 같은 도구를 사용하며 터미널만 바라보는 시간이 많아졌다. 우리는 점점 코드를 덜 쓰는 방향으로 가고 있다. 시니어 개발자가 될수록 설계와 문서화 같은 더 높은 레벨의 일을 해야 한다는 이야기는 오래전부터 있었다.

하지만 이렇게 빠르게 “코드를 덜 쓰는 개발자의 삶”이 올 줄은 예상하지 못했다. 그래서 문득 이런 질문이 들었다. 이게 맞는 방향일까?

주니어는 앞으로 어떻게 성장해야 할까?
리드 엔지니어의 역할은 사라지는 걸까?
우리는 지금 무엇을 공부해야 할까?

그래서 40년 차 미국 빅테크 프린시펄 엔지니어부터 쿠팡, 네이버 개발자에게 같은 질문을 던져보았다.

“AI를 어떻게 받아들이고 있으며, 실제 업무에서는 어떻게 활용하고 있나요?”

“우리는 AI와 페어 프로그래밍을 하고 있다”

첫 번째 인터뷰: 40년 차 미국 빅테크 개발자
그는 세미나에서 만난 40년 차 개발자였다. 아마존을 포함한 여러 빅테크에서 시스템을 설계했고, 현재도 미국 빅테크에서 프린시펄 엔지니어로 일하고 있다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

내가 개발을 시작한 80년대에도 AI는 핫한 토픽이었어. Smalltalk 머신도 있었지. 다만 그때는 연산 능력과 데이터가 부족했을 뿐이야. 페어 프로그래밍(Pair Programming)에 대해 잘 알지? 내가 이렇게 연차가 쌓이고 나와 함께 페어 프로그래밍을 하겠다고 찾아오는 사람은 없는데, 지금은 AI와 페어 프로그래밍을 하는 것 같아. 다만 이제는 상대가 사람이 아니라 모델일 뿐이지.

그에게 AI는 처음 보는 토픽이 아니었다. 하지만 예전과 달리, 지금은 이론과 실험을 넘어 실용적인 도구로 실제 업무에 적극 활용된다는 점이 다르다고 했다.

AI는 정말 페어 프로그래머처럼 동작한다.

코드를 제안한다.
리팩토링을 제안한다.
테스트를 작성한다
구조를 정리해준다.
문서를 만든다.

하지만 그는 중요한 차이를 강조했다. “AI는 비판하지 않아. AI와 대화해 보면 알겠지만, 아직까지는 내가 질문한 의도대로 답변하는 경향이 있지. 그리고 이것이 사람과의 대화에서 가장 큰 차이점이라고 생각해.”

사람과 페어 프로그래밍을 하면 의견에 대한 반박이 오가고, 논리와 근거에 따라 때로는 내 의견이 받아들여지기도 하고, 상대방의 의견이 받아들여지기도 한다. 그리고 그 과정을 거쳐 코드가 완성된다. 나의 경우에도 페어 프로그래밍을 하다가 코드 컨벤션 문제로 크게 충돌했던 경험이 있었는데, 결국 그 사람과 팀이 달라지고 나서야 해결됐다. 지금 생각해 보면 아주 중요한 일은 아니었는데 말이다. 이렇듯 사람과의 페어 프로그래밍은 때로 강한 논쟁을 수반한다.

하지만 이와 달리 AI는 사람이 반박하면 대부분 수용적인 입장으로 바뀌고, 이를 최대한 답변에 녹여내려 한다. 최근에는 이런 점 때문에 코드 리뷰 에이전트에 ‘무조건 반대하는 입장에서 코드를 리뷰’하는 역할을 부여하기도 한다는 글이 종종 보인다.

Q. 우린 어떤 것을 준비해야할까요?

다들 느끼겠지만, AI의 결과의 퀄리티는 질문과 설계의 퀄리티에 달려있어. 그리고 이 말은 내가 개발을 시작했던 40년 전에도 똑같이 들었던 이야기야. 물론 AI의 결과가 아닌 사람의 결과라는 차이점이 있지만 말이지. 따라서 내가 어떤 문제를 풀고자 하는지를 정확히 아는지 중요해, 이전에 주니어 레벨은 주어진 것만 완벽히 그리고 빠른 시간내에 구현하는 것이 최고였지. 그런데 이제는 AI가 더 빠르고 더 완벽해, 물론 질문이 완벽하다는 전제가 필요하지만. 아무튼 이젠 질문하는 법을 배워야해 다른 것은 그 다음에 챙겨도 돼.

생각해 보면 이런 류의 작업은 전통적으로 주니어를 넘어 시니어의 일이었다. 어떤 문제인지 정의하고, 어떤 방법으로 해결할지를 설계하고, 또 일을 분배하는 작업을 말한다.

이 문제의 이해관계자는 누구인가?
언제까지 이 문제를 해결해야 하는가?
어떤 제약 사항이 있는가?
성공적인 문제 해결의 기준과 측정 방법은 무엇인가?

그는 또 하나의 우려를 덧붙였다. “나는 주니어가 초기에 겪어야 할 고통이 없다는 게 두렵다고 봐.그러니 그 경험을 준비하라고 말해주고 싶지.”

버그를 추적하며 스택을 따라 내려가는 경험, 잘못된 설계로 장애를 내보고 복구하는 경험, 이런 감각은 자동으로 생기지 않는다고 그는 말했다. 그리고 이런 경험을 바탕으로 시스템을 설계하면서, 시스템의 가용성, 회복성 등 여러 가지를 고려하는 능력이 자연스럽게 길러진다고 덧붙였다.

“그렇다고 AI를 쓰지 말라는게 아니야. AI와 함께 버그를 추적하며 설계를 해보면 돼.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

크게 두 가지가 있어. 원래 나는 간단한 사이트를 만들 시간이 없어. 그래서 대부분 주니어 개발자에게 위임하곤 했지. 그런데 이번에는 AI와 함께 주말 동안 만들어봤어. 피그마 디자인과 함께 말이지. 그다음으로는 특정 DB 버그의 stack trace 전문을 읽게 했더니, 한 번에 오류를 찾아냈어. 그 방법론과 접근법은 내가 생각한 것과 매우 유사했고, 결과도 내가 예상했던 이슈와 정확히 일치했지.

그가 사용했던 방법은 우리가 사용하던 것과 크게 다르지 않았다. 다만 이전에는 시간이 없어 하지 못했던 일, 그리고 본인이 생각했던 검증을 누구보다 빠르게 실행해 주는 도구로 AI를 활용하고 있었다.

그리고 덧붙여 말했다. “AI는 도구야. 장인은 도구를 탓하지 않는다던데, 실력도 좋은데 도구까지 좋으면 더 빨리, 더 멀리 갈 수 있지 않겠나?”

이 말을 듣고, AI에 매몰되지 말자고 스스로 다짐했던 생각이 다시 떠올랐다. 40년 차인 그에게 AI는 본인의 일을 빼앗는 경쟁자가 아니라, 만능 도구에 불과했다는 점이 아이러니하게 느껴졌다.

스킬을 만드는 스킬을 만들어요

두 번째 인터뷰: 쿠팡 9년 차 프론트엔드 개발자
여러 스타트업을 거쳐 쿠팡에 들어간 9년 차 개발자인 그는 개발을 시작할 때부터 프론트엔드만 집요하게 파고들었다. 그런 그를 이전 회사 동료로서 인터뷰해 보았다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

핫하기도 하고, 회사에서도 AI를 업무에 많이 녹이려고 노력하고 있어요. 그리고 매니저와 1대1 미팅을 할 때도 요새 AI를 업무에 어떻게 사용하고 있느냐는 질문을 꼭 받아요. 제가 여기 들어온 지 이제 반년인데, 입사할 때부터 계속 같은 질문을 하시더라고요. 재작년까지만 해도 AI는 딱 제 연차에 엄청난 기회를 준다고 했어요. 절대적인 코딩 시간이 부족한 시니어 개발자에게 주니어 개발자를 여럿 붙여준다는 의미였지요. 그런데 지금 생각하면 아니에요. 모든 개발자에게 엄청난 기회를 주고 있다고 느껴요. 물론 AI가 여기서 더 발전하면, 그때는 어떻게 될지 모르겠네요.

쿠팡에서는 대부분의 팀이 AI 도구를 활용하고 있다고 한다. 그리고 전사적으로 할당된 AI 툴을 선점하기 위해 오픈런이 가끔씩 벌어지기도 한다고 한다.

“agent.md 문서를 계속 업데이트해요. AI가 일관된 방향으로 작업하도록 규칙을 정리하고, 또 계속 추가하죠. 그리고 AI가 리뷰를 해주는데, 코멘트나 컨벤션에 어긋나는 부분이 있으면 바로 규칙에 반영해요. 제가 작성하는 PR 중 10%는 오로지 AI를 위한 수정 사항이에요.”

그러면서 간단한 예시를 몇 개 말해줬다.

“테스트 코드는 XXXX 이런 식으로 작성해야 해요. jest 규칙에 언급되어 있죠. 하지만 AI가 그것을 누락했으니 규칙을 추가해야 하죠. CSS의 design token은 YYYY에 있는 파일에서 가져다 써야 해요. 그런데 기존 코드베이스에서는 이게 섞여 있어서 잘못된 방식으로 읽어오고 있으니, 여기도 규칙을 추가해야 해요.”

옆에서 보는 그의 모습은 마치 AI에게 코드 리뷰를 하고 있는 듯했다. 그리고 그는 이렇게 말했다.

“실은 지금 말했던 예시들은 제가 초반에 입사하고 나서 받았던 코드 리뷰 내용이에요. 처음에는 하나의 PR에 대충 30개의 리뷰가 달렸었어요. 그중에는 간단하지만 반복되는 리뷰들도 있었죠. 그래서 중간에는 자체적으로 ‘pr-check’라는 스킬을 만들어, 코드 리뷰에서 반복적으로 나오는 코멘트를 먼저 수정하는 과정을 거쳤었죠. 그리고 최근에는 AI 리뷰가 자동으로 도입되면서, 이런 스킬들을 바탕으로 agent rule을 만들어 계속 추가하고 있네요.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

쿠팡은 아니고, 이전 회사에서 CMS(Content Management System)를 자체적으로 구현해야 했어요. 콘텐츠가 정적인 텍스트로만 이뤄지면 참 좋겠지만, 실제로는 다양한 미디어 파일과 인터랙션을 포함한 데모형 콘텐츠가 많았죠. 그래서 ‘puck editor’라는 오픈소스를 가져와 구현했어요. 이 라이브러리는 제가 사전에 구현해 둔 컴포넌트를 바탕으로, 사용자가 drag & drop으로 컴포넌트를 가져와 콘텐츠를 수정할 수 있어요.

<출처: 공식 홈페이지>

그리고 저는 여기에서 사용되는 컴포넌트들을 AI를 이용해 대부분 만들었어요. 예전 같으면 해당 컴포넌트를 만드는 데 컴포넌트 하나당 며칠씩은 걸렸을 거예요. 그런데 AI를 이용해 회사에서 쓰는 디자인 시스템을 바탕으로 puck editor에 필요한 컴포넌트로 포팅하는 작업을 전체 3일 만에 끝냈어요. 기본적인 레이아웃용 컴포넌트와 데모용 컴포넌트까지 포함하면 대략 30개 정도를 지원했던 것 같은데, 이전에는 상상도 못 할 속도예요. 그리고 저는 이 시스템을 만들어보면서 AI가 수평 확장에 정말 강력하다는 걸 깨달았어요.

같은 구조를 여러 곳에 적용해야 할 때, AI는 압도적으로 빠르다. 그러면서 그는 말을 덧붙였다.

“그렇다면 개발자가 할 일은 수평 확장이 가능하도록, 수직 확장의 토대를 마련하는 것이죠.”

AI는 지시된 방향 안에서 훌륭하다. 하지만 방향을 설정하고, 수직 확장이 가능하도록 토대를 만드는 일은 여전히 인간, 곧 개발자의 몫이다.

Q. 요새 어떤 것을 공부하고 계시나요?

방금 말한 것처럼, 수직 확장을 위해 조금 더 깊은 내용을 공부하고 있어요. 최근에 읽은 책으로는 <멀티패러다임 프로그래밍(유인동 저)>을 포함해, 테스트 코드를 위한 책들을 중점적으로 보고 있습니다.

인터뷰이가 공유해 준 책 구매 이력 <출처: 작가>

요새 AI가 테스트 코드를 잘 만들어주잖아요. 그런데 그게 테스트 개수만 늘리는 건지, 테스트 커버리지만 채우는 건지 제가 잘 모르겠더라고요. 그래서 이번 기회에 테스트 코드에 대해 깊이 있게 학습해보려고, 우선 5권을 구매해서 보고 있어요. 지금은 4권째 읽고 있습니다. 여기에서 읽은 지식과 학습한 내용을 바탕으로, 테스트 코드를 위한 agent.md 파일을 작성하는 것을 목표로 삼고 있어요.

현재 제가 주로 일하는 서비스는 AI가 본격적으로 도입되면서 테스트 코드가 3배가량 증가했어요. 제 목표는 이것들을 더 이상 늘리지 않고, 유의미한 개수로 유지하는 거예요. 테스트가 많아질수록 CI/CD 시간이 오래 걸리고, 불필요한 테스트는 오히려 리팩토링 프로세스에도 좋지 않은 영향을 주니까요.

Q. 왜 이렇게 테스트 코드에 진심이세요?

요즘 일부에서는 ‘코드를 안 보고 배포한다’는 말도 나오는데, 저는 AI를 신뢰하는 것과 판단을 위임하는 것은 다르다고 생각해요. 만약 제가 혼자 일하고 모든 책임도 혼자 진다면, 코드를 안 보고 배포할 수도 있겠죠. 하지만 실제 제품은 혼자 힘으로 동작하지 않아요. 따라서 안 보고 배포한다는 말은, 나는 책임질 수 없으니 너희가 책임지라는 의미처럼 들려요.

그렇지만 또 AI가 생성하는 코드를 안 쓸 수는 없죠. 저는 AI가 생성한 코드의 책임을 테스트 코드에서 찾아보고 있어요. 요새는 ‘테스트를 통과하면 제대로 된 기능이다’라는 말도 유행하고 있어요. 이게 맞는 명제인지는 모르겠지만, 현실적인 타협안이라고 생각하고 있습니다.

9년 차 개발자는 책임을 질 수 있는 수준으로 AI를 활용하고 있었고, 그 책임을 위해 여러 가지 자신만의 규칙과 환경을 만들어가며 깊이 공부하고 있었다. 그렇다면 규칙은 어떻게 세우고 있는지 물어봤다.

“요새 많이 하는 것 중 하나는 ‘이때까지 대화 중에 스킬이나 룰로 만들 수 있는 것이 있으면 만들어줘’라는 명령어예요. 그리고 이를 바탕으로, 위에서 말한 스킬을 만드는 스킬(/create-skills)을 커스텀해서 만들고 있어요.”

스킬을 만들기 위한 스킬이라니, 처음 재귀 함수를 봤을 때처럼 오묘하고 신기했다.

나는 직접 코드를 안 쓴 지 두 달째다

세 번째 인터뷰: 네이버 12년 차 백엔드 개발자
그는 프론트엔드로 시작해 백엔드를 거쳐, 현재는 풀스택으로 일하고 있다. 그리고 이제 막 매니저 역할을 시작한 초보 매니저이기도 하다.

Q. 요새 AI가 핫한데, 어떻게 느끼시나요?

갑자기 생각난 건데, 올해(인터뷰 날짜 기준 3월 초)에는 IDE를 안 켜본 것 같아요. 갑자기 소름이 끼치네요. AI가 핫한 만큼 저도, 그리고 조직도 AI에 발 빠르게 적응하려고 준비하고 있어요.

IDE를 안 켠다고 해서 개발을 안 하고 있는 것은 아닙니다. 오히려 PR 양은 이전보다 더 늘어났어요. 저는 주로 클로드 코드를 사용하고 있는데요. 문서와 지라 티켓에 상세하게 작성된 PRD(Product Requirements Document, 제품 요구사항 정의서의 약자로 서비스나 기능의 목표, 타깃 고객, 핵심 기능, 성공 지표 등을 명확히 정의해 개발팀, 디자인팀 등 이해관계자와 공유하는 문서)를 클로드 코드가 알아서 가져와 백엔드 코드를 작성해줘요.

물론 제가 하는 일이 단순히 API를 만드는 것뿐만 아니라 다양하게 있지만, 그래도 그중에서 가장 많은 시간을 잡아먹는 것은 단연 API를 만드는 부분이죠.

그는 최근 IDE를 사용하는 시간이 눈에 띄게 줄었다고 말했다. 그렇다면 개발 시간은 과연 줄어들었을까?

“단순히 AI가 있어서 개발 시간이 10분의 1로 줄었나? 생산성이 10배, 100배가 되었나? 이런 느낌은 아니네요. 제가 하는 업무가 단순히 코딩이 전부가 아니고, 또 AI가 이렇게 발전하기 전에도 코딩 그 자체가 시간을 가장 많이 잡아먹는 일은 아니었거든요. 요즘도 그렇고 이전에도 코딩보다는 컨텍스트를 정리하고 문서화하는 시간이 더 길어요. 여러 가지 문서를 읽고 R&R(Role & Responsibilities의 약자로, 조직이나 프로젝트 내에서 각 구성원이 맡은 ‘역할과 책임’을 의미)를 정리하는 일이죠. 대신 한 가지 고무적인 점은, 제가 하는 컨텍스트 정리와 문서화 작업이 실제로 개발 속도를 끌어올린다는 점입니다.

제가 이 작업을 하는 이유는 개발자들(프론트엔드, 백엔드)에게 스펙을 정의하고 전달하기 위해서였어요. 때로는 기획자의 역할도 해야 하니, 이런 부분을 구체화하고 통일한 문서를 바탕으로 기능을 만들기 위해 시간을 들여 정성껏 작성하고 공유하는 것이었죠. 물론 이 작업이 개발자들의 일을 줄여주기도 합니다. 제대로 된 문서는 잘못된 개발 방향을 초반부터 걷어내고, 불필요한 의사소통 비용을 줄여주니까요. 하지만 이게 직접적으로 코딩 그 자체의 속도에 영향을 주지는 않았어요.

그런데 AI가 본격적으로 업무 프로세스에 녹아들면서 달라졌어요. 제가 만든 문서는 AI가 일을 한 번에, 그리고 제대로 하게 만드는 잘 정리된 Plan 문서로 동작합니다. 실제로 저는 업무를 정리하면서 해야 할 To-do list를 만드는데, 이것조차 AI를 잘 동작하게 하는 하나의 방법론으로 작동합니다.”

Q. 최근 업무에서 AI를 활용한 경험에 대해 알려주세요.

아마 많은 분들이 직접적인 개발 과정에서 AI를 활용한 경험을 말씀하실 텐데요. 저는 오히려 비개발적인 부분에서 AI를 활용하는 일이 생산성을 더 높여준다고 생각합니다. 예를 들어, 매니저인 저에게 지라 티켓이나 일정을 관리하는 일은 항상 어렵고 큰일이지만, 사실 하기 싫은 일이기도 하죠. 왜냐하면 그 많은 지라 티켓을 일일이 확인하면서 기능 개발이 어디까지 왔는지, 또 일정은 잘 진행되고 있는지 체크하는 건 너무 번거로운 일이기 때문이에요.

지라 대시보드나 여러 기능도 있지만, 많은 개발자분들이 경험적으로 느끼시겠지만 생각보다 지라 티켓이나 일정 관리를 꼼꼼히 하지 않아요. 주로 개발을 시작할 때 한 번, 그리고 개발이 전부 마무리돼 ‘완료’ 처리할 때 한 번, 이렇게 두 번 정도만 상태를 변경합니다. 이게 개발자 입장에서는 꽤 번거로운 일이거든요. 그래서 저는 이 프로세스의 상당 부분을 클로드 코드를 이용해 자동화하고 있습니다.

클로드 코드를 연결해 지라 티켓을 가져온 뒤, 어떤 작업을 시작할 거라고 하면 클로드 코드가 다음 작업을 진행해줍니다.

지라 티켓 status 변경
지라 티켓 번호를 포함한 브랜치 설정
해당 브랜치를 기반으로 GitHub draft 작성

이렇게 되니 ‘지라 대시보드와 GitHub pull request에서 누가 어떤 작업을 진행 중이구나’를 한눈에 볼 수 있더라고요. 그리고 하루에 한 번씩 일정 관리 크론잡도 돌고 있는데요. 지라 티켓과 GitHub 정보, 그리고 일정 정보를 바탕으로 일이 어느 정도 진행되고 있는지 알려주는 스크립트입니다. 저는 이것을 통해 매니저 역할을 해 나가고 있어요.

그러면서 그는 클로드 코드에서 해당 화면을 보여주었다. 그의 클로드 코드는 터미널 기반이지만, 한껏 커스텀되어 필자가 보기에도 깔끔한 하나의 매니저 도구처럼 보였다.

“그리고 하나의 작업이 더 있어요. 제가 오늘 하루 동안 작업한 내용을 바탕으로 성과 관리 문서를 생성합니다. 그리고 주간, 월간, 분기 단위로 제 성과 관리를 해가고 있어요. 아직 이 자동화를 시작한 지 반년이 안 돼서 연간 단위는 없지만, 지금 추세라면 연간 성과 관리도 잘할 수 있을 것이라 생각합니다.”

그가 자동화에 푹 빠져 클로드 코드에 대해 설명하던 그 순간은, IDE를 몇 달 동안 켜지 않았음에도 가장 개발자답게 보이는 순간이었다.

Q. 요새 어떤 것을 공부하고 계시나요?

“제가 학부생 때는 동기들끼리 마우스 없이 코딩하는 날 같은 것도 만들어서 했었어요. 그때는 vim으로 빠르게 코딩하는 게, 뭔가 동기들 사이에서 실력의 척도였어요. 초등학교 때 타자 수가 빠르면 컴퓨터를 잘하는 사람 취급받는 것처럼요. 생각해 보니 그때도 속도가 전부였네요. 아무튼 그때 저는 코딩을 잘하기 위해 도구 사용법을 따로 시간을 들여 공부했어요. 그리고 AI도 마찬가지라고 생각해요. 시간을 들여 익혀야 해요. 우리가 vim 수련을 한 것처럼요.

요새는 또 하네스 엔지니어링(인공지능 모델, 특히 LLM(거대 언어 모델)을 감싸서 그 능력을 실전에 안전하게 활용할 수 있도록 통제하고, 도구와 연결해 실제 행동을 수행하게 하는 외부 소프트웨어 프레임워크 또는 구조)이나 AI 오케스트레이션(거대 언어 모델(LLM), 이미지 모델, 데이터베이스 등 서로 다른 AI와 시스템을 하나의 워크플로 안에서 지휘자처럼 통합·관리해, 단일 모델로 해결하기 어려운 복잡한 문제를 풀고 효율을 높이는 기술) 같은 것들을 어떻게 활용할 수 있을지 고민해보고 있어요.

그리고 이런 것들은 때로 너무 빨리 변해서, 제가 공부하기도 전에 새로운 방법론과 패러다임의 변화가 일어나기도 합니다. 그래서 불안하기도 하죠. 그래도 어쩌겠습니까? 다들 AI라는 비행기를 타고 날아가고 있는데, 저만 뛰어갈 수는 없잖아요.

신이 나서 클로드 코드를 만지고 있는 그의 모습에서, 어쩌면 AI라는 비행기의 속도보다 하늘을 난다는 그 기술 자체에 매료된 한 사람을 본 것 같았다.

세 명의 개발자와의 인터뷰를 마치며

세 사람의 이야기를 듣고 나니 한 가지는 분명했다. AI가 등장했다고 해서 개발이라는 일이 완전히 다른 일이 된 것은 아니라는 점이다. 다만 우리가 시간을 쓰는 방식이 조금 바뀌고 있을 뿐이다. 코드를 직접 작성하는 시간은 줄어들고, 문제를 정리하고 맥락을 설명하고 방향을 잡는 시간은 늘어나고 있다.

40년 차 엔지니어는 좋은 결과는 여전히 좋은 질문에서 시작한다고 말했다. 쿠팡 개발자는 AI가 잘 일하도록 규칙을 계속 추가하고 있었고, 네이버 개발자는 문서와 맥락을 정리하는 일이 개발 속도를 높인다고 했다. 세 사람의 이야기를 듣다 보니 결국 같은 결론으로 이어졌다. AI는 일을 더 빠르게 만들어주는 도구지만, 무엇을 만들지 결정하고 책임지는 일은 여전히 사람의 몫이라는 것이다.

그래서 요즘의 개발자는 코드를 얼마나 많이 쓰느냐보다 어떤 문제를 풀려고 하는지, 어떤 맥락에서 이 일을 하는지, AI에게 무엇을 맡기고 무엇은 직접 판단할지를 조금 더 깊이 고민하게 되는 것 같다. 아직 정답은 없다. 지금은 모두가 조금씩 자기 방식으로 실험해보고 있는 시기인 듯하다. 그래서 인터뷰를 마치고 나서 남은 질문은 이것 하나였다. “나는 오늘 AI에게 무엇을 시켰는가”가 아니라, “나는 오늘 어떤 문제를 풀려고 했는가?”라는 것. 여러분은 어떻게 생각하시나요?

]]>

요즘IT » AI » 피드

클로드 코드 제대로 써보신 분! <클코나잇 2> 발표자 모집

클로드 코드 현업 경험담을 나눠주실 발표자를 찾습니다!

➡️발표자 신청하기

클로드 코드, 지금 어디까지 왔나요?

이런 이야기 환영해요

발표 안내

신청 방법

발표자에게 드리는 것

클코나잇은?

“이걸 누가 관리하나요?” GEO 자동화가 필요한 이유

GEO가 필요한데, 어떻게 적용할 것인가?

GEO 전략을 실제 서비스에 적용할 때 마주하는 문제

AI 기반 구조화 데이터 생성 파이프라인

CDN 엣지 기반 GEO 자동 삽입 아키텍처

GEO 적용 이후 무엇을 확인해야 하는가?

JSON-LD가 전부는 아니다

GEO는 이제 콘텐츠 전략을 넘어선 플랫폼 전략

16년 된 백준(BOJ)이 문을 닫습니다

1. 써볼 것: 노트북 닫아도 PR 리뷰하고 알림 분류하는 자동화 기능

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

어떻게 쓰나요?

2. 참고할 것: 16년간 한국 개발자와 함께한 백준이 문을 닫습니다

BOJ가 어떤 곳이었나요?

무엇이 남고, 무엇이 사라지나요?

무엇을 얻어가야 하나요?

3. 적용해볼 것: AI로 만든 환자 관리 앱이 30분 만에 털린 이유

무슨 일이 벌어졌나요?

기술적으로 무엇이 빠져 있었나요?

왜 이런 일이 생기는 건가요?

적용해볼 질문

실행해볼 수 있는 것

오늘 내용, 이렇게 적용해보세요

왜 개인 위키는 실패할까? 안드레 카파시의 ‘LLM 위키’

‘LLM 위키’로 지식을 복리로 쌓는 방법

부담이 쌓이면 위키는 멈춘다

내가 소스를 넣으면 LLM이 위키를 쌓는다

AI가 정리까지 해주면, 생각은 누가 하지?

1) 하나의 주제를 정합니다

2) 스키마 파일을 먼저 씁니다

3) 아티클 하나를 넣어보세요

마치며: 유지 관리 비용이 낮아지면 지식은 복리로 쌓인다

4계층 문서 체계로 만드는 AI Driven 쿠버네티스 운영 표준

문제 인식: 제한된 리소스의 제약

전통적 접근의 한계

4계층 문서 체계의 탄생

Layer 1: work-plans, 사람이 읽는 계획서

Layer 2: claude-context, AI를 위해 증류한 문서

Layer 3: command-guardrails, AI의 행동 제어

Layer 4: helm-values, IaC에 가까워진 계층

Tip. 왜 AI를 위한 문서는 영어로 증류해야 하는가

CLAUDE.md: AI가 가장 먼저 읽는 행동 규칙

settings.local.json

4계층 문서에 기반한 운영 전략과 도입 방법

1. GitAIOps

2. AI에게 맡기는 것의 경계

3. DEV에서 PROD로: Guardrail 재사용 패턴

4. 생산성 변화

5. 조직에 적용할 점진적 도입 로드맵

마치며: DevOps/SRE의 역할 변화

부록 1: AI의 기억 관리를 위한 Memory 시스템

부록 2: 옵저버빌리티 감사 데모로 직접 해보기

작가

AI 에이전트 많이 만든다고 AX가 아니다

성공적인 AX의 모습을 상상할 수 있는가

AI 도입 속도는 빨라졌지만, 검증은?

바이브 코딩, 엔터프라이즈에서 조심해야 하는 이유

AI 교육만으로는 부족하다: 실행 환경이 필요한 이유

1단계: AI를 많이 쓸 수 있는 환경 조성

2단계: AI 챔피언 양성

3단계: 실행 생태계 조성

AI 에이전트를 많이 만들면 AX 성공인가

혁신에는 레이어가 있다

알고리즘 전문가가 하루 아침에 PM이 되지는 않는다

기준 없이 시작하면 성과도 보이지 않는다

자동화했다고 끝이 아니다

에이전트 오너십이 필요하다

AX를 하고도 남는 질문: 그래서, 살림살이 나아졌나

자바 vs. 파이썬: 더 나은 에이전트 개발 언어는?

LangGraph 아키텍처