이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
시안을 받으면 저는 바로 안 짜고, 먼저 무엇이 안 그려져 있는지부터 봅니다. 시안은 보통 잘 된 경우의 화면 한 장인데, 실제로는 데이터가 없을 때, 에러 났을 때, 너무 많을 때, 로딩 중일 때가 다 화면이 됩니다. 그래서 제 첫 작업은 이 화면이 가질 수 있는 상태를 모두 적어 보는 것입니다. 학부 프로젝트에서 시안대로만 만들었다가, 데이터가 없을 때 빈 화면이 깨져 보인 경험이 있어 이 순서를 세웠습니다. 그 뒤로는 상태 목록을 먼저 만들어 빠진 화면을 기획·디자인에 일찍 묻고, 그다음에 구현에 들어갑니다. 이렇게 하는 이유는 없는 상태를 나중에 발견하면 구조를 다시 짜야 하지만, 처음에 알면 한 번에 설계되기 때문입니다. 순서를 한마디로 하면 상태 정의 → 빠진 것 확인 → 그다음 구현입니다.
저는 시안을 받으면 왜 이렇게 그렸는지부터 확인합니다. 시안은 결과물이라 의도가 안 적혀 있고, 그대로 픽셀만 맞추면 의도와 다른 동작을 만들기 쉽습니다. 한 프로젝트에서 목록을 시안 그대로 구현했는데, 디자인은 항목이 적을 때를 가정한 거라 항목이 많아지자 화면이 무너진 경험이 있습니다. 시안만 보고 그 가정을 안 물은 게 문제였습니다. 그 뒤로 제 첫 순서는 이 화면이 어떤 데이터·조건을 가정하는지 디자인에 확인하는 것입니다. 그다음 그 가정이 깨지는 경우의 화면을 같이 정하고, 마지막에 구현에 들어갑니다. 이 순서의 이유는 가정은 구현 전에 맞춰야 싸고, 구현 후엔 다시 만드는 비용이기 때문입니다. 그래서 저는 시안을 그릴 대상이 아니라, 숨은 가정을 캐내야 할 자료로 봅니다.
솔직히 시안을 그대로 받아 만들다 막판에 갈아엎은 경험에서 순서를 배웠습니다. 디자인이 멋졌는데, 그 효과를 그대로 구현하면 성능이 크게 나빠지는 자리가 있었습니다. 그걸 다 만든 뒤에야 발견해, 디자인을 늦게 수정하느라 모두 고생했습니다. 그때 구현 난이도·비용은 시안 단계에서 미리 드러내야 한다는 걸 알았습니다. 그 뒤 제 순서는 이렇습니다. 먼저 시안에서 구현이 비싸거나 위험해 보이는 지점을 짚어 디자인과 일찍 공유합니다. 그다음 상태·예외를 정의하고, 마지막에 구현합니다. 이 순서의 이유는 비싼 부분을 늦게 알면 디자인과 코드를 둘 다 다시 손봐야 하기 때문입니다. 그래서 저는 구현 전에 이 시안에서 무엇이 비싼가를 먼저 말하는 사람이 되려 합니다. 지금도 시안 검토 첫 단계는 위험 지점 공유입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스인슈어런스 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.