수탁 개발·운영 유지보수 계약은 어떻게 맺어야 하는가 ── IPA 「모델 거래·계약서」에서 배우는 준위임과 도급의 구분

「일괄 도급으로 계약했는데, 요건이 잡히지 않은 채로 개발이 시작되어 완성 기준을 두고 다투었다」

「월액 유지보수 계약을 맺고 있지만, 어디까지가 유지보수 범위인지 서로의 인식이 달랐다」

「견적을 받았더니 『요건 정의는 준위임으로』라는 말을 들었는데, 왜 공정마다 계약을 나누는지 모르겠다」

시스템 개발을 외부에 위탁할 때는, 기술이 아니라 계약의 형태 때문에 문제가 생기는 경우가 적지 않습니다.

사실 이 문제에는 공적인 「본보기」가 있습니다. IPA(독립행정법인 정보처리추진기구)가 공개하는 정보시스템·모델 거래·계약서입니다.

이 글에서는 이 모델 계약을 바탕으로, 수탁 개발이나 운영 유지보수를 맡길 때·맡을 때의 계약을 어떻게 짜야 하는지를 발주 측도 이해할 수 있는 말로 정리합니다.

다만 이 글은 IPA의 공개 자료를 바탕으로 한 일반적인 설명이며, 법적 조언이 아닙니다. 개별 계약에 대해서는 변호사 등 전문가에게 상담하시기 바랍니다.

1. 먼저 결론

시스템 개발과 운영 유지보수 계약에 대해, IPA의 모델 거래·계약서가 제시하는 관점을 먼저 정리합니다.

• 개발의 전 공정을 하나의 계약으로 묶지 않고, 공정마다 계약을 나눈다(다단계 계약)
• 「무엇을 만들 것인가」가 아직 정해지지 않은 기획·요건 정의 공정은 준위임 계약으로 한다
• 「무엇을 만들 것인가」가 정해진 뒤의 내부 설계〜개발·테스트 공정은 도급 계약을 기본으로 한다(외부 설계는 사안에 따라 어느 쪽도 가능하다)
• 운영·유지보수처럼 계속되는 업무는 준위임 계약을 기본으로 한다
• 발주 측에도 요건을 정하고 정보를 제공하는 등의 협력 의무가 있다
• 사양 변경은 구두로 주고받지 않고, 문서에 의한 변경 관리 절차로 다룬다

한 줄로 말하면, 「정해지지 않은 것에는 완성 책임을 약속하지 않고, 정해진 것에는 완성 책임을 약속한다」는 원칙으로 공정마다 계약 형태를 가려 쓰는 방식입니다.

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 27건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. IPA 「정보시스템·모델 거래·계약서」란

정보시스템·모델 거래·계약서는 시스템 개발 위탁 계약의 서식과 그 해설을 정리한 공적 문서입니다.

원래는 경제산업성이 2007년에 수탁 개발(일부 기획을 포함), 보수 운용을 대상으로 한 제1판으로 공개했습니다. 사용자 기업(발주 측)과 IT 벤더(수탁 측) 사이에서 계약 내용의 인식이 어긋나 분쟁이 잦았던 것이 배경입니다.

이후 개정을 IPA가 이어받아, 2020년 4월에 시행된 개정 민법에 맞춘 제2판이 2020년 12월 22일에 공개되었습니다. 제2판에서는 뒤에서 다루는 계약부적합책임이나 성과완성형 준위임 계약의 위치 등이 정리되어 있습니다.

적용 범위에는 주의가 필요합니다. 이 제1판·제2판은 원래 기업의 기간 시스템처럼 비교적 대규모 맞춤 개발(Waterfall형)을, 시스템 부서나 법무 체제를 갖춘 기업 간의 거래로 상정하고 만든 것입니다. 중소 규모 거래나 패키지·SaaS를 쓰는 경우를 향해서는, 따로 「패키지, SaaS/ASP 활용, 보수 운용」을 대상으로 한 보충판 계통의 모델 계약이 마련되어 있습니다. 자사 거래가 어느 쪽에 가까운지를 확인한 뒤, 조문을 그대로 가져오기보다 관점의 바탕으로 쓰는 것이 올바른 거리감입니다. 이 글에서 소개하는 것도 규모를 가리지 않고 도움이 되는 「관점」의 부분입니다.

