내 코드베이스가 더 이상 내 것처럼 느껴지지 않았다. 자세히 들여다보니 발견한 것들.

몇 달 전 AI로 구축했던 컴포넌트를 열어보았습니다.

로직은 맞았습니다. 기능도 여전히 작동했습니다. 하지만 무언가 낯선 느낌이 들었습니다. 명명 규칙(Naming)은 제가 지었을 방식이 아니었습니다. 구조(Structure) 또한 제가 구성했을 방식이 아니었습니다. 작동은 잘 되었고 기술적으로는 제 것이 맞았지만, 제가 직접 만든 것 같다는 느낌이 들지 않았습니다.

확실히 하기 위해 git 히스토리를 확인했습니다. 제가 작성한 것이 맞았습니다. AI가 대부분을 생성했고, 당시 저는 그것을 검토하고 수락했습니다. 하지만 지금 다시 보니, 마치 누군가의 코드가 제 프로젝트의 파일 확장자를 달고 있는 것처럼 읽혔습니다.

실제로 일어나고 있었던 일

저는 AI와 지속적으로 작업하다 보면 자연스럽게 제가 일하는 방식이 반영된 결과물이 나올 것이라고 가정해 왔습니다.

하지만 상황은 그렇게 흘러가지 않습니다. 각 세션(Session)은 그 자체로 독립적인 의사결정 과정입니다. AI는 "이 개발자가 코드를 짜는 방식"에 대한 감각을 계속해서 가져가지 않습니다. AI는 현재 컨텍스트(Context)에서 보이는 것들을 전달받고, 컨텍스트가 부족해지면 자신의 기본값(Defaults)을 바탕으로 생성할 뿐입니다.

따라서 제가 3개월 전에 만든 컴포넌트는 당시 제가 설명했던 내용과 그 특정 세션에서 AI에게 타당해 보였던 것들을 반영했습니다. 지난주에 만든 컴포넌트는 다른 세션, 다른 프롬프트(Prompt), 그리고 무엇이 좋은 결과물인지에 대한 다른 일련의 가정들을 반영했습니다.

둘 다 틀린 것은 아니었습니다. 단지 같지 않았을 뿐입니다. 그리고 충분히 많은 세션이 쌓이면, 이 "같지 않음"은 사소한 변형처럼 느껴지는 단계를 넘어, 코드베이스에 더 이상 작성자가 존재하지 않는 것처럼 느껴지기 시작합니다.

이것이 개발자 간의 불일치와 다른 이유

팀 내에 불일치가 발생하면 보통 추적이 가능합니다. 이 부분은 Sarah의 것이고, 이 부분은 Alex의 것이라고 말이죠. 스타일이 다른 이유는 사람이 다르기 때문입니다.

당신과 AI만이 함께할 때는, 그 불일치(inconsistency)의 원인을 탓할 제2의 인물이 존재하지 않습니다. 여전히 당신의 프로젝트이고, 모든 커밋(commit)에는 여전히 당신의 이름이 적혀 있지만, 구조와 명명(naming), 그리고 패턴에 관한 실제 결정들은 당신이라는 존재를 구체적으로 인식하지 못하는 무언가에 의해 내려졌습니다.

이는 참으로 묘한 기분을 느끼게 합니다. 법적, 직업적 관점에서 코드베이스(codebase)는 모든 면에서 당신의 것입니다. 하지만 실제로 코드가 읽히는 방식의 상당 부분은 당신이 결정한 것이 아니었습니다. 그것들은 당신이 직접 알려주지 않는 한, 당신의 선호도를 유지하지 못하는 도구에 의해 매 세션(session)마다 결정되었습니다.

당신의 코드베이스가 더 이상 당신의 것처럼 느껴지지 않는 이유는 당신이 코딩하는 방식을 잊어버렸기 때문이 아닙니다. 단일 세션을 넘어 지속될 수 있는 방식으로, 당신이 어떻게 코딩하는지를 AI에게 아무도 알려주지 않았기 때문입니다.

실제로 문제를 해결하기 위해 필요했던 것

나는 코드베이스를 다시 작성(rewrite)하지 않았습니다. 그것이 목적이 아니었으며, 그렇게 하기에는 시간이 너무 오래 걸려 가치가 없었을 것입니다.

내가 한 일은 자리에 앉아 내가 실제로 보고 싶은 패턴들을 직접 적어 내려가는 것이었습니다. 추상적인 원칙이 아니라, 구체적인 결정 사항들이었습니다:

컴포넌트(Components)는 그것이 속한 페이지가 아니라, 무엇을 렌더링(render)하는지에 따라 이름을 짓는다.
렌더링에만 영향을 미치는 상태(State)는 로컬(local)에 유지한다. 공유되는 모든 것은 전용 훅(hook)으로 이동한다.
모든 내보내기(exported) 함수는 타입 추론(inference)이 가능하더라도 명시적인 반환 타입(return type)을 가진다.

이 경우에는 세 가지 규칙이었지만, 시간이 지나면서 목록은 늘어났습니다. 각 규칙은 내 코드가 어떻게 보여야 하는지에 대해 내가 이미 믿고 있던 것들이었습니다. 단지 AI가 새로운 것을 생성하기 전에, AI가 볼 수 있는 곳에 그것을 적어둔 적이 없었을 뿐입니다.

그다음에 만든 몇 개의 컴포넌트들은 내가 직접 손으로 작성했을 법한 모습에 눈에 띄게 가까워졌습니다. AI가 더 똑똑해졌기 때문이 아닙니다. 처음으로 AI가 내가 무엇을 원할지 추측하는 대신, 따라야 할 구체적인 무언가를 갖게 되었기 때문입니다.

나를 놀라게 한 부분

나는 이 규칙들이 결과물을 더 일관되게 만들 것이라고 예상했습니다. 실제로 그랬습니다.

내가 예상하지 못했던 점은 오래된 파일을 열 때의 경험이 얼마나 크게 변했는가 하는 것이었습니다. 규칙들이 자리를 잡자, 새로운 컴포넌트들이 마치 제가 AI의 도움 없이 직접 작성했던 것들 옆에 놓여도 어색하지 않을 것처럼 보이기 시작했습니다. 프로젝트는 단순히 작동하는 코드들로 이어 붙인 일련의 단절된 결정체들이 아니라, 다시 하나의 통일된 결과물로 읽히기 시작했습니다.

이 부분은 제가 처음에 생각했던 것보다 훨씬 더 중요했습니다. 일관성 (Consistency)은 단순히 버그를 피하거나 코드 리뷰 (Code Review)를 빠르게 만드는 것만을 의미하지 않습니다. 그것은 자신의 프로젝트를 열었을 때 그것을 알아볼 수 있어야 한다는 것을 의미합니다.

만약 여러분의 코드베이스 (Codebase)가 실제 여러분의 사고 방식으로부터 멀어지고 있다는 것을 느꼈다면, 가장 먼저 살펴봐야 할 곳은 코드가 아닙니다. 그보다는 '나만의 코딩 방식'이 무엇인지에 대해 AI가 실제로 사용할 수 있는 형태로 기록해 둔 적이 있는지 확인해야 합니다.

→ React AI Clean Code 체크리스트 받기 — 무료

→ Avery Code React AI 엔지니어링 시스템