OLE 개체란 무엇인가 - 포함과 연결의 구조, 그리고 업무 문서의 함정

「Word 사양서에 있는 표를 두 번 클릭했더니 메뉴가 Excel로 바뀌었다」. 이것은 표를 단순한 그림이 아니라 OLE 개체로 문서에 넣었을 때의 동작입니다.

OLE는 Object Linking and Embedding(개체의 연결과 포함)의 줄임말입니다. 다른 애플리케이션이 만든 문서 데이터를 포함 또는 연결로서, 그릇이 되는 문서에 통합합니다. 기술적인 실체는 문서에 포함하거나 연결할 수 있는 COM 개체입니다.¹²

이해의 출발점은 「데이터 본체는 어디에 있는가」입니다. 이 점이 분명해지면 문서가 커지는 이유, 서버 이전으로 연결이 끊어지는 이유, 표는 보이는데 편집할 수 없는 이유를 정리할 수 있습니다.

이 글은 중소기업의 정보 시스템 담당자와 업무 애플리케이션 개발자를 대상으로 합니다. 먼저 포함과 연결을 비교하고, 익숙한 조작, 증상별 대처, Access와 보안에서 주의할 점으로 나아갑니다. COM이나 구조화 스토리지 같은 내부 구조는 7장에, 앞으로의 운영과 설계 판단은 8장에 정리합니다.

1. 먼저 결론: 포함은 「문서 안의 복사본」, 연결은 「다른 위치에 대한 참조」

포함과 연결의 차이는 데이터 본체를 저장하는 위치입니다. 이식성, 파일 크기, 업데이트되는 방식은 이 차이에서 정해집니다.³

포함은 문서를 원본 파일에서 독립시키고 싶을 때 알맞습니다. 연결은 여러 문서에서 같은 데이터를 공유하고 원본의 변경을 반영하고 싶을 때 알맞습니다. 다만 연결의 업데이트가 반드시 자동인 것은 아닙니다. 자동 업데이트인지 수동 업데이트인지는 문서 쪽 설정으로 정해집니다.⁴⁵⁶

flowchart TB
    accTitle: 포함과 연결의 차이
    accDescr: 포함은 데이터 본체를 그릇이 되는 문서 안에 통째로 저장해 자기 완결적인 대신 문서가 커지고, 연결은 문서에 참조와 업데이트 설정과 보통은 표시용 정보만 두고 데이터 본체는 연결 원본 파일에 남으므로 문서는 작고 연결 업데이트의 설정(자동인지 수동인지)에 따라 연결 원본의 변경을 반영할 수 있다
    doc["그릇이 되는 문서(Word 문서 등)"] --> emb["포함: 데이터 본체까지 저장"]
    doc --> lnk["연결: 참조와 설정과 표시 정보(보통)"]
    emb -.-> self["자기 완결적이지만 커진다"]
    lnk --> src["연결 원본 파일(본체는 여기)"]
    src -.-> upd["원본의 변경을 반영할 수 있다(설정에 따라)"]

그림 1: 문서 안에 본체를 두는가, 다른 위치의 본체를 참조하는가. 이 차이가 크기와 업데이트와 전달의 성질로 이어진다.

「문서 안에 데이터가 있다」라는 것과 「어느 PC에서든 편집할 수 있다」라는 것은 별개입니다. 또한 표시용 캐시가 남아 있으면 원본 애플리케이션이나 연결 원본을 이용할 수 없어도 마지막 모습만 표시되는 경우가 있습니다. 「보인다」, 「편집할 수 있다」, 「최신으로 업데이트되어 있다」를 나누어 생각하는 것이 원인 파악의 기본입니다.⁷⁸

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 25건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 어디에서 쓰이고 어떻게 문서에 들어가는가

2.1 Word, Excel, Access, 오래된 업무 문서에서 만난다

OLE는 1990년대부터 Windows의 문서 문화를 떠받쳐 온 기술입니다. 지금도 구조는 현역이지만, 새로 설계할 때 적극적으로 채택하는 기술이라기보다 기존 문서나 데이터베이스 안에서 만나는 기술로 파악하면 실무에 맞습니다.

Access의 직원 사진이나 제품 이미지를 OLE 개체 형식으로 저장해 온 데이터베이스도 대표적인 기존 자산입니다. 이 용도에는 비대화 문제가 있어서, 5장에서 이전 판단을 다룹니다.⁹

