일하는 ai

70. 1일차 2 1000억 벌기 매출

12 min read

-

코드팩토리는 새로 만든 채널 인증이 안 돼 기존 채널에서 라이브를 이어 가며, PMS와 MCP 주변 구조를 실제로 붙여 보는 과정을 보여준다. 포트 변경, 디자인 선택, 문서 확인, 검색 기반 디버깅 원칙까지 실시간으로 드러나서 구현보다 운영 판단이 더 선명하게 남는 세션이다.

flowchart LR
A[PMS와 MCP 흐름을 실제로 붙여야 함] --> B[새 채널 인증 지연과 라이브 환경 이슈]
B --> C[포트 변경·디자인 선택·공식 문서 확인·검색 기반 수정]
C --> D[다음 작업에 이어질 구조와 운영 원칙 정리]

핵심 요약

  • 새로 만든 채널은 인증이 안 돼 최대 24시간이 걸린다고 했고, 그래서 이날 작업은 기존 채널 라이브에서 계속 진행된다.
  • 초반 작업은 PMS 테스트와 슬라이드 리워크, index.html 오픈, 프로젝트 링크와 어댑터 흐름 확인 쪽에 맞춰져 있다.
  • 세션 중간에는 “우리가 서버 포트를 바꿔 놔야 돼”라고 짚으면서 4400 포트를 기준으로 다시 잡고, 3000, 4040, 4600 같은 숫자를 오가며 로컬 동작을 확인한다.
  • 설계 쪽에서는 design A를 선택하고 다른 콘셉트는 제거하라고 정리한다. 동시에 “official documentation”, “most recent and official way”를 기준으로 구현하라고 방향을 준다.
  • 후반에는 PMS에 파일을 다 넣는 방식은 레이턴시 때문에 맞지 않을 수 있다고 보고, “하네싱을 자동화해 주는 프레임워크 같은 느낌”으로 보는 편이 맞다고 설명한다. 확신이 없을 때는 인터넷 검색을 먼저 시켜 답을 바꾸는 것도 작업 원칙으로 말한다.

왜 지금 중요한가

이 라이브가 남기는 값은 완성본보다 의사결정 로그에 가깝다. 개발팀 실전에서는 기능 하나를 만드는 속도만큼, 포트를 어디에 고정할지, 어떤 설계를 버릴지, 모를 때 검색과 공식 문서를 어떤 순서로 볼지가 유지보수 품질을 갈라놓는데, 그 판단이 영상 안에 그대로 나온다.

주요 내용

새 채널 인증 문제로 기존 채널에서 바로 이어 간다

시작부터 기술 작업 외 이슈가 하나 나온다. 새 채널에서 라이브하려고 했지만 인증이 필요했고, 그 인증은 최대 24시간까지 걸린다고 한다. 그래서 이날은 목표를 크게 잡기보다 저녁 먹기 전까지 기존 채널에서 계속 진행하겠다고 정리한다.

이 맥락이 중요한 이유는 세션 전체가 미리 짜인 강의보다 실제 작업 로그에 가깝기 때문이다. 댓글이 안 보이는 문제도 잠깐 언급하지만, 그대로 진행하면서 PMS 테스트로 바로 들어간다.

PMS 테스트와 포트 재설정이 세션의 첫 축이다

초반 작업에서는 “things to actually test”를 적어 두고 PMS 관련 링크, 어댑터, 셋업 흐름을 점검한다. 이어서 슬라이드 리워크가 됐다고 말하고 index.html을 열어 보며 상태를 확인한다.

여기서 가장 분명하게 남는 판단은 포트다. “항상 이게 굉장히 중요한게 우리가 서버 포트를 바꿔 놔야 돼”라고 말한 뒤 next 서버를 4400으로 바꾸는 흐름을 탄다. 이후 4040, 4400, 3000, 4600 같은 숫자가 계속 등장하는데, 단순 구현보다 로컬 환경을 다시 맞추는 작업 비중이 컸다는 걸 보여 준다.

디자인 선택과 문서 기준이 함께 잡힌다

중간에는 “So we are going to go with design A”라고 못 박고, 다른 콘셉트는 제거하라고 한다. 이건 UI 취향 얘기라기보다 구현 범위를 줄이는 결정에 가깝다. 라이브로 작업할 때 가장 흔한 실패가 선택지를 남겨 둔 채 계속 고치는 건데, 여기서는 먼저 방향을 고정한다.

문서 기준도 같이 나온다. “look official documentation”, “implement in the most recent and official way”라고 하면서 최신 공식 방식으로 구현해야 한다고 정리한다. 즉흥적으로 돌아가는 해법보다, 이후에도 다시 읽고 맞출 수 있는 기준점을 남기려는 선택으로 보인다.

MCP와 PMS를 보는 관점이 후반에 더 선명해진다

후반으로 가면 프로젝트의 중심이 기능 자체보다 구조 쪽으로 이동한다. “What if we explicitly make users trigger skills to create a workflow?” 같은 질문을 던지면서 워크플로 절차를 저장하는 방향을 생각하고, 나중에는 “So MCP server runs on next and comb…”라고 하며 서버 배치와 연결 구조를 계속 확인한다.

특히 [04:22] 근처 설명이 구체적이다. 파일을 전부 넣는 방식은 레이턴시 때문에 말이 안 될 수 있고, PMS는 “하네싱을 자동화해 주는 프레임워크 같은 느낌”이 될 것 같다고 한다. 다시 말해 모든 것을 한 군데에 몰아넣는 제품보다, 기존 흐름을 묶고 자동화하는 얇은 레이어에 더 가깝게 보고 있다는 뜻이다.

확신이 없을 때는 검색을 먼저 시키는 운영 원칙

이 라이브에서 인상적인 부분 하나는 모를 때의 처리 방식이다. [04:29] 근처에서 그는 “확신이 안 들면은 일단 인터넷 찾아보고서 와라고 하면은 답변이 달라져요”라고 말한다. 알고 있으면 직접 few-shot이나 수정 방향을 주는 게 낫지만, 모르는 경우에는 검색을 시켜서 인터넷 기반으로 답하게 하는 편이 더 낫다고 설명한다.

즉, 모델이 혼자 추정한 답보다 검색을 거친 답을 더 신뢰하는 장면이 반복된다. 이건 요즘 에이전트 워크플로를 다룰 때 꽤 실무적인 습관이다. 모델의 자신감보다 근거 경로를 먼저 붙이는 방식이기 때문이다.

원문 발화 하이라이트

  • [00:54] “안타깝게도 인증을 해야 되더라고요. 근데 인증은 제가 안 해 놔서 최대 24시간까지 걸린답니다.”
  • [01:48] “오늘 장애둔 목표 없습니다. 그냥 일단이 지금 라이브는 저녁 먹기 전까지 할 거고요.”
  • [04:13] “항상 이게 굉장히 중요한게 우리가 서버 포트를 바꿔 놔야 돼.”
  • [08:56] “So we are going to go with design A.”
  • [13:57] “look official documentation implement in the most recent and official way”
  • [04:22:24] “제가 생각하는 거는 파일을 다 넣는 거는 사실상 레이턴시 때문에 좀 말이 안 될 거 같고”
  • [04:29:42] “일단 인터넷 찾아보고서 와라고 하면은 답변이 달라져요.”
  • [04:33:43] “모르는 경우에는 서치를 시키는게 좋고요.”

바로 실행해 보기

  • 작업 시작 전에 things to actually test 메모를 만들고, PMS 링크 확인 → 프로젝트 연결 → 어댑터 설치 → index.html 오픈 순서로 테스트 항목을 잘게 쪼갠다. 영상처럼 먼저 테스트 순서를 고정해 두면 중간에 수정이 많이 들어가도 어느 단계에서 막혔는지 바로 되짚을 수 있다.
  • 서버를 띄울 때는 포트를 먼저 하나로 못 박는다. 이 세션처럼 4400을 기준으로 잡고, 실제 웹이 3000, 4040, 4600 중 어디에서 열리는지 바로 확인한 다음, 도메인 이름이나 엔트리 설정이 어긋난 부분을 다시 맞춘다.
  • 구현 방향이 헷갈리면 후보를 늘리지 말고 design A처럼 하나를 먼저 정한 뒤 다른 콘셉트는 제거한다. 그다음 공식 문서를 다시 보고 “most recent and official way”로 구현을 맞추고, 그래도 확신이 안 서는 부분만 인터넷 검색을 붙여서 답을 교정한다.

참고

영상 메타

수집 품질

  • 자막 세그먼트: 2659개
  • 자막 문자수: 31071자
  • 챕터 추출: 0개
  • 콘텐츠 생성: Subagent 기반

AI 생성 도구를 활용해 초안을 구성했고, 원영상 발화와 공개 자료를 교차 확인해 정리했습니다.

그래프 뷰

백링크