타입스크립트는 왜 컴파일 레벨에서 강제하지 않을까?이펙티브 타입스크립트를 읽다가 문득 궁금했다.“왜 타입스크립트는 자바나 C#처럼 컴파일 레벨에서 타입을 완전히 강제하지 않을까?”이 질문의 답을 찾다 보니, 단순한 기술적 이유가 아니라 웹이라는 플랫폼의 철학과 자바스크립트의 역사적 맥락이 깊게 얽혀 있었다.1. 웹 브라우저 환경의 철학: “부분적 실패를 견딘다”자바스크립트를 해본 사람이라면 알겠지만, 자바스크립트는 그 어떤 실수에도 관대하다.undefined를 덧셈해도 죽지 않고, 엉뚱한 타입을 넘겨도 그냥 실행된다.이런 유연함(혹은 관대함) 은 단순한 결함이 아니라, 웹 환경의 생존 전략이었다.웹의 기본 철학은 “부분적 실패를 견딘다(Tolerate partial failure)”이다.이미지 하나가 깨..
개요회사에서 NestJS 기술을 활용하면서 Guard라는 기능을 접했을 때, 추상적으로 'Spring Security와 비슷하구나'라는 생각으로만 접근했습니다. 하지만 실제 동작 원리와 인가된 유저 주입 메커니즘을 깊이 이해하지 못한 채, AI가 생성한 코드를 검증 없이 사용하다가 기존 인증/인가 로직에 예기치 않은 영향을 주는 문제를 발생시켰습니다. 이로 인해 팀원들에게 불편을 끼치는 상황이 발생했고, 이는 근본적인 이해 부족에서 비롯된 것임을 깨달았습니다. 같은 실수를 반복하지 않기 위해, 그리고 Guard를 제대로 이해하기 위해 이 글을 작성합니다. 이 글을 읽으면 좋은 사람들Spring 백그라운드를 가진 개발자가 NestJS로 전환하는 경우두 프레임워크를 함께 사용하는 팀에서 일하는 개발자인증/인..
시작하게 된 계기 이전에도 웹을 어느정도 개발 해왔기 때문에 jquery와 thymeleaf와 같은 도구를 활용하여 쉽게 개발을 해왔었지만 리액트나 vue와 같은 프론트 기술스택을 활용을 해야될 때에는 만들어진 프로젝트 위에 하드 코딩을 하거나 프론트 개발자를 구해 개발을 했어야 했다. 그래서 내 마음 한켠에서는 항상 불편함이 자리 잡고 있었고. 프론트 개발을 제대로 하지 못한다는 자책감을 가지게 되었다. 그리고 시시각각 변하는 프론트엔드의 시장에서의 나는 점점 프론트엔드 개발자들과의 소통이 더욱 어려워지기 시작했고 요구사항에 맞춰 소프트웨어를 함께 설계하고 개발해 나가는 과정 속에서 지속적인 커뮤니케이션의 어려움을 느끼며 큰 부담으로 다가오게 되었다. 그렇게 그런 생각이 희미해져 갈 때 쯤 회사에서 갑..
자바스크립트 기반의 프로젝트를 진행하면서 String, number, boolean, undefinded, null 등의 값과는 다른 Symbol이라는 타입도 있다는 것을 알게되었습니다. 심볼은 다른 타입과 달리 독특하게 동작하기 때문에 그와 관련해서 정리를 하기 위한 글입니다. 심볼이란? 문서에서는 아래와 같이 정의를 하고 있습니다. Symbol() 함수는 심볼(symbol) 형식의 값을 반환하는데, 이 심볼은 내장 객체(built-in objects)의 여러 멤버를 가리키는 정적 프로퍼티와 전역 심볼 레지스트리(global symbol registry)를 가리키는 정적 메서드를 가지며, "new Symbol()" 문법을 지원하지 않기 때문에 생성자 어떤 면에서는 불완전한 내장 객체 클래스(built-..