들어가며..

2024년도 벌써 끝나가고, 제가 저희 회사에 온지 8개월이란 시간이 지났는데요. 한 해를 돌아보면 ‘올해는 정말 많은 일들이 있었구나’라는 생각이 듭니다. 연말을 맞이해서 어떤 변화가 있었는지 정리해보는 시간을 가져보려고 합니다.

기억에 남는 회사업무 3가지 💬

8개월이라는 시간이 그리 긴 시간은 아니었지만, 신규 페이지 개발부터 버그 수정, 리팩토링까지 다양한 업무를 경험했습니다. 이전 회사에서는 주로 신규 서비스를 만드는 데 집중했다면, 이번에는 이미 운영 중인 서비스를 개선하고 안정화하는 경험을 쌓을 수 있었는데요. 이와 관련해서 업무 난이도와 상관없이 가장 기억에 남는 것들을 정리해보았어요.

1. axios 인터셉터 개선

제가 회사에 들어오고나서 가장 먼저 맞닥뜨린 이슈가 로그인이 유지되지 않는다는 인증관련 오류였어요. 모바일 웹에서 ‘로그인 유지’를 눌러서 로그인했는데도, 시간이 지나서 로그인이 풀려있다거나 특정 상황에서 인증 에러가 빈번하게 발생했거든요.

기존 시스템을 파악해보니 정말 복잡하게 얽혀있었습니다. 가장 눈에 띈 건 각 페이지마다 에러를 따로따로 처리하고 있다는 점이었어요. CallApi라는 클래스에 수백 줄의 if-else문으로 "이 페이지에서 이 에러코드가 나오면 이렇게 처리해라"는 식으로 하드코딩되어 있었거든요.

// 기존: callApi 구현
class CallApi {
  async request(
    url: string,
    method: string,
    params?: any,
    data?: any,
    signal?: any
  ) {
    try {
      const res = await instance({
        url,
        method,
        params,
        data,
        signal,
      });
      return res?.data?.data;
    } catch (err: any) {
// 공통에러처리
}
}

// 기존: 각 컴포넌트에서 개별 처리
const handleSubmit = async () => {
  try {
    const result = await callApi.request('/api/product', 'POST', data);
    // 성공 처리
  } catch (error) {
    // 여기서 또 에러별 분기 처리...
  }
};

그리고 axios 인스턴스도 일관성이 없었어요. 어떤 곳에서는 공통 인스턴스를 쓰고, 어떤 곳에서는 그때그때 새로 만들어서 쓰고... 이러다 보니 인증 헤더가 빠지거나 설정이 달라지는 경우가 생겼죠. tanstack query 같은 서버 상태 관리 라이브러리도 제대로 사용하지 않고 있어서 useState나 redux로 API 응답을 관리하는 경우도 있었고, 같은 API가 여러 번 호출되는 문제도 자주 발생했어요.

제가 이를 확인하고 가장 먼저 한 일이 서비스에서 axios 인스턴스를 단일로 사용할 수 있도록 개선하고, 인터셉터를 사용하여 인증로직을 공통화하는 작업이었어요. 이렇게 새로운 axios 인터셉터 구조로 개선하면서 인증과 관련된 로직들을 중앙집중화할 수 있었어요


// 1️⃣ 단일 axios 인스턴스 생성
const instance = axios.create({
  baseURL: process.env.REACT_APP_REQUEST_DOMAIN,
  withCredentials: true,
  timeout: 40000,
});

// 2️⃣ 요청 인터셉터 - 모든 요청에 공통 로직 적용
function setupRequestInterceptor() {
  instance.interceptors.request.use(config => {
    // 모든 요청에 인증 헤더 자동 추가
    config.headers = {
      ...config.headers,
      ...getAxiosRequestHeaders(), // 토큰 등 인증 정보
    };
    return config;
  });
}

// 3️⃣ 응답 인터셉터 - 에러 처리 및 토큰 갱신
function setupResponseInterceptor() {
  instance.interceptors.response.use(
    response => response,
    async (error) => {
      // 중복 요청 에러 처리
      // 재시도 로직 (횟수 제한)
      // 토큰 갱신 로직
      // 401 에러 시 자동 로그인 페이지 이동
    }
  );
}

또한 tanstack query를 적극적으로 도입해서 서버상태관리를 개선했고, 사용 빈도가 높은 페이지들부터 점진적으로 리팩토링을 진행했어요.

서비스의 페이지가 너무 많아서 기존의 코드를 다 바꾸지 못했지만, 중요한 페이지 위주로 작업한 결과 로그인과 관련된 문제가 현저하게 줄었어요.

하지만 여전히 비동기 처리는 가장 어려운 영역이라고 생각해요. 서버로 중복 요청을 보내면 안 되고, 인증과도 얽혀있고... 이전보다는 많이 나아졌지만 더 좋은 방법이 있지 않을까 뭔가 아쉬움이 많이 남아서 비동기 처리에 관한 로직들을 지속적으로 살펴보려고 해요.

2. 화면 최대 너비 지정 - "작은 제안으로 서비스 개선하기”

올해 가장 기억에 남는 작업은 바로 화면 최대 너비 지정 작업이었어요.

이전까지 저희 서비스의 모바일 웹은 모바일 반응형 작업을 해주지 않아 화면을 끝까지 다 채우는 구조였는데요, PC 환경에서 개발할 때마다 UI가 과도하게 늘어지면서 불편함을 느꼈거든요.

저희 서비스는 PC버전이 따로 있다 보니 다른 분들은 이 부분에 대해서 문제라고 인식하지 않아 이 상태를 계속 유지하고 있었어요. 하지만 PC 버전은 유지보수가 오래된 PHP 로직을 가지고 있고, 가끔 느리거나 기능이 잘 안될때가 있는데요, 그러면 CS팀에서 유저분들께 모바일 주소로 해당 기능을 사용하라고 안내드릴때가 종종 있더라구요.

자주 있는 일은 아니지만 유저분들께 이렇게 늘어진 UI를 맞이하게 하는건, 제가 개발할 때 느끼는 불편함을 유저분들이 똑같이 느끼게 된다는 생각에 불편했습니다. 그래서 저는 팀에 무신사, 카카오패션 등 여러 레퍼런스를 조사해서 화면 최대 너비를 지정하여 데스크톱 웹에서 접속해도 모바일 UI가 틀어지지 않는 방안에 대해 제안했습니다.

단순해 보이는 작업이었지만, 실제로 적용해보니 예상치 못한 문제들이 발생했어요. 가장 큰 문제는 모달이나 사이드바 컴포넌트들이 새로 설정된 영역이 아닌 기존 전체 화면 영역을 기준으로 동작하는 것이었습니다.

/* 메인 컨테이너에 max-width 적용 */
.container {
   max-width: var(--size-max-width);
}


/* 모달들은 여전히 100vw를 기준으로 동작 */
.modal {
  position: fixed;
  left: 50%;
  transform: translateX(-50%); /* 전체 화면 기준 */
}

기존에 모달이나 팝업 컴포넌트들이 공통화되지 않아서 각 페이지마다 개별적으로 구현되어 있었고, 카카오 주소 검색 같은 외부 라이브러리를 사용한 모달들도 같은 문제를 겪었거든요.

그래서 전체 서비스를 하나씩 점검하면서 수정 작업을 진행해야 했는데, 서비스 곳곳에 존재하는지도 몰랐던 페이지들을 발견하기도 했고, 각각 다르게 구현된 모달들을 찾아내느라 생각보다 시간이 많이 걸렸어요. 하지만 그 덕분에 구버전의 모달들을 공통 컴포넌트로 통일하는 작업도 함께 진행할 수 있었습니다.

이 작업이 기억에 남는 이유는 기술적 난도는 높지 않았지만 서비스 전반에 미치는 임팩트가 컸다는 점입니다. 사용자들의 반응도 좋았고, 무엇보다 개발하면서 계속 불편하다고 느꼈던 부분이 깔끔하게 해결되어서 개인적으로 만족스러웠어요. 작은 제안 하나가 서비스 개선으로 이어진 경험이라서 더욱 기억에 남습니다.

3. FSD를 활용한 파일구조 리팩토링

처음 회사 프로젝트를 맡았을 때, 파일 구조가 제대로 정리되어 있지 않은 상태였는데요. 아토믹 패턴을 기반으로 컴포넌트 폴더를 정리하려던 흔적은 보였지만, 이전 개발자분이 불편함을 느꼈는지 최근 생성된 파일들은 아예 루트에 나와있기도 하고, 아토믹 구조도 제대로 적용되지 않아서 결과적으로 일관된 구조가 없는 상태였어요.

이 프로젝트를 이어받아서 작업하려면 구조부터 바꿔야겠다는 생각이 들었습니다. 하지만 프론트엔드 개발자 혼자서 프로젝트 구조를 처음부터 설계하고 모든 상황에 대응하는 규칙을 만드는 건 리소스를 너무 낭비한다고 판단했어요. 아토믹 디자인처럼 컴포넌트 단위로만 분류하는 방식도 검토했지만, 신규 기능이 추가될 때마다 파일이 어디에 들어가야 하는지 기준이 흔들리는 문제가 반복될 것 같았어요.

그래서 문서화가 잘 되어 있고, 실제 프로젝트 레퍼런스도 찾을 수 있었던 FSD(Feature-Sliced Design)에 관심을 갖게 되었습니다.

FSD 적용의 어려움

FSD는 레이어 간 의존성 방향을 단방향으로 고정하기 때문에, 이론적으로는 "어떤 파일이 어디에 들어가야 하는가"에 대한 명확한 기준이 생겨서 문서만 봤을때는 어렵지 않아 보였어요.

막상 프로젝트에 적용해보니 달랐습니다. 처음에는 FSD 이론대로 기능별로 잘게 쪼개는 방식으로 구현했어요.

src/
├── entities/
│   ├── product/
│   │   ├── product-edit
│   │   ├── product-register
│   │   ├── product-stock
│   └── order/ 
│
├── features/
│   ├── product/
│   │   ├── product-edit
│   │   ├── product-register
│   │   ├── product-stock
│   └── order/

그런데 도메인이 늘어날수록 같은 기능인데도 entities, features, widgets에 흩어져 있게 되었어요. 상품 하나를 수정하려면 세 폴더를 오가야 하는 상황이 생기더라구요. 구조를 위한 구조가 되는 느낌이었고, 오히려 개발 속도가 느려지는 시점이 왔습니다.

현장에서 얻은 힌트

마침 그 때 제가 재직자 부트캠프를 진행하고 있었는데 다른 개발자들과 토론하며 많은 인사이트를 얻을 수 있었어요. 특히 실제로 FSD를 대규모 프로젝트에 적용 중인 멘토님께 이 고민을 털어놨는데, 이때 돌아온 답이 인상적이었습니다.

"FSD를 그대로 쓰는 것보다, 프로젝트 특성에 맞게 변형해서 쓰는 게 더 중요해요. 정답이 있는 게 아니에요"

이 한마디에서 매우 큰 영감을 받았습니다. 그래서 FSD의 레이어 개념은 유지하되, 도메인을 먼저 묶고 그 안에서 레이어를 나누는 방식으로 변형해서 적용했습니다.

src/pages/
├── product/              # 상품 도메인
│   ├── entities/
│   │   ├── api/         
│   │   ├── model/       
│   │   └── ui/          
│   ├── features/
│   ├── widgets/
│   └── pages/
│
└── order/               # 주문 도메인
    ├── entities/
    ├── features/
    ├── widgets/
    └── pages/

이렇게 하니 상품 관련 코드는 product/ 안에서, 주문 관련 코드는 order/ 안에서 찾을 수 있게 되었어요. 파일을 어디에 둘지 고민하는 시간이 눈에 띄게 줄었고, 신규 기능을 추가할 때 기존 코드에 미치는 영향 범위도 예측하기 쉬워졌습니다. 이 경험을 정리해서 부트캠프에서 발표도 진행했어요.

지금도 경계가 모호한 케이스가 생기면 잠깐 고민하게 되지만, "일관된 기준으로 판단할 수 있다"는 것 자체가 이전과 가장 달라진 점입니다. 정답이 없는 영역일수록, 팀 상황과 프로젝트 특성에 맞는 기준을 직접 세워보는 경험이 중요하다는 걸 배웠어요.

올해의 성장

항해99 재직자 부트캠프 - "생각보다 훨씬 값진 경험"

올해 가장 큰 성장의 계기가 된 것은 항해99 재직자 부트캠프 참여였어요. 혼자 일하게 된 환경을 극복하기 위해 재직자 부트캠프를 신청하게 되었는데, 결과적으로는 정말 잘한 선택이었습니다. 단순히 새로운 기술을 배우는 것이 아니라, 체계적으로 정리된 커리큘럼을 통해 기존에 알고 있던 내용들도 다시 한 번 정리할 수 있었어요. 특히 "이걸 왜 이렇게 하지?"라고 막연하게 생각했던 부분들이 명확해졌습니다.

실무에서는 당장 서비스가 돌아가게 만드는 것이 우선이다 보니, 기본 개념을 깊게 파기 어려운 경우가 많았는데, 부트캠프에서는 "왜?"에 대한 답을 찾는 시간을 가질 수 있었어요.

하지만 무엇보다 가장 값진 경험은 다른 회사 개발자들의 고민과 생각을 들을 수 있었다는 점입니다.

"우리 회사만 이런 문제가 있나?"라고 생각했던 것들이 사실은 어디서나 겪는 공통적인 고민이었다는 걸 알게 되었어요. 상태관리를 어떻게 할지, 컴포넌트 구조를 어떻게 잡을지, 테스트 코드는 어디까지 작성할지... 이런 고민들이 저만의 것이 아니었더라구요. 앞서 언급한 FSD 아키텍처 적용도 다른 개발자들과의 토론을 통해 많은 힌트를 얻을 수 있었습니다.

마지막에 커뮤니케이션상을 받게 되었는데, 모르는 걸 적극적으로 질문하고, 다른 분들과 활발하게 소통했던 것들이 인정받은 것 같아서 뿌듯했습니다.

개발자로서 기술적 역량뿐 아니라 협업 능력의 중요성을 다시 한번 되새기는 계기가 되었습니다

컨퍼런스 참여 - "시야를 넓히는 시간"

올해는 의도적으로 FEConf, Google DevFest 등 여러 컨퍼런스에 참여해봤습니다.

다양한 회사에서 문제를 어떻게 정의하고 해결하는지, 그리고 최신 기술 트렌드를 실무에 어떻게 적용하는지 파악할 수 있는 기회였어요. 실무에만 몰두하다 보면 시야가 좁아질 수 있는데, 컨퍼런스를 통해 '아, 이런 방법도 있구나!'라는 영감을 얻을 수 있었어요.

리팩토링 2판 - "이론의 뿌리 만들기"

이전에 결합도와 응집도에 대해서 질문을 받은 적이 있었어요. 실무에서는 결합도와 응집도를 고려해서 코드를 작성하려고 노력하는데도, 막상 "설명해보세요"라는 질문을 받으면 너무 장황하게 설명하게 되더라구요. 이 경험을 통해 이론적 기반이 부족하다는 생각이 들어서 이 책을 읽게 되었어요.

막상 읽어보니 객체지향, 클래스 중심의 내용이 대부분이어서, 함수형 패러다임인 React에서 직접 적용하기는 어려운 부분들이 많았어요. 하지만 함수 추출, 변수명 개선 같은 미시적 관점에서의 개선 방법들은 충분히 도움이 되었고, 무엇보다 리팩토링에 대한 체계적인 사고를 배울 수 있었어요.

특히 서비스 운영에서 리팩토링은 피할 수 없는 일인데, "언제, 어떻게, 왜"에 대한 명확한 기준을 갖게 된 것이 가장 큰 수확이었습니다.

이직과 항해99 등으로 바쁜 시기여서 좀 오래 걸렸는데요, 책을 읽는 것보다 이 내용들을 내 것으로 만드는 게 더 중요하다고 생각해서 두고두고 다시 읽을 계획입니다.

간단히 훑어본 올해의 다른 것들

🏃‍♂️ 올해의 건강

어느날 갑자기 몸을 움직이기가 힘들어서 정형외과에서 도수치료를 받았어요.. 물리치료사선생님이 놀라실 정도로 등근육이 뭉쳐있었는데 이를 계기로 스트레칭의 중요성을 깨닫게 되었습니다..

그리고 스플릿 키보드를 갖게 되었는데, 선물로 받아서 더 의미가 있었습니다. 이쁜 키캡도 사고 너무 좋았습니당

✈️ 올해의 여행

올해는 남해, 경주, 푸꾸옥 등 여행도 많이 다녀왔어요 :)

