저의 긴 IT 커리어 중 지난 1년만큼 제가 일하는 방식을 극적으로 변화시킨 해는 없었습니다. 단 12개월 만에 저는 똑똑한 자동 완성 (autocomplete)을 사용하는 단계에서, 실제 제품 출시를 돕는 에이전트 (agents) 팀을 지휘하는 단계로 나아갔습니다. 그래서 저는 이러한 변화 뒤에 숨겨진 개인적인 여정과 우리가 다음에 어디로 향하고 있다고 믿는지에 대해 공유하기로 했습니다. --- AI가 제가 제품을 만들고, 새로운 스택 (stacks)을 배우며, 가족 생활과 소프트웨어 개발을 병행하는 방식을 어떻게 바꾸었는가

1년 전, AI는 저에게 주로 더 똑똑한 자동 완성 (autocomplete)이었습니다. 최근에는 AI 에이전트 (AI agents) 덕분에 이전에 한 번도 다뤄본 적 없는 스택 (stack)을 사용하여 약 일주일 만에 크로스 플랫폼 모바일 앱을 구축하고 게시할 수 있었습니다. 그것은 중단 없이 코딩만 한 풀타임 일주일이 아니었습니다. 업무, 가족에 대한 책임, 그리고 아기를 돌보는 일 사이사이에 집중적으로 진행한 일련의 세션들이었습니다. 저는 에이전트 (agents)들에게 목표를 부여했습니다. 그들은 프로젝트를 검토하고, 코드를 작성하고, 테스트를 실행하고, 오류를 수정하고, 브라우저 흐름 (browser flows)을 처리하며, 앱의 출시 준비를 도왔습니다. 저는 작업을 검토하고, 결정을 내리고, 방향을 수정하며, 중요한 단계들을 승인했습니다. 그 경험은 이 변화를 무시할 수 없게 만들었습니다. AI 개발은 더 이상 단순히 코드를 더 빨리 작성하는 것에 관한 것이 아닙니다. 그것은 한 개인이 책임감 있게 시도할 수 있는 범위를 바꾸고 있습니다.

더 나은 키보드에서 시작되다
저의 첫 번째 본격적인 AI 개발 도구는 JetBrains 제품 내의 GitHub Copilot이었습니다. 당시에는 이를 더 똑똑한 자동 완성 (autocomplete)이라고 부르는 것이 정확했습니다. 그것은 반복적인 코드를 완성하고, 변수 이름을 제안하며, 작은 함수들을 도와주고, 생소한 언어에 대한 두려움을 줄여주었습니다. 제가 Go 언어를 배우고 작성할 때, 그것은 공통적인 패턴을 인식하고 더 빠르게 움직일 수 있도록 도와주었습니다. 하지만 워크플로 (workflow)는 여전히 완전히 인간 주도적이었습니다. 제가 아키텍처 (architecture)를 계획했습니다. 어떤 파일을 수정할지 결정했습니다. 터미널에서 오류를 복사했습니다. 로그 (logs)를 검토했습니다. 모든 변경 사항을 테스트했습니다. 프로젝트의 전체 컨텍스트 (context)를 제 머릿속에 담고 있었습니다. GitHub Copilot은 유용했지만, 혁명처럼 느껴지지는 않았습니다. 마치 더 나은 키보드처럼 느껴졌습니다.

