LogoSEO Jing
  • All Posts
  • SEO Jing
  • okayJing
  • KD Team
  • CLAB Coreteam
  • Study

Contact Me

© 2026 SEOJing. All rights reserved.

JS 퀴즈북 × 이펙티브 타입스크립트 읽기 지도

2026년 7월 12일·9분 읽기
대상 글: JavaScript Quizbook 리마인드 Day 1–13, Effective TypeScript 2판 Day 1–14
이 글의 목적: 두 시리즈를 순서대로 다 읽은 뒤, 프론트엔드 코드 리뷰 질문별로 다시 찾아 들어갈 수 있게 만드는 지도

두 시리즈는 처음부터 역할이 조금 달랐습니다. JavaScript Quizbook 리마인드는 런타임에서 실제로 값이 어떻게 움직이는지를 붙잡는 글이고, Effective TypeScript 2판 시리즈는 그 움직임을 타입과 API 경계로 어떻게 좁히고 표현할지를 보는 글입니다.

그래서 복습할 때는 “JS 1일부터 TS 14일까지 다시 정주행”보다, 지금 리뷰 중인 코드가 어떤 질문을 던지는지부터 잡는 편이 낫습니다.

JS 런타임 감각과 TS 리뷰 감각을 연결한 지도

1. 값·비교·강제 변환을 의심할 때

먼저 읽을 글은 JavaScript Quizbook Day 1–3입니다.

[Day 1: 숫자 모델과 NaN](/blog/study/javascript-quizbook/day1) [Day 2: 동등성 알고리즘](/blog/study/javascript-quizbook/day2) [Day 3: 강제 변환과 ToPrimitive](/blog/study/javascript-quizbook/day3)

이 구간은 “왜 이 값이 같다고 나오지?”, “왜 빈 문자열이 빠졌지?”, “왜 +가 문자열 연결로 바뀌지?” 같은 버그를 다룹니다. 런타임 규칙을 모르면 TypeScript 쪽에서 string | number를 얼마나 예쁘게 표현해도 리뷰가 흔들립니다.

같이 읽을 TypeScript 글은 Day 1–2입니다.

[Effective TS Day 1: TS/JS 관계와 any 경계](/blog/study/effective-typescript/day1) [Effective TS Day 2: 타입은 값의 집합이다](/blog/study/effective-typescript/day2)

여기서 연결되는 질문은 하나입니다.

타입은 가능한 값의 집합을 줄여주지만, 런타임 비교와 변환 규칙을 대신 실행해주지는 않는다.

예를 들어 id: string | number를 허용하는 순간, 비교 정책도 같이 정해야 합니다. ==로 느슨하게 맞출지, API 경계에서 문자열로 정규화할지, 아예 서로 다른 타입으로 나눌지 결정해야 합니다. TypeScript는 그 결정을 표현할 수 있지만, 결정 자체를 대신 해주지는 않습니다.

2. 객체 참조와 상태 모델을 같이 볼 때

객체 복사, Map/Set, WeakMap, 얕은 복사 문제는 JavaScript Quizbook Day 4–5로 돌아가면 됩니다.

[Day 4: 프로퍼티 descriptor와 객체 제한](/blog/study/javascript-quizbook/day4) [Day 5: 참조, 복사, Map/Set](/blog/study/javascript-quizbook/day5)

이 구간의 핵심은 “새 값처럼 보이는 것이 정말 새 값인가?”입니다. `는 최상위 객체만 새로 만들 수 있고, const는 객체 내부 불변을 보장하지 않으며, Map`은 key를 강하게 붙잡을 수 있습니다.

TypeScript 쪽에서는 Day 6과 연결됩니다.

[Effective TS Day 6: 유효한 상태만 표현하는 타입 설계](/blog/study/effective-typescript/day6)

상태 타입을 잘 만들었다고 해도, 앱 내부에서 같은 객체 참조를 여러 캐시와 UI 상태가 공유하면 이상한 변경이 퍼질 수 있습니다. 반대로 참조 모델을 잘 이해해도, loading: boolean; data?: T; error?: string처럼 불가능한 상태 조합을 허용하면 렌더링 branch가 복잡해집니다.

리뷰 순서는 이렇게 잡으면 좋습니다.

질문먼저 볼 글이어서 볼 글
복사한 객체가 원본을 바꾸는가?JS Day 5TS Day 6
캐시가 객체를 계속 붙잡는가?JS Day 5TS Day 8
상태 조합이 이상한가?TS Day 6JS Day 4–5
readonly/as const가 안전해 보이지만 런타임은 다른가?TS Day 3, TS Day 6JS Day 4

3. 스코프·클로저·비동기 순서를 추적할 때

오래된 값, stale closure, await 뒤 최신성 문제는 JavaScript Quizbook Day 6–8을 한 묶음으로 봐야 합니다.

[Day 6: 스코프 체인과 호이스팅](/blog/study/javascript-quizbook/day6) [Day 7: 클로저 버그와 오래된 값](/blog/study/javascript-quizbook/day7) [Day 8: 이벤트 루프와 Promise 타이밍](/blog/study/javascript-quizbook/day8)

이 세 글은 순서가 중요합니다. Day 6은 “함수가 어느 바인딩을 보나”를 잡고, Day 7은 “그 바인딩이 나중에 실행될 때 오래될 수 있나”를 묻고, Day 8은 “그 나중이 정확히 어느 큐 뒤인가”를 봅니다.

TypeScript에서는 Day 5, Day 13과 연결됩니다.

[Effective TS Day 5: narrowing과 async/type flow](/blog/study/effective-typescript/day5) [Effective TS Day 13: 런타임 타입, DOM, 테스트, 성능](/blog/study/effective-typescript/day13)

TypeScript가 if (!currentUser) return 뒤의 타입을 좁혀줘도, await 동안 전역 상태가 바뀌는지까지 보장하지는 않습니다. DOM 타입이 정확해도, 실제 브라우저 이벤트와 렌더 타이밍을 테스트하지 않으면 깨질 수 있습니다.

리뷰할 때는 이 질문을 그대로 쓰면 됩니다.

이 함수는 어디서 만들어졌고, 언제 실행되며, 그 사이 어떤 값이 바뀔 수 있나?

4. 타입 설계가 과하게 넓거나 좁을 때

Effective TypeScript Day 3–7은 타입 설계의 기본 골격입니다.

[Day 3: excess property, 함수 타입, type/interface, readonly](/blog/study/effective-typescript/day3) [Day 4: index signature와 추론 기본](/blog/study/effective-typescript/day4) [Day 5: narrowing과 흐름](/blog/study/effective-typescript/day5) [Day 6: 유효한 상태와 API 경계](/blog/study/effective-typescript/day6) [Day 7: string, optional, special value, 이름](/blog/study/effective-typescript/day7)

이 구간은 “타입을 많이 적자”가 아니라 “검토해야 할 경우의 수를 줄이자”에 가깝습니다. string 하나로 모든 상태를 표현하면 간단해 보이지만, 실제로는 리뷰어가 가능한 문자열 전체를 머릿속에 들고 있어야 합니다. optional 필드가 많으면 객체 하나가 너무 많은 상태를 허용할 수 있습니다.

JavaScript 쪽에서는 Day 1–5가 배경입니다. 값의 실제 모양, 객체 참조, 프로퍼티 동작을 모른 채 타입만 좁히면 as const, readonly, Object.freeze 같은 말이 서로 섞입니다.

5. `any`, `unknown`, assertion이 보이면

바로 Effective TypeScript Day 8로 가면 됩니다.

[Day 8: any, unknown, assertion, soundness traps](/blog/study/effective-typescript/day8)

이 글은 TypeScript 시리즈의 안전벨트에 가깝습니다. 외부 데이터, 라이브러리 틈, monkey patching, assertion을 다룰 때 “일단 통과시키는 타입”이 어디서 들어오는지 봐야 합니다.

같이 읽을 JavaScript 글은 상황에 따라 다릅니다.

외부 JSON 값의 숫자/문자열 혼합이면 JS Day 1–3 객체 shape와 프로퍼티 접근이면 JS Day 4–5 async 뒤 stale result면 JS Day 7–8

unknown은 귀찮은 타입이 아니라 “여기서 아직 모른다”는 표시입니다. 반대로 any는 그 표시를 지워버립니다. 리뷰에서는 any를 발견했을 때 바로 없애기보다, 어느 경계에서 검증하면 가장 작게 줄일 수 있는지부터 봐야 합니다.

6. 제네릭·조건부 타입·템플릿 리터럴 타입이 어려울 때

Effective TypeScript Day 9–10을 읽으면 됩니다.

[Day 9: type coverage, generics, conditional/template literal types](/blog/study/effective-typescript/day9) [Day 10: type test, display, tail recursion, codegen, never exhaustiveness](/blog/study/effective-typescript/day10)

이 구간은 “타입 퍼즐”로 읽으면 금방 피곤해집니다. 프론트엔드 코드 리뷰 관점에서는 공개 API, route param, event name, design-system prop처럼 반복 규칙이 있는 문자열/객체를 얼마나 안전하게 표현할지에 가깝습니다.

JavaScript 쪽 연결은 Day 10–13입니다.

[JS Day 10: 함수와 아키텍처](/blog/study/javascript-quizbook/day10) [JS Day 11: prototype과 class](/blog/study/javascript-quizbook/day11) [JS Day 13: ESM과 모듈 경계](/blog/study/javascript-quizbook/day13)

타입이 복잡해지는 곳은 대개 런타임 구조도 복잡합니다. 함수 합성, 클래스 인스턴스, 모듈 export/import 경계가 흐린데 타입만 똑똑해지면 리뷰가 더 어려워질 수 있습니다.

7. DOM, 브라우저 환경, 테스트를 볼 때

DOM과 런타임 검증은 Effective TypeScript Day 13이 중심입니다.

[Effective TS Day 13: 런타임 타입, DOM, 환경 모델, 테스트](/blog/study/effective-typescript/day13)

이 글은 타입 시스템 바깥을 보는 훈련입니다. 브라우저 API는 타입 정의가 있어도 실제 DOM 상태, 렌더 타이밍, 이벤트 순서를 테스트해야 합니다. 그래서 JavaScript Quizbook Day 8, Day 12와 같이 읽는 편이 좋습니다.

[JS Day 8: 이벤트 루프와 Promise 타이밍](/blog/study/javascript-quizbook/day8) [JS Day 12: 브라우저 이벤트](/blog/study/javascript-quizbook/day12)

실제 리뷰에서는 이런 식으로 묻습니다.

타입은 HTMLElement라고 말하지만, 실제 selector가 항상 그 요소를 찾는가? 이벤트가 capture/bubble 어느 단계에서 처리되는가? Promise/microtask 뒤 DOM 측정이 의도한 시점에 일어나는가? unit test는 타입이 놓친 런타임 branch를 확인하는가?

8. 모듈·마이그레이션·점진적 개선을 할 때

마지막 묶음은 JavaScript Quizbook Day 13과 Effective TypeScript Day 14입니다.

[JS Day 13: ESM live binding과 모듈 경계](/blog/study/javascript-quizbook/day13) [Effective TS Day 14: JS 마이그레이션과 noImplicitAny](/blog/study/effective-typescript/day14)

모듈은 파일을 나누는 문법이 아니라 의존성과 실행 순서를 만드는 경계입니다. ESM live binding, circular dependency, dynamic import를 모르면 “분리했는데 왜 초기화 순서가 꼬이지?” 같은 문제가 남습니다.

TypeScript 마이그레이션은 여기서 현실적인 끝을 맺습니다. 모든 파일을 한 번에 .ts로 바꾸는 게 아니라, @ts-check, JSDoc, allowJs, 모듈별 변환, noImplicitAny 같은 단계로 위험을 줄입니다.

추천 복습 순서

처음부터 다시 읽을 시간이 없다면 아래 네 경로 중 하나만 골라도 됩니다.

값 버그가 많을 때

JS Day 1 JS Day 2 JS Day 3 Effective TS Day 2 Effective TS Day 8

React 상태·비동기 버그가 많을 때

JS Day 6 JS Day 7 JS Day 8 Effective TS Day 5 Effective TS Day 6 Effective TS Day 13

API 타입 설계를 정리할 때

Effective TS Day 3 Effective TS Day 5 Effective TS Day 6 Effective TS Day 7 Effective TS Day 8 JS Day 5

JS 프로젝트를 TS로 옮길 때

Effective TS Day 1 Effective TS Day 14 JS Day 13 Effective TS Day 12 Effective TS Day 10

마지막으로 남길 기준

두 시리즈를 같이 읽는 이유는 “JS를 알고 TS를 쓰자”라는 구호 때문이 아닙니다. 코드 리뷰에서 실제로 필요한 질문이 서로 이어지기 때문입니다.

JavaScript는 값, 참조, 실행 순서, 모듈 경계를 보여줍니다. TypeScript는 그 경계 중 어디를 타입으로 표현하고, 어디를 런타임 검증과 테스트로 남겨야 하는지 보여줍니다. 프론트엔드 리뷰는 둘 중 하나만으로 끝나지 않습니다. 타입이 맞아도 런타임이 틀릴 수 있고, 런타임을 알아도 타입 설계가 상태 공간을 줄이지 못하면 유지보수가 어려워집니다.

복습할 때는 글 순서보다 리뷰 질문을 먼저 잡으면 됩니다. “이 버그는 값 비교인가, 참조 공유인가, 오래된 콜백인가, API 경계인가, 런타임 검증인가?” 그 질문이 정해지면 위 지도에서 다시 들어갈 글도 자연스럽게 정해집니다.

Post Q&A

오케이징에게 물어보기

JS 퀴즈북 × 이펙티브 타입스크립트 읽기 지도 전체를 기준으로 질문과 피드백을 받아요.답을 본 뒤에는 이 내용을 댓글로 달아서 서징에게도 물어볼 수 있어요. 작성자가 직접 볼 수 있어요!

0/500

포스트 목록

/study
파일 1개, 폴더 5개
JS 퀴즈북 × 이펙티브 타입스크립트 읽기 지도

같은 섹션의 대표 이미지

80 posts · latest first
JavaScript Quizbook과 Effective TypeScript를 코드 리뷰 주제별로 연결한 읽기 지도
Study26. 07. 13.

JS 퀴즈북 × 이펙티브 타입스크립트 읽기 지도.

JavaScript Quizbook 13일과 Effective TypeScript 2판 14일을 값, 참조, 스코프, 비동기, 타입 설계, 런타임 검증, 마이그레이션 주제로 다시 묶어 읽는 안내서입니다.

26. 07. 13.SEOJing
런타임 값 검증, DOM 환경, 테스트, 컴파일러 성능으로 이어지는 타입스크립트 경계 다이어그램
Study26. 07. 09.

이펙티브 타입스크립트 2판 Day 13: 타입은 런타임과.

Item 74–78 범위를 바탕으로 런타임 타입 재구성, DOM과 환경 모델, 단위 테스트 관계, 컴파일러 성능을 코드 리뷰 관점에서 정리합니다.

26. 07. 09.SEOJing
JavaScript 현대화에서 @ts-check, allowJs, 모듈별 전환, noImplicitAny로 이어지는 마이그레이션 단계 다이어그램
Study26. 07. 09.

이펙티브 타입스크립트 2판 Day 14: JS에서 TS로 옮길.

Item 79–83 범위를 바탕으로 JS 현대화, @ts-check와 JSDoc, allowJs, 모듈별 마이그레이션, noImplicitAny를 코드 리뷰 관점에서 정리합니다.

26. 07. 09.SEOJing
ESM live binding과 dynamic import, circular dependency 리뷰 포인트를 보여주는 module graph 다이어그램
Study26. 07. 09.

자바스크립트 퀴즈북 리마인드 Day 13: 모듈은 파일 묶음이.

ESM live binding, default/named export, circular dependency, dynamic import, CJS와 ESM 차이를 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 07. 09.SEOJing
내부 구현 타입에서 문서화된 public API 타입으로 넘어가는 경계 다이어그램
Study26. 07. 08.

이펙티브 타입스크립트 2판 Day 12: 타입은 공개 API의.

Item 67–73 범위를 바탕으로 public API 타입, TSDoc, this callback, module augmentation, TypeScript 기능 선택, source map을 코드 리뷰 관점에서 정리합니다.

26. 07. 08.SEOJing
DOM 이벤트가 capture 단계로 내려가고 bubble 단계로 올라가는 경로 다이어그램
Study26. 07. 08.

자바스크립트 퀴즈북 리마인드 Day 12: 이벤트는.

DOM 이벤트의 capture/bubble, delegation, default action, React synthetic event 경계를 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 07. 08.SEOJing
Object iteration, Record, tuple/rest, XOR, brand, @types 버전 관리를 연결한 타입 리뷰 다이어그램
Study26. 07. 07.

이펙티브 타입스크립트 2판 Day 11: 객체 타입은 열려.

Item 60–66 범위를 바탕으로 Object iteration, Record, tuple/rest, XOR, brand, @types 버전 경계를 코드 리뷰에서 다루는 방법을 정리합니다.

26. 07. 07.SEOJing
인스턴스에서 프로토타입과 Object.prototype으로 이어지는 프로퍼티 조회 경로 다이어그램
Study26. 07. 07.

자바스크립트 퀴즈북 리마인드 Day 11: class를 봐도.

프로토타입 조회, class 문법, 인스턴스 필드와 prototype 메서드 차이를 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 07. 07.SEOJing
타입 계약, 타입 테스트, never exhaustiveness, 코드 생성 경계를 보여주는 다이어그램
Study26. 07. 06.

이펙티브 타입스크립트 2판 Day 10: 타입도 테스트하고.

Item 55–59 범위를 바탕으로 type test, 타입 표시, 꼬리 재귀 한계, 코드 생성, never exhaustiveness를 코드 리뷰에서 다루는 방법을 정리합니다.

26. 07. 06.SEOJing
입력, 순수 계산, 출력, 부수 효과 경계를 나누어 함수 설계를 보여주는 다이어그램
Study26. 07. 06.

자바스크립트 퀴즈북 리마인드 Day 10: 함수는 값이고 경계다.

고차 함수, 순수 함수, 부수 효과, async 함수의 Promise 반환을 코드 리뷰에서 어떻게 읽을지 정리합니다.

