본문 바로가기
C.W.K.
Stream
Lesson 02 of 04 · published

긁어놓은 글이 들어가는 자리

~10 min · input-token, template, rendering, append

Level 0식은 부싯돌
0 XP0/34 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"틀이 곧 동작이야. 만드는 건 {input} 이라고 뚫어둔 구멍에 내 글을 떨구는 것뿐이고."

틀이 곧 동작이야

매크로가 하는 일은 통째로 그 프롬프트 틀이야. 자리 하나 뚫어둔 짧은 지시문. '철자랑 문법 고쳐. 고친 글만 돌려줘.' '한국어로 번역해.' '더 부드러운 말투로 다시 써.' 오타 고치개랑 번역기의 차이가 문자열 하나인 거지. 이 방식의 좋은 점이 거기 있어. 새 변환을 만들려면 새 코드가 아니라 새 지시문을 쓰면 되거든. 매크로가 곧 프롬프트고, 프롬프트는 그냥 글이야.

긁어놓은 글 떨구기

만드는 건 있을 수 있는 제일 단순한 일이야. 틀에서 {input} 을 찾아 붙잡아둔 글로 바꿔치기. 문법 고쳐:\n\n{input} 같은 틀이 지시문 뒤에 내 진짜 글이 붙은 모양이 되는 거지. 해석도, 로직도, 조건도 없어. 구멍 뚫린 글 한 줄이랑 그 구멍에 들어가는 내 글뿐이야. 이걸 이렇게까지 멍청하게 두는 게 매크로를 순수한 지시문으로 남겨줘. 똑똑한 건 전부 아래쪽 머리에 있지, 프롬프트를 조립하는 데 있는 게 아니거든.

틀에 {input} 이 없을 때

어떤 매크로는 긁어놓은 글을 가운데 안 넣어. 입력이 뒤따라오면 되는 상설 지시문이거든. 범용 'Prompt' 매크로가 그래. 틀이 열린 지시문이고, 긁었든 쳤든 그 글이 자리에 들어가는 대신 빈 줄 하나 뒤에 붙어. 그래서 규칙이 두 갈래야. 틀에 {input} 이 있으면 거기 넣고, 없으면 빈 줄 뒤에 붙이고. 둘 다 완성된 프롬프트가 나오고, 틀을 쓰는 사람은 어느 쪽이든 기계 사정을 신경 쓸 필요가 없어.

{input} 있는 틀:
  "문법 고쳐:\n\n{input}"   +  긁은 글="teh cat"
  -> "문법 고쳐:\n\nteh cat"

{input} 없는 틀:
  "다음 글을 요약해."        +  긁은 글="긴 글..."
  -> "다음 글을 요약해.\n\n긴 글..."   (뒤에 붙임)
클라이언트가 만드는 건 멍청하게 둬. 똑똑한 건 한 군데 모아두고. 만드는 쪽을 영리하게 하고 싶어져. 조건문, 도우미, 틀 안의 작은 로직. 참아. 프롬프트를 조립하는 데 로직이 많이 살수록 클라이언트가 조용히 생각을 대신하기 시작하거든. '지시문 더하기 자리' 만 있는 매크로가 갈라짐을 깨끗하게 지켜줘. 클라이언트는 기계적으로 글을 붙이고, 판단은 전부 그걸 읽는 머리 쪽에서 일어나게.

Code

{input} 이 있으면 넣고, 없으면 뒤에 붙인다·swift
func render(_ template: String, input: String) -> String {
    if template.contains("{input}") {
        return template.replacingOccurrences(of: "{input}", with: input)
    }
    // 자리가 없으면 상설 지시문 뒤 빈 줄 다음에 붙인다.
    return input.isEmpty ? template : "\(template)\n\n\(input)"
}

// 예시:
//   render("Translate to Korean:\n\n{input}", input: "hello")
//     -> "Translate to Korean:\n\nhello"
//   render("Summarize the following.", input: "long text")
//     -> "Summarize the following.\n\nlong text"

External links

Exercise

매크로 셋의 틀을 직접 써봐. JSON 정리해주는 것, 영어를 한국어로 옮기는 것, '이거 더 간결하게' 고쳐주는 것. 각각 {input} 자리를 쓸지, 아니면 뒤에 붙는 방식에 기댈지 정하고. 그다음, 만드는 쪽이 왜 '글자가 코드면 감싸줘' 같은 조건 로직을 갖는 대신 멍청한 바꿔치기로 남아야 하는지 따져봐.
Hint
셋 다 명확하게 {input} 을 써도 되고, 간결하게 고치는 건 자리 없이 뒤에 붙이는 방식도 괜찮아. 둘 다 맞아. 만드는 쪽이 멍청하게 남아야 하는 건, 틀이 갈래를 치기 시작하는 순간 클라이언트가 내용을 보고 판단하는 셈이 되기 때문이야. 그건 머리가 할 일이거든. 그 판단은 지시문 안에 넣어서 — '글자가 코드면 감싸줘' — 모델이 정하게 해. 클라이언트는 붙이기만 하고 따지지는 않는 거지.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.