가리키지 말고 프롬프트를 보내

"Flint 가 프롬프트를 통째로 만들어서 완성된 글을 보내. 브레인한테 뭘 찾아보라고 시키는 법이 없어."

여기서 만들어 완성해서 보낸다

계약 이름이 'apply-free' 인 건 Flint 가 자유롭게 쓴 프롬프트를 그대로 적용시키기 때문이야. 템플릿 채우기를 자기 쪽에서 다 하고, 붙잡아둔 글을 {input} 자리에 넣고, 완성된 프롬프트 한 덩이를 만들어. 그러고 나서야 선을 넘어 부르지. 브레인이 받는 건 채워야 할 틀도, 찾아봐야 할 이름도 아니라 바로 바꿀 수 있는 완성된 글이야. 만드는 건 Flint 일이고, 생각하는 건 브레인 일이니까.

선을 넘는 것

요청이 나르는 건 셋이야. 만들어진 프롬프트, vault 를 쓸지 말지, 그리고 로컬 모델 쪽이면 어느 등급 어느 모델인지. 계약이 그게 전부고. 프롬프트가 내용이고 나머지 둘은 어떻게 돌릴지 알려주는 조건이지. 세션도 없고, 기록도 없고, 딴 데 저장된 뭔가를 가리키는 것도 없어. 부를 때마다 그 요청 하나에 브레인이 답하는 데 필요한 게 전부 들어 있어.

vault 를 쓸지 말지는 선 위에 대놓고 실려. 숨은 기본값이 아니야. 매크로가 개인 vault 맥락을 통째로 붙여 돌지 아예 건너뛸지는 진짜 결과가 걸린 결정이야. 속도도 달라지고 모델이 나에 대해 뭘 아는지도 달라지거든. 그래서 매크로마다 정해서 요청마다 대놓고 실어. 소울이 비어 있다거나 칸이 없다고 그게 조용히 빠른 길이 되면 절대 안 돼. 매번 소리 내어 말하니까 어떤 요청도 의도한 것보다 많거나 적은 맥락을 몰래 보내지 않아.

매크로 번호는 절대 안 보내

요청에서 제일 중요한 칸은 없는 칸이야. 매크로 번호. Flint 는 '저기 저장해둔 7번 매크로 돌려' 라고 절대 안 해. 프롬프트 자체를 보내지. 일부러 그래. Flint 가 브레인 쪽 매크로를 번호로 가리키는 순간 두 시스템이 그 번호로 묶이고, 다음 레슨에서 얘기할 따로 살기가 사라지거든. 남이 쥔 것을 가리키지 말고 내용을 보내.

가리키지 말고 내용을 보내. 필요한 걸 다 담아 보내는 요청은 받는 쪽 사정에서 자유로워. 반대로 받는 쪽이 찾아봐야 할 번호를 부르는 요청은, 저쪽에서 그 번호가 뭘 뜻하든 거기 묶여버리고. 통째로 보낼 여유가 되면 보내. 몇 바이트를 내주고 양쪽을 따로 바꿀 자유를 사는 셈이야.

Code

apply-free 요청 — 완성된 프롬프트, 매크로 번호 없음·swift

struct ApplyFreeRequest: Encodable {
    let prompt: String        // 다 만들어진 글. {input} 은 이미 채워져 있다
    let vaultBypass: Bool     // 선 위에 대놓고. 숨은 기본값이 아니다
    let ollamaTier: String?   // local / server / cloud
    let model: String?
    // 매크로 번호 칸은 일부러 없다. Flint 는 프롬프트를 보내지,
    // 브레인이 저장해둔 뭔가를 가리키지 않는다. 그 없음이 둘을 떼어놓는다.
}

func applyFree(_ req: ApplyFreeRequest) async throws -> String {
    var request = URLRequest(url: brainURL)   // .../utility-macros/apply-free
    request.httpMethod = "POST"
    request.httpBody = try JSONEncoder().encode(req)
    // ... 보내고, 응답에서 바뀐 글을 꺼낸다 ...
}

선 위를 실제로 지나가는 모양·json

{
  "prompt": "Fix the spelling and grammar. Return only the corrected text.\n\nteh qiuck borwn fox",
  "vaultBypass": true,
  "ollamaTier": "local",
  "model": null
}

Exercise

Flint 를 이렇게 만들 수도 있었어. 매크로를 브레인에 저장해두고 긁어놓은 글이랑 '7번 돌려' 만 보내는 방식으로. 그 설계가 만들어낼 얽힘을 나열해보고, 프롬프트를 통째로 보내는 apply-free 방식이 대신 뭘 치르고 뭘 사는지 비교해봐. 그리고 따로: vault 를 쓸지 말지가 왜 소울이 있냐 없냐로 추측하면 안 되고 대놓고 실린 칸이어야 할까?

Hint

'7번 돌려' 방식은 두 살림을 그 번호로 묶어. 브레인 쪽 매크로를 고치면 Flint 동작이 조용히 달라지고, 어느 목록도 상대 없이는 못 움직이지. apply-free 는 부를 때마다 몇 바이트를 더 내고 완전히 따로 살 자유를 사고. vault 쪽이 대놓고 실려야 하는 건, 소울이 비었다고 추측해버리면 지식이랑 속도에 관한 결정이 보이지 않는 부작용이 되기 때문이야. 작성자가 생각한 것과 다른 맥락이 나가버리는 거지.

여기서 만들어 완성해서 보낸다

선을 넘는 것

매크로 번호는 절대 안 보내

Code

External links

Exercise

Progress

댓글 0