수탁 개발의 사양서, Excel 그대로 둬도 될까 ── 납품물 형식을 고르는 법

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

「개수를 맡기려 했더니, 납품받아 둔 Excel 사양서가 지금 화면과 전혀 달랐다」

「개발사에서 모눈종이처럼 칸을 나눈 Excel 사양서가 왔는데, 이게 보통인가」

시스템 개발을 외부에 맡기면 프로그램과 함께 사양서·설계서가 납품됩니다. 일본의 수탁 개발에서는 이 문서를 Excel로 만드는 경우가 매우 많고, 흔히 「Excel 모눈종이」라고 부르는, 셀을 잘게 나눠 원고지처럼 쓰는 스타일로 작성됩니다.

Excel 모눈종이에 대한 비판은 인터넷에 많지만, 대부분은 개발팀 내부 문서로서 쓰기 어렵다는 이야기에 머뭅니다. 이 글에서는 시선을 바꿔, 수탁 개발에서 고객에게 납품하는 사양서에 한정해, 무엇이 문제이고 어떤 형식을 고를지를 검수·사양 변경·유지보수라는 계약 실무의 말로 정리합니다. 발주하는 쪽과 납품하는 개발사 양쪽에게 도움이 되는 내용을 목표로 합니다.

1．먼저 결론

먼저 요점을 정리합니다.

• 납품하는 사양서의 형식은 「개발 중에 쓰기 쉬운가」가 아니라, 「고객이 리뷰할 수 있는가」「검수에 견딜 수 있는가」「사양 변경의 차이를 공유할 수 있는가」「몇 년 뒤 유지보수에서 쓸 수 있는가」로 고른다
• 결론은 「Excel을 버린다」가 아니라 「모눈종이를 그만두고, 용도에 맞게 되돌린다」입니다. 글은 Word, 표는 Excel 본래의 표, 그림은 다이어그램 도구, 합의 기록은 PDF
• 형식 논의에 들어가기 전에, 어떤 문서를 성과물로 할지·편집 가능한 원본을 받을 수 있는지를 계약(개별 계약에서 납품물을 특정)으로 정해 둔다

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

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

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

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

먼저 분명히 하면, Excel이라는 소프트웨어가 나쁜 것은 아닙니다. 표 계산·목록을 다루는 도구로서 Excel은 뛰어나고, 뒤에서 말하듯 항목 정의서 등에서는 Excel이 정답입니다. 문제는 글도 그림도 표도, 성격이 다른 것을 전부 「모눈종이」에 밀어 넣고 있다는 점입니다.

사내 내부 문서라면 「쓴 사람들만 고생하는」 문제에 그칩니다. 그러나 납품물이 되면 이야기가 달라집니다. 사양서는 고객이 대가를 내고 받는 성과물이며, 검수 대상이고, 그 후 몇 년이고 쓰는 자산이기 때문입니다. 납품물 관점에서 보면 Excel 모눈종이에는 다음 문제가 있습니다.

2.1 검수에서 리뷰를 끝까지 할 수 없다

Excel 모눈종이에는 Word의 변경 내용 추적처럼 실무에서 쓸 만한 차이 표시 장치가 없습니다. 정확히 말하면, Microsoft 365의 공동 편집 환경에는 셀 변경 이력(「변경 내용 표시」나 버전 기록)이 있고, 통합 문서끼리 비교하는 Spreadsheet Compare 같은 도구도 있습니다. 다만 추적되는 것은 셀 값이나 수식이 중심이고, 모눈종이 문서가 많이 쓰는 도형·텍스트 상자 안의 글자는 대상이 아닙니다. 메일 첨부로 파일을 주고받는 납품 현장에서는 공동 편집 이력 자체가 동작하지 않습니다.

결국 리뷰 지적을 반영한 수정본을 받았을 때, 고객은 「어디가 바뀌었는지」를 눈으로 찾게 됩니다. 시트가 수십 장인 문서를 매번 처음부터 다시 읽는 일은 비현실적이라, 실제로는 「아마 고쳤겠지」라는 심정으로 검수 도장을 찍게 됩니다.

이것은 검수가 유명무실해지는 일입니다. 검수는 「납품물이 합의한 내용과 같은지 확인하고 받아들이는」 절차입니다. 여기가 형식만 남으면, 나중에 문제가 나왔을 때 「검수를 통과시키지 않았느냐」「아니, 확인할 수 있는 형태로 납품되지 않았다」는 공허한 논쟁이 됩니다.

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

개발 도중에 사양은 반드시 바뀝니다. 그때 문서가 Excel 모눈종이이면, 변경 주고받기가 「파일 복사 더미」가 되기 쉽습니다. 仕様書_v2_最終_修正(2).xlsx 같은 파일명에 익숙한 분이 많을 것입니다.

문제는 어느 판이 「양쪽이 합의한 판」인지 나중에 특정할 수 없다는 점입니다. 추가 비용이나 납기를 두고 의견이 갈릴 때, 근거가 되는 것은 합의한 문서입니다. 그 문서가 어느 것인지 모르면 평행선만 달리는 논쟁이 됩니다.

2.3 유지보수 단계에서 구현과 어긋난다

모눈종이 문서는 갱신 비용이 커서, 납품 후 개수에서는 점점 갱신되지 않습니다. 레이아웃이 깨질까 봐 아무도 손대지 않고, 도형 안 글자는 검색에 잡히지 않아 수정을 빠뜨리는 일이 쌓입니다. 몇 년 뒤에는 「사양서는 있는데, 현황과 맞는지 아무도 모른다」는 상태가 됩니다.

이 빚을 갚는 시점은 다음 개수입니다. 문서를 믿을 수 없으면 실물(돌아가는 시스템과 소스 코드) 조사부터 다시 하게 되고, 그 공수는 견적에 올라갑니다. 문서가 유지되지 않으면, 그 부담은 장래 개수 비용으로 돌아옵니다.

2.4 고객 손에서 활용할 수 없다

인쇄를 전제로 짠 레이아웃은 화면에서 읽기 어렵습니다. 내용이 수많은 시트와 도형에 흩어져 있어 전체 텍스트 검색도 잘 되지 않고, 「그 사양이 어디에 적혀 있었는지」를 찾는 데 시간이 걸립니다. 고객 쪽에서 운용 메모를 덧붙이거나 사내 설명 자료로 재사용하는 이차 활용도 어려워, 대가를 치른 문서가 「보관만 되는」 신세가 되기 쉽습니다.

3．계약의 관점 ── 사양서는 「성과물」이다

형식 이야기에 들어가기 전에, 한 단계 위의 이야기를 합니다. 사양서·설계서는 계약에서 납품물로 정해야 프로그램과 같은 계약상 성과물이 됩니다. 거꾸로 말하면, 계약에서 특정하지 않은 문서는 당연히 납품된다고 볼 수 없습니다. IPA의 정보시스템·모델 거래·계약서에서도, 개별 계약에서 납품물을 특정하고 검수 방법과 기간을 정하는 구성입니다. 모델 계약의 전체 그림은 별도 글 「수탁 개발·운용 유지보수 계약은 어떻게 맺을까 ── IPA 『모델 거래·계약서』로 보는 준위임과 도급의 구분」에서 설명합니다.

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

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

여기가 계약에 없으면, 형식을 아무리 잘 골라도 「애초에 그 문서가 납품 대상인가」로 다툽니다. 발주 전 정리에 대해서는 「Windows 앱 외주·수탁 개발을 맡기기 전에 정리할 것」도 참고하시기 바랍니다.

4．납품 형식의 선택지 ── 「납품물로 성립하는가」로 비교한다

토대가 정해지면 형식을 고릅니다. 평가 축은 서두에서 말한 대로 고객이 읽기 쉬운가 / 리뷰·검수가 쉬운가 / 사양 변경의 차이 관리 / 유지보수 단계에서의 지속성 네 가지입니다.

평가 기호의 의미는 다음과 같습니다. 「그 형식에 도구로서 갖춰져 있는가」로 판정하며, 운용으로 보완할 수 있는지는 넣지 않았습니다.

△를 붙인 세 곳은 이유를 먼저 적습니다.

• Excel의 차이 관리가 △인 이유: Word의 변경 내용 추적처럼 빨간 글씨로 차이가 보이는 장치가 없기 때문입니다. 셀 값의 버전 기록이나 Spreadsheet Compare는 있지만, 공동 편집 환경이 전제이거나 도형·텍스트 상자 안 글자는 대상이 아닙니다(2.1절). 결국 「변경 위치 목록을 따로 붙인다」는 운용 규칙으로 보완하게 됩니다.
• PDF의 유지보수 지속성이 △인 이유: 읽는 데는 문제가 없지만, 구조를 유지한 채 계속 고칠 수 없어 편집 가능한 원본이 따로 필요합니다(4.3절).
• Wiki의 유지보수 지속성이 △인 이유: 고치기 쉬운 정도는 오히려 최고이지만, 계약이 끝난 뒤에 문서가 남는지는 도구의 계약과 설정에 달려 있기 때문입니다. 내보내기 가능 여부, 스페이스 소유권, 계정 취급을 처음에 정하지 않으면, 계약 종료와 함께 문서 접근을 잃습니다(4.5절).

각각을 보충합니다.

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

개요 설계서나 업무 흐름 설명처럼 「글로 말하는」 문서는 워드프로세서로 쓰는 것이 본래 모습입니다. Word에는 납품 문서에 필요한 도구가 처음부터 갖춰져 있습니다.

• 제목 스타일과 자동 목차: 문서 구조가 분명해지고, 목차에서 목적 위치로 이동할 수 있다
• 변경 내용 추적(검토 기능): 수정본의 어디가 바뀌었는지가 빨간 글씨로 보인다. 리뷰와 검수의 실효가 전혀 달라진다
• 메모 기능: 고객의 지적과 그에 대한 답이 문서 위에 남는다
• 문서 비교: 두 판의 차이를 나중에라도 표시할 수 있다

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

