brunch

라이킷 19 댓글 2

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Rapha Aug 30. 2022

좋은 것을 빠르고 낭비 없이 만드는 것

슬기로운 쿠팡페이 개발 생활

수단보다는 목표

쿠팡페이에서 강조하는 점 중의 하나는 수단보다는 목표를 먼저 생각하라는 거다.

목표를 추구하기 위한 좋은 수단이 있다면 우린 그 수단을 그냥 취하면 된다.

예를 들자면 아래와 같은 목표가 있을 수 있다.

세상에서 가장 간편하고 편리한 결제 서비스를 제공한다.

결제 실패율 0%!

은행계좌나 신용카드가 없어도 되는 세상

첫째도 보안, 둘째도 보안, 셋째도 보안

어떤 상황이 와도 지켜야 하는 것을 기억해야 한다.

그렇게 해야 좋은 서비스가 만들어지고 시간이 가도 유지가 되며 고객들은 열광하게 된다.

쿠팡페이 엔지니어링 팀에서의 목표를 잘 설명하고 있는 것 같아서 이 글의 제목을 "좋은 것을 빠르고 낭비 없이 만드는 것"이라고 적어봤다.

좋은 것을 빠르고 낭비 없이 만드는 것

생각만 해도 좋지 않은가! 좋은 것을 빠르고 낭비 없이만들다니!

항상 리소스는 없고 개발할 것, 개선할 것은 차고 넘친다.

신규 프로젝트가 발생하면 배고픈 승냥이처럼 리소스를 찾아 헤맨다.

"리소스 전쟁"이라고 해도 과언이 아니다. 이 문제를 슬기롭게 해결하는 조직이 곧 게임에서 승리한다.

지난날을 생각해보면 결국 좋은 것을 빠르고 낭비 없이 만드는 방법론을 찾아서 여러 가지 시행착오를 겪은 건 아닐까?

그저 그런 것을 느리고 많은 리소스를 들이며 만드는 것 - 최악이다! 곧 다시 개발해야 하고 다른 과제를 할 수 없음, 배포를 하고 나서도 장애 알림에 시달림

좋은 것을 느리고 많은 리소스를 들이며 만드는 것 - 다른 과제를 할 수 없음

엔지니어링 팀의 궁극적인 목표는 정해진 리소스와 정해진 기간에 최대 성과를 내는 것이라고 생각한다.

여기에서의 성과는 단순히 일정을 맞추는 것이 아닌 운영 가능한, 완성도가 높은 소프트웨어를 의미한다.

좋은 것을 만든다.

좋은 것을 만든다. 좋은 소프트웨어는 무엇이고 어떻게 만들어야 할까?

비즈니스 성장을 생각한다.

쿠팡의 성장과 더불어 쿠팡페이에서 처리하는 결제 트랜잭션의 건수는 매년 증가하고 있다.

친절하게도 소프트웨어는 힘들면 힘들다고 얘기를 해준다.

멀쩡히 잘 돌아가던 배치 프로그램은 처리를 못한다고 하면서 중지한다.

특별히 수정한 곳은 없지만 결제 과정의 전체적인 처리 속도가 조금씩 느려진다.

트래픽은 동일한데 스레드 카운트가 증가한다.

엔지니어링팀은 모든 분야에 있어 현재보다 10배의 트래픽을 고려해서 아키텍처를 설계하거나 개선한다.

그렇게 간단한 쿼리로 만들면 당장은 깔끔하고 좋겠지만 비즈니스가 계속 성장하게 되면 쿼리가 엄청 느려질 거예요. 지난 3개월의 데이터 건수 기준으로 10배 정도 늘어났을 경우를 대비해서 개선하면 좋겠어요.

해당 API는 사용 트래픽이 제일 많아서 데이터베이스 성능에 많은 영향을 미치고 있습니다. 캐시를 고려해보면 어떨까요?

API 서버에서 너무 많은 일을 하고 있는 것 같아요. 분리할 수 있는 기능이 있을까요?

동료들이 이해하고 수정 가능한 코드를 작성한다.

