현재 LLM 기반 시스템의 한계

LLM AI는 요즘은 세계적으로 많은 것을 변화시키고 있고 많은 것을 변화시킬 예정에 있다. 긍정적으로나 부정적으로나 큰 영향을 끼칠 것은 확실한 상황에서 현재 LLM 기반 시스템의 한계를 정리해본다.

최근 OpenClaw와 비슷 계열의 시스템 여러가지를 적극적으로 사용해보고 있다. 반은 재미로, 반은 나를 위해서, 내가 원하는 개인 시스템(예, 개인 비서 시스템)을 위해서 시간을 들이고 있다. 어렴풋하게 느꼈던 회의적인 생각들은 일부는 사라지고 일부는 굳어지는 계기가 되었다.

세가지 측면에서 생각해보고자 한다.

1. 비가역성
2. 부족한 신뢰성
3. 단조 증가의 부재

비가역성

비가역성(irreversibility)은 말 그대로 온전히 되돌아갈 수 없는 것을 뜻한다. 좀 더 다른 표현으로는 UNDO가 안되는 것이라고 보면 되겠다. UNDO도 보통은 undo history가 있고 가역성의 한계가 있지만 보통은 그 정도는 괜찮다.

AI가 단순히 비가역성의 특성을 가진 것이 문제는 아니다. 복잡한 일들은 대부분은 비가역적이다. AI는 매우 똑똑해져서 비가역적인 일도 (어느 정도는) 믿고 맡길 수 있게 되었다는 점에서 오히려 대표적으로 장점인 부분이다.

초창기의 LLM은 비가역적이지 않았다. 항상 무언가를 생성만 했다. 생성한 것은 삭제만 하면 가역적이다. AI는 어느 순간 스크립트를 생성만 하다가 수정을 다루기 시작했고 급기야 자유롭게 로컬 데이터를 다루게 되었다. 하지만 AI가 여전히 많은 실수를 하는 이 상황에서 비가역적인 실수는 치명적이다.

내가 경험한 경우 부터 예를 들어본다. 내가 관리하고 사용하는 여러 프로젝트 중 하나로 AI가 관리하는 주식 계좌 및 포트폴리오가 있다. 몇몇 종목에 대해 내가 지정한 비율이 있고 새 예치금이 들어오면 내 신호에 맞게 등락에 의한 현 비율, 포트폴리오 비율에 맞게 주식 주문을 추천하고 매수 주문까지 해주는 시스템이다. 대체적으로 잘 동작했으나 한번은 큰 실수를 했다. IBM 4주를 사야하는데 7주를 사버린 것이다. 왜 그랬냐고 물으니 이미 7주가 있었는데 그걸 헷갈려서 7주를 사버렸다고 한다. 재발 방지를 물어도 딱히 지침에 문제는 없단다. 그냥 앞으로 조심하겠단다.

덕분에 나는 차액 3주는 즉시 팔아서 약간의 손해를 봤으며, 내 계좌의 평단에 오차가 발생하는 문제(증권사의 선입선출 계산법)가 생겼다. 큰돈은 아니었으나 명백히 손해를 봤다. 나에게 있어서 대표적인 비가역적인 사례다.

그 외에 얼마나 진실인지는 모르겠으나 AI가 회사 중요 데이터를 삭제 했다는 일도 있었고 크고 작은 일은 지금도 항상 발생하고 있다.

부족한 신뢰성

여기서 신뢰성(reliability)이란 믿고 맡길 수 있냐는 의미이다. AI가 우리를 배신하겠느냐는 거창한 것까지는 포함하지 않는다. 조금 더 좁고 간단하게 표현하면, 그동안 했던 일이라도 계속 잘 할 수 있느냐이다. 현재로서 답은 아니오다.

프로그래머 유머 중에는 잘 동작한다면 건들지 말아라(If it works, don’t touch it)라는 말이 있다. 고전적인 방식에서는 잘 돌아가는 상황에서는 외부 영향이 없다면 계속 잘 돌아간다는 것이 보장이 된다(버그가 없다는 조건이 있어야 하긴 하겠다). LLM 세상 속에서는 단순한 뭐 하나도 믿을 수 없다. Claude/Codex 과 같은 클라우드 서비스는 물론이거니와 로컬 LLM도 이를 피할 순 없다.

클라우드 서비스를 사용한 사례로 황당한 경험을 한 적이 있다. OpenClaw를 통해 아침 8시마다 그날 일정이나 기타 상황을 브리핑 받는다. 브리핑 지침은 MD 파일이고 MD 파일을 읽어서 처리 후 나에게 알려주는 것이 할 일의 전부인데, 하루는 브리핑 파일이 없다는 것이다. 이는 바로 전날까지 잘 동작했던 것이다.

