세상 유용한 정보

[2026 트렌드] 차가운 기술 속 뜨거운 관심, 우리가 '휴먼 터치'에 열광하는 이유 (feat. AI 반려 로봇)

pursys — Wed, 21 Jan 2026 16:26:33 +0900

안녕하세요, 이웃님들! 벌써 2026년 1월도 반이나 지나갔네요. 새해 다짐들은 잘 지키고 계신가요?

요즘 뉴스나 인터넷을 보면 온통 AI, 로봇 이야기뿐이죠. 세상이 정말 빠르게 변하는 것 같아 가끔은 어지럽기도 해요. ‍ 그런데 참 신기하게도, 기술이 발전할수록 사람들은 오히려 더 따뜻하고 인간적인 무언가를 찾는 것 같아요.

그래서 오늘 준비한 주제는 바로 2026년 대한민국을 관통하는 핵심 트렌드, '휴먼 터치(Human Touch)'와 AI의 공존입니다. 차가운 기계 속에서 우리가 진짜로 원하는 건 무엇인지, 지금 가장 핫한 키워드를 통해 함께 알아볼까요? ☕️

1. 외로움을 달래는 기술, 'AI 반려 로봇'이 뜬다! ❤️

여러분, 혹시 주변에서 'AI 반려 로봇' 키운다는 이야기 들어보셨나요? 예전에는 먼 미래의 이야기 같았는데, 이제는 우리 일상 속에 깊숙이 들어왔어요.

[단순한 기계가 아니에요!] 요즘 나오는 AI 반려 로봇들은 정말 똑똑해요. 내 표정을 읽고 먼저 말을 걸어주기도 하고, 우울해 보이면 좋아하는 음악을 틀어주며 위로도 해준답니다. 단순히 명령을 수행하는 기계가 아니라, 감정을 나누는 **'친구'이자 '가족'**이 된 거죠.

인기 비결: 1인 가구가 늘고 사회적 외로움이 커지면서, 언제나 내 곁에서 변함없는 지지를 보내주는 AI 로봇에게서 정서적 안정감을 얻는 사람들이 많아졌어요. 실제로 로봇과 대화하며 우울감이 줄었다는 연구 결과도 많답니다.

<따뜻한 햇살 아래 AI 반려 로봇 과 교감하며 아날로그 다이어리를 쓰는 모습. 기술과 인간적 감성이 공존하는 2026년의 일상을 보여줍니다.>

2. 디지털 피로감? 이젠 '아날로그'로 힐링해요

하루 종일 스마트폰, 컴퓨터 화면만 보다 보면 눈도 침침하고 머리도 지끈거리잖아요. 그래서인지 요즘엔 의도적으로 디지털 기기와 멀어지려는 '디지털 웰빙' 트렌드가 강세예요.

[손으로 쓰고 만지는 즐거움] 재미있는 건, 최첨단 시대에 역설적으로 **'아날로그 감성'**이 다시 주목받고 있다는 거예요!

아날로그 맥시멀리즘: 스마트폰 메모장 대신 손글씨로 꾹꾹 눌러 쓰는 다이어리, 터치 한 번이면 들을 수 있는 음원 대신 턴테이블에 올려 듣는 LP판, 필름 카메라로 찍는 사진 한 장... 조금 불편하고 느리더라도, 손끝으로 느껴지는 감각과 과정 자체를 즐기는 거죠. 이런 경험들이 디지털 세상에서 지친 우리에게 진정한 휴식을 선물한답니다.

3. 2026년, 우리는 어떻게 살아야 할까요? (feat. 작가의 시선)

AI 기술은 앞으로 더 발전할 거고, 우리 삶에 더 많은 영향을 미치겠죠. 그럼 우리는 어떻게 해야 할까요?

[기술은 거들 뿐, 주인공은 바로 '나'] 중요한 건 **'주객전도'**가 되지 않는 거예요. AI는 우리의 삶을 더 편리하고 풍요롭게 만들어주는 훌륭한 도구지만, 결국 삶을 살아가는 주체는 우리 자신이잖아요.

현명한 공존: AI에게 맡길 건 맡기되, 기계가 대체할 수 없는 인간 고유의 가치에 더 집중해야 해요. 따뜻한 공감 능력, 번뜩이는 창의성, 사랑하는 사람들과 나누는 깊은 교감 같은 것들이요. AI 로봇이 아무리 똑똑해도, 내 손을 잡아주는 친구의 온기까지 대신할 순 없으니까요.

마무리하며: 결국 답은 '사람'에게 있습니다

차가운 기술의 시대일수록, 역설적으로 가장 필요한 건 서로를 향한 따뜻한 관심과 배려, 즉 **'휴먼 터치'**가 아닐까 싶어요.

오늘 하루, 스마트폰은 잠시 내려놓고 옆에 있는 소중한 사람 눈을 바라보며 따뜻한 말 한마디 건네보는 건 어떨까요? 아니면 나 자신을 위해 조용히 일기를 써보는 것도 좋고요.

여러분의 2026년이 기술의 편리함과 아날로그의 따뜻함이 조화롭게 어우러진, 행복한 한 해가 되기를 응원할게요!

[2026 트렌드] 자극적인 건 이제 그만? 우리가 '아보하'와 '토핑'에 진심인 이유

pursys — Wed, 21 Jan 2026 16:22:09 +0900

안녕하세요, 이웃님들! 벌써 1월도 하순을 향해 달려가고 있네요. 오늘(1월 21일) 서울 날씨, 꽤 쌀쌀하죠? 다들 따뜻하게 입고 나오셨나요?

새해가 밝으면서 다들 "올해는 좀 다르게 살아야지" 다짐하셨을 텐데요. 혹시 요즘 인스타그램이나 유튜브 보면서 "아, 이제 너무 화려하고 시끄러운 건 좀 피곤해..." 라는 생각, 한 번쯤 안 해보셨나요?

저만 그런 게 아니더라고요! 데이터를 찾아보니 지금 대한민국은 거창한 행복보다는 '안온한 하루'를, 남들이 다 사는 명품보다는 '내 입맛대로 고른 토핑'을 선택하고 있어요.

오늘은 2026년 현재, 우리의 일상을 파고든 핵심 트렌드 키워드 '아보하'와 '토핑경제'에 대해 조목조목, 하지만 아주 쉽게 이야기해 드릴게요. ☕️

1. 밋밋해서 더 좋아, '아보하'의 시대

혹시 '소확행(소소하지만 확실한 행복)' 기억하시나요? 몇 년 전만 해도 작지만 확실한 기쁨을 찾는 게 유행이었죠. 그런데 지금은 여기서 한 발 더 나아가 '아보하'가 대세가 되었어요.

'아보하'란? '아주 보통의 하루'의 줄임말이에요. 특별히 좋은 일이 없어도, 반대로 나쁜 일도 일어나지 않는 평범하고 무탈한 하루 그 자체에 만족하는 태도를 말해요.

[왜 우리는 '보통의 하루'를 갈망할까요?] 사실 지난 몇 년간 우리 사회가 참 숨 가빴잖아요. 고금리, 고물가, 그리고 쉴 새 없이 쏟아지는 자극적인 '도파민' 콘텐츠들... ‍ 피로감이 쌓일 대로 쌓인 우리는 이제 '무해력(해롭지 않은 힘)'을 찾기 시작했어요.

