AI 시대, 개발자는 정말 사라지는가 — 현직 시니어의 냉정한 분석
지난주에 팀 회의에서 한 주니어 개발자가 조심스러운 표정으로 물었다. "시니어님, 혹시 제가 지금 배우는 게 2-3년 뒤엔 필요 없어지는 건 아닐까요?" 나는 한숨을 쉬었지만, 그의 질문이 정당하다는 건 안다. 지난 몇 개월간 인터넷은 비슷한 질문들로 가득 찼다. "개발자는 5년 안에 사라질 것이다", "AI가 모든 코드를 짤 수 있다", "프로그래밍의 미래는 끝났다".
나는 6개월간 거의 매일 GitHub Copilot, Cursor, Claude Code 등을 사용했다. 팀의 다른 개발자들도 마찬가지다. 우리가 경험한 것들은 정말로 인상적이지만, 동시에 현실과 기대의 차이도 명확했다. 이 글에서는 그 차이를 있는 그대로 말하려고 한다. 우리는 어떻게 일하는지, 무엇이 바뀌었는지, 그리고 가장 중요하게 무엇은 바뀌지 않았는지.
먼저 솔직한 고백부터 하자
나는 당신의 직업이 완전히 안전하다고 말할 생각이 없다. 왜냐하면 사실 아무도 모르기 때문이다. 하지만 동시에, "개발자가 사라진다"는 말도 거짓일 가능성이 높다는 것도 알고 있다.
역사를 보자. 1960년대 프로그래머들은 기계식 펀칭 카드를 직접 작성했다. 그 후 고급 언어(Fortran, COBOL)가 나왔다. 그러면 "프로그래머는 이제 필요 없을 것"이라고 했다. 하지만 프로그래머는 사라지지 않았고, 오히려 더 많이 필요해졌다. 왜? 코딩이 쉬워지자, 더 많은 문제들이 소프트웨어로 해결되기 시작했기 때문이다.
같은 패턴이 반복됐다. IDE가 나왔을 때도 "프로그래머는 필요 없을 것"이라고 했다. 프레임워크와 라이브러리가 나왔을 때도. 그 모든 것들은 개발자들의 생산성을 올렸지만, 개발자를 제거하지는 못했다. 오히려 개발자들이 더 높은 수준의 문제에 집중할 수 있도록 만들었다.
이번은 다를 수도 있다. 하지만 역사의 패턴을 본다면, 가능성은 낮다.
우리의 워크플로우는 어떻게 바뀌었는가
구체적으로, AI를 도입한 이후 우리의 개발 프로세스가 어떻게 바뀌었는지 설명하겠다.
이전: 전형적인 개발자의 하루
일년 전만 해도, 우리의 작업 흐름은 이랬다. 새로운 기능을 구현해야 한다고 하자.
- 요구사항을 이해한다. 보통 30분에서 1시간이 걸린다.
- 아키텍처를 설계한다. 기존 코드와의 호환성, 테스트 가능성, 유지보수성을 고려한다. 30분에서 2시간.
- 코드를 작성한다. 보통 이것이 전체 시간의 30~40%를 차지한다. 2~4시간.
- 단위 테스트를 작성한다. 시간이 걸리지만 필수다. 1~2시간.
- 코드 리뷰를 받는다. 피드백을 반영하고 수정한다. 1~3시간.
- 통합 테스트를 한다. 1시간.
전체적으로, 중간 복잡도의 기능은 8~12시간이 걸렸다.
지금: AI를 활용한 워크플로우
이제는 이렇다:
- 요구사항을 이해한다. 동일. 30분에서 1시간.
- 아키텍처를 설계한다. 동일. AI가 이 부분을 완전히 대체하지는 못한다. 30분에서 2시간.
- 코드의 골격을 AI에게 맡긴다. "이런 구조의 React 컴포넌트를 만들어달라"고 하면, AI는 기본 구조, Props 정의, 이벤트 핸들러, 스타일 설정을 모두 생성한다. 20분.
- AI가 생성한 코드를 내 요구사항에 맞게 수정한다. 기본 구조는 맞지만, 세부사항들은 조정이 필요하다. 30분에서 1시간.
- 테스트 코드를 작성한다. AI가 테스트 템플릿을 제시하지만, 나는 어떤 엣지 케이스를 테스트해야 하는지를 결정해야 한다. 45분에서 1.5시간.
- 코드 리뷰와 최적화. AI의 코드가 항상 최적인 것은 아니므로, 개선해야 한다. 30분에서 1시간.
- 통합 테스트. 동일. 1시간.
전체적으로, 같은 기능은 이제 4~7시간이 걸린다. 대략 40~50% 단축됐다.
그런데 여기서 주목해야 할 점이 있다. 코드를 더 빨리 작성했다고 해서, 우리의 생산성이 40~50% 올랐다는 뜻은 아니다.
왜 아닌가? 개발 시간의 축소는 좋지만, 문제 해결(troubleshooting), 버그 수정, 코드 리뷰의 질이 같은 시간에 유지되어야 하기 때문이다. 우리가 경험한 것은 오히려 이렇다: 코드 작성은 빨라졌지만, 디버깅과 최적화는 오히려 더 시간이 걸린다.
코드 작성은 빨라졌지만, 이해는 느려졌다
구체적인 예를 들자. 최근에 우리는 복잡한 상태 관리 로직이 필요했다. AI는 이에 대해 매우 합리적인 코드를 생성했다. Redux를 사용하거나, 또는 Context API를 사용하는 방식. 문법적으로 완벽했다.
하지만 코드 리뷰 과정에서, 우리는 이 구조가 특정 시나리오에서 문제를 일으킬 수 있다는 것을 발견했다. 사용자가 빠르게 여러 작업을 연속으로 할 때, 상태 업데이트의 순서가 중요했는데, AI가 생성한 코드는 이것을 보장하지 못했다.
그러면 AI의 코드를 수정해야 했다. 그런데 이 과정에서 시간이 더 들었다. 왜? AI가 생성한 코드의 의도를 완전히 이해하고, 그 안에서 어떤 부분을 수정할 수 있는지를 판단해야 했기 때문이다. 처음부터 직접 작성했다면, 우리가 알고 있는 문제들을 예방하면서 작성했을 것이다.
이것이 반복되면서, 우리는 깨달았다. AI는 "수용 가능한 코드"를 빠르게 생성한다. 하지만 "당신의 문제를 정확히 푸는 코드"를 생성하지는 못한다. 그 차이는 무엇인가?
- 컨텍스트의 부족: AI는 당신의 비즈니스 로직, 성능 요구사항, 미래의 확장성을 알 수 없다.
- 트레이드오프의 미해결: 모든 설계는 트레이드오프다. 간단함 vs 기능성, 속도 vs 정확도. AI는 이 중 어느 것을 우선해야 하는지를 모른다.
- 기술적 부채의 회피: 빠르게 작동하는 코드는 좋지만, 미래에 유지보수하기 쉬운 코드는 다르다. AI는 후자를 우선하기 않는다.
주니어 개발자와 시니어 개발자에게 미치는 영향의 차이
흥미로운 관찰이 하나 있다. AI가 팀의 모든 개발자에게 같은 정도의 이득을 주지는 않는다는 것이다.
주니어 개발자에게 미치는 영향
우리 팀의 2년차 개발자는 AI의 도움으로 생산성이 크게 올랐다. 그 이유는:
학습 곡선의 단축: 처음 접하는 기술 스택(Vue.js, TypeScript)에서, 주니어는 기본 패턴을 몰랐다. AI는 "Vue에서 전역 상태 관리를 하는 방법"을 물으면 여러 가지 방법을 제시한다. 이것이 교육적 가치가 있다.
반복적 작업의 제거: 주니어는 여전히 많은 시간을 "이 작업을 어떻게 하지?"라는 질문에 쓴다. AI는 빠르게 답변을 제시하므로, 이들은 더 핵심적인 로직 구현에 집중할 수 있다.
신뢰도 있는 출발점: AI가 생성한 기본 구조는 나쁘지 않으므로, 주니어는 여기서 시작해서 개선하는 방식으로 배울 수 있다. "왜 이렇게 했을까?"를 물으면서.
우리 팀에서는 주니어 개발자가 동일한 작업을 60~70% 시간에 완료하고 있다.
시니어 개발자에게 미치는 영향
반면, 나와 같은 경험이 많은 개발자에게는 이득이 상대적으로 작다. 이유:
이미 알고 있는 패턴들: 내가 필요로 하는 코드 구조들은 대부분 이미 머릿속에 있다. AI가 제시하는 것들은 종종 "맞지만 내가 원한 것이 아닌" 것들이다.
아키텍처 결정이 코드 작성 시간을 초과: 큰 시스템을 다룰 때, 코드를 작성하는 시간은 전체의 30~40%에 불과하다. 70%는 "어떻게 하면 이 문제를 가장 잘 풀 수 있을까?"를 고민하는 시간이다. AI는 이 부분을 도와주지 못한다.
코드 리뷰의 부담 증가: AI가 생성한 코드의 정확성을 확인해야 하는 책임이 늘었다. 처음부터 내가 작성한 코드보다, 더 신중하게 봐야 한다.
우리 팀에서 시니어 개발자들의 생산성 증대는 약 15~20% 정도였다. 주니어보다 훨씬 작다.
이것이 의미하는 것
만약 우리가 이 추세를 외삽한다면, 어떤 결론에 도달할까? AI는 주니어 개발자들의 일을 더 빠르게 하고, 학습을 가속화한다. 하지만 복잡한 시스템 설계, 아키텍처 결정, 기술적 리더십—이런 일들은 여전히 경험이 많은 개발자가 필요하다.
따라서 결론은 이렇다. AI 시대에 "개발자"가 사라지는 게 아니라, "특정 유형의 개발자"의 역할이 바뀐다는 것이다.
실무에서 본 실제 변화들
추상적인 논의를 벗어나, 우리가 직접 경험한 구체적인 변화들을 나열해보자.
코드 리뷰의 새로운 도전
과거에는 코드 리뷰의 주된 목적이 "코딩 스타일, 명명 규칙, 기본적인 오류 확인"이었다. 이런 것들은 자동화되고, 많은 부분이 린터와 포매터가 담당했다.
하지만 이제 AI가 생성한 코드를 리뷰할 때는 다르다. 일반적인 코딩 스타일은 이미 좋으므로(AI는 오픈소스 코드에서 학습했으니까), 우리의 리뷰는 더 깊은 부분에 집중해야 한다:
- 이 설계가 우리의 시스템 아키텍처와 맞는가?
- 이 구현이 에지 케이스를 고려하는가?
- 성능상의 문제는 없는가?
- 2년 뒤에 이 코드를 이해할 수 있을까?
이것은 더 깊은 이해를 요구한다. 따라서 코드 리뷰 시간이 오히려 늘어났다.
테스트의 중요성 증대
AI가 생성한 코드를 신뢰하려면, 우리는 더 엄격한 테스트가 필요했다. "이 코드가 정말로 작동하는가?"를 확인해야 하기 때문이다.
우리는 이전보다 더 많은 단위 테스트와 통합 테스트를 작성하기 시작했다. 이것은 생산성의 증가를 상쇄한다. 코드를 빨리 작성했지만, 테스트에 더 오래 걸린다.
문서화의 중요성 재발견
AI가 코드를 자동으로 생성할 수 있다면, "왜 이렇게 했는가"를 설명하는 것이 더 중요해진다. AI가 생성한 코드만으로는 설계의 의도를 이해할 수 없기 때문이다.
따라서 우리는 이전보다 더 많은 문서를 작성하기 시작했다. 아키텍처 의사결정 기록(ADR), 복잡한 로직의 설명, 성능 트레이드오프의 기록. 이것이 좋은 변화인지는 확실하지 않다. 더 문서가 많은 것이 좋은 것은 확실하지만, 그것이 코딩 시간 단축을 상쇄하는가?
아키텍처 역할의 강화
흥미로운 변화가 하나 더 있다. 아키텍처를 정의하는 것이 더욱 중요해졌다. 왜? AI가 명확한 요구사항을 받으면, 그 안에서 일관된 결과를 생성한다. 따라서 "이 시스템이 어떤 구조를 가져야 하는가"를 정확히 정의하는 것이 매우 중요하다.
예를 들어, 우리는 마이크로서비스 아키텍처를 도입하고 있다. 이전에는 이것이 복잡한 설계 문제였다. 하지만 이제는, 각 서비스의 책임을 명확히 정의하면, AI가 그 안에서 일관된 코드를 생성할 수 있다.
결과적으로, 좋은 아키텍처를 설계할 수 있는 개발자의 가치가 올라갔다.
개발자의 미래: 세 가지 시나리오
지금까지의 분석을 바탕으로, 가능한 미래를 세 가지로 나누어 생각해보자.
시나리오 1: 개발자의 역할 변화 (가능성 60%)
가장 가능성 높은 시나리오다. AI는 코드 작성을 더욱 자동화하지만, 개발자는 계속 필요하다. 다만 그들의 역할이 변한다.
미래의 개발자는:
- 시스템 설계자: "이 문제를 어떻게 구조화할 것인가"를 결정하는 사람
- 검증자: AI가 생성한 코드가 정말로 작동하는지 확인하는 사람
- 문제 정의자: AI에게 "정확히 무엇을 해야 하는가"를 설명할 수 있는 사람
- 통합자: 많은 AI 생성 코드 조각들을 연결하는 사람
이 경우, 개발자는 사라지지 않지만, 수요가 줄어들 가능성이 있다. "더 많은 일을 더 적은 개발자가 할 수 있다"는 뜻이기 때문이다.
시나리오 2: 소프트웨어 개발의 민주화 (가능성 30%)
AI가 코드 작성을 충분히 자동화해서, 더 이상 "전문 개발자"가 필요 없게 되는 시나리오다. 비즈니스 애널리스트, 데이터 분석가, 디자이너 등이 직접 AI를 사용해서 필요한 소프트웨어를 만든다.
이 경우, "개발자"라는 직업은 사라지지만, 더 높은 수준의 "소프트웨어 아키텍트"는 더욱 중요해진다. 왜냐하면 여러 AI 생성 시스템들을 조율하고, 보안과 성능을 보장하는 사람이 필요하기 때문이다.
실제로 이것이 가능한지는 의문이다. 현재의 AI 수준에서는, 비전문가가 실제로 사용 가능한 소프트웨어를 만들기는 어렵다. 하지만 기술이 충분히 발전한다면?
시나리오 3: 새로운 병목의 등장 (가능성 10%)
코딩 자동화가 완전해진다면, 병목은 어디로 이동할까? 아마도 요구사항 정의, UX 설계, 테스트, 배포, 운영이 될 것이다. 이 경우, "개발자"는 사라지지만, 그들의 역할은 다른 분야로 확산된다.
예를 들어, 지금의 "전스택 개발자"는 사라지고, "시스템 설계자", "QA 엔지니어", "DevOps 엔지니어" 등의 전문화된 역할들이 더욱 중요해질 것이다.
그렇다면 당신은 뭘 준비해야 하는가?
만약 당신이 개발자이고, AI 시대를 앞두고 불안해한다면, 다음 몇 가지를 고려해보자.
1. 문제를 정의하는 능력을 기르자
AI가 코드를 쓸 수 있지만, "정확히 어떤 문제를 풀 것인가"를 정의하는 것은 여전히 인간의 몫이다. 스스로 질문을 잘 할 수 있는 능력이 가장 가치 있는 기술이 될 것이다.
2. 깊은 도메인 지식을 만들자
당신이 일하는 분야의 깊은 이해가 있다면, AI를 효과적으로 사용할 수 있다. 예를 들어, 금융 시스템을 잘 이해한 개발자는, AI가 생성한 거래 처리 로직의 문제를 즉시 잡아낼 수 있다.
3. 시스템 사고 능력을 기르자
개별 함수를 작성하는 것은 AI가 더 잘할 수도 있다. 하지만 여러 컴포넌트가 어떻게 함께 작동해야 하는가를 이해하는 것은 여전히 인간의 영역이다.
4. AI를 배우되, 모든 것이 아닌 도구로
GitHub Copilot, ChatGPT, Claude를 배우자. 하지만 이것들을 마법의 해결책으로 생각하지 말자. 대신, 당신의 생산성을 20~30% 올려주는 도구로 생각하자. 그리고 그것으로도 충분한 경쟁 우위다.
AI 시대에서 경쟁 우위는 "AI를 더 빨리 배운 사람"이 아니라, "AI의 한계를 이해하고, 그것을 잘 보완할 수 있는 사람"에게 간다.
5. 계속 학습하되, 당황하지 말자
기술은 계속 변한다. 내가 현업에서 느낀 것은, 변화에 가장 잘 대응하는 사람은 특정 기술에 집착하지 않는 사람이라는 것이다. 대신 "어떻게 배울 것인가"를 알고 있는 사람이다.
AI도 마찬가지다. 지금 당신이 "이 프로그래밍 언어를 완벽히 배워야 한다"고 생각한다면, 그 집착을 버리자. 대신 "새로운 도구에 어떻게 적응할 것인가"를 배우는 것이 더 중요하다.
결론: 개발자는 변할 것이다. 사라지지는 않을 것이다.
우리의 결론은 간단하다. AI는 개발자의 역할을 크게 바꿀 것이다. 하지만 개발자를 사라지게 할 거 같지는 않다.
더 정확히는, "현재의 개발자"라는 개념은 변할 것이다. 코드를 작성하는 것이 전부가 아닌, 문제를 정의하고, 시스템을 설계하고, 결과를 검증하는 역할로. 그리고 그런 개발자는 지금보다 더 가치 있을 것이다.
당신이 불안해하는 것이 너무 자연스럽다. 하지만 기술 변화는 항상 새로운 기회를 만든다. 우리는 그 기회를 놓치지 말고, 동시에 변화에 현명하게 대응해야 한다. 그것이 현업에서 일해 온 내 조언이다.