Build in Public Ep.8: 인블로그에 더 이상 안 들어갑니다 - 클로드에서 MCP 서버로 글 쓰고 발행까지 끝내는 구조

Salesforce MCP 설치 경험에서 시작해 인블로그 MCP 서버를 직접 만들기까지. API 스펙 하나로 코드 한 줄 없이 MCP 서버를 만들고, 미팅→콘텐츠→발행 파이프라인의 마지막 조각을 채운 전체 기록.

Mar 19, 2026

Build in Public Ep.8: 인블로그에 더 이상 안 들어갑니다 - 클로드에서 MCP 서버로 글 쓰고 발행까지 끝내는 구조

Contents

들어가며: 복붙이 병목이 되는 순간 Salesforce MCP → "이 패턴은 반복 가능하다"1월 30일 — 최초 구상 2월 22~23일 — 설치 및 테스트 성공 "인블로그도 되겠는데?" - 사고의 연결 경험 API 스펙 확보: 자동으로 안 되는 건 직접 건네줘야 한다 맥락 먼저 전달 API 문서 탐색 — 실패 API 스펙 분석 결과 "여기서 만들지 말고 지시서를 써줘"지시서의 핵심 구성 Claude Code로 코드 생성 → 설치 → 연결 성공 코드 생성 설치 과정 — 삽질 기록 MCP 서버가 없을 때의 불편함이 가치를 증명하다 배운 것들 하나를 해보면 다음 게 쉬워진다 맥락을 먼저 줘야 결과가 다르다 API 스펙만 있으면 된다 개별 도구가 아니라 파이프라인 마무리: "콘텐츠 마케팅 에이전트"의 첫 번째 실증

들어가며: 복붙이 병목이 되는 순간

블로그 글을 하나 발행하려면 이런 과정을 거쳤습니다.

Claude에서 글을 쓴다. 완성된 마크다운을 전체 선택해서 복사한다. 인블로그 대시보드에 들어간다. 새 포스트를 만든다. 붙여넣는다. 서식이 깨진 부분을 손으로 고친다. 태그를 설정한다. 메타 디스크립션을 넣는다. 발행 버튼을 누른다.

한 번이면 괜찮아요. 근데 매일 하면 이게 생각보다 시간을 잡아먹더라고요.

Ep.7에서 Slack Connect 메시지를 Salesforce 안에서 직접 읽을 수 있게 만들었을 때, "Salesforce를 떠나지 않고 고객 대화를 확인할 수 있다"는 게 핵심이었거든요. 블로그도 마찬가지였어요. Claude를 떠나지 않고 블로그에 발행할 수 있으면, 복붙이라는 병목이 사라지는 건데 — 그러려면 인블로그 MCP 서버가 필요했습니다.

Salesforce MCP → "이 패턴은 반복 가능하다"

인블로그 MCP 서버를 만들겠다는 생각 자체가, Salesforce MCP 서버를 직접 설치해본 경험이 없었으면 안 났을 거예요.

1월 30일 — 최초 구상

시작은 단순한 질문이었어요. "클로드와 세일즈포스를 MCP 형태로 연결하는 커넥터를 직접 만들 수 있을까?"

이 시점에서 저는 이런 상태였어요. Node.js 미설치. Homebrew 미설치. "node가 뭔지도 몰랐음." Ep.6에서 "Homebrew가 뭐야? sudo는 뭐야?"부터 시작했던 그 사람이 맞습니다.

Claude에게 이 상태를 그대로 공유하고, "각 단계를 실행하기 전에 나에게 설명해주고, 내가 확인하면 다음 단계로 진행해줘"라는 조건을 붙였습니다.

2월 22~23일 — 설치 및 테스트 성공

@tsmztech/mcp-server-salesforce를 선택했어요. Salesforce CLI 인증 방식을 지원해서 기존 터미널 인증을 그대로 쓸 수 있었거든요.

설치 과정에서 또 막혔습니다. zsh: command not found 에러 → Apple Silicon Mac의 PATH 문제. Salesforce 로그인 실패 → My Domain 때문에 기본 URL로 안 됨. Ep.6에서 겪었던 것과 똑같은 패턴이죠. 에러 나고, 물어보고, 해결하고, 다음 단계로.

Claude Desktop에서 자연어로 "Account 목록 보여줘"라고 하니까 무신사, LG CNS, 삼성리서치 같은 실제 고객 데이터가 나왔어요. 이게 나중에 세일즈포스에 로그인을 안 하고 자연어로만 CRM을 다루는 방식으로 이어지게 됩니다.

이때 느낀 게 하나 있어요. "이거 다른 서비스에도 똑같이 하면 되겠는데?" MCP 서버를 로컬에 설치하고 Claude Desktop에 연결하면, 자연어로 외부 서비스를 다룰 수 있다는 걸 직접 해본 거니까요.

"인블로그도 되겠는데?" - 사고의 연결 경험

Salesforce MCP를 해보니까 자연스럽게 다음 생각이 나오더라고요.

Salesforce MCP 설치 성공 (8분)
  → "이 패턴 반복 가능하다"
    → "인블로그도 API 있으니 되겠는데?"
      → 더 큰 그림: 미팅 → 콘텐츠 → 자동 발행 파이프라인

인블로그도 API가 있으니 MCP 서버를 만들면, Claude에서 글 쓰고 바로 블로그에 발행하는 루프가 가능해요. 여기서 더 나아가면, 영업사원이 미팅을 끝내면 에이전트가 미팅 내용에서 글감을 자동 추출해서 블로그 초안을 바로 올려주는 것까지 확장 가능하고요. 영업사원 100명인 회사라면 하루에 콘텐츠 수십 개가 쏟아지는 거예요. 이걸 "콘텐츠 마케팅 에이전트"라는 서비스로 패키징할 수 있겠다는 생각이었습니다.

결국 AI 아웃풋의 퀄리티를 결정하는 건 AI가 아니라 인풋이거든요. ground truth DATA가 들어올 수 있는 환경을 만드는 것이 시작점이고, 인블로그 MCP 서버는 이 파이프라인의 "마지막 한 조각"이었습니다.

API 스펙 확보: 자동으로 안 되는 건 직접 건네줘야 한다

아이디어를 얻은 날 바로 작업에 들어갔습니다. 근데 코딩부터 시작하지 않았어요.

맥락 먼저 전달

먼저 Claude에게 왜 이 MCP 서버를 만드는지 비즈니스 맥락부터 전달했어요. 콘텐츠 마케팅 에이전트 비전, 파이프라인에서 빠진 조각이 뭔지, 이걸 만들면 어디에 쓸 건지. Ep.6에서 "도메인 지식이 핵심"이라고 했던 것과 같은 맥락이에요.

API 문서 탐색 — 실패

Claude에게 "인블로그 API 문서 직접 찾아봐, 공개되어 있을 거야"라고 했습니다.

Claude의 시도:

web_search: inblog API documentation → 결과 없음
web_fetch: https://inblog.ai/api-docs → JavaScript 렌더링 페이지라 내용 추출 실패
여러 차례 추가 검색 → 모두 실패

결국 인블로그 대시보드 Settings → API에서 직접 OpenAPI JSON 파일을 다운로드해서 업로드했습니다. AI가 알아서 다 찾아주진 않더라고요. 이런 건 사람이 직접 건네줘야 해요.

API 스펙 분석 결과

Claude가 api-1.json 파일을 파싱해서 도출한 구조:

Base URL: https://inblog.ai/api/v1
인증: Bearer token
8개 엔드포인트: GET /me, GET /posts, GET /posts/{id}, POST /posts, PATCH /posts/{id}, PATCH /posts/{id}/publish, GET /forms, GET /form-responses
주요 발견: DELETE 엔드포인트 없음(삭제 불가, unpublish만 가능), content_type이 TipTap 에디터 기반

8개면 충분했습니다. 글을 조회하고, 만들고, 수정하고, 발행하는 기본 루프가 다 있었거든요.

"여기서 만들지 말고 지시서를 써줘"

API 분석이 끝나자 Claude가 바로 코드를 만들기 시작했습니다.

mkdir -p /home/claude/inblog-mcp-server && npm init -y

여기서 방향을 전환했어요.

"여기서 만들지 말고 클로드 코드로 작업할 수 있게 지시서 만들어줘. 왜 만드는지에 대한 맥락도 잘 정리하고."

기존에는 클로드 대화창 내에서 실행했는데, 이 경우에는 클로드 코드로 따로 만들어서 설치까지 로컬에 해야했기 때문에 지난 번 실행을 통해서 이 방식이 더 낫다는 걸 배웠기 때문입니다.

지시서의 핵심 구성

작성된 지시서(inblog-mcp-server-instruction.md)에는 이런 것들이 들어갔습니다.

왜 만드는가 — 콘텐츠 파이프라인의 한 조각, 콘텐츠 마케팅 에이전트 비전
API 스펙 요약 — 엔드포인트, 인증 방식, TipTap HTML 규칙
10개 MCP Tool 정의 — inblog_me, inblog_list_posts, inblog_get_post, inblog_create_post, inblog_update_post, inblog_publish_post, inblog_unpublish_post, inblog_schedule_post, inblog_list_forms, inblog_list_form_responses
마크다운 → HTML 자동 변환 — content_markdown 입력 시 TipTap 호환 HTML로 변환
테스트 계획 — 5단계 (API 연결 → 읽기 → 쓰기 → 변환 → E2E)

10개 Tool을 명시적으로 정의한 게 중요했어요. "인블로그 API 연동해줘"라고 하는 것과, "이 10개 기능을 각각 이런 이름으로 만들어줘"라고 하는 것은 나오는 결과가 다르거든요.

Claude Code로 코드 생성 → 설치 → 연결 성공

코드 생성

지시서와 api-1.json을 Claude Code에 넘기면, Claude Code가 프로젝트 전체를 생성했습니다. package.json, TypeScript 소스코드(src/index.ts, src/inblog-client.ts, src/tools.ts), tsconfig.json, 빌드 설정까지. 코드를 한 줄도 직접 쓰지 않았습니다.

설치 과정 — 삽질 기록

1단계: git clone 실패 3회

git clone https://github.com/michaelchoi910-droid/sales-coaching.git
# → fatal: could not read Username (HTTPS 인증 필요)

git clone git@github.com:michaelchoi910-droid/sales-coaching.git
# → Permission denied (publickey) (SSH 키 없음)

해결: GitHub CLI 설치 (brew install gh → gh auth login → 브라우저 인증) → gh repo clone → 성공.

Ep.6에서 Homebrew를 처음 알게 됐고, Ep.7에서 VS Code를 처음 써봤고, 이번에는 GitHub CLI를 처음 설치했어요. 매번 처음 보는 도구가 나오는데, 하는 일은 똑같아요. 막히면 물어보고, 알려주는 대로 하면 넘어가더라고요.

2단계: npm install & build — 이번에는 에러 없이 통과

cd inblog-mcp-server
npm install  # 95 packages, 0 vulnerabilities
npm run build  # TypeScript → JavaScript 컴파일 완료

3단계: 파일 위치 정리

클론된 위치가 엉뚱한 곳(slack-integration 폴더 안)이었어요. MCP 서버 전용 디렉토리를 만들어서 정리했습니다.

~/entryai/
└── mcp-servers/
    └── inblog-mcp-server/

4단계: API 키 보안 — macOS Keychain

Claude Desktop config 파일에 API 키를 평문으로 넣을 수도 있었는데, 보안이 찜찜했어요. macOS Keychain에 저장하는 방식을 선택했습니다.

security add-generic-password -a "inblog" -s "INBLOG_API_KEY" -w "실제_API_키"

config에서는 실행할 때마다 Keychain에서 꺼내오는 방식이에요. config 파일에 키가 노출되지 않으니 안전하죠.

5단계: config 내용이 자꾸 사라지는 문제

Claude Desktop이 켜진 상태에서 config를 수정하면, Desktop이 자체적으로 설정을 저장하는 타이밍과 겹쳐서 수정 내용이 사라졌습니다. 이건 꽤 당황스러웠어요.

교훈: 반드시 Claude Desktop을 Cmd + Q로 완전 종료한 후 config를 수정해야 합니다. Cmd + W로 창만 닫으면 백그라운드에서 계속 돌고 있거든요.

6단계: 연결 성공

Claude Desktop을 재시작하니 망치 아이콘(🔨)에 inblog 관련 툴 10개가 떴습니다. 테스트:

"B2B 세일즈에서 CRM 데이터 입력이 중요한 이유라는 주제로 블로그 글 작성하고 인블로그에 발행해줘."

Claude가 inblog_create_post → inblog_publish_post 순서로 자동 실행. 인블로그에 실제 발행 성공.

