[아이티데일리] 1. 들어가며

얼마 전 Y-콤비네이터가 주최한 인공지능(AI) 스타트업 스쿨에서 안드레이 카파시(Andrej Karpathy)는 ‘AI 시대의 소프트웨어(Software in the Era of AI)’라는 주제로 키노트 연설을 했다.¹

많은 사람이 키노트에 뜨거운 반응을 보였는데, 여기서 그는 ‘소프트웨어 3.0’이라는 용어를 대중에게 처음 공개했다. 안드레이는 테슬라에서 자율주행 소프트웨어 비전 부분과 AI 책임자를 역임했으며 오픈AI 창립자 중 한 명이기도 하다. AI 분야 대표적인 석학으로 알려진 페이페이 리(Fei-Fei Li) 교수의 지도하에 스탠포드 대학에서 박사학위를 받은 이력도 확인할 수 있다.

이 키노트에서 안드레이 카파시는 소프트웨어 개발 패러다임이 세 단계에 걸쳐 진화하고 있다고 설명한다. C++나 파이썬(Python) 같은 언어로 직접 코드를 작성하던 ‘소프트웨어 1.0’ 시대를 지나 방대한 데이터를 통해 뉴럴 네트워크를 학습시켜 프로그램이 스스로 문제를 해결하게 만드는 ‘소프트웨어 2.0’, 더 나아가 대규모 언어 모델(LLM)을 영어와 같은 자연어 프롬프트로 직접 프로그래밍하는 ‘소프트웨어 3.0’이라는 새로운 패러다임이 등장했다는 것이다. 카파시는 이 세 가지 방식이 각각의 특징을 가지고 공존하며, 미래의 소프트웨어 개발자는 이 모든 패러다임에 익숙해져야 할 필요가 있다고 강조했다.

필자는 소프트웨어를 전공하는 대학 4학년 학생의 졸업 프로젝트를 지난 9년간 지도해 오고 있는데, 생성형 AI가 등장하며 이의 관심이 높아지기 시작한 2023년부터 학생들의 생성형 AI 활용을 적극 권장하고 있다. 최근 마무리한 2025년 1학기를 회고해 보면 안드레이 카파시가 말한 소프트웨어 3.0 시대의 개발자 모습을 학생들의 프로젝트 수행 과정에서도 들여다볼 수 있는 것 같다.

이들이 졸업해 개발자로 성장하기 위해선 핵심 역량도 언어와 프레임워크를 잘 다루는 소위 ‘하드 스킬’보다는 문제 정의와 솔루션 설계, 그리고 협업과 같은 ‘소프트 스킬’이 더 중요하다는 것을 점점 더 절실하게 느끼고 있다.

소프트웨어 3.0에 대한 안드레이 카파시의 생각과 아울러 필자가 느끼는 바를 정리해 봤다.

2. 안드레이 카파시가 말하는 소프트웨어 진화 3단계

안드레이 카파시는 다음의 세 단계로 소프트웨어가 진화한다고 말한다.

영화 리뷰를 분석해 감성(sentiment)을 긍정 혹은 부정으로 분류하는 문제를 해결하는 단계별 소프트웨어 해결 방식을 예로 들어 설명하면 그림과 같다.

그림에서 글자 가독성이 좀 떨어져 이를 간단히 설명하면 이렇다. 소프트웨어 1.0은 개발자라면 익숙한 ‘simple_sentiment()’라는 파이썬 함수이다. 입력 파라미터(문장)를 받아 미리 정의된 긍정 키워드와 부정 키워드 출현 횟수를 세어 많은 쪽으로 판단한 결과를 출력한다.

소프트웨어 2.0에서는 각각 10,000개의 긍정/부정 리뷰로 신경망을 학습시킨다. 소프트웨어 3.0에서는 LLM의 역할을 감성 분류사로 정의하고, 몇 개의 부정과 긍정 예를 제시한 다음 문제의 리뷰를 제시하고 긍정 혹은 부정으로 답하도록 지시한다.

