지금 커버링은 최적화 스쿼드에서 실험을 주도할 클라이언트 엔지니어, 백엔드 엔지니어를 채용하고 있습니다. 조직에서 가장 큰 비중을 차지하기도 하는 개발팀이 어떻게 일하는지 최인준 CTO님과의 인터뷰를 통해 담아봤습니다.

개발팀 소개

안녕하세요 인준님, 먼저 가볍게 소개 부탁드려요. 처음에 어떤 기대로 커버링에 합류하셨나요?

커버링에서 기술 조직이 고객의 문제를 더 빠르고 안정적으로 해결할 수 있는 역할을 하고 있습니다.

커버링에 합류한 이유는 사람들의 문제를 해결하여 가치를 만드는 프로덕트에 관심이 가졌기 때문이에요. 그래서 여러 예비 창업자들을 만났었는데요. 그 과정에서 파운더인 성진님과 지훈님을 만나게 되었어요. 처음 만났을 땐 지금 커버링이 해결하고 있는 문제가 구체화되지 않았었지만 제가 지향하는 방향으로 일할 수 있을 것 같은 기대를 주시는 분들이라 합류하게 되었어요.

현재 개발팀이 어떤 구성으로 어떤 과제들을 고민하고 계신지 가볍게 소개해주시면 좋겠어요.

크게 보면 두 가지 과제를 풀고 있고 앞으로도 그럴 것 같아요.

하나는 제품 가까이에서 빠르게 실험하고 이터레이션 하는 일, 그리고 다른 하나는 그 속도를 유지할 수 있도록 개발 표준과 품질의 공통적인 기반을 쌓는 일이에요. 내부에서는 실험 영역과 안정화 영역으로 나눠 부르고 있습니다.

기술보다 문제 해결에 집중하는 것

지금 채용 중인 엔지니어 공고에 ‘특정 기술보다 문제 해결 방식 자체에 주목하시는 분.’ 이란 기준이 있잖아요. 기술 역량보다는 태도에 가까운 표현인데 왜 그 기준에 주목 하시는지 궁금해요.

사실 엔지니어 뿐 아니라 모든 직무에 공통적으로 적용되는 기준이라고 생각해요. 어떤 직무든 지속적인 가치를 만들어내고 제공하는 게 중요한 역할이라고 생각합니다.

엔지니어는 기술로써 가치를 만들어내는 사람이에요. 트렌드한 기술을 사용하더라도 아무도 사용하지 않고 시간은 시간대로 쓴다면 그것은 가치를 만든 것이 아니라 비용을 만들어 낸 것이죠. 기술 자체보다는 ‘처리를 편리하게 일상을 지속 가능하게’ 라는 커버링 미션을 달성하는 것에 가장 높은 우선순위를 두고 적절한 기술을 활용하는 게 중요합니다. 1만명의 문제를 푸는데 100만명을 위한 기술을 가져오는 것은 오버 엔지니어링이에요.

그렇다면 인준님께서도 기술적으로 더 좋은 방법을 알지만 미션을 달성하는 데 우선순위를 두고 다른 선택을 하신 일도 있으셨을 것 같아요. 그 때 어떤 고민을 하셨는지 듣고 싶어요.

처음 커버링의 제품들을 만들 때에도 선택이 가능했죠. 처음부터 아키텍쳐를 견고하게 설계해서 개발할 수 있음에도 불구하고 아직 제품 자체를 검증 하지 못한 단계였기 때문에 견고함 보다는 빠르게 개발하는 게 중요했어요. 그래서 구조가 아닌 기능 중심으로 정확히는 고객의 요구 사항 중심으로 개발했었어요.

최근 들어 커버링 제품이 크게 성장하고 개발 조직도 커지게 되었죠. 이제는 초기 방식을 유지하는 것이 비효율을 만들어 내고 있기 때문에 이제 구조를 개선하고 있어요. 클린 아키텍쳐를 적용하고 개발팀 내부의 표준을 마련해서 협업을 더 원활하게 하여 속도를 더 낼 수 있게끔 기반을 잡아나가고 있습니다.

제가 기술적인 의사결정을 할 때 주목하는 것은 투입하는 리소스 대비 만들어낼 수 있는 임팩트, 즉 ROI입니다. ROI를 판단하기 위해 결정을 얼마나 쉽게 되돌릴 수 있는지, 결정의 영향 범위가 어디까지 미치는지, 만약 잘못된 결정이 내려질 경우 바로잡는 비용이 얼마나 커질지 함께 고려합니다. 그 과정에서 지금 반드시 필요한 것과 나중으로 미뤄도 되는 것을 구분하고 우선순위를 정합니다.