코드를 개발하고 배포되는 순간 팀의 코드가 된다. 팀의 코드가 된다는 건 개선사항이 발생하거나 장애 시에 처리가 가능하다는 것을 의미한다. 특정 코드를 특정 팀원만 수정할 수 있다는 건 엔지니어링 조직이나 팀으로서는 절대적으로 피해야 하는 일이다. 팀에서는 코드 리뷰라는 활동을 통해서 이런 부분들을 많이 해소하고 있지만 엔지니어링 전체 조직을 확대하고자 한다면 아직 많은 고민이 필요하다. 한 가지 긍정적인 부분을 꼽자면 최근 들어 "엔지니어링 조직 차원에서도 가능할까?"라는 질문을 던지고 있다는 것이다. 조직이 커지다 보면 엔지니어링 리소스의 효율성에 대한 이야기가 나온다. 쉽지 않은 일이기에 많은 토론과 질문들을 통해서 해답을 찾아야 할 것이라고 생각한다.

문제가 있다면 문제가 있다고 말해야 하고 말하면 바로 알아야 한다.

코드 결함에 대해서 숨기면 안 된다. 배포가 나가고 갑자기 사용자 문의사항이 몰려올 수 있다. 중요한 부분은 사용자 문의사항은 언제든지 올 수 있지만 우리가 먼저 인지를 해야 한다는 것이다. 코드의 결함이 있는데 코드에서 어떤 예외 사항도 없고 이 부분을 뒤늦게 알았다면 문제가 커진다. 기본적으로 Platform에서 제공하는 가이드를 준수하면 System Metric(Thread Count, Request Count, CPU, Memory,... 등)은 측정이 되고 모니터링이 잘 되고 있다. 코드 결함에 대해서는 코드 내에서 이루어지기 때문에 주의가 필요하다.

엔지니어가 일을 하지 않고 소프트웨어가 일하게 한다.

서비스가 론칭을 하고 나면 주요 기능에 밀렸던 여러 가지 예외처리에 대한 복구 기능이나 운영 업무들을 처리 위한 기능이 필요하다. 다른 우선순위에 밀려서 보통 수작업으로 해결을 하게 되는데 가급적이면 리소스를 투입해서 기능으로 제공해야 한다. 엔지니어가 일을 하지 않고 소프트웨어가 일하게 함으로써 어느 순간 리소스가 거의 들지 않은 자동화된 서비스가 되어 있는 것이다. 이런 서비스가 많아질수록 리소스는 절약되며 절약된 리소스로 우린 더 좋은 소프트웨어를 개발할 수 있는 기회를 가질 수 있다.

빠르게 만든다.

그저 그런 것을 빠르게 만들 수는 있지만 좋은 것을 빠르게 만든다는 것은 쉬운 일은 아니다. 예를 들어, 배치 프로그램을 개발하는데 한 번만 사용할 것이라고 가정한다면 비슷한 배치 프로그램을 카피해서 30분 정도만 투입해도 개발이 가능하다. 위에서 말한 것처럼 좋은 소프트웨어가 갖춰야 할 항목이 많기 때문에 빠르게 만들려면 상당한 기술과 노하우가 필요하다.

좋은 코드

동료들의 코드 리뷰를 거치고 오랜 기간 운영을 해오면서 안정성까지도 검증된 코드들이 이미 많이 있다. 소수의 엔지니어들을 제외하고는 처음부터 모두 개발하지는 않는다. 이미 잘 작성된 코드들을 토대로 요구사항에 맞게끔 수정해서 개발을 진행하게 되는데 이때 좋은 코드들은 상당한 도움이 된다. 좋은 코드가 많이 생성되는 동시에 엔지니어들의 실력이나 경험이 증가하면서 생산성도 점점 증가하고 있다. 그리고 우리가 개발하는 IDE, 프레임웍, 코드 구조에 대한 아키텍처들이 점점 비즈니스 요구사항에 집중할 수 있는 구조로 발전하고 있다. 좋은 코드를 생성하는 문화는 코드 리뷰 활동이 한몫을 하고 있다고 생각한다.

좋은 엔지니어

