AI가 앱은 뚝딱 만들었는데…회사에서는 왜 못 쓸까?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Kimi Code가 업무용 앱을 뚝딱 만들어도, 회사에서 쓰려면 코딩보다 배포 인프라·데이터 영속성·접근 권한·보안 승인·운영 책임을 함께 해결해야 한다.

📌 핵심 요점

1. 생성형 AI의 활용 범위는 프롬프트 작성에서 바이브 코딩으로 넓어졌고, 비개발자도 법인카드 영수증 정리나 협업 프로그램처럼 구체적인 업무 도구를 몇 시간 안에 구현할 수 있게 됐다.
2. 그러나 개인용 프로토타입과 조직용 서비스는 전혀 다른 문제다. 전사 공유에는 서버 공간, 데이터베이스, 접근 권한, 보안 정책, IT 조직의 승인과 장기 운영 주체가 필요하다.
3. 팀 전용 PC나 Mac mini, Docker, OrbStack, Cloudflare 터널을 이용하면 소규모 공유 환경을 만들 수 있지만, 장비 설치와 외부 접속이 허용되는지는 회사별 보안 정책에 달려 있다.
4. 실제 운영 단계에서는 PRD를 기준으로 요구사항을 명확히 하고, 비밀정보 분리, 헬스체크, 자동 재시작, 개발·운영 환경 분리, GitHub Actions와 Runner를 통한 CI/CD, 데이터 영속성에 맞는 플랫폼 선택까지 설계해야 한다.
5. 가장 큰 병목은 기술만이 아니라 조직의 인센티브다. 도구를 만든 직원에게 구축·교육·확산·운영 책임과 성과 입증 부담이 집중되고 기존 업무까지 유지되면, 생산성 혁신은 자발적 공유보다 개인 사용과 노하우 은폐를 유도할 수 있다.

🧩 배경과 문제 정의

• 생성형 AI 활용이 프롬프트 작성에서 바이브 코딩으로 확장되면서, 비개발자도 업무용 프로그램을 직접 만들 수 있게 됐다.
• 개인용 프로토타입은 빠르게 완성할 수 있지만, 회사에서 공유하려면 서버·데이터베이스·접근 권한·보안 정책이라는 별도의 장벽을 넘어야 한다.
• 기술적 배포 문제뿐 아니라 추가 업무와 책임, 성과 입증 압박, 인력 감축 가능성까지 얽히면서 직원들이 만든 도구가 조직 전체로 확산되기 어렵다.

🕒 시간순 섹션별 상세정리

1. 기업 AI 교육의 초점 변화

• 기업 현장에서는 ChatGPT·Gemini·Claude를 이미 업무에 활용하는 직원이 많아져, 단순한 프롬프트 사용법만으로는 충분한 효용을 주기 어려워졌다. [04:00]
• 질문과 답변을 주고받는 노하우는 축적됐지만, 채팅창을 벗어나 실제 프로그램을 만드는 바이브 코딩까지 경험한 직원은 아직 많지 않다. [04:24]

2. 비개발자에게 열린 바이브 코딩

• 코딩도 챗봇과 대화하는 과정과 크게 다르지 않다는 사실을 체감하면, 비개발자도 자신의 업무 문제를 직접 해결할 수 있다는 가능성을 발견한다. [05:09]
• 법인카드 영수증 정리나 부서용 협업 프로그램처럼 구체적인 문제를 정하면, 기획서 없이도 두세 시간 안에 작동하는 결과물을 체험할 수 있다. [06:02]

3. 빠른 구현 뒤에 나타나는 배포 문제

• 개인용 프로그램이나 게임을 완성한 다음에는 다른 사람이 사용할 수 있도록 어디에 어떻게 배포할지가 새로운 과제가 된다. [07:05]
• 일정 관리나 랜딩 페이지 같은 서비스는 빠르게 만들 수 있지만, 혼자만 쓴다면 로컬 컴퓨터에서 실행하는 수준에 머물기 쉽다. [08:08]

4. 기업 인프라와 보안 정책의 장벽

• 규모 있는 기업은 자체 IT 조직과 인프라를 갖추고 있어도, 개인이 만든 서비스를 전사적으로 사용하려면 회사 서버와 보안 정책을 따라야 한다. [09:07]
• 배포에는 서버 공간·접근 권한·데이터베이스가 필요하며, Oracle이나 MySQL 같은 사내 DB는 초보자가 다루기 어렵고 IT 조직도 운영 위험 때문에 권한을 쉽게 내주지 않는다. [09:53]

5. 승인 절차가 만드는 조직적 비용

• 새로운 서비스를 올리려면 IT 조직에 필요성과 운영 방식을 설명하고 결재를 받아야 하며, 심사 기간이 길어지거나 요청이 반려될 가능성도 크다. [11:09]
• 도구를 제안한 직원에게 구축·확산·운영 책임까지 돌아오지만 기존 업무는 줄지 않아, 결국 조직 공유를 포기하고 혼자만 사용하는 선택으로 계속된다. [11:56]

6. AI 전파가 개인 책임으로 돌아오는 구조

• 사내 AI 교육과 도구 도입을 주도해도 직원들이 사용하지 않거나 제대로 정착하지 못한 책임까지 최초 제안자에게 부과될 수 있다. [12:37]
• 특히 대리·과장급 직원은 새로운 미션을 거부하기 어렵고 권한보다 책임이 커져, 자발적인 혁신 활동이 오히려 스트레스로 바뀔 위험이 있다. [13:08]

7. 회사별로 달라지는 소규모 배포 가능성

• 개인 PC나 팀 전용 미니 PC에서 서비스를 실행하면 중앙 인프라를 거치지 않고 소규모로 공유할 수 있지만, 허용 여부는 회사별 보안 정책에 따라 달라진다. [13:37]
• 보안 규제가 약한 조직은 팀 자체적으로 활용할 수 있는 반면, 통제가 엄격한 조직은 장비 설치와 내부 공유 자체가 제한될 수 있다. [14:08]

8. 공기업의 팀 전용 데스크톱 사례

• 보안 절차가 엄격한 한 공기업에서는 중앙 인프라에 서비스를 올리는 대신, 팀이 보유한 데스크톱 장비에서 서버를 실행해 내부 구성원만 사용하도록 요구했다. [15:07]
• 네다섯 명에서 열 명 이하의 조직이라면 중앙 정책과 분리된 팀 전용 실행 환경을 마련해 필요한 프로그램을 운영하는 대안이 가능하다. [16:00]

9. 폐쇄망과 예산이 제한하는 개발 환경

• 일부 회사에서는 Codex 같은 도구를 사용할 수 있어도 Kimi와 같은 외부 서비스는 차단되며, 더 엄격한 환경에서는 회사 PC의 바이브 코딩과 소규모 공유도 불가능하다. [17:17]
• 금융권의 폐쇄망이나 팀 인프라 예산 부족은 프로그램 개발뿐 아니라 배포 환경 확보까지 막아, 개인의 아이디어가 실제 업무 도구로 이어지기 어렵게 만든다. [18:35]

10. 개인 비용으로 만든 도구의 회사 사용

• 회사 환경에서 개발할 수 없다면 개인 노트북과 개인 구독을 이용해 업무 프로그램을 만든 뒤, 외부 환경에 배포해 회사에서 접속하는 방식을 생각할 수 있다. [19:10]
• 월 100~200달러 수준의 코딩 도구를 자기계발 비용으로 부담하더라도, 외부에 배포한 프로그램을 회사 업무에 사용하는 행위가 보안 정책상 허용되는지는 별개의 문제다. [19:51]

11. AI 지원에 따라붙는 성과 입증

• 한 코스닥 상장 기업은 직원별 AI 구독비를 지원하되, 매달 어떤 효과를 얻었는지 입증하지 못하면 지원을 중단할 수 있다는 조건을 붙였다. [20:46]
• 직원에게 AI는 업무 시간을 줄이는 생산성 도구지만, 기업에는 세 사람이 하던 일을 한 사람이 처리할 수 있는지를 판단하는 비용 절감 수단이 될 수 있다. [21:31]

12. 생산성 향상의 역설

• AI로 업무가 빨라지면 여유 시간이 생기는 대신 더 많은 일이 배정돼 개인의 부담이 오히려 증가할 수 있다. [22:05]
• 처리 속도 향상이 인력 감축의 근거가 될 수도 있으며, 기업의 AI 도입 의지가 강해도 구독비 지원이 없으면 개인은 월 20달러 안팎의 제한된 도구만 선택하게 된다. [22:24]

13. 개인 노하우와 조직 확산의 충돌

