'90%의 코드가 AI로 생성될 것이다'라는 예측이 현실로 다가오고 있다. 그런데 이 수치를 들었을 때 드는 첫 번째 질문이 여전히 '그래서 개발자는 뭘 하면 되나?'라면, 아직 이 전환의 핵심을 짚지 못한 것이다. 더 정확한 질문은 이거다. '코드를 짜는 행위 자체의 의미가 바뀌었다면, 우리는 무엇에 능숙해져야 하는가?'
세 편의 글—dev.to의 《AI 생성 코드 엔지니어링 가이드》, 《코드는 더 이상 인간을 위해 쓰이지 않는다》, 그리고 GeekNews에서 공유된 《AI 코딩은 도박이다》—은 각기 다른 톤으로 같은 지점을 가리키고 있다. 표면적 생산성 뒤에 숨어 있는 패러다임 전환, 그리고 그 전환이 개발자에게 요구하는 진짜 역량.
핵심 이슈: 코드의 목적지가 바뀌었다
오랫동안 코드는 두 가지 독자를 동시에 섬겼다. 기계와 인간. 좋은 변수명, 깔끔한 추상화, 예측 가능한 파일 구조—이 모든 관행은 '다음에 이 코드를 열 인간 개발자'를 위한 것이었다. 《코드는 더 이상 인간을 위해 쓰이지 않는다》는 이 전제가 흔들리고 있다고 진단한다.
AI 코딩 에이전트가 실제 협업자로 코드베이스를 읽고, 변경을 제안하고, 구현을 작성하는 환경에서는 '다음 독자'가 인간이 아닐 수 있다. 그리고 에이전트가 막히는 지점은 복잡한 로직이 아니다. '왜 이렇게 짰는가'가 코드 어디에도 없을 때다. "trial 계정에는 이 이메일을 보내지 말 것"이라는 규칙이 Slack 히스토리나 누군가의 머릿속에만 있다면, 에이전트는 그냥 추측한다.
결론은 명확하다. 코드의 중심이 '구현'에서 '의도(intent)'로 이동하고 있다. 코드는 점점 더 명확하게 정의된 스펙의 컴파일된 결과물이 되어가고 있다.
맥락 해석: 생산성 착각과 도박의 심리
그런데 여기서 불편한 진실이 끼어든다. 《AI 코딩은 도박이다》는 이 전환 과정에서 발생하는 심리적 함정을 정면으로 건드린다. AI 코딩 도구의 즉각적 결과 생성은 슬롯머신을 당기는 행위와 구조적으로 닮아 있다. 명령을 입력하고, 그럴듯한 결과를 기다리고, 틀려도 '뭔가 한 것 같은' 착각이 남는다.
이게 팀 리빌딩 관점에서 실질적인 위험이다. 표면적 생산성은 올라가는데 개발자의 사고 근육은 조용히 약해지는 구조. 직접 문제를 파헤치고, 트레이드오프를 계산하고, 아키텍처 결정의 맥락을 머릿속에 쌓아가는 과정—이것이 시니어 개발자를 시니어답게 만드는 요소인데, AI에 사고를 위임하면 이 과정이 생략된다.
Hacker News 댓글 중 가장 예리한 것은 이거다. "테스트가 있는 코드 변환 작업은 AI가 꽤 잘하지만, 테스트가 없으면 슬롯머신처럼 운에 의존하게 된다." 결국 AI의 신뢰도는 인간이 미리 심어놓은 명세와 테스트의 품질에 정비례한다.
시사점: 테크 리드가 지금 당장 해야 할 세 가지 재정의
이 세 편의 글을 종합하면, AI-First 팀에서 개발자의 역할은 세 축으로 재정의된다.
첫째, 명세 작성 능력이 1급 기술 스킬이 된다. 《AI 생성 코드 엔지니어링 가이드》가 강조하듯, 'garbage-in, garbage-out' 원칙은 AI에게 지수적으로 적용된다. "데이터베이스 연결 함수 써줘"가 아니라, 어떤 드라이버를 쓰고, 어떤 환경 변수를 읽고, 커넥션 풀은 몇 개이며, 에러 처리는 어떻게 하는지를 명확하게 서술하는 능력. 이게 이제 코딩 실력만큼 중요한 스킬이다. 팀원 채용 기준에 '요구사항을 얼마나 정밀하게 언어로 표현할 수 있는가'를 추가해야 하는 이유가 여기 있다.
둘째, 코드 리뷰의 성격이 근본적으로 바뀐다. AI가 생성한 코드는 인간이 쓴 코드보다 더 꼼꼼히 검토해야 한다. AI는 비즈니스 로직도, 장기적 결과도 이해하지 못한 채 그럴듯한 코드를 뱉는다. SQL injection 취약점을 코드 구조상 문제없어 보이는 형태로 심어놓는 건 AI가 가장 잘 하는 실수 유형 중 하나다. 리뷰어는 이제 '이 코드가 잘 읽히는가'가 아니라 '이 코드가 우리 시스템의 의도를 정확히 구현했는가'를 판단하는 역할로 전환된다.
셋째, 아키텍처 결정권은 절대 위임하지 않는다. AI는 당신이 내린 결정을 구현하는 데 탁월하다. 마이크로서비스냐 모놀리스냐, 이벤트 드리븐이냐 요청-응답이냐, 도메인 모델을 어떻게 구성하느냐—이 판단들은 비즈니스 맥락과 팀의 역량, 시스템의 미래를 동시에 고려해야 한다. AI는 그 맥락이 없다. 아키텍처 주권(Architectural Sovereignty)을 유지하는 것, 이게 시니어 개발자와 AI의 가장 명확한 역할 경계선이다.
전망: '어떤 개발자를 뽑을 것인가'의 기준이 바뀐다
AI-First 팀 리빌딩을 진행하면서 가장 자주 받는 질문이 있다. "AI 잘 쓰는 개발자를 어떻게 구분하나요?" 이 세 편의 글이 제시하는 답은 역설적이다. AI를 잘 쓰는 개발자는 AI 없이도 잘 생각하는 개발자다.
알고리즘과 자료구조의 기초, 시스템 설계 원칙, 보안 취약점에 대한 감각—이것들은 AI 출력물을 평가하는 프레임워크다. 이 프레임워크가 없으면 AI가 생성한 코드의 품질을 판단할 수 없고, 판단할 수 없으면 검증도 없고, 검증이 없으면 그게 바로 도박이 된다.
반대로 온보딩 설계에서 중요해지는 건 '명세 작성 훈련'이다. 신규 팀원에게 AI 도구부터 쥐여주기 전에, 요구사항을 언어로 정밀하게 표현하는 연습을 먼저 시켜야 한다. 스펙 문서 작성, 테스트 케이스 선정의 논리, 아키텍처 결정의 맥락 문서화—이 역량들이 AI-First 환경에서의 주니어와 시니어를 가르는 새로운 기준선이 되고 있다.
'90%의 코드가 AI 생성'이 되더라도, 그 100%의 책임은 여전히 인간에게 있다. 그 책임을 지려면 생각하는 힘을 지켜야 한다. AI에게 슬롯머신을 당기는 역할을 맡길 것인가, 아니면 AI를 시니어가 지휘하는 주니어 개발자로 다룰 것인가—이 선택이 지금 모든 팀의 실질적인 분기점이다.