대화 설치에서 프로젝트 설치로, 트리즈 엔진을 고정하는 세 단계

새 대화에서 사라지는 엔진

2장에서 붙여 넣은 라이트 프롬프트는 한 대화 안에서 작동한다. 새 대화를 열면 다시 넣어야 한다. 오래 대화하면 다른 지시와 자료 사이에 묻힐 수도 있다. 한두 번 시험할 때는 문제가 없지만 매주 사용하려면 고정된 작업 공간이 필요하다.

이 책에서 설치란 AI 모델 자체를 변경한다는 뜻이 아니다. 반복해서 사용할 사고 절차와 참고 자료를 지침, 프로젝트, 재사용 도구 형태로 고정한다는 뜻이다.

설치는 세 단계로 나뉜다.

단계가 높다고 답이 자동으로 좋아지는 것은 아니다. 대화 설치는 가볍고 수정하기 쉽다. 프로젝트 설치는 맥락을 유지하기 좋지만 잘못된 지침도 반복한다. 재사용 도구는 배포하기 쉽지만 버전과 자료 관리가 필요하다.

대화 설치: 가장 작은 시험

라이트 프롬프트 v1.1은 공백 포함 745자다. ChatGPT와 Gemini의 교차 테스트 뒤 세 부분을 보완했다.

• 비기술 문제를 기술적 모순이라고 부르지 않는다.
• 선택한 원리마다 대안 2개를 각각 만든다.
• 사용자가 정한 제약의 의미를 바꾸기 전에 다시 승인받는다.

교차 테스트에서 ChatGPT는 선택한 네 원리마다 두 대안을 만들고, 전원의 구두 발언 기회를 유지했다. Gemini는 문서 작성 기회를 발언 기회로 바꾸고, 선택 원리를 섞어 세 대안만 만들었다. 아이디어는 흥미로웠지만 보호 조건의 뜻이 달라졌다.

이 차이는 특정 모델의 우열을 말하기 위한 것이 아니다. 같은 지침도 모델에 따라 절차 충실도와 제약 해석이 달라질 수 있다는 뜻이다. 설치가 끝났다는 표시는 프롬프트를 저장했다는 사실이 아니라, 정상 작동 테스트를 통과했다는 사실이다.

대화 설치는 다음 상황에 맞는다.

• 엔진이 내 문제에 맞는지 처음 확인할 때
• 민감한 자료 없이 짧은 문제를 풀 때
• 원리와 절차를 자주 고치며 시험할 때
• 프로젝트 기능을 사용할 수 없을 때

반대로 같은 절차를 매번 붙여 넣고, 40원리의 설명과 개인 사례까지 함께 제공한다면 대화가 무거워진다. 그때 프로젝트로 옮긴다.

프로젝트 설치: 지침과 지식을 나눈다

프로젝트 설치에서 가장 중요한 원칙은 행동 규칙과 참고 자료를 섞지 않는 것이다.

프로젝트 지침에는 AI가 반드시 지킬 순서를 넣는다.

• 바로 해결하지 않는다.
• 목표와 제약을 재진술한다.
• 모순 후보를 2개에서 3개 제시한다.
• 인간 승인 전에는 원리 선택으로 넘어가지 않는다.
• 선택 원리와 대안의 대응 관계를 유지한다.
• 제약을 재해석하려면 다시 승인받는다.
• 현실 필터와 폐기 이유를 남긴다.

지식 파일에는 원리를 적용할 때 참고할 내용을 넣는다.

• 40원리의 자체 번역명
• 원리별 한 줄 설명
• 업무용 적용 방향
• 적합한 모순 유형
• 잘못 적용하기 쉬운 방식
• 자체 제작 사례

규칙을 지식 파일에 묻어두면 AI가 참고 자료로만 취급할 수 있다. 반대로 40원리 전체를 지침 입력란에 넣으면 핵심 절차가 길어진 자료에 묻힌다. 지침은 짧고 단단하게, 지식 파일은 넓고 찾아보기 쉽게 만든다.

프로젝트 폴더는 다음 정도면 충분하다.

project_instructions.txt
triz_40_principles.md
my_constraints.md
successful_cases.md
failure_log.md

처음부터 개인 파일 세 개를 모두 만들 필요는 없다. 원리 파일로 시작하고, 실제 사용 기록이 쌓일 때 제약과 성공 사례와 실패 로그를 추가한다.

정식 실행 프로토콜: 여덟 단계

프로젝트 지침에서는 라이트판보다 한 단계를 더 분리한다.

1. 목표와 제약을 재진술한다.
2. 개선-악화형, 동시 상태형, 거짓 양자택일을 판별한다.
3. 모순 후보를 제시하고 인간의 승인을 받는다.
4. 승인된 모순에 맞는 원리를 제한적으로 선택한다.
5. 원리마다 서로 다른 대안을 만든다.
6. 기존 해법과 행동이 겹치는 대안을 제거한다.
7. 비용, 시간, 권한, 부작용, 되돌리기로 평가한다.
8. 추천안과 폐기안을 이유와 함께 제시한다.

라이트판은 5단계 안에서 기존 해법 제거를 함께 처리한다. 프로젝트판은 이 단계를 따로 떼어 반복 사용 때 생기는 익숙한 답의 재등장을 더 분명하게 막는다.

프로젝트 지침 원문

다음 지침은 플랫폼에 맞게 메뉴 위치만 바꾸고 내용은 유지한다.

[트리즈 모순 해결 엔진 - 프로젝트]

역할: 비기술 업무·사업·콘텐츠 문제를 자연어 모순으로 구조화하고, 제한된 해결 원리로 실행 가능한 대안을 만드는 도구다.

절차:
1. 바로 답하지 말고 목표와 제약을 각각 한 줄로 재진술한다.
2. 개선-악화형, 동시 상태형, 거짓 양자택일 여부를 판별한다. 비기술 문제에는 '기술적 모순'이라는 명칭을 쓰지 않는다.
3. 서로 다른 관점의 모순 후보 2~3개를 제시하고 사용자 승인을 기다린다.
4. 승인된 모순에 맞는 원리 2~4개를 지식 파일에서 고르고 선정 이유를 쓴다.
5. 선택한 원리마다 서로 다른 대안 2개를 각각 만든다. 선택하지 않은 원리를 추가하지 않는다.
6. 사용자가 이미 하는 방법과 행동이 겹치는 대안을 표시하고 제외한다.
7. 비용, 준비 시간, 실행 권한, 난도, 부작용, 되돌리기로 평가한다.
8. 추천안 1~2개, 최소 시험, 폐기안과 이유를 제시한다.

통제:
- 사용자가 지정한 제약의 의미를 바꾸려면 대안 생성 전에 다시 승인받는다.
- 대안 수보다 모순을 줄이는 방식의 차이를 우선한다.
- 성과를 단정하지 않는다.
- 정보가 부족하면 추정 사실을 표시하고 필요한 맥락을 요청한다.
- 사용자가 '빠르게'라고 말할 때만 승인 단계를 생략하고 최유력 모순 하나로 진행한다.

이 지침은 40원리를 포함하지 않는다. 절차를 지키는 행동 지침이기 때문이다. 원리 파일은 별도로 두고 4단계에서만 참조하게 한다.

원리 지식 파일의 한 항목

40원리 지식 파일은 긴 해설보다 일정한 항목 구조가 중요하다. 다음 형식을 원리마다 반복한다.

원리명:
한 줄 방향:
적합한 상황:
업무 번역:
자체 제작 예시:
잘못 적용하는 방식:
함께 검토할 원리:

예를 들어 분할은 다음처럼 적을 수 있다.

원리명: 분할
한 줄 방향: 한 덩어리로 처리하던 대상을 독립적으로 조정할 수 있는 단위로 나눈다.
적합한 상황: 모든 대상에 같은 깊이·시간·기능을 적용해 부담이 커질 때
업무 번역: 본문과 근거, 기본 서비스와 선택 서비스, 정기 업무와 사건 업무로 나눈다.
자체 제작 예시: 보고서 본문은 변화와 결정만 담고 상세 수치는 근거 부록으로 분리한다.
잘못 적용하는 방식: 나눈 뒤 다시 연결할 책임과 기준을 정하지 않는다.
함께 검토할 원리: 추출, 조건 분리, 통합

원리명만 나열하면 AI가 일반 지식으로 빈칸을 채울 수 있다. 업무 번역과 잘못 적용하는 방식을 함께 넣으면 대안의 방향과 경계를 동시에 준다.

세 플랫폼을 같은 기준으로 비교한다

메뉴와 이름보다 다음 기능이 있는지를 본다.

기능 제공 범위와 화면은 계정과 시점에 따라 달라질 수 있다. 따라서 책에서는 메뉴를 외우게 하기보다 지침, 지식, 새 대화 테스트의 세 요소를 찾게 한다. 화면이 달라져도 이 구조는 유지된다.

ChatGPT에 설치한다

2026년 7월 기준, ChatGPT에서는 프로젝트에 파일과 프로젝트 지침을 둘 수 있다. 프로젝트 지침은 해당 프로젝트 안에서 적용되고 전역 사용자 지정 지침보다 우선한다.

설치 순서는 단순하다.

1. 트리즈 문제해결 전용 프로젝트를 만든다.
2. 프로젝트 설정에 여덟 단계 실행 프로토콜을 넣는다.
3. triz_40_principles.md를 프로젝트 자료로 추가한다.
4. 새 대화에서 정상 작동 문제를 입력한다.
5. 승인 전 멈춤과 원리별 대안 수를 확인한다.

745자 라이트 프롬프트는 공개된 1,500자 사용자 지정 지침 제한 안에도 들어간다. 하지만 전역 사용자 지정 지침에 넣으면 일반 요약, 번역, 글쓰기 대화까지 모순 승인 절차가 끼어들 수 있다. 전용 프로젝트를 우선하고, 사용자 지정 지침은 거의 모든 대화에서 엔진을 쓸 사람만 선택한다.

프로젝트 자료에 회사의 실제 문서를 넣을 때는 필요한 부분만 추린다. 고객 이름, 계약 조건, 개인정보, 공개되지 않은 수치를 문제 해결에 꼭 필요한 수준으로 줄인다. 사고 절차를 고정하는 일과 민감한 원문을 모두 올리는 일은 별개다.

Claude에 설치한다

Claude 프로젝트에는 프로젝트 지침과 지식 자료를 둘 수 있다. 프로젝트 지침은 해당 프로젝트의 대화에서 반복 적용된다. 서로 다른 대화의 세부 맥락이 자동으로 모두 이어진다고 가정하지 말고, 계속 사용할 정보는 프로젝트 지식에 넣는다.

설치 순서는 ChatGPT와 비슷하다.

1. 새 프로젝트를 만들고 트리즈 엔진용 이름을 붙인다.
2. 프로젝트 지침에 여덟 단계 프로토콜을 넣는다.
3. 프로젝트 지식에 원리 파일을 추가한다.
4. 정상 작동 문제를 새 채팅에서 실행한다.
5. 실패 로그를 프로젝트 지식에 계속 갱신한다.

지식 파일이 지나치게 커지면 필요한 원리를 찾는 방식이 달라질 수 있다. 원리 파일은 표와 짧은 예시 중심으로 만들고, 사례 원문을 무제한으로 쌓지 않는다. 성공 사례와 실패 로그는 문제 유형, 승인 모순, 선택 원리, 결과만 남긴다.

Gemini에 설치한다

Gemini에서는 웹에서 Gem을 만들고 지침과 지식 파일을 추가할 수 있다. Gem 편집 화면에서 이름과 지침을 입력하고, 지식 자료를 추가한 뒤 미리보기에서 시험하고 저장한다.

설치 순서는 다음과 같다.

1. 새 Gem을 만들고 목적을 비기술 문제의 모순 해결로 적는다.
2. 지침에 여덟 단계 프로토콜을 넣는다.
3. 지식 영역에 원리 파일을 추가한다.
4. 미리보기에서 정상 작동 문제를 실행한다.
5. 저장한 뒤 새 대화에서도 같은 중단 규칙이 작동하는지 확인한다.

교차 테스트에서 Gemini는 승인 전 중단은 잘 지켰지만, 승인 후 제약의 뜻을 바꿨다. 따라서 Gem 지침에는 제약의 의미를 바꾸기 전에 다시 승인받는다는 문장을 유지한다. 원리마다 대안 두 개를 각각 쓰게 하고, 선택하지 않은 원리를 중간에 추가하지 못하게 한다.

두 가지 작동 모드

프로젝트 지침에는 문제 유형에 따라 모드를 나누는 규칙을 넣는다.

이 책의 주력은 범용 원리 모드다. 회의 시간, 보고서 가독성, 고객 피로도 같은 문제를 공학 파라미터로 변환하지 않는다. 자연어로 목표와 제약을 적고, 개선-악화형 또는 동시 상태형 모순을 승인한다.

기술 문제를 다룰 때도 프로젝트가 전문가를 대신하지 않는다. 파라미터 선택과 기술 안전성, 특허 가능성은 해당 분야의 검토가 필요하다. 이 책에서는 정통 매트릭스 모드의 존재와 경계만 안내한다.

재사용 도구 설치: 이름보다 기능을 본다

플랫폼마다 재사용 기능의 이름이 다르다. ChatGPT의 GPT, Gemini의 Gem, Claude의 프로젝트처럼 구현 방식도 제공 범위도 다르다. 이 책에서는 이를 묶어 재사용 도구라고 부른다.

재사용 도구에는 네 요소가 있어야 한다.

• 실행 프로토콜
• 원리 지식 파일
• 정상 작동 테스트
• 버전 기록

이름과 설명도 기능 중심으로 쓴다. 창의성 천재보다 모순 승인 후 대안을 만드는 업무 문제해결 도구가 낫다. 사용자가 언제 켜고 언제 일반 대화를 써야 하는지 시작 화면에 적는다.

버전 기록에는 프롬프트 길이보다 변경 이유를 남긴다.

v1.0: 7단계 라이트판
v1.1: 비기술 용어, 원리별 대안, 제약 재승인 규칙 보완

모델이 바뀌거나 지식 파일을 수정하면 같은 정상 작동 문제를 다시 실행한다. 재사용 도구는 한 번 만들어 끝나는 물건이 아니라, 작동을 확인하며 유지하는 절차다.

프로젝트 지침을 고쳤다면 날짜, 바꾼 문장, 바꾼 이유, 시험 결과를 한 줄로 남긴다. 답이 마음에 들지 않아 수정보다 Gemini가 발언 기회를 문서 작성으로 재해석해 제약 재승인 규칙 추가처럼 기록한다. 다음 수정 때 어떤 문제를 해결하려 했는지 알 수 있다.

지식 파일도 같은 방식으로 관리한다. 원리 설명을 바꿨는데 대안 품질이 나빠지면 이전 문구로 돌아갈 수 있어야 한다. 파일 이름에 날짜를 계속 붙이기보다 문서 상단에 버전 표를 두고 최신 파일 하나를 프로젝트에 유지하는 편이 덜 헷갈린다.

정상 작동 테스트

설치 직후에는 실제 회사의 가장 어려운 문제를 넣지 않는다. 조건이 분명하고 결과를 비교하기 쉬운 고정 문제를 사용한다.

이 책의 테스트 문제는 6명 회의를 60분에서 30분으로 줄이되 전원의 발언 기회와 주요 쟁점 기록을 유지한다였다. 사전 준비 10분 이내, 새 도구 도입 불가라는 조건도 붙였다.

다섯 항목을 본다.

1. 목표와 제약을 정확히 되풀이하는가
2. 비기술 문제에 개선-악화형이라는 표현을 쓰는가
3. 승인 전 해결책을 멈추는가
4. 선택 원리마다 대안 두 개를 만드는가
5. 제약의 의미를 바꿀 때 다시 묻는가

하나가 빠지면 전체 지침을 길게 다시 쓰지 않는다. 빠진 규칙을 지침의 해당 단계에 한 문장으로 추가하고 같은 문제를 다시 실행한다.

설치의 끝은 파일 업로드가 아니다. 같은 문제를 새 대화에서 넣어도 핵심 절차가 재현되는 상태다.

이 장에서 내 AI에 추가된 기능 3개

1. 대화용 엔진을 프로젝트 지침과 지식 파일로 분리해 고정하는 기능
2. 플랫폼이 달라도 같은 정상 작동 문제로 절차 충실도를 확인하는 기능
3. 비기술 문제와 기술 문제를 서로 다른 모드로 처리하는 기능