왜 항상 “코딩 시간이 어디로 갔는지” 애매할까

하루 종일(혹은 밤새) 코딩을 끝냈습니다. IDE에는 오늘 건드린 파일 몇 개가 남아 있고, 브라우저 히스토리는 문서, Stack Overflow, Jira 티켓으로 가득합니다. git log에는 커밋 몇 개가 찍혀 있죠.

그런데 누군가 이렇게 물어보면:

• 오늘 실제로 뭐 했어?
• 어떤 기능에 시간이 제일 많이 들었어?
• 왜 그 간단해 보이던 티켓이 이틀이나 더 길어졌어?

…아마 머릿속 기억이랑 여기저기 흩어진 도구들을 짜 맞추면서 “아, 디버깅 뭔가 하다가…” 정도의 흐릿한 답을 만들게 될 겁니다.

기존의 트래킹 도구들은 이 지점을 잘 못 도와줍니다:

• Timing / RescueTime: 어떤 앱과 사이트를 썼는지 알고
• WakaTime: 어떤 프로젝트/파일을 수정했는지 알고
• Git log: 어떤 코드를 커밋했는지 압니다

하지만 이 도구들은 이런 질문에는 답을 거의 못 해줍니다:

“기능, 티켓, 결과 관점에서 보면, 내 시간이 정확히 어디에 쓰였지?”

바로 그 빈틈을 채우기 위해 만든 것이 한눈에 보이는 기능 원장(Feature Ledger) 입니다.

One-Glance Feature Ledger란 무엇인가

“One-Glance Feature Ledger(한눈에 보이는 기능 원장)”는 작고 가벼운 트래킹 시스템입니다. 언제든 이걸 보면 지금:

• 어떤 기능이나 작업을 하고 있는지
• 왜 그걸 하고 있는지
• 방금 무엇을 했는지
• 다음에 무엇을 할 건지

를 바로 알 수 있습니다.

아이디어는 원장(ledger) 에서 가져왔습니다. 원래 원장은 단순히 기록을 차곡차곡 쌓아가는 장부죠. 이 개념을 다음 범위에 맞게 축소한 버전이라고 보면 됩니다:

• 전 세계가 아닌 나(혹은 우리 팀) 중심의 기록
• 금융 거래가 아닌 기능, 티켓, 버그, 실험 중심의 기록

핵심 설계 원칙은 이겁니다. 한 번 쓱 보기만 해도, 새벽 2시든 컨텍스트 전환 한가운데든, 이런 질문에 답할 수 있어야 합니다:

“지금 나는 실제로 뭘 하고 있고, 여기까지 어떻게 흘러온 거지?”

복잡한 대시보드도, 시간표도, 수동 시간 입력도 필요 없습니다.

그냥 현재 진행 중인 기능 작업의 작은 살아 있는 기록만 있으면 됩니다.

기존 도구들이 놓치는 지점

대부분의 개발자용 트래킹 도구는 행위(activity) 에 최적화되어 있고, 의도(intent) 에는 그렇지 않습니다.

이 도구들이 알려줄 수 있는 것:

• VS Code에서 3시간, Chrome에서 2시간, Slack에서 30분 썼다
• user_service.py, billing_controller.ts 를 수정했다
• 새벽 1시 13분에 fix edge case in payment retries 를 커밋했다

하지만 이 도구들이 깔끔하게 알려주지 못하는 것:

• 그 작업들이 어떤 기능 또는 티켓에 속하는지
• 그 시간 중 얼마나 조사 / 구현 / 마무리에 쓰였는지
• 시간이 추정치나 우선순위와 어떻게 맞아떨어졌는지

여기서 빠져 있는 레이어는 아주 단순한 매핑입니다:

로우 액티비티 → 기능 / 티켓 / 결과(Outcome)

One-Glance Feature Ledger는 바로 이 누락된 레이어 역할을 합니다.

시작은 새벽의 디버깅 나선에서

이 아이디어는 꽤 고통스러운 새벽 디버깅 세션에서 나왔습니다.

