Skip to content

Latest commit

 

History

History
144 lines (104 loc) · 17 KB

faq.md

File metadata and controls

144 lines (104 loc) · 17 KB

3장 자주 묻는 질문과 답변(FAQ)

  • Q1 왜 공개SW 개발방식으로 개발하는 것이 좋은가요?

    공개SW 개발방식은 기존의 내부 자원으로 수행하던 연구개발 방식과 비교하면 다수의 (고객, 개발자, 경쟁사, 협력사 등) 참여를 통해 개발 속도 향상, 개발 비용 절감, 빠른 고객 요구사항 반영, 잠재 고객 확보, 선제적 개발자 확보, 외부 사용자에 의한 품질 검증, 생태계 사전 조성 등의 많은 장점이 있는 방식입니다.

    글로벌 산업에서 두각을 나타내고 있는 구글, MS, 아마존 같은 기업들도 안드로이드, 텐서플로우, vscode, 쿠버네티스 같은 공개SW 연구개발 프로젝트를 공개하고 이를 기반으로 시장을 선도하고 있으며, 대표적인 공개SW 프로젝트 저장소인 깃허브의 사용자 수와 조직의 수는 연 평균 80% 이상 성장하고 있습니다. 18

  • Q2 공개SW 개발방식과 기존 개발방식의 차이점은 무엇인가요?

    보편적으로 공개SW 개발방식은 외부 개발자들의 참여를 허용하기 위해 깃허브와 같은 공개된 소스 코드저장소에 소프트웨어 개발과정을 공개하면서 개발이 진행됩니다. 기존의 개발방식은 일부의 개발자들에 의해 통제되어 소수의 협력으로 개발하게 되지만, 공개SW 개발방식은 누구나 참여할 수 있도록 개발과정이 공개되어 수행하게 됩니다.

    공개SW 개발방식은 다수의 외부 참여를 통해 다양한 아이디어를 수용할 수 있고 이를 기반으로 소프트웨어의 문제해결 시간 단축과 많은 사용자에 의한 소프트웨어 품질에 대한 검증을 효율적으로 수행할 수 있습니다.

  • Q3 공개SW R&D를 수행하게 되면 반드시 전체 프로그램 소스 코드를 공개해야 하는지요?

    그렇지 않습니다. 기존 공개SW 프로젝트들도 전체 소스 코드를 공개하는 경우가 아닌 특정 라이브러리, 모듈 등을 공개하는 경우도 있습니다. 또한 동일한 SW 중 일부 기능을 제공하는 소스 코드는 공개해서 자유롭게 사용하도록 허용하면서도 일부 기능은 상용SW로 판매하는 경우도 있습니다. 따라서, 공개SW R&D의 추진전략에 따라 소스 코드 공개 범위를 검토할 수 있습니다.

  • Q4 공개SW R&D 결과물에 적용할 공개SW 라이선스 선택의 기준은 무엇인가요?

    공개SW R&D 결과물에 적용할 라이선스 선택기준은 추진전략입니다. 추진전략이 다양한 산업과 사용자들의 자유로운 사용을 장려하기 위한 경우는 될 수 있으면 제약조건이 없는 퍼미시브(허용적) 라이선스 계열을 적용하는 것이 권장되고, 공개SW R&D 결과물을 공개 후 특정 기업이나 개발자들의 상용/독점 사용을 제한하고 싶은 경우는 스트롱 카피레프트 라이선스 계열을 적용하는 것을 권장합니다. 공개SW 라이선스에 대한 보다 자세한 내용은 연구계획 수립을 위한 가이드라인 편에서 참고하실 수 있습니다.

  • Q5 공개SW 연구개발 과제의 성과지표는 어떻게 구성해야 하나요?

    공개SW 연구개발과제의 성과지표는 공개한 프로젝트의 성숙도를 표현할 수 있는 다양한 지표를 선정하여 관리할 수 있습니다. 소스 코드 저장소의 활성화 정도를 표시하는 저장소, 스타, 커밋(commit), 포크(fork), 이슈(Issue), 풀리퀘스트(Pull Request) 등의 지표와 커뮤니티의 활동성을 대변하는 기여자 수, 커뮤니티 사용자, 홍보 채널, 각종 행사 참여 수, 기술 문서 등의 지표, 그리고 결과물의 활용성을 의미하는 기술이전, 적용사례, 파트너 참여기업 수 등의 지표도 사용할 수 있습니다.

    이러한 다양한 지표를 이용하여 소스 코드 저장소의 README 파일에 배지 이미지 형식으로 가시화하여 구성하면 프로젝트의 사용자에게 신뢰할 수 있는 프로젝트로 보일 수 있으므로 적극적으로 활용하는 것이 좋습니다.

  • Q6 공개SW 담당자로서 필요한 역량은 어떻게 준비해야 하나요?

    한국정보통신기술협회의 표준으로 배포 중인 공개소프트웨어 기반 개방형 혁신 연구개발 역량 성숙도 모델 (TTAK.KO-11.0246)에 따르면 공개SW 연구개발과제 수행을 위해 필요한 역량은 다음과 같습니다.

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

    정보통신산업진흥원(NIPA)의 오픈소스 소프트웨어 통합지원센터에서는 공개SW 교육지원사업으로 대상별 맞춤형 교육을 운영하고 있으니 이를 활용하여 과제 수행에 필요한 역량을 사전에 준비할 수 있습니다.


  • Q7 공개SW 개발과정을 미리 학습하려면 어떻게 하는 것이 좋을까요?

    공개SW 프로젝트마다 각기 다른 개발문화와 절차를 가지고 운영되기 때문에 과제 수행에 참여하는 연구원은 다양한 공개SW 프로젝트에 참여하여 자신의 소스 코드를 다른 프로젝트에 기여 해보는 과정을 통해 공개 SW 개발방식을 배울 수 있습니다. 만약 어떻게 공개SW 프로젝트에 기여하는지 모르는 경우는 다음과 같은 문서를 참고할 수 있습니다.

    그리고 정보통신산업진흥원(NIPA)의 오픈소스 소프트웨어 통합지원센터에서는 공개SW 컨트리뷰션 아카데미를 운영하여 공개SW 개발방식을 실제 공개SW 프로젝트의 경험자들과 함께 배워볼 수 있도록 제공하고 있으므로 공개SW 개발방식을 학습하기 위해 이 과정을 활용하는 것도 좋습니다.

    컨트리뷰션 아카데미
    URL : https://www.oss.kr/contribution_academy

    언어, 협업 개발문화, 시작의 두려움 등 다양한 이유로 공개SW 진입장벽이 높게만 느껴지는 개발자들을 위한 '공개SW 컨트리뷰톤' 멘토링 행사.

    컨트리뷰션 아카데미를 통해 선배 개발자가 직접 기여하는 공개SW 프로젝트 가이드와 함께 공개SW 기여에 대한 진입장벽을 뚫어 참여·공유·협업 방식의 글로벌 개발문화와 다양한 기여(Contribution)를 직접경험하는 프로그램.

    예비 컨트리뷰터 인재들이 자신의 잠재적 공개SW 역량을 강화하고, 다양한 글로벌 기술 분야에서 코드 기여, 코드 리뷰, 테스트, 버그 리포트, 기능제안, 이슈 댓글, 질문,&건의, 번역, 문서작성 등의 다양한 방법 으로 공개SW 문화에 기여할 수 있는 기회를 제공.

  • Q8 과제에서 사용할 외부의 공개SW 프로젝트를 어떻게 평가할 수 있나요?

    공개SW 연구개발과제 수행 시 외부의 공개SW 프로젝트를 활용해야 하는 경우, 비슷한 기능을 제공하는 다수의 프로젝트에 대하여 조사를 하게 되며, 발견된 프로젝트 중 어떤 프로젝트가 더 과제 수행에 적합한지 평가하기 위한 기준이 필요합니다.

    공개SW 프로젝트를 평가하는 경우에는 일반적인 소프트웨어의 품질속성과 공개SW의 특성을 반영한 품질 속성, 그리고 과제 이해관계자의 요구사항과 연구원의 역량 등을 복합적으로 고려하여 평가해야 합니다.

    한국정보통신기술협회의 공개SW 성숙도 및 적용성 평가 지침(TTA.KO-11.0133)은 공개SW 프로젝트의 성숙도 및 적용성을 평가하기 위한 항목과 평가방법을 제공하므로, 외부의 공개SW 프로젝트의 평가에도 활용할 수 있으며 수행 중인 공개SW 연구개발과제의 성숙도를 자체 평가하는 용도로도 활용할 수 있습니다.

  • Q9 공개SW 프로젝트에서 사용하는 개발 방법론은 어떤 것이 있나요?

    기존의 소프트웨어 개발 방법론인 폭포수 모델에서는 요구사항 개발, 설계, 구현, 검증, 관리와 같이 순차적인 절차에 의해 개발이 진행되지만, 공개SW 개발방식에서 외부 기여자의 참여는 이러한 순차적인 단계에 대한 고려가 없으므로 소프트웨어 개발의 전 과정에서 외부 기여자의 요청에 대한 수용이 가능한 소프트웨어 개발 방법론이 필요합니다.

    공개SW 개발 방법론에 대한 명확한 정의는 없지만, 보편적으로 공개SW 개발에 사용되는 개발 방법론은 점진적 순환을 기본으로 하는 스크럼, 칸반 등의 애자일 개발 방법론이 자주 사용되며 자유로운 외부 기여자의 참여를 소프트웨어 개발과정에 적용하기 위해 연구개발 과제 수행에 적합한 브랜치 모델(git-flow, githubflow 등)을 기반으로 소스 코드의 형상 관리가 요구됩니다.

  • Q10 공개SW 연구개발 과제의 결과물을 배포할 때는 소프트웨어의 소스 코드만 배포해도 되나요?

    과제의 결과물로 소프트웨어 소스 코드만 배포해도 되지만 공개SW 개발방식의 장점을 활용하기 위해서는 공개한 프로젝트를 사용하려는 외부 사용자가 사용하기 쉽도록 소프트웨어 소스 코드, 빌드 결과 파일(exe, jar 등), 배포용 패키지(rpm, deb, appImage 등), 제품 설명서 같은 여러 가지 프로그램 사용을 돕는 파일도 함께 배포하는 것이 좋습니다.

  • Q11 공개한 프로젝트 사용자에게 프로젝트의 품질을 어떻게 보여줘야 하나요?

    성숙도가 높은 공개SW 프로젝트는 코드 커버리지, 릴리즈 관리 도구를 연동하여 항상 사용자에게 소프트웨어 소스 코드의 품질에 대한 신뢰성을 제공합니다. 공개SW 프로젝트의 다양한 메타데이터를 이미지 형태로 제공하는 서비스(https://shields.io/)를 이용하여 배지 이미지를 소프트웨어 소스 코드 저장소의 README 파일에 표기하여 품질을 가시화하는 것도 좋은 방법입니다.

  • Q12 공개SW 연구개발 과제의 라이선스 검증은 어떻게 해야 하나요?

    공개SW 연구개발과제의 수행 중 외부의 공개SW를 획득하여 활용하기 위해 기존의 소프트웨어 소스 코드에 결합하는 시점과 공개SW 연구개발과제의 결과물을 배포하는 시점에는 반드시 라이선스 검증을 통해 의무사항의 준수 여부를 확인하고 조치해야 합니다.

    연구개발과제 수행 조직 내부의 자원으로 라이선스 검증이 어려운 경우에는 정보통신산업진흥원(NIPA)에서 공개SW 라이선스 검증서비스(https://www.oss.kr/license_verify)를 1년에 3회를 무료로 제공하고 있으므로 이를 활용하여 검토를 수행하고 조치할 수 있습니다.

  • Q13 공개SW 프로젝트의 보안 취약점은 어떻게 검사할 수 있나요?

    대부분의 공개SW 연구개발과제는 직접 개발하는 소프트웨어 소스 코드와 함께 외부의 공개SW를 활용하여 개발하게 되는 경우가 많습니다. 이처럼 직접 개발한 소스 코드가 아닌 외부에서 가져온 공개SW 프로젝트에 대한 보안 취약점도 함께 검사하고 발견된 취약점에 대하여 수시로 패치가 수정되어야 안전한 결과물을 공개할 수 있습니다.

    기존의 소프트웨어 보안 취약점 점검은 제품 출시 전 1회 검사 후 소프트웨어를 배포하는 것이 일반적이나 이런 방식은 외부에서 획득한 공개SW 프로젝트의 취약점이 발견되는 경우에 빠른 조치가 어렵습니다. 따라서 소프트웨어의 지속적 릴리즈를 관리할 수 있는 도구와 보안 취약점 검사를 연동하여 항시 외부 라이브러리의 보안 취약점을 검사하는 과정을 수행하도록 구축하는 것이 필요하며, 깃허브의 Security 메뉴를 이용하면 소스 코드 정적검사와 보안 취약점 데이터베이스를 통한 보안 검사를 쉽게 수행할 수 있습니다.

  • Q14 공개SW 연구개발과제는 커뮤니티 구축이 필수인가요?

    공개SW 개발방식의 장점을 활용하기 위해서는 다수의 외부 참여자가 활동할 수 있도록 커뮤니티를 잘 구축하고 운영하는 것이 중요합니다. 하지만 공개SW 연구개발 과제의 수행 기간이 짧은 경우에는 과제의 결과물을 연구개발하는 것과 동시에 커뮤니티를 구축하고 운영하기 쉽지 않습니다.

    수행 기간이 짧은 과제의 경우는 커뮤니티를 구축하고 운영하지 못하더라도 본 가이드에서 제시한 연구과제 결과물의 공개를 우선 수행하고, 과제 수행 기간 종료 후 커뮤니티의 구축 및 활성화를 추가로 계획하는 것도 좋은 방법입니다.

  • Q15 커뮤니티를 구축하기 어려운 경우는 어떻게 수행해야 하나요?

    모든 공개SW 연구개발 과제가 커뮤니티를 신규로 구축하고 운영해야 하는 것은 아닙니다. 신규 커뮤니티의 구축보다 좋은 방식은 기존의 커뮤니티에 참여하여 연구개발 결과물을 기존 커뮤니티에서 공유하고 참여하면서 함께 성장하는 것입니다.

    하지만 적절한 분야의 기존 커뮤니티가 없으나 커뮤니티를 활용하고자 하는 경우 신규 커뮤니티를 구축하고 운영을 전담할 수 있는 담당자 및 적절한 예산과 자원을 배정해야 합니다.

    만약 커뮤니티 구축이 어려운 경우에는 국내에서 공개SW 커뮤니티 운영을 지원할 수 있는 한국공개소프트웨어 협회 또는 오픈소스 소프트웨어재단과 같은 단체와 함께 운영하는 것도 좋은 방법입니다.

  • Q16 커뮤니티를 구축하려고 하지만 과제 예산으로 수행이 어려운 경우 지원을 요청할 방법은 없나요?

    과제 수행기관 자체적으로 커뮤니티 구축에 필요한 환경이 부족한 경우에는, 정보통신산업진흥원(NIPA)에서 운영하는 오픈소스 소프트웨어 통합지원센터의 공개SW 커뮤니티 지원사업을 통해서 신청(https://www.oss.kr/community_support)하여 커뮤니티 운영에 필요한 온·오프라인 모임 장소 및 전용 장비 활용 등 커뮤니티 운영에 필요한 지원을 받을 수 있습니다.

    문의처 : 2021 공개SW 커뮤니티 지원 운영사무국, 02-561-0552, comm@oss.kr

  • Q17 공개SW 연구개발과제를 공개하고 후원을 받을 수 있도록 구성해도 되나요?

    이미 많은 공개SW 프로젝트가 지속해서 유지되기 위해서 후원자들이 쉽게 후원할 수 있도록 만들어진 Open Collective, Tidelift, Ko-fi, Patreon 등 다양한 크라우드펀딩(crowdfunding)19 방식의 서비스를 이용하고 있습니다.

    공개한 프로젝트가 지속해서 유지되기 위해서 예산을 확보하는 것은 필수적인 일이며, 리눅스민트 같은 프로젝트는 기업이나 개인이 쉽게 후원에 참여할 수 있도록 구성하고 후원자들의 내역과 후원금을 다음 이미지와 같이 커뮤니티에 투명하게 공개하며 운영하고 있습니다.

그림 27. 리눅스민트(linuxmint) 프로젝트의 후원금 공개 페이지



18) 공개SW 활성화를 위한 공개SW 연구개발 생태계 연구(소프트웨어정책연구소, 2021) return
19) 크라우드펀딩은 소셜 네트워크 서비스를 이용해 소규모 후원을 받거나 투자 등의 목적으로 인터넷과 같은 플랫폼을 통해 다수의 개인들로부터 자금을 모으는 행위이다. return