Cursor가 그 느낌을 바꾸어 놓았습니다. Cursor는 워크플로 (workflow)가 다르게 느껴지게 만든 첫 번째 도구였습니다. 코드 완성 (completions) 기능이 향상되었지만, 그것이 중요한 부분은 아니었습니다. 진짜 변화는 어시스턴트 (assistant)가 프로젝트의 더 많은 부분을 이해할 수 있게 되었다는 점이었습니다. 채팅 (Chat)은 저장소 수준 (repository-level)의 질문에 유용해졌습니다. 에이전트 모드 (Agent mode)는 코드 완성 그 이상의 무언가처럼 느껴지기 시작했습니다. 비슷한 시기에 모델 생태계 (model landscape)도 빠르게 변하고 있었습니다. GPT 모델, Claude 모델, Gemini 모델, 그리고 초기 추론 모델 (reasoning models)들은 모두 각기 다른 강점을 가지고 있었습니다. 모델을 선택하는 것이 엔지니어링 프로세스 (engineering process)의 일부가 되었습니다. 어떤 모델은 Python에 더 뛰어날 수 있습니다. 다른 모델은 인프라 (infrastructure)를 더 안정적으로 처리할 수도 있습니다. 어떤 모델은 어려운 아키텍처 (architecture) 문제를 추론해낼 수 있지만 속도가 느릴 수 있습니다. 또 다른 모델은 코드를 빠르게 생성하지만 더 많은 검토 (review)를 필요로 할 수도 있습니다. 도구들이 계속해서 개선되었기 때문에 영구적인 승자는 없었습니다. 이는 저에게 첫 번째 중요한 교훈 중 하나를 주었습니다. AI 개발에서 진정한 가치를 얻으려면 실험 (experimentation)이 필요하다는 것입니다. 어떤 모델이 작업에 적합한지, 얼마나 많은 컨텍스트 (context)가 필요한지, 그리고 어디에서 실패할 가능성이 높은지를 이해해야 합니다. 초기 워크플로는 강력하면서도 고통스러웠습니다. 그 단계에서 AI는 진지한 업무를 도울 수 있었지만, 여전히 인간이 많은 수동적인 연결 고리 (manual glue) 역할을 해야 했습니다. 브라우저에서 무언가 실패하면, 콘솔 에러 (console error)를 복사하여 채팅에 붙여넣었습니다. 페이지가 잘못되어 보이면, 시각적인 문제를 말로 설명했습니다. 모델이 잘못된 변경 사항을 생성하면, 디프 (diff)를 검사하고 실수를 설명한 뒤 다시 시도하도록 요청했습니다. 때로는 작업 중간에 지시 사항을 잊어버리기도 했습니다. 때로는 자신 있게 잘못된 방향으로 나아가기도 했습니다. 때로는 문제의 80%를 해결하고 마지막 20%에서 새로운 문제를 만들어내기도 했습니다. 하지만 저는 혼자였다면 시도하지 않았을 것들을 만들어가고 있었습니다. 저는 전 세계의 따뜻한 해수 지역을 보여주고, 이를 웹캠 (webcams)과 연결하며, 기상 조건에 따라 사람들이 여행 아이디어를 발견할 수 있도록 돕는 날씨 제품을 탐구했습니다. TTS Buddy 개발을 계속했습니다. 크롬 확장 프로그램 (Chrome extension)을 실험하기도 했습니다.

저는 프론트엔드 (frontend), 백엔드 (backend), 인프라스트럭처 (infrastructure), 배포 (deployment), 그리고 사용자 경험 (user experience) 전반에 걸쳐 작업했습니다. 그것이 제 사고방식의 첫 번째 실질적인 변화였습니다. 가치는 단순히 AI가 저를 대신해 코드를 작성해 준다는 것에 있지 않았습니다. 가치는 제가 평소라면 시작하기를 망설였을 기술적 영역에 진입할 수 있도록 AI가 도와주었다는 점에 있었습니다. 더 큰 컨텍스트 (context)가 새로운 작업 패턴을 만들어냈습니다. 더 큰 컨텍스트 윈도우 (context windows)를 가진 모델들이 워크플로 (workflow)를 다시 한번 변화시켰습니다. Gemini 2.5 Pro는 이 단계에서 특히 유용했습니다. 리포지토리 패킹 (Repository-packing) 도구들을 통해 프로젝트의 상당 부분을 수집하고, 모델에게 아키텍처 (architecture)를 분석하고, 패턴을 식별하며, 상세한 구현 계획을 세울 수 있을 만큼 충분한 컨텍스트를 제공하는 것이 가능해졌습니다. 과정은 여전히 어색했습니다. 리포지토리를 패킹하여 하나의 모델에 보내 분석을 요청한 다음, 그 계획을 Cursor나 다른 코딩 도구로 옮겨 구현했습니다. 때로는 출력을 더 집중시키기 위해 아키텍트 (architect), 개발자 (developer), 또는 테스터 (tester)와 같은 역할을 부여하기도 했습니다. 워크플로에는 한계가 있었습니다. 요청이 너무 커질 수 있었고, 계획은 훌륭하게 들리면서도 실질적인 세부 사항을 놓칠 수 있었습니다. 구현에는 종종 여러 차례의 수정 과정이 필요했습니다. 하지만 유용한 패턴이 나타났습니다. 하나의 모델을 사용하여 시스템에 대해 깊이 생각하게 하고, 그다음 다른 에이전트 (agent)를 사용하여 작업을 실행하는 것입니다. 즉, '두뇌'와 '손'을 분리하는 것입니다. 오늘날 그 패턴은 자연스럽게 느껴지지만, 당시에는 매주 새로운 개발 프로세스를 설계하는 것처럼 느껴졌습니다. CLI 에이전트가 위임하는 법을 가르쳐 주었습니다. 다음 주요 변화는 Claude Code나 Codex와 같은 CLI 기반 코딩 에이전트로부터 왔습니다. 처음에는 불편했습니다. 엔지니어들은 코드와 밀접하게 붙어 있는 것에 익숙합니다. 우리는 파일을 직접 보고, 모든 수정을 검사하며, 각 명령어를 이해하고 싶어 합니다. 그런데 갑자기 에이전트가 리포지토리를 검색하고, 파일을 수정하고, 테스트를 실행하고, 실패를 검사하고, 코드를 패치(patch)한 뒤 다시 시도할 수 있게 된 것입니다. 터미널 (terminal)은 단순히 명령어를 입력하는 장소가 아니게 되었습니다. 에이전트가 작동할 수 있는 워크스페이스 (workspace)가 되었습니다. 가장 큰 조정은 기술적인 것이 아니었습니다. 그것은 바로 위임하는 법을 배우는 것이었습니다.

