AI-driven, 토큰 맥싱, 청구서: AI를 작업의 중심으로 끌어들이고
도입
24년 상반기, 신임 교수님의 <소프트웨어공학론> 수업. 나는 이 수업을 교수님께 메일을 보내면서 수강하려고 한 것을 이따금 후회하고 있었다.
평균 35 페이지의 슬라이드가 27개 분량. 단순 계산으로 945페이지, 의대생의 과목당 학습량이 이정도 수준일까. 열정 넘치는 교수님은 고전 소프트웨어공학론에 최신 연구를 계속해서 추가하면서 매 회차마다 슬라이드에 (revised) 표시를 붙여가며 콘텐츠를 늘려갔다. 고전적인 소프트웨어공학론도 꽤 양이 되는데, AI 기반 방법론이 고전 이론의 절반 정도 되는 분량으로 새로 투입되며 가히 파괴적이라 할 수 있는 양의 수업이 되었다.
이 수업은 24년 1학기 중에 있었고, ICSE’24는 24년 4월 14일부터 20일까지 열렸다.
고전 이론은 이미 어느정도 학습했거나 체감한 바가 있었지만, AI를 사용한 방법론들은 새롭고 신기한 내용들이었다. 방법론들은 AI 성능에 너무 낙관적이었다. 아무리 학교는 이론을 공부하는 곳이라고 한들, 종종 현실과 거리가 있는 내용이 아닐까 생각하곤 했다.
물론 성능만 보장된다면 실현될 것이었겠지만, 당시의 최신 모델은 GPT-4, Claude 3, Gemin 1.5, GLM-4 같은 것들이었다. 나는 지금 수준의 LLM의 발전을 생각하기 이전에, 앞으로 수 개월 뒤 딥시크 쇼크가 올 것조차 생각하지 못했다.
<2028 글로벌 지능 위기>의 해설 영상
26년 1분기, 이미 프론티어 랩의 부침은 테크업계 뿐 아니라 전 세계에 직접적인 영향을 주고 있었다. 어느날, 월스트리트를 중심으로 한 건의 시나리오가 리서치 리포트로 퍼지기 시작했다. <2028 글로벌 지능 위기>, 월가는 공포와 탐욕, 환희와 비관에 휩싸여 온갖 시장을 뒤흔들어놓았다.
보고서는 더 이상 지능이 인간의 전유물이 아니게 된 세상, 지능에 매겨지던 가격이 현저히 저렴해지는 세상을 묘사하고 있었다. 나도 내심 불안감에 휩싸였지만, 이내 금융시장의 호들갑이겠거니 하며 안정을 찾기 위해 노력했다.
그로부터 얼마 지나지 않아, 앤트로픽은 미토스로 이름 붙인 모델 하나로 미국 행정부 전체를 움직이게 만들었다.
사례: 비전공자 개발 프로젝트 팀에서 활동하기
다른 단과대학에서 3D 실시간 멀티플레이어 게임을 연구개발하는 프로젝트 팀의 유일한 컴퓨터 공학 전공 학부생으로서
나는 교환학생을 떠나면서 한국에서 프로젝트를 하나 받아갔다. 간호대학 학생들이 논문을 작성하기 위해 응급실 시뮬레이션을 만든다며 팀을 구성하고 있었고, AI를 사용해서 개발할테니 작업을 보조해주고 조언해줄 컴퓨터 전공자를 찾고 있었다. 나는 그 팀에 들어가 3D 실시간 멀티플레이어 게임 스펙의 응급실 시뮬레이터 개발을 주도하게 되었다.
하지만 이 프로젝트는 기획의 규모가 요구하는 시간 대비 설정된 프로젝트 일정이 매우 짧은 편이었다. 컴퓨터 전공과 관계없는 학부생들이 계획을 마련했기 때문에, 필요한 시간을 제대로 산정하지 못했던 것이다. 이후에 원안의 수 배로 일정을 늘렸지만, 여전히 요구되는 코드 구현량이 순수하게 막대했다. 머릿속으로 코드를 어떻게 구현할지 완전히 알고 있다고 하더라도, 손으로 직접 타이핑하는 것으로는 기간 내에 제대로 끝마치지 못했을 것이다. 그래서 코드 생성 속도 하나만으로도 AI를 사용할 유인이 컸다.
최초에는 프로젝트를 두 개 층위로 나누어 작업했다. 절대로 AI에게 수정을 맡기지 않는 것이 의도되고, 설령 맡긴다고 하더라도 인간 작업자에 의해 철저히 리뷰되어야 하는 인프라 계층, AI에 의해 작성되고 수정되는 것이 의도되는 콘텐츠 계층으로 나누었다. 프로젝트에서 인프라 계층은 플레이어 컨트롤 처리, 인게임 환경의 흐름 제어, 네트워크 제어 등, 이 프로젝트 주제가 아니라 다른 프로젝트에서도 사용 가능한 수준으로 일반화한 기능 구현들이었다. 이어서 이 프로젝트의 기획 하에서만 유효하고 다른 프로젝트 등에서는 사용 불가능한, 인게임 시나리오, 다이얼로그 처리, 각종 이벤트 정의 등, 콘텐츠 계층은 인프라 계층이 제공하는 기능 구현들을 이용해 사용자 측이 접하는 콘텐츠를 표시하도록 했다.
결함 주도 개발
이해는 새로운 병목입니다.
하지만 인간 작업자 범위인 인프라 계층이 전체 과정의 병목이 되어, 콘텐츠 계층을 아무리 AI에게 맡기더라도 개발 속도가 진척되지 않았다. 그래서 결국 인프라 계층에도 AI 작업을 허용할 수밖에 없었다.
여러 방면으로 시행착오를 겪고, 개발 상황에서 인간 작업자가 병목이 되었다고 깨달았을 때는, 이미 남은 기간이 별로 남지 않았다. AI에게 코드를 생성시키고 그 결과를 직접 검토하는 것만으로도 프로젝트 기간을 맞추지 못하게 되는 것은 확정 사항이 되는 수준이었다.
위험한 가정: 평균적으로는 적당히 결함있는 코드와 적당히 결함없는 코드가 적당히 섞여서 나올 것이다. 그리고 치명적인 버그는 낮은 확률로 발생할 것이다. 1
그래서 결국 24년-25년 초의 자신이었다면 기함을 했을 태도를 취하게 되었다: AI가 생성하는 코드에 일정 확률로 결함이 있을 것을 인정하고, 계속해서 막연하게 AI 생성 코드를 쌓아갔다. AI 생성 코드를 쌓으면서 주기적으로 프론티어 랩의 고급 모델에게 최근 십수개의 커밋을 읽어들여 적대적 코드 리뷰를 수행시켰다.
이 방법으로 작업(이 행위를 development라고 불러도 되는지 모르겠다.)을 계속하니 일정 계획에 맞출 수 있는 수준의 작업 속도를 얻을 수 있었다.
문제가 있다면 직접 작업했을 때는 거의 마주하지 않았을 silent fail을 겪는 횟수가 괄목할 수준으로 증가했다는 것이다. 그럼에도 불구하고 이들 문제들을, 관리 가능한 수준으로 해결하거나 완화하는데 추가적으로 지시문을 작성하고 처리시키는 데 걸리는 시간이, 문제를 확인하고 직접 수정하는 것보다 덜 소모적이고 빨랐다. 오류 메시지 없이 오작동하는 구현을 보고 피로감을 느끼는 것만 감내하기만 하면 됐다.
당연하게도 프로덕션에서는 상상도 못할 태도이다. 이 프로젝트는 많은 예외상황을 확인하며 대응하지 않아도 되고, 관계자에 의해 실행 환경이 관리되고 있을 것이며, 일반에 배포하는 것이 아니기 때문에 적당한 선에서 이와 같이 작업했던 것이다.
청구서
만약 연봉 50만달러의 엔지니어가 최소 25만달러 상당의 토큰을 사용하지 않는다면, 저는 매우 우려할 것입니다.
날이 갈수록 코드베이스가 복잡해지고, 시간을 들여서 코드의 정돈된 상태를 유지하려는 노력을 포기하게 되면서, 작업 당 토큰 사용량은 날이 갈수록 천정부지로 높아지게 되었다.
최초에는 VSCode 기능으로 추가된 GitHub Copilot(코파일럿)을 통해 코딩에 튜닝되었을 것으로 추측되는 GPT 모델들을 사용했다. 코파일럿은 작년까지 학생 계정을 상대로 꽤 사용량을 지원해주어, 교환학생 유학생 생활을 하면서 넉넉하지 못했던 지갑 사정을 적절히 케어해주었다. 코파일럿은 사용하는 기간동안 계속해서 요금 정책이 조정되어 체감하는 가용 크레딧은 증감하고 있었는데, 연초에 정책이 변경되면서 그동안의 사용 패턴으로는 코파일럿에서 추가 크레딧을 구매해 사용하면 매우 곤란해질 수 있다고 판단하게 되어 프로바이더를 전면적으로 교체할 수밖에 없었다.
25년 연말 즈음에는 OpenRouter(오픈라우터)의 사용 요금 무료 모델을 Kilo Code(킬로코드)에 연결해서 제한적으로 사용해보기 시작했다. 언급한 코파일럿의 체감 가용 크레딧 감소에 대응한 것이었는데, 프리 티어 모델들은 시간 당 토큰 수, 정확도, 처리율 제한, 속도 면에서 코드 수정을 맡길 수는 없었다.
프리 티어 모델들은 프롬프트의 지시조차 제대로 이해하지 못했다. 한 예시로 모듈의 기능을 캐시해놓은 마크다운 파일을 업데이트하라는 지시에, 업데이트 대상으로 삼아야 할 마크다운 파일의 내용을 근거로 업데이트할 내용이 없다고 인식, 세션을 종료했다.
26년 초에는 자료 조사나 학습 보조 도구 목적으로 채팅으로만 사용하던 Poe를 킬로코드에 연결해서 코파일럿을 대체하기 시작했다. Poe 기본 구독 플랜의 크레딧 제공량은 자료 조사 목적으로는 차고 넘쳤는데, 킬로코드에 연결해 사용하니 금세 소진되었다. 한동안은 매월 30달러 내외를 추가 크레딧을 구하는 데 사용했다.
실은 Poe 기본 구독 플랜과 월 30달러의 추가 크레딧으로는 사용량을 제대로 다 감당하지 못했다. 나는 전남대학교 구성원 전원에게 제공하는 타임리AI 크레딧을 이용해 부족분을 채웠다. 학교는 꽤 넉넉한 크레딧을 제공했고, 타임리AI는 오픈라우터 프록시를 제공해주었다. 대부분의 재학생들은 학교가 제공하는 방식이 불편하다며 사용하지 않았지만, 나는 오픈라우터 프록시에 킬로코드를 연결해 사용했으므로 문제 상황을 겪지 않았다.
계속해서 추가 크레딧을 결제하면서 종량제의 설움이 쌓여갔다. 리셀러로부터 크레딧을 제공받으면서 다양한 모델을 사용할 수는 있었지만, 다른 사람들이 퍼스트 파티 결제로 사용하게 되는 실제 토큰 당 비용이 내 방식의 토큰 당 비용보다 현저히 낮은 것 같았다. 그래서 이윽고는, Poe 구독을 해지하고 오픈AI와 앤트로픽을 직접 결제해 사용하는 것으로 AI 사용 방향을 틀었다.
동시에 가격 효율적인 중국산 오픈웨이트 모델을 계속해서 실험적으로 도입해보았다. 이들 모델은 비용 측면에서 압도적인데다, 계속되는 발전으로 프론티어 랩들의 모델 성능을 꽤 따라왔다고 평가되었기 때문이다. 심지어는 오픈라우터 등으로 서드파티 프로바이더를 사용하면 퍼스트 파티 개발사가 책정한 요금보다 더 저렴하게 사용할 수도 있었다.
나는 알리바바 모델 스튜디오 플랜으로 Qwen을, 이어서는 Z.ai의 플랜으로 GLM을 사용해보았다. 하지만 이 모델들은 모두 이 프로젝트의 복잡한 코드베이스의 경우와 같이, 컨텍스트에 올려야 할 내용이 많을 수록 성능이 현저히 떨어지는 모습을 보였다.
때문에 같은 티어의 플랜을 구독하더라도 이 사례에서는 프론티어 랩의 모델을 사용했을 때 더 많은 작업을 수행할 수 있었다. 작업에 따라서 상이하나, 같은 5시간 쿼터, 일주일 쿼터에서 대략 1.5배에서 3배 더 많은 일을 프론티어 랩 모델이 더 빠르게 처리했다. 더 높은 티어의 플랜에서는 또 다르게 체감, 이 내용이 타당하지 않을 수 있으나, 최고 티어의 플랜을 구독할 수 있는 입장이 아니어서 내게는 확인할 수 있는 방법이 없다.
자동화, 자동화, 자동화
이전까지만 하더라도 간단한 자동화 배치 스크립트를 작성하는 것도 고려해야할 비용이었다. 소위 ‘노가다’라고 불리는 시간 소모적인 작업을 할 때는, 하고 있는 작업을 자동화하기 위해 스크립트를 작성하는 시간과 직접 작업하는 시간 사이를 재보면서 어느 편이 더 나은지 판단해야했다. 심지어 스크립트는 미처 고려하지 못한 요소로 작성을 중간에 포기하거나 고려했던 것보다 더 오랜 시간이 걸리게 될 지도 모른다.
그래서 자동화 스크립트는 그 자체만으로도 꽤 가치를 지닌 물건이었다. 이후에 다른 비슷한 작업에서 수정해 사용할 수 있도록, 일종의 사례집 리포지토리를 운용했고, 아마 사실상 모든 개발자가 그러했을 것으로 생각한다.
하지만 이제 자동화 스크립트는 예전만큼의 가치가 없다. 노동집약적인 작업을 자동화하는 스크립트는 이제 그 가치가 0에 가까워졌다고 생각한다. 자동화 스크립트는 이제 더 이상 재사용되지 않는다. 자동화 사례집 리포지토리는 AI에게는 캐시 저장소의 역할만도 못했다. 저렴한 모델에서는 이 리포지토리가 오히려 자동화 스크립트를 편향된 방향으로 작성하게 하는 계기로서 작용하기도 했다.
거대 분산 시스템을 구축해본 사람이라면, (마이크로서비스 아키텍처가) 기대한 그대로 작동하지 않으며 그것에 해야만 하는 것을 알고 있을 것이다.
개인적인 경험에서는 CI 스크립트를 작성하는 데 투입할 수 있는 시간이 확연히 단축되었다. 이전에는 CI 워크플로우를 정의하기 위해서는 충분한 시간 여유를 두어야 했다. 비공개 포크 리포지토리에서 CI가 제대로 문법에 맞게 정의되었는지 확인해야 했으며, 기대와 같은 동작을 하는지 확인하여야 했다.
하지만 이제 같은 맥락에서 간단한 CI 정의는 AI로 생성한 자동화 스크립트 집합을 호출하는 방식으로, 혹은 그 자체 전부를 AI로 생성하여도 큰 장애 없이 동작할 수 있었다.
이 프로젝트에서는 리포지토리의 용량 문제로 Git 호스트 프로바이더를 수 차례 전환했다. 처음에는 GitHub, 다음은 GitLab, 이어서 RocketGit을 거쳐 Azure DevOps로 전환했다. CI는 GitLab에서부터 테스트 러너와 빌드하여 컴파일 오류가 있는지 확인하기 위해 사용하기 시작했다. AI는 이 워크플로우를 정의하는 작업을 큰 문제 없이 실행까지 해보였다.
RocketGit으로 전환했을 때. DevOps 서비스도 제공하는 다른 Git 호스트들과는 달리, RocketGit은 Git 호스트를 제공하는 것만에 초점을 두고 있었기 때문에 정석적인 CI를 사용할 수 없었다. 다만 웹훅 기능은 있었으므로 셀프 호스트 러너 환경에서 레포를 폴링하면서 CI 워크플로우를 처리, 결과를 웹훅으로 반환하는 것으로 CI를 비슷하게 실현할 수는 있었다. 역시 이 작업도 내 직접적인 개입은 필요하지 않았다.
Azure DevOps로 전환할 때 역시 내 직접적인 개입은 필요하지 않았다. GitLab CI 정의와 RocketGit의 자동화 처리는 큰 맥락에서 변화한 것이 없었더라도, 작업이 실행되는 주체가 상이하므로 저렴한 모델에서는 다소 혼란이 있지 않을까 우려했다. 하지만 비용 최적화 모델로도 문제 없이 전환이 이루어졌다.
이들 경험을 바탕으로 CI 외의 스크립트도 같은 작업을 거치기 시작했다. AI가 작업하기 위해 즉석으로 생성하는 명령줄 스크립트들을 일반화해서 에이전트 스킬로 등록하거나, 리포지토리 전반에 흩어져 여러 차례의 명령으로 쿼리해야 할 데이터들을 캐시해두거나, 코드베이스와 데이터를 인덱스해두어 커밋에 포함시켜두면서 에이전트 효율을 높이도록 했다.
이렇게 시간이 지나니 프로젝트 루트에는 상당량의 닷파일들이 즐비하게 되었다. 에이전트 지시문, 자동 생성된 인덱스, 각종 자동화 정의로 가득했다.
루프 안의 인간은 지쳤다
LLM으로 프로그래밍하는 것은 유용하면서 지치게 만듭니다. 만약 우리가 후자를 간과한다면, 우린 모두 번아웃이 와버릴 것입니다.
Laura Summers https://pydantic.dev/articles/the-human-in-the-loop-is-tired
AI가 효율성을 극대화 할것이라는 기대는 타당하다. 나는 코드의 작성 속도만으로도 AI 사용 효용을 매우 크게 느꼈고, AI가 가져다주는 효용은 더 다양하다.
하지만 이제 인지 부채(Cognitive Debt)라는 단어가 생길 정도로, AI의 작업과 우리 두뇌가 인식한 작업 사이에는 간격이 발생하는 일이 잦아졌다. AI가 의존하는 고속 연산 인프라와는 달리 우리 두뇌의 신경은 지식 활동으로 만들어낸 데이터의 처리에 오랜 시간이 걸린다. AI의 작업 상황과 우리가 인식하는 상황을 동기화하는 것은 이 속도 차이가 더 커질수록 더 도전적이게 될 것이다.
이번 위의 사례에서 나는 결국 이 인지 부채를 해결하는 것을 포기하게 된 셈이다.
하지만 인지 부채 외에도 단순히 지시를 내리는 것도 나를 지치게 만들기에는 충분했다. SNS에서 우스갯소리로 AI 시대 최고 인재는 ADHD라는 주장을 접한 적 있다. 나는 어느 측면에서는 웃으며 동의할 수밖에 없었다. AI가 의도와 다르게 작업하지 않을 만큼 상세한 지시를, 모순되게도 지나치게 편향되어 경직적으로 동작하지 않도록 간결하게 작성해야 했다. 동시에 코드 리뷰를 포기하니 머릿속에서는 여러 개 창에 걸쳐, 지시문을 계속 맥락을 전환하면서 작업을 쉼없이 트리거해야만 했다. 한 번 이렇게 작업하고 나면 상당한 피로감이 나를 덮쳤다.
여러개의 워크트리에 걸쳐 두뇌 컨텍스트 스위치를 하다보면, 복잡하게 꼬인 브랜치 그래프만큼 어느순간 내 사고 흐름도 꽉 꼬여 잠시 패닉에 빠졌다.
마무리
AI 에이전트는 인간을 루프 바깥으로 밀어내고 있다.
M Mitchell, et al. https://arxiv.org/abs/2608.23642
이번 경험은 시간, 돈, 노력, 정신적 측면에서 꽤 큰 비용을 지불했지만, 내게 시대 변화에 대응을 시도할수는 있을 정도의 통찰과 경험을 주었다.
하지만 AI 작업은 지금까지 직접 개발 작업을 했던 것과는 다르게 내게 직접적으로 지식을 습득할 기회가 있지는 않았다. 직접 개발 작업을 수행했을 때는, 진짜 기획을 구현해내는 주체가 작업자 자신이므로, 구현을 위해 추가적으로 직접 조사하거나 사고를 거쳐야만 했다. 이 과정에서 새롭게 지식을 획득할 수 있었다. 프로그래밍은 일이면서 공부였다.
AI 작업은 인간 두뇌가 조사하는 과정, 사고하는 과정을 건너뛰게 했기 때문에, 작업 자체가 곧바로 지식으로 이어지지 않았다. 지식을 획득하기 위해서는 주체적으로 능동적으로 추가적인 행동을 취해야만 했다.
그래서 일반론은 아니고 개인적인 감상, ‘나는 카페에서 공부가 더 잘된다.’, ‘나는 이어폰을 꽂으며 공부하는 것이 효율이 더 좋다.’와 같은 감상론에 불과한데, 내 경우에는 프로그래밍 작업 외에도, 공부는 고전적인 방법으로 별도로 시간을 들여야 하겠다고 느꼈다.