2.2 「개체 삽입」과 「선택하여 붙여넣기」

「개체 삽입」에서는 새 개체를 만드는 방법과 기존 파일에서 만드는 방법을 고를 수 있습니다. 「아이콘으로 표시」라는 표시 방법도 있습니다.

「선택하여 붙여넣기」에서는 데이터의 형식에 더해 포함으로 할지 연결로 할지를 고릅니다. 여기에 늘어서는 「~ 개체」가 OLE로 붙여 넣는 선택지입니다. 단순한 그림으로 붙이는 것과는 저장하는 데이터도, 그 뒤의 편집 방법도 다릅니다.¹⁰¹¹

이 두 가지는 OLE의 표준 대화 상자인 Insert Object와 Paste Special에 대응하며, MFC에는 표시용 클래스도 준비되어 있습니다. 복사와 붙여넣기나 끌어서 놓기에서 만드는 경로와, 등록된 클래스나 파일에서 직접 만드는 경로의 차이는 7.1에서 설명합니다.¹⁰¹²

3. 두 번 클릭하면 무슨 일이 일어나는가

3.1 그릇은 「컨테이너」, 편집을 담당하는 애플리케이션은 「서버」

Word 문서 안에 Excel 표가 있는 경우, Word는 그릇이 되는 OLE 컨테이너, 표의 편집을 담당하는 Excel은 OLE 서버입니다. 하나의 문서 안에서 여러 애플리케이션에서 온 데이터를 다루는 문서를 OLE의 복합 문서라고 부릅니다.¹²

Word가 Excel의 편집 기능을 전부 구현하고 있는 것은 아닙니다. 개체를 조작할 때 원본 애플리케이션의 기능을 쓰는 구조입니다. 그래서 문서 안에 데이터 본체가 저장되어 있어도 편집에는 원본 애플리케이션이 필요합니다.

3.2 두 번 클릭은 개체가 정한 「주 동사」의 실행

OLE 개체는 자신에게 실행할 수 있는 조작을 동사(verb)로 정의합니다. 표라면 「편집」, 소리라면 「재생」 같은 조작입니다.

그릇이 되는 애플리케이션은 두 번 클릭 같은 조작을 받아 IOleObject::DoVerb를 호출합니다. 기본 조작인 주 동사(OLEIVERB_PRIMARY)의 내용을 정하는 것은 그릇이 아니라 개체 쪽입니다. DoVerb는 OLE 서버 애플리케이션을 자동으로 실행하고, 그 개체에 맞는 조작을 수행합니다. 두 번 클릭이 언제나 「편집」을 뜻하는 것은 아닙니다.¹³

3.3 Word 안에서 편집할 수 있는 경우와 별도 창에서 열리는 경우

포함 개체와 그릇 양쪽이 In-Place Activation(제자리 활성화)을 지원하면 그릇의 창 안에서 편집할 수 있습니다. 메뉴 모음은 컨테이너와 서버 양쪽의 메뉴를 합성한 복합 메뉴 모음으로 바뀝니다. Word 안에 Excel의 편집용 메뉴가 나타나는 것이 이 구조입니다. 바깥쪽을 클릭하면 비활성화되어 원래 메뉴로 돌아갑니다.¹⁴

sequenceDiagram
    accTitle: 두 번 클릭에서 In-Place Activation까지
    accDescr: 그릇이 되는 애플리케이션은 두 번 클릭을 받아 IOleObject의 DoVerb로 주 동사를 실행하면 OLE가 서버 애플리케이션을 실행하고, 그릇과 서버 양쪽이 In-Place Activation을 지원하는 경우 포함 개체는 그릇의 창 안에서 메뉴를 합성해 편집되며 바깥쪽 클릭으로 비활성화되어 원래 메뉴로 돌아간다(지원하지 않는 경우에는 별도 창에서의 편집이 된다)
    participant U as 사용자
    participant C as 그릇 애플리케이션(Word 등)
    participant S as OLE와 서버 애플리케이션
    U->>C: 포함 개체를 두 번 클릭
    C->>S: DoVerb로 주 동사를 실행
    alt 양쪽이 In-Place Activation을 지원
        S->>C: 서버 실행과 메뉴 합성
        U->>C: 그 자리에서 편집
        U->>C: 개체 바깥쪽을 클릭
        C->>S: 비활성화하고 원래 메뉴로
    else 한쪽이 미지원
        S->>C: 별도 창에서 편집
    end

그림 2: 포함을 그 자리에서 편집하려면 컨테이너와 서버 양쪽의 지원이 필요하다. 지원하지 않으면 별도 창에서 편집한다.

열리는 방식은 개체의 종류, 실행하는 동사, 애플리케이션의 지원 여부에 따라 달라집니다.

In-Place Activation은 포함을 전제로 하는 구조이며 연결에는 쓰지 않습니다. 또한 컨테이너와 서버 양쪽 모두에게 구현은 선택 사항입니다. 「같은 문서인데 열리는 방식이 다르다」라는 것만으로는 고장이라고 판단할 수 없습니다.¹¹⁴¹³

4. 증상에서 원인을 좁힌다: 업데이트되지 않는다, 크다, 열리지 않는다

4.1 표는 보이는데 연결 원본의 변경이 반영되지 않는다

연결 원본의 위치와 연결의 업데이트 방법을 확인합니다. 연결이 문서 쪽에 가지고 있는 것은 데이터 본체가 아니라 연결 원본의 이름과 위치나 업데이트 설정 같은 관리 정보, 그리고 보통은 표시용 캐시입니다.¹⁵⁵

연결 원본을 따라가는 역할은 모니커(moniker)라는 COM의 부품이 맡습니다. 파일 서버 이전, 폴더 이름 변경, 공유 경로 변경, 원본 파일 삭제 등으로 변경된 뒤의 위치를 따라갈 수 없게 되면 연결 확인에 실패합니다. 이것이 링크 깨짐입니다.

이때 표시용 캐시가 저장되어 있으면 문서에는 오래된 표가 남습니다. 표가 표시되고 있다는 것은 연결이 정상이라는 증거가 되지 않습니다. 캐시를 가지지 않는 지정으로 만들어진 개체라면 그 마지막 표시도 남지 않습니다.⁷⁸

대처는 문서의 「연결 편집」에서 연결 원본 경로를 새 위치로 바꾸는 것입니다. 경로가 올바른데도 업데이트되지 않는 경우에는 수동 업데이트로 설정되어 있을 뿐일 가능성도 있으므로 업데이트 방법도 확인합니다. 연결 원본의 변경을 언제 반영할지는 자동 업데이트인지 수동 업데이트인지의 설정에 따릅니다.⁶

연결을 많이 쓴 문서가 대량으로 있다면 이전 전의 조사와 이전 후의 연결 업데이트까지를 파일 서버 이전 계획에 포함합니다. 가능하면 일괄 업데이트도 계획합니다. 이전한 뒤에야 알아차리면 과거 담당자가 쓰던 연결 원본을 문서마다 찾아다니게 됩니다.

4.2 Word나 Excel 문서가 비정상적으로 크다

다시 편집할 필요가 있는지 확인하고, 문서 안에 데이터 본체를 가질 필요를 재검토합니다. 포함은 본체를 복제해 문서 안에 저장하므로 같은 내용을 연결한 경우보다 일반적으로 커집니다. 보통은 표시용 캐시도 저장되므로 편집용 데이터만 들어 있다고 할 수 없습니다.⁴⁷

표를 많이 포함한 보고서가 커지고 여는 데 시간이 걸린다면 이 구조를 의심합니다. 대처는 쓰임새에 맞춰 고릅니다.

다만 크기를 줄이려고 연결로 바꾸면 연결 원본을 관리할 책임이 늘어납니다. 배포하는 문서에서는 참조 대상이 끊어지기 쉬우므로, 단순히 「포함을 모두 연결로 바꾼다」라는 대처는 알맞지 않습니다.

4.3 두 번 클릭해도 열리지 않거나 편집되지 않는다

먼저 그 개체의 원본 애플리케이션이 지금의 PC에도 있는지를 확인합니다. 포함의 자기 완결성은 데이터를 저장하는 위치에 관한 이야기이며, 편집 기능까지 문서에 들어 있는 것은 아닙니다.

원본 애플리케이션이 없는 경우, 표시용 캐시가 저장되어 있으면 그 표시만은 이용할 수 있습니다. 캐시된 표시 데이터는 서버 애플리케이션이 실행되지 않았거나 이용할 수 없을 때에도 컨테이너에서 이용할 수 있도록 설계되어 있습니다.⁷

