스토아 철학과 엔지니어링 의사결정: 통제 이분법, 프리모템, 네거티브 시각화로 더 나은 결정 내리기

상황: 프로덕션 데이터베이스 성능 저하 알림

통제 가능한 것:
  - 쿼리 분석 및 최적화
  - 커넥션 풀 설정 조정
  - 읽기 복제본으로 트래픽 분산
  - 팀원에게 상황 공유
  - 롤백 결정

통제 불가능한 것:
  - 이미 발생한 성능 저하
  - 사용자들이 이미 경험한 지연
  - 클라우드 제공자의 기반 인프라 상태
  - 비즈니스 측의 반응

행동 계획: 통제 가능한 것에 집중하고, 나머지는 수용한다.

오늘 내가 마주할 수 있는 도전은 무엇인가?
  - [상황 나열]

그 중 내가 통제할 수 있는 것은?
  - [통제 가능 항목]

통제할 수 없는 것에 에너지를 쓰고 있지는 않은가?
  - [점검]

오늘 내가 집중해야 할 행동은?
  - [구체적 행동 계획]

프리모템 워크숍 진행 가이드

1단계: 설정 (5분)
  "지금부터 6개월이 지났습니다.
   우리 프로젝트는 완전히 실패했습니다.
   왜 실패했을까요?"

2단계: 개별 작성 (10분)
  각자 포스트잇에 실패 원인을 적는다.
  최소 5개 이상 작성한다.
  기술적, 조직적, 외부 요인 모두 포함한다.

3단계: 공유 및 분류 (15분)
  모든 원인을 공유하고 카테고리별로 분류한다.
  중복을 합치고, 빠진 것을 추가한다.

4단계: 우선순위 결정 (10분)
  가능성(Likelihood)과 영향도(Impact)로 순위를 매긴다.
  상위 5개 리스크를 선정한다.

5단계: 완화 계획 (20분)
  각 리스크에 대한 구체적 완화 방안을 수립한다.
  담당자와 기한을 지정한다.

네거티브 시각화 시스템 설계 체크리스트

데이터베이스 영역:
  - 마스터 DB가 다운되면?
  - 복제 지연이 30분 이상이면?
  - 디스크가 100% 차면?
  - 백업이 손상되었으면?

네트워크 영역:
  - DNS가 응답하지 않으면?
  - 로드 밸런서가 다운되면?
  - 특정 가용 영역이 통째로 장애이면?
  - 리전 간 네트워크가 끊기면?

애플리케이션 영역:
  - 메모리 누수가 발생하면?
  - 무한 루프에 빠지면?
  - 써드파티 API가 30초간 응답이 없으면?
  - 배포 직후 크래시가 발생하면?

인적 영역:
  - 핵심 개발자가 갑자기 퇴사하면?
  - 온콜 담당자가 연락이 안 되면?
  - 새 팀원이 실수로 프로덕션 DB를 삭제하면?

프로젝트: 모놀리스에서 마이크로서비스로 전환 (예상 기간 12개월)

프리모템 결과 - 상위 실패 원인:

1. 데이터 일관성 문제 (가능성: 높음, 영향: 치명적)
   - 완화: 이벤트 소싱 패턴 도입, 사가 패턴 학습
   - 담당: 백엔드 리드
   - 기한: 2개월 이내

2. 팀 역량 부족 (가능성: 중간, 영향: 높음)
   - 완화: 외부 교육, 파일럿 서비스로 시작
   - 담당: 엔지니어링 매니저
   - 기한: 1개월 이내

3. 운영 복잡도 폭발 (가능성: 높음, 영향: 높음)
   - 완화: 표준 서비스 템플릿, 중앙 관측 플랫폼
   - 담당: 플랫폼 팀
   - 기한: 3개월 이내

4. 비즈니스 요구사항과 병행 개발 충돌 (가능성: 높음, 영향: 중간)
   - 완화: 스트랭글러 패턴, 점진적 전환
   - 담당: 프로덕트 매니저 + 테크 리드
   - 기한: 지속적

