dev-oil의 개발 블로그

URL 파라미터 정리하기: JavaScript와 React에서

dev-oil — Tue, 30 Dec 2025 22:08:31 +0900

오늘은 URL 파라미터를 정리해보려고 합니다.

URL 파라미터에 대해 간략한 설명과 JS에서 운영하는법, react에서 react-router의 hook들을 사용한 방법들을 소개해보려고합니다.

바쁘신 분들은 맨 밑으로 내려가셔서 5. 읏차차 최종정리 (요약) 섹션만 확인해주세요!

1. URL 파라미터의 종류

URL에는 두 가지 파라미터가 있습니다.

https://example.com/product/123?category=react&page=1
                      ↑         ↑
                 경로 파라미터  쿼리 파라미터

경로 파라미터 (Path Parameter)

URL 경로의 일부: /product/123, /user/kim
필수 값, URL 구조의 핵심입니다.
용도: 특정 리소스 식별 (상품 ID, 사용자 ID)

쿼리 파라미터 (Query Parameter)

? 뒤에 key=value 형태: ?page=1&sort=latest
선택 값, 필터링/정렬/페이지네이션에 주로 사용됩니다.
용도: 검색, 필터, 정렬 조건

언제 무엇을 쓸까요?

파라미터	예시	사용 시점
경로	/product/123	특정 상품 상세 페이지
쿼리	/products?category=react	상품 목록 필터링
둘 다	/product/123?tab=review	상품 상세의 리뷰 탭

2. Vanilla JavaScript로 파라미터 조작하기

자 그럼 이제 파라미터를 읽어보고 만져볼까요?

먼저 기본 자바스크립트에서 파라미터 조작하는 방법을 알아보겠습니다.

경로 파라미터 읽기

window.location.pathname을 사용하여 경로 파라미터를 확인할 수 있습니다.

// URL: https://example.com/product/123

// 경로 전체
console.log(window.location.pathname); // "/product/123"

// 특정 부분 추출
const id = window.location.pathname.split('/')[2]; // "123"

쿼리 파라미터 읽기/쓰기

URLSearchParams를 이용해 쿼리 파라미터를 관리할 수 있습니다.

// URL: https://example.com/products?page=1&category=react

// 1. 읽기
const params = new URLSearchParams(window.location.search);
console.log(params.get('page')); // "1"
console.log(params.get('category')); // "react"

// 2. 추가/수정
params.set('page', '2');
params.set('sort', 'latest');

// 3. 삭제
params.delete('category');

// 4. URL 업데이트 (새로고침 없이)
const newUrl = `${window.location.pathname}?${params.toString()}`;
window.history.pushState({}, '', newUrl);

// 결과: https://example.com/products?page=2&sort=latest

주의사항 :

pushState (히스토리 추가)

뒤로가기 스택에 쌓입니다.
이동한 모든 페이지로 뒤로가기가 가능합니다.

replaceState (히스토리 교체)
- 뒤로가기 시 replaceState 사용 이전 페이지로 이동합니다. (히스토리가 교체됩니다)
- 교체된 URL들은 히스토리에서 사라집니다.
새로고침 없이 URL만 변경되므로 상태 업데이트는 수동 처리가 필요합니다.

3. React에서 파라미터 조작하기

이번엔 리액트에서 파라미터와 관련된 훅들을 살펴보겠습니다.

주로 react router에서 제공하는 hook들을 사용해서 편하게 구현합니다.

물론 React Router 없이 useEffect와 window.location으로 직접 구현할 수도 있겠지만, 우리는 시간이 없습니다.

빨리 잘만들어진거 써서 일해야죠!

3-1. useParams - 경로 파라미터 읽기

단순히 경로 파라미터의 값을 가져와야 할 때 사용합니다.

import { useParams } from 'react-router-dom';

// 라우트 설정
<Route path="/product/:id" element={<ProductDetail />} />
<Route path="/user/:userId/post/:postId" element={<Post />} />

// 컴포넌트
export const ProductDetail = () => {
  const { id } = useParams();
  
  console.log(id); // URL이 /product/123이면 "123"
  
  return <div>상품 ID: {id}</div>;
}

