作者 주: Heimstaden 환경 위험 평가 프로젝트를 사례로, 개발자가 아닌 사람이 Codex로 데이터를 탐색·정제하고 처리 프로세스를 구축할 때 어떻게 AI와 역할을 나누는지 살펴봅니다. 방법론의 주도권과 사람의 검증이 왜 도메인 전문가에게 남아 있어야 하는지도 설명합니다.
많은 비즈니스 분석가가 업계는 잘 알지만 코드는 작성하지 못해요. ‘데이터가 수십 개의 공개 출처에 흩어져 있고 형식도 제각각인’ 프로젝트를 만나면, 예전에는 기술팀의 지원을 기다리거나 외부 컨설턴트를 고용할 수밖에 없었죠. 이 글에서는 공개된 실제 사례를 바탕으로 개발자가 아닌 사람이 Codex로 데이터 처리 프로세스를 구축할 때 사람과 AI가 역할을 나누는 방법을 소개해요. 특히 방법론의 주도권과 사람의 검증이라는 두 가지 원칙을 중점적으로 살펴봅니다.
이 글은 ‘AI가 모든 일을 대신해 준다’는 홍보 글이 아니에요. 사례에는 눈에 띄는 수치도 있지만 공개되지 않은 세부 사항도 많아요. 확인된 사실과 추론을 구분해 설명할게요.
핵심 가치: 이 글을 읽고 나면 데이터 프로젝트에서 코딩 에이전트에 어떤 단계를 맡기고, 어떤 책임은 직접 유지해야 하는지 알 수 있어요. 일회성 분석을 팀이 지속적으로 발전시킬 수 있는 역량으로 만드는 방법도 이해할 수 있습니다.
비개발자가 Codex로 데이터 처리 워크플로를 구축할 때의 핵심
2026년 11월 3일, OpenAI는 유럽 주거용 부동산 운영사 Heimstaden의 고객 사례를 공개했어요. 이 사례에는 소프트웨어 개발 경험이 없는 환경 지속가능성 분석가 Julia Erlandsen이 Codex를 활용해 전체 자산 포트폴리오의 환경 위험 평가를 완료한 이야기가 담겨 있어요. 참고할 만한 핵심 내용을 표로 정리했어요.
| 핵심 | 사례의 내용 | 독자에게 주는 시사점 |
|---|---|---|
| 문제의 성격 | 정보는 존재하지만 여러 공개 자료와 형식, 데이터셋에 흩어져 있음 | 에이전트를 활용하기 좋은 ‘데이터 분산형’ 프로젝트를 알아볼 수 있음 |
| 에이전트의 역할 | 데이터 탐색, 정제와 표준화, 품질 검사, 반복 가능한 처리 워크플로 개발 | 에이전트에 맡길 수 있는 단계를 명확히 구분할 수 있음 |
| 전문가의 역할 | 방법론과 검증은 분석가가 계속 통제 | 결론의 신뢰성을 지키는 기준을 확보할 수 있음 |
| 규모와 결과 | 자산 20,112개를 평가하고 활용 가능한 데이터 600만 행 이상 생성 | 비개발자도 상당한 규모의 데이터를 처리할 수 있음을 보여줌 |
| 장기적 이점 | 일회성 프로젝트가 반복 가능한 역량으로 전환되어 외부 컨설턴트가 필요 없어짐 | 방법론을 직접 보유하고 이후에도 스스로 개선할 수 있음 |
Codex 데이터 처리 워크플로에서의 역할 분담
이 사례의 핵심은 간단해요. Codex는 데이터 탐색, 정제, 표준화, 품질 검사와 반복 가능한 처리 워크플로 개발을 지원했고, Julia는 방법론과 검증에 대한 통제권을 유지했어요. 데이터를 정리하고 실행 가능한 워크플로로 만드는 일은 에이전트에 맡기되, 위험 판단 기준과 결과의 정확성은 사람이 책임지는 거예요.
이 경계가 중요한 이유는 환경 위험 평가가 기후 위험 평가, 보고 규정 준수, 투자 의사결정에 활용되기 때문이에요. 방법론을 에이전트의 기본 가정에 맡기면 분석가는 투자자나 감사 담당자에게 결론이 어떻게 도출됐는지 설명할 수 없어요. Julia도 “이제 우리는 이 방법론을 보유하고 있으며, 계속해서 직접 발전시킬 수 있습니다”라고 말했어요. 여기서 ‘보유’란 결과표를 갖고 있는 것뿐 아니라 평가 논리를 이해하고 통제한다는 뜻이에요.
비개발자를 위한 Codex 데이터 처리 과정의 역할 분담 원칙
사례의 역할 분담을 정리하면 더 일반적인 분담표를 만들 수 있어요. ‘사례에서 세부 사항 공개 여부’는 원문에 관련 내용이 나와 있는지를 뜻해요. 표의 권장 방식은 일반적인 데이터 프로젝트 경험을 바탕으로 정리한 것으로, Heimstaden의 실제 작업 방식을 뜻하지는 않아요.
| 단계 | 코딩 에이전트 담당 | 도메인 전문가 담당 | 사례에서 세부 사항 공개 여부 |
|---|---|---|---|
| 데이터 탐색 | 후보 데이터 소스를 검색하고 목록화하며 필드의 의미 설명 | 출처의 권위와 평가 목적에 대한 적합성 판단 | 구체적인 데이터 소스는 공개되지 않음 |
| 정제 및 표준화 | 형식, 단위, 인코딩 통일 및 좌표와 주소 매칭 | 결측값과 충돌하는 값의 처리 방식 결정 | 규칙은 공개되지 않음 |
| 품질 검사 | 자동 검사 작성 및 이상 항목 목록 출력 | ‘무엇을 이상으로 볼지’ 정의하고 표본 재검토 | 방법과 오류율은 공개되지 않음 |
| 프로세스 구축 | 각 단계를 반복 실행할 수 있는 처리 프로세스로 구성 | 프로세스 논리가 방법론과 일치하는지 확인 | ‘반복 가능’하다고만 설명 |
| 방법론과 결론 | 지시에 따라 계산 수행 | 평가 프레임워크, 가중치, 임계값을 설정하고 결과에 책임 | 분석가가 담당한다고 명시 |
이 표를 바탕으로 5가지 역할 분담 원칙을 정리할 수 있어요.
- 실행은 맡길 수 있지만, 판단은 맡길 수 없어요. 에이전트는 막연한 ‘데이터 좀 정리해 줘’를 구체적인 작업으로 바꾸는 데 능하지만, ‘이 임계값이 합리적인가’는 업계를 잘 아는 사람만 답할 수 있어요.
- 방법론을 먼저 문서화한 뒤 에이전트에 맡겨요. 평가 프레임워크는 대화에 흩어진 단편적인 지시가 아니라, 스스로 명확하게 설명할 수 있는 문서여야 해요.
- 검증에는 독립적인 관점이 필요해요. 프로세스를 작성한 에이전트가 자기 결과물까지 검사하면 일부 문제만 발견할 수 있어요. 사람이 표본을 검토하고 외부 기준과 대조하는 과정은 빼놓을 수 없어요.
- 프로세스는 반복할 수 있어야 해요. 일회성 수작업 결과는 반복 개선하기 어렵지만, 다시 실행할 수 있는 프로세스는 자산이 돼요.
- 결론에 대한 책임은 언제나 사람에게 있어요. Heimstaden의 전반적인 AI 전략도 직원이 의사결정을 검토하고 승인하며, AI가 생성한 콘텐츠는 발행 전에 사람이 확인해야 한다고 강조해요.
🎯 기술 제안: 데이터 처리 과정에서 비정형 텍스트 설명을 위험 등급으로 분류하는 등 대규모 언어 모델을 호출해야 한다면, APIYI apiyi.com을 통해 동일한 인터페이스로 여러 주요 모델을 호출할 수 있어요. 같은 샘플을 여러 모델로 교차 판단하면 특정 모델의 체계적인 편향을 더 쉽게 발견할 수 있어요. 그 자체로 비용이 적게 드는 검증 방법이에요.
비개발자를 위한 Codex 데이터 처리 워크플로 빠른 시작
사례에서는 Julia가 어떤 형태의 Codex를 사용했는지, 구체적으로 어떻게 상호작용하고 작업했는지 밝히지 않았어요. 따라서 아래 단계는 사례를 재현한 것이 아니라, 그 역할 분담 방식을 참고해 개발 경험이 없는 분석가를 위해 정리한 시작 방법이에요. 요청에 따라 코드는 제공하지 않고, 각 단계에서 에이전트에게 무엇을 전달하고 직접 무엇을 확인해야 하는지만 목록으로 설명할게요.
1단계: 자연어로 방법론 설명서 작성하기
작업을 시작하기 전에 평가 로직을 문서로 명확하게 정리하세요. 예를 들어 methodology.md라는 이름을 붙일 수 있어요. 평가 목표, 필요한 지표, 각 지표의 산출 기준, 위험 수준을 구분하는 임계값, 데이터가 누락됐을 때의 처리 원칙은 최소한 포함해야 해요. 이 문서는 방법론에 대한 여러분의 ‘소유권’을 보여주는 근거예요. 앞으로 에이전트에게 워크플로 수정을 요청할 때마다 이 문서를 기준으로 삼으세요.
2단계: 에이전트가 데이터를 탐색하되, 최종 결정은 직접 내리세요
평가 목표를 에이전트에 알려주고, 활용 가능한 데이터 출처와 각 출처의 필드, 갱신 주기, 알려진 한계를 정리해 달라고 요청하세요. 각 출처가 신뢰할 만한지, 데이터 범위가 자산 분포와 맞는지는 직접 판단해야 해요. 다운로드한 원본 데이터는 별도의 raw 디렉터리에 보관하고 절대 수정하지 않도록 하세요. 이후 처리는 모두 복사본을 기준으로 진행하면 돼요.
3단계: 정제와 표준화, “모든 변경 사항을 기록하세요”
통일할 주소 형식, 좌표계, 단위, 날짜 형식 등 표준화 규칙을 에이전트에 알려주고 처리 절차를 만들어 달라고 요청하세요. 중요한 점은 각 변환 단계에서 변경 내역을 출력하도록 하는 거예요. 예를 들어 삭제한 행과 병합한 항목의 수, 매칭되지 않은 레코드를 기록하면 코드를 이해하지 못해도 처리가 적절했는지 판단할 수 있어요.
4단계: 품질 검사를 두 단계로 나누기
첫 번째 단계는 에이전트가 맡아요. 중복값, 결측값, 허용 범위를 벗어난 값, 자산 매칭 실패 등을 자동으로 검사하고 이상 항목 목록을 출력하도록 하세요. 두 번째 단계는 직접 맡아요. 결과에서 자산 일부를 무작위로 추출해 익숙한 방식으로 수동 검증하세요. 샘플링 비율과 허용 오차 기준은 미리 방법론 문서에 적고, validation_log와 같은 표에도 별도로 기록해야 해요.
5단계: 반복 실행할 수 있는 프로세스로 정착시키기
결과를 신뢰할 수 있다고 판단되면, 에이전트에게 전체 과정을 한 번의 실행으로 다시 수행할 수 있는 프로세스로 정리하고 운영 가이드도 작성하도록 하세요. 코드를 모르는 동료도 가이드를 보고 따라 할 수 있어야 해요. 여기까지 마쳐야 프로젝트가 ‘일회성 분석’에서 ‘재사용 가능한 역량’으로 바뀌어요.
| 단계 | 에이전트에 제공할 입력 | 반드시 확인할 산출물 | 흔한 위험 |
|---|---|---|---|
| 방법론 | 평가 목표와 업계 지식 | 직접 작성한 방법론 문서 | 지표 정의가 모호해 이후 반복적으로 재작업함 |
| 데이터 탐색 | 목표와 적용 범위 | 출처 목록과 한계 설명 | 신뢰성이 낮거나 오래된 데이터를 사용함 |
| 정제 및 표준화 | 표준화 규칙 | 단계별 변경 기록 | 데이터가 알림 없이 삭제돼 결과가 깔끔해 보임 |
| 품질 검사 | 이상 항목 정의와 샘플링 비율 | 이상 항목 목록과 수동 샘플링 결과 | 자동 검사만 믿고 체계적인 오류를 놓침 |
| 프로세스 정착 | 실행 및 업데이트 요구사항 | 재실행 가능한 프로세스와 운영 가이드 | 프로세스 실행 방법을 에이전트만 ‘기억’함 |
🚀 빠른 시작: 3단계나 4단계에서 여러 국가의 공개 보고서에 담긴 서술형 위험 정보를 해석하는 등 텍스트 필드를 이해하는 데 대규모 언어 모델이 필요할 수 있어요. 이때는 먼저 APIYI apiyi.com에서 소량의 샘플로 여러 모델의 출력을 비교해 보세요. 가장 안정적인 모델을 선택해 정식 프로세스에 연결하면 처음부터 전체 데이터를 단일 모델에 맡기는 위험을 줄일 수 있어요.
Codex 데이터 처리 프로세스와 다른 방식 비교
| 방식 | 방법론 소유권 | 반복 실행 가능성 | 검증 신뢰도 | 주요 문제 |
|---|---|---|---|---|
| 전적으로 수작업 | 전문가에게 있음 | 낮음, 다시 실행하기 어려운 경우가 많음 | 개인의 꼼꼼함에 달려 있음 | 인력 소모가 큼, 사례 추정치로 5명이 1년간 작업해야 함 |
| 외부 컨설턴트 | 대개 컨설턴트에게 있음 | 보통, 컨설턴트의 산출물에 의존함 | 비교적 높지만 투명하지 않음 | 후속 개선을 위해 계속 서비스를 구매해야 함 |
| 전문가 + 코딩 에이전트 | 전문가에게 있음 | 높음, 프로세스를 다시 실행할 수 있음 | 높음, 사람이 제대로 검증한다는 전제하에 | 전문가가 방법론을 체계적으로 정리할 수 있어야 함 |
| 에이전트에 전적으로 위임 | 불분명하며 기본 가정에 숨겨져 있음 | 보통 | 낮음, 결론의 근거를 설명하기 어려움 | 결론에 대해 대외적으로 책임지기 어려움 |
비교 분석
외부 컨설턴트와 비교: 외부 컨설턴트는 전문 경험과 작업 속도에서 어느 정도 강점이 있어요. 하지만 방법론이 컨설턴트에게 남는 경우가 많아, 이듬해 평가를 갱신하려면 다시 협의하고 비용도 지불해야 해요. 반면 “전문가 + 코딩 에이전트” 방식에서는 방법론이 조직 내부에 남아요. Heimstaden도 이 프로젝트 덕분에 원래 고용해야 했던 외부 컨설턴트가 필요 없었다고 명시했어요.
에이전트에 전적으로 위임하는 방식과 비교: 프로젝트 전체를 에이전트에 맡기면 가장 간편해 보이고 결과물도 빠르게 나와요. 하지만 에이전트는 결측값을 어떻게 채울지, 이상값을 어떻게 제거할지 등 수많은 세부 사항을 스스로 가정해요. 이런 가정은 업계 관행과 맞지 않을 수 있어요. 보고서의 규정 준수와 투자 의사결정을 뒷받침해야 하는 평가라면, 이런 결론은 근거를 따져 묻는 상황에서 신뢰를 얻기 어려워요.
인력 절감 수치는 객관적으로 봐야 해요. 원문에서는 “추정 작업량”이 5명이 1년간 일하는 수준에서 2명이 2개월간 일하는 수준으로 줄었다고 설명해요. 인월로 대략 환산하면 약 60인월에서 4인월로 줄어든 셈이에요. 다만 이는 회사 자체 추정치로 독립적인 검증을 거치지 않았고, 두 사람이 각각 어떤 역할을 맡았는지도 명시되지 않았어요.
💡 선택 가이드: 팀에 이미 방법론이 있지만 기술적인 실행 역량이 부족하다면 “전문가 + 코딩 에이전트” 방식을 가장 먼저 시도해 볼 만해요. 프로세스에서 모델 호출이 필요한 부분은 APIYI apiyi.com의 통합 인터페이스를 이용해 여러 모델을 바꿔 가며 비교할 수 있어요. 나중에 모델을 교체할 때도 전체 프로세스를 다시 작성할 필요가 없어요.
Codex 데이터 처리 프로세스 사례에서 알려진 것과 알려지지 않은 것
사례를 과도하게 해석하지 않도록, 원문에 명시된 정보와 공개되지 않은 정보를 나눠 정리했어요.
| 구분 | 내용 |
|---|---|
| 공개된 정보 | 분석가에게 소프트웨어 개발 경험이 없었음; Codex가 데이터 탐색, 정제 및 표준화, 품질 검사, 프로세스 개발을 지원함; 방법론 수립과 검증은 분석가가 담당함; 자산 20,112곳을 평가해 600만 행 이상의 데이터를 생성함; 외부 컨설턴트가 필요하지 않았음; 결과는 기후 리스크 평가, 보고 및 투자 의사결정에 활용됨 |
| 추정치 | 작업에 필요한 인력이 5명 1년에서 2명 2개월로 줄었다는 수치는 회사의 추정치임 |
| 공개되지 않은 정보 | 구체적인 데이터 출처; Codex 사용 형태(데스크톱, CLI 또는 기타); 상호작용 방식과 워크플로; 구체적인 검증 방법과 오류율; 사용 과정에서 겪은 어려움과 실패 경험 |
이처럼 공개되지 않은 정보가 있어도 역할 분담 원칙은 참고할 만해요. 다만 이 사례의 효율 수치를 그대로 적용할 수는 없다는 뜻이기도 해요. 실제 프로젝트에서는 ‘에이전트가 프로세스를 작성하도록 하는 일’보다 방법론을 정리하고 사람이 직접 검증하는 데 더 많은 시간이 들 수 있어요. Heimstaden 경영진이 정리한 이 한마디를 기억해 둘 만해요. AI는 잘못된 프로세스를 고칠 수는 없지만, 좋은 프로세스의 효과는 크게 증폭할 수 있어요.
자주 묻는 질문 FAQ
Q1: 개발자가 아닌 사람이 Codex로 데이터 처리 프로세스를 구축한다는 건 무슨 뜻인가요?
프로그래밍 경험이 없는 분야 전문가가 자연어로 요구사항을 설명하면, 코딩 에이전트가 데이터 수집, 정제, 검사와 프로세스 작성 등 기술 작업을 수행하는 방식이에요. 전문가는 방법론을 정하고 결과를 검증해요. Heimstaden의 환경 위험 평가 프로젝트가 공개된 사례입니다.
Q2: ChatGPT에 데이터 관련 질문을 직접 하는 것과는 어떻게 다른가요?
질문과 답변 방식은 보통 일회성 문제를 해결하는 데 쓰이고, 결과를 재현하기 어려워요. 코딩 에이전트의 가치는 반복 실행할 수 있는 처리 프로세스를 만든다는 데 있어요. 데이터가 갱신되면 다시 실행하고, 방법론이 바뀌면 수정할 수 있죠. 이것이 사례에서 말하는 “복잡한 분석 프로젝트를 반복 가능한 역량으로 바꾼다”는 뜻이에요.
Q3: 이 사례는 언제 공개됐나요?
OpenAI가 2026년 11월 3일에 공개한 사례로, 최근 기업에서 코딩 에이전트를 활용하는 방식을 보여줘요. 구체적인 수치와 도구 형태는 시간이 지나며 바뀔 수 있지만, “실행은 에이전트에게 맡기고 판단은 전문가가 한다”는 역할 분담 원칙은 더 오래 참고할 만해요.
Q4: 어떤 데이터 프로젝트에 이런 역할 분담 방식이 가장 적합한가요?
– **여러 출처의 공개 데이터 통합**: 환경, 기후, 인구 등 여러 기관에 흩어져 있는 데이터세트
– **정기 보고서**: 분기별 또는 매년 반복해서 작성하는 규제 준수 및 공시 보고서
– **자산 포트폴리오 단위의 일괄 평가**: 수천에서 수만 건의 기록을 통일된 기준으로 평가해야 하는 경우
Q5: 프로세스에서 대규모 언어 모델을 호출해야 한다면 어떻게 빠르게 시작할 수 있나요?
먼저 APIYI apiyi.com에 가입해 동일한 인터페이스로 몇 가지 주요 모델을 호출하고, 대표적인 소규모 샘플로 분류나 추출 결과를 비교해 보세요. 안정성과 기준의 일관성을 확인한 후 실제 프로세스에 연동하면 돼요. 여러 모델을 비교하는 것 자체도 사람이 검증할 때 보조 수단으로 활용할 수 있어요.
Q6: 사람의 검증은 구체적으로 어느 정도까지 해야 하나요?
이 사례에서는 검증 방법과 오류율을 공개하지 않았어요. 일반적으로는 샘플링 비율과 허용 오차 기준을 미리 정하고, 자동 검사에서 표시된 이상 항목을 하나씩 재검토해요. 정상 결과도 무작위로 추출해 확인하고, 이미 알려진 외부 기준과 비교합니다. 모든 검증 기록은 향후 감사를 위해 보관해야 해요.
Q7: 이 방식에는 어떤 한계가 있나요?
첫째, 효율성 수치는 회사의 추정치이며 독립적인 검증이 없어요. 둘째, 개발자가 아닌 사람도 방법론을 명확하게 작성할 수 있어야 해요. 그렇지 않으면 에이전트가 혼란만 키울 수 있어요. 셋째, 이 사례에는 어려움이나 실패 경험이 소개되지 않았어요. 실제 도입 시 프로세스에 오류가 생겨도 원인을 이해하기 어려울 수 있으므로, 필요하다면 기술 담당자의 도움을 받아야 해요.
Q8: “방법론을 직접 보유하는 것”이 왜 중요한가요?
방법론을 직접 보유하면 데이터가 갱신되거나 규제 요건이 바뀌고, 투자자가 추가 질문을 할 때 팀이 직접 수정하고 설명할 수 있어요. 컨설턴트를 다시 찾을 필요도 없죠. Julia가 “이제 우리는 이 방법론을 보유하고 있으며, 계속해서 직접 발전시킬 수 있다”고 말한 것도 바로 이런 장기적인 자율성을 뜻해요.
비개발자를 위한 Codex 데이터 처리 워크플로 핵심 요약 Key Takeaways
- 역할 분담: 데이터 탐색, 정제, 품질 검사와 워크플로 구축은 에이전트에 맡기고, 방법론 수립과 검증은 전문가가 담당해요
- 방법론 우선: 평가 프레임워크를 문서로 먼저 정리한 뒤, 에이전트가 문서에 따라 작업하도록 해요
- 독립적인 검증: 자동 검사, 사람이 직접 수행하는 표본 검사, 외부 기준과의 비교가 모두 필요해요
- 반복 실행이 핵심: 다시 실행할 수 있는 워크플로가 자산이 돼요. 일회성 결과물은 개선을 이어가기 어려워요
- 수치는 신중하게: 5명 1년에서 2명 2개월로 줄었다는 수치는 추정치이므로 그대로 적용하기 어려워요
- 모델 비교로 검증 보강: 대규모 언어 모델을 호출하는 단계에서는 APIYI의 통합 인터페이스로 여러 모델을 교차 검증할 수 있어요
정리
비개발자가 Codex로 데이터 처리 워크플로를 구축할 때 가장 참고할 만한 점은 효율성 수치가 아니라 명확한 역할 분담이에요.
- 에이전트는 실행을 담당해요: 데이터 탐색, 정제와 표준화, 품질 검사, 반복 실행 가능한 워크플로 구축을 맡길 수 있어요
- 전문가는 판단을 담당해요: 방법론 수립과 결과 검증은 신뢰할 수 있고 설명 가능한 결론을 내리는 데 필수적이에요
- 역량을 축적해요: 방법론을 조직이 직접 관리하고 워크플로를 다시 실행할 수 있다면, 일회성 프로젝트가 지속적으로 개선할 수 있는 조직의 역량이 돼요
지금 “데이터가 여기저기 흩어져 있고 기술 인력도 확보하기 어려운” 프로젝트를 맡고 있다면, 먼저 시간을 들여 방법론을 문서화하고 작은 규모의 시범 프로젝트부터 시작해 보세요. 워크플로에서 대규모 언어 모델을 호출하는 단계에는 APIYI apiyi.com의 통합 인터페이스로 여러 모델의 성능을 비교해, 사람이 직접 수행하는 검증을 한층 보강할 수 있어요.
📚 참고 자료
- OpenAI 고객 사례 – Heimstaden: Heimstaden이 ChatGPT와 Codex를 활용해 주거용 부동산 관리를 혁신한 사례
- 링크:
openai.com/index/heimstaden/ - 설명: 이 글에 소개된 사례의 유일한 출처로, 환경 위험 평가 프로젝트의 역할 분담과 추정 데이터가 담겨 있어요.
작성자: APIYI 기술팀
기술 교류: APIYI 웹사이트 홈페이지에서 문의해 주세요. 더 많은 모델 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.