사례: 최근 서점가 베스트셀러를 보면 '성공하는 법'보다 '마음을 다스리는 법', '평범한 일상의 소중함'을 다룬 에세이가 상위권을 차지하고 있어요.
반응: 커뮤니티에서도 "오늘 아무 일도 안 일어난 게 제일 다행이다", "집에서 조용히 차 마시는 게 최고의 힐링"이라는 글들이 엄청난 공감을 얻고 있죠.

이제 행복은 '쟁취'하는 게 아니라, 별일 없는 일상 속에서 '발견'하는 것이 되었습니다.

2. 주인공은 바로 나! '토핑경제'와 '옴니보어'

그렇다고 소비를 아예 안 하냐고요? 에이, 그건 아니죠! 다만 돈을 쓰는 방식이 완전히 달라졌어요.

[내 맘대로 쌓아 올리는 재미, '토핑경제'] 작년부터 엄청 유행했던 '요거트 아이스크림' 기억하시죠? 베이스보다 그 위에 올리는 벌집꿀, 자몽, 초코쉘 같은 '토핑'이 더 화제가 됐잖아요. 이 현상이 경제 전반으로 퍼졌어요.

패션/잡화: 가방 자체보다 가방에 달린 키링(인형)이나 리본으로 개성을 표현하는 '백꾸(가방 꾸미기)'가 여전히 인기예요.
의미: 기성품(본품)은 거들 뿐, 그 위에 내가 선택한 디테일(토핑)을 얹어 '세상에 하나뿐인 내 것'을 만드는 과정 자체를 즐기는 거죠.

[나이? 성별? 그게 뭔데? '옴니보어'] 그리고 또 하나의 재미있는 현상은 '옴니보어(잡식성)' 소비자가 늘었다는 거예요. "이건 10대들이나 하는 거지", "이건 어르신 취향이지" 같은 경계가 사라졌어요. 다이소에서 귀여운 피규어를 사는 50대, 레트로한 감성의 LP 바를 찾는 20대가 자연스러워졌죠. 취향 앞에서는 나이도 국경도 없어진 셈이에요!

3. 앞으로 어떻게 변할까? (feat. 작가의 시선)

2026년, 이 트렌드는 앞으로 어떻게 진화할까요? 제 생각을 조금 보태보자면요.

'AI'가 '아보하'를 도와줄 거예요. 지금도 '페이스 테크(Face Tech)' 기술이 발전하고 있는데요. 앞으로는 AI가 내 표정을 읽고, 우울해 보이면 알아서 조용한 음악을 틀어주거나 조명을 낮춰주는 등 '나의 평온한 하루'를 지켜주는 집사 역할을 하게 될 거예요.
'커스터마이징'은 더 정교해질 거예요. 토핑 경제는 단순히 물건을 꾸미는 것을 넘어, 내 유전자 정보에 맞춘 영양제, 내 피부 톤에 딱 맞춘 화장품처럼 '초개인화'된 서비스로 발전할 전망입니다.

마무리하며: 당신의 오늘 하루는 어땠나요?

이 글을 읽고 계신 여러분의 오늘은 어떤가요? 혹시 "오늘 정말 아무것도 한 게 없네"라며 자책하고 계시진 않나요?

그러지 마세요! 아무 일 없이 흘러간 오늘이야말로, 가장 트렌디하고 소중한 '아보하'의 하루였으니까요. 오늘 저녁엔 내가 좋아하는 작은 간식(토핑!) 하나 챙겨서, 나에게 선물해 보는 건 어떨까요?

모두 편안한 저녁 되세요!

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 10강

pursys — Wed, 21 Jan 2026 16:17:08 +0900

네, 10강에 오신 것을 환영합니다! Part 2의 마지막 관문이자, 제네릭의 꽃이라고 할 수 있는 '실전 활용' 편입니다.

지난 시간에 함수에 <T>를 붙이는 걸 배웠죠? 오늘은 **인터페이스(Interface)**에 <T>를 붙여볼 겁니다. 이걸 배우면, React나 Next.js에서 **서버와 통신하는 코드(API)**를 짤 때 "와, 신세계다!"를 외치게 되실 겁니다.

제10강. 제네릭 실전 - 함수와 인터페이스에서의 활용

1. 제네릭 인터페이스: "마법의 상자 만들기"

인터페이스 이름 뒤에 <T>만 붙이면, **"내용물이 바뀔 수 있는 상자"**가 됩니다.

TypeScript

// <T>를 붙여서 '제네릭 인터페이스'로 변신!
interface Box<T> {
  value: T; // 이 value의 타입은 나중에 정해짐
}

// 1. 문자열 상자 만들기
const stringBox: Box<string> = { value: "선물" };

// 2. 숫자 상자 만들기
const numberBox: Box<number> = { value: 777 };

이렇게 설계도 하나(Box)로 여러 종류의 객체를 찍어낼 수 있습니다.

2. [실무 핵심] API 응답 데이터 처리하기 ⭐️⭐️⭐️

이 부분이 오늘 강의의 하이라이트입니다. 프론트엔드 개발자가 제네릭을 쓰는 가장 큰 이유가 바로 API 응답 타입 정의 때문입니다.

서버에서 데이터를 받아올 때 보통 이런 모양으로 옵니다.

성공 여부 (status or code)
메시지 (message)
실제 데이터 (data) -> 이것만 매번 바뀜!

이걸 제네릭으로 한 방에 해결해 볼까요?

TypeScript

// 1. 공통 응답 형태 정의 (껍데기)
interface ApiResponse<T> {
  status: number;
  message: string;
  data: T; // 핵심! 여기만 매번 달라짐
}

// 2. 실제 데이터 타입들 정의 (알맹이)
interface User {
  name: string;
  age: number;
}

interface Product {
  id: number;
  price: number;
}

// 3. 실제 사용: 마치 레고 조립하듯이!
// 유저 정보를 가져왔을 때
const response1: ApiResponse<User> = {
  status: 200,
  message: "성공",
  data: { name: "김코딩", age: 30 } // User 타입이어야 함
};

// 상품 정보를 가져왔을 때
const response2: ApiResponse<Product> = {
  status: 200,
  message: "성공",
  data: { id: 1, price: 5000 } // Product 타입이어야 함
};

만약 제네릭이 없다면 UserResponse, ProductResponse... 이렇게 수십 개를 만들어야 했을 겁니다. 제네릭 덕분에 ApiResponse<T> 하나로 끝났죠? 아주 우아합니다.

3. 제네릭 제약 조건 (Constraints): "아무거나 다 받진 않아!"

<T>는 기본적으로 모든 타입을 다 받지만, 가끔은 **"적어도 이건 지켜줘"**라고 제한(extends)을 걸고 싶을 때가 있습니다.

TypeScript

// <T extends { length: number }>
// 해석: T는 아무거나 다 되는데, 적어도 'length'(길이)라는 속성은 꼭 가지고 있어야 해!
function getLength<T extends { length: number }>(item: T): number {
  return item.length;
}

