ji-frontdev

2024년 vs 2025년 AI 트렌드, 뭐가 달라졌을까?

ji-frontdev — Fri, 22 Aug 2025 07:00:39 +0900

AI는 매년 상상 이상의 속도로 발전하고 있습니다.
2024년이 ‘AI 대중화의 시작’을 알린 해였다면, 2025년은 ‘초개인화 & 실질적 가치 창출’의 시대로 자리 잡고 있습니다.
이번 포스팅에서는 2024년과 2025년 AI 트렌드를 비교하고, 각 산업별 활용 현황을 정리해보겠습니다.

2024년 AI 트렌드: 대중화의 시작

1. AI의 대중화

기업들이 AI를 속속 도입하며 업무 효율 & 고객 경험 개선에 집중
특히 Generative AI가 디자인, 마케팅, 콘텐츠 제작에서 혁신 주도 ✨

2. Generative AI 확산

텍스트, 이미지, 음악 생성까지 가능한 창조형 AI
맞춤형 콘텐츠 제작 & 마케팅 강화에 활용

3. 산업별 AI 활용 확대

금융 : 사기 탐지 & 리스크 평가
의료 : 영상 분석 & 신약 개발 지원
제조업 : 스마트 팩토리, 품질 관리

4. AI 플랫폼 성장

기업들이 쉽게 AI를 도입하도록 지원
기술적 장벽 → 낮추고, 접근성 → 높임

5. 윤리적 AI 논의

"AI가 어떻게 결정했는가?"에 대한 투명성 요구 증가
기업마다 윤리 가이드라인 마련

2025년 AI 트렌드: 초개인화 & 실질적 가치

1. 초개인화 (Hyper-Personalization)

고객 행동·취향·맥락 기반 맞춤형 서비스
마케팅, 금융, 의료 등에서 개인별 AI 경험 제공

2. 실질적 가치 창출

단순 효율화 → 새로운 비즈니스 모델 창출
AI가 이제는 전략적 자산으로 격상

3. 산업 맞춤형 AI

의료 : 환자 데이터 기반 맞춤 치료
농업 : 작물 성장 예측 & 스마트 농기계
관광 : 개인 여행 추천 & 자동화 예약

4. AI 에이전트의 성장

고객 상담, 정보 제공 등 상호작용형 에이전트 대중화
사람과 대화하듯 AI와 상호작용하는 시대

5. 설명 가능한 AI (Explainable AI)

"AI가 왜 그렇게 판단했는지"를 투명하게 설명
신뢰도 & 책임성 강화

6. 멀티모달 AI

텍스트, 이미지, 음성까지 동시 이해 & 처리
UX를 한층 더 풍부하게

7. AI M&A 활발화

AI 스타트업 ↔ 빅테크 기업 간 기술 확보 경쟁
M&A를 통한 생태계 가속화

산업별 AI 활용 현황

금융 : 사기 탐지, 리스크 평가
의료 : 의료 이미지 분석, 개인 맞춤형 치료
제조업 : 생산 최적화, 품질 관리
농업 : 스마트 농기계, 작물 성장 예측
✈️ 관광 : 맞춤형 여행 추천, 예약 자동화
미디어 : 콘텐츠 추천, 자동 뉴스 생성
⚖️ 법률 : 계약 분석, 법률 상담

산업마다 AI가 적용되는 방식은 다르지만, 공통적으로 생산성과 효율성 → 극대화하고 있습니다.

이미지 출처

AI의 미래 전망

앞으로 AI는 더 넓고, 더 깊게 우리의 삶에 스며들 것입니다.

AI의 보편화 : 모든 산업 & 일상 속으로 확산
AI와 인간 협업 : 인간의 창의성 + AI의 연산 능력 → 시너지 극대화
정교화 & 고도화 : 점점 더 스마트한 AI로 진화

결론적으로, 2024년의 AI가 “대중화의 문을 열었다면”,
2025년의 AI는 **“가치를 창출하며 삶을 바꾸는 동반자”**로 자리 잡고 있습니다.

마무리 한 줄
AI는 이제 기술 그 이상입니다.
우리가 어떻게 활용하느냐에 따라 미래의 경쟁력이 달라질 것입니다.

#AI#AI트렌드 #2024AI #2025AI #GenerativeAI #산업별AI #초개인화 #AI에이전트 #AI윤리 #AI미래

정육각, 초록마을 인수 후.. 유니콘 후보에서 회생 절차까지

ji-frontdev — Fri, 15 Aug 2025 11:03:19 +0900

정육각, 초록마을 인수 후 자본잠식… 무엇이 잘못되었나?

초록마을

정육각

기술 관점에서 본 기업 분석

유니콘 후보에서 회생 절차까지

2016년 설립된 정육각은 "도축 후 4일 이내 배송"을 핵심 가치로 내세운 푸드테크 스타트업입니다.
2019~2021년 동안 누적 투자금 약 1,200억 원을 유치했고,

2022년에는 기업가치 4,000억 원을 인정받아 유니콘 후보로 주목받았습니다.

같은 해, 정육각은 유기농·친환경 식품 유통업체 초록마을을 약 900억 원에 인수했습니다.

하지만 3년도 채 되지 않아 양사 모두 자본잠식과 회생 절차에 들어갔습니다.

[내 분석] "온라인 신선식품 기술 + 전국 오프라인 유통망"의 시너지를 노린 전략으로 보이지만, 결과적으로는 기술과 사업모델의 부조화가 주요 실패 원인이었다고 판단됩니다.

️ 정육각의 기술적 강점 (공개 정보 기반)

정육각은 다음과 같은 IT 기반 신선식품 공급망(SCM) 기술을 보유했다고 공개했습니다:

데이터 기반 수요 예측

판매량 패턴을 머신러닝으로 분석해 재고와 도축량 최적화
AI 기반 수요 예측 시스템 운영

콜드체인 물류 자동화

자체 시스템으로 발주, 패킹, 배송까지 실시간 관리
온도 관리 자동화 시스템

도축-배송 시간 단축

농장, 도축장, 물류센터 데이터 연동 시스템
'초신선' 기준 유지를 위한 통합 플랫폼

풀필먼트 통합 플랫폼

B2C 및 B2B 납품 물량 통합 관리 시스템

초록마을 인수: 기대와 현실

인수 당시의 기대 효과 (언론 보도 기반)

언론에서는 다음과 같은 시너지 효과를 기대한다고 보도했습니다:

초록마을의 300여 개 매장을 통한 오프라인 확장
유기농 야채, 가공식품 등 제품 포트폴리오 다각화
프리미엄·신선 브랜드 이미지 상호 강화

