나의 AI와의 관계는 어떻게 진화했는가?
요약
시니어 개발자가 AI 도구를 단순한 코드 생성기를 넘어 기획자와 작업자로 분리하여 활용하며 업무 워크플로를 진화시킨 과정을 다룹니다. 다양한 LLM 모델의 특성을 파악하고, 프로젝트의 성격에 따라 모델을 전략적으로 배치하는 멘탈 모델 구축의 중요성을 강조합니다.
핵심 포인트
- AI를 단순 생산성 도구가 아닌 기획자와 작업자로 역할 분리하여 활용
- 모델별 특성(추론, 코드 생성, 트레이드오프 설명 등)에 따른 전략적 선택 필요
- Gemini 1.5 Pro를 기획자로, Copilot/Claude를 작업자로 활용하는 워크플로 제안
- 시니어 개발자에게 AI는 단순 보조를 넘어선 강력한 레버리지 도구
모두가 AI가 주니어 개발자들이 이전에는 작성할 수 없었던 코드를 작성하도록 어떻게 돕고 있는지에 대해 이야기합니다. 그것은 사실입니다. 하지만 잘 알려지지 않은 이야기가 있습니다. 바로 시니어 개발자가 이러한 도구들을 집어 들었을 때 어떤 일이 일어나는가 하는 점입니다. 그 레버리지(leverage)는 완전히 다르며, 저는 이를 사용한 지 6개월이 지나서야 완전히 이해하게 되었습니다.
조심스러운 실험 단계에서부터 오늘날 제가 의존하고 있는 워크플로(workflow)에 이르기까지, AI와의 업무 관계가 실제로 어떻게 진화했는지 소개합니다.
1단계: Copilot으로 간 보기
저는 대부분의 개발자가 시작하는 곳, 즉 2025년 어느 시점에 VSCode 내의 GitHub Copilot으로 시작했습니다. 저는 AI에게 기능을 만들어 달라고 요청하지 않았습니다. 대신 아무도 이야기하지 않는 시니어 업무의 일상적인 레이어, 즉 요약 보고서, 적절한 어조가 필요한 기술 이메일, 스프린트 계획(sprint planning)을 위한 빠른 추정치 산출 등에 사용했습니다.
그것은 충분히 유용해서 호기심이 생겼습니다. 저는 차이점을 이해하기 위해 의도적으로 모델을 교체하기 시작했습니다: GPT-4, Claude Sonnet, Gemini X Pro, Kimi2.5, Minimax. 각 모델은 서로 다른 특성을 가지고 있었습니다. 어떤 모델은 구조적 추론(structured reasoning)에 더 뛰어났고, 어떤 모델은 깔끔한 코드를 생성하는 데, 또 어떤 모델은 트레이드오프(tradeoffs)를 설명하는 데 뛰어났습니다. 저는 어떤 기사에서 시켜서가 아니라 매일 비공식적인 실험을 수행하면서, _어떤 작업에 어떤 도구를 사용할지_에 대한 멘탈 모델(mental model)을 구축하기 시작했습니다.
이 시점에서 AI는 제가 이미 할 줄 아는 일들에 대한 생산성 승수(productivity multiplier)였습니다. 유용했지만, 아직 변혁적이지는 않았습니다.
2단계: 기획자/작업자 실험
2026년 1월, 저는 Live Dubbing for Holoscan 프로젝트를 시작했습니다. 이는 제가 한 번도 다뤄본 적 없는 프레임워크인 NVIDIA의 Holoscan SDK를 사용하여 실시간 음성-대-음성(speech-to-speech) 파이프라인을 구축하는 프로젝트였습니다. 기술적 깊이가 상당했습니다: ASR 모델, 번역, TTS, 저지연 스트리밍(low-latency streaming), 생소한 API들.
저는 이전에 해본 적 없는 시도를 했습니다. 서로 다른 역할을 가진 두 개의 AI 시스템을 동시에 사용하는 것이었습니다.
기획자로서의 Gemini 1.5 Pro. 저는 이를 연구, 아키텍처 결정, 그리고 생소한 영역을 이해하는 데 사용했습니다. 문제를 제시하면 접근 방식에 대한 구조화된 분석을 얻을 수 있었습니다.
GitHub Copilot + Claude Sonnet을 작업자 (Worker)로 활용. 구현 계층 (Implementation layer)입니다. 무엇을 왜 만들어야 하는지 알게 된 후에는, Copilot이 IDE 내부에서 구현 세부 사항을 처리했습니다.
이러한 분리는 제가 예상했던 것보다 더 중요했습니다. 기획자 (Planner) 역할은 넓은 문맥 (Context), 문서 전반에 걸친 추론, 그리고 '왜'에 대한 이해를 필요로 했습니다. 이는 큰 컨텍스트 윈도우 (Context window)와 강력한 추론 능력을 갖춘 모델로부터 이점을 얻을 수 있는 요소들입니다. 반면 작업자 (Worker) 역할은 정밀함과 실제 코드의 흐름을 유지하는 능력을 필요로 했습니다. 두 역할에 동일한 모델을 사용하는 것은 건축가에게 벽돌까지 쌓으라고 요구하는 것과 같습니다.
3단계: 사고방식을 바꾼 깨달음
Claude에 접근 권한을 얻고 Cowork과 Claude Code를 함께 사용하기 시작했을 때, 제가 분명하게 말하고 싶은 무언가가 머릿속에서 정리되었습니다.
저는 운영 서비스 (Production services)에서 Python을 사용하여 작업합니다. 솔직히 제 Python 수준은 주니어에서 중급 사이입니다. 코드를 읽을 수 있고, 무슨 일이 일어나는지 이해하며, 디버깅도 할 수 있습니다. 하지만 프로젝트가 요구하는 속도로 GPU 가속 오디오 처리가 포함된 프로덕션급 FastAPI 서비스를 처음부터 구축할 수 있는 능력은 있다고 주장하지 않았을 것입니다.
그런데 실제로 해냈습니다. 코드는 배포되었고, 운영 환경에서 작동하며, 실제 사용자들을 처리하고 있습니다.
그 이유는 다음과 같습니다: AI는 좋은 아키텍처 (Architecture)가 무엇인지 모릅니다. 제가 알고 있습니다.
AI를 사용하는 주니어 개발자는 작동하는 코드를 생성할 것입니다. AI를 사용하는 시니어 개발자는 작동하면서도 올바르게 구조화되어 있고, 예외 케이스 (Edge cases)를 처리하며, 적절하게 확장 가능하고, 6개월 뒤에 무너지지 않는 더 큰 시스템에 부합하는 코드를 생성할 것입니다. AI는 코드 라인을 작성합니다. 경험은 어떤 라인을, 어떤 순서로, 어떤 제약 조건 하에 작성할지를 결정합니다.
주니어와 시니어 개발자의 차이는 결코 문법 (Syntax)을 아는 것에 그치지 않았습니다. 그것은 판단력 (Judgment)에 관한 문제였습니다. 어떤 문제가 실제로 어려운지, 어떤 추상화 (Abstractions)가 부하를 견뎌낼 수 있는지, 어떤 지름길이 나중에 비용을 치르게 할지를 아는 것입니다. AI는 그 격차를 줄이지 않습니다. AI는 당신이 이미 가지고 있는 판단력을 증폭시킬 뿐입니다.
4단계: 현재의 워크플로 (Workflow)
오늘날 저의 작업 프로세스는 다음과 같습니다:
AI 우선의 연구 및 계획 (Research and planning with AI first). 티켓을 작성하거나 브랜치 (branch)를 시작하기 전에, 저는 Claude를 사용하여 문제를 깊이 있게 생각합니다. 제가 무엇을 만들고 있는지, 제약 조건은 무엇인지, 기존 아키텍처 (architecture)는 어떠한지를 설명합니다. 그 결과물은 실제 기획 회의에서 제가 방어할 수 있는 구조화된 접근 방식이 됩니다.
계획이 가시적인 산출물 (artifacts)이 됩니다. 기획 세션에서 나온 내용을 가져와 Jira와 GitHub Projects에 반영합니다. 이것이 중요합니다. 계획은 단순히 제 머릿속이나 채팅창 안에 머무는 것이 아니라, 팀원들이 보고, 의견을 남기고, 제가 계획을 준수하는지 확인할 수 있는 곳에 존재하게 됩니다.
자동화가 보고 오버헤드 (reporting overhead)를 제거합니다. 저는 n8n을 사용하여 일일 업무 업데이트를 자동화합니다. 매니저는 Jira와 GitHub에서 실제로 일어난 일을 바탕으로 생성된 상태 보고서를 받습니다. 수동으로 작성하는 업데이트도, "이번 주에 무엇을 했나요?"라는 질문에 허둥지둥 대답할 필요도 없습니다. 복잡한 구현은 아니었지만, 매주 실질적인 시간을 절약해주며 추가적인 노력 없이도 제 업무를 더 잘 보이게 만들어 줍니다.
MCP 서버가 도구들을 연결합니다. 시도해 보지 않은 사람에게 설명하기 가장 어려운 부분은 이것입니다. 시스템 간에 복사하여 붙여넣는 대신, AI 어시스턴트가 프로젝트 관리 시스템을 직접 쿼리(query)하고, GitHub PR을 읽고, 워크플로 (workflow)를 실행할 수 있게 되면 오버헤드가 현저히 줄어듭니다. 저는 GitHub, Jira, n8n에 대한 MCP 연결을 가지고 있으며, 업무가 얼마나 유연하게 느껴지는지 그 차이는 실재합니다.
이 여정을 시작하려는 사람에게 해주고 싶은 말
"어떻게 하면 AI를 사용해 코드를 더 빨리 짤 수 있을까"로 시작하지 마세요. 대신 "내 업무에서 흥미로운 부분이 아닌데, 실제로 시간을 쓰고 있는 것은 무엇인가?"로 시작하세요.
저의 경우 그것은 상태 업데이트 작성, 아키텍처 결정을 티켓으로 변환하기, 전문 지식이 없는 언어의 공백 메우기, 그리고 생소한 API 조사하기였습니다. AI는 이 모든 일에 놀라울 정도로 뛰어납니다.
업무의 흥미로운 부분 — 무엇을 만들지, 왜 만드는지, 시스템에 어떻게 부합하는지, 부하 상황에서 무엇이 깨질지 결정하는 것 — 그 부분은 여전히 당신을 필요로 합니다. 도구들은 단지 당신이 그 부분에 집중할 수 있도록 다른 소음들을 제거해 줄 뿐입니다.
나는 GitHub Copilot과 약간의 호기심으로 이 과정을 시작했습니다. 1년이 지난 지금, 나는 이전에는 같은 속도나 품질로는 결코 만들 수 없었을 것들을 만들어내고 있습니다. 이는 AI가 나의 판단력을 대체했기 때문이 아닙니다. AI가 마침내 나의 판단력이 제 역할을 다할 수 있도록 충분한 여유를 주었기 때문입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기