다만 「아이콘으로 표시」로 붙여 넣은 경우에는 아이콘이 보여도 내용을 확인할 수 없습니다. 캐시 자체를 가지지 않는 개체에서는 마지막 모습도 남지 않습니다. 캐시의 유무는 만들 때의 OLERENDER 지정에 따릅니다.⁸

원본 애플리케이션이 있는데도 열리지 않는 경우에는 다음 순서로 원인을 좁힙니다.

1. 애플리케이션의 버전 호환성을 확인한다. 종류의 변환이 필요한 경우가 있고, OLE에는 변환용 표준 대화 상자도 있다.
2. COM 클래스 등록(CLSID)의 누락이나 손상을 확인한다. 애플리케이션 재설치 등으로 등록을 복구해야 하는 경우가 있다.
3. 보안 설정에 의한 차단과 문서 쪽의 손상을 확인한다.¹⁰

출처를 알 수 없는 문서에 대해서는 열 수 있게 만드는 것을 우선하지 말고, 개체를 활성화하지 않는 운영을 택합니다. 보안상의 취급은 6장에서 설명합니다.

5. Access에서는 「저장만 하고 싶은가, OLE의 동작이 필요한가」를 나눈다

5.1 이미지를 OLE 개체 형식에 넣으면 비대해지기 쉽다

Access의 OLE 개체 형식은 Excel 스프레드시트, Word 문서, 그림, 소리 등을 테이블에 포함하거나 연결하기 위한 필드 형식입니다. 상한은 약 1GB입니다.⁹

직원 사진이나 제품 이미지를 저장하는 데에만 이 형식을 쓰면 저장 공간의 효율이 문제가 됩니다. Microsoft는 첨부 파일 형식이 OLE 개체 형식보다 유연하고, 원본 파일의 비트맵 이미지를 만들지 않기 때문에 저장 공간도 효율적으로 쓸 수 있다고 설명합니다.⁹

다만 첨부 파일 형식으로 바꾼다고 해서 용량 상한이 없어지는 것은 아닙니다.

이것들은 Access 첨부 파일 형식의 제약입니다. OLE 개체 형식의 약 1GB라는 상한과는 대상이 다릅니다.¹⁶

5.2 저장만 한다면 첨부 파일 형식이나 폴더와 경로 관리로

이미지나 파일을 저장하기만 하는 새 설계에서 OLE 개체 형식을 고를 필요는 없습니다. 첨부 파일 형식, 또는 파일을 폴더에 두고 DB에는 경로만 가지게 하는 설계를 검토합니다. 기존 DB에서도 이 두 가지가 이전 대상의 선택지입니다.

한편 연결이나 활성화처럼 OLE 고유의 동작이 필요하다면 이야기가 다릅니다. 이 경우에는 현상 유지도 포함해 판단합니다. 「OLE 개체 형식이니까 즉시 바꾼다」가 아니라, 단순한 저장인지 개체로서 동작시켜야 하는지를 먼저 나누어 보십시오.⁹¹⁶

6. 보안: 일반적인 포함과 OLE 패키지를 나누어 다룬다

6.1 문서가 다른 애플리케이션을 실행하는 입구가 된다

OLE에서는 문서 안에 다른 애플리케이션의 개체를 들여와 여는 쪽 PC에서 동작시킵니다. 이 구조는 공격자에게도 운반 수단이 됩니다.

실제로 조작된 OLE 개체를 포함한 PowerPoint 파일 등으로 임의의 코드를 실행하게 하는 취약점 CVE-2014-4114는 표적형 공격에 사용되었습니다. OLE 개체를 저장할 수 있는 Office 형식 등이 공격 경로가 될 수 있어서, 「문서를 읽기만 할 생각」이 실행의 입구가 되어 버립니다.¹⁷

6.2 OLE 패키지의 활성화는 조직 차원에서 금지한다

특히 주의해야 할 것이 OLE 패키지(Object Packager)입니다. 임의의 파일을 OLE 개체로 문서에 감싸 넣는 오래된 구조이며, 실행 파일도 저장할 수 있습니다. Object Packager에 관한 원격 코드 실행 취약점도 공표되어 있습니다.¹⁸

