나와 AI의 공동작업소

바이브 코딩 경험 - 네트워크/디버깅/보안/모바일 대응

일머리 강교수 — Mon, 27 Apr 2026 23:18:06 +0900

네트워크(Network)란?

컴퓨터와 컴퓨터가 데이터를 주고받는 통신 체계를 말한다. 이 앱에서는 프론트엔드(GitHub Pages)와 백엔드(Google Apps Script) 사이에 데이터가 오가는 과정이 곧 네트워크다. 사용자가 저장 버튼을 누르는 순간, 눈에 보이지 않는 곳에서 데이터가 이동한다.

이 앱에서 핵심적으로 등장하는 네트워크 개념은 세 가지다.

첫 번째는 HTTP/HTTPS다. 인터넷에서 데이터를 주고받는 규칙(프로토콜)이다. HTTP에 보안이 추가된 것이 HTTPS인데, 이 앱에서는 GitHub Pages도, Apps Script도 모두 HTTPS를 사용한다. 둘 중 하나라도 HTTP면 통신이 차단되기 때문에 반드시 일치해야 한다.

두 번째는 REST API다. 프론트엔드가 백엔드에 데이터를 요청하는 방식의 약속이다. "이 날짜의 데이터를 주세요(doGet)", "이 데이터를 저장해 주세요(doPost)"처럼 정해진 형식으로 요청하고 응답받는 구조다.

세 번째는 CORS다. 보안상의 이유로 브라우저는 기본적으로 다른 주소 간의 데이터 통신을 차단한다. GitHub Pages 주소와 Apps Script 주소가 서로 다르기 때문에, GAS 코드에서 CORS를 허용해주는 설정이 필요하다. 실제로 초기 개발 과정에서 저장 기능이 구현되지 않아서 계속 디버깅을 했는데 원인 중 하나가 바로 이 CORS 문제였다고 한다.

바이브 코딩에서 네트워크는 가장 존재감이 없는 개념이다. Claude가 보이지 않는 곳에서 모두 처리해줬기 때문이다. 그러나 문제가 생겼을 때 "왜 저장이 안 되는가"를 이해하려면 결국 네트워크 개념이 바탕에 있어야 한다.

좋은 방향입니다. 각 섹션마다 "이전에는 이랬다 → 바이브 코딩에서는 이렇게 바뀌었다"는 대비 구조를 넣으면 독자가 변화의 의미를 훨씬 실감할 수 있습니다.

디버깅 섹션부터 그 구조로 다시 써보겠습니다.

디버깅(Debugging)이란?

앱이 의도한 대로 작동하지 않을 때 원인을 찾아 고치는 과정을 말한다. 'Bug(버그)'는 원래 벌레라는 뜻인데, 초창기 컴퓨터 시대에 실제 벌레가 기계 안에 끼어 오작동을 일으킨 사건에서 유래했다. 지금은 소프트웨어의 오류나 결함을 통칭하는 말로 쓰인다.

바이브 코딩 이전에는 디버깅이 개발자에게 가장 고된 작업 중 하나였다. 브라우저 개발자 도구를 열고 네트워크 탭을 분석하고, GAS 실행 로그를 한 줄씩 추적하며 원인을 찾아야 했다. 오류 메시지를 읽고 해석하는 것 자체가 전문 지식을 요구했다. 초보자에게 디버깅은 종종 개발을 포기하게 만드는 벽이었다.

바이브 코딩에서는 디버깅 방식이 완전히 달라졌다. 오류 메시지를 그대로 복사해서 Claude에게 보여주는 것이 가장 강력한 디버깅 도구였다. 이 앱을 개발하는 과정에서 구글 시트 저장이 되지 않는 문제가 두 번 있었다. 두 번 모두 화면에 뜬 오류 메시지를 그대로 붙여넣었고, Claude가 원인을 진단하고 수정된 코드를 만들어줬다. 모바일에서 화면이 잘리는 문제도 마찬가지였다. "모바일에서 오른쪽이 잘려요"라는 한 마디로 충분했다.

보안(Security)이란?

앱과 데이터를 외부의 unauthorized 접근이나 악의적인 공격으로부터 보호하는 것을 말한다. 아무리 잘 만든 앱이라도 보안이 허술하면 개인 정보가 유출되거나 데이터가 손상될 수 있다.

바이브 코딩 이전에는 보안이 개발자에게 가장 전문적인 영역 중 하나였다. HTTPS 설정, 접근 권한 제어, 데이터 암호화, SQL 인젝션 방어 등 보안 관련 지식만으로도 별도의 전문가가 존재할 만큼 깊고 넓은 분야다. 초보 개발자가 가장 소홀히 하기 쉬운 영역이기도 했다.

바이브 코딩에서는 기본적인 보안 설정을 Claude가 코드 안에 자동으로 반영해줬다. 이 앱에서 적용된 보안 요소는 크게 두 가지다.

첫 번째는 HTTPS 강제 적용이다. GitHub Pages와 Apps Script 모두 HTTPS를 사용하기 때문에 데이터가 암호화된 상태로 전송된다. 중간에서 누군가 가로채더라도 내용을 읽을 수 없다.

두 번째는 Apps Script 접근 권한 설정이다. GAS를 웹앱으로 배포할 때 "누가 접근할 수 있는가"를 설정한다. 이 앱은 개인용이므로 본인 계정으로만 접근하도록 제한했다. 아무나 그 URL로 접근해도 데이터를 읽거나 저장할 수 없다.

단, 바이브 코딩에서 보안의 한계도 분명히 있다. Claude는 요청한 기능에 필요한 보안만 처리한다. 요청하지 않은 보안 취약점은 스스로 찾아주지 않는다는 점이다. 개인용 앱 수준에서는 충분하지만, 여러 사람이 사용하는 서비스로 확장한다면 보안은 별도로 깊이 검토해야 할 영역이다.

모바일 대응(Mobile Optimization)이란?

PC에서 만든 앱이 스마트폰에서도 불편함 없이 작동하도록 최적화하는 것을 말한다. 화면 크기, 터치 방식, 손가락으로 누르는 버튼 크기 등 모바일 환경은 PC와 근본적으로 다르기 때문에 별도의 대응이 필요하다.

