로그북을 작성하라고 하면 학생들은 대개 당황해 한다. 그 이유는 로그북 자체가 이름도 낯설고 형식도 익숙하지 않기 때문이다.
로그북은 크게 7개 정도의 항목으로 구성되어 있다. 먼저 전체 구조를 눈으로 파악하고, 그 다음 각 항목을 하나씩 살펴보자.
단, 여기에서 사용하는 로그북은 대학교 '캡스톤디자인' 수업에 특화된 로그북이다.
로그북의 7가지 항목 — 한눈에 보기
No. 항목 작성 기준
| ① | 수행목표 | 과제에서 내가 맡은 역할과 목표 |
| ② | 오늘의 목표 | 오늘 달성할 구체적 목표 |
| ③ | 활동 내용 | 수행한 활동을 순서대로 요약 |
| ④ | 문제 해결 | 문제 / 원인 / 해결방안 / 결과 구분 |
| ⑤ | 달성도·결과 | 달성도 + 결과 + 증빙 자료 첨부 |
| ⑥ | 성찰 (주관 허용) | 안다고 생각한 것과 실제 경험의 차이 |
| ⑦ | 내일 목표 및 계획 | 성찰을 바탕으로 내일 목표 설정 + 실행 계획 수립 |
7개 항목이 하나의 흐름으로 이어진다는 것을 기억해 두자. 이제 각 항목을 하나씩 살펴본다.
항목별 작성 방법
① 수행목표
이번 과제 전체에서 내가 맡은 역할과 목표다. 학기 내내 크게 바뀌지 않는 항목으로, 팀 안에서 내가 어떤 사람인지를 한눈에 보여주는 자리다. 역할명과 그에 따른 구체적 목표를 함께 적는다.
나쁜 예: 열심히 과제에 참여하겠다 잘된 예: 인터뷰 담당 — 현장 인터뷰 설계 및 진행
좋은 예 (인문사회): 인터뷰 담당 — 현장 인터뷰 설계 및 진행
좋은 예 (이공계): 하드웨어 담당 — 온습도·초음파·PIR 센서 아두이노 연결 및 데이터 수집
② 오늘의 목표
오늘 하루 내가 달성하려는 것이다. 수행목표라는 큰 방향 안에서, 오늘은 어디까지 가겠다는 구체적인 지점을 적는다. "열심히 하겠다"가 아니라, 오늘이 끝났을 때 무엇이 완성되어 있어야 하는지를 쓴다.
나쁜 예: 인터뷰 관련 작업
좋은 예: (인문사회) 이해관계자 지도 작성 완료
좋은 예: (이공계): 온습도 센서 아두이노 연결 및 데이터 수집 코드 완성
③ 활동 내용
오늘 실제로 한 일을 순서대로 요약한다. 무엇을 했는지, 어떤 순서로 했는지가 드러나야 한다. 문장형이 아니라 개조식으로, 번호를 붙여 구분한다.
나쁜 예: 자료를 조사하고 팀원들과 회의를 하고 지도를 작성하였다
좋은 예: (인문사회) ①이해관계자 분류, ②지도 작성, ③팀 검토 완료
좋은 예: (이공계) ∙ ①센서 배선 연결 , ②데이터 수집 코드 작성 , ③동작 테스트 완료
④ 문제 해결
로그북의 문제 해결 항목은 문제에 부닥뜨렸을 때 이를 체계적으로 해결하는 방법을 매일 훈련하는 자리다. 따라서 문제 해결은 다음의 네 가지를 반드시 구분해서 써야 한다.
- 문제 — 오늘 실제로 부딪힌 장애물이 무엇인지를 객관적으로 기술한다. "잘 안 됐다"가 아니라 "센서 값이 불규칙하게 출력됐다"처럼 구체적으로 써야 한다. 문제를 정확히 정의하는 것이 해결의 첫 단계다.
- 원인 — 왜 그 문제가 발생했는지를 분석한다. 원인 없는 해결은 임시방편에 불과하다. "배선 접촉 불량"처럼 근본 원인을 찾아야 한다. 원인을 모르면 "원인 미파악 — 추가 분석 필요"라고 솔직하게 쓴다.
- 해결방안 — 원인을 바탕으로 어떤 방법으로 해결했는지를 기록한다. 시도한 방법이 여러 개라면 모두 적고, 최종적으로 채택한 방법을 명시한다.
- 결과 — 해결방안을 적용한 뒤 어떻게 됐는지를 기록한다. 해결됐다면 어떻게 해결됐는지, 해결되지 않았다면 어디까지 진행됐는지를 솔직하게 남긴다.
단, 문제가 없었던 날은 "해당 없음"이라고 쓰면 된다. 학생들이 이 항목 작성을 많이 어려워한다. 익숙하지 않기 때문이다. 그러나 이 항목을 성실하게 채우는 학생과 그렇지 않은 학생의 차이는 한 학기가 끝났을 때 명확하게 드러난다.
잘된 예 (이공계):
- 문제: 온습도 센서 값 불규칙 출력
- 원인: 배선 접촉 불량
- 해결: 납땜으로 고정
- 결과: 정상 데이터 수집 확인
잘된 예 (인문사회):
- 문제: 이해관계자 구분 기준 모호
- 원인: 분류 기준 미설정
- 해결: 영향력 방향으로 기준 설정
- 결과: 이해관계자 지도 완성
나쁜 예:
- 문제 해결: 이해관계자 구분 문제 해결함 → 원인도, 해결방안도, 결과도 없다
- 문제 해결: 해당 없음 → 실제로는 문제가 있었는데 그냥 넘긴 경우
⑤ 달성도·결과
오늘의 목표를 얼마나 달성했는지, 그 결과물은 무엇인지를 기록하고 증빙 자료로 뒷받침하는 항목이다.
- 달성도 — 오늘의 목표를 얼마나 이뤘는지를 수치로 표현한다. "90% 달성"처럼 구체적으로 쓴다. 달성하지 못한 부분도 솔직하게 기록한다. "100% 달성"이 좋은 로그북이 아니다. 미달성 항목을 정확히 남기는 것이 다음 날 계획의 출발점이 된다.
- 결과 — 오늘 실제로 완성된 것이 무엇인지를 사실로 기록한다. "잘 됐다", "만족스럽다"는 결과가 아니다. "이해관계자 지도 완성", "센서 연결 완료"처럼 처음 보는 사람이 읽고 무엇이 완성되었는지 파악할 수 있어야 한다.
- 결과 증빙 — 결과로 주장한 것은 반드시 데이터나 이미지로 뒷받침해야 한다. "완료"라고 썼다면 그것이 사실임을 확인할 수 있는 파일을 첨부한다. 증빙이 없는 결과는 주장에 불과하다.
나쁜 예: 잘 됐다 (증빙 없음)
좋은 예: (인문사회)
* 달성도 : 90% 달성
* 결과 : / 이해관계자 지도 완성 / 인터뷰 일정 미확정
* 결과증빙 : (2026.04.07)이해관계자지도.jpg
좋은 예 (이공계):
* 달성도 : 80% 달성
* 결과 / 온습도·PIR 센서 연결 완료 / 초음파 센서 오류 미해결
* 결과 증빙 : 화일명 : (2026.04.07)센서연결완료.png
⑥ 성찰 (유일하게 주관적 내용을 쓸 수 있는 항목)
오늘을 통해 생각이 바뀐 것, 새롭게 알게 된 것을 기록한다. 로그북의 7개 항목 중 유일하게 주관적 내용을 쓸 수 있는 자리다. 단, "힘들었다", "보람 있었다"는 성찰이 아니다. 안다고 생각했던 것과 실제로 해본 것의 차이를 쓰는 자리다.
나쁜 예: 오늘 힘들었지만 보람 있었다
잘된 예: 이해관계자를 단순 나열하면 된다고 생각했으나, 실제로는 영향력 방향과 관계성을 함께 고려해야 함을 알게 됨
좋은 예 (이공계): 코드만 수정하면 된다고 생각했으나, 실제로는 배선 접촉 문제가 원인이었음. 소프트웨어 문제와 하드웨어 문제를 구분해서 점검해야 함을 알게 됨
⑦ 내일 목표 및 계획
오늘의 성찰을 바탕으로 내일의 목표를 설정하고, 그것을 달성하기 위한 실행 계획을 수립한다. "목표"와 "계획"은 다르다. 목표는 내일이 끝났을 때 무엇이 완성되어 있어야 하는지이고, 계획은 그것을 어떻게 달성할 것인지의 순서다.
나쁜 예: 인터뷰하기
잘된 예: 목표: 인터뷰 질문지 초안 완성 / 계획: ① 기존 항목 검토 ② 항목 추가 및 수정 ③ 팀 공유
좋은 예 (이공계): 목표: 초음파 센서 오류 해결 및 전체 센서 통합 테스트 완료 / 계획: ① 배선 재점검 ② 코드 디버깅 ③ 통합 동작 확인
7개 항목이 하나의 사이클이다
항목을 따로따로 보면 그냥 칸 채우기처럼 보이지만 그런데 7개 항목은 서로 유기적으로 연결된 개념이다.
나는 이번 과제에서 이런 역할을 맡고 있고 (수행목표) → 오늘은 이것을 하려 했고 (오늘의 목표) → 실제로 이렇게 했고 (활동 내용) → 수행 도중 이런 문제가 있었는데 이렇게 풀었고 (문제 해결) → 결과는 이렇고 (달성도·결과) → 오늘 이것을 새롭게 알게 됐고 (성찰) → 그래서 내일은 이렇게 하겠다 (내일 목표 및 계획)
과제와 관련하여 개인의 활동이 체계적으로 정리된다. 작성하는 사람의 생각이 정리되고, 읽는 사람은 그 사람의 하루 활동을 한눈에 파악할 수 있다. 그리고 내일 목표 및 계획이 다음 날의 오늘의 목표로 이어지면서 사이클이 반복된다.
로그북을 잘 쓰기 위한 3원칙
사이클을 이해했다면 이제 어떻게 써야 하는지가 문제다. 로그북 작성에는 세 가지 원칙이 있다.
- 원칙 1. 객관성 — 두 가지를 동시에 요구한다. 첫째, 실제 일어난 사실만 쓴다. 감정, 소감, 다짐은 사실이 아니다. 둘째, 그 사실이 객관적으로 확인될 수 있어야 한다. 결과를 주장했다면 데이터나 이미지로 반드시 뒷받침한다. 단, 성찰 항목은 예외다.
- 원칙 2. 구체성 — 무엇을, 어떻게, 어느 수준까지 했는지 알 수 있게 작성하여야 한다. 학생들이 이 부분이 가장 취약하다. '보고서 작성', '회의' 등으로 표현하는 것이 대표적인 나쁜 예이다. 무슨 보고서를 작성하였는지? 어떤 회의를 작성하였는지 구체적으로 작성해야 정보 전달의 능력을 갖게 되기 때문이다
- 원칙 3. 가독성 — 타인이 한눈에 읽을 수 있게 쓴다. 예를 들어 문장을 서술형이 아니라 개조식으로, 내용은 구분해서, 짧고 명확하게 작성하는 것을 말한다.
이 세 원칙이 지켜지면 구체적이고 객관적인 사실 위주의 기록이 되어 타인과의 공유가 쉬워진다. 나만 이해하는 기록이 아니라, 누구든 읽고 파악할 수 있는 문서가 된다. 그것이 로그북의 목적이며 직장생활에 필요한 협업 능력의 기초가 되기도 한다.
'로그북' 카테고리의 다른 글
| 9회. 로그북은 AI 문해력 훈련 (0) | 2026.04.19 |
|---|---|
| 7회. 로그북 논리 에러 (0) | 2026.04.19 |
| 4회. 로그북 작성 에러 유형 개관 (0) | 2026.04.19 |
| 3회. O-PDCA와 로그북 (0) | 2026.04.19 |
| 1회. 로그북이란 무엇인가? (0) | 2026.04.19 |