이런 말이 있습니다: 가진 것이 망치뿐이라면 모든 것이 못처럼 보인다는 것입니다. 소프트웨어를 구축하는 데 LLM 에이전트(LLM agent)만을 사용해 왔다면, 토큰(tokens)은 많은 소프트웨어 문제에 대한 간단하고 쉬운 해결책이 될 수 있습니다. 하지만 그것이 항상 해당 작업에 가장 좋거나 효율적인 도구는 아닐 수도 있습니다. 그것이 잘못되었다는 뜻은 아닙니다. 이 포스트의 목표는 여러분의 도구 상자에 여러분이 예상하는 것보다 더 멀리 닿을 수 있는 또 다른 도구를 제공하는 것입니다. 마지막에는 제가 저녁을 요리하는 동안 Claude가 만들어 준, 실행하는 데 단 하나의 토큰도 들지 않는 신경망(neural network)에 대해 이야기하겠습니다.

좋습니다, 그럼 LLM과 AI 에이전트(AI Agents) 이전의 코딩에 대해 생각해 봅시다. 그것은 무엇이었나요? 그저 컴퓨터가 정확히 따를 수 있도록 지침을 작성하는 것이었습니다. 거의 자동화(automation)에 가까웠죠. 데이터를 지속시키고, 이동시키고, 장비와 기계를 자동화하는 것 말입니다. 이를 위해 사용된 단어는 "결정론적(deterministic)"이었습니다. 즉, 동일한 입력이 주어지면 (대부분의 경우) 항상 동일한 출력을 내놓는다는 의미입니다. 따라서 무언가를 수행하기 위해 스크립트를 작성하고 싶다면, 동일한 데이터가 주어졌을 때 동일한 결과를 생성해야 했습니다. 취약할 수는 있었지만, 여전히 놀라운 일이었습니다. 제가 이전에 사용했던 간단한 예시는 다음과 같습니다:

여러분이 계산기 앱이고 두 숫자를 더하는 기능이 필요하다고 가정해 봅시다. a와 b를 받아서 a + b를 반환하는 add()라는 함수가 있을 수 있습니다. 여러분은 add(1,2)를 연속으로 백만 번 호출할 수 있으며, 그것은 항상 정확히 3을 반환할 것입니다. 매번 말이죠. 이것이 결정론적(deterministic)인 것입니다.

이제 현재로 빠르게 넘어가 봅시다. 우리에게는 LLM과 AI 에이전트(AI Agents)가 있습니다. 이것들은 코딩의 결정론적(deterministic)인 측면을 완전히 뒤집어 놓습니다. LLM에 프롬프트(prompt)를 주면, 매번 동일한 결과를 얻을 것이라는 보장이 전혀 없습니다. 멋지고 흥미로운 점은, "1과 2를 더하고 그 결과를 알려줘"라는 프롬프트로 LLM에 백만 번 호출을 할 수 있다는 것입니다. 응답이 매번 완전히 동일할 것이라고 얼마나 확신하시나요? 아마 대부분의 경우, 혹은 매번 3의 변형된 형태를 줄 것입니다. 하지만 그냥 숫자만 줄까요? "물론이죠! 제가 할 수 있습니다!"와 같은 추가적인 문구는 어떨까요?

그 숫자들을 합쳐서 "합계는 3입니다"라고 말하거나, 그냥 "3"만 반환할 수도 있습니다 (아마 그럴 가능성은 낮습니다. LLM은 너무 장황하니까요). 그리고 여러분은 프롬프트를 만들 때 "출력값만 반환하세요" 또는 "간결하게 작성하세요"와 같은 문구를 추가해 본 적이 얼마나 많으신가요? 그리고 그것이 어느 정도 효과가 있었을 것입니다. 하지만 오직 가끔만 그랬을 뿐이죠. 이 점은 이미 충분히 강조되어 왔지만, 부디 이것이 명확해지기를 바랍니다: LLM은 비결정론적 (non-deterministic)입니다.

그리고 한 가지 짚고 넘어가자면, 비결정론적 (non-determinism)인 것이 나쁜 것은 아닙니다! 사실, 그 반대입니다! 그것이 바로 LLM과 AI 에이전트(AI agents)를 마법처럼 만드는 요소입니다. 오타가 있거나, 문법이 틀리거나, 모호한 용어를 사용한 프롬프트를 입력하더라도, 여러분의 의도가 전달되어 원하는 결과를 얻을 가능성이 높습니다. 결정론적 (deterministic) 코드에서는 보통 그런 일이 일어나지 않습니다. 하지만 이 둘 사이에는 공생 관계가 존재합니다. 음과 양과 같죠. 서로를 아주 잘 보완합니다.

그리고 이것이 바로 이 포스트의 핵심입니다. 그 관계를 여러분의 주의를 끌어 설명하는 것이죠. 저의 가설은 이렇습니다 (완전히 틀릴 수도 있지만, 어쨌든 이 글을 쓰는 것이 매우 즐겁습니다): 코딩에 입문한 지 얼마 되지 않았고 바이브 코딩 (vibe coding)을 통해 코딩을 접한 사람들은 아마도 코딩의 LLM 측면, 즉 비결정론적 (non-deterministic)인 측면만을 경험했을 가능성이 큽니다. 만약 이 말이 공감된다면, 저는 여러분에게 코딩의 결정론적 (deterministic)인 측면을 알려주고 이 둘이 어떻게 서로를 보완하는지 보여드리고 싶습니다.

말로만 하지 말고 보여줍시다

좋습니다, 제가 너무 모호하게 말했으니 좀 더 구체적으로 예시를 들어보겠습니다. 일반적인 유스케이스 (use case)를 보여드리고 결정론적 (deterministic) 접근 방식과 비결정론적 (non-deterministic) 접근 방식을 모두 제시하겠습니다. 여러분이 '던전 크롤러 칼 (Dungeon Crawler Carl)' 도서 시리즈에 매우 관심이 있다고 가정해 봅시다 (저는 그 시리즈를 정말 좋아합니다... 음, 오디오북을요. 전부 다 들어버렸거든요 :D). 그리고 다음 책이 언제 나오는지에 대한 새로운 정보가 있을 때 그 과정을 자동화하고 싶다고 해봅시다.

비결정론적 (non-deterministic) 방식
여러분의 첫 번째 본능은 이 방식으로 가는 것일 수 있습니다. 그 방식이란 무엇일까요?

LLM이 매일 웹사이트를 웹 검색(web search)하게 하여 변경 사항이 있는지 알려주도록 하는 방식입니다. 이는 완전히 유효한 접근 방식이며 몇 가지 실질적인 이점이 있습니다.

• 웹사이트가 변경되더라도 매번 작동합니다.
• 매우 맞춤화된 응답을 얻을 수 있으며, 발생한 모든 변경 사항을 요약할 수 있습니다.

하지만 단점은 무엇일까요?

• 매번 토큰을 소모합니다 (상당히 비용이 많이 듭니다).
• 다소 느릴 수 있습니다 (하지만 솔직히 그렇게 나쁘지는 않을 것입니다).

결정론적 (deterministic) 방식
그렇다면 다른 접근 방식은 무엇이 있을까요? 웹사이트에서 업데이트가 있는 특정 'Dungeon Crawler Carl' 페이지를 스크래핑(scrape)하여 변경 사항이 있는지 확인하는 스크립트를 작성할 수 있습니다. 즉, 이전 텍스트와 오늘의 텍스트를 비교하는 것입니다. 만약 다르다면 알림을 보내 사용자가 페이지를 읽을 수 있게 합니다. (또는 그냥 새로운 텍스트를 보내줄 수도 있습니다. 이 방식은 여러 가지로 구현할 수 있지만, 제 의도는 전달되었을 것입니다).

이 방식의 단점부터 시작하겠습니다:

• 취약할(brittle) 수 있습니다. 사이트 구조가 바뀌면 어떻게 될까요? 텍스트는 업데이트되었지만 실제 유의미한 정보가 없다면 어떻게 될까요?
• 직접 실행되도록 설정해야 합니다 (크론 잡(cron job)이든, 직접 작성한 서비스든 상관없이).

그렇다면 장점은 무엇일까요:

• 가장 큰 장점은 토큰이 들지 않는다는 것입니다 -> 단 하나의 토큰도 쓰지 않고 반복해서 실행할 수 있는 정적인 코드 조각입니다.

도구를 만드는 데 한 번만 토큰을 쓰고, 그 이후에는 추가 비용 없이 영원히 실행하는 것입니다. 이것이 이 포스트 전체의 주제입니다. 정말 놀라운 일이죠. (시간이든, 노력이든, 혹은 토큰이든) 초기에 비용을 투자하여 (LLM을 사용하여!) 결정론적인 코드를 구축한 다음, 이를 평생 무료로 실행하는 것입니다. 그게 전부입니다. 제가 말하고자 하는 핵심은 이것입니다. 이것이 단순하고 당연해 보일 수도 있지만, 코딩이 처음이거나 에이전트(agent)를 사용하여 코딩하는 분들에게는 무언가 깨달음을 주는 계기가 되기를 바랍니다. 여러분의 구독 서비스 토큰을 사용하여, 토큰을 낭비하지 않고도 반복해서 실행할 수 있는 코드를 만들 수 있습니다.

그리고 이 점은 앞으로 더욱 중요해질 것입니다. 제 직감으로는 토큰이 항상 지금처럼 보조금(subsidized)을 받는 형태는 아닐 것 같습니다. 우리는 이미 변화를 목격하고 있습니다. 6월 15일부터 Claude Agent SDK를 통해 실행하는 모든 것은 일반적인 플랜 제한이 아닌 별도의 월간 크레딧에서 차감됩니다. 이는 실행할 때마다 LLM을 호출하는 앱은 해당 크레딧을 소모하는 반면, 결정론적 스크립트 (deterministic script)는 그렇지 않다는 것을 의미합니다. 장기적으로는 결정론적인 방식이 더 저렴하고, 빠르고, 효율적일 가능성이 높습니다. 그냥 참고만 하세요.

그리고 한 가지 덧붙이자면, 결정론적인 경로가 모든 소프트웨어 문제에 작동하는 것은 아닙니다. 작동하지 않는 경우가 아주 많습니다. 그 점을 분명히 말씀드립니다. 핵심은, LLM이 여러분을 위해 결정론적 소프트웨어 (deterministic software)를 작성하는 데 놀라울 정도로 뛰어나다는 것입니다.

심지어 그 이상입니다! 과거에 저는 머신러닝 (machine learning)과 신경망 (neural networks)에 꽤 관심이 많았습니다. 사진에 스폰지밥이 포함되어 있는지 여부를 판단하는 유치한 코드를 작성한 적이 있습니다. 그 코드는 엉망이었고, 비효율적이었으며, 작성하는 데 몇 주가 걸렸습니다. 어젯밤에 실험을 하나 해봤는데, 모든 학습 이미지가 구글 드라이브에 있었기 때문에 Claude Code를 사용했고, 제가 저녁을 요리하는 동안 Claude Code는 훨씬 더 뛰어나고 꽤 정확한 신경망을 구축할 수 있었습니다. 제 요점이 무엇일까요? 이것은 "Claude Code가 웹 스크래핑을 위한 스크립트를 작성해 줄 수 있다"는 수준보다 훨씬 더 깊은 이야기입니다. 그것은 단지 기초적인 예시였을 뿐입니다. 핵심은 Claude Code가 여러분을 위해 신경망 (NEURAL NETWORKS)을 작성할 수 있다는 것입니다. 이는 수년간의 훈련과 교육을 받은 사람만이 접근할 수 있는 영역이며, 실행할 때 토큰 비용이 들지 않습니다. 구축할 때 한 번만 토큰을 사용하면, 그 이후로는 영원히 무료로 사용할 수 있습니다.

사람들이 관심이 있다면, 스폰지밥 신경망 (SpongeBob Neural Network)에 대해 더 깊이 파고들어 보겠습니다. 또는 저의 다른 작업물들을 보고 싶다면 vibeblog.net을 확인해 보세요.

즐거운 목요일 보내시고, 계속해서 바이브를 유지하세요 (keep on vibin')!
submitted by /u/thelocalnative
[link] [comments]