프롤로그

1년동안 OKR을 통해 쉼없이 달려온 후 뒤를 돌아보니 정말 많은 것들을 해온 나를 볼 수 있었다.

2023년의 마지막 스프린트인 Sprint 18을 끝낸 뒤 나름의 뿌듯함과 약간의 아쉬움 등 많은 감정을 느끼게 되었다.

그런 김에 우리가 왜 OKR 방식을 도입했고 어떤 식으로 진행해왔는지, 그 과정에서는 아쉬움들이 있었는지를 말해보고자 한다.

우리가 OKR 방식을 도입한 이유

'우리들이 주도적으로 목표를 정하고 달성할 것들을 결정해보자. 우리가 훨씬 더 큰 도전을 이루고 많은 성취를 거둬보자'

기존의 진행해오던 중고거래 서비스에서 중고 패션에 집중하고자 리브랜딩을 거치고 OKR이라는 방식도 도입을 하기로 했다.

애자일 방식 도입

OKR을 설명하기에 앞서 우리는 애자일 방식을 도입하여 업무 프로세스를 다져왔다.

기존의 업무 방식은 데일리 스크럼 + 워터풀이었고, 목표가 없었다. 그저 각자의 자리에서 각자의 역할에 집중했을 뿐 가설을 세워서 목표에 도달하는 사람이나 책임을 지는 사람도 없었다.

또한, 우리의 속도를 알 수가 없었고 경험과 직관에만 의존하며 공수를 산정해야해서 목표한 일정에 릴리즈하기가 어려운 경우가 많았다.
만들어야 할 결과물이 명확하다면 기존 방식대로 각자의 위치에서 할 일만 하면 되기는 했다. 이런 상황이라면 워터풀 방식도 우리 핏에 맞는 방식이라고 할 수 있다.

하지만 서비스의 프러덕트를 변경하는 만큼 많은 시행착오와 여러 변경점, 그 과정에서 생기는 다양한 새로운 기능들이 우리 앞에 놓여있었다.

우리는 결과물을 알 수 없고, 빠르게 변화하고, 신속하게 실행하고 의사결정을 해야 하는 상황에 놓여있기 때문에 마라톤 보다는 전력질주(스프린트)를 조금씩 해보는 방식을 사용하며 애자일 프로세스를 도입하였다.
조금 달려보고 방향을 조금 수정해서 다시 달리면 되기 때문에 !

OKR이란

OKR에(Objective and Key Results) 대해 간단하게 설명하자면 조직의 목표와 그 목표를 달성하는 데 필요한 단계의 역할을 하는 결과물을 의미한다.

또한 OKR은 Agile Goal이라고 해도 무방하기에 Agile 프로세스를 도입한 기업의 핏에 잘 맞는다.

'Objective'라는 목표를 세우고,
그 목표를 달성했다고 판단할 수 있는 중요한 핵심 결과(Key Result)를 세 개 정도 세우는 방식이다.

애자일 형태와 잘맞는 OKR

OKR은 목표를 빠르게 수정하고 조정할 수 있기 때문에 기업이 변화에 빠르게 대응하는데 도움이 된다.
또한, 목표와 성과를 분명하게 정의하고 조직 내부의 모든 구성원이 목표를 이루기 위해 노력하도록 한다.

우리는 리브랜딩을 거치며 여러 시도들을 빠르게 실행하고 고객 중심적으로 소통하며 이슈 발생 시 최대한 빠르게 대응을 해야했다.

그렇기에 핏도 잘맞고, 실무자가 한 발 더 빠르게 시장에 대해 학습하고 주도적으로 프로젝트를 이끌어 나갈 수 있도록 환경을 조성하는 OKR을 도입하였다.

서비스의 프러덕트를 변경하는 만큼 동기가 필요했고,
동기 부여를 통해 더 높은 단계를 가고자 하는 팀원들이 모였고,
많은 시행착오와 여러 변경점, 그 과정에서 생기는 다양한 새로운 기능들이 우리 앞에 놓여있었다.

OKR 도입 후 과정

스쿼드 조직

각자 목표와 달성하고자 하는 대상을 각각 정하고 맡기위해 사업팀, 개발팀, 마케팅팀 등으로 이뤄져있었던 조직도에서 기획, 디자인, 개발 인원을 적절히 분배하여 각 스쿼드로 조직을 만들었다.