export const Post = () => {
  const { userId, postId } = useParams();
  
  return (
    <div>
      사용자: {userId}, 게시글: {postId}
    </div>
  );
}

주의사항 :

경로 파라미터 전용, 쿼리 파라미터(?key=value)는 읽을 수 없습니다.
라우트 설정에서 :파라미터명 으로 정의가 필요합니다.

3-2. useSearchParams - 쿼리 파라미터 읽기/쓰기

쿼리 파라미터를 읽고 쓸 때 사용합니다.

import { useSearchParams } from 'react-router-dom';

export const ProductList = () => {
  const [searchParams, setSearchParams] = useSearchParams();
  
  // 읽기
  const page = searchParams.get('page') || '1';
  const category = searchParams.get('category') || 'all';
  const sort = searchParams.get('sort');
  
  // 쓰기 - 방법 1: 객체로 전달 (기존 파라미터 모두 교체)
  const handlePageChange = (newPage) => {
    setSearchParams({ page: newPage, category });
  };
  
  // 쓰기 - 방법 2: 함수형 업데이트 (특정 파라미터만 수정)
  const handleCategoryChange = (newCategory) => {
    setSearchParams(prev => {
      prev.set('category', newCategory);
      prev.set('page', '1'); // 카테고리 변경 시 페이지 초기화
      return prev;
    });
  };
  
  // 삭제
  const handleDeleteSort = () => {
    setSearchParams(prev => {
      prev.delete('sort');
      return prev;
    });
  };
  
  // 전체 초기화
  const handleReset = () => {
    setSearchParams({});
  };
  
  return (
    <div>
      <p>페이지: {page}, 카테고리: {category}</p>
      <button onClick={() => handlePageChange('2')}>2페이지</button>
      <button onClick={() => handleCategoryChange('react')}>React 카테고리</button>
      <button onClick={handleReset}>초기화</button>
    </div>
  );
}

주의사항 :

객체로 전달 시 기존 파라미터가 모두 교체됩니다.
특정 파라미터만 수정하려면 함수형 업데이트를 사용하면 됩니다.
페이지 전환 없이 같은 페이지에서 쿼리만 변경됩니다.

4. React 네비게이션 방식

이번엔 페이지 이동시에 파라미터를 어떻게 관리할지 알아보겠습니다.

React Router는 두 가지 방식으로 페이지 이동을 제공합니다.

4-1. 선언적 네비게이션 (Link)

링크를 사용해서 바로 파라미터와 함께 넘어갈 수 있습니다.

import { Link } from 'react-router-dom';

export const Navigation = () => {
  return (
    <nav>
      {/* 경로 파라미터 */}
      <Link to="/product/123">상품 123</Link>
      
      {/* 쿼리 파라미터 */}
      <Link to="/products?category=react&page=1">React 카테고리</Link>
      
      {/* 둘 다 사용 */}
      <Link to="/product/123?tab=review">상품 리뷰</Link>
    </nav>
  );
}

특징 :

JSX에 직접 작성해야합니다.
사용자가 클릭해야 이동이 가능합니다.
접근성이 자동 처리됩니다. (키보드, 스크린 리더)
브라우저 우클릭 메뉴 사용이 가능합니다. (새 탭에서 열기, 새 창에서 열기, 링크 복사 등)

4-2. 프로그래밍 방식 네비게이션 (useNavigate)

useNavigate를 사용하면 코드로 페이지 이동을 제어할 수 있습니다.

import { useNavigate, useSearchParams } from "react-router-dom";

export const Examples = () => {
  const navigate = useNavigate();
  const [searchParams, setSearchParams] = useSearchParams();

  // 예시 1: 경로 파라미터와 함께 이동
  const goToProduct = (productId: number) => {
    navigate(`/product/${productId}`);
  };

  // 예시 2: 쿼리 파라미터와 함께 이동
  const goToSearch = (keyword: string) => {
    navigate(`/search?q=${keyword}&page=1`);
  };

  // 예시 3: 객체 형태로 전달 (권장)
  const goToFilteredList = (category: string, sort: string) => {
    navigate({
      pathname: "/products",
      search: `?category=${category}&sort=${sort}`,
    });
  };

  // 예시 4: 경로 + 쿼리 파라미터 모두 사용
  const goToProductTab = (id: number, tab: string) => {
    navigate(`/product/${id}?tab=${tab}`);
  };

  // 예시 5: 기존 쿼리 파라미터 유지하며 추가
  const addSortParam = (sortType: string) => {
  	// 같은 페이지에서 쿼리만 변경할 때는 setSearchParams 사용
    setSearchParams(prev => {
      prev.set("sort", sortType);
      return prev;
    });
  };

  // 예시 6: 조건부 이동
  const handleSubmit = async (data: any) => {
    // API 호출 예시 (실제로는 구현 필요)
    const result = { success: true, id: 123 };
    
    if (result.success) {
      navigate(`/success?id=${result.id}`);
    } else {
      navigate("/error");
    }
  };

  // 예시 7: 히스토리에 남지 않고 이동 (replace)
  const redirectToHome = () => {
    navigate("/home", { replace: true });
  };

  return (
    <div>
      <button onClick={() => goToProduct(123)}>상품 보기</button>
      <button onClick={() => goToSearch("react")}>검색</button>
      <button onClick={() => goToFilteredList("react", "latest")}>
        필터 목록
      </button>
      <button onClick={() => goToProductTab(123, "review")}>
        상품 리뷰탭
      </button>
      <button onClick={() => addSortParam("latest")}>최신순 정렬</button>
      <button onClick={() => handleSubmit({})}>제출</button>
      <button onClick={redirectToHome}>홈으로 (replace)</button>
    </div>
  );
};

특징 :

JavaScript 코드로 제어할 수 있습니다.
조건부 이동이 가능합니다.
API 호출, 폼 제출 등 로직 실행 후 이동등에 주로 사용합니다.

주의사항 :

replace: true 옵션 시 현재 페이지가 히스토리에서 교체되어, 뒤로가기 시 해당 페이지를 건너뜁니다. 주로 다음과 같은 상황에서 사용합니다.
- 로그인 후 대시보드 이동 시 (뒤로가기로 로그인 페이지 복귀 방지)
- 결제 완료 페이지 (뒤로가기 방지)
- 폼 제출 후 (중복 제출 방지)

// 히스토리 상태
홈페이지
  ↓ 링크 클릭
로그인 페이지
  ↓ 로그인 성공 후 navigate("/dashboard", { replace: true })
대시보드 (현재)

// 뒤로가기 누르면?
대시보드 → 홈페이지 (로그인 페이지 건너뜀)

한글/특수문자는 encodeURIComponent 사용이 필요합니다. 설명한 부분 중 녀석만 자동 인코딩이 안됩니다.

navigate(`/search?q=${encodeURIComponent(keyword)}`);

쿼리 스트링 직접 조합 시 조금 복잡해질 수 있어, 객체 방식으로 진행하는 것을 강추드리옵니다.

4-3. 언제 무엇을 쓸까요?

상황	방식	예시
네비게이션 메뉴	Link	헤더, 사이드바 링크
목록 아이템 클릭	Link	상품 카드, 게시글 제목
폼 제출 후 이동	useNavigate	로그인, 회원가입, 글 작성
API 성공/실패 분기	useNavigate	결제 완료/실패 페이지
조건부 리다이렉트	useNavigate	권한 없을 시 로그인 페이지
타이머 후 자동 이동	useNavigate	3초 후 메인으로

5. 읏차차 최종 정리 (요약)

바로 요약으로 내려오신 분들 반갑습니다.

파라미터 타입별 Hook

파라미터	Hook	읽기	쓰기	페이지전환
경로 파라미터용	useParams	됨	안됨	안됨
쿼리 파라미터용	useSearchParams	됨	됨	안됨
둘 다 가능	useNavigate	안됨	됨	됨

네비게이션 방식

방식	도구	사용 시점
선언적	<Link>	사용자 클릭하는 링크
프로그래밍 방식	useNavigate()	코드 실행 후 자동 이동

선택 추천 가이드

쿼리 파라미터 조작 시?

같은 페이지에서만 변경 → useSearchParams
다른 페이지로 이동하며 전달 → useNavigate

네비게이션 방식?

단순 링크 → <Link>
조건부 이동/API 후 이동 → useNavigate

경로 파라미터 관련?

읽기만 → useParams
다른 ID로 이동 → useNavigate

개발 원칙 DRY, KISS, YAGNI, WET, SOLID 란?

dev-oil — Tue, 11 Nov 2025 20:40:22 +0900

개발하다보면 주워듣는 말...

예시와 두가지 답변으로 한번 이해해보시죠.

DRY - Don't Repeat Yourself

코드를 반복하지 마라
예시
- 이 코드는 조금 DRY 할 필요가 있겠네요
  - 답변 1 - 건조..한건가..
  - 답변 2 - 넵, 반복 코드 함수로 만들어 두겠습니다.

YAGNI - You Ain't Gonna Need It

필요한 작업만 하라 (미리 만들어 두지 마라)
예시
- 이게 왜 필요합니까 그냥 YAGNI 하세요
  - 답변 1 - 야근이나 하라고요...
  - 답변 2 - 넵, 당장 필요한 것만 우선적으로 구현하겠습니다.

KISS - Keep It Simple, Stupid / Keep It Short and Simple / Keep It Small and Simple

단순하게 해라
예시
- KISS 하시죠
  - 답변 1 - 헉.. 너무 이른걸요 ㅠ
  - 답변 2 - 넵, 생각해보니 그냥 if문 하나면 되겠네요.

WET - Write Everything Twice (안티패턴)

모든 것을 두 번 작성 (DRY의 반대)
예시
- 이 코드 너무 WET 하네요
  - 답변 1 - 물광
  - 답변 2 - 넵, 반복 코드 함수로 만들어두겠습니다.

SOLID

객체지향 설계의 5가지 원칙 (단일책임 - Single responsibility, 개방폐쇄 - Open-closed, 리스코프치환 - Liskov substitution, 인터페이스분리 - Interface segregation, 의존역전 - Dependency inversion)
예시
- 여기 SOLID 하게 짜주세요
  - 답변 1 - 컴퓨터는 원래 단단함
  - 답변 2 - 넵, 단일책임, 개방폐쇄, 리스코프... 일단.. ㅠㅠ 알겠습니다.

예시를 재미있게 적어보려했는데..

+ ) 2025.12.30 심지어 다시 봤을 때 너무 재미없어서 수정을 했는데도 예시가 너무 재미없음 심지어 처음에는 이모티콘으로 O X 넣었는데 너무 AI 스럽고 촌스러워서 다시 뺌

2025-11-10 진짜 문제를 찾고, 가장 쉬운 길로 해결하자

dev-oil — Mon, 10 Nov 2025 20:40:55 +0900

요새 작업을 하면서 다양한 개선을 시도하고, 새로운 기술을 적용시켜보고싶은 욕심이 생기고 있다.

보여지는 그 자체에 매몰되지 않기 위해 가장 중요한 기록을 남겨보고자 한다.

1. 지금 풀어야 할 수많은 문제 중, 진짜 해결해야하는 문제는 뭘까?

비즈니스에 직접적인 임팩트를 주거나, 사용자가 가장 불편해하는 문제를 먼저 해결하자.
‘이 문제를 풀면 서비스가 정말 나아지는가?’를 스스로에게 묻자.

2. 그 문제를 가장 단순하게 해결할 방법 (최대한 값싸게 해결할 기술 포인트)

최신 기술이 항상 답일까? 단순한 해결책이 효과적일때도 있다.
가격 / 시간을 고려해보자.
ex. 채팅 구현을 할 때 일반적으로 모두가 WebSocket을 생각하겠지만, 메시지가 유실되면 안되는 상황이 더 중요하다면? HTTP polling이 더 적합할 수 있다.

3. 이 문제를 해결할 때, 여기서 절대 실패하면 안되는 핵심 기능은?

해결 과정에서 무조건 안정적으로 작동해야 하는 부분을 명확히 정의하자.

이게 정말 지금 필요한 건가..

이거 없으면 서비스가 안돌아가나..

사용자가 진짜 원하는게 뭔가..

가장 쉽게 해결할 수 있는 도구는 뭘까..

동기화 안 되는 main-develop, PR Cherry-pick 전략으로 배포 프로세스 개선해보기

