백엔드 개발자로 성장하기
머피의 법칙
p-122
머피의 법칙은 '항상 나한테만 재수 없는 일이 일어난다'는 의미가 아닙니다. '어떤 일을 하는 데에 둘 이상의 방법이 있고 그것 중 하나가 나쁜 결과를 불러온다면 누군가가 꼭 그 방법을 사용한다'에서 시작해 '잘못되는 것은 꼭 잘못되게 마련이다'라는 의미입니다. 특정한 개인의 불행과는 상관없는 것이지요.
보안은 쇠사슬이다.
p-136
보안은 평균으로 작동하지 않고 가장 약한 부분에 의해 뚫리게 됩니다. 쇠사슬처럼요. 100개 중 99개가 튼튼해도 1개의 사슬만 고장나 있으면 그 쇠사슬은 끊어집니다.
ID 값 Integer 타입 과연 맞을까?
p-140
스타트업 개발자들의 흔한 착각 중에 '설마 우리 서비스가 성공할 리 없어~'라는게 있는 것 같습니다. 비용을 아낀다는 명목으로, 별 생각 없이 순차 증가하는 기본 키를 Integer로 만듭니다. 이는 갑자기 폭발적으로 성장하는 서비스의 발목을 잡는 주범이 됩니다. 단순히 순차 증가 값을 Long으로 하는 것만으로 엄청난 장애를 막고 비용을 아낄 수도 있습니다.
매핑 필드 타입을 변경하는 작업은 엄청난 비용을 초래하며 수많은 연계 시스템 중에서 한 개만 Integer 매핑 상태로 있어도 전면 장애로 이어질 수 있습니다.
주의할 점이 있습니다. API로 외부 연동을 할 경우 클라이언트 애플리케이션에서도 확실히 Long으로 매핑하고 저장하는지 확인해야만 합니다. 초반 테스트용 데이터의 작은 숫자만 보고 Integer로 API 결과를 매핑하는 일도 부지기수로 일어납니다.
당신의 서버는 무조건 죽는다 : SPoF를 제거하자
p-142
'설마 내가 구축한 서버가 죽겠어?' 네, 죽습니다. 안 죽는 서버가 아니라 '죽어도 괜찮은 서버'를 구축해야 합니다. 단일 장애점 SPoF를 제거하라는 의미입니다. 내가 호출하는 애플리케이션이 죽는 경우도 염두에 두고, 서킷 브레이커 등을 도입하는 것도 고려하면 좋습니다.
과제와 교훈
p-147
서비스는 종료되었지만, 소스 코드는 그대로 남아있다.
신규 개발 후 QA 과정에서 새로 개발한 시스템이 아닌 레거시 시스템으로 연결되어 테스트 당시에는 오류를 발견하지 못했지만, 시간이 지나면서 데이터에 누수가 생기기도 하고, 불필요한 부분에서 병목이 발생해서 전체 서비스 레이턴시에 문제가 생기기도 합니다. 이는 레거시를 정리하지 못해서 생기는 부작용입니다.
모두가 주인인 듯 아무도 주인이 아니다.
하나의 프로시저를 여러 시스템에서 호출하고, 여러 개발자가 동시에 수정하면서 모두가 사용하지만 아무도 오너십을 가지지 않는 상황이 되었습니다. 그리고 결국, 내가 수정한 코드가 다른 부분에서 어떤 문제를 야기할 수 있는지 파악하기 힘들어지고, 이로 인해 전체 시스템에 대한 불확실성이 증가했습니다.
배운 점
프로젝트를 계획할 때 레거시 제거도 프로젝트 범위에 포함하자
수많은 레거시가 제거되지 못하는 이유는 바로 '일정이 부족해서'일 겁니다. 처음 프로젝트를 시작할 때 전체 일정을 산정하는데 대부분 레거시 제거를 프로젝트 범위에 포함하지 않습니다. 하지만 이 과정이 생략됨으로 인해서 발생하는 부작용은 생각보다 큽니다.
코드에 대한 오너십을 갖자.
가급적 코드에 대한 오너십을 명확하게 하는 것이 좋습니다. 공통으로 사용하는 기능이라고 하더라도 오너십을 부여하고 이를 주기적으로 관리하는 것과 관리하지 않는 것의 차이는 큽니다. 아무도 관리하고 있지 않은 때에 장애 인지 및 장애 복구가 전반적으로 늦어지고 장애 확산 가능성도 훨씬 커질 수 있습니다.
당연한게 당연한 것이 아니다.
p-168
모든 시스템과 집단은 각자의 사정이 있습니다. 그 안에서 약속한 규칙들이 생깁니다. 약속한 규칙은 그 집단에서 당연한 것이 됩니다. 하지만 그 집단을 벗어나면, 그 약속은 더 이상 당연한 게 아닙니다. 개발 존 1과 2에 같은 ID의 상품이 존재하지만, 두 상품은 전혀 다른 상품일 수 있습니다. 반대로 서로 같은 상품이지만 서로 다른 환경에서는 ID가 다를 수 있습니다.