[짧QA] 23장. 네트워크 QA는 ‘끊겼을 때’만 보는 게 아니다

네트워크 QA를 이야기하면
가장 먼저 떠올리는 장면이 있다.

• 연결이 끊긴다
• 에러 메시지가 뜬다
• 재접속이 필요하다

그래서 많은 테스트가
이 지점에서 끝난다.

“끊겼을 때 어떻게 되는지 확인했습니다.”

하지만 이 테스트는
네트워크 QA의 절반에도 미치지 못한다.

---

네트워크 문제의 대부분은
끊어지지 않은 상태에서 발생한다.

• 연결은 유지되는데
• 반응이 늦고
• 결과가 어긋난다

이 상태가
가장 위험하다.

왜냐하면
시스템은 정상이라고 판단하고,
유저는 이상하다고 느끼기 때문이다.

---

네트워크 QA에서
가장 먼저 버려야 할 생각은 이것이다.

“연결만 유지되면 된다.”

연결은
조건일 뿐이다.

QA가 봐야 할 것은
연결 상태에서
무엇이 보장되는가다.

• 요청은 반드시 처리되는가
• 응답은 순서대로 오는가
• 실패했을 때 복구 경로가 있는가

이 질문을 하지 않으면
네트워크 QA는
단순 체크가 된다.

---

네트워크 문제는
항상 상태(State)를 흔든다.

• 요청은 보냈는데
  응답이 늦는다
• 응답은 왔는데
  이미 상태가 바뀌었다
• 재시도 중
  중복 처리가 발생한다

이 문제들은
끊김 테스트로는
절대 잡히지 않는다.

---

예를 들어 보자.

보상 수령 요청을 보냈다.

• 서버는 보상을 지급했다
• 클라이언트는 응답을 받지 못했다

유저는
다시 버튼을 누른다.

이 순간 QA가 던져야 할 질문은 이것이다.

• 중복 지급이 되는가
• 이미 처리된 요청으로 인식하는가
• 유저에게 어떤 메시지를 보여주는가

이건
네트워크가 끊겼을 때의 문제가 아니다.

네트워크가 애매하게 동작할 때의 문제다.

---

그래서 네트워크 QA에서
가장 중요한 개념은 이것이다.

불완전한 연결 상태

• 지연
• 패킷 손실
• 순서 꼬임
• 부분 성공

이 상태는
실제 유저 환경에서
가장 흔하다.

QA가
완벽한 연결만 테스트하면
실제 환경은
항상 QA를 배신한다.

---

네트워크 QA는
단독으로 존재하지 않는다.

• 기능 QA와 엮이고
• 상태 QA와 엮이고
• 데이터 QA와 엮인다

그래서 네트워크 문제는
항상 이렇게 보인다.

“어디가 문제인지 모르겠다.”

하지만 구조를 보면
대부분 이 패턴이다.

• 요청 → 처리 → 응답
• 이 중 하나가
  지연되거나 누락된다

QA는
이 흐름을 기준으로
문제를 잘라야 한다.

---

네트워크 QA에서
QA가 반드시 확인해야 할 질문들이 있다.

• 요청은
  언제 재시도되는가
• 재시도 시
  중복 방어가 있는가
• 실패 상태는
  유저에게 명확히 전달되는가
• 네트워크 복구 후
  상태는 자동으로 정합되는가

이 질문이 빠지면
문제는
CS와 운영으로 넘어간다.

---

네트워크 QA의 또 다른 함정은
테스트 환경이다.

QA 환경의 네트워크는
대부분 너무 안정적이다.

• 지연이 적고
• 손실이 없고
• 변동이 없다

이 환경에서
아무리 테스트해도
실제 유저 환경은
재현되지 않는다.

QA는
의도적으로 나쁜 환경을 만들어야 한다.

---

정리하자면 이렇다.

네트워크 QA는
끊겼을 때를 보는 일이 아니다.

네트워크 QA는
연결이 애매하게 유지되는 상황에서
시스템이 어떻게 판단하는지를
끝까지 추적하는 일이다.

• 중복은 막히는가
• 상태는 정합되는가
• 유저는 이해할 수 있는가

이 세 가지를 설명할 수 없다면
네트워크 QA는
아직 끝나지 않은 것이다.

---

네트워크 QA에서 API와 패킷을 이해해야 하는 이유

― 끊김이 아니라 ‘통신 단위’를 보라

네트워크 QA에서
“요청이 갔다”, “응답이 왔다”라는 말은
너무 거칠다.

QA가 봐야 할 것은
연결이 아니라
통신의 단위다.

