brunch

You can make anything
by writing

C.S.Lewis

by 동그리 10시간전

IT 개발회사 팀장이 사는 법

중소기업 SI 개발사 팀장의 넋두리

오후 3시. 연구소장 이하 연구소 팀장들이 회사 근처 카페에서 모였다.

원래는 오전에 했어야할 회의다.


이렇게 늦어진건 연구소장이 사업관리 신규 직원 면접, 부서장 회의 등 생각지 못한 일정을 소화하느라 겨우 시간을 낸것이다.

회사에 회의실이 비어 있는데도 밖으로 나온것은 그냥 커피 한 잔 하고 싶은 마음도 있었으리라.


이 회사의 조직은 크게 사업부, 연구소로 나누어져 있고, 부서장으로서 사업 본부장, 연구소장이 조직을 대표한다.

연구소는 SI 구축사업이나 연구과제 수행 등 IT 솔루션을 위한 개발 업무를 주로 하는 조직이다.

그 중 연구소장 만은 엔지니어적인 업무를 제외한 연구소 입장에서의 사업 대응과 관리 업무가 주된 역할이다.


부서장은 사업자 및 관리자의 역할에 가깝고, 팀장 부터는 각 부서의 실무를 한다.

그래서 프로젝트 투입 공수를 이야기 할때 자연히 각 팀장의 거취를 이야기 할 수 밖에 없다.


어색한 침묵을 깨고 연구소장이 말했다.

"그러면 이번에 수행할 사업의 인력 계획에 대해서 의견을 들을게요.

아시다시피 원주, 춘천에 위치한 각 고객사 상주가 필요한 사업이고 기간상 동시에 진행됩니다.

기본 계획은 단기간내에 승부를 봐야하는 춘천에 A팀, B팀이 투입되고, 원주에 C팀이 배치되는 것입니다."


카페 테이블에 마주앉아 각자 주문한 음료를 바라보고 있었다.

대략의 계획과 연구소장의 생각은 예전의 회의에서 들어서 알고는 있다.

여기서 의견을 말한다고 해서 들어주는건 아니다.

어차피 연구소장 주관대로 밀어붙일것이다. 하지만...


"원주는 저희만으로는 사업 진행하기 어렵습니다. 저번에 보고드렸듯이 개발 분량도 그렇지만 기획자가 필요합니다."

"해당 의견은 대표님에게 타진 했지만, 프리랜서로 기획자를 뽑는것이 정답도 아니고 우리가 원하는 만큼 일이 된다는 보장도 없다고 봐요."

"그렇다고 기획자 없이 개발자가 그 역할을 하면 어차피 해당 일을 하는 인력의 시간 만큼 개발 진도는 못나갈겁니다."

"가능한 지인 풀 안에서 추천해주시면 건의 해보겠지만, 저번의 사업 경험상 프리랜서를 쓰는건 부정적이라고 봅니다."


역시 C팀 팀장과 연구소장이 인력 투입 구도를 가지고 논쟁하기 시작했다.

상황이 꼬인걸 모두가 인지하고 있었기에 선뜻 말을 꺼내지 못했던것이다.


현재 회사내 인력풀은 프로젝트 수주시 개발을 수행할 개발자 위주로 꾸려져 있다.

문제의 원인은 회사내에 비즈니스 분석가, 즉 기획자가 없다는데 있다.


과거의 사업에서는 기획자의 역할을 어쩔수 없이 개발자가 병행해서 하곤 했다.

이번에도 그렇게 수행할 수 있을거라 생각하고 준비없이 사업 시작 코앞까지 시간만 지나왔다.

막상 시니어 개발자가 투입되어 사업 내용을 검토해보니 리스크가 발견된것이다.

중요도를 간과했기에 미리 대비를 하지 못했다는 문제는 있지만, 여러가지 여건상의 문제도 있기는 하다.


"춘천 프로젝트 일정을 아시잖아요. 5월 중순까지 고객들을 설득할만한 결과가 우선적으로 나오지 않으면 곤란합니다."

"그렇다고 아무 진행도 못하고 손 놓고 있을수는 없지 않나요?"

