허나, 정석적인 애자일 방법론은 아닙니다. 우리 팀은 애자일 방법론을 엄격한 규칙에 얽매이지 않고, 상황에 맞게 유연하게 조정하여 업무를 수행하고 있습니다. 이를 통해 우리는 변화에 더 적극적으로 대응하고, 효과적인 협업과 지속적인 성장을 추구하는 스쿼드로서의 역량을 계속해서 강화하고 있습니다.

사실 서비스에 따라서 적응형이 좋을 수도 있고, 반응형이 더 좋을 수도 있어요.그래서 속한 회사와 서비스의 성격에 따라 알맞다고 생각하는 선택지를 고르는 게 가장 현명한 방법 아닐까 싶어요.

앞으로 저는 어떤 프로젝트를 하더라도 통합, 반응형, 디자인 시스템 이 3가지를 염두에 둔 프로젝트를 경험할 기회는 많지 않을 것 같아요.

소프트웨어 엔지니어들은 수많은 추상화 속에서 살아갑니다. 하위 레벨에서 제공하는 추상화는 공기처럼 당연한 것으로 여겨지고, 그 위에 무엇을 어떻게 쌓아 올릴지 고민하는 게 소프트웨어 엔지니어링이라 할 수 있습니다. 오늘은 이렇게 당연하게 여겼던 추상화를 하나하나 파고들어간 이야기를 소개해 볼까 합니다. 수십 명의 개발자들이 만들었던 게임. 36시간 장애 속에서 수백만 명이 서비스 오픈만을 기다리고 있고, DB를 만든 회사에서 복구는 불가능하다고 얘기하는 극한의 상황 속에서 CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기를 소개합니다.