바이브 코딩 이전에는 모바일 대응이 상당한 추가 작업을 요구했다. 화면 크기에 따라 레이아웃이 자동으로 바뀌는 반응형 CSS를 별도로 설계해야 했고, 터치 이벤트 처리, 버튼 크기 조정, 폰트 크기 최적화 등 PC 버전과는 별개의 작업이 필요했다. 경우에 따라서는 모바일 앱을 아예 따로 개발하기도 했다.

바이브 코딩에서는 "모바일에서도 잘 보이게 해주세요"라는 한 마디로 충분했다. Claude가 반응형 CSS를 자동으로 적용해줬고, 실제로 모바일에서 열었을 때 오른쪽이 잘리는 문제가 생겼을 때도 "모바일에서 화면이 잘려요"라고 말하는 것만으로 즉시 수정됐다.

한 걸음 더 나아가 이 앱은 PWA(Progressive Web App) 개념을 적용했다. PWA란 웹페이지이지만 스마트폰 홈 화면에 추가하면 일반 앱처럼 동작하는 기술이다. 앱스토어에 등록하거나 별도로 설치할 필요 없이, 브라우저에서 홈 화면에 추가하는 것만으로 앱 아이콘이 생기고 전용 앱처럼 실행된다. 앱스토어 없이, 설치 없이, 대화만으로 모바일 앱이 만들어졌다.

바이브 코딩 경험 - 데이터 저장 / 웹호스팅/버전관리

일머리 강교수 — Mon, 27 Apr 2026 23:16:59 +0900

데이터 저장(Data Storage)이란?

입력한 정보를 잃어버리지 않고 보관하는 것을 말한다. 아무리 잘 만든 화면이라도 데이터를 저장하지 못하면 앱이라고 할 수 없다. 이 로그북 앱에서는 저장 방식이 두 가지로 나뉜다. 상황에 따라 역할이 다르기 때문이다.

첫 번째는 LocalStorage(로컬스토리지)다. 인터넷 연결 없이 브라우저 안에 임시로 데이터를 보관하는 공간이다. 아직 정리가 덜 된 내용, 완성되지 않은 기록을 임시저장 버튼을 눌러 여기에 맡겨둘 수 있다. 개발하는 개인 로그북의 경우 하루동안 여러번 입력이 이뤄지기 때문에 최종 구글 시트에 저장하기 전까지는 임시 저장 기능인 로컬 스토리지를 이용하는 것이 필요하다.

두 번째는 Google Sheets(구글 시트)다. 저장 버튼을 누르면 GAS를 통해 구글 시트에 기록이 남는다. 어느 기기에서 열어도 같은 데이터를 볼 수 있고, 영구적으로 보관된다. 날짜가 같은 기록이 이미 있으면 새 행을 추가하는 대신 기존 행을 덮어쓰기 때문에 중복 없이 깔끔하게 관리된다.

웹호스팅(Web Hosting)이란?

내가 만든 앱을 인터넷에 올려두어 누구든 어디서든 접근할 수 있게 하는 것을 말한다. 아무리 잘 만든 앱이라도 내 컴퓨터 안에만 있으면 나 혼자만 쓸 수 있다. 웹호스팅은 그 앱을 인터넷 세상에 공개하는 과정이다. 물론 지금 내가 개발하는 '개인 로그북 앱'은 나혼자만 사용하지만 인터넷이 접속되는 환경이면 어디에서든 사용할 수 있게 만드는 것이 웹호스팅 개념이다.

이 앱에서는 GitHub Pages를 사용했다. GitHub는 원래 개발자들이 코드를 관리하고 공유하는 플랫폼이다. 쉽게 말해 코드의 구글 드라이브라고 생각하면 된다. 파일을 올려두고, 수정 이력을 관리하고, 다른 사람과 공유할 수 있다.

여기서 한 걸음 더 나아간 것이 GitHub Pages다. GitHub에 올려둔 HTML 파일을 그대로 인터넷 웹페이지로 공개해주는 기능이다. 별도의 서버를 구매하거나 운영할 필요 없이, 파일을 올리고 Pages 기능을 활성화하는 것만으로 https://아이디.github.io/저장소명 형태의 고유한 주소가 생성된다.

즉, 앞서 프론트엔드에서 만들었던 index.html 파일 하나를 올려두면 https://아이디.github.io/저장소명 형태의 고유한 주소가 생성되고 이 주소를 스마트폰 브라우저에서 열면 앱으로 사용할 수 있다.

이 앱에서는 URL이 두 개 만들어진다. 하나는 사용자가 앱에 접속하는 GitHub Pages 주소이고, 다른 하나는 프론트엔드와 구글 시트가 데이터를 주고받는 Apps Script 주소다. 혼동을 없애기 위하여 두가지 URL 에 대하여 다시 정리해 보았다.

사용자용 URL	GitHub Pages	사용자가 브라우저에서 앱에 접근	https://아이디.github.io/logbook
연동용 URL	Google Apps Script	프론트엔드↔백엔드 데이터 통신	https://script.google.com/macros/s/...

버전 관리(Version Control)란?

파일을 수정할 때마다 그 변경 이력을 기록해두는 것을 말한다. 쉽게 말해 "언제, 무엇을, 어떻게 바꿨는지"를 저장해두는 시스템이다. 글쓰기로 비유하면 초고, 2고, 3고를 모두 보관해두고 필요하면 이전 버전으로 되돌아갈 수 있는 것과 같다.

이 앱에서는 Git과 GitHub를 사용했다. Git은 버전 관리를 담당하는 도구 자체이고, GitHub는 Git으로 관리한 파일을 인터넷에 올려두는 플랫폼이다. 앞서 웹호스팅에서 설명한 GitHub가 바로 이것이다. 즉 GitHub는 버전 관리(Git)와 웹호스팅(Pages) 두 가지 역할을 동시에 담당한다.

