AI가 앱을 만들 수 있다는 것. 하지만 왜 작동하지 않는지 아십니까?

하나의 언어. 하나의 프레임워크. 다수의 코딩 에이전트. 그리고 소프트웨어가 어떻게 작동하는지 배울 필요가 없다고 듣는 개발자 세대.

AI 에이전트를 사용해 일주일 만에 애플리케이션을 구축한다고 상상해 보세요.

프론트엔드는 작동합니다. 백엔드도 작동합니다. 배포까지 마쳤습니다. 모든 것이 완벽해 보입니다.

그런데 프로덕션 환경에서 오류가 발생합니다.

AI 에이전트에게 수정하라고 요청합니다. 코드를 다시 작성합니다. 여전히 작동하지 않습니다. 다른 모델을 사용하고, 다른 프롬프트를 시도하며, 또 다른 접근 방식을 취해봅니다.

3시간과 100달러의 토큰을 사용한 끝에, 문제는 애초에 코드에 있는 것이 아니었음을 발견합니다.

사용자의 AWS Lambda 함수가 적절한 네트워크 경로를 통해 외부 서비스에 도달할 수 없는 VPC(Virtual Private Cloud) 내부에서 실행되고 있었던 것입니다.

자바스크립트(JavaScript) 코드를 아무리 많이 다시 작성해도 그 문제는 해결되지 않았을 겁니다.

그리고 이것이 바로 제가 현재 AI 지원 개발을 둘러싼 대화가 중요한 무언가를 놓치고 있다고 생각하는 이유입니다.

소프트웨어 구축은 쉬워지고 있지만, 소프트웨어를 이해하는 것은 그렇지 않습니다.

1. 저는 예전에 Nokia Snake Game을 만들었습니다. 이제는 AI가 만든 앱에 대한 피드백을 받는 것이 어렵습니다.

옛날 Nokia 휴대폰에 기본으로 탑재되어 있던 게임, Snake을 기억하십니까? XD

2017년에서 2019년 사이에 저는 저만의 Snake Game을 만들었습니다. 인터넷에 무언가를 올리고 무작위의 낯선 사람들이 그것을 발견하는 것이 얼마나 흥분되는 일이었는지 기억합니다.

스타트업도 아니었고, 정교한 백엔드나 AI 기반 워크플로우, 혹은 열일곱 개의 GitHub Actions 같은 것도 없었습니다.

그냥 게임이었습니다. 하지만 사람들이 그것을 찾아 플레이할 수 있었습니다.

시간이 흘러 오늘날까지 왔습니다.

저는 AI 에이전트를 사용해 일주일 만에 훨씬 더 정교한 애플리케이션을 구축할 수 있습니다. 컴포넌트(component)를 생성하고, API를 구현하며, 데이터베이스를 연결하고, 버그를 수정하고, 작동하는 제품을 배포할 수 있습니다.

그리고 그것을 공유합니다.

하지만 때로는 아무 일도 일어나지 않습니다.

의미 있는 피드백이 없습니다. 자신들이 무엇에 혼란스러워했는지 말해주는 사람이 없습니다. 제품을 왜 사용하지 않을지 설명해 주는 사람도 없습니다.

물론 인터넷은 변했고, 경쟁은 심화되었으며, 조회수가 진정한 참여를 보장하는 경우는 결코 없었습니다.

그럼에도 불구하고 대비되는 점이 이상합니다.

무언가를 만드는 것은 쉬워졌지만, 누군가 그것에 관심을 갖게 하는 것은 어려워졌습니다.

AI는 제품을 생산하는 데 도움을 줄 수 있습니다. 하지만 관심(attention), 신뢰(trust), 또는 수요(demand)를 보장할 수는 없습니다.

이것이 제가 업계에 진입하는 모든 개발자가 스스로에게 던져야 할 질문으로 이어집니다: 지금 우리가 실제로 시간을 들여 배워야 할 것은 무엇일까요?

2. 단 하나의 언어, 단 하나의 프레임워크 시대

