사내 특허팀 필독: 소스코드 없이 SW 특허 침해 증명하기: AI를 활용한 SW 분석 실무 A to Z

 

소프트웨어 특허 침해, 어떻게 증명할 것인가? 이 가이드는 최신 리버스 엔지니어링 기법과 LLM(대규모 언어 모델)을 결합하여, 눈에 보이지 않는 코드 속에서 결정적 증거를 찾아내고, 법적 효력을 갖는 '클레임 차트'를 작성하는 전 과정을 사내 특허 전문가의 눈높이에서 안내합니다.

 

안녕하세요, 특허 담당자님! 경쟁사 소프트웨어가 우리 특허를 침해한 것 같은데, 소스코드 없이는 증명할 방법이 없어 막막했던 경험, 혹시 없으신가요? 소프트웨어 특허 침해 분석은 종종 '범죄 현장 없는 수사'에 비유되곤 합니다. 시장에 배포된 실행 파일이라는 유일한 단서만으로 기술의 비밀을 역추적해야 하니까요.

이 과정은 전통적으로 막대한 시간과 고도의 전문성을 요구했습니다. 하지만 이제 대규모 언어 모델(LLM)이 이 게임의 판도를 바꾸고 있습니다. LLM은 단순한 조수를 넘어, 방대한 문서를 구조화하는 Claude, 멀티모달 분석이 가능한 Gemini, 논리적 초안 작성에 뛰어난 ChatGPT 등 각자의 강점을 가진 전문 분석 파트너가 될 수 있습니다.

이 가이드는 변리사님이나 특허팀 담당자님께서 직접 리버스 엔지니어링을 수행하는 것이 아니라, 그 과정을 깊이 이해함으로써 외부 기술 전문가와 효과적으로 소통하고, 소송의 승패를 좌우할 증거의 질을 관리하는 역량을 갖추는 것을 목표로 합니다. 그럼, 지금부터 AI와 함께하는 특허 침해 분석의 세계로 들어가 볼까요? 😊

Notice: 안내 및 주의사항

• 본 가이드는 교육 목적으로만 제공되며 법률 자문을 대체하지 않습니다. 실제 분석에 착수하기 전, 해당 관할의 지식재산권 전문 변호사와 반드시 상담하십시오.
• 리버스 엔지니어링의 허용 범위는 국가별 법령 및 계약(EULA 등)에 따라 다릅니다. 적용 가능한 규정을 사전에 서면으로 법무팀과 확인하십시오.
• 기밀 코드·자산을 외부 LLM 서비스로 전송하지 마십시오. 불가피한 경우 온프레미스(사내 구축형) 운영, DLP(데이터 유출 방지), 접근 통제, DPA(데이터 처리 계약) 등 계약적 보호장치를 갖춘 뒤 진행하십시오.
• LLM 출력에는 오류나 환각(Hallucination)이 포함될 수 있습니다. 모델의 추론은 전문가 검증과 교차 기술 증거로 독립 확인되기 전까지 미검증 정보로 취급하십시오.

 

분석 시나리오: 가상 특허 침해 추적

이해를 돕기 위해 가상의 특허와 침해 혐의 제품을 설정해 보겠습니다.

분석 개요

• 가상 특허: US 15/987,654 "효율적인 파일 동기화를 위한 데이터 처리 및 전송 방법"
• 핵심 기술: 파일 변경을 ① 실시간으로 감지하여, 데이터를 ② 압축한 뒤, ③ AES-256으로 암호화하여 서버로 ④ 전송하는 순차적 프로세스.
• 분석 대상: 클라우드 서비스 'SyncSphere'의 윈도우 클라이언트 `SyncSphere.exe`

 

1단계: 법적 검토 및 포렌식 준비 (Legal & Forensic Pre-flight)

본격적인 기술 분석에 앞서, 모든 과정의 법적, 절차적 정당성을 확보하는 것이 무엇보다 중요합니다. 이 단계에서 확보된 증거의 신뢰성이 소송 전체의 향방을 결정하기 때문입니다.

⚖️ Legal Pre-flight: 분석 전 필수 체크리스트

• 분석 권한 (Authorization): 분석 대상 소프트웨어의 EULA(최종사용자 라이선스 계약)를 검토하여 리버스 엔지니어링 금지 조항의 유효성 및 법적 리스크를 확인합니다. (미국 DMCA, 한국 저작권법 등 관할권별 법령 확인 필수)
• 변호사-의뢰인 비밀유지 특권 (Attorney-Client Privilege): 분석이 소송을 염두에 둔 법률 자문의 일환으로 진행됨을 명확히 하여, 분석 과정에서 생성된 자료가 보호받을 수 있도록 합니다.
• 변호사 승인 (Counsel Sign-off): 특히 네트워크 트래픽 감청, 메모리 덤프와 같이 통신비밀보호법 등 법적 민감성이 높은 분석 행위는 사전에 법률 자문을 구하고 서면 승인을 받아야 합니다.
• 개인정보보호 (Data Privacy): 동적 분석 중 개인정보(PII)가 수집될 가능성을 평가하고, GDPR, PIPA 등 관련 법규 준수를 위해 이를 최소화하거나 비식별화할 방안을 마련합니다.