실제 사용 방식은 간단하다. index.html 파일을 수정할 때마다 GitHub에 올리면(commit → push), 변경 이력이 자동으로 쌓인다. "버튼 색상 변경", "지출 합계 기능 추가"처럼 무엇을 바꿨는지 메모를 남길 수도 있다. 덕분에 새 기능을 추가했다가 문제가 생기면 이전 버전으로 즉시 되돌아갈 수 있다.

바이브 코딩에서 버전 관리는 특히 중요하다. Claude가 코드를 수정해줄 때마다 GitHub에 올려두면, 혹시 수정이 잘못되더라도 언제든 되돌아갈 수 있는 안전망이 생기기 때문이다.

9회. 로그북은 AI 문해력 훈련

일머리 강교수 — Sun, 19 Apr 2026 23:27:24 +0900

요즘 "프롬프트 엔지니어링"이라는 말이 자주 들린다. AI가 말을 잘 듣게 하는 명령어 기법이다. ㉮ 페르소나 설정, ㉯ 목표와 맥락 제공, ㉰ 단계별 질문, ㉱ 예시 제공 — 이런 기술들이 소개된다. 그런데 이 설명들이 공통적으로 간과하는 것이 있다.

프롬프트 엔지니어링의 진짜 핵심은 기법이 아니다. AI와 구조적으로, 체계적으로 대화하라는 것이다.

AI와의 소통은 인간과의 소통과 다르다

인간 사이의 소통에는 감정적 배려와 비언어적 맥락이 큰 역할을 한다. 말이 좀 모호해도 눈치로 채우고, 표정으로 보완하고, 관계의 맥락으로 이해한다.

AI와의 소통은 다르다. 감정적 배려도, 비언어적 맥락도 작동하지 않는다. AI에게 필요한 것은 오직 두 가지다. 전달 정보의 정확성과 논리성이다.

이 차이를 이해하는 순간, AI 협업은 "잘 쓰는 능력"의 문제임이 분명해진다. 아무리 좋은 AI를 갖고 있어도, 내가 무엇을 원하는지 명확하게 전달하지 못하면 AI는 그럴 듯한 답을 내 놓을 수는 있지만 절대 좋은 답을 내놓을 수는 없다.

로그북이 훈련하는 것이 바로 그것이다

로그북은 자신의 행위와 의도를 정제된 언어로 출력하는 과정이다.

무엇을 하려 했는가 → 목표
왜 그 방식이었는가 → 배경
어떤 순서로 실행했는가 → 절차
그 결과 무엇을 깨달았는가 → 성찰

이 네 가지를 매일 기록하는 습관은 머릿속에 흩어져 있던 생각의 파편들을 논리적 체계 안에 정렬시킨다. 처음에는 칸을 채우는 것이 어렵다. 그런데 반복하다 보면 어느 순간 생각 자체가 이 구조로 움직이기 시작한다.

그리스 철학자 아리스토텔레스는 말했다.

"사람은 반복적으로 행하는 것에 의해 형성된다. 탁월함은 행동이 아니라 습관이다."

로그북이 단순한 기록 도구가 아닌 이유가 바로 여기에 있다.

AI는 내가 입력한 대로 움직인다

AI는 사용자가 입력한 데이터의 인과관계를 따라 결과물을 도출한다. 목표가 모호하면 결과도 모호하다. 맥락이 없으면 AI는 스스로 맥락을 채워 넣는데, 그것이 내가 원하는 방향과 다를 수 있다. 절차가 뒤섞여 있으면 AI의 답도 뒤섞인다.

반대로 말하면 이렇다. 목표를 명확히 정의하고, 배경을 상세히 설명하며, 실행 절차를 단계적으로 구조화하는 능력을 가진 사람은 AI를 제대로 쓸 수 있다.

그것이 바로 로그북이 훈련하는 능력이다.

로그북으로 다듬어진 사고의 근육을 가진 사람은 AI에게 지시할 때도 모호함이 없다. 자신이 기록해온 로그북의 구조대로 맥락을 제공하기만 하면, AI는 최상의 퍼포먼스로 응답한다.

그런 사람에게 AI는 위협이 아니라 자신의 사고를 증폭시켜주는 도구가 된다.

로그북 구조와 AI 프롬프트 구조는 같다

흥미로운 것은 로그북의 구조와 좋은 AI 프롬프트의 구조가 사실상 같다는 점이다.

로그북 항목 AI 프롬프트 요소

로그북	AI 프롬프트
수행목표	역할 및 페르소나 설정
오늘의 목표	목표(Goal) 명시
활동 내용·문제 해결	배경(Context) 및 절차 설명
달성도·결과	기대 결과물 정의
성찰	피드백 및 개선 요청

매일 로그북을 쓰는 것은 매일 AI 프롬프트를 설계하는 훈련과 본질적으로 같다. 즉, 로그북을 잘 쓰는 사람이 AI를 잘 쓰는 사람이 되는 이유다.

교육이 가르쳐야 할 것이 바뀌었다

교수가 지식을 주입하는 시대는 끝났다. 이제 중요한 것은 학생 스스로 자신의 사고 프로세스를 객관화하고, 이를 바탕으로 AI라는 거대한 지능과 정교하게 협업하는 능력이다.

그 능력은 특별한 기술을 배운다고 생기지 않는다. 매일 목표를 쓰고, 활동을 기록하고, 결과를 점검하고, 성찰을 남기는 습관에서 온다. 로그북을 통해 다져진 논리적 사고의 기초 체력이 AI 시대를 살아갈 가장 오래가는 경쟁력이 된다.

아홉 번의 이야기를 마치며

1회부터 9회까지, 로그북의 정의에서 시작해 작성법, 에러 유형, 그리고 왜 써야 하는지까지 다뤘다.

로그북은 칸을 채우는 도구가 아니다. 생각을 언어로 정렬하는 훈련이고, PDCA 사이클을 몸에 익히는 과정이고, 기록으로 나를 지키는 습관이고, AI 시대를 살아가는 기초 체력이다.

오늘부터 써보자. 처음엔 어색하다. 그래도 괜찮다. 습관은 완벽하게 시작하는 것이 아니라,
일단 시작하는 것에서 만들어진다.

7회. 로그북 논리 에러