"그런 이야기는 아니죠. 급한일 부터 우선순위를 두자는 거잖아요."


사실 말이 '우선순위를 두자'지만 쉽지않은 상황이다.

C팀의 입장은 기획자가 들어오지 않으면 분석설계 기간동안 손놓고 있어야한다는거다.

거기다 주니어 개발자들까지 빼서 1.5개월간 쓰겠다고 하는 상황이다.

팀장 혼자서 분석설계를 다 해야하는데, 설계감리 기간까지 제때 못할지도 모른다.

업무 공백에 대해 고객을 충분히 설득하지 못하면 심각한 상황에 빠질것이다.

문제는 반대쪽 일이 1.5개월내에 시연이 가능한 결과물을 내야한다는것이다.


일반적으로 SI 구축 사업 진행 단계는 분석설계, 개발, 테스트 및 안정화, 릴리즈로 이루어진다.

사업의 규모나 여건에 따라서 각 단계별로 들어가는 시간은 천차만별이다.

상식적으로 6개월 사업이면 분석설계 2개월, 개발 2개월, 안정화 1.5개월, 릴리즈 및 인수 테스트 0.5개월 이런식으로 진행된다.


위 상식에 비추어 봤을때 신규 프로젝트 결과를 내는데 1.5개월은 말도 안되는 일정이다.

그럼에도 이렇게 일을 몰아쳐야하는 이유는 고객의 주요 행사에 대응하기 위해서다.

고객측에서 진행중인 프로젝트에 심각한 문제가 생겼고, 그 대응을 위한 자리에 급하게 내보내야하기 때문이다.

전체 사업 일정은 주요 이벤트 대응 이후로 6개월 가량 여유가 있다.


그에 비해서 원주 프로젝트는 일반적인 사업 형태라고 생각하면 된다.

프로젝트 착수 이후 분석설계를 하고, 설계 감리를 받고, 개발을 하고, 종료 감리를 받고, 고객에게 납품한다.

비즈니스 분석 및 설계 기간 동안 많은 인력이 투입되지 않아도 된다.

프로젝트 수행 주기에서 가장 많은 인력이 들어가는 시점은 개발을 해야할때다.

연구소장 입장에서는 당장 상주로 투입시키지 않아도 되는 인력을 빼서 다른 프로젝트에 넣고 싶을것이다.


"C팀 주니어들이 춘천에 비상주로 투입된다고 해서 별로 달라질것 같지는 않는데요.

뭘할지 설계가 안된 상태에서 붙어봐야 혼란스러울 뿐입니다."

"그래도 당장에 개발 가능한 버전을 정의해서 밀고나갈 수 밖에 없어요."


일반적으로 프로젝트를 수행하기 위해서는 고객사 내부나 근처에 프로젝트를 위한 업무 공간을 마련한다.

그리고 그 공간으로 출근을 해서 업무시간동안 해당 프로젝트에만 집중을 한다.

하지만 비상주로 투입한다는 말은 위 공간에 출근은 하지 않지만 외부에서 관련된 업무를 하는 사람을 뜻한다.


"일단... B팀에서 제안드릴수 있는건 두가지 입니다."


B팀 역할은 춘천, 원주 두 프로젝트에 사용될 연계 솔루션 개발이다.

그래서 어차피 B팀 역할은 춘천, 원주 프로젝트에 머물지 않는다.

거기다 지금 논의되고 있는 프로젝트 외에 쿠킹 하고 있는 또 다른 사업에 대응도 B팀이 전담해서 한다.

불평하고 싶은 마음은 있지만, 이 자리의 논지는 그게 아니기 때문에 할 수 있는 이야기만 한다.


"첫번째는, 저희팀은 그래도 연차가 좀 있는 친구들이어서 화면설계 정도는 할 수 있습니다.

프로토타입이 목표인 지금은 제 역할을 저희팀 대리에게 넘기고 원주 프로젝트 설계를 도와주고 복귀하는 것입니다.

두번째는, 춘천 프로젝트는 바쁘게 진행되는것 처럼 보이는 것 이면으로는 실제 연계 관련 논의는 한참 뒤에 진행될것으로 생각됩니다.

