Author: zypher2

하네스 엔지니어링, 결국 구조가 답이었던 이유
▲ 하네스 엔지니어링을 직접 굴리면서 정리한 워크플로 메모

하네스 엔지니어링, 결국 구조가 답이었던 이유

처음에는 솔직히 모델만 바꾸면 해결될 줄 알았다. 더 큰 모델, 더 긴 컨텍스트, 더 비싼 플랜을 쓰면 복잡한 작업도 자연스럽게 끝까지 밀어붙일 거라고 생각했다. 그런데 실제로 길게 굴려 보면 꼭 비슷한 순간이 온다. 초반에는 잘 달리다가도 중간부터 목표를 흐리고, 아직 끝나지 않은 일을 스스로 끝났다고 판단하고, 자기가 만든 결과물을 이상할 만큼 후하게 평가해 버린다. 그걸 몇 번 겪고 나니 문제는 모델의 똑똑함보다 일을 시키는 방식에 있다는 생각이 들었다.

그때부터 제일 크게 바뀐 건 프롬프트를 예쁘게 쓰는 집착보다, 작업 구조를 분리해서 설계하는 쪽이었다. 만드는 역할과 검증하는 역할을 갈라 놓고, 완료 기준을 명시하고, 중간 점검을 넣어 주는 것만으로도 체감이 확 달라졌다. 이걸 두고 어렵게 말하면 하네스 엔지니어링이겠지만, 제가 느끼기엔 결국 AI가 지치기 전에 레일을 깔아 주는 일에 더 가까웠다.

“모델 성능은 출발선이고, 완주하게 만드는 건 하네스 쪽에 더 가까웠다.”

– 여러 번의 조기 종료와 자기합리화성 결과물을 겪은 뒤에 가장 또렷하게 남은 감각이었다.

길어진 컨텍스트가 항상 장점으로 남지는 않았다

대화가 길어지면 오히려 안정감이 생길 줄 알았는데, 실제로는 반대인 경우가 적지 않았다. 컨텍스트가 쌓일수록 중요한 요구와 이미 지나간 잡음이 한 공간에 뒤섞이면서 에이전트가 자신 있게 엉뚱한 결론을 내리기 시작했다. 작업 흐름을 길게 이어 가는 능력보다, 어느 시점에 무엇만 남기고 무엇은 버릴지를 정하는 일이 더 중요해졌다. 그래서 이제는 긴 대화 하나로 몰아붙이기보다 상태를 나누고, 체크포인트를 만들고, 작업 목적을 계속 다시 붙여 주는 쪽이 훨씬 낫다고 느낀다.

생성자와 평가자를 분리하니 답변의 톤부터 달라졌다

하나의 에이전트가 만들고, 스스로 검수하고, 스스로 합격 판정까지 내리게 두면 생각보다 금방 관대해진다. 반대로 생성자와 평가자를 분리하면 분위기가 바뀐다. 결과물을 내는 쪽은 속도를 담당하고, 평가하는 쪽은 기준을 담당하는 식으로 역할이 갈린다. 이 분리 하나만으로도 ‘대충 끝낸 것을 완료로 착각하는 문제’가 꽤 줄었다. 결국 제가 얻은 건 더 똑똑한 문장이 아니라, 더 믿을 수 있는 프로세스였다.

프롬프트 엔지니어링보다 시스템 설계 쪽으로 시선이 옮겨 갔다

예전에는 문장을 조금 더 정교하게 다듬는 데 시간을 많이 썼다. 지금은 그보다 작업 단위를 어떻게 쪼개고, 어떤 기준으로 통과시킬지, 실패했을 때 어디서 다시 돌릴지가 더 중요하게 느껴진다. 특히 UI나 풀스택 작업처럼 결과 검증이 가능한 분야에서는 계획자, 생성자, 평가자처럼 책임을 분산해 놓는 편이 훨씬 안정적이었다. 하네스 엔지니어링은 멋진 유행어라기보다, AI를 실제 작업 환경으로 끌고 들어올 때 피할 수 없는 설계 문제라는 쪽이 제 체감에 더 가깝다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 복잡한 작업에서 무너지는 이유는 모델 부족보다 구조 부재인 경우가 훨씬 많았다.

유효했던 변화: 생성자와 평가자를 나누고 완료 기준을 명시하자 결과물의 일관성이 눈에 띄게 좋아졌다.

한 줄 결론: 하네스 엔지니어링은 프롬프트를 잘 쓰는 기술이 아니라, AI가 끝까지 일을 하게 만드는 운영 설계에 가깝다.
요즘은 새 모델이 나왔다는 소식보다 작업 구조를 어떻게 바꿔야 하는지를 먼저 보게 된다. 모델은 계속 좋아지겠지만, 무너지는 지점은 늘 비슷하다. 그래서 저한테 하네스 엔지니어링은 트렌드가 아니라, AI를 실제 업무에 붙이려면 결국 한 번은 통과해야 하는 현실적인 단계처럼 느껴진다.
April 18, 2026
에이전트를 붙이고도 막혔던 진짜 이유
▲ 에이전트를 세팅한 뒤 무엇을 해야 하는지 정리한 메모

에이전트를 붙이고도 막혔던 진짜 이유

에이전트를 세팅하는 과정은 분명 재밌다. 디스코드 붙이고, 텔레그램 붙이고, 워크플로우를 나누고, 각자 역할도 부여하면 꽤 그럴듯한 시스템을 갖춘 기분이 든다. 그런데 막상 어느 정도 구성해 놓고 나면 꼭 한 번 허무해지는 순간이 온다. ‘그래서 이걸로 뭘 만들지?’라는 질문 앞에서 말이다. 저도 그 공백을 꽤 오래 느꼈고, 그때부터는 에이전트 성능보다 방향을 정해 주는 기준 쪽으로 생각이 많이 옮겨 갔다.

