개발 배우는 몽이

WOOWACON 2025 참가 후기

wddy2001 — Fri, 31 Oct 2025 20:21:03 +0900

WOOWACON이란?

올해로 6회째를 맞은 우아콘(WOOWACON)은 배달의 민족을 운영하는 우아한 형제들이 매년 개최하는 기술 컨퍼런스입니다. 실무에서 쌓은 기술과 경험을 개발 커뮤니티와 공유하는 자리로, 매년 천여 명의 개발자들이 참여합니다. 저는 우아한 형제들의 교육 프로그램인 우아한 테크코스 과정 중 진행된 추첨에 당첨되어 참가하게 되었습니다.

기대와 첫 인상

당첨 소식을 받았을 때, 솔직히 우아콘에 대한 기대나 관심이 크지 않았습니다. 최근에야 개발에 관심을 갖기 시작해서인지, 이런 컨퍼런스에서 무엇을 얻을 수 있는지 감이 오지 않았습니다.

대규모 컨퍼런스에 대한 회의감도 있었습니다. '내게 필요한 정보가 있을까?', '나중에 영상으로 보는 게 더 효과적이지 않을까?' 현장에서만 느낄 수 있는 무언가가 있을지 의구심이 컸습니다.

그런데 주변 크루들의 반응이 생각보다 뜨거웠습니다. 개발에 진심인 이들의 희비가 엇갈리는 모습을 보니, 문득 내가 이 기회를 너무 가볍게 여기고 있는 건 아닌가 하는 생각이 들었습니다.

마음가짐을 바꾸고 사전 프로그램을 살펴보기 시작했습니다. 어떤 세션이 내게 도움이 될지, 어떤 주제에서 배울 점이 있을지 고민했습니다. 우아한 형제들이 실무에서 마주한 기술적 도전을 어떻게 해결했는지, 그 과정에서 어떤 인사이트를 얻을 수 있을지 기대하게 되었습니다.

참석한 세션들과 소감

세션들은 시간대마다 6개 트랙(A~F)이 동시에 진행되었고, 각 시간대마다 하나씩 선택할 수 있었습니다.

레거시 시스템 관리 등 관심 있는 주제들도 많았지만, 현재 프로젝트 과제와 연관성이 높은 세션을 우선 선택했습니다.

우아콘에서 들었던 세션들

세션들을 경험하면서 가장 크게 느낀 점은 예상과의 차이였습니다. 사전 프로그램을 보며 '실무에서 마주한 기술적 도전을 어떻게 해결했는지'에 대한 인사이트를 기대했는데, 돌이켜보니 조금 순진한 기대였던 것 같습니다.

대학이나 우테코 기술 특강, 테코톡 같은 교육 세션을 떠올렸지만, 우아콘은 기업 컨퍼런스라는 점에서 차이가 있었습니다. 교육 세션들이 특정 기술 스택이나 아키텍처 설계처럼 깊이 있는 기술 내용 자체를 전달하는 데 집중한다면, 우아콘 세션들은 '우리 팀이 조직 내에서 어떤 역할을 하고, 어떤 성과를 보였는가'를 보여주는 데 무게를 두고 있었습니다.

이런 특징은 다음 두 세션에서 특히 명확했습니다.

고객의 편리함을 완성하는 프로세스, 배민 사용자 경험 관리

UX Management TF팀이 조직 내에서 수행하는 역할을 소개한 세션이었습니다.

배민 클럽 같은 기능 하나를 만들 때도 마케팅, 기획, 개발 등 여러 부서가 참여하는데, 각자 다른 관점에서 요구사항을 제시하다 보니 조율 과정에서 방향성이 엇갈리기 쉽습니다. TF팀은 이 지점에서 중간 다리 역할을 합니다. '고객 관점에서 일관성 있는 경험과 디테일 제공'을 최우선에 두고, 여러 부서가 통합된 환경에서 논의할 수 있도록 돕습니다. 조직 내 피드백 루프를 구축해 빠른 의사결정을 가능하게 하고, 고객 중심의 의사결정 프로세스와 도구를 만들어 전사에 전파하는 것이 이 팀의 목표입니다.

방향성이 엇갈리면 일관된 사용자 경험이 깨지고, 화면마다 다른 UI/UX가 나타나 마치 서로 다른 화면을 억지로 이어붙인 것처럼 느껴집니다.

더 나은 이상 탐지를 위한 여정: 서버부터 서비스, 그리고 문화까지

SRE팀이 시스템 신뢰성을 어떻게 개선해왔는지 공유한 세션이었습니다.

우형에서는 SRE팀이 생기기 전부터 각 부서가 자체 모니터링 시스템을 운영하고 있었습니다. 하지만 이는 각 부서의 필요에 따라 개별적으로 구축된 시스템이었기에, 전사적인 장애 대응에는 한계가 있었습니다.

구체적으로는 다음과 같은 문제들이 있었습니다.

지표별로 경보 전달 방식이 제각각이고, 담당자가 대응 중인지 확인할 수단이 없음
지표별 담당 조직 정보가 없어 장애 여부 판단이 어렵고, 장애 전파가 지연됨
장애 여부를 판단하고 원인과 해결 방안을 확인하는 과정에서 시간이 소요되어 대응이 늦어짐

SRE팀은 이러한 문제를 해결하기 위해 '빠른 장애 전파'와 '신뢰성 있는 경보 시스템 구축'에 집중했습니다. 그 결과 장애 인지 시간과 장애 공지 시간을 단축해 전체적인 장애 대응 속도를 개선할 수 있었습니다.

두 세션 모두 조직 내에서 부서 간 조율을 담당하는 팀을 소개했다는 공통점이 있었습니다.

회사가 커지면서 하나의 서비스에도 여러 부서가 관여하게 되고, 이들 사이를 조율하고 통합하는 역할이 필요해진 것입니다. 어떻게 보면 AOP의 횡단 관심사 같은 개념이라, 무엇을 하려는 팀인지는 쉽게 이해할 수 있었습니다.

다만 전사 규모의 조직을 경험해본 적 없는 저에게는 깊이 있게 다가오지 않았습니다. 우테코에서 이런 역할의 필요성을 배웠고, 작은 규모이지만 현재 프로젝트에서도 비슷한 고민을 하고 있었기 때문입니다. 규모의 차이가 가져오는 복잡도는 비교할 수 없이 크겠지만, 문제의 본질만 놓고 보면 유사해 보였습니다.

그래서인지 세션에서는 '기술적으로 어떻게 해결했는가'보다, '우리 팀이 어떤 성과를 냈는가'가 더 부각되어 보였습니다. 여기서 앞서 기대했던 교육 세션과의 차이를 다시 확인할 수 있었습니다.

이 시점까지는 제가 우아콘을 잘못 이해하고 온 것 같다는 생각이 들었습니다. 각 팀의 성과를 듣는 것이 제게는 크게 의미 있게 느껴지지 않았기 때문입니다. 그런데 다음 세션을 들으면서 생각이 달라졌습니다. 제가 너무 좁은 관점으로 우아콘을 바라보고 있었던 것입니다.

무조건 격리한다고 좋은 테스트일까? MSA 환경에서 구축하는 시나리오 인수 테스트

광고 플랫폼 서버 개발팀과 서버교육팀이 함께 진행한 MSA 환경 인수 테스트 적용 사례였습니다.

개발팀이 QA팀에 검증을 의뢰한 결과, 1800개 가량의 시나리오 테스트가 진행되었습니다. 개발팀도 기존에 인수 테스트를 작성했지만, 이는 개별 서비스 단위 테스트였을 뿐 MSA 전체 흐름을 검증하는 테스트는 아니었습니다.

여기서 두 가지 의문이 생겼습니다. 매번 QA팀에 의존해야만 신뢰할 수 있는 서비스일까? 그리고 독립적인 검증만으로 전체 시브템의 연결성을 보장할 수 있을까? 이러한 문제의식에서 MSA 환경에 적합한 시나리오 인수 테스트 개발이 시작되었습니다

인수테스트는 Cucumber로 직관적인 인수 조건을 작성하고, Docker Compose로 환경을 구성했으며, 외부 의존성은 WireMock으로 관리했습니다. 테스트 계층은 커버리지에 따라 세 단계로 나뉩니다. 먼저 서버가 정상 실행되는지 확인하는 Smoke 테스트, MSA 상에서 개별 서비스 간 연결 상태를 확인하는 E2E 테스트를 작성해 순수한 MSA 환경 상태를 검증합니다. 이후 Acceptance 테스트로 서비스에 대한 본격적인 검증을 진행합니다. MSA 환경의 문제 영역에 맞게 테스트 계층을 분리해 빠른 피드백을 받을 수 있었습니다.

모든 엣지 케이스를 처음부터 작성하는 것은 테스트 도입 부담을 키우기에, 먼저 유저의 해피 케이스 중심으로 인수 조건을 작성했습니다. 해피 케이스가 안정된 이후 배포를 거듭하며 필요한 엣지 케이스를 리그레션 테스트로 추가하는 점진적 도입 방식을 택했습니다.

이러한 시나리오 기반 테스트를 통해 QA 이후에도 QA 수준의 테스트를 반복 수행할 수 있게 되었고, 격리 대신 통합된 테스트 환경을 구축해 MSA 환경에서 서비스 간 연결성을 검증할 수 있었습니다.

이 세션이 인상적이었던 건 단순히 성과를 나열하는 데 그치지 않았다는 점입니다. 발표자는 한 가지 질문을 던졌습니다. "그렇다면 이 테스트 전략은 얼마나 효과적이었을까?" 테스트 성과는 배포 실패율이나 장애 건수처럼 유의미한 수치로 측정하기 어렵습니다. 하지만 발표자는 측정하기 어렵다고 의미가 없는 것은 아니라고 강조했습니다.

발표자는 개발팀 인터뷰 결과를 공유했습니다. 테스트 코드 작성이 번거롭다는 의견도 있었지만, 시스템에 대한 신뢰성을 팀 전체가 공유할 수 있게 되었다는 반응이 더 컸습니다. 팀이 추구하는 가치가 당장의 불편함을 넘어 하나의 문화로 자리 잡았다는 것이 핵심이었습니다. 발표자는 이렇게 작은 시도부터 시작해 점차 팀 문화로 발전시켜나가는 도전을 권유하며 세션을 마무리했습니다.

이 세션을 통해 우아한형제들의 문화를 이해하게 되었습니다. 이전 세션들에서 '성과 위주'라고 느꼈던 발표들도, 사실은 각 부서가 추구하는 목표와 창출한 가치를 공유하는 자리였습니다. 부서가 자신의 가치를 명확히 인식하고 조직에 공유하는 것, 그 자체가 의미 있는 일이었습니다.

각 부서의 가치를 인정하고 공유하는 것, 이것이 우아콘의 목적이자 우아한형제들 조직 문화의 핵심으로 느껴졌습니다. 각 부서가 명확한 가치를 가지고, 그 가치들이 서로 연결되면서 시너지를 만들어냅니다. 앞서 단순한 '횡단 관심사'로만 느껴졌던 UX TF팀이나 SRE팀도, 이렇게 보니 조직의 다른 부서들과 상호작용하며 새로운 가능성을 여는 것 같았습니다.

이런 조직 문화는 우아한형제들을 새롭게 보게 만들었습니다. 배민은 이미 시장을 선도하는 위치에 올랐고, 성장기는 지났다고 생각했습니다. 하지만 우아콘에서 본 모습은 달랐습니다. 각 부서는 여전히 살아 움직이며 새로운 가치를 만들어내기 위해 끊임없이 시도하고 있었습니다. 안정기에 접어든 대기업에서 이런 내부 활력을 유지한다는 것이 얼마나 어려운 일인지 생각하니, 더욱 인상적이었습니다. 이런 문화가 배민의 폭발적 성장을 가능하게 했고, 지금도 그 문화를 이어간다는 것을 우아콘을 통해 느낄 수 있었습니다.

마치며

우아콘에 대한 처음의 회의감은 완전히 사라졌습니다. 기술 컨퍼런스를 단순히 '새로운 기술을 배우는 곳'으로만 생각했던 제 시야가 얼마나 좁았는지 깨달았습니다. 우아콘은 기술을 넘어 문화를 보여줬습니다. 조직이 어떻게 움직이는지, 각 팀이 어떤 가치를 만들어내는지, 그리고 그 가치들이 어떻게 연결되어 더 큰 성과를 만드는지 배울 수 있었습니다.

우아한테크코스 크루로서 이런 기회를 얻게 되어 감사합니다. 언젠가 저도 무대에 서서 우리 팀이 만들어낸 가치를 공유할 수 있는 날이 오길 기대합니다.

왜 DDL-AUTO를 포기하고 Flyway를?

wddy2001 — Sat, 27 Sep 2025 15:56:21 +0900

프로젝트가 성장하면서 개발 환경과 운영 환경이 분리되었고, 각 환경의 데이터베이스 스키마를 체계적으로 관리할 필요성을 느끼게 되었습니다.

개발 환경에서는 JPA의 DDL-AUTO를 통해 손쉽게 스키마를 관리할 수 있었습니다.
하지만 팀 협업과 운영 안정성을 고려할 때 더 체계적인 접근이 필요했습니다.

Flyway는 데이터베이스 스키마 버전 관리 도구입니다.
Git이 소스코드를 관리하듯이, Flyway는 데이터베이스 구조 변경을 체계적으로 관리합니다. 각 스키마 변경을 순차적으로 적용하여 개발 환경과 운영 환경 간 데이터베이스 구조의 일관성을 보장합니다.

반면, JPA는 설정 한 줄로 일관된 데이터 스키마를 보장하는 강력한 편의성을 제공합니다. 객체 지향 개발자가 객체와 데이터베이스 테이블을 동일한 관점에서 다룰 수 있게 해주죠. Spring Boot 환경에서 개발해본 경험이 있다면 이러한 편의성을 잘 알 것입니다.

JPA의 편리함에도 불구하고 별도의 스키마 관리 도구가 필요한 이유를 API 버저닝 경험에서 찾을 수 있었습니다. 프론트엔드와의 협업에서 겪은 API 버전 관리 문제가 스키마 관리에서도 동일하게 나타났고, 이를 통해 점진적 마이그레이션의 중요성을 깨닫게 되었습니다.

요약
- 협업 과정에서 겪은 "점진적 리펙터링을 WAS를 넘어 DB에 적용한 경험을 회고합니다.
- API 버저닝을 시작으로, JPA 중심의 DB 스키마 관리에서 Flyway로 전환한 배경을 다룹니다.

팀 협업에서 발견한 문제점

팀 프로젝트에서 데이터베이스 구조를 변경하는 과정에서 협업의 어려움을 겪었습니다.

Room → WishList → Wish 구조에서 WishList를 제거하고 Room → Wish로 단순화하는 리팩터링이 필요했습니다.

초기 구조와 요구사항 변경

프로젝트 초기에는 다음과 같은 엔티티 구조를 설계했습니다.

@Entity
public class Room {
    @OneToMany
    private List<WishList> wishLists;
}

@Entity
public class WishList {
    @ManyToOne
    private Room room;
    
    @OneToMany
    private List<Wish> wishes;
}

@Entity
public class Wish {
    @ManyToOne
    private WishList wishList;
}

이 구조에 맞춰 프론트엔드에서는 Room 조회 → WishList 조회 → Wish 조회 페이지 순서로 네비게이션을 구현했습니다.

사용자 테스트를 통해 다음과 같은 요구사항 변경이 발생했습니다.

Room당 둘 이상의 WishList가 불필요함
WishList라는 중간 개념이 UX적으로 불편함
Room에서 바로 Wish 목록을 관리하는 것이 더 직관적

결론적으로 WishList를 제거하고 Room → Wish로 단순화하자는 결정을 내렸습니다.

API 변경에서 겪은 협업 문제

초기에는 단순하게 접근했습니다. 기존 API를 직접 수정하는 방식이었습니다.

- 기존 API 직접 변경 방식

기존: GET /api/rooms/{roomId}/wishlists/{wishlistId}/wishes
변경: GET /api/rooms/{roomId}/wishes

하지만 이는 협업 지연 문제로 이어졌습니다.

프론트엔드 팀에서는 Room 조회 페이지와 Wish 조회 페이지를 서로 다른 팀원이 담당하고 있었습니다.

Wish 페이지 담당자: Room 페이지가 수정되기 전까지 작업 불가능
Room 페이지 담당자: 자신의 작업이 다른 팀원의 작업을 막고 있다는 부담
전체 팀: 순차적 작업으로 인한 개발 속도 저하

API 버저닝으로 해결한 협업 독립성

이 문제를 해결하기 위해 API 버저닝을 도입했습니다.

API 버저닝이란?
기존 API를 제거하지 않고 새 버전의 API를 병렬로 제공하는 방식입니다. 클라이언트가 각자의 일정에 맞춰 새 버전으로 전환할 수 있어 하위 호환성을 보장합니다.

- API 버저닝

기존 API 유지: GET /api/v1/rooms/{roomId}/wishlists/{wishlistId}/wishes
새로운 API 추가: GET /api/v2/rooms/{roomId}/wishes

이제 각 팀원이 자신의 일정에 맞춰 독립적으로 작업할 수 있게 되었습니다.

Room 페이지 담당자: 언제든 원하는 시점에 v2 API로 전환 가능
Wish 페이지 담당자: v1, v2 API 모두 동작하므로 대기할 필요 없음
다른 팀원들: 기존 v1 API로 개발 지속 가능

모든 팀원이 v2 API로 전환을 완료한 후, 안전하게 v1 API를 제거할 계획이었습니다.

하지만 API 버저닝으로 협업 문제를 해결했다고 생각했던 순간, 예상치 못한 곳에서 새로운 문제가 발생했습니다.

데이터베이스에서 발견된 새로운 문제

WAS에서 DB로 확장된 관리 범위

두 가지 API를 위해 엔티티 구조를 다음과 같이 확장했습니다:

@Entity
public class Room {
    @OneToMany
    private List<WishList> wishLists; // v1 API용
    
    @OneToMany  
    private List<Wish> wishes; // v2 API용
}

@Entity
public class Wish {
    @ManyToOne
    private WishList wishList; // v1 API용
    
    @ManyToOne
    private Room room; // v2 API용
}

JPA DDL-AUTO가 새로운 room_id 컬럼을 자동으로 추가했지만, 기존 데이터는 모두 NULL 상태였습니다. v2 API가 정상 동작하려면 다음과 같은 데이터 동기화가 필요했습니다.

UPDATE wish 
SET room_id = (
    SELECT room_id 
    FROM wishlist 
    WHERE wishlist.id = wish.wishlist_id
);

하지만 이 과정에서 다음과 같은 문제들이 발생했습니다.

실행 추적 불가: 누가 언제 실행했는지 알 수 없음
중복 실행 위험: 같은 스크립트를 여러 번 실행하는 경우 발생
누락 위험: 스크립트 실행을 깜빡하고 넘어가는 경우
순서 의존성: 여러 스크립트가 있을 때 실행 순서 관리 어려움

데이터 상태가 환경별로 일치하지 않는 문제가 발생했습니다.

개발자 A 로컬: room_id 데이터 동기화 완료
개발자 B 로컬: room_id 데이터 동기화 미완료 (모든 값이 NULL)

동일한 코드를 실행해도 환경마다 다른 결과가 나오면서 "왜 내 로컬에서 갑자기 에러가 나죠?"라는 질문이 슬랙에 계속 올라왔습니다.

핵심은 이것이었습니다: API는 버저닝을 통해 체계적으로 관리하고 있었는데, 데이터베이스는 여전히 수동으로 관리하고 있었던 것입니다.

JPA 중심 접근법의 한계

WAS 레벨에서만 생각했을 때는 JPA DDL-AUTO와 코드 변경만으로도 충분히 관리할 수 있었습니다.

하지만 실제로는 DB 레벨에서 다음과 같은 요소들을 고려해야 했습니다:

스키마 구조 변경
기존 데이터의 이관과 변환
환경별 데이터 상태 일관성
데이터 정합성 보장

JPA는 근본적으로 객체 지향 패러다임에서 설계된 도구입니다. 객체와 테이블 간의 매핑, 엔티티 관계 표현, 객체 중심의 쿼리 작성에 초점을 맞추고 있습니다. DDL-AUTO 기능도 "현재 엔티티 구조에 맞는 테이블 구조를 만들어주는" 역할을 합니다.

하지만 실제 데이터베이스를 운영하다 보면 데이터 중심적 사고가 필요한 순간들이 있습니다:

기존 데이터를 새로운 구조로 변환
복잡한 비즈니스 규칙에 따른 데이터 재구성
데이터 정합성을 보장하면서 단계적인 스키마 변경

이런 상황에서 JPA DDL-AUTO는 예상과 다르게 동작할 수 있습니다.

컬럼 타입 변경 시 데이터 손실 예시:

@Entity
public class User {
    @Column(length = 10)  // 기존 255에서 10으로 축소
    private String username;
}

JPA가 ALTER TABLE user MODIFY username VARCHAR(10)을 실행하면 10자를 초과하는 기존 데이터가 잘릴 수 있습니다.

안전한 변경을 위해서는 다음과 같은 단계별 접근이 필요합니다:

// V2__safe_username_length_reduction.sql

// 1. 백업 컬럼 생성 및 원본 데이터 보존
ALTER TABLE user ADD COLUMN username_old TEXT;
UPDATE user SET username_old = username;

// 2. 데이터 변경 로깅  
CREATE TABLE username_truncation_log (
    user_id BIGINT,
    original_data TEXT,
    truncated_data VARCHAR(10),
    truncation_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO username_truncation_log (user_id, original_data, truncated_data)
SELECT id, username, LEFT(username, 10) 
FROM user WHERE LENGTH(username) > 10;

// 3. 안전하게 데이터 축약 후 컬럼 변경
UPDATE user SET username = LEFT(username, 10);
ALTER TABLE user MODIFY COLUMN username VARCHAR(10);

JPA는 "현재 객체 구조에 맞는 테이블을 만든다"는 목적에는 충실하지만, "기존 데이터를 안전하게 보존하면서 점진적으로 구조를 변경한다"는 관점에서는 한계가 있었습니다.

점진적 마이그레이션의 필요성

우리가 필요했던 것은 객체 중심 접근법과 데이터 중심 접근법을 모두 활용할 수 있는 방식이었습니다.

API를 v1 → v2로 체계적으로 관리하는 것처럼, 데이터베이스의 형상(스키마 + 데이터)도 V1 → V2 → V3 형태로 체계적으로 관리할 수 있는 도구가 필요했습니다.

이것이 JPA의 존재에도 불구하고 Flyway를 도입하게 된 배경이 되었습니다.

마무리

API 버저닝 경험을 통해 얻은 가장 큰 깨달음은 "점진적 변경을 시스템 전체에 적용하기 위한 더 넓은 관점"이었습니다.

단순히 JPA에서 Flyway로 도구를 바꾸는 것이 아니라, 점진적 변경 관리라는 사고방식을 데이터베이스 영역으로 확장하는 경험이었습니다. 개발 초기에는 JPA DDL-AUTO의 편의성이 큰 도움이 되었습니다. 하지만 팀이 성장하고 프로젝트가 복잡해지면서 더 체계적인 접근이 필요했습니다. Git이 코드 변경을 관리하고, API 버저닝이 인터페이스 변경을 관리하듯이, 데이터베이스 마이그레이션 도구도 스키마와 데이터 변경을 체계적으로 관리하는 자연스러운 확장선 상에 있었습니다.

협업과 운영 안정성이라는 두 가지 축에서 겪은 구체적인 문제들은 단순한 도구의 문제가 아니라 개발 프로세스 전반의 성숙도와 관련된 이슈였습니다. 결국 일관된 변경 관리 원칙을 시스템 전체에 적용하는 것이 지속 가능한 개발 환경을 만드는 핵심이었습니다. API에서 시작된 점진적 변경을 데이터베이스로 확장한 경험은 향후 다른 영역에서도 동일한 원칙을 적용할 수 있는 기반이 될 것입니다.

메트릭(Metric)

wddy2001 — Tue, 29 Jul 2025 20:45:05 +0900

메트릭이 무엇이길래, 모니터링 환경까지 구성해야할까?

모니터링이란?

모니터링은 시스템의 상태와 성능을 지속적으로 관찰, 추적하는 과정입니다.

모니터링의 주요 목적은 3가지로 나눌 수 있습니다.

문제가 발생하기 전, 미리 감지하기
문제가 발생했을 때, 빠르게 원인 파악하기
시스템 전반 성능 추세를 파악하여, 향후 계획 세우기

이를 복잡한 소프트웨어 시스템에서 만족하기 위해서는, 시스템 내부의 상태를 외부에서 출력값만으로 얼마나 잘 이해할 수 있는 지가 중요한 개념입니다. 이를 관찰 가능성(Observbility)이라고 합니다.

관찰 가능성의 세 기둥

관찰 가능성은 크게 메트릭, 로그, 트레이싱으로 이야기할 수있습니다.

이 3가지 개념은 시스템을 이해하기 위해 유기적으로 연결됩니다.

메트릭

메트릭은 시스템의 특정 측면을 수치로 표현한 측정값으로, 시간에 따른 시스템 상태를 정략적으로 나타내는 데이터입니다.

연속적이고 집계 가능한 데이터를 모으기에, 시간에 따른 패턴과 추세 파악에 용이합니다.

시스템의 "맥박"을 측정하는 계기판 역할로, 문제의 존재와 심각성을 알려줍니다.

로그

시스템에서 발생하는 개별 이벤트들을 시간 순서대로 기록한 것으로, 각 사건의 맥락과 세부 사항을 담고 있는 데이터입니다.

불연속적인 이벤트 기반 데이터이며, 구체적인 맥락 정보를 포함합니다.

문제의 근본 원인과 구체적인 맥락을 제공하는 "현미경" 역할입니다.

트레이싱

하나의 요청이 여러 서비스나 컴포넌트를 거치면서 처리되는 전체 경로를 추적한 것으로, 분산 시스템에서 요청의 흐름을 시각화하는 데이터입니다.

요청 전체의 생명 주기를 추적하고, 서비스 간 의존성과 상호작용을 시각화합니다. 이때, 각 단계별 처리 시간과 성능을 측정합니다.

복잡한 분산 시스템에서 요청의 "여행 경로"를 추적하여 병목 지점과 장애 원인을 파악합니다.

세 요소의 상호 보완적 관계

이 세 요소들은 각각 다른 관점에서 시스템을 바라보며 함께 작동할 때 완전한 관찰 가능성을 제공합니다.

예를 들어, 메트릭으로 API 응답 시간 증가를 감지하고, 트레이싱으로 어느 서비스에서 지연이 발생했는지 파악한 후, 로그로 해당 서비스의 구체적인 오류 원인을 분석하는 방식으로 활용됩니다.

메트릭(Metrics)의 정의

시스템의 특정 측면을 수치로 표현한 측정값으로, 시간에 따른 시스템 상태를 정량적으로 나타내는 데이터입니다.

연속적이고 집계 가능한 수치 데이터
시간에 따른 패턴과 추세 파악에 용이
실시간 모니터링과 자동화된 알림 설정 가능

메트릭의 "연속적" 특성은 실제로는 불연속적 샘플링의 연속적 해석입니다. 1초마다 CPU 사용률을 측정하더라도, 그 사이의 마이크로초 단위 변화는 놓치게 됩니다. 이는 샘플링 주기가 곧 관찰 가능한 문제의 최소 단위가 됩니다.

메트릭의 분류체계

데이터 타입별 분류

Counter (카운터)

정의: 계속 증가하는 값
실무 활용: 총 요청 수, 오류 발생 횟수
핵심 가치: rate(비율) 계산 → "초당 요청 수"

Counter의 진짜 위력은 미분적 사고("변화량 ÷ 시간 = 속도")에 있습니다. 총 요청 수(적분값)를 시간으로 미분하면 초당 요청 수(순간 변화율)가 나오는데, 이것이 실제 시스템 부하를 나타내는 핵심 지표입니다.

여기서 "미분적 사고"는 단순히 "1시간 동안 얼마나 늘었나?"를 계산하는 것입니다. "변화량 ÷ 시간 = 속도"를 의미, 즉 지금 서버가 얼마나 바쁜지를 알 수 있습니다.

Gauge (게이지)

정의: 현재 시점의 값
실무 활용: CPU 사용률, 메모리 사용량, 현재 활성 사용자 수
역할: 시스템의 "지금 이 순간" 상태 스냅샷

Gauge는 상태의 절대값을 나타내므로, 임계값 기반 알림의 주요 대상입니다. 하지만 단순한 임계값보다는 변화율을 함께 고려해야 합니다. CPU 사용률 80%라도 안정적이면 문제없지만, 급격히 증가하는 추세라면 조기 경고가 필요합니다.
"지금 상태 + 변화 추세 = 미래 예측"이 핵심입니다.

Histogram (히스토그램)

정의: 값의 분포를 보여주는 측정값
중요성: 평균 지연 시간이 100ms인 웹 서비스에서 1%의 요청은 쉽게 5초가 걸릴 수 있음
해결책: 지연 시간별로 버킷화된 요청 수를 수집 (히스토그램 렌더링에 적합)

Histogram은 통계학의 분포 이론을 시스템 모니터링에 적용한 것입니다.
특히 롱테일 분포(Long-tail Distribution) 특성을 가진 시스템에서 평균의 함정을 피할 수 있게 해줍니다.

"분포 이론"이란 간단히 말해서:

데이터가 어떻게 퍼져있는지 보는 것
예: 웹사이트 응답시간이 대부분 100ms인데, 가끔 5초 걸리는 경우들이 있다

"평균의 함정":

99번은 100ms, 1번은 5초 → 평균 149ms
하지만 실제로는 대부분 100ms인데 평균만 보면 "149ms 정도 걸리는구나" 착각
평균이 실제 사용자 경험을 제대로 반영 못함

"롱테일 분포":

대부분은 빠른데(100ms), 소수가 엄청 느림(5초)
마치 공룡 꼬리처럼 길게 늘어진 모양의 데이터 분포
인터넷 서비스에서 매우 흔한 패턴

결국 "평균에 속지 말고, 실제 사용자들이 어떤 경험을 하는지 정확히 파악하자"는 것입니다!

SRE의 4가지 황금 신호 (Golden Signals)

메트릭 타입: "어떻게 측정할 것인가?" (방법론)
황금 신호: "무엇을 측정할 것인가?" (목적론)

설계 원칙:

황금 신호를 먼저 정의하고, 적합한 메트릭 타입을 선택
단일 황금 신호도 복수 메트릭 타입으로 다각도 측정
황금 신호 간 상관관계를 메트릭 설계에 반영
메트릭 타입의 한계를 다른 타입으로 보완

1) Latency (지연 시간)

