🌐 HTTP 통신과 API 설계의 기초

클라이언트와 서버가 데이터를 주고받는 가장 기본적인 약속인 HTTP에 대해 정리해보려 합니다. 프론트엔드 개발을 하다 보면 API 명세서를 보고 axios나 fetch로 데이터를 요청하게 되는데요. 이때 우리가 사용하는 메서드나 상태 코드가 어떤 의미를 갖는지 명확히 이해하는 것이 중요합니다.

1️⃣ HTTP 메서드 = 이 요청의 목적이 무엇인가요?

HTTP(HyperText Transfer Protocol)는 브라우저와 서버 간의 데이터를 주고받기 위한 규칙입니다. 여기서 메서드(Method)는 서버에게 보내는 '동사'와 같아서, 해당 요청으로 무엇을 하고 싶은지를 나타냅니다.

프론트엔드에서 axios.get이나 axios.post를 선택하는 기준은 이 설계 의도에 있습니다.

2️⃣ 상태 코드 (Status Code) = 서버로부터 온 신호

상태 코드는 서버가 요청을 처리한 결과를 숫자로 요약해서 알려주는 신호입니다. 프론트엔드에서는 이 코드를 바탕으로 사용자에게 성공 메시지를 보여줄지, 혹은 에러 페이지로 보낼지 결정하게 됩니다.

• 200 OK: 요청 성공! (조회나 수정이 잘 되었을 때)
• 201 Created: 새로운 리소스 생성 성공 (주로 POST 요청 후 응답)
• 400 Bad Request: 요청 자체가 잘못됨 (필수 값 누락, 형식 오류 등)
• 401 Unauthorized: 인증되지 않음 (로그인이 필요하거나 토큰이 만료됨)
• 403 Forbidden: 권한 없음 (로그인은 했지만 접근 권한이 없는 페이지)
• 404 Not Found: 리소스 없음 (잘못된 URL이거나 삭제된 데이터)
• 500 Internal Server Error: 서버 내부 오류 (서버의 에러)

3️⃣ Request와 Response의 구조

데이터 통신은 크게 '요청(Request)'과 '응답(Response)'으로 나뉩니다.

3-1. Request (클라이언트 → 서버)

클라이언트가 서버로 보내는 메시지입니다. 메서드, URL, 헤더, 그리고 데이터를 담는 Body로 구성됩니다.

// POST /login 요청 예시
Headers: { "Content-Type": "application/json" }
Body: { "email": "test@test.com", "password": "1234" }

3-2. Response (서버 → 클라이언트)

서버가 처리 후 보내주는 메시지입니다. 상태 코드와 헤더, 그리고 서버가 돌려주는 데이터인 Body가 포함됩니다.

// 서버의 응답 예시
{ "id": 1, "name": "Choi" }

axios를 사용하면 response.status로 상태 코드를, response.data로 바디 데이터를 쉽게 꺼내 쓸 수 있습니다.

4️⃣ JSON 직렬화와 역직렬화

데이터를 전송할 때는 자바스크립트 객체 그대로 보낼 수 없습니다. 그래서 JSON이라는 문자열 형식을 빌려 통신합니다.

• 직렬화(Serialization): JSON.stringify(obj)를 통해 JS 객체를 문자열로 변환합니다. 서버로 보낼 때 사용해요.
• 역직렬화(Deserialization): JSON.parse(string)를 통해 문자열을 다시 JS 객체로 변환합니다. 서버 응답을 사용할 때 필요하죠.

Axios는 기본적으로 JavaScript 객체를 JSON으로 자동 직렬화(Serialization)하여 서버로 전송하고, 서버에서 온 JSON 응답을 객체로 자동 역직렬화(Deserialization/Parsing)하여 제공하는 기능을 갖추고 있습니다.

5️⃣ 통신 전체 흐름 한눈에 보기

프론트엔드가 axios.post('/login', data)를 호출하면 어떤 일이 벌어질까요?

1. 프론트: 데이터를 JSON으로 직렬화하여 HTTP 요청을 보냅니다.
2. 네트워크: Method, URL, Body 등이 담긴 패킷이 서버로 전달됩니다.
3. 서버: 요청을 받아 JSON을 역직렬화하고 비즈니스 로직을 처리합니다.
4. 서버 응답: 결과 데이터와 상태 코드를 담아 다시 프론트로 보냅니다.
5. 프론트: 응답받은 데이터를 역직렬화하여 화면에 렌더링합니다.

6️⃣ 에러 응답 구조 통일의 중요성

협업 시 서버에서 내려주는 에러 구조가 제각각이면 프론트엔드 코드는 매우 복잡해집니다.

• 문제 상황: 어떤 API는 { "msg": "error" }, 어떤 API는 { "error_message": "error" }라고 준다면?
• 해결 방안: 아래와 같이 에러 구조를 약속(규약)하는 것이 좋습니다.

{
  "code": "AUTH_001",
  "message": "로그인이 필요합니다."
}

이렇게 구조가 통일되면 공통 에러 처리 로직을 만들기 수월해지고, 사용자에게 일관된 UX를 제공할 수 있으며, 코드의 유지보수성도 비약적으로 향상됩니다.

🔚 마치며

오늘 정리한 HTTP 메서드, 상태 코드, 그리고 JSON 통신 흐름은 웹 개발의 뼈대와 같습니다. 이 기초가 탄탄해야 더 복잡한 비동기 처리나 상태 관리도 수월하게 해낼 수 있습니다.

개요

Anthropic은 2025년 8월, 132명의 엔지니어와 연구원을 대상으로 설문조사를 실시하고, 53명과 심층 인터뷰를 진행했으며, 내부 Claude Code 사용 데이터를 분석하여 AI가 업무를 어떻게 변화시키고 있는지 조사했습니다.

핵심 발견 사항

설문조사 데이터

1. Claude 주요 사용처: 코드 오류 수정(디버깅)과 코드베이스 이해가 가장 일반적
2. 생산성 향상: 직원들은 업무의 약 60%에서 Claude를 사용하며, 50% 생산성 향상을 보고 (1년 전 대비 2~3배 증가)
3. 새로운 업무 창출: Claude 지원 업무의 27%는 AI 없이는 수행하지 않았을 작업 (스케일링 프로젝트, 편의 도구 제작, 탐색적 작업 등)
4. 완전 위임 비율: 대부분의 직원이 Claude를 자주 사용하지만, 완전히 위임할 수 있는 업무는 0~20% 정도로 보고

정성적 인터뷰

1. AI 위임에 대한 직관 발달: 검증이 쉬운 작업, 위험도가 낮은 작업, 지루한 작업을 위임하는 경향. 신뢰 수준이 점진적으로 증가
2. 스킬 확장과 우려: "풀스택"으로 영역 확장 가능해졌지만, 깊이 있는 기술 역량 퇴화에 대한 우려도 존재
3. 코딩 장인정신에 대한 변화: 일부는 AI 지원을 환영하고 결과물에 집중, 다른 일부는 직접 코딩하는 것을 그리워함
4. 직장 내 사회적 역학 변화: Claude가 동료에게 가던 질문의 첫 번째 창구가 됨. 멘토링과 협업 기회 감소 우려
5. 커리어 불확실성: 단기적으로는 낙관적이나 장기적으로는 불확실. "매일 출근해서 스스로를 실직시키는 느낌"이라는 의견도

Claude Code 사용 트렌드

1. 더 복잡한 작업을 더 자율적으로 처리: 6개월 전에는 평균 10개 작업 후 사람 개입 필요 → 현재는 약 20개 작업까지 자율 처리
2. "페이퍼컷" 수정: Claude Code 작업의 8.6%가 유지보수성을 위한 리팩토링 등 사소하지만 삶의 질을 개선하는 작업
3. 모두가 "풀스택"화: 보안팀은 익숙하지 않은 코드 분석, 연구팀은 프론트엔드 시각화 구축 등 각 팀이 핵심 전문성 외 영역으로 확장

상세 발견 사항

어떤 코딩 작업에 Claude를 사용하는가?

생산성 변화 (1년 전 → 현재)

14%의 응답자는 100% 이상의 생산성 향상을 보고

AI 위임 기준

엔지니어들이 Claude에게 위임하는 작업 유형:

직접 수행하는 작업

• 고수준/전략적 사고가 필요한 작업
• 조직적 맥락이나 "취향"이 필요한 설계 결정
• 단, 이 경계는 모델이 발전함에 따라 계속 재협상 중

스킬 변화

확장되는 역량:

"프론트엔드, 트랜잭셔널 데이터베이스, API 코드 등 이전에는 건드리기 두려웠던 것들을 이제 능숙하게 다룰 수 있다"

우려 사항:

"직접 어려운 이슈를 디버깅하면 문서와 코드를 읽으면서 시스템 작동 방식에 대한 모델을 구축하게 된다. Claude가 바로 문제로 데려다주기 때문에 그런 과정이 많이 줄었다"

"감독의 역설":

"Claude를 효과적으로 사용하려면 감독이 필요하고, Claude를 감독하려면 AI 과다 사용으로 퇴화될 수 있는 바로 그 코딩 스킬이 필요하다"

직장 내 사회적 변화

• Claude가 동료에게 가던 질문의 첫 번째 창구가 됨
• 일부: "동료의 시간을 뺏는 것에 대한 부담감 감소" 긍정적
• 일부: "사람들과 일하는 것을 좋아하는데 그들이 덜 '필요'해져서 슬프다"
• 시니어 엔지니어: "주니어들이 질문을 덜 하게 되어 아쉽다. 하지만 그들은 분명 더 효과적으로 답을 얻고 더 빨리 배운다"

커리어 전망

역할 변화:

• 코드 작성자 → AI 시스템 관리자로 전환
• "70% 이상이 새 코드 작성자가 아닌 코드 리뷰어/수정자가 됨"
• "1개, 5개, 100개의 Claude에 대한 책임을 지는 것"이 미래 역할

장기적 불확실성:

"단기적으로는 낙관적이지만 장기적으로는 AI가 모든 것을 하게 되어 나와 많은 다른 사람들을 무의미하게 만들 것 같다"

Claude Code 사용 변화 (2025년 2월 → 8월)

작업 유형 분포 변화

팀별 Claude Code 활용 패턴

시사점

1. 생산성 향상은 실재하나 복잡함: 단순히 시간 단축이 아닌 출력량 증가가 주요 동인
2. 스킬 퇴화 우려는 진지하게 고려 필요: 특히 주니어 개발자의 기초 역량 습득에 대한 고민 필요
3. 협업 패턴 변화: 멘토링, 동료 간 학습 기회 감소에 대한 대응 필요
4. 적절한 위임 전략이 핵심: 검증 가능하고, 잘 정의되고, 위험도 낮은 작업부터 시작
5. 역할 진화 준비: 코드 작성자 → AI 관리자/감독자로의 전환에 대비

출처: Anthropic Research - How AI Is Transforming Work at Anthropic (2025.12.02)

백엔드 서버를 운영하다 보면 "왜 이 API가 느리지?", "왜 이 요청이 실패했지?" 같은 질문을 자주 마주하게 됩니다. 이런 문제를 해결하려면 체계적인 로깅 시스템이 필수입니다.

이 글에서는 NestJS + Fastify 환경에서 Request Log와 Service Log를 어떻게 구현했는지, 그리고 이 둘이 어떻게 협력하는지 설명하겠습니다.

📋 두 가지 로그 정책

구축한 로깅 시스템은 크게 두 가지로 나뉩니다.

Request Log는 "누가, 언제, 어디로, 얼마나 걸렸는지"를 기록하고, Service Log는 "내부에서 무슨 일이 일어났는지"를 기록합니다.

🌐 Request Log 구현

기술 스택 선택

Request Log를 구현하기 위해 nestjs-pino를 선택했습니다.

npm install nestjs-pino pino-http pino-pretty

선택 이유

• NestJS의 Logger 인터페이스를 그대로 유지하면서
• 내부적으로 고성능 Pino 엔진 사용
• 민감 정보 자동 마스킹 지원
• 로컬에서는 예쁜 출력, 운영에서는 JSON 출력

LoggerModule 구현

// src/common/modules/logger/logger.module.ts
import { randomUUID } from 'node:crypto';
import { Module } from '@nestjs/common';
import { LoggerModule as PinoLoggerModule } from 'nestjs-pino';

