오늘 proxmox 구축을 하다가  헤놀로지 부트로더 개발자의 깃허브 저장소가 없어진것을 확인했습니다.

개발자가 저장소를 더 이상 제공하지 않기로 결정했다는데 자세한 내용은 아래 링크에 참고하실 수 있습니다.

https://www.2cpu.co.kr/nas/44055

이 글을 읽으면서 저도 오픈소스를 개발하고 배포하는 입장에서 여러가지 생각이 들어서 생각을 정리해봅니다.

 

 

Heartbleed 보안 취약점 사건에 대해서 들어보셨나요? 

이 사태는 2014년에 발생한 중요한 보안 취약점 사건입니다. OpenSSL 소프트웨어에서 발견된 이 취약점은 암호화된 통신 중에 사용자 데이터를 노출시킬 수 있는 위험이 있었습니다.  카드결제, SSL인증서 등에 사용되는 필수 라이브러리이기 때문에 이 사건은 많은 웹 사이트와 서버에 영향을 미쳤으며, 사용자 정보가 유출될 수 있는 위험을 야기했습니다.

이 개발팀의 내부를 들여다보면 얼마나 오픈소스 개발자들이 힘들게 희생하는지 알 수 있습니다. 

이 사고 이전까지 OpenSSL은 일년에 2,000달러(약 260만원)으로 유지되고 있다가, 문제가 생긴후 지금은 9,000달러(약 1100만원)의 기부금으로 운영되고 있습니다. OpenSSL 개발팀은 프로젝트 유지에 상시 개발자 6명 정도가 필요하지만, 프로젝트 지속할 비용을 충당하기 위해 다른 개발 계약을 계속하고 있다고 합니다.

아래 글에서는 오픈소스 개발자들이 자신의 소프트웨어가 수익성 있는 상업 제품에 사용되는 동안에도 아무런 보상없이 무료로 일하는 어려움을 다루고 있으니 한번 읽어보세요. 

https://techcrunch.com/2022/01/18/open-source-developers-who-work-for-free-are-discovering-they-have-power/

또 다른 예로 curl 명령을 자주 사용하실텐데, 이 명령어가 25년 동안 다니엘 스타인버그라는 개발자 한명에 의해 무료로 유지되고 있는것을 아시나요? 만약 cURL처럼 수백만 대의 기기에 라이브러리로 사용되는 프로젝트들이, 만약 개발자가 지원하는 것에 스트레스를 받아서 배포를 중단하기로 결정한다면 어떻게 될까요?

많은 사용자들과 기업들은 오픈소스를 자신의 제품이나 서비스에 많이 사용하지만, 오픈소스 소프트웨어가 무료로 제공되는 노력과 그 뒤에 있는 개발자들의 기여를 간과합니다. 

또한, 오픈소스 프로젝트는 종종 소수의 개발자들에 의해 유지되지만, 이들의 노력은 상업적인 가치와 비교할 때 충분히 인정받지 못합니다. 

오픈소스 공동체의 지속 가능성을 위해서는 오픈소스 사용자들이 이러한 개발자들에 대한 적절한 인정과 지원이 필요합니다. 

오픈소스 사용자는 공동체를 지속가능하게 하기 위해서 오픈소스 프로젝트에 대한 책임감 있는 태도를 가져야 합니다. 

책임감 있는 태도란 특정 프로젝트를 사용하고 있다면 프로젝트에 대한 적극적인 참여, 버그 리포트 및 피드백 제공, 커뮤니티 활동 참여, 후원 등을 포함합니다.

개발자들의 노력을 존중하고, 그들의 작업에 대한 가치를 인식함으로써, 오픈소스 생태계의 건강과 지속 가능성을 지원하는 것이 중요합니다. 

이러한 상호 존중과 협력은 오픈소스 커뮤니티의 성장과 발전에 필수적이라고 생각합니다.

결국 오픈소스 세계에서는 서로 돕고 존중하며 모두가 '함께' 즐길때 오픈소스 커뮤니티가 진정으로 번창할 수 있으니까요!

Subsai

유튜브 동영상에 자막을 입히는 일은 많은 노력을 필요로 하는 일입니다. 하지만 자막은 다양한 언어의 관객을 대상으로 콘텐츠를 보다 친근하게 만들 수 있기 때문에 가능하다면 추가하는 것이 좋죠. Subsai는 동영상 자막을 자동으로 생성하는 혁신적인 오픈 소스 프로젝트로 인공지능을 이용한 자막 생성 프로그램입니다.

https://github.com/abdeladim-s/subsai

기능 및 이점

  • 자동 자막 생성: Subsai는 오디오에서 텍스트로의 변환을 통해 자동으로 자막을 생성합니다.
  • 다양한 언어 지원: 여러 언어의 자막 생성이 가능하여 글로벌 시장을 대상으로 활용할 수 있습니다.
  • 사용자 친화적: 간편한 설치 및 사용법으로 사용자가 쉽게 접근할 수 있습니다.

사용 방법

자신의 PC에 직접 설치해서 사용하거나 Docker 를 이용하여 쉽게 구동할 수 있습니다.

1. 도커가 설치되어 있는지 확인합니다.
2. 리포지토리에 복제하고 CD로 복사합니다.
3. docker compose build
4. docker compose run -p 8501:8501 -v /path/to/your/media_files/folder:/media_files subsai-webui
5. 마운트된 media_files 폴더를 통해 미디어 파일에 액세스할 수 있습니다.

 

Subsai는 동영상 자막 생성의 새로운 방향을 제시하며, 콘텐츠 제작자들에게 유용한 도구로 자리 잡을 것으로 보입니다. 
오픈 소스로 제공되기 때문에 개발자 커뮤니티와 함께 성장할 가능성이 크며, 계속해서 주목해 볼 만한 프로젝트입니다.

오픈AI의 wisper 를 이용하는 방식으로 리눅스, 윈도우, 맥에서 동작하고 모든 소스코드를 제공하기 때문에  CLI 또는 파이썬 패키지를 이용하여 자신만의 어플리케이션을 개발할 때 사용할 수 도 있고, 테스트 한 결과 한국어 자막 자동생성도 지원됩니다.

 

오늘은 디스코드에서 Midjourney Bot을 사용하는 방법을 알아보겠습니다. 

Midjourney 란 무엇인가요?

Midjourney는 텍스트 기반의 프롬프트를 기반으로 복잡하고 상세한 이미지를 생성하는 AI 기반의 서비스입니다. 이 서비스는 기계 학습 모델을 사용하여 사용자가 입력한 텍스트의 시각적 표현을 만들어냅니다.

Midjourney와 다른 Text-to-Image 엔진의 차이점

Midjourney는 다른 텍스트-이미지 생성 엔진들과 비교하여 몇 가지 주요한 차이점을 가지고 있습니다:

  • Midjourney는 매우 상세한 이미지를 생성할 수 있는 능력이 탁월합니다. 복잡한 씬이나 특정 객체를 설명하는 텍스트를 입력하면, Midjourney는 그에 맞는 정교한 이미지를 만들어냅니다.
  • Midjourney는 텍스트의 뉘앙스를 잡아내는 데 탁월합니다. 같은 텍스트 프롬프트를 사용하더라도, 프롬프트 내의 작은 변경사항에 따라 다른 결과를 만들어냅니다.
  • Midjourney는 디스코드와 같은 플랫폼에 통합되어 있어, 사용자들이 쉽게 사용하고 공유할 수 있게 해줍니다.

디스코드에서 Midjourney Bot 사용하기: 단계별 가이드

다음은 디스코드에서 Midjourney Bot를 사용하는 방법에 대한 단계별 가이드입니다.

Step 1: 먼저, 디스코드에 로그인합니다. 디스코드 계정이 없다면 먼저 계정을 생성해야 합니다.

Step 2: Midjourney Bot의 공식 웹사이트를 방문하여 '디스코드에 추가하기' 버튼을 클릭합니다.

Step 3: 디스코드 서버를 선택하고, Midjourney Bot이 필요로 하는 권한을 확인한 후에 '권한 부여'를 클릭하여 Bot을 서버에 추가합니다.

Step 3: 디스코드 서버에서 Midjourney Bot을 활성화합니다. 이를 위해 서버에서 '/midjourney start'라고 입력하면 됩니다.

Step 4: Midjourney 서비스를 사용하려면 구독을 해야 합니다. '/midjourney subscribe'를 입력하면 구독 페이지로 연결됩니다. 해당 페이지에서 결제 정보를 입력하고 구독을 완료하세요.

Step 5: 이제 텍스트 프롬프트를 입력하면 됩니다. '/imagine prompt: [프롬프트]'를 입력하면 이미지를 생성하게 됩니다.

예를 들어, "/imagine prompt: 노을 지는 바다 위에 떠 있는 작은 섬" 이라고 입력하면, 이 설명에 기반한 이미지가 생성됩니다.

Step 6: 생성된 이미지를 저장하고 싶다면, 디스코드에서 이미지를 우클릭하고 '이미지 저장' 옵션을 선택하면 됩니다.

이렇게, Midjourney를 사용하여 디스코드에서 텍스트 프롬프트를 통해 고도로 복잡하고 상세한 이미지를 생성하고, 그 결과를 저장하는 방법에 대한 가이드를 마무리합니다. 이제, '/imagine prompt:' 명령어를 사용하여 자신만의 독특한 시각적 표현을 만들어 보세요!

프롬프트 예시:

"/imagine prompt: 화산이 폭발하는 모습"

"/imagine prompt: 사막에 있는 외딴 오아시스"

"/imagine prompt: 어린 왕자가 달에서 바라보는 지구"

"/imagine prompt: 야생에서 놀고 있는 아프리카 사자 가족"

"/imagine prompt: 도시 위로 떠오르는 풀 달 아래의 풍경"

참고 링크들:

  1. Midjourney 공식 웹사이트
  2. Midjourney를 이용한 예시 작업들
  3. Midjourney에 대한 자주 묻는 질문
  4. Midjourney 디스코드 서버 가이드
  5. 미드저니 사용법 총정리 : https://edmblackbox.tistory.com/901
  6. 미드저니 개인서버 만들기 : https://www.nanumpress.com/ai%EC%A0%95%EB%B3%B4/midjourney/%EB%AF%B8%EB%93%9C%EC%A0%80%EB%8B%88-%EA%B0%9C%EC%9D%B8-%EC%84%9C%EB%B2%84-%EB%A7%8C%EB%93%A4%EA%B8%B0/#:~:text=%EB%B2%84%ED%8A%BC%EC%9D%84,%EB%B4%87%20%EC%B4%88%EB%8C%80%EA%B0%80%20%EC%99%84%EB%A3%8C%EB%90%A9%EB%8B%88%EB%8B%A4.
  7. Prompt 생성기 : https://prompt.noonshot.com/

 

오늘은 엑셀을 넘어서, 구글 문서도구의 Google Sheets를 더욱 효율적으로 활용하는 방법을 소개하려고 합니다. 이를 위해 사용할 도구는 바로 https://gptforwork.com/에서 제공하는 GPT for Sheets입니다.

전통적으로 엑셀이나 구글 시트에서 복잡한 데이터를 처리하려면 복잡한 수식이나 코드를 작성해야 했습니다. 하지만 이제 GPT for Sheets를 이용하면, 직관적인 자연어 질문을 통해 데이터를 처리하고 분석할 수 있습니다. 예를 들어, '이 달의 매출 합계는 얼마인가요?'라는 질문을 시트에 입력하면 GPT for Sheets가 이를 처리하고 답변을 제공합니다. 이처럼 자연어 질문을 이용하면 복잡한 수식을 사용하지 않고도 원하는 데이터 분석을 쉽게 수행할 수 있습니다.

이제 GPT for Sheets를 통해 구글 문서도구를 어떻게 활용하는지 알아보겠습니다.

1단계: GPT for Sheets 설치

먼저, Google Sheets에 GPT for Sheets를 추가해야 합니다. 이를 위해, Google Sheets를 열고 상단 메뉴에서 "확장 프로그램" > "확장 프로그램 추가"로 이동합니다. 검색창에 "GPT for Sheets"를 입력하고 "설치"를 클릭하면 확장 프로그램이 설치됩니다.

2단계: OpenAI API 키 설정

다음으로, OpenAI 웹사이트 (https://openai.com)에서 개인 API 키를 받아야 합니다. "API Keys" 섹션에서 새 키를 생성할 수 있습니다. API 키를 받은 후, Google Sheets에서 "확장 프로그램" > "GPT for Sheets" > "설정"으로 이동하여 OpenAI API 키를 입력합니다. API 키를 입력한 후에는 "저장"을 클릭하여 설정을 완료합니다.

3단계: 확장 프로그램 활성화

이제 설치된 GPT for Sheets 확장 프로그램을 활성화해야 합니다. Google Sheets에서 열려진 문서에서 상단 메뉴의 "확장 프로그램" > "GPT for Sheets" > "시작하기"를 선택하면 활성화가 됩니다.

4단계: GPT for Sheets 사용

GPT for Sheets를 활성화하면, 셀에 데이터를 입력하거나 셀에 질문을 통해 대답을 받을 수 있게 됩니다.

데이터 분석: 예를 들어, A1부터 A10까지 셀에 판매 데이터가 있고, B1 셀에 "A1:A10의 평균은 무엇인가요?"라는 질문을 작성하면, GPT for Sheets가 자동으로 계산하여 답변을 제공합니다.

자연어 질문: 또한, "A1:A10의 가장 큰 값은 무엇인가요?" 또는 "A1:A10에서 가장 작은 값은 무엇인가요?"와 같은 질문에 대해서도 GPT for Sheets는 대답을 제공합니다.

5단계: 고급 기능 사용

GPT for Sheets는 데이터 분석과 자연어 처리뿐만 아니라, 각 셀의 데이터를 기반으로 한 예측도 제공합니다. 예를 들어, 과거의 판매 데이터를 바탕으로 미래의 판매 예측을 요청할 수 있습니다. 이는 "A1:A10의 판매 트렌드를 바탕으로 다음 주의 판매량을 예측해주세요."와 같은 질문을 작성함으로써 가능합니다.

추가로, 실제 사용 예제와 더 자세한 설명을 원하신다면 아래의 링크를 확인해주세요.

GPT for Sheets는 구글 문서도구에서 데이터를 분석하고, 이해하며, 예측하는데 강력한 도구로 업무 생산성을 향상시키기 위해 활용할 수 있는 좋은 방법입니다.

오늘은 OpenAI의 ChatGPT와 Mermaid를 사용하여 간단하고 명확한 시퀀스 다이어그램을 만드는 방법을 다룰 것입니다. 이것은 복잡한 시스템이나 프로세스를 설명하는 데 매우 유용하며, 서로 간의 통신을 효과적으로 시각화하는 데 도움이 됩니다.

다이어그램 예시

1단계: 시나리오 설계

첫 번째 단계는 시나리오를 설계하는 것입니다. 예를 들어, 온라인 쇼핑 웹사이트에서 상품을 구매하는 시나리오를 가정해 보겠습니다. 시나리오는 다음과 같습니다:

  1. 사용자가 상품을 선택합니다.
  2. 사용자가 장바구니에 상품을 추가합니다.
  3. 사용자가 체크아웃을 합니다.
  4. 결제 시스템이 사용자의 결제를 처리합니다.
  5. 결제가 완료되면, 시스템은 사용자에게 결제 완료 메시지를 보냅니다.

2단계: ChatGPT를 사용하여 시퀀스 다이어그램 작성

이제 시나리오가 준비되었으므로, ChatGPT에 다음과 같은 지시를 내립니다: "위에 설명된 시나리오를 기반으로 한 시퀀스 다이어그램을 만들어주세요."

ChatGPT의 응답:

sequenceDiagram
    participant User
    participant System
    participant Payment

    User->>System: Selects product
    System->>User: Confirms product selection
    User->>System: Adds product to cart
    System->>User: Confirms product added to cart
    User->>System: Checkout
    System->>Payment: Process payment
    Payment-->>System: Payment confirmation
    System->>User: Sends payment confirmation message

3단계: Mermaid에 시퀀스 다이어그램 입력

이제 Mermaid를 사용하여 다이어그램을 그릴 준비가 되었습니다. Mermaid Live Editor에 위에서 얻은 코드를 붙여넣습니다. 그러면 시퀀스 다이어그램이 실시간으로 그려집니다.

저는 구글 문서도구에 확장기능을 설치해서 아래와 같은 다이어그램을 작성했습니다.

4단계: 다이어그램 확인 및 저장

마지막으로, 다이어그램이 정확하게 표현되었는지 확인하고, 필요한 경우 수정합니다. 만족하면, 다이어그램을 이미지나 PDF 형식으로 내보낼 수 있습니다.

그러면 완성된 다이어그램은 시나리오의 각 단계를 명확하게 보여주며, 사용자, 시스템, 결제 처리 시스템 간의 상호작용을 시각화합니다.

이 방법은 복잡한 프로세스를 이해하고 문서화하는 데 매우 유용합니다. ChatGPT는 효과적인 시퀀스 다이어그램을 작성하는 데 필요한 논리와 순서를 제공하며, Mermaid는 이러한 정보를 빠르게 시각화합니다. 이 두 가지 도구를 함께 사용하면, 시스템의 행동을 빠르고 쉽게 표현할 수 있습니다.

결론

이렇게, ChatGPT와 Mermaid를 이용해 빠르고 효과적인 시퀀스 다이어그램을 만들 수 있습니다. 이는 소프트웨어 개발, 시스템 설계 및 문서화 작업에 많은 도움이 될 것입니다. 이 두 가지 도구의 강력한 조합을 활용하여 여러분의 작업을 쉽게 만들어보세요!

참고 : https://mermaid.js.org/intro/

E: Could not get lock /var/lib/dpkg/lock - 잠금 파일을 얻을 수 없습니다 - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

apt update 또는 apt install 을 할 때 나타나는 오류 메세지로 이전의 작업 내용으로 잠금 파일이 있는 경우 패키지의 인덱스를 갱신하지 못해서 생기는 오류입니다. 클라우드 가상머신에 접속했을때 인스턴스 이미지의 템플릿에서 종종 나타납니다.

해결 방법

1) 어떤 프로세스가 잠금파일을 생성하고 있는지 확인합니다.

