당근마켓 인프라실의 새로운 비전은 바로 ‘DevSecOps 문화를 실현하는 당근마켓을 만들어요.’ 입니다. 그런데 여기서 이야기하는 DevSecOps 문화란 무엇일까요?
소프트웨어 엔지니어가 소프트웨어를 만들고 운영할 수 있는 도구를 개발하고 문화를 조성하는 것, 그리고 그 모든 과정에 보안을 함께 고려 하는 것
당근마켓 인프라실이 ‘DevSecOps 문화’를 정의하는 방식입니다. 그리고 이 문화를 실현할 수 있도록 방향을 잡는 것, 그것이 인프라실의 새로운 비전이자 도전입니다. 그럼 당근마켓 인프라실은 왜 이런 방향으로 나아가고자 하는 것일까요?
클라우드 시대에 변화가 필요한 업무 모델
당근마켓은 모든 인프라가 AWS 위에서 동작하고 있는 퍼블릭 클라우드 환경입니다. 하지만 우리는 온프레미스 환경에서 업무를 하던 것과 크게 다르지 않은 방식으로 업무를 하고 있었다는 걸 발견 했습니다.
위 그림처럼, 온프레미스 환경에서는 다음과 같은 방식으로 업무를 진행합니다.
- 주로 개발자가 인프라에 대한 변경을 요청한다.
- 시스템 엔지니어 혹은 어드민이 변경 작업을 한다.
- 결과를 개발자에게 전달한다.
서버 구매, 네트워크 연결, 데이터센터 작업 등 물리적인 작업이 필요하기 때문에 요청 기반의 업무 방식이 잘 동작하는 환경입니다.
하지만 퍼블릭 클라우드 환경으로 넘어온 후에도 우리는 여전히 같은 방식으로 일하고 있었습니다. 다만 인프라에 대한 변경 작업이 기존보다 더 빨라졌을 뿐이죠. 서버 구매 및 증설 요청 등 며칠이 소요되던 것이 몇 시간 안에 처리되는 것처럼요.
요청 기반의 업무 방식으로 계속 나아갈 경우, 개발 조직의 인원수가 늘어난 만큼 요청 자체도 늘어나게 됩니다. 그럼 늘어나는 요청을 처리하기 위한 인프라 조직의 인원수도 함께 늘어나야 합니다. 하지만 당근마켓 인프라실은 요청 기반의 업무 처리 방식이 퍼블릭 클라우드 환경에 적합한 것인지 고민하기 시작했습니다. 또 이런 방식의 성장이 과연 지속 가능한 것인지 다시 한번 생각해 볼 필요가 있다고 느꼈습니다.
그리고 이런 고민에 대한 답으로 인프라 조직의 업무 방식이 변화해야 한다는 결론에 도달했습니다. 바로 아래처럼 말이죠.
개발팀이 스스로 할 수 있는 환경을 만들기 위한 조직이 되는 것
그리고 이런 방향성을 바탕으로 만든 비전이 바로 ‘DevSecOps 문화를 실현할 수 있는 당근마켓을 만들어요.’ 였습니다.
개발팀이 스스로 할 수 있는 환경이 된다는 것, 그건 당근마켓의 개발팀들이 더 빠르게 하고 싶은 것들을 할 수 있는 환경이 되는 걸 의미합니다. 곧 당근마켓 전체의 성장을 이끌어 낼 수 있다는 힘이자 문화가 될 것이고요. 그리고 인프라실은 이런 것들을 할 수 있게 만드는 목적 조직이 되는 것이죠. 이를 통해 인프라실 역시 지속적인 성장이 가능한 조직이 됩니다. 개발조직의 인원수가 늘어나더라도 인프라실에서는 DevSecOps 문화를 실현할 수 있는 환경을 만드는 것에 집중하면 되기 때문입니다.
비슷한 개념으로 넷플릭스에서 이야기 하고 있는 Full Cycle Developer 라는 개념이 있습니다. 소프트웨어를 개발한 주체가 소프트웨어 개발 주기의 모든 과정에 개입해서 직접 모든 것을 할 수 있도록 하는 개념 입니다.
Full Cycle Developer가 가능하도록 각 과정의 전문가들이 도구를 개발하거나 문화를 조성하는 역할을 합니다. 당근마켓 인프라실도 개발자들이 Full Cycle Developer가 될 수 있도록 하는 역할에 집중하고, 역량을 강화 하려는 방향으로 움직이려 합니다. 당근마켓의 개발자들이 Full Cycle Developer가 될 수 있게 하는 문화를 ‘DevSecOps 문화를 실현한다’라는 표현으로 만들어 비전으로 만든 것입니다.
그렇다면 조금 더 구체적으로 어떻게 DevSecOps 문화를 실현할 수 있을까요?
Internal Developer Platfotm
저희는 그 답을 Internal Developer Platform (이하 IDP) 에서 찾았습니다. 당근마켓 개발팀을 위한 IDP를 만들고 이를 운영하고 관리하는 역할을 하는 것이죠.
IDP는 당근마켓 인프라를 구성하는 다양한 요소를 추상화한 도구입니다. AWS 콘솔에 직접 접근하거나 테라폼을 이용해서 리소스를 생성하는 대신 IDP를 통해서 AWS 리소스들을 만들게 됩니다. 쿠버네티스 역시 마찬가지입니다. 개발자들이 쿠버네티스의 매니페스트를 직접 수정하지 않아도 IDP를 이용해 수정하고 배포하는 등의 작업을 할 수 있게 됩니다. 이렇게 IDP를 통해 당근마켓 인프라 구성 요소들을 추상화하고 개발자들이 서비스에 필요한 인프라 작업들을 직접 할 수 있게 하는 것이죠.
하지만 IDP가 일종의 게이트키퍼가 되는 것은 아닙니다. IDP가 모든 인프라 구성 요소들을 추상화하진 않습니다. 그렇게 할 수도 없구요. IDP는 가장 많이 사용되는 인프라 리소스들을 안전하고 편하게 사용할 수 있는 도구가 됩니다. IDP를 이용하지 않아도 쿠버네티스에 접근해서 매니페스트들을 수정할 수 있습니다. IDP의 가장 중요한 역할은 인프라에 대한 전문적인 지식이 없어도 인프라 작업을 할 수 있게 하는 것입니다. 그리고 그 과정에 인프라실이 만든 가드레일이 적용됩니다. 누가 어떻게 생성하더라도, 보안 위험에 안전하고 장애에 유연한 인프라를 구성할 수 있도록 도와주는 것이죠. 이게 IDP의 역할입니다.
앞으로의 도전 과제들
하지만 IDP를 만들었다고 해서 IDP 사용을 강제하고 싶진 않습니다. IDP가 자체로 뛰어난 플랫폼이 되어, 개발팀이 스스로 IDP를 사용하고 싶게 만드는 것이 가장 큰 숙제입니다. 그리고 IDP를 뛰어난 플랫폼으로 만들기 위해 Developer Experience (이하 DX)를 더 연구하고 이해하는 게 중요합니다.
2021년 아마존 주주서한에 있던 문구처럼, DX에 대한 연구를 바탕으로 좋은 IDP를 만들어 내기 위해 도전과 실패를 반복해야겠죠.
마치며
새로운 비전을 바탕으로 도전을 시작했지만 이제 첫 발걸음을 내디딘 수준입니다. 무엇보다 인프라실의 구성원들 중에 IDP를 만들거나 사용해본 경험이 없습니다. 하지만 무엇보다 인프라실의 구성원들이 새로운 방향으로 나아가야 한다는 공감대를 형성했습니다. 힘든 길이지만 모두에게 의미 있는 경험이 될 거라고 생각합니다.
시간이 더 지나 내년 이맘때쯤이 되면, 우리의 도전이 어떤 결실을 맺고 있는지 혹은 어떤 어려움들을 헤쳐 나갔는지 공유할 수 있으면 좋겠습니다. 또한 이 글을 읽고 저희보다 먼저 이 길을 걸어보신 분들이 계신다면 어떤 어려움들을 겪었고 어떻게 이겨 나가고 있는지 이야기를 나눠 보고 싶습니다. 감사합니다.
