금융권 개발망에서 프로젝트를 준비하다 보면 코드보다 먼저 개발 환경을 살펴보게 됩니다.

필요한 라이브러리를 바로 설치할 수 없고, 공식 문서나 예제를 확인할 수 있는 도메인도 제한됩니다. 오픈소스 하나를 추가하려면 반입 절차와 취약점, 라이선스까지 함께 확인해야 합니다.

처음에는 이런 절차를 개발을 늦추는 제약으로만 바라본 적도 있습니다. 하지만 고객 정보와 거래 시스템을 다루는 환경에서 보안 기준은 가볍게 볼 수 없는 조건입니다.

그렇다고 개발 생산성을 포기할 수도 없었습니다.

오픈소스 하나가 의존성 하나로 끝나지 않았습니다

개발자가 직접 선택한 라이브러리는 하나여도 실제 프로젝트에는 여러 하위 의존성이 함께 들어옵니다.

직접 사용하는 패키지의 라이선스가 문제없어 보여도 하위 라이브러리에 다른 라이선스나 알려진 취약점이 포함될 수 있습니다. 버전이 조금 달라지면 개발자 PC에서는 되지만 빌드 서버에서는 실패하는 문제도 생깁니다.

그래서 오픈소스 반입은 파일을 외부에서 내부로 옮기는 작업이 아니라 변경관리의 일부에 가까웠습니다.

  • 어떤 기능을 위해 사용하는지
  • 직접·하위 의존성에 어떤 라이선스가 있는지
  • 알려진 취약점과 대체 버전은 무엇인지
  • 내부 저장소에 어떤 버전으로 등록할지
  • 문제가 생겼을 때 누가 변경 이력을 확인할지

이 기준이 있어야 같은 검토를 매번 처음부터 반복하지 않을 수 있었습니다.

Nexus는 패키지 저장소 이상의 역할을 했습니다

폐쇄망에서는 Maven Central이나 npm Registry에 직접 접근할 수 없습니다. 필요한 패키지는 검토와 반입 절차를 거쳐 내부 Nexus Repository에 등록해야 합니다.

Nexus를 기준으로 의존성을 관리하면 개발자 PC와 빌드 서버가 같은 패키지를 사용하게 됩니다. 승인된 버전을 팀 전체가 재사용할 수 있고, 외부망 연결 없이도 동일한 조건으로 빌드할 수 있습니다.

하지만 저장소만 만든다고 기준이 완성되는 것은 아니었습니다.

새 버전을 누가 요청하고 검토할지, 취약점이 발견되면 어떤 버전으로 교체할지, 사용하지 않는 패키지는 어떻게 정리할지까지 운영 절차가 필요했습니다. 기술 인프라와 관리 기준이 함께 있어야 내부 저장소가 실제 생산성으로 이어졌습니다.

모든 산출물을 같은 방식으로 볼 필요가 있을까

프로젝트를 진행하면서 산출물의 성격과 위험도를 구분할 필요도 느꼈습니다.

고객 정보, 인증, 거래, 원장 연동과 관련된 코드는 통제된 개발망에서 엄격하게 다뤄야 합니다. 반면 비즈니스 로직이 없는 UI 컴포넌트, 디자인 토큰, Storybook 문서처럼 상대적으로 위험도가 낮은 산출물은 승인된 범위에서 다른 개발 방식을 검토할 수 있습니다.

이 구분이 보안 기준을 낮추자는 뜻은 아닙니다. 무엇을 보호해야 하는지 더 명확히 하고, 위험도가 낮은 영역에는 안전하게 생산성을 높일 수 있는 절차를 만드는 쪽에 가깝습니다.

차단과 허용 사이에 기준이 필요했습니다

금융권 개발환경을 일반 인터넷 환경과 똑같이 만들 수는 없습니다. 그러나 필요한 도구를 일괄적으로 차단하는 것만으로는 변화하는 개발 방식을 따라가기 어렵습니다.

어떤 오픈소스를 어떤 절차로 사용할 수 있는지, 낮은 위험도의 산출물에는 어떤 개발 방식을 허용할 수 있는지, 검토 결과와 변경 이력을 어디에 남길지를 함께 정해야 합니다.

보안과 생산성은 서로 반대편에 놓인 목표라기보다 함께 운영해야 하는 조건이라고 생각합니다. 개발자가 더 안전하게, 그리고 더 잘 일할 수 있도록 만드는 구체적인 기준이 그 사이를 연결합니다.