4/11/2026

AI를 쓰고 있는데, 왜 바뀌지 않을까?

Written by Giljae Joo(주길재) in AI, Harness Engineering with 댓글 없음

Man On Arrow
Photo by Smart on Unsplash

현재 AI를 쓰지 않는 조직은 거의 없다. 레포트에 따르면 약 88%의 기업이 최소 한 개 이상의 업무에 AI를 활용하고 있다고 한다.

하지만 질문을 하나 던져보면 답이 달라진다.

"그 AI가 조직의 결과를 바꿨는가?"

또 다른 연구에서는 기업의 생성형 AI 프로젝트 중 95%가 실제 성과에 영향을 주지 못했다고 한다. 이건 기술 문제가 아니다.

AI는 이미 작동하고 있다.
작동하지 않는 것은 조직이다.

실패의 본질 - 우리는 AI를 "도입"하고 있다.

AI 프로젝트 실패율은 자료마다 다르지만, 대략 70% ~ 95% 수준이라는 공통된 범위가 나온다.
이 숫자의 핵심은 실패율이 아니라 "실패 이유"이다.
대부분의 실패 원인은 다음과 같다.

기술 문제 X
조직 문제 O

연구에 따르면 AI 실패의 63%는 기술이 아니라 인간, 조직 요인에서 발생한다. 여기서 중요한 차이가 하나 나온다.

도입 vs 전환

도입: AI 도구를 업무에 추가
전환: 업무 자체를 다시 설계

문제는 대부분의 기업이 전환이 아니라 도입을 하고 있다는 점이다.

AX팀 패러독스 - 전환을 하겠다고 하면서 더 멀어진다.

FLowkater 블로그의 "AX Team Paradox" 글에서 매우 중요한 통찰이 하나 제시된다.

AX팀을 만드는 순간, AX는 실패한다.

위 문장은 과장처럼 보일 수 있지만 구조적으로 보면 맞다고 생각된다. 이유는 단순한다.

AX의 본질은:

의사결정 -> 실행 간 거리 축소
중간 레이어 제거

그런데 아래의 조직을 만든다:

AX팀
AI TF
전환 조직

즉, 단순한 실행 문제를 넘어서 구조적 모순이다라는 점이다.

계층을 줄여야 하는데
계층을 하나 더 추가하는 모양새다.

개인은 변했지만 조직은 변하지 않았다.

현재 기업에서 실제로 일어나는 변화는 대부분이 아래 수준이다.

개발자 -> Claude Code, Cursor, Codex 등 사용
마케터 -> GPT 사용
기획자 -> AI 리서치 사용

즉, 개인 생산성은 올라간다.

하지만 조직 수준에서는:

승인 프로세스 변화 없음
핸드오프 변화 없음
KPI 변화 없음

결과적으로 "고도화된 각자도생" 상태가 된다.

이건 MacKinsey 레포트와도 정확하게 일치한다.

AI 성과를 내는 기업은 워크플로우를 재설계한다.

왜 조직은 바뀌지 않는가?

AI 전환이 어려운 이유는 크게 3가지라고 본다.

조직 구조의 문제

기존 조직은 역할 기반이다.

PM
기획
개발
QA
운영 등

AI는 위 구조를 무너뜨린다. 한명이 기획 -> 개발 -> 테스트를 수행할 수 있게 만든다.
하지만 조직은 그대로 유지된다.

결과적으로 AI는 도입했지만, 병목은 그대로 유지된다.

정체성의 문제

AI 전환은 단순한 생산성 문제가 아니다.

"나는 개발자다"
"나는 기획자다"

이 정체성이 흔들린다. 그래서 서로 가지 않았던 영역을 걸어가야 한다고 가이드하고 있다.
즉, AI는 업무를 바꾸는 것이 아니라, 사람의 역할을 재정의한다.

시스템의 문제 (하네스 부재)

현재 대부분의 기업은 여러 AI 도구를 가지고 있다. 그러나 없는 것이 있다. (물론 있는 기업도 있다.)

"어떻게 같이 일하게 할 것인가?"

이게 바로 하네스(Harness) 문제다.

전환의 본질 - 조직을 다시 설계하는 것

McKinsey에서는 이 문제에 대해 이야기한다. "AI 경쟁력은 기술이 아니라 어떻게 적용하느냐에서 나온다." 그리고 가장 중요한 요소는 "워크플로우 재설계"라고 언급한다.

즉, AI는 기능 자동화 기술이 아니라 조직 구조를 바꾸는 도구다.

새로운 운영 모델