Claude에서 글을 쓰고, 같은 대화창에서 "발행해줘"라고 하면 끝나는 구조가 완성된 거예요. 복사, 붙여넣기, 서식 정리, 태그 설정 — 이 전부가 사라졌습니다.

MCP 서버가 없을 때의 불편함이 가치를 증명하다

며칠 후, claude.ai 웹에서 블로그 글을 최종 검수하려고 했습니다. 이 글은 인블로그에 draft 상태로 저장되어 있었어요. Claude에게 인블로그 대시보드 URL을 줬더니 — 로그인이 필요한 페이지라 접근 불가.

"연결된 MCP 서버 통해서 검색이나 글 못 읽어오는 거야?"
→ "인블로그(inblog) MCP 서버는 연결되어 있지 않아."

Claude Desktop 로컬에만 인블로그 MCP가 연결되어 있었으니 당연한거죠.

그런데 이 경험이 오히려 인블로그 MCP 서버의 가치를 제일 선명하게 보여줬어요. MCP 서버가 있는 환경에서는 "이 글 수정해줘"라고 하면 끝이에요. 없는 환경에서는 "글을 복사해서 붙여넣기”를 내 손으로 직접 해야합니다.

없어져봐야 있을 때의 편리함을 알게 되더라고요.

배운 것들

하나를 해보면 다음 게 쉬워진다

Salesforce MCP → 인블로그 MCP 서버 직접 제작. 한 번 해본 사람은 다음에 또 해요. Salesforce MCP를 설치했을 때 "아 이게 되는구나"를 몸으로 알게 됐고, 그 다음부터는 "이것도 되겠는데?"가 자연스럽게 나오더라고요.

맥락을 먼저 줘야 결과가 다르다

Claude에게 "인블로그 MCP 서버 만들어줘"라고 하지 않고, 비즈니스 맥락을 먼저 전달했어요. "여기서 바로 만들지 말고 지시서를 써줘"라고 방향을 전환한 것도 마찬가지고요.

결국 코딩 능력이 아니라 "뭘 원하는지 설명하는 능력"이 결과물을 좌우하더라고요.

API 스펙만 있으면 된다

인블로그는 공식 MCP 서버를 제공하지 않아요. 하지만 OpenAPI JSON 파일이 있었습니다. 이걸 Claude에게 주고 지시서를 쓰면, Claude Code가 TypeScript MCP 서버를 생성해요.

인블로그가 됐으면 다른 서비스도 돼요. API 스펙 확보 → 지시서 작성 → Claude Code가 코드 생성 → 설치 → 테스트. 이 순서만 반복하면 됩니다.

개별 도구가 아니라 파이프라인

Salesforce, Fireflies, LinkedIn, 인블로그를 각각 따로 연결한 게 아니에요. 데이터가 흘러가는 파이프라인을 만든 겁니다.

미팅 녹음(Fireflies) → CRM 데이터 참조(Salesforce) → 콘텐츠 생성(Claude) → 블로그 발행(인블로그) → 소셜 공유(LinkedIn)

인블로그 MCP 서버는 이 파이프라인의 "마지막 한 조각"이었어요. 이게 빠져 있을 때는 파이프라인 중간에서 사람이 복사-붙여넣기를 해야 했고, 이게 채워지면서 글을 쓰고 발행하는 전체 루프가 대화 한 번으로 완결되는 구조가 만들어진 겁니다.

마무리: "콘텐츠 마케팅 에이전트"의 첫 번째 실증

이 글 자체가 그 실증이에요.

인블로그 MCP 서버를 만든 과정을 Claude에서 글로 쓰고, 같은 환경에서 인블로그에 발행하는 루프를 실제로 돌렸습니다. 만든 과정 자체가 글감이 되고, 그 글이 자동으로 블로그에 올라가는 거예요.

지금은 1인 기업이니까 이걸 혼자 하고 있지만, 이 구조가 확장되면 이야기가 달라져요. 영업사원이 미팅을 끝내면 → 미팅 내용에서 글감이 자동 추출되고 → 블로그 초안이 올라가는 파이프라인. 영업사원 100명인 회사라면 하루에 콘텐츠 수십 개가 만들어지는 거예요.

AI 시대에 소프트웨어를 직접 만드는 것보다 이미 있는 도구를 연결하는 게 더 빠르다고 전에 쓴 적 있는데, 이번에 직접 해본 거예요. API가 있는 서비스면 MCP 서버를 만들 수 있고, MCP 서버가 있으면 파이프라인의 빈 자리를 채울 수 있어요.

코드를 한 줄도 직접 쓰지 않았습니다. 필요했던 건 "뭘 원하는지 설명하는 능력"이었어요.

Contents

AI Agent Build in Public B2B SaaS

Build in Public Ep.8: 인블로그에 더 이상 안 들어갑니다 - 클로드에서 MCP 서버로 글 쓰고 발행까지 끝내는 구조

최승호

Mar 19, 2026

Contents

들어가며: 복붙이 병목이 되는 순간

블로그 글을 하나 발행하려면 이런 과정을 거쳤습니다.

한 번이면 괜찮아요. 근데 매일 하면 이게 생각보다 시간을 잡아먹더라고요.

Salesforce MCP → "이 패턴은 반복 가능하다"

인블로그 MCP 서버를 만들겠다는 생각 자체가, Salesforce MCP 서버를 직접 설치해본 경험이 없었으면 안 났을 거예요.

1월 30일 — 최초 구상

시작은 단순한 질문이었어요. "클로드와 세일즈포스를 MCP 형태로 연결하는 커넥터를 직접 만들 수 있을까?"

Claude에게 이 상태를 그대로 공유하고, "각 단계를 실행하기 전에 나에게 설명해주고, 내가 확인하면 다음 단계로 진행해줘"라는 조건을 붙였습니다.

2월 22~23일 — 설치 및 테스트 성공

@tsmztech/mcp-server-salesforce를 선택했어요. Salesforce CLI 인증 방식을 지원해서 기존 터미널 인증을 그대로 쓸 수 있었거든요.

"인블로그도 되겠는데?" - 사고의 연결 경험

Salesforce MCP를 해보니까 자연스럽게 다음 생각이 나오더라고요.

Salesforce MCP 설치 성공 (8분)
  → "이 패턴 반복 가능하다"
    → "인블로그도 API 있으니 되겠는데?"
      → 더 큰 그림: 미팅 → 콘텐츠 → 자동 발행 파이프라인

API 스펙 확보: 자동으로 안 되는 건 직접 건네줘야 한다

아이디어를 얻은 날 바로 작업에 들어갔습니다. 근데 코딩부터 시작하지 않았어요.

맥락 먼저 전달

API 문서 탐색 — 실패

Claude에게 "인블로그 API 문서 직접 찾아봐, 공개되어 있을 거야"라고 했습니다.

Claude의 시도:

web_search: inblog API documentation → 결과 없음
web_fetch: https://inblog.ai/api-docs → JavaScript 렌더링 페이지라 내용 추출 실패
여러 차례 추가 검색 → 모두 실패

API 스펙 분석 결과

Claude가 api-1.json 파일을 파싱해서 도출한 구조:

Base URL: https://inblog.ai/api/v1
인증: Bearer token
8개 엔드포인트: GET /me, GET /posts, GET /posts/{id}, POST /posts, PATCH /posts/{id}, PATCH /posts/{id}/publish, GET /forms, GET /form-responses
주요 발견: DELETE 엔드포인트 없음(삭제 불가, unpublish만 가능), content_type이 TipTap 에디터 기반

8개면 충분했습니다. 글을 조회하고, 만들고, 수정하고, 발행하는 기본 루프가 다 있었거든요.

"여기서 만들지 말고 지시서를 써줘"

API 분석이 끝나자 Claude가 바로 코드를 만들기 시작했습니다.

mkdir -p /home/claude/inblog-mcp-server && npm init -y

여기서 방향을 전환했어요.

"여기서 만들지 말고 클로드 코드로 작업할 수 있게 지시서 만들어줘. 왜 만드는지에 대한 맥락도 잘 정리하고."

지시서의 핵심 구성

작성된 지시서(inblog-mcp-server-instruction.md)에는 이런 것들이 들어갔습니다.

왜 만드는가 — 콘텐츠 파이프라인의 한 조각, 콘텐츠 마케팅 에이전트 비전
API 스펙 요약 — 엔드포인트, 인증 방식, TipTap HTML 규칙
10개 MCP Tool 정의 — inblog_me, inblog_list_posts, inblog_get_post, inblog_create_post, inblog_update_post, inblog_publish_post, inblog_unpublish_post, inblog_schedule_post, inblog_list_forms, inblog_list_form_responses
마크다운 → HTML 자동 변환 — content_markdown 입력 시 TipTap 호환 HTML로 변환
테스트 계획 — 5단계 (API 연결 → 읽기 → 쓰기 → 변환 → E2E)

Claude Code로 코드 생성 → 설치 → 연결 성공

코드 생성

설치 과정 — 삽질 기록

1단계: git clone 실패 3회

git clone https://github.com/michaelchoi910-droid/sales-coaching.git
# → fatal: could not read Username (HTTPS 인증 필요)

git clone git@github.com:michaelchoi910-droid/sales-coaching.git
# → Permission denied (publickey) (SSH 키 없음)

해결: GitHub CLI 설치 (brew install gh → gh auth login → 브라우저 인증) → gh repo clone → 성공.

2단계: npm install & build — 이번에는 에러 없이 통과

cd inblog-mcp-server
npm install  # 95 packages, 0 vulnerabilities
npm run build  # TypeScript → JavaScript 컴파일 완료

3단계: 파일 위치 정리

클론된 위치가 엉뚱한 곳(slack-integration 폴더 안)이었어요. MCP 서버 전용 디렉토리를 만들어서 정리했습니다.

~/entryai/
└── mcp-servers/
    └── inblog-mcp-server/

4단계: API 키 보안 — macOS Keychain

Claude Desktop config 파일에 API 키를 평문으로 넣을 수도 있었는데, 보안이 찜찜했어요. macOS Keychain에 저장하는 방식을 선택했습니다.

security add-generic-password -a "inblog" -s "INBLOG_API_KEY" -w "실제_API_키"

config에서는 실행할 때마다 Keychain에서 꺼내오는 방식이에요. config 파일에 키가 노출되지 않으니 안전하죠.

5단계: config 내용이 자꾸 사라지는 문제

교훈: 반드시 Claude Desktop을 Cmd + Q로 완전 종료한 후 config를 수정해야 합니다. Cmd + W로 창만 닫으면 백그라운드에서 계속 돌고 있거든요.

6단계: 연결 성공

Claude Desktop을 재시작하니 망치 아이콘(🔨)에 inblog 관련 툴 10개가 떴습니다. 테스트:

"B2B 세일즈에서 CRM 데이터 입력이 중요한 이유라는 주제로 블로그 글 작성하고 인블로그에 발행해줘."

Claude가 inblog_create_post → inblog_publish_post 순서로 자동 실행. 인블로그에 실제 발행 성공.

MCP 서버가 없을 때의 불편함이 가치를 증명하다

"연결된 MCP 서버 통해서 검색이나 글 못 읽어오는 거야?"
→ "인블로그(inblog) MCP 서버는 연결되어 있지 않아."

Claude Desktop 로컬에만 인블로그 MCP가 연결되어 있었으니 당연한거죠.

없어져봐야 있을 때의 편리함을 알게 되더라고요.

배운 것들

하나를 해보면 다음 게 쉬워진다

맥락을 먼저 줘야 결과가 다르다

결국 코딩 능력이 아니라 "뭘 원하는지 설명하는 능력"이 결과물을 좌우하더라고요.

API 스펙만 있으면 된다

인블로그가 됐으면 다른 서비스도 돼요. API 스펙 확보 → 지시서 작성 → Claude Code가 코드 생성 → 설치 → 테스트. 이 순서만 반복하면 됩니다.

개별 도구가 아니라 파이프라인

Salesforce, Fireflies, LinkedIn, 인블로그를 각각 따로 연결한 게 아니에요. 데이터가 흘러가는 파이프라인을 만든 겁니다.

미팅 녹음(Fireflies) → CRM 데이터 참조(Salesforce) → 콘텐츠 생성(Claude) → 블로그 발행(인블로그) → 소셜 공유(LinkedIn)

마무리: "콘텐츠 마케팅 에이전트"의 첫 번째 실증

이 글 자체가 그 실증이에요.

코드를 한 줄도 직접 쓰지 않았습니다. 필요했던 건 "뭘 원하는지 설명하는 능력"이었어요.

Contents