법적 검토가 완료되면, 포렌식의 기본 원칙인 '증거 보전 절차(Chain of Custody)'를 시작합니다. `SyncSphere.exe` 파일의 SHA-256 해시값을 계산하여 '디지털 지문'을 확보하고, 분석에 사용할 모든 도구의 버전과 OS 환경 정보를 상세히 기록해야 합니다. 이 모든 내용은 '포렌식 매니페스트(Forensic Manifest)'에 기록되어 증거의 무결성과 재현성을 보장하는 첫걸음이 됩니다.

 

2단계: 정적 분석 (Static Analysis) – 코드의 청사진 확보하기

정적 분석은 프로그램을 실행하지 않고 내부 구조를 파헤치는 과정입니다. 이를 통해 프로그램이 특허 기술을 수행할 '잠재적 능력(capability)'이 있는지 확인하고 침해 가설을 세웁니다.

초기 정찰 (Reconnaissance)

본격적인 코드 분석에 앞서, 세 가지 정찰 기법으로 분석의 방향을 설정합니다.

1. 문자열 추출 (strings): strings -a SyncSphere.exe > strings.txt 명령어로 파일 내 하드코딩된 텍스트를 모두 추출합니다. 여기서 "zlib", "AES", "OpenSSL" 같은 키워드는 압축/암호화 기능의 존재를 강력히 시사하는 첫 단서가 됩니다.
2. PE 구조 분석 (PE-bear): PE 분석 도구로 `SyncSphere.exe`를 열어 임포트 주소 테이블(IAT)을 확인합니다. IAT는 프로그램이 Windows로부터 어떤 기능을 빌려 쓰는지 보여주는 '외부 기능 의존성 목록'입니다. `kernel32.dll`의 파일 API(예: `CreateFileW`)는 파일 감지 기능(청구항 a)을, `advapi32.dll`의 암호화 API(예: `CryptEncrypt`)는 암호화 기능(청구항 c)의 잠재력을 보여줍니다.
3. 라이브러리 시그니처 스캔 (signsrch): 만약 zlib, OpenSSL 같은 라이브러리가 정적으로 링크(코드 내부에 포함)되었다면 IAT에 나타나지 않습니다. signsrch 같은 도구는 알려진 라이브러리의 고유 코드 패턴(시그니처)을 스캔하여 이를 찾아낼 수 있습니다.

📝 노트: 초기 정찰 단계에서의 LLM 활용 심화

초기 정적 분석(정찰 및 가설 수립)은 본격적인 디컴파일에 앞서 분석의 방향을 설정하기 위한 단서를 수집하는 단계입니다. 이 과정은 문자열 추출, PE 구조 분석, 라이브러리 시그니처 스캔으로 구성됩니다.

이 단계에서 LLM을 활용하면 방대한 출력 데이터를 효율적으로 정리할 수 있습니다. 예컨대 strings_output.txt는 수만~수백만 줄에 이를 수 있는데, LLM은 이를 자동 요약하여 특허 청구항 (b), (c)와 직접 관련된 키워드(압축, 암호화, 서버 통신)와 그 주변 맥락만 추출할 수 있습니다.

또한 LLM은 PE-bear/DumpPE 출력에서 가져온 임포트 API를 정규화·중복 제거하고, 이를 파일 I/O와 암호화 기능군으로 분류한 뒤, 각 항목을 청구항 요소에 매핑합니다. 예를 들어, CreateFileW, ReadFile, WriteFile 등은 (a) ‘파일 변경 감지 역량’에, CryptEncrypt나 bcrypt 계열 함수는 (c) ‘암호화 역량’에 연결할 수 있습니다. 이어서 요소별 간결한 진술문을 작성하고, “임포트가 존재하더라도 런타임 사용은 불명확하다”와 같은 불확실성 및 보강 필요 증거도 명시할 수 있습니다.

마찬가지로 LLM은 Signsrch 탐지 결과를 정규화하고 중복된 시그니처를 제거한 뒤, 각 시그니처를 추정 라이브러리·버전에 매핑합니다. 이를 통해 정적 링크 여부를 설명하고, 탐지된 결과를 청구항 (b) 압축(zlib), (c) 암호화(OpenSSL/LibreSSL/AES) 단계에 연결할 수 있습니다.

*독자의 가독성을 위해 이러한 작업에 필요한 구체적인 프롬프트 예시는 본문에서 생략하였습니다.

심층 분석 (Deep Dive with Ghidra & LLM)

정찰로 얻은 단서를 바탕으로, Ghidra나 IDA Pro 같은 디컴파일러로 코드의 실제 로직을 분석합니다. 'AES' 같은 문자열을 참조 역추적(Cross-Referencing)하여 암호화 로직이 담긴 핵심 함수(가령, `process_file_for_upload`)를 찾아내고, 디컴파일된 의사 코드(Pseudo-code)에서 `compress_data` 함수의 출력값이 `encrypt_data` 함수의 입력값으로 직접 전달되는지 확인합니다. 이 데이터 흐름이 특허의 순차적 단계를 증명하는 핵심 증거가 됩니다.

LLM 프롬프트 예시: 코드 로직 분석 및 구조화된 답변 요청

복잡한 의사 코드를 법률가가 이해할 수 있는 명료한 언어로 번역하고, 분석 보고서의 초석을 다지기 위해 LLM에 다음과 같이 체계적으로 요청할 수 있습니다.

# 역할
당신은 특허 분석을 지원하는 C++ 리버스엔지니어링 전문가입니다.

# 입력
아래는 Ghidra로 디컴파일한 `process_file_for_upload` 함수의 의사코드입니다.
[Ghidra 의사코드 삽입]

# 과업
1. 이 함수의 데이터 처리 파이프라인(단계, 순서)을 정확히 기술하십시오.
2. 압축 결과가 암호화의 직접적인 입력으로 사용되는지 확인하고, 이를 뒷받침하는 변수를 명시하십시오.
3. 이 함수가 '압축 후 암호화' 구조를 따르는지 명확히 결론 내리십시오.
4. 결과를 아래 JSON 형식으로 출력하십시오.

# 출력 형식 (JSON)
{
  "finding_text": "함수 동작에 대한 명확한 설명",
  "evidence_refs": ["증거가 되는 코드 라인 인용"],
  "confidence_score": 0.9,
  "uncertainties": ["코드만으로 확정할 수 없는 부분"]
}
        

➡️ 예상되는 LLM 결과물 (JSON):

{
  "finding_text": "이 함수는 입력 데이터를 zlib으로 압축한 뒤, 압축된 결과물을 그대로 AES 암호화 함수의 입력으로 사용하고, 최종적으로 서버로 전송합니다. 압축은 암호화보다 명백히 선행되며, 데이터 흐름이 직접적으로 연결되어 있습니다.",
  "evidence_refs": [
    "compressed_result = compress_data_with_zlib(original_data);",
    "final_payload = encrypt_data_with_aes(compressed_result->data, compressed_result->size);"
  ],
  "confidence_score": 0.9,
  "uncertainties": [
    "사용한 AES 운영 모드(CBC/GCM 등)나 키 출처는 이 코드만으로는 확인할 수 없습니다."
  ]
}
        

주의하세요! 정적 분석의 한계
정적 분석 결과는 어디까지나 동적 검증으로 입증되어야 할 '가설'입니다. 코드에 특정 기능이 존재한다고 해서, 그 기능이 실제 실행 시 특허와 동일한 방식으로 사용된다고 단정할 수 없습니다. 또한, 코드 난독화(Obfuscation)나 패킹(Packing)이 적용된 경우 정적 분석만으로는 실제 로직을 파악하기 매우 어렵습니다.

 

3단계: 동적 분석 (Dynamic Analysis) – 실제 동작 포착하기

동적 분석은 정적 분석에서 세운 가설이 '실제로 실행(action)'되는지를 객관적인 로그와 데이터를 통해 증명하는 단계입니다. 이 과정은 통제된 환경(가상 머신 또는 루팅된 물리 기기)에서 수행하는 것이 중요합니다.

1. 실시간 감지 검증 (Process Monitor): ProcMon으로 `SyncSphere.exe`의 파일 시스템 접근을 모니터링합니다. 동기화 폴더에 파일을 저장하는 순간, `SyncSphere.exe`가 즉시 관련 파일 이벤트를 발생시키는지 타임스탬프를 통해 확인합니다. 이 로그가 '실시간 감지'의 직접 증거가 됩니다.
2. 순서 및 데이터 흐름 검증 (x64dbg): 디버거(x64dbg)를 실행 중인 `SyncSphere.exe`에 연결하고, 2단계에서 찾은 압축 및 암호화 함수 주소에 브레이크포인트(breakpoint)를 설정합니다. 파일을 동기화할 때, ① 압축 함수가 먼저 멈추고, ② 암호화 함수가 나중에 멈추는지 순서를 확인합니다. 가장 결정적으로, 압축 함수가 반환하는 출력 버퍼의 메모리 주소와 크기가 암호화 함수의 입력 버퍼와 정확히 일치하는지 확인합니다. 이것이 '압축 후 암호화'를 증명하는 '결정적 증거(smoking gun)'입니다.
3. 암호화 후 전송 검증 (Wireshark & Burp Suite): Wireshark로 프로그램이 생성하는 네트워크 트래픽을 캡처합니다. 전송 데이터의 엔트로피(Entropy)를 분석했을 때, 잘 암호화된 데이터는 무작위성에 가까워 엔트로피가 이론적 최댓값(8.0)에 근접합니다. 이는 데이터가 암호화 후 전송되었음을 뒷받침하는 강력한 정황 증거입니다.

LLM 프롬프트 예시: 다중 로그 상관관계 분석

ProcMon, x64dbg, Wireshark에서 나온 각기 다른 로그들을 종합하여 하나의 일관된 사건으로 재구성하도록 LLM에 요청할 수 있습니다.

# 역할
당신은 디지털 포렌식 전문가입니다.

# 입력
[타임스탬프가 포함된 ProcMon, x64dbg, Wireshark 통합 로그 삽입]

