Loopers WIL – 2주차

1. 멱등성 – GET만 멱등하면 되는 게 아니었다

처음엔 단순하게 생각했다.
“GET은 멱등하고, POST는 멱등하지 않다.”

하지만 좋아요 기능을 설계하면서 이 생각은 깨졌다.
좋아요는 POST 요청이지만, 사용자가 100번을 눌러도 결과는 한 번만 반영되어야 한다.
→ 이건 POST라도 비즈니스적으로는 멱등해야 한다.

그제야 알게 됐다.
HTTP 메서드의 특성만 따지는 게 아니라,
**“이 요청이 시스템 상태를 얼마나 예측 가능하게 유지시켜주는가”**가 진짜 기준이라는 걸.

이건 단순한 사용성 이슈를 넘어서 아래와 같은 시스템 설계로 이어진다:

• 💥 동시성 제어
• 🔁 재시도(Retry) 대응
• 🔐 API 설계 시 신뢰성 확보

결국 멱등성은 단순히 HTTP 개념이 아니라,
서버의 신뢰성과 안정성을 지탱하는 설계 원칙이었다.

---

🧨 2. 에러 메시지 관리 – Enum만으로는 끝이 아니었다

이번 주에 에러 처리를 설계하면서 가장 먼저 떠올린 건

“에러 메시지는 하드코딩하지 말자.”

그래서 처음에는 ErrorType 이라는 Enum에
에러 코드와 메시지를 함께 묶어서 관리했다.

그런데 금방 문제가 생겼다.

• 메시지가 수십 개로 늘어나면서 Enum 하나가 비대해지고
• 도메인별로 나눠보려 해도 경계가 애매하고
• 무엇보다 다국어 대응이 불가능했다

그래서 고민이 아래와 같은 흐름으로 정리됐다.

 

1. Enum 기반 관리  
  → 유지보수는 쉬움, 확장성은 낮음

2. 도메인별 Enum 분리  
  → 어느 정도 모듈화 가능, 다국어 불가

3. code는 Enum/DB, message는 Property/DB 분리  
  → 다국어 대응 가능, 관리 구조 이원화

4. Admin에서 NoSQL 기반으로 메시지 관리  
  → 운영 중 메시지 수정, 다국어 추가 가능

“에러 메시지는 사용자에게 전달되는 프론트라인이다.”
라는 인식으로, 메시지 역시 설계 대상이라는 걸 크게 느꼈다.

---

🪓 3. try-catch 전략 – 얼마나, 어디까지 잡을 것인가?

SonaQube에서 try-catch 범위가 넓다고 경고가 떴다.
처음엔 그냥 무시했지만, 점점 고민이 생겼다.

• try 범위를 좁게 잡으면 예외 처리가 분산되고
• catch를 너무 많이 쓰면 코드가 난잡해진다
• CustomException만 잡으면, 알 수 없는 예외는 그대로 노출된다

결국 기준을 세웠다.

 

try {
  어떤 작업()
} catch (CustomException e) {
  // 인지한 예외: 명확한 응답으로 포장
} catch (Throwable e) {
  // 예기치 못한 예외: 500으로 래핑 + 로깅
}
예외는 무조건 포착한다고 좋은 게 아니었다.
“내가 아는 예외만 책임지고, 모르는 예외는 안전하게 감싼다”는 철학이 필요했다.

---

🧪 4. 테스트 스타일 – GWT vs AAA, 기준은 무엇인가?

이번 주 테스트 리팩토링을 하면서,
GWT(Given-When-Then) 패턴을 쓰고 있다는 걸 문득 깨달았다.
근데 팀원들 코드를 보니 어떤 곳은 AAA(Arrange-Act-Assert)를 쓰고 있었다.

딱히 이유 없이 GWT를 쓰고 있는 나 자신을 보며,

“이 구조가 진짜 맞는 걸까?”
라는 의문이 들었다.

---

🔍 GWT vs AAA – 뭐가 다른가?

기준GWT (BDD 스타일)AAA (전통 스타일)

목적	행위 중심 설계	로직 흐름 중심
표현	Given / When / Then	Arrange / Act / Assert
사용	시나리오 테스트	단위 테스트

 

GWT는 “어떤 상황에서 어떤 행위가 어떤 결과를 낳는가”를
사람이 읽기 좋게 표현하기에 좋았다.
AAA는 “로직 흐름 중심”으로 테스트가 간결하고 직관적이다.

---

🔍 내가 내린 기준

• 비즈니스 로직은 GWT
  → 유즈케이스 중심 테스트, 읽는 사람이 이해하기 쉬움
• 도메인 유틸 / 내부 로직은 AAA
  → 빠르게 로직 검증, 선언적이고 직관적

테스트 스타일도 결국 일관성과 의도가 중요하다는 걸 느꼈다.

---

✍️ 마무리 – 기능보다 기준

이번 주엔 코드를 많이 짠 것 같진 않다.
하지만 확실한 건 있다.

“코드를 어떻게 짤지”보다,
“어떤 기준으로 설계할지”가 더 중요하다는 걸 배운 한 주였다.

• 멱등성은 API의 신뢰성과 직결되고,
• 에러 메시지는 사용자 경험과 연결되고,
• 예외 처리는 시스템의 복원력을 결정하고,
• 테스트는 설계의 거울이라는 걸 실감했다.

이번 주는 그렇게, “예측 가능한 코드”를 만드는 기준들을 고민한 시간이었다.