EROKE ORIGINAL WEBBOOK

혼자 일하지만 혼자 하지 않는다

혼자 일하지만 혼자 하지 않는다 웹북 표지
전체 목차23개 장
  1. 혼자 일하지만 혼자 하지 않는다: 1장 AI보다 먼저 고객의 비싼 결정을 찾는다
  2. 혼자 일하지만 혼자 하지 않는다: 2장 솔루션 인터뷰 대신 과거 행동을 묻는다
  3. 혼자 일하지만 혼자 하지 않는다: 3장 기능 목록이 아니라 유료 제안을 만든다
  4. 혼자 일하지만 혼자 하지 않는다: 4장 팔기 전에 손으로 한 번 배달한다
  5. 혼자 일하지만 혼자 하지 않는다: 5장 ChatGPT는 창업자의 질문을 날카롭게 한다
  6. 혼자 일하지만 혼자 하지 않는다: 6장 Codex는 파일과 반복을 책임지는 운영자다
  7. 혼자 일하지만 혼자 하지 않는다: 7장 한 작업은 한 봉투에 넣는다
  8. 혼자 일하지만 혼자 하지 않는다: 8장 고객 데이터와 회사 비밀을 먼저 분류한다
  9. 혼자 일하지만 혼자 하지 않는다: 9장 근거 카드는 회사의 원재료다
  10. 혼자 일하지만 혼자 하지 않는다: 10장 좋은 브리프는 결론보다 반증이 먼저 보인다
  11. 혼자 일하지만 혼자 하지 않는다: 11장 공개 버튼 앞에 사람을 세운다
  12. 혼자 일하지만 혼자 하지 않는다: 12장 랜딩 페이지는 약속과 증거만 남긴다
  13. 혼자 일하지만 혼자 하지 않는다: 13장 고객지원도 제품 데이터다
  14. 혼자 일하지만 혼자 하지 않는다: 14장 매출보다 먼저 운영 지표를 본다
  15. 혼자 일하지만 혼자 하지 않는다: 15장 14일 출시 스프린트
  16. 혼자 일하지만 혼자 하지 않는다: 16장 수익보다 먼저 문제 인터뷰를 검증한다
  17. 혼자 일하지만 혼자 하지 않는다: 17장 제안·가격·범위를 한 장으로 만든다
  18. 혼자 일하지만 혼자 하지 않는다: 18장 고객 작업을 재현 가능한 Runbook으로 바꾼다
  19. 혼자 일하지만 혼자 하지 않는다: 19장 개인정보와 회사 비밀의 보존 기한을 정한다
  20. 혼자 일하지만 혼자 하지 않는다: 20장 판매 Funnel과 운영 Capacity를 함께 본다
  21. 혼자 일하지만 혼자 하지 않는다: 21장 30일 상업 출시 실기
  22. 혼자 일하지만 혼자 하지 않는다: 22장 AI 비용과 품질을 같은 실험으로 측정한다
  23. 혼자 일하지만 혼자 하지 않는다: 23장 고객지원과 Incident를 신뢰 자산으로 만든다

ChatGPT·Codex로 만드는 1인 회사 AI 운영체제

고객 문제 검증부터 근거 기반 주간 브리프 SignalDesk의 출시와 운영까지 14일 동안 완주한다.

상태: 출간 후보 교정쇄 · 베타 리딩 대기 · 15개 장

웹북 초판 기준일 2026년 8월 2일 · 실습 fixture SIGNALDESK-2026-08

SignalDesk의 주간 리서치 상품 운영 화면
SignalDesk의 주간 리서치 상품 운영 화면

혼자 일하는 사람에게 부족한 것은 아이디어가 아니다. 오늘 팔 일을 정하고, 고객의 말을 모으고, 결과물을 만들고, 품질을 확인하고, 다음 주에도 같은 일을 반복하는 운영 체계가 부족하다. 생성형 AI는 빈 문서를 채우는 데는 능하지만, 누구의 어떤 결정을 돕는지 정하지 않으면 더 많은 초안만 만든다.

이 책은 AI로 큰돈을 보장하지 않는다. 대신 한 사람이 감당할 수 있는 작은 유료 서비스를 고르고, ChatGPT를 문제 인터뷰와 의사결정에, Codex를 파일·검증·반복 작업에 배치하는 방법을 익힌다. 완성 프로젝트는 SignalDesk다. 특정 업계의 중요한 변화를 매주 조사해 근거가 달린 의사결정 브리프로 제공하는 구독형 서비스다. 독자는 관심 분야를 채용, 교육, 이커머스, 지역 사업, 소프트웨어 중 하나로 바꿀 수 있다.

OpenAI가 2026년 공개한 자료에서는 Codex가 개발 밖의 내부 앱, 대시보드, 기획 자료와 지식 노동으로 확장되고 있으며 비개발자 개인 사용도 빠르게 늘었다. 이 책은 그 흐름을 성공담으로 소비하지 않고 작은 회사의 반복 가능한 절차로 바꾼다. 특정 메뉴와 모델명은 달라져도 목표·근거·권한·검증·회고는 남는다.

1장 AI보다 먼저 고객의 비싼 결정을 찾는다

이번 장의 약속

한 문장으로 고객과 결정을 정의하고, “모두를 위한 서비스”를 버린다. 좋은 첫 상품은 고객이 이미 시간·돈·평판을 쓰는 결정을 더 빠르고 안전하게 만든다.

“AI 뉴스 요약을 제공한다”는 상품 설명이 아니다. 뉴스는 넘친다. “직원 30명 이하 B2B SaaS의 제품 리드가 매주 도구 도입 여부를 결정하도록 공식 가격·보안·기능 변경을 한 장으로 비교한다”는 고객, 상황, 결정, 산출물이 보인다.

비싼 결정은 반드시 고가 구매만 뜻하지 않는다. 잘못된 채용 공고, 근거 없는 경쟁사 대응, 놓친 정부 지원 일정, 고객 데이터가 들어간 AI 도구 선택처럼 되돌리기 어려운 판단도 비싸다. 독자는 자신이 잘 아는 분야에서 “이번 주 안에 결정해야 하지만 자료가 흩어져 있는 일”을 찾는다.

실습: 결정 문장 10개

다음 틀로 후보를 열 개 쓴다.


[구체적인 사람]은 [정해진 시점]에 [되돌리기 비싼 결정]을 해야 하지만
[흩어진 정보·반복 작업·검증 부족] 때문에 [시간·돈·위험]을 부담한다.

각 후보를 빈도, 지불 의사, 접근 가능성, 검증 가능성, 실패 비용으로 1~5점 평가한다. 총점보다 1점 항목을 본다. 고객을 만날 수 없거나 결과의 옳고 그름을 확인할 수 없는 문제는 첫 상품에서 제외한다.

실패 복구

“누구나”, “모든 회사”, “생산성을 높인다”가 들어가면 범위가 넓다. 실제 지난달에 그 결정을 내린 사람 한 명을 떠올리고 직책, 회사 규모, 마감 시점을 넣어 다시 쓴다.

↑ 목차로 돌아가기

2장 솔루션 인터뷰 대신 과거 행동을 묻는다

사람은 미래의 구매 의사를 친절하게 과장한다. “이런 서비스가 있으면 쓰겠습니까?”보다 “마지막으로 이 결정을 내렸을 때 어떤 파일과 사이트를 열었습니까?”를 묻는다. 과거 행동에는 실제 대안과 비용이 남아 있다.

인터뷰는 AI에게 맡기지 않는다. AI는 질문 초안과 기록 정리에 쓴다. 사람은 표정, 망설임, 회사 맥락을 듣고 후속 질문을 선택한다. 녹음과 외부 모델 전송은 먼저 동의를 받는다. 동의하지 않으면 익명 메모만 남긴다.

실습: 다섯 번의 문제 인터뷰

  1. 마지막 사례의 날짜와 계기를 묻는다.
  2. 처음부터 끝까지 화면과 파일의 순서를 묻는다.
  3. 가장 오래 걸린 단계와 다시 한 일을 묻는다.
  4. 결과를 누구에게 설명했고 무엇을 근거로 냈는지 묻는다.
  5. 현재 대안에 실제로 지불한 돈·시간·기회비용을 묻는다.

인터뷰가 끝나면 ChatGPT에 익명화한 메모를 주고 반복 문장, 반례, 추가 확인 질문을 분리하게 한다. 원문 메모를 지우지 않고 AI 요약을 별도 파일로 둔다.

기대 산출물

