현업 개발자의 바이브코딩 소통 & 라이브

한 줄 핵심

기존에 디스코드로 쓰던 자체 에이전트 Simple Clo를 데스크톱 앱으로 재구성하면서, 실제로 쓰는 제품을 QA·브랜딩·아키텍처·세컨브레인까지 함께 고도화하는 실전 바이브코딩 과정을 보여주는 영상이다.

시간별 요약

1. 0:00
   시작 지금 만들고 있는 에이전트 제품 Simple Clo를 실제 작업에 쓰면서 데스크톱 앱으로 옮길 준비를 한다. 아직 상용 수준은 아니어서 클로드 코드를 병행하지만, 내부적으로 쓰는 도구를 직접 제품화하는 방향이 분명하다.
2. 6:50
   오늘 작업 — 쓰던 에이전트 Simple Clo를 데스크톱 앱으로 X4로 만든 웹 앱을 Electron 데스크톱 앱으로 감싸고, 사람처럼 스크린샷을 보며 UI/UX 문제를 찾도록 테스트한다. 브랜딩, 실시간 작업 표시, 통화 기능처럼 디스코드만으로는 해결되지 않는 요구를 앱 레이어로 옮기는 흐름이다.
3. 13:04
   내 판단을 담은 세컨드 브레인, 마피아 브레인 MCP 과거 라이브와 평소 프롬프트, 개발 원칙을 온톨로지로 정리한 마피아 브레인 MCP를 만들어 상황별로 조회한다. 전부를 한 번에 주는 방식보다 필요한 판단만 꺼내 쓰는 구조가 실전에서 더 유용하다.
4. 32:55
   리브랜딩 — 새 이름 deus와 로고 기존 제품명을 이어받아 deus로 리브랜딩하고, 예전 프로젝트를 다시 살려 제품화하는 방향을 잡는다. 업무용 에이전트로서 여러 사람이 함께 쓰기 좋게 컨텍스트 관리와 자동화 장치를 강화하는 데 초점이 맞춰진다.
