현직 개발자가 바이브코딩 구조를 잡는 방법

한 줄 핵심

현직 개발자가 디스코드+Claude Code로 만든 개인용 에이전트 서비스 “심플로”를 더 확장 가능한 앱/클라이언트 구조로 재설계하면서, 바이브 코딩에서는 기능 구현보다 아키텍처·테스트·역할 분리가 훨씬 중요하다는 점을 실전 방식으로 보여준다.

시간별 요약

1. 4:56
   라이브 시작과 심플로 소개 디스코드에서 Claude Code를 조작하는 개인용 에이전트 서비스 “심플로”를 소개한다. 업무, 일정, 조회, 브라우저 자동화까지 한 곳에서 처리하는 실사용 도구라는 점이 핵심이다.
2. 7:00
   에이전트 OS로 쓰는 현재 구조 맥미니에 Claude Code를 붙이고 디스코드를 입력창처럼 써서 여러 작업을 처리하는 구조를 설명한다. 브라우저 자동화, 지식베이스, 멀티세션까지 결합해 사실상 개인용 AI 운영체제처럼 사용한다.
3. 12:01
   가볍게 만든 이유와 통제 철학 기존 도구보다 코드베이스를 작고 통제 가능하게 유지하려는 이유를 강조한다. 의도하지 않은 학습·행동을 줄이고, 토큰 사용과 복잡도를 낮추는 것이 설계의 우선순위다.
4. 14:01
   휴먼 인 더 루프와 원격 이어하기 본인 인증처럼 사람이 개입해야 하는 순간을 위해 원격 이어하기 기능을 둔다. 휴대폰으로 맥미니의 브라우저 화면을 열어 직접 인증하고, 이후 에이전트가 다시 이어서 판단하는 흐름이다.
5. 17:02
   새 앱과 클라이언트로의 확장 계획 디스코드 UI의 한계 때문에 대시보드형 UI와 네이티브 클라이언트를 새로 만들기로 한다. 먼저 현재 구조를 재정비해 디스코드 의존을 줄이고, 다른 클라이언트로 갈아끼울 수 있게 만드는 것이 목표다.
6. 21:01
   리팩터링 순서와 역할 경계 먼저 E2E 테스트로 현재 동작을 고정하고, 그 다음 어댑터 친화적인 구조로 리팩터링한 뒤 새 클라이언트를 붙이는 순서를 택한다. 개발자는 메인 개발자인 Claude Code가 주도하고, 사람은 PM처럼 의견만 주는 방식이 더 효율적이다.
7. 26:03
   확장 과잉 설계에 대한 경계 처음부터 모든 확장을 미리 고려하는 설계는 비효율적이라고 본다. 지금 필요한 구조를 먼저 만들고, 실제 확장 필요가 생기면 그때 구조를 바꾸는 편이 더 자연스럽다.
8. 37:07
   로컬 미니 PC와 에이전트 운용 에이전트는 클라우드보다 로컬 머신에서 돌리는 편이 훨씬 편하고 강력하다고 본다. 브라우저, 파이썬 스크립트, 여러 세션을 직접 쥐고 있는 로컬 환경이 장기적으로 더 유리하다는 관점이다.
9. 52:01
   개발 기본기와 공식 문서의 중요성 바이브 코딩을 하더라도 프레임워크와 언어의 기본 개념은 반드시 알아야 한다고 강조한다. 공식 문서를 영어 그대로 읽고 외우는 수준까지 가야 실무 검토와 문제 해결이 가능하다고 본다.
10. 59:02
    언어와 용어를 영어 그대로 익혀야 하는 이유 번역본으로 보면 개념의 어감과 정확성이 약해져서, 에러 로그나 전문 용어를 바로 연결하기 어렵다. 개발 도구와 문서는 영어 원문 그대로 익히는 것이 장기적으로 훨씬 실용적이다.
11. 1:13:01
    테스트용 가짜 객체와 느린 테스트의 문제 외부 서비스 연동은 실제 호출 대신 테스트용 더미 객체로 대체해 안정성을 확보한다. 테스트가 느리면 에이전트 작업 속도 전체가 떨어지므로, 테스트 최적화는 기능 구현만큼 중요하다.
12. 1:26:00
    메모리 도구보다 파일과 테스트 에이전트 메모리 도구는 품질과 이식성 측면에서 신뢰하기 어렵다고 본다. 필요한 정보는 파일과 테스트로 명시적으로 남겨야 다른 세션이나 다른 모델에서도 일관되게 활용할 수 있다.
13. 1:43:06
    평가 기준을 먼저 정하는 방식 구조를 평가할 때는 레이어링, 직관적인 폴더 구조, 객체 간 협력성, 테스트 용이성, 구식 파일 제거 같은 기준을 먼저 합의해야 한다. 기준이 있어야 코드 평가가 감이 아니라 판단이 된다.
14. 2:06:02
    세션 관리와 구조 정리의 현실 컨텍스트를 70% 이상 쓰기 전에 멈추고 상태를 저장하는 습관이 중요하다. 세션이 길어질수록 코드와 논의가 지저분해지므로, 작은 단위로 끊고 정리하는 편이 안정적이다.
15. 2:25:07
    폴더 구조와 네이밍 재설계 adapter, core, process 같은 계층을 다시 나누며 직관적인 아키텍처를 만들려 한다. 바이브 코딩이라도 네이밍과 책임 분리를 잘못 잡으면 나중에 유지보수가 급격히 어려워진다.
16. 3:07:12
    브라운필드 리팩터링과 마무리 기존 E2E를 유지한 채 내부 구조를 바꾸는 브라운필드 방식이 더 현실적이라고 정리한다. 완전히 새로 짜는 그린필드보다, 동작 보장을 유지하면서 점진적으로 정리하는 쪽이 안전하다고 결론낸다.

실무 인사이트

• 바이브 코딩에서 가장 중요한 것은 코드를 많이 쓰는 것이 아니라, 테스트로 현재 동작을 고정하고 구조 변경의 범위를 통제하는 일이다.
• 에이전트 기반 개발은 결국 아키텍처 문제이므로, 클라이언트·어댑터·코어의 경계를 먼저 정해야 다른 UI나 모델로 갈아타기 쉬워진다.
• 실무 수준의 AI 활용은 개념을 대체하지 못한다. 프레임워크 공식 문서와 기본 용어를 영어 원문 기준으로 익혀야 에러 로그와 설계 논의를 제대로 따라갈 수 있다.