Logic in Code,
Freedom in Travel.

콜백 지옥의 다음 세대Promise 가 도입되기 전 '콜백 지옥' 은 어지러웠다. Java나 Go처럼 멀티 스레드를 사용하거나, PHP처럼 동기적 흐름이 기본인 언어를 다루다 Node.js 으로 넘어오면서 비동기 흐름 제어가 가장 큰 진입 장벽이었다. 하지만 자바스크립트는 ES6(ECMAScript 2015)가 등장하면서 비동기 작업의 최종 완료 또는 실패를 나타내는 Promise가 표준으로 채택되면서 보기 좋은 비동기 코드를 작성할 수 있게 되었다. Promise: 비동기의 새로운 문법콜백 패턴에서는 비동기 처리의 결과를 콜백 함수 내부에서만 처리할 수 있었다. 하지만 Promise 는 미래의 어떤 시점에 결과를 담은 객체를 반환한다. 이 객체는 성공(resolve)하거나 실패(reject)하며 th..

DNS와 TCP, 그리고 성능의 병목DNS(Domain Name System)는 가볍고 빠른 UDP(User Datagram Protocol) 53번 포트를 주로 사용한다고 알려져 있다. 하지만 DNSSEC의 보급, IPv6 도입, TXT 레코드 등으로 인해 응답 패킷의 크기가 UDP의 제한인 512바이트(EDNS0 제외 시)를 초과하는 경우가 빈번해졌다. 이때 DNS는 신뢰성 있는 전송을 위해 TCP로 프로토콜을 전환(Fallback)한다.학교에서 배웠듯 TCP는 3-way Handshake를 통해 연결을 수립하고, 흐름 제어(Flow Control)와 혼잡 제어(Congestion Control)를 수행한다. 이는 데이터 무결성을 보장하지만, UDP 대비 오버헤드가 크다는 것을 의미한다. 트래픽이 몰..

싱글 스레드 기반의 Node.js 환경에서 동적 UI, 네트워크 통신, 파일 I/O 등과 '동시성(Concurrency)' 의 문제로 비동기 처리 전략이 항상 문제다. 과거 법무법인에서 ERP를 개발하던 시절에 Ext.js를 사용하며 처음으로 진짜 '콜백 지옥'을 경험했다. 시간이 꽤 흐른 뒤, 우연히 마주한 레거시 코드에서 이 지옥을 다시 만났을 때 주님을 찾는건 어쩔 수 없었다. JavaScript 의 버전 업데이트가 진행되면서 불편한게 많이 개선되었지만 개선되기 전에 작성된 코드에는 Node.js 6 이라는 버전을 사용하는 프로젝트에서 콜백 지옥이 나를 기다리고 있었다. 콜백 지옥지금은 async/await 이 당연한 문법처럼 느껴지지만, Node.js 가 처음 등장했을 때 비동기 처리는 혁명적이었..

웹 생태계의 복잡도가 증가함에 따라 HTTP 1.1 표준은 성능상의 한계로 HTTP 2.0 이 등장하였다. 요즘 회사에서도 (옆 팀에서) MSA 에 관한 주제로 많은 이야기를 하고 있으며 HTTP 2.0 이 언급되었다. 1. HTTP 1.1 의 한계: 직렬 처리의 병목HTTP 1.1은 기본적으로 텍스트 기반이며, 요청과 응답이 순차적으로 이루어지는 구조를 가진다. 이는 현대의 웹 환경에서 두 가지 치명적인 비효율을 야기했다.HOL Blocking (Head of Line Blocking)HTTP 1.1은 한 번에 하나의 요청만 처리 가능하다(Pipelining이 존재했으나 안정성 문제로 사장됨). 앞선 요청의 처리가 지연되면 후속 요청들이 모두 대기해야 하는 병목 현상이 발생한다.헤더의 중복 전송매 요청..

PHP 와 Node.js 생태계에서 개발하면서 문서가 너무 없거나, 너무 많아서 원하는 내용을 찾기 힘든 경우가 많았다.1. 문서가 부실한 이유: "개발자의 딜레마와 현실"오픈소스가 문서화보다 기능 구현에 쏠릴 수 밖에 없는 원인 The Code is Truth코드를 작성한 사람은 코드의 흐름을 너무 잘 알고 있을 것이다. 그래서 주석이나 문서 없이도 변수명과 함수 구조만 보면 잘 안다. 프로그래밍 언어 특성에 따라 자바스크립트 생태계는 코드를 빨리 짜고 배포하는 문화가 강하다. "일단 동작하게 만드는 것(Make it work)"이 우선시되다 보니 문서는 뒷전으로 밀리는 것 같다. 이로인해 `README.md`에 설치 방법만 있고, 구체적인 사용법이나 엣지 케이스에 대한 설명이 없는 경우가 많은 것 같..

우리가 커밋을 하고 코드를 push/merge 할 때에는 잘 동작하고 테스트도 잘 통과되었기 때문에 그랬을 것이다. 내가 서비스의 이해도가 깊고, 코드를 장악하고 있고, 테스트 커버리지가 100 이 나온다 하더라도 주의하고 침착해야 한다. 코드 한줄로 회사가 문을 닫을수도 있는게 개발자, 엔지니어로서의 책임이라 생각된다. 엔지니어의 책임으로서 꼭 알아야 할 1가지가 있다면 git add -p 이다.git add -p는 변경된 파일의 일부만 선택적으로 스테이지에 추가할 수 있도록 도와주는 기능이다. 전체 파일을 한 번에 커밋하지 않고, 필요한 부분만 선택해서 커밋하고 싶을 때 사용하며 매번 사용하는 습관을 들이면 좋다.습관을 들인다면 10년후 누군가 내 코드의 의도를 쉽게 파악하는데 도움이 된다. 누가 ..