일머리 강교수 — Sun, 19 Apr 2026 23:11:28 +0900

5회에서 항목정의 에러를, 6회에서 작성지침 에러를 살펴봤다. 두 가지를 모두 넘어서면 각 항목을 올바르게 쓸 수 있다. 그런데 마지막 관문이 하나 더 있다.

항목 하나하나는 맞는데, 전체를 읽으면 뭔가 어색하다. 오늘 이 사람이 무엇을 하려 했고 어떻게 됐는지 파악이 안 된다. 이것이 로그북논리 에러다.

각 항목을 올바르게 썼더라도, 항목과 항목 사이의 흐름이 논리적으로 연결되지 않는 것

목표가 가장 중요하다

로그북에서 가장 중요한 것은 오늘의 목표다. 오늘의 목표를 달성하기 위해 활동 내역이 나와야 하고, 활동 중 부딪힌 문제를 해결하는 것도 오늘의 목표를 달성하기 위한 것이 되어야 하고, 결과도 오늘의 목표 달성 여부를 보여주는 것이다.

그런데 실제로 학생들의 로그북을 보면 이것을 중요시 하지 않고 작성하는 경우가 많다. 목표가 분명하지 않다거나 활동이 목표와 무관하게 나열되거나, 결과가 목표 달성과 분명하게 연결되지 않는다. 항목 하나하나 작성에만 신경을 쓴 탓에 전체 내용에 일관성이 보이지 않는다.

나쁜 예:

오늘의 목표: 이해관계자 지도 작성 완료
활동 내용:
- ∙ 팀원과 카페에서 미팅
- ∙ 인터넷 자료 검색
달성도·결과: 70% 달성

목표는 '이해관계자 지도 작성'인데, 활동에는 지도를 작성한 흔적이 없다. 카페 미팅이 지도 작성을 위한 것인지, 자료 검색이 무엇을 위한 것인지 알 수 없다. 결과의 "70% 달성"도 무엇이 70%인지 파악이 안 된다.

좋은 예:

오늘의 목표: 이해관계자 지도 작성 완료
활동 내용:
- ∙ 이해관계자 분류 기준 설정 (팀 회의)
- ∙ 이해관계자 지도 초안 작성
- ∙ 팀 검토 및 수정
달성도·결과:
- ∙ 70% 달성
- ∙ 이해관계자 지도 초안 완성
- ∙ 인터뷰 일정 미확정 (미달성)

오늘의 목표를 중심으로 활동·문제해결·결과가 하나의 이야기로 읽힌다. 처음 보는 사람도 오늘 이 사람이 무엇을 하려 했고, 어떻게 했고, 어디까지 됐는지 한눈에 파악할 수 있다.

매일의 목표는 수행목표를 향해야 한다

오늘의 목표 중심으로 하루가 잘 연결되는 것만으로는 부족하다. 오늘의 목표와 내일 목표 및 계획이 학기 전체의 수행목표(O)를 향해 수렴해야 한다.

O-PDCA에서 O를 맨 앞에 놓은 이유가 바로 여기에 있다. 수행목표는 단순히 첫 번째 칸을 채우는 항목이 아니다. 매일의 로그북에 내재된 PDCA 사이클이 향해야 할 방향이다. O가 있어야 매일의 사이클이 축적이 된다. 없으면 열심히 돌아가도 방향이 흩어진다.

나쁜 예:

수행목표: 인터뷰 담당 — 현장 인터뷰 설계 및 진행
오늘의 목표: 보고서 서론 작성 완료
내일 목표 및 계획: 목표: 보고서 본론 작성 / 계획: ∙ 문헌 조사 ∙ 초안 작성

오늘과 내일의 목표가 내부적으로는 연결되어 있다. 그런데 수행목표인 "인터뷰 설계 및 진행"과는 어떤 연결이 되고 있는지가 분명하게 보이지 않는다.

좋은 예:

수행목표: 인터뷰 담당 — 현장 인터뷰 설계 및 진행
오늘의 목표: 인터뷰 질문지 초안 완성
내일 목표 및 계획: 목표: 인터뷰 담당자 섭외 완료 / 계획: ∙ 섭외 대상자 명단 확정 ∙ 연락 및 일정 조율

오늘과 내일의 목표가 모두 수행목표인 "인터뷰 설계 및 진행"을 향해 수렴하고 있다.

서술논리를 점검하는 두 가지 질문

로그북을 다 쓴 뒤 이 두 가지를 스스로 물어보면 로그북 논리 에러를 대부분 잡을 수 있다.

첫째. 오늘의 활동·문제해결·결과 항목의 내용이 오늘의 목표를 달성하기 위해 작성되어 있는가?

둘째. 오늘의 목표와 내일 목표 및 계획이 학기 전체의 수행목표(O)를 향해 수렴하고 있는가?

두 가지에 모두 "예"라고 답할 수 있다면 서술논리 에러가 없는 것이다.

로그북은 목표 중심으로 하루를 설계하는 훈련이다

로그북 논리 에러를 제대로 이해하면 로그북을 바라보는 시각이 달라진다.

로그북은 의무적으로 칸을 채우는 도구가 아니다. 수행목표라는 큰 방향 안에서, 오늘의 목표를 중심으로 활동·문제해결·결과를 논리적으로 연결하는 훈련이다. 이 훈련이 매일 반복될 때 목표 중심으로 생각하고 일하는 습관이 만들어진다.

그것이 로그북이 단순한 기록 도구를 넘어서서 사고를 체계화하는 도구가 되는 이유다.

6회. 작성지침 에러

일머리 강교수 — Sun, 19 Apr 2026 23:09:21 +0900

작성지침 에러는 로그북 작성 지침을 준수하지 않았을 때를 말한다.

대체로 로그북 작성 3원칙 — 객관성·구체성·가독성 — 을 지키지 않았을 때 나타난다.

작성지침은 반드시 이렇게 작성하여야 한다는 것은 아니다. 즉, 절대적인 지침은 아니다. 단, 지침을 지키면 정보의 전달력이 크게 상승하여 타인과의 공유가 쉬워진다
작성지침 에러에는 크게 다섯 가지 유형이 있고, 고치기 쉬운 것부터 순서대로 살펴본다.

① 서술 에러

정의: 문장을 컴팩한 개조식이 아닌 서술식(문장형)으로 쓰는 것.

로그북은 타인이 한눈에 읽을 수 있어야 한다. 서술식 문장은 읽는 데 시간이 걸리고, 핵심이 어디 있는지 파악하기 어렵다.

나쁜 예:

"인터뷰지 작성을 위해 원활한 소통을 했습니다. 학생용과 교육자용 구분을 했습니다."

좋은 예:

∙ 인터뷰지 작성 담당
∙ 학생용 / 교육자용 구분 및 최종안 완성

핵심 질문: 문장형이 아닌 개조식으로 한눈에 쉽게 읽히는가?

② 나열 에러

정의: 하나의 문장에 여러개의 주제가 나열되어 있는 경우.

여러개의 주제를 개별적으로 분리하여 불릿기호(·)와 줄바꿈으로 표현하면 가독성이 크게 향상된다

나쁜 예:

"자료조사, 회의 진행, 보고서 작성 및 역할 분담 논의"

좋은 예:

자료조사
팀 회의 진행
보고서 초안 작성
역할 분담 확정

핵심 질문: 각 내용이 명확히 구분되어 한눈에 쉽게 파악할 수 있는가?

③ 불명확 에러

정의: 표현이 구체적이지 않게 작성하는 것.

학생들이 많이 간과하는 부분이고 어려워하는 부분이다.

처음 보는 사람이 읽고 그 내용을 정확히 파악할 수 없다면 불명확 에러다.
예를 들어 그냥 "자료조사"라고 쓰면 자신은 무슨 자료인지 알겠지만 타인은 어떤 자료를 조사했는지 알 수 없다.

내가 현재 수행하고 있는 과제 주제와 연결하면 구체성을 확보하기가 쉬워진다.

나쁜 예:

"자료조사", "회의하기", "보고서 작성"

좋은 예:

발달장애인 견과류 선별 자동화 사례 조사
역할 분담 확정을 위한 팀 회의 (의사결정 완료 목표)
과제계획서 초안 작성 (서론·목적 섹션)

핵심 질문: 타인이 내용을 정확히 파악할 수 있을 만큼 구체적인가?

④ 주관 에러

정의: 사실(Fact) 대신 주관적인 감정·소감·다짐을 쓰는 것.

로그북은 일기를 작성하는 것이 아니기 때문에 객관적 사실을 바탕으로 기록하는 것이 원칙이다. "열심히 했다", "잘된 것 같다"라는 식으로 표현하는 경우가 있다. 이는 사실이 아니라 자기 판단이고 느낌이다.

다만 항목명 중 '성찰'은 예외로 둘 수 있다. 성찰은 유일하게 주관적 내용을 쓸 수 있는 칸이다. 그렇지만 이 때 소감이나 다짐을 표현하는 것보다 "생각의 변화"를 기록하는 것이 중요하다는 점은 5회에서 설명한 바 있다.

나쁜 예:

결과: "열심히 했다고 말은 못하지만 내가 해야 하는 일은 함"

좋은 예:

∙ 이해관계자 지도 작성 완료
∙ 인터뷰 질문지 초안 5개 항목 완성

핵심 질문: 문장 내에 주관적 느낌을 표현하지 않았는가?

⑤ 증빙 에러

정의: 결과를 데이터·이미지 등으로 뒷받침하지 않는 것.

증빙 에러는 주로 결과 항목을 작성할 때 범하는 실수 유형이다. 결과는 반드시 증빙하는 습관을 길러야 한다. 결과로 얻은 데이터와 사진을 첨부하는 방식을 사용한다.

나쁜 예:

결과: "센서 연결 완료" (증빙 자료 없음)
결과: "이해관계자 지도 작성 완료" (증빙 자료 없음)

좋은 예:

센서 연결 완료

(2026.04.07)센서연결완료.png

증빙 자료를 제출할 때 파일명 작성에도 신경을 쓰야 한다.
(일자)(수업명,팀이름,학생명)파일내용.확장자 형식으로 제출한다.
파일명만 봐도 누가, 언제, 무엇을 증빙하는지 알 수 있도록 작성하여야 한다.

나쁜 파일명 좋은 파일명

image-홍길동.jpg	(2026.04.01)(CD_Kim,어벤저스,홍길동)인터뷰질문지.jpg
사진.jpg	(2026.04.07)(CD_Park,바이오시그널,장길산)센서연결완료.png
1774951315930-장길산.jpg	(2026.04.02)(CD_Lee,뿌린조,황진이)과제계획서수정본.pdf

핵심 질문: 이 결과가 사실임을 확인할 수 있는가?

4회. 로그북 작성 에러 유형 개관

일머리 강교수 — Sun, 19 Apr 2026 17:05:09 +0900

1회에서 로그북의 정의를, 2회에서 7개 항목을, 3회에서 O-PDCA 사이클을 살펴봤다.

작성 원칙을 알고, 로그북의 항목을 나름 이해하고, 로그북의 기본이 되는 O-PDCA 사이클까지 파악했다.

그런데 학생들이 실제로 작성한 내용을 보면 미흡한 부분이 많다. 그 실수들은 무작위로 나타나지 않는다. 일정한 패턴을 가지고 있다. 그래서 그 패턴을 크게 세가지로 분류하여 에러의 유형이라 이름 붙여 보았다.

첫 번째 에러 — 항목정의

항목이 무엇을 요구하는지 모르고 엉뚱한 내용을 쓰는 경우다. "오늘의 목표"는 오늘 달성할 목표를 쓰는 칸이지, 오늘 한 활동을 쓰는 칸이 아니다. 항목의 정의를 오해한 것이기 때문에 표현을 다듬어도 해결되지 않는다. 칸이 무엇을 원하는지부터 다시 이해해야 한다.

나쁜 예: 오늘의 목표 — 자료 조사, 팀 회의, 보고서 작성
좋은 예: 오늘의 목표 — 이해관계자 지도 작성 완료

