두 갈래 코딩 로그: 배운 것과 배포한 것을 나눠 적으면, 드디어 ‘지식’과 ‘성과’가 또렷해진다

대부분의 개발자는 어떤 식으로든 메모를 남깁니다. Notion에 쌓인 코드 조각들, 코드 안에 남긴 암호 같은 주석, stuff라는 이름의 스크린샷 폴더, 반쯤만 채워진 마크다운 파일들의 공동묘지까지.

늘 뭔가를 배우고 있는 것 같지만, 예전에 분명 한 번 풀어봤던 문제를 다시 마주하면… 마치 처음 보는 것처럼 막막할 때가 많습니다. 머릿속 어딘가(혹은 하드 디스크 어딘가)에 지식은 있는 것 같은데, 정작 필요할 때 꺼내 쓰질 못합니다.

의외로 단순한 해결책이 있습니다. 코딩 메모를 두 개의 트랙으로 분리해서 적는 것입니다.

1. 배운 것 (개념, 아이디어, 패턴)
2. 배포한 것 (기능, 버그, 업무, 커밋)

이걸 **두 갈래 코딩 로그(Two-Track Coding Log)**라고 부르겠습니다. 가볍고 유지하기 쉽고, 시간이 지날수록 점점 강력한 개인 지식 베이스로 자라납니다. 그것도 당신이 실제로 어떻게 배우고, 어떻게 만드는지에 딱 맞게요.

지금 쓰는 개발 메모가 잘 안 남는 이유

대부분의 코딩 메모는 한 번에 모든 걸 다 하려고 합니다.

• 따라 보는 튜토리얼 내용
• Stack Overflow에서 복사해 온 답변
• 버그 리포트나 TODO 목록
• 설계 아이디어나 아키텍처 스케치

이게 한데 섞여 있다 보니, 몇 가지 문제가 생깁니다.

• 나중에 찾기 너무 어렵습니다. “promise는 어떻게 동작하더라”를 찾고 싶은데, 배포 로그 사이에 무작위 쉘 명령어와 함께 파묻혀 있습니다.
• 패턴이 안 보입니다. 비슷한 유형의 버그를 계속 고치는데도, “아 이거 그때 그 문제네” 하고 재사용 가능한 교훈으로 연결되지 않습니다.
• 성장이 안 느껴집니다. 어제 한 일과 오늘 한 일이 비슷해 보입니다. 내 이해도가 어떻게 달라지고 있는지, 이야기가 보이지 않습니다.

두 갈래 코딩 로그는 **배움(learning)**과 **배포(shipping)**를 분리하면서도, 이 둘을 서로 연결해 줌으로써 이 문제를 해결합니다.

두 개의 트랙: Learn Log vs Ship Log

이 시스템의 핵심은 아주 단순한 두 개의 별도 로그입니다.

1. Learn Log: “지금 내가 이해한 것”

이 트랙에는 개념, 인사이트, 패턴을 기록합니다. 즉, 개발자로서 내 머릿속 모델을 업그레이드해 주는 모든 것들입니다.

예를 들어 이런 식입니다.

• "배움: useEffect의 dependency 배열이 왜 중요한지, 그리고 어떻게 무한 루프를 유발하는지 이해함."
• "개념: 유닛 테스트, 통합 테스트, E2E 테스트의 차이."
• "패턴: JavaScript에서 언제 map, forEach, reduce를 써야 하는지."
• "실수: 배열을 slice할 때 off-by-one 에러가 난 원인과, 이런 실수를 어떻게 미리 알아챌 수 있는지."

전부를 문서화하려는 게 아닙니다. 내가 실제로 마주친 세계를 문서화하는 겁니다.

형식은 자유지만, 다음 세 가지만은 지키면 좋습니다.

• 짧게 – 몇 문장 혹은 몇 개의 bullet point
• 구체적으로 – 실제 코드, 실제 버그, 실제 결과를 언급
• 검색 가능하게 – 나중에 검색할 만한 키워드를 꼭 포함

이렇게 쌓인 Learn Log는 시간이 지나면 나만의 교과서가 됩니다. 남의 말이 아니라, 내가 직접 겪고 필요해서 적어 둔 설명들로만 채워진 교과서입니다.

2. Ship Log: “내가 실제로 만든 것”

이 트랙에는 실제로 시도하거나 배포한 작업을 기록합니다. 기능 개발, 버그 수정, 실험(spike), 리팩터링 등입니다.

예시는 다음과 같습니다.

• "기능: 비밀번호 재설정 플로우 추가 (백엔드 토큰 + 이메일 링크)."
• "버그 픽스: 프로필 저장 시 race condition – API 호출에 디바운스를 걸어 해결."
• "리팩터링: 커스텀 이벤트 버스를 Redux로 교체해 전역 상태 관리."
• "스파이크: 실시간 업데이트를 위한 WebSocket 지원 테스트 – PoC 브랜치 남겨 둠."

각 항목은 아주 짧아도 되지만, 최소한 이건 포함해야 합니다.

• 무엇을 시도했거나 만들었는지
• 왜 그렇게 했는지
• 코드가 어디에 있는지 (브랜치, 레포지토리, 파일 경로, PR 링크 등)

이렇게 쌓인 Ship Log는 **나만의 변경 이력(changelog)**이 됩니다. 회사 일, 사이드 프로젝트, 공부용 토이 프로젝트가 뒤섞여도, 내가 어떤 일을 해왔는지 분명한 서사가 생깁니다.

진짜 마법은 두 트랙을 ‘서로 연결할 때’ 생긴다

트랙을 나누는 것 자체보다 중요한 건, 이 둘을 서로 참조하게 만드는 것입니다.

• Learn Log 항목에는, 그 개념을 어디에서 적용했는지 혹은 깨달았는지에 해당하는 Ship Log를 링크합니다.
• Ship Log 항목에는, 그 작업을 하면서 무엇을 배웠는지에 해당하는 Learn Log를 링크합니다.

예를 들어:

• Ship Log: 2025-01-03 – React 프로필 페이지에서 무한 re-render 버그를 수정. 원인: useEffect dependency 누락.

  • 링크: Learn Log – useEffect dependency 이해하기

• Learn Log: useEffect dependency 이해하기

  • 링크: Ship Log – React 프로필 페이지 re-render 버그 수정

이렇게 서로를 교차 링크하면, 중요한 효과가 생깁니다.

1. 추상적인 개념이 실제 경험에 단단히 닻을 내립니다. “React를 안다”가 아니라, *“프로필 페이지 한 번 날려 먹고, 그걸 고치면서 배운 React”*로 기억됩니다.
2. 실수가 재사용 가능한 자원이 됩니다. 버그 하나가 일회성 짜증으로 사라지는 대신, 다음에 알아볼 수 있는 패턴이 됩니다.
3. 시간이 지나면 반복되는 주제가 눈에 띕니다. 버그의 절반이 비동기 코드에서 나오거나, 데이터 모델링 실수거나, off-by-one 에러일 수 있습니다. 이건 “다음에 뭘 깊게 공부해야 할지”에 대한 힌트가 됩니다.

실수를 ‘다시 쓸 수 있는 교훈’으로 바꾸기

많은 개발자는 버그를 그냥 잠깐의 귀찮은 일 정도로 취급합니다. 고치고, 넘기고, 잊으려고 합니다.

두 갈래 로그는 정반대를 권장합니다. 버그를 붙잡고, 분석하고, 재활용하라는 방향입니다.

버그를 마주치거나 실수를 했을 때 이렇게 해봅니다.

1. 먼저 Ship Log에 짧게 기록합니다.

   • 원래 하려던 일은 무엇이었는지
   • 무엇이 잘못됐는지 (겉으로 보이는 증상)
   • 어떻게 고쳤는지

2. 그다음 Learn Log에 정리합니다.

   • 이 버그 뒤에 숨어 있는 일반적인 원리나 패턴은 무엇인지
   • 다음에는 어떻게 미리 알아차리거나 피할 수 있을지
   • 가능하다면 최소한의 코드 예제나 스니펫을 추가

예시 쌍을 보겠습니다.

• Ship Log: 2025-01-08 – 폼 제출이 두 번 실행됨. 원인: button type="submit" + onClick에서 수동으로 submit을 한 번 더 호출.

• Learn Log: 중복 폼 제출 문제

  • 증상: 한 번 클릭할 때 API 엔드포인트가 두 번 호출됨.
  • 근본 원인: 폼의 기본 submit 동작 + 커스텀 submit 코드가 동시에 동작.
  • 교훈: 제출 경로를 하나만 사용하기. 폼의 onSubmit에만 의존하거나, preventDefault로 막고 수동으로만 처리하기.

다음에 비슷한 이중 요청 이슈를 보면, 완전히 처음 보는 문제가 아닙니다. 이미 한 번 정리해 둔 패턴을 다시 꺼내 쓰는 거죠.

이렇게 쌓이면 ‘가벼운 개인 지식 베이스’가 된다

회사에서는 지식을 공유하기 위해 Confluence, Notion, 위키, 설계 문서 같은 도구를 씁니다.

두 갈래 코딩 로그는 비슷한 역할을 하지만, 대상이 **팀이 아니라 ‘나 자신’**이라는 점이 다릅니다.

• 개념(Learn Log) 항목은 작은 문서 페이지 역할을 합니다. 정의, 패턴, 주의할 점(gotcha) 등을 담습니다.
• 작업(Ship Log) 항목은 내가 만진 코드베이스와 프로젝트의 히스토리를 검색 가능한 형태로 남깁니다.
• 교차 링크는 낱개의 메모를 서로 연결된 이해의 그래프로 바꿉니다.

결과적으로, 아주 가벼운 형태의 개인 지식 베이스가 생깁니다. 이건 이렇게 활용할 수 있습니다.

• 막힐 때 검색해서 비슷한 사례를 찾아보기
• 새 프로젝트를 계획할 때 과거 경험을 훑어보기
• 블로그 글, 발표, 포트폴리오에 쓸 소재를 고를 때 아이디어 뽑기

이제 의미 있는 작업과 배움이, 잊힌 브랜치나 닫힌 브라우저 탭 속으로 사라지지 않습니다. 대부분의 중요한 경험에 작은 발자국이 남습니다.

보이지 않던 성장을 ‘눈으로’ 확인하기

하루하루로 보면, 내가 성장하고 있는지 느끼기 어렵습니다.

버그를 하나 고치고, 기능을 하나 만들고, 영상을 하나 보고, 글을 하나 읽어도… 전부 흐릿하게 섞여 버립니다.

두 갈래 코딩 로그를 돌아보면 이 안개가 걷힙니다.

• 한 달 전 로그를 훑어보며, 그때는 무엇에 막혀 있었는지 본다.
• 지금 정리하고 있는 개념을, 1년 전에는 어떻게 이해 못 하고 있었는지 비교해 본다.
• 메모의 내용이 “X를 어떻게 하지?”에서 “X를 하는 여러 방법의 트레이드오프는?”으로 변해 가는 걸 확인한다.

이걸 더 효과적으로 만들려면, 간단한 리뷰 루틴을 넣어봅니다.

• 주간(10–15분): 지난 일주일의 항목을 훑어보고, 핵심 교훈 2–3개를 표시.
• 월간(30분): 패턴을 찾습니다. 이슈가 특히 많이 쌓이는 영역이 테스트인지, 상태 관리인지, 데이터베이스 설계인지.
• 분기별(45–60분): 반복해서 등장한 주제 하나를 골라, 집중 연습이나 더 깊은 학습 계획을 세웁니다.

이건 단순히 “기분 좋아지기”가 목적이 아닙니다(물론 그런 효과도 있습니다). 실제 기록에 기반해서, 학습 방향을 의도적으로 조정하는 도구입니다. 랜덤 튜토리얼이 아니라, 내 역사에 근거한 로드맵인 거죠.

나만의 두 갈래 코딩 로그 시작하기

멋진 도구는 필요 없습니다. 중요한 건 일관성과 낮은 진입 장벽입니다.

먼저, 진짜 쓸 만한 매체 하나를 고르세요.

• /learn, /ship 두 폴더만 있는 단일 마크다운 레포
• Notion에서 두 개의 데이터베이스
• Obsidian, Logseq, Evernote 같은 노트 앱에서 두 개의 최상위 노트북/태그

그리고 구조를 아주 단순하게 유지합니다.

• Ship Log 항목:

  • 날짜
  • 짧은 제목
  • 무엇을 만들었는지/고쳤는지
  • 코드 위치(레포, 브랜치, PR, 파일 경로 등)
  • 옵션: 관련 Learn Log 링크

• Learn Log 항목:

  • 개념 이름 또는 짧은 설명
  • 2–6개의 bullet point로 요약
  • 옵션: 코드 스니펫
  • 이 개념이 등장한 Ship Log 항목 링크 1개 이상

처음에는 아주 작게 시작해서, 필요에 따라 발전시키면 됩니다.

첫 일주일은 이렇게만 목표를 잡아봅니다.

• 하루에 Ship 항목 1–3개 ("CSS 버그 디버깅함" 정도도 괜찮습니다.)
• 하루에 Learn 항목 1개 ("array filter가 이제 익숙해짐" 같은 아주 작은 것도 OK)

처음부터 시스템을 과하게 설계하지 마세요. 템플릿이나 태그 구조는, 써보면서 불편함이 느껴질 때 조금씩 다듬어도 늦지 않습니다.

마무리: 일과 배움이 서로 말하게 만들어라

우리는 모든 걸 다 기억할 필요는 없습니다. 대신, 필요할 때 다시 연결할 수 있는 믿을 만한 방법만 있으면 됩니다.

두 갈래 코딩 로그는 딱 그 역할을 합니다.

• 배운 것과 배포한 것을 분리해, 메모를 더 명확하고 쓸모 있게 만듭니다.
• 실수와 버그를, 반복되는 짜증이 아니라 재사용 가능한 패턴으로 바꿉니다.
• 실제 프로젝트와 실제 문제에 맞춰진, 가벼운 개인 지식 베이스를 만들어 줍니다.
• 성장 과정을 눈에 보이게 만들어, 내가 얼마나 멀리 왔고 어디로 가야 할지 알 수 있게 해 줍니다.

어차피 어려운 일은 이미 하고 있습니다. 코드를 쓰고, 버그를 고치고, 문서를 읽고, 새벽 2시에 에러와 싸우고 있죠.

이 시스템이 하는 일은, 그 고생에서 나오는 가치를 놓치지 않고 붙잡는 것뿐입니다.

지금 하고 있는 다음 작업, 혹은 다음에 만나는 버그에서 시작해 보세요. Ship Log 항목 하나를 쓰고, Learn Log 항목 하나를 씁니다. 그리고 둘을 서로 링크합니다.

그걸 계속 반복해 보세요. 1년쯤 지나면, 단지 “경험이 늘어난” 것이 아니라, 내가 어떤 과정을 거쳐 지금의 개발자가 되었는지 잘 정리된 지도가 손에 들어 있을 겁니다.