Engineering

같은 장애를 두 번 겪지 않기 위해, 배포 전에 리뷰합니다 — KRIS 개발기

2026년 8월 31일

들어가며

지난 글 LLM as a Judge를 활용한 CodeBuddy 성능 평가에서는 사내 AI 코드 리뷰 서비스 코드버디(CodeBuddy)의 응답 품질을 어떻게 측정할 것인지를 다뤘습니다. 평가 체계를 세우고 나니 다음 질문이 따라왔습니다.

"그래서 이 리뷰가 실제로 무엇을 막아주고 있는가?"

코드버디는 PR을 요약하고(describe), 리뷰하고(review), 개선안을 제안합니다(improve). 정확도는 꾸준히 올라갔습니다. 그런데 리뷰 결과를 오래 들여다볼수록 한 가지가 계속 걸렸습니다. 리뷰는 코드가 올바른가 를 봅니다. 하지만 저희가 정말 알고 싶었던 건 이 변경이 과거에 장애를 냈던 그 변경과 닮았는가였습니다.

AI 리뷰 도입 자체가 더 이상 혁신이 아니라 기본이 된 시점에서, 목표를 다시 잡았습니다. "응답을 잘한다"가 아니라 "배포 전 리스크를 줄인다."

그렇게 만든 것이 배포 리스크 감지 에이전트 KRIS(Kakao Risk Inspection Service, 케이리스) 입니다. 이 글에서는 왜 이런 도구가 필요했는지, 어떤 구조로 위험을 판정하는지, 그리고 정책을 만들면서 마주친 가장 어려운 문제가 무엇이었는지를 이야기해보려 합니다.

1. 장애는 왜 늘 배포 후에 발견될까

게이트는 이미 충분히 많습니다

소프트웨어가 배포되기까지 거치는 관문은 적지 않습니다. 코드 리뷰가 있고, 정적 분석이 있고, 테스트가 있고, QA가 있고, 최근에는 AI 리뷰까지 붙었습니다. 그런데도 장애는 납니다.

기존 게이트들에는 공통점이 하나 있습니다. 전부 "일반적으로 올바른 코드인가"를 기준으로 판단한다는 것입니다. 정적 분석은 문법과 컨벤션을, 보안 스캐너는 취약점을, 코드 리뷰는 설계와 가독성을 봅니다. 모두 필요한 검사입니다.

다만 어느 도구도 "이 조직에서 이 패턴이 과거에 장애를 일으킨 적이 있는가"는 묻지 않습니다. 그 정보를 갖고 있지 않기 때문입니다.

장애 데이터는 왜 다음 배포에 쓰이지 않는가

장애가 나면 저희는 장애일지를 씁니다. 현상, 영향, 원인, 타임라인, 재발 방지 대책 등이 기록됩니다.

그런데 그 문서의 역할은 대부분 회고에서 끝납니다. 작성되고, 공유되고, 승인되고, 아카이브됩니다.

여섯 달 뒤 다른 팀의 개발자가 거의 같은 구조의 변경을 올릴 때, 그 장애일지는 어디에서도 참고되지 않습니다. 같은 팀에서도 담당자가 바뀌면 잊힙니다.

사내 장애를 원인 유형별로 분류해봤을 때, 사람의 실수(Human Fault)에서 비롯된 장애가 과반을 차지했습니다. 그중 소스코드 오류가 약 40%, 설정값(파라미터) 오류가 약 20%였습니다.

이 숫자가 시사하는 바는 분명했습니다. 난해한 분산 시스템 문제보다 사람이 놓치기 쉬운 결함 이 훨씬 자주 서비스를 멈춘다는 것입니다. 그리고 사람이 놓치기 쉬운 결함은 바꿔 말하면 패턴이 반복된다는 뜻이기도 합니다.

패턴이 반복되고, 기록도 이미 있다면, 그건 검색 가능한 형태로 만들어 배포 전에 되돌려보낼 수 있지 않을까. KRIS는 이 질문에서 출발했습니다.

2. KRIS가 하는 일과, 하지 않기로 한 일

KRIS는 배포 소스의 변경을 과거 장애에서 도출한 위험 패턴과 대조해, 배포 위험의 심각도를 판정하는 서비스입니다.

동작을 세 문장으로 줄이면 이렇습니다.

