> For the complete documentation index, see [llms.txt](https://guide.allibee.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guide.allibee.ai/allibee/review.md).

# 계약서 검토

AI가 계약서를 조항별로 검토하고, 고쳐야 할 부분의 수정안까지 만들어 줍니다.

#### 두 가지로 시작합니다

<figure><img src="https://851683292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlYb8RCswvOdlgmdfACCT%2Fuploads%2FT4i0D9Zl0UVmBFzO1SbI%2Freview_entry_points.gif?alt=media&amp;token=d556759a-d7c8-488c-9087-4210a8989c29" alt=""><figcaption></figcaption></figure>

* **파일을 올려서 검토**: 좌측 메뉴의 `계약서 검토`에서 파일을 올립니다. 저장소에 올리지 않고 지금 이 한 건만 빠르게 봐야 할 때 사용합니다.
* **저장소 계약서를 검토**: 계약서를 열고 우측 `계약서 검토` 탭에서 실행합니다. 목록에서 계약서를 선택해 `검토`를 눌러도 같은 화면으로 이동합니다.

둘의 차이는 결과가 어디에 남느냐입니다.

* 파일을 올려서 검토한 결과는 **내 검토 내역**에 쌓입니다. 본인만 볼 수 있습니다.
* 저장소 계약서를 검토한 결과는 **그 계약서에 붙어서** 남습니다. 계약서를 열면 팀원도 최신 검토 결과를 볼 수 있습니다.

<figure><img src="https://851683292-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FlYb8RCswvOdlgmdfACCT%2Fuploads%2FHbvFiLqHCRg1ImpsCYGR%2Freview_flow.gif?alt=media&amp;token=27a462bd-577e-4694-a144-7da4132427c4" alt=""><figcaption></figcaption></figure>

#### 1. 당사자 확인하기

검토를 시작하기 전에 **우리가 어느 쪽인지**부터 정합니다. 같은 계약서라도 갑 입장인지 을 입장인지에 따라 위험한 조항이 달라지기 때문입니다.

* 워크스페이스에 등록된 회사명을 기준으로 AI가 우리 쪽을 먼저 골라 둡니다.
* 잘못 잡혔다면 직접 바꿀 수 있습니다.
* 확인했으면 `계약서 검토 실행`을 누릅니다.

{% hint style="info" %}
검토는 자동으로 시작되지 않습니다. 당사자를 확인한 뒤 직접 실행해야 크레딧이 차감됩니다.
{% endhint %}

#### 2. 검토 진행

당사자와 계약서 유형에 맞는 **검토 기준(체크리스트)**&#xC744; 찾아 조항을 하나씩 대조합니다. 해당하는 기준이 없으면 그 계약서에 맞는 기준을 새로 만들어 검토합니다.

#### 3. 검토 결과 확인

맨 위에 전체 위험 요소 개수와 등급별 건수가 표시됩니다. 등급은 세 가지입니다.

* **위험**: 없거나 한쪽에 치우쳐 있어 계약 자체가 위태로울 수 있는 조항
* **주의**: 불리하지만 다른 조항이나 법 규정으로 어느 정도 보완되는 조항
* **보통**: 고치면 유리하지만 그대로 두어도 큰 위험은 아닌 조항

한 조항에 여러 기준이 걸리면 **가장 높은 등급으로** 표시됩니다.

`전체/위험/주의/보통` 탭으로 걸러 볼 수 있고, 조항순으로 정렬됩니다. 급하다면 `위험`부터 보시면 됩니다.

{% hint style="info" %}
계약서에 아예 없는 조항은 **신설 필요**로 표시되며, 마지막 조항 다음 번호부터 매겨집니다.
{% endhint %}

#### 4. 수정안 만들기

조항을 펼치면 **확인된 위험**과 **수정 기준**이 나옵니다.

* 확인된 위험: 이 조항이 왜 문제인지 두세 문장으로 정리해 줍니다.
* 수정 기준: 어떤 기준에 걸렸는지 보여줍니다. **체크한 항목만 수정안에 반영**되므로, 받아들이지 않을 기준은 체크를 해제하면 됩니다.

정했으면 `수정안 생성`을 누릅니다. 이 조항을 그냥 넘길 거라면 `반영 안 함`을 누릅니다.

#### 5. 수정안 확인하고 반영하기

수정 제안에는 **지워지는 내용과 새로 들어가는 내용이 색으로 구분**되어 표시됩니다. 마음에 들지 않으면 `다시 제안받기`로 새로 받거나, `복사`로 텍스트만 가져갈 수 있습니다.

`계약서에 적용`을 누르면 계약서 본문이 바로 바뀝니다.

* 반영한 부분은 본문에서 색으로 표시되어 어디가 바뀌었는지 바로 알 수 있습니다.
* 되돌리고 싶으면 `되돌리기`를 누릅니다.
* 위쪽 진행 표시줄에 지금까지 몇 건을 반영했는지 나옵니다.

{% hint style="warning" %}
**수정안을 본문에 적용하려면 워드나 한글 파일이어야 하고, 전자서명을 보내기 전이어야 합니다.**\
PDF나 이미지 파일, 전자서명이 진행 중인 계약서, 뷰어 권한만 있는 경우에는 검토 결과와 수정안은 볼 수 있지만 본문에 적용할 수는 없습니다.
{% endhint %}

#### 6. 새 버전으로 저장하기

본문이 바뀌면 상단의 `새 버전으로 저장`이 활성화됩니다.

`변경하기`를 누르면 v1 다음 버전인 v2로 저장됩니다. 원본은 그대로 남아 있으니 언제든 되돌아가 볼 수 있습니다.

{% hint style="warning" %}
저장하지 않고 화면을 벗어나면 반영한 내용이 남지 않습니다. 벗어나기 전에 안내가 표시됩니다.
{% endhint %}

#### 7. 버전 확인하고 다시 검토하기

상단의 버전 기록 아이콘을 누르면 저장된 버전이 시간순으로 나옵니다. 원하는 버전을 선택해 그때의 내용을 확인할 수 있습니다.

새 버전으로 저장하면 검토 탭에 **다시 검토할지 묻는 안내**가 나타납니다.

* `계약서 검토 실행`: 바뀐 내용으로 다시 검토합니다. 반영한 수정으로 위험이 실제로 해소됐는지 확인할 수 있습니다.
* `v1 검토 결과 보기`: 이전 버전의 검토 결과를 그대로 다시 봅니다.

#### 검토한 계약서 저장하기

파일을 올려서 검토한 경우, 그 계약서는 아직 저장소에 없는 상태입니다.\
계속 관리할 계약서라면 `이 계약서 저장`으로 **체결 전** 저장소에 올려 주세요.

저장소에 올리면 달라지는 점입니다.

* 검토 이력이 **삭제할 때까지** 남습니다. 올리지 않으면 보관 기간이 지나면서 사라집니다.
* 팀원과 공유하고 함께 볼 수 있습니다.
* AI 물어보기에서 이 계약서를 찾아 질문할 수 있습니다.

####

#### 알아두세요

* 검토는 AI 크레딧을 사용합니다. 크레딧이 없으면 실행되지 않으며, 실행 전에 안내됩니다.
* 저장소에 올리지 않고 파일로만 검토한 건은 검토 이력과 파일이 **365일** 보관됩니다.
* **검토 결과는 AI 분석이며 법적 자문이 아닙니다. 중요한 판단은 반드시 원문을 확인해 주세요.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://guide.allibee.ai/allibee/review.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.