Dev Log

오늘은 조금 가벼운 내용을 올려봅니다. 개발을 하다 보면 장애 대응, 디버깅, 로그 분석, 재현 환경 구성처럼 머리를 오래 써야 하는 순간이 자주 있습니다. 이런 상황에서는 기술적인 숙련도도 중요하지만, 의외로 집중력을 회복하는 루틴도 꽤 중요합니다. 개인적으로 효과가 좋았던 방법을 정리해보면 아래와 같습니다. 1. 일단 화면에서 한 발짝 떨어지기 오래 붙잡고 있어도 안 보이던 문제가, 잠깐 시선을 돌리고 나면 보일 때가 있습니다. 2. 로그를 다시 보기 전에 마음을 먼저 진정시키기 급할수록 로그를 더 대충 읽게 되는 경우가 있습니다. 한 템포만 늦추면 놓친 포인트가 다시 들어옵니다. 3. 너무 복잡하게 생각하지 않기 문제는 종종 예상보다 단순한 곳에 있습니다. 캐시, 환경 변수, 타임아웃, 직렬화, 커넥션 풀 같은 기본 요소부터 다시 보면 의외로 빨리 풀리기도 합니다. 4. 귀여운 것을 잠깐 보기 생각보다 효과가 있습니다. 5. 다시 본론으로 돌아오기 자, 이제 다시 개발로 돌아갈 시간입니다. 개 발입니다. 꿀팁이죠? 조금 뻘글이었습니다. 그래도 진짜로, 막히는 날에는 잠깐 쉬고 시선을 환기하는 게 꽤 도움이 됩니다. 읽어주셔서 감사합니다.

안녕하세요. Dev Log의 첫 글입니다. 이 채널에는 개발 과정에서 겪은 문제와 해결 과정을 기록하려고 합니다. 특히 운영 환경에서 발생하는 trouble shooting 사례를 중심으로, 증상과 원인, 확인 방법, 대응 방법을 정리해볼 예정입니다. 첫 글에서는 Node.js 서버 운영 중 발생했던 지연 이슈를 추적하고 해결한 과정을 정리합니다. 문제 상황 운영 중이던 Node.js API 서버에서 특정 시간대에 응답 지연이 발생했습니다. 평소에는 대부분의 요청이 100ms 안팎에서 처리됐지만, 문제가 발생하는 구간에는 일부 요청이 3초에서 5초까지 증가했습니다. 특이한 점은 CPU 사용률이 지속적으로 높지 않았고, 메모리 사용량도 즉시 장애를 의심할 정도는 아니었다는 점입니다. 초기에는 단순한 트래픽 증가나 인스턴스 성능 문제를 먼저 의심했습니다. 하지만 요청 패턴을 보면 전체 API가 느려지는 것이 아니라, 특정 요청들이 묶여서 지연되는 형태에 가까웠습니다. 이 패턴 때문에 애플리케이션 레벨의 병목 가능성을 먼저 확인하기로 했습니다. 1차 확인 우선 아래 항목을 기준으로 원인을 좁혀갔습니다. 데이터베이스 쿼리 지연 외부 API 응답 지연 Node.js 이벤트 루프 블로킹 DB slow query 로그에는 유의미한 이상이 없었습니다. 외부 API 호출 시간도 평소와 큰 차이가 없었습니다. 다음으로 이벤트 루프 지연을 측정하는 로그를 추가했습니다. 문제 시간대의 로그를 확인해보니, 지연이 발생한 시점마다 event loop lag가 함께 증가하고 있었습니다. 이 시점에서 문제는 I/O 대기보다, Node.js 프로세스 내부에서 메인 스레드를 오래 점유하는 작업일 가능성이 높다고 판단했습니다. 원인 분석 코드를 추적하던 중, 관리자 통계 페이지에서 사용하는 API 하나가 눈에 들어왔습니다. 이 API는 최근 24시간 기준 데이터를 조회한 뒤, 여러 집계 결과를 하나의 큰 객체로 조합해 응답하는 구조였습니다. 문제는 응답 직전에 끝나지 않았습니다. 같은 데이터를 Redis 캐시에 저장하기 위해, 서버에서 큰 객체를 JSON.stringify() 한 뒤 캐시에 기록하고 있었습니다.