사내 GitHub PR과 사내 배포시스템에서 코드·설정 변경을 자동 분석합니다.
과거 장애에서 도출한 정책 규칙과 대조해 AI가 심각도를 판정합니다.
위험 요소마다 검출 근거와 수정 방향을 함께 제시합니다.

현재 겨냥하는 대표 장애 유형은 세 가지입니다.

유형	내용
환경 불일치	운영 환경에 개발·검증 환경 도메인이나 설정이 섞여 들어가는 경우
설정값 변경	API Key 누락, DB 스키마 삭제, 리소스 limits/requests 누락 등
운영 안전장치 해제	운영 환경을 보호하기 위한 설정이 풀리는 경우. 리소스 삭제 방지 해제, 운영 환경 DEBUG 로깅, 이미지 태그 고정 해제 등

하지 않기로 한 것

KRIS를 만들 때 가장 먼저 정한 것은 오히려 비목표였습니다.

코딩 컨벤션·가독성 등 일반적인 코드 품질 리뷰 → 기존 코드 리뷰 도구의 몫
보안 취약점 스캔 → 기존 보안 도구의 몫
성능 최적화 제안 → 장애 유발 가능성과 직접 관련이 없음
전체 코드베이스 분석 → PR·배포 단위의 변경점(diff)만 봄

이 선을 명확히 그은 이유는 단순합니다. 또 하나의 범용 리뷰 도구를 만들면 개발자에게는 코멘트가 하나 더 늘어나는 일일 뿐이기 때문입니다. 이미 여러 봇이 PR에 코멘트를 답니다. 여기에 “일반적으로 좋은 코드” 이야기를 하나 더 얹으면 읽히지 않습니다.

KRIS의 코멘트가 읽히려면, 우리 조직과 개인의 기억에서만 나올 수 있는 문장이어야 했습니다. 다른 도구는 할 수 없는 말이니까요.

3. 어떻게 판정하는가 — 규칙 검사와 LLM 판정을 분리한 이유

KRIS는 저장소의 변경분을 아래 순서로 처리합니다.

Compare Provider  →  Policy RAG  →  LLM Severity 재평가  →  결과 전달
(diff 추출)       (규칙 검색·대조)      (3축 판정)         (배포시스템 / PR)

각 단계의 역할은 다음과 같습니다.

Compare Provider. 저장소의 base와 compare 참조를 GitHub Compare API로 조회해 변경 파일 목록과 diff를 만듭니다. 배포시스템에서는 절차서에 지정된 참조를, PR에서는 PR의 base SHA와 head SHA를 사용합니다.

Policy RAG . diff 컨텍스트로 관련 정책 규칙을 벡터 검색한 뒤, 규칙마다 정의된 판정 로직으로 변경 내용을 직접 대조합니다. 여기가 중요한 지점입니다. 검색은 "어떤 규칙을 볼 것인가"를 좁히는 데만 쓰고, 실제 위반 여부는 이 판정 로직이 결정합니다.

LLM Severity 재평가. 규칙에서 정의한 기본 심각도를 시작점으로, LLM이 diff 전체 문맥을 보고 다시 판정합니다.

결과 전달. 배포시스템에서는 배포 리스크 영역에, PR에서는 PR 코멘트에 표시됩니다.

왜 판정을 둘로 나눴는가

처음에는 LLM에게 전부 맡기는 구조도 검토했습니다. 하지만 리스크 판정에서 같은 코드에 대한 판정이 매번 달라지게 된다면 어떻게 될까요? 어제는 HIGH였는데 오늘은 LOW라면 아무도 그 등급을 믿지 않게 되고, 도구는 그 순간 무의미해집니다.

그래서 역할을 나눴습니다.

"규칙을 위반했는가" — 규칙별 위반 여부 판정 로직. 같은 입력이면 항상 같은 출력.
"그래서 얼마나 위험한가" — LLM. 문맥/상황에 따라 달라져야 하는 판단.

application-prod.yml에 DEBUG 로그 레벨이 들어갔다는 사실은 흔들리면 안 됩니다. 하지만 그게 CRITICAL인지 LOW인지는 그 파일이 정말 운영 설정인지, 함께 바뀐 다른 변경이 무엇인지에 따라 달라집니다. 앞은 코드가, 뒤는 LLM이 맡는 게 맞다고 봤습니다.

3축 심각도 판정

심각도는 3단계로 산정됩니다.

1단계 — Base severity 제공. Policy RAG에 정의된 룰별 기본 심각도를 프롬프트에 넣습니다. 다만 이건 어디까지나 출발점일 뿐, 최종 판정은 달라질 수 있습니다.

