호기심이 생겨 다운그레이드를 진행해보기로 했다.

처음엔 구글링 해서 나온 블로그 글을 보고 단순히 npm uninstall 후 원하는 버전을 설치하면 끝날 줄 알았다... 하지만 실제로는 삭제가 제대로 되지 않았다.

⸻

시도했던 방법

처음 구글링한 방법은 아주 단순했다.

### npm
npm uninstall -g @anthropic-ai/claude-code
npm install -g @anthropic-ai/claude-code@1.0.88

### brew
brew uninstall claude-code
brew install claude-code@1.0.88

이 방법만 따르면 문제없이 될 줄 알았는데... 내 환경에서는 조금 달랐다.

⸻

1. 문제가 발생했다

삭제를 했는데도 claude 버전이 계속 최신 버전으로 고정되었다. 즉, 다른 경로 어딘가에 여전히 실행 파일과 패키지가 남아 있었던 것이다. nvm을 설치하고 관리하며 zsh에서 자바 경로 설정 문제를 겪은 적이 있었다. 비슷한 삽질을 했던 경험이 있어서 이번에도 결국 경로 꼬임이 문제일 거라고 짐작했다.

⸻

2. 삽질의 흔적

다음과 같은 시도들이 있었다......

2005  npm uninstall -g @anthropic-ai/claude-code
2006  npm install -g @anthropic-ai/claude-code@1.0.88
2013  brew uninstall claude-code
2020  sudo rm -rf /Users/johndoe/.npm-global/lib/node_modules/@anthropic-ai/claude-code
2022  rm -f ~/.npm-global/bin/claude
2097  sudo rm -rf /Users/johndoe/.nvm/versions/node/v20.10.0/lib/node_modules/@anthropic-ai/claude-code
2101  sudo rm -rf /Users/johndoe/.nvm/versions/node/v20.10.0/lib/node_modules/@anthropic-ai/claude-code
2103  which claude
2105  npm install -g @anthropic-ai/claude-code@1.0.88
2106  which claude
2110  claude --version

여기서 중요한 단서를 발견했다. .npm-global 경로를 지우려 계속 시도했지만, 사실 내 컴퓨터에는 그 디렉토리가 아예 존재하지 않았다. 그걸 어떻게 알았냐면

cd ~/.npm-global을 찍어봤는데,
cd: no such file or directory: /Users/johndoe/.npm-global
???

나는 없는 디렉토리를 지우려고 헛수고를 하고 있었던 것이다.

⸻

3. 원인과 해결

아... 나 nvm쓰지;

결국 진짜 원인은 내 환경에서 nvm을 사용하고 있다는 사실이었다.

패키지가 설치된 위치는 ~/.nvm/versions/node/v20.10.0/lib/node_modules/ 아래였다.

해결 과정

1. 실행 경로 확인

which claude
# -> /Users/johndoe/.nvm/versions/node/v20.10.0/bin/claude

2. 실제 설치 경로에서 삭제

sudo rm -rf ~/.nvm/versions/node/v20.10.0/lib/node_modules/@anthropic-ai/claude-code

3. 원하는 버전(1.0.88) 재설치

npm install -g @anthropic-ai/claude-code@1.0.88

4. 정상 확인

claude --version
# -> 1.0.88

⸻

느낀 점

• 삭제가 안 될 때는 먼저 which로 실행 경로를 확인했어야 하는데... nvm에서 JAVA_HOME 경로 설정해 줄 때랑 데자뷰가 느껴졌음 • 경로를 의심하기 전에, 실제로 그 디렉토리가 존재하는지 먼저 확인할 것 • nvm을 쓰는 환경에서는 전역 패키지가 .nvm/versions/node/.../lib/node_modules/에 설치된다는 점을 기억해야 했다.

다운그레이드 해서 사용해보니 확실히 응답의 품질이 달라진 것 같다. 클로드 업데이트가 안정화될 때 까지는 당분간 1.0.88 버전으로 사용해야 할 듯!

우리 서비스는 아직 QA팀이 따로 없고, 기존 코드베이스도 테스트 커버리지가 없었던 상태였다.

최근에 jest와 playwright 환경을 구축했으니, 신규 기능부터라도 테스트 작성을 병행하기로 다짐했다.