저는 변경을 원하는 모든 줄을 일일이 설명하는 것을 멈추고 결과(outcomes)를 정의하기 시작해야 했습니다. 목표는 무엇인가? 어떤 제약 조건(constraints)을 준수해야 하는가? 무엇이 변해서는 안 되는가? 작업이 올바르게 수행되었음을 어떻게 알 수 있는가? 어떤 결정에 나의 승인이 필요한가? 명확한 수락 기준(acceptance criteria)이 세세한 마이크로매니지먼트(micromanagement)보다 더 가치 있게 되었습니다. 이를 깨닫고 나니, AI 지원 코딩(AI-assisted coding)은 에이전트 엔지니어링 (agentic engineering)처럼 느껴지기 시작했습니다. 에이전트는 더 이상 명령어를 제안하는 것에 그치지 않았습니다. 명령어를 실행하고, 결과를 검사하며, 에러를 이해하고, 구현(implementation)을 변경하고, 테스트를 재실행하며 계속 진행할 수 있었습니다. 이것은 완전히 다른 작업 모델입니다.

벤치마크 (Benchmarks), MCP, 그리고 스킬 (skills)이 시스템을 더욱 실용적으로 만들었습니다. 모델이 개선됨에 따라 평가 (evaluation)가 더욱 유용해졌습니다. Artificial Analysis와 같은 서비스와 SWE-bench, Terminal-Bench, OSWorld와 같은 벤치마크는 실질적인 질문에 답하는 데 도움을 주었습니다. 어떤 모델이 코딩에 더 나은가? 어떤 모델이 터미널 작업을 더 잘 처리하는가? 어떤 모델이 긴 작업 동안 신뢰성을 유지할 수 있는가? 어떤 모델이 속도, 비용, 정확도 사이에서 최적의 균형을 제공하는가? 잘못된 선택은 우아한 난장판을 만들 수 있기 때문에, 모델 선택은 엔지니어링 결정 (engineering decision)이 되었습니다.

