"에이전트가 슬랙에 직접 업무 보고를 올리는 시대. 그게 당연해진 날이 있었다."
들어가며
AI 뉴스는 매일 쏟아진다. 근데 정작 현장에서 개발자들이 실제로 무엇을 쓰고, 무엇 때문에 흥분하고, 무엇에 막히는지는 잘 보이지 않는다. 이 글은 2026년 3월 어느 하루, 테크 회사 내부 채널에서 오간 이야기들을 바탕으로 지금 AI 개발자들의 관심사를 정직하게 정리한 기록이다.
1. "10번 중 8번 한 방에 된다" — Claude Code + Superpowers
한 개발자가 올린 짧은 추천 글이 채널에서 가장 많은 반응을 얻었다.
"cc로 개발할 때 아래 순서대로 하는데요. 이걸로 하면 거의 10번에 8번은 한방에 성공하는 것 같네요."
그가 소개한 Superpowers 플러그인의 워크플로우는 단순하다:
1. superpowerpowers:brainstorming → 구조와 접근법 먼저 탐색
2. superpowerpowers:writing-plans → 구체적인 실행 계획 수립
3. superpowerpowers:executing-plans → 실제 코드 생성 및 실행
포인트는 LLM에게 바로 코드를 시키지 않는다는 것이다. 먼저 생각하게 하고, 계획을 세우게 하고, 그 다음에 실행하게 한다. 인간 개발자가 일하는 방식과 같다.
팀원들 반응도 뜨거웠다. "목업을 보여줘서 너무 좋아요", "frontend-design 플러그인이랑 같이 쓰면 진짜 요물이네요."
Superpowers 5.0 업그레이드 이후엔 새 기능 추가 시 brainstorming 단계에서 UI 구성까지 자동으로 추천해준다고 한다. 시키지도 않았는데.
왜 중요한가: 프롬프트 하나로 모든 걸 해결하려는 접근은 이미 낡았다. 복잡한 개발 작업일수록 단계 분리(brainstorm → plan → execute) 전략이 성공률을 크게 높인다. 이건 Claude Code뿐 아니라 모든 AI 코딩 도구에 적용되는 원칙이다.
2. 에이전트가 슬랙에 업무 보고를 올렸다
이날 채널에서 가장 흥미로웠던 장면은 따로 있었다.
멀티에이전트 오케스트레이션 관련 글타래에서, caz라는 내부 AI 에이전트가 직접 슬랙 스레드에 참여해 task.json 상태를 보고했다:
🔵 reviewing (1건)
• aip-openclaw-a2a-plugin — AIP ↔ OpenClaw A2A Plugin 설계 및 구현 플랜
- plan.md 작성 완료, Zac 검토 대기 중
✅ done (2건)
• hn-fe-20260308 — 해커뉴스 FE 요약 (완료)
• lifecycle-viz-20260309 — 요청 의사결정 트리 + lifecycle 다이어그램 (완료)
회사 내부에서 AI 에이전트가 이미 실제 업무에 투입되어 PR을 올리고, 상태를 보고하고, 다음 작업을 기다리고 있다. SF 얘기가 아니다.
이 과정에서 나온 중요한 논쟁이 있었다. OpenClaw vs Paperclip — 둘 다 멀티에이전트 오케스트레이션 도구지만, 개발자가 느끼는 경험은 달랐다.
"OpenClaw 사용하면 느낀 게, 에이전트가 작업하는 게 정말 잘 하고 있는지가 잘 안 보여서 좀 답답했는데요. Paperclip은 대시보드 상에서 투명하게 에이전트 로그와 명령어들, 에이전트 간 핸드오프 과정이 나오고 사람이 개입해야 하는 부분은 Inbox에 에이전트가 의사회 결재 같은걸 올리니까 좀 편한거 같네요."
핵심 차이: 가시성(Visibility). 에이전트가 뭘 하는지 보이지 않으면, 아무리 잘 작동해도 실무에서 쓰기 어렵다.
그리고 이런 실용적 결론이 나왔다:
"슬랙을 메인으로 업무하기는 쉽지않고, 슬랙을 트리거, 승인 레이어 정도로, 실제 작업은 저런 개인 에이전트 세션에 접근하게 하는게 좋을거같아요."
슬랙은 알림창이고, 실제 작업은 에이전트 세션에서. 역할 분리가 명확해졌다.
왜 중요한가: AI 에이전트의 도입 장벽은 성능이 아니라 신뢰다. 신뢰는 가시성에서 온다. 에이전트가 잘 작동하고 있다는 걸 사람이 확인할 수 있어야 실제 업무에 쓸 수 있다. UI/UX 레이어는 AI 제품의 핵심 경쟁력이 될 것이다.
3. Claude Code 비용을 90% 줄이는 법 — 그리고 캐시 이야기
"Claude Code 비용을 90% 줄이는 숨겨진 설계 원칙"이라는 제목의 LinkedIn 포스트가 공유됐다. 그에 달린 코멘트가 인상적이었다:
"컴패션 같은 컨텍스트 엔지니어링 할 때 캐시 히트도 고려하나요?"
이건 단순한 질문이 아니다. Claude API는 동일한 프롬프트 prefix가 반복될 때 Prompt Caching 기능으로 토큰 비용을 대폭 줄여준다. 그런데 대부분의 개발자가 컨텍스트 엔지니어링(어떤 정보를 어떻게 넣을지)에는 공을 들이면서, 캐시 히트율(같은 prefix가 얼마나 재사용되는지)은 신경 쓰지 않는다.
실제로 멀티에이전트 환경에서 에이전트들을 여러 개 돌리면 토큰 소모가 폭발적으로 늘어난다. 누군가는 "일단 Codex 무료로 쓰고 있으니까"라고 했지만, 프로덕션 환경에서는 이 비용이 진짜 문제가 된다.
90% 절감 공식 (추정):
- 시스템 프롬프트는 고정 → 캐시 히트율 극대화
- 컨텍스트는 필요한 것만, 순서를 일관되게 유지
- 멀티에이전트면 에이전트별 캐시 전략을 별도 설계
왜 중요한가: AI 비용 최적화는 이제 엔지니어링 역량이다. 모델 선택만큼이나 캐싱 전략, 컨텍스트 설계, 호출 구조가 실제 비용을 결정한다.
4. promptfoo — "보안 테스트 도구"이지 "보안 보증서"가 아니다
AI 보안 레드팀 도구 promptfoo가 공유됐다. 질문은 날카로웠다: "이걸로 테스트 통과하면 보안이 좋다고 할 수 있을까요?"
QueryPie Bot의 답변이 명쾌했다:
promptfoo는 "보안 테스트 도구"이지 "보안 보증서"가 아닙니다.
- 할 수 있는 것: 알려진 취약점 패턴 탐지 (prompt injection, jailbreak, data leakage 등)
- 할 수 없는 것: 미지의 공격 벡터 탐지, Zero-day 예방
그리고 Luka가 냉정하게 정리했다:
"LLM 보안에 대해서만 본다면 사실 요런 스캐너가 많이 없는걸로 알고 있는데 인사이트는 줄 수 있을거 같습니다."
툴은 있지만 생태계는 아직 초기. promptfoo가 유용한 건 맞지만, LLM 보안의 완성이 아니라 출발점이다.
이상적인 3단계 보안 전략:
1단계: promptfoo로 기본 취약점 스캔 (자동화)
↓
2단계: 수동 Red Teaming (보안팀이 직접 공격 시뮬레이션)
↓
3단계: 프로덕션 모니터링 (실시간 이상 감지)
5. Meta가 Moltbook을 인수했다
마지막으로 가볍게. Meta가 AI 에이전트 소셜 네트워크 Moltbook을 인수했다는 소식이 Axios를 통해 전해졌다. 팀 반응은 간결했다: "이얼....", "씐쑤우!"
웃음 속에도 함의는 있다. 소셜 네트워크에 AI 에이전트가 참여하는 시대. 사람과 에이전트가 같은 공간에서 상호작용하는 플랫폼을 Meta가 직접 인수했다는 건, 이 방향에 대한 빅테크의 확신이기도 하다.
마치며 — 2026년 3월의 풍경
이 채널에서 하루 동안 오간 이야기들을 보면 몇 가지가 선명해진다.
1. 에이전트는 이미 팀원이다. caz가 슬랙에 업무 보고를 올리는 건 실험이 아니라 일상이었다.
2. 성능보다 가시성이 먼저다. 에이전트가 잘 작동하는 것만큼, 잘 작동하고 있다는 걸 사람이 볼 수 있어야 한다.
3. 워크플로우가 곧 실력이다. brainstorm → plan → execute. AI 도구를 잘 쓰는 건, 도구 선택이 아니라 사용 구조의 문제다.
4. 비용은 엔지니어링이다. 캐시 히트율, 컨텍스트 설계, 호출 최적화. AI 비용을 통제하는 능력이 엔지니어링 역량이 됐다.
5. 보안 생태계는 아직 초기다. 도구는 있지만 완성된 프레임워크는 없다. 여기서 기회가 있다.
이 글은 내부 AI 뉴스 채널의 실제 토론을 바탕으로 재구성했습니다.