충분한 검증이 이뤄진 제품이라면 지속적으로 리소스를 투자할 수 있습니다. 반대로 아직 검증되지 않은 단계에서 확장성과 재사용성을 과도하게 고려해 구조를 설계하는 것은 투자 대비 이득이 크지 않은 오버엔지니어링이에요. 완벽한 구조보다 문제가 발생하지 않을 최소한의 품질을 확보하면서 더 많은 제품 실험을 빠르게 수행할 수 있도록 만드는 것이 중요합니다.

결국 좋은 코드라는 건 얼마나 큰 가치를 줄 수 있는가에 달려있다고 생각해요. 기술적인 완성도만을 최적화하기보다, 한정된 시간과 개발 리소스를 어디에 투자했을 때 가장 큰 임팩트를 만들 수 있는지를 판단할 수 있어야 합니다. 그래서 저는 엔지니어 관점뿐만 아니라 메이커 관점에서 ROI를 판단하고, 필요하다면 기술적인 완성도를 의도적으로 내려놓을 수 있는 사람이 좋은 엔지니어라고 생각합니다.

고개가 끄덕여지면서도 한편으론 기술적으로 깊이 있는 경험이 어려운 것 아닌가 생각이 들기도 해요. 엔지니어가 기술적인 성장을 할 수 있는 순간은 언제일까요?

클라이언트와 서버 파트 미팅이 기술적인 성장의 기회가 될 수 있도록 신경쓰고 있어요.

미팅을 통해 서버 파트와 클라이언트 파트 내에서 미들, 주니어 엔지니어가 함께 기술적인 문제를 논의하고 표준을 만드는 경험을 하게 되는데요. 제품의 범위와 사용자가 늘어남에 따라 발생하는 성능, 운영 안정성 등의 기술적 문제들을 장기적인 관점에서 해결하려면 코드가 어떻게 바뀌어야 하는지 고민합니다.

더 나은 방향으로 코드를 작성하기 위해 어떤 것들을 챙겨야 하는지 논의하고 속도를 내는 데 있어 필요한 것들을 합의하고 기준으로 만들어서 그 기준 위에서 개발하는 것이 목표인 회의예요.

클라이언트 부채는 이제 조금씩 개선되는 과정에 있습니다.
확실히 파트 회의 전후가 많이 달라졌어요. 파트 회의의 가장 큰 장점은 ‘현재 코드를 돌아보는 일’을 할 수 있다는 점입니다. 지금 우리의 레거시 코드가 어디에 어떻게 있고, 어떤 것들이 일관성 없이 작성돼있고, 또 어떤 것들이 부채로 남아있는지, 그리고 내가 요즘 고민하는 것은 무엇인지 모두에게 공유가 됩니다. 그래서 우리가 어느 단계에 있는지 객관적으로 판단이 되고, 앞으로 실행할 것들이 결정돼서 한 곳에 계속 고여있지 않게 됩니다.
그리고 개인이 아닌 파트가 책임을 진다는 것도 더 좋은 방향으로 나아갈 수 있는 점인 것 같아요. 사실 각각 실험과 안정화 영역에서 개발을 빠르게 진행하다 보면, AI가 코드리뷰도 다 해주는 세상에서 동료가 작성한 코드와 내 코드를 비교해볼 시간이 많이 없습니다. 특히 ‘기준’이 명확히 잡혀있지 않아서 개인의 주관대로 개발이 이루어지는 경우가 많습니다. 여기서 ‘기준’이라는 게 AI에게 가이드라인을 주는 것도 있지만, 결국은 인간이 보고 이해하는 것이 최종 단계니까요.
제품이 성장하고 규모가 커짐에 따라 기술적인 고민의 깊이가 달라지리라 생각해요. 이걸 제일 기대하고 있습니다!

- 클라이언트 엔지니어 나연님

