A
약 75초
경험 중심 1인칭 답변
학교 프로젝트에서 실시간 채팅 기능을 만들 때 REST API와 WebSocket 중 어느 것을 쓸지 결정하는 것이 첫 번째 어려움이었습니다. REST로 구현했더니 폴링 방식에서 클라이언트가 0.5초마다 요청을 보내 서버 부하가 급격히 올라가는 문제가 생겼습니다. WebSocket으로 전환 후 연결 유지와 재연결 로직을 직접 구현했는데, 네트워크가 끊겼을 때 메시지 유실을 어떻게 처리하는지가 두 번째 어려움이었습니다. 이것은 클라이언트 측에서 메시지에 ID를 붙이고, 재연결 시 마지막 수신 ID 이후 메시지를 재요청하는 방식으로 해결했습니다. 세 번째 어려움은 양방향 통신에서 클라이언트 상태와 서버 상태를 어떻게 동기화하는가였는데, 서버를 단일 진실 공급원으로 삼고 클라이언트는 로컬 캐시를 갖되 주기적으로 검증하는 구조를 택했습니다.
통신 설계는 "연결됐을 때"보다 "연결이 끊겼을 때"를 먼저 설계하는 것이 더 중요하다는 것을 배웠습니다.
이 결의 특징
실패를 구체적으로 관찰하고 각 단계별 문제를 기술적으로 풀어가는 흐름이 뚜렷합니다. 통신 신뢰성을 '연결됐을 때'가 아닌 '끊겼을 때'를 먼저 설계하는 사고방식이 두드러집니다.
이 결이 통하는 자리
장애 상황과 네트워크 변수를 고려하는 조직에서 신뢰를 얻습니다. 성능 최적화만 아니라 안정성을 우선으로 보는 팀 문화와 맞닿아 있습니다.