[Java&Spring 면접 준비] Day 6 - 프로젝트 관련

1. OMS 시스템 개발 시 프론트엔드와 백엔드 중 더 어려웠던 점은 무엇이었나요? 어떻게 해결했나요?

저는 입사하고 React를 처음 접하고 공부하면서 개발했기때문에 프론트엔드가 더 어려웠습니다. 특히 컴포넌트가 불필요하게 리렌더링되면서 데이터 저장이 제대로 되지 않는 문제였습니다.

예를 들어, 주문 수정 화면에서 편집 후 저장하면, 상위 컴포넌트의 state 변경으로 리렌더링되면서 편집 중이던 데이터가 초기화되는 이슈가 있었습니다.

이를 해결하기 위해 React.memo와 useCallback을 적용했습니다.

• React.memo를 통해 props가 실제로 변경된 컴포넌트만 리렌더링하도록 막았고,
• 이벤트 핸들러 함수는 useCallback으로 메모이제이션해 매번 새로운 함수 참조로 인한 리렌더링을 방지했습니다.

결과적으로 편집 중 데이터가 사라지는 문제가 해결할 수 있었습니다.

2. 신규 이커머스 연동 과정에서 API 연동 시 발생했던 대표적인 이슈와 해결 방법은?

대표적인 이슈는 API 스펙 불일치와 예외 데이터 처리였습니다.

일부 이커머스 플랫폼은 상태 코드나 응답 필드가 다르게 내려왔습니다.
예를 들어, 이커머스 플랫폼마다 주문 상태 코드가 달라 “결제 완료” 상태가 불일치했습니다.
저는 StatusMapper라는 매핑 계층을 만들어 외부 상태 값을 내부 표준 상태 값으로 변환해 처리했습니다.

또, 일부 플랫폼에서 필수값(예: 수취인 연락처)이 누락된 주문 데이터가 내려오는 문제가 있었습니다.
우선적으로 주문자 연락처를 수취인 연락처로 대체 저장하도록 처리했습니다.
이렇게 하면 데이터 유실 없이 정상 주문 프로세스를 이어갈 수 있고, 운영자는 이후 로그나 에러 큐 알림을 통해 해당 주문을 확인해 실제 수취인 연락처를 보정할 수 있었습니다.

즉, 시스템은 멈추지 않고 안정적으로 처리하되, 운영 단계에서 추후 정정할 수 있는 구조로 설계했습니다.
이런 방식으로 API 연동의 안정성을 확보할 수 있었습니다.

3. 대용량 엑셀 다운로드 기능 구현 시, 비동기 처리와 스트리밍 처리를 함께 적용한 이유는 무엇인가요?

두 가지 이유가 있었습니다.

1. 비동기 처리는 사용자가 다운로드 요청 후 브라우저가 멈추지 않고, 작업이 완료되면 알림을 받을 수 있도록 하기 위함이었습니다.
2. 스트리밍 처리는 10만 건 이상 데이터를 한 번에 메모리에 올리면 OOM이 발생했기 때문에, 데이터를 청크 단위로 끊어서 처리하기 위함이었습니다.

즉, 비동기로 사용자 경험을 개선하고, 스트리밍으로 시스템 안정성을 확보한 것이 핵심입니다.

꼬리질문:

→ 17만 건 처리 시 메모리 사용량을 70%로 안정화했다고 했는데, 메모리 최적화 과정에서 고려한 다른 방법은 있었나요?

네, 여러 가지 방법을 검토했습니다. 예를 들어,

• 쿼리 최적화: 필요한 컬럼만 select 하도록 projection을 최소화했습니다.
• 파일 분할 다운로드: 65,000행 단위로 xlsx 파일을 분할하고, 여러 개일 경우 zip으로 묶어 제공했습니다.
• Heap 증설보다는 코드 최적화: 단순히 서버 메모리를 늘리는 대신, BlockingQueue와 생산자-소비자 패턴을 적용해 메모리 사용량을 제어했습니다. 결과적으로 시스템 자원 증설보다 구조적인 최적화를 택해 안정성을 확보했습니다.

4. WMS와 연동된 주문 등록 기능 개발에서 시스템 간 연동 시 고려한 주요 포인트는 무엇이었나요?

가장 중요하게 본 건 두 가지입니다.

• 데이터 정합성: 주문이 OMS에서 WMS로 전달된 후, 정상적으로 등록/처리되었는지 이중 확인 로직을 넣었습니다.
  • 1차로 API 응답 코드를 확인하고, 2차로는 WMS DB나 조회 API를 호출해 실제 주문이 정상적으로 생성되었는지 검증했습니다.
    만약 응답은 성공이지만 DB에 데이터가 반영되지 않은 경우, 재시도 프로세스나 알림을 통해 운영자가 확인할 수 있도록 했습니다.
    덕분에 데이터 정합성을 보장하고, 주문 유실 가능성을 최소화했습니다.
• 성능: OMS에서 대량 주문을 일정 건수로 분할해 멀티스레드로 병렬 처리하도록 설계했습니다. 특정 청크가 실패하면 해당 부분만 재처리할 수 있어 운영 안정성도 높일 수 있었습니다.
  • 사실 당시에는 메시지 큐 도입을 검토했지만, WMS가 실시간 API 호출 기반으로만 동작하는 구조때문에 적용이 어려웠습니다.
    대신 대량 주문 배치 트래픽이 몰리는 경우를 대비해 청크 단위 비동기 처리 방식을 도입했습니다. 예를 들어, 주문 데이터를 일정 건수(1000건)로 나누고, 각 청크를 별도의 스레드에서 병렬 처리하도록 구현했습니다.
    또한 청크 단위 상태를 관리해서 실패한 청크만 재처리할 수 있도록 했습니다.
    덕분에 단일 쓰레드 순차 처리 대비 처리 속도가 크게 개선됐고, 전체 배치가 중단되지 않고 안정적으로 마무리될 수 있었습니다.

5. 풀스택 개발 경험을 바탕으로, 물류시스템 운영/개발 업무에서 어떻게 기여할 수 있을지 구체적으로 말해보세요.

저는 프론트엔드와 백엔드 모두 경험했기 때문에, 단일 영역이 아닌 엔드투엔드 관점에서 문제를 해결할 수 있는 점이 강점입니다. 예를 들어, 물류시스템에서 주문 조회 속도가 느리다면, API 쿼리 튜닝부터 화면 최적화까지 전 과정에서 개선안을 제시할 수 있습니다.

또한 이커머스 API 연동 경험을 통해 외부 시스템과 안정적으로 연계하는 방법을 알고 있고, 대용량 엑셀 처리 경험을 통해 대규모 데이터 처리 및 성능 최적화 역량도 갖추었습니다.

단순 운영을 넘어 시스템 성능과 사용자 경험을 동시에 개선하는 개발자로 기여하고 싶습니다.