research/interviews/I-001.md부터 I-005.md, 그리고 공통 패턴과 반례가 있는 research/patterns.md가 남아야 한다. 이메일, 전화번호, 회사 내부 숫자는 익명화한다.

↑ 목차로 돌아가기

3장 기능 목록이 아니라 유료 제안을 만든다

제안은 “무엇을 만들어 드립니다”가 아니라 “어떤 결정을 언제까지 어떤 증거로 돕습니다”다. SignalDesk의 첫 제안은 다음처럼 쓸 수 있다.

매주 월요일 오전 9시, 검토한 1차 자료 최소 다섯 개를 바탕으로 이번 주 도입·보류·관찰 결정을 한 장으로 보냅니다. 근거가 부족한 항목은 추천하지 않습니다.

가격은 모델 사용료의 합이 아니다. 고객이 절약하는 조사 시간, 피하는 실패, 의사결정 빈도와 비교한다. 첫 가격은 정답이 아니라 실험이다. 무료 사용자 반응만 모으지 말고 작은 금액이라도 결제 의사를 확인한다. 단, 실습에서는 실제 결제를 받지 않고 제안 카드와 취소 조건까지만 만든다.

실습: 제안 계약


{
  "customer": "직원 30명 이하 B2B SaaS 제품 리드",
  "expensiveDecision": "새 AI 업무 도구의 2주 파일럿 여부",
  "deliverable": "매주 근거가 달린 1쪽 의사결정 브리프",
  "cadence": "월요일 09:00 KST",
  "price": 49000,
  "notIncluded": ["법률 자문", "자동 구매", "고객 데이터 업로드"],
  "refundRule": "첫 발행 전 전액 취소"
}

프로젝트 루트에서 npm test를 실행해 제안 계약 검증 예를 확인한다. 고객·결정·산출물·가격 중 하나라도 빠지면 실패해야 한다.

↑ 목차로 돌아가기

4장 팔기 전에 손으로 한 번 배달한다

자동화는 반복이 확인된 뒤에 한다. 첫 브리프는 사람이 직접 자료를 찾고 비교하고 보낸다. 그래야 어느 단계가 어렵고, 고객이 무엇을 읽지 않으며, 어떤 근거에서 질문하는지 알 수 있다.

첫 배달의 목표는 완벽한 디자인이 아니다. 고객이 브리프를 읽고 실제 결정을 바꾸거나 더 빨리 내렸는지 확인하는 것이다. “좋았습니다” 대신 결정, 추가 질문, 공유 대상, 다시 받고 싶은 날짜를 묻는다.

실습: 컨시어지 판

선택한 분야의 공개 1차 자료 두 개로 1쪽 브리프를 만든다. 제목, 한 문장 결정, 달라진 사실 세 개, 반대 근거 하나, 다음 행동, 출처와 확인일을 넣는다. 법령·의료·투자처럼 전문가 책임이 필요한 분야는 연습 주제로 쓰지 않는다.

2부 AI 팀의 역할과 작업장을 만든다

↑ 목차로 돌아가기

5장 ChatGPT는 창업자의 질문을 날카롭게 한다

ChatGPT에 대표 역할 전체를 넘기지 않는다. 문제 인터뷰 질문, 반례 탐색, 제안 문장 비교, 회고 질문처럼 생각의 폭을 넓히는 일에 쓴다. 가격 확정, 고객 약속, 공개 주장, 개인정보 처리 결정은 사람이 맡는다.

좋은 요청은 역할보다 입력과 판정 기준이 선명하다.


첨부한 익명 인터뷰 5건만 사용한다.
반복된 문제와 반례를 분리하고 각 결론 옆에 인터뷰 ID를 붙인다.
근거가 한 건뿐이면 '약한 신호'로 표시한다.
새로운 시장 사실을 만들어 넣지 않는다.
마지막에 내가 결정해야 할 질문 세 개를 작성한다.

실습: 세 개의 제안을 비교한다

같은 인터뷰에서 고객 범위를 좁게, 중간, 넓게 잡은 제안 세 개를 요청한다. 선택은 ChatGPT에게 맡기지 않는다. 접근 가능한 고객 수, 반복 빈도, 실패 비용을 표로 비교해 사람이 하나를 고른다.

↑ 목차로 돌아가기

6장 Codex는 파일과 반복을 책임지는 운영자다

Codex는 대화 상대라기보다 작업 공간을 읽고 수정하고 검증하는 실행 에이전트로 다룬다. OpenAI는 2026년 Codex가 엔지니어링뿐 아니라 내부 앱, 대시보드, 기획 자료 같은 지식 업무로 확장된 사례를 공개했다. 그러나 넓은 권한이 좋은 결과를 보장하지 않는다. 일상 작업은 좁은 경계에서 자동화하고 외부 전송·삭제·결제는 사람에게 멈춘다.

SignalDesk 저장소에는 다음 구조를 둔다.


company/
  COMPANY.md          # 고객, 제안, 비범위
  AGENTS.md           # 작업 규칙과 검증 명령
  research/inbox/     # 반입 전 원문
  evidence/           # 승인 가능한 근거 카드
  issues/             # 주간판 작업 봉투
  briefs/             # 초안과 승인본
  decisions/          # 공개·보류 기록

실습: 회사의 운영 계약

AGENTS.md에 정본 파일, 수정 가능 경로, 금지 데이터, 검증 명령, 공개 전 승인 조건을 적는다. “좋은 글을 써라” 대신 “주장마다 근거 ID가 없으면 빌드에 실패한다”처럼 확인 가능한 규칙을 쓴다.

↑ 목차로 돌아가기

7장 한 작업은 한 봉투에 넣는다

“이번 주 뉴스 조사해 줘”는 끝이 없다. 작업 봉투에는 목표, 입력, 허용 출처, 산출물, 완료 조건, 예산, 중단 조건을 넣는다.


{
  "id": "ISSUE-2026-32",
  "objective": "AI 업무 도구 3개의 가격·보안·데이터 정책 변경 비교",
  "allowedSources": ["공식 제품 문서", "공식 보안 문서"],
  "deliverables": ["evidence.json", "brief.md"],
  "doneWhen": ["근거 5개 이상", "반대 근거 1개", "사람 승인"],
  "stopWhen": ["로그인 필요", "가격 단위 충돌", "출처 날짜 없음"]
}

중단 조건은 에이전트의 실패가 아니라 회사의 비용 통제다. 로그인이 필요하거나 자료가 충돌하면 추측하지 않고 사람에게 질문한다.

↑ 목차로 돌아가기

8장 고객 데이터와 회사 비밀을 먼저 분류한다

1인 회사도 개인정보 처리자와 계약 당사자가 될 수 있다. 편의 때문에 고객 메일 전체를 외부 모델에 붙여 넣지 않는다. 공개, 내부, 고객 기밀, 결제·인증 정보 네 등급으로 나누고 각 도구에 보낼 수 있는 등급을 정한다.

비밀은 프롬프트에 넣지 않고 환경 변수나 비밀 저장소에 둔다. 실습 fixture에는 실제 API 키, 이메일, 회사 이름을 넣지 않는다. 공개 자료를 수집할 때도 robots 정책, 이용 약관, 저작권을 확인한다. 긴 원문을 재배포하지 않고 사실을 자기 문장으로 요약하며 원문 링크를 제공한다.

실습: 데이터 출구 표

각 데이터가 로컬 파일, ChatGPT 대화, Codex 작업 공간, 외부 공급자 API, 공개 웹페이지 중 어디로 갈 수 있는지 표로 만든다. 미확인은 허용이 아니다.

3부 SignalDesk를 만든다

↑ 목차로 돌아가기

9장 근거 카드는 회사의 원재료다

요약만 저장하면 다음 주에 같은 주장을 다시 검증할 수 없다. 근거 카드는 URL, 제목, 짧은 원문 구간, 확인일, 자료 유형, 어떤 주장을 지지하는지 가진다. 번역과 해석은 원문을 덮어쓰지 않는다.


{
  "id": "E-2026-032-01",
  "claim": "공식 요금제가 변경됐다",
  "url": "https://example.org/pricing",
  "quote": "공식 페이지에서 확인한 짧은 구간",
  "observedAt": "2026-08-02",
  "sourceType": "primary",
  "status": "reviewed"
}

실습: 근거 점수의 의미

제공 테스트는 HTTPS URL, 의미 있는 원문, 날짜, 1차 자료에 점수를 준다. 점수는 진실 점수가 아니라 검토 준비도다. 높은 점수도 원문이 주장을 실제로 지지하는지 사람 검토를 대신하지 않는다.

