Clzzi 개발 블로그

정들었던 첫 회사를 떠나며

Fri, 17 Oct 2025 00:00:00 GMT

어느덧 프론트엔드 엔지니어로 일한 지도 3년이 흘러, 4년 차 엔지니어가 되었습니다.
2022년 10월, 고등학교 3학년 때 모두싸인에 입사해 3년이 지난 2025년 10월에 퇴사하게 되었어요.
이번 글에서는 첫 회사를 떠나며, 그리고 이직을 준비했던 과정을 회고해보려 합니다.

이름표

지난 3년간 나는 무엇을 했을까?

고등학생 때부터 사회생활을 시작했기 때문에, 첫 회사에서는 가능한 많은 것을 경험해보고 싶었어요.

입사 당시 일반적인 취업흐름과 달리 대학교를 스킵하고 취업하였기 때문에 남들보다 더 열심히 해야 물경력이 되지 않을거라는 생각과, 남들보다 빠르게 일하기 시작한만큼 부스터(?)효과를 누려야겠다고 생각했기때문이에요.

그 경험에는 기술, 도메인 & 비즈니스 이해, 재테크 공부, 네트워크 형성, 사회생활 등 다양한 요소가 있었고,
3년 동안 멈추지 않고 성장하는 것에 집중했던 것 같아요.

무엇을 만들었나?

모두싸인에서 근무하며 여러 기능을 개발했지만, 그중에서도 특히 기억에 남는 기능은 두 가지예요.

홈화면

현재의 홈화면

홈화면은 계약관리팀에서 진행했던 1박 2일 해커톤을 통해 만들어진 기능이에요.
당시 홈화면의 필요성은 인지하고 있었지만 직접적인 매출로 이어지는 기능이 아니다 보니 우선순위가 계속 밀렸어요.
그래도 팀 내부에서 공감대가 잘 형성되었고, 정식 스프린트 대신 해커톤을 통해 만족할 만한 결과물을 낼 수 있어서 정말 뿌듯했던 기억이에요.

거기다가 크리스마스 전에 개발을 마치고, 크리스마스 선물처럼 전사에 공유했던 기억이 아직도 생생하네요 🎁

계약관리팀 a.k.a FLAME-BOYS

테넌트 시스템

사내 블로그

테넌트 시스템은 구축형 프로젝트에서 만들었던 기능이에요.
프로젝트의 FE 엔지니어가 저 혼자뿐이어서 시행착오도 많았지만, 결과적으로는 잘 완성되어서 다행이었어요.

모두싸인은 8년 이상 된 코드가 남아 있었고, 그 부분까지 포함해 시스템적인 개선을 해야 했어요.
이런 경험은 흔치 않은 기회라고 생각해요, 특히 저연차 엔지니어에게는 더더욱 그런것같아요.

또한 변경 범위가 프론트엔드 챕터 전체에 영향을 주었기 때문에 회의 리딩이나 문서화까지 챙겨야 했고,
그 과정에서 리딩 능력과 커뮤니케이션 역량도 많이 성장했어요.

수많은 회의들…

노션에 적은 정책서

회사 보안정책상 테넌트 시스템 관련 내용을 자세히 적지 못하는 게 아쉽네요 🥲

이외에도 리마인더, 예약전송, API 연동 페이지, 그로스 프로젝트 등 다양한 기능을 개발했고,
여러 팀을 오가며 다양한 경험을 쌓을 수 있었습니다.
3년이 지나고 보니 전자계약 도메인과 B2B 비즈니스에 대한 이해도도 많이 깊어졌어요.
이런 경험들은 앞으로의 커리어에도 큰 자산이 될 것 같습니다.

다른 경험들

회사 생활을 하면서 팀원분들과도 많이 친해졌고,
업무 외적으로도 재테크 공부나 네트워크 형성에 관심을 가지고 꾸준히 노력했어요.

사진으로 보는 게 더 잘 전달될 것 같아요 ☺️

FLAME-BOYS 여행

책도 읽고

수익 천만원 이상 달성!

산업기능요원 마무리

입사 동기들과 여행 - 주디 커비 바트 레오

왜 이직을 결심했을까?

3년 동안 계약관리팀, API 연동팀, 플랫폼팀, Growth팀 등 다양한 도메인을 경험하며
입사 당시 세웠던 목표를 어느 정도 이뤘다고 느꼈어요.

하지만 시간이 지나면서 회사에도 여러 변화가 있었죠.

입사 당시와 비교했을 때 FE 엔지니어 인원이 절반 가까이 줄어 코드 리뷰나 기술 논의의 제약이 존재했음
작업 방식이나 회사 방향성의 변화로 인한 아쉬움이 있었음

이런 부분들이 누적되면서 자연스레 이직을 고민하게 되었어요.
여러 개선 시도를 해봤지만 결과적으로는 잘 풀리지 않았고,
새로운 환경에서 다시 도전해보기로 결심했어요.

이번 이직에서는 아래와 같은 점들을 기대했어요.

개인적으로 흥미를 느낄 수 있는 프로덕트를 서비스하는 조직
모두싸인(약 100명)보다 규모가 크고 체계적인 조직
구성원들이 밀도 있고 열정적으로 일하는 조직

이런 기준에 부합하는 회사를 찾아 지원하기 시작했습니다.

결과적으로