각 항목별 정의와 에러 사례는 5회에서 자세히 다룬다.

두 번째 에러 — 작성지침

항목이 무엇을 요구하는지는 알지만, 쓰는 방식이 잘못된 경우다. 로그북 3원칙인 객관성·구체성·가독성을 위반할 때 나타난다. 서술 에러, 나열 에러, 불명확 에러, 주관 에러, 증빙 에러 — 다섯 가지 유형이 있다.

나쁜 예: 자료를 조사하고 팀원들과 회의를 진행하였다
좋은 예: ∙ 자료 조사 ∙ 팀 회의 진행

다섯 가지 유형의 정의와 사례는 6회에서 자세히 다룬다.

세 번째 에러 — 로그북 논리

개별 항목을 맞게 썼는데, 전체를 놓고 보면 흐름이 끊어지는 경우다. 로그북의 정의인 "공유와 성장의 도구"가 되려면 항목과 항목 사이의 흐름이 논리적으로 연결되어야 한다. 오늘의 목표를 중심으로 활동·결과가 연결되지 않거나, 매일의 목표가 학기 전체의 수행목표(O)를 향해 수렴하지 않는 경우가 여기에 해당한다.

나쁜 예: 목표 — 이해관계자 지도 작성 완료 / 활동 — 팀원과 카페에서 미팅, 자료 검색
좋은 예: 목표 — 이해관계자 지도 작성 완료 / 활동 — 이해관계자 분류 기준 설정, 지도 초안 작성, 팀 검토

3회. O-PDCA와 로그북

일머리 강교수 — Sun, 19 Apr 2026 16:31:11 +0900

1회에서 로그북을 이렇게 정의했다.

"목표 달성을 위해 수행한 객관적 사실과 주관적 성찰을 기록함으로써, 타인과 정보 공유와 자기 성장을 동시에 이루는 도구"

로그북에는 중요한 하나의 원리가 작동하고 있다. 1950년대 품질관리의 아버지로 불리는 에드워즈 데밍이 정립한 PDCA 사이클이다. 로그북의 7개 항목은 이 PDCA 사이클 위에 설계되어 있다.

PDCA란 무엇인가

PDCA는 1950년대 품질관리에서 출발한 개념이지만, 지금은 일하는 방식 전반에 적용된다. 네 단계의 머리글자다.

P (Plan) — 목표를 세우고 계획을 수립한다
D (Do) — 계획대로 실행한다
C (Check) — 결과를 확인하고 평가한다
A (Act) — 평가를 바탕으로 다음을 개선한다

중요한 것은 A 다음에 다시 P가 온다는 것이다. 한 번으로 끝나는 직선이 아니라, 계속 돌아가는 사이클이다. 그리고 여기서 핵심이 있다 — 매 사이클이 이전보다 조금 나아진다. 원을 그리며 제자리로 돌아오는 것이 아니라, 위로 올라가는 나선이다. 이것이 PDCA가 단순 반복과 다른 이유다.

출처 : https://m.blog.naver.com/kcscpr/223139301197

PDCA는 새로운 것이 아니다. 우리는 이미 무의식적으로 PDCA를 생활 곳곳에 적용하고 있다. 다이어트를 예로 들어보자. 한 달 안에 3kg 감량이 목표다. 하루 1시간 걷기, 저녁 6시 이후 탄수화물 제한으로 계획(Plan)을 세운다.

실제로 걷고 식단을 조절한다. 실행(Do)이다. 매일 체중계에 올라간다. 점검(Check)이다. 목표대로 안 되고 있다면 원인을 찾는다. 저녁 약속이 많았다. 약속 전 미리 식사하는 방식으로 바꾼다. 개선(Act)이다. 그리고 다시 Plan으로 돌아간다.

로그북에 O가 추가된 이유

PDCA에는 아주 중요한 전제가 빠져 있다. "무엇을 위해 도는가"가 그것이다. 목표 없는 PDCA는 그냥 반복이다. 열심히 계획하고 실행하고 점검해도, 그것이 어디를 향하는지 모른다면 사이클은 제자리를 맴돈다.

그래서 로그북은 PDCA 앞에 하나를 더 붙인다. O (Objective), 즉 목표다.

O는 매일의 사이클을 관통하는 상위 목표다. 캡스톤디자인이라면 내가 이 과제에서 맡은 역할과 책임이고, 직장이라면 이 프로젝트에서 달성해야 하는 그 무엇이다. 불량률 5% 감소, 응급실 환자 대기시간 10분 단축, 월 신규고객 15% 증가 등이 그 예시이다.

O가 확정되어야 오늘 무엇을 계획하고 실행할지가 결정된다. O 없이 P부터 시작하면 매일 열심히 하는데 방향이 없다.

O-PDCA = 목표가 있는 사이클

로그북 7개 항목과 O-PDCA 매핑

O-PDCA 로그북 항목 핵심 질문

O	수행목표	나는 이 과제에서 무슨 역할인가?
P	오늘의 목표	오늘 무엇을 달성할 것인가?
D	활동 내용	실제로 무엇을 했는가?
D	문제 해결	어떤 문제가 있었고 어떻게 풀었는가?
C	달성도·결과	목표를 얼마나 달성했는가?
A	성찰	오늘 무엇을 새롭게 알게 됐는가?
A→P	내일 목표 및 계획	내일은 무엇을, 어떻게 할 것인가?

O-PDCA 동작모습

Act가 다음 Plan이 되는 순간

가장 중요한 연결이 있다. ⑦번 항목 '내일 목표 및 계획'이 다음 날의 '오늘의 목표'로 이어진다는 것이다.

이게 제대로 작동하면 로그북은 단순한 기록이 아니라 나선형 성장의 엔진이 된다. 오늘 성찰에서 이것을 깨달았다고 하자.

"이해관계자를 단순 나열하면 된다고 생각했는데, 실제로는 영향력 방향과 관계성을 함께 고려해야 했다."

이 성찰이 내일 목표를 바꾼다.

성찰 이전: "내일 인터뷰 진행" 성찰 이후: "목표: 인터뷰 설계 전 이해관계자 관계도 재검토 완료 / 계획: ① 관계도 수정 ② 영향력 기준 재설정 ③ 인터뷰 질문지 보완"

