AI가 코드를 쓰는 시대, 개발자의 진짜 역량이 드러난다

이번 포스팅에서는 AI 시대에 개발자의 역할이 어떻게 달라지고 있는지, 그리고 무엇을 준비해야 하는지 이야기해보려 한다. 최근 필자가 재직 중인 직장에서도 많은 개발자들이 이 주제에 대해 고민을 하고 있는데, 비단 이 주제는 필자 같은 개발자뿐 아니라 다양한 직군이 함께 고민하는 문제일 것이다.

공통적으로는 AI로 인한 생산성 향상에 대한 기대와 함께, 대체 가능성에 대한 불안도 동시에 느끼는 것 같다.

물론 AI로 인해 앞으로의 먼 미래가 어떻게 달라질 것인지에 대해서는 아무도 알지 못할테고, 필자 또한 마찬가지이다. 그래도 아무것도 안할 수는 없으니 필자가 그리는 미래의 개발자의 역할과 모습에 대해서 한번 가볍게 이야기해보려고 한다.

ChatGPT 이후 3년

처음 ChatGPT가 등장한 2022년 말, 사실 필자는 AI가 이렇게 빠르게 발전할 것이라고는 상상하지 못 했다. 당시에는 할루시네이션 이슈도 많았고 무엇보다 출력의 퀄리티 자체가 그리 좋지 않았기 때문이다.

하지만 이제 겨우 3년 정도가 지났음에도 불구하고 우리 개발자의 하루는 상당히 많은 부분이 변화했다.

지금까지의 개발자라는 직업의 정의는 “프로그래밍이라는 행위를 통해 세상의 문제를 해결하는 사람” 정도였던 것 같다. 자연어로 된 요구사항을 분석하고, 설계에 대해 고민하고, 직접 키보드를 타이핑해 구현체를 만들어내는 일련의 과정을 직접 수행했다.

그래서 불과 몇 년 전까지만 해도 아침에 출근하면 에디터를 열고 빈 파일에 커서를 놓는 것으로 하루를 시작했지만, 최근에는 직접 코딩을 하기보다는 AI에게 맥락을 전달하고, 생성된 코드를 읽고, 고치고, 다시 요청하는 것이 하루의 많은 부분을 차지한다.

ChatGPT가 처음 등장한 지 3년 남짓한 시간 동안 변화가 워낙 빨랐기에, 나름 휴대폰과 스마트폰의 등장을 모두 겪어본 아재인 필자도 이렇게 빨리 세상이 바뀔 줄은 상상하지 못했다.

이미 AI 코딩 에이전트의 성능은 단순 보조 수준을 넘어선지 오래다. 프롬프트만 잘 제공하면 함수 하나, 모듈 하나 정도는 사람이 작성한 것과 쉽게 구별하기 어려운 코드를 내놓는다. 이런 환경에서 개발자가 모든 코드를 직접 한 줄씩 작성하는 방식은, 최소한 일부 업무에서는 점점 비효율이 되어가고 있다.

앞으로 변화 속도는 더 빨라질 가능성이 높다. 그리고 이 과정에서 개발자의 역할도 팀과 조직의 맥락에 따라 다르게 재편될 것이다. 그렇다면 지금 우리는 어떤 방향으로 미래를 준비해야 할까?

작성자에서 의사결정권자로

이 질문에 답하려면 먼저 개발 과정에서 우리가 사용하는 시간이 어디에 주로 투자되고 있는지부터 봐야 한다. 예전에는 구현을 위해 직접 타이핑하는 시간이 길었다면 지금은 AI에게 프롬프트로 맥락을 전달하고, 생성된 코드를 읽고 고치고 다시 요청하는 시간이 빠르게 늘어나고 있다.

즉, 코드를 통해 제품을 생산하는 행위는 직접적인 코드 작성에서 점점 “코드에 대한 판단”으로 이동하고 있다. 여기서 판단이란 단순히 AI 출력이 의도대로 됐는지 확인하는 것이 아니라 비즈니스 의도가 기술적 구현으로 올바르게 번역됐는지 검증하는 과정을 의미한다.

물론 AI가 계속 발전하면 코드 리뷰조차 인간이 할 필요가 없어질 수 있다고 생각할 수 있겠지만, 필자 생각은 다르다. 그 이유는 기술적 가능성이 아닌 훨씬 더 근본적인 곳에 있다.

코드에 대한 책임을 질 사람이 필요하다

최근 많은 개발자들이 코드 리뷰에도 AI를 활용하고 있다. 보통 Pull Request에 AI가 코드를 읽어보고 코멘트를 남겨주는 방식으로 작동하는데, 의외로 예리한 부분을 지적하는 경우도 있어서 필자도 가끔 놀란다.

하지만 필자는 기술이 얼마나 발전하든 결국 최종적인 “문제 없음”이라는 승인 도장을 찍는 인간의 역할은 여전히 존재할 것이라 생각한다.

그 이유는 바로 이 질문 때문이다.

과연 코드로 인해 문제가 발생했을 때 누가 책임을 지는가?

AI는 법적으로 인격체가 아니기 때문에 책임을 질 수 없다. 그렇다면 AI가 생성한 코드로 인해 문제가 발생했다면 과연 누가 책임을 져야하는 것인지에 대한 질문을 던져볼 필요가 있다.

만약 AI가 작성한 코드로 인해 결제 로직에 버그가 생겨 고객에게 잘못된 금액이 청구됐을 때 서비스 운영자가 이렇게 답변하면 어떻게 될까?

AI가 작성한거라 전 왜 이렇게 됐는지 모르겠는디요

이딴 답변을 고객이 받아줄리가 없다. 입장바꿔서 생각해보면 아주 복장터지는 일이다.

아무리 AI가 작성한 코드라고 해도 결국 누군가는 “책임”을 져야한다. 그리고 필자가 생각하기에 그 책임을 져야하는 사람은 바로 그 코드를 리뷰하고 승인한 개발자, 그리고 그 개발자가 속한 조직이다.

이러한 방향성은 필자의 뇌피셜이 아니라 이미 여러 규제로 나타나고 있다.

2024년 발효된 EU AI Act는 의료, 금융, 인프라 같은 고위험 영역에서 AI 시스템에 인간 감독을 의무화했다. 시행 자체는 단계적으로 진행 중이지만 방향성 자체는 분명하다. AI가 판단을 내리더라도 이 과정을 인간이 리뷰 가능하도록 만들어야 한다는 원칙을 법으로 못 박은 것이다.

또한 EU 쪽에서는 제품책임 체계를 디지털 제품/소프트웨어까지 포괄하려는 논의도 이어지고 있다. “AI가 만들었으니 우리 책임이 아니다”는 주장이 법적으로 점점 통하기 어려워지는 방향으로 가고 있는 것이다.

규제 뿐 아니라 다른 분야에서 나타난 실제 사례들도 보여지고 있다. 자율주행차는 사고가 나면 책임이 제조사와 운전자에게 돌아간다. FDA 승인을 받은 의료 AI 진단 도구도 최종 판단은 의사가 내려야 한다. 2010년 미국 주식시장에서 알고리즘 트레이딩이 연쇄 폭락을 일으킨 Flash Crash 사건에서도 알고리즘을 포함한 자동화 시스템을 운영하는 주체가 규제/집행의 대상이 된다는 걸 보여준다.

자동화가 고도화될수록 책임 구조는 희미해지는 게 아니라 오히려 더 선명하게 인간 쪽으로 귀속되는 경향이 존재하는 것이다.

그래서 필자는 앞으로 개발자의 역할이 사라지기보다는 코드를 작성하는 사람에서 “코드를 리뷰하고 승인 도장을 찍는 사람”으로 변화하게 될 것이라 생각한다.

결국 개발자의 역할이 사라지는 것이 아니라 무게 중심이 이동하는 것에 가깝다. 코드를 생산하는 방법이 달라졌을 뿐, 최종 코드의 품질이 그것을 리뷰하는 개발자의 역량에 달려 있다는 사실은 변하지 않는다. 그렇다면 이 새로운 구조에서 개발자에게 구체적으로 어떤 역량이 필요해지는 걸까?

AI 시대에 개발자에게 요구되는 역량

