이 내용을 글로 정리해보고 싶었습니다. 놀라울 정도로 반복 가능한 결과가 나오고 있으며, 누군가 저에게 진작 이 방법을 설명해 주었더라면 좋았을 것이라는 생각이 들었기 때문입니다.

지난 1년 정도를 돌아보면, 2019년경의 제 기준과 비교했을 때 개발 속도가 최소 20배, 때로는 그 이상 빨라졌습니다. 이는 제가 타자를 더 빨리 치거나 절차를 생략하기 때문이 아니라, AI를 사용하는 방식을 바꿨기 때문입니다.

요약하자면 이렇습니다: 저는 에디터(Editor) 내부에서 AI를 사용하지 않습니다. 대신 브라우저에서 전체 컨텍스트(Context)를 가진 두 개의 AI를 병렬로 사용합니다.

설정 방법은 다음과 같습니다.

저는 두 개의 탭을 열어둡니다:

1. "빌더(Builder)" 역할을 하는 AI 하나. 많은 컨텍스트를 전달받아 무거운 작업(Heavy lifting)을 수행합니다.

2. "리뷰어(Reviewer)" 역할을 하는 AI 하나. 오직 디프(Diffs)만을 확인하며 실수를 찾아내려고 시도합니다.

그게 전부입니다. 플러그인도, 특별한 도구도 필요 없습니다. 그저 브라우저 탭과 터미널(Terminal)만 있으면 됩니다.

중요한 부분은 컨텍스트(Context)입니다. 코드 조각(Snippets)을 요청하는 대신, 파일 전체나 모듈 전체를 붙여넣고 목표를 설명합니다. AI에게 코드를 작성하기 전에 트레이드오프(Tradeoffs)를 포함한 접근 방식부터 설명하도록 요청합니다. 이렇게 하면 제가 이해하지 못하는 덩어리(Blob)를 그대로 받아들이는 대신, 아키텍처(Architecture)에 대한 통제권을 유지할 수 있습니다.

전형적인 흐름은 다음과 같습니다:

1. 관련된 여러 파일(종종 여러 언어에 걸친 파일)을 붙여넣습니다.

2. 원하는 변경 사항을 설명하고 선택지들에 대한 설명을 요청합니다. 개념, 위키피디아 등을 읽고 요약합니다.

3. 접근 방식을 선택합니다. 트레이드오프(Trade-offs), 개념, 적대적 보안(Adversarial security) 등에 대해 광범위하게 대화합니다. OS가 허용하는 방식으로 일을 처리할 방법을 찾습니다.

4. AI가 모든 파일에 걸쳐 이를 구현하도록 합니다.

5. 디프(Diff)를 두 번째 AI에 복사하여 회귀(Regressions), 누락된 인자(Arguments), 또는 미묘한 기능 고장(Subtle breakage)이 있는지 확인하도록 요청합니다.

6. 발견된 사항을 수정합니다.

배포(Ship).

두 번째 AI는 제가 빠르게 작업할 때 놓칠 수 있는 많은 것들을 잡아냅니다. 예를 들어 "이 호출 시그니처(Call signature)를 변경했지만 호출자(Caller) 중 하나를 업데이트하지 않았습니다"라거나 "이 기본값(Default value)이 동작을 미묘하게 변경했습니다"와 같은 것들 말입니다.

저를 놀라게 한 점은 크로스 스택 (cross-stack) 작업이 얼마나 더 빨라지는가 하는 점입니다. 경계를 넘나든다는 이유로(Swift → Obj-C → JS, 또는 백엔드(backend) → 프론트엔드(frontend)) 중단되곤 했던 작업들이, AI가 이 모든 것을 한 번에 추론할 수 있기 때문에 매우 간단해집니다.

저는 "외과적 편집 (surgical edits)"에 대해 의도적으로 엄격하게 규칙을 정하고 있습니다. 명시적인 작업이 아닌 이상 AI가 파일을 통째로 다시 쓰게 두지 않습니다. 대신 추가하거나 변경할 정확한 라인을 요청합니다. 이렇게 하면 디프 (diff)가 작게 유지되어 검토가 용이해집니다.

이는 자동 완성 (autocomplete) 스타일의 도구들과는 매우 다릅니다. 그런 도구들은 로컬 편집에는 훌륭하지만, 여전히 파일 간의 통합(integrator) 역할은 사용자의 몫으로 남겨둡니다. 이 방식은 그 관계를 뒤집습니다. 사용자는 설계자(architect)이자 검토자(reviewer)로 남고, AI가 통합 작업을 수행하며, 두 번째 AI가 이를 검증(sanity-check)합니다.

비용은 한 달에 총 약 40달러 정도가 듭니다. 진짜 비용은 절제력(discipline)입니다. 항상 컨텍스트 (context)를 제공하고, 항상 디프 (diff)를 검토하며, 이해하지 못하는 코드는 절대 붙여넣지 않는 태도 말입니다.

제가 이것을 공유하는 이유는 이것이 단순한 눈속임(gimmick)이 아니라 저에게 진정한 단계적 변화(step-change)를 가져다주었기 때문입니다. 한계점, 실패 모드(failure modes), 또는 이 방식이 제대로 작동하지 않는 부분에 대한 질문은 언제든 환영합니다.

다음은 저희 팀 개발자들을 위해 제가 정리한 위키(wiki) 형식의 개요입니다: