Background Image
조회 수 1456 추천 수 1 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄 첨부

시작하며

안녕하세요, 유형규 선임연구원입니다. 이번 포스트에서는 먼저 큐브리드 프로젝트의 개발 프로세스를 소개하고, 프로세스를 개선하기 위한 노력과 개발 문화를 소개하려고 합니다. 큐브리드에 입사한 지 벌써 거의 2년 반이 흘렀습니다. 처음 입사했을 때 하나의 팀이었던 개발 조직도 어느새 대단한 동료 개발자분들이 많이 입사하면서 세 개발팀과 QA팀까지 규모가 제법 커지면서 새로 합류한 신입 동료 개발자분들도 많아졌습니다. 입사 후 첫 메이저 버전 릴리즈를 경험하면서 릴리즈 과정을 돌아보며 동료 개발자들과 큐브리드의 개발 프로세스를 조금 더 개선하게 되었습니다.

 

오픈소스 데이터베이스 프로젝트, CUBRID의 개발 프로세스

큐브리드는 오픈소스 프로젝트 입니다. 큐브리드는 참여, 개방, 공유의 가치를 지향하며 이를 실현하기 위해 정보의 공유와 프로세스의 투명성은 큐브리드의 개발 프로세스와 문화에 녹아있습니다.

큐브리드에 기여하는 모든 개발자는 오픈소스 프로젝트 개발 프로세스를 기반으로 개발을 진행합니다. 이 의미는 큐브리드 사내의 개발자든 큐브리드에 외부 기여자 (컨트리뷰터) 모두 동일한 과정으로 개발을 진행한다는 것입니다. 또한 개발 과정에서 만들어지는 정보 (기능 정의, 디자인 설계, 소스 구현)는 자연스럽게 개발 프로세스 과정에서 공유됩니다.

CUBRID의 모든 프로젝트, 기능 추가, 버그 수정은 다음과 같은 과정을 거쳐서 완료됩니다.

dev-process.PNG

  • - 커뮤니케이션 (Communication): 프로젝트, 기능 추가, 버그 수정에 대한 제안과 토론을 합니다.
  • - 선별 (Triage): 세상의 모든 문제를 해결할 순 없는 것 처럼, 큐브리드에 필요한 모든 기능을 단번에 모두 개발 하거나, 모든 버그를 완벽하게 알아내고 해결할 수 없습니다. 프로젝트 메인테이너 (개발 리더)가 해결해야할 작업인지, 어떤 작업을 우선해서 먼저 시작할 지 판단합니다.
  • - 개발 (Dev): 지정된 개발자가 설계 디자인, 코드 구현, 코드 리뷰를 수행합니다.
  • - 검증과 테스트 (QA): 구현 결과에 대해 큐브리드 QA 시스템에서 기능, 성능 테스트를 수행합니다.

큐브리드는 위에서 설명한 개발 과정을 JIRA와 Github 협업 도구를 사용하여 CUBRID 개발 프로세스를 정의하고 운영하고 있습니다. JIRA는 소프트웨어 프로세스 관리를 도와주는 협업 도구입니다. 각각의 작업을 JIRA 이슈라는 단위로 관리할 수 있습니다. Github은 오픈소스 프로젝트를 위한 원격 저장소를 제공해주는 서비스로, 웹 상에서 Pull Request라는 기능을 통해 코드 리뷰를 수행할 수 있습니다.

 

JIRA

JIRA.PNG

예시) http://jira.cubrid.org/browse/CBRD-23629

 

CUBRID의 모든 프로젝트, 기능추가, 버그수정은 JIRA 이슈 생성으로부터 시작합니다. 개발 과정에서 이슈에는 어떤 작업을 할 건지 (기능 정의), 어떻게 할 것인지 (설계 디자인) 또 어떤 과정으로 작업이 완료했는지 (상세 설계/구현)에 대한 기록이 위 그림과 같이 자연스럽게 남게됩니다

.

jira-status.PNG

큐브리드 개발 프로세스와 JIRA 이슈 상태

 

각 JIRA 이슈에 대해 앞서 설명한 [기능 제안/토론 → 선별 → 개발 → 테스트] 과정은 위 그림과 같이 이슈의 상태를 가집니다. (OPEN, CONFIRMED, IN PROGRESS, REVIEW IN PROGRESS, REVIEWED, RESOLVED, CLOSED) 상태의 이름을 보면 각 단계에서 어떤 작업을 하고 있는지 쉽게 파악할 수 있는데, 각 상태에 따라 설계/구현 중인지, 코드 리뷰 중인지, 테스트 중인지 알 수 있습니다.

 

Github 코드 리뷰

코드 리뷰란 이슈를 담당한 개발자가 작성한 코드를 큐브리드에 반영하기 전에 다른 개발자가 코드를 검토하고 피드백하는 과정입니다. Github에서는 각 이슈에서 개발한 결과물에 대해 Pull Request 기능을 이용해 코드 리뷰를 수행합니다. JIRA에서 공유된 내용 (기능 스펙, 설계 디자인) 을 참고하여 큐브리드의 개발자들은 구현 로직에 대해서 더 안전하고 더 빠른 방법을 찾기 위해 토론합니다.

codereview.PNG

 

개발 프로세스 개선

개발 프로세스는 왜 개선하게 되었는가?

어느 날 업무를 하다가 동료들과 점심시간에 꿀 같은 낮잠을 포기하고 개발자들의 창의성이 가장 높아진다는 커피 타임 & 잡담을 가지고 있었습니다. 가장 최근에 릴리즈된 CUBRID 11 버전의 기능을 개발하면서 있었던 일, 힘들었던 이야기를 하면서요.

그러다 동료 개발자들끼리 앞서 설명한 개발 프로세스에 따라 작업을 할 때 조금씩 디테일이 차이가 난다는 것을 알게 되었습니다. 작업이 종료된 순간에는 "모로 가도 서울만 가면 된다"라는 말처럼 성공적으로 릴리즈는 했지만, 어딘가 찜찜했습니다.

그래서 동료 개발자들과 큐브리드의 개발 프로세스를 뜯어보기 시작했습니다. "이건 왜 이렇게 해야 하지? 매번 넣어주는 이 정보의 의미는 뭘까? 이 절차가 효율적일까?" 하고 서로 질문하며 Why? 를 생각해보기 시작했습니다. 많은 부분에서 대답은 "모호한 부분이 많아 개선이 필요하다." 였습니다.

앞서 설명했던 큐브리드의 개발프로세스는 이전에 누군가의 노력으로 만들어진 절차입니다. 우리가 왜, 어떤 목표를 가지고 개발프로세스를 운영하고 있는지 충분한 이해를 못 한다면 개발 문화로 자리 잡지 못한다고 생각했습니다. 시간이 지날수록 모호한 규칙들은 금방 잊어버리거나 확실히 합의 되지 않아 일부의 구성원들만 알고 있는 것 같은 경우가 생기고 있었습니다. 개발 프로세스의 각 요소에 대해서 충분한 합의가 없이 구성원들의 문화로 자리 잡지 못한다면, 서로 조금씩 다르게 이해하고 있는 디테일들은 구성원들의 귀차니즘과 까먹음에 의해서, 지켜야 할 가치 있는 개발 문화에서 멀어질 것이 당연했습니다.

그래서 큐브리드가 개발 문화로 지켜야 할 가치는 무엇일까 생각해보았습니다. 그것은 이 포스팅의 첫 문단에서 소개한 오픈소스의 주요 가치인 "참여, 개방, 공유" 입니다. 큐브리드의 개발 문화의 관점에서 해석해보면 "큐브리드 프로젝트에 누구든 쉽고 안전하게 참여할 수 있고, 그 과정은 누구든 투명하게 볼 수 있으며 정보들이 충분히 잘 공유되어야 한다"라고 볼 수 있습니다. 그리고 비로소 이러한 가치들을 잘 지키는 것이 더 높은 수준의 개발 결과물과 연결된다는 것을 알게 되었습니다.

이러한 내용들이 사내에서 공유되어, 잘 정립된 개발 프로세스는 단순히 관리의 편의성, 성숙한 개발문화를 표현하는 것을 넘어서 업무의 효율성을 극대화해 줄 것이라는 공감대가 형성되어 개발 프로세스를 조금 더 개선하게 되었습니다. 다음 장에서 개발 프로세스의 개선사항과 "참여, 개방, 공유"의 가치와 어떻게 연결되는지 알아보겠습니다.

 

JIRA 프로세스 정리

앞서 큐브리드 개발 프로세스 소개에서 설명한 것과 같이 CUBRID의 모든 프로젝트, 기능추가, 버그수정은 JIRA 이슈 생성으로부터 시작합니다. 이슈를 생성하고 관리할 때 각 개발 프로세스 단계에서 필수로 작성되어야 할 항목들과 내용들을 작성해야 하는데 사용자가 파악하기 힘든 부분이 많았습니다.

jira-open.PNG

위의 화면은 JIRA 프로세스를 개선하기 전의 이슈 생성 창입니다. JIRA 프로젝트를 만들면 기본으로 설정된 화면을 그대로 사용하고 있었고 다음과 같은 문제가 있었습니다.

  • - 이슈를 생성할 때 입력해야 할 항목들이 너무 많이 보여서 어떤 항목만 작성해야할 지 모르겠음
  • - 어떤 내용을 작성해야할지 모르겠음

이 문제로 이슈 작업마다 필요한 내용들이 일관적으로 작성되지 않거나, 매번 작업을 시작할 때마다 내용을 넣어야하나 말아야하나 고민하면서 생산성이 떨어지고 있었습니다.

 

이슈를 생성할 때 입력해야 할 항목들이 너무 많이 보여서 어떤 항목만 작성해야할 지 모르겠음

큐브리드에 새로 합류한 동료개발자가 처음 이슈를 생성할 때 가장 많이 하는 질문은 "헉... 여기 있는 내용 다 입력해야해요??" 였습니다. 이슈를 생성할 때 프로젝트 메인테이너가 이슈를 선별하기 위해서 필요한 내용은 이 중 몇 가지만 정해져 있는데, JIRA의 기본 설정을 그대로 사용해서 모든 필드가 보여지고 있었습니다.

