AI가 코딩을 '해결'했는가? AI의 영향과 함정에 대한 개발자의 관점

이 대담한 주장은 처음에는 회의적인 반응을 얻었지만, 개발자들이 AI가 일상적인 워크플로우에 미치는 영향이 커지는 것을 목격하면서 점차 인식이 바뀌었습니다. 이 논쟁의 미묘한 차이를 이해하려면 AI 개발 커뮤니티 내에서 '해결됨'과 '코딩'에 대한 다양한 해석을 인정하고, 피상적인 논의를 넘어 현재 AI 에이전트의 실제 능력과 한계를 다루어야 합니다. 연사는 "코딩은 해결되었습니다. 버그는 아직 해결되지 않았습니다. 수정이 들어옵니다."라고 말합니다.

앱은 잘린 업데이트 텍스트를 표시했는데, 이는 인간의 검증을 거쳤다면 발견되었을 시각적 결함입니다. 이 문제는 AI 이전 개발과 주요 차이점을 강조하는데, 그 당시에는 코드 검토에서 이러한 UI 관련 오류가 덜 일반적이었습니다. 연사는 "이것은 AI 생성 코드에서 항상 보는 흔한 실수인데, 솔직히 AI 생성 코드가 등장하기 전에는 그렇게 많이 발생하지 않았습니다."라고 지적합니다.

개발 분야에서 AI의 부상은 코드 검토 문화에 대한 우려스러운 변화를 초래하고 있으며, 풀 리퀘스트 제출이 더 이상 코드가 철저히 테스트되었거나 수동으로 검증되었음을 보장하지 않습니다. 이 새로운 패러다임은 개발자들이 AI 생성 코드가 존재한다는 이유만으로 기능할 것이라고 잘못 가정하게 만들며, 비판적인 인간의 감독 없이 진행됩니다. 연사는 "그러나 이제 우리는 코드 검토가 사전에 점검하는 데 어떤 노력도 기울이지 않았다는 것을 의미하지 않는 세상에 살고 있습니다."라고 강조합니다. 개발자 품질 보증 표준의 이러한 침식은 최종 사용자 경험에 직접적인 영향을 미치며, 문제를 '코딩이 해결됨'에서 '기능적 UI'가 해결되지 않은 과제로 옮겨놓습니다.

AI가 코딩을 '해결'했는지에 대한 의미 있는 논의를 하기 위해서는 '코딩'과 '해결됨'과 같은 용어에 대한 명확한 정의를 확립하는 것이 중요합니다. 연사는 화면에서 기능이 시각적으로 잘려 나갈 때 '버그'의 정의에 대한 질문을 제기하며, 이러한 문제가 전통적인 버그로 간주되지 않을 수 있지만 여전히 기능적 문제임을 강조합니다. '코딩' 자체의 정의는 단순한 텍스트 편집에서부터 포괄적인 엔드투엔드 제품 개발에 이르기까지 매우 다양하므로, 생산적인 대화를 위한 통일된 이해가 필수적입니다. 연사는 "우리가 이것에 대해 대화하려면 코딩과 해결됨이라는 단어에 대한 정의가 필요합니다."라고 말합니다.

이 게임은 의도적으로 좌절감을 주도록 설계되었으며, 오늘날 많은 웹사이트에서 흔히 볼 수 있는 지나치게 복잡한 비밀번호 요구 사항을 비웃으며 종종 사용자 경험을 저하시킵니다. 이 예시는 의도적으로 나쁜 디자인과 우연히 좋지 않은 구현이 근본적으로 코딩 행위임을 보여줍니다. 그러나 엔지니어링은 단순히 기능적인 코드를 만드는 것을 넘어 사용자 경험과 전반적인 시스템 상태에 대한 더 깊은 고려를 포함합니다.

성공적인 엔지니어링 주기는 건전한 계획과 효과적인 실행 모두에 달려 있지만, 엔지니어는 종종 제품 팀의 계획에 이의를 제기하기보다 구현해야 하는 압력에 직면합니다. 핵심 질문은 아이디어를 코드로 변환하는 것이 직업인 뛰어난 코더가 결함 있는 계획에 반대할 것인가, 아니면 코딩 능력 때문에 단순히 실행할 것인가 하는 것입니다. 연사는 뛰어난 코더가 나쁜 계획을 단순히 구현하는 것이 아니라 비판적으로 평가하고 도전하는 능력으로 구별된다고 주장합니다. 좋은 코드를 만드는 것뿐만 아니라 좋은 소프트웨어를 만드는 것에 중점을 둡니다. 왜냐하면 나쁜 계획을 훌륭하게 실행하더라도 결국 나쁜 소프트웨어로 이어질 것이기 때문입니다. 연사는 "아이디어를 코드로 바꾸는 것이 직업인 진정으로 뛰어난 코더는 나쁜 계획에 반대할까요, 아니면 코딩을 잘한다는 이유로 나쁜 계획을 실행할까요? 좋은 소프트웨어를 만드는 것이 아니라요?"라고 말합니다.