실험 파트를 담당하면서 실험 영역에서 구현하는 것과 코어 서비스 구조 간의 의존성을 줄이기 위한 고민들이 있었을 때가 떠오르는데요. 제가 생각한 방향에 대한 확신이 없어 서버 파트 회의에서 제 고민을 말씀 드렸고 다양한 의견을 제시해주셨습니다. 이를 바탕으로 원하던 방향으로 구현할 수 있었고 지금도 의견 주실 때마다 고민하며 개선해나가고 있습니다.
또 기술적인 챌린지가 주어져요. 서비스가 빠르게 성장하고 있는만큼 기존에는 문제 없었지만 이제는 부하가 걸린다거나, 레플리카 DB를 사용하면서 새로 발생하는 이슈들이 회의에 올라옵니다. 최근에는 배치 작업과 조회 API에서 발생하는 레플리카 충돌 이슈가 안건으로 올라와 해결했습니다. 원인 파악부터 로직/쿼리 개선, 추후 모니터링까지 실험 파트와는 또 다른 역량을 키울 수 있는 경험들을 할 수 있었어요.

- 백엔드 엔지니어 예진님

반대로 당장 급한 일은 아니지만 제대로 해두자고 공을 들인 작업도 있었을까요? 개발 관점에서 타협하지 않는 기준이 있으신지 궁금해요.

되돌리기 어려운 작업, 미치는 영향이 큰 작업일 경우가 그래요. 데이터 정합성 같은 사례인데, 데이터 정합성을 잘 쌓아 놓으면 개발하는 데 있어서도 데이터의 약속이 분명하기 때문에 오류가 발생할 가능성도 적거든요. 장애를 발견하고 복구하는 체계의 경우에도 처음부터 데이터를 잘 쌓아나가야 하는 경우예요.

보안이나 권한 등 안 챙긴다 해서 당장 문제가 되지는 않지만 문제가 될 경우에 큰 리스크로 다가오는 것들은 타협하지 않고 지키려고 합니다.

특히 커버링은 앱에서 발생하는 데이터와 실제 현장에서 이루어지는 행동이 직접 연결되는 O2O 서비스이기 때문에 데이터 정합성이 중요한데요.

온라인으로 제공하는 서비스는 잘못된 데이터나 로직을 발견했을 때 코드를 수정하거나 데이터를 보정하는 것으로 해결할 수 있는 경우가 많지만, 커버링은 데이터에 따라 라이더가 실제 현장에서 움직이고 운영이 이루어집니다. 한 번 현장에서 실행된 의사결정은 되돌리는 데 훨씬 큰 비용이 발생합니다. 잘못된 정보로 라이더가 현장에서 수거를 잘못 처리하면 이후 고객과 다시 커뮤니케이션하거나 재방문해야 하고, 경우에 따라 결제나 정산까지 함께 바로잡아야 합니다.

운영 의사결정 측면에서도 마찬가지입니다.. 커버링은 현장에서 발생한 데이터를 기반으로 운영 상의 문제를 파악하고 정책이나 프로세스를 변경해요 그런데 운영 프로세스는 한 번 변경하면 라이더 교육, 운영 정책, 고객 안내 등 여러 영역에 영향을 주기 때문에 변경 비용이 큽니다. 따라서 의사결정을 내리기 전에 데이터를 충분히 들여다보는 것이 중요한데, 애초에 데이터가 실제 현장의 상태를 정확하게 반영하지 못하고 있다면 올바른 의사결정 자체가 어려워집니다.

그래서 커버링에서는 데이터 정합성을 단순한 개발 품질의 문제라기보다, O2O 서비스를 안정적으로 운영하고 올바른 의사결정을 내리기 위한 기반으로 중요하게 보고 있습니다.

품질과 속도 사이의 균형

코드 품질과 출시 속도 사이에서 지금 개발팀은 어디쯤에 서 있다고 생각하세요?

기존에는 속도가 압도적으로 높았다면 균형을 맞추기 위해 품질을 신경쓰고 있습니다. 그래도 커버링은 스타트업이고 성장하는 서비스이기에 아직까지 완벽하게 만든 뒤에 내놓기 보다는 유저의 반응을 보면서 개선해야 하기에 속도에 좀 더 치중하는 시점이에요.

균형이나 적당함이라는 것이 어렵고 추상적이기도 하잖아요. 엔지니어 분들도 그 기준을 어렵게 느끼실 수도 있다고 생각해요. 균형을 어떻게 맞추길 기대하고 계세요?

저희도 이 부분이 어렵다고 생각해요. 그래서 품질과 속도를 몇 대 몇으로 가져간다는 식의 기준을 두고 있지는 않습니다. 결국 지금 만드는 게 어떤 성격의 것인지에 따라 달라지는 것 같아요