MCP와 재사용 가능한 스킬 (reusable skills) 또한 워크플로 (workflow)를 개선했습니다. MCP는 에이전트가 GitHub, Jira, Slack, 브라우저, 데이터베이스, 클라우드 도구와 같은 시스템과 상호작용할 수 있는 공통된 방법을 제공했습니다. 스킬은 특정 작업과 도구에 대한 재사용 가능한 지침을 제공했습니다. 이 두 번째 부분이 들리는 것보다 더 중요합니다. 스킬이 없다면 모델은 프로세스를 수행하는 방법을 종종 추측해야 합니다. 좋은 스킬이 있다면, 모델은 절차, 제약 조건, 예시, 그리고 성공의 정의를 전달받습니다. 동일한 워크플로를 반복해서 즉흥적으로 수행하는 대신, 에이전트는 검증된 운영 패턴 (operating pattern)을 따를 수 있습니다. 이것이 저에게 에이전트 팀 (team of agents)이라는 개념이 현실적으로 다가온 지점입니다. 더 강력한 브레인 모델 (brain model)은 계획하고 검토할 수 있습니다. 더 빠른 핸즈 모델 (hands model)은 집중적인 작업을 구현할 수 있습니다. 테스트, 보안 점검, 그리고 인간의 승인이 시스템을 통제된 상태로 유지할 수 있습니다.

Computer use(컴퓨터 사용) 기능은 마지막 주요 격차를 메웠습니다. 모든 실제 워크플로(workflow)가 API, CLI, SDK 또는 MCP 통합을 지원하는 것은 아닙니다. 때로는 브라우저에서 작업이 이루어지기도 합니다. 때로는 클라우드 대시보드, Google Play Console, Apple App Store Connect, 설정 화면, 또는 오직 인간만을 위해 구축된 양식(form)에서 작업이 발생합니다. Computer-use 기능은 그 경계를 변화시켰습니다. 에이전트가 화면을 검사하고, 웹사이트를 탐색하며, 양식을 채우고, 시각적 상태를 비교하고, 인터페이스를 테스트하며, 엔드 투 엔드(end-to-end) 워크플로를 수행할 수 있게 된 것입니다. 이로 인해 "개발자 어시스턴트(developer assistant)"라는 문구는 너무 작게 느껴졌습니다. 이제 에이전트는 코드, 터미널, 브라우저, 문서, 인프라 및 배포 도구 전반에 걸쳐 작동할 수 있습니다. 그것은 디지털 동료(digital coworker)가 되어가고 있었습니다.

모바일 앱 실험이 이를 현실로 만들었습니다. 제가 가장 좋아했던 테스트는 크로스 플랫폼(cross-platform) 모바일 애플리케이션을 구축하는 것이었습니다. 저는 모바일 개발자가 아닙니다. 모바일 플랫폼을 위해 진지하게 개발해 본 적이 없으며, 앱 스토어 출시(app-store publication)에 대한 깊은 경험도 없었습니다. 그 점이 오히려 유용한 실험이 되었습니다. 저는 에이전트들에게 목표를 부여했습니다: 익숙하지 않은 스택(stack)으로 앱을 구축하고, 출시를 준비하며, 출시 과정을 진행할 수 있도록 돕는 것입니다. 그들은 제가 기대했던 것보다 훨씬 더 많은 일을 처리했습니다. 그들은 프로젝트 구조를 잡고, 애플리케이션을 생성하며, 빌드(build)를 준비하고, 스토어 요구 사항을 처리하며, 에셋(asset)과 메타데이터(metadata)를 생성하고, 브라우저 흐름을 탐색하며, 진행 과정에서의 문제들을 해결하는 것을 도왔습니다. 여전히 감독은 필요했습니다. 저는 필요할 때 제품 결정과 계정 정보를 제공했습니다. 결과물을 검토하고 중요한 작업을 승인했습니다. 하지만 시작하기 전에 모든 세부 사항을 배우느라 몇 달을 보낼 필요는 없었습니다. 아이디어에서 공개 가능 상태가 되기까지 약 일주일이 걸렸습니다. 그것이 저의 개인적인 "와우(wow)" 모먼트였습니다. 병목 현상은 더 이상 "내가 이 전체 스택을 먼저 배울 수 있는가?"가 아니었습니다. 새로운 질문은 "내가 목표를 명확하게 설명하고, 좋은 결정을 내리며, 책임감 있게 결과를 검토할 수 있는가?"였습니다.

가장 중요한 변화는 개인적인 부분이었습니다. 올해 저는 아기를 돌보고 가족과 많은 시간을 보내기도 했습니다.