2단계 — LLM 재평가. LLM이 아래 3축 기준으로 severity_reasoning을 먼저 작성한 뒤 심각도를 정합니다.

축	판단 기준
환경	운영에 개발/스테이지 설정이 혼용되어 있다면 → `CRITICAL`
설정 및 구성	안전장치 비활성화 → `HIGH` / 단순 값 튜닝 → `LOW`
인프라·배포 구성	K8s, Terraform, DB 스키마 변경 → `HIGH~CRITICAL`

판정보다 판정 근거를 먼저 쓰게 한 것이 실제로 효과가 있었습니다. 결론부터 뽑게 하면 근거가 결론에 맞춰 사후 작성되는데, 순서를 뒤집으면 근거가 빈약한 케이스에서 LLM이 등급을 낮춰 잡습니다.

3단계 — 배포 종합 Severity. 배포시스템에서는 개별 발견 항목을 모아 하나의 releaseSeverity를 정합니다. CRITICAL > HIGH > LOW 중 가장 높은 레벨이 그대로 배포 전체의 심각도가 됩니다. CRITICAL 1건, HIGH 2건이 감지된 배포라면 종합 심각도는 CRITICAL입니다.

여기에 UNKNOWN이 하나 더 있습니다. 분석에 실패했거나 권한이 부족해 판단 근거 자체가 부족한 경우입니다. 이걸 LOW로 처리하지 않고 별도 상태로 둔 이유는, "위험하지 않다"와 "모르겠다"는 완전히 다른 정보이기 때문입니다. 후자를 전자로 뭉개면 확인하지 않은 것까지 안전하다고 말하게 됩니다.

같은 이유로 분석 상태도 세 가지로 나눴습니다. 분석 완료 / 분석 불가 (배포 기준 정보가 없는 경우) / 분석 실패(시스템 오류나 저장소 접근 문제). 사용자가 "왜 결과가 없는지"를 알 수 있어야 다음 액션을 정할 수 있습니다.

4. 정책을 만드는 일은, 더하는 게 아니라 덜어내는 일이었습니다

현재 KRIS는 네 개 카테고리의 정책 규칙을 운영합니다.

카테고리	다루는 내용
환경 설정	운영/개발 환경 도메인 혼용, 검증존 리소스의 운영 유입, 레거시 도메인
데이터베이스 설정	Connection Pool 변경, Timeout 미설정, 운영 환경 DDL Auto, 파괴적 스키마 변경
인프라	K8s limits/requests 누락, latest 태그, Terraform destroy, 시크릿 파일 노출, GitOps 매니페스트 변경
빌드 설정	의존성 버전 변경, 운영 환경 DEBUG 로깅, 모바일 매니페스트

규칙을 처음 발굴했을 때는 이십여 개가 나왔고, 솔직히 "더 잡을 수 있는 게 많은데"라는 생각을 했습니다. 그런데 실제 장애 케이스로 돌려보고 팀 내 검토를 거치면서, 논의의 방향이 정반대로 흘렀습니다. 무엇을 더 추가할까가 아니라, 무엇을 덜어낼까가 쟁점이 됐습니다.

몇 가지 실제 논의를 옮겨봅니다.

latest 태그를 무조건 막아야 하는가 . 처음에는 HIGH였습니다. 하지만 사내 이미지 저장소에 직접 만들어 올린 이미지를 쓰는 경우, 파일 수정을 줄이려고 의도적으로 latest를 붙이기도 합니다. 결국 LOW로 낮췄습니다. 외부 도메인 이미지에 대해서만 강하게 볼 여지를 남겨두고요.

DB Connection Pool은 어디까지 볼 것인가 . 초안은 "값이 50을 초과하면 위반"이었습니다. 하지만 운영 DB는 대부분 DBA 조직이 관리합니다. 저희가 장애 예방을 명분으로 구체적인 수치까지 관여할 영역이 아니라고 판단해, "변경이 있었다"만 알리는 방식으로 바꿨습니다. 판단은 실제 담당자가 하는 게 맞습니다.

의존성 버전은 Dependabot과 겹치지 않는가. 겹칩니다. 다만 시점이 다릅니다. Dependabot은 코드를 푸시한 시점에, KRIS는 배포 직전에 봅니다. 품질 관점에서는 배포에서 먼 단계일수록 고치는 비용이 적으니 장기적으로는 Dependabot이 유리합니다. 그래서 이 규칙은 이중 경고가 되지 않도록 옵셔널하게 두는 방향으로 정리했습니다.

린팅·리팩터링 설정 변경. 프레임워크 런타임 설정, 시스템 빌드 설정, 스크립팅 설정 변경 규칙은 아예 제거를 검토했습니다. 빌드 최적화나 린팅 목적의 변경이 대부분이라 너무 자주 잡히고, 자주 잡히면 읽히지 않기 때문입니다.

반대로 올린 것 도 있습니다. K8s 리소스 limits/requests 누락은 HIGH에서 CRITICAL로 올렸습니다. 설정값 누락은 장애 유발 가능성이 높고 영향 범위도 크기 때문입니다. 컨테이너 시크릿·키 파일 노출도 마찬가지로 CRITICAL로 올렸습니다. 당장의 장애와는 거리가 있지만 사고로 이어질 때의 크기가 다릅니다.

이 과정에서 배운 것이 하나 있습니다. 도구가 쓰이지 않게 되는 건 부정확해서가 아니라, 맞는 말을 너무 자주 해서 아무도 읽지 않게 되기 때문입니다. 규칙 하나를 추가할 때마다 나머지 탐지 결과의 신뢰도를 조금씩 깎아먹는다고 생각하면, 규칙을 늘리는 일이 훨씬 신중해집니다.

5. 전사 공통 규칙의 한계

여기까지 만들고 나니 다음 질문이 생겼습니다. 전사 공통 규칙만으로 충분한가.

확인해보기 위해 A 서비스의 실제 장애 이력을 가져와 돌려봤습니다. 2025년 이후 발생한 설정값 오류 장애들이었습니다. 결과는 두 방향에서 의미가 있었습니다.

① 공통 룰이 놓치고 있던 것

한 케이스에서 운영 설정 파일에 비운영 환경 호스트가 들어간 변경이 있었습니다. 환경 혼용은 저희가 가장 자신 있는 영역이었는데, 초기 규칙은 이걸 놓쳤습니다.

원인은 단순했습니다. 비운영 환경을 식별하는 마커 목록에 -dev, -beta, -cbt, -sandbox만 있었고, 해당 케이스에서 쓰인 canary 표기가 목록에 없었던 것입니다. 곧바로 canary, stage, staging, alpha, test 계열 마커를 추가했고, 이후 같은 케이스에서 정상적으로 검출됐습니다.

작은 수정이지만 시사하는 바가 있었습니다. 환경 명명 규칙조차 조직마다 다릅니다. 전사 공통 룰은 최대공약수일 수밖에 없고, 최대공약수는 언제나 누군가의 실제 환경보다 좁습니다.

② 공통 룰이 애초에 알 수 없는 것

더 흥미로운 건 두 번째 방향이었습니다. 장애 이력을 계속 보다 보니, 공통 룰로는 원리적으로 만들 수 없는 규칙들이 보이기 시작했습니다.

가장 대표적인 사례는 로그 수집 파이프라인의 토픽-브로커 매핑이었습니다. A 서비스에서는 식별자 유형별로 카프카 토픽과 브로커가 엄격하게 분리되어 있습니다. 토픽과 브로커를 나눠 운영하는 것 자체는 흔한 구성이지만, 어느 토픽이 어느 브로커로 가야 하는지는 이 조직의 데이터 정책에 따라 정해집니다 . 그런데 로그 수집 설정에 새 입력이 추가되면서, 특정 식별자 유형의 토픽이 다른 유형 전용 브로커로 전달되는 변경이 들어갔습니다.

문법적으로는 완벽히 정상인 YAML입니다. 어떤 정적 분석기도, 어떤 범용 AI 리뷰도 이걸 문제 삼을 수 없습니다. 하지만 이 조직에서 이 변경의 의미는 과금 데이터 혼재입니다.

이런 규칙을 몇 가지 더 발굴했습니다.

- 로그 수집 토픽-브로커 매핑 위반 — 식별자 유형별 브로커 분리 규칙을 어긴 변경

Spring 설정 변경 시 Vault·Profile Key 일치 확인 — 오타나 profile 미분리 시 운영에서 에러 없이 로컬/샌드박스 값으로 fallback되는 문제
자체 Ingress 컨트롤러 환경에서의 Nginx 어노테이션 사용 — 사내 Ingress 환경에서는 Nginx 어노테이션이 무시되며, 특히 ssl-redirect 기본값 차이로 HTTP 요청이 강제 리다이렉트되는 문제

그래서 컬렉션을 분리했습니다

이 규칙들을 전사 공통 컬렉션에 넣을 수는 없었습니다. 다른 조직에서는 존재하지도 않는 개념이라 오탐만 만들 테니까요.

그래서 서비스 조직 전용 컬렉션을 별도로 두고, 규칙마다 적용 범위를 명시하도록 구조를 바꿨습니다.

scope: global → 전사 공통 규칙
scope: service → 특정 서비스 조직에만 적용
tenant → 어느 조직의 규칙인지
target_systems → 어떤 시스템에 적용되는지
policy_source → 이 규칙의 근거가 되는 사내 가이드 문서 링크

이 중 policy_source를 넣은 이유가 있습니다. 조직 특화 규칙은 대부분 어딘가에 이미 문서로 존재합니다. 배포 가이드에, 플랫폼 가이드에, 보안 가이드에 다 적혀 있습니다. 문제는 배포 직전에 그 문서를 다시 읽는 사람이 극히 드물다는 것입니다.

그래서 규칙에 원본 문서 링크를 함께 심어뒀습니다. 개발자가 경고를 받았을 때 **“이게 어느 규칙에 근거한 말인지”**를 바로 확인할 수 있고, 규칙 자체가 틀렸다면 그 문서를 고치면 됩니다. AI가 판정했다는 이유로 결과를 믿으라고 요구하지 않는 것, 이게 저희가 규칙을 설계하며 지키려 한 원칙이었습니다.

이 구조 덕분에 각 서비스 조직은 다른 조직에 영향 없이 자기 팀의 장애 패턴과 정책을 추가로 검사하게 만들 수 있습니다. 저희가 모든 조직의 도메인을 알 수는 없지만, 각 조직은 가장 잘 압니다. 그 지식이 들어올 자리를 만들어두는 것이 저희 몫이라고 봤습니다.

6. 개발자의 흐름을 끊지 않는 곳

기술적으로 잘 동작해도, 새로운 화면을 하나 더 열어야 한다면 그 도구는 쓰이지 않습니다. 그래서 KRIS는 이미 개발자가 매일 머무는 두 지점에만 연동했습니다.

배포시스템

배포절차서의 리뷰 요청을 보내는 시점에 자동으로 분석이 실행됩니다. 절차서를 저장하는 시점이 아니라 리뷰 요청 시점인 이유는, 승인 직전의 최신 코드 상태를 기준으로 판정해야 하기 때문입니다.

결과는 배포절차서의 배포 리스크 영역에 표시됩니다. 상단에 이번 분석의 핵심 메시지 배너가 있고, 심각도별 발견 개수가 카드로 요약되며, 그 아래 Findings(탐지) 목록이 이어집니다. 각 항목에는 심각도 뱃지, 규칙 ID, 배포 기준, 대상 파일, 탐지 신호 요약이 붙습니다.

카드를 클릭하면 상세 모달에서 감지 사유 (왜 위험 신호로 판정했는지), 권장 조치 (어떻게 고치면 되는지), 그리고 AI 심각도 판단 근거 3축 카드를 볼 수 있습니다. 리뷰어는 이 리포트를 배포 승인 전 판단 근거로 사용하고, 문제가 있으면 작성자에게 수정 요청을 보냅니다.

과거 분석 결과는 분석 이력에 최신순으로 쌓입니다. 수정 요청 → 코드 수정 → 재요청 사이클이 돌면 그 변화를 그대로 추적할 수 있습니다.

이 경로가 갖는 강점은 분석 범위 입니다. PR은 단일 브랜치의 변경만 봅니다. 배포절차서는 여러 저장소·브랜치·태그가 함께 나가는 범위를 통합해서 봅니다. 개별 PR에서는 아무 문제가 없었지만 함께 배포될 때 어긋나는 조합이 있고, 통합 배포처럼 변경 규모가 크고 영향 범위가 넓을수록 이 검사의 가치가 커집니다.

GitHub PR

PR 코멘트에 /risk_detector 를 입력하면 즉시 분석이 실행되고, main 또는 master 대상 PR을 열면 자동으로 실행됩니다.

분석이 시작되면 먼저 진행 중임을 알리는 코멘트가 게시되고, 완료되면 ## ⚠️ Predictive Incidents 헤더의 결과 코멘트로 교체됩니다. 이전 KRIS 결과가 있으면 새 결과가 덮어씁니다. 커밋을 밀 때마다 코멘트가 쌓이면 PR이 금세 지저분해지기 때문에, 항상 최신 결과 하나만 유지되도록 했습니다.

로딩 코멘트를 굳이 띄우는 이유도 같은 맥락입니다. 아무 반응이 없으면 개발자는 분석이 시작되지 않았다고 판단할 수 있고, 그러면 다음부터 쓰지 않게 됩니다.

두 진입점은 동일한 분석 엔진을 공유하며, 같은 정책 규칙과 심각도 판정 기준을 적용합니다. 어디서 실행하든 같은 답이 나와야 판정을 신뢰할 수 있기 때문입니다.

7. 다음 이야기 — 설정값에서 소스코드로

지금까지 이야기한 것은 전부 설정값 계층입니다. 환경 도메인, 리소스 설정, 인프라 매니페스트. 이 영역은 규칙으로 만들 수 있습니다. "운영 파일에 비운영 도메인이 있는가"는 코드로 명확하게 판정할 수 있습니다.

그런데 앞서 본 통계를 다시 보면, 소스코드 오류가 설정값 오류보다 두 배 가까이 많습니다. 그리고 이쪽은 규칙으로 만들 수 없습니다.

"이 코드가 과거에 장애를 냈던 코드와 닮았는가"라는 질문에는 코드로 답할 수 없습니다. 게다가 두 가지 조건을 더 만족해야 합니다.

언어가 달라도 잡아야 합니다. 과거 장애 코드가 Java인데 유사 패턴이 Python으로 작성된 연동 코드에서 발생한다면?
서비스 맥락을 알아야 합니다. 동일한 코드 패턴이 A 서비스에서는 장애지만 B 서비스에서는 정상일 수 있습니다.

저희는 이 문제를 풀기 위해 장애일지와 실제 장애 유발 코드를 RAG로 구성했고, 여기서 예상하지 못한 결과를 마주했습니다.

정교하게 설계한 청킹 전략이 오히려 발목을 잡고 있었다는 것입니다. 장애일지를 목적별로 잘게 나눠 임베딩하는 방식보다, LLM에게 원문을 읽히고 위키 페이지로 합성하게 한 쪽의 검색 정확도가 더 높았습니다. Karpathy가 제안한 llm-wiki 개념을 사내 장애 데이터에 적용해 여러 비교 실험을 돌린 결과입니다.

이어지는 이야기는 다음 글에서 다루려 합니다.

2편에서는 RAG와 llm-wiki를 비교 검증한 과정과, 두 방식을 어떻게 나눠 쓰기로 했는지를 정리합니다.
3편에서는 장애일지를 LLM이 직접 소유·갱신하는 위키로 만드는 구조를 다룰 예정입니다.

소스코드 오류 탐지는 아직 출시 전이며, 현재 검증과 구조 개선을 진행하고 있는 단계입니다.

마치며

KRIS를 만들며 배운 것을 하나로 줄이면 이렇습니다.

조직의 장애 이력은 이미 충분히 축적되어 있었습니다. 다만 그것이 쓰이는 시점이 늦었을 뿐입니다.

장애일지는 성실하게 쓰였고, 재발 방지 대책도 꼼꼼했고, 배포 가이드도 잘 정리되어 있었습니다. 문제는 그 문서들이 다음 배포 앞에 놓이지 않았다 는 것이었습니다. 이상 징후는 대부분 배포가 나간 뒤 모니터링과 알림으로 발견됩니다. KRIS가 한 일은 새로운 지식을 만든 것이 아니라, 이미 있던 지식이 소환되는 시점을 앞으로 당긴 것에 가깝습니다.

AI를 도입하는 일도 비슷하다고 생각합니다. 더 좋은 모델을 쓰는 것보다 그 조직만이 가진 맥락을 어떤 형태로 모델에게 건네줄 것인가가 결과를 가릅니다. 범용 도구가 "일반적으로 좋은 코드"까지밖에 말할 수 없는 이유도, 반대로 조직 특화 규칙이 "이 변경은 과금 데이터를 혼재시킵니다"라고 말할 수 있는 이유도 거기에 있습니다.

같은 장애를 두 번 겪지 않는 조직을 만드는 일에, 저희가 만든 도구가 작은 몫이라도 하기를 바랍니다.

읽어주셔서 감사합니다.