dev-oil — Sat, 18 Oct 2025 17:22:37 +0900

1. 깃허브 배포 전략 및 문제를 파악하다.

사내에서 담당하게 된 프로젝트의 Git 브랜치 구조를 처음 봤을 때, 바로 개선이 필요하다고 생각했습니다.

처음 본 문제

main (운영 서버) / develop (개발 서버) 브랜치만 존재했습니다.
main과 develop이 동기화되지 않은 부분이 있었습니다.
전달받은 main 배포 방식은.. develop 작업 파일 수동 복붙이었습니다.

왜 이런 상황이 됐을까?

더 파보니 이전 작업자분들도 나름의 이유가 있었습니다.

로컬에서 CRUD 테스트가 불가능 (보안 제약으로 조회만 가능)
- 즉, 기능 검증을 위해서는 무조건 develop에 올려야만 했습니다.
- feature 브랜치 없이 모두가 develop에 직접 push 했음.
- 배포 제외 기능도 develop에 계속 쌓임.
담당자도 자주 바뀌어, 체계적인 시스템이 없어 어려웠다고 했습니다.

무튼 결과적으로 맞닥뜨린 상황은

develop 브랜치는 보류 기능 + 테스트 코드 + 실제 필요 코드가 전부 섞여있는 상태가 되었습니다.

즉, 배포 할 때 develop → main merge는 불가하고요, 그렇다고 수동 복붙을 계속할 수도 없는 딜레마였습니다.

2. 몇가지 전략을 생각하다.

흠... 운영 배포를 준비하면서 저는 여러 가지 방법을 고민했습니다.

무조건 develop을 한번 타야 테스트 및 공유가 되니,,

develop 브랜치에서 main으로 넘어가는 효율적인 방법을 고민해야 했습니다.

복붙 전략 (기존)
- 작업한 코드만 develop에서 main으로 수동 복사
- 작업량이 많고, 사람 손 타는 순간 오류 발생 가능성이 매우 높았습니다. (시간도 오래걸림)
강제 동기화 전략
- 동기화를 위해 main을 develop에 덮어씌워 일단 싱크를 맞추기
- 하지만 develop에 있던 차후 배포에 포함될 수 있는 기능까지 전부 날아가 버립니다.
release 브랜치 전략
- 배포 가능한 기능만 추려 별도 release 브랜치 생성
- 하지만 이전 develop 커밋들을 정리하기에는 난이도가 너무 높았습니다.

이 모든 방법에는 단점이 있었습니다.
단순히 이전 작업 따라서 땜빵치기는 싫고,, 한가지 키워드를 보고 이거다! 싶었습니다.

바로바로 그 키워드는...

3. 최종 해결책: PR 단위 Cherry-pick 전략

고민 끝에 제가 내린 해결책은 PR 단위 cherry-pick전략이었습니다.

develop에 merge된 Pull Request(PR) 단위를 기준으로 cherry-pick을 진행합니다.
즉, 배포할 기능만 main에 안전하게 반영할 수 있는 구조입니다.
추가적으로 PR number 기준으로 Git 히스토리 관리도 할 수 있죠.

제가 만든 작업 흐름은 다음과 같습니다.

모든 작업은 반드시 신규 브랜치에서 시작합니다.
- ex. feature/JIRA-TICKET-ID-search-filter
작업이 완료되면 → develop에 PR 생성 후 Merge 시점에서 PR 번호(ex. #9)가 작업 마무리의 증거가 됩니다.
- ex. Merge pull request #9 from feature/JIRA-TICKET-ID-search-filter
운영 반영 시에는 main에서 해당 PR 커밋만 cherry-pick 합니다.→ main git log에도 “Merge pull request #9 …” 기록이 남습니다.
- ex. git checkout main git cherry-pick <commit-hash-of-PR-#9>

이제 운영 브랜치에는 작업한 PR 단위로만 코드가 반영되고, 다른 부분에 대한 걱정을 하지 않게 되었습니다!

+) PR number 외 Jira 컨벤션으로 업무 추적까지 (더보기)

저희 회사는 Jira를 사용해서, ticket ID 기반으로 컨벤션도 세웠습니다.

