테스트 코드.. 🖥️

정말 궁금했다.
테스트 코드는 한 번도 작성해본 적이 없기 때문에 어떻게 작성하는 것이 바람직한거고 어떤 것들을 이용하는지도...
그리고.. 내가 좋아하는 코치의 챕터이기도 해서 더욱 기대가 됐다.

과제는 3개의 난이도로 구성이 되어있었다. Easy, Medium, Hard.
그리고 AI를 사용하지 말자. AI 사용 없이 테스트 코드를 작성해보자는 제한이 있었다.

괜찮을거라고 생각하고 망설임 없이 Hard 를 골랐고. FAIL 을 받았다.

처음 테스트 코드를 작성하다 보니까 방식을 어떻게 가져가야 할지에서 시간을 좀 잡아먹혔다는 생각이 든다.

또, 이번 주는 회사에서 긴급 패치를 두 번이나 진행이 돼서…. 너무나…. 바쁜 주간이었다. 과제고 뭐고 정신을 쓸 겨를이 없었다.
그래서 다른 사람들과 24시 카페에서 모각코를 했으나 ㅠㅠ... 그치만 다른 좋은 추억이 생겼다.

그리고 나에 대한 과대평가 (Hard를 고른)가 fail의 가장 큰 원인이지 싶다.. 겸손해야겠다... 아니면 더 노력해야하는 게 맞겠지. 둘 다 해야겠다 ㅎㅎㅎ

다음 주차는 꼭 다시 Pass를 받을 수 있도록!..

이번주는 6기 수강생들과 외부 활동(?)이 많은 주 였다. ㅋㅋㅋㅋㅋ
재밌었고 즐거웠다. 사람들이 다 유쾌해서 좋다.
특히 이번 주 개인적으로 힘들었는데 유쾌한 사람들이 있어서 매몰되지 않게 만들어준 거 같다.

감사하다. 🙇

---

MSW(Mock Service Worker) ❓

MSW(Mock Service Worker)의 처음 존재를 알게 된 건 1주차 과제에서 알게 되었습니다.

그 때는 SPA 구현이 우선이라 테스트에 필요한 라이브러리 정도로만 알고있었습니다. 해당 라이브러리의 기능을 전혀 모르고 있었습니다.
이번 주차 과제에서 msw 의 활용에 대해 쓰려고 했으나 방향을 바꿔 개념 정리를 해봤습니다.

가보시죠!

Mocking 👯‍♂️

Mockig 이라는 개념에 대해서 설명하자면 '진짜가 아닌 가짜를 흉내 내는 것' 이라고 할 수 있습니다. 그럼 FE에서는 어떤 가짜를 흉내낼 수 있을까요?..
3.. 2... 1 💥

바로 실제 서버나 외부 의존성 없이 가짜 데이터를 흘려 보내는 것 을 말할 수 있겠습니다. 그럼 가짜 데이터를 과연 언제 쓸까요?

Mock 데이터를 쓰는 상황 👨‍💻

1. 백엔드가 아직 준비 안 됐을 때

   • 프론트엔드 개발이 서버 개발보다 빨리 시작되면, API 응답을 흉내 내는 데이터를 만들어 UI를 먼저 구현함.

2. 외부 API 의존성을 줄이고 싶을 때

   • 테스트할 때마다 네트워크 요청을 보내면 느리고 불안정해짐.
   • Mock 데이터를 쓰면 빠르고 안정적으로 테스트 가능.

3. 특정 케이스를 강제로 재현하고 싶을 때

   • 예: 에러 응답(500), 빈 데이터, 엄청 긴 텍스트 등.
   • 실제 서버에서 이런 케이스 만들기 어렵거나 위험할 때 Mock으로 처리.

4. UI/UX 확인 및 디자인 리뷰용

   • 디자이너나 기획자가 “이 버튼 클릭했을 때 로딩 상태가 어떻게 보여?” 같은 걸 확인할 때 가짜 응답을 씀.

5. 스토리북(Storybook) 같은 컴포넌트 단위 개발

   • 서버 없이 독립적으로 UI 컴포넌트를 보여주고 싶을 때 Mock Data를 씀.

위와 같은 상황일 때 Mock 데이터를 활용하곤 합니다.
그럼 Mock 데이터를 활용하는 건 좋은걸까요??? 꼭 그렇지만은 않습니다.
개발 초기와 테스트 환경등에서는 유용할 수 있으나, 프로덕션 준비 단계에서는 실제 API와의 차이로 문제가 발생할 수 있습니다.

Mock 데이터의 단점😵

코드와 함께 설명하겠습니다.

1. 실제 데이터와의 차이

// Mock 데이터
{
  "id": "1",
  "title": "기존 회의",
  "date": "2025-10-15"
}

// 실제 API 응답
{
  "id": "uuid-string",
  "title": "기존 회의",
  "date": "2025-10-15T00:00:00.000Z", // ISO 형식
  "createdAt": "2025-01-20T10:30:00.000Z", // 추가 필드
  "status": "active" // 추가 필드
}

Mock에 없는 필드를 프론트엔드에서 참조하려 할 때,
TypeError: Cannot read property 'status' of undefined 에러가 나타나 컴포넌트 렌더링이 실패하여 화면이 깨질 수 있고

타입이 맞지 않아 Invalid Date: NaN 오류로 인한 날짜 계산이나 캘린더 표시 문제가 발생 될 수 있습니다.

그리고 실제 API에서 제공하는 정제된 데이터와 달라서 비즈니스 로직 상의 오류가 발생할 수 있으며, 이는 실제 운영 환경에서는 발견되지 않을 데이터 패턴에 맞춰 개발이 진행되는 결과를 초래할 수 있습니다.

즉, Mock 데이터와 실제 API 데이터 간의 구조·타입·값의 불일치는 프론트엔드 애플리케이션의 안정성을 크게 떨어뜨릴 수 있습니다.

2. API 동작 방식의 차이

// Mock에서는 단순한 응답
http.post('/api/events', async ({ request }) => {
  const form = await request.json();
  return HttpResponse.json({ id: randomUUID(), ...form });
});

// 실제 API는 validation, 에러 처리 등이 복잡
app.post('/api/events', async (req, res) => {
  try {
    // 복잡한 validation
    const validation = await validateEvent(req.body);
    if (!validation.isValid) {
      return res.status(400).json({ errors: validation.errors });
    }
    
    // 데이터베이스 저장
    const event = await Event.create(req.body);
    
    // 캐시 업데이트
    await updateCache();
    
    res.status(201).json(event);
  } catch (error) {
    // 에러 로깅, 모니터링 등
    logger.error('Event creation failed', error);
    res.status(500).json({ error: 'Internal server error' });
  }
});

권한 문제
Mock에서는 모든 사용자가 모든 작업 가능하지만, 실제 API에서는 사용자별 권한이 달라서 권한 없는 사용자의 작업 시도 시 에러 발생을 야기합니다.

비즈니스 규칙 위반
Mock의 단순 CRUD와 달리 실제 API에는 시간 겹침 금지 같은 복잡한 규칙이 있어서, 프론트엔드에서 체크하지 않으면 사용자가 실패 원인을 모르는 상황 발생할 수 있습니다.

데이터 처리 과정의 복잡성
Mock의 단순 삭제와 달리 실제 API에서는 관련 데이터 정리, 감사 로그 등 여러 단계를 거치며, 하나라도 실패하면 전체 작업 실패로 이어질 수 있습니다.

에러 메시지의 차이
Mock의 "404 에러"와 달리 실제 API는 구체적인 에러 메시지와 해결 방법을 제공하므로, 이를 처리하지 않으면 사용자 혼란을 야기합니다.

실시간 업데이트와 동시성 문제
Mock의 즉시 반영과 달리 실제 API는 서버 처리 지연과 동시 사용자 충돌이 발생할 수 있어서, 데이터 꼬임이나 사용자 혼란 초래할 수 있습니다.

3. 성능과 규모의 차이

// Mock: 즉시 응답
http.get('/api/events', () => {
  return HttpResponse.json(events); // 10개 이벤트
});

// 실제: 네트워크 지연, 대용량 데이터
app.get('/api/events', async (req, res) => {
  const page = parseInt(req.query.page) || 1;
  const limit = parseInt(req.query.limit) || 50;
  
  // 데이터베이스 쿼리 (시간 소요)
  const events = await Event.find()
    .skip((page - 1) * limit)
    .limit(limit)
    .populate('category')
    .sort({ date: 1 });
    
  // 페이지네이션 정보
  const total = await Event.countDocuments();
  
  res.json({
    events,
    pagination: { page, limit, total, pages: Math.ceil(total / limit) }
  });
});

Mock 환경은 소량 데이터와 단일 사용자, 안정적인 로컬 네트워크를 전제로 단순하게 동작하지만, 실제 API는 수천~수만 건의 대용량 데이터, 다수 사용자의 동시 접근, 불안정한 네트워크, 메모리 부담, 캐싱·동기화 과정까지 고려해야 합니다.

따라서 페이지네이션, 충돌 처리, 오류 대응, 성능 최적화 같은 요소를 놓치면 Mock에서는 문제없던 기능도 실제 서비스에서는 성능 저하, 데이터 꼬임, 화면 반영 지연 등 다양한 문제가 발생할 수 있습니다.

📍 Mock과 실제 API의 차이점을 예방하려면 "Mock을 실제 API와 동일하게 만들기" 가 핵심입니다.

특히 데이터 구조, API 동작 방식, 성능 요구사항을 Mock 단계에서부터 고려하고, 단계적으로 실제 API와 비슷한 환경을 만들어가는 것이 중요합니다.

이렇게 해야 나중에 실제 API 연동 시 예상치 못한 문제들을 크게 줄일 수 있고, 개발 시간도 단축할 수 있습니다.

🔗 MockAPI 대 실제 API 응답: 현대 개발자를 위한 직접 비교
🔗 모의 API 대 실제 API - 최적의 개발을 위해 각각을 선택하는 시기

FE에서 자주 쓰는 Mocking 방식들 📝

상황	목적	추천 도구/방법
개발 환경	실제 서버가 없어도 API 응답 시뮬레이션	MSW, JSON Server, MirageJS
테스트 (단위/통합)	외부 API 호출 차단, 원하는 응답 제어	Jest/Vitest mock, fetch stub/mock
UI 컴포넌트 개발	서버 의존 없이 UI 상태 확인	Storybook + mock data, MSW addon
GraphQL 사용 시	쿼리/뮤테이션 응답 가짜로 제공	Apollo MockedProvider, GraphQL Faker
프로토타입/데모	빠르게 가짜 데이터로 화면 뽑기	하드코딩된 객체/배열 (in-memory mock)

---

이번주 6기와의 추억 🌇

멘토링에 부랴부랴 참석해서 질문을 남겼다.
마지막 질문이기도 해서 분위기도 좀 풀어볼겸 작성을 해봤는데.
이런 질문에도 정말 성심성의껏 답해주는 준일코치는 최고다.

뭘까....?

인생 절반 손해 볼 뻔도 했다.

QnA 전 오프코치 등장 전에 바람잡이 활동 ㅎㅎㅎ..

금요일..아침.... 달래해장.. 최고의 선택
다들 과제로 밤 새고 수육과 해장국 같이 먹으면 그게 비로소 과제 제출입니다.
여러분 기억하세요. 꼭이요!

토요일..귀멸의 칼날:무한성 본 후 헤어지기 아쉬워서 새벽 3시까지...
그리고 난.. 다음 날(일요일) 오후 5시에 집에 들어왔다.. 어찌저찌..여찌져찌..요로코롬..해서.... 😵‍💫😵‍💫😵‍💫

... ... .... 😦
술을 좀 많이 마셨다... 흠... 🍻
앞으로 더 마실거 같긴한데 그래도 자중 해야겠다.

대망의.. 귀멸의 칼날:무한성

학창시절 이후로 이렇게 단체(8명)로 영화를 보는 것이 오랜만이여서 설렜다.
다 큰 어른들이 ㅎ.. 조금 귀엽기도 했다. (쭈르륵 앉아서 한 화면 보는게)

심지어 귀멸의 칼날을 이번 개봉한 극장판으로 처음 접하는 친구(체인소 맨 좋아함)도 있었는데 좀 고맙다 함께 해줘서

귀멸의 칼날 아이맥스 한 번 더 보고싶은데 같이 가줄 사람? 🙋‍♂️ 🙋‍♀️

그리고 나도 같이 가줄게 체인소맨 🪚

---

✅ Keep: 이번주 내가 잘한 것들

• 개발적인건 아니지만 8명과 영화 보러 간 것.
  

❗ Problem: 탈탈 털린 순간

• 음... 이번주 개인적으로 힘들었다.
• 과제에 탈탈 털렸다. HARD 난이도로 호기롭게 실행했으나, 처참히 FAIL.
  • 이번주차에 회사에서의 긴급 패치가 2회 있어서 과제에 집중을 할 수 있는 시간이 다른 주차보다 적었다.
  • AI 디톡스..로 인한 초반에 시간을 좀 까먹었다.. 계속 이어나가질 줄 알았으나 위 상황 때문에 제출 당일에는 거의 AI로만 해버렸다.. 언제쯤 나는 AI를 덜 사용 해볼 수 있을까?
• 체력 관리.. 시간관리..

💡 Try: 노력, 다짐, 실행

• 이번 주차도 비록 정기 상용 배포라는 큰 벽이 있지만. 꼭 과제 제출을 하고 싶다.
• 팀 협업이 심화 과제에 예정이 되어있어서 팀에게 누가 안 되도록 더 신경 써서 진행할 것.

🧠 이번 주 한 줄 회고:

테스트 통과 쉽지 않다. 다 쉽지 않다.

▶ 허정석님의 추천 코드 : Vo6fpd