오픈소스를 잘 사용하는 프론트엔드 개발자

개요

요즘 소프트웨어 개발에 있어서 오픈소스는 빠질 수 없는 필수 불가결한 존재가 됐습니다.

 

웹 프론트엔드 개발에 있어서 주로 사용하는 React도 오픈소스, 상태 관리를 위해 사용하는 Zustand, Jotai, Redux 라이브러리도 오픈소스, 심지어 배포를 위한 서버의 OS로 사용하는 Linux도 오픈소스 입니다.

 

최근에는 오픈소스 기여 경험이 취업의 스펙이 되는 등 오픈소스 생태계가 정말 활발해지고 있는데, 여러분들은 오픈소스를 어떻게 사용 중에 계신가요?

 

최근 프론트엔드 개발자라면 누구나 한번은 사용해봤을 라이브러리인 eslint-config-prettier 플러그인이 해킹되는 충격적인 사건이 발생했습니다. 또 프론트엔드의 인기 프레임워크인 Next.js에서 보안 취약점이 발견이 되는 등 오픈소스에서 많은 취약점이 발견되고 있는데요. 여러가지 사건 사고가 있어도 우리는 오픈소스를 절대 포기할 수 없습니다.

 

이번 글에서는 국내 오픈소스 생태계와 프론트엔드의 오픈소스 생태계에 대해서 살펴보고, 오픈소스를 도입하는 기준에 대해서 살펴보며 마지막으로 프로젝트에서 오픈소스 보안 취약점을 어떻게 다뤄볼 수 있을까 살펴보도록 하겠습니다.

 

국내의 유명한 오픈소스

국내의 유명한 오픈소스 생태계를 살펴보겠습니다.

 

es-toolkit

먼저 요즘 제일 핫한 국내 오픈소스는 es-toolkit이 아닐까 싶습니다. Toss에서 시작된 es-toolkit은 lodash를 대체하는 JavaScript 유틸리티 라이브러리 인데요, 패키지 매니저인 Yarn과 Storybook에서 es-toolkit을 도입하는 등 해외에서도 많은 반응을 얻고 있는 라이브러리 입니다.

 

TOAST-UI

NHN에서 시작된 TOAST-UI는 Chart, Editor, Grid 등 다양한 라이브러리로 인기를 얻은 오픈소스 입니다. 특히 TOAST-UI Editor은 에디터 라이브러리 중 레퍼런스도 많고 사용성이 좋아 많은 사랑을 받고 있는 라이브러리 입니다.

 

billboard.js

Naver에서 시작된 billboard.js 라이브러리는 D3 기반의 차트 라이브러리 입니다. npm을 살펴보면 25/10/1 기준 weekly download 횟수가 30k가 넘어가는 등 꾸준히 많은 사랑을 받고 있습니다.

 

 

대표적으로 세 개의 라이브러리를 살펴봤는데요, 국내의 오픈소스 생태계 역시 꾸준히 성장하며 많은 사랑을 받고 있는 것을 볼 수 있습니다.

 

프론트엔드, 뭐로 개발해?

만약 여러분이 프론트엔드 개발자라면, 뭐로 개발하시나요? React? Next? Vue? Angular? Svelte? 아니면 jQuery?

 

위에 나열한 그 어떤 것을 사용하던 여러분은 오픈소스를 사용해 프로젝트를 진행하고 있습니다.

 

그럼 React를 사용한다고 가정하고 다시 질문해볼까요. 상태 관리 라이브러리로 어떤 것을 사용하시나요? Zustand, Jotai, Redux, 서버 상태를 위해 tanstack/react-query, SWR.. 어떤 것을 선택하든 우리는 오픈소스 생태계에 푹 빠져있는 것을 확인할 수 있습니다.

 

요즘 프론트엔드에서 어떤 기능을 구현하려고 할 때 우리는 그 기능을 직접 구현하는 일은 드뭅니다. (물론 기존에 구현된 오픈소스가 마음에 안들어 직접 구현하는 케이스들도 더러 존재하지만요.)

 

기존에 구현된 라이브러리를 찾아보고, 라이브러리의 장단점을 비교해가며 실제 프로젝트에 도입하여 기능 구현을 진행합니다.

React 생태계가 이렇게 성장할 수 있었던 것도 오픈소스 생태계의 성장과 서드 파티 라이브러리를 선택함에 있어서 자유도가 있었기 때문이라고 생각하고요.

 

그럼 이렇게 자유롭게 선택할 수 있는 오픈소스 생태계에서 오픈소스를 도입하려 할 때 여러분들은 어떤 기준점을 가지고 도입하나요? 그럼 프로젝트에 오픈소스를 도입하려 할 때 왜 기준을 가지고 도입을 해야 할까요? 왜 아무 오픈소스나 막 도입하면 안될까요?

 

