Claude Code for Developers 밋업 후기

출처: https://luma.com/tzobcks8

 

Claude Code 커뮤니티가 주최하는 밋업을 다녀왔다. 

• 일시: 2026-04-30 10:00 ~ 12:00
• 형식: 발표 4 세션 + 네트워킹 Q&A

 

 

---

발표 메모

이 글은 밋업에서 들은 내용을 정리한 글입니다. 발표를 듣고 메모한 내용을 재구성하였으며, 이 과정에서 발표자의 의도와 다른 정보가 적혀있을 수 있습니다. 이후에 발표자 분들의 링크드인을 통해 발표 자료를 공유주실 예정입니다.

 

1. Claude Code 최신 업데이트 / 최훈민

4월 중후반에 추가된 주요 업데이트와 품질 이슈 공유

• /ultrareview: 클라우드에서 PR 리뷰 수행 (5/5까지 3회 무료)
• /usage: 사용량의 출처(도구, 세션 등)를 상세하게 보여줌
• session recap: 세션 이탈 후 복귀 시 컨텍스트 자동 요약
• claude --teleport: 웹/모바일 세션을 CLI로 전환
• /claude-api
  • migrate: 모델, 프롬프트 자동 업데이트 및 마이그레이션
  • managed-agents-onboard: 설정, 모니터링, 디버그 지원
• https://claude.ai/code 사이트 UI 개선

Claude Code

• prompt caching dashboard 추가
  • 캐시 히트율 ↑ = 비용 절감으로 이어지기 때문에, 대시보드를 통해 캐시 히트율을 높이려는 시도 가능
  • 대시보드에서 사용 현황 확인 가능
• managed agents memory
  • 기존: 세션 종료 시 기억 소실
  • 변경: 사용자 선호도, 반복 작업, 연락처 등 영속화 지원

📝 개인 메모
session recap를 보고 생각난 팁. 나는 현재 세션에서 갑자기 동작이 정지되거나 뭘 하고 있었는지 까먹어서 물어보고 싶을 때 /btw를 자주 쓴다. 현재 세션의 컨텍스트를 오염시키지 않으면서도 새로운 질문을 던질 수 있다.
- ex: /btw 지금 서브 에이전트 동작에 문제 있는지 확인해 줘

 

 

2. Claude와 함께라면 놀면서 온보딩 / 변규홍

클로드를 업무나 일상 등 다양한 방면으로 사례를 소개해주신 발표. 좋은 이야기를 많이 주셨는데 사례 위주다 보니 메모한 내용이 적다. 

 

활용 사례

• 복잡한 로직 분석 — 레거시 코드 흐름 빠르게 파악 및 개발
• 일상 활용 — 비행기에서 읽을 전자책 제작, 일상에 필요한 간단한 도구 만들기
• 커뮤니케이션 개선
  • 요구사항 전달 시 모호함 감소
  • 프로토타입을 직접 만들어 전달 가능

 

 

3. Ouroboros 딥다이브 — MCP Mesh와 Disposable Memory를 활용한 자율형 AI 하네스 / 이재규

우로보로스(Ouroboros)라는 하네스 오픈소스를 개발 및 운영하는 과정에서 얻은 인사이트를 공유해 주신 발표. 보통 '하네스 엔지니어링'에 대한 추상적인 개념만 설명하는 경우가 많은데, 재규님은 실제 구현한 사례와 아키텍쳐 등을 공유 주셔서 더 와닿았다.

 

Bitter Lesson

• Rich Sutton: "사람이 짜낸 도메인 지식보다, 연산량을 더 많이 투입한 일반적 학습 방법이 결국 이긴다"
• 참고: https://news.hada.io/topic?id=19154

AI 창업자의 씁쓸한 교훈 (Bitter Lesson) | GeekNews

 

LLM은 animal이 아니라 ghost다

• LLM = 인간 텍스트로부터 압축된 결과물
• 강력하지만 인간의 편향에 의존적

 

컨텍스트 엔지니어링의 한계

• 문맥이 길어지면 앞 내용을 잘 기억하지 못함
• 추론도 비용이기 때문에 무한히 늘릴 수 없음
• 초반에 준 지시가 뒤로 갈수록 흐려짐
• 빈칸을 그럴듯하게 채움 (할루시네이션)

 

해결 접근 - 세션 쪼개기

• 하나의 긴 대화로 모든 작업을 처리하지 않고, 아주 긴 프롬프트를 격리된 세션으로 분리
• 현재 세션이 더럽혀지거나 바닥나면 계속 이어가지 말고 독립 세션에서 진행
• 이 과정에서 인간이 컨텍스트를 직접 관리하기는 어려워 MCP 서버를 통해 구축
  • 메인 세션: 명령·결과 수집·오케스트레이션
  • 서브 에이전트: 작업 수행
  • 나뉜 작업 결과를 다시 모아서 최종 결과 생성
• 기존의 fat skill은 모델, 설정 등에 따라 결과가 계속 달라질 수 있다
• 수직적(vertical) fat skill이 아닌, 수평적(horizontal) 연결된 구조(shared coordination layer)로 확장

 

세션을 쪼개며 알게 된 점

• 도구가 LLM을 호출하는 구조로 바뀜
  • 기존: 특정 시점에 실행되는 hook 기반 제어
  • 변경: MCP가 실행 흐름 자체를 제어
• 오케스트레이션 과정 자동화
  • rule과 skill은 "부탁"에 가까움
  • 직접 독립 세션을 열고 다시 합치려면 spawn / schedule / collect 과정 필요
  • 이 오케스트레이션이 MCP handler 안으로 들어감
• 작업 흐름(call structure) 고정
  • 스킬은 멱등성이 없음 (모델이 바뀌면 처리 과정도 달라질 수 있다)
  • 세션을 쪼개는 과정에서 호출 순서를 고정하게 됨

 

Agent OS는 Contract Layer다

• 이러한 오케스트레이션 구조를 추상화한 것이 Agent OS
• Agent OS는 커널이 아니라 런타임과 에이전트 사이의 Contract Layer
• Agent OS: 에이전트 실행을 위한 상위 레벨 오케스트레이션 환경
• Contract Layer: 시스템 간 상호작용을 명확한 규칙(계약)으로 정의하는 계층

 

runtime 내부의 프롬프트가 아니라, agent를 가로로 묶는 OS contract primitive

 

 

4. K-FED — 수천 시간 삽질로 깨달은 AX의 진짜 의의 / 이선민

하네스 엔지니어링에 대한 개인적 견해와 다양한 시도를 공유한 발표. 암묵지라는 개념을 설명 주시면서 이를 어떻게 문서화하였는지에 대한 과정이 흥미로웠다.

엔지니어링의 진화

• prompt engineering → context engineering → harness engineering → problem engineering
• 하네스 엔지니어링은 마케팅 용어라는 말이 있음
• 하네스는 새로운 학문이 아님. 유사한 용어들이 이미 다양하게 존재.
• 하네스는 코드가 아니라 문제에 씌워야 한다 — 코드는 결과물, 문제 정의가 본질

 

Dev-Harness Mapping Table

• 하네스 용어가 사실상 기존 인프라/데브옵스 개념과 1:1 매칭된다는 것을 보여주는 표

 

암묵지 끌어내기

암묵지: 학습과 경험을 통해 개인에게 체화되어 있지만, 말이나 글로 표현하기 어려운 노하우나 경험적 지식

• 사례 - 한의학: 기술이 구두로 전수되고 사람마다 다르게 관리되고 용어가 다른 경우가 많음
• 동일한 개념 다양한 용어를 어떻게 다 커버할 것인가가 핵심 과제
• 최대한 많은 데이터를 모아 md로 전환
• 패턴을 파악하는 것이 중요

 

Polysona (오픈소스) 개발

• AI가 모를 수 있는 모든 컨텍스트(경쟁사 뉴스, 팀원과의 관계, 핸드폰 메모 등)를 모아 페르소나 생성
• 24시간 동작하는 AI - 온갖 곳에서 컨텍스트를 끊임없이 수집
• 심리학, 철학, 정신의학 기법 활용

 

 

5. 네트워킹 Q&A (11:30)

하네스 시작이 어려운 사람들을 위한 조언

• 잘 만들어진 하네스를 분석해 보기
  • 여러 구조를 뜯어보면 다양한 영감을 받을 수 있음
  • 어떤 것은 과하게 복잡하다, 어떤 추상화는 깔끔하다 등 비교 분석하는 것이 큰 도움
• 어렵게 생각하지 말 것 - "랄프 루프(Ralph Loop)에 종료 조건을 붙이는 것"만으로도 하네스
• 처음이라면 스킬을 깎아가며 다양한 시도해 보는 것을 추천

 

AI Slop Tossing 문제 & 코드 리뷰

AI가 만든 결과물을 검증 없이 던지는 문제

1. 코드가 아닌 ADR(Architecture Decision Record) 작성 및 리뷰
2. 코드 작성자가 스스로 생각하도록 유도하는 리뷰 — 이해 안 되는 부분은 리뷰로 남겨 답변하게 만들기
3. AI끼리 토론 (최대 횟수 제한두기) → 인간이 최종 리뷰

위 방법들과는 별개로 어떤 설계·결정이 있었는지 개발자가 반드시 알고 있어야 한다고 생각.

 

AI로 컨텐츠를 제작할 경우 잘못된 정보가 있지 않은가

• plan 모드 적극 활용해 확률을 줄임
• 할루시네이션이 발생 가능하다는 것을 인지해야 함

 

클로드 코드로 팀원과 협업하는 방법

• 팀 공유용 규칙·코드와 개인용 규칙·코드를 분리해야 함
• 하네스를 팀/조직 기준으로 강제하면 개인의 커스텀이 어려울 수 있음

 

AI 트렌드 습득 방법

1. 유사한 정보를 자주 보면 SNS 알고리즘이 자동으로 추천
2. 트렌드 팔로업을 일부러 안 함
   • 일주일 이상 지속되는 키워드만 인사이트가 있을 거라고 기대
   • 의외로 많은 기술이 원래 존재했지만 하드웨어 한계로 적용되지 못함. 이런 것들 위주로 확인

 

하네스 결과물이 만족스럽지 않은 상태라, 개선 방식에 대한 고민

• AI 생성 속도 > 인간의 인지 속도 → AI에 브레이크가 필요
• AI에게 이데아·온톨로지를 주입하면서 방향성을 스스로 인지·조정하게 함
• 가장 중요한 것은 아키텍처 설계 단계, 그 위에서 결과물이 잘 동작하는지 검증

 

AI와 직무 경계가 흐릿해진다에 대한 의견

• 모든 직군의 컨텍스트를 한 번에 넣기는 어려워서 혼자서 모든 걸 처리하는 건 아직 이른 이야기 같다
• 도메인 지식 깊이가 중요할까?
  • 도메인 지식을 넓게 익히고 도메인 간 링크하는 능력 중요
  • 도메인 지식을 깊게 파는 건 AI에게 시키는 것이 ROI 측면에서 유리하다고 생각

📝 개인 메모
고민 중에 현재 조직의 형태가 FE개발자만 BE개발자만 이런 식의 동일 직군에 대한 조직이어서, 특정 직군에 한정된 AI 활용이 이루어지는 것 같다(?)는 이야기가 있었다. 너무 단순하게 생각하는 것 같기도 하지만 나는 개인적으로 이는 내가 다른 직군의 업무에 계속 관심을 갖고, 원활한 커뮤니케이션을 할 수 있다면 큰 문제가 아닐 것 같았다. 이는 AI에 한정된 이야기가 아니라 어떤 업무를 개발로 자동화할 수 있을지 고민하는 등의 일도 마찬가지라고 생각했다.

 

 

---

밋업 후기

 

오랜만에 밋업에 참여했다. 최근 회사에서 Claude가 도입되어 관련 이야기를 듣고자 신청했는데, 특정 도구에 한정되지 않고 AI 전반에 대한 다양한 관점을 들을 수 있었다. 기존에 막연하게 생각하던 개념들이 조금 더 구체화된 느낌이었다.

특히 그동안 하네스 엔지니어링에 대한 추상적인 개념을 설명하는 자료는 많았지만, 실제로 어떻게 구현하고 적용하는지에 대한 사례는 접하기 어려웠다. 이번 밋업에서 공유된 사례는 절대적인 기준이라고 보기는 어렵지만, 실제 구현을 기반으로 한 이야기라는 점에서 참고할 만한 방향성을 제공해 주었다. 어떤 식으로 접근해야 할지에 대한 감이 조금 잡힌 만큼, 관련 오픈소스 사례들을 모아 비교해 보는 것부터 시작해보려고 한다.

트위터를 통해 다양한 AI 정보를 접하고 있지만, 새로운 정보가 빠르게 소비되다 보니 충분히 소화하기도 전에 다음 흐름으로 넘어가는 경우가 많았다. 반면 밋업 발표는 내용을 정리하고 구조화하는 과정을 거치기 때문에, 일시적인 유행보다는 비교적 오래 남는 이야기라는 인상을 받았다.

한편 컨텍스트 수집에 대한 고민도 남았다. 온오프라인 혼합 근무 환경에서 온라인 작업은 기록이 비교적 잘 남지만, 오프라인에서의 구두 논의는 쉽게 휘발된다. 회의록으로 일부 보완할 수는 있지만, 항상 기록을 남기기 어려운 상황도 많다. 과제를 병렬로 진행하다 보면 회의 간 간격이 촘촘해 바로 정리하기도 쉽지 않다. 이 문제를 어떻게 해결할 수 있을지 질문해보고 싶었지만, 시간 관계상 답변을 듣지는 못했다.