400~500명 규모의 기수제 AI 스터디 커뮤니티를 단 2명이 운영한다면? 지피터스(GPTers)의 송다혜님은 Claude Code(오픈클로)로 만든 뽀짝이 에이전트를 통해 그 불가능에 가까운 운영을 실제로 해내고 있습니다. 이 글은 빌더 조쉬 채널의 인터뷰를 바탕으로, 뽀짝이가 어떻게 만들어졌고 어떻게 동작하며, 그 경험에서 AI 네이티브 조직을 만들려는 분들이 무엇을 배울 수 있는지를 정리합니다. 더보기

AI로 이미지나 영상을 생성할 때 가장 큰 난관 중 하나는 캐릭터 일관성 입니다. 같은 캐릭터를 여러 장면에서 반복 생성하면 얼굴, 체형, 의상 등이 매번 미묘하게 달라지는 문제가 생기죠. 이 문제를 해결하는 핵심 도구가 바로 캐릭터 시트 입니다. 이 글에서는 마스터 프롬프트를 활용해 정밀한 캐릭터 시트를 만드는 전체 워크플로우를 정리합니다. 더보기

LLM의 컨텍스트 윈도우는 계속 커지고 있습니다. 그런데 실무에서는 이상한 장면이 자주 나옵니다. 자료를 더 많이 넣었는데 답이 더 좋아지기는커녕, 엉뚱한 파일을 집거나 이미 결정한 사항을 다시 뒤집는 경우입니다. 이 현상을 최근 실무권에서는 컨텍스트 로트(context rot) 라는 말로 자주 부릅니다. 중요한 점은 이 표현이 엄밀한 학술 용어라기보다, 긴 문맥이 쌓일수록 모델의 주의력과 일관성이 서서히 망가지는 현상을 묶어 부르는 실무 용어라는 점입니다. 더보기

겉으로만 보면 bkit 과 GSD(Get Shit Done) 는 비슷해 보입니다. 둘 다 AI 코딩을 더 체계적으로 만들겠다고 말하고, 계획과 실행 사이를 문서와 에이전트로 연결하며, 컨텍스트 엔지니어링이라는 표현도 사용합니다. 하지만 공식 문서를 조금만 깊게 읽어 보면, 두 도구가 실제로 통제하려는 대상은 꽤 다릅니다. bkit 은 Claude Code 안에서 엔지니어링 절차와 검증 규율 을 강하게 밀어 넣는 쪽이고, GSD 는 여러 런타임에서 context rot를 줄이면서 실전 구현을 계속 굴리는 운영 흐름 에 더 가깝습니다. 그래서 중요한 질문은 “어느 쪽이 더 강한가"가 아닙니다. 더 정확한 질문은 AI 코딩에서 내가 지금 가장 줄이고 싶은 실패가 무엇인가 입니다. 요구사항 없이 바로 구현으로 점프하는 문제가 더 큰지, 긴 세션에서 품질이 무너지는 문제가 더 큰지, 혹은 Claude Code 하나에 깊게 최적화할지 여러 런타임을 오갈지가 더 중요한지에 따라 답은 달라집니다. 더보기

Claude Code를 쓰다 보면 금방 느끼는 문제가 있습니다. 코드는 빨리 나오는데, 계획과 설계와 검증이 한 흐름으로 묶이지 않으면 결과가 들쭉날쭉해진다는 점입니다. bkit 은 바로 그 지점을 겨냥한 플러그인입니다. 저장소의 현재 설명대로 보면, 이 도구는 Claude Code 위에 PDCA 방법론, CTO-Led Agent Teams, 자동 문서화, Context Engineering 을 얹어 AI 코딩을 조금 더 “운영 가능한 개발 프로세스"에 가깝게 바꾸려는 시도입니다. 현재 공개 저장소 기준으로 bkit 은 v2.0.6, Apache-2.0 라이선스, 37 Skills, 32 Agents, 18 Hook Events, 57 scripts, 88 lib modules, ~620+ functions를 내세우고 있습니다. 숫자만 많아 보이는 도구처럼 보일 수도 있지만, 핵심은 숫자보다 구조입니다. 이 글에서는 그 구조가 실제로 무엇을 바꾸는지 중심으로 보겠습니다. 더보기

Marmelab의 “Agent Experience” 글이 흥미로운 이유는, 코딩 에이전트의 성능 차이를 모델 자체보다 코드베이스가 얼마나 에이전트 친화적으로 설계되어 있는가 로 설명하기 때문입니다. 글은 “좋은 프롬프트를 어떻게 쓸까” 보다 한 단계 더 들어가서, 에이전트가 검색하고, 이해하고, 실행하고, 검증하는 전 과정을 코드베이스 차원에서 어떻게 돕느냐를 묻습니다. 즉 이 글은 에이전트를 잘 쓰는 법을 말하는 사용법 가이드라기보다, 에이전트가 잘 일할 수 있는 저장소를 만드는 운영 원칙 모음 에 가깝습니다. 다만 이때의 Agent Experience는 아직 널리 합의된 표준 용어라기보다, Developer Experience의 문제의식을 에이전트 실행 환경으로 확장한 실무적 framing으로 보는 편이 더 정확합니다. 특히 대형 프로젝트에서 사람이 반복해서 채팅으로 설명하던 규칙과 문맥을 파일, 테스트, 도구, 훅, 문서로 옮겨 두면 에이전트의 자율성과 정확도가 함께 올라간다는 점을 아주 실무적으로 보여 줍니다. 더보기