기능 개발과 함께 테스트 작성을 해보며 느낀 점과 테스트가 어떻게 도움이 되었는지 정리해보려고 한다.

⸻

1. 테스트 작성은 품이 든다

테스트를 작성과 기능 개발을 같이 하려니 초기 개발 속도는 느려지긴 하는 것 같았다.

하지만 장기적으로 유지보수나 리팩토링을 고려하면 테스트를 작성하는 리소스가 훨씬 적다고 생각했다. 특히 요즘같은 AI 시대에... 바이브 코딩을 하려면 테스트가 필수적이라고 다시금 느꼈다.

⸻

2. Playwright로 QA 자동화

Playwright를 사용하면서 가장 크게 느낀 점은 반복적인 테스트 과정을 자동화할 수 있다는 점이었다. 기존에는 직접 브라우저를 켜고 번거롭게 일일이 확인해야 했는데, 이제는 스크립트만으로 정말 브라우저에서 테스트하는 것 처럼 대체할 수 있다니 신세계였다.

특히 우리처럼 아직 QA팀이 없는 환경에서는, 개발 시간 단축에 크게 도움이 됐다!

나 대신 QA 뺑뺑이 돌려주는 Playwright야 고마워...

But! 초반에 성능 문제가 있었다. 초기 로그인 시나리오 테스트가 지나치게 느려서 30초 타임아웃 에러가 발생하기도 했다 💧

로그인 등 공통 시나리오는 최대한 캐싱/최적화하고, 모든 케이스를 커버하기보다는 핵심 시나리오 위주로 작성해야겠다는 교훈을 얻었다.

⸻

3. 유닛 vs 통합 테스트 범위 기준

테스트를 공부하며 가장 혼란스러웠던 부분은 유닛 테스트와 통합(E2E) 테스트의 작성 범위였는데, 직접 작성해 보며 나름의 기준이 생겼다. • 구체적이고 사소한 동작 (버튼 클릭 시 상태 변경, util 함수 결과 등) → 유닛 테스트 (Jest) • 전체적인 시나리오 (관심매물 등록 → 수정 → 삭제 흐름) → 통합/E2E 테스트 (Playwright)

먼저 테스트를 작성할 경계를 잡고 나니, 새로운 테스트를 작성할 때 테스트 케이스를 고민하는 시간이 줄었다. 앞으로는 팀원들의 합의를 구하고 어느정도 정형화된 컨벤션으로 굳혀두면 좋을 것 같았다.

⸻

4. 실제로 테스트가 도움이 된 사례

Jest와 React-Testing-Library로 작성한 유닛테스트. 생각보다 성능이 만족스럽고, 도움도 많이 주었다.

4-1. 사소하지만 UI 에러를 조기에 잡아냄!

테스트 작성 덕분에 놓칠 뻔한 UI 버그를 발견했다. 관심매물 카드에서 가격 변동이 없는 경우 화살표(up, down)가 표시되면 안 되는데, 직접 개발할 때는 그 부분을 놓쳤다.

작성한 유닛 테스트가 실패하면서 문제를 바로 확인할 수 있었고, 코드를 수정해 반영했다.

it('변동 정보가 없을 때 화살표가 표시되지 않는지 확인', () => {
  const apartmentDataWithoutDeltas: typeof mockApartmentData = {
    ...mockApartmentData,
    salePrice: {
      ...mockApartmentData.salePrice,
      salePriceMinDealPrice: 75000,
      salePriceMaxDealPrice: 75000,
    },
  };

  render(
    <ComplexPriceCard
      apartmentData={apartmentDataWithoutDeltas}
      expanded={true}
    />
  );

  const priceSection = screen.getAllByText('7억 5,000')[0].closest('div');
  const arrowImages = priceSection?.querySelectorAll('img');
  expect(arrowImages).toHaveLength(0);
});

4-2. 리팩토링에 자신감을 줌

관심매물을 등록할때, 매물을 선택하는 모달(단지이름, 평형, 타입 등)과 중복되는 부분이 많아서 공통 컴포넌트로 분리해야 했다. 이 과정에서 기존에 모달을 사용하는 부분도 수정이 불가피했다.