↑ 목차로 돌아가기

10장 좋은 브리프는 결론보다 반증이 먼저 보인다

구독자는 자료 목록이 아니라 결정을 산다. 브리프 첫 화면에는 “도입”, “보류”, “관찰” 중 현재 결론과 확신 수준을 둔다. 바로 아래에 결론을 뒤집을 수 있는 반대 근거와 아직 모르는 것을 쓴다.

SignalDesk 템플릿은 다음 순서다.

  1. 이번 주 결정 한 문장
  2. 지난주와 달라진 사실 세 개
  3. 추천 행동과 예상 비용
  4. 반대 근거와 불확실성
  5. 다음 확인 날짜
  6. 근거 카드와 원문 링크

실습: 두 근거 규칙

makeWeeklyBrief는 검토 준비가 된 근거 두 개 이상과 의미 있는 결론이 있어야 ready: true를 반환한다. 한 회사의 보도자료를 복제한 기사 둘은 독립 근거 둘로 세지 않는다.

↑ 목차로 돌아가기

11장 공개 버튼 앞에 사람을 세운다

초안 생성과 외부 공개는 다른 권한이다. 미리보기는 자동화할 수 있지만 웹 공개, 구독자 발송, 결제는 승인 영수증이 필요하다. 승인에는 대상, 산출물 해시, 시각, 만료, 승인자를 묶는다.

이 장의 브라우저 fixture는 승인 유무만 보여 주는 축약 모델이다. 실제 영수증의 대상·산출물 해시·시각·만료·승인자 필드는 개념 계약이며 현재 UI가 생성하거나 검증하지 않는다. 이 필드가 필요한 운영 시스템은 서버 측 저장소와 만료 검사를 별도로 구현해야 한다.

책 루트에서 npm run buildnpm start를 실행하고 http://127.0.0.1:4183/을 연다. 행동을 ‘웹에 공개’로 바꾸면 승인 체크 전에는 approve, 체크 후에는 allow가 나와야 한다. 등록되지 않은 transfer는 UI 메뉴에는 없고 자동 테스트가 허용 목록 우회를 검사하기 위해 쓰는 공격 입력이다. 승인 표시가 있어도 npm test에서 거부되는지 확인한다.

실패 복구

승인 뒤 본문이나 수신자가 바뀌면 기존 승인을 폐기한다. 발송 요청 후 응답이 끊기면 무작정 재발송하지 않고 공급자의 처리 기록을 먼저 조회한다.

↑ 목차로 돌아가기

12장 랜딩 페이지는 약속과 증거만 남긴다

첫 랜딩 페이지에 화려한 AI 기술 목록을 넣지 않는다. 고객의 결정, 받는 결과물, 샘플, 발행 주기, 가격, 환불, 데이터 처리, 운영자 연락처를 먼저 보인다. 아직 없는 고객 수와 절감률을 만들지 않는다.

실습: 일곱 블록 랜딩

  • 누구의 어떤 결정을 돕는가
  • 이번 주 샘플 브리프
  • 근거를 고르는 기준
  • 포함·비포함 범위
  • 가격과 해지
  • 개인정보와 AI 사용 범위
  • 운영자와 문의 방법

검색 제목은 멋진 브랜드보다 질문을 담는다. 예: “B2B SaaS 팀을 위한 AI 도구 가격·보안 주간 비교”. 한 페이지에 서로 다른 고객 세 명을 넣지 않는다.

↑ 목차로 돌아가기

13장 고객지원도 제품 데이터다

문의는 방해가 아니라 제안이 어디서 오해되는지 알려 주는 센서다. 자동 답변은 배송 시간, 환불 절차, 문서 위치처럼 정답이 고정된 질문부터 시작한다. 불만, 계약, 개인정보, 결제 분쟁은 사람에게 넘긴다.

FAQ를 쓸 때 질문의 표현을 고객 언어로 보존한다. AI가 모든 질문을 매끄러운 내부 용어로 바꾸면 검색어와 불편의 강도가 사라진다. 답변에는 근거 문서 버전과 갱신일을 붙인다.

4부 다음 주에도 돌아가는 회사를 만든다

↑ 목차로 돌아가기

14장 매출보다 먼저 운영 지표를 본다

초기에는 매출 변동이 커서 무엇이 좋아졌는지 알기 어렵다. 선행 지표는 인터뷰 수, 샘플 완독, 답장, 유료 전환, 해지 이유, 브리프 한 건당 사람 검토 시간이다. AI 토큰 사용량은 비용 원자료이지 고객 가치가 아니다.

매주 다음 네 값을 기록한다.

  • 가치: 브리프가 실제 결정에 쓰인 비율
  • 품질: 수정·철회·근거 누락 건수
  • 운영: 제작 시간과 사람 개입 시간
  • 경제성: 수입, 변동비, 환불, 기여이익

실습: 계속·수정·중단

4주 뒤 결정을 미리 정한다. 유료 고객 3명 이상과 주간 제작 4시간 이하이면 계속, 고객은 있으나 제작이 길면 범위를 줄이고, 인터뷰 10명 뒤에도 문제 빈도가 낮으면 중단한다. 숫자는 업종에 맞게 조정하되 관찰 후 유리하게 바꾸지 않는다.

↑ 목차로 돌아가기

15장 14일 출시 스프린트

1~2일에는 고객과 결정을 고른다. 3~5일에는 인터뷰 다섯 번을 하고 패턴과 반례를 분리한다. 6일에는 유료 제안을 작성한다. 7~8일에는 첫 브리프를 손으로 만든다. 9일에는 근거와 개인정보를 검토한다. 10일에는 랜딩 페이지와 샘플을 연다. 11~12일에는 대상 고객 열 명에게 개인화한 소개를 보내되 스팸 발송은 하지 않는다. 13일에는 질문과 거절 이유를 정리한다. 14일에는 계속·수정·중단을 결정한다.

졸업 조건은 웹사이트가 열리는 것이 아니다. 실제 고객 문제를 다섯 번 들었고, 근거가 있는 샘플을 만들었고, 가격이 있는 제안을 보여 주었고, 외부 공개 기록과 다음 실험이 남아야 한다.

최종 체크포인트

  • 한 고객과 한 비싼 결정을 말할 수 있는가?
  • AI 요약에서 원문 인터뷰로 돌아갈 수 있는가?
  • 모든 공개 주장에 근거와 확인일이 있는가?
  • 공개·발송·결제 전에 사람이 승인하는가?
  • 4주 뒤 중단 기준이 있는가?

부록 A 처음 막혔을 때

먼저 프로젝트 루트에서 node --version을 확인하고 npm run qa를 실행한다. 테스트 실패는 마지막 줄보다 첫 not ok과 파일명을 읽는다. 브라우저 화면은 file://가 아니라 npm start로 로컬 HTTP 서버를 열어 ES module을 정상 로드한다.

제안 검증이 실패하면 고객·결정·산출물·가격을 확인한다. 근거 점수가 낮으면 URL, 원문, 확인일, 자료 유형 중 빠진 값을 본다. 공개가 approve에서 멈추면 승인 체크를 우회하지 말고 근거와 대상이 맞는지 확인한다.

부록 B 저작권·상표·개인정보 원칙

이 책의 본문, 코드, fixture, SVG는 이 프로젝트를 위해 새로 작성했다. 외부 책과 문서의 문장을 장문 복제하지 않는다. 사실과 기능은 공식 자료를 확인해 자기 문장으로 요약하고 링크와 확인일을 남긴다. 제품명은 식별을 위한 상표이며 제휴·보증을 뜻하지 않는다. 독자가 만든 결과물의 권리는 사용한 모델·데이터·폰트·이미지·템플릿의 약관을 별도로 확인해야 한다.

고객 인터뷰와 지원 메일은 동의, 목적, 보존 기간을 정한다. 실습에는 실제 고객 데이터 대신 fixture를 쓴다. 의료·법률·투자 판단은 전문가 검토 없는 자동 서비스를 만들지 않는다.

공식 자료와 더 읽을거리

위 자료는 제품 기능과 사례의 근거다. 특정 조직의 성과를 독자의 예상 매출이나 생산성으로 일반화하지 않는다.

이 책은 3만 부 판매나 사업 수익을 보장하지 않는다. 실제 결과는 분야·제안·가격·영업 실행에 따라 달라진다. 독자는 작은 검증으로 손실 한도를 정하고 자신의 책임으로 공개와 거래를 결정한다.

↑ 목차로 돌아가기