책에 포함된 노트AI를 잘 쓰는 법: 프롬프트를 넘어 컨텍스트·워크플로·에이전트까지

9부 48장. 긴 문맥, 추론, 도구 사용, 코딩 성능을 보는 법

2026-04-24Views 22약 9분생성형 AI 활용

9부 48장. 긴 문맥, 추론, 도구 사용, 코딩 성능을 보는 법

지난 장에서 우리는 모델 선택을 속도, 비용, 품질의 균형으로 봐야 한다고 이야기했다. 그런데 여기서 바로 다음 질문이 생긴다. 품질은 정확히 무엇으로 판단할 것인가?

모델 소개 페이지에는 늘 멋진 말이 붙는다. "1M 컨텍스트", "고급 추론", "에이전트 지원", "코딩 특화". 하지만 이런 문구만 보고 모델을 고르면, 새 운동화를 박스 디자인만 보고 사는 것과 비슷하다. 예뻐 보여도 내 발에는 안 맞을 수 있다.

특히 긴 문맥에서는 더 그렇다. 컨텍스트 윈도우가 크다고 해서 긴 문서를 정말 잘 이해하는 것은 아니며, 중요한 정보가 문서 한가운데 숨어 있으면 성능이 크게 떨어지는 경우도 많다. 공개 비교 자료들도 광고된 최대 문맥 길이와 실제로 믿고 쓸 수 있는 문맥 성능 사이에 꽤 큰 차이가 있음을 계속 보여 준다.¹²

그래서 모델을 볼 때는 "이 모델이 제일 좋나?"라고 묻기보다, "내 작업에 필요한 능력 축에서 얼마나 강한가?"라고 묻는 편이 훨씬 실용적이다. 이 장에서는 그때 꼭 봐야 할 네 가지 축, 즉 긴 문맥, 추론, 도구 사용, 코딩 성능을 어떻게 읽어야 하는지 정리해 보겠다.

9부 48장. 긴 문맥, 추론, 도구 사용, 코딩 성능을 보는 법

종합 점수보다 능력 축을 먼저 보라

많은 사람이 리더보드를 볼 때 전체 순위부터 본다. 물론 전체 순위는 방향을 잡는 데 도움이 된다. 하지만 실제 일에서는 종합 1등보다 내 일에 맞는 강점이 더 중요하다.

예를 들어 어떤 모델은 긴 문서 처리에는 강하지만 도구 사용이 서툴 수 있다. 어떤 모델은 코드 생성은 훌륭하지만 터미널 작업에서는 답답할 수 있다. 또 어떤 모델은 짧은 질문에는 재빠르고 똑똑해 보이지만, 여러 문서를 엮어 추론하라고 하면 금세 흔들릴 수도 있다.

실무적으로는 네 가지를 나눠 봐야 한다.

긴 문맥 성능: 많은 정보를 넣었을 때 앞, 중간, 뒤의 내용을 잃지 않는가
추론 성능: 흩어진 사실을 엮고, 제약을 지키고, 애매한 문제를 풀 수 있는가
도구 사용 성능: 검색, 파일, 데이터베이스, 캘린더 같은 도구를 적절한 순간에 제대로 쓰는가
코딩 성능: 코드를 생성하는 것을 넘어 코드베이스를 이해하고, 수정하고, 테스트하고, 실행 흐름까지 다룰 수 있는가

이 네 축을 분리해서 보면 유행에 덜 휘둘린다. "요즘 가장 핫한 모델"보다 "내가 하려는 일을 가장 안정적으로 끝내는 모델"이 보이기 시작한다.

긴 문맥 성능은 창 크기가 아니라 기억 유지율이다

긴 문맥을 볼 때 가장 먼저 버려야 할 오해가 하나 있다. 컨텍스트 윈도우 숫자 자체가 곧 실력은 아니라는 점이다.

