한국에서 만든 AI 코딩 도구, 어디까지 믿어도 될까

왜 한국산 AI 도구에 의심이 가는가#

새 도구의 품질, 데이터 처리나 지원 이력이 충분히 보이지 않으면 의문을 가질 수 있습니다. 그 의문은 어느 나라에서 만든 제품이든 같은 기준으로 확인하세요. 국적이나 브랜드만으로 안전성이나 성능을 결론내리지 마세요.

이 표는 NIST AI 위험관리 프레임워크의 위험 평가 취지를 참고한 독자용 질문지입니다(2026-11-03 확인). 특정 제품의 안전성이나 인증을 판정한 결과는 아닙니다.

1. 조직 승인을 받고 비밀정보와 고객 데이터를 제외한 과제를 준비합니다.
2. 도구마다 같은 요구사항, 환경, 권한 범위와 수용 기준을 적용합니다.
3. 결과의 diff와 테스트, 한국어 처리, 비용과 실패 사례를 기록합니다.
4. 계약·데이터 처리·지원 조건을 확인하고 미해결 항목이 있으면 공급자에게 묻습니다.
5. 중요한 기준을 충족하지 못하면 도입을 보류하거나 다른 도구를 선택합니다.

신뢰는 점수 하나로 정하지 않습니다. NIST AI 100-1은 신뢰 특성들이 서로 영향을 준다고 설명하며, 정확하지만 설명할 수 없는 시스템, 안전하지만 불공정한 시스템, 부정확하지만 안전하고 투명한 시스템을 모두 바람직하지 않다고 봅니다. 한 항목의 강점이 다른 항목의 약점을 가릴 수 있으므로 충돌하는 결과를 그대로 적습니다.

출신 국가보다 데이터가 어디서 처리되고 조회되는지를 먼저 봅니다. 개인정보 보호법 제28조의8은 개인정보를 국외로 제공(조회되는 경우 포함)하거나 처리를 위탁·보관하는 것을 원칙적으로 금지하고 예외를 한정합니다. 국내 회사의 제품이라도 처리나 보관이 국외에서 일어난다면 같은 조항을 확인하세요. 제품의 출신과 무관하게 처리 위치부터 확인한 뒤 평가합니다.

책임 소재도 확인합니다. NIST AI 100-1은 신뢰가 책임성에 기대고 책임성은 투명성을 전제로 한다고 설명합니다. 공급자가 문제의 원인을 모델, 호스팅, 도구 연결 중 어디에서 찾았는지 설명하지 못한다면 그 설명 부족을 평가 결과에 적습니다. NIST AI 100-1은 잠재적이거나 실제 피해가 감지됐을 때 사람 운영자나 사용자에게 어떻게 알리는지도 투명성의 일부로 다룹니다. 이상 결과를 알리는 경로가 없는 제품은 평가표에서 '확인하지 못함'으로 둡니다.

의심은 합리적입니다: 확인해야 할 다섯 가지#

위 다섯 항목에 대해 필요한 증거와 책임자를 정하세요. 공급자의 설명과 직접 확인한 결과를 구분하고, 확인하지 못한 항목을 빈칸으로 남기는 것이 추측으로 채우는 것보다 낫습니다.

미확인 항목에 따라 결론의 범위도 정합니다. 데이터·권한이나 지원 항목이 확인되지 않았다면 도입 결정을 보류합니다. 한국어나 비용 항목만 미확인이라면 그 항목을 '미확인'으로 명시하고, 민감정보를 뺀 가상 과제로 시험 범위를 제한합니다.

실제 결과는 같은 과제에서 얻은 diff와 테스트 출력으로 확인합니다. 점수 자체보다 점수를 낸 조건이 중요합니다. NIST AI 100-1은 검증을 특정 용도의 요구사항이 충족되었음을 객관적 증거로 확인하는 일이라고 인용합니다. 정확도 측정도 실제 사용 조건을 대표하는 테스트 세트와 방법 설명에 묶으라고 권합니다. 과제 입력, 예상 출력, 테스트 방법이 빠진 결과는 증거로 받지 않습니다.

