세 통짜리 코딩 저널: 아이디어, 실험, 결정을 나눠서 개발자 뇌를 가볍게 만들기

코드를 짜는 동안, 당신의 뇌는 너무 많은 일을 동시에 하고 있다.

지금도 이런 일들을 한꺼번에 하느라 바쁘다:

• 문제를 이해하기
• 반쯤 해둔 실험 기억하기
• 여러 대안 솔루션 비교하기
• TODO와 엣지 케이스 추적하기
• 왜 A가 아니라 B 방식을 선택했는지 떠올리기

이 대부분은 결국 이렇게 흩어져 버린다:

• 여기저기 섞여 있는 주석
• 랜덤 노트
• 까먹은 결정들
• 나중에는 거짓말이 되어버리는 포스트잇 메모들

간단한 해결책: 노트를 코드처럼 다루는 것이다.

여기서 등장하는 것이 바로 세 통짜리 코딩 저널(Three-Bucket Coding Journal) — 생각을 세 가지 카테고리로 나누는 미니멀 시스템이다.

1. 아이디어(Ideas)
2. 실험(Experiments)
3. 결정(Decisions)

이 작은 구조 변화만으로도 개발자 뇌를 차분하게 만들고, 작업 흐름을 추적 가능하게 바꾸며, “메모”를 개발 프로세스의 능동적이고 강력한 일부로 전환할 수 있다.

왜 개발자 뇌에 ‘버킷’이 필요한가

모든 걸 생각나는 대로 한 줄기 로그에 때려 넣으면 이런 일이 벌어진다:

• 덜 다듬어진 아이디어와 최종 결론이 섞여 버리고
• 오래된 실험 결과가 아직도 사실인 것처럼 남아 있고
• 중요한 결정은 텍스트 벽 속에 파묻히고
• 다시 읽고 싶지 않은 노트만 잔뜩 쌓인다

인지적으로 보면, 뇌는 동시에 분류, 필터링, 비교, 기억 유지를 모두 수행하고 있다. 이건 당연히 피곤하다.

해결책은 전형적인 알고리즘 아이디어인 **버킷 소트(bucket sort)**와 닮아 있다.

매번 노트를 다시 평가하는 대신, 먼저 버킷(통)에 떨어뜨린다 — 아이디어, 실험, 결정 중 하나로. 각 버킷 안에서는 나중에 천천히 정리하고 다듬으면 된다.

무엇을 생각하는지(아이디어), 무엇을 실제로 시도하는지(실험), **무엇을 선택했는지(결정)**를 분리해 두면, 저널은 이렇게 변한다:

• 훨씬 탐색하기 쉽고
• 되돌아보기도 편하고
• 믿을 수 있는 자료가 된다

그리고 더 이상 모든 걸 뇌의 RAM에 올려둘 필요가 없다.

세 개의 버킷: 아이디어, 실험, 결정

버킷 1: 아이디어 (Ideas)

여기에 들어갈 것:

• 가능한 접근 방식들
• 나중에 해볼 수 있는 리팩터링
• 여러 가지 설계(디자인) 대안
• 성능 개선 아이디어
• “만약 우리가 이렇게 해본다면…?” 류의 생각들

목표: 약속이 아닌 가능성을 담는 것.

예시:

• "아이디어: 알림을 폴링에서 WebSocket 기반으로 바꾸기. 장점: 네트워크 트래픽 감소, 실시간 UX. 단점: 인프라 복잡도 증가."
• "아이디어: 할인 로직을 별도 PricingRules 서비스로 분리. 체크아웃 컨트롤러 단순화 가능할 듯."

왜 도움이 되는가:

• 모든 ‘번뜩이는 생각’을 기억해 둘 필요가 없어서 뇌가 한결 가벼워진다.
• 시간이 지난 뒤, 더 맑은 정신으로 다시 검토할 수 있는 선택지 목록이 된다.
• 브레인스토밍과 구현을 분리해, 코딩 중에 계속 스스로를 의심하는 일을 줄여준다.

버킷 2: 실험 (Experiments)

여기에 들어갈 것:

• 실제로 시도해 본 것들
• 실행한 명령어
• 사용한 디버깅 전략
• 작은 프로토타입이나 코드 스니펫
• 벤치마크 및 프로파일링 결과

목표: 성공이든 실패든, 실제로 무엇을 했는지를 기록하는 것.

예시:

• "실험: Redis로 사용자 프로필 호출을 캐싱해 봄. 결과: 약 25% 빨라졌지만, 프로필 수정 시 캐시 무효화가 까다로움."
• "실험: /api/orders에 빈 payload를 보내서 버그 재현. 스택 트레이스가 OrderSerializer를 가리킴."
• "실험: 벤치마크 — old = 450ms, new = 220ms ( perf 로 프로파일링. 주요 개선점: N+1 쿼리 제거)."

왜 도움이 되는가:

