면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
개인 프로젝트로 만든 웹 서비스가 특정 시간대마다 서버가 다운되는 문제를 겪은 적이 있습니다. 처음엔 트래픽이 몰려서 그런가 싶어 서버 사양부터 의심했는데, 실제로는 트래픽이 많지 않은 시간에도 다운되는 걸 확인하고 원인을 다시 찾아야 했습니다. 로그를 시간대별로 살펴보니 특정 배치 스크립트가 실행될 때마다 메모리 사용량이 급증하는 패턴이 보였고, 결국 그 스크립트의 무한 루프 버그가 원인이었습니다. 짐작만으로 서버 사양을 올렸다면 문제는 해결되지 않았을 텐데, 로그를 직접 확인하고서야 진짜 원인을 찾을 수 있었습니다. 이 경험으로 장애가 발생하면 짐작보다 로그를 먼저 확인하는 습관이 중요하다는 걸 배웠습니다.
백엔드 인턴 시절 제가 작성한 코드를 배포한 직후 일부 API 응답이 500 에러를 반환하는 상황이 발생한 적이 있습니다. 처음엔 당황해서 혼자 원인을 찾으려 했는데, 시간이 지체될수록 오류 범위가 넓어지는 걸 보고 바로 팀 채널에 상황을 공유했습니다. 선배와 함께 로그를 확인한 결과, 새로 추가한 필드에 대한 null 처리를 빠뜨린 게 원인이었습니다. 긴급히 롤백한 뒤 다음 날 null 체크를 추가해 다시 배포했습니다. 혼자 해결하려다 시간을 지체했던 그 순간을 계기로, 이후로는 문제를 발견하면 먼저 상황을 공유하고 함께 판단하는 게 더 빠른 해결로 이어진다는 걸 배웠습니다.
졸업 프로젝트에서 특정 시간대에만 데이터베이스 연결 오류가 간헐적으로 발생하는 문제를 겪었습니다. 재현이 잘 안 돼서 처음엔 원인을 특정하기 어려웠는데, 오류 발생 시점의 커넥션 풀 사용량을 로그로 남기도록 코드를 수정한 뒤 다시 관찰했습니다. 그 결과 동시 요청이 몰리는 순간 커넥션 풀이 고갈되는 게 원인이라는 걸 확인했고, 풀 크기를 조정하고 타임아웃 설정을 추가해 문제를 해결했습니다. 처음엔 재현이 안 돼 답답했지만, 오히려 관찰 로그를 추가하는 방식으로 접근을 바꾸면서 원인을 찾을 수 있었습니다. 이 경험으로 재현이 어려운 문제일수록 관찰할 수 있는 지점을 늘리는 게 중요하다는 걸 배웠습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.