5. 네트워크 장애 전파 (가능성: 중간, 영향: 높음)
   - 완화: 서킷 브레이커, 벌크헤드 패턴
   - 담당: 인프라 팀
   - 기한: 파일럿 단계

엔지니어링 의사결정 저널 템플릿

날짜: YYYY-MM-DD

오늘의 주요 결정:
  1. [결정 내용]
     - 배경: [왜 이 결정이 필요했는가]
     - 선택지: [고려한 대안들]
     - 최종 선택: [선택한 것과 이유]
     - 불확실성: [확신하지 못하는 부분]
     - 검증 시점: [언제 이 결정을 재평가할 것인가]

감정 점검:
  - 오늘 감정적으로 반응한 순간이 있었는가?
  - 그 반응은 적절했는가?
  - 다음에는 어떻게 대응할 것인가?

배운 것:
  - 기술적으로 새로 알게 된 것
  - 사람 관리에서 깨달은 것
  - 프로세스 개선 아이디어

내일 집중할 것:
  - [최우선 과제]

# ADR-0042: 캐시 레이어에 Redis 대신 Memcached 선택

## 상태

승인됨

## 맥락

주문 서비스의 읽기 성능 개선이 필요하다.
현재 평균 응답 시간 200ms를 50ms 이하로 줄여야 한다.

## 고려한 대안

1. Redis - 풍부한 데이터 구조, 영속성 지원
2. Memcached - 단순한 키-값, 멀티스레드, 높은 처리량
3. 로컬 캐시(Caffeine) - 네트워크 없음, 일관성 문제

## 결정

Memcached를 선택한다.

## 근거

- 캐시 용도는 단순 키-값 조회뿐이다
- Redis의 풍부한 기능이 필요하지 않다
- Memcached의 멀티스레드 아키텍처가 우리 워크로드에 적합하다
- 팀 내 Memcached 운영 경험이 있다

## 스토아적 성찰 (통제 이분법 적용)

- 통제 가능: 캐시 설정, TTL 정책, 적중률 모니터링
- 통제 불가: 트래픽 패턴 변화, 클라우드 서비스 가격 변동
- 수용 사항: 완벽한 선택은 없다. Memcached가 한계를 보이면
  그때 Redis로 전환한다. 미래의 변화를 두려워하지 않는다.

## 검증 계획

- 2주 후: 캐시 적중률 90% 이상 확인
- 1개월 후: P99 응답 시간 50ms 이하 확인
- 3개월 후: 운영 비용 및 장애 빈도 검토

스토아 회고 프레임워크

1. 이번 주 우리가 통제할 수 있었던 것 중
   잘한 것은 무엇인가?
   (덕: 지혜, 용기, 절제, 정의)

2. 이번 주 우리가 통제할 수 없는 것에
   에너지를 낭비한 부분은?
   (불필요한 걱정, 비난, 후회)

3. 다음 주 최악의 시나리오는?
   (프리모템)

4. 우리가 집중해야 할 행동은?
   (통제 가능한 것에 에너지 집중)

장애 발생 시 스토아적 마인드셋

전통적 반응:
  "왜 하필 지금?"
  "누가 이런 코드를 작성한 거야?"
  "이번 달에만 세 번째 장애라니..."

스토아적 반응:
  "이 장애가 우리에게 무엇을 가르쳐주는가?"
  "우리 시스템의 어떤 가정이 틀렸는가?"
  "이 경험을 통해 어떻게 더 강해질 수 있는가?"

실천 방법:
  - 비난 없는 포스트모템(Blameless Postmortem) 문화 정착
  - "5 Whys" 기법으로 근본 원인 탐색
  - 장애를 학습 기회로 기록하고 공유
  - 재발 방지 조치를 자동화

실패 프로젝트 회고 (아모르 파티 프레임워크)

프로젝트명: [실패한 프로젝트]

사실 기록 (판단 없이):
  - 무슨 일이 있었는가?
  - 어떤 결정이 내려졌는가?
  - 결과는 무엇이었는가?

장애물이 곧 길이다:
  - 이 실패가 드러낸 우리의 약점은?
  - 이 경험이 없었다면 놓쳤을 교훈은?
  - 이 실패 덕분에 우리가 얻은 것은?

다음 단계:
  - 이 교훈을 어떻게 다음 프로젝트에 적용할 것인가?
  - 팀에 어떻게 공유할 것인가?

기술 부채에 대한 세네카적 접근

세네카의 원칙: "시간을 빌려주지 말라"
  현대 적용: 기술 부채는 미래의 시간을 빌려 쓰는 것이다.
  이자는 복리로 증가한다.

세네카의 원칙: "매일을 마지막 날처럼"
  현대 적용: 오늘 고칠 수 있는 작은 기술 부채를 내일로 미루지 말라.
  Boy Scout Rule을 실천하라.

세네카의 원칙: "바쁘다는 것은 살아있다는 것이 아니다"
  현대 적용: 새 기능만 추가하면서 바쁜 것은
  진정한 발전이 아니다. 리팩터링과 테스트도 본질적 업무다.

기술 부채 우선순위 매트릭스 (세네카 프레임워크)

분류 기준:
  - 긴급도: 당장 해결하지 않으면 영향이 큰가?
  - 이자율: 시간이 지날수록 비용이 증가하는가?
  - 영향 범위: 얼마나 많은 코드/팀에 영향을 미치는가?

1사분면 (긴급 + 높은 이자율): 즉시 해결
  예시: 보안 취약점, 데이터 손실 위험
  세네카: "내일이 있을 것이라 기대하지 말라"

2사분면 (비긴급 + 높은 이자율): 계획적 해결
  예시: 테스트 부재, 문서 미비, 의존성 업데이트
  세네카: "시간을 아끼는 것이 곧 생명을 아끼는 것이다"

3사분면 (긴급 + 낮은 이자율): 최소 대응
  예시: 마이너 UI 버그, 로깅 개선
  세네카: "중요하지 않은 일에 시간을 낭비하지 말라"

4사분면 (비긴급 + 낮은 이자율): 무시 또는 기록만
  예시: 코딩 컨벤션 불일치, 이상적인 리팩터링
  세네카: "완벽은 충분함의 적이다"

엔지니어링에서의 지혜:
  - 올바른 기술 선택을 위한 판단력
  - "은탄환(silver bullet)은 없다"는 것을 아는 것
  - 트레이드오프를 이해하고 명확히 소통하는 것
  - YAGNI(You Ain't Gonna Need It) 원칙의 적용

실천 방법:
  - 기술 선택 시 최소 3개 대안을 비교한다
  - 각 선택의 장단점을 문서화한다
  - "5년 후에도 이 결정이 유효한가?" 질문한다
  - 팀의 역량과 컨텍스트를 고려한다

엔지니어링에서의 용기:
  - 기술적 의견에 대한 건설적 반대
  - 실패 가능성이 있어도 혁신적 접근 시도
  - 장애 상황에서 침착한 판단과 결정
  - 어려운 피드백을 솔직하게 전달

실천 방법:
  - 코드 리뷰에서 불편해도 진심어린 피드백을 제공한다
  - "아키텍처 재설계가 필요합니다"라고 말할 수 있는 용기
  - 자신의 실수를 먼저 인정한다
  - 불확실성 속에서도 결정을 내리고 책임진다

엔지니어링에서의 절제:
  - 과도한 최적화(premature optimization) 자제
  - 적정 기술(appropriate technology) 선택
  - 기능 추가의 유혹에 대한 절제
  - 번아웃을 방지하는 지속 가능한 페이스

실천 방법:
  - MVP를 정의하고 그 범위를 지킨다
  - "이게 정말 필요한가?" 3번 질문한다
  - 주 40시간을 넘지 않도록 노력한다
  - 새 기술 도입 시 검증 기간을 반드시 거친다

엔지니어링에서의 정의:
  - 공정한 코드 리뷰 프로세스
  - 지식의 독점이 아닌 공유
  - 비난 없는 포스트모템 문화
  - 주니어 개발자에 대한 멘토링

실천 방법:
  - 모든 PR은 동일한 기준으로 리뷰한다
  - 문서화와 지식 공유를 일상화한다
  - 실수한 사람이 아닌 시스템의 문제를 찾는다
  - 팀 내 심리적 안전감을 조성한다

시나리오: 새 프로젝트의 프로그래밍 언어 선택

편향이 작용하는 상황:
  팀 리드 A: "Go로 하자. Netflix도 쓰고 있잖아." (밴드왜건)
  팀 리드 B: "우리는 항상 Java를 써왔어. 바꿀 이유가 없어." (현상 유지)
  시니어 C: "Rust가 확실히 성능이 좋아." (과신)

스토아적 접근:
  1. 통제 가능한 것에 집중: 우리 팀의 역량, 프로젝트 요구사항
  2. 프리모템: "이 언어 선택이 실패하는 이유는?"
  3. 네거티브 시각화: 각 선택의 최악 시나리오
  4. 정의: 모든 의견을 동등하게 평가

평가 매트릭스:
  평가 항목          | Go  | Java | Rust
  팀 경험          | 2/5 | 5/5  | 1/5
  성능 요구 충족    | 4/5 | 3/5  | 5/5
  생태계/라이브러리 | 3/5 | 5/5  | 3/5
  채용 용이성      | 3/5 | 5/5  | 2/5
  유지보수 난이도   | 4/5 | 3/5  | 2/5

결론: 팀 역량과 프로젝트 요구사항에 기반한 Java 선택
      (인기나 개인 선호가 아닌 데이터 기반 결정)

엔지니어의 아침 명상 (5분)

1. 오늘의 의도 설정:
   "오늘 나는 ___에 집중할 것이다."

2. 장애물 예상:
   "오늘 어떤 방해가 있을 수 있는가?"
   "통제할 수 없는 것에 어떻게 대응할 것인가?"

3. 덕목 점검:
   "오늘 지혜/용기/절제/정의 중
    어떤 덕목을 특히 실천할 것인가?"

4. 감사:
   "오늘 일할 수 있는 것에 감사한다."

엔지니어의 저녁 회고 (5분)

1. 오늘의 결정 리뷰:
   "오늘 어떤 결정을 내렸는가?"
   "그 결정은 적절했는가?"

2. 감정 점검:
   "감정적으로 반응한 순간이 있었는가?"
   "그 감정이 판단에 영향을 미쳤는가?"

3. 통제 이분법 점검:
   "통제할 수 없는 것에 에너지를 쓰지 않았는가?"

4. 개선점:
   "내일은 무엇을 다르게 할 것인가?"

주간 스토아 회고 (30분)

1. 이번 주 주요 결정 (최대 5개):
   - 결정 1: [내용] / 결과: [성공/실패/미확정]
   - 결정 2: ...

2. 덕목 실천 점수 (1-5):
   - 지혜: [ ] / 사례:
   - 용기: [ ] / 사례:
   - 절제: [ ] / 사례:
   - 정의: [ ] / 사례:

3. 통제 이분법 위반 사례:
   - 통제 밖의 것에 에너지를 쓴 경우
   - 통제 가능한 것을 방치한 경우

4. 프리모템:
   - 다음 주 가장 큰 리스크는?
   - 완화 방안은?

5. 감사 일지:
   - 이번 주 감사한 것 3가지

시스템 사고와 스토아 철학의 교차점

피드백 루프 = 행동과 결과의 인과관계
  스토아: 우리의 판단이 행동을 만들고, 행동이 결과를 만든다
  시스템: 출력이 입력에 영향을 미치는 순환 구조

레버리지 포인트 = 통제 가능한 핵심 지점
  스토아: 통제 가능한 것 중 가장 영향력 있는 것에 집중
  시스템: 작은 변화가 큰 영향을 미치는 지점을 찾아라

창발(Emergence) = 전체는 부분의 합 이상
  스토아: 개인의 덕은 공동체의 번영으로 이어진다
  시스템: 구성 요소의 상호작용에서 새로운 특성이 발생한다

레버리지 포인트 분석 (시스템 사고 + 스토아)

낮은 레버리지 (효과 작음):
  - 서버 추가 (스케일 아웃)
  - 코드 미세 최적화
  - 도구 변경

중간 레버리지:
  - 아키텍처 패턴 변경
  - 자동화 도입
  - 모니터링 개선

높은 레버리지 (효과 큼):
  - 팀의 사고방식 변화 (스토아!)
  - 의사결정 프로세스 개선
  - 학습 문화 구축
  - 심리적 안전감 조성

스토아의 통찰: 가장 높은 레버리지는 기술이 아니라
              사람의 사고방식과 문화에 있다.

STOIC 의사결정 프레임워크

S - Separate (분리하라)
  통제 가능한 것과 불가능한 것을 분리한다.
  질문: "이 상황에서 내가 실제로 영향을 미칠 수 있는 것은?"

T - Think Ahead (미리 생각하라)
  최악의 시나리오를 미리 상상한다. (프리모템)
  질문: "이 결정이 최악으로 실패한다면, 그 원인은?"

O - Observe Objectively (객관적으로 관찰하라)
  편향을 제거하고 데이터에 기반하여 판단한다.
  질문: "내 판단에 편향이 작용하고 있지 않은가?"

I - Implement with Virtue (덕으로 실행하라)
  지혜, 용기, 절제, 정의에 기반하여 실행한다.
  질문: "이 행동은 4가지 덕목에 부합하는가?"

C - Chronicle and Review (기록하고 검토하라)
  결정과 결과를 기록하고 정기적으로 복습한다.
  질문: "이 결정을 어떻게 기록하고 언제 재평가할 것인가?"

시나리오: Kubernetes 클러스터 업그레이드 결정

S (분리):
  통제 가능: 업그레이드 시점, 테스트 범위, 롤백 계획
  통제 불가: 업스트림 버그, 써드파티 호환성 문제

T (미리 생각):
  최악의 시나리오:
  - 업그레이드 중 다운타임 발생
  - 특정 워크로드가 호환되지 않음
  - 롤백 실패
  완화: 카나리 업그레이드, 충분한 테스트, 유지보수 시간대 활용

O (객관 관찰):
  데이터 확인:
  - 현재 버전의 EOL 일정
  - 새 버전의 안정성 리포트
  - 다른 팀/회사의 업그레이드 사례
  편향 점검: "단순히 최신 버전이라서 업그레이드하려는 건 아닌가?"

I (덕으로 실행):
  지혜: 단계적 업그레이드 계획 수립
  용기: 필요하다면 업그레이드 연기 결정
  절제: 한 번에 모든 것을 업그레이드하지 않음
  정의: 모든 이해관계자에게 영향 공유

C (기록/검토):
  ADR 작성, 업그레이드 결과 문서화
  2주 후 안정성 리뷰 예정

일일 실천 체크리스트:
  아침:
    [ ] 5분 명상/의도 설정
    [ ] 오늘의 장애물 예상
    [ ] 통제 가능한 것에 집중 계획

  업무 중:
    [ ] 의사결정 시 STOIC 프레임워크 적용
    [ ] 감정적 반응 감지 시 일시 정지
    [ ] 통제 밖의 것에 에너지 낭비 자제

  저녁:
    [ ] 5분 회고/저널링
    [ ] 오늘의 결정 기록
    [ ] 감사 일지 작성