10월 27일 화요일

성능 병목, 코드 이해, 입력 변환, 검색 품질을 한 시스템 안에서 어떻게 분리해 검증해야 하는가?

다섯 신호를 하나의 제품 목록으로 읽으면 공통점이 흐려진다. 더 유용한 독법은 각 도구가 어떤 경계를 바꾸고, 그 변화가 어느 지표에서만 성립하는지를 묻는 것이다. GPU-unlock은 RTX 30 시리즈의 FP16·BF16 행렬 연산 제한을 드라이버 수정 없이 푸는 Linux 커널 모듈이다. RTX 3090 Ti의 BF16 처리량이 87.50에서 157.41 TFLOPS로 늘었다는 결과는 강하지만, 메모리 대역폭에 묶인 LLM 토큰 생성과 INT8 작업은 거의 나아지지 않았다. 반대로 Sphinx는 처리량이 아니라 AI 생성 코드를 사람이 이해했는지를 푸시 전에 확인한다. kordoc은 다양한 문서를 구조화된 텍스트로 옮기는 입력 계층을 넓히지만 DRM 문서는 경계 밖이다. Rerank 5는 검색 결과와 문서 안 근거를 좁혀 후단의 토큰과 정답률을 개선했다고 보고한다. 즉 구현 검토의 단위는 ‘새 도구를 붙였는가’가 아니라 병목, 검증 게이트, 지원 입력, 평가 조건을 명시했는가다. 이 구분을 지키면 한 계층의 개선을 전체 시스템 성능으로 과장하지 않고, 관찰 가능한 실패 조건을 다음 실험에 남길 수 있다. 각 계층에는 통과 기준과 실패 기준을 쌍으로 둬야 한다. 연산은 빨라진 경로와 그대로인 경로, 코드는 설명 가능한 동작과 설명하지 못한 실패 조건, 문서는 변환되는 형식과 제외되는 DRM, 검색은 토큰과 정답률을 함께 기록해야 한다. 그래야 다음 계층이 앞선 성공의 범위를 오해하지 않는다.

1. 01

   연산 상한과 애플리케이션 병목을 분리한다

   행렬 연산 제한을 해제해 BF16 처리량을 크게 높인 결과와 토큰 생성·INT8 개선이 거의 없었다는 결과는 동시에 참이다. 전자는 특정 연산 경로의 상한을 보여주고, 후자는 실제 작업이 메모리 대역폭 같은 다른 제약에 묶일 수 있음을 보여준다. 따라서 도입 전 검증은 TFLOPS 하나로 끝내지 말고 대상 워크로드를 연산 유형별로 나눠야 한다. 개선이 관측된 FP16·BF16 경로와 개선이 희박한 생성·INT8 경로를 같은 평균값으로 합치면 모듈이 해결하지 않은 병목까지 해결한 것처럼 보일 수 있다. 검증표에는 하드웨어와 정밀도, 측정한 처리량뿐 아니라 개선이 거의 없던 작업도 남겨야 한다.

2. 02

   코드 생성과 코드 이해 사이에 게이트를 둔다

   Sphinx의 핵심은 또 다른 모델이 코드를 평가한다는 사실보다 Git 푸시를 잠시 멈추는 위치에 있다. 별도 리뷰어 모델이 상황형 질문을 만들고, 개발자는 코드와 diff를 볼 수 있는 오픈북 방식으로 동작과 실패 조건을 설명한다. 오답이면 같은 문장을 반복하지 않고 다른 상황으로 다시 묻는다. 이 흐름은 생성 완료를 검증 완료로 취급하지 않는다. 다만 퀴즈 통과가 모든 결함 제거를 뜻한다는 근거는 없다. 확인되는 것은 작성자가 코드의 동작과 실패 조건을 설명할 수 있는지이며, 게이트의 목적도 그 경계에 맞춰야 한다. 따라서 통과 여부뿐 아니라 어떤 실패 조건에서 재질문이 생겼는지를 남기는 편이 도구의 역할에 맞다. 코드와 diff를 볼 수 있다는 조건도 평가 해석에서 빼면 안 된다.

3. 03

   입력 파이프라인은 지원 형식과 제외 조건으로 정의한다

   kordoc은 HWP·HWPX뿐 아니라 PDF, Office 문서, 이미지까지 Markdown이나 JSON으로 변환하고 병합 표 구조 보존과 로컬 OCR을 제시한다. CLI·SDK·MCP라는 접점도 제공한다. 구현 관점에서 중요한 것은 형식 개수보다 변환 뒤 구조가 후단에서 쓸 수 있는지다. 표 보존과 구조화 출력은 그 검증점을 제공하지만, 한컴 DRM 문서를 처리하지 못한다는 제한도 명시돼 있다. 따라서 수집 계층은 성공 경로만 연결하지 말고 DRM 여부를 입력 단계에서 식별해 지원되지 않는 문서가 조용히 누락되지 않게 다뤄야 한다. 연결 방식은 셋이지만 결과 계약은 Markdown이나 JSON이라는 출력으로 모인다. 입력 형식별로 표 구조와 OCR 결과를 확인하고, 처리 불가 문서는 명시적 제외로 분류해야 후단 검색이 빈 입력을 정상 결과로 오인하지 않는다.

4. 04

   검색 평가는 순위와 근거 압축을 함께 본다

   Rerank 5는 Pro와 Fast 모델로 검색 결과를 재정렬하고 Context Focus로 문서 안 핵심 구절을 추출한다. 자체 평가에서 검색 에이전트의 토큰 사용량이 35% 줄고 정답률이 46%에서 58%로 올랐다고 보고했다. 이 수치는 재정렬과 근거 추출이 후단 문맥을 줄이면서 답 품질을 높일 가능성을 보여주지만, 제공된 자료는 자체 평가라는 경계도 함께 갖는다. 검증 시에는 토큰 절감과 정답률을 따로 기록하고, 둘 중 하나만 좋아진 경우를 성공으로 합치지 않아야 한다. Pro와 Fast 역시 이름만으로 선택하지 말고 같은 평가 질문에서 비교할 대상이다. 또한 재정렬 결과와 Context Focus가 뽑은 구절을 분리해 관찰해야 어느 단계가 토큰 감소와 정답률 변화에 기여했는지 판단할 수 있다. 제공된 수치는 그 분해 결과까지 말해 주지는 않는다.

5. 05

   구현 지표를 사업 성과의 대리값으로 쓰지 않는다

   기술업계의 일부 대형 기업에서는 직원당 매출과 이익률이 개선됐지만, 나머지 S&P 493과 거시 생산성 지표에서는 AI 성과가 뚜렷하지 않다는 신호가 함께 제시됐다. AI 지출도 소수 기업에 집중돼 있다. 이는 커널 처리량, 퀴즈 통과, 변환 성공, 검색 정답률이 각각 유효해도 조직의 매출·이익 전환을 자동으로 증명하지는 못한다는 상위 검증 경계를 만든다. 기술팀은 각 계층의 로컬 지표를 유지하되, 저렴해지는 AI가 실제 결과로 이어지는지는 별도 결과 지표로 확인해야 한다. 다시 말해 구성 요소 벤치마크와 조직 성과 사이에는 자동 등호가 없다. 어느 로컬 지표가 어떤 업무 결과로 이어졌는지 연결을 확인해야 소수 기업의 개선을 일반화하지 않을 수 있다.

오늘의 자료가 제안하는 구현 원칙은 단순하다. 먼저 목표 워크로드를 연산 경로까지 좁히고, 생성된 코드는 사람이 실패 조건을 설명하는 게이트를 통과시킨다. 문서 입력은 지원 형식과 DRM 제외 조건을 함께 기록하고, 검색은 토큰 절감과 정답률을 분리해 측정한다. 마지막으로 이 로컬 지표를 매출이나 생산성의 증거로 바로 승격하지 않는다. GPU-unlock의 상반된 워크로드 결과와 Rerank 5의 자체 평가라는 표시는 특히 중요하다. 성능 수치가 어디에서 나왔고 어디까지 일반화할 수 없는지를 남길 때, 도구 조합은 기능 목록이 아니라 반증 가능한 시스템 설계가 된다.