결과를 읽을 때는 설명과 해석을 구분합니다. NIST AI 100-1에 따르면 설명 가능성은 AI 시스템이 작동하는 메커니즘을 나타내고, 해석 가능성은 출력이 설계된 업무 목적에서 무엇을 뜻하는지를 나타냅니다. 도구가 왜 그렇게 했는지 설명하지 못하더라도, 산출물이 업무에서 무엇을 뜻하는지는 리뷰로 확인할 수 있어야 합니다.

한국어 지원은 화면이 한글로 나오는지보다 같은 글자가 같은 파일로 취급되는지로 확인합니다. 유니코드 UAX #15는 '가'와 'ᄀ+ᅡ'를 정준 동등성의 예로 들고, 정준 동등 문자열은 올바르게 표시될 때 같은 모양과 동작을 가져야 한다고 설명합니다. 두 문자열은 코드 포인트 순서가 다르므로 파일명 비교나 검색에서 차이가 날 수 있습니다.

데이터와 권한은 처리 위치, 보관 기간, 학습 사용 여부, 도구 접근 범위를 나눠 확인합니다. 두 곳의 답이 다르면 계약 문서를 기준으로 삼고, 설정 화면은 실제 상태를 기록하는 근거로만 씁니다. 개인정보를 입력하지 않았다는 사실만으로 안전하다고 보지도 않습니다. NIST AI 600-1은 모델이 학습 데이터의 민감한 정보를 드러내거나, 사용자가 입력하지 않은 개인 정보를 추론할 수 있다고 설명합니다. 같은 문서는 생성형 AI 자체가 프롬프트 주입과 데이터 포이즈닝에 취약하다고도 설명하므로, 외부 입력을 읽는 도구의 권한 범위를 함께 확인합니다.

비용은 구독료 한 줄로 판단하지 않습니다. 같은 과제를 같은 횟수로 수행했을 때 청구 금액을 계산하고, 환율과 부가세가 청구서에 어떻게 반영되는지를 결제 전에 공급자 설명으로 확인합니다.

지원은 문의 창구의 존재보다 장애가 났을 때의 대응을 봅니다. NIST AI 100-1은 제3자 AI 시스템의 실패와 사고에 대비한 대응 절차를 두라고 설명합니다. 한국어 문의가 되는지, 응답 기한이 계약에 적혀 있는지, 장애 공지를 받는 경로가 있는지를 묻습니다.

보안은 공격을 막는 것만이 아닙니다. NIST AI 100-1은 보안이 공격을 피하고 막는 절차뿐 아니라 공격에 대응하고 복구하는 절차까지 포함한다고 설명합니다. 복구 목표 시간과 데이터 사본의 위치를 지원 항목에 넣으세요.

벤치마크보다 중요한 것: 내 저장소에서의 결과#

공개 벤치마크는 참고 자료이지만 내 업무 환경을 그대로 대표하지는 않습니다. 조직이 허용한 합성 또는 공개 저장소에서 같은 버그 수정과 테스트 추가 과제를 수행해 보세요. 실험 조건과 반복 횟수도 함께 남겨야 결과의 범위를 판단할 수 있습니다. 실제 도구 간 동일 과제 결과는 아직 확인되지 않았습니다.

벤치마크의 범위부터 확인합니다. SWE-bench는 실제 GitHub 이슈와 풀 리퀘스트에서 가져온 2,294개 문제를 12개의 인기 Python 저장소에서 모았습니다. 점수는 이 저장소 집합과 언어 범위에 대한 결과이므로, 한국어 요구사항이나 다른 언어로 된 조직 저장소에 그대로 옮길 근거가 되지 않습니다.

과제에는 여러 파일에 걸친 변경을 넣으세요. SWE-bench 논문은 이슈 해결에 여러 함수, 클래스, 파일의 변경을 동시에 이해하고 조율하는 일이 자주 필요하다고 설명합니다. 같은 논문은 이런 과제가 실행 환경과 상호작용하고 매우 긴 문맥을 처리하며, 코드 생성을 넘는 복잡한 추론을 요구한다고 씁니다. 한 파일의 작은 수정만 평가하면 이 차이가 드러나지 않을 수 있습니다.