어떤 업무를 맡게 되면 해당 엔지니어가 전체적으로 리드를 하는 문화가 있다. 그 업무에 대해서는 누구보다 잘 알아야 하고 때로는 회의를 소집하고 사내 메신저를 뒤지고 위키를 뒤져서 어떤 일을 해야 하는지 찾아낸다. 많은 회사에서도 이런 엔지니어들을 원하고 있고 실제 엔지니어들에게 이런 역할을 주고 있는 것으로 알고 있다. 무엇을 해야 하는지 스스로 찾는 엔지니어가 필요하다. 기다리는 것은 시간이다. 누구도 리드하지 않는 다면 시간은 그냥 간다. 경험적으로 팀에 능동적인 엔지니어가 3명 정도만 있어도 나머지 엔지니어나 다른 유관부서는 상당히 신속하게 진행되는 걸 볼 수 있었다.

신속한 의사결정

대부분의 엔지니어들이 무엇을 하려고 해도 주요 의사결정이 나질 않아서 개발을 멈췄던 경험을 가지고 있을 것이다. 무엇보다도 수평적인 조직구조가 이 부분을 상당 부분 해결하고 있는 것 같다. 수평적인 조직구조라는 것은 실제 실무를 담당하고 책임을 지는 조직이 전체에 8-90% 이상을 차지하는 것을 말한다. 이렇기 때문에 의사결정을 누군가에게 받는다는 표현보다 같이 토론하고 결정하는 것이 더 맞는 표현일 것 같다. 상위 조직에서는 목표를 제시하고 실무 조직에서 이 목표를 달성하는 활동을 하는 데 있어서 어느 정도 신뢰관계가 형성되어 있기 때문에 가능하다고 생각한다. 관련해서 동료(Call My Nickname) 글도 도움이 될 것 같다.

낭비 없이 만든다.

소프트웨어 개발 과정에서 낭비요소에는 여러 가지가 있다. 몇 가지 생각나는 것을 적어보겠다.

일정을 맞추기 위해서 그저 그런 것을 만든다.

장기적으로 리소스 낭비이다. 시간이 갈수록 안정성이 확보되고 운영 업무가 줄어드는 것이 아니라 점점 쌓여가기 때문에 초기에 2주만 연장하면 됐던 일이 2배, 3배가 돼서 돌아온다. 일정을 지연하더라도 완성도에 포커스 하는 것이 좋다.

Over Engineering

오버 엔지니어링이란 쉽게 말해서 거의 일어나지 않을 일까지 고려해서 개발을 하는 것이다. 어느 수준까지가 적당한가에 대해서는 정확히 규정할 수는 없지만 가끔 콘셉트 리뷰(코드를 작성하기 전에 개발 전략에 대한 리뷰)를 할 때 나오곤 한다. 동료들은 이런 상황에서 이런 조언을 해주곤 한다. "해당 예외사항까지 고려하는 것은 좋지만 오버 엔지니어링인 것 같아요. 해당 예외 부분에는 주석을 달아두고 다른 작업을 일주일 빨리 시작하는 게 좋겠습니다". 실제 개발을 할 때 오버 엔지니어링으로 인해서 투입되는 리소스는 상당히 크고 읽기 쉬운 코드가 읽기 어려운 코드로 변화할 수도 있다. 때로는 트레이드오프를 통해서 밸런스를 맞춘다.

파워포인트가 아닌 실제 사용자가 사용하는 디자인

사용자가 실제 사용하는 디자인이 아닌 파워포인트로 작성된 화면 계획서를 보고 UI 개발을 하던 시절이 있었다. 디자인 부서는 항상 바빠서 오픈이 며칠 남지 않는 날 최종 디자인이 나오곤 했는데, 이 부분에서 예상했던 재개발이 시작이 되고 가끔 야근도 했던 기억이 난다. 이제 이렇게 개발하는 회사는 없을 것으로 생각한다. 쿠팡에 입사하고 놀라웠던 건 파워포인트로 작성된 화면 계획서를 만드는 단계를 없애고 바로 UX/UI 단계로 진입한다. UX/UI의 초안이 나오면 Frontend, Backend 엔지니어들이 모여서 바로 이해하고 개발에 들어간다. 이게 시스템 얼럿인지, 커스텀 얼럿인지, 해당 데이터를 백엔드 사이드에서 제공해 줄 수 있는 데이터인지 고민할 필요가 없다. 이미 실제 사용자가 사용하는 디자인으로 개발을 하기 때문에 재개발 가능성도 낮추고 화면 계획서를 UI로 옮겨 담는 과정을 없앰으로써 획기적으로 낭비를 줄였다.