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

• 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와 함께 일하는 능력을 키우면 더 생산적이며 더 가치 있는 엔지니어가 될 수 있음
  • 툴을 완전히 “길들이는” 법을 익히기까지 시간이 걸리므로, 빠르게 변하는 도구 환경 속에서 적극적으로 실험하고 학습해보는 것이 중요함