AI 전환의 끝에는 완전히 다른 조직 형태가 나온다. 그 특징은 아래와 같다.

역할 중심 -> 결과 중심
부서 중심 -> 문제 중심
사람 중심 -> 사람 + AI Agent 협업

그리고 가장 중요한 변화는.,

"팀"의 정의가 바뀐다.

단순한 자동화가 아니라 조직 단위 자체의 변화다.

핵심 매커니즘 - 하네스 엔지니어링

AI 전환의 핵심은 모델이 아니다. 물론 모델도 중요하다. 하지만 모든 작업에 동일한 모델을 사용하지 않을 것이다. 이것만큼 비효율은 없으니까...

Orchestration

그래서 하네스 엔지니어링이 필요하다. 구성 요소는 다음과 같다.

역할 정의 (Agent)
워크플로우
메모리
피드백 루프

Zero Human Company - 전환의 끝

AI 전환의 궁극적인 형태는...

사람은 실행하지 않는다.
사람은 설계한다.

즉,

"운영하는 회사" -> "설계하는 회사"

위 개념은 아직 극단적으로 보이지만, 이미 일부 영역에서는 현실이 되고 있다.

실행 전략 - 어떻게 시작할 것인가?

현실적인 전략은 다음에 언급하는 네 가지이다.

AX팀을 만들지 말 것

별도 조직을 만들지 말고, 기존 조직 내에 embedding 해야 한다.

도구가 아니라 워크플로우 설계

AI 도구 도입이 우선시 되는 것이 아니라, End-to-End를 AI기반으로 설계해야 한다.

개인 자동화에서 조직 자동화로

개인 생산성은 이미 어느정도 올라가 있다. 이것을 조직 구조 변화로 확장해야 한다.

역할을 다시 정의

하나의 질문을 해보자.

"AI가 60%를 하면, 남은 40%는 무엇인가?"

마무리

AI는 이미 충분히 발전했다. 문제는 기술이 아니라고 생각한다.

AI는 도입하는 순간 실패하고, 조직을 다시 설계하는 순간 시작된다.

위 차이를 이해하는 것과 이해하는 못한 상황의 격차는 앞으로 훨씬 더 벌어질 것이다.

References:

모델이 읽는 쓰레기 줄이기

Written by Giljae Joo(주길재) in AI, Compression, RTK with 댓글 없음

요즘 팀내에서 토큰 부족 현상이 자주 발생한다.

Budget을 무한정 투입할 수 없는 상황이라 여러 고민을 하던 중, Github에 꽤 괜찮은 Repo가 있는 것을 발견했다. 팀에 내용을 공유하고 여기에 정리해본다.

A close up of a thermometer and a hose
Photo by camera obscura on Unsplash

AI 코딩 도구를 처음에 쓸땐 대부분 감탄한다. 코드를 읽고, 테스트를 수행하고, 수정안을 내놓는 속도가 생각보다 빠르다. 사람보다 빠르다는 말이 과장이 아닐 때도 있다.

그러나 오랫동안 붙잡고 있으면 문제가 나타난다. 대화가 길어질수록 에이전트가 점점 이상해진다. 방금 전까지 이해하던 문맥을 놓치고, 이미 확인한 내용을 다시 확인하고, 중요하지 않은 로그에 매달린다. 모델이 멍청해졌다기보다는 모델이 읽는 환경이 나빠졌다고 봐야한다.

RTK는 이런 문제를 해소하기 위해 등장했다. 공식 설명은 단순하다.

CLI 출력이 LLM의 context window에 들어가기전에 필터링하고 압축하는 CLI Proxy이다.

즉, 모델을 바꾸는 도구가 아니라, 모델에게 들어가는 입력의 형태를 바꾸는 도구다. CLI noise를 줄여 더 나은 reasoning, 더 긴 세션, 더 낮은 비용을 만들기 위함히다.

우리는 종종 더 큰 모델, 더 긴 컨텍스트, 더 좋은 에이전트를 원한다. 하지만 실제 사용에서 문제가 되는 것은 모델의 지능이 아니라 입력의 질이다. 지나치게 장황한 git diff, 쓸모없는 pass log로 가득한 cargo test, 사람이 터미널에서 볼 때는 무해하지만, 모델에게는 비용과 혼란만 남기는 출력들... RTK는 이 문제를 아래와 같이 접근한다.

모델이 읽는 터미널은 아직도 인간용으로 설계되어 있다.

공식 사이트를 보면 숫자가 매력적이다. 평균 89%의 노이즈 제거, 3배 더 긴 세션을 언급한다. 대체로 큰 폭의 출력 압축을 지향하지만 수치는 커맨드와 환경에 따라 다르다고 인지해야 한다.

RTK의 구조는 생각보다 단순하다. Github 아키텍처 문서를 보면 이 도구는,

특정 커맨드를 감지하고
원래 커맨드를 실행한 뒤
stdout/stderr를 캡쳐하고
커맨드 종류에 맞는 필터를 적용하고
더 짧은 형태로 다시 출력한다.

즉, RTK는 커맨드별 규칙 기반 압축기이다. 단순해서 신뢰가 간다. 모델이 요약하는 구조가 아니라, 개발 도구의 출력 형식을 사람이 이해 가능한 규칙으로 재구성하는 쪽에 가깝기 때문이다.

그렇다고 RTK를 단순한 "토큰 절약기"로만 보는 것은 이 도구의 확장성 관점에서 아깝다. RTK는 LLM용 인터페이스 레이어라고 볼 수 있다.

우리가 사용하는 CLI는 원래 인간을 위한 인터페이스다. 행 단위로 길게 출력하고, 강조를 위해 반복하고, 상태를 친절하게 설명하고, 때때로 인테리어 장식도 넣는다. 그중 사람은 필요한 것만 골라서 본다.

반면 대부분 LLM의 경우는 사람처럼 골라보지 못한다. 읽을 수 있는 것은 읽고, 읽은 것은 비용이 되고, 비용은 곧 컨텍스트 오염이 된다. RTK는 이 오래된 CLI를 LLM 친화적으로 번역한다. 같은 사실을 더 짧고 구조적으로 표현하는 것이다.

이 아이디어는 생각보다 큰 의미를 가진다. AI 시대에 경쟁력이 모델 그 자체에서만 생기는 것이 아니라, 모델이 무엇을 어떤 형태로 읽게 하느냐에서 생길 수 있단느 점을 보여주기 때문이다.

물론, 모든 컨텍스트 문제의 해결사는 아니다. Shell 출력이라는 오염원 하나를 잘라내는 도구로 봐야 한다. 그러나 이것만 해도 꽤 큰 오염원 제거이다. 현실의 생산성 도구는 대체로 이렇게 부분적인 문제를 해결해나가기 때문이다.

이제까지 살펴본 바로는 이 프로젝트는 "더 똑똑한 모델"을 포커싱하는 것이 아니라, "더 적절한 입력"을 문제의 중심에 놓고 있다. 지금까지 AI 도구 시장은 주로 모델 교체를 경쟁처럼 진행되었다. GPT가 좋냐, Claude가 좋냐, Gemini가 좋냐 등... 그런데 현장에서는 종종 더 하위 레이어가 중요하다. 파일을 어떻게 읽히게 할 것인가, 테스트 결과는 어디까지 보여줄 것인가, diff를 어떤 단위로 잘라줄 것인가, 이런 문제들은 모델의 IQ보다 입구의 형식과 더 가깝다. RTK는 이 문제에 접근해서 풀어냈다.

이미 있는 모델이 쓸데없는 것을 덜 읽게 만든다.

이것은 화려하진 않지만 대단히 실용적이다.

그런데, 불편한 점도 존재한다. 압축은 trade-off다. 출력이 짧아진다는 것은 토큰 낭비를 덜한다는 점에서 좋아보이지만, 어떤 상황에서는 정보 손실이 될 수 있다. 상황에 따른 호불호가 있다고 생각된다. 그래서 RTK에서는 언제 압축하고 언제 원본으로 돌아갈지를 사용자가 통제할 수 있게 하였다.

이 프로젝트는 단순한 유틸리티로 볼 수도 있다. 하지만 AI Native 개발 환경 관점에서 보면 느낌이 다르다.

모델은 두뇌이고, RTK와 같은 도구는 감각을 정리하는 장치다.

두뇌를 키우는 일만큼, 들어오는 감각을 정제하는 일도 중요하다는 것을 이 도구가 보여주기 때문이다.

결국 RTK가 던지는 질문은 단순하다.

정말 필요한 것은 더 큰 모델일까? 아니면 더 깨끗한 입력일까?

아마도 답은 둘 다일 것이다. 그러나 현장에서는 두 번째가 더 중요하다. 더 큰 모델은 비싸고, 느리고, 언제나 접근 가능하지 않기 때문이다. 반면 입력을 정리하는 일은 상대적으로 싸고, 빠르고, 바로 적용이 가능하다. 이 작은 도구는 거대한 AI 혁신처럼 보이지는 않지만, 실제 사용 경험의 병목을 직접 건드린다.