그래서 Word, Excel, PowerPoint에서 OLE 패키지의 활성화를 레지스트리 설정으로 금지하는 것이 강화책이 됩니다. 오스트레일리아 정부의 Essential Eight에 대응한 Microsoft의 지침은, 설정용 PowerShell 스크립트를 Intune으로 조직에 배포하는 절차를 제시합니다.¹⁹

운영은 다음 세 가지로 나눕니다.

• 출처를 알 수 없는 문서의 개체는 열지 않고 열게 하지도 않는다. 활성화는 다른 파일을 여는 것과 같은 무게의 조작으로 다룬다.
• OLE 패키지의 활성화는 조직 차원에서 차단한다. 통상 업무에서 필요해지는 상황은 거의 없으므로 개인의 주의에만 기대지 않는다.
• 사내 문서의 일반적인 포함이나 연결까지 일률적으로 금지하지는 않는다. 패키지나 조작된 문서의 위험과 기존의 업무상 이용을 나누어 판단한다.

이 글의 결론은 「OLE를 전부 금지한다」가 아닙니다. 일반적인 Excel 표의 포함까지 일률적으로 금지해 업무를 멈추는 것이 아니라, 출처를 알 수 없는 개체와 OLE 패키지를 중점적으로 다룬다는 정리입니다.

7. 내부 구조: COM, 구조화 스토리지, 모니커의 역할

여기부터는 업무 애플리케이션의 유지보수나 문서 자산 조사에 필요해지는, 구현에 가까운 설명입니다. 지금까지의 증상을 「어느 구조가 담당하는가」에 대응시킵니다.

7.1 OLE 복합 문서를 떠받치는 세 가지 토대

OLE 복합 문서는 COM, 구조화 스토리지, 통합 데이터 전송 위에 성립합니다. 개체는 COM의 IUnknown에 더해 IOleObject, IViewObject2 같은 복합 문서 고유의 인터페이스를 공개합니다. 연결 개체는 여기에 더해 IOleLink를 구현합니다.²

데이터 전송 경로에서는 OLE 서버가 자신의 데이터를 IDataObject로 제공하고, 전용 클립보드 형식을 통해 포함으로 붙일 수 있는지 연결로 붙일 수 있는지를 컨테이너에 전달합니다. 이것이 「선택하여 붙여넣기」의 선택지로 이어집니다.¹²

다만 모든 생성 조작이 IDataObject를 거치는 것은 아닙니다. 「개체 삽입」에서 새로 만드는 경우나 기존 파일에서 만드는 경우는, 등록된 클래스나 파일에서 직접 개체를 만드는 다른 경로입니다. 클립보드와 끌어서 놓기 자체의 구조는 「클립보드와 끌어서 놓기의 구조」에서 다룹니다.

7.2 구조화 스토리지는 「하나의 파일 안의 파일 시스템」

구조화 스토리지에서는 하나의 파일 안에 디렉터리에 해당하는 스토리지(IStorage)와 파일에 해당하는 스트림(IStream)의 계층을 만듭니다. 루트 스토리지 아래에 하위 스토리지와 스트림을 중첩할 수 있습니다.²⁰

COM이 제공하는 표준 구현이 복합 파일(Compound Files)입니다. FAT나 NTFS 같은 파일 시스템에 의존하지 않고 다룰 수 있는 단일 파일 형식이며, 형식 자체는 MS-CFB(Compound File Binary File Format)로 공개되어 있습니다.²¹²²

컨테이너는 개체의 저장 위치를 준비합니다. IPersistStorage로 영속화하는 개체는 건네받은 IStorage에 자신의 데이터를 씁니다. IPersistStream을 쓰는 구현이라면 저장 위치는 IStream입니다.²

flowchart TB
    accTitle: 복합 파일의 내부 구조
    accDescr: 복합 파일은 루트 스토리지 아래에 디렉터리에 해당하는 스토리지와 파일에 해당하는 스트림의 계층을 가지며, IPersistStorage로 영속화하는 포함 개체는 하위 스토리지에, IPersistStream으로 영속화하는 개체는 스트림에 저장되고, 포함 개체의 스토리지에는 원본 애플리케이션을 식별하는 CLSID를 가지게 할 수 있으며(비어 있을 수도 있다), 표시용 캐시의 스트림은 보통 저장되지만 만들 때의 지정에 따라서는 가지지 않을 수도 있어서 하나의 파일 안의 파일 시스템으로서 작동한다
    root["루트 스토리지(문서 본체)"] --> s0["스트림: 본문 데이터"]
    root --> st1["스토리지: 포함(IPersistStorage)"]
    st1 --> s1["스트림: 개체의 데이터"]
    st1 --> s2["스트림: 표시용 캐시(보통)"]
    st1 -.-> cls["CLSID로 원본을 나타낼 수 있다(선택)"]
    root -.-> s3["스트림: IPersistStream 영속화"]

