현업 개발자 바이브코딩 Q&A

정해 둔 주제 없이 채팅 질문을 중심으로 답한 소통 라이브예요. 기획을 어디까지 구체화할지, 코드 퀄리티가 아직 중요한지 같은 개발 질문이 앞부분을 채웠고, 뒤로 갈수록 토스 입사·퇴사, 공부법, 1인 개발자용 책 티어표로 이어졌어요.

2026-11-12 라이브 · 2시간 11분 · 다시보기

이 노트를 읽고 나면 할 수 있는 것

1. 요구사항과 유스케이스를 구분하고, 유스케이스는 AI에게 맡기지 않고 직접 쓰기
2. 폴더 구조를 "흔한 이름 + 같은 층의 같은 추상화 수준"으로 점검하기
3. 1인 개발 전에 읽을 책을 S~C 순서로 고르기

목차

• 유스케이스까지는 직접 써요 ▶ 0:10:26
• 미래 기능, 폴더 구조, 고수의 레포 ▶ 0:25:20
• 코드 퀄리티와 하네스, 예전만큼 중요할까요 ▶ 0:26:53
• 학점 2점대에서 토스까지 ▶ 0:47:37
• 토스에서 PM을 하다 나온 이유 ▶ 0:58:38
• 해자가 있어야 기술 창업이에요 ▶ 0:32:35
• 넘어가고, 여러 번 읽어요 ▶ 1:11:18
• 1인 개발 추천 책 티어표 ▶ 1:43:43
• AX와 보안 질문 ▶ 1:13:10
• 오늘 해볼 것 ▶ 2:09:28

유스케이스까지는 직접 써요 ▶ 0:10:26

라이브 초반에는 소프트웨어 설계 책을 함께 읽고 나눈 대화를 녹음해 정리한 문서를 띄웠어요. 첫 주제가 유스케이스였어요.

유스케이스는 명세 기법이에요. 시스템이 어떻게 작동할지, 단계별로 해야 할 작업을 명확히 적는 스펙이죠 ▶ 0:11:05.

요구사항과는 수준이 달라요. 요구사항은 "이루어져야 하는 조건"이고, 문서화를 철저히 하는 회사가 아니면 기획은 보통 이 수준으로 넘어와요 ▶ 0:12:41. 결국 유스케이스 수준의 구체화는 개발자 몫이 돼요. 유스케이스는 코드로 거의 그대로 옮길 수 있을 만큼 구체적이에요.

그 체계를 알고 있다는 것만으로도 엣지 케이스를 미리 고려하는 눈을 갖추기 좋아요. ▶ 0:13:43 매번 손으로 문서를 쓰지 않더라도요.

함께 읽은 책은 유스케이스를 어떻게 쓰는지까지는 설명하지 않았어요. 작성법은 유스케이스의 거장인 앨리스터 코오번의 『유스케이스』를 추천했어요 ▶ 0:14:20. 내용은 조금 어려워요.

유스케이스를 AI에게 맡겨도 될까요

대화 속에서 이런 질문도 나왔어요. 바이브코딩을 하는 사람이 유스케이스까지 기획하려면 어떻게 해야 하냐고요. 저는 유스케이스 작성은 AI에게 맡기지 않는 편을 권해요 ▶ 0:15:43.

엄청 긴 분량을 써야 하는 문서가 아니고, 거의 다 내 아이디에이션과 의사결정이에요. 그걸 맡겨버리면 내가 흐름조차 추적하지 못하는 프로덕트가 되는 거죠. ▶ 0:16:03

이 대화는 애니메이션 롱폼으로 만들고 있어요. 라이브에서 틀어 본 시안 속 제 대사가 이래요. 쓴 유스케이스를 계속 들여다볼 문서로 두지는 않고, 생각을 정리하는 중간 단계로 쓰다가 E2E 테스트까지 완성하면 지워요 ▶ 0:19:06. E2E 테스트만 남아 있으면 유스케이스는 언제든 다시 쓸 수 있고, 같은 정보를 문서로 두 벌 두면 낡은 문서가 생기거든요 ▶ 0:19:46.