"LLM이 읽는 모든 것을 더 많이 넣자!"는 방향이 아니라, "LLM이 읽을 가치가 없는 것을 빼자!"는 방향을 선택한다.

이 프로젝트가 의미 있다고 보는 이유는, 문제를 정확히 문제로 본다는 데 있다. AI 코딩의 병목은 모델안에만 있지 않다. 종종 모델 바깥, 터미널의 지저분한 출력과 도구 체인에 있을 수 있다.

즉, "AI가 일하는 환경을 인간 중심 인터페이스에서 기계 중심 인터페이스로 번역하려는 시도다."

나는 이런 종류의 시도가 앞으로 더 많아질 것이라고 본다. 모델이 좋아질수록, 오히려 모델 앞단의 정제 레이어가 더 중요해질 가능성이 크기 때문이다.

지금 이 모델은, 무엇을 읽고 있는가?

References:

Unlearning - 배운 것 중 필요없는 것을 버리는 능력

Written by Giljae Joo(주길재) in Unlearning with 댓글 없음

If you use this image, we’d appreciate a link back to our website www.quotecatalog.com.
Photo by Thought Catalog on Unsplash

우리는 그동안 지식, 경험, 확신을 계속 쌓아왔다. 더 많이 알고, 더 정교한 프레임을 갖고, 더 많은 경험을 쌓는 사람이 결국 더 멀리 간다고 생각했다.

실제로 그동안 역사에서 그것은 맞는 말이었다. 산업화 시대에도 그랬고, 디지털 전환 초반에도 그랬다. 문제는 지금이다. 지금은 많이 아는 사람이 아니라, 무엇을 계속 붙잡고 있는지 스스로 의심할 수 있는 사람이 더 멀리 간다. 새로운 것을 배우는 능력보다, 한때 나를 성공시켰던 방식을 내려놓는 능력이 더 중요해진 시대다.

경영학에서 이 문제를 오래전부터 다뤄온 개념이 바로 organizational unlearning이다. 고전적으로는 Hedberg가 조직이 학습할 뿐 아니라 “기존의 이해와 방식을 벗어나는 과정”도 필요하다고 보았고, 이후 연구들은 이를 조직 변화의 핵심 주제로 확장해 왔다.

대부분 unlearning을 “잊는 것” 정도로 이해한다. 하지만 연구자들은 대체로 그렇게 보지 않는다. 최근 리뷰들은 unlearning을 단순한 망각이 아니라, 더 이상 적합하지 않은 지식/루틴/기억 구조를 의도적으로 약화시키거나 버리는 과정으로 정리한다.

이 차이는 생각보다 중요하다. 그냥 시간이 흘러서 잊어버리는 것은 forgetting에 가깝다. 하지만 “이 방식은 더 이상 맞지 않는다”는 판단 아래 기존의 신념, 관행, 규칙, 평가기준을 흔들고 재배치하는 것은 unlearning에 가깝다.

다시 말해 unlearning은 기억의 자연 소멸이 아니라, 판단 체계의 의도적 수정이다. 그래서 이 개념은 개인보다도 조직 변화, 혁신, 전략 전환, 리더십, 팀 실험과 더 자주 연결된다.

이 지점에서 Chris Argyris의 double-loop learning은 여전히 유효하다. Argyris는 조직이 오류를 수정하는 데에도 두 단계가 있다고 봤다.

하나는 기존 목표와 규칙을 그대로 둔 채 그 안에서 오차를 고치는 방식이고, 다른 하나는 아예 그 목표와 규칙 자체, 즉 “governing variables”를 다시 묻는 방식이고, 이것이 double-loop learning이다.

이 개념은 unlearning과 동일하지는 않지만, 실제 조직에서 unlearning이 일어나는 방식과 깊게 닿아 있다. 왜냐하면 기존의 운영 변수와 기준을 바꾸지 않으면, 새로운 학습은 대부분 낡은 프레임 안에 흡수되기 때문이다. 결국 무언가를 새로 배우는 일보다 먼저 필요한 것은, 지금의 기준이 여전히 맞는지를 묻는 일이다.

그래서 unlearning은 학습의 반대말이 아니다. 정확하게 말하면, 제대로 배우기 위해 필요한 해체 과정에 가깝다. 조직은 흔히 새로운 시스템을 도입하고, 새로운 도구를 교육하고, 새로운 KPI를 붙이면 변화가 일어난다고 생각한다. 하지만 현실에서는 새 제도가 들어와도 사람들은 예전 방식으로 해석하고 예전 방식으로 사용한다.