이전 같으면 “혹시 기존 동작이 깨지진 않을까?” 하는 불안감으로 직접 QA를 몇 번이고 해 봤을 텐데, 테스트가 있었기 때문에 안심하고 자신있게 리팩토링할 수 있었다.

⸻

이번 작업을 하며 프론트엔드에서 테스트의 역할을 체감할 수 있었다. 그리고 테스트를 실무에서 작성하고 사용해 본 첫 프로젝트라서, 개인적으로도 기억에 남을 프로젝트가 되었다!

그동안 우리 서비스의 클라이언트는 앱도, 웹도 테스트가 전혀 없는 상태였다. 망망대해에서 노를 젓는 기분으로 개발을 진행해왔다... (새로 합류하신 동료분이 지금까지 클라이언트 쪽에서 테스트 하나 없이 서비스를 굴려왔다는 게 오히려 대단하다고 하실 정도였다.)

항상 클라이언트에도 테스트를 도입하고 싶었지만, 일정에 쫓겨 구현하지 못했었다. 하지만 이번에 네이버 지도api를 사용하는 어플리케이션의 레거시 코드를 모두 걷어내는 방대한 리팩토링을 시작하게 되었고, 안전한 리팩토링을 위해 테스트코드의 필요성을 절실히 느꼈다. 그리고 마침 우리 팀에는 클로드 코드가 결제되어있었다.

그래서 일단 테스트를 구축하기 비교적 수월한 Next.js 기반의 웹 서비스부터 테스트 환경 구축을 시작했다.

⸻

Playwright + Jest 환경 구축

클로드 코드야 고마워...

이번엔 claude code 도움을 받아 e2e는 Playwright로, 유닛테스트는 Jest로 환경을 세팅했다. 생각보다 훨씬 빨리 끝났다. 예전에 admin 페이지에서 Jest를 쌩으로 세팅할 때랑 비교하면 차이가 컸다.

그때는 babel, ts-jest, transform 설정부터 막히고, config를 어떻게 나눠야 할지 애매해서 시간을 많이 날렸는데 클로드 코드와 함께하니 기본 구조를 내가 알고 있고, LLM이 실행하고 디테일을 채워주는 느낌이었다.

예전에 jest를 냅다 도입하느라 삽질했던 경험 덕분에, LLM이 준 답이 맞는지 틀린지 판단할 수 있었던 것이 큰 차이를 가져왔다.

하지만 역시 설계는 사람이 직접 해야죠

LLM이 큰 도움은 됐지만, 초기 설계는 아직 사람이 직접 하는 게 낫다는 걸 느꼈다. 폴더 구조나 테스트 전략 설계를 LLM한테 맡겨봤는데, 컨텍스트가 조금만 복잡해지면 다소 조잡한 설계를 제시하는 같았다.

TDD의 현실화

그동안 TDD는 리소스가 부족한 우리 팀에선 다소 사치스러웠다 하지만 클로드 코드가 mock 코드 생성이나 반복적인 작업을 해주니 진짜 TDD가 눈 앞에 다가왔다.

그래도 공부는 당연히 해야함!

테스트를 직접 세팅하면서 삽질해본 경험이나 javascript의 동작 원리에 대한 지식 등 기본기는 무조건 필요하다는 걸 느꼈다. 특히 디버깅할 때, 예전에 Jest를 직접 만져본 경험이 큰 도움이 됐다.

내가 뭘 쓰고 있는지 모른 채로 LLM을 쓰는 것은 개발자로서 지양하고 싶고, 그래야 한다고 생각한다.

⸻

시맨틱 마크업의 중요성

테스트를 작성하면서 HTML 기본기의 필요성도 크게 느꼈다. 특히 e2e 테스트에선 지금 마크업 구조로는 도저히 요소를 찾아오기가 어려워서... 직접 코드를 수정하는 일도 있었다. 테스트 때문에 코드를 수정하는 것은 지양하고 싶었지만, 어차피 리팩토링이 필요한 구조였기도 했다. 이제부터라도 시맨틱 마크업을 철저히 지키자고 다짐했다.

⸻

테스트 친화적인 코드 ≒ 클린 코드

테스트를 고려하면서 컴포넌트를 작성하면 코드가 자연스럽게 클린코드에 다가가는 것 같았다. 그동안은 비즈니스 로직과 UI가 뒤엉킨 코드가 많아서 테스트하기도 어려웠는데, 앞으로는 테스트를 기반으로 점진적으로 리팩토링을 해야겠다. 테스트 가능성과 코드 품질은 상관관계가 크다는 것을 느꼈다.

