지난 몇 년 동안 AI 지원 개발에 깊이 관여하면서 흥미로운 현상을 발견했습니다. 엔지니어들은 AI를 사용함으로써 생산성이 크게 향상되었다고 보고하지만, 우리가 매일 사용하는 실제 소프트웨어는 크게 나아지지 않는 것 같습니다. 무슨 일이 벌어지고 있는 걸까요?
그 이유를 알 것 같고, 그 답을 통해 우리가 직면해야 할 소프트웨어 개발에 대한 몇 가지 기본적인 사실이 드러납니다. 제가 발견한 사실을 공유하겠습니다.

개발자가 실제로 AI를 사용하는 방법
저는 팀이 AI로 개발하는 방식에서 두 가지 다른 패턴을 관찰했습니다. 우리는 이를 '가이드'와 '반복자'라고 부릅니다. 두 가지 모두 엔지니어(심지어 비기술적인 사용자)가 아이디어에서 실행(또는 MVP)까지의 간극을 메우는 데 도움이 됩니다.

퍼실리테이터: 제로에서 MVP까지
Bolt, v0, 스크린샷 투 코드 AI와 같은 도구는 새로운 프로젝트를 부트스트랩하는 방식을 혁신적으로 바꾸고 있습니다. 이런 팀들은 보통
- 디자인이나 대략적인 콘셉트로 시작하기
- AI를 사용하여 완전한 초기 코드 베이스 생성하기
- 몇 주가 아닌 몇 시간 또는 며칠 만에 작동하는 프로토타입을 만들어 보세요!
- 신속한 검증 및 반복에 집중
그 결과는 인상적일 수 있습니다. 최근에 한 인디 개발자가 볼트 Figma 디자인을 단기간에 작동하는 웹 애플리케이션으로 전환했습니다. 아직 제작할 준비가 되지 않았지만 초기 사용자 피드백을 받기에 충분합니다.
이터레이터: 일일 개발
두 번째 캠프는 커서, 클라인, 코파일럿 및 윈드서핑 이와 같은 도구를 일상적인 개발 워크플로에 사용할 수 있습니다. 드라마틱하지는 않지만 잠재적으로 더 큰 변화를 가져올 수 있습니다. 이런 개발자들이 있습니다:
- 코드 완성 및 제안을 위한 AI 사용
- 복잡한 재구성 작업에 AI 활용하기
- 테스트 및 문서 생성
- AI를 '페어 프로그래머'로 사용하여 문제 해결
두 가지 접근 방식 모두 개발 속도를 크게 높일 수 있지만, 당장 눈에 보이지 않는 숨겨진 비용이 발생한다는 점이 문제입니다.
'AI 속도'의 숨겨진 비용
선임 엔지니어가 커서 어쩌면 부조종사 이러한 AI 도구는 마법처럼 보입니다. 테스트와 문서화를 포함하여 전체 기능을 몇 분 안에 구축할 수 있습니다. 하지만 자세히 살펴보면 중요한 사실을 발견할 수 있습니다. AI의 조언만 받아들이지 않는다는 것입니다. 끊임없이 조언을 구합니다:
- 생성된 코드를 더 작고 집중된 모듈로 리팩토링하기
- AI 누락 에지 조건 처리 추가
- 유형 정의 및 인터페이스 개선
- 아키텍처 결정에 대한 질문
- 포괄적인 오류 처리 기능 추가
즉, 수년간 쌓아온 공학적 지혜를 적용하여 AI의 결과물을 형성하고 제한하고 있습니다. AI는 구현을 가속화하고 있지만, 코드를 유지 관리할 수 있는 것은 전문 지식입니다.
주니어 엔지니어는 이러한 중요한 단계를 놓치는 경우가 많습니다. 그들은 AI의 결과물을 받아들일 가능성이 더 높기 때문에 제가 '카드의 집 코드'라고 부르는, 완벽해 보이지만 실제 스트레스를 받으면 무너지는 코드가 만들어질 수 있습니다.
지적 역설
제가 발견한 가장 반직관적인 사실은 AI 도구가 초보자보다 숙련된 개발자에게 더 도움이 된다는 것입니다. AI가 코딩을 민주화해야 하지 않을까요?
현실에서 AI는 팀에 매우 열성적인 주니어 개발자가 있는 것과 같습니다. 그들은 코드를 빠르게 작성할 수 있지만 지속적인 감독과 수정이 필요합니다. 더 많이 알수록 더 잘 멘토링할 수 있습니다.
이것은 제가 '지식의 역설'이라고 부르는 것을 만들어냅니다:
- 시니어는 AI를 사용하여 이미 알고 있는 업무의 속도를 높입니다.
- AI를 사용하여 업무 학습을 시도하는 주니어 직원
- 결과는 매우 달랐습니다.
저는 시니어 엔지니어들이 AI를 사용하는 것을 봅니다:
- 이미 이해한 아이디어를 빠르게 프로토타입으로 제작하기
- 나중에 개선할 수 있는 기본 구현을 생성합니다.
- 알려진 문제에 대한 대안 탐색
- 일상적인 코딩 작업 자동화
동시에 주니어 직원도 종종 있습니다:
- 부정확하거나 오래된 솔루션의 수용
- 주요 보안 및 성능 고려 사항 누락
- AI 생성 코드를 디버깅하기 어려운 경우
- 완전히 이해하지 못하는 취약한 시스템 구축
70% 문제: AI의 학습 곡선 역설
최근 제 관심을 끌었던 한 트윗은 제가 현장에서 관찰한 바를 완벽하게 포착하고 있습니다. 엔지니어가 아닌 사람이 AI로 코딩하는 경우 좌절스러운 장애물에 부딪히게 된다는 것입니다. 그들은 놀라운 속도로 70%를 완료할 수 있지만, 결국 30%는 수익률이 떨어지는 연습이 됩니다.

