핵심노트 · 주제 06-02

테크니컬 커뮤니케이션

이게 뭔가요?

기술과 관련된 일을 상대가 이해하고 다음 행동을 할 수 있게 설명하고, 서로 확인하는 방법을 배웁니다. 질문과 대화로 요구를 파악하고, 문서와 발표로 전달하며, 합의한 내용을 기록하는 일입니다. 식당 직원이 “예약은 50명까지”라고 하면 하루 전체인지 시간대별인지 확인하는 것도 여기에 해당합니다.

왜 배우나요?

같은 말을 듣고도 서로 다른 결과를 생각하면 잘못 만든 뒤 다시 고치게 됩니다. 개발자에게는 구현 조건을, 식당 직원에게는 사용 방법과 업무에 미치는 영향을 이해할 수 있게 설명해야 합니다. 말의 뜻과 완료 기준을 맞추고, 함께 판단하고 일할 수 있도록 배우는 과목입니다.

상대가 기술 내용을 이해해 필요한 행동과 판단을 할 수 있도록 설명·문서·대화를 설계합니다.

교재 개념의 뜻을 설명하고, 가상 업무에서 언제 왜 쓰는지 풀어 쓴 자체 해설입니다. 먼저 설명과 예시를 읽고, 확인 질문에 자신의 말로 답해 보세요. 각 항목의 관련 교재 내용에서 단원과 교재 페이지를 확인할 수 있습니다. 20개 노트는 교재 전체 요약이나 시험 중요도 순위가 아니며, 주제 끝의 추가 학습 내용도 함께 확인하세요.

1. 독자와 목적 — 읽고 무엇을 하게 할지 정한다

기술을 설명할 때는 누가 읽고, 읽은 뒤 무엇을 해야 하는지부터 정합니다. 같은 장애라도 고객과 복구 담당자에게 필요한 정보는 다릅니다.

고객에게는 지금 이용할 수 없는 기능과 다음 안내 시점이 필요합니다. 복구 담당자에게는 확인할 기록과 조치 순서가 필요합니다. 독자의 지식과 다음 행동을 정하면 아는 내용을 모두 나열하는 대신 필요한 설명부터 제공할 수 있습니다.

가상 업무 예시

택배 조회가 멈췄을 때 고객에게는 ‘배송은 진행 중이며 조회 화면만 사용할 수 없습니다. 오후 3시에 다시 안내하겠습니다’라고 알립니다. 복구 담당자에게는 ‘오후 1시 배포 뒤 조회 오류 증가, 이전 버전과 응답 기록 비교 필요’를 전달합니다. 같은 사건도 고객의 기다림과 운영자의 조사라는 다음 행동이 달라 필요한 설명이 다릅니다.

생각해 볼 질문
이 문서를 읽은 고객이나 운영자는 무엇을 결정하거나 실행해야 하나요? 그 행동에 필요한 내용을 먼저 설명했나요?

2. 공통 용어 — 같은 말을 같은 뜻으로 쓴다

공통 용어는 여러 사람이 같은 상황을 같은 말로 부르도록 정한 표현입니다. 익숙한 단어라도 팀마다 뜻이 다르면 설명을 듣고 서로 다른 행동을 할 수 있습니다.

‘처리 완료’가 접수 완료인지 배송 완료인지 다르다면 고객 안내가 어긋납니다. 접수됨·배송 중·배송 완료처럼 상태를 구분하고 언제 바뀌는지 정합니다. 화면과 문서, 상담에서도 같은 의미로 사용하고 처음 나오는 전문용어는 바로 풀어 줍니다.

가상 업무 예시

“처리 완료”가 접수 완료인지 실제 배송 완료인지 다르면 고객 안내가 어긋납니다. 각 상태의 시작·종료 조건을 정의하고 화면, 안내 문서와 상담에서 같은 표현을 사용합니다.

생각해 볼 질문
“처리 완료”가 접수 완료인지 배송 완료인지 정했나요? 다른 팀도 같은 상태를 뜻하는 말로 사용하나요?

3. 맥락과 결론 — 현재 문제와 요청 사항을 먼저 전한다

판단을 요청하는 글은 현재 문제와 원하는 결정을 먼저 밝혀야 합니다. 조사한 과정을 시간순으로 모두 적으면 읽는 사람은 끝까지 읽어도 자신이 무엇을 결정해야 하는지 모를 수 있습니다.

‘새 검색 배포 후 오류가 늘어 이전 버전으로 되돌리는 승인을 요청합니다’라고 목적과 요청을 말한 뒤 측정 결과와 예상 영향, 다른 대안, 문제가 생겼을 때 되돌릴 방법을 설명합니다. 결론을 먼저 말하더라도 그 결론에 이른 근거는 이어서 제공해야 합니다.

가상 업무 예시

담당자는 ‘오늘 14시에 새 검색 기능을 이전 버전으로 되돌리는 승인을 요청합니다. 새 버전 적용 뒤 검색 실패가 늘었고, 결제는 정상입니다’라고 먼저 보고합니다. 이어 전후 오류 기록, 되돌리는 데 걸릴 시간, 확인 방법을 붙입니다. 조사 과정을 끝까지 읽어야 요청이 나오는 글보다 책임자가 결정할 일과 근거를 빨리 찾을 수 있습니다.

생각해 볼 질문
첫 문단에서 현재 문제와 요청 사항을 알 수 있나요? 읽는 사람이 승인해야 하는지, 의견을 줘야 하는지도 분명한가요?

4. 사실과 추정 — 확실성의 수준을 드러낸다

사실은 확인한 내용이고 추정은 그 사실을 바탕으로 아직 확인하지 않은 것을 판단한 내용입니다. 제안은 앞으로 하자는 행동입니다. 이 셋을 구분해야 상대가 어디까지 믿고 무엇을 더 확인할지 알 수 있습니다.

‘데이터베이스 때문에 느립니다’라고 단정하기 전에 실제 확인한 것이 무엇인지 봅니다. 조회 단계에서 대기만 관찰했다면 ‘조회 대기가 확인됐고 원인은 조사 중입니다’라고 말합니다. 수치에는 측정한 시간과 조건도 붙여 다른 상황까지 검증했다고 오해하지 않게 합니다.

가상 업무 예시

“데이터베이스 때문에 느립니다”라고 단정하는 대신 “조회 단계에서 대기가 관찰됐고 원인을 조사 중입니다”라고 설명합니다. 확인된 범위와 다음 점검을 구분하면 다른 담당자도 조사에 참여하기 쉽습니다.

생각해 볼 질문
직접 측정한 현상과 아직 확인하지 못한 원인을 구분했나요? 수치의 측정 조건과 시점도 적었나요?

5. 구체적인 예 — 추상적인 설명을 확인 가능한 형태로 바꾼다

구체적인 예시는 용어의 뜻이나 규칙을 실제 상황에 적용해 보여 줍니다. 입력이 무엇이고 어떤 결과가 나오는지 알면 독자는 같은 의미로 이해했는지 확인하기 쉽습니다.

‘필수 정보를 입력하세요’만 쓰는 대신 빠진 항목과 올바른 입력 형식을 알려 줄 수 있습니다. 개발 문서라면 정상 요청뿐 아니라 항목이 빠진 요청의 응답도 보여 줍니다. 가상으로 만든 수치와 상황은 실제 측정이나 사건처럼 표시하지 않습니다.

가상 업무 예시

배송일 문서에 ‘올바른 날짜를 입력한다’만 쓰면 작성 순서를 알 수 없습니다. 작성자는 ‘2026-09-17처럼 연-월-일로 입력합니다. 2026-02-30은 없는 날짜이므로 저장하지 않고 날짜 수정을 요청합니다’라고 적습니다. 정상 입력과 거부할 입력을 나란히 보여 주면 사용자와 개발자가 같은 규칙을 확인할 수 있습니다.

생각해 볼 질문
정상 입력과 잘못된 입력을 각각 넣었을 때 어떤 결과가 나오는지 예시를 제공했나요?

6. 실행 가능한 절차 — 준비와 결과 확인까지 쓴다

절차 문서는 독자가 준비부터 작업 완료 확인까지 수행할 수 있게 써야 합니다. 작성자가 이미 알고 있는 권한이나 설정을 독자도 안다고 가정하면 중간에 막힐 수 있습니다.

