소프트웨어 엔지니어링 팀에 혁신을 요구하는 기업이 많다. 하지만 지금과 같은 경제 상황에서는 다른 면모를 강조해야 할 필요도 있다. 그건 바로 안정성이다.

[보안뉴스 문정후 기자] 엔지니어의 역할에 대해 오해하는 사람들이 많다. 많은 이들이 엔지니어를 하루 종일 앉아서 코드를 만지작거리며 뭔가를 만들고 수정하고 어디론가 납품하는 사람으로만 알고 있다. 잘 몰랐겠지만 우리 엔지니어들은 이것보다 훨씬 많은 일들을 처리하고 있다. 그리고 그 ‘훨씬 많은 일’이라는 건 사업의 확장에 이바지하는 것이라고 정의할 수 있다.


경제적으로 불안한 시기가 끝나지 않을 것처럼 보이는 이 때, 기업들은 사업 전략을 이리 저리 바꾸는 중이다. “이런 시기에도 성장을 이어나가려면 어떻게 해야 하는가”라는 고민을 가지고 전략들을 수립하고 수정하고 폐기한다. 엔지니어링 팀을 이끌고 있는 사람이라면 이 질문에 대한 답으로 다음 세 가지를 제시할 수 있다. 1) 제품 로드맵 수립, 2) 팀 운영 최적화, 3) 정량적 성과 평가 방법 정의.

제품 로드맵 분석
경제가 불안한 상황에서도 기업이 살아남을 뿐 아니라 오히려 성장하려면 가장 필요한 게 제품 로드맵이다. 제품과 서비스에 대한 기획과 계획이 있어야 한다는 뜻인데, 사실 이거 없는 회사는 거의 없다. 문제는 작년에 만들었던 것이 올해의 상황과 전혀 맞지 않을 가능성이 높다는 것이다. 그러므로 우선순위를 새롭게 정립하는 단계를 다시 거쳐야 하며, 핵심 제품 및 서비스가 전략의 한 중심에 있도록 다시 한 번 확인해야 한다.

이 때 충성 고객이 많은 기존 서비스나 제품에도 투자를 소홀히 하지 말아야 한다. 그런 충성 고객이야 말로 기업의 가장 큰 자산 중 하나다. 관리하려면 그들이 사용하는 제품과 서비스가 계속 좋은 것으로 남아 있어야 한다.

로드맵 작업을 할 때 주의해야 할 것이 하나 있는데, 시장 규모를 확대하는 것과 시장 내에서 경쟁력을 확보하는 것에는 분명한 차이가 있다는 것이다. 이 둘을 같은 것으로 혼동하는 경우가 많다. 사업을 정신없이 진행하다 보면 어느 새 이 두 가지를 같은 것으로 여기고 일을 진행하게 되는데, 제대로 된 로드맵이 없어서 이런 일이 벌어지기도 한다. 경쟁력을 높인답시고 성급하게 분야를 확장시키다 보면 큰 손해를 보고, 심지어 기업이 휘청거리게 만들 수도 있다.

경제가 불안하고 자본도 넉넉하지 않은 상황에서 돌파구를 찾겠다면서 새 서비스와 제품을 기획하는 것 역시 대부분의 경우 좋은 결과를 내지 못한다. 잘하고 있던 것, 예전부터 계획이 세워져 있던 핵심 제품이나 서비스에 투자될 자원을 일부 빼돌리게 되는 것이고, 심지어 애초에 자원이 넉넉하지도 않아 이도 저도 아닌 것으로 결론이 날 때가 많다. 그 동안 잘 해왔던 기본 서비스와 제품, 핵심 전략 사업에 꾸준히 투자하는 것이 보다 안전하다.

엔지니어들은 기존 것을 유지하는 것보다 새로운 것, 차세대 히트 상품을 기획하는 것에 훨씬 큰 매력을 느낀다. 그 충동을 이해하지 못할 것은 아니나, 지금은 그것을 잠시 재워두어야 할 때다. 새로운 것에 대한 열망은 분명 필요한 요소다. 하지만 그것이 아무 때나 발현되는 것은 적절하지 않다.

팀의 최적화
코로나 이후 경제 침체가 장기화 되면서 사업 운영의 기본은 ‘적은 것으로 많이 거둔다’이 되었다. 엔지니어링 팀의 기존 인력을 유지하면서(즉 새로운 인원의 추가 영입 없이) 더 많은 결과와 성과를 내라는 뜻이 된다. 답은 더 많은 야근일까? 아니다. 자원을 가장 올바른 곳에 절절히 배치하고, 최대의 효율을 거두는 방법과 프로세스를 정착시켜야 한다.