• 개인이 만든 프로그램은 업무 효율을 높여도, 확산 과정에서 추가 책임만 늘어날 수 있어 제작자가 혼자 사용하는 편을 선택하기 쉽다. [23:44]
• AI 활용 노하우로 회사 업무에 기여한 직원에게 프롬프트 공유를 요구하고, 퇴사 후 이를 제공하지 않았다는 이유로 법적 분쟁까지 벌어진 사례는 개인 지식과 회사 자산의 경계를 드러낸다. [24:15]

14. Codex와 Claude Code의 선택 기준

• Codex와 Claude Code의 성능 차이는 개발할 프로그램의 성격에 따라 달라지며, 전반적인 코딩 능력만으로 한쪽이 절대적으로 우세하다고 보기 어렵다. [24:43]
• Codex의 디자인 품질도 향상됐고 상대적으로 토큰 여유가 있어, 초보자는 가성비가 나은 Codex로 시작한 뒤 필요할 때 Claude Code를 경험하는 선택이 가능하다. [25:03]

15. 경영진의 실습과 현실적인 배포 방식

• 직원뿐 아니라 C레벨도 AI를 직접 사용해야 결과물이 한 번의 요청으로 완성되지 않고, 반복적인 수정과 검토가 필요하다는 현실을 이해할 수 있다. [26:04]
• Vercel·ChatGPT Sites·Cloudflare 터널·맥미니·개인 노트북 등으로 서비스를 공개하거나 내부 공유할 수 있으며, 데이터베이스가 필요한 서비스는 별도의 운영 환경을 준비해야 한다. [27:24]

16. 개인 장비를 활용한 서비스 배포 구상

• 보안을 위해 Proxmox 위에 서비스를 배치하고 Cloudflare 프록시 서버를 중간에 두는 방식도 개인 서버 배포 선택지에 포함된다. [30:05]
• Kimi Code로 약 한 시간 만에 고객사별 교육 목록과 강의 단계를 관리하는 기업 교육 운영 대시보드를 만들었다. [31:09]

17. 로컬 서비스를 외부에서 사용해야 하는 이유

• 로컬에서만 실행하면 외부 활동 중이거나 회사에 있을 때 접근할 수 없으므로, 실제 서비스로 쓰려면 상시 접속 가능한 환경에 배포해야 한다. [32:11]
• VibeLabs KR 도메인과 Docker, Cloudflare 터널링을 결합해 별도 서버 없이 맥미니를 운영 서버로 활용한다. [32:45]

18. 비개발자의 AI 기반 배포 범위

• 배포가 본업이 아닌 사용자는 기술 절차를 모두 숙지하기보다 전체 흐름을 이해한 상태에서 AI에 실행을 맡길 수 있다. [33:59]
• 기업 교육 대시보드는 이미 Docker 컨테이너에서 실행 중이며, 현재 개발 환경을 운영 환경으로 전환하는 것이 다음 과제다. [34:12]

19. OrbStack을 이용한 컨테이너 실행 환경

• LectureOps 컨테이너는 Docker Desktop 호환 도구인 OrbStack에서 실행되며, 개인 사용자는 무료로 이용할 수 있다. [34:38]
• 개발 컨테이너를 GitHub에 푸시하면 맥북·맥미니·윈도우 PC 등 선택한 장비를 운영 서버로 사용할 수 있다. [35:13]

20. 터미널 실행과 컨테이너 운영의 차이

• AI가 특정 포트로 개발 서버를 실행해도 터미널을 닫으면 프로세스가 종료되므로 지속적인 서비스 운영에는 적합하지 않다. [36:53]
• OrbStack에서는 컨테이너를 버튼으로 종료하거나 다시 기동할 수 있고, 호스트와 컨테이너가 사용하는 3000번 포트도 확인할 수 있다. [37:56]

21. 개인 서버와 GitHub 기반 자동 배포

• 회사 PC·맥미니·미니 PC를 서버로 활용하면 Docker Desktop 계열 도구로 서비스 실행 환경을 단순하게 관리할 수 있다. [38:38]
• GitHub에 코드를 푸시하는 순간 운영 장비까지 자동 배포하는 CI/CD 흐름을 구성하면 수동 배포의 복잡성과 실수를 줄일 수 있다. [39:01]

22. 긴 배포 지시를 PRD로 전환

• 약 7천 자의 배포 프롬프트와 Kimi Code의 Goal 스킬을 결합해 프로덕션 배포 전 과정을 자동화하려 했지만, 입력창의 4천 자 제한에 걸렸다. [40:28]
• 긴 요구사항을 프로젝트 폴더의 PRD.md 파일로 저장하고 AI가 해당 문서를 기준으로 작업하도록 전환했다. [41:18]

