기술 보고서를 고객용과 제조사용으로 어떻게 나눠 쓰나요?

이 글은 고객과 제품 제조사, 두 외부 독자에게 가는 서비스 보고서, 시험 보고서, 고객 불만 보고서, 고장 보고서를 다룹니다. 물질안전보건자료(SDS)처럼 법이나 계약으로 내용이 정해진 문서는 다루지 않습니다. 법률 관련 내용은 방향을 잡기 위한 것이며, 특정 관할 지역에 대한 법률 자문이 아닙니다.

기술 보고서를 독자별로 맞춰 쓰기 전에 무엇이 필요한가요?

기술 보고서를 독자별로 맞춰 쓰기 전에, 완성된 사내 분석, 모든 독자의 목록, 독자마다 적은 목적 한 가지가 있어야 합니다. PDHonline의 기술 보고서 작성 과정은 보고서에 명확한 목적과 분명한 독자가 있어야 하며, 왜 쓰는지와 누가 읽는지를 아는 것이 보고서 설계의 바탕이라고 설명합니다(PDHonline G102, accessed 2026). Texas A&M의 전문 작문 교재는 초안을 쓰기 전에 독자를 정해야 한다고 덧붙입니다. 이 교재는 사내 보고서와 외부 보고서를 구분하며, 외부 보고서는 신뢰도 함께 얻어야 한다고 봅니다(Texas A&M Professional Writing, accessed 2026). 고객과 제조사가 함께 걸린 케이스라면, 먼저 사내 파일에 다섯 가지를 모읍니다. 첫째, 확정된 결론입니다. 확인된 부분과 확인되지 않은 부분을 나눠 적습니다. 둘째, 결론의 근거가 되는 기록입니다. 시험 보고서, 시험성적서(CoA), 방문 기록이 여기에 들어갑니다. 셋째, 독자입니다. 회사 팀, 고객사의 엔지니어나 관리자, 제조사의 기술팀입니다. 넷째, 외부 독자마다 그 독자가 결정하거나 해야 할 일을 적은 문장 한 개입니다. 다섯째, 제조사 버전에서 고객 이름 대신 쓸 케이스 코드입니다. 예를 들면 "Case 2026-114"(예시)입니다. 결론이 아직 바뀌고 있다면 기다리는 것이 좋습니다. 확정되지 않은 분석으로 쓴 버전은 모두 두 번 고쳐야 합니다.

기술 보고서 하나를 고객용과 제조사용으로 나눠 쓰는 단계

기술 보고서 하나를 고객용과 제조사용으로 나눠 쓰는 일은 번호를 붙인 4단계로 진행하며, 케이스마다 각 단계를 한 번씩 합니다.

1. 사내 분석을 파일 1개로 마무리합니다. 결론, 근거, 미결 사항, 사내 검토 이력을 담습니다.

2. 외부용 문장을 쓰기 전에, 아래 공개 범위 표로 독자별 범위를 정합니다. 독자마다 열을 1개씩 둡니다.

3. 각 외부 버전은 다른 버전이 아니라 사내 파일을 바탕으로 씁니다. 그러면 외부 버전 2개가 원본 1개에서 나옵니다.

4. 발송하는 파일마다, 그 파일을 쓰지 않은 다른 사람이 아래쪽 점검 표로 공개 내용을 검토합니다.

짧은 케이스라도 4단계를 이 순서대로 지킵니다. 2단계를 건너뛰면 고객 이름이 제조사에 가장 쉽게 넘어갑니다.

아래 공개 범위 표를 보면 독자별 기술 보고서 버전에 무엇을 넣고, 줄이고, 뺄지 정할 수 있습니다.

두 외부 버전을 가르는 줄은 고객 식별 정보입니다. 고객 버전은 이 정보를 그대로 두고, 제조사 버전은 케이스 코드로 바꿉니다.

기술 보고서를 독자마다 손으로 다시 쓰면 왜 정보가 새나요?