중고의류를 판매하는 입장에서의 목표를 달성하기 위한 셀러 스쿼드, 구매하는 입장에서의 목표를 달성하기 위한 바이어스쿼드(난 이쪽이었다.✌️) 등으로 나뉘어졌다.

3개월 단위의 목표 수립 및 측정

우리가 뭘 하겠다고 목표를 세웠더라도, 일하면서 목표와 프로세스는 언제나 변할 수 있다.
그렇기에 3개월이라는 다소 짧은 단위로 목표를 수립하고 측정을 하였다.
이렇게 세운 목표에 대한 일은 실제로 3개월 안에 끝났고, 목표와 프로세스가 달라진 후 새로운 방향을 설정하더라도 문제가 없었다.

각 스쿼드에서는 업무를 어떻게 진행했을까?

매일 아침 약 10~15분을 넘기지 않을 정도로 스크럼을 진행했다.
스크럼에서는 당일 할 일, 논의할 내용, 어려움을 겪는 부분을 팀원들에게 공유했다.
어려움을 겪는 부분이 있다면 스크럼이 끝난 후에 담당인원들과 함께 논의를 하고 도움을 주고 받았다.

OKR 도입 초반에는 스쿼드 전 인원이 모여 어떤 목표를 잡고 어떤 기능을 만들지를 큰 틀을 함께 기획하고 기획자 분들이 큰 틀의 세부사항들을 기획하신 후 공유 했고, 함께 리뷰를 진행했다.

리뷰 내용을 정리해서 기획자 분께서 기획 최종안을 공유하시면 디자인 인원들은 공수를 산정하고 작업에 들어간다.

이 때 개발인원들은 기획 내용을 보고 대략적인 공수를 산정해본 후 전 스프린트의 백로그를 처리하거나 이슈를 해결하고 리팩토링을 진행한다.

디자인 작업이 끝나면 함께 리뷰를 진행하고 개발자들은 공수를 공유한 후 개발을 하고 나서 QA를 진행한다.
배포를 다 하고나면 스프린트가 종료되고 마지막으로 스프린트를 회고한다.

회고 때는 개발 중 문서화를 한 것들이 있다면 공유하고, 지속할 것 (Keep), 해결할 것(Problem), 시도할 것(Try)등에 대해 얘기를 나누고 피드백을 가진다.

스프린트의 내용과 진행도 등 전반적으로 이슈들은 지라로 관리하였다.

이러한 과정들은 보통 5일 내로 끝나고 최대 2주를 넘기지 않았다. 만약, 공수가 너무 길어진다면 기획의 일부분을 수정하고 나누어서 다음 스프린트로 넘기게 된다.

좋았던, 배우게 된, 문제와 개선된 점 . . .

좋았던,

처음엔 내가 아이디에이션을 하는 과정들을 즐겨하는 것도 있지만, 다같이 목표를 설정하고 구체화하는 방안들을 자유롭게 제시하고 피드백하는 부분들이 흥미로웠다. 특히나 내가 좋아하는 패션에 대해서도 여러 이야기를 나눌 수 있다는 점이 좋았다.

업무적으로는 좋았던 점은 기존 업무 방식보다 확실히 '체계적'으로 일할 수 있었고, 오너십을 가지며 능동적이고 주체적으로 일할 수 있었다.

또한, 해결하기 어려운 점이 닥쳤을 때 스크럼을 통해 여러 팀원들과 논의를 하여 전보다 비교적 쉽게 도움을 받을 수 있었고 시니어 개발자분들도 서슴없이 주니어 개발자들에게 논의를 요청하며 의사소통이 더욱 활발해졌다.

배우게 된,

개인적으로는 공수를 파악함에 있어서 기존에는 어렴풋이 정하고 그로인해 작업 시간이 많이 늘어나는 경우가 많았고 프로답지 못한 모습들이 많이 보였다. (경험이 부족하다는 말로 핑계를 ...)

하지만 작은 단위의 기능들로 컴팩트하게 스프린트를 진행하다 보니 정밀하게 공수파악을 할 수 있었고, 원활한 커뮤니케이션으로 인해 타 플랫폼의 일정도 고려할 수 있었다.

또한 디자이너, 기획자와 개발자 간의 커뮤니케이션 역량도 강화할 수 있었다.

비개발자들과의 소통은 개발자들 간의 소통보다 더욱 디테일하면서 쉽게(?) 말씀을 드려야 했고 쉽게 설명하는 것은 곧 '내가 더욱 잘 알아야 한다'는 마음을 갖고 기존에 알던 것도 더 공부하게 되었다.

