
개발 일지 쓰기: 회고와 성장의 도구
개발 일지는 단순한 메모가 아니다. 내가 무엇을 배웠는지, 어디서 막혔는지, 어떤 결정을 내렸는지 기록하면 성장 속도가 확연히 달라진다. 작성 방법부터 블로그 포스팅으로 전환하는 법까지 정리했다.

개발 일지는 단순한 메모가 아니다. 내가 무엇을 배웠는지, 어디서 막혔는지, 어떤 결정을 내렸는지 기록하면 성장 속도가 확연히 달라진다. 작성 방법부터 블로그 포스팅으로 전환하는 법까지 정리했다.
거창한 포트폴리오보다 작은 사이드 프로젝트가 더 강력한 이유. 6개월간 만든 앱이 망하고, 주말에 만든 도구가 크게 성공한 경험을 통해 배운 '완성'의 중요성을 이야기합니다.

"기술 부채"라는 말을 들은 비개발자 관리자는 왜 항상 고개를 갸우뚱할까? 기술 부채를 비즈니스 언어로 번역하고, 리팩토링을 투자로 포지셔닝하고, 이해관계자를 설득하는 실전 프레임워크를 정리했어.

처음 코드 리뷰를 받았을 때 느끼는 그 두려움, 누구나 겪는 거다. PR 올리는 법부터 건설적인 피드백 주는 법까지, 리뷰 문화를 제대로 만들어가는 실전 가이드.

서비스를 운영하면서 유저가 어디서 이탈하는지, 어떤 기능을 쓰는지 전혀 몰랐다. PostHog를 붙이고 데이터 기반으로 결정하기 시작한 경험.

