← 뉴스레터

2026-04-21

바이브코딩 뉴스레터 Ep.2 — 기억이를 드롭했다

2026-04-20 자정, 나는 3시간 만에 만든 봇에 “오늘 뭐 했어?” 하고 물었다. 한국어로 요약이 돌아왔고, 나는 흐뭇했다. 2026-04-21 아침, 나는 그 봇을 드롭했다.

Ep.1 에서 나는 Phase 3 예고를 남기고 떠났다. 맥의 ~/docs 를 WSL 로 rsync 해서 인덱싱 범위를 넓히고, 증분 ingest 를 붙이고, git 히스토리까지 먹이겠다고 했다. 독자에게 한 약속이었다.

그 Phase 3 는 이제 안 일어난다. 이번 에피소드는 약속을 깨는 이야기 다. 왜 깼는지, 그게 왜 바이브코딩에서 드물지 않은지, 그리고 “만든 걸 죽이는” 기술에 대해서.

1. 드롭한 이유는 하나였다

“품질이 마음에 들지 않았다.”

엔지니어링 문제도 아니고, 돈 문제도 아니고, 시간이 부족해서도 아니었다. 기억이가 내놓는 답의 품질이 나에게 쓸 만한 수준이 아니었다. 그게 전부다.

3시간 만에 돌아간 건 맞다. Ep.1 에서 자랑한 것도 맞다. “폰에서 물어보면 한국어로 답이 온다” 는 사실이다. 그런데 그 답이 좋은가 는 그 다음 질문이고, 나는 다음날 아침에 그 질문을 하루 종일 해 보다가 결국 “아니” 라고 결정했다.

2. 어떤 품질 문제였나

Ep.1 마지막에 슬쩍 숨겨둔 문장이 있다:

(섞여 있는 중국어는 다음날 새벽에 해결했지만 그건 Ep.2 이야기)

Phase 2.1 로 qwen2.5:7b 의 중국어 누수는 프롬프트 튜닝으로 눌렀다. 하지만 그건 빙산의 한 꼭지였다. 하루를 써 보니 나온 것은:

① 같은 질문에 다른 답 “지난 주 더치페이에 뭐 했지?” 를 아침에 물으면 A 답이, 저녁에 물으면 B 답이 나왔다. 두 답 다 내 기록에 있는 사실이지만, 매번 다른 3~5개 청크를 집어서 그 중 일부만 종합했다. 사실은 맞는데 결론은 달랐다. 이걸 일관된 참고자료로 쓰기는 어렵다.

② 요약이 흐릿하다 “심사레이더 Phase 2 가 뭐였는지 자세히” 같은 구체 질문에 “Phase 2 는 Telegram 봇 구현 관련 작업이었습니다” 수준으로 돌아왔다. worklog 원문에는 “[Service] 헤더 누락으로 systemd 가 ExecStart assert 거부, 30분 삽질” 이라는 구체 정보가 있는데, 모델이 뭉개 버린다. 7B 모델의 한계다.

③ 최근 3일 가중치가 없다 “오늘 뭐 했어?” 에도 2주 전 기록이 섞여 들어왔다. 임베딩 기반 retrieval 은 의미 유사도로 뽑지 시간 신선도는 모르기 때문에, “오늘” 이라는 단어가 2주 전 메모에 많이 들어가 있으면 그쪽을 집는다. 매번 newer_than:7d 비슷한 필터를 직접 넣어야 했다.

④ 반문/확인이 없다 모호한 질문에 그냥 답한다. “약먹자 상태가 어때?” 에 “약먹자 프로젝트는 진행 중입니다” 로 답했는데, 내 실제 기록에는 “약먹자 드롭 → 부활 → 스토어 등록” 같은 굴곡이 있다. 봇은 “어떤 시점 기준으로?” 를 안 물어본다.

이 네 개를 Phase 3 가 해결했을까? ①②④ 는 모델 교체 없이는 안 된다. ③ 만 retrieval 필터로 부분 해결 가능. 즉 Phase 3 의 세 가지 (맥 docs 추가 / 증분 ingest / git 히스토리) 는 데이터를 늘리는 것이었지 답을 나아지게 하는 것이 아니었다.

