저는 지난 3개월 동안 AI 중심의 에디터를 사용했습니다. 처음에는 마치 초능력 같았습니다. 키보드 단축키를 누르고 기능을 설명하면, React 코드 50줄이 나타나는 것을 볼 수 있었습니다. 빠르다고 느꼈습니다. 그러다가 버그들이 터지기 시작했습니다.

저는 제가 위험한 습관을 들였다는 것을 깨달았습니다. 즉, 제가 완전히 이해하지 못한 코드를 받아들이고 있었다는 것입니다. AI가 작성한 컴포넌트에 프로덕션 버그가 발생했을 때, 저는 실제로 그 코드를 작성한 것이 아니었기 때문에 로직을 파악하는 데 40분을 소비했습니다. 저는 제 자신의 코드에 대한 리뷰어였지만, 게으른 리뷰어였습니다.

제가 실제로 통제권을 유지하기 위해 워크플로우를 바꾼 방법은 다음과 같습니다.

큰 프롬프트의 함정

가장 큰 실수는 한 번에 전체 기능을 요청하는 것입니다. '정렬 및 필터링이 가능한 페이지네이션 테이블을 만들어 줘'라고 프롬프트를 입력하면, AI는 거대한 코드 블록을 제공할 것입니다. 그것은 올바르게 보일 것이고, 첫 실행에서는 아마 작동할 것입니다.

하지만 그 코드는 블랙박스입니다. 종종 불필요한 의존성, 프로젝트에 맞지 않는 이상한 엣지 케이스 처리, 또는 구식 API 패턴을 포함합니다. 100줄의 diff를 받아들이는 것은 본질적으로 자신이 설계하지 않은 100줄의 로직을 유지해야 한다는 계약서에 서명하는 것과 같습니다.

원자적 프롬프팅 방법 (Atomic Prompting Method)

큰 블록 대신, 저는 원자적 프롬프트(atomic prompts)로 전환했습니다. 작업을 가능한 가장 작은 논리적 단위로 분해합니다.

먼저, 타입 또는 인터페이스를 정의합니다. TypeScript 정의만 요청하도록 프롬프트를 입력합니다. 그것을 검토하고 수정합니다. 데이터 형태가 확정되면 다음 단계로 넘어갑니다.

다음으로, 단일 헬퍼 함수(helper function)에 대해 프롬프트를 입력합니다. 예를 들어, '이 특정 객체 배열을 날짜별로 정렬하는 함수를 작성해 줘'와 같습니다. 저는 그 함수를 격리된 상태에서 테스트합니다.

마지막으로, AI에게 이 조각들을 UI에 연결하도록 요청합니다. 컴포넌트가 완성될 때쯤이면, 저는 이미 모든 헬퍼 함수와 모든 타입 정의를 이해하고 있습니다. 왜냐하면 제가 과정을 단계별로 안내했기 때문입니다.

AI를 작가(Ghostwriter)가 아닌 고무 오리(Rubber Duck)처럼 사용하기

저는 채팅 기능을 다르게 사용하기 시작했습니다. 단순히 "이 버그를 고쳐줘"라고 말하는 대신, 이제는 "이 버그가 왜 발생할 수 있는지 설명해주고, 조사해 볼 만한 세 가지 가능한 방향을 제시해 줘."라고 말합니다.

이렇게 하면 제 두뇌가 계속 집중하게 됩니다. AI가 단순히 해결책을 주면, 제 두뇌는 작동을 멈춥니다. 하지만 AI가 이론을 제시하면, 저는 여전히 그 해결책을 구현하는 작업을 해야 합니다. 여기서 실제 학습이 일어납니다. 문제 해결을 멈추면, 여러분의 기술은 퇴화합니다. 여러분은 프롬프트 엔지니어가 되는데, 이는 요구사항과 기계 사이의 중개자라는 것을 멋지하게 표현한 말일 뿐입니다.

코드 리뷰 규칙 (The Code Review Rule)

저는 개인적인 규칙을 세웠습니다. AI가 생성한 코드는 모든 줄에 대해 가상의 주니어 개발자에게 설명할 수 있을 때까지 커밋하지 않겠다는 것입니다.

AI가 만든 정규 표현식(regex pattern)이 마법처럼 보인다면, 저는 그것을 받아들이지 않습니다. AI에게 그 정규 표현식을 분해해 달라고 요청합니다. 몇 가지 문자열에 대해 테스트를 합니다. 이 '마법'의 원리를 이해한 후에야 커밋합니다.

이렇게 하면 초기 개발 속도는 느려지지만, 디버깅 단계에서 소비되는 시간을 극적으로 줄여줍니다. 만약 그 속도가 여러분이 헤쳐나갈 수 없는 기술 부채(technical debt)를 초래한다면, 그 속도는 거짓말입니다.

구체적인 시사점 (Concrete Takeaways)

만약 AI 에디터를 사용하고 있다면, 이번 주에 이 세 가지를 시도해 보세요:

1. Diff 제한하기. 만약 AI가 한 번에 20줄 이상의 변경 사항을 제안한다면, 프롬프트를 더 작은 조각들로 나누세요.
2. '어떻게(How)'보다 '왜(Why)'를 먼저 요청하기. 코드를 요청하기 전에 논리나 계획을 물어보세요.
3. 수동 리팩토링 (Manual Refactor). AI가 작동하는 해결책을 생성한 후, 여러분의 스타일에 맞게 변수 이름을 수동으로 변경하거나 루프 구조를 재구성하세요. 이는 여러분이 코드를 주의 깊게 읽도록 강제합니다.

AI는 보일러플레이트(boilerplate) 코드를 제거하는 데 훌륭한 도구이지만, 건축가로서는 형편없습니다. 아키텍처는 머릿속에 유지하고, AI를 빈틈을 채우는 용도로 사용하세요.