채용 시장이 얼어붙어 있던 시기였지만,
노력하고 성장하는 사람에게는 결국 기회가 온다고 믿었어요.
가고 싶은 회사를 먼저 리스트업하고, JD에 맞춰 이력서를 조금씩 수정하며 지원했어요.

열심히 면접 준비했던 흔적

가고 싶었던 회사는 아래와 같아요.

오늘의집: 프로덕트에 대한 개인적 흥미
강남언니: 프로덕트 & 도메인 모두에 대한 관심
토스: 기술적으로 유명하고, 지인들의 추천
당근마켓: 자유로운 분위기와 자주 사용하는 서비스
카카오: 대기업이면서 동시에 힙한(?) 문화

결국 강남언니(힐링페이퍼) 에 최종 합격하여 조인하게 되었습니다! 🎉

최종 합격 메일

강남언니는 제가 실사용했던 서비스이기도 하고, 이전부터 조직 문화와 방향성에 매력을 느꼈던 회사예요.
게다가 처우 협의 결과도 만족스러워서 정말 좋은 기회라고 생각했어요.

마치며

모두싸인에서의 3년 여정을 마치며 이렇게 짧은 회고록을 남깁니다.
입사와 퇴사 당시의 슬랙 메시지를 함께 보니
그 사이 있었던 수많은 추억이 새록새록 떠오르네요 ㅎㅎ

입사 메시지

퇴사 메시지

첫 회사를 통해 단단해질 수 있었고, 이제는 새로운 무대에서 또 다른 도전을 시작하려 해요.
여전히 배움의 길 위에 있고, 앞으로의 여정이 기대돼요!
모두싸인에서의 지난 3년은 제 커리어의 든든한 시작점이자, 가장 따뜻한 기억으로 남을 것 같아요.

하나의 코드로 멀티 테넌트 서비스 운영하기

Tue, 16 Sep 2025 00:00:00 GMT

해당 글에선 테넌트(Tenant)라는 용어와 환경(Environment)이라는 용어를 동일하게 사용합니다 🙇🏻‍♂️

배경

모두싸인에서 근무하며 계약 관리, API 연동, 그로스팀 등 다양한 목적을 가진 팀을 경험했다.
그러던 중 온프레미스(on-premise) 형태로 서비스를 제공할 수 있는 구축형 서비스가 필요해졌고, 내가 Frontend Engineer로 참여하게 되었다.

여러 테넌트에서 모두싸인 서비스를 각 환경의 특성에 맞게 제공할 수 있어야 했고, 기능적인 부분은 주로 “A, B, C 기능 중 A와 B만 동작한다” 와 같은 분기 처리가 필요했다.
이러한 요구사항은 기존 기능 중 일부만 노출하거나, 기능 동작을 조금씩 수정해 제공하는 형태여야 했기 때문에 흔히 생각할 수 있는 MicroFrontend 방식은 적합하지 않았다(인적·금전적 리소스 문제도 있었다).

그 결과, 하나의 코드로 여러 테넌트 환경에 맞는 서비스를 제공하고 운영할 수 있는 구조를 설계하게 되었다.

내용

개인 블로그에는 보안 정책으로 인해 구체적인 작업 내용을 작성하기 어려워, 사내 기술 블로그에 정리해 공유했다.

👉🏻 사내 기술 블로그 - 하나의 코드로 멀티 테넌트 서비스 운영하기 👈🏻

느낀점

테넌트 시스템을 설계하면서 다방면으로 챌린지가 있었다.

1. 문서화 & 설득

온프레미스 프로젝트는 Frontend Engineer가 나 혼자였지만, 변경 범위는 프론트엔드 챕터 전체에 영향을 주었기 때문에 변경 사항을 자주 공유하고, 팀원들의 의견을 반영하며, 불가능한 부분은 설득해야 했다.
초반에는 어려웠지만 점차 적응하면서 점점 더 잘 해낼 수 있었다.
중요했던 것은 왜 이런 선택을 하려는지, 다른 선택지와 비교했을 때 어떤 트레이드오프가 있는지를 명확히 하고, 설득할 수 있는 근거 자료를 충분히 모아 문서화하는 일이었다고 생각한다.

2. 시스템 설계

작은 프로젝트에서는 시스템을 쉽게 수정·개선할 수 있었지만, 이렇게 방대한 코드가 쌓여 있는 프로젝트에서 시스템을 개선하고 설계한 것은 처음이었다.
다른 도메인 팀에서는 실시간으로 개발과 배포가 이루어지고 있었기 때문에 영향 범위 최소화, 하위 호환성 유지, 이슈 발생시 빠른 대응 등 고려해야 할 요소가 많아 접근 자체가 쉽지 않았다. 다행히 경험이 많은 CTO님과 DevOps 엔지니어(전 Frontend Engineer) 한 분의 도움으로 이러한 요소들을 꼼꼼히 체크하며 설계할 수 있었다.
앞으로 다시 비슷한 상황이 온다면, 이번 경험이 큰 자산이 될 것이라 생각한다.

Input 제일 뒤로 커서 보내기

Wed, 06 Nov 2024 00:00:00 GMT

배경

회사에서 진행 중인 프로젝트에서 UX 향상을 위해 키보드 사용성 개선 작업을 진행했어요. Input 컴포넌트 하위에 검색 결과가 리스트 형태로 노출되고, 해당 리스트 아이템들을 키보드로 쉽게 탐색하고 선택할 수 있는 UX를 구현하는 것이 목적이었어요.

