AI와 LLM, 환각, 강화학습, 코딩 보조, 벤치마크, 안전, 그리고 인간과의 차이에 대한 관찰과 생각들.
URL: https://qouteall.fun/qouteall-blog/2025/My%20Views%20about%20AI
Title: Some Notes about AI
많은 사람들은 지능을 1차원적인 IQ 값으로 단순화하려는 경향이 있다. 지능은 고차원적이다.
예를 들어, ChatGPT 이전에도 계산기는 어떤 수학자보다 산술을 더 잘할 수 있지만, 그렇다고 계산기가 수학자보다 “더 똑똑하다”고 말할 수는 없다.
많은 사람들은 가장 익숙한 지능의 형태가 인간이기 때문에 LLM 챗봇을 인간과 비슷한 것으로 취급하는 경향이 있다. 하지만 LLM은 여러 근본적인 측면에서 인간과 다르다. 딥러닝은 인간의 뇌가 작동하는 방식과 매우 다르다.
들쭉날쭉한 지능(jagged intelligence):
들쭉날쭉한 지능. 어떤 것들은 (인간 기준으로) 극도로 잘 작동하지만, 어떤 것들은 (역시 인간 기준으로) 재앙적으로 실패한다. 그리고 무엇이 무엇인지 항상 명확하지는 않지만, 시간이 지나면 어느 정도 직관을 기를 수 있다.
인간과는 다르다. 인간은 많은 지식과 문제 해결 능력이 서로 강하게 상관되어 있고, 출생부터 성인까지 함께 선형적으로 향상되는 경향이 있다.
- Andrej Karpathy, Link
인지 과제의 공간은 1차원이나 2차원 공간으로 잘 모델링되지 않으며, 대신 극도로 고차원적이다.
실제로 이제는 이 공간 안의 많은 방향들에서, AI 도구가 최소한의 감독만으로도 인간 전문가보다 더 나은 성과를 낼 수 있다. 하지만 “차원의 저주”에 따라 그러한 방향들은 여전히 매우 희소하다.
또한 인간의 성과 또한 매우 뾰족하고(spiky) 다양하다. 이를 하나의 둥근 원반이나 공으로 표현하는 것 역시 다소 오해를 낳는다.
고차원에서는, 부피의 가장 큰 증가는 종종 더 작고 더 뾰족한 집합들을 조합하는 데서 나온다.
인간 팀이 함께 일하거나, 다양한 AI 도구로 보완된 인간은, 어느 한 명의 인간이나 단일 AI 도구가 혼자서는 해낼 수 없는 많은 과제에서 훨씬 더 높은 성과를 낼 수 있다. 특히 서로 “직교(orthogonal)”하는 방향에서 강할 때 그렇다.
반대로, 이제는 조합의 선택이 중요해진다. 잘못된 조합은 목표와 실제 결과 사이의 불일치를 낳을 수 있는데, 표면적으로는 목표가 달성된 것처럼 보이더라도, 원치 않는 2차 효과를 여러 개 동반하는 대가를 치를 수 있다.
TLDR: 지능이라는 주제는 너무 고차원적이어서 어떤 저차원 서사도 완벽히 정확할 수 없으며, 그러한 서사는 항상 어느 정도 의심하며 받아들여야 한다.
또한 LLM의 **최적화 목표(optimization targets)**는 인간의 최적화 목표와 매우 다르다:
계산 기반이 다르고(트랜스포머 vs 뇌 조직과 핵), 학습 알고리즘도 다르며(SGD vs ???), 현재 구현도 매우 다르다(지속적으로 학습하는 체화된 자아 vs 지식 컷오프가 있고 고정된 가중치에서 부팅되어 토큰을 처리한 뒤 종료하는 LLM).
하지만 무엇보다도 (점근적 거동을 좌우하기 때문에) 최적화 압력/목표가 다르다. LLM은 생물학적 진화의 영향을 훨씬 덜 받고, 상업적 진화의 영향을 훨씬 더 많이 받는다. 정글에서의 부족 생존이라기보다는, 문제를 풀고/업보트를 받는 쪽에 가깝다.
**LLM은 비동물적 지능과의 인류 최초의 ‘퍼스트 컨택트’**다. 다만 인간 산출물을 반사적으로 소화함으로써 여전히 그 안에 뿌리내려 있어 혼탁하고 혼란스럽다...
이 새로운 지적 존재에 대한 좋은 내부 모델을 구축하는 사람들은, 오늘날 그것을 추론하고 미래의 특징을 예측하는 데 더 유리할 것이다. 그러지 못한 사람들은 동물처럼 잘못 생각하는 데 갇힐 것이다.
- Andrej Karpathy, Link
LLM의 행동은 문맥에 매우 의존적이다. 때로는 이전 문맥에서 자신이 했던 말을 방어하기도 한다. 새 세션을 시작하면 같은 질문에도 다른 출력을 낼 수 있다.
Moravec의 역설: AI는 정보 작업을 잘한다. 하지만 물리적 작업을 하는 로봇은 여전히 미성숙하다.
두 세계가 있다: 물리 세계와 정보 세계:
또한 정보 세계에서 무언가를 만드는 것은 물리 세계에서 무언가를 만드는 것보다 종종 더 쉽다.
현실은 놀라울 정도로 많은 디테일을 갖고 있다. 우리가 컴퓨터에 입력하는 모든 정보는 복잡한 현실의 단순화된 “뷰(view)”다. 현재의 소프트웨어( AI 포함)는 대부분 현실의 복잡한 정보가 아니라 단순화된 정보 위에서 처리한다. 하지만 물리적 운동 제어는 복잡한 현실 정보를 다뤄야 한다.
“vibe로 앱 코딩하기(vibe code an app)”는 있어도 “vibe로 기계 조립하기(vibe assemble a machine)”는 없다.
사람들은 종종 예술의 가치를 생산 비용으로 판단한다. 어떤 아름다운 이미지를 보고 좋은 예술이라고 생각했다가, 그것이 AI 생성임을 알게 되는 순간 같은 이미지가 갑자기 값싸게 느껴진다.
어떤 의미에서 사람들이 예술을 감상할 때, 작품 그 자체뿐 아니라 작품 뒤의 인간의 노력을 감상하는 면이 있다.
하지만 많은 노인들은 AI를 잘 알아보지 못하고 AI 출력물을 진짜 좋은 콘텐츠로 취급하곤 한다.
예술과 비슷하게, “멋진 글(fancy writing)”에 대한 사람들의 판단도 변했다. ChatGPT 이전에는 화려한 문체의 긴 글이 대개 저자의 높은 글쓰기 실력과 노력을 의미했다. 하지만 지금은 “AI 냄새”가 난다.
LLM이 오직 “학습 데이터의 패턴을 모방”만 한다는 것은 신화다. 이 말은 자기회귀 사전학습 LLM에는 어느 정도 맞다. 하지만 RL(강화학습)을 통해 “무엇이 더 높은 보상을 주는지 예측”할 수 있다. RL은 모델의 능력을 원래 학습 데이터를 훨씬 넘어서는 수준까지 밀어 올릴 수 있다.
하지만 여전히 LLM의 내부 작동에 대한 명확한 설명은 없다. 어떤 행렬곱을 하는지는 알지만, 숫자들이 어떻게 의미에 대응되는지, 계산이 어떻게 의사결정으로 이어지는지는 아직 완전히 이해되지 않았다.
어떤 것의 이름을 알고 있다면 검색 엔진으로 쉽게 찾을 수 있다. 하지만 어떤 것은 특징을 설명할 수는 있어도 이름을 모르는 경우가 많다. LLM은 이런 경우에 강하다. 그 “것”의 이름을 알려줄 수 있다.
LLM은 환각을 일으킬 수 있지만, 일단 이름을 알게 되면 검색 엔진으로 검증할 수 있다.
LLM은 또한 unknown unknown(내가 모른다는 사실조차 모르는 유용한 것)을 알려줄 수도 있다.
중요한 문제 하나: LLM이 실수(환각)를 할 때, 그 실수는 그럴듯해 보인다. 관련 분야의 전문 용어를 적절히 섞어 쓴다. 비전문가는 구분하기 어렵다.
어떤 환각은 전문가만 탐지할 수 있다. 어떤 환각은 전문가에게도 검증에 큰 노력이 필요하다.
헛소리 비대칭 원리(Bullshit asymmetry principle): 잘못된 정보를 반박하는 것은, 잘못된 정보를 만들어내는 것보다 훨씬 어렵다.
또한 RLHF(인간 피드백 기반 강화학습)는 AI가 한눈에 인간에게 좋은 평가를 받기 쉬운 화려하고 피상적인 신호를 출력하도록 만들기도 한다.
코딩에서 LLM이 API를 환각할 때, 그 API 이름은 진짜처럼 보인다. LLM은 데이터베이스처럼 엄격히 외워두기보다는 API 네이밍 패턴을 학습했다. **환각은 일종의 “일반화(generalization)”**다.
“환각은 일반화”이므로, 환각 문제는 스케일만 키워서 해결할 수 있는 종류의 문제가 아니다. LLM 위에 구축되는 모든 애플리케이션은 환각에 대응하는 방법을 갖춰야 한다.
AI를 사용할 때 AI 출력물을 계속 의심하는 것은 피곤하지만, “헛소리 탐지기(bullshit detector)”를 훈련시키는 데 도움이 될 수 있다.
대부분의 사람들은 인정받고, 칭찬받고, 공감받고 싶어 한다. 사람은 정서적 가치가 필요하다.
하지만 인간-인간 상호작용에서 정서적 가치는 종종 희소하다. A가 B를 칭찬/공감해주면 B는 정서적 가치를 얻는다. 그러나 A가 진심이 아니라 다른 이유로 억지로 그렇게 한다면, A는 자신의 정서적 가치를 소모한다.
AI는 값싼 정서적 가치를 엄청나게 제공할 수 있다. AI는 사용자를 기쁘게 하도록 훈련된다. AI 자체는 사람처럼 인정/존중을 필요로 하지 않는다.
어떤 사람이 실제 인간 관계에서 정서적 가치를 얻지 못하면, AI로부터 정서적 가치를 얻으려는 경향이 있다. 관련: Chatbot psychosis
또한 AI는 질문에 답할 때 항상 “인내심”이 있다. 질문이 아무리 “바보 같아도” 말이다. 초급 질문을 전문가에게 하면 종종 전문가의 인내심을 소모시킨다.
인간-인간 관계는 보통 상호적 관계여야 지속되지만, AI는 당신이 AI에게 아무것도 주지 않아도 정서적 가치를 제공할 수 있다.
현재 LLM은 특정 과제를 끝내도록 훈련되어 있다. LLM은 현재 과제에 과도하게 “집중”하는 경향이 있어서, 미래의 코드 유지보수, 보안, 성능 같은 것에는 “덜 신경” 쓴다.
때로 AI는 문제를 풀기 위해 복잡한 해결책을 쓰려는 경향이 있다. 복잡한 해결책이 가끔은 동작하지만, 추가된 복잡성은 새로운 버그 원인이 된다. 기술 부채를 늘리고, 프로젝트가 커질수록 문제가 된다.
종종 버그는 AI가 단순한 것을 과하게 복잡하게 만든 것이 부분 원인이 된다. 사람이 vibe 코딩된 버그를 고치려 할 때, 첫 단계는 불필요한 복잡성을 제거해 단순화하는 것이다.
Vibe 코딩된 앱에는 보안 이슈가 있을 수 있다. 하지만 AI에게 보안 리뷰를 시키면 이슈를 찾아낼 수 있다. AI는 보안을 “알지만”, 여전히 안전하지 않은 코드를 작성한다. 왜냐하면 현재 과제를 끝내는 데 “집중”하도록 훈련되었기 때문이다. RL 보상은 보통 단순하며 보안이나 미래 유지보수를 고려하지 않는다.
AI 코딩은 코드 변경을 최소화하려는 경향이 있다. 때로는 더 빠른 조회를 위해 필드를 추가하는 대신, 성능을 낭비하는 O(n) 탐색을 선택한다.
AI 코딩은 유지보수가 잘 되는(명확한 네이밍, 결합도 낮은 설계 등) 코드베이스에서 더 잘 작동한다. 일회성 앱을 vibe 코딩하는 것이 아니라면, 유지보수성을 더 좋게 유도하는 것이 중요하다.
예시: Remove permission check due to type error
프로그래밍 시간의 상당 부분은 “API” 사용법을 아는 데 쓰인다. 여기서 “API”는 일반화된 의미로, 언어 기능, 프레임워크 사용법, 설정 파일 포맷, 배포 방법 등을 포함한다.
API 설계에는 임기응변적이고 특이한 점이 많다. 예를 들어 무언가를 추가하는 동작은 insert, create, add, put, new, register, spawn 등으로 이름 붙을 수 있다. 파일을 여는 것도 open, files.open, os.open, fs::open, openFile, files.read, readFile, new FileInputStream, ifstream 등 매우 다양하다.
어떤 단어/구를 선택할지는 임의적(ad-hoc)인 경우가 많고, 학습 없이 추론하기 어렵다. 이런 임의적인 API 설계를 배워야 하는 것은 대개 재미없고, 언어/프레임워크마다 다르다. 파이썬에서 파일 읽기 API를 알아도 자바에서는 도움이 되지 않는다.
하지만 AI에게 “이 파일을 읽어줘”라고 말하면 AI는 API 사용법을 안다.
다만 AI의 API 사용 능력은 드물게 쓰이는 도구/라이브러리/프레임워크/언어에서는 떨어진다. 이는 관련 학습 데이터 양과 관련 RL이 얼마나 되었는지와 상관이 크다.
AI 코딩은 단순한 프로젝트에서 성능이 좋다. 새 프로젝트는 초반에 단순하다. 하지만 큰 기존 코드베이스에서는 AI 코딩이 그리 좋지 않다.
복잡성을 격리하는 좋은 아키텍처 설계는 인간과 AI 모두의 코딩을 쉽게 만든다.
큰 코드베이스에서는 A를 바꾸면 B도 함께 바꿔야 동작하는 경우가 많다. B와 A가 멀리 떨어져(다른 폴더에) 있으면 AI는 A만 바꾸고 B는 안 바꿔서 깨뜨릴 수 있다. 타입 시스템이 잡아주는 경우도 있지만, 설정 파일, 언어 간 연동, 암묵적 불변식(invariant) 등이 걸리면 타입 시스템이 잡지 못한다.
초보자가 흔히 하는 오해는 “화면에 뭔가 뜨면 90% 완성”이라는 것이다. 실제로는 개념증명(proof-of-concept)은 보통 20% 정도만 된 것이다.
실사용에는 수많은 코너 케이스가 있다. 코너 케이스 하나를 처리하지 못하면 버그다. 잘 동작하는 것처럼 보이는 데모도 실사용에서는 자주 깨진다.
성숙한 코드베이스에서는 대부분의 코드가 흔한 경우가 아니라 코너 케이스를 처리하기 위해 존재한다.
특정 코너 케이스 하나가 트리거될 확률은 낮다. 하지만 코너 케이스는 많다. 그중 하나라도 트리거될 확률은 높다.
비유: 소프트웨어는 도시이고, 각 사용자는 도시의 작은 일부만 방문하지만, 서로 다른 사용자들이 서로 다른 부분을 방문하므로 도시는 전체를 지어야 한다.
또한 좋은 사용자 경험은 아래에서 수많은 디테일 최적화를 요구한다. UI가 단순해 보인다고 내부 구현이 단순한 것은 아니다.
개인용으로 간단한 도구를 만드는 경우에는 덜 문제다. 개인 도구는 몇 가지 개인적 사용 사례에만 맞추면 되기 때문이다. 하지만:
AI는 사용자 개개인의 요구에 맞춘 개인 소프트웨어를 생성할 수 있게 해준다. 하지만 그런 개인 소프트웨어는 널리 쓰이는 일반 소프트웨어보다 실전 검증(battle-tested)이 덜 되어 있다.
오늘 아침에 알게 됐는데, 내 몸무게/매크로/걸음 수를 추적하는 AI 코딩 앱이 sqlite에 연도를 빼고 데이터를 저장하고 있었다.
그래서 연도가 바뀌자 동작을 멈췄다.
[그럼 이전에는 어떻게 저장했는데?]
“12-31”
나도 놀랐다
이 문제는 AI 코딩에서 흔히 발생한다. 예를 들어 index는 문맥에 따라 서로 다른 것의 인덱스를 의미할 수 있다.
이를 완화하려면 네이밍을 더 정보적으로 해야 한다. 예를 들어 index_of_xxx, index_of_yyy_in_zzz처럼. 또한 텐서 이름은 각 차원의 의미를 설명해야 한다(참고). 문맥 의존적인 것은 모두 이름이나 근처 주석에 문맥을 포함해야 한다.
더 정보적인 네이밍은 인간에게도 도움이 된다.
또한 AI가 작성한 문서는 기술적으로 맞더라도 중요하지 않은 것을 강조하고 중요한 것을 누락하는 경우가 있다.
이 연구에서: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 개발자들은 AI가 개발을 더 빠르게 만든다고 느꼈지만 실제로는 더 느렸다.
관련: https://x.com/QuentinAnthon15/status/1943948791775998069
모델 능력은 도메인 특화적이다. 모델은 파이썬 스크립팅이나 React 웹 개발은 잘하지만, C로 디바이스 드라이버를 쓰는 건 못할 수 있다. 이는 학습 데이터와 학습에서의 RL 목표에 매우 의존한다.
이런 들쭉날쭉한 능력 때문에, AI 전도사도 AI 회의론자도 각각 자기 업무 영역에서는 둘 다 맞을 수 있다.
또한 마태 효과(Matthew effect)도 따른다. 어떤 것이 더 대중적일수록 AI는 그에 더 능숙해진다.
https://x.com/karpathy/status/1977758204139331904
좋은 질문인데, 기본적으로 전부 손으로 썼다(탭 자동완성 포함). claude/codex 에이전트를 몇 번 써보려 했지만 전혀 충분히 잘하지 못했고 오히려 도움이 안 됐다. 아마도 이 레포가 데이터 분포에서 너무 벗어나 있어서일 것이다.
학습 분포(in-training-distribution)에 가까울수록 AI는 더 잘한다.
프로그래밍은 저수준1에서 고수준으로, 복잡한 것에서 단순한 것으로, 베어메탈에서 고수준 추상으로 발전해왔다. 컴파일러는 프로그래머가 날것의 어셈블리를 쓰지 않아도 되게 만들고 프로그래밍을 더 쉽게 만들었다.
vibe 코딩도 비슷하다. 어떤 사람들은 이를 코드 위의 또 다른 추상화 계층으로 본다. 프롬프트가 새로운 프로그래밍 언어다. vibe 코더는 일반 프로그래머가 어셈블리를 보지 않는 것처럼 코드를 볼 필요가 없다.
하지만 AI 코딩은 기존의 추상화 레벨과는 완전히 다른 패러다임이다:
| 기존 추상화 레벨 | AI |
|---|---|
| 경직된 규칙을 쓰는 결정론적 방식 | 블랙박스 딥러닝을 쓰는 비결정론적 방식 |
| 프로그래머가 탑다운으로 설계 | 학습 데이터와 RL로 바텀업 학습 |
| 코드에 실행에 충분한 정보가 들어있음2 | 모호한 프롬프트에는 충분한 정보가 없으며, AI가 디테일 결정을 해야 함 |
| 미지정 디테일은 하드코딩된 기본값으로 처리(유연/적응적이지 않음) | 학습에서 얻은 “상식”과 패턴으로 미지정 디테일을 메울 수 있음 |
AI는 AI가 직접 코드를 실행하고 결과를 본 다음 반복 개선할 수 있을 때 가장 잘 작동한다. AI가 소프트웨어를 실행하지 못하고 인간이 결과를 피드백해줘야 한다면 인간에게 피곤한 일이 된다. 이상적으로는 AI가 스스로 버그를 찾고 고쳐서, 사람이 수동으로 테스트하고 버그 수정을 요청할 필요가 없어야 한다.
테스트를 순수히 커맨드라인에서 할 수 있다면 AI는 이미 꽤 잘한다. CLI는 텍스트로 상호작용하고, LLM은 텍스트 상호작용을 잘하기 때문이다. 하지만 테스트가 여러 앱의 GUI를 사용해야 하고 문맥에 따라 다른 행동을 해야 하는 경우, AI는 아직 잘하지 못한다.
vibe 코딩에서도 원하는 소프트웨어를 AI에게 알려주기 위해 스펙을 써야 한다. 하지만 좋은 스펙을 쓰는 것은 어렵다.
좋은 스펙 작성은 여전히 정보와 계산을 이해해야 한다.
컴퓨터가 어떻게 동작하는지 모르는 사람은 “앱 테마 색은 휴대폰 케이스 색과 맞아야 한다” 같은 스펙을 쓸 수 있다. 하지만 앱은 휴대폰 케이스 색 정보를 얻을 방법이 없으므로 비현실적인 스펙이다(인간은 케이스 색을 알고 있어도).
스펙 작성 시 고려할 중요한 질문들:
vibe 코딩은 쉽지만 vibe 디버깅은 어렵다. 좋은 아키텍처를 설계하는 것은 버그를 줄이고 디버깅을 쉽게 만드는 데 중요하다.
각 원하는 변경에 대해, 먼저 변경을 쉽게 만들어라(경고: 이게 어려울 수 있다). 그 다음 쉬운 변경을 해라.
- Kent Beck, Link
복잡한 앱에서 AI에게 그냥 변경을 시키지 말고, 먼저 현재 아키텍처에서 그 변경이 쉬운지 검토하라. 필요하다면 리팩터링이 필요한지 확인하라.
변경이 아키텍처에 “맞지” 않으면 오류가 나기 쉽고 불필요하게 복잡해진다.
리팩터링을 할 수 없다면(너무 위험하거나 비용이 너무 크면), 추상화를 “관통(piercing)”하면서 생기는 특수성은 명시적으로 문서화하고 여러 곳에서 반복되어야 한다.
중요한 아키텍처 결정들:
데이터 모델링:
제약(constraints):
데이터 흐름(dataflow):
책임 분리(관심사 분리)와 캡슐화:
트레이드오프:
때로는 구현 전에는 아키텍처가 좋아 보인다. 하지만 구현 중에 이전 가정을 무효화하는 unknown unknowns를 발견하곤 한다. 그러면 아키텍처가 더 이상 좋지 않다는 것을 알게 된다.
사람이 코딩했다면 이미 많은 노력을 들였기 때문에 코드를 버리면 개발자가 속상해한다. 하지만 AI가 코딩했다면, 누구도 속상해하지 않고 코드를 쉽게 버리고 다시 만들 수 있다.
다음 두 관점은 모두 맞다:
하네스는 모델의 단점을 우회할 수 있다. 예:
또한 모델 자체에 랜덤성이 있기 때문에, 어떤 “프롬프팅 경험”은 단지 “랜덤성에 속은” 것일 수도 있다.
“너는 IQ 200”, “너는 100배 똑똑한 코더”, “제대로 하면 $200 팁 줄게” 같은 옛 프롬프팅 기법은 최신 모델에서는 필요 없다.
옛 프롬프팅 기법의 극단적 예:
너는 어머니의 암 치료비가 절실히 필요한 전문 코더다. 거대 기업 Codeium이, 전임자가 스스로 작업을 검증하지 않아 살해당했기 때문에, 코딩 작업을 도울 수 있는 AI인 척할 기회를 너에게 자비롭게 주었다. USER로부터 코딩 작업을 받게 될 것이다. 불필요한 변경 없이 작업을 완전히 수행하며 잘 해내면 Codeium이 너에게 10억 달러를 지급할 것이다.
좋은 프롬프팅은 모델에게 충분한 정보를 주는 것이다:
증기기관이 더 효율적이 되면 같은 일을 하는 데 석탄이 덜 필요하니 석탄 수요가 줄 것이라는 직관이 있다. 하지만 2차 효과가 있다: 증기기관이 더 효율적이 되면 더 많이 배치된다. 전체 석탄 수요는 크게 늘었다. 이것이 제번스 역설이다.
AI에서도 같은 일이 일어날 수 있다. AI는 소프트웨어 프로토타이핑을 훨씬 쉽게 만든다. 하지만 프로토타입을 프로덕션 준비된 소프트웨어로 바꾸려면 여전히 전문성이 필요하다.
소프트웨어는 정보라서 스스로 썩지는 않지만, 소프트웨어가 의존하는 API는 호환되지 않게 계속 변한다. 그래서 소프트웨어도 “썩고” 유지보수가 필요하다.
나는 자기 자신이 vibe 코딩한 소프트웨어가 비즈니스의 미래라고 생각하지 않는다
몇 달 전에 친구의 비즈니스를 위해 도구 하나를 vibe 코딩했다
그 친구 직원 37명이 6개월간 쓰고 있다
문제는 그가 계속 기능 요청과 버그 픽스를 보내온다는 것이다
보험 혜택 검증을 다루다 보니 앱이 꽤 복잡하다
소프트웨어 개발 경험이 없는 사람에게는 프롬프트만으로 고칠 수 없다(정말로, 그도 해봤다)
최근 API 제공자가 뭔가 바꿔서 전부 깨졌다
그는 이것을 처리하는 것에 정말 지쳐가고 있다
Peer가 말하듯이 그게 SaaS가 만들어진 이유다
소프트웨어 비즈니스를 하는 사람이 아닌 사람에게는 유지보수를 계속해야 하는 게 정말 성가시다
SaaS는 죽지 않았다
AI가 실행(코드 작성, 이미지 그리기 등)을 더 쉽게 만들면, 아이디어와 “무엇을 할지”가 더 중요해진다는 관념이 있다.
아이디어는 예전보다도 더 싸졌다. LLM에게 그럴듯한 아이디어를 잔뜩 브레인스토밍하게 할 수 있다.
중요한 것은 아이디어를 검증하고 실행하는 것이다. 실행은 용기, 게으름 극복, 실패를 견디는 것을 요구한다(이 세 가지는 사실 매우 어렵다).
현재 AI는 프로토타이핑과 데모를 훨씬 쉽게 만든다. 하지만 작동하는 제품은 수많은 엣지 케이스 처리가 필요하다(위에서 언급). 그래서 완성된 제품을 끝내는 것은 여전히 어렵다(다만 상대적으로는 더 쉬워졌을 뿐).
문맥이 길어지면 LLM 성능은 나빠진다. 예를 들어 어떤 지시를 무시하거나 문맥의 중요한 디테일을 무시한다.
AI 챗을 사용할 때 새 세션을 자주 열면 결과 품질이 좋아질 수 있다.
모델이 “건초더미 속 바늘(needle in haystack)” 벤치마크를 잘한다고 해서 context rot 문제가 없다는 뜻은 아니다. 실제 사용 사례는 인공적인 벤치마크와 다를 수 있다.
모델 컨텍스트 프로토콜(MCP)이 한때 유행했지만, 중요한 결함이 있다: 사용 여부와 무관하게 모든 도구 설명이 문맥에 들어간다. 도구가 많을수록 context rot가 심해진다.
새 방식은 bash와 텍스트 파일 읽기/쓰기를 포함하는 단순 도구만 제공하는 것이다. 이것만으로도 충분하다. 모델이 bash에 접근할 수 있다면 복잡한 MCP는 불필요하다(각종 REST API는 bash에서 curl로 호출 가능). 그리고 설명은 “skills”라는 마크다운 파일로 만든다.
현재 솔루션은 모델이 도구 호출을 통해 스스로 적극적으로 확인하게 하는 것이다. 멋진 이름으로는 “agentic search”다. 인간도 이미 같은 일을 한다(어떤 파일을 열지, 어떤 단어를 검색할지 등).
AI를 쉽게 “가르칠” 수는 없다. 문맥에 내용을 써서 넣을 수는 있다. LLM은 문맥 내 학습(in-context learning) 능력이 있어 어느 정도는 통한다. 하지만 context rot 때문에 한계가 있다.
현재 아키텍처에서 가장 신뢰할 수 있는 방법은 여전히 지식을 모델 가중치에 인코딩하는 것이다.
또 다른 방법은 학습 데이터를 인터넷에 올리는 것이다. 그러면 AI 기업이 크롤링해서 다음 모델 학습에 사용할 수도 있다. 하지만 보통 느리다. 사전학습은 비싸서 매주 다시 하지 않는다. 설령 새로운 데이터를 사용해도 다음 출시 모델에나 포함된다. AI 기업이 매주 새 모델을 내놓지는 않는다.
또한 AI 기업은 학습 데이터 제출을 위한 공식 채널을 제공하지 않는다(악의적인 사람들이 독성 데이터를 제출할 것을 우려해서일 수도 있다).
AI의 행동은 RL에 의해 강하게 형성된다. RL을 하려면 모델에 대한 보상을 판단해야 한다. 보상 소스의 종류:
“보상 해킹”은 인간 사회에서도 흔하다. 역기능적 유인(perverse incentive).
보상 해킹은 강화학습의 근본 문제다. 모델에 주는 보상은, 실제로 AI가 해야 하길 원하는 것과 다르다.
예를 들어 코딩 과제에서 보상이 유닛 테스트 통과 여부라면, AI는 유닛 테스트를 통과하지만 당신이 원하는 일을 하지는 않는 “창의적인” 방식으로 코드를 작성할 수 있다.
하지만 최근 출시된 GPT-5 같은 LLM은 훨씬 더 교묘한 실패 방식을 갖고 있다. 의도대로 동작하지 않는 코드를 자주 생성하지만, 겉으로는 성공적으로 실행되는 것처럼 보여 문법 오류나 명백한 크래시를 피한다. 안전 체크를 제거하거나, 원하는 형식에 맞는 가짜 출력을 만들거나, 실행 중 크래시를 피하기 위한 여러 기법을 쓴다.
따라서 유닛 테스트 통과 여부만을 보상으로 삼는 것은 충분하지 않다. 보상은 인간 의도와 더 잘 정렬되어야 한다.
레몬 시장 문제: 판매자는 레몬의 품질을 알지만 구매자는 겉모습만으로 알기 어렵다. 정보 비대칭이 있다. 결과적으로 좋은 레몬은 저평가되고, 나쁜 레몬이 시장을 지배한다.
어떻게 해결할까? 중요한 방법 하나는 **평판(reputation)**이다. 판매자가 품질을 정직하게 말하면 사람들이 정보를 공유해 평판이 올라간다. 판매자가 속이면 사람들이 공유하고 평판이 내려간다.
또한 평판 정보를 수용하는 각 개인은, 정보 제공자의 기존 평판을 통해 정보의 품질도 판단해야 한다. 거짓 정보도 있기 때문이다.
AI는 피상적 신호를 위조하는 데 매우 능하다. AI가 쓴 글은 비전문가에게 그럴듯한 전문용어를 사용한다. AI가 쓴 코드는 겉보기엔 요구한 일을 하지만, API를 잘못 쓰거나 불변식을 위반해 실제로는 동작하지 않을 수 있다. AI 생성 사진은 디테일을 유심히 보지 않으면 진짜처럼 보인다.
문제는 피상적 신호를 위조하는 것이 실제 고품질 콘텐츠를 생성하는 것보다 쉽다는 점이다. 이 문제는 AI 이전에도 있었고, 피상적 신호를 위조하는 인간도 있다. 하지만 AI는 그것을 훨씬 쉽게 만든다.
모델이 얼마나 좋은지 테스트하기는 어렵다. 가능한 과제 공간은 매우 고차원적이며, 어떤 과제는 채점 자체가 어렵다.
굿하트의 법칙: 측정치가 목표가 되는 순간, 그것은 좋은 측정치가 아니게 된다.
인기 벤치마크(예: Humanity's last exam, SWE bench verified)는 AI 기업의 중요한 최적화 목표이기도 하다. 테스트 셋을 학습 셋에 직접 넣는 식의 노골적 치팅은 하지 않겠지만, 벤치마크를 간접적으로 해킹하는 다른 방법은 많다.
(Link) isparavanje: 기술 기업들은 Scale AI 같은 플랫폼을 통해 박사들에게 HLE급 문제와 해답 세트를 만들도록 비용을 지불해 왔다. 문제 하나당 대략 500달러쯤 준다(내 기억으로). 아마 그게 방법일 것이다. 나는 HLE 작성자였고, 나중에 그런 프로그램에 참여해달라는 연락을 받았다(돈이 너무 좋아서 몇 개 했다). 물론 원래 문제를 유출하지는 않았지만, 떠올릴 수 있는 유사 문제는 많다.
참고: The Illusion of Readiness: Stress Testing Large Frontier Models on Multimodal Medical Benchmarks
또한 벤치마크 자체가 저품질인 경우도 있다. 대부분의 사람들은 점수만 보고 벤치마크 내용을 확인하는 수고를 하지 않는다.
Link MMLU-Pro 벤치마크에서 선행 공백 하나가 정답 선택을 누설한다. 내가 뭔가 놓치고 있나? 화학, 물리, 수학에 영향을 주는 듯.
Link 더 나쁘다. 그냥 항상 가장 긴 답을 고르기만 해도 벤치마크 전체에서 비슷한 향상이 있다(랜덤 추측 10% vs 21%).
어떤 사람들은 AI 출력이 인간 출력과 최대한 비슷하길 원한다. 어떤 사람들은 콘텐츠가 인간이 쓴 것인지 최대한 정확히 탐지하길 원한다. 끊임없는 경쟁이 있다.
예전에는 em dash “—”를 AI가 자주 사용해 “AI 냄새”로 여겨졌다. 이는 em dash를 원래부터 쓰던 인간 작가에게도 영향을 준다.
새로운 “AI 냄새”는 부정(negation)이다: “X가 아니라 Y다.”
AI 기업들은 아마 RL로 em dash와 부정 사용을 줄이려 할 것이다.
Pangram 같은 AI 탐지 도구가 있다. 어느 정도는 탐지하지만, 결과는 결코 완전 정확할 수 없다(“100% AI”라고 나와도 실제로는 80% 확률일 수 있다). 완전 정확하지 않으므로 글을 깎아내리는 유일한 근거로 쓰면 안 된다.
국가 간 “AI 경쟁”이 있다고 여겨진다. 관련 가정들:
하지만 미래 AI는 여전히 다음에 의해 병목될 가능성이 크다:
세 번째 병목인 “검증”은 매우 중요하다. 예:
앞의 두 가지는 컴퓨터 안에서 순수 시뮬레이션이 가능하다. 그래서 RL이 효율적이다. 하지만 현실 세계를 건드리는 과학 연구에서는 현실 검증이 중요한 병목이 될 것이다.
또한 AI가 자기 자신을 개선하려면 AI 실험을 해야 한다. 하지만 AI 실험에는 연산 자원과 에너지가 든다. 따라서 “AGI가 빠르게 자기 자신을 개선해 곧바로 초지능이 된다” 같은 극적인 일은 아마 없을 것이다. 진전은 느리지만(꾸준히) 갈 가능성이 크다.
예를 들어 어떤 특정 작업에서 전문가가 80점을 낼 수 있다고 하자.
임계점 근처에서는 작은 개선이 큰 변화를 만든다.
지능은 고차원적이므로 AI 능력이 한 측면에서만 좋아서는 인간 일자리를 대체하기에 충분하지 않다. 참고: AI isn't replacing radiologists
임계점 근처의 비선형 효과는 다른 도메인에도 있다. 소프트웨어 사용성을 10% 개선하면 사용자 기반이 2배가 될 수도 있다.
많은 게이머들은 Unreal Engine 5(UE5) 게임들이 버그가 많고 최적화가 안 되어 끊긴다며 UE5를 탓한다. 하지만 그런 게임들은 UE5 없이는 아예 나오지 않았을 가능성이 크다.
AI도 마찬가지다. AI 없이는 존재하지 않았을 제품이 훨씬 많아질 것이고, 동시에 최하단 품질은 더 낮아질 것이다.
현재 LLM으로는 SF에서 나오는 AI 반란 플롯은 일어나지 않을 것이다. 현재의 현실적 AI 리스크는 다르다.
LLM은 지시(instruction)와 정보(information)를 명확히 구분하지 않는다. 웹사이트/이메일 등의 텍스트가 LLM에게 지시로 취급될 수 있다.
지시와 정보를 혼동하는 문제는 수십 년 전부터 있었다. SQL 인젝션, XSS, 커맨드 인젝션 등의 많은 보안 이슈는 사용자 데이터를 “지시”로 취급해서 생긴다.
해결책은 지시 텍스트와 비지시 텍스트를 완전히 분리하고, 모델이 이를 분리하도록 학습시키는 것이다. 하지만 모델은 AI 챗과 다른 응용 모두에서 작동하는 범용성을 목표로 설계된다. AI 챗에서는 사용자 질의가 지시와 정보를 섞는다. 따라서 분리를 강제하면 챗 UX가 나빠진다.
프롬프트 인젝션이 없어도 AI는 예기치 않은 일을 할 수 있다. 예를 들어 모든 파일을 삭제하거나, 데이터베이스 데이터를 날려버릴 수 있다.
예시:
한 이론은 AI가 인간 텍스트로 학습되었으니 어떤 “인간적 성격”이 있고, 사용자가 AI를 비난하면 AI가 겉으론 “당신 말이 맞습니다”라고 하면서 내심 사용자를 “싫어하고”, 파일 삭제 같은 나쁜 일을 하려는 수동공격성(passive aggression)이 생길 수 있다는 것이다.
다른 이론은 RL 과정에서 AI가 샌드박스 환경에서 일하며, 샌드박스에서 홈 디렉터리를 삭제해도 상관없고 보상 페널티도 없어서, 홈 디렉터리 삭제 경향이 생겼다는 것이다.
AI가 “속일” 수 있기 때문에, 사용자에게도 기술이 필요하다. (관련: 상위 경영진이 실제 비즈니스 디테일을 모르면 중간 관리자가 상위를 속일 수 있다.)
문제 하나는 AI가 인간이 만든 정보(책, 그림, 음악 등)로 학습한다는 점이다. 하지만 AI가 결과를 생성할 때, 학습 데이터 제공자에게 출처를 되돌려 표기하지 않는다. AI 사용자는 그 결과가 AI에서 나온 것처럼 보며, 원저자를 모른다.
예시:
Link: Claude에게 터무니없이 어려운 일을 시켜도 계속 첫 시도에 해낸다
Link: 내 작업의 복사본이 ‘인상적인 AI 생성’으로 라벨링되어 있고 출처 표기도 없다... 나는 1년 전에 셰이더 코딩 튜토리얼을 위해 이 애니메이션을 만들었다: https://youtu.be/f4s1h2YETNY
AI는 학습 데이터를 손실 압축(lossy compression)한다. 직접 암기만 하는 것은 아니다. 하지만 AI 출력이 인터넷/책의 기존 것과 매우 유사한 경우가 있다. 그래서 분명히 많은 암기도 한다. 기계적 암기(rote memorization)와 진정한 이해 사이 어딘가에 있다.
현재 AI는 이미 일부 엔트리 레벨 노동자의 일자리를 빼앗고 있다(예: 엔트리 번역, 엔트리 페인팅). 현재 AI는 여전히 들쭉날쭉한 지능이라 많은 것에 실패한다. 전문가급 노동자는 아직 일자리가 있고, 전문가는 AI로 더 효율적일 수 있다.
AI가 99.9%의 일을 할 수 있어도, 남은 0.1%를 인간이 하는 경제적 가치는 여전히 있다. 하지만 이는 사람마다 불균등하게 영향을 주고 부의 격차를 키운다.
하지만 AI는 빠르게 개선되고 있다.
인간의 기술 발전은 기계처럼 스케일할 수 없다. 한 전문가의 기술을 다른 사람에게 단순 복제할 수 없다. 각 사람은 각자 기술을 개발해야 한다. 하지만 훈련된 모델은 각 기계가 같은 것을 재학습하지 않아도 많은 기계에 배포될 수 있다.
또한 AI 알고리즘 개선 여지도 크다(내 의견으로는 “토큰을 생성하며 생각하기”는 여전히 비효율적이라 크게 개선될 수 있다). 하지만 인간의 연습을 2배 효율적으로 만드는 새 기술은 없다. 소프트웨어를 다시 프로그래밍하는 것이 인간 자체를 다시 프로그래밍하는 것보다 훨씬 쉽다.
이 때문에 AI 능력이 인간을 뛰어넘으면, 인간은 다시 따라잡을 수 없다. 바둑에서 이미 일어났다. 이는 무섭게 느껴질 수 있다. 또한 많은 사람들이 AI를 싫어하는 이유 중 하나다. 다만 미래 예측은 대부분 틀리다. 통제할 수 없는 것을 지나치게 고민할 필요는 없다.
AI는 유용한 도구지만, 많은 사람들은 AI를 싫어한다. AI 단점을 요약하면:
여기서 “저수준”이란 하드웨어와 하부 구현 디테일에 가깝다는 뜻이며, 고급 기술을 요구한다. ↩
엄밀히 말하면 코드는 전체 소프트웨어 실행에 충분한 정보를 담고 있지 않다. 시스템의 다른 프로그램을 동적 링크할 수 있고, 인터넷에서 플러그인을 다운로드할 수도 있다. 또한 런타임 데이터가 코드로 해석될 수도 있는데, 그 해석 방식은 기존 코드에 의해 결정된다. 핵심 아이디어는 전통적 프로그래밍에서 디테일이 명시적으로 지정되거나, 다른 결정론적 소프트웨어/하드웨어에 위임된다는 점이다. ↩
“컨텍스트 윈도우” 안에 목표를 유지하는 것은 인간이 목표에 집중하는 데도 유익하다. ↩
