AI 활용법, 1년 반 만에 완전히 바뀌었다 — 프롬프트 엔지니어링은 이제 필요 없을까?
2024년 11월 말, 처음으로 AI를 사용했다.
그로부터 1년 반. 그 사이에 일어난 변화는 단순한 도구의 발전이 아니었다. 일하는 방식 자체가 바뀌었고, 바뀌는 속도 자체가 가속되고 있다. 처음에는 6개월 단위로 새로운 패러다임이 등장했다. 그것이 3개월로 줄었고, 지금은 한 주가 멀다 하고 새로운 것이 쏟아진다.
AI는 태동기를 지나 과도기에 접어들었다. 그리고 과도기의 한가운데에 서 있는 지금, 이 1년 반을 돌아보는 것이 의미가 있겠다는 생각이 들었다.
과거 — 복사 붙여넣기, 그리고 프롬프트 엔지니어링
대화창 시대
정확히 말하면 ChatGPT에 코드를 물어보는 것부터 시작했다. 함수 하나, 에러 메시지 하나를 붙여넣고 답변을 받아 복사해서 에디터에 옮기는 방식. 구글 검색 대신 AI에게 물어본다는 것 자체가 신선했고, 답변의 정확도에 꽤 놀랐다. 하지만 사용 방식은 본질적으로 검색과 다르지 않았다. 질문하고, 답변을 읽고, 수동으로 적용하는. 그 반복이었다.
그때는 이것만으로도 충분히 혁신적이라고 생각했다.
프롬프트 엔지니어링이라는 발견
몇 달이 지나자 한계가 보이기 시작했다. 같은 질문인데 어떻게 물어보느냐에 따라 답변의 질이 확연히 달라졌다. "이 코드 고쳐줘"라고 하면 대충 수정해주지만, 역할을 부여하고 맥락을 설명하고 출력 형식을 지정하면 전혀 다른 수준의 결과가 나왔다.
2025년 초, 프롬프트 엔지니어링을 본격적으로 학습하기 시작했다.
시스템 프롬프트 설계, 체인 오브 씽킹, 퓨샷 러닝, 역할 지정. 프롬프트 하나를 설계하는 데 코드를 작성하는 것만큼의 시간을 들이기도 했다. 실제로 효과가 있었다. 같은 모델이라도 프롬프트에 따라 주니어 개발자 수준의 답변과 시니어 개발자 수준의 답변을 오갔다. AI를 제대로 활용하려면 프롬프트 엔지니어링은 필수라고 확신했다.
그런데 그 확신은 오래가지 않았다.
프롬프트 엔지니어링의 퇴장
2025년 중반, Claude Code와 OpenAI Codex 같은 CLI 기반 AI 도구가 등장했다.
이 도구들은 대화창에서 코드를 주고받는 방식이 아니었다. 터미널에서 직접 코드베이스를 읽고, 파일을 수정하고, 테스트를 실행했다. 프로젝트 전체의 맥락을 이해한 상태에서 작업했다. 내가 정교하게 프롬프트를 설계하지 않아도, 도구 자체가 맥락을 파악하고 적절한 행동을 했다.
프롬프트 엔지니어링의 중요성이 급격히 줄어드는 걸 체감했다.
처음에는 받아들이기 어려웠다. 몇 달간 공들여 학습한 스킬이 이렇게 빨리 가치를 잃어가다니. 하지만 곧 깨달았다. 역프롬프트 엔지니어링이라는 방법이 있기 때문이다. AI에게 "이 작업에 최적의 프롬프트를 만들어줘"라고 하면 사람이 설계하는 것보다 더 정밀한 프롬프트를 만들어냈다. 프롬프트를 잘 쓰는 기술이, 프롬프트를 잘 만들어달라고 요청하는 기술로 대체되는 순간이었다.
물론 프롬프트 엔지니어링의 기본 원리를 아는 것 자체는 여전히 유용하다. AI가 어떻게 입력을 해석하는지 이해하고 있으면 커뮤니케이션의 효율이 다르다. 다만 정교한 프롬프트를 수작업으로 다듬는 행위 자체는 점점 의미가 줄어들고 있다.
지금 돌아보면 이 시기까지가 AI의 태동기였다. 도구가 나오고, 사람들이 사용법을 학습하고, 새로운 기법이 발견되는 시기. 변화의 주기는 대략 6개월이었다. 반년 정도면 새로운 패러다임이 하나씩 등장했다.
현재 — 과도기의 한가운데
복사 붙여넣기의 종말
돌이켜보면 가장 큰 변화는 작업 방식 자체였다.
초기에 AI를 사용할 때는 이런 흐름이었다. 대화창에 요청을 입력한다. AI가 코드를 보여준다. 그 코드를 복사한다. 에디터에 붙여넣는다. 실행해본다. 에러가 나면 에러 메시지를 다시 복사해서 붙여넣는다. 이 과정을 반복한다. 컨텍스트 스위칭의 연속이었고, 작업의 절반은 복사와 붙여넣기에 소비되었다.
지금은 완전히 다르다. CLI 도구는 코드베이스 전체를 읽는다. 변경이 필요한 파일을 스스로 찾아 수정한다. 수정한 코드를 테스트한다. 테스트가 실패하면 원인을 분석하고 다시 수정한다. 계획을 세우고, 실행하고, 결과를 검증하고, 필요하면 계획을 수정한다. 개발자가 하는 일련의 과정을 AI가 자율적으로 수행한다.
내가 하는 일은 방향을 제시하고 결과를 검토하는 것으로 바뀌었다. 코드를 한 줄 한 줄 작성하는 대신, 무엇을 만들지를 설명하고 AI가 만든 결과물을 리뷰한다. 개발자의 역할이 작성자에서 설계자와 감독자로 이동하고 있다.
에이전트 팀의 등장
그리고 지금, 2026년. AI 활용은 또 한 단계 진화했다.
단일 에이전트가 코드를 작성하는 것을 넘어, 여러 에이전트가 팀을 이루어 협업하는 단계다. 전략 에이전트가 방향을 설계하고, 프로덕션 에이전트가 실행하고, 품질 에이전트가 검수한다. 각 에이전트는 자신의 전문 영역에 특화되어 있고, 오케스트레이터가 이들을 조율한다. 소프트웨어 개발 팀의 구조를 AI로 재현하는 것이다.
더 흥미로운 건 최근 유행하는 AI 회사 구축이다. CEO 에이전트를 만들면 이 에이전트가 회사의 비전을 수립하고, CTO나 CPO 같은 서브 에이전트를 영입한다. 이 에이전트들은 다시 각자의 사업팀을 구성한다. 사람이 조직을 만드는 방식 그대로를 AI가 재현하는 것이다. 처음 들었을 때는 과장이라고 생각했다. 하지만 직접 에이전트 팀을 구성해 블로그를 운영해보니, 이 방향이 단순한 유행이 아니라는 걸 체감하고 있다.
가속되는 변화의 주기
지금 이 시점이 과도기라고 느끼는 이유가 있다.
1년 전만 해도 AI 생태계의 변화 주기는 대략 6개월이었다. ChatGPT가 나오고 반년쯤 지나 프롬프트 엔지니어링이 주목받았고, 또 반년쯤 지나 CLI 도구가 등장했다. 그런데 2025년 후반부터 그 주기가 3개월로 줄었다. 에이전트 코딩, 멀티 에이전트, MCP 프로토콜, 역프롬프트 엔지니어링. 새로운 개념이 분기마다 쏟아졌다.
그리고 2026년 지금, 한 주가 멀다 하고 새로운 것이 나온다. 이번 주엔 새로운 모델이, 다음 주엔 새로운 프레임워크가, 그 다음 주엔 기존 패러다임을 뒤집는 접근법이 등장한다. 변화의 간격이 6개월에서 3개월로, 3개월에서 한 주로 압축되고 있다.
이건 태동기의 패턴이 아니다. 태동기에는 큰 변화가 가끔 일어난다. 지금은 작은 변화가 끊임없이 일어나면서 전체 판도를 계속 재편하고 있다. 기술이 성숙하기 전에 다음 기술이 나오고, 그 기술이 자리잡기 전에 또 다음 것이 나온다. 전형적인 과도기의 모습이다.
미래 — 과도기 너머에는 무엇이 있을까
과도기는 영원하지 않다
모든 과도기에는 끝이 있다. 인터넷도 그랬다. 90년대 후반 닷컴 버블 시절, 매주 새로운 서비스와 비즈니스 모델이 쏟아졌다. 대부분 사라졌고, 살아남은 것들이 지금의 인터넷을 형성했다. 스마트폰도 마찬가지다. 초기에는 수십 개의 모바일 OS가 난립했지만, 결국 두세 개의 플랫폼으로 수렴했다.
AI도 결국 수렴할 것이다. 지금 매주 쏟아지는 도구와 프레임워크 중 대부분은 사라질 것이고, 살아남는 것들이 표준이 될 것이다. 그때가 되면 지금의 혼란은 정리되고, AI 활용은 전기나 인터넷처럼 당연한 인프라가 될 것이다.
그때까지 우리는 무엇을 해야 하는가
문제는 과도기가 얼마나 지속될지 아무도 모른다는 것이다. 1년일 수도 있고, 5년일 수도 있다. 그 사이에 확실한 것은 하나뿐이다. 지금 내가 아는 방식은 곧 구식이 된다는 것.
정리하면 이렇다.
- 2024년 11월 — 대화창에 질문하고 코드를 복사 붙여넣기 (변화 주기: ~6개월)
- 2025년 초 — 프롬프트 엔지니어링 학습, 정교한 프롬프트 설계
- 2025년 중반 — CLI 도구 등장, 프롬프트 엔지니어링의 중요성 감소 (변화 주기: ~3개월)
- 2025년 후반 — 역프롬프트 엔지니어링, AI가 프롬프트를 설계
- 2026년 — 에이전트 팀 구성, AI 조직 구축 (변화 주기: ~1주)
- 미래 — ?
프롬프트 엔지니어링을 열심히 배울 때는 이것이 AI 시대의 핵심 역량이 될 줄 알았다. 그런데 반년도 안 돼서 CLI 도구가 그 필요성을 상당 부분 대체했다. 에이전트 팀 역시 지금은 최전선이지만, 이 가속도라면 몇 달 후에는 또 다른 패러다임이 등장할 수 있다.
AI 활용 능력에서 중요한 것은 특정 기술이 아니라 변화에 적응하는 속도다. 프롬프트를 잘 쓰는 기술보다, 새로운 도구가 나왔을 때 빠르게 파악하고 자신의 워크플로우에 통합하는 능력이 더 중요하다.
과도기는 불안하다. 어제 배운 것이 오늘 쓸모없어질 수 있다. 하지만 과도기이기 때문에 기회이기도 하다. 판이 정해지지 않았다는 건, 누구든 빠르게 적응하는 사람이 주도권을 잡을 수 있다는 뜻이다.
지금 내가 하는 방식도 곧 구식이 될 것이다. 그것을 받아들이는 유연함이, 어쩌면 AI 과도기를 살아가는 가장 현실적인 전략일지도 모른다.
댓글
댓글 쓰기