오픈소스 도입의 기준

프로젝트에 오픈소스를 도입하는데 있어서 많은 기준 점이 있습니다.

 

예를 들면 웹 프론트엔드에서 상태 관리 라이브러리를 도입하는 상황이라면 Zustand, Jotai를 선택할 수 있는데요, 프로젝트의 규모, 상태 관리 중 선호하는 방식 (Top-down or Bottom-up), 번들링 사이즈, 미들웨어를 지원하는 여부 등이 될 수 있습니다.

 

만약 여러분이 dnd(drag and drop) 기능을 개발하는 상황이고, 오픈소스 라이브러리를 도입하기로 결정했다고 가정합시다. dnd 기능을 지원하는 오픈소스 라이브러리는 많습니다. react-beautiful-dnd, dnd-kit, 혹은 drag로 resize를 해야하는 상황이라면 react-drag-sizing, re-resizable 등 여러 선택지가 존재합니다.

 

이 많은 선택지 중 하나의 오픈소스 라이브러리를 선택해야 한다면 어떤 기준으로 선택을 해야 할까요?

 

유지 보수

해당 오픈소스 라이브러리가 메인테이너에 의해 유지 보수가 되고 있는지에 대해 체크해봐야 합니다. 도입을 결정한 시점을 기준으로 몇 년 동안 라이브러리의 패치가 없었다면 해당 오픈소스는 EOL(End of Lifecycle)이 됐을 확률이 높습니다.

 

만약 해당 라이브러리를 프로젝트에 도입을 결정한다면, 기능을 구현한 뒤 해당 프로젝트를 유지보수 할 때 라이브러리에 문제가 생겼을 경우 도움을 받기 어려울 뿐더러, 메인 라이브러리의 버전이 올라갔을 때 대응이 없을 수 있습니다.

 

이런 이유로 라이브러리의 버전이 오랜 기간 동안 동일하게 머물고 있다면 과감하게 해당 라이브러리는 선택지에서 제외해야 합니다.

react-drag-sizing 라이브러리의 마지막 퍼블리싱은 3년 전 입니다.

 

대안인 re-resizable 라이브러리는 7달 전 퍼블리싱이 됐으며 React 19버전이 커버 됩니다.

 

라이브러리 호환성

메인 라이브러리와 호환성 여부를 체크해야 합니다.

유지 보수와 비슷한 맥락으로 해당 오픈소스 라이브러리가 프로젝트에서 사용하는 라이브러리의 버전을 지원하는지 확인이 필요합니다.

 

도입하고자 하는 오픈소스 라이브러리가 오래전에 퍼블리싱 됐다면 해당 라이브러리는 메인 라이브러리의 최신 버전을 지원하지 못할 가능성이 존재합니다.

 

취약점의 여부

해당 오픈소스 라이브러리에 취약점이 존재하는지 여부도 체크의 대상이 됩니다.

오픈소스 보안 취약점은 SBOM을 생성해 취약점을 점검할 수 있고, 프론트엔드 환경이라면 npm audit를 활용해 빠르게 취약점을 검출하고 취약점이 수정된 버전으로 업그레이드도 진행할 수 있습니다.

 

프로젝트에서 오픈소스 라이브러리의 쓰임새, 러닝 커브(학습 곡선), 인기도 등 다양한 요소가 오픈소스 도입의 기준이 될 수 있지만 반드시 체크해야 할 부분은 유지 보수, 호환성, 취약점 입니다.

 

오픈소스 보안 취약점

오픈소스 보안 취약점을 사례와 함께 살펴보도록 하겠습니다.

 

Log4j — 로그가 공격 통로가 된 사건

log4j 취약점 사태는 2021년 11월에 발생한 사건으로 취약점 심각도 10점 만점 중 10점을 받은 심각한 사태였습니다.

Log4j는 자바 진영에서 가장 많이 쓰이는 로그 라이브러리입니다. 문제는 로그 메시지를 처리하면서 특정 문자열을 동적으로 해석하는 기능이 들어있었다는 점입니다.

공격자는 이 기능을 악용해 단순히 로그에 특정한 문자열을 남겼을 뿐인데, 서버가 그 문자열을 코드 실행처럼 처리해버렸습니다. 결국 원격에서 마음대로 명령을 실행할 수 있는, 흔히 말하는 “원격 코드 실행” 취약점이 생긴겁니다.

 

이 사건(Log4Shell)은 전 세계적으로 큰 파장을 일으켰습니다. 수많은 서비스가 Log4j를 사용하고 있었고, 단순한 로그 한 줄이 시스템 전체를 뚫는 결과를 가져왔습니다. 편리함을 위해 넣은 기능 하나가 보안의 아킬레스건이 된 대표적인 사례입니다.

 