# 과업
1. 모든 로그를 시간순으로 재구성하여 타임라인을 만드십시오.
2. "파일 저장 → 압축 함수 호출 → 암호화 함수 호출 → 네트워크 전송"의 인과 관계가 성립하는지 분석하십시오.
3. x64dbg 로그에서 압축 함수의 출력 버퍼와 암호화 함수의 입력 버퍼가 일치하는지 확인하십시오.
4. 위 분석을 종합하여, 특허 침해 가설을 뒷받침하는 최종 진술문을 작성하십시오.
        

알아두세요! 동적 분석의 현실적 장애물
상용 소프트웨어는 분석을 방해하기 위해 여러 보안 기법을 사용합니다. 먼저 SSL Pinning은 앱이 특정 서버 인증서를 내부에 고정시켜, 중간자 공격(MITM) 방식으로 패킷을 가로채려 할 때 인증서 불일치로 연결을 거부합니다. 따라서 평문 데이터를 보려면 단순 패킷 캡처만으로는 부족합니다. 이때 Frida 같은 동적 계측 도구를 활용하면 앱 내부의 함수 호출을 직접 관찰하거나 조작하여, 암호화되기 전의 데이터를 확인할 수 있습니다. 그러나 많은 상용 앱은 안티-디버깅(Anti-debugging), 안티-후킹(Anti-hooking) 기법을 추가해 이러한 도구의 접근 자체를 탐지하고 차단합니다. 예컨대 디버거가 연결되면 실행을 중단하거나 다른 경로로 분기하고, 후킹 시도를 차단하여 분석이 무력화됩니다. 따라서 SSL Pinning, MITM 회피, 안티-분석 기술을 이해하고 대응하려면 고도의 전문 지식과 합법적 절차가 필요합니다.

 

4단계: 클레임 차트 작성 – 증거를 법률 주장으로 변환

클레임 차트는 특허 소송의 성패를 좌우하는 가장 핵심적인 법률 문서입니다. 지금까지 수집한 기술적 증거들을 특허의 각 구성요소와 일대일로 명확하게 대응시키는 '증거 대조표'로, 판사나 배심원 같은 비전문가도 침해 사실을 쉽게 이해하도록 돕는 다리 역할을 합니다.

LLM 프롬프트 예시: 클레임 차트 서술문 초안 작성

분석가가 수집한 증거(facts)를 제공하면, LLM이 법률 문서에 적합한 문장(prose)을 구성하도록 할 수 있습니다.

# 페르소나 및 임무
당신은 특허 소송 기술 전문가입니다. 제공된 증거들을 사용하여 클레임 차트의 '침해 증거' 항목 초안을 객관적이고 사실에 입각하여 작성해주십시오. 각 증거는 해당 레이블(예: [증거 A])로 명확히 인용해야 합니다.

# 맥락 정보
- 특허 번호: US 15/987,654
- 청구항 1(c): ...압축된 데이터를 AES-256 암호화 알고리즘으로 암호화한 후, 원격 서버로 전송하는 단계...

# 입력 데이터 (MVE - 최소 증거 패키지)
- [증거 B (Ghidra)]: `encrypt_data(compressed_result->data, ...)`
- [증거 C (x64dbg)]: Input buffer: `0xDCBA0000`, size: 150 for `AES_256_encrypt`
- [증거 D (Wireshark)]: Payload entropy: 7.98 bits/byte

# 과업
청구항 (c)에 대해, "SyncSphere는 ... 방식으로 이 단계를 수행합니다."로 시작하는 문단을 작성하고, 제공된 증거로 주장을 뒷받침하십시오.
        

최종 클레임 차트 (예시)

특허 US 15/987,654의 청구항 1 구성요소	침해 제품 ('SyncSphere' 클라이언트 v2.5.1)의 해당 구성요소 및 증거
(a) 로컬 지정 폴더 내의 파일 생성 또는 수정을 실시간으로 감지하는 단계;	SyncSphere는 OS 수준의 파일 시스템 모니터링 기능을 통해 이 단계를 수행합니다. 사용자가 지정된 'SyncSphere' 폴더 내에서 파일을 수정하면, 해당 행위는 즉각적으로 감지되어 후속 데이터 처리 절차를 촉발합니다. [증거 A: Process Monitor 로그]는 사용자가 파일을 수정한 시점(14:01:15.123) 직후 SyncSphere.exe 프로세스가 해당 파일에 접근했음을 명백히 보여줍니다.
(b) 상기 감지된 파일을 원격 서버로 전송하기 전에 데이터 압축 알고리즘을 먼저 적용하는 단계;	SyncSphere는 zlib 기반의 압축 라이브러리를 이용하여 이 단계를 수행합니다. [증거 B: Ghidra 디컴파일 코드]는 파일 처리 함수 내에서 `compress_data_with_zlib` 함수가 데이터 처리의 첫 번째 단계로 호출됨을 보여줍니다. [증거 C: x64dbg 디버거 로그]는 이러한 코드의 실제 실행 순서를 직접적으로 증명합니다. 로그에 따르면, 암호화 함수보다 압축 함수(zlib.dll!compress)가 명백히 먼저 호출되었습니다.
(c) 상기 압축된 데이터를 AES-256 암호화 알고리즘을 적용하여 암호화한 후, 원격 서버로 전송하는 단계를 포함하는 것을 특징으로 하는 방법.	SyncSphere는 압축 단계의 출력물을 AES-256 암호화 함수의 입력으로 직접 전달함으로써 이 단계를 수행합니다. [증거 B: Ghidra 디컴파일 코드]는 `compress_data_with_zlib` 함수의 반환값이 `encrypt_data_with_aes` 함수의 인자로 직접 전달되는 데이터 흐름을 보여줍니다. [증거 C: x64dbg 디버거 로그]는 이 데이터 흐름을 메모리 수준에서 확증합니다. 압축 함수의 출력 버퍼 주소(예: 0xDCBA0000)와 크기(예: 150 bytes)가 `libcrypto.dll!AES_256_cbc_encrypt` 함수의 입력 버퍼와 정확히 일치했습니다. 암호화된 데이터의 후속 전송은 [증거 D: Wireshark 엔트로피 분석]을 통해 뒷받침됩니다. 분석 결과, 'SyncSphere' 서버로 전송되는 데이터 패킷의 페이로드(payload)가 7.98 bits/byte의 높은 엔트로피를 보여, 이는 AES-256 암호화 데이터의 통계적 특성과 완벽하게 부합합니다.

 

