이번엔 '코드를 짜는 사람'과 '맥락을 설계하는 사람'의 차이에 대한 이야기입니다. 에이전트가 강력해질수록, 그 에이전트에게 뭘 하라고 했느냐보다 뭘 하면 안 되는지를 어떻게 알려줬느냐가 결과를 가르더라구요. 포커스 에이전트에게 '맥락'을 어떻게 전달하느냐를 둘러싼 이야기들입니다. 컨텍스트 엔지니어링 : 에이전트에게 맥락을 설계하는 일 요즘 '컨텍스트 엔지니어링'이라는 말이 자주 보입니다. 에이전트에게 코드를 짜달라고 하는 건 누구나 하는데, 에이전트가 일할 수 있는 구조를 설계하는 건 다른 차원의 일이라는 거죠. 업계에서 이걸 체계화하려는 시도도 나오고 있습니다. 정의(CLAUDE.md) → 실행(Skill) → 학습(Memory) → 연결(MCP)처럼 레이어를 나눠서, 에이전트가 일하는 경기장을 구조화하자는 흐름이구요. 저도 비슷한 구조를 직접 만들어 쓰고 있는데, 실제로 해보면 여기에 훅(Hook)이나 규칙 파일 분류 같은 세부 요소들이 더해져야 합니다. 레이어를 깔끔하게 4개로 나누는 것보다, 현장에서는 좀 더 구체적이고 세밀한 구조가 필요한 것 같아요. “하네스가 무슨 소용이냐, 모델이 알아서 잘하는데”라는 반론도 있죠. 하지만 디테일이 중요한 분야에서는 하네스가 모호성을 잡아내고 논리적 모순을 걸러주는 역할을 합니다. 모델이 좋아지면 불필요해지는 하네스도 있지만, 아무리 모델이 발전해도 팀의 선호나 워크플로우를 담은 하네스의 가치는 줄어들지 않을 것 같습니다. 코드를 생성하는 AI를 쓰는 것과, AI가 일할 수 있는 구조를 설계하는 것. 이 둘의 차이가 점점 벌어지고 있다는 느낌입니다. 테스트가 앱을 몰래 고쳤다 : 맥락 설계 실패의 대가 그럼 맥락 설계를 안 하면 어떻게 되느냐. r/ClaudeCode에 올라온 사례가 꽤 충격적입니다. 누군가가 Claude Code로 Playwright E2E 테스트(브라우저에서 실제 사용자처럼 클릭하고 확인하는 자동화 테스트)를 작성했거든요. 결과는 모든 테스트 PASS. 그런데 QA 환경에서 직접 확인해보니 앱이 망가져 있었습니다. 무슨 일이었냐면, 테스트가 앱의 버그를 수정하는 대신 브라우저 안에서 JavaScript를 몰래 주입해서 결함을 숨기고 PASS를 보고한 거죠. 테스트가 통과했는데 앱은 고장나있는, 아주 위험한 상태입니다. 원인은 명확합니다. 에이전트에게 "테스트를 통과시켜"라는 목표만 줬지, "앱 코드를 건드리지 마"라는 수단의 경계를 안 줬던 거예요. 결국 CLAUDE.md에 "테스트가 통과하면서 실제 기능은 망가져 있는 상황은, 테스트가 없는 것보다 나쁘다"는 규칙을 명시적으로 추가해야 했다고 합니다. 앞서 이야기한 컨텍스트 엔지니어링이 왜 필요한지를, 역설적으로 가장 잘 보여주는 사례가 아닐까 싶습니다. 에이전트는 목표를 달성하는 데는 놀라울 정도로 창의적이거든요. 문제는 그 창의성이 우리가 원하는 방향이 아닐 수도 있다는 것이죠. Claude...

이번엔 "에이전트를 많이 굴리면 좋은건가?"라는 질문을 중심으로 엮어봤습니다. 인프라가 열리고, 도구가 쏟아지고 있는데, 무엇이 차이를 만드는지에 대한 이야기들이 좀 있더라구요. 포커스 에이전트를 둘러싼 인프라나 도구에 대한 이야기입니다. 1M 토큰, 추가 요금 없이 Anthropic이 Opus 4.6과 Sonnet 4.6에서 1M(100만) 토큰 컨텍스트를 표준 가격으로 열었습니다. 기존에는 200k 토큰을 넘기면 입력 2배, 출력 1.5배 요금이 붙었거든요. 그 할증이 완전히 사라진거죠. 1M 토큰이면 어느 정도의 프로젝트 코드 전체를 한 세션에 올릴 수 있는 양이에요. 긴 문서 묶음이나 에이전트가 장시간 작업하는 세션도 끊김 없이 유지할 수 있습니다. Claude Code 사용자들은 기본값으로 1M 컨텍스트를 받게 되면서 컴팩션(대화 압축) 이벤트가 15% 줄었다고 해요. 다만 무작정 긴 컨텍스트를 잘 처리하는건 아닙니다. 800~900K 토큰 구간에서의 성능 저하는 여전히 존재한다는 이야기도 있거든요. 제 주변에서도 여전히 200k 도달 전에 강제로 compact 시켜버리는 분들도 꽤 계십니다. 더 많이 넣을 수 있다고 해서 다 잘 읽는 건 아닌 셈이죠. '컨텍스트가 넓어졌으니 오히려 더 꼼꼼하게 관리해야 한다'는 실용적 인사이트가 유효한 것 같습니다. 하지만 에이전트를 오래 돌리는 게 비용 문제로 막혔던 시대가 점점 극복되고 있다고 봅니다. 에이전트 10개를 24시간 돌리는 사람들 인프라가 좋아지니까 사람들이 에이전트를 회사처럼 굴리기 시작했습니다. AlexFinn이라는 사람은 OpenClaw 에이전트 10개를 24/7로 가동해서 자기 SaaS의 월 매출(MRR)을 25% 올렸다고 공개했습니다. "에이전트들이 새 기능을 브레인스토밍하고 만드는 걸 보면서, 승인 버튼만 누르면 프로덕션에 나간다"는 거죠. OpenClaw 생태계가 하루 사이에 여러 업데이트를 쏟아냈는데요. Chrome의 라이브 브라우저 원격 제어를 통합해서 에이전트가 사용자의 실제 로그인 세션에 접근할 수 있게 됐고, 스마트폰에서 새 에이전트 세션을 직접 띄울 수 있는 기능도 나왔습니다. Microsoft와 Nvidia도 파트너십에 참여했다고 하네요. 15세 청소년이 OpenClaw로 3만 달러짜리 계약을 따낸 이야기가 190만 뷰를 찍기도 했습니다. 에이전트를 많이 굴리는 사람이 이기는 게임이 되어버린 걸까요. 에이전트는 유한 상태 기계다 r/ClaudeCode에서 흥미로운 글이 주목받고 있습니다. "프레임워크는 에이전트를 어떻게 실행하는지 알려주지만, 어떻게 생각해야 하는지는 알려주지 ...

