절대 안 닿는 두 목록

"양쪽 다 '매크로' 라는 게 있어. 그 같은 이름이 함정이지, 합칠 이유가 아니라."

닮아 보이는 두 목록

Flint 는 매크로 목록을 자기 파일에 갖고 있어. 이름, 프롬프트 틀, 단축키, vault 를 쓸지 말지. 빌린 브레인도 자기 화면들을 위한 동작 목록을 따로 갖고 있고. 둘이 같은 물건처럼 보이는데, 바로 그 닮은 데가 얽힘이 슬쩍 끼어들려는 자리야. '둘 다 매크로 목록인데 왜 같이 안 써? 아니면 맞춰두든가, 아니면 한쪽이 번호로 부르든가.' 답은, 둘이 주인이 다르고 같이 만지는 순간 다시 만든 게 무의미해진다는 거야.

다시 만들면서 없앤 그 얽힘

옛 도구는 클라이언트 동작이랑 서버 동작이 한 덩어리로 엉켜 있었어. 하나를 바꾸면 다른 쪽을 따져봐야 했고. 그걸 떼어놓는 게 다시 만들기의 목표였지 우연이 아니야. 그래서 Flint 목록이랑 브레인 목록은 설계부터 딴 살림이야. Flint 는 자기 프롬프트를 만들어 보내고(지난 레슨의 apply-free 계약이 이걸 가능하게 해줘), 브레인 쪽 매크로를 번호로 절대 안 불러. 두 목록이 각자 알아서 늘고 줄고 바뀔 수 있는 거지.

FLINT 의 목록 (이 컴퓨터)      브레인의 목록 (자기 것)
----------------------        -------------------------
주인은 Flint                   주인은 브레인
자유 프롬프트로 만들어 보냄     브레인 자기 화면들이 씀
마음대로 바뀜                  마음대로 바뀜
         \                              /
          \___ 번호를 절대 안 나눔 ____/
              맞춰두지도 않음
              번호로 부르지도 않음

어느 쪽도 상대를 안 쥐어

따로 산다는 건 어느 쪽으로도 지시가 안 간다는 뜻이야. Flint 가 브레인 매크로를 관리하지 않고, 브레인이 Flint 한테 매크로를 밀어넣지도 않아. Flint 매크로를 고쳐도 브레인은 그대로고, 브레인 목록을 갈아엎어도 Flint 는 알지도 못하고. 그게 이득 전부야. 두 사람이, 또는 두 시점의 나 자신이, 서로 밟을 게 없으니까 각자 목록을 마음대로 손볼 수 있어.

닮은 둘이 주인이 다르면, 좀 겹치더라도 따로 둬. 닮은 건 뭐든 하나로 합치고 싶어지는 본능이 있어. '같은 거 두 번 쓰지 마' 하는 반사 말이야. 근데 그 둘의 주인이 시스템에서 서로 다른 부분이면 그 본능이 틀려. 합치면 아낀 중복보다 훨씬 오래 사는 얽힘이 생기거든. 생김새가 같다고 주인이 같은 건 아니야. 뭘 합칠지는 생김새가 아니라 주인이 정하는 거야.

이 얽힘을 없애는 게 다시 만든 이유였어. 옛 도구의 클라이언트-서버 뒤엉킴이 바로 Flint 의 따로 살기가 고치려는 병이야. 그러니 나중에 누가 '중복 피하게 Flint 가 브레인 매크로를 갖다 쓰게 하자' 고 꼬시면, 그게 병이 돌아오는 거라고 알아보고 거절해. 중복은 싸. 얽힘이 이미 값을 치르고 없앤 비싼 물건이고.

Code

Flint 의 목록은 이 컴퓨터에, 자기 것으로·swift

// Flint 는 자기 매크로를 자기 파일에 저장한다. 브레인은 여기 안 쓰고,
// Flint 도 브레인 목록을 안 읽는다.
struct MacroStore {
    private(set) var macros: [FlintMacro]

    func save() throws {
        let data = try JSONEncoder().encode(macros)
        try data.write(to: localMacrosFile)   // Flint 자기 폴더
    }
    // sync() 도 없고, fetchFromBrain() 도 없고, 같이 쓰는 번호도 없다.
    // 따로 사는 걸 이 '없음' 으로 지킨다.
}

Exercise

동료가 이렇게 제안해. 'Flint 도 브레인도 매크로를 저장하니까, 하나로 합쳐서 둘 다 거기서 읽자. 중복 없애게.' 그 제안이 다시 불러올 얽힘을 짚어서 반박해봐. 그다음, 닮았다는 이유로 같이 써도 되는 것 하나(코드)랑 절대 같이 쓰면 안 되는 것(주인)을 갈라서 설명해봐.

Hint

하나로 합친 목록은 두 시스템을 도로 묶어. 한쪽 매크로를 고치면 다른 쪽 동작이 조용히 달라지고, 어느 쪽도 혼자 못 움직이지. 다시 만들면서 없앤 그 뒤엉킴 그대로야. 닮았다는 이유로 같이 쓸 수 있는 건 데이터 타입이나 프롬프트 만드는 코드처럼 주인이 없는 것들이고. 양쪽이 같이 고치는 목록 자체는 절대 안 돼. 따로 살기가 막으려던 그 지시 관계가 다시 생기니까.

닮아 보이는 두 목록

다시 만들면서 없앤 그 얽힘

어느 쪽도 상대를 안 쥐어

Code

External links

Exercise

Progress

댓글 0