3년 전 나는 매일 코드를 짰지만 뭘 배웠는지 기억이 안 났다. 같은 에러를 두 번, 세 번 구글링했고, 왜 이 아키텍처를 선택했는지 반년 뒤에 물어보면 대답을 못 했다.
그러다 개발 일지를 쓰기 시작했다. 처음엔 "이게 무슨 소용이야" 싶었는데, 석 달 뒤부터 뭔가 달라졌다. 예전에 막혔던 문제를 내 메모에서 찾아낼 수 있었고, 회고할 때 "내가 이 달에 이런 걸 했구나"가 보이기 시작했다.
지금은 일지 쓰기가 코드 작성만큼 중요한 습관이 됐다. 왜 도움이 되는지, 어떻게 쓰면 좋은지 공유해보려 한다.
우리 뇌는 "중요하지 않다"고 판단한 것을 빠르게 잊는다. 오늘 3시간 씨름한 nginx 설정 문제, 내일은 절반만 기억하고, 다음 주엔 흔적도 없다.
일지는 외부 기억 저장소다. 내가 기억을 신뢰하는 게 아니라, 기록이 기억을 대신하게 만든다.
"이해했다"는 착각을 가장 잘 깨는 방법이 "남에게 설명하기"다. 일지에 쓰는 것도 같은 효과다. 글로 옮기다 보면 "어... 이 부분은 사실 잘 모르는데?"가 나온다. 그 지점이 진짜 학습이 필요한 곳이다.
3개월치 일지를 돌아보면 "나는 비동기 처리에서 자주 막히는구나", "기술 부채가 쌓이는 패턴이 있구나"가 보인다. 그게 자기 성장의 지도다.
면접에서 "최근에 어떤 기술적 도전을 해결했나요?" 질문에 당황하지 않게 된다. 이직 시즌에 포트폴리오 정리할 때 일지가 원자재가 된다. 블로그 포스팅 아이디어도 일지에서 나온다.
오늘 새로 알게 된 것. 크고 작은 거 다 포함이다.
## TIL - 2026-03-21
- `Array.at(-1)`로 마지막 요소에 접근 가능. `arr[arr.length - 1]` 대신.
- PostgreSQL에서 `EXPLAIN ANALYZE`가 `EXPLAIN`과 다르게 실제 실행을 해서 정확한 cost를 보여줌
- React `useEffect` cleanup 함수는 다음 effect 실행 전에도 호출됨 (언마운트 때만이 아님)
작은 것처럼 보이지만 쌓이면 엄청난 레퍼런스가 된다.
막혔다가 해결한 것. 가장 가치 있는 기록이다.
## 블로커 - CORS 에러 (30분)
**증상**
로컬에서 API 호출 시 CORS 에러. 서버에서는 `Access-Control-Allow-Origin: *` 설정했는데도 발생.
**시도한 것**
1. `cors()` 미들웨어 위치 변경 → 실패
2. 브라우저 캐시 클리어 → 실패
3. OPTIONS preflight 요청 로그 확인 → 여기서 발견!
**원인**
`cors()` 미들웨어가 인증 미들웨어 뒤에 등록되어 있었음.
OPTIONS 요청이 인증 미들웨어에서 401 반환 → CORS 헤더 추가 안 됨 → 브라우저가 CORS 에러로 표시.
**해결**
```javascript
// 잘못된 순서
app.use(authMiddleware);
app.use(cors(corsOptions));
// 올바른 순서
app.use(cors(corsOptions)); // CORS 먼저
app.use(authMiddleware);
교훈: 미들웨어 순서가 중요. OPTIONS 요청은 인증 검사 전에 처리되어야 함.
이걸 안 적어두면 6개월 뒤 똑같은 문제에서 또 30분을 쓴다.
### 아키텍처 결정 기록
왜 이 기술을 선택했나, 어떤 선택지가 있었나.
```markdown
## ADR (Architecture Decision Record) - 상태 관리 라이브러리 선택
**날짜**: 2026-03-21
**상태**: 결정됨
**결정**: Zustand 선택
**맥락**
사용자 인터랙션이 많은 대시보드 개발. 전역 상태 관리 필요.
**고려한 옵션**
| 옵션 | 장점 | 단점 |
|------|------|------|
| Redux Toolkit | 생태계 크고 표준적 | 보일러플레이트 많음 |
| Zustand | 가볍고 설정 간단 | 대형 앱에서 패턴 부재 |
| Jotai | 원자적 업데이트 | 팀 학습 곡선 |
| Context API | 추가 라이브러리 없음 | 리렌더링 문제 |
**결정 이유**
팀 규모(3명)와 앱 복잡도를 고려했을 때 Zustand가 가장 적합.
추후 복잡해지면 Redux로 마이그레이션 고려.
**결과 확인 일정**: 2026-06-21
ADR(Architecture Decision Record)은 미래의 나와 팀원에게 보내는 편지다.
생산성 패턴을 파악하는 데 의외로 중요하다.
## 에너지 기록 - 2026-03-21
- 오전: 집중력 높음. 복잡한 알고리즘 문제 집중해서 풀었음.
- 오후 2~4시: 에너지 급격히 떨어짐. 코드 리뷰나 문서 작업이 오히려 나을 것 같음.
- 저녁: 가볍고 창의적인 작업이 잘 됨 (UI 컴포넌트 작업).
→ 복잡한 설계 작업은 오전으로 몰아야겠다.
# 개발 일지 - YYYY-MM-DD
## 오늘 한 것
- [ ]
- [ ]
## TIL (Today I Learned)
-
## 블로커 / 해결
> 블로커: [문제 설명]
> 해결: [해결 방법]
> 교훈: [배운 것]
## 내일 할 것
- [ ]
## 에너지 / 메모
> 에너지 레벨: [1-10]
> 기타:
# 주간 리뷰 - YYYY W[n]
## 이번 주 완료한 것
-
## 이번 주 배운 것 (TIL 요약)
-
## 막혔던 것과 해결법
-
## 잘한 것
-
## 아쉬운 것 / 개선할 것
-
## 다음 주 목표
-
## 레벨업 지표
- 새로 배운 개념: [n]개
- 해결한 블로커: [n]개
- 블로그 초안 가능한 주제: [리스트]
# 월간 리뷰 - YYYY-MM
## 이번 달 완료한 주요 작업
-
## 기술적 성장
- 새로 익힌 기술/개념:
- 깊이 파고든 주제:
- 여전히 약한 영역:
## 커리어
- 의미 있는 기여:
- 팀/조직에 기여한 것:
## 숫자로 보는 이달
- 커밋 수:
- 해결한 이슈 수:
- 작성한 일지 수:
## 다음 달 포커스
1.
2.
3.
my-dev-journal/
├── daily/
│ ├── 2026-03-21.md
│ └── 2026-03-22.md
├── weekly/
│ └── 2026-W12.md
├── monthly/
│ └── 2026-03.md
├── til/
│ ├── javascript.md
│ └── postgresql.md
└── adr/
└── 001-state-management.md
Obsidian의 강점은 로컬 마크다운 파일 + 링크 그래프다. [[CORS 에러 해결]]처럼 링크를 걸면 관련 노트들이 자동으로 연결된다. Daily Notes 플러그인으로 매일 자동 생성도 된다.
추천 플러그인:
- Daily Notes: 매일 자동 생성
- Templater: 커스텀 템플릿 적용
- Dataview: 일지 내용 집계/쿼리
- Calendar: 주간/월간 뷰
팀 단위 공유가 필요하면 Notion이 더 편하다. 데이터베이스 기능으로 태그, 날짜별 필터링이 쉽다.
Notion 구조 예시:
📁 Dev Journal
📋 Daily Log (Database)
- Date
- Energy (1-10)
- TIL count
- Blocker count
- Tags
📝 ADR (Database)
📚 TIL Reference (Database)
가장 단순하고 영구적인 방법이다. Markdown 파일을 Git 저장소에 쌓는다.
# 구조
~/dev-journal/
2026/
03/
21.md
22.md
weekly/
W12.md
# 매일 커밋
cd ~/dev-journal
git add .
git commit -m "journal: 2026-03-21"
git push
GitHub Private Repo에 올려두면 검색도 되고 어디서든 접근 가능하다. 도구에 종속되지 않는 것이 장점.
| 상황 | 추천 도구 |
|---|---|
| 혼자, 로컬 중심 | Obsidian |
| 팀 공유 필요 | Notion |
| 단순함 최우선 | 플레인 텍스트 + Git |
| 모바일에서도 쓰고 싶음 | Notion |
| 그래프/링크 탐색 좋아함 | Obsidian |
도구는 취향이다. 가장 중요한 건 지속적으로 쓸 수 있는 도구다.
일지의 숨겨진 가치는 블로그 콘텐츠의 원자재라는 것이다. 방법은 간단하다.
## 블로그 후보 목록 (weekly 리뷰에서 추출)
- [ ] CORS 에러 미들웨어 순서 문제 (2026-03-21)
- [ ] Redis 캐시 eviction 정책 비교 (2026-03-19)
- [ ] Kubernetes readinessProbe vs livenessProbe 차이 (2026-03-15)
좋은 블로그 글 기준: "내가 이걸 알았더라면 [X시간]을 절약했을 텐데"
# 일지 (raw)
CORS 에러. cors() 미들웨어 위치 문제였음. 인증 미들웨어 뒤에 있었음. 30분 날림.
# 블로그 초안
## Express에서 CORS 에러가 해결 안 되는 진짜 이유
설정은 다 맞는데 CORS 에러가 계속 난다면, 미들웨어 순서를 의심해봐야 한다.
### 문제 상황
...
### 원인
...
### 해결
...
### 교훈
...
일지는 "나를 위한 메모"고, 블로그는 "독자를 위한 설명"이다. 전환할 때 독자 관점으로 다시 쓰면 된다.
매주 금요일 30분. 이번 주 일지를 훑으면서:
# 주간 리뷰 체크리스트
- [ ] 이번 주 일지 전부 훑어보기
- [ ] TIL 요약 작성
- [ ] 반복 블로커 패턴 메모
- [ ] 잘한 것 한 가지 (구체적으로)
- [ ] 개선할 것 한 가지 (실행 가능한 것)
- [ ] 다음 주 TOP 3 목표
- [ ] 블로그 글감 후보 업데이트
# 월간 성장 대시보드 - 2026-03
기술적 성장
- TIL 기록: 42개
- 해결한 블로커: 18개
- 새로 배운 라이브러리: 3개 (Argo Rollouts, OpenTelemetry, Tempo)
생산성
- 커밋 수: 187개
- PR 머지: 23개
- 코드 리뷰 완료: 31개
커뮤니티/공유
- 블로그 포스팅: 2편
- 팀 내 지식 공유 세션: 1회
개인 평가: 8/10
→ OTel 도입 완료. 다음 달은 테스트 커버리지 올리는 것에 집중.
이렇게 숫자로 보면 "이번 달 뭐 했지?"에 명확한 답이 생긴다.
일지는 일기장이다. 오타, 불완전한 문장 다 괜찮다. 10분 안에 쓰는 게 2시간 들여 완벽하게 못 쓰는 것보다 100배 낫다.
너무 많이 쓰려는 욕심처음엔 TIL 한 줄부터 시작해라. 루틴을 만드는 게 내용보다 먼저다.
쓰다가 중단하는 것일지는 매일 쓰지 않아도 된다. 막혔다가 해결했을 때, 뭔가를 배웠을 때, 중요한 결정을 내렸을 때 쓰면 된다. "매일" 강박보다 "있을 때" 습관이 더 지속 가능하다.
도구 설정에 너무 집착Notion 세팅하다가 일지 못 쓰는 케이스가 많다. 텍스트 파일 하나로 오늘 당장 시작하자.
오늘 할 일은 딱 하나다:
# 2026-03-23
## TIL
-
## 오늘 막혔던 것
-
## 내일 할 것
-
이 세 줄짜리 파일을 만들고 오늘 있었던 일 한 가지씩 채우면 된다. 그게 전부다. 완벽한 시스템을 나중에 만드는 것보다, 불완전한 일지를 오늘 시작하는 것이 훨씬 중요하다.
6개월 뒤 과거의 기록들을 보면서, "내가 이 문제로 고민했구나, 이렇게 해결했구나"를 느낄 수 있다면 그게 성공이다.