모델이 200K, 400K, 1M 토큰을 넣을 수 있다고 말하는 것은 어디까지나 "이만큼 받을 수 있다"는 뜻에 가깝다. 하지만 진짜 중요한 것은 그 안에 있는 정보를 얼마나 잘 찾고, 연결하고, 끝까지 유지하느냐다. 긴 문맥 비교 자료들은 단순히 많이 넣는 능력보다, 묻혀 있는 정보를 회수하고 멀리 떨어진 근거를 연결하는 능력이 더 중요하다고 지적한다.¹²

여기서 봐야 할 것은 대개 세 단계다. 첫째, 바늘 찾기처럼 숨어 있는 정보를 찾아내는가. 둘째, 여러 위치에 흩어진 정보를 묶어 답할 수 있는가. 셋째, 긴 문서를 읽고도 요약과 세부 질의응답에서 일관성을 유지하는가. 장문 이해 벤치마크들은 바로 이 지점을 시험하며, 인간이 여전히 모델보다 훨씬 잘하는 영역도 적지 않다고 말한다.³

LooGLE 같은 벤치마크는 이런 문제를 더 현실적으로 보여 준다. 단순 검색뿐 아니라 장거리 의존성, 계산, 타임라인 재정렬, 다중 정보 회수, 요약 같은 과제를 넣어 "정말 긴 문맥을 이해했는가"를 묻는다.⁴ L-Eval 역시 긴 문맥 모델을 비교하려면 데이터 구성과 평가 방식이 표준화되어야 한다고 강조한다.⁵

실제로 긴 문맥이 중요한 작업은 생각보다 많다. 계약서 비교, 회의 기록 누적 분석, 긴 대화 이력 유지, 여러 보고서 종합, 대형 코드 저장소 파악이 모두 그렇다. 이런 작업에서는 "문서를 통째로 넣을 수 있나"보다 "문서 전체를 넣었을 때도 중간에 있는 중요한 조항이나 예외를 놓치지 않나"가 훨씬 중요하다.

긴 문맥 성능을 직접 볼 때는 다음 같은 테스트가 잘 통한다.

같은 사실을 문서의 앞, 중간, 뒤에 나눠 놓고 모두 회수하는지 본다.
여러 문서에 흩어진 근거를 엮어 하나의 판단을 내리게 해 본다.
요약을 시킨 뒤, 요약에 포함되지 않은 세부 반례를 다시 물어본다.
중요 정보 주변에 눈길을 끄는 잡정보를 많이 넣어 흔들리는지 본다.

이 테스트에서 자주 보이는 실패는 꽤 인간적이다. 앞부분은 잘 기억하는데 중간을 놓친다. 요약은 그럴듯하지만 예외 조항이 빠진다. 개별 문장은 맞는데 서로 연결하면 모순이 생긴다. 바로 이런 순간에 "문맥 길이"와 "문맥 활용력"의 차이가 드러난다.

추론 성능은 똑똑해 보이는 말솜씨와 다르다

추론 성능을 볼 때 많은 사람이 속는 이유는 간단하다. 모델이 아주 그럴듯하게 말하면, 마치 제대로 생각한 것처럼 느껴지기 때문이다. 하지만 추론은 말의 분위기가 아니라 문제를 푸는 구조에서 드러난다.

좋은 추론은 단순히 정답 하나를 맞히는 능력이 아니다. 서로 떨어진 사실을 연결하고, 조건을 빠뜨리지 않고, 반례를 고려하고, 모르면 섣불리 단정하지 않는 능력에 가깝다. 특히 긴 문서 기반 추론에서는 단순 발췌보다 종합과 판단이 더 어렵고, 이 영역은 아직도 만만하지 않다.³

예를 들어 재무 보고서를 읽고 "이번 분기의 매출이 늘었는가?"를 묻는 것은 비교적 쉽다. 하지만 "매출은 늘었는데 수익성이 나빠졌다면 그 이유를 세 항목으로 분해해 설명하라"는 질문은 훨씬 어렵다. 숫자를 읽는 것만으로는 안 되고, 비용 구조와 문맥을 함께 엮어야 하기 때문이다.

