코히어, 폐쇄형 코딩 AI에 맞설 오픈소스 모델 ‘노스 미니 코드’ 공개

• 코히어가 첫 에이전틱 코딩 모델 ‘노스 미니 코드’를 오픈소스로 공개함

  • 개발자가 자체 환경에서 돌릴 수 있는 코딩 모델을 내세워, 오픈AI·앤트로픽·구글 같은 폐쇄형 대형언어모델(LLM) 의존도를 낮추려는 기업 수요를 겨냥함
  • 지난 4월 독일 알레프알파와 결합하며 내세운 소버린 AI 전략을 개발자 도구 영역으로 확장한 흐름으로 읽힘

• 스펙만 보면 ‘작게 돌리는 큰 모델’ 쪽에 가깝다

  • 전체 30B 파라미터, 활성 3B 파라미터의 혼합전문가(MoE) 구조
  • 컨텍스트 길이 256K, 최대 생성 길이 64K
  • 라이선스는 아파치 2.0이고, 허깅페이스 가중치 다운로드·코히어 API·모델 볼트·오픈라우터 등을 통해 사용 가능
  • 최소 하드웨어는 FP8 기준 H100 1개로 제시됨

• 코히어가 노린 사용처는 단순 코드 자동완성이 아님

  • 코드 생성뿐 아니라 에이전틱 소프트웨어 엔지니어링, 터미널 작업, 코드 리뷰, 시스템 아키텍처 파악에 최적화했다고 설명함
  • 요즘 코딩 에이전트가 저장소 탐색, 명령 실행, 테스트 수행까지 맡는 걸 보면 꽤 현실적인 포지셔닝임
  • 이 과정에서 소스코드, 개발 로그, 내부 시스템 구조가 모델과 직접 연결되기 때문에 기업 입장에선 보안과 통제가 중요해짐

• 성능 홍보 포인트는 속도와 비용 효율임

  • 코히어 내부 테스트 기준, 노스 미니 코드는 동일 하드웨어와 동시성 조건에서 데브스트랄 스몰 2보다 최대 2.8배 높은 출력 처리량을 기록함
  • 토큰 간 지연 시간도 30% 우위였다고 밝힘
  • 다만 첫 토큰 생성 시간은 일부 조건에서 데브스트랄 스몰 2가 앞섰다고 함. 즉 “항상 더 빠르다”라기보단 처리량 쪽 강점을 강조한 셈

• 기업 도입 기준은 벤치마크 점수 하나로 끝나지 않음

  • 코딩 모델은 장기 컨텍스트 처리, 저장소 이해도, 테스트 자동화, 보안 취약점 탐지, 개발 도구 연동성까지 같이 봐야 함
  • 특히 내부망이나 온프레미스에서 운용하려는 조직은 추론 로그가 어디에 남는지, 기존 개발 도구와 얼마나 안정적으로 붙는지를 더 민감하게 볼 수밖에 없음
  • 코히어가 오픈코드 호환성을 강조한 것도 실제 개발 워크플로 안에 넣기 위한 포석으로 보임

• 오픈소스 코딩 모델 경쟁은 더 빡세질 가능성이 큼

  • 폐쇄형 진영에선 오픈AI, 앤트로픽, 구글이 코딩 에이전트 시장을 키우고 있음
  • 개방형 진영에선 메타, 미스트랄, 딥시크 같은 모델들이 계속 압박 중임
  • 코히어는 여기에 “기업이 직접 통제 가능한 코딩 에이전트”라는 각도로 끼어든 셈이라, 개발 조직 입장에선 선택지가 하나 더 늘어난 상황임

---

기술 맥락

• 코히어의 선택은 단순히 코딩 모델을 하나 더 낸 게 아니라, 모델 운영 위치를 기업 쪽으로 당겨오려는 전략이에요. 코딩 에이전트는 저장소와 터미널, 테스트 로그를 직접 다루기 때문에 일반 챗봇보다 훨씬 민감한 데이터를 만지거든요.

• 혼합전문가 구조를 쓴 이유도 비용과 성능의 타협점 때문이에요. 전체 모델은 30B지만 실제 활성 파라미터는 3B라서, 큰 모델의 여지를 남기면서도 추론 부담을 낮추려는 설계로 볼 수 있어요.

• 256K 컨텍스트는 대형 저장소를 읽는 코딩 에이전트에서 꽤 중요한 숫자예요. 함수 하나만 보는 자동완성과 달리, 에이전트는 여러 파일의 의존성과 테스트 흐름을 같이 봐야 하니까요.

• 다만 기업이 실제로 쓰려면 벤치마크보다 개발 도구 연동성이 더 중요해질 수 있어요. 코드 리뷰, 테스트 실행, 취약점 탐지까지 자연스럽게 이어져야 개발자가 “쓸 만하다”고 느끼거든요.