‘백업을 복원한다’만 쓰면 어느 환경에 어떤 백업을 쓸지 알 수 없습니다. 대상 환경과 권한, 백업 선택 기준, 실행 순서, 복원 후 확인할 기능을 적습니다. 실패했을 때 중단할 조건과 다음 담당자도 안내하고 실제 담당자가 시험 환경에서 따라 해 봅니다.

가상 업무 예시

복구 안내가 ‘최신 백업 복원’뿐이라면 담당자는 운영 서버에 덮어쓸지 별도 서버에 복원할지 알 수 없습니다. 문서에 ‘격리된 복구 서버인지 확인 → 장애 전 마지막 정상 백업 선택 → 복원 → 알려진 주문 세 건의 금액과 건수 대조 → 확인 담당자 승인 후 전환’을 씁니다. 각 단계의 실제 명령·권한·중단 조건도 연결해 담당자가 시험 환경에서 따라 하게 합니다.

생각해 볼 질문
처음 수행하는 담당자도 준비부터 결과 확인까지 안전하게 따라갈 수 있습니까?

7. 시각화 — 표와 그림으로 관계와 차이를 보여 준다

표는 같은 기준으로 차이를 비교할 때, 그림은 순서와 연결 관계를 보여 줄 때 도움이 됩니다. 하지만 행·열·화살표가 무엇을 뜻하는지 설명이 없으면 독자가 다르게 읽을 수 있습니다.

주문 처리 그림에는 상자마다 담당자와 행동을 적고 화살표에는 넘기는 정보나 조건을 표시합니다. 승인 실패 때 어디로 가는지도 보여 줍니다. 표와 그림에는 제목을 붙이고 필요한 단위·범위·기호를 설명해 본문과 같은 뜻을 전달하게 합니다.

가상 업무 예시

환불 절차 그림에 ‘고객 → 상담 → 회계’만 있으면 누가 환불을 승인하는지 알 수 없습니다. 작성자는 ‘고객: 반품 요청 → 상담: 수거 확인 → 회계: 환불 승인·지급’으로 행동을 적고, 수거 미확인 시 상담으로 되돌리는 조건을 표시합니다. 그림 제목도 ‘수거 확인 후 환불 처리 순서’로 붙입니다. 상자를 늘리는 대신 결정과 전달 관계를 드러냅니다.

생각해 볼 질문
그림의 화살표가 자료 전달인지 작업 순서인지 표시했나요? 표의 단위와 비교 대상도 독자가 알 수 있나요?

8. 이해 확인 — 전달했다는 사실로 끝내지 않는다

전달은 자료를 보내는 일이고 상호이해는 상대가 같은 뜻으로 이해하는 것입니다. 메일을 보냈거나 교육을 끝냈다는 기록만으로 이해까지 확인한 것은 아닙니다.

승인 절차를 알려 준 뒤 ‘알겠죠?’ 대신 승인자가 없는 상황에서 어떻게 처리할지 설명해 보게 합니다. 답이 다르면 상대의 능력 탓부터 하기보다 빠진 조건과 어려운 표현을 찾습니다. 확인한 차이를 문서에 반영해야 다음 사람도 같은 곳에서 막히지 않습니다.

가상 업무 예시

새 승인 절차를 교육한 뒤 “알겠죠?”로 끝내지 않고 승인자가 부재한 상황에서 어떻게 처리할지 함께 확인합니다. 대답이 다르면 대리 승인 조건을 다시 설명하고 문서에 반영합니다.

생각해 볼 질문
설명을 들은 사람이 승인자 부재 같은 실제 상황에서 어떻게 처리할지 직접 말하거나 수행해 봤나요?

9. 결정 기록 — 나중에도 이유와 다음 행동을 찾게 한다

회의록은 무엇을 논의했고 어떤 결정을 했는지 나중에 확인할 기록입니다. 결정한 내용과 아직 검토 중인 내용을 구분해야 제안을 확정된 약속으로 오해하지 않습니다.

‘보안 검토가 필요하다’에서 끝내지 말고 누가 어떤 항목을 언제까지 확인할지 적습니다. 참석자가 기록을 확인하도록 하고, 결정 이유와 근거도 남깁니다. 다음 회의에서는 같은 논의를 처음부터 반복하기보다 남은 행동의 결과를 확인할 수 있습니다.

가상 업무 예시

회의에서 문자 알림 추가를 논의했지만 요금이 확인되지 않아 결정하지 못했습니다. ‘문자 알림 도입 논의’만 적으면 개발자는 승인으로 오해할 수 있습니다. 회의록에는 ‘도입 미결정. 운영 담당자가 금요일까지 월 예상 발송량과 비용을 확인하고, 사업 책임자가 다음 월요일 채택 여부 결정’이라고 남깁니다. 제안과 확정, 다음 행동을 구분합니다.

생각해 볼 질문
회의록에 결정한 내용, 추가 검토할 내용, 담당자와 기한을 구분해 적었나요?

10. 문서의 유지 — 바뀐 기능과 절차에 맞춰 안내를 고친다

문서는 기능과 업무가 바뀌면 함께 갱신해야 합니다. 어떤 버전을 설명하며 언제 수정됐는지 알 수 있어야 오래된 안내를 최신 절차로 착각하지 않습니다.

신청 메뉴 이름을 바꾼다면 화면뿐 아니라 안내와 교육 자료도 확인합니다. 최신 원본을 관리할 위치와 담당자를 정하고 예전 문서에서 새 안내를 찾을 수 있게 합니다. 여러 사본을 제각각 고치면 다시 서로 다른 설명이 퍼질 수 있습니다.

가상 업무 예시

신청 메뉴 이름을 바꿀 때 화면만 수정하지 않고 사용자 안내와 교육 자료도 확인합니다. 예전 문서에서는 최신 안내로 이동할 수 있게 해 서로 다른 절차가 퍼지는 일을 줄입니다.

생각해 볼 질문
화면이나 절차가 바뀌면 누가 안내 문서를 고치나요? 독자가 최신 안내인지 확인할 수 있나요?

11. 정보 구조 — 독자가 필요한 절차를 쉽게 찾게 배치한다

정보 구조는 독자가 필요한 설명을 어떤 제목과 순서로 찾게 할지 정하는 것입니다. 문장이 쉬워도 답이 엉뚱한 곳에 있으면 실제로 사용하기 어렵습니다.

장애 담당자가 복구 방법을 찾는데 제품의 개발 역사부터 읽어야 한다면 대응이 늦어집니다. 증상별로 시작할 위치를 보여 주고 필요한 준비와 절차로 연결합니다. 핵심 행동과 자세한 참고 정보를 나누되 독자가 어디에서 시작할지 분명하게 합니다.

가상 업무 예시

운영자가 장애 대응을 찾는데 설치 역사부터 길게 읽어야 한다면 대응이 늦습니다. 증상별 진입점과 공통 준비 사항을 분리해 필요한 절차로 바로 이동하게 합니다.

생각해 볼 질문
장애 대응 방법을 찾는 사람이 증상별 제목과 목차를 따라 필요한 절차로 바로 갈 수 있나요?

12. 범위와 전제 — 적용되지 않는 상황을 알린다

전제는 설명이나 절차가 성립하기 위해 먼저 갖춰져야 하는 조건입니다. 적용 환경·버전·권한이 다르면 같은 명령을 실행해도 다른 결과가 나올 수 있습니다.

시험 서버의 데이터를 초기화하는 명령이라면 운영 서버에도 써도 되는 것처럼 안내해서는 안 됩니다. 시작 부분에 대상 환경과 지워지는 자료, 필요한 권한을 밝힙니다. 독자가 자신의 조건과 맞는지 확인한 뒤 따라 할 수 있게 해야 합니다.

가상 업무 예시

시험 환경용 초기화 명령을 운영 절차처럼 보이게 쓰면 위험할 수 있습니다. 사용할 환경과 영향, 실행 권한을 분명히 표시합니다.

생각해 볼 질문
어떤 프로그램 버전과 환경에서 사용할 안내인지 밝혔나요? 운영 환경에서 실행하면 안 되는 작업도 구분했나요?

13. 단위와 기준 — 숫자의 의미를 함께 전한다

숫자는 단위와 기준이 있어야 뜻이 분명해집니다. ‘처리율 90%’만으로는 전체 접수 중 완료 비율인지, 시도한 작업 중 성공 비율인지 알 수 없습니다.

‘오늘 접수한 100건 중 90건이 승인까지 끝났다’처럼 기간·전체 수·완료 조건을 함께 적습니다. 전후 비교에서도 대상과 측정 조건을 맞춰야 합니다. 어제의 모든 요청과 오늘의 빠른 요청만 비교하면 숫자는 정확해도 결론은 잘못될 수 있습니다.

가상 업무 예시

대시보드의 ‘처리율 90%’를 보고 팀장은 업무가 거의 끝났다고 생각했습니다. 실제로는 오늘 자동 처리 시도 100건 중 90건 성공이었고, 수동 대기 200건은 분모에 없었습니다. 담당자는 ‘오늘 자동 처리 성공 90/100건, 별도 수동 대기 200건’으로 바꿉니다. 같은 90%라도 무엇을 셌는지가 판단을 바꿉니다.

생각해 볼 질문
독자가 숫자의 단위와 분모, 기간을 알 수 있습니까?

14. 오류 안내 — 원인보다 다음 행동부터 돕는다

오류 안내는 무엇이 실패했고 사용자가 다음에 무엇을 할 수 있는지 알려 주는 설명입니다. 내부 오류 코드만 보여 주면 사용자는 다시 시도해도 되는지조차 알기 어렵습니다.

파일이 너무 크다면 허용 크기와 파일을 줄여 다시 올리는 방법을 안내합니다. 원인이 확인되지 않았다면 추측을 사실처럼 말하지 않고 현재 상태와 문의 방법을 알려 줍니다. 입력 내용이 저장됐는지도 밝혀 불필요한 재입력이나 중복 요청을 줄입니다.

가상 업무 예시

고객이 18MB 견적서를 올렸는데 ‘잘못된 요청’만 나오면 다시 올려도 같은 실패를 반복합니다. ‘파일은 10MB까지 올릴 수 있습니다. 현재 파일은 18MB입니다. 용량을 줄여 다시 선택하세요. 작성한 내용은 유지됩니다’라고 안내합니다. 서비스가 실제로 입력을 보존하는지도 확인해야 문구가 거짓 약속이 되지 않습니다.

생각해 볼 질문
오류 안내에 실패한 작업과 다시 시도할 방법이 있나요? 이미 입력하거나 결제한 내용이 어떻게 됐는지도 알 수 있나요?

15. 요청 문장 — 원하는 답과 기한을 분명히 한다

요청 문장은 상대가 확인할 대상, 원하는 답, 필요한 기한을 알 수 있어야 합니다. ‘검토 부탁드립니다’만으로는 오류를 찾으라는 것인지 승인해 달라는 것인지 모호합니다.

‘설계서의 관리자 권한 세 항목을 확인하고 금요일까지 승인 또는 수정 의견을 주세요’처럼 적습니다. 판단에 필요한 근거와 관련 부분도 함께 제공합니다. 답이 늦어지면 어떤 후속 작업이 영향을 받는지도 알려 주면 기한의 이유를 이해하기 쉽습니다.

가상 업무 예시

‘설계 검토 부탁드립니다’ 대신 ‘관리자 권한 표의 2·3행에서 고객 자료 다운로드 권한이 필요한지 목요일 15시까지 승인 또는 수정 의견을 주세요. 금요일에 권한 개발을 시작합니다’라고 요청합니다. 관련 표와 업무 이유도 함께 보냅니다. 상대는 어디를 보고 무엇을 답하며 왜 그때까지 필요한지 알 수 있습니다.

생각해 볼 질문
상대가 무엇을 어떤 형태로 언제까지 답해야 하는지 알 수 있습니까?

16. 대안 비교 — 같은 기준으로 선택하게 한다

대안을 비교할 때는 같은 항목으로 장점과 부담을 살펴야 합니다. 도구 A는 가격, 도구 B는 기능만 적으면 어느 쪽이 조건에 맞는지 판단할 수 없습니다.

두 도구 모두 필요한 기능·도입 기간·사용료·운영 인력·자료 이전 방법을 적습니다. 추천할 때는 어떤 조건 때문에 선택했는지와 감수할 단점을 설명합니다. 사용량 같은 가정이 바뀌면 결론도 달라질 수 있다는 점을 함께 밝힙니다.

가상 업무 예시

백업 도구 A는 월 10만 원, B는 월 20만 원입니다. 제안자는 두 도구를 같은 자료 1TB로 복구 시험한 결과 A는 5시간, B는 1시간 걸렸다고 함께 제시합니다. 업무의 복구 목표가 2시간이라 B를 추천하되 자료량 증가 시 재시험이 필요하다고 적습니다. 가격만 싼 안과 기능이 많다는 안을 비교하는 대신 같은 요구로 선택합니다. 수치는 가상 시험 결과입니다.

