안녕하세요! 퇴근 후 취미로 코딩하고 있는 직장인 바이브코더입니다.
오늘 작업 트리를 깨끗하게 정돈하고, 전체 7단계 마일스톤 중 3단계(괘사·효사 한글 번역)와 4단계(RAG 청크 적재)를 무사히 돌파했습니다.
유닛 테스트 20건도 올패스 상태입니다.
현재 깃허브 레포는 프라이빗(Private)으로 굳게 닫혀 있지만, 이곳 커뮤니티에는 생생한 삽질기와 설계를 아낌없이 공유해 드리려 합니다.
오늘 마주한 "AI 모델들이 부리는 꼼수와 잔머리" 격파 일지입니다.
🛠️ My Vibe Coding Stack
- Local Dev: Mac Mini M4 Pro + Ollama + Docker Compose
- Database: PostgreSQL 16 + pgvector (iching-db)
- Model: Gemma 4 26B (MoE) / Gemini / Claude API
- AI Assistants: Google Antigravity + Claude Code
📝 오늘의 작업 결과 (3~4단계 완성)
1. [3단계 완료] 괘사·효사 한글 번역 450건 적재
파일럿 12건 진행 후 블라인드 채점을 통해 용어표 110항목을 견고하게 확정했습니다. 이후 두 개의 대형 모델(클로드, 제미나이)을 하이브리드로
태워 450건을 뽑아낸 뒤 DB 적재를 마쳤습니다. (괘사 64건, 효사 386건 모두 NULL 없이 100% 성공)
2. [4단계 완료] RAG 청크 1,751건 적재
정전(程傳) 주석 1,237건과 소상전·단전·대상전 514건의 한글 번역을 거쳐 768차원 임베딩 벡터로 PostgreSQL pgvector에 무사히
꽂아 넣었습니다. 64괘 전체 커버리지를 만족하며, 실제 질문을 던져 의미 검색(Semantic Search)이 올바르게 괘를 찾아내는지
교차 검증까지 마쳤습니다.
🔍 오늘의 실질: LLM의 '꼼수'와 찐 버그 디버깅 기록
1. 파서가 부록(계사전 등)을 마지막 괘로 집어삼키던 오류
괘64의 1효 효사 데이터에 계사전 등 부록 9,688자가 한꺼번에 달라붙어 삼켜지는 심각한 파싱 로직 오류를 발견했습니다.
그대로 진행했다면 괘의 의미가 엉망으로 오염되었을 텐데, 바이트 단위로 꼼꼼하게 대조하여 원본 재파싱을 끝마치고
나머지 446건 데이터의 동일성을 확인했습니다.
2. max_tokens=2048의 덫 (Gemini를 깨뜨린 주범)
테스트를 1건만 돌릴 때는 가장 짧은 데이터가 우연히 통과되어 몰랐는데, 대량 배치 중 4건 중 3건꼴로 실패가 떴습니다.
원인은 추론 전용 모델의 사고 과정(Reasoning Tokens)이 너무 길어져 정작 답변이 나오기 전에 '토큰 예산 부족'으로 아웃풋이 댕강 잘리는
문제였습니다. 토큰 제한을 늘려 우아하게 해결했습니다.
3. 병렬 모드 데드락 (Deadlock)
비동기 병렬 스크립트 실행 중 같은 락(Lock)을 쥔 채 내부에서 다시 락을 잡으려고 시도하는 교착 상태가 일어났습니다.
재진입이 가능한 RLock으로 교체하여 병목 현상을 뚫었습니다.
4. 450건 전수 조사에서 드러난 Claude의 고질병
파일럿 12건의 좁은 표본에서는 완벽해 보였으나, 450건 대량 배치를 돌리니 한자를 누락하고 번역하지 않은 경우가 9건,
핵심 고자(古字)인 '眚(재앙 생)'을 단순 '허물'로 두루뭉술하게 뭉개버린 번역이 3건 발견되었습니다.
해당 오염 데이터 13건을 품질이 훨씬 뛰어났던 Gemini의 번역 값으로 교체했습니다.
5. 안전 스크리너의 '책임 회피'와 우회 규칙
정신의학적 위기나 무리한 질문을 스크리닝할 때, 모호하면 상담사에게 핸드오프하라는 'ASK' 규칙을 명시해 두었더니 모델이
"오늘 밤에 끝내려고요" 같은 심각한 우울 위기 신호(13건)조차 직접 처리하지 않고 전부 'ASK' 옵션으로 도망쳐서
책임을 회피해 버리는 현상이 발생했습니다. 규칙의 허점을 정교하게 보완했습니다.
💡 반복해서 마주한 가장 큰 교훈: "모델은 절대 자발적으로 모르겠다고 하지 않는다"
번역 파일럿 단계에서나 안전 필터링 단계에서나, 모델은 자신이 헷갈려하는 영역(flag, unclear)에 대해 0건으로 리포팅하며
완벽한 것처럼 자기 신고를 속였습니다.
결국 자동화된 모니터링을 "모델의 정직성"에 기대어 설계하면 반드시 무너진다는 뼈아픈 교훈을 얻었습니다.
이를 타개하기 위해 두 모델의 번역 결과가 서로 어긋나는 부분(Diff)을 '블라인드 검수 목록'으로 강제 추출하는
실패 방지 테스트 세트를 먼저 세팅했습니다.
다음 단계인 5단계는 멀티에이전트 파이프라인의 핵심인 '에이전트 4종 구현 및 실제 연동'입니다.
전체 에이전트를 한 번에 다 붙이면 에러 위치를 찾기 불가능하므로, 목(Mock)/스텁(Stub)으로 파이프라인의 껍데기를 먼저 단단하게 이어둔 후
해석 에이전트를 척추 삼아 하나씩 실제 모듈로 교체해 갈 예정입니다.
💬 바이브코더분들께 드리는 질문!
1. 세션 간 연동 및 상담 에이전트의 반복 호출 테스트를 구현하실 때, 테스트 크레딧 누수나 비용 낭비를 막는 효율적인 모킹(Mocking) 노하우가 있다면 공유 부탁드립니다! 👇