기본적인 동작은 잘 작동했지만, 키보드 사용성을 강화하면서 새로운 UX적인 불편함이 발생했어요.
바로, 키보드로 포커싱한 리스트 아이템에서 다시 Input으로 포커스를 이동할 때, Input에 값이 있음에도 불구하고 커서가 항상 맨 앞으로 고정된다는 점이었어요.

Pain Point

이 이슈는 단순히 백로그 성격의 문제일 수 있지만, 개인적으로는 중요한 UX 결함이라고 느꼈어요.

사용자가 가장 불편하게 느낄 수 있는 지점은 다음과 같아요:

“타이핑을 잘못해서 다시 수정하려고 커서를 옮겼는데, 예상과 다르게 커서가 맨 앞으로 이동한다면?”

이런 경험은 사용자가 기대하는 UX와 실제 동작이 다르다고 느끼게 만들고, 불필요한 인지적 스트레스를 유발해요 🫠

해결방법

이 문제를 해결하기 위해 리서치를 진행하던 중, 아래와 같은 사실을 알게 되었어요.

input 요소에는 전체 선택을 위한 select 메서드가 있어요.
커서 위치를 특정 지점으로 이동하거나 범위를 지정해 선택할 수 있는 setSelectionRange 메서드도 존재해요.
setSelectionRange는 WHATWG forms spec에 따라 text, search, url, tel, password 타입에서만 사용할 수 있어요.

🔍 WHATWG란?
WHATWG는 Web Hypertext Application Technology Working Group의 약자로, 웹 표준을 정의하는 그룹이에요.
웹 표준은 브라우저 간 호환성을 보장하고, 웹 개발자들이 참고할 수 있는 명확한 지침을 제공해요.

키보드 사용성을 챙길때 제작한 React.Ref도 있었고, 기본적으로 Input 컴포넌트에서 onFocus 메서드를 지원해주니 포커스 이벤트 발생 시, 커서를 Input 맨 뒤로 이동시키면 되겠다고 판단했어요.

하지만… 예상대로 동작하지 않았어요 🥲

실패 원인 분석

생각을 조금 더 정리해보니, 실패 원인은 브라우저의 렌더링 타이밍에 있었어요.

focus 이벤트가 발생하고 onFocus 핸들러가 호출되는 시점에는 브라우저가 아직 Input의 포커스 상태나 커서 위치 정보를 완전히 반영하지 않은 상태일 수 있어요. 이로 인해 setSelectionRange를 즉시 호출해도 커서 위치가 예상대로 설정되지 않는 문제가 있었어요.

해결방법: setTimeout

저는 해당 문제를 해결하기 위해 setTimeout을 사용했어요. setTimeout는 콜백함수의 실행시점을 현재 실행중인 코드블록 다음 순서로 실행하기 때문이에요.

상세 이유: setTimeout API는 MacroTaskQueue로 분류되어 MicroTaskQueue에 등록된 핸들러가 먼저 실행되어 렌더링 업데이트가 처리된 후 실행되기 때문이에요. 비슷한 원리의 해결방법으론 requestAnimationFrame가 있어요.

const DELAY_TIME = 0;
const INPUT_END_INDEX = inputRef.current?.value.length ?? 0;

const handleFocusToEnd = () => {
    setTimeout(() => {
        inputRef.current?.setSelectionRange(INPUT_END_INDEX, INPUT_END_INDEX);
    }, DELAY_TIME);
}

setTimeout의 delay를 0초로 두고 실행하게되면 Input에 포커스 되고 값이 반영되는 시점 이후의 이벤트 루프에서 코드를 실행하게 되기때문에 커서 위치를 원하는 대로 이동시킬 수 있어요.

마무리

이번 버그를 해결하면서 단순한 커서 위치 조정 문제를 넘어, 브라우저 렌더링 흐름, 이벤트 루프, WHATWG 명세까지 사고를 확장할 수 있었어요. 마이너한 이슈일 수 있지만 생각보다 얻은 지식이 많아서 좋았어요.

yalc를 통해 로컬 패키지를 테스트해보자

Mon, 09 Sep 2024 00:00:00 GMT

배경

회사에서 메인 작업을 진행하던중 기존 DesignSystem(DS)에 존재하던 컴포넌트의 결함 및 DS 컴포넌트를 신규로 제작하는 과업이 생겼어요.
DS 컴포넌트가 메인 작업에서 필요했었기때문에 작업방향은 크게 2가지로 나뉠 수 있었어요.

1️⃣ 메인작업에 쓰일 컴포넌트는 로컬 컴포넌트로 제작하고 추후에 DS에 작업해서 배포하기
2️⃣ DS 컴포넌트를 우선적으로 제작하고 함께 배포하기

저는 로컬컴포넌트로 제작 후 추후 DS로 옮기는것은 비효율적이라고 판단했고, 코드리뷰에서 시간이 조금 걸리더라도 DS 작업을 병렬적으로 가져가는것이 좋다고 판단했어요.

문제지점

위와 같이 의사결정을 한 후, DS 작업을 통해 기존 컴포넌트의 결함 수정 및 새로운 컴포넌트 제작을 진행하였어요.
그러나 작업한 내용을 테스트할 방법이 마땅치 않았어요.

기존에 존재하던 테스트방법은 storybook으로 확인하거나 npm 패키지 배포를 통해 확인하는 방법뿐이였어요. 하지만 발견된 결함은 제품에 결합되었을때 생기는 결함이였기때문에 storybook에서 완벽히 재현할 수 있음을 보장할 수 없었어요.
그래서 로컬에서 테스트해볼 수 있는 방법이 없을까? 하면서 질문을 했더니 yalc라는 라이브러리를 알게되었어요.

yalc란?

yalc는 로컬에서 개발 중인 npm 패키지를 테스트할 때 사용하는 도구로, 패키지를 실제로 npm에 배포하지 않고도 다른 프로젝트에서 설치해서 확인할 수 있게 해줘요.

보통 NPM 패키지를 개발할 때, 아래와 같은 과정을 거치는데요

1️⃣ 패키지 작성 (개발)
2️⃣ NPM에 배포 (npm publish)
3️⃣ 다른 프로젝트에 설치 (npm install)
4️⃣ 테스트 후, 문제가 있으면 다시 수정 후 재배포

하지만, 이 방식은 배포 과정이 필수라서 수정사항이 생길 때마다 NPM에 업로드해야 하는 번거로움이 있어요.

yalc의 경우에는

1️⃣ 로컬 패키지 개발용이성
2️⃣ 변경사항 즉시 적용
3️⃣ NPM보다 간편한 워크플로우

와 같은 차이점이 있기때문에 더 선호되는것같아요.

또한, 기존의 npm link처럼 심볼릭 링크 방식으로 동작하지 않고, ~/.yalc 폴더에 패키지를 패키징한 후 대상 레포지토리에 실제 파일 형태로 저장하기 때문에, node_modules까지 심볼릭 링크를 생성하는 npm link와는 달리 의존성 충돌이나 예기치 않은 문제를 일으키지 않아요.

즉, yalc는 패키지를 일종의 로컬 레지스트리처럼 다루기 때문에 더 안정적이고 예측 가능하게 작동해요.

yalc github

적용방법

yalc는 CLI 커맨드를 통해서 손쉽게 붙일 수 있어요.

설치

글로벌 또는 프로젝트 내부에 설치

$ npm install -g yalc

패키지 버전 변경

yalc가 패키징할 패키지의 버전을 테스트용 버전으로 변경해주세요.
변경된 버전은 추후 설치할 로컬 패키지의 버전이 되어요.

// package.json
{
  "name": "some-package",
  "version": "3.1.5-yalc-test",
  ...
}

패키징

먼저 패키지를 빌드하고 이후 yalc를 통해 패키징 해주세요.

$ npm run build
$ yalc publish {패키지이름} 
# e.g. yalc publish @some-package@3.1.5-yalc-test

패키지 설치

테스트할 프로젝트에서 패키지를 추가해주세요

$ yalc add {패키지이름}
# e.g. yalc add @some-package@3.1.5-yalc-test

잘 설치된 모습

패키지 업데이트

패키지를 수정하고 다시 배포하려면 아래처럼 해주시면 돼요
push를 활용하면 yalc update 하고 yalc publish를 한번에 트리거 할 수 있어요.

$ yalc push {패키지이름}
# e.g. yalc push @some-package@3.1.5-yalc-test

패키지 제거

테스트가 끝났다면 패키지를 제거해야 해요.
제거하지 않으면 추후 실제 배포용 패키지와 충돌이 있을 수 있어요!

$ yalc remove {패키지이름}
# e.g. yalc remove @some-package@3.1.5-yalc-test

마무리

yalc를 활용해서 성공적으로 서비스에 테스트하고 적용할 수 있었어요 ☺️

기존의 npm 패키지 테스트 방식이 비효율적이라고 느껴 더 나은 방법을 찾던 중 알게 된 도구인데, Design System뿐만 아니라 다양한 패키지에도 활용할 수 있어 공유 가치가 높다고 생각했어요. 이 도구를 통해 사내 Frontend 챕터에 공유할 수 있었고, DS 온보딩 문서에도 기여할 수 있어 의미 있는 경험이었어요.

온보딩 문서 기여 성공

구글 번역기 이슈 해결 해보기

Thu, 18 Jan 2024 00:00:00 GMT

배경

사내 오류 지원 채널을 통해 “구글 번역기를 사용하면 서비스 이용 중 화면이 하얗게 사라지는(화이트아웃) 현상” 이 발생한다는 제보를 받았어요. 문제가 발생한 상황은 Chrome 브라우저에서 구글 번역기를만 사용하고 있는 유저가, 특정 조건에서 화면 전체가 화이트아웃 되는 현상이었어요.
처음엔 아무 단서가 없어 당황스러웠지만, 관련 리서치를 통해 재현 조건과 원인을 파악할 수 있었어요.

재현조건

문제를 분석하며 발견한 재현 조건은 아래와 같아요:

부모-자식 관계의 컴포넌트 구조
2개 이상의 자식 노드
Hello World처럼 텍스트만 존재하는 노드가 조건에 따라 제거되는 경우

const [someCondition, setSomeCondition] = useState(true);
<div id="parent">
  {someCondition && 'Hello World'}
  <text onClick={() => setSomeCondition(false)}>Hello</text>
</div>

위와 같은 상황에서 클릭을 통해 someCondition이 false가 바뀐다면 어떻게 될까요?
아래 사진과 같이 에러(화이트아웃)가 나오게 돼요.

구글번역기 동작방식

저는 해당 현상이 리액트보단 구글 번역기의 번역 방식과 더 관련 있다고 판단했어요.