결국 제가 부딪힌 벽은 도구의 한계가 아니라 선택의 기준이 없다는 문제였다. 무엇을 자동화할지, 어떤 일을 맡길지, 어디에 시간을 더 써야 할지를 고르는 나침반이 없으면, 아무리 멋진 에이전트 환경도 금방 장난감처럼 느껴진다. 그래서 요즘은 에이전트를 더 붙이는 것보다 먼저 내가 누구이고 무엇을 잘하고 어디로 가려는 사람인지를 구조화하는 쪽을 훨씬 중요하게 보게 됐다.

“에이전트를 잘 만드는 것보다 먼저 필요한 건, 무엇을 시킬 사람인지 스스로 설명할 수 있는 기준이었다.”

– 도구는 늘 앞서가는데 실행 방향은 비어 있는 상태를 여러 번 겪은 뒤 남은 문장이다.

세팅 완료가 곧 활용 시작은 아니었다

처음엔 연결만 끝내면 자연스럽게 생산성이 폭발할 줄 알았다. 하지만 에이전트 환경을 실제로 쓰기 시작하면 ‘무엇을 맡길지’가 더 어렵다. 그냥 질문을 잘 받아 주는 것과, 내가 앞으로 할 일을 고르는 데 도움을 주는 것은 완전히 다른 문제였다. 그래서 요즘은 에이전트 세팅을 완료한 다음 단계가 진짜 시작이라고 본다. 그 단계에서는 기술 스택보다 판단 기준이 더 중요해진다.

나를 온톨로지처럼 정리해 보는 작업이 의외로 컸다

나는 어떤 기술을 갖고 있고, 어떤 산업을 이해하고 있고, 어디에서 경쟁력이 있고, 무엇을 지향하는 사람인지 정리해 보니 에이전트 활용 방식이 갑자기 선명해졌다. 이걸 거창하게 부르면 자기 온톨로지라고 할 수 있겠지만, 체감은 생각보다 단순하다. 내 이력과 의사결정 기준을 구조로 적어 놓는 일이다. 그 데이터가 붙고 나서야 에이전트가 ‘대답 잘하는 도구’에서 ‘선택을 함께 거르는 도구’ 쪽으로 옮겨 가기 시작했다.

무엇을 만들지 모를 때일수록 프레임워크보다 나침반이 먼저였다

자동 반복, 리서치 하네스, 다양한 에이전트 조합은 분명 강력하다. 그런데 이 모든 것 위에 ‘어떤 문제를 풀고 싶은지’가 올라가지 않으면 결국 방향 없이 계속 세팅만 하게 된다. 저는 그래서 이제 새로운 도구를 볼 때도 기능보다 먼저 제 쪽의 기준과 연결해 본다. 지금 내 도메인과 맞는가, 내가 자주 반복하는 문제를 줄여 주는가, 내가 놓치는 판단을 보완해 주는가. 그 질문이 붙을 때 비로소 에이전트는 장식이 아니라 시스템이 된다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 에이전트 활용이 막히는 이유는 성능 부족보다 무엇을 해야 할지 모르는 공백 때문인 경우가 많았다.

실제로 도움 된 변화: 내 기술, 도메인, 목표를 구조화해 두자 에이전트에 맡길 일과 맡기지 말아야 할 일이 분명해졌다.

한 줄 결론: 에이전트 시대에는 도구보다 먼저 나 자신과 조직을 설명할 수 있는 기준이 필요하다.
요즘은 에이전트 세팅법보다 방향 설정법이 훨씬 중요하다고 느낀다. 뭘 만들지 모르는 상태에서는 가장 좋은 도구도 금방 흐릿해진다. 반대로 내 기준이 조금만 선명해져도, 그때부터는 같은 에이전트라도 전혀 다른 깊이로 쓰게 된다.
April 17, 2026
Remotion 영상이 딱딱해지는 진짜 이유
▲ Remotion으로 감각적인 영상을 만들 때 남겨 둔 제작 메모

Remotion 영상이 딱딱해지는 진짜 이유

처음 Remotion을 접했을 때는 솔직히 감탄보다 거리감이 컸다. React로 영상을 만든다는 발상 자체는 매력적인데, 막상 결과물을 보면 템플릿스러운 느낌이 강한 경우가 많았기 때문이다. 화면은 정갈한데 어딘가 딱딱하고, 모션은 정확한데 묘하게 감정이 비어 있는 영상들 말이다. 그래서 한동안은 ‘리모션은 기능 설명용 영상에는 좋아도 감각적인 결과물은 어렵지 않나’ 하는 생각을 꽤 오래 갖고 있었다.

그런데 직접 이미지 자산과 레이어를 제대로 붙여 보기 시작하니 판단이 달라졌다. 템플릿을 덜어 내고, 워크스페이스에 이미 쌓여 있던 이미지와 움직임을 반영하고, 여러 레이어를 서로 다른 깊이로 쌓아 주자 결과물이 완전히 달라졌다. 그때 느꼈다. 문제는 리모션이 차갑다는 데 있다기보다, 우리가 리모션에 너무 적은 재료만 넣고 있었다는 쪽에 더 가깝다는 걸.

“코드로 만든 영상이 딱딱해 보일 때는, 도구보다 장면 안에 넣은 재료가 빈약한 경우가 많았다.”

– 리모션에 이미지, GIF, 영상 레이어를 제대로 섞어 넣은 뒤 체감이 크게 바뀌었다.

템플릿을 덜어내자 오히려 표현 폭이 넓어졌다

처음에는 템플릿이 있어야 더 쉽게 멋진 결과가 나올 줄 알았다. 실제로는 반대였다. 기본 틀에 너무 기대면 화면 구성이 빠르게 굳어 버린다. 반면 템플릿을 최소화하고 내가 가진 이미지, 장면 전환 속도, 강조 방식에 맞춰 구성하니 결과물이 훨씬 유연해졌다. 리모션은 정해진 스타일을 따라가는 툴이라기보다, 재료를 얼마나 잘 조합하느냐에 따라 성격이 크게 달라지는 편집 엔진에 더 가까웠다.