이런 상황은 외부 기여자가 큐브리드에 참여하기 위한 문턱을 높이게 되는데, 이슈 생성 버튼을 눌렀을 때, 너무 많은 필드가 한꺼번에 보이면 혹시나 잘못 입력할까봐 여기저기 찾아보다가 기여해보기를 포기하게 됩니다.

따라서 각 이슈의 상태에서 필요한 내용들을 정리해서, 그 상태로 변경할 때 필수적으로 입력해야하는 내용만 보여져 입력하도록 설정했습니다.

모든 개선사항을 설명하기 힘들어 한 가지 예만을 소개하자면, 버전과 관련한 필드의 경우 이슈를 생성하고 관리할 때 구성원들이 가장 헷갈려하는 부분들 중에 하나였습니다. 위 그림에서 빨간색으로 표시한 것 처럼 다음 세 가지 버전 필드가 이슈 생성 과정에서 함께 보여지니 어디에 입력해야 할지 모르니 이 중 하나에만 값을 넣어주거나 입력을 포기하는 경우가 생겼습니다.

  • - Affected Version: 이슈 생성자가 분석 과정에서 버그나 문제를 찾은 버전 (버그 수정 타입 only)
  • - Planned Version: 이슈를 진행하도록 계획한 버전
  • - Fixed Version: 이슈 결과가 반영된 버전

그래서 각 버전에 대해 명확한 의미를 공유하고, 어떤 이슈의 상태에서 입력해야 하는지 정의했습니다. Affected Version은 이슈 생성 시(OPEN 상태), Planned Version은 프로젝트 메인테이너가 이슈 선별 시(CONFIRMED), 그리고 Fixed Version은 이슈 해결 시(RESOLVED) 에 입력해야합니다. 그래서 다음 그림과 같이 이슈 상태가 변할 때마다 각 단계에서 필요한 항목, 입력해야 하는 버전만 보여져 자연스럽게 내용을 빠뜨리지 않고 또 좀 더 편하게 개발 프로세스를 따라 작업을 진행할 수 있습니다.

jira-version-resolved.PNG

 

어떤 내용을 작성해야할지 모르겠음

큐브리드에서는 이슈를 생성할 때 해야할 작업에 따라 이슈 타입(Issue Types)를 지정합니다.

  • - Correct Error: 버그 수정
  • - Improve Function/Performance: 기존의 기능을 개선하거나 성능을 향상
  • - Development Subject: 새로운 기능
  • - Refactoring: 불필요한 코드 정리, 코드 구조 변경 등의 작업
  • - Internal Management: 소스 관리를 위한 작업
  • - Task: 나머지

이러한 이슈 타입에 따라 작성할 내용이 달라지게 됩니다. 예를 들어 버그 수정의 경우에 어떤 버그가 발생했는지, 버그를 재현해보려면 어떻게 해야하는지, 버그를 고치면 어떻게 동작해야하는지 등을 적어야 합니다. 또 기능 개선이나 새로운 기능인 경우에 어떤 기능을 어떻게 추가할건지 자세한 설명이 필요합니다 (기능 스펙과 설계 디자인). 이 내용을 충분히 잘 작성하고 공유하면 프로젝트에 참여하는 사람들에게 좀 더 쉽게 프로젝트에 반영된 내용들을 파악할 수 있게 합니다. 그리고 이렇게 잘 정리해서 공유된 기능 스펙이나 설계 디자인은 개발 작업 결과의 품질을 높이는 장점도 가지게 됩니다.

그래서 우리는 각 이슈 타입에 따라 꼭 담아야 할 내용들을 적도록 내용 템플릿을 구성했습니다.

Correct Error

Improve Function/Performance

Development Subject

Refactoring

Internal Management

Task

  • Description: 이슈 설명

  • Test Build: 빌드 버전

  • Repro: 버그를 재현하기 위한 매우 자세한 절차

  • Expected Result: 기대 결과 (고쳐져야 할 예상 결과)

  • Actual Result: 현재 결과 (문제가 있는 결과)

  • Additional Information: 추가로 참고할 자료

  • Description: 이슈 설명

  • Specification Changes: 변경될 기능 스펙

  • Implementation: 디자인 명세, 구현 컨셉 및 상세를 작성

  • Acceptance Criteria: 디자인/구현의 완료 판단(리뷰)의 기준 정의

  • Definition of done: 이슈를 완료하기 위해 도달해야 할 검증

Description: 이슈 설명

 

이 내용들은 다음 장에서 설명할 코드 리뷰 프로세스를 개선하는데 큰 도움을 줍니다. 큐브리드는 여러 기능과 모듈이 복잡하게 얽혀있는 시스템인 만큼 코드 변경사항만을 가지고 모든 맥락을 파악하기 어렵기 때문입니다.

 

Github 코드 리뷰/코드 반영 프로세스 개선