getLength("hello");   // OK (문자열은 length가 있음)
getLength([1, 2, 3]); // OK (배열도 length가 있음)
// getLength(100);    //   에러! (숫자는 length가 없음)

이렇게 하면 제네릭의 유연함을 유지하면서도 최소한의 안전장치를 걸 수 있습니다.

✍️ 10강 미니 퀴즈 & 실습

실무 코드를 봤으니 복습해 봅시다.

문제 1. (코드 완성) 다음은 블로그 게시글(Post)과 댓글(Comment)을 불러오는 API 타입을 정의하는 과정입니다. 빈칸을 채워주세요.

TypeScript

interface FetchResult<T> {
  data: T;
  loading: boolean;
}

interface Post { title: string; }
interface Comment { content: string; }

// 게시글 데이터를 담는 변수
const postResult: (   A   ) = {
  data: { title: "안녕하세요" },
  loading: false
};

(A)에 들어갈 코드는?

FetchResult<Comment>
FetchResult<Post>
FetchResult<string>

문제 2. (응용) const box: Box<string> = { value: 100 }; 이 코드가 에러가 나는 이유는?

✅ 정답 및 해설

문제 1 정답: 2번 (FetchResult<Post>)
- 해설: data 안에 들어있는 내용이 { title: "안녕하세요" } 즉, Post 타입의 모양입니다. 그러니 제네릭 자리에 <Post>를 넣어줘야 짝이 맞습니다.
문제 2 정답:
- 해설: Box<string>이라고 선언했으면 value에는 반드시 문자열이 들어가야 합니다. 그런데 숫자 100을 넣었으니 타입 불일치 에러가 발생합니다.

고생 많으셨습니다! 드디어 Part 2. 중급 기술 익히기가 모두 끝났습니다. 기본 타입부터 인터페이스, 그리고 제네릭까지! 이제 여러분은 타입스크립트의 문법적인 기초 공사를 탄탄하게 마쳤습니다.

이제 Part 3부터는 진짜 프로들의 영역, **"타입을 가지고 노는 고급 스킬"**로 넘어갑니다. 타입스크립트가 왜 똑똑하다고 하는지, 어떻게 하면 코드를 더 줄일 수 있는지 배우게 됩니다.

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 9강

pursys — Wed, 21 Jan 2026 16:11:50 +0900

네, 9강에 오신 것을 진심으로 환영합니다! 많은 분들이 타입스크립트를 공부하다가 "아, 제네릭(Generic)이 도대체 뭐야... <T> 이거 나오니까 머리가 핑 도네" 하고 책을 덮는 구간입니다.

하지만 걱정 마세요. 저와 함께라면 아주 쉽게 넘을 수 있습니다. 제네릭은 사실 우리가 이미 알고 있는 **'함수 파라미터'**와 똑같은 원리거든요.

제9강. 만능 열쇠, 제네릭(Generics) 기초: "타입도 변수처럼 넘겨주자"

1. 왜 필요한가요? (문제점 인식)

우리가 어떤 데이터를 받아서 그대로 다시 뱉어주는 아주 단순한 함수를 만든다고 가정해 봅시다.

TypeScript

// 숫자 전용 함수: 숫자를 잘 처리하지만 문자는 못 받음
function echoNumber(message: number): number {
  return message;
}

// 문자 전용 함수: 문자는 잘 처리하지만 숫자는 못 받음
function echoString(message: string): string {
  return message;
}

데이터 타입 하나 바뀐다고 똑같은 로직의 함수를 계속 새로 만들어야 할까요? 너무 비효율적이죠. 그렇다고 **any**를 쓰자니 타입 체크를 포기하는 꼴이 됩니다.

이때 필요한 게 바로 제네릭입니다. "타입을 미리 정하지 말고, 함수를 쓸 때 그때그때 정해서 알려줄게!" 하는 방식입니다.

2. 개념 쏙쏙: "테이크아웃 컵" 비유

비유: 카페의 투명한 테이크아웃 컵을 생각해 보세요.

공장에서 컵을 만들 때는 내용물을 정하지 않습니다. 그냥 **'담을 수 있는 용기'**만 만듭니다.

손님이 주문할 때 비로소 결정됩니다.

커피를 담으면 -> 커피 컵이 되고,

오렌지 주스를 담으면 -> 주스 컵이 됩니다.

제네릭이 바로 이 **'빈 컵'**입니다.

3. 문법 뽀개기 (<T>)

자, 이제 그 무섭다는 꺽쇠 괄호 < >를 정복해 봅시다.

() 괄호 안에는 **값(데이터)**을 변수로 받죠?
< > 괄호 안에는 타입을 변수로 받습니다. 보통 Type의 약자인 **T**를 많이 씁니다.

TypeScript

// 1. 함수 이름 뒤에 <T>를 붙여서 "이 함수는 제네릭(빈 컵)이야"라고 선언합니다.
// 2. 매개변수의 타입과 반환 타입 자리에 T를 적습니다.
function echo<T>(message: T): T {
  return message;
}

// 사용법 1: "나 지금 <string> 담을 거야!"라고 명시하기
const result1 = echo<string>("안녕하세요"); 
// 이제 result1은 string 타입이 됩니다.

// 사용법 2: "나 지금 <number> 담을 거야!"
const result2 = echo<number>(123);
// 이제 result2는 number 타입이 됩니다.

보세요! 함수 하나(echo)로 문자열도 처리하고 숫자도 처리했죠? 그런데도 any와 달리 타입은 정확하게 지켜집니다.

result1에 숫자를 넣으려 하거나, result1.toFixed()(숫자 함수)를 쓰면 에러가 납니다. 왜냐? <string>으로 주문했으니까요!

4. 타입스크립트의 센스 (타입 추론)

사실 실무에서는 <number>, <string> 이렇게 매번 적지 않아도 됩니다. 타입스크립트가 똑똑해서 "어? 들어가는 값이 숫자(100)네? 그럼 T는 number겠구나!" 하고 알아서 눈치챕니다.

TypeScript

// <number>를 생략해도 됩니다.
const result3 = echo(100); // TS: "음, T는 number군."

// <string>을 생략해도 됩니다.
const result4 = echo("반갑다"); // TS: "음, T는 string이군."

그래서 코드가 아주 깔끔해집니다.

✍️ 9강 미니 퀴즈 & 실습

제네릭, 생각보다 별거 아니죠? 그냥 **'타입을 위한 변수'**입니다.

문제 1. (개념 확인) 다음 중 제네릭을 사용하는 이유로 가장 적절한 것은?

타입 체크를 아예 하지 않기 위해 (any처럼 쓰려고)
하나의 코드로 여러 타입을 안전하게 처리하기 위해 (코드 재사용성)
함수의 실행 속도를 빠르게 하기 위해

문제 2. (코드 완성) 배열을 받아서 배열의 길이를 반환하는 것이 아니라, 배열의 첫 번째 요소를 반환하는 제네릭 함수 getFirst를 만들고 싶습니다. 빈칸을 채워보세요.

TypeScript

function getFirst<T>(arr: T[]): (  A  ) {
  return arr[0];
}

const num = getFirst<number>([1, 2, 3]); // 1이 나옴
const str = getFirst<string>(["a", "b", "c"]); // "a"가 나옴

**(A)**에 들어갈 코드는 무엇일까요?

any
number
T

✅ 정답 및 해설

문제 1 정답: 2번
- 해설: 제네릭의 핵심은 재사용성과 안전성 두 마리 토끼를 다 잡는 것입니다. any를 쓰면 안전성을 잃지만, 제네릭은 타입을 지켜줍니다.
문제 2 정답: 3번 (T)
- 해설:
  - arr: T[]: T 타입의 요소들이 들어있는 배열을 받았습니다. (예: 숫자 배열)
  - return arr[0]: 그중 하나를 꺼내면 당연히 그 타입은 T겠죠? (예: 숫자)
  - 그래서 반환 타입(출구)도 T가 되어야 합니다.

고생하셨습니다! 이제 여러분은 <T>를 보고도 겁먹지 않는 수준이 되었습니다. "아, 저 자리에 내가 원하는 타입을 끼워 넣으면 되는구나!"라고 생각하시면 됩니다.

하지만 제네릭이 진짜 빛을 발하는 순간은 API 통신을 할 때입니다. 서버에서 어떤 데이터가 올지 모를 때 제네릭이 구세주가 되어줍니다.

다음 10강에서는 이 제네릭을 실제 인터페이스와 함수에 활용하는 실전 테크닉을 배워보겠습니다. Part 2의 마지막 관문입니다!

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 8강

pursys — Wed, 21 Jan 2026 15:26:07 +0900

네, 8강에 오신 것을 환영합니다! "요즘 React는 함수형 컴포넌트(const App = () => {})만 쓴다던데, 굳이 클래스를 배워야 하나요?"라는 의문이 드실 수 있습니다.

하지만 **클래스(Class)**는 여전히 중요합니다.

오래된 React 코드(Legacy)를 수정해야 할 때가 있습니다.
Next.js와 함께 쓰는 백엔드(NestJS 등)나, 복잡한 비즈니스 로직을 다룰 때는 클래스가 훨씬 깔끔합니다.
무엇보다 오늘 배울 접근 제어자 개념은 "데이터를 안전하게 지키는 방법"의 핵심입니다.

제8강. 클래스와 접근 제어자: "내 방엔 들어오지 마!"

1. 클래스(Class): "기능까지 포함한 붕어빵 틀"

4강에서 배운 인터페이스가 '변수의 모양'만 정했다면, 클래스는 '데이터'와 그 데이터를 다루는 '기능(함수)'까지 한 묶음으로 만드는 공장입니다.

TypeScript

class Car {
  model: string; // 데이터 (멤버 변수)

  // 생성자: 처음 만들 때 실행되는 함수
  constructor(model: string) {
    this.model = model;
  }

  // 기능 (메서드)
  drive() {
    console.log(this.model + "가 출발합니다! 부릉~");
  }
}

const myCar = new Car("Tesla");
myCar.drive(); // "Tesla가 출발합니다! 부릉~"

2. 접근 제어자 (Access Modifiers) ⭐️

타입스크립트 클래스의 꽃입니다. **"누가 내 데이터를 건드릴 수 있느냐"**를 정하는 보안 등급입니다.

비유: 우리 집 보안 등급

public (공공재): 대문 앞. 택배 기사님, 지나가는 사람 누구나 볼 수 있습니다. (기본값)

private (사유지): 내 침실. 오직 **나(현재 클래스)**만 들어갈 수 있습니다. 가족도 못 들어옵니다.

protected (보호구역): 거실. **나와 내 자식(상속받은 클래스)**까지만 들어갈 수 있습니다. 남은 못 들어옵니다.

코드로 보는 차이

TypeScript

class Employee {
  public name: string;      // 누구나 이름은 부를 수 있음
  private salary: number;   // 연봉은 나만 알아야 함 (1급 비밀)
  protected department: string; // 부서는 나랑 내 후배(상속)만 알면 됨

  constructor(name: string, salary: number, department: string) {
    this.name = name;
    this.salary = salary;
    this.department = department;
  }

  // 내부에서는 private인 salary에 접근 가능!
  public getSalaryCheck() {
    return this.salary; 
  }
}

const kim = new Employee("김철수", 5000, "개발팀");

console.log(kim.name);       // OK (public)
// console.log(kim.salary);  //   에러! "private 속성입니다."
// console.log(kim.department); //   에러! "protected 속성입니다."

3. 실무 꿀팁: 생성자 파라미터 단축 문법

실무에서는 코드를 짧게 쓰기 위해 생성자 안에서 접근 제어자를 바로 씁니다. React나 NestJS 코드 볼 때 당황하지 마세요!

TypeScript

class User {
  // 예전 방식
  // name: string;
  // constructor(name: string) { this.name = name; }

  // ✨ 최신 단축 방식 (위와 100% 똑같음)
  // 생성자 파라미터 앞에 public/private을 붙이면 알아서 변수도 만들어주고 값도 넣어줍니다.
  constructor(public name: string, private age: number) {}
}

const user = new User("짱구", 5);
console.log(user.name); // "짱구"
// user.age; // 에러 (private)

✍️ 8강 미니 퀴즈 & 실습

접근 제어자, 확실히 이해했는지 확인해 볼까요?

문제 1. (연결하기) 다음 상황에 알맞은 접근 제어자를 연결해 주세요.

public
private
protected

A. "이 변수는 클래스 내부에서만 쓰고, 밖에서는 절대 몰라야 해!" ( ) B. "이 변수는 어디서든 자유롭게 쓰고 고칠 수 있어." ( ) C. "이 변수는 나랑, 나를 상속받은 자식 클래스까지만 쓸 수 있어." ( )

문제 2. (에러 찾기) 다음 코드에서 에러가 발생하는 줄은 어디일까요?

TypeScript

class BankAccount {
  private balance: number = 0; // 잔고

  deposit(amount: number) {
    this.balance += amount; // A
  }
}

const myAccount = new BankAccount();
myAccount.deposit(1000);   // B
myAccount.balance = 50000; // C

✅ 정답 및 해설

문제 1 정답:
- A - 2 (private): 가장 강력한 보안입니다. 비밀번호, 내부 키 값 등에 씁니다.
- B - 1 (public): 기본값입니다. 안 적으면 public입니다.
- C - 3 (protected): 상속 관계에서 유용합니다.
문제 2 정답: C
- 해설: balance는 private으로 선언되었습니다. 즉, BankAccount 클래스 안에서만(this.balance) 건드릴 수 있습니다. 클래스 밖에서(myAccount.balance) 직접 숫자를 바꾸려고 하면 보안 위반으로 에러가 납니다.

고생하셨습니다! 이제 여러분은 데이터를 안전하게 보호하는 **캡슐화(Encapsulation)**의 기초를 마스터하셨습니다. Part 2의 절반을 넘어섰네요!

다음 9강과 10강은 타입스크립트의 '알파이자 오메가', **'만능 열쇠'**라고 불리는 **제네릭(Generics)**입니다. 많은 초보자분들이 여기서 포기하지만, 제 설명과 함께라면 "어? 그냥 파라미터랑 똑같네?" 하고 넘어가실 수 있습니다. 정말 중요하니 기대해 주세요!

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 7강

pursys — Wed, 21 Jan 2026 15:04:31 +0900

네, 7강에 오신 것을 환영합니다! 럭키 세븐이네요. 6강에서 **유니온 타입(|)**을 배우면서 "success" | "error" 같은 코드를 잠깐 보셨죠? "어? 타입 자리에 string이 아니라 구체적인 단어가 들어갔네?" 하고 느끼셨다면 눈썰미가 대단하신 겁니다.

오늘은 바로 그 **"딱 정해진 값만 받겠다!"**는 기술, 리터럴 타입과 Enum을 배워보겠습니다.

제7강. 리터럴 타입과 Enum: "메뉴판에 있는 것만 시키세요!"

식당에 가서 "밥 주세요"(string)라고 하면 주인이 곤란하겠죠? "김치볶음밥" 아니면 "오므라이스" 중에 하나를 콕 집어야 합니다. 타입스크립트도 변수에게 **"너는 아무 문자열이나 되지 말고, 딱 이 단어들 중 하나만 가져!"**라고 명령할 수 있습니다.

1. 리터럴 타입 (Literal Types): "구체적인 값 그 자체"

string, number 같은 뭉뚱그린 타입 대신, 값 그 자체를 타입으로 씁니다. 주로 **유니온 타입(|)**과 짝꿍으로 다닙니다.

비유: 자판기 버튼입니다. '콜라', '사이다', '환타' 버튼만 있습니다. '우유' 버튼은 없어서 누를 수(입력할 수) 없습니다.

① 코드 예시

TypeScript

// 문자열은 문자열인데, 오직 이 3가지 단어만 허용!
type ButtonSize = "small" | "medium" | "large";

let myBtn: ButtonSize = "small"; // OK
// myBtn = "extra-large"; //   에러! "그런 사이즈는 안 팝니다."

② [실무 핵심] React 컴포넌트 Props에서 ⭐️ React 버튼 컴포넌트를 만들 때 정말 많이 씁니다. 오타를 완벽하게 방지해주죠.

TypeScript

interface ButtonProps {
  // 테마는 딱 2가지만 있다!
  theme: "light" | "dark"; 
  label: string;
}

// 나중에 쓸 때:
// <Button theme="lite" ... />  <-- 'light' 오타 내면 바로 빨간 줄!

2. Enum (열거형): "이름표 붙인 상수들의 집합"

비슷한 기능인데, 관련된 상수들을 그룹으로 묶어서 관리하는 문법입니다. 다른 언어(Java, C#)에서 온 분들에게 익숙합니다.

① 코드 예시

TypeScript

// 메뉴판을 미리 만들어두는 느낌
enum UserRole {
  ADMIN = "ADMIN",
  USER = "USER",
  GUEST = "GUEST"
}

let myRole: UserRole = UserRole.ADMIN;

3. 선생님의 솔직한 조언: "뭘 써야 하나요?" (중요!)

이건 실무에서도 의견이 갈리지만, 최신 프론트엔드(React/Next.js) 트렌드를 딱 정해드릴게요.

요즘 트렌드: **리터럴 타입(1번)**을 훨씬 더 많이 씁니다.

이유:

코드가 더 간결함: UserRole.ADMIN 처럼 길게 안 쓰고 그냥 "ADMIN"이라고 쓰면 됩니다.
번들 용량: Enum은 자바스크립트로 변환될 때 꽤 복잡한 코드가 생성되지만, 리터럴 타입은 0바이트로 사라집니다(가볍습니다).
직관적임: 마우스를 올렸을 때 "small" | "medium" 하고 바로 보입니다.

결론: 특별한 이유가 없다면 리터럴 타입 + 유니온 조합을 먼저 고려하세요!

✍️ 7강 미니 퀴즈 & 실습

개념이 잡혔는지 확인해 볼까요?

문제 1. (코드 작성 - 리터럴 타입) 신호등 색깔을 저장하는 타입 TrafficLight를 만들어주세요. 오직 "red", "yellow", "green" 3가지 문자열만 허용해야 합니다.

TypeScript

type TrafficLight = // 여기에 코드를 작성하세요

문제 2. (에러 찾기) 다음 코드에서 에러가 나는 이유는 무엇일까요?

TypeScript

type Direction = "UP" | "DOWN" | "LEFT" | "RIGHT";

function move(dir: Direction) {
  console.log(dir + "로 이동!");
}

move("Up"); //   에러 발생!

move 함수가 void를 리턴해서
"Up"은 "UP"과 달라서 (대소문자 차이)
Direction은 enum이 아니라서

✅ 정답 및 해설

문제 1 정답:
- 해설: 아주 간단하죠? 이렇게 해두면 나중에 "blue" 같은 엉뚱한 색을 넣는 실수를 원천 봉쇄할 수 있습니다.

TypeScript

type TrafficLight = "red" | "yellow" | "green";

문제 2 정답: 2번
- 해설: 리터럴 타입은 토씨 하나 틀리면 안 됩니다. "UP"과 "Up"은 컴퓨터에게 완전히 다른 글자입니다. 오타나 대소문자 실수를 잡아주는 강력한 기능이죠!

고생하셨습니다! 이제 여러분은 변수에 아무 값이나 넣지 않고, **원하는 값 목록(화이트리스트)**을 딱 정해서 관리하는 능력을 얻었습니다. 여기까지가 타입스크립트의 기본적인 타입 정의 방법들이었습니다.

이제 8강에서는 조금 더 구조적인 문법인 **'클래스(Class)'**를 배울 차례입니다. "어? React 함수형 컴포넌트 쓰는데 클래스 몰라도 되지 않나요?" 라고 하실 수 있지만, 타입스크립트의 private, public 같은 접근 제어자 개념은 알아두면 데이터 관리할 때 정말 유용합니다. 아주 짧고 굵게 핵심만 짚어드릴게요.

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 6강

pursys — Wed, 21 Jan 2026 15:01:49 +0900

반갑습니다! 6강까지 오시다니, 이제 정말 타입스크립트와 친해지신 것 같네요. ‍♂️

우리가 5강 마지막에 살짝 맛봤던 **'합체'**와 **'선택'**의 기술을 본격적으로 배워볼 시간입니다. 이 기능을 알면 코드가 아주 유연해집니다. 딱딱한 타입스크립트를 말랑말랑하게 만드는 비법이죠!

제6강. 유니온 타입과 인터섹션: "또는(|) 그리고(&)"

1. 유니온 타입 (Union Type): "이거 아니면 저거 (OR)"

유니온(Union)은 **'합집합'**입니다. 파이프 기호 | (Shift + 백슬래시)를 사용합니다. "A 타입이어도 되고, B 타입이어도 돼!" 라고 허락해 주는 것이죠.

비유: 짬짜면 그릇입니다. 짜장면(A)을 담아도 되고, 짬뽕(B)을 담아도 됩니다. (물론 둘 다 담을 수 있는 그릇이죠).

① 기본 사용법 변수 하나에 숫자도 넣고 싶고 문자도 넣고 싶을 때 씁니다.

TypeScript

// 숫자여도 되고, 문자여도 됩니다.
let id: string | number;

id = "user_123"; // OK
id = 123;        // OK
// id = true;    //   에러! (boolean은 허락 안 함)

② [실무 핵심] React에서의 활용 ⭐️ React를 하다 보면 **"데이터가 아직 안 왔을 때(로딩 중)"**를 처리해야 합니다. 이때 데이터는 '있을 수도 있고', '없을 수도(null)' 있죠.

TypeScript

// 유저 정보가 있을 수도 있고(User), 아직 없을 수도 있음(null)
type User = { name: string; age: number };

// React의 useState에서 정말 많이 봅니다!
const [user, setUser] = useState<User | null>(null);

이렇게 하면 user 변수는 처음엔 null이었다가, 나중에 데이터가 로딩되면 User 객체로 바뀔 수 있게 됩니다.

2. 인터섹션 타입 (Intersection Type): "너랑 나랑 합체 (AND)"

인터섹션(Intersection)은 **'교집합'**이라는 뜻이지만, 실제로는 **'합체(Fusion)'**에 가깝습니다. 앤퍼센트 기호 &를 사용합니다. "A 타입의 특징도 갖고 있고, B 타입의 특징도 다 가져야 해!" 라는 뜻입니다.

비유: 스마트폰입니다. 전화기(A) 기능도 있어야 하고, 그리고(&) 카메라(B) 기능도 있어야 스마트폰이라고 부를 수 있죠.

① 기본 사용법 두 개의 타입을 합쳐서 새로운, 더 강력한 타입을 만듭니다.

TypeScript

type IronMan = { fly: () => void };
type CaptainAmerica = { shield: boolean };

// 두 영웅의 능력을 합친 '어벤져스' 타입 탄생!
type Avengers = IronMan & CaptainAmerica;

const hero: Avengers = {
  fly: () => console.log("슈웅~"), // IronMan 속성 필수
  shield: true                     // CaptainAmerica 속성 필수
};

만약 하나라도 빼먹으면? "어벤져스 자격 미달이야!" 라며 에러가 납니다.

② [실무 핵심] 언제 쓸까요? 주로 남이 만든 타입에 내 입맛대로 속성을 추가하고 싶을 때 씁니다. (5강에서 배운 extends와 비슷하죠?)

TypeScript

// 1. 기본 버튼 타입 (남이 만든 것)
type ButtonProps = {
  color: string;
  onClick: () => void;
};

// 2. 내가 만든 아이콘 버튼 (기본 버튼 + 아이콘 속성 추가)
type IconButtonProps = ButtonProps & {
  iconName: string;
};

⚠️ 주의할 점 (초보자가 자주 하는 실수)

유니온 타입(|)을 쓸 때 주의하세요. "문자열(string) 또는 숫자(number)야" 라고 하면, 타입스크립트는 보수적으로 **"둘 다 공통적으로 가지고 있는 기능"**만 쓰게 해줍니다.

TypeScript

function printId(id: string | number) {
  // console.log(id.toUpperCase()); 
  //   에러! 숫자가 들어올 수도 있는데 대문자 변환(toUpperCase)을 어떻게 해?
  
  // 해결책: "너 문자열 맞니?" 하고 확인해야 함 (이건 12강에서 배웁니다!)
  if (typeof id === "string") {
    console.log(id.toUpperCase()); // 이제 OK!
  }
}

✍️ 6강 미니 퀴즈 & 실습

개념을 잡았으니 확인해 봅시다!

문제 1. (코드 작성) Status라는 타입을 만들고 싶습니다. 이 타입은 오직 문자열 "success" 또는 문자열 "error" 둘 중 하나만 가질 수 있습니다. (유니온 타입 활용)

TypeScript

type Status = // 여기에 코드를 작성하세요

문제 2. (결과 예측) 다음 Worker 타입 변수를 만들 때 필요한 속성은 총 몇 개일까요?

TypeScript

type Person = { name: string };
type Skill = { coding: boolean };
type Worker = Person & Skill; // 인터섹션!

const kim: Worker = { ... };

1개 (name)
1개 (coding)
2개 (name과 coding 둘 다)

✅ 정답 및 해설

문제 1 정답:
- 해설: 문자열 자체를 타입으로 쓰는 것(리터럴 타입)을 유니온(|)으로 묶으면 됩니다. 이게 바로 다음 7강 예습입니다!
TypeScript
```
type Status = "success" | "error";
```
문제 2 정답: 3번 (2개)
- 해설: &는 '그리고' 입니다. Person의 속성(name)도 있어야 하고, 그리고 Skill의 속성(coding)도 모두 가지고 있어야 Worker로 인정받습니다.

고생하셨습니다! 이제 "이것도 되고 저것도 되는(|)" 유연함과, "이것도 있고 저것도 있는(&)" 강력함을 모두 손에 넣으셨습니다.

방금 퀴즈 1번에서 "success" | "error" 처럼 딱 정해진 값만 받는 방법을 보셨죠? 이걸 전문 용어로 **'리터럴 타입'**이라고 합니다. 실무에서 "이 버튼은 'small', 'medium', 'large' 사이즈만 있어!" 라고 제한할 때 엄청나게 많이 쓰입니다.

다음 7강에서는 이 리터럴 타입과, 비슷한 듯 다른 Enum에 대해 확실하게 정리해 드리겠습니다.

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 5강

pursys — Wed, 21 Jan 2026 14:58:16 +0900

네, 5강에 오신 것을 환영합니다! ️

많은 분들이 타입스크립트를 공부할 때 "도대체 interface랑 type이랑 뭐가 다른 거야?" 하고 가장 많이 헷갈려 하십니다. 사실 기능적으로는 90% 비슷하거든요.

하지만 미묘한 차이를 알면 상황에 딱 맞는 도구를 골라 쓸 수 있습니다. 오늘 이 논란을 아주 깔끔하게 종결시켜 드릴게요!

제5강. 객체를 정의하는 법 2 - 타입 별칭(Type Alias) vs 인터페이스

1. 타입 별칭(Type Alias): "너의 이름은..."

인터페이스가 **'정식 계약서'**라면, 타입 별칭(type)은 데이터에 **'별명(닉네임)'**을 붙여주는 것과 같습니다.

① 기본 사용법 type 키워드를 쓰고 = (등호)를 사용합니다. (변수 만드는 거랑 비슷하죠?)

TypeScript

// 인터페이스랑 거의 똑같아 보이죠?
type User = {
  name: string;
  age: number;
};

const kim: User = { name: "김코딩", age: 25 };

② 타입 별칭만 할 수 있는 것 (강력한 기능!) 인터페이스는 오직 '객체' 모양만 정의할 수 있지만, type은 모든 데이터에 별명을 붙일 수 있습니다.

TypeScript

// 1. 기본 타입에 별명 붙이기 (ID는 문자열이야!)
type ID = string;

// 2. 여러 타입을 묶기 (Union Type - 6강 예고!)
type Status = "success" | "error" | "loading";

const myId: ID = "user_123";
const currentStatus: Status = "success";

핵심: 단순한 데이터나, 여러 타입을 조합할 때는 type이 훨씬 편합니다.

2. 결정적 차이: "확장하는 방법"

이 부분이 면접 질문으로도 자주 나옵니다. "기존에 만든 것에 내용을 더 추가하고 싶을 때" 어떻게 할까요?

① 인터페이스: 상속(extends) 객체 지향 프로그래밍 느낌으로 extends를 써서 내용을 물려받습니다.

TypeScript

interface Animal {
  name: string;
}

// Animal을 상속받아 size를 추가!
interface Bear extends Animal {
  size: number;
}

// 결과: { name: string; size: number }

② 타입 별칭: 교차(& - Intersection) 두 가지 타입을 **'합친다'**는 느낌으로 & 기호를 씁니다.

TypeScript

type Animal = {
  name: string;
}

// Animal과 size를 합침!
type Bear = Animal & {
  size: number;
}

3. 실무 가이드: 그래서 뭘 써야 하나요?

이게 제일 중요하죠. 정답은 없지만, **실무 국룰(Convention)**은 있습니다.

객체(Object) 데이터를 정의할 때: 주로 **interface**를 씁니다. (확장이 편하고 에러 메시지가 좀 더 깔끔합니다.)
- 예: React 컴포넌트의 Props, API 응답 데이터 등
단순 타입, 유니온 타입, 튜플 등을 정의할 때: **type**을 씁니다.
- 예: type ID = string | number;
가장 중요한 원칙: 팀의 규칙을 따르세요! (팀에서 type만 쓰기로 했으면 type만 씁니다. 일관성이 생명입니다.)

선생님의 추천: 시작은 **interface**로 하세요. 그러다 "어? 인터페이스로는 표현이 안 되네?" 싶을 때(예: string | number) **type**으로 넘어가면 됩니다.

✍️ 5강 미니 퀴즈 & 실습

개념 정리를 위해 문제를 풀어볼까요?

문제 1. (코드 변환) 다음 인터페이스 코드를 type 별칭 문법으로 바꿔보세요.

TypeScript

// [Before] Interface
interface Point {
  x: number;
  y: number;
}

TypeScript

// [After] Type Alias
// 여기에 코드를 적어보세요

문제 2. (선택) 다음 중 interface로는 만들 수 없는 타입 정의는 무엇일까요?

{ name: string; age: number } (객체)
string | number (문자열이거나 숫자 - 유니온 타입)
{ readonly id: number } (읽기 전용 속성)

✅ 정답 및 해설

문제 1 정답:
- 해설: interface 대신 type을 쓰고, 이름 뒤에 **= (등호)**를 붙여주면 끝입니다!

TypeScript

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

문제 2 정답: 2번
- 해설: interface는 객체의 모양을 정의하는 설계도입니다. "A 아니면 B" 같은 **유니온 타입(|)**은 오직 **type**으로만 정의할 수 있습니다. 이것이 type이 필요한 결정적인 이유입니다.

고생하셨습니다! 이제 interface와 type의 차이를 알았으니, 상황에 맞춰 골라 쓰는 센스를 갖추게 되셨습니다. Part 1 기초 체력 다지기가 거의 끝나가네요!

다음 6강에서는 방금 살짝 맛본, **"이거 아니면 저거?"**를 다루는 **유니온 타입(|)**과 **인터섹션 타입(&)**을 제대로 배워보겠습니다. 실무에서 정말 많이 쓰이는 **'유연한 코드'**의 핵심입니다.

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 4강

pursys — Wed, 21 Jan 2026 14:52:52 +0900

좋습니다! 핵심 중의 핵심, 4강에 오신 것을 환영합니다. 지금까지는 숫자 하나, 문자 하나 같은 단순한 데이터를 다뤘죠? 하지만 실무에서는 "이름은 철수고, 나이는 30살이고, 기술스택은 React인 개발자" 처럼 여러 정보가 뭉쳐진 **객체(Object)**를 다룰 일이 99%입니다.

이 객체의 모양을 아주 예쁘고 엄격하게 정의하는 방법, 바로 **인터페이스(Interface)**입니다.

제4강. 객체를 정의하는 법 1 - 인터페이스 (Interface)

1. 개념 쏙쏙: "객체의 설명서(Specification)"

인터페이스는 "이 객체는 이렇게 생겨야만 해!" 라고 정해두는 설명서이자 계약서입니다.

비유:

객체(Object): 실제 만들어진 '붕어빵'

인터페이스(Interface): 붕어빵을 찍어내는 '붕어빵 틀' (또는 설계도)

설계도에 "꼬리는 3cm"라고 적혀있는데, 꼬리가 없는 붕어빵을 만들면 불량이겠죠? 타입스크립트는 이 설계도를 보고 불량품을 걸러냅니다.

2. 코드 사용법 (따라해보세요!)

interface 키워드를 쓰고 이름을 붙인 뒤(보통 대문자로 시작), 필요한 속성들의 타입을 적어줍니다.

TypeScript

// 1. 설계도(인터페이스) 만들기
interface User {
  name: string;
  age: number;
  isDeveloper: boolean;
}

// 2. 실제 객체 만들기 (설계도 적용)
// 변수명 뒤에 ': User'라고 적어서, "이 변수는 User 설계도를 따릅니다"라고 선언합니다.
const member1: User = {
  name: "김코딩",
  age: 28,
  isDeveloper: true
};

//   에러 상황
const member2: User = {
  name: "이철수",
  age: 30
  // 앗! isDeveloper가 빠졌네요. 
  // 에러: 'isDeveloper' 속성이 'User' 형식에 없지만 필수입니다.
};

3. 실무 꿀팁: 옵션과 읽기 전용

실무에서는 모든 속성이 다 필수인 건 아닙니다. 그리고 절대 수정하면 안 되는 값도 있죠.

선택적 속성 (?): "있어도 되고 없어도 돼" (3강에서 배운 것과 같아요!)
읽기 전용 (readonly): "처음에 만들 때만 넣고, 나중엔 절대 수정 불가!" (주민번호, ID 같은 것)

TypeScript

interface Car {
  readonly id: number; // 자동차 고유 번호 (수정 불가)
  model: string;       // 모델명
  color?: string;      // 색상 (없을 수도 있음)
}

const myCar: Car = {
  id: 12345,
  model: "Tesla"
  // color는 없어도 에러 안 남! (?) 덕분이죠.
};

// myCar.id = 99999; //   에러! readonly라 수정할 수 없습니다.
myCar.model = "Ionic"; // 이건 수정 가능!

4. React에서의 활용 미리보기

나중에 우리가 만들 게시판의 게시글 데이터를 이렇게 정의하게 됩니다. 벌써 실무 느낌이 나죠?

TypeScript

interface Post {
  id: number;
  title: string;
  content: string;
  author?: string; // 작성자는 익명일 수도 있으니 선택값으로!
}

✍️ 4강 미니 퀴즈 & 실습

인터페이스, 이제 감이 좀 오시나요? 간단한 퀴즈로 확인해 봅시다.

문제 1. (코드 작성) 다음 요구사항에 맞는 Pizza 인터페이스를 작성해 보세요.

name은 문자열이고 필수입니다.
price는 숫자이고 필수입니다.
topping은 문자열 배열(string[])이고, 있어도 되고 없어도 됩니다.

TypeScript

interface Pizza {
  // 여기에 코드를 적어보세요
}

문제 2. (OX 퀴즈) readonly가 붙은 속성은 객체가 만들어진 이후에도 마음대로 값을 바꿀 수 있다. (O / X)

✅ 정답 및 해설

문제 1 정답:
- 해설: 선택 사항이므로 속성명 뒤에 ?를 붙여야 하고, 여러 개의 토핑이 들어갈 수 있으니 문자열 배열 string[]을 사용하면 완벽합니다.

TypeScript

interface Pizza {
  name: string;
  price: number;
  topping?: string[]; // 핵심! 물음표(?)와 배열([])을 잘 썼나요?
}

문제 2 정답: X
- 해설: readonly는 '읽기 전용'입니다. 처음에 값을 할당할 때 외에는 절대 수정할 수 없습니다. 데이터가 꼬이는 걸 방지하는 아주 좋은 기능이죠.

고생 많으셨습니다! 이제 여러분은 **"데이터의 설계도"**를 그릴 줄 아는 개발자가 되었습니다.

그런데 타입스크립트 코드를 보다 보면 interface 말고 type이라는 것으로 똑같이 만드는 걸 볼 수 있을 거예요. "어? 둘 다 비슷한 것 같은데 도대체 뭘 써야 하지?" 혼란스러우시죠?

다음 5강에서는 '타입 별칭(Type Alias) vs 인터페이스', 이 영원한 난제를 아주 깔끔하게 정리해 드립니다. 이것만 알면 기본기는 졸업입니다!

Typescript 완벽 가이드｜기초부터 실전까지 한 번에 정리 - 3강

pursys — Wed, 21 Jan 2026 14:48:22 +0900

네, 좋습니다! 속도가 아주 좋네요. 바로 3강으로 들어가 봅시다.

이번 시간에는 프로그래밍의 꽃, **'함수(Function)'**를 다뤄볼 겁니다. React나 Next.js를 하다 보면 컴포넌트도 결국 함수고, 이벤트 처리하는 것도 함수고... 온통 함수 세상이죠? 여기서 타입을 딱 잡아두면 에러가 획기적으로 줄어듭니다.

제3강. 함수에도 타입을 입혀보자: "입구와 출구를 지켜라!"

함수는 **'자판기'**와 같습니다.

입구 (Parameter, 매개변수): 동전을 넣는 곳
내부 로직: 윙~ 하고 돌아가는 기계 장치
출구 (Return, 반환값): 음료수가 나오는 곳

타입스크립트는 이 자판기의 입구와 출구에 경비원을 세우는 것입니다. "이 입구엔 500원짜리만 들어와!", "이 출구에선 콜라만 나와야 해!"라고 말이죠.

1. 함수의 기본 문법 (입구와 출구 정의하기)

자바스크립트 함수에 딱 두 군데만 신경 쓰면 됩니다. () 안쪽과 () 바깥쪽입니다.

TypeScript

// (a: number, b: number)  <-- 입구(매개변수): 숫자만 들어와!
// : number                <-- 출구(반환값): 나갈 땐 무조건 숫자여야 해!
function add(a: number, b: number): number {
  return a + b;
}

이걸 요즘 React에서 많이 쓰는 **화살표 함수(Arrow Function)**로 바꾸면 이렇게 됩니다.

TypeScript

const add = (a: number, b: number): number => {
  return a + b;
};

꿀팁: 사실 '출구(반환값)' 타입은 안 적어도 타입스크립트가 알아서 추측(추론)해 줍니다. a랑 b가 숫자면 더한 값도 당연히 숫자겠지? 하고요. 하지만, 명확하게 적어주는 습관이 실수를 줄여줍니다.

2. 실무 꿀팁: "있을 수도, 없을 수도?" (선택적 매개변수 ?)

실무를 하다 보면 어떤 값은 꼭 필요하지만, 어떤 값은 없어도 될 때가 있습니다. 예를 들어, 회원가입할 때 '이름'은 필수지만 '별명'은 선택사항일 수 있죠.

이때 변수명 뒤에 물음표(?) 만 붙이면 됩니다.

TypeScript

// nickname 뒤에 ?가 붙었죠? "문자열이거나, 아니면 아예 없거나(undefined)"라는 뜻입니다.
function printProfile(name: string, nickname?: string) {
  console.log(`이름: ${name}`);
  
  if (nickname) {
    console.log(`별명: ${nickname}`);
  } else {
    console.log("별명 없음");
  }
}

printProfile("김코딩");             // OK! (별명 안 넣어도 됨)
printProfile("이철수", "스파이더맨"); // OK! (별명 넣어도 됨)

⚠️ 주의: 선택적 매개변수(?)는 무조건 필수 매개변수 뒤에 와야 합니다. (nickname?: string, name: string) 순서로 쓰면 에러가 납니다. (중요한 게 먼저 와야 하니까요!)

3. React에서의 활용 (맛보기)

나중에 자세히 배우겠지만, React 컴포넌트도 함수죠? "이 컴포넌트는 name이라는 문자열을 받아서 HTML(JSX)을 뱉어내는 함수야!"라고 정의하는 식입니다.

TypeScript

// 간단한 예시 (나중에 더 자세히 배웁니다)
const WelcomeMessage = (name: string): string => {
  return `환영합니다, ${name}님!`;
};

✍️ 3강 미니 퀴즈 & 실습

개념을 잡았으니 문제를 풀어봅시다!

문제 1. (코드 완성) 두 개의 숫자 price(가격)와 count(개수)를 받아서, 총금액(숫자)을 반환하는 함수 calculateTotal을 만들려고 합니다. 빈칸 (A)와 (B)에 들어갈 코드는?

TypeScript

function calculateTotal(price: number, count: number): (A) {
  return price * count;
}

(A): string
(A): number
(A): void

문제 2. (에러 찾기) 다음 코드에서 에러가 발생하는 이유는 무엇일까요?

TypeScript

function greet(name?: string, age: number) {
  console.log(name, age);
}

name은 문자열인데 숫자를 넣어서
age에 타입을 지정하지 않아서
선택적 매개변수(?)가 필수 매개변수보다 앞에 와서

✅ 정답 및 해설

문제 1 정답: 2번 (number)
- 해설: 숫자끼리 곱하면 결과도 당연히 숫자(number)가 나와야겠죠? string은 문자열, void는 리턴값이 없을 때 씁니다.
문제 2 정답: 3번
- 해설: 아까 배운 꿀팁 기억나시죠? 물음표(?) 붙은 녀석은 항상 맨 뒤로 가야 합니다. function greet(age: number, name?: string) 순서로 바꿔야 에러가 사라집니다.

수고하셨습니다! 이제 함수에 데이터가 들어오고 나가는 길목을 완벽하게 통제할 수 있게 되었습니다.

그런데 지금까지는 숫자, 문자 같은 간단한 것만 다뤘죠? 실무에서는 { name: "철수", age: 30, skills: ["React"] } 처럼 복잡한 '객체(Object)' 데이터를 훨씬 많이 다룹니다.

이런 객체의 모양을 정의하는 **'설계도'**를 만드는 방법, 바로 **4강 '인터페이스(Interface)'**에서 배울 차례입니다. 타입스크립트의 꽃이라고 할 수 있죠!