JEV 패턴

모든 JEV 패턴이 공유하는 뼈대

TypeSafe 자신의 문서는 이 Jev 패턴의 구성을 세로줄 하나로 그린다. 구조화되지 않은 상태가 타입이 붙은 질문으로 흐르고, 타입이 붙은 질문이 Jev로 흐르고, Jev가 분포가 달린 choice·score·noul을 돌려주고, 코드 안의 결정적인 조합이 결과를 두 갈래로 나눈다 —— 한쪽은 되돌릴 수 있는 동작, 다른 쪽은 재확인이나 우회 경로.

이 그림에서 가장 중요한 낱말은 「되돌릴 수 있는」이다. 아래의 어떤 Jev 패턴도 Jev의 답이 불러오는 일이 취소되거나, 다시 시도되거나, 위로 올려질 수 있다는 전제에 서 있다. Jev는 빠르고 싸고 잘 보정된 추측기이고, 빠르고 싼 추측기를 둘 자리는 어디인가 —— 가끔 틀려도 견딜 수 있는 판단 앞이지, 견딜 수 없는 판단 뒤가 절대 아니다.

Jev 패턴을 쓸 수 있는 경계를 TypeSafe는 분명히 적어 두었다. Jev가 답해야 할 것은 「이 요청은 알려진 어느 경로인가」「이 문제는 이 기준으로 얼마나 무거운가」「이 메시지는 환불을 요구하는가」「이 인용은 이 주장을 떠받치는가」 같은 것들이다. 「이 계정을 지울까」「이 송금을 실행할까」처럼 영향이 큰 결정의 유일한 결정자로 Jev를 앉혀서는 안 된다.

왜 JEV 패턴이 필요한가

질문 유형이 셋뿐이고 텍스트도 내지 않는 모델이라면 문서 같은 건 필요 없을 것처럼 들린다. 실제로는 반대다. 이 제약이 설계의 일을 통째로 한자리에 밀어 넣는데, 그 한자리가 대부분의 사람이 평소 생각해 본 적 없는 곳 —— 질문 자체의 모양 —— 이기 때문이다.

챗 모델이라면 모호하게 던지고 모델이 알아서 헤아리게 할 수 있다. Jev에서는 못 한다. 선택지마다 이름이 필요하고, 단계마다 설명이 필요하고, 임계값은 프롬프트로 풍기는 게 아니라 직접 정해야 한다. 이걸 잘하는 건 기술이고, 여기 있는 Jev 패턴은 첫 주에 사람들이 되풀이해 틀린 물음에 대한 지금 시점의 답이다.

Jev 패턴이 필요한 두 번째 이유는 조합이다. Jev 질문 하나만으로 재미있어지는 일은 거의 없다. Jev를 들일 값어치를 만드는 것은 같은 상태에 대해 한 요청에서 여섯 개를 묻고, 여섯 확률을 하나의 동작으로 바꾸는 스무 줄짜리 라우팅을 쓰는 쪽이다. Jev 패턴이 주로 말하는 것은 그 뒷부분 —— 즉 Jev가 대신해 주지 않는 부분 —— 이다.

어떤 JEV 패턴을 고를까

내 프로그램이 이미 아는 것에서 출발한다. 갈 곳의 집합이 고정돼 있고 거기서 하나를 골라야 한다면 필요한 건 라우팅형 Jev 패턴이고, 진짜 설계 작업은 그 갈 곳들에 충분히 정밀하고 서로 겹치지 않는 이름을 붙이는 일뿐이다. 대상이 하나 있고 그게 얼마나 나쁜지 알아야 한다면 설명이 달린 단계를 가진 채점형 Jev 패턴. 실행하려는 동작이 있고 그 허가가 필요하다면 Noul로 짠 가드레일형 Jev 패턴.

자기가 어느 쪽인지 가려지지 않는다면, 그 판단이 아직 Jev에게 넘길 만큼 윤곽이 서지 않았다는 뜻인 경우가 대부분이다. 받아들일 수 있는 답을 전부 적어 본다. 그 목록이 열려 있다면 Jev는 틀린 도구이고 텍스트 모델이 맞다. 목록이 닫혀 있다면 방금 Jev 질문 하나를 설계한 것이다.

또 하나 쓸모 있는 체는 양이다. 여기 있는 어떤 Jev 패턴도 그 판단이 충분히 자주 돌 때에만 엔지니어링 투자에 값한다. 하루에 두 번 일어나는 판단은 이미 돈을 내고 있는 모델에 맡겨 두면 된다. Jev의 논리는 첫 번째가 아니라 천 번째 호출 위에 서 있다.

JEV 패턴의 질문 설계

Jev 패턴에서 가장 크게 먹히는 습관은, 선택지에 라벨을 붙이는 대신 설명을 쓰는 것이다. 「버그, 청구, 기타」인 Jev Choice는 하나하나에 한 문장이 붙은 쪽보다 확실히 못하다 —— 「제품 결함, 서비스 중단 또는 연동 실패」「결제, 환불, 청구서, 구독에 관한 것」「위 어디에도 분명히 들어맞지 않음」. 모델이 읽는 건 이쪽 설명이니, 설명이 모호하면 판단도 모호해진다.

Jev 패턴의 두 번째 습관은 Jev에게 빠져나갈 길을 남기는 것이다. 거의 모든 Choice에 「해당 없음」을 분명히 넣어야 한다. 정답이 없는 목록에서 고르라고 밀어붙이면 자신만만한 오답이 돌아올 수밖에 없다. 코드 쪽 확신도 하한과 묶어 두면 모호한 건은 억지로 찍지 않고 알아서 재확인으로 흘러간다.

세 번째는 Jev 질문 하나가 한 가지만 묻게 하는 것이다. 써 놓은 선택지 집합 안에서 두 선택지가 서로 무관한 두 축으로 갈린다는 걸 알아챘다면, 질문이 둘 있는 것이다. 나눈다. Jev는 병렬로 풀기 때문에 나눠도 거의 공짜고, 대개 양쪽 답이 다 좋아진다.

마지막으로, 상태 안에서 진짜 관련 있는 부분을 Jev에게 가리켜 준다. playbook의 예시는 전부 필드를 명시해 참조한다 —— 객체 전체가 아니라 ticket.messages[0].text를 넘긴다 —— 상태가 클 때 이 정밀함이 답을 눈에 띄게 조인다.

JEV 패턴의 임계값은 어디에 두나

코드 안. Jev 패턴의 임계값은 언제나 코드 안이고, 찾을 수 있고 고칠 수 있는 상수로 둔다. 확신도 임계값을 헬퍼 함수 깊숙이 묻어 버리거나, 더 나쁘게는 Jev에게 주는 instructions에 적어 넣으려는 일이 흔한데 둘 다 프로덕션에서 버티지 못한다. 정말 원하는 숫자는 미리 추론해서 나오는 게 아니라 실제 트래픽을 들여다보다 발견되는 것이기 때문이다.

Jev 패턴에서 먹히는 방식은 작고 명시적인 계단이다. 위쪽 임계값보다 높으면 자동 실행. 두 임계값 사이면 실행하되 표시해 두고 표본 검사. 아래쪽 임계값보다 낮으면 실행하지 않는다 —— 사람에게 넘기거나, 애초에 피하려 했던 비싼 모델로 되돌린다.

Jev는 보정을 목표로 훈련됐으므로 이 숫자들에는 의미가 있다. Jev가 0.9라고 하면 대체로 열 번 중 아홉 번은 맞아야 하고, 그러면 남은 1할에 대한 비용 추정이 선다. 찍어 보는 게 아니라. 이 성질이야말로 진짜 상품이고, 속도나 가격보다 무겁다.

몇 번이고 되풀이할 값어치가 있는 주의가 하나 있다. 보정은 많은 호출에 대한 통계적 약속이지 개별 한 번에 대한 보증이 아니다. Jev가 특정 건에서 자신만만하게 틀리는 일은 얼마든지 있고, 설명은 해 주지 않는다. 표본 검사는 첫날부터 붙여 둔다.

먼저 손댈 JEV 패턴

하나만 먼저 구현한다면 가드레일 Jev 패턴을 고른다. 가장 작고, Noul 하나면 되고, 그 자체로는 아무것도 막지 않으며, 중요한 것을 Jev에게 맡기기 전에 실제 트래픽으로 임계값을 보정할 수 있다.

거기서 자연스러운 다음 Jev 패턴은 라우팅이다. 돈이 움직이는 자리가 거기이기 때문으로, 비싼 모델 앞에 Jev 호출 하나를 두고 요청마다 비싼 모델이 얼마나 필요한지를 정한다. 여기서 아끼는 건 싼 업체로 갈아타서 얻는 2할이 아니라, 그 호출을 통째로 안 해서 얻는 9할이다.

이 페이지의 모든 Jev 패턴은 커뮤니티 playbook에서 옮겨 온 것이고, 저마다 페이지에 state와 타입이 붙은 질문과 라우팅 정책이 적혀 있다. 감상하라고 둔 게 아니라 읽고 베끼라고 둔 것이다.