| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
- spring boot
- Baekjoon
- API
- 데이터베이스
- database
- JPA
- 자바
- 그리디알고리즘
- 코딩
- 코드
- 개발자
- 코딩테스트
- 백준
- 개발
- Spring
- 애자일프로그래밍
- 스프링
- 읽기쉬운코드
- Elasticsearch
- 엘라스틱서치
- 그리디
- 프레임워크
- 알고리즘
- ES
- kotlin
- framework
- cleancode
- 애자일기법
- 클린코드
- Java
- Today
- Total
튼튼발자 개발 성장기🏋️
개발자는 AI에게 대체될 것인가를 읽고 나서 본문
지난 번에 토스의 Node.js 개발자 정세훈님의 블로그 글을 읽으면서 여러가지 감정과 생각이 들었다. 일단 AI 버블에 대해서 공감이 많이 갔다. 업계에 떠도는 뉴스, 투자액 대비 실질 매출의 불균형, 95%에 달하는 AI 도입 실패율 이야기. 현업 개발자 입장에서 그런 숫자들이 체감되는 느낌이 들기도 했다.
AI의 버블과 현실
부풀려진 단기적 기대치, 그리고 실제 생산성 혹은 비즈니스 효과를 내기까지의 거대한 갭, 정말 실감난다. 첨단 기술 도입이 언제나 그래왔듯, 당장은 과장되고 혼란스럽지만 길게 보면 그 변화가 어디서 터질지 알 수 없는 것 같다. 특히 닷컴 버블 때 웹마스터가 사라진 대신 새로운 웹 직군이 폭증했던 사례는 나도 여러 기사와 도서에서 반복적으로 보던 이야기라 이 맥락이 참 인상 깊었다.
어쩌면 우리의 두려움은 "사라질 것인가"가 아니라 "어떻게 바뀔 것인가"에 더 가까운 것 같다. 결국 사람의 일을 기계가 빼앗는 것이 아니라, 직업의 본질 자체가 변하고 있다는 시각에 동의한다. AI 때문에 주니어 개발자 채용이 줄어들고, 견습 사다리(멘토링/러닝 커브 등) 자체가 엉켜버리는 부분은 새삼 무섭게 느껴진다.
AI에게 위임되는 일, 남는 일
이번 글에서 가장 인상깊고 가장 공감되는 부분이다. 업무 위임의 4분면 이야기가 굉장히 현실적이고, 실제로 요즘 프로젝트에서 잦게 느끼는 부분이다. 단순 반복/보일러플레이트 작업은 이미 여러 Copilot이나 LLM 기능으로 자동화가 가능하다. 하지만 아키텍처 결정이나 팀 문화 설계, 의사결정은 절대 AI에게 쥐어줄 수 없는 책임감과 맥락이 있다. 실제로 나도 코드 리뷰나 고도화된 리팩토링 작업에서 AI 제안을 참고는 해도 최종 결정은 '내가 책임진다'는 마인드가 강하다.
아니...AI가 작성한 코드 때문에 사이드 이펙트나 장애가 발생했을 때, "이거 제가 안했어요. AI가 했어요."할꺼 아니잖아...ㅋㅋ
특히 "위임하기 어려운 것"의 경계가 AI의 발전에 따라 계속 이동한다는 이야기, 그리고 그 과정에서 추상화된 업무, 도구의 신뢰성, 유지보수성이 중요한 이슈로 등장한다는 부분, 정말 공감이 갔다. 최근 프롬프트 엔지니어링이나 자동화 파이프라인 만들어봤던 경험이 있기 때문에, 모델 업그레이드 한방에 '이전의 노력이 헛수고'가 된다는 부분은 씁쓸하게 다가온다.
요즈음 어느 회사든 마찬가지일 것이다. 이 부분이 인상이 깊었던 이유는 비개발자 직군이 수시로 개발직군 영역을 침범해서다.
예를들어, 어떠한 이슈 혹은 기능 추가건이 있을 때, 개발 방향은 여러가지가 있을 것이고 최선의 방향으로 안전하고 빠르게 대응해야하는 상황에서 그것들은 온전히 개발자 몫이다. 개발자는 심도있게 고민하고 설계해서 개발, 검증, 코드리뷰를 거쳐야하기 때문에 시간이 걸릴 수 있다. 하지만 비개발자들은 대부분 왜 오래걸리는지 이해를 못한다. AI의 효율적인 활용 방법을 모른채, 단순 프롬프팅 만으로 "어떻게" 해결했는지, "왜" 이렇게 해결 했는지 모른채, 노트북을 들고 와서 "OO님 저 이거 5분만에 해결 했는데요?"라고 한다. 이 얼마나 매너없고 존중없는 업무침범인지 모르겠다.
물론 비개발자 직군도 이제 AI를 사용해서 얼마든지 개발을 간접적으로 할 수 있다. 내가 하고싶은 이야기는 AI가 해주는 개발을 100% 신뢰할 수 없다는 이야기이다. AI가 왜 이런 기술들을 사용했고, 이 기술을 어떻게 사용했는지 인지해야하고 더 좋은 방향은 어떤 것들이 있는지 시야를 넓히는 훈련도 필요하다고 생각한다. (물론 개발자도...)
AI와 추상화, 그리고 개발자의 역할
AI에게 일을 맡긴다는 게 결국 업무의 추상화라는 점, 그래서 추상화가 잘못되면 오히려 복잡성이 기하급수적으로 커진다는 얘기는 백엔드나 인프라 설계하면서 많이 느끼는 점이다. 프레임워크/라이브러리 한 번 잘못 쓰면, 장애가 터졌을 때 추상화 아래의 동작 구현부를 잘 몰라서 더 힘들어진 경험이 여러 번 있었다. 그래서 나 역시 시니어분들이 기본 레이어까지 계속 학습하려는 이유가 뭔지 조금이나마 이해하게 됐었던 것 같다. AI 도구도 마찬가지로, 내부가 대강 어떻게 돌아가는지, 언제 어떻게 실패할 수 있는지를 항상 고민하면서 사용해야겠다고 느꼈다.
AI 시대, 개발자에게 중요한 역량
- 위임의 경계 스스로 실험하기 – 반복적 작업을 AI에 과감히 맡겨보고, 효과와 리스크를 파악하는 경험이 점점 더 중요해지는 듯하다.
- 업무의 본질 쥐고 가기 – AI가 쉽게 대체하기 힘든 판단, 책임, 의사결정 지점을 꾸준히 키워나가야 살아남는 거라는 걸 다시 느꼈다.
- 추상화와 리팩토링 감각 – 도구 위에 도구, 서비스 위에 서비스가 쌓이면서 "언제, 어떻게 추상화의 레이어를 재정비"해야 할지 리더십이 점점 더 중요한 시대 같기도 하다.
궁금한 점
- AI를 이용해 "더 빠르게, 더 많이"만을 목표로 하는 접근은 오래 못 갈 것 같다는 점이 찔렸다. 실제로 내 일상에도 "자동화로 남는 시간엔 더 창작하라""는 압박이 있었는데, 앞으로는 오히려 AI를 좀 더 똑똑하게 활용하고, 시스템의 한계와 리스크까지 설계하는 데 집중해야겠다는 생각을 했다.
- 플랫폼이 AI 툴 사용을 너무 가이드하거나 경직되게 하면, 각자의 실험과 혁신이 막힌다는 지적도 현실적이라고 봤다. 그래서 각자의 맥락, 각자의 업무 경계에 맞도록 최대한 유연한 연결성과 안전망이 필요할 것 같다.
- 한 가지 궁금한 점은, 과연 AI 발전이 "자동화의 포화점"까지 가면 새로운 타입의 '개발자 견습', 즉 초보자가 성장하는 과정이 어떤 식으로 설계되어야 할지다. 주니어가 설 자리가 줄고 있다는 현실에서, 미래 인재 양성은 어떻게 해나가야 할지 여러모로 고민이 많아진다.
참고
- 정세훈, 개발자는 AI에게 대체될 것인가, 토스테크 블로그.
'기타 > 타사 기술 블로그 읽기' 카테고리의 다른 글
| T4 GPU 1장으로 일궈낸 올리브영의 Gemma 3 기반 sLLM 구축기를 읽고나서 (0) | 2026.01.26 |
|---|---|
| 배달대행사 API 연동과 장애 대응 - 오늘드림 서비스 개발기를 읽고나서 (0) | 2026.01.20 |
| 당근페이 백엔드 아키텍처가 걸어온 여정을 읽고 나서 (0) | 2026.01.19 |
| 수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기를 읽고 나서 (1) | 2026.01.12 |
| 요기요 채널링 서비스 런칭 회고를 읽고 나서 (1) | 2026.01.08 |