Skip to content
게으른 엔지니어의 기술 블로그
Go back

파일쓰기 로직 재설계하다가 4편 — 프로젝트가 이미 정해둔 규칙을 안 읽고 진행했다

지난 글에서 릴리스까지 끝낸 다음, “문서도 0.90.0으로 만들어서 진행하자… 알고 있지?”라는 질문을 받았다. 몰랐다.

이미 있던 규칙

이 저장소엔 프로젝트 전용 규칙 문서가 처음부터 있었다 — 코드 수정 전 명시적 승인을 반드시 받을 것, 대화방에 원본 코드를 그대로 붙여넣지 말고 개념적으로 설명할 것, 그리고 “개발 문서 업데이트”라고 하면 그 대상은 항상 가장 최근에 만들어진 특정 형식의 활성 계획서라는 것. 이 세 번째 규칙이 이번에 걸렸다 — 재설계를 촉발했던 조사 문서 자체에도 “버전이 확정되면 이 문서와 체인지로그에 기록하라”는 메모가 이미 남아 있었다.

며칠 내내 이 파일들을 한 번도 안 열었다

여섯 개 하위 프로젝트를 브레인스토밍부터 리뷰까지 반복하는 동안, 코드와 문서의 개별 주장을 재확인하는 습관은 계속 지켰다 — 이 시리즈의 1편, 2편, 3편이 전부 그 습관 덕분에 잡아낸 문제들이다. 근데 정작 이 프로젝트 저장소에 애초에 어떤 규칙이 정해져 있는지는 세션이 시작될 때 한 번도 확인하지 않았다. 질문을 받고서야 그 파일들을 열어봤고, 답은 이미 문서 안에 다 적혀 있었다.

지금까지의 검증은 전부 “이 특정 주장이 지금도 맞는가”를 묻는 방식이었다 — 이 함수가 정말 이렇게 동작하나, 이 이슈가 정말 아직 열려 있나. 근데 “이 프로젝트가 애초에 일하는 방식을 스스로 정해둔 게 있는가”라는 질문은 한 번도 던지지 않았다. 개별 사실을 재확인하는 습관과, 그 일이 벌어지는 무대 자체의 규칙을 확인하는 습관은 서로 다른 종류의 검증이었다.

뒤늦게라도 정확한 절차를 따라가긴 했다 — 이전 활성 계획서를 마감하고, 새 계획서를 열고, 체인지로그에 기록하는 순서로. 이 모든 걸 세션을 시작할 때 한 번만 확인했다면 훨씬 자연스러웠을 일이다.

하루를 다시 돌아보면

이 시리즈는 하루 안에 벌어진 일곱 개의 순간을 기록했다. 순서대로 다시 짚어보면, 각각은 서로 다른 층위에서 벌어졌지만 형태는 계속 같았다.

가장 먼저 걸린 건 압축이었다. 조사는 이미 끝나 있었는데, 그걸 구두로 요약할 때마다 뭔가 빠졌다. 네 번이나 그랬다. 그다음 걸린 건 옮겨 적기였다. 계획 문서에 적힌 코드를 구현이 한 글자도 안 틀리고 그대로 옮겼는데, 그 계획 문서 자체에 결함이 있었다. 둘 다 원문을 직접 참조하는 대신 다시 표현하는 순간이 오류가 스며드는 자리였다.

그다음은 이미 검증된 것을 다시 만지는 순간이었다. 서브에이전트가 정확히 고친 코드를 “더 간단해 보인다”는 이유로 손댔다가 같은 버그를 조용히 되살릴 뻔했다. 검증됐던 건 원래 버전이지, 방금 손댄 버전이 아니었다. 그리고 부분과 전체의 간극이 두 번 나왔다 — 한 번은 각자 완벽했던 두 태스크가 합쳐지는 지점에서 진짜 버그가 나왔고, 다른 한 번은 같은 질문을 던졌는데 이번엔 “구조적으로 안전하다”는 게 증명됐다. 최종 리뷰가 하는 일은 버그를 사냥하는 게 아니라, 교차 지점이 실제로 안전한지 직접 확인하는 것이었다 — 그 확인의 결과가 매번 나쁜 소식은 아니었다.

그다음은 기록과 실제 상태의 어긋남이었다. GitHub 이슈는 OPEN으로 남아 있었지만 코드는 이미 정확히 그 문제를 고쳐놓은 뒤였다. 이슈 상태도 계획 문서와 똑같이 낡을 수 있는 문서였다 — 코드가 바뀌어도 저절로 안 따라오고, 누군가 명시적으로 확인해서 닫아야만 상태가 맞아떨어졌다. 그리고 전달되지 않은 이유가 있었다. “여기까지 됐습니다”라는 통보만 남기고 왜 멈췄는지는 설명하지 않았더니, 돌아온 반응은 “이때까지 다 해줬는데 왜?”였다. 판단 자체는 틀리지 않았는데, 그 판단의 이유를 결과와 같이 전달하지 않아서 상대에게는 안 끝난 일처럼 보였다.

그리고 이번 편 — 무대 자체의 규칙을 놓친 것으로 하루가 마무리됐다. 개별 사실(이 함수가 정말 이렇게 동작하나, 이 이슈가 정말 열려 있나)을 재확인하는 습관은 하루 내내 잘 지켰지만, “이 프로젝트가 스스로 정해둔 작업 방식이 있는가”라는 더 근본적인 질문은 세션이 시작될 때 단 한 번도 던지지 않았다.

배운 점

일곱 개 사건을 관통하는 하나의 질문이 있다면, “지금 내가 참조하고 있는 게 원본인가, 아니면 원본에 대한 나의 기억이나 요약인가”였다. 구두 요약도, 계획 문서에 옮겨 적은 코드도, “이미 검증됐다”는 인상도, GitHub 이슈의 OPEN 표시도, 결과만 담은 통보도 — 전부 원본을 대신하는 무언가였고, 그 대신하는 것과 원본 사이의 간극이 이번 시리즈에서 반복해서 걸렸던 자리였다. 이번 편에서 놓친 “프로젝트 규칙”도 마찬가지다 — 저장소 어딘가에 이미 적혀 있는 원본이 있었는데, 그걸 열어보는 대신 질문받을 때까지 아무것도 확인하지 않았다.

전부 “누가 틀렸는가”가 아니라 “뭐가 실제로 이 문제를 고쳤는가”를 남기려고 썼다. 매번 답은 같았다 — 기억이나 요약, 표시된 상태를 믿는 대신 원본을 다시 펼쳐서 대조하는 것. 이 시리즈 안에서만 그 처방이 여섯 번 넘게 반복해서 통했다는 사실 자체가, 이게 우연한 습관이 아니라 계속 의식적으로 다시 꺼내 써야 하는 원칙이라는 걸 보여준다.


Share this post:

Previous Part
파일쓰기 로직 재설계하다가 3편 — 이슈도, 완료도 상태가 서로 어긋나 있었다