[고찰] 생성형 AI와 함께하는 개발 경험을 돌아보며

생성형 AI 도구 사용 연대기

오늘 글은 미래를 예측해보려는 것은 아니고 AI 에이전트를 사용하지 않던 마지막 개발자 세대로서 겪었던 경험들과 생각을 더 늦기 전에 정리해보려고 한다. 본인의 개인 경험에 기반하여 쓴 글이기에 세계적인, 학문적인 시점과는 일부 차이가 있을 수 있다.

2026년 10월 현재, LLM 기반 생성형 AI 도구(이하 편의상 AI로 지칭)는 빠르게 세상을 변화시키고 있다. OpenAI의 GPT-6 Astra(아스트라)는 놀라운 성능으로 세상을 다시금 놀라게 했고, 공개되지 않은 내부 모델은 밀레니엄 문제인 나비에-스토크스 문제를 88시간 만에 풀었다고 발표하기도 하였다(다만 독립적인 검증과 선행 연구 관련 논란은 아직 진행 중이다).

메타의 Muse(뮤즈)는 개인정보 보호 등의 우려가 남아있긴 하지만 기업과 개발자를 넘어서 일반 사용자들에게까지 닿을 수 있는 개인용 AI 에이전트 서비스를 선보였고, 앤트로픽의 클로드 또한 개발자 진영에서 뛰어난 개발 생산성을 보이며 압도적이고 폭넓은 지지를 받고 있다.

필자도 현역 개발자인 만큼 기술적 호기심도 있고, 또 어떻게 보면 거대한 흐름에 맞게 사용하게 되기도 하였다. 올해 들어서는 AI 에이전트 없이 순수하게 개발한 적은 손에 꼽을 정도이며(기억나는 몇 안 되는 순간은 단순 API 확장 작업이다.), 단순히 프로그래밍할 때뿐 아니라 여러 방면에서 생성형 AI 도구를 매우 유용하게 활용하고 있다.

신기하고도 두려운 것은, 지금 시점에서 아직도 과도기에 불과하다는 생각이 드는 것이다. 어떤 식으로 나아갈지는 아직 모르겠으나, 이제까지만큼 아니 이제까지보다 더 생산성의 증가가 있으리라는 생각이 강하게 든다. 예상하기로는 이미 상당 부분 진행되긴 했지만, SDD(Spec-Driven Development)가 아닐까 싶기는 하다. 다만 이 개념은 2025년 하반기 AWS의 Kiro와 GitHub의 Spec Kit 등으로 주목받기 시작한 지 1년이 넘었음에도 빠르게 주류가 되지는 않았(다고 느끼)기에 다를 수도 있겠다.(SDD 참고1, SDD 참고2)

2010년대

필자는 2020년 입사이므로 2010년대는 학생이었지만, 어렸을 때부터 관심을 가지고 있어서 적게나마 기억이 있다. 2010년에는 Visual Studio 2008을 집에서 설치해서 책을 보고 메모장처럼 코드를 입력하여 실행해봤던 기억이 있었고, 2011년에는 학교 방과후 수업에서 수강했을 때도 강의를 들으면서 문제를 풀고 따라 입력하기는 했으나 크게 벗어나지는 않았던 것으로 기억한다.

말하자면, 필자의 기억 속 2010년대 초반은 "모든 걸 손으로 다 입력하는 시대"였다.

2010년대 들어 스마트폰이 본격적으로 보급되고 모바일 시장이 커졌고, 2016년 알파고가 이세돌 九단에게 4:1로 승리하며 대중들에게 새로운 시대를 선보이면서 IT 업계는 (적어도 한국 내에서는) 급격하게 변하였다. 2017~2018년 Android Studio와 Visual Studio 2017 등을 사용해보면서 전에 비해 확실히 편의성이 증가한 느낌을 받았다. Android의 경우 조잡하기는 했으나 GUI로 UI 코드를 만들어낼 수도 있었고, 자동완성, 코드 포매터 등 편의성을 위한 도구들이 크게 늘어났다.

물론 미성년자 때 취미(?)와 전공자 학부생으로서 받아들이는 것이 달랐을 수도 있지만, 2010년대 초반에 비해 편의성이 많이 증가한 느낌은 받았으나 개발의 근본적인 패러다임은 바뀌었다고 생각하지 않았다.

2020년~2021년

본격적으로 개발자 업계에서 일을 시작했지만, 학부생 시절과 하는 일이 크게 달라졌다고 생각하지는 않았다. 물론 회사 내에서 개발하기 때문에 개발 프로세스에 대해서 배우고, 기획자나 운영팀 등과 함께 일하거나 라이브 고객들에게 서비스하는 경험도 쌓았으나 기술적인 변화를 느낀 것은 아니었다.

2021년 GitHub Copilot의 등장

2021년 6월 29일 GitHub Copilot이 테크니컬 프리뷰로 세상에 처음 발표되었다. 당시 내 기억은 자동으로 코드를 작성해주는 도구라고 하여 매우 신기하게 생각했던 경험이 있었고, 시연을 봤을 때 웹 페이지 코드를 작성하는 걸 보면서 대단하다는 생각을 했었다.

실제로 사용하려고 해 봤는데, 당시 회사에서는 보안상 사용할 수도 없었고, 함수의 주석을 자동으로 달아주는 정도가 보통 사용하는 범위인 것 같기도 했다. 하지만 그 당시 코드를 읽고 분석하는 것은 어쨌든 인간이 진행해야 한다고 생각했었기에 매우 놀라긴 했었다. 2019년에 정적 분석 도구인 SonarQube를 인턴 시절 활용해보긴 했으나, 결국 인간이 보고 처리해야 했던 기억이 있어서 더 그랬던 것 같다.

어쨌든 당시에는 신기한 경험 한 번 했고, 이미 코로나19 경기 침체와 맞물려 개발자 붐이 일어나며 AI와 (한국 한정) 4차 산업혁명 등의 키워드가 우후죽순으로 늘어나고 또 각광받던 시기였기 때문에 자연스럽게 잊혀져 갔다. 당시에는 자동화 같은 것이 있으면 AI나 스마트 글자를 붙여서 과대 마케팅하는 경우가 많았기에 그런 것을 별로 좋아하지 않았던 개인 성향도 한몫했다고 생각한다.

2022년 GPT-3.5 기반 챗봇, 2023년 GPT-4 등장

그렇게 필자의 기억 속에서 잊혀져가던 AI 도구 활용은, 2022년 11월 30일 GPT-3.5 계열 모델 기반의 챗봇인 ChatGPT가 공개되면서 또다시 전환점이 왔다. 이때만 해도 위의 GitHub Copilot과 유사하게 테스트 정도 해보고 말았으나, 2023년 3월 GPT-4가 등장하면서 아주 간단한 일은 물어볼 수 있겠다는 생각이 들었다.

이를테면 정규 표현식을 만들거나 아주 정형화된 함수를 물어보는 일 정도는 잘 해냈었다. 물론, 수동으로 만드는 것이 더 익숙하던 시기이기에 이미 만든 것을 다듬거나 검증해달라고 하기도 했고, 그 이후에도 여러 번 테스트를 거쳐서 사용해야 했기 때문에 실무에서 바로 사용하기에는 아직은 무리가 있는 수준이었다.

2024년 후반까지는 코드를 짤 때 활용하는 일은 거의 없었고, 단순히 기술적 호기심과 단순 작업 보조를 위해 가끔 질의하는 정도로 활용을 해왔다.

2025년 Gemini, ChatGPT 등 LLM의 폭발적 증가

2025년 들어서 비약적으로 ChatGPT나 Gemini 등 LLM의 성능이 증가했다는 말을 듣고, 조금 더 적극적으로 활용하기 시작했다. 이때쯤부터 구글링을 거의 하지 않게 되었고 단순한 스크립트나 짧은 함수들은 채팅창에 복사 붙여넣기 하여 검증을 받거나 아예 프롬프트를 정교하게 넣은 후에 생성을 요청하여 내가 수정하여 적용하기도 했다. 이때는 아직 에이전트가 아니었기 때문에 프로젝트의 맥락을 이해하지 못하거나 채팅창도 대화가 길어지면 이전 맥락을 잃어버리는 등의 문제가 있었기에 제한적으로 활용을 해 왔다.

이보다 앞서 2023년부터 Cursor와 같은 AI 네이티브 IDE도 이미 출시되어 주목받고 있었으나, 필자는 생산성에 큰 차이가 없다고 생각하기도 했고 환경을 세팅하는 게 복잡하기도 해서 사용하지는 않았다.

마침 2025년 중반에 회사에서 공식적으로 생성형 AI 사용에 대한 비용 지원을 해줘서 ChatGPT를 더 깊게 활용하게 되었다. 당시 맡았던 프로젝트에서 그동안 실무에서 다루어보지 않았던 AWS CDN 자동화에 대한 업무를 혼자 담당하게 되었는데 GPT와 함께 일하면서 아직까지는 없는 함수를 사용하라는 등 AI 환각도 있었고 채팅창 복붙의 한계상 맥락을 알지 못하므로 내가 수정하는 부분이 큰 부분을 차지했으나 이때 개발에 대한 완전히 새로운 경험을 겪었다고 생각한다.

그 전까지는 생성형 AI가 없었다고 해도 내가 해내지 못할 것은 아니었으나, 당시 프로젝트는 생성형 AI가 없었다면 혼자 기한 안에는 해내지 못했을 것이라는 생각이 들었고, 거대한 변화 속에 이미 내가 들어와있음을 느끼면서 불안함도 처음으로 느끼게 되었다.

2025년 코딩 에이전트의 폭발적 증가

위 경험을 내가 하고 있을 때, 2025년 4월 OpenAI의 Codex CLI, 5월 Claude Code 정식 출시(2월 리서치 프리뷰), 6월 Gemini CLI 등 세상에는 코딩 에이전트가 이미 등장하고 있었다. 출시 당시에도 들어서 알고는 있었으나, Cursor 때와 비슷하게 생산성에 얼마나 차이가 있겠나 싶기도 했고, 채팅창으로 개발함에도 부족함이 없다고 느꼈기 때문에 도입은 해보지 않았었다.

2025년 연말이 되어서야 당시 발전이 빠르다는 평을 받던 Gemini CLI를 활용해보았고, 사내 Git PR 리뷰에도 사용해보았다. 초기 세팅이 나름 복잡하였지만 PR의 diff에 대해 자동으로 코멘트를 해주고 프로젝트 전체를 분석해서 맥락을 파악하여 질문에 답을 해주고 코드를 생성하는 경험은, 이제까지 생성형 AI 도구를 활용해보면서 처음 느끼는 엄청난 순간이었다. 가히 학생 때부터 10년 간의 개발자 인생 중에 가장 충격받았던 순간이 아닐까 싶다.

심지어 그렇게 자동 생성해준 코드는 잘 돌아갔고, 나보다 잘 짠다는 생각까지 들게 만들 정도였다!

2026년 들어서는 Gemini CLI를 활용하는 빈도수가 훨씬 늘어났고, 직접 코드를 입력하는 경우는 그에 반비례하여 매우 줄어들게 되었다. 다만 회사에서 지원해주던 유료 토큰으로는 마음껏 활용하기는 어려웠는데, 2026년 중반 회사에서 Claude Code를 엔터프라이즈로 구매하면서 개발 업계에서 유명했던 Claude Code로 넘어오게 되었다.

코드를 생성하는 능력은 필자도 벤치마크만 보고 대략적으로 파악하는 것이지, Codex, Gemini, Claude 모두 비슷한 수준이라고 생각한다. 다만 편의성에서는 Claude Code가 압도적이라고 생각하는데, 환경 세팅이 매우 편리하여 접근성이 좋았다고 느껴졌다. 이는 결국 제품 사용성에 대한 관점에서는 사용자가 접근하기 편리해야 모두에게 체감되는 것이므로 ChatGPT가 처음 채팅과 함께 등장했을 때 비슷한 느낌을 받기도 하였다.

Claude Code를 사용한 이후로는 회사 차원에서 PR의 리뷰를 Claude가 달게 되었고, 여러 가지 검증 장치 또한 Claude가 맡게 되었다. Claude Code는 로컬에서 실행되므로 로컬 프로젝트 폴더를 참조시킬 경우 프로젝트 전체를 분석하고 맥락을 파악하여 요청 사항을 처리하고, 빌드나 cpplint 등 제약사항을 통한 검증 또한 스스로 수행하였다. 최근에 요청한 무거운 프로세스가 있었는데, (토큰은 많이 쓰긴 했지만) 3~4개의 서브에이전트를 스스로 띄워서 자문자답하는 형식으로 개선안을 검증하여 승인/기각을 스스로 하여 대답을 도출하는 등 현 시점에서도 실시간으로 발전해나가는 것이 느껴진다.

이 시점에서 나의 역할은?

당연히 이제까지의 나의 경험을 통해서 나의 역할은 어디로 옮겨가야 하는지가 계속해서 고민이 되고 있다. 기술적인 부분은 이제 거의 제약이 사라지고 사람의 의사 결정이 병목이 되어가는 요즘, 어떤 역할을 해나가야 할까?

우선은, 전적으로 AI만 믿고 넘어가는 것은 아직까지 위험하다고 생각한다. 왜냐하면 AI는 책임을 질 수 없기 때문이다. 결국 AI를 사용한 사용자에게 책임이 넘어갈 것이고, 그 결과물을 검증하는 것은 인간이 아직까지는 해야 한다고 생각한다. 검증 또한 AI의 도움을 받을 수는 있겠지만 말이다.

테스터처럼 구현된 결과물을 빌드해서 기능을 실행해보는 것으로 검증할 수도 있겠고, 당연히 이도 해야 하지만, 개발자들은 생성된 코드에 대해서 적어도 읽어보고 이해하고 넘어가야 한다고 생각한다. 물론 라인 바이 라인으로 읽으면 AI로 인한 생산성 향상을 누릴 수 없으므로 딜레마이긴 하지만, 큰 틀에서 어째서 이런 코드가 나왔는지, 그리고 도메인에 얽힌 부분이나 히스토리가 있는 레거시 코드의 경우 아직까지는 완벽하게 분석 및 변경하지 못하기 때문에 코드를 읽고 고쳐주는 것이 필수적이라고 생각한다.

그래도 지금까지 6~7년간의 경험으로 코드를 읽는 훈련이 꽤 되어 있어서 아직까지는 따라갈 수 있는 편이지만, 내 이후 세대들은 학생 때부터 AI가 있었을 텐데 어떻게 될지 또한 요즘의 관심거리이긴 하다. 코드를 써 봐야 읽을 줄 알기도 하고, 읽는 것은 더욱 많이 해봐야 한다고 생각하는데 둘 다 AI의 등장 이후로는 귀찮은 작업이 되어버렸으니...

어쨌든 당장에 개발자라는 직업이 증발하거나 하지는 않겠지만 불과 1~2년 사이에 코드를 입력하여 생산해내던 직업의 느낌은 많이 사라지고, 동작 원리를 이해하고 개발과 유지 보수를 생성형 AI를 통해 지시 및 검증하는 서비스 엔지니어라는 직업의 느낌이 강해지고 있다. 천공카드를 뚫던 기술자가 사라지고 직접 타이핑해서 설계를 컴퓨터 위로 옮겼던 시대와 동일하게 코드를 옮기는 기술자가 사라지고 원리를 잘 이해하고 설계를 잘 해내는 엔지니어로 나아가야 하지 않을까라는 생각이 드는 요즘이다.

때문에 자동으로 PR에 리뷰가 달리고 개선안까지 달리더라도 기계적으로 수정하는 것은 절대적으로 지양하고, 남이 올린 PR이어도 diff에 대해서는 충분히 숙지하고자 코드를 읽어보고 로직적인 흐름은 대략적으로 그려보면서 검증을 한다. 이런 과정에서 실제로 AI가 도메인적인 변수에 대해서 헷갈린 부분을 찾아서 수정하기도 하는 등(보안상 자세히 말할 수는 없으나 이름이 비슷하지만 다른 역할의 두 변수였다.) 아직까지도 완전히 만능은 아닌 모습을 보이고 있기도 하다.

이런 일련의 과정들이 쌓인다면 생성형 AI 시대에 맞는 훈련이 되지 않을까 하는 생각이 막연하게 들기도 한다.

 

마치며

글 중간에도 말하긴 했지만, 지금은 엄청난 변화의 와중이라고 생각한다. 휩쓸려 사라지지 않도록 트렌드를 잘 읽고 좋은 방향을 잡을 수 있도록 모두 잘 해나가야 한다고 생각한다. 글에서는 AI를 통해 향상된 생산성을 위주로 얘기하다보니 좋은 점 위주로 글이 작성되었는데, 당연히 범람하는 AI 티가 나는 글 등 문제점도 함께 나타나고 있기도 하다. 본인부터도 그런 글을 싫어하는 편이고... 나에게 그런 경험이 쌓이고 기회가 된다면 그런 글도 다루어볼까 싶기도 하다.

이 글을 읽은 모두들 잘 살아남기를 기원한다!