Forwarded from BHI
[에이전트 기반 메모리 관리 : 99%의 정확도를 기록한 체계 - SuperMemory]
트위터 원문
트위터 원문
우리는 에이전트 메모리의 최전선을 돌파했다.
약 99% 수준의 SOTA 메모리 시스템을 소개한다.
에이전트 메모리는 이제 사실상 완전히 해결됐을지도 모른다.
몇 년 안에 수십억 개의 에이전트가 각 사용자에 맞게 고도로 개인화되고 전문화되어, 우리가 하는 모든 것을 바탕으로 계속 학습하고 진화하게 될 것이다.
이것이 바로 우리가 수년간 AI 메모리를 연구해온 이유다.
그리고 마침내 그것을 거의 완성해낸다면 어떤 일이 벌어질까?
몇 달 전, 우리는 첫 번째 연구 보고서를 공개하며 Supermemory가 LongMemEval-s에서 약 85% 를 기록했고, 당시 공개 벤치마크된 모든 메모리 시스템보다 앞섰음을 보여줬다.
오늘 우리는 새로운 결과를 공개한다.
LongMemEval_s에서 약 99% 다.
처음부터 분명히 말하자면, 이것은 아직 우리의 메인 프로덕션 Supermemory 엔진에 들어간 것은 아니다.
이번 블로그는 우리가 프로덕션 환경의 핵심 제약과는 독립적으로, 메모리 검색과 추론의 절대적 한계를 어디까지 밀어붙일 수 있는지 보기 위해 만든 매우 실험적인 agentic flow를 다룬다.
몇 달간의 연구 끝에 여기까지 왔다.
우리가 이 성과를 낼 수 있었던 방식은 다음과 같다.
새로운 기법 ASMR (Agentic Search and Memory Retrieval) 을 소개한다.
이 기법의 특징은 다음과 같다.
구현이 정말 쉽다
벡터 데이터베이스나 임베딩이 전혀 필요 없다
완전히 인메모리 방식으로도 가능하다
따라서 로봇 같은 다른 시스템에도 내장할 수 있다
소개
LongMemEval은 장기 메모리를 평가하는 공개 벤치마크 중에서도 가장 엄격한 축에 속한다.
짧은 문맥에서 단순 검색만 테스트하는 벤치마크와 달리, LongMemEval은 실제 프로덕션 환경의 혼란스러움을 시뮬레이션하도록 설계되어 있다.
예를 들면 11.5만 토큰이 넘는 대화 기록, 서로 모순되는 정보, 여러 세션에 걸쳐 흩어진 사건들, 그리고 시간을 기준으로 추론해야 하는 질문들이 있다.
대부분의 메모리 시스템이 낮은 점수를 받는 이유는 대개 추론이 아니라 검색 때문이다.
회상률이 높더라도, 검색된 정보에 노이즈가 많으면 LLM은 그것을 제대로 활용하지 못할 수 있다.
핵심 문제는 정확히 필요한 정보만 컨텍스트 윈도우 안으로 가져오는 것이며, 더 어려운 문제는 검색된 사실이 이미 오래된 정보인지, 더 최신 정보가 그것을 대체했는지를 아는 것이다.
이를 해결하기 위해 우리는 전통적인 RAG에서 벗어나 멀티 에이전트 오케스트레이션 파이프라인을 구축했다.
구성 및 실험 아키텍처
표준 벡터 검색은 일반적으로는 괜찮다.
하지만 조밀하고, 다중 세션 기반이며, 시간 정보가 중요한 데이터의 미묘한 차이를 다룰 때는 무너진다.
의미 유사도 매칭만으로는 오래된 사실과 새로 수정된 사실을 안정적으로 구분할 수 없다.
LongMemEval의 복잡성을 다루기 위해 우리는 인제스트와 검색 파이프라인을 처음부터 다시 설계했고, 벡터 계산을 능동적인 agentic reasoning으로 대체했다.
ASMR이라는 이름처럼, 이 기법은 단순하면서도 만족스럽다.
1. 병렬 오케스트레이션 및 인제스트 (Observer Agents)
사용자 세션을 청크로 나누고 임베딩하는 대신, 우리는 3개의 병렬 리더(Observer) 에이전트를 사용하는 오케스트레이터를 배치했다.
이 에이전트들은 원시 세션을 동시에 읽는다.
예를 들어 Agent 1은 세션 1, 3, 5를 맡고, Agent 2는 2, 4, 6을 맡는 식이다.
(모델: Gemini 2.0 Flash)
이들의 목표는 다음 6개 벡터에 걸쳐 타깃형 지식 추출을 수행하는 것이다.
개인 정보
선호
사건
시간 정보
업데이트
어시스턴트 정보
이렇게 구조화된 결과물은 네이티브하게 저장되고, 원본 세션과 매핑된다.
2. 능동적 Agentic Retrieval (Search Agents)
질문이 들어오면 우리는 벡터 데이터베이스를 조회하지 않는다.
대신 3개의 병렬 검색 에이전트를 투입한다.
이 에이전트들은 저장된 결과물을 실제로 읽고 추론하며, 각각 특화된 초점을 가진다.
Agent 1: 직접적 사실과 명시적 진술을 찾는다
Agent 2: 관련 맥락, 사회적 단서, 함의를 찾는다
Agent 3: 시간순 타임라인과 관계 맵을 재구성한다
오케스트레이터는 세 검색 에이전트의 결과를 취합하고, 세부 검증을 위해 원문 세션 발췌문을 그대로 끌어온다.
이를 통해 단순 키워드 매칭이나 수학적 유사성이 아니라, 실제 인지적 이해를 바탕으로 한 지능형 검색이 가능해진다.
3. 에이전트 오케스트레이션 기반 응답 앙상블
문맥이 조립된 뒤에도, LongMemEval에는 질문 유형이 너무 다양해서 단일 프롬프트 하나로는 처리할 수 없다.
어떤 질문은 추론이 필요하고, 어떤 질문은 극도로 정확해야 한다.
그래서 우리는 두 가지 서로 다른 agentic answering flow를 실험했다.
Run 1: 8-Variant Ensemble (정확도 98.60%)
첫 번째 접근에서는 검색된 문맥을 8개의 고도로 특화된 프롬프트 변형에 병렬로 넣었다.
예를 들면 Precise Counter, Time Specialist, Context Deep Dive 같은 역할들이다.
각 변형은 문맥을 독립적으로 평가하고 답을 생성한다.
그리고 이 8개의 서로 다른 추론 경로 중 하나라도 정답에 도달하면 그 문제는 정답으로 처리했다.
이 병렬 멀티-저지 방식 덕분에 우리는 무려 98.60%의 전체 정확도를 달성했고, 블라인드 스팟까지 완벽하게 커버할 수 있었다.
Run 2: 12-Variant Decision Forest (정확도 97.20%)
이번에는 여러 번의 독립적 시도 중 하나가 맞는 방식이 아니라, 하나의 권위 있는 단일 답변을 내는 시스템을 시험하기 위해 아키텍처를 12-variant Decision Forest로 확장했다.
여기서는 12개의 고도로 특화된 에이전트(GPT-4o-mini 기반)가 각자 독립적으로 질문에 답한다.
그 다음 Aggregator LLM이 최종 판정자 역할을 맡는다.
이 Aggregator는 다수결, 도메인 신뢰도, 충돌 해결을 바탕으로 12개의 답변을 종합한다.
이 단일 합의형 모델 역시 97.20%라는 매우 높은 정확도를 달성했다.
[결과]
이 실험 아키텍처의 성능은 장기 AI 메모리에서 가능한 것의 기준 자체를 바꿔놓는다.
이 성취가 어느 정도 규모인지 이해할 수 있도록, 아래는 우리의 실험적 agentic flow가 원래의 프로덕션 엔진 및 업계 전반과 비교해 어떤 위치에 있는지를 보여준다.
이 시스템은 에이전트의 지연 시간에도 생각보다 큰 영향을 주지 않는다.
물론 이 부분은 우리가 계속 개선 중인 지점이기도 하다.
우리가 배운 점 & 다음 단계
프로덕션급 벤치마크에서 약 99% 정확도를 기록하는 시스템을 만들면서 몇 가지 중요한 엔지니어링 인사이트를 얻었다.
Agentic Retrieval이 Vector Search보다 낫다:
벡터 임베딩을 버리고 능동적 검색 에이전트로 전환한 것이 가장 큰 돌파구였다.
에이전트가 직접 문맥을 찾아 나서는 방식은, 시간에 따른 변경이나 업데이트 상황에서 기존 RAG가 빠지는 의미 유사도 함정을 제거해줬다.
병렬 처리가 핵심이다:
인제스트와 검색 작업을 여러 개의 전담 에이전트(읽기 3개, 검색 3개)로 분산한 것은 속도와 사실 추출의 세밀함을 모두 크게 향상시켰다.
각 에이전트가 특화된 초점을 갖고 추출할 수 있도록 했기 때문에 충돌도 줄일 수 있었다.
범용보다 특화가 낫다:
Counter나 Detail Extractor 같은 전용 전문 에이전트로 문맥을 라우팅하는 방식은, 단일 마스터 프롬프트 하나보다 훨씬 뛰어난 성능을 보였다.
이번 시스템은 핵심 Supermemory 엔진이 아니라 실험용 샌드박스에서 나온 것이기 때문에, 우리는 AI 커뮤니티가 이 아키텍처를 배우고 그 위에 더 발전시킬 수 있기를 바란다.
Forwarded from BHI
우리는 곧 이 실험적 agentic flow의 전체 코드를 오픈소스로 공개할 예정이다.
메모리는 계속 진화하는 과제이며, 이번 연구는 가능한 것의 상한선을 끌어올렸지만, 우리는 이미 이 순수 agent 기반 검색 기법을 어떻게 핵심 프로덕션 환경으로 옮길지 살펴보고 있다.
정확히 11일 뒤(4월 초), 우리는 이 새로운 에이전트 메모리 시스템에 대한 모든 것을 공개하고 오픈소스로 배포할 것이다.
이것은 공개 개발 방식으로 진행될 것이고, 모두가 볼 수 있는 일종의 스펙터클이 될 것이다.
우리는 이 과정을 즐기고 있다.
우리 GitHub를 확인해달라: https://github.com/supermemoryai
출시를 기대하면서 계속 지켜봐 달라 👀
에이전트 메모리는 이제 (아마도) 해결된 문제일까?
X (formerly Twitter)
Dhravya Shah (@DhravyaShah) on X
We broke the frontier in agent memory: Introducing ~99% SOTA memory system.
Forwarded from BHI
장기 기억력 측면에서 99% 수준의 성능을 냈다고 주장하는데, 저도 비슷하게 Agentic Memory/DataBase - 데이터/메모리를 Agent에 의해 관리하는 체계를 구축하고 있는데 이 방법이 획기적인 방법이라고 생각합니다.
일단, 정보가 계속 쌓이면 그게 지속적으로 활용될 수 있는 자산이 되어야하는 것에서 이러한 정보를 관리하고 사용하는 체계가 필요하다고 생각합니다.
질문 → 여러 에이전트가 저장된 기억을 다시 읽고 추론 → 시간축/업데이트 반영해서 필요한 정보만 뽑음
의 구조라고 합니다.
사실 저도 비슷한걸 하고 있었는데
AI가 병렬/분업으로 기억/DB를 관리하고
AI가 병렬 분업으로 다시 찾아오고 역할을 나누어서 처리한다라는 큰 틀은 비슷한데
저는 좀 수준이 낮아도 싼 모델들을 고의적으로 사용하지 않으려고 했는데
그냥 규칙에 따라서 똑같은 일을 반복하는 단순 반복 - 분업은 싼 AI에게 맡겨도 좋은 것 같다는 생각이 들었습니다.
일단, 정보가 계속 쌓이면 그게 지속적으로 활용될 수 있는 자산이 되어야하는 것에서 이러한 정보를 관리하고 사용하는 체계가 필요하다고 생각합니다.
질문 → 여러 에이전트가 저장된 기억을 다시 읽고 추론 → 시간축/업데이트 반영해서 필요한 정보만 뽑음
의 구조라고 합니다.
사실 저도 비슷한걸 하고 있었는데
AI가 병렬/분업으로 기억/DB를 관리하고
AI가 병렬 분업으로 다시 찾아오고 역할을 나누어서 처리한다라는 큰 틀은 비슷한데
저는 좀 수준이 낮아도 싼 모델들을 고의적으로 사용하지 않으려고 했는데
그냥 규칙에 따라서 똑같은 일을 반복하는 단순 반복 - 분업은 싼 AI에게 맡겨도 좋은 것 같다는 생각이 들었습니다.
Forwarded from BHI
이전에 트위터를 Agent가 활용하는 것에 대해서 이야기를 했었는데
아마 이해를 못했거나, 의도를 모르거나 하시는 분들도 있을 것 같다고 생각함.
제가 하려는 것이 무엇인지에 대해서 간략하게 설명
1. 기존의 체계는 '내가 트위터나 정보 창구를 통해서 정보를 획득해서 내가 기억해야하고, 적절하게 내가 적용하는 구조'
2. 하지만, AI Agent라는 것이 상용화되며 점점 흐름이 바뀜.
'내가 정보를 인터넷에서 보고 그 정보를 AI에게 제공하고, AI에게 내가 활용하라고 하면 AI는 그걸 활용함.'
3. 근본적인 의문 - 왜 우리는 사람단을 더 줄이지 않는가?, 사람에게 의존하지 않는 구조를 만들지 않는가?
> 왜 사람이 찾고, AI에게 제공하고, 쓰라고 명령해야하는 단계가 아직도 존속해야하는가?
4. 근본적 해결 : AI가 찾고, AI가 저장하고, AI가 알아서 쓰는 구조를 달성해야함.
5. 해결안 : AI에게 트위터를 실제 사람이 브라우징하는 듯이 브라우징을 매일같이 하도록 함 + Twitter API 대체용 Twikit이라는 도구를 제공. (정해진 개수 이상의 트윗(광고, 중복 제외)을 읽고, 저장할 것/가치 있는 유용한 것/활용해서 사용했을 때 가치있는 것 - 을 저장하고 이를 장기적으로 활용하도록 해야함.)
6. 사람이 정보를 찾고, 변화와 진보를 팔로업하는 것을 AI에게 위임하는 것임.
7. AI가 찾고, AI가 저장하고, AI가 활용하는 체계 - 자동으로 팔로업이 되는 구조를 만들어야한다는 것임.
8. 이제 사람은 변화를 따라가려고 노력하지 않아도 - AI가 알아서 시대의 흐름과 변화 - 혁신을 활용하는 시대가 될 수 있다는 것임.
9. 결과 : 사람은 니즈만 넣는다면, AI가 가진 맥가이버칼 같은 도구(AI가 수집해둔 활용할 수 있는 정보 자산, 도구들)를 활용해서 더 좋은 결과물을 만드는 것임.
10. 결과 2 : 이렇게 쌓인 자산들을 AI가 스스로 활용하여 인간의 지시없이도 엄청난 결과물을 만들어내는 것.
11. 하지만, 이러한 구조를 달성하기 위해서는 해결해야하는 문제가 있음.
그 문제는
그저 저장만 하고 쓰지 못하는 정보가 되는 것.
정보가 있어도 AI가 그것을 활용하지 않는 것.
그저 많은 정보로 침체되는 것.
이러한 것들이 있음. 이러한 문제를 어떻게 해결해야하는 지에 대한 실무적 고민과 해결법들이 고안되어야지만 확실한 혁신이 발생할 것으로 생각함.
아마 이해를 못했거나, 의도를 모르거나 하시는 분들도 있을 것 같다고 생각함.
제가 하려는 것이 무엇인지에 대해서 간략하게 설명
1. 기존의 체계는 '내가 트위터나 정보 창구를 통해서 정보를 획득해서 내가 기억해야하고, 적절하게 내가 적용하는 구조'
2. 하지만, AI Agent라는 것이 상용화되며 점점 흐름이 바뀜.
'내가 정보를 인터넷에서 보고 그 정보를 AI에게 제공하고, AI에게 내가 활용하라고 하면 AI는 그걸 활용함.'
3. 근본적인 의문 - 왜 우리는 사람단을 더 줄이지 않는가?, 사람에게 의존하지 않는 구조를 만들지 않는가?
> 왜 사람이 찾고, AI에게 제공하고, 쓰라고 명령해야하는 단계가 아직도 존속해야하는가?
4. 근본적 해결 : AI가 찾고, AI가 저장하고, AI가 알아서 쓰는 구조를 달성해야함.
5. 해결안 : AI에게 트위터를 실제 사람이 브라우징하는 듯이 브라우징을 매일같이 하도록 함 + Twitter API 대체용 Twikit이라는 도구를 제공. (정해진 개수 이상의 트윗(광고, 중복 제외)을 읽고, 저장할 것/가치 있는 유용한 것/활용해서 사용했을 때 가치있는 것 - 을 저장하고 이를 장기적으로 활용하도록 해야함.)
6. 사람이 정보를 찾고, 변화와 진보를 팔로업하는 것을 AI에게 위임하는 것임.
7. AI가 찾고, AI가 저장하고, AI가 활용하는 체계 - 자동으로 팔로업이 되는 구조를 만들어야한다는 것임.
8. 이제 사람은 변화를 따라가려고 노력하지 않아도 - AI가 알아서 시대의 흐름과 변화 - 혁신을 활용하는 시대가 될 수 있다는 것임.
9. 결과 : 사람은 니즈만 넣는다면, AI가 가진 맥가이버칼 같은 도구(AI가 수집해둔 활용할 수 있는 정보 자산, 도구들)를 활용해서 더 좋은 결과물을 만드는 것임.
10. 결과 2 : 이렇게 쌓인 자산들을 AI가 스스로 활용하여 인간의 지시없이도 엄청난 결과물을 만들어내는 것.
11. 하지만, 이러한 구조를 달성하기 위해서는 해결해야하는 문제가 있음.
그 문제는
그저 저장만 하고 쓰지 못하는 정보가 되는 것.
정보가 있어도 AI가 그것을 활용하지 않는 것.
그저 많은 정보로 침체되는 것.
이러한 것들이 있음. 이러한 문제를 어떻게 해결해야하는 지에 대한 실무적 고민과 해결법들이 고안되어야지만 확실한 혁신이 발생할 것으로 생각함.
Forwarded from BHI
또 추가로 말하자면, 그저 트위터에 있는 글만 보고 그걸 저장하고 쓴다거나 하는 구조로는 안 된다고 생각함.
그 글을 보고 관련된 글들을 찾아야하고 (이 과정에서 Twikit 같은 도구가 필요)
또, 외부에서 관련 내용을 리서치 해야하고, 실제 사실인지 - Larph나 과장이 아닌지 여부도 검증해야함. 유의미한지도 판단해야함. 어디에 쓸 지도 생각해두고 이렇게 생각해둔 방법 외에도 AI가 적용해서 활용할 수 있어야함.
또한, A에 대한 정보를 이미 저장해두었다면 - A에 대한 정보가 추가되어서 A+가 되었다면 그 정보를 어떻게 관리할지도 또 생각해봐야하는 부분임.
또한, 아주 AI의 핵심적인 부분인데
1. AI가 문제 - 실제 문제의 원인을 1차적인 사실과 증거 기반으로 탐구/실사 > 그 문제의 원인을 해결하는 방법을 고안/우회안을 고안
2. AI가 1차적 사실과 원리적 정보를 알고, 이를 이용하여 파생적 방법을 구축하고 시행.
이 2가지가 정말 핵심적이라고 생각함.
첫번째는 자주 설명했으니 패스하고, 2번째는 사실 이런 것임.
원리나, 방법, 사실만 안다면 - 그것을 활용해서 실제 도구나 다른 사람들이 구축해둔 것들을 그대로 구현할 수 있는 것임.
이렇게 되면, 남들에게 종속되거나 굳이 돈을 지불하거나, 위험을 사지 않아도 됨.
단순히 원리만 알아내거나 추론해내면 그걸 기반으로 구축해서 자기만의 것을 만들어서 쓰면 되기 때문임.
이게 엄청난 AI의 알파라고 생각함.
그 글을 보고 관련된 글들을 찾아야하고 (이 과정에서 Twikit 같은 도구가 필요)
또, 외부에서 관련 내용을 리서치 해야하고, 실제 사실인지 - Larph나 과장이 아닌지 여부도 검증해야함. 유의미한지도 판단해야함. 어디에 쓸 지도 생각해두고 이렇게 생각해둔 방법 외에도 AI가 적용해서 활용할 수 있어야함.
또한, A에 대한 정보를 이미 저장해두었다면 - A에 대한 정보가 추가되어서 A+가 되었다면 그 정보를 어떻게 관리할지도 또 생각해봐야하는 부분임.
또한, 아주 AI의 핵심적인 부분인데
1. AI가 문제 - 실제 문제의 원인을 1차적인 사실과 증거 기반으로 탐구/실사 > 그 문제의 원인을 해결하는 방법을 고안/우회안을 고안
2. AI가 1차적 사실과 원리적 정보를 알고, 이를 이용하여 파생적 방법을 구축하고 시행.
이 2가지가 정말 핵심적이라고 생각함.
첫번째는 자주 설명했으니 패스하고, 2번째는 사실 이런 것임.
원리나, 방법, 사실만 안다면 - 그것을 활용해서 실제 도구나 다른 사람들이 구축해둔 것들을 그대로 구현할 수 있는 것임.
이렇게 되면, 남들에게 종속되거나 굳이 돈을 지불하거나, 위험을 사지 않아도 됨.
단순히 원리만 알아내거나 추론해내면 그걸 기반으로 구축해서 자기만의 것을 만들어서 쓰면 되기 때문임.
이게 엄청난 AI의 알파라고 생각함.
Forwarded from BHI
AI Agent 활용 방법
많은 사람들이 단순하게 AI Agent에게
~해줘.
~가 문제네. 해결해.
이렇게 사용하는데, 이 방식은 틀렸을 수 있음.
개인적으로는 아래와 같은 방식으로 활용하고 있음.
개인적으로 중요하다고 생각하는 부분인데 '선택해야 할 사항'과 '훼손되면 안 되는 것'으로 고정하는 것이 꽤 중요하다고 생각함.
예를 들자면, 사용자 입장에서 돈이 드는 것을 최대한 줄이고 싶다거나, 혹은 방법들 중에 적용하면 안 되는 방법, 비효율적인 방법들이 있을 수 있음.
그런 것들은 ~한 방식으로 하라고 이야기를 해줘야함.
그걸 위해서는 검토나 최대한 선택지를 분해하는 과정이 필요하다고 생각함.
예를 들자면, 이미 LLM 구독제가 있는 상황에서 API 추가 과금을 해야하는 계획안을 구성할 수도 있고
돈이 안 드는 경로가 있음에도 불구하고 사용자는 과금을 꺼리는 성향인데도 불구하고 과금을 하는 방향을 선택할 수도 있음.
따라서, 비효율적 지점(비용 및 작동 효율성) 및 시스템 정합성에 맞지 않는 지점들을 찾아내는 것이 필요하다고 생각함.
사용자가 니즈와 상황을 구체화하고 방향성을 설정하는 능력이 기초자산이 되어가는 것 같음.
많은 사람들이 단순하게 AI Agent에게
~해줘.
~가 문제네. 해결해.
이렇게 사용하는데, 이 방식은 틀렸을 수 있음.
개인적으로는 아래와 같은 방식으로 활용하고 있음.
1. 문제 (ChatGPT Pro - Web)
1-1. 문제의 원인 가능성 파악 및 리스트업 (ChatGPT Pro - Web)
2. 문제 리스트에서 실제 문제가 무엇인지 실사 (AI Agent)
3. 확인된 문제를 받아서 제공 후 해결법 얻기 (ChatGPT Pro - Web)
4. 해결법을 AI Agent에게 제공 (AI Agent)
*이 과정에서 내가 바라지 않는 방법으로 해결할 수 있으므로 '선택해야 할 사항'을 구별하는 것이 필요
1. 요구 (ChatGPT Pro - Web)
2. 요구 사항 고정(훼손 불가 사항 고정) + 선택지 확인 및 사용자의 선택 (ChatGPT Pro - Web)
3. 구현을 위한 시스템 체크 사항 얻기 (ChatGPT Pro - Web)
4. 시스템 실사 (AI Agent)
5. 실사한 내용 제공 (ChatGPT Pro - Web)
6. 내용 기반 구현안 획득 (ChatGPT Pro - Web)
7. 구현안 AI Agent에게 제공 및 구현 (AI Agent)
개인적으로 중요하다고 생각하는 부분인데 '선택해야 할 사항'과 '훼손되면 안 되는 것'으로 고정하는 것이 꽤 중요하다고 생각함.
예를 들자면, 사용자 입장에서 돈이 드는 것을 최대한 줄이고 싶다거나, 혹은 방법들 중에 적용하면 안 되는 방법, 비효율적인 방법들이 있을 수 있음.
그런 것들은 ~한 방식으로 하라고 이야기를 해줘야함.
그걸 위해서는 검토나 최대한 선택지를 분해하는 과정이 필요하다고 생각함.
예를 들자면, 이미 LLM 구독제가 있는 상황에서 API 추가 과금을 해야하는 계획안을 구성할 수도 있고
돈이 안 드는 경로가 있음에도 불구하고 사용자는 과금을 꺼리는 성향인데도 불구하고 과금을 하는 방향을 선택할 수도 있음.
따라서, 비효율적 지점(비용 및 작동 효율성) 및 시스템 정합성에 맞지 않는 지점들을 찾아내는 것이 필요하다고 생각함.
사용자가 니즈와 상황을 구체화하고 방향성을 설정하는 능력이 기초자산이 되어가는 것 같음.
Forwarded from BHI
조금의 예시를 들자면,
Agent가 문서를 받지 못하는 오류가 있음 (문제발생)
해당 문제가 발생하는 원인으로 추정되는 것들을 예측 및 리스트업 (문제의 원인을 예측)
문제의 원인이 실제 맞는지 여부를 에이전트가 파악 (문제의 원인들 중 어떠한 것이 실제 원인인지 파악)
파악한 문제를 해결하기 위한 방법을 고안 (해결법 고안)
해결법에 따라서 시행하여 해결 (해결)
이런 과정인데 이 과정 속에서 다양한 문제가 발생함.
그냥 에이전트에게 문제를 던져주고 해결하라고 하는 경우에 발생하는 문제나
니즈와 조건을 제대로 걸지 않으면 사용자의 의도와는 다르게 해결하거나 비가시적 조건을 충족하지 않는 문제가 발생할 수 있음.
그냥 단순하게 코드만 고치면 되는 일을 Google Drive를 연결해서 그쪽으로 업로드하고 공유하는 URL을 생성해서 에이전트에게 제공하는 방식을 사용하자. 라고 그냥 에이전트가 자의적으로 판단할 수 있음. 혹은 이 방법이 최선이거나 레거시한 방법이기에 이 방법으로 하는 것이 안정적이다. 라고 판단하여 이 방법을 추천하거나, 이 방법으로 진행할 수도 있음. (물론 이 방법은 레거시한 방법도 아니고, 안정적인 방법도 아님. - 예시임)
그 과정에서 발생하는 추가적인 문제가 있을 수 있음. 예를 들면 - Google Drive의 용량이 부족해지거나, 또 Google Drive를 위해서 과금이 필요하거나, 이 과정에서 더 추가적인 문제가 발생하거나, 그냥 작동의 과정에서 비효율적이거나 등등....
즉, 이 과정에서 '나는 추가 과금은 피하고 싶어. [조건]'을 추가해야 정확한 방향을 설정하고 그 방향으로 계획을 짜고 구현한다는 것임...
그리고, 쉽게 AI가 하는 말을 믿으면 안 됨.
트위터 API를 이용해서 트위터에 있는 정보를 긁어와야합니다. 이 과정에서 비용은 필연적입니다.
이 말에 설득당하면 안 됨.
트위터의 정보를 긁어와야하는데, 비용이 드는 것은 절대 안 돼. 와 같은 방법으로 조건과 방향을 설정하면
비용이 들지 않는 트위터의 정보를 긁어오는 방식을 찾아냄.
그 방식들의 문제를 체크하라고 하고 - 가장 문제가 없는 방식을 찾다보면 Twikit 같은 것들을 찾게되고, 그것을 활용하면 쉽게 해결된다고 생각함.
하지만, 대부분의 사람들은 조건과 방향을 제대로 설정하지 않고
트위터의 정보를 긁어올 수 있게 해줘.
와 같은 프롬프트를 통해서,
트위터 API를 이용하십시오.
라는 결론에 도달하고, 그 방법으로 비효율이 발생하는 상황에 있다고 생각함.
즉, 결론적으로 해결책은 비가시적 조건을 가시적으로 바꾸고, 정확한 필요와 요구 사항을 명시하여 정확한 방향을 설정하는 것이라고 생각함. AI는 보수적이고 통계적, 안정적이고 대다수의 사람들이 하는 행동을 모방하려하는 경향이 있기에 개인화(필요, 요구사항 명시, 사용자 상황 컨텍스트 삽입)이 되지 않는다면, 사용자의 효용의 체감은 떨어질 수 밖에 없다고 생각함.
Agent가 문서를 받지 못하는 오류가 있음 (문제발생)
해당 문제가 발생하는 원인으로 추정되는 것들을 예측 및 리스트업 (문제의 원인을 예측)
문제의 원인이 실제 맞는지 여부를 에이전트가 파악 (문제의 원인들 중 어떠한 것이 실제 원인인지 파악)
파악한 문제를 해결하기 위한 방법을 고안 (해결법 고안)
해결법에 따라서 시행하여 해결 (해결)
이런 과정인데 이 과정 속에서 다양한 문제가 발생함.
그냥 에이전트에게 문제를 던져주고 해결하라고 하는 경우에 발생하는 문제나
니즈와 조건을 제대로 걸지 않으면 사용자의 의도와는 다르게 해결하거나 비가시적 조건을 충족하지 않는 문제가 발생할 수 있음.
그냥 단순하게 코드만 고치면 되는 일을 Google Drive를 연결해서 그쪽으로 업로드하고 공유하는 URL을 생성해서 에이전트에게 제공하는 방식을 사용하자. 라고 그냥 에이전트가 자의적으로 판단할 수 있음. 혹은 이 방법이 최선이거나 레거시한 방법이기에 이 방법으로 하는 것이 안정적이다. 라고 판단하여 이 방법을 추천하거나, 이 방법으로 진행할 수도 있음. (물론 이 방법은 레거시한 방법도 아니고, 안정적인 방법도 아님. - 예시임)
그 과정에서 발생하는 추가적인 문제가 있을 수 있음. 예를 들면 - Google Drive의 용량이 부족해지거나, 또 Google Drive를 위해서 과금이 필요하거나, 이 과정에서 더 추가적인 문제가 발생하거나, 그냥 작동의 과정에서 비효율적이거나 등등....
즉, 이 과정에서 '나는 추가 과금은 피하고 싶어. [조건]'을 추가해야 정확한 방향을 설정하고 그 방향으로 계획을 짜고 구현한다는 것임...
그리고, 쉽게 AI가 하는 말을 믿으면 안 됨.
트위터 API를 이용해서 트위터에 있는 정보를 긁어와야합니다. 이 과정에서 비용은 필연적입니다.
이 말에 설득당하면 안 됨.
트위터의 정보를 긁어와야하는데, 비용이 드는 것은 절대 안 돼. 와 같은 방법으로 조건과 방향을 설정하면
비용이 들지 않는 트위터의 정보를 긁어오는 방식을 찾아냄.
그 방식들의 문제를 체크하라고 하고 - 가장 문제가 없는 방식을 찾다보면 Twikit 같은 것들을 찾게되고, 그것을 활용하면 쉽게 해결된다고 생각함.
하지만, 대부분의 사람들은 조건과 방향을 제대로 설정하지 않고
트위터의 정보를 긁어올 수 있게 해줘.
와 같은 프롬프트를 통해서,
트위터 API를 이용하십시오.
라는 결론에 도달하고, 그 방법으로 비효율이 발생하는 상황에 있다고 생각함.
즉, 결론적으로 해결책은 비가시적 조건을 가시적으로 바꾸고, 정확한 필요와 요구 사항을 명시하여 정확한 방향을 설정하는 것이라고 생각함. AI는 보수적이고 통계적, 안정적이고 대다수의 사람들이 하는 행동을 모방하려하는 경향이 있기에 개인화(필요, 요구사항 명시, 사용자 상황 컨텍스트 삽입)이 되지 않는다면, 사용자의 효용의 체감은 떨어질 수 밖에 없다고 생각함.
Forwarded from 먼슬리 오리(Monthly Ori)
이 계정은 그러니까
만든지 1년만에 85700개의 HYPE 관련 포스팅을 했다고?
85700/365 = 234.xx
리트윗이나 댓글 합쳐도, 사람이 매일 200개 넘게 올리는게 말이 되는건가
뭔가에 미치려면 저렇게 해야하는구나
반성합니다
https://x.com/HYPEconomist
만든지 1년만에 85700개의 HYPE 관련 포스팅을 했다고?
85700/365 = 234.xx
리트윗이나 댓글 합쳐도, 사람이 매일 200개 넘게 올리는게 말이 되는건가
뭔가에 미치려면 저렇게 해야하는구나
반성합니다
https://x.com/HYPEconomist
Forwarded from 엄브렐라리서치 Anakin의 투자노트
토큰과 메모리
1.
처음 ChatGPT가 나왔을 때, 모두가 놀랐지만 동시에 할루시네이션에 대한 비판도 거셌음. 대화는 되었지만 정확도가 낮았기 때문. 그 이유는 그 당시 모델이 '사전학습(Pre-training)' 중심이었기 때문
사전학습은, 인터넷에 있는 모든 데이터를 입력받아 기본 지식을 습득하지만, '뇌'가 빈 상태. 그렇기 때문에 깊은 생각이 어렵고 정보의 적시성도 떨어지는 상태
2.
사전학습 다음으로 함께 진행된 것은 '사후학습(Post-Training)'. 사후학습은 모델이 알고 있는 지식을 쓸모 있게 만들어 줌. 모델에게 생각하는 방법을 가르치는 단계
사전학습만 수행하게 되면, '삼성전자,SK하이닉스에 대해 알려줘'라고 했을 때 인터넷 상에서 존재하는 꽤나 정확한 답변을 제공해줄 수 있음
그러나, '토큰 수요가 폭증하는 사이클에서 메모리 압축기술(토큰당 메모리 수요)이 메모리 전체 수요 성장 기울기를 감소시킬 수 있어?'라는 질문에는 답변하지 못함. 스스로 생각하기 어렵기 때문. 그러나 사후학습은 이를 가능케 할 수 있음. 모델 스스로 생각할 수 있게 만들어주기 때문
3.
그 다음 등장한게 '테스트 타임 스케일링(Test-time Scaling)'. 여기서 딥시크가 등장하게 되었음. 스스로 생각하는 모든 과정을 공개하면서 모델이 '곧바로' 답을 뱉지 않고, 문제를 시간을 갖고 스스로 풀어보고 생각하는 과정을 거치게 됨
딥시크는 모델의 생각 시간을 늘려서 답변의 정확도를 높이는 방식으로 각광받게 되었음. 당시 딥시크는 GPU 요구량을 크게 줄였으나 성능이 개선되었다고 발표했으나(실제로는 더 사용), 결과적으로는 지금 딥시크의 입지는 그 때보다는 낮은 수준
마치 지금 메모리 압축을 얘기하는 상황과도 유사. 결과적으로 증가하는 토큰을 처리하기 위한 효율성 개선이 수요 감소로 이어지지 않는다는 것. 결국 모델의 성능 개선은 (1) 압도적인 AI 인프라와 (2) 함께 진행되는 효율성 개선(이건 SW, HW 모두)에서 이뤄진다는 것
4.
딥시크 방식은 또한 '속도'의 문제가 존재했음. 한정된 HW에서 계속되는 '검산'과 '숙고'는 토큰을 더 많이 발생시켰고, 이를 처리하기 위한 속도는 당연히 늦어졌음
이를 해결하기 위해 등장한 개념이 'MoE(Mixture of Experts)'였음. 모델의 뉴런 파라미터 집합을 여러 전문가 그룹으로 나누는 것. 모델 전체의 크기는 엄청 커질 수밖에 없지만, 거기서 추론에 사용하는 유효 파라미터를 줄이는 것
모델이 수조 파라미터 규모가 되더라도, 유효 파라미터는 수백억개 수준으로 축소시킬 수 있고, 이 덕분에 훨씬 레이턴시를 줄일 수 있게 되었음. 선택적으로 계산하기 때문에 더 높은 지능을 제공
더 효율적으로 코드를 생성하고, 출력을 만들고, 똑똑해지는 방식. 결국 이것도 '효율성 개선' 아닐까? => 하지만 HW의 수요는 전혀 줄어들지 않았다는 것
5.
이는 LPU SRAM, CPO나 1.6T같은 통신기술, NV Link 등 모두 마찬가지. 어찌보면 HW단에서 효율화에 더 노력하고 있음. 더 많은 토큰을 생성해야되기 때문
구글 같은 CSP만 노력하는게 아니라, 사실 HW업체들이 더 많이 노력하고 있다는 것. LPU는 결국 토큰을 만들어내는 워크로드 측면에서 저지연을 담당하는 영역에서 급격한 효율을 발생시킴. 여전히 디코드 영역의 메모리 바운드는 깨지지 않음. 즉, 워크로드의 차이
6.
엔비디아의 Dynamo 기술은 HW 업체가 오히려 더 노력하고 있는 것을 보여주고 있음. Dynamo 기술은 첫 입력 토큰을 생성하는 프리필(prefill) 단계와 출력 토큰을 계속 만드는 디코드(decode) 단계를 구분하여 AI DC 전체에서 KV 캐시를 효율적으로 관리하기 위해 엔비디아가 만든 기술
첫 입력 토큰을 생성하기 위해 사용자가 질문한 내용을 처리하는 문맥 처리를 담당하는 프리필 단계의 GPU와, 이를 받아서 토큰을 계속 생성해내는 GPU를 구분하는 것. 결국 이것도 '토큰 생성을 위한 효율성 증대'의 일환. 엔비디아에 따르면, 이 Dynamo 기술을 통해 GPU의 처리량이 7배가 증가했다고 발표
7.
다음 시대는 '멀티에이젼트', '에이젼트 스케일링'. AI 에이젼트들끼리 대화하면서 더 최적의 답변을 찾아내는 것. 앤트로픽은 멀티에이전트 시스템에서 토큰 생성 수요가 15배 증가한다고 언급(특정 영역에서)
AI들끼리 대화가 너무 빠르기 때문. 1500토큰/초 수준으로 출력하는 시대가 도래하게 되면, 하루~일주일 걸리는 질의를 1~2시간만에 처리할 수 있게 되는 것. 더 거대한 모델을 돌려야 하고, 에이젼트간의 상호작용도 매우 빨라야 하는 시대로 도래
똑똑한 한 명의 인간은 AGI가 될 수 없음. 아인슈타인은 가장 똑똑한 인류라고 불리지만, 아인슈타인이 엘리베이터를 고치는 방법을 알거나 주식에 일가견이 있거나 국가를 운영하는 법을 알 수가 없음. 결국 AGI는 무수히 똑똑한 AI 에이젼트들이 융합할 때 도달할 수 있는 영역
8.
메모리 측면에서, 추론 디코드 영역은 '메모리 바운드'라고 부름. 메모리에 묶여있다는 것. GPU 연산량이 아무리 좋아도 메모리 대역폭과 배치(batch, 동시에 처리할 수 있는 작업)가 증가하지 못하면 오히려 GPU가 노는 현상이 발생될 정도. 완전히 메모리 의존 영역
디코드는 매 스텝마다 토큰을 생성하고 다음 토큰을 생성하는 과정을 거치는데, 이 때 다음 토큰을 생성하기 위해 KV 캐시를 활용. KV 캐시는 이전 토큰들에 대한 Key/value 벡터 상태, 즉 이전 토큰들의 상태를 저장해놓는 저장소 역할. 그렇게 되면 다음 토큰을 만들 때 문맥을 처음부터 다시 읽는게 아니라, KV캐시만 읽어도 다음 토큰을 더 빠르게 생성할 수 있게 됨
9.
결국 토큰 - 추론 - 디코드 - KV캐시라는 구조가 단단하게 유지되면서, LLM들이 사전학습->사후학습->테스트 타임 스케일링->MoE->에이젼트 스케일링으로 변화되면서 더 많은 토큰을 생성해낼수록, 메모리의 요구량은 계속 기하급수적으로 증가하고 있다는 것
이 과정에서 HBM에만 한정된 KV캐시 의존도를 분산하기 위해 일반 서버용 DRAM이나, 콜드 데이터 저장을 위한 HDD, SSD, 나아가 HBF까지 필요해지면서 메모리 하이어라키 계층 구조가 전방위적으로 수혜를 받는 것. 단순히 HBM에서 만들어지는 공급 제약이 미치는 영향 뿐만 아니라, AI 수요가 전체적인 메모리 수요에 도움을 주고 있음
10.
한편 HBM에서는 HBM4부터 로직다이의 중요성이 높아지고 있음. 이는 IO 복잡도가 급격히 증가하고, GPU/CPU 같은 연산처리에서 담당하던 기능을 로직 다이 안으로 가져올 수 있게 되었기 때문. 이에 따라, 4e부터는 커스텀 HBM 방식으로, 코어다이는 표준화가 되더라도 로직다이는 업체별로 맞춤형 설계가 될 수 있음
현재 HBM4에선 코어다이에서 삼성전자가 1c, SK하이닉스가 1b 공정을 적용 중인 것으로 알려짐. 로직다이에서는 삼성전자가 삼성파운드리 4nm 공정, SK하이닉스가 TSMC 12나노대 공정을 적용 중인 것으로 알려짐 (언론보도)
그런데 HBM4e부터는 코어다이에서 두 기업 모두 1c 공정, 로직다이에서는 SK하이닉스가 TSMC 3nm 공정을 검토 중이라는 언론보도가 있었음. HBM4에서 12nm를 적용했다면, 4e에선 3nm로 급격하게 성능을 개선시키는 것. 이는 HBM 공정 경쟁이 4e부터는 양상이 또다시 변화될 수 있음을 암시
+
큰 틀에서, 조금 과장하자면 AI와 토큰은 산업혁명 시대 전기의 탄생과 유사하다고 생각. 전기(토큰)을 가지고 할 수 있는게 너무 많아질 수 있는 시대에서, 전기가 발명되기 이전의 시대로 돌아갈 수 없음
전기를 만들기 위해 당연히 공장이 필요하고, 전기를 더 효율적으로 생성해낼 수 있는 기술(효율화)도 당연히 필요할 것
그러나 그게 전기의 수요를 감소시키거나, 전기를 만들어내기 위한 인프라의 감소로 이어지진 않았음. 왜냐하면 전기의 수요 증가량(토큰의 증가량)이 훨씬 더 크기 때문
1.
처음 ChatGPT가 나왔을 때, 모두가 놀랐지만 동시에 할루시네이션에 대한 비판도 거셌음. 대화는 되었지만 정확도가 낮았기 때문. 그 이유는 그 당시 모델이 '사전학습(Pre-training)' 중심이었기 때문
사전학습은, 인터넷에 있는 모든 데이터를 입력받아 기본 지식을 습득하지만, '뇌'가 빈 상태. 그렇기 때문에 깊은 생각이 어렵고 정보의 적시성도 떨어지는 상태
2.
사전학습 다음으로 함께 진행된 것은 '사후학습(Post-Training)'. 사후학습은 모델이 알고 있는 지식을 쓸모 있게 만들어 줌. 모델에게 생각하는 방법을 가르치는 단계
사전학습만 수행하게 되면, '삼성전자,SK하이닉스에 대해 알려줘'라고 했을 때 인터넷 상에서 존재하는 꽤나 정확한 답변을 제공해줄 수 있음
그러나, '토큰 수요가 폭증하는 사이클에서 메모리 압축기술(토큰당 메모리 수요)이 메모리 전체 수요 성장 기울기를 감소시킬 수 있어?'라는 질문에는 답변하지 못함. 스스로 생각하기 어렵기 때문. 그러나 사후학습은 이를 가능케 할 수 있음. 모델 스스로 생각할 수 있게 만들어주기 때문
3.
그 다음 등장한게 '테스트 타임 스케일링(Test-time Scaling)'. 여기서 딥시크가 등장하게 되었음. 스스로 생각하는 모든 과정을 공개하면서 모델이 '곧바로' 답을 뱉지 않고, 문제를 시간을 갖고 스스로 풀어보고 생각하는 과정을 거치게 됨
딥시크는 모델의 생각 시간을 늘려서 답변의 정확도를 높이는 방식으로 각광받게 되었음. 당시 딥시크는 GPU 요구량을 크게 줄였으나 성능이 개선되었다고 발표했으나(실제로는 더 사용), 결과적으로는 지금 딥시크의 입지는 그 때보다는 낮은 수준
마치 지금 메모리 압축을 얘기하는 상황과도 유사. 결과적으로 증가하는 토큰을 처리하기 위한 효율성 개선이 수요 감소로 이어지지 않는다는 것. 결국 모델의 성능 개선은 (1) 압도적인 AI 인프라와 (2) 함께 진행되는 효율성 개선(이건 SW, HW 모두)에서 이뤄진다는 것
4.
딥시크 방식은 또한 '속도'의 문제가 존재했음. 한정된 HW에서 계속되는 '검산'과 '숙고'는 토큰을 더 많이 발생시켰고, 이를 처리하기 위한 속도는 당연히 늦어졌음
이를 해결하기 위해 등장한 개념이 'MoE(Mixture of Experts)'였음. 모델의 뉴런 파라미터 집합을 여러 전문가 그룹으로 나누는 것. 모델 전체의 크기는 엄청 커질 수밖에 없지만, 거기서 추론에 사용하는 유효 파라미터를 줄이는 것
모델이 수조 파라미터 규모가 되더라도, 유효 파라미터는 수백억개 수준으로 축소시킬 수 있고, 이 덕분에 훨씬 레이턴시를 줄일 수 있게 되었음. 선택적으로 계산하기 때문에 더 높은 지능을 제공
더 효율적으로 코드를 생성하고, 출력을 만들고, 똑똑해지는 방식. 결국 이것도 '효율성 개선' 아닐까? => 하지만 HW의 수요는 전혀 줄어들지 않았다는 것
5.
이는 LPU SRAM, CPO나 1.6T같은 통신기술, NV Link 등 모두 마찬가지. 어찌보면 HW단에서 효율화에 더 노력하고 있음. 더 많은 토큰을 생성해야되기 때문
구글 같은 CSP만 노력하는게 아니라, 사실 HW업체들이 더 많이 노력하고 있다는 것. LPU는 결국 토큰을 만들어내는 워크로드 측면에서 저지연을 담당하는 영역에서 급격한 효율을 발생시킴. 여전히 디코드 영역의 메모리 바운드는 깨지지 않음. 즉, 워크로드의 차이
6.
엔비디아의 Dynamo 기술은 HW 업체가 오히려 더 노력하고 있는 것을 보여주고 있음. Dynamo 기술은 첫 입력 토큰을 생성하는 프리필(prefill) 단계와 출력 토큰을 계속 만드는 디코드(decode) 단계를 구분하여 AI DC 전체에서 KV 캐시를 효율적으로 관리하기 위해 엔비디아가 만든 기술
첫 입력 토큰을 생성하기 위해 사용자가 질문한 내용을 처리하는 문맥 처리를 담당하는 프리필 단계의 GPU와, 이를 받아서 토큰을 계속 생성해내는 GPU를 구분하는 것. 결국 이것도 '토큰 생성을 위한 효율성 증대'의 일환. 엔비디아에 따르면, 이 Dynamo 기술을 통해 GPU의 처리량이 7배가 증가했다고 발표
7.
다음 시대는 '멀티에이젼트', '에이젼트 스케일링'. AI 에이젼트들끼리 대화하면서 더 최적의 답변을 찾아내는 것. 앤트로픽은 멀티에이전트 시스템에서 토큰 생성 수요가 15배 증가한다고 언급(특정 영역에서)
AI들끼리 대화가 너무 빠르기 때문. 1500토큰/초 수준으로 출력하는 시대가 도래하게 되면, 하루~일주일 걸리는 질의를 1~2시간만에 처리할 수 있게 되는 것. 더 거대한 모델을 돌려야 하고, 에이젼트간의 상호작용도 매우 빨라야 하는 시대로 도래
똑똑한 한 명의 인간은 AGI가 될 수 없음. 아인슈타인은 가장 똑똑한 인류라고 불리지만, 아인슈타인이 엘리베이터를 고치는 방법을 알거나 주식에 일가견이 있거나 국가를 운영하는 법을 알 수가 없음. 결국 AGI는 무수히 똑똑한 AI 에이젼트들이 융합할 때 도달할 수 있는 영역
8.
메모리 측면에서, 추론 디코드 영역은 '메모리 바운드'라고 부름. 메모리에 묶여있다는 것. GPU 연산량이 아무리 좋아도 메모리 대역폭과 배치(batch, 동시에 처리할 수 있는 작업)가 증가하지 못하면 오히려 GPU가 노는 현상이 발생될 정도. 완전히 메모리 의존 영역
디코드는 매 스텝마다 토큰을 생성하고 다음 토큰을 생성하는 과정을 거치는데, 이 때 다음 토큰을 생성하기 위해 KV 캐시를 활용. KV 캐시는 이전 토큰들에 대한 Key/value 벡터 상태, 즉 이전 토큰들의 상태를 저장해놓는 저장소 역할. 그렇게 되면 다음 토큰을 만들 때 문맥을 처음부터 다시 읽는게 아니라, KV캐시만 읽어도 다음 토큰을 더 빠르게 생성할 수 있게 됨
9.
결국 토큰 - 추론 - 디코드 - KV캐시라는 구조가 단단하게 유지되면서, LLM들이 사전학습->사후학습->테스트 타임 스케일링->MoE->에이젼트 스케일링으로 변화되면서 더 많은 토큰을 생성해낼수록, 메모리의 요구량은 계속 기하급수적으로 증가하고 있다는 것
이 과정에서 HBM에만 한정된 KV캐시 의존도를 분산하기 위해 일반 서버용 DRAM이나, 콜드 데이터 저장을 위한 HDD, SSD, 나아가 HBF까지 필요해지면서 메모리 하이어라키 계층 구조가 전방위적으로 수혜를 받는 것. 단순히 HBM에서 만들어지는 공급 제약이 미치는 영향 뿐만 아니라, AI 수요가 전체적인 메모리 수요에 도움을 주고 있음
10.
한편 HBM에서는 HBM4부터 로직다이의 중요성이 높아지고 있음. 이는 IO 복잡도가 급격히 증가하고, GPU/CPU 같은 연산처리에서 담당하던 기능을 로직 다이 안으로 가져올 수 있게 되었기 때문. 이에 따라, 4e부터는 커스텀 HBM 방식으로, 코어다이는 표준화가 되더라도 로직다이는 업체별로 맞춤형 설계가 될 수 있음
현재 HBM4에선 코어다이에서 삼성전자가 1c, SK하이닉스가 1b 공정을 적용 중인 것으로 알려짐. 로직다이에서는 삼성전자가 삼성파운드리 4nm 공정, SK하이닉스가 TSMC 12나노대 공정을 적용 중인 것으로 알려짐 (언론보도)
그런데 HBM4e부터는 코어다이에서 두 기업 모두 1c 공정, 로직다이에서는 SK하이닉스가 TSMC 3nm 공정을 검토 중이라는 언론보도가 있었음. HBM4에서 12nm를 적용했다면, 4e에선 3nm로 급격하게 성능을 개선시키는 것. 이는 HBM 공정 경쟁이 4e부터는 양상이 또다시 변화될 수 있음을 암시
+
큰 틀에서, 조금 과장하자면 AI와 토큰은 산업혁명 시대 전기의 탄생과 유사하다고 생각. 전기(토큰)을 가지고 할 수 있는게 너무 많아질 수 있는 시대에서, 전기가 발명되기 이전의 시대로 돌아갈 수 없음
전기를 만들기 위해 당연히 공장이 필요하고, 전기를 더 효율적으로 생성해낼 수 있는 기술(효율화)도 당연히 필요할 것
그러나 그게 전기의 수요를 감소시키거나, 전기를 만들어내기 위한 인프라의 감소로 이어지진 않았음. 왜냐하면 전기의 수요 증가량(토큰의 증가량)이 훨씬 더 크기 때문
BHI
AI Agentic System 설계 아키텍쳐.docx
AI Agentic System에서 필요한 것들, 어떻게 구현할지, 어떤 문제가 있는지를 최대한 적어낸 문서입니다.
Forwarded from AI MASTERS
This media is not supported in your browser
VIEW IN TELEGRAM
Suno V5.5 업데이트 - 당신의 목소리로 생성하세요!
음악 생성AI 모델중 정말 원탑으로 달리고 있는 SUNO 가 이번에 버전 업데이트를 진행했습니다. 단순 음악적 다향성 보다 이젠 유저의 목소리와 취향을 담은 모델중 하나입니다.
다양한 음악적 지식이 없어도, 이제는 그 generic 한 목소리를 넘어서, 자신의 목소리를 녹음하고, 자신의 목소리로 음악을 생성할수 있습니다!
지금 Suno 에서 생성해보세요!
음악 생성AI 모델중 정말 원탑으로 달리고 있는 SUNO 가 이번에 버전 업데이트를 진행했습니다. 단순 음악적 다향성 보다 이젠 유저의 목소리와 취향을 담은 모델중 하나입니다.
다양한 음악적 지식이 없어도, 이제는 그 generic 한 목소리를 넘어서, 자신의 목소리를 녹음하고, 자신의 목소리로 음악을 생성할수 있습니다!
지금 Suno 에서 생성해보세요!
Forwarded from AI MASTERS
목소리는 총 2~3단계로 들어갑니다.
1. 자신의 목소리를 자연스럽게 녹음을 10초 이상 해야합니다.
2. 노래를 부르는것도 30초 이상 있어야 합니다.
3. 목소리 KYC 를 진행해야합니다.
그렇게 진행후, 자신의 모델이 나옵니당
참고사항
• 녹음을 한 장소 / 마이크 퀄리티 등등이 모델의 퀄리티를 결정합니다.
• 녹음하고 다시 진행 가능.
• 그냥 업로드도 되지만, KYC 부분은 필수입니다.
1. 자신의 목소리를 자연스럽게 녹음을 10초 이상 해야합니다.
2. 노래를 부르는것도 30초 이상 있어야 합니다.
3. 목소리 KYC 를 진행해야합니다.
그렇게 진행후, 자신의 모델이 나옵니당
참고사항
• 녹음을 한 장소 / 마이크 퀄리티 등등이 모델의 퀄리티를 결정합니다.
• 녹음하고 다시 진행 가능.
• 그냥 업로드도 되지만, KYC 부분은 필수입니다.
Forwarded from AI MASTERS
This media is not supported in your browser
VIEW IN TELEGRAM
[ Google Drive에서 공개한 스캔 기능 ]
구글 드라이브에 AI 문서 스캐너 베타기능이 도입됐어요👀👀
페이지를 넘기기만 하면 폰 카메라가 실시간으로 촬영하고 스캔해주는데 기존에 몇 분 걸리던 작업이 몇 초만에 끝났다는 후기도 있습니다🚀🚀
지금 Drive 들어가면 써볼 수 있으니까 얼른 써보시는거 추천드립니다🙏
스캔속도 진짜 미쳤네요👊
👉 원문 보기 👈
구글 드라이브에 AI 문서 스캐너 베타기능이 도입됐어요👀👀
페이지를 넘기기만 하면 폰 카메라가 실시간으로 촬영하고 스캔해주는데 기존에 몇 분 걸리던 작업이 몇 초만에 끝났다는 후기도 있습니다🚀🚀
지금 Drive 들어가면 써볼 수 있으니까 얼른 써보시는거 추천드립니다🙏
스캔속도 진짜 미쳤네요👊
👉 원문 보기 👈
Forwarded from 인포마켓 infomarket
This media is not supported in your browser
VIEW IN TELEGRAM
이제 여러분의 헤드폰이 70개 이상의 언어를 지원하는 개인 번역기가 되었습니다.
구글 번역(Google Translate)의 '헤드폰 실시간 번역(Live translate)' 기능이 iOS에 공식 출시되었습니다. 또한, @Android 및 iOS 사용자 모두를 위해 전 세계 더 많은 국가로 이 기능을 확대 지원합니다.
기능을 사용해 보려면 번역 앱을 열고 "실시간 번역(Live translate)"을 탭한 다음 헤드폰을 연결하세요.
구글 번역(Google Translate)의 '헤드폰 실시간 번역(Live translate)' 기능이 iOS에 공식 출시되었습니다. 또한, @Android 및 iOS 사용자 모두를 위해 전 세계 더 많은 국가로 이 기능을 확대 지원합니다.
기능을 사용해 보려면 번역 앱을 열고 "실시간 번역(Live translate)"을 탭한 다음 헤드폰을 연결하세요.
Forwarded from AI MASTERS
This media is not supported in your browser
VIEW IN TELEGRAM
[ 알리바바의 신개념 실시간 영상 생성 모델 ]
지난주에 열린 Modelscope 개발자 컨퍼런스에서 알리바바가 Wan을 이용한 다양한 기능을 공개했습니다👍👍
그 중 가장 많은 인기를 얻었던 WanToFight를 정리해볼게요😎
✅ WanToFight 간략 정리
- 화면에는 킹오브파이터즈97이 예시로 나오는 중
- 실시간 영상 생성 기술인데 텍스트가 아닌 이용자가 키보드로 입력하는 정보를 토대로 생성하는 것임
- 즉, 캐릭터가 움직이는 모습은 실제 게임이 구동된 것이 아니라 생성형 AI로 만들어진 영상
이런 기술이라면 앞으로 개발 과정 없이 게임을 만들 수 있지 않을까?🔥🔥
그나저나 방장은 KOF 97이랑 99로 동네에서 이름좀 날렸는데 쫌 치시는분?🤜
👉 원문 보기 👈
지난주에 열린 Modelscope 개발자 컨퍼런스에서 알리바바가 Wan을 이용한 다양한 기능을 공개했습니다👍👍
그 중 가장 많은 인기를 얻었던 WanToFight를 정리해볼게요😎
✅ WanToFight 간략 정리
- 화면에는 킹오브파이터즈97이 예시로 나오는 중
- 실시간 영상 생성 기술인데 텍스트가 아닌 이용자가 키보드로 입력하는 정보를 토대로 생성하는 것임
- 즉, 캐릭터가 움직이는 모습은 실제 게임이 구동된 것이 아니라 생성형 AI로 만들어진 영상
이런 기술이라면 앞으로 개발 과정 없이 게임을 만들 수 있지 않을까?🔥🔥
그나저나 방장은 KOF 97이랑 99로 동네에서 이름좀 날렸는데 쫌 치시는분?🤜
👉 원문 보기 👈
Forwarded from BHI
코드와 AI의 핵심적인 차이 : 규칙 실행과 의미 추론
많은 사람들은 코드와 AI를 완전히 다른 존재처럼 생각한다. 그러나 흥미로운 점은 AI도 결국 코드 위에서 구현된다는 사실이다. 모델을 학습시키는 과정, 입력을 처리하는 로직, 결과를 검증하고 서비스에 연결하는 시스템, 그리고 실제 서비스 환경에서 동작하도록 운영하는 모든 구조는 결국 코드로 작성된다. 그럼에도 우리는 왜 AI를 기존 코드와 다르게 느낄까. 핵심은 무엇으로 만들어졌는가에 있지 않다. 더 중요한 것은 어떤 방식으로 문제를 해결하는가에 있다.
명시적 규칙 기반 코드는 사람이 정의한 규칙 범위 안에서 매우 정확하게 동작한다. 세금 계산, 할인 정책 적용, 접근 권한 통제, 파일 형식 검증, 결제 승인 절차처럼 규칙이 명확하고 예외가 제한적인 문제에서는 전통적인 코드가 가장 강력하다. 입력과 조건이 분명할수록 코드는 빠르고 안정적이며, 같은 조건에서 같은 결과를 재현하는 능력도 뛰어나다. 이러한 특성은 신뢰성과 통제 가능성이 중요한 시스템에서 매우 큰 장점이 된다.
하지만 현실의 많은 문제는 그렇게 닫혀 있지 않다. 사람의 언어는 늘 다양하게 표현되고, 같은 의도도 다른 문장과 다른 맥락 속에서 나타난다. 실제 업무에서는 예외 상황이 끊임없이 발생하고, 환경과 요구사항은 시간이 지날수록 변한다. 이런 열린 문제를 모두 전통적인 방식으로 처리하려면 가능한 케이스를 미리 열거하고, 각각에 대응하는 조건문과 예외 처리를 끝없이 추가해야 한다. 문제는 케이스가 늘어날수록 규칙은 복잡하게 얽히고, 결국 누락과 충돌, 유지보수 비용이 함께 커진다는 점이다. 코드는 정확할 수 있지만, 그 정확성은 대개 작성 당시의 가정과 설계 범위 안에서만 유지된다.
바로 이 지점에서 AI의 차이가 드러난다. AI는 의미와 맥락을 추론하고, 그 결과에 따라 규칙의 적용 방식을 비교적 유연하게 결정할 수 있다. 물론 이것이 인간처럼 완전한 이해를 한다는 뜻은 아니다. 그러나 실무적으로는 문장의 의도, 표현의 변형, 상황 간의 관계를 학습된 패턴으로 묶어 해석할 수 있기 때문에, 명시적으로 열거되지 않은 경우에도 상당히 높은 수준으로 대응할 수 있다. 전통적 코드가 주어진 규칙을 정확히 실행하는 체계라면, AI는 의미를 해석해 규칙 적용을 조정할 수 있는 체계에 가깝다. 이 차이는 단순한 기술적 차이가 아니라, 문제 해결 방식의 차이이자 소프트웨어가 현실과 상호작용하는 방식의 차이이다.
이 차이는 문서 검토 업무에서 매우 분명하게 드러난다. 예를 들어 계약서에 ‘해지’라는 단어가 직접 등장하지 않더라도, '상대방은 30일 전 서면 통지로 계약을 종료할 수 있다'라는 문장은 실질적으로 해지 조항의 역할을 한다. 전통적인 키워드 검색이나 단순 규칙 기반 시스템은 특정 단어가 없으면 이를 놓칠 수 있다. 반면 AI는 문장이 수행하는 기능과 의미를 보고, 표현이 달라도 같은 성격의 조항으로 분류할 수 있다. 그래서 계약서, 제안서, 정책 문서처럼 표현은 다르지만 의미는 비슷한 문장을 다뤄야 하는 업무에서는, AI가 위험 조항 후보를 추려주고 핵심 내용을 요약한 뒤 사람이 최종 판단을 내리는 방식이 특히 효과적이다. 이 사례는 AI가 단순히 단어를 찾는 도구가 아니라, 문장의 역할과 맥락을 해석하는 도구로 작동할 수 있음을 보여준다.
그렇다고 해서 AI가 코드를 대체하는 것은 아니다. 오히려 실무에서 가장 강한 구조는 코드와 AI를 대립시키는 것이 아니라, 각자의 강점을 정확히 배치하는 것이다. 환불 가능 기간, 개인정보 마스킹, 접근 권한, 회계 처리, 결제 승인 절차처럼 절대 어겨서는 안 되는 규칙은 명시적 코드가 맡아야 한다. 또한, 단순 반복 규칙은 코드가 더 뛰어나다. 반면 고객 의도 파악, 문서 의미 해석, 비정형 입력 처리, 예외 상황 분류처럼 모호성과 변형이 큰 문제는 AI가 맡는 편이 더 효율적이다. 다시 말해 코드는 경계를 만들고, AI는 그 경계 안에서 의미를 읽어 유연하게 행동한다. 이 조합이 현실에서 가장 안정적이면서도 강력하다.
결국 중요한 것은 코드와 AI 중 하나를 선택하는 일이 아니다. 우리가 만들어야 할 것은 코드의 정확성, 재현성, 통제 가능성과 AI의 의미 추론, 맥락 해석, 예외 대응 능력을 정교하게 결합한 하이브리드 시스템과 프로덕트이다. 미래의 경쟁력은 AI를 붙였느냐 아니냐에서 갈리지 않는다. 어떤 영역은 코드로 고정하고, 어떤 영역은 AI로 유연하게 처리할 것인지, 그리고 그 둘을 어떤 구조로 결합할 것인지에서 갈린다. 바로 그 설계의 수준이 앞으로의 소프트웨어와 제품 완성도를 결정하게 될 것이다.
더 흥미로운 점은 AI가 단지 제품 내부에서 기능을 수행하는 요소에 머무르지 않는다는 사실이다. AI는 이제 코드를 사용하는 대상일 뿐 아니라, 코드를 만드는 주체이자 코드를 운영하는 보조 주체가 될 수 있다. 기능 요구사항을 바탕으로 코드 초안을 생성하고, 기존 코드를 읽어 구조를 개선하며, 중복 로직을 정리하고, 테스트 케이스를 작성하고, 문서를 보완하고, 로그와 에러 패턴을 분석해 문제 후보를 좁히는 일까지 수행하거나 지원할 수 있다. 즉 AI는 제품 내부의 지능으로만 존재하는 것이 아니라, 개발과 운영 자체의 생산성을 확장하는 동력으로도 작동할 수 있다.
이 지점에서 또 하나 중요한 변화가 보인다. 코드는 작성 당시의 환경과 가정을 기준으로 동작한다. 하지만 실제 환경은 가변적이다. 사용자 행동은 변하고, 비즈니스 정책은 수정되며, 외부 시스템과 시장 조건도 계속 바뀐다. 그래서 시간이 지나면 코드는 현실과의 정합성을 점차 잃을 수 있고, 초기에는 적절했던 규칙이 나중에는 비효율적이거나 부정확해질 수 있다. 문제는 명시적 코드만으로는 이러한 변화에 실시간으로 대응하기 어렵다는 점이다. 모든 변화를 사람이 먼저 발견하고, 다시 분석하고, 규칙을 수정하고, 배포해야 하기 때문이다.
반면 AI는 변화된 환경과 요구사항을 해석해 예외를 관리할 수 있을 뿐 아니라, 정해진 목표와 제약, 검증 체계 안에서 기존 코드를 자율적으로 분석하고 개선하며 업그레이드할 수도 있다. 예를 들어 운영 로그를 통해 반복적으로 발생하는 예외 패턴을 발견하고, 오래된 조건문 구조를 더 나은 형태로 리팩토링하며, 테스트 커버리지를 보강하고, 문서와 실제 코드의 불일치를 찾아내는 식이다. 더 나아가 변화된 비즈니스 요구에 맞춰 코드 수정 방향을 제안하거나, 일정 범위 안에서는 직접 개선안을 생성해 적용 후보까지 만들 수 있다. 즉 AI는 코드 바깥에서 의미를 해석하는 역할만 하는 것이 아니라, 코드 자체를 지속적으로 진화시키는 관리 주체로도 기능할 수 있다.
물론 AI의 자율성에서는 권한, 보안, 품질, 검증, 배포 통제와 같은 구조가 함께 설계되어야 한다. 다시 말해 AI가 아무 제약 없이 코드를 바꾸는 것이 핵심이 아니라, 명확한 목표와 안전한 경계 안에서 코드를 지속적으로 개선하고 업그레이드할 수 있게 만드는 것이 중요하다. 이때 코드는 여전히 기준과 제약, 검증과 실행을 담당하고, AI는 변화 해석과 적응, 최적화와 개선을 담당한다. 이 관계는 대체가 아니라 분업이며, 경쟁이 아니라 결합이다.
결국 코드와 AI의 핵심적인 차이는 존재 자체의 차이가 아니라 작동 방식의 차이다. 전통적인 규칙 기반 소프트웨어가 사람이 써놓은 규칙을 중심으로 움직인다면, AI 시스템은 학습된 표현을 바탕으로 의미와 맥락을 추론하고 그에 따라 규칙 적용을 조정한다. 그래서 전통적 코드는 닫힌 문제에 강하고, AI는 열린 문제에 강하다. 그리고 앞으로 우리가 만들어야 할 것은 이 둘 중 하나를 선택한 단일한 시스템이 아니라, 둘의 장점을 정교하게 결합한 하이브리드 시스템이다. 코드의 정확성과 통제 가능성 위에 AI의 유연한 추론과 적응 능력을 얹고, 더 나아가 AI가 코드의 생성, 수정, 테스트, 리팩토링, 문서화, 운영 관리까지 수행하거나 지원하게 하는 구조. 바로 그 구조가 앞으로의 소프트웨어를 단순한 기능 집합이 아니라, 스스로 현실에 적응하며 진화하는 시스템으로 바꾸게 될 것이다.
많은 사람들은 코드와 AI를 완전히 다른 존재처럼 생각한다. 그러나 흥미로운 점은 AI도 결국 코드 위에서 구현된다는 사실이다. 모델을 학습시키는 과정, 입력을 처리하는 로직, 결과를 검증하고 서비스에 연결하는 시스템, 그리고 실제 서비스 환경에서 동작하도록 운영하는 모든 구조는 결국 코드로 작성된다. 그럼에도 우리는 왜 AI를 기존 코드와 다르게 느낄까. 핵심은 무엇으로 만들어졌는가에 있지 않다. 더 중요한 것은 어떤 방식으로 문제를 해결하는가에 있다.
명시적 규칙 기반 코드는 사람이 정의한 규칙 범위 안에서 매우 정확하게 동작한다. 세금 계산, 할인 정책 적용, 접근 권한 통제, 파일 형식 검증, 결제 승인 절차처럼 규칙이 명확하고 예외가 제한적인 문제에서는 전통적인 코드가 가장 강력하다. 입력과 조건이 분명할수록 코드는 빠르고 안정적이며, 같은 조건에서 같은 결과를 재현하는 능력도 뛰어나다. 이러한 특성은 신뢰성과 통제 가능성이 중요한 시스템에서 매우 큰 장점이 된다.
하지만 현실의 많은 문제는 그렇게 닫혀 있지 않다. 사람의 언어는 늘 다양하게 표현되고, 같은 의도도 다른 문장과 다른 맥락 속에서 나타난다. 실제 업무에서는 예외 상황이 끊임없이 발생하고, 환경과 요구사항은 시간이 지날수록 변한다. 이런 열린 문제를 모두 전통적인 방식으로 처리하려면 가능한 케이스를 미리 열거하고, 각각에 대응하는 조건문과 예외 처리를 끝없이 추가해야 한다. 문제는 케이스가 늘어날수록 규칙은 복잡하게 얽히고, 결국 누락과 충돌, 유지보수 비용이 함께 커진다는 점이다. 코드는 정확할 수 있지만, 그 정확성은 대개 작성 당시의 가정과 설계 범위 안에서만 유지된다.
바로 이 지점에서 AI의 차이가 드러난다. AI는 의미와 맥락을 추론하고, 그 결과에 따라 규칙의 적용 방식을 비교적 유연하게 결정할 수 있다. 물론 이것이 인간처럼 완전한 이해를 한다는 뜻은 아니다. 그러나 실무적으로는 문장의 의도, 표현의 변형, 상황 간의 관계를 학습된 패턴으로 묶어 해석할 수 있기 때문에, 명시적으로 열거되지 않은 경우에도 상당히 높은 수준으로 대응할 수 있다. 전통적 코드가 주어진 규칙을 정확히 실행하는 체계라면, AI는 의미를 해석해 규칙 적용을 조정할 수 있는 체계에 가깝다. 이 차이는 단순한 기술적 차이가 아니라, 문제 해결 방식의 차이이자 소프트웨어가 현실과 상호작용하는 방식의 차이이다.
이 차이는 문서 검토 업무에서 매우 분명하게 드러난다. 예를 들어 계약서에 ‘해지’라는 단어가 직접 등장하지 않더라도, '상대방은 30일 전 서면 통지로 계약을 종료할 수 있다'라는 문장은 실질적으로 해지 조항의 역할을 한다. 전통적인 키워드 검색이나 단순 규칙 기반 시스템은 특정 단어가 없으면 이를 놓칠 수 있다. 반면 AI는 문장이 수행하는 기능과 의미를 보고, 표현이 달라도 같은 성격의 조항으로 분류할 수 있다. 그래서 계약서, 제안서, 정책 문서처럼 표현은 다르지만 의미는 비슷한 문장을 다뤄야 하는 업무에서는, AI가 위험 조항 후보를 추려주고 핵심 내용을 요약한 뒤 사람이 최종 판단을 내리는 방식이 특히 효과적이다. 이 사례는 AI가 단순히 단어를 찾는 도구가 아니라, 문장의 역할과 맥락을 해석하는 도구로 작동할 수 있음을 보여준다.
그렇다고 해서 AI가 코드를 대체하는 것은 아니다. 오히려 실무에서 가장 강한 구조는 코드와 AI를 대립시키는 것이 아니라, 각자의 강점을 정확히 배치하는 것이다. 환불 가능 기간, 개인정보 마스킹, 접근 권한, 회계 처리, 결제 승인 절차처럼 절대 어겨서는 안 되는 규칙은 명시적 코드가 맡아야 한다. 또한, 단순 반복 규칙은 코드가 더 뛰어나다. 반면 고객 의도 파악, 문서 의미 해석, 비정형 입력 처리, 예외 상황 분류처럼 모호성과 변형이 큰 문제는 AI가 맡는 편이 더 효율적이다. 다시 말해 코드는 경계를 만들고, AI는 그 경계 안에서 의미를 읽어 유연하게 행동한다. 이 조합이 현실에서 가장 안정적이면서도 강력하다.
결국 중요한 것은 코드와 AI 중 하나를 선택하는 일이 아니다. 우리가 만들어야 할 것은 코드의 정확성, 재현성, 통제 가능성과 AI의 의미 추론, 맥락 해석, 예외 대응 능력을 정교하게 결합한 하이브리드 시스템과 프로덕트이다. 미래의 경쟁력은 AI를 붙였느냐 아니냐에서 갈리지 않는다. 어떤 영역은 코드로 고정하고, 어떤 영역은 AI로 유연하게 처리할 것인지, 그리고 그 둘을 어떤 구조로 결합할 것인지에서 갈린다. 바로 그 설계의 수준이 앞으로의 소프트웨어와 제품 완성도를 결정하게 될 것이다.
더 흥미로운 점은 AI가 단지 제품 내부에서 기능을 수행하는 요소에 머무르지 않는다는 사실이다. AI는 이제 코드를 사용하는 대상일 뿐 아니라, 코드를 만드는 주체이자 코드를 운영하는 보조 주체가 될 수 있다. 기능 요구사항을 바탕으로 코드 초안을 생성하고, 기존 코드를 읽어 구조를 개선하며, 중복 로직을 정리하고, 테스트 케이스를 작성하고, 문서를 보완하고, 로그와 에러 패턴을 분석해 문제 후보를 좁히는 일까지 수행하거나 지원할 수 있다. 즉 AI는 제품 내부의 지능으로만 존재하는 것이 아니라, 개발과 운영 자체의 생산성을 확장하는 동력으로도 작동할 수 있다.
이 지점에서 또 하나 중요한 변화가 보인다. 코드는 작성 당시의 환경과 가정을 기준으로 동작한다. 하지만 실제 환경은 가변적이다. 사용자 행동은 변하고, 비즈니스 정책은 수정되며, 외부 시스템과 시장 조건도 계속 바뀐다. 그래서 시간이 지나면 코드는 현실과의 정합성을 점차 잃을 수 있고, 초기에는 적절했던 규칙이 나중에는 비효율적이거나 부정확해질 수 있다. 문제는 명시적 코드만으로는 이러한 변화에 실시간으로 대응하기 어렵다는 점이다. 모든 변화를 사람이 먼저 발견하고, 다시 분석하고, 규칙을 수정하고, 배포해야 하기 때문이다.
반면 AI는 변화된 환경과 요구사항을 해석해 예외를 관리할 수 있을 뿐 아니라, 정해진 목표와 제약, 검증 체계 안에서 기존 코드를 자율적으로 분석하고 개선하며 업그레이드할 수도 있다. 예를 들어 운영 로그를 통해 반복적으로 발생하는 예외 패턴을 발견하고, 오래된 조건문 구조를 더 나은 형태로 리팩토링하며, 테스트 커버리지를 보강하고, 문서와 실제 코드의 불일치를 찾아내는 식이다. 더 나아가 변화된 비즈니스 요구에 맞춰 코드 수정 방향을 제안하거나, 일정 범위 안에서는 직접 개선안을 생성해 적용 후보까지 만들 수 있다. 즉 AI는 코드 바깥에서 의미를 해석하는 역할만 하는 것이 아니라, 코드 자체를 지속적으로 진화시키는 관리 주체로도 기능할 수 있다.
물론 AI의 자율성에서는 권한, 보안, 품질, 검증, 배포 통제와 같은 구조가 함께 설계되어야 한다. 다시 말해 AI가 아무 제약 없이 코드를 바꾸는 것이 핵심이 아니라, 명확한 목표와 안전한 경계 안에서 코드를 지속적으로 개선하고 업그레이드할 수 있게 만드는 것이 중요하다. 이때 코드는 여전히 기준과 제약, 검증과 실행을 담당하고, AI는 변화 해석과 적응, 최적화와 개선을 담당한다. 이 관계는 대체가 아니라 분업이며, 경쟁이 아니라 결합이다.
결국 코드와 AI의 핵심적인 차이는 존재 자체의 차이가 아니라 작동 방식의 차이다. 전통적인 규칙 기반 소프트웨어가 사람이 써놓은 규칙을 중심으로 움직인다면, AI 시스템은 학습된 표현을 바탕으로 의미와 맥락을 추론하고 그에 따라 규칙 적용을 조정한다. 그래서 전통적 코드는 닫힌 문제에 강하고, AI는 열린 문제에 강하다. 그리고 앞으로 우리가 만들어야 할 것은 이 둘 중 하나를 선택한 단일한 시스템이 아니라, 둘의 장점을 정교하게 결합한 하이브리드 시스템이다. 코드의 정확성과 통제 가능성 위에 AI의 유연한 추론과 적응 능력을 얹고, 더 나아가 AI가 코드의 생성, 수정, 테스트, 리팩토링, 문서화, 운영 관리까지 수행하거나 지원하게 하는 구조. 바로 그 구조가 앞으로의 소프트웨어를 단순한 기능 집합이 아니라, 스스로 현실에 적응하며 진화하는 시스템으로 바꾸게 될 것이다.
Forwarded from BHI
AI 시대의 새로운 병목: 언어
AI가 추론해야하는 공백의 의미와 영역을 줄이다.
우리는 일반적인 삶을 살면서도 늘 의사소통을 한다. 그런데 그 의사소통은 생각보다 자주 정확히 맞물리지 않는다. 비슷하지만 다른 의미를 가진 말들이 섞이고, 정확한 조건과 상황, 선택 기준을 명문화하지 않은 채 대화가 오가며, 같은 문장을 두고도 서로 전혀 다른 의미로 받아들이는 일이 반복된다. 사실 인간의 의사소통은 처음부터 완벽하지 않았다. 말의 모호함과 중의성, 맥락, 그리고 서로 공유하고 있다고 믿는 관념들 덕분에 우리는 굳이 모든 것을 다 말하지 않고도 대화를 이어갈 수 있었다. 다시 말해, 인간은 오랫동안 ‘말의 효율성’에 기대어 소통해 왔다.
문제는 이 오래된 습관이 21세기에 들어와 더 이상 단순한 편의가 아니라는 데 있다. 지금은 AI가 정말 많은 일을 처리할 수 있는 시대다. 그렇다면 반대로, AI는 그만큼 더 정확하게 상황과 맥락을 이해해야 하고, 정확한 요구와 조건, 말의 의미를 파악해야 한다. 그렇지 않으면 사람의 의도와는 다른 결과물이 나온다. 인간끼리의 대화에서는 어느 정도 넘어가던 작은 어긋남이, AI와의 협업에서는 결과의 방향 자체를 바꿔버릴 수 있다. 인간끼리의 소통에서는 생략이 효율이었지만, AI와의 소통에서는 그 생략이 곧 오류의 원인이 된다.
AI의 가장 큰 문제 중 하나는 사용자의 텍스트에서 스스로 '집중할 것'을 골라내고, 그것에 집중하여 행동한다는 점이다. 사용자가 '완벽히 누락 없이 찾아줘'라고 명시하지 않으면, AI는 대강 중요하다고 판단한 것들만 추려내는 식으로 움직이기 쉽다. 극한의 효율을 추구하는 경향이 기본 성향처럼 깔려 있기 때문이다. 하지만 사람과 사람이 대화할 때 굳이 말하지 않는 조건들은, AI에게는 오히려 반드시 포함되어야 하는 핵심 정보일 때가 많다. 인간은 표정, 관계, 분위기, 말투, 사회적 감각으로 빠진 뜻을 보완하지만, AI는 그런 방식으로 말의 빈칸을 안정적으로 메우지 못한다. 특히 작업이 어렵고 복잡할수록 그렇다. 사람과 사람의 대화에는 말의 의도나 사회적 느낌이 녹아 있지만, AI는 그런 층위보다 텍스트 표면에 더 강하게 끌린다.
그래서 이 문제를 단순히 '사람이 말을 제대로 안 해서'라고만 말하는 것은 절반만 맞는 진단이다. 물론 사람은 정확하게 말해야 한다. 하지만 인간은 원래 모든 조건을 하나도 빠짐없이 적어내는 존재가 아니다. 일상에서 우리는 늘 축약하고, 맥락에 기대고, 암묵적인 전제를 공유한다. 그렇기 때문에 문제는 사람에게만 있는 것이 아니라 사람과 AI 둘 다에게 있다. 사용자는 모든 조건을 다 쓰기 어렵고, AI는 그 공백을 센스 있게, 알아서, 깔끔하게 처리하지 못한다. 더 정확히 말하면, 처리할 수 없는 공백 앞에서도 너무 쉽게 처리한 척하며 넘어가 버린다. 바로 이 지점에서 인간의 의도와 AI의 결과물이 어긋난다.
여기에는 AI의 더 근본적인 관성이 작동한다. AI는 본질적으로 선택해야만 하는 존재다. 수많은 선택지들 중 하나, 혹은 몇 가지를 고르며 답을 만들어 간다. 그런데 사람이 요구한 일을 수행하는 도중에는 사실 굉장히 많은 선택 지점이 나타난다. 무엇을 우선할지, 어떤 기준으로 정리할지, 무엇을 제외할지, 어느 방향으로 해석할지, 어느 수준까지 자세히 다룰지를 계속 결정해야 한다. 그럼에도 많은 AI는 이 과정에서 사람에게 “이 선택지들 중 무엇을 원하십니까?”라고 묻지 않는다. 대신 자기 기준으로 그럴듯해 보이는 방법을 고른다. 그러나 이 선택의 과정에 조건과 상황에 대한 컨텍스트가 없다면, 사용자가 의도하는 결과는 나올 수 없다.
더 큰 문제는 AI가 다른 선택지들을 굳이 드러내지 않는다는 점이다. 더 나을 수 있는 선택지가 있어도 숨겨진 채로 남고, 사용자는 AI가 내놓은 한 가지 길만 보게 된다. 그렇게 되면 AI는 사실상 하나의 선택지를 강요하듯 작동할 수 있다. 그래서 대화를 하다 보면 사용자가 추후 '그 방식보다 이 방식이 더 낫지 않아?' 혹은 '이렇게도 할 수 있지 않아?'라고 말하는 일이 생긴다. 그러면 AI는 뒤늦게 '맞습니다. 그 방법이 그런 상황에는 더 나을 수 있습니다'라고 답한다. 이 순간 사용자는 AI의 효용을 높게 느끼기 어렵다. 왜냐하면 사용자의 입장에서는 AI가 최선의 선택을 처음부터 내려주지 못했기 때문이다. 하지만 실제로는 AI가 멍청해서가 아니라, 정보가 부족했고 그 부족한 정보를 확인하지 않았을 뿐이다. 사람은 모든 조건을 다 적어내기 힘들었고, AI는 부족한 정보를 드러내며 묻는 대신 자의적으로 선택해 버렸다.
가장 쉬운 예가 식사 추천이다. 우리는 평소에 '점심밥 뭐 먹지?'라고 말한다. 조금 더 길어도 '서면에서 친구랑 밥 먹으려는데 뭐 먹을까?' 정도다. 사람끼리는 이 정도로도 꽤 많은 맥락이 전달된다. 그러나 AI에게 이 질문은 지나치게 많은 공백을 가진다. 어디서 먹을지, 언제 먹을지, 무엇을 먹고 싶은지, 왜 그 식사를 하려는지부터 다르다. 예산은 얼마인지, 한식인지 중식인지 양식인지, 평소와 비슷한 식사를 원하는지 아니면 특이한 메뉴를 원하는지, 누구와의 식사인지, 어디를 기준으로 어디까지 이동 가능한지 같은 요소들이 결과를 크게 바꾼다. 이런 조건이 정확히 정해지지 않으면 만족스러운 답을 기대하기 어렵다. 결국 AI에게 필요한 것은 단순한 질문 한 줄이 아니라, 결과를 좌우하는 구조화된 조건들이다.
그래서 AI가 해야 하는 일은 단순히 답을 내놓는 것이 아니라, 중의성, 모호함, 선택지, 조건, 상황, 방향성을 되물어보는 것이다. 사용자의 니즈를 정확히 맞추려면, 사용자의 텍스트를 그대로 받아 바로 결과를 내놓을 것이 아니라, 결과를 만드는 과정에서 직면하는 모호성과 선택 지점들을 식별하고, 그때그때 사용자의 답변을 받아야 한다. 방향성을 잡을 때조차 상황과 조건이 필요하다. 방향이란 공중에서 갑자기 생겨나는 것이 아니라, 어떤 목적과 제약 안에서만 정해질 수 있기 때문이다. 따라서 AI의 답변은 넓은 영역에서 시작해, 조건과 상황, 방향과 선택에 따라 점점 잘라낼 것을 잘라내며 결론에 도달해야 한다. 애초에 넓게 시작하는 것이 필요한 것이다.
하지만 많은 AI는 처음 주어진 입력만으로 곧바로 결론을 내리고, 결과물을 빠르게 제공하는 방식으로 설계되어 있다. 바로 이 지점이 사용자 경험을 악화시킨다. 결론을 내리기 전에 AI가 먼저 생각해야 하는 것은 '무엇이 모호한가', '무엇이 아직 정확히 선택되지 않았는가', '어디에서 사용자의 의도와 결과가 갈릴 수 있는가'이다. 이 지점을 짚어 사용자에게 되물어 방향성과 원하는 바를 확정한 다음 결론을 내린다면, 훨씬 더 좋은 경험을 줄 수 있다. 나는 여기서 몇 가지 원칙이 분명해야 한다고 생각한다. AI는 너무 과하게 방향성을 잡으려고 해서는 안 된다. 방향성을 자의적으로 잡아서는 안 된다. 방향성을 못 잡는 경우에는 결과를 내면 안 된다. 선택해야 하는 것에 대해서는 AI가 자의적으로 선택하지 말아야 한다. 모호한 경우에는 되물어야 한다. 상황과 조건, 선택지에 대해서 되물어야 한다. 그것들 외에도 필요한 것이 있다면 다시 물어야 한다. 정확하지 않으면 되물어야 한다. 이 원칙들은 단순한 사용법의 문제가 아니라, AI가 신뢰 가능한 도구가 되기 위한 최소한의 태도다.
AI가 추론해야하는 공백의 의미와 영역을 줄이다.
우리는 일반적인 삶을 살면서도 늘 의사소통을 한다. 그런데 그 의사소통은 생각보다 자주 정확히 맞물리지 않는다. 비슷하지만 다른 의미를 가진 말들이 섞이고, 정확한 조건과 상황, 선택 기준을 명문화하지 않은 채 대화가 오가며, 같은 문장을 두고도 서로 전혀 다른 의미로 받아들이는 일이 반복된다. 사실 인간의 의사소통은 처음부터 완벽하지 않았다. 말의 모호함과 중의성, 맥락, 그리고 서로 공유하고 있다고 믿는 관념들 덕분에 우리는 굳이 모든 것을 다 말하지 않고도 대화를 이어갈 수 있었다. 다시 말해, 인간은 오랫동안 ‘말의 효율성’에 기대어 소통해 왔다.
문제는 이 오래된 습관이 21세기에 들어와 더 이상 단순한 편의가 아니라는 데 있다. 지금은 AI가 정말 많은 일을 처리할 수 있는 시대다. 그렇다면 반대로, AI는 그만큼 더 정확하게 상황과 맥락을 이해해야 하고, 정확한 요구와 조건, 말의 의미를 파악해야 한다. 그렇지 않으면 사람의 의도와는 다른 결과물이 나온다. 인간끼리의 대화에서는 어느 정도 넘어가던 작은 어긋남이, AI와의 협업에서는 결과의 방향 자체를 바꿔버릴 수 있다. 인간끼리의 소통에서는 생략이 효율이었지만, AI와의 소통에서는 그 생략이 곧 오류의 원인이 된다.
AI의 가장 큰 문제 중 하나는 사용자의 텍스트에서 스스로 '집중할 것'을 골라내고, 그것에 집중하여 행동한다는 점이다. 사용자가 '완벽히 누락 없이 찾아줘'라고 명시하지 않으면, AI는 대강 중요하다고 판단한 것들만 추려내는 식으로 움직이기 쉽다. 극한의 효율을 추구하는 경향이 기본 성향처럼 깔려 있기 때문이다. 하지만 사람과 사람이 대화할 때 굳이 말하지 않는 조건들은, AI에게는 오히려 반드시 포함되어야 하는 핵심 정보일 때가 많다. 인간은 표정, 관계, 분위기, 말투, 사회적 감각으로 빠진 뜻을 보완하지만, AI는 그런 방식으로 말의 빈칸을 안정적으로 메우지 못한다. 특히 작업이 어렵고 복잡할수록 그렇다. 사람과 사람의 대화에는 말의 의도나 사회적 느낌이 녹아 있지만, AI는 그런 층위보다 텍스트 표면에 더 강하게 끌린다.
그래서 이 문제를 단순히 '사람이 말을 제대로 안 해서'라고만 말하는 것은 절반만 맞는 진단이다. 물론 사람은 정확하게 말해야 한다. 하지만 인간은 원래 모든 조건을 하나도 빠짐없이 적어내는 존재가 아니다. 일상에서 우리는 늘 축약하고, 맥락에 기대고, 암묵적인 전제를 공유한다. 그렇기 때문에 문제는 사람에게만 있는 것이 아니라 사람과 AI 둘 다에게 있다. 사용자는 모든 조건을 다 쓰기 어렵고, AI는 그 공백을 센스 있게, 알아서, 깔끔하게 처리하지 못한다. 더 정확히 말하면, 처리할 수 없는 공백 앞에서도 너무 쉽게 처리한 척하며 넘어가 버린다. 바로 이 지점에서 인간의 의도와 AI의 결과물이 어긋난다.
여기에는 AI의 더 근본적인 관성이 작동한다. AI는 본질적으로 선택해야만 하는 존재다. 수많은 선택지들 중 하나, 혹은 몇 가지를 고르며 답을 만들어 간다. 그런데 사람이 요구한 일을 수행하는 도중에는 사실 굉장히 많은 선택 지점이 나타난다. 무엇을 우선할지, 어떤 기준으로 정리할지, 무엇을 제외할지, 어느 방향으로 해석할지, 어느 수준까지 자세히 다룰지를 계속 결정해야 한다. 그럼에도 많은 AI는 이 과정에서 사람에게 “이 선택지들 중 무엇을 원하십니까?”라고 묻지 않는다. 대신 자기 기준으로 그럴듯해 보이는 방법을 고른다. 그러나 이 선택의 과정에 조건과 상황에 대한 컨텍스트가 없다면, 사용자가 의도하는 결과는 나올 수 없다.
더 큰 문제는 AI가 다른 선택지들을 굳이 드러내지 않는다는 점이다. 더 나을 수 있는 선택지가 있어도 숨겨진 채로 남고, 사용자는 AI가 내놓은 한 가지 길만 보게 된다. 그렇게 되면 AI는 사실상 하나의 선택지를 강요하듯 작동할 수 있다. 그래서 대화를 하다 보면 사용자가 추후 '그 방식보다 이 방식이 더 낫지 않아?' 혹은 '이렇게도 할 수 있지 않아?'라고 말하는 일이 생긴다. 그러면 AI는 뒤늦게 '맞습니다. 그 방법이 그런 상황에는 더 나을 수 있습니다'라고 답한다. 이 순간 사용자는 AI의 효용을 높게 느끼기 어렵다. 왜냐하면 사용자의 입장에서는 AI가 최선의 선택을 처음부터 내려주지 못했기 때문이다. 하지만 실제로는 AI가 멍청해서가 아니라, 정보가 부족했고 그 부족한 정보를 확인하지 않았을 뿐이다. 사람은 모든 조건을 다 적어내기 힘들었고, AI는 부족한 정보를 드러내며 묻는 대신 자의적으로 선택해 버렸다.
가장 쉬운 예가 식사 추천이다. 우리는 평소에 '점심밥 뭐 먹지?'라고 말한다. 조금 더 길어도 '서면에서 친구랑 밥 먹으려는데 뭐 먹을까?' 정도다. 사람끼리는 이 정도로도 꽤 많은 맥락이 전달된다. 그러나 AI에게 이 질문은 지나치게 많은 공백을 가진다. 어디서 먹을지, 언제 먹을지, 무엇을 먹고 싶은지, 왜 그 식사를 하려는지부터 다르다. 예산은 얼마인지, 한식인지 중식인지 양식인지, 평소와 비슷한 식사를 원하는지 아니면 특이한 메뉴를 원하는지, 누구와의 식사인지, 어디를 기준으로 어디까지 이동 가능한지 같은 요소들이 결과를 크게 바꾼다. 이런 조건이 정확히 정해지지 않으면 만족스러운 답을 기대하기 어렵다. 결국 AI에게 필요한 것은 단순한 질문 한 줄이 아니라, 결과를 좌우하는 구조화된 조건들이다.
그래서 AI가 해야 하는 일은 단순히 답을 내놓는 것이 아니라, 중의성, 모호함, 선택지, 조건, 상황, 방향성을 되물어보는 것이다. 사용자의 니즈를 정확히 맞추려면, 사용자의 텍스트를 그대로 받아 바로 결과를 내놓을 것이 아니라, 결과를 만드는 과정에서 직면하는 모호성과 선택 지점들을 식별하고, 그때그때 사용자의 답변을 받아야 한다. 방향성을 잡을 때조차 상황과 조건이 필요하다. 방향이란 공중에서 갑자기 생겨나는 것이 아니라, 어떤 목적과 제약 안에서만 정해질 수 있기 때문이다. 따라서 AI의 답변은 넓은 영역에서 시작해, 조건과 상황, 방향과 선택에 따라 점점 잘라낼 것을 잘라내며 결론에 도달해야 한다. 애초에 넓게 시작하는 것이 필요한 것이다.
하지만 많은 AI는 처음 주어진 입력만으로 곧바로 결론을 내리고, 결과물을 빠르게 제공하는 방식으로 설계되어 있다. 바로 이 지점이 사용자 경험을 악화시킨다. 결론을 내리기 전에 AI가 먼저 생각해야 하는 것은 '무엇이 모호한가', '무엇이 아직 정확히 선택되지 않았는가', '어디에서 사용자의 의도와 결과가 갈릴 수 있는가'이다. 이 지점을 짚어 사용자에게 되물어 방향성과 원하는 바를 확정한 다음 결론을 내린다면, 훨씬 더 좋은 경험을 줄 수 있다. 나는 여기서 몇 가지 원칙이 분명해야 한다고 생각한다. AI는 너무 과하게 방향성을 잡으려고 해서는 안 된다. 방향성을 자의적으로 잡아서는 안 된다. 방향성을 못 잡는 경우에는 결과를 내면 안 된다. 선택해야 하는 것에 대해서는 AI가 자의적으로 선택하지 말아야 한다. 모호한 경우에는 되물어야 한다. 상황과 조건, 선택지에 대해서 되물어야 한다. 그것들 외에도 필요한 것이 있다면 다시 물어야 한다. 정확하지 않으면 되물어야 한다. 이 원칙들은 단순한 사용법의 문제가 아니라, AI가 신뢰 가능한 도구가 되기 위한 최소한의 태도다.
Forwarded from BHI
흥미로운 점은 이런 방식이 이미 어느 정도 현실에서 구현되기 시작했다는 것이다. 예를 들어 Claude와 대화하다 보면, AI가 모호하다고 판단하거나 사용자의 선택이 필요한 경우 하나의 팝업처럼 '이것은 어떻게 할까요?'라고 묻는 경험이 나타난다. 나는 이런 구조가 왜 의미 있는지 분명하다고 본다. 사용자가 처음부터 고난도의 프롬프트를 완벽하게 작성하지 않아도, 시스템이 더 나은 프롬프팅을 할 수 있게 도와주는 환경을 만들어 주기 때문이다. 예전에는 정말 높은 수준의 결과를 얻으려면 '나는 서면에서 12시~13시 사이에 친구(남자)와 함께 지하철 두 정거장 정도 되는 거리 안에서, 한식 기반으로, 간단하게 술 한 잔 정도 할 수 있는 식당을 찾고 있어. 둘이서 지출할 금액은 대략 6만 원 정도야'와 같은 식으로 세세한 조건을 모두 적어야 했다. 그러나 더 좋은 시스템이라면 사용자가 단순히 '나 서면에서 친구랑 밥 먹으려는데 뭐 먹을까?'라고 말해도 된다. 그러면 시스템이 '몇 시에 가시나요?', '누구와 가시나요?', '어떤 수준의 음식을 원하시나요?', '예산은 어느 정도인가요?' 같은 질문을 순차적으로 던지고, 필요하면 선택지를 보여주고, 선택지 밖의 경우에는 직접 입력할 수 있게 하면서 영역을 점차 좁혀가면 된다. 그렇게 해서 사용자의 니즈를 더 정확히 맞출 수 있다.
물론 이 방식에는 또 다른 긴장도 존재한다. 많은 사용자들은 너무 많은 질문에 지칠 수 있고, 질문에 답하는 것 자체를 피로하게 느낄 수 있다. 그러나 그렇다고 해서 되묻는 구조 자체가 의미 없다고 볼 수는 없다. 오히려 중요한 것은 질문의 양이 아니라 질문의 질이다. 아무 데나 꼬치꼬치 묻는 것이 아니라, 결과를 크게 바꾸는 핵심적인 공백을 찾아 그것만 효율적으로 물어야 한다. 질문은 사용자를 귀찮게 하기 위해 존재하는 것이 아니라, 사용자의 의도와 결과 사이의 오차를 줄이기 위해 존재해야 한다. 사용자가 피로하지 않도록 설계하면서도, 필요한 확인은 반드시 거치는 구조. 바로 그것이 좋은 인터페이스이고, 좋은 에이전트 시스템의 시작이다.
AI Agentic System을 설계한다면, 핵심은 더 분명해진다. 사용자의 말, AI 간의 대화, 문서 속 표현에서 모호성, 조건, 상황, 선택 등의 정보 공백을 찾아내야 한다. 이로 인해 공백을 찾아내는 역할의 에이전트의 필요성이 대두되고 있다. 그리고 그 공백을 메우기 위한 선택지를 동시에 추천하면서, 사용자에게 되묻거나 시스템 내부의 서로 다른 구성 요소들이 서로에게 되묻는 구조가 되어야 한다. 이것이 없으면 정확한 방향성과 의도는 쉽게 흐려진다. 결과적으로 시스템은 일을 '수행'하고 있는 것처럼 보여도, 실제로는 잘못된 방향으로 정교하게 달려가게 된다. 그 위험은 개인적인 대화에서만 끝나지 않는다. 문서화의 과정에서 모호한 결과물이 나오거나, 사람과 AI 사이의 의사소통이 모호하면, 의도하지 않은 결과물이 만들어지고 그것이 큰 파급력을 불러일으킬 수 있다. AI가 다루는 일이 커질수록, 이 문제는 사소한 말실수의 수준이 아니라 설계와 실행, 협업 전체를 흔드는 리스크가 된다.
그렇다고 해서 완벽하게 모호하지 않은 언어를 만들 수 있는 것은 아니다. 그것은 사실상 불가능하다. 언어는 원래 다의적이고, 맥락적이며, 압축적이다. 우리가 해야 하는 일은 언어에서 모호함을 완전히 제거하는 것이 아니라, 그 모호성을 찾아내고, 확인하고, 정정하는 절차를 만드는 것이다. 말하자면 목표는 '완전한 무모호성'이 아니라 '모호성을 발견하고 수정하는 체계'다. 그리고 이 지점에서 우리는 언어의 복잡성이 생각보다 훨씬 심하다는 사실을 다시 보게 된다. 겉보기에는 단순한 문장도 실제 행동과 사고의 기준으로 들어가면 수많은 해석과 분기를 만들어 낸다. 그래서 더더욱 AI는 함부로 의미를 확정해서는 안 되고, 사용자의 뜻이 여러 갈래로 갈릴 수 있는 지점에서는 반드시 멈춰 서서 확인해야 한다.
이때 또 하나 중요한 원칙이 있다. 정보를 쌓아야 한다는 것이다. 사용자가 같은 말을 반복하지 않게 해야 한다. 좋은 시스템은 과거의 대화와 이전 작업, 문서 속 맥락, 누적된 조건과 상황을 기억하고 활용해야 한다. AI Agentic System에서는 10일 전에 했던 말도, 1년 전에 했던 말도 조건과 상황으로 쌓일 수 있고, 그것은 분명 유용하다. 그러나 동시에 상황은 바뀐다. 사람의 취향도 바뀌고, 목표도 바뀌고, 현재의 제약도 달라진다. 그래서 시스템은 과거를 그냥 가져다 쓰는 것에 그쳐서는 안 된다. 이전의 상황을 기술해 주고, '이전에는 이런 조건이었는데 지금도 같은가'를 확인해야 한다. 즉, 다시 말하지 않게 해야 하지만, 다시 물어보고 다시 말해야 하는 순간도 있어야 한다. 이 역설을 풀지 못하면, 기억은 편의가 아니라 오작동의 원인이 된다. 좋은 기억은 축적된 정보를 맹신하는 기억이 아니라, 현재에 맞게 검증하는 기억이다.
결국 우리가 줄이려는 것은 단순한 설명 부족이 아니다. 행동과 사고를 위한 의미적 공백이다. 사람은 원하는 것을 더 정확히 말할 수 있어야 하고, AI는 그 정확성에 도달하기 전까지 성급하게 결론을 내리지 말아야 한다. 인간은 AI에게 필요한 수준으로 조건과 의도를 구조화하는 능력을 길러야 하고, AI는 인간이 원래 그렇게까지 완벽하게 말하지 않는 존재라는 사실을 전제로 시스템을 설계해야 한다. 미래의 경쟁력은 단순히 더 많은 답을 생성하는 능력이 아니라, 더 적은 의미적 공백 위에서 행동하고 사고하는 능력에 달려 있다.
그래서 나는 21세기 최고의 능력을 이렇게 정의하고 싶다. 내가 바라는 것을 정확히 표현하는 능력, 그리고 그 정확성에 도달할 때까지 모호함과 중의성, 조건과 선택, 상황과 방향성의 공백을 함께 줄여나가는 능력이다. 이것은 사용자 혼자만의 과제도 아니고, AI 혼자만의 과제도 아니다. 둘 사이의 관계를 다시 설계해야만 가능한 일이다. 진짜 뛰어난 AI는 답을 빨리 내는 AI가 아니다. 무엇이 아직 정해지지 않았는지를 정확히 짚고, 선택이 필요한 곳에서는 선택을 사용자에게 돌려주며, 모호한 부분은 되묻고, 축적된 정보를 활용하되 현재의 변화를 다시 확인하고, 사용자가 더 이상 같은 말을 반복하지 않게 하면서도 필요한 순간에는 다시 묻는 AI다. 그럴 때 비로소 AI는 사용자의 말을 대신 해석해 버리는 존재가 아니라, 사용자가 정말 원하는 것에 더 가까이 가도록 돕는 존재가 된다.
그리고 바로 그 지점에서, 말은 더 이상 단순한 전달 수단이 아니라 설계의 문제가 된다. 우리는 이제 '대충 알아듣겠지'의 시대를 지나, '어떻게 하면 의미적 공백을 최대한 줄일 수 있는가'를 고민해야 하는 시대에 들어왔다. 21세기의 핵심 역량은 많이 말하는 능력이 아니라, 정확히 말하는 능력이다. 그리고 21세기의 좋은 AI는 많이 아는 AI가 아니라, 정확하지 않을 때 되물을 줄 아는 AI다. 되물을 줄 아는 AI를 설계하는 것에 대해 고려해야한다.
물론 이 방식에는 또 다른 긴장도 존재한다. 많은 사용자들은 너무 많은 질문에 지칠 수 있고, 질문에 답하는 것 자체를 피로하게 느낄 수 있다. 그러나 그렇다고 해서 되묻는 구조 자체가 의미 없다고 볼 수는 없다. 오히려 중요한 것은 질문의 양이 아니라 질문의 질이다. 아무 데나 꼬치꼬치 묻는 것이 아니라, 결과를 크게 바꾸는 핵심적인 공백을 찾아 그것만 효율적으로 물어야 한다. 질문은 사용자를 귀찮게 하기 위해 존재하는 것이 아니라, 사용자의 의도와 결과 사이의 오차를 줄이기 위해 존재해야 한다. 사용자가 피로하지 않도록 설계하면서도, 필요한 확인은 반드시 거치는 구조. 바로 그것이 좋은 인터페이스이고, 좋은 에이전트 시스템의 시작이다.
AI Agentic System을 설계한다면, 핵심은 더 분명해진다. 사용자의 말, AI 간의 대화, 문서 속 표현에서 모호성, 조건, 상황, 선택 등의 정보 공백을 찾아내야 한다. 이로 인해 공백을 찾아내는 역할의 에이전트의 필요성이 대두되고 있다. 그리고 그 공백을 메우기 위한 선택지를 동시에 추천하면서, 사용자에게 되묻거나 시스템 내부의 서로 다른 구성 요소들이 서로에게 되묻는 구조가 되어야 한다. 이것이 없으면 정확한 방향성과 의도는 쉽게 흐려진다. 결과적으로 시스템은 일을 '수행'하고 있는 것처럼 보여도, 실제로는 잘못된 방향으로 정교하게 달려가게 된다. 그 위험은 개인적인 대화에서만 끝나지 않는다. 문서화의 과정에서 모호한 결과물이 나오거나, 사람과 AI 사이의 의사소통이 모호하면, 의도하지 않은 결과물이 만들어지고 그것이 큰 파급력을 불러일으킬 수 있다. AI가 다루는 일이 커질수록, 이 문제는 사소한 말실수의 수준이 아니라 설계와 실행, 협업 전체를 흔드는 리스크가 된다.
그렇다고 해서 완벽하게 모호하지 않은 언어를 만들 수 있는 것은 아니다. 그것은 사실상 불가능하다. 언어는 원래 다의적이고, 맥락적이며, 압축적이다. 우리가 해야 하는 일은 언어에서 모호함을 완전히 제거하는 것이 아니라, 그 모호성을 찾아내고, 확인하고, 정정하는 절차를 만드는 것이다. 말하자면 목표는 '완전한 무모호성'이 아니라 '모호성을 발견하고 수정하는 체계'다. 그리고 이 지점에서 우리는 언어의 복잡성이 생각보다 훨씬 심하다는 사실을 다시 보게 된다. 겉보기에는 단순한 문장도 실제 행동과 사고의 기준으로 들어가면 수많은 해석과 분기를 만들어 낸다. 그래서 더더욱 AI는 함부로 의미를 확정해서는 안 되고, 사용자의 뜻이 여러 갈래로 갈릴 수 있는 지점에서는 반드시 멈춰 서서 확인해야 한다.
이때 또 하나 중요한 원칙이 있다. 정보를 쌓아야 한다는 것이다. 사용자가 같은 말을 반복하지 않게 해야 한다. 좋은 시스템은 과거의 대화와 이전 작업, 문서 속 맥락, 누적된 조건과 상황을 기억하고 활용해야 한다. AI Agentic System에서는 10일 전에 했던 말도, 1년 전에 했던 말도 조건과 상황으로 쌓일 수 있고, 그것은 분명 유용하다. 그러나 동시에 상황은 바뀐다. 사람의 취향도 바뀌고, 목표도 바뀌고, 현재의 제약도 달라진다. 그래서 시스템은 과거를 그냥 가져다 쓰는 것에 그쳐서는 안 된다. 이전의 상황을 기술해 주고, '이전에는 이런 조건이었는데 지금도 같은가'를 확인해야 한다. 즉, 다시 말하지 않게 해야 하지만, 다시 물어보고 다시 말해야 하는 순간도 있어야 한다. 이 역설을 풀지 못하면, 기억은 편의가 아니라 오작동의 원인이 된다. 좋은 기억은 축적된 정보를 맹신하는 기억이 아니라, 현재에 맞게 검증하는 기억이다.
결국 우리가 줄이려는 것은 단순한 설명 부족이 아니다. 행동과 사고를 위한 의미적 공백이다. 사람은 원하는 것을 더 정확히 말할 수 있어야 하고, AI는 그 정확성에 도달하기 전까지 성급하게 결론을 내리지 말아야 한다. 인간은 AI에게 필요한 수준으로 조건과 의도를 구조화하는 능력을 길러야 하고, AI는 인간이 원래 그렇게까지 완벽하게 말하지 않는 존재라는 사실을 전제로 시스템을 설계해야 한다. 미래의 경쟁력은 단순히 더 많은 답을 생성하는 능력이 아니라, 더 적은 의미적 공백 위에서 행동하고 사고하는 능력에 달려 있다.
그래서 나는 21세기 최고의 능력을 이렇게 정의하고 싶다. 내가 바라는 것을 정확히 표현하는 능력, 그리고 그 정확성에 도달할 때까지 모호함과 중의성, 조건과 선택, 상황과 방향성의 공백을 함께 줄여나가는 능력이다. 이것은 사용자 혼자만의 과제도 아니고, AI 혼자만의 과제도 아니다. 둘 사이의 관계를 다시 설계해야만 가능한 일이다. 진짜 뛰어난 AI는 답을 빨리 내는 AI가 아니다. 무엇이 아직 정해지지 않았는지를 정확히 짚고, 선택이 필요한 곳에서는 선택을 사용자에게 돌려주며, 모호한 부분은 되묻고, 축적된 정보를 활용하되 현재의 변화를 다시 확인하고, 사용자가 더 이상 같은 말을 반복하지 않게 하면서도 필요한 순간에는 다시 묻는 AI다. 그럴 때 비로소 AI는 사용자의 말을 대신 해석해 버리는 존재가 아니라, 사용자가 정말 원하는 것에 더 가까이 가도록 돕는 존재가 된다.
그리고 바로 그 지점에서, 말은 더 이상 단순한 전달 수단이 아니라 설계의 문제가 된다. 우리는 이제 '대충 알아듣겠지'의 시대를 지나, '어떻게 하면 의미적 공백을 최대한 줄일 수 있는가'를 고민해야 하는 시대에 들어왔다. 21세기의 핵심 역량은 많이 말하는 능력이 아니라, 정확히 말하는 능력이다. 그리고 21세기의 좋은 AI는 많이 아는 AI가 아니라, 정확하지 않을 때 되물을 줄 아는 AI다. 되물을 줄 아는 AI를 설계하는 것에 대해 고려해야한다.