std → absl 마이그레이션 전략

#한 번에 다 바꾸지 않는다

Abseil은 std의 보완 이지 대체가 아니다. 도입은 영역별로 점진적이며 가치가 명확한 곳부터 한다.

권장 우선순위:

1. 새 코드만 Abseil 사용 — 기존 코드는 그대로
2. 에러 처리 — absl::Status / absl::StatusOr 도입
3. 컨테이너 hot spot — flat_hash_map 등 성능 측정 가능한 곳
4. 문자열 — StrCat, StrSplit, string_view
5. 시간 — absl::Time / Duration
6. 나머지 유틸 — flags, log, random

#1단계 — 새 코드 한정 도입

가장 안전한 시작.

1
// 기존 module — 손대지 않음
2
class LegacyService {
3
    std::unordered_map<int, User> users_;   // 그대로
4
};
5

6
// 새 module — Abseil 사용
7
class NewService {
8
    absl::flat_hash_map<int, User> users_;
9
};

빌드에 absl dependency를 추가해 두고, 사용은 점진. 코드 리뷰에서 “새 코드는 abseil 권장” 컨벤션을 명문화.

#2단계 — 에러 처리 통일

가장 가치가 큰 마이그레이션. optional + error_code 혼재된 인터페이스를 StatusOr로 통일.

1
// before
2
struct GetResult {
3
    bool ok;
4
    User user;
5
    std::string error_message;
6
};
7
GetResult GetUser(int id);
8

9
// after
10
absl::StatusOr<User> GetUser(int id);

매크로(ASSIGN_OR_RETURN, RETURN_IF_ERROR)가 호출 측 코드를 크게 줄여 준다.

1
// before
2
GetResult ProcessFlow() {
3
    auto a = GetUser(1);
4
    if (!a.ok) return {.ok = false, .error_message = a.error_message};
5
    auto b = GetUser(2);
6
    if (!b.ok) return {.ok = false, .error_message = b.error_message};
7
    return Combine(a.user, b.user);
8
}
9

10
// after
11
absl::StatusOr<Combined> ProcessFlow() {
12
    ASSIGN_OR_RETURN(User a, GetUser(1));
13
    ASSIGN_OR_RETURN(User b, GetUser(2));
14
    return Combine(a, b);
15
}

#3단계 — 컨테이너 hot spot

벤치마크 결과 1-2배 차이 나는 hot path만 우선 치환.

1
// before — profile에서 unordered_map이 hot
2
std::unordered_map<std::string, Counter> hits_;
3

4
// after — flat_hash_map
5
absl::flat_hash_map<std::string, Counter> hits_;

모든 unordered_map을 한 번에 바꾸지 않는다. 그런 wholesale 변경은 PR이 비대해지고 부작용 검증이 어렵다. 한 hot path씩.

이때 주의 — flat_hash_map은 iterator invalidation 규칙이 더 엄격 (Part 5-01). 기존 코드가 iterator 유지를 가정하면 node_hash_map으로.

#4단계 — string 도구

1
// before
2
std::string result;
3
for (int i = 0; i < n; ++i) {
4
    result += std::to_string(values[i]) + ", ";
5
}
6

7
// after
8
std::string result = absl::StrJoin(values, ", ");

1
// before
2
std::vector<std::string> tokens;
3
boost::split(tokens, input, boost::is_any_of(","));
4

5
// after
6
std::vector<std::string> tokens = absl::StrSplit(input, ',');

치환이 국소적 이라 작은 PR로 분할하기 쉽다.

#5단계 — Time

1
// before — chrono boilerplate
2
void Wait(std::chrono::milliseconds ms);
3
Wait(std::chrono::seconds(5));
4

5
// after
6
void Wait(absl::Duration d);
7
Wait(absl::Seconds(5));

Chrono ↔ Abseil 변환은 absl::FromChrono / absl::ToChrono*로 가능.

1
absl::Duration d = absl::FromChrono(std::chrono::seconds(5));
2
auto chrono_d = absl::ToChronoMilliseconds(d);

라이브러리 경계에서 변환하고 내부는 한 시스템으로 통일.

#ABI 격리 — 헤더 인터페이스 분리

라이브러리를 제공하는 입장에서는 공개 헤더에 Abseil 타입 노출 여부 가 큰 결정이다.

1
// 회피 — 공개 헤더에 absl 타입
2
#include "absl/container/flat_hash_map.h"
3
class MyLib {
4
public:
5
    void Process(const absl::flat_hash_map<int, Data>& data);
6
};

사용자가 우리와 같은 Abseil 버전 을 써야 한다. ABI 격리가 깨진다.

