한 줄 정의
FIM completion은 Fill In the Middle completion의 줄임말이고, 앞부분과 뒷부분을 같이 보고 가운데 빠진 내용을 채우는 완성 방식이야. 일반적인 왼쪽에서 오른쪽으로 이어 쓰기 completion은 커서 앞 문맥만 보는 쪽에 가깝지만, FIM은 prefix와 suffix 사이에 들어갈 코드를 만들 수 있다는 점이 달라.
DeepSeek API 문맥에서는 이 차이가 더 구체적이야. 2026년 5월 7일 기준 공식 문서는 이 기능을 /completions 베타 경로로 두고, base_url="https://api.deepseek.com/beta"와 model="deepseek-v4-pro"를 요구해. 이건 messages 배열을 보내는 Chat Completions가 아니라, prompt와 선택적 suffix를 보내는 별도 호출 경로야.
어떻게 작동하나
작동 방식은 단순해. 호출하는 쪽이 먼저 앞 문맥을 prompt에 넣고, 뒤에 이미 존재하는 문맥을 suffix에 넣어. 모델은 둘 사이에 자연스럽게 들어갈 텍스트를 choices[0].text로 돌려줘. DeepSeek 예시는 def fib(a):를 앞에 두고 return fib(a-1) + fib(a-2)를 뒤에 둔 다음, 가운데 함수 본문을 채우게 한다. 코드 편집기에서 함수 내부, 조건문 본문, 닫는 괄호 앞 줄을 채울 때 이런 모양이 나온다.
두 번째 장면은 문서나 템플릿 편집이야. 앞에는 보고서 도입 문단이 있고 뒤에는 이미 정해진 결론 문단이 있을 때, 중간 설명을 채우는 식으로 쓸 수 있어. 다만 DeepSeek 문서는 이 기능의 최대 토큰을 4K로 제한하고 베타 base URL을 요구해. 그러니까 저장소 전체를 다시 설계하는 기능이라기보다, 양쪽 문맥이 이미 정해진 빈칸을 채우는 API 기능으로 보는 편이 정확해.
FIM이라는 개념 자체는 DeepSeek 전용은 아니야. 2022년 7월 28일 공개된 Efficient Training of Language Models to Fill in the Middle 논문은 자기회귀 언어 모델도 학습 데이터에서 가운데 span을 뒤로 옮기는 변환을 쓰면 infill 능력을 배울 수 있다고 설명해. API 사용자는 그 학습 방식을 직접 만지는 게 아니라, 그 결과로 노출된 prompt/suffix 호출 모양을 쓰는 거야.
왜 중요한가
코드 완성에서 이 차이는 꽤 실무적이야. 커서 뒤에 이미 return, 타입 선언, 닫는 괄호, 다음 테스트 코드가 있는데 모델이 그걸 못 보면, 그럴듯하지만 이어 붙이면 깨지는 제안을 내기 쉬워. 중간 채우기 방식은 뒤쪽 문맥까지 조건으로 받으니 “이 사이에 들어가야 하는 코드”라는 문제가 더 선명해져.
문서에서 이 용어가 나오면 먼저 Chat Completions와 분리해서 봐야 해. Chat Prefix Completion은 마지막 assistant 메시지에 prefix: True를 넣어 답변의 시작 모양을 고정하는 기능이고, 이 항목은 /completions에서 prompt와 suffix 사이를 채우는 기능이야. 둘 다 베타 문서에 있지만 입력 계약이 달라. SDK에서 같은 OpenAI 호환 클라이언트를 쓴다고 해서 같은 API로 보면 로그와 재시도 설계가 헷갈려.
또 하나는 모델 기사 해석이야. 후보 근거에는 2025년 1월 20일 DeepSeek-R1 릴리스와 R1 저장소가 들어 있지만, 이 기능의 직접 근거는 DeepSeek의 FIM 가이드와 /completions API 참조야. R1이 추론 모델로 공개됐다는 사실과, 현재 DeepSeek API에서 FIM 베타가 어떤 base URL과 모델명을 요구하는지는 다른 판단이야.
주의해서 볼 점
첫째, suffix가 선택 사항이라고 해서 FIM의 장점이 항상 살아나는 건 아니야. 뒤 문맥을 주지 않으면 사실상 앞 문맥만 보고 이어 쓰는 completion에 가까워져. 코드 편집기에 붙일 때는 커서 뒤쪽의 닫는 블록, 함수 시그니처, 테스트 기대값을 같이 보내야 이 기능을 쓰는 이유가 생긴다.
둘째, 베타 기능이라는 운영 조건을 빼면 안 돼. DeepSeek 문서는 베타 base URL을 따로 요구하고, API 참조는 현재 가능한 모델 값을 deepseek-v4-pro로 보여줘. DeepSeek V4나 legacy 별칭 정책은 바뀔 수 있으니, 배포 코드에서는 모델명과 endpoint를 설정값으로 분리해 두는 편이 낫다.
셋째, 이 방식은 에이전트가 계획을 세우고 도구를 실행하는 전체 흐름이 아니야. 가운데 텍스트를 채우는 좁은 완성 기능이야. 자동 수정, 테스트 실행, PR 작성까지 기대한다면 FIM 하나가 아니라 코드 인덱싱, diff 적용, 실행 로그, 승인 절차가 따로 필요해.