인프런 커뮤니티 질문&답변
작성한 질문수
readFileSync
해결된 질문
작성
·
54
0
readFileSync 메서드는 동기적인 메서드라 이벤트 루프에서 막혀서 파일을 읽어오는동안 스레드를 멈춰서 실무에선 잘 사용 안 하지 않나요?
단순히 서버의 흐름 이해를 돕기위한 코드 정도로 이해해도 될까요?
혹시 이 강의는 express와 서버의 개념만 이해하고 넘어가는 정도의 강의일까요?
실무적인 관점의 강의는 파트 2라고 보면 될까요
아님 파트1 파트2 모두 실무적인 관점의 코드는 작성하지 않고 넘어가나요?
답변 1
0
안녕하세요 코딩님!
학습에 대한 열정이 느껴지는 질문을 주셔서 정말 감사합니다. 질문하신 내용은 Node.js의 핵심 철학인 비동기 처리를 아주 정확하게 관통하고 있으며, 강의의 구성 의도에 대한 분석 또한 매우 타당합니다.
질문하신 내용을 면밀히 살펴보면 readFileSync 메서드에 대한 우려는 기술적으로 매우 정확한 지적입니다. 이 메서드는 이름 그대로 파일을 읽어오는 작업을 수행하는 동안 다음 코드로 넘어가지 않고 전체 실행 흐름을 멈춰 세우는 동기 방식으로 동작합니다. Node.js는 기본적으로 한 번에 하나의 작업만 처리할 수 있는 싱글 스레드 기반의 이벤트 루프 모델을 사용하기 때문에, 이 루프가 멈춘다는 것은 다른 사용자의 접속이나 데이터 요청을 전혀 처리할 수 없는 상태가 됨을 의미합니다. 이는 마치 좁은 단선 도로에서 앞차가 통과하기 전까지 뒤에 있는 수많은 차가 하염없이 기다려야 하는 상황과 같아서, 실제 서비스 환경의 비즈니스 로직에서는 매우 치명적인 코드가 될 수 있습니다.
이러한 맥락에서 파트 1 과정은 말씀하신 대로 실무 전체를 대변하기보다는 Express 프레임워크와 서버의 기본적인 구조를 잡는 단계로 이해하시면 좋습니다. 이 단계에서 readFileSync를 활용하는 이유는 비동기 처리라는 다소 복잡한 개념을 배우기 전에 서버가 어떻게 요청을 받고 응답을 보내는지 그 직관적인 흐름을 먼저 익히기 위해서입니다. 이것은 마치 운전을 처음 배울 때 엔진의 내부 복잡한 작동 원리보다는 핸들을 조작하고 브레이크를 밟는 법부터 익히는 것과 비슷합니다. 따라서 학습자가 서버의 전체적인 골격을 파악하는 데 방해가 되지 않도록 의도적으로 단순화된 코드를 사용하는 과정이라 볼 수 있습니다.
본격적인 실무 관점의 최적화와 깊이 있는 내용은 파트 2에서 중점적으로 다뤄지게 됩니다. 파트 2에서는 단순히 기능을 구현하는 것을 넘어 Express의 내부 엔진이 실제로 어떻게 미들웨어를 실행하고 요청을 처리하는지 그 내부를 깊숙이 들여다봅니다. 특히 대규모 트래픽을 견디기 위한 성능 최적화 기법을 배우면서, 왜 실무에서는 비동기 방식인 readFile이나 async/await를 활용해 이벤트 루프를 방해하지 않아야 하는지를 실무적인 코드로 확인하게 됩니다. 결과적으로 파트 2까지 모두 경험하셔야 비로소 실제 서비스에 적용 가능한 수준의 깊이 있는 개발 역량을 갖추실 수 있습니다.
그렇다면 실무에서는 이 동기 메서드를 아예 배제하는 것일까요? 사실 실무에서도 이 방식이 정답이 되는 순간이 있는데, 바로 서버가 가동되기 직전의 초기 설정 단계입니다. 예를 들어 서버 운영에 반드시 필요한 보안 인증서나 환경 설정 파일을 불러오는 작업은 서버가 손님의 요청을 받기 시작하기 전에 딱 한 번만 수행됩니다. 이는 식당이 문을 열기 전 주방을 세팅하는 시간에는 잠시 작업이 멈춰도 손님에게 지장을 주지 않는 것과 같습니다. 오히려 이런 초기화 단계에서는 실행 순서를 확실히 보장하면서도 코드가 간결한 동기 방식이 더 안전하고 효율적일 수 있습니다.
결론적으로 파트 1은 서버의 기초 체력을 기르는 과정이며, 파트 2는 그 체력을 바탕으로 실제 서비스에서 최적의 성능을 끌어내는 법을 배우는 과정입니다. 지금처럼 코드 한 줄이 실무에서 어떤 영향을 미칠지 고민하며 학습하신다면 파트 2에서 다룰 심화 개념들도 아주 빠르게 본인의 것으로 만드실 수 있을 것입니다.
참고해주세요!
안녕하세요 코딩님!
Express 파트 2에서 Express의 내부 엔진을 직접 구현해보는 경험은 마치 자동차 엔진의 피스톤과 기어가 어떻게 맞물려 돌아가는지 밑바닥부터 직접 조립해보는 것과 같습니다. NestJS는 사실상 Express라는 강력한 엔진을 심장으로 품고 그 위에 '대규모 건축 설계도'를 얹은 형태이기 때문에, 코딩 님이 직접 한 줄씩 코딩하며 만들게 될 미들웨어의 작동 원리나 요청과 응답이 오가는 정교한 순환 구조는 NestJS의 내부에서도 토씨 하나 틀리지 않고 동일한 논리로 흐르게 됩니다. 이를 실무적인 관점에서 본다면 단순히 프레임워크의 사용법만 익힌 개발자들이 원인 모를 에러 앞에서 당황할 때, 엔진의 구조를 아는 코딩 님은 본인이 직접 짰던 코드를 떠올리며 엔진룸을 열어 문제를 정확히 짚어낼 수 있는 해결사 역할을 할 수 있다는 뜻이기도 합니다.
하지만 자동차 엔진을 완벽히 이해했다고 해서 바로 자율주행 시스템을 운영할 수 있는 것은 아니듯, NestJS라는 거대한 자동화 프레임워크를 다루기 위해서는 두 가지 핵심적인 무기를 추가로 장착해야 합니다. 첫 번째는 타입스크립트(TypeScript)라는 정밀한 언어 도구인데, 이는 자바스크립트가 누구나 자유롭게 말하는 구어체라면 타입스크립트는 단어 하나하나의 의미와 규격을 명확히 정의해야 하는 '법률 계약서'와 같습니다. 실무에서는 수만 줄의 코드가 얽히기 때문에 "이 데이터는 반드시 숫자여야 한다"는 식의 엄격한 계약 없이는 금방 시스템이 무너지고 맙니다. NestJS는 이 계약서를 기반으로 모든 기능을 수행하므로, 클래스와 인터페이스 그리고 코드 위에 일종의 명찰을 붙여 역할을 부여하는 데코레이터 같은 문법들을 익히는 데 반드시 별도의 노력을 기울여야 합니다.
두 번째로 익혀야 할 중요한 개념은 제어의 역전(IoC)과 의존성 주입(DI)이라는 설계 방식입니다. Express에서는 요리사인 개발자가 직접 칼과 도마를 챙겨와서 요리를 하는 수동 방식이었다면, NestJS는 요리사가 "나는 지금 이런 칼이 필요해"라고 선언만 하면 프레임워크라는 주방 매니저가 상황에 맞는 최적의 도구를 요리사의 손에 직접 쥐여주는 자동화 시스템을 갖추고 있습니다. 파트 2에서 모든 객체를 직접 생성하고 연결해보는 고생스러운 경험을 먼저 쌓아야만, 나중에 NestJS가 제공하는 이 관리 시스템이 얼마나 편리하고 강력한 것인지 진심으로 이해하고 자유자재로 다룰 수 있게 됩니다.
이러한 이해를 바탕으로 실무에서 두 도구를 선택할 때는 프로젝트의 목적을 고려해야 합니다. Express는 최소한의 도구로 아이디어를 빠르게 구현해야 하는 1인 개발이나 가벼운 서비스에 최적화된 DIY 툴킷과 같아서, 자유도가 높은 만큼 신속한 검증이 필요한 단계에서 강력한 힘을 발휘합니다. 반면 NestJS는 수많은 개발자가 협업하며 시스템을 안정적으로 확장해야 하는 대규모 공장 시스템과 같아서, 엄격한 규칙을 통해 프로젝트가 커져도 누구나 구조를 쉽게 파악할 수 있는 유지보수의 안정성을 제공합니다.
또한 NestJS는 단순히 요청을 받는 미들웨어를 넘어 데이터가 유효한지 검사하는 파이프나 사용자의 권한을 확인하는 가드처럼 훨씬 세분화된 처리 장치들을 가지고 있습니다. 이는 코딩 님이 파트 2에서 구현할 미들웨어 개념을 NestJS만의 철학으로 아주 촘촘하게 확장한 것이라 볼 수 있습니다. 실무에서는 이 장치들이 어떤 순서로 실행되는지 그 '생명주기'를 파악하는 것이 성능 최적화와 보안의 핵심이 됩니다.
결국 파트 2는 어떤 새로운 프레임워크가 등장하더라도 그 밑바닥을 꿰뚫어 볼 수 있는 본질적인 엔진의 원리를 깨닫게 해주는 과정이며, 그 단단한 기초 위에 타입스크립트라는 정교함과 설계 전략을 얹는다면 단순히 기능을 구현하는 수준을 넘어 시스템 전체의 흐름을 설계하는 시니어 개발자로 성장하는 발판이 될 것입니다.
참고해주세요!
파트2까지 수강이후 nest 프레임워크를 공부해서 프로젝트에 적용해보려는데
파트 2내용을 잘 체득한다면 nest는 express위에서 돌아가는 프레임워크이기에 nest의 내구조의 기반도 같이 체득하는것인지 아님 nest의 내부구조에 대한 이해는 또 다른 공부가 추가적으로 필요한지가 좀 궁금합니다