23. 프로덕션 배포 요구사항의 구체화

• LectureOps를 프로덕션 이미지로 패키징하고 Docker Compose로 실행하며, 같은 LAN의 다른 PC와 스마트폰에서도 접근할 수 있어야 한다. [41:55]
• 운영 비밀정보를 소스에서 분리하고 헬스체크와 비정상 종료 시 자동 재시작을 구현해 보안성과 가용성을 함께 확보해야 한다. [42:05]

24. 자율 배포 모드와 후속 기능 배포

• PRD.md에 따른 배포를 지시하고 자동 재시작 모드로 전환해, 완료 지점까지 작업이 이어지는 실행 환경을 구성했다. [43:18]
• 초기 프로덕션 구성이 끝나면 새 기능을 추가한 뒤 GitHub에 푸시하는 것만으로 변경 사항이 자동 배포되는 흐름을 목표로 한다. [43:41]

25. 사용자 요청 중심의 라이브 주제 선정

• 이후 라이브는 채팅방과 VibeLabs 커뮤니티에서 받은 요청을 반영해, 실제 사용자가 필요로 하는 주제를 중심으로 구성한다. [44:31]
• 제품 중심 요구사항은 PRD, 비즈니스 관점의 요구사항은 BRD로 구분할 수 있다. [45:16]

26. GitHub가 CI/CD의 중심이 되는 이유

• GitHub는 소스 형상 관리뿐 아니라 Actions와 Runner 같은 자동화 기능을 제공해 별도의 배포 시스템을 직접 구현할 부담을 줄인다. [45:53]
• 무료로 사용할 수 있고 다수의 웹 호스팅·배포 서버가 GitHub 연동을 지원하므로 CI/CD 구성의 기본 플랫폼으로 자리 잡았다. [46:01]

27. 회사 업무 자동화를 위한 작업 분해

• 큰 업무를 실행 가능한 작은 단위로 나누지 않으면 AI가 자동화 범위와 순서를 판단하기 어렵고, 실제 실행 단계에서도 모호성이 남는다. [48:06]
• 먼저 AI에 업무 맥락을 충분히 이해시킨 뒤 작업을 분해하게 하고, 애자일 방식처럼 하루 안에 처리할 수 있는 크기까지 줄이는 접근이 유효하다. [48:48]

28. 도메인 지식을 AI에 전달하는 방법

• 간단한 방법은 관련 자료를 NotebookLM에 폭넓게 업로드한 뒤, 축적된 맥락을 바탕으로 업무 처리와 자동화 방법을 함께 찾는 것이다. [49:29]
• 더 정교한 환경에서는 그래프나 RAG를 구축해 AI가 전체 업무 구조와 관계를 이해하도록 만든 다음 자동화 단계로 넘어갈 수 있다. [49:49]

29. 온보딩 매뉴얼 제작 실습 준비

• 완성된 작업물을 다른 사용자가 온보딩할 수 있도록 매뉴얼로 전환하는 과정을 Kimi에서 직접 시험한다. [51:02]
• 빠른 결과를 위해 K3 모델의 딥 리서치를 선택하고, 매뉴얼의 출발 자료로 사용할 주제를 X에서 탐색한다. [51:44]

30. 그래프 엔지니어링 매뉴얼 프롬프트

• 첨부 사이트뿐 아니라 관련 아티클·논문·기사·블로그를 수집하고, 왕초보도 이해할 수 있는 형식으로 재구성하도록 요청한다. [53:50]
• 개념 이해부터 설치와 활용까지 다루고, 사용자가 여러 옵션을 직접 체험할 수 있는 인터랙티브 HTML 매뉴얼로 제작해 별도 배포하도록 범위를 정한다. [54:39]

31. 리서치 모드 선택과 실제 매뉴얼 생성

• Deep Research는 작업 시간이 짧고, 다수 에이전트를 활용하는 Swarm은 시간이 오래 걸리지만 경험상 결과물의 품질이 더 높다. [55:57]
• 배포 작업은 GitHub 푸시와 Actions 확인을 거쳐 셀프 호스티드 Runner에서 실제 운영 장비로 배포하는 단계에 진입했다. [56:35]

32. 간단한 요청으로 완성하는 HTML 매뉴얼

