COBOL 현대화 서비스를 구매하는 일은 다른 어떤 소프트웨어 발주와도 다릅니다. 대상 시스템은 삼사십 년째 돌아가고 있고, 지금 회사에 남아 있는 사람 가운데 그 전체를 온전히 이해하는 사람은 없으며, 잘못됐을 때의 대가는 놓친 스프린트가 아니라 규제 보고 실패라는 단위로 측정됩니다. 그런데 책상 위에 놓인 제안서들은 하나같이 같은 결과를 약속하면서 가격만 터무니없이 벌어져 있습니다.

이 글은 제대로 된 계약에 실제로 무엇이 담기는지, 업체 유형이 어떻게 다른지, 그리고 근거 위에 세운 입찰과 낙관 위에 세운 입찰을 갈라내는 질문이 무엇인지 정리합니다. 읽는 사람이 나중에 그 결정을 직접 해명해야 하는 자리에 있다고 전제했습니다.

무엇을 볼 것인가: 믿을 만한 COBOL 현대화 제안에는 현황 분석, 목표 아키텍처 설계, 데이터 이전, 변환 또는 리호스팅, 비교 기반 테스트 프로그램, 병행 운영, 전환 계획, 지식 이전이 들어 있습니다. 코드 변환에만 값을 매긴 입찰은 프로그램 계획이 아닙니다. 그 가운데 가장 싼 사분의 일일 뿐입니다.

COBOL 현대화 서비스에 실제로 들어가는 것

세 업체에 제안을 요청하면 범위에 대한 정의도 세 가지로 돌아옵니다. 가격을 비교하기 전에 항목 목록부터 맞춰 두는 것이 이 단계에서 할 수 있는 가장 쓸모 있는 일입니다. 작업의 절반을 빠뜨린 입찰은 요약 페이지 위에서 언제나 더 좋아 보이기 때문입니다.

현황 분석이 먼저입니다. 업체는 자산 전체를 파싱해 의존 관계와 데이터 계보 지도를 그리고, 죽은 코드를 찾아내고, 프로그램과 카피북, 잡 스트림, 데이터베이스 객체의 목록을 내놓습니다. 이 단계에서는 비용을 밀어 올리는 구조도 함께 드러나야 합니다. 어셈블러 모듈, 별난 트랜잭션 처리 방식, 가변 레코드 레이아웃, 그리고 수십 년 동안 컴파일러가 눈감아 준 표현들 말입니다.

목표 아키텍처가 그다음입니다. 이 시스템이 무엇이 될지는 누군가 결정해야 합니다. 리호스팅된 COBOL 워크로드인지, 현대적인 언어로 변환된 코드베이스인지, 여러 서비스의 묶음인지, 아니면 시간을 두고 단계적으로 섞은 형태인지입니다. 이 결정은 변환을 시작하기 전에 놓여야 하고, 결론만 통보할 것이 아니라 그렇게 판단한 이유가 보이도록 문서로 남아야 합니다.

데이터 이전은 스키마 설계와 추출, 변환, 대사까지를 포함합니다. 메인프레임 데이터 형식은 관계형 스키마가 직접 표현하지 못하는 의미를 품고 있어서, 이 작업은 기계적이기보다 분석적입니다.

코드 변환 또는 리호스팅은 모두가 눈길을 주는 부분이지만, 전체 공수에서는 보통 소수에 그칩니다. 자동화가 여기서 무엇을 할 수 있고 무엇을 할 수 없는지는 메인프레임 마이그레이션 도구 를 다룬 저희 글에서 정리했습니다.

구매자가 가장 자주 잘라내는 단계

테스트와 비교가 돈이 흘러가는 곳입니다. 제대로 된 프로그램은 옛 시스템과 새 시스템에 동일한 입력을 넣어 돌리고 출력을 항목 단위로 맞대어 보는 하네스를 만든 다음, 거기서 나온 차이를 하나씩 고치거나 공식적으로 받아들이는 데까지 끌고 갑니다. 이것은 그 자체로 하나의 소프트웨어 프로젝트이며 그렇게 값이 매겨져야 합니다.

병행 운영과 전환은 정해진 기간 동안 실제 운영 물량으로 두 시스템을 함께 돌린 뒤, 검증된 되돌리기 계획을 손에 쥐고 넘어가는 것을 뜻합니다. 시간을 아끼려고 이 단계를 건너뛴 프로그램이 나중에 좋지 않은 이유로 사례 연구에 등장합니다.

