2025년 제 GitHub contribution 그래프는 서로 다른 두 개발자의 기록처럼 보입니다. 상반기는 거의 비어 있습니다. 하반기에는 4,000개가 넘는 커밋이 있습니다.
갑자기 자유 시간이 늘어난 것은 아닙니다. 여전히 풀타임 일을 하면서 사이드 프로젝트를 병행했습니다. 달라진 것은 아이디어와 실제로 작동하는 버전 사이의 friction이었습니다. AI 코딩 도구를 훨씬 더 진지하게 쓰기 시작했습니다.
다만 이 숫자는 정확하게 해석해야 합니다. 커밋 수 자체는 생산성 지표가 아닙니다. 4,000개의 커밋이 4,000개의 의미 있는 개선을 뜻하지도 않고, 코드 품질이 좋았다는 증거도 아닙니다. 그래도 그래프는 제 작업 패턴이 실제로 달라졌다는 점을 분명히 보여줍니다. 이전보다 훨씬 꾸준하게 만들고, 반복하고, 작동하는 버전까지 밀어붙였습니다.
진짜 병목은 실험을 시작하는 데 필요한 에너지였습니다
Side project를 하다 보면 같은 문제가 반복됐습니다. 첫 번째 useful version까지 routing, validation, script, test, configuration, cleanup 같은 routine work가 많이 필요합니다. 아이디어가 가치 있는지 확인하기도 전에 그 과정에서 momentum을 잃을 수 있습니다.
예전에는 첫 working version까지 여러 저녁이 필요해 보이면 실험을 미루곤 했습니다. AI coding tool이 그 일을 없애지는 않았지만 first pass의 비용을 낮추고 testable version까지 더 빨리 갈 수 있게 했습니다.
따라서 가장 큰 이득은 typing speed가 아니었습니다. 더 중요한 변화는 activation energy가 낮아진 것입니다. 실제 evidence를 얻을 수 있는 단계까지 도달하는 아이디어가 늘었습니다.
Node.js workflow에서 실제로 달라진 점
Development process를 chat window로 대체한 것은 아닙니다. Node.js side project에서 DeepSeek를 범위가 명확한 작업의 second pair of hands로 사용했습니다. 첫 implementation 초안, 낯선 code 읽기, test 제안, stack trace 분석, 큰 refactor 쪼개기, deployment assumption 검토 같은 작업입니다.
- Scaffolding: handler, validation, script, test의 지루한 first version 만들기.
- Code reading: edit 전에 request나 value의 흐름 추적하기.
- Refactoring: 큰 변경을 review 가능한 작은 diff로 나누기.
- Debugging: log에서 여러 가설 만들기.
- Verification: happy path 이후 edge case와 regression 찾기.
input, output, constraint, existing convention이 명확할수록 결과를 검증하기 쉬웠습니다. 반대로 vague task는 그럴듯하지만 잘못된 abstraction을 만들기 쉬웠습니다.
그래서 AI output을 final answer가 아니라 candidate patch로 취급했습니다. Type checking, test, build, 실제 flow가 evidence였고 자신감 있는 설명은 evidence가 아니었습니다.
DeepSeek가 가장 도움이 된 곳 — 그리고 그렇지 않은 곳
DeepSeek는 concrete programming task에 반복해서 쓰기 쉬웠다는 점에서 유용했습니다. first pass를 받고, 일부를 버리고, 실제 error를 다시 주고, scope를 줄여 빠르게 iterate할 수 있었습니다.
이것을 benchmark라고 부르지는 않습니다. 모든 competing model을 대상으로 controlled study를 한 것도 아니고 model lineup도 빠르게 바뀝니다. 제가 말할 수 있는 것은 DeepSeek가 제 workflow에 충분히 잘 맞아서 AI assistance 사용 빈도가 크게 늘었다는 정도입니다.
function, test, 실제 error가 있는 문제에서는 강했고, 숨겨진 product context나 미묘한 architecture trade-off가 필요한 문제에서는 약했습니다. 그런 경우 fluent output이 잘못된 assumption을 완성된 답처럼 보이게 할 수 있습니다.
AI가 바꾼 것은 실험의 비용이었습니다
가장 큰 변화는 “AI가 코드를 쓰니 development가 자동화됐다”가 아니었습니다. 많은 작은 요소를 시도하는 비용이 충분히 낮아졌다는 점이었습니다. 예전에는 setup이 너무 커 보이던 side-project feature도 아이디어에 대한 관심이 남아 있을 때 prototype으로 만들어 볼 수 있게 됐습니다.
이 차이는 중요합니다. AI는 testable version까지 가는 비용을 줄였습니다. 하지만 architecture, product judgment, deployment, correctness를 없애지는 않았습니다. generated implementation은 틀릴 수 있고, 성공한 build도 runtime에서 깨질 수 있으며, deploy된 prototype도 여전히 나쁜 제품일 수 있습니다.
제게 가장 실질적인 이점은 momentum이었습니다. 시스템 전체가 실제로 작동하는 모습을 한 번 보면 계속 개선하려는 동기가 훨씬 커졌습니다.
더 강한 benchmark에 필요한 것
재현 가능한 benchmark를 만들려면 exact model version, fixed programming task, repository snapshot, prompt, raw output, elapsed time, accepted/rejected patch, review time, test result, rework를 기록해야 합니다.
Commit 외에도 idea에서 verified version까지 걸린 시간, defect, rollback, 다시 작성한 작업량을 측정해야 합니다. 이런 context가 없으면 4,000개 commit은 activity와 behavior change의 증거일 뿐 software quality의 증명은 아닙니다.
제게 실제로 달라진 것
2025년은 모든 사이드 프로젝트를 수작업으로 넘어야 하는 거대한 setup 산처럼 보지 않게 된 해였습니다. AI가 첫 번째 작동 버전의 비용을 충분히 낮춰 주었고, 덕분에 실제 product decision이 중요해지는 지점까지 더 자주 도달할 수 있었습니다.
제 GitHub 그래프 하반기가 그렇게 다르게 보이는 이유가 바로 이것입니다. AI가 하루의 시간을 늘려 준 것도 아니고, 생성된 모든 코드가 좋았던 것도 아닙니다. 아이디어가 현실이 되기 전에 죽게 만들던 friction을 줄여 줬습니다.
2026년에는 덜 화려한 다음 단계에 더 집중하고 있습니다. workflow를 다듬고, quality를 더 진지하게 측정하며, 더 빠른 development가 단순히 더 많은 commit이 아니라 더 나은 software로 이어지는지 확인하는 일입니다.