많은 기업들에서 기능별로 팀을 꾸리는 걸 선호한다. 프론트엔드 엔지니어 팀 따로, 백엔드 엔지니어 따로, 각 제품별 엔지니어 따로, 이런 식이다. 최근에는 ‘풀 스택 팀(full-stack team)’이라는 팀 구성론이 힘을 얻고 있다. 팀 하나에 각 기능별 전문가를 다 배치시켜, 그 팀이 온전하게 한 프로젝트를 소화할 수 있게 하는 것이다. 한 팀 한 팀이 독립적 사업부와 같은 역할을 하도록 유도하는 것인데, 여러 기업들에서 꽤나 효과적이라는 피드백들이 나오고 있다.

물론 이 풀 스택 팀 방식이 만능인 건 아니다. 제품이나 서비스, 기업의 특성이나 지역의 문화에 따라 기능별로 팀을 꾸리는 게 나을 수도 있다. 다만 풀 스택 팀을 꾸려 특정 제품이나 서비스의 사업을 통째로 맡기게 된다면 해당 제품/서비스에 대한 주인의식이 발동되고, 이 때문에 더 나은 결과가 나오는 것이 꽤나 여러 조직에서 목격되고 있다는 걸 강조하고 싶다. 그러므로 상황에 맞게, 가장 적절한 팀 구성을 해야 한다. 인력을 늘리고 근무 시간을 늘리는 것만이 아웃풋을 늘리는 방법이 아님을 기억해야 한다.

사실 요즘 ‘디지털 경제 시대’이기 때문에 엔지니어링 팀들이 조직 내에서 갖는 힘은 점점 커지고 있다. 그러니 엔지니어링 팀이나 IT 팀만이 아니라 전체 조직 내 팀들의 효율성까지 고민할 수 있어야 한다. 그렇지 않으면 모든 일들이 결국 엔지니어링 팀에게 돌아와 병목 현상이 생기는 걸 막을 수 없게 된다. 조직 전체가 이런 상황이라면 IT 팀 혹은 엔지니어링 팀이 아무리 잘해봐야 소용이 없다. 팀의 효율을 추구하다보면 언젠가 조직 전체의 효율까지 고민하는 스스로를 발견할 수 있을 것이다. 미리 고민을 해 두는 것도 나쁘지 않다.

정량적 평가가 가능해야 한다
로드맵도 가지고 있고, 팀도 효율적으로 기능을 발휘하기 시작했다. 그렇다면 결과에 대한 평가를 진행해야 한다. 로드맵을 짤 때부터 이 평가 부분을 고려하는 게 좋다. 평가라는 건 반드시 측정이 가능해야 한다. 정성적으로 ‘잘 되고 있어’라거나 ‘잘 안 되는 거 같아’라는 식으로 평가해서는 죽도 밥도 안 된다. 팀 내 모든 사람이 지금의 상황을 명확히 이해하려면 평가가 구체적이고 정량적이어야 하며 투명하게 공유되어야 한다.

필자가 근무하는 곳에서는 WLU라는 지표를 매우 중요하게 여긴다. 주별 학습자 수(weekly leraning users)라는 건데, 자신의 인사이트를 공유해 1주일 안에 자신을 포함하지 않은 최소 두 명의 다른 사용자가 소비하도록 하는 사람의 수를 의미한다. 즉 사용자들 중 꽤나 영향력이 있는 부류들을 식별할 수 있게 해 주는 지표인 것이다. 이들이 사용자들 사이의 여론과 결정에 매우 중대한 역할을 하고 있다고도 볼 수 있다. 여기서 사용자는 팀원이 될 수도 있고, 다른 부서의 일반 임직원일 수도 있다.

그 다음으로 중요하게 보는 지표는 WCU다. 주별 협업자 수(weekly collaborative users)라는 의미로, 시장에 나와 있는 협업 도구를 사용하는 사람들의 수를 나타낸다. WLU와 밀접한 관계를 가지고 있기도 하다. 엔지니어링이라는 업무가 워낙 ‘협업’ 없이는 성립되지는 않기에 신경 쓰는 지표이기도 하다. 이를 통해 협업의 효율과 활성화 정도를 가늠할 수 있게 되며, 따라서 업무 효율을 높이기 위해 어떤 협업 도구에 투자해야 하는지를 판단할 수 있게 된다.

시장을 뒤흔들 혁신적인 제품을 만드는 건 모든 기업들의 꿈이다. 하지만 그렇게 하기 위해서는 재능과 장인정신, 팀 워크와 예산 등 모든 조건이 딱 맞아떨어져야 한다. 불가능한 건 아니지만 경제 상황이 불안할 때는 이 중 한두 개가 삐걱거리기 쉽다. 혁신의 리스크가 커진다는 뜻이다. 그럴 때는 효율성에 집중을 하면서 혁신의 아이디어나 잠재력을 계속해서 저장해둘 필요도 있다.

글 : 샤디 로스타미(Shadi Rostami), 부회장, Amplitude
[국제부 문정후 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>