⸻

대규모 리팩토링 전, 테스트는 필수!

내가 진행중인 지도 서비스는 UI+비즈니스 로직+복잡한 상태들+외부 API 호출+중복된 코드등이 얽혀있는 레거시 코드다. 이전에도 지도 코드 리팩토링을 진행 했었으나, 자신감이 없어서 운영환경에 붙이지 못한 브랜치들도 많았다.

이제는 테스트를 기반으로 시도할 수 있다는 자신감이 생겼다. 특히 LLM과 개발하는 환경에서 테스트는 선택이 아니라 필수!! 클로드 코드가 있으니 테스트 작성은 더 이상 리소스 낭비가 아니라 투자라고 느껴진다.

⸻

드디어 테스트 없는 클라이언트에서, TDD로 나아가는 첫걸음을 뗐다. 너무 감격스럽고 마치 망망대해에서 유람선에 올라탄 기분이다...

사실 2~3년 전에는 프론트엔드에서 테스트의 필요성 자체에 대한 논쟁이 분분했는데, LLM의 등장 이후부터는 거의 논쟁이 종결된 것 같다. LLM으로 개발하다보면 왜 테스트가 필수인지 자연히 알게 되어서 그런 듯 (나 역시도 그랬다).

다음엔 지도 리팩토링이나 신규 개발하는 기능에서 테스트가 어떤 역할을 하는지, 어떤 도움을 받았는지 등을 더 구체적으로 기록해 볼 예정이다!!

sdk 라이브러리 설치, appsflyer에 앱 추가하고 sdk 연결하기 까지는 무난하게 되었다.

onelink 도메인도 appsflyer에서 제공해주어서 쉽게 새로 팠다.

문제는 안드로이드에서 앱링크를 사용하려면 SHA-256 서명을 RN프로젝트에 추가하라는데?

이 서명이 왜 필요한지, 어떻게 추가할 수 있는지를 전혀 몰랐다는 것 …

공식문서를 봐도,

참고 그림을 봐도 전혀 무슨 소리인지 이해가 되지 않았고,

지피티에 질문해서 하기와 같은 결론을 얻어내었다.

📌 PKCE를 거치면 얻게 되는 것

• code_verifier - a large random string generated by the client
• code_challenge - the SHA 256 of the code_verifier

요약하자면

• SHA-256은 어떤 프로토콜이나 정책이 아닌 단순한 ‘해시 함수’.

• code_verifier를 전달하면 SHA-256 해시함수를 통해 해시 값을 반환하는구나.
• 이 해시 값을 처리하는 것은 OAuth 2.0 인증 과정과 서버.
• AppsFlyer 서버에서는 정확히 어떻게 처리하는지 모르지겠만, code_verifier와 code_challenge 의 일치성을 검증하는 로직이 있겠구나.
  라는 결론에 도달함.

이것을 이해하고 다시 위의 RN공식문서를 보니 이해가 잘 되었다.

그런데 이제 어떻게 구현하지?

인증서를 내 앱에 구현하기 위해 많은 서치를 해보았다…

💥 그러나! SHA-256 인증을 구현할 필요 없었다 …

참고 문서 : Android initial setup

우리 프로젝트는 이미 플레이 스토어에 서비스 중인 상태였다.

→ 당연히 keystore 파일이 플레이스토어에 올라간 상태였음.

→ keystore를 업로드했다면 해당 keystore에 종속된 SHA-256 인증도 있을것이고…

→ appsFlyer 공식문서를 확인하니 SHA-256 인증 관련 내용이 있었음.

→ 문서를 보고 우리 서비스 플레이 콘솔에 들어가보니 … 당연히 서명키 인증이 있었더랬다 😂

✏️ 느낀 점

공식 문서를 진작 봤으면 될 걸 너무 멀리 가서, 이미 구현되어 있던 것의 원리를 파고 들었다.

그치만 해시함수를 추상적으로만 배우고 알고리즘이나 달달 외웠지… 이렇게 실제로 사용하는 예시를 보니 헛으로 공부한건 아니라서 재밌기도 했다.

