수탁 개발의 사양서, Excel 그대로 괜찮을까 ── 납품물로서의 형식 선택법

「수정판 사양서를 받았지만, 어디가 바뀌었는지 모른 채 검수 도장을 찍었다」

「개수를 의뢰하려 했더니, 납품받은 Excel 사양서가 지금 화면과 전혀 달랐다」

「개발 회사로부터 모눈종이 형태의 Excel 사양서가 도착했는데, 이것이 일반적인 것인가」

시스템 개발을 외부에 위탁하면 프로그램과 함께 사양서·설계서가 납품됩니다. 일본의 수탁 개발에서는 이 문서가 Excel로 작성되는 경우가 매우 많으며, 흔히 ‘Excel 모눈종이’라고 불리는, 셀을 잘게 나누어 원고지처럼 사용하는 스타일로 작성됩니다.

Excel 모눈종이에 대한 비판은 인터넷상에 수없이 많지만, 그 대부분은 개발팀 내부 문서로서의 사용 불편함을 논한 것입니다. 이 글에서는 관점을 바꾸어 수탁 개발에서 고객에게 납품하는 사양서에 초점을 맞추어, 무엇이 문제이고 어떤 형식을 선택해야 하는지를 검수·사양 변경·보수라는 계약 실무의 언어로 정리합니다. 발주하는 쪽에도, 납품하는 쪽의 개발 회사에도 도움이 되는 내용을 목표로 합니다.

1. 먼저 결론

먼저 요점을 정리합니다.

• 납품하는 사양서의 형식은 ‘개발 중에 쓰기 쉬운가’가 아니라, ‘고객이 리뷰할 수 있는가’, ‘검수를 견딜 수 있는가’, ‘사양 변경의 차이를 공유할 수 있는가’, ‘몇 년 후의 보수에서 사용할 수 있는가’로 선택한다
• 결론은 ‘Excel을 그만두는 것’이 아니라 ‘모눈종이를 그만두고, 적재적소로 되돌리는 것’. 문장은 Word, 표는 Excel 본래의 표, 도면은 작도 도구, 합의의 기록은 PDF
• 형식을 논의하기 전에, 어느 문서를 성과물로 할지, 편집 가능한 원본을 받을 수 있는지를 계약(개별 계약에서의 납입물 특정)으로 정해 둔다

문서의 성질별 권장 형식을 판단표로 정리하면 다음과 같습니다.

이하, 왜 이렇게 되는지를 순서대로 설명합니다.

2. 납품물로서의 Excel 모눈종이 사양서, 무엇이 문제인가

먼저 분명히 해두자면, Excel이라는 소프트웨어 자체가 나쁜 것은 아닙니다. 표 계산·목록 작성 도구로서의 Excel은 우수하며, 뒤에서 설명하듯 항목 정의서 등에서는 Excel이 정답입니다. 문제는 문장도 도면도 표도, 성질이 다른 것을 전부 ‘모눈종이’에 밀어 넣고 있다는 점입니다.

사내 내부 문서라면 이는 ‘작성한 본인들만 곤란한’ 문제입니다. 그러나 납품물이 되면 이야기가 달라집니다. 사양서는 고객이 대가를 지불하고 받는 성과물이며, 검수의 대상이고, 그 후 몇 년이나 사용되는 자산이기 때문입니다. 납품물의 관점에서 보면 Excel 모눈종이에는 다음과 같은 문제가 있습니다.

2.1 검수에서 제대로 리뷰할 수 없다

Excel 모눈종이에는 Word의 변경 이력과 같은 실용적인 차이 표시 기능이 없습니다. 정확히 말하면 Microsoft 365의 공동 편집 환경에는 셀 변경 이력(‘변경 내용 표시’나 버전 기록)이 있고, 통합 문서끼리 비교하는 Spreadsheet Compare 같은 도구도 존재합니다. 그러나 추적할 수 있는 것은 셀 값이나 수식이 중심이며, 모눈종이 문서에서 자주 사용하는 도형·텍스트 상자 안의 문자는 대상 밖이고, 메일 첨부로 파일을 주고받는 납품 현장에서는 공동 편집 이력이 애초에 작동하지 않습니다.