기술 보고서를 독자마다 손으로 다시 쓰면 정보가 샙니다. 대개 앞 버전을 고쳐 다음 버전을 만드는데, 고칠 때마다 원래 독자의 흔적이 남을 수 있기 때문입니다. 흔히 사내 초안에서 고객 버전을, 고객 버전에서 제조사 버전을 만듭니다. 그러면 고객 이름이 머리글, 파일명, 현장 간판이 찍힌 사진 캡션, "고객사 정비팀과 합의한 대로" 같은 문장에 남습니다. 숨은 내용도 함께 넘어갑니다. Microsoft의 Document Inspector 안내에 따르면, 변경 내용 추적의 수정 표시, 메모, 버전 정보 때문에 문서 작업자의 이름과 검토자의 메모가 다른 사람에게 보일 수 있고, 이는 팀 밖에 공유하고 싶지 않은 내용일 수 있습니다(Microsoft Support, accessed 2026). 고치는 사이에 내용도 달라집니다. 고객용으로 반올림한 값이나, 고객 서신을 짧게 하려고 뺀 단서가 고친 그대로 제조사에 갑니다. 그러면 두 외부 독자가 한 케이스에 대해 서로 다른 사실을 받게 됩니다. 두 외부 버전을 모두 사내 파일에서 쓰면 두 문제가 함께 풀립니다. 버전마다 깨끗한 상태에서 시작하고, 수치, 시험 방법, 결론을 한 곳에서 옮겨 오기 때문입니다. 사내 분석이 바뀌면 한 버전만 고치고 다른 버전을 잊는 대신, 사내 분석을 먼저 고친 다음 두 버전을 다시 만듭니다.

제조사용 기술 보고서에서는 고객에 관한 어떤 내용을 빼야 하나요?

제조사용 기술 보고서에서는 고객을 알아볼 수 있는 내용을 모두 빼야 합니다. 회사명, 현장, 직원 이름, 주문 번호, 그리고 이런 정보가 드러나는 사진이나 파일명입니다. 제조사 기술팀에 필요한 것은 제품, 로트 또는 배치 번호, 시험성적서, 보관 조건과 적용 조건, 시험 방법, 결과, 경과 일정입니다. 제품이 누구의 공장에서 문제를 일으켰는지까지 알아야 하는 경우는 드뭅니다. 고객 이름을 밝히는 공급사는 고객이 믿고 맡긴 정보를 넘기는 것일 수 있습니다. 고객 대신 케이스 코드를 쓰고, 코드와 고객을 잇는 대응표는 사내 파일에만 둡니다. 다만 제조사에 필요한 로트 번호는 제조사 자체의 출하 기록을 거쳐 고객을 가리킬 수 있습니다. 그러니 케이스 코드는 문서에서 이름을 빼는 방법으로 다루고, 제조사가 고객을 알아낼 수 없다는 약속으로 여기지 않습니다. 보고서에 사람 이름이 나온다면, EU GDPR은 가명처리를 따로 보관한 추가 정보 없이는 개인정보를 더 이상 특정인과 연결할 수 없도록 처리하는 것으로 정의합니다(Regulation (EU) 2016/679, Article 4(5)). 제5조(1)(c)는 개인정보를 목적에 필요한 범위로 제한합니다. 라인 속도, 배합, 세척 순서 같은 고객 공정 세부 사항은 그 중간에 있습니다. 진단에 필요한 내용만 넣고, 계약이 그 내용을 다루고 있다면 먼저 고객에게 묻습니다. 고객 버전에서 뺄 내용은 별개의 질문이며, 고객용 기술 보고서에서 뺄 내용을 다룬 가이드에서 설명합니다.

고객용과 제조사용 기술 보고서는 용어를 어떻게 달리해야 하나요?

고객용과 제조사용 기술 보고서의 용어는 사실이 아니라 설명에서 달라야 합니다. 두 버전에는 같은 값, 단위, 시험 방법이 들어가고, 그 주변의 표현만 바뀝니다. 제조사 기술팀은 대개 작성자와 같은 분야에서 일하므로, 제조사 버전에는 정확한 용어, 시험 방법 번호, 제조사 자체의 제품 코드를 설명 없이 써도 됩니다. 고객 버전은 누가 읽느냐에 따라 달라집니다. 영국 셰필드 대학교(University of Sheffield)가 인용한 엔지니어링 컨설팅 회사의 한 부디렉터는, 비기술 독자에게는 쓰는 용어를 바꿔야 하지만 수준을 낮추라는 뜻이 아니라 분명하게 설명하라는 뜻이라고 말합니다. 기술 독자에게도 용어집을 두고, 약어는 처음 나올 때 풀어 쓰라고 권합니다(University of Sheffield, accessed 2026). Texas A&M 교재도 같은 점을 짚습니다. 내용과 표현을 독자마다 맞춰야 한다는 것입니다(Texas A&M Professional Writing, accessed 2026). 실무에서는 사내 파일에 용어집을 하나 두고, 버전마다 쉬운 설명이 필요한 용어를 정합니다. 측정 결과를 "약간 높음"처럼 더 모호한 말로 바꾸지 않습니다. 숫자를 방법과 함께 쓰고, 불확도가 있으면 불확도도 씁니다. JCGM 100:2008은 측정 결과를 보고할 때 품질을 정량적으로 나타내는 것을 필수로 보기 때문입니다(JCGM, 2008).

기술 보고서의 버전마다 발송 전에 어떻게 점검하나요?

기술 보고서의 버전마다 발송 전 점검은 실제로 나갈 파일 그대로 하고, 그 파일을 쓰지 않은 다른 사람이 맡습니다. 외부 버전마다 한 번씩 점검하고, 누가 어느 버전을 언제 점검했는지 사내 파일에 기록합니다. 아래 점검 표를 보면 버전을 보내도 되는지, 무엇을 먼저 고쳐야 하는지 정할 수 있습니다.

가장 자주 불합격하는 줄은 제조사 버전의 고객 식별 정보입니다. 본문을 읽는 사람이 보지 않는 곳, 즉 파일명, 이미지 캡션, 문서 속성에 숨어 있기 때문입니다. 점검을 마친 뒤에야 파일을 PDF로 내보내고, 보내기 전에 PDF의 문서 속성을 한 번 더 엽니다. 어느 항목에서든 불합격한 버전은 발송용으로 준비한 파일을 급히 고치지 말고 3단계로 돌아갑니다. Microsoft는 문서 속성에 작성자, 주제, 제목 같은 정보가 들어 있다고 설명합니다(Microsoft Support, accessed 2026).

제조사에 보내는 기술 보고서는 언제 법무 담당자가 봐야 하나요?

제조사에 보내는 기술 보고서에 고객이 비밀유지계약(NDA)에 따라 공유한 정보, 개인정보, 보증 청구로 읽힐 수 있는 문장, 분쟁에서 증거가 될 수 있는 내용이 있으면 법무 담당자가 봐야 합니다. EU 영업비밀 지침은 보유자가 비밀로 유지하기 위한 합리적인 조치를 취한 경우에만 영업 정보를 보호합니다(Directive (EU) 2016/943, Article 2). 계약을 확인하지 않고 고객의 공정 세부 사항을 제3자에게 넘기면, 고객 입장에서는 그 조치가 약해질 수 있습니다. 제조사를 상대로 한 배상 청구로 번질 수 있는 고객 불만도 독자를 바꿉니다. 나중에 엔지니어뿐 아니라 변호사와 보험사도 보고서를 읽을 수 있기 때문입니다. 이런 경우에는 보내기 전에 문구를 검토받고, 사내 파일, 케이스 코드 대응표, 발송한 각 버전을 함께 보관합니다. 루빈플라의 문서 작성 스킬은 태스크를 제안할 때 독자(사내, 고객사 담당자, 제품 제조사 기술팀)를 정하고, 외부 버전에서는 작업 이력, 신뢰도 점수, 사내 기록 출처를 뺍니다. 독자가 제조사일 때는 작성 규칙에 고객 식별 정보를 지우라는 지시가 들어 있고, 승인 전에 사람이 이를 확인합니다. 어떤 도구를 쓰든, 버전마다 승인하는 사람은 독자 범위를 확정한 사람이어야 합니다.