이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
EAI 연계 경험에서 가장 먼저 파악한 것은 각 시스템의 데이터 포맷과 인터페이스 방식이었습니다. 한쪽은 XML, 다른 쪽은 JSON을 사용하는 경우 EAI 미들웨어의 변환 로직을 구성해야 했고, 매핑 규칙을 잘못 정의하면 데이터 손실이 생겼습니다.
SAP 연계에서는 RFC(Remote Function Call) 방식으로 기능을 호출하는 구조를 많이 사용했습니다. SAP 쪽에서 노출한 기능 모듈을 외부 시스템이 직접 호출하는 방식이었는데, 인자 타입과 예외 처리 방식이 일반 REST API와 달라 처음에 적응 시간이 필요했습니다.
연계 안정성 확보를 위해 재시도 정책과 오류 알림을 구성했습니다. 연계가 실패했을 때 원인을 빠르게 파악하고 재처리할 수 있도록 오류 로그와 큐 상태를 모니터링하는 대시보드를 함께 만들었습니다.
EAI 연계 업무에서 가장 어려웠던 것은 두 시스템 사이의 데이터가 불일치했을 때 어떻게 처리할지였습니다. 연계가 정상 작동하는 동안에는 문제가 없는데, 한쪽 시스템이 일시 중단됐다가 다시 연결됐을 때 그 사이에 생긴 변경 사항이 누락되는 경우가 있었습니다. 누락된 데이터를 확인하기 위해 양쪽 시스템의 처리 이력을 비교하는 방식을 사용했는데, 각 시스템의 타임스탬프 기준이 달라 어느 건이 실제로 처리됐는지 판단하는 것이 쉽지 않았습니다. 이후에는 연계 건마다 고유한 식별자를 부여해서 양쪽에서 수신 여부를 추적하는 구조를 추가했습니다. 연계 안정성은 정상 경로가 잘 작동하는 것뿐 아니라 일시 중단 후 재연결했을 때 누락 없이 복구되는 것까지 포함한다는 것을 이 경험에서 배웠습니다.
EAI 및 SAP 연계 작업에서 기술적인 부분만큼이나 인터페이스 명세를 명확히 하는 것이 중요하다는 것을 배웠습니다. 연계 대상 시스템 담당자와 필드명과 데이터 타입을 구두로 합의했는데, 나중에 실제 전송된 데이터를 보니 합의한 것과 다른 형태로 오는 필드가 있었습니다. 특히 날짜 형식이나 코드 값 매핑이 시스템마다 다르게 정의된 경우가 있어서, 변환 로직을 잘못 짜면 데이터가 틀린 형태로 저장됐습니다. 이후에는 인터페이스 명세를 문서로 작성하고 실제 샘플 데이터로 검증하는 단계를 연계 작업의 시작 점검 항목으로 추가했습니다. 연계 테스트도 정상 케이스만 확인하는 것이 아니라 누락 필드, 타입 오류, 코드 값 불일치 케이스를 의도적으로 만들어서 변환 로직이 처리하는지 확인하는 방식으로 바꿨습니다. EAI 연계에서 기술 구현보다 인터페이스 명세를 정확하게 합의하고 검증하는 과정이 더 많은 문제를 막는다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.