Offcanvas

������������

MIT 출신 스타트업 데이터세보, 합성 데이터 품질 검증하는 오픈소스 공개

MIT 컴퓨터과학 및 인공지능 연구소 출신 연구원이 만든 스타트업 데이터세보(DataCebo)가 합성데이터(synthetic data) 품질을 실제 데이터와 비교 분석해주는 SD메트릭스(Synthetic Data Metrics, SD Metrics)를 공개했다.    SD메트릭스는 파이썬 라이브러리 형태로 만든 오픈소스 애플리케이션이며, 적용된 모델과 상관없이 다양한 테이블 형식의 합성 데이터를 평가한다. 사용자는 통계, 효율성, 개인정보 보호와 관련 범주를 정하고 특정 지표를 기준으로 데이터 품질을 확인할 수 있다.  데이터세보의 공동 설립자 네하 팟키는 “테이블 형태의 합성 데이터를 만들 경우 실제 데이터와 합성 데이터들의 품질을 비교할 수 있는 기준이 필요하다. 각 기준은 커버리지, 상관관계 같은 데이터의 특정 요소를 측정한다. 사용자는 SD메트릭스 같은 도구로 어떤 항목을 보존 혹은 삭제해야 할지 결정하며 합성 데이터의 수준을 더욱 높일 수 있다”라고 밝혔다.  특히 SD메트릭스에는 ‘카테고리커버리지(CategoryCoverage)’와 ‘레인지커버리지(RangeCoverage)’라는 기능을 제공하는데, 해당 기능은 합성 데이터가 실제 데이터값과 유사한 범위 안에서 생성되고 있는지 수치로 파악해준다. MIT 수석 연구원이자 데이터세보 공동설립자 칼리안 베라마차네니는 “소프트웨어 개발자나 데이터 과학자라면 SD메트릭스를 다운로드해서 '콜로케이션시뮬레리티(CorrelationSimilarity)' 같은 지표를 이용해 상관관계를 분석할 수 있다. 현재 30가지 넘는 지표를 제공하며, 앞으로 더 개발할 계획이다”라고 설명했다.  SD메트릭스는 합성데이터 금고라는 뜻의 ‘SDV(Synthetic Data Vault)’ 프로젝트의 일환으로 개발됐다. SDV 프로젝트는 MIT의 데이터투에이아이 연구소에서 2016년 개발한 기술로, 2020년부터는 데이터세보가 프로젝트 전부를 가져와 관리 및 개발하고 있다....

합성데이터 오픈소스 데이터세보 SDV SD메트릭스

3일 전

MIT 컴퓨터과학 및 인공지능 연구소 출신 연구원이 만든 스타트업 데이터세보(DataCebo)가 합성데이터(synthetic data) 품질을 실제 데이터와 비교 분석해주는 SD메트릭스(Synthetic Data Metrics, SD Metrics)를 공개했다.    SD메트릭스는 파이썬 라이브러리 형태로 만든 오픈소스 애플리케이션이며, 적용된 모델과 상관없이 다양한 테이블 형식의 합성 데이터를 평가한다. 사용자는 통계, 효율성, 개인정보 보호와 관련 범주를 정하고 특정 지표를 기준으로 데이터 품질을 확인할 수 있다.  데이터세보의 공동 설립자 네하 팟키는 “테이블 형태의 합성 데이터를 만들 경우 실제 데이터와 합성 데이터들의 품질을 비교할 수 있는 기준이 필요하다. 각 기준은 커버리지, 상관관계 같은 데이터의 특정 요소를 측정한다. 사용자는 SD메트릭스 같은 도구로 어떤 항목을 보존 혹은 삭제해야 할지 결정하며 합성 데이터의 수준을 더욱 높일 수 있다”라고 밝혔다.  특히 SD메트릭스에는 ‘카테고리커버리지(CategoryCoverage)’와 ‘레인지커버리지(RangeCoverage)’라는 기능을 제공하는데, 해당 기능은 합성 데이터가 실제 데이터값과 유사한 범위 안에서 생성되고 있는지 수치로 파악해준다. MIT 수석 연구원이자 데이터세보 공동설립자 칼리안 베라마차네니는 “소프트웨어 개발자나 데이터 과학자라면 SD메트릭스를 다운로드해서 '콜로케이션시뮬레리티(CorrelationSimilarity)' 같은 지표를 이용해 상관관계를 분석할 수 있다. 현재 30가지 넘는 지표를 제공하며, 앞으로 더 개발할 계획이다”라고 설명했다.  SD메트릭스는 합성데이터 금고라는 뜻의 ‘SDV(Synthetic Data Vault)’ 프로젝트의 일환으로 개발됐다. SDV 프로젝트는 MIT의 데이터투에이아이 연구소에서 2016년 개발한 기술로, 2020년부터는 데이터세보가 프로젝트 전부를 가져와 관리 및 개발하고 있다....

3일 전

칼럼 | 티(tea), 오픈소스 무료 노동을 끝내자

