이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제가 흥미롭게 보는 건 값이 없을 때를 다루는 문법을 더 단순하게 하려는 흐름입니다. 특정 제안 이름보다, 그게 푸는 문제가 제 경험과 닿아서입니다. 학부 프로젝트에서 서버 응답에서 값이 없을 때마다 길고 반복적인 방어 코드를 쓰다, 그게 핵심 로직을 가려 읽기 어려웠던 경험이 있습니다. 그 부류 불편을 언어 차원에서 짧게 표현하게 해 주는 방향이라 눈여겨봅니다. 단순히 새로워서가 아니라, 반복 방어 코드가 의미를 가리던 자리를 줄여 주기 때문입니다. 다만 균형 있게 봅니다.
제안은 단계가 있어 확정 전엔 바뀔 수 있고, 너무 일찍 쓰면 나중에 문법이 달라져 다시 손봐야 하는 비용이 있습니다. 그래서 저는 방향은 따라가되, 실제 도입은 안정된 뒤에 하는 편입니다. 언어 변화는 흥미롭게 보되 내 코드에 들이는 시점은 따로 판단합니다.
제가 보는 건 타입을 더 코드 가까이서 안전하게 다루려는 흐름입니다. TypeScript를 쓰며 경계에서 타입이 사실상 풀려, 타입이 있는데도 런타임에서 엉뚱하게 터진 경험이 있어 이 방향이 와닿습니다. 그 부류 제안은 불확실한 데이터를 들어오는 자리에서 한 번에 좁히도록 도와, 제가 데여 본 그 사고를 줄여 줍니다. 새 문법이라 끌리는 게 아니라, 경계에서 타입이 무력해지던 자리를 메우기 때문입니다. 다만 균형도 봅니다.
제안이 표준이 되기 전엔 도구 지원이 들쭉날쭉하고, 무리해서 쓰면 팀 환경마다 안 돌아 오히려 비용이 됩니다. 그래서 저는 그 방향을 학습으로 따라가되, 팀 도구가 안정적으로 받을 때 도입합니다. 언어 변화는 흥미와 도입을 분리해서 봅니다.
솔직히 새 스펙에 끌려 일찍 도입했다가 데인 경험에서 보는 법을 배웠습니다. 흥미로워 보이는 제안을 확정 전인데 실제 코드에 넣었다가, 문법이 바뀌어 다시 다 손본 적이 있습니다. 그때 언어 제안은 흥미롭게 지켜보는 것과, 내 코드에 들이는 것은 다른 결정임을 알았습니다. 지금 제가 흥미롭게 보는 흐름은 반복되는 방어·변환 코드를 언어가 줄여 주려는 방향입니다. 제가 그런 코드에 시간을 많이 써 본 터라 와닿습니다. 다만 그게 좋아 보여도, 제안 단계와 도구 지원을 확인하기 전엔 학습만 하고 도입은 미룹니다. 흥미는 방향을 따라가는 데, 도입은 안정성에 답니다. 그래서 저는 새 스펙을 방향 학습용과 실사용을 나눠 보고, 지금도 그 둘을 섞지 않습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스페이먼츠 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.