개발자 안티패턴4 - 남의 문제를 지적하지 말라

제목을 다소 과하게 잡기는 했는데 이 부분에 대해서 제가 스트레스를 받은 적이 많아서 꼭 이야기하고 싶었던 내용 중 하나입니다. 사실 제목과 다르게 남의 문제를 지적하는 건 사실 괜찮습니다. 이거 보여주고 싶어서 어그로 끌어보았습니다. 제가 여기서 집중하고자 하는 부분은 '남의 문제를 지적'하는 행위 자체가 아니라 '어떻게 지적하느냐'에 대해서 조금 더 이야기해보고 싶었습니다. 제가 최근에 몇 년 새에 겪었던 두 가지 케이스를 이야기해드리고자 합니다.

 

1. 이상주의 개발자 D와의 협업

가끔 보면 개발자 중에 이상주의자들이 많습니다. 이상주의자란 무엇이냐 하면 항상 이상적인 세계를 꿈꾸듯, 이상주의 개발자는 항상 이상적인 코드와 이상적인 인프라를 상상하는 개발자들입니다. 이러한 이상적인 것을 추구하는 것이 나쁘다는 것은 아니고 어떻게 추구하느냐에 따라 크게 다릅니다. 

 

어느 날 팀에 CI와 코드에 대한 정적 분석(static analysis)이 부족하다고 판단해서 최근에 회사에서 새로운 CI 툴과 소나큐브를 연동하기 시작한다는 소식을 듣고 제가 한번 자진해서 저희 팀의 코드베이스를 연동시키고 정적 분석까지 할 수 있게 준비한 적이 있습니다. 빌드의 실패 / 성공에 따라 슬렉 메시지도 내보낼 수 있게 연동하고 팀에 공유를 했습니다. 여기서 이상주의 개발자 D의 반응은 어땠을까요.

 

D: "도커 이미지도 푸시하고 자동 배포까지 되면 더 좋겠네요."

 

여기서 참 한숨이 나오더라고요. 지금은 회사에서 근본적으로 자동배포를 막아놨기 때문입니다. 물론 자동배포를 하기 위한 비즈니스 요구사항들에 대한 테스트 커버리지도 안 좋은 상태이기도 하고요. 그런데 현재 상황을 고려하지도 않은 채 본인이 생각하고 있는 가장 이상적인 그림에 대해서만 언급을 합니다. 이 개발자에게 코드리뷰 같은 곳에서 코멘트를 달면 어떻게 반응을 할까요?

 

저: "이 부분은 이러이러하게 고쳐주시면 좋을 것 같습니다."
D: "원래 코드가 그랬어요."

저: "이 부분을 효율적으로 고쳐주시면 좋을 것 같습니다."
D: "아 그게 원래 그렇게 구현은 안 했는데, 이렇게도 해보고 저렇게도 해보고 {어쩌고 저쩌고 엄청 긴 변명}

 

일단 본인이 지적당하는 것에 대한 변명을 많이 하기도 하고, 본인이 생각하는 이상적인 그림으로 하지 못한 것은 전적으로 본인 탓이 아닌 남 또는 환경의 탓으로 돌리는 경우가 많았습니다. 

 

2. 주관이 뚜렷한 입만 살아있는 개발자 J와의 협업

몇 년 전 한 개발자 J가 입사를 하였는데 나이는 저보다 조금 많아 보였습니다. 어쨌든 새로 온 개발자와 친숙해지기 위하여 가끔 테크톡을 하곤 했습니다. 이 개발자는 그러한 테크톡을 정말로 좋아하는 개발자였습니다. 이상주의 개발자와 약간 비슷하기는 한데 자기 주관이 더 뚜렷한 스타일입니다. 이 개발자와 했던 많은 이야기들이 기억나곤 합니다. 

 

J: "저는 reflection 사용하는 것을 너무 싫어합니다."
저: "네 맞아요. 당장은 편할 때도 있지만 나중에 유지보수가 너무 힘들어요."

J: "저는 annotation을 싫어합니다."
저: "네 맞아요. 저도 동작을 annotation으로 바꾸면 영향도 파악이 어려워서 적용하는 것을 선호하지 않습니다"

 

여러 부분들이 맞기도 하고 저도 많이 배웠던 것 같습니다. 이러한 테크톡을 좋아하는 개발자와 간간히 테크톡을 하면 저도 많이 배우기도 해서 좋아합니다. 단지, 한번 말 걸면 1시간 동안 혼자서 계속 주저리주저리 한다는 게 문제였죠. 본인의 생각이 확고하여 새로운 생각이나 접근 방법을 쉽게 받아들이지 못하는 고집스러운 타입이기도 했습니다. 하지만 여기서 제일 큰 문제는 본인의 주관에 받는 실력을 갖추지 못했다는 것입니다. 저는 당시 테크리드였지만 다른 일을 하고 있었고 어느 날 이 개발자 J와 다른 개발자 S가 동업을 하는 것을 옆에서 들은 적이 있습니다.

 

J: "구현을 이렇게 하는 게 마음에 안 드네요."
S: "그러면 어떻게 해야 될까요?"
J: "잘 모르겠지만, 그냥 이렇게 하는 것이 마음에 안 들어요."
S: "..."

 

J는 어떠한 식으로 하면 안 좋을지 어느 정도의 감이 있습니다. 하지만 실제로 어떻게 문제를 풀어나가야 할지 모르고 일단 반대부터 하고 시작합니다. 이것 때문에 개발자 S가 저한테 따로 와서 엄청 한탄하더라고요. 그렇다면 이러한 개발자들이 어떠한 악영향을 미치게 될까요.

 

이러한 개발자들의 영향

앞선 개발자 D는 원래 있는 팀에서 단기로 파견 나왔던 개발자입니다. 이 개발자는 코딩은 그래도 어느 정도 실력이 있지만, 다른 사람과의 협업에 있어서 팀워크를 방해하고 다른 팀원들의 성취감을 박탈합니다. 팀적인 분위기에서 악영향을 미치게 되는 개발자라고 볼 수 있습니다. 왜 이전 팀에서 파견이 나왔을지 확신은 없지만 약간 의심은 들게 만드는 그러한 개발자입니다. 참고로 지금은 다시 다른 팀으로 또 파견 간 상태입니다.

 

개발자 J는 어떨까요. 개발자 S는 저보다 회사를 조금 더 오래 다녔고, 개발자 J는 저보다 회사를 조금 늦게 입사를 했던 상황이었고, 저와 개발자 S, 그리고 개발자 J가 묶여서 한 서비스를 구축해나가고 있었습니다. 이때 같이 동업 안 했던 개발자들은 개발자 J가 정말 일 잘하는 것으로 생각하고, 외부의 평가는 엄청나게 좋죠. 하지만 같이 일 해본 사람은 실제 밑천이 다 드러났기 때문에 부정적인 반응이 대부분이었습니다. 개발자 S는 저한테 와서 엄청 신세한탄을 하곤 했습니다. 같이 일을 하는 사업부서와 매니저 급에서도 어느 순간 눈치를 채기는 했지만 그 시간이 조금 걸리기는 했습니다. 나중에는 결국 저희 매니저가 개발자 J를 다른 급한 프로젝트가 있는 팀으로 파견시켜 버렸습니다. 그전까지 개발자 J가 미친 영향은 단순히 팀적 분위기의 와해뿐만 아니라 다른 개발자들의 생산성에도 영향을 주어서 팀 전체의 생산성을 저하시키게 되는 결과로 이어졌습니다. 나중에 개발자 J는 다른 팀으로 갔었고 이후에 어느 순간 퇴사한 것을 알게 되었습니다.

 

남의 문제를 지적하기 전에 현재 상황을 먼저 이해하고 적극적으로 도와주세요

어떠한 문제를 지적할 때에는 현실을 직시하고 단기적으로 불가능한 것과 가능한 것을 이해하는 것이 필요하고 현재 상황을 먼저 고민해 보고 문제를 지적하는 것이 좋을 것입니다.

 

Q: 문제를 지적함으로써 해결 가능한 문제인가? 다른 어떠한 이유로 해결이 불가능한 문제인가? 

