AI가 기본기를 더 가치 있게 만든 이유: 가치가 낮아진 것이 아니라

두 명의 개발자가 동일한 기능, 즉 쿼리 문자열과 일치하는 사용자를 반환하는 검색 엔드포인트 (search endpoint)를 구축하기 위해 앉았습니다. 두 사람 모두 Claude Code를 열어두었습니다. 두 사람 모두 대략적으로 동일한 프롬프트 (prompt)를 입력했습니다: "페이지네이션 (pagination) 기능이 포함된, 이름으로 사용자를 검색하는 REST 엔드포인트를 만들어줘." 5분 후, 두 사람 모두 작동하는 코드를 갖게 되었습니다. 컴파일도 됩니다. 테스트도 통과합니다. 엔드포인트는 결과를 반환합니다. 하지만 코드는 동일하지 않습니다.

3년 차 경력의 개발자 A는 첫 번째 출력물을 그대로 수용합니다. 그것은 LIMIT와 OFFSET을 사용한 SELECT * FROM users WHERE name LIKE '%query%'를 사용합니다. 사용자 50명인 개발 환경에서는 잘 작동합니다. 하지만 사용자 50,000명에서는 깨질 것이고, 500,000명에서는 전체 서비스를 느리게 만들 것입니다. 12년 차 경력의 개발자 B는 출력물을 읽고 후속 질문을 던집니다: "우리의 예상 규모 (scale)는 어느 정도인가요? 그리고 사용자 테이블의 인덱스 전략 (index strategy)은 무엇인가요?" 수정된 코드는 전문 검색 인덱스 (full-text index), 커서 기반 페이지네이션 (cursor-based pagination), 적절한 쿼리 제한 (query limits), 인기 검색어를 위한 캐시 레이어 (cache layer), 그리고 속도 제한기 (rate limiter)를 사용합니다. 이것은 사용자 50명인 개발 환경에서도 작동합니다. 또한 500만 명의 사용자 환경에서도 작동합니다. 동일한 AI. 동일한 프롬프트 구조. 동일한 소요 시간. 하지만 근본적으로 다른 코드입니다.

이것은 AI에 대한 비난이 아닙니다. AI는 요청받은 일을 정확히 수행했습니다 — 그것도 두 번이나 말이죠. 이것은 개발자가 상호작용에 무엇을 가져오는지, 그리고 왜 "AI가 코딩을 민주화한다"는 서사가 거꾸로 가고 있는지에 관한 것입니다.

모두가 했던 가정
2022년 ChatGPT가 폭발적으로 성장했을 때, 기술 미디어의 지배적인 이야기는 다음과 같았습니다: "AI가 개발자들 사이의 운동장을 평평하게 만들 것이다." 프롬프트를 잘 작성하는 주니어 (junior)가 아키텍처 (architect)를 설계할 수 있는 시니어 (senior)와 대등해질 것이라는 내용이었습니다. 부트캠프 (bootcamps)가 그 격차를 더 빠르게 줄일 것이라고 했습니다. 깊은 전문 지식의 경제적 가치는 하락할 것이라고 했습니다. 이것은 결코 사실이 아니었습니다. 이제 그것은 명백히 사실이 아닙니다. 그리고 그 증거는 지난 18개월 동안 AI의 도움을 받아온 모든 코드베이스 (codebase)에 들어 있습니다. AI는 운동장을 평평하게 만든 것이 아닙니다. 오히려 한쪽으로 더 기울게 만들었습니다.

AI가 실제로 하는 일
AI 코딩 어시스턴트 (AI coding assistants)는 특정한 종류의 작업에 매우 탁월합니다: 인간의 명확한 의도 (clear intent)를 작동하는 코드로 번역하는 일 말입니다. 그 "명확한 의도"가 바로 결정적인 자격 요건입니다.

다음 사항들을 알고 있는 개발자:

• 사용자 테이블에 수백만 개의 행(rows)이 쌓일 것이라는 점
• LIKE '%query%'는 인덱스(index)를 사용하지 않는다는 점
• 대규모 환경에서는 커서 기반 페이지네이션(cursor-based pagination)이 오프셋 기반(offset-based)보다 안전하다는 점
• 검색 트래픽이 급증(spiky)할 수 있다는 점
• 캐싱(caching)이 일관성(consistency) 문제를 야기한다는 점