그림 3: 문서 안에 계층을 만들고 개체 자신이 데이터를 저장한다. 스토리지를 쓰는 영속화와 스트림을 쓰는 영속화를 구별한다.

디렉터리 항목에는 개체의 원본을 식별하는 CLSID를 가지게 할 수 있습니다. 포함의 스토리지에 CLSID가 들어 있으면 어느 애플리케이션으로 열어야 할 개체인지 판단할 수 있습니다. 다만 CLSID는 비어 있는 경우도 있고, 표시용 캐시도 만들 때의 지정에 따라서는 존재하지 않습니다.²²⁸

7.3 .docx가 되어도 OLE의 저장 형식이 사라진 것은 아니다

구 Office 형식인 .doc / .xls는 파일 자체가 복합 파일입니다. 문서 본체는 스트림으로, 포함 개체는 하위 스토리지로 저장됩니다.

현행 .docx / .xlsx는 ZIP 기반의 Open XML 형식이지만, 레거시 OLE 포함의 바이너리 oleObject*.bin은 지금도 복합 파일 형식으로 저장됩니다. 한편 새로운 Office 문서끼리의 포함에서는 .xlsx 같은 파일이 그대로 ZIP 안에 담기기도 합니다.²²

즉 복합 파일은 단순히 「옛 문서 형식」인 것이 아니라, 현행 문서 안에도 중첩된 저장 형식으로 남아 있습니다.

7.4 연결의 위치는 모니커, 업데이트는 연결의 설정이 관리한다

모니커는 COM에서 개체의 위치를 이름으로 나타내고 필요할 때 확인하기 위한 부품입니다. 이 확인을 바인딩이라고 부릅니다. 연결 개체는 모니커를 써서 연결 원본의 명명, 추적, 실행을 관리합니다.¹⁵

IOleLink는 연결 원본의 관리 기능을 컨테이너에 제공하는 인터페이스입니다. 컨테이너는 그 유무로 포함인지 연결인지를 판별할 수 있습니다. 연결을 포함한 문서를 저장해도 연결의 데이터 본체는 연결 원본에 저장됩니다. 문서에 남는 것은 이름과 위치, 업데이트 설정 같은 연결 자신의 관리 정보와, 보통은 표시용 캐시입니다.¹⁵

이 분담이 4.1의 「표는 보이는데 업데이트되지 않는다」로 이어집니다. 연결 원본의 확인에 실패하면 본체에 도달할 수 없고, 도달하더라도 수동 업데이트라면 자동으로는 업데이트되지 않습니다. 위치의 확인, 업데이트 설정, 캐시의 표시를 나누어 조사하면 원인을 정리할 수 있습니다.⁶⁷

8. 지금 어떻게 대할 것인가: 새 의존을 늘리지 않고 기존의 의존을 파악한다

새 설계에서 OLE 포함에 기대는 것은 피하고, 기존 자산은 「열 수 있는 환경의 유지」와 「조사」로 다루는 것이 기본 방침입니다. 계속 쓸지 여부는 상황마다 판단합니다.

Access와 보안에 관한 판단은 각각 Microsoft의 자료에도 대응합니다.⁹¹⁹

장기 보존에서는 데이터뿐 아니라 열 수 있는 환경도 자산의 일부입니다. 애플리케이션의 세대 교체나 OS의 변화로 원본 애플리케이션을 쓸 수 있다는 전제는 사라져 갑니다. 중요 문서의 PDF판을 남기는 것에 더해, 열 수 있는 환경을 가상 머신으로 유지하는 등의 조치가 필요합니다.

OLE의 구조는 Windows가 하위 호환을 계속 지키는 한 계속 작동합니다. 다만 개별 개체가 열리는지는 원본 애플리케이션이 남아 있는지에 달려 있습니다. 그 전제를 확보하고 있다면 서둘러 전부 없앨 필요는 없습니다.