아무래도 AI 시대이니 프롬프트를 잘 다루거나 AI 도구에 능숙한 것이 핵심 역량이 될 것 같지만, 필자 생각은 조금 다르다.

뭐 요즘에는 “유명한 개발자 누구처럼 짜줘”라고 하면 알아서 해준다고는 하는데, 반대로 생각해보면 그 프롬프트를 작성할 수 있는 누구나 그렇게 짤 수 있다는 말이다. 거기에 어떤 경쟁력이 있는 것일까.

중요한 것은 그런 프롬프트를 작성하는 것이 아니라, 혹여나 그런 프롬프트를 넣었음에도 불구하고 퀄리티 기준을 충족하지 않는 코드가 출력됐을 경우 문제를 감지할 수 있는 능력이다. 그 프롬프트 넣는다고 무조건 결과물의 퀄리티가 좋은 것은 아닐테니 말이다.

아이러니하게도, 필자는 AI 시대에 개발자에게 요구되는 역량 또한 지금 좋은 개발자에게 요구되는 역량과 크게 다르지 않을 것이라 생각한다.

왜냐하면 리뷰 과정 속에서 인간은 이 코드가 런타임에서 큰 문제가 없을지, 장기적인 변화에 대비할 수 있는 코드인지, 빠진 예외처리는 없을지, 정책에 위반되는 코드는 없는지와 같은 고맥락의 체크 리스트를 확인해야하기 때문이다. 그리고 결정적으로 코드에 대해서 최종적으로 승인 도장을 찍는 사람이 존재한다는 것은 여전히 “인간이 이해하기 쉬운 코드”를 작성해야한다는 것을 의미한다.

만약 인간이 코드를 읽을 필요가 없다면 모든 코드는 기계어로 작성해도 된다. 하지만 만약 이 코드에서 문제가 생기면 여러분이 책임을 져야하는데, 아무리 시대가 발전한다고 해도 그 코드를 읽지도 않고 라이브에 배포할 수 있겠는가?

이 벽을 넘지 못하는 이상, 결국 인간이 코드를 읽고 이해해야하는 상황은 여전히 발생하기 때문에 인간이 이해하기 쉬운 코드란 무엇일지, 어떻게 하면 그런 코드를 작성할 수 있을지와 같은 지금 시대에 개발자들이 고민하고 있는 내용은 AI 시대에도 반복될 가능성이 높다.

장기 변경 비용을 예측하는 역량

최근 링크드인에 올라오는 게시물을 보면, 처음에는 “AI로 이런 거 만들었어요”라는 포스팅만 올라오더니, 요즘에는 간간히 “유지보수가 어려워서 개발자를 고용했습니다”, “기능을 도저히 못 붙히겠어서 접었습니다”와 같은 슬픈 엔딩도 보인다.

이런 일이 발생하는 이유는 AI가 “작동하는 코드”를 만드는데 최적화되어있기 때문이다. 결국 학습 데이터에서 가장 빈번하게 등장하는 패턴을 재현하는 것이 AI의 동작 방식인데, 그 패턴들은 당연히 정상적으로 실행되는 코드들이다. 하지만 지금 당장 작동하는 코드와 6개월 뒤에도 유지보수가 쉬운 코드는 전혀 다른 기준이다.

물론 최근 모델은 유지보수성까지 고려한 답을 제시하는 경우도 늘고 있다. 하지만 필자가 말하고자 하는 핵심은 단일 산출물의 품질과 장기 변경 비용 예측이 다른 문제라는 점이다.

소프트웨어의 품질이라는 건 원래 즉시 드러나지 않는 성질의 것이다. 나쁜 설계의 비용은 코드를 작성한 시점이 아니라, 그 코드를 변경해야 하는 시점에 발생하기 때문이다.

코드를 다각도로 평가하는 역량

나쁜 설계의 비용이 작성 시점이 아닌 변경 시점에 드러난다는 건 AI 등장 이전에도 마찬가지였지만, 코드 생성 속도가 빨라지면서 이 “지연된 비용”이 쌓이는 속도도 함께 빨라졌다는 게 차이점이다.