차라리 춘천 프로젝트는 더미로 막아두고, 원주 프로젝트를 우선 개발하는게 나을 수 있습니다."


이렇게 동떨어진 두 프로젝트에서 하나의 코드 베이스를 만들고 유지하는것은 어려운 일이다.

최종적으로는 프로젝트에 상주 투입되어 개발을 해야하지만, 본사에서 개발후 주기적으로 패치를 하는식으로 운영한다면 가능할수는 있다.

하지만 누가 생각해도 좋은 방법은 아니다.

하나를 끝내고 다른 프로젝트로 넘어가는 수 밖에 없지만, 현실적으로 원하는 대로 되지 않을 가능성이 높다.


이렇듯이 일을 진행하는 내내 여러 여건이 항상 꼬여있고 힘들다.

매일이 불합리하고 불편한 상황에 놓인다.


처음에는 회사가 이상한줄 알았다.

그런데 생각해보면 내가 감당하지 않았을뿐 이전에도 이런 일은 있었다.

예전의 나는 이런 업무 환경에 맞닥뜨리게 되면 견디지 못해 도망치고, 또 도망쳤다.


'도망친곳에 낙원은 없다.'라는 말이 있다.

도망칠 이유를 생각하는것 보다, 언젠가 이 일이 먼 과거가 되더라도 떳떳할 수 있는 선택을 하는게 낫다.


일의 장점도 단점도 결국 회사의 비지니스에서 온다.

솔루션 개발사든 SI 개발사든 대부분의 중소 IT 개발사의 업무 여건은 디테일은 다를지언정 비슷한것으로 보인다.

소프트웨어 납품을 통해 고객만족을 목표로 하는 비지니스는 결국 방법의 차이일뿐 같을 수 밖에 없다.


안타깝게도 개발자로서 살기를 희망하는 이상, 다른 회사를 가더라도 이러한 비지니스를 하는 회사에 갈것이다.

신입과는 달리 경력직은 한단계씩 쌓아올린 전문성을 상품으로 내세울 수 밖에 없다.

장소와 환경이 바뀐다고 별반 다를게 없는것이다.


누구나 가고싶어 하는 나머지 소수의 유니콘, 대기업들은 솔직히 경험해보지 않아 모르겠다.

다만 확실한것은 그곳도 나름의 체계와 전문성이 있을것이고, 비지니스에서 오는 어려움과 책임져야하는 고난을 피하지 않고 감내하는 사람이 있어 주변 사람들이 편할것이라는 것이다.


팀장이 감내해야할 어려움은 여러가지가 있다.

내 일만 신경쓰고 싶은데 그렇지 못한것은 애교 수준이다.

하루 내내 회의에 불려가느라 목표로한 분량의 코딩을 못할수도 있다.

물리적으로 코딩 등 내 분량의 업무를 할 시간이 부족한것이다.

거기서 오는 일정 부담과 리스크는 오롯이 책임져야한다.


그럼에도 불구하고 팀장도 코딩을 해야 납기를 맞추는 프로젝트가 많다.

어려운 상황에 놓이더라도 앞장서서 문제를 해결하거나, 팀원들을 수행하는 보람 있는 일로 보내고 뒤에서 뒷감당 하는게 팀장의 일이다.


'우리도 힘듭니다!'하고 불평하고 싶은 마음은 굴뚝 같지만, 회사가 생존하기 위해서는 일은 완수해야 한다.

그래서 팀장을 도울 팀원이 필요하고, 서로의 필요를 알고 소중히 해야한다.


일을 하다 보면 나의 일, 회사의 일 구분이 없어진다.

팀원은 일 다했다고 퇴근해도 팀장은 퇴근하지 못한다.


왜 일까? 왜 팀장은 나의 안위를 생각하지 못하고 짐을 다 떠안아야 하나?

감당하는 일과 책임의 범위를 생각하면 결코 돈을 많이 받아서도 아니다.

다른곳에 못가서 그 자리에서 죽어라 힘든일을 하면서 버티고 있는것도 아니다.

팀장이 조직에 대한 애착을 잃어버리면, 그 자리는 얼마 안가 공석이 될것이다.


경력으로서 팀장 커리어의 가치는 '그 자리에서 조직의 가치를 지키는 것'이다.

거창하게 말해서 '회사가 곤란하지 않게 하는것'이다.

회사 생활의 기본이기도 하다.


이 기본 하나 지키기 힘들어서 많은 회사가 어이없이 문닫는다.

어떤 직종이든 신입은 쉽게 뽑아도 경력을 쉽게 뽑지 못하는 이유가 이것이다.

경력직은 아주 많은 능력과 인성 검증을 거치는 이유 또한 같다.

잘못된 채용으로 지게되는 리스크는 신입보다 경력직이 연봉의 차이만으로 설명할 수 없는게 있다.


이직이 어렵고 자유롭지 않고의 문제를 이야기 하는것이 아니다.

원한다면 어떤 위치든 직업이든 선택할 수 있는것은 자유민주주의 국가 국민의 기본권이자 자유다.

다만 한걸음이 꼬맹이였을때 보다 신중할 성인이라면, 자신의 한발짝이 얼마나 크고 무거운지 알아야 함이다.


하지만 너무 괴롭고 무겁다면 내려놓을줄도 알아야 한다.

일도 좋지만 모든것을 희생할만큼 회사가, 일자리가 중요하지는 않을것이다.

내가 없으면 세상도 없다.


팀장은 씨앗이다. 적당한 토양에 심는다면 그 역량이 닿는한 조직을 키워 나갈것이다.

그래서 그 자신이 세상이자 팀이 될 수 있도록 정진해야 한다.

팀의 역량은 팀장의 능력이다. 반대로 말하면 팀장의 능력이 팀의 역량이다.


'혼자만 일 잘하는 팀장이 제일 쓸모 없다.'

요즘 대부분의 리더십 관련 자기계발서에서 지적하는 말이다.

위에서 이야기한 '팀장의 능력이 팀의 역량이다'와 배치되는 주장이라고 생각 될것이다.

하지만 그건 틀렸다. 정확히는 팀장은 팀의 리소스를 활용해서 일을 하는 역량을 키워야 한다.


무작정 일을 시키는것이 팀의 리소스를 잘 활용하는 것은 아니다.

일의 단계 마다 목표와 실적을 정의하고, 사기를 복돋아 줘야한다.

방향성을 잃지 않는 조직은 지속적으로 성장해 나갈 수 있다.


체육계 에서는 국가대표팀의 실적이 나쁘면 감독을 경질한다.

훈련방법과 경기를 운영하는 전략이 팀의 성적을 끌어올리지 못했다 라는 것에 대한 책임을 져야 하기 때문이다.

실무도 같이 하는 팀장은 감독 이라기 보단 주장, 코치에 가깝다.

그라운드에 내보낸 선수들의 포지션에 따른 성장과 실적을 생각해야 한다.


코치는 선수를 전투에서 승리하게 하고, 감독은 팀을 전쟁에서 승리하도록 한다.

코치가 지향해야할 목표는 팀이 전쟁에서 승리하기 위한 선수의 성장이다.

이것은 곧 이렇게 표현할 수도 있을것이다.

'혼자만 잘 뛰는 코치가 제일 쓸모 없다.'


코치가 선수에 대한 책임감이나 애정이 없다면 과연 선수들의 기량을 높일 수 있을까?

제대로된 케어를 받지 않은 선수들이 훌륭한 성적을 낼 확률이 얼마나 될까?

코딩 한줄 더 할 시간에 팀원들의 기본 실력을 키울 방법을 고민해야한다.


100세 시대라 아직 일해야할 세월이 한참 남았다.

당신이 현역 개발자로서 수명이 얼마나 남았을지 알 수 없지만, 주위와 함께해야 오래갈 수 있을것이다.

팀원 들은 내버려 두고 저 만치 앞에서 혼자서 달려가고 있진 않는가?


이전 03화 개발자는 만들면서 성장한다
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari