핵심 논쟁
AI가 더 강해질수록 사람은 덜 배워도 되는가, 아니면 맥락과 기준을 더 잘 설계해야 하는가가 중심이었다.
방 헤더 · 2026-06-05
[실밸개발자] 바이브코딩 클럽
오늘의 한 문장: 하네스를 만들 때 reviewer 역할, ADR, 계정 정책, 보안 권한, 디자인 QA를 체크리스트로 분리해야 한다.
705메시지
69참여자
4주요 주제
2짧은 기록
대화 타임라인
-
1
새벽
에이전트 하네스 실험이 예상 가능한 자동화에서 모르는 영역을 가르치는 동료로 넘어간 사례가 공유됐다.
-
2
오후와 밤
계정 밴, 토큰 소진, 회사 GitHub 계정, 디자인 도구, 부서 하네스 도입까지 실무 리스크가 이어졌다.
핵심 논쟁
합의점
코드 작성 능력보다 source of truth, 보안 경계, 검증 루프, 디자인 판단을 정리하는 사람이 더 중요해졌다.
주제별 깊이 읽기
1
하네스 설계
Thinking budget과 self reviewer가 바꾼 하네스 실험
왜 중요한가
고난도 병렬 과업에서 thinking budget과 다중 reviewer를 늘리자 에이전트가 예측 범위를 넘어선 시나리오와 예외를 제안했다는 경험담이 핵심이었다.
깊이 보기
하루의 첫 대화는 그동안 만든 agent와 하네스가 토큰을 태우며 어떤 수준까지 갈 수 있는지에 대한 실험담이었다.
- 고난도 병렬 과업에서 thinking budget과 다중 reviewer를 늘리자 에이전트가 예측 범위를 넘어선 시나리오와 예외를 제안했다는 경험담이 핵심이었다.
- 대화는 이렇게 움직였다.
- 오전 12:01 DV/Antigravity의 "그동안 만든 agent와 하네스로 어디까지 가능할지 어려운 과업과 병렬 작업 테스트를 하면서 토큰을 과하게 태워봤는데 정말 많은 생각이 드는 하루였어요.
- " / 오전 12:04 아웃라이너/클코덱스의 "그럼 에이전트와 하네스가 토큰을 엄청 태우더니 드디어 제대로 일을 한건가요?
- " / 오전 12:04 DV/Antigravity의 "Thinking budget을 좀 높게 주었고, self reviewer를 덕지덕지 추가해봤어요.
ceo, business analyst, cto, senior engineer, qa 등등. " / 오전 12:06 DV/Antigravity의 "아예 모르는 영역의 일을 시켰는데도 잘하더군요.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
CEO, business analyst, CTO, senior engineer, QA 같은 reviewer를 붙인 것은 역할놀이가 아니라 산출물을 여러 기준으로 동시에 압박하는 구조다. 특히 모르는 영역에서는 한 번의 답보다 서로 다른 실패 기준이 중요하다.
특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다. 맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다.
다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다. 첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다.
둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다. 셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다.
좋은 하네스는 토큰을 아끼는 장치가 아니라 필요한 곳에 토큰을 쓰게 만드는 장치에 가깝다.
연결 링크
2
계정·보안
계정 밴과 회사 GitHub 계정이 드러낸 보안 경계
왜 중요한가
회사 프로젝트에서 개인 계정, 공용 계정, 여러 기기 사용, 침투 테스트가 얽히며 생산성보다 계정 책임과 감사 추적이 먼저라는 논의가 커졌다.
깊이 보기
오전에는 회사 GitHub를 개인 계정으로 써도 되는지에 대한 질문이 나왔고, 오후에는 OpenAI 계정 밴 사례가 이어졌다.
- 회사 프로젝트에서 개인 계정, 공용 계정, 여러 기기 사용, 침투 테스트가 얽히며 생산성보다 계정 책임과 감사 추적이 먼저라는 논의가 커졌다.
- 대화는 이렇게 움직였다.
- 오전 9:31 웃는 라이언/클코의 "회사 프로젝트 github 하실 때 회사 계정으로 따로 쓰시나요?
- 아니면 개인계정으로 하나요?
- " / 오전 9:35 칼카리 / 클코의 "개인계정으로 하시면 사고 나면 그대로 추적도 못하고 옴팡 뒤집어쓰고 민사소송 받으셔야함.
" / 오후 3:33 통신보안/커서의 "저는 OpenAI 계정을 밴 당했네요 ㅠㅠ. 환불 안해주는듯 해요.
" / 오후 3:36 춘식/코파닐럿의 "예전 클코도 밴 많았었는데 한 계정으로 다중이용자 탐지가 되면 밴당하더라고요. " 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다.
그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다. 두 대화는 별개처럼 보이지만 같은 주제다.
AI 도구와 개발 계정이 개인 생산성 도구처럼 보여도 회사 자료, 코드, 결제, 접근 권한이 묶이면 즉시 조직 보안 문제가 된다. 특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다.
맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다. 다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다.
첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다. 둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다.
셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다. 업무에서 쓸 계정과 권한은 애초에 감사 가능한 형태로 설계해야 한다.
3
조직 기억
source of truth와 ADR이 레거시를 가르는 기준
왜 중요한가
AI가 코드를 잘 써도 비즈니스 의도와 결정 기록이 source of truth에 없으면 레거시가 빨리 커진다는 논의가 나왔다.
깊이 보기
새벽 중반의 대화는 레거시를 코드 품질 문제가 아니라 조직 기억 문제로 다시 정의했다.
- AI가 코드를 잘 써도 비즈니스 의도와 결정 기록이 source of truth에 없으면 레거시가 빨리 커진다는 논의가 나왔다.
- 대화는 이렇게 움직였다.
- 오전 12:37 아웃라이너/클코덱스의 "비즈니스 의도가 source of truth에 기술되어있지 않고 개개인의 저장소에 분산되어 있다 = 내 의도는 내 머릿속에만 있고 클로드에게 알려주지 않았음.
- " / 오전 12:43 DV/Antigravity의 "ADR만 잘 남겨도 이미 레거시 코드는 벗어난거죠!
- " / 오전 12:45 아웃라이너/클코덱스의 "ADR 진짜.
영상 보기 전엔 몰랐는데 잘 배웠습니다. " 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다.
그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다. AI가 코드를 많이 만들어서 레거시가 되는 것이 아니라, 사람이 말하지 않은 의도와 예외가 코드 밖에 남아 있어서 레거시가 된다.
ADR은 왜 이 결정을 했는지와 어떤 대안을 버렸는지 남기는 최소 기록이다. 특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다.
맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다. 다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다.
첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다. 둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다.
셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다. 코드 파일은 결과물이고, 비즈니스 의도와 예외처리의 역사는 별도의 source of truth로 복원해야 한다.
4
디자인 실무
AI 디자인 도구와 감각 학습의 한계
왜 중요한가
Claude Design, Stitch, Pencil, Figma 이야기가 오가며 AI가 화면을 만들어도 디테일과 감각은 아직 사람이 훈련해야 한다는 쪽으로 모였다.
깊이 보기
밤에는 디자인 이야기가 길게 이어졌다.
- Claude Design, Stitch, Pencil, Figma 이야기가 오가며 AI가 화면을 만들어도 디테일과 감각은 아직 사람이 훈련해야 한다는 쪽으로 모였다.
- 대화는 이렇게 움직였다.
- 오후 9:25 MIN/클코의 "디자인 기획을 지금 클로드디자인 원툴로만 쓰고있는데 좀더 파보고싶은 마음이 생기네요.
- " / 오후 9:33 이충규(스티브)의 "pencil MCP 쓰셔도 좋구요.
- 스티치, pencil, 피그마 순으로 퀄리티가 좋습니다.
" / 오후 9:32 에에의 "요즘 디자인 ai 툴들이 많이 나오긴 했지만 그래도 아직 피그마가 현업에선 대세라. " / 오후 9:52 마스트/클코의 "진짜 디자인 배워보고 싶으시면 빠른 방법이 하나 있긴해요.
" 순서로 이어지며, 처음에는 체감이나 질문으로 시작했지만 곧 운영 기준과 다음 행동의 문제로 바뀌었다. 그래서 이 항목은 짧은 키워드 요약보다 “누가 무엇을 물었고, 다른 사람이 어떤 기준으로 받아쳤는지”를 읽어야 한다.
AI 디자인 도구는 빠르게 화면을 제안하지만, 현업에서는 여전히 Figma가 대세이고 디테일을 잡으려면 전문 도구와 반복 작업이 필요하다는 말이 나왔다. 특히 이 흐름은 AI 도구를 잘 쓰는 일이 모델명 선택만으로 끝나지 않는다는 점을 보여준다.
맥락을 어디에 적어둘지, 어떤 권한을 열어둘지, 어떤 자료를 신뢰할지, 비용과 사람의 집중력을 어떻게 나눌지 같은 운영 질문이 같이 따라붙었다. 다음에 같은 주제를 다시 볼 때는 세 가지를 확인하면 좋다.
첫째, 오늘 나온 말이 단순 의견인지 실제 작업 사례인지 구분한다. 둘째, 링크나 도구 이름보다 그 도구를 왜 꺼냈는지 본다.
셋째, 내 작업에 옮길 때 필요한 선행 조건, 실패 기준, 보안 경계를 함께 적어둔다. AI에게 디자인을 맡길수록 사람은 더 적게 보는 것이 아니라 더 빨리 비교하고 더 정확히 피드백하는 능력을 배워야 한다.
짧은 기록
도구 링크 공유
awesome-claude-code-subagents, financial-services, headroom, apple-health-mcp-server 등 실험 링크가 다수 공유됐다.
토큰 농담과 피로
토큰 소진과 뇌토큰 농담이 이어졌지만 실제로는 비용과 집중력 관리 문제가 깔려 있었다.
제외한 잡담
짧은 축하, 이모티콘, 날씨·금요일 반응, 단발성 링크는 핵심 주제에서 줄였다.