이 모델 계약에는 다음과 같은 특징이 있습니다.

• 사용자 기업, IT 벤더, 업계 단체, 법률 전문가가 논의해 만들었으며, 어느 한쪽에 유리하지 않도록 중립적으로 설계되어 있다
• 계약서 서식이 Word 형식으로 공개되어 있어, 자사 거래에 맞춰 수정해 쓸 수 있다
• 조문만이 아니라 「왜 그렇게 정하는지」의 해설이 붙어 있다
• 개발 계약의 보안 사양을 정하기 위한 가이드라인 등 부속 문서도 공개되어 있다

즉, 앞으로 계약서를 만들 때의 초안으로도, 상대가 제시한 계약서를 확인할 때의 비교 기준으로도 쓸 수 있는 자료입니다.

어느 판을 보면 되는가

IPA 페이지에는 여러 판이 나란히 있으므로, 자사 거래가 어디에 가까운지를 먼저 정한 뒤 열면 헤매지 않습니다.

이 글의 이후 설명은 가장 기본이 되는 제2판 본편을 전제로 합니다.

3. 핵심은 「다단계 계약」── 왜 공정마다 계약을 나누는가

모델 거래·계약서의 핵심은 다단계 계약입니다.

시스템 개발은 대략 다음 같은 공정으로 진행됩니다.

기획·요건 정의(무엇을 만들지를 정한다)
        ↓
설계·개발·테스트(정한 것을 만든다)
        ↓
인수·도입 지원(만든 것을 업무에 올린다)
        ↓
운영·유지보수(계속 가동한다)

다단계 계약이란, 이 공정들을 하나의 계약으로 묶지 않고 공정마다(또는 공정의 묶음마다) 계약을 나누어 맺는 방식입니다.

실제 문서 구조 ── 기본 계약서와 개별 계약서의 이층

「공정마다 계약을 나눈다」고 하면 공정 수만큼 독립된 계약서를 만드는 것처럼 들리지만, 모델 계약서가 취하는 것은 기본 계약서와 개별 계약서의 이층 구조입니다. 서식을 열었을 때 당황하지 않도록 구조를 먼저 잡아 둡니다.

• 소프트웨어 개발 위탁 기본 모델 계약서(기본 계약서) ── 프로젝트 전체에 공통되는 사항을 정하는 것으로, 원칙적으로 프로젝트마다 한 부를 맺습니다. 용어의 정의, 재위탁, 협업과 역할 분담, 책임자, 연락 협의회, 변경 관리 절차, 비밀 유지, 지적재산권, 손해배상 같은 조문은 여기에 들어갑니다.
• 개별 계약서 ── 개별 업무에 착수하기 전에 그 업무마다 맺습니다. 요건 정의 작성 지원 업무, 외부 설계서 작성(지원) 업무, 소프트웨어 개발 업무, 소프트웨어 운용 준비·이행 지원 업무 같은 단위입니다. 여기서 정하는 것은 구체적인 작업 내용과 범위, 계약 유형(도급인지 준위임인지), 작업 기간 또는 납기, 역할 분담의 상세, 위탁료와 지급 방법, 납품물, 검사·확인에 관한 사항 등입니다.

즉 「공정마다 바뀌는 것」은 모두 개별 계약서 쪽으로 모아 두었고, 도급으로 할지 준위임으로 할지도 개별 계약서에서 정하는 구조입니다. 기본 계약서에는 개별 계약서의 조항이 기본 계약서에 우선한다는 취지도 정해져 있습니다.

운영·유지보수는 개발과는 다른 계약서(정보시스템 보수 운용 위탁 기본 모델 계약서)가 마련되어 있으며, 이쪽도 기본 계약서와 개별 계약서라는 같은 이층입니다. 보수 운용은 업무 종류가 다양해 일률적인 서식을 만들 수 없으므로, 공통 조항만 기본 계약서에 두고 각각의 위탁 업무는 개별 계약서에서 정한다는 관점이 명시되어 있습니다. 개별 계약서에는 정형화된 서비스 내용을 쓰는 업무 사양서와, 대상 시스템이나 실시 장소·역할 분담처럼 고객마다 달라지는 사항을 쓰는 수탁 조건 명세를 첨부하는 상정입니다.

제2판 본편에 수록된 계약 서류는 다음과 같습니다.

왜 나눌까요. 이유는 단순합니다. 공정에 따라 「약속할 수 있는 것」이 다르기 때문입니다.

요건 정의가 끝나기 전 단계에서는 만들 것의 내용도 분량도 확정되어 있지 않습니다. 이 시점에서 개발 전체의 금액과 납기를 확정하면 다음 중 하나가 일어납니다.

• 수탁 측이 불확정한 위험을 반영한 큰 금액을 제시한다
• 싸게 받은 수탁 측이 나중에 「그것은 범위 밖입니다」라고 주장해 발주 측과 다툰다

반면 요건 정의가 끝나 있으면 만들 것이 정해져 있으므로, 수탁 측은 현실적인 정밀도로 견적과 완성 약속을 할 수 있습니다.

다단계 계약은 「요건 정의가 끝난 시점에서 개발 부분을 다시 견적한다」는 것을 전제로 한 방식입니다. 발주 측에서 보면 총액이 처음에 확정되지 않는 불안은 있지만, 근거 없는 금액으로 전체를 확정하는 것보다 결과적으로 분쟁도 불필요한 비용도 줄어든다는 것이 모델 계약의 입장입니다.

4. 준위임과 도급 ── 두 계약 유형의 차이

다단계 계약에서는 공정마다 준위임 계약과 도급 계약을 가려 씁니다. 이 둘의 차이가 이 글에서 가장 중요한 포인트입니다.

이 장에서 나오는 용어를 먼저 짧게 정리합니다.

그다음에 도급과 준위임의 차이를 한눈에 정리합니다.

도급 계약 ── 완성을 약속하는 계약

도급은 「이 산출물을 완성합니다」라고 약속하는 계약입니다. 수탁 측은 완성 책임을 지며, 완성하지 못하면 원칙적으로 보수를 청구할 수 없습니다(다만 프로젝트가 도중에 끝난 경우에도, 완성된 부분을 떼어 발주 측의 이익이 될 때는 그 비율에 따른 보수가 인정되는 경우가 있습니다).

납품물이 계약 내용에 적합하지 않았던 경우, 수탁 측은 계약부적합책임을 집니다. 2020년 시행의 개정 민법에서 종래의 「하자담보책임」에서 재구성된 것으로, 발주 측은 수선(고쳐 달라고 하는 것)을 청구할 수 있고, 기간을 정해 수선을 요구해도 이루어지지 않는 경우 등 일정한 조건 아래에서는 보수의 감액을 청구할 수도 있게 되었습니다. 다만 발주 측이 제시한 사양이나 지시 자체가 원인이 되어 부적합이 생긴 경우에는, 수탁 측이 그 문제를 알면서도 알리지 않은 때 등을 제외하고 원칙적으로 이러한 청구는 할 수 없습니다. 모델 계약 제2판은 이 개정을 반영하고 있습니다.

완성과 맞바꿔 강한 책임을 지는 계약이므로, 「무엇을 가지고 완성으로 볼 것인가」를 명확히 정할 수 있는 공정에서 쓰는 것이 적절합니다.

준위임 계약 ── 전문가로서의 일을 약속하는 계약

준위임은 「전문가로서 업무를 수행합니다」라고 약속하는 계약입니다. 수탁 측은 완성 책임을 지지 않는 대신, 선관주의의무 즉 전문가로서 보통 기대되는 주의를 기울여 업무를 수행할 의무를 집니다.

「완성 책임이 없다」고 하면 발주 측에는 불안하게 들릴 수 있습니다. 그러나 이것은 「손을 놓아도 된다」는 뜻이 아닙니다. 전문가로서 부적절한 일을 하면 선관주의의무 위반으로 책임을 묻습니다.