브랜치명: feature/JIRA-TICKET-ID-search-filter
커밋 메시지: feat: JIRA-TICKET-ID 검색 필터 기능 추가
PR 제목: JIRA-TICKET-ID 검색 필터 기능 추가

이를 통해 어떤 업무인지 추적도 쉬워졌죠!

4. 선택적 배포도 이제 유연하게!

PR 단위 cherry-pick 전략 덕분에 배포 범위 조절도 편리하게 할 수 있게 되었습니다.

특정 Jira 업무가 이번 배포에 포함되지 않는다면, 해당 PR은 cherry-pick 대상에서 단순히 제외시킬 수 있게 되었습니다.

추후 필요할 때는 기록을 추적해 해당 PR만 cherry-pick 하여 운영에 반영할 수 있게 되었죠!

5. Before vs After

Before

로컬
  ↓
develop (CRUD 테스트 위해 무작위 push, 테스트용 + 보류 기능 + 실제 필요 기능 뒤섞임)
  ↓
main (운영, merge 불가능 - 수동 복붙)

Git 그래프:

develop: A---B---C---D---E (보류 기능 + 테스트용 작업 혼재)
main:    1---2---3 (수동 복붙으로 관리)

After

Jira Issue
  ↓
feature/Jira Issue-작업
  ↓
(PR) develop (test 전용)
  ↓
(PR 단위 cherry-pick) main (운영 안정 반영)

Git 그래프:

