AI 활용 FAQ
AX·AI-native·에이전트 운영에 대해 가장 자주 받는 질문 18개. 전부 실제 운영 경험에서 나온 답입니다.
Q1. AX(AI 전환)가 뭔가요?
AI Transformation — 업무 일부에 AI를 '도구'로 쓰는 단계를 넘어, 조직의 운영 방식 자체를 AI 중심으로 재설계하는 것을 말합니다. 문서 요약에 챗봇을 쓰는 건 AI 활용이고, 리서치→제작→검증→배포 파이프라인을 에이전트가 돌리고 사람은 승인만 하는 구조가 AX입니다.
Q2. AI-native 회사는 뭐가 다른가요?
AI를 나중에 붙인 회사가 아니라 처음부터 AI가 1급 구성원인 회사입니다. 특징 세 가지: ① 지식이 사람 머릿속이 아니라 AI가 읽는 문서(회사 두뇌)에 있고 ② 반복 업무는 크론·에이전트가 수행하며 ③ 사람은 방향 결정과 승인 게이트만 담당합니다.
Q3. 1인 기업도 가능한가요?
가능합니다. 이 사이트(OIYO)가 그 사례로, 사람 1명이 AI 에이전트 조직과 함께 웹사이트 6개를 운영합니다. 오히려 의사결정 병목이 없는 1인 조직이 AX 속도가 가장 빠릅니다. 최소 구성은 코딩 에이전트 1개 + 마크다운 두뇌 폴더 + 검증 스크립트면 시작됩니다.
Q4. 비용은 얼마나 드나요?
구성에 따라 0원부터 시작할 수 있습니다. 무료 축: Gemini CLI(코딩), 무료 티어 챗봇들, Cloudflare Pages·GitHub Pages(호스팅), Ollama(로컬 모델). 본격 운영은 코딩 에이전트 구독(월 2~20만원대)이 중심 비용이고, 서버 비용은 정적 사이트 구조로 0원에 가깝게 유지할 수 있습니다.
Q5. 코딩을 몰라도 되나요?
시작은 됩니다. Replit·Lovable 같은 도구는 대화만으로 앱을 만들어 주고, 코딩 에이전트가 코드를 대신 씁니다. 다만 '무엇을 검증해야 하는지'를 판단하는 눈은 필요합니다 — 코드를 직접 쓰는 능력보다, 요구사항을 명확히 말하고 결과를 의심하는 능력이 핵심입니다.
Q6. 어디서부터 시작해야 하나요?
① 반복되는 업무 하나를 고르고(주간 리포트, 자료 정리 등) ② 그 업무의 입력→출력을 글로 정의한 뒤 ③ AI에게 맡기고 결과를 검증하는 체크리스트를 만드세요. 도구 선택은 그 다음입니다. 이 순서를 뒤집으면(도구부터 사면) 대부분 구독료만 나갑니다.
Q7. 에이전트(Agent)와 챗봇의 차이는?
챗봇은 물으면 답하고 끝나지만, 에이전트는 목표를 받아 도구(파일 수정, 명령 실행, 웹 검색)를 스스로 사용하며 여러 단계를 진행합니다. '이 버그 고쳐줘'에 코드를 찾고, 수정하고, 테스트까지 돌리는 것이 에이전트입니다.
Q8. 에이전트 '조직'은 왜 필요한가요?
하나의 만능 에이전트보다 역할별로 나눈 에이전트가 안전하고 품질이 높기 때문입니다. 핵심은 프롬프트가 아니라 권한 경계입니다 — 검증 담당은 읽기 전용, 리서치 담당은 코드 수정 불가처럼 도구 자체를 제한하면 실수의 반경이 줄어듭니다.
Q9. AI가 지어내는 답(환각)은 어떻게 막나요?
완전히 막을 수는 없고, 구조로 관리합니다: ① 수치·사실은 API/DB 원본에서 코드로 가져오고 AI에겐 해석만 맡기기 ② 출처 표시를 강제하기 ③ 중요한 출력은 검증 게이트(테스트·감사·사람 확인)를 통과시키기. 'AI를 믿지 말고 게이트를 믿는다'가 원칙입니다.
Q10. 회사 두뇌(brain)가 뭔가요?
에이전트가 세션을 넘어 기억을 이어가도록 만든 마크다운 지식베이스입니다. 결정(왜 그렇게 했나), 실패(다시 하면 안 되는 것), 진행 맥락을 축적하고, 새 세션의 AI가 먼저 읽습니다. Obsidian 같은 로컬 위키로 충분히 시작할 수 있습니다.
Q11. CLAUDE.md는 왜 중요한가요?
코딩 에이전트가 세션마다 자동으로 읽는 유일한 파일이라서입니다. 여기에 하드 규칙(배포 승인, 비밀키 금지), 검증 명령, 반복 실수 교정을 담으면 에이전트 품질이 안정됩니다. 원칙은 '없으면 모델이 틀리는 것만 담기'입니다. 작성법은 플레이북에 템플릿과 함께 정리했습니다.
Q12. 보안·비밀키는 어떻게 관리하나요?
① 비밀키는 커밋되는 어떤 파일에도 넣지 않고 환경변수·로컬 전용 파일로 분리 ② 에이전트에게 '민감정보 저장 금지'를 하드 규칙으로 명시 ③ 외부로 나가는 행동(발행·전송·결제)은 사람 승인 게이트를 강제합니다. 특히 웹에서 가져온 텍스트 안의 지시문을 에이전트가 따르지 않도록 하는 프롬프트 주입 방어가 중요합니다.
Q13. AI로 주식 투자 자동화가 가능한가요?
'분석 자동화'는 가능하고 유용합니다 — 데이터 수집, 지표 계산, 아침 리포트 생성까지. 그러나 매매 결정·주문 실행까지 자동화하는 것은 권하지 않으며, 이 사이트도 다루지 않습니다. '숫자는 코드가, 해석은 AI가, 결정은 사람이'가 안전한 경계입니다. 구성법은 플레이북에 있습니다.
Q14. 로컬 모델(오픈웨이트)은 언제 쓰나요?
① 데이터를 외부로 보낼 수 없을 때 ② 대량 반복 작업이라 API 비용이 부담될 때 ③ 오프라인·저지연이 필요할 때입니다. Ollama나 LM Studio로 시작하면 됩니다. 품질이 중요한 판단 작업은 프론티어 모델, 물량 작업은 로컬·경량 모델로 나누는 하이브리드가 실용적입니다.
Q15. AI 결과물의 품질은 어떻게 관리하나요?
완료의 정의를 AI의 보고가 아니라 게이트에 둡니다: 코드면 빌드·타입체크·테스트, 콘텐츠면 사실 검증·표기 규칙·금지 표현 감사를 자동 실행하고, 통과해야만 '완료'로 승격합니다. 사람 리뷰는 게이트가 못 잡는 것(방향성, 톤)에 집중합니다.
Q16. 어떤 업무부터 AI에게 맡기면 안 되나요?
비가역적이거나 책임이 무거운 결정입니다: 돈이 나가는 실행(결제·매매), 법률·의료·세무의 개인 맞춤 판단, 대외 발행(브랜드 리스크), 개인정보 처리. 이런 지점엔 반드시 사람 게이트를 두고, AI는 그 앞까지(초안·분석·요약)만 담당하게 합니다.
Q17. MCP가 뭔가요?
Model Context Protocol — AI가 외부 도구·데이터(파일, DB, 사내 시스템, SaaS)에 연결되는 표준 프로토콜입니다. 도구마다 제각각이던 연동이 표준화되면서, 에이전트에 '손발'을 붙이는 비용이 크게 내려갔습니다. 에이전트 생태계의 USB 규격이라고 생각하면 쉽습니다.
Q18. 이 사이트의 정보는 얼마나 믿을 수 있나요?
여기 있는 매뉴얼·플레이북은 이론 소개가 아니라 OIYO 패밀리 6개 사이트를 실제로 운영 중인 구성을 옮긴 것입니다. 실패 사례(대량 생성 실패, 배포 한도 소진 등)도 그대로 공개합니다. 다만 AI 서비스 정보는 변화가 빠르므로 각 항목의 확인일자를 함께 보세요.
더 깊이 보기
구성 방법이 궁금하면 플레이북, 운영 체계 전반은 매뉴얼, 실제 아키텍처는 AI-native Systems, 도구 선택은 AI 큐레이터를 보세요.