이 "70% 질문"은 AI 지원 개발의 현재 상태에 대한 몇 가지 핵심 정보를 보여줍니다. 처음에는 원하는 것을 설명하면 v0 또는 Bolt와 같은 AI 도구가 인상적인 프로토타입을 생성하는 등 진행 상황이 놀랍게 느껴졌습니다. 하지만 현실이 닥쳤습니다.
2단계 뒤로 모드
일반적으로 예측 가능한 패턴이 다음에 발생합니다:
- 작은 버그를 수정하려고 했습니다.
- AI가 합리적으로 보이는 변경 사항을 제안했습니다.
- 이 수정으로 인해 다른 문제가 발생했습니다.
- AI에게 새로운 문제를 해결해 달라고 요청했습니다.
- 이는 다시 두 가지 질문을 제기합니다.
- 반복해서
이 주기는 비엔지니어에게 특히 고통스러운데, 실제로 무엇이 잘못되었는지 이해할 수 있는 정신적 모델이 부족하기 때문입니다. 숙련된 개발자는 오류가 발생하면 수년간의 패턴 인식을 바탕으로 잠재적인 원인과 해결책을 유추할 수 있습니다. 이러한 배경 지식이 없으면 완전히 이해하지 못하는 코드를 가지고 두더지 잡기 게임을 하는 것과 같습니다.
학습 역설의 지속
여기에는 더 심각한 문제가 있습니다. 비엔지니어도 쉽게 사용할 수 있는 AI 코딩 도구, 즉 복잡성을 다루는 능력이 오히려 학습을 방해할 수 있다는 점입니다. 코드가 '나타나는' 상황에서 기본 원리를 이해하지 못하면 학습에 방해가 될 수 있습니다:
- 디버깅 기술을 개발하는 것이 아닙니다.
- 기본 패턴 학습을 놓치고 있습니다.
- 아키텍처 결정을 추정할 수 없습니다.
- 코드를 유지 관리하고 개발하는 데 어려움이 있습니다.
이로 인해 문제를 해결하기 위해 스스로 전문성을 개발하기보다는 AI에 계속 의존해야 하는 종속성이 생깁니다.
지식 격차
제가 본 가장 성공적인 비엔지니어의 AI 코딩 도구 사용 사례는 하이브리드 접근 방식을 취했습니다:
- AI를 활용한 신속한 프로토타이핑
- 생성된 코드의 작동 방식을 이해하는 데 시간을 할애하세요.
- AI를 사용하면서 기본 프로그래밍 개념 배우기
- 단계별 지식창고 구축
- 단순한 코드 생성기가 아닌 학습 도구로 AI 사용
하지만 많은 사람이 AI 도구를 사용하여 달성하고자 하는 목표와는 정반대로 인내와 헌신이 필요합니다.
미래에 대한 시사점
'70% 문제'는 현재의 AI 코딩 도구가 그렇게 간주되는 것이 가장 좋다는 것을 시사합니다:
- 숙련된 개발자를 위한 프로토타입 액셀러레이터
- 개발을 이해하려는 사람들을 위한 학습 보조 도구
- 아이디어의 빠른 검증을 위한 MVP 생성기
하지만 아직 많은 사람이 기대하는 코딩 민주화의 해결책은 아닙니다. 마지막으로 30% - 소프트웨어를 프로덕션에 사용할 수 있고 유지 관리가 가능하며 견고하게 만드는 부분 - 는 여전히 실제 엔지니어링 지식이 필요합니다.
좋은 소식은? 도구가 개선되면 그 격차가 좁혀질 수 있습니다. 하지만 현재로서는 가장 실용적인 접근 방식은 학습을 완전히 대체하는 것이 아니라 학습을 가속화하는 데 AI를 사용하는 것입니다.
실제로 작동하는 모델: 실용적인 모델
수십 개의 팀을 관찰한 결과, 일관되게 효과가 있는 것은 다음과 같습니다:
1. 'AI 초안' 모델
- AI가 기본 구현을 생성하도록 합니다.
- 모듈화를 위한 수동 검토 및 리팩토링
- 포괄적인 오류 처리 기능 추가
- 포괄적인 테스트 작성
- 주요 의사 결정에 대한 문서화
2. '연속 대화' 모델
- 다양한 작업마다 새로운 AI 채팅을 시작하세요.
- 컨텍스트에 집중하고 최소화하기
- 잦은 검토 및 변경 사항 제출
- 긴밀한 피드백 루프 유지
3. '신뢰하되 검증' 모델
- AI를 사용한 초기 코드 생성
- 모든 중요 경로의 수동 검토
- 자동화된 에지 케이스 테스트
- 정기적인 보안 감사 실시
미래 전망: AI의 진정한 미래는 무엇인가요?
이러한 어려움에도 불구하고 저는 소프트웨어 개발에서 AI의 역할에 대해 낙관적으로 생각합니다. 핵심은 AI가 정말 잘하는 것이 무엇인지 이해하는 것입니다:
- 알려진 가속도
AI는 우리가 이미 이해하고 있는 패턴을 실현하는 데 능숙합니다. 마치 매우 빠르게 타이핑할 수 있는 인내심이 무한한 쌍둥이 프로그래머가 있는 것과 같습니다. - 가능성 살펴보기
AI는 아이디어를 빠르게 프로토타이핑하고 다양한 접근 방식을 탐색하는 데 유용합니다. 마치 개념을 빠르게 테스트할 수 있는 샌드박스가 있는 것과 같습니다. - 자동화 루틴
AI는 샘플과 일반 코딩 작업에 소요되는 시간을 크게 줄여주므로 흥미로운 문제에 집중할 수 있습니다.
어떤 의미인가요?
이제 막 AI 지원 개발을 시작하신다면 다음과 같은 권장 사항을 참고하세요:
- 소규모로 시작하기
- 격리되고 잘 정의된 작업에 AI 사용
- 생성된 코드의 각 줄을 검토하세요.
- 점진적으로 더 큰 기능 구축
- 모듈성 유지
- 모든 것을 작고 집중력 있는 문서로 나누기
- 컴포넌트 간 명확한 인터페이스 유지
- 모듈 경계 문서화
- 여러분의 경험을 믿으세요.
- 판단을 대체하는 것이 아니라 가속화하는 데 AI 사용
- 올바르지 않은 코드 생성에 대한 질문
- 엔지니어링 표준 유지
에이전트 소프트웨어 엔지니어링의 부상
2025년에 접어들면서 AI 지원 개발의 환경은 극적으로 변화하고 있습니다. 현재의 도구가 프로토타이핑과 반복 작업 방식을 변화시켰지만, 저는 에이전트 기반 소프트웨어 엔지니어링의 부상이라는 훨씬 더 중요한 변화의 정점에 있다고 생각합니다.

