🎯 오픈 소스 저작자가 되는 방법, 오픈 소스 사용 체크리스트에 대해 정리합니다.

📗 Today I Learned

오픈 소스 저작자 👩‍💻 되기

오픈 소스는 단순히 코드를 공개하는 것을 넘어서, 함께 성장하고 공유하는 문화입니다. 그 중심에 있는 사람이 바로 저작자입니다.

저작자가 되면 좋은 이유

• 사용 중인 오픈 소스 프로젝트에 직접 기여합니다.
  기능 추가나 수정 하고 싶은 부분을 직접 구현해 PR을 보낼 수 있습니다.

• 기여가 반려돼도 기회가 있다.
  만약 우선순위 문제로 PR이 받아들여지지 않더라도, 해당 프로젝트를 fork해서 나만의 버전으로 독립 운영할 수 있습니다. (기존 프로젝트 라이선스 준수)

• 프로젝트를 직접 키워나갈 수 있다.
  더 많은 사용자를 만나고, 함께 쓰고 개선하며 다양한 아이디어를 실현할 수 있습니다.

---

저작자 체크리스트 ✅

README

• 왜 만들었는지 (배경/목적)

• 어떤 용도로 쓰면 좋은지 (추천 사용 예시)

• 설치 / 실행 방법

CONTRIBUTING

• 누구나 기여를 환영한다는 메시지

• PR 가이드라인, 브랜치 네이밍 규칙 등

LICENSE

• 프로젝트의 라이선스 전문 명시 (MIT, Apache, GPL 등)

프로젝트 명

• 상표권을 피하고, 중복이 적고 기능이 명확하게 드러나는 이름

코드

• 변수 및 함수명은 명확하게

• 주석은 핵심 위주로 간결하게

• 데드코드, 민감정보 (API KEY 등)는 반드시 제거

🏢 회사 프로젝트라면?

• 외부에 바로 공개 금지, 사내 공개 → 사내 오픈소스 담당자 또는 법무팀 자문 후 오픈
• 필요 시, 사내 오픈소스 운영 지침/담당자와 협의

---

회사에서 오픈 소스 활용할 때 주의사항

특히 금융권이나 보안 민감한 환경에서는 더 엄격한 검토가 필요합니다.
아래는 금융감독원, 금융보안원 등의 가이드라인을 참고해 정리한 항목입니다.

[개발 전]

1. 기능 및 보안성 테스트

• 주요 기능 정상 동작 여부

• 보안 취약점 유무

• 해당 프로젝트 이슈 현황 검토

• 필요 시 해당 기관에 연락 검토

2. 라이선스 확인

• 어떤 규정을 따라야 하는지

• 위반 시 법적 문제 소지 여부

• 사내 법무팀 자문 필수

[개발 중]

1. 취약점 최소화

• 보안정책팀과 협업

• 인증 로직, 주요 기능 보안 강화

2. 대체 수단 고려

• 예외 발생 시 대응 방안 마련

3. 내부 대응 역량 확보

• 충분히 이해하고 직접 대응 가능한 기술력 확보

[개발 후]

1. 지속적인 모니터링

• 오픈소스 버전, 취약점 이슈 지속 확인

2. 보안 패치

• 취약점 확인 시 신속히 패치 적용

3. 종속성 검사

• 라이브러리들의 목록을 추출해서, 각각에 대해 보안 취약점, 의존 구조 , 버전 관리 등을 검사

4. 기능/보안성 재테스트

• 보안팀, QA팀과 함께 지속적인 테스트

---

✏️ 회고

오픈 소스가 처음엔 공유를 위해 만들어졌지만, 갈수록 더 많은 대비와 책임이 필요하다는 것을 느꼈다.