코딩, 학습, 자연어 질의, 이 각각이 안드레이 카파시가 말하는 소프트웨어 3단계의 핵심 해결 방식이다. 안드레이가 제시한 코드 예제를 자세히 보면 우측 상단에 COPY라는 표시가 있는 것을 알 수 있다. 매우 익숙한 아이콘 아닌가? 안드레이가 소프트웨어 1.0 예제 코드조차 생성형 AI로 만든 것으로 의심해 볼 수 있다.

필자는 이 단계에서 “개발자는 과연 어떻게 정의돼야 하나?”라는 고민을 지울 수 없게 됐다. 이는 나뿐만 아니라 모든 전통적 의미의 개발자, 그리고 이러한 소프트웨어 개발자를 키우는 학교 또는 지도자가 공통으로 직면한 고민거리일 것이다.

안드레이의 정의에 따르면 이미 2단계에서 개발자의 역할은 새로운 국면으로 접어든다. 이 단계에서 개발자의 역할은 코드를 작성하는 것에서 양질의 데이터를 수집하고 관리하며, 모델을 훈련시키는 ‘선생님’ 또는 ‘큐레이터’의 역할이라고 했다. 이 맥락을 이어 나가면 3단계에서는 영어나 한국어를 논리적으로 잘 구사하면서 문제를 해결하는 것이 개발자의 역할이 된다.

필자 입장에서는 매우 받아들이기 거북하다. 아마 소프트웨어 개발을 업으로 삼고 있거나 개발자를 양성하는 모든 이들이 비슷하게 느낄 것이다. 이는 안드레이가 자신의 키노트에서 문제를 해결하는 도구로서 ‘소프트웨어’를 너무 광범위하게 설정했기 때문에 빚어진 오해의 소지에 비롯한다고 필자는 판단한다.

‘바이브 코딩(Vibe Coding)’이라는 용어를 최초로 만들어 낸 사람이 안드레이 카파시임을 다시금 떠올린다면 소프트웨어 3.0 시대의 개발자는 LLM을 개발 동반자로 함께 ‘코딩’을 하는 모습을 염두에 뒀을 것이라고 생각한다. 이러한 가정하에 소프트웨어를 전공하는 학생들을 지도하는 한 사람으로서 경험과 느낀 점을 좀 더 얘기해 보고자 한다.

3. 소프트웨어 진화에 따른 과제 수행 양상의 변화

소프트웨어를 전공하는 학생들의 졸업과제를 통해서도 소프트웨어가 진화하는 단계별 변화를 바로 감지할 수 있다. 알파고가 이세돌을 바둑에서 이기며 AI의 실전 활용 가능성에 대한 기대감이 높아짐과 함께 학교에서도 딥러닝에 대한 교육이 강화됐고 학생들이 수행하는 프로젝트에서도 서서히 소프트웨어 2.0 단계가 시작된다.

3.1 소프트웨어 2.0 단계

소프트웨어를 전공하는 4학년 학생들이 졸업 프로젝트에서 AI를 활용하기 시작한 것은 꽤 오래됐다. 딥러닝이 학교의 정규 교과과정에서 다뤄지며 졸업을 앞둔 학생들이 이를 자신의 프로젝트에 적용하려는 시도는 어쩌면 매우 자연스러운 현상이라고 볼 수 있다. 영상이나 이미지를 분석해 이를 바탕으로 한 다양한 서비스를 개발하는 것이 한때 유행하기도 했다.

예를 들면 개나 고양이의 이미지를 분석해 이 아이들이 불편해하는 것이 무엇인지를 파악하는 것, 특정 행동 영상에서 폭력적인 상황이 발생하는지 판단하기, 운동 영상을 실시간으로 판단하면서 잘못된 자세를 교정해 주기, 면접 영상을 보며 상대방에게 좀 더 좋은 인상을 줄 수 있는 방안을 제안하기 등 실제 수많은 프로젝트에서 딥러닝이 활용됐다.

이를 안드레이 카파시 분류에 의하면 소프트웨어 2.0에 가깝다고 볼 수 있다. 여기서 내가 ‘가깝다’라고 한 이유는 딥러닝 부분이 프로젝트의 전체가 아니라 일부로서 기능을 제공하고 실제 더 많은 부분은 프로젝트 멤버가 직접 프로그램을 작성해 완성해야 하는 부분이기 때문이다.

