이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 사용자가 회원가입하면 웰컴 메일을 보내는 기능을 만들 때, 처음엔 HTTP 요청 흐름 안에서 메일 발송을 바로 처리했는데 메일 서버가 느리면 API 응답도 같이 느려지는 문제가 생겼습니다. 그래서 회원가입 완료 이벤트를 큐에 넣고, 별도 워커가 메일을 보내도록 분리했습니다. 처음 구현할 때 큐가 차는 속도보다 워커가 느려서 메일이 수분 뒤에 도착하는 현상이 있었고, 워커 수를 늘리기 전에 병목 원인을 먼저 확인했어야 했는데 그냥 늘렸다가 서버 리소스를 과하게 잡은 게 실패였습니다. 이후로 워커 처리량과 큐 적재 속도를 같이 보는 습관을 들였습니다. 이벤트 기반이 처음이라 간단한 예제였지만, 처리를 분리하면 각 부분을 독립적으로 조정할 수 있다는 걸 직접 경험했습니다.
사이드 프로젝트에서 외부 서비스 웹훅을 받아 처리하는 기능을 만들었습니다. 웹훅이 오면 즉시 처리하는 방식으로 시작했는데, 처리 중 오류가 나면 해당 이벤트가 그냥 사라지는 문제가 있었습니다. 그래서 수신된 웹훅을 DB에 먼저 저장하고, 별도 처리 루프에서 순서대로 실행하는 구조로 바꿨습니다. 실패한 이벤트는 재시도 횟수를 기록해서 3회 초과 시 실패 처리하도록 했습니다. 처음 재시도 로직을 넣을 때 무한 루프가 생겨서 같은 이벤트가 계속 처리됐고, 멱등성 처리를 빠뜨린 게 원인이었습니다. 규모는 작았지만 이벤트 기반 구조에서 실패 처리와 멱등성이 왜 중요한지 몸으로 익혔습니다.
인프라 수업에서 서버 지표가 임계치를 넘으면 슬랙으로 알림을 보내는 파이프라인을 팀원과 함께 설계하는 실습을 했습니다. 저는 지표 수집 → 임계치 초과 이벤트 발생 → 알림 발송 세 단계를 분리하는 구조를 제안했습니다. 실습 환경이 제한적이라 실제로 다 구현하진 못하고 설계와 일부 구현만 했지만, 각 단계를 분리하면 알림 채널이 바뀌어도 앞 단계를 건드리지 않아도 된다는 장점을 팀 발표에서 설명했습니다. 다른 팀이 단일 스크립트로 모두 처리하는 방식을 썼는데, 교수님이 두 방식의 유지보수 차이를 질문하셔서 설계 이유를 설명할 수 있었습니다. 실습 수준이었지만 분리 설계가 왜 필요한지 직접 비교하면서 익혔습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.