물론 시행착오도 굉장히 많았다. 초반에는 공수 산정에 있어서 당장 앞에 있는 기능보다 유지보수를 위한 탄탄한 설계를 '무조건'적으로 1순위로 두거나 오버엔지니어링을 하는 바람에 배포 날짜를 연기하게 되는 사고가 일어나기도 했다.

그래서 주위 개발자분들에게도 노하우도 여쭙고 공수산정과 오버엔지니어링에 대해 공부도 했다.

1) 공수 산정 시 계획한 작업들이 오버엔지니어링이 아닌지?
2) 개발 진행 시 꼭 필요한 작업들인지?
3) 리팩토링 기간에 해도 될만한 규모인지? 를 파악 후
4) 배포 일정을 얼마나 확보할 수 있는지에 대해 스크럼 시 논의를 하였고 차츰 배포일정은 안정스러워졌다.

시행착오

문제

대부분의 업무 프로세스가 너무나도 만족스럽고 재미있었지만 몇가지 아쉬운 점이 있었다.

일정

배운점에서 말했듯이 어느정도 안정화가 되었고, 나의 판단 미스인 것도 있었지만 확보할 수 있는 일정 자체가 조금은 촉박했다. 이것은 사실 업무 프로세스 즉, 애자일과 스프린트 방식에 대한 문제는 아니긴 하였다.

우리는 투자를 받기 위해 열심히 빠르게 새로운 기능을 개발하여 탐낼만한 프러덕트를 만들어내야했기에 당연한 수순이기는 했다.

하지만 이렇기에 테스트 코드를 작성하는 것은 오히려 불필요한 프로세스가 되어버렸고, 리팩토링 기간을 못가져가는 경우도 있어서 업무시간 외에 진행해야 했었다.

사공이 많으면 배가 산으로 간다

스크럼 시 기획, 디자인, 개발자들이 함께 큰 틀의 기획을 논의하고 리뷰를 하다보니 새로운 아이디어가 많이 나오고 의견들과 피드백이 많아졌다. 이 점이 좋기도 했지만 스피커(Speaker)가 많다보니 아젠다가 산으로 가는 현상도 종종 일어났었다. 간혹 스크럼이 스크럼이 아니게 되는,,, 30분도 넘어가는 상황도 발생했고, 이는 시간이 급한 우리에게 좋지 않은 모습이었다.

물론 트레이드 오프(Trade-Off)가 있기는 하지만 시간이 우선순위에 있었고, 다소 자유분방한 의견들은 독이
되는 경우가 많았다.

공유

스쿼드를 나눠서 기획하고 개발을 진행하다보니 각 스쿼드끼리 진행한 내용에 대한 인지가 부족했다.

물론 배포를 할 때마다 작업 내용들을 간략하게 공지하기 때문에 어떤 기능인 지는 알았지만, 어떤식으로 동작하는지 왜 진행을 했는지에 대한 의문은 풀리지 않았다.

개선점

시간 비용을 아끼기 위해 초반에는 의견들이 아젠다에서 벗어나지 않도록 서로 주의하였고, 나중에 가서는 리뷰만 함께 하도록 하고 기획은 기획자들끼리 논의하도록 변경되어 시간 비용을 절약할 수 있게 되었다.

내용 공유에 관한 개선점은 기획 및 디자인에서는 큰 틀에 대한 리뷰를 모든 스쿼드의 기획/디자인 인원들이 함께 참여했고, 개발자로서의 공유는 서로 코드리뷰를 좀 더 디테일하게 하고 리뷰이들은 변경사항에 대해 좀 더 세부적으로 작성하였다.

또한, 리뷰어들은 코드리뷰를 하며 추가/변경된 기능을 실행해보며 궁금증에 대해 리뷰이에게 자유롭게 물어보며 서로가 하는 일에 대해 자세히 알 수 있었다.

마무리

혹여나 위와 같은 상황을 들어가시는 분들이 있다면 문제점들에 대해 한 번씩 참고하셔도 좋을 것 같다.

개인적으로는 쉼없이 열심히 달려왔고 다소 급하게 달려온 감도 있었지만 그 과정속에서 굉장히 많은 것들을 배웠고 일에 대한 오너십도 다양한 형태로 느낄 수 있었던 1년이었다.

앞으로도 이러한 경험들이 나에게 굉장한 영양분이 될 것이라고 굳게 믿고 있고! 이런 경험을 접할 수 있는 많은 기회를 만들어 나가야겠다.