zigbang

문제데이터 용량을 표기할 때 1KB가 1,000바이트인지 1,024바이트인지가 도구마다 달라 혼란이 생긴다.

접근비트와 바이트의 정의부터 십진과 이진 표기 차이, 그리고 1998년 IEC가 도입한 KiB 같은 이진 접두사 표기법을 차례로 정리한다.

결과KB는 십진의 1,000바이트, KiB는 이진의 1,024바이트로 구분해 표기하는 것이 표준이며 AWS 등에서도 이 구분을 따른다고 정리한다.

문제직방의 매물 조회 기능은 19개에 달하는 복잡한 필터 조건을 다루다 보니 QueryBuilder 코드가 중복되고 테스트와 유지보수가 어려워졌다.

접근빌더 패턴을 도입해 `ItemFindOptions`로 옵션을 정의하고 `ItemFindQueryBuilder`가 메서드 체이닝으로 동적 쿼리를 조립한다. Repository는 빌더를 통해 단일 진입점만 노출한다.

결과하나의 메서드로 여러 필터 조합을 처리하면서 빌더 단위 유닛테스트로 각 조건을 검증할 수 있게 됐다. 새 필터 추가가 쉬워지고 서비스 로직 테스트 난이도가 떨어졌다.

문제인덱스가 걸려 있는데도 MySQL 쿼리 성능이 안 나오는 네 가지 상황을 다룬다. 손익 분기점, 범위 조건의 비효율, 랜덤 액세스 비용, 중복 인덱스 문제다.

접근EXPLAIN ANALYZE와 I/O 프로파일링으로 실행 계획을 분석하고, 국토부 부동산 실거래 200만 건으로 테스트했다. LIKE를 IN-LIST로 변환하고 커버링 인덱스를 추가하며 중복 인덱스를 통폐합한다.

결과테이블 액세스 I/O가 457,927에서 16,785로 약 3.7% 수준까지 줄었다. 중복 인덱스 정리로 쓰기 I/O는 199,677에서 80,328로 40% 수준으로 떨어졌다.

문제직방의 React Native 앱은 모듈별 독립 배포와 OTA 업데이트, 앱스토어 심사 회피, 빠른 빌드가 동시에 필요했다.

접근Webpack 기반 번들러 Re.Pack을 도입해 호스트 앱이 원격 모듈을 동적으로 로드하는 Module Federation 구조를 만들고 코드 스플리팅으로 청크 단위 배포를 가능하게 했다.

결과모듈 단위 독립 개발과 OTA 배포가 가능해졌지만 네트워크 비용 증가와 테스트·디버깅 복잡도, 좁은 생태계라는 트레이드오프도 확인했다.

문제Node.js에서 haversine, geolib, cheap-ruler 같은 거리 계산 라이브러리의 실제 성능 차이를 확인해야 한다.

접근세 라이브러리를 NestJS API 엔드포인트로 각각 구현한 뒤 autocannon으로 60초간 부하테스트를 수행한다. 매 요청마다 위경도를 랜덤화해 실제 트래픽에 가깝게 측정한다.

결과60초 동안 551k~559k 요청, 평균 응답 0.54~0.56ms로 라이브러리 간 차이는 미미했다. 성능보다는 커뮤니티 규모와 정확도 기준으로 선택하는 게 합리적이다.

문제AWS RDS는 CloudWatch에서 100개 가까운 지표를 제공하지만 필요한 것만 골라 한눈에 보기 어렵다.

접근필요한 핵심 지표만 모은 개인 CloudWatch Dashboard를 구성한다. Horizontal Thresholds로 경고/위험 라인을 그리고, Anomaly Detection으로 ML 기반 정상 범위를 자동 산출해 이상 신호를 강조한다.

결과DB 상태를 시각적으로 정상/주의/위험 단계로 구분할 수 있는 개인화 모니터링 화면을 얻는다. 사람이 일일이 임계값을 정하지 않아도 이상 패턴을 잡아낸다.

문제로그와 메트릭만으로는 마이크로서비스 사이 요청 흐름을 추적하는 observability가 부족하다.

접근Kubernetes 위에서 OpenTelemetry, Grafana, Tempo로 분산 추적 스택을 구축한다. Helm으로 인프라 설치를 자동화하고, Node.js 앱에는 auto-instrumentation을 붙여 코드 변경을 최소화한다.

결과HTTP 요청, DB 쿼리 등 라이브러리 활동이 자동으로 trace로 수집된다. 마이크로서비스 사이의 호출 경로를 시각화해 병목 지점을 찾기 쉬워진다.

문제S3 + CloudFront로 배포되는 호갱노노 이미지가 무단 사용되는 것을 막고 브랜드 표시를 자동화해야 했다.

접근CloudFront 응답 단계에서 Lambda@Edge를 실행해 Sharp로 워터마크를 합성한다. S3 업로드는 Presigned URL로 분리하고, edgelambda.amazonaws.com 권한을 IAM Role에 부여한다.

결과원본 이미지에 워터마크가 엣지에서 동적으로 입혀져 별도 배치 없이 보호와 브랜딩이 동시에 적용된다.

문제개발자가 코드를 작성하는 시간보다 읽는 시간이 약 10배 많아 클린코드 원칙만으로는 가독성이 부족했다.

접근JetBrains IDE의 시각 강화 기능을 적용한다. 검색 결과 하이라이트, 변수 읽기·쓰기 구분, 현재 라인 강조, Method Separator, 시맨틱 하이라이팅을 켜고 Indent Rainbow 플러그인으로 들여쓰기를 시각화한다.

결과코드가 텍스트가 아니라 색과 패턴으로 인지되어 가독성과 생산성이 높아진다. 같은 IDE에서도 설정만으로 큰 차이를 만든다.

문제클린코드가 좋다는 건 알지만 왜 읽기 쉬운지 과학적 근거가 부족했다.

접근뇌의 인지 구조로 설명한다. 혼란은 지식 부족·정보 부족·처리 능력 부족 세 가지로 나뉘고, 기억은 장기기억(LTM)·단기기억(STM)·작업기억으로 구성된다. 청킹으로 정보를 의미 단위로 묶어 용량을 늘린다.

결과함수 인수 최소화는 작업기억 부하를 줄이고, 작은 클래스·메서드는 청킹을 돕는다. 중복 제거는 혼동을 막고 의미 있는 이름은 LTM 검색을 쉽게 한다. 클린코드 지침의 근거가 인지과학에 있음을 보여준다.