신규하 블로그

바이브코딩(Vibe Coding) 관련 콘텐츠는 많지만, 실제로 돈을 받고 무엇을 만들었는지까지 공개하는 사례는 생각보다 드뭅니다. 이번 영상이 흥미로운 이유는 “두달만에 3500” 이라는 강한 문구 자체보다, 최소한 공개 페이지와 댓글만 봐도 외주 실험의 방향, 숨고 같은 유입 채널, 그리고 실제로 언급된 프로젝트 종류가 제법 구체적으로 드러난다는 점에 있습니다.12 더보기

이 영상이 흥미로운 이유는 “2주 만에 앱으로 2,800만원” 이라는 숫자보다, 비개발자형 바이브코딩을 어떤 프로세스로 해석하고 있는지 를 꽤 선명하게 보여주기 때문입니다. 공개된 설명과 공유 요약을 기준으로 보면, 코딩 자체보다 앞단의 시장 조사, 온보딩 해석, AI에게 넣는 입력 구조, 그리고 너무 늦지 않게 출시하는 판단이 더 중요하다는 방향이 두드러집니다.12 더보기

AGENTS.md 이야기가 흥미로운 이유는 이 파일이 단순히 새 문서 이름을 제안하는 것이 아니라, 에이전트가 프로젝트를 읽는 방식 자체를 표준화하려는 시도 이기 때문입니다. agents.md는 이 포맷을 “README for agents” 라고 설명하는데, 이 표현 하나에 거의 모든 핵심이 들어 있습니다. 사람용 README와 에이전트용 실행 문맥을 분리해 두면, 프로젝트 설명은 깔끔하게 유지하면서도 코딩 에이전트에는 더 구체적인 실행 지침을 안정적으로 줄 수 있습니다. 이 사이트가 설득력 있는 이유는 기능을 과장하기보다, 실제로 어떤 정보가 에이전트에게 필요한지 아주 실무적으로 설명한다는 점입니다. 예를 들어 설정 명령, 테스트 명령, 코드 스타일, PR 규칙, 모노레포 하위 지침, 충돌 우선순위 같은 항목은 사람이 프로젝트 소개 문서에서 늘 보고 싶어 하는 내용은 아니지만, 에이전트가 작업을 끝까지 수행하는 데는 매우 중요합니다. 결국 AGENTS.md는 “문서를 더 하나 만든다” 가 아니라, 사람과 에이전트의 독자층을 분리해 문맥 비용을 줄이는 운영 패턴 에 가깝습니다. agents.md 더보기

Claude Code를 오래 쓰다 보면 가장 먼저 부딪히는 한계는 모델 성능보다 세션 단절 입니다. 방금 전까지 무엇을 조사했고 어떤 결정을 내렸는지 다음 세션에서 다시 설명해야 하는 순간이 반복되기 때문입니다. thedotmack/claude-mem은 바로 그 문제를 겨냥한 플러그인입니다. 저장소의 표현을 그대로 옮기면, 이 프로젝트는 Claude Code용 “persistent memory compression system” 이고, 세션 동안 발생한 관찰을 자동 수집하고 요약한 뒤 다음 세션에 다시 주입하는 구조를 제공합니다. (README.md) 더보기

Shotgun은 요즘 흔한 “AI가 코드를 대신 써 준다” 류의 도구와 출발점이 조금 다릅니다. 이 프로젝트가 전면에 내세우는 핵심은 코드 생성 자체가 아니라, AI 코딩 에이전트가 큰 기능에서 왜 자꾸 탈선하는지 먼저 인정하고 그 앞단의 리서치, 명세, 계획을 구조화하는 것 입니다. README의 한 문장으로 요약하면 Shotgun은 “codebase-aware specs” 를 만들어 Codex, Cursor, Claude Code 같은 에이전트가 엉뚱한 방향으로 새지 않게 돕는 CLI입니다. GitHub Repository README 더보기

Claude Code를 사용하다 보면 스킬(Skill)이 기대만큼 동작하지 않아 답답할 때가 있습니다. 흔히 “70/30"의 법칙이라고 부르는, 70%는 잘하지만 나머지 30%에서 삐끗하는 불확실성 때문입니다. 이때 많은 개발자가 직접 프롬프트를 수정하며 시행착오를 겪지만, 이는 오히려 다른 케이스에서 성능을 떨어뜨리는 부작용을 낳기도 합니다. 이번 글에서는 안드레이 카파시(Andrej Karpathy)의 Autoresearch 개념을 빌려와, Claude Code 스킬을 데이터와 지표 기반으로 자동 개선하는 영리한 접근법을 정리해 보겠습니다.12 더보기

이 영상이 흥미로운 이유는 “Claude Code로 콘텐츠를 빨리 쓴다” 는 수준에서 멈추지 않고, 리서치 -> 리드 마그넷 -> 포스트 작성 을 하나의 운영 파이프라인으로 묶어 설명하기 때문입니다. 발표자는 이 흐름으로 LinkedIn 팔로워가 1,500명에서 10,000명 이상으로 늘었고 비즈니스 리드도 크게 증가했다고 말하지만, 이런 성장 수치와 리드 수는 어디까지나 발표자 개인이 영상에서 제시한 사례이므로 일반화된 성과 공식으로 보기보다 재현 가능한 작업 구조 에 주목해 읽는 편이 안전합니다 (근거: t=13, t=19, t=47, t=53). 더보기