Offcanvas

���

깃허브, 깃 리포지토리로 구축된 오픈소스 IAM 솔루션 공개

깃허브가 ‘IAM(Identity and Access Management)’용 프레임워크를 사용하는 새로운 방법을 공개했다.  깃허브가 자체 깃 프레임워크를 활용하여 기업 시스템 액세스를 구문 분석, 추적, 승인하는 새로운 IAM 도구(Entitlements; 이하 인타이틀먼트)를 선보였다. 기본 개념은 전용 깃 리포지토리를 ID 관리 데이터의 중앙집중식 정보센터를 제공하는 방법으로 사용하고, 풀 리퀘스트를 통해 변경하는 것이다. 새로운 승인, 재검증 등 모든 변경 사항을 특정 시스템에 지정된 리포지토리에 수행할 수 있다.   또한 관리자는 메타데이터 태그를 활용하여 시스템 액세스 제어 방법을 세분화할 수 있다. 이를테면 오래된 승인은 필수 재검증 대상이 될 수 있고, 서로 다른 태그가 지정된 사용자에게는 서로 다른 권한이 부여될 수 있다.  아울러 깃을 사용하면 전체 프로세스의 자세한 감사 로그를 제공하여 (예를 들어) 누가 어떤 액세스 권한을 요청했는지, 언제 그리고 누가 부여했는지 등을 추적할 수 있다. 관리자, 지역, 액세스 수준 등으로 구성된 그룹의 세부 목록도 확인할 수 있다고 회사 측은 설명했다.  인타이틀먼트가 오픈소스로 전환됐다고 발표한 깃허브의 공식 블로그에 따르면 깃은 ‘수년 동안’ 내부적으로 해당 시스템을 사용해 왔다. 이는 모든 깃 리포지토리에서 쓸 수 있지만 깃허브닷컴과 함께 활용하면 크론(cron) 작업을 사용하여 검토 및 감사를 자동화하거나 비즈니스 데이터 ‘source-of-truth’를 통해 조직도에서 인타이틀먼트 프레임워크로 업데이트를 푸시하는 등 더 많은 기능을 직접 사용할 수 있다.  이 밖에 깃허브는 다른 오픈소스 프로젝트와 마찬가지로 인타이틀먼트도 지속적으로 개선되고 있다고 밝혔다. “매일 이 시스템을 사용하며, 한 달에 평균 약 2,000건의 커밋을 한다. 계속해서 앱을 향상시키고 더 쉽게 쓸 방법을 모색하고 있다. 다른 사용자가 자신의 IAM 요건에 맞게 구축한...

깃허브 깃 리포지토리 IAM ID 관리 액세스 관리 메타데이터 감사

2022.06.13

깃허브가 ‘IAM(Identity and Access Management)’용 프레임워크를 사용하는 새로운 방법을 공개했다.  깃허브가 자체 깃 프레임워크를 활용하여 기업 시스템 액세스를 구문 분석, 추적, 승인하는 새로운 IAM 도구(Entitlements; 이하 인타이틀먼트)를 선보였다. 기본 개념은 전용 깃 리포지토리를 ID 관리 데이터의 중앙집중식 정보센터를 제공하는 방법으로 사용하고, 풀 리퀘스트를 통해 변경하는 것이다. 새로운 승인, 재검증 등 모든 변경 사항을 특정 시스템에 지정된 리포지토리에 수행할 수 있다.   또한 관리자는 메타데이터 태그를 활용하여 시스템 액세스 제어 방법을 세분화할 수 있다. 이를테면 오래된 승인은 필수 재검증 대상이 될 수 있고, 서로 다른 태그가 지정된 사용자에게는 서로 다른 권한이 부여될 수 있다.  아울러 깃을 사용하면 전체 프로세스의 자세한 감사 로그를 제공하여 (예를 들어) 누가 어떤 액세스 권한을 요청했는지, 언제 그리고 누가 부여했는지 등을 추적할 수 있다. 관리자, 지역, 액세스 수준 등으로 구성된 그룹의 세부 목록도 확인할 수 있다고 회사 측은 설명했다.  인타이틀먼트가 오픈소스로 전환됐다고 발표한 깃허브의 공식 블로그에 따르면 깃은 ‘수년 동안’ 내부적으로 해당 시스템을 사용해 왔다. 이는 모든 깃 리포지토리에서 쓸 수 있지만 깃허브닷컴과 함께 활용하면 크론(cron) 작업을 사용하여 검토 및 감사를 자동화하거나 비즈니스 데이터 ‘source-of-truth’를 통해 조직도에서 인타이틀먼트 프레임워크로 업데이트를 푸시하는 등 더 많은 기능을 직접 사용할 수 있다.  이 밖에 깃허브는 다른 오픈소스 프로젝트와 마찬가지로 인타이틀먼트도 지속적으로 개선되고 있다고 밝혔다. “매일 이 시스템을 사용하며, 한 달에 평균 약 2,000건의 커밋을 한다. 계속해서 앱을 향상시키고 더 쉽게 쓸 방법을 모색하고 있다. 다른 사용자가 자신의 IAM 요건에 맞게 구축한...

2022.06.13

“깃보다 더 확장 가능하고 빠르다”··· 피줄(Pijul), 베타로 이동

‘패치 이론(theory of patches)’을 기반으로 하는 이 오픈소스 분산 버전 관리 시스템은 깃(Git)보다 빠르고, 확장 가능하며, 배우고 사용하기 쉽다.  워크플로우를 간소화하는 패치 이론을 기반으로 한 오픈소스 분산 버전 제어 시스템 ‘피줄(Pijul)’이 베타 릴리즈로 이동했다. 해당 프로젝트 공식 문서에 따르면 피줄은 수학적 변경 이론을 바탕으로 하는 최초의 분산 버전 제어 시스템이며, 깃(Git)보다 더 간단하게 작업할 수 있고 대규모 리포지토리와 빠른 속도의 워크플로우로 확장할 수 있다.   피줄 개발팀은 지난 1월 18일(현지 시각) 알파 릴리즈를 내놓은 지 거의 1년 만에 이번 베타 버전을 선보였다. 다운로드 지침은 이곳(pijul.org)에서 확인할 수 있다.  깃과 마찬가지로 피줄은 파일의 변경 사항을 추적하고 되돌릴 수 있으며, 파일을 공동 작성자의 변경 사항과 병합할 수 있다. 하지만 공식 문서에 의하면 피줄은 변경 사항 또는 패치를 다루는 반면 깃은 스냅샷 또는 버전을 처리한다는 점에서 깃 및 기타 버전 제어 시스템과는 다르다.  해당 프로젝트의 리더 피에르 에티엔 뫼니에는 “피줄의 경우 결과를 변경하지 않고 독립적인 변경 사항을 어떤 순서로든 적용할 수 있다”라고 밝혔다. 이어서 그는 “한 브랜치에서 여러 기능을 개발할 수 있으며, 개발자는 비즈니스 방법론 및 제약 조건에 따라 일부 기능만 프로덕션으로 푸시할 수 있다. 또 피줄 데이터 구조는 충돌을 모델링해 충돌 해결을 직관적으로 만든다”라고 설명했다.  그에 따르면 피줄 1.0 릴리즈 이전에 여러 번의 테스트, 디버깅 및 성능 조정이 진행될 예정이다. 알파 릴리즈 이후의 주요 변경 사항은 다음과 같다.  • 더 빠르고 더 모듈화되도록 Sanakirja 백엔드를 재설계했다.  • 패치는 이제 단일 리포지토리 및 바이너리 파일 내에서 서로 다른 인코딩으로 인코딩된 파일을 포함해 더 일반적인 유형의 파...

오픈소스 분산 버전 관리 시스템 피줄 패치 이론

2022.01.25

‘패치 이론(theory of patches)’을 기반으로 하는 이 오픈소스 분산 버전 관리 시스템은 깃(Git)보다 빠르고, 확장 가능하며, 배우고 사용하기 쉽다.  워크플로우를 간소화하는 패치 이론을 기반으로 한 오픈소스 분산 버전 제어 시스템 ‘피줄(Pijul)’이 베타 릴리즈로 이동했다. 해당 프로젝트 공식 문서에 따르면 피줄은 수학적 변경 이론을 바탕으로 하는 최초의 분산 버전 제어 시스템이며, 깃(Git)보다 더 간단하게 작업할 수 있고 대규모 리포지토리와 빠른 속도의 워크플로우로 확장할 수 있다.   피줄 개발팀은 지난 1월 18일(현지 시각) 알파 릴리즈를 내놓은 지 거의 1년 만에 이번 베타 버전을 선보였다. 다운로드 지침은 이곳(pijul.org)에서 확인할 수 있다.  깃과 마찬가지로 피줄은 파일의 변경 사항을 추적하고 되돌릴 수 있으며, 파일을 공동 작성자의 변경 사항과 병합할 수 있다. 하지만 공식 문서에 의하면 피줄은 변경 사항 또는 패치를 다루는 반면 깃은 스냅샷 또는 버전을 처리한다는 점에서 깃 및 기타 버전 제어 시스템과는 다르다.  해당 프로젝트의 리더 피에르 에티엔 뫼니에는 “피줄의 경우 결과를 변경하지 않고 독립적인 변경 사항을 어떤 순서로든 적용할 수 있다”라고 밝혔다. 이어서 그는 “한 브랜치에서 여러 기능을 개발할 수 있으며, 개발자는 비즈니스 방법론 및 제약 조건에 따라 일부 기능만 프로덕션으로 푸시할 수 있다. 또 피줄 데이터 구조는 충돌을 모델링해 충돌 해결을 직관적으로 만든다”라고 설명했다.  그에 따르면 피줄 1.0 릴리즈 이전에 여러 번의 테스트, 디버깅 및 성능 조정이 진행될 예정이다. 알파 릴리즈 이후의 주요 변경 사항은 다음과 같다.  • 더 빠르고 더 모듈화되도록 Sanakirja 백엔드를 재설계했다.  • 패치는 이제 단일 리포지토리 및 바이너리 파일 내에서 서로 다른 인코딩으로 인코딩된 파일을 포함해 더 일반적인 유형의 파...

2022.01.25

퍼블릭 코드 저장소의 기밀을 안전하게!··· 추천 툴 4종

깃랩, 깃허브, 구글 클라우드 빌드와 같은 저장소에 존재하는 기밀은 기업에게 재앙이 될 수 있다. 이와 관련해 검토해볼 만한 4가지 도구를 정리했다.  깃(Git) 저장소에 저장된 ‘기밀’은 공격자에게 유용한 공격 대상이다. 소프트웨어가 침해될 확률을 낮추기 위해서는 저장소(리포지토리)의 정보를 안전하게 저장하는 것과 폐기하는 것을 감안해야 한다. 애석하게도 개발 도구 자체에 하드코딩 된 방식으로 연결 문자열, 암호, 심지어 일반 텍스트 형식의 크리덴셜이 저장되어 있음이 자주 간과되곤 한다. 예를 들어, 비주얼 스튜디오(Visual Studio)는 다르게 설정하지 않으면 플레인 텍스트 형식으로 SQL 연결 크리덴셜을 저장한다. 깃가디언(GitGuardin)에 따르면, 2020년 한 해에만 퍼블릭 리포지토리에 보관된 ‘기밀’이 200만 개가 넘었다. 인턴이 생성한 크리덴셜이 유출되어 솔라윈드(SolarWinds) 공격에 큰 역할을 한 것으로 알려진 바 있다. 이런 사건을 감안할 때 자신의 프로젝트가 노출될 수 있는지 신중하게 검토할 가치가 있다. 먼저 할 일은 기밀을 찾는 것이다. 기밀은 코드나 모호한 XML 파일에 숨겨져 있고, 찾기 어려운 방식으로 되어있는 경우가 많다. 수동으로 코드를 스크러빙(scrubbing) 하면 실수하기 쉽다.  유감스럽게도 깃은 다른 소스 관리 시스템처럼 이전의 커밋을 유지하기 때문에 노출된 기밀을 정리하는 작업은 단순히 코드에서 기밀을 삭제해 리커밋을 하는 수준을 넘어선다. 히스토리에서 제거해야 한다. 다시 시작해야 하는 경우도 있다. 이런 이유로 처음부터 올바르게 하는 것이 중요하다. 다행히 이런 문제를 다루는 데 도움을 주는 몇몇 도구들이 있다. 대부분은 명령줄 도구이지만, 웹 기반 도구들도 존재한다. 대개 이런 도구들은 사용자 이름, 비밀번호, 프라이빗 키, 기타 민감할 수 있는 정보들을 찾는다. 기능은 비슷하지만, 동작 방식은 제각각이다.  적합한 도구를 선택하려 한다면, 자신의 기술 ...

퍼블릭 코드 저장소 기밀 관리 기밀 데이터 깃가디언 스펙트럴옵스 기티리크스 깃리크스

2021.11.12

깃랩, 깃허브, 구글 클라우드 빌드와 같은 저장소에 존재하는 기밀은 기업에게 재앙이 될 수 있다. 이와 관련해 검토해볼 만한 4가지 도구를 정리했다.  깃(Git) 저장소에 저장된 ‘기밀’은 공격자에게 유용한 공격 대상이다. 소프트웨어가 침해될 확률을 낮추기 위해서는 저장소(리포지토리)의 정보를 안전하게 저장하는 것과 폐기하는 것을 감안해야 한다. 애석하게도 개발 도구 자체에 하드코딩 된 방식으로 연결 문자열, 암호, 심지어 일반 텍스트 형식의 크리덴셜이 저장되어 있음이 자주 간과되곤 한다. 예를 들어, 비주얼 스튜디오(Visual Studio)는 다르게 설정하지 않으면 플레인 텍스트 형식으로 SQL 연결 크리덴셜을 저장한다. 깃가디언(GitGuardin)에 따르면, 2020년 한 해에만 퍼블릭 리포지토리에 보관된 ‘기밀’이 200만 개가 넘었다. 인턴이 생성한 크리덴셜이 유출되어 솔라윈드(SolarWinds) 공격에 큰 역할을 한 것으로 알려진 바 있다. 이런 사건을 감안할 때 자신의 프로젝트가 노출될 수 있는지 신중하게 검토할 가치가 있다. 먼저 할 일은 기밀을 찾는 것이다. 기밀은 코드나 모호한 XML 파일에 숨겨져 있고, 찾기 어려운 방식으로 되어있는 경우가 많다. 수동으로 코드를 스크러빙(scrubbing) 하면 실수하기 쉽다.  유감스럽게도 깃은 다른 소스 관리 시스템처럼 이전의 커밋을 유지하기 때문에 노출된 기밀을 정리하는 작업은 단순히 코드에서 기밀을 삭제해 리커밋을 하는 수준을 넘어선다. 히스토리에서 제거해야 한다. 다시 시작해야 하는 경우도 있다. 이런 이유로 처음부터 올바르게 하는 것이 중요하다. 다행히 이런 문제를 다루는 데 도움을 주는 몇몇 도구들이 있다. 대부분은 명령줄 도구이지만, 웹 기반 도구들도 존재한다. 대개 이런 도구들은 사용자 이름, 비밀번호, 프라이빗 키, 기타 민감할 수 있는 정보들을 찾는다. 기능은 비슷하지만, 동작 방식은 제각각이다.  적합한 도구를 선택하려 한다면, 자신의 기술 ...

