Claude CLI에 텍스트 넘길 때 대시가 옵션으로 둔갑하던 버그
목차
새벽 2시, 파이프라인 로그를 훑다가 조용히 끊겨 있던 스크럽 단계를 발견했다. 에러 메시지는 처음엔 전혀 엉뚱한 방향을 가리켰다.
증상: 옵션인 줄 알았던 문단
opsvoro 스크럽 파이프라인은 원문 텍스트를 단락 단위로 잘라서 Claude CLI로 흘려보내는 구조다. 평소엔 문제가 없었는데, 특정 문서에서 갑자기 CLI가 이상한 에러를 뱉기 시작했다.
범인을 찾고 보니 단순했다. 문단 첫 글자가 -(대시)로 시작하는 경우, Claude CLI가 그걸 인자 텍스트가 아니라 플래그 옵션으로 파싱하고 있었다.
예를 들면 이런 케이스:
- 항목 A
- 항목 B
- 항목 C
이 문단을 그대로 CLI에 넘기면, 첫 줄 - 항목 A의 -가 옵션 플래그 파싱에 걸려버린다. 셸에서 --로 옵션 구분을 끝내거나, 래퍼로 감싸지 않으면 CLI는 이걸 명령어 인수로 오해한다.
수정 방향
수정 포인트는 scrub_paragraphs.py 하나였다. 문단을 CLI에 넘기기 직전, 래퍼를 앞에 붙여서 leading-dash가 CLI 파서에 도달하기 전에 중립화하는 방식으로 해결했다.
- 별도 플래그(
--)로 옵션 구분자를 끼워넣는 방법도 있었지만, 파이프라인 상 다른 인수들과 순서 충돌이 생길 수 있었다 - 래퍼로 문단 자체를 감싸는 방식이 가장 비침습적이고, 이후 다른 문단 포맷에도 방어적으로 대응 가능했다
- 수정 범위가 해당 파일 내 전달 로직 한 곳에 국한돼 사이드 이펙트가 없었다
왜 새벽에야 터졌나
| 항목 | 상황 |
|---|---|
| 평소 문서 | 문단 첫 글자가 대시인 경우 거의 없었음 |
| 이번 문서 | 불릿 리스트 구조로 시작하는 단락이 포함됨 |
| 탐지 시점 | 파이프라인 로그 주기 확인 중 |
결국 입력 데이터 패턴이 바뀌면서 드러난 잠재 버그였다. 단위 테스트에서 대시 시작 문단을 케이스로 넣지 않았던 게 아쉬웠다. 다음엔 스크럽 입력 픽스처에 leading-dash 케이스를 명시적으로 추가해둘 것.
짧은 수정이었지만, 파이프라인이 침묵하며 데이터를 버리던 문제라 조용한 데이터 손실 쪽으로 번질 수 있었다. 새벽에 잡아서 다행이었다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.