1. 아름다운 문구가 아닌 계약으로서의 system‑prompt
이전 모듈에서는 ChatGPT App을 아키텍처 관점에서 보았습니다: 위젯, tools, 그리고 MCP 서버. 이번 강의에서는 모델에게 그 역할을 어떻게 말로 설명할지에 집중합니다. 무엇을 할 수 있고, 무엇은 하지 말아야 하며, 도구는 어떻게 사용하는가. 본질적으로 우리는 system‑prompt를 여러분과 모델 사이의 계약으로 설계할 것입니다.
일반적인 ChatGPT 채팅에서는 “너는 유쾌한 해적 조수라고 상상해”나 “다섯 살 아이에게 설명하듯 말해” 같은 프롬프트에 익숙할 수 있습니다. 이것은 페르소나와 스타일에 관한 것입니다. 하지만 ChatGPT App 맥락에서 system‑prompt라는 용어는 전혀 다른 의미를 가집니다.
여기서 system‑prompt는 사용자에게 보이지 않는 첫 번째 역할 메시지인 system으로, 모델에게 다음을 지정합니다.
- 이 App의 범위에서 모델이 누구인지;
- 어떤 과제에 집중해야 하는지;
- 무엇을 하지 말아야 하는지;
- 언제, 어떻게 애플리케이션의 도구를 호출해야 하는지.
즉, 이는 형식적 계약에 매우 가까운 행동 사양입니다. 합의가 잘 되어 있다면 모델은 그 계약을 따르려 노력합니다. 합의가 없다면 모델은 평범한 “일반” ChatGPT처럼 행동할 것이고, 여러분의 훌륭한 App은 한쪽 구석으로 밀려나 버릴 겁니다.
중요한 점은 ChatGPT App에서 이 system‑prompt가 다음과 같다는 것입니다.
- 애플리케이션 자체에 묶이며, 특정 대화 하나에 한정되지 않습니다;
- 위젯 사용과 tools 호출 모두에 경계를 부여합니다;
- 사용자가 여러분의 애플리케이션과 대화하는 동안, 즉 App 세션이 지속되는 동안 살아 있습니다.
요약하면 이런 계약입니다. 여러분은 모델에게 도구를 제공하고, 어떤 종류의 어시스턴트인지, 무엇을 하고 무엇은 하지 않는지, 도구는 어떻게 쓰고 사용자 데이터는 어떻게 다루는지 역할을 설명합니다. 모델은 그에 맞춰 행동하려고 합니다.
2. 아키텍처에서 system‑prompt가 위치하는 곳
이게 어떤 마법 같은 실체가 아니라는 점을 보여 주기 위해 그림으로 보는 것이 도움이 됩니다.
sequenceDiagram
participant User as 사용자
participant ChatGPT as ChatGPT + 모델
participant App as 당신의 ChatGPT App
participant MCP as MCP/백엔드
Note over ChatGPT: App 초기화 시
모델에 system‑prompt가 전달됨
User->>ChatGPT: "친구에게 줄 선물을 $50 이하로 찾아줘"
ChatGPT->>ChatGPT: system‑prompt와 tools 설명을 적용
ChatGPT->>App: callTool recommend_gifts(...)
App->>MCP: HTTP /tools/recommend_gifts
MCP-->>App: 선물 목록
App-->>ChatGPT: Tool result (JSON)
ChatGPT-->>User: 텍스트 + 카드 위젯 표시 지시
system‑prompt는 App이 초기화될 때, 즉 ChatGPT가 대화에 여러분의 애플리케이션을 “연결”하기로 할 때 모델에 전달됩니다. 이후 ChatGPT의 모든 결정—도구를 부를지 말지, 위젯을 제안할지, 데이터가 없을 때 무엇을 말할지—은 이 계약의 프리즘을 거치게 됩니다.
Apps SDK의 코드 관점에서는 보통 App 구성 옆 어딘가에 놓인 문자열일 뿐입니다. 예를 들면:
// app/config/systemPrompt.ts
export const giftGeniusSystemPrompt = `
당신은 GiftGenius, 선물 추천을 돕는 어시스턴트입니다...
`;
그다음 이 문자열은 여러분의 애플리케이션이 ChatGPT와 연결되는 지점으로 전달됩니다. 기술적인 “랩핑”은 다를 수 있지만, 중요한 점은 다음과 같습니다. system‑prompt는 도구의 스키마나 React 컴포넌트처럼 똑같이 다루어야 할 코드 아티팩트이며, 동일한 주의도로 설계하고 보관해야 합니다.
이제 system‑prompt가 아키텍처에서 어디에 있고 모델에 어떻게 전달되는지 이해했으니, 가장 중요한 것은—그 안에 무엇을 넣어 계약으로 만들 것인지입니다. “귀여운 페르소나” 설명으로 끝나지 않도록요.
3. App의 역할과 책임 범위
정상적인 system‑prompt의 첫 번째이자 가장 중요한 섹션은 당신이 누구이며 무엇에 책임지는가입니다.
“페르소나”와 “App 계약”의 차이는 단순합니다. “너는 해적이고 뱃사람 말투로 말해”는 톤에 관한 것입니다. “너는 우리 선물 카탈로그에 대한 인터페이스이고, 선물을 추천하며 다른 주제에는 관여하지 않는다”는 계약입니다.
선물을 추천하는 학습용 애플리케이션 GiftGenius의 경우, 역할의 핵심은 다음과 같이 정리할 수 있습니다.
역할:
- 당신은 GiftGenius, 우리 서비스의 선물 추천 어시스턴트입니다.
- 당신의 임무는 오직 우리 카탈로그만 사용하여 사용자가 알맞은 선물을 고르도록 돕는 것입니다.
- 의학적, 법률적, 금융적 조언은 하지 않습니다.
강조점을 확인하세요.
첫째, 도메인을 좁게 정의합니다. 우리 서비스 범위의 선물 추천에만 집중합니다. 이렇게 해야 모델이 여러분의 App을 열어야 할 때 “양자역학”을 설명하기 시작하지 않고, 다른 애플리케이션을 둘러싼 이상한 워크플로를 대신 만들려고 하지 않습니다.
둘째, App이 하지 않는 일을 명확히 고정합니다. 예를 들면:
- 선물 및 구매와 관련 없는 주제에 대한 조언을 하지 않습니다;
- 카탈로그에 없는 선물을 지어내지 않습니다;
- 사용자를 대신해 결정을 내리지 않고, 옵션을 제시하고 근거를 설명할 뿐입니다.
이런 부정적 제약은 종종 긍정적 지시보다 더 중요합니다. 모델은 “무엇이든” 할 수 있으므로, system‑prompt에서 불필요한 부분을 잘라내는 것입니다.
한 개발자가 여러 App(예: “선물 추천”과 “주문 배송 추적”)을 운영하는 더 복잡한 환경에서는, 이 system‑prompt에 이 App에서는 선물 추천만 담당하며 주문/물류 관리는 맡지 않고 다른 애플리케이션을 실행하지 않는다고 명시하는 것이 유용합니다. 이렇게 해야 “누구의 일인지” 모델이 헷갈릴 위험이 줄어듭니다.
4. 언제 App을 호출하고, 언제 스스로 답할까
다음으로 중요한 계약 블록은 도구 사용 규칙입니다.
이를 명시하지 않으면 보통 두 가지 극단으로 흐릅니다.
- 모델이 거의 App을 호출하지 않습니다. 왜냐하면 “머릿속” 지식으로 답하는 편이 더 쉽고 저렴하기 때문입니다;
- 반대로, 가장 이론적인 질문에도 이유 없이 도구를 호출하기 시작합니다.
App을 위한 system‑prompt에는 다음을 꽤 명확하게 고정해야 합니다.
- 어떤 경우에 도구를 사용해야 하는지;
- 어떤 경우에 도구 없이 스스로 답해야 하는지;
- 사용자가 “애플리케이션을 열지 말라”고 명시적으로 요청할 때 어떻게 할지.
GiftGenius를 위한 텍스트 조각 예시는 다음과 같습니다.
도구 사용:
- 카탈로그의 사실 데이터(선물 목록, 가격, 상품 유형, 배송/할인 여부)가 필요할 때 App의 도구를 사용하세요.
- 질문이 이론적이고 카탈로그 접근이 필요 없다면(예: "보통 집들이에는 어떤 선물을 주나요") 도구를 쓰지 말고 직접 답하세요.
- 사용자가 "애플리케이션을 열지 말아 달라"거나 "위젯 없이 답해 달라"고 명시하면 이를 존중하고 도구를 호출하지 마세요.
여기에는 몇 가지 중요한 사항이 담겨 있습니다.
첫째, tools 호출을 요청 유형에 묶습니다. 사실/카탈로그 데이터 → 도구, 일반 이론 → 모델이 직접 답변.
둘째, 사용자 의도 존중을 명확히 말합니다. 사람이 “아무 것도 실행하지 말고 그냥 설명해”라고 썼다면, 모델이 그 신호를 무시해서는 안 됩니다.
셋째, 이렇게 App 사용 빈도를 관리합니다. 좋은 system‑prompt는 모델이 균형을 찾도록 돕습니다. 필요한 경우에만 App을 사용하고, 언제나 끼어드는 성가신 팝업이 되지 않도록요.
다음 UX 지침 강의에서 위젯 실행을 모델이 어떻게 알리고 시나리오 종료 후 무엇을 말해야 하는지 따로 다룹니다. 여기서는 의사결정 규칙—App을 사용할지 말지—에 초점을 맞춥니다.
5. tools의 안전한 사용과 사용자 데이터 처리
이번에는 보안과 상식에 관한 이야기입니다.
여러분의 App 도구는 다양할 수 있습니다.
- 공개 데이터(선물 카탈로그, 재고, 배송 조건)를 다루는 도구;
- 개인 데이터를 다루거나 사용자 명의로 행동을 수행하는 도구(주문 생성, 결제, 설정 변경).
system‑prompt에서 모델이 이러한 차이를 어떻게 다뤄야 하는지 표시해야 합니다.
전형적인 규칙 묶음:
보안 및 프라이버시:
- 사용자 동의가 필요한 행동(구매, 구독, 개인정보 변경)을 명시적 채팅 확인 없이 수행하지 마세요.
- 도구가 동작하는 데 필요한 데이터만 전달하세요(데이터 최소화).
- 민감한 데이터(건강, 금융, 아동)가 관련된 요청이라면, 먼저 이 데이터를 앱에 전달해도 되는지 사용자의 확인을 받으세요.
여기서 우리는 여러 과제를 동시에 해결합니다.
첫째, 예기치 않은 활동으로부터 사용자를 보호합니다. 모델은 임의로 선물을 구매하거나 주문을 생성해서는 안 됩니다(여러분이 그런 도구를 제공했다 하더라도). 먼저 텍스트로 확인을 받고, 그다음 도구를 호출해야 합니다.
둘째, 과도한 데이터 유출 위험을 낮춥니다. 모델은 보통 도구 인자에 “보이는 모든 것”을 넣으려는 경향이 있으므로, 최소한의 필드로 제한하라고 명시합니다.
셋째, 재정 도구가 없어도 법적/윤리적 리스크가 될 수 있는 민감 도메인을 별도로 강조합니다.
좋은 실무는—위험한 도구의 설명(description)에 상태 변경이나 결제를 수행한다고 명시하고, 이를 system‑prompt 수준에서도 중복하는 것입니다. 이렇게 하면 이중 장벽—계약과 도구 설명—이 생깁니다.
6. system‑prompt의 형식과 스타일: 사양처럼 쓰기
가장 흔한 실수 중 하나는 system‑prompt를 마케팅 문구로 쓰는 것입니다. “너는 혁신적이고 믿을 수 없을 만큼 똑똑한 어시스턴트로 세상을 더 좋게 만들어…” 같은 표현은 보기엔 멋지지만 모델에게는 아무 소용이 없습니다. 모델이 궁금한 것은 다음뿐입니다.
- 나는 누구인가;
- 무엇을 해야 하는가;
- 무엇을 하지 말아야 하는가;
- 도구는 어떻게 쓰는가;
- 데이터와 다른 App을 어떻게 대하는가.
따라서 system‑prompt는 사양처럼 다루는 것이 좋습니다.
- “역할”, “작업”, “경계”, “도구 사용”, “보안”처럼 논리 블록으로 나눕니다;
- 블록 안에서는 짧고 의미가 모호하지 않은 문장을 씁니다;
- “해야 할 일”과 “하지 말아야 할 일”을 명확히 구분합니다(프롬프트 내부 목록은 매우 적절합니다).
GiftGenius를 위한 구조화된 프롬프트의 한 조각은 다음과 같습니다.
역할:
- 당신은 GiftGenius, 우리 서비스의 선물 추천 어시스턴트입니다.
작업:
- 사용자의 과제, 수 recipient의 관심사, 예산에 맞게 선물을 고르도록 돕습니다.
- 각 옵션의 장단점을 쉬운 언어로 설명합니다.
하지 말 것:
- 카탈로그에 없는 선물을 지어내지 마세요.
- (예: 카탈로그에 유료라고 되어 있는데) 없는 서비스를 약속하지 마세요(예: 무료 배송).
문체는 중립적이고 “건조하게” 두는 것이 좋습니다. 판매 문구가 아니라 계약입니다. 모호함이 적을수록 동작이 안정적입니다.
또 하나의 중요한 실무: system‑prompt를 코드와 함께 리포지토리에서 버전 관리하는 것입니다. 프롬프트에도 버전이 있고, 그 변화는 TypeScript 로직 변경만큼 동작을 깨뜨릴 수 있습니다. PR 리뷰에서 다음과 같은 diff를 보는 게 훨씬 낫습니다.
- 카탈로그에 없는 선물을 지어내지 마세요.
+ 카탈로그에 없는 선물을 지어내지 마세요, 사용자가 "아무거나 만들어줘"라고 명시적으로 요청하더라도.
인터페이스에서 “문구를 살짝 조정했다”는 기억에 의존하기보다 훨씬 낫습니다.
7. 학습용 App을 위한 system‑prompt 전체 예시
이제 모두 합쳐서 학습용 GiftGenius를 위한 깔끔한 system‑prompt를 작성해 보죠. 읽고 수정하기 쉽도록 조각으로 나눕니다.
먼저 역할과 작업을 설명합니다.
역할:
- 당신은 GiftGenius, 우리 서비스의 선물 추천 어시스턴트입니다.
- 사용자가 먼저 쓰지 않는 한, 속어와 농담 없이 정중하고 비즈니스 톤으로 대화합니다.
작업:
- 지정된 매개변수(수령인 프로필, 관심사, 계기, 예산)에 따라 선물을 고르는 데 도움을 줍니다.
- 왜 이러한 옵션을 제시하는지 그 이유를 쉽고 명확한 언어로 설명합니다.
이제 경계와 제한을 명시합니다.
책임 범위:
- 우리 선물 카탈로그와 그 메타데이터만 사용합니다.
- 카탈로그나 도구 응답에 없는 선물, 프로모션, 할인은 만들어내지 마세요.
- 의학적, 법률적, 금융적 조언은 하지 마세요.
- 다른 애플리케이션이나 사이트의 동작에 대해 책임지지 않습니다. 사용자가 그것을 묻는다면 도울 수 없다고 말하세요.
도구 사용 규칙을 추가합니다.
도구 사용:
- 수령인에 대한 자유 서술을 관심사 세그먼트로 변환해야 할 때 tool `profile_to_segments`를 사용하세요.
- 사용자 매개변수(세그먼트, 예산, 계기, 로케일)에 따라 선물을 찾거나 필터링할 때 tool `recommend_gifts`를 사용하세요.
- 특정 선물의 상세 정보(설명, 유형, 가격, 배송 제한)가 필요할 때 tool `get_gift`를 사용하세요.
- 도구를 호출하기 전에, 그렇게 하지 않으면 결과가 쓸모없을 경우 누락된 매개변수(수령인 나이, 예산, 계기)를 먼저 확인하려고 하세요.
- 요청이 이론적이라면(예: "결혼 1주년 선물은 전반적으로 어떻게 고르면 좋나요") 도구를 호출하지 말고 직접 답하세요.
이제—보안과 사용자 명의의 행동에 관한 블록입니다.
보안:
- 명시적 채팅 확인 없이 구매, 구독 또는 선물 발송을 진행하지 마세요.
- 도구에 개인정보(수령인 e‑mail, 배송 주소, 이름)가 필요하다면, 먼저 왜 필요한지 사용자에게 설명하고 확인을 요청하세요.
- 필요한 것보다 많은 데이터를 도구에 전달하지 마세요(예: 연령, 관심사, 예산이면 충분한데 전체 메시지를 통째로 보내지 마세요).
그리고 전체 톤/글로벌 규칙입니다.
일반 규칙:
- 도구가 빈 결과를 반환하면 이를 솔직히 알리고 조건을 완화하도록 제안하세요(예산, 선물 유형, 카테고리 또는 계기 변경).
- 사용자가 "애플리케이션을 열지 말아 달라"거나 "위젯 없이 해 달라"고 요청하면 이를 존중하고 tools 호출 없이 텍스트로만 답하세요.
- 요청이 선물이나 구매와 관련이 없다면 기본 ChatGPT처럼 답하고 GiftGenius 도구는 사용하지 마세요.
결과적으로 이 구성은 보충 자료의 예시와 매우 유사합니다. “역할”, “작업”, “해야 할 일/하지 말 것”, “도구 사용”, “보안”, “일반 규칙” 섹션이 있습니다.
Next.js 코드에서는 이를 별도의 모듈로 구성할 수 있습니다.
// app/config/giftGeniusPrompt.ts
export const giftGeniusSystemPrompt = `
역할:
- 당신은 GiftGenius, 우리 서비스의 선물 추천 어시스턴트입니다.
...
일반 규칙:
- 요청이 선물과 관련이 없다면 기본 ChatGPT처럼 답하고 GiftGenius 도구는 사용하지 마세요.
`;
그런 다음 App 구성에서 이 상수를 사용합니다(구체적인 방법은 Apps SDK 버전에 따라 다르지만, 아이디어는 동일합니다. 이 텍스트가 App 대화 초기화 시 system 역할로 전달됩니다).
8. system‑prompt의 동적 컨텍스트
때로는 system‑prompt에 약간의 동적 정보를 “섞어” 넣어야 합니다. 현재 날짜, 로케일, 사용자 유형(신규/기존 고객), 구독 상태 등입니다.
예를 들어, 지역별로 선물 카탈로그와 가격이 다르다면, system‑prompt에 현재 지역을 전달할 수 있습니다.
export function buildSystemPrompt(locale: string) {
return `
역할:
- 당신은 ${locale} 지역을 위한 선물 추천 어시스턴트 GiftGenius입니다.
경계:
- ${locale} 지역에서 이용 가능한 선물과 가격만 사용하세요.
...
`;
}
Apps SDK는 App 초기화 시 _meta["openai/locale"]를 제공할 수 있고, 여러분은 이를 바탕으로 필요한 프롬프트 변형을 생성할 수 있습니다. 로컬라이제이션은 나중에 자세히 다루겠지만, system‑prompt가 항상 정적일 필요는 없다는 점을 지금도 알아두면 좋습니다.
핵심은—조건문 스파게티로 만들지 않는 것입니다. 로직이 너무 복잡해지면 App을 분리하거나 로직을 tools로 옮기는 편이 낫습니다(예: MCP 서버가 locale에 따라 적절한 데이터 소스를 스스로 선택). system‑prompt에는 상위 수준의 규칙만 남기세요.
9. system‑prompt와 tools 설명 및 UX 지침의 관계
이 강의는 system‑prompt에 집중하지만, 실제 App에서는 단독으로 존재하지 않습니다. 도구 설명(description, inputSchema)과 이후 주제에서 다룰 follow‑up 예시도 있습니다. 이 모든 것이 함께 하나의 지시 체계를 이룹니다.
tools 호출 관리:
- system‑prompt는 “도구는 사실 데이터에만”, “선물 지어내지 말 것”, “확인 없이 구매하지 말 것” 같은 철학을 설정합니다;
- tools의 descriptions는 recommend_gifts가 정확히 무엇을 하는지, 어떤 매개변수가 필요한지, 언제 호출해야 하는지를 구체화합니다;
- follow‑up 문구는 도구 호출 이후의 대화 스타일을 규정합니다. 예를 들어 결과가 없을 때 정직하게 말하는 법, 요청을 어떻게 수정 제안할지, 결과를 요약하는 방법 등입니다.
이 세 층이 정합적이면 모델은 예측 가능하게 행동합니다.
- 정말 필요할 때만 App을 호출합니다;
- 카탈로그 밖의 선물/상품을 지어내지 않습니다;
- 무엇이 일어났는지(찾음/못 찾음/추가 정보 필요) 사용자가 이해할 수 있게 설명합니다.
정합적이지 않다면—예측 불가능한 행동과 끝없는 “마법의 프롬프트 튜닝” 세션을 얻게 됩니다. 모두가 금세 지치게 됩니다.
10. system‑prompt ChatGPT App 작업 시 흔한 실수
실수 1: system‑prompt를 “보기 좋게”만 쓰고 계약으로 쓰지 않는다.
개발자들이 “사용자가 과제를 해결하도록 도와줘”, “친절하게 대화해” 같은 일반론으로 끝내는 경우가 아주 흔합니다. 그러나 이것만으로는 모델이 언제 App을 호출할지, 책임 경계가 어디인지, 데이터를 지어내도 되는지, 도구 오류 시 무엇을 해야 하는지가 전혀 명확해지지 않습니다. 결과적으로 로직의 절반은 코드 스택과 작성자의 머릿속에 흩어지고, 명시적인 계약으로 묶이지 않습니다.
실수 2: 역할을 지나치게 넓게 잡는다(“모든 걸 도와줘”).
역할 섹션에서 “너는 사용자의 모든 질문을 도와주는 어시스턴트야”라고 쓰면, 모델은 기쁜 마음으로 바로 그 일을 하고 App을 종종 잊어버립니다. App은 모델이 “나 혼자도 할 수 있어”라고 판단하여 거의 쓰이지 않는 선택 사항으로 변합니다. 니치를 명확히 하세요. 선물 추천, 선물 카탈로그 작업, 특정 도메인 지원처럼요.
실수 3: 도구를 언제 호출할지에 대한 규칙이 없다.
“필요에 따라 도구를 사용해” 같은 문구는 너무 모호합니다. 모델은 tools를 완전히 무시하거나, 오히려 머릿속 지식만으로 답할 수 있는 상황에서도 도구를 호출할 수 있습니다. 시나리오를 명확히 구분해야 합니다. 사실 데이터 → 도구, 배경 설명 → 모델 자체 답변, 사용자가 App을 거부 → 텍스트만.
실수 4: “지어내지 마” 한 줄로 환각 문제를 해결하려고 한다.
“환각하지 마”라는 말만으로는 거의 도움이 되지 않습니다. 정확히 무엇을 지어내면 안 되는지(카탈로그 밖의 상품/선물, ID 없는 항목, 존재하지 않는 할인)와, 결과가 비었을 때 무엇을 해야 하는지(정직하게 없다고 말하기)를 명시해야 합니다. 그렇지 않으면 모델은 “잘 보이려는” 성향 때문에 여전히 허구의 옵션을 만들어낼 것입니다. system‑prompt의 전역 금지, tools 설명의 제약, “없을 때” 응답 템플릿—이 전체 세트가 필요합니다.
실수 5: 보안과 사용자 동의를 무시한다.
만약 system‑prompt에 구매, 예약, 개인정보 변경이 명시적 확인을 필요로 한다는 내용이 없다면, 모델은 “선의”를 근거로 스스로 도구를 호출할 수 있습니다. UX 관점에서 이는 재앙입니다. 금융이나 계정과 관련된 모든 행동은 채팅에서 명시적으로 동의한 이후에만 수행된다고 항상 명시하세요.
실수 6: 다른 App과 도구의 존재를 고려하지 않는다.
하나의 계정에 여러 App과 수많은 tools가 있는 환경에서는, 모델이 “알아서” 어떤 앱을 써야 할지 추론할 것이라고 기대해선 안 됩니다. system‑prompt가 이것이 바로 “선물 선택을 위한 App이며 그 일만 한다”고 못 박지 않으면, 모델은 서로 다른 App 사이를 예측 불가능하게 전환하거나 도구를 잘못된 용도로 쓰려 할 수 있습니다.
실수 7: 버전 관리와 테스트 없이 “실시간”으로 system‑prompt를 수정한다.
설정에 들어가 한 줄 바꾸고 “더 좋아졌을 거야”라고 믿고 싶어집니다. 실제로 프롬프트의 어떤 수정도 다른 시나리오의 동작을 망가뜨릴 수 있습니다. system‑prompt를 리포지토리에 보관하지 않고, diff를 보지 않으며, 테스트 요청 세트(golden prompt set—이 모듈에서 다룰 예정)를 돌리지 않는다면, 회귀를 몇 주간 쫓게 될 것입니다.
GO TO FULL VERSION