Next.js middleware 보안 취약점

Next.js 미들웨어 보안 취약점은 미들웨어 기능을 사용할 때 내부적으로 사용하는 특수한 헤더가 있었는데, 이 헤더를 외부에서 조작할 수 있는 여지가 남아 있었습니다.

결국 공격자가 이 헤더를 직접 넣어버리면, 원래라면 거쳐야 할 인증이나 권한 검증이 우회되는 상황이 벌어졌습니다. 즉, “프레임워크 내부용”이라고 생각했던 값이 실제로는 누구나 넣을 수 있었던 것입니다.

 

Next.js 버전 15.2.3 보안 취약점 해결 출시 | GeekNews

 

Linux xz-utils 사태

XZ Utils는 리눅스 환경에서 파일을 압축하거나 풀 때 흔히 사용하는 아주 기본적인 도구입니다. 2024년에 발견된 사건은 충격적이었는데, 프로젝트 메인테이너의 권한을 노려서 악성 코드가 포함된 버전이 공식 배포물로 올라왔습니다.

이 악성 버전은 평범한 것처럼 보였지만 실제로는 SSH 같은 중요한 통신을 가로채서 인증을 우회할 수 있는 백도어를 심어두고 있었습니다. 다시 말해, 리눅스 배포판을 설치했을 뿐인데 공격자가 원격에서 접속할 수 있는 뒷문이 열려 있는 상태가 될 수 있었던 겁니다.

이 사건은 단순한 취약점이 아니라 2021년부터 공격자로 인해 치밀하게 계획된 사건이었고 공급망 자체가 공격에 뚫린 경우였습니다. “공식 저장소에서 내려받으면 안전하다”는 믿음을 완전히 무너뜨렸고, 오픈소스 신뢰 체계에 큰 경종을 울렸습니다.

 

xz-utils 백도어 사건

 

eslint-config-prettier

비교적 최근인 25년 7월 18일에 프론트엔드 개발자라면 한번은 들어봤거나 사용했을 eslint-config-prettier 패키지가 피싱 공격으로 계정이 탈취되어 악성코드가 유포되는 공급망 공격(Supply Chain Attack)이 발생했습니다.

 

공격자는 가짜 NPM 사이트를 만들어 패키지 매니저의 계정을 탈취했고, 악성코드가 삽입된 버전을 배포하여 수많은 프로젝트 공격을 시도했습니다.

 

eslint-config-prettier 패키지는 주로 개발 환경에서만 쓰이기 때문에 “이 정도는 안전하겠지” 하고 넘어가기 쉽습니다.

하지만 현실은 달랐습니다. 개발 환경에서 설치되는 패키지라 해도 결국 빌드 서버나 CI/CD 환경을 거쳐 최종 산출물로 이어지기 때문에 공격자는 dev-dependency도 훌륭한 공격 통로로 삼을 수 있습니다.

 

이 사례는 “개발용 도구니까 괜찮다”는 안일한 생각이 얼마나 위험한지 보여줍니다. 실제 업무에서는 개발 도구까지 포함해 모든 오픈소스를 보안 점검 대상에 넣어야 한다는 교훈을 남겼습니다.

eslint-config-prettier NPM 패키지 해킹, 전 세계 개발자 7천 8백만명 피해

 

 

여러가지 사례를 통해 살펴듯이 우리가 사용하는 오픈소스도 주의해서 사용해야 하며 항상 보안 취약점에 관심을 가지고 있어야 함을 알 수 있습니다.

 

프론트엔드에서 오픈소스 보안 취약점 검증, 조치

프론트엔드에서 보안 취약점을 쉽게 탐지할 수 있는 방법이 있을까요?

또 보안 취약점이 발견된다면 어떻게 조치를 해야할까요?

 

npm audit

우리가 사용하는 패키지 매니저에는 audit이라는 훌륭한 기능이 있습니다.

해당 명령어는 프로젝트에서 사용되는 라이브러리의 취약점을 검사하고, 보안 문제를 해결할 수 있는 업데이트 정보를 제공하는 기능입니다.

취약점의 위험도에 따라 critical > high > moderate > low 로 취약점을 제공합니다.

 

npm에 새로 추가된 audit 기능 :: Outsider's Dev Story

 

 

--fix

아래 내용은 pnpm을 기준으로 기술합니다.

 

--fix 플래그를 추가하면, pnpm은 다음 작업을 자동으로 수행하여 발견된 취약점을 수정하려 합니다.

1. 취약점 분석: 취약점이 발견된 패키지와 해당 취약점을 해결할 수 있는 안전한 버전을 식별합니다.
2. 버전 업데이트: 안전한 버전으로 업데이트하기 위해 pnpm-lock.yaml 파일을 수정하고, 해당 패키지의 의존성 트리를 변경합니다.
3. 패키지 설치: 변경된 잠금 파일을 기반으로 새로운 패키지를 설치하여 취약점이 해결된 버전이 프로젝트에 실제로 적용되도록 합니다.

 