조사에서는 연결 원본이 있는 서버, 포함을 담고 있는 문서, OLE 개체 형식을 쓰는 데이터베이스의 세 가지를 파악합니다. 이 의존 관계를 알고 있으면 이전, 보안 강화, 마이그레이션을 계획에 넣을 수 있습니다.

9. 정리

OLE 개체는 다른 애플리케이션의 문서 데이터를 포함 또는 연결로 다루기 위한 COM 개체입니다. 포함은 본체를 문서 안에 저장하고, 연결은 다른 위치의 본체를 참조한다. 먼저 이 차이를 기억해 두십시오.²⁴⁵

다음으로 표시, 편집, 업데이트를 나누어 생각합니다. 표시용 캐시가 남아 있어도 원본 애플리케이션이 없으면 편집할 수 없고, 연결 원본을 따라갈 수 없으면 업데이트할 수 없습니다. 두 번 클릭했을 때 열리는 방식도 개체의 종류와 동사, In-Place Activation 지원 여부에 따라 달라집니다.

새로운 운영에서는 의존을 늘리지 않고, 기존 문서는 열 수 있는 환경과 참조 대상을 파악해 유지합니다. Access의 단순한 이미지나 파일 저장에는 첨부 파일 형식이나 경로 관리를 쓰고, OLE 패키지의 활성화는 조직 차원에서 차단합니다.

COM, 클립보드와 끌어서 놓기, 그리고 이 글의 복합 문서는 OLE라는 말의 서로 다른 측면입니다. 컴포넌트 기반, 데이터 전송, 문서로의 통합이라는 역할을 나누면 오래된 업무 자산 안에서 무슨 일이 일어나고 있는지 따라가기 쉬워집니다.

관련 글

• COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 한번에 정리
• 클립보드와 끌어서 놓기의 구조 - 업무 앱에서 OLE 데이터 전송을 올바르게 다루기
• COM STA/MTA 기초 지식 - 스레드 모델과 멈춤을 피하는 사고방식
• C#의 Excel 조작에서 EXCEL.EXE가 남는 문제 - COM 참조 해제 패턴과 대체 판단
• ActiveX / OCX를 지금 어떻게 다룰 것인가 - 남긴다, 감싼다, 바꾼다의 판단표
• VB6 / Access 업무 앱의 수명 연장과 이전 - 남긴다, 감싼다, 바꾼다의 판단표

관련 상담 영역

코무라소프트에서는 OLE와 COM이 얽힌 레거시 문서와 데이터베이스 자산의 조사 및 이전(Access의 OLE 개체 형식에서 벗어나기, 포함 문서의 조사와 PDF화, 링크 깨짐의 일괄 대처), COM 컴포넌트를 포함한 업무 애플리케이션의 유지보수와 개선, Office 연동 앱의 설계를 다룹니다. 「이 문서, 두 번 클릭하면 무슨 일이 일어나는지 모르겠다」라는 단계에서도 상담하실 수 있습니다.

• Windows 앱 개발
• COM 컴포넌트 개발
• 기술 상담과 설계 리뷰
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

포함과 연결은 무엇이 다른가요?

데이터 본체를 어디에 두는지가 다릅니다. 포함(Embedding)은 개체의 데이터 본체를 그릇이 되는 문서 안에 통째로 저장합니다. 문서가 원본 파일에서 독립하므로 다른 PC에 건네도 참조가 끊어지는 일은 없습니다(다만 편집하려면 건네받은 쪽 PC에도 원본 애플리케이션이 필요합니다. 없는 경우에는 표시용 캐시가 저장되어 있으면 그것을 볼 수 있을 뿐이고, 아이콘으로 표시된 개체는 내용을 확인할 수 없습니다). 그 대신 파일은 커지고, 원본 데이터를 변경해도 문서 쪽에는 반영되지 않습니다. 연결(Linking)은 문서에는 참조(연결 원본의 이름과 위치)나 업데이트 설정과 표시용 정보만 두고, 데이터 본체는 연결 원본 파일에 남깁니다. 문서는 작고 연결 원본의 변경을 문서에 반영할 수 있지만(자동인지 수동인지는 연결의 업데이트 설정에 따릅니다), 연결 원본이 이동되거나 이름이 바뀌어 행선지를 따라갈 수 없게 되면 링크가 깨집니다. 어느 쪽으로 붙여 넣을지는 「선택하여 붙여넣기」나 「개체 삽입」 대화 상자에서 고를 수 있습니다.