실제 결과

인수 후 다음과 같은 문제들이 발생했습니다:

인수 자금 900억 원 중 370억 원을 단기 차입으로 조달(*단기 차입: 다른 외부로부터 빌린 돈)
코로나19 이후 오프라인 매장 방문객 감소
2023-2024년 투자 시장 위축으로 추가 자금 유치 실패

[내 분석]

기술-제품 부조화 문제: 정육각의 초신선 공급망 기술은 빠른 회전율을 가진 신선 정육에 최적화되어 있었습니다. 반면 초록마을의 주력 상품인 가공·포장 유기농식품은 상대적으로 긴 유통기한을 가지며 다른 공급망 구조를 필요로 합니다. 이는 마치 F1 레이싱카로 일반 도로를 달리는 것과 같은 기술-사업 불일치였다고 봅니다.

타이밍의 불운: 코로나19라는 예측 불가능한 변수가 오프라인 중심의 초록마을 사업에 치명타를 가했습니다. 하지만 이런 리스크에 대한 사전 대비가 부족했던 것으로 판단됩니다.

자본잠식 과정 (공개 자료 기반)

공개된 재무 정보를 바탕으로 한 자본잠식 경로:

1단계: 인수 직후 (2022년)

900억 원 인수 자금 중 370억 원 차입금 발생
재무 레버리지 급상승
통합 비용 증가

2단계: 외부 환경 악화 (2023년)

투자 시장 위축으로 추가 자금 조달 실패
물가 상승 및 소비 위축
매출 성장 둔화

3단계: 현금흐름 악화 (2024년)

지속적인 기술 투자 및 마케팅 비용
운영비 증가
현금 소진 가속화

4단계: 자본잠식 (2024년 말)

누적 손실이 자본금 초과
회생 절차 신청

재무적으로 보면 정육각은 매출은 늘었지만, 계속해서 큰 영업손실

2019년: 매출 41억, 영업손실 26억

2020년: 매출 162억, 영업손실 79억

2021년: 매출 401억, 영업손실 249억

2023년: 매출 282.5억, 영업손실 67.4억, 당기순손실 314.8억

초록마을도 상황이 좋지 않음

2022년: 영업손실 82억

2023년: 영업손실 67억

단계별로 보면 재무 위험 관리의 부재가 가장 큰 문제였다고 생각합니다. 특히 대규모 인수 시 최악의 시나리오에 대한 대비책이 부족했던 것으로 보입니다.

기술 관점에서의 핵심 문제 분석

1. 시스템 아키텍처의 한계

정육각의 SCM 시스템은 고속회전 상품군에 특화된 아키텍처로 설계되었을 것입니다. 실시간 재고 관리, 빠른 의사결정 프로세스, 짧은 리드타임 최적화 등이 핵심이었겠죠. 하지만 이런 시스템을 저속회전 상품군에 그대로 적용하면 오히려 오버엔지니어링이 되어 비효율을 초래합니다.

2. 데이터 품질과 예측 정확도

온라인 거래 데이터는 실시간성과 정확도가 높지만, 오프라인 매장 데이터는 그렇지 않습니다. 결국 AI 모델의 입력 데이터 품질이 떨어지면서 예측 정확도도 함께 하락했을 것입니다.

3. 기술 투자 ROI의 급속한 악화

시스템 확장과 유지보수 비용은 기하급수적으로 증가하는 반면, 매출 증가는 선형적이었을 가능성이 높습니다. 특히 서로 다른 사업 모델을 하나의 플랫폼에서 운영하려다 보니 복잡성만 늘어났을 것입니다.

사례에서 배우는 교훈

정육각-초록마을 사례는 높은 기업가치를 인정받은 푸드테크 스타트업도 M&A 후 3년 내에 회생 절차에 들어갈 수 있음을 보여준 실제 사례입니다.

[내가 생각하는 핵심 교훈들]

1. 기술의 도메인 특화성을 간과하지 말자

아무리 뛰어난 기술이라도 특정 도메인에 최적화된 경우, 다른 영역으로의 확장은 신중해야 합니다. 기존 기술을 재활용하려는 욕심보다는, 새로운 도메인에 맞는 별도의 기술 스택을 고려하는 것이 더 현명할 수 있습니다.

2. M&A는 기술 통합이 아닌 사업 통합이다

많은 기술 기업들이 M&A를 통해 기술적 시너지를 기대하지만, 실제로는 사업 모델, 조직 문화, 고객층의 통합이 더 중요합니다. 기술은 그 다음 문제입니다.

3. 현금흐름이 기술보다 우선이다

아무리 혁신적인 기술을 보유해도 현금이 떨어지면 게임 오버입니다. 특히 대규모 인수 시에는 보수적인 재무 계획이 필수입니다.

4. 시장 환경 변화에 대한 민감도를 높여야 한다

코로나19 같은 외부 충격은 예측하기 어렵지만, 그런 상황에서도 생존할 수 있는 사업 구조를 미리 고민해야 합니다.

마무리

정육각은 2016년 설립부터 2024년 회생 절차까지 8년간의 여정, 초록마을과의 합병은 2022년부터 시작되어 약 2년 만에 실패로 끝났습니다.

이 사례를 보면서 느끼는 점은, 기술 중심 스타트업일수록 기술과 비즈니스의 균형감각이 더욱 중요하다는 것입니다. 기술은 문제를 해결하는 도구일 뿐이고, 어떤 문제를 풀 것인지, 어떤 시장에서 어떻게 수익을 낼 것인지가 더 근본적인 질문입니다.

정육각의 기술은 분명 인상적이었습니다. 하지만 그 기술을 잘못된 방향으로 확장하려다가 결국 본업의 경쟁력마저 잃게 된 것 같아 아쉽습니다.

[react/ts] 한글 Base64 디코딩 삽질기: atob만으로는 안 되는 이유와 해결법(atob,escape,decodeURIComponent,TextDecoder)

ji-frontdev — Wed, 6 Aug 2025 05:45:46 +0900

삽질의 시작

React 프로젝트를 진행하던 중, 서버에서 Base64로 인코딩된 한글 데이터를 받아서

클라이언트에서 디코딩해야 하는 상황이 생겼습니다.

"Base64 디코딩이야 간단하지!" 하며 당연히 atob()를 사용했는데...

// 서버에서 받은 Base64 인코딩된 한글
const base64Data = "7JWI64WV7ZWY7IS47JqU"; // "안녕하세요"를 base64로 인코딩한 값

// 단순한 접근
const decoded = atob(base64Data);
console.log(decoded); // ì???íì¸ì! (깨진 한글...)