develop:  A---B---[PR#9(실제 필요한 기능)]---C(테스트코드)---[PR#11(실제 필요한 기능)]---D(보류기능)
                     ↓                                   ↓
main:     1---2---[PR#9]----------------------------- [PR#11]

6. 회고

세운 전략으로 배포를 마무리하니, 수작업 복붙의 공포와 불편성에서는 확실히 벗어났습니다.

- Before: 불안 및 불편 지수 ████████░░ 80%

- After: 불안 및 불편 지수 ███░░░░░░░ 30%

통계적으로 유의미한 개선이었습니다. 물론 표본은 접니다.

추가로 나름 깨달은 점도 있습니다.

개발자에게 꼭 필요한 사고방식이 있죠.

"문제가 뭘까? 어떻게 편한 시스템을 만들까?"

이게 사용자를 위한 서비스 개발에만 적용되는 게 아니라, 나 스스로를 위한 운영 환경 개선에도 똑같이 적용되더라구요.

물론 이게 근본적인 해결책은 아니고, Best Practice도 아닐 수 있습니다.

하지만 현 상황에서는 최대한 안전하고 편하게 배포해야 하니까요. (배포 얘기를 하니까 뭔가 다음주에도 배포가 있을 것 같은 느낌이 드네요 )

무튼 마무리 하자면-

이 글을 읽는 선배님들 중 더 나은 방법이 생각나시는 분이 계시다면 제발 댓글로 남겨주세요..

아주 긴 글 읽어주셔서 감사합니다!

github 에서 삭제한 branch 로컬에 남아있는 경우 해결법

dev-oil — Sat, 18 Oct 2025 14:03:48 +0900

문제

github에서 삭제되었다고 전달받은 브랜치가 git fetch를 해도 남아있었습니다.

아니 git fetch 하면 다 최신화 아니냐? 어이없네 하면서 0과 1밖에 모를놈 따위에게 예민하게 굴었는데요!

좀 알아보니까 이유를 발견했습니다.

원인

이유는 origin에 올렸던 reference 값은 fetch를 하더라도 남아있어서였습니다.

fetch는 원격의 새로운 변경사항은 가져오지만, 삭제된 브랜치의 로컬 참조는 자동으로 제거하지 않기 때문입니다.

해결

prune 이라는 "가지치기" 뜻을 가진 명령어를 사용해주면 해결됩니다.

# prune(가지치기 명령어)를 사용
git fetch --prune origin

# 짧게도 가능
git fetch -p origin

자동으로 fetch 할 때 마다 같이 되게 하는법은 다음과 같습니다.

git config --global fetch.prune true

이렇게 오늘도 이슈 하나 해결했습니다!

TB (Test Bed) 란?

dev-oil — Thu, 25 Sep 2025 23:26:22 +0900

지라에서 주워들은말 ... TB

일반적으로 Test Bed(테스트베드)란, 새로운 기능이나 서비스를 시험·검증하기 위한 테스트 환경을 말한다.
우리 회사에선 주로 개발 서버를 TB라고 부르시곤 한다.

TB에서 확인했다 === 운영 배포 전, 개발 서버에서 확했다는 의미!

리액트 구버전 실행 시 Node 17+에서 발생하는 error:0308010C 에러 해결

dev-oil — Thu, 25 Sep 2025 23:16:38 +0900

옛날 리액트 코드를 볼일이 있어서 신나게 npm start 때렸더니 에러가 떴습니다.

npm i 할때부터 deprecated!!! deprecated!! 하더니 역시나…

Error: error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:79:19)
    at Object.createHash (node:crypto:139:10)
    ...
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'

원인은?

Node.js 17+ 버전에서 OpenSSL v3가 기본 적용되면서 Webpack(react-scripts 포함)과의 호환 문제로 발생하는 에러였슴다. (webpack 구버전이 OpenSSL 을 지원 못한다 카더라)

해결 방법

1. 직접 옵션 추가

package.json → scripts에 --openssl-legacy-provider 옵션 추가

"scripts": {
  "start": "react-scripts --openssl-legacy-provider start",
  "build": "react-scripts --openssl-legacy-provider build"
}

2. Node.js 버전 조정

nvm 또는 Node 버전 관리 도구 사용
Node 16 (LTS) 또는 Node 18 (LTS) 버전으로 변경

nvm install 16
nvm use 16

정리

Node 최신 버전과 구버전 webpack 충돌 문제입니다.
빠른 해결은? --openssl-legacy-provider 옵션을 추가해주는 것이고요.
근본 해결은? vite로 마이그레이션해서 node 22 사용하도록 하는것 또는 cra 유지 필요한 케이스는 node 버전을 낮춰서 LTS 버전(Node 16/18) 을 사용하는 것을 권장합니다요.

참석 후기 - 2025 원티드 커리어 웨비나ㅣ물경력 다시 쓰기: 개발자 편

dev-oil — Wed, 17 Sep 2025 20:17:45 +0900

원티드 커리어 웨비나(물경력 다시쓰기 - 개발자 편)가 열린다 그래서 얼레벌레 참석하고왔습니다.

간략한 후기글을 써보려고합니다.

듣게된 계기?

뻔하죠 ㅠㅠ 나 앞으로 물경력 안되려면 뭐하고 또 뭐하고 또 뭐해야할까? 라는 생각에 신청했습니다.

웨비나 신청페이지에서 연사님들의 세션 소개서를 먼저 확인했었는데요, 기술적인 부분보다는 현재 불안한 개발자들을 위한 위로 스타일의 세션일거라고 예상했습니다.

(그리고 그게 맞았습니다)

세션 소개 등의 정보는 더보기 내 원티드 페이지를 참고해주십쇼.

기억에 남는 포인트

1 세션 - 어려운 취업과 이직, 다가오는 AI 가 두려운 개발자들에게

물경력?
남이랑 비교하다가 스스로 깎아내리는 말일 뿐이라고 합니다.
비교는 어제의 나랑만 하면 되고, 올바른 경력이란 없다.
당신의 경력은 당신만의 고유한 경험.
AI 불안?
통제할 수 없는 건 신경 끄고, 내가 할 수 있는 것만 하자.
새로운 경험을 최대한 많이 하자 (문서정리, 리팩토링, 다른 부서 기웃거리기 등등)
개발자 마인드셋?
없다네요 ㅋㅋ 그냥 직장인 마인드셋이라고 생각하는게 맞죠 라고 하셨습니다.
“어떻게 하면 더 완성도 높고 효율적으로 일할까?” 일반적인 직장인들이 생각하는 그거면 충분하다.
환경
환경에 적응하고자 하되, 그 환경이 전부가 아님을 인지하자.

2 세션 - 지금 잘하고 있는지 불안함에 휜싸인 그대에게

불안 대처법
- 기록 습관: 업무일지 쓰면 작은 성취가 쌓이고, 나중에 어필할 근거도 됨.
- 나 관찰하기: 제3자 시점에서 내가 뭘 좋아/싫어하는지 관찰하기.
- 인생 = 프로젝트, 나는 내 인생의 PM. 지금 환경에서 얻을 수 있는 열매부터 따먹자.

Q&A 에서 건졌던 인사이트

사수 없는 회사에서 시니어 되려면?
- 남의 코드 많이 읽으세요. 오픈소스 라이브러리 코드가 최고입니다.
- 시니어는 단순히 코딩만 잘하는 게 아니라, 도메인 이해·협업·소통까지 포함이라고 하셨습니다.
- "사수가 없어서…"를 "그럼에도 불구하고"로!
깊게 vs 얕게?
- 어느 쪽도 정답은 없다고 하셨습니다.
- 본인이 원하는 방향을 먼저 고민하는 게 중요하고, 개인적으로는 넓고 얕되, 특정 분야는 강점으로 잡으면 좋다고 하셨어요.

소감

듣고 나니까 요새 제가 주로 생각하던 것들이라 참 많이 공감이 되었습니다.

“걱정 말고 일단 해라, 경험 쌓아라, 개발자도 직장인이다.”

이 말이 특히 마음에 남았습니다.

또 참여자분들이 채팅창에서 화기애애 대화 나누시면서 각자의 상황을 공유해주신 것도 인상 깊었습니다.

이번 웨비나를 통해 다양한 사람들의 이야기를 듣게 되었고, 무엇보다 웨비나 참석 자체가 연사님이 말씀하신 대로 새로운 경험이라 의미가 있었습니다.

좋은 자리 만들어주셔서 감사합니다 원티드~

voc (Voice of Customer) 란?

dev-oil — Tue, 16 Sep 2025 20:22:10 +0900

기획 회의 중 주워들은 말 ... voc

voc는 보통 Voice of Customer(고객의 소리)라고 한다.
기업이나 서비스 조직에서 고객 불만, 문의, 건의사항 등을 수집하고 관리하는 활동이나 시스템을 통틀어 voc라고 부른다고 함.

voc 대응 건 === 고객 불만·요청에 대응하기 위해 진행하는 건!

next.js 버전 업데이트하면서 알게 된 pnpm add / up 차이

dev-oil — Tue, 2 Sep 2025 21:28:10 +0900

사내에서 깃헙 security 대응으로 next.js 버전을 업데이트 했어야 했습니다.

일단 내부 설정을 살펴보니 package-lock.json / package.json / pnpm-lock.yaml 이렇게 세개의 파일이 관리되고 있었습죠.

이거 세개를 다 바꿔줘야했는데요.

일단 pnpm이 메인 패키지 매니저라 pnpm 으로 대응 하려던 중에, 헷갈리는 게 하나 있었습니다.

바로 버전 업 명령어인 pnpm add / pnpm up 입니다.

두 개나 있는데 느낌대로 쓸 순 없겠죠? ㅋ 그래서 알아보고 한번 돌려봤습니다.

pnpm up

pnpm-lock.yaml 만 업데이트
package.json은 유지

pnpm up next@latest   # 범위 무시하고 최신 버전으로
pnpm up next          # dependencies에 적힌 범위 내 최신으로
pnpm up --latest      # 모든 패키지를 최신 버전으로 (next와 같은 단일 패키지 하나만 아니라 싹다..)

pnpm add

pnpm-lock.yaml / package.json 같이 업데이트 됨

pnpm add next@latest   # 최신 버전으로 교체
pnpm add next@15.5.2   # 특정 버전으로 교체

저는 next 버전만 세 파일 다 바꿔줘야했어서 pnpm add 선생님을 선택했습니다.

pnpm add next@latest 로 진행 후 npm i 해서 package-lock.json 까지 변경해줬습니다.

그래서 결론

lock 파일만 최신화 → pnpm up
package.json까지 확실히 기록 → pnpm add
npm + pnpm 혼용 환경이라면 마지막에 npm i로 package-lock.json까지 정리

필요에 따라 잘 선택하셔서 적용하시면 될 것 같습니다.

별거 없죠? 그럼 전 이만..