본문 바로가기
스타트업/IT경영

대안을 이야기해줘. 내가 어떻게 할까?

by 회색연필 2019. 7. 28.

이미지 : Pixabay

"이렇게 하면 안됩니다."

팀장을 치받았다.

나에게 질문이 던져졌다.

 

팀 : "그래서 하고 싶은 이야기가 뭐야?"

나 : "그렇게 하면 안되고, ... 주절주절..."

팀 : "알았어, 그래서 넌 어떤 선택을 할거야?"

나 : " !!! "

 

멈칫했다.

나보고 결정하라니.

 

나는 결정을 해본 적이 없다.

책임을 져본 일이 없다.

책임을 지는게 무섭기도 했지만,

내 이야기대로 했을 때 문제가 클리어 된다고 확신하긴 어려웠다.

나는 그냥 그게 옳다고 생각한거다.

 

한발 물러섰다.

"그건 팀장님이 알아서..."

에이~ 쪼다발언.

 

팀장은 내 발언을 무시했다.

하고 싶은대로 했다.

졌다.

 

"이렇게 하시죠."

자꾸 치받다 보니 요령이 생겼다.

다행히 팀장은 내 제안을 받아줬다.

많이 받아줄 때도 있었고, 적게 받아줄 때도 있었다.

절충할 때도 있었다.

 

물론 결과는 예상대로 되지 않았다.

완전히 실패한 것도 아니다.

그냥 예측과 다른 것 뿐이다.

 

여러번 이렇게 했다.

여러번 이러저러한 걸 겪었다.

 

예측이 10% 정도 빗나가면 잘된 거였다.

대부분 40~50% 정도 예측을 빗나갔다.

잘했다고도 못했다고도 할 수 없는 제안이었다.

 

 

훈련

지나고 보니 팀장되는 훈련이었다.

물론 훈련 프로그램 같은 거 아니다.

 

현재 문제에 충실했고, 그 문제를 풀려고 노력했다.

속이 좋아서 노력한 거 아니다.

하고 싶어서 노력한 거 아니다.

그 땐 솔직히 그렇게 할 수밖에 없었다.

내가 피해 당사자였기 때문이다.

 

혼자 하는 일이 아니다.

책임이 따른다.

그런데 팀장이 받아줌으로써

나는 책임을 지지 않고 훈련해 볼 수 있게 되었다.

 

나쁜 결과가 나오면, 팀장은 자기탓이라고 했다.

좋은 결과가 나오면, 내가 한거라고 이야기했다.

참 좋은 팀장이었다.

참 많이 배웠다.

 

사실, 팀장이 책임을 진다고 해서 사장이 화내지는 않는다.

안다.

그런 책임을 지라고 팀장 시켜놓은 거다.

팀장은 책임의 보관함이다.

모았다가 한번에 정리한다.

매번 책임을 물어 짜르진 않는다.

사장 이야기는 다음에 하자.

 

팀장이랑 친해졌다.

물어봤다.

 

나 : "형, 이건 이렇게 하면 되지 않을까? 안그럼 꽤 타격이 클 것 같은데?"

팀 : "알아... 그런데 방법이 없어."

 

이러면 어떻게?

저러면 어떻게?

한참동안 함께 시뮬레이션을 했다.

정말 다른 방법이 없었다.

내가 모르는 정보들이 상황을 제약했다.

소나기를 맞으면서 가는 수 밖에 없다.

 

"그래, 알았어, 그럼 언제까지 해 놓을께."

내가 해줄 수 있는 유일한 말이었다.

 

팀장도 다 모른다.

알아도 어쩔 수 없는 때가 많다.

내부 비판분위기로 흐르면 안된다.

그를 욕해서 해결될 일이 아니다.

 

스트레스는 만병의 근원이다.

해결못할 일에 짜증을 내면 "간"이 상한다.

 

술먹고 노래방에다 풀어버렸다.

사람 붙들고 말섞으면,

싸움만 나고 갈등만 커진다.

그냥 서버 모니터링이나 하면서,

데이터 뒤져보는게 훨씬 더 낫다.

 

 

절망

"개발자의 눈"은 문제식별의 눈이다.

통찰력은 매우 중요하다.

해법을 찾아야 코드로 짜는 거다.

해법을 찾으려면 "눈"이 필요하다.

 

하지만, 야근요인은 대부분 개발팀 내부에 있지 않다.

다 외부에서 밀려 온다.

"고객과의 회의", "전략수정", "영업상황변화" 등등.

짜다 말고 반영해야 할 사항들이 자꾸자꾸 생긴다.

 

코드문제로 야근하면 뿌듯하다.

레벨업된 느낌이 들고 뚜렷한 성취감이 있다.

 

하지만, 외부요인은 전혀 그렇지 않다.

수동적으로 대처할 수 밖에 없다.

 

문제를 미리 막거나 근본적으로 제거할 수 없다.

발생한 다음에야 수습해야 하고,

재발방지까지 기약할 수도 없었다.

절망스러웠다.

내 인생이 외부에 의해 끌려다니는 느낌이었다.

 

회의란 건 대부분 행동직전에 이루어진다.

그리고, 대부분 결정되어져 온다.

내가 결정할 수 있는 건 겨우 둘 중의 한가지다.

"할 것인가", "하지 않을 것인가?"

 

내가 풀어야 하는 문제인데

내 문제도 아니고, 풀이를 주도할 수도 없다.

그런데 피해는 나도 받을 수 밖에 없다.

어처구니 없고, 화 나는 일 아닌가?

 

영업아, 말도 안되는 걸 코드로 풀지말고,

밥이라도 먹여서 화를 풀어주란 말이다.

 

 

팀장이 되다.

바쁘다. 뭔 일 때문인지 계속 바쁘다.

폭탄을 해체하기엔 너무 시간이 모자랐다.

뇌관만 제거하고 우선 문제를 봉합했다. 

이 폭탄은 언제고 다시 터질 수 있다.

 

"기술부채"라고 포장하지만, 업계에선 그냥 "폭탄"이라고 부른다.

누가 이렇게 우아한 용어를 썼을까?

말 잘하는 컨설턴트였겠지,

적어도 개발자는 아니다.

 

젊은 시절 이 스트레스는 굉장했다.

화풀이 대상은 주로 내 "팀장"이었다.

그는 내 공격에 지쳐 있었다.

자기도 할 말이 없기 때문이다.

한 때 공격의 대상이 점점 더 높아졌다.

상무한테도 대들고, 사장에게도 따졌다.

 

하지만, 결국 되돌아옸다.

더 높은 사람이라고 더 높은 답을 가지고 있진 않았다.

사장도 결국 1인분어치의 일만 하는거다.

문제의 내용과 질이 다를 뿐.

문제의 양, 인식범위는 나와 다르지 않았다.

 

팀장이나 임원도 현장문제를 해결하진 못한다.

현장문제는 현장에 있는 내가 가장 잘 풀 수 있는 거였다.

그들도 그냥 자기의 일을 하고 있는 거다.

내 일을 봐줄만큼 잘 알지도 못했다.

 

 

비판은 종점이 아니다.

그 사실을 알고나니 내 태도는 굉장히 많이 변했다.

동료로서 발언했고, 주장했고 배려했다.

 

동료로서 인정하지 않으면 조직이 불합격이다.

운명공동체가 아니기 때문에 잘해줄 필요도 없다.

비판할 필요도 없고, 적당한 날을 골라서 떠나면 된다.

 

"비판"은 문제를 드러내는 과정이다.

반드시 필요하다.

그러나 해결책이 아니다.

대화의 종점이 아니다.

 

"비판"에서 끝내는 건, 너와 내가 남이라는 뜻이다.

나는 "문제의 발견자", 너는 "문제의 풀이자". 이렇게 구분짓는 거다.

 

책임범위가 명확하고 분업화된 조직에서 내부싸움할 때 주로 쓴다.

문제해결 때까지 현재업무를 정지시키는 방법이다.

대기업이니까 가능하다.

 

아웃소싱이 힘든 것도 이런 이유 때문이다.

발주자는 기획, 아이디어,

수주사는 설계, 개발

이렇게 나누면 대화는 항상 계약이야기부터 시작된다.

 

 

한 팀

"사장, 임원은 결국 나와 한팀이다."

물론 사장 업무를 내가 한다는 건 아니다.

 

이 사실을 인정하니 상황이 다르게 보였다.

비판만 하고 있어봤자, 변하는 건 없다.

답은 없지만 당장 내가 불편했다.

조금이라도 문제를 풀어야 했다.

 

나 : "이걸 내버려 두면 곧 문제가 터질거예요."

나 : "이렇게 하면 어떨까요?"

나 : "이렇게 되어야 하는데, 우선은 이렇게 해놓을께요."

나 : "하지만 이 방법은 결국 1년짜리예요."

 

회사는 훌륭하진 않다.

하지만 회사도 노력하고 있었다.

내가 도움을 받기엔 너무 느리지만 말이다.

그냥 그렇게 받아들이기로 했다.

 

 

꾸준함

1년이 지나고나니 종종 묻어둔 폭탄이 터졌다.

시간을 두고 해체한 것도 있었지만,
폭탄이 터지고 난 후에야 수습한 적도 있었다.

 

욕을 디지게 얻어 먹었다.

우리팀도 불이익을 받았다.

하지만, 방법이 없었다.

 

"터진다, 피해 !!!"

팀원들에게 할 수 있는 건 이 말밖에 없었다.

힘들고 좌절스러웠다.

 

"왜 그랬어요?"

"왜 팀원들을 그런 곳으로 몰았어요?"

나도 내 팀장에게 따져물은 적이 있다.

하지만, 안다.

그도 외통수였다는 걸.

 

그렇게 하루하루 나아갔다.

그러다가 어딘가에 도착하더라. 

남들이 불가능하다고 생각하던 곳이었다.

원래 가고자 했던 조청과 단꿀이 흐르는 땅은 아니었지만,

태풍과 파도를 피할 수 있는 충분히 마른 땅이었다.

그걸로 충분했다.

 

"대안"은 100점짜리를 말하는 게 아니다.

60점 짜리, 70점 짜리도 대안이다.

알면서 받아들이는거다.

사업이란 그런 걸 모아서 1,000점 짜리 만드는 거다.

꾸준함이 결과를 만든다.

 

 

교훈

중요한 게 있다.

 

"현장문제"는 현장에 답이 있다.

"대안"은 결국 "실무담당자"가 내야 한다.

가장 문제를 잘 아는 사람이자,

해결 못하면 불편해지는 사람이기 때문이다.

 

이거 헷갈리는 사람 많다.

현장문제를 풀어달라고 윗쪽을 갈구는 건,

산에 가서 물고기 찾는 격이다.

 

"사람들은 자기 문제일 때 가장 진지해진다."

절대 이해당사자가 아닌 사람에게 대안을 부탁해선 안된다.

다른 팀이 조언해줄수는 있지만, 결국 풀어야 할 것은 나다.

 

 

사장님에게

웃긴 이야긴데, 사장들도 그렇게 생각한다.

그런데, 우리팀에다 안 묻고 네이버 개발팀에게 묻는다.

 

우리팀 이야기는 안믿어도,

네이버 개발팀 이야기는 믿는다.

하아~~

 

외부의 베테랑과 고수들이 정보를 줄 수는 있다.

하지만, 문제를 풀진 못한다.

"현장보존의 법칙" - "문제의 답은 현장에 있다."

 

이 사실을 무시했다가 깨지는 회사 여럿 봤다.

네이버 개발팀 이야기 듣고,

우리 개발팀 갈구다가 망한 회사 여럿 봤다.

 

언제나 멋지게 문제를 풀수 있다면 굿럭이다.

사장 체면도 산다.

하지만 그렇지 않다.

대부분 부족한 "대안"들로 현장을 메꾼다.

 

인터넷 서비스에서 "프로그램"은 현장이다.

개발자들을 같은 편으로 만들 수 없다면, 솔직히 IT사업은 실패다.

시작부터 실패다.

 

"이해당사자"로 만들어야 참여한다.

주식을 줘도 좋다.

머리를 맞대로 이야기를 들어주는 것만으로도 좋다.

생각보다 사업운영에 도움이 많이 될거다.

 

뭔가 "부족한 오늘"이 있다면,

그건 "부족했던 과거"가 있었기 때문이다.

 

그들의 대안에 익숙해져라.

서툴지만 함께 해라.

그래야 진화한다.

개발팀을 진화시켜야 품이 덜 들어간다.

 

"개발자" = "이해당사자" = "대안토론자"

이렇게 생각해라.

그리고, 이건 시작점이지 종점이 아니다.

 

"We are the one team!"

"미드"에서 자주 듣는 말이다.

갈등이 고조되는 순간에 저렇게 말한다.

어벤저스도 저렇게 말했다.

 

우연이 아니다.

미국이 발전한 원동력이다.

미국은 저런걸 고민한다.

 

일일히 터치할 수 없으니까 저러는 거다.

저게 유일한 대안이다.

 

※ 주인의식 운운하지 마라.

주인의식은 주인이 가지는 거다.

직원이 주인처럼 주장하면 주인은 싫어한다.

직원에게 바라야 할 건, "올바른 직원의식"이다.

"프로의식"이라는 우아한 용어도 있다.

 

끝.

반응형

댓글