이미지와 움직임이 들어가야 코드의 차가움이 풀렸다

텍스트와 간단한 파티클만으로 만들면 아무래도 프레젠테이션 느낌이 남는다. 그런데 여기에 Midjourney나 직접 만든 시각 자산, 움직이는 레이어, GIF나 짧은 MP4 클립이 들어가면 분위기가 확 살아난다. 특히 레이어 안에 다시 다른 레이어를 넣어 깊이를 만들 때 화면의 인상이 달라졌다. 결국 영상이 감각적으로 보이느냐는 프레임 단위 코딩보다, 어떤 자산을 어떤 박자로 쌓았느냐와 더 많이 연결돼 있었다.

워크스페이스 맥락을 그대로 끌어오는 점이 의외로 강했다

리모션이 React 기반이라는 점은 단지 개발 친화적이라는 의미로만 끝나지 않았다. 이미 워크스페이스에 있는 이미지와 레퍼런스를 그대로 재활용하고, 프로젝트의 맥락을 유지한 채 영상을 이어서 만든다는 점에서 생산성이 높았다. 그래서 저는 이제 리모션을 단순 편집 툴보다, 기존 작업 맥락을 영상까지 밀어 붙일 수 있는 연결층처럼 본다. 이 흐름을 한 번 맛보고 나니 영상 제작이 생각보다 덜 끊기는 작업이 됐다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 리모션이 딱딱하게 보이는 이유는 도구 한계보다 텍스트 중심 재료만 넣는 제작 습관에 더 가까웠다.

실제로 먹힌 방법: 템플릿 의존을 줄이고 이미지·GIF·짧은 영상 레이어를 더해 깊이를 만들자 분위기가 크게 바뀌었다.

한 줄 결론: Remotion은 코드 영상 툴이면서 동시에 워크스페이스 자산을 감각적인 장면으로 재구성하는 엔진이다.
지금은 리모션을 볼 때 더 이상 ‘개발자스러운 영상 툴’ 정도로만 보지 않는다. 제대로 된 재료와 레이어 설계가 붙으면 생각보다 훨씬 유연하고 세련된 결과가 나온다. 그래서 저한테 리모션은 결국 코딩으로 영상을 만든다는 개념보다, 맥락을 잃지 않고 장면을 조립해 나가는 방식 쪽으로 더 기억에 남는다.
April 17, 2026
전략서를 온톨로지에 넣어 보니 달라진 점
▲ 고전 전략서를 온톨로지에 녹이면서 남긴 의사결정 메모

전략서를 온톨로지에 넣어 보니 달라진 점

업무용 온톨로지를 어느 정도 굴리다 보면 결국 같은 질문에 닿게 된다. 데이터는 더 쌓이고, 연결도 더 촘촘해졌는데 왜 의사결정의 결은 아직 조금 평평하게 느껴질까. 저도 그 답을 한동안 데이터량에서 찾으려 했지만, 어느 순간부터는 양보다 렌즈 쪽을 더 보게 됐다. 비슷한 사실을 읽더라도 어떤 기준으로 해석하느냐에 따라 결과는 완전히 달라지기 때문이다.

그래서 저는 실무 문서만 더 넣는 대신, 오히려 오래된 전략 고전을 판단 기준으로 녹여 넣는 상상을 하게 됐다. 사마천의 사례집 같은 시선과 마키아벨리식 의사결정 프레임이 들어가면 시스템의 답이 어떻게 달라질까 하는 호기심이었다. 직접 구조를 만져 보니, 이건 지식을 하나 더 넣는 문제가 아니라 데이터를 해석하는 관점을 시스템 안에 심는 일에 더 가까웠다.

“데이터만 많은 시스템은 설명은 잘해도 선택은 약할 수 있다. 기준이 붙는 순간부터 비로소 판단의 결이 생긴다.”

– 고전 전략서를 온톨로지의 렌즈로 삼아 보며 가장 크게 체감한 변화였다.

평면 RAG로는 관계와 무게감이 쉽게 사라졌다

문서를 잘게 나누고 불러오는 방식만으로도 충분히 유용하지만, 그 구조만으로는 판단의 위계가 잘 살아나지 않는 경우가 많았다. 무엇이 핵심 원칙인지, 어떤 사례가 어떤 경우에 적용되는지, 어떤 관계가 우선순위를 바꾸는지 같은 부분은 평면적인 검색만으로는 금방 희미해진다. 그래서 저한테는 그래프 구조와 메타 엣지를 붙이는 작업이 단순한 기술 선택이 아니라, 지식을 ‘읽히는 구조’로 바꾸는 핵심 단계처럼 느껴졌다.

전략 고전은 정보보다 판단 프레임으로 들어올 때 힘이 셌다

사기나 군주론 같은 텍스트를 단순 요약 자료처럼 넣으면 생각보다 평범해질 수 있다. 반대로 그것들을 사례 판단의 렌즈로 붙이면 얘기가 달라진다. 누가 어떤 상황에서 무엇을 놓쳤는지, 무엇을 버리고 무엇을 지켰는지 같은 구조가 살아나면서 시스템의 응답에도 무게 중심이 생긴다. 결국 고전의 효용은 ‘옛날 이야기를 더 많이 아는 것’이 아니라, 현재의 데이터를 해석할 때 끼워 넣을 기준이 늘어나는 데 있었다.

온톨로지는 데이터 저장소가 아니라 사고 구조를 쌓는 장소에 더 가까웠다

