면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
교내 프로젝트에서 소규모 결제 연동 기능을 설계할 때, 저는 정상 결제 흐름보다 실패 흐름을 먼저 정의했습니다. 결제 실패·중복 요청·타임아웃 세 가지 케이스를 먼저 표로 정리한 뒤 정상 흐름을 붙였습니다.
이렇게 접근하니 정상 흐름 설계도 더 단순해졌습니다. 예외를 나중에 끼워 넣으려 하면 구조가 복잡해지지만, 먼저 고려하면 자연스럽게 자리 잡습니다.
코어 시스템일수록 예외 케이스가 설계의 뼈대가 된다고 생각합니다.
인턴 기간 중 사내 CX 플랫폼 개선안을 검토하며, 저는 고객센터 응대 시간 단축이라는 비즈니스 목표를 먼저 확인했습니다. 그 다음 이를 달성하기 위한 기술 요건을 역으로 도출했습니다.
기술적으로 가능한 기능을 나열하기보다, 목표에 실제로 기여하는 기능부터 우선순위를 정했습니다. 그 결과 초기 범위를 3개 기능에서 1개로 좁혀 먼저 검증하자는 제안을 드렸습니다.
설계는 기술이 아니라 목표에서 시작해야 한다고 생각합니다.
팀 프로젝트로 SCM 재고 관리 도구를 만들 때, 처음엔 창고 하나만 지원하는 요구사항이었습니다. 하지만 저는 다중 창고 확장 가능성을 염두에 두고 데이터 구조를 미리 분리했습니다.
실제로 프로젝트 후반부에 다중 창고 요구가 추가됐는데, 구조를 다시 짜지 않고 필드만 확장해 대응할 수 있었습니다.
당장 필요 없어 보이는 확장 가능성도 초기 설계 단계에서 값싸게 반영할 수 있다면 반영해 두는 편입니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.