(1) 채용에 어필하는 방법
오픈소스 프로젝트를 통해 기여(컨트리뷰트)까지 마쳤는데
“이걸 채용시장에서 어떻게 어필 할 수 있을까 ?”
- 협업&커뮤니케이션 능력
- 오픈소스에 컨트리뷰트한다는 것은 “코드로 대화를 한다는 것”
- 개발자가 가져야할 커뮤니케이션은 “코드로 대화”
- 불특정 다수와 소통할 수 있는 능력
- 프로젝트 문해력 : 기획, 설계, 구현 ~ 테스트, … 유지보수, 리팩토링, 운영
- 코드 분석 능력 : 언어의 특징, 인사이트 ⇒ 코드 구현 능력!
- 개발 문화 속에서 성장 경험을 가져봤다!
- 꾸준한 노력/개선 (?) ft.블로그
- 개발자 한정 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) 오픈 소스 사용 체크리스트 (특히 회사에서)
금융권 회사에서는 …
금융감독원, 금융보안원 등에서 시큐어 코딩이라고 엄청 까다롭게 점검한다.
또한 오픈소스 활용/관리 안내서까지 있다고 한다.
[개발 전]
- 오픈 소스에 대한 사정 기능 및 보안성 테스트
- 기능에 문제가 없는지
- 보안성에 문제가 없는지
- 이슈 현황을 파악하고
- 오픈 소스에 취약점이 있는지 확인
- 기관에 연락해 검토를 요청한다.
- 라이선스 검토하기
- 해당 오픈소스 라이선스를 사용함으로써 지켜야 하는 규정, 준수사항 검토
- 혹시 잘못되었을때 위약금, 법적 문제를 확인해야한다.
- 사내 법무팀에 자문을 구한다.
[개발 중]
- 만약 개발중에 취약점을 발견했다면…..
- 취약점을 최소화한다 with 보안 정책팀
- 대체 수단 확보 : 예외, 법적 이슈 발생 ⇒ 대비책 마련
- 자체 대응 및 추가 개발 역량 확보 : 충분한 이해, 기술력 ⇒ 문제 해결 능력 갖춤
[개발 후]
(금융권은 모든 기관들이 연결되어 있다. 시스템이 변경되면 모든 기관들이 변경되게끔 되어 있다.)
(즉 시스템은 가능한 자주 변경되지 않도록 설계되어 오랫동안 사용하게 된다)
그래서 개발 후 필요한 것은
- 모니터링 : 오픈 소스 현황, 취약점 업데이트
- 오픈소스 보안패치 : 확인, 취약점 최소화, 적용
- 오픈소스 종속성 검사 : 문제 발생, 최대한 빠른 해결
- 기능 및 보안성 테스트 : 테스트 부서, 보안 팀, … 협업