제출 소스의 상태 검증 일관화: HEAD 가드 추가

여러 제출 경로를 관리하다 보면 같은 로직을 여러 곳에서 서로 다르게 구현하게 되는 일이 생긴다. 이번엔 GSC 제출 모듈의 여러 소스(slecs, opsvoro, coway)에 HEAD 가드를 추가해서 상태 검증 로직을 일관화했다.

배경: 왜 상태 검증이 필요했나

데이터를 외부 시스템에 제출할 때는 단순히 "지금 데이터를 보내면 되지"가 아니다. 특히 멀티 소스 환경에서는 각 제출 경로가 현재 어떤 상태에 있는지 정확히 알아야 한다. 예를 들어:

• 이미 같은 데이터를 제출했는데 또 제출하려는 건 아닐까?
• 이전 제출이 실패한 상태에서 새로운 제출을 시도하면?
• 여러 제출이 동시에 일어나면 어떤 데이터가 최종 상태인가?

이런 질문들이 나오는 이유는 제출 시스템이 단순히 "한 번 보내고 끝"이 아니라, 상태를 추적하고 재시도하고 동기화해야 하기 때문이다. 그래서 HEAD(현재 상태)를 검증하는 로직이 필요했다.

HEAD 가드의 역할

HEAD 가드는 간단히 말해서 "지금 상태가 안전한가?"를 확인하는 검증 단계다. 제출을 진행하기 전에:

• 현재 HEAD가 예상된 상태와 일치하는가
• 이미 제출한 상태인가
• 제출 중인 다른 작업이 있는가

이런 식으로 사전 검증을 하는 것. 이 패턴은 분산 시스템에서 매우 흔하다. 데이터베이스의 낙관적 잠금(optimistic locking), Git의 rebase 전 검증, 또는 마이크로서비스 간 상태 동기화 등에서 비슷한 개념을 쓴다. 여러 경로에서 동시에 상태를 변경할 가능성이 있을 때, 충돌을 사전에 탐지하는 안전장치 역할을 한다.

구현: 여러 소스에 일관되게 적용

_lib/gsc_submit.py와 _lib/coway_gsc_submit.py 두 파일에 HEAD 가드를 추가했다.

중요한 건 이제 slecs, opsvoro, coway 모두에서 같은 방식으로 상태를 검증한다는 것. 팀원들도 코드를 읽을 때 "어느 소스든 같은 로직을 따르겠구나" 하고 예측 가능해진다. 버그가 생겼을 때도 "제출 로직은 여기를 봐"라고 명확히 가리킬 수 있다.

왜 이런 일관화가 중요한가

코드리뷰를 하다 보면 자주 마주치는 패턴이 있다. 각 팀원이 비슷한 기능을 다른 방식으로 구현하는 경우다. 처음엔 문제 없어 보이지만, 시간이 지나면서:

• 한쪽에서는 버그 수정이 되고 다른 쪽은 안 된다
• 성능 개선이 일부 경로에만 적용된다
• 새로운 요구사항이 생기면 여러 곳을 동시에 수정해야 한다
• 온보딩할 팀원이 어느 패턴을 따라야 할지 헷갈린다

그래서 초기에 "이 로직은 여러 곳에서 쓰이고 있으니 통일하자"고 판단하는 게 팀의 유지보수 비용을 크게 줄인다. 이 경우 새로운 제출 소스가 생길 때마다 같은 패턴을 복사해서 쓰면 되니까 일관성도 자동으로 보장된다.

회고

이번 작업을 하면서 느낀 건, 기능 개발만큼 "일관성"도 의사결정에 포함되어야 한다는 것. 특히 팀이 여러 비슷한 모듈을 관리할 때, 각자 최선의 선택을 했다고 생각해도 큰 그림에서는 산 맥락이 될 수 있다는 점이다.

좋은 패턴을 찾으면 과감하게 다른 곳에도 적용하는 게, 결국 코드 리뷰 시간, 버그 수정 시간, 온보딩 시간을 모두 아낀다. 그리고 팀원들 사이에서도 신뢰가 생긴다. "아, 이 팀은 같은 문제를 같은 방식으로 푸는구나."

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.