중국 소프트웨어 회사와 일하기 전에 확인할 7가지

볼 것은 진행 방식이 아니라 상대의 내용

오프쇼어 개발 실패 원인으로 자주 언급되는 것은 대부분 프로세스 문제입니다. 요구사항의 세밀도, 진도 공유, 검수 조건 — 이런 것들은 발주사가 자기 관리로 보완할 수 있습니다. 반면 관리로 메울 수 없는 격차도 있습니다. 상대가 공장 현장을 다뤄본 적이 있는지, 우리 언어로 문서를 낼 수 있는지, 납품 후에 연락이 닿는지. 이것들은 공급사 자체의 속성이며 계약 후에는 바뀌지 않습니다.

그래서 확인 작업은 두 층으로 나뉩니다. 위층은 프로젝트 관리, 아래층은 공급사 적격성입니다. 이 글이 다루는 것은 아래층 — 약정 전에 상대의 내용을 확인하는 7가지입니다. 7가지 모두에 서면으로 답할 수 있는 회사는 실제로 많지 않습니다. 뒤집어 말하면 이 목록은 후보를 좁히는 도구로 쓸 수 있습니다.

계약 전에 확인할 7가지

• ① 공장 현장 경험이 있는가 — IT 수탁 개발 실적이 아니라 PLC, 필드버스, 전기 제어를 다뤄온 경력을 확인합니다. 설비에서 데이터를 가져오는 작업은 웹 시스템 개발과는 다른 종류의 일입니다. 반도체·디스플레이 같은 라인에서 어느 제조사의 PLC를 어떤 프로토콜로 연결했는지 구체적으로 물으면 경험 유무는 바로 드러납니다.
• ② 소통과 문서를 어떤 언어로 하는가 — 회의에 통역이 붙는지가 아니라 사양서와 조작 설명서를 한국어로 납품할 수 있는지를 확인합니다. 현장 작업자가 읽지 못하는 문서는 가동 후에 쓰이지 않습니다. 프로젝트 전 기간 유지되는 한국어 또는 영어 대응 창구가 있는지, 그리고 두 개 이상의 언어로 엔지니어링 문서를 낸 경험이 있는지 확인하는 것이 확실합니다.
• ③ 납품 문서가 체계를 이루는가 — 설계서 한 부가 아니라 착수부터 유지보수까지의 문서 목록이 준비되어 있는지를 봅니다. 프로젝트 제안서, 기술 협약, 사양서, I/O 배분표, 주소 배분표, 네트워크 구성도, 화면 설계 설명서, 조작 설명서, 데이터베이스 테이블 설명서, 데이터 인터페이스 설명서, 시험 보고서, 검수 자료, 유지보수 목록, 연간 유지보수 보고서 — 이런 목록을 먼저 내놓을 수 있는지에서 차이가 갈립니다.
• ④ 정보 보안과 데이터를 어떻게 다루는가 — 접속 방식(VPN, 전용 회선), 접근 권한 관리, 조작 로그 보관, 소스 코드와 도면의 보관 위치, 데이터를 국내에 두는지 상대 측에도 두는지. 비밀유지계약 문구만이 아니라 일상 운영 절차로 설명할 수 있는지를 확인합니다.
• ⑤ 소규모 파일럿을 받을 수 있는가 — 처음부터 전체를 발주하지 않고 설비 1대나 라인 1개로 범위를 좁힌 파일럿을 맡을지 물어봅니다. 파일럿을 거절하거나 파일럿과 본 개발의 비용 구성을 설명하지 못하는 회사는 범위를 그어본 경험이 부족할 수 있습니다. 파일럿 산출물을 본 개발의 토대로 그대로 쓸 수 있는지도 함께 확인합니다.
• ⑥ 검수 기준을 기술 협약에 쓸 수 있는가 — '기능을 구현한다'가 아니라 데이터 지연 상한, 리포트 집계 정의, 통신 복구 후 데이터 누락 여부처럼 측정 가능한 조건을 계약 문서에 넣을 수 있는지 확인합니다. 그 자리에서 '쓸 수 있다'고 답하는 회사와 구두로만 보증하는 회사의 위치는 크게 다릅니다.
• ⑦ 납품 후 유지보수와 응답을 어떻게 약정하는가 — 문의 창구, 응답 시간, 연간 유지보수 작업 내용, 라인 변경 시 대응 방식, 보고서 제출 주기. 연간 유지보수 계약 표준안과 유지보수 보고서 양식을 이미 가지고 있는지 보면 지속 지원이 실제 관행인지 알 수 있습니다.