즉 문제 해결의 일부만 ‘학습’으로 해결한 것이란 뜻이다. 프로젝트팀이 문제를 제시하고 이를 해결하는 과정에서 필요한 핵심 기능이기는 하지만 이를 제품화 혹은 서비스화하기 위해서는 더 많은 소프트웨어 개발 역량을 발휘해야 한다. 다양한 프레임워크와 개발도구와의 씨름은 기본이며, 필자가 매우 중요하게 평가하는 기준인 협업 및 데브옵스 같은 개발 환경 구성 역시 프로젝트 멤버들이 풀어야 하는 숙제다.

당시 이런 과제는 학생들에게 꽤 도전적인 것이었다. 텐서플로나 파이토치와 같은 프레임워크를 활용해 모델을 개발하고 이를 학습시키는 과정을 직접 수행해야 하는 것이 우선 첫 번째 지나야 할 관문이다.

전체 서비스의 UX나 다른 기능이 훌륭하게 완성되고, 체계적인 협업과 CI/CD² 자동화 파이프라인이 아무리 완벽하게 구현됐다 하더라도 구현된 모델이 제대로 답을 주지 못하면 좋은 평가를 받기 어려울 수밖에 없다. 그래서 필자가 학생들을 지도할 때 이런 점을 사전에 주지시키기도 했다.

졸업과제는 그동안 학교에서 습득한 역량을 발휘해 완성도 높은 제품을 만드는 것이 중요한데, 만일 AI 모델 개발에 발목을 잡히면 열심히 작업한 나머지 부분도 제대로 평가받지 못하게 되니 결과에 대한 확신이 없다면 노력한 만큼 좋은 평가를 받을 수 없음을 강조한 것이다. 그럼에도 딥러닝에 꽂힌 팀들이 한 학기 내내 모델과 씨름하다가 참담한 결과를 맞게 된 여러 케이스를 목격했다.

만족스러운 결과를 얻지 못한 원인을 분석해 보면 딥러닝 교과목에서 예제 수준의 과제를 통해 경험한 모델 개발 및 학습만으로 실제 세상의 다른 문제를 풀 수 있을 것이라는 막연한 자신감이 너무 충만해 무리한 목표를 잡은 경우가 대부분이다. 간혹 모델 개발은 잘했으나 문제 정의 오류에서 빚어진 예상과 다른 결과 때문에 고전하는 팀도 있다. 제대로 된 학습 데이터를 확보하지 못해 학기 내내 데이터 확보를 위해 전전긍긍하다가 포기하는 경우도 다수 목격했다.

디지털 뉴딜 정책의 일환으로 구축된 AI 허브가³ 등장하면서 학습용 데이터 부족 문제가 일부 해결된 점은 매우 고무적이기도 했다. 학생들에게 AI 허브를 학기 초에 소개해 여기서 확보 가능한 데이터를 주제로 프로젝트 방향을 설정하는 팀도 있었고, 이런 팀은 대체로 좋은 성과를 내기도 했다.

어떤 경우라도 소프트웨어 2.0 시대에 문제 해결을 위한 핵심 기능에 딥러닝을 본격적으로 활용하기 시작했다는 점이 주목할 부분이다. 다만 지금 돌이켜 보면 이런저런 이유로 학생들이 당초 설정했던 야심 찬 성과를 내는 데에는 대체로 부족했다는 생각이다.

3.2 소프트웨어 3.0 단계

챗GPT가 처음으로 세상에 모습을 드러낸 것이 2022년 11월이고, 2023년 1학기 학생들 프로젝트에 생성형 AI가 등장한다. 아직 일부 프로젝트에서만 생성형 AI를 활용하기 시작했는데 가장 처음 LLM을 본격적으로 활용한 사례는 여행계획을 수립하는데 오픈AI의 GPT3.5를 활용한 것이다. 여행자들의 후기를 분석하고 이를 바탕으로 특정 지역을 여행하려는 예비 여행자에게 여행계획을 제안하는 데 오픈AI 모델을 활용했다.