그래서 AI를 도입해도 구조는 쉽게 바뀌지 않는다. 승인 체계는 그대로 남고, 보고 방식도 달라지지 않는다. 클라우드로 옮겨도 온프레미스 시절의 의사결정 속도와 통제 습관이 그대로면 혁신은 지연된다. 애자일을 선언해도 실패를 허용하지 않는 평가 체계가 유지되면 팀은 더 자주 회의할 뿐 덜 실험하지는 않는다. 최근 연구들이 unlearning을 개인, 팀, 조직의 여러 수준에서 동시에 봐야 한다고 강조하는 이유가 여기에 있다.

이제 왜 지금 unlearning이 중요한지 생각해볼 필요가 있다.

첫째는 환경 변화의 속도 때문이다. 과거에는 한번 익힌 지식의 유효기간이 꽤 길었다. 제품 사이클도 길었고, 조직 구조도 비교적 천천히 변했다. 하지만 지금은 시장, 기술, 규제, 고객 기대가 동시에 빠르게 바뀐다.

최근 리뷰들은 조직 기억이 개인 기억, 팀 기억, 루틴과 관행, 디지털 저장소까지 여러 레이어위에 저장된다고 설명하는데, 문제는 이 기억 구조가 환경 변화보다 느리게 움직인다는 점이다. 조직은 늘 이미 지나간 현실에 맞춰 최적화되어 있기 쉽다. 이럴 때 필요한 것은 추가 학습보다 현재를 더 이상 설명하지 못하는 기억 구조를 약화시키는 일이다.

둘째는 AI 시대의 아이러니 때문이다. 많은 사람이 AI 시대를 “배움이 쉬워진 시대”로 말한다. 분명 맞는 말이다. 정보 접근 비용은 낮아졌고, 코드 작성, 문서 초안, 자료 조사, 번역, 요약 같은 지식노동의 진입장벽은 빠르게 내려가고 있다.

그래서 무엇을 새로 배우느냐보다 어떤 프레임으로 질문하느냐가 더 중요해졌다. 기존 방식대로 질문하면 기존 방식대로 답을 얻는다. 기존 조직 논리 안에서 AI를 배치하면 AI는 혁신 엔진이 아니라 자동화된 보조 인력으로 축소된다. 이때 필요한 것은 “AI를 배우자”라는 구호가 아니라, “우리가 일을 정의하는 방식부터 다시 볼 수 있는가”라는 질문이다. 이것은 기술 도입의 문제가 아니라 unlearning의 문제다.

unlearning이 어려운 이유는 아래와 같다.

첫째, 사람은 자신이 틀렸다는 사실보다 자신이 틀릴 수 있다는 사실을 견디기 어려워한다. 오래 써온 개념, 익숙한 루틴, 성과를 냈던 프레임은 단순한 지식이 아니라 정체성의 일부가 된다. 그래서 unlearning은 정보 업데이트보다 훨씬 불편한 경험이다.

둘째, 조직 차원에서는 성과평가와 보고체계가 이를 더 어렵게 만든다. 조직은 예측 가능성과 반복 가능성을 좋아한다. 반면 unlearning은 대체로 불확실성과 실험, 일시적 혼란을 수반한다.

셋째, 성공 경험이 강할수록 더 버리기 어렵다. 실패한 방식은 쉽게 버릴 수 있지만, 성공한 방식은 마지막까지 남는다. 바로 이 때문에 많은 기업이 위기 때보다 호황기 말기에 더 취약하다.

unlearning은 종종 도전(challenge)으로 시작된다. 여기서 challenge는 단순한 반항이 아니다. 지금의 질서, 지금의 설명, 지금의 성공 공식을 다시 질문하는 과정이다. 무엇이 당연한가를 묻는 순간, 조직은 비로소 현재를 현재의 언어로 보기 시작한다. 어떤 사람의 생각이 바뀌는 것만으로는 unlearning이 완성되지 않는다. 기준, 프로세스, 루틴, 자원 배분, 승인 구조가 함께 바뀌어야 한다.

그렇다면 실무에서 unlearning은 어떻게 일어나는가? 나는 이것을 세 단계로 설명하는 편이 가장 현실적이라고 본다.

첫 번째는 인식이다. 지금의 문제가 실행력 부족인지, 아니면 전제 자체가 낡았는지 구분해야 한다. 대부분의 조직은 낡은 프레임의 문제를 실행의 문제로 오해한다. 고객 반응이 달라졌는데 메시지의 빈도를 높이거나, 제품 구조가 바뀌었는데 보고 횟수를 늘리거나, 전략의 전환이 필요한데 예전 KPI를 더 엄격히 적용한다. 이 단계에서 필요한 질문은 단순하다.