• Kimi는 그래프 엔지니어링 자료 수집을 마친 뒤 매뉴얼 구조를 설계하고 HTML 제작 단계로 넘어갔다. [58:35]
• Orca AD 매뉴얼은 공식 사이트·웹·X·YouTube를 검색해 기초 사용법부터 활용법까지 담은 HTML 페이지를 만들어 달라는 짧은 요청으로 제작했다. [59:27]

33. 핵심을 관통하는 지시와 스웜 설정

• 긴 설명보다 핵심 요구사항을 정확한 문장으로 전달하는 능력이 결과를 좌우하며, 프롬프트에는 해결해야 할 중심 문제를 선명하게 담아야 한다. [1:00:01]
• 스웜은 이론상 최대 300개의 에이전트를 작동시킬 수 있고, 새 채팅에서 스웜과 K3를 선택한 뒤 추론 강도와 콘텐츠 길이를 조정할 수 있다. [1:00:21]

34. Kimi 데스크톱의 로컬 폴더 연동

• Kimi 데스크톱은 로컬 폴더를 작업 공간으로 지정할 수 있어, 기존 프로젝트 파일을 불러와 분석과 수정 작업을 이어갈 수 있다. [1:02:39]
• 프로젝트 폴더를 선택하고 현재 구조 분석을 요청하면 되지만, 데스크톱 사용 경험은 확인되지 않았고 터미널 방식이 주된 작업 환경이다. [1:03:03]

35. AI 배포와 개발·운영 환경 분리

• AI에게 배포 전반을 맡길 수 있어도 GitHub 푸시와 GitHub Actions 같은 기본 절차를 알아야 오류 발생 시 흐름을 점검할 수 있다. [1:03:59]
• 코딩과 디버깅을 수행하는 개발 폴더와 실제 서비스가 동작하는 프로덕션 폴더를 분리하면 변경 작업이 운영 환경을 직접 훼손할 위험이 줄어든다. [1:04:53]

36. Mac mini 운영 서버와 협업 규칙

• Mac mini를 별도 서버로 두고 화면 공유와 Claude Code를 연결하면 개인 PC와 분리된 상시 운영 환경을 구성할 수 있다. [1:05:24]
• 여러 팀원이 같은 저장소에 직접 푸시하면 병합 충돌이 커지므로, PR을 통한 검토와 병합 절차가 협업 안정성에 필요하다. [1:06:07]

37. Vercel에 적합한 정적 서비스

• 데이터베이스가 없는 정적 사이트는 Vercel에 적합하지만, 실행 상태와 업로드 파일은 서버 재시작 과정에서 초기화될 수 있어 영구 저장소처럼 사용할 수 없다. [1:07:06]
• 내용이 자주 변하지 않는 홈페이지는 정적 배포의 장점을 얻지만, 자체 상태를 보존해야 하는 애플리케이션은 별도 저장 구조가 필요하다. [1:07:30]

38. 데이터베이스 구조가 결정하는 배포 플랫폼

• Supabase처럼 외부에서 영속성을 보장하는 데이터베이스는 Vercel과 조합할 수 있지만, 로컬 파일에 저장하는 SQLite는 서버리스 환경과 맞지 않는다. [1:07:40]
• SQLite 파일은 배포 환경이 원본 상태로 리셋될 때 함께 교체될 수 있어, 서비스에서 축적한 데이터가 전부 삭제될 위험이 있다. [1:08:13]

39. GitHub 중심의 자동 배포 경로

• 최소한 GitHub로 소스 코드를 관리해야 변경 이력을 보존하고, 배포 실패나 서버 장애가 발생했을 때 이전 상태를 복구할 수 있다. [1:09:22]
• GitHub Actions와 Runner는 DigitalOcean·Vultr 같은 호스팅 서비스와 연동되며, 저장소에 푸시하는 동작만으로 배포를 시작할 수 있다. [1:10:12]

40. 서버리스 데이터베이스와 Cloudflare 조합

• Vercel Postgres나 Neon 같은 외부 데이터베이스와 Cloudflare R2를 조합하면 애플리케이션 실행 환경과 영구 저장 공간을 분리할 수 있다. [1:12:01]
• Cloudflare의 무료 티어와 서버리스 구조는 초기 운영 비용과 서버 관리 부담을 낮추는 선택지가 될 수 있다. [1:12:15]

41. 브라우저와 컴퓨터 제어를 통한 설정 자동화

• 과거에는 클라우드 콘솔 화면을 캡처해 AI에게 설정 방법을 묻고 사용자가 직접 입력했지만, 브라우저 제어 기능은 페이지의 입력과 설정 작업까지 대신 수행한다. [1:12:58]
• AI 접근이 차단된 보안 영역만 사용자가 직접 처리하면 되고, 일반적인 Cloudflare 터널링과 콘솔 설정은 Claude Code나 브라우저 확장으로 자동화할 수 있다. [1:13:34]

42. 클라우드 콘솔 자동화와 민감정보 처리

• Google Cloud Console, Amazon S3, 이메일 자동화처럼 설정 단계가 많은 작업도 AI가 대신 처리하면서 인프라 구축의 수작업 부담이 줄어든다. [1:15:07]
• API 키는 민감정보이므로 사용자가 필요한 값만 복사해 환경변수에 저장하고, AI에는 저장 위치와 후속 작업만 맡기는 방식이 안전하다. [1:15:39]

43. Kimi Code의 프로덕션 배포 자동화

• Kimi Code는 GitHub Actions와 Runner 설정이 필요한 프로덕션 배포를 진행하면서 사용자에게 별도 조치를 요구하지 않아, 이전보다 개입 단계가 크게 줄었다. [1:16:50]
• GitHub Actions 화면에서는 실제 배포 작업과 반복된 빌드 시도를 확인할 수 있으며, 세 번째 빌드까지 자동으로 재시도하는 흐름이 나타났다. [1:17:44]

44. 사용량과 보안 제약의 차이

• Vivace 요금제에서 주간 토큰 사용량은 24%에 그쳐, 고강도 코딩과 배포 작업을 수행해도 사용 한도에는 상당한 여유가 있었다. [1:18:36]
• Kimi는 Claude Code보다 보안 제한이 느슨하게 느껴졌고, 로봇 정책 등으로 일반적인 접근이 막힌 웹사이트의 스크래핑도 수행했다. [1:19:17]

45. 배포 워크플로 검증과 형상 관리

• 세 번째 워크플로가 실제 배포 단계에 진입하면서, 단순한 코드 생성이 아니라 CI 작업 실행까지 자동화되는 흐름을 확인할 수 있다. [1:20:15]
• 이후 기능을 추가해 저장소에 푸시했을 때 프로덕션 배포까지 자동으로 이어지는지만 확인하면 지속 배포 구성의 정상 동작을 검증할 수 있다. [1:20:36]

46. GitHub 허브와 Kimi Code의 발전

• GitHub 저장소가 살아 있으면 Mac mini가 중단돼도 다른 서버나 배포 경로로 전환할 수 있어, 특정 장비에 종속되지 않는 복구 지점이 된다. [1:22:57]
• Kimi Code CLI는 2.6·2.7대에서 3.0으로 오면서 사용성이 개선됐고, Claude Code 역시 질문 도구와 명령 기능을 지속적으로 확장하고 있다. [1:23:37]

47. 장시간 빌드 관찰과 운영 서버의 역할

• 빌드가 5분 이상 이어지자 감시 작업을 백그라운드로 전환해, 긴 배포를 기다리는 동안 다른 작업을 계속할 수 있게 했다. [1:26:31]
• GitHub Actions의 실행 항목을 열면 빌드와 배포 진행 과정을 단계별로 확인할 수 있어, 자동화 이후에도 운영 상태를 추적할 수 있다. [1:29:09]

48. 저전력 서버로 활용하는 맥 미니

• 맥 미니로 바이브랩스 홈페이지를 약 9개월간 중단 없이 운영했으며, 서버가 꺼진 적도 없었다. [1:30:35]
• 월 전기요금은 약 2,000~3,000원이고 소비전력과 발열이 낮아 상시 가동 서버에 적합하다. [1:30:40]

49. UI 디자인 참고 자료 활용

• 모션 중심 웹사이트는 화면 전환과 상호작용을 설계할 때 참고할 수 있는 디자인 자료가 된다. [1:36:35]
• 모비처럼 널리 알려진 UI 레퍼런스 사이트를 함께 활용하면 화면 구성과 디자인 완성도를 높이는 데 도움이 된다. [1:36:50]

50. 배포 오류와 반복 수정

• Kimi Code의 배포 과정에서 오류가 발생해 작업 시간이 예상보다 길어졌고, 정상 배포를 위해 재시도가 필요해졌다. [1:37:20]
• 배포 실패는 원인을 찾아 수정한 뒤 다시 배포하는 순환 작업으로 이어지며, 자동화 도구도 이 과정을 완전히 피하지 못한다. [1:37:37]

51. 그래프 엔지니어링 매뉴얼의 구성

• Kimi로 제작한 그래프 엔지니어링 매뉴얼은 프롬프트 중심 접근에서 워크플로와 에이전트 설계로 넘어가는 과정을 다룬다. [1:37:49]
• 그래프 이론 자체보다 상태·노드·엣지·게이트라는 네 가지 구성 요소와 다섯 가지 핵심 패턴으로 개념을 구조화한다. [1:38:17]

52. 실행형 학습 자료와 웹 배포

• 각 항목을 클릭하면 설명이 나타나고 점수·문제·퀴즈가 동작해, 정적인 문서가 아니라 게임형 학습 자료로 사용할 수 있다. [1:38:53]
• 그래프 도입 필요성을 점검하고 예제 프로그램과 참고 자료까지 실행형으로 제공해 실제 적용 여부를 판단할 수 있다. [1:39:10]

53. Kimi Code 활용과 현실적인 우려

• Kimi Code는 코딩 작업에 자주 활용할 만큼 확산됐지만, 사용자가 몰리면서 신규 가입이 막혀 기존 가입자만 이용할 수 있는 상태였다. [100:17] [1:41:10]
• 중국 서비스라는 점에서 개인정보 우려가 남아 있지만, 편의성을 택해 실제 코딩 작업을 계속 맡기는 선택도 가능하다. [100:28] [1:41:25]

54. Codex에 통합된 Open Design

• Codex에는 Open Design이 탑재돼 디자인 작업을 별도 도구 밖으로 옮기지 않고 플러그인 형태로 실행할 수 있다. [100:52] [1:43:36]
• 플러그인을 설치한 뒤 @와 Open Design 명령을 입력하면 기능이 활성화되고, 현재 작업 환경에서 바로 디자인을 시작할 수 있다. [101:49] [1:43:51]

55. Open Design의 독립 실행과 AI 연동

• Open Design은 디자인 품질을 개선하며, 자체 웹사이트와 CLI를 통해 Codex나 Claude 같은 여러 AI 도구와 연결할 수 있다. [102:55] [1:45:13]
• 메뉴에서 사용할 AI를 선택할 수 있어 특정 모델에 고정되지 않고 디자인 작업 환경을 구성할 수 있다. [103:40] [1:45:28]

56. 작업 단계에 따른 AI 도구 교체

• Kimi Code가 배포를 제대로 처리하지 못하면 Claude Code로 전환하는 방식으로 병목을 우회할 수 있다. [104:12] [1:47:52]
• 하나의 도구에 모든 단계를 맡기기보다 코딩·디자인·배포 성능에 따라 적합한 AI를 골라 쓰는 방식이 실용적이다. [104:21] [1:48:07]

57. Open Design 설치와 상용화 기준

• GitHub의 Open Design 주소를 AI에 전달해 설치를 요청하면 GUI가 실행되고, 그 화면에서 사용할 AI를 CLI로 연동할 수 있다. [105:13] [1:48:22]
• 혼자 쓰는 프로그램은 디자인 우선순위가 낮지만, 공동 사용·포트폴리오·상용화가 목적이면 UI 완성도까지 관리해야 한다. [106:27] [1:48:37]

58. 배포 자동화에서 줄어드는 인간 개입

• 자동 배포에서 인간이 직접 처리할 작업은 로그인이나 인증 정도로 줄고, 오류 수정 같은 반복적이고 번거로운 단계는 AI가 대신하게 된다. [109:52] [1:49:54]
• 사람의 시간은 절약되지만 반복 실행에 토큰이 소비되므로, 자동화 효율과 사용 비용을 함께 고려해야 한다. [110:15] [1:50:15]

59. 가입 제한과 미완료 배포의 후속 처리

• Kimi 신규 가입 재개 시점은 담당자도 확답하지 못했고, 특정 채널 이용자만 별도로 가입시키는 요청도 받아들여지지 않았다. [111:49] [1:52:23]
• 진행 중인 배포는 Kimi Code에 계속 맡기고, 완료 결과는 별도 채팅방에서 공유하기로 했다. [112:53] [1:52:38]

🧾 결론

