AI 보조 코딩이 소프트웨어 엔지니어링을 어떻게 바꿀 것인가: 불편한 진실

(newsletter.pragmaticengineer.com)

59P by xguru 5일전 | ★ favorite | 댓글 8개

GenAI(LLM)는 코드를 자동 생성하고 보조하는 기능으로 개발자들의 생산성을 높이고 있음
과거부터 “코딩이 필요 없는 툴”들이 있었지만, 결국 실제 소프트웨어 엔지니어링 과정에는 여전히 고유한 복잡도가 존재함
ChatGPT 출시 이후 AI 도구의 빠른 발전 속도가 눈에 띄지만, 모든 과정을 획기적으로 바꾸기보다는 주어진 문제에서 일부 단계를 크게 단축해 주는 역할을 하고 있음

개발자들의 실제 사용 방식이 두 갈래로 나뉨

부트스트래퍼(bootstrappers)
- Bolt, v0, Screenshot-to-code 같은 도구로 새 프로젝트나 MVP를 빠르게 구현
- 디자인(Figma 등) 혹은 러프 콘셉트에서부터 AI가 완전한 초기 코드베이스를 생성함
- 며칠에서 몇 시간 이내로 작동하는 프로토타입을 만듦
- 프로덕션 수준으로는 불완전해도, 아이디어 검증에 강점이 있음
- 빠른 검증과 반복을 중시함
이터레이터(iterators)
- Cursor, Cline, Copilot, WindSurf 등을 일상 개발 과정에서 활용함
- 코드 자동완성, 복잡한 리팩토링, 테스트∙문서 생성 등에 AI를 사용함
- 복잡한 테스트, 문서화, 리팩터링 등을 AI에 맡기되, 결과를 끊임없이 점검함
- ‘페어 프로그래머’처럼 문제 해결을 함께해주는 용도로 활용함
- 개발자가 AI 제안을 선택·수정·보완하는 과정을 반복해 최적의 코드로 발전시킴

70% 문제: “마지막 30%”의 어려움 - AI의 학습 곡선 역설

AI가 70% 정도까지는 빠르게 코드를 만들어주지만, 마지막 30%가 크게 발목을 잡는 현상
사소한 버그를 고치면 또 다른 부분이 망가지는 식의 악순환이 생김
특히 비전공자나 주니어는 AI가 제안하는 코드를 전부 수용하다가 문제를 연쇄적으로 유발하기 쉬움
- AI가 제안하는 수정사항이 왜 문제를 일으키는지 파악하기 어려워함
숙련된 시니어 개발자는 버그 원인을 빠르게 추론하고, 코드를 재구조화하며, 보안과 성능을 추가로 고려해 AI가 놓친 부분을 보완함
- AI를 적극 활용하면서도 끊임없이 리뷰하고 리팩토링해 “유지보수 가능한 코드”로 만들어냄
주니어/비개발자가 AI가 생성한 코드를 무심코 받아들이면, 실제 운영 환경에서 쉽게 무너지는 “하우스오브카드 코드”가 생길 위험이 있음
지식 역설
- 시니어는 이미 아는 문제를 AI와 함께 빠르게 구현할 수 있음
- 주니어는 AI를 통해 배워야 하지만, 기초 지식이 부족하면 디버깅과 검증 과정에서 큰 어려움을 겪음

효과적인 사용 패턴

AI 초안 후 세분화
- AI가 초기 구현을 해주면, 이를 사람이 직접 검토∙리팩토링∙테스트함
- 에러 처리와 예외 케이스를 수동으로 추가하고 자동화된 테스트와 리뷰 과정을 강화해 신뢰도를 높임
- 모듈성, 에러 처리, 타입 정의, 아키텍처 설계를 강화해 유지보수가 가능하도록 만듦
작업 단위별 대화 유지
- 한 번에 큰 맥락을 넘기기보다, 작은 문제마다 독립된 프롬프트를 사용해 집중적인 답변을 얻음
- 변경 사항을 자주 리뷰하고 커밋하며, 피드백을 짧은 주기로 반영함
“신뢰하되 검증”하는 접근
- AI가 초안을 만들되, 중요한 로직과 에러 처리, 보안 이슈 등은 사람이 직접 챙김
- 항상 테스트 케이스를 작성하고, 성능·보안·구조적 타당성 등을 꼼꼼히 점검함