"에이전트"란 무엇을 의미하나요? 이러한 시스템은 단순히 프롬프트에 응답하는 것이 아니라 자율성을 높여 솔루션을 계획, 실행 및 반복합니다.
커서/클라인/v0/볼트에 대한 제 생각을 비롯하여 프록시에 대해 더 자세히 알고 싶으시다면 제 글을 참고하세요.
우리는 이미 이러한 변화의 초기 징후를 목격하고 있습니다:
응답자에서 공동 작업자로
현재 도구는 주로 명령을 기다립니다. 하지만 다음과 같은 업데이트된 기능을 살펴보세요. 인류학 존재 Claude (a) 컴퓨터에서 컴퓨터를 사용하거나 Cline 브라우저를 자동으로 실행하고 테스트를 실행하는 기능. 이는 단순히 미화된 자동 완성이 아니라 실제로 작업을 이해하고 주도적으로 문제를 해결하는 기능입니다.
디버깅에 대해 생각해 보세요. 이러한 에이전트는 단순히 수정 사항만 제안하는 것이 아닙니다:
- 잠재적 문제의 사전 식별
- 테스트 제품군 설정 및 실행하기
- UI 요소 검사 및 스크린샷 캡처하기
- 개선 제안 및 구현
- 솔루션이 작동하는지 확인합니다(큰 문제가 될 수 있음).
멀티모달의 미래
차세대 도구는 단순히 코드를 처리하는 데 그치지 않고 원활하게 통합될 수 있습니다:
- 시각적 이해(UI 스크린샷, 모델, 다이어그램)
- 구두 언어 대화
- 환경 상호 작용(브라우저, 터미널, API)
이러한 멀티모달 기능은 코드 수준뿐만 아니라 전반적으로 인간처럼 소프트웨어를 이해하고 사용할 수 있음을 의미합니다.
자율적이지만 가이드 제공
이러한 도구를 사용하면서 얻은 핵심 인사이트는 미래는 AI가 개발자를 대체하는 것이 아니라, AI가 인간의 지침과 전문성을 존중하면서 주도권을 잡을 수 있는 점점 더 유능한 협력자가 되는 것이라는 점입니다.