“우리는 무엇을 너무 당연하게 여기고 있는가?”

두 번째는 분리다. 낡은 지식이 사람의 능력 부족 때문인지, 루틴 때문인지, 제도 때문인지 떼어서 봐야 한다. 조직 기억은 개인 기억만이 아니라 팀 기억, 루틴과 관행, 디지털 저장소에 분산되어 있다. 그래서 unlearning은 교육만으로 해결되지 않는다. 사람은 바뀌었는데 회의체가 안 바뀌면 예전 방식이 돌아오고, 프로세스가 바뀌었는데 데이터 정의가 안 바뀌면 같은 판단이 반복된다. 시스템 차원에서 무엇이 기존 질서를 지탱하는지 분리해 보지 않으면, 조직은 늘 “새로운 언어로 옛날 일”을 하게 된다.

세 번째는 대체다. 버리는 것만으로는 조직이 움직이지 않는다. 기존 신념과 관행을 제거한 자리에 새로운 해석과 루틴이 들어와야 한다. 새로운 제도가 실제로 반복되고 저장되는 구조를 만드는 일이다. 결국 조직은 기억하는 방식대로 움직이기 때문이다.

unlearning을 정말 쓰고 싶다면, 막연히 “과거를 버려야 한다”는 선언이 아니라 무엇이 어떻게 약화되었는지?, 무엇이 대체되었는지?, 그 변화가 실제 루틴과 의사결정에 어떻게 남았는지를 보여줘야 한다. 그렇지 않으면 unlearning은 그냥 멋있는 단어에 그친다.

실무에서 unlearning을 판단하는 가장 현실적인 기준은 이것이다.

새로운 도구를 도입했는가? 가 아니라, 옛 판단 기준이 약해졌는가?
새로운 조직도를 만들었는가? 가 아니라, 예전 승인 구조가 실제로 덜 중요해졌는가?
AI를 붙였는가? 가 아니라, 사람이 직접 해야 한다고 믿었던 일의 경계가 다시 그어졌는가?
데이터를 쌓았는가? 가 아니라, 직관이 아니라 실험으로 결론 내리는 비율이 높아졌는가?

이 질문들에 “그렇다”고 답할 수 있을 때 비로소 unlearning은 시작된 것이다.

그래서 나는 unlearning을 혁신의 부속 개념으로 보지 않는다. 오히려 혁신의 앞단에 놓인 조건이라고 본다. 많은 조직이 transformation을 말하지만 실제로는 기존 운영 모델을 조금 더 디지털화하는 데 그친다.

이유는 단순하다. 학습은 했지만 unlearning은 하지 않았기 때문이다. 기존의 권한 구조, 성공 공식, 리스크 정의, 고객 이해 방식이 그대로면 혁신은 반드시 기존 질서의 범위 안으로 흡수된다. 결국 “새로운 것을 받아들일 준비”보다 더 중요한 것은 “기존 것을 의심할 준비”다. unlearning은 개인의 태도 변화로 끝나지 않고, 전략적 유연성, 혁신, 조직 성과와 연결될 가능성이 있지만, 그 효과는 언제나 맥락과 구조를 탄다.

결국 unlearning은 많이 배운 사람에게 더 어려운 일이다. 많이 아는 사람은 더 많은 설명을 가지고 있고, 더 많은 성공 경험을 가지고 있으며, 더 많은 정당화를 할 수 있다. 그렇기에 배움의 총량이 많은 사람이 반드시 변화에 강한 것은 아니다. 때로는 반대다. 진짜 유연한 사람은 많이 아는 사람이 아니라, 자신의 지식이 언제 낡아지는지 감지할 수 있는 사람이다. 조직도 마찬가지다. 더 많은 시스템을 가진 조직이 강한 것이 아니라, 그 시스템을 언제 내려놓아야 하는지 아는 조직이 강하다.

지금 시대에 learning은 기본 역량이 되었다. 누구나 배울 수 있고, 도구도 많고, 접근도 빠르다. 차이를 만드는 것은 그다음이다. 무엇을 더 추가하느냐보다, 무엇을 계속 들고 가지 않느냐가 더 중요해졌다. 그래서 앞으로의 경쟁력은 지식의 축적량만으로 설명되지 않을 것이다. 본 글에서 하고 싶은 이야기는 아래의 문장으로 정리된다.