2021.11.12

깃허브, ‘코드 리뷰 제한’ 기능 추가

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

깃허브 코드 공유 코드 리뷰 풀 리퀘스트 버전 관리 리포지토리 개발자 오픈소스 메인테이너

2021.11.04

깃허브의 새로운 관리 기능은 ‘드라이브-바이(drive-by)’ 풀 리퀘스트 승인 및 ‘스팸성(spammy)’ 변경 요청을 처리하도록 설계됐다.  지난 11월 1일(현지 시각) 깃허브가 깃(Git) 기반 버전 관리 시스템 및 코드 공유 사이트 사용자를 위해 코드 리뷰 제한을 추가하고 모바일 알림을 개선했다.  회사에 따르면 코드 리뷰 제한의 목적은 ‘드라이브-바이’ 풀 리퀘스트 승인과 스팸성 변경 요청 문제를 해결하는 것이다. 메인테이너는 이제 풀 리퀘스트에 대해 변경을 승인하고 요청할 수 있는 사용자를 제한할 수 있다.  즉, 리포지토리 수준에서 읽기 이상의 액세스 권한을 명시적으로 부여받은 사용자로 승인 및 변경 요청을 제한할 수 있다. 사용자 또는 조직 계정과 연결된 모든 리포지토리에서 코드 리뷰 제한을 활성화할 수도 있다.  리포지토리 코드 리뷰 제한을 활성화하려면 해당 리포지토리의 설정 페이지로 이동하여 왼쪽 메뉴에서 조정 설정(Moderation Settings)을 선택한다. 그다음 ‘코드 리뷰 제한(Code review limits)’을 누른 후 ‘읽기 이상의 권한이 명시적으로 부여된 사용자로 제한(Limit to users explicitly granted read or higher access)’ 상자를 체크한다.    또한 깃허브 모바일 앱에서 스팸성 이슈와 풀 리퀘스트를 처리하기 어렵다는 문제를 해결하기 위해 모바일 알림이 개선됐다. 이제 모바일 알림에 스팸 이슈 또는 풀 리퀘스트 팝업이 표시되면 쉽게 해당 이슈를 닫고, 개발자의 스마트폰에서 바로 조직의 사용자를 블록할 수 있다.    이 2가지 기능은 깃허브가 올해부터 제공하기 시작한, 오픈소스 커뮤니티의 ‘삶의 질 향상’에 초점을 맞춘 기능 중 하나다. 이를 지원하는 다른 기능은 아래와 같다.  • 문제 양식(Issue forms): 필수 필드를 포함한 양식 필드로 문제 템플릿을 생성해 문제...

2021.11.04

MS, C++ 20 모든 기능 지원하는 비주얼 스튜디오 2019 버전 16.10 출시

마이크로소프트가 자사의 플래그십 IDE인 비주얼 스튜디오 2019의 버전 16.10 릴리즈를 25일(현지시간) 출시했다. C++ 20의 모든 기능을 이용할 수 있는 게 특징이다. 한편, 같은 날 공개된 버전 16.11의 프리뷰 릴리즈는 핫 리로드(Hot Reload)와 .NET MAUI를 지원하는 데 초점을 맞춘다.   비주얼 스튜디오 2019 버전 16.10은 캘린더 및 타임존 설정 그리고 <format> 텍스트 포맷 기능 등 C++ 20의 기능을 구현할 수 있다. 마이크로소프트에 따르면 16.10의 컴파일러와 표준 라이브러리는 현재 기능 완료(feature-complete) 단계에 있다.    C++ 11이나 C++ 14 환경에 있는 개발자는 /await:strict 스위치를 활성화해 C++ 20-스타일 코루틴을 사용할 수 있다. 그리고 CMake 빌드 도구를 사용하는 이들은 CMakeSettings.json 대신 CMakePresets를 사용해 구성을 특정할 수 있다. 그 외 비주얼 스튜디오 2019 버전 16.10의 기능들은 다음과 같다.    깃 메뉴의 상태 표시줄에 새 브랜치 피커가 추가됐다. 이를 통해 로컬 및 원격 브랜치를 필터링하고, 마우스 우클릭 시 나오는 컨텍스트 메뉴에서 페치, 풀, 푸쉬 등 일반적인 행동을 수행할 수 있다. 또한, 깃 > 설정을 보면 리포지토리 열기 및 전환을 관리할 수 있는 옵션이 일부 추가됐다.    도커 컨테이너 기반 서비스를 빌드하고 관리하는 기능이 개선됐다. 개발자는 컴포즈 파일에 정의된 서비스들을 조합해 실행해볼 수 있다. 또한 컨테이너 창에서 보이는 컨테이너 및 이미지 관리 기능도 업그레이드됐다.   ‘사용되지 않는 레퍼런스 제거하기’ 명령이 추가됐다. 사용되지 않는 프로젝...

마이크로소프트 IDE 비주얼 스튜디오 2019 C++ 핫 리로드 .NET

2021.05.28

마이크로소프트가 자사의 플래그십 IDE인 비주얼 스튜디오 2019의 버전 16.10 릴리즈를 25일(현지시간) 출시했다. C++ 20의 모든 기능을 이용할 수 있는 게 특징이다. 한편, 같은 날 공개된 버전 16.11의 프리뷰 릴리즈는 핫 리로드(Hot Reload)와 .NET MAUI를 지원하는 데 초점을 맞춘다.   비주얼 스튜디오 2019 버전 16.10은 캘린더 및 타임존 설정 그리고 <format> 텍스트 포맷 기능 등 C++ 20의 기능을 구현할 수 있다. 마이크로소프트에 따르면 16.10의 컴파일러와 표준 라이브러리는 현재 기능 완료(feature-complete) 단계에 있다.    C++ 11이나 C++ 14 환경에 있는 개발자는 /await:strict 스위치를 활성화해 C++ 20-스타일 코루틴을 사용할 수 있다. 그리고 CMake 빌드 도구를 사용하는 이들은 CMakeSettings.json 대신 CMakePresets를 사용해 구성을 특정할 수 있다. 그 외 비주얼 스튜디오 2019 버전 16.10의 기능들은 다음과 같다.    깃 메뉴의 상태 표시줄에 새 브랜치 피커가 추가됐다. 이를 통해 로컬 및 원격 브랜치를 필터링하고, 마우스 우클릭 시 나오는 컨텍스트 메뉴에서 페치, 풀, 푸쉬 등 일반적인 행동을 수행할 수 있다. 또한, 깃 > 설정을 보면 리포지토리 열기 및 전환을 관리할 수 있는 옵션이 일부 추가됐다.    도커 컨테이너 기반 서비스를 빌드하고 관리하는 기능이 개선됐다. 개발자는 컴포즈 파일에 정의된 서비스들을 조합해 실행해볼 수 있다. 또한 컨테이너 창에서 보이는 컨테이너 및 이미지 관리 기능도 업그레이드됐다.   ‘사용되지 않는 레퍼런스 제거하기’ 명령이 추가됐다. 사용되지 않는 프로젝...