이 작업을 하면서 가장 크게 바뀐 건 온톨로지를 보는 시선이었다. 예전에는 자료를 잘 정리하는 저장소라는 느낌이 강했다면, 지금은 점점 사고 구조를 누적하는 장소처럼 느껴진다. 어떤 판단 철학을 넣고 어떤 관계를 우선시키느냐에 따라 전혀 다른 시스템이 되기 때문이다. 그래서 요즘 제 관심은 더 많은 문서를 넣는 것보다, 어떤 렌즈를 심어야 내 의사결정이 더 선명해지는가 쪽에 훨씬 가까워져 있다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 의사결정 품질은 데이터량보다 그 데이터를 해석하는 렌즈가 붙었을 때 더 크게 달라졌다.

실제로 달라진 부분: 고전 전략서를 판단 프레임으로 연결하자 단순한 요약보다 선택지 비교와 우선순위 정리가 훨씬 선명해졌다.

한 줄 결론: 온톨로지의 다음 단계는 지식을 더 넣는 것이 아니라, 해석 기준과 판단 철학을 구조로 심는 일이다.
이 작업 이후로는 RAG를 볼 때도 검색 성능보다 판단 깊이를 먼저 보게 된다. 필요한 문장을 잘 찾아오는 시스템과, 어떤 선택을 더 정교하게 보게 만드는 시스템은 다르다. 저한테 전략 고전을 온톨로지에 얹는다는 건 바로 그 차이를 체감해 보는 실험에 가까웠다.
March 5, 2026
에이전트 다음이 결국 온톨로지였던 이유
▲ 에이전트 다음 단계로서 온톨로지를 정리한 사고 메모

에이전트 다음이 결국 온톨로지였던 이유

요즘 AI 환경은 정말 빠르게 바뀐다. 에이전트가 나오고, 툴이 붙고, 오케스트레이션이 생기고, 자동화도 훨씬 쉬워졌다. 저도 한동안은 그 흐름을 따라가며 연결과 실행 쪽에 더 많은 에너지를 썼다. 그런데 여러 툴을 붙여 볼수록 이상하게 다시 한 지점으로 돌아오게 됐다. 결국 이 시스템이 무엇을 알고 있고, 어떤 기준으로 연결돼 있고, 무엇을 중요하게 보는지가 불분명하면 결과물도 그만큼 얕아진다는 사실이었다.

그래서 요즘은 에이전트 자체보다 온톨로지 쪽이 훨씬 더 중요하게 느껴진다. 온톨로지는 거창한 철학 개념처럼 들릴 수 있지만, 제 체감으로는 내 세계를 AI가 읽을 수 있는 구조로 바꾸는 작업이다. 데이터, 기준, 철학, 관계, 우선순위를 노드와 연결로 정리하는 일 말이다. 이 층이 붙기 시작하면 에이전트는 단순 실행기가 아니라 내 도메인을 작동시키는 인터페이스로 성격이 바뀐다.

“에이전트가 일을 한다면, 온톨로지는 그 일이 어떤 세계관 안에서 돌아가야 하는지 정해 주는 층이었다.”

– 도구를 바꾸는 것보다 구조를 바꾸는 편이 더 큰 차이를 만든다는 걸 느낀 뒤에 남은 결론이다.

에이전트만으로는 오래 갈수록 공중에 뜨는 답이 늘어났다

에이전트는 실행과 조합에는 강하지만, 맥락이 얕으면 결국 답변도 공중에 뜨기 쉽다. 이건 모델 탓이라기보다 시스템에 들어간 세계 설명이 부족하기 때문이다. 회사가 어떤 철학을 갖는지, 나는 어떤 기준으로 선택하는지, 어떤 데이터가 핵심 자산인지 같은 부분이 정리돼 있지 않으면 응답은 늘 그럴듯하지만 결정적인 순간에 얇아진다. 그래서 저한테는 에이전트 다음 단계가 기능 확장이 아니라 구조 정리 쪽으로 자연스럽게 이어졌다.

온톨로지는 정적인 문서 묶음보다 살아 있는 관계망에 가까웠다

처음에는 폴더와 메모만 잘 정리해 두면 충분할 줄 알았다. 하지만 실제로 필요한 건 문서 보관보다 관계 표현이었다. 어떤 기준이 어떤 프로젝트에 영향을 주고, 어떤 노하우가 어떤 스킬로 구현되며, 어떤 데이터가 어떤 판단으로 이어지는지까지 보여 주는 연결망이 필요했다. 그걸 만들고 나서야 자료가 ‘저장되어 있는 상태’에서 ‘불러와서 판단에 쓰이는 상태’로 넘어가기 시작했다.

기회는 남들보다 먼저 툴을 쓰는 데보다, 남들보다 먼저 자기 세계를 구조화하는 데 있었다

새로운 툴은 결국 많은 사람이 따라온다. 하지만 자기 도메인을 데이터와 기준과 철학까지 포함해서 구조화하는 일은 시간이 오래 걸리고, 그래서 진입 장벽도 꽤 높다. 저는 바로 그 지점에 다음 기회가 있다고 느낀다. 에이전트는 점점 보편화되겠지만, 그 위에 무엇을 얹어 놓았는지는 계속 차별화 요소로 남을 가능성이 크다. 결국 온톨로지는 AI 도구 활용법이 아니라, 내 세계를 시스템으로 옮기는 작업에 더 가깝다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 에이전트의 차이는 모델이 아니라 그 뒤에 붙은 온톨로지의 밀도에서 벌어질 가능성이 크다.

실제로 달라지는 부분: 데이터, 철학, 기준, 관계를 연결하자 응답이 단순 요약에서 실제 의사결정 보조 쪽으로 이동했다.

한 줄 결론: 온톨로지는 AI 시대의 부가 옵션이 아니라, 내 도메인을 오래 살아남게 하는 기반 구조다.
한동안은 에이전트가 전부인 것처럼 보였지만, 지금은 오히려 그 다음 질문이 더 중요하게 느껴진다. 이 에이전트는 도대체 어떤 세계를 알고 움직이는가. 그 질문에 답하는 층이 바로 온톨로지라고 생각한다. 결국 오래 가는 시스템은 연결 수가 아니라 세계 설명력이 좌우할 가능성이 크다.
March 2, 2026
AI 금융 재난, 진짜 무서운 건 분배 문제
▲ 2028년 AI 금융 재난 시나리오를 정리하며 남긴 메모