결국 리뷰 지적 사항을 반영한 수정판을 받았을 때, 고객은 ‘어디가 바뀌었는지’를 눈으로 직접 찾아야 합니다. 수십 개의 시트로 이루어진 문서를 매번 전부 다시 읽는 것은 비현실적이므로, 실제로는 ‘아마 고쳐졌겠지’라며 검수 도장을 찍게 됩니다.

이것이 바로 검수의 형해화입니다. 검수는 ‘납품물이 합의한 내용대로인지 확인하고 받아들이는’ 절차이며, 이 부분이 형해화되면 나중에 문제가 발견되었을 때 ‘검수를 통과시키지 않았느냐’, ‘아니, 확인할 수 있는 형태로 납품되지 않았다’라는 소모적인 논쟁으로 이어집니다.

2.2 사양 변경의 합의 기록이 남지 않는다

개발 도중에 사양은 반드시 바뀝니다. 그때 문서가 Excel 모눈종이라면, 변경 관련 주고받음은 ‘파일 사본의 산더미’가 되기 쉽습니다. 사양서_v2_최종_수정(2).xlsx 같은 파일명에 낯이 익은 분이 많을 것입니다.

문제는 어느 버전이 ‘양측이 합의한 버전’인지 나중에 특정할 수 없다는 것입니다. 추가 비용이나 납기를 둘러싸고 의견이 엇갈렸을 때, 근거가 되는 것은 합의한 문서입니다. 그 문서가 어느 것인지 알 수 없다면 평행선을 달리는 논쟁이 됩니다.

2.3 보수 단계에서 구현과 괴리된다

모눈종이 문서는 갱신 비용이 높기 때문에 납품 후 개수 시 점점 갱신되지 않게 됩니다. 레이아웃이 무너지는 것을 두려워해 아무도 손대지 않거나, 도형 안의 문자는 검색에 걸리지 않아 수정을 빠뜨리는 등이 쌓여, 몇 년 후에는 ‘사양서는 있지만 현재 상태와 맞는지 아무도 모르는’ 상태가 됩니다.

이 상태의 대가를 치르는 것은 다음 개수 때입니다. 문서를 믿을 수 없다면 실물(동작 중인 시스템과 소스 코드)의 조사부터 다시 시작해야 하고, 그 공수는 견적에 그대로 얹힙니다. 문서가 보수되지 않는 것은 향후 개수 비용으로 되돌아오는 것입니다.

2.4 고객이 직접 활용할 수 없다

인쇄를 전제로 짜인 레이아웃은 화면에서 읽기 어렵습니다. 또한 내용이 다수의 시트와 도형에 분산되어 있어 전문 검색이 잘 되지 않아, ‘그 사양이 어디에 적혀 있었는지’를 찾는 데 시간이 걸립니다. 고객 측에서 운용 메모를 덧붙이거나 사내 설명 자료로 전용하는 등의 2차 활용도 어려워, 모처럼 대가를 지불한 문서가 ‘보관만 되어 있는’ 상태가 되기 쉽습니다.

3. 계약의 관점 ── 사양서는 ‘성과물’이다

형식 이야기에 들어가기 전에 한 단계 위의 이야기를 하겠습니다. 사양서·설계서는 계약에서 납입물로 정함으로써 프로그램과 같은 계약상의 성과물이 됩니다. 반대로 말하면, 계약에서 특정되지 않은 문서는 당연히 납품되는 것이라고 할 수 없습니다. IPA의 정보 시스템·모델 거래·계약서에서도 개별 계약에서 납입물을 특정하고 검수 방법과 기간을 정하는 구성으로 되어 있습니다. 모델 계약의 전체상은 별도 글 「수탁 개발·운용 보수 계약은 어떻게 맺어야 하는가 ── IPA ‘모델 거래·계약서’로 배우는 준위임과 도급의 구분」에서 설명하고 있습니다.

즉, Excel이냐 Word냐 하는 형식 논의는 다음과 같은 토대가 정해져 있어야 비로소 의미를 가집니다.

• 어느 문서가 성과물인가: ‘문서 일체’가 아니라 문서명 수준에서 목록화한다
• 어떤 형식으로 받을 것인가: 편집 가능한 원본(Word나 Excel 파일)을 포함하는가. PDF만으로는 보수 시 곤란하다
• 검수 방법: 무엇을 확인하면 받아들이는가. 수정판의 차이를 어떻게 제시할 것인가
• 저작권·2차 이용의 취급: 고객이 사내에서 복제·개변할 수 있는가. 앞으로 다른 회사에 보수를 위탁할 때 문서를 넘길 수 있는가

이 부분이 계약에서 정해져 있지 않으면, 아무리 훌륭한 형식을 선택하더라도 ‘애초에 그 문서가 납품 대상인가’로 갈등이 생깁니다. 발주 전 정리에 관해서는 「Windows 앱 외주·수탁 개발을 의뢰하기 전에 정리해야 할 것」도 참고하시기 바랍니다.

4. 납품 형식의 선택지 ── ‘납품물로서 성립하는가’로 비교한다

토대가 정해지면 형식을 선택합니다. 평가 축은 서두에서 언급한 대로 고객의 가독성 / 리뷰·검수의 용이성 / 사양 변경의 차이 관리 / 보수 단계에서의 지속성의 4가지입니다.

평가 기호의 의미는 다음과 같습니다. ‘그 형식에 도구로서 갖추어져 있는가’로 판정하며, 운용상의 궁리로 커버할 수 있는지 여부는 포함하지 않았습니다.

△를 붙인 3곳은 그 이유를 먼저 적어두겠습니다.

• Excel의 차이 관리가 △인 이유: Word의 변경 이력에 해당하는, 빨간 글씨로 차이를 보여주는 기능이 없기 때문입니다. 셀 값의 버전 기록이나 Spreadsheet Compare는 있지만, 공동 편집 환경을 전제로 하거나 도형·텍스트 상자 안의 문자는 대상 밖이거나 합니다(2.1절). 결국 ‘변경 부분 목록을 별도로 첨부한다’는 운용 규칙으로 보완하게 됩니다.
• PDF의 보수에서의 지속성이 △인 이유: 읽는 데는 문제없지만, 구조를 유지한 채 계속 갱신할 수 없기 때문에 편집 가능한 원본이 별도로 필요합니다(4.3절).
• Wiki의 보수에서의 지속성이 △인 이유: 갱신하기 쉬운 정도는 오히려 최고지만, 계약이 끝난 후 문서가 남는지 여부가 도구의 계약과 설정에 좌우되기 때문입니다. 내보내기 가능 여부, 스페이스의 소유권, 계정의 취급을 처음에 정해두지 않으면 계약 종료와 동시에 문서에 대한 접근 권한을 잃게 됩니다(4.5절).

각각을 보충 설명합니다.

4.1 Word ── 문장 중심 사양서의 제1후보

개요 설계서나 업무 흐름 설명처럼 ‘문장으로 서술하는’ 문서는 워드프로세서로 작성하는 것이 본래의 모습입니다. Word에는 납품 문서에 필요한 도구가 처음부터 갖추어져 있습니다.

• 제목 스타일과 자동 목차: 문서의 구조가 명확해지고, 목차에서 원하는 부분으로 바로 이동할 수 있다
• 변경 이력(검토 기능): 수정판의 어느 부분이 바뀌었는지가 빨간 글씨로 보인다. 리뷰와 검수의 실효성이 확연히 달라진다
• 코멘트 기능: 고객의 지적 사항과 그에 대한 답변이 문서상에 남는다
• 문서 비교: 두 버전의 차이를 나중에라도 표시할 수 있다

고객 측에서 특별한 도구도 학습도 필요 없고, 납품 형식으로 그대로 통용되는 것도 실무상 큰 이점입니다.

주의할 점은 스타일을 사용하지 않고 ‘겉모습만’ 정돈된 문서를 만들면, Word 모눈종이라고 부를 만한 같은 함정에 빠진다는 것입니다. 제목은 제목 스타일로, 레이아웃은 스페이스 연타가 아니라 서식 설정으로 만듭니다. 또한 ‘최신 버전이 어느 것인지 모르는 문제’는 Word에서도 발생하므로, 뒤에서 설명할 버전 관리 운용과 함께 사용해야 합니다.

4.2 Excel은 ‘진짜 표’로 되돌려 사용한다

화면 항목 정의서, 코드 목록, 권한 매트릭스 같은 문서는 본질적으로 표입니다. 이를 Word로 작성하는 것은 오히려 불편하며, Excel이 정답입니다. 다만 모눈종이가 아니라 데이터로 다룰 수 있는 순수한 표로 사용합니다.

• 1행이 1레코드, 1열이 1속성. 1시트에는 1개의 표만 둔다
• 셀 병합으로 레이아웃을 만들지 않는다. 제목은 첫 행에 1행
• 인쇄 시 보기 좋게 하려고 데이터 구조를 무너뜨리지 않는다(인쇄용 체재는 별도의 수단으로)

이렇게 만들어 두면 보수할 때 문서를 기계적으로 다룰 수 있습니다. 항목 정의와 실제 데이터베이스 정의를 대조하거나, 목록을 그대로 테스트 항목의 기반으로 삼는 등의 재사용이 가능해져, ‘문서가 구현과 괴리되지 않았는지 확인하는’ 작업 자체가 수월해집니다.

4.3 PDF ── ‘합의한 버전’을 고정하는 형식

PDF는 손쉽게 편집할 수 없다는 점이 단점도 되고 장점도 됩니다. 사양서의 원본으로서는 실격이지만, 검수를 통과한 버전·사양 변경으로 합의한 버전의 스냅샷으로서는 적합합니다. 실수로 내용이 바뀔 일이 없으므로 ‘이 시점에 이렇게 합의했다’는 기록으로 기능합니다.

다만 엄밀히 말하면 PDF도 다시 만들 수는 있습니다. 기록으로서의 힘은 PDF라는 형식 자체가 아니라 양측이 같은 파일을 보관하고 있다는 사실에서 나오므로, 메일로 발송해 발송 기록까지 함께 남기거나 양측의 환경에서 보관하는 등의 운용과 함께 사용하시기 바랍니다. 분쟁 시의 증거 능력까지 요구한다면 전자서명이나 타임스탬프 부여도 선택지입니다.

또 하나의 원칙은 단순합니다. PDF는 항상 편집 가능한 원본과 함께. PDF만 납품하는 것은 고객의 향후 선택지(자사에서의 활용, 타사로의 보수 위탁)를 좁힙니다.

4.4 Markdown + Git을 원본으로, Word / PDF를 생성해 납품한다

개발 회사 측의 관리 방법으로는 사양서를 Markdown으로 작성하여 소스 코드와 같은 Git 저장소에서 버전 관리하는 방식이 최근 확산되고 있습니다. 행 단위의 차이를 확인할 수 있고, 코드 리뷰와 같은 방식으로 문서 리뷰를 할 수 있으며, 변경 경위가 이력으로 남습니다(개발 실무의 기록으로는 충분하지만, 감사나 분쟁 대응의 증거까지 요구한다면 이력 재작성을 금지하는 운용 등이 별도로 필요합니다).

이때 고객에게 Git 사용을 요구할 필요는 없습니다. 원본은 Markdown으로 관리하고, 납품물은 Pandoc 등의 변환 도구로 Word나 PDF를 생성하는 구성으로 하면 고객은 지금까지처럼 Word/PDF를 받기만 하면 됩니다. 개발 측의 관리 효율과 고객 측의 가독성을 양립할 수 있습니다.

여기서 등장하는 Pandoc은 문서 형식을 상호 변환하는 무료 도구(오픈소스, 명령줄로 실행)입니다. Markdown에서 Word(.docx)나 PDF, HTML 등 다양한 형식으로 변환할 수 있으며, 자사의 로고나 제목 스타일을 넣은 Word 파일을 ‘서식’으로 지정하면 생성되는 Word를 사내 표준 체재에 맞출 수 있습니다. 도입하는 것은 개발 회사 측뿐이며, 발주 측에는 새로운 도구가 필요하지 않습니다. 이 점은 오해받기 쉬우므로 제안 시 명확히 전달해야 할 부분입니다.

흐름을 그림으로 나타내면 다음과 같습니다.

［개발 회사 측］
  사양서를 Markdown으로 작성한다
        ↓
  소스 코드와 같은 Git 저장소에서 관리한다
    ・행 단위로 차이를 확인할 수 있다
    ・코드 리뷰와 같은 방식으로 문서를 리뷰할 수 있다
    ・언제·누가·왜 변경했는지가 이력으로 남는다
        ↓
  Pandoc으로 변환한다(자사 서식의 Word 파일을 체재로 지정)
        ↓
  Word / PDF가 생성된다
        ↓
─────────── 납품 ───────────
        ↓
［발주 측］
  지금까지처럼 Word / PDF를 받아 읽고 리뷰한다
        ↓
  수정 요청은 '코멘트'로 전달한다(생성물을 직접 고치지 않는다)
        ↓
  개발 회사 측이 원본 Markdown에 반영하여 재생성 후 재납품한다

주의할 점은 ‘원본이 어느 쪽인지’를 계약상 명확히 해두는 것입니다. 생성된 Word 파일에 고객이 직접 손을 대면 원본과 분기되어 버리므로, 그림의 마지막에 있듯이 수정 요청은 코멘트로 받아 원본 측에 반영한다는 식의 운용상 약속이 필요합니다.

4.5 Wiki·온라인 도구 ── 지속적인 보수가 있는 경우의 ‘살아있는 사양서’

보수 계약이 계속되어 개수가 빈번한 시스템에서는 Notion이나 Confluence 같은 온라인 도구로 사양서를 상시 갱신해 나가는 방식도 유력합니다. 검색성이 높고 변경 이력이 자동으로 남으며, ‘납품하면 끝’이 아니라 ‘살아있는 문서’를 유지하기 쉬운 형식입니다.

다만 납품물의 관점에서 보면, 계약이 끝났을 때 무엇이 남는지를 처음에 정해 두어야 합니다. 내보내기 형식(Word나 PDF로 출력할 수 있는가), 스페이스의 소유권과 요금 부담, 열람 계정의 취급. 이 부분을 애매하게 두면 특정 도구에 대한 종속(lock-in)이 발생하여, 계약 종료와 동시에 문서에 대한 접근 권한을 잃을 위험이 있습니다.

5. 사양 변경 관련 소통을 어떻게 운영할 것인가

형식을 정비하더라도 운용이 없으면 ‘최신 버전이 어느 것인지 모르는 문제’는 재발합니다. 납품하면 끝이 아니라 개발 중에도 보수 단계에서도 사양은 계속 바뀌기 때문입니다. 권장하는 기본형은 다음과 같습니다.

1. 변경 관리 대장을 하나 마련한다: 변경 번호·날짜·내용·영향(비용/납기)·합의자를 1행으로 기록하는 목록표. 이 자체는 Excel의 순수한 표로 충분합니다. IPA 모델 계약의 변경 관리 절차(앞서 언급한 글 참조)와 대응시킵니다
2. 문서 수정은 차이가 보이는 형태로 주고받는다: Word라면 변경 이력을 켠 상태로 수정판을 보내고, 고객은 빨간 글씨를 중심으로 확인한다. 변경 이력 표시 누락이 불안하다면, 받은 쪽이 Word의 ‘비교’ 기능으로 이전 합의판과 대조하면 누락도 검출할 수 있습니다. 합의되면 이력을 반영하여 버전을 확정합니다
3. 버전 번호 규칙을 정한다: 검수판을 v1.0으로 하고, 변경 합의가 있을 때마다 v1.1, v1.2로 올린다. ‘최종’, ‘수정’, ‘(2)’ 같은 표현을 파일명에 사용하지 않는다
4. 합의한 버전은 PDF로 고정하여 양측이 보관한다: 어느 버전에서 합의했는지를 나중에 누구나 특정할 수 있게 합니다

도구가 무엇이든 이 4가지가 잘 운영되고 있다면 ‘어디가 바뀌었는지 모른다’, ‘어느 것이 합의판인지 모른다’는 2대 문제는 거의 방지할 수 있습니다. 반대로 말하면, 도구 선정보다 운용 규칙의 합의 쪽이 본질입니다.

6. 발주 측이 계약 전에 확인해 두고 싶은 것

발주하는 측을 위해, 견적·계약 단계에서 확인해야 할 사항을 체크리스트로 정리합니다.

• 성과물 목록에 사양서·설계서가 문서명 수준으로 포함되어 있는가(‘문서 일체’로 되어 있지 않은가)
• 편집 가능한 원본(Word/Excel 파일 등)으로 받을 수 있는가. PDF만으로 되어 있지 않은가
• 수정판을 받을 때 어디가 바뀌었는지 알 수 있는 형태(변경 이력·변경 부분 목록)로 제시되는가
• 보수 계약의 범위에 개수 시 문서 갱신이 포함되는가. 포함되지 않는다면 괴리가 진행되는 것을 전제로 해도 괜찮은가
• 문서의 저작권·2차 이용의 취급. 앞으로 다른 회사에 보수를 위탁할 때 문서를 넘길 수 있는가
• 사양 변경 절차(변경 관리 대장·합의 기록 방법)가 정해져 있는가

수탁 측의 관점에서도 이 목록은 그대로 견적 정리에 활용할 수 있습니다. 어느 문서를 어느 정도의 상세도로 작성할지는 공수이며 금액입니다. 성과물의 범위를 애매하게 둔 채 수주하면, 납품 직전에 ‘이 문서도 당연히 포함되는 줄 알았다’는 엇갈림이 발생합니다. 문서 목록과 형식을 처음에 합의해 두는 것은 양측을 보호합니다.

정리

수탁 개발에서 납품하는 사양서에 관해, 이 글의 요점을 정리합니다.

• 납품하는 사양서의 형식은 검수·사양 변경·보수의 관점에서 선택한다. ‘개발 중에 쓰기 쉬운가’만으로 선택하지 않는다
• Excel 모눈종이의 본질적인 문제는 차이가 보이지 않아 발생하는 검수의 형해화, 합의 기록의 상실, 갱신 비용의 높음에 따른 구현과의 괴리
• 결론은 ‘Excel 전면 폐지’가 아니라 적재적소로의 회귀. 문장은 Word(스타일+변경 이력), 표는 Excel의 순수한 표, 합의 기록은 PDF 고정
• 개발 측의 원본을 Markdown+Git으로 관리하고, 납품물로서 Word/PDF를 생성하는 구성은 양측의 이점을 양립할 수 있다
• 형식보다 먼저, 성과물 목록·편집 가능한 원본의 납품·저작권의 취급을 계약으로 정한다. 도구보다 운용 규칙의 합의가 본질

참고로 Excel을 프로그램에서 읽고 쓰는 이야기(장표 출력)는 「Excel 장표 출력을 어떻게 만들까 - COM 자동화 / Open XML / 템플릿 방식의 판단표」에서, 계약의 구성은 IPA 모델 거래·계약서 해설 글에서 다루고 있습니다. 함께 참고해 보시기 바랍니다.

참고 링크

• IPA 정보 시스템·모델 거래·계약서 ─ 제3장에서 언급한, 납입물의 특정·검수 방법과 기간·변경 관리 절차를 정하는 계약의 서식. 발주 측·수탁 측 모두 무료로 입수할 수 있습니다
• IPA 「정보 시스템·모델 거래·계약서」 제2판(민법 개정을 반영한 개정) ─ 현행 제2판과 그 해설
• Pandoc ─ 4.4절에서 언급한 문서 변환 도구의 공식 사이트. 지원 형식 목록과 Word 서식 지정을 포함한 사용법
• IPA 비기능 요구 등급 ─ 사양서에 빠뜨리기 쉬운 비기능 요건 정리에. 해설은 별도 글

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