lsof /var/lib/dpkg/lock

lsof 명령어는 프로세스가 사용중인 파일을 표시하는 명령어로 특정 네트워크 포트를 사용하는 프로세스도 확인할 수 있습니다.

lsof [ 옵션 [ : 포트번호 | 서비스 ]] [ 파일 | 프로세스 ]

lsof 로 특정 네트워크 포트를 사용하는 프로세스 확인

2) 잠금파일을 생성하고 있는 프로세스 제거

kill PID
#wait
kill -9 PID

 

3) 잠금파일 제거

sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lock

 

4) dpkg 명령으로 문제 수정

sudo dpkg --configure -a

몇일 전 제로트러스트 가이드라인 1.0이 발표되어 한국인터넷진흥원 홈페이지에서 배포되고 있습니다.

 

KISA 한국인터넷진흥원

 

www.kisa.or.kr

이 가이드라인을 토대로 제로트러스트라는 용어에 대해서 이해를 높일 수 있도록 한번 정리해 보았습니다.

사이버 공격 침투방법 단계

① 최초 침투 단계 해커는 공격대상 기업의 사용자 계정 등을 다크웹 등에서 구입하거나 업무 관련으로 위장한 악성 메일를 보내 계정을 수집하는 등 다양한 방식을 활용하였으며, 일회용 비밀번호 등의 추가 계정 인증 요구도 우회하는 형태를 보임

② 내부망 침투 단계  내부 시스템에 침투한 이후, 다수 계정·단말을 관리하는 중앙서버 또는 기업 내 프로그램 관리 서 등에 접속하여 추가 정보 습득을 위한 악성코드를 배포하는 방식 등으로  접근하기도 함

③ 내부자료 유출 단계 내부망 침투 이후에는 제품 및 영업 관련 정보 또는 내부 직원 정보 등이 저장된 데이터 수집소에 접근한 뒤 관련 파일을 확보하여 외부 반출로 이어짐

사이버 보안 기술 이슈 및 동향

최근 발생한 수많은 해킹 및 랜섬웨어 공격 사례는 경계 기반 보안모델의 한계점을 드러내고 있으며, 최근 등장하는 보안 솔루션만으로는 완벽한 해결책을 제공하지 못함

기존의 경계기반 보안모델은  내부자에 대한 암묵적 신뢰와 함께 높은 권한을 부여함에 따라 고도화·지능화되는 보안 위협에 한계 노출
- 내부 접속 사용자·기기 또는 내부 트래픽에 대해 외부에서 요구하는 접속과 비교하여 높은 수준의 신뢰성을 부여
- 공격자는 악성코드, 크리덴셜 스터핑* 등을 통한 내부 시스템 침투 후 횡적이동**을 통한 DB 관리자 권한 획득 및 데이터 유출

전통적인 경계 기반 보안(Perimeter Security)으로는 업무 환경의 변화와 진화하는 사이버 위협에 효과적으로 대응하기 어려워 ‘제로트러스트(Zero Trust)’ 개념 등장

제로트러스트

제로트러스트(Zero Trust)란 보안위협이 언제 어디서든 발생 가능하다는 전제하에 요건*을 갖추지 않은 사용자·기기는 자원(데이터, 컴퓨팅 서비스 등) 접근을 제한하고, 신뢰도 평가, 지속적 인증, 세밀한 권한 부여 등 각종 접근제어 기관·기업의 ‘경계’ 기반 보안체계 구축보다 ‘내부 데이터 보호’에 집중하는 새로운 보안 패러다임을 의미.

기 존   경계 기반 보안모델은 네트워크 내부 접속 요구(사용자, 기기 등)는 어느 정도 신뢰할 수 있다는 가정에서 시작
- 반면, 제로트러스트 모델은 해커가 네트워크 내·외부 어디든 존재할 수 있으며, 모든 접속 요구는 신뢰할 수 없다는 가정에서 시작

경계 기반 보안모델은 신뢰하는 자원(내부 네트워크)과 신뢰하지 않은 자원(인터넷) 사이에 보안 경계의 벽을 세움
* 내부자 공모 또는 권한탈취 후 침투, 권한 상승 및 횡적이동을 통한 데이터 유출
- 반면, 제로트러스트 모델은 보호해야할 모든 데이터와 컴퓨팅 서비스를 각각의 자원(Resource)으로 분리·보호
* 모든 자원의 경계를 구분하여 분리·보호, 하나의 자원에 접속한 후에는 정해진 권한만큼만 활동이 가능하고, 인근 자원에 대한 추가 접속 요구 시 지속적 인증으로 침투 제한