개발자에게 주는 시사점

작게 시작
- 잘 정의된 작은 작업, 명확한 범위의 문제부터 AI를 활용해 보고, 생성된 코드를 꼼꼼히 검토함
- 규모가 큰 기능으로 넘어가기 전에 테스트와 문서화를 철저히 챙김. 그리고 단계적으로 범위를 확장함
모듈화 유지
- 코드 베이스를 적절히 분리해 AI가 만들어낸 코드가 구조적으로 혼재되지 않도록 함
- 파일과 기능을 작은 단위로 분리하고 인터페이스와 의존성 흐름을 명확히 정의함
경험에 대한 신뢰
- AI를 조력자로 활용하되, 최종 판단은 자신의 경험을 기준으로 삼음
- 수상쩍은 코드나 설계는 의심하고, 엔지니어링 표준을 지키는 편이 좋음

에이전트형(agentic) 소프트웨어 엔지니어링의 부상

기존에는 AI 도구가 명령에 대응해 코드를 생성하는 수준이었다면, 앞으로는 에이전트(Agentic) 개념으로 진화
- 에이전트형 AI는 스스로 목표를 계획·실행·검증하며, 더 자율적으로 작동함
Claude(Anthropic), Cline 등은 단순 자동완성 이상의 수준으로, 브라우저를 자동으로 띄우고 테스트를 수행함
디버깅 과정도 달라짐
- 에이전트가 알아서 잠재적 이슈를 찾고, 테스트 세트를 실행하며, UI 상태까지 점검해 수정안을 제안할 수 있음
미래 도구들은 코드만 다루지 않음
- UI 스크린샷, 다이어그램, 음성 대화 등 여러 입력 채널을 이해하고 통합할 수 있음
이 흐름 속에서 개발자가 해야 할 일
- AI가 창의적으로 작업을 진행하되, 인간의 가이드를 받고 건전한 아키텍처 안에서 작동하도록 유지함
- 인간과 AI 간 강력한 피드백 루프를 구축함
인간은 큰 틀과 목표를 설정하고, 에이전트는 세부 작업을 처리하는 협업 모델이 생길 것으로 예상됨
“가장 중요한 프로그래밍 언어는 영어”라는 말처럼, 명확하고 정확한 자연어로 요구사항을 표현하는 역량이 중요해짐

소프트웨어 장인 정신이 돌아올까?

AI 덕분에 프로토타입과 데모는 빨리 만들어질 수 있음
그러나 실제 사용자들이 다양한 환경과 엣지 케이스로 소프트웨어를 다루기 시작하면 문제가 발생함
- 사용자에게 이해 불가능한 에러 메시지
- 충돌을 유발하는 특수 환경(엣지 케이스)
- 접근성(Accessibility)을 전혀 고려하지 않은 설계
- 느린 기기에서 발생하는 성능 이슈
- UI/UX 등의 디테일이 품질을 좌우함
소비자 관점에서 “폴리시”가 잘 된 제품이 되려면, 세밀함과 인간적인 배려가 필요함
AI가 반복 작업을 줄여주면, 개발자는 이러한 세부적인 완성도에 집중할 수 있게 됨
- 사용자 경험, 엣지 케이스, 의미 있는 에러 처리 등 인간적이면서도 전문적인 영역에 시간을 더 쏟을 수 있음

추가적인 생각

