AI 시대에도 코드는 죽지 않는다 — '정밀도'라는 관점에서 본 프로그래밍의 미래

코드의 종말이라는 예언

최근 몇 년간 "코드를 직접 작성하는 시대는 끝났다"는 주장이 끊임없이 등장하고 있습니다. LLM이 자연어만으로 소프트웨어를 만들어주는 시대가 오면 개발자가 필요 없어질 것이라는 논리입니다. GitHub Copilot이 코드를 자동 완성해주고, Claude나 ChatGPT가 전체 함수를 생성해주는 현실을 보면 일리가 있어 보이기도 합니다. 하지만 실제로 AI 코딩 도구를 깊이 사용해본 개발자라면 한 가지 근본적인 문제를 체감하게 됩니다. 바로 정밀도(precision)의 문제입니다.

Steve Krouse는 자신의 글에서 이 핵심을 정확히 짚어냅니다. 코드가 사라질 것이라는 예측이 과장되었다는 것, 그리고 그 이유가 바로 프로그래밍 언어가 제공하는 정밀한 의사 표현 능력에 있다는 것입니다.

자연어의 근본적 한계: 모호함

프로그래밍 언어가 존재하는 이유를 곰곰이 생각해보면, 결국 자연어가 소프트웨어의 동작을 기술하기에 너무 모호하기 때문입니다. "사용자가 로그인하면 대시보드를 보여줘"라는 문장 하나만 해도, 실제 구현에서는 수십 가지 결정이 필요합니다. 어떤 인증 방식을 사용할 것인가? 세션은 어디에 저장할 것인가? 비밀번호를 틀리면 어떻게 할 것인가? 동시 로그인은 허용할 것인가?

자연어로 이 모든 것을 기술하려면, 결국 코드를 작성하는 것 이상으로 긴 명세서를 써야 합니다. 그리고 그 명세서조차 해석의 여지가 남습니다. 프로그래밍 언어는 바로 이 모호함을 제거하기 위해 만들어진 도구입니다. if, else, for, return 같은 키워드는 단 하나의 의미만 가집니다. 이것이 코드의 본질적 가치입니다.

바이브 코딩의 한계가 보여주는 것

요즘 "바이브 코딩(vibe coding)"이라는 말이 유행하고 있습니다. AI에게 대충 의도를 던져주고, AI가 생성한 코드를 직접 검토하지 않고 그대로 사용하는 방식을 말합니다. 프로토타이핑이나 일회성 스크립트에는 꽤 효과적입니다. 하지만 프로덕션 수준의 소프트웨어를 이 방식으로 만들 수 있을까요?

현실에서 바이브 코딩의 한계는 빠르게 드러납니다. AI가 생성한 코드가 대부분의 케이스에서는 동작하지만, 엣지 케이스에서 미묘한 버그를 만들어내는 경우가 흔합니다. 그리고 그 버그를 자연어로 설명해서 수정하려고 하면, 한 곳을 고치면서 다른 곳이 깨지는 상황이 반복됩니다. 결국 코드를 직접 읽고 이해하고 수정하는 능력이 없으면, AI 도구조차 제대로 활용할 수 없습니다.

이는 마치 자동차의 자율주행 기능과 비슷합니다. 레벨 2 자율주행은 운전을 보조하지만, 운전자가 항상 핸들을 잡고 있어야 합니다. AI 코딩 도구도 마찬가지입니다. 코드를 생성해주지만, 그 코드의 정확성을 판단하고 방향을 잡는 것은 여전히 개발자의 몫입니다.

정밀도 스펙트럼: 추상화 수준의 문제

코드가 사라질 것이라는 예측의 핵심 오류는 추상화 수준의 변화를 코드의 소멸로 착각한다는 점입니다. 역사적으로 프로그래밍은 계속 더 높은 수준의 추상화로 이동해왔습니다. 어셈블리에서 C로, C에서 Python으로, 그리고 프레임워크와 라이브러리의 발전까지. 매번 "이제 저수준 코드는 필요 없다"는 말이 나왔지만, 실제로 일어난 것은 새로운 추상화 계층 위에서 새로운 종류의 코드를 작성하게 된 것이었습니다.

AI 코딩 도구도 같은 패턴을 따릅니다. 보일러플레이트 코드를 AI가 생성해주면, 개발자는 더 높은 수준의 아키텍처 결정과 비즈니스 로직에 집중할 수 있게 됩니다. 하지만 그 결정을 정밀하게 표현하는 수단은 여전히 코드(혹은 코드와 유사한 형식적 언어)입니다. 자연어 프롬프트가 이를 완전히 대체하려면, 자연어 자체가 형식 언어만큼 정밀해져야 하는데, 그 시점에서 그것은 이미 프로그래밍 언어의 한 형태가 됩니다.

개발자의 역할은 변하지만 사라지지 않는다

이 논의에서 놓치기 쉬운 포인트가 있습니다. AI 도구가 발전할수록 좋은 코드를 읽고 판단하는 능력의 가치가 오히려 높아진다는 것입니다. AI가 초안을 작성하는 세상에서 차별화되는 역량은 그 초안을 평가하고, 올바른 방향으로 수정하고, 전체 시스템의 맥락에서 적절한 결정을 내리는 능력입니다.

코드 리뷰를 생각해보세요. 주니어 개발자의 코드를 리뷰할 때, 단순히 동작 여부만 보는 것이 아니라 유지보수성, 확장성, 성능, 보안 등 여러 차원을 동시에 고려합니다. AI가 생성한 코드에 대해서도 똑같은 판단이 필요합니다. 어쩌면 더 까다로운 판단이 필요할 수 있습니다. AI는 자신감 있게 잘못된 패턴을 사용하는 경우가 많으니까요.

한국 개발자에게 주는 시사점

이 논의는 한국 개발 현장에서도 매우 현실적인 의미를 가집니다. 최근 많은 기업이 AI 코딩 도구를 도입하고 있고, 일부에서는 "개발자 수를 줄일 수 있지 않을까"라는 기대도 있습니다. 하지만 현실은 AI 도구를 잘 활용하는 개발자와 그렇지 못한 개발자 사이의 생산성 격차가 벌어지는 것에 가깝습니다.

실무적으로 권장할 수 있는 접근은 이렇습니다. AI 코딩 도구를 적극적으로 활용하되, 코드를 직접 읽고 이해하는 능력을 소홀히 하지 마세요. 프롬프트 엔지니어링보다는 소프트웨어 설계 원칙과 시스템 사고 능력을 키우는 것이 장기적으로 더 가치 있는 투자입니다. AI가 아무리 발전해도 "이 시스템이 이렇게 동작해야 하는 이유"를 정밀하게 정의하는 것은 사람의 몫으로 남을 가능성이 높습니다.