코드 짜는 시간보다 고민하는 시간이 더 긴 이유

개발자 현직자 솔직 경험담

코드 짜는 시간보다
고민하는 시간이 더 긴 이유

하루 8시간 중 실제 타이핑은 90분, 나머지는 전부 생각이었다는 걸 기록해보고 알았다.

비개발자 친구가 "하루 종일 뭐해?"라고 물어봐서 별생각 없이 "코드 짜지"라고 답했는데, 문득 이게 정확한 답이 아니라는 걸 깨달았다. 실제로 손을 움직여 타이핑하는 시간과 화면을 보며 생각만 하는 시간을 구분해서 일주일간 기록해봤다. 결과는 예상보다 훨씬 극단적이었다.

코드 짜는 시간보다 고민하는 시간이 더 긴 이유

90분하루 평균 실제 타이핑 시간

5.5시간하루 평균 고민 시간

1주일기록한 기간

1. 처음엔 "일을 안 하고 있나"라는 죄책감이 들었다

기록을 시작한 계기는 단순한 호기심이었다. 근데 막상 시간을 재보니, 하루 8시간 중 실제 코드를 작성하는 시간은 고작 1시간 반이었고, 나머지는 화면을 보며 멍하니 있거나, 종이에 뭔가를 끄적이거나, 그냥 걸어 다니며 생각하는 시간이었다.

친구 그럼 하루 8시간 중에 실제로 코드 짜는 시간은 얼마나 돼?

나 어... 재보니까 1시간 반 정도더라고. 처음엔 나 이렇게 놀고 있었나 싶어서 좀 당황했어.

처음엔 이 사실이 불안했다. "내가 일을 제대로 안 하고 있는 건가"라는 생각까지 들었다. 근데 그 5시간 반 동안 실제로 뭘 하고 있었는지 더 자세히 들여다보니, 절대 노는 시간이 아니었다.

⚠ 처음 든 오해 타이핑하지 않는 시간을 "일하지 않는 시간"으로 착각했다. 하지만 실제로는 그 시간이 코드의 방향을 결정하는, 가장 중요한 부분이었다.

2. 그 5시간 반 동안 실제로 한 일들

일주일 동안 기록한 내용을 다시 분류해보니, 고민 시간도 종류가 다양했다.

고민·설계 (5.5시간)

실제 타이핑 (1.5시간)

하루 8시간 기준 나머지 12%는 회의·커뮤니케이션

• 문제 이해 (약 1.5시간) — 요구사항이 애매한 부분을 다시 읽고, 관련 코드를 찾아 읽는 시간
• 설계 고민 (약 2시간) — 어떤 구조로 짤지, 기존 코드와 어떻게 연결할지 종이에 그려보는 시간
• 디버깅 사고 (약 1.5시간) — 콘솔 로그를 보며 "왜 이렇게 동작하지"를 추리하는 시간
• 대안 비교 (약 0.5시간) — 두세 가지 구현 방식 중 어떤 게 나을지 장단점을 따지는 시간

이렇게 나눠보니, 타이핑은 이미 결정된 것을 코드로 옮기는 마지막 단계일 뿐이었다. 진짜 어려운 일은 그 전 단계에서 다 끝나 있었다.

// 실제로 30분 고민하고 5분 만에 짠 코드 // 고민한 것: 이 필터링을 컴포넌트 안에서 할지, // 커스텀 훅으로 뺄지, 아니면 상위에서 이미 필터링된 데이터를 내려줄지 function useFilteredProducts(products, filters) { return useMemo( () => products.filter(p => matchesFilters(p, filters)), [products, filters] ); } // 코드 자체는 5줄, 근데 이 구조를 정하기까지가 30분

3. 팀에서 이 사실을 오해하고 있다는 걸 알게 된 순간

이 기록을 팀 회고에서 공유했더니, 흥미로운 반응이 나왔다.

PM 어? 저는 개발자분들이 화면 보고 계실 때 다 코드 짜고 계신 줄 알았어요. 생각하는 시간이 그렇게 길 줄은 몰랐네요.