생각해 볼 질문
각 대안을 동일한 비용·기간·운영 조건으로 비교했나요? 추천한 대안의 불리한 점도 설명했나요?

17. 회의의 목적 — 공유와 결정을 구분한다

회의는 정보를 공유하는 자리일 수도 있고 여러 의견을 조정해 결정을 내리는 자리일 수도 있습니다. 끝날 때 어떤 결과를 얻어야 하는지에 따라 참석자와 준비 자료가 달라집니다.

설계를 결정해야 한다면 선택지와 쟁점을 미리 보내 검토할 시간을 줍니다. 회의 중에는 차이와 영향을 비교하고 결정권자가 결론을 내릴 수 있게 합니다. 결정하지 못했다면 부족한 정보와 조사 담당자·기한을 남겨야 다음 행동으로 이어집니다.

가상 업무 예시

금요일 회의의 목적은 두 백업 방식 중 하나를 고르는 것입니다. 담당자는 수요일에 같은 조건의 비용·복구 시간·운영 부담 비교표를 보내고 예산 승인권자를 초대합니다. 회의에서는 빠진 조건을 확인해 선택하고, 부족한 시험이 있으면 담당자와 기한을 정합니다. 단순 진행 공유는 문서로 먼저 끝내 결정할 시간을 확보합니다.

생각해 볼 질문
회의가 끝나면 무엇이 결정되거나 달라져야 합니까?

18. 발표의 3P — 목적·청중·장소에 맞춰 설계한다

발표의 3P는 청중(Person), 목적(Purpose), 장소·환경(Place)을 살피는 준비 원칙입니다. 누구에게 어떤 이해나 행동을 기대하며 어디에서 얼마나 설명할 수 있는지 정합니다.

기술 도입 승인을 받는 발표라면 제품 기능을 전부 나열하기보다 현재 업무 문제와 제안의 효과, 필요한 비용과 결정을 연결합니다. 청중이 모르는 용어를 풀고 화면이 작은 장소라면 표의 양도 조절합니다. 정해진 시간 안에 전달되는지 실제로 연습합니다.

가상 업무 예시

개발자는 임원에게 백업 예산 승인을 받을 10분 발표를 준비합니다. 청중은 복구 명령보다 영업 중단 시간과 비용을 판단해야 하므로 피해·대안·요청 예산 순서로 설명합니다. 회의실 뒷자리에서는 작은 표를 읽기 어려워 핵심 비교만 크게 보여 주고 세부 내역은 배포합니다. 발표 시간을 재며 연습해 청중·목적·장소를 모두 반영합니다.

생각해 볼 질문
같은 백업 제안을 운영자 교육용 온라인 발표로 바꾼다면 청중·목적·장소에 따라 무엇을 바꾸겠습니까?

19. 검토와 사용 시험 — 처음 읽는 사람도 따라 할 수 있는지 확인한다

문서 검토는 내용이 정확하고 일관되며 독자의 목적에 맞는지 확인하는 일입니다. 작성자는 익숙한 준비 과정을 빠뜨려도 머릿속으로 보완하기 때문에 처음 읽는 사람의 사용 시험이 도움이 됩니다.

새 운영자가 설치 문서만 보고 따라 하다가 권한 신청에서 멈췄다면 준비 조건이 빠진 것입니다. 어디서 막혔는지 기록하고 권한을 받는 경로와 필요한 시간을 보완합니다. 문법만 고치는 것보다 실제 작업이 끝나는지 확인하는 것이 중요합니다.

가상 업무 예시

새 운영자가 설치 문서를 따라 하다가 권한 신청에서 멈췄다면 필수 준비가 빠진 것입니다. 담당 경로와 승인 시간을 문서에 보완합니다.

생각해 볼 질문
처음 읽는 담당자가 문서만 보고 실제 작업을 끝낼 수 있는지 시험했나요? 막힌 단계의 설명을 보완했나요?

20. 용도에 맞는 채널 — 급한 일은 대화하고 결정은 기록한다