소프트웨어 엔지니어링 과정은 기획, 설계, 구현, 검증, 모니터링, 유지보수 등 다양한 영역이 있는데, 현재 AI는 주로 “코드 작성” 영역을 크게 효율화함
과거에도 COBOL, Visual Basic, No-code 플랫폼 등으로 “비개발자도 쉽게 소프트웨어를 만든다”는 시도가 이어졌지만, 복잡도가 커지면 결국 숙련된 개발자가 필요했음
LLM 도구가 코드량을 폭발적으로 늘려줄수록, 복잡한 프로젝트에서는 더 많은 시니어 엔지니어가 필요해질 전망임
AI 사용 능력을 갖춘 숙련 개발자는 본인의 가치를 더욱 높일 수 있음
결론적으로 AI 도구는 개발자를 완전히 대체하기보다는, 인사이트와 경험을 가진 개발자를 더욱 강력하게 만드는 방향으로 진화할 것으로 보임

추가적인 생각 (Gergely의 코멘트 포함)

소프트웨어 엔지니어링에서 코딩 자체가 차지하는 비중은 과거부터 그렇게 크지 않았음
과거 프레드 브룩스의 경우, 소프트웨어 작업 시간을 대략
- ⅓ 기획
- ⅙ 코딩
- ¼ 컴포넌트∙시스템 테스트
- ¼ 시스템 테스트 (모든 컴포넌트를 손으로)
  로 분류했음
현재 시각에서는 코딩(테스트 포함) 시간이 늘어났으나, 계획, 코드 리뷰, 모니터링, 롤아웃 등이 여전히 중요한 몫을 차지함
- 20% 기획
- 40% 코딩 (코드 + 테스트)
- 20% 코드 리뷰(다른 사람의 코드)
- 20% 프로덕션 준비 + 롤아웃 + 이 기간중 작은 수정 + 모니터링 + 알림
소프트웨어를 잘 만드는 과정
- 1. What: 무엇을 만들지 결정
  - 브레인스토밍, 디자인, 사용자 테스트, 제품 매니저∙비즈니스 이해관계자와 협업 등을 포함함
  - 스타트업의 경우 이 단계가 매우 짧을 수 있음(“만들어보고 반응을 보자” 식)
  - 이미 자리를 잡은 회사라면 기존 고객이 혼란스러워하지 않도록, 무엇을 만들지 결정하는 데 더 많은 시간이 걸릴 수 있음
- 2. How: 어떻게 만들지 계획
  - 제품/기능/서비스를 어떻게 구현할지 구체적으로 설계함
  - 아키텍처 영향, 의존성, 테스트 전략 등을 고민함
  - 스타트업은 이 과정을 생략하고 바로 실행에 들어갈 수 있지만, 큰 조직에서는 사전 설계를 무시하면 후에 문제가 커질 수 있음
  - 대다수 팀은 Design doc, RFC, ADR 등을 활용해 어느 정도 계획 과정을 거침
- 3. Build: 실제로 기능 구현
  - 원하는 기능∙제품을 코드로 작성하고 정상 동작을 확인함
- 4. Verify: 검증
  - 프로덕션에 배포하기 전, 예상대로 동작하는지 꼼꼼히 확인함
  - 특히 금융 서비스처럼 오작동이 치명적 결과를 초래할 수 있는 경우 QA 과정을 철저히 거침
- 5. Ship it: 배포
  - 변경사항을 머지하고 고객에게 릴리스함
  - 프로덕션에 배포하는 방식은 다양함
- 6. Monitoring and oncall: 모니터링 및 온콜
  - 제품에 문제가 발생하면 즉시 감지해 해결함
  - 동일한 장애가 재발하지 않도록 사후 조치도 함께 진행함
- 7. Maintain: 유지보수
  - 사용자 불만∙피드백을 수집하고 어떤 버그를 수정할지, 어떤 기능 개선을 우선순위로 둘지 결정함
  - 무시해도 되는 피드백을 걸러내는 과정도 포함함
- 8. Migrate: 마이그레이션
  - 제품 자체가 크게 달라지거나 기술 스택이 바뀔 때 대규모 마이그레이션이 필요해질 수 있음
- AI 도구는 현재 “Build” 단계에 큰 도움을 주지만, 위에 언급된 나머지 7가지 부분에서도 얼마나 유용할지 고민해볼 필요가 있음
1960년대 이후로 “비개발자도 개발자 없이 소프트웨어를 만들 수 있는 꿈”이 이어져 왔음
- COBOL, Visual Basic, No-code 등이 그 예임
- 간단한 웹사이트 정도는 아예 코딩 없이도 만들 수 있지만, 복잡한 제품에서는 엔지니어링 작업이 여전히 필요함
표현력이 높아질수록, 구체적으로 “어떻게 동작해야 하는지”를 AI에 세세히 지시해야 해 복잡성이 증가함
AI가 코드를 많이 만들어줄수록, 이를 유지보수하고 아키텍처를 다루는 전문 엔지니어의 필요성은 오히려 커질 가능성이 높음
오늘날 LLM을 활용해 작업하는 법을 익힌 시니어 개발자일수록 생산성이 높아지고, 기업에서 더 큰 가치를 발휘할 수 있음

AI 에이전트: 주요한 약속이지만 2025년에는 '미지의 영역'이기도

LLM 출시 후 2년이 지난 시점, 많은 개발자들이 LLM을 코딩∙소프트웨어 엔지니어링에 활용하는 법을 익혀옴
시제품 제작, 낯선 언어로의 전환, 결과물 정확성을 검증하고 잘못된 답변(환각)을 잡아내는 등의 작업에서 LLM이 크게 기여함
그러나 AI 에이전트는 아직 초기 단계임
- 현재 일반적으로 사용할 수 있는 에이전트는 Devin 정도이며, 월 500달러로 비용이 높고 평가도 엇갈림
벤처 자금이 몰리면서 더 많은 AI 코딩 에이전트 툴이 등장할 것으로 예상됨
- 가격도 점차 낮아질 가능성이 높음
- GitHub Copilot은 2025년에 에이전트 기반인 Copilot Workspace를 일반에 제공할 것으로 보임
- Stripe 전 CTO가 설립한 /dev/agents 등도 출시될 예정임
AI 에이전트는 더 느린 응답(“생각” 프로세스)과 높은 비용을 감수하고 정확도 향상을 추구함
- 실제로 이 방식이 얼마나 정확도를 높이고, 어떤 엔지니어링 사례에 큰 생산성 향상을 가져올지 아직 미지수임

숙련된 소프트웨어 엔지니어에 대한 수요 증가 가능성

숙련된(시니어 이상) 소프트웨어 엔지니어가 지금보다 더 필요해질 수 있음
- 이들은 AI 툴을 더 효과적으로 다룰 수 있으며, “뛰어난 결과물”이 어떤 모습인지 알고 정확하게 “명령”할 수 있음
- 잘못된 코드 생성이 감지되면 생성 과정을 멈추고 직접 소스 코드를 고치는 지점을 판단할 수 있음
AI 툴의 도움으로 훨씬 더 많은 코드가 작성되고, 더욱 많은 개인∙기업이 자체 솔루션을 만들 것으로 보임
- 하지만 복잡성이 커질수록, 이를 제어할 수 있는 숙련된 엔지니어가 필요해질 것임
- 기존 기술 기업들도 AI로 인해 늘어나는 복잡성을 다룰 인력이 필요해질 가능성이 큼
소프트웨어 엔지니어가 AI와 함께 일하는 능력을 키우면 더 생산적이며 더 가치 있는 엔지니어가 될 수 있음
- 툴을 완전히 “길들이는” 법을 익히기까지 시간이 걸리므로, 빠르게 변하는 도구 환경 속에서 적극적으로 실험하고 학습해보는 것이 중요함