지식 이전과 지원이 계약을 마무리합니다. 업체가 떠난 뒤에도 내부 팀이 결과물을 운영하고 바꿀 수 있어야 합니다. 그것이 인수 기준을 갖춘 명시적 산출물이 아니라면, 당신이 산 것은 현대화가 아닙니다. 종속입니다.

업체의 세 가지 유형과 각자 잘하는 일

이 시장은 강점이 실제로 다른 세 집단으로 나뉘고, 무엇이 맞는지는 순위표보다 당신의 자산이 결정합니다.

도구 업체와 그 파트너는 자동 변환이나 리호스팅 플랫폼을 앞세웁니다. 기술은 대체로 성숙했고 변환 처리량은 실제로 인상적입니다. 짚어 둘 것은 이해관계의 방향입니다. 이들의 상업적 이익은 자사 제품이 처리하는 비중을 키울수록 커지는데, 그것이 당신이 즐겁게 유지보수할 코드베이스와 늘 같은 방향은 아닙니다. 게다가 운영 자산이 그들의 런타임에 묶입니다. 이것은 값을 매겨 두어야 할 종속입니다.

글로벌 시스템 통합업체는 규모와 프로그램 거버넌스, 여러 해에 걸친 대규모 인력 운용 능력을 가져옵니다. 자산이 여러 사업부에 걸쳐 수백만 행에 이른다면 이 공급 능력은 실제로 중요하고, 그것을 댈 수 있는 곳은 많지 않습니다. 대가는 비용 구조와, 제안서를 쓴 사람과 실제로 일할 사람 사이의 거리입니다. 누가 팀에 들어오는지, 어디에 앉아 있는지, 어떤 경험이 있는지를 콕 집어 물어보십시오.

전문 엔지니어링 회사는 규모가 작고 처음부터 끝까지 경력 있는 사람이 붙으며, 팔 제품이 없어서 도구에 대해 중립인 경우가 많습니다. 수십만 행 규모의 자산, 단계를 나눈 프로그램, 그리고 어려운 지점이 물량이 아니라 업무 로직인 상황에 맞습니다. 이백 명 규모의 프로그램에 인력을 세울 수는 없고, 그렇다고 말해야 합니다.

어디에나 통하는 정답은 없습니다. 특정 자산에 맞는 정답이 있을 뿐이고, 자기 모델이 모든 상황에 맞는다고 말하는 업체는 자기가 어떻게 파는지를 알려 주고 있는 것입니다.

부실한 입찰을 드러내는 질문

구매 질의서로는 정작 중요한 것이 잘 드러나지 않습니다. 아래 질문은 드러냅니다.

“가장 고약한 모듈을 변환해서 결과물을 보여 주십시오.” 모두가 피해 다니는 프로그램을 고르십시오. 어셈블러를 호출하고 여러 겹의 가변 레코드를 쓰는 것이면 더 좋습니다. 요약이 아니라 생성된 코드 자체를 보여 달라고 하십시오. 자기 방식에 자신이 있는 업체는 금액이 정해진 적당한 범위 산정 비용 안에서 이 일을 해 줍니다. 꺼리는 반응 역시 하나의 답입니다.

“십진 연산과 정렬 순서는 어떻게 다룹니까?” 팩 십진 필드와 메인프레임 조합 순서는 둘 다 재무 수치와 보고서 정렬에서만 나타나는 차이를 만듭니다. 답변은 구체적이고 기술적이어야 합니다. 여기서 말이 흐릿한 상대와는 인수 테스트 구간이 힘들어집니다.

“테스트 범위에는 정확히 무엇이 들어가고, 비교 하네스는 누가 씁니까?” 여기서 찾는 것은 이름이 붙은 산출물, 공수 추정치, 그리고 운영에 준하는 데이터를 누가 대는지에 대한 정리입니다. 테스트가 구축 공수의 몇 퍼센트라는 식으로 설명된다면 그 업체는 추측하고 있는 것입니다.

“설명되지 않는 차이가 나오면 어떻게 합니까?” 어떤 프로그램에서든 출력이 어긋나는데 아무도 이유를 대지 못하는 경우가 나옵니다. 좋은 업체는 현업 승인이 들어간 분류 절차를 설명합니다. 그런 일은 생기지 않는다고 말하는 쪽은 프로그램을 끝까지 해 본 적이 없거나 솔직하지 않은 것입니다.