5단계: 전문가 검증 및 최종 보고 – 증거에 법적 효력을 부여하다

AI가 아무리 발전해도 법적 책임을 질 수는 없습니다. 모든 분석 과정과 결과물은 최종적으로 인간 전문가의 검토와 승인을 거쳐야 합니다. LLM이 생성한 모든 산출물은 '해석을 돕는 보조 자료'일 뿐, 그 자체가 증거는 아닙니다. 이 단계는 AI가 정리한 데이터를 법적 효력을 갖는 강력한 증거로 완성하는 최종 절차입니다.

• 사실 관계 교차 검증: LLM이 생성한 모든 분석 내용(코드 해설, 로그 요약 등)이 원본 데이터와 일치하는지 철저히 검증하여 기술적 오류나 논리적 비약을 바로잡습니다.
• MVE 패키지 무결성 보증: 분석에 사용된 원본 파일의 해시값부터, 사용된 도구의 버전, 모든 로그 기록, LLM과의 상호작용 기록까지, MVE(최소 증거 패키지)에 포함된 모든 항목의 무결성을 최종적으로 확인합니다.
• 전문가 선언문 (Affidavit) 서명: 분석가로서 모든 절차를 준수했으며, 분석 결과가 자신의 전문적 소견임을 확인하는 법적 문서에 서명합니다.

💡 MVE(최소 증거 패키지)의 구성 요소
MVE(최소 증거 패키지)는 메타데이터(Identification Metadata), 정적 증거(Static Evidence), 동적 증거(Dynamic Evidence), 네트워크 증거(Network Evidence), 종합 진술(Concise Statement)으로 구성되며, 이를 상호 교환 가능한 JSON 파일과 함께 아카이브(예: 암호화된 ZIP) 형태로 보관·공유하는 것이 바람직합니다.

법정에서 증언하고 상대방의 반대 심문에 답변하는 것은 결국 인간 전문가의 몫입니다. 이러한 엄격한 절차를 통해 비로소 AI가 정리한 데이터는 법정에서 상대방의 공격을 방어할 수 있는 견고한 증거로 완성됩니다.

📋

특허 침해 분석 워크플로우 요약

🔒 1. 법적/포렌식 준비: 분석 권한을 확보하고, 원본 파일 해시값을 계산하여 MVE(최소 증거 패키지) 작성을 시작합니다.

🔎 2. 정적 분석: 실행 파일 자체를 분석해 '압축', '암호화' 관련 코드의 존재와 순서를 파악, 침해 가설을 수립합니다.

⚡ 3. 동적 분석: 프로그램을 실행하며 파일 I/O, 함수 호출 순서, 네트워크 트래픽을 관찰해 가설을 실증합니다.

✍️ 4. 클레임 차트 작성:

수집된 기술 증거(코드, 로그)를 특허의 각 청구항 요소에 1:1로 매핑합니다.

👨‍⚖️ 5. 전문가 검증: 모든 분석 결과와 LLM 산출물을 인간 전문가가 최종 검증하고, 법적 효력을 갖는 선언문에 서명합니다.

이 체계적인 접근법은 증거의 신뢰성과 법적 방어력을 극대화합니다.

마무리: 인간 전문가와 AI의 전략적 파트너십

ChatGPT, Gemini, Claude와 같은 LLM을 소프트웨어 특허 침해 분석에 활용하는 것은 단순히 시간을 절약하는 것을 넘어, 분석의 깊이와 객관성을 한 차원 높이는 전략적 선택입니다. AI는 지칠 줄 모르는 파트너로서 방대한 데이터를 처리하고 패턴을 찾아내며, 인간 전문가는 그 결과를 바탕으로 창의적인 통찰과 최종적인 법적 판단을 내립니다.

기억하십시오. 최고의 도구는 그것을 사용하는 사람의 능력을 증폭시킬 때 가장 빛납니다. 이 가이드에서 제시한 포렌식 기반의 워크플로우가 여러분의 소중한 지식재산권을 지키는 데 있어 강력하고 예리한 무기가 되기를 바랍니다. 추가로 궁금한 점이 있다면 언제든 댓글로 남겨주세요!

 