검수의 대상도 다양하다. 단순히 “이 코드가 맞느냐 틀리느냐”와 같은 기능적 정확성은 테스트로 어느 정도 검증할 수 있다. 더 까다로운 건 구조적 품질이다.

과연 이 모듈의 책임 범위가 적절한가? 이 의존성 방향이 맞는가? 이 인터페이스가 변경에 유연한가? 이런 질문들은 자동화된 테스트로는 잡기 어렵다. 그 너머에는 성능적 함의도 있다. AI가 생성한 코드가 작동은 하지만, 데이터가 10배 늘었을 때도 괜찮을까? 그리고 보안적 측면도 있다. 입력 검증이 충분한가, 권한 확인이 빠져 있지는 않은가. 이 모든 차원을 동시에 고려하면서 코드를 평가하는 건, 단순히 “코드를 읽을 줄 아는 것”과는 다른 수준의 역량이다.

그리고 AI의 생성 속도가 빨라질수록 이 문제는 더 심각해진다.

사람이 직접 코드를 작성하던 시절, 코드 생산량에는 물리적 상한이 있었다. 한 개발자가 하루에 만들어낼 수 있는 코드의 양이 제한되어 있었기 때문에, 팀 전체가 검토해야 할 코드의 규모도 그 속도에 맞춰 조절됐다. 생산 속도와 리뷰 역량 사이에 어느 정도의 균형이 자연스럽게 유지됐던 것이다. 물론 느리게 작성한다고 코드가 더 좋아지는 건 아니지만 생산량이 리뷰 역량을 크게 앞지르기 어려운 구조이기는 했다.

하지만 AI가 수 초 만에 수백 줄의 코드를 생성할 수 있는 환경에서는 코드 생산 속도와 리뷰 역량 사이의 균형이 쉽게 깨질 수 있다.

특히 리뷰 기준, 병렬 리뷰 체계, 자동화 게이트가 충분하지 않다면 코드 양이 두세 배 늘어도 리뷰 인력과 시간은 그대로라 검증 누락이 생기기 쉽다. 그 결과 기술 부채가 더 빠르게 쌓일 가능성이 커진다. 공장의 생산 라인이 빨라졌는데 품질 검사 체계가 그대로인 상황인 것이다.

필자는 아마 많은 회사들이 AI를 도입했음에도 생산성 증가를 못 느끼는 이유가 이것이 아닐까 생각한다. 코드 생산은 빨라졌을지 몰라도 AI가 뱉은 코드를 리뷰하는 과정이 제일 병목이다.

이 구조에서 코드를 제대로 빠르게 검수할 수 있는 개발자의 가치는 자연스럽게 올라간다. AI가 쏟아내는 코드의 양이 많아질수록 그 코드에 섞인 잠재적 위험과 기술 부채를 선별할 수 있는 사람의 필요성이 커지기 때문이다.

추상화 역량

필자는 추상화 역량도 중요한 포인트 중 하나라고 생각한다. 결국 추상화란 복잡한 시스템에서 무엇을 감추고 무엇을 드러낼지, 그리고 어디에 경계를 그을지 결정하는 능력이다.

AI가 추상화를 못하느냐고 물으면 솔직히 그건 아니다. AI도 인터페이스를 정의하고 클래스를 나누고 모듈을 분리할 수 있다. 사실 형식적인 측면에서는 필자보다 잘 하는 경우도 있다. 하지만 AI가 만드는 추상화와 숙련된 개발자가 만드는 추상화 사이에는 결정적인 차이가 하나 있다.

AI의 추상화는 학습 데이터의 통계적 평균에 기반한다. 수많은 프로젝트에서 본 “그럴듯한 패턴”을 현재 상황에 적용하는 방식이다. 하지만 실제 소프트웨어 설계는 정답을 맞히는 게임이 아니라, 한정된 자원과 불확실한 미래 속에서 무엇을 포기할지 결정하는 트레이드오프의 영역이다.

AI는 코드 내부의 정합성을 맞추는 데 능숙할지 몰라도 코드 외부의 맥락까지 고려하여 “어디에 경계를 그을지” 결정하는 것은 어려워한다. 특정 맥락에서 최적인 코드는 통계적 평균 너머의 전략적 판단이 개입될 때 비로소 완성되기 때문이다.

