AI 발전의 끝은 어디인가 — 현업 개발자가 본 기술의 천장
지난달에 한 스타트업 창업자가 나에게 물었다. "AI가 계속 이런 식으로 발전하면, 2030년쯤엔 AGI가 나올까요?" 나는 한숨을 쉬었다. 불과 두 달 전에도 똑같은 질문을 받았고, 그 전해도, 그 전전해도. 1998년부터 개발해온 시간 동안 나는 이런 질문들을 몇십 번 들었다. 다만 주인공이 바뀌었을 뿐이다. ActiveX, Flash, 블록체인, 메타버스... 그리고 이제 AI다.
AI의 미래를 논할 때 우리는 실제로 얘기하고 싶은 것이 무엇인지부터 명확히 해야 한다. 기술적 발전의 한계는 어디인가? 현재의 대규모 언어 모델이 극복해야 할 근본적인 문제는 무엇인가? 그리고 가장 중요하게, 실제 개발 현장에서 우리가 체감하는 AI의 수준은 정확히 어떤 상태인가? 이 글은 기술 커뮤니티의 흥분과 좌절을 거리를 두고 바라본, 한 명의 경험이 많은 개발자의 냉정한 분석이다.
오랜 시간이 지난 지금도 우리는 같은 대화를 반복한다
1998년, 나는 여전히 ActiveX가 미래라고 믿는 개발자들을 봤다. 우리는 Microsoft의 약속을 진심으로 받아들였다. 플러그인 기반의 인터넷 애플리케이션이 미래라고. 그것이 모든 소프트웨어의 방식을 바꿀 거라고. 2008년쯤 되자 Flash가 차례였다. 어도비는 플러그인 없이도 웹에서 리치한 경험을 제공한다고 했다. 기업들은 수백억 원을 들여 Flash 기반의 포탈을 구축했다. 나도 그 프로젝트에 참여했다.
2017년, 블록체인이 미래가 될 거라고 했다. 모든 데이터베이스를 블록체인으로 대체할 것이고, 중앙 서버는 사라질 거라고. 2021년부터 메타버스 이야기가 나왔다. 5년 안에 세상이 가상 세계로 바뀔 거라고. 기업들은 수조 원대의 투자를 했다. 지금 어디에 있는가?
이제 2026년이다. AI가 모든 것을 바꿀 거라고 한다. 개발자는 2년 안에 시장에서 사라질 거라고. AGI는 2027년부터 2035년 사이에 나올 거라고. 나는 이런 말들을 들을 때마다 같은 감정을 느낀다. 설렘도 있지만, 더 강한 건 피로다.
문제는 이 모든 기술들이 실제로 정말로 중요한 것들이었다는 점이다. ActiveX는 당시로서는 혁신적이었다. Flash는 웹 경험을 근본적으로 바꿨다. 블록체인은 분산 합의의 새로운 가능성을 열었다. 메타버스 기술들은 실제로 유용한 곳에서 쓰이고 있다. 다만 우리의 예상과 현실 사이에는 항상 거대한 차이가 있었다.
기술 하이프 사이클에서 가장 위험한 순간은 기술이 이미 성숙했을 때인데, 우리는 여전히 마지막 남은 변화를 기대할 때다.
현재 LLM의 근본적인 한계들
Claude 3.5, GPT-4, Gemini 2.0이 나온 지금, 우리가 직면하고 있는 기술적 현실을 정직하게 봐야 한다. 이 모델들은 정말로 놀랍다. 내가 써본 도구 중에 가장 강력하다. 하지만 동시에 명백한 한계들이 있다. 그리고 이 한계들은 단순히 "더 큰 모델을 학습하면 해결된다"는 식의 문제가 아니다.
맥락의 깊이 문제
가장 기본적인 문제부터 시작하자. 현재의 모든 LLM은 토큰 기반으로 작동한다. 입력과 출력의 토큰 개수가 늘어날수록 성능이 저하된다. 이것은 이론적인 문제가 아니라, 매일 느껴지는 현실이다.
내가 Kakao에서 지난 6개월간 작업한 프로젝트를 예로 들자. 우리는 레거시 코드베이스를 현대화하고 있었다. 50만 줄 규모의 TypeScript 프로젝트였다. AI에게 "이 아키텍처의 문제점을 찾아달라"고 요청했을 때, AI는 처음 보는 파일들에 대해서는 합리적인 분석을 제공했다. 하지만 전체 시스템의 맥락—왜 이런 구조를 택했는지, 과거의 결정들이 현재의 코드에 어떻게 영향을 미쳤는지—을 이해하려면, 우리는 여전히 직접 코드를 읽어야 했다.
이것이 왜 중요한가? 진정한 아키텍처 리뷰나 시스템 리팩토링은 단순히 "이 함수는 너무 길다"는 지적을 넘어선다. 그것은 역사적 맥락, 비즈니스 제약, 팀의 역량, 미래의 요구사항을 모두 고려해야 한다. 현재의 어떤 LLM도 이것을 온전히 해내지 못한다.
진정한 추론의 부재
두 번째 한계는 더 근본적이다. LLM은 추론하는 것처럼 보이지만, 실제로는 패턴을 완성하고 있을 뿐이다. 이것이 무슨 차이냐고 물을 수 있겠지만, 실제로 이것은 거대한 차이다.
구체적인 예를 보자. 나는 최근에 Claude에게 다음과 같은 문제를 주었다. "이 복잡한 버그를 추적하기 위해 어떤 단계별 접근 방식을 추천하시겠습니까?"라고 물었을 때, AI는 일반적인 디버깅 방법론을 제시했다. 변수 추적, 로그 추가, 단위 테스트 작성 등등. 하지만 이것은 맥락을 무시한 일반적인 조언이었다.
실제로 그 버그는 부동소수점 연산의 정확도 문제에서 비롯된 것이었다. 세 가지 다른 숫자 형식이 서로 상호작용하는 방식 때문이었다. 이것을 찾으려면 단순한 일반적 방법론이 아니라, 그 시스템의 수학적 기초를 이해하고 거기서부터 거꾸로 추론해야 했다. LLM은 이런 "거꾸로 추론"을 제대로 못 한다.
왜인가? LLM은 학습 데이터에서 본 패턴을 따르는 데 최적화되어 있다. 하지만 진정한 추론이란, 본 적 없는 문제를 새로운 방식으로 조합하는 것이다. 이것은 신경망의 현재 아키텍처로는 근본적으로 어렵다.
일관성과 신뢰성의 문제
AI는 같은 질문을 두 번 하면 다른 답변을 한다. 이것은 "창의성"이 아니라 신뢰성의 문제다. 개발 환경에서 이것은 치명적이다. 프로덕션 시스템에서 기댈 수 있는 도구가 되려면, 같은 입력에 대해 같은 출력(또는 최소한 예측 가능한 변동)을 제공해야 한다.
내가 최근에 경험한 예: 우리 팀이 테스트 케이스를 자동으로 생성하도록 AI를 구성했다. 같은 코드 함수에 대해 요청할 때마다, AI는 다른 테스트 케이스를 생성했다. 어떤 것들은 겹쳤고, 어떤 것들은 완전히 빠졌다. 결국 우리는 AI가 생성한 테스트를 모두 수동으로 검토하고 정렬해야 했다. 이것이 생산성 향상이 되는가?
실제 통합의 어려움
마지막으로, 가장 실무적인 한계가 있다. 우리가 매일 접하는 것은 "대화형 AI"가 아니라, 프로덕션 시스템 안에 통합되어야 하는 AI 기능이다.
예를 들어, 우리는 자동 코드 완성 시스템을 구축했다. 이것은 단순히 "좋은 추천을 제공한다"는 것보다는, "정확한 타입 정보를 유지하면서 기존 코드 스타일을 따른다"는 것이 중요하다. 또는 "제안한 코드가 실제로 컴파일되고 실행된다"는 것이 중요하다.
이런 제약 조건들이 있을 때, 현재의 LLM은 흔히 "좋지만 불완전한" 결과를 낸다. 개발자는 여전히 50%의 시간을 AI가 생성한 코드를 검수하고 수정하는 데 쓴다.
개발 현장에서 체감하는 AI의 실제 수준
이론적인 한계를 넘어, 실제 업무에서 AI는 어느 정도 도움이 되는가? 나는 지난 6개월간 매일 GitHub Copilot, Claude, ChatGPT를 사용했다. 정직한 평가를 하자면, 그것은 도움이 된다. 하지만 우리가 기대하는 수준의 도움은 아니다.
AI가 정말 잘하는 것들
먼저 긍정적인 부분부터 얘기하자. AI는 정말로 특정 작업에서 뛰어나다.
보일러플레이트 코드 생성: 새로운 React 컴포넌트를 만들 때, AI는 매우 빠르고 정확한 기초 코드를 제공한다. 기본 구조, 스타일 설정, 이벤트 핸들러 등등. 이런 반복적인 패턴은 AI가 자주 본 것들이므로, AI는 여기서 시간을 절약해준다.
문서화와 주석: 기존 코드에 설명을 추가해달라고 하면, AI는 꽤 좋은 결과를 낸다. 특히 복잡한 알고리즘에 대해, AI는 인간의 관점을 반영하지 않은 객관적인 설명을 할 수 있다.
간단한 버그 패턴 인식: "이 에러 메시지가 뜨면 보통 뭘까?"라는 질문에, AI는 많은 경우 올바른 답변을 한다. 왜냐하면 이런 패턴들이 스택오버플로우, 깃허브 이슈에 수천 번 나왔기 때문이다.
언어 간 변환: Python 코드를 JavaScript로 변환해달라는 요청에, AI는 대부분 작동하는 코드를 제시한다. 구조가 유지되고, 문법이 올바르기 때문이다.
정규식과 같은 복잡한 패턴: 정규식을 직접 작성하는 것은 번거롭지만, "이 이메일 형식을 맞추는 정규식을 만들어달라"고 요청하면, AI는 매우 정확하게 제시한다.
AI가 흔히 실패하는 것들
반대로, AI가 흔히 실패하거나 일관성 있게 실패하는 영역들이 있다.
복잡한 아키텍처 결정: "마이크로서비스를 써야 할까?"라는 질문에, AI는 일반적인 장단점을 나열한다. 하지만 당신의 팀 규모, 조직의 성숙도, 현재의 기술 스택, 비용 제약을 모두 고려한 맞춤형 답변은 주지 못한다.
기존 코드베이스의 깊은 이해: "이 코드의 문제를 찾아달라"는 요청에, AI는 표면적인 문제들(이름 지정, 함수 길이)은 찾지만, "왜 이전 개발자가 이런 구조를 택했는지"는 이해하지 못한다.
성능 최적화: "이 함수가 느려요"라고 하면, AI는 일반적인 최적화 기법들을 제안한다. 하지만 실제로 그것이 당신의 상황에서 가장 중요한 최적화인지는 알 수 없다. 프로파일링 결과를 보지 않고는.
장기 유지보수성을 고려한 설계: AI가 제안하는 코드는 "지금 작동한다"는 기준에서는 좋지만, "3년 후에도 유지보수하기 쉬울까?"라는 관점에서는 부족하다.
실무에서의 생산성 증감
그렇다면 실제로 생산성이 얼마나 올랐는가? 나의 경험을 수치화하면, 대략 20~30% 정도다. 개발 초기 단계에서는 더 높을 수 있고(40~50%), 복잡한 문제 해결 단계에서는 거의 도움이 되지 않는다(0~10%).
특히 주목할 점은, 생산성 증가가 균등하지 않다는 것이다. 주니어 개발자는 더 큰 이득을 본다. 왜냐하면 그들은 여전히 학습 중이기 때문에, AI의 예시들이 그들에게 교육적 가치가 있다. 반면 시니어 개발자는 이미 알고 있는 것들을 AI가 반복해서 제시하는 경우가 많으므로, 상대적으로 덜 유용하다.
그렇다면 AGI는 언제 올까?
이제 원래 질문으로 돌아가자. AGI(일반 인공지능)은 정말로 올까? 그리고 언제?
정직하게 답하자면, 현재의 LLM 아키텍처에서는 AGI로의 진화가 직선적이지 않을 것 같다. 더 큰 모델, 더 많은 데이터, 더 좋은 하드웨어는 확실히 성능을 올린다. 하지만 현재 우리가 직면한 한계들—진정한 추론, 진정한 학습, 시간에 따른 적응—은 단순히 규모의 문제가 아니다.
이것은 아키텍처 혁신이 필요하다는 뜻이다. 그리고 그런 혁신은 예측 불가능하다. 1998년에 누가 딥러닝이 2012년에 이미지 인식을 지배할 거라고 예상했는가? 또는 2019년에 누가 변환기 모델이 NLP를 이렇게 바꿀 거라고 생각했는가?
하지만 동시에, 나는 현재의 LLM이 AGI의 필요조건이 아닐 수도 있다고 생각한다. 우리는 지능을 인간의 지능으로 정의하는 경향이 있다. 하지만 진정한 일반지능이란, 인간의 방식과 완전히 다를 수도 있다. 오히려 우리가 기대하는 방식의 "일반지능"이 가능할지 자체가 의문이다.
기술 예측에서 가장 정확한 것은 항상 회의론이다. 왜냐하면 큰 혁신은 예측할 수 없기 때문이고, 작은 개선은 확실하기 때문이다.
내가 할 수 있는 최선의 예측은 이것이다. 앞으로 5년간 AI는 계속해서 더 능력 있어질 것이다. 그리고 그것은 특정 영역에서는 정말로 혁신적일 것이다. 하지만 우리가 AGI라고 부를 만한 수준에 도달할 가능성은... 50% 미만이라고 본다. 그리고 그것이 온다면, 우리가 지금 예상하는 방식과는 다를 것이다.
그래서 우리는 뭘 해야 하는가?
AI의 미래가 불확실하다면, 개발자로서 우리는 어떻게 대비해야 할까?
첫째, AI를 도구로 받아들이되, 만능 도구가 아닌 "특정 작업에 뛰어난" 도구로 본다. Figma가 모든 디자인 작업을 하지는 못하지만, 매우 유용한 것처럼, AI도 그런 도구가 될 것이다.
둘째, 기본 실력을 계속 갈아야 한다. 알고리즘, 시스템 설계, 아키텍처—이런 것들은 AI가 완전히 대체하기 어렵다. 오히려 이런 실력이 있을수록, AI를 더 잘 활용할 수 있다.
셋째, 기술 트렌드의 과장을 거르는 능력을 기르자. 나는 많은 "혁신"을 봤다. 그 중 정말로 판도를 바꾼 것들은 몇 개뿐이었다. 우리의 일은 지금 당신 앞에 있는 문제를 푸는 것이지, 2030년의 불확실한 미래에 대비하는 것이 아니다.
AI는 확실히 앞으로도 중요할 것이다. 하지만 그것이 모든 것을 바꿀 것이라는 말은 거짓일 가능성이 높다. 기술 변화는 항상 예상보다 느리고, 예상과 다른 방향에서 온다. 이게 실무에서 얻은 교훈이다.