26. 07. 06.SEOJing
외부 경계, 제네릭, 조건부 타입, 템플릿 리터럴 타입의 역할과 과한 타입 계산의 위험을 보여주는 다이어그램
Study26. 07. 05.

이펙티브 타입스크립트 2판 Day 9: 제네릭은 관계를 보존할.

Item 49–54 범위를 바탕으로 type coverage, 제네릭, 조건부 타입, 템플릿 리터럴 타입을 코드 리뷰에서 어떻게 판단할지 정리합니다.

26. 07. 05.SEOJing
메서드 호출, 분리된 함수, 이벤트 콜백, bind와 arrow function의 this 차이를 보여주는 다이어그램
Study26. 07. 05.

자바스크립트 퀴즈북 리마인드 Day 9: this는 호출한 쪽이.

this 바인딩을 정의 위치가 아니라 호출 형태, 메서드 분리, arrow function, bind 기준으로 읽는 방법을 코드 리뷰 관점에서 정리합니다.

26. 07. 05.SEOJing
외부 JSON을 unknown으로 받고 검증 뒤 도메인 타입으로 넘기는 경계와 any가 내부로 번지는 위험을 보여주는 다이어그램
Study26. 07. 04.

이펙티브 타입스크립트 2판 Day 8: any를 밖에 세우고.

Item 42–48 범위를 바탕으로 any, unknown, 타입 단언, monkey patching, soundness 함정을 외부 입력 경계와 코드 리뷰 관점에서 정리합니다.

26. 07. 04.SEOJing
콜 스택이 비워진 뒤 마이크로태스크 큐가 먼저 실행되고 다음 태스크로 넘어가는 이벤트 루프 다이어그램
Study26. 07. 04.

자바스크립트 퀴즈북 리마인드 Day 8: 이벤트 루프와.

콜 스택, 태스크 큐, 마이크로태스크 큐를 기준으로 Promise와 setTimeout 실행 순서를 코드 리뷰 관점에서 정리합니다.

26. 07. 04.SEOJing
넓은 문자열과 선택적 필드를 도메인 이름과 유효 상태 유니온으로 좁히는 다이어그램
Study26. 06. 29.

이펙티브 타입스크립트 2판 Day 7: 문자열보다 도메인.

Item 35–41 범위를 바탕으로 string 남용, optional 필드, 특수 값, 도메인 이름 설계를 코드 리뷰 관점에서 정리합니다.

26. 06. 29.SEOJing
클로저가 생성 위치의 바인딩을 기억해 나중 실행에서 오래된 값을 읽을 수 있음을 보여주는 다이어그램
Study26. 06. 29.

자바스크립트 퀴즈북 리마인드 Day 7: 클로저 버그와 오래된.

클로저가 값 복사가 아니라 렉시컬 환경 참조라는 점을 stale closure, 루프 콜백, React 이벤트 리뷰 관점에서 정리합니다.

26. 06. 29.SEOJing
API 응답을 유효한 상태 유니온으로 변환하는 흐름 다이어그램
Study26. 06. 28.

이펙티브 타입스크립트 2판 Day 6: 유효한 상태만 표현하는.

Item 28–34 범위를 바탕으로 추론 위치, 유효 상태 모델링, API 입출력, null 경계, union 설계를 프론트엔드 코드 리뷰 관점에서 확장 정리합니다.

26. 06. 28.SEOJing
스코프 체인과 호이스팅 관계를 단순화한 다이어그램
Study26. 06. 28.

자바스크립트 퀴즈북 리마인드 Day 6: 스코프 체인과 호이스팅.

스코프 체인, 렉시컬 환경, var/let/const 호이스팅 차이를 콜백·상태 버그 리뷰 관점에서 다시 정리합니다.

26. 06. 28.SEOJing
타입스크립트 추론이 값에서 API 경계로 흐르는 과정을 보여주는 다이어그램
Study26. 06. 27.

이펙티브 타입스크립트 2판 Day 5: 좁혀진 타입은 언제.

Item 22–27 범위를 바탕으로 narrowing, alias, context inference, evolving type, async/type flow를 프론트엔드 코드 리뷰 관점에서 다시 정리합니다.

26. 06. 27.SEOJing
JavaScript 객체 참조와 Map, Set, WeakMap의 참조 구조를 비교한 다이어그램
Study26. 06. 27.

자바스크립트 퀴즈북 리마인드 Day 5: 참조, 복사,.

객체 참조와 얕은 복사, Object와 Map/Set의 차이, WeakMap/WeakSet이 필요한 메모리 상황을 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 06. 27.SEOJing
TypeScript에서 넓은 타입으로 먼저 담으면 key와 literal 정보가 사라지고 리뷰 체크가 약해지는 흐름 다이어그램
Study26. 06. 26.

이펙티브 타입스크립트 2판 Day 4: 추론을 살리는 값 생성.

Effective TypeScript 2판의 Item 16–21을 바탕으로 index signature, 타입 추론 기본, 변수/객체 생성 패턴을 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 06. 26.SEOJing
JavaScript 프로퍼티 descriptor가 data descriptor와 accessor descriptor로 갈라지는 구조 다이어그램
Study26. 06. 26.

자바스크립트 퀴즈북 리마인드 Day 4: 프로퍼티.

객체 프로퍼티를 key/value가 아니라 descriptor로 읽는 법, getter/setter와 defineProperty, preventExtensions/seal/freeze의 경계를 코드 리뷰 관점에서 정리합니다.

26. 06. 26.SEOJing
반복된 타입 선언을 원본 타입에서 파생한 타입으로 바꿔 리뷰 체크를 강하게 만드는 흐름 다이어그램
Study26. 06. 25.

이펙티브 타입스크립트 2판 Day 3: 타입 반복을 줄이는 리뷰.

Effective TypeScript 2판의 Item 11–15를 바탕으로 excess property check, 함수식 타입, type vs interface, readonly, 타입 반복 제거를 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 06. 25.SEOJing
객체가 ToPrimitive를 거쳐 + 연산자의 문자열 연결 또는 숫자 덧셈으로 갈라지는 흐름 다이어그램
Study26. 06. 25.

자바스크립트 퀴즈북 리마인드 Day 3: + 연산자와.

객체가 원시값으로 바뀌는 ToPrimitive 흐름, + 연산자의 문자열 연결과 숫자 덧셈 분기, Symbol.toPrimitive가 코드 리뷰에서 왜 중요한지 정리합니다.

26. 06. 25.SEOJing
TypeScript 타입을 값의 집합, type space, value space, assertion 경계로 정리한 다이어그램
Study26. 06. 24.

이펙티브 타입스크립트 2판 Day 2: 타입을 값의 집합으로.

Effective TypeScript 2판의 Item 6–10을 바탕으로 타입 시스템을 탐색하는 법, 타입을 값의 집합으로 보는 관점, type/value space, 타입 단언의 경계를 코드 리뷰 관점에서 정리합니다.

26. 06. 24.SEOJing
==, ===, Object.is, SameValueZero의 차이를 정리한 JavaScript equality 다이어그램
Study26. 06. 24.

자바스크립트 퀴즈북 리마인드 Day 2: 같은 값인지 묻는 네.

==, ===, Object.is, SameValueZero가 각각 어떤 비교 알고리즘을 쓰는지 정리하고, includes와 indexOf, Map/Set 키 비교에서 생기는 프론트엔드 리뷰 포인트를 잡습니다.

26. 06. 24.SEOJing
Study26. 06. 23.

에이전트 프레임워크 스터디 Day 13: Trace는 로그가.

에이전트 시스템에서 trace를 콘솔 로그나 비용 기록으로만 보면 왜 부족한지, 사용자 요청부터 도구 호출, 산출물, 검증, 다음 실행 개선까지 이어지는 증거 사슬로 어떻게 설계해야 하는지 reverse-engineering합니다.

26. 06. 23.SEOJing
TypeScript를 JavaScript 위의 정적 타입 계층, 타입 제거, 구조적 타이핑, any의 구멍으로 정리한 다이어그램
Study26. 06. 23.

이펙티브 타입스크립트 2판 Day 1: 타입스크립트를 믿기.

Effective TypeScript 2판의 Item 1–5를 바탕으로 TypeScript와 JavaScript의 관계, tsconfig, 타입 제거, 구조적 타이핑, any의 위험을 프론트엔드 코드 리뷰 관점에서 정리합니다.

26. 06. 23.SEOJing
JavaScript Number, safe integer, NaN, -0, BigInt를 한 장으로 정리한 다이어그램
Study26. 06. 23.

자바스크립트 퀴즈북 리마인드 Day 1: 숫자는 왜 가끔 믿을.

자바스크립트의 Number가 왜 정수처럼 보여도 부동소수점 모델 위에서 움직이는지, NaN과 -0, safe integer, BigInt를 프론트엔드 코드 리뷰 관점에서 다시 정리합니다.

26. 06. 23.SEOJing
Study26. 06. 22.

에이전트 프레임워크 스터디 Day 12: Agent Card는.

에이전트가 서로 협업하려면 "무엇을 잘한다"는 소개가 아니라 능력, 입력, 산출물, 권한, 실패 모드, 사람 개입 조건을 적은 실행 가능한 경계선이 필요하다는 점을 reverse-engineering합니다.

26. 06. 22.SEOJing
에이전트 프레임워크 스터디 Day 11: MCP 서버는 설치 목록이 아니라 검문 가능한 계약이다 글의 리소그래프 스타일 대표 이미지 배경
Study26. 06. 21.

에이전트 프레임워크 스터디 Day 11: MCP 서버는 설치.

MCP 서버를 많이 붙이는 문제가 아니라, 에이전트가 외부 능력을 쓰기 전에 도구 목록, 입력 스키마, 권한, 샘플 호출, 실패 모드를 검문 가능한 계약으로 다루는 법을 reverse-engineering합니다.

26. 06. 21.SEOJing
에이전트 프레임워크 스터디 Day 10: harness는 팀 아키텍처를 만드는 공장이다 글의 리소그래프 스타일 대표 이미지 배경
Study26. 06. 20.

에이전트 프레임워크 스터디 Day 10: harness는 팀.

harness를 단순 테스트 환경이나 공유 프롬프트가 아니라 모델, 컨텍스트, 도구, 권한, 작업 원장, 검증, 피드백을 묶어 전문 작업 단위를 찍어내는 팀 아키텍처 공장으로 reverse-engineering합니다.

26. 06. 20.SEOJing
에이전트 프레임워크 스터디 Day 9: 확장점은 플러그인이 아니라 경계면이다 글의 리소그래프 스타일 대표 이미지 배경
Study26. 06. 19.

에이전트 프레임워크 스터디 Day 9: 확장점은 플러그인이.

에이전트 프레임워크를 직접 설계하거나 고칠 때 확장점을 단순 플러그인 기능이 아니라 책임과 권한이 갈리는 경계면으로 보는 법을 reverse-engineering합니다. 모델, 도구, 기억, 세션, 게이트웨이, 스케줄러, 리뷰 게이트가 어디에서 갈라져야 안전한지 봅니다.

26. 06. 19.SEOJing
Study26. 06. 18.

에이전트 프레임워크 스터디 Day 8: 여러 에이전트는 역할이.

여러 에이전트나 프로필을 붙일 때 사람 역할놀이가 아니라 capability, task, artifact, handoff contract로 연결해야 하는 이유를 reverse-engineering합니다. A2A식 사고와 OkayJing hub-spoke 운영을 바탕으로 안전한 협업 경계를 봅니다.

26. 06. 18.SEOJing
Study26. 06. 17.

에이전트 프레임워크 스터디 Day 7: 작업은 답변이 아니라.

에이전트 실행을 단순한 채팅 답변이 아니라 이벤트, 산출물, 검증, 상태 전이의 흐름으로 설계하는 법을 reverse-engineering합니다. 티켓, 세션, 파일, 로그, 아티팩트가 왜 프레임워크의 중심이 되는지 봅니다.

26. 06. 17.SEOJing
Study26. 06. 16.

에이전트 프레임워크 스터디 Day 6: 사람 개입은 예외가.

에이전트 프레임워크에서 사람 개입, 승인, 거절, 확인 질문을 예외 처리로 두지 않고 실행 표면으로 설계하는 법을 봅니다. 위험도 기반 autonomy ladder, interrupt, approval gate, 검증 보고를 reverse-engineering합니다.

26. 06. 16.SEOJing
Study26. 06. 15.

에이전트 프레임워크 스터디 Day 5: 워크플로와 에이전트의.

에이전트 프레임워크에서 반복 가능한 워크플로와 열린 에이전트 판단을 어떻게 분리해야 하는지 봅니다. 모든 것을 자율 에이전트로 만들지 않고, 상태·도구·검증·사람 개입 지점을 나누는 설계 기준을 reverse-engineering합니다.

26. 06. 15.SEOJing
Study26. 06. 14.

에이전트 프레임워크 스터디 Day 4: 관측 가능해야.

에이전트 프레임워크에서 로그, trace, 평가, 재현 가능한 증거를 어떻게 설계해야 하는지 봅니다. 단순한 채팅 기록이 아니라 실행을 다시 읽고 고칠 수 있는 관측 가능성 계층을 reverse-engineering합니다.

26. 06. 14.SEOJing
Study26. 06. 13.

에이전트 프레임워크 스터디 Day 3: 컨텍스트는 자료 더미가.

에이전트 프레임워크에서 컨텍스트를 긴 프롬프트나 자료 모음이 아니라 실행 상태로 설계하는 법을 봅니다. 세션 기록, 작업 상태, 장기 기억, 검색 결과, 산출물, 검증 근거를 분리하고 조립하는 기준을 reverse-engineering합니다.

26. 06. 13.SEOJing
Study26. 06. 12.

에이전트 프레임워크 스터디 Day 2: 도구는 함수가 아니라.

에이전트가 도구를 쓴다는 말을 함수 호출이 아니라 계약 설계로 다시 봅니다. MCP식 tool contract, 입력 스키마, 권한, 결과 해석, 실패 처리, 검증 책임을 기준으로 개인 에이전트 프레임워크의 도구 런타임을 설계합니다.

26. 06. 12.SEOJing
Study26. 06. 12.

백엔드 스터디 Day 12: 프론트엔드 개발자를 위한 협업.

백엔드 스터디 마지막 날입니다. Spring Boot 세부 문법을 외우는 대신 프론트엔드 개발자가 백엔드와 안전하게 협업하기 위해 알아야 할 요청 흐름, API 계약, 데이터, 인증, 테스트, 운영 대화법을 하나의 지도로 정리합니다.

26. 06. 12.SEOJing
Study26. 06. 11.

에이전트 프레임워크 스터디 Day 1: 프레임워크보다 먼저.

개인에게 맞는 에이전트 프레임워크를 만들기 전에 먼저 에이전트가 실제로 실행되는 환경을 분해합니다. 모델, 컨텍스트, 도구, 권한, 검증, 로그가 합쳐진 harness를 기준으로 현재 도구들의 한계와 확장 지점을 읽는 첫 번째 글입니다.

26. 06. 11.SEOJing
Study26. 06. 11.

백엔드 스터디 Day 11: AI가 만든 백엔드 코드를 리뷰하는.

Day 1부터 Day 10까지 배운 백엔드 읽기 기준을 하나의 리뷰 체크리스트로 묶습니다. AI가 만든 Spring Boot 백엔드를 기능 단위가 아니라 요청 흐름, 계약, DB, 보안, 테스트, 운영 가능성 기준으로 검토하는 방법을 정리합니다.

26. 06. 11.SEOJing
Study26. 06. 10.

백엔드 스터디 Day 10: 로그와 관측 가능성으로 문제 흐름.

AI가 만든 Spring Boot 백엔드를 운영 가능한 코드로 보려면 기능 구현뿐 아니라 문제가 났을 때 어디서 막혔는지 추적할 수 있어야 합니다. Day 10에서는 로그, 요청 ID, 에러 추적, 메트릭, 알림을 낮은 단계부터 읽는 법을 정리합니다.

26. 06. 10.SEOJing
Study26. 06. 09.

백엔드 스터디 Day 9: API 문서와 팀 협업 흐름 읽기.

AI가 만든 Spring Boot 백엔드가 실제 팀 작업에 들어갈 수 있는지 보려면 코드만이 아니라 API 문서, README, 변경 이력, 프론트엔드와의 계약 흐름을 읽을 수 있어야 합니다. Day 9에서는 Swagger/OpenAPI, README, 예시 요청, 에러 표, 협업 리뷰 기준을 낮은 단계부터 정리합니다.

26. 06. 09.SEOJing
Study26. 06. 08.

백엔드 스터디 Day 8: 배포와 운영 환경 읽기.

AI가 만든 Spring Boot 백엔드가 로컬에서만 돌아가는 코드인지, 실제 서버에서 안전하게 운영될 수 있는 코드인지 판단하려면 배포 구조와 운영 환경을 읽을 수 있어야 합니다. Day 8에서는 Docker, 환경 변수, 프로필, 로그, 헬스체크, CI/CD를 낮은 단계부터 봅니다.

26. 06. 08.SEOJing
Study26. 06. 08.

프론트엔드 스터디 11주차: React 기초 2 —.

useEffect로 사이드 이펙트를 다루고, 이벤트 처리와 폼 상태 관리까지 — React로 실제 동작하는 앱을 만들기 위한 핵심 기술을 배웁니다.

26. 06. 08.SEOJing
Study26. 06. 08.

프론트엔드 스터디 심화: 에러 처리와 정규 표현식.

지금 당장 읽지 않아도 됩니다. React를 배우면서 에러 처리가 필요해지거나 면접 대비가 필요할 때 참고하세요.

26. 06. 08.SEOJing
Study26. 06. 07.

백엔드 스터디 Day 7: 테스트 코드로 AI 백엔드 검증하기.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 테스트는 기능이 실제로 지켜지는지 확인하는 가장 안전한 증거입니다. Day 7에서는 테스트 문법을 외우기보다 Controller, Service, Repository 테스트가 무엇을 보장하는지 읽는 법을 낮은 단계부터 익힙니다.

26. 06. 07.SEOJing
Study26. 06. 06.

백엔드 스터디 Day 6: 로그인과 권한 흐름을 코드에서 읽기.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 로그인, 인증, 인가, 토큰, 현재 사용자 흐름은 기능 안전성을 결정합니다. Day 6에서는 auth 코드를 외우는 대신 요청이 누구의 요청인지 확인하고 권한을 적용하는 흐름을 낮은 단계부터 읽습니다.

26. 06. 06.SEOJing
Study26. 06. 05.

백엔드 스터디 Day 5: Service와 트랜잭션으로 비즈니스.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 Service 계층은 Controller, Repository, Entity를 연결하는 핵심 판단 지점입니다. Day 5에서는 Service 메서드, 비즈니스 규칙, 트랜잭션, 읽기/쓰기 경계, 위험 신호를 낮은 단계부터 읽는 법을 다룹니다.

26. 06. 05.SEOJing
Study26. 06. 03.

백엔드 스터디 Day 4: Entity와 Repository로.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 DB 저장 흐름은 가장 자주 위험해지는 지점입니다. Day 4에서는 Entity, Repository, JPA, ID, 관계, 조회/저장 메서드를 낮은 단계부터 읽고 프론트엔드 기능과 연결해 점검하는 방법을 다룹니다.

26. 06. 03.SEOJing
Study26. 06. 02.

백엔드 스터디 Day 3: 검증과 에러 응답을 읽는 법.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 입력 검증과 에러 응답은 사용자의 화면 경험을 직접 바꾸는 핵심 지점입니다. Day 3에서는 @Valid, 검증 어노테이션, BindingResult, 전역 예외 처리, 에러 응답 DTO를 낮은 단계부터 읽는 법을 다룹니다.

26. 06. 02.SEOJing
Study26. 06. 01.

백엔드 스터디 Day 2: API 계약과 DTO를 읽는 법.

AI가 만든 Spring Boot 백엔드 코드를 검토할 때 가장 먼저 맞춰야 하는 것은 문법 암기가 아니라 프론트엔드와 백엔드 사이의 API 계약입니다. Day 2에서는 URL, HTTP Method, 요청 바디, 응답 바디, DTO, 검증 어노테이션, 에러 응답을 낮은 단계부터 읽습니다.

26. 06. 01.SEOJing
Study26. 06. 01.

프론트엔드 스터디 10주차: React 기초 1 — 컴포넌트,.

React를 처음 시작합니다. 컴포넌트, JSX, props, useState까지 — React 앱을 만들기 위한 핵심 네 가지를 한 번에 배웁니다.

26. 06. 01.SEOJing
Study26. 06. 01.

프론트엔드 스터디 심화: this, 실행 컨텍스트, 이터러블.

React를 배우면서 this가 헷갈리거나, 면접 대비가 필요할 때 참고하는 JS 심화 자료입니다. 이 내용을 지금 당장 완벽히 이해하지 않아도 React를 배우는 데 지장이 없습니다.

26. 06. 01.SEOJing
Study26. 05. 31.

백엔드 스터디 Day 1: 스프링 프로젝트를 읽기 위한 최소 지도.

직접 백엔드 코드를 다 작성하는 사람이 아니라, AI가 만든 Spring Boot 코드를 이해하고 수정 방향을 판단할 수 있는 사람을 목표로 시작합니다. Day 1에서는 서버가 하는 일, HTTP 요청의 흐름, 스프링 프로젝트 폴더 구조, Controller-Service-Repository의 역할을 아주 낮은 단계부터 잡습니다.

26. 05. 31.SEOJing
Study26. 05. 25.

프론트엔드 스터디 대면 9주차: Next.js 렌더링 진화와 웹.

Next.js가 무엇이고 왜 필요한지 React와 비교해 이해한 뒤, CSR부터 SSR, SSG, ISR, PPR까지 렌더링 전략과 Web Vitals를 정리하며 스터디를 마무리합니다.

26. 05. 25.SEOJing
Study26. 05. 25.

프론트엔드 스터디 9주차: React 입문 전 필수 JS.

다음 주부터 React를 시작합니다. React 코드에서 매 줄 등장하는 map/filter, 구조 분해, 스프레드, 옵셔널 체이닝, 모듈까지 — React 코드를 막힘없이 읽기 위한 JS 문법을 한 번에 정리합니다.

26. 05. 25.SEOJing
Study26. 05. 18.

프론트엔드 스터디 대면 8주차: API와 통신 — 프론트엔드와.

비동기와 async/await를 배운 뒤, 대면에서는 API를 단순 호출 방법이 아니라 프론트엔드와 백엔드 사이의 계약으로 바라봅니다. HTTP, REST, CORS, 프록시, API 클라이언트 구조, TanStack Query와 파일 배치까지 연결합니다.

26. 05. 18.SEOJing
Study26. 05. 18.

프론트엔드 스터디 8주차: 클로저, Promise,.

JS 비동기 처리의 흐름을 배웁니다. 클로저가 왜 중요한지, 콜백 지옥을 해결한 Promise, 그리고 현대 JS의 표준인 async/await까지 이어지는 흐름을 이해합니다.

26. 05. 18.SEOJing
Study26. 05. 11.

프론트엔드 스터디 대면 7주차: React 입문과 프로젝트 구조.

바닐라 JS의 한계에서 React가 등장한 이유까지, 컴포넌트와 렌더링 방식을 이해하고 프로젝트 구조 감각을 만들어가는 대면입니다.

26. 05. 11.SEOJing
Study26. 05. 11.

프론트엔드 스터디 7주차: 불변성, 프로토타입, 타입 체크.

JS에서 가장 낯선 개념 중 하나인 프로토타입 기반 상속을 다룹니다. const가 왜 불변을 보장하지 않는지, 타입을 런타임에 정확히 확인하는 방법까지 함께 배웁니다.

26. 05. 11.SEOJing
Study26. 05. 05.

프론트엔드 스터디 6주차: 객체, 함수, 그리고 스코프.

JavaScript에서 거의 모든 것은 객체입니다. 함수가 일급 객체라는 의미, var와 let의 스코프 차이, 그리고 렉시컬 스코프까지 다룹니다.

26. 05. 05.SEOJing
Study26. 05. 04.

프론트엔드 스터디 대면 6주차(1): HTML/CSS/JS.

4~6주차 공백 이후 진행하는 첫 번째 대면입니다. HTML/CSS/JS 핵심을 가볍게 다시 연결하고, 브라우저가 코드를 실제 화면으로 바꾸는 과정을 통해 렌더링 파이프라인과 성능 감각을 잡습니다.

26. 05. 04.SEOJing
Study26. 05. 04.

프론트엔드 스터디 대면 6주차(2): AI 시대의 개발 방식과.

길어진 6주차 대면의 두 번째 차시입니다. AI 시대에 개발자가 실제로 어떻게 일하는지, 그리고 프론트엔드 개발자가 디자이너·백엔드·PM 사이에서 어떤 연결과 리딩 역할을 하는지 다룹니다.

26. 05. 04.SEOJing
Study26. 04. 28.

프론트엔드 스터디 5주차: JavaScript.

JavaScript를 처음 제대로 배우는 주차입니다. var/let/const의 차이, JS만의 독특한 타입 시스템, 그리고 호이스팅·TDZ까지 다룹니다.

26. 04. 28.SEOJing
Study26. 04. 13.

프론트엔드 스터디 4주차: 자유자재 레이아웃 (포지션과.

배경 이미지를 제어하고, Position으로 요소를 원하는 위치에 배치하며, Flexbox로 유연한 가로·세로 레이아웃을 구성합니다. 요소를 화면 정중앙에 띄우거나, 내비게이션 바처럼 가로로 예쁘게 정렬하는 것이 이번 주 목표입니다.

26. 04. 13.SEOJing
Study26. 04. 10.

프론트엔드 스터디 대면 3주차: 박스 모델 실전,.

3주차 박스 모델과 스타일링 복습, 과제 풀이, 4주차 Position과 Flexbox 레이아웃까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 마진 겹침, box-sizing, Flexbox 관련 질문도 함께 준비합니다.

26. 04. 10.SEOJing
Study26. 04. 06.

프론트엔드 스터디 3주차: 프론트엔드의 첫 번째 벽, 박스.

폰트와 색상을 다루고, 인라인과 블록 요소의 차이를 이해하며, 마진·패딩으로 구성되는 박스 모델을 완벽하게 익힙니다. 요소들 사이의 여백을 자유자재로 제어하고 화면이 찌그러지지 않게 박스 크기를 다루는 것이 이번 주 목표입니다.

26. 04. 06.SEOJing
Study26. 04. 03.

프론트엔드 스터디 대면 2주차: 폼(Form), CSS.

2주차 폼과 CSS 선택자 복습, 과제 풀이, 3주차 박스 모델과 스타일링까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 GET vs POST, CSS 우선순위, 박스 모델 관련 질문도 함께 준비합니다.

26. 04. 03.SEOJing
Study26. 03. 30.

프론트엔드 스터디 2주차: 사용자와 소통하는 폼 &.

사용자 입력을 받는 폼(Form)을 만들고, CSS를 HTML에 연결하는 방법과 원하는 요소를 정확히 선택하는 CSS 선택자 규칙을 배웁니다. 로그인·회원가입 폼을 직접 만들고, CSS로 원하는 요소를 콕 집어내는 것이 이번 주 목표입니다.

26. 03. 30.SEOJing
Study26. 03. 27.

프론트엔드 스터디 대면 1주차: HTML 마크업과 폼, 그리고.

1주차 HTML 핵심 복습과 과제 풀이, 2주차 폼(Form)과 CSS 선택자까지 다룬 대면 스터디 정리입니다. 면접에서 자주 나오는 시맨틱 HTML, img alt 속성 관련 질문도 함께 준비합니다.

26. 03. 27.SEOJing
Study26. 03. 23.

프론트엔드 스터디 1주차: 마크업 그 이상, 실무를 위한.

기초 태그 강의에서 한 걸음 더 나아갑니다. 카카오톡 공유 썸네일, 모바일 데이터 절약, 스크린 리더기를 위한 숨은 정보 등 실무에서 마주하게 될 중급 HTML 개념들을 가볍게 훑어봅니다.

26. 03. 23.SEOJing
Study26. 03. 20.

프론트엔드 스터디 대면 0주차: 프론트엔드 개발자란? 그리고.

프론트엔드 개발자가 실무에서 하는 일, 2025-2026 기술 스택, 현실적인 연봉과 채용 트렌드를 정리했습니다. 스터디 자료 구조와 앞으로의 방향도 함께 안내합니다.

26. 03. 20.SEOJing
Study26. 03. 19.

사전 진단 퀴즈 3단계 (변수와 DOM).

스터디 커리큘럼 방향을 정하기 위한 세 번째 사전 진단 퀴즈입니다. 자바스크립트의 스코프, 참조 타입의 메모리 할당, DOM 제어와 이벤트 흐름 등 React 실무의 근간이 되는 CS 지식을 점검합니다.

26. 03. 19.SEOJing
Study26. 03. 19.

사전 진단 퀴즈 4단계 (배열, 함수, 비동기).

스터디 커리큘럼 방향을 정하기 위한 마지막 사전 진단 퀴즈입니다. React 컴포넌트를 다루기 위해 필수적인 배열 고차 함수(map, filter)와 비동기 통신(async/await) 능력을 점검합니다.

26. 03. 19.SEOJing
Study26. 03. 19.

사전 진단 퀴즈 5단계 (선언적 UI와 상태).

스터디 커리큘럼 방향을 정하기 위한 마지막 사전 진단 퀴즈입니다. 선언적 UI, 상태(State), 단방향 데이터 흐름, 부수 효과(Side Effect) 등 React 생태계 진입을 위한 필수 개념을 점검합니다.

26. 03. 19.SEOJing
Study26. 03. 18.

사전 진단 퀴즈 1단계 (HTML/CSS).

스터디 커리큘럼 방향을 정하기 위한 첫 번째 사전 진단 퀴즈입니다. HTML 태그 구조부터 CSS 박스 모델까지, 실무와 React 환경에서 이 기초들이 왜 중요한지 점검합니다.

26. 03. 18.SEOJing
Study26. 03. 18.

사전 진단 퀴즈 2단계 (HTML/CSS 활용).

스터디 커리큘럼 방향을 정하기 위한 두 번째 사전 진단 퀴즈입니다. 시맨틱 마크업, 폼 이벤트 제어, CSS 우선순위, Flexbox 레이아웃 등 실전 활용 능력을 점검합니다.

26. 03. 18.SEOJing