Branch IO와 고민했으나, 내부에서 상의 후 우세한 사용량 + 무료라는 메리트로 AppsFlyer 솔루션으로 결정!

sdk 라이브러리 설치, appsflyer에 앱 추가 후 sdk 연결하고, onelink 도메인도 appsflyer에서 제공해주어서 쉽게 새로 팠다.

아래 세팅 과정을 참고하시어 간단히 구현하시길 바란다.

📌 세팅 과정

1. AppsFlyer에 우리 서비스 앱 추가 및 sdk연동

sdk설치, AppsFly 앱 추가 후 연동 같은 것은 다른 솔루션들과 비슷하기 때문에 어렵지 않게 세팅할 수 있음. SDK연동은 하기 라이브러리를 사용하였다.

GitHub - AppsFlyerSDK/appsflyer-react-native-plugin: AppsFlyer plugin for React Native

2. App ID, Bundle ID, SHA256 해시값 가져오기

apple developer에서 App ID와 Bundle ID를, google play console에서 SHA256 해시값을 찾는다. (SHA256 해시값 관련하여 거대한 삽질 일기가 있는데... 이것은 별도 포스팅으로 발행하였다)

3. 원링크 템플릿에 해당 값들 추가

원링크 템플릿을 추가하면서 2에서 찾아온 값들을 각각 유니버설 링크, 앱링크에 세팅해주면 됨.

4. fallback 커스텀 스킴 설정

URI scheme fallback에는 우리 앱의 커스텀 스킴 ur를 넣어주었다.

유니버설링크 or 딥링크는 아직까지 호환성 문제에서 완전히 자유롭지 못하기 때문에, 해당 링크들이 동작하지 않을 경우 uri스킴으로 폴백도 가능해서 편리하다!

입력 폼을 테스트 하다가 아래와 같은 이슈로 테스트가 막혔다.

경험상 is not a function으로 끝나는 TypeError는 보통 타입에 관한 문제가 아니라, 환경 안에서 함수를 못 찾는 이슈였다.
parse는 date-fns라는 외부 라이브러리에서 가져와서 사용하는 함수였다.

-> 모킹이 안되거나 모듈 시스템 관련 이슈가 있겠구나! 라는 결론에 달했다.

| Trial 1 - 실패

먼저 클로드에서 알려 준 대로, 모킹을 손보기 위해 jest.setup.js에 아래 코드를 추가해보았다.

//jest.setup.js

jest.mock('date-fns', () => {
  const actual = jest.requireActual('date-fns');
  return {
    ...actual,
    parse: jest.fn(() => new Date()),
    isValid: jest.fn(() => true),
    __esModule: true,
  };
});

1. requireActual 메소드로 실제 라이브러리를 가져오고.

2. 에러메세지에 '_parse.default'가 포함된 것으로 보아 default export임을 인식하게 해주기 위해 __esModule: true 를 추가했다.

하지만 에러는 그대로였다. 모킹이 되고 있지 않았다.

| Trial 2 - 성공!

그런데 실제로 parse를 사용하는 함수가 정의된 파일에서는 아래와 같이 named import를 사용하고 있었다.

import { isValid, parse } from 'date-fns';

왜 jest는 parse 함수가 default export라고 생각했을까? <- 여기부터 문제가 있었다.

그래서 모킹 관련 코드를 모두 삭제 후 구글링을 시작했고,

아래 이슈에서 해결책을 찾아 1초 만에 해결되었다.

https://github.com/date-fns/date-fns/issues/3674

parse를 사용하는 함수가 정의된 곳에서, 아래와 같이 namespace import 문으로 변경하고 해결되었다.

import * as dateFns from 'date-fns';

왜 에러메세지에선 default라고 했느냐?

컴파일 과정 중 jest가 parse함수를 찾을 때 아래와 같이 변환된 것 같았다.

const { default: parse } = require('date-fns');

1. Jest가 ES 모듈의 named exports를 default export로 잘못 해석하는 문제가 있었고
2. 이로 인해 const { default: parse } = require('date-fns')와 같은 잘못된 변환이 일어났으며
3. 이를 해결하기 위해 namespace 객체를 통째로 가져오는 import문을 사용해서 해결.
   

| 느낀 점

• 진작 해당 라이브러리 이슈를 뒤져볼 걸 (...) 아직은 디버깅에서 AI를 완전히 신뢰하기엔 힘들다.
• 그래도 ES 모듈 시스템과, named import와 namespace import를 더 잘 이해하게된 계기가 되었다.
• jest의 컴파일링 과정을 알았다면 실패를 줄일 수 있지 않았을까? jest의 동작원리도 추후 찾아보아야겠다.

Error: Cannot create styled-component for component: undefined.

라는 오류를 만났다.

//from 
export const Wrapper = styled(PrevComponent)
//to
export const Wrapper = styled( props => <PrevComponent {...props} />)

이런 형식으로 바꿔주면 된다고 하는데 일일히 바꾸기엔 해당 문법을 써둔 코드가 너무 많았다 ... 😢

비효율을 너무 싫어하는 나는 방법을 찾았다.

VScode의 찾아바꾸기 기능을 이용해 styled(_문자열_) 을 모두
styled(props => <_문자열_> {...props} />) 형식으로 바꿔주는 것!

정규표현식을 사용하면 특정 문자열을 뽑아낼 수 있다.

VScode의 검색을 켜고 .*을 눌러 정규표현식을 활성화 후, 바꾸기 모드도 활성화 해준다.

styled\((.*?))
해당 문자를 찾아
styled(props => <$1 {...props} />)
로 바꿔주면 된다!

\( 이스케이프 문자가 붙은 괄호는 ( 이 괄호 스트링을 찾는 것이고,

(.*?)을 묶는 양옆의 괄호는 $1로 괄호안의 문자열을 치환하기 위한 괄호인 것을 주의하기 바람

공익 차원에서 정규식을 공유해본다.

조금이나마 시간 아끼고 효율적인 개발 하는 하루 되시길!

zsh를 설치했고, 조금 더 편리하게 사용하기 위해 oh-my-zsh를 사용하고 있다.

어차피 리눅스 기반의 쉘스크립트는 다 유닉스랑 비슷하지 않겠어?라는 생각에 서치해봤더니
역시 oh-my-zsh에서도 alias를 등록할 수 있었다.

회사 업무를 하다보면 자주 중복해서 사용하는 명령어가 있기 마련이고, 일일히 타이핑하기 귀찮을 때도 있을 것이다.

alias를 사용하면 더 효율적인 작업이 가능할 듯 했다.

자주 쓰게되는 명령어나, 입력하기 귀찮은 명령어들은 alias로 등록해두면 편하게 사용할 수 있다.

방법은 간단하다.

1. zsh의 rc파일 열기

open ~/.zshrc

2. open ~/.zshrc 파일 편집 후 저장하기 

.zshrc 파일 내에 내가 지정할 별칭과 명령어를 입력한 후 저장하면 된다.
형식은 다음과 같다.

 alias 별칭="명령어"

3. 수정된  zshrc 저장 후, 수정사항을 등록하기

source ~/.zshrc

이제 내가 지정한 alias를 oh-my-zsh 터미널에서 사용할 수 있다!

++ 아래는 내가 사용하는 alias중 일부이다.

alias addextpod="git add . && git reset ios/Podfile.lock"

빌드 시 내 개발환경에서만 문제가 있는 라이브러리가 있어서, 늘 작업할때 Potfile.lock을 바꿔서 작업 후 빌드를 돌려본다. git add .를 하면 자꾸 lock파일이 변경사항으로 잡혀 같이 올라갔다. gitigonre에 lock파일을 추가하거나 다른 팀원분들의 lock파일까지 바꿔버릴 수 없어서 Podfile.lock을 제외하고 staging하는 명령어를 따로 지정해두었다.

alias stashall="git stash -u"

그냥 git stash를 하면 untracked file(신규 파일)은 포함되지 않는 것이 불편했다. git stash -u 를 stashall이라는 별칭으로 저장해두었다.

격세지감이라는 말은 이럴 때 쓰는 건가 싶다.

많은 일이 있었지만 아직도 개발은 좋다.

원래 2022년 부터 작성하던 티스토리 블로그는 편리하고 커스텀하기 좋았지만, 서비스가 불안정해 보여서 벨로그로 마이그레이션 하려고 한다.

2025년 개발 블로그로 다시 시작!