이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 10년 된 XML 기반 내부 시스템과 새로 만든 REST API를 연동하는 작업을 맡았습니다. 처음에는 단순한 포맷 변환이라고 생각했지만, 레거시 쪽에서 XML 네임스페이스를 일관성 없이 사용하고 있어서 파서가 절반의 메시지에서 실패했습니다.
원인은 구버전 시스템이 XML 표준을 완전히 따르지 않은 데 있었습니다. 표준 XML 파서 대신 정규식으로 필요한 필드만 추출하는 방식으로 임시 해결했지만, 유지보수가 어렵다는 것을 알면서도 더 빠른 방법이 없었습니다.
결국 3주 뒤 레거시 팀과 협의하여 신규 출력 포맷을 표준 XML로 고치는 작업을 같이 진행했습니다. 레거시 연동은 상대 시스템을 바꾸는 협의 비용이 기술 구현보다 더 오래 걸린다는 것을 이때 처음 실감했습니다.
인턴 때 20년 된 기간계 시스템의 DB에서 특정 데이터를 뽑아 신규 서비스에 넘기는 작업을 도왔어요. 테이블이 200개가 넘는데 ER 다이어그램도 컬럼 설명도 없었습니다.
처음엔 막막했는데, 담당자 할아버지뻘 되시는 분이 10년 전 코드를 같이 뒤져주셨어요. 컬럼명이 C001, C002 같은 식이라 실제 데이터를 보면서 의미를 역추론해야 했습니다.
2주 만에 주요 10개 테이블의 역공학 문서를 만들었고, 이걸 기반으로 인터페이스를 완성했어요. 이 경험에서 레거시 연동은 기술 문제보다 지식 소실 문제라는 걸 배웠습니다. 그 분이 퇴사하시기 전에 문서를 남긴 게 얼마나 다행인지 나중에야 실감했어요.
레거시 시스템 간 인터페이스 개발을 전문적으로 해본 경험은 없지만, 팀 프로젝트에서 두 서비스가 서로 다른 날짜 포맷을 쓰면서 데이터가 깨지는 문제를 해결한 적이 있어요.
A 서비스는 YYYY-MM-DD, B 서비스는 DD/MM/YYYY를 쓰는데 중간 변환 레이어 없이 바로 연결했던 게 문제였어요. 월이 12 이하면 날짜와 구분이 안 돼서 8월 데이터가 랜덤하게 틀리게 들어왔습니다.
중간에 포맷 정규화 레이어를 추가해서 해결했어요. 작은 문제처럼 보이지만, 레거시 연동에선 이런 암묵적인 규약의 불일치가 많다는 걸 배웠습니다. 두 시스템 모두 각자 기준에서는 맞게 동작하니 어느 쪽 로그를 봐도 이상이 없어 보이는 게 더 찾기 어려웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.