Engineering Culture
Rune의 오픈소스 공개에서 본 IDE 성능과 확장성의 조건
Go로 만든 Rune의 오픈소스 공개를 계기로 터미널 성능 측정의 범위와 확장 API의 경계를 살펴본다. 언어 지원, 빌드 전제, 원격 연결 비용을 바탕으로 일상적인 개발 도구로 전환할 조건을 정리한다.
THE BUILDER’S NOTE
Engineering.
01 / INSIDE THE BUILD만들며 배우고, 배운 것을 나눕니다.
더 나은 제품을 향한 개발의 기록.
최근 이야기
작은 발견부터 깊이 있는 고민까지.
DevOps
사용자 증상에서 출발하는 서비스 지표, 다음 실험으로 이어지는 회고
CPU 사용률만 보고 있으면 요청이 실패하는데도 상태가 정상처럼 보일 수 있다. 자원 지표와 사용자가 경험하는 결과를 함께 관찰해야 한다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
AI & Data
시간 순서를 지키는 평가, 다음 실험으로 이어지는 회고
미래 값을 예측하는 문제를 무작위로 나누면 미래 정보가 과거의 학습에 섞일 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
Backend
N+1 조회를 목록 단위로 보기, 다음 실험으로 이어지는 회고
목록의 각 행을 그릴 때 관련 데이터를 따로 읽으면 항목 수만큼 쿼리가 늘어날 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
Frontend
검색 조건을 URL에 보관하기, 다음 실험으로 이어지는 회고
목록에서 상세로 갔다가 돌아오면 검색어와 페이지가 사라져 탐색을 다시 시작하게 된다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.
DevOps
요청 식별자로 여러 서비스의 기록 연결하기, 다음 실험으로 이어지는 회고
요청이 프록시와 API, 작업 큐를 거치면 한 줄의 오류만으로 전체 흐름을 찾기 어렵다. 각 구간이 같은 상관 식별자를 공유하면 조사 범위를 좁힐 수 있다. 결론보다 남은 질문를 중심으로 작은 예제와 확인 기준을 정리합니다.