이후 대부분 프로젝트에서 자연어 문서를 분석하고 또 사용자들에게 제안하는 콘텐츠를 제작하는 데 생성형 AI를 활용하기 시작한다. 프로젝트에서 주장하는 주요 특징 또는 강점이 사용자가 원하는 결과를 얻을 수 있는 최적의 ‘프롬프트’를 제공한다는 것이다. 초기에는 오픈AI 모델 활용이 주를 이루던 것이 프로젝트의 성격과 목적, 그리고 가용한 비용에 따라 클로드(Claude) 등 다양한 생성형 AI를 활용하기 시작했고 최근에는 구글 제미나이 활용이 부쩍 많아진 것도 눈여겨 볼 만한 현상이다.

활용 방식과 범위도 점점 더 다양해졌다. 초기에는 생성형 AI 서비스에서 제공하는 API를 활용해 기능의 일부를 해결하는 것이 주류였다면, 점차 바이브 코딩을 통해 실제 프로덕션 수준에서 동작하는 코드를 작성하는 데 LLM 활용 비중이 높아지고 있음을 알 수 있다.

프롬프팅(Prompting) 기법도 제로샷(Zero-shot) 프롬프팅뿐 아니라 주어진 목표에 부합하는 상황 예시를 정교하게 설계해 원하는 결과 수준을 높일 수 있는 퓨샷(Few-shot) 프롬프팅을 혼용하며 응답시간과 정확한 답변 사이의 다양한 사용자 요구사항에 적절히 대응하는 방식도 보편화되고 있다. 최근에는 더 나아가 프로젝트 도메인에 특화된 데이터를 바탕으로 벡터 임베딩 및 검색 증강 생성(Retrieval-Augmented Generation, RAG)을 많은 프로젝트에서 구현/활용하기도 한다.

생성형 AI를 활용한 소위 바이브 코딩은 이제 모든 학생이 사용하고 있다고 보면 된다. 대부분 자신이 즐겨 사용하는 IDE와 결합한 형태로 활용하는데, 코파일럿과 커서(Cursor)가 지금은 대세인 것 같다. 이러한 코드 작성은 프로덕션 코드뿐만 아니라 테스트 코드를 작성할 때도 특히 많이 활용되고 있다.

필자의 경우 프로젝트 결과물에서 테스트 코드를 매우 중요시하고 있고 또 이의 작성 여부를 평가에 일부 반영한다. 하지만 과거 사례를 보면 대부분 팀이 프로젝트 완성도를 높이는 데 급급해 테스트 코드를 실제 작성해 활용하는 팀은 그리 많지 않았다. 1년 전만 하더라도 전체의 절반 정도만 테스트 코드를 활용했다.

그런데 2025년도 1학기 프로젝트 평가를 하며 팀별 깃허브 저장소를 탐색해 보니 모든 팀이 테스트 코드를 작성한 것을 확인할 수 있었다. 이 코드를 자세히 들여다보면 형식이 매우 유사한 것이 마치 동일한 보일러 플레이트(Boilerplate)⁴ 활용한 것처럼 보이는데 단박에 AI가 작성해 준 것임을 알 수 있었다. 학생들에게 직접 물어보니 역시 AI가 작성해 준 것이 맞았다.

AI가 작성해 준 테스트 코드의 특징은 과도하게 많은 외부 모듈을 활용한다는 사실이다. 코드를 작성한 장본인에게 설명해 보라 했더니 자신도 이런 외부 모듈이 왜 필요한지는 정확하게 이해하지 못하지만, 이를 임의로 제거할 경우 제대로 동작하지 않을 것을 우려해 함부로 정리하기도 어렵다고 한다.

테스트 코드가 정확하게 동작하는 것이 프로덕션 코드보다 더 중요한데 정작 코드 작성자가 테스트 코드를 완벽하게 이해하지 못한다는 것은 향후 유지보수에서 큰 맹점이 될 수 있다. 이런 요소들이 확대되면 나중에 걷잡을 수 없는 기술 부채가 될 수도 있다. 어쨌든 AI 덕분에 테스트 코드 활용도가 높아진 것은 고무적인 현상이다.