구글 번역기는 페이지 내 텍스트를 감지하고 번역하는 과정에서 다음과 같은 방식을 사용해요:

태그로 감싼 텍스트는 해당 태그 내부의 텍스트만 치환
태그로 감싸지 않은 순수 텍스트는 <font> 태그로 감싼 후 번역된 텍스트로 직접 치환

// AS IS
<div>
  'Welcome'
  <text>Something</text>
</div>

// TO BE
<div>
	<font>'안녕하세요'</font>
  <text>무언가</text>
</div>

이때 실제 번역 과정에서는 removeChild, insertBefore와 같은 DOM API를 활용하여 기존 텍스트를 제거하고 새 엘리먼트를 삽입하게 돼요.

const children = document.getElementById("parent").childNodes;
	for (const myEl of children) {
		if (myEl.nodeType === Node.TEXT_NODE) {
			const fontEl = document.createElement("font");
			fontEl.textContent = myEl.data;
            myEl.parentElement.insertBefore(fontEl, myEl);
            myEl.parentElement.removeChild(myEl);
		}
	}

원인

해당 이슈에 대해서 조금 더 리서치를 진행해보았고 한 Github Issue를 찾았어요. 알고보니 되게 오래된 이슈였고, 논의가 최근까지도 활발하게 진행되고 있었어요. 하나하나 코멘트들을 읽어보니 원인에 대해서 알겠더라구요.

The problem is that Google Translate replaces text nodes with <font> tags containing translations while React keeps references to the text nodes that are no longer in the DOM tree.

구글 번역기는 번역된 텍스트를 <font> 태그로 감싼 후 대체하지만, React에선 더 이상 DOM tree에 없는 텍스트노드에 대한 참조를 계속 유지하고 있기때문이에요.
조건에 의해서 텍스트노드가 갑자기 사라지게될때 이미 DOM tree에서 없어진 텍스트 노드를 리액트에선 계속 참조하고 있기 때문에, 존재하지 않는 텍스트노드에 대해서 계속 메서드(removeChild)를 실행하려고 해서 에러가 발생하게 되는것이에요.

개인적인 생각으로는, React에서 reconcile 과정 이후 변경사항 반영 & 렌더링 해주는 과정에서, 외부요인에 의해 실제론 DOM이 바뀌었으나 리액트에서 참조하고있는 메모리상의 DOM(VDOM)에서는 바뀐것을 인지하지 못해서 에러가 나는것같다고 생각했어요.

근본원인: React vs Chromium

논의가 진행중이던 Github Issue를 조금 더 살펴보니, React 개발자들은 해당 이슈에 대해서 구글 번역기의 동작이 문제인것이라고 판단하고 chromium측에 다시 이슈레이징을 한 상태였더라구요.

그러나 chromium 개발자들은 장문으로 반박하였어요.

요약:
React와 같은 Virtual DOM을 사용하는 라이브러리들은 DOM 노드 참조에 의존하기 때문에 구글번역기 같은 외부에서 DOM을 조작하는 라이브러리와 공존하게 되는경우 에러가 날 수 밖에 없다.
대부분의 VDOM 라이브러리는 자기자신 이외에는 DOM을 수정하는 매개체가 없다는 가정 하에 작성되는 경우가 많다. 외부에서 트리거된 DOM변경작업 이후에도 DOM을 최신 상태로 유지하도록 사전에 모니터링하지 않으면 이 문제는 더욱 악화될것이다.
문제는 자바스크립트 라이브러리가 DOM이 본질적으로 설계상 변경 가능하다는 사실을 고려하지 않고, VDOM 라이브러리들이 DOM에 대한 완전하고 독점적인 제어권을 가지고 있다고 가정할 때 발생한다.
이것은 구글번역기만의 문제가 아닌 매우 일반적인 상황에서도 나타날 수 있으며, 구글 번역기는 한 브라우저의 DOM 수정 기능 중 하나일 뿐 근본적인 문제의 증상을 더욱 명확하게 만들고 있는꼴이다.

chromium측에서는 위와같은 입장을 밝히면서 수정에 대해선 회의적인 입장이였어요. 저도 해당 글을 읽어보면서 공감이 잘 되었기때문에 근본적인 해결방법은 없겠다고 생각했어요.

해결방법

프로덕션 환경에서 실사용자에게 영향을 주는 문제이기에, 임시적이더라도 대응이 필요했어요.
저는 아래 두 가지 방법을 생각했어요:

1. Eslint 커스텀 룰을 통한 사전 차단 태그로 감싸지지 않은 순수 텍스트가 존재하지 않도록 강제하는 방법이에요.

관련 오픈소스: eslint-plugin-sayari
효과적이고 앞으로 발생할 문제를 사전차단 가능하다고 생각했지만 적용 시 1300곳 이상 수정이 필요해 현실적으로 어려웠어요 🥲

2. Monkey Patching을 통한 방어코드 적용 문제가 발생하는 removeChild, insertBefore 메서드 자체를 Monkey Patch 방식으로 오버라이드 해서, 안전하게 동작하도록 만드는 방법이에요.

export const monkeyPatchGoogleTranslatorMethods = () => {
    if (typeof Node === 'function' && Node.prototype) {
      const { removeChild: originalRemoveChild } = Node.prototype;
      Node.prototype.removeChild = function (child) {
        if (child.parentNode !== this) {
          if (console) { logError(child, this) }
          return child;
        }
        return originalRemoveChild.apply(this, arguments);
      };

      const { insertBefore: originalInsertBefore } = Node.prototype;
      Node.prototype.insertBefore = function (newNode, referenceNode) {
        if (referenceNode && referenceNode.parentNode !== this) {
          if (console) { logError(referenceNode, this) }
          return newNode;
        }
        return originalInsertBefore.apply(this, arguments);
      };
    }
  };