"우리는 계속 배우고 있다. 문제는, 무엇을 아직도 버리지 못하고 있는가다."

Refercences:

Bo Hedberg, How Organizations Learn and Unlearn (1981). (Semantic Scholar)
Chris Argyris, Double-Loop Learning in Organizations (1977). (Antonie van Nistelrooij)
Adrian Klammer et al., Organizational unlearning as a process: What we know, what we don’t know, what we should know (2024). (ResearchGate)
Samuele Maccioni et al., Navigating the unlearning landscape: an organizational unlearning taxonomy and an outcome-centric model (2024). (Emerald)
Annette Kluge, Recent findings on organizational unlearning and intentional forgetting research (2019–2022) (2023). (Frontiers)
Adrian Klammer & Stefan Gueldenberg, Unlearning and forgetting in organizations: a systematic review of literature (2019). (Emerald)
John Howells & Joachim Scholderer, Forget unlearning? (2016). (Sage Journals)

gstack을 Antigravity로 포팅

Written by Giljae Joo(주길재) in Antigravity, gstack, porting with 댓글 없음

AI 코딩 도구를 쓰다 보면 비슷한 순간이 온다.

처음에는 “정말 똑똑하네”에서 시작한다.
그다음에는 “이걸 어떻게 더 잘 시킬까?”로 넘어간다.
그리고 조금 더 쓰다 보면 결국 이런 고민을 하게 된다.

이걸 팀처럼 일하게 만들 수는 없을까?

내가 gstack에 관심을 가진 이유도 여기에 있었다.

gstack은 스스로를 단순한 스킬 모음이 아니라, Claude Code를 하나의 가상 엔지니어링 팀처럼 움직이게 만드는 방식으로 설명한다.

CEO, 엔지니어링 매니저, 디자이너, 리뷰어, QA 리드, 보안 담당, 릴리즈 엔지니어 같은 역할이 나뉘어 있고, 전체 흐름이 Think → Plan → Build → Review → Test → Ship → Reflect로 설계되어 있다.

즉, 핵심은 프롬프트 몇 개가 아니라 역할 분리와 작업 순서에 있다.

요즘 AI 도구들은 대부분 “잘 대답하는가?”에 초점이 맞춰져 있다. 그런데 gstack은 한 걸음 더 들어가서 “어떤 순서로 일하게 만들 것인가”를 다룬다.

`/office-hours`로 문제를 다시 정의하고,
`/plan-ceo-review`와 `/plan-eng-review`로 범위와 구조를 다듬고,
`/review`, `/qa`, `/ship`으로 마무리하는 흐름은 실제 팀이 일하는 방식과 꽤 닮아 있다.

그래서 gstack을 처음 봤을 때 든 생각은 신기하다보다 이건 실무에 더 가깝다는 쪽이었다.

그런데 여기서 다음 질문이 생겼다.

좋은 건 Claude Code 자체일까, 아니면 gstack의 워크플로우일까?

gstack은 Claude Code 중심으로 설계돼 있다.

설치 구조도 Claude 체계를 전제로 하고 있고, 브라우저 자동화 역시 자체 browse 흐름을 기준으로 설명한다.

ARCHITECTURE 문서에서는 persistent browser와 long-lived Chromium daemon을 유지해서 첫 호출 이후에는 빠르게 재사용하고, 세션과 탭 상태도 이어가는 방식이라고 설명한다.

즉, 원본 gstack은 단순한 명령어 모음이 아니라 브라우저 기반 검증과 리뷰까지 포함한 일종의 소프트웨어 팩토리에 가깝다.

그래서 Antigravity로의 포팅은 이름만 바꾸는 작업이 될 수 없었다. 그냥 복사해서 붙여넣는다고 되는 구조가 아니었기 때문이다.

gstack의 핵심은 명령어 목록 그 자체가 아니라, 그 명령들이 어던 런타임 위에서 어떤 철학으로 연결되는가에 있다.

결국 이 작업은 포팅이라기보다 번역에 가까웠다. 원본의 철학과 흐름을 이해한 뒤, 그것을 Antigravity의 문법으로 다시 써야 했기 때문이다.

gstack-antigravity는 바로 이 관점에서 시작되었다. 물론 내가 antigravity를 자주 사용하는 이유도 있었다.

내가 사용하기 위해서는 Antigravity 환경에 맞춘 네이티브 포팅이 필요했고, 그 과정에서 Thin Router Architecture, Native Browser Integration, Cross-Platform Parity를 고민하게 됐다.