주의점은, 스타일을 쓰지 않고 「겉모습만」 맞춘 문서를 만들면, Word 모눈종이라 부를 같은 함정에 빠진다는 것입니다. 제목은 제목 스타일로, 레이아웃은 스페이스를 연타하지 말고 서식 설정으로. 또한 「최신판이 어느 것인가」 문제는 Word에서도 생기므로, 뒤에서 말하는 판 관리 운용과 함께 씁니다.

4.2 Excel은 「진짜 표」로 되돌려 쓴다

화면 항목 정의서, 코드 목록, 권한 매트릭스 같은 문서는 본질이 표입니다. 이것을 Word로 쓰면 오히려 불편하고, Excel이 정답입니다. 다만 모눈종이가 아니라, 데이터로 다룰 수 있는 본래의 표로 씁니다.

• 한 행이 한 레코드, 한 열이 한 속성. 시트 하나에는 표 하나만 둔다
• 셀 병합으로 레이아웃을 만들지 않는다. 머리글은 첫 행에 한 줄
• 인쇄 모양 때문에 데이터 구조를 깨지 않는다(인쇄용 서식은 다른 수단으로)

이렇게 만들어 두면 유지보수 때 문서를 기계적으로 다룰 수 있습니다. 항목 정의와 실제 데이터베이스 정의를 맞춰 보거나, 목록을 시험 항목의 바탕으로 쓰는 식의 재사용이 가능해지고, 「문서가 구현과 어긋나지 않았는지 확인」 자체도 수월해집니다.

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로 내보낼 수 있는지), 스페이스 소유권과 요금 부담, 열람 계정 취급. 여기를 모호하게 두면 특정 도구에 락인이 생기고, 계약 종료와 함께 문서 접근을 잃을 위험이 있습니다.

5．사양 변경의 주고받기를 어떻게 돌릴 것인가

형식을 갖춰도 운용이 없으면 「최신판이 어느 것인가」 문제는 다시 생깁니다. 납품하고 끝이 아니라, 개발 중에도 유지보수 단계에서도 사양은 계속 바뀌기 때문입니다. 권하는 기본형은 다음과 같습니다.

1. 변경 관리 대장을 하나 둔다: 변경 번호·날짜·내용·영향(비용/납기)·합의자를 한 행으로 기록하는 목록. 이것 자체는 Excel의 본래 표로 충분합니다. IPA 모델 계약의 변경 관리 절차(앞에서 든 글 참조)와 대응시킵니다
2. 문서 수정은 차이가 보이는 형태로 주고받는다: Word라면 변경 내용 추적을 켜고 수정본을 보내고, 고객은 빨간 글씨를 중심으로 확인합니다. 추적을 빠뜨릴까 걱정되면, 받은 쪽이 Word의 「비교」 기능으로 직전 합의판과 맞춰 보면 누락도 잡을 수 있습니다. 합의하면 이력을 반영해 판을 확정합니다
3. 판 번호 규칙을 정한다: 검수판을 v1.0으로 두고, 변경 합의마다 v1.1, v1.2로 올립니다. 「최종」「수정」「(2)」를 파일명에 쓰지 않습니다
4. 합의한 판은 PDF로 고정하고 양쪽이 보관한다: 어느 판으로 합의했는지를 나중에 누구나 특정할 수 있게 합니다

도구가 무엇이든, 이 네 가지가 돌아가면 「어디가 바뀌었는지 모른다」「어느 것이 합의판인지 모른다」는 두 가지 큰 문제는 거의 막을 수 있습니다. 거꾸로 말하면, 도구 선정보다 운용 규칙의 합의가 본체입니다.

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

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

• 성과물 목록에 사양서·설계서가 문서명 수준으로 들어가 있는가(「문서 일체」가 되어 있지 않은가)
• 편집 가능한 원본(Word/Excel 파일 등)으로 받을 수 있는가. PDF만으로 되어 있지 않은가
• 수정본을 받을 때, 어디가 바뀌었는지 알 수 있는 형태(변경 내용 추적·변경 위치 목록)로 제시되는가
• 유지보수 계약 범위에 개수 시 문서 갱신이 포함되는가. 포함되지 않는다면 점점 어긋나는 전제로 괜찮은가
• 문서의 저작권·이차 이용 취급. 나중에 다른 회사에 유지보수를 맡길 때 문서를 넘길 수 있는가
• 사양 변경 절차(변경 관리 대장·합의를 남기는 방법)가 정해져 있는가

수탁 측 관점에서도, 이 목록은 그대로 견적 정리에 쓸 수 있습니다. 어떤 문서를 어느 상세도로 쓸지는 공수이며, 금액입니다. 성과물 범위를 모호하게 둔 채 수주하면, 납품 직전에 「이 문서도 당연히 포함되는 줄 알았다」는 어긋남이 생깁니다. 문서 목록과 형식을 처음에 합의해 두는 일은 양쪽을 지킵니다.

정리

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

• 납품하는 사양서의 형식은 검수·사양 변경·유지보수의 관점으로 고른다. 「개발 중에 쓰기 쉬운가」만으로 고르지 않는다
• 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.