이건 AI의 결함이라기보다는 통계적 학습이라는 방식 자체가 가진 구조적 한계에 가깝다. 평균적으로 좋은 코드를 만들 수는 있지만, 특정 맥락에서 최적인 코드를 만드는 건 다른 문제다.

AI가 출력한 코드의 위험한 점은 겉보기에 좋아 보인다는 것이다. 코드 리뷰에서도 쉽게 통과할 수 있다. 파일이 적절히 나뉘어 있고, 네이밍도 관례를 따르고, 패턴도 익숙하기 때문이다. 문제는 실제로 변경이 필요한 시점에 발견된다. 결제 수단을 하나 추가하려고 하는데, “깔끔하게 나뉘어 있던” 구조의 여기저기를 동시에 수정해야 한다는 걸 그제야 깨닫게 되는 것이다. 이런 종류의 결함은 코드를 쓸 때가 아니라 코드를 고칠 때 드러난다.

AI가 만든 코드에서 이런 패턴은 꽤 자주 발견된다. 통계적으로 가장 흔한 구조를 따랐기 때문에 표면적으로는 나무랄 데가 없지만, 실제 요구사항과 어긋나 있는 경우가 적지 않다.

또 다른 예로, 프론트엔드에서 흔히 보이는 상황을 생각해보자. AI에게 대시보드 컴포넌트를 만들어달라고 하면, 보통은 하나의 거대한 컴포넌트 안에 데이터 페칭, 상태 관리, UI 렌더링을 모두 담은 구조를 내놓는다. 혹은 반대로 학습 데이터에서 본 모범 사례를 과하게 적용해서, 간단한 차트 하나를 그리기 위해 커스텀 훅 세 개와 컨텍스트 프로바이더를 만들어놓기도 한다.

전자는 추상화가 부족한 것이고, 후자는 추상화가 과잉인 것이다. 둘 다 현재 프로젝트의 복잡도 수준에 맞지 않는다는 점에서는 같은 문제다. 적절한 추상화란 결국 현재 상황에서 딱 필요한 만큼의 구조를 만드는 것이고, 이 “만큼”을 판단하는 건 맥락을 아는 사람만 할 수 있다.

숙련된 개발자는 이런 코드를 읽을 때 “여기서 이렇게 나눈 건 이 도메인의 특성을 모르고 한 거구나”라는 걸 알아채고 도메인에 맞는 경계를 다시 긋는다. 이 과정에서 동원되는 건 코딩 스킬이 아니라 시스템에 대한 이해와 설계에 대한 감각이다.

즉, AI가 만든 코드를 평가할 때도 사람이 만든 코드를 평가할 때와 동일한 기준이 적용된다. “이 추상화가 실제로 복잡도를 줄이고 있는가, 아니면 추적해야 할 간접 경로만 늘리고 있는가?” 이 질문을 던질 수 있는 것 자체가 이미 하나의 역량이다.

암묵지를 명시화할 수 있는 역량

추상화 역량이 “어디에 경계를 그을지 아는 것”이라면, 암묵지를 명시화하는 역량은 “왜 거기에 경계를 그어야 하는지 설명할 수 있는 것”이다. 서로 다른 능력이지만 실제로는 함께 작동한다.

좋은 코드와 나쁜 코드를 구분하는 감각은 코드를 많이 읽고 쓰면서 자연스럽게 체득하게된다. 보통 “뭔가 이상한데”라는 직감으로 시작되는 암묵지는 언어로 명확하게 설명하기가 꽤나 어렵다.

그런데 이 암묵지를 언어로 만드는 능력이 AI 시대에 특히 중요해진다. “뭔가 이상한데”라는 직감을 “이 함수는 두 가지 책임을 가지고 있다”, “이 인터페이스가 변경에 취약하다”는 구체적인 언어로 바꿀 수 있어야 AI에게 올바른 명령을 내릴 수 있기 때문이다.

다만 여기서 말하는 건 few-shot 예시나 chain-of-thought 같은 형식적인 프롬프트 기법이 아니다. 어차피 그런 것들은 모델이 발전하면서 자연스럽게 희석된다.

