본문 바로가기

전체 글

AI 모델이란 무엇인가? ChatGPT·Claude·Gemini 쉽게 이해하기 한 줄 결론AI 모델은 '입력을 받아 결과를 만들어내는 학습된 두뇌'이고, ChatGPT·Claude·Gemini는 그 두뇌를 우리가 쉽게 쓰도록 감싼 '서비스'입니다. 처음 AI를 접하면 이 둘이 같은 말처럼 느껴지지만, 사실 모델(두뇌)과 서비스(그 두뇌를 담은 앱)는 구분해서 생각해야 혼란이 사라집니다. 이 글에서는 모델·서비스·개발 도구·API 네 가지를 차근차근 나눠 설명하겠습니다.핵심 개념: 모델, 서비스, 개발 도구, API 구분하기AI 모델AI 모델은 대량의 데이터를 학습해서, 새로운 입력이 들어오면 그에 맞는 결과를 생성하는 '학습된 계산 덩어리'입니다. 쉽게 말하면 요리를 아주 많이 연습해 몸에 익힌 요리사의 실력 자체에 해당합니다. 정확히 표현하면, AI 모델은 입력 데이터를 바탕으로.. 더보기
스캘핑 전략을 시작하기 전에: 비용·데이터·레이턴시부터 계산하는 법 왜 스캘핑은 '아이디어'부터 시작하면 실패하는가스캘핑처럼 하루에 수십~수백 번 진입하는 고회전 전략은 보통 '어떤 신호로 진입할까'부터 고민한다. 하지만 실제로 KR·US·코인 4개 시장의 스캘핑 연구 계획을 검토하면서 확인한 결론은 반대였다. 전략 아이디어보다 비용·데이터·실행 레이턴시가 먼저 전략의 생사를 결정한다.이유는 단순하다. 회전이 빨라질수록 한 번의 왕복에서 발생하는 수수료·슬리피지가 기대 수익을 잠식하고, 검증에 필요한 데이터가 애초에 존재하지 않으며, 신호가 맞아도 실행 지연 때문에 그 가격에 못 들어간다. 이 세 가지 전제조건이 충족되지 않으면 백테스트 성적이 아무리 좋아도 실거래 성과와 검증 신뢰도가 크게 훼손될 수 있다.이 글은 특정 전략의 매매법이 아니라, 고회전 전략을 시작하기 .. 더보기
자동화에 판단을 맡길 때 '긴급도'와 '실행 권한'을 반드시 분리해야 하는 이유 문제: '급하다'와 '자동으로 고쳐라'를 한 덩어리로 묶는 실수AI에게 "알아서 판단하고 조치하라"고 맡기고 싶은 순간이 온다. 개선 아이디어를 수집하고, 우선순위를 매기고, 급한 건 알려주고, 나아가 스스로 고치게 하는 자가발전 루프다. 이때 가장 흔한 설계 실수는 '긴급도 판단'과 '자동 실행 권한'을 하나의 결정으로 묶는 것이다."이 문제는 A등급(가장 급함)이다" → "그러니 바로 자동 수정한다"로 이어지는 흐름이 대표적이다. 언뜻 합리적으로 보인다. 급한 문제니까 빨리 고치는 게 맞지 않나? 하지만 급하다는 것과 AI가 손대도 안전하다는 것은 전혀 다른 질문이다. 급한 결제 로직 오류는 급하면서도 절대 AI가 자동으로 건드려서는 안 되는 코드다.실제 개발 기록(개선 루프 1단계, improvem.. 더보기
여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것 문제: 채널을 늘리면 소재 리서치가 병목이 된다블로그를 자동화로 굴리다가 쇼츠 채널을 추가하려 할 때 가장 먼저 마주치는 벽은 편집이 아니라 매일의 소재 리서치다. 채널이 하나 늘 때마다 '오늘 무엇을 다룰까'를 처음부터 다시 찾아야 하면, 채널 수에 비례해 번아웃이 커진다.실제 개발에서 이 문제를 만났을 때 상황은 이랬다. 블로그 에이전트(ai-blog-agent)는 이미 각 저장소의 DEVLOG와 커밋을 긁어와 글감으로 만드는 harvest 파이프라인을 갖고 있었다. 즉 소재를 길어 올리는 '우물'은 이미 파여 있었다. 쇼츠에도 같은 우물을 쓰게 하면 추가 리서치 비용이 0에 수렴한다는 발상이 여기서 나왔다.여기서 중요한 결정이 갈린다. 두 채널이 우물을 공유한다면 어디까지 공유하고 어디부터 분리할 .. 더보기
AI가 검사자 역할을 할 때 절대 시키면 안 되는 네 가지 문제: 검사자가 작가로 변하는 순간AI로 글을 만드는 흔한 구조는 두 단계다. 한 모델이 초안을 쓰고, 다른 모델이 그 초안을 검사한다. 필자가 운영하는 콘텐츠 파이프라인도 이 형태다. 초안은 한 모델이 쓰고 검사는 다른 모델이 맡는, 초안자 ≠ 검사자라는 규칙을 지킨다.이 구조에서 가장 흔히 예상되는 실패는 검사자가 조용히 작가로 변하는 것이다. "이 문장이 어색하니 이렇게 고치는 게 낫다"며 통째로 다시 써서 돌려주는 경우다. 얼핏 친절해 보이지만 이건 검사가 아니라 재작성이다. 검사자가 재작성을 하면 그 결과물은 아무도 검사하지 않은 새 글이 되어버린다. 검사 단계 자체가 무력화된다.이 글은 필자가 docs/content-generation-contract.md라는 문서에 명문화한 "검사자가 절대 .. 더보기
AI 티 안 나는 글은 문체가 아니라 소재 관리에서 나온다 문제: 문체를 아무리 다듬어도 AI 티가 남는 이유AI로 글을 자동 생성하면 가장 먼저 손대게 되는 것이 문체다. 어미를 바꾸고, 접속사를 줄이고, '~합니다'를 '~한다'로 통일한다. 그런데 이렇게 표면을 다듬어도 여러 글을 나란히 놓고 보면 여전히 인공적인 느낌이 남는다. 원인은 문장이 아니라 소재에 있다.일반 AI 주제 생성에 의존하면 글은 '한국 주식 자동화의 5가지 장점' 같은 어디서 본 듯한 일반론으로 수렴한다. 실제로 어느 레포에서, 어떤 기록을 근거로 나온 이야기인지 추적할 수 있는 출처가 없다. 사람이 쓴 글과 갈리는 지점은 바로 이 검증 가능한 구체성인데, 주제부터 추상적이면 문체를 어떻게 손봐도 채울 재료가 없다.실제 개발 파이프라인(EP.19)에서 내린 결론도 같았다. AI 티를 줄.. 더보기
여러 시스템에 흩어진 같은 문제를 빠짐없이 닫는 법 문제 제기: '고쳤다'는 완료가 아니다여러 시스템이 같은 뼈대를 공유하면, 하나에서 발견한 문제는 대개 다른 곳에도 있다. 실제 개발 기록에서는 KR·US·코인 세 시장의 자동매매 시스템에서 같은 종류의 운영 위험이 여러 레포에 공통으로 흩어져 있었다. 원장 불일치, 시세 조회 실패 처리, 계정 동기화, 승인 인가 같은 문제들이 시장별로 다른 레포에 나뉘어 있었다.이때 흔한 착각은 "코드를 고쳤으니 끝났다"는 것이다. 하지만 멀티레포 환경에서 안전 수정은 발견 → 수정 → 배포 → 관찰이라는 사슬 전체가 이어져야 실제로 닫힌다. 커밋 하나가 머지됐다는 사실은 그 사슬의 두 번째 고리일 뿐이다. 세 번째, 네 번째 고리가 빠지면 문제는 조용히 남아 있다.왜 위험한가: 빠지는 시장이 생길 수 있다레포가 하나.. 더보기
AI에게 규칙을 지시서로 맡길 때와 훅으로 강제해야 할 때 문제: AI가 규칙을 '읽었다'고 지킨 게 아니다AI 코딩 에이전트에게 "push 전에는 반드시 검토해"라고 문서로 적어두면, 대부분의 경우 잘 지킨다. 그런데 '대부분'이 문제다. 컨텍스트가 길어지거나, 급한 작업이 끼거나, 프롬프트가 살짝 달라지면 같은 규칙도 건너뛴다. 문서는 부탁이지 강제가 아니기 때문이다.필자는 여러 레포를 한 AI 에이전트로 관리하면서 이 경계를 마주했다. 전 시스템 공통 규칙 체계를 만들고, 그 첫 규칙 RULE-001(push 전 필수 검토)을 '문서로 부탁할지, 훅으로 막을지' 판단해야 했다. 결론부터 말하면 두 방식은 서로 다른 층위이며, 섞어 쓰되 역할을 나눠야 한다.왜 문서만으로는 위험한가문서 기반 규칙의 약점은 두 가지다. 첫째, 확률적이다. LLM은 지시를 따를 .. 더보기
반응형

티스토리툴바