“완성된 소스 코드는 누구 것이 되고, 우리가 떠날 수 있습니까?” 답은 전부 온전히 당신 것이고, 계속 운영하는 데 런타임 라이선스가 필요 없다는 것이어야 합니다. 답의 어느 부분에라도 독자 계층에 대한 지속적인 라이선스가 끼어 있다면, 결제를 멈췄을 때 운영 시스템에 무슨 일이 벌어지는지를 정확히 파악해 두십시오.

“잘못됐던 프로그램과 그 뒤에 무엇을 바꿨는지 들려주십시오.” 이런 일을 몇 건 넘게 해 본 조직이라면 반드시 하나쯤 있습니다. 이 답은 지금 마주 앉은 상대가 엔지니어인지 영업 조직인지를 알려 줍니다.

COBOL 현대화 서비스의 가격은 어떻게 매겨지나

가격 모델은 여러 가지이고, 각각 위험을 다르게 나눕니다. 겉에 적힌 숫자보다 그 분배 방식을 이해하는 편이 중요합니다.

실비 정산은 진짜 미지수가 남아 있는 일에 가장 정직한 모델이고, 이사회에는 가장 불편한 모델입니다. 이 방식은 현황 분석에 맞습니다. 그리고 현황 분석은 거의 언제나 따로, 가장 먼저 발주되어야 합니다. 그래야 나머지를 가정이 아니라 근거에 대고 값을 매길 수 있습니다.

모듈 단위나 천 행당 고정가는 변환 작업에서 흔하고, 현황 분석이 모듈 안에 무엇이 들었는지 밝혀낸 뒤라면 합리적입니다. 다만 제외 조항을 꼼꼼히 읽으십시오. 이런 가격은 대개 정해진 복잡도 구간 안에 드는 코드를 전제하며, 그 밖의 것은 개별로 다시 값이 매겨집니다. 편차는 바로 거기 삽니다.

성과 기반 가격은 인수된 기능적 동등성에 대금을 묶는 방식으로 이해관계는 잘 맞춰지지만, 다툼을 가릴 수 있을 만큼 정밀한 인수 기준을 요구합니다. 그 기준을 제대로 정의하는 수고는 들일 값어치가 있습니다.

현황 분석을 돌리기도 전에 프로그램 전체에 확정 고정가를 내미는 회사는 의심하십시오. 그것은 자신감의 표시가 아닙니다. 최악의 경우까지 덮을 만큼 예비비를 얹은 가격이거나, 낙관적으로 매겨 놓고 어려운 모듈이 드러나는 순간 변경 요청으로 도착할 가격이거나 둘 중 하나입니다. 어느 쪽도 싸게 산 것이 아닙니다.

할인에 대해 말하자면, 이 시장은 그런 식으로 굴러가지 않습니다. 의미 있는 감액은 범위를 좁히거나, 뒤 단계가 앞 단계에서 배운 것을 쓰도록 프로그램을 나누거나, 현황 분석이 더는 쓰이지 않는다고 밝혀낸 코드를 걷어낼 때 나옵니다. 범위를 그대로 둔 채 가격을 크게 깎는 업체는 첫 숫자가 임의였다고 스스로 말한 셈입니다. 예산이 실제로 어디로 가는지는 COBOL 마이그레이션 비용과 기간 가이드 에서 나눠 두었습니다.

계약서에서 반드시 지켜야 할 조항

몇 개의 조항이 아무리 두꺼운 거버넌스보다도 결과를 더 잘 지켜 줍니다.

납품되는 소스 코드와 스키마, 스크립트, 테스트 자산 전부에 대해 제약 없는 소유권을 요구하십시오. 비교 하네스도 포함입니다. 그 하네스는 앞으로 몇 년을 두고 다시 쓰게 될 자산입니다.

인수는 코드의 납품이 아니라 합의된 데이터 집합에 대해 기능적 동등성이 시연된 상태로 정의하십시오. 변환이 끝났다는 말과 출력이 일치한다는 말 사이의 거리가 이 프로젝트의 전부입니다.

현황 분석과 파일럿, 단계별 변환, 전환으로 나뉜 구조와 진짜 출구를 요구하십시오. 어느 단계에서 멈추더라도 손에 값어치 있는 것이 남습니다. 통짜 계약 하나로는 그렇게 되지 않습니다.