상황을 떠올려 봅시다:

• 이미 자정은 넘었고, “간단한” 버그 픽스가 끝 모를 토끼굴이 되었습니다.
• 로그, DB 쿼리, 예전 티켓, Slack 스레드, 이상한 기능 플래그 사이를 튕기며 돌아다녔습니다.
• 세 가지 접근을 시도했고, 두 개는 막다른 길. 하나는 그럭저럭 동작하는데, 왜 되는지 완전히 확신은 안 섭니다.

새벽 2시에 문득 멈춰서 스스로에게 묻게 됩니다:

“지난 4시간 동안 대체 뭘 한 거지?”

주변 도구들이 보여주는 건 조각난 히스토리뿐입니다:

• 터미널 히스토리에는 명령어들이 있고
• 에디터에는 열려 있는 파일들이 있고
• 브라우저에는 방문한 링크들이 남아 있는데

어느 것도 이걸 하나의 이야기로 엮어주진 못합니다. 이런 식으로 말해주는 한 곳이 없는 겁니다:

“지금 너는 티켓 ABC-1429: 결제가 간헐적으로 실패함 을 작업 중이다.

지난 4시간 동안 한 일:

• payments-api 에서 로그 패턴 조사
• 레이스 컨디션으로 인해 재시도 실패하는 문제 확인
• 서로 다른 재시도 전략 2개 실험
• 하나는 복잡도로 인해 보류
• 최소한의 가드(guard) 수정과 트레이싱 추가

다음 할 일: 가드를 다듬거나, 메트릭이 안 좋으면 아침까지 롤백 고려.”

그 밤에 이런 생각이 들었습니다. “이 이야기를 간단하게라도 적어 두는, 항상 손 닿는 작은 원장이 있으면 어떨까?”

기능 원장의 핵심 원칙

One-Glance Feature Ledger는 몇 가지 단순한 원칙 위에 서 있습니다.

1. 언제든 ‘한눈에’ 보이기
   1초만 훑어봐도 바로 알 수 있어야 합니다:

   • 지금 내가 뭘 하고 있는지
   • 그게 왜 중요한지
   • 직전에 무엇을 했는지
   • 다음에 무엇을 할 건지

2. 앱 중심이 아니라 기능 중심
   기록 단위는 개별 앱이나 파일이 아니라, 기능, 티켓, 작업 단위입니다.

3. 가볍고 작게
   시간 단위 쪼개기, 시트 작성, 마이크로 매니징은 없습니다. 짧고 의미 있는 기록만 남깁니다.

4. 수동 입력은 최소한으로
   짧고 마찰이 거의 없는 업데이트를 기본으로 하고, 가능한 곳에는 자동화를 씁니다(브랜치 이름, 커밋 메시지, Jira ID 등).

5. 기존 워크플로에 자연스럽게 녹아들 것
   하루 종일 켜둬야 하는 새로운 SaaS가 아니라, 이상적으로는 다음 중 하나에 살게 됩니다:

   • 에디터 안
   • 터미널 안
   • 아주 작은 로컬 웹 페이지나 노트

6. 브리지(연결) 레이어 역할
   Jira/Linear나 WakaTime/RescueTime을 대체하는 게 아니라, 이들을 이어주는 레이어입니다:

   • 로우 액티비티 → 서술(narrative) → 다시 상위 계획 도구로.

실제로 원장은 어떻게 생겼나

가장 단순한 형태의 기능 원장은 아래 같은 작은 구조의 리스트일 수 있습니다:

[ABC-1429] Payments intermittently failing
- 21:05 Start: Investigating spike in 5xx responses on /charge
- 21:30 Note: Logs suggest race between retry job + manual refund
- 22:10 Experiment: Added extra logging around retry scheduling
- 23:05 Finding: Confirmed duplicate job scheduling when flag X is on
- 23:40 Decision: Implement minimal guard, revisit full refactor later
- 00:10 Next: Monitor metrics for 30 mins; if stable, ship

[FEAT-721] New dashboard chart for admin metrics
- 14:00 Start: Wireframe integration into admin layout
- 14:45 Blocked: Waiting on metrics API format from data team
- 15:10 Next: Switch to ABC-1429 while blocked

여기서 볼 포인트 몇 가지:

• 각 블록은 하나의 기능 또는 티켓에만 범위가 묶여 있습니다.
• 각 엔트리는 짧습니다—대부분 한 줄 정도.
• 하루(또는 밤)를 바로 되감아 볼 수 있습니다:
  • 언제 어떤 작업 사이를 오갔는지
  • 어디서 막혔는지
  • 왜 예상보다 오래 걸렸는지

진짜 ‘한눈에’ 보기 위해: 어디에 두는가

“한눈에”라는 속성이 생각보다 중요합니다. 원장을 찾으려고 이리저리 뒤져야 하면, 결국 안 쓰게 됩니다.

좋은 위치 예시:

• IDE 안의 작은 패널이나 사이드바
• 현재 컨텍스트를 출력해 주는 터미널 커맨드 (ledger 나 feat 같은)
• 고정해 둔 노트(Obsidian, Notion, 로컬 Markdown 파일 등)
• 개발 환경이 열릴 때 자동으로 뜨는 미니멀한 웹 UI

테스트는 간단합니다. Slack에서 누가 불러서 흐름이 끊겼다가, 다시 돌아올 때:

1. 명령어 한 번 치거나 창 하나만 힐끗 보고
2. 바로 떠올릴 수 있어야 합니다: “아, 맞다. 지금 ABC-1429 작업 중이었고, 가드 수정 후 메트릭 모니터링 하려던 참이었지.”

“딱 필요한 만큼”만 자동화하기

무거운 수동 기록은 항상 실패합니다. 기능 원장은 **“딱 필요한 만큼의 자동화”**를 목표로 합니다. 별도의 프로젝트가 되지 않을 정도로만.

쓸 수 있는 자동화 훅 예시:

• 브랜치 이름 → 티켓 ID
  브랜치를 feat/ABC-1429-payments-retry-fix 같이 만드는 문화라면, 현재 체크아웃된 브랜치에서 티켓을 자동 인식하게 할 수 있습니다.

• 커밋 메시지 → 짧은 노트
  Add logging around retry job scheduling 같은 커밋을 올리면, 현재 기능에 대한 노트로 자동 첨부하게 만들 수 있습니다.

• 에디터/터미널 커맨드 → 퀵 엔트리
  예를 들면:

  • feat start "Investigate retry race condition"
  • feat note "Confirmed duplicate scheduling when flag X is on"
  • feat next "Monitor metrics and evaluate guard"

• Jira / Linear 연동
  원장에는 최소한만 저장합니다:

  • 티켓 ID
  • 제목
  • 상태

목표는 업데이트를 **“미래의 나를 위한 빵가루(브레드크럼)를 남기는 느낌”**으로 만드는 것입니다. 보고서 작성 느낌이 나면 실패입니다.

로우 액티비티와 계획 도구를 어떻게 이어주는가

당신이 쓰는 도구 스택을 세 개의 레이어로 생각해 볼 수 있습니다:

1. 로우 액티비티(하단 레이어)

   • IDE 사용, 수정한 파일, 실행한 커맨드, 방문한 웹사이트.

2. 기능 원장(중간 레이어)

   • “무엇을, 왜 했는지”가 보이는 사람 읽을 수 있는 내러티브.

3. 계획 도구(상단 레이어)

   • Jira, Linear, Asana 등—범위, 우선순위, 마감일이 있는 곳.

기능 원장은 이 셋을 이렇게 연결해 줍니다:

• 회고(retro)를 할 때:
  단순히 “결제 버그에 2일 걸렸어요.”가 아니라, 이렇게 보여줄 수 있습니다:

  • 조사에 든 시간
  • 막다른 길들
  • 예상 밖 복잡성이 어디서 나왔는지

• 추정(estimate)을 할 때:
  과거의 비슷한 기능을 보면서:

  • 실제 시간이 코딩 vs 디버깅 vs 다른 팀 기다리기에 얼마나 나뉘었는지 볼 수 있습니다.