이러한 개발자는 AI에게 이 모든 지식이 반영된 코드를 생성하도록 프롬프트(prompt)를 작성할 수 있습니다. 프롬프트는 짧지만, 결과물은 정교합니다. 개발자는 AI가 기계적인 번역을 처리하는 동안 의사 결정, 아키텍처(architecture), 리뷰와 같이 중요한 부분에 시간을 할애합니다. 반면, 이러한 것들을 모르는 개발자는 이를 반영하지 못하는 프롬프트를 작성합니다. AI는 개발자가 미처 생각하지 못해 묻지 않은 내용을 알 방법이 없습니다. AI는 학습 데이터에서 가장 흔한 패턴으로 빈칸을 채우는데, 이는 튜토리얼이나 소규모 프로젝트에는 적절할지 몰라도 프로덕션 시스템(production systems)에서는 명백히 틀린 경우가 많습니다. 프롬프트가 기술은 아닙니다. 프롬프트를 형성하는 지식이 바로 기술입니다. AI는 이제 단 한 명의 개발자가 가진 지식을 10배 더 많은 코드에 적용할 수 있게 함으로써, 시간당 그 지식의 가치를 더욱 높였습니다.

보이지 않는 격차
여기 불편한 진실이 있습니다. AI 이전에는 주니어와 시니어의 코드 차이가 눈에 보였습니다. PR 디프(PR diffs)를 통해 확인할 수 있었죠. 시니어의 코드는 더 짜임새 있고, 더 사려 깊으며, 에러 처리(error handling)가 더 뛰어나고, 추상화(abstraction)가 더 깔끔한 등 다르게 보였습니다. 코드 리뷰어는 특정 줄을 가리키며 "이것이 우리가 다르게 처리하는 이유입니다"라고 말할 수 있었습니다. 하지만 AI와 함께라면, 그 격차는 '작성되지 않은 코드' 속에 숨겨집니다. 주니어의 코드는 깨끗해 보일 수 있습니다. 린터(linter)를 통과하고, 테스트도 갖추고 있습니다. 대충 훑어보면 아무런 문제도 보이지 않습니다. 하지만 아키텍처는 미묘하게 어긋나 있습니다. AI에게 묻지 않았기 때문에 엣지 케이스(edge cases)가 고려되지 않았습니다. 개발자가 물어야 한다는 사실조차 몰랐기 때문에 확장성(scaling)에 대한 고려도 없습니다. 이러한 버그들은 스테이징(staging) 환경에서는 나타나지 않습니다. 서비스가 부하 상황에서 타임아웃(timeout)이 발생하기 시작하고 아무도 이유를 파악하지 못하는 6개월 뒤 새벽 3시에 나타납니다. 일반적인 코드 작업에서 주니어와 시니어 사이의 생산성 격차는 대략 2~3배 정도였습니다.

AI와 함께라면 그 격차는 5~10배로 벌어졌다고 주장하기 쉽습니다. 이는 시니어 (Seniors)가 더 빨라졌기 때문만이 아니라 (물론 그들도 빨라졌지만), 주니어들이 시니어의 속도로 코드를 생산하기 시작했기 때문입니다. 하지만 그 코드에는 오직 시니어만이 잡아낼 수 있는 숨겨진 문제들이 포함되어 있습니다.

시니어들이 조용히 알고 있는 사실
AI를 1년 동안 사용해 온 숙련된 엔지니어들에게 이야기해 보면, 모순적으로 들리는 말을 할 것입니다. "AI는 나의 생산성을 극적으로 높여주었습니다." 그리고 "AI는 나를 덜 주의 깊게 만드는 것이 아니라, 더 주의 깊게 만듭니다." 이 두 말은 모두 사실입니다. 생산성 향상은 AI가 상용구 코드 (Boilerplate), 테스트 (Tests), 문서 (Docs), 그리고 단순한 구현 (Straightforward implementations)을 처리하는 데서 옵니다. 주의력이 높아진 이유는 AI가 100%의 확신을 가지고 미묘하게 틀린 코드 (Subtly-wrong code)를 기꺼이 생성할 것이라는 점을 알고 있기 때문이며, 이 위험을 완전히 제거할 수 있는 프롬프트 (Prompt)는 존재하지 않습니다.

제가 함께 일해온 시니어들은 AI의 결과물을 유능하지만 감독이 필요한 주니어 개발자를 대하듯 다룹니다. 즉, 신뢰하되 공격적으로 검증 (Trust, but verify aggressively)합니다. 모든 가정을 확인하고, 모든 예외 케이스 (Edge case)를 고려하며, 모든 최적화 결정은 '왜' 그런지를 이해하는 인간이 내립니다. 아이러니하게도, AI는 시니어를 쓸모없게 만든 것이 아닙니다. 오히려 이제는 10배 더 빠르게 코드를 생산하는 파이프라인 (Pipeline) 내에서 시니어를 결정적인 품질 필터 (Quality filter)로 만들었습니다.

주니어들에게 팔리는 서사 vs. 실제로 일어나고 있는 일
주니어들에게 전달되는 서사는 다음과 같습니다. "AI 도구를 배우면 취업할 수 있습니다. AI가 코딩을 하고, 당신은 이를 조율 (Orchestrate)하면 됩니다." 하지만 현실은 더 가혹하며 동시에 더 유용합니다. AI는 당신의 코딩 결과물을 훨씬 더 빨리 가시화하며, 이는 당신의 코딩 약점 또한 훨씬 더 빨리 드러난다는 것을 의미합니다. 전문적인 환경에서 AI의 도움을 받아 코드를 배포하는 주니어는, 모든 것을 직접 손으로 쓰는 주니어보다 잘못된 코드에 대한 피드백을 10배 더 빨리 받게 됩니다. 이는 좋은 현상입니다. 더 빠른 학습 루프 (Learning loop)가 형성되는 것이니까요. 하지만 이는 주니어가 단순히 AI의 다음 제안을 수용하는 것이 아니라, 피드백으로부터 실제로 배우고 있을 때에만 유효합니다.

향후 5년 동안 번창할 주니어들은 AI를 학습 도구 (learning tool)로 사용하는 이들입니다. 즉, 코드가 왜 작동하는지 질문하고, AI의 제안에 이의를 제기하며, AI가 생성한 결과물 이면의 문서 (documentation)를 읽고, 가설을 검증하기 위해 실험을 수행하는 이들입니다. 반면, 정체될 주니어들은 AI를 지팡이 (crutch)로 사용하는 이들입니다. 결과물을 그대로 수용하고, 통과되는 대로 배포하며, 근저에 깔린 패턴을 결코 이해하지 못하는 이들입니다. AI가 기초 (fundamentals) 학습을 대체한 것이 아닙니다. AI는 기초를 학습한 개발자와 그렇지 않은 개발자 사이의 차이를 더 명확하고 빠르게 만들었을 뿐입니다.

가치가 상승한 기술들. 만약 당신이 AI가 계속해서 발전할 것이라는 점을 인지한 상태에서 지금 당장 기술에 투자해야 한다면, 어디에 투자하시겠습니까? 틀린 답은 프롬프트 엔지니어링 (prompt engineering)입니다. 프롬프트 기술은 2008년에 구글링 (Google)하는 법을 아는 것과 같습니다. 일시적으로는 가치가 있지만, 결국에는 보이지 않게 될 것입니다. 정답은 AI가 잘할 수 없고, 앞으로도 오랫동안 잘하지 못할 모든 것입니다.

시스템 디자인 (System design). AI는 컴포넌트 (components)를 생성할 수 있습니다. 하지만 어떤 컴포넌트가 존재해야 하는지, 그것들이 어떻게 상호작용해야 하는지, 혹은 어떤 경계 (boundaries)를 설정해야 하는지는 아직 결정할 수 없습니다. 이것은 아키텍처 (architecture)이며, 인간의 영역입니다.

운영 환경의 디버깅 (Debugging production issues). AI는 로그 (logs)를 읽고, 서비스 간의 이벤트를 상관 분석하며, 가설을 세우고 이를 테스트해야 하는 문제에는 놀라울 정도로 취약합니다. 새벽 3시의 알람을 보고 10분 만에 근본 원인 (root cause)을 좁혀낼 수 있는 개발자는, AI에게 도움을 요청하고 유용한 답변을 기다리는 개발자보다 100배 더 가치 있습니다.

시간 압박 속에서의 코드 리뷰 (Code review under time pressure). AI가 더 많은 코드를 더 빠르게 생성함에 따라, 병목 현상 (bottleneck)은 리뷰가 됩니다. AI가 생성한 400줄짜리 PR (Pull Request)을 훑어보고, 규모가 커졌을 때 실패할 가설을 즉시 찾아낼 수 있는 개발자는 필수불가결한 존재가 됩니다.

시스템에 대한 깊은 이해 (Understanding systems deeply). 당신의 데이터베이스 쿼리 플래너 (query planner)는 어떻게 작동합니까? 클릭과 리렌더링 (re-render) 사이의 브라우저 내부에서는 어떤 일이 일어납니까? git bisect는 내부적으로 실제로 무엇을 수행합니까? AI는 표면적인 답변을 줄 수는 있지만, 이러한 시스템을 구축하고 디버깅하며 얻게 되는 직관 (intuition)을 줄 수는 없습니다.

그러한 직관 (intuition)이야말로 애초에 올바른 프롬프트 (prompt)를 작성할 수 있게 해주는 힘입니다. 코드가 아니라, 글쓰기 (prose)를 포함해서 말입니다. 왜 특정 결정이 중요한지 설명할 수 있고, 명확한 RFC (Request for Comments)를 작성하며, 다음 사람이 이해할 수 있도록 시스템을 문서화할 수 있는 개발자는, 아무도 유지보수할 수 없는 코드를 5배 더 많이 생산하는 개발자보다 뛰어난 성과를 낼 것입니다. 이들의 공통점을 주목하십시오. 이 중 그 어느 것도 AI에 관한 것이 아닙니다. 이 모든 것은 AI가 우연히 그 가치를 부각시킨 기본기 (fundamentals)들입니다.

