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

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

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

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

시스템 개발의 외부 위탁에서는 기술이 아니라 계약의 형태가 원인이 되어 문제가 생기는 경우가 적지 않습니다.

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

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

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

1. 먼저 결론

시스템 개발과 운용 보수 계약에 대해, IPA의 모델 거래·계약서가 제시하는 사고방식을 먼저 정리합니다.

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

한마디로 말하면, 「정해지지 않은 것에는 완성책임을 약속하지 않고, 정해진 것에는 완성책임을 약속한다」는 원칙으로 공정별로 계약의 형태를 구분해서 사용하는 사고방식입니다.

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

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

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

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

다만 적용 범위에는 주의가 필요합니다. 이 제1판·제2판은 원래 기업의 기간계 시스템 등 비교적 대규모의 커스텀 개발(워터폴형)을, 시스템 부서나 법무 체계를 갖춘 기업 간의 거래를 상정하여 만든 것입니다. 중소 규모의 거래나 패키지·SaaS를 활용하는 사례를 위해서는, 별도로 「패키지, SaaS/ASP 활용, 보수 운용」을 대상으로 한 추보판 계열의 모델 계약이 마련되어 있습니다. 자사의 거래가 어느 쪽에 가까운지 확인한 다음, 조문을 그대로 가져다 쓰기보다는 사고방식의 토대로 삼는 것이 올바른 거리감입니다. 이 글에서 소개하는 것도 규모를 불문하고 도움이 되는 「사고방식」 부분입니다.

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

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

즉, 앞으로 계약서를 작성할 때의 초안으로도, 상대방이 제시한 계약서를 확인할 때의 비교 기준으로도 사용할 수 있는 자료입니다.

어느 판을 보면 좋은가

IPA 페이지에는 여러 판이 나열되어 있으므로, 자사의 거래가 어느 것에 가까운지 먼저 정하고 나서 열어보면 헤매지 않습니다.

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

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

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

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

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

다단계 계약이란 이러한 공정을 하나의 계약으로 묶지 않고, 공정별(또는 공정 묶음별)로 계약을 나누어 체결하는 방식입니다.

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

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

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

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

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

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

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

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

• 수탁 측이 불확실한 리스크를 감안한 다소 큰 금액을 제시한다
• 저렴하게 수주한 수탁 측이 나중에 「그것은 범위 밖입니다」라고 주장하며 발주 측과 다툰다

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

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

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

다단계 계약에서는 공정별로 준위임 계약과 도급 계약을 구분해서 사용합니다. 이 둘의 차이가 이 글에서 가장 중요한 포인트입니다.

이 장에서 나오는 용어를 먼저 간단히 정리해 둡니다.

이를 바탕으로 도급과 준위임의 차이를 표로 정리합니다.

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

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

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

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

준위임 계약 ── 전문가로서의 업무를 약속하는 계약

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

「완성책임이 없다」고 하면 발주 측에게는 불안하게 들릴지도 모릅니다. 그러나 이는 「대충 해도 된다」는 뜻이 아닙니다. 전문가로서 부적절한 업무를 하면 선관주의의무 위반으로 책임을 추궁당합니다.

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

공정별 구분 사용

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

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

정해지지 않은 단계의 업무를 무리하게 도급으로 하면, 완성의 기준이 모호한 채 완성책임만 약속되어 「완성했다/하지 않았다」의 진흙탕 싸움이 됩니다. 공정의 성질에 맞는 계약유형을 선택하는 것이, 결국은 양측을 지키는 길입니다.

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

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

운용 보수라고 한마디로 말해도, 그 안에는 성질이 다른 업무들이 모여 있습니다.

• 가동 감시, 백업, 정기 점검
• 조작 방법 등의 문의 대응
• 장애 발생 시의 1차 조사·복구 대응
• 결함 수정
• OS나 미들웨어 업데이트 대응
• 기능 추가·화면 변경 등의 개수

이 중 감시·문의 대응·1차 조사와 같은 계속적인 업무는 준위임형이 기본입니다. 한편, 내용을 명확히 정의할 수 있는 기능 추가나 개수는 보수 계약 안에 모호하게 포함시키지 말고, 개별로 견적을 내어 도급으로 분리하는 것이 안전합니다.

