TEREO가 뭐야?

AI가 코드를 바꾸면 TEREO는 그 변화가 진짜 좋아진 건지 확인한다.

• #AI
• #메모리
• #작업 방식
• #운영 원칙

한 줄 결론

TEREO는 작은 목표를 고정하고 같은 기준으로 반복 판정해 noise를 이긴 gain만 남기는 proof layer다.

3줄 요약

1. TEREO는 scope, promise, check, baseline을 먼저 고정해 이번 라운드의 작은 진실을 정한다.
2. 새 문제가 보여도 현재 promise를 거짓으로 만드는지 먼저 묻고, 아니라면 다음 라운드로 넘긴다.
3. receipt는 keep, hold, drop의 이유를 남겨 AI의 목표 이동과 자기합리화를 막는다.

---

변경의 진실을 밝히는 증명 레이어 TEREO

AI가 코드를 바꾸면, TEREO는 그 변화가 진짜 좋아진 건지 확인한다.
keep only if gain > noise

Repo: https://github.com/kim-woojoo/tereo

---

이게 뭐 하는 거야?

쉽게 정리해 볼게요.

기존 AI 코딩은 코드를 바꾸고, 다시 돌려보고, 또 바꿉니다.

• 메인 에이전트가 수정하고
• 서브 에이전트가 다시 검토하고
• harness나 다른 검증 레이어가 한 번 더 확인하기도 합니다

문제는 이 과정에 고정된 기준이 없으면, 결과가 그럴듯해 보여도 진짜 좋아진 건지 알기 어렵다는 점입니다.

그래서 여러 가지 오류가 발생합니다.

사용자의 오류

예를 들어 다양한 코드가 포함된 A 프로젝트를 만들었다고 합시다.

프로젝트 안의 코드들은 각기 다른 역할로 작동합니다.

• 어떤 코드는 UI
• 어떤 코드는 할인 계산
• 어떤 코드는 결제
• 어떤 코드는 데이터 흐름
• 어떤 코드는 테스트

숙련된 개발자는 이 구조와 흐름을 비교적 빨리 읽습니다.
하지만 바이브 코더나 비개발자는 그렇지 못한 순간이 자주 옵니다.

그래서 수정할 때마다 이런 문제가 생깁니다.

• 어디부터 봐야 하지?
• 어떤 파일이 연결돼 있지?
• 뭘 건드리면 안 되지?
• 지금 고친 게 진짜 맞는 방향인가?

검증의 오류

예를 들어 쇼핑몰 프로젝트를 생각해 봅시다.

사용자는 10% 할인 쿠폰 기능을 개선하고 싶어 합니다.

겉으로는 단순해 보입니다.

“10% 할인만 잘 되면 되는 거 아닌가?”

하지만 실제로는 그렇지 않습니다.

예를 들어 이런 일이 가능합니다.

• 쿠폰 10% 할인은 적용됨
• 그런데 총액 계산이 깨져서 음수가 됨
• 또는 checkout 전체 흐름이 깨짐

이 경우 겉으로는 일부 성공처럼 보이지만, 실제로는 거짓 개선입니다.

즉:

• 좋아진 한 점만 보면 성공처럼 보임
• 전체 핵심 동작까지 보면 실패임

기준 이동의 오류

AI는 코드를 수정하다 보면 새로운 문제를 계속 발견합니다.

예를 들면:

• “어? 세금 반올림도 이상한데?”
• “어? 무료배송 조건 계산도 미묘한데?”

기존 AI 방식은 여기서 타협하기 쉽습니다.

• “그럼, 이번엔 쿠폰 말고 세금까지 같이 보자”
• “기준을 조금 넓혀서 한 번에 고치자”
• “문제가 보였으니 같이 수정하자”

이렇게 되면 중간에 승리 조건이 바뀝니다.

그러면 원래 고치려던 문제가 진짜 해결됐는지 흐려집니다.

TEREO는 이 문제를 어떻게 푸는가

TEREO는 이런 갈증들을 명확히 풀어줍니다.

우선 A라는 프로젝트를 만든다고 칩시다.

TEREO는 전체 코드를 훑고, 지금 다룰 작은 주제를 하나 고르게 만들고, 그 주제에 대해 작은 범위를 먼저 고정하게 합니다.

즉, 전체를 한 번에 고치는 대신 이번 판에서 다룰 작은 진실만 정하게 만드는 겁니다.

그리고 단순히 “좋아졌는가?”만 보지 않습니다.

“그 좋아짐을 거짓으로 만드는 핵심 파손이 없는가?”

까지 같이 봅니다.

또한 문제를 발견했다고 기준을 흔들지 않습니다.

현재 진실을 먼저 닫고, 다음 진실은 다음 라운드로 넘깁니다.

좀 더 상세하게 풀어볼게요.

예시: A 프로젝트가 쇼핑몰 프로젝트라면

A 프로젝트가 쇼핑몰 프로젝트라고 예시를 들어볼게요.

여기서 사용자가 원하는 건 쿠폰 할인 개선입니다.

TEREO는 전체 코드에서 쿠폰과 관련된 코드를 찾습니다.

• cart.py
• discount.py
• 관련 테스트 몇 개

이게 scope입니다.

그래서 이 코드 묶음이 A라는 주제가 됩니다.

그리고 A 주제로 지금 무엇을 진실로 만들지 목표를 정합니다.
이게 promise입니다.

예를 들어:

• 상품 가격 10,000원
• 10% 할인 쿠폰을 적용하면 총액은 9,000원

그리고 목표인 promise를 어떻게 판정할지 규칙 또는 실행 명령을 정합니다.
이게 check입니다.

예를 들어:

• 쿠폰 적용 결과가 9,000원인지 확인
• 총액이 음수가 아닌지 확인
• 기존 결제 테스트가 계속 통과하는지 확인

이 check를 현재 코드로 돌려 봅니다.

실행 결과:

• 현재 쿠폰 테스트 실패
• 이 과정에서 checkout 핵심은 안 깨짐
• 총액 음수가 생김

이 결과가 현재 상태입니다.
즉 baseline이 됩니다.

그럼 이 baseline이 현재 A 주제의 상태로 고정됩니다.

정리하면:

• promise = 무엇이 참이어야 하는가? 즉 목표
• check = 그걸 어떻게 시험할 것인가? 즉 판정법
• baseline = 현재 출발 상태, 즉 현재 상태

그리고 이제부터가 핵심입니다.

TEREO의 1라운드 루프

baseline을 정했으니 이제 수정을 들어가야겠죠?

여기서 TEREO의 1라운드 루프가 생깁니다.

목표는 이렇습니다.

• 현재 쿠폰 테스트를 성공시키기
• 총액 음수 없애기
• 수정 과정에서 checkout 핵심 유지하기

수정은 안전하게 작동됩니다.

가능하면 한 파일 또는 한 작은 파일 묶음씩 수정합니다.

수정 후 check를 돌립니다.

check 결과는?

• 총액 음수 없음 → 성공
• 수정 과정에서 checkout 핵심 유지 → 성공
• 그런데 쿠폰 테스트는 실패

그러면 쿠폰 테스트 실패와 관련된 파일, 예를 들어 coupon.py에서 할인 계산 로직을 수정합니다.

다시 check를 돌립니다.

목표가 성공할 때까지 반복합니다.

성공했다면?

여기서 검증 로직인 judge가 작동합니다.

• 변경이 미묘하다 → hold
• 이전 코드보다 개선되는 게 없다 → drop
• 확실히 개선됐다 → keep

어떻게 남기냐고요?

결과표인 receipt로 남깁니다.

그럼 이 keep 결과표는 새로운 baseline으로 추가됩니다.

여기까지가 TEREO 1라운드 루프의 끝입니다.

이 결과를 좀 더 풀어볼게요.

judge와 receipt는 무슨 역할을 하나

검증 로직인 judge는 말 그대로,
이번 변화가 진짜 좋은 변화인지 시험을 보는 문제지예요.

promise와 baseline을 기준으로 다양한 조건을 check하여
keep, hold, drop을 결정해 주는 역할이에요.

결과표인 receipt는 왜 남기냐고요?

나중에 코드를 수정할 때 아주 유용한 증거자료가 되거든요.

receipt에는 이런 내용이 저장됩니다.

• scope
• promise
• baseline.id
• check
• before/after metric
• evidence
• verdict
• why
• confidence
• win_probability
• trace

쉽게 말하자면 이런 겁니다.

• 무엇을 목표로 했는지
• 무엇을 시험했는지
• 왜 keep / hold / drop이 나왔는지

즉 receipt는
무엇을 믿을지 결정하는 증거이자,
왜 그렇게 결정했는지까지 남기는 기록입니다.

이게 중요한 이유는, 기준을 슬쩍 바꿔 AI가 자기합리화하는 걸 막아주기 때문이에요.

여기까지 잘 이해가 된다면 이제부터 중요합니다.

새 문제가 발견되면 어떻게 되나

예를 들어 coupon.py에서 할인 계산 로직을 수정하다 보니 새로운 문제점이 보입니다.

예를 들면:

• “어? 세금 반올림도 이상한데?”
• “어? 무료배송 조건 계산도 미묘한데?”

기존 AI의 문제는, 새 문제를 발견하면
원래 고치기로 한 문제 + 새로 발견한 문제를 합쳐버린다는 점입니다.

예를 들면:

• 원래 목표는 쿠폰 10% 할인 수정
• 그런데 수정하다가 세금 반올림 문제를 발견

그러면 기존 AI는 이렇게 갑니다.

• “그럼 세금까지 같이 보자”
• “이번엔 무료배송도 같이 맞추자”
• “한 번에 전체 흐름을 정리하자”

겉보기엔 똑똑해 보이지만, 실제로는 위험합니다.

왜 위험하지?

왜 위험한가

• 원래 목표가 흐려집니다
• 성공 조건이 중간에 바뀝니다
• 무엇이 진짜 개선된 건지 불명확해집니다
• 새 문제를 고치다가 원래 문제는 오히려 애매하게 남을 수 있습니다

결과적으로 많이 바꿨다는 남지만
어떻게 바꿨는가는 남지 않습니다.

특히 가장 큰 문제는 자기합리화예요.

• 진짜 해결된 건지
• 아니면 얼버무린 건지

구분이 안 됩니다.

똑똑한 AI일수록 더 치명적이죠.

TEREO는 이 지점을 어떻게 파고드나

TEREO는 이 점을 명확히 파고듭니다.

1라운드 목표는 끝까지 이것만 봅니다.

“쿠폰 버그가 고쳐졌는가?”

왜?

promise로 고정했으니까요.

그럼 세금 반올림 문제는?

judge는 문제에 대해 이렇게 묻습니다.

“이 세금 문제 때문에 쿠폰 성공이 거짓이 되는가?”

• 답이 Yes면 같은 1라운드에 남아서 개선
• 답이 No면 다음 주제인 B 주제로 작성

예를 들어 No면 1라운드가 성공적으로 끝납니다.

그럼 2라운드에서 B 주제인 세금 반올림을 시작합니다.

한 파일씩 수정했을 때 결과는 2%, 1.5%처럼 미묘할 수 있습니다.

한 번만 보면:

• 좋아진 것 같기도 하고
• 아닌 것 같기도 한

상태일 수 있습니다.

하지만:

• 1라운드
• 2라운드
• 3라운드
• …

이렇게 라운드를 계속 거쳐 전체적인 결과로 본다면, 점점 더 분명해집니다.

마무리

TEREO의 규칙은 단순합니다.

• 작은 목표를 고정하고
• 같은 기준으로 반복 판정해서
• noise를 이긴 진짜 gain만 다음 기준점으로 남긴다

즉:

keep only if gain > noise

이 방식은 개선할 수 있는 모든 영역에서 작동시킬 수 있습니다.

정말 안타까운 건 TEREO는 한 가지 조건이 있습니다.

• 컴퓨터 필수

이 조건만 충족하면 어디에 붙여도 사용할 수 있습니다.

• 다양한 프로젝트
• 다양한 작업
• 다양한 실험
• 다양한 자동화
• 다양한 취미 활동

AI가 계속 발전하면 TEREO가 필요 없어질까요?

아뇨.
오히려 더 필요합니다.

AI가 강해질수록 더 빠르게, 더 많이, 더 그럴듯한 이유를 만들어냅니다.

그래서 정말 중요한 건
바꿀 수 있느냐가 아니라
무엇을 남길 것이냐가 됩니다.

그 지점에서 TEREO의 역할은 더 커집니다.

AI가 만든 수많은 변화 가운데,
실제로 성과로 이어지는 진짜 개선만 골라 남기는 증명 레이어가 되기 때문입니다.

이제 궁금한 건 여러분의 사례입니다

• 어떤 프로젝트에 붙였는지
• 어떤 작업에 써봤는지
• 어떤 취미나 실험에 적용했는지
• 어떤 변화가 keep됐는지
• 어떤 변화가 drop됐는지

함께 공유해 주세요.

사례들이 쌓일수록 TEREO는 작은 진실을 하나씩 남기면서 성장할 수 있습니다.

TEREO의 철학처럼요.

자주 받는 질문

보이는 문제를 한 번에 다 고치면 왜 안 되나?

문제가 늘어나는 순간 승리 조건이 바뀌고 원래 개선이 진짜였는지 흐려지기 때문이다. TEREO는 현재 promise를 거짓으로 만드는 문제만 같은 라운드에 남긴다.

`check`와 `judge`는 어떻게 다른가?

`check`는 목표를 시험하는 규칙과 명령이고, `judge`는 그 결과를 바탕으로 keep, hold, drop을 결정하는 판정 단계다.

`receipt`는 왜 남기나?

나중에 코드를 다시 바꿀 때 무엇을 목표로 했고 무엇을 시험했으며 왜 keep, hold, drop이 되었는지 증거로 남기기 위해서다.