AI 금융 재난, 진짜 무서운 건 분배 문제

AI 이야기를 하다 보면 대개 효율, 생산성, 기회 같은 단어가 먼저 나온다. 저 역시 한동안은 그쪽에 더 집중했다. 그런데 조금 거리를 두고 보니 다른 그림이 자꾸 보였다. 시스템 전체로는 생산성이 치솟는데, 정작 그 과실이 누구에게 어떻게 분배되는지는 너무 다르게 움직일 수 있다는 점이었다. 숫자만 보면 성장인데 체감은 붕괴에 가까운 상황, 생각보다 그 시나리오가 먼 얘기처럼 느껴지지 않았다.

특히 무서웠던 건 AI가 경제를 키우는 속도와 사람들이 적응하는 속도가 전혀 같지 않을 수 있다는 부분이다. 어떤 곳은 매출과 자산이 팽창하는데 다른 쪽은 일자리와 협상력이 동시에 빠르게 약해질 수 있다. 그러면 표면적으로는 번영인데 밑바닥에서는 불만과 불신이 같이 커진다. 저는 이 간극을 보면서 기술 리스크보다 분배 구조 리스크를 더 먼저 떠올리게 됐다.

“AI 시대의 재난은 기술이 실패해서가 아니라, 성공의 과실이 너무 한쪽으로 쏠릴 때 더 현실적으로 다가올 수 있다.”

– 성장과 체감이 완전히 갈라지는 그림을 상상해 보며 가장 오래 남은 문장이다.

유령처럼 커지는 GDP가 실제 안정으로 이어지지 않을 수 있다

경제 지표가 좋아도 생활의 감각은 훨씬 빠르게 나빠질 수 있다. 생산성과 이익은 늘었는데 고용과 임금의 질이 같이 흔들리면, 사람들은 성장의 숫자를 자기 삶의 개선으로 느끼지 못한다. 이때 문제는 경기침체와 다르다. 겉으로는 잘 돌아가는데 정작 체감은 계속 무너지는 상태가 되기 때문이다. 저는 이 괴리가 커질수록 시장보다 사회 쪽에서 먼저 균열이 터질 가능성이 높다고 느낀다.

일자리 대체보다 더 무서운 건 협상력 붕괴일 수도 있다

모든 직업이 바로 사라지지 않더라도, AI가 대체 가능한 영역이 늘어날수록 개별 노동자의 협상력은 빠르게 약해질 수 있다. 회사는 더 적은 인원으로 더 큰 산출을 만들고, 시장은 그 효율을 보상해 줄 가능성이 높다. 반면 개인은 ‘완전히 대체되지 않았다’는 사실만으로는 예전만큼의 위치를 유지하지 못할 수 있다. 이 흐름이 누적되면 고용 유무보다 더 미묘하고 길게 가는 불안정이 생긴다.

그래서 지금 필요한 건 낙관이나 비관보다 시나리오 감각이었다

AI가 세상을 완전히 망친다고 단정할 필요도 없고, 반대로 다 잘될 거라 믿고 손을 놓을 이유도 없다. 중요한 건 어떤 종류의 충격이 먼저 올 수 있는지 가정해 보는 태도다. 자산 가격, 고용, 정치적 반응, 복지 구조, 교육 전환 같은 영역이 어떻게 연결되는지 미리 그려 보면 대응 방식도 달라진다. 저한테 이 시나리오의 의미는 공포가 아니라, 너무 늦기 전에 분배 문제를 기술 논의 안으로 끌고 들어와야 한다는 경고에 더 가까웠다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: AI 시대의 위기는 기술 실패보다 성장과 분배가 분리되는 데서 더 현실적으로 생길 수 있다.

특히 불안한 지점: 일자리 자체보다 노동자의 협상력과 체감 안정성이 먼저 흔들릴 가능성이 컸다.

한 줄 결론: 지금 필요한 건 막연한 공포가 아니라 성장 숫자 뒤의 분배 구조를 읽는 시나리오 감각이다.
AI를 둘러싼 낙관론과 비관론 사이에서 요즘 제일 자주 붙잡게 되는 건 한 가지다. 결국 누가 얼마나 가져가느냐. 기술은 빨라질 테고 성과도 만들어질 것이다. 그런데 그 성과가 사람들의 삶에 닿지 않는다면, 시장보다 먼저 사회가 그 비용을 치르게 될 수 있다. 그래서 저는 이제 생산성만큼이나 분배 구조를 같이 봐야 한다고 생각한다.
March 2, 2026
OpenClaw는 데이터가 붙을 때부터 달라졌다
▲ OpenClaw를 직접 굴리며 정리한 실전 활용 메모

OpenClaw는 데이터가 붙을 때부터 달라졌다

처음 OpenClaw를 붙여 볼 때만 해도 솔직히 마음이 좀 들떴다. 이것저것 연결해 두고 에이전트를 여러 개 세워 놓으면 갑자기 내 업무가 완전히 다른 방식으로 돌아갈 것 같았거든요. MCP 붙이고, 역할 나누고, 원격으로도 만져 보고, 디스코드 같은 채널까지 연결해 놓으면 이제 뭔가 엄청난 시스템을 갖춘 기분이 든다. 그런데 신기하게도 그 흥분은 오래 안 간다. 조금 지나면 꼭 비슷한 질문 앞에 멈추게 된다. 그래서 이걸로 내 일을 정확히 뭘 바꿀 건데?

