2024년 11월 29일

✏️ 오픈 소스 컨트리뷰트 하면?

• 협업 능력 : 코드 대화(소통) 가능, 이슈 ~ 토론

• 프로젝트 문해력 : 기획, 설계, 구현 ~ 테스트, … 유지보수, 리팩토링, 운영… 등 체크

• 코드 분석 : 언어의 특징, 인사이트 ⇒ 코드 구현 능력

• 개발 문화 속에서 상장 경험

• 꾸준한 노력 / 개선 cf.블로그

• 개발자 한정 X (문서, 주석, 설계, 테스트, … 기능 제안) ⇒ 다양한 직군 어필! ex) IT 서비스 기획, QA

• 팀스테이지(Teamstage) 70% 실패

  • 기술 오류, 휴먼 에러, 전반적 프로세스, 실현 불가능, 사용자들과 접점 낮음 등등 ⇒ 슈퍼 유저 시선

✏️ 저작자가 되면 좋은 이유

• 사용 중인 오픈 소스 프로젝트에 코드를 구현해서 컨트리뷰트 PR : 기능 수정, 추가 욕심

  만약 우선 순위에 따라서 반려 당하면?

  • 오픈 소스 포크 → 단독으로 프로젝트 운영하려고 포크해서 별도의 프로젝트로 내가 운영 → 이런식으로 저작자가 주로 됨 (대신 원래 기존의 오픈 소스 프로젝트 라이선스 지켜줘야함 & 라이선스에 맞게 오픈하고 적용해야함)

• 프로젝트 성장 도모 → 함께 공유, 함께 개선, 아이디어 추가

✏️ 저작자가 되는 방법

• 오픈 소스 프로젝트가 되는 코드가 따로 있다? → X
  • 아무 프로젝트 라이선스 달면 오픈 소스 (ex. MIT)
  • ReadMe
  • Contributing
  • 프로젝트 이름
• 화려한 프로젝트 vs 기본이 탄탄한 프로젝트
  • 기본이 탄탄한 프로젝트가 훨씬 나음

✏️ 저작자 체크 리스트

• Readme
  • 프로젝트 만든 이유, 목적, 사용 용도 추천
  • 코드 사용 방법 / 설치 사용 방법
• Contributing
  • 환영 메시지
  • 가이드 (다른 프로젝트 참고)
• LICENSE
  • 라이선스 전문
• 상표권 침해를 피하기 위해 가능한 중복이 아닌, 기능이 명확한 프로젝트 이름(ex.is-null-or-not)
• 코드
  • 이해하기 쉬운 코드(명명법, 주석 설명 깔끔, 데드 코드 정리, 민감 정보 제외)
• 만약 회사 프로젝트라면 사내 법무팀에 자문 요청

✏️ 오픈 소스 사용 체크리스트

• (특히 회사에서) 오픈 소스 사용할 때, 체크리스트
  • 금융권 : 시큐어 코딩, 오픈 소스 활용/관리 안내서 by 금융감독원, 금융보안원
• 개발 전
  • 오픈 소스에 대한 사전 기능 및 보안성 테스트 : 기능, 보안성, 이슈 현황 파악
    • 취약점 확인, 기관 연락 검토 요청 → 신뢰성 검증
  • 라이선스 검토 : 랄이선스를 사용함으로써 지켜야 하는 규정, 준수 검토
    • 위약금, 법적 문제 → 사내 법무팀 자문
• 개발 중
  • 취약점 최소화 : 보안 정책팀 협업 ⇒ 인증, 주요 기능 보안 강화
  • 대체 수단 확보 : 예외, 법적 이슈 발생 ⇒ 대비책 마련
  • 자체 대응 및 추가 개발 역량 확보
• 개발 후
  • 모니터링 : 오픈 소스 현황, 취약점 업데이트
  • 오픈소스 보안패치 : 확인, 취약점 최소화, 적용
  • 오픈소스 종속성 검사 : 문제 발생, 최대한 빠른 해결
  • 기능 및 보안성 주기적으로 테스트 : 테스트 부서 요청, 보안팀 요청 등 협업을 통해 꾸준히 지속적으로 테스트, 분석해야함