안녕하세요, 저는 Rijul이며, 비즈니스 핵심 시스템을 위해 설계된 blast-radius 인식 AI 코드 리뷰 도구인 LiveReview를 개발하고 있습니다. [GitHub 링크]에서 저희 프로젝트에 별점을 주시면 개발자들이 이 프로젝트를 발견하고 사용해 보고, 제품 개선에 도움이 되는 피드백을 공유하는 데 큰 힘이 될 것입니다.

이전 글에서는 Jev의 기본 개념과 세 가지 결정 유형인 Choice, Score, Noul에 대해 탐구했습니다. [링크]

이제 Jev를 더 효과적으로 활용하는 방법을 살펴보겠습니다. 입력으로 받아들이는 종류, 요청을 구조화하는 방법, 여러 질문이 어떻게 평가되는지, 그리고 강제적이거나 오해의 소지가 있는 답변을 피하는 Choice 질문을 설계하는 방법에 대해 다룰 것입니다.

1. State 이해하기

Jev에서 **state(상태)**는 모델이 사용자의 질문을 평가하는 데 사용하는 정보입니다.

State는 세 가지 형식으로 제공될 수 있습니다:

String: 고객 메시지나 사고 보고서와 같은 일반 텍스트.
JSON object: 주문 ID, 고객 상태 또는 오류 메시지와 같은 필드를 포함하는 구조화된 정보.
Array: 결정을 위한 정보를 제공하는 컨텍스트 항목들의 모음.

예를 들어, 고객 지원 애플리케이션은 다음과 같은 state를 제공할 수 있습니다:

{
  "customer_message": "결제가 실패했지만, 두 번 청구되었습니다.",
  "account_status": "active",
...

Jev는 이 정보를 사용하여 고객의 문제, 계정 또는 다음 단계에 대한 질문에 답변할 수 있습니다.

하지만 Jev는 텍스트 기반 모델입니다. 이미지, 오디오, 비디오 또는 기타 바이너리 입력을 state로 직접 받아들이지는 않습니다. 만약 애플리케이션이 이러한 형식들을 받는다면, Jev로 전송하기 전에 관련 정보를 텍스트나 구조화된 데이터로 추출해야 합니다.

2. Request Anatomy 이해하기

A Jev 요청은 세 가지 주요 구성 요소로 이루어집니다:

model: 사용하려는 Jev 모델.
state: 모델이 평가해야 할 정보.
questions: 답변을 원하는 이름 붙여진 질문들의 맵(map).

각 질문은 고유의 식별자(identifier)와 정의를 가집니다. 이 식별자는 애플리케이션이 응답에서 해당 답변을 찾도록 돕습니다.

예시:

{
  "model": "jev-latest",
  "state": {
...

이 예시에서 요청은 동일한 고객 메시지에 대한 두 가지 질문을 포함합니다.

첫 번째는 Choice를 사용하여 이슈 유형을 분류하고, 두 번째는 Noul을 사용하여 후속 조치가 필요한지 평가합니다.

각 질문이 고유의 type과 instructions를 가지고 있다는 점에 주목하세요. Choice는 사용 가능한 옵션을 정의하기 위해 criteria 필드를 사용하고, Score는 순서가 있는 척도를 정의하기 위해 기준(criteria)을 사용하며, Noul은 기준을 요구하지 않고 예/아니오 질문을 평가할 수 있습니다.

이 구조를 통해 모든 질문에 대해 별도의 요청을 보내는 대신 하나의 요청에서 여러 결정을 정의할 수 있습니다.

3. 병렬적이고 독립적인 평가 (Parallel, Independent Evaluation)

Jev는 동일한 요청에서 여러 질문을 평가할 수 있습니다. 하지만 각 질문은 공유된 상태(shared state)를 기준으로 독립적으로 평가됩니다.

이는 한 질문이 다른 질문의 답변을 추가적인 컨텍스트로 받지 못한다는 것을 의미합니다.

고객 지원 티켓을 처리해야 하는 AI 에이전트를 고려해 보세요. 다음과 같은 작업을 수행하도록 요청할 수 있습니다:

이슈 유형 식별하기.
심각도 결정하기.
인간의 개입이 필요한지 판단하기.

세 가지 질문 모두를 하나의 요청으로 할 수 있습니다. 하지만 심각도 질문은 이슈 분류 질문의 답변을 사용할 수 없고, 에스컬레이션(escalation) 질문은 심각도 답변을 검사할 수 없습니다.

각 질문은 원래 상태를 독립적으로 평가합니다.

이것이 중요한 이유 (Why does this matter?)

애플리케이션이 심각도가 높은 임계값에 도달하면 티켓을 에스컬레이션해야 하는 상황을 가정해 봅시다.

Jev에게 이슈 분류와 심각도 점수화를 요청한다고 해서 그 답변들이 자동으로 연결될 것이라고 가정할 수 없습니다. 대신, 애플리케이션이 반환된 값들을 결합하고 에스컬레이션 규칙을 적용해야 합니다.

예를 들어, Score 척도가 2를 심각한 수준으로 정의한다면:

예시 스케일: 0 = 경미(minor), 1 = 보통(moderate), 2 = 심각(severe)

if severity >= 2:
escalate_to_human()

여기서 애플리케이션은 반환된 점수를 사용하여 최종 결정을 내립니다. 스케일이 정의된 레벨 사이의 값을 허용하는 경우, 프로덕션 환경에서 사용하기 전에 대표적인 예시를 통해 임계값(threshold)을 설정하고 테스트해야 합니다.

만약 나중에 제기되는 질문이 이전 답변에 진정으로 의존한다면, 관련 결과를 상태(state)에 포함하여 두 번째 요청을 사용하십시오. 또는 두 번째 모델 평가가 필요하지 않은 경우, 애플리케이션 코드에서 독립적인 답변들을 결합할 수 있습니다.

핵심 원칙은 개별 질문 평가와 그 답변들을 워크플로우로 결합하는 것을 분리하는 것입니다.

4. 더 나은 선택형 질문 설계하기 (Designing Better Choice Questions)

선택(Choice)은 미리 정의된 옵션 세트 중에서 하나의 답변을 선택해야 할 때 유용합니다.

하지만 결과의 품질은 해당 옵션들을 어떻게 정의하느냐에 부분적으로 달려 있습니다.

이 예시를 고려해 보세요:

{
  "type": "choice",
  "instructions": "주요 문제는 무엇인가요?"
...

만약 고객이 배송 지연에 대해 문의한다면 어떻게 될까요?

제공된 옵션 중 어느 것도 그 문제를 포괄하지 못합니다. 적절한 대체(fallback) 옵션이 없다면, 모델은 여전히 사용 가능한 옵션 중 하나를 선택하여 오해의 소지가 있는 분류 결과를 생성할 수 있습니다.

'기타(other)' 또는 '없음(none)' 옵션 포함하기

미리 정의된 선택지들이 모든 가능한 입력을 포괄하지 못할 수도 있으므로, 대체 옵션을 포함하십시오.

예를 들어:

{
  "type": "choice",
  "instructions": "주요 문제는 무엇인가요?"
...

이제 애플리케이션은 예상되는 범주 외의 문제에 대한 옵션을 갖게 되었습니다.

이는 고객 메시지나 기타 입력이 항상 미리 정의된 분류에 깔끔하게 들어맞지 않을 수 있는 실제 데이터를 처리할 때 특히 유용합니다.

옵션들을 명확히 구분하기 (Make the options distinct)

대체 옵션은 좋은 질문 설계의 한 부분일 뿐입니다. 다른 옵션들 역시 명확하게 구별되어야 합니다.

예를 들어, billing과 account 모두 구독 문제를 포함한다면, Jev가 이 둘을 구분하는 데 어려움을 겪을 수 있습니다.

각 옵션이 무엇을 포함하는지 정의하고, 불필요한 중복을 피하세요. 두 옵션이 다른 결과를 나타낸다면, 그 설명에서 차이점을 명확히 해야 합니다.

Choice는 사용자가 제공한 옵션 중에서 선택합니다. 예상치 못한 사례가 발생한다고 해서 목록을 자동으로 확장하지 않습니다.

마무리하며

Jev를 활용하는 것은 Choice, Score, Noul 사이에서 선택하는 것 이상을 포함합니다. 상태(state)를 구조화하고, 각 질문을 명확하게 정의하며, 답변들이 서로 어떻게 관련되는지 이해해야 합니다.

다음 원칙들을 염두에 두세요:

관련 컨텍스트를 문자열(string), JSON 객체 또는 컨텍스트 항목 배열로 제공하세요.
모든 질문에 명확한 지침과 적절한 기준을 제시하세요.
동일한 요청 내의 질문들을 독립적인 평가로 취급하세요.
워크플로우가 여러 결정을 요구하는 경우, 답변들을 애플리케이션에서 조합하세요.
Choice 카테고리가 모든 사례를 포괄하지 못할 수 있을 때 other 또는 none 옵션을 포함하세요.

이러한 기본 사항들이 갖춰지면, 애플리케이션 로직을 통제하면서 Jev 주변에 더 제어된 의사결정 워크플로우를 구축할 수 있습니다. 명확한 지침과 잘 정의된 옵션이 도움이 될 수는 있지만, 올바른 결정을 보장하지는 않습니다. 배포 전에 레이블링된 예시(labelled examples)를 통해 워크플로우를 평가하고, 실제 입력값이 변경됨에 따라 지속적으로 성능을 모니터링해야 합니다.

_
팀의 관심은 제한적이며, AI가 생성한 코드의 홍수는 생산성을 유지하고 보안을 지키는 것을 더욱 어렵게 만들고 있습니다._

_
저는 비즈니스 중요 시스템을 위해 구축된, 폭발 반경(blast-radius) 인식 AI 코드 리뷰 도구인 LiveReview를 개발하고 있습니다.

모든 diff를 동일한 강조점으로 제시하는 대신, LiveReview는 각 변경 사항을 폭발 반경—즉, 호출 그래프(call graph)를 통해 그 영향이 얼마나 멀리 미치는지—으로 점수화하여 실제로 중요한 곳에 주의를 집중할 수 있게 합니다.

비즈니스 위험이 가장 높은 곳에 코드 리뷰 노력을 투입하세요. 모든 diff에 고르게 분산시키지 마세요.

⭐ GitHub에서 별표하기:

GitHub logo HexmosTech / LiveReview

비즈니스 중요 시스템을 위한 폭발 반경 기반 AI 코드 리뷰

LiveReview: 비즈니스 중요 시스템을 위한 위험 인식 AI 코드 리뷰

LiveReview는 **폭발 반경(blast radius)**에 따라 diff의 모든 hunk 점수를 매기는 AI 코드 리뷰어입니다. 폭발 반경이란 변경 사항이 호출 그래프를 통해 얼마나 멀리 도달하는지, 영구 상태(persistent state)를 얼마나 많이 건드리는지, 그리고 테스트가 얼마나 잘 되어 있는지를 의미합니다. 공유 인증 확인 로직에 대한 3줄의 변경이 300줄짜리 UI 수정보다 더 높은 위험 점수를 받을 수 있습니다. 팀의 관심은 모든 diff에 고르게 분산되는 것이 아니라 가장 높은 위험을 가진 코드부터 집중됩니다.

blast-radius-demo.mp4

LiveReview의 폭발 반경 및 리뷰 우선순위 점수는 diff 뷰어에서 실시간으로 확인 가능합니다.