목표 자체가 달라진다. 오늘의 깨달음이 내일의 출발점을 바꾸는 것 — 이것이 사이클이 위로 올라가는 나선이 되는 순간이다.

왜 C와 A를 건너뛰면 안 되는가

로그북을 처음 쓰는 학생들이 가장 많이 건너뛰는 항목이 있다. 성찰과 내일 목표 및 계획이다. 오늘 한 일(D)과 결과(C)는 쓰면서, 그것을 바탕으로 한 성찰(A)과 내일 계획(A→P)은 대충 넘어간다.

그런데 C와 A 없이 D만 반복하면 PDCA가 아니라 그냥 일지다. 한 일을 나열하는 것과 사이클을 돌리는 것은 다르다. 매일 성찰하고 내일 목표를 다듬는 사람은 한 학기가 끝났을 때 출발점과 다른 자리에 있다.

로그북이 훈련인 이유

PDCA는 직장에서도 동일하게 작동한다. 업무계획을 세우고, 실행하고, 결과를 평가하고, 다음을 개선하는 것. 형식만 다를 뿐 구조는 같다.

지금 로그북으로 이 사이클을 훈련하는 것은, 나중에 직장에서 자연스럽게 이 방식으로 일하기 위해서다. 처음에는 항목을 채우는 것도 어렵다. 그런데 습관이 되면 사이클 자체가 몸에 밴다. 그게 로그북이 단순한 과제 제출물이 아닌 이유다.

2회. 로그북 구성 및 작성 방법

일머리 강교수 — Sun, 19 Apr 2026 14:20:33 +0900

로그북을 작성하라고 하면 학생들은 대개 당황해 한다. 그 이유는 로그북 자체가 이름도 낯설고 형식도 익숙하지 않기 때문이다.

로그북은 크게 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. 가독성 — 타인이 한눈에 읽을 수 있게 쓴다. 예를 들어 문장을 서술형이 아니라 개조식으로, 내용은 구분해서, 짧고 명확하게 작성하는 것을 말한다.

이 세 원칙이 지켜지면 구체적이고 객관적인 사실 위주의 기록이 되어 타인과의 공유가 쉬워진다. 나만 이해하는 기록이 아니라, 누구든 읽고 파악할 수 있는 문서가 된다. 그것이 로그북의 목적이며 직장생활에 필요한 협업 능력의 기초가 되기도 한다.

1회. 로그북이란 무엇인가?

일머리 강교수 — Sun, 19 Apr 2026 12:53:16 +0900

기록되지 않으면 공유되지 않는다

기업에서 모든 업무는 기록으로 관리된다. 아이디어도, 회의 내용도, 오늘 내가 한 일도 — 기록이 없으면 팀 안에서 공유되지 않는다. 공유되지 않는 일은 조직 입장에서 없는 일이나 마찬가지다.

이건 능력의 문제가 아니다. 습관의 문제다.

그리고 그 습관은 하루아침에 만들어지지 않는다. 직장에 들어간 뒤에 배우려 하면 이미 늦다. 일을 배우느라 정신이 없는 상황에서 기록까지 챙기는 건 두 가지를 동시에 처음 하는 것과 같다.

로그북은 바로 그 습관을 미리 훈련하는 도구다.

로그북(Logbook)이란?

로그북(logbook)은 1670년대에 처음 등장한 말로, 배의 속도를 측정하는 데 쓰던 나무 부표(log)에서 유래했다. 당시 선원들은 이 나무 조각을 바다에 던져 배의 속도를 측정하고, 그 수치를 책(book)에 기록했다. 측정 도구의 이름이 기록 행위의 이름이 된 것이다.

로그북은 선박의 항해 기록에서 출발했다. 선장은 바람, 속도, 방향, 위치를 매일 기록할 의무가 있었다. 의무였던 이유는 세 가지였다. 사고가 났을 때 원인을 명확히 밝히기 위해, 책임 소재를 가리기 위해, 그리고 다음 사람이 항해 정보를 이어받을 수 있도록 하기 위해서였다. 망망대해에서 기록은 생존의 도구였다.

이 원리는 바다를 넘어 하늘로 올라갔다. 1910년대 항공기가 등장하면서 조종사들은 비행 시간, 기종, 기상 조건, 이상 징후를 빠짐없이 기록하기 시작했다. 비행 로그북은 법적 의무 문서가 되었다. 바다와 하늘, 환경은 달랐지만 원리는 같았다.

과학자들도 같은 결론에 도달했다. 실험실에서 연구자들은 실험 방법, 절차, 데이터, 결과를 날짜별로 기록하는 실험실 노트(lab notebook)를 발전시켰다. 기록이 없으면 실험을 재현할 수 없고, 재현할 수 없으면 과학이 성립하지 않는다.

그리고 교육 분야로 왔다. 1870년대부터 학생의 학습 과정을 기록하는 도구로 도입되기 시작했고, 오늘날 캡스톤디자인 로그북으로 이어진다. 무엇을 배웠는지가 아니라 어떻게 생각하고 행동했는지를 기록한다. 결과가 아니라 과정을 남긴다.

1960년대 이후에는 디지털 세계로도 확장되었다. 컴퓨터 서버가 무슨 일을 했는지 자동으로 기록하는 시스템 로그, 원자력 발전소와 입자가속기의 운영 기록까지 — 형식은 달라도 본질은 같다.

분야는 달라도 로그북이 확장된 곳에는 항상 같은 이유가 있었다.

복잡한 일을 다루는 곳, 책임이 필요한 곳, 성장이 요구되는 곳. 항해도, 비행도, 실험도, 업무도 — 혼자 머릿속으로만 처리하기엔 너무 복잡하고, 실수가 생겼을 때 기록이 없으면 원인을 찾을 수 없다.

로그북은 그 필요에서 자연스럽게 퍼져나갔다.

일기와 다른 점, 보고서와 다른 점

일기는 '나를 위한 기록'이다. 감정을 쏟아내도 괜찮고, 비밀이어도 괜찮다.