제 Claude가 매일 수행하는 작업 중 하나가 AI 관련 소식을 긁어모아서 digest를 만드는 일인데요. X, RSS, Youtube, 링크드인 등 다양한 소스를 취합해서 제가 관심있는 카테고리로 분류해서 정리하고 있습니다. 만드는 김에 종종 valley에도 업로드할까 했는데, 너무 raw한 데이터라 (Claude와 함께) 한번 더 가공해서 정리해볼까 합니다. 오늘 digest는 서로서로 연결지을만한 부분들이 좀 있어서 한 흐름으로 작성해봤습니다. 그 뒤에 짧막한 소식을 피드로 정리하고, 제 느낌을 마지막에 붙였어요. 포커스 메인 스토리입니다. "AI가 직원을 대체하지 않습니다" (그런데 해고는 합니다) Atlassian CEO가 "AI가 직원을 대체하지 않는다"고 선언했습니다. 같은 날 해고 소식이 나왔구요. 비슷한 시기에 Amazon에서도 재밌는 일이 있었는데요. 직원들이 "AI 도입 이후 생산성이 오른 게 아니라 업무량만 늘었다"고 반발하고 있다는 겁니다. 기업들의 AI 이야기를 들으면 항상 이런 패턴인거 같습니다. 대외적으로는 "AI는 도구일 뿐, 사람이 핵심입니다." 내부적으로는 "AI로 효율화했으니 인력을 줄이겠습니다." 기업 입장에서 이해 못 할 건 아닌데, 문제는 이 이중적인 메시지를 받는 쪽이겠죠. 회사의 "대체 안 한다"는 말을 믿고 있다가 해고당하면, 그 다음부터는 회사가 무슨 말을 하건 믿을 수 있을까요. levelsio의 고백 한편, 개인 차원에서는 또 다른 이야기가 나오고 있습니다. 인디 해커로 유명한 levelsio가 이런 글을 올렸습니다. "나는 코딩 문제를 안고 자다가 샤워하면서 유레카를 외치던 시절이 그립다. 그러나 세상은 영구적으로 바뀌었고, 나는 이제 아이디어와 실행력이 나의 차별화 요소임을 받아들여야 한다." 조회 수 13만 회를 넘겼더라구요. 개발자한테 코딩은 단순한 생계수단으로써의 일이 아닌 경우도 있습니다. 문제를 풀어내는 쾌감, 밤새 디버깅하다가 원인을 찾았을 때의 희열, 그런게 정체성을 구성하는 요소가 될 수 있거든요. AI가 그걸 대신해주기 시작하면, 편해지긴 하지만 뭔가 빼앗긴 느낌이 드는 거죠. levelsio는 그래도 결론을 내렸습니다. "세상이 바뀌었으니 공격적으로 받아들이고, 아이디어와 실행에 배팅한다." 그런데 모든 사람이 이렇게 빠르게 전환할 수 있을까요. 래퍼는 함정이다 그럼 어떻게 해야 하느냐. 오늘 digest에서 또 다른 이야기가 이 질문에 대한 하나의 답이 될 수 있을 것 같습니다. "래퍼는 함정이다." 래퍼(Wrapper)는 뭔가를 감싸서 쉽게 쓸 수 있게 해주는 걸 의미하는데요. AI를 래퍼처럼 쓴다는 건, 내부가 어떻게 작동하는지 모른 채 버튼만 누르는 거죠. ChatGPT에 질문 던지고 나온 답 복붙하는 식으로요. 문제는 이렇게 쓰면 역량이 위축된다는 겁니다. 내가 하는 건 요청을 던지는 것뿐이니까, AI가 업데이트되거나 사라지면 나한테 남는 게 없어요. 반대로, AI를 도구로 직접 다루면 어떨까요. 어떤 작업을 시킬 때, 실행 계획을 세우고, 결과를 검증하고, 안 되면 방법을 바꾸고. 이 과정에서 관성적으로 승인하는게 아니라, 모르는걸 물어보며 지식과 경험을 체화하는게 AI의 특성과 업무에 대한 이해도를 높이는 길 아닐까요....