제로트러스트는 ①SW Defined Perimeter, ②Micro-Segmentation, ③Enhanced Identity Governance에 기반을 두며, 각각의 자원에 대한 접속요구에 동적인증을 통한 선인증 후 접속, 이후에도 가시성 확보를 통한 지속적 모니터링으로 보안 수준을 높임

제로트러스트 기본철학

① 모든 종류의 접근에 대해 신뢰하지 않을 것(명시적인 신뢰 확인 후 리소스 접근 허용)
② 일관되고 중앙집중적인 정책 관리 및 접근제어 결정·실행 필요
③ 사용자, 기기에 대한 관리 및 강력한 인증
④ 자원 분류 및 관리를 통한 세밀한 접근제어(최소 권한 부여)
⑤ 논리 경계 생성 및 세션 단위 접근 허용, 통신 보호 기술 적용
⑥ 모든 상태에 대한 모니터링, 로그 기록 등을 통한 신뢰성 지속 검증·제어

기존 경계 기반 VS 제로트러스트 보안모델 비교

미국의 제로트러스트 도입 동향

美 민간의 제로트러스트 논의 및 도입, NIST의 문서 발표(’20.8월 SP 800-207) 후 미 연방 정부 행정명령(EO 14028)을 통해 연방정부 차원의 제로트러스트 본격 도입 중

출처 : 제로트러스트 가이드라인 1.0(KISA,2023)

 

전통적으로 기술 혁신은 내부 연구개발(R&D) 투입, 규모의 경제, 자체 내부의 우수 인적자원의 확보 및 효율적 활용 등으로 이루어져 왔습니다. 이말은 아이디어의 발굴에서 기초 연구, 제품 개발, 사업화에 이르는 모든 기술 혁신 과정을 기업 내부에서 독자적으로 수행하는 것을 의미하는 것입니다.

하지만 기술의 복잡성 증대, 경제의 글로벌화, 제품 수요의 다양화 등 국내·외 경제 환경의 급격한 변화는 기업의 기술 혁신 활동에 상당한 변화를 요구하고 있으며 이러한 기술 혁신의 패러다임 변화와 맞물려, 기술 혁신 과정에서 외부의 혁신 주체들과 협력하는 방식이 확대됨에 따라, 전 세계적으로 개방형 혁신 활동이 급속히 확산되고 있습니다.

이처럼 개방형 혁신 활동의 필요성이 증가하고 국내에서도 정부지원금을 제공받는 다양한 연구개발 사업에서 오픈소스SW 개발방식의 과제 수행을 요구하는 경우가 많아지고 있지만, 개방형 혁신 연구개발(이하 오픈 R&D)을 수행하려는 수행 기관들은 자신에게 필요한 오픈 R&D 평가 지표와 체계적인 관리 모델들의 부재로 인한 혼란이 가중되고 있습니다.

한국정보통신기술협회의 공개소프트웨어 프로젝트 그룹에서는 조직이 오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 함께 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 부문에서 현재의 역량 상태를 평가하고, 목표 수준을 설정하여 개선의 우선순위를 설정하기 위한 기준을 제시하고 있으므로 이 모델을 활용하면 오픈 R&D를 수행하는 조직이 다른 조직과의 오픈 R&D 수행 역량 성숙도 수준을 비교할 수 있습니다.

개방형 혁신 연구개발 역량 성숙도 모델

PDF 다운로드 : ::: TTA표준화 위원회 :::

오픈소스 연구개발 역량 성숙도 모델

이 표준은 오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 수준을 개선하기 위해 필요한 성숙도 모델을 위해 7개의 도메인(비즈니스 전략, 정책 및 조직, 프로젝트 평가, 공급망 관리, 커뮤니티, 개발 환경, 성과 관리) 관점에서 5 등급의 역량 성숙도 등급으로 측정할 수 있는 기준을 제공합니다.

오픈 R&D를 수행하는 수행 기관이 외부의 참여자와 개방형 혁신 활동의 관리를 할 수 있는 연구개발 능력 수준을 개선하기 위해 필요한 성숙도 모델을 정의하고, 역량 성숙도 등급(Capability Maturity Level), 성숙도 모델 프로세스가 적용되는 도메인(Domain), 도메인별 세부 등급 기준으로 구성되어 있습니다.

평가 수준은 획일적으로 적용하는 것이 아니라 조직의 정책에 의해 적합하게 결정될 수 있으며, 이 표준에서는 5 등급의 성숙도 등급을 제시합니다.

평가 모델은 다음과 같이 7개의 평가 도메인으로 구성되며 각 도메인은 개방형 혁신 연구개발 활동들로 구성된 논리적 그룹, 조직의 성숙도를 평가하기 위해 서로 독립적인 활동 등 관행의 집합이며 각 관행은 조직이 오픈 R&D를 수행하기 위한 활동을 의미합니다.

도메인 설명
비즈니스 전략 오픈소스SW 기반의 비즈니스 전략
정책 및 조직 오픈 R&D 거버넌스 정책과 조직의 구성
프로젝트 평가 오픈소스SW 프로젝트의 성숙도 평가
공급망 관리 오픈소스SW가 포함되는 소프트웨어 공급망 관리
커뮤니티 오픈소스SW 커뮤니티 거버넌스
개발 환경 오픈소스SW 개발을 위한 개발 환경
성과 관리 오픈 R&D에 적합한 성과 지표
 

조직은 평가를 위한 도메인을 결정하고 선정한 도메인에 대하여 다음과 같은 5 등급의 성숙도 수준을 평가하게 되는데, 개방형 혁신 연구개발 역량 성숙도 평가를 위하여 단일 도메인을 평가하는 공식은 평가 도메인 내 오픈 R&D를 수행하기 위한 활동들에 대하여 조직이 설정한 중요도(가중치)를 할당하여 가중 산술 평균값을 합산하여 등급 기준에 따라 평가합니다.

 
 
 

평가를 위하여 다수의 도메인을 평가하는 공식은 다음과 같이 평가 도메인들에 대하여 조직이 설정한 중요도(가중치)를 할당하여 가중 산술 평균값을 합산하여 최종 등급 기준을 평가할 수 있습니다.

 

기본적으로 평가대상 도메인들에 대한 가중 산술 평균값을 5 단계 척도로 구분하여 식별하여 적용할 수 있습니다.

(1단계) 초기 (2단계) 정의 (3단계) 관리 (4단계) 확산 (5단계) 최적화
20 이하 21~40 41~60 61~80 81 이상
 

각 도메인의 세부 평가 기준은 별도 문서를 참고하시기 바랍니다.

개요

작년 미국의 국가 사이버 보안 강화 지침(2021년 5월)이 배포된 이후, 소프트웨어 산업의 다양한 채널에서 SBOM과 관련한 자문이나 회의가 생기고 있는 상황입니다. 

최근의 보안 위협은 공급망, 구축도구, 구축환경, 레파지토리등을 공격하는 추세가 많아지고 있는데 이 지침에서는 미국 연방정부가 사용하는 소프트웨어 공급망의 보안과 무결성을 개선하기 위한 조치를 지시하고 있습니다.

지침이 배포된 이후 미국 정부의 요청으로 미국의 90여개 소프트웨어 기업, 오픈소스 커뮤니티가 자문에 참여하여 의견을 제시히고, CISA, NTIA 에서는 이를 정리하여 SBOM 과 관련한 가이드라인 및 FAQ를 공개하였습니다.

 

SOFTWARE BILL OF MATERIALS | National Telecommunications and Information Administration

A “Software Bill of Materials” (SBOM) is a nested inventory for software, a list of ingredients that make up software components. The following documents were drafted by stakeholders in an open and transparent process to address transparency around sof

www.ntia.gov

 

SBOM 이란?

SBOM 은 SOFTWARE BILL OF MATERIALS 의 약자로 소프트웨어의 구성 요소를 나타내는 메타데이터를 의미하는데 이를 보다 쉽게 설명하자면 우리가 흔히 볼 수 있는 다음과 같은 제품의 성분표기를 떠올리면 됩니다.

성분표기를 통해서 알러지가 있는 사람은 해당 식품을 피하기도 하고, 공급자는 제품의 우수성을 홍보하기도 하고, 크게 성분에 신경쓰지 않고 그냥 사용하는 사용자도 있을 수 있죠.

이와 유사하게, SBOM은 공급되는 소프트웨어의 구성 목록을 잘 표시해서 공급자와 사용자가 이를 기반으로 의사결정에 활용할 수 있는 환경을 조성하는 것을 목표로 하고 있습니다.

NTIA 에서 발표한 SBOM의 필수 구성요소는 다음과 같이 구성되어 있습니다.

 

  • Supplier name
  • Component name
  • Version of the component
  • Cryptograph hash of the component
  • Any other unique identifier
  • Dependency relationship
  • Author of the SBOM data

 

이를 기반으로 작성한다면 다음과 같은 개념도로 표시할 수 있습니다.

National Telecommunications and Information Administration (NTIA) 에서는 오픈소스 소프트웨어나 상용 소프트웨어로 구분하지 않고 모든 공급되는 소프트웨어를 대상으로 광범위하게 적용할 수 있는 SBOM 적용을 위해 산업계의 여러 기업과 커뮤니티에 의견을 청취하고 이를 토대로 SBOM의 이해를 돕는 자료와 적용방법에 대하여 다양한 문서를 배포하고 있으니 아래 문서들을 참고하시기 바랍니다.

 

SPDX, OpenChain