• 예전에 실패했던 실험을 다시 반복하는 일을 막아준다.
• 디버깅이 ‘운’에 맡기는 작업이 아니라, 훨씬 체계적이고 구조적인 과정이 된다.
• 스스로의 문제 해결 과정을 되짚어보며 개선할 수 있다.

이제 더 이상 "지난번에 뭐 해봤지?" 하고 머리를 쥐어짤 필요 없이, Experiments 버킷을 쭉 스크롤하면 된다.

버킷 3: 결정 (Decisions)

여기에 들어갈 것:

• 선택한 아키텍처나 설계 방향
• 라이브러리, 프레임워크 선택
• 네이밍 컨벤션
• API 계약(Contract)
• 명시적으로 받아들인 트레이드오프

목표: 무엇을, 왜 그렇게 결정했는지를 남겨서, 미래의 나(또는 동료들)가 추측하지 않도록 만드는 것.

예시:

• "결정: v1에서는 Elasticsearch 대신 PostgreSQL full-text search 사용. 이유: 인프라 단순화, 구성 요소 수 감소, 10만 건 미만 데이터에는 충분한 성능."
• "결정: UserService는 얇게 유지하고 비즈니스 룰은 도메인 오브젝트로 밀어 넣기. 이유: anemic model(빈약한 도메인 모델) 방지."
• "결정: 중복 회원가입에 대해 400이 아니라 409 Conflict 반환. 이유: 의미론적으로 더 정확하고 클라이언트 처리도 간단."

왜 도움이 되는가:

• *"우리가 왜 이렇게 했더라?"*라는 질문에 빠르게 답할 수 있다.
• 이미 끝난 논의를 다시 자전거 타이어처럼(=bikeshedding) 끝없이 되풀이하는 일을 줄인다.
• 사람 눈으로 읽기 좋은, reasoning(사고 과정) 중심의 가벼운 변경 로그 역할을 한다.

만약 버킷을 하나만 유지해야 한다면, 결정(Decisions) 버킷을 택하라. 장기적인 가치는 거기에 가장 많이 쌓인다.

개발의 일부로 메모하기 (부록 작업이 아니다)

코딩 저널이 가장 잘 작동하는 때는, 이를 부가 업무가 아니라 개발의 일부로 취급할 때다.

디버거, 린터처럼 하나의 개발 도구라고 생각하면 좋다.

• 계획 단계: 떠오르는 아이디어를 적어 둔다.
• 디버깅 중: 시도해보는 것들을 실험으로 계속 기록한다.
• 배포하거나 머지한 후: 방금 내린 결정을 정리해 적는다.

이렇게 하면:

• 선택을 더 의식적으로 내리게 되고
• 실험을 더 엄밀하게 수행하게 되며
• 트레이드오프에 더 민감해진다.

또한 이해도도 깊어진다. 글로 쓰는 과정 자체가 이런 질문을 명확히 하도록 만든다:

• "지금 정확히 무엇을 시도하는가?"
• "무엇이 성공 조건인가?"
• "이 결정을 통해 어떤 리스크를 받아들이는가?"

이런 성찰 과정에서 진짜 학습이 많이 일어난다.

분산되지 않는, 단 하나의 신뢰할 수 있는 장소

툴이 화려할 필요는 없다. 대신 다음 세 가지만 만족하면 된다:

• 중앙 집중화 – “여기에만 있으면 된다”라고 믿을 수 있는 단 하나의 장소
• 검색 가능성 – 나중에 실제로 찾을 수 있어야 한다
• 백업 – 노트가 노트북과 함께 증발하지 않아야 한다

추천할 만한 형태:

• 하나의 Markdown 리포지토리 (예: Git에 dev-journal/ 디렉터리)
• 태그를 지원하는 노트 앱 (Obsidian, Logseq, Notion 등)
• 개인 위키 / 개인 지식베이스

가장 중요한 건, 노트가 다섯 군데 시스템에 흩어지지 않는 것이다.

예를 들어 이런 구조를 쓸 수 있다:

/dev-journal
  ├─ 2026-01-05-feature-x.md
  ├─ 2026-01-10-bug-1324.md
  └─ decisions-architecture.md

각 파일 안에서는 세 개의 버킷을 헤딩으로 사용한다.

버킷 소트에서 빌려오기: 먼저 모으고, 나중에 정리하기

버킷 소트는 처음부터 모든 원소를 전역적으로 비교하지 않는다. 먼저 버킷에 그룹핑한 뒤, 각 버킷 안에서 정렬한다.

노트에도 같은 원칙을 적용하자:

1. 첫 번째 패스: 이건 아이디어인가, 실험인가, 결정인가만 재빨리 정한다.
2. 두 번째 패스(나중에): 정리, 재구성, 리팩터링, 관련 노트 간 링크 추가 등을 한다.

이렇게 하면 코딩 플로우를 깨지 않고도 저널을 유지할 수 있다. 그 순간에는 완벽한 구조를 고민할 필요가 없다. 그저

"지금 이 메모를 어느 버킷에 넣을지만 정하고, 다듬기는 나중에 한다."

라고 생각하면 된다.

리뷰도 훨씬 쉬워진다:

• 다음 단계를 계획할 때는 아이디어만 훑어보고
• 비슷한 문제를 디버깅할 때는 실험만 모아서 보고
• 온보딩이나 리팩터링을 시작할 때는 결정만 쭉 읽어본다.

저널을 더 탐색하기 쉽게: 태그, 링크, 간단한 시각화

세 개의 버킷이 준비됐다면, 여기에 몇 가지 가벼운 도구를 더해 시스템을 업그레이드할 수 있다.

1. 태그

태그로 파일과 시간을 가로질러 노트를 묶어보자:

• #performance
• #security
• #frontend / #backend
• #bug / #feature

예시:

결정: 모바일 앱 인증을 JWT 기반 토큰으로 전환. 이유: 오프라인 지원, 스케일링 단순화. 트레이드오프: 토큰 무효화 로직이 더 복잡해짐. #security #mobile

태그는 별도의 인덱스를 만들지 않아도, 저널 전체를 색인처럼 사용할 수 있게 해준다.

2. 링크와 위키 스타일

툴이 지원한다면, 관련 노트를 서로 링크하자:

• 어떤 결정이 어떤 실험들에서 나왔는지 연결
• 여러 프로젝트에 반복 등장하는 아이디어를 서로 연결해 패턴을 보기

예시:

결정: 이메일 발송을 백그라운드 잡으로 처리 (참고: [[2026-01-05-email-latency-experiments]]).

시간이 지나면, 이렇게 해서 당신만의 작은 엔지니어링 위키가 만들어진다.

3. 간단한 시각화

대단한 다이어그램이 필요하지는 않다. 작은 시각적 요소만으로도 큰 도움이 된다:

• ASCII로 그린 간단한 아키텍처 스케치
• 시퀀스 다이어그램 비슷한 bullet 리스트
• 여러 접근 방식을 비교하는 표

예를 들어 아이디어 버킷 안에 다음과 같은 비교 표를 만들 수 있다:

이런 시각적 정리는 나중의 ‘나’가 컨텍스트를 다시 불러오는 시간을 크게 줄여 준다.

단순하지만 꾸준한 습관 만들기

완벽한 시스템이 중요한 게 아니다. 중요한 건 반복 가능한 시스템이다.

예를 들어 이런 최소 루틴을 생각해볼 수 있다:

• 작업 시작 시 (2–3분):

  • 오늘 날짜와 할 일을 적는다.
  • 어떻게 접근할지 떠오르는 아이디어 몇 가지를 적는다.

• 작업 중 (수시):

  • 시도해 본 중요한 실험들을 그때그때 기록한다.
  • “이건 이제 거의 확정이다” 싶은 순간, 결정으로 승격해 적어 둔다.

• 작업 종료 시 (5분):

  • 오늘 쓴 내용을 한 번 훑어본다.
  • 아이디어/실험 중 명확히 결정이 된 것들은 결정으로 옮긴다.
  • 두세 개 정도 태그를 붙인다.

몇 주, 몇 달만 이렇게 해도 다음과 같은 결과가 쌓인다:

• "왜 이렇게 되어 있지?"라는 질문에 훨씬 빨리 답할 수 있다.
• 미래의 나에게도 좋은 온보딩 문서가 생긴다.
• 내 사고와 설계 방식이 어떻게 진화해 왔는지 기록으로 남는다.

그리고 무엇보다: 머릿속 잡음이 눈에 띄게 줄어든다.

결론: 혼란을 줄이는 세 개의 버킷

세 통짜리 코딩 저널은 의도적으로 단순하다:

• 아이디어(Ideas) – 할 수도 있는 것들
• 실험(Experiments) – 실제로 해 본 것들
• 결정(Decisions) – 선택한 것과 그 이유

생각을 이 세 버킷으로 나누어, 하나의 믿을 수 있는 장소에 쌓아 두면:

• 코딩 중 인지 부하를 줄이고
• 메모를 개발 프로세스의 능동적인 일부로 만들며
• reasoning과 문제 해결 과정을 시간에 따라 추적 가능하게 만든다.

거창한 지식 관리 시스템이 필요하지 않다. 필요한 건 습관 하나와, 라벨이 선명하게 붙은 세 개의 버킷뿐이다.

다음에 코딩을 시작할 때, 저널을 열고 이렇게 세 개의 헤딩을 적어보자:

## Ideas

## Experiments

## Decisions

그리고 떠오르는 생각들을 알맞은 버킷에 하나씩 던져 넣기만 하면 된다. 미래의 당신이 분명히 고마워할 것이다.