주 0: Platform Engineering을 향한 16주 여정 시작

Source: Dev.to

Canonical URL

왜 이 여정인가?

앞으로 16주 동안, 나는 진정한 SRE 책임을 갖춘 백엔드/플랫폼 엔지니어가 되기 위해 스스로 길을 닦아가고 있습니다. 이것은 자격증을 모으거나 튜토리얼을 완료하는 것이 아니라, 실제 시스템을 구축하고, 고의로 이를 파괴해 어떻게 실패하는지 살펴보며, 그 실패에서 지속되는 교훈을 얻는 것입니다.

Source: …

이것이 다른 이유는?

일반적인 학습 경로는 기능을 만드는 방법을 가르칩니다. 저는 더 어려운 것에 집중하고 있습니다: 시스템을 운영하는 방법을 배우는 것입니다. 노트북에서 작동하는 코드를 작성하는 것과, 프로덕션 압력 하에서도 신뢰성을 유지하는 서비스를 운영하는 것 사이에는 중요한 차이가 있습니다.

• 단순히 서비스를 구축하는 대신, 문제가 발생했을 때 서비스를 운영하는 방법을 배우고 있습니다.
• 코드를 작성하는 것만이 아니라, 이를 배포하고, 동작을 모니터링하며, 실패 시 복구를 연습하고 있습니다.
• 패턴을 외우는 대신, 의도적인 아키텍처 선택을 하고 그 결과를 충분히 경험함으로써 트레이드‑오프를 몸소 이해하고 있습니다.

계획

여정은 네 단계로 나뉘며, 각 단계는 이전 단계 위에 구축됩니다.

1단계 (1‑4주): 서비스 기반

백엔드 서비스를 구축하는 것부터 시작하지만, 경계와 계약에 명시적으로 주의를 기울입니다. 초기부터 포괄적인 장애 처리 방식을 구현하고 있으며, 사후에 추가하는 것이 아닙니다. 가시성은 나중에 추가할 것이 아니라 기반의 일부이며, 볼 수 없는 것을 운영할 수 없기 때문입니다.

2단계 (5‑8주): 프로덕션 현실

그 서비스를 실제 클라우드 환경에 배포하여 실제 비용과 실제 장애 유형이 존재하도록 합니다. 여기서 카오스 엔지니어링이 들어갑니다: 고의적으로 장애를 주입해 무엇이 어떻게 깨지는지 확인합니다. 사고 대응 및 복구를 연습하여 알림이 발생했을 때 침착함을 유지하는 근육 기억을 구축합니다.

3단계 (9‑12주): 플랫폼 사고

관점을 단일 서비스에서 재사용 가능한 구성 요소로 전환합니다. 서비스 수준 목표와 오류 예산을 정의하고, 신뢰성을 바라는 이상이 아닌 명시적인 트레이드오프가 있는 제품 기능으로 다룹니다. 여기서 플랫폼 엔지니어처럼 생각하기 시작합니다: 다른 엔지니어가 신뢰할 수 있는 서비스를 더 쉽게 구축하도록 어떻게 도울 수 있을까?

4단계 (13‑16주): 커뮤니케이션

기술 작업에는 명확한 문서와 설명이 필요함을 인식합니다. 소유권을 보여주는 기술 문서를 작성하고, 실제로 다른 사람에게 유용한 문서를 구축합니다. 목표는 내가 무엇을 만들 수 있는지뿐만 아니라 신뢰성과 운영에 대해 어떻게 생각하는지를 보여주는 포트폴리오를 만드는 것입니다.

공개 학습

내가 하는 모든 일은 보이고 문서화될 것이다. 매주 나는 내가 만든 것, 부서진 것, 그리고 그로부터 배운 것을 다루는 포스트를 공개할 것이다. 매주 금요일은 Failure Friday이며, 그 주의 문제에 대해 솔직한 사후 분석을 쓴다. 나는 어떤 접근 방식을 선택했는지, 고려한 트레이드‑오프를 포함한 결정을 설명하는 의사결정 로그를 유지하고 있다. 모든 코드는 GitHub에 있으며, 누구나 실제 작업을 볼 수 있고, 다듬어진 요약만 보는 것이 아니다.

세 가지 질문

매주 금요일마다, 저는 저를 정직하게 유지해 주는 세 가지 구체적인 질문에 답하고 있습니다:

1. 이번 주에 무엇이 실패했거나 거의 실패했나요?
   답이 “아무것도 아니다”라면, 충분히 노력하지 않았거나 스스로에게 정직하지 못했다는 것을 의미합니다.

2. 어떤 신호가 실패를 포착했으며, 혹은 어떤 신호가 포착했어야 했지만 포착하지 못했나요?
   이는 관측 가능성에 대해 생각하게 하고 실제 운영 환경에서 문제가 있었는지를 알 수 있었는지를 검토하게 합니다.

3. 가장 중요한 인간의 결정은 무엇이었나요?
   기술 선택도 중요하지만, 결정적인 순간은 종종 판단에 달려 있습니다—우선순위를 어떻게 정했는지, 무엇을 조사하기로 했는지, 복잡성을 더하는 대신 단순화하기로 선택한 시점 등.

따라가기

다음 여러 곳에서 진행 상황을 확인할 수 있습니다:

• GitHub repository – 개발 과정에서 모든 코드와 문서를 포함합니다.
• Notion – 나의 학습 시스템으로, 진행 상황을 추적하고 노트를 정리합니다.
• This blog – 매주 업데이트됩니다.
• Spreadsheet – 계획 대비 진행 상황을 추적합니다.

분명히 말씀드리자면, 저는 전문가로 시작하는 것이 아닙니다. 저는 유능한 개발자에서 자신 있게 운영할 수 있는 플랫폼 엔지니어가 되기까지의 여정을 기록하고 있습니다. 비슷한 길을 걷고 계시다면, 댓글로 이야기를 나눠 주세요.

다음은?

1주차는 내일 시작됩니다. 저는 이 16주 동안 저를 이끌 학습 시스템을 구축하고 있습니다. 코드를 작성하기 전에 먼저 구축할 첫 번째 서비스를 정의하고, 그 서비스의 OpenAPI 사양을 작성할 예정입니다—계약과 인터페이스를 먼저 고민하는 습관을 연습하려고 합니다.

이 내용이 여러분에게도 공감된다면, 여정을 함께 따라와 주세요. 비슷한 기술을 배우고 있거나 이미 이 전환을 겪어보신 분이라면, 댓글로 여러분의 의견을 들려주시면 감사하겠습니다.