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

> Clean Markdown view of GeekNews topic #18712. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18712](https://news.hada.io/topic?id=18712)
- GeekNews Markdown: [https://news.hada.io/topic/18712.md](https://news.hada.io/topic/18712.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-01-13T10:44:02+09:00
- Updated: 2025-01-13T10:44:02+09:00
- Original source: [newsletter.pragmaticengineer.com](https://newsletter.pragmaticengineer.com/p/how-ai-will-change-software-engineering)
- Points: 76
- Comments: 11

## Summary

GenAI(LLM)은 코드를 자동 생성하여 개발자들의 생산성을 높이지만, 소프트웨어 엔지니어링의 복잡성을 완전히 해결하지는 못합니다. AI가 70% 정도까지는 빠르게 코드를 만들어주지만, 마지막 30%의 문제 해결에는 여전히 숙련된 개발자의 개입이 필요하며, 특히 주니어 개발자들은 AI가 제안하는 코드를 무분별하게 수용할 경우 문제를 일으킬 수 있습니다. AI 도구는 개발자를 대체하기보다는 그들의 인사이트와 경험을 보완하여 더욱 강력한 개발자가 되게 해줍니다.

## Topic Body

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

## Comments



### Comment 33639

- Author: logone72
- Created: 2025-01-20T15:44:32+09:00
- Points: 1

정말 좋은 내용의 글이네요.

### Comment 33636

- Author: youngmuk
- Created: 2025-01-20T13:48:58+09:00
- Points: 1

마지막 단락인 "숙련된 소프트웨어 엔지니어에 대한 수요 증가 가능성" 에 많이 공감합니다. 아는 만큼 잘 쓴다라는 것이겠죠? ^^

### Comment 33612

- Author: wkang586
- Created: 2025-01-20T10:08:00+09:00
- Points: 2

Expo 52 처럼, 최근에 큰 변화가 발생한 영역에서는 똑똑한 Claude 도 도움이 안되더군요.  
낡고 사라진 코드를 자꾸 제안해와서 오히려 방해만 되었던 경험이 있네요.  
역시 AI 는 '보는 눈' 이 훈련되어 있어야 제대로 쓸 수 있는 것 같습니다.

### Comment 33353

- Author: scari
- Created: 2025-01-13T14:16:25+09:00
- Points: 1

사소한 얘기지만 /dev/agents 는 코딩 에이전트가 아닌 것으로 알고 있습니다. 아직 출시 전이지만 스스로를 "AI 에이전트를 위한 OS" 라고 얘기하고 있네요.

### Comment 33347

- Author: ethanhur
- Created: 2025-01-13T11:46:38+09:00
- Points: 1

저는 개인적으로 미래(혹은 View에 따라 중기적으로)에는 모든 엔지니어의 역할에 코더 역할이 축소되고 TPM 역할이 확대될 거라고 생각하고 베팅하고 있습니다.  
  
코드는 Cursor가 더 잘 짜니 위임을 하고 사람은 그 위의 추상화된 레이어에서 대부분의 업무를 하지 않을까 싶습니다.

### Comment 33346

- Author: spilist2
- Created: 2025-01-13T11:13:12+09:00
- Points: 1

공유 감사합니다. 저도 관련된 글을 최근 하나 썼는데 비슷한 면이 있네요. https://www.stdy.blog/can-junior-beat-coding-agent/

### Comment 33343

- Author: bemong1
- Created: 2025-01-13T10:59:00+09:00
- Points: 8

요약 : AI로 인한 개발자의 미래 (희망편)

### Comment 33395

- Author: cwforum0340
- Created: 2025-01-14T04:45:41+09:00
- Points: 4
- Parent comment: 33343
- Depth: 1

?? : 이제 개발자 필요없내 (좆소편)

### Comment 33554

- Author: tsboard
- Created: 2025-01-17T20:31:10+09:00
- Points: 1
- Parent comment: 33395
- Depth: 2

세상에 ㅎㅎㅎㅎㅎ

### Comment 33389

- Author: kaykim
- Created: 2025-01-14T00:06:40+09:00
- Points: 1
- Parent comment: 33343
- Depth: 1

1+ ㅋㅋㅋ

### Comment 33350

- Author: roxie
- Created: 2025-01-13T12:58:27+09:00
- Points: 2
- Parent comment: 33343
- Depth: 1

ㅋㅋ 100점
