JasonYoo1995
commented
9 months ago 서론
- 기능 개발 완료 ≠ 운영 준비 완료
- 개발 ≠ 기능 추가
- 개발 ⊃ 기능 추가
- 운영하기 버겁지 않도록 개발해야 함
- 설계 대상
- 해야 하는 것만 설계 X
- 하지 말아야 하는 것도 설계 O
- 시스템 장애/중단, 데이터 유실, 개인 정보 침해, 금전 손실, 회사 피해, 고객 피해 등
- 테스트 통과가 본질적인 목표이면 안 된다 (테스트가 커버하지 못하는 영역)
- 실제 유저 시나리오
- 막대한 트래픽
- 변조/어뷰징/바이러스 등 악의적 공격
- 완벽한 방지는 없다
- 피해 발생 시, 복구 가능한 설계
1.1 올바른 목표 설정
- 테스트는 인공 영역이고, 실제 세계를 모두 반영하지 못한다
- 비슷한 예시 : 90년대 초반의 자동차 설계
- 현실과 동떨어진 설계
- 쾌적한 개발 환경에서 잘 돌아가는 것 ≠ 다사다난한 운영 환경에서 잘 돌아가는 것
- 테스트만으로는 향후 장애 예측 불가
- 비슷한 예시 : 90년대 초반의 자동차 설계
- 제조업에서 저비용 고품질의 제조 고려 설계(Design For Manufacturability)와 유사한 운영 고려 설계(Design For Production)라는 개념을 책에서 다룰 예정
- 개별 시스템이 아닌 상호 의존적인 시스템 전체를 설계해야 함
1.2 도전의 범위
- 오늘날의 변화
- 막대한 트래픽
- 365일 24시간 멈추지 않는 가동시간에 대한 요구 사항
- 시스템 공격 기술의 발전
1.3 여기도 백만 달러, 저기도 백만 달러
- 데드라인으로 인해 운영 비용을 포기하고 개발 비용을 줄이는 결정
- 개발 기간보다 운영 기간이 더 길기 때문에 장기적으로는 손해
- 코앞의 ROI(=Return On Investment, 투자 대비 수익률)로는 CFO가 거절할지 몰라도 향후 5년 간의 ROI를 제시하면 CFO가 흔쾌히 승인할 것
- 이를 기술적 관점과 재무적 관점의 융합이라고 함
1.4 ‘포스’를 사용하라
- 초기 단계에서의 의사 결정은 가장 적은 정보량을 토대로 내려야 하나 최종 모습에 가장 큰 영향을 끼친다는 모순 → 초능력(포스) 필요
- 애자일은 운영 환경에 최대한 빨리 배치하여 현실에서 발생 가능한 문제를 미리 배울 수 있다는 면에서 긍정적
- 두 가지 의사 결정에 대한 구현 비용은 비슷하더라도 전체 생애 주기 비용은 극단적으로 다를 수 있어 → 실제 예시를 다룰 예정
1.5 실용주의 아키텍처
- 상아탑 아키텍처
- High Level로 추상화 시키고 Low Level은 최적화하지 않음
- 비효율적인 리소스 사용에도 표준만을 고수함
- 시스템 완성 후 개선하지 않음
- 실용주의 아키텍처
- Low Level을 최적화함
- 효율적인 리소스 사용을 위해 주저 않고 구조를 교체함
- 시스템을 끊임 없이 개선함
- 이 책은 실용주의 아키텍처에 관한 스킬들을 소개하는 책
마치며
- 소프트웨어는 운영을 통해 가치를 전달함
- 개발/테스트는 운영을 위한 사전 단계
- 2장에서는 운영 시 안정성과 관련하여, 한 항공사 시스템의 버그를 예시로 살펴볼 예정
1장의 키워드는?
- 운영
주제
대신 할 수 있는 만큼의 조치를 취하고 예방하면서, 정말 심각하고 예상치 못한 피해가 발생하더라도 전체 시스템이 복구될 수 있게 만들어야 한다.(p.35)꼼꼼하게 설계하고 개발하여 장애가 안 생기는 것이 베스트지만, 누구나 실수를 할 수 있기 때문에 장애는 필연적으로 발생할 수 밖에 없다고 생각합니다. 이러한 장애 상황에 빠르게 대처하고, 후에 동일한 문제가 생기지 않도록 꾸준히 공부해야되겠다는 생각이 들게 해준 문구라서 기록해보았습니다.
다른 기술을 사용하면 10배는 쉬울 일을 회사 표준을 따르느라 어쩔 수 없이 이를 악물고 코딩해야 했다면 상아탑 아키텍트에 희생된 것이다.(p.40)단순히 구현에 급급한 코드로 방치해두고, 버전 마이그레이션, 리팩터링을 진행하지 않는다면? 위와 같은 문제가 발생할 수 있습니다. 마찬가지로 꾸준히 공부해야 함을 강조하기에 적합한 문구라 생각돼서 적어보았습니다.
연관 챕터
1