2025년에 가장 효과적인 팀은 학습하는 팀이 될 것입니다:
- AI 에이전트에 대한 명확한 경계 및 가이드라인 설정
- 상담원이 작업할 수 있는 강력한 아키텍처 패턴 구축
- 사람과 AI 기능 간에 효과적인 피드백 루프 만들기
- AI 자율성을 활용하면서 수동 감독 유지
영어 우선 개발 환경
안드레이 카파티가 지적했듯이
"영어가 가장 인기 있는 새로운 프로그래밍 언어가 되고 있습니다."
이는 우리가 개발 도구와 상호작용하는 방식에 근본적인 변화를 가져오고 있습니다. 자연어로 명확하게 사고하고 정확하게 소통하는 능력이 전통적인 코딩 기술만큼이나 중요해지고 있습니다.
에이전시 개발로의 전환은 우리의 기술 개발을 요구할 것입니다:
- 더 강력한 시스템 설계 및 아키텍처적 사고
- 요구 사항 사양 및 커뮤니케이션 개선
- 품질 보증 및 검증에 대한 집중도 향상
- 사람과 AI 기능 간의 협업 강화
엔지니어링으로서의 소프트웨어의 귀환?
AI 덕분에 소프트웨어를 빠르게 구축하는 것이 그 어느 때보다 쉬워졌지만, 진정으로 세련된 소비자 경험을 만드는 기술이라는 중요한 것을 잃을 위험이 있습니다.