A: 해결이 안 된다면 굳이 지적할 필요가 없습니다. 지적만 하지 말고 어떠한 이유로 해결이 안 되는지 확인하고 그것이 해소될 수 있도록 도와주세요.

 

Q: 어떻게 해결해야 할지 본인이 잘 알고 있는가?

A: 모른다면 직접 여기저기 물어보고 조사해서 공유하세요. 누군가가 알고 있다면 그 사람에게 도움을 청하세요. 문제 해결을 다른 사람한테 미루지 마시고 적극적으로 나서세요.

 

Q: 해결할 방법은 아는데 시간이 없어서 직접 나서서 도와주고 해결할 수 없는가?

A: 특히 코드리뷰나 디자인 리뷰를 할 때 "이렇게 하시면 안 되요"라고만 달지 마세요. 그리고 논의에는 참석 안 하다가 뒤늦게 와서 "그렇게 하시면 안 되요" 한마디 던지고 가지 마세요. 정말 얄미워요. 항상 방향성도 같이 알려주거나 방향성을 간단하게 문서화해서 공유하세요. 

 

상황에 따라 다르기는 하지만, 일반적인 코드리뷰나 디자인 리뷰에서의 문제 제시는 방향성에 대한 토론 또는 방향성 제시와 함께 해주세요. 그렇게 하는 것이 상대방에 대한 동기부여와 활력을 불어넣어 주게 되고, 팀적인 신뢰를 쌓을 수 있는 가장 간단하게 할 수 있는 노력입니다. 

 

어떻게 이러한 개발자들의 채용을 막아야 하나?

솔직히 방법이 없습니다. 면접에서는 이러한 개발자들이 더욱더 활개 치며 본인의 생각과 이상적인 방향을 이야기하듯이 풀면 어느 면접자가 매료 안 될 수 있을까요. 그러한 이상적인 모습을 회사에 반영할 수만 있다면 정말 이러한 인재는 그대로 채용하는 게 맞겠죠. 저는 그래서 인터뷰할 때 살짝 돌려서 묻는 질문들이 있습니다. "본인이 가장 실패했을 때"를 물어본다던지 "현재 구현한 알고리즘의 부족한 부분"에 대해서 물어보면 이 사람이 다른 사람의 의견을 듣는 사람인지 아닌지 최소한 고집이 있는 사람인지는 구분할 확률이 높습니다. 그것 외에는 단편적으로 짧은 시간의 면접에서 다 파악하는 것은 사실상 불가능하기 때문에 이러한 개발자의 입사를 완전히 막을 수는 없다고 생각합니다.

 

어떠한 식으로 개선시켜줘야 할까?

사실 사람을 바꿔서 쓰는 게 아니라서 힘듭니다. 이미 오랫동안 형성되어 온 성격을 회사에서 바꾸는 것은 어렵지만 적어도 주변의 환경이나 분위기 구성은 바꿀 수 있게 도와줘야 하지 않나 생각합니다.

 

서로 칭찬하고 격려하는 분위기를 만듭니다.

 

Acknowledgement라고도 하는데, 일단 각 팀 구성원의 작은 성과라도, 작은 버그의 원인 발견이라도 칭찬하고 고맙다고 해주는 분위기가 중요하다고 생각합니다. 이렇게 하면 개발자들은 성취감을 느끼게 되고, 자진해서 야근(?)까지 하게 되는 기이한 현상도 보이게 됩니다. 다른 사람들이 칭찬하고 있는데 그 와중에 와서 얼굴에 침 뱉고 갈 수는 없겠죠. 그러니까 이러한 개발자들이 활개 치기 전에(?) 먼저 선수 쳐서 빠르게 칭찬해 줍시다.

저: 저번에 R이 프로세스를 자동화시켜 줬어요. 정말 고마워요. 덕분에 잠을 더 잘 수 있게 되었어요.

물론 이 개발자에게도 비슷하게 칭찬도 해주고 자진해서 개선할 수 있게 독려하면 좋은 것 같습니다.

저: D가 자동배포에 대한 좋은 의견 내주었는데, 향후 개선할 점으로 인지하고 티켓을 하나 만들어 놔 주세요.

이상주의 개발자들의 말을 무시하는 것보다 활용하는 것이 효율적입니다. 궁극적으로 그렇게 하면 이점이 많아지는 경우가 많으니까요. 하지만 위의 D의 케이스를 보면 현재 어떠한 상황이고 어떠한 제약사항이 있는지 모르는 것이 분명했습니다. 따라서 이 부분을 도와주는 것이 좋습니다.

 

현재 상황 분석을 도와주고 단계별로 비전을 제시하고 업무를 줍니다.

 

만약 어떠한 제약조건 때문에 이상적인 구현 방법으로 나갈 수 없는 상황에 있을 때에는 이러한 개발자들에게 직접 해결하도록 맡기는 것도 좋은 방법입니다. 이미 본인은 이상적으로 어떠한 방향으로 가는 것이 좋을지 알고 있지만 현재의 제약사항들을 잘 이해하고 있지 못하기 때문에 이에 대해서 잘 설명하고 단계별로 그 방향으로 나아갈 수 있는 업무를 주면 좋다고 생각합니다.

저: D가 말하는 방향이 맞습니다. 그런데 그 방향으로 가기 위해서는 먼저 테스트 커버리지가 좋아야 하는 문제가 있습니다. D가 방향성에 대해 잘 아는 것 같으니 직접 해결해줄 수 있나요?

근데 실력이 없는 J의 상황이었다면 어떻게 반응 했을까요?

저: 저번에는 J가 정말 좋은 의견 내주었는데 혹시 J가 직접 디자인 진행해주실 수 있으신가요?
J: 못 합니다. 제 역할이 아닙니다. 다른 일 하고 있습니다.

네, 다른 사람들은 놀고 있는게 아니죠. 사사건건 딴지 걸면서 이러한 반응을 한다면 지뢰입니다. 이렇게 바뀌지 않을 것 같다는 확신이 있다면 또 다른 방법을 찾아봐야겠죠.

 

혼자 활개칠 수 있는 협업이 덜 필요한 프로젝트 투입 시켜줍니다.

 

문제가 되는 이상주의 개발자들은 머리는 이미 저 높이 올라가있는데 현실 실력은 시궁창인 것이 문제입니다. 그래도 머리로는 어디로 가야할지 알고 있기 때문에 사실 이러한 개발자들은 그러한 프로세스 개선이나 플랫폼/인프라 개선하는 일에 투입되는 것이 효율적일 때가 많습니다. 확장성과 속도가 중요한 서비스보다는 좀 느리지만 품질을 더 중요한 쪽에서 일을 하면 더 적성에 맞을 때가 많다고 생각합니다. 이러한 개발자를 다른 개발자와 협업하게 되면 다른 개발자들에게 악영향을 미치므로 협업은 최소화할 수 있는 단독 프로젝트를 시켜주는 것도 괜찮습니다. 물론 개발자 J와 같이 처음부터 실력이 뒷받침되지 않는 경우에는 단독 프로젝트를 통해서 외부에 대한 평가를 제대로 받게 되는 효과도 있습니다. 저는 이 방법으로 다른 사람들에게 J의 실제 실력에 대해 알려주었습니다.

 

근데 이러한 실력 없는 이상주의 개발자들이 항상 하는 장애나 어떠한 문제가 발생경우 "꼭" 하는 말이 있습니다.

 

제발 이런 말은 하지 마세요. "제가 그렇게 하면 안 된다고 했잖아요"

 

제발 이러한 말은 하지 맙시다. 개발자들이 실수를 하는 것은 당연한 것이고, 버그가 배포되거나 장애가 발생하는 것은 언젠가는 반드시 일어납니다. 개발자라면 피할 수 없는 숙명이기 때문에 누구누구의 잘잘못을 따지고 추궁하는 것보다는 이후에 비슷한 장애 발생시의 회복 절차와 재발 방지에 집중하는 것이 훨씬 생산적입니다.

 

나중에 와서 그렇게 말 할 거였으면 제발 문제를 봤을 때 먼저 적극적인 자세로 직접 고쳐주세요.

 

 

다음편: 개발자 안티패턴5 - "제 역할이 아니에요"