7가지 중 ① ② ③은 공급사의 속성이고 ④ ⑤ ⑥ ⑦은 계약에서 다듬을 수 있는 부분입니다. 속성 쪽이 충족되지 않으면 계약을 아무리 꼼꼼히 써도 현장으로 넘어오는 부담은 줄지 않습니다.

순수 IT 외주와 현장 배경이 있는 공급사의 차이

같은 '소프트웨어 개발 회사'라도 IT 수탁을 주업으로 해온 회사와 공장 현장에서 출발한 회사는 강한 공정이 다릅니다. 어느 쪽이 옳다는 이야기가 아니라 공장 시스템에서 공수가 어디에 쌓이는지 알아두기 위한 대조입니다.

위 표는 경향의 대조이며 개별 회사에 대한 평가가 아닙니다. 실제로는 두 성격을 겸비한 회사도 있습니다. 판단 근거는 회사의 분류가 아니라 ①부터 ⑦까지의 답변 내용입니다.

납품 문서는 '나중에 정한다'가 아니라 먼저 확정한다

공장 시스템에서 마찰이 생기는 시점은 보통 가동 후에 '이 문서가 없다'는 것을 알게 될 때입니다. 담당자 교체, 설비 갱신, 2단계 추가 개발 — 어느 상황에서든 손에 있는 문서의 범위가 곧 스스로 대응할 수 있는 범위가 됩니다. 문서는 납품물의 부속이 아니라 그 자체가 납품물입니다.

확인 방법은 단순합니다. 계약 전에 '납품할 문서 목록을 내주세요'라고 요청하면 됩니다. 목록이 나오지 않거나 '일반적인 것을 제공합니다'라는 답이 돌아오면 체계가 없을 가능성이 큽니다. 체계가 있는 회사는 아래와 같은 분류로 목록을 제시할 수 있습니다.

• 기획·계약: 프로젝트 제안서, 기술 협약, 사양서 — 범위와 검수 조건을 정하는 문서
• 설계: I/O 배분표, 주소 배분표, 네트워크 구성도, 화면 설계 설명서 — 어떤 신호가 어디서 오고 어떻게 표시되는지를 정하는 문서
• 운영: 조작 설명서, 데이터베이스 테이블 설명서, 데이터 인터페이스 설명서 — 가동 후 현장과 정보 부서가 쓰는 문서
• 검증: 시험 보고서, 검수 자료 — 합의한 기준을 충족했음을 보여주는 문서
• 유지보수: 유지보수 목록, 연간 유지보수 보고서 — 가동 후 작업 범위와 실시 기록을 남기는 문서

소규모 파일럿에서 관찰할 5가지

①부터 ⑦까지 서면 답변을 모두 받아도 실제 협업의 궁합은 보이지 않습니다. 범위를 좁힌 파일럿을 먼저 두면 자료로는 보이지 않는 부분이 몇 주 안에 드러납니다. 체계적으로 일하는 회사는 진단·파일럿·구축·검수·유지보수·확장이라는 단계로 프로젝트를 끊어 진행하므로, 파일럿 단계만 잘라내 위탁하는 요청도 받을 수 있습니다.

파일럿 대상은 설비 1대 또는 라인 1개로 충분합니다. 관찰할 것은 산출물의 완성도만이 아니라 아래 5가지입니다.

• 질문의 내용 — 현장 조건을 확인하는 질문이 오는가, 요구사항서를 그대로 받아들여 진행하는가
• 응답의 속도와 형태 — 답이 구두에 머무는가, 문서와 도면으로 남는가
• 문서의 세밀도 — 파일럿 단계 자료라도 나중에 다시 읽을 수 있는 수준인가
• 변경이 발생했을 때의 처리 — 영향 범위를 먼저 알리고 대응하는가, 조용히 다시 만드는가
• 한국어 문서의 실제 수준 — 기계 번역 출력에 가까운가, 현장 작업자가 읽을 수 있는 문장인가