brunch

라이킷 12 댓글 공유 작가의 글을 SNS에 공유해보세요

You can make anything
by writing

C.S.Lewis

재즈에서 클래식으로

by 정주홍 Nov 30. 2024

스타트업에서 일하는 사람들이 자주 호소하는 어려움 중 하나는 바로 체계 없이 일해야 한다는 점이다. 체계가 없으면 업무 방식이 그때그때 달라지거나 각자의 역할이 명확하지 않아 책임 소재가 모호해지는 등 혼란이 발생하기 쉽다. 따라서 체계가 없어서 혼란스럽고 불안하다는 감정은 충분히 이해할 수 있다. 하지만 체계를 갖추는 것 역시 장단점이 있기 때문에 무조건적으로 체계를 만드는 것이 능사는 아니다.

체계를 갖추는 과정을 개발자의 관점에서 코드 재사용성을 높이는 작업에 비유할 수 있다. 많은 개발자들이 재사용성을 높이려다 오히려 유지보수가 어려워지는 경험을 한 번쯤은 해봤을 것이다. 예를 들어, API A, B, C에서 동일한 로직을 처리하고 있다고 가정해 보자. 이 로직을 수정해야 할 일이 생기면 여러 곳의 코드를 일일이 손봐야 하기에 불편함을 느낀다. 그래서 이 로직을 함수나 클래스로 묶어 공통화한다. 하지만 공통화를 끝낸 후, 갑자기 API A에서만 로직이 달라져야 한다는 요청이 들어오면 상황은 복잡해진다. 이미 공통화된 로직을 API A에만 다르게 적용하려면 더 많은 노력이 필요해지기 때문이다.

이 사례에서 알 수 있듯, 로직을 공통화하려는 노력은 했지만, 이후 발생한 요구 사항 변경 때문에 오히려 더 큰 부담이 생긴다. 물론 "처음부터 추상화를 잘했으면 됐을 것"이라는 이야기도 가능하겠지만, 이번 논의에서는 이 부분은 넘어가자. 체계를 만드는 주제와 연결해 보면, 체계를 만들기 위해 노력은 노력대로 들이고, 새로운 상황을 대응하는 것도 어렵게 만드는 결과를 초래할 수도 있다는 점에서 비슷한 맥락이다. 아마 많은 사람들이 비슷한 경험을 해봤을 것이라 생각한다.

따라서 체계를 갖출 것인지 고민할 때는, 지금 체계를 만드는 결정이 정말로 효율적인지 신중히 따져봐야 한다. 섣불리 체계를 만들면, 체계를 만드느라 노력도 많이 들이고, 이미 바쁜 상황에서 체계를 유지·보수하느라 오히려 더 비효율적인 상황에 빠질 수 있다. 반대로, 체계를 만드는 시기가 너무 늦어지면 그동안 발생하는 업무 처리 오류나 동료들이 겪는 어려움이 지속될 위험이 있다.

그렇다면 체계를 갖출 것인지 여부를 판단하는 기준은 무엇일까? 솔직히 말해, 나도 명확한 기준을 제시하기는 어렵다. 다만, 대략적으로 생각해 보면 다음과 같은 요소들을 고려할 수 있다. 해당 업무가 얼마나 반복적으로 발생하는지, 대부분의 업무 유형이 파악됐는지, 새로운 변수가 생겨도 예외 처리가 가능한지, 체계에 따라 일했을 때 발생할 수 있는 리스크는 어느 정도인지 등이다. 이는 앞서 언급한 코드 재사용성을 높이는 결정과도 비슷한 고민이다.

나는 종종 체계를 만드는 과정을 재즈에서 클래식으로 일하는 방식으로 전환하는 것에 비유하곤 한다. 재즈는 대략적인 흐름 속에서 즉흥적으로 연주를 잘 해내는 것이 중요하고, 클래식은 정해진 악보를 따라 연주를 완벽히 해내는 것이 중요하다. 이 둘은 단순히 다를 뿐, 어느 쪽이 더 우월하다고 평가할 수 있는 문제는 아니다.

내가 다니는 회사에서도 체계가 잘 잡힌 업무와 그렇지 않은 업무가 공존한다. 중요한 것은 무조건 클래식처럼 체계를 갖추는 것이 아니라, 효율성을 기준으로 판단하는 것이다. 체계가 없어서 불안하다는 이유만으로 체계를 만들려는 것은 잘못된 선택일 수 있다. 재즈가 더 효율적이라면 재즈로, 클래식이 더 효율적이라면 클래식으로 일하는 것이 옳다.

작가의 이전글 대기시간 안내판 하나로 모두가 행복해진 이유

브런치 로그인

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari