최근 몇 달 동안 묘한 감각이 있었다.
내가 직접 짜는 코드는 줄어들고 있는데, 생산성은 오히려 올라가고 있었다.
처음에는 이게 좋은 변화인지, 아니면 내가 점점 코드베이스에서 멀어지고 있는 건지 판단이 잘 서지 않았다.
나는 지금 테크리드 역할을 하고 있고, 최근에는 이미지 AI 쪽에 집중하고 있었다.
그러다 보니 자연스럽게 에이전틱 코딩 흐름에서 조금씩 멀어지고 있다는 느낌이 들었다.
그래서 생각했다.
이건 감으로 판단할 문제가 아니다. 직접 해봐야 한다.
5주 동안 일부러 많이 만들어봤다
짧은 기간 안에 일부러 다양한 형태의 앱을 만들어보기로 했다.
- Electron 기반 데스크탑 툴
- Tauri 기반 데스크탑 앱
- Love2D 기반 간단한 게임
의도는 단순했다.
AI 코딩이 실제로 어느 정도까지 가능한지,
그리고 개발자의 역할이 어디까지 남는지 확인해보고 싶었다.
다만 한 가지 전제를 두었다.
AI는 기본적으로 오류를 낼 수 있다.
그래서 시작부터 “틀려도 바로 드러나는 환경”을 먼저 만들었다.
- 린트, 타입 체크, 테스트 코드를 촘촘하게 구성
- 엔드투엔드 테스트는 비용이 크기 때문에 핵심 흐름만 작성
- 간단한 디자인 시스템을 미리 갖춰서 일관성 확보
이 정도만 세팅해두어도 AI가 만든 코드의 품질을 빠르게 검증할 수 있었고,
체감되는 생산성 차이는 생각보다 훨씬 컸다.
결과적으로 말하면,
생산성은 확실히 올라갔다.
그런데 더 인상적이었던 건 속도 자체가 아니었다.
개발자는 코드를 덜 짜게 된다
AI를 활용하면 반복적인 구현은 상당 부분 위임할 수 있다.
UI를 만들고, API를 붙이고, 기본적인 로직을 구성하는 것까지
생각보다 빠르게 진행된다.
문제는 그 다음이다.
“이 코드, 믿어도 되는가?”
AI가 만들어준 코드는 대부분 그럴듯하다.
하지만 그게 맞다는 의미는 아니다.
기능적으로는 얼핏 문제가 없어 보이지만, AI의 판단과 실무 맥락 사이에는 늘 작은 괴리가 있다.
도메인 특성, 운영 환경, 팀의 컨벤션 같은 것들은 AI가 알기 어렵다.
그런데 이건 AI만의 문제가 아니다.
주니어가 작성한 코드에서도 같은 일이 벌어진다.
돌아가는 코드를 만드는 것과, 그 코드가 실무에서 문제없이 유지되는 것은 다른 이야기다.
결국 누가 작성했는지는 중요하지 않다.
그 코드를 판단할 수 있는 사람이 있는가가 중요하다.
그래서 이 시점에서 개발자의 역할은 사라지는 게 아니라 바뀐다.
코드를 작성하는 사람이 아니라,
코드를 판단하는 사람이 된다.
“좋은 코드”의 기준이 바뀌고 있다
그동안 우리가 이야기하던 좋은 코드의 기준은 비교적 명확했다.
- 사람이 읽기 쉬운 코드
- 유지보수가 쉬운 구조
- 예측 가능한 동작
이 기준이 틀린 건 아니다.
하지만 지금은 이유가 바뀌고 있다.
물론 지금도 협업은 중요하다.
하지만 코드를 읽는 가장 중요한 이유는 조금 바뀌고 있다고 느낀다.
이제 코드는 사람이 “협업하기 위해” 읽는 것이기도 하지만,
무엇보다 “검증하기 위해” 읽는다.
AI가 코드를 만들어내는 속도는 점점 빨라지고 있다.
하지만 그 코드의 품질은 균일하지 않다.
결국 누군가는 판단해야 한다.
- 이 구조가 유지 가능한지
- 이 로직이 예외 케이스를 커버하는지
- 이 코드를 앞으로 확장할 수 있는지
그래서 나는 여전히 “사람이 읽을 수 있는 코드”를 기준으로 유지하고 있다.
다만 이유는 명확하게 바뀌었다.
협업 때문이 아니라, 책임과 검증 때문이다.
협업은 사라지지 않는다. 형태가 바뀐다.
이번 실험을 하면서 가장 크게 느낀 변화도 여기에 있었다.
한 사람이 엔드투엔드로 개발하는 것이 충분히 가능한 시대가 왔다.
예전에는 기능 하나를 여러 명이 나눠서 개발하는 것이 자연스러웠다.
지금은 한 사람이 전체 흐름을 잡고 끝까지 구현하는 것이 훨씬 자연스럽다.
그래서 처음에는 “이제 협업이 필요 없는 것 아닌가?”라고 생각했다.
하지만 실제로는 반대였다.
예전의 협업이 기능을 나누고, 각자 구현하고, 나중에 합치는 구조였다면
지금은 한 명이 기능을 끝까지 밀고 가고, 팀이 그 결과를 검증하는 구조에 더 가깝다.
협업의 중심이 코드에서 판단으로 이동했다.
“누가 만들었는가”보다
“누가 이걸 설명할 수 있는가”가 더 중요해졌다.
주니어를 어떻게 성장시킬 것인가
이 변화 속에서 내가 가장 자주 고민하게 되는 건 주니어 교육이다.
요즘 주니어들은 AI를 아주 적극적으로 활용한다.
그리고 결과물을 꽤 빠르게 가져온다.
문제는 그 다음이다.
코드는 돌아간다.
데모도 된다.
그런데 운영에 올린 뒤에도 괜찮을지는 선뜻 확신이 서지 않는다.
예전에는 구현 경험이 곧 학습 경험으로 이어지는 경우가 많았다.
지금은 AI가 그 구현 속도를 크게 앞당기기 때문에, 무엇을 배웠는지 확인하는 기준도 달라져야 한다.
이럴 때 예전처럼 말하기는 어렵다.
“코딩을 더 공부해라”
물론 여전히 중요하다.
하지만 그것만으로는 부족하다.
그래서 요즘은 피드백의 기준을 조금 바꾸고 있다.
코드보다 “판단”을 가져오게 한다
이제는 이렇게 묻는다.
- 왜 이 구조를 선택했는가?
- 다른 선택지는 무엇이었는가?
- 이 코드의 리스크는 무엇인가?
AI가 만든 코드를 가져오는 것 자체는 문제가 아니다.
문제는 그 코드에 대한 판단 없이 가져오는 것이다.
“GPT가 이렇게 짰어요”는 판단이 빠져 있다.
“이렇게 짰고, 이 이유로 선택했습니다”에는 최소한의 책임이 담겨 있다.
이 차이가 결국 성장의 차이를 만든다.
마무리
아마 이 기준도 시간이 지나면 또 바뀔 것이다.
지금 우리가 당연하게 생각하는 것들이 몇 년 뒤에는 전혀 다르게 보일 수도 있다.
다만 지금 시점에서 확실하게 느끼는 것은 하나다.
개발자는 코드를 덜 짜게 되었지만,
더 많은 것을 판단해야 하는 역할로 이동하고 있다.
예전보다 코드를 덜 짜고 있는데도 일이 더 많이 진행되는 이유가 여기에 있다.
이제 개발자의 경쟁력은 얼마나 빨리 구현하느냐에만 있지 않다.
무엇을 믿고, 무엇을 의심하고, 어디에서 멈춰서 다시 판단하느냐에 더 가까워지고 있다.
그리고 아마 당분간은,
나 역시 그 변화의 한가운데에서 계속 적응하게 될 것 같다.
참고
이번에 AI 코딩 흐름을 점검하면서 실제로 만든 프로젝트들이다.