필자가 이야기하고 싶은 건 그 아래에 있는 능력, 즉 무엇을 만들어야 하는지 명확하게 정의하고, 어떤 맥락이 중요한지 판단해서 전달하는 것이다.

대충 “이걸 만들어줘”라고 말할 수 있는 사람은 많다. 하지만 개발자는 AI가 뱉은 코드의 문제점을 정확하게 파악하고 “이걸 이런 방식이 아니라 저런 방식으로 만들어야 하는 이유”를 설명할 수 있는 사람이 되어야한다.

“뭔가 이상한 코드”를 보고 그 이유를 구체적으로 알고 말할 수 있는 것이 곧 개발자의 설계 역량이 될 것이다. 즉, 시스템과 코드에 대한 이해가 깊을수록, AI에게 더 구체적이고 더 정확한 지시를 내릴 수 있다.

메모리를 직접 다루지 않아도 메모리 모델을 이해해야 성능 문제를 해결할 수 있듯이, 코드를 직접 작성하지 않아도 추상화를 이해해야 설계 문제를 잡아낼 수 있다. 추상화의 계층이 하나 더 생겼을 뿐, 추상화를 다루는 능력의 필요성 자체는 사라지지 않았다.

이 역량들의 유효기간은 도구 숙련도보다 훨씬 길다. 도구 숙련도의 수명은 도구의 교체 주기에 묶여 있다. jQuery가 React에 밀리는 데 몇 년이 걸렸고, Webpack이 Vite에 밀리는 데 또 몇 년이 걸렸다. 반면 설계 판단과 암묵지 언어화 역량의 수명은 소프트웨어의 본질적 복잡성이 존재하는 한 유효하다.

이 복잡성은 도구가 바뀌어도 사라지지 않는다. 결제 시스템이 복잡한 이유는 프레임워크 때문이 아니라 결제 도메인 자체가 복잡하기 때문이고, 그 복잡성을 다루는 감각은 특정 도구에 종속되지 않는다.

의도적 수련 설계의 필요성

여기까지 읽으면 자연스럽게 떠오르는 질문이 하나 있다. 코드를 직접 작성하는 시간이 줄어드는데, 도대체 추상화나 설계 감각은 어떻게 기르라는 걸까?

이건 “도구가 할 수 없는 것에 집중하라”고 말하면서 정작 그것을 기를 기회가 줄어드는 모순적인 상황이다.

해법은 두 층으로 나뉜다. 하나는 업무 흐름 안에서 AI에게 넘기지 말아야 할 두 지점을 지키는 것이고, 다른 하나는 그 판단력의 바탕이 되는 설계 감각을 업무 밖에서 의도적으로 유지하는 것이다. 그리고 이 두 가지를 관통하는 태도가 하나 있다.

AI에게 넘기지 말아야 할 두 지점: 설계와 리뷰

평소 업무 흐름 안에서 AI에게 넘기지 말아야 할 지점이 두 군데 있다. 바로 코드 작성 앞단의 설계와 뒷단의 리뷰다.

설계를 직접 하는 것은 단순한 습관의 문제가 아니다. 프롬프트를 치기 전에 “이 모듈이 외부에 노출할 인터페이스는 무엇인가”, “책임의 경계는 어디에 그을 것인가”를 먼저 정의하는 과정을 거치고 구현을 AI에게 위임하면, AI가 만들어낸 결과물을 자신의 설계 결정과 비교할 수 있게 된다.

AI가 다른 구조를 선택했다면 왜 그랬는지 분석하게 되고, 내가 놓친 것은 없는지, AI가 틀린 것은 아닌지 다시 생각하게 된다. 만약 이 과정이 부재한다면 단순히 AI가 출력한 코드를 소비하게 될 가능성이 높은데, 단순히 출력을 소비하는 것과 자신의 판단을 기준으로 출력을 평가하는 것은 완전히 다른 경험이다.

또한 리뷰는 의도적으로 시간을 따로 내지 않아도 업무 흐름 안에서 자동으로 주어지는 역량 성장 기회다. 그렇기 때문에 이 기회를 그냥 흘려보내는 것이 가장 위험하다.

AI에게 PR 리뷰를 맡기고 별다른 문제가 없으면 그냥 승인해버리는 습관은 마치 체육 시간에 운동장에 나가서 벤치에만 앉아 있다가 들어오는 것과 같다. 업무 자체는 어찌어찌 진행할 수 있겠지만, 그렇게 몇 년을 일을 해도 실력은 그대로일 가능성인 높다.

코드 리뷰는 요구사항, 설계 의도, 비즈니스 맥락을 동시에 고려하면서 코드를 읽는 과정이고, 이 과정 자체가 설계 감각을 유지하는 훈련이라고 생각해야한다.

의도적으로 직접 짜보는 시간

업무 안에서 설계와 리뷰를 직접 한다고 해서 충분한 건 아니다. 설계 감각 자체가 구현의 고통을 알아야 생기기 때문이다. 어떤 구조가 변경에 취약한지를 직접 손으로 겪어봐야 “이 추상화가 잘못됐다”는 직감이 생긴다. 겪어보지 못한 고통은 감각으로 남지 않는다.

주니어 개발자의 경우 특히 그렇다. 경험이 적은 상태에서 AI가 생성한 코드를 리뷰하는 건, 아직 운전을 배우는 중인 사람에게 자율주행차의 판단을 평가하라고 하는 것과 비슷한 면이 있다. 직접 핸들을 잡아봐야 도로 위의 감각이 생기는 것처럼 직접 코드를 짜봐야 구조에 대한 감각이 생긴다.

미래의 개발자에게 코딩하는 역량은 매일 하는 업무가 아니라 판단력을 유지하기 위한 훈련이 될 가능성이 높다고 본다. (아마 주니어 시절의 고통스러운 직접 구현 경험은 선택이 아니라 리뷰어로서 면허를 따는 과정 정도가 되지는 않을까.)

그래서 사이드 프로젝트나 개인 학습에서는 의도적으로 AI를 내려놓고 처음부터 끝까지 직접 구현해보는 시간을 만드는 게 좋다.

AI가 편리할수록 그 마찰이 귀찮게 느껴지지만 그 마찰과 고통을 겪어야 빠른 실력 향상이 생길 것이라고 생각한다. 그리고 구현이 막히는 지점이나 리팩토링을 해야 하는 순간이 깨달음을 얻을 수 있는 순간이다.

두 가지를 관통하는 태도: “왜”를 언어화하는 연습

업무에서 설계와 리뷰를 직접 하든, 따로 시간을 내서 직접 짜든 이 두 가지 모두에서 작동해야 하는 태도가 있다. 바로 “뭔가 이상한데”라는 직감이 드는 순간 그 감각을 그냥 넘기지 않고 왜 그렇게 느꼈는지 명확한 말로 표현할 수 있을 때까지 다듬는 것이다.

“이상한데”에서 멈추면 그냥 직감에서 끝나버리지만, “이 함수가 두 가지 책임을 가지고 있다”까지 가면 언어가 된다. 직감은 나만 아는 것이고 언어는 쓸 수 있는 것이다. 언어가 되어야 AI에게 정확한 지시를 내릴 수 있고, 팀원에게 설명할 수 있고, 다음에 비슷한 패턴을 만났을 때 알아챌 수 있다.

AI가 만들어낸 코드가 작동한다고 해서 거기서 멈추지 않고, “왜 이 구조를 선택했을까”, “다른 구조였다면 어떤 트레이드오프가 있었을까”를 스스로에게 물어보는 것. 이 습관이 있는 개발자와 없는 개발자 사이의 격차는 시간이 갈수록 벌어질 것이다.

결국 본질은 변하지 않았다

AI의 등장으로 개발자의 역할이 코드 작성자에서 리뷰어로 이동하고 있다. 생산과 검수를 모두 인간이 하던 시대에서 생산은 AI가 하고 검수는 인간이 담당하는 시대로 변화하고 있는 것이다.

그리고 이러한 변화가 기술적 한계가 아닌 책임 소재라는 사회적 문제에서 비롯된다는 걸 이해하면 역할 전환의 의미가 더 명확해진다.

결국 필자는 리뷰 승인이라는 도장을 잘 찍으려면 작동하는 코드와 오래 살아남는 코드를 구분하는 눈, 맥락에 맞는 추상화를 판단하는 설계 감각, 그 감각을 언어로 만들어 정확한 방향을 잡는 역량이 필요해질 것이라 생각한다.

즉, AI 시대의 차이는 생산량이 아니라 누가 맥락을 이해하고 책임 있게 승인하느냐에서 난다. 시대는 변화했지만 결국 개발자라는 사람이 책임져야하는 영역이 코드의 퀄리티라는 사실은 변하지 않는 것이다.

AI가 이전 도구들과 근본적으로 다른 것은 사실이다. 농기구나 기계와 달리 AI는 스스로 추론하고 생성한다. “AI도 그냥 또 하나의 도구야”라는 식의 주장이 설득력을 잃는 건 당연하다. 그렇다면 왜 요구되는 역량이 바뀌지 않는다고 할 수 있을까.

논리는 책임에서 시작한다. 책임을 진다는 건 판단을 한다는 뜻이고, 판단의 질은 코드의 구조적 건강함을 알아보는 눈, 도메인에 맞는 추상화를 구분하는 감각, 장기 변경 비용을 예측하는 능력에서 온다. 이것들이 항상 좋은 개발자와 평범한 개발자를 갈랐던 것들이다.

프레드 브룩스(Fred Brooks)는 1986년에 소프트웨어의 복잡성을 두 가지로 나눴다. 우발적 복잡성은 도구의 한계에서 오는 것이고, 본질적 복잡성은 문제 자체에 내재된 것이다. AI가 해결하는 건 우발적 복잡성이다. 보일러플레이트, 반복 패턴, 문법 오류 같은 것들. 하지만 비즈니스 요구사항의 모호함, 상충하는 설계 목표 사이의 균형, 미래 변경 방향에 대한 불확실성 같은 본질적 복잡성은 AI가 아무리 발전해도 사라지지 않는다. 이 복잡성은 도구의 수준이 아니라 문제 자체의 성격에서 온다.

그래서 AI의 성격이 이전 도구들과 달라도 인간이 판단과 책임의 주체로 남아 있는 한 그 판단에 필요한 역량의 본질은 바뀌지 않는다. 필자는 오히려 코드 생산이 자동화될수록 그 생산물을 검수하는 판단력의 비중이 오히려 부각될 것이라 생각한다.

필자와 함께 일하는 코치 중 한 분은 이 상황을 빗대어
"물이 빠지면 비로소 누가 발가벗고 수영을 하고 있었는지 알 수 있을 것"이라고 했는데
아주 찰떡인 비유인 것 같다.

그래서 필자는 최근 많은 사람들이 AI라는 도구를 잘 깎는 것에 집중하는 것을 보면서 뭔가 조금 이상하다는 생각을 했었다.

불과 1년 전만해도 프롬프트 엔지니어링이 굉장히 중요한 화두였지만 지금은 그 얘기는 쏙 들어가고 스킬, 병렬 에이전트, 팀과 같은 기능들에 대한 이야기가 오간다. 아마 6개월만 지나도 이 키워드들도 쏙 들어갈 것이다.

어차피 AI는 길가는 초등학생이 프롬프트를 갈겨도 제대로된 출력을 낼 수 있는 수준까지 발전할텐데, 지금 도구를 잘 사용하는 방법에 집중하는 것이 정말 옳은 방향일까? 오히려 필자는 도구를 잘 깎는 것에만 집중하면 도태되기 쉬워지지는 않을까 하는 생각을 가지고 있다.

물론 필자가 그리는 미래가 실제로 그렇게 펼쳐질지는 모른다. AI가 어느 방향으로 얼마나 빠르게 발전할지 정확히 아는 사람은 없고, 필자도 예외가 아니다. 이 글도 결국 불확실한 미래를 앞에 두고 한 명의 개발자가 지금 할 수 있는 생각을 정리해본 것일 뿐이다.

정답은 없지만, 물이 빠지는 속도 만큼은 분명히 빨라지고 있다. 이 글을 읽는 독자 분들도 물이 빠졌을 때 발가벗고 수영을 하고 있는 사람이 되지 않도록 최선을 다해 각자만의 답을 찾아보기를 바란다.