1. AI 시대에 느끼는 위기감

AI 에이전트는 나날이 편리해지고 있습니다.

한편, 저는 최근 한 가지 위기감을 느끼고 있습니다.

그것은

「AI를 똑똑하게 만들기 위한 지식과 시행착오가 자사가 아닌 AI 플랫폼 측으로 축적되어 가는 구조」

입니다.

AI에 전달하는 것은 코드뿐만이 아닙니다.

• 도메인 지식 (Domain Knowledge)
• 개발 규칙
• 테스트
• 설계 의도
• 시행착오

이러한 「사고의 이력」 그 자체입니다.

AI를 사용하면 사용할수록,

개발자 자신이 아니라 플랫폼 측이 똑똑해진다.

저는 이 구조에 약간의 위기감을 느끼고 있습니다.

2. 하네스의 블랙박스화라는 문제

현재 각 AI 프로바이더는 개발 에이전트를 판매할 때, **「하네스(Harness: AI를 안전하고 정확하게 구동하기 위한 피드백 루프(Feedback Loop)나 문맥 제어 메커니즘)」**의 중요성을 어필하고 있습니다.

「AI가 테스트를 돌리고, 에러를 자동 수정하며, 적절한 도구를 호출합니다」라는 강력한 에코시스템입니다.

하지만 여기에 가장 큰 함정이 있습니다. 이 하네스 자체가 AI 프로바이더의 플랫폼 측에 닫힌 「블랙박스(Black Box)」로서 제공되고 있다는 점입니다.

LLM 자체는 교체할 수 있습니다.

• Claude라도
• Gemini라도
• GPT라도 좋습니다.

하지만

교체하기 어려운 것은 하네스입니다.

AI가

• 무엇을 읽을지
• 어떤 순서로 생각할지
• 에러 발생 시 어떻게 재시도(Retry)할지
• 어떤 테스트를 실행할지

이러한 "사고의 흐름"이

프로바이더 독자적인 메커니즘에 갇히게 되면,

모델보다 더 갈아타기가 어려워집니다.

즉,

AI를 똑똑하게 만들기 위한 피드백 루프는 축적되더라도,

이용자의 리포지토리(Repository)에는 아무것도 남지 않는다

고 생각합니다.

AI의 버전이 바뀌거나 프로바이더를 갈아타는 순간, 자사에는 아무것도 남지 않게 될 수도 있습니다. 사고의 장(하네스)을 프로바이더에게 장악당한다는 것은 기술적 부채를 넘어 「지적 부채」를 떠안는 것을 의미합니다.

3. 해결책: 문서/테스트의 자동 추종 (오픈 하네스)

이 위기를 회피하기 위해 필요한 것은, 무턱대고 AI에게 사고를 맡기는 것이 아니라, **「AI를 구동시키는 하네스 자체를 우리들의 오픈한 코드(리포지토리) 측으로 되찾아오는 것」**입니다.

그렇다고 해서 지금의 코딩 에이전트를 전면적으로 부정하는 것은 아니며, 이용할 수 있는 것은 이용하는 것이 좋다고 생각합니다.

「되돌릴 수 있는 것은 되돌려서 최대한 활용한다」가 됩니다.

AI 에이전트의 시행착오, 피드백 루프, 도메인 제약을 플랫폼의 기능에 의존하지 않고, 리포지토리 내의 코드·테스트·문서로서 자율적으로 추종하게 하는 구성을 지향합니다.

프롬프트를 쓰는 시대에서, 리포지토리를 키우는 시대로.

AI에 대한 입력은 프롬프트만이 아닙니다.

리포지토리 그 자체가 AI에게 프롬프트가 됩니다.

테스트: 단순한 성패 판정이 아니라, AI에 대한 「실행 가능한 사양서(프롬프트의 대체제)」로서 기능하게 한다.

문서: 코드의 변경에 따라 자동으로 추종·검증되며, 항상 AI가 참조해야 할 「최신 문맥(Context)」으로 남는다.

자체 리포지토리 내에 「질 높은 문맥과 피드백 루프」를 틀(Type)로서 계속 유지하는 것. 이것이야말로 특정 AI 모델에 의존하지 않고, 어떤 AI가 오더라도 자사의 노하우를 안전하고 최대 효율로 활용하기 위한 유력한 접근법 중 하나라고 생각합니다.

4. 왜 Effect-ts 인가

오픈 하네스를 실현하기 위해서는,

• 실패를 AI에게 반환할 수 있을 것
• AI가 이용할 수 있는 도구를 제어할 수 있을 것
• 지식을 코드로부터 생성할 수 있을 것

이 필요합니다.

• Cause (실패를 구조화함)
• Layer (의존 관계를 관리함)
• Schema (지식을 코드화함)

이라는 세 가지 메커니즘이 있으며,

이것들을 조합하면

오픈 하네스를 TypeScript만으로 구축할 수 있습니다.

즉,

Effect-ts는

AI 라이브러리가 아닙니다.

하지만,

오픈 하네스를 구현하기 위한 토대로서,

매우 궁합이 좋다고 생각합니다.

오픈 하네스는,

특정 AI 모델을 교체하기 위한 메커니즘이 아닙니다.

AI가 진화해도,

리포지토리에 축적된 지식을 그대로 계속 활용하기 위한 설계 사상입니다.

5. 동료 모집: 지식을 우리들의 손으로 되찾아오자

AI 프로바이더에게 노하우를 넘겨주고 사고 정지(思考停止)의 레거시로 갈 것인가.

아니면, 자체 리포지토리에 견고한 하네스(Harness)를 구축하여 AI를 진정한 '파트너'로서 활용할 것인가?

지금 엔지니어에게 요구되는 것은 단순히 AI 도구를 능숙하게 사용하는 것이 아니라, **'지식의 주권(ナレッジの主権)을 우리 코드 안으로 되찾는 아키텍처 설계'**입니다.

• Effect-ts를 활용한 실질적인 에이전트 하네스 설계 패턴
• 문서와 테스트를 AI가 자동으로 추적하는 CI/CD 파이프라인 구축
• 특정 모델에 의존하지 않는 컨텍스트 제어 기법

이러한 '오픈 하네스(Open Harness) 설계' 시도에 공감하며, 함께 직접 손을 움직여 노하우를 오픈으로 공유할 수 있는 동료를 모집하고 있습니다.

프로바이더의 블랙박스 속에서 사고가 빼앗기기 전에, 코드로 미래를 구축해 나갑시다.

AI는 앞으로도 진화할 것입니다.

모델은 바뀔 것입니다.

프로바이더도 바뀔 것입니다.

하지만,

리포지토리에 축적된 지식은 변하지 않습니다.

그래서 저는

"오픈 하네스(Open Harness)"

라는 개념을 널리 알리고, 여러분과 함께 키워나가고 싶습니다.

💬 의견 교환 및 피드백의 장을 마련했습니다

솔직히 말해, 이 '리포지토리에 되찾는 오픈 하네스 설계'는 아직 시행착오(試行錯誤) 단계입니다.

"나라면 이렇게 작성할 것 같다", "여기서 과제가 있지 않을까?"와 같은 의견이나 아이디어를 대환영합니다!

글 내용에 대한 댓글이나 피드백은 아래 GitHub Discussion에서 기다리겠습니다.

관심이 있다면 꼭 Discussion에서 논의해 봅시다.

"여기가 흥미롭다", "Effect-ts의 활용처에 대해"와 같은 가벼운 댓글이나 👍 리액션만으로도 기쁩니다!

※이번 주말 7/31부터 잠시 자리를 비우게 되어, 남겨주신 댓글에 대한 답변 및 리액션이 다소 늦어질 수 있습니다. 미리 양해 부탁드립니다!

Discussion