오픈소스)Maintainer해보기 & 장점 & 체크리스트

Songss·2025년 2월 20일
0

개발지식

목록 보기
9/16

(1) 채용에 어필하는 방법

오픈소스 프로젝트를 통해 기여(컨트리뷰트)까지 마쳤는데

“이걸 채용시장에서 어떻게 어필 할 수 있을까 ?”

  1. 협업&커뮤니케이션 능력
    1. 오픈소스에 컨트리뷰트한다는 것은 “코드로 대화를 한다는 것”
    2. 개발자가 가져야할 커뮤니케이션은 “코드로 대화”
      1. 불특정 다수와 소통할 수 있는 능력
  2. 프로젝트 문해력 : 기획, 설계, 구현 ~ 테스트, … 유지보수, 리팩토링, 운영
  3. 코드 분석 능력 : 언어의 특징, 인사이트 ⇒ 코드 구현 능력!
  4. 개발 문화 속에서 성장 경험을 가져봤다!
  5. 꾸준한 노력/개선 (?) ft.블로그
  6. 개발자 한정 X (문서, 주석, 설계, 테스트, … 기능 제안) ⇒ 다양한 직군 어필 ! ex. IT서비스 기획, QA

“프로젝트 관리 전문성이 부족한 이유가 매우 크다고한다.”

팀스테이지(Teamstage) 왈 : 70%가 실패한다. (ft. 성공 기준 모호)

기술 오류, 휴먼 에러, 전반적 프로세스 오류, 실현 불가능, 사용자들과 접점 낮음

(2) 저작가

(2-1) 저작자가 되면 좋은 이유

  • 사용중인 오픈 소스 프로젝트에 코드를 구현해서 컨트리뷰트 PR : 기능 수정, 추가 욕심
    • 내가 궁금하고 욕심나는 코드는 누구든 궁금하고 욕심낼 수 있다.
    • 만약 반려 당한다면 ?
      • 해당 오픈소스 프로젝트를 Fork 해 온다. 그리고 ! 내가 직접 운영한다.
      • 단, 기존 프로젝트 라이선스를 신경써줘야한다.

(2-2) 저작자가 되는 방법

cf. 화려한 프로젝트 vs 기본이 탄탄한 프로젝트

→ 기본이 탄탄한 프로젝트 👍Win

그렇다면 …

오픈소스 프로젝트가 되는 코드가 따로 있다 ?

→ X , 아닙니다. 당사자가 라이센스를 달아두면 오픈소스 프로젝트가 되는 것

아무 프로젝트에 라이선스 달면 오픈 소스가 된다. (ex. MIT)

(2-3) 저작자가 체크 리스트

그럼에도 불구하고 “최소한”이라는게 존재하지않을까 ?

그래서 “최소한” Maintainer라면 지켜야할 체크 리스트를 챙겨보자

단, 최소 README, Contributing 은 작성하자.

  • README
    • 프로젝트 만든 이유, 목적, 사용 용도 추천
    • 코드 사용 방법 / 설치 사용 방법
  • Contributing
    • 환영 메세지 / 가이드 (다른 프로젝트 참고)
  • LICENSE
    • 라이선스 전문
  • 프로젝트 이름
    • 상표권 침해하지 않고
    • 중복되지 않고
    • 기능이 명확한(?)
  • 코드
    • 이해하기 쉬운 코드(*명명법)
    • 주석 설명은 깔끔하게
    • 필요 없는, 데드 코드 정리
    • 민감 정보는 제외 !

(3) 오픈 소스 사용 체크리스트 (특히 회사에서)

금융권 회사에서는 …

금융감독원, 금융보안원 등에서 시큐어 코딩이라고 엄청 까다롭게 점검한다.

또한 오픈소스 활용/관리 안내서까지 있다고 한다.

[개발 전]

  1. 오픈 소스에 대한 사정 기능 및 보안성 테스트
    1. 기능에 문제가 없는지
    2. 보안성에 문제가 없는지
    3. 이슈 현황을 파악하고
    4. 오픈 소스에 취약점이 있는지 확인
    5. 기관에 연락해 검토를 요청한다.
  2. 라이선스 검토하기
    1. 해당 오픈소스 라이선스를 사용함으로써 지켜야 하는 규정, 준수사항 검토
    2. 혹시 잘못되었을때 위약금, 법적 문제를 확인해야한다.
      1. 사내 법무팀에 자문을 구한다.

[개발 중]

  1. 만약 개발중에 취약점을 발견했다면…..
    1. 취약점을 최소화한다 with 보안 정책팀
  2. 대체 수단 확보 : 예외, 법적 이슈 발생 ⇒ 대비책 마련
  3. 자체 대응 및 추가 개발 역량 확보 : 충분한 이해, 기술력 ⇒ 문제 해결 능력 갖춤

[개발 후]

(금융권은 모든 기관들이 연결되어 있다. 시스템이 변경되면 모든 기관들이 변경되게끔 되어 있다.)

(즉 시스템은 가능한 자주 변경되지 않도록 설계되어 오랫동안 사용하게 된다)

그래서 개발 후 필요한 것은

  1. 모니터링 : 오픈 소스 현황, 취약점 업데이트
  2. 오픈소스 보안패치 : 확인, 취약점 최소화, 적용
  3. 오픈소스 종속성 검사 : 문제 발생, 최대한 빠른 해결
  4. 기능 및 보안성 테스트 : 테스트 부서, 보안 팀, … 협업

0개의 댓글