또 하나 중요한 것은 전문 영역 추론은 일반 지식 문제와 다르다는 점이다. 법률, 금융, 과학, 운영 의사결정처럼 실제 현장 판단이 필요한 영역에서는 별도의 전문 추론 평가가 따로 존재한다. 즉, 일반적인 "똑똑함" 점수가 높다고 해서 내 업종의 판단을 잘해 준다는 보장은 없다.⁶

추론 성능을 평가할 때는 이런 질문이 유용하다.

이 모델은 여러 조건을 동시에 지키는가?
결론뿐 아니라 근거 연결이 자연스러운가?
애매한 문제에서 모른다고 말할 줄 아는가?
반례나 예외가 들어오면 기존 답을 수정하는가?

말하자면 추론 성능은 "답을 빨리 내는 능력"이 아니라, 답을 함부로 내지 않아야 할 때 멈출 줄 아는 능력까지 포함한다. 이것이 빠져 있으면, 모델은 똑똑한 조언자가 아니라 자신감 넘치는 오답 제조기가 되기 쉽다.

도구 사용 성능은 호출 횟수가 아니라 일의 완성도로 봐야 한다

도구를 쓰는 모델은 겉으로 보면 대단해 보인다. 검색도 하고, 파일도 열고, 캘린더도 확인하고, 데이터베이스도 조회한다. 하지만 여기에도 함정이 있다. 도구를 호출할 수 있는 것과 도구를 잘 써서 일을 끝내는 것은 다르다.

도구 사용 성능은 생각보다 넓은 능력이다. 어떤 도구가 필요한지 판단해야 하고, 적절한 파라미터를 넣어야 하고, 받은 결과를 읽어 다음 행동을 정해야 하고, 모호하면 질문도 해야 한다. 최근 벤치마크들이 BFCL, MCP Atlas, TAU Bench 같은 별도 범주로 도구 사용을 분리해 보는 이유가 바로 여기에 있다.⁷ 또한 HiL-Bench처럼 필요한 순간에 도움을 요청하거나 명확화 질문을 하는 능력을 따로 재는 평가도 있다.⁶

좋은 도구 사용 모델은 대체로 다음과 같은 특징을 보인다.

도구가 필요 없는 일에는 괜히 호출하지 않는다.
도구가 필요할 때는 적절한 것을 고른다.
인자와 범위를 비교적 정확하게 넣는다.
실패한 도구 결과를 무시하지 않고 복구 경로를 찾는다.
정보가 부족하면 추측하지 않고 질문한다.
도구 결과를 그냥 붙여넣지 않고 실제 판단에 반영한다.

이 부분은 특히 에이전트형 워크플로에서 중요하다. 검색 도구가 붙은 모델이 항상 더 좋은 답을 주는 것은 아니다. 어떤 모델은 검색을 너무 자주 해서 느리고 산만해지고, 어떤 모델은 검색은 해 놓고 읽지를 않는다. 또 어떤 모델은 파일을 열어 놓고도 핵심 줄을 놓친다.

그래서 도구 사용은 "호출 성공 여부"보다 작업 완료 성공률로 보는 편이 맞다. 예를 들어 일정 조율 에이전트라면 단순히 캘린더 API를 불렀는지가 아니라, 충돌 없는 시간을 찾았는지, 애매한 요청은 확인했는지, 잘못된 약속을 만들지 않았는지를 봐야 한다.

코딩 성능은 코드 생성만으로 판단하면 자주 속는다

코딩 모델을 볼 때도 비슷한 착시가 있다. 멋진 함수 하나를 잘 짜면 "코딩 잘하네"라고 생각하기 쉽다. 하지만 실무 코딩은 대개 함수 한 문제 풀기로 끝나지 않는다. 기존 코드를 읽고, 여러 파일을 고치고, 테스트를 돌리고, 실패 원인을 찾고, 터미널에서 환경을 다루는 일이 한 묶음으로 온다.

그래서 코딩 성능은 최소한 네 갈래로 나눠 봐야 한다.

코드 생성: 설명을 보고 함수를 만들어 내는 능력
코드베이스 이해: 낯선 저장소 구조와 의존관계를 파악하는 능력
수정과 디버깅: 기존 버그를 고치고 테스트를 통과시키는 능력
터미널 작업: 명령 실행, 로그 확인, 환경 설정, CI 문제 해결 능력

2026년 코딩 벤치마크들을 보면 이 차이가 아주 선명하다. HumanEval 같은 초기 벤치마크는 상위 모델 사이 변별력이 많이 줄었고, SWE-bench Verified는 방향성은 주지만 이미 포화와 오염 문제가 지적된다. 더 현실적인 비교를 위해 SWE-bench Pro, Terminal-Bench, LiveCodeBench, Aider Polyglot 같은 서로 다른 평가들이 함께 쓰인다.⁸⁹

여기서 중요한 교훈은 하나다. 코딩 성능에도 단일 왕좌는 없다는 것이다. 어떤 모델은 리포지터리 버그 수정에 강하고, 어떤 모델은 터미널 작업에서 더 낫고, 어떤 모델은 순수 코드 생성 능력이 좋다. 심지어 같은 모델도 어떤 에이전트 프레임워크나 CLI 스캐폴드를 붙이느냐에 따라 점수가 크게 달라진다.⁸

이 말은 곧, 코딩 모델을 고를 때 "누가 1등인가"보다 "내 개발 흐름과 어디서 만나는가"를 봐야 한다는 뜻이다. 내 일이 프론트엔드 UI 생성인지, 백엔드 버그 수정인지, 대형 모노레포 탐색인지, 터미널 중심 운영 자동화인지에 따라 기준이 달라진다.

실전에서는 이런 테스트가 좋다. 기존 저장소에서 버그 하나를 고치게 하고, 관련 파일을 제대로 찾는지 본다. 수정 후 테스트를 돌리게 하고, 실패 로그를 읽고 다음 시도를 하는지 본다. 또 낯선 모듈을 설명하게 해서, 코드 한 파일이 아니라 코드베이스 수준으로 이해하는지 확인한다. 이 과정을 보면 알고리즘 문제 풀이 점수와는 전혀 다른 얼굴이 드러난다.

벤치마크는 지도이고, 내 작업 샘플은 현장이다

여기까지 읽으면 벤치마크를 믿지 말라는 말처럼 들릴 수 있다. 하지만 그렇지는 않다. 벤치마크는 여전히 중요하다. 다만 지도를 목적지로 착각하면 안 된다는 뜻이다.

벤치마크는 모델의 경향을 빠르게 파악하게 해 준다. 긴 문맥에서 강한지, 도구 사용이 좋은지, 코딩에서 어디가 강한지 대강의 지형을 보여 준다. 하지만 실제 운영에서 중요한 것은 내 데이터, 내 문서, 내 코드, 내 실패 비용이다.

그래서 가장 좋은 방법은 작은 자체 평가 세트를 만드는 것이다.

자주 하는 작업 20개 안팎을 고른다.
각 작업이 긴 문맥, 추론, 도구 사용, 코딩 중 어디에 걸리는지 표시한다.
성공 기준을 정답률뿐 아니라 형식 준수, 재시도 횟수, 수정 시간까지 포함해 정한다.
후보 모델을 같은 프롬프트와 같은 도구 권한에서 비교한다.
결과보다 실패 패턴을 기록한다.

여기서 특히 중요한 것은 실패 패턴이다. 어떤 모델은 자주 틀리지는 않지만 한 번 틀리면 크게 틀린다. 어떤 모델은 성능은 조금 낮아도 틀릴 때 이유를 드러내서 고치기 쉽다. 어떤 모델은 코드 수정은 잘하지만 긴 설명 문서는 엉성하다. 이 차이는 전체 평균 점수만 봐서는 잘 보이지 않는다.

결국 우리가 원하는 것은 시험 성적표가 아니라, 내 워크플로 안에서의 재현 가능한 성공이다.