--fix의 주요 역할: 버전 업그레이드

--fix의 주요 목적은 호환성을 깨지 않는 선에서 취약점이 있는 패키지를 보안 패치가 적용된 가장 낮은 버전으로 업그레이드하는 것입니다.

• 자동 마이너/패치 업데이트: 대부분의 취약점은 해당 패키지의 마이너 버전(Minor) 또는 패치 버전(Patch) 업데이트만으로 해결됩니다. --fix는 이러한 업데이트를 자동으로 수행하며, 일반적으로는 프로젝트의 기존 기능에 영향을 미치지 않습니다.
• 주요 버전(Major) 업데이트는 수행하지 않습니다. 주요 버전 업데이트는 호환성이 깨질 수 있는 변경사항(Breaking Changes)을 포함할 수 있으므로, --fix는 개발자의 명시적인 승인 없이 이를 자동으로 처리하지 않습니다.

 

주의사항

pnpm audit --fix는 취약점 수정에 매우 유용하지만, 다음과 같은 이유로 자동 수정 후 반드시 테스트가 필요합니다.

• 잠재적 호환성 문제: 패치가 마이너 버전 내에서 이루어졌다고 하더라도, 드물게 다른 의존성이나 프로젝트 코드와 예기치 않은 충돌을 일으킬 수 있습니다.
• 완벽한 해결 불가: 만약 취약점을 해결하기 위해 주요 버전(Major) 업그레이드가 필요하거나, 취약한 패키지가 프로젝트의 루트 package.json에 명시된 범위("~1.0.0", "^1.0.0")를 벗어나는 경우, --fix만으로는 해결되지 않을 수 있습니다. 이때는 개발자가 수동으로 package.json 파일을 수정하거나 pnpm의 resolutions 기능을 사용하여 버전을 명시적으로 지정해야 합니다.

 

Github Actions를 활용한 CI

pnpm audit를 활용해 CI 파이프라인에서 취약점을 점검해봅시다.

아래 작성된 CI 파이프라인은 high 이상의 취약점이 발견된 경우 CI를 중단합니다.

name: CI

on: [push, pull_request]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v2
        with:
          version: 9
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
      - name: Run pnpm audit
        run: pnpm audit --audit-level=high

 

--audit-level 플러그인을 사용해 high 이상의 취약점이 검출될 시 파이프라인을 종료합니다.

 

마치며

우리는 이번 글을 통해 오픈소스가 현대 소프트웨어 개발의 핵심 동력이자 동시에 가장 큰 보안 취약점의 통로가 될 수 있음을 여러 사례를 통해 확인했습니다.

 

Log4j 사태는 편의성 이면에 숨겨진 기능의 위험성을, XZ Utils 사태는 개발 생태계 전체를 겨냥한 치밀한 공급망 공격의 현실을 보여주었습니다. 특히 프론트엔드 개발자에게 경고를 던진 Next.js의 내부 헤더 우회 취약점과 eslint-config-prettier의 개발 도구 해킹 사건은 '개발용이니까 안전하겠지'라는 안일한 인식이 얼마나 위험한지 분명히 깨닫게 해주었습니다.

 

이러한 사건 사고에도 불구하고 우리는 오픈소스를 포기할 수 없습니다. 핵심은 맹목적인 신뢰 대신 신중한 관리로 나아가야 한다는 것입니다.

 

프로젝트에 오픈소스를 도입할 때는 단순히 기능 구현 여부뿐만 아니라 유지 보수 상태, 호환성, 그리고 취약점 여부를 핵심 기준으로 삼아야 합니다. 나아가, npm audit 같은 패키지 매니저의 기본 기능을 활용하고, CI/CD 파이프라인에 pnpm audit --audit-level=high 와 같은 자동 검증 단계를 의무화해야 합니다.

 

오픈소스는 자유와 성장의 토대이지만, 그 자유에는 책임이 따릅니다. 모든 의존성은 잠재적인 위험 요소라는 인식을 가지고, 시스템적인 검증과 지속적인 관심을 기울일 때, 비로소 우리는 오픈소스의 무한한 가능성을 안전하게 누릴 수 있을 것입니다.

 

읽어봐주셔서 감사합니다.

 

참고하면 좋은 블로그

SBOM에 관해 잘 정리되어 있는 블로그 글 입니다. SBOM이 무엇인지, 프로젝트 내 오픈소스 보안 취약점을 검출하는 방법을 상세하게 기술해놓은 글 입니다.

 

우리가 쓰는 오픈소스, 안전할까?(쓰봄sbom...)