품질 함정 시연
팀들이 AI를 사용하여 인상적인 데모를 빠르게 제작하는 것이 하나의 패턴이 되어가고 있습니다. 행복한 여정이 아름답게 진행되고 있습니다. 투자자와 소셜 네트워크에서도 극찬을 아끼지 않습니다. 하지만 실제 사용자가 클릭하기 시작하면 어떨까요? 그때부터 모든 것이 무너집니다.
저도 직접 눈으로 확인했습니다:
- 일반 사용자에게는 의미가 없는 오류 메시지
- 애플리케이션 충돌로 이어지는 엣지 케이스
- 정리되지 않은 지저분한 UI 상태
- 접근성 완전히 무시
- 느린 디바이스에서의 성능 문제
이는 단순한 P2 버그가 아니라 사람들이 용인하는 소프트웨어와 사람들이 좋아하는 소프트웨어의 차이입니다.
잃어버린 꾸밈의 예술
사용자가 지원팀에 문의할 필요가 없는 진정한 셀프 서비스 소프트웨어를 만들려면 다른 사고방식이 필요합니다:
- 잘못된 정보에 집착
- 느린 연결에서 테스트하기
- 모든 엣지 케이스를 우아하게 처리
- 검색 가능한 기능 만들기
- 기술 전문가가 아닌 실제 사용자를 대상으로 한 테스트
이러한 디테일에 대한 관심은 (아마도) 인공지능이 만들어낼 수 없는 것입니다. 공감과 경험, 기술에 대한 깊은 관심에서 비롯됩니다.
개인용 소프트웨어 르네상스
저는 개인 소프트웨어 개발의 르네상스를 보게 될 것이라고 믿습니다. 시장에 AI가 생성한 MVP가 넘쳐나면서 눈에 띄는 제품은 다음과 같은 개발자가 만든 제품이 될 것입니다.
- 장인 정신에 대한 자부심
- 작은 디테일에 대한 관심
- 완벽한 사용자 경험에 집중
- 엣지 케이스용으로 제작
- 진정한 셀프 서비스 경험 만들기
아이러니하게도 AI 도구가 오히려 이 르네상스에 기여하고 있는지도 모릅니다. 일상적인 코딩 작업을 처리함으로써 개발자는 가장 중요한 일, 즉 사용자에게 실제로 도움이 되고 즐거움을 주는 소프트웨어를 만드는 데 집중할 수 있습니다.
밑줄
소프트웨어 품질은 코딩 속도에 의해 크게 제한되지 않았기 때문에 AI가 소프트웨어를 더 좋게 만들지는 못합니다. 요구 사항 이해, 유지 관리 가능한 시스템 설계, 에지 케이스 처리, 보안 및 성능 보장 등 소프트웨어 개발의 어려운 부분은 여전히 사람의 판단을 필요로 합니다.
AI를 사용하면 더 빠르게 반복하고 실험할 수 있으며, 더 빠르게 탐색함으로써 더 나은 솔루션을 찾을 수 있습니다. 하지만 엔지니어링 규율을 유지하고 AI를 좋은 소프트웨어 관행을 대체하는 것이 아니라 도구로 사용할 경우에만 가능합니다. 기억하세요: 목표는 더 많은 코드를 더 빨리 작성하는 것이 아닙니다. 그보다는 더 나은 소프트웨어를 만드는 것이 목표입니다. 현명하게 사용하면 AI는 이를 달성하는 데 도움이 될 수 있습니다. 하지만 '더 나은'의 의미와 이를 달성하는 방법을 이해하는 것은 여전히 우리의 몫입니다.
AI 지원 개발에 대한 경험은 어떤가요? 댓글로 여러분의 이야기와 인사이트를 듣고 싶습니다.
© 저작권 정책
기사 저작권 AI 공유 서클 모두 무단 복제하지 마세요.
관련 문서
댓글 없음...