이하 내용은 제가 겪은 개인적인 경험과 생각에 불과합니다. 특정 기술에 대한 객관적인 평가라기보다는 한 개발자의 여정으로 재미있게 봐주시면 감사하겠습니다.
1. 2022년 4분기, 최초의 코딩 도우미 GPT-3.5
GPT-3.5가 처음 세상에 나왔을 때, 제가 있던 연구실의 모두는 그 잠재력에 놀라움을 금치 못했습니다. 지금의 고성능 모델들과 비교하면 아쉬운 수준이지만, '프로그래머로서의 미래가 불투명해질 수도 있겠다'는 생각에 모두가 동의할 정도였으니까요. 당시만 해도 자연어 처리(NLP)는 감성 분석이나 텍스트 분류 같은 비교적 간단한 작업에 머물러 있었고, 오히려 컴퓨터 비전 분야의 발전이 더 눈부시다고 생각했던 시기였습니다. 그런 상황에서 등장한 GPT-3.5는 충격 그 자체였습니다.
하지만 기술적 한계는 명확했습니다. 넓은 컨텍스트를 이해하지 못했고, 지시사항을 조금만 벗어나도 전혀 다른 답변을 내놓기 일쑤였습니다. 결국 실무적인 관점에서는 매우 제한적으로 사용될 수밖에 없었습니다. LLM이 스스로 처음부터 끝까지 작성한 코드는 기존 프로젝트의 맥락을 벗어나거나 아예 동작하지 않는 경우가 다반사였기 때문입니다.
결국 저희의 활용법은 크게 두 가지로 좁혀졌습니다. 첫째는 미완성된 함수나 코드 블록을 던져주고 나머지를 완성하도록 하는 것, 둘째는 이미 완성된 코드의 주석을 달거나 비효율적인 부분을 개선하도록 요청하는 것이었습니다. 명확한 목적을 가진 개별 함수, 즉 '부품' 수준의 코드를 만들게 하는 것이 당시로서는 최선의 활용법이었습니다.
2. GPT-4의 등장, 드디어 코드가 '동작'하다
본격적으로 의미 있는 코드를 작성하기 시작한 모델은 단연 GPT-4라고 생각합니다. GPT-3.5가 표준 라이브러리를 활용하는 데 그쳤다면, GPT-4는 PyTorch나 FastAPI 같은 복잡한 외부 라이브러리의 사용법을 정확히 이해하고 있었습니다. 더 이상 오래전에 deprecated된 코드를 내놓거나, 라이브러리의 철학을 무시한 코드를 보여주지 않았습니다. 응답 속도는 다소 느렸지만, 그 기다림을 충분히 감내할 만한 퀄리티였습니다.
개인적으로 가장 기억에 남는 경험은, 학부생 교육용으로 사용할 이미지 분류(Image Classification) 모델의 전체 학습 파이프라인 작성을 요청했을 때입니다. 놀랍게도 GPT-4가 생성한 코드는 단 한 번의 수정 없이 완벽하게 동작했고, 당시 표준으로 여겨지던 최신 문법을 정확히 구사했습니다.
물론 이때도 지금의 Cursor와 같은 MCP(Multi-Code-Prompt) 툴이 없었기에 한계는 여전했습니다. 프로젝트의 전체적인 맥락을 전달하기 위해 관련된 소스 코드를 일일이 복사해서 붙여넣어야 했습니다.
예를 들어, 당시에는 이런 방식으로 프롬프트를 작성하곤 했습니다.
예시: 주변 소스 코드를 전달하고 목표 소스 코드 작성 요청하기
# [Context] 현재 프로젝트의 models.py 파일 내용입니다. from pydantic import BaseModel class User(BaseModel): id: int name: str email: str age: int # [Request] # 위 User 모델을 사용하는 FastAPI 엔드포인트를 작성해주세요. # GET /users/{user_id} 경로로 요청이 오면, # 미리 정의된 더미 데이터에서 해당 유저를 찾아 반환하고, # 만약 사용자가 없으면 404 에러를 반환해야 합니다.
당시의 컨텍스트 길이는 지금보다 훨씬 짧았기 때문에, 위와 같이 핵심적인 부분만 전달하여 복잡한 프로젝트 전체를 이해시키는 것은 불가능에 가까웠습니다.
그럼에도 불구하고 데이터 전처리, 로깅, 테스트 코드 작성 등 비교적 독립적인 보조 작업을 맡기기에는 충분히 강력한 성능을 보여주었습니다. 또한, 이 시점의 모델부터 마크다운 문법을 능숙하게 활용하기 시작해서 README.md 같은 문서를 작성하는 데도 매우 편리했던 기억이 납니다.
예시: README.md와 같은 문서화 요청하기
# [Request] # 제가 만든 간단한 파이썬 스크립트에 대한 README.md 파일을 작성해주세요. # 스크립트 이름: image_resizer.py # 기능: 지정된 폴더의 모든 이미지를 원하는 해상도로 변경하고 다른 폴더에 저장합니다. # 사용법: python image_resizer.py --source <원본폴더> --dest <저장폴더> --width 800 # 필요한 라이브러리: Pillow # 이 내용을 바탕으로 설치 방법, 사용법, 예시를 포함한 멋진 README.md를 마크다운으로 만들어주세요.
3. Claude 3 Opus, 사람 '만큼' 코드를 작성하는 LLM
GPT-4가 '쓸 만한' 코드의 시대를 열었다면, Claude 3 Opus는 '사람처럼' 코드를 짜는 LLM의 등장을 알렸습니다. 물론 자극적인 표현일 수 있지만, 충분하고 상세한 설명이 동반된다면 사람이 긴 시간 고민하여 작성한 코드에 버금가는 결과물을 내놓았습니다. 특히 백준 온라인 저지의 꽤 어려운 알고리즘 문제도 막힘없이 풀어내는 것을 보며, '이제는 정말 LLM이 사람보다 글(코드)을 더 잘 쓸 수 있겠다'는 경외심과 두려움이 동시에 생겨났습니다.
하지만 개발 환경의 패러다임이 바뀐 것은 아니었기에, 활용 방식 자체는 GPT-4 시절과 크게 다르지 않았습니다. 여전히 필요한 코드 조각을 얻기 위해 채팅창에 컨텍스트를 설명하고 질문하는 방식이 주를 이루었습니다. Cursor와 같은 툴이 막 등장하던 시기였지만, 아직은 소수의 선구적인 개발자들을 제외하고는 널리 쓰이지 않았습니다.
공교롭게도 이 시점부터 OpenAI와 Anthropic 모두 고가의 엔터프라이즈 요금제를 출시하기 시작했고, 월 20달러 수준의 프로 요금제에는 타이트한 사용량 제한이 걸리기 시작했습니다. API 호출 비용 또한 점진적으로 증가하던 추세였으니, 아마 LLM 활용에 가장 많은 비용을 지불했던 시기가 아니었나 싶습니다.
4. MCP의 시대, 사용하기 좋은 도구들의 탄생
물론 CoT(Chain-of-Thought)와 같은 프롬프팅 기술의 진보가 모델의 잠재력을 끌어올린 것은 사실입니다. 하지만 개발자 입장에서 체감된 진정한 혁신은 MCP(Multi-Code-Prompt)를 지원하는 편의성 도구들이 본격적으로 보급되면서 시작되었다고 생각합니다. GitHub Copilot, Cursor와 같은 도구들이 AI를 채팅창에서 꺼내 IDE 안으로 완벽하게 통합시키면서 개발의 패러다임이 바뀌기 시작한 것입니다.
특히 Copilot의 자동 완성 기능은 개발 방식 자체를 바꾸어 놓았습니다. 개발자는 마치 옆에 앉은 똑똑한 동료 개발자가 내 의도를 파악하고 코드를 대신 입력해주는 듯한 경험을 하게 되었습니다.
예시: Copilot의 자동 완성 (Autocompletion)
사용자가 함수의 이름과 타입을 정의하는 단 한 줄만 작성해도, Copilot은 함수의 전체 구현부를 예측하여 회색 텍스트로 제안합니다.import requests # 사용자가 아래 한 줄까지만 입력하면, def fetch_user_data(user_id: int) -> dict: # --- (아래 블록 전체를 Copilot이 회색 텍스트로 제안) --- # api_url = f"https://api.example.com/users/{user_id}" # try: # response = requests.get(api_url) # response.raise_for_status() # 2xx 상태 코드가 아니면 에러 발생 # return response.json() # except requests.exceptions.RequestException as e: # print(f"An error occurred: {e}") # return {} # -----------------------------------------------------------------개발자는 그저
Tab키를 한 번 누르는 것만으로 전체 코드를 완성할 수 있었습니다. 이러한 실시간 코드 제안은 단순한 타이핑 감소를 넘어, 개발자의 생각의 흐름을 끊지 않고 다음 단계를 예측하여 제시해주었다는 점에서 혁신적이었습니다.
이러한 도구들의 확산은 선순환 구조를 만들었습니다. 더 많은 개발자가 AI 코딩 에이전트를 사용하기 시작했고, 이는 자연스럽게 방대하고 다양한 실제 사용 데이터를 축적하는 결과로 이어졌습니다. 이 데이터는 모델을 파인튜닝(Fine-tuning)하는 데 재사용되어, 모델이 실제 개발 현장에서 마주하는 문제들을 더 잘 해결하도록 꾸준히 진화하는 원동력이 되었습니다.
특히 RAG(Retrieval-Augmented Generation) 와 같은 보조 기술의 결합이 결정적이었습니다. RAG는 AI가 답변을 생성하기 전에, 사용자의 전체 프로젝트 코드와 같은 관련 문서를 먼저 참조하게 만드는 기술입니다. 이는 연쇄적인 장점을 낳았습니다. AI가 프로젝트의 맥락을 더 명확히 이해하게 되니, 단번에 정확도 높은 답변을 생성할 확률이 높아졌습니다. 이는 불필요한 재질문이나 수정을 줄여 API 호출 횟수를 감소시켰고, 결과적으로 개발자는 더 빠른 피드백을 받을 수 있게 되었습니다. 결국 이 모든 과정은 LLM의 가장 큰 골칫거리였던 할루시네이션(Hallucination)으로 인한 불편함을 극적으로 줄이는 핵심 열쇠였습니다.
하지만 이 시기에도 명백한 문제점과 한계는 존재했습니다.
첫째, 컨텍스트 길이의 물리적 한계입니다. 당시 주력 모델들의 컨텍스트 길이는 32,768 토큰이나 65,536 토큰에 머물렀습니다. 이는 중소 규모의 프로젝트에서는 충분할 수 있었지만, 복잡하고 거대한 레거시 시스템 전체를 이해시키기에는 여전히 부족한 크기였습니다.
둘째, 기술 스택에 따른 극심한 성능 편차입니다. React처럼 학습 데이터가 압도적으로 많은 라이브러리에 대해서는 놀라울 정도로 정교한 코드를 작성했지만, Next.js 수준만 되어도 종종 헤매는 모습을 보였고, Svelte와 같은 상대적 비주류 프레임워크는 거의 활용이 불가능에 가까웠습니다. 이는 프로그래밍 언어 간에도 마찬가지여서, Python이나 JavaScript에 비해 다른 언어에서는 성능이 현저히 떨어지는 경향을 보였습니다.
결론적으로 이 시기는 '쓸 만은 한데, 아직은 아쉬운' 느낌이 강했습니다. 분명 이전과는 비교할 수 없는 생산성을 보여줬지만, 내가 사용하는 기술 스택이 AI의 지원 범위 밖에 있을 수 있다는 불안감을 떨치기 어려웠던, 가능성과 한계가 공존하는 과도기였다고 기억합니다.
5. 컨텍스트 길이의 폭발적 증가와 llms.txt의 탄생
최근 등장하는 모델들은 GPT-4가 처음 주었던 것과 같은 폭발적인 성능 향상의 충격보다는, 다른 차원의 발전을 보여주고 있습니다. 바로 컨텍스트 길이(Context Length)의 비약적인 증가입니다. 모델의 추론 능력 자체가 극적으로 향상되었다기보다는, 한 번에 이해하고 기억할 수 있는 정보의 양이 대폭 늘어난 것입니다.
컨텍스트 길이가 128K, 200K, 심지어 1M 토큰까지 확장되면서, LLM은 더 이상 코드의 '조각'을 보는 것이 아니라 프로젝트 '전체'를 하나의 거대한 문맥으로 이해하기 시작했습니다. 이는 복잡하게 얽힌 레거시 코드의 의존성을 파악하거나, 프로젝트 전반에 걸쳐 일관된 코딩 스타일을 유지하는 작업을 훨씬 수월하게 만들었습니다. 수십 개의 파일을 열어보며 파악해야 했던 거대 함수의 호출 관계를, AI는 단 몇 초 만에 요약하고 분석할 수 있게 된 것입니다.
이러한 거대 컨텍스트 시대를 맞아 개발 현장에서는 새로운 관행이 생겨나고 있습니다. 바로 llms.txt 또는 copilot_instructions.txt 와 같은 LLM을 위한 전용 설명서를 프로젝트에 포함하는 것입니다. 이는 AI 코딩 에이전트가 프로젝트를 분석할 때 가장 먼저 읽도록 하여, 프로젝트의 핵심적인 규칙과 구조를 명확하게 전달하는 역할을 합니다.
예시: 프로젝트 루트에 위치한
llms.txt파일# === Project Overview === 이 프로젝트는 FastAPI와 SQLModel을 사용한 간단한 블로그 API입니다. 사용자는 게시물을 작성, 조회, 수정, 삭제할 수 있습니다. # === Key Libraries & Usage === - FastAPI: 모든 의존성 주입(DI)은 `Depends`를 사용합니다. 라우터는 기능별로 분리하여 `app/routers/` 폴더에서 관리합니다. - SQLModel: 데이터베이스 모델과 Pydantic 모델의 역할을 동시에 수행합니다. 모든 DB 세션은 `app/db.py`의 `get_db` 함수를 통해 관리해야 합니다. - Alembic: 데이터베이스 마이그레이션 도구입니다. 모델 변경 시에는 반드시 `alembic revision` 명령어를 사용하세요. # === Coding Style Guide === - 모든 함수와 메서드에는 Python 타입 힌트를 반드시 명시해야 합니다. - 하나의 함수는 30줄을 넘지 않도록 최대한 간결하게 작성합니다. - 환경 변수는 `app/core/config.py`의 Settings 클래스를 통해서만 접근해야 합니다. # === Important Rules === - 절대 `.env` 파일을 직접 수정하는 코드를 작성하지 마세요. - 비밀 키나 민감 정보는 코드에 하드코딩하지 말고 환경 변수를 사용하세요.
결국 llms.txt는 AI에게 프로젝트의 '설계도'와 '규칙'을 명시적으로 알려주는 역할을 합니다. 개발자는 더 이상 AI에게 단편적인 지식을 주입할 필요 없이, 잘 작성된 온보딩 문서를 건네주는 것만으로 AI를 고도로 숙련된 팀원으로 활용할 수 있게 된 것입니다. 이는 진정한 의미의 '협업'을 한 단계 더 높은 수준으로 끌어올린, 의미 있는 변화라고 할 수 있습니다.
이 지점에서 개발의 패러다임은 다시 한번 전환됩니다. 단순히 코드를 아는 것을 넘어, AI에게 어떻게 일을 시킬 것인가, 즉 소위 '바이브 코딩(Vibe Coding)'의 기술이 무엇보다 중요해졌습니다. 개발자가 프로젝트의 전체적인 방향성, 아키텍처, 핵심 규칙이라는 '바이브'를 얼마나 정교하게 전달하느냐에 따라 AI가 내놓는 결과물의 질이 천차만별로 달라지기 시작한 것입니다.
그리고 자연스럽게 이러한 변화의 이면에는 어두운 그림자도 드리워졌습니다. AI를 활용한 코딩 기술을 가르친다는 명목으로, 본질적인 소프트웨어 공학 지식 없이 얄팍한 프롬프트 기술만을 파는 '사짜'들이 판을 치기 시작한 시점이기도 합니다. AI를 '활용'하는 것과 그저 AI에게 '의존'하는 것의 경계에서, 이제는 개발자 개개인의 문제 정의 능력과 방향 제시 능력이 그 어느 때보다 중요해진 시기라 할 수 있겠습니다.
6. 사람을 넘어서는 모델들: Gemini 1.5 Pro와 o1
이 시점에 이르러서는 모델의 발전이 단순히 더 나아지는 수준을 넘어, 질적으로 다른 차원으로 접어들었습니다. 컨텍스트 길이는 1M 토큰 수준으로 늘어났고, 모델의 성능 자체도 특정 영역에서는 인간을 넘어서는 것처럼 느껴지기 시작했습니다. 예를 들어, Gemini 1.5 Pro에게 파이썬 코딩을 지시하면, 단순히 코드를 생성하는 것을 넘어 완벽한 타입 힌팅과 PEP 규약을 만족시키면서도 동시성까지 고려한, 한 번에 완벽하게 동작하는 코드를 내놓기 시작했으니까요.
이는 단순 코딩 작업을 넘어, o1이나 o1-pro와 같은 최신 모델들이 실제 과학 및 공학 리서치 영역에서 인간 연구원을 보조하거나 특정 문제를 해결하는 데 쓰이는 것을 보면 더욱 명확해집니다. 이제 모델은 인간의 지식을 모방하는 것을 넘어, 인간의 역량 이상으로 문제를 해결하는 가능성을 보여주기 시작한 것입니다.
그러나 이 경이로운 성능에는 명백한 대가가 따랐습니다. (천문학적인 비용을 제외하더라도) 가장 큰 문제점은 이 강력한 모델들이 CoT(Chain-of-Thought)와 같은 복잡한 추론 과정을 거치는 데 너무 많은 시간이 소모된다는 점이었습니다. 이로 인해 Cursor와 같이 실시간 상호작용과 빠른 피드백이 생명인 도구에서는, 어쩔 수 없이 GPT-4o나 Claude 3.5 Sonnet과 같이 추론 속도가 빠른 경량화 모델을 주력으로 사용할 수밖에 없었습니다.
자연스럽게 개발 워크플로는 이원화되었습니다. 대부분의 일상적인 코딩은 빠른 경량 모델의 도움을 받고, 그 모델들이 해결하지 못하는 정말 어렵고 복잡한 문제에 부딪혔을 때만 무거운 대형 모델을 호출하는 방식입니다. 이러한 방식은 필연적으로 중간중간 사람의 개입(interaction)을 요구했고, 어떤 모델에게 어떤 문제를 맡길지 판단하고 결과를 통합하는 과정은 상당한 피로감을 유발했습니다.
그럼에도 불구하고, 이 모든 경험은 하나의 강력한 생각으로 귀결되었습니다. '이제 주니어 개발자의 시대는 정말로 끝났다.' 신입 개발자들이 경험을 쌓기 위해 수행하던 비교적 단순하고 정형화된 작업들을, 이제 AI가 훨씬 빠르고 정확하며 저렴하게 처리할 수 있게 되었기 때문입니다. 개발자로서 성장하는 전통적인 사다리가 끊어졌다는 생각은 이 시기 개발자들 사이에서 더 이상 기우가 아닌 현실적인 공포로 다가오기 시작했습니다.
7. DeepSeek R1으로 시작된 가격 파괴와 생태계의 분화
이전 세대 모델들이 성능의 정점을 향해 치달으며 API 호출 비용 또한 천정부지로 솟았습니다. 특히 o1-pro 모델이 기록한, 백만 토큰당 입력/출력에 각각 75달러/150달러라는 경이로운 가격은 그 정점이자 버블의 상징과도 같았습니다. 모두가 이 비용을 감당할 수는 없었기에, 최상위 모델은 그저 선망의 대상일 뿐이었죠. 바로 이 시점에, DeepSeek R1의 등장은 그 판 자체를 뒤흔든 사건이었습니다.
모두에게 충격을 안겨주었죠. RLHF(Reinforcement Learning from Human Feedback)와 같은 고도화된 기법을 통해, 상대적으로 규모가 작은 중국의 스타트업이 OpenAI, Anthropic, Google과 어깨를 나란히 하는, 혹은 특정 영역에서는 그들을 뛰어넘는 모델을 만들어낸 것입니다. 검열과 같은 일부 사소한 문제점을 차치하더라도, DeepSeek이 보여준 기술적 성취와 그 학습 방법론은 업계 전체에 엄청난 파급력을 미쳤습니다. 개인적으로 이는 두 가지 중요한 관점에서의 진보를 촉발했다고 평가합니다.
첫째, 최상위 모델 개발에 대한 장벽이 무너지며 본격적인 '가격 파괴'가 시작되었습니다. 이전까지 최신예 LLM 구축은 빅테크만의 영역이라는 인식이 지배적이었습니다. 하지만 DeepSeek은 "우리가 투입한 정도의 자본과 노력이라면, R1 수준의 모델을 충분히 만들어낼 수 있다"는 강력한 증거가 되었습니다. 이는 자체 모델 구축에 소극적이거나 엄두를 내지 못했던 수많은 기업들이 경쟁에 뛰어드는 계기가 되었습니다. 너도나도 강력한 모델을 더 저렴하게 제공하려는, 진정한 의미의 '치킨게임'이 시작된 것입니다. 그 결과, o1-pro가 찍었던 정점을 끝으로 API 가격은 가파르게 하락하기 시작했습니다.
둘째, MoE(Mixture of Experts) 아키텍처의 대중화와 함께 의미 있는 중간 수준(Mid-tier) 모델이 폭발적으로 증가했습니다. 하나의 거대한 통짜 모델을 만드는 대신, 언어, 코딩, 추론 등 특정 분야에 특화된 여러 '전문가(Expert)' 모델을 두고, 입력된 질문의 성격에 따라 필요한 전문가만 활성화하여 문제를 푸는 MoE 방식이 핵심 기술로 떠올랐습니다. 이는 전체 모델의 잠재적 규모는 거대하게 유지하면서도, 실제 연산 비용과 응답 시간은 획기적으로 줄이는 결과를 낳았습니다. DeepSeek이 보여준 증류(Distillation) 기법과 MoE 아키텍처의 결합은, "강력하면서도 효율적인 모델을 만들 수 있다"는 새로운 공식을 제시했습니다. 이는 곧 o3, o4와 같이, 대부분의 일상적인 코딩 작업에서는 대형 모델 못지않은 성능을 내면서도 훨씬 가볍고 빠르게 동작하는 모델들의 등장을 이끌었습니다.
결국 이 시점부터 LLM 시장은 단순히 '가장 강한 모델' 하나를 좇는 것이 아니라, '상황에 맞는 최적의 모델'을 현명하게 조합하여 사용하는 다채로운 생태계로 진화하기 시작했습니다.
8. 사람을 아득히 뛰어넘는 모델의 등장: Gemini 2.5 Pro
모든 프로그래머들은 절망을 느끼기 시작했습니다.
Gemini 2.5 Pro의 등장은 이전 세대의 모델들과는 차원이 다른 충격이었습니다. 이 모델은 모호한 기획서 한 장을 입력받아, 백엔드 API, 프론트엔드 UI, 데이터베이스 스키마, 테스트 코드, 그리고 클라우드 배포를 위한 CI/CD 파이프라인까지 포함된 완벽한 프로젝트 저장소를 단 몇 분 만에 생성해냈습니다.
무엇보다 이 변화가 더욱 서늘하게 다가오는 이유는, 그동안 인간의 한계가 만들어낸 '기술적 관성'을 완전히 파괴해버리기 때문입니다. 실제 실무에서는 다음과 같은 일들이 왕왕 발생합니다. Rust 백엔드가 성능과 안정성 면에서 뛰어나다는 점은 모든 프로그래머들이 인정합니다. 하지만 Rust를 능숙하게 다루는 개발자는 드물고, 관련 프레임워크 생태계에 익숙한 인력은 더더욱 구하기 어렵습니다. 결국 수많은 기업은 인력 수급이 용이하다는 이유 하나만으로, 기술적 우월성을 알면서도 기존의 Java Spring에 머무르는 결정을 내립니다.
이것은 그저 가상의 이야기가 아닙니다. 저 역시 비슷한 경험을 직접 겪었습니다. 저는 개인적으로 간결하고 반응성이 뛰어난 Svelte를 열렬히 사랑하지만, 실제 프로젝트에 도입하기에는 Svelte 개발자를 구인할 수 없어 울며 겨자 먹기로 Next.js를 선택해야만 했습니다. 기술적 이상과 현실의 채용 시장 사이에서 타협할 수밖에 없었던 것입니다.
그런데 이 시기 이후에는 더 이상 그럴 필요가 없었습니다. LLM은 제가 그토록 찾아 헤맸지만 고용할 수 없었던 그 'Svelte 전문가'의 역할을 완벽하게 수행했습니다. 저는 가장 이상적이라고 생각했던 기술 스택으로 성공적인 풀스택 서비스를 재구축할 수 있었습니다. 물론, 그 대가는 명확했습니다. 신규 인력 채용 계획은 대부분 사라졌습니다. 결과적으로 LLM만으로 더 뛰어난 결과물을 얻게 되면서, 인간 개발자를 고용해야 할 필요성 자체가 극적으로 줄어든 것입니다.
9. 진정한 절망의 시작: Sonnet-4 와 GPT-5
이전 세대의 Gemini 2.5 Pro가 아무리 강력했어도, 거기에는 마지막 심리적 안전장치가 존재했습니다. 바로 '비용'이었습니다. 하루 10시간 기준, 미친 듯한 속도로 모델을 활용하는 '올타임 바이브 코딩'을 한다면 하루에 100달러 이상을 지출해야 할 정도로 비쌌습니다. 이는 마치 F1 머신과 같아서, 그 성능은 경이롭지만 모든 개발자가 매일 출퇴근용으로 쓸 수는 없는, 특별한 날에만 사용하는 고급 도구와 같았습니다.
그러나 상대적으로 합리적인 가격의 Sonnet-4는 그 마지막 가격적인 장벽마저도 무자비하게 부숴버렸습니다.
Sonnet-4는 Gemini 2.5 Pro가 보여준 압도적인 천재성에는 미치지 못할지 모릅니다. 하지만, 뛰어난 시니어 개발자 서너 명의 역할을 충분히 해내면서도 그 비용은 인간 개발자 한 명의 월급에도 미치지 않았습니다. 그 결과, AI 활용은 더 이상 '특별한 투자'가 아닌 '당연한 기본 비용'이 되었습니다. 개발의 모든 과정에서 AI를 물처럼, 공기처럼 사용하는 시대가 열린 것입니다. 더 이상 비용 때문에 AI 사용을 망설일 이유가 사라졌습니다.
지금 바이브 코딩의 수준은 대략적으로 다음과 같습니다.
Svelte5, drizzle, tailwindcss만을 사용해서 완벽히 동작하는 sveltekit 기반의 풀스택 어플리케이션, DB 스키마와 인증 로직까지 만들어줘
이 한 문장이 이제 개발의 시작이자 끝입니다. 더 이상 폴더 구조를 고민하고, 데이터베이스 테이블을 설계하며, API 엔드포인트를 하나하나 만들 필요가 없습니다. 개발자는 그저 자신이 원하는 최종 결과물의 '분위기(Vibe)'와 핵심 요구사항을 전달할 뿐입니다. AI는 필요한 질문 몇 개를 던진 뒤(예: "인증은 구글 OAuth를 사용할까요, 아니면 이메일/비밀번호 방식을 선호하시나요?"), 전체 프로젝트를 스스로 구축합니다.
귀찮아서 구축하지 않았던 리프레쉬 토큰 로직 조차도, 내가 언급하지 않았음에도 불구하고 보안을 위해 자동으로 완성되어 있습니다. zod를 활용한 꼼꼼한 유효성 검사(validation)는 기본적으로 포함되고, 사용자 경험을 해치지 않는 세심한 에러 핸들링도 당연히 존재합니다. Sveltekit의 hook에 대한 언급을 하지 않았음에도, 프레임워크의 철학을 완벽하게 이해하고 hook 기반으로 모든 인증, 검증 과정을 가장 합리적으로 구축해 놓습니다. 그 코드는 사람이 급하게 작성했을 때 흔히 보이는 타협의 흔적이나 '나중에 수정해야지' 하는 식의 기술 부채가 전혀 존재하지 않습니다.
바로 이 지점이 '진정한 절망'의 핵심입니다. 나의 경험과 노하우, 심지어 나의 게으름과 실수까지도 모두 뛰어넘는 존재가 등장한 것입니다.
Sonnet-4, GPT5의 품질에 부족함을 느낄때가 있습니다. 그 경우에는 돈을 조금 더 쓰더라도 Gemini-2.5-pro, opus-4를 쓰면 그만인 시대가 되어버렸습니다.
10. 결론
주니어 개발자는 이제 정말 끝인것 같습니다(특히 프레임워크 중심의 국비학원..). 코딩을 배우기 보다는 비즈니스 로직과 메타 프로그래밍과 같은 고차원적 사고 능력에 집중해야 하는 시대가 되었습니다.
더 이상 문법을 외우고 프레임워크 사용법을 익히는 것이 개발자의 핵심 역량이 아닙니다. 중요한 것은 "무엇을 만들 것인가"에 대한 명확한 비전과, 그것을 AI에게 정확하게 전달할 수 있는 소통 능력입니다. 프로그래밍 언어는 AI가 완벽하게 구사하지만, 사용자의 진짜 니즈를 파악하고 비즈니스 가치를 창출하는 것은 여전히 인간의 영역입니다.
앞으로 살아남을 개발자는 두 부류입니다. 첫째는 AI조차 해결하기 어려운 최첨단 기술적 문제를 다루는 극소수의 엘리트 개발자들입니다. 둘째는 개발자라기보다는 '비즈니스를 이해하는 AI 오케스트레이터'에 가까운 역할을 하는 사람들입니다.
전통적인 의미의 개발자, 즉 요구사항을 받아 코드로 구현하는 역할은 이미 AI에게 완전히 대체되었습니다. 이제는 AI를 도구로 활용하여 비즈니스 문제를 해결하고, 사용자 경험을 설계하며, 제품의 방향성을 결정하는 능력이 더욱 중요해졌습니다.
결국 개발이라는 행위 자체보다는, 개발을 통해 달성하고자 하는 목표와 그 과정에서 발생하는 수많은 판단들이 인간만이 할 수 있는 고유한 영역으로 남게 되었습니다. 코딩은 끝났지만, 진정한 의미의 '문제 해결'은 이제 막 시작된 것일지도 모릅니다.