자주 묻는 질문 (FAQ)

Q: 여러 LLM 모델 중 어떤 것을 사용하는 것이 가장 좋은가요?

A: '최고'의 모델은 없습니다. 각 작업에 '최적'의 모델이 있을 뿐입니다. 긴 특허 문서나 로그 파일을 요약하고 구조화할 때는 Claude, 복잡한 코드 분석과 논리적 추론에는 GPT-4o, 스크린샷과 같은 시각 자료를 함께 분석할 때는 Gemini가 유리할 수 있습니다. 각 모델의 장점을 이해하고 복합적으로 활용하는 것이 전문가의 역량입니다.

Q: '최소 증거 패키지 (MVE)'는 왜 그렇게 중요한가요?

A: MVE는 분석 결과의 '신뢰성'과 '재현성'을 보장하는 핵심입니다. 소송 과정에서 상대방은 "이 증거가 어떻게 만들어졌는가?", "결과를 신뢰할 수 있는가?"를 집요하게 공격합니다. MVE는 원본 파일부터 사용된 도구, 모든 로그, 분석가의 서명까지 전 과정을 투명하게 기록하여 이러한 공격을 방어하고, 판사가 증거를 채택할 수 있도록 만드는 법률적 안전장치입니다.

Q: LLM이 생성한 JSON이나 코드 해설을 그대로 증거로 제출하나요?

A: 아니요, 그렇지 않습니다. LLM이 생성한 결과물은 '분석 과정의 기록'으로서 MVE에 포함될 수는 있지만, 법정에 직접 제출되는 핵심 증거는 아닙니다. 핵심 증거는 원본 로그 파일, 캡처된 데이터, 그리고 이 모든 것을 종합하여 전문가가 서술하고 서명한 '클레임 차트'와 '전문가 보고서'입니다. LLM의 결과는 이 최종 보고서를 작성하기 위한 중간 산출물이자 강력한 보조 자료입니다.

‘추상적 아이디어’ 공격을 피하는 프롬프트 특허 전략

 

AI에게 내리는 단순한 명령, 특허가 될 수 있을까? LLM 프롬프트 기술이 단순한 ‘아이디어’를 넘어 어떻게 구체적인 ‘기술적 발명’으로 인정받을 수 있는지, 그 핵심 전략과 국가별 법적 기준을 심층적으로 분석합니다.

우리 주변에 LLM 모델에게 지시하는 프롬프트 기법이나 그 프롬프트를 특허로 보호받을 생각을 하는 사람은 거의 없는 것 같습니다. 저도 처음에는 ‘단순히 컴퓨터에 내리는 명령인데 이게 특허가 될까?’ 하는 의구심이 들었죠. 하지만 이 주제에 대해 깊이 파고들면서, 특정 조건을 만족할 경우 충분히 가능하다는 결론에 이르게 되었습니다. 이 글은 제가 도달한 일련의 사고 과정을 정리한 것이며, 아직 학술적으로 확립된 견해는 아닐 수 있다는 점을 감안하고 읽어주시면 좋겠습니다. 😊

 

🤔 프롬프트, 단순한 ‘사람의 생각’이라 특허가 안 된다고요?

많은 분들이 가장 먼저 떠올리는 장벽은 바로 ‘인간의 정신적 활동’은 특허 대상이 아니라는 원칙일 겁니다. 실제로 “프롬프트는 근본적으로 인간의 개입이며, 이러한 인간의 정신적 활동이 개입되는 기술은 특허 대상이 아니다”라는 주장은 특허 심사에서 가장 강력한 거절 이유 중 하나입니다. 이는 특히 미국 연방대법원의 앨리스 판례(Alice Corp. v. CLS Bank) 이후 더욱 확고해진 기준이죠. 사람이 머릿속으로 생각해서 할 수 있는 일을 단순히 컴퓨터로 구현한 것만으로는 특허를 받을 수 없다는 의미입니다.

이 논리에 따르면, 우리가 프롬프트를 통해 AI에게 무언가를 지시하는 행위는 결국 사람의 머릿속 생각을 표현한 것이니, 특허가 될 수 없다는 결론에 쉽게 다다를 수 있습니다. 하지만 이 주장은 절반은 맞고 절반은 틀립니다. 바로 여기서부터 우리의 특허 확보 전략이 시작됩니다.

💡 알아두세요!
특허법이 문제 삼는 ‘인간의 개입’은 시스템에 명령을 내리는 행위 자체가 아닙니다. 발명의 핵심 아이디어가 인간의 머릿속에서 실질적으로 수행될 수 있는 정신적 단계에 머무는 경우를 의미합니다. 따라서 우리의 프롬프트 기술이 이 경계를 넘어서는 것임을 증명하는 것이 핵심입니다.

 

📊 관점의 전환: ‘명령어’에서 ‘컴퓨터 제어 기술’로

프롬프트 기술의 특허 가능성을 열기 위한 첫걸음은 관점을 바꾸는 것입니다. 우리의 기술을 ‘인간이 AI에게 보내는 메시지’가 아니라, ’복잡한 컴퓨터 시스템(LLM)의 내부 연산 과정을 특정 구조의 데이터를 통해 제어하여, 기술적 문제를 해결하고 구체적인 성능 향상을 이끌어내는 기술’로 재정의해야 합니다.