핵심 인력을 계약서에 이름으로 적고, 교체에 관한 조항을 넣으십시오. 제안하러 온 팀과 실제로 도착하는 팀 사이의 간극은 이 시장에서 가장 흔한 불만입니다.

마지막으로 지식 이전을 자체 인수 기준을 가진 산출물로 만들고, 내부 팀이 도움 없이 실제 변경을 해내는 것으로 그 증거를 삼으십시오. 그러지 않으면 그것은 마지막 주에 배포되는 슬라이드 묶음이 됩니다.

재판매업체 말고 엔지니어와 이야기하십시오

Mecanik은 독립 엔지니어링 회사로서 COBOL 현대화 와 COBOL 마이그레이션 프로그램을 수행합니다. 저희는 변환 플랫폼을 재판매하지 않기 때문에, 도구에 대한 권고는 저희가 라이선스를 들고 있는 것이 아니라 당신의 코드베이스가 필요로 하는 것을 반영합니다.

저희는 현황 분석과, 가장 어려운 모듈을 대상으로 한 유상 파일럿에서 시작합니다. 업계 평균이 아니라 당신의 실제 코드에 뿌리를 둔 추정이 나오기 때문입니다. 거기서부터 변환하거나, 리호스팅하거나, 지금은 둘 다 정당화되지 않는다고 말씀드립니다. 마지막 답이 맞을 때도 가끔 있습니다. 단계별 내용은 COBOL 마이그레이션 서비스 페이지에 더 자세히 적어 두었고, 그보다 앞서 오는 재작성과 리팩터링, 리플랫폼 사이의 결정은 메인프레임 현대화 전략 가이드에서 다룹니다.

자산이 대략 얼마나 큰지, 그리고 시기를 밀어붙이는 것이 무엇인지 알려 주시면, 현실적인 프로그램이 어떤 모습인지 말씀드리겠습니다.

함께 읽기: COBOL에서 Java로 마이그레이션 - 영국 기업 가이드 , COBOL에서 C#로 마이그레이션: UK 기업 가이드 , COBOL에서 Python으로 마이그레이션 - 영국 기업 가이드 , COBOL에서 Go로 마이그레이션: 영국 기업 가이드 .

자주 묻는 질문

COBOL 현대화 서비스에는 무엇이 포함됩니까? 온전한 계약은 현황 분석, 목표 아키텍처 설계, 데이터 이전, 코드 변환 또는 리호스팅, 비교 기반 테스트 프로그램, 병행 운영, 전환 계획, 지식 이전을 아우릅니다. 코드 변환에만 값을 매긴 제안은 실제 작업 가운데 소수만 덮고 있는 것입니다.

COBOL을 현대 언어로 옮기는 일은 누가 제공합니까? 세 집단이 합니다. 도구 업체와 그 구축 파트너, 글로벌 시스템 통합업체, 그리고 독립 전문 엔지니어링 회사입니다. 도구 업체는 성숙한 자동화를, 통합업체는 아주 큰 자산을 감당할 규모를, 전문 회사는 중간 규모 프로그램에 경력 있는 엔지니어와 도구 중립성을 제공합니다.

COBOL 현대화 프로젝트의 가격은 어떻게 매겨집니까? 흔한 모델은 실비 정산, 모듈 단위나 천 행당 고정가, 그리고 기능적 동등성에 묶인 성과 기반 가격입니다. 현황 분석은 따로, 가장 먼저 발주해야 나머지를 가정이 아니라 근거에 대고 값을 매길 수 있습니다.

현황 분석 전에 고정가를 받아들여도 됩니까? 대체로 아닙니다. 분석 없이 나온 고정가는 필요 없을 수도 있는 예비비가 얹혀 있거나, 낙관적이어서 결국 변경 요청으로 돌아옵니다. 현황 분석을 먼저 구매하고, 그 결과로 이후 단계의 확정 가격을 받으십시오.

업체가 우리 코드베이스를 감당할 수 있는지 어떻게 확인합니까? 범위 산정 단계에서 가장 어려운 모듈을 변환해 생성된 결과물을 보여 달라고 하십시오. 어셈블러 호출과 가변 레코드 레이아웃, 팩 십진 연산이 들어간 것을 고르십시오. 무엇이 나오는지, 그리고 얼마나 선뜻 응하는지가 어떤 레퍼런스 통화보다 많은 것을 알려 줍니다.