이슈 대응에 대해 느낀점

🔧 이슈 대응을 하면서 정리한 3가지 기준

최근 프로젝트를 진행하면서
단순히 개발만 하는 것이 아니라 이슈를 어떻게 다루느냐가 더 중요하다는 걸 느꼈다.

그래서 현재는 아래 3가지 기준을 가지고 이슈를 대응하고 있다.

---

1️⃣ 정말 이슈인가? (재현 가능 여부)

컨버전 과정에서는 특히
실제 해외 구매 시스템의 업무 프로세스를 완전히 이해하기 어렵다.

그래서 멕시코 현지에서 이슈가 올라왔을 때,
가장 먼저 확인하는 것은 **“이게 정말 이슈인가?”**이다.

• 사용자의 업무 프로세스 미숙지인지
• 단순 데이터 문제인지
• 실제 시스템 오류인지

이걸 구분하지 않으면, 불필요한 디버깅에 시간을 쓰게 된다.

결국 이슈는 반드시 재현 가능해야 한다.
재현되지 않는 문제는 원인을 찾기도, 해결하기도 어렵기 때문이다.

---

2️⃣ 근본적인 원인은 무엇인가?

문제가 발생했을 때 가장 중요한 건
겉으로 보이는 증상이 아니라, 근본 원인을 해결하는 것이다.

급하게 대응해야 한다는 이유로
하드코딩이나 임시 처방으로 문제를 막아버리면,

• 예상하지 못한 부작용이 생기거나
• 동일한 이슈가 다시 발생할 가능성이 높다

결국 한 번 더 고치는 일이 생긴다.

그래서 시간이 조금 더 걸리더라도
**“왜 이 문제가 발생했는가?”**를 끝까지 파고드는 것이 중요하다.

---

3️⃣ 수정으로 인한 Side Effect는 없는가?

사실 이상적으로는
1번과 2번을 제대로 수행했다면,
Side Effect는 거의 발생하지 않는다.

하지만 현실에서는

• 이슈 검증이 부족하거나
• 원인을 정확히 파악하지 못한 상태에서 수정할 경우

특히 테스트가 충분하지 않다면
수정 이후 또 다른 문제가 발생하는 경우가 많다.

그래서 코드 수정 이후에는
다른 영역에 영향이 없는지 반드시 확인하는 과정이 필요하다.

---

💭 정리

이 세 가지를 지키면서 느낀 점은 명확하다.

“이슈 대응은 빠르게 하는 것이 아니라, 정확하게 하는 것이다.”

 

조금 느리더라도
재현 → 원인 분석 → 영향 범위 확인
이 흐름을 지키는 것이 결과적으로 더 빠르고 안정적인 방법이었다.