결과는 참담한 한글 깨짐 현상이었습니다. 분명 서버에서는 제대로 인코딩했는데 왜 깨질까요?

이 문제를 해결하기 위해 escape와 decodeURIComponent를 사용해야 했고,

그 과정에서 인코딩/디코딩의 원리를 제대로 이해하게 되었습니다.

문제의 원인: atob()의 한계

atob()는 Latin-1만 지원

브라우저의 atob() 함수는 Latin-1(ISO-8859-1) 문자 집합을 기준으로 동작합니다. 이는 1바이트로 표현되는 서구권 문자만 올바르게 처리할 수 있다는 의미입니다.

// ASCII/Latin-1 문자는 정상 동작
const englishBase64 = btoa("Hello World");
console.log(englishBase64); // "SGVsbG8gV29ybGQ="
console.log(atob(englishBase64)); // "Hello World" ✅

// 하지만 한글은...
const koreanText = "안녕하세요";
// btoa(koreanText); // ❌ DOMException 발생!

UTF-8과 Latin-1의 차이점

// 문자별 바이트 분석
const analyzeText = (text: string) => {
  const utf8Bytes = new TextEncoder().encode(text);
  console.log(`"${text}"`);
  console.log(`UTF-8 bytes: [${Array.from(utf8Bytes).join(', ')}]`);
  console.log(`Byte length: ${utf8Bytes.length}`);
};

analyzeText("A");      // UTF-8: [65], Latin-1과 동일
analyzeText("안");     // UTF-8: [236, 149, 136], 3바이트!
analyzeText(" ");     // UTF-8: [240, 159, 140, 159], 4바이트!

올바른 해결법: 단계별 접근

1. 전통적인 방법 (Deprecated)

// ⚠️ Deprecated 방법이지만 여전히 작동
const decodeBase64Korean = (base64String: string): string => {
  try {
    // 1. Base64 디코딩
    const decoded = atob(base64String);
    
    // 2. escape로 URL 인코딩 형태로 변환
    const escaped = escape(decoded);
    
    // 3. decodeURIComponent로 UTF-8 디코딩
    const result = decodeURIComponent(escaped);
    
    return result;
  } catch (error) {
    console.error('Base64 디코딩 실패:', error);
    return '';
  }
};

// 사용 예시
const base64Data = "7JWI64WV7ZWY7IS47JqU";
const decoded = decodeBase64Korean(base64Data);
console.log(decoded); // "안녕하세요" ✅

2. 모던 방법: TextDecoder 활용

const decodeBase64KoreanModern = (base64String: string): string => {
  try {
    // 1. Base64를 Uint8Array로 변환
    const binaryString = atob(base64String);
    const bytes = new Uint8Array(binaryString.length);
    
    for (let i = 0; i < binaryString.length; i++) {
      bytes[i] = binaryString.charCodeAt(i);
    }
    
    // 2. TextDecoder로 UTF-8 디코딩
    const decoder = new TextDecoder('utf-8');
    return decoder.decode(bytes);
  } catch (error) {
    console.error('Base64 디코딩 실패:', error);
    return '';
  }
};

3. 가장 모던한 방법: Web API 활용

// 최신 브라우저 지원 (IE 제외)
const decodeBase64KoreanWebAPI = async (base64String: string): Promise<string> => {
  try {
    // Base64 문자열을 Blob으로 변환
    const response = await fetch(`data:text/plain;base64,${base64String}`);
    const text = await response.text();
    return text;
  } catch (error) {
    console.error('Base64 디코딩 실패:', error);
    return '';
  }
};

React에서 실전 활용

커스텀 훅으로 만들기

import { useState, useCallback } from 'react';

interface UseBase64DecoderReturn {
  decode: (base64String: string) => string;
  isLoading: boolean;
  error: string | null;
}

export const useBase64Decoder = (): UseBase64DecoderReturn => {
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  const decode = useCallback((base64String: string): string => {
    setIsLoading(true);
    setError(null);

    try {
      // 입력값 검증
      if (!base64String || typeof base64String !== 'string') {
        throw new Error('유효하지 않은 Base64 문자열입니다.');
      }

      // Base64 형식 검증
      const base64Regex = /^[A-Za-z0-9+/]*={0,2}$/;
      if (!base64Regex.test(base64String)) {
        throw new Error('Base64 형식이 올바르지 않습니다.');
      }

      // 디코딩 실행
      const binaryString = atob(base64String);
      const bytes = new Uint8Array(binaryString.length);
      
      for (let i = 0; i < binaryString.length; i++) {
        bytes[i] = binaryString.charCodeAt(i);
      }
      
      const decoder = new TextDecoder('utf-8');
      const result = decoder.decode(bytes);
      
      setIsLoading(false);
      return result;
    } catch (err) {
      const errorMessage = err instanceof Error ? err.message : '디코딩 중 오류가 발생했습니다.';
      setError(errorMessage);
      setIsLoading(false);
      return '';
    }
  }, []);

  return { decode, isLoading, error };
};

React 컴포넌트에서 사용

import React, { useState } from 'react';
import { useBase64Decoder } from './hooks/useBase64Decoder';

const Base64DecoderComponent: React.FC = () => {
  const [input, setInput] = useState('');
  const [result, setResult] = useState('');
  const { decode, isLoading, error } = useBase64Decoder();

  const handleDecode = () => {
    const decoded = decode(input);
    setResult(decoded);
  };

  return (
    <div className="p-4 max-w-md mx-auto">
      <h2 className="text-xl font-bold mb-4">Base64 한글 디코더</h2>
      
      <div className="mb-4">
        <label className="block text-sm font-medium mb-2">
          Base64 문자열:
        </label>
        <input
          type="text"
          value={input}
          onChange={(e) => setInput(e.target.value)}
          className="w-full p-2 border rounded"
          placeholder="7JWI64WV7ZWY7IS47JqU"
        />
      </div>

      <button
        onClick={handleDecode}
        disabled={isLoading || !input}
        className="w-full bg-blue-500 text-white p-2 rounded disabled:opacity-50"
      >
        {isLoading ? '디코딩 중...' : '디코딩'}
      </button>

      {error && (
        <div className="mt-4 p-2 bg-red-100 text-red-700 rounded">
          {error}
        </div>
      )}

      {result && (
        <div className="mt-4 p-2 bg-green-100 rounded">
          <strong>결과:</strong> {result}
        </div>
      )}
    </div>
  );
};

export default Base64DecoderComponent;

서버와의 협업 시 고려사항

1. 서버 측 인코딩 확인

// Node.js 서버에서 올바른 인코딩
const text = "안녕하세요";
const base64 = Buffer.from(text, 'utf8').toString('base64');
console.log(base64); // "7JWI64WV7ZWY7IS47JqU"