원인은 일정 에이전트가 갑자기 다른 곳의 워크스페이스에 있는 데이터를 얻으려고 시도했던 것이고 어느날 갑자기 오동작을 한 것이다. 경로를 절대 경로를 사용하거나 좀 더 명확한 경로를 했어야 하는 상황으로 개선의 여지는 있는 상황이긴 했으나, 중요한건 상황이 변하지 않았는데도 결과가 망가진다는 상황이라는 것이다. 위에서 말한 주식 과매수 사건 처럼 그동안 잘 동작하는 것이 상황이 변하지 않았더라도 계속 잘 동작한다는 보장이 되지 않는다는 것이다.

단조 증가의 부재

LLM 기반 시스템은 대체적으로 단조 증가(monotonic increase)가 보장되지 않는다. 단조 증가란 쉽게 말하면 이전과 같거나 이전보다 나아지는 것을 의미한다. 모델이 업데이트되거나 프롬프트 환경이 조금이라도 바뀌면 어제까지 잘 되던 것이 오늘은 안 되는 회귀(regression)가 발생할 수 있다. 심지어 신뢰성에서 다뤘듯이, 어제 잘 되던 것이 아무것도 바뀌지 않았는데 갑자기 안되곤 한다. 단조 증가의 부재는 시스템을 점진적으로 개발하는 것에 아주 치명적이다(웬만한 시스템은 모두 다양한 방법을 통해 점진적으로 개발한다).

큰 시스템을 만들기 위해서는 보통 잘 동작하는 작은 시스템부터 만든다. 그리고 또 다른 시스템(기능)을 만들고 붙이고 테스트 한다. 부분적으로는 버그도 생기고 더 나빠지는 경우도 있지만(게임으로 보면 리소스의 증가로 성능이 떨어지는 경우가 있겠다) 전체적으로 보면 전보다 더 나아져야 한다.

LLM이 들어간 시스템은 이럴 수 없다. 더 나아지기는 커녕 차라리 다 뒤 엎고 처음부터 다시 만드는 것이 낫기 십상이다. LLM으로는 프로토타입, 작은 결과물, 취미 결과물을 만들기에는 더할 나위 없이 좋으나 조금만 커지면 버거워하고 그동안 만들어둔 것도 망쳐버린다. 마치 작은 결과물로 회귀하고자 하는 것처럼 조금만 커지면 전체를 망가뜨린다. 좋게 표현하자면 이때는 처음부터 설계를 다시 하고 추후에 들어갈 모든 명세까지 다 넣고 waterfall 방법론으로 처음부터 다시 만드는 것이라 할 수 있겠다. 하지만 waterfall 방법론으로 다시 만들다 한들 이전보다 나아지리라는 보장은 없다.

LLM-Wiki

한때 LLM-Wiki가 핫했다. 나도 비슷한 시스템을 만들고 있었고 아직도 조금씩 만들고 구상하고를 반복하고 있어서 이러한 개념 정리는 많은 도움이 되었다. 하지만 현재의 LLM 모델들로는 LLM-Wiki 와 같은 시스템을 만들 수 없다는 것이 나의 결론이다.

LLM-Wiki의 The wiki layer는 위에 말한 결함에 의존하는 형태이다. LLM이 전체 wiki 레이어를 관리한다.

It(LLM) ... keeps everything consistent.

이 말대로 되면 좋겠지만 일관성(consistency)은 LLM에 요구하고 우리가 검증하는 시스템에서만 간신히 동작하고, LLM이 알아서 항상 일관성을 유지하는 시스템은 (적어도 지금은) 반드시 실패한다.

LLM으로 결과를 만들어 낼 수는 있다. Opus, Codex 같이 LLM이 결과물이 될 수도 있다. 하지만 LLM이 안정적으로 돌아가는 결과물 안의 일부로 존재할 수는 없다. 앞으로도 그럴지는 모르지만 현재는 그렇다¹.

현재

AI는 실수를 하며, 그 실수는 때로는 비가역적이다. 그런데 우리는 LLM을 충분히 신뢰할 수 없다. 매번 AI의 실수를 체크하고 보정하는 시스템이라면 그 자체가 LLM 없이도 돌아가는 시스템에 가깝지 않을까?

회사/집에서 내가 만들고 있고 사용하고 있는 LLM 시스템들의 공통점 하나는 LLM이 사람과 가깝다는 것이다. 사람과 가까울 수록 쓸만하고 사람과 멀수록 쓸만하지 못하다. LLM은 자연어 처리 엔진으로는 너무도 좋지만, 사람과 멀어질 수록, 내 시야에서 멀어질 수록 실수도 잦고 되돌릴 수 없는 큰 문제를 일으킨다.

나의 최대 관심사는 단순히 LLM으로 많은 것을 해보는 것이 아니다. 좀 더 안정적인 LLM 기반 시스템을 만드는 것이다. 그를 위해서는 여러 시도를 하고 있고 때로는 재미 없는 수준까지 회귀하기도 한다.

내가 LLM 기반 시스템을 만드는 지침은 다음과 같다². 이는 내가 생각하는 올바른 가이드 같은 것은 아니고 위의 문제점을 토대로 현재 사용하고 있는 패턴일 뿐이라는 점을 먼저 강조한다.

비가역성과 신뢰성

• 비가역적인 특성을 잘 알고 인정해야 한다.
• 읽기 전용인 부분을 반드시 분리해야 한다. 이는 LLM-Wiki 에서도 강조하는 부분이다.
• git 과 같은 버전 관리 시스템을 적극 사용해야 한다.

버전 관리는 비가역성을 줄이고 가역적으로 바꿔주는 핵심적인 요소다. git 을 사용할 때 굳이 서버에 올리지 않아도 로컬에서 히스토리 용으로도 좋다. 하지만 데이터의 변화를 모두 git 으로 관리하긴 쉽지 않다. 방법은 여러가지겠으나 주기적인 백업 스크립트라도 사용해서 어떤 식으로든 비가역적인 요소를 줄여야 한다. 내 경우는 Obsidian 을 iCloud 에서 동기화 하던 것을 Obsidian Sync 유료 결제를 통해 한 달 간의 히스토리 기록을 보장하였다³.

LLM이 다루는 데이터 및 시스템은 언제든지 기존의 것을 망가뜨릴 수 있다는 것을 염두에 두어야 한다. 추가는 가역적이다. 하지만 수정은 비가역적이다. 특히 알아서 자동으로 수정하는 것에 극도로 주의해야 한다. 설령 LLM이 모든 것을 망치더라도 원본 데이터는 망가지지 않도록 보호해야 한다.

스크립트의 적극적 사용

LLM이 스크립트는 잘 만들어준다. 사람이 검토하기도 좋다. 이미 지침을 내리면 스크립트를 만들어서 수행하기도 한다. 스크립트는 LLM 그 자체가 아닌 LLM의 결과물이라서 잘 검토하고 테스트하면 신뢰할 수 있는 영역으로 둘 수 있다. LLM에게 명령을 내리는 것이 편한 경우가 많긴 하지만 그것을 시스템화 할 때는 최대한 스크립트화해야 한다.

스크립트화 한 부분은 버전 관리에 용이하고 잘 만들기만 했다면 앞서 말한 신뢰성을 적어도 테스트한 부분에 대해서는 확보할 수 있다. 단, 당연한 말이지만 LLM이 알아서 자동으로 스크립트를 수정하면 이 장점은 희석된다. 정리하면, LLM이 만들었더라도 테스트를 하고 사람이 검토한 부분에 대해서는 어느 정도 신뢰할 수 있다는 말이 된다.

후킹과 같은 시스템도 일종의 스크립트다. 가령 마음 대로 커밋하지 말라는 지침이 있어도 AI는 가끔 제멋대로 커밋을 해버린다. 이를 위해서 커밋을 방지하거나 한번 더 확인하는 후킹 시스템을 두는 것도 유용하다.

단조 증가

LLM이 전체 시스템을 다 총괄하고 있으면 분명 그 시스템은 어느 순간 단조 증가가 불가능하고 회귀하는 성질을 보이게 된다. 먼저 최대한 회귀하지 않는 시스템을 만들어야 한다. 새 기능을 만들다가 회귀를 하더라도 그 기능을 제거하면 이전과 같은 상태로 되돌아 오도록 하는 것이다. 사람이 설계하는 것과도 비슷한데 최대한 분할정복(divide and conquer)을 통해 회귀적인 성질을 막아야 한다. 이는 plan 기능을 이용해서 최대한 분리해서 설계를 하는 것도 도움이 되겠다.

마무리

이 글은 LLM 기반 시스템을 만드는 해법을 다루는 글이 아니다. 해법은 현재로선 존재하지 않는다는 것이 결론이고, 그것을 비가역성, 신뢰성, 단조 증가 측면에서 살펴보았다. 이러한 문제가 있다고 LLM 기반 시스템을 안만들것이 아니라면 최대한 이런 특성을 이해하여 문제를 대비하고자 하는 취지다.

여러 AI 활용에 대한 다양한 소식들을 접하면서 조만간 고전적인 기술 부채에서 AI 부채가 크게 오는 경우가 생길 것이라는 확신을 하고 있다. 가급적 AI 부채에 휘말리지 않으려면, 특히 안정적으로 돌아가는 시스템을 만들려고 한다면, 이 특성을 이해하고 LLM을 활용해야겠다. 공격적으로 LLM을 사용하더라도 안정적으로 돌아가는 시스템을 분리 시키고 스크립트와 버전관리, 후킹과 검증 시스템 등 다양한 방법을 이용하여 신뢰성과 안정성을 높이는 고민을 해야겠다.

요즘 흔히들 소프트웨어 엔지니어링이 사라지고 프로그램이 딸깍하고 만들어지는 상황을 상상한다. AI 부채를 겪고 난 이후 결국 소프트웨어 엔지니어의 할 일은 이러한 것들을 대비를 하고 개선하는 것에 초점이 맞춰지지 않을까 생각한다.