{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Corca Blog",
  "home_page_url": "https://blog.corca.cc/",
  "feed_url": "https://blog.corca.cc/feed.json",
  "description": "Corca가 AI 제품, 워크플로, 팀 운영에서 배운 내용을 기록하는 공식 블로그입니다.",
  "language": "ko",
  "items": [
    {
      "id": "https://blog.corca.cc/posts/ceal-terview-blog.html",
      "url": "https://blog.corca.cc/posts/ceal-terview-blog.html",
      "title": "씰터뷰: 블로그 사이트를 만든다는 것의 진짜 목표",
      "content_html": "<p class=\"lead\">처음에는 “블로그 사이트를 새로 만든다”는 일이었다. 글을 올릴 수 있는 공간을 만들고, 필요한 기능을 구현하면 되는 일처럼 보였다. 그런데 구현을 하다 보니 질문이 달라졌다. “이 기능을 만들 수 있나?”보다 먼저 봐야 할 것은 “이 일이 원래 풀려던 문제를 풀고 있나?”였다.</p>\n\n      <p>문정민님은 이 전환을 겪으면서, 블로그 프로젝트의 핵심이 사이트 자체가 아니라는 점을 발견했다. 진짜 목표는 회사 안에 이미 쌓이고 있는 경험과 지식을 외부 콘텐츠로 전환하고, 그 반응을 다시 내부 구성원의 글쓰기 동력으로 돌려주는 순환 구조를 만드는 것이었다.</p>\n\n      <div class=\"quote\">“처음에는 블로그 사이트를 새로 만들어서 글을 올릴 수 있게 하는 것이었다면, 나중에는 내부 지식을 외부로 전환하는 프로세스를 개선하는 것이 메인 목표가 됐다.”</div>\n\n      <h2>구현보다 먼저 봐야 했던 전체 그림</h2>\n      <div class=\"qa\">\n        <div class=\"q\">처음 블로그 일을 맡았을 때, 어떤 지점에서 관점이 바뀌었나요?</div>\n        <div class=\"a\">단순히 구현에만 집중하다 보니 큰그림을 덜 보게 됐어요. 그러다 보니 정말 구현한 것이 목표에 맞는지 체크조차 못하고 구현만 하고 있었던 거죠.</div>\n      </div>\n\n      <p>이 경험은 개발 과정에서 자주 놓치는 지점을 보여준다. 구현은 눈에 보이고, 할 일 목록은 계속 생긴다. 하지만 전체 목표가 명확하지 않으면, 열심히 만들고 있으면서도 정작 문제의 중심에서 멀어질 수 있다.</p>\n\n      <p>정민님은 그래서 일을 시작하기 전에 자신만의 언어로 전체 그림을 다시 그리는 과정이 필요하다고 말했다. 남이 알려준 업무라도 그대로 받아 적는 것만으로는 충분하지 않다. 왜 필요한 일인지, 전체 흐름 안에서 내가 맡은 부분은 어디인지, 어떤 상태가 되어야 성공인지 스스로 설명할 수 있어야 한다.</p>\n\n      <h2>노트에 그린 흐름도와 질문들</h2>\n      <div class=\"qa\">\n        <div class=\"q\">그 전체 그림은 어떤 방식으로 정리했나요?</div>\n        <div class=\"a\">저는 노트에 적어보면서 한 단계씩 이해하는 게 좋았어요. 전체 흐름도를 그려보고, 그 사이의 디테일한 구현할 것들과 얘기해볼 거리들을 적으면서 알게 됐어요.</div>\n      </div>\n\n      <p>정민님에게 노트는 단순한 메모장이 아니었다. 전체 흐름을 그려보고, 각 단계 사이에 구현할 것과 논의할 것을 표시하면서 “내가 지금 무엇을 알고 있고, 어디가 아직 불확실한지”를 확인하는 도구였다.</p>\n\n      <p>특히 구현 방식의 선택이 필요한 부분들이 있었다. 메인 목표를 정하는 과정에서 중간에 형태가 많이 바뀌었고, 그때마다 기존 구현이 여전히 맞는지 다시 봐야 했다. 목표가 흔들리면 구현 방식도 흔들릴 수밖에 없었다.</p>\n\n      <h2>블로그 스킬보다 먼저 필요한 것</h2>\n      <div class=\"qa\">\n        <div class=\"q\">처음에는 블로그 작성을 도와주는 스킬을 만들려고 했다고 했는데, 왜 방향이 바뀌었나요?</div>\n        <div class=\"a\">블로그는 취향의 영역이라 스킬로는 한계가 있다고 봤어요. 그래서 스킬보다 프로세스 개선이 먼저라고 생각했습니다.</div>\n      </div>\n\n      <p>기존 사내 블로그의 문제는 “글을 못 쓴다”가 아니었다. 글감 찾기, 글쓰기, 블로그 형식 맞추기, 담당자에게 반영을 부탁하기까지 모든 과정이 개인의 수고에 기대고 있었다. 글을 올린 뒤에도 반응이나 인정, 피드백이 작성자에게 다시 돌아오는 구조가 약했다.</p>\n\n      <p>정민님은 기존 블로그가 거의 두 달에 한 번 정도만 올라오는 상황을 근거로 봤다. 글을 쓰면 좋다는 말은 있지만, 실제 행동으로 이어지기에는 마찰이 컸던 것이다.</p>\n\n      <div class=\"quote\">“글을 잘 쓰자”가 아니라, 글이 자연스럽게 발견되고 정리되고 발행되고 다시 내부 동력으로 돌아오는 구조를 만들어야 했다.</div>\n\n      <h2>AX 공유회를 블로그 글감의 출발점으로 삼기</h2>\n      <p>정민님이 제안한 개선 방향은 명확하다. 매주 진행되는 AX 공유회에서 주제 하나를 고르고, 해당 주제를 발표한 구성원을 내부 에이전트가 인터뷰한다. 발표자는 빈 화면 앞에서 글을 써야 하는 것이 아니라, 자신이 이미 공유한 경험에 대해 질문에 답하면 된다.</p>\n\n      <div class=\"loop\" aria-label=\"AX 공유회 기반 블로그 작성 루프\">\n        <div class=\"step\"><strong>1. AX 공유회</strong><span>이미 말해진 내부 경험과 지식을 발견한다.</span></div>\n        <div class=\"step\"><strong>2. 씰터뷰</strong><span>내부 에이전트가 질문으로 관점과 글감을 끌어낸다.</span></div>\n        <div class=\"step\"><strong>3. 초안 작성</strong><span>인터뷰 내용을 블로그 글 형태로 정리한다.</span></div>\n        <div class=\"step\"><strong>4. 발행</strong><span>사내 블로그와 내부 채널을 통해 공유한다.</span></div>\n        <div class=\"step\"><strong>5. 반응 회수</strong><span>내부·외부 반응과 피드백을 작성자에게 돌려준다.</span></div>\n      </div>\n\n      <p>이 흐름의 핵심은 구성원에게 “글을 쓰라”고 시키는 것이 아니다. 이미 회사 안에서 말해진 좋은 주제를 잡아, 글이 자연스럽게 만들어지고, 발행되고, 반응이 돌아오는 경험을 설계하는 것이다.</p>\n\n      <h2>블로그 개발의 역할도 다시 정의된다</h2>\n      <p>이 관점에서 블로그 사이트 개발은 목적이 아니라 기반이 된다. 사이트는 글을 담는 공간일 뿐 아니라, 글 작성과 리뷰, 반영, 공유, 반응 수집의 마찰을 줄여야 한다. 즉 기능 요구사항도 “무엇을 만들 것인가”가 아니라 “이 순환 구조가 어디서 막히는가”를 보고 정해야 한다.</p>\n\n      <p>처음에는 에이전트가 글쓰기 부담을 낮추는 보조 역할을 한다. 하지만 글이 발행되고 반응이 돌아오는 경험이 쌓이면, 구성원은 “내 경험도 글이 될 수 있구나”, “내가 한 이야기가 외부에 의미 있게 전달될 수 있구나”를 느끼게 된다. 그 경험이 다음 글의 동력이 된다.</p>\n\n      <h2>정리하면</h2>\n      <p>이번 씰터뷰에서 드러난 핵심은 단순하다. 블로그 사이트를 새로 만드는 일은 화면과 기능을 만드는 일이기도 하지만, 더 본질적으로는 내부 지식이 외부 자산으로 전환되는 흐름을 만드는 일이다.</p>\n\n      <p>AX 공유회는 이미 좋은 글감이 생기는 자리다. 내부 에이전트는 그 글감을 질문으로 끌어내는 역할을 할 수 있다. 블로그는 그 결과를 외부로 전달하는 채널이 되고, 반응은 다시 내부 구성원의 동력으로 돌아온다.</p>\n\n      <section class=\"orbit\" aria-label=\"Orbit 질문\">\n        <h2>Orbit으로 다시 떠올릴 질문</h2>\n        <p class=\"orbit-intro\">Orbit 문서의 방식처럼 리뷰 질문과 답변을 함께 정리해, 독자가 글의 핵심을 나중에 다시 복습할 수 있게 했다.</p>\n        <a class=\"orbit-link\" href=\"https://docs.withorbit.com/\" target=\"_blank\" rel=\"noreferrer\">https://docs.withorbit.com/</a>\n        <div class=\"orbit-reviewarea\">\n          <section class=\"orbit-prompt\"><h3>이번 씰터뷰에서 블로그 사이트 개발의 진짜 목표는 무엇으로 재정의됐나?</h3><p>단순히 글을 올릴 사이트를 만드는 것이 아니라, AX 공유회에서 나온 내부 지식이 인터뷰와 초안을 거쳐 외부 콘텐츠가 되고, 그 반응이 다시 구성원의 글쓰기 동력으로 돌아오는 순환 구조를 만드는 것이다.</p></section>\n          <section class=\"orbit-prompt\"><h3>AX 공유회 발표를 블로그 글감으로 바꾸기 위해 내부 에이전트가 맡는 역할은 무엇인가?</h3><p>발표자에게 빈 화면에서 글을 쓰게 하는 대신, 이미 공유한 경험을 질문으로 끌어내고 관점·맥락·구체 사례를 정리해 블로그 초안의 재료로 만드는 역할이다.</p></section>\n          <section class=\"orbit-prompt\"><h3>이 프로세스에서 발행 이후의 반응 회수가 중요한 이유는 무엇인가?</h3><p>글이 외부에 전달된 뒤의 반응과 인정이 작성자에게 돌아와야 ‘내 경험도 글이 될 수 있다’는 감각이 생기고, 다음 글을 쓰는 동력으로 이어지기 때문이다.</p></section>\n        </div>\n      </section>\n\n      <div class=\"quote\">블로그 자동화가 아니라, 글을 쓰는 문화가 생기기 전까지의 마중물 프로세스.</div>\n\n      <p class=\"note\">이 글은 2026년 6월 18일 AX 공유회 발표 이후 진행한 내부 에이전트 씰터뷰 내용을 기반으로 작성한 블로그 글 초안입니다.</p>",
      "summary": "블로그 사이트 구현을 넘어 내부 지식이 외부 콘텐츠가 되고 다시 구성원의 동력으로 돌아오는 흐름을 정리한 씰터뷰 글입니다.",
      "date_published": "2026-06-22T00:00:00.000Z",
      "authors": [
        {
          "name": "Corca Team"
        }
      ]
    }
  ]
}
