이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 프론트엔드에 더 자신 있습니다. 사용자가 막히는 자리를 화면에서 직접 고쳐 본 경험이 쌓여서입니다. 다만 풀스택으로 가려면 약점이 분명합니다. 서버가 데이터를 어떻게 저장하고 왜 느려지는지를 깊게 모릅니다. 학부 프로젝트에서 화면이 느려 프론트만 한참 고쳤는데, 진짜 원인이 서버 쪽 비효율 조회였던 경험이 있습니다. 그때 프론트만 보면 못 푸는 문제가 있다는 걸 몸으로 알았습니다. 그래서 보완점은 막연한 백엔드가 아니라 데이터가 어떻게 저장·조회되고 어디서 느려지는지로 좁힙니다. 메우는 방법도 다짐이 아니라, 내가 만든 화면이 부르는 그 요청을 따라 들어가 서버가 무엇을 하는지 직접 보는 것부터 합니다. 풀스택은 한 번에 다 잘하는 게 아니라, 경계에서 막힌 문제를 한 단계씩 따라가 메우는 것이라고 봅니다.
저는 백엔드 쪽에 더 자신 있습니다. 데이터가 들어와 저장되기까지를 직접 다뤄 본 경험이 많아서입니다. 다만 풀스택으로 가려면, 사용자가 실제로 그걸 어떻게 쓰는지를 화면에서 보는 감각이 약합니다. 학부 때 기능은 잘 동작하게 만들었는데, 정작 사용자가 그 흐름을 헷갈려 거의 안 쓴 경험이 있습니다. 그때 서버에서 맞다고 화면에서도 맞는 건 아니라는 걸 알았습니다. 그래서 제 보완점은 추상적인 프론트가 아니라 사용자가 한 작업을 끝내기까지의 흐름을 화면 기준으로 보는 것으로 좁힙니다. 메우는 방법은, 내가 만든 API를 실제로 쓰는 화면을 직접 붙여 보고, 어디서 사용자가 멈추는지 관찰하는 것부터 합니다. 풀스택은 양쪽을 다 안다기보다, 내가 약한 쪽의 시선을 빌려 내 강한 쪽을 점검하는 것이라고 봅니다.
솔직히 둘 다 잘하려다 어느 쪽도 깊지 않게 됐던 경험에서 보는 법을 배웠습니다. 풀스택이 좋다길래 프론트·백엔드를 동시에 넓게 건드렸는데, 결과는 둘 다 얕아 정작 문제를 깊게 못 푼 것이었습니다. 그때 풀스택은 둘을 동시에 넓히는 게 아니라, 한쪽을 깊게 한 뒤 그 깊이로 다른 쪽을 이해하는 것임을 알았습니다. 지금 저는 프론트가 더 자신 있고, 그 깊이 덕에 서버가 화면에 무엇을 줘야 하는지는 잘 압니다. 약한 건 그 데이터가 서버 안에서 어떻게 만들어지는지입니다. 그래서 보완은 넓게 다 가 아니라, 내가 잘 아는 화면의 요구에서 출발해 그 데이터의 출처를 한 단계씩 따라가는 것입니다. 한 번에 풀스택이 아니라, 깊은 한쪽을 다리 삼아 다른 쪽으로 건너가는 순서로 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.