2. API 응답 헤더 확인

// Fetch 시 응답 헤더 확인
const fetchData = async () => {
  const response = await fetch('/api/data');
  const contentType = response.headers.get('content-type');
  console.log('Content-Type:', contentType); // application/json; charset=utf-8
  
  const data = await response.json();
  return data;
};

3. TypeScript 타입 정의

interface ApiResponse {
  encodedMessage: string; // Base64 인코딩된 메시지
  timestamp: number;
  userId: string;
}

interface DecodedMessage {
  originalMessage: string; // 디코딩된 원본 메시지
  decodedAt: Date;
}

const processApiResponse = (response: ApiResponse): DecodedMessage => {
  const { decode } = useBase64Decoder();
  
  return {
    originalMessage: decode(response.encodedMessage),
    decodedAt: new Date()
  };
};

인코딩/디코딩의 핵심 개념

ASCII의 역할과 한계

// ASCII는 0-127 범위의 문자만 표현
console.log('A'.charCodeAt(0)); // 65 (ASCII)
console.log('안'.charCodeAt(0)); // 50504 (Unicode, ASCII 범위 초과!)

유니코드와 UTF-8

const explainUnicode = (char: string) => {
  const codePoint = char.codePointAt(0)!;
  const utf8Bytes = new TextEncoder().encode(char);
  
  console.log(`문자: ${char}`);
  console.log(`유니코드 코드 포인트: U+${codePoint.toString(16).toUpperCase()}`);
  console.log(`UTF-8 바이트: [${Array.from(utf8Bytes).map(b => `0x${b.toString(16)}`).join(', ')}]`);
};

explainUnicode('A');    // 1바이트
explainUnicode('안');   // 3바이트
explainUnicode(' ');   // 4바이트

성능 최적화 팁

1. 메모이제이션 활용

import { useMemo } from 'react';

const useMemoizedDecoder = (base64String: string) => {
  return useMemo(() => {
    if (!base64String) return '';
    
    try {
      const binaryString = atob(base64String);
      const bytes = new Uint8Array(binaryString.length);
      
      for (let i = 0; i < binaryString.length; i++) {
        bytes[i] = binaryString.charCodeAt(i);
      }
      
      return new TextDecoder('utf-8').decode(bytes);
    } catch {
      return '';
    }
  }, [base64String]);
};

2. 워커 활용 (대용량 데이터)

// worker.ts
self.onmessage = function(e) {
  const { base64Data } = e.data;
  
  try {
    const binaryString = atob(base64Data);
    const bytes = new Uint8Array(binaryString.length);
    
    for (let i = 0; i < binaryString.length; i++) {
      bytes[i] = binaryString.charCodeAt(i);
    }
    
    const result = new TextDecoder('utf-8').decode(bytes);
    self.postMessage({ success: true, result });
  } catch (error) {
    self.postMessage({ success: false, error: error.message });
  }
};

// 메인 스레드에서 사용
const decodeWithWorker = (base64String: string): Promise<string> => {
  return new Promise((resolve, reject) => {
    const worker = new Worker('/decoder-worker.js');
    
    worker.postMessage({ base64Data: base64String });
    
    worker.onmessage = (e) => {
      const { success, result, error } = e.data;
      worker.terminate();
      
      if (success) {
        resolve(result);
      } else {
        reject(new Error(error));
      }
    };
  });
};

디버깅과 테스트

1. 단위 테스트

// base64Decoder.test.ts
import { describe, it, expect } from 'vitest';

describe('Base64 한글 디코더', () => {
  const testCases = [
    { input: '7JWI64WV7ZWY7IS47JqU', expected: '안녕하세요' },
    { input: 'SGVsbG8=', expected: 'Hello' },
    { input: '7ZWc6riAIOuniOS9nOycvA==', expected: '한글 테스트' }
  ];

  testCases.forEach(({ input, expected }) => {
    it(`should decode "${input}" to "${expected}"`, () => {
      const result = decodeBase64Korean(input);
      expect(result).toBe(expected);
    });
  });

  it('should handle invalid input gracefully', () => {
    expect(decodeBase64Korean('')).toBe('');
    expect(decodeBase64Korean('invalid!')).toBe('');
  });
});

2. 브라우저 호환성 확인

const checkBrowserSupport = () => {
  const support = {
    textDecoder: typeof TextDecoder !== 'undefined',
    textEncoder: typeof TextEncoder !== 'undefined',
    atob: typeof atob !== 'undefined',
    fetch: typeof fetch !== 'undefined'
  };

  console.log('브라우저 지원 현황:', support);
  return support;
};

실제 프로덕션 환경에서의 예외 처리

1. 에러 바운더리

import React, { Component, ErrorInfo, ReactNode } from 'react';

interface Props {
  children: ReactNode;
}

interface State {
  hasError: boolean;
  error?: Error;
}

class Base64DecoderErrorBoundary extends Component<Props, State> {
  constructor(props: Props) {
    super(props);
    this.state = { hasError: false };
  }

  static getDerivedStateFromError(error: Error): State {
    return { hasError: true, error };
  }

  componentDidCatch(error: Error, errorInfo: ErrorInfo) {
    console.error('Base64 디코딩 에러:', error, errorInfo);
  }

  render() {
    if (this.state.hasError) {
      return (
        <div className="p-4 bg-red-50 border border-red-200 rounded">
          <h3 className="text-red-800 font-semibold">디코딩 오류</h3>
          <p className="text-red-600">
            Base64 디코딩 중 오류가 발생했습니다. 데이터를 확인해주세요.
          </p>
        </div>
      );
    }

    return this.props.children;
  }
}

2. 로깅과 모니터링

const logDecodingAttempt = (base64String: string, success: boolean, error?: string) => {
  const logData = {
    timestamp: new Date().toISOString(),
    inputLength: base64String.length,
    success,
    error,
    userAgent: navigator.userAgent
  };

  // 프로덕션에서는 실제 로깅 서비스로 전송
  console.log('Base64 디코딩 로그:', logData);
};

마무리: 삽질에서 얻은 교훈

처음에는 단순히 atob()만 사용하면 될 줄 알았던 Base64 한글 디코딩 문제가

인코딩/디코딩의 깊은 원리를 이해하는 계기가 되었습니다.

핵심 포인트

atob()는 Latin-1 기준이므로 한글 처리에 한계가 있음
UTF-8과 Latin-1의 차이를 이해해야 올바른 해결책을 찾을 수 있음
TextDecoder API를 활용하면 모던하고 안전한 처리가 가능
타입스크립트와 React를 활용해 재사용 가능한 컴포넌트 구현

결론

단순해 보이는 문제도 깊이 파보면 복잡한 원리가 숨어있음
브라우저 호환성과 성능을 함께 고려해야 함
에러 처리와 사용자 경험도 빼먹지 말아야 함

ECMAScript 2025(ES2025)의 핵심 변경 사항

ji-frontdev — Mon, 21 Jul 2025 09:00:33 +0900

2025년 6월 25일, 제129회 Ecma 총회에서 ECMAScript 2025 언어 사양이 공식 승인되었습니다.
이번 업데이트는 JavaScript의 실용성과 생산성을 높이는 핵심 기능들이 대거 포함되어 있어, 개발자 경험을 한 단계 끌어올리는 중요한 전환점이 될 것으로 기대됩니다.

주요 기능 요약

Iterator Helpers: 함수형 프로그래밍 패턴을 반복자에 적용 가능

Set Methods: 교집합, 합집합 등 집합 연산의 표준화

JSON Modules: JSON 파일을 import로 직접 불러오기

Promise.try(): 동기/비동기 오류 처리의 간결화

Float16Array: 메모리 효율적인 16비트 부동소수점 지원

정규표현식 개선: 유니코드, 이모지, 캡처 그룹 개선 등

1. Iterator Helpers - 반복자의 함수형 혁신

기존에는 배열로 변환 후 .filter(), .map() 체인을 사용했지만

ES2025부터는 반복자 자체에 지연 평가(lazy evaluation) 기반 연산이 가능해졌습니다.

대용량 데이터 처리에 특히 적합합니다.

2. Set Methods - 집합 연산 표준화

lodash 등의 유틸리티 없이 직접 집합 연산이 가능

데이터 분석, 중복 제거, 교차 데이터 집계 등에 유용

3. JSON Modules - JSON 파일 직접 import

JSON 파일을 fetch나 번들링 없이 모듈처럼 import 가능

정적 설정, 환경 구성 관리가 쉬워짐

Node.js 22+, Chrome 126+, TypeScript 5.5+ 대응 필요

4. Promise.try() - 에러 처리 통합

function processData(data) {
  return Promise.try(() => {
    const result = syncProcess(data);
    return asyncProcess(result);
  });
}

Promise.try(() => {
  if (Math.random() < 0.5) throw new Error("실패!");
  return "성공!";
})
.then(console.log)
.catch(console.error);

기존에는 try/catch + Promise 조합 필요

이제는 동기/비동기 코드를 하나의 흐름으로 처리

5. Float16Array - 고성능 16비트 부동소수점

const f16 = new Float16Array([1.5, 2.7, 3.14]);
console.log(f16.length); // 3

const rounded = Math.f16round(3.14159265359);
console.log(rounded); // 3.140625

Float32Array 대비 메모리 절반 사용

WebGL, 머신러닝, 고성능 수치 연산에서 필수

6. 정규표현식 개선

// 유니코드 스크립트 매칭
const hangulRegex = /\p{Script=Hangul}+/u;
console.log("안녕하세요 Hello".match(hangulRegex)); // ["안녕하세요"]

// 이모지 필터링
const emojiRegex = /\p{Emoji}/u;
console.log(" ".match(emojiRegex)); // [" "]

향상된 유니코드 처리

정규식 inline flag (?i:HELLO) 사용 가능

중복된 named group을 /v 플래그로 처리 가능

브라우저 및 플랫폼 지원

TypeScript 5.5 이상 + lib: ["esnext"] 설정으로 대부분의 기능 사용 가능

⚡ 성능 및 개발자 경험 향상

메모리 최적화: Float16Array, lazy iterator

생산성 향상: 표준화된 Set 연산, JSON 모듈 import

코드 품질 개선: Promise.try(), 정규표현식 유틸리티

라이브러리 의존도 감소: Lodash, Ramda 등의 유틸 함수 대체 가능

마이그레이션 가이드

기존 lodash, 커스텀 헬퍼 함수 등을 ES2025 기능으로 대체할 수 있습니다.

// 기존 lodash
_.intersection(arr1, arr2);

// ES2025
new Set(arr1).intersection(new Set(arr2));

filter().map().toArray()를 반복자 체인으로 전환
설정 관련 JSON 파일은 import로 직접 로딩
에러 핸들링에는 Promise.try() 적용

✅ 결론

ECMAScript 2025는 단순한 문법 개선이 아닌, 실질적으로 개발자들의 업무 효율성과 코드 품질을 높여주는 기능이 대거 포함된 업데이트입니다.

특히 다음과 같은 점에서 강력한 가치가 있습니다:

함수형 프로그래밍 스타일의 도입과 확장
메모리 효율성과 성능 최적화
명확한 표준 API로 라이브러리 의존도 감소
실제 서비스 코드에 즉시 적용 가능

앱 스킴(URL Scheme)”의 개념과 Android/iOS 차이, 앱 선택 처리 방식

ji-frontdev — Wed, 9 Jul 2025 08:33:47 +0900

앱 스킴(URL Scheme)이란?

– Android와 iOS의 앱 연결 방식과 차이를 이해하기

✨ 목차

앱 스킴이란 무엇인가?
앱 스킴과 딥링크는 어떤 관계인가?
Android와 iOS의 앱 스킴 처리 방식
앱 스킴 충돌 시 어떻게 동작할까?
앱 미설치 시 처리 방식
앱 선택 UI 제공 여부
실제 서비스 적용 시 팁
마무리 요약

1. ✅ 앱 스킴이란 무엇인가?

**앱 스킴(URL Scheme)**은 웹 브라우저나 다른 앱에서 특정 앱을 직접 실행하기 위한 일종의 주소 규칙입니다.

예:
kakaotalk://inappbrowser → 카카오톡 실행
mobileid://requestVP → 모바일 신분증 앱 실행

앱이 설치되어 있다면 해당 스킴을 통해 앱을 직접 호출할 수 있고,
파라미터를 함께 전달해 앱 내 특정 기능까지 바로 진입할 수 있습니다.

용어 설명

URL Scheme: 앱이 인식할 수 있는 특별한 URL 포맷. 보통 앱이름://경로 형식
딥링크(Deep Link): 앱의 내부 특정 화면까지 직접 진입할 수 있도록 도와주는 링크 방식

2. ✅ 앱 스킴과 딥링크는 어떤 관계인가?

앱 스킴은 딥링크의 한 종류입니다.
웹 브라우저에서 앱을 여는 가장 기본적인 방식이 앱 스킴입니다.
최신 방식은 Universal Link(iOS) 또는 **App Link(Android)**도 존재하지만,
앱 스킴은 여전히 많이 사용됩니다.

	설명
앱 스킴	예: myapp://home
Universal Link	예: https://example.com/path – 앱 설치 시 앱으로, 아니면 웹으로
App Link (Android)	Universal Link와 유사 – 안전하게 앱 호출

3. ✅ Android와 iOS의 앱 스킴 처리 방식

	Android	iOS
스킴 중복 등록	✅ 가능	❌ 불가능
스킴 호출 시 앱 선택 UI	✅ 시스템이 자동 제공	❌ 없음 (개발자가 직접 구성)
앱 우선순위	사용자 선택 or 기본 앱 설정	먼저 등록된 앱만 가능

예시 상황

mobileid://이라는 스킴을 여러 앱(A, B, C)이 등록한 경우,
- Android: "앱 선택 팝업" 자동 표시
- iOS: 가장 먼저 등록한 앱만 열림

4. ✅ 앱 스킴 충돌 시 어떻게 동작할까?

Android

동일 스킴을 가진 앱이 여러 개 설치된 경우,
시스템이 아래와 같은 **앱 선택 창(Chooser Dialog)**을 자동으로 띄움:

"다음 앱으로 열기"
지갑24
PASS
삼성월렛
[이번 한 번만] [항상]

→ 사용자는 원하는 앱을 선택하고, 항상 이 앱으로 열 수도 있음.

iOS

동일 스킴을 두 개 이상 등록 불가.
한 앱만 해당 스킴을 가질 수 있고, 충돌 시 나머지는 무시됨.
앱 선택 UI가 없음. → 개발자가 직접 리스트 구성 필요

5. ✅ 앱 미설치 시 처리 방식

단순 스킴 (myapp://)

앱이 설치되지 않았을 경우:
- Android: 아무 반응이 없거나, Toast로 “앱 없음” 안내
- iOS: 아무 반응 없음 (에러 표시도 없음)

해결책: intent:// 스킴 사용 (Android 전용)

intent://somepath#Intent;scheme=myapp;package=com.example.myapp;end

앱이 설치되어 있으면 실행
설치 안 돼 있으면 → Google Play Store로 이동

6. ✅ 앱 선택 UI 제공 여부

	Android	iOS
여러 앱이 동일 스킴 등록	앱 선택 화면 자동 제공	❌ 자동 미제공
앱을 고정 선택 가능?	✅ “항상 이 앱으로 열기”	❌ 불가능
앱 리스트 수동 구성 가능?	✅ 가능 (UX 제어 목적)	✅ 필수 (UI 직접 구현해야 함)

7. ✅ 실제 서비스 적용 시 팁

Android에서는 intent:// 스킴을 사용하는 것이 가장 안전함
iOS에서는 앱 리스트 UI를 직접 구성하고, 각 앱의 고유 스킴을 수동으로 실행해야 함
스킴 호출 시 JS fallback 로직 (앱 미설치 시 스토어 이동)을 반드시 구현할 것

복사편집

// iOS 앱 스킴 호출 후 fallback window.location.href = "mobileid://requestVP"; setTimeout(() => { window.location.href = "https://apps.apple.com/app/모바일신분증"; }, 1500);

8. 마무리 요약

	Android	iOS
스킴 중복 허용	✅ 가능	❌ 불가능
앱 선택 화면 제공	✅ 자동	❌ 수동 구성 필요
앱 미설치 대응	intent:// 또는 JS fallback	Universal Link 또는 JS fallback
실무 적용 난이도	낮음	상대적으로 높음 (제약 多)

마무리 코멘트

앱 스킴은 웹과 앱, 앱과 앱 간의 연결을 만드는 매우 중요한 기술입니다.
Android와 iOS는 이를 처리하는 방식이 다르기 때문에,
UX/보안/fallback 처리까지 고려한 구현이 필요합니다.

[Higher-Order Component(HOC)] 등장배경/Custom Hooks 비교 / 예제 코드

ji-frontdev — Sun, 20 Apr 2025 10:00:48 +0900

1. HOC란 무엇인가?

**Higher-Order Component(HOC)**는
“컴포넌트를 인자로 받아서 새로운 컴포넌트를 반환하는 함수”

즉, 하나의 컴포넌트를 감싸 공통된 로직이나 기능을 주입하는 패턴이다.

function withFeature<P>(WrappedComponent: React.ComponentType<P>) {
  return function EnhancedComponent(props: P) {
    // 공통 로직
    return <WrappedComponent {...props} />;
  };
}

2. HOC 패턴의 역사와 등장 배경

️ 언제 등장했나?

**React Hooks가 등장하기 전 (React 16.8 이전)**에 유일한 로직 재사용 방식이었다.
React 공식 문서에서도 권장되던 방식.

왜 등장했나?

공통 기능 (로딩, 인증, 로깅, 테마 등)을 여러 컴포넌트에서 반복 작성하지 않기 위해.
코드 중복 제거 및 추상화를 통해 유지보수성을 높이기 위해.

3. HOC vs 다른 패턴들

패턴	등장 시기	강점	단점
HOC	pre-Hooks	UI 래핑, 공통 로직 삽입	Wrapper Hell, 타입 추론 어려움
Render Props	pre-Hooks	동적인 props 전달	가독성 떨어짐 (중첩 JSX)
Custom Hooks	React 16.8 이후	로직 분리 및 재사용, 명확한 추상화	렌더링 제어는 불가능

4. TypeScript 기반 HOC 예제

로깅 HOC

import React from 'react';

function withLogger<P>(WrappedComponent: React.ComponentType<P>) {
  const ComponentWithLogger = (props: P) => {
    console.log(`[Logger] ${WrappedComponent.name} rendered`);
    return <WrappedComponent {...props} />;
  };

  ComponentWithLogger.displayName = `WithLogger(${WrappedComponent.displayName || WrappedComponent.name})`;
  return ComponentWithLogger;
}

사용

type MyComponentProps = { message: string };

const MyComponent = ({ message }: MyComponentProps) => <div>{message}</div>;

export default withLogger(MyComponent);

5. 같은 기능, Custom Hook으로 바꾸면?

Custom Hook 버전

function useLogger(componentName: string) {
  useEffect(() => {
    console.log(`[Logger] ${componentName} rendered`);
  }, []);
}

사용 예

const MyComponent = () => {
  useLogger('MyComponent');
  return <div>Hello</div>;
};

✅ 비교 요약

항목	HOC	Custom Hook
사용 방식	컴포넌트 감싸기	내부에서 훅 호출
로직 재사용	✅	✅
렌더링 제어	✅ (조건부 렌더링 가능)	❌ (렌더링 자체는 못 막음)
UI 구조 영향	❌ Wrapper 증가	✅ 컴포넌트 구조 그대로 유지
TypeScript 추론	❌ 복잡할 수 있음	✅ 타입 추론 명확

6. Next.js + React Query + Zustand 환경에서의 HOC 예시

예: 인증 여부를 검사하고 리디렉션

// withAuth.tsx
import { useRouter } from 'next/router';
import { useUserStore } from '@/stores/userStore';

export function withAuth<P>(Component: React.ComponentType<P>) {
  const Wrapper = (props: P) => {
    const router = useRouter();
    const isAuthenticated = useUserStore((state) => state.isLoggedIn);

    useEffect(() => {
      if (!isAuthenticated) router.push('/login');
    }, [isAuthenticated]);

    if (!isAuthenticated) return null;
    return <Component {...props} />;
  };

  return Wrapper;
}

// pages/profile.tsx
const ProfilePage = () => <div>프로필입니다</div>;
export default withAuth(ProfilePage);

7. 실무에서 HOC를 선택하는 상황

여러 페이지에 동일한 UI 제어 또는 조건 분기 로직이 필요할 때
SSR, 라우팅 전 체크, 로딩/에러 핸들링 등 렌더링 제어가 필요할 때
특정 스타일/레이아웃/테마 래핑이 필요할 때

8. 정리: 지금 시점에서 HOC를 쓴다는 건?

✅ 사용할 때	❌ 피해야 할 때
공통 렌더링 제어가 필요할 때	단순 로직 재사용만 필요한 경우 (useXXX로 충분)
UI 컨텍스트나 테마 적용 시	너무 많은 HOC 중첩이 발생할 경우
페이지 단위 조건 분기	로직 복잡도 높은 컴포넌트에 적용 시

✍️ 마무리하며

HOC는 오래된 개념이지만 여전히 유효한 재사용 패턴이다.

다만, React의 변화와 함께 사용 목적이 명확한 상황에서만 선택적으로 활용해야 한다.

다음 글에서는 Render Props 또는 Compound Components 패턴도 함께 정리해볼 예정

프론트엔드 개발자가 구독하거나 즐겨찾기 해두면 좋은 뉴스레터, 사이트

ji-frontdev — Sat, 19 Apr 2025 10:00:04 +0900

프론트엔드 개발자로서 트렌드, 기술, 도구 변화가 빠르기 때문에 꾸준히 정보 얻는 게 중요해요.
아래는 프론트엔드 개발자가 구독하거나 즐겨찾기 해두면 좋은 뉴스레터, 사이트 등을 정리해봤어요.

뉴스레터 (이메일로 받아보기 좋은 소스)

Frontend Focus
- https://frontendfoc.us
- 매주 발행되는 프론트엔드 뉴스 요약 (HTML, CSS, JS 중심)
JavaScript Weekly
- https://javascriptweekly.com
- JS 중심으로 유용한 라이브러리, 아티클, 도구 등을 매주 소개
React Status
- https://react.statuscode.com
- React 생태계 관련 소식 요약 (라이브러리, 아티클, 릴리즈 등)
CSS Weekly
- https://css-weekly.com
- 최신 CSS 기법과 인사이트를 간단히 받아볼 수 있어요.
Bytes.dev
- https://bytes.dev
- 유머 섞인 톤으로 JS/웹 개발 뉴스 전해주는 인기 뉴스레터

사이트 & 블로그

Smashing Magazine
- https://www.smashingmagazine.com
- 디자인, UX, HTML/CSS, JS 등 다양한 프론트엔드 주제 다룸
CSS-Tricks (지금은 DigitalOcean 블로그로 통합)
- https://www.digitalocean.com/blog
- CSS, JS 실용적인 팁, 문제 해결 중심 아티클 많음
Dev.to
- https://dev.to
- 개발자 커뮤니티 기반, 다양한 주제로 아티클이 올라옴
Medium – Better Programming / JavaScript in Plain English
- https://medium.com/better-programming
- 초중급 개발자에 좋은 튜토리얼과 모던 JS/React/Next.js 등 실습 글 다수
MDN Web Docs
- https://developer.mozilla.org
- 기본기와 참조용으로는 최고의 웹 표준 문서

추가 추천

GitHub Trending (JavaScript / TypeScript)
- https://github.com/trending/javascript
- 요즘 뜨는 오픈소스 트렌드 살펴보기
HN (Hacker News)
- https://news.ycombinator.com
- 실리콘밸리 개발자들이 보는 뉴스, 흥미로운 토론 많음

Next.js App Router에서 CSR 탭에서 SSR 페이지 전환으로 전환하기까지

ji-frontdev — Fri, 18 Apr 2025 10:00:32 +0900

Next.js의 App Router 기반 프로젝트에서 탭 UI를 구성하고, 각 탭에 컴포넌트를 연결하는 작업까지는 무리 없이 진행되었다.
버튼을 클릭하면 탭이 바뀌고, 화면도 전환되는 인터랙션은 제대로 작동했다.

하지만 치명적인 문제가 있었다.

화면은 떴지만, 정작 중요한 데이터는 비어 있었다

탭을 눌러도 아무런 정보가 표시되지 않았다.
버튼은 잘 보였고, 레이아웃도 정상이라 “정상 동작”처럼 보였지만, 실제로는 데이터가 끝내 표시되지 않았다.

원인은 클라이언트 사이드에서 데이터를 요청하는 구조 때문이었다.
useQuery를 사용해 데이터를 가져오도록 했지만, 이 방식은 브라우저가 로드된 뒤 실행된다.
그래서 브라우저에서 API 요청이 이루어지고, 거기서 데이터를 받아야만 실제 콘텐츠가 보여지는 구조였던 것이다.

그런데 탭이 기본적으로 서버 사이드에서 렌더링되는 구조가 아니고, use client로 클라이언트 컴포넌트로만 구성되어 있다 보니, 데이터는 서버에서 전혀 전달되지 않았고, 브라우저에서도 API 요청조차 보내지 못한 상태였다.
(게다가 에러도 안 났다...)

SEO도 완전히 무의미했다

이 구조에서는 HTML의 초기 렌더링 결과에 실제 콘텐츠 데이터가 아무것도 포함되어 있지 않았다.
검색 엔진, OG 태그, SNS 미리보기 등에서도 빈 껍데기만 확인할 수 있었고, 이는 SEO 측면에서 심각한 결함이었다.

✅ 구조 개선: SSR 페이지 전환 방식으로 리팩토링

결국 탭 UI를 단순한 라우팅 전환 트리거로 변경하고,
각 탭은 /guide/a, /guide/b처럼 SSR 페이지로 구성해 데이터를 미리 불러와 렌더링하도록 구조를 바꿨다.

탭 클릭 → 페이지 이동 (router.push)
각 페이지에서 서버에서 데이터를 미리 불러오기 (async 서버 컴포넌트 + fetch)
초기 HTML에 데이터 포함 → SEO 반영 가능 + 즉시 콘텐츠 표시

정리: 인터랙션이 된다고 “잘 된 UI”는 아니다

이번 시행착오를 통해 다음과 같은 교훈을 얻었다:

겉으로 보이는 UI와 실제 데이터 상태는 다르다.
클라이언트 컴포넌트만 사용하면, 서버는 아무것도 렌더링하지 않는다.
Next.js App Router에서는 getServerSideProps를 사용할 수 없다.
서버에서 데이터를 가져오는 구조로 렌더링하려면 SSR 컴포넌트를 사용해야 한다.
SEO 성능 확보는 구조적인 설계에서 시작된다.

[Vite defineConfig 설정 기본편] root, base, plugins, resolve, build, 상황별 예시

ji-frontdev — Wed, 16 Apr 2025 10:46:16 +0900

1. defineConfig()와 설정 구조 개요

Vite는 ESM 기반의 번들러로, vite.config.ts 또는 .js 파일을 통해 설정을 제공합니다.

이 설정 파일에서 defineConfig()는 타입 지원과 자동 완성을 위한 래퍼입니다.

// 기본 구조
import { defineConfig } from 'vite';

export default defineConfig({
  root: '.',           // 프로젝트 루트 (index.html 기준)
  plugins: [],         // 플러그인 배열
  resolve: {},         // 경로 해석 관련 설정
  build: {},           // 빌드 설정 (rollup 옵션 포함)
});

2. 주요 설정 속성 복기 및 해설

✅ root

기본값: process.cwd()
설명: 프로젝트의 루트 디렉토리 설정. 이 디렉토리 기준으로 index.html, src 등이 해석됨.
예시:

root: './demo', // ./demo/index.html이 엔트리로 사용됨

✅ base

기본값: '/'
설명: 빌드시 생성되는 자산의 URL prefix. CDN 경로 지정 등 외부 환경 대응에 사용.
예시:

base: './', // 상대 경로로 자산 import (file:// 테스트용)
base: '/static/', // Nginx 서브경로 대응

✅ plugins

설명: Vite의 플러그인 생태계 또는 Rollup 플러그인 포함 가능
주요 예시:

plugins: [
  react(),                   // @vitejs/plugin-react-swc
  tsconfigPaths(),           // tsconfig.json 기반 경로 alias
  removeCrossoriginPlugin()  // 커스텀 HTML 수정 플러그인
]

✅ resolve

설명: 모듈 import 경로를 해석하는 방식 지정 (alias 등)
예시:

resolve: {
  alias: {
    '@editor': path.resolve(__dirname, 'src/editor'),
  }
}

✅ build

설명: Vite → Rollup 기반 빌드 설정
주요 속성:

build: {
  outDir: 'dist',                 // 출력 디렉토리
  assetsDir: 'assets',           // 정적 자산 폴더
  sourcemap: true,               // sourcemap 생성 여부
  target: 'es2020',              // 트랜스파일 타겟
  minify: 'esbuild',             // 'terser' or 'esbuild'
  rollupOptions: {
    input: './index.html',       // HTML 엔트리 명시 (멀티페이지 대응 시 유용)
    output: {
      entryFileNames: `assets/[name]-[hash].js`,
      chunkFileNames: `assets/[name]-[hash].js`,
      assetFileNames: `assets/[name]-[hash].[ext]`,
    },
  },
  emptyOutDir: true,             // 기존 dist 제거 여부
}

3. 설정 상황 예시

A. 파일 시스템 기반 로딩 테스트 (file:// 환경 대응)

export default defineConfig({
  base: './', // 상대 경로로 경로 지정
  plugins: [
    {
      name: 'remove-crossorigin',
      transformIndexHtml(html) {
        return html.replace(/<script type="module" crossorigin/g, '<script type="module"');
      }
    }
  ]
});

B. 외부 CDN 자산 사용

export default defineConfig({
  base: 'https://cdn.mycdn.com/myapp/',
});

C. 라이브러리 번들링 용도 (build.lib)

export default defineConfig({
  build: {
    lib: {
      entry: path.resolve(__dirname, 'src/index.ts'),
      name: 'MyLib',
      fileName: format => `my-lib.${format}.js`
    },
    rollupOptions: {
      external: ['react'],
      output: {
        globals: {
          react: 'React'
        }
      }
    }
  }
});

마무리 팁

vite build는 Rollup을 래핑한 고수준 추상화임.
파일 경로, publicPath(base), asset 위치 정책이 명확하지 않으면 정적 배포에서 이슈가 빈번하게 발생함.
로컬에서 file://로 열 경우엔 crossorigin, base, 상대경로의 정합성이 매우 중요함.
다중 HTML 엔트리를 사용하는 경우 rollupOptions.input을 꼭 명시할 것.

tsconfig.json 설정 오류 해결: allowImportingTsExtensions는 왜 에러가 날까?

ji-frontdev — Tue, 15 Apr 2025 21:19:49 +0900

에러 원인:

allowImportingTsExtensions 옵션은 TypeScript가 .ts 또는 .tsx 확장자를 명시적으로 import하는 것을 허용하는 기능입니다.

import { something } from './utils.ts';

이런 식의 import를 허용하려면 TypeScript가 실제로 JavaScript 파일을 emit하지 않는 설정이어야 합니다. 그렇지 않으면 문제가 발생할 수 있기 때문이에요.

그래서 이 옵션을 사용하려면 아래 중 하나를 설정해야 합니다:

"noEmit": true
TypeScript가 아무 파일도 출력하지 않음
"emitDeclarationOnly": true
타입 정의 파일(.d.ts)만 출력함

✅ 해결 방법:

방법 1. noEmit 설정 추가하기 (가장 일반적)

{
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "noEmit": true
  }
}

방법 2. emitDeclarationOnly 설정 추가

{
  "compilerOptions": {
    "allowImportingTsExtensions": true,
    "emitDeclarationOnly": true
  }
}

❓ 왜 이렇게 제한할까?

.ts 확장자를 포함한 import는 Node.js ESM 환경에서 주로 사용되며, TypeScript가 이를 처리할 때 .js로 변환하는 과정에서 충돌이 발생할 수 있기 때문입니다. 그래서 출력을 하지 않도록 제한한 것입니다.