합동회사 코무라소프트에서는 Windows 업무 애플리케이션의 수탁 개발을 맡을 때, 이 글에서 소개한 사고방식으로 성과물 문서의 범위·형식·갱신 운용을 처음에 발주 측과 합의하도록 하고 있습니다. 또한 기존 소프트웨어의 개수에서는 ‘사양서는 있지만 현재 상태와 맞는지 알 수 없는’ 상태로부터의 조사도 맡고 있습니다. 사양서 정비나 납품 형식 재검토를 포함하여 편하게 상담해 주시기 바랍니다.

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

발주처로부터 Excel 모눈종이 템플릿을 지정받았습니다. 따를 수밖에 없나요?

납품 형식 지정을 따르는 것 자체는 수탁 측의 의무이지만, 지정의 목적을 확인해 볼 가치는 있습니다. 사내 문서 표준이나 감사 대응이 목적이라면 같은 내용을 Word 양식으로 충족할 수 없는지 제안할 여지가 있고, 템플릿이 오래된 관행으로 남아 있을 뿐인 경우도 적지 않습니다. 지정을 바꿀 수 없는 경우에도 수정판에 '변경 부분 목록'을 첨부하거나 합의한 버전을 PDF로 고정하는 등 운용상의 궁리로 차이가 보이지 않는 문제의 상당 부분을 완화할 수 있습니다.

사양서가 PDF로만 납품되었습니다. 문제없나요?

그 시점에서는 읽을 수 있으니 문제로 보이지 않지만, 보수·개수 단계에서 곤란해집니다. PDF 편집은 전용 도구로 불가능한 것은 아니지만, Word나 Excel 원본처럼 구조를 유지한 채 계속 갱신하는 것은 현실적이지 않아, 사양 변경이 있을 때마다 구현과의 괴리가 진행됩니다. 또한 앞으로 다른 회사에 보수를 맡길 경우에도 편집 가능한 원본이 없으면 문서를 인계하기 어려워집니다. 계약 시에 '편집 가능한 형식(Word나 Excel 원본)을 포함하여 납품한다'는 것을 성과물의 조건으로 명기해 두는 것이 확실합니다. 이미 PDF로만 받은 경우에는 원본 제공을 개발 회사에 상담해 보시기 바랍니다.

사양서는 어느 정도까지 상세하게 작성해야 하나요?

'상세할수록 좋다'는 것은 아닙니다. 상세한 문서일수록 갱신 비용이 높아, 보수 단계에서 구현과 괴리되기 쉽기 때문입니다. 기준은 검수의 근거로 사용할 수 있을 정도로 동작이 특정되어 있는 것, 그리고 보수·개수 시에 참조되는 정보(화면 항목, 데이터 구조, 외부 연계, 업무 규칙)가 남아 있는 것입니다. 반대로 코드를 읽으면 알 수 있는 구현의 세세한 설명은 문서보다 코드와 주석에 남기는 편이 괴리가 적습니다. 어느 문서를 어느 정도의 상세도로 작성할지는 공수, 즉 견적 금액에 직결되므로 계약 전에 맞춰 두어야 할 항목입니다.

납품 후 사양서의 갱신은 누구의 책임인가요?

계약에 따라 다릅니다. 보수 계약의 범위에 '개수 시 설계 문서의 갱신'이 포함되어 있다면 수탁 측의 작업이고, 포함되어 있지 않다면 개수 때마다 문서 갱신을 별도로 발주하거나 괴리가 진행되는 것을 전제로 다루게 됩니다. 문제가 되기 쉬운 것은 이 점을 정하지 않은 채 '당연히 갱신되어 있을 것'이라고 양쪽이 생각하고 있는 경우입니다. 보수 계약을 맺을 때 어느 문서를 보수 대상으로 할지 문서명 수준에서 명기해 둘 것을 권장합니다.

저자 프로필

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

Go Komura

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

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