왜 청구항이라고 부르는가?

1 먼저 답하면

청구항은 발명을 설명하는 여러 문장 가운데 특허로 보호받으려는 사항을 하나의 항목으로 구획해 적는 문장이기 때문에 그렇게 부릅니다. 제품의 장점을 요약하는 문구도, 소송에서 상대방에게 돈을 청구하는 문장도 아닙니다. 각 청구항은 구성요소·단계·조건과 그 관계를 한 경계 안에 배치하며, 독립항과 종속항은 서로 다른 참조 구조를 가질 수 있습니다. 한 단어만 보고 권리범위나 침해를 단정할 수 없고 현행 법령, 명세서·도면, 관련 판례와 구체적 대상을 함께 검토해야 합니다.

2 무엇을 ‘청구’한다는 뜻인가

특허법 제42조 제4항은 청구범위에 보호받으려는 사항을 적은 항, 즉 청구항이 하나 이상 있어야 한다는 구조를 둡니다. 같은 항은 청구항이 발명의 설명에 의해 뒷받침되고 명확·간결하게 적혀야 한다고 정합니다. 따라서 청구항의 ‘청구’는 심사와 등록 절차에서 보호를 요청하는 기술적 사항을 문장으로 특정한다는 의미로 이해해야 합니다.

명세서의 발명의 설명이 기술내용을 펼쳐 보이는 공간이라면, 청구항은 그 설명을 바탕으로 보호받으려는 조합을 구획하는 공간입니다. 설명에 부품 A, B, C와 여러 대안이 모두 등장해도 한 청구항이 그 전부를 같은 방식으로 포함하는 것은 아닙니다. 반대로 청구항에 쓴 표현이 발명의 설명에서 어떤 의미와 근거를 갖는지 추적할 수 있어야 합니다.

3 청구항은 구성요소의 목록을 넘어 관계를 적는다

처음 읽는 사람은 명사만 표시하기 쉽습니다. 그러나 “센서”, “처리부”, “출력부”가 있다고 해서 문장의 경계를 이해한 것은 아닙니다. 센서가 무엇을 검출하고, 처리부가 어떤 입력을 어떤 조건에서 처리하며, 출력부가 그 결과와 어떻게 연결되는지가 중요할 수 있습니다. 방법 청구항에서는 단계의 순서·조건·주체가 쟁점이 될 수 있습니다.

그래서 청구항을 요소 노드와 관계 엣지로 나눠 읽습니다. 명사구는 Element 후보로 표시합니다. “연결된”과 “기초하여” 및 “응답하여” 같은 표현은 Relation 또는 Condition 후보로 표시합니다. 기능 표현은 어떤 구조와 동작이 설명되어 있는지 원문으로 돌아가 확인합니다. 이 분해는 판결을 대신하는 해석법이 아니라 누락과 모순을 찾는 독해 보조도구입니다.

4 독립항과 종속항은 어떻게 다른가

특허법 시행령 제5조는 청구항을 발명의 성질에 따라 적정한 수로 기재하고, 독립청구항과 다른 청구항을 인용하는 종속청구항의 작성 방식을 규정합니다. 종속청구항은 인용하는 청구항의 번호를 적고, 둘 이상의 청구항을 인용하는 경우 선택적으로 인용하는 형식 등 세부 규칙을 따릅니다. 조문은 인용 관계와 번호 체계를 포함해 여러 항의 구조를 정리합니다.

독립항을 무조건 ‘넓은 항’, 종속항을 무조건 ‘좁고 약한 항’으로만 외우면 실제 문장을 놓칠 수 있습니다. 종속항은 인용한 청구항의 사항에 추가 한정을 더하는 구조이지만, 어떤 기술적 의미와 절차적 역할을 갖는지는 문언과 출원 전체를 보아야 합니다. 여러 독립항이 장치, 방법, 시스템 등 서로 다른 범주를 다룰 수도 있으므로 번호만으로 중요도를 정하지 않습니다.

5 청구항과 발명의 설명은 연결되지만 같은 글은 아니다

청구항의 표현을 이해할 때 발명의 설명과 도면을 확인하는 이유는 용어, 구성 관계와 실시 내용을 찾기 위해서입니다. 그러나 설명에 나온 특정 실시예 하나를 곧바로 모든 청구항의 경계로 동일시하거나, 반대로 청구항 문언을 무시하고 설명에서 원하는 범위를 가져오는 것도 조심해야 합니다.

대법원 2018후10350 판결의 공식 판례 페이지는 보호범위 해석의 원칙을 제시합니다. 특허발명의 보호범위는 청구범위에 적혀 있는 사항에 의해 정해지는 것이 원칙이라는 취지입니다. 청구범위 문언의 의미가 명확하지 않으면 명세서의 다른 기재와 도면을 참작할 수 있다는 취지도 제시합니다. 동시에 명세서의 다른 기재만으로 청구범위를 임의로 확장하거나 제한할 수 없다는 취지를 밝힙니다. 이 판결의 문구는 해당 사건의 쟁점과 이유 전체를 함께 읽어야 하며, 다른 청구항에 자동 적용되는 결론표가 아닙니다.

6 세 번 나눠 읽으면 문장이 보인다

첫 번째 읽기에서는 청구항 유형과 참조관계를 봅니다. 물건·방법 등 범주가 무엇인지, 독립항인지 종속항인지, 어떤 번호를 인용하는지 표시합니다. 두 번째 읽기에서는 구성요소와 관계를 분해합니다. 각 요소의 수식어·연결·순서·조건·기능을 빠뜨리지 않고 표시합니다. 세 번째 읽기에서는 명세서·도면의 locator와 연결합니다. 같은 용어의 정의와 실시 내용, 대안, 도면부호가 어디에 있는지 확인합니다.

이 세 번의 읽기 뒤에도 결론은 유보합니다. 특정 제품이나 방법과 비교하려면 대상의 사실관계를 정확히 특정하고, 청구항 해석과 법률 쟁점을 전문가가 검토해야 합니다. 등록공보인지 공개공보인지, 보정과 정정 여부, 권리 상태와 기준일도 구분해야 합니다.

7 짧은 청구항이 항상 넓은가

단어 수가 적으면 제한이 적어 보일 수 있지만, 문장의 범위는 길이만으로 판단할 수 없습니다. 하나의 용어가 기술적으로 좁은 의미를 가질 수 있고, 관계 표현이나 수치 조건 하나가 중요한 한정이 될 수 있습니다. 반대로 긴 청구항도 여러 대안을 포괄하는 표현을 포함할 수 있습니다.

청구항의 품질도 “짧을수록 좋다” 또는 “많을수록 안전하다”로 평가해서는 안 됩니다. 발명의 핵심·설명의 뒷받침·선행기술·사업상 목적과 절차를 함께 고려해야 합니다. WIPO Patent Drafting Manual은 청구항의 구조와 유형·독립·종속 청구항·문언 선택과 뒷받침을 여러 모듈에서 설명합니다. 그러나 이는 국제 교육자료이며 국내 사건의 결론을 대신하지 않습니다.

8 청구항을 지식그래프로 표현하는 방법

그래프에서는 Claim을 중심으로 ClaimElement·Relation·Condition·ReferenceClaim을 연결합니다. 각 ClaimElement는 발명의 설명의 Passage와 도면의 FigureReference로 이어지고, 문서 버전은 ClaimRevision으로 분리합니다. 법령 제42조·제97조는 LegalProvision 노드, 판례의 판시와 이유는 CaseHolding·ReasoningPassage 노드로 저장하며 정확한 locator를 붙입니다.

제품 비교가 필요한 경우 ProductFeature를 곧바로 ClaimElement와 ‘일치’로 연결하지 않습니다. 먼저 관찰자료의 출처와 버전을 EvidenceCandidate로 둡니다. 결론을 유보한 관계만 사용합니다. “검토 필요”와 “사실 미확인”이 그 예입니다. “용어 대응 쟁점”도 사용할 수 있습니다. 사람이 증거와 문언을 검토한 뒤에도 승인 상태는 별도의 HIL 절차가 정합니다.

9 청구항을 볼 때 피해야 할 네 가지 지름길

• 제목이나 요약서만 읽고 청구항의 범위를 추정하기
• 구성요소는 표시하면서 요소 사이 관계와 조건을 빼기
• 종속항을 부차적 문장으로 보고 인용 구조를 건너뛰기
• 공개공보·등록공보·정정된 문서를 구분하지 않고 비교하기

이 지름길은 초보자뿐 아니라 자동화 시스템에도 위험합니다. 검색 결과의 한 문장만 수집하면 문서 버전과 참조항, 판례의 사실관계가 사라질 수 있습니다. API나 브라우저로 가져온 값은 원문 스냅샷과 locator를 만든 뒤 검증 단계로 보내야 하며, 실시간 조회값을 곧바로 지식 원장에 확정 사실로 쓰지 않아야 합니다.

10 변리사 검토 질문

• ‘보호받으려는 사항을 구획한 문장’이라는 설명이 청구항의 법적 성격을 정확하면서도 쉽게 전달하는가?
• 시행령 제5조의 독립항·종속항 설명에서 예외나 실무상 주의점을 더 밝혀야 하는가?
• 2018후10350의 판시를 일반 독해 규칙처럼 과도하게 넓히지 않았는가?
• 기능적 표현, 수치범위, 방법 단계 등 분야별 후속 기사로 분리할 쟁점은 무엇인가?
• PractitionerPattern 후보로 남길 청구항 검토 질문은 무엇이며, 저자 경험으로 공개하기 전에 어떤 사실 검증이 필요한가?

11 FAQ

11.1 Q1. 청구항에 없는 구성도 보호받을 수 있나?

