자동화 썸네일형 리스트형 자동화가 사람 개입 후 멈추는 문제: 중복 없이 다시 태우는 재개 경로 설계법 문제 제기: 사람이 고쳐도 자동화로 돌아갈 길이 없다여러 단계를 이어 붙인 자동화(글 생성 → 품질 검사 → 이미지 생성 → 발행 대기)를 운영하다 보면, 중간 단계에서 멈추는 작업이 생길 수 있습니다. 품질 검사에 걸린 글이 대표적입니다. 이때 사람이 문장을 손봐서 검사를 통과시키는 것까지는 어렵지 않습니다. 진짜 문제는 그다음입니다.실제 개발 기록에서 확인한 상황은 이랬습니다. 검사에 걸리면 자동으로 이어지는 작업 흐름은 돈이 드는 이미지 생성 단계를 건너뜁니다. 그런데 사람이 원고를 고쳐 검사를 통과시켜도, 한 번 건너뛴 그 단계가 저절로 되살아나지 않았습니다. 결국 사람이 이미지를 손으로 만들어 다시 올렸고, 그 재업로드 과정에서 블로그에 중복 초안이 실제로 생겼습니다.핵심 원인은 기능 부족이 아.. 더보기 EP.33 자동화 자동으로 이어지는 작업 흐름 재개 경로 만들기: 사람이 고친 글을 중복 없이 다시 태우기 (EP.자동화) 이번 회차의 문제: 사람이 고쳐도 돌아갈 길이 없었다글을 자동으로 만들어 올리는 프로그램을 쓰다 보면, 품질 검사에 걸려 중간에 멈추는 글이 생깁니다. 이럴 때 사람이 문장을 손봐서 검사를 통과시키는 것까지는 됩니다. 문제는 그다음이었습니다.검사에 걸리면 프로그램은 돈이 드는 이미지 만들기를 건너뜁니다. 그런데 사람이 문장을 고쳐 통과시켜도, 한 번 건너뛴 그 단계가 저절로 되살아나지 않았습니다. 돌아갈 길이 없으니 사람이 직접 이미지를 손으로 만들어 다시 올렸고, 그 과정에서 블로그에 중복 초안이 생겼습니다.이번 회차에서는 사람이 고친 글을 명령어 한 줄로 다시 태우는 재개 경로를 만들었습니다. 빠진 부분만 채우고 발행 대기 상태로 되돌리는 길입니다.무엇을 확인했나: 멈춘 뒤 벌어진 일들기존 흐름에서 .. 더보기 AI API를 자동화에 연결하는 기본 구조는 어떻게 될까? 한 줄 결론AI API를 자동화에 연결하는 기본 구조는 '사용자가 입력하면 → 프로그램이 인증된 요청을 보내고 → AI가 응답하면 → 그 응답을 검증·저장·전달하는' 흐름입니다. 복잡해 보이지만 큰 그림은 이 네 단계뿐이며, 여기에 오류·비용·보안 점검을 더하면 자동화를 좀 더 안정적으로 운영하는 데 도움이 됩니다.이 글에서는 용어 구분부터 순서대로 정리하겠습니다. 코드를 외우게 하려는 것이 아니라, '무엇이 어디로 오가는지'라는 지도를 먼저 그려 주는 데 목적이 있습니다.먼저 용어부터 구분하기: 모델, 서비스, 개발 도구, API구조를 이해하기 전에 자주 섞여 쓰이는 네 가지 단어를 구분하면 이후 설명이 훨씬 쉬워집니다.AI 모델: 학습을 통해 만들어진 '두뇌' 자체입니다. 글을 생성하거나 이미지를 분.. 더보기 API란 무엇인가? 일반 AI 서비스와 API의 차이 쉽게 정리 한 줄 결론API는 사람이 아니라 '프로그램'이 AI에게 요청을 보내고 결과를 받아오는 창구입니다. 일반 AI 서비스는 우리가 웹사이트나 앱 화면에서 직접 글을 입력하고 답을 눈으로 보는 방식이고, API는 다른 프로그램이 정해진 규칙에 따라 자동으로 요청을 보내 결과를 받아 처리하는 방식입니다. 쉽게 말해 하나는 '사람이 손으로 쓰는 창구', 다른 하나는 '프로그램이 자동으로 쓰는 창구'라고 보면 됩니다.먼저 네 가지 개념부터 구분해요AI를 처음 공부할 때 함께 등장해 서로 섞이기 쉬운 단어가 모델, 서비스, 개발 도구, API입니다. 이 네 가지는 서로 다른 층에 있는 개념이에요. 하나씩 쉬운 말로 풀어봅니다.1) AI 모델모델은 실제로 답을 만들어내는 '두뇌' 부분입니다. 방대한 데이터를 학습해서 .. 더보기 여러 채널을 함께 운영할 때, 합쳐야 할 것과 끝까지 분리해야 할 것 문제: 채널을 늘리면 소재 리서치가 병목이 된다블로그를 자동화로 굴리다가 쇼츠 채널을 추가하려 할 때 가장 먼저 마주치는 벽은 편집이 아니라 매일의 소재 리서치다. 채널이 하나 늘 때마다 '오늘 무엇을 다룰까'를 처음부터 다시 찾아야 하면, 채널 수에 비례해 번아웃이 커진다.실제 개발에서 이 문제를 만났을 때 상황은 이랬다. 블로그 에이전트(ai-blog-agent)는 이미 각 저장소의 DEVLOG와 커밋을 긁어와 글감으로 만드는 harvest 파이프라인을 갖고 있었다. 즉 소재를 길어 올리는 '우물'은 이미 파여 있었다. 쇼츠에도 같은 우물을 쓰게 하면 추가 리서치 비용이 0에 수렴한다는 발상이 여기서 나왔다.여기서 중요한 결정이 갈린다. 두 채널이 우물을 공유한다면 어디까지 공유하고 어디부터 분리할 .. 더보기 AI 티 안 나는 글은 문체가 아니라 소재 관리에서 나온다 문제: 문체를 아무리 다듬어도 AI 티가 남는 이유AI로 글을 자동 생성하면 가장 먼저 손대게 되는 것이 문체다. 어미를 바꾸고, 접속사를 줄이고, '~합니다'를 '~한다'로 통일한다. 그런데 이렇게 표면을 다듬어도 여러 글을 나란히 놓고 보면 여전히 인공적인 느낌이 남는다. 원인은 문장이 아니라 소재에 있다.일반 AI 주제 생성에 의존하면 글은 '한국 주식 자동화의 5가지 장점' 같은 어디서 본 듯한 일반론으로 수렴한다. 실제로 어느 레포에서, 어떤 기록을 근거로 나온 이야기인지 추적할 수 있는 출처가 없다. 사람이 쓴 글과 갈리는 지점은 바로 이 검증 가능한 구체성인데, 주제부터 추상적이면 문체를 어떻게 손봐도 채울 재료가 없다.실제 개발 파이프라인(EP.19)에서 내린 결론도 같았다. AI 티를 줄.. 더보기 새 자동화 기능은 실제 장부와 분리한 관찰 모드부터 돌려라 문제 제기: 새 기능을 실제 장부에 바로 붙이면 생기는 일새로운 자동화 전략이나 규칙이 떠오르면 곧바로 실제 시스템에 연결하고 싶어진다. 하지만 성격이 다른 가설을 기존 전략에 그대로 섞으면, 결과가 좋아도 나빠도 어느 규칙이 원인이었는지 분리할 수 없다.실제 개발에서 개장 급등주를 노리는 공격적 단타 가설을 별도 장부(Shadow Open)로 격리해 검증한 적이 있다. 기존 포지션 장부에 바로 섞었다면 손익과 실패 원인을 구분하지 못했을 것이다. 이 글은 그 경험에서 얻은 '관찰 모드 먼저' 원칙을 일반적인 자동화 작업에 적용할 수 있게 정리한 것이다.왜 위험한가: 원인 분리 불가와 되돌리기 어려움손익·실패 원인의 오염: 새 규칙과 기존 규칙의 결과가 한 장부에 섞이면, 성과의 원인을 특정 규칙에 귀속.. 더보기 여러 시스템을 다듬다 공통 매니저를 만든 이유 문제 제기: 하나가 잘 돌면 나머지도 잘 돌 줄 알았다시스템을 하나 잘 만들어 놓으면, 비슷한 대상에 그대로 붙이면 될 것 같습니다. 실제 개발 기록에서도 한국 주식으로 만든 기본 시스템에 코인과 미국 주식을 이어 붙이는 방식으로 확장했습니다.하지만 다듬는 과정에서 문제가 반복됐습니다. 한국 주식은 멀쩡한데 미국 주식에서만 문제가 생기는 일이 계속 나온 것입니다. 원인은 단순했습니다. 세 대상이 서로 다른 환경인데, 처음부터 끝까지 한국 주식 기준으로만 생각했기 때문입니다.왜 위험한가: 같은 수정이 환경마다 다르게 작동한다이 개발 기록에서 문제가 됐던 지점은, 한 곳(한국 주식)의 기준으로 검증한 사고방식을 나머지 환경에도 그대로 적용한 것이었습니다.거래 시간, 통화 단위, 데이터 형식, 규칙이 환경마다.. 더보기 이전 1 2 다음