그 단위가
바로 API와 **패킷(Packet)**이다.

---

API는
서버와 클라이언트가
약속한 대화 방식이다.

• 어떤 요청을 보내면
• 어떤 형식의 응답이 와야 하고
• 어떤 상태를 바꿔야 한다

QA가 API를 본다는 것은
코드를 분석하겠다는 뜻이 아니다.

QA가 API를 본다는 것은
이 질문을 던지는 것이다.

“이 요청은
언제, 어떤 상태에서,
어떤 결과를 만들어야 하는가?”

---

네트워크 QA에서
가장 흔한 착각은 이것이다.

“응답이 왔으니 성공이다.”

하지만 API 관점에서는
이 말이 틀릴 수 있다.

• 응답은 왔지만 실패 코드다
• 응답은 성공이지만 데이터가 비어 있다
• 응답은 정상인데 상태 반영이 안 됐다

QA는
HTTP 200 같은 숫자에
속으면 안 된다.

성공 응답 ≠ 성공 처리다.

---

API QA에서
QA가 반드시 확인해야 할 핵심 축은 세 가지다.

1️⃣ 요청 조건

• 어떤 상태에서 호출되는가
• 중복 호출이 가능한가
• 순서가 보장되는가

2️⃣ 응답 의미

• 성공과 실패는 어떻게 구분되는가
• 부분 성공은 존재하는가
• 클라이언트가 오해할 여지는 없는가

3️⃣ 상태 반영

• 응답 이후 상태는 어떻게 바뀌는가
• 재요청 시 결과는 동일한가
• 실패 후 복구 경로는 있는가

이 셋이 맞지 않으면
네트워크 QA는
항상 애매한 이슈를 만든다.

---

패킷은 ‘보이지 않는 진실’이다

패킷(Packet)은
API보다 한 단계 아래에 있다.

QA가 패킷을 본다는 말은
모든 패킷을 분석하겠다는 뜻이 아니다.

QA가 패킷을 본다는 것은
통신이 실제로 어떤 순서로 오갔는지
확인하겠다는 뜻이다.

---

네트워크 이슈에서
가장 자주 나오는 말이 있다.

“요청은 보냈는데
응답이 안 왔어요.”

이 말은
아무 정보도 아니다.

QA는
패킷 관점에서
이렇게 말할 수 있어야 한다.

• 요청 패킷은 실제로 나갔는가
• 서버 응답은 왔는가
• 중간에서 유실되었는가
• 순서가 바뀌었는가

이 정보가 있어야
문제는
추측이 아니라 사실이 된다.

---

패킷 QA에서
QA가 주의해야 할 핵심 포인트는 이것이다.

• 중복 전송
  → 재시도 로직이 중복 처리를 만들지 않는가
• 순서 역전
  → 늦게 온 응답이 상태를 덮어쓰지 않는가
• 부분 수신
  → 일부 데이터만 도착했을 때 시스템은 어떻게 반응하는가

이 문제들은
끊김 테스트로는
절대 드러나지 않는다.

---

네트워크 QA의 수준을 가르는 질문

API·패킷 관점이 잡힌 QA는
리포트가 이렇게 바뀐다.

• “간헐적으로 발생합니다” ❌
• “네트워크 문제인 것 같습니다” ❌

대신 이렇게 말한다.

• “동일 API 요청이
  네트워크 지연 상황에서
  중복 처리됩니다”
• “응답 순서가 뒤바뀔 경우
  상태 롤백이 발생합니다”

이 순간
QA는
현상을 전달하는 사람이 아니라
구조를 설명하는 사람이 된다.

---

네트워크 QA에서 이론이 중요한 이유

API와 패킷 개념을
모르고도
네트워크 테스트는 할 수 있다.

하지만 그 테스트는
항상 운에 의존한다.

• 운 좋게 문제 안 터지면 통과
• 운 나쁘면 라이브에서 사고

이건 테스트가 아니다.

QA가 이론을 알아야 하는 이유는
모든 경우를 직접 만들 수 없기 때문이다.

대신
이론으로
“어디서 깨질 수 있는지”를
예측해야 한다.

---

정리하자면 이렇다.

네트워크 QA는
연결 상태를 보는 일이 아니다.

네트워크 QA는
API 호출과 패킷 흐름이
의도한 대로 동작하는지를
확인하는 일이다.

• 요청은 언제든 중복될 수 있고
• 응답은 언제든 늦을 수 있으며
• 패킷은 언제든 순서를 어길 수 있다

QA는
이 현실을 전제로
테스트해야 한다.