타입스크립트 도메인 모델링

Q7-1-a. utils와 types를 한 파일에 둔 게 좀 어색한데요? passenger.ts에 totalPassengers 함수가 들어가 있어요. → 의식적으로 그 결정을 했습니다. totalPassengers나 formatPassengerCount는 PassengerCount 데이터 위에서만 의미 있는 함수예요. 도메인 entity와 함께 두면 entity가 자신을 다루는 함수까지 캡슐화하는 모양이 되어, 사용처에서 import { PassengerCount, totalPassengers, formatPassengerCount } from 'types/passenger' 한 줄로 다 가져올 수 있습니다. utils로 빼면 같은 도메인이 두 폴더로 흩어지는 비용이 더 큽니다. 다만 date.ts처럼 특정 도메인에 묶이지 않는 일반 유틸은 utils에 두는 식으로 구분했어요.

Q7-1-b. Station은 그냥 { id, name } 두 필드뿐인데 굳이 따로 인터페이스로 둘 필요가 있나요? → 두 필드뿐이라도 따로 두는 게 맞다고 봤습니다. 첫째, 도메인 entity의 이름이 코드 곳곳에 등장하면 의도가 분명해져요 — Station[] vs Array<{ id: number; name: string }>. 둘째, 미래에 Station이 더 많은 필드를 가지게 됐을 때 — 영문명, 코드, 좌표 등 — 한 군데만 고치면 모든 사용처가 자동 반영됩니다. Naming things가 cache invalidation만큼 어렵다는 격언이 있을 정도로 이름의 가치가 큰데, 도메인 entity는 그 이름의 가장 단단한 닻이에요.

Q7-1-c. enum을 쓴 곳(PASSENGER_TYPE, TRIP_TYPE, STATION_TYPE)과 as const를 쓴 곳(TICKET_STATUS)이 섞여 있는데 이유가 있나요? → 처음 작성 시 일관성 측면에서는 한쪽으로 통일하는 게 더 좋았을 거 같아요. as const + (typeof X)[keyof typeof X] 패턴은 tree shaking과 컴파일 결과(런타임 객체가 따로 안 만들어짐) 측면에서 enum보다 가볍습니다. enum은 isolated modules·tree shaking에 약점이 있어서 최근 TypeScript 컨벤션은 as const 쪽을 권장하는 흐름이에요. 이번 과제에서는 enum과 as const가 혼재한 건 사실인데, 둘 다 만들 때의 결정이 일관되지 못했던 부분이라 인터뷰에서 솔직하게 인정하고 "통일한다면 as const 쪽으로" 답변할 생각입니다.

Q7-2-a. Get/Post 두 종류뿐인데, Put/Delete/Patch는 어떻게 처리하실 건가요? → 같은 컨벤션을 그대로 따라가면 됩니다. PutXxxApiBody, DeleteXxxApiParams 같은 식으로요. PATCH는 부분 업데이트라 PatchXxxApiBody도 자연스럽고요. 컨벤션이 method 이름을 prefix로 하니까 새로운 method가 추가돼도 일관성이 유지됩니다.

Q7-2-b. GetStationApiResponse = Station[]처럼 단순 alias라면 굳이 새 타입을 만들 필요 있나요? → 약간의 over-engineering 같지만 두 가지 이유로 정당화한다고 생각해요. 첫째, 미래에 응답이 wrapper 객체로 바뀔 때 alias만 수정하면 모든 사용처가 자동 반영. 둘째, query 파일 안에서 GetStationApiResponse라는 이름이 보이는 게 "이 query의 응답"이라는 의도를 명시합니다. 그냥 Station[]만 보면 "이게 검색 응답인지, 다른 데서 가져온 list인지"가 한 단계 추론이 필요해요.

Q7-2-c. 지금 컨벤션의 한계나 실수할 수 있는 부분은요? → entity name이 단수/복수가 섞일 수 있는 게 한 가지 위험입니다. GetStationApiResponse = Station[](단수 + array)인데 GetTicketsApiResponse = Ticket[]처럼 entity를 복수로 갖다 쓰는 사람이 있을 수 있어요. 컨벤션을 "단수 entity + 응답이 array면 array로"로 정해서 일관성을 유지했는데, lint rule이나 codegen으로 자동화하면 더 안전합니다. 또 query factory와 결합하면 zod schema와 묶어서 런타임 validation까지 가는 길이 있어요.

Q7-3-a. PostReservationApiBody도 같은 패턴인데, 응답(Reservation)과 요청(PostReservationApiBody)에서 ticket 필드 모양이 다르네요. 왜 다른가요? → 요청은 ticket의 ID만 보내면 충분해요(서버가 ID로 ticket 정보를 채움). 그래서 PostReservationApiBodyOneWay는 ticketId: number, Round는 outboundTicketId: number, inboundTicketId: number. 응답은 사용자에게 보여줄 ticket 정보가 필요하니까 ReservationTicket = Pick<Ticket, ...>로 부분 객체. 같은 도메인 흐름의 두 끝(요청/응답)이 다른 데이터 모양을 갖는 게 자연스럽고, discriminated union은 두 끝 모두에서 동일한 패턴으로 적용 가능합니다.

Q7-3-b. exhaustive check는 어떻게 하시나요? switch에서 새 type이 추가됐을 때 컴파일 에러가 나도록. → switch (reservation.type) 패턴에서 default: const _exhaustive: never = reservation; throw new Error(...) 방식으로 했어요. 새 type(예를 들어 MULTI_LEG)이 추가되면 _exhaustive: never 할당이 컴파일 에러를 내서 switch가 모든 케이스를 다루는지를 강제합니다. 이번 과제에서는 분기가 두 곳뿐이라 명시적으로 안 박았는데, 더 큰 코드베이스라면 utility로 assertNever(value: never): never 함수를 두는 게 표준이에요.

Q7-3-c. discriminated union 대신 클래스 + 다형성으로 풀 수도 있을 텐데요? → 가능합니다. class OneWayReservation, class RoundReservation이 같은 인터페이스의 getTotalPrice() 같은 메서드를 구현하는 식. 다만 React에서는 데이터를 plain object로 다루는 게 일반적이라 — JSON 응답이 그대로 들어오고, jotai atom이나 react-query 캐시가 plain object를 가정 — 클래스를 쓰면 직렬화/역직렬화 layer가 추가로 필요해집니다. 함수형 React 환경에서는 discriminated union이 더 자연스럽다고 봤어요.

Q7-4-a. INITIAL_PASSENGER_COUNT가 PassengerCount 타입이 아니라 const라 type assertion 같은 게 보이는데요? → 코드 보면 export const INITIAL_PASSENGER_COUNT: PassengerCount = { [PASSENGER_TYPE.ADULTS]: 1, [PASSENGER_TYPE.CHILDREN]: 0, [PASSENGER_TYPE.NEWBORN]: 0 }; 형태로 type annotation을 명시했어요. as const로 narrow하게 가는 것보다 PassengerCount 그대로 두는 게 atom의 default value로 쓰기 좋습니다(atom 타입이 PassengerCount라 자동 호환). 어른 default를 1로 둔 건 가장 자주 쓰이는 케이스(어른 1명)를 미리 채워둬서 한 번의 클릭을 줄이는 UX 결정이에요.

Q7-4-b. formatPassengerCount에서 count.adults처럼 직접 접근하던데, enum을 통해 접근하지 않은 이유가 있나요? → 의식적으로 그렇게 했어요. count[PASSENGER_TYPE.ADULTS]도 가능하지만, 이미 PassengerCount 타입 안에서는 key가 좁혀진 상태라 직접 접근이 더 가독성이 좋다고 봤습니다. enum의 가치는 "외부에서 식별자로 전달할 때"에 있고, 데이터 내부 접근에서는 count.adults가 자연스러워요. 다만 일관성 측면에서는 둘 중 하나로 통일하는 게 좋긴 합니다.

Q7-4-c. MAX_PASSENGER_TOTAL = 9 같은 상수도 type 파일에 있던데, 비즈니스 룰을 type 파일에 두는 게 맞나요? → 도메인 단위 모듈화 원칙을 따른 건데, 인터뷰어가 짚을 만한 부분이에요. PassengerCount 도메인의 invariant("합계 ≤ 9")가 같은 파일에 있으면 도메인 자체를 한 군데서 다 보는 이점이 있습니다. 다만 비즈니스 룰이 늘어나면 passengerRules.ts로 분리하는 게 맞을 거예요. Rule of Three — 한두 개는 entity 파일에, 셋 이상이면 분리. 지금은 한 개라 같이 뒀습니다.

Q7-5-a. 만약 백엔드가 응답 필드명을 바꾸면 클라이언트 코드 전체를 수정해야 할 텐데요? → 그 위험은 있지만, 변환 layer를 둔다고 위험이 사라지지 않아요. 변환 layer 안에서 같은 변경을 처리해야 하는 건 똑같습니다. 차이는 변경의 노출 범위 — layer가 있으면 변경이 layer 안에 격리되고, 없으면 사용처 모두에 퍼집니다. 다만 격리의 비용이 평소의 추적 비용보다 클 때만 layer가 정당화돼요. 4개 API + 작은 프로젝트에서는 평소 비용이 더 큽니다.

Q7-5-b. zod 같은 런타임 검증을 도입했다면 자연스럽게 변환 layer도 같이 들어왔을 텐데요? → 맞아요. zod의 .transform()을 쓰면 검증과 변환을 한 번에 할 수 있고, 응답이 예상과 다를 때 런타임 보호도 됩니다. 6시간 안에서 zod 도입이 ROI가 어느 정도일지 고민했는데 — schema 정의 + transform 작성 시간이 만만치 않고, 4개 API라 정의해야 할 schema가 적지 않아요. 그래서 README to-do에 "API 응답 zod 검증 도입" 후보로 남길 수는 있는데, 이번 과제에서는 우선순위에서 뺐습니다.

Q7-5-c. 응답 필드명을 그대로 가져가다 보니 outboundTicket/inboundTicket 같은 긴 이름이 코드에 자주 등장하는데 가독성이 어땠나요? → 길긴 한데, 의미가 분명해서 짧게 줄이는 것보다 가독성이 좋다고 봤어요. out/in으로 줄이면 의미가 모호해지고, outbound/inbound는 이미 traffic·로직의 표준 용어라 줄이면 오히려 컨벤션에서 벗어납니다. 길이는 IDE 자동완성으로 보완되니 큰 비용이 아니에요.