그것은 업무가 하루 일과에 어떻게 녹아드는지를 변화시킵니다. 전통적인 개발은 종종 컴퓨터 앞에서 방해받지 않는 긴 세션에 의존합니다. 가족 생활에 집중해야 할 때는 그러한 세션을 확보하기가 어렵습니다. 이제 저의 워크플로 (workflow)는 달라졌습니다. 때로는 아기에게 수유하기 전후로 밤에 에이전트 (agent)에게 작업을 할당합니다. 때로는 아침의 짧은 시간 동안 진행 상황을 검토합니다. 때로는 휴대폰으로 작업을 재지시하고 나중에 돌아와 테스트하거나 승인합니다. 제가 가족과 시간을 보내는 동안에도 에이전트들은 계속해서 작업을 수행할 수 있습니다. 이는 단순한 생산성 향상 그 이상입니다. AI는 저에게 개발 속도만 높여준 것이 아닙니다. 실제 삶의 흐름에 맞춰 개발을 더 유연하게 만들어 주었습니다. 그것이 아마도 가장 의미 있는 혜택일 것입니다.

이제 한 사람이 전체 제품 사이클 (product cycle)을 아우르며 작업할 수 있습니다. 지난 1년 동안 AI는 고립된 코딩 작업을 돕는 수준에서 거의 전체 제품 사이클을 지원하는 단계로 이동했습니다: 제품 기획 (Product planning) -> 아키텍처 (Architecture) -> 프론트엔드 및 백엔드 개발 (Frontend and backend development) -> 인프라 및 CI/CD (Infrastructure and CI/CD) -> 배포 (Deployment) -> 테스트 및 디버깅 (Testing and debugging) -> 보안 검토 (Security review) -> 시각적 및 엔드 투 엔드 테스트 (Visual and end-to-end testing) -> 문서화 (Documentation) -> GitHub 이슈 및 풀 리퀘스트 (GitHub issues and pull requests) -> 브라우저 워크플로 (Browser workflows) -> 스토어 게시 (Store publication) -> 운영 수정 (Operational fixes). 이것이 인간의 중요성을 낮추는 것은 아닙니다. 오히려 인간의 판단력을 더 중요하게 만듭니다. 여전히 누군가는 고객을 이해하고, 제품을 정의하며, 제약 조건을 설정하고, 잘못된 결정을 포착하며, 보안 리스크를 검토하고, 무엇이 '좋은 결과물'인지 결정해야 합니다. 역할은 모든 줄을 직접 타이핑하는 것에서 작업을 지시하고 검증하는 것으로 변합니다. 당신은 에이전트 팀의 제품 소유자 (product owner), 아키텍트 (architect), 검토자 (reviewer), 테스터 (tester), 그리고 운영자 (operator)가 됩니다. 여전히 기술적 지식이 필요합니다. 여전히 안목 (taste)이 필요합니다. 여전히 모델이 틀렸을 때를 알아차릴 수 있어야 합니다. 하지만 이제 작업을 시작하기 전에 모든 기술 영역의 전문가가 되어야만 하는 것은 아닙니다.

에이전트가 강력해질수록 안전성이 더 중요해집니다. 더 유능한 에이전트는 더 많은 책임도 수반합니다. 초기 도구들은 종종 두 가지 좋지 않은 선택지만을 제공했습니다.

그들은 모든 작은 행동 전에 승인을 요청하거나, 아니면 거의 무엇이든 할 수 있는 광범위한 권한을 부여받았습니다. 더 나은 승인 시스템은 더 유용한 중간 지대를 만들어냅니다. 에이전트는 일상적인 파일 편집, 안전한 테스트 실행, 로그 검사 등을 독립적으로 수행할 수 있습니다. 또한 파괴적인 명령, 자격 증명 (credential) 접근, 운영 환경 (production) 변경, 또는 인간의 판단이 필요한 결정 전에는 동작을 멈출 수 있습니다. 그 구분이 중요합니다. 목표는 최대의 자율성 (autonomy)이 아닙니다. 목표는 명확한 경계 내에서의 유용한 자율성입니다. 에이전트가 더 많은 도구와 시스템에 접근하게 될수록, 세심한 권한 설정, 테스트, 감사 추적 (audit trails), 그리고 인간의 승인은 덜 중요한 것이 아니라 더욱 중요해집니다. 지금은 1인 창업자들에게 놀라운 시기입니다. AI는...