이 글만으로 답할 수 없습니다. 권리범위는 특허법 제97조의 틀 아래 청구항 문언과 명세서·도면, 관련 법리와 구체적 사실을 함께 검토해야 합니다.

11.2 Q2. 독립항 하나만 읽으면 특허를 이해할 수 있나?

핵심 구조의 출발점은 될 수 있지만 충분하지 않을 수 있습니다. 종속항·발명의 설명·도면·문서 버전과 법적 상태를 함께 확인해야 합니다.

11.3 Q3. 경쟁사 제품에 구성요소가 모두 보이면 침해인가?

곧바로 단정할 수 없습니다. 청구항 해석, 대상 제품·방법의 정확한 사실, 권리 상태와 여러 법률 쟁점을 전문가가 검토해야 합니다.

12 관련 기사 제안

• 왜 명세서라고 부르는가? — 청구항을 뒷받침하는 발명의 설명과 도면의 구조를 다룹니다.
• 나는 무엇을 보호받고 무엇을 관리해야 하는가? — 특허·상표·디자인·저작권의 보호대상을 구분합니다.
• 출원 전에 무엇을 기록해야 하는가? — 청구항 검토에 필요한 구성·대안·시험 원본을 정리합니다.

13 대표 이미지 브리프 — ‘청구항 경계의 등고선 지도’

• 규격: 1200×630
• 장르: 위상지도형 데이터 시각화와 정밀 벡터 다이어그램
• 구도: 중앙의 비대칭 청록 등고선 안에 구성요소 노드와 관계 화살표를 배치하고, 바깥에는 설명·도면 locator가 가는 선으로 연결된다. 독립항은 하나의 큰 등고선, 종속항은 그 위에 겹치는 반투명 보조 등고선으로 표현하며 오른쪽 아래에 버전 시간축을 둔다.
• 색과 질감: 먹색 바탕, 청록 경계, 보라색 종속층, 흰색 가는 locator 선, 매끈한 벡터 표면
• 금지요소: 울타리·성벽 클리셰, 법봉·저울, 승소나 침해를 표시하는 빨간 도장, 실제 청구항 문구·특허번호, 특정 경쟁 제품, 전구·뇌
• 대체텍스트 후보: “독립항과 종속항의 겹친 등고선 안에 구성요소와 관계가 배치되고 설명·도면 근거가 연결된 청구항 지도”

14 공식 출처 대조 기록

• 국가법령정보센터, 특허법 [시행 2025.11.11][법률 제21134호], locator: 제42조 제4항·제6항 및 제97조, URL: https://www.law.go.kr/LSW/lsInfoP.do?lsiSeq=279827
• 국가법령정보센터, 특허법 시행령 [시행 2025.10.1][대통령령 제35809호], locator: 제5조 제1~8항, URL: https://www.law.go.kr/LSW/lsLinkCommonInfo.do?lspttninfSeq=121414
• 국가법령정보센터 대법원 판례, 2018후10350 등록무효(특), locator: 판시사항 [1] 및 판결이유 1. 청구범위 해석 법리의 첫째 문단, URL: https://law.go.kr/LSW/precInfoP.do?mode=0&precSeq=208832
• WIPO, Patent Drafting Manual, Second edition, locator: Module IV “Claims”, pp.39–71 및 Module VI “Designing Patent Claims”, pp.88–108, URL: https://www.wipo.int/edocs/pubdocs/en/wipo-pub-867-23-en-wipo-patent-drafting-manual.pdf
• 특허로, 명세서작성사례안내, locator: 청구범위 작성방법 안내와 특허법 제42조·특허법 시행령 제5조 연결 부분, URL: https://kporc.kipo.go.kr/smart/jsp/ka/menu/guide/main/GuideMain0208.do

대조일은 2026-08-27입니다. 공개 화면·PDF 대조만 완료했으며 immutable EvidenceSnapshot과 SourceVersion은 생성되지 않았습니다.

15 한계와 발행 상태

이 글은 청구항의 구조를 설명하는 교육용 후보이며 특정 청구항의 해석·등록 가능성·유효성·권리범위 또는 침해를 판단하지 않습니다. 적용 법령·문서 버전·판례 사실관계와 대상 기술을 전문가가 다시 검토하고 원문을 고정해야 합니다. 현재 상태는 candidate / unpublished / pending / HOLD입니다.

15.1 함께 보면 좋은 글 (연관 지식 그래프)

• 왜 명세서라고 부르는가?

다음 한 걸음

왜 명세서라고 부르는가?특허 명세서가 단순한 제품 소개서가 아닌 이유와 발명의 설명, 청구범위, 도면이 어떻게 연결되는지 현행 법령·판례·공식 안내로 설명합니다.

연결된 모든 문서와 그 이유는 옆의 「연결된 문서」에 있습니다.

글 위키스튜디오 · 최초 작성 2026-08-27 · 최종 수정 2026-08-27