또한 개정 민법에서는 성과완성형 준위임이라는 보수 지급 방식도 명문화되었습니다. 수행한 업무의 비율에 따라 보수를 지급하는 이행비율형(시간 단가로 정산하는 방식이 그 대표적인 예이고, 정형 업무를 월액 고정으로 수행하는 형태도 있을 수 있습니다)에 대해, 성과완성형에서는 합의한 성과에 대해 보수를 지급합니다. 요건 정의서처럼 산출물이 있는 준위임 업무에서는 이 형을 씀으로써 「준위임이지만 산출물의 납품과 보수가 연결되어 있는」 형태로 만들 수 있습니다.

공정마다의 구분

모델 거래·계약서에서는 대략 다음과 같은 구분이 상정되어 있습니다.

여기서 중요한 것은 「도급이 발주 측에 유리하다」「준위임은 수탁 측에 유리하다」는 단순한 이야기가 아니라는 점입니다.

정해지지 않은 단계의 일을 억지로 도급으로 하면, 완성 기준이 모호한 채로 완성 책임만 약속되어 「완성했다/하지 않았다」는 공방이 됩니다. 공정의 성격에 맞는 계약 유형을 고르는 일이 결국 양쪽을 지킵니다.

5. 운영 유지보수 계약에서 정해 두어야 할 것

개발이 끝난 뒤의 운영 유지보수는 개발과는 다른 분쟁의 씨앗을 안고 있습니다. 가장 많은 것은 「월액 유지보수 요금에 어디까지 포함되는가」의 인식 차이입니다.

운영 유지보수라고 한 마디로 말해도, 속은 성격이 다른 업무의 모임입니다.

• 가동 감시, 백업, 정기 유지보수
• 조작 방법 등의 문의 대응
• 장애 발생 시의 1차 조사·복구 대응
• 결함의 수정
• OS나 미들웨어 갱신에 대한 추종
• 기능 추가·화면 변경 등의 수정

이 가운데 감시·문의 대응·1차 조사처럼 계속되는 업무는 준위임형이 기본입니다. 반면 내용을 명확히 정의할 수 있는 기능 추가나 수정은 유지보수 계약 안에 모호하게 넣지 말고, 따로 견적해 도급으로 떼어 내는 편이 안전합니다.

말만으로는 실감하기 어려우니 선 긋기의 예를 듭니다. 어디에 선을 그을지는 계약에서 정하는 일이므로, 이것은 어디까지나 「흔히 보는 타협점」입니다.

4행째의 「화면에 한 항목 추가」는 의뢰하는 쪽에서는 가볍게 보이지만, 실제로는 설계·구현·테스트·릴리스가 한 세트로 움직입니다. 「화면이나 장표의 항목이 늘거나 줄어드는 의뢰는 별도 견적」처럼, 판단이 갈리지 않는 기준을 한 줄 정해 두면 그때그때의 협상이 줄어듭니다.

계약 시에는 적어도 다음 점을 문서로 정해 두기를 권합니다.

• 월액(정액) 범위에 포함되는 작업과 포함되지 않는 작업의 선 긋기
• 문의나 장애 대응의 접수 시간대와, 대응 시작까지의 대략적인 시간
• 장애 중요도의 구분과, 구분마다의 대응 방침
• 정액 범위를 넘는 작업이 생긴 경우의 견적·발주 절차
• 개발 시의 계약부적합책임(무상 수정의 대상)과 유지보수 계약(유상 대응)의 관계

특히 마지막 점은 놓치기 쉽습니다. 납품 직후 발견된 결함이 개발 계약의 계약부적합책임 범위인지, 유지보수 계약에서의 대응인지는 기간과 조건을 계약에서 명확히 해 두지 않으면 다투기 쉬운 포인트입니다.

6. 발주 측에도 의무가 있다 ── 협력 의무와 프로젝트 매니지먼트 의무

계약서 이야기에서 조금 넓어지지만, 모델 거래·계약서의 해설과 지금까지의 판례에서 반복해 제시되어 온 중요한 관점이 있습니다. 시스템 개발은 발주 측과 벤더의 공동 작업이며, 양쪽 모두 해야 할 의무가 있다는 점입니다.

• 벤더 측은 전문가로서 프로젝트를 적절히 관리하고, 위험이 있으면 설명할 의무(프로젝트 매니지먼트 의무)를 진다
• 발주 측은 요건을 정하고, 업무 내용의 정보를 제공하며, 필요한 의사결정을 기한 안에 하는 등의 협력 의무를 진다

즉 발주 측이 「전문적인 일은 모르니까」라며 모든 것을 벤더에 맡기는, 이른바 떠넘기기를 하면 요건이 잡히지 않고, 프로젝트가 실패했을 때 발주 측의 협력 의무가 문제로 떠오르기도 합니다.

모델 거래·계약서에는 양쪽의 역할 분담을 문서로 남기고, 연락 협의회(정례 회의)에서 진척과 과제를 공유하는 장치가 들어 있습니다. 계약서 서식이라기보다 프로젝트를 함께 운영하기 위한 규칙집으로 읽으면, 발주 측에도 얻는 것이 큰 자료입니다.

7. 사양 변경은 「변경 관리 절차」로 다룬다

개발 도중에 「역시 이 화면은 이렇게 바꾸고 싶다」는 요청이 나오는 것은 피할 수 없는 일입니다. 문제는 변경이 나온다는 것 자체가 아니라, 변경을 구두나 메일의 주고받음만으로 진행해 버리는 것입니다.

• 발주 측은 「가벼운 변경이라고 생각했다」
• 수탁 측은 「대응했지만 공수가 커졌으니 추가 비용을 청구하고 싶다」

구두나 메일의 주고받음도 교섭의 기록은 되지만, 변경의 범위·비용·납기까지 포함해 양쪽이 정식으로 합의한 문서가 없으므로, 이 상태가 되고 나면 공방이 되기 쉽습니다.

모델 거래·계약서에는 변경 관리 절차가 정해져 있습니다. 대략 다음 흐름입니다.

변경의 제안(어느 쪽에서든)
        ↓
서면(변경 제안서)으로 내용·영향 범위·비용·납기에 대한 영향을 제시
        ↓
양쪽이 협의
        ↓
합의되면 서면으로 남기고 변경을 실시 / 합의되지 않으면 현행대로

포인트는 변경의 내용만이 아니라 비용과 납기에 대한 영향을 세트로 합의한 뒤에 착수하는 것입니다. 절차로서는 한 번 더 손이 가지만, 이 한 번이 「말했다·말하지 않았다」를 막습니다.

8. Agile 개발의 경우에는 전용 모델 계약이 있다

여기까지 설명한 것은 요건을 정한 뒤에 만드는 Waterfall형을 전제로 한 계약입니다.

한편 만들면서 요건을 다시 보는 Agile 개발에는 정보시스템·모델 거래·계약서(Agile 개발판)이라는 전용 모델 계약이 2020년 3월 31일에 공개되어 있습니다.

Agile 개발판의 특징은 다음과 같습니다.

• 계약 유형은 준위임 계약을 전제로 한다. 개발 도중에 기능의 추가·변경이나 우선순위의 재검토를 하는 것이 전제인 기법이며, 처음에 산출물을 확정하는 도급과 맞지 않기 때문이다
• 개발 기법으로 Scrum을 채택하고, 역할 분담(Product Owner 등)을 계약에 넣고 있다
• 계약 전 체크리스트가 붙어 있어, 프로젝트의 목적이나 Agile 개발에 대한 이해도를 발주 측·수탁 측이 확인한 뒤에 계약으로 나아가는 구성이다

「Agile이니까 계약은 모호해도 된다」가 아니라, 「변화에 대응하는 개발이니까 역할과 진행 방식을 계약에서 명확히 한다」는 설계입니다.

정리

IPA의 정보시스템·모델 거래·계약서에서 배울 수 있는, 수탁 개발·운영 유지보수 계약의 관점을 정리합니다.

• 개발 전체를 하나의 계약으로 묶지 않고, 공정마다 계약을 나눈다(다단계 계약)
• 「무엇을 만들 것인가」를 정하는 기획·요건 정의는 준위임, 정해진 것을 만드는 내부 설계 이후의 개발은 도급이 기본(외부 설계는 어느 쪽도 가능하다)
• 도급은 완성 책임과 계약부적합책임, 준위임은 선관주의의무로, 수탁 측이 지는 책임의 성격이 다르다
• 운영 유지보수는 준위임을 기본으로, 정액 범위와 개별 견적의 선 긋기를 계약 시 문서로 남긴다
• 발주 측에도 협력 의무가 있으며, 떠넘기기는 프로젝트를 실패시킨다
• 사양 변경은 변경 관리 절차에 올리고, 비용·납기에 대한 영향과 세트로 합의한다
• Agile 개발에는 준위임을 전제로 한 전용 모델 계약이 있다

모델 계약서의 서식과 해설은 IPA의 Web 사이트에서 Word 형식으로 무상 다운로드할 수 있습니다. 앞으로 개발을 위탁하는 분도, 계약서를 제시받은 분도, 한 번 읽어 두면 손해 없는 자료입니다.

시스템 개발·유지보수의 위탁을 검토하시는 분께

계약의 형태를 적절히 고르려면, 그 전제로 「무엇을 만들 것인가」「어디까지를 위탁할 것인가」「발주 측과 수탁 측이 역할을 어떻게 나눌 것인가」가 정리되어 있어야 합니다.

합동회사 고무라소프트에서는 Windows 업무 앱이나 Web 시스템의 수탁 개발·유지보수 상담을 받을 때, 이 글에서 소개한 다단계 계약의 관점에 따라 요건 정리 단계와 개발 단계를 나누어 제안합니다. 개발 범위나 산출물의 정리가 아직 남아 있는 단계라도, 현재 업무 내용의 확인부터 상담하실 수 있습니다.

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

도급 계약과 준위임 계약의 차이는 무엇인가요?

도급 계약은 「정한 산출물을 완성하는 것」에 대해 보수를 지급하는 계약으로, 수탁 측은 완성 책임과 계약부적합책임을 집니다. 준위임 계약은 「전문가로서 업무를 수행하는 것」에 대해 보수를 지급하는 계약(성과완성형 준위임에서는 합의한 성과에 대해 보수를 지급합니다)으로, 수탁 측은 선관주의의무(전문가로서 주의 깊게 업무를 수행할 의무)를 지지만 완성 책임은 지지 않습니다. 만들 것과 완성의 기준을 명확히 정할 수 있는 공정에는 도급이, 발주 측이 주체가 되는 검토를 지원하는 공정이나 계속적인 업무에는 준위임이 맞습니다.

왜 요건 정의는 준위임 계약이 권장되나요?

요건 정의는 「무엇을 만들 것인가」를 발주 측이 주체가 되어 정하는 공정이며, 벤더는 그 검토를 지원하는 입장이기 때문입니다. 또한 시작 시점에는 산출물을 구체적으로 확정하기 어려우므로, 이 단계에서 완성 책임(도급)을 약속하면 완성 기준이 모호해져 분쟁의 원인이 됩니다. IPA의 모델 거래·계약서에서도 기획·요건 정의 공정은 준위임형을 상정하고 있습니다.

운영 유지보수 계약은 도급과 준위임 중 어느 쪽이 좋은가요?

가동 감시, 문의 대응, 장애의 1차 조사처럼 「계속적인 업무」는 완성이라는 개념과 맞지 않으므로 준위임형이 기본입니다. 한편, 내용과 완성 기준을 명확히 정의할 수 있는 기능 추가나 화면 수정은 따로 떼어 도급으로 계약하는 방법이 있습니다. 월액 유지보수 계약에 무엇이 포함되고 무엇이 별도 견적인지를, 계약 시 문서로 선을 그어 두는 것이 중요합니다.

IPA의 모델 거래·계약서는 그대로 사용할 수 있나요?

모델 계약서는 Word 형식으로 공개되어 있으며, 자사 거래에 맞춰 수정해 쓰는 것이 전제입니다. 사용자 기업과 IT 벤더 어느 한쪽에 유리하지 않은 중립적인 입장에서 만들어졌기 때문에, 계약서의 초안이나 제시받은 계약서를 확인할 때의 비교 기준으로 도움이 됩니다. 다만 개별 계약 판단에 대해서는 변호사 등 전문가와 상담하시기를 권합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.