이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 논문 실험으로 실시간 알림 시스템 POC를 진행했습니다. WebSocket과 SSE 중 어느 방식이 더 적합한지 확인하는 게 목적이었고, 2주 안에 판단 가능한 최소 구현이라는 범위를 먼저 정했습니다. 성공 기준도 구체적으로 잡았는데, 100명 동시 접속 시 메시지 지연 1초 이내를 넘기면 채택하지 않는다는 조건이었습니다. 구현 후 locust로 부하 테스트를 돌려 측정값을 기록했고, SSE 방식이 목표를 만족했습니다. 운영 관점에서는 POC 이후 재현 가능한 인계 문서를 팀 위키에 남겨 다른 팀원도 같은 환경을 재구성할 수 있게 했습니다. 모니터링 중에 SSE 연결이 끊길 때 자동 재연결이 안 되는 케이스를 발견해 클라이언트 EventSource 재구독 로직을 추가했는데, 운영 관점은 구현 이후에야 보이는 부분이 많다는 걸 배웠습니다.
POC 경험에서 운영을 의식하게 된 경험은 POC 결과가 좋아도 실제 운영 환경에서 달라지는 부분이 있다는 걸 인식한 케이스였습니다. WebSocket POC에서 연결 수를 늘려가며 테스트했는데, 로컬에서는 문제가 없었지만 실제 서버 환경에서는 동시 연결 수에 따른 메모리 사용량 문제가 생겼습니다.
POC가 검증하는 것은 기능 가능성이고, 운영 가능성은 추가 검증이 필요하다는 걸 이해했습니다. POC 결과를 운영 적용 가능 여부로 직접 이어지는 것으로 보면 나중에 예상치 못한 문제가 생길 수 있다는 결이 남아 있습니다.
POC 경험에서 확장으로 이어진 경험은 POC 결과를 기반으로 실제 구현 방향을 결정한 케이스였습니다. WebSocket과 SSE를 비교한 POC 결과를 팀에 공유하면서 각 방식의 장단점을 요약했습니다. 결과를 근거로 실제 구현에서 SSE를 선택하는 결정을 했습니다.
POC가 실제 결정으로 이어지는 경험이 처음이었는데, POC의 가치는 기술 탐색만이 아니라 결정의 근거를 만드는 것에 있다는 걸 이해했습니다. POC를 의미 있게 만드는 것은 결과 자체가 아니라 결과를 바탕으로 다음 결정이 이루어지는 것이라는 결이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 람다256 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.