@Module({
  imports: [
    PinoLoggerModule.forRootAsync({
      useFactory: () => {
        const isLocal = process.env.NODE_ENV === 'local';

        return {
          pinoHttp: {
            // 기본 메타데이터
            base: {
              service: process.env.SERVICE_NAME || 'my-api',
              env: process.env.NODE_ENV || 'local'
            },

            // 민감정보 마스킹 설정
            redact: {
              paths: [
                'req.headers.cookie',
                'req.headers.authorization',
                'req.body.password',
                'req.body.email',
                '*.token',
                '*.secret'
              ],
              remove: true
            },

            // 요청마다 고유 ID 생성
            genReqId: (req) => {
              const existingId = req.headers['x-request-id'];
              return (Array.isArray(existingId) ? existingId[0] : existingId) || randomUUID();
            },

            // 추가 컨텍스트 정보 수집
            customProps: (req) => ({
              userId: req.user?.userId || null,
              clientIp: req.ips?.[0] || req.ip || req.socket?.remoteAddress
            }),

            level: isLocal ? 'debug' : 'info',

            // 로컬: 예쁜 출력, 운영: JSON
            transport: isLocal
              ? {
                  target: 'pino-pretty',
                  options: {
                    singleLine: false,
                    translateTime: 'SYS:yyyy-mm-dd HH:MM:ss.l',
                    colorize: true
                  }
                }
              : undefined,

            // 성공/에러 메시지 포맷
            customSuccessMessage: (req, res, responseTime) => {
              return `${req.method} ${req.url} ${res.statusCode} - ${Math.round(responseTime)}ms`;
            },

            customErrorMessage: (req, res, err) => {
              return `${req.method} ${req.url} ${res.statusCode} - ERROR: ${err.message}`;
            }
          }
        };
      }
    })
  ],
  exports: [PinoLoggerModule]
})
export class LoggerModule {}

main.ts 설정

// src/main.ts
import { NestFactory } from '@nestjs/core';
import { FastifyAdapter, NestFastifyApplication } from '@nestjs/platform-fastify';
import { Logger } from 'nestjs-pino';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(
    AppModule,
    new FastifyAdapter({
      logger: false  // Fastify 기본 로거 비활성화
    }),
    { bufferLogs: true }
  );

  // nestjs-pino의 Logger로 교체
  app.useLogger(app.get(Logger));

  await app.listen(3000, '0.0.0.0');
}
bootstrap();

Request Log 출력 예시

로컬 환경:

[14:32:15.123] INFO: GET /api/orders 200 - 152ms
    service: "my-api"
    env: "local"
    userId: "user-12345"
    clientIp: "::1"

운영 환경 (JSON)

{"level":30,"time":1702647135123,"service":"my-api","userId":"user-12345","responseTime":152,"msg":"GET /api/orders 200 - 152ms"}

📊 Service Log 구현

왜 Service Log가 필요한가?

Request Log만으로는 "API가 왜 느린지", "어느 단계에서 실패했는지" 알 수 없습니다. Service Log는 비즈니스 로직의 내부 흐름을 상세히 기록합니다.

구현 패턴

// src/orders/orders.service.ts
import { Injectable, Logger, BadRequestException } from '@nestjs/common';

@Injectable()
export class OrdersService {
  private readonly logger = new Logger(OrdersService.name);

  async createOrder(dto: CreateOrderDto) {
    const startTime = Date.now();

    // Stage 1: 요청 수신
    this.logger.log('[Stage 1/4] 주문 생성 요청 수신', {
      productId: dto.productId,
      quantity: dto.quantity
    });

    // Stage 2: Validation
    this.logger.debug('[Stage 2/4] Validation 시작');

    if (dto.quantity <= 0) {
      this.logger.warn('[Validation 실패] 유효하지 않은 수량', {
        quantity: dto.quantity,
        reason: '수량은 1 이상이어야 합니다'
      });
      throw new BadRequestException('수량은 1 이상이어야 합니다');
    }

    this.logger.debug('[Stage 2/4] Validation 통과');

    // Stage 3: 비즈니스 로직 처리
    this.logger.debug('[Stage 3/4] 주문 처리 중...');

    const order = await this.orderRepository.save({
      productId: dto.productId,
      quantity: dto.quantity,
      totalPrice: dto.quantity * 10000
    });

    this.logger.log('[Stage 3/4] 주문 생성 완료', { orderId: order.id });

    // Stage 4: 완료
    const duration = Date.now() - startTime;
    this.logger.log('[Stage 4/4] 처리 완료', {
      orderId: order.id,
      duration: `${duration}ms`
    });

    return order;
  }
}

Service Log 출력 예시

정상 처리

[14:32:15.050] INFO: [Stage 1/4] 주문 생성 요청 수신 { productId: 'PROD-001', quantity: 5 }
[14:32:15.060] DEBUG: [Stage 2/4] Validation 시작
[14:32:15.065] DEBUG: [Stage 2/4] Validation 통과
[14:32:15.100] DEBUG: [Stage 3/4] 주문 처리 중...
[14:32:15.140] INFO: [Stage 3/4] 주문 생성 완료 { orderId: 'ORD-123' }
[14:32:15.142] INFO: [Stage 4/4] 처리 완료 { duration: '92ms' }

Validation 실패

[14:32:15.050] INFO: [Stage 1/4] 주문 생성 요청 수신 { productId: 'PROD-001', quantity: -1 }
[14:32:15.060] DEBUG: [Stage 2/4] Validation 시작
[14:32:15.062] WARN: [Validation 실패] 유효하지 않은 수량 { quantity: -1, reason: '수량은 1 이상이어야 합니다' }

🔄 Request Log의 작동 원리 (인터셉트 방식)

Request Log가 어떻게 자동으로 기록되는지, 그 흐름을 단계별로 설명하겠습니다.

전체 흐름도

핵심 포인트

pino-http가 인터셉트하는 방식

1. 요청 시작 시: 미들웨어로서 요청을 가로채 정보 수집 (로그 출력 X)
2. 응답 완료 시: 등록해둔 콜백이 실행되어 최종 로그 출력

이 방식 덕분에 개발자가 별도 코드를 작성하지 않아도 모든 API에 자동 적용되며responseTime을 정확히 측정 가능해 집니다. (요청 시작 ~ 응답 완료) 또한, req.user 등 Guard에서 설정한 정보도 로그에 포함 가능합니다.

💡 실무 적용 팁

1. X-Request-Id 활용

프론트엔드에서 디버깅 시 직접 ID를 지정할 수 있습니다

fetch('/api/orders', {
  headers: { 'X-Request-Id': `debug-${Date.now()}` }
});

2. 민감 정보 마스킹 필수

운영 환경에서는 개인정보가 로그에 남지 않도록 주의

redact: {
  paths: ['req.body.password', 'req.body.email', '*.token'],
  remove: true  // 해당 필드 완전 제거
}

3. 로그 레벨 활용

this.logger.debug('...');  // 개발 시에만 확인할 상세 정보
this.logger.log('...');    // 일반적인 정보
this.logger.warn('...');   // 주의가 필요한 상황
this.logger.error('...');  // 에러 상황

마치며

로깅 시스템을 구축하면서 느낀 점은, 좋은 로그는 문제 해결 시간을 극적으로 줄여준다는 것입니다.

Request Log와 Service Log를 조합하면

• 전체적인 트래픽 흐름 파악 (Request Log)
• 내부 비즈니스 로직 추적 (Service Log)

이 두 가지를 모두 할 수 있어, 장애 대응과 성능 최적화에 큰 도움이 됩니다.

참고 자료

• nestjs-pino 공식 문서
• Pino 공식 문서
• NestJS Logging 가이드 ```

💡 TL;DR: AI 시대에도 코딩 컨벤션은 필수입니다. Prettier + ESLint + AI 프롬프트 조합으로 팀 전체가 일관된 코드를 작성하게 된 경험을 공유합니다.

1. 왜 코딩 컨벤션인가?

코딩 컨벤션(Code Convention): 팀이 일관된 코드 스타일과 규칙을 사용하기 위해 정한 약속.

도입을 고민하게 된 계기

I. 개발자마다 다른 코딩 스타일

가장 큰 이유였습니다. 협업 프로젝트가 있을 때마다 개발팀의 스타일이 제각각이라 가독성이 좋지 않았습니다.

결과적으로 발생한 문제들

🔴 코드 리뷰 시 스타일 논쟁에 시간 낭비 🔴 신규 팀원 온보딩 시 "이 프로젝트는 이렇게 해요"라는 불필요한 설명 증가 🔴 Git diff가 실제 로직 변경이 아닌 포맷팅 변경으로 오염

II. 프롬프트 엔지니어링과 AI 코딩

회사에 Cursor IDE를 적극 도입하면서 생산성은 이전과 비교할 수 없을 정도로 향상되었습니다. 하지만 한 가지 문제가 있었습니다.

AI는 기본적으로 우리 팀의 코딩 컨벤션을 모릅니다.

AI가 생성한 코드가 다음과 같은 문제를 일 수 있습니다.

// AI가 생성한 코드 (우리 컨벤션과 다름)
import {Controller} from "@nestjs/common"
import {UserService} from "./user.service"

export class UserController {
    constructor(private userService: UserService) {}
}

// 우리 팀 컨벤션
import { Controller } from '@nestjs/common';

import { UserService } from './user.service';

export class UserController {
  constructor(private readonly userService: UserService) {}
}

따라서 바이브 코딩(Vibe Coding) 을 하더라도 코딩 컨벤션을 지켜야 한다는 건 변함이 없었습니다.

2. 코딩 컨벤션 도입이 실패하는 이유

많은 팀이 코딩 컨벤션 도입을 시도하지만 실패하는 경우가 많습니다. 왜 그럴까요?

우리 팀의 해결 원칙

1. Prettier가 포맷 최종 결정권자 → 포매팅 논쟁 종결
2. 가독성 > 개인 취향 → 정답이 없는 부분은 Prettier 기본값 + 팀 최소 합의
3. 경고 중심 도입 → 대부분 warn으로 시작, 익숙해지면 error로 승격
4. 자동화 우선 → 저장 시 포맷/자동수정, 커밋 전 자동 검사
5. 규칙은 짧게 → 꼭 필요한 소수 규칙만, 나머지는 리뷰로 보완

3. 코딩 컨벤션 도입 방법

3-1. 공통 설정 파일 구성

모든 IDE에서 공통으로 읽을 수 있는 4가지 핵심 설정 파일을 프로젝트 루트에 배치합니다.

.editorconfig - IDE 공통 설정

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2
trim_trailing_whitespace = true

.prettierrc.json - 코드 포맷팅

{
  "printWidth": 100,
  "tabWidth": 2,
  "singleQuote": true,
  "semi": true,
  "trailingComma": "none",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

.eslintrc.cjs - 코드 품질 검사

module.exports = {
  root: true,
  plugins: ['@typescript-eslint', 'import', 'unused-imports'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
    'plugin:import/recommended',
    'plugin:prettier/recommended'  // Prettier와 충돌 방지
  ],
  rules: {
    'prettier/prettier': ['warn'],
    'prefer-const': 'error',
    '@typescript-eslint/no-unused-vars': ['warn', { argsIgnorePattern: '^_' }],
    'import/order': ['warn', {
      groups: ['builtin', 'external', 'internal', 'parent', 'sibling', 'index'],
      'newlines-between': 'always',
      alphabetize: { order: 'asc', caseInsensitive: true }
    }],
    'unused-imports/no-unused-imports': 'warn'
  }
};

3-2. AI IDE용 프롬프트 설정

Cursor (VS Code 계열)

Settings > Cursor Settings > Rules for AI에 팀 컨벤션 프롬프트 입력

# 코딩 컨벤션 규칙
- Prettier 규칙 준수: singleQuote, semi, trailingComma: none
- import 정렬: builtin → external → internal → parent/sibling
- 변수/함수: camelCase, 컴포넌트/클래스: PascalCase
- const 우선, async/await 사용
- 메서드는 동사로 시작 (예: checkSomething, getUserById)

JetBrains (WebStorm, IntelliJ 등)

프로젝트 루트에 .aiassistant/rules/ 폴더를 생성하고 마크다운 파일로 프롬프트 작성

📁 프로젝트 루트
└── 📁 .aiassistant
    └── 📁 rules
        └── 📄 coding-convention-prompt.md

3-3. package.json 스크립트 추가

{
  "scripts": {
    "lint": "eslint . --ext .ts,.tsx,.js --max-warnings=0",
    "lint:fix": "eslint . --ext .ts,.tsx,.js --fix",
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

4. 트러블 슈팅

🔧 CRLF vs LF 문제

증상

Windows 개발자와 Mac/Linux 개발자가 협업할 때 줄바꿈 문자 충돌

해결 방법

1. .gitattributes 파일 추가

   * text=auto eol=lf
   *.{cmd,[cC][mM][dD]} text eol=crlf
   *.{bat,[bB][aA][tT]} text eol=crlf

2. .prettierrc.json에 "endOfLine": "lf" 설정

3. Git 전역 설정

   git config --global core.autocrlf input  # Mac/Linux
   git config --global core.autocrlf true   # Windows

🔧 ESLint + Prettier 충돌

증상

ESLint와 Prettier가 서로 다른 포맷을 요구

해결 방법

npm install -D eslint-config-prettier eslint-plugin-prettier

.eslintrc.cjs의 extends 마지막에 추가

extends: [
  // ... 다른 설정들
  'plugin:prettier/recommended'  // 반드시 마지막에!
]

🔧 import 순서 자동 정렬 안 됨

증상

import/order 규칙이 경고만 주고 자동 수정 안 됨

해결 방법

1. eslint-import-resolver-typescript 설치

   npm install -D eslint-import-resolver-typescript

2. 설정 추가

   settings: {
     'import/resolver': {
       typescript: { project: '.' }
     }
   }

🔧 미사용 import 자동 삭제

증상

사용하지 않는 import가 남아있음

해결 방법

npm install -D eslint-plugin-unused-imports

plugins: ['unused-imports'],
rules: {
  'unused-imports/no-unused-imports': 'warn'
}

5. 결과 및 기대효과

📊 정량적 효과

✅ 정성적 효과

• 코드 리뷰 품질 향상: 스타일 논쟁 대신 로직과 설계에 집중
• 인지 부하 감소: 어떤 파일을 열어도 익숙한 구조
• AI 협업 효율화: 프롬프트에 컨벤션을 넣어 처음부터 올바른 코드 생성
• 팀 문화 개선: "내 스타일" 대신 "팀 표준"이라는 인식 정착

📚 참고 자료

• Prettier 공식 문서
• ESLint 공식 문서
• TypeScript ESLint
• 사내 코딩 컨벤션 가이드 (사내 Confluence)

해당 포스트는 인프런 강의를 수강한 뒤 개인적으로 요약·정리한 블로그 글입니다.

관련 용어 발음 정리

1. 쿠버네티스란 무엇인가?

1. 왜 필요한가?

   • 전통적 서버 운영: VM 혹은 물리 서버에 애플리케이션 직접 배포 → 수동 스케일링·업데이트
   • 문제점: 사람 손이 많이 가고, 설정이 복잡, 장애 대응이 느림

2. 쿠버네티스의 해결책

   • 자동화: 컨테이너화된 애플리케이션 배포·스케일·롤백을 자동 처리
   • 추상화: Pod·Service 같은 논리 단위로 묶어 인프라 세부사항 숨김
   • 확장성: 자동 오토스케일(AutoScaling) 지원
   • 고가용성: 노드 장애 시 자동 복구

3. 핵심 컴포넌트 구조

   graph TD
     A[Control Plane] -->|API 요청| B[kube-apiserver]
     B --> C[kube-scheduler]
     B --> D[kube-controller-manager]
     B --> E[etcd]
     F[Worker Node] -->|Pod 관리| G[kubelet]
     F -->|네트워크| H[kube-proxy]
     G --> Pod[Pod]

   • Control Plane

     • kube-apiserver: API 요청 처리
     • etcd: 클러스터 상태 저장
     • kube-scheduler: Pod 배치 결정
     • kube-controller-manager: 레플리카 관리 등 컨트롤러 실행

   • Worker Node

     • kubelet: Control Plane과 통신하며 Pod 실행
     • kube-proxy: 네트워크 룰 설정
     • 컨테이너 런타임(Docker, containerd)

4. 왜 Kubernetes인가?

   • Google Borg/Omega 경험 기반 설계
   • CNCF 졸업 프로젝트로 활발한 커뮤니티·생태계
   • AWS·GCP·Azure·온프레미스 모두 동일한 운용 경험 제공

2. Cloud Native란?

1. 정의 클라우드 장점을 최대한 활용하는 애플리케이션 설계·구축 패러다임

   • 컨테이너화, 마이크로서비스, 선언적 인프라(IaC), CI/CD 등 포함

2. 과거 vs 현재

• 과거: 모놀리식→수동 프로비전→장애 시 수동 복구
• 현재: 수십~수백 개 컨테이너 동적 운용→자동 스케일·롤백→일관된 환경

3. 구성 요소

   • 컨테이너: 애플리케이션 + 의존성 경량 패키지
   • 마이크로서비스: 기능별 독립 서비스
   • 서비스 메시: Istio 등으로 트래픽·보안·모니터링
   • DevOps: CI/CD로 배포 자동화
   • IaC: Terraform·Helm·GitOps

3. 주요 리소스 관계

1. Deployment → ReplicaSet → Pod
2. Service → Pod 그룹에 IP·DNS 제공
3. Ingress → Service에 외부 트래픽 라우팅
4. ConfigMap/Secret → Pod에 설정·민감정보 주입
5. PVC → Pod에 영구 볼륨 마운트

4. 쿠버네티스 배포(Deployment) 개념 및 아키텍처

4.1 Deployment란?

• Deployment: 원하는 Pod 사양·개수(desired state)를 선언 → ReplicaSet 생성·관리
• 지원 기능: 롤링 업데이트, 롤백, 자동 스케일링

4.2 주요 구성 요소

• ReplicaSet: Pod 복제본(desired number) 유지
• Rolling Update: 순차적 교체로 무중단 배포
• Rollback: 문제 발생 시 이전 Revision으로 복귀

4.3 배포 흐름 단계별 설명

1. 명세 제출: kubectl apply -f deployment.yaml
2. API Server 저장: Deployment 오브젝트(etcd)에 기록
3. 컨트롤러 동작: Deployment 컨트롤러가 ReplicaSet 생성/업데이트
4. 스케줄링 & 실행: kube-scheduler→kubelet→컨테이너 기동
5. 상태 조정: Controller Manager가 desired vs actual 비교 후 조정

4.4 배포 전략 비교

✨ 이 글에서 쿠버네티스의 핵심 개념과 아키텍처, 배포 전략까지 한눈에 살펴보았습니다. 다음 포스트에서는 실제 deployment.yaml 예제를 작성하고, Helm Chart를 이용해 배포를 자동화하는 과정을 단계별로 다뤄볼게요. 🚀

🧩 컨테이너 오케스트레이션

복잡한 컨테이너 환경을 효과적으로 관리하기 위한 도구

🧱 기존 방식의 한계

• 서버 환경을 아무리 문서화해도 환경/버전이 바뀌면 잘 안 돌아가는 경우 많음
• 설정 관리 도구 등장
  대표 도구: CHEF, Puppet Labs, Ansible
  하지만…
  • 배우기 어렵고
  • 설정이 복잡해지면 도구 자체도 복잡해짐
• 가상머신(VM)의 등장
  • 클라우드와 찰떡궁합은 아님
  • 특정 벤더에 종속
  • 부팅이 느려서 유연성 떨어짐

🐳 도커(Docker)의 등장

도커는 이 문제들을 상당히 해결해줬음.

• 실행 환경을 컨테이너로 추상화
• 도커만 설치되어 있으면 어디서든 동일하게 실행 가능
• 사용법이 상대적으로 쉬움 → 서버 운영 복잡성 ↓

📌 컨테이너의 특징

• VM보다 빠르고 효율적
• 이미지 기반 배포 및 롤백 가능
• 언어나 프레임워크에 상관없이 동일한 방식으로 앱 관리
• 개발/테스트/운영 환경 통일 가능
• 특정 클라우드 벤더에 종속되지 않음

📦 컨테이너화의 흐름

코드 작성 → Docker build → Ship → Run

• DB, Redis, Jenkins 등도 컨테이너화하여 관리 가능
• "이미지화"된 애플리케이션을 어디서든 실행 가능하게 만들어 줌

🤯 컨테이너가 많아지면?

컨테이너가 10개, 100개, 1000개가 되면?

• docker run만으로는 관리가 점점 어려워짐
• 배포, 업데이트, 서비스 연결, 장애 대응까지 운영 자동화에 대한 요구 증가

🛠 도커 이후의 고민들

🚀 컨테이너 배포는 어떻게?

docker stop app && docker run ...

• 수동 작업 많음
• 빈 서버 찾기도 힘듦
• 롤백/업데이트 불편

🧭 서비스 검색은 어떻게?

• 마이크로서비스 구조에서 컨테이너가 많아질수록 통신이 복잡
• 로드밸런서 설정도 번거롭고, 자동화 필요

🌐 서비스 노출은 어떻게?

• 가장 쉬운 방식: Nginx 같은 프록시 서버로 연결
• 하지만 프록시 설정을 컨테이너 증가에 맞춰 자동화해야 함

📊 모니터링과 확장

• 컨테이너 상태 이상 여부 체크
• CPU나 메모리 사용량에 따라 자동 확장/축소 필요

🧠 컨테이너 오케스트레이션의 필요성

컨테이너를 자동으로 배포, 관리, 확장, 모니터링해주는 시스템

주요 기능 요약

1. 클러스터 단위 관리

   • 개별 노드가 아닌 클러스터 단위로 컨테이너를 관리
   • SSH로 접속하지 않고, 마스터 노드에 명령 전달
   • 노드 간 통신이 원활해야 함

2. 상태 관리(State Management)

   • 예: Replica를 2 → 3으로 설정하면, 자동으로 컨테이너 3개 유지
   • 시스템이 자동으로 상태를 유지해줌

3. 스케줄링

   • 리소스 상황에 따라 컨테이너 배치 자동 조정

4. 버전 관리

   • Rollout, Rollback 같은 배포 이력 관리 기능 제공

5. 서비스 디스커버리

   • 컨테이너가 DNS 이름 기반으로 자동으로 서비스에 접근 가능
   • 예: user-service → http://user-service

6. 볼륨 스토리지

   • 상태 유지가 필요한 서비스(DB 등)를 위한 Persistent Volume
   • NFS, AWS EBS, Ceph 등 외부 스토리지 연동 가능

🤖 왜 쿠버네티스(Kubernetes)인가?

구글이 만든 오픈소스 오케스트레이션 플랫폼. 도커 이후의 실질적인 표준.

핵심 특징

• Borg라는 구글 내부 컨테이너 시스템에서 출발
• 가장 큰 커뮤니티와 생태계를 가진 오케스트레이션 도구

쿠버네티스를 선택하는 이유

1. 자가 치유(Self-healing)

   • 실패한 컨테이너를 자동으로 재시작

2. 자동 확장(Auto-scaling)

   • 부하에 따라 컨테이너 수 자동 조절

3. 버전 관리와 롤백

   • 이전 상태로 쉽게 복구 가능

4. 멀티 클라우드 호환성

   • GCP, AWS, Azure, 온프레미스 등 어디서든 실행 가능

5. 강력한 생태계

   • 다양한 오픈소스 프로젝트와 연동 가능
     (예: Kubeflow, Tekton, Istio, KNative 등)

🏁 마무리

컨테이너는 Dev-Ops 전체 프로세스를 변화시켰고,
오케스트레이션은 이를 실전에서 쓸 수 있게 만들어 주는 핵심 기술

이전 팀 프로젝트에서 Spring + Docker + Redis 기반의 백엔드 환경 설치 과정에 오류가 생겨 제공 받지 못했다. API 구현 및 명세서는 아직 준비중이었고, 이상적인 개발 과정은 기획 및 MVP 모델수립 -> 백엔드 개발 -> 프론트엔드 개발이겠지만 여태까지 겪었던 현업 및 팀 프로젝트의 과정은 위 3가지의 과정을 병행해야 하는 경우가 많았다.

결국에 백엔드의 API를 제공받고 활용해야 하며 API에 대해 종속적이라면, 해당 부분이 완성되기 전까지는 프론트엔드에서 개발을 진행할 수 없고, 그 부분이 진행된 후에나 개발이 가능하다. 따라서, 마냥 기다리기에는 시간이 부족할 것으로 예상되어 MSW를 이용한 API Mocking하기로 했다.

이렇게 하면 지속적으로 기능 구현이 가능하고, 실제 API 연동 시에도 간편하게 코드를 교체할 수 있다. 또한, 주요 기능 중 회원가입을 먼저 구현하기로 했기 때문에 OAuth, 소셜 로그인 및 accessToken 등에 대해서 자유로워서 MSW를 적극 도입하기로 했다.

2. MSW의 진행 과정

MSW(Mock Service Worker)는 API Mocking 라이브러리로, 네트워크 요청을 가로채서 모의 응답(Mocked response)을 보내주는 역할을 한다. 따라서 별도의 Mock 서버를 구축하지 않아도 API를 네트워크 수준에서 Mocking 할 수 있다.

1. 브라우저에서 요청을 보낸다
2. Service Worker에서 요청을 받고 그 요청을 복제한다. 이후 MSW에게 전송한다.
3. MSW는 요청과 일치하는 목업을 생성한다.
4. MSW가 모킹한 응답을 다시 Service Worker에게 전송한다.
5. Service Worker는 모킹된 응답을 브라우저에게 보내고 브라우저는 이 응답을 받는다.

3. 설치 과정

프론트엔드 개발 환경 : Vite + React + TypeScript

1. MSW 설치

npm install msw

패키지 설치가 끝나면 자동으로 public 폴더에 mockServiceWorker.js 파일이 생성된다.

2. MSW 사용

• src 폴더 안에 mocks라는 폴더를 만든다.

• handler 함수 생성

//     src\mocks\handlers.ts

import { rest } from 'msw'

const mockData = ['test1', 'test2', 'test3']
const tempEmail = 'temp@gmail.com'

const emailAPI = {
  sendVerificationEmail: `/auth/verification/send/${tempEmail}`,
}

export const handlers = [
  rest.get('/test', (_req, res, ctx) => {
    // 가짜 응답 데이터 생성 (원하는대로 수정 가능)
    return res(ctx.status(200), ctx.json(mockData))
  }),

  rest.post('/auth/signup', (_req, res, ctx) => {
    // 가짜 응답 데이터 생성 (원하는대로 수정 가능)
    return res(ctx.status(201))
  }),

  rest.post(emailAPI.sendVerificationEmail, (_req, res, ctx) => {
    const randomCode = Math.floor(Math.random() * 1000000) + 100000
    randomCode.toString()
    return res(
      ctx.status(200),
      ctx.json({
        message: 'Verification email sent successfully',
        email: tempEmail,
        code: randomCode,
      })
    )
  }),
]

REST API 방식의 HTTP 메서드를 작성할 수 있다. 위 코드는 MSW를 사용하여 회원가입 기능 중 이메일 관련 API를 모킹하는 예시이다.

• service worker 생성

// src\mocks\browsers.ts

import { setupWorker } from 'msw'
import { handlers } from './handlers'

export const worker = setupWorker(...handlers)

setupWorker() 함수는 브라우저에서 API mocking을 활성화할 수 있도록 클라이언트-작업자 간 통신을 준비한다.

• MSW 실행

마지막으로, MSW를 실행시키기 위한 코드를 추가한다. 환경 변수에 따라 MSW를 사용하기 위한 분기를 포함하여 현재 실행중인 환경이 dev 환경일때만 실행할 수 있도록 한다.

// src\main.tsx

if (process.env.NODE_ENV === "development") {
    worker.start();
}

브라우저 개발자 도구에서 [MSW] Mocking enabled. 라는 메세지가 보이면 MSW가 정상적으로 실행 중인 상태다.

4. 후기

MSW를 사용하면 API 요청 및 응답을 가로채고 모의 데이터로 대체할 수 있어서 테스트 및 개발이 훨씬 용이해졌다. 특히 백엔드 API가 아직 완전히 개발되지 않았을 때나 여러 상황을 시뮬레이션 하기에 적합했다. 또한, 백엔드 API의 구현 여부와 상관없이 프론트단을 독립적으로 개발할 수 있어서 좋았다.

하지만 실제 API와 모킹된 데이터 간의 차이가 발생할 수 있어서 특정 케이스를 놓치거나 예상치 못한 문제가 발생할 수 있는 점과, 환경 설정 및 초기 세팅이 쉽지 않았다는 느낌도 들었다. 이 점은 다음 협업 때 MSW를 사용한다면 개선할 수 있을 것 같다.

5. 참고자료

https://jaypedia.tistory.com/382 https://tech.kakao.com/2021/09/29/mocking-fe/ https://mswjs.io/docs/integrations/browser https://mswjs.io/docs/api/setup-worker

01. HTML

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="styles.css" />
    <title>Todo App</title>
  </head>
  <body>
    <div class="todo-container">
      <h1>Todo App</h1>
      <input type="text" id="taskInput" placeholder="할 일 추가" />
      <button id="addTask">추가</button>
      <ul id="taskList">
        <!-- 동적으로 추가할 내용 -->
      </ul>
    </div>
    <script src="app.js"></script>
  </body>
</html>

1. 할 일 목록을 배열로 초기 생성한다.
2. input button ul 태그의 요소를 가져온다.
3. 할 일 추가 함수를 작성한다.
4. 렌더링 함수를 작성한다.
5. 버튼 클릭 이벤트 처리

02. TypeScript

i. Task 객체

type Task = {
  id: number;
  text: string;
  completed: boolean;
};

코드를 구조화하고, 유지보수를 쉽게 하기 위하여 객체로 생성했다. id는 고유 식별자, text 는 내용, completed는 완료 여부 속성이다.

ii. tasks 배열

const tasks: Task[] = [];

Tasks 객체를 담는 배열. 추가한 리스트를 관리한다.

iii. HTML 요소 가져오기

const taskInput = document.getElementById('taskInput') as HTMLInputElement;
const addTaskButton = document.getElementById('addTask') as HTMLButtonElement;
const taskList = document.getElementById('taskList') as HTMLUListElement;

HTML에서 taskInput addTaskButton taskList 요소를 가져온다. taskInput은 할 일을 입력하는 입력 필드, addTaskButton은 할 일을 추가하는 버튼, taskList는 할 일 목록을 표시하는 <ul> 요소를 나타낸다.

as 키워드

let title = document.querySelector('#title');
title.innerHTML = 'Hi'

타입스크립트는 위와 같이 작성하면 에러를 발생시킨다. title 변수의 타입이 HTMLElement | null 이기 때문에 타입 확정이 불가능한 상태에서 DOM 조작을 금지시킨다.

따라서 Type Narrowing 또는 Type Assertion을 통해 타입을 확정시킨다. as 키워드는 Type Assertion으로 사용되며 컴파일러에게 "이 변수는 이러한 타입이다" 라고 명시해준다.

iv. 할 일 추가 함수

// 할 일 추가 함수
function addTask() {
  const text = taskInput.value.trim();
  if (!text) return;
  const newTask: Task = {
    id: tasks.length + 1,
    text,
    completed: false,
  };

  tasks.push(newTask);
  taskInput.value = '';
  renderTask(newTask);
}

addTask 함수는 사용자가 input 태그에 입력한 값을 가져오고, 새로운 Task 객체를 만든다음에 tasks 배열에 푸시한다. 그리고 나서 input 태그 필드를 비우고, 렌더링하는 함수인 renderTask를 실행한다.

v. 렌더링 함수 & 버튼 클릭 이벤트

function renderTask(task: Task) {
  const taskItem = document.createElement('li');
  taskItem.innerHTML = `
        <input type="checkbox" id="task-${task.id}" ${task.completed ? 'checked' : ''}>
        <label for="task-${task.id}">${task.text}</label>
    `;
  taskList.appendChild(taskItem);
}

// 할 일 추가 버튼 클릭 이벤트 처리
addTaskButton.addEventListener('click', addTask);

renderTask 함수는 li 요소를 생성하고 Task 객체를 HTML 목록으로 렌더링한다. 이후 추가 버튼에 이벤트 리스너를 추가해서 버튼을 클릭했을 때 addTask 함수가 실행되도록 추가한다.

03. 전체코드(TypeScript)

// app.ts

// Task 타입 정의
type Task = {
  id: number;
  text: string;
  completed: boolean;
};

// 할 일 목록
const tasks: Task[] = [];

// HTML 요소 가져오기
const taskInput = document.getElementById('taskInput') as HTMLInputElement;
const addTaskButton = document.getElementById('addTask') as HTMLButtonElement;
const taskList = document.getElementById('taskList') as HTMLUListElement;

// 할 일 추가 함수
function addTask() {
  const text = taskInput.value.trim();
  if (!text) return;

  const newTask: Task = {
    id: tasks.length + 1,
    text,
    completed: false,
  };

  tasks.push(newTask);
  taskInput.value = '';
  renderTask(newTask);
}

// 할 일 렌더링 함수
function renderTask(task: Task) {
  const taskItem = document.createElement('li');
  taskItem.innerHTML = `
        <input type="checkbox" id="task-${task.id}" ${task.completed ? 'checked' : ''}>
        <label for="task-${task.id}">${task.text}</label>
    `;
  taskList.appendChild(taskItem);
}

// 할 일 추가 버튼 클릭 이벤트 처리
addTaskButton.addEventListener('click', addTask);

타입스크립트에서 타입 별칭(Type Aliases)은 특정 타입에 이름을 부여하여 재사용 가능한 변수를 말한다. 타입 별칭을 사용하면 반복적으로 작성해야 하는 복잡한 타입을 간결하게 표현하거나, 여러 곳에서 사용되는 타입을 중앙에서 관리하며 유지보수하기 용이해진다.

type TypeName = TypeDefinition;

TypeName은 타입 별칭의 이름이며, TypeDefinition은 해당 별칭이 나타내는 실제 타입을 정의한다.

오브젝트 타입도 저장이 가능하다. 아래 코드에서 Point와 Person은 각각 별칭이며, 객체 타입을 간결하게 표현할 수 있다. 함수의 파리미터나 리턴값으로 사용될 때 유용하다.

type Point = {
  x: number;
  y: number;
};

type Person = {
  name: string;
  age: number;
};

function distance(p1: Point, p2: Point): number {
  // ...
}

const john: Person = {
  name: "John",
  age: 30,
};

02. Optional

type Square = {
  color?: string;
  width: number;
};

Square 타입은 color 속성과 width 속성을 가진 객체를 표현한다. color 속성 뒤에 붙은 물음표(?)는 해당 속성이 옵셔널(선택적)이라는 것을 나타낸다.

Square 타입으로 선언된 객체는 color 속성을 포함할 수도 있고, 포함하지 않을 수도 있지 width 속성은 반드시 존재해야 하는 필수 속성이다.

03. Union Types

Type Aliases도 | 키워드를 사용하여 Union Type을 만들 수 있다. & 기호를 쓴다면 인터섹션 타입(Intersection Type)을 만들 수 있다.

인터섹션 타입(Intersection Type) 여러 타입을 모두 만족하는 하나의 타입을 의미

type ID = number | string;

type Address = {
  street: string;
  city: string;
};

type DetailedPerson = Person & Address;

04. Function

함수의 파라미터와 리턴값도 타입지정이 가능하다.

// 타입 별칭 정의
type Person = {
  name: string;
  age: number;
};

// 함수에서 타입 별칭 사용
function greet(person: Person): string {
  return `안녕하세요, ${person.name}님! 당신은 ${person.age}살이군요.`;
}

// 예제
const user: Person = { name: 'Alice', age: 30 };
const greeting: string = greet(user);

console.log(greeting); // "안녕하세요, Alice님! 당신은 30살이군요."

Person이라는 타입 별칭을 정의하고, greet라는 함수의 파라미터로 사용했다. 함수 내부에서는 person.name 및 person.age를 사용하여 인사말을 생성하고. user 객체를 만들어 함수에 전달하고 함수 호출 결과를 출력한다.

타입스크립트는 변수와 파라미터, 반환 값 등의 타입을 명시적으로 선언할 수 있다. 이로 인해 코드 작성 시 타입 관련 오류를 미리 찾을 수 있고, 런타임 에러를 사전에 방지할 수 있다.

01. 함수의 타입 선언

JavaScript

function sum(a, b) {
  return a + b;
}

TypeScript

function sum(a: number, b: number): number {
  return a + b;
}

함수에 타입을 지정할 때는 2곳에 지정이 가능하다.

1. 파라미터
2. 리턴 값

02. Void 타입

void 타입은 함수의 리턴 타입 중 하나로, 함수가 아무런 값을 반환하지 않을 때 사용된다. 로그를 출력하는 함수나 데이터를 저장하는 함수 등이 해당된다. 이벤트 핸들러 함수도 주로 특정 이벤트가 발생했을 때 호출되며 반환 값이 필요하지 않은 경우가 많은데, 이런 경우에도 void 타입을 사용할 수 있다.

function sum (a: number, b: number): void {
  return a + b // number 형식은 void 형식에 할당할 수 없다.
}

03. 인자

자바스크립트는 선언한 함수의 파라미터 개수와 인자의 개수가 일치하지 않더라도 에러를 발생시키지 않는다. 하지만 타입스크립트는 에러를 발생시키므로 함수의 인자를 모두 필수 값으로 간주한다.

function sum (a: number, b: number): number {
  return a + b
}

sum(1) // 2개의 인수가 필요한데 1개의 인수를 가져옴.
sum(1,2)
sum(1,2,3) // 2개의 인수가 필요한데 3개의 인수를 가져옴.

위 특성은 정의된 파라미터 갯수 만큼 인자를 넘기지 않아도 되는 자바스크립트의 특성과 반대된다. 만약 이러한 특성을 살리고 싶다면 ?를 이용해서 옵션 정의를 할 수 있다.

function option (a?: number) {
  return a;
}

sum(10);
sum();

하지만 아래와 같은 코드는 에러를 발생시킨다. 변수의 타입이 아직 확정되지 않았으므로 값을 변경시킬 수 없기 때문이다. 타입스크립트에서 + 연산자는 2개의 피연산자가 모두 숫자인 경우에만 수학적으로 덧셈을 수행하는데, 피연산자가 string 일 가능성이 있으므로 에러를 발생시킨다.

function plusOne(x :number | string){ 
    return x + 1 
} 

function myFunc(x? :number) :number { 
    return x * 2 
}  

파라미터를 옵션으로 정의할 경우 number | undefined 타입으로 정의되기 때문에 타입을 확정할 수 없어 에러를 발생시킨다.

04. Type Narrowing

function plusOne(x :number | string){ 
    return x + 1 // '+' 연산자를 적용할 수 없다.
} 

타입스크립트에서 + 연산자는 2개의 피연산자가 모두 숫자인 경우에만 수학적으로 덧셈을 수행하는데, 피연산자가 string 일 가능성이 있으므로 에러를 발생시킨다.

이러한 경우 Type Narrowing을 주로 해준다. Type Narrowing은 변수의 타입을 좁혀나가는 프로세스를 말한다.

function plusOne(x :number | string){
    if (typeof x === 'number'){
        return x + 1;
    } else if (typeof x === 'string'){
        return Number(x) + 1;
    }
}

if문과 typeof 키워드로 typeof x === 'number' 조건에서는 숫자 타입인 경우에는 그대로 x + 1을 반환하고, typeof x === 'string' 조건에서는 문자열을 숫자로 변환한 후에 Number(x) + 1을 반환하는 방식으로 처리할 수 있다. 과정이 번거롭긴 하지만 타입이 확실하지 않을 때 생기는 부작용을 막을 수 있다.

Any

들어올 타입이 확실치 않거나 알지 못할 때 타입을 표현해야 할 수도 있다. 클라이언트로부터 받은 데이터, 서드 파티 라이브러리 같은 동적인 컨텐츠가 주로 그렇다. 이 경우 타입 검사를 하지 않고, 그 값들이 컴파일 시간에 검사를 통과하길 원할 때 any 타입을 사용한다.

let notSure: any = 4;
notSure = "maybe a string instead";
notSure = false;

Unknown

any 와 마찬가지로 모든 종류의 값과 메소드를 할당할 수 있지만, 사용하기 전에 타입을 체크하거나 변환해야한다. unknown 타입을 사용하면 컴파일러가 타입 검사를 엄격하게 강제하며, 안전한 타입 변환을 해야만 해당 값의 속성과 메소드에 접근할 수 있다

let y: unknown = 5;

if (typeof y === "string") {
    console.log(y.toUpperCase()); // 문자열인 경우에만 실행됨
}

Union Types

number나 string 타입이 들어올 것이라고 예상할 때, OR 연산자랑 비슷하게 | 연산자를 사용하여 타입을 정의할 수 있다.

let age: string | number = 25;
let arr: (number | string)[] = [1,'2',3];
let obj: { a: string | number } = { a: '3'};

01. 기본 타입

TypeScript는 JavaScript와 거의 동일한 데이터 타입을 지원하며, 열거 타입을 사용하여 더 편리하게 사용할 수 있다.

가장 기본적인 데이터 타입은 JavaScript, TypeScript에서 boolean 값이라고 일컫는 참/거짓(true/false) 값이다.

let isDone: boolean = false;

변수명: 타입 으로 인해 isDone 이라는 변수는 boolean 타입이 되며 숫자나 문자등을 할당하면 에러가 발생한다.

배열 타입은 두 가지 방법으로 쓸 수 있다. 첫 번째 방법은, 배열 요소들을 나타내는 타입 뒤에 []를 쓰는 것이다.

let list: number[] = [1, 2, 3];

두 번째 방법은 제네릭 배열 타입을 쓸 수 있다.

let list: Array<number> = [1, 2, 3];

object 자료안에 들어갈 타입은 내가 만들 object와 똑같은 모습으로 지정하면 된다.

let myInfo : { age : number } = { age : 20 }

02. 타입 명시

타입스크립트를 사용한다고 해서 모든 변수에 타입을 지정해야 하는 것은 아니다. 변수 생성시 타입스크립트가 타입을 자동으로 부여해주기 때문이다.

내가 생각하는 타입 명시를 해야할 때와 하지 않아도 될 경우

1. 변수의 타입을 명시해야 하는 경우

• 함수의 파라미터와 리턴 값 : 함수의 경우 타입을 예상하기 어렵기 때문이다.
• 객체 또는 배열의 타입이 동적일 때
• 타입 예상이 어려울 때

2. 변수의 타입을 명시하지 않아도 되는 경우

• 간단한 리터럴 let name = 'kim'; 과 같이 타입을 유추하기 쉽고 자동으로 string 타입이 할당되기 때문이다.

• 변수의 타입이 확실한 경우

03. 예제

개인정보를 담고 있는 객체를 만들고, 타입을 지정한다.

let person : {
  firstName : string;
  lastName : string;
  age : number;
  isStudent : boolean;
} = {
  firstName : "John",
  lastName : "Doe",
  age : 25,
  isStudent : true,
};

만약 해당 객체를 여러 곳에서 재사용하고, 구조가 복잡하거나 가독성을 높이려고 할 때는 타입 정의를 사용할 수 있다. 인터페이스 같은 개념인 것 같다.

// 개인 정보를 담는 객체 타입 정의
type Person = {
  firstName: string;
  lastName: string;
  age: number;
  isStudent: boolean;
};

// 개인 정보 객체 생성
const person: Person = {
  firstName: "John",
  lastName: "Doe",
  age: 25,
  isStudent: true,
};

함수를 명시적으로 호출하지 않고 일정 시간이 지난 다음에 호출을 예약하려면 타이머 함수를 쓰면 됨. setTimeout 과 setInterval 은 일정 시간이 지나면 콜백 함수가 호출된다. setTimout은 타이머가 한번만 동작하고 setInterval은 반복적으로 동작.

41.3 디바운스와 스로틀

scroll, mousemove 같은 이벤트는 console.log 이벤트 행위에 비해 좀 과도하게 호출되는 경향이 있는것 같다. 이때 디바운스랑 스로틀을 써서 과도한 이벤트 호출을 방지할 수도 있음.

디바운스

setTimeout과 비슷하게 일정시간동안 이벤트가 발생되지 않으면 이벤트 핸들러가 한번만 호출.

스로틀

일정시간 간격으로 이벤트 핸들러가 최대 한번만 호출되도록 한다.

42장 비동기 프로그래밍

자바스크립트 엔진은 한 번에 하나의 태스크만 실행할 수 있는 싱글 스레드 방식으로 동작한다. 때문에 시간이 걸리는 태스크를 실행하는 경우 블로킹이 발생한다.

현재 실행 중인 태스크가 종료할 때까지 다음에 실행될 태스크가 대기하는 방식을 동기처리라고 하고 현재 실행 중인 태스크가 종료되지 않은 상태라 해도 다음 태스크를 곧바로 실행하는 방식을 비동기처리라고 한다.

타이머 함수인 setTimeout과 setTimeinterval, HTTP 요청, 이벤트 핸들러는 비동기 처리 방식으로 동작한다.

이벤트 루프와 태스크 큐

이벤트 루프는 동시성을 지원하는 것이며 콜 스택이 비어 있고 태스큐 큐에 대기 중인 함수가 있다면 이벤트 루프는 순차적으로 콜 스택으로 이동시킨다.

태스크 큐는 setTimeout과 setTimeinterval과 같은 비동기 함수의 콜백 함수 또는 이벤트 핸들러가 일시적으로 보관되는 장소.

비동기 함수인 setTimeout의 콜백 함수는 태스크 큐에 푸시되어 대기하다가 콜 스택이 비게 되면, 콜 스택에 푸시되어 실행된다.

43장 AJAX

브라우저가 서버에게 비동기 방식으로 데이터를 요청하고 서버가 응답한 데이터를 받아서 동적으로 렌더링하는 프로그래밍 방식을 말한다.

장점

1. 변경할 부분을 갱신하는데 필요한 데이터만 서버로부터 받기 때문에 불필요한 데이터 통신이 발생하지 않는다.
2. 변경할 필요가 없는 부분으 다시 렌더링하지 않는다. 따라서 화면이 순간적으로 깜빡이는 현상이 발생하지 않는다.
3. 비동기 방식으로 동작하기 때문에 서버가 요청을 보낸 이후 블로킹이 발생하지 않는다.

JSON

자바스크립트의 객체 리터럴과 유사하게 키와 값으로 구성된 순수한 텍스트다.

44장 REST API

https://velog.io/@boseong-choi/RESTful-API%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

브라우저는 처리해야 할 특정 사건이 발생하면 이를 감지하여 이벤트를 발생시킨다. 이때 이벤트가 발생했을 때 호출될 함수를 이벤트 핸들러라 하고, 이벤트가 발생했을 때 브라우저에게 이벤트 핸들러 호출을 위임하는 것을 이벤트 핸들러 등록이라 한다.

브라우저는 사용자의 버튼 클릭을 감지하여 클릭 이벤트를 발생시킬 수 있다. 그리고 클릭 이벤트가 발생하면 특정함수를 호출하도록 브라우저에게 위임할 수 있다. 프로그램의 흐름을 이벤트 중심으로 제어하는 프로그래밍 방식을 이벤트 드리븐 프로그래밍이라 한다.

40.2 이벤트 타입

1. 마우스 이벤트
2. 키보드 이벤트
3. 포커스 이벤트
4. 폼 이벤트 기타 등등

40.3 이벤트 핸들러 등록

이벤트 핸들러는 이벤트가 발생했을 때 브라우저에 호출을 위임한 함수. 이벤트가 발생하면 브라우저에 의해 호출될 함수가 이벤트 핸들러다.

1. 어트리뷰트 방식 HTML 요소의 어트리뷰트에는 이벤트 핸들러 어트뷰리트가 있다. 가급적 사용하지 말자.

2. 프로퍼티 방식 이벤트 핸들러 프로퍼티에 함수를 바인딩하면 이벤트 핸들러가 등록된다.

   const $button = document.querySelector('button');
   

// 이벤트 핸들러 프로퍼티에 이벤트 핸들러를 바인딩한다. $button.onclick = function () { // $button -> 이벤트 타깃, onclick -> 이벤트 타입, function () {} -> 이벤트 핸들러 console.log('button clicked'); };

단, 이벤트 핸들러 프로퍼티에 하나의 이벤트 핸들러만 바인딩할 수 있다는 단점이 있다.

3. addEventListener 메서드
`이벤트 타깃.addEventListener(이벤트 타입, 이벤트 핸들러[, 옵션]);`
addEventListener 메서드는 이벤트 핸들러 프로퍼티에 바인딩된 이벤트 핸들러에 영향을 주지 않는다. 따라서 버튼 요소에서 클릭이벤트가 발생하면 2개의 이벤트 모두 호출된다. 단, 참조가 동일한 이벤트 핸들러를 중복 등록할 수 없다.

### 40.4 이벤트 핸들러 제거
addEventListener 메서드로 등록한 이벤트 핸들러는 removeEventListener 메서드로 제거할 수 있다. 인수는 addEventListener 메서드와 동일하게 전달한다. 하지만, 인수가 일치하지 않으면 제거되지 않는다.

removeEventListener 메서드에 인수로 전달한 이벤트 핸들러는 addEventListener 메서드로 등록한 이벤트 핸들러와 동일한 함수 객체여야 한다. 따라서 무명 함수를 사용한 이벤트 핸들러는 제거할 수 없다.

무명함수에 대해 직접 접근하기 어렵기 때문. 제거하려면 addEventListener 메서드에 전달한 이벤트 핸들러를 변수에 할당하여 사용해야 한다.

``` js
$button.addEventListener('click', () => {
  console.log('button clicked');
});