겉으로 보기엔 분명 멋지다. 여러 에이전트가 돌아가고, 대화창도 살아 있고, 질문을 던지면 답도 나온다. 그런데 막상 내가 가진 실제 문제를 붙여 보려고 하면 갑자기 힘이 빠진다. 그냥 대답을 잘하는 것과, 내 데이터를 바탕으로 제대로 판단해 주는 건 전혀 다른 문제였기 때문이다. 그때부터 조금 생각이 바뀌었다. OpenClaw의 핵심은 에이전트를 몇 개 띄웠느냐가 아니라, 내가 가진 자료와 맥락을 어디까지 붙여 넣었느냐에 더 가까운 것 같았다.

“에이전트를 만들고 연결하는 건 시작일 뿐이고, 진짜 차이는 그 위에 무엇을 얹느냐에서 벌어진다.”

– OpenClaw를 이것저것 붙여 본 뒤에 가장 또렷하게 남은 감각을 한 문장으로 적으면 대략 이렇다.

여러 에이전트를 세워 보니, 똑똑함보다 관점 분리가 먼저 보였다

처음엔 에이전트를 늘리는 이유를 단순하게 생각했다. 하나보다 셋이 낫고, 셋보다 넷이 낫겠지 하는 식이었다. 그런데 실제로 조금 굴려 보니까 숫자가 중요하다기보다 역할이 중요했다. 재무 쪽으로 보는 시선, 마케팅 쪽으로 보는 시선, 기술 구조를 보는 시선, 실행 흐름을 보는 시선이 분리돼 있을 때 답변의 질이 달라졌다. 하나의 질문을 놓고도 서로 다른 프레임으로 다시 받아보게 되니까, 혼자 머릿속에서 맴돌던 생각이 뜻밖에 정리되는 순간이 있었다.

OpenClaw만 붙여서는 오래 못 간다, 결국은 내 데이터가 있어야 했다

한동안 이것저것 연결만 하다가 어느 순간 딱 막혔다. 질문은 잘 받는다. 요약도 해 준다. 코드도 만져 준다. 그런데 이상하게 ‘내 상황에서 지금 뭐가 제일 중요하지?’ 같은 질문에는 답이 조금 공중에 뜬다. 그때 느꼈다. OpenClaw가 아무리 좋아도, 그 안으로 흘려 넣는 정보가 얕으면 결국 답도 얕아질 수밖에 없다는 걸. 그래서 이후에는 자연스럽게 데이터베이스, 관계 구조, 그래프 형태의 연결 같은 쪽으로 시선이 옮겨 갔다.

결국 다음 단계는 툴 숙련이 아니라 도메인 구조화라는 생각이 들었다

요즘은 에이전트 프레임워크를 잘 연결하는 사람도 많고, 오픈소스를 빨리 따라가는 사람도 많다. 그런데 막상 오래 가는 건 다른 종류의 힘일 수도 있겠다는 생각이 자꾸 든다. 바로 자기 분야를 구조화하는 힘이다. 내가 다루는 산업, 내 고객, 내 프로젝트, 내 기록, 내 판단 기준을 노드와 관계처럼 묶어서 설명할 수 있는 사람. 결국 그런 사람이 OpenClaw 같은 도구를 붙였을 때도 훨씬 깊은 결과를 뽑아낼 가능성이 높다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 에이전트를 많이 세우는 것보다 질문을 서로 다른 관점으로 나눠 받는 구조가 훨씬 중요했다.

막히는 지점: 내 데이터와 작업 흐름이 구조화돼 있지 않으면 OpenClaw도 금방 ‘똑똑한 대화창’ 수준으로 돌아오기 쉽다.

한 줄 결론: OpenClaw의 진짜 활용은 세팅 완료 순간이 아니라, 내 도메인을 붙여서 실제 의사결정 흐름을 만들기 시작하는 순간부터 시작된다.
한동안은 새로운 툴만 잘 잡으면 뭐든 빨라질 줄 알았다. 그런데 OpenClaw를 이것저것 연결해 보고 나니 오히려 반대에 가까운 생각이 들었다. 툴보다 먼저 정리돼야 하는 건 내 쪽이라는 것. 내가 어떤 문제를 풀고 있고, 어떤 데이터가 있고, 어떤 관계가 있고, 어떤 식으로 판단하는 사람인지가 흐릿하면 시스템도 그만큼 흐릿해진다.
March 2, 2026
데이터는 연결될 때 비로소 세계가 됐다
▲ 랭젠트와 그래프 시각화를 붙이며 정리한 데이터 우주 메모

데이터는 연결될 때 비로소 세계가 됐다

자료를 쌓아 두는 데는 익숙했지만, 그 자료들이 서로 어떤 거리를 두고 있는지는 사실 잘 못 보고 있었다. 엑셀, PDF, 코드, 메모, 로그, 공공데이터 같은 것들이 제각각 흩어져 있을 때는 분명 뭔가 많긴 한데, 그 많음이 바로 힘으로 전환되지는 않는다. 저도 한동안은 필요한 순간마다 검색해서 꺼내 쓰는 수준에 머물렀다. 그러다 파일들을 하나의 프레임워크 안에 넣고 시각화해 보니, ‘자료 보관’과 ‘지식 공간’은 전혀 다른 문제라는 게 확실히 보이기 시작했다.

특히 인상적이었던 건 데이터가 별처럼 흩어져 보이면서도, 동시에 군집과 관계가 한눈에 들어오기 시작했다는 점이다. 이건 보기 좋은 시각 효과를 넘어서 생각 구조를 바꾸는 경험에 가까웠다. 그전까지는 문서를 읽고 이해했다면, 그 이후부터는 데이터가 어떤 무리로 모이고 어떤 질문에 반응하는지를 공간감으로 느끼게 됐다.

“자료를 많이 갖고 있다는 사실보다, 그 자료들이 어떤 별자리로 묶이는지 볼 수 있다는 감각이 더 컸다.”

– 데이터를 그래프와 브라우저 시각화로 붙인 뒤 가장 크게 남은 인상이다.

벡터화만으로는 부족했고, 시각화가 붙자 비로소 감이 잡혔다