🧾 올해 정산하기 (총평)

잘한 것들 ✅

이직을 통한 새로운 경험: 이커머스 서비스 경험을 쌓을 수 있었고, 서비스 운영의 현실적인 부분들을 많이 배웠어요
성장을 위한 의도적 노력: 항해99, 컨퍼런스 참여, 기술 도서 읽기 등 인풋을 늘리려고 노력했어요
팀 내 신뢰 구축: 새로운 환경에서 빠르게 적응하고 동료들과 좋은 관계를 만들 수 있었어요

아쉬웠던 것들 ❌

계획성 없는 소비: 예산 관리를 좀 더 체계적으로 했으면 좋았을 것 같아요
깊이 있는 학습 부족: 당장 필요한 것들 위주로만 공부하다 보니, 기본기나 CS 지식 같은 부분이 소홀했던 것 같아요

🎯 2025년을 향한 다짐

회사 업무에서

상품등록 페이지 고도화: 상품등록페이지가 우리 서비스에서 굉장히 중요한 부분인데, 더 나은 사용자 경험을 만들어보고 싶어요
비동기 처리 완전 정복: 올해 개선했지만 아직 마음에 들지 않는 부분들을 내년에는 확실히 해결하고 싶어요

개발 역량에서

기술 도서 꾸준히 읽기: 클린 아키텍처, 오브젝트, 자바스크립트 딥다이브 등 읽고 싶은 책들이 쌓여있어서 이 책들을 꾸준히 읽으려고 합니다.
CS 지식과 알고리즘: 매번 미뤘던 부분들을 내년에는 조금씩이라도 진전을 만들어보려고 해요

개인적인 부분에서

건강 관리: 운동을 더 규칙적으로 하고, 체중 관리도 좀 더 계획적으로 해보려고 해요
예산 관리: 올해 돈을 좀 많이 쓴거 같아서 목표를 정하고 그 안에서 생활하는 습관을 만들어보려고 해요

마치며

올해를 한 문장으로 정리하면 "새로운 환경에서 적응하며 성장의 기반을 다진 해"였던 것 같아요.

완벽하지 않았고, 아쉬운 부분들도 많지만, 분명히 성장하고 있다는 느낌은 받고 있어요. 특히 문제를 체계적으로 해결하는 능력이나 팀워크, 새로운 기술에 대한 학습 의지 같은 부분들에서는 확실히 발전했다고 생각해요.

무엇보다 올해는 혼자가 아니라는 걸 많이 느꼈어요. 항해99에서 만난 동료들, 새로운 회사의 팀원들, 컨퍼런스에서 만난 개발자들... 비슷한 고민을 하고, 함께 성장하려는 사람들이 이렇게 많다는 것 자체가 큰 힘이 되었습니다.

내년에는 이런 자기 인식을 바탕으로 장점은 더 키우고, 단점은 보완하는 방향으로 성장해보려고 해요. 특히 당장 효과가 없어 보여도 기본기를 탄탄히 하는 시간을 의도적으로 만들어보려고 합니다.

이 글을 읽어주신 분들도 새해에는 더 큰 성장과 행복한 개발 생활이 되시길 바라요. 언젠가 어디선가 만나서 서로의 성장 이야기를 나눌 수 있다면 좋겠습니다.

2025년도 화이팅! 🚀

감사합니다! 😊

[2024년 연간회고] 새로운 회사에서의 적응과 성장