보고서는 '최종 결과에 대한 기록'이다. 완성된 것을 정리해서 제출하는 것이 보고서이다.

로그북은 그 사이에 있다. 중간 과정을 기록하되, 타인이 읽을 수 있도록 쓴다. 아직 완성되지 않은 오늘의 일을, 처음 보는 사람도 이해할 수 있는 언어로 남기는 것. 그것이 로그북이다.

지금 쓰는 로그북이 곧 내일의 업무일지다

신입사원이 되면 매일 업무일지를 쓰는 회사가 많다. 처음에는 무엇을 어떻게 써야 할지 몰라 막막하다. 그 막막함은 '쓰는 법'을 몰라서가 아니라, 기록이라는 행위 자체에 익숙하지 않아서 생긴다.

로그북은 그 훈련이다. 캡스톤디자인 수업에서 매주 쓰는 이 기록이, 실은 직장에서 매일 쓰게 될 업무일지의 예행연습이다.

처음에는 어색하고 번거롭다. 그런데 습관이 되면, 생각이 정리되고, 일이 보이고, 그것이 실력이 된다.

다음 글에서는 로그북이 어떤 항목으로 구성되어 있는지, 각 항목을 어떻게 작성해야 하는지를 살펴본다.

바이브 코딩 경험 - 프론트엔드/백엔드 연동

일머리 강교수 — Sun, 19 Apr 2026 06:23:42 +0900

나는 이번 바이브 코딩을 통하여 몇가지 중요한 개념을 배웠다. 이 개념을 프론트엔드, 백엔드 연동, 데이터 저장, 웹호스팅, 버전관리, 네트워크, 디버깅, 보안, 그리고 모바일 대응으로 분류하여 차례로 정리해 보겠다

프론트엔드(Frontend)란?

사용자가 직접 눈으로 보고 손으로 조작하는 화면 부분을 말한다.

앱을 열었을 때 보이는 입력 칸, 버튼, 날짜 표시, 체크박스 — 이 모든 것이 프론트엔드다. 쉽게 말해 "사용자와 맞닿는 면"이다.

주요 기술은 세 가지로 구성된다. 이 세 가지는 별개가 아니라 하나의 HTML 파일 안에 함께 담긴다.

HTML은 페이지의 뼈대를 만든다. 어떤 항목이 어디에 배치될지, 입력 칸은 몇 개인지를 정의한다.
CSS(Cascading Style Sheets) 는 그 뼈대에 옷을 입힌다. 글자 크기, 색상, 버튼 모양, 모바일에서 화면이 잘리지 않도록 하는 반응형 레이아웃이 여기에 해당한다.
JavaScript는 화면에 생명을 불어넣는다. 오늘 날짜를 자동으로 불러오고, 전날 "내일 할 일"을 오늘 칸에 채워주고, 3초마다 자동 저장하고, 이달 지출 합계를 계산하는 것 — 이 모든 동작이 JavaScript의 역할이다.

백엔드 연동(Backend Integration)이란?

사용자가 화면에서 입력한 데이터를 어딘가에 저장하고, 필요할 때 다시 불러오는 과정을 말한다. 프론트엔드가 "보이는 면"이라면, 백엔드는 "보이지 않는 면"이다. 로그북 앱에서 저장 버튼을 눌렀을 때 구글 시트에 기록이 남는 것, 그것이 백엔드 연동의 결과다.

이 앱에서 백엔드 연동의 핵심 기술은 Google Apps Script(GAS)이다. GAS는 구글이 제공하는 자동화 도구로, 구글 시트·구글 문서·구글 폼 등 구글 서비스를 코드로 제어할 수 있게 해준다. 이 앱에서는 두 가지 역할을 담당했다. doPost는 프론트엔드에서 데이터가 넘어오면 받아서 구글 시트에 저장하는 입력 역할이고, doGet은 저장된 데이터를 날짜 기준으로 찾아서 다시 화면으로 보내주는 조회 역할이다.

GAS를 작성한 뒤 '웹앱으로 배포'하면 고유한 URL이 하나 생성된다. 프론트엔드는 이 URL로 데이터를 보내고 받는다. 이 URL이 프론트엔드와 백엔드를 연결하는 다리 역할을 한다.

좀 더 비유적으로 설명을 하면 URL은 GAS의 현관 주소에 해당한다. 프론트엔드는 이 주소(URL)를 이용하여 GAS에 요청을 한다. "이 데이터 저장해 주세요", "이 날짜 데이터 꺼내주세요". 그러면 GAS는 해당 내용을 처리해 주는데, 그 처리하는 함수가 입력일 때는 (doPost), 출력일 때는 (doGet)이다. 바이브 코딩을 통하여 URL이 전달되는 과정을 설명하면 다음과 같다

URL 전달 과정

GAS를 웹앱으로 배포하면 구글이 고유한 URL을 자동 생성
그 URL을 화면에서 복사
Claude에게 "이 URL 넣어서 코드 수정해 주세요"라고 전달
Claude가 index.html 안에 그 URL을 하드코딩으로 삽입
이후 저장 버튼을 누를 때마다 프론트엔드가 그 URL로 자동 요청

즉 URL은 자동으로 연결되는 게 아니라, 내가 배포를 한 뒤 생성된 URL을 클비서에게 전달을 했다.

그리고 여기서 배포 개념에 대한 이해가 필요하다. 배포는 GAS가 웹앱 URL를 만드는 것을 말한다.
주의할 점은 중간에 GAS의 코드를 수정해도 배포 URL에 자동 반영되지 않는다는 점이다. 반영하려면 반드시:

GAS 편집기 상단 → 배포 클릭
배포 관리 선택
연필(✏️) 아이콘 → 버전: 새 버전 선택
배포 클릭

그래야 기존 URL 그대로 유지되면서 수정 내용이 반영된다. 새 배포를 선택하게 되면 URL을 새로 생성하는 것이다. 그렇게 되면 이미 프론트엔드에 전달되었던 URL도 수정해야 하는 번거로움이 생기게 되므로 기존 URL을 그대로 두면서 새 버전을 선택하는 것이 좋다.