$button.removeEventListener('click', () => {
  console.log('button clicked');
}); // 제거되지 않는다.

이벤트 핸들러 프로퍼티 방식으로 등록한 이벤트 핸들러는 removeEventListener 메서드로 제거할 수 없다. 이벤트 핸들러 프로퍼티 방식으로 등록한 이벤트 핸들러는 null을 할당하여 제거한다.

40.5 이벤트 객체

생성된 이벤트 객체는 이벤트 핸들러의 첫 번째 인수로 전달된다.

function showCoords(event) {
  $msg.textContent = `X: ${event.clientX}, Y: ${event.clientY}`;
}

document.onclick = showCoords;

이벤트 객체 : PointerEvent {isTrusted: true, pointerId: 0, width: 1, height: 1, pressure: 0, …} 클릭 이벤트 = document.onclick = showCoords; -> 클릭 이벤트가 발생하면 showCoords 함수가 호출된다.

이때 이벤트 객체가 showCoords 함수의 첫 번째 인수로 전달되고 파라미터 event에 할당된다. 함수 이름만을 쓰는 이유는 이벤트의 결과값을 내가 아직 모르기 때문에 브라우저에게 위임하는 것이다. 그래서 암묵적으로 함수 이름을 쓰는 것이다라고 이해했다.

