SI(시스템 통합)에 대한 이해가 있는지, IT 직무에 입문하기 위한 기초 개념 파악 여부를 확인합니다.
이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
SI를 처음 들은 건 전산 수업이 아니라 프로젝트 발표를 들으면서였습니다. 고객사가 여러 시스템을 쓰고 있는데 이걸 하나로 묶는 작업을 한다는 설명이었는데, 처음엔 그게 왜 어려운지 몰랐습니다. 직접 겪어본 건 인턴 때였는데, 구매 시스템과 재고 시스템의 코드 방식이 달라서 두 DB가 같은 항목을 다른 키값으로 저장하고 있었습니다. 그 불일치를 맞추는 매핑 작업이 SI의 현실이라는 걸 그때 알았습니다. SI는 단순히 시스템을 연결하는 게 아니라 서로 다른 기준과 언어로 만들어진 것을 하나의 흐름으로 만드는 일이라고 이해하고 있습니다. 기술보다 표준 정의와 이해관계 조율이 더 어렵다는 말을 들었는데, 그 의미를 짧은 경험에서도 조금은 알 수 있었습니다.
SI 프로젝트에서 기술적 어려움만큼 이해관계 조율이 어렵다고 들었습니다. 여러 시스템을 하나로 연결하는 작업에서 각 시스템의 소유자가 다르고 기술 스택도 제각각인 경우가 많아서, 기술 문제보다 조직 간 합의가 더 오래 걸리는 경우가 있습니다. 인터페이스 명세처럼 시스템 간에 어떤 방식으로 데이터를 주고받을지를 먼저 문서화해야 하는데, 이 합의 과정이 의외로 시간이 걸립니다.
레거시 시스템이 포함된 경우에는 문서가 없거나 맞지 않는 경우가 많아서 역추적이 필요하기도 합니다. SI는 기술력만큼 커뮤니케이션과 문서화 능력이 중요한 분야라는 걸 케이스를 통해 이해했습니다. 시스템을 연결하는 것보다 시스템 뒤에 있는 사람들을 연결하는 것이 더 어려운 일이라는 생각이 들었습니다.
SI에서 기술은 전제이고, 조율이 본질이라는 관점이 생겼습니다. 인터페이스 명세 합의가 통합 작업의 시작점입니다.
SI와 일반 소프트웨어 개발의 차이를 고객 요구사항을 어디서 출발하느냐에서 이해했습니다. 패키지 소프트웨어나 서비스 개발은 불특정 다수를 위한 제품을 만들지만, SI는 특정 고객의 기존 환경에 맞는 시스템을 구축하는 작업입니다. 그래서 요구사항 분석과 현행 시스템 파악이 개발보다 먼저 오고, 그 과정이 전체 프로젝트 성패를 결정하는 경우가 많습니다.
처음 요구사항 정의가 충분하지 않으면 나중에 범위가 계속 늘어나는 문제가 SI에서 자주 생기는 패턴이라고 들었습니다. 고객의 숨겨진 요구사항을 찾아내는 것도 SI 경험의 중요한 부분이라는 걸 배웠습니다. SI를 통해 기술을 배우는 것만큼 요구사항을 이해하고 설계하는 능력을 기를 수 있다는 것도 알게 됐습니다.
SI는 기술과 업무 이해를 동시에 요구하는 분야라고 생각합니다. 현행 시스템 파악이 SI 프로젝트의 첫 번째 과제입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ시스템즈 엔지니어링 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.