문서 안의 포함 개체를 두 번 클릭해도 열리지 않거나 편집되지 않는 이유는 무엇인가요?

가장 흔한 원인은 그 개체의 원본 애플리케이션이 지금의 PC에 설치되어 있지 않은 것입니다. 포함 개체의 편집은 원본 애플리케이션(OLE 서버)을 실행해서 이루어지므로, 애플리케이션이 없으면 표시용 캐시가 저장되어 있는 경우에 그것을 표시하는 것밖에 할 수 없고, 아이콘으로 표시된 경우에는 내용을 볼 수조차 없습니다. 원본 애플리케이션이 있는데도 열리지 않는다면, 버전 차이로 「변환」이 필요한 경우, 재설치 등으로 고쳐지는 COM 클래스 등록(CLSID)의 누락이나 손상, 문서 자체의 손상, 보안 설정 때문에 활성화가 차단된 경우를 순서대로 의심해 보십시오.

Word나 Excel 파일이 포함 개체 때문에 비정상적으로 커지는 이유는 무엇인가요?

포함이 데이터 본체를 문서 안에 복제해서 저장하는 방식이기 때문입니다. 같은 개체를 연결로 가지는 문서에 비해, 포함을 가지는 문서는 일반적으로 커집니다. 게다가 문서에는 보통 편집용 데이터 본체에 더해 표시용 캐시도 저장됩니다(캐시를 가질지 여부는 만들 때의 지정으로 정해집니다). 파일을 작게 하고 싶다면 포함이 아니라 연결로 바꾸기, 그림으로 붙여 넣기(다시 편집할 필요는 없다고 정리하기), 원본 파일을 따로 공유하고 문서에는 연결이나 그림만 두기 같은 선택지가 있습니다. 다만 연결은 연결 원본을 관리해야 하므로, 배포하는 문서에는 맞지 않습니다.

파일 서버를 이전했더니 문서 안의 연결 개체가 업데이트되지 않습니다. 왜 그런가요?

연결 개체가 문서 안에 가지고 있는 것은 데이터 본체가 아니라 연결 원본의 이름과 위치 정보(모니커)나 업데이트 설정과 표시용 캐시뿐이기 때문입니다. 파일 서버 이전, 폴더 이름 변경, 공유 경로 변경 등으로 연결 원본의 위치가 바뀌고 변경된 뒤의 위치를 따라갈 수 없게 되면 연결 확인에 실패하고, 문서에는 오래된 표시용 캐시만 남습니다(캐시를 저장하지 않는 지정으로 만들어진 개체에서는 그 표시조차 남지 않습니다). 복구하려면 각 문서의 「연결 편집」에서 연결 원본 경로를 새 위치로 바꿔 주어야 합니다. 참고로 경로는 올바른데 반영되지 않는 경우에는 링크가 깨진 것이 아니라 연결이 수동 업데이트로 설정되어 있을 뿐일 수도 있으니, 업데이트 방법 설정도 함께 확인하십시오. 문서가 대량으로 있다면 이전 전에 연결을 포함한 문서를 조사해 두고, 가능하면 연결의 일괄 업데이트를 계획에 넣으십시오.

OLE 개체는 보안상 위험하다고 들었습니다. 계속 써도 괜찮을까요?

「문서 안에 다른 애플리케이션의 개체를 들여와 여는 쪽에서 실행한다」라는 OLE의 구조는 공격자에게도 편리한 운반 수단이며, 조작된 OLE 개체를 통한 임의 코드 실행 취약점이 실제 표적형 공격에 사용되어 왔습니다. 특히 임의의 파일을 감쌀 수 있는 OLE 패키지가 위험해서, 오스트레일리아 정부의 Essential Eight 같은 공적 지침은 Word, Excel, PowerPoint에서 OLE 패키지를 활성화하지 못하도록 레지스트리 설정으로 금지할 것을 권장합니다. 사내 문서에서의 일반적인 포함이나 연결까지 일률적으로 금지할 필요는 없지만, 출처를 알 수 없는 문서의 개체는 열지 않고 OLE 패키지 활성화는 조직 차원에서 차단한다는 운영이 현실적인 타협점입니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.