즉, 원본을 그대로 흉내 내는 포크가 아니라, 원본 워크플로우를 Antigravity 쪽에서 오래 버틸 수 있게 다시 설계한 포팅이라고 보는 편이 맞다.

또 하나는 토큰 문제였다.

AI 워크플로우를 오래 쓰다 보면 언젠가는 비슷한 문제를 겪게 된다.

처음에는 잘 되는데, 문맥이 길어질수록 점점 느려지고, 작업이 커질수록 흐름이 흐트러진다. 특히 역할과 규칙이 많아질수록, 매번 모든 설명을 통째로 들고 다니는 방식은 금방 무거워진다.

gstack-antigravity는 이 문제를 해결하기 위해, 가벼운 규칙 파일이 먼저 라우터처럼 동작하고 실제 워크플로우가 호출될 때만 필요한 내용을 읽어오는 방향을 택했다.

모든 걸 항상 들고 있는 구조가 아니라, 필요한 순간에 필요한 것만 가져오는 구조를 지향하는 셈이다.

이런 종류의 포팅이 실패하는 가장 흔한 이유는 원본 시스템의 방식을 너무 고집해서, 새 환경이 이미 잘하는 것을 못 쓰는 경우다.

그래서 gstack-antigravity는 원본처럼 별도의 브라우저 체계를 억지로 유지하기보다 Antigravity가 제공하는 네이티브 브라우저 도구를 우선 활용하는 방식으로 정리했다.

나는 이 방향이 꽤 중요하다고 생각한다. 좋은 포팅은 원본을 똑같이 복제하는 것이 아니라, 원본의 철학을 유지한 채 새 환경이 잘하는 방식을 받아들이는 일에 더 가깝기 때문이다.

그리고 이 포팅은 antigravity-skills와 함께 쓰면 더 효율적이다. 실제 작업할 때는 큰 흐름을 잡아주는 운영체계와 세부 작업을 도와주는 스킬셋을 나눠 쓰는 편이 훨씬 효율적이다.

gstack-antigravity가 생각-계획-구현-리뷰-QA-배포 같은 전체 흐름을 잡아주는 쪽이라면, antigravity-skills는 브레인스토밍이나 계획 작성 같은 작업 단위 스킬을 보강하는 쪽에 가깝다.

개인적으로 이 조합이 괜찮다고 느껴지는 이유는 현실의 작업 방식과도 잘 맞기 때문이다.

실제 일은 처음부터 끝까지 한 가지 모드로만 흐르지 않는다.

어떤 날은 아이디어를 넓게 보는 시간이 필요하고,
어떤 날은 빠르게 계획을 해야 하며,
어떤 날은 리뷰와 QA가 더 중요하다.

이럴 때 gstack-antigravity가 전체 뼈대를 잡아주고, antigravity-skills가 필요한 순간에 세부 스킬을 보강해주면 흐름이 훨씬 부드러워진다.

예를 들어 새로운 기능을 시작할 때는 먼저 @brainstorming으로 문제를 살펴보고, 그다음 gstack 스타일의 계획 흐름으로 구조를 잡고, 구현 이후에는 리뷰와 QA로 마무리하는 식이다.

즉, 이 둘은 경쟁 관계라기보다 운영체계와 도구 상자라고 표현하는 편이 더 맞다.

AI 도구를 오래 써보면 결국 필요한 건 “더 똑똑한 답변”만이 아니다. 오히려 더 절실한 건 흐트러지지 않는 작업 흐름, 길어져도 무너지지 않는 문맥 관리, 실제로 계속 쓸 수 있는 운영 방식이다.

gstack-antigravity는 원본 gstack의 핵심인 역할 분리, 스프린트형 흐름, 작업 철학을 유지하면서, 그것을 Antigravity 환경에 맞게 다시 설계한 포팅이다.

이 과정에서 얇은 라우팅 구조를 통한 문맥 경량화, Antigravity 네이티브 브라우저 도구 활용, 크로스 플랫폼 대응을 함께 고민했다.

여기에 antigravity-skills 같은 실전 스킬 저장소를 함께 붙이면, 전체 흐름과 세부 작업을 나눠서 다루는 좀 더 현실적인 작업 방식이 만들어진다.

혹시, 써보고 싶은신 분들은 아래를 참고하세요.

https://www.npmjs.com/package/@runchr/gstack-antigravity

다음 글에서는 paperclipai + opencode 같은 조합으로 여러 Agent를 회사 조직처럼 묶어서 운영하는 방법에 대해 정리해보려고 합니다.

Giljae Joo (주길재)