개발 프로세스에서 가장 중요한 목표 중 하나는 코드 리뷰를 어떻게 잘 할 수 있을까입니다. 코드 리뷰로 얻을 수 있는 장점은 다음과 같습니다. [3]

  • - 더 좋은 코드 수준: 코드의 품질과 쉽게 관리할 수 있는 구조로 만듭니다.
  • - 결함 발견: 기능 정확성(버그), 성능 문제, 보안 취약성 등을 더 잘 발견 할 수 있습니다.
  • - 학습/지식 전달: 리뷰어와 저자, 그리고 오픈소스 프로젝트 참여자에게 코드베이스, 해결 방법에 대한 접근법 등의 지식등을 전달하고 공유할 수 있습니다.
  • - 책임감 증대: 리뷰어와 저자 모두가 그 코드에 대한 책임감을 가질 수 있습니다.
  • - 더 나은 솔루션: 더 나은 해결 방법과 아이디어에 대한 공유가 이루어집니다.

이러한 장점들은 구성원 모두 잘 알고 있지만, 막상 코드 리뷰를 하면 리뷰어는 어느 수준까지 리뷰해야하지? 또 작성자는 이런 수준의 리뷰까지 과연 필요한가? 라는 생각들을 하면서 조금은 의무적인 리뷰가 되어버릴 수 있습니다.

그래서 조금 더 효과적/효율적인 코드 리뷰를 유도하기 위해 어떻게 코드 리뷰를 잘 할 것인지 고민하고 개선할 필요가 있었습니다. 코드를 읽는 것은 고수준의 집중력을 요구하는 작업입니다. 따라서 리뷰어가 짧은 시간에 고수준의 고민을 하고 피드백을 줄 수 있도록 해야합니다.

큐브리드에서 코드 리뷰를 잘 하기 위해 도입해왔고, 또 개선한 내용을 소개해드리겠습니다.

 

자동화 도구 도입

지루하고, 컴퓨터가 더 잘 할 수 있는 부분에는 자동화 도구를 활용해서 리뷰어의 정신적인 노력을 낭비하지 않도록 해야합니다. 예를 들어 코드 스타일, 라이선스를 고치거나 자주 발생하는 실수 (변수를 초기화하지 않거나 필요 없는 코드가 남아있는 등) 와 같은 것입니다.

큐브리드에서는 코드 리뷰에 도움을 줄 수 있도록 기본적으로 다음의 자동화 도구를 도입하고 있었습니다.

  • - 빌드: 반영할 코드에 대해서 각 환경 별로 (CentOS, Ubuntu, Windows) 빌드를 하고 성공 여부를 보여줍니다.
  • - SQL 테스트 자동화: 많은 SQL 테스트 케이스를 돌려보고 기능에 문제가 없는지 검증합니다.

참고) https://app.circleci.com/pipelines/github/CUBRID

 

이러한 자동화 도구는 좀 더 안정적인 코드가 반영될 수 있도록 도움을 주었습니다. 하지만 리뷰어가 코드가 설계 디자인을 얼마나 잘 충족하는지, 반영할 코드의 로직에 집중할 수 있도록 도와주기엔 부족합니다. 리뷰어는 단순 실수나, 코드 포매팅과 같은 눈에 쉽게 보이는 문제에 리뷰 시간 동안 매몰되기 쉽기 때문입니다.

indent.PNG

코드 퀄리티 유지에 중요하지만, 고수준의 리뷰와는 거리가 먼 코드포매팅 피드백

 

따라서, Pull Request에서 이러한 저수준의 리뷰는 자동화 도구를 사용하여 리뷰어가 고수준의 리뷰만을 집중할 수 있도록 개선했습니다.

  • - license: 오픈소스의 라이선스 준수와 책임을 다하기 위해 올바른 형태의 라이센스 헤더 주석을 가지고 있는지 확인합니다.
  • - Pull Request Style: 반영할 코드에 대한 정보가 충분히 잘 공유될 수 있도록 모든 Pull Request이 각각의 JIRA 이슈와 연결되어야한다는 규칙을 가지고 있고 이를 검사합니다.
  • - code-style: 일관성 있는 코드 유지를 위해 정의된 코드스타일을 따르는지 확인합니다. 코드 스타일은 코드 포맷팅 도구들을 이용하여 정의하고, code-style은 이 도구들을 이용해 정해진 규칙을 올바르게 따르는지 확인하고 수정합니다. 만약 규칙과 다르다면 실패하고 PR의 suggestion을 통해 리포트 합니다.
  • - cppcheck: Cppcheck는 C++ 언어를 위한 정적분석 도구입니다. 사용되지 않는 변수, NULL 참조 등 개발자가 저지를 수 있는 많은 문제들이 정적 분석을 통해 발견될 수 있습니다. 이러한 오류들은 실수하기 쉽지만 명백하여 문맥없이 코드를 살펴보는 것만으로 찾아낼 수 있습니다. 그렇기에 리뷰어가 일일이 찾아내고 코멘트를 다는 것은 낭비입니다. 에러가 있을 경우 실패하고 PR에 코멘트를 사용하여 리포트 합니다.

automation_tool.PNG

 