정의: 요청을 처리하는 데 걸리는 시간
핵심: 성공/실패 요청 구분 필요
실무 주의점: 느린 오류는 빠른 오류보다 더 나쁨

Latency는 사용자 체감 성능의 직접적 지표입니다. 하지만 성공/실패 구분이 중요한 이유는 실패의 패턴을 이해하기 위함입니다. 빠른 실패(Fail-fast)는 시스템 보호 메커니즘이지만, 느린 실패는 자원 고갈의 신호일 수 있습니다.

메트릭 타입과의 연계점: Latency는 반드시 Histogram으로 측정해야 의미가 있습니다. 평균이나 단순 게이지로는 꼬리 분포의 문제를 놓치기 때문입니다.

2) Traffic (트래픽)

정의: 시스템에 가해지는 수요의 양
측정 방식:
- 웹 서비스: 초당 HTTP 요청 수
- 스트리밍: 네트워크 I/O 속도
- 저장소: 초당 트랜잭션 수

심화 이해: Traffic은 단순한 부하량이 아니라 비즈니스 활동의 대리 지표입니다. 트래픽 패턴 분석을 통해 예측적 스케일링이 가능하며, 이상 트래픽 탐지로 DDoS나 버그로 인한 무한루프를 조기 발견할 수 있습니다.

메트릭 타입과의 연계점 : Traffic 메트릭은 본질적으로 Counter 타입 메트릭의 변화율입니다.

3) Errors (오류)

정의: 실패한 요청의 비율
세 가지 유형:
- 명시적: HTTP 500s
- 암시적: 잘못된 콘텐츠와 함께한 HTTP 200
- 정책적: 약속된 응답 시간 초과

심화 이해: Error 분류의 핵심은 관찰 가능성의 계층 구조를 보여줍니다. 명시적 오류는 프로토콜 레벨에서, 암시적 오류는 애플리케이션 레벨에서, 정책적 오류는 비즈니스 레벨에서 감지됩니다.

메트릭 타입과의 연계점 : 총 오류 수는 Counter로 측정하고, 오류율 = error_counter / total_requests_counter로 계산합니다.

4) Saturation (포화도)

정의: 서비스가 얼마나 "가득 찬" 상태인지
핵심: 지연 시간 증가는 종종 포화도의 선행 지표
측정: 99th percentile 응답 시간으로 조기 신호 획득

심화 이해: Saturation은 대기열 이론(Queueing Theory)의 실무 적용입니다. 시스템의 처리 능력 한계에 가까워지면 대기열이 길어지고, 이는 지연 시간 증가로 나타납니다. 99th percentile을 사용하는 이유는 평균의 함정을 피하면서도 소수 사용자의 극단적 경험을 포착하기 위함입니다.

메트릭 타입과의 연계점 : 지연 시간 증가는 종종 포화도의 선행 지표이므로, Gauge로 측정한 자원 사용률과 Histogram으로 측정한 지연 시간이 상관관계를 보입니다.

대기열 이론 (Queueing Theory)
핵심: 서버가 바빠지면 요청들이 줄 서서 기다리게 됨
메트릭 적용: 시스템이 포화 상태에 가까워지면 대기 시간이 급격히 증가
실무 의미: CPU 사용률 80%는 괜찮아도 95%는 위험한 이유

SLI/SLO - 메트릭의 비즈니스 적용

SLI (Service Level Indicator)

본질: 서비스 상태를 측정하는 "체온계"
SRE 연계: 4가지 황금 신호를 SLI로 활용
실무 원칙: 사용자 경험과 직결되는 지표 선택

SLI 선택의 핵심은 사용자 여정(User Journey) 매핑입니다. 단일 기술 메트릭이 아니라 전체 사용자 경험을 대표하는 복합 지표여야 합니다. 예를 들어, 전자상거래에서는 "검색 → 상품 조회 → 장바구니 → 결제"의 각 단계별 SLI가 필요합니다.

SLO (Service Level Objective)

본질: 비즈니스가 사용자에게 하는 "약속의 기준선"
SRE 철학: 4가지 황금 신호를 측정하고 문제 시 페이지를 보내면 적절한 모니터링
실무 예시: "API의 95%는 100ms 이내 응답" (기술적 지표 지양)

SLO는 확률론적 품질 보장의 개념입니다. 100% 가용성은 비현실적이므로, 허용 가능한 실패율을 명시합니다. 이는 Error Budget 개념으로 이어지며, 남은 오류 예산 내에서는 혁신적 배포를, 예산 소진 시에는 안정성 우선으로 전략을 바꾸는 근거가 됩니다.

메트릭 설계의 핵심 원칙

SRE의 단순성 원칙

실제 인시던트를 가장 자주 잡는 규칙은 가능한 한 단순하고, 예측 가능하며, 신뢰할 수 있어야 합니다.

단순성 원칙은 인지 부하(Cognitive Load) 이론에 기반합니다. 복잡한 메트릭과 알림은 경보 피로(Alert Fatigue)를 야기하며, 결국 진짜 문제를 놓치게 만듭니다. 이는 파레토 법칙(80/20 Rule)과도 연결되어, 핵심 20%의 메트릭이 80%의 문제를 잡아낸다는 실무 경험과 일치합니다.

파레토 법칙 (80/20 Rule)
핵심: 전체 결과의 80%가 원인의 20%에서 나온다
메트릭 적용: 핵심 20%의 메트릭이 80%의 문제를 잡아낸다
실무 의미: 모든 메트릭을 다 보지 말고 정말 중요한 것만 집중하자

메트릭 설계 시 고려해야할 문제 사항

카디널리티 관리

문제: method(4) × status(10) × endpoint(1,000,000) = 4천만 개 시계열
SRE 해결책: 거의 실행되지 않는 데이터 수집은 제거 대상
실무 전략: 패턴 정규화, 샘플링 적용, 필수 차원만 포함