저는 최근 Hitesh Choudhary의 영상을 보았는데, 이 영상은 제가 소프트웨어 개발을 배우는 방식에 대해 재고하게 만들었습니다. 즉, 기술 사이를 끊임없이 뛰어다니기보다는, 하나의 언어와 하나의 프레임워크를 깊이 있게 마스터하는 데 집중해야 한다는 것입니다.

전통적인 학습 주기를 생각해 보세요.

JavaScript. React. Next.js. Angular. NestJS. AI가 존재하기 때문에 Python. X의 누군가가 성능이 중요하다고 말했기 때문에 Rust.

여섯 개의 미완성 과정 끝에, 당신은 여전히 비동기 함수(asynchronous function) 디버깅에 불편함을 느낍니다.

저도 이 함정에 빠진 적이 있습니다.

하지만 AI 에이전트가 이미 여러 언어와 프레임워크에 걸쳐 코드를 생성할 수 있다면, 생산성을 갖추기 위해 정말로 이 모든 것을 마스터해야 할까요?

저는 그렇지 않다고 생각합니다.

만약 당신이 인턴십을 준비하는 2학년 학생이라면, 더 나은 전략은 강력한 프로그래밍 기초를 다지고, 하나의 주력 언어를 마스터하며, 실제 애플리케이션을 구축하고, 디버깅하고, 테스트하고, 유지보수할 수 있을 만큼 한 프레임워크를 잘 이해하는 것입니다.

Python 스크립트가 필요합니까? 에이전트가 도와줄 수 있습니다.

Go로 된 서비스가 필요합니까? 에이전트가 도와줄 수 있습니다.

한 번도 사용해 본 적 없는 프레임워크로 작업해야 합니까? 에이전트가 그 관례(conventions)를 설명하고 초기 구현을 생성할 수 있습니다.

모든 언어를 사용하기 전에 외울 필요는 없습니다. 하지만 각 언어가 무엇 때문에 다른지 이해할 필요는 있습니다.

Python은 데이터 과학과 자동화에 유용합니다. C++는 성능에 민감한 시스템을 위한 낮은 수준의 제어(low-level control)를 제공합니다. Rust는 소유권 모델(ownership model)을 통해 메모리 안전성 보장(memory-safety guarantees)을 제공합니다. JavaScript의 비동기 실행 모델(asynchronous execution model)은 웹 애플리케이션의 동작 방식을 결정합니다.

에이전트가 이 모든 언어로 코드를 생성할 수 있습니다. 하지만 그렇다고 해서 에이전트가 자동으로 올바른 추상화(abstractions), 성능 최적화, 또는 동시성 모델(concurrency model)을 선택한다는 의미는 아닙니다.

목표는 새로운 것을 만지기 전에 모든 것을 배우는 것이 아닙니다.

한 스택(stack)을 깊이 이해하고, 언어 전반에 걸쳐 적용되는 개념들을 학습하며, 에이전트를 사용하여 의존하게 되지 않으면서도 역량을 확장하는 것입니다.

3. "더 이상 코딩을 배울 필요가 없다." 이것이 함정입니다.

YouTube에는 AI가 대신해 줄 수 있기 때문에 더 이상 코드를 배울 필요가 없다고 말하는 사람들이 가득합니다.

여기에는 어느 정도 진실이 있습니다.

모든 API를 외우거나 모든 컴포넌트를 수동으로 작성할 필요는 없습니다.

하지만 이러한 주장을 하는 많은 숙련된 개발자들은 이미 데이터베이스, 네트워킹, 운영체제(operating systems), 보안, 그리고 프로덕션 실패(production failures)에 대한 이해를 바탕으로 수년간 시간을 보냈습니다.

그들은 에이전트가 생성한 결과물에 의문을 제기할 만큼 충분히 많이 알고 있습니다.

두 명의 개발자가 같은 에이전트에게 인증 시스템을 구축해달라고 요청하는 상황을 상상해 보세요.

둘 다 작동하는 코드를 얻습니다. 둘 다 성공적으로 로그인할 수 있습니다.

하지만 구현에 권한 부여 취약점(authorization vulnerability)이 포함되어 있다면 어떨까요? 한 사용자가 요청에서 식별자(identifier)를 변경함으로써 다른 사용자의 데이터에 접근할 수 있게 된다면요?