• Kimi Code는 코드 생성에서 GitHub Actions와 Runner 설정을 포함한 프로덕션 배포까지 인간의 개입을 줄일 가능성을 보여줬지만, 반복된 빌드와 배포 실패는 자동화 결과를 사람이 검증해야 한다는 점도 드러냈다.
• 기업용 AI 앱의 성패는 얼마나 빨리 만들었는지가 아니라 누가 승인하고, 어디서 실행하며, 데이터를 어떻게 보존하고, 장애와 보안을 누가 책임지는지에 의해 결정된다.
• 중앙 인프라 도입이 어려운 조직에서는 승인된 팀 전용 장비를 활용한 소규모 배포가 현실적인 중간 단계가 될 수 있지만, 비공식 우회 배포가 아니라 사내 정책 안에서 설계해야 한다.
• GitHub를 소스와 변경 이력의 허브로 유지하고 개발 장비와 운영 장비를 분리하면, 특정 서버가 중단되거나 자동 배포가 실패해도 복구 가능한 운영 기반을 확보할 수 있다.

📈 투자·시사 포인트

• 기업 AI 시장의 차별화 지점은 단순 코드 생성에서 보안 승인, 권한 관리, 데이터 영속성, 배포 자동화, 장애 복구를 통합하는 운영 역량으로 이동할 가능성이 크다.
• Vercel 같은 정적·서버리스 플랫폼과 Docker 기반 상시 서버는 대체 관계가 아니라 데이터 보존 방식과 실행 상태에 따라 선택되는 상호 보완적 인프라다.
• GitHub Actions, Runner, 컨테이너, 외부 데이터베이스, Cloudflare 같은 구성 요소는 비개발자의 앱을 실제 서비스로 전환하는 연결 계층으로서 중요성이 커질 수 있다.
• AI 생산성의 효과를 인력 감축이나 추가 업무 배정으로만 회수하면 직원의 자발적 도입과 노하우 공유가 위축될 수 있으므로, 기업은 비용 절감뿐 아니라 기여 보상과 책임 재설계까지 함께 고려해야 한다.
• Kimi Code, Codex, Claude Code는 코딩·디자인·배포 단계마다 강점과 제약이 달라 하나의 도구에 고정하기보다 작업별로 교체하는 멀티도구 전략이 실용적이다.

⚠️ 불확실하거나 확인이 필요한 부분

• Kimi Code의 프로덕션 배포는 여러 차례 실패한 뒤 재시도 중이었으며, 최종적으로 지속 배포가 정상 작동했는지는 영상 안에서 확인되지 않았다.
• Kimi 데스크톱의 로컬 폴더 연동은 소개됐지만 발표자도 데스크톱 사용 경험이 확인되지 않았다고 밝혀, 실제 안정성과 작업 범위는 추가 검증이 필요하다.
• 개인 PC, 팀 전용 미니 PC, Cloudflare 터널, 외부 배포 서비스의 허용 범위는 회사마다 다르므로 다른 조직의 성공 사례를 그대로 적용할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자동화하려는 업무를 하루 안에 처리할 수 있는 작은 단위로 분해하고, 반복 조건과 입력·출력, 성공 기준을 PRD에 명시한다.
• 개발 전에 IT·보안 담당자와 서버 위치, 외부 접속, 데이터 등급, 접근 권한, 로그, 소유권, 장애 대응 및 운영 책임을 합의한다.
• 화면이나 프레임워크보다 데이터 보존 방식을 먼저 결정하고, SQLite·Supabase·외부 서버리스 데이터베이스 중 배포 환경에 맞는 구조를 선택한다.
• GitHub로 소스와 변경 이력을 관리하고 Docker Compose, 비밀정보 분리, 헬스체크, 자동 재시작, 개발·운영 환경 분리와 롤백 절차를 구성한다.

❓ 열린 질문

• 직원이 만든 업무 도구와 프롬프트는 개인 노하우와 회사 자산 중 어디에 속하며, 퇴사·인수인계·보상 기준은 어떻게 정해야 하는가?
• AI로 절감한 시간을 추가 업무나 인력 감축이 아니라 직원과 조직이 함께 이익을 얻는 방식으로 배분하려면 어떤 성과 지표가 필요한가?
• 팀 전용 장비에서 시작한 서비스를 언제 중앙 인프라로 이전해야 하며, 사용 인원·데이터 민감도·장애 비용 중 무엇을 전환 기준으로 삼아야 하는가?