이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 API 연동이 갑자기 안 되는 상황이 생겼습니다. 처음엔 이것저것 바꿔보다가 시간만 날렸고, 결국 코드 문제인지 환경 문제인지부터 분리하는 방식으로 접근을 바꿨습니다. 먼저 동일한 요청을 Postman으로 직접 날려봤고, 거기서는 잘 됐습니다. 그러면 코드 문제였고, 로그를 보니 헤더 값이 빠져 있었습니다.
원인을 범위별로 좁혀가는 방식이 이리저리 시도하는 것보다 훨씬 빠르다는 걸 그때 배웠습니다. 그 이후로는 문제가 생기면 '어느 레이어의 문제인지'를 먼저 정하고 들어가는 습관이 생겼습니다. 실패했던 건 처음에 방향 없이 수정을 반복한 것인데, 그 경험이 오히려 체계적 접근의 중요성을 배우게 했습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
졸업 프로젝트에서 데이터베이스 조회가 예상과 다른 결과를 내는 문제를 만났습니다. 저는 혼자서 2시간을 고민하다가 결국 팀원에게 물었는데, 10분 만에 해결됐습니다. 인덱스 설정을 빠뜨린 문제였는데, 저는 쿼리만 보고 있어서 놓쳤던 겁니다. 그 이후로 저는 '30분 이상 막히면 팀원에게 물어보는 것도 실력'이라는 기준을 만들었습니다. 물어보기 전에 제가 시도한 것과 현재 상태를 정리해서 보여주는 방식을 쓰는데, 그렇게 하면 팀원도 빠르게 파악할 수 있고 제 생각도 정리가 됩니다. 기술적 문제를 혼자 해결하는 것도 중요하지만, 막히는 걸 빨리 인식하고 도움을 요청하는 것도 팀 전체 효율에 도움이 된다고 생각합니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
인턴 때 서버 배포 이후 특정 기능만 오류가 나는 상황이 있었습니다. 처음엔 코드 자체를 의심해서 수정을 반복했는데 낫지 않았습니다. 그때 멘토님이 '로그 먼저 봐라'고 하셔서 서버 로그를 열었더니 환경 변수 하나가 누락된 게 보였습니다. 코드가 아닌 설정 문제였고, 10분 만에 해결됐습니다.
그 이후로 저는 문제가 생기면 코드보다 로그를 먼저 확인하는 습관이 생겼습니다. 코드와 환경과 데이터 중 어느 레이어인지를 로그가 바로 알려주기 때문입니다. 기술적 문제 분석에서 '내가 틀렸을 것이다'보다 '증거를 먼저 보자'가 더 효율적인 접근이라고 생각합니다.
로그를 읽는 습관 하나가 디버깅 시간을 크게 줄여준다는 걸 직접 배웠습니다. 경험을 통해 배웠습니다. 앞으로도 이 방향으로 성장하겠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.