40.6 이벤트 전파

DOM 요소 노드에서 발생한 이벤트는 DOM 트리를 통해 전파된다. 그림 40-8 보시면 이해가 더 쉬울듯. 상위 요소에서 하위 요소로 전파되는 것이 캡처링 단계. 이벤트가 타깃에 도달하는게 타깃 단계. 하위 요소에서 상위 요소로 전파되는 것이 버블링 단계.

이처럼 이벤트는 이벤트를 발생시킨 타깃은 물론 상위 DOM 요소에서도 캐치할 수 있다.

40.7 이벤트 위임

하위 요소에 이벤트를 걸지 않고 이벤트 전파의 특징을 활용해서 상위 요소에 이벤트를 걸어서 상위 요소 너한테 맡길게.

784P 맨 아래 코드는 하위 요소에 일일이 이벤트 핸들러를 등록하고 있음. 만약 하위 요소가 동적이거나 한 100개 되면은 매우 불편. 이를 보완한게 786P 상위 요소에 이벤트 핸들러 등록.

matches 메서드. ul → li 로 전파되는건 눈에 잘 보이는 편인데. 이게 컴포넌트 방식으로 만들거나, 구조가 복잡할경우 잘 파악이 안됨. 이럴 때 특정 노드를 탐색해서 전파가 가능한지 사용하기도 하고, 허용되지 않은 타깃이 전파되는걸 막기도 함. 예제 40-33 타깃이 #fruits 자식 요소가 아니면 얼리 리턴해줌.

