스크립트
00:00:00루프 엔지니어링에 관한 대화는 완전히 방향을 잃었습니다.
00:00:04유튜브와 X의 모든 영상이 똑같은 이야기만 합니다.
00:00:08프롬프트 엔지니어링은 죽었고 루프 엔지니어링만 해야 한다고요.
00:00:12하지만 문제는 이게 완전히 틀렸을 뿐만 아니라, 완전히 거꾸로 되었다는 점입니다.
00:00:17그 이유는 루프도 본질적으로는 프롬프트이기 때문입니다.
00:00:20단지 몇 가지 추가적인 비계를 얹어 계속 반복하는 프롬프트일 뿐이죠.
00:00:25루프도 프롬프트와 마찬가지로 하나의 도구일 뿐입니다.
00:00:29어제 렌치를 발견했다고 해서 드라이버를 버리는 게 아니잖아요.
00:00:34각각 제자리가 있고, 상황에 맞게 사용하는 건 여러분의 몫입니다.
00:00:39그래서 이번 영상에서는 거품을 걷어내고
00:00:42루프 엔지니어링에 대해 무엇을 알아야 하는지, 언제 사용해야 하는지,
00:00:46어떻게 실제로 구축하는지, 어떤 사례에 적합한지 설명해 드리겠습니다.
00:00:49루프 엔지니어링의 정의부터 시작하죠.
00:00:52루프 엔지니어링이란 CloudCode, Codex 등
00:00:55어떤 에이전트 디코더를 사용하든 작업 하나를 던져주고,
00:00:58그냥 프롬프트를 주고 끝내는 게 아니라, 특정 방식으로 설정해서
00:01:03루프를 통해 반복적으로, 계속해서 다시 시도하게 만들어
00:01:09정의된 성공 기준에 도달할 때까지 작업을 완료하게 하는 개념입니다.
00:01:15작업이 성공했다는 걸 어떻게 판단할지 알려주는 거죠.
00:01:18루프 엔지니어링은 효율적이고 효과적이면서 타당한 방식으로
00:01:24루프를 설정하는 것입니다.
00:01:25그게 다예요.
00:01:26핵심은 무엇일까요?
00:01:28프롬프트입니다.
00:01:29프롬프트 위에 프롬프트를 쌓아서 작업을 완료할 때까지
00:01:33반복하는 겁니다.
00:01:34그러니 프롬프트 엔지니어링이 죽었다는 건 완전히 잘못된 말입니다. 그 핵심에는
00:01:39수많은 프롬프트가 쌓여 있으니까요.
00:01:41그게 다입니다.
00:01:42나머지 영상은 이런 작업을 완료하기 위해 타당한 방식으로
00:01:47루프를 어떻게 설정하는지에 대한 내용입니다.
00:01:49또한 어떤 작업이 실제로 루프로 접근하는 게 적절한지도 알아볼 거고요.
00:01:56당연히 항상 그렇게 할 필요는 없으니까요.
00:02:00이것도 '프롬프트 엔지니어링은 죽었다'는 말에 대한 반박이죠.
00:02:03이건 만능 도구가 아닙니다.
00:02:04모든 것에 루프를 만들 필요는 없지만, 때로는 필요하죠.
00:02:07알아두면 좋은 겁니다.
00:02:08모든 루프에는 4단계가 있습니다.
00:02:09트리거 단계, 실행 단계, 검증 단계, 그리고 다음 루프로 넘어가기 전 상태(state) 관리입니다.
00:02:14그 과정을 반복하는 거죠.
00:02:161단계는 트리거인데, 꽤 명확합니다.
00:02:19어떻게 작업을 시작하게 할 것인가?
00:02:21여러 방법이 있습니다.
00:02:22Clawd Code 내에서 일정이나 루틴을 예약할 수 있습니다.
00:02:26크론 작업이나 웹훅 등 무엇이든 좋습니다.
00:02:28별로 상관없어요.
00:02:29어떻게든 시작할 방법만 있으면 됩니다.
00:02:31자동으로 돌아가는 걸 원하니까요.
00:02:352단계는 실행 단계입니다.
00:02:37AI가 우리를 위해 무언가를 실제로 수행하는 단계인데, 대개 코딩 관련 작업이죠.
00:02:41어쨌든 일종의 스킬(skill)을 사용하는 편이 좋을 겁니다.
00:02:45스킬은 Clawd Code에게 특정 결과를 얻기 위해 구체적인 일을 수행하도록
00:02:51지시하는 데 완벽하니까요.
00:02:53루프의 목적 자체가 특정 결과를 내는 것이며, 이는 3단계인
00:02:59목표이자 검증 단계로 이어집니다.
00:03:02사실 이 부분은 성공 기준에 관한 것입니다.
00:03:08성공 기준.
00:03:09성공 기준이 무슨 뜻일까요?
00:03:11작업 완료를 어떻게 판단할까요?
00:03:14이는 진지하게 고민해봐야 할 문제인데, 사람들은 얘기하면서도
00:03:18이해가 안 되는 예시만 듭니다.
00:03:19알겠죠?
00:03:19성공 기준에 대해 말할 때 때로는 매우 명확할 수 있습니다.
00:03:23파이썬 애플리케이션의 실행 속도를 높이는 것이 목표라면
00:03:30성공 기준은 아주 자명합니다.
00:03:33그건 실행 시간이죠.
00:03:34알겠죠?
00:03:34실행 시간을 줄이려고 반복적으로 시도하는 루프를 만들 수 있습니다.
00:03:38객관적인 성공 기준이 있는 명확한 목표죠.
00:03:43하지만 항상 그런 건 아닙니다.
00:03:45만약 콘텐츠 제작과 관련해서 LinkedIn 기사를 쓰려는
00:03:49루프라면 어떨까요?
00:03:51알겠죠?
00:03:51루프의 일부분은 지속적으로 웹에서 AI 관련 정보를 찾아서
00:03:57LinkedIn 기사로 바꾸고 시간이 지나면서 루프를 통해 더 좋은 기사를 쓰는 것입니다.
00:04:03그럼 어떻게 더 좋은 LinkedIn 기사를 만들죠?
00:04:07아시나요?
00:04:08여기서 성공이란 뭘까요?
00:04:09참여도일까요?
00:04:10참여도가 기사의 질과 항상 완벽하게 일치할까요?
00:04:16매우 모호하죠.
00:04:18따라서 모호한 성공 기준을 가진 루프를 만들 수도 있지만, 그럴 경우 효과가 떨어진다는 점을 이해해야 합니다.
00:04:24그런 상황에 대해 더 얘기해보겠습니다.
00:04:25개선해야 할 숫자가 명확하지 않은 모호한 목표가 있을 때
00:04:31무엇을 할 수 있을지 더 이야기해 봅시다.
00:04:35입니다.
00:04:364단계는 무엇일까요?
00:04:37상태(state)입니다.
00:04:38루프 엔지니어링의 진짜 가치는 우리가 출력과 메모리를 통해
00:04:45매 루프마다 스스로 개선하고 시간이 지날수록 매 실행마다 개선할 수 있다는 점입니다.
00:04:51스스로 더 발전하게 만드는 거죠.
00:04:53파이썬 아이디어를 다시 생각해 보세요.
00:04:57실행 시간을 줄이고 싶다는 파이썬 아이디어 말이죠.
00:05:01더 빠르게 만들고 싶습니다.
00:05:03각 루프가 사일로(격리된 상태)에 갇혀 매번 다른 시도만 한다면 루프가 무슨 소용일까요?
00:05:08아니죠.
00:05:08이전 실행 시간을 확인할 수 있는 문서나 데이터베이스가 필요합니다.
00:05:15그게 이전 런타임입니다.
00:05:16여기에 런타임을 줄이려고 시도했던 것들이 있죠.
00:05:19뭐가 효과가 있었는지.
00:05:20뭐가 효과가 없었는지.
00:05:21이제 뭘 시도해야 할지 알게 됩니다.
00:05:23RALF 루프 개념과 매우 비슷하게 들릴 겁니다.
00:05:27많은 루프 엔지니어링이 이런 RALF 루프 개념에 기반하거든요.
00:05:33그래서 제대로 된 루프에는 출력이 무엇인지 알 방법이 필요합니다.
00:05:38기록할 수 있어야 하죠.
00:05:40이어지는 루프를 위해 실행 단계에서 무엇을 했는지 확인하고 볼 수 있어야 합니다.
00:05:46무엇을 했는지.
00:05:47무엇이 통했는지.
00:05:48무엇이 안 통했는지, 그렇죠?
00:05:49그게 스스로 개선하게 만드는 유일한 방법입니다.
00:05:52마지막으로, 단계는 아니지만 일부인 부분은
00:05:56중단 기준이 무엇인가입니다.
00:05:58언제 루프를 멈출 것인가?
00:06:01어떤 경우에는 목표에 도달했을 때가 되겠죠.
00:06:03검증되었습니다.
00:06:04그럼 끝난 거죠.
00:06:05하지만 그런 일이 일어날 때까지 계속, 계속, 계속
00:06:08돌아가길 원하시나요?
00:06:11아마 아닐 겁니다. AI는 공짜가 아니니까요.
00:06:15진전이 없는 경우처럼 어떤 방식으로든 강제 중단을 내장해야 할까요?
00:06:18발전이 없을 때 말이죠.
00:06:19파이썬 런타임이 충분히 줄어들지 않는다거나 하는 경우요.
00:06:24또는 8번 반복하고 끝내겠다는 식의 강제 중단이 있을 수 있습니다.
00:06:28이런 것들을 생각해봐야 합니다.
00:06:33루프 엔지니어링은 이론적 관점에서는 비교적 간단하지만,
00:06:37단계와 루프 자체를 엔지니어링하는 세부적인 부분으로 들어가면
00:06:41분명히 미묘한 차이가 있고 답해야 할 질문들이 있습니다.
00:06:47한꺼번에 받아들이긴 벅찰 수 있습니다.
00:06:48혼란스러울 수도 있고요.
00:06:51그래서 이 영상에서 한 가지만 얻어간다면,
00:06:52정말 생각해야 할 것은 바로 성공 기준입니다.
00:06:57그것이 성공 기준이죠.
00:06:58이것은 이 작업이 실제로 루프 형식에 적합한지 판단하는 데도 영향을 미칩니다.
00:07:05루프 형식으로 만드는 게 맞을까요?
00:07:07가지고 계신 작업이 매우 명확한 성공 기준을 가지고 있다면, 특히 숫자처럼
00:07:14객관적이라면 루프가 최고입니다.
00:07:17루프 엔지니어링은 멋진 거죠.
00:07:18그렇지 않다면, 모호하다면, LinkedIn 기사 예시를 떠올려 보세요.
00:07:23글쎄요, 그래도 말이 될 수도 있습니다.
00:07:26그 부분에 사람을 더 개입시켜야 할 수도 있습니다.
00:07:30어떤 식으로든 하이브리드 접근 방식이 필요할 수도 있지만, 시작할 때
00:07:33염두에 두어야 합니다. 명확한 목표와 성공 기준이 없다면
00:07:36이 모든 건 무의미하고 그냥 헛수고하며
00:07:39토큰만 낭비하게 될 겁니다.
00:07:40시작하기 전에 꼭 아셔야 합니다.
00:07:42다른 건 몰라도 성공 기준, 꼭 고민해 보세요.
00:07:46이제 여러분만의 루프와 개인적인 루프 엔지니어링을 설정하는 방법으로 넘어가기 전에
00:07:50오늘의 후원사인 저에 대해 짧게 말씀드리면,
00:07:54방금 Claude Code 마스터클래스를 출시했는데, 완전 초보에서 AI 개발자가 되기에 완벽한 곳입니다.
00:07:59특히 기술적 배경이 없으신 분들께 좋습니다.
00:08:02매주 업데이트하고 있으며 Codex 마스터클래스와 Agentic
00:08:07OS 마스터클래스도 포함되어 있습니다.
00:08:09Chase AI Plus에서 찾을 수 있고 고정 댓글에 링크가 있습니다.
00:08:13자, 개인적인 루프 엔지니어링 워크플로우로 들어가기 전에,
00:08:17Auto Research와 슬래시 목표(/goals)에 대해 짧게 이야기해보고 싶습니다.
00:08:21지금까지 내용을 듣고 '그냥 카파시(Carpathy)의 Auto Research를 쓰면 되지 않나?'
00:08:23라고 생각하실 수도 있으니까요.
00:08:26왜 Claude Code의 일부인 슬래시 목표를 그냥 쓰지 않을까요?
00:08:28물론, Auto Research는 여전히 훌륭합니다.
00:08:30우리가 루프 엔지니어링에 대해 말한 많은 부분이 Auto Research가
00:08:35자동으로 하는 것과 비슷하거든요.
00:08:36문제는 Auto Research가 명확하게 정의된 성공 기준이 필요하다는 점입니다.
00:08:41말씀드렸던 것처럼요.
00:08:42모호한 것은 처리할 수 없죠.
00:08:46우리는 다소 모호한 성공 기준을 가지고도 Claude Code 내에서 루프 엔지니어링을 할 수 있습니다.
00:08:50Auto Research는 그렇지 않죠.
00:08:52아까 파이썬 예시처럼 런타임을 빠르게 하려는 경우에는
00:08:55완벽한 사례입니다.
00:08:57하지만 그게 아니라, 우리가 개선하려는 객관적인 숫자 같은 것이
00:09:01아니라면요?
00:09:02Auto Research로는 처리하기 어렵습니다.
00:09:04그리고 슬래시 목표 같은 경우, 슬래시 목표는 일종의 루프
00:09:09엔지니어링의 요약본입니다.
00:09:10Claude Code에게 특정 일을 하고 싶다고 말하는 것이죠.
00:09:13특정 조건에 도달할 때까지 계속해서 반복하라고 하는 것입니다.
00:09:17슬래시 목표와 넓은 의미의 루프 엔지니어링의 차이는, 슬래시 목표는
00:09:21Codex도 마찬가지지만, 단일 세션 내에서만 작동한다는 점입니다.
00:09:26이 한 가지 일을 완료하고 끝내는 거죠.
00:09:29루프 엔지니어링은 무한한 수평선을 가진 느낌입니다.
00:09:32항상 슬래시 목표를 루프로 돌리는 것과 거의 같습니다.
00:09:36슬래시 목표를 반복하는 거죠.
00:09:38자기 개선 측면이 있습니다.
00:09:39다시 LinkedIn 기사 예시를 떠올려 보세요.
00:09:42앞으로 영원히 더 좋은 LinkedIn 기사를 만들어달라고 하는
00:09:47슬래시 목표는 실행할 수 없습니다.
00:09:48지금 한 번, 사일로 안에서 하나를 만들어달라고 할 수는 있겠죠.
00:09:54하지만 매주 반복해서 하고 싶은 거라면 슬래시 목표로는 할 수 없습니다.
00:09:58그런 용도가 아니니까요.
00:09:59루프 엔지니어링은 더 큰 그림을 보는 것입니다.
00:10:02여기서 조금 더 이야기해보죠.
00:10:04이제 루프 엔지니어링에 관한 여러분의 여정이 어떠해야 할지 이야기해 봅시다.
00:10:08어떻게 접근해야 할까요?
00:10:10어떤 작업을 염두에 두고 있고 루프 엔지니어링을 하고 싶다면요?
00:10:15따라야 할 영웅의 여정 같은 것이 있습니다.
00:10:19이 여정의 첫 단계는 순전히 수동 과정입니다.
00:10:23LinkedIn 기사 예시를 다시 들어보죠.
00:10:25LinkedIn 기사를 만들고 싶습니다.
00:10:27그럼 뭘 해야 할까요?
00:10:28Claude Code를 켜고 AI 정보를 연구해서 나를 위해 LinkedIn 기사를 써달라고 할 것입니다.
00:10:35작성해 줘.
00:10:37농담하는 게 아닙니다.
00:10:39이게 정말 첫 단계가 되어야 해요.
00:10:40왜냐고요?
00:10:41우리가 하려는 게 과연 가능한지, AI가 할 수 있는지 확인해야 하니까요.
00:10:45알겠죠?
00:10:46그게 1단계입니다.
00:10:48직접 수동으로 하면서 이게 가능한지 확실히 검증하는 거죠.
00:10:52이게 실제로 가능하다는 걸 확인했고 앞으로 개선하고 싶다면,
00:10:55이제 코드로 구현할 차례입니다.
00:10:582단계는 스킬로 만드는 겁니다. 아무도 앉아서 “A, B, C를 계속 해줘”라고 매번 말하고 싶진 않을 테니까요.
00:11:04원하는 결과물이 있고, 특정 방식으로 하고 싶거든요.
00:11:06그래서 이걸 스킬로 만드는 겁니다.
00:11:10그게 바로 2단계죠.
00:11:14그게 2단계입니다.
00:11:15그리고 안타깝게도 많은 사람이 여기서 멈춰 있어요.
00:11:18대부분 1단계인 수동 작업에만 계속 머물러 있거든요.
00:11:21프로세스를 검증했으면,
00:11:23이제 스킬로 체계화한 겁니다.
00:11:25그다음은 그냥 자동화하면 됩니다.
00:11:28귀찮으니까 스킬을 자동화하고 싶은 거죠.
00:11:30심지어 LinkedIn 아티클 명령어 입력조차 하고 싶지 않거든요.
00:11:33그냥 알아서 실행되길 바라죠.
00:11:34이런 건 Cloud Code 같은 곳에서 꽤 쉽게 할 수 있습니다.
00:11:37루틴(Routines)으로 들어가서,
00:11:39LinkedIn 아티클이라는 자동화를 설정하면 됩니다.
00:11:42그리고 지침에 그냥 LinkedIn 아티클 스킬을 실행하라고 하면 되죠, 맞죠?
00:11:48설명을 실행하고, 스킬을 실행하는 거죠.
00:11:51트리거도 이미 정해져 있고요.
00:11:52원하는 대로 일정을 잡으면 됩니다.
00:11:54매일 오전 9시에 실행하게 하는 식이죠.
00:11:56이렇게 루프 엔지니어링에 본격적으로 들어가기도 전에 이미 트리거와 실행의 일부를 해결한 겁니다.
00:12:01이제 이 자동화된 스킬을 진짜 루프 엔지니어링 구조로 발전시키려면,
00:12:06어떻게 해야 할까요?
00:12:11이제는 자기 개선에 대해 생각해야 합니다.
00:12:14성공 기준에 대해서도 고민해야 하고요.
00:12:17그리고 상태(state)에 대해서도 생각해야 합니다.
00:12:19정확히 무엇이 성공인지 말이죠.
00:12:22성공의 정의가 무엇인가?
00:12:24어떻게 기록하고 개선해 나갈 것인가?
00:12:273단계에 접어들면 이제 이 후반부 전체를 고려해야 합니다.
00:12:32스킬은 잘 작동하겠지만, 4단계로 넘어가기 전에 몇 가지를 추가해야 합니다.
00:12:37무엇을 더해야 할까요?
00:12:40앞서 말한 성공 기준을 추가해야 합니다.
00:12:42그리고 일종의 상태 로깅(state logging)도 필요하죠.
00:12:46다시 한번 말하지만, 상태 로깅입니다.
00:12:53제가 무슨 말을 하는 걸까요?
00:12:54정보가 어디로 가느냐는 거죠.
00:12:55링크드인에 게시하는 건 쉽죠.
00:12:57물론 링크드인에 게시할 수는 있겠지만, 참여 통계를 스크랩할 수 있나요?
00:13:01성공의 정의를 참여 통계라고 한다면 말이죠.
00:13:05좋아요(likes) 수라고 칩시다.
00:13:06그 좋아요 수를 가져와서 지표가 어떤지 확인한 다음, 어딘가에 저장해야 합니다.
00:13:11그래야 개선할 수 있으니까요.
00:13:12그 데이터를 통해 무엇이 효과적이었는지, 무엇이 아니었는지 알아낼 수 있습니다.
00:13:17어떤 아티클이 성공했는지,
00:13:18어떤 게 안 됐는지,
00:13:19이 후크(hook)는 좋았는지,
00:13:20이 후크는 나빴는지,
00:13:20이 행동 유도(CTA)는 효과가 있었는지 등을요.
00:13:23처음 1, 2, 3단계에서는 그런 게 없었지만, 4단계인 루프 엔지니어링으로 넘어가려면,
00:13:27꼭 필요한 과정입니다.
00:13:31이 두 가지가 필요하죠.
00:13:32이건 무엇을 하든 똑같이 적용됩니다.
00:13:36자, 그럼 이제 4단계가 꼭 필요한가 싶은 의문이 들 수 있습니다.
00:13:40어떤 식으로든 성공을 정의할 수 있고, 다소 모호하더라도 상태를 기록할 방법만 있다면,
00:13:44그걸로 충분합니다.
00:13:47성공 기준에 대해 조금 더 얘기해 보죠. 여기에는 5단계의 검증 계층이 있는 것 같거든요.
00:13:51첫 3단계가 우리가 주로 머물러야 할 곳입니다.
00:13:54성공 기준이 매우 명확한 경우죠.
00:13:56이상적으로는 결정론적이어야 합니다.
00:14:00예/아니오로 답할 수 있으면 완벽하죠.
00:14:01또는 일종의 규칙이나 제약 조건이 있는 경우도 좋고요.
00:14:04파이썬 애플리케이션 실행 속도가 빨라야 한다는 건 개선하려는 규칙이나 제약 조건 같은 거니까요.
00:14:06만약 그런 기준이 없다면,
00:14:103~5단계로 가게 되는데, 여기서는,
00:14:12기준이 다소 모호해집니다. 이럴 때 성공을 어떻게 판단할지 고민해야 하죠.
00:14:15좋아요나 참여도처럼 수치가 있다면 3단계에 해당합니다.
00:14:20만약 그걸로 만족한다면 계속 완전 자동화를 유지하면 됩니다.
00:14:24하지만 미묘한 판단이 필요한 경우라면,
00:14:26자기 자신이나 Cloud Code와 상의해야 할 수도 있습니다.
00:14:29예를 들어, 대형 언어 모델(LLM)을 심판으로 세우는 거죠.
00:14:33Cloud Code가 아티클을 작성하는데, 그 글을 다시 Cloud Code가 판단하게 할까요?
00:14:38아마 좋은 생각은 아닐 겁니다.
00:14:44루프 안에 Codex 같은 걸 도입해서 검토하게 만드는 방법이 있습니다.
00:14:51관련해서 이미 영상을 만든 적이 있는데요.
00:14:52Codex를 사용해 Cloud Code의 결과물을 판단하게 하는 거죠.
00:14:56Cloud Code나 다른 모든 AI 시스템은
00:14:57기본적으로 자기가 만든 결과물을 아주 좋아하거든요.
00:15:01그래서 루프 안에서 AI가 무언가를 판단하게 할 때는,
00:15:01왜냐하면 클라우드 코드나 모든 AI 시스템의 공통적인 문제점은
00:15:05자신의 결과물을 너무 좋아한다는 것입니다.
00:15:07그러니 AI에게 루프 속 무언가를 판단하게 할 때는,
00:15:11주의해야 합니다. 특히 주관적인 경우라면 더욱요.
00:15:14또 다른 선택지는 여러분을 루프에 포함시키는 것입니다.
00:15:18그럼 자동화 수준은 낮아지겠죠.
00:15:19이 지점에서 과연 이게 루프가 필요한가라는 의문이 들 수 있습니다.
00:15:23하지만 충분히 의미가 있을 수 있습니다.
00:15:24사람의 개입이 꼭 필요한 시나리오들이 있거든요.
00:15:28사실 이게 가장 강력할 때도 있죠, 맞죠?
00:15:31특히 링크드인 게시물 같은 예시에서, 그게 좋은 글이었을까요?
00:15:34내가 다룬 주제에 비해서 반응이 적절했나?
00:15:37게시물 품질과는 아무 상관 없이 반응이 폭발할 수도 있잖아요.
00:15:40그저 타이밍이나 주제가 좋았던 것뿐이죠.
00:15:41그럼 우리가 작성 방식을 골든 스탠다드로 삼고 싶을까요?
00:15:44말씀드린 것처럼, 우리가 쓴 게시물 정보를 앞으로의 기준으로 삼을까요?
00:15:49역시나 많은 미묘한 판단이 필요합니다.
00:15:51정말 많은 고려가 필요하죠.
00:15:53미묘한 차이가 존재합니다.
00:15:54이런 결정들을 여러분이 직접 내려야 합니다.
00:15:56루프가 제대로 설계되었는지 결정짓는 건 바로 이런 부분들이죠.
00:16:00여기에도 완벽한 정답은 없습니다.
00:16:02모두 케이스 바이 케이스입니다.
00:16:03여러분 스스로 실험을 거쳐서 찾아내야 하는 부분이죠.
00:16:07하지만 지금 이 예시에서는 '좋아요'를 기준으로 삼겠습니다.
00:16:11우리에겐 충분하니까요.
00:16:11좋아요가 많으면 좋은 게시물이라고 간주하는 거죠.
00:16:14이것을 기초 데이터로 삼겠습니다.
00:16:15그럼 우리의 루프를 다시 보면, 오전 9시 트리거가 있고 기술(Skill)을 통해 실행하며,
00:16:20목표는 최대한 많은 '좋아요'를 받는 것으로 정의했습니다.
00:16:27스크래퍼로 이를 검증하고, 게시물과 좋아요 수를 데이터베이스에 기록할 수 있죠.
00:16:33이렇게 되면 사실상 매일 오전 9시에 루프가 돌아가게 됩니다.
00:16:40그런데 여러분도 바로 몇 가지 문제를 발견하셨을 겁니다.
00:16:44이게 단순한 단일 루프가 아닐 거라는 점을요.
00:16:49단 하나의 루프만으론 부족할 겁니다.
00:16:52게시물을 작성하는 시점과 좋아요가 쌓이는 시점 사이에 시간차가 있기 때문이죠.
00:16:58시간차가 발생하니까요.
00:16:59그래서 실제 작동하는 데에도 지연 시간이 생기게 됩니다.
00:17:02기다리면서 게시물과 좋아요 데이터가 담긴 실제 데이터베이스를 구축해야 할 겁니다.
00:17:08데이터를 쌓아야 하니까요.
00:17:09아니면 한 달 정도 이 루프를 돌려서 이미 데이터가 충분히 쌓였다고 가정해 봅시다.
00:17:14작성한 게시물과 좋아요 수의 데이터 보물 창고가 있는 셈이죠.
00:17:18그러면 매일 오전 9시 트리거가 작동하고, 기술(Skill)이 실행되어 AI 소식을 찾고 게시물을 쓰기 시작할 겁니다.
00:17:25그런데 그때 가져오는 정보는 단순히 AI 뉴스뿐만이 아니겠죠?
00:17:30이제 데이터베이스의 지난 게시물과 좋아요를 분석해서,
00:17:35요즘 트렌드가 무엇인지, 우리가 어떤 후킹을 시도했는지 등을 살펴볼 겁니다.
00:17:40어떤 CTA가 효과적이었는지 분석해서 가져오는 거죠.
00:17:43그 내용이 실행 과정에 통합됩니다.
00:17:45그게 바로 자기 개선 과정이 되는 겁니다.
00:17:48그런 정보들을 가져와서 기술(Skill) 안에 녹여내는 거죠.
00:17:52자기 개선의 일부입니다.
00:17:53결과물을 확인하고 좋아요 수를 기록합니다.
00:17:55실제로는 24시간마다 좋아요 수를 긁어와서 업데이트하는 루프가 따로 돌아야 합니다.
00:17:59그래야 데이터가 갱신되니까요.
00:18:01계속 돌아가는 거죠.
00:18:02보시다시피 '좋아요'라는 기준은 루프 설계의 복잡도를 증가시킵니다.
00:18:06단순한 파이썬 앱 속도 개선 작업과는 차원이 다르죠.
00:18:11그건 10분마다 실행해서 앱 속도를 체크하면 되지만,
00:18:15이건 코드 변경 사항과 시간을 담은 문서를 활용해 계속해서 실험하는 거니까요.
00:18:21반복적인 개선이 핵심이죠.
00:18:23어떤 변경이 속도를 낮추는지 확인하면서 최적의 방식을 찾는 겁니다.
00:18:29결론적으로, 성공 기준이 명확하면 루프 설계는 훨씬 쉬워집니다.
00:18:33지금 제가 드린 말씀이 여러분을 완전히 혼란스럽게 했을지도 모르겠네요.
00:18:40하지만 링크드인의 이런 모호한 상황을 짚어드리는 게 중요하다고 생각했습니다.
00:18:45실제로 많은 분이 이 지점에 계시거든요.
00:18:46모든 게 자동 연구처럼 딱 떨어지지는 않으니까요.
00:18:51그게 바로 루프 엔지니어링의 핵심입니다.
00:18:56트리거가 있고,
00:18:57기술(Skill)을 통해 실행하며,
00:19:01하지만 이런 링크드인식 혼란스럽고 모호한 이야기를 해보는 것도 좋을 것 같았어요.
00:19:07그리고 모든 과정을 기록해서 자기 개선 루프로 만드는 겁니다.
00:19:11실행 단계에서 지난 상태를 확인하며 시도했던 것들을 돌아보는 것이 중요합니다.
00:19:15무엇이 효과가 있었고 무엇이 실패했는지 알아야 하니까요.
00:19:20이번 이야기는 여기까지 하겠습니다.
00:19:23영상 재미있게 보셨나요?
00:19:24정말 흥미로운 주제라고 생각합니다.
00:19:26프롬프트 엔지니어링이 죽었다는 말에 휘둘리지 마세요.
00:19:29전혀 사실이 아니니까요.
00:19:34제 클라우드 코드 마스터클래스를 배우고 싶으시다면 'Chase AI Plus'를 꼭 확인해 보세요.
00:19:40그럼 다음에 또 뵙겠습니다.
00:19:44오늘도 시청해 주셔서 감사합니다.
00:19:45다들 건강하세요.
00:19:46성공적인 루프를 만드시길 바랍니다.
00:19:47질문 있으시면 언제든 남겨주세요.
00:19:48좋아요와 구독도 부탁드립니다.
00:19:51이게 정말 복잡해 보일 수 있습니다.
00:19:55하지만 연습하면 충분히 가능합니다.
00:19:56저와 함께 해보시죠.
00:19:58제 Cloud Code 마스터클래스를 확인하고 싶으시다면 Chase AI Plus를 확인해 보세요.
00:20:02행복한 하루 보내세요.
00:20:02안녕히 계세요.