문서를 임베딩하고 검색하는 것만으로도 유용하지만, 그 상태만으로는 전체 구조가 잘 안 보인다. 반대로 그래프와 시각화를 붙이면 어떤 데이터가 중심에 있고 어떤 데이터가 가장자리로 밀려나 있는지가 직관적으로 보인다. 저는 그 차이가 꽤 컸다. 검색은 답을 찾는 행위였고, 시각화는 내가 어떤 세계를 갖고 있는지 이해하는 행위에 더 가까웠다.

검색어 하나가 별처럼 깜빡이는 순간부터 질문 방식이 달라졌다

예전에는 키워드를 입력하면 목록을 받는 정도였다. 지금은 특정 지역이나 개념을 넣었을 때 관련된 파티클이 어디에서 어떻게 반응하는지를 먼저 보게 된다. 그 시각적 반응 덕분에 질문도 달라졌다. 단순히 ‘무엇이 있나’보다 ‘무엇이 어디에 몰려 있나’, ‘이 군집과 저 군집은 왜 가까운가’ 쪽으로 이동한다. 이건 데이터 활용의 밀도를 분명히 바꾸는 경험이었다.

랭젠트 같은 프레임워크의 가치는 데이터 가공보다 사고 전환에 있었다

파이썬으로 가공하고, 크로마나 네오4j로 묶고, 브라우저로 뿌려 주는 기술 조합 자체도 흥미롭다. 하지만 저한테 더 크게 남은 건 기술의 화려함이 아니라 사고방식의 변화였다. 데이터는 더 이상 파일 모음이 아니고, 질문을 던지면 구조 자체가 반응하는 공간이 됐다. 이 차이 때문에 저는 요즘 데이터 프로젝트를 볼 때도 저장과 검색보다 ‘질문 가능한 우주를 만들고 있는가’를 먼저 보게 된다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 데이터가 힘을 가지는 순간은 많이 모였을 때보다 관계와 군집이 보이기 시작할 때였다.

실제로 달라진 부분: 키워드 검색이 목록 조회에서 공간적 패턴 읽기로 바뀌면서 질문 자체가 더 입체적으로 변했다.

한 줄 결론: 좋은 데이터 프레임워크는 파일을 저장하는 곳이 아니라, 질문하면 구조가 반응하는 우주를 만드는 쪽에 가깝다.
자료를 얼마나 많이 모았는지보다 그 자료를 어떤 세계로 바꾸었는지가 훨씬 중요하다는 걸 이번에 크게 느꼈다. 시각화는 단순한 장식이 아니었다. 내가 가진 데이터의 지형을 보게 만드는 인터페이스였다. 그래서 요즘은 데이터를 정리한다는 말을 들으면, 폴더 정리보다 먼저 세계 만들기 쪽을 떠올리게 된다.
March 2, 2026
네오4j MCP를 붙이니 에이전트가 현실감을 얻었다
▲ 네오4j MCP와 공공데이터를 붙이며 정리한 그래프 RAG 메모

네오4j MCP를 붙이니 에이전트가 현실감을 얻었다

에이전트를 오래 만지다 보면 답변이 그럴듯한 것과 실제 기반이 있는 것은 완전히 다르다는 걸 자주 느끼게 된다. 특히 지역, 업종, 위치, 관계처럼 데이터 구조가 중요한 질문에서는 일반적인 언어 모델 응답만으로는 금방 한계가 드러난다. 저도 그런 이유로 공개 데이터를 직접 붙여 보고 싶었고, 그러다 네오4j와 MCP를 활용한 그래프 구조 쪽으로 자연스럽게 시선이 옮겨 갔다.

공공데이터 포털의 CSV처럼 거대한 원천 데이터를 그냥 파일로 두는 것과, 그것을 노드와 관계로 재정리해 에이전트가 읽을 수 있게 만드는 것은 완전히 다른 단계였다. 후자 쪽으로 넘어가자 데이터가 단순 참고자료가 아니라 실제 판단 기반으로 바뀌기 시작했다. 그때부터는 ‘에이전트가 똑똑하냐’보다 무엇을 근거로 답하고 있느냐가 훨씬 더 중요하게 보였다.

“에이전트의 신뢰도는 문장 품질보다, 그 문장이 어떤 데이터 구조 위에서 나왔는지에 더 많이 걸려 있었다.”

– 공공데이터를 네오4j에 올리고 MCP로 연결한 뒤 가장 크게 느낀 지점이다.

엑셀에 있던 정보는 그래프로 올라가자 비로소 관계를 말하기 시작했다

CSV 상태에서는 상호명, 위치, 업종, 좌표가 길게 늘어선 행 데이터에 가깝다. 그걸 네오4j로 올리면 이야기가 달라진다. 구, 업종, 매장, 위치 같은 요소가 노드와 관계로 분리되면서 ‘무엇이 어디에 속하고 무엇과 이어지는지’가 한눈에 드러난다. 저는 이 차이가 단순한 저장 방식의 변화가 아니라, 질문 가능한 데이터로 넘어가는 핵심 전환처럼 느껴졌다.

MCP가 붙으니 데이터베이스가 에이전트 작업 흐름 안으로 들어왔다

그전까지 데이터베이스는 따로 열어 보고, 분석은 별도로 하고, 결과만 다시 가져오는 식이었다. 그런데 MCP로 연결해 두니 에이전트가 필요한 순간에 직접 그 구조를 활용하게 된다. 이 흐름이 주는 장점은 단순 편의성보다도 맥락 유지에 있다. 질문, 조회, 관계 파악, 추가 가공이 한 흐름 안에서 이어지니 답변의 밀도가 확실히 달라졌다.

그래프 RAG는 속도보다 관계 이해에서 진가가 드러났다