생성형 AI를 활용하면서 개발 기간을 단축하게 되는 중요한 요소 중 하나는 개발 환경 구축에 필요한 리드타임이 대폭 줄어드는 것이다. 일일이 필요한 기술 스택을 확인하고 테스트하는 데 걸리는 시간, 그리고 CI/CD 파이프라인과 클라우드 서비스를 구축하기 위해서 학생들이 학습해야 할 시간을 많이 줄일 수 있다. AI의 가이드에 따라 시행착오를 최소화하며 좀 더 빨리 실제 개발 모드에 진입할 수 있기 때문이다.

개발 플로우 자동화를 위한 스크립트 작성 또한 AI가 도와줄 수 있으나 이의 동작 원리는 개발자가 반드시 숙지해 향후 빌드 최적화 등의 작업은 직접 수행해야 할 것이다. 최종 빌드 타깃인 컨테이너 빌드에 적지 않은 시간이 소요되는데 스크립트를 최적화함으로써 빌드 시간을 대폭 줄일 수 있다. 예전 개발 추억을 떠올린다면 메이크파일(Makefile)을 생성형 AI가 자동으로 생성해 준다고 보면 된다.

개발자들이 다소 버거워하는 초기 기획 단계에서도 생성형 AI는 도움을 줄 수 있다. 물론 명확하게 아이디어가 정의되어야 하는 것은 선결 조건이다. 이후 단계에서 생성형 AI가 세부 기획안을 제안해 줄 수 있다. 이미 잘 알려진 서비스를 예로 생성형 AI를 통해 기획안을 만들어 달라고 하면 꽤 쓸만한 기획서를 빠르게 완성할 수 있음을 필자도 확인할 수 있었다.

4. 나가며 - 소프트웨어 3.0 시대에 개발자로 성장하려면

안드레이 카파시가 정의한 소프트웨어 3.0 시대의 개발자는 생성형 AI를 최대한 활용해 생산성을 극대화하되 바이브 코딩 하에서 만들어지는 결과물도 결국 자신이 책임져야 할 부분임을 명심해야 한다. 자칫 AI가 작성한 코드가 기술 부채가 될 수도 있기 때문이다. 바이브 코딩 방식도 문제 해결을 무작정 AI에 맡기기보다는 최초 동작하는 코드는 AI가 작성한 코드를 활용하되 이를 수정하는 과정에서는 가능한 그 내용을 정확히 이해하도록 노력해야 한다.

깃(Git)과 같은 소스코드 관리 도구를 활용한 협업의 경우는 동료들과 코드 리뷰를 하고 또 어떤 부분이 어떻게 수정됐는지 커밋 메시지를 통해 공유되는 것이 일반적인 관행인데 개발자가 수정된 부분을 제대로 이해하지 못한다는 사실은 쉽게 수긍하기 어렵다.

몇 주 전 ‘AI 시대의 개발자’를 주제로 한 토론회에서 과연 ‘버전 관리’가 필요하냐는 한 패널 토론자의 발언은 필자에게 적지 않은 충격이었다.

소프트웨어 전공자를 교육하는 입장에서 AI 시대에 개발자가 갖추어야 할 역량에 대한 고민은 피할 수 없는 어려운 숙제이다. AI 시대에는 교육을 통해 습득할 수 있는 하드 스킬보다 경험을 통해 얻을 수 있는 ‘소프트 스킬’ 역량이 더 중요할 것이라고도 한다. 프로그래밍 언어, 기술 스택 이해, 알고리듬 지식과 같은 것이 하드 스킬 영역이라면, 팀워크, 문제 해결 능력, 의사소통, 리더십 같이 측정하기 어려운 부분이 소프트 스킬 영역이다.

물론 하드 스킬은 기본적으로 갖춰야 하는 것이고 AI 시대에 ‘좋은’ 개발자의 기준은 소프트 스킬 역량이 될 것이란 뜻이다.

필자의 N사 시절 직장 동료이자 많은 개발자의 롤모델로 인정받고 있으며, 또한 매 학기 우리 학교 학생들에게 소프트웨어 개발자로서의 성장을 위해 소중한 얘기를 해주는 현대 오토에버 유석문 전무가 말하는 AI 활용 지침을 여기에 옮기며 소프트웨어 3.0 시대의 단상을 맺고자 한다.