2021.05.28

비주얼 스튜디오 코드 1.53, 사용자 지정 가능한 검색 모드 지원

마이크로소프트의 오픈소스 코드 편집기 ‘비주얼 스튜디오 코드(Visual Studio Code)’ 최신 버전이 지난 2월 4일 공개됐다. 사용자 지정 가능한 검색 모드를 지원하고 자바스크립트 디버깅을 개선하는 등 새로운 기능 및 개선 사항을 제공한다.    2월에 발표되긴 했지만 2021년 1월 릴리스라고 칭하는 ‘비주얼 스튜디오 버전 1.53’은 이곳(visualstudio.com)에서 다운로드 받을 수 있다. 이번 릴리스에서는 search.mode 설정이 도입됐다.  이를 사용하면 ‘검색: 파일에서 찾기(Search: Find in Files)’, 탐색기의 ‘폴더에서 찾기(Find in Folder)’, ‘작업 공간에서 찾기(Find in Workspace)’ 컨텍스트 메뉴 항목과 같은 UI 검색 명령에 관한 옵션을 구성할 수 있다. 옵션은 다음과 같다.  • view: 사이드바 또는 패널의 검색 보기를 사용하여 검색한다.  • newEditor: 새 검색 편집기(Search Editor)에서 검색한다.  • existingEditor: 기존에 열려 있는 검색 편집기가 있는 경우 다시 사용하고, 그렇지 않으면 새 편집기를 만든다.  이전에는 키 바인딩을 편집해 기본 검색 UI를 구성하도록 권장했다. 이는 더 이상 필요하지 않으며, 이러한 키 바인딩은 해당 설정에 맞게 제거할 수 있다. 이 밖에 비주얼 스튜디오 코드 1.53의 새로운 기능 및 개선 사항은 아래와 같다.  • 자바스크립트 디버거에서 조건부 예외 중단점이 활성화된다. Node.js worker_threads 또한 지원된다.  • workbench.editor.wrapTabs 설정을 사용하면 스크롤 막대를 표시하지 않고 편집기 탭을 줄 바꿈 할 수 있다.  • 새로운 두 가지 설정을 사용해 편집기 탭에 깃(git) 상태 또는 진단과 같은 데코레이션을 표시할지 여부를 구성할 수 있다. workbenc...

마이크로소프트 코드 편집기 오픈소스 비주얼 스튜디오 코드 검색 모드 자바스크립트 디버깅 에밋

2021.02.08

마이크로소프트의 오픈소스 코드 편집기 ‘비주얼 스튜디오 코드(Visual Studio Code)’ 최신 버전이 지난 2월 4일 공개됐다. 사용자 지정 가능한 검색 모드를 지원하고 자바스크립트 디버깅을 개선하는 등 새로운 기능 및 개선 사항을 제공한다.    2월에 발표되긴 했지만 2021년 1월 릴리스라고 칭하는 ‘비주얼 스튜디오 버전 1.53’은 이곳(visualstudio.com)에서 다운로드 받을 수 있다. 이번 릴리스에서는 search.mode 설정이 도입됐다.  이를 사용하면 ‘검색: 파일에서 찾기(Search: Find in Files)’, 탐색기의 ‘폴더에서 찾기(Find in Folder)’, ‘작업 공간에서 찾기(Find in Workspace)’ 컨텍스트 메뉴 항목과 같은 UI 검색 명령에 관한 옵션을 구성할 수 있다. 옵션은 다음과 같다.  • view: 사이드바 또는 패널의 검색 보기를 사용하여 검색한다.  • newEditor: 새 검색 편집기(Search Editor)에서 검색한다.  • existingEditor: 기존에 열려 있는 검색 편집기가 있는 경우 다시 사용하고, 그렇지 않으면 새 편집기를 만든다.  이전에는 키 바인딩을 편집해 기본 검색 UI를 구성하도록 권장했다. 이는 더 이상 필요하지 않으며, 이러한 키 바인딩은 해당 설정에 맞게 제거할 수 있다. 이 밖에 비주얼 스튜디오 코드 1.53의 새로운 기능 및 개선 사항은 아래와 같다.  • 자바스크립트 디버거에서 조건부 예외 중단점이 활성화된다. Node.js worker_threads 또한 지원된다.  • workbench.editor.wrapTabs 설정을 사용하면 스크롤 막대를 표시하지 않고 편집기 탭을 줄 바꿈 할 수 있다.  • 새로운 두 가지 설정을 사용해 편집기 탭에 깃(git) 상태 또는 진단과 같은 데코레이션을 표시할지 여부를 구성할 수 있다. workbenc...

2021.02.08

VS 코드 버전 1.52, '확장' 문제 빠르게 해결하는 기능 추가

‘비주얼 스튜디오 코드(Visual Studio Code)’의 최신 월간 업데이트에 문제를 일으키는 확장 프로그램을 빠르게 식별하기 위해 이진 탐색 알고리즘을 사용하는 확장 이분(Extension Bisect) 기능이 추가됐다.  2020년 11월 릴리즈된 ‘비주얼 스튜디오 코드 버전 1.52’에 확장 프로그램을 이등분하는 기능이 추가됐다. 편집기에서 문제를 발생시키는 확장 프로그램을 신속하게 해결할 수 있도록 하기 위해서다. 이전에는 모든 확장 프로그램을 비활성화한 다음, 하나씩 다시 활성화해 문제를 찾아야 했기 때문이다.    확장 이분 기능은 이진 탐색 알고리즘을 사용하여 문제를 일으키는 확장 프로그램을 빠르게 식별한다. 구체적으로 설명하자면, 이 기능은 확장 프로그램의 절반을 비활성화하고 개발자에게 나머지 부분에서 문제가 있는지 확인하도록 한다. 여기서 문제가 없다면 잘못된 확장 프로그램은 비활성화된 확장 프로그램 목록에 있어야 한다. 잘못된 확장 프로그램이 남을 때까지 프로세스가 반복된다.  비주얼 스튜디오 코드 개발팀은 월간 업데이트 게시판을 통해 테마부터 언어 지원, 디버깅, 코드 탐색까지 다양한 기능을 제공하는 확장 프로그램은 비주얼 스튜디오 코드의 ‘진정한 저력’이라고 설명했다.  비주얼 스튜디오 코드는 이곳(code.visualstudio.com)에서 다운로드받을 수 있다. 비주얼 스튜디오 코드 1.52의 다른 기능은 다음과 같다.  • 여러 깃(Git) 명령이 커맨드 팔레트에 추가됐다. 여기에는 브랜치에 관한 특정 커밋을 선택하는 체리 픽(Cherry Pick), 활성 파일 이름 변경(Rename), 로컬 태그를 원격으로 푸시하는 태그 푸시(Push Tags), 분리 모드에서 체크아웃을 수행하는 체크아웃(Checkout)이 포함됐다.  • 원격 참조를 패칭할 때 ‘git fetch --prune'를 실행하도록 하는 git.pruneOnFetch 등 여러 깃 설정이 추...

마이크로소프트 코드 편집기 비주얼 스튜디오 코드 확장 프로그램 이진 탐색 알고리즘

2020.12.16

‘비주얼 스튜디오 코드(Visual Studio Code)’의 최신 월간 업데이트에 문제를 일으키는 확장 프로그램을 빠르게 식별하기 위해 이진 탐색 알고리즘을 사용하는 확장 이분(Extension Bisect) 기능이 추가됐다.  2020년 11월 릴리즈된 ‘비주얼 스튜디오 코드 버전 1.52’에 확장 프로그램을 이등분하는 기능이 추가됐다. 편집기에서 문제를 발생시키는 확장 프로그램을 신속하게 해결할 수 있도록 하기 위해서다. 이전에는 모든 확장 프로그램을 비활성화한 다음, 하나씩 다시 활성화해 문제를 찾아야 했기 때문이다.    확장 이분 기능은 이진 탐색 알고리즘을 사용하여 문제를 일으키는 확장 프로그램을 빠르게 식별한다. 구체적으로 설명하자면, 이 기능은 확장 프로그램의 절반을 비활성화하고 개발자에게 나머지 부분에서 문제가 있는지 확인하도록 한다. 여기서 문제가 없다면 잘못된 확장 프로그램은 비활성화된 확장 프로그램 목록에 있어야 한다. 잘못된 확장 프로그램이 남을 때까지 프로세스가 반복된다.  비주얼 스튜디오 코드 개발팀은 월간 업데이트 게시판을 통해 테마부터 언어 지원, 디버깅, 코드 탐색까지 다양한 기능을 제공하는 확장 프로그램은 비주얼 스튜디오 코드의 ‘진정한 저력’이라고 설명했다.  비주얼 스튜디오 코드는 이곳(code.visualstudio.com)에서 다운로드받을 수 있다. 비주얼 스튜디오 코드 1.52의 다른 기능은 다음과 같다.  • 여러 깃(Git) 명령이 커맨드 팔레트에 추가됐다. 여기에는 브랜치에 관한 특정 커밋을 선택하는 체리 픽(Cherry Pick), 활성 파일 이름 변경(Rename), 로컬 태그를 원격으로 푸시하는 태그 푸시(Push Tags), 분리 모드에서 체크아웃을 수행하는 체크아웃(Checkout)이 포함됐다.  • 원격 참조를 패칭할 때 ‘git fetch --prune'를 실행하도록 하는 git.pruneOnFetch 등 여러 깃 설정이 추...

2020.12.16

칼럼ㅣ‘리눅스’는 여전히 ‘표준’이다

'리눅스(Linux)'는 오픈소스의 성공 기반을 닦았을 뿐만 아니라 오픈소스 커뮤니티의 운영 방식을 구체화했다. 우리는 리눅스에 대해 충분히 이야기하고 있는가? 오픈소스 세상에서 자라난 사람뿐만 아니라 오픈소스를 처음 접한 사람 모두 리눅스 커뮤니티의 선구적인 역할에 감사해야 한다. 어쨌든 리눅스는 오픈소스가 무엇을 의미하는지, 그리고 이것이 개인, 기업, 정부에 무엇을 의미할 수 있는지를 보여주는 대표적인 첫 모델이었다.    리눅스 창시자 리누스 토발즈를 포함한 ‘리눅스 커뮤니티’는 오늘날 오픈소스가 작동하는 방식 또한 정의했다. 깃(Git)부터 조직 구조(메인테이너, 커미터 등)에 이르기까지 리눅스는 오픈소스 커뮤니티 운영 방식에 직접적으로 또는 간접적으로 영향을 미쳤다.  여기서는 리눅스 재단의 ‘2020년 리눅스 커널 역사 보고서(2020 Linux Kernel History Report)’에 따라 리눅스가 어떻게 오픈소스의 기반을 닦아 놓았는지를 살펴본다.  대규모 협력 리눅스는 모든 것이 크다(임베디드 리눅스 배포판을 실행하는 수많은 IoT 장치는 예외다). 올해로 리눅스는 탄생 29주년을 맞았다. 현재까지 2만 명이 넘는 기여자(contributors)가 참여했고, 100만 개의 커밋(2020년 8월 기준)이 추가됐다. 지난 몇 년으로 따지자면 평균 7만 5,000개의 커밋이 추가됐다. 놀라운 기록이다.  물론 처음부터 이렇진 않았다.  리눅스는 토발즈의 단독 프로젝트로 시작됐다. 그리고 1996년경 앨런 콕스와 존 네일러가 합류했다. 이들은 서로를 ‘메인테이너’라고 불렀다. 같은 기간 동안 아파치 웹 서버와 같은 다른 프로젝트도 조직적인 형태를 갖췄지만, 필자가 아는 한 메인테이너 계층을 중심으로 이렇게 빠르게(그리고 공식적으로) 조직화된 사례는 없었다.  이러한 계층은 중요했다. 최초의 MAINTERS 파일(커널 v1.3.68용)에서 밝힌 바와 같이 프로젝트 커뮤니케...

리눅스 리누스 토발즈 리눅스 커뮤니티 메인테이너 커미터 컨트리뷰터 기트허브 기트랩 오픈소스 레드햇

2020.09.11

'리눅스(Linux)'는 오픈소스의 성공 기반을 닦았을 뿐만 아니라 오픈소스 커뮤니티의 운영 방식을 구체화했다. 우리는 리눅스에 대해 충분히 이야기하고 있는가? 오픈소스 세상에서 자라난 사람뿐만 아니라 오픈소스를 처음 접한 사람 모두 리눅스 커뮤니티의 선구적인 역할에 감사해야 한다. 어쨌든 리눅스는 오픈소스가 무엇을 의미하는지, 그리고 이것이 개인, 기업, 정부에 무엇을 의미할 수 있는지를 보여주는 대표적인 첫 모델이었다.    리눅스 창시자 리누스 토발즈를 포함한 ‘리눅스 커뮤니티’는 오늘날 오픈소스가 작동하는 방식 또한 정의했다. 깃(Git)부터 조직 구조(메인테이너, 커미터 등)에 이르기까지 리눅스는 오픈소스 커뮤니티 운영 방식에 직접적으로 또는 간접적으로 영향을 미쳤다.  여기서는 리눅스 재단의 ‘2020년 리눅스 커널 역사 보고서(2020 Linux Kernel History Report)’에 따라 리눅스가 어떻게 오픈소스의 기반을 닦아 놓았는지를 살펴본다.  대규모 협력 리눅스는 모든 것이 크다(임베디드 리눅스 배포판을 실행하는 수많은 IoT 장치는 예외다). 올해로 리눅스는 탄생 29주년을 맞았다. 현재까지 2만 명이 넘는 기여자(contributors)가 참여했고, 100만 개의 커밋(2020년 8월 기준)이 추가됐다. 지난 몇 년으로 따지자면 평균 7만 5,000개의 커밋이 추가됐다. 놀라운 기록이다.  물론 처음부터 이렇진 않았다.  리눅스는 토발즈의 단독 프로젝트로 시작됐다. 그리고 1996년경 앨런 콕스와 존 네일러가 합류했다. 이들은 서로를 ‘메인테이너’라고 불렀다. 같은 기간 동안 아파치 웹 서버와 같은 다른 프로젝트도 조직적인 형태를 갖췄지만, 필자가 아는 한 메인테이너 계층을 중심으로 이렇게 빠르게(그리고 공식적으로) 조직화된 사례는 없었다.  이러한 계층은 중요했다. 최초의 MAINTERS 파일(커널 v1.3.68용)에서 밝힌 바와 같이 프로젝트 커뮤니케...

2020.09.11

'뜻밖의 선물'같은 팁··· '깃(Git)' 고급 명령어 5가지

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

개발자 커밋 디버깅 리포지토리 브랜치 머지 풀 리퀘스트 깃 리베이스 스쿼시 버그 코드 체리픽 서브모듈

2020.06.12

더 깔끔한 커밋, 더 스마트한 디버깅, 더 세련된 리포지토리를 위해 한 단계 업그레이드된 깃 기술들을 마스터하라.  오늘날 개발자 대부분은 소프트웨어 워크플로우의 핵심인 버전 관리 시스템 깃(Git)을 배웠을 가능성이 크다. 그리고 기본 개념과 명령어도 당연히 알고 있을 것이다. 이를테면 리포지토리(repositories) 작동 방식, 브랜치(branch)를 만들고 변경사항을 커밋(commit)하는 방법, 변경사항을 머지(merge)하고 풀 리퀘스트(pull request)하는 방법 등이다. 기본을 잘 알고 있다면 이제 수준을 조금 높여야 할 때다. 워크플로우에서 깃의 더욱 강력한 기능들을 활용할 수 있도록 말이다.    1. git rebase로 커밋 히스토리 단순화하기 한 프로젝트에 2개의 브랜치(예: 개발 브랜치와 마스터 브랜치)가 있고, 두 브랜치를 결합해야 하는 변경사항이 있다고 가정해보자. 이때 git merge 명령어는 이들을 통합하는 간단한 방법이다.  merge는 한 브랜치의 개발 히스토리를 다른 브랜치의 머지 커밋으로 추가한다. 이를 통해 두 히스토리를 온전히 보존할 순 있지만 전체 프로젝트 히스토리를 파악하기 어려울 수 있다. 더 단순하고 깔끔한 결과를 원한다면 git rebase가 도움이 된다.  git rebase 명령어도 2개의 브랜치를 머지하지만 약간 다르게 진행된다. git rebase는 한 브랜치가 생성된 지점부터 다른 브랜치가 통합될 수 있도록 커밋 히스토리를 다시 쓴다. 즉 덜 복잡하고 선형적인 커밋 히스토리를 만들 수 있는 것이다. 하지만 이 과정에서 다른 브랜치 및 머지 프로세스와 관련해 유용할 수도 있는 세부정보가 제거된다는 점을 유의해야 한다.  따라서 rebase는 공용(public) 브랜치와 머지하기 전에 하나의 깔끔한 커밋 히스토리로 통합하려는 여러 비공개(private) 브랜치가 있을 경우 특히 유용하다. 이를 통해 프로젝트의 커밋 히스토리와 관련...

2020.06.12

깃랩 13.0 나왔다··· 보안 중심의 신기능 추가 

깃랩이 5월 22일 소프트웨어 개발, 배포 및 프로젝트 관리 툴을 통합한 자사의 데브옵스 플랫폼을 버전 13.0으로 업데이트했다. 이번 버전은 여러 보안 및 협업 기능을 추가한 것이 특징이다.  회사에 따르면 깃랩(GitLab) 13.0에는 깃(Git) 오픈소스 분산 버전 관리 시스템, CI/CD, 설계 및 협업 도구가 결합됐다. 이 밖의 새로운 기능들은 아래와 같다.   • 보안 스캐닝: 보안 스캐닝을 위해 닷넷(.NET) 프레임워크용 SAST(Static Application Security Testing)를 제공한다. REST API에 대해서는 DAST (Dynamic Application Security Testing) 스캐닝을 지원한다. 또한 깃랩 13.0은 오프라인 환경 스캐닝을 위한 지원도 확대한다. • 취약성 분리: 취약성 및 관련 리스크의 우선순위를 정하고 관리할 수 있도록 취약성 관리 방법을 재설계했다. • 컴플라이언스 관리: 컴플라이언스 프레임워크 구축을 자동화하고, 규제 제어를 적용하며, 감사보고를 간소화할 수 있게 됐다. 이와 함께 보안 가드레일을 단순화하는 초기 보안정책 UI도 개발 중이라고 회사 측은 설명했다. • 설계 관리: 제품을 설계하는 사용자를 개별 기여자로 인식할 수 있도록 설계 관리를 핵심 부문으로 이전했다. • 대시보드: 운영 대시보드는 여러 변수를 사용하도록 허용해 사용자 정의가 용이해졌다. 보안 대시보드는 깃랩 외의 사용자들과도 협업할 수 있도록 내보내기가 가능하다. 쿠버네티스 클러스터(Kubernetes clusters) 지원은 향후 제공될 예정이다. • 깃앨리 클러스터(Gitaly Cluster): 깃 리포지토리(Git Repository) 스토리지에 장애가 발생하는 경우 이를 즉시 복구하는 웜 레플리카(Warm Replica)를 제공할 수 있도록 깃앨리 클러스터가 지원된다. • 가치 흐름 관리(Value Stream Management): 병목현상 및 낭비 요소를 빠르게 식별할 ...

깃랩 데브옵스 소프트웨어 개발 배포 프로젝트 관리 분산 버전 관리 시스템 CI CD 보안 스캐닝 닷넷 프레임워크 REST API SATS DAST 취약성 관리 컴플라이언스 대시보드 깃앨리 클러스터 쿠버네티스

2020.06.05

깃랩이 5월 22일 소프트웨어 개발, 배포 및 프로젝트 관리 툴을 통합한 자사의 데브옵스 플랫폼을 버전 13.0으로 업데이트했다. 이번 버전은 여러 보안 및 협업 기능을 추가한 것이 특징이다.  회사에 따르면 깃랩(GitLab) 13.0에는 깃(Git) 오픈소스 분산 버전 관리 시스템, CI/CD, 설계 및 협업 도구가 결합됐다. 이 밖의 새로운 기능들은 아래와 같다.   • 보안 스캐닝: 보안 스캐닝을 위해 닷넷(.NET) 프레임워크용 SAST(Static Application Security Testing)를 제공한다. REST API에 대해서는 DAST (Dynamic Application Security Testing) 스캐닝을 지원한다. 또한 깃랩 13.0은 오프라인 환경 스캐닝을 위한 지원도 확대한다. • 취약성 분리: 취약성 및 관련 리스크의 우선순위를 정하고 관리할 수 있도록 취약성 관리 방법을 재설계했다. • 컴플라이언스 관리: 컴플라이언스 프레임워크 구축을 자동화하고, 규제 제어를 적용하며, 감사보고를 간소화할 수 있게 됐다. 이와 함께 보안 가드레일을 단순화하는 초기 보안정책 UI도 개발 중이라고 회사 측은 설명했다. • 설계 관리: 제품을 설계하는 사용자를 개별 기여자로 인식할 수 있도록 설계 관리를 핵심 부문으로 이전했다. • 대시보드: 운영 대시보드는 여러 변수를 사용하도록 허용해 사용자 정의가 용이해졌다. 보안 대시보드는 깃랩 외의 사용자들과도 협업할 수 있도록 내보내기가 가능하다. 쿠버네티스 클러스터(Kubernetes clusters) 지원은 향후 제공될 예정이다. • 깃앨리 클러스터(Gitaly Cluster): 깃 리포지토리(Git Repository) 스토리지에 장애가 발생하는 경우 이를 즉시 복구하는 웜 레플리카(Warm Replica)를 제공할 수 있도록 깃앨리 클러스터가 지원된다. • 가치 흐름 관리(Value Stream Management): 병목현상 및 낭비 요소를 빠르게 식별할 ...

2020.06.05

칼럼ㅣ깃옵스란?··· '깃'의 장점을 운영으로 가져오다

깃옵스는 개발자와 운영팀 모두에게 매우 좋은 효과를 발휘할 수 있고, 데브옵스가 오랫동안 지향해온 궁극의 특징을 지니고 있다.  아마 한 번쯤은 깃옵스(GitOps)에 대해 들어봤겠지만, 여전히 모르고 있을 수 있다. 만약 깃옵스가 반드시 깃을 포함하는 것은 아니며, 일반적으로 연결되는 쿠버네티스가 요구되는 것은 아니라고 말한다면 더 애매모호할 수 있다. 해당 용어를 창안한 위브웍스에 따르면 깃옵스는 ‘개발자 중심의 애플리케이션 관리 환경을 가능하게 하는 방법론’이다.  그래도 혼란스러운가? 단도직입적으로 말하자면 깃옵스는 개발자가 산출물을 더 많이 제어할 수 있도록 하는 방법이다. 한층 더 업그레이드된 데브옵스(DevOps)인 셈이다. 결론은 간단하다. 깃옵스는 개발자가 애플리케이션 운영에서 훨씬 더 큰 역할을 담당할 수 있도록 지원하는 동시에 운영팀의 프로세스도 크게 개선한다.   시작은 깃(Git)이었다 분산 버전 관리 시스템 깃을 발명한 인물은 리눅스의 아버지로 널리 알려진 리누스 토발즈다. 토발즈는 “내가 '히트곡 하나뿐인 가수'가 아니라는 것을 깃이 증명했다"라고 말했다. 그러나 이는 깃의 중요성을 표현하기에 굉장히 부족하다. 그만큼 깃은 중요하다. 깃 이전에도 버전 관리 시스템, 이를테면 서브 버전 등이 있었지만 깃은 2005년 공개된 이후 개발자가 소프트웨어를 구축하는 방식에 혁명을 일으켰다. 애널리스트 로렌스 헥트는 오늘날 깃이 '가장 보편적인' 소프트웨어 개발 요소라고 분석했다. 프로그래밍 커뮤니티 스택 오버플로우(Stack Overflow)의 설문조사에 따르면 2018년 깃을 사용한다고 밝힌 응답자가 78%에 달했다. 소프트웨어 개발사 젯브레인(JetBrains)도 2017년 79%에서 2019년 90%로 깃 사용자 수가 급증했다는 설문조사 데이터를 공개한 바 있다. 그도 그럴 것이 공공 및 개인 깃 저장소에 엄청나게 많은 코드가 있기 때문이다.  위브웍스 CEO 알렉시스 리처드슨은 "...

개발자 머큐리얼 깃옵스 쿠버네티스 데브옵스 클러스터 운영 개발 애플리케이션 서브버전

2020.03.26

깃옵스는 개발자와 운영팀 모두에게 매우 좋은 효과를 발휘할 수 있고, 데브옵스가 오랫동안 지향해온 궁극의 특징을 지니고 있다.  아마 한 번쯤은 깃옵스(GitOps)에 대해 들어봤겠지만, 여전히 모르고 있을 수 있다. 만약 깃옵스가 반드시 깃을 포함하는 것은 아니며, 일반적으로 연결되는 쿠버네티스가 요구되는 것은 아니라고 말한다면 더 애매모호할 수 있다. 해당 용어를 창안한 위브웍스에 따르면 깃옵스는 ‘개발자 중심의 애플리케이션 관리 환경을 가능하게 하는 방법론’이다.  그래도 혼란스러운가? 단도직입적으로 말하자면 깃옵스는 개발자가 산출물을 더 많이 제어할 수 있도록 하는 방법이다. 한층 더 업그레이드된 데브옵스(DevOps)인 셈이다. 결론은 간단하다. 깃옵스는 개발자가 애플리케이션 운영에서 훨씬 더 큰 역할을 담당할 수 있도록 지원하는 동시에 운영팀의 프로세스도 크게 개선한다.   시작은 깃(Git)이었다 분산 버전 관리 시스템 깃을 발명한 인물은 리눅스의 아버지로 널리 알려진 리누스 토발즈다. 토발즈는 “내가 '히트곡 하나뿐인 가수'가 아니라는 것을 깃이 증명했다"라고 말했다. 그러나 이는 깃의 중요성을 표현하기에 굉장히 부족하다. 그만큼 깃은 중요하다. 깃 이전에도 버전 관리 시스템, 이를테면 서브 버전 등이 있었지만 깃은 2005년 공개된 이후 개발자가 소프트웨어를 구축하는 방식에 혁명을 일으켰다. 애널리스트 로렌스 헥트는 오늘날 깃이 '가장 보편적인' 소프트웨어 개발 요소라고 분석했다. 프로그래밍 커뮤니티 스택 오버플로우(Stack Overflow)의 설문조사에 따르면 2018년 깃을 사용한다고 밝힌 응답자가 78%에 달했다. 소프트웨어 개발사 젯브레인(JetBrains)도 2017년 79%에서 2019년 90%로 깃 사용자 수가 급증했다는 설문조사 데이터를 공개한 바 있다. 그도 그럴 것이 공공 및 개인 깃 저장소에 엄청나게 많은 코드가 있기 때문이다.  위브웍스 CEO 알렉시스 리처드슨은 "...

2020.03.26

깃 사용자가 흔히 저지르는 6가지 실수와 대처 방법

개발자들이 깃(Git)과 같은 소스 제어 시스템을 사용하는 중요한 이유 중 하나는 각종 재난을 최대한 방지하기 위해서다. 단순하게는 실수로 파일 하나를 삭제하는 경우부터 여러 파일을 잘못 변경하는 실수까지 여러 가지 사고가 일어날 수 있지만, 깃이 있으면 간단히 되돌릴 수 있다.   이중에는 경험 많은 깃 사용자라 해도 되돌리기가 어려운 실수도 있다. 설령 프로그래머들이 듣더라고 깜짝 놀랄 최악의 실수를 저질렀다 해도 패닉에 빠지지 않고 신중하게 대처하면 롤백이 가능하다.   깃에서 저지를 수 있는 큰 실수와 함께 이를 되돌리고 애초에 방지하기 위한 팁을 소개한다. 목록 마지막으로 갈수록 더 심각한 사고다.   깃 실수 1: 마지막 커밋에 깜박하고 변경을 추가하지 않았을 때 깃 실수 중에서 복구하기가 가장 쉬운 실수에 속한다. 예를 들어 로컬 분기에 작업을 커밋한 이후에 필요한 일부 파일을 스테이징하지 않았다는 사실을 알게 되거나, 커밋 메시지에 세부 정보를 추가하지 않았다는 것을 뒤늦게 깨닫는 경우다. 걱정할 필요 없다. 먼저 스테이징할 새로운 변경 사항이 있다면 스테이징을 한다. 그 다음 git commit --amend를 입력해서 커밋 메시지를 편집한다. Esc를 누른 다음 :xq를 입력해서 저장하고 편집기에서 나온다. (기본 깃 편집기의 특징을 잘 모르는 깃 초보자는 이 마지막 단계에서 당황하는 경우가 많다.) 파일만 변경하고 커밋 메시지를 수정할 필요는 없다면 git commit --amend --no-edit를 사용해서 파일을 추가하고 메시지 편집 과정을 생략할 수 있다.   이와 같은 종류의 실수를 피하려면 깃에서 커밋하는 방법을 바꿔야 한다. 증분적 리비전을 추적하기 위해 수시로 작게 커밋하는 작업은 임시 분기에서 한다. 그리고 이 과정에서 중요한 변경은 git commit 명령을 하는 시점까지 기다리지 말고 다른 곳에 문서로 작성한다. 그런 다음 중요한 이정표에 도달하면 임시 분기에서 git me...

2020.01.23

개발자들이 깃(Git)과 같은 소스 제어 시스템을 사용하는 중요한 이유 중 하나는 각종 재난을 최대한 방지하기 위해서다. 단순하게는 실수로 파일 하나를 삭제하는 경우부터 여러 파일을 잘못 변경하는 실수까지 여러 가지 사고가 일어날 수 있지만, 깃이 있으면 간단히 되돌릴 수 있다.   이중에는 경험 많은 깃 사용자라 해도 되돌리기가 어려운 실수도 있다. 설령 프로그래머들이 듣더라고 깜짝 놀랄 최악의 실수를 저질렀다 해도 패닉에 빠지지 않고 신중하게 대처하면 롤백이 가능하다.   깃에서 저지를 수 있는 큰 실수와 함께 이를 되돌리고 애초에 방지하기 위한 팁을 소개한다. 목록 마지막으로 갈수록 더 심각한 사고다.   깃 실수 1: 마지막 커밋에 깜박하고 변경을 추가하지 않았을 때 깃 실수 중에서 복구하기가 가장 쉬운 실수에 속한다. 예를 들어 로컬 분기에 작업을 커밋한 이후에 필요한 일부 파일을 스테이징하지 않았다는 사실을 알게 되거나, 커밋 메시지에 세부 정보를 추가하지 않았다는 것을 뒤늦게 깨닫는 경우다. 걱정할 필요 없다. 먼저 스테이징할 새로운 변경 사항이 있다면 스테이징을 한다. 그 다음 git commit --amend를 입력해서 커밋 메시지를 편집한다. Esc를 누른 다음 :xq를 입력해서 저장하고 편집기에서 나온다. (기본 깃 편집기의 특징을 잘 모르는 깃 초보자는 이 마지막 단계에서 당황하는 경우가 많다.) 파일만 변경하고 커밋 메시지를 수정할 필요는 없다면 git commit --amend --no-edit를 사용해서 파일을 추가하고 메시지 편집 과정을 생략할 수 있다.   이와 같은 종류의 실수를 피하려면 깃에서 커밋하는 방법을 바꿔야 한다. 증분적 리비전을 추적하기 위해 수시로 작게 커밋하는 작업은 임시 분기에서 한다. 그리고 이 과정에서 중요한 변경은 git commit 명령을 하는 시점까지 기다리지 말고 다른 곳에 문서로 작성한다. 그런 다음 중요한 이정표에 도달하면 임시 분기에서 git me...

2020.01.23

올해가 가기 전에 반드시 배워야 할 6가지 IT 기술

기술은 빠르게 변한다. 그래서 자바 1.3 코드 편집이나 파워빌더(PowerBuilder)에만 집착하면 새로운 취업 기회를 잡기가 점점 어려워질 것이다. 그렇다면 어떤 기술을 배워야 할까? 자신의 경력을 계속 발전시키고 시장 수요에 맞춰 연봉을 높이려면 지금 제시하는 6가지 기술 정도는 알고 있어야 한다. 1. 하둡 : 신기술 시장의 지배자 아직 하둡에 대해 잘 모르고 있다면 서둘러 하둡(Hadoop)에 통달해야 한다. 맵리듀스(MapReduce) 개념과 이용 방법도 알아야 한다. 하둡은 인기와 수요 등 모든 기준에서 신기술 시장을 지배하고 있다. 다른 기술을 배울 능력도 있을 수 있지만 하둡은 더 어렵다. 'Hello world' 이상을 터득하기 위해서는 더 많은 시간과 노력을 기울여야 한다. 가장 어려운 작업 중 하나는 스스로 공부를 할 간단한 주제를 찾는 것이다. 그러나 이조차도 그리 쉽지는 않다. 충분한 데이터를 확보하는 것도 마찬가지다. 위키피디아(Wikipedia)같이 인기는 있지만, 덩치가 커서 별 쓸모없는 데이터들이 있다. 어쩌면 이를 다른 것들과 결합해, 누가 누구를 '편집하는 것'을 좋아하는지 보여주는 일종의 소셜 그래프를 만드는 것도 방법이다. 호튼워크(Hortonwork)는 깃허브(GitHub)와 관련해 유사한 개념을 입증해 보였다. 일단 '손을 더럽히고 나면' 맵리듀스가 대답할 수 있는 다른 질문 결과를 화면에서 확인할 수 있게 될 것이다. 이 분야에는 호튼워크 같이 하둡에만 전문화된 회사에서 (VM웨어/EMC에서 분사한) 피보탈(Pivotal) 같이 여러 기술을 취급하는 업체, 자신들의 제품에 하둡을 도입하기 시작한 오라클(Oracle) 등 기존 업체까지 많은 기업이 있다. 이 가운데 어떤 회사도 성장 가능성은 무궁무진하다. 2. 몽고DB : 객체지향형 백 엔드의 출발점 하둡만큼 거대하지는 않지만 몽고DB(MongoDB) 또한 중요한 기술이다. 또 훨씬 배우기 쉽다....

하둡 몽고DB Node.js 스칼라 어셈블리

2013.08.26

기술은 빠르게 변한다. 그래서 자바 1.3 코드 편집이나 파워빌더(PowerBuilder)에만 집착하면 새로운 취업 기회를 잡기가 점점 어려워질 것이다. 그렇다면 어떤 기술을 배워야 할까? 자신의 경력을 계속 발전시키고 시장 수요에 맞춰 연봉을 높이려면 지금 제시하는 6가지 기술 정도는 알고 있어야 한다. 1. 하둡 : 신기술 시장의 지배자 아직 하둡에 대해 잘 모르고 있다면 서둘러 하둡(Hadoop)에 통달해야 한다. 맵리듀스(MapReduce) 개념과 이용 방법도 알아야 한다. 하둡은 인기와 수요 등 모든 기준에서 신기술 시장을 지배하고 있다. 다른 기술을 배울 능력도 있을 수 있지만 하둡은 더 어렵다. 'Hello world' 이상을 터득하기 위해서는 더 많은 시간과 노력을 기울여야 한다. 가장 어려운 작업 중 하나는 스스로 공부를 할 간단한 주제를 찾는 것이다. 그러나 이조차도 그리 쉽지는 않다. 충분한 데이터를 확보하는 것도 마찬가지다. 위키피디아(Wikipedia)같이 인기는 있지만, 덩치가 커서 별 쓸모없는 데이터들이 있다. 어쩌면 이를 다른 것들과 결합해, 누가 누구를 '편집하는 것'을 좋아하는지 보여주는 일종의 소셜 그래프를 만드는 것도 방법이다. 호튼워크(Hortonwork)는 깃허브(GitHub)와 관련해 유사한 개념을 입증해 보였다. 일단 '손을 더럽히고 나면' 맵리듀스가 대답할 수 있는 다른 질문 결과를 화면에서 확인할 수 있게 될 것이다. 이 분야에는 호튼워크 같이 하둡에만 전문화된 회사에서 (VM웨어/EMC에서 분사한) 피보탈(Pivotal) 같이 여러 기술을 취급하는 업체, 자신들의 제품에 하둡을 도입하기 시작한 오라클(Oracle) 등 기존 업체까지 많은 기업이 있다. 이 가운데 어떤 회사도 성장 가능성은 무궁무진하다. 2. 몽고DB : 객체지향형 백 엔드의 출발점 하둡만큼 거대하지는 않지만 몽고DB(MongoDB) 또한 중요한 기술이다. 또 훨씬 배우기 쉽다....

2013.08.26

IDG 설문조사

회사명:한국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.5.0.9