저작자 체크리스트
상표권 침해를 피하기 위해 프로젝트 이름은 중복되지 않아야 한다. 또한, 프로젝트 이름은 기능이 명확하게 나타나도록 지어야 한다.
회사 프로젝트라면 사내 법무팀이나 오픈 소스 담당 팀에게 자문을 구하는 것이 좋다. 혼자 프로젝트 전체를 책임지기는 힘들기 때문에 담당자를 추가하고, 해당 프로젝트를 사내에 먼저 오픈하고 나서 외부에 오픈하는 것이 좋다.
LISENCE
fork 한 프로젝트일 경우 해당 프로젝트의 라이선스 전문을 포함해야 한다.
README
이 프로젝트를 만든 이유와 목적, 사용 용도, 코드 사용 방법, 설치 방법 등에 대해 작성한다.
CONTRIBUTING
다른 프로젝트를 참고하여 가이드를 작성한다. 작성이 어렵다면 환영 메시지만 작성해도 된다.
코드
이해하기 쉬운 코드를 작성해야 하며, 사용하지 않는 코드는 정리하고, 주석 설명을 깔끔히 작성하고, 민감한 정보는 제거해야 한다.
금융권 오픈 소스
금융권에서는 돈이 오고 가기 때문에 보안 관련 코드 점검이 엄격하다. 금융권의 코드는 금융감독원과 금융보안원에게 감사를 받는다.
개발 전
- 오픈 소스에 대한 사전 기능 및 보안성 테스트
: 기능, 보안성, 이슈 현황을 파악한다.
: 취약점을 확인하고, 기관에 연락해 검토를 요청하여 신뢰성을 검증받는다. - 라이선스 검토
: 라이선스를 사용할 때 지켜야 하는 규정을 검토한다.
: 위약금과 법적 문제가 얽혀있으므로 사내 법무팀에 자문을 구한다.
개발 중
- 취약점 최소화
: 보안 정책팀과 협업하여 인증과 주요 기능의 보안을 강화한다. - 대체 수단 확보
: 예외나 법적 이슈가 발생할 수 있기 때문에 대비책을 마련해 둔다. - 자체 대응 및 추가 개발 역량 확보
개발 후
- 모니터링
: 오픈 소스 현황을 확인하고, 취약점을 업데이트한다. - 오픈 소스 보안 패치
: 보안 패치를 확인하고, 취약점을 최소화하여 적용한다. - 오픈 소스 종속성 검사
: 해당 오픈 소스의 종속성을 검사하여 문제가 발생했을 때 최대한 빠르게 해결해야 한다. - 기능 및 보안성 테스트
: 테스트 부서, 보안 팀 등의 협업을 통해서 지속적으로 테스트하고 분석한다.
배운 점
- 상표권 침해를 피하기 위해 프로젝트 이름은 중복되지 않아야 한다. 또한, 프로젝트 이름은 기능이 명확하게 나타나도록 지어야 한다.
- 회사 프로젝트라면 사내 법무팀이나 오픈 소스 담당 팀에게 자문을 구하는 것이 좋다.
- 회사 프로젝트일 경우 해당 프로젝트를 사내에 먼저 오픈하고 나서 외부에 오픈하는 것이 좋다
'데브코스' 카테고리의 다른 글
[14주차 - DAY4] 도서 정보 사이트 - 라우팅 (0) | 2024.05.30 |
---|---|
[14주차 - DAY3] 도서 정보 사이트 - 테마 스위치 (0) | 2024.05.29 |
[13주차 - DAY5] 오픈 소스(4) (0) | 2024.05.24 |
[13주차 - DAY4] 오픈 소스(3) (0) | 2024.05.23 |
[13주차 복습 발표] 싱글톤 패턴 (0) | 2024.05.22 |