카디널리티 폭발은 조합론적 복잡성의 실무 사례입니다. 각 차원이 추가될 때마다 곱셈적으로 증가하는 특성 때문에, 차원 선택이 아키텍처 설계 결정이 됩니다.

꼬리 분포 (Tail Distribution) 고려

SRE 경고: 평균을 기반으로 모니터링 시스템 설계하는 것의 위험성
실무 해결: 95%는 30ms, 5%는 2초인 상황에서 평균 100ms의 함정 인식
방법: 히스토그램을 통한 분포 측정

심화 이해: 꼬리 분포 문제는 분산 시스템의 본질적 특성을 보여줍니다. 부분 장애(Partial Failure)가 일상적인 환경에서, 소수의 극단값이 전체 사용자 경험을 좌우할 수 있습니다.

메트릭의 운영상 한계와 보완책

Symptoms vs Causes

메트릭의 역할: "무엇이 망가졌는가"(증상) 답변
한계: "왜 망가졌는가"(원인)는 로그가 필요
보완: 로그, 트레이싱과의 유기적 연계

이는 의학의 진단 과정과 정확히 일치합니다. 체온(메트릭)이 높다는 것은 증상이고, 감염원(로그)을 찾고, 감염 경로(트레이싱)를 추적해야 완전한 진단이 됩니다.

성능과 비용 트레이드오프

SRE 해상도 원칙: 시스템의 다양한 측면은 다양한 세분화 수준으로 측정
실무 문제: 메트릭 수집 자체가 애플리케이션 성능에 영향
해결: 내부 샘플링 후 외부 시스템에서 집계

심화 이해: 이는 하이젠베르크의 불확정성 원리의 시스템 버전입니다. 관찰 행위 자체가 시스템에 영향을 미칩니다. 프로파일링 오버헤드가 실제 성능을 왜곡할 수 있으므로, 적응적 샘플링 전략이 필요합니다.

데이터 정확성과 신뢰성

분산 시스템 문제: 네트워크 분할로 인한 데이터 누락/지연
SRE 접근: 정확성 vs 실시간성 트레이드오프 인정
실무 대응: 시계 동기화, 부분 집계 전략

이는 CAP 이론의 모니터링 적용판입니다. 네트워크 분할 상황에서 일관성(Consistency) vs 가용성(Availability)을 선택해야 하듯, 메트릭에서도 정확성 vs 실시간성을 선택해야 합니다.

CAP 이론
핵심: 분산 시스템에서 일관성(C), 가용성(A), 분할 허용성(P) 중 2개만 보장 가능
메트릭 적용: 네트워크 문제 시 정확성 vs 실시간성 중 선택해야 함
실무 의미: 완벽한 모니터링은 불가능하니 트레이드오프를 인정하자

메트릭의 활용 전략

알림 설계 원칙

긴급하고, 실행 가능하며, 사용자에게 보이는 조건 감지
사용자에게 부정적 영향을 미치는 상황 확실히 표시
조치 가능한 알림 설계

이는 신호 검출 이론(Signal Detection Theory)의 적용입니다. True Positive(올바른 알림) vs False Positive(거짓 알림)의 균형을 맞춰야 하며, ROC 곡선을 통해 최적 임계값을 찾을 수 있습니다.

제거 기준

수집되지만 대시보드에 노출되지 않거나 알림에서 사용되지 않는 신호는 제거 후보입니다.

심화 이해: 이는 린(Lean) 방법론의 낭비 제거와 일치합니다. 사용되지 않는 메트릭은 기술 부채가 되어 시스템 복잡성만 증가시킵니다.

린(Lean) 방법론
핵심: 낭비 제거를 통한 효율성 극대화
메트릭 적용: 사용하지 않는 메트릭은 낭비이므로 제거하자
실무 의미: 수집만 하고 안 쓰는 데이터는 복잡성만 늘린다

비용 대비 효과

직접 비용: 인프라, 라이선스, 엔지니어링 시간
간접 효과: 장애 예방, 개발 생산성 향상 (정량화 어려움)
SRE 접근: 예방적 가치의 장기적 관점 적용

이는 예방의 경제성을 이야기합니다. 질병을 치료하는 비용과 예방하는 비용의 비교처럼, 장애 대응 비용 vs 모니터링 비용을 비교해야 합니다.

결론

메트릭은 SRE의 4가지 황금 신호를 중심으로 한 시스템 상태의 정량적 측정 도구로, 단순성과 실용성을 강조하면서 로그, 트레이싱과 함께 완전한 관찰 가능성을 구성하는 핵심 요소입니다. 기술적 측정을 넘어 사용자 경험과 비즈니스 약속을 연결하는 다리 역할이며, 안정적이고 효과적인 시스템 운영을 가능하게 하는 도구입니다.

메트릭은 결국 복잡계 이론(Complex Systems Theory)의 실무 적용입니다. 분산 시스템이라는 복잡계에서 창발적 행동(Emergent Behavior)을 관찰하고 예측하기 위한 도구이며, 피드백 루프를 통해 시스템을 자동으로 조절하는 "메트릭 → 알림 → 대응 → 개선의 순환 구조"의 핵심 요소입니다. 단순한 숫자의 나열이 아니라, 시스템의 건강성을 유지하는 면역 체계이자 진화를 위한 적응 메커니즘으로 이해해야 합니다.

참고 자료

러버덕 후기

wddy2001 — Sun, 4 May 2025 14:58:08 +0900

레벨 2에서는 다른 크루의 우테코 생활을 도와주는 카인드 러버덕이 생겼습니다.
러버덕이 되어 다른 크루의 학습이나 고민을 자유롭게 들어보세요..!

우테코의 레벨 1을 끝마치고 레벨 2를 시작하며 카인드 러버덕 제도가 도입되었습니다.

러버덕에 지원하고 2주가 지나, 이 경험을 통해 발견한 제 자신의 모습을 정리해보고자 합니다.

이 과정에서 발견한 '모범생'으로서의 한계에 대해서도 함께 이야기해보려 합니다.

러버덕을 신청한 이유

레벨 1을 끝내면서 느낀 점은 "환경의 중요성"이었습니다.

