먼저 솔직하게 말씀드리겠습니다. 제가 배포하는 코드의 상당 부분은 AI가 작성합니다. Exequtech에서 기술자들이 사용하는 오프라인 우선 (offline-first) Android 앱, 이 웹사이트의 일부, 마이그레이션 스크립트 (migration scripts), 테스트 스위트 (test suites) — Claude Code가 제 터미널에서, 제 눈앞에서 이 중 많은 부분을 작성했습니다. 이것이 저를 엔지니어로서 덜 가치 있게 만든다고 생각하지 않습니다. 저는 제가 '어떻게' 하는지가 저를 결정한다고 생각합니다.

몇 년 전, 저는 AI와 제대로 협업하는 법을 배우는 것을 목표로 삼았습니다. 그것이 유행이기 때문이 아니라, 우리는 실제 사용자가 있는 제품을 소규모 팀으로 운영하고 있으며, 이러한 레버리지 (leverage)를 거부하는 것은 직무 유기에 가깝기 때문입니다. 제가 예상하지 못했던 점은, 그 레버리지가 실제로 얼마나 많은 기술을 요구하는가 하는 점이었습니다.

혼돈 관리하기 (Managing the chaos)

방치해 두면, 에이전트 (agent)는 그럴듯한 혼돈을 만들어냅니다. 요청하지 않은 부분을 리팩터링 (refactor)하고, 거의 존재할 법한 API를 발명하며, 이러한 도구를 사용하는 대부분의 개발자들이 말하듯 '거의' 맞는 코드를 작성합니다. '거의' 맞다는 것은 비용이 많이 드는 종류의 오류입니다. 컴파일은 되고 데모도 잘 되지만, 3주 뒤 신호가 전혀 잡히지 않는 지하 공간에서 폭발해 버립니다.

따라서 저의 업무는 매우 빠르고 매우 자신감 넘치는 주니어 개발자를 위한, 매우 실무 중심적인 테크 리드 (tech lead)가 되는 것과 비슷해졌습니다:

• 프롬프트 작성 전에 문제를 구조화하세요 (Structure the problem before the prompt). 만약 제가 제약 사항을 정확하게 명시할 수 없다면 — 예: "쓰기 작업은 로컬에서 성공하고 큐(queue)에 들어가야 하며, 네트워크 상태가 양호할 때 큐가 비워져야 한다" — 에이전트(agent)는 이를 달성할 수 없습니다. 그리고 제약 사항을 명시하지 못한다는 사실 자체가 제가 아직 제 자신의 문제를 이해하지 못하고 있다는 신호라는 것을 배웠습니다.

• 디프(diffs)를 읽으세요. 대충 훑어보지 말고, 정독하세요. 제가 읽기를 멈춘 날, "작은 수정"이 동기화 충돌(sync conflicts)이 해결되는 방식을 조용히 바꿔놓았습니다. 다시는 그러지 않을 것입니다.

• 수용하는 대신 심문하세요. "왜 여기서 Dispatchers.IO를 사용했나요?"라고 묻는 것은 매번 얻을 수 있는 무료 레슨입니다. 에이전트는 제가 스스로를 설명하게 만들 때만, 제가 경험해 본 가장 빠른 스승이 됩니다.

• 결과에 책임을 지세요. 밤 10시에 동기화(sync) 과정에서 사진이 삭제되었을 때, 아무도 모델에게 무슨 일이 일어났는지 묻지 않습니다. 사람들은 저에게 묻습니다. 그 책임감이 도구를 사용하는 것과 도구의 승객이 되는 것 사이의 근본적인 차이입니다.

예상치 못했던 점: 타이핑이 그리워졌다

어느 순간 저는 불편한 점을 하나 발견했습니다. 저는 그 어느 때보다 더 많은 결과물을 내놓고 있었지만, 코딩은 그 어느 때보다 적게 하고 있었습니다. 그리고 저는 그것이 그리워졌습니다. 더 나쁜 것은, 오직 리뷰만 할 때 퇴화하는 것들을 느낄 수 있었다는 점입니다. 언어에 대한 손가락의 감각(finger-knowledge), 표준 라이브러리(standard library)가 무엇을 제공하는지에 대한 본능, 그리고 에이전트가 주변을 맴돌 때 까다로운 함수를 직접 작성할 수 있는 능력 말입니다.

그래서 저는 가능한 한 방향을 수정하고 있습니다. 스프린트(sprint)가 허락할 때면, 직접 코드를 작성하며 기초를 제대로 다집니다. 솔직히 말하자면, 시스템은 제가 공부할 수 있는 시간보다 더 빠르게 성장하는 경우가 많습니다. 이것은 제가 계속해서 응답해야 하는 이끌림이지, 제가 완전히 숙달한 루틴은 아닙니다. 깊이를 유지하는 것이 목표이며, 속도가 매주 제가 얼마나 그 깊이에 도달할 수 있는지를 결정합니다.

정체성이 아닌 도구

저는 저 자신을 Kotlin 개발자나 React 개발자라고 부르지 않으며, 그렇다고 AI 위스퍼러 (AI whisperer)라고 자처하지도 않습니다. 언어, 프레임워크, 에이전트 (agents) — 이들은 모두 도구일 뿐입니다. 중요한 질문은 언제나 동일합니다. 이 문제, 이 팀, 그리고 우리가 실제로 할 수 있는 것을 고려했을 때, 최선의 해결책은 무엇인가? 때로는 해당 플랫폼을 잘 아는 파트너와 함께하는 노코드 (no-code) 방식이었을 수도 있습니다. 때로는 짧은 목줄을 채운 에이전트 (agent)였을 수도 있습니다. 그리고 때로는, 제가 시간을 낼 수 있을 때 직접 타이핑을 하는 저 자신이었을 수도 있습니다.

이 워크플로우 (workflow)가 실제 운영 환경에서도 유효하다는 증거는 다음과 같습니다: Exequ-Jobs 및 Exequtech OS.