40.8 DOM 요소의 기본 동작 조작

1. preventDefault 기본 동작을 중지시킨다. 회원 가입 폼이 있는데, 따로 조건 제한 안하면 공백을 입력하든 입력 안하든 form action은 하게 되어있음. 그걸 방지하기 위해 input의 값을 받아서 그게 null 또는 공백이면 e.preventDefault() 해서 제출 동작을 막을 수 있음.

2. stopPropagation 전파를 막는 메서드. 캡처링/버블링 둘다.

40.9 이벤트 핸들러 내부의 this

일반함수로서 호출되는 함수 내부의 this는 전역 객채를 가리킴. 근데 예외로 이벤트 핸들러 어트리뷰트 방식에서 이벤트 핸들러를 호출할 때 아규먼트를 this로 넣으면 이벤트를 바인딩한 DOM 요소를 가리킨다.

그리고 이벤트 핸들러 프로퍼티 방식과 addEventListener 메서드 방식은 내부의 this가 이벤트를 바인딩한 DOM 요소를 가리킨다. 근데 이벤트핸들러를 화살표 함수로 정의하면 상위 스코프의 this를 가리킴. 화살표 함수는 자체적으로 this 바인딩이 없기 때문에.

40.10 이벤트 핸들러에 인수 전달

원래 함수에 아규먼트를 전달하려면 호출할 때 전달해야 하는데 이벤트 핸들러 프로퍼티랑 addEventListener 메서드는 이벤트 핸들러를 브라우저가 호출함. 그래서 아규먼트를 전달할 수 없지만 방법이 하나 있음.

40.11 커스텀 이벤트

이벤트 객체는 MoustEvent 같은 이벤트 생성자 함수로 생성할 수 있다. 예제 40-49 MouseEvent 생성자 함수로 클릭 이벤트 타입의 이벤트 객체를 생성.

797p 커스텀 이벤트 디스패치 : 실제로 이벤트가 발생한 것처럼 하고 싶다. 실제로 클릭한게 아니라 커스텀 이벤트 만들어놓고 클릭이벤트가 발생한 것처럼 구현할 때.

39.1 노드

노드는 트리 자료구조의 기본 구성 요소이다.

트리 자료구조

하나의 루트 노드에서 시작하여 나뭇가지 형태로 연결된 노드의 집합으로 계층적 관계를 표현한다. 치상위 노드를 루트 노드, 최하위 노드를 리프 노드라 한다. 이런 형태가 노드로 구성되어 있는 것을 DOM이라 한다. 그래서 DOM 트리라고도 한다.

모든 노드 객체는 Object, EventTarget, Node 인터페이스를 상속받는다. 문서 노드는 Document, HTMLDocument 인터페이스를 상속받고 어트리뷰트 노드는 Attr 인터페이스를 상속받는다. 요소 노드는 Element 인터페이스를 상속받고 추가적으로 태그의 종류별로 세분화된 인터페이스를 상속받는다.

프로토타입 체인 관점에서 살펴보면 input 요소 노드 객체는 HTMLElement, Element, Node, EventTarget, Object의 프로토타입 체인을 갖는다.

39.2 요소 노드 취득

1. id를 사용하여 요소 노드를 취득하는 방법

Document.getElementById 메서드는 인수로 전달받은 id 어트리뷰트 값을 갖는 요소 노드를 탐색하여 반환한다. getElementById 메서드는 Document.prototype의 프로퍼티이므로 document 객체를 통해 호출한다.

// id 값이 banana인 요소 노드를 탐색하여 반환한다.
const $elem = document.getElementById('banana');

// 취득한 요소 노드의 style.color 프로퍼티 값을 변경한다.
$elem.tyle.color = 'red';

HTML 문서내에 id 값이 여러 개 존재하더라도 에러가 발생하지 않는다. 이런 경우 첫 번째 요소 노드만 반환한다.

만약 인수로 전달된 id 어트리뷰트 값을 갖는 요소 노드가 존재하지 않으면 null을 반환한다. HTML 요소에 id 어트리뷰트를 부여하면 id 값과 동일한 이름의 전역 변수가 암묵적으로 생성된다.

2. 태그 이름을 사용하여 요소 노드를 취득하는 방법

Document.getElementsByTagName 메서드는 인수로 전달받은 태그 이름을 갖는 요소 노드를 탐색하여 HTMLCollection 객체를 반환한다. HTMLCollection 객체는 유사 배열 객체이자 이터러블이며, length 프로퍼티와 item 메서드를 갖는다. HTMLCollection 객체는 라이브 상태이므로 DOM이 변경되면 자동으로 갱신된다.

3. 클래스 이름을 사용하여 요소 노드를 취득하는 방법

Document.getElementsByClassName 메서드는 인수로 전달받은 클래스 이름을 갖는 요소 노드를 탐색하여 getElementByTagName 메서드와 마찬가지로 HTMLCollection 객체를 반환한다.

만약 인수로 전달된 class 값을 갖는 요소가 존재하지 않을 경우 빈 HTMLCollection 객체를 반환한다.

4. CSS 선택자를 사용하여 요소 노드를 취득하는 방법

생략

5. 특정 요소 노드를 취득할 수 있는지 확인

Document.querySelector 메서드는 인수로 전달받은 CSS 선택자를 사용하여 특정 요소 노드를 탐색하여 반환한다. Element.prototype.matches 메서드는 인수로 전달받은 CSS 선택자를 사용하여 특정 요소 노드를 탐색하여 취득할 수 있는지 확인한다.

const $apple = document.querySelector('.apple');

console.log($apple.matches('.apple')); // true
console.log($apple.matches('.banana')); // false

Element.prototype.matches 메서드는 이벤트 위임을 사용할 때 유용하다.

39.3 노드 탐색

요소 노드를 취득한 다음, DOM 트리를 탐색하여 자식, 부모, 형제 노드를 취득할 수 있다.

1. 공백 텍스트 노드

HTML 요소 사이의 공백 문자(스페이스, 탭, 개행 등)는 브라우저에 의해 공백 텍스트 노드로 변환된다.

2. 자식 노드 탐색

3. 자식 노드 존재 확인

Node.prototype.hasChildNodes 메서드는 자식 노드가 존재하면 true, 그렇지 않으면 false를 반환한다.

4. 요소 노드의 텍스트 노드 탐색

요소 노드는 자식 노드로 텍스트 노드를 가질 수 있다. 이때 텍스트 노드는 요소 노드의 첫 번째 자식 노드이다. Node.prototype.firstChild 메서드는 요소 노드의 첫 번째 자식 노드를 탐색하여 반환한다.

5. 부모 노드 탐색

Node.prototype.parentNode 메서드는 부모 노드를 탐색하여 반환한다.

6. 형제 노드 탐색

Node.prototype.nextSibling 메서드는 형제 노드 중 다음 형제 노드를 탐색하여 반환한다. Node.prototype.previousSibling 메서드는 형제 노드 중 이전 형제 노드를 탐색하여 반환한다.

39.4 노드 정보 취득

Node.prototype.nodeType 프로퍼티는 노드의 타입을 나타내는 정수 값을 반환한다. Node.prototype.nodeName 프로퍼티는 노드의 이름을 나타내는 문자열을 반환한다.

39.5 노드 요소의 텍스트 조작

1. nodeValue

nodeValue 프로퍼티는 getter와 setter 함수를 갖는 데이터 프로퍼티이다. 따라서 참조와 할당 모두 가능하다. 노드 객체의 값을 반환하고, 노드 객체의 값이란 텍스트 노드의 텍스트다. 요소 노드의 경우 null을 반환한다.

<div id="foo">Hello</div>

// 문서(document) 노드의 nodeValue 프로퍼티는 null을 반환한다.
console.log(document.nodeValue);  // null

// 요소 노드의 nodeValue 프로퍼티는 null을 반환한다.
console.log(document.getElementById('foo').nodeValue); // null

// 텍스트 노드의 nodeValue 프로퍼티는 텍스트를 반환한다.
console.log(document.getElementById('foo').firstChild.nodeValue); // Hello

2. textContent

nodeValue 와 마찬가지로 getter와 setter 함수를 갖는 데이터 프로퍼티이다. 요소 노드의 텍스트와 모든 자손 노드의 텍스트를 모두 취득하거나 변경할 수 있다.

nodeValue는 텍스트 노드의 텍스트만 취득하거나 변경할 수 있지만 textContent는 요소 노드의 텍스트와 모든 자손 노드의 텍스트를 모두 취득하거나 변경할 수 있다.

39.6 DOM 조작

새로운 노드를 생성하여 DOM에 추가하거나 기존 노드를 제거하거나 교체하는 등의 DOM을 조작하는 것. DOM 조작에 의해 새로운 노드가 추가되거나 삭제되면 리플로우와 리페인트가 발생한다. 이는 성능에 영향을 주므로 주의해야 한다.

innerHTML

innerHTML 프로퍼티는 HTML 문자열을 파싱하여 DOM을 생성하고 기존의 DOM을 제거한 후 새로운 DOM을 삽입한다. textContent 프로퍼티를 참조하면 텍스트만 취득할 수 있지만 innerHTML 프로퍼티를 참조하면 HTML 마크업이 포함된 문자열을 취득할 수 있다.

insertAdjacentHTML

insertAdjacentHTML 기존 요소를 제거하지 않고도 지정한 위치에 새로운 요소를 삽입할 수 있다.

노드 생성과 추가

1. createElement
2. createTextNode
3. appendChild

39.7 어트리뷰트

HTML 요소는 여러 개의 어트리뷰트를 가질 수 있다. 어트리뷰트는 HTML 요소의 부가 정보를 제공한다.

getAttribute, setAttribute 메서드는 요소 노드에서 직접 HTML 어트리뷰트 값을 취득하거나 변경할 수 있어서 편리하다.

HTML 어트리뷰트 vs DOM 프로퍼티

요소 노드 객체에는 HTML 어트리뷰트에 대응하는 DOM 프로퍼티가 존재한다. 이 DOM 프로퍼티들은 HTML 어트리뷰트의 값을 초기값으로 가지고 있다. DOM 프로퍼티는 HTML 어트리뷰트의 값을 변경하면 DOM 프로퍼티의 값도 자동으로 변경된다. 예를들어 input 요소에 value 어트리뷰트를 변경하면 value 프로퍼티의 값도 자동으로 변경된다.

그러면 HTML 어트리뷰트와 DOM 프로퍼티가 동시에 관리되고 있는 것 처럼 보이지만 사실은 그렇지 않다.

HTML 어트리뷰트의 역할은 변하지 않는 초기값을 제공하는 것이고, DOM 프로퍼티의 역할은 HTML 어트리뷰트의 값을 반영하는 것이다.

첫 렌더링 이후 HTML 어트리뷰트의 값은 DOM 프로퍼티에 의해 더 이상 참조되지 않는다.

즉, 요소 노드는 2개의 상태를 갖는다. 초기 상태와 최신 상태. 초기 상태는 HTML 어트리뷰트의 값이고, 최신 상태는 DOM 프로퍼티의 값이다.

39.8 스타일

style 프로퍼티는 인라인 스타일을 취득하거나 변경할 수 있다. CSS 프로퍼티는 케밥 케이스를 따른다. CSS 프로퍼티 background-color는 style 프로퍼티의 backgroundColor로 변경해야 한다.

브라우저의 렌더링 과정

1. 브라우저는 HTML, CSS, JS, 이미지, 폰트 등의 리소스를 서버로부터 요청하고 응답받는다.
2. 브라우저는 서버로부터 응답받은 HTML, CSS를 파싱하여 DOM, CSSOM을 생성하고 이들을 결합하여 렌더 트리를 생성한다.
3. 브라우저의 자바스크립트 엔진은 서버로부터 응답받은 JS를 파싱하여 AST(Abstract Syntax Tree)를 생성하고 바이트코드로 변환하여 실행한다. 이때 자바스크립트 엔진은 DOM API를 통해 DOM이나 CSSOM을 변경할 수 있다.
4. 렌더 트리를 기반으로 HTML 요소의 레이아웃을 계산하고 브라우저 화면에 HTML 요소를 페인트하여 브라우저 화면에 표시한다.

38.1 요청과 응답

브라우저는 서버로부터 HTML, CSS, JS, 이미지, 폰트 등의 리소스(정적 파일 또는 서버가 동적으로 생성한 데이터)를 요청하고 응답받는다.

38.2 HTTP 1.1과 HTTP 2.0

HTTP는 클라이언트와 서버 간에 요청과 응답으로 데이터를 교환하기 위한 통신 규약이다. HTTP를 왜 만들었는가? HTTP 등장 이전에는 FTP, SMTP, NNTP 등의 프로토콜이 존재했다. 각각 목적에 맞게 설계된 프로토콜이어서 서로 다른 프로토콜을 사용하는 서버와 클라이언트는 통신할 수 없었다. 이를 해결하기 위해 HTTP가 등장했다.

HTTP 1.1은 1997년에 등장했고 현재까지 가장 많이 사용되는 HTTP 프로토콜이다. 하나의 연결에 하나의 요청과 응답을 처리한다. HTTP 2.0은 하나의 연결에 여러 요청과 응답을 처리할 수 있다. HTTP 2.0을 적용한 웹 사이트는? Google, YouTube, Facebook, Twitter, Wikipedia 등등.

38.3 HTML 파싱과 DOM 생성

과정 설명

1. 요청이 발생하면 서버는 HTML, CSS, JS를 포함한 리소스를 응답한다. 이때 서버는 요청한 html 파일을 읽어들여 메모리에 저장한다음, 저장된 바이트를 인터넷을 경유하여 응답한다.
2. 브라우저는 서버가 응답한 html 파일을 바이트 형태로 읽어들인다. 그리고 읽어들인 바이트를 문자열로 변환한다.
3. 문자열로 변환된 문서를 읽어 들여 문법적 의미를 가진 최소 단위인 토큰으로 분해한다.
4. 분해된 토큰을 객체로 변환하여 노드들을 생성한다.
5. 생성된 노드들을 트리 구조로 구성한다. 이를 DOM(Document Object Model)이라 한다. CSSOM도 거의 비슷

38.5 렌더 트리

렌더 트리는 DOM과 CSSOM을 결합하여 생성한다.

38.6 자바스크립트 파싱과 실행

DOM은 HTML 요소와 스타일을 변경할 수 있는 API를 제공한다. DOM API 라고 하며, getElementById, querySelector, addEventListener 등이 있다. HTML, CSS와 마찬가지로 위에서 아래로 파싱되고 Abstract Syntax Tree(AST)를 생성한다. AST는 자바스크립트 엔진이 자바스크립트 코드를 실행하기 위해 필요한 구문을 추상적으로 표현한 트리 자료구조이다. 그리고 AST를 기반으로 바이트코드로 변환하여 실행한다.

38.7 리플로우와 리페인트

리플로우 : 레이아웃을 다시 계산하는 것 리페인트 : 레이아웃을 다시 그리는 것

느낀점

브라우저 렌더링 원리를 이해하면 DOM, 노드, AJAX, 이벤트, 비동기 처리, 렌더링 최적화 등을 이해하는데 도움이 될것 같다. 면접에서도 자주 물어보는 주제라서 중요한 파트다. Q. 브라우저의 렌더링 과정을 설명하시오. Q. Reflow와 Repaint가 실행되는 시점. Q. 주소창에 URL을 입력하면 어떤 일이 일어나는가? Q. CORS를 대응하는 방법은?

배열과 같은 이터러블 또는 객체를 destructuring(비구조화, 구조분해)하여 1개 이상의 변수에 개별적으로 할당하는 것. 필요한 값만 추출하여 변수에 할당할 때 유용하다.

36.1 배열 디스트럭처링 할당

const arr = [1,2,3]

// ES6 배열 디스트럭처링 할당
// 변수 one, two, three를 선언하고 배열 arr을 디스트럭처링하여 할당한다.
// 이때 할당 기준은 배열의 인덱스다.
const [one, two, three] = arr
console.log(one, two, three) // 1 2 3

배열 디스트럭처링 할당을 위해서는 할당 연산자 왼쪽에 배열 형태의 변수를 선언해야 한다. 이때 변수를 배열 리터럴 형태로 선언한다.

const [x, y] = [1, 2]

우변에 이터러블을 할당하지 않으면 에러가 발생한다.

또한 변수에 기본값을 설정해 줄 수 있으나 할당되는 값이 우선순위가 높다는 것을 기억해야 한다.

const arr = [1, 2];

const [one, two, three = 3] = arr;

console.log(one); // 1
console.log(two); // 2
console.log(three); // 3

Rest 파라미터 또한 구조분해에서 사용할 수 있다.

const arr = [1, 2, 3];

const [one, ...other] = arr;

console.log(one); // 1
console.log(other); // [2, 3]

36.2 객체 디스트럭처링 할당

객체를 구조분해하기 위해서는 변수명을 객체에서 사용하고 있는 프로퍼티키로 사용해야 한다. 즉 할당의 기준이 배열과 같이 인덱스가 아니라 프로퍼티 키. 또한 배열과 다르게 할당하고자 하는 변수들을 중괄호({})로 묶어줘야 한다.

const name = {
  firstName: 'bs',
  lastName: 'choi'
}

const {lastName, firstName} = name;

console.log(firstName); // bs
console.log(lastName); // choi

또한 다른 변수 이름으로 할당받을 수도 있다.

const name = {
  firstName: 'bs',
  lastName: 'Choi'
}

const {lastName: two, firstName: one} = name;

console.log(one); // bs
console.log(two); // Choi

배열의 요소가 객체인 경우 디스트럭처링 할당과 객체 디스트럭처링 할당을 혼용할 수 있다.

const todos = [
  { id: 1, content: 'HTML', completed: true },
  { id: 2, content: 'CSS', completed: false },
  { id: 3, content: 'Javascript', completed: true },
];

// todos 배열의 첫 번째 요소인 객체로부터 id 프로퍼티만 추출한다.
const [, { id }] = todos;
console.log(id); // 2

정규 표현식은 문자열을 대상으로 패턴 매칭 기능을 제공하는 문자열의 구조를 파악하는 데 사용하는 패턴

• 문자에 한글이 들어가 있는지
• 이메일 형식이 맞는지
• 숫자로 시작하는지 등

문자 형식을 검증할 때 사용한다. 거의 모든 언어에서 지원한다.

정규 표현식이 어려운 이유

1. 정규 표현식은 암기해야 할 문법이 많다.
2. 예측이 어렵다.
3. 잘못 작성한 정규 표현식은 애플리케이션을 정지시킬 수 있다.

그래서 대부분 라이브러리나 AI의 도움을 받는다.

📌 32장 String

String 빌트인 객체는 문자열을 다룰 때 유용한 프로퍼티와 메소드를 제공한다. 사용법은 다른 빌트인 객체와 동일하게 new 연산자를 사용하여 인스턴스를 생성한다. Array와 마찬가지로 indexOf, slice, length 등의 프로퍼티와 메소드를 사용할 수 있다.

메서드를 나열하기 보다는 Array와 String을 비교하며 느낀점을 적는 것이 좋을것 같다.

Array 객체는 데이터를 순서대로 저장할 수 있다는 장점이 있다. 또한, Array 객체는 다양한 메서드와 속성을 제공하여 데이터를 쉽게 처리할 수 있다.

String 객체는 데이터를 문자열로 저장할 수 있다는 장점이 있다. 또한, Array 객체와 달리 순서가 없기 때문에 데이터를 순서대로 처리할 수 없다는 점이 있는데, 단점이자 장점같다.

따라서, Array 객체와 String 객체 중 어느 객체를 사용할지는 데이터의 특성에 따라 다르다. 만약, 데이터를 순서대로 저장하고, 다양한 메서드와 속성을 사용하여 데이터를 처리해야 한다면 Array 객체를 사용하는 것이 좋고 정규식이 필요하거나 문자열의 길이와 구조를 변경할 필요가 없는 경우 String 객체를 사용하는 것이 좋을 것 같다.

📌 33장 Symbol

7번째 자료형. 변경 불가능한 원시 타입의 값이다. 심벌 값은 다른 값과 중복되지 않는 유일무이한 값이다. 따라서 주로 이름의 충돌 위험이 없는 유일한 객체의 프로퍼티 키를 만들기 위해 사용한다.

심볼 함수에는 선택적으로 설명을 붙일 수 있다. 이 설명은 디버깅 용도로만 사용되며 심벌 값에 영향을 주지 않는다. 즉, 설명이 같은 심벌 값도 다른 심벌 값이다.

변수처럼 같은 값을 가지면 같은 변수로 취급해주는 전역 심볼을 만들어쓸 수 있다. Symbol.for() 를 사용하면 된다.

33.7 Well-Known Symbol

자바스크립트는 기본으로 제공하는 빌트인 심벌 값을 제공한다. Array나 Object 같은 자료형을 만들 때 암묵적으로 사용되는 심벌 값이다.

예를 들면 Array, String 등의 경우 Symbol.iterator를 키로 갖는 메서드를 가지고 있다. 이 메서드는 이터레이터를 반환한다고 규정되어있다. 빌트인 이터러블은 이터레이션 프로토콜을 준수한다.

어디에 사용할 수 있을까?

1. 유일한 식별자를 만들어야 할 때
2. 숨길 수 있는 프로퍼티를 만들 때. 외부 코드에서 접근할 수 없는 프로퍼티를 만들 수 있다. 예를 들어 객체에 심벌을 사용하면 for...in, for...of 문으로 순회할 수 없다. enumerate 할 수 없다는 뜻이다. 그래서 JSON.stringify() 에서도 제외된다.

📌 34장 이터레이션 프로토콜

ES6에서 도입된 이터레이션 프로토콜은 순회 가능한 객체를 만들기 위한 규약이다. 이전에는 배열, 문자열 등은 각자 나름의 방식으로 순회(for문, for...in문, forEach 메서드 등)했지만, ES6에서는 순회 가능한 데이터 컬렉션을 프로토콜을 준수하는 객체로 통일하여 for...of, 스프레드 문법, 배열 디스트럭쳐링 할당의 대상으로 일원화했다.

이터레이션 프로토콜은 덕 타이핑을 통해 구현된다.

덕 타이핑 사람이 오리처럼 행동하고 오리처럼 생겼으면 오리다. 실제 타입은 상관없고 구현된 메서드가 같으면 같은 타입으로 간주한다. 즉, 객체의 구조가 프로토콜을 충족하면 이터러블로 간주한다.

프로토콜을 충족하려면 객체의 프로퍼티에 Symbol.iterator가 있어야 하고, 이것은 이터레이터를 반환하는 함수여야 한다. 이터레이터는 next 메서드를 갖는다.

next 메서드는 다시 value와 done 프로퍼티를 갖는 객체를 반환한다. 이터레이션 프로토콜은 이터러블 프로토콜, 이터레이터 프로토콜로 구성된다.

이터러블인지 확인하는 함수 (615p)

const isIterable = v => v !== null && typeof v[Symbol.iterator] === 'function';

console.log(isIterable([])); // true
console.log(isIterable('')); // true
console.log(isIterable(new Map())); // true
console.log(isIterable(new Set())); // true
console.log(isIterable({})); // false

const obj = { a: 1, b: 2 };

console.log(Symbol.iterator in obj); // false

// 이터러블이 아닌 객체는 for...of 문에서 순회할 수 없다.
for (const p of obj) {
  console.log(p);
}

단, 일반 객체에 스프레드 문법을 사용할 수 있도록 허용한다.

느낀 점

프로젝트 중에 for...in 문을 사용한 부분이 있었는데, 이 부분을 for...of 문으로 바꾸니까 값이 제대로 나오지 않았다.

이유를 찾으려고 에전에 검색했던 내용을 다시 찾아보았는데, 그 때 당시에는 이터러블에 대한 개념이 없어서 이해하지 못했었다.

이번에 이터러블에 대해 공부하고 나니까 이해가 되었다. for...in 문은 객체의 프로퍼티를 순회하지만 for...of 문은 이터러블을 순회하기 때문에 값이 제대로 나오지 않았던 것으로 이해된다.

📌 35장 스프레드 문법

하나로 뭉쳐있는 여러 값들을 펼쳐서 사용할 수 있게 해주는 문법. Array, Object, String, Map, Set, DOM collection 등 for...of 문으로 순회할 수 있는 이터러블은 모두 스프레드 문법의 대상이 될 수 있다.

// ...[1, 2, 3]은 [1, 2, 3]을 개별 요소로 분리한다.(-> 1, 2, 3)
console.log(...[1, 2, 3]); // 1 2 3

// 문자열은 이터러블이다.
console.log(...'Hello'); // H e l l o

// Map과 Set은 이터러블이다.
console.log(...new Map([['a', '1'], ['b', '2']])); // [ 'a', '1' ] [ 'b', '2' ]
console.log(...new Set([1, 2, 3])); // 1 2 3

// 이터러블이 아닌 일반 객체는 스프레드 문법의 대상이 될 수 없다.
console.log(...{ a: 1, b: 2 }); // TypeError: Found non-callable @@iterator

스프레드 문법의 결과물을 값으로 사용할 수 없고, 쉼표로 구분된 값의 목록이 필요한 문맥에서만 사용할 수 있다.

• 함수 호출문의 인수 목록
• 배열 리터럴의 요소 목록
• 객체 리터럴의 프로퍼티 목록

Rest 파라미터 / Spread 문법 비교

1. Rest 파라미터 Rest 파라미터는 함수의 파라미터 선언에서 사용되는 문법이다. Rest 파라미터는 함수에 전달된 아규먼트들을 배열로 나타낸다

   이 배열은 함수 내에서 배열로 처리할 수 있으며, 함수 호출 시 전달된 인수의 개수와 상관없이 모든 아규먼트를 배열로 받을 수 있다. Rest 파라미터는 함수 정의에서 마지막 파라미터로만 사용할 수 있으며, 매개변수 이름 앞에 세 개의 점(...)을 붙여서 표현한다.

function myFunction(...args) {
  console.log(args);
}

myFunction(1, 2, 3, 4, 5); // [1, 2, 3, 4, 5]

2. Spread 문법 Spread 문법은 배열이나 객체를 펼쳐서 개별 요소로 확장하는 문법이다. Spread 문법은 배열 또는 객체 앞에 세 개의 점(...)을 붙여서 사용한다. 배열을 Spread 문법으로 확장하면 개별 요소가 된다.

const arr = [1, 2, 3];
const newArr = [...arr, 4, 5];

console.log(newArr); // [1, 2, 3, 4, 5]

배열에는 원본 배열을 직접 변경하는 메서드와 원본 배열을 직접 변경하지 않고 새로운 배열을 생성하여 반환하는 메서드가 있다.

27.8.1 Array.isArray

Array.isArray 메서드는 인수가 배열이면 true, 배열이 아니면 false를 반환한다.

27.8.2 Array.prototype.indexOf

Array.prototype.indexOf 메서드는 인수로 전달된 배열 요소를 검색하여 인덱스를 반환한다. 배열 요소가 여러 개 존재하더라도 처음으로 검색된 요소의 인덱스만 반환한다. 배열 요소가 존재하지 않으면 -1을 반환한다.

사용 예시 : 장바구니에 이미 있는 상품을 추가하려 할 때 사용

솔직히 includes 메서드가 더 편한듯.

push : 배열의 끝에 요소를 추가한다. pop : 배열의 마지막 요소를 제거하고 제거한 요소를 반환한다. unshift : 배열의 첫 번째 요소로 요소를 추가한다. shift : 배열의 첫 번째 요소를 제거하고 제거한 요소를 반환한다.

Array.prototype.splice 와 Array.prototype.slice 의 차이점

splice : 원본 배열을 직접 변경한다. slice : 원본 배열을 직접 변경하지 않고 새로운 배열을 생성하여 반환한다.

28장 Number

• 빌트인 객체 Number는 원시 타입인 숫자를 다룰 때 유용한 프로퍼티와 메서드를 제공한다.

28.1 Number 생성자 함수

표준 빌트인 객체인 Number는 생성자 함수다. 따라서 new 연산자와 함께 호출하여 인스턴스를 생성할 수 있다.

563p Math.random

난수 생성하는 메서드. 0에서 1미만. 주로 단독으로 사용하지 않고 다른 메서드와 함께 사용한다.

1부터 9까지 난수 생성 코드

Math.floor(Math.random() * 9) + 1;

1부터 43까지 난수 생성 코드

Math.floor(Math.random() * 43) + 1;

29장 Math

표준 빌트인 객체 Math는 상수와 함수를 위한 프로퍼티와 메서드를 제공한다. 생성자 함수가 아니고 정적 프로퍼티와 정적 메서드만 제공한다.

30장 Date를 활용한 시계 예제.

function generateLottoNumbers() {
  let lottoNumbers = new Set();

  while (lottoNumbers.size < 6) {
    let randomNumber = Math.floor(Math.random() * 45) + 1;
    lottoNumbers.add(randomNumber);
  }

  return Array.from(lottoNumbers);
}

const koreanLottoNumbers = generateLottoNumbers();
console.log(koreanLottoNumbers);

let words = ["spray", "limit", "elite", "exuberant", "destruction", "present"];
const appendedWords = words.filter((word, index, arr) => {
  arr.push("new");
  return word.length < 6;
});

// 30.3 Date를 활용한 시간 예제

(function printNow() {
  const today = new Date();

  const dayNames = ['(일요일)', '(월요일)', '(화요일)', '(수요일)', '(목요일)', '(금요일)', '(토요일)'];

  // getDay: 요일을 나타내는 정수를 반환한다. (0 ~ 6)
  const day = dayNames[today.getDay()];

  const year = today.getFullYear();
  const month = today.getMonth() + 1;
  const date = today.getDate();
  let hour = today.getHours();
  let minute = today.getMinutes();
  let second = today.getSeconds();
  const ampm = hour >= 12 ? 'PM' : 'AM';

  // 12시간제로 변경
  hour %= 12;
  hour = hour || 12; // 0 => 12

  // 10미만인 분과 초를 2자리로 변경
  minute = minute < 10 ? '0' + minute : minute;
  second = second < 10 ? '0' + second : second;

  const now = `${year}년 ${month}월 ${date}일 ${day} ${hour}:${minute}:${second} ${ampm}`;

  console.log(now);

  setTimeout(printNow, 1000);
})();

느낀 점

1. 배열 메서드가 정말 다양하다. 종류가 많기도하고 자주쓰는 메서드들이기 때문에 주의하며 사용해야 할것 같다.

2. Date 객체는 많이 불편하다. 날짜와 시간 처리가 복잡하고 정확성에서도 의문이 남는다. 달력을 구현할 때도 인덱스 처리 (1월은 0으로 시작) 때문에 불편했던 경험이 있다. 메서드 종류나 원리만 알고 라이브러리를 쓰는 것도 좋을듯.

ES6 이전의 모든 함수는 일반 함수로서 호출할 수 있는 것은 물론 생성자 함수로서 호출할 수 있다.

var foo = function () {
    return 1;
};

// 일반적인 함수로서 호출
foo(); // 1

// 생성자 함수로서 호출
new foo(); // foo {}

// 메서드로서 호출
var obj = { foo: foo };
obj.foo(); // 1

26.2 메서드

ES6 사양에서 메서드는 메서드 축약 표현으로 정의된 함수만을 의미한다. ES6 메서드는 자신을 바인딩한 객체를 가리키는 내부 슬롯 [[HomeObject]]를 갖는다.

26.3 화살표 함수

함수를 더 간결하게 작성할 수 있는 문법적인 편의를 제공하는 JavaScript의 기능이다.

class Prefixer {
    constructor(prefix) {
        this.prefix = prefix;
    }

    add(arr) {
        return arr.map(function (item) {
            return this.prefix + item;
        });
    }
}

const prefixer = new Prefixer('-webkit-');
console.log(prefixer.add(['transition', 'user-select']));

기대값 : ["-webkit-transition", "-webkit-user-select"] 실제값 : TypeError: Cannot read properties of undefined (reading 'prefix')

기대값과 실제값이 다른이유

1. 메서드 내부에서 this를 사용하면 메서드를 호출한 객체를 가리킴. -> Prefixer 객체
2. map 메서드의 콜백 함수 내부에서 this를 사용하면 전역 객체를 가리킴. -> window
3. 하지만 this는 undefined를 가리킨다.
4. 왜냐하면, 클래스 내부의 모든 코드는 엄격 모드(strict mode)로 실행되고,
5. strict mode에서 함수를 일반 함수로서 호출하면 this에 undefined가 바인딩되기 때문이다.

이런 원하지 않는 결과값을 해결하기 위해 480p 까지 다양한 해결법이 존재. 그 중 하나가 화살표 함수를 사용하는 것. 화살표 함수는 함수 자체의 this 바인딩을 갖고 있지 않기 때문에 상위 스코프의 this를 그대로 참조한다.

const person = {
    name: 'Lee',
    sayHi: () => console.log(`Hi ${this.name}`)
};

person.sayHi(); // Hi

화살표 함수는 메서드로 사용하기에는 적합하지 않다. sayHi 메서드 내부의 this는 메서드를 소유한 객체, 즉 person 객체를 가리키지 않고 상위 스코프인 전역 객체를 가리키기 때문이다. super, arguments도 상위 스코프의 super, arguments를 가리킨다.

느낀점

1. ES6 이전의 모든 함수는 일반 함수로서 호출할 수 있는 것은 물론 생성자 함수로서 호출할 수 있었기 때문에 문법상 가능은 하지만 결과나 성능에 대해서 원치 않는 결과를 불러올 수 있겠다라는 생각이 들었다.

2. 화살표 함수는 constructor, prototype, super, arguments 바인딩을 갖고 있지 않기 때문에 개발자가 의도한 대로 더 간결한 코드, 가독성을 가져올 수 있는 것 같다.