다만 Monkey Patching 특성상 서비스 환경에선 위험성이 존재했기 때문에 서비스 환경이 아닌 개발 환경에서만 활성화하여 점진적으로 문제를 개선할 수 있도록 했어요.

마무리

이번 이슈는 단순 버그 수정보다는 얻은게 많았어요. 정확한 재현 조건과 외부 라이브러리 간 충돌 구조를 분석하고, React와 Chromium 개발자들의 기술적 논의와 관점 차이를 직접 확인해보며 많은 것을 배울 수 있었어요. 근본적인 해결은 어려웠지만, 현실적인 대안을 마련하고 서비스 품질을 지킬 수 있었던 점에서 좋은 경험이였던것 같아요 ☺️

참고

Axios Interceptor에서 CustomHook을 사용하는 방법

Thu, 26 May 2022 00:00:00 GMT

이번 포스트에서는 제가 프로젝트를 진행하면서 Axios Interceptor에서 React Hook 및 Custom Hook을 사용하기 위해 고민했던 과정을 소개합니다.

Axios Interceptor에 대해 모르시는 분이 계신다면 아래 링크를 통해 공부해 보시길 권장 드려요

한글문서

📌 개요

저는 Axios Interceptor를 통해 AccessToken이 만료되었을 때 토큰을 재발급 받아오는 용도로 사용하곤 했었습니다. 그러나 이번 프로젝트에서는 위와 같은 기능에 그치지 않고 Toast 팝업을 직접 만들어서 API 통신 성공/실패 시 자동으로 팝업을 띄워 유저가 확인할 수 있게 하고 싶었습니다. 아래와 같이 말이죠

🔥 기존 코드의 문제점

먼저 Toast 팝업을 만들기 위해 해당 게시글을 참고해서 만들었습니다. Recoil 과 setTimeout을 사용해 Custom Hook(useToast)으로 Toast 팝업을 사용할 수 있었는데요, 여기서 문제점이 생깁니다.

기존 제 Axios Interceptor 코드는 libs/axios 폴더에 axios.ts에 위치해있어서 React의 바운더리 밖에있기때문에 custom hook을 사용할 수 없는 구조로 되어있었습니다.

// libs/axios/axios.ts

const requestHandler = async (config) => {
	if(accessToken && refreshToken) {
    	if(decodedToken.exp < currentDate) {
          try {
            const new_token = await getTokenReissuance({token: accessToken});
            localstorage.set("accessToken", new_token);
            accessToken = new_token;
          } catch(error) {
          	console.error(error);
          }
        }
      config.headers!["token"] = accessToken;
    }  
  return config;
}

const customAxios = axios.create({
	baseURL: "url",
	headers: {
    	"token": localstorage.get("accessToken"),
    }
});

customAxios.interceptors.request.use(requestHandler);

export default customAxios;

이런 구조에서 useToast 를 선언해 Toast 팝업을 띄우려면 어떻게 해야 할까요? 저는 고민하다가 2가지 해결 방안을 생각했습니다.

Axios Interceptor를 Custom Hook 형태로 만들어서 사용해 보자

Provider 컴포넌트를 제작해서 Root에서 주입할 수 있도록 해보자

2가지 방법 중에서 1번, Custom Hook 방식을 선택해서 적용해 보았는데요. 1번 방식을 선택한 이유는 다음과 같습니다.

루트에 컴포넌트를 감싸는 형태는 조금 더러워 보였다.
Custom Hook으로 만들어서 사용하는 것이 조금 더 React스럽다.

🐬 적용

저는 useAxiosInterceptor 라는 네이밍으로 Axios Interceptor를 선언하고 custom Hook을 사용했습니다.

// hooks/useAxiosInterceptor.ts
import { customAxios } from "libs/axios/axios.ts";

export const useAxiosInterceptor = () => {
  // requestHandler는 위와 같은 로직이기에 생략.
  const { fireToast } = useToast();

  const errorHandler = (error) => {
    let msg = error.message;
    fireToast({ content: ` ${msg} 🔥 `, duration: 2000 });
  };

  const responseHandler = (response) => {
    return response;
  };

  const responseInterceptor = customAxios.interceptors.response.use(
    (response) => responseHandler(response),
    (error) => errorHandler(error.response.data),
  );

  const requestInterceptor =
    customAxios.interceptors.request.use(requestHandler);

  useEffect(() => {
    return () => {
      customAxios.interceptors.request.eject(requestInterceptor);
      customAxios.interceptors.response.eject(responseInterceptor);
    };
  }, [responseInterceptor, requestInterceptor]);
  
};

하지만 이렇게 만든 custom Hook을 어디에서 선언해서 사용해야 할까요?
저는 해당 Hook을 한 페이지에서만 사용하게 되면 다른 페이지에서 API를 호출할 시에는 적용되지 않게 되고, 여러 곳에 선언해서 사용하자니 코드 중복 및 토스트가 여러개뜰 수 있다고 생각했습니다.

그래서 저는 Layout과 같은 Global 한 컴포넌트에서 선언하면 괜찮지 않을까?라고 생각했고 적용해 보았더니 정상적으로 작동하는 것을 확인할 수 있었습니다.

// src/common/Layout/index.tsx
import { Header } from 'Header';
import { useAxiosInterceptor } from 'hooks/useAxiosInterceptor.ts';

export const Layout = ({ children }) => {
  useAxiosInterceptor(); // AxiosInterceptor 선언

  return (
    <>
      <Header />
      {children}
    </>
  );
};

마치며

Axios Interceptor에 Custom Hook 및 React Hook을 사용하기 위해 고민했던 과정들을 소개하며 useAxiosInterceptor Hook을 만들어보았습니다.

기존에는 Token Controll만 담당하던 Interceptor를 확장해서 생각해서 다른 사용성을 보여준 좋은 사례라고 생각합니다. 더 나은 구현방법이 있을것같은데 떠오르는 방법은 2가지였어서 작성해보았습니다.

학교에서도 해당 내용을 주제로 발표했었는데 친구들에게 도움되어서 기분이 좋았습니다 ㅎㅎ

Reference

GroupBy 인턴십 프로그램 후기

Fri, 04 Mar 2022 00:00:00 GMT

현재는 나비효과라는 기업이 없어져서 홈페이지나 앱이 모두 없어졌습니다.

💡 그룹바이란?

그룹바이는 시리즈 A 이하의 초기 스타트업과 주니어 개발자가 함께 성장하는 과정을 만드는 스타트업을 위한 스타트업입니다. 저는 그룹바이의 인턴쉽 매칭 프로그램에 참여하여 스타트업 나비효과에 인턴으로 합격하였습니다. 이 글에서 2달간의 인턴십 경험을 풀어보려고 합니다.

🦋 스타트업 나비효과

제가 합격한 기업인 나비효과는 크리에이터 중심의 커머스로써, 현재의 정보 과잉 시대에서 소비자들이 좋은 상품 및 스타일을 찾기 위해 쇼핑에 들이는 시간을 절약해 주고 더 가치 있는 일에 시간을 쓰게 하자는 비전을 가지고 있는 기업입니다 🔥

이러한 비전을 가진 나비효과에서는 봄봄이라는 앱을 서비스하고 있습니다.

1. 그룹바이 공고 📌

일과 후 페이스북을 보던 중 우연히 해당 포스트를 보게 되었습니다. 마침 겨울방학이 다가오고 있었기도 하고, 고등학생 개발자인 저한테 정말 좋은 기회라고 생각되어서 고민하다가 바로 지원하게되었습니다. 모두 다 뽑히는것은 아니고 서류 전형이 있어서 저는 노션으로 작성한 이력서를 제출했어요.

2. 매칭 데이 👨‍💻

그룹바이 매칭 프로그램에서는 여러 스타트업들 중에서 자신에게 맞는 스타트업 15곳을 추천해 줍니다. 또한 각 기업별로 최소 30분씩미팅을 할 수 있게 해줍니다.

저는 여러 기업들 중 대략 10곳의 기업에 미팅을 신청하였습니다. 미팅은 줌으로 진행되며 저와 같은 프로그램 신청자들과 함께 미팅을 진행했습니다 🙋

줌을 통해서 기업들은 간단하게 어떤 비전을 가지고 일하고 있는지, 지원자분들에게 기대하고 있는 점들은 어떤것이 있는지 알려주시고 지원자와 Q&A 형식으로 시간을 보냈습니다.

3. 직무 면접 💻

저는 신청한 10개의 기업들과 미팅을 거친 후, 최종적으로 4곳에 지원을 하였습니다. 최종적으로는 그중 한곳에 합격하게 되었습니다.

합격하면 메일을 통해 면접 일정 조율이 이루어집니다(평균적으로 메일 수신 1~2주 내외)

그룹바이측에서 지원자와 기업 사이에서 빠르게 핑퐁이 이어질 수 있도록 많은 노력을 해주십니다.

저는 대구에서 서울로 가야했었기때문에 1주일후에 면접일정을 잡았었고, 면접은 개발자분들 및 대표님과 3 대 1로 진행되었습니다.

면접에서는 대부분 제 이력서를 기반으로 해서 질문을 하셨습니다
직무 부분에서는 React, Javascript 관련한 깊은 개념을 물어보셨고
프로젝트에서 활용한 기술을 사용한 이유 및 어떻게 활용했는지 등을 구체적으로 물어보셨습니다.
확실히 학교에서 동아리 활동한 것, 해커톤 했던 경험, 기초 공부한 것 등이 많이 도움 된 것 같아요!

직무면접 후, 다음날에 대표님의 전화로 바로 합격 소식이 들려왔습니다! 🎉

4. 합격 이후 🙌

인턴십에 합격해 학생이 아닌 프론트엔드 개발자로써 일을 하게 되었습니다.
회사에서 온보딩부터 시작해 스타트업에서 할 수 있는 여러 경험들을 팀원분들과 함께하며 성장하고 있습니다.

또한, 일적인 요소 말고도 사회생활에 대한 해봐야만 알 수 있는 것들에 대한 부분에서도 많은 도움이 되어서 정말 좋았습니다 :)
서울, 자취, 사회생활 모든것이 처음인 저를 잘 적응할 수 있게 해주신 팀원분들에게 정말 고맙다고 생각해요

5. 마지막으로

그룹 바이 매칭 프로그램을 우연히 보았지만 많은 고민을 했습니다.

학생인데 잘할 수 있을지
기업에서는 나이가 어리다고 싫어하진 않을지
가서 잘할 수 있을지

이런 고민들이 있었지만,
어차피 언젠가는 경험해야하고 일찍할수록 좋다라는 생각이 들었고 저는 용기내서 지원했던것 같습니다. 자신감을 가지고 일단 시도해보면 뭐든 얻는게 있는것 같아요 :)

6. 여담 🐳

저는 현재 2달간의 인턴십을 무사히 마치고 다시 학교에서 열심히 공부하고 있습니다. 더 잘하는 개발자가 되어서 재취업해보려고 합니다!

2021.Clzzi.log

Tue, 21 Dec 2021 00:00:00 GMT

2021년도 1주일밖에 남지 않았기 때문에 고등학교 2학년이자 프론트엔드 개발자로써의 올해를 회고하고 되돌아보는 시간을 가져봅니다.

열심히 달려왔던 2021년

2021년은 B1ND 팀 활동, 해커톤, 공모전, 인턴 준비, 포트폴리오 준비 등 목표를 설정하고 달성하기 위해서 쉴 틈 없이 꾸준히 무언가를 하려고 했던 해 같아요😁

B1ND팀

2020년 말에 교내 동아리인 B1ND 팀에 입사하게 되고, 그 후 겨울 및 봄 방학 동안 인수인계를 받게 되었습니다.
교내에서 서비스되고 있는 프로젝트를 인수인계 받고 기능 개발에도 참여했습니다.

B1ND팀은 학생 생활 관리 플랫폼인 도담도담이라는 서비스를 비롯해 교내 프로젝트를 운영하는 팀 입니다.

도담도담 서비스를 운영하면서 크고 작은 이슈들을 해결하였는데 그중에는 렌더링 최적화한 작업이 가장 기억에 남는 거 같아요.

추가로 나르샤 프로젝트로 모람모람이라는 팀 빌딩 서비스를 기획하여 개발했습니다. 부족한 점이 많아 기획부터 엎고 다시 작업하기를 반복하며 거의 7개월간 개발을 했어요 ㅜㅜ
개발 도중에 팀원의 이탈로 골머리를 앓았던 적도 있고, 커뮤니케이션이 원활하지 않아서 개발했던 것을 또 해야 하는 상황도 있었습니다😥

결과적으로는 성공한 프로젝트라고 말할 수는 없지만.. 개발 실력이나 정신적으로 많이 성장해서 저는 만족해요!

모람모람과 도담도담을 ICT 공모전에 출품하였고 3일간 전시하며 발표도 했습니다. 학교 사람들이 아닌 외부인에게 서비스를 소개하고 시연하는 것이 생각보다 어려웠지만 재미있었어요! 잊지 못할 추억이 될 것 같아요 ☺️

2학년 2학기가 되면서 후배들이 B1ND 팀에 입사를 하게 되었고, 1년 전에 제가 받았던 것처럼 인수인계를 해주려니 감회가 새로웠어요.

3학년이 되면 팀 활동보다는 취업 준비를 해야 하기 때문에 인수인계만 하고 나가야 합니다.

인턴준비

저희 학교에서는 2학년 2학기부터 인턴으로 일할 수 있게 되어있어요, 그래서 저도 프론트엔드 분야에 인턴으로 일할 곳을 찾고 있었고 운 좋게 그룹바이라는 프로그램에 참여하게 되었어요!

노션으로 포트폴리오를 만들어 그룹바이에 지원해서 4개의 기업에 지원을 넣었습니다. 2곳에서는 탈락하였고, 최종적으로 1곳에 면접을 보러 가게 되었습니다.

면접에서는 커피챗느낌으로 면접을 보았고 기술적인 부분 조금과 인성 면접을 위주로 진행했어요.
서울도 처음 간 것이고 채용 면접도 처음이라서 엄청 떨렸지만 여유롭게 보자고 마인드 컨트롤 했어요 ㅎㅎ
바로 다음날 대표님이 전화로 합격 소식을 알려주셔서 정말 기뻤습니다 😎

인턴으로 일하기 위해서 글을 쓰는 지금도 자취방을 알아보고 있어요! 이번 주 내로 계약하고 서울로 올라갈 예정이랍니다 ㅎㅎ

그 외

인턴과 B1ND 팀 활동 외에도 해커톤이나 공모전, 개인 프로젝트 등 여러 가지 활동한 것이 많았어요!

교내 여름 해커톤에서 금상도 타고, 연합해커톤에서 다른 마이스터고 학생들과 한글코딩 및 라이브쉐어 조합으로 협업도 해보고, 개인 프로젝트로 실 서비스까지 진행해 보았어요!

DGIT

DGIT은 학생들의 경쟁심리를 자극해 더 나은 개발 문화 및 동기부여의 목적으로 개발한 프로젝트에요.
프로젝트를 진행하면서 전에는 해보지 못한 테스팅과 반응형, CI/CD, 배포까지 진행하면서 더 애착이 가는 프로젝트랍니다😊

DGIT이 궁금하시다면 레포지토리를 방문해주세요!

마무리

올해는 잊지 못할 많은 일들이 있었어요, 힘들기도 했지만 다 자양분이 된다고 생각하면서 노력했던것같아요.
2021년도 알차게 보낸것같습니다!

올해의 흔적들

DGIT / 연합해커톤 / 공부한것들 / 깃허브 / 교내해커톤 / ETC