어정쩡한 확장하면 결국 원래 하던 사업으로 돌아가게 된다

과거 경험 이야기다. 이력서 쓰다보니 든 생각이다. 잡소리로 들어줬으면 하는 글이다.

2010~2011년 당시, 사람들이 미친듯이 모바일 앱 개발에 빠져들고, 모든 걸 앱으로 개발하고자 하고 했던 미쳐돌던 시절의 이야기다.

요즘은 이미 뻔히 아는 사실이지만, 모바일 앱은 앱 하나당 하나의 기능만 제대로 지원하면 된다. 앱 하나가 이 기능 저 기능 다 가지고 있을 필요는 없다. 예를 들어, 배달의 민족의 경우에는 배달 기능 하나에만 집중한다. 바코드 인식 프로그램들은 바코드 인식해서 내용만 잘 보여주고 하면 된다.

그런데 저때 당시에는 그냥 이것저것 다 집어넣고 해서 일부러 쓸데없이 앱 사이즈를 막 키우고 했던 앱들이 많은 거 같다. 윈도우 프로그램 개발하던 것과 같이, 그냥 자기 회사의 기능이면 이것저것 막 집어넣고 했던 그런 느낌. 자기들 앱이 모든 걸 다 지원해줍니다 같은 형식으로 마구잡이로 집어넣고 했던 그런 기능들이 엄청났다. 그래서 앱 하나에 거의 포탈을 방불케하는 여러 기능들을 마구잡이로 집어넣는 그런 앱들도 무지 많이 개발되었다. 당연 높으신 분들의 생각없는 결단에 의한 것이다.

특히, 자기들만의 솔루션이나 사업 아이템이 기존에 있던 업체들은 모바일 앱을 통해서 그 당시에 엄청나게 막 확장해보고 하려고 미친듯이 돈을 써붓고 그랬다. 그래서 보면 특정 기능을 강조한 앱들도 많았지만, 해당 회사를 강조하여 한 앱에 여러 기능들을 무리하게 막 집어넣고 작업한 앱들도 무지하게 많았다. 지금 생각해보면 그런 회사들이라도 개발에는 돈을 많이 쓰려고 노력했던 거 같다. 싸게 들이던 비싸게 들이던 말이지…

근데 나중에 어느 정도 인기가 식고, 모바일 앱들 중에 유명해지거나 좋은 케이스로 소개되고 하는 것들이 선택과 집중에 의해 특정하게 사용자들이 원하는 기능만 충실하게 지원하는 그런 앱들이 유행하고 하다 보니, 그냥 자신들의 솔루션이나 제품에 맞는 기능만 제대로 하면 그 외에는 무리한 확장을 하려 하지 않은 거 같다. 사용자들도 어느 정도 스마트폰의 사용에 대해서 많은 정보를 알게 되고, 그들이 그대로 회사의 직원들이 되고 하다보니 좋고 나쁨이 뭔지 정확하게 알게 된 것이다. 그 뒤로도 막 잡다한 기능을 넣어야 한다 아니다 라고 하는 건 이젠 의미없는 그런 일들이 되어가고, 그때 당시에 개발했던 수많은 것들은 그냥 잡 노가다가 되어버린 그런 분위기이다.

기존 경험 이야기이다. 당시 했던 잡다한 것들보다 결국은 그 회사의 솔루션을 모바일에 확장시켰던 기능 하나 제외하곤 다 쓸모없게 변해버린 것들을 보니 여러모로 씁쓸해서 적어봤다. 이런 걸 바로 무리한 확장 실패라고 여긴다. 당시에 모바일이 확 유행하면서 모바일도 제공한답시고 해서 제대로 자기들의 솔루션만 제공해서 이미지를 얻는 것만 해도 대단한 것 같다. 반대로, 무리하게 쓸데없는 기능들을 여러모로 확장하고 하면 그 쓸데없는 기능에 대해서는 별 볼일 없는 그냥 잡다한 기능밖에 되지 않는다는… 오히려 그 기능을 전문으로 하는 회사들의 솔루션에 밀려서 아무 쓸모도 없는 그런 기능들이 되곤 했다.

그런 것들 싹 다 지나가니, 결국은 자기들이 원래 제대로 하던 사업으로 돌아가게 된다. 개발자들한테는 개발 경험과 함께 사업과 프로젝트에 대해서 여러모로 돌아보게 되는 좋은 기회였다고 본다. 어정쩡한 개발보다는 선택과 집중이 중요하다는 걸 그때 제대로 보여준 거 같아서…

그리고, 지금 또 그런 부분이 될만한 기술이 충분히 있는데… 그거 잘못까면 어떤 ㅄ업자들이 “암호화폐 꼭 필요한 거거든요! 블록체인하고 분리해서 생각 못하거든요!” 하면서 날 토론장에 몰아넣겠지…

Advertisements

관리자의 프로그래밍

굉장히 안타까운 걸 너무 많이 봐서… 좀 착각하시는 분들이나 이런 상황에 못 헤어나오는 분들을 위해서 글을 적어봅니다. 내용은 지극히 제 주관적일 수 있지만, 한번쯤은 좀 생각해 볼 만한 이야기 같아서 적어봅니다. 딴지 걸고 싶은 분들이나 의견 있으신 분들은 댓글 달면 제가 댓글 내용 승인해서 내용 공유를 해보겠습니다.

개발자들이 흔히들 말하는 것 중에 이런 이야기가 있다. 바로 “백발까지 프로그래밍 하고 싶다.”라는 것이다. 개발이 너무 좋아서, 갈때까지 가보고 싶어서 다들 이런 소리 하나씩은 하고, 한번쯤은 꼭 품에 안고 간다.

근데 지금, 이 때까지 관리자나 팀장 자리에 있으면서도 불구하고 사원, 주임급 개발자랑 동등한 수준의 코딩을 계속해서 하고 나가면서 팀 관리는 팀 관리대로 요구받는 개발자들을 많이 볼 수 있다. 근데 이분들이 하는 방식이 내가, 우리가 아는 그 끝까지 프로그래밍 하는 그런 모습이었을까란 생각이 들었다.

관리자라고 해서 바로 관리자가 되지 않는다. 초반에는 프로그래머, 혹은 코더로부터 시작해서 실력을 쌓고 경력을 쌓아가다 보면 어느 샌가 진급을 하게 되고, 프로젝트 단위로 볼 수 있는 프로그래머로 성장하게 된다. 그렇게 되다 보면 관리자 자리에 앉아 있게 된다. 문제는 여기서부터 시작된다.

관리자가 되면서 코딩을 완전히 손을 떼는 개발자들도 생기고, 그렇지 않는 개발자들도 생긴다. 관리자가 되면서 손 떼는 경우에는 여러모로 말이 많기도 해서 안좋은 경우가 엄청나게 많이 나열되어 있다. 지시를 해야 하는 젊은 개발자들과 개발에 대해서 말이 조금씩 안통하기 시작한다던가, 최신 개발 환경에 대해서 어두워지는 경우가 생기기도 하고 개발 문제 시 생기는 부분에 대해서 이해도가 떨어지는 등 여러모로 골치아픈 경우가 많이 생기게 된다. 따라서 관리자라 하더라도 프로그래밍을 어느 정도 해야 한다는 것은 여러모로 많이 퍼져있다. 필자도 이 부분에 대해서는 찬성을 하는 부분이다.

자, 이제 관리자도 개발을 한다고 치자. 그러고 보니 이젠 관리자한테는 업무량이 배로 늘게 되었다. 개발도 해야 하고, 팀 관리를 위한 관리자의 업무도 주어지게 된다. (팀 관리가 얼마 안될꺼라고 생각하는가? PM의 일이 얼마 되지 않을꺼라고 생각하는 사람들은 개발 경험이 전무하다거나 학생 수준이라고 보겠다.) 이런 상황에서 팀장에게는 선택지가 주어지게 된다. 바로 본인의 참여도를 조정하는 정도에 따라 어떤 방식으로 일을 하냐를 선택할 수 있다.

내가 바라보는 문제가 이제 여기에 발생한다. 개발을 자기 팀원들과 똑같은 수준으로 하게 되다보면 관리자 업무를 야근으로 땜빵하는 관리자들이 존재하게 된다. 의외로 손이 모자란다는 회사들에서는 관리자 분들이 똑같은 수준으로 개발 일정을 본인 것까지 잡고 관리 업무에 대해서는 야근을 하는 등의 땜빵으로 처리하는데, 이렇게 되면 관리 업무에 있어서 본인의 관리가 소홀해지는 경우가 생기는 것이다. 즉, 팀원들에 대한 관리는 하면서 정작 이분들 스스로에 대한 관리기능이 전무한 상태가 되는 것이다.

일단, 관리자들은 프로그래밍을 어느 정도까지 할 수 있어야 하는지를 묻는다면, 난 현업에 투입되어소 아무 막힘 없이 개발할 수 있는 실력이 있어야 한다고 주장한다. 그러나 이런 실력이 있다고 해서 그래도 투입되어서 개발하는 게 좋다고는 생각되지 않는다. 오히려 몇몇 파트를 제외하고는 개발에는 깊게 들어가면 안된다고 본다.

필자인 내 주장으로는 우선 팀장은 팀원들의 진행상황을 확인하고 관리해야 한다. 그리고 그에 따른 리스크 또한 계산해 둬야 하고, 해당 코드들을 결합하는 작업에 대해서 들어가는 것이 맞다고 본다. 그 중에서도 심각하게 생각하는 것이 바로 프로젝트의 문제, 즉 이슈에 대한 대응과 그에 따른 리스크 관리에 대해서 심각하게 보고 있다.

팀원들의 수준은 여럿 존재할 것이다. 주니어 개발자부터 시작해서 시니어, 어드밴스까지 다양하게 존재하는 개발자들이 개발을 진행하면서 서로의 문제를 공유하고 그에 따라 그들이 쉽게 해결할 수 없는 문제가 발생할 것이다. 이것은 그대로 이슈화 되고 리스크로 이어진다. 이럴 때, 관리자가 들어가서 개발을 하거나 하면 맞다고 본다. 특히, 문제 해결을 위한 능력은 아무래도 관리자가 좀 더 경험에 의한 해결을 더 할 수 있기 때문이다. 경력 있는 개발자들이 알고리즘 문제를 풀거나 문제 해결능력을 요구받는 것은 바로 이런 부분에서 조금이나마 경력 있는 사람들이 그렇지 않은 사람들과 해결 방법이나 능력이 다르기 때문인 것이라고 이해한다. 관리자의 조언 혹은 관리자가 생각하는 해결책을 제시해 줌으로써 해당 팀원 개발자가 그 내용을 이해해서 오류나 이슈를 수정할 수 있다면 확실히 처리할 수 있게 되는 것이다.

이때, 관리자에게도 문제 해결을 위한 어느 정도의 프로그래밍 실력(프로그래밍 언어의 스킬과는 관련이 있긴 하지만 많다고는 생각하지 않는다.), 문제 해결 능력이 없다면 여기서 생긴 이슈는 상당히 위험한 이슈가 되는 것이다. 팀원이 여럿 달려들어서 해결해야 하는 문제가 되는 것이다. 이런 이슈가 발생하면 이 이슈를 해결하기 위한 시간과 인력이 필요할 것이고, 이는 또 관리와 보고의 대상이 된다. 프로그래밍을 할 줄 알고 문제 풀이 능력이 되는 관리자라 해도 이런 일이 생기면 또 다른 관리 항목이 늘어나게 되는 것이다.

이런 상황에서 만약 관리자가 팀원들과 동일한 수준으로 개발 스케쥴을 잡고 개발을 진행한다? 매니지먼트에 대해서 바로바로 대응 못하고 뒤에 남아 야근으로 몰아서 관리한다? 관리자의 입장에서는 언제 터질 지 모르는 리스크를 안고 가는 것이라고 생각한다. 팀원 개발자들이 뭐 슈퍼천재라서 뭐 개발만 하면 아무 문제없이 전부 다 되고 그러면 모를까, 현실에서는 그럴 일은 없다.

여기에 회사에서 팀 평가 방식으로 한국식 평가지표들을 끼고 들어서면 그때는 진짜로 미친다. 특히 숫자로 제시하라 뭐하라 그러면서 KPI 지표 만들어서 매달 결과 보고 하거나 하면 어차피 진행사항이 최고 100%까지 밖에 안되는 개발 업무상(참고로 영업은 팀에서 잡은 영업 목표치보다 영업을 더 하면 저 지표가 100%를 초과할 수 있다.) 이런 저런 리스크 다 끌어안고 문제 터질 때마다 밀리고 밀리면 당연히 지표 떨어져서 한 90, 80% 이렇게 되면 일 못하는 개발팀이란 형식으로 또 찔리고 욕먹는 것이 개발팀이 되는 것이고, “개발의 특수성”이란 걸 주장하면 변명 취급당하고… 그냥 악순환이다.

이런 것 없이 그냥 개발자들의 개발 지표만 가지고 따로 관리해주면서 개발에만 집중시켜 주는 회사라면 관리자라 해도 그냥 개발자들처럼 직접 개발해도 될 지도 모르겠다. 그런데, 실제로 대부분의 회사들은 그렇지 않다. 심지어 실리콘벨리에 있는 회사들도 관리자에게는 관리자가 해야 할 일이 있는 것이기에 주니어, 시니어 프로그래머들처럼 프로그래밍 작업에 몰두하고 하는 것이 바람직하다고는 하지 않는다. 그러나 이곳도 현실적으로 막 닥치고 하면 관리자도 개발해야 한다. 그렇기에 관리자도 바로바로 투입 가능한 수준으로 프로그래밍을 할 수 있어야 한다. 근데 첨부터 관리자조차 전부 개발하는 데 인력을 투입하고 관리에 대해서 소홀하다면 그건 좀 고민해야 할 부분이라고 생각한다.