이러한 소프트웨어 구성 목록을 기반으로 공급망의 투명성을 확보해야 한다는 필요성은 오픈소스 커뮤니티에서 10여년 전부터 논의되어 왔으며, 이를 해결하기 위해 실제 산업에서 SPDX와 OpenChain 이 많이 사용되고 있습니다.

  • SPDX는 라이선스 컴플라이언스, 보안 등과 같은 문제를 다루면서 진화해서 현재는 시장에서 가장 성숙한 SBOM으로 자리잡고 있습니다. (https://www.linuxfoundation.org/blog/what-is-an-sbom/)
  • 또한 오픈소스 라이선스 준수를 위한 ISO 국제표준(https://www.iso.org/standard/81039.html) 으로 오픈체인이 있으며, 이는 소프트웨어 공급망의 투명성을 강화하기 위하여 오픈소스 커뮤니티에서 고민하던 결과물입니다.

SBOM이 소프트웨어 보안의 모든 문제를 해결할 수는 없지만 보다 안전한 소프트웨어 사용에 필요한 기본을 제공하는 것은 분명히 필요한 일이며, 다양한 산업계의 의견을 토대로 만들어진 SBOM을 기반으로 소프트웨어 공급망의 투명성을 강화할 수 있는 미국의 이번 정책은 향후 IT 산업과 디지털 인프라의 소프트웨어 관리에 있어서 매우 중요하다고 생각됩니다.

'IT/비즈니스 컨설팅' 카테고리의 다른 글

제로트러스트  (0) 2023.07.12
미래교육을 위한 에듀테크 플랫폼  (0) 2019.10.30
4차산업혁명과 오픈소스거버넌스  (0) 2017.03.18
애자일 이야기  (0) 2016.09.25
IT 기획 전문가 학습로드맵  (2) 2013.11.16

최근 개방형OS 키워드로 여러가지 보고서 작성이나 교육 또는 컨설팅을 하는 일이 종종 생기면서 국내의 개방형OS 생태계에 대한 생각을 여러번 하게 되었습니다. 이런 과정에서 국내의 경우 해외의 개방형OS 생태계와 차이점이 있는 상황이기 때문에 이 부분을 이해하고 적합한 행동을 해야 한다는 생각이 들었고 국내의 개방형OS 생태계를 도식화 하면서 작성한 내용을 공유합니다.

개방형OS 소프트웨어 아키텍처

개방형OS는 어떤 소프트웨어 아키텍처로 구성되는지 생각해보면, 기존의 비공개OS(Windows, MacOS)들은 특정 기업이 독자적으로 모든 소프트웨어 구성요소를 개발하여 배포하는 방식이지만, 개방형OS는 개별 오픈소스 프로젝트들을 컴포넌트로 사용하는 아키텍처로 구성됩니다.

개방형OS의 거버넌스 구조

이처럼 다양한 오픈소스 프로젝트들의 집합인 개방형 OS 생태계의 이해를 위해서는 우선 오픈소스 커뮤니티의 개발 방식과 오픈소스 커뮤니티의 참여자들이 어떻게 구성되는지 식별할 필요가 있습니다.

오픈소스 커뮤니티 개발 방식

개방형 OS와 같이 커뮤니티를 기반으로 형성되는 소프트웨어 개발에는 소프트웨어 릴리즈를 위한 활동을 중심으로 형성되는 개발자(오픈소스 프로젝트) 커뮤니티와 공개된 소프트웨어에 대한 테스트, 버그에 대한 피드백, 신규요구사항, 의견제시 등을 중심으로 형성되는 사용자 커뮤니티가 존재하며, 이 두 커뮤니티의 상호 작용으로 지속적인 발전을 도모할 수 있는 구조입니다.

오픈소스 커뮤니티 개발 방식

오픈소스 커뮤니티의 구성원

일반적으로 오픈소스 프로젝트의 커뮤니티 내 역할 카테고리를 설명하는 데 사용하는 모델은 월트 스카치(Walt Scacchi)와 예·K, 키시다의 양파 모델이 사용 되는데 이 모델은 커뮤니티에 투자를 많이 하고 가장 적극적인 역할은 가운데 있고, 양파 껍질 바깥쪽에서 일할수록 활동과 투자 수준이 줄어드는 특징이 있습니다.

오픈소스 커뮤니티 구성원의 역할

  • 가장 중심에 있는 핵심 개발자는 프로젝트의 창시자 또는 핵심 개발자로 프로젝트의 최종 결정권을 보유합니다. 이 사람들은 대개 프로젝트에서 가장 경험이 많은 실력자이며 수는 많지 않지만, 이들은 모든 커뮤니티 멤버를 지도하거나 멘토링을 하는 사람들이며 이 사람들은 커뮤니티의 소스코드 주 저장소에 외부 참여자의 기여 결과물을 병합하도록 승인하는 커밋 비트 권한을 가지고 있으며 가장 큰 책임을 맡고 있습니다. 
  • 커뮤니티 관리자는 커뮤니티가 외부 커뮤니티 또는 기업과 협력이 필요한 경우 핵심 개발자와 협의를 거쳐 필요한 의사결정과 실행을 담당합니다. 이 사람들은 프로젝트의 지속성을 담보하는 파트너들을 발굴하고 프로젝트가 다양한 분야에서 활용될 수 있도록 프로모션을 하는 등 비즈니스 관점에서 매우 중요한 역할을 합니다.
  • 프로젝트 관리자는 커뮤니티 내부에 다수의 프로젝트가 있는 경우 각각의 프로젝트를 집중적으로 관리하는 사람들입니다. 리눅스 재단, 오픈스택재단, 아파치 재단 등 단일 프로젝트가 아닌 다수의 프로젝트가 활성화된 대규모의 오픈소스 커뮤니티는 개별 프로젝트의 관리를 집중할 수 있는 프로젝트 관리자를 통해 커뮤니티 참여자들과 소통하고 있습니다.
  • 개발자는 일반적인 기여자로써 이 사람들은 프로젝트에 어느 정도 정기적인 기여를 제공하고 대부분의 토론에 꽤 활발하게 참여합니다. 다른 사람들이 한 기여를 검토하는 데 협력하기도 하며 신입 기여자들에게 멘토링을 제공하기도 합니다.
  • 능동적 사용자는 프로젝트의 적극적 사용자들로 신입 기여자의 후보가 되는 그룹을 의미합니다. 프로젝트의 결과물을 주변에 적극적으로 홍보하며 자신도 항상 프로젝트 결과물을 사용하면서 발견한 버그를 공유하고, 이 중 일부는 일정한 시간과 연습을 거친 후 프로젝트의 신입 기여자가 됩니다. 일반 사용자의 질문에 대한 답변을 적극적으로 하며 사람들이 커뮤니티에 잘 정착할 수 있도록 지원하는 중요한 역할을 하게되며 이 사람들은 프로젝트에 도움이 되는 귀중한 피드백, 버그 보고, 기능에 대한 아이디어를 계속 제공하며 프로젝트를 지탱하는 가장 중요한 원동력입니다.
  • 가장 바깥쪽의 계층은 수동적 사용자들로써 개발자나 사용자의 입장으로 적극적 참여는 하지 않지만, 프로젝트를 관심 있게 지켜보고 응원하는 사람들로 비정기적인 피드백을 제공하는 역할을 합니다.

개방형OS 생태계의 이해관계자

’글로벌 상용 소프트웨어 백서‘(과학기술정보통신부, 2017)에서는 국내 소프트웨어 산업 중 PC 운영체제의 생태계를 하드웨어 업체, PC운영체제, 애플리케이션, 클라우드 사업자, 소비자, 공개소프트웨어 커뮤니티의 구성요소로 제시한 바 있으며 공개소프트웨어 커뮤니티는 하드웨어 업체를 포함하여 모든 구성요소와 공헌 및 협업 관계를 유지하는 것으로 표현하고 있습니다. 이 구성을 최근 국내 개방형 OS 생태계에서 실제 참여하고 있는 구성원들을 중심으로 재구성하면 다음과 같이 구성할 수 있습니다.

국내 개방형OS 생태계

이 구성을 오픈소스 커뮤니티를 중심으로 개방형 OS 산업의 이해관계자 그룹으로 재구성하면 생산자 그룹, 공급자 그룹, 소비자 그룹으로 다음과 같이 간략하게 도식화할 수 있습니다.

개방형OS 생태계 이해관계자

  • 생산자 그룹은 오픈소스 활동을 적극적으로 하는 오픈소스 기여자와 기여자가 속한 커뮤니티 또는 재단으로 자발적 기여자들과 해당 커뮤니티에 속한 기업의 재정적 지원을 통해 유지됩니다.
  • 공급자 그룹은 해당 프로젝트를 중심으로 비즈니스 생태계를 조성하고 프로젝트 관련 제품개발, 교육이나 컨설팅 서비스, 기술지원 서비스 등을 공급하여 매출을 달성하고, 해당 커뮤니티와 협력관계를 유지하며 기술인력의 수급, 재정적 지원 등을 통해 참여합니다.
  • 소비자 그룹은 무료로 배포되는 개방형 OS를 사용하는 일반 사용자와 커뮤니티 기반의 지식 채널을 이용하는 방식보다 향상된 지원을 받기 위해 유로 지원 서비스를 구독하는 개방형 OS 활용 조직으로 구성됩니다.

개방형OS 생태계의 시사점

(해외) 개방형 OS 부문에서 대표적인 우분투, 수세, 페도라 등 사용자들의 인지도가 높은 글로벌 개방형 OS의 생태계는 오픈소스 커뮤니티를 중심으로 다음과 같이 오픈소스 프로젝트의 커뮤니티가 구심점이 되어서 다양한 분야의 기업들이 참여하여 생태계를 이루고 있습니다.

해외 오픈소스 생태계의 구성

  • 해외의 개방형 OS의 경우 가장 핵심이 되는 오픈소스 프로젝트의 커뮤니티를 중심으로 프로젝트를 이용하여 제품을 공급하는 공급사와 공급사의 하드웨어, 소프트웨어, 공급망, 기술지원 파트너사들이 참여하는 구조의 생태계를 구성하고 있습니다.
  • 개방형OS 프로젝트의 활성화를 지원하는 프로젝트 파트너사와 다수의 개방형 OS 공급기업, 개방형 OS 기술지원기업이 참여하는 생태계를 구성하여 최종 사용자에게 커뮤니티 기반의 기술지원과 기업의 서브스크립션 기반의 기술지원이 제공되는 구조

(국내) 국내의 개방형OS 생태계는 오픈소스 커뮤니티가 중심이 된 구조가 아니라 개방형OS 공급사가 중심이 되어 사용자 커뮤니티가 최종 사용자의 기술지원 요구사항을 지원하는 구조로 지속성을 담보하는 주체가 커뮤니티가 아니라 개방형OS 공급사에 의존적인 구조입니다.

국내 개방형OS 생태계의 구성

  • 물론 국내에도 개방형 OS 공급사의 파트너사와 프로젝트 파트너사도 존재하지만, 하드웨어, 교육, 기술지원 등의 파트너사의 수가 매우 적어서 해외 개방형 OS 프로젝트의 파트너사를 통한 지원의 수준과는 큰 차이가 있는 상황이며, 이처럼 개방형 OS 사용자가 증가할수록 특정 기업이 기술지원을 모두 해소해야 하는 전통적인 방식으로는 개방형 OS 산업에 적합하지 않은 생태계의 구조입니다.
  • 이처럼 국내의 개방형 OS 생태계는 개방형 OS 프로젝트의 커뮤니티 중심이 아닌 개방형 OS 공급 기업을 중심으로 형성된 생태계이기 때문에 공급 기업의 오픈소스 커뮤니티 활성화 노력이 해외의 개방형 OS 공급사보다 더 많이 요구되는 상황입니다. 하지만 그럼에도 불구하고 실제 개방형 OS 커뮤니티를 활성화하기 위한 개방형 OS 관련 기업들의 인적, 물적 지원이 미비한 상황으로 안타까운 현실입니다.
  • 또한 국내 개방형 OS 산업이 양질의 품질을 지속하기 위해서는, 현재 개방형 OS 소비자로서 강한 권리를 가진 공공 정보화 사업에서 발주자의 역할이 매우 중요한 영향을 미치게 됩니다.
  • 따라서 정보화 사업 담당자는 개방형 OS 도입 사업의 사업자 평가 기준에 사업자의 개방형 OS 커뮤니티 참여 현황과 개방형 OS 프로젝트의 성숙도를 포함하여 평가하는 제도가 필요하며, 이러한 접근을 통해서 개방형 OS 생태계의 관련 기업들이 사업 수주를 위해서는 개방형 OS 커뮤니티의 참여를 유도하게 될 것이며, 그 결과 개방형 OS 프로젝트의 커뮤니티를 중심으로 개방형 OS 생태계를 조성하는 초석이 될 수 있을것입니다.

 

+ Recent posts