소통 채널은 대화·전화·메일·문서처럼 정보를 주고받는 수단입니다. 바로 묻고 답해야 하는지, 여러 사람이 나중에 같은 내용을 찾아야 하는지에 따라 알맞은 방법이 달라집니다.

장애 중에는 통화로 즉시 상황을 맞추고 조치할 수 있습니다. 그 뒤 결정·담당자·결과를 공통 기록에 남기면 늦게 합류한 사람도 이어받을 수 있습니다. 빠르게 말한 내용이 필요한 사람에게 전달됐는지와 기록에 접근할 수 있는지도 확인합니다.

가상 업무 예시

장애 중 두 담당자가 통화로 새 배포를 중지하기로 했지만 기록하지 않았습니다. 뒤늦게 합류한 담당자는 이를 모르고 배포를 다시 시작했습니다. 팀은 긴급 조치는 통화로 맞추되 ‘중지 대상 버전·결정 시각·담당자·재개 조건’을 공통 기록에 즉시 남기기로 합니다. 빠른 대화와 이후의 동일한 판단에 필요한 기록을 함께 사용합니다.

생각해 볼 질문
통화나 채팅으로 정한 조치와 결과를 공통 문서에 남겼나요? 나중에 합류한 담당자가 그 기록으로 업무를 이어 갈 수 있나요?

교재에서 함께 확인할 내용

위 20개 노트는 교재 개념을 업무에 적용하는 길잡이입니다. 다음 이론과 기법은 별도로 읽고 직접 설명하거나 계산해 보세요. 이 목록도 교재 전체를 대신하지는 않습니다.

1. 문제 해결을 위한 의사소통

문제를 해결하려면 어떤 일이 잘되지 않는지 정하고 원인을 확인한 뒤 대안을 비교해야 합니다. 아이디어를 모을 때부터 바로 비판하면 선택지가 줄어들 수 있습니다. 먼저 여러 방법을 모으고 그다음 비용과 효과를 비교한 뒤, 실행 결과로 실제 문제가 줄었는지 확인합니다.

확인해 보기: 아이디어를 많이 모으는 단계와 비용·효과로 대안을 비교하는 단계의 진행 방식은 어떻게 달라야 하나요?

프로젝트관리 및 테크니컬커뮤니케이션 · 25쪽 →

2. 5W2H1T로 문서의 목적 정리

5W2H1T는 문서에 필요한 정보를 빠뜨리지 않도록 묻는 항목입니다. 교재는 왜 쓰는지(Why), 무엇을 다루는지(What), 누가 읽는지(Target), 어떻게 하는지(How), 언제(When), 누가(Who), 어디서(Where), 비용은 얼마인지(How much)를 확인합니다. 장애 보고라면 독자가 복구 작업을 할 사람인지 공개 여부를 결정할 사람인지에 따라 앞에 쓸 내용이 달라집니다.

확인해 보기: 같은 장애 보고서를 운영 담당자와 의사결정자에게 보낼 때 Target에 따라 어떤 내용을 달리 설명할까요?

프로젝트관리 및 테크니컬커뮤니케이션 · 34쪽 →

3. 테크니컬 라이팅의 검토

기술 문서는 사실이 맞는지와 함께 독자가 필요한 일을 할 수 있는지도 확인해야 합니다. 설치 명령이 정확해도 파일 위치나 사전 권한이 빠지면 초보자는 실패합니다. 처음 쓰는 사람이 절차를 따라 하게 해 막힌 단계와 오해한 표현을 고쳐 보세요.

확인해 보기: 설치 설명서의 문장이 문법적으로 맞아도 처음 사용하는 사람이 실패한다면 무엇을 추가로 검토해야 할까요?

프로젝트관리 및 테크니컬커뮤니케이션 · 49쪽 →

4. 프레젠테이션의 3P

발표의 3P는 청중(Person), 목적(Purpose), 장소(Place)입니다. 개발자에게 구조를 검토받는 자리와 경영진에게 예산을 승인받는 자리는 필요한 설명이 다릅니다. 누구에게 무엇을 요청할지와 화면·소리 등 발표 환경을 확인한 뒤 자료와 연습을 준비합니다.

확인해 보기: 같은 시스템 제안을 개발자 검토 회의와 경영진 승인 회의에서 발표할 때 어떤 차이가 필요할까요?

프로젝트관리 및 테크니컬커뮤니케이션 · 57쪽 →