• 퍼포먼스 리뷰를 할 때:
  “백엔드 작업 좀 했고 버그도 좀 고쳤습니다.” 수준에서 막히지 않고, 훨씬 구체적인 내러티브를 제시할 수 있습니다:

  • 어떤 기능을 주도했는지
  • 어떻게 다른 사람들을 언블락 했는지
  • 인시던트나 까다로운 리팩터링을 어떻게 처리했는지

오늘 당장 기능 원장을 시작하는 방법

전용 툴이 없어도 시작할 수 있습니다. 간단한 워크플로로 바로 실험해 볼 수 있습니다.

1. 작은 원장 파일 하나 만들기
   예: feature-ledger.md 같은 Markdown 또는 텍스트 파일 하나.

2. 티켓/기능별로 헤더 만들기

   ## [ABC-1429] Payments intermittently failing
   - 21:05 Start: Investigating spike in 5xx responses on /charge

3. 의미 있는 전환이나 발견이 있을 때마다 → 한 줄

   • “Note: Logs suggest retry/refund race”
   • “Experiment: Added additional logging”
   • “Decision: Minimal guard fix, full refactor later”

4. 컨텍스트를 전환할 때는 항상 ‘Next’ 한 줄 남기기

   • “Next: Implement guard once metrics confirm hypothesis”

5. 쉬기 전/돌아오기 전·후에 꼭 한 번씩 훑어보기

   • 점심이나 회의 전에 Next: 한 줄을 남기고,
   • 돌아와서는 마지막 2–3줄을 읽습니다.

시간이 지나면서, 작은 자동화를 얹거나 이 패턴을 IDE/터미널에 녹여 둔 오픈소스 구현체를 써볼 수도 있습니다.

보기보다 훨씬 중요한 이유

겉으로 보면 기능 원장은 그냥 작은 로그일 뿐입니다.

하지만 실제로는 이런 걸 제공합니다:

• 압박 속에서도 명료함: 새벽 디버깅 세션이 흐릿한 기억이 아니라, 다시 따라갈 수 있는 이야기로 남습니다.
• 더 나은 추정: 조사와 커뮤니케이션에 실제로 얼마나 시간이 드는지 드디어 눈에 보입니다.
• 더 강한 커뮤니케이션: PM이나 팀원에게 “왜 오래 걸렸는지”를 손사래가 아닌 구체적인 단계로 설명할 수 있습니다.
• 개인용 확장 메모리: 나중에 “내가 그때 왜 이렇게 했더라?”를 다시 묻지 않아도 됩니다.

무엇보다도, 이 방식은 개발자가 실제로 일하는 방식을 존중합니다:

• 깔끔하지 않고 비선형적인 진전
• 잦은 인터럽트와 컨텍스트 스위치
• 커밋 로그에는 잘 드러나지 않는 디버깅 여정들

마무리 생각

코딩 시간이 어디에 쓰였는지 이해하려고, 대기업 수준 분석 도구나 침 intrusive 한 시간 추적기가 꼭 필요한 건 아닙니다. 필요한 건, 내가 실제로 뭘 하고 있는지에 대한 작고 솔직하며 한눈에 보이는 내러티브입니다.

One-Glance Feature Ledger가 제공하는 게 바로 그것입니다. 최소한의, 개방적이고, 개발자 친화적인 방식으로:

• 내 일을 실제 기능과 결과에 매핑하고
• 로우 액티비티와 계획 도구 사이의 빈틈을 메우고
• 나와 팀 모두가 코드 뒤에 숨은 “진짜 이야기”를 볼 수 있게 합니다.

아주 작게 시작하면 됩니다. 파일 하나, 기능 하나, 짧은 줄 몇 개.

다음에 새벽 2시에 고개를 들고 “오늘 밤 어디로 사라진 거지?”라고 스스로에게 물어보게 될 때, 그 답은 이미 당신이, 당신을 위해, 당신의 말로 써 둔 곳에 있을 겁니다.