여러분의 커리어에 주는 실질적인 시사점:

주니어 (junior)라면: AI를 학습 도구로 활용한다면 환상적인 도구가 될 것입니다. AI가 생성하는 모든 줄에 대해 설명을 요구하십시오. 왜 대안 대신 이 패턴을 선택했는지 물으십시오. 코드를 실행하기 전에 동작을 예측하고 실행해 보십시오. 첫 번째 제안에 의문을 제기하십시오. 만약 여러분이 AI가 생성한 결과물을 그대로 배포하고 다음 단계로 넘어가기만 한다면, 여러분은 배우고 있는 것이 아니라 여러분의 성장을 블랙박스 (black box)에 위임하고 있는 것입니다.

미드 레벨 (mid-level)이라면: 지금은 넓이가 아니라 깊이에 투자해야 할 시기입니다. 아마 여러분은 12개의 프레임워크 (framework)를 피상적으로 알고 있을 것입니다. 데이터베이스 (database), 프로토콜 (protocol), 디자인 패턴 (design pattern) 중 한 분야를 선택하여, 그에 관한 책을 쓸 수 있을 정도의 수준까지 학습하십시오. AI가 표면적인 지식을 무료로 제공하게 될 때, 여러분을 차별화해 주는 것은 바로 그 깊이입니다.

시니어 (senior) 또는 테크 리드 (tech lead)라면: 여러분의 직무 기술서 (job description)는 바뀌었지만, 대부분의 회사는 직함을 업데이트하지 않았습니다. 여러분은 더 이상 핵심 코드를 직접 작성하는 사람이 아닙니다. 여러분은 그 코드를 누가 혹은 무엇이 만들었든 상관없이, 핵심 코드가 정확한지 확인하는 사람입니다. 검토 기준 (review bar)은 높아져야 합니다. 여러분의 기준은 명시적이어야 하며 반드시 준수되어야 합니다. 주니어들에게는 더 많은 멘토링 (mentorship)이 필요합니다. AI가 그들이 여전히 얼마나 더 배워야 하는지를 숨길 수 있기 때문입니다.

채용 담당자라면:

이 책은 기본기(fundamentals)를 다룹니다. Git이 실제로 어떻게 작동하는지, 팀이 어떻게 협업하는지, CI/CD 파이프라인이 어떻게 프로덕션(production)을 보호하는지, 그리고 방법론을 워크플로우(workflow)에 어떻게 맞추는지에 대해 다룹니다. 이것들은 AI가 코드를 생성할 때 당신이 이미 알고 있다고 가정하는 것들입니다. 만약 AI가 향후 10년 동안 나의 코파일럿(co-pilot)이 될 것이라면, 나는 내 밑의 토대가 견고하기를 바랍니다. 나는 git bisect가 무엇을 하는지 충분히 이해하여, AI가 이를 사용하라고 제안했을 때 그것이 틀렸음을 알 수 있기를 바랍니다. 나는 브랜치 전략(branch strategies)을 충분히 이해하여 AI에게 "아니요, 여기서는 Git Flow를 사용하지 않으니 제안을 수정하세요"라고 말할 수 있기를 바랍니다. 나는 프로덕션 디버깅(production debugging)을 충분히 이해하여, AI가 추론(reasoning)을 하고 있는지 아니면 단순히 추측(guessing)을 하고 있는지 알 수 있기를 바랍니다. 그것이 제가 쓴 책입니다. 그리고 만약 이 포스트의 논지가 맞다면, 이 책은 3년 전보다 오늘날 더 가치 있습니다.

한 문장으로 요약하자면, AI는 훌륭한 평등화 도구(equalizer)가 아닙니다. 그것은 훌륭한 증폭기(amplifier)입니다. AI는 당신이 이미 가진 것을 증폭시킵니다. 더 좋게 만들 수도, 더 나쁘게 만들 수도 있습니다. 향후 10년 동안 번창할 개발자들은 AI가 표면적인 기술(surface skills)을 소모품처럼 보이게 만들 때 기본기에 투자한 사람들입니다. 기본기를 건너뛰지 마세요. 그것은 선택 사항이 아닙니다. 그 어느 때보다 지금 더 중요합니다.

저는 현업 개발자들을 위해 Git과 엔지니어링 실무(engineering practice)에 대해 글을 씁니다. 저의 저서인 Git in Depth는 AI가 당신이 이미 알고 있다고 가정하는 기본기들을 담은 658페이지 분량의 책입니다. Git과 엔지니어링 실무에 관한 저의 모든 글은 다음에서 확인하실 수 있습니다: dev.to/mdenda .