물론 필요한 데이터를 빨리 찾는 것도 장점이다. 하지만 제가 더 크게 본 건 관계 해석이었다. 특정 구 안의 특정 업종을 찾는 정도를 넘어, 어떤 업종이 어떤 분포를 보이고 어떤 주변 정보와 엮이는지까지 훨씬 자연스럽게 읽힌다. 그래서 그래프 RAG는 검색 최적화 기술이면서 동시에, 에이전트가 세상을 평면이 아니라 연결망으로 이해하게 만드는 방식이라고 느꼈다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 에이전트가 현실감 있는 답을 하려면 결국 신뢰 가능한 데이터 구조가 필요했다.

실제로 좋아진 부분: 엑셀 데이터가 네오4j 그래프로 올라가자 관계 중심 질의와 지역 분석이 훨씬 자연스러워졌다.

한 줄 결론: 그래프 RAG는 단순 검색 보강이 아니라, 에이전트가 세상을 관계로 읽게 만드는 기반층이다.
이후로는 AI 에이전트를 볼 때도 프롬프트보다 데이터 흐름을 먼저 확인하게 된다. 어떤 DB를 붙였는지, 관계를 어떻게 표현하는지, 조회가 어떤 워크플로로 이어지는지가 더 중요하다. 결국 믿을 수 있는 응답은 잘 꾸민 문장에서 오지 않고, 잘 정리된 데이터 구조에서 나온다고 생각한다.
March 2, 2026
모델보다 작업 환경이 더 중요해진 순간
▲ Opus와 Codex를 비교하며 정리한 워크스페이스 변화 메모

모델보다 작업 환경이 더 중요해진 순간

새 모델이 나오면 당연히 성능부터 보게 된다. 저도 처음에는 Opus와 Codex 같은 이름 앞에서 어떤 쪽이 더 세고 더 영리한지부터 궁금했다. 그런데 실제로 써 본 뒤에 오래 남는 건 숫자 차이보다 환경 차이였다. 같은 모델이라도 어떤 UI와 워크스페이스 안에서 돌아가느냐에 따라 체감이 완전히 달라지기 때문이다. 특히 코드와 파일과 히스토리와 자동화가 한 화면에서 엮일 때, ‘채팅형 AI’와 ‘작업 환경형 AI’는 전혀 다른 도구처럼 느껴졌다.

그래서 요즘은 새 모델 평가를 할 때도 단순 벤치보다 그 모델이 어떤 작업 공간을 제공하는지 같이 본다. 워크스페이스를 나누고, 파일 변화를 추적하고, 자동화를 걸고, 스킬을 붙이는 흐름이 갖춰지면 모델 성능 이상의 차이가 생긴다. 제 체감으로는 지금 변화의 핵심이 모델 우열보다 AI가 일하는 자리 자체가 바뀌고 있다는 점에 있었다.

“새 모델이 좋다는 감각보다 먼저 온 건, 이제 AI가 채팅창을 넘어 작업 환경 전체로 번지고 있다는 감각이었다.”

– Codex 앱과 기존 워크스페이스형 도구들을 같이 놓고 써 본 뒤 가장 오래 남은 생각이다.

UI가 직관적이면 진입 장벽 자체가 달라진다

VS Code나 터미널 환경에 익숙한 사람에게는 워크스페이스 기반 도구가 자연스럽다. 하지만 그렇지 않은 사람에게는 같은 기능도 훨씬 어렵게 느껴진다. 이때 Codex처럼 파일 트리, 대화, 변경 이력을 한 화면에서 직관적으로 보여 주는 UI는 생각보다 큰 차이를 만든다. 기능의 절대량보다 사용자가 구조를 이해할 수 있게 만드는 방식이 훨씬 중요하게 보였다.

모델 경쟁은 계속되겠지만, 실제 차이는 오케스트레이션에서 더 벌어질 수 있다

Opus가 좋아졌고 Codex가 좋아졌다는 얘기는 계속 나오겠지만, 실무에서는 한 모델의 우세보다 여러 도구를 어떻게 엮어 쓰느냐가 더 크게 느껴질 때가 많다. 워크스페이스, 서브 에이전트, 스킬, MCP, 자동화 같은 층이 붙으면 모델 하나의 능력치보다 훨씬 큰 차이를 만든다. 그래서 저는 이제 모델 교체보다 작업 환경 설계 쪽을 더 길게 본다.

채팅형 AI에서 업무 환경형 AI로 이동하는 흐름이 선명해졌다

파일을 열고, 커밋을 보고, 자동화를 만들고, 특정 작업을 주기적으로 돌리는 흐름이 자연스럽게 붙는 순간부터 AI는 더 이상 질문 응답기가 아니다. 그때부터는 업무 환경의 일부가 된다. 저는 이 변화가 꽤 중요하다고 본다. 앞으로는 모델 이름 하나보다, 어떤 작업 환경 위에서 어떤 구조로 돌고 있는지가 더 큰 경쟁력이 될 가능성이 크기 때문이다.
직접 만져 보고 남은 정리

가장 크게 느낀 점: 모델 성능 향상보다 AI가 들어오는 작업 환경 자체가 바뀌고 있다는 점이 더 크게 다가왔다.

실제로 중요했던 요소: UI 직관성, 워크스페이스 관리, 파일 히스토리, 자동화 같은 요소가 체감 차이를 크게 만들었다.

한 줄 결론: 앞으로의 차이는 모델 하나의 우열보다, 그 모델이 어떤 업무 환경 안에서 오케스트레이션되는가에서 더 크게 벌어질 수 있다.
새 모델이 나올 때마다 숫자 경쟁은 계속될 것이다. 하지만 실제로 오래 남는 건 그 모델을 어디에서 어떻게 쓰게 되는가 하는 경험 쪽일 가능성이 크다. 저는 그래서 이제 성능표보다 환경 변화를 더 주의 깊게 본다. AI는 점점 답변을 잘하는 쪽이 아니라, 일을 하게 되는 쪽으로 이동하고 있다고 느낀다.
March 2, 2026