나 저도 직접 재보기 전까진 몰랐어요. 근데 이걸 알고 나니까 일정 산정할 때도 "타이핑 시간"이 아니라 "고민까지 포함한 시간"으로 얘기해야겠다는 생각이 들더라고요.

이 대화 이후로, 일정 산정 방식 자체가 조금 달라졌다. "이 기능 코딩하는 데 얼마 걸려요?"라는 질문에 예전엔 순수 작업량만 생각했다면, 이제는 설계와 디버깅까지 포함한 현실적인 시간을 이야기하게 됐다.

기록 전 일정 산정

"이틀이면 돼요"

타이핑 시간 기준, 실제로는 항상 지연됨

기록 후 일정 산정

"고민 포함 나흘 정도요"

설계·디버깅 시간까지 포함, 실제 소요와 근접

4. 고민 시간을 줄이는 게 아니라, 잘 쓰는 게 답이었다

처음엔 "고민 시간을 줄여서 타이핑 시간을 늘려야 하나"라고 생각했는데, 몇 주 실험해보니 그건 방향이 잘못됐다는 걸 알게 됐다. 오히려 고민 시간을 억지로 줄이면 코드 품질이 눈에 띄게 떨어졌다.

실험 1주 차

일부러 고민 없이 빠르게 타이핑부터 시작. 결과적으로 중간에 구조를 두 번 갈아엎어야 했음.

실험 2주 차

고민 시간에 종이 스케치를 습관화. 타이핑 시간은 그대로였지만, 재작업이 크게 줄어듦.

실험 3주 차

고민 시간과 타이핑 시간을 분리해서 캘린더에 각각 블록으로 표시. 팀원들도 "저 지금 설계 중이에요" 같은 표현을 쓰기 시작.

고민 없이 바로 코딩 — 재작업 빈도8 / 10

 

고민 시간 확보 후 — 재작업 빈도3 / 10

 

고민 시간 확보 후 — 코드 만족도8.5 / 10

 

💡 지금 지키고 있는 습관 코드를 짜기 전에 최소 10분은 종이나 메모장에 구조를 먼저 적어보는 시간을 의도적으로 갖는다. 이 짧은 시간이, 나중에 몇 시간의 재작업을 막아준다는 걸 반복적으로 확인했다.

일주일 기록 후 결론

개발자의 일은 타이핑이 아니라 사고 과정 자체였다. 코드는 그 사고의 결과물을 옮겨 적는 마지막 단계일 뿐이고, 진짜 실력 차이는 그 사고 과정을 얼마나 정교하게 하는가에서 갈렸다.

"타이핑 속도는 실력의 지표가 아니었다. 오래 고민할수록 오히려 좋은 코드가 나왔다."

개인적으로 일주일간 기록한 데이터를 바탕으로 작성했으며, 업무 특성이나 프로젝트 난이도에 따라 고민-타이핑 비율은 사람마다 크게 다를 수 있다. 절대적인 기준이 아니라 하나의 참고 사례로 봐주시면 좋겠다.

결론

코드를 짜는 시간보다 고민하는 시간이 더 길다는 걸 직접 기록해보고 나서야 확인했다. 이 사실을 받아들이고 나니, 스스로에게도 팀에게도 더 정직하게 일정을 이야기할 수 있게 됐다. 타이핑 속도를 높이려 애쓰기보다, 고민하는 시간을 의도적으로 확보하고 잘 쓰는 것이 결과적으로 더 좋은 코드와 더 적은 재작업으로 이어진다는 걸 배웠다. 혹시 스스로 "왜 이렇게 코드를 안 짜고 있지"라는 불안감을 느끼고 있다면, 그 시간이 사실은 가장 중요한 작업 중이라는 걸 꼭 말해주고 싶다.

여러분의 고민-타이핑 비율은 어떠신가요?

직접 시간을 재보고 느낀 점이나, 고민 시간을 잘 활용하는 노하우가 있다면 댓글로 공유해주세요. 비슷한 궁금증을 가진 다른 개발자분들께 큰 도움이 될 것 같습니다.