1
// Good — 공개 헤더는 std/raw types
2
#include <unordered_map>
3
class MyLib {
4
public:
5
    void Process(const std::unordered_map<int, Data>& data);
6
private:
7
    class Impl;
8
    std::unique_ptr<Impl> impl_;   // pimpl
9
};
10

11
// my_lib.cc — 구현은 자유롭게 absl
12
#include "absl/container/flat_hash_map.h"
13
class MyLib::Impl {
14
    absl::flat_hash_map<int, Data> cache_;
15
};

내부 cache는 빠른 flat_hash, 외부 인터페이스는 std 호환.

#마이그레이션 도구 — clang-tidy / refactoring scripts

Abseil은 공식 자동 마이그레이션 도구를 일부 제공한다(/tools/ 디렉터리). 다만 대규모 코드베이스용이고, 보통은 IDE의 find & replace + 컴파일 에러 활용 이 실용적.

1
# 예: unordered_map → flat_hash_map (대량 변환)
2
rg -l "std::unordered_map" src/ | xargs sed -i \
3
    -e 's/std::unordered_map/absl::flat_hash_map/g' \
4
    -e '/^#include/a #include "absl/container/flat_hash_map.h"'
5
# 그 후 컴파일·테스트 반복

자동 변환 후 반드시 테스트 및 수동 리뷰. iterator invalidation 같은 의미 차이는 sed가 못 잡는다.

#”Living at Head” — 버전 관리

Abseil은 LTS와 HEAD 두 가지 트랙(Part 1-04). 새 도입은 LTS로 시작, 안정화되면 HEAD 추적 평가.

#마이그레이션 PR 패턴

권장 PR 분할:

1. 빌드 dependency 추가 — absl 링크. 코드는 안 바꿈.
2. 새 코드만 absl — 컨벤션 문서화.
3. 에러 처리 — module별로 Status 도입. 1 module = 1 PR.
4. hot path 컨테이너 — 벤치마크 첨부.
5. string/time — 영역별 작은 PR.
6. legacy 호환 layer 정리 — 마지막.

대형 wholesale PR은 리뷰가 마비된다. 각 PR이 독립적으로 의미 있게 작동 하도록 분할.

#실패 패턴 — 흔한 마이그레이션 실수

1
// 실패 — 임시 절충
2
namespace mylib {
3
template <typename K, typename V>
4
using HashMap = absl::flat_hash_map<K, V>;   // ❌ 별칭이 abseil ABI 노출
5
}

별칭이 우리 공개 API 가 되면 사용자 코드가 그 타입에 의존. Abseil 버전 업그레이드 시 충돌. 차라리 명시적 import.

1
// 실패 — std와 absl 혼재된 컨테이너
2
absl::flat_hash_map<std::string, int> a;
3
std::unordered_map<std::string, int> b;
4
a.insert(b.begin(), b.end());   // ❌ 컨테이너 종류가 다른 인터페이스

내부적으로 두 컨테이너가 섞이면 변환 비용 이 자주 발생. 모듈별로 하나만 선택.

#정리

• 전부 한 번에 바꾸지 말 것. 가치 큰 영역부터 점진.
• 우선순위: 새 코드 → Status → 컨테이너 hot spot → string → Time → 나머지.
• 공개 헤더는 std/raw 타입 — Abseil 노출은 ABI 격리 깨짐.
• pimpl 패턴으로 외부 std, 내부 Abseil 분리.
• PR 분할: 1 PR = 1 module, 1 영역.

#시리즈 마무리

Part 1~13으로 Google이 사내 코드 리뷰에서 무엇을 보는가를 컴포넌트 단위로 정리했다. Abseil은 도구 모음이 아니라 코드 리뷰 컨벤션의 코드화에 가깝다. 같은 문제를 같은 방식으로 풀면 큰 코드베이스의 변경 비용이 줄어든다.

#다음 편

Part 14~16에서는 본 시리즈에서 다루지 않은 모듈을 추가로 본다. Part 14-01 — Cleanup부터 시작해 algorithm wrapper, function_ref/any_invocable, Cord, charconv, stacktrace, CRC32C, PeriodicSampler까지.

#관련 항목

• Part 14-01: Cleanup — RAII scope guard
• Part 15-01: Cord — 분산 시스템용 문자열
• Part 16-01: Stacktrace / Symbolize — crash 분석
• Part 1-01: Abseil 개요
• Part 13-01: Google 스타일의 Abseil 사용 패턴
• Part 13-02: 자주 보는 anti-pattern
• Folly Code Review 시리즈 — Meta의 같은 종류 라이브러리
• 원문 — Abseil compatibility