메인 칼럼 개발일지 작업물 연락처
← ocul-pm 프로젝트
개발일지 / DEVLOG

1만 3천 줄 지우고 나서야 보인 것들

RefactoringDebtRetrospective

기능을 두 달 붙였더니 어디가 살아 있고 어디가 죽었는지 감이 안 왔다. 그래서 코딩 멈추고 보고서를 3편 썼다. 정리할 거, 구조 부채, 앞으로 할 기능. 쓰면서 안 사실이 좀 충격적이었는데, 만들어놓고 아무도 안 부르는 백엔드 커맨드가 22개 있었다. 그중엔 꽤 공들여 만든 것도 있어서 좀 그랬다.

일단 다 밀었다. 레거시랑 죽은 코드 합쳐서 약 13,600줄. 고아 커맨드 22개, 옛날 goal/subtask 커맨드 8개, 쓰이지 않는 db 메서드 5개, 안 쓰는 의존성들. SQLite에서 .oculpm으로 옮길 때 만들었던 일회성 마이그레이션 shim도 이제 할 일 다 했으니 은퇴. 설정 쪽 죽은 코드도 같이.

보고서 쓰면서 제일 뜨끔했던 건 redaction이었다. 시크릿 마스킹하는 코드를 만들어놓고 정작 일지랑 diff 쓰고 읽는 경로에 안 붙여놨더라. 만들어놓은 걸로 만족하고 넘어간 거다. 이건 그냥 버그가 아니라 좀 위험한 거라 바로 배선했다.

정직성 감사(F2)도 비슷한 케이스였다. oculpm_compare_layers라는 커맨드가 완성돼 있는데 호출처가 0이었다. 얘가 뭘 하냐면, 실제로 바뀐 파일 목록이랑 에이전트가 일지에 적은 파일 목록을 비교해서 “바뀌었는데 기록엔 없는” 걸 찾아준다. 즉 에이전트가 뭘 빼먹었는지 잡아내는 거다. Today 화면에 카드로 올렸는데, 문제 있을 때만 뜨게 했다. 깨끗한 날엔 아예 안 보임. 안 그러면 금방 무시하게 되니까.

콜드스타트 문제도 손봤다(F5). 프로젝트를 새로 추적 시작하면 그 전 기록이 통째로 없어서 화면이 텅 비는데, 이게 은근 김이 샌다. git 히스토리를 백필해서 절벽을 없앴다. frontmatter 자동 보정도 넣었다. tz 오프셋 빠진 거 채우고 한글 slug 정규화하고. 일지 검색이 14일까지밖에 못 보던 것도 백엔드 쿼리로 바꿔서 전체 기간으로 풀었다(F3).

플래너는 아직도 파일이랑 DB 두 군데를 보는 소비처가 남아 있었다. 세 곳을 다 파일 기반으로 일원화(S1). 이건 지난번에 다 한 줄 알았는데 아니었다.

새로 만든 건 두 개. 하나는 회고/인사이트 화면(F4)이다. 기간 정해서 결정적 신호(커밋 수, 작업 유형 분포 같은 거) 뽑고 그 위에 LLM이 한국어로 회고를 써준다. 다른 하나는 자동 화해(F1). 워처가 새 일지를 인덱싱하면 그걸 근거로 활성 계획 상태를 LLM이 알아서 갱신한다. 이제까지 항상 비어 있던 plan-log의 journal_ref가 드디어 채워지기 시작했다.

일지 신뢰도 문제도 손봤다. frontmatter가 깨진 일지는 그동안 조용히 잘못된 값으로 읽히고 있었는데, 이제 파싱 경고를 ⚠ 배지로 카드에 띄운다. “이 기록은 못 믿는다”를 화면에서 바로 보여주는 게 낫다고 봤다. 한글 slug는 정규화 규칙을 다시 잡고 기존 캐시 행까지 재보정했고, tz 오프셋 빠진 건 원본 파일을 한 번만 고쳐 쓰는 걸로 정리했다. 남의 파일을 앱이 고치는 거라 이건 좀 고민했는데, 어차피 규격 위반이라 놔두면 계속 문제 생긴다.

자동 화해는 겁이 좀 나서 방어를 많이 걸었다. 기본 off인 옵인이고, try_lock_owned로 동시에 한 건만, 겹치면 그냥 드롭. 활성 계획이 정확히 하나일 때만 돈다. 제일 신경 쓴 건 쓰기 직전 CAS인데, 내가 손으로 고치고 있는 계획을 백그라운드 LLM이 덮어쓰면 진짜 열받을 것 같아서. 사람 편집이 무조건 이긴다. 적대적 리뷰에서 버스트 과금, 쓰기 레이스, 가드 취약 3건 지적받고 다 반영했다.

일단 돌려보니 활성 계획이 여러 개일 때 아무것도 안 하고 넘어가는 게 걸려서, 다중 활성 계획도 화해하게 확장했다. 화해랑 사용자 쓰기가 같은 파일을 동시에 건드릴 수 있으니 공유 락으로 직렬화하고, 끝나면 토스트로 알려주게. 이런 건 한 번에 안 되고 꼭 며칠에 걸쳐 붙는다.

일지 .md 내보내기도 붙였다. 남한테 보여줄 일이 생기더라.

며칠 뒤엔 “문제 해결” 화면을 하나 더 만들었다. 결정을 내리기 전에 뭘 고민했는지 남기는 토의 문서인데, 일지가 “뭘 했다”라면 이건 “왜 그렇게 하기로 했다”를 적는 곳이다. 3개월 전 나한테 물어볼 수가 없으니 어쩔 수 없다.

김현빈 Developer & Writer

기술, 포스팅 관련 질문, 프로젝트 협업 등 연락주시면 언제든지 회신 드립니다.