긴 세션이 코드 품질을 갉아먹어요: 컨텍스트 예산 규율
긴 코딩 세션에서 코드 품질이 조용히 나빠지는 이유와, 컨텍스트 예산으로 세션을 끊어 관리한 1인 개발 경험을 정리했어요.
긴 세션이 코드 품질을 갉아먹어요: 컨텍스트 예산 규율
한 화면을 붙잡고 두세 시간을 이어서 작업한 날, 결과물이 이상하게 지저분했던 적 없나요? 저는 혼자 운영하면서 이걸 꽤 자주 겪었어요. 처음 한 시간은 깔끔하다가, 세션이 길어질수록 비슷한 함수가 두세 개씩 생기고 앞에서 정한 규칙을 스스로 어기더라고요.
왜 뒤로 갈수록 나빠질까
원인은 실력이 아니라 기억 용량이었어요. 사람이든 AI 도구든 한 세션에서 담아둘 수 있는 맥락에는 한계가 있어요. 앞부분 결정이 흐려지면 이미 만든 유틸을 못 찾고 새로 짜게 돼요. 그 중복이 다음 작업의 나쁜 본보기가 되면서 조용히 쌓이는 거죠.
직접 만들어 보니, 이건 '조금만 더 하면 끝난다'는 마음일 때 제일 위험했어요. 끝이 보이니까 세션을 안 끊고 밀어붙이는데, 정작 그 구간에서 짠 코드를 다음 날 다시 뜯어고치는 일이 많았어요.
컨텍스트 예산이라는 규율
그래서 세션에도 예산을 정했어요. 돈처럼 맥락도 한정된 자원으로 보는 거예요. 제가 쓰는 기준은 이래요.
- 맥락이 30~40% 차면 새 세션 준비를 시작해요.
- 50%를 넘기면 그 뒤 산출물은 신뢰도가 떨어진다고 보고, 급하지 않으면 끊어요.
- 파일은 한 개 500줄을 넘기지 않게 잘라요. 길수록 읽는 데만 맥락을 다 써버리거든요.
- 30~40% 새 세션 준비
- 50% 하드 한계
- 파일 500줄 상한
돌려 보니 규칙 자체보다 '끊는 습관'이 핵심이었어요. 한 작업이 끝나면 다음 걸 이어서 하기 전에 세션을 한 번 정리하고, 지금까지 정한 것만 짧게 요약해 다음 세션으로 넘겼어요. 이렇게 하니 같은 실수를 반복하는 빈도가 눈에 띄게 줄었어요.
작은 도구를 만들 때도 똑같아요
플랜씨(plan-c) 같은 금융계산기를 손볼 때도 이 규율을 적용해 봤더니, 계산 로직 한 덩어리를 끝낼 때마다 세션을 끊는 게 오히려 빨랐어요. 맥락이 가벼울 때 짠 코드가 나중에 덜 고쳐지니까요.
테스트해 보면 알겠지만, 긴 세션의 손해는 그 순간엔 잘 안 보여요. 며칠 뒤 그 코드를 다시 열 때 드러나죠. 그래서 요즘은 '한 번에 오래'보다 '짧게 여러 번'을 택해요. 반복을 줄이는 가장 싼 방법이더라고요.
관련 글
댓글
아직 댓글이 없어요. 첫 댓글을 남겨주세요.