facts

자연어로 아이디어를 설명하면 수 분 안에 UI와 데이터베이스가 연결된 작동 가능한 프로토타입이 화면에 나타난다. 코드를 한 줄도 쓰지 않은 비전공자에게는 마법처럼 보이고, 숙련된 엔지니어에게도 놀라운 속도다. 하지만 이렇게 만들어진 결과물은 노트북 환경에서만 작동할 뿐, 실제 서비스 환경에 투입되는 순간 한계를 드러낸다.

문제는 프로토타입이 '작동한다'는 사실과 '배포 준비가 됐다'는 상태 사이에 거대한 간극이 존재한다는 점이다. AI가 만든 초기 버전은 부하 테스트를 견디지 못하거나 에러 핸들링이 누락된 경우가 많다. API 토큰이 외부로 유출될 가능성이 있고, 단일 사용자에게는 적합했던 데이터 모델이 두 번째 사용자가 추가되는 순간 무너진다. 인증 체계 역시 엄격한 검증보다는 막연한 가정 위에 세워져 있어 보안 취약점에 노출되어 있다.

기존 소프트웨어 엔지니어링에서 시간이 가장 많이 소요된 지점은 단순히 구문을 작성하는 일이 아니었다. 확장 가능한 시스템을 설계하고, 사용자가 예상치 못하게 마주칠 예외 상황을 처리하며, 장애 발생 시 원인을 파악할 수 있는 관측 가능성(Observability)을 구축하는 작업이 핵심이었다. AI는 첫 번째 작동 버전에 도달하는 시간은 획기적으로 단축했지만, 그 버전에서 프로덕션 등급의 시스템으로 넘어가는 거리까지 줄이지는 못했다.

market-flow

최근 업계에서는 AI로 코드를 생성할 수 있게 되면서 컴퓨터 과학(CS) 전공 지식을 배울 필요가 있느냐는 의문이 제기되고 있다. 하지만 실제 시장의 흐름은 오히려 기초 지식의 가치를 높이는 방향으로 움직인다. AI가 제공하는 빠른 피드백 루프 때문에 많은 이들이 소프트웨어 개발 전체 과정이 압축되었다고 착각하지만, 정작 중요한 '판단'의 영역은 여전히 인간의 몫이기 때문이다.

컴퓨터 과학 교육의 본질은 코드 생산 능력이 아니라 시스템이 어떻게 작동하고 왜 실패하는지에 대한 멘탈 모델을 구축하는 데 있다. 이 모델이 있어야만 AI가 작성한 쿼리가 5,000만 건의 행을 가진 테이블에서 풀 테이블 스캔(Full Table Scan)을 일으켜 시스템을 멈추게 할 것임을 알아챌 수 있다. 또한 AI가 제안한 캐싱 전략이 동시 접속 환경에서 레이스 컨디션(Race Condition)을 유발할 가능성을 식별하고, 현재의 해결책이 미래의 확장성을 저해하는 구조인지 판단할 수 있다.

단순히 요구사항을 한 줄씩 구현 코드로 옮기는 '기계적 코더'에 대한 수요는 빠르게 감소하고 있다. 이 영역은 이미 자동화의 범위에 들어왔다. 대신 생산성 분포의 하단은 압축되고 상단의 천장은 높아지는 현상이 나타나고 있다. 숙련된 엔지니어가 AI 도구를 활용하면 과거에는 상상할 수 없었던 속도로 움직일 수 있다. 이는 어려운 문제가 사라졌기 때문이 아니라, 많은 시간과 주의력을 소모하던 기계적 작업들을 AI가 처리해주면서 전문성이 필요한 설계와 판단에 더 많은 시간을 투입할 수 있게 되었기 때문이다.

reader-impact

실무자가 경계해야 할 지점은 AI를 이해의 대체재로 사용하는 '바이브 코딩(Vibe-coding)'이다. 논리적으로 추론할 수 없는 시스템을 AI의 감각에만 의존해 구축하면, 정작 시스템이 무너졌을 때 수정할 수 없고 성장이 필요할 때 확장할 수 없으며, 유지보수 담당자에게 구조를 설명할 수 없는 상태에 빠지게 된다. AI 기술 습득보다 더 시급한 것은 추상화 수준을 높이면서도 기본기에 뿌리를 두는 운영 방식의 전환이다.

AI를 깊은 지식의 대체재가 아닌 '포스 멀티플라이어(Force Multiplier, 전력 증강 도구)'로 취급하는 엔지니어가 경쟁 우위를 점하게 된다. 이들은 모델에게 무엇을 생성하라고 요청할지 정확히 알고 있으며, 생성된 코드를 주니어 엔지니어의 풀 리퀘스트(Pull Request)를 검토하듯 비판적인 시각으로 리뷰한다. 단순한 기능 묘사가 아니라 아키텍처 관점에서 대화를 주도하며, 모델의 제안이 부적절할 때 이를 거부하고 수정 방향을 제시한다.

결국 프로토타입을 만드는 것은 이제 누구나 할 수 있는 쉬운 일이 되었다. 하지만 그 이후의 단계, 즉 신뢰할 수 있는 소프트웨어를 출시하는 것은 여전히 고도의 엔지니어링 판단을 요구한다. 한국의 개발자와 기업들은 '도구의 숙련도'보다 '기본기의 내재화'를 우선순위에 두어야 한다. 학습 순서는 명확하다. 먼저 기본기를 익히고, 그 다음에 새로운 도구를 배우는 것이다.