계획의 품질은 소프트웨어 프로젝트의 성공과 직접적으로 관련됩니다. 좋은 계획은 숙련된 엔지니어가 실행할 때 일반적으로 높은 성공률(10점 만점에 8~10점)을 가져옵니다. 반대로, 나쁜 계획은 엔지니어의 능력과 상관없이 거의 예외 없이 낮은 결과(종종 10점 만점에 1~4점)로 이어집니다. 또한, 모호하거나 불분명한 계획은 상당한 변동성을 유발하여 소프트웨어의 최종 품질이나 성공을 예측하기 거의 불가능하게 만듭니다. 연사는 "계획이 좋고 엔지니어가 좋으면 성공 범위는 10점 만점에 8~10점이라고 말할 수 있습니다. 나쁜 계획의 경우, 나오는 소프트웨어는 아마도 10점 만점에 1~4점 정도로 좋지 않을 것이라고 주장하고 싶습니다."라고 말합니다.

이는 종종 코드가 메인 브랜치에 병합된 후에야 인간 사용자가 결함을 발견하고 보고하게 됨을 의미합니다. 테스트되지 않은 코드를 병합하는 결과는 문제를 해결하는 데 필요한 '마찰'이 크게 증가한다는 것입니다. 개발 주기 후반에 문제를 해결하는 것이 초기에 코드를 검증하는 것보다 훨씬 더 많은 자원 집약적이기 때문입니다. 연사는 "코드를 실제로 실행하여 확인하지 않으면 괜찮아 보일 수 있지만, 누군가가 확인하기 전까지는 괜찮은지 알 수 없습니다."라고 경고합니다.

개발자가 로컬에서 코드를 설정하고 테스트하는 데 상당한 어려움을 겪는다면, 자율 에이전트는 동일한 검증 작업을 수행하는 데 훨씬 더 큰 어려움을 겪을 것입니다. 복잡하고 어려운 검증 프로세스는 본질적으로 엄격한 테스트를 저해하여 배포 전에 코드가 철저히 검사될 가능성을 낮춥니다. 검증을 복잡하게 만드는 방식으로 소프트웨어를 설계하고 구축하는 회사는 품질 문제에 가장 취약합니다. 이는 고급 AI 에이전트조차도 적절한 테스트를 방해하는 근본적인 아키텍처 결함을 보완할 수 없기 때문입니다. 연사는 "설정하고 테스트하기 너무 어렵다면, 에이전트가 동일한 작업을 수행하는 것은 훨씬 더 어렵습니다. 코드베이스를 실제로 검증하기 쉽게 만들어야 합니다."라고 말합니다.

이 피드백 메커니즘은 소프트웨어가 의도한 대로 작동하고 품질 표준을 충족하는지 확인하는 데 필수적입니다. 연사는 Claude Code 데스크톱 버전이 웹 버전보다 품질 면에서 어려움을 겪는 주된 이유가 데스크톱 애플리케이션에 대한 강력한 테스트 및 검증 프로세스를 확립하는 데 내재된 어려움 때문이라고 언급합니다. 그는 "이 소프트웨어가 작동함을 증명하는 데 필요한 훌륭한 품질 검증 루프"라고 강조합니다.

'코딩'이라는 용어는 종종 계획을 코드 라인으로 변환하는 과정으로만 좁게 정의됩니다. 그러나 소프트웨어 엔지니어링은 초기 계획 및 아키텍처 설계에서부터 실제 코딩 및 엄격한 검증에 이르기까지 전체 개발 수명 주기를 포함하는 훨씬 더 넓은 범위를 포괄합니다. 따라서 AI 에이전트가 코드를 생성할 수 있다는 이유만으로 소프트웨어 엔지니어링이 '해결되었다'는 주장은 부정확합니다. AI가 코드를 작성하는 능력은 진정한 소프트웨어 엔지니어링에 내재된 책임과 복잡성의 일부만을 다룹니다. 연사는 "소프트웨어 엔지니어링은 코드를 만드는 이 작은 부분만이 아닙니다. 소프트웨어 엔지니어링은 이 사각형 전체도 아닙니다."라고 강조합니다.

AI 에이전트도 새로운 인간 엔지니어와 마찬가지로 효과적으로 기능하기 위해 적절한 자원과 유리한 환경이 필요합니다. 제대로 설계되지 않았거나 복잡한 코드베이스 내에서 에이전트에게 맹목적으로 작업을 할당하면 필연적으로 생산성을 저해하고 생산되는 소프트웨어의 전반적인 품질을 제한할 것입니다. 검증은 여전히 중요한 단계입니다. 에이전트가 출력을 확인할 강력한 메커니즘이 없다면 그들의 기여는 신뢰할 수 없을 것이며 광범위한 인간의 감독이 필요할 것입니다. 연사는 "새로운 엔지니어가 와서 이 변경 사항을 할당받았는데 테스트 빌드를 자신의 머신에서 실행조차 할 수 없었다면, 변경 사항을 테스트할 세 명의 엔지니어와 마찬가지로 에이전트도 망한 것입니다."라고 강조합니다.

AI 에이전트가 자신의 출력을 검증할 뿐만 아니라 촉진하는 환경에서 작동하는 것이 필수적입니다. 기존 소프트웨어 공급업체는 에이전트가 자신의 작업을 검증하고 성과에 대한 입증 가능한 증거를 제공할 수 있도록 특정 계층과 인터페이스를 노출해야 합니다. 이러한 검증 메커니즘이 없으면 에이전트는 기여에 눈에 띄는 실패가 포함되어 있음에도 불구하고 종종 성공을 주장하며, 인간 엔지니어의 수동 수정이 필요하게 됩니다. 이는 AI 생성 코드의 품질과 정확성을 보장하기 위한 인간 감독의 지속적인 필요성을 강조합니다. 연사는 "우리는 에이전트가 자신의 작업을 검증하고 그렇게 했음을 증명할 수 있는 방식으로 노출되어야 합니다."라고 말합니다.

시각적인 코드 검토는 종종 많은 유형의 버그를 잡기에 불충분합니다. 기능적 결함은 겉보기에는 올바른 코드 안에 숨어 있는 경우가 많기 때문입니다. 단순히 코드를 읽는 전통적인 방법은 운영상의 결함을 효과적으로 식별하는 데 한계에 도달했습니다. 아키텍처 문제는 여전히 인간의 눈으로 발견될 수 있지만, 기능적 버그는 라이브 실행 및 테스트를 통해 감지되어야 합니다. 따라서 소프트웨어의 실제 동작을 테스트하는 데 중점을 두는 결과 중심 코드 검토로의 전환이 필요합니다. 연사는 "우리는 코드가 아니라 결과를 확인해야 합니다. 솔직히 말해서 코드는 괜찮아 보였기 때문에 코드 검토에서 이 버그를 잡았을 사람은 아무도 없었을 것입니다."라고 강조합니다.

Boris의 '코딩은 해결되었다'는 도발적인 주장은 많은 개발자들의 이 용어에 대한 더 넓은 이해와 충돌했기 때문에 상당한 반발을 불러일으켰습니다. 이러한 이견은 개발에서 AI의 역할에 대한 논의에서 정확한 용어의 중요성을 강조합니다. 연사는 "그것이 '코딩은 해결되었다'는 것의 전부입니다. 특히 코딩에 대한 정의가 다르다면요."라고 말합니다.

점점 더 많은 최고 수준의 엔지니어들이 AI 에이전트를 단순히 간단한 코드 변경뿐만 아니라 복잡한 이론을 테스트하고 이전에는 너무 시간이 많이 걸려서 착수할 수 없었던 야심찬 작업을 탐색하는 데 활용하고 있습니다. 이러한 에이전트는 아이디어의 병렬 실행을 가능하게 하여 개별 엔지니어가 달성할 수 있는 범위을 크게 확장합니다. 이러한 변화는 선도적인 전문가들 사이에서 AI가 자신의 능력을 향상시키는 강력한 도구가 될 수 있으며, 더 높은 수준의 문제 해결에 집중할 수 있게 한다는 인식이 커지고 있음을 나타냅니다. 연사는 "저는 세계 최고의 상위 계층 엔지니어들이 이러한 에이전트를 활용하여 많은 코딩 작업을 수행할 수 있다는 것을 점점 더 많이 깨닫고 있는 것을 보고 있습니다."라고 말합니다.

전술적 프로그래밍은 코딩의 일상적이고 현장적인 측면을 의미하며, 즉각적인 구현 및 문제 해결을 포함합니다. 대조적으로 전략적 프로그래밍은 코드베이스의 장기적인 건전성, 아키텍처 결정 및 미래 확장성에 중점을 둡니다. 현재 AI 에이전트는 '전술적 회오리바람'으로서 매우 효과적이며, 빠른 코드 생성 및 지역화된 작업에 뛰어나지만, 장기 계획 및 아키텍처 결정에 필요한 전략적 사고 능력은 대체로 부족합니다. 연사는 "그는 John Ousterhout의 전술적 프로그래밍 대 전략적 프로그래밍 정의를 인용합니다. 전술적은 코딩의 현장 일상적인 측면이고, 전략적은 장기적인 것입니다"라고 인용합니다.

AI 에이전트를 사용하여 파이프라인을 자동화하려면 필요한 프레임워크와 지침을 설정하기 위해 상당한 인간 엔지니어링 노력이 사전에 필요합니다. 인간의 판단은 복잡한 의사 결정과 전략적 통찰력이 중요한 RFC(Request for Comments) 및 아키텍처 변경과 같은 고수준 프로세스를 관리하는 데 여전히 필수적입니다. 이는 에이전트가 전술적 코딩 작업을 처리할 수 있지만, 효과적이고 전략적인 AI 파이프라인을 설계하고 유지 관리하는 데 인간의 감독과 엔지니어링 전문 지식이 여전히 필수적임을 나타냅니다. 연사는 "에이전트가 더 전략적으로 행동하고 더 엔지니어처럼 행동하게 만들려면 먼저 직접 엔지니어링 작업을 수행해야 합니다."라고 말합니다.