새로운 기능을 만들어서 유저의 반응을 확인하는 단계라면 처음부터 완성도를 높이는 데 시간을 많이 쓰기보다는 빠르게 내놓고 실제 반응을 보는 게 더 중요합니다. 반대로 결제나 정산, 데이터 마이그레이션처럼 한번 문제가 생겼을 때 영향이 크거나 복구하기 어려운 작업은 당연히 더 많은 시간을 들여서 확인합니다.

커버링은 특히 현장과 연결되어 있어서 이 차이가 큰 편이에요. 화면에서 발생한 문제는 수정해서 다시 배포할 수 있지만, 잘못된 데이터로 기사님이 작업을 진행하지 못하거나 고객에게 결제가 발생했다면 코드만 수정한다고 해결되지 않습니다. 이런 작업은 처음부터 조금 더 보수적으로 접근합니다. 즉, 미치는 영향은 항상 생각을 해야합니다.

반대로 모든 작업을 이런 수준으로 가져가면 스타트업에서 필요한 속도를 낼 수 없다고 생각해요. 그래서 엔지니어에게도 단순히 코드의 완성도를 높이는 것보다는 지금 이 작업에 어느 정도까지 시간을 쓰는 게 맞는지를 판단하는 것을 기대합니다.

그 기준도 처음부터 개인이 완벽하게 가지고 있을 필요는 없다고 생각합니다. PR이나 설계 논의에서 서로 판단을 맞춰가면서 팀의 기준이 생기는 거니까요. 저희도 계속 그런 경험을 쌓으면서 커버링에 맞는 속도와 품질의 균형을 찾아가고 있습니다.

답을 기다리기 보다 함께 찾아가는 것

새로 합류하실 엔지니어들께서 낯설게 여길 개발 문화가 있을까요?

커버링만의 방식은 아닐 수 있는데요. 엔지니어링 관점에서만 바라보는 게 아니라 메이커 관점으로 고려하는 게 필요합니다. 엔지니어가 기획을 받아서 그대로 구현하는 게 아니라, 왜 이 문제를 푸는 것인지 고객이나 현장에서 어떤 일이 벌어지는 지 이해하고 의견을 내야 합니다. 문제에 대해서 해결하고자 몰입할 수 있어야해요.

그리고 우선순위나 해결 방법이 빠르게 바뀔 수 있습니다. 한 번 요구사항이 정해져서 내려와서 개발하는 정석적으로 순서대로 개발하는게 아니라 PRD를 보고 PO에게 피드백하여 PRD 품질을 높이고, 그 변화에 맞춰서 실행 방법을 바꿔야 하는 방식이에요.

매 실험마다 그래서 오히려 특정 사례를 꼽기가 어렵네요😅 실험 영역에 있다보니 아무래도 플래닝할 때 같은 임팩트를 주더라도, 속도는 빠르게 유지하면서 개발 리소스는 줄일 수 있는 방법을 항상 찾고 있는 것 같아요. 하나의 팀으로서 제품을 성장시키기 위해 같은 방향을 함께 바라보고 있다고 느낍니다.
애자일하게 움직인다는 의미를 이해하고서는, 이제는 백로그를 받으면 자동적으로 ‘이게 최선의 방법일까?’를 되묻습니다. 실험의 의도와 목적을 달성할 수 있으면서도 더 좋은 다른 방법을 찾으면, 곧바로 PO와 디자이너에게 제시하는데 빠르고 적극적으로 수용해주십니다. 이렇게 스프린트 내에 매일같이 논의하다보면, 자연스레 ‘엔지니어’라는 직무보다는 내가 하나의 프로덕트를 같이 만들어나가는 일원, ‘메이커’가 됨을 깨닫습니다. 단지 내가 맡은 개발만을 하는 게 아니라 나도 모르게 제품의 성장을 기대하고 애정하는 과정에 빠져드는 것 같아요.
개발적인 부분이 아니라도 가끔 실험 자체의 목적성에 의문이 들 때도 있는데, 결국 중요한 것은 엔지니어도 설득되는 실험을 하게 된답니다. PRD는 절대 버전 1에서 끝나지 않는 법!

- 클라이언트 엔지니어 나연님