중국의 DeepSeek-R1의 알고리즘을 가만히 들여다보면, 다양한 프롬프트 기법을 그대로 구현하고 있다는 사실을 발견할 수 있습니다.

생각해보세요. 수십억 개의 파라미터를 가진 LLM에 특정 전문가 역할을 부여하고, 복잡한 라이브러리 의존성 정보를 컨텍스트로 주입하며, 수많은 제약 조건을 조합해 최적의 코드를 생성하도록 제어하는 과정은 명백히 ‘인간의 정신 능력으로는 실질적으로 수행 불가능한(cannot practically be performed in the human mind)’ 영역입니다. 이는 미국 특허상표청(USPTO)의 가이드라인이나 판례에서도 특허 적격성을 인정하는 중요한 기준이 됩니다.

 

🌍 주요국 특허청별 핵심 심사 기준 비교

프롬프트 기술의 특허 가능성은 모든 나라에서 동일하게 평가되지 않습니다. 국제 출원을 고려한다면 주요국 특허청의 미묘한 시각차를 이해하는 것이 매우 중요합니다.

1. USPTO (미국 특허청) – 추상적 아이디어 예외 강조

미국 특허청은 대법원 판례에서 비롯된 Alice/Mayo 2단계 테스트를 엄격히 적용합니다. 단순히 인간의 사고 과정을 대체하는 지시나 일반적 언어 표현은 “추상적 아이디어”로 보아 배제될 수 있습니다. 그러나 프롬프트가 구체적인 기술적 구현(예: 모델 정확도 개선, 특정 하드웨어 연산 최적화)에 연결되어 있음을 입증하면 특허 적격성을 인정받을 여지가 있습니다.

2. EPO (유럽 특허청) – 기술적 효과(technical effect) 중심

유럽 특허청은 ”기술적 성격” 및 “기술적 효과”를 기준으로 판단합니다. 단순히 데이터 입력이나 언어 규칙을 제시하는 수준은 발명성이 없다고 보지만, 프롬프트 구조가 기술적 문제를 해결하는 수단(예: 연산 효율 개선, 메모리 사용 최적화, 특정 장치와의 상호작용 강화)으로 기능한다면 특허 적격성을 인정할 수 있습니다.

3. KIPO (한국 특허청) – 소프트웨어 발명의 실체적 요건 강조

한국 특허청은 “자연법칙을 이용한 기술적 사상의 창작”이라는 전통적 요건을 중시합니다. 따라서 단순히 문장이나 언어 규칙으로서의 프롬프트는 기술적 사상이 아니라고 보지만, 특정 알고리즘·하드웨어·시스템과 결합하여 구체적인 기술적 결과를 도출함을 입증하면 발명으로 인정될 수 있습니다. 특히 한국 실무에서는 구체적 시스템 구조나 처리 흐름을 함께 제시해야 설득력이 큽니다.

핵심 비교 요약

특허청	핵심 요건
USPTO (미국)	추상적 아이디어 예외를 피하기 위한 ‘구체적 기술 구현’ 강조
EPO (유럽)	‘기술적 효과(technical effect)’ 입증이 핵심. 단순 데이터 조작은 불가
KIPO (한국)	자연법칙을 이용한 기술적 사상 + 시스템/구조적 구현 강조

⚠️ 국제출원 시사점
동일한 “LLM 프롬프트” 기술이라도 미국에서는 “추상적 비즈니스 방법”으로, 유럽에서는 “비기술적 언어 규칙”으로, 한국에서는 “단순 아이디어”로 배제될 위험이 각각 존재합니다. 따라서 국제출원을 고려한다면, 공통분모인 ‘구체적인 시스템 아키텍처’와 ‘측정 가능한 기술적 효과’를 명세서 전반에 명확히 드러내는 전략이 필수적입니다.

 

🧮 특허 청구항 구성 실무 가이드 (상세편)

그렇다면 ‘인간의 개입’이라는 공격을 피하고 ‘기술적 발명’임을 명확히 하려면 특허 청구항을 어떻게 작성해야 할까요? 핵심 전략 4가지를 더 구체적으로 살펴보겠습니다.

1. 주어를 ‘사람’이 아닌 ‘컴퓨터(프로세서)’로 설정하세요.

이는 발명의 중심을 ‘사용자의 정신 활동’에서 ‘기계의 기술적 동작’으로 옮기는 가장 중요한 단계입니다. 청구항의 모든 단계가 컴퓨터 하드웨어(프로세서, 메모리 등)에 의해 수행됨을 명시해야 합니다.

• Bad 👎: 사용자가 LLM에 페르소나를 지정하고 코드를 생성하는 방법.
• Good 👍: 프로세서가(A processor), 사용자의 입력을 수신하여 특정 프로그래밍 언어의 전문가 페르소나를 LLM에 부여하는 단계.

2. 프롬프트를 ‘구조화된 데이터’로 구체화하세요.

‘자연어 프롬프트’와 같은 추상적인 표현 대신, 컴퓨터가 처리하는 구체적인 데이터 구조임을 명확히 해야 합니다. 이는 발명이 단순한 아이디어가 아님을 보여줍니다.

