diff --git a/ko/sections/05-1-model-selection.qmd b/ko/sections/05-1-model-selection.qmd
index f9544e1..e99ac5f 100644
--- a/ko/sections/05-1-model-selection.qmd
+++ b/ko/sections/05-1-model-selection.qmd
@@ -1,2 +1,144 @@
-# §5.1 작업에 맞는 모델 고르기 {.unnumbered}
+<!-- authoritative-lang: ko -->
+
+## 작업에 맞는 모델 고르기 {#sec-model-selection}
+
+AI 코딩 도구에서 여러 모델을 고를 수 있게 되면, 어떤 모델을 써야 하는지부터 고민하게 된다. 이때 필요한 질문은 “내 작업을 끝내는 데 어떤 능력이 필요한가?”이다. 모델을 선택하려면 먼저 결과물의 기준과 작업의 조건을 구체화해야 한다.
+
+### 모든 작업에 같은 모델을 써야 할까?
+
+친구들과 게임을 하기 위한 내전 관리 프로그램을 만든다고 하자. 이 프로그램에는 참가자 목록, 포지션별 정렬, 팀 편성, 경기 결과와 점수 기록 기능이 있다. 개발 중에는 다음과 같은 요청이 생긴다.
+
+- 참가자 목록을 정렬하는 코드가 어떻게 동작하는지 설명해 달라.
+- 포지션 순서대로 목록을 정렬하는 기능을 추가해 달라.
+- 경기 결과가 두 번 반영되는 오류의 원인을 찾아 달라.
+- 점수가 중복 계산되거나 예외 처리가 빠진 부분이 있는지 검토해 달라.
+
+모두 같은 프로그램에 관한 요청이지만, 필요한 판단은 다르다. 짧은 함수의 동작은 해당 코드만으로 설명할 수 있는 경우가 있다. 반면 결과가 두 번 반영되는 원인을 찾으려면 화면의 이벤트 처리, 서버 요청, 데이터 저장 과정을 함께 확인해야 할 수 있다.
+
+같은 “코드 수정” 안에서도 차이가 생긴다. 버튼에 보이는 문구를 바꾸는 일과 경기 점수의 계산 규칙을 바꾸는 일은 변경량이 비슷해도 오류의 영향이 다르다. 따라서 작업 이름이나 코드 길이만으로 모델을 배정하기는 어렵다.
+
+여기서 작업에 맞는 모델이란, **정해 둔 완료 기준을 충족하면서 허용할 수 있는 시간과 비용 안에서 작업을 수행하는 모델**이다. 품질이 충분한지 먼저 확인하고, 그 기준을 통과한 후보 사이에서 다른 조건을 비교한다. OpenAI의 모델 선택 가이드도 작업의 품질, 응답 시간, 사용 빈도 등을 고려하고 같은 입력으로 후보를 비교하도록 안내한다.[^model-selection-openai]
+
+### 모델 선택에서 무엇을 볼까?
+
+비교에 앞서 후보가 필요한 입력과 기능을 지원하는지 확인한다. 화면 이미지를 보고 판단해야 하는지, 관련 파일에 접근해야 하는지, 코드를 실행해야 하는지에 따라 사용할 수 있는 후보가 달라진다. 이때는 모델 자체의 지원 기능과 실제 사용하는 도구가 제공하는 기능을 함께 살펴본다.
+
+그다음에는 정확도, 속도, 비용을 비교한다. 여기에 오류가 미치는 영향과 결과를 검증할 수 있는 정도를 더하면, 같은 작업에서도 우선순위가 달라지는 이유를 설명할 수 있다.
+
+| 판단 기준 | 확인할 질문 | 내전 관리 프로그램에서의 예 |
+| --- | --- | --- |
+| 정확도와 요구 충족 | 무엇이 맞아야 작업이 끝나는가? | 정렬 순서와 동점 처리 규칙을 모두 지키는가? |
+| 속도 | 답변을 얼마나 빨리 받아야 하며, 완료까지 얼마나 걸리는가? | 화면을 조금씩 고치며 빠르게 확인해야 하는가? |
+| 비용 | 사용 빈도와 반복 요청을 감당할 수 있는가? | 작은 수정을 여러 번 요청할 때 이용 부담이 커지는가? |
+| 오류의 영향 | 틀리면 어디까지 영향을 미치는가? | 화면 표시만 달라지는가, 저장된 경기 기록도 바뀌는가? |
+| 검증 가능성 | 결과가 맞는지 무엇으로 확인할 수 있는가? | 예시 목록, 테스트, 요청 로그, 저장 기록으로 확인할 수 있는가? |
+
+#### 정확도는 작업의 완료 기준으로 판단한다
+
+질문에 대한 정확도와 코드 수정의 정확도는 같은 방식으로 확인하기 어렵다. 설명은 코드와 근거가 일치하는지 살펴봐야 한다. 기능 구현은 요구한 동작과 예외 조건을 만족하는지 확인해야 한다. 디버깅은 제시한 원인이 관측된 현상을 설명하고, 수정 후 같은 오류가 재현되지 않는지 봐야 한다.
+
+따라서 모델을 고르기 전에 “좋은 답”을 관찰할 수 있는 조건으로 바꾸는 편이 좋다. “정렬을 잘 구현한다”보다 “지정한 포지션 순서를 따르고, 같은 포지션에서는 점수 내림차순으로 정렬한다”가 비교 기준으로 유용하다. 설명이 길거나 자신 있게 쓰였다는 사실은 이 기준을 대신하지 못한다.
+
+#### 속도는 작업을 끝내는 시간까지 본다
+
+응답을 빨리 받으면 작은 수정을 반복하기 편하다. 그러나 첫 답변이 빨라도 잘못된 결과를 여러 번 수정해야 한다면 작업 완료는 늦어질 수 있다. 반대로 시간이 더 걸리는 후보라도 추가 수정이 적다면 전체 작업에는 유리할 수 있다.
+
+비교할 때는 첫 응답 시간과 검증까지 포함한 완료 시간을 구분한다. 특히 사용자가 결과를 기다리며 다음 작업을 해야 하는 경우와, 나중에 결과를 확인해도 되는 경우는 허용할 수 있는 지연이 다르다.
+
+#### 비용은 사용 빈도와 재시도까지 고려한다
+
+한 번의 이용 비용이 낮아도 반복 요청이 많으면 실제 지출이 커질 수 있다. 구독형 도구와 API는 요금과 사용량을 계산하는 방식도 다르므로, 자신이 이용하는 환경의 기준으로 비교해야 한다.
+
+금전적 비용과 함께 사람이 검토하고 수정하는 시간도 따로 기록하면 좋다. 두 항목을 하나의 숫자로 무리하게 합치기보다, 이용 부담과 재작업 부담을 나란히 보는 편이 판단하기 쉽다. 구체적인 가격 계산과 사용량 관리는 §5.5에서 다룬다.
+
+#### 오류의 영향과 검증 가능성을 구분한다
+
+오류의 영향은 틀렸을 때 생기는 결과이고, 검증 가능성은 그 오류를 발견할 수 있는 정도다. 계산 규칙을 테스트하기 쉽더라도, 잘못된 규칙으로 실제 기록을 갱신하면 영향은 클 수 있다. 반대로 화면 배치처럼 영향은 제한적이어도 만족스러운 결과인지 판단하는 데 여러 번의 확인이 필요할 수 있다.
+
+오류의 영향이 크거나 검증이 어려운 작업에서는 후보의 품질을 더 엄격하게 확인하고 별도의 검토 절차를 둔다. 추론 성능이 높은 모델을 골랐다는 이유만으로 검증을 생략할 수는 없다.
+
+### 작업별로 무엇을 우선할까?
+
+GitHub의 모델 비교 문서는 일반적인 개발, 단순하고 반복적인 작업, 깊은 추론과 디버깅 등을 구분한다.[^model-selection-github] 이를 출발점으로 삼되, 실제 선택에서는 각 작업의 완료 기준을 더 구체적으로 정해야 한다.
+
+| 작업 | 우선 확인할 능력 | 충분한 결과의 예 | 부족한 결과의 예 |
+| --- | --- | --- | --- |
+| 질문 | 설명의 정확성, 주어진 자료의 이해, 근거 제시 | 실제 정렬 코드를 따라 우선순위와 예외를 설명한다. | 일반적인 정렬 설명만 하고 현재 코드의 동작을 놓친다. |
+| 코드 작성 | 요구사항 준수, 기존 코드와의 연결, 예외 처리 | 정렬 기능을 추가하고 빈 목록이나 누락값의 동작을 확인한다. | 정상 입력에서만 동작하거나 기존 기능을 바꾼다. |
+| 디버깅 | 원인 가설 수립, 증거 확인, 수정의 타당성 | 중복 반영이 발생하는 경로를 로그와 코드로 확인한다. | 원인을 확인하지 않고 중복된 결과만 화면에서 숨긴다. |
+| 리뷰 | 구체적인 문제 탐지, 발생 조건과 근거 제시 | 같은 경기의 재요청으로 점수가 중복되는 조건을 지적한다. | “예외 처리를 보강하라”는 일반론만 제시한다. |
+
+#### 질문은 필요한 지식과 자료의 범위를 본다
+
+문법이나 짧은 함수의 동작을 묻는 경우에는 빠르고 명확한 설명이 중요할 수 있다. 여러 파일의 설계 의도를 묻거나 연구 내용을 질의하는 경우에는 자료 사이의 관계와 설명의 근거를 확인하는 능력이 더 중요해진다. 예를 들어 논문의 정리를 설명하도록 할 때는 가정과 결론을 구분하는지가 판단 기준이 될 수 있다.
+
+최신 API의 동작처럼 외부 정보가 필요한 질문이라면 해당 문서에 접근할 수 있는 환경도 확인해야 한다. 필요한 자료가 빠진 문제는 모델을 바꾸는 것만으로 해결되지 않을 수 있다.
+
+#### 코드 작성은 변경 범위와 예외 조건을 본다
+
+입출력이 명확한 작은 기능은 제한된 예제로 비교하기 쉽다. 반면 화면, 서버, 저장 구조를 함께 바꾸는 기능은 여러 부분의 연결을 확인해야 한다. 후보를 비교할 때는 코드가 생성되었는지에 더해, 기존 인터페이스를 지키고 요청한 범위 안에서 수정했는지를 본다.
+
+#### 디버깅은 증상과 원인을 구분하는지 본다
+
+오류 메시지 한 줄의 의미를 설명하는 일과, 여러 파일에서 발생하는 상태 불일치를 해결하는 일은 필요한 분석이 다르다. 복잡한 오류에서는 후보가 관측한 사실과 추측을 구분하고, 어떤 증거로 가설을 확인할지 제시하는지가 중요하다.
+
+#### 리뷰는 지적의 구체성과 타당성을 본다
+
+리뷰에서는 문제를 많이 나열하는 것보다, 실제 문제가 되는 위치와 조건을 설명하는지가 중요하다. 정상 코드를 잘못된 문제로 지적하면 불필요한 수정이 생길 수 있다. 알려진 결함을 찾는지와 함께, 근거 없는 지적 때문에 검토 부담이 커지지는 않는지도 살펴본다.
+
+### 같은 작업에서도 모델 선택은 달라진다
+
+앞의 기준을 내전 관리 프로그램의 작업에 적용해 보자. 아래 사례는 특정 모델의 성능을 측정한 결과가 아니라, 후보에서 어떤 능력을 확인할지 보여 주는 예다.
+
+#### 사례 1. 참가자 정렬 기능 추가하기
+
+정렬 규칙이 이미 정해져 있고 한 함수 안에서 구현할 수 있다면, 속도와 비용을 중시하는 후보가 완료 기준을 충족하는지 먼저 확인할 수 있다. 포지션별 순서, 동점, 빈 목록 등의 입력에 대한 예상 결과를 준비하면 비교하기 쉽다.
+
+반면 참가자를 서버에서 여러 페이지로 나누어 불러오는 경우에는 현재 화면의 목록만 정렬해서는 전체 참가자의 순서를 맞출 수 없다. 같은 정렬 기능이라도 데이터 조회와 화면 표시를 함께 살펴봐야 한다. 이 경우에는 여러 파일의 연결과 기존 동작을 이해하는 능력을 후보에서 확인해야 한다.
+
+#### 사례 2. 경기 결과가 두 번 반영되는 오류 고치기
+
+버튼을 빠르게 두 번 누르면 요청이 두 번 전송되는 문제와, 한 번의 요청이 서버에서 중복 처리되는 문제는 화면에 같은 증상을 만들 수 있다. 버튼을 잠그는 수정만으로 모든 경우가 해결된다고 판단해서는 안 된다.
+
+여러 경로가 가능한 상황에서는 관련 코드와 로그를 연결해 원인을 좁히는 능력에 더 큰 비중을 둔다. 수정 후에는 원래 오류가 사라졌는지와 정상적인 결과 입력이 계속 동작하는지를 함께 확인한다.
+
+#### 사례 3. 코드 변경 검토하기
+
+버튼 문구와 여백을 바꾼 변경은 화면 확인과 짧은 코드 검토로 평가할 수 있다. 경기 점수의 갱신 규칙을 바꾼 변경은 기존 기록과 중복 요청까지 고려해야 한다. 같은 “리뷰”라도 두 번째 작업에서는 상태 변화와 예외 조건을 추적하는 능력의 비중이 커진다.
+
+이처럼 작업 유형은 출발점이고, 변경 범위와 오류의 영향, 검증 방법이 실제 우선순위를 결정한다.
+
+#### 후보는 작은 실제 작업으로 비교한다
+
+후보를 좁힐 때는 공식 문서에서 지원 기능과 용도를 확인한다. 예를 들어 Anthropic의 모델 개요는 모델 ID, 지원 기능, 상대적인 응답 지연과 가격 등을 비교하는 항목을 제공한다.[^model-selection-anthropic] 제공사의 용도 설명은 비교의 출발점으로 사용하고, 자신의 작업에서 완료 기준을 충족하는지는 직접 확인한다.
+
+비교할 때는 같은 시작 코드와 요청, 참고 자료, 완료 기준을 준비한다. 가능한 한 같은 도구와 실행 조건을 사용하고, 모델명과 버전, 설정, 확인 날짜를 기록한다. 도구 환경까지 달랐다면 결과를 모델 자체의 차이로만 해석하지 않는다.
+
+기록할 항목은 완료 기준 충족 여부, 작업 완료까지 걸린 시간, 추가 수정 횟수, 검증에 든 노력, 이용 비용 등이다. 한 번의 성공은 해당 사례에서의 가능성을 보여 준다. 반복해서 사용할 모델을 고르려면 자신이 자주 하는 작업과 까다로운 사례에서도 확인할 필요가 있다.
+
+공개 벤치마크는 후보를 좁히는 참고자료가 된다. SWE-bench는 실제 GitHub 이슈와 저장소를 바탕으로 코드 수정 과제를 평가하며, 해결한 과제의 비율을 보고한다.[^model-selection-swebench] 이 결과를 논문 설명이나 모든 코드 리뷰의 정확도로 일반화하기는 어렵다. 내 작업과 평가 과제가 얼마나 비슷한지, 어떤 도구와 실행 조건에서 얻은 결과인지 함께 확인해야 한다.
+
+### 내 작업에 맞는 모델 선택 체크리스트
+
+모델을 선택하기 전에 다음 질문에 답해 보자.
+
+- [ ] 원하는 산출물을 한 문장으로 설명할 수 있는가?
+- [ ] 설명, 코드 수정, 원인 분석, 리뷰 중 무엇을 요구하는지 구체화했는가?
+- [ ] 변경 범위와 필요한 파일·자료·도구를 파악했는가?
+- [ ] 완료 기준과 결과를 확인할 방법을 정했는가?
+- [ ] 틀렸을 때 영향을 받는 데이터와 기능을 파악했는가?
+- [ ] 허용할 수 있는 응답 시간, 이용 비용, 반복 사용량을 정했는가?
+- [ ] 실제 작업과 비슷한 사례로 후보를 비교했는가?
+
+결과가 기준에 못 미쳤다면 다음 선택에 앞서 실패 원인을 확인한다. 필요한 정보가 빠졌는지, 요구사항이 모호했는지, 도구가 필요한 자료에 접근하지 못했는지, 모델이 제공된 조건을 처리하지 못했는지를 구분한다. 그 결과에 따라 자료나 작업 범위를 보완하거나 다른 후보를 비교한다.
+
+모델 선택은 작업의 조건을 설명하고 실제 결과로 확인하는 판단이다. 작업이 바뀌면 필요한 능력과 우선순위도 다시 점검한다.
+
+[^model-selection-openai]: OpenAI, [Model selection](https://developers.openai.com/api/docs/guides/model-selection). 확인일: 2026-10-27. OpenAI의 제공사 가이드로, 품질·지연·사용 빈도와 후보 비교에 관한 판단 틀을 참고했다. 회사 간 성능 순위의 근거로 사용하지 않는다.
+
+[^model-selection-github]: GitHub Docs, [AI model comparison](https://docs.github.com/en/copilot/reference/ai-models/model-comparison). 확인일: 2026-10-27. 작업별 구분을 참고했다. 모델 추천은 Copilot에서 제공되는 모델과 사용 환경에 관한 안내다.
+
+[^model-selection-anthropic]: Anthropic, [Models overview](https://platform.claude.com/docs/en/models/overview). 확인일: 2026-10-27. 공식 사양과 비교 항목을 확인하는 자료다. 제공사의 성능 표현과 독립적인 평가 결과는 구분한다.
+
+[^model-selection-swebench]: SWE-bench, [원본 평가 소개](https://www.swebench.com/original.html), [공식 리더보드](https://www.swebench.com/). 확인일: 2026-10-27. 저장소 이슈 해결 과제와 평가 방식의 범위를 확인하는 데 사용했다.