러버덕 활동은 "어떻게 이러한 긍정적 환경을 스스로 만들 수 있을까?"란 고민에서 시작했습니다.

"환경의 중요성"을 깨달은 이유는 우테코에서 매너리즘에서 빠져나올 수 있었기 때문입니다.

이전까지는 개발자 진로와 목표에 대한 진정한 원동력을 찾지 못했습니다.

정말 개발자가 되고 싶다는 마음이 있었을까? 이런 의문이 끊임없이 들었습니다.

우테코 환경은 제 매너리즘을 넘어서 학습에 대한 열정을 다시 불러일으켰습니다.

미션이라는 큰 줄기에서 의견이 나뉘었고, 이에 관해 깊이 있는 토론을 할 수 있었습니다.

혼자 공부할 때보다 몇 배 더 많이 배우고 성장했으며, 무엇보다 즐거웠습니다.

하지만 방학이 되어 혼자 공부하게 되니, 다시 예전의 수동적인 상태로 돌아가더라고요.

이 경험을 통해 스스로가 환경에 크게 영향받는 수동적인 사람이란 것을 깨달았습니다.

동시에 적절한 환경 속에서는 능동적인 사람으로 변화할 수 있다는 가능성도 발견했습니다.

바로 이 지점이 매너리즘을 극복할 열쇠였습니다.

내가 되고 싶었던 것은 능동적인 사람이었구나
그렇다면 우테코라는 환경 없이도, 능동적인 사람이 되려면 어떻게 해야 할까?
단순히 좋은 환경을 찾아다니는 것만으로는 부족하지 않을까?
내가 직접 성장을 위한 환경을 만들 수는 없을까?

이러한 질문들이 러버덕 활동을 시작한 진짜 계기가 되었습니다.

모범생을 발견하다

"내가 직접 사람들을 참여하는 환경을 만든다"

처음 세웠던 이 목표는 방향이 잘못되었다는 것을 깨달았습니다.

코치님과 다른 러버덕들의 피드백을 통해, 이 목표 뒤에 숨은 제 모습을 들여다보게 되었습니다.

왜 나는 수동적인지, 능동적이 되기 위해 진정으로 필요한 것은 무엇인지 고민하게 되었습니다.

토의하는 모습이 너무 부럽지만, 아직 배우지 못한 내용이 많아 참여할 수 없다.
어떻게 저렇게 깊게 공부할 수 있는 것인지 모르겠다.
일단 내 공부를 끝내야만 할 것 같다.

러버덕 활동을 시작하며, 비슷한 학습 고민을 가진 크루들을 만났습니다.
그리고 그들이, 위와 같이 저와 유사한 고민을 하고 있다는 사실을 발견했습니다.

우리 모두 능동적인 환경에 속하고 싶었지만, 그런 환경에 기여할 준비가 되지 않았다는 불안감을 공유하고 있었습니다.

스스로에게 조언하듯 그들과 대화했지만, 근본적인 해결책은 찾지 못했습니다.

고민을 안고 코치님과 다른 러버덕들에게 솔직한 피드백을 구했습니다.

90점의 벽: 안전한 목표 설정의 함정

피드백 끝에, 학습 고민을 가진 크루를 찾아다닌 진짜 이유가 드러났습니다.

"학습할 환경을 만든다"는 표면적 목표가 아니라, "나와 같은 고민을 함께 해결하고 싶다"는 내면의 바람이었습니다.

비슷한 고민을 함께 해결하면서 제 자신의 고민도 풀고 싶었던 것입니다.

이 과정에서 발견한 중요한 통찰은, 제가 스스로를 능동적으로 바꿀 수 없다는 두려움을 품고 있다는 점이었습니다.
그래서 "나를 능동적으로 바꾸는" 어려운 도전 대신, "환경을 바꾸는" 우회로를 택했던 것입니다.
이것이 바로 제가 수동적으로 행동하는 근본적인 이유이자, 코치님들이 지적한 "모범생"의 본질이었습니다.

저는 목표를 선정할 때, 기본 점수를 설정한다는 것을 깨달았습니다.

적어도 90점은 받을 수 있는 목표를 세우고, 부족한 10점만을 위해 노력합니다.

120점 달성이 가능했던 도전적인 목표들도, 실패 가능성이 없었기에 선택해왔던 것 같았습니다.
즉, 실패할 리스크가 있는 목표는 항상 피해던 것입니다.

그렇게 저는 항상 이길 수 있는 게임만 하는 '모범생'이 되었습니다.

반면, 우테코에서 활발히 토론하던 시기에는 이런 안전한 목표 설정 방식에서 벗어나 있었습니다.

완벽하게 이기지 못하더라도 당장 필요한 해답을 찾았고, 그 해답을 통해 다음 단계로 나아갔습니다.

40점으로 시작하더라도, 과정에서 60점을 더 배워가며 성장할 수 있었습니다.

바로 이 '90점의 벽'이 매너리즘에 빠졌던 근본 원인이자, 진정한 능동성을 찾는 열쇠라는 것을 깨달았습니다.

어떻게 이 90점의 벽을 허물 것인가?

앞으로의 과제는 분명합니다.

실패할 가능성이 있더라도, 도전적인 목표를 세우고 추구하는 법을 배워야 합니다.

구체적으로는

1. 매주 하나씩 "성공 확률 60%" 정도의 도전적 목표를 세우기

2. 실패를 감수하고 무엇을 해냈는 지, 그 사실에 집중하기

3. 가장 중요한 것은 꾸준한 피드백으로 목표의 방향을 점검하기

이 접근법은 아직 구체화 단계에 있습니다만, 방향성은 분명합니다.

정확한 방법을 모를 때는 다양한 시도와 꾸준한 피드백이 최선의 전략입니다.
피드백을 주고받으며 방향을 조정해나가는 과정 자체가 제게 필요한 성장의 과정이었습니다.

이제 제 질문은 바뀌었습니다.

새로운 목표는 정말 내 성장을 위한 것일까?
안전한 목표가 아니라, 나를 성장시킬 목표를 만들자.

앞으로의 러버덕 활동에서 좀 더 성장해가는 제 모습을 기대하며,
회고글을 마무리하겠습니다.