only 해피패스 테스팅만 하면 벌어지는 일: 코드가 잘 돌아가는데 데이터가 왜 사라질까요?;;

🧩 배경: 코드를 또 뜯어봤습니다..

팀 내에서 비동기로 수집한 데이터를 LLM 전처리 과정에 태우고 이를 최종 병합하는 로직이 있었다.

겉보기에는 결과물도 잘 나오고 큰 문제가 없어 보였다.

하지만 데이터 처리의 핵심은 겉보기에 멀쩡한 것이 다가 아니지 않은가..?

데이터가 누락 없이 정확하게 흘러가는가에 있기에 기존 코드를 깊숙이 보게 되었다.

 

 

💭 내 고민: 눈에 보이지 않던 시한폭탄들

( 👆🏻 이 소제목은 내 이야기를 들은 gemini의 답변에서 따왔다 ㅋㅋㅋㅋㅋㅋ) 

실제로 코드를 뜯어보니 생각보다 꽤 아찔한 구조적 결함들이 숨어 있었다(난 왜 이걸 이제야 발견했지..?)

 

1. 불명확한 식별 기준

• 데이터를 취합할 때 기준이 되는 식별 키의 레벨이 너~무 상위 개념을으로 뭉뚱그려져 있었다
• 이로 인해 하위 상세 단위에서 데이터가 꼬이거나 오매핑/오치환될 위험이 있었다..

2. 말도 없이 사라지는 비정상 데이터

• 데이터 정제 과정에서 실패하거나 빈 값이 들어오는 등 잘못된 값들에 대해, 로직이 아무런 에러 로그도 남기지 않고 continue로 넘어가버린다
• 실패 시 실패 상태의 결과 객체를 생성/처리하도록 해놨는데.. 이게 잘 안 타고 있었던 것이다..!
• 즉, 시스템이 터지지 않고 넘어가는 것까지는 의도가 맞았지만(여기까진 OK) -> 그 속에서 데이터가 누락되고 있었던 것(이건 안됨!!)
• 특히 LLM을 태우는 만큼 비정상의 범위는 솔직히 개발자인 나도 잘 모르겠다. 알 수 없다!!! 그래서 그만큼 예외 데이터 처리가 더 중요했는데 말이다.

3. 추적이 불가능한 예외 처리

• 에러가 발생해도 구체적인 사유 없이 단독으로 raise를 던지고 있음 -> 이래선 운영 중에 문제가 생겼을 때 원인을 추적하기가 불가능에 가깝다..

 

🛠️ 해결을 위한 시도들: 구조 개선

기존의 안일했던 구조(순서 기반 매핑)을 걷어내고 중간중간 예외 로직을 촘촘하게 설계해 보았다

 

1. 식별 기준 일원화하기(하위 상세 단위 기준)

• 식별 키를 상위 레벨이 아닌 가장 구체적인 하위 단위로 일원화하여 저장하고 조회하도록 매핑 로직을 바꿨다

2. 검증 단계 분리

• 데이터가 들어오면 단계별로 쪼갰다(실제 내용을 적을 순 없으니 간단 예시로 대체해본다....):
  • 즉시 원본 검증
  • 타입 체크
  • 공백 체크

3. 누락 방지 실패 처리 강화

• 에러를 컨티뉴로 씹지 않고 실패 상태의 결과 객체를 "정상적으로" 생성하여 에러 메시지와 함께 로그를 남겼다
• 최종결과에서 유실되지 않도록 정말 다양한 테스트를 해봤는데 내 머리론 한계가 있어서 동기들에게 테스트 케이스 리뷰를 부탁했다..ㅎㅎ (고마워요 사랑합니다) 

 

📈 변화 : 고생(?) 끝에 얻은 안정성

성공 케이스에만 집중되어 있던 코드에 꼼꼼한 예외 처리와 명확한 기준 키를 심어주고 나서 느낀 변화는 다음과 같다:

• 정합성 향상: 상세 단위의 데이터 병합 정확도가 올라갔고 중복이나 오치환 이슈가 확연히 줄었다
• 관측 가능성: 비정상 데이터가 들어와도 유실 없이 '실패 상태'로 아주 잘 보인다
• 장애 대응 속도 향상: 단계별 로그와 명시적 에러 덕분에 문제가 생겨도 더 빠른 원인 파악이 가능해졌다(특히 나 말고 다른 팀원분들이 이슈를 보셨을 때 트래킹 속도가 빨라진 게 체감된다!)

 

📌 회고 & 다음 목표

"돌아가는 코드가 좋은 코드의 전부가 아니다."

특히 데이터 처리나 AI 프롬프트 전처리 단계에서는 에러를 조용히 묻고 지나가는 코드가 얼마나 위험한지 한 번 더 뼈저리게 체감했다

데이터 유실을 막으려면 성공뿐만 아니라 실패마저도 명확하게 기록하여 갖고 있어야한다는 시각의 전환을 다시금 뇌리에 각인할 수 있는 기회였다ㅎㅎ

앞으로는 해피 패스(Happy Path)만 그릴 게 아니라 최악의 예외 상황을 먼저 설계하고 방어벽을 치는(?) 습관을 지녀야겠다..!