새로 도입된 자동화 도구는 Github에서 직접 제공하는 CI 도구인 Github Actions (https://docs.github.com/en/actions) 를 사용했습니다. 이 도구의 도입으로 큐브리드에 기여자들이 큐브리드의 코드 컨벤션과 도달하려는 코드의 퀄리티를 좀 더 쉽게 이해하고 참여할 수 있습니다. 자동화 도구를 통과하지 않으면 쉽게 머지 (코드 반영) 되지 않아 혹시라도 실수할 걱정을 하지 않아도 됩니다.

 

큰 리뷰를 잘게 나누기

큐브리드는 여러 기능과 모듈이 복잡하게 얽혀있는 데이터베이스 시스템인 만큼 반영하려고 리뷰를 요청한 코드의 양이 어마어마하게 많은 경우가 많이 생깁니다. 너무 많은 코드 변경사항을 가진 하나의 Pull Request는 리뷰어의 효과적인 리뷰를 불가능하게 합니다.

 

code-review-best-practices-figure-01.gif

LOC (코드 라인 수) 가 400 줄 이상 넘어 갈수록 코드 결함 발견 밀집된 (Defect Density)은 적어진다. [4]

 

큐브리드에서는 너무 많은 변경사항을 가진 Pull Request를 피하기 위해 Feature branch를 생성해서, 하나의 의미 있는 작은 기능 단위로 코드 리뷰를 수행하려고 노력합니다. Feature branch에 대한 자세한 설명은 [5]를 참고해주세요.

 

개발 프로세스 (큐브리드 기여 가이드) 문서 작성

큐브리드 개발에 조금 더 쉽게 참여하도록, 전체적으로 개발 프로세스가 어떻게 진행되는지 설명하고 각 단계에서 필수적으로 작성해야 하는 내용을 공유할 방법이 필요했습니다. 그래서 큐브리드에 관심있어서 기여해보려는 개발자, 큐브리드에 새로 합류하는 신입 개발자 모두 참고할 수 있는 설명하는 가이드라인 문서를 작성했습니다.

https://dev.cubrid.org/

dev-doc.PNG

 

 

이 가이드라인 문서를 작성하면서 고려했던 사항들이 있는데 다음과 같습니다.

  • - 보기 힘든 문서는 읽지 않는다. 개발 프로세스는 단계별로 되어있으니 각 단계를 설명한 단락으로 쉽게 찾아갈 수 있게 하자!
  • - 누구나 최신 버전을 항상 볼 수 있게 하자!
  • - 완벽한 개발 프로세스도, 가이드 문서도 없다. 더 쉽게 편집할 수 있도록 하자!

워드 문서, JIRA 위키, 구글 문서, 웹 페이스 작성, Github pages 등 많은 도구와 서비스를 고민했습니다. 이러한 고민의 결과로 Gitbook 서비스를 사용하게 되었습니다. (Thank you for Gitbook Team)

  • - 문서 구조별로 탭 형식으로 표시해주어 단락별로 쉽게 볼 수 있습니다.
  • - 웹페이지로 배포되고 실시간으로 수정하고 반영하면 실시간으로 수정사항을 볼 수 있습니다.
  •  -오픈소스 프로젝트에 대해서 Open Source Community 플랜을 지원합니다!

다른 오픈소스 프로젝트에서도 기여 가이드문서를 작성해보려고 한다면 문서 배포 방법과 도구를 고민할 때 한번 참고해보세요!

마치며... 큐브리드의 개발 문화에 대하여

많은 개발자들이 당연히 좋은 개발 문화에서 일하고 싶어합니다. 그러나 세상에 완벽한 개발 문화를 가진 개발 조직은 없다고 생각합니다. 앞서 설명한 개발 프로세스는 '개발 문화'가 만들어지기 위한 수단이고 개발 프로세스에 검증 과정만을 더 추가할수록 당연히 생산성은 그에 따라 떨어집니다. 또 시간이 지나가고 상황이 바뀌면서 개선한 프로세스가 제대로 동작하지 않을 수도 있습니다.

큐브리드는 좀 더 나은 퀄리티의 결과와 높은 생산성의 균형을 찾으려고 노력하며 계속 나아가고 있습니다. 모든 구성원이 좀 더 자연스럽게 큐브리드의 개발 문화에 올라탈 수 있도록 다음의 내용과 같은 코드 리뷰를 잘 하는 법에 대해 구성원들이 모여서 공유하고 토론하기도 합니다.

  • - How to Do Code Review Like a Human (https://mtlynch.io/human-code-reviews-1/, https://mtlynch.io/human-code-reviews-2/)

cubrid-meeting.jpg

 

수평적이고 자유로운 소통, 지식의 공유를 중요하게 생각하는 큐브리드의 조직 문화를 기반으로, 많은 분들이 적극적으로 함께하고 도와주어 개발 프로세스를 개선할 수 있었습니다.

(Special Thanks to CTO, 김재은, 김주호 선임연구원). 이 글을 통해 큐브리드의 개발 조직이 일하는 방식을 소개하고, 개발 문화에 대해 이해할 수 있는 기회가 되었으면 합니다.

감사합니다 :-)

 

참고자료

[1] 오픈소스 가이드, https://opensource.guide/ko/

[2] 오픈소스 기술혁신, 수평적인 정보 공유와 투명한 프로세스가 생명이다, 소프트웨어정책연구소, https://spri.kr/posts/view/19821?page=2&code=column

[3] 코드 리뷰, 위키피디아, https://en.wikipedia.org/wiki/Code_review

[4] Best Practices for Code Review, https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/

[5] Feature branch workflow, https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow


  1. CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

    시작하며 이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다. 이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다. 빌드 준비하기 누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려...
    Date2023.09.08 Category오픈소스 이야기 By유형규 Views298 Votes2
    Read More
  2. CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까?

    시작하며 안녕하세요, 유형규 선임연구원입니다. 이번 포스트에서는 먼저 큐브리드 프로젝트의 개발 프로세스를 소개하고, 프로세스를 개선하기 위한 노력과 개발 문화를 소개하려고 합니다. 큐브리드에 입사한 지 벌써 거의 2년 반이 흘렀습니다. 처음 입사했을 때 하나의 팀이었던 개발 조직도 어느새 대단한 동료 개발자분들이 많이 입사하면서 세 개발팀과 QA팀까지 규모가 제법 커지면서 새로 합류한 신입 동료 개발자분들도 많아졌습니다. 입사 후 첫 메이저 버전 릴리즈를 경험하면서 릴리즈 과정을 돌아보며 동료 개발자들과 큐브리드의 개발 프로세스를 조금 더 개선하게 되었습니다. 오픈소스 데이터베이스 프로젝트, CUBRID의 개발 프로세스 큐브리드는 오픈소스 프로젝트 입니다. 큐브리드는 참여, 개방, 공유의 가치를 지향하며 이를 실현하기 위해 정보의 공유와 프로세스의 투명성은 큐브리드의 개발 프로세스와 문화에 녹아있습니다. 큐브리드에 기여하는 모든 개발자는 오픈소스 프로젝트 개발 프로세스를 기반으로 개발을 진행합니다. 이 의미는 큐브리드 사내의 개발자든 큐브리드에 외부 기여자 (컨트리뷰터) 모두 동일한 과정으로 개발을 진행한다는 것입...
    Date2021.04.29 Category오픈소스 이야기 By유형규 Views1456 Votes1
    Read More
  3. ANTLR, StringTemplate를 사용해서 PL/SQL을 CUBRID Java SP로 변환하기

    ANTLR, StringTemplate를 사용해서 PL/SQL을 CUBRID Java SP로 변환하기 CUBRID DBMS(이하 'CUBRID')는 PL/SQL을 지원하지 않습니다. PL/SQL 문법으로 함수나 서브 프로그램을 만들어서 해왔던 작업들을 CUBRID에서 하려면 Java Stored Function/Procedure(이하 'Java SP')으로 변환해야 합니다. 데이터베이스 개발자나 관리자, 엔지니어는 PL/SQL 문법에는 친숙하지만 프로그래밍 언어에는 친숙하지 않은 경우가 대부분입니다. 또한 어플리케이션 개발은 사용하는 DBMS에 따라 달라지는 부분이 거의 없지만 PL/SQL을 Java SP로 변환하는 것은 새로운 시스템을 개발하는 느낌을 받아서 어려움을 느끼는 것 같습니다. 그래서 PL/SQL 을 Java SP 쉽게 변환하는 방법에 대해서 찾아보던 중 ANTLR에 대해서 알게 되었습니다. ANTLR는 파서를 만드는 도구입니다. 전세계에 있는 컨트리뷰터들로부터 도움을 받아서 다양한 프로그래밍 언어들의 파싱할 수 있도록 문법 파일들을 지원하고 있습니다. 공식 홈페이지에서는 ANTLR에 대해서 아래와 같이 소개하고 있습니다. "ANTLR (ANother Tool for Language Recognition)은 구조화 된 텍스트 또는 이진 파일을 읽고, 처...
    Date2020.12.31 Category오픈소스 이야기 By주영진 Views2797 Votes2
    Read More
  4. 오픈소스 DBMS 10년의 여정

    10년 전인 2008년 11월 22일 NHN(현, 네이버)의 첫번째 개발자 행사인 DEVIEW 2008을 통해 CUBRID 오픈소스 버전이 첫 선을 보였습니다. 사용자 확산을 위해 2006년 5월 무료 라이선스를 선언을 한 이후 2008년 초부터 1년 가까이 오픈소스 전환을 위한 준비 과정을 거쳐 결국 오픈소스 DBMS로 변신을 한 것입니다.   -> CUBRID 2008 신제품이 출시되던 날…   오픈소스 DBMS 전환에 대한 사용자들의 인식을 제고하기 위해 버전 표기는 기존 숫자(CUBRID 6, 7) 중심에서 연도 체계 방식으로 변경하여 “CUBRID 2008”로 명칭을 했으며(2013년 3월 출시한 CUBRID 9부터 다시 숫자 표기로 변경), 라이선스의 경우 많은 논의 과정을 통해 엔진은 소스 코드 수정/배포 시 공개 의무가 있는 GPL v2 or higher, 인터페이스와 도구는 자유롭게 수정/배포가 가능한 BSD 라이선스를 채택했습니다.   CUBRID 2008 출시 후 초기 2년 동안의 미션은 개발자 및 사용자 확산이었습니다. CUBRID Inside라는 개발자 중심의 커뮤니티 행사를 통해 내부 개발자와 외부 개발자간에 만남의 장을 마련했고, 닉네임 Pcraft님 같은 경우에는 CUBRID Manager에 컨트리뷰션을 하시다가 추후 CUBRID 개발팀...
    Date2018.11.30 Category오픈소스 이야기 By정병주 Views1237 Votes0
    Read More
  5. 젊은 열정 대학생들과 함께한 컨트리뷰톤(contributon) 2017

    프롤로그 컨트리뷰톤 2017(https://www.kosshackathon.kr). 약 2달간의 일정으로 진행되는 오픈소스 멘토링 행사에 멘토 자격으로 참여하였습니다. 총 10개의 프로젝트에 각각 12~15명 내외의 멘티들이 선발되어 git 사용법부터 오픈소스에 컨트리뷰션(contribution)까지 진행해보는 과정으로 대학생들이 주를 이루었지만 간혹 경력이 상당한 개발자 분들도 멘티로써 참석하셨습니다. 뜨거운 열정이 느껴집니다. 저희는 CUBRID Manager(GUI 도구)를 진행 프로젝트로 선정하였는데, 오픈소스를 거의 처음 접해보는 멘티들에게 적절한 선택이지 않았나 생각합니다. 아래 사진 속에 저와 멘티들이 보이네요. 아마 진행할 프로젝트와 멘토 소개를 했던 것으로 기억하는데, 오랜만에 100명이 넘는 사람들 앞에서 잡은 마이크라 그런지 긴장한 모습이 역력합니다. 오픈소스 참여하고 싶어요 멘티들과의 첫만남. 저는 “컨트리뷰톤에 등록된 프로젝트 중 왜 CUBRID Manager에 지원하셨어요”란 질문을 던졌습니다. 아마 “CUBRID에 관심이 많아요.”, “DBMS 개발을 해보고 싶어요.”란 답변을 기대했던거 같은데, 의외로 “쉬워보여서요.”, “오픈소스가 처음인데, 멘토님이 친절하실 것 같아...
    Date2017.12.28 Category오픈소스 이야기 By민준 Views1992 Votes0
    Read More
  6. No Image

    손쉬운 PHP 확장 기능 개발

    PHP 확장 기능 Web 개발 인터페이스로 널리 사용되는 PHP에는 PHP고유의 기능 외에도 사용자가 기능을 추가할 수 있는 확장(Extension) 기능이 있습니다. 확장 기능을 사용하기 위해서는 리눅스 상에서는 PHP와 인터페이스되는 확장 라이브러리를 만들어야 합니다. PHP는 C 프로그래밍 초보자라도 확장 기능을 쉽게 만들 수 있도록 Zend Platform이라는 인터페이스를 제공하고 있습니다. 그럼 간단한 'Hello World' 확장 기능을 작성해 보겠습니다. 작성된 확장 기능은 CentOS 6.x 기준입니다. 설정하기 첫 번째 단계는 소스에서 PHP를 컴파일하는 데 필요한 필수 개발 도구 (automake, autoconf 등)를 설치하는 것입니다. 쉘 상태에서 다음 명령을 실행하면됩니다. (이미 이러한 개발 도구가 설치되어 있는 경우는 이 단계는 생략해도 됩니다) $ sed -i "s/^\exclude.*$/exclude=/g" /etc/yum.conf # allow kernel-devel package.                                                         $ yum groupinstall -y 'Development Tools' git 도구를 이용하여 php 소스를 다운 받습니다.  $ git clone http://git.php.net/repository/php-src.git                              ...
    Date2017.12.08 Category오픈소스 이야기 By김병욱 Views2906 Votes0
    Read More
  7. 제16차 동북아 공개SW활성화포럼 참관기

    11월 15일 ~ 16일 중국 톈진에서 개최된 제16차 동북아 공개SW활성화포럼 행사에 다녀왔습니다.   동북아 공개SW활성화포럼은 한중일 협력체를 구성하여 글로벌 시장에서의 영향력을 확보하기 위한 목적으로 2004년 4월 출범하였으며, 금년까지 총 16차에 걸쳐 포럼 행사가 개최되었습니다. (작년에는 제주도에서 개최됨) 또한, 정부 차원의 IT 국장급 회의도 병행해서 운영이 되는데, 한중일 IT국장회의에서 수립된 IT 분야 협력 기본 방향에 맞춰 동북아 공개SW활성화포럼에서는 3국간 협력사업 및 자국 내 공개SW 활성화 활동을 수행하게 됩니다.   한중일 3국에는 각각 한국공개SW활성화포럼(KOPF), 중국공개SW활성화포럼(COPF), 일본공개SW활성화포럼(JOPF)이 구성되어 있으며, 각 포럼에는 4개의 워킹그룹이 - WG1 기술개발분과, WG2 인력양성분과, WG3 표준화분과, WG4 비즈니스분과 - 활동을 하고 있습니다.   [1일차]   오전에는 워킹그룹별로 1년 동안의 각 분과 활동에 대한 정리 및 2018년 계획을 수립하는 회의가 진행되었으며, 오후에는 한중일 국장 합의문과 포럼 의장 합의문에 대한 논의가 진행되었습니다. 또한, 주최국인 중국에서 환영만찬을 제공해 주었...
    Date2017.11.22 Category오픈소스 이야기 By정병주 Views1419 Votes0
    Read More
  8. 공생발전형 SW 생태계 구축 전략에 대한 단상

    작년 10월말 ‘공생발전형 SW 생태계 구축 전략’이 발표되었다. 전략의 기본방향은 IT서비스는 대기업 중심의 시장질서에서 전문*중소기업 중심으로 전환하고, 패키지SW*임베디드SW는 대한민국 경제의 사활이 걸린 분야로 핵심경쟁력 제고에 주력하겠다는 것이다. 이를 위한 정책 부문으로 SW 공정거래 질서 확립, SW 기초체력 강화, SW 융합 활성화, 지속적 추진체계 확보 4개를 선정하고 총 11개의 정책 과제를 제시했다. 이 중 시장에 충격을 주었던 정책 과제가 소프트웨어 공정거래 질서 확립을 위한 전문*중소기업 참여 확대 및 감시기능 강화였다. 그 동안 대기업 SI 업체들이 계열사의 일감몰아주기에 의존하고 저가로 공공시장에 참여함으로써 소프트웨어 생태계를 왜곡하고 중소 SW 기업의 성장을 저해했다는 이유에서다. 구체적인 실천방안으로 소프트웨어산업진흥법 개정을 통해 상호출자제한기업집단 소속 SI 기업의 공공시장 신규 참여를 전면 제한한다는 내용을 제시했으며, 법률 개정 전까지는 대기업 참여하한제 하한금액을 상향 적용하겠다는 것이다. 한국SW전문기업협회 등 패키지 SW 업계에서는 기자간담회를 개최하는 등 환영의 목소리를 일관되게 내고 있...
    Date2012.01.26 Category오픈소스 이야기 Byadmin Views25655 Votes0
    Read More
  9. 오픈소스 소프트웨어 기반의 성공적인 비즈니스 모델

    11월 2일 지식경제부가 주최하고 정보통신산업진흥원, 한국공개SW활성화포럼, 한국공개소프트웨어협회에서 주관한 제2회 공개SW Day 행사에 참석을 했었습니다. 행사의 주요 일정으로 개발자 대회 시상식과 트레이닝 캠프가 진행되었으며, 오전에 카네기멜론대 실리콘밸리 캠퍼스에서 소프트웨어 매니지먼트 프랙티스를 가르치고 있는 Tony Wasserman 교수가 “Building a Business on Open Source Software”라는 주제로 해외초청 강연을 해 주셨습니다.   Wasserman 교수는 강연을 시작하기 전 본인의 노트북과 LCD 프로젝터 간 연결이 매끄럽지 못해 잠시 난관에 부딪쳤는데, 그 와중에 “오픈소스 소프트웨어 행사에서 윈도우 기반의 노트북으로 발표를 하는 것이 맞느냐?”라는 질문을 던져 청중들에게 웃음을 선사했습니다(Wasserman 교수는 리눅스 OS를 사용함). 총 11개의 비즈니스 모델에 대해서 발표를 해 주셨고, 대부분 일반적인 내용들이라 새로움 또는 신선함에 대한 욕구 충족은 되지 않았지만, 전반적으로 핵심 내용만 잘 기술되어 있어서 발표자료의 일부를 발췌해 보았습니다(영어 단어가 평이하여 번역하지 않음).   Subscription Model - User downloads softw...
    Date2010.11.13 Category오픈소스 이야기 By정병주 Views43651 Votes0
    Read More
  10. 큐브리드 “더 로드(The Road)” – 2009년 발자취

    현재 상영 중인 영화 더 로드(The Road)의 네티즌 리뷰 중에 “차가운 절망 속 뜨거운 여정!!”이라는 제목이 눈에 띄어 확인을 해 보았습니다. 절망의 세상 속에서 희망을 이야기하는 뜨거운 부성애의 힘과 아들을 향한 아버지의 모습을 통해 깊고, 진한 여운을 받았다는 감상평이였는데, 왠지 국내 DBMS 시장의 현실과 흡사하다는 느낌을 받았습니다. 왜냐하면, 척박한 글로벌 경쟁 환경 속에서 큐브리드 뿐만 아니라 알티베이스, 티맥스데이타 각각 자신의 색깔을 가지고 뜨거운 여정을 보내고 있는데 전세계적으로 이러한 시장 경쟁 구도를 갖고 있는 국가가 전무하기 때문입니다. 그럼, 이제부터 큐브리드의 2009년 발자취를 살펴보도록 하겠습니다. 2009년은 오픈소스 DBMS로 전환(2008년 11월 CUBRID 2008 R1.1 신제품 출시)하고 나서 맞이하는 첫 번째 해로 상반기에는 “개발자확산”, 하반기에는 “적용확산”이라는 키워드로 국내의 개발자, 사용자에게 다가가기 위해 노력을 하였습니다. 우선, 제품 다운로드부터 들여다보면, 2009년 한해 제품 다운로드 수는 3만 2천여 건으로 2008년 1만 4천여 건 대비 123% 성장하였으며, 총 누적 다운로드 수는 6만 6천 건에 도달했...
    Date2010.01.28 Category오픈소스 이야기 By정병주 Views31485 Votes0
    Read More
Board Pagination Prev 1 2 Next
/ 2

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales