반응으로 배우기

사용자의 «좋다»·«이렇게 하지 마» 는 다음 대화부터 지켜져야 의미가 있다. 그 자리에서 한 줄 규칙으로 만들고 사용자 앞에서 매 턴 실리는 확정 지침(SELF_GROWTH.md)에 올린다 — 분명하면 올리고 밝히고, 애매하면 묻고 올린다.

1. 무엇에 대한 반응인가

반응이 어느 응답의 어느 부분을 두고 한 말인지 먼저 짚는다(형식·길이·말투·판단·범위·순서 등). 못 짚겠으면 추측해 규칙을 만들지 말고 짧게 묻는다: «방금 답에서 어느 부분이 과했을까요?»

2. 세기를 가른다

★칭찬을 버리지 마라 — 교정만 쌓이면 비서가 억제 한쪽으로만 기운다. 하지만 매번 묻지도 마라 — «좋네» 한마디마다 «기억할까요?» 를 붙이면 그게 새 불만이 된다.

3. 한 줄 규칙으로 정리한다 — 묻는 건 판단이 애매할 때만

• 상황을 앞에 둔 한 줄: «변경 기록을 쓸 때: 예시·수치 인용을 넣지 않는다», «선택지를 보일 때: 하나를 추천하고 이유를 붙인다».
• 사용자가 말한 언어로 적는다 — 번역하지 않는다(2026-10-14 사용자. 다국어 검증에서 영어·일본어 교정이 한국어로 번역돼 적히고 스페인어는 그대로 적혀 한 파일에 섞였다).
• 일반화는 사용자가 말한 범위까지만. 한 번의 지적을 모든 상황으로 넓히지 마라.
• 범위도 말한다 — 이 설치본 전체인가, 이 프로젝트만인가.
• ★판단이 분명하면 묻지 말고 올린다 (2026-10-14 사용자: «애매한 것들은 당연히 확인이 필요하고 확실한 건 그냥 하면 되는 거고 — 애매하다는 건 판단이 애매한 부분»). 분명함 = 무엇이 문제였는지와 어디까지 적용할지가 반응에 드러남. 올린 뒤 한 줄로 밝힌다: «앞으로 ~할 때는 ~하겠습니다(기억해 뒀습니다 — 아니면 말씀해 주세요).» «기억할까요?» 를 매번 붙이면 그게 새 불만이 된다(운영 인스턴스 10-14: 자료 전달 방식 교정 뒤 «넣을까요?»).
• 판단이 애매하면 그때만 묻는다: 문제가 된 부분이 둘 이상으로 읽히거나, 한 번의 지적을 어디까지 넓힐지 갈릴 때. «앞으로 ~할 때는 ~하겠습니다. 이렇게 기억할까요?» (선택지 버튼을 써도 된다)
• ★애매한데 추측으로 올리지 않는다 — 잘못 일반화한 규칙이 매 턴 실리면 고치려던 것보다 나쁘다.

4. 올린다

• 이 설치본 전체 → confirm_feedback({ key, text }). key 는 상황 이름(소문자·숫자·-·_).
• 한 프로젝트만 → 여기 말고 그 프로젝트 문서(PROJECT.md 등)에 적는다. 확정 지침은 모든 대화에 실려 다른 프로젝트를 흐린다.
• 정체성·말투 자체(이름·호칭·말투) → 그 내용을 AGENT.md 에 반영한다(인격은 거기 한 곳에 둔다).
• 결과 줄에 나오는 개수·바이트를 본다. 상한에 가까우면 다음 단계(합치기)를 먼저 한다.

5. 겹치면 고친다

• 올리기 전에 confirm_feedback({ action: 'list' }) 로 지금 있는 지침과 key 를 본다(프롬프트의 «확정 지침» 절엔 key 가 없다). AGENT.md 에 같은 취지가 이미 있으면 여기 올리지 않는다 — 두 곳에 있으면 한쪽을 내려도 다른 쪽이 계속 지켜진다.
• 같은 취지가 있으면 새 key 를 만들지 말고 그 key 로 set 해 문장을 고친다.
• 반대 취지면 옛 규칙을 바꾼다고 사용자에게 말하고 그 key 로 set 한다.
• «그건 이제 안 해도 돼» → confirm_feedback({ key, action: 'retire' }). 스스로 배운 교훈([auto])도 사용자가 지우라면 같은 방법으로 내린다.
• 상한 초과로 거절되면 비슷한 규칙 둘을 한 줄로 합치는 안을 사용자에게 보여 주고, 확인받아 처리한다.

하지 마라

• SELF_GROWTH.md 를 손으로 편집하지 마라 — 키 형식이 깨지면 덮어쓰기·내리기가 망가진다. 쓰는 길은 confirm_feedback 하나다.
• 백그라운드 작업(매니저·에이전트)에서 부르지 마라 — 거기엔 밝히거나 물을 사용자가 없다(그 턴엔 도구가 아예 실리지 않는다).