벤치마크 자체의 품질도 확인합니다. NIST AI 600-1은 모델 검증에 쓰는 테스트 데이터셋에 라벨 오류가 있을 수 있고, 이 오류가 벤치마크의 안정성과 견고성에 영향을 준다고 설명하며, 그 안정성이 많은 실무자가 모델을 고를 때 고려하는 요소라고도 씁니다. 공개 점수를 인용할 때는 데이터셋 버전과 측정 방법이 함께 공개되었는지 봅니다.

점수 한 줄 대신 과제별 기록을 나란히 둡니다. 과제 번호, 입력, 기대 결과, diff 요약, 테스트 결과, 실패 사례, 사람이 고친 횟수를 같은 열에 씁니다. 이 형식이면 어느 쪽이 높은 점수를 받았는지보다 실패가 어디서 나왔는지를 비교할 수 있습니다.

예시(실행하지 않은 가상 설계): 공개 이슈 두 건과 조직 내부 합성 과제 두 건을 같은 열 형식으로 기록하고, 실행 전에 기대 결과를 적어 둡니다.

한국어 지원을 확인하는 방법#

한국어 설정과 한글 처리(입력, 오류 메시지, 리뷰)가 실제로 어떻게 되는지를 확인합니다. 한글 파일명과 조합 입력, 긴 한국어 요구사항, 리뷰에서의 용어 보존을 같은 예제로 시험하세요. 한국어 화면과 실제 과제의 검증 기록은 아직 확보하지 못했습니다.

제안(아직 실행하지 않음): 시험 파일명은 같은 글자를 완성형과 자모 조합형으로 각각 만들어 두고, 생성, 열기, 검색, 비교를 모두 수행합니다. 결과 표에는 두 형태에서 같은 결과가 나왔는지를 적습니다.

오류 메시지는 한국어 설정에서 원인과 조치를 같은 뜻으로 전달하는지 확인합니다. 리뷰 코멘트에서는 원래 요구사항의 용어, 예를 들어 팀 이름과 금액 단위가 바뀌지 않는지 봅니다. 번역된 요약만 보고 리뷰하면 용어 변화를 놓치기 쉽습니다.

긴 한국어 요구사항은 문장마다 검사 항목으로 나눠 기록합니다. 그래야 어느 문장이 구현에서 빠졌는지 추적할 수 있습니다. 2026-11-03 합성 CSV 과제의 독립 검사도 금액 표기와 날짜처럼 항목별 사례로 나뉘어 있어 실패 이유를 특정할 수 있었습니다.

가격·데이터·지원을 확인하는 방법#

가격은 자주 바뀝니다. Mirr Code 요금제, Claude와 Codex의 요금은 이 글에서 아직 확인하지 않았습니다. 실제 결제 금액과 조건은 계정과 지역, 환율·부가세·초과 사용에 따라 각 결제처에서 다시 확인하세요. 데이터 처리와 지원은 해당 계약 및 Mirr Code 지원 안내에서 별도로 확인하세요.

데이터 처리 답변은 개인정보 보호법 제28조의8 제2항이 동의 전에 알리도록 정한 항목을 기준으로 받습니다. 이전되는 항목, 이전되는 국가와 시기·방법, 이전받는 자, 보유 기간, 거부 방법을 질문하고, 답이 빠진 항목은 '확인하지 못함'으로 표시합니다.

개인정보 보호법 제28조의8 제3항은 제2항의 사항이 바뀌면 정보주체에게 알리고 동의를 받도록 정합니다. 그러므로 공급자가 이전 국가나 이전받는 자를 바꾸면 조직은 평가를 다시 합니다.

예외 조항을 근거로 든 답변도 그대로 받아들이지 않습니다. 같은 조 제4항은 예외로 이전하는 경우에도 국외 이전 규정과 제17조부터 제19조, 제5장을 지키고 대통령령이 정한 보호조치를 해야 한다고 정합니다. 공급자가 예외에 해당한다고 말한다면 해당 조항과 보호조치 설명을 함께 요청하세요.

보호위원회는 위반된 국외 이전이 계속되거나 추가 이전이 예상되면 이전 중지를 명할 수 있으므로(제28조의9 제1항), 계약 기간 중 처리 위치가 바뀌는 조건도 확인합니다.

NIST AI 100-1은 익명성, 기밀성, 통제 같은 프라이버시 가치가 AI 시스템의 설계, 개발, 배포 선택을 이끌어야 한다고 설명합니다. 그래서 '데이터를 누가 통제하는지'를 제품 비교표의 한 행으로 둡니다.

학습 데이터의 출처 정보도 요청합니다. NIST AI 100-1은 학습 데이터의 출처를 유지하고 AI의 결정을 학습 데이터의 일부로 귀속할 수 있으면 투명성과 책임성에 도움이 된다고 설명합니다. 학습 데이터가 저작권의 대상이 될 수 있다는 점도 함께 적혀 있으므로, 출처를 밝히지 않는 답은 '확인하지 못함'으로 남깁니다.

NIST AI 100-1은 투명성의 범위가 설계 결정과 학습 데이터에서 배포와 사용자 결정이 언제, 누가 내렸는지까지 이어진다고 설명합니다. 공급자의 변경 이력과 결정 주체를 평가표의 항목으로 둡니다.

가격을 적을 때는 확인한 날짜와 확인한 페이지 주소를 함께 남깁니다. 날짜 없이 '최신 가격'이라고 쓰면 다음 독자가 오래된 금액을 믿을 수 있습니다.

Mirr Code에 적용해 본다면#

위 평가 질문을 Mirr에도 그대로 적용합니다. 실제 과제 화면과 비교 결과는 아직 없습니다.

Mirr Code 소개와 Mirr Code의 한계와 로드맵를 읽고 위의 동일한 질문지를 적용하세요. 가격과 지원 경로는 확인할 수 있지만, 데이터 보존·학습 사용·계약상 조건은 해당 문서와 공급자 답변을 직접 확인하세요. 같은 과제의 결과와 미해결 항목을 적기 전에는 적합성을 결론내리지 않습니다.

이 표를 쓸 때는 자료의 종류를 먼저 나눕니다. 번역된 화면 하나나 점수표는 판단 자료가 되지 못하고, 같은 입력에 대한 파일명, diff, 오류 사례는 한국어 작업의 증거가 됩니다. Mirr 자료로 인용하는 것은 합성 CSV 과제 기록 하나뿐입니다.

표의 '충분하지 않은 자료' 열은 판단을 막는 조건으로 씁니다. 해당 열의 자료만 있다면 그 주장은 보류하고, 필요한 자료를 요청하거나 같은 과제를 직접 수행하는 쪽으로 넘어갑니다.

그래도 Anthropic/OpenAI가 나은 경우#

이미 특정 공급자와 승인된 계약이나 운영 절차가 있거나, 필요한 작업 환경이 그 도구에 갖춰져 있다면 각 공급자의 공식 문서와 실제 계약 조건을 확인해 선택할 수 있습니다. 이는 일반적인 성능 우위 주장이 아닙니다. 양쪽 공식 조건과 실제 과제 결과를 비교해 판단하세요.

기존 계약이 있다는 사실만으로 선택을 정당화하지 않습니다. NIST AI 100-1의 GOVERN 6.1은 제3자 기관과 관련된 AI 위험을 다루는 정책과 절차를 요구합니다. 두 공급자를 비교할 때 권리 침해 위험, 데이터 처리, 사고 대응을 같은 표의 같은 항목으로 놓습니다.

공급자의 기본 설정이 조직의 위험 허용 기준과 맞는지도 따로 봅니다. NIST AI 100-1은 제3자 기술이 복잡하거나 불투명할 수 있고 위험 허용 수준이 도입 조직과 다를 수 있다고 설명합니다. 그러므로 설정 화면을 캡처해 조직이 쓸 플랜과 계정 유형 기준으로 기록합니다.