최근 실험 사례가 기억에 남는데요. 수거 신청 취소율을 낮추기 위한 쿠폰 발급 실험이 있었어요. 1)바로 신청한 경우에만 쿠폰 발급 가능 2)해당 주문에만 사용 가능 3)쿠폰 수정 또는 주문 삭제할 경우 쿠폰 삭제 라는 요구사항이 DB 구조상 불가능 했습니다.
그래서 의도는 살리되 개발에도 문제없는 다른 방안을 제시했습니다. 쿠폰을 삭제 하는 대신 특정 모달에서만 발급 가능하게 하고 쿠폰 유효기간을 짧게 가져가는 방식이었고, 이를 PO와 디자이너 분이 받아주셔서 원활하게 진행되었어요.
기능이 나온 배경과 의도를 생각하고 해결하려는 문제에 집중했기에 가능한 사례였다고 생각해요.

- 백엔드 엔지니어 예진님

운영까지 고려해야 하는 서비스의 특성 또한 낯설 수 있으실 것 같아요.

커버링은 고객 앱, 라이더 앱, 백오피스, 배치 등 여러 제품이 하나의 서비스 흐름 안에서 유기적으로 연결되어 있고, 그 흐름이 실제 현장까지 이어지는 O2O 서비스입니다. 그래서 하나의 문제를 해결할 때도 특정 제품이나 코드만 바라보기 어렵습니다.

예를 들어 현장에서 발생하는 문제 하나가 고객 앱의 경험, 라이더의 업무 방식, 운영팀의 처리 프로세스, 결제와 정산까지 연결될 수 있습니다. 따라서 “내가 맡은 서비스에서 요구사항을 구현한다”는 관점보다는, 실제로 해결해야 하는 문제가 무엇인지 정의하고 그 문제를 해결하기 위해 필요한 영역을 함께 살펴보는 방식으로 일해야 해요.

또 커버링에서는 역할에 따라 주로 맡고 있는 서비스나 제품이 있더라도 오너십의 대상을 특정 서비스로 제한하지 않습니다. 오너십의 대상은 서비스가 아니라 문제로 바라보고 있고 고객 앱을 담당한다고 해서 고객 앱 안에서만 해결책을 찾거나, 백엔드 엔지니어라고 해서 서버의 변경만으로 문제를 해결하려 하지 않아요. 문제를 해결하기 위해 라이더 앱이나 백오피스, 운영 프로세스까지 변경해야 한다면 그 범위까지 함께 고려합니다.

이러한 방식은 엔지니어가 정해진 요구사항을 전달받아 구현하는 수동적인 구현 조직과는 차이가 있습니다. 요구사항 자체가 적절한지, 실제 문제가 무엇인지, 어느 지점을 변경하는 것이 가장 효과적인지부터 함께 고민하고 얼라인한 뒤 해결책을 만들어갑니다.

그래서 처음 합류하면 하나의 문제를 해결하기 위해 고려해야 하는 범위가 넓다는 점이 낯설 수 있어요.

모든 엔지니어 분들이 커버링과 맞지는 않을 것이라 생각하는데요. 어떤 분들이 커버링에 적응하기 어려우실 것 같으세요?

정해진 답이 주어지기를 기대하는 엔지니어분은 커버링과 잘 맞지 않을 수 있다고 생각해요. 기획의 완성도가 부족하다고 느껴질 때 기획자만을 탓하기보다, 아직 답이 정해지지 않은 문제에 직접 뛰어들어 함께 답을 만들어갈 수 있는 분이어야 합니다.

이건 엔지니어에게만 해당하는 이야기는 아니에요. 커버링에서는 각자의 역할에 제한을 두고 머무르기보다 공동의 목표를 달성하기 위해 필요한 일을 함께 고민하고, 빠르게 시도하고, 때로는 치열하게 몰입하는 과정이 많습니다. 그래서 이런 과정을 즐길 수 있는지가 중요하다고 생각합니다.

우리는 하루의 상당한 시간을 커버링에서 보내고 있어요. 1년으로 환산하면 2,000시간이 넘는 꽤 큰 시간입니다. 이 시간을 단순히 해야 하는 ‘일’로만 여기기보다, 좋은 동료들과 함께 어려운 문제를 풀고 목표를 달성해 나가는 과정 자체에서 재미와 성취감을 느낄 수 있는 분과 잘 맞는 조직이라고 생각해요.

반대로 그 과정에서 몰입하거나 즐거움을 느끼기 어렵고, 주어진 역할과 업무를 수행하는 것만을 기대한다면 커버링에서 일하는 방식이 다소 힘들게 느껴질 수 있을 것 같습니다.

AI와 함께 하는 개발