5. 50:47
   랜딩 페이지 만들기 (Vercel 배포·도메인까지 위임 랜딩 페이지는 Vercel에 배포하고 도메인 연결은 브라우저 자동화로 처리하는 흐름을 잡는다. 이 과정에서 실제 UI를 보며 시안 후보를 여러 개 만들고, 가장 나은 안을 골라 바로 적용한다.
6. 56:31
   QA는 사람처럼 화면을 보고 테스트하게 에이전트에게 단순 명령 대신 사람이 쓰듯 화면을 시각적으로 읽게 하면, 버튼 배치나 정보 과밀 같은 문제를 더 잘 잡아낸다. 실제로 여러 시안을 병렬로 만든 뒤 가장 나은 것을 고르는 방식이 효율적이다.
7. 1:11:05
   하네스는 로그를 심어 실측으로 개선한다 하네스 설계는 일반론보다 로그를 심어 실측 데이터로 개선해야 한다는 원칙을 강조한다. 어떤 구조가 최적인지는 프로젝트마다 다르므로, 사용 데이터를 쌓아 평가하고 반복 개선하는 방식이 맞다.
8. 1:20:33
   리버스 엔지니어링이 쉬워지면 — 로직은 서버로 오픈 소스 리버스 엔지니어링이 쉬워질수록 클라이언트에 중요한 로직을 두는 것이 부담스러워진다. 실시간성이 필요한 영역을 제외하면 검증과 핵심 책임은 서버로 보내는 쪽이 더 안전하다.
9. 1:30:16
   서브에이전트를 잘 안 쓰는 이유 대화 맥락이 끊기는 것을 싫어해 가능한 한 서브에이전트 사용을 줄이고, 대신 직접 논의하면서 작업을 이어간다. 다만 길어진 세션은 자동 압축을 활용해 유지한다.
10. 1:51:00
    클로드 데스크톱의 하위 세션 클로드 데스크톱의 하위 세션은 사용자가 중간에 개입할 수 있어 포크된 작업을 다시 제어하기 좋다. 토큰 맥싱보다도 AI가 잘 맞는 새로운 업무를 찾아야 한다는 고민도 함께 나온다.
11. 2:03:21
    지난 라이브 노트를 그대로 프롬프트로 넣기 예전 라이브 노트를 그대로 붙여 넣어 문서 점검과 코드베이스 검토를 시킨다. 세션 로그와 로컬 기록을 쌓아 나중에 효과를 분석할 수 있게 해두는 점이 중요하다.
12. 2:21:20
    데스크톱 앱 바이너리를 뜯어 디자인 분석하기 설치된 앱 바이너리를 분석해 디스코드나 다른 데스크톱 앱의 디자인과 기술 스택을 참고한다. 마이크로 인터랙션, 색상, 상태 관리 같은 요소를 직접 추출해 자기 서비스에 반영하는 방식이다.
13. 2:25:41
    세컨드 브레인에는 무엇을 넣나 세컨드 브레인에는 개인이 라이브에서 말한 설계 원칙과 프롬프트, 개발 철학을 넣는다. 프로젝트 문서보다 개인 판단 기준을 모아두는 용도로 특히 잘 맞는다.
14. 2:40:22
    바이브코딩 공부는 인프라부터 바이브코딩을 잘 하려면 가장 큰 단위인 인프라 개념부터 공부하는 것이 좋다. CDN, 캐싱, 포트 같은 기초를 알아야 그 위의 아키텍처와 에이전트 설계를 제대로 이해할 수 있다.
15. 2:50:55
    오래 걸리던 검증 게이트 잡기 세션이 필요 이상으로 길어지는 원인을 찾아 검증 게이트를 정리한다. 오래 걸리더라도 실제 실행과 테스트를 모두 거치게 하되, 병목은 로그로 확인해 조정한다.
16. 2:52:05
    AI에게 명령 대신 질문으로 지시하는 이유 명령형보다 질문형 프롬프트를 쓰면 AI가 더 주도적으로 판단할 여지가 생긴다. 사용자는 참고 의견만 주고 최종 결정을 AI가 하도록 두는 편이, 능력을 더 잘 끌어내는 방식이다.
17. 3:00:09
    디스코드의 마이크로 인터랙션을 코드로 뜯어 적용 디스코드 앱을 리버스 엔지니어링해 마이크로 인터랙션과 UI 패턴을 코드 수준으로 분석한다. 시각만으로는 놓치기 쉬운 타이밍과 전환을 정확히 가져와 자기 서비스에 적용한다.
18. 3:10:05
    코드는 안 읽어도 된다, 아키텍처는 공부한다 개발에서 중요한 것은 개별 코드 읽기가 아니라 아키텍처와 구조를 이해하는 일이다. 폴더 배치와 책임 분리 같은 설계 감각이 있으면, 세부 구현은 AI에 맡겨도 된다.
19. 3:20:51
    하네스 엔지니어링, 지금 공부해야 할까 에이전트를 직접 만들 계획이 아니라면 하네스 엔지니어링보다 기획과 아키텍처, UI/UX를 먼저 익히는 편이 낫다. 서비스 완성도는 하네스보다 문제 정의와 구조 설계에서 더 크게 갈린다.
20. 3:52:58
    마피아 브레인으로 설계 기본기 공부하기 마피아 브레인 MCP를 공부 도구로도 써서 설계 기본기를 단계적으로 배우는 방식이 가능하다. 기능 목록보다 성공 기준, 역할 분리, 화면 역도출 같은 질문으로 설계를 풀어가는 게 핵심이다.
21. 4:13:55
    ADR은 프로젝트에 둘까, 세컨드 브레인에 둘까 개인적인 개발 철학과 프로젝트 종속 맥락을 분리해 관리하는 편이 더 좋아 보인다. ADR 같은 문서도 프로젝트 내부보다 세컨드 브레인 쪽으로 옮기는 방향을 검토한다.
22. 4:20:37
    클로드 코드 필수 세팅 — 브라우저 자동화 클로드 코드 활용에서 브라우저 자동화는 사실상 필수에 가깝다. 브라우저 유즈나 비슷한 도구를 연결하면 UI 테스트와 실제 웹 작업의 편의성이 크게 올라간다.
23. 4:42:01
    디스코드 앱은 어떤 기술로 만들어졌나 디스코드는 Electron 껍데기 위에 React와 일부 네이티브 모듈을 섞어 만든 구조로 확인된다. 자신이 만들 서비스도 이런 식으로 기술 스택을 참고하면 시행착오를 줄일 수 있다.
24. 5:01:19
    심플클로를 디스코드로 쓰는 모습 디스코드에서 메시지를 보내면 집에 있는 클로드 코드가 작업을 수행하고 답을 다시 돌려주는 방식으로 운용한다. 원격으로 계속 켜 두고 쓰는 구조라, 노트북을 옮겨 다니며 작업하는 방식보다 훨씬 안정적이다.
25. 5:12:06
    Playwright MCP 대신 쓰는 것 / 세션 병렬 실행의 단점 브라우저 자동화는 Playwright MCP보다 브라우저 유즈나 비슷한 도구가 더 낫다고 본다. 병렬 세션은 편하지만 상태 충돌과 커밋 꼬임이 생길 수 있어, 필요한 만큼만 병렬화하는 게 좋다.
26. 5:36:15
    작업이 오래 걸리는 진짜 이유는 기획 오래 걸리는 이유는 코딩 자체보다 기획을 구체화하고 수정하는 과정에 있는 경우가 많다. 스펙이 불명확하면 구현보다 방향 정리에 더 시간이 든다.
27. 5:41:00
    시안보다 바로 구현해서 보기 별도 시안을 만드는 비용이 크므로, 가능하면 바로 구현해서 결과 화면을 보는 편이 낫다. 피그마 MCP보다 HTML로 즉시 보면서 조정하는 방식이 더 실용적이다.
28. 5:58:01
    E2E 테스트는 초기에 만들지 않는다 아직 프로덕션 릴리즈 전이라면 무거운 E2E 테스트를 초기에 깔기보다, 실제 동작을 먼저 만드는 것이 낫다. 브레이크를 많이 달기보다 핵심 기능이 먼저 돌아가게 하는 쪽이 효율적이다.
29. 6:01:09
    직접 쓸 도구는 일단 써보면서 만든다 내가 직접 쓸 도구는 추상적으로 만들지 말고, 최소한 실사용 가능한 수준까지 빨리 만들어서 써봐야 한다. 써보면서 가장 미치는 불편함이 드러나고, 그 지점을 기준으로 개선해야 한다.
30. 6:14:08
    모델·effort 고르는 기준 현재는 Claude Opus 5.5를 중심으로 쓰고, effort는 개입을 많이 하고 싶으면 Medium, 더 많은 창작을 원하면 High 이상을 고르는 식이 적절하다. 기본은 빠른 응답과 적당한 추론을 우선하는 설정이다.
31. 6:16:23
    마무리 오늘은 에이전트 제품을 실제로 고도화하면서 문서, 디자인, 검증, 브랜딩까지 한 번에 손보는 라이브였다. 앞으로도 인프라 강의와 함께 제품을 공개할 계획이다.

실무 인사이트

• 실무용 에이전트는 기능 추가보다 먼저 실제 사용 로그를 쌓아 병목과 실패 패턴을 측정해야 개선 속도가 빨라진다.
• AI에게는 명령형보다 질문형으로 여지를 남기고, 대신 로그·검증·권한 경계를 분명히 두는 편이 장기적으로 더 안정적이다.
• 바이브코딩으로 도구를 만들 때는 시안·E2E보다 실제 사용과 즉시 피드백을 우선해야 진짜 불편한 지점이 빠르게 드러난다.