이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 가장 중요하게 두는 원칙은 불확실한 데이터는 들어오는 경계에서 한 번에 타입을 좁힌다입니다. 서버 응답이나 외부 입력을 any에 가깝게 흘려보내면, 타입이 있어도 사실상 없는 것과 같아 사고가 멀리서 터집니다. 한 프로젝트에서 서버가 가끔 빈 값을 주는 걸 화면 깊은 곳까지 안 좁힌 채 흘려보냈다가, 엉뚱한 컴포넌트에서 터져 원인 찾는 데 한참 걸린 경험이 있습니다. 그 뒤로 경계에서 응답을 검사해 좁은 타입으로 바꾼 뒤에야 안으로 보냅니다. 그러면 문제가 경계에서 일찍, 한 곳에서 잡힙니다. 이게 안정성으로 가는 이유는 틀린 데이터가 멀리 못 가게 막아 디버깅 거리를 줄이기 때문입니다. 다만 이 원칙은 경계마다 검사 코드를 짜는 비용이 있어, 자주 안 바뀌는 내부 데이터까지 다 적용하진 않습니다. 핵심은 불확실이 들어오는 입구에만 무겁게 두는 것입니다.
제 원칙은 같은 상태를 여러 곳에서 바꾸지 않는다입니다. React에서 버그가 가장 잦았던 건 같은 값을 여기저기서 직접 바꿔, 화면이 상황마다 다르게 나오던 것이었습니다. 타입이 맞아도 언제 누가 바꿨는지 추적이 안 돼 안정성이 깨졌습니다. 한 프로젝트에서 그 추적 불가 버그를 며칠 못 잡은 경험이 있어, 그 뒤로 상태 변경은 정해진 한 통로로만 하고 화면은 결과만 받게 했습니다. 그러면 틀어졌을 때 그 통로만 보면 됩니다. 이게 안정성으로 가는 이유는 변경 출처가 하나라 원인 추적이 짧아지기 때문입니다. 다만 모든 상태에 이걸 강요하면 작은 UI 상태까지 통로를 거쳐 코드가 늘어나는 비용이 있어, 여러 곳이 공유하는 상태에만 적용합니다. 핵심은 공유 상태의 변경 출처를 하나로 모으는 것입니다.
제 원칙은 실패와 빈 상태를 정상 흐름과 똑같이 먼저 설계한다입니다. 안정적인 서비스가 깨지는 건 보통 잘 될 때가 아니라, 에러·빈 데이터·로딩 같은 안 그려진 경우입니다. 한 프로젝트에서 성공 경로만 타입과 화면을 잡고 실패는 나중에 처리하려다, 에러 응답에서 화면이 통째로 깨진 경험이 있습니다. 그 뒤로 저는 데이터 타입을 정의할 때 성공만이 아니라 실패·없음까지 같은 급으로 적고, 화면도 그 상태들을 처음부터 같이 설계합니다. 이게 안정성으로 가는 이유는 예외가 사후 땜질이 아니라 처음부터 타입과 화면에 박혀, 빠뜨릴 수가 없기 때문입니다. 다만 이 원칙은 단순한 화면에도 상태를 다 정의하느라 초기 작업이 느려지는 비용이 있어, 틀어졌을 때 영향이 큰 화면부터 적용합니다. 핵심은 실패를 나중이 아니라 처음에 일급으로 두는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.