오픈소스에는 모두가 알고 있지만 아직 충분히 해결되지 않은 문제가 있다. 바로 공정성이다. 그동안 인터넷과 인터넷의 모든 혁신의 근간이 되어온 오픈소스 프로젝트는 주로 자발적인 노동력 기여로 운영됐다. 그러나 이처럼 오픈소스가 개발자에 대한 보상이 거의 또는 전혀 이루어지지 않는 상태로 만들어지고 유지되면, 이는 개발자에게 불공정할 뿐만 아니라 사용자를 잠재적인 위험에 드러낼 가능성이 있다. 실제로 그동안 많은 사용자가 사이버보안 문제에 취약한 상태로 방치되곤 했다.   필자는 대다수의 개발자가 인류 전체에 유익한 소프트웨어 인프라를 만드는 일 대신 페이스북, 애플, 아마존, 넷플릭스, 구글 등 대형 IT 업체의 광고 수익을 늘리는 일에 집중하고 있기 때문에 현대 기술의 성장이 정체됐다고 믿는다. 그 결과 자금난에 시달리는 소규모 오픈소스 개발자 집단에 더는 연봉과 인터넷 운영 유지 가운데 양자택일을 강요할 수는 없는 상태에 이르렀다. 그리하여 필자는 이 문제를 해결하기 위해 ‘브루투포웹쓰리(brew2 for web3)’의 일종인 티(tea) 제작에 나서고 있다.   오픈소스에서 공정성이 중요한 이유 필자는 오픈소스와 블록체인 분야에서 개발해 왔다. 특히 패키지 관리자가 개발 스택에 상주하는 홈브루(Homebrew)의 제작을 통해, 오픈소스에 대한 경제적 인센티브를 바꾸는 데 도움을 줄 방법을 찾았다. 맥스(이 글의 필자 중 한 명)는 오픈소스 소프트웨어 패키지 관리 시스템 홈브루(일명 ‘브루’)를 만들었고, 이는 사상 최대의 기여를 끌어낸 오픈소스 소프트웨어 프로젝트로 성장했다. 세계 최대 IT 기업이 제품 구축의 근간으로 홈브루를 사용하지만 홈브루 개발이나 홈브루에 기여한 개발자에 대해 직접적으로 자금을 지원하지는 않는다. 팀(이 글의 또 다른 필자)은 블록체인 개발 분야의 오랜 리더로서 이키가이 자산 운용(Ikigai Asset Management)은 물론 비영리 단체인 DEVxDAO의 창립자이기도 하다. DEVxDAO는 DAO(탈...

tea 오픈소스

2022.09.19

오픈소스에는 모두가 알고 있지만 아직 충분히 해결되지 않은 문제가 있다. 바로 공정성이다. 그동안 인터넷과 인터넷의 모든 혁신의 근간이 되어온 오픈소스 프로젝트는 주로 자발적인 노동력 기여로 운영됐다. 그러나 이처럼 오픈소스가 개발자에 대한 보상이 거의 또는 전혀 이루어지지 않는 상태로 만들어지고 유지되면, 이는 개발자에게 불공정할 뿐만 아니라 사용자를 잠재적인 위험에 드러낼 가능성이 있다. 실제로 그동안 많은 사용자가 사이버보안 문제에 취약한 상태로 방치되곤 했다.   필자는 대다수의 개발자가 인류 전체에 유익한 소프트웨어 인프라를 만드는 일 대신 페이스북, 애플, 아마존, 넷플릭스, 구글 등 대형 IT 업체의 광고 수익을 늘리는 일에 집중하고 있기 때문에 현대 기술의 성장이 정체됐다고 믿는다. 그 결과 자금난에 시달리는 소규모 오픈소스 개발자 집단에 더는 연봉과 인터넷 운영 유지 가운데 양자택일을 강요할 수는 없는 상태에 이르렀다. 그리하여 필자는 이 문제를 해결하기 위해 ‘브루투포웹쓰리(brew2 for web3)’의 일종인 티(tea) 제작에 나서고 있다.   오픈소스에서 공정성이 중요한 이유 필자는 오픈소스와 블록체인 분야에서 개발해 왔다. 특히 패키지 관리자가 개발 스택에 상주하는 홈브루(Homebrew)의 제작을 통해, 오픈소스에 대한 경제적 인센티브를 바꾸는 데 도움을 줄 방법을 찾았다. 맥스(이 글의 필자 중 한 명)는 오픈소스 소프트웨어 패키지 관리 시스템 홈브루(일명 ‘브루’)를 만들었고, 이는 사상 최대의 기여를 끌어낸 오픈소스 소프트웨어 프로젝트로 성장했다. 세계 최대 IT 기업이 제품 구축의 근간으로 홈브루를 사용하지만 홈브루 개발이나 홈브루에 기여한 개발자에 대해 직접적으로 자금을 지원하지는 않는다. 팀(이 글의 또 다른 필자)은 블록체인 개발 분야의 오랜 리더로서 이키가이 자산 운용(Ikigai Asset Management)은 물론 비영리 단체인 DEVxDAO의 창립자이기도 하다. DEVxDAO는 DAO(탈...

2022.09.19

오픈소스 보안, '정신 번쩍 차렸다'··· 2022년 쏟아진 보안 이니셔티브 8선

작년 말 로그4j 대란은 그 피해의 규모만큼이나 큰 변화의 계기가 됐다. 아직 한 해가 끝나지 않았음에도 2022년을 ‘오픈소스 보안의 해’라고 불러도 무리가 아닐 정도로 수많은 오픈소스 보안 이니셔티브, 프로젝트 및 지침이 잇따라 공개됐기 때문이다.    오늘날 오픈소스 구성요소는 거의 모든 소프트웨어에 쓰인다. 무수한 개발자가 애용하지만 그만큼 보안 위협 또한 비대해졌다. 따라서 여러 벤더, 조직, 정부 기관 모두 너나할  것 없이 오픈소스 보안을 굳건히 하고자 발 벗고 나섰다.  리눅스재단의 오픈소스 공급망 보안 책임자인 데이비드 휠러는 “2022년에는 그 어느때보다도 오픈소스 보안에 대한 관심이 커졌다. 각 분야의 조직이 자신의 역할을 모색하기 시작했다. 아직 갈 길이 멀지만 확실히 의미 있는 진전을 이뤄냈다”라고 말했다.  윌러는 이어 “오픈소스는 오늘날 거의 모든 소프트웨어의 근간이다”라며 “최근 조사에 따르면 현존하는 모든 애플리케이션 중 70~90%가 오픈소스 소프트웨어(OSS)구성요소를 포함한다. 높은 의존도 자체가 문제는 아니다. 그러나 OSS 보안이 취약하다면 얘기는 달라진다”라고 설명했다.  그는 또한 “기업이 어떤 식으로든 오픈소스 보안을 강화하려면 추가 자원과 계기가 필요하다”라며 “소프트웨어 개발자에게 보안이란 또 다른 요구사항이 되므로 대다수 기업은 도움에 목말라 있다”라고 말했다. 2022년에는 기업을 지원하기 위한 오픈소스 이니셔티브 및 프로젝트가 여럿 출범했다. 이 중 8가지 주요 이니셔티브에 대해 알아본다.    1. 백악관의 오픈소스 보안 서밋 (1월) 지난 1월 백악관은 정부와 민간 부문의 이해관계자를 소집해 오픈소스 소프트웨어의 보안을 개선하기 위한 이니셔티브와 개선을 추진하기 위한 새로운 협업 방식에 대해 논의했다. 회의 참석자로는 앤 뉴버거 사이버 및 신기술 국가안보 부보좌관과 크리스 잉글리스 국가사이버국장을 비롯해 아카마이, 아마...

오픈소스 오픈소스보안 OSS 오픈소스 커뮤니티 오픈소스 SW

2022.09.14

작년 말 로그4j 대란은 그 피해의 규모만큼이나 큰 변화의 계기가 됐다. 아직 한 해가 끝나지 않았음에도 2022년을 ‘오픈소스 보안의 해’라고 불러도 무리가 아닐 정도로 수많은 오픈소스 보안 이니셔티브, 프로젝트 및 지침이 잇따라 공개됐기 때문이다.    오늘날 오픈소스 구성요소는 거의 모든 소프트웨어에 쓰인다. 무수한 개발자가 애용하지만 그만큼 보안 위협 또한 비대해졌다. 따라서 여러 벤더, 조직, 정부 기관 모두 너나할  것 없이 오픈소스 보안을 굳건히 하고자 발 벗고 나섰다.  리눅스재단의 오픈소스 공급망 보안 책임자인 데이비드 휠러는 “2022년에는 그 어느때보다도 오픈소스 보안에 대한 관심이 커졌다. 각 분야의 조직이 자신의 역할을 모색하기 시작했다. 아직 갈 길이 멀지만 확실히 의미 있는 진전을 이뤄냈다”라고 말했다.  윌러는 이어 “오픈소스는 오늘날 거의 모든 소프트웨어의 근간이다”라며 “최근 조사에 따르면 현존하는 모든 애플리케이션 중 70~90%가 오픈소스 소프트웨어(OSS)구성요소를 포함한다. 높은 의존도 자체가 문제는 아니다. 그러나 OSS 보안이 취약하다면 얘기는 달라진다”라고 설명했다.  그는 또한 “기업이 어떤 식으로든 오픈소스 보안을 강화하려면 추가 자원과 계기가 필요하다”라며 “소프트웨어 개발자에게 보안이란 또 다른 요구사항이 되므로 대다수 기업은 도움에 목말라 있다”라고 말했다. 2022년에는 기업을 지원하기 위한 오픈소스 이니셔티브 및 프로젝트가 여럿 출범했다. 이 중 8가지 주요 이니셔티브에 대해 알아본다.    1. 백악관의 오픈소스 보안 서밋 (1월) 지난 1월 백악관은 정부와 민간 부문의 이해관계자를 소집해 오픈소스 소프트웨어의 보안을 개선하기 위한 이니셔티브와 개선을 추진하기 위한 새로운 협업 방식에 대해 논의했다. 회의 참석자로는 앤 뉴버거 사이버 및 신기술 국가안보 부보좌관과 크리스 잉글리스 국가사이버국장을 비롯해 아카마이, 아마...

2022.09.14

'자바 스레드 간 데이터 공유' 새 오픈JDK 제안

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘Extent-local Variables(JEP 429)’은 자바 스레드 간 데이터 공유를 지원한다.    자바 스레드 간 데이터 공유가 더 쉬워질 전망이다. 새로운 오픈JDK 제안이 아직 개발 중인 ‘extent-local’ 변수 API를 소개했다. 이 API를 통해 개발자는 한 스레드 안에서는 물론 차일드 스레드(child threat) 간 데이터를 공유할 수 있는 프로그래밍 모델을 제공받는다. 더 많은 가상 스레드를 손쉽게 다룬다는 점을 비롯해 현재 threat-local 변수보다 더 낫다고 해당 제안은 주장했다.  이 제안은 이 API의 목표 4가지를 제시했다.  사용 편의성: 데이터 플로우의 로직을 간소화한다.  일괄성: 공유된 데이터의 전반적인 라이프사이클을 코드의 구문 구조에서 바로 볼 수 있게 한다.  보안성: 공유된 데이터는 인증된 호출자만 접근할 수 있다.  성능: 공유된 데이터를 변경할 수 없도록 해 많은 스레드 간의 데이터 공유를 가능케하고 런타임을 최적화한다.  새로운 extent local 변수 API 제안은 특정 자바 버전을 명시하지 않았다. 가장 빠른 예상 출시일은 2023년 3월 예정인 Java 20일 것이다. Java 19 또는 Java Development Kit 19는 9월 20일에 배포될 예정이며 새로운 기능이 포함되지 않는다.  이번 제안은 자바 프로그래밍 언어 자체에 아무런 영향을 끼치지 않는 추가 기능이다. threat local 변수에서 extent local 변수 API로 이전이 강제되거나 ThreatLocal API 지원이 끊길 가능성은 없다. ciokorea@idg.co.kr

오픈JDK 자바 오픈소스 프로그래밍 API

2022.09.13

오픈JDK(OpenJDK) 커뮤니티에서 인큐베이션 중인 새로운 제안 ‘Extent-local Variables(JEP 429)’은 자바 스레드 간 데이터 공유를 지원한다.    자바 스레드 간 데이터 공유가 더 쉬워질 전망이다. 새로운 오픈JDK 제안이 아직 개발 중인 ‘extent-local’ 변수 API를 소개했다. 이 API를 통해 개발자는 한 스레드 안에서는 물론 차일드 스레드(child threat) 간 데이터를 공유할 수 있는 프로그래밍 모델을 제공받는다. 더 많은 가상 스레드를 손쉽게 다룬다는 점을 비롯해 현재 threat-local 변수보다 더 낫다고 해당 제안은 주장했다.  이 제안은 이 API의 목표 4가지를 제시했다.  사용 편의성: 데이터 플로우의 로직을 간소화한다.  일괄성: 공유된 데이터의 전반적인 라이프사이클을 코드의 구문 구조에서 바로 볼 수 있게 한다.  보안성: 공유된 데이터는 인증된 호출자만 접근할 수 있다.  성능: 공유된 데이터를 변경할 수 없도록 해 많은 스레드 간의 데이터 공유를 가능케하고 런타임을 최적화한다.  새로운 extent local 변수 API 제안은 특정 자바 버전을 명시하지 않았다. 가장 빠른 예상 출시일은 2023년 3월 예정인 Java 20일 것이다. Java 19 또는 Java Development Kit 19는 9월 20일에 배포될 예정이며 새로운 기능이 포함되지 않는다.  이번 제안은 자바 프로그래밍 언어 자체에 아무런 영향을 끼치지 않는 추가 기능이다. threat local 변수에서 extent local 변수 API로 이전이 강제되거나 ThreatLocal API 지원이 끊길 가능성은 없다. ciokorea@idg.co.kr

2022.09.13

"보안 위험 줄이는 종속성 관리법"··· 오픈SSF, 'npm' 가이드 발표

최근 오픈SSF(The Open Source Security Foundation, OpenSSF)가 npm 베스트 프랙티스 가이드(npm Best Practices Guide)를 발표했다. 자바스크립트와 타입스크립트 개발자가 오픈소스 종속성 관련 보안 위협을 줄이는 데 도움을 주기 위한 목적이다. 개발자들이 종속성을 점점 더 많이 공유하고 사용하는 것은 신속한 개발과 혁신에 기여할 수 있지만, 동시에 위험을 초래할 수도 있기에 주의가 요구된다.   오픈SSF 베스트 프랙티스 워킹 그룹(OpenSSF Best Practices Working Group)이 제작한 이번 가이드는 npm을 위한 종속성 관리와 공급망 보안을 중심으로 안전한 CI 환경을 설정하는 방법, 종속성 혼란을 피하는 방법, 종속성 탈취로 인한 여파 제한하는 방법과 같은 다양한 영역을 다룬다.  심각한 보안 위험이 될 수 있는 오픈소스 종속성 오픈SSF 기여자들은 블로그에서 오픈소스 종속성을 사용하는 이점이 단점을 능가하는 경우가 종종 있지만 상당한 위험이 발생할 수 있다며, “간단한 종속성 업데이트로 종속 프로젝트가 중단될 수 있다. 또한 다른 소프트웨어처럼 종속성에 취약성이 있거나 하이재킹되어 이를 사용하는 프로젝트에 영향을 줄 수 있다”라고 썼다. 리눅스 재단의 오픈소스 공급망 보안 부문 이사 데이비드 A. 휠러는 CSO에 개발자의 오픈소스 종속성 사용으로 인한 가장 큰 보안 위험이 직간접 종속성의 취약성이 지닌 파괴력을 과소평가하는 것이라고 지적했다. 휠러는 “결함은 모든 소프트웨어에서 발생할 수 있다. 주의를 기울이지 않으면 공급망에 심각한 영향을 미칠 수 있다. 종속성은 보이지 않는 경우가 빈번하며, 개발자나 조직은 스택의 모든 레이어를 볼 수 없다. 소프트웨어 재사용을 중단한다고 해서 해결되는 문제가 아니다. 소프트웨어를 현명하게 재사용하면서 취약점이 발견됐을 때 구성요소를 업데이트할 준비를 하고 있어야 한다”라고 덧붙였다. 그러나 효율적인 종속성 보안 전략...

오픈SSF 오픈소스 종속성관리 베스트프랙티스 npm

2022.09.07

최근 오픈SSF(The Open Source Security Foundation, OpenSSF)가 npm 베스트 프랙티스 가이드(npm Best Practices Guide)를 발표했다. 자바스크립트와 타입스크립트 개발자가 오픈소스 종속성 관련 보안 위협을 줄이는 데 도움을 주기 위한 목적이다. 개발자들이 종속성을 점점 더 많이 공유하고 사용하는 것은 신속한 개발과 혁신에 기여할 수 있지만, 동시에 위험을 초래할 수도 있기에 주의가 요구된다.   오픈SSF 베스트 프랙티스 워킹 그룹(OpenSSF Best Practices Working Group)이 제작한 이번 가이드는 npm을 위한 종속성 관리와 공급망 보안을 중심으로 안전한 CI 환경을 설정하는 방법, 종속성 혼란을 피하는 방법, 종속성 탈취로 인한 여파 제한하는 방법과 같은 다양한 영역을 다룬다.  심각한 보안 위험이 될 수 있는 오픈소스 종속성 오픈SSF 기여자들은 블로그에서 오픈소스 종속성을 사용하는 이점이 단점을 능가하는 경우가 종종 있지만 상당한 위험이 발생할 수 있다며, “간단한 종속성 업데이트로 종속 프로젝트가 중단될 수 있다. 또한 다른 소프트웨어처럼 종속성에 취약성이 있거나 하이재킹되어 이를 사용하는 프로젝트에 영향을 줄 수 있다”라고 썼다. 리눅스 재단의 오픈소스 공급망 보안 부문 이사 데이비드 A. 휠러는 CSO에 개발자의 오픈소스 종속성 사용으로 인한 가장 큰 보안 위험이 직간접 종속성의 취약성이 지닌 파괴력을 과소평가하는 것이라고 지적했다. 휠러는 “결함은 모든 소프트웨어에서 발생할 수 있다. 주의를 기울이지 않으면 공급망에 심각한 영향을 미칠 수 있다. 종속성은 보이지 않는 경우가 빈번하며, 개발자나 조직은 스택의 모든 레이어를 볼 수 없다. 소프트웨어 재사용을 중단한다고 해서 해결되는 문제가 아니다. 소프트웨어를 현명하게 재사용하면서 취약점이 발견됐을 때 구성요소를 업데이트할 준비를 하고 있어야 한다”라고 덧붙였다. 그러나 효율적인 종속성 보안 전략...

2022.09.07

칼럼ㅣ한때 잘 나갔는데... ‘헤로쿠’가 시들해지는 이유

한때 애플리케이션 배포의 대명사였던 ‘헤로쿠(Heroku)’는 투자 부족으로 다른 배포 옵션을 많이 제공하지 않고 있다.  ‘헤로쿠’에 관해 이야기할 때면 항상 ‘하지만’이 붙는다. 이를 감안하고 보도록 하자. 필자는 지난 15년 동안 헤로쿠가 ‘마법 같은’ 개발자 경험을 제공한다는 이야기를 많이 들었다. 이스라엘 민족이 광야에서 살아남을 수 있도록 하늘이 내려 준 열매처럼 말이다.  하지만…   헤로쿠는 ‘현실’보다 ‘신화’ 속에서 더 크게 보인다. 헤로쿠가 다른 서비스 및 제품에 미친 영향이 크지 않다고 말하려는 건 아니다. 하지만 왜 헤로쿠가 아닌, 쿠버네티스가 애플리케이션을 구축하고 확장하는 기본 방법으로 자리 잡고 있을까? 일각에서는 헤로쿠가 시대를 앞서갔다고 주장한다. 아마도? 아니면 그 마법 같은 개발자 경험의 대가가 오늘날의 복잡한 엔터프라이즈 컴퓨팅에서 작동하기에 너무 제한적일지도 모른다.  개발자 경험의 황금기 최근 헤로쿠는 무료 플랜을 폐지한다고 발표했다. 왜? 알고 보니, 무료 계층을 관리하는 데 너무 많은 작업이 필요했다. 2010년 말 헤로쿠를 인수한 세일즈포스의 부사장 겸 헤로쿠 총괄 책임자 밥 와이즈는 “자사의 제품, 엔지니어링, 보안팀은 헤로쿠 무료 플랜의 사기와 남용을 관리하기 위해 엄청난 노력을 기울이고 있다”라고 말했다. 이 회사는 크립토 사기꾼과 두더지 잡기 게임을 계속하는 대신, (아마도 있어야 할 만큼 많지 않은) 고객에게 더 나은 투자를 하기를 원하고 있다.  필자가 팔로우하는 사용자에 한정되긴 하지만 (필자는) 애플리케이션 배포에 혁명을 일으킨 방법을 칭찬하는 것 외에는 헤로쿠에 관한 다른 언급을 들어본 적이 없다. 헤로쿠 이전에는 애플리케이션을 구축하고 배포하는 데 시간이 오래 걸렸다. 헤로쿠를 사용하면 배포가 깃(git) 푸시만큼 쉽다.  2014년과 2017년 사이 헤로쿠에서 엔지니어링을 이끌었던 제이슨 워너가 주장하는 것처럼 문제는 “헤로쿠가 ...

헤로쿠 PaaS 애플리케이션 배포 클라우드 세일즈포스 쿠버네티스 오픈소스

2022.08.30

한때 애플리케이션 배포의 대명사였던 ‘헤로쿠(Heroku)’는 투자 부족으로 다른 배포 옵션을 많이 제공하지 않고 있다.  ‘헤로쿠’에 관해 이야기할 때면 항상 ‘하지만’이 붙는다. 이를 감안하고 보도록 하자. 필자는 지난 15년 동안 헤로쿠가 ‘마법 같은’ 개발자 경험을 제공한다는 이야기를 많이 들었다. 이스라엘 민족이 광야에서 살아남을 수 있도록 하늘이 내려 준 열매처럼 말이다.  하지만…   헤로쿠는 ‘현실’보다 ‘신화’ 속에서 더 크게 보인다. 헤로쿠가 다른 서비스 및 제품에 미친 영향이 크지 않다고 말하려는 건 아니다. 하지만 왜 헤로쿠가 아닌, 쿠버네티스가 애플리케이션을 구축하고 확장하는 기본 방법으로 자리 잡고 있을까? 일각에서는 헤로쿠가 시대를 앞서갔다고 주장한다. 아마도? 아니면 그 마법 같은 개발자 경험의 대가가 오늘날의 복잡한 엔터프라이즈 컴퓨팅에서 작동하기에 너무 제한적일지도 모른다.  개발자 경험의 황금기 최근 헤로쿠는 무료 플랜을 폐지한다고 발표했다. 왜? 알고 보니, 무료 계층을 관리하는 데 너무 많은 작업이 필요했다. 2010년 말 헤로쿠를 인수한 세일즈포스의 부사장 겸 헤로쿠 총괄 책임자 밥 와이즈는 “자사의 제품, 엔지니어링, 보안팀은 헤로쿠 무료 플랜의 사기와 남용을 관리하기 위해 엄청난 노력을 기울이고 있다”라고 말했다. 이 회사는 크립토 사기꾼과 두더지 잡기 게임을 계속하는 대신, (아마도 있어야 할 만큼 많지 않은) 고객에게 더 나은 투자를 하기를 원하고 있다.  필자가 팔로우하는 사용자에 한정되긴 하지만 (필자는) 애플리케이션 배포에 혁명을 일으킨 방법을 칭찬하는 것 외에는 헤로쿠에 관한 다른 언급을 들어본 적이 없다. 헤로쿠 이전에는 애플리케이션을 구축하고 배포하는 데 시간이 오래 걸렸다. 헤로쿠를 사용하면 배포가 깃(git) 푸시만큼 쉽다.  2014년과 2017년 사이 헤로쿠에서 엔지니어링을 이끌었던 제이슨 워너가 주장하는 것처럼 문제는 “헤로쿠가 ...

2022.08.30

칼럼ㅣ오픈소스 리더십, 구글에 도움이 될까?

구글이 오픈소스 프로젝트에 얼마나 매진하는지는 깃허브 기여자 수에서 드러난다. 한편 AWS의 전략은 고객들이 오픈소스를 사용하기 쉽게 만드는 것이다. 누가 이기고 있는가?   구글의 오픈소스 사랑은 공공연하다. 필자는 이 회사의 오픈소스 부문 책임자 크리스 디보나가 더 많은 일을 해야 한다고 언급한 적 있긴 하지만 구글만큼 오픈소스에 많이 기여하는 회사가 없다는 게 현실이다. 이는 오픈소스 기여 지수(Open Source Contributor Index; OCSI)에서 알 수 있다. 2022년 7월 깃허브의 오픈소스 프로젝트에 기여한 총직원 수에서 구글은 마이크로소프트를 앞질렀다.   물론 이는 드루팔(Drupal; PHP 기반의 오픈소스 CMS 서비스) 등의 큰 프로젝트를 포함하지 않는 깃허브의 데이터일 뿐이다. 또한 직원들의 회사 정보 입력 여부나 간단하게는 리포지토리 위생(repository hygiene)에 따라 달라질 수 있다. 그렇다. 이는 오픈소스 기여 데이터를 물어보기에 적절한 질문이 아니다. 진짜 질문은 ‘오픈소스 기여가 중요한지 여부’여야 한다.  진입로에서 어디로? 일반적으로 오픈소스는 ‘다른 것이 섞이지 않은(unalloyed)’ 제품으로 간주된다. 그렇지 않은가? 어찌 됐든 오픈소스는 좋다. 예를 들면 커뮤니티 중심의 쿠버네티스를 제공하는 것은 코드로 협업하는 좋은 방법이다. 이는 또한 채용하거나 일자리를 구할 수 있는 좋은 방법이다. 아울러 경쟁사 유료 제품의 무료 대안을 만들어 경쟁사를 약화시키는 중요한 방법이기도 하다. 하지만 오픈소스가 무너질 수 있는 곳이기도 하다.    필자는 지난 2017년 ‘오픈소스 진입로(open source on-ramps)’에 관해 이야기한 바 있다. 이는 클라우드 서비스를 보완하는 오픈소스화의 관행이다. 특히 구글은 이 작업을 매우 잘 수행했다. 브루킹스 연구소(Brookings Institution)의 연구원 알렉스 잉글러는 “구글과 페이스북이 ...

오픈소스 구글 AWS 마이크로소프트 깃허브 기여자

2022.08.16

구글이 오픈소스 프로젝트에 얼마나 매진하는지는 깃허브 기여자 수에서 드러난다. 한편 AWS의 전략은 고객들이 오픈소스를 사용하기 쉽게 만드는 것이다. 누가 이기고 있는가?   구글의 오픈소스 사랑은 공공연하다. 필자는 이 회사의 오픈소스 부문 책임자 크리스 디보나가 더 많은 일을 해야 한다고 언급한 적 있긴 하지만 구글만큼 오픈소스에 많이 기여하는 회사가 없다는 게 현실이다. 이는 오픈소스 기여 지수(Open Source Contributor Index; OCSI)에서 알 수 있다. 2022년 7월 깃허브의 오픈소스 프로젝트에 기여한 총직원 수에서 구글은 마이크로소프트를 앞질렀다.   물론 이는 드루팔(Drupal; PHP 기반의 오픈소스 CMS 서비스) 등의 큰 프로젝트를 포함하지 않는 깃허브의 데이터일 뿐이다. 또한 직원들의 회사 정보 입력 여부나 간단하게는 리포지토리 위생(repository hygiene)에 따라 달라질 수 있다. 그렇다. 이는 오픈소스 기여 데이터를 물어보기에 적절한 질문이 아니다. 진짜 질문은 ‘오픈소스 기여가 중요한지 여부’여야 한다.  진입로에서 어디로? 일반적으로 오픈소스는 ‘다른 것이 섞이지 않은(unalloyed)’ 제품으로 간주된다. 그렇지 않은가? 어찌 됐든 오픈소스는 좋다. 예를 들면 커뮤니티 중심의 쿠버네티스를 제공하는 것은 코드로 협업하는 좋은 방법이다. 이는 또한 채용하거나 일자리를 구할 수 있는 좋은 방법이다. 아울러 경쟁사 유료 제품의 무료 대안을 만들어 경쟁사를 약화시키는 중요한 방법이기도 하다. 하지만 오픈소스가 무너질 수 있는 곳이기도 하다.    필자는 지난 2017년 ‘오픈소스 진입로(open source on-ramps)’에 관해 이야기한 바 있다. 이는 클라우드 서비스를 보완하는 오픈소스화의 관행이다. 특히 구글은 이 작업을 매우 잘 수행했다. 브루킹스 연구소(Brookings Institution)의 연구원 알렉스 잉글러는 “구글과 페이스북이 ...

2022.08.16

‘협업’ 레벨 업··· 오픈소스 프로젝트 8선

오늘날 디지털 워크스페이스의 핵심은 ‘협업’이다. 게다가 수많은 팀이 원격으로 이동하면서 혁신적인 (협업) 도구의 필요성은 그 어느 때보다 커지고 있다. 여기서는 분산된 팀, 홈 오피스, 최신 하이브리드 워크플레이스에 상관없이 가상 협업을 한 단계 끌어올릴 수 있는 8가지 오픈소스 프로젝트를 소개한다.     짓시(Jitsi) 코로나19 팬데믹은 끝날 수도 있고 끝나지 않을 수도 있지만 어찌 됐든 이제 원격근무와 화상통화는 하나의 일상으로 자리 잡았다. ‘짓시’는 브라우저-측 코드와 서버-측 브릿지를 모두 제공하는 오픈소스 프로젝트다. 이를 통해 줌(Zoom)이나 구글 미트(Google Meet)를 쓸 필요 없이 통화를 호스팅할 수 있다.  줄립(Zulip) 또한 대부분의 팀은 실시간으로 그리고 비동기적으로 업무를 논의할 방법이 필요하다. ‘줄립’은 이에 적합한 메시징 플랫폼이다. 슬랙(Slack)의 오픈소스 대안인 줄립을 사용하면 코드를 제어할 수 있다. 주요 스마트폰 및 데스크톱 플랫폼용 맞춤형 앱도 제공된다.  매터모스트(Mattermost) ‘매터모스트’는 팀 간의 커뮤니케이션을 지원하는 또 다른 자체 호스팅 메시지 도구다. 특히 소프트웨어 개발을 위해 설계됐다. 이 오픈소스 프로젝트는 커뮤니티가 활성화돼 있으며, 해당 커뮤니티는 메시지 흐름을 안전하기 관리하기 위한 서버를 구축했다. 매터모스트의 차별점은 체크리스트, 코딩 회고 등 전문 기능이 포함된 소프트웨어 개발 플레이북 모음이다. 아울러 이는 웹 애플리케이션 및 모바일 도구로도 사용할 수 있다.  신닷인(Cyn.in) 공유 공간이 필요한 프로젝트라면 이 오픈소스 프로젝트에 주목할 필요가 있다. 이는 IRL 프로젝트 랩 또는 ‘워룸(war room; 프로젝트를 진행하는 모든 사람을 한데 모아 의사소통하고 논의하는 곳)’에서 경험할 수 있는 공유 액세스를 복제한다. 커뮤니티 에디션은 위키 및 협업 파일 저장소 등의 데이터 공유 기능을 제공한다. 콘...

협업 오픈소스 원격근무 재택근무 하이브리드 근무 가상 협업

2022.08.16

오늘날 디지털 워크스페이스의 핵심은 ‘협업’이다. 게다가 수많은 팀이 원격으로 이동하면서 혁신적인 (협업) 도구의 필요성은 그 어느 때보다 커지고 있다. 여기서는 분산된 팀, 홈 오피스, 최신 하이브리드 워크플레이스에 상관없이 가상 협업을 한 단계 끌어올릴 수 있는 8가지 오픈소스 프로젝트를 소개한다.     짓시(Jitsi) 코로나19 팬데믹은 끝날 수도 있고 끝나지 않을 수도 있지만 어찌 됐든 이제 원격근무와 화상통화는 하나의 일상으로 자리 잡았다. ‘짓시’는 브라우저-측 코드와 서버-측 브릿지를 모두 제공하는 오픈소스 프로젝트다. 이를 통해 줌(Zoom)이나 구글 미트(Google Meet)를 쓸 필요 없이 통화를 호스팅할 수 있다.  줄립(Zulip) 또한 대부분의 팀은 실시간으로 그리고 비동기적으로 업무를 논의할 방법이 필요하다. ‘줄립’은 이에 적합한 메시징 플랫폼이다. 슬랙(Slack)의 오픈소스 대안인 줄립을 사용하면 코드를 제어할 수 있다. 주요 스마트폰 및 데스크톱 플랫폼용 맞춤형 앱도 제공된다.  매터모스트(Mattermost) ‘매터모스트’는 팀 간의 커뮤니케이션을 지원하는 또 다른 자체 호스팅 메시지 도구다. 특히 소프트웨어 개발을 위해 설계됐다. 이 오픈소스 프로젝트는 커뮤니티가 활성화돼 있으며, 해당 커뮤니티는 메시지 흐름을 안전하기 관리하기 위한 서버를 구축했다. 매터모스트의 차별점은 체크리스트, 코딩 회고 등 전문 기능이 포함된 소프트웨어 개발 플레이북 모음이다. 아울러 이는 웹 애플리케이션 및 모바일 도구로도 사용할 수 있다.  신닷인(Cyn.in) 공유 공간이 필요한 프로젝트라면 이 오픈소스 프로젝트에 주목할 필요가 있다. 이는 IRL 프로젝트 랩 또는 ‘워룸(war room; 프로젝트를 진행하는 모든 사람을 한데 모아 의사소통하고 논의하는 곳)’에서 경험할 수 있는 공유 액세스를 복제한다. 커뮤니티 에디션은 위키 및 협업 파일 저장소 등의 데이터 공유 기능을 제공한다. 콘...

2022.08.16

마이크로소프트의 오픈소스 SBOM 생성기 살펴보기

솔라윈즈(SolarWinds) 해킹 사건 이후, 기업은 CI/CD를 도입하는 과정에서 확인해야 할 것이 많아졌다. 사용자에게 배포하는 소프트웨어를 의도한 대로 구축하려면 어떻게 해야 하는가? 코드의 의존성이 모두 원하는 형태로 나타났는가? 서드파티 모듈을 사용하면 기대한 결과를 얻을 수 있는가? 같은 질문을 던져야 하는 것이다.    겹겹이 쌓인 코드와 의존성으로 시스템은 점점 복잡해지고 있다. 거기다 현대 시대의 개발자는 공개된 소스코드를 활용한다. 남이 만든 코드이지만 사람들은 그 소스코드를 있는 그대로 신뢰한다. 하이퍼텍스트라는 용어를 고안한 걸로 유명한 옥스포드대 교수 테드 넬슨의 표현처럼, 모든 기술이 이제 서로 심층적으로 얽히고설켜 있는 것이다. 이때 소스코드의 신뢰를 확인하기 위한 방안으로 SBOM이 떠오르고 있다.    SBOM이 필요한 이유 솔라윈즈 해킹 사건이 일어난 후 미국 행정부는 국가 사이버 보안을 높이겠다는 행정명령을 따로 발표하고 미 국립 표준기술연구소(National Institute of Standards and Technology)에게 관련 지침을 개발 및 배포하라고 지시했다. 해당 지침은 소프트웨어 공급망, 모듈 네트워크, 코드 개발에 사용되는 구성요소의 보안을 강화하는 방안을 골자로 하고 있으며, 현재 외부에 공개된 상태다. 이 문서는 기업에게 코드와 함께 소프트웨어 명세서(Software Bill of Material, SBOM)를 함께 제시하라고 요청하고 있다.  사실 SBOM은 새로운 것이 아니다. 마이크로소프트를 포함한 많은 기업이 기술 상세 정보를 사용자에게 제공하고 있었다. 대신 표준화된 문서는 없었으며, 기업마다 그 구조가 다 달랐고, 기계가 판독할 수 없는 형태이기도 했다. 그래서 마이크로소프트는 SBOM 스키마 표준을 개발하기 CISQ(Consortium for Information and Software Quality)라는 그룹과 협력했다. 미 정부가 SBO...

SBOM 오픈소스

2022.08.02

솔라윈즈(SolarWinds) 해킹 사건 이후, 기업은 CI/CD를 도입하는 과정에서 확인해야 할 것이 많아졌다. 사용자에게 배포하는 소프트웨어를 의도한 대로 구축하려면 어떻게 해야 하는가? 코드의 의존성이 모두 원하는 형태로 나타났는가? 서드파티 모듈을 사용하면 기대한 결과를 얻을 수 있는가? 같은 질문을 던져야 하는 것이다.    겹겹이 쌓인 코드와 의존성으로 시스템은 점점 복잡해지고 있다. 거기다 현대 시대의 개발자는 공개된 소스코드를 활용한다. 남이 만든 코드이지만 사람들은 그 소스코드를 있는 그대로 신뢰한다. 하이퍼텍스트라는 용어를 고안한 걸로 유명한 옥스포드대 교수 테드 넬슨의 표현처럼, 모든 기술이 이제 서로 심층적으로 얽히고설켜 있는 것이다. 이때 소스코드의 신뢰를 확인하기 위한 방안으로 SBOM이 떠오르고 있다.    SBOM이 필요한 이유 솔라윈즈 해킹 사건이 일어난 후 미국 행정부는 국가 사이버 보안을 높이겠다는 행정명령을 따로 발표하고 미 국립 표준기술연구소(National Institute of Standards and Technology)에게 관련 지침을 개발 및 배포하라고 지시했다. 해당 지침은 소프트웨어 공급망, 모듈 네트워크, 코드 개발에 사용되는 구성요소의 보안을 강화하는 방안을 골자로 하고 있으며, 현재 외부에 공개된 상태다. 이 문서는 기업에게 코드와 함께 소프트웨어 명세서(Software Bill of Material, SBOM)를 함께 제시하라고 요청하고 있다.  사실 SBOM은 새로운 것이 아니다. 마이크로소프트를 포함한 많은 기업이 기술 상세 정보를 사용자에게 제공하고 있었다. 대신 표준화된 문서는 없었으며, 기업마다 그 구조가 다 달랐고, 기계가 판독할 수 없는 형태이기도 했다. 그래서 마이크로소프트는 SBOM 스키마 표준을 개발하기 CISQ(Consortium for Information and Software Quality)라는 그룹과 협력했다. 미 정부가 SBO...

2022.08.02

“C++의 후계자가 목표”··· 구글, ‘카본’ 공개

‘C++’을 대체하기 위해 개발 중인 오픈소스 프로그래밍 언어 ‘카본(Carbon)’은 C++과 동일한 수준의 성능 그리고 호환성을 지원하는 한편, 기술적 부채와 고질적인 문제를 해결할 계획이다.  전 세계에서 가장 많이 쓰이는 프로그래밍 언어 중 하나인 ‘C++’의 후계자가 필요한 시점이라고 생각하는가? 구글의 개발자 그룹은 그렇다고 보고 있다.     해당 그룹은 C++과의 상호 운용성을 제공하는 동시에, 이 레거시 언어를 개선하는 데 있어 알려진 문제를 해결하는 실험적 프로그래밍 언어 ‘카본’을 개발하고 있다. 개발팀에 따르면 카본은 C 또는 C++이 수십 년간 쌓아온 기술적 부채를 상속하지 않으면서 최신 제네릭 시스템, 간단한 구문, 모듈식 코드 구성 등의 기반으로 시작하여 앞서 언급한 장애물을 극복하려고 시도 중이다.  현재 카본은 사용 가능한 상태는 아니다. 카본 개발팀은 C++이 퍼포먼스 크리티컬 소프트웨어 구축에 지배적인 프로그래밍 언어이며, 방대한 코드 기반이 있다고 말했다. 이에 카본은 ‘진화’보다는 ‘후속 접근 방식’을 제시하며, 기존 C++ 코드 기반 및 C++ 개발자를 위한 마이그레이션을 지원할 것이라고 전했다.  카본은 지난주 캐나다 토론토에서 열린 개발자 컨퍼런스 ‘C++노스(CPP North)’에서 공개됐다. 카본의 리소스는 해당 프로젝트의 깃허브 리포지토리에서 액세스할 수 있다. 개발팀은 C++ 후계자로써의 요건을 다음과 같이 언급하면서, 카본의 접근 방식이 C++ 생태계 위에 구축될 수 있다고 밝혔다.  • C++과 동일한 수준의 성능  • C++과의 원활한 상호 운용성 • 완만한 학습 곡선 • 비슷한 표현식 • 확장 가능한 마이그레이션  카본은 타입스크립트가 자바스크립트, 코틀린이 자바와 비슷한 것처럼 C++과 유사하게 설계됐다. 개발팀은 카본이 퍼포먼스 크리티컬 소프트웨어, 소프트웨어 및 언어 발전을 지원하고, 안전하며 읽기 및 쓰기가 쉬운 ...

C++ 카본 구글 프로그래밍 언어 개발 언어 오픈소스

2022.07.29

‘C++’을 대체하기 위해 개발 중인 오픈소스 프로그래밍 언어 ‘카본(Carbon)’은 C++과 동일한 수준의 성능 그리고 호환성을 지원하는 한편, 기술적 부채와 고질적인 문제를 해결할 계획이다.  전 세계에서 가장 많이 쓰이는 프로그래밍 언어 중 하나인 ‘C++’의 후계자가 필요한 시점이라고 생각하는가? 구글의 개발자 그룹은 그렇다고 보고 있다.     해당 그룹은 C++과의 상호 운용성을 제공하는 동시에, 이 레거시 언어를 개선하는 데 있어 알려진 문제를 해결하는 실험적 프로그래밍 언어 ‘카본’을 개발하고 있다. 개발팀에 따르면 카본은 C 또는 C++이 수십 년간 쌓아온 기술적 부채를 상속하지 않으면서 최신 제네릭 시스템, 간단한 구문, 모듈식 코드 구성 등의 기반으로 시작하여 앞서 언급한 장애물을 극복하려고 시도 중이다.  현재 카본은 사용 가능한 상태는 아니다. 카본 개발팀은 C++이 퍼포먼스 크리티컬 소프트웨어 구축에 지배적인 프로그래밍 언어이며, 방대한 코드 기반이 있다고 말했다. 이에 카본은 ‘진화’보다는 ‘후속 접근 방식’을 제시하며, 기존 C++ 코드 기반 및 C++ 개발자를 위한 마이그레이션을 지원할 것이라고 전했다.  카본은 지난주 캐나다 토론토에서 열린 개발자 컨퍼런스 ‘C++노스(CPP North)’에서 공개됐다. 카본의 리소스는 해당 프로젝트의 깃허브 리포지토리에서 액세스할 수 있다. 개발팀은 C++ 후계자로써의 요건을 다음과 같이 언급하면서, 카본의 접근 방식이 C++ 생태계 위에 구축될 수 있다고 밝혔다.  • C++과 동일한 수준의 성능  • C++과의 원활한 상호 운용성 • 완만한 학습 곡선 • 비슷한 표현식 • 확장 가능한 마이그레이션  카본은 타입스크립트가 자바스크립트, 코틀린이 자바와 비슷한 것처럼 C++과 유사하게 설계됐다. 개발팀은 카본이 퍼포먼스 크리티컬 소프트웨어, 소프트웨어 및 언어 발전을 지원하고, 안전하며 읽기 및 쓰기가 쉬운 ...

2022.07.29

"개발자에 좋은 건 해커에게도..." 오픈소스 SW 공급망 보안 문제의 해법

소프트웨어 공급망 보안에 대한 권한은 누가 가져야 할까? 개발자 혹은 개발자를 지원하는 플랫폼과 보안 엔지니어링 팀? 과거에는 기업의 지원 계약 및 보안 서비스수준협약(SLA)을 어느 리눅스 배포판과 운영체제, 인프라 플랫폼으로부터 확보할지를 CIO, CISO, 또는 CTO와 담당 보안팀이 결정하곤 했다. 하지만 이후 개발자가 이 모든 일을 도커 파일(Docker Files)과 깃허브 액션(GitHub Actions)에서 처리하게 됐다. 개발자에게 상황이 ‘시프트 레프트(shift left)’했고 이전과 같은 기업 차원의 감독은 사라졌다.   오늘날에는 규정 준수 및 보안 팀이 이런 정책과 요건을 규정한다. 개발자는 이 요건을 준수하는 범주 내에서 원하는 도구를 선택할 유연성을 갖는다. 이처럼 업무가 구분되면 개발자 생산성에 가속도가 크게 붙는다. 그러나 Log4j 사태는 기업의 시스템 보안 문제에 대한 경종을 울렸다. 시프트 레프트 개발자 자율성과 생산성의 장점에도 불구하고 소프트웨어 공급망을 이루는 오픈소스 구성요소는 악성 행위자가 노리는 새로운 표적이 되고 말았다.   오픈소스는 개발자와 공격자 모두에게 좋다 네트워크 보안은 공격자 입장에서 예전보다 훨씬 더 어려운 공격 벡터가 됐다. 반면 오픈소스라면? 오픈소스 의존성 또는 라이브러리를 찾아 개입한 후 다른 모든 의존성으로 방향을 전환하면 그만이다. 공급망은 기업과 기업의 소프트웨어 산출물 사이의 연결 고리가 중요하다. 오늘날 공격자는 바로 이 부분을 집중적으로 공략하고 있다. 기본적으로 개발자 입장에서 오픈소스 소프트웨어의 장점은 공격자 입장에서도 장점이다. 개방성: 개발자는 ‘누구나 코드를 볼 수 있고 누구나 코드에 기여할 수 있다’는 점을 좋아한다. 리누스 토발스의 말처럼 “지켜보는 눈이 많으면 모든 버그는 잡아내기 쉬워지고” 이는 오픈소스의 큰 장점이다. 반면 공격자는 ‘깃허브 계정이 있는 사람이라면 누구나 필수 라이브러리에 코드에 기여할 수 있다’는 점을 대단히 좋아한다...

오픈소스 보안

2022.07.25

소프트웨어 공급망 보안에 대한 권한은 누가 가져야 할까? 개발자 혹은 개발자를 지원하는 플랫폼과 보안 엔지니어링 팀? 과거에는 기업의 지원 계약 및 보안 서비스수준협약(SLA)을 어느 리눅스 배포판과 운영체제, 인프라 플랫폼으로부터 확보할지를 CIO, CISO, 또는 CTO와 담당 보안팀이 결정하곤 했다. 하지만 이후 개발자가 이 모든 일을 도커 파일(Docker Files)과 깃허브 액션(GitHub Actions)에서 처리하게 됐다. 개발자에게 상황이 ‘시프트 레프트(shift left)’했고 이전과 같은 기업 차원의 감독은 사라졌다.   오늘날에는 규정 준수 및 보안 팀이 이런 정책과 요건을 규정한다. 개발자는 이 요건을 준수하는 범주 내에서 원하는 도구를 선택할 유연성을 갖는다. 이처럼 업무가 구분되면 개발자 생산성에 가속도가 크게 붙는다. 그러나 Log4j 사태는 기업의 시스템 보안 문제에 대한 경종을 울렸다. 시프트 레프트 개발자 자율성과 생산성의 장점에도 불구하고 소프트웨어 공급망을 이루는 오픈소스 구성요소는 악성 행위자가 노리는 새로운 표적이 되고 말았다.   오픈소스는 개발자와 공격자 모두에게 좋다 네트워크 보안은 공격자 입장에서 예전보다 훨씬 더 어려운 공격 벡터가 됐다. 반면 오픈소스라면? 오픈소스 의존성 또는 라이브러리를 찾아 개입한 후 다른 모든 의존성으로 방향을 전환하면 그만이다. 공급망은 기업과 기업의 소프트웨어 산출물 사이의 연결 고리가 중요하다. 오늘날 공격자는 바로 이 부분을 집중적으로 공략하고 있다. 기본적으로 개발자 입장에서 오픈소스 소프트웨어의 장점은 공격자 입장에서도 장점이다. 개방성: 개발자는 ‘누구나 코드를 볼 수 있고 누구나 코드에 기여할 수 있다’는 점을 좋아한다. 리누스 토발스의 말처럼 “지켜보는 눈이 많으면 모든 버그는 잡아내기 쉬워지고” 이는 오픈소스의 큰 장점이다. 반면 공격자는 ‘깃허브 계정이 있는 사람이라면 누구나 필수 라이브러리에 코드에 기여할 수 있다’는 점을 대단히 좋아한다...

2022.07.25

‘록키 리눅스 9.0’ GA 버전 출시··· “새 빌드 시스템 제공”

레드햇 엔터프라이즈 리눅스(RHEL; Red Hat Enterprise Linux)의 소스 코드를 사용해 만든 무료 리눅스 배포판이자 오픈소스 엔터프라이즈 OS ‘록키 리눅스(Rocky Linux)’의 최신 릴리즈가 GA 버전으로 출시됐다. 이번 업데이트에는 새로운 보안 및 네트워크 기능과 ‘페리도트(Peridot)’라는 새 오픈소스 빌드 시스템이 추가됐다.    지난 7월 14일(현지 시각) 공개된 ‘록키 리눅스 9.0’는 개발자가 커뮤니티 또는 업스트림 지원 조직과 독립적으로 무언가 하려는 경우, 록키 리눅스를 선택하거나 OS를 확장 혹은 재생산할 수 있는 모든 빌드 체인 인프라 도구를 제공한다. 새로운 클라우드 네이티브 빌드 시스템 개발의 목표는 새 RHEL 버전 출시 후 일주일 이내에 록키의 새 버전이 출시될 수 있도록 하는 것이라고 프로젝트 담당자는 밝혔다.  페리도트의 소스 코드는 깃허브에서 확인할 수 있으며, 머지않아 헬름(Helm) 차트를 통해 쉽게 설치할 수 있을 것이라고 회사 측은 전했다. 록키 리눅스는 이곳에서 다운로드할 수 있다. 록키 엔터프라이즈 소프트웨어 재단(RESF)에서 호스팅하는 록키 리눅스는 센트OS(CentOS) 공동 창시자이자 CIQ의 CEO 그레고리 커처가 센트OS의 (원래) 목표인 RHEL의 프로덕션 레디 다운스트림 버전을 제공하기 위해 개발했다.  CIQ에서 개발하고 RESF에서 제공하는 페리도트는 록키 리눅스를 구축 및 관리하기 위한 클라우드 네이티브 스택 역할을 한다. 이 스택은 오픈소스로 출시됐다. 록키 리눅스는 오픈소스 도구를 사용하여 센트OS 수명 종료 문제가 반복되지 않도록 ‘재생산 가능한(reproducible)’ 운영체제를 제공한다. 이 밖에 록키 리눅스 9.0의 새로운 기능 및 변경 사항은 다음과 같다.  • SE리눅스(SELinux) 성능, 메모리 오버헤드, 로드 시간이 개선됐다.  • 현재 버전 3.0.1인 오픈SSL(OpenSSL)은...

록키 리눅스 리눅스 리눅스 배포판 소프트웨어 개발 클라우드 컴퓨팅 오픈소스

2022.07.15

레드햇 엔터프라이즈 리눅스(RHEL; Red Hat Enterprise Linux)의 소스 코드를 사용해 만든 무료 리눅스 배포판이자 오픈소스 엔터프라이즈 OS ‘록키 리눅스(Rocky Linux)’의 최신 릴리즈가 GA 버전으로 출시됐다. 이번 업데이트에는 새로운 보안 및 네트워크 기능과 ‘페리도트(Peridot)’라는 새 오픈소스 빌드 시스템이 추가됐다.    지난 7월 14일(현지 시각) 공개된 ‘록키 리눅스 9.0’는 개발자가 커뮤니티 또는 업스트림 지원 조직과 독립적으로 무언가 하려는 경우, 록키 리눅스를 선택하거나 OS를 확장 혹은 재생산할 수 있는 모든 빌드 체인 인프라 도구를 제공한다. 새로운 클라우드 네이티브 빌드 시스템 개발의 목표는 새 RHEL 버전 출시 후 일주일 이내에 록키의 새 버전이 출시될 수 있도록 하는 것이라고 프로젝트 담당자는 밝혔다.  페리도트의 소스 코드는 깃허브에서 확인할 수 있으며, 머지않아 헬름(Helm) 차트를 통해 쉽게 설치할 수 있을 것이라고 회사 측은 전했다. 록키 리눅스는 이곳에서 다운로드할 수 있다. 록키 엔터프라이즈 소프트웨어 재단(RESF)에서 호스팅하는 록키 리눅스는 센트OS(CentOS) 공동 창시자이자 CIQ의 CEO 그레고리 커처가 센트OS의 (원래) 목표인 RHEL의 프로덕션 레디 다운스트림 버전을 제공하기 위해 개발했다.  CIQ에서 개발하고 RESF에서 제공하는 페리도트는 록키 리눅스를 구축 및 관리하기 위한 클라우드 네이티브 스택 역할을 한다. 이 스택은 오픈소스로 출시됐다. 록키 리눅스는 오픈소스 도구를 사용하여 센트OS 수명 종료 문제가 반복되지 않도록 ‘재생산 가능한(reproducible)’ 운영체제를 제공한다. 이 밖에 록키 리눅스 9.0의 새로운 기능 및 변경 사항은 다음과 같다.  • SE리눅스(SELinux) 성능, 메모리 오버헤드, 로드 시간이 개선됐다.  • 현재 버전 3.0.1인 오픈SSL(OpenSSL)은...

2022.07.15

리뷰 | RHEL 9, 보안ㆍ관리 기능 강화한 기업용 리눅스 대표주자

레드햇 엔터프라이즈 리눅스(RHEL)의 최신 릴리스인 RHEL 9.0이 나왔다. 엔터프라이즈 서버와 클라우드 환경을 위한 더 견고한 보안을 지원하고 설치, 배포, 관리 기능도 개선됐다.   RHEL 9.0의 코드명은 '플로우(Plow)'다. RHEL 8.0 대비 큰 폭의 업그레이드로, 이를 이용하면 애플리케이션 개발자가 컨테이너를 더 쉽게 테스트하고 배포할 수 있다. 서버와 데스크톱 버전으로 제공되며, 안정성과 신뢰성, 견고함을 바탕으로 엔터프라이즈 워크로드를 위한 주요 리눅스 배포판이라는 위상을 잘 유지하고 있다. 소프트웨어 개발 용도로는 무료지만 인스턴스를 사용하려면 레드햇 구독 관리(RHSM) 서비스에 등록해야 한다. IBM의 자회사인 레드햇은 연중무휴 24시간 구독 기반 고객 지원과 전문 통합 서비스를 제공한다. 이렇게 구독을 통해 벌어들이는 수익으로 RHEL 자체에 포함되는 업스트림 기능을 비롯한 다른 오픈소스 프로젝트를 지원한다.   RHEL 9가 우리 기업 환경에 맞을까 RHEL 9는 다양한 물리적 하드웨어에서 실행하거나 하이퍼바이저의 가상머신, 컨테이너, 또는 서비스형 인프라(IaaS) 퍼블릭 클라우드 서비스의 인스턴스로 실행할 수 있다. 레거시 x86 하드웨어와 64비트 x86_64-v2, aarch64, ARMv8.0-A 하드웨어 아키텍처는 물론 IBM 파워 9, 파워 10, Z-시리즈(z14) 하드웨어 플랫폼을 지원한다. 보편적인 Ext4 파일 시스템, GFS2와 XFS를 포함한 다양한 데이터 스토리지 파일 시스템을 지원하고, Ext2, Ext3, vfat(FAT32)을 위한 레거시도 마찬가지다. RHEL은 대규모 영구 및 단기 저장 공간을 확장할 수 있는데 RHEL 9에서는 x86_64 아키텍처를 위한 최대 메모리 용량이 48TB로 늘었다.   RHEL 9 설치하기 RHEL 9를 설치하려면 먼저 운영체제를 다운로드해 간단한 몇 가지 단계를 따른다. RHEL 9를 설치할 때 '소프트웨어 선택(Software...

레드햇 RHEL 리눅스 오픈소스

2022.07.14

레드햇 엔터프라이즈 리눅스(RHEL)의 최신 릴리스인 RHEL 9.0이 나왔다. 엔터프라이즈 서버와 클라우드 환경을 위한 더 견고한 보안을 지원하고 설치, 배포, 관리 기능도 개선됐다.   RHEL 9.0의 코드명은 '플로우(Plow)'다. RHEL 8.0 대비 큰 폭의 업그레이드로, 이를 이용하면 애플리케이션 개발자가 컨테이너를 더 쉽게 테스트하고 배포할 수 있다. 서버와 데스크톱 버전으로 제공되며, 안정성과 신뢰성, 견고함을 바탕으로 엔터프라이즈 워크로드를 위한 주요 리눅스 배포판이라는 위상을 잘 유지하고 있다. 소프트웨어 개발 용도로는 무료지만 인스턴스를 사용하려면 레드햇 구독 관리(RHSM) 서비스에 등록해야 한다. IBM의 자회사인 레드햇은 연중무휴 24시간 구독 기반 고객 지원과 전문 통합 서비스를 제공한다. 이렇게 구독을 통해 벌어들이는 수익으로 RHEL 자체에 포함되는 업스트림 기능을 비롯한 다른 오픈소스 프로젝트를 지원한다.   RHEL 9가 우리 기업 환경에 맞을까 RHEL 9는 다양한 물리적 하드웨어에서 실행하거나 하이퍼바이저의 가상머신, 컨테이너, 또는 서비스형 인프라(IaaS) 퍼블릭 클라우드 서비스의 인스턴스로 실행할 수 있다. 레거시 x86 하드웨어와 64비트 x86_64-v2, aarch64, ARMv8.0-A 하드웨어 아키텍처는 물론 IBM 파워 9, 파워 10, Z-시리즈(z14) 하드웨어 플랫폼을 지원한다. 보편적인 Ext4 파일 시스템, GFS2와 XFS를 포함한 다양한 데이터 스토리지 파일 시스템을 지원하고, Ext2, Ext3, vfat(FAT32)을 위한 레거시도 마찬가지다. RHEL은 대규모 영구 및 단기 저장 공간을 확장할 수 있는데 RHEL 9에서는 x86_64 아키텍처를 위한 최대 메모리 용량이 48TB로 늘었다.   RHEL 9 설치하기 RHEL 9를 설치하려면 먼저 운영체제를 다운로드해 간단한 몇 가지 단계를 따른다. RHEL 9를 설치할 때 '소프트웨어 선택(Software...

2022.07.14

칼럼 | ‘경기 침체가 오히려 호황기’ 오픈소스 개발자여, 지금이 기회다

고용 불안정을 벗어나고 싶다면, 오픈소스 소프트웨어와 가깝게 지내야 할 때다. 오픈소스 프로젝트를 활용하는 회사에 취업하거나 프로젝트 커뮤니티에 직접 기여해라.    경기 침체기에 진입한 것일까? 월스트리트의 저널(WSJ)의 대답은 ‘애매모호하다’라고 표현할 수 있다. 해당 매체는 지난 4일(현지 시각) ‘만약 미국이 경기 침체기에 접어든 것이 사실이라면, 이는 매우 독특한 형태의 경기 불황이다(If the U.S. is in a Recession, It’s a Very Strange One)’라는 제목의 기사를 게재하며 이런 투의 해석을 내놓았다. 경제의 총생산량이 하락했음에도 채용 시장은 아직 활발한 움직임을 보이고 있기 때문이라고 기사는 설명했다.  하지만 해당 기사는 벌서 2달 전인 5월의 경제 지표를 분석한 결과다. 현재 미국 테크 업계의 분위기는 심상치 않다. 최근 테크 기업이 신규 채용을 줄이고 심지어 정리해고를 단행하고 있기 때문이다. 항상 낙관적인 전망으로 가득 차 있는 벤처 투자 업계조차도 위험 부담이 큰 장기적인 투자 대신 단기수익 포트폴리오에 관심을 더 쏟고 있는 형국이다.  닷컴버블과 2008년 금융위기 같은 우여곡절을 겪은 세대에게 이런 광경은 역사의 반복처럼 느껴진다. 이런 경제난에 기업은 항상 비슷한 행태를 보인다. 투자를 진행하지만 대상을 선정하는 데 더 까다로워진다. 아울러, 오픈소스 소프트웨어에 더 많이 의존하게 되는 경향을 띠기 시작한다. 따라서 만약 고용 불안감에 허덕이고 있다면, 오픈소스가 원하는 기업으로 들어가는 길을 열여주는 '입장권'이 될 수 있을지도 모른다.  경기 침체에도 ‘끄떡없는’ 오픈소스  필자는 2007년에 한 가지 예측을 했다. 오픈소스가 “효율성을 최우선으로 설계되어 불황이 닥쳐도 가장 타격을 덜 받을 것”이라고 말했다. 그리고 오늘날, 이 예측은 맞아떨어졌다. 이를 증명할 만한 수치는 없지만, 오픈소스 기반 서비스 제공업체는 경기 불황...

오픈소스 오픈소스커뮤니티 경기침체 금융위기 닷컴버블

2022.07.12

고용 불안정을 벗어나고 싶다면, 오픈소스 소프트웨어와 가깝게 지내야 할 때다. 오픈소스 프로젝트를 활용하는 회사에 취업하거나 프로젝트 커뮤니티에 직접 기여해라.    경기 침체기에 진입한 것일까? 월스트리트의 저널(WSJ)의 대답은 ‘애매모호하다’라고 표현할 수 있다. 해당 매체는 지난 4일(현지 시각) ‘만약 미국이 경기 침체기에 접어든 것이 사실이라면, 이는 매우 독특한 형태의 경기 불황이다(If the U.S. is in a Recession, It’s a Very Strange One)’라는 제목의 기사를 게재하며 이런 투의 해석을 내놓았다. 경제의 총생산량이 하락했음에도 채용 시장은 아직 활발한 움직임을 보이고 있기 때문이라고 기사는 설명했다.  하지만 해당 기사는 벌서 2달 전인 5월의 경제 지표를 분석한 결과다. 현재 미국 테크 업계의 분위기는 심상치 않다. 최근 테크 기업이 신규 채용을 줄이고 심지어 정리해고를 단행하고 있기 때문이다. 항상 낙관적인 전망으로 가득 차 있는 벤처 투자 업계조차도 위험 부담이 큰 장기적인 투자 대신 단기수익 포트폴리오에 관심을 더 쏟고 있는 형국이다.  닷컴버블과 2008년 금융위기 같은 우여곡절을 겪은 세대에게 이런 광경은 역사의 반복처럼 느껴진다. 이런 경제난에 기업은 항상 비슷한 행태를 보인다. 투자를 진행하지만 대상을 선정하는 데 더 까다로워진다. 아울러, 오픈소스 소프트웨어에 더 많이 의존하게 되는 경향을 띠기 시작한다. 따라서 만약 고용 불안감에 허덕이고 있다면, 오픈소스가 원하는 기업으로 들어가는 길을 열여주는 '입장권'이 될 수 있을지도 모른다.  경기 침체에도 ‘끄떡없는’ 오픈소스  필자는 2007년에 한 가지 예측을 했다. 오픈소스가 “효율성을 최우선으로 설계되어 불황이 닥쳐도 가장 타격을 덜 받을 것”이라고 말했다. 그리고 오늘날, 이 예측은 맞아떨어졌다. 이를 증명할 만한 수치는 없지만, 오픈소스 기반 서비스 제공업체는 경기 불황...

2022.07.12

'보안도 왼쪽으로'··· 오픈소스 SW 보안과 시프트레프트 전략의 상관관계

오픈소스 소프트웨어는 대다수 애플리케이션에서 큰 비중을 차지하지만, 개발자와 보안 부서에는 보안 관련 과제를 던지는 존재다. 이번주 공개된 2종의 보고서에는 오픈소스 소프트웨어의 과제를 ‘시프트 레프트’ 전략을 확대 적용하면서 극복할 수 있다는 내용이 실려 주목을 끈다. 개발자 보안 업체인 스니크(Snyk)와 리눅스 재단은 ‘오픈소스 보안 현황(The State of Open Source Security)’ 보고서에서 10곳 중 4곳 이상의 기업(41%)이 오픈소스 보안에 확신이 없다고 지적했다. 또한 지난 3년 간 오픈소스 프로젝트에서의 취약점 수정 기간이 꾸준히 늘어 2018년(49일)보다 2021년(110일)에는 2배가 넘었다고 발표했다.     오픈소스에 대한 논쟁 : 생산성 vs. 보안 550명 이상의 응답자를 확보한 이번 보고서는 애플리케이션 개발 프로젝트의 취약점이 평균 49개, 일명 오픈소스 코드라고 칭하는 직접 의존성이 평균 80개라고 밝혔다. 그러나 오픈소스 소프트웨어 개발 또는 사용에 대한 보안 정책을 마련한 기업은 절반에 약간 못 미치는 49%였다. 규모를 중대형 기업으로 좁혀보면 이 수치는 27%에 지나지 않는다. 스니크 개발 관계 이사인 매트 저비스는 발표문에서 “오늘날 소프트웨어 개발사는 자체적인 공급망을 보유하고 있다. 자동차 부품을 조립하는 것처럼 자사만의 독특한 코드로 기존 오픈소스 구성요소를 이어서 코드를 조립한다. 생산성과 혁신을 대폭 개선할 수는 있지만 그만큼 보안 위험이 커진다는 단점이 있다”라고 지적했다.   "시프트 레프트로 취약점 조기 발견할 수 있어" 애플리케이션 자동화 테스트 업체 시프트 레프트(ShiftLeft) 역시 '애플리케이션 보안 발전(AppSec  Progress)' 보고서를 발행하면서 오픈소스 소프트웨어 보안 역시 시프트 레프트 전략, 또는 소프트웨어 개발 생명주기 시작을 조기에 앞당기는 것으로 보완할 수 있다고 주장했다. 보고서는 시프트레프트의 코어(Cor...

오픈소스소프트웨어 오픈소스 보안 Log4j 시프트레프트 보안테스트

2022.06.27

오픈소스 소프트웨어는 대다수 애플리케이션에서 큰 비중을 차지하지만, 개발자와 보안 부서에는 보안 관련 과제를 던지는 존재다. 이번주 공개된 2종의 보고서에는 오픈소스 소프트웨어의 과제를 ‘시프트 레프트’ 전략을 확대 적용하면서 극복할 수 있다는 내용이 실려 주목을 끈다. 개발자 보안 업체인 스니크(Snyk)와 리눅스 재단은 ‘오픈소스 보안 현황(The State of Open Source Security)’ 보고서에서 10곳 중 4곳 이상의 기업(41%)이 오픈소스 보안에 확신이 없다고 지적했다. 또한 지난 3년 간 오픈소스 프로젝트에서의 취약점 수정 기간이 꾸준히 늘어 2018년(49일)보다 2021년(110일)에는 2배가 넘었다고 발표했다.     오픈소스에 대한 논쟁 : 생산성 vs. 보안 550명 이상의 응답자를 확보한 이번 보고서는 애플리케이션 개발 프로젝트의 취약점이 평균 49개, 일명 오픈소스 코드라고 칭하는 직접 의존성이 평균 80개라고 밝혔다. 그러나 오픈소스 소프트웨어 개발 또는 사용에 대한 보안 정책을 마련한 기업은 절반에 약간 못 미치는 49%였다. 규모를 중대형 기업으로 좁혀보면 이 수치는 27%에 지나지 않는다. 스니크 개발 관계 이사인 매트 저비스는 발표문에서 “오늘날 소프트웨어 개발사는 자체적인 공급망을 보유하고 있다. 자동차 부품을 조립하는 것처럼 자사만의 독특한 코드로 기존 오픈소스 구성요소를 이어서 코드를 조립한다. 생산성과 혁신을 대폭 개선할 수는 있지만 그만큼 보안 위험이 커진다는 단점이 있다”라고 지적했다.   "시프트 레프트로 취약점 조기 발견할 수 있어" 애플리케이션 자동화 테스트 업체 시프트 레프트(ShiftLeft) 역시 '애플리케이션 보안 발전(AppSec  Progress)' 보고서를 발행하면서 오픈소스 소프트웨어 보안 역시 시프트 레프트 전략, 또는 소프트웨어 개발 생명주기 시작을 조기에 앞당기는 것으로 보완할 수 있다고 주장했다. 보고서는 시프트레프트의 코어(Cor...

2022.06.27

오픈소스 MPP 데이터 웨어하우스, ‘아파치 도리스’란? 

‘그’가 누구이고, 어떤 학교에 다녔는지 궁금한가? ‘아파치 도리스(Apache Doris)’는 아파치 인큐베이터(Apache Incubator)에서 개발한 오픈소스 MPP 분석 데이터 웨어하우스다. 지난주 아파치 소프트웨어 재단(Apache Software Foundation; ASF)은 도리스가 최상위 수준 프로젝트(Top-Level Project; TLP)로 승격했다고 발표했다.  MySQL 애널리틱스를 활용하는 이 SQL 기반 데이터 웨어하우스는 최근 버전 1.0 그리고 도리스를 다양한 애널리틱스 및 처리 기술과 연결하는 6개의 커넥터 릴리즈를 함께 출시했다(버전 1.0은 여덟 번째 릴리즈다). 특히 이는 데이터 과학 시나리오에서 자주 사용되는 온라인 분석 처리(OLAP) 워크로드를 지원하기 위해 개발됐다.  도리스는 중국의 인터넷 검색 대기업 바이두(Baidu)에서 태어났으며, 당시에는 ‘팔로(Palo)’라고 불렸다. 2017년 오픈소스화되고, 이어 2018년 아파치 인큐베이터에 기증되기 전까지 (바이두의) 광고 비즈니스를 위한 데이터 웨어하우징 시스템으로 사용됐다.    아파치 임팔라 및 구글 매사를 기반으로 하는 도리스 도리스는 구글 F1(Google F1)을 토대로 2012년 개발된 오픈소스 MPP SQL 쿼리 엔진 구글 매사(Google Mesa)와 아파치 임팔라(Apache Impala)의 기술 통합을 바탕으로 한다. 2014년경 확장성이 뛰어난 분석 데이터 웨어하우징 시스템으로 설계된 매사는 구글의 인터넷 광고 비즈니스와 관련된 중요한 측정 데이터를 저장하는 데 활용됐다.  바이두와 아파치 인큐베이터의 개발자에 따르면 이 데이터베이스는 고가용성, 안정성, 내결함성, 확장성은 물론 단순한 설계 아키텍처까지 제공한다. 아파치 소프트웨어 재단은 공식 성명에서 “단일 시스템(에서의 개발, 배포, 사용)과 많은 데이터 제공 요건을 충족하는 게 도리스의 주요 기능이다”라면서, “이 데이터 웨어하우수...

오픈소스 데이터 웨어하우스 아파치 도리스 아파치 소프트웨어 재단 아파치 인큐베이터 MPP 데이터 과학 바이두 오픈소스 데이터베이스

2022.06.24

‘그’가 누구이고, 어떤 학교에 다녔는지 궁금한가? ‘아파치 도리스(Apache Doris)’는 아파치 인큐베이터(Apache Incubator)에서 개발한 오픈소스 MPP 분석 데이터 웨어하우스다. 지난주 아파치 소프트웨어 재단(Apache Software Foundation; ASF)은 도리스가 최상위 수준 프로젝트(Top-Level Project; TLP)로 승격했다고 발표했다.  MySQL 애널리틱스를 활용하는 이 SQL 기반 데이터 웨어하우스는 최근 버전 1.0 그리고 도리스를 다양한 애널리틱스 및 처리 기술과 연결하는 6개의 커넥터 릴리즈를 함께 출시했다(버전 1.0은 여덟 번째 릴리즈다). 특히 이는 데이터 과학 시나리오에서 자주 사용되는 온라인 분석 처리(OLAP) 워크로드를 지원하기 위해 개발됐다.  도리스는 중국의 인터넷 검색 대기업 바이두(Baidu)에서 태어났으며, 당시에는 ‘팔로(Palo)’라고 불렸다. 2017년 오픈소스화되고, 이어 2018년 아파치 인큐베이터에 기증되기 전까지 (바이두의) 광고 비즈니스를 위한 데이터 웨어하우징 시스템으로 사용됐다.    아파치 임팔라 및 구글 매사를 기반으로 하는 도리스 도리스는 구글 F1(Google F1)을 토대로 2012년 개발된 오픈소스 MPP SQL 쿼리 엔진 구글 매사(Google Mesa)와 아파치 임팔라(Apache Impala)의 기술 통합을 바탕으로 한다. 2014년경 확장성이 뛰어난 분석 데이터 웨어하우징 시스템으로 설계된 매사는 구글의 인터넷 광고 비즈니스와 관련된 중요한 측정 데이터를 저장하는 데 활용됐다.  바이두와 아파치 인큐베이터의 개발자에 따르면 이 데이터베이스는 고가용성, 안정성, 내결함성, 확장성은 물론 단순한 설계 아키텍처까지 제공한다. 아파치 소프트웨어 재단은 공식 성명에서 “단일 시스템(에서의 개발, 배포, 사용)과 많은 데이터 제공 요건을 충족하는 게 도리스의 주요 기능이다”라면서, “이 데이터 웨어하우수...

2022.06.24

컨테이너 분야의 '요즘 애들', 포드맨을 아시나요?

갑자기 플레이어가 많아지고 있는 새로운 컨테이너 지형에서 ‘포드맨(Podman)’은 떠오르는 스타다. 여기서는 포드맨이란 무엇이며, 도커와 어떻게 다른지 등을 살펴본다.  포드맨은 ‘컨테이너 엔진’이다. 즉, 컨테이너 및 컨테이너 이미지를 개발, 관리, 실행하기 위한 도구다. 컨테이너는 사용자 정의 없이 어디서나 실행하는 데 필요한 모든 요소(예: 애플리케이션 코드, 지원 라이브러리 등)를 갖추고 있는 표준화된 독립형 소프트웨어 패키지다. 컨테이너 기반 애플리케이션은 분산형 및 클라우드 기반 시스템을 쉽게 배포하고 유지관리할 수 있게 하면서 소프트웨어 개발에 일대 혁신을 일으켰다.  레드햇의 프로젝트인 포드맨은 오픈소스이며 무료로 다운로드할 수 있다. 이는 지난 2019년 버전 1.0이 출시됐으며, 컨테이너화 업계에서는 비교적 신참이다. 그 이후로 포드맨은 약진을 거듭했다. 게다가 여러 면에서 오늘날의 컨테이너 세계를 만든 프로젝트인 ‘도커(Docker)’의 점진적인 쇠퇴로 이러한 포드맨의 상승세가 더욱 부각되고 있다.    포드맨과 쿠버네티스 컨테이너 기반 개발을 조금이라도 안다면 ‘쿠버네티스(Kubernetes)’도 알 것이다. 컨테이너화된 애플리케이션이 점점 더 복잡해지면서 개발자들은 다양한 가상머신, 심지어는 서로 다른 물리적 머신에서 실행되면서 상호작용하는 컨테이너를 조정할 수 있는 도구가 필요했다.  그러한 도구를 ‘컨테이너 오케스트레이션 플랫폼’이라고 하는데, 그중 쿠버네티스가 가장 유명하다. 쿠버네티스는 오픈 컨테이너 이니셔티브(Open Container Initiative; OCI) 이미지 사양을 충족하는 모든 컨테이너와 함께 사용할 수 있으며, 포드맨의 컨테이너도 마찬가지다. 쿠버네티스의 중요한 특징으로 ‘포드(pod)’ 개념이 있다. 포드란 쿠버네티스가 관리할 수 있는 최소의 컴퓨팅 단위인 하나 이상의 컨테이너를 임시로 그룹화한 것이다. 포드맨 역시 이름에서 알 수 있듯이 포드 개념을 ...

컨테이너 도커 포드맨 쿠버네티스 클라우드 레드햇 오픈소스 오케스트레이션

2022.06.21

갑자기 플레이어가 많아지고 있는 새로운 컨테이너 지형에서 ‘포드맨(Podman)’은 떠오르는 스타다. 여기서는 포드맨이란 무엇이며, 도커와 어떻게 다른지 등을 살펴본다.  포드맨은 ‘컨테이너 엔진’이다. 즉, 컨테이너 및 컨테이너 이미지를 개발, 관리, 실행하기 위한 도구다. 컨테이너는 사용자 정의 없이 어디서나 실행하는 데 필요한 모든 요소(예: 애플리케이션 코드, 지원 라이브러리 등)를 갖추고 있는 표준화된 독립형 소프트웨어 패키지다. 컨테이너 기반 애플리케이션은 분산형 및 클라우드 기반 시스템을 쉽게 배포하고 유지관리할 수 있게 하면서 소프트웨어 개발에 일대 혁신을 일으켰다.  레드햇의 프로젝트인 포드맨은 오픈소스이며 무료로 다운로드할 수 있다. 이는 지난 2019년 버전 1.0이 출시됐으며, 컨테이너화 업계에서는 비교적 신참이다. 그 이후로 포드맨은 약진을 거듭했다. 게다가 여러 면에서 오늘날의 컨테이너 세계를 만든 프로젝트인 ‘도커(Docker)’의 점진적인 쇠퇴로 이러한 포드맨의 상승세가 더욱 부각되고 있다.    포드맨과 쿠버네티스 컨테이너 기반 개발을 조금이라도 안다면 ‘쿠버네티스(Kubernetes)’도 알 것이다. 컨테이너화된 애플리케이션이 점점 더 복잡해지면서 개발자들은 다양한 가상머신, 심지어는 서로 다른 물리적 머신에서 실행되면서 상호작용하는 컨테이너를 조정할 수 있는 도구가 필요했다.  그러한 도구를 ‘컨테이너 오케스트레이션 플랫폼’이라고 하는데, 그중 쿠버네티스가 가장 유명하다. 쿠버네티스는 오픈 컨테이너 이니셔티브(Open Container Initiative; OCI) 이미지 사양을 충족하는 모든 컨테이너와 함께 사용할 수 있으며, 포드맨의 컨테이너도 마찬가지다. 쿠버네티스의 중요한 특징으로 ‘포드(pod)’ 개념이 있다. 포드란 쿠버네티스가 관리할 수 있는 최소의 컴퓨팅 단위인 하나 이상의 컨테이너를 임시로 그룹화한 것이다. 포드맨 역시 이름에서 알 수 있듯이 포드 개념을 ...

2022.06.21

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.31