경험 많은 엔지니어는 무엇을 조사해야 하는지 인식할 가능성이 더 높습니다. 초보자는 문제 자체가 존재한다는 사실조차 모를 수도 있습니다.

코딩을 배울 필요가 없다는 조언은 종종 코딩보다 훨씬 더 많은 것을 이미 학습한 사람들에게 가장 효과적입니다.

AI는 구현(implementation)을 접근하기 쉽게 만듭니다. 하지만 수년간의 엔지니어링 경험을 통해 축적된 판단력(judgment)을 초보자에게 자동으로 제공하지는 않습니다.

이것이 바로 기초 학습이 중요하고, 적게 중요하다는 것이 아닙니다. 좋은 결과물이 어떤 모습인지 이해하지 못한다면, 에이전트가 자신 있게 잘못된 것을 만들어낼 때 어떻게 알 수 있겠습니까?

4. AI 에이전트는 JavaScript를 재작성하여 누락된 네트워크 경로를 수정할 수 없습니다

AWS 예시로 돌아가 봅시다.

사용자의 Lambda 함수가 외부 서비스를 호출할 때 시간 초과(timeout)됩니다. 사용자의 에이전트는 타임아웃을 늘리고, 재시도(retries)를 추가하며, 요청 핸들러를 재작성합니다.

여전히 작동하지 않습니다.

실제 원인은 무엇일까요? 함수가 목적지로 가는 적절한 네트워크 경로가 부족한 VPC 구성에 있습니다.

아키텍처에 따라 수정에는 NAT 게이트웨이(NAT gateway), VPC 엔드포인트(VPC endpoint) 또는 다른 유효한 네트워크 경로가 필요할 수 있습니다.

코드는 완벽하게 정확할 수 있습니다. 하지만 네트워크는 여전히 작동하지 않을 것입니다.

이는 설명적인 시나리오이지만, 근본적인 문제는 흔합니다. 같은 오류가 시스템의 완전히 다른 계층에서 발생할 수 있기 때문입니다.

데이터베이스 연결 실패는 자격 증명(credentials), DNS, 네트워크 규칙 또는 연결 제한으로 인해 발생할 수 있습니다. 배포는 환경 변수(environment variable)가 누락되어 실패할 수 있습니다. API는 애플리케이션 로직보다는 클라우드 권한 문제로 오류를 반환할 수 있습니다.

엔지니어링 작업은 해결책을 선택하기 전에 실패하는 계층을 식별하는 것입니다.

이를 위해서는 로그 읽기, 구성 검사, 연결 테스트 수행 및 가설 설정(hypotheses)이 가능해야 합니다.

에이전트는 이 모든 것을 도와줄 수 있습니다. 하지만 사용자는 올바른 컨텍스트를 제공하고 그 결론을 평가해야 합니다.

그렇지 않으면 점점 더 정교해지는 추측에 비용을 지불하는 것입니다.

때로는 버그가 단 하나의 구성 설정일 뿐입니다. 디버깅 세션은 전체 캐릭터 개발 아크(character-development arc)가 됩니다.

5. 코딩 에이전트는 직업을 바꿀 뿐, 엔지니어링 자체를 제거하지는 않습니다.

AI 에이전트가 생성한 결제 엔드포인트를 가정해 봅시다.

데모 중에는 완벽하게 작동합니다.

하지만 요청이 시간 초과(times out)되어 클라이언트가 재시도하면 어떻게 될까요? 만약 결제 제공업체(payment provider)가 청구를 처리했지만, 서버가 응답을 받지 못하는 상황이라면요? 웹훅(webhook)이 두 번 도착한다면 어떨까요?

이제 여러분은 아이디엠포턴시(idempotency), 트랜잭션 경계(transaction boundaries), 동시성(concurrency), 그리고 조정(reconciliation)이라는 문제들을 다루게 됩니다.

만약 이러한 개념들을 이해하지 못한다면, 에이전트에게 어떤 요구사항을 주어야 할지조차 모를 수 있습니다.

우리가 이해해야 할 차이는 바로 이것입니다:

• 코드 작성(Writing code): 요구사항을 구현으로 번역하는 행위.
• 소프트웨어 엔지니어링(Engineering software): 요구사항을 이해하고, 설계를 선택하며, 트레이드오프를 평가하고, 실패 모드를 테스트하며, 신뢰할 수 있는 시스템을 유지하는 것.

AI는 코드를 작성하는 데 점점 더 효과적이 되고 있으며 주변 작업의 많은 부분을 도울 수 있습니다. 하지만 생성된 코드는 여전히 사용자가 검증해야 하는 무언가입니다.

실질적인 변화는 간단합니다. 반복적인 코드(boilerplate)를 수동으로 작성하는 데 쓰는 시간을 줄이고, 요구사항을 정의하고, 변경 사항(diffs)을 검토하며, 엣지 케이스(edge cases)를 테스트하고, 실패 원인을 이해하는 데 더 많은 시간을 할애해야 합니다.

위임된 구현(delegated implementation)과 위임된 책임(delegated responsibility)을 혼동하지 마세요.

6. 취업 시장에 진입하려는 개발자는 무엇을 배워야 할까요?

저는 다음 다섯 가지에 집중할 것을 권합니다:

1. 한 언어, 깊이 있게. 그 실행 모델(execution model), 오류 처리(error handling), 자료 구조(data structures), 그리고 성능 특성(performance characteristics)을 이해하세요.

2. 하나의 프레임워크, 깊이 있게. 추상화(abstractions), 라이프사이클(lifecycle), 테스트 관례(testing conventions), 그리고 일반적인 실패 모드(common failure modes)를 배우세요.

3. 그 아래의 시스템들. HTTP, 데이터베이스(databases), 네트워킹(networking), 보안(security), 배포(deployment), 그리고 관측 가능성(observability)을 이해하세요. 이 지식들이 작동하는 코드가 프로덕션 환경에서 실패할 수 있는 이유를 설명해 줍니다.

4. AI 지원 엔지니어링 (AI-assisted engineering). 컨텍스트를 제공하고, 인수 기준(acceptance criteria)을 정의하며, diff를 검사하고, 테스트를 실행하고, 체계적으로 디버깅하는 방법을 배우세요. 생성된 코드를 반드시 검증해야 하는 제안으로 취급하세요.

5. 제품 판단력 (Product judgment). 사용자들과 대화하고, 가정을 검증하며, 프로토타입을 출시하고, 자신이 만들고 있는 것이 실제로 누군가에게 필요한지 배우세요.

커리어를 시작하기 전에 모든 기술을 마스터할 필요는 없습니다. 대신 엔지니어링 판단력을 희생하지 않으면서 낯선 환경에서도 생산성을 발휘하는 능력을 개발해야 합니다.

그리고 기억하세요: 숙련된 개발자들은 바로 이러한 도구들로 인해 더욱 생산적이 되고 있습니다. 단순히 코드를 생성하는 것 자체가 모두가 유사한 기능에 접근할 수 있게 되면서 반드시 경쟁 우위는 아닙니다.

7. AI에서 SI로: 지능이 저렴해지면 무슨 일이 벌어질까?

Elon Musk는 최근 Tesla의 AI 계정이 @TeslaSI 핸들을 채택하고, SpaceXAI를 SpaceXSI로 이름을 바꾸겠다는 발언을 하면서 '슈퍼 인텔리전스(Super Intelligence)', 즉 SI라는 용어를 강조했습니다.

브랜딩 변경이 슈퍼 인텔리전스가 도착했음을 증명하는 것은 아닙니다. 하지만 이는 논의되고 있는 야망의 방향을 반영합니다.

AI 시스템들이 계속해서 더 유능해진다면, 소프트웨어를 구현하는 비용은 더욱 낮아질 수 있습니다. 더 많은 사람들이 이전에 훨씬 더 많은 수동 노력이 필요했던 프로토타입을 구축하고, 워크플로우를 자동화하며, 제품을 만들 수 있게 될 것입니다.

그렇다면 차별점은 무엇이 될까요?

아마도 당신이 암기한 프레임워크의 개수나 컴포넌트를 얼마나 빨리 생성할 수 있느냐가 아닐 것입니다.