다른 직무들도 AI를 활용하고자 노력하지만 사실 엔지니어 분들의 고민이 가장 클 것 같아요. 팀에서는 어떻게 AI를 활용하고 계신가요?

엔지니어들이 AI를 활용하는 방법에 관심이 많다 보니 열려 있어요. 새로운 것이 나왔을 때 팀에 적극적으로 공유하고 팀에 가져오기 전에 개인적으로 학습하고 활용하시는 분들이 많아요.

PRD 문서를 받았으면 그것을 읽는 데에도 AI를 활용하고, PRD와 현재 코드 베이스를 비교하며 PRD가 코드에 미칠 영향이나 실현 가능성을 체크하고 조사하는 거죠.

POC를 만드는 데 활용하기도 하고, PRD 기반으로 테크 스펙을 산출하고, 코드 작성하는 데에도, 정해진 리뷰 규칙에 따라서 AI가 승인을 하게 돼요. 과정을 마치고 문서화하는 것 또한 규칙에 맞춰서 AI가 작성하게 되죠.

AI로 많은 영역을 자동화 하시면서 리소스를 사용하시는 방향도 달라졌을 것 같아요.

가장 크게 달라진 점은 엔지니어가 판단하기 위해 필요한 근거를 확보하는 비용이 크게 줄었다는 것입니다. 결국 어떤 문제를 해결할지, 어떤 구조를 선택할지에 대한 최종적인 판단과 책임은 엔지니어에게 있습니다. 다만 그 판단을 위해 기존 코드와 데이터, 여러 제품 간의 의존성을 파악하고 검증하는 데 들어가는 시간을 AI를 통해 크게 줄일 수 있게 되었어요.

특히 신규 프로덕트로의 개편이나 대규모 마이그레이션처럼 기존에는 6개월에서 1년 정도를 예상해야 했던 작업의 속도가 크게 달라졌습니다. 커버링에서도 최근 서비스의 핵심 구조를 확장 가능한 형태로 개편하는 대규모 마이그레이션을 진행했는데, AI를 적극적으로 활용하면서 2개월이 채 되지 않는 기간에 주요 마이그레이션을 마무리할 수 있었습니다. 덕분에 엔지니어가 더 빠르게 다음 문제로 넘어가 실제 사용자에게 가치를 주는 프로덕트를 개발할 수 있게 되었죠.

앞으로의 개발팀.

인준님께서는 커버링이 엔지니어 분들에게 좋은 성장의 기회가 될 수 있을지 고민이 많으실 텐데요. 엔지니어 분들이 커버링에서 꼭 이것 만큼은 얻어갈 수 있도록 신경쓰시는 것은 무엇이세요?

기술을 잘 구현하는 것을 넘어 내가 만드는 것이 실제 가치로 연결되는 경험들을 커버링에서 얻어가셨으면 좋겠습니다. 단순히 기능 요구 사항을 받아서 개발하고 끝나는 것이 아니라 내 개발이 어떻게 목표에 연결되고 가치를 만드는지 고객들의 사용에 어떤 영향을 미치는지 경험해보았으면 좋겠어요.

또 커버링이 빠르게 성장하기 때문에 기술적인 챌린지가 계속 생겨나고 있습니다. 빠르게 성장하는 회사이기 때문에 가능한 일이라고 생각하고 만들어진 표준 위에서 일하는 게 아니라 함께 표준과 시스템을 만드는 경험을 하실 수 있길 바라고 있어요.

마지막으로 앞으로 회사가 성장하면서 개발팀, 그리고 엔지니어 분들은 어떻게 기여하시게 될까요?

비즈니스의 깊이와 넓이가 확장될 것이라고 생각해요.

깊이가 깊어진다는 것은 다양한 상황들을 이해해야 하고 개발팀은 그 복잡성을 데이터와 도메인 단위로 나누어서 안정적인 시스템으로 담아내야 해요.

넓이가 넓어지면 서비스의 접점이 많아지면서 해결해야 할 문제가 많아진다는 것이에요. 외부 연동이나 자동화, 내부 운영 도구 등 기술에 기여할 수 있는 영역도 넓어지지 않을까 싶어요.

글 | 한얼 커버링 HR 리드

Dtx, 교육, 커머스 스타트업을 거쳐 커버링에 합류했습니다. 합류하기 전 이미 커버링 멤버십 묘목 등급으로 서비스의 팬이었기에 덕업일치의 마음으로 일하고 있습니다.