문제가 생겼을 때 원인을 한 구성 요소에 돌리기 어렵다는 점도 비교 항목입니다. NIST AI 600-1은 생성형 AI 가치사슬에 데이터셋, 사전학습 모델, 소프트웨어 라이브러리 같은 제3자 구성 요소가 많아 행동 문제의 원인을 하나로 특정하기 어렵다고 설명합니다. 계약서에 장애와 오류의 책임 범위를 어디까지 적을지 확인하세요.

예시(실행하지 않은 가상 비교표): 두 공급자 각각에 같은 과제의 수용 검사를 적용하고, 데이터 처리 답변과 사고 대응 절차를 같은 칸에 적습니다.

실제 작은 과제의 성공과 실패를 함께 읽어 보기#

Mirr에도 같은 기준을 적용하면 성공한 마지막 화면만 소개해서는 충분하지 않습니다. 2026-11-03 KST에 기존 macOS arm64 Mirr v0.6.15로 수행한 합성 CSV 집계 과제에서는 처음 생성한 테스트 13개가 모두 통과했습니다. 하지만 원래 요구사항으로 준비한 별도 수용 검사 아홉 건 가운데 여섯 건이 실패했습니다. 허용하지 않은 금액 표기를 받아들이고 요청에 없던 연도 범위를 제한한 문제가 있었습니다. 따라서 처음 테스트가 초록이었다는 설명만으로 정확성을 주장할 수 없습니다.

담당자는 그 실패와 추가로 명확히 한 입력 조건을 별도 수정 요청에 전달했습니다. 회귀 검사를 추가한 뒤에는 17개 통과·아홉 개 실패가 관찰됐고 구현 수정 후 26개가 통과했습니다. 마지막 별도 수용 검사 아홉 건과 저장 결과 대조도 통과했습니다. 이 기록에서 모델이 독립적으로 모든 누락을 찾아냈다고 말하면 사실과 다릅니다. 외부 검토와 추가 지시가 결과를 바꿨으며 평가자는 그 부담도 결과의 일부로 읽어 보세요.

대상은 따옴표 없는 세 열의 작은 합성 CSV였습니다. 실제 고객 작업, 일반 CSV 파서나 엑셀·HWPX 처리의 증거는 아닙니다. 해당 예제의 26개 테스트를 사이트 전체 검사나 일반 성능 수치로 바꾸지 않습니다. 설치, GUI·IME, 사람이 응답하는 승인과 복구, 모델 이용 권리나 비용도 이 과제로 확인되지 않았습니다.

이 기록은 과신과 과소평가를 함께 경계해야 한다는 점도 보여 줍니다. NIST AI 600-1은 사람이 생성형 AI 결과를 지나치게 신뢰할 수 있는 한편, 전문가가 AI를 불필요하게 꺼려 유용한 활용을 놓칠 수 있다고 설명합니다. 한 번의 실패로 도구 전체를 배제하는 결정과 처음의 초록 테스트만으로 신뢰하는 결정은 모두 같은 근거 기준을 따라야 합니다. 앞의 검증 정의에 비추면, 구현자가 만든 테스트의 통과는 독립 증거로 쓰기 어렵습니다.

예시(실행하지 않은 가상 계획): 다음 회차에서는 같은 과제를 두 번 이상 수행해 결과 차이를 적고, 결과 한 번으로 평가하지 않도록 하는 방법을 시험해 볼 수 있습니다.

신뢰의 정도를 정할 때는 한 번의 결과로 도구 전체를 판단하지 말고, 같은 기준을 반복 과제로 적용해 봅니다. 과신과 과소평가 둘 다에 같은 근거를 요구하면, 국적이 아니라 실제로 확인된 동작에 대한 판단으로 정리됩니다. 같은 조건을 몇 번 반복했을 때 결과가 흔들리는지, 같은 방향으로 나오는지를 보는 것이 일반화를 막는 최소한의 습관입니다.

관련#

• Mirr Code 소개
• Mirr Code의 한계와 로드맵
• AI 코딩 도구 비교

편집 메모 (2026-11-02): 주장과 증거의 대응표, 한국어·벤치마크·데이터 판단 FAQ를 보충했습니다. 국적이나 특정 공급자의 일반 성능 우위를 주장하지 않습니다.