말로만 설명하면 실감하기 어려우므로, 선을 긋는 예를 들겠습니다. 어디에 선을 그을지는 계약으로 정하는 것이므로, 이는 어디까지나 「흔히 있는 타협점」입니다.

4번째 줄의 「화면에 1항목 추가」는 의뢰하는 쪽에서 보면 사소해 보이지만, 실제로는 설계·구현·테스트·릴리스 일체가 움직입니다. 「화면이나 장표의 항목이 증감하는 의뢰는 별도 견적」과 같이, 판단이 갈리지 않는 기준을 한 줄 정해 두면 그때그때의 협상이 줄어듭니다.

계약 시에는 적어도 다음 사항을 문서로 정해 둘 것을 권장합니다.

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

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

6. 발주 측에도 의무가 있다 ── 협력의무와 프로젝트 관리 의무

계약서 이야기에서 조금 범위를 넓히면, 모델 거래·계약서의 해설이나 그동안의 판례에서 반복적으로 제시되어 온 중요한 사고방식이 있습니다. 시스템 개발은 발주 측과 벤더의 공동 작업이며, 어느 쪽에도 다해야 할 의무가 있다는 점입니다.

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

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

모델 거래·계약서에는 양측의 역할 분담을 문서화하고, 연락협의회(정례 회의)에서 진행 상황과 과제를 공유하는 구조가 포함되어 있습니다. 계약서 양식이라기보다 프로젝트를 공동으로 운영하기 위한 룰북으로 읽으면, 발주 측에게도 얻는 것이 많은 자료입니다.

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

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

• 발주 측은 「사소한 변경이라고 생각했다」
• 수탁 측은 「대응은 했지만, 공수가 늘어났으므로 추가 비용을 청구하고 싶다」

구두나 메일 주고받기도 협상의 기록은 되지만, 변경의 범위·비용·납기까지 포함해 양측이 공식적으로 합의한 문서가 없기 때문에, 이런 상태가 된 뒤에는 진흙탕 싸움이 되기 쉽습니다.

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

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

포인트는 변경의 내용뿐 아니라 비용과 납기에 대한 영향을 함께 합의한 다음 착수하는 것입니다. 절차로서는 한 단계 더 거치는 셈이지만, 이 한 단계가 「말했다·안 했다」를 막아 줍니다.

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

지금까지 설명한 것은 요건을 정한 뒤 만드는 워터폴형을 전제로 한 계약입니다.

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

애자일 개발판의 특징은 다음과 같습니다.

• 계약유형은 준위임 계약을 전제로 한다. 개발 도중에 기능의 추가·변경이나 우선순위의 재검토를 하는 것이 전제인 방법론이며, 처음에 산출물을 확정하는 도급과는 맞지 않기 때문
• 개발 방법론으로 스크럼을 채택하고, 역할 분담(프로덕트 오너 등)을 계약에 포함하고 있다
• 계약 전 체크리스트가 첨부되어 있어, 프로젝트의 목적이나 애자일 개발에 대한 이해도를 발주 측·수탁 측이 확인한 뒤 계약으로 진행하는 구성으로 되어 있다

「애자일이니까 계약은 모호해도 된다」가 아니라, 「변화에 대응하는 개발이기 때문에 오히려 역할과 진행 방식을 계약으로 명확히 한다」는 설계입니다.

정리

IPA의 정보시스템·모델 거래·계약서에서 배울 수 있는, 수탁 개발·운용 보수 계약의 사고방식을 정리합니다.

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

모델 계약서 양식과 해설은 IPA 웹사이트에서 Word 형식으로 무료로 다운로드할 수 있습니다. 앞으로 개발을 위탁하실 분도, 계약서를 제시받으신 분도 한 번쯤 훑어봐서 손해될 것 없는 자료입니다.

시스템 개발·보수 위탁을 검토 중이신 분께

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

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

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

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

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

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

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

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

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

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

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

저자 프로필

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

Go Komura

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

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