• Bad 👎: LLM에 자연어 프롬프트를 제공하는 단계.
• Good 👍: 라이브러리 명칭 및 버전 제약 조건을 포함하는 기계 판독 가능한 컨텍스트 스키마(a machine-readable context schema)를 생성하여 LLM에 제공하는 단계.

3. 결과물이 아닌 ‘시스템 성능 개선’을 청구하세요.

‘좋은 코드’와 같은 주관적인 결과물이 아니라, 컴퓨터의 기능을 실질적으로 향상시키는 객관적이고 측정 가능한 효과를 명시해야 합니다. 이것이 바로 ‘기술적 효과’의 핵심입니다.

• Bad 👎: 최적화된 코드를 생성하는 단계.
• Good 👍: 상기 스키마를 통해 LLM의 토큰 생성 확률을 제어하여, 코드 호환성 오류를 감소시키고 GPU 메모리 사용량을 절감하는 최적화된 코드를 생성하는 단계.

4. ‘자동화’ 과정을 명확히 하세요.

최초의 입력을 제외한 모든 과정(데이터 구조화, LLM 제어, 결과 생성 등)은 인간의 추가적인 판단 없이 시스템에 의해 자동으로(Automatically) 이루어진다는 점을 명시하여, 재현 가능한 기술 프로세스임을 보여줘야 합니다.

 

📜 강화된 청구항 예시

앞서 설명한 전략들을 모두 통합하면 다음과 같이 강화된 특허 청구항을 구성할 수 있습니다.

[청구항] 최적화된 코드를 생성하는 컴퓨터 구현 방법으로서,

1. (a) 프로세서가 사용자의 자연어 입력을 파싱하여, 특정 프로그래밍 언어의 전문가 역할을 정의하는 페르소나 식별자를 생성하는 단계;
2. (b) 프로세서가 상기 입력 및 외부 코드 저장소를 참조하여, 라이브러리 명칭과 버전 제약조건, 하드웨어 메모리 사용 한계치를 포함하는 구조화된 컨텍스트 데이터(structured context data)를 생성하는 단계;
3. (c) 프로세서가 상기 페르소나 식별자 및 구조화된 컨텍스트 데이터를 포함하는 제어 프롬프트를 생성하여 LLM에 전송함으로써, LLM의 내부 토큰 생성 과정을 자동으로 제어하는 단계;
4. (d) 상기 제어된 LLM으로부터, 상기 제약조건을 만족하고 컴파일 오류율이 사전 정의된 임계값 미만이며 GPU 메모리 사용량이 감소된 최적화된 코드를 수신하는 단계를 포함하는 방법.

→ 이 예시는 단순한 결과물이 아니라, ‘컴파일 오류율 감소’, ‘GPU 메모리 사용량 감소’와 같은 시스템 수준의 측정 가능한 기술적 효과를 명확히 함으로써 특허 등록 가능성을 크게 높입니다.

 

자주 묻는 질문 ❓

Q: “고양이 시를 써줘” 같은 간단한 프롬프트도 특허를 받을 수 있나요?

A: 아니요, 그 자체는 아이디어에 불과하여 특허를 받기 어렵습니다. 특허의 대상은 시를 생성하기 위해 특정 데이터 구조(예: 시적 장치, 운율 구조를 정의한 스키마)를 가진 프롬프트를 사용하여 LLM을 제어하고, 그 결과 컴퓨팅 자원을 덜 사용하거나 특정 스타일의 시를 더 정확하게 생성하는 등의 기술적 방법이나 시스템입니다.

Q: 프롬프트 기술의 ‘기술적 효과’는 구체적으로 어떤 것들이 있나요?

A: 대표적으로 코드 생성 시 컴파일 오류율 감소, GPU나 메모리 같은 컴퓨팅 리소스 사용량 절감, 응답 생성 시간 단축, 특정 데이터 형식(JSON, XML 등)의 출력 정확도 향상 등이 있습니다. 중요한 것은 이 효과가 측정 가능하고 재현 가능해야 한다는 점입니다.

Q: 국제 출원 시 국가마다 청구항을 다르게 작성해야 하나요?

A: 네, 핵심 전략은 같지만 각 특허청이 중시하는 포인트에 맞춰 강조점을 달리하는 것이 유리합니다. 예를 들어, 미국(USPTO) 명세서에는 ‘컴퓨터 기능의 구체적 개선’을, 유럽(EPO)에는 ‘기술적 문제 해결을 통한 기술적 효과’를, 한국(KIPO)에는 ‘시스템 구성과 처리 흐름의 구체성’을 더 부각시키는 방식입니다.

결론적으로, AI 프롬프트를 특허로 보호받는 길은 분명히 존재합니다. 다만, ‘무엇을 요청하는가’라는 아이디어의 차원을 넘어, ‘어떻게 컴퓨터 시스템을 기술적으로 제어하고 개선하는가’를 명확히 보여주는 전략적 접근이 필요합니다. 이 글이 여러분의 혁신적인 아이디어를 강력한 지식재산으로 만드는 데 작은 실마리가 되었으면 합니다. 더 궁금한 점이 있다면 댓글로 물어봐 주세요~ 😊