데이터가 늘면 retrieval 후보가 늘어서 ①번 일관성 문제가 더 심해질 수 있다. Phase 3 는 상황을 악화시킬 수도 있는 방향이었다.

3. 고치려면 뭐가 필요했나

품질을 쓸 만하게 끌어올리려면 이 중 하나가 있어야 했다:

  • LLM 교체: qwen2.5:7b → 32B 이상. 내 2070S 8GB 에서는 안 뜬다. 양자화로 14B 까지는 끌어올 수 있지만 초당 3~5토큰으로 떨어짐. 대화용으로는 느려서 쓰기 싫어짐.
  • 외부 API 로 전환: OpenAI 또는 Claude API. 그러면 “로컬, 무료, 내 노트북” 이라는 Ep.1 의 자랑 포인트가 사라진다. 가격도 붙는다.
  • retrieval 재설계: 시간 가중 + 청크 크기 조정 + 멀티 쿼리. 1~2주 작업. 한다고 ①② 문제가 해결된다는 보장이 없음 (모델이 7B 이기 때문에).

세 옵션 다 “3시간에 만든 걸 서른 시간 더 써서 쓸 만하게 만드는” 방향이었다. 그 서른 시간 투입 대비 얻는 게 뭐냐를 봤다.

얻는 것 — 내 작업 기억에 자연어로 물어보는 기능.

그게 다른 방식으로 이미 해결돼 있는가 를 그제서야 차분히 봤다. 그랬더니 있었다.

4. 대안은 이미 내 손에 있었다

심사레이더 Gmail OAuth 연동을 하면서 Claude Code 에 자연스럽게 물어봤다 — “심사레이더 어제 어디까지 했지?” 회신은 즉각적이고 구체적이었다:

“2026-04-20 야간에 C:\src\review_radar 에 MVP 스캐폴드 완성, Mock 데이터로 S24 설치·실행 확인, Gmail OAuth 만 아침 슬롯으로 뺀 상태입니다.”

이건 기억이가 잘 못 하던 ②번 (요약이 흐릿하다) 이 해결된 답이다. Claude Code 의 auto memory 는 내 작업 기록을 매 세션 자동으로 넣어 두고, 큰 모델 기반으로 답하고, 현재 대화 맥락까지 섞어서 반환한다. 내가 봇에 요구한 “정확하고 구체적인 요약” 이 그쪽에서는 자연스럽게 나온다.

폰에서 쓰기? @Myclaude2_ssamssae_bot 텔레그램 플러그인으로 폰에서도 Claude Code 와 대화한다. 기억이의 유일한 독점 포인트였던 “폰 접근성” 도 가져갔다.

기억이를 드롭한 건 “대안이 있어서” 가 아니다. 순서가 중요하다 — 품질이 안 나와서 드롭했고, 그 뒤에 다행히 대안이 있었다. 대안이 없었어도 드롭했을 것이다. 품질을 타협해서 쓰느니 없이 사는 쪽이 낫다.

5. 품질 기준은 타협하지 않기로 한다

이번에 배운 건 기술적인 것 말고 태도 에 가깝다.

바이브코딩은 “빨리 만들어서 빨리 쓴다” 가 원칙이다. 하지만 “만들었으니 쓰자” 와 “만족하지 않아도 쓰자” 는 다르다. 둘을 섞으면 내가 만든 쓰레기에 점점 둘러싸이게 된다. 이건 1인 개발자한테 특히 위험한 구도다. 팀이라면 “이거 좀 이상한데” 하는 사람이 있지만, 혼자면 내 감이 전부다.

그래서 이번에 스스로 룰을 정했다:

만든 것의 품질이 마음에 안 들면, 그 도구는 버린다. 붙잡고 개선하지 않는다.

개선은 좋은 작업이지만, “이미 만든 것을 지키려고 하는 개선” 과 “다음 버전을 더 잘 만들고 싶어서 하는 개선” 은 다르다. 전자는 sunk cost fallacy 고, 후자는 이터레이션이다. 전자라고 느껴지는 순간 드롭한다.

3시간 투자는 sunk 다. 회수할 수 없다. 회수하려고 30시간 더 쓰면 33시간을 sunk 로 만드는 거다. 그게 “개선” 의 실체다.

6. 만들면서 얻은 건 남긴다

드롭은 도구 제거지 기록 제거가 아니다. 3시간에 얻은 것들은 그대로 남겼다:

  • ChromaDB 청킹 전략: 문단 + 500자 재분할 규칙. 다음 RAG 성 작업에서 재사용.
  • systemd 유저 서비스 함정: [Service] 헤더 누락이 “Assertion failed on ExecStart” 로 표시되는 것. 기록해 둬야 다음에 30분 덜 낭비한다.
  • 텔레그램 봇 getUpdates 충돌: 같은 토큰으로 두 인스턴스가 폴링하면 둘 다 죽는 것. 봇 디버깅 때 항상 확인할 포인트.
  • 로컬 LLM 의 7B 체감 한계: 한국어 요약 품질이 쓸 만한 수준에 아직 모자라다. 다음에 로컬 LLM 고민할 때 이 선을 기억한다.
  • Ep.1 원고 — 그대로 살아있다. 그 3시간은 기록으로 남았다.

제거된 것:

  • ChromaDB 컬렉션 (~/기억이/chroma.db) — 삭제
  • systemd 유저 서비스 — 삭제
  • WSL 메모리 ~1GB 상시 점유 — 해제
  • @gieogu_ssamssae_bot 은 BotFather 에서 삭제 안 함 — 텔레그램은 한번 지은 봇 이름을 영구 예약해서 재활용 자산으로 둠.

7. 드롭 판단 체크리스트

다음 프로젝트에서도 쓸 것:

  1. 내가 쓰는 수준의 품질이 나오나? — 안 나오면 드롭 0순위. 다른 문항 볼 필요 없음.
  2. 품질이 안 나오는 원인이 고쳐질 수 있는 것인가? — 모델 교체, 데이터 부족처럼 근본 제약 이면 드롭. 프롬프트 튜닝, 필터 추가처럼 주변부 면 한 번 더 시도.
  3. 고치는 데 드는 시간 대비 얻는 값어치 있는가? — 새 프로젝트를 시작하는 게 더 재밌고 배움이 많다면 드롭.
  4. 드롭해도 학습은 챙겼는가? — 아직이면 드롭 전에 기록 (이 뉴스레터가 그 기록) 부터.

1 번이 “아니오” 가 나오면 나머지는 사실상 뚫린다. 이번에 품질 문제 를 맨 위에 둔 이유가 그것이다.

8. 이 이야기가 주는 2가지

① 만든 것의 품질에 솔직하라. “3시간 만에 만들었으니 기적이다” 는 사실이지만 “그래서 쓸 만하다” 는 아니다. 만든 과정과 만든 결과를 분리해서 평가해야 한다. 과정이 자랑스럽다고 결과가 타협할 이유는 아니다.

② 드롭은 실패가 아니다. 드롭한 덕에 다음 30시간을 더 나은 데 쓴다. 이번에 내가 그 30시간을 심사레이더 Gmail OAuth 연동 에 돌렸고, 그 결과가 Ep.3 내용이다. 드롭이 없었으면 그 시간은 “기억이 답 품질 고치는” 에 들어갔을 것이고, 결과물은 여전히 애매했을 것이다.

9. 다음 이야기

Ep.3 는 오늘 아침에 끝낸 심사레이더 Gmail OAuth 연동 이야기. 야간 러너가 만든 Mock UI 를 실데이터로 갈아 끼우는 여정 — 그 안에 WSL 의 Playwright 가 Windows Chrome 을 원격 조종하는 법 이라는 예상 못 한 곁가지가 터졌다. 이번엔 약속 지킬 예정이다.

— 강대종 / @ssamssae