협업을 잘하는 개발자가 되어보자 - 프로그래머가 아니라 문제 해결사가 되자!

해당 글은 SOPT의 MIND23과 삼성강남 X 점핏에서 요청을 해주셔서 진행한 강연의 내용을 바탕으로 작성하였습니다. 다시 한번 이 자리를 빌려 강연 기회를 만들어주셔서 감사드립니다.

프롤로그

이 글은 협업을 잘하는 개발자가 되어보자 라고 하는 주제로 "프로그래머가 아니라 문제 해결사가 되자." 라는 이야기를 해보려고 합니다.

이 글은 협업을 잘 하기 위해서 이렇게 해야한다 라는 방법론적인 이야기보다는 왜 개발자가 협업을 잘 해야 하는 지에 대한 개인적인 생각, 마인드 그리고 약간 지침에 가까운 이야기들을 좀 준비를 해봤습니다.

협업을 잘하는 팁이나 솔루션을 설명하게 되면 언제나 은빛총알은 없는 것이기에 나에게 맞지 않은 솔루션을 적용하면서 부작용이 생길수도 있습니다. 그렇기에 솔루션을 말하기에 앞서 협업에 대한 생각을 중심으로 얘기를 하고자 합니다.

개발자에게 협업이란 당연히 잘 해야 하는 소양같은 것이라고 생각을 할 수 있습니다. 그렇지만 막연히 협업을 잘해야된다더라 보다는 개발자가 왜 협업을 잘 해야하는지, 그리고 어떻게 협업을 바라봐야 하는지를 이해하면 더 나은 관점과 태도를 가지게 되고 그것이 결국 협업을 더 잘하는 방법으로 이어질 수 있다고 생각합니다.

이 글에서는 1) 왜 협업을 잘 해야 하는지, 2) 그래서 어떠한 태도와 관점을 가져야 하는지, 3) 그리고 어떻게 하면 협업을 더 잘 할 수 있는지에 대해서 개인적인 생각을 이야기 드리려고 합니다.

---

1. 성장을 하면서 변화하게 되는 개발의 가치관

과연 "개발을 잘한다" 라는 것은 무엇일까요?

협업을 잘해야 하는 이유를 설명하기 위해서 개발에 대한 제 생각과 이야기를 먼저 해야 해야 할 것 같습니다. 그래야 개발자에게 협업이 중요한 이유를 더 잘 설명할 수 있을 것 같아요. 제가 성장을 하는 과정에서 얻은 인사이트이긴 하지만 대부분의 개발자분들에게도 통용이 될 수 있을 이야기일거라고 생각합니다.

우리 모두는 좋은 개발자, 잘하는 개발자, 훌륭한 개발자가 되고 싶어 합니다. 저 역시 그러했고 지금도 그러합니다. 그렇기에 좋은 개발자가 되기 위해 꿈꾸고 노력하면서 성장을 해왔습니다.

그런데 개발을 잘한다는 것은 구체적으로 무엇을 잘한다는 것일까요? 좋은 개발자는 어떤 개발자를 말하는 걸까요?

"아는만큼 보인다"라는 말이 있습니다. 제가 개발자로 성장을 하다보니 좋은 개발자, 잘하는 개발자에 대해 가치관들이 아는 만큼 보이고 변화하고 함께 성장했습니다.

초창기, 개발을 잘한다 = 코딩을 잘한다 = 구현을 잘한다.

초창기 개발에 막 입문을 하고 개발 자체가 재밌는 시절에는 개발을 잘한다는 것을 코딩을 잘한다는 것이었습니다. 그리고 코딩을 잘한다라고 하는 것은 단순히 개발지식이 뛰어난것만은 아니다라고 하는 것들을 어렴풋이 알게 되었습니다.

아무리 기술을 잘 알고 이론도 잘 알더라도 주위에 개발을 더 잘하는 친구들을 보면 많이 알고 있는 것보다도 그냥 알아서 뚝딱뚝딱 잘 만들어내는 친구들이 있습니다. 그런 친구들을 보면서 참 코딩을 잘한다라고 생각이 들곤 했습니다.

학교에서 수업을 받는 내용을 잘 아는 것보다 잘 몰라도 스택 오버 플로우와 구글을 뒤져가며 게임이나 과제등을 어떻게는 잘 만들어내는 것이 개발을 잘한다라고 생각을 했습니다.

제가 항상 개발은 학문보다 운동 같은 거라고 많이 얘기를 하는데 결국 지식이 많은 것 보다 구현을 잘하는 것이 중요하고 할 줄 아는 것보다 해내는 것이 더 중요하다고 생각을 했습니다. 결국 구현을 잘하는 것이 개발을 잘하는 것이라고 생각을 했습니다.

조금 지나면, 코딩을 잘한다 = 좋은 코드품질(구조)를 유지하면서 코딩을 하는 것

조금 더 연차가 차니 단순히 구현만 잘하는 것만이 개발을 잘하는 척도는 아니라는 것을 알게 되었습니다. 개발을 할 때 구현을 잘 하면서도 높은 품질의 코드를 계속 유지할 수 있도록 하는 것이 정말 개발을 잘하는 것이구나 라는 생각을 했습니다.

개발을 처음 배우던 시절에도 물론 좋은 코드를 만들기 위해서 노력을 했겠지만 실질적으로 내가 만드는 코드의 규모가 커지고 내가 만든 코드의 구조로 인해서 나중에 수정하거나 새로운 기능을 추가하려고 할 때 어려움을 겪으면서 좋은 코드의 의미를 보다 몸으로 체감을 할 수 있었습니다.

높은 품질의 코드가 왜 생산성과 유지 측면에서도 중요하다고 하는지, 내가 만든 코드에 내가 발목을 잡히면서 내가 왜 이렇게 짰을까 속으로 한탄을 하면서 좋은 구조에 대해서 고민을 하는 시기이기도 했습니다.

| "잘하는 개발자는 규모가 커져도 꾸준히 예측가능한 속도로 개발가능한 구조를 함께 생각한다."

그러면서 우리 사수보다도 내가 더 빨리 잘 코딩한다고 생각했던 부분들이 사실은 잘하는게 아니라는 것을 깨달으면서 프로젝트의 규모가 커져도 일정한 퍼포먼스를 낼 수 있도록 좋은 구조를 유지하고 테스트 가능하게 코드를 작성하면서 코드 품질을 항상 신경을 쓰고자 하는것이 잘하는 개발자라는 의미를 이해하게 되었습니다.

이렇게 좋은 코드를 만들기 위해서 끊임없이 노력하는 개발자가 좋은 개발자, 잘하는 개발자라고 생각을 했습니다.

실전에는 코딩만 잘하는 것만 가지고는 충분하지 않다.

본격적으로 사업을 하게 되면서 실전에서는 구현을 잘하고 코딩을 잘하고 좋은 구조를 통해 좋은 코드 품질을 신경쓰는 것만으로는 충분하지 않다는 것을 알게되었습니다.

특히 스타트업에 계시는 분 사업이나 기획과 굉장히 맞닿아 있는 분들은 더 느낄 수도 있긴 하겠지만 사업과 개발을 같이 하다 보면 지속적으로 가치의 충돌을 겪게 됩니다.

우선 요구 사항이 계속 바뀝니다. 지난주에 요구 사항이 지금과 달라지고 전에 만들어 달라고 했던 것들이 지금은 아니라고 합니다. 나는 좋은 코드의 품질을 유지하고 싶고 좋은 구조를 만들고 싶은데 지금의 구조로 만들 수 없는 것들을 계속 만들어 달라고 요구를 할 때마다 대처하기 어려울 때가 있습니다. 그래서 더욱더 변화에 유연하고 더 좋은 구조의 코드를 만들고자 노력을 합니다.

그런데 일정에 대해서도 계속 압박을 받게 되죠. 언제나 빠르면 빠를수록 좋고 마감시감의 압박은 무시무시합니다. 코드의 품질을 유지하기 위해서는 시간이 필요한데 언제나 시간은 부족하기 마련입니다.

그럼에도 코드의 품질을 지켜내는 것이 잘하는 개발자가 아닐까?

저는 이러한 요구사항의 변화와 일정의 압박을 이해하면서도 코드의 품질을 지키고자 꺽이지 않는 것이 좋은 개발자라고 생각을 했습니다. 포기하고 타협해서 나쁜 코드를 만드는 사람은 능력이 없는 개발자이고 어떻게든 그 코드의 품질을 지켜내는 것이 잘하는 개발자라고 생각을 했습니다.

개발자는 요구사항의 완수와 시간의 압박을 받습니다. 그러면서도 코드의 품질을 지켜내야 하는 사람이기도 합니다.

그러면 이 셋을 다 지켜내려고 하면 어떻게 될까요?

결국 내가 포기할 수가 없으니 자발적인(!) 야근을 택하게 되고 그 결과는 안타깝게도 번아웃으로 이어지게 되었습니다.

| "코드, 구현, 시간 셋 다 만족시키는 것이 가능할까요? 혹시 당신이라면?"

그렇다면 반대로 코드의 품질을 좀 포기하면 어떤가요?

그렇다면 개발자로서 내가 지금 개발을 하고 있는 건지 그냥 요구 사항을 쳐내고 있는 사람인지 개발자로써 자괴감에 빠지게 되죠. 잘하는 개발자를 스스로 포기하는 기분이 들었습니다.

나를 갈아 넣을 수 없고 나를 포기할 수도 없는 괴로운 상황. 그리고 이걸 본인의 능력부족이라고 생각해도 회사가 열악하기 때문이라고 생각해도 둘다 괴로운 상황이 이어졌습니다.

그리고 이 시기가 보내고 나면서 깨닫게 된 것이 있었습니다.

🫢 시장은 내.생.각.보.다.는. 고품질의 코드를 중요하게 생각하지 않는다.

시장은 일반적인 개발자의 생각보다는 - 제가 생각하는 것보다는 - 고품질의 코드를 중요하게 생각하지 않는다는 것을 알게 되었습니다.

코드의 품질을 높일 필요가 없다는 얘기가 아닙니다. 일반적으로 개발자들은 - 최소한 저는 - 코드의 품질을 훨씬 더 고평가를 한다라는 것입니다. 하지만 실제로 그렇지는 않습니다. 저는 이 명제를 꼭 한번 곱씹어 보시라 얘기를 드리고 싶습니다.

갓 취업한 프론트엔드 개발자분이 본인이 입사한 회사에서 jQuery와 PHP를 쓰고 있다고 낙후된 회사라고 불만을 토하는 글을 종종 보곤 하지만 정작 내가 웹 사이트에 접속을 할 때에는 PHP로 만들어졌는지 jQuery로 만들어졌는지 확인하면서 사용하지 않습니다. 개중에는 React로 만든 서비스보다 훨씬 더 돈을 잘 벌고 있는 서비스들도 많습니다.

우리가 어플리케이션이나 서비스들을 선택을 하는 이유는 코드를 잘 만들었기 때문이지 않습니다. 심지어 개발자들조차 코드가 공개되어 있는 오픈 소스의 라이브러리를 선택할 때 코드를 열어보고 좋은 코드 품질을 가지고 있기 때문에 선택하지 않습니다. 나에게 그 라이브러리가 얼마나 필요하고 유용하게 만들어졌는지에 따라서 선택을 하게 됩니다.

그러니까 결국 개발자가 만들어내는 가치는 코드의 품질에 있는게 아니라는 것입니다.

코드의 가치는 코드 그 자체가 아니라 코드가 어떤 가치를 만들어내는가에 있다.

우리는 코드를 만들어내는 사람이지만 우리가 만드는 실제 가치는 코드가 아닙니다. '코드의 가치는 코드 자체가 아니라 그 코드로 어떤 가치를 만들어내느냐 하는 것으로 결정된다' 라는 사실을 깨닫는 것이 훨씬 중요하다는 것을 알게 되었습니다.

나는 동일한 사람이고 같은 기술과 같은 시간을 투자했고 코드의 품질의 차이가 크지 않음에도 어떤 프로젝트는 비싸게 책정이 되었고 어떤 프로젝트들은 그것보다 훨씬 낮은 비용이 책정되곤 했습니다. 내가 어떻게 만드는냐보다 무엇을 만들어내느냐에 따라서 그 가치들이 달라졌습니다.

심지어 내가 만들어 내고 있는 회사가 망해버린다면 내가 아무리 잘 만든 코드는 한순간 의미가 없어지는 코드가 됩니다.

우리가 좋은 개발자, 잘하는 개발자가 되기 위해서 코딩을 잘해야 하는 시기를 거치면서 코드를 잘 만들고 코드의 품질을 높이고자 하는 노력을 하는 과정에서 한쪽 가치에만 매몰이 되는 경우가 생기곤 합니다.

내가 추구하고 있는 코드의 품질이 어느정도의 가치를 지니는지 내가 만들고 있는 코드는 어떤 가치를 만들어 내고 있는지 "두 가지 모두"를 생각해보는 것이 정말 중요합니다.

개발자의 평가는 어떻게보다 무엇을 개발하느냐로 따라 정해진다.

개발자의 평가는 결국 어떻게보다는 무엇을 개발하느냐에 따라 정해집니다. 그래서 우리가 흔히 유명한 어떤 빅테크 기업을 떠올렸을 때 잘하는 개발자라고 생각을 하게 되지만 그들이 어떻게 잘하는지에 대해서는 사실 알 수 있는 방법이 없습니다. 결국은 무엇을 개발했는지로 어떤 개발에 참여했는지에 따라서 잘하고 못하는 개발자로 평가를 받게 됩니다.

당연히 어떻게 개발을 하는가 라고 하는 라고 하는 것은 굉장히 중요합니다. 그것이 개발자로서의 아이덴티티이자 실제로 그 사람이 잘하는 개발자냐 못하는 개발자냐가 정해지는 부분이긴 하지만 그것을 보여주고 증명하기란 정말로 어려운 일입니다.

본인이 알고 있는 유명한 개발자를 한번 떠올려봅시다. 혹은 뉴스에서 천재 개발자를 운운하거나 유명한 개발자들을 언급하는 경우를 한번 생각해봅시다. 그 사람이 어떻게 개발하는지에 대한 방법이나 철학등으로 평가를 받나요? 아니면 무엇을 만들어냈는지에 대해서 평가를 받고 있나요?

어떻게 개발하는가의 가치를 폄하하고자 하는 것은 아닙니다. 그렇지만 결국 개발을 통해서 무엇을 만들었고 그게 얼마나 큰 가치를 만들어 냈는가 라고 하는 것이 훨씬 더 중요하다라는 이야기를 강조해서 알려드리고 싶었습니다.

기왕이면 더 나은 가치를 만들어보자!

같은 기술과 같은 시간을 쓰는 거라면 적어도 내가 만들어 내는 것이 더 가치 있는 것이 되기를 바랬습니다.

개발의 역량이 어느정도 오르고 나니 새로운 기술적 성장이나 숙력도의 상승을 통해 만들어내는 내 가치성장의 폭은 점점 더 줄어들었습니다. 내 코드의 품질을 정성들여 닦아 내는 것 보다 더 나은 가치를 만들어 내는 것들이 훨씬 더 큰 가치를 만들고 있다는 생각이 들었습니다.

가치 있는 코드란, 적절한 코드 품질을 유지하려고 하면서도 더 큰 가치를 만들 수 있는 좋은 요구 사항를 찾아 구현을 하고 주어진 일정을 지키고자 할때 만들어진다 라는 것을 알게되었습니다.

결국 개발이라고 하는 행위는 더 나은 가치를 만들어내기 위한 좋은 도구중에 하나인 것이고 나는 그 숙련도를 높여 원하는 만큼의 결과물을 만들어내는 사람이 되고자 노력했다면 결국 개발을 통해서 가치과 결과물을 만들어내는 것이 진짜 개발이구나 라는 생각이 들었습니다.

나는 코드를 만드는 사람이기에 좋은 코드를 만들어내려고 노력을 해야 되는 사람이지만, 동시에 나는 코드가 만들어내고 있는 가치를 만들고 있는 사람이다 라고 하는 것들을 기억해 주셨으면 좋겠습니다.

---

2. 코드의 가치와 비지니스

그렇다면 좋은 코드의 가치는 무엇일까요?
결국 우리는 코드의 품질보다는 비지니스의 성공만을 위해서 개발해야 하는 걸까요?

지난 글에서는 코드가 만들어내는 가치, 즉 비지니스의 가치가 훨씬 더 중요하다는 얘기를 했습니다. 그리고 비지니스의 가치를 무시한채로 코드의 품질을 고집하려고 하지 말라는 얘기도 함께 했습니다. 그렇지만 좋은 코드를 만들기 위한 노력은 그만한 가치가 없다는 얘기는 결코 아닙니다.

비지니스가 성공하여 규모가 커지면 다시 코드의 품질이 중요해진다.

비즈니스가 성공을 하고 규모가 커지게 되면 코드의 품질이 훨씬 더 중요해지는 시기가 옵니다. 처음에 봤던 좋은 구조를 가진 코드가 만들어내는 그래프를 다시 한번 생각해봅시다.

| "코드의 품질이 중요해지는 것은 규모가 커지고 복잡도가 높아졌을 때이다."

사실 코드의 품질은 일정 수준의 규모가 되기 전까지는 잘 티가 나질 않습니다. 오히려 좋은 구조를 생각지 않고 그냥 코딩을 하는 것이 훨씬 더 개발속도 측면에서는 나을지도 모릅니다. 그렇지만 그 순간이 오게 되면 앞으로 새로운 기능과 변화를 만들어내는데 계속적으로 비용이 비약적으로 높아지게 됩니다.

이러한 지점을 맞이하게 되면 결국 서비스의 질적하락으로 이어지게 됩니다. 점점 더 코드가 나빠지고 기능의 구현성과 안정성이 떨어지게 되면 결국 비지니스의 가치를 떨어뜨리게 됩니다. 비지니스의 가치가 떨어진다는 얘기는 결국 코드의 가치가 떨어진다는 것과 같은 이야기입니다.

비즈니스의 가치를 떨어뜨리지 않게 하기 위해서는 코드의 품질이 중요합니다.

코드의 품질 역시 비즈니스의 가치 관점에서 바라본다면 비즈니스의 가치를 유지하기 위해서 코드의 품질을 계속 갈고 닦아줘야 합니다.

이미 잘 만들어졌고 코드의 품질은 새로운 기능과 변화를 저해하는 요인이니 내버려둔다면 어떨까요? 비즈니스와 코드는 가만히 놔두기만 해도 스스로 낡아집니다.

엘리스에서 나오는 붉은여왕처럼 온 힘을 다해서 변해야만 제자리를 유지 할 수 있으며 내가 가만히 있으면 주위의 변화들로 인해서 집어삼켜질테니까요.

그래서 결국은 이 코드의 품질이라고 하는 것들은 이제 비즈니스의 가치를 높이는 것보다는 떨어뜨리지 않도록 그리고 유지할 수 있도록 하는 어떤 방부제 역할이라고 생각합니다.

| "김을 계속 바삭거리게 맛있게 만들기 위해서는 방부제가 필요하다."

낙후된 코드의 품질은 개발자의 성장을 저해한다.

끊임없이 닦아주지 않으면 스스로 낡아져버리기에 제때 관리를 하지 못하고 방치를 해두고 타이밍을 놓친다면 낡은 세상속에서 계속 개발을 해야만 합니다. 조금 어질러진 방은 금방 치울 수 있지만 너무 더러운 방은 대청소가 필요한데 그러면 대청소를 하기 전까지는 치울 엄두조차 못내는 것처럼요.

그런 환경에서는 개발자의 동기부여가 떨어집니다. 그래프에 따르면 잘못된 코드와 환경 속에서는 더이상의 개발속도가 점점 더뎌지고 괴로워집니다. 나는 굉장히 열심히 하고 있지만 내가 한 결과는 티가 나지도 않고 실제로 가치를 만들어내기 보다 그 환경속에서 허우적 거리느라 대부분의 시간들을 보내게 됩니다.

개발자가 일을 할 수 없는 환경이 되면 비지니스는 유지 할 수가 없게 됩니다. 좋은 비즈니스를 지속적으로 유지하기 위해서 우리는 계속 코드의 품질 역시 관리를 해야합니다.

비즈니스의 가치가 기술적 챌린지를 만들고 결국 개발의 가치를 더 높인다.

아이러니하게도 개발의 성장은 비즈니스의 가치가 높아질때 발생을 하게 됩니다. 조그만한 규모에서는 대부분이 큰 문제가 되지 않습니다. 그러나 비즈니스의 복잡도만큼이나 코드의 규모가 커지게 되고 이때는 기존에 없던 새로운 기술적 챌린지를 맞이하게 됩니다. 그리고 그 챌린지를 넘어서야 비즈니스도 성장을 하지만 그 챌린지를 해결하는 것이 개발과 기술의 성장을 가져오게 됩니다.

규모와 복잡도가 커지면 같은 기술을 사용하더라도 난이도가 달라집니다. 우리가 개발자적인 관점에서 개발의 성장과 코드의 성장만을 바라본다고 하더라도 결국 비즈니스의 성장이 되어야만 이러한 기회를 만들 수 있게 됩니다.

비즈니스적인 가치가 높아져야 규모가 커질 수 있고, 규모가 커져야 서비스의 복잡도가 올라가고 서비스의 복잡도가 올라가는 부분들을 해결을 해야 개발자의 어떤 기술적 성장을 경험하게 해주면서 개발자적인 성장을 할 수 있게 됩니다.

결국 처음에는 비즈니스의 요구사항과 코드의 품질간에는 어느 한쪽을 포기하거나 타협을 하거나 고집을 부려서 쟁취를 해야하는 것인줄 알았지만, 사실 이 둘은 베타적인 관계가 아니었습니다. 비즈니스의 가치와 코드의 가치는 상호보완적인 부분을 가지고 있습니다.

비지니스 가치와 코드의 품질간의 균형감각

코드의 품질을 올리고자 하니 요구사항과 마감이라고 하는 비즈니스의 가치를 떨어뜨리는 것 같고, 비즈니스의 가치를 맞춰주고자 하면 코드의 품질을 포기하는 것 같지만, 사실은 서로가 서로에게 필요한 어떤 동반자적인 관계라는 사실을 알게되었습니다. 다만 동시에 둘 다 가져가려고 한다면 '나 자신을 갈아넣어야 한다. = 배드엔딩' 이라는 사실도 알게 되었죠.

그래서 종국에는 개발자에게 비즈니스의 가치와 코드품질 간의 균형 감각이 요구되게 됩니다. 비즈니스의 가치는 개발의 가치를 높여주는 쪽으로 연결이 되고, 개발의 가치를 높이는 것들은 결국 비즈니스의 가치를 또 떨어뜨리지 않도록 해주는 역할을 하는 하기에 이 시소놀이를 이해하고 받아들여야 합니다.

그래서 개발자는 적절한 코드의 품질을 계속 유지하면서도 비즈니스의 가치를 높이는 약간 균형의 수호자 역할을 해줘야 됩니다. (그렇다고 나를 희생해서 모두를 챙기려고 한다면 파국으로 이어질겁니다.) 그래서 어렵습니다. 그래서 고연차의 경험들과 판단을 필요로 하게 됩니다.

처음에 봤었던 다이어그램을 다시 한번 살펴 봅시다. 우리는 이 중에 2개를 선택하는 선택지라고 생각을 했지만 이사실 서로의 관계가 마냥 베타적인 것이 아니라는 것을 알게 되었습니다.

| "셋다 가지는게 불가능하기 때문에 꼭 어느 하나를 포기해야하는 걸까?"

지금이 어떤 상황인지 지금은 무엇을 더 중시해야 하는 상황인지, 궁극적으로는 내가 만들어내는 코드의 가치를 높이기 위해 비즈니스의 가치를 높이는 방향으로, 그러나 코드의 품질을 적절히 유지해나가면서 시기에 따라 상황에 따라 적절한 균형점을 잡아가려고 노력하고자 하는 것이 바로 잘하는 개발자라는 얘기를 드리고 싶습니다.

| "꼭 하나를 포기할 필요는 없다. 어떤 모양의 삼각형을 그려야 하는 지 아는 것이 실력이다."

---

3. 협업의 가치와 문제해결

우리는 비즈니스의 가치를 높이면서 코드의 품질을 유지하면서 변화에 유연하게 대응하고자 하기 위해서 노력하며 적절한 균형점을 찾으려고 해야한다고 했습니다. 그러기 위해서는 무엇이 필요할까요? 바로 협업이 필요합니다.

개발자의 직무로만 비지니스의 가치를 높이는건 쉽지 않다.

내가 만들어내는 코드가 만들어내는 가치로 내가 평가를 받는다고는 했지만, 실질적으로 개발자의 직무로만 비즈니스의 가치를 높이는 건 쉽지 않은 일입니다.

앞서 시장에서는 생각보다 고품질의 코드를 원하는 것은 아닌정도지만 저품질의 코드를 만들었다가는 큰일이 납니다. 앱 스토어에서 평점이 깎이는 가장 큰 이유는 제대로 동작하지 않은 "버그"때문인 경우가 많죠. 개발자에게 가장 크게 기대하는 것은 요구사항대로 구현을 하고 안정성 있는 코드를 시간내에 만들어내는 것입니다.

안타깝지만 개발자에게는 이른바 "감점식 계산법"이 적용이 됩니다. 우리가 시험을 받았을 때 가까스로 최선을 다해야 100점이고 틀릴때마다 점수가 깍이는 것처럼요.

내가 실제로 요구사항의 80% 정도밖에 완성을 하지 못했다면 그 제품은 완성했다고 보기는 어렵지만 120% 200% 더더욱 잘 만든다해도 그 초과분 만큼이 실제 비즈니스의 가치로 다 인정이 되어 보탬이 되지 않습니다. 일반적으로 개발의 업무 특성상 비즈니스의 가치의 저점을 높이는 것을 담당하지만 고점을 높이기는 어렵습니다.

테크 자체가 비즈니스의 가치를 만들어내는 경우에는 개발이 가치를 만들어내는 것이 아닌가요? 라고 생각할 수도 있습니다. 충분히 맞는 말이지만 생각해볼 내용은 여전히 존재합니다.

ChatGPT를 떠올려보면 분명 개발이 만들어낸 기술이 가치를 만들어냈다고도 보여집니다. 그렇지만 Open AI와 유사한 기술을 가진 그 전부터 더 나은 기술을 가졌을거라고 생각되어 왔던 구글이 아니라 ChatGPT에 사람들이 열광하는 것을 그 기술을 비즈니스의 가치가 발생 할 수 있도록 기획하고 만들고 브랜딩을 구축했기 때문입니다. 그리고 이러한 방향성을 정하고 비즈니스의 모델을 만들어내는 것은 일반적으로 개발자의 역할은 아니죠.

개발 기술이 비즈니스의 가치를 만들지 못한다는 것이 아니라, 개발자가 만들어내는 가치는 개발 외 다른 직군의 업무로 인해서 원래의 가치보다 훨씬 더 큰 가치를 더 만들어낼수가 있다는 것 그렇기에 협업이 중요하다는 이야기를 드리고 싶습니다.

개발자 직군의 직접적인 목표가 비지니스 가치의 창출이 아니므로 대개 가치의 충돌이 생긴다.

이렇듯 개발자 직군에게 기대하는 바는 요구사항을 구현하고 안정성과 시간마감을 잘 지켜줄 것을 기대하지 비즈니스의 가치를 직접적으로 올리는 것을 기대하지 않기에 개발자는 기대에 부응하기 위한 일, 즉 구현과 안정성을 최우선적으로 할 수 밖에 없습니다.

거기에다가 안정성과 미래를 안정성과 시간마감을 더 잘 지켜가며 요구사항을 구현하기 위해서는 코드의 품질이라고 불리는 나의 산출물 관리가 더더욱 중요해지죠. 그러다보니 원래의 큰 목표가 되어야 할 비즈니스의 가치 창출보다는 개발자에게 중요한 가치를 앞세우게 되면서 가치의 충돌이 발생하게 됩니다.

그러니까 사장님과 개발자가 싸우고, 기획자와 개발자가 싸우고, 디자인과 개발자가 싸우는 이유는 궁극적으로는 비즈니스의 가치를 높이는 것이겠지만 각자의 직군의 1차 특성에서 중요하게 생각하는 가치가 다르기 때문입니다.

코드의 가치와 비즈니스의 가치의 균형을 수호하는 사람이 되어야 잘하는 개발자라고 얘기를 드리는 것도 이러한 시각이 없는 사람들은 결국은 내가 포기하거나 내가 물러서지 않는 타협을 하는 거라고 생각을 할 수밖에 없게 되면서 베타적인 성향이 되고는 합니다.

오죽하면 이러한 부분에 대해서 "오늘도 개발자가 안된다라고 했다" 라고 밈이 생겨난 것이지요.

내 성과가 아니라 우리의 성과이고 우리의 성과가 내 성과이다.

그렇지만 결국 성과라고 하는 것들은 코드의 품질보다는 대개 비즈니스의 성과로 평가가 됩니다. 우리가 고성과자를 평가하는 기준 역시 프로젝트의 성공여부로 판단하는데, 프로젝트의 성공은 결국 돈을 얼마나 벌었나로 1차적으로는 판단을 하게 됩니다. 돈을 벌지를 못했는데 코드를 잘 작성했고 구조를 잘 만들었다고만 해서 고성과로 평가를 해주지는 않습니다.

결과적으로는 내가 만들 결과물이 얼만큼의 돈을 버느냐 혹은 얼마나 많은 사람들이 사용하고 있느냐에 따라서 성과가 판가름이 납니다. 계속해서 얘기를 하고 있는 개발한 코드가 아니라 코드로 만들어낸 비즈니스의 가치로 평가를 받게 되는 것이죠.

하지만 앞서 설명했듯이 개발자의 직군은 비즈니스의 가치를 직접적으로 성장시키는 역할을 하고 있지는 않습니다.

그렇기 때문에 내가 만든 가치를 더 올릴 수 있도록 나를 도와줄 사람이 필요하고, 나 역시 그들을 도와서 비즈니스의 가치를 구현하고 만들어 낼 수 있어야 합니다.

그렇기에 우리는 협업이라고 하는 것들을 잘 해야 합니다. 나 혼자만 잘한다고 해서 이러한 성과들을 만들어 낼 수 있는 것들이 아니기 때문입니다. 설사 내가 잘해서 무언가의 성과를 낸다고 하더라도 내 주위 사람들은 나의 성과를 훨씬 더 크게 만들어주게 만들 수 있는 사람들이라는 것을 생각해주시면 좋겠습니다.

나를 위해 협업하자! 내가 남을 돕는게 곧 나를 돕는 일이다.

결국 나를 위해서 협업을 해야 됩니다. 내가 남을 돕는 게 곧 나를 돕는다라는 생각으로 이기적인 이타심을 좀 발휘를 하셔야합니다.

개발자가 개발 직군에서 비즈니스 가치를 높이기가 어렵다고 비즈니스 가치를 높이는 위해 기획이나 사업에 관여를 해서 감놔라 배놔라 해서 끌고가는 방법은 아니어야 합니다.

협업이란, 목표는 함께 공유하면서도 각자의 전문성을 더 잘 발휘할 수 있도록 서로 도와주는 것이며 전문성들의 통합이 서로 시너지가 되어 더 큰 가치를 만들어내는 과정입니다.

그렇게 하기 위해서는 내가 가진 나의 전문성으로 남이 가진 남의 전문성이 더 빛이 날 수 있도록 지원하는 것입니다. 기획이 기획을 더 잘할 수 있게, 디자이너가 디자인을 더 잘 할 수 있게, 사장님이 돈을 더 잘 벌 수 있도록 궁리할 수 있게, 나는 개발로써 이들을 돕고자하는 방법을 고민하고 찾아내고 실행하는 것이 협업을 잘하는 개발자이자 궁극적으로 비즈니스 가치를 만들어내는 잘 하는 개발자가 됩니다.

그렇기에 우리는 남들을 잘 도울 수 있는 방법을 고민해야 하고 남들을 도와주려고 하는 자세를 가져야 합니다. 뿐만 아니라 언제든 기꺼이 도움을 받으려고도 해야 합니다. 그게 결국은 나를 위하는 길이라는 사실을 기억하셔야 합니다.

개발은 코드로만 하는게 아니다.

개발의 가치가 코드에만 있는 게 아니라 코드가 만들어내는 가치에 있다고 한다면 결국 코드가 만들어내는 가치를 높이는 모든 과정 또한 개발이라고 볼 수 있습니다.

그렇게 생각하면 개발은 코드로만 하는게 아니라는 것을 알 수 있습니다. 비록 1차적으로 기술을 통해서 코드를 작성하는 게 어떤 개발자의 역할이지만 우리의 목표는 결국 코드가 아니라 비즈니스의 가치를 높이는 것이라면 내가 만드는 비즈니스의 가치를 높이기 위해 나와 함께 하는 사람을 도와주고 도움을 받고 문제를 해결하는 모든 과정 또한 개발입니다.

| "코드를 작성하지 않아도 다른 사람과 함께 하는 모든 행위가 곧 개발이고 비지니스다."

프로그래머를 넘어서 문제 해결사가 되자!

그래서 우리는 프로그래머가 아니라 문제해결사라는 관점을 가져야 합니다.

개발자의 진짜 역할은 코드를 만들어내는 게 아니라 문제 해결입니다. 우리가 해결할 수 있는 문제들이 코드안에도 있지만 우리가 만나는 문제들은 코드 밖에도 존재합니다.

코드를 통해서 문제를 해결하기 위한 구현을 하는 것은 1차적인 개발자의 가장 중요한 덕목이지만, 그 이상을 넘어서 코드를 만들기까지 위해서 그리고 그 코드가 만들어내는 가치를 더 높이고자하는 과정에서 겪는 모든 문제들을 다 해결하는 것이 개발자의 역할이고 이것들마저 잘하는 것이 잘하는 개발자가 될 수 있다고 생각을 합니다.

그렇기에 코드를 잘 작성하는 것을 넘어 일정 마감, 기술 교체, 기술 부채에 대한 해결, 사용자의 니즈 파악, 팀원 간의 의사소통, 협업들이 모두 개발자의 역량에 포함이 되는 것이며 이 모든 과정들을 궁극적으로 비즈니스의 가치를 높이기 위한 여정이고 그러기 위해서 우리는 혼자서가 아니라 함께 할 수 있어야 합니다.

그래서 코드는 우리가 해결해야할 문제를 풀수 있는 도구 중에 하나이며, 어떻게 문제를 해결하고 어떤 가치를 창출하고 어떤 것들을 할 것인지에 대한 결정하는 것과 마음가짐과 접근 방식이 중요하다라는 얘기들을 드리고 싶습니다.

---

3. 함께 문제를 해결하기

코드를 잘 작성하면서도 비즈니스의 가치를 높이는 잘하는 개발자로 성장을 하다보면 문제해결과 협업이라고 하는 곳에 다다르게 됩니다.

문제는 혼자서 해결하는게 아니라 함께 해결을 하는 것이죠. 문제해결과 함께 협업에 대한 이야기를 해보고자 합니다.

문제: 공항의 민원처리 이야기

제가 다른 발표 영상에서 들은 이야기 하나를 들려드릴까 합니다. 어떤 공항의 민원처리 이야기입니다. (출처를 계속 찾는 중인데 잘 찾아지지가 않네요. 정확한 수치등은 조금 다를 수 있습니다.)

어떤 공항이 있었습니다.

이 곳에서는 비행기에 내려서 곧바로 수화물을 찾으러 가면 30분이나 기다려야 짐을 찾을 수가 있었습니다. 대기줄과 대기시간로 인해 공항은 언제나 혼잡했으며 이로 인해 항상 민원이 끊이질 않았습니다.

이 문제를 해결하기 위해서 엔니지어들은 갖은 수단을 동원해 15분까지는 단축을 시킬 수 있었습니다. 이것은 대단한 성과였지만 여전히 너무 오래 기다려야 한다고 하는 민원의 비중은 크게 줄지 않았습니다.

대기 기간을 기술적으로 더 이상 줄이는 것은 한계라고 보여지는 이 상황이지만 새로운 담당자는 이 문제를 해결했습니다.

어떻게 문제를 해결했을까요?

해결: 수화물을 찾는 위치를 옮긴다. 그것도 더 멀리

새로운 담당자가 제시한 해법은 비행기에서 내리는 곳에서 수화물을 찾는 위치를 기존보다 더 멀리 옮기는 것이었습니다. 그래서 공항이용자에게는 실질적으로 짐을 찾게되는 기간은 이전에 비해서 오히려 더 늘어났습니다.

그렇지만 오히려 사람들은 비행기에 내려서 수화물을 찾으러 가는 동안 에스컬레이터를 타면서, 주변 구경을 하면서 오는 시간들을 대기시간이라고 생각하지 않습니다.

그리고 오히려 수화물을 찾으러 가는 곳에 도착하자마다 바로 내 짐이 나와 있는 것을 보고 이 공항은 굉장히 신속하고 일을 빠르게 처리한다고 칭찬을 들을 수 있었습니다.

대기시간이 길다는 것이 문제의 시작이었지만 그래서 대기시간을 줄이려고만 해서 문제를 해결할 필요는 없었습니다. 그보다 훨씬 더 좋은 해결방법은 있었습니다.

교훈: 모든 문제를 개발로만 해결하려고 할 필요가 없다.

저는 이 이야기에서 다양하고 많은 인사이트를 느낄 수 있었습니다. 그중에서도 제가 작성하고 있는 글과 관련이 있는 인사이트는 개발로만 모든 문제를 해결하려고 할 필요는 없다는 것이었습니다.

뿐만 아니라 요구사항을 요구사항 그대로 해결하려고만 하지 않아야 된다는 것도 알 수 있었습니다. 분명 처음 요구사항은 짐을 찾을 수 있는 대기시간을 줄여달라라는 것이었지만 그걸 구현하는 것만이 떄로는 최선이 아닐수도 있고 실질적으로 불가할수도 있습니다.

이러한 상황은 사실 개발자에게는 낯설지 않다고 생각을 합니다. 자주 발생하는 일이죠. 내가 고민고민해서 해결하고자 하는 것보다 기획을 바꿔서 해결하는 편이 나은 경우가 훨씬 더 많습니다. 반대로 기획을 바꾸면 더 쉽게 할 수 있는 일을 꾸역꾸역 개발을 하다가 엎어지는 경우도 허다하죠.

지금 최선이라고 생각하는 방법이 실제로는 최선의 방식이 아닐 수도 있는 것이고, 특정한 방법에 매몰이 되면 다른 것들을 볼 수 없다는 것들도 느낄 수 있는 이야기였습니다.

실제 개발 경험담 하나.

앞선 공항이야기가 인상깊었던 이유는 이야기가 주는 교훈과 인사이트도 있겠지만 실제로 유사한 개발 경험담이 있었기에 더 기억에 남는 것 같습니다.

서비스를 개발하면서 특정 서버의 api 호출이 10초가 넘어가고, 30초가 넘어가고, 심지어 1분이 넘게 걸리는 경우가 발생하는 상황을 맞이한적이 있었습니다. 헤비유저들에게만 발생하는 건이었지만 이로 인해서 주요 사용자가 서비스의 로딩 시간이 너무 길다고 하는 불만들이 많아졌습니다.

내부에서는 성능 개선을 계속하고 있지만 어떻게 언제까지 개선이 될지도 모르고, 최적화가 가능한 부분인이도 판단하기 어렵다고 하는 상황이었습니다.

그렇다고 서버성능이 개선될 때까지 업데이트를 무한정 미루거나 양해만 구하면서 넘어갈수는 없다고 생각을 했습니다.

당시의 쟁점들

• 서버 API가 느린 문제니까 서버가 해결해야 되는거 아닌가요?
• 로직이 아니라 인프라가 못 받쳐주는 상황인데 인프라 확충은 안되나요?
• 인프라 확충은 지금 문제로 인해서 지원하기 어려워요.
• 클라이언트에서는 캐싱을 하면 안되나요?
• 보안정책상 로컬에 보관하면 안되는 데이터가 있는데 지금 데이터가 그렇습니다.
• 설사 캐싱을 해도 동기화하는 과정이 상당히 어색하게 보여요.

...어떻게 하면 좋을까?

어떻게든 다 같이 힘을 모아서 되게 해보자!

그러면 결국 서버 이슈이니까 서버에서 처리해주세요. (X)
우리 문제니까 다 같이 함께 어떻게 하면 좋을지 고민해봐요! (O)

이게 서버에서 발생하는 이슈이기에 서버 API만 최적화를 하면 끝나는 문제라고 생각할 수 있었지만, 당시에는 어떻게든 다 같이 힘을 모아서 이걸 되게 해보자라고 생각을 했습니다.

앞선 쟁점들을 양보할 수 없는 각자의 입장이 아니라, 이 상황이 우리가 함께 해결해야 될 문제로 보고, 내 전문성에 입각을 해서 어떻게 이 문제를 해결할 수 있을까에 대해서 머리를 맞대고 함께 고민을 해보기 시작했습니다.

• 서버에서 한번에 데이터를 전달해줘서 오래걸리는 거라면 이걸 나눠서 전달하는 방식은 어떨까요? 클라이언트에서는 스트림하게 받아서 처리해볼 수 있을 것 같아요.

• 캐싱을 했을때 동기화가 부분이 어색한 부분은 디자인에서 자연스럽게 만들 수 있는지 고민해볼게요.

• 보안정책을 우회할 수 있는 방법을 찾아보겠습니다. 일단 안되더라도 캐싱을 먼저 만들어서 디자인을 테스트 할 수 있게 전달을 드려볼게요.

• 보안정책에서 정확하게 어떤 부분이 문제였는지는 제가 담당자랑 확인해보겠습니다.

• 인프라쪽은 비용이 들지 않는 선에서 지원받을 수 있는건 없는지도 같이 확인해볼게요.

우리의 문제를 각자의 분야에서 다른 분야의 업무를 도와줄 수 있는 방법을 제안하고 강구하면서 해결방법을 찾고자 노력했습니다.

우리가 만들어낸 성과들

• 보안정책에서 문제가 되는 내용들은 사용자가 데이터를 접근할 수 없고 눈으로 볼 수 있는 방법이 없으면 되는 부분이었기에 클라이언트에서는 자체적으로 가벼운 보안처리를 통해서 캐싱데이터를 보관하기로 하였습니다.

• 서버에서는 당장의 성능을 개선할 수 없었기에 데이터를 여러번의 호출로 나눠서 전달할 수 있는 방법을 만들면서 여러번을 전달하더라도 1회응답의 속도는 평균 300ms를 보장할 수 있도록 만들었습니다.

• 클라이언트에서는 캐싱 기능과 낙관적 업데이트를 통해서 서버와 무관하게 반응속도를 개선하였고 체감속도를 크게 향상시킬수 있었습니다.

• 이 과정에서 디자인적인 개선이 있었고 전보다 훨씬 빨라보이는 서비스를 만들 수 있게 되었습니다.

실질적으로 서버 API의 속도를 당장 개선을 하지는 못했습니다. 그리고 우리는 꽤나 많은 작업들을 해야했습니다. 그렇지만 우리는 상당한 체감속도 개선을 할 수 있었고 이 업데이트는 상당히 반응이 좋은 업데이트가 되었습니다.

이로 인해서 서버는 해당 이슈를 급하게 다뤄야 할 사안이 되지 않았고, 그로인해 전체적인 구조를 개선할 충분한 시간을 들인 상태에서 나중에는 원래보다 더 나은 구조로 개선이 되었습니다.

분명 처음의 요구사항은 "서버의 응답속도가 너무 느려요" 였지만, 서버의 속도를 당장 개선할 수 없다는 상황에서 문제를 다같이 해결하고자 노력했기에 더 나은 성과를 가져올 수 있게 되지 않았나 생각을 합니다.

그리고 그렇게 할 수 있었던 것은 이 문제가 서버의 문제가 아니라 우리의 문제라고 생각했고 다같이 이 문제를 해결하자고 했기 때문이라고 생각합니다.

다시 보는 당시의 쟁점들

• 서버 API가 느린 문제니까 서버가 해결해야 되는거 아닌가요?
• 로직이 아니라 인프라가 못 받쳐주는 상황인데 인프라 확충은 안되나요?
• 인프라 확충은 지금 문제로 인해서 지원하기 어려워요.
• 클라이언트에서는 캐싱을 하면 안되나요?
• 보안정책상 로컬에 보관하면 안되는 데이터가 있는데 지금 데이터가 그렇습니다.
• 설사 캐싱을 해도 동기화하는 과정이 상당히 어색하게 보여요.

??? : 그러면 결국 서버 이슈네요. 서버에서 잘 처리해주세요.

라고 했으면 어떻게 되었을까요?

---

4. 문제 해결을 잘 하는 개발자가 되기 위한 Tip

문제해결이란 상대적인 것이고 상황에 따라 다르기 때문에 정답이 있을 수 없고 그래서 어려운 것입니다. 그렇기에 문제 해결을 하는 정답은 있을 수 없겠죠. 우리의 많은 경험과 경험으로 인해 만들어지는 넓은 시야를 통해서 문제를 해결하는 능력을 발전해야할 것입니다.

그렇지만 무언가 이 글을 통해서 생각과 마음가짐에 대한 이해에서 그치는 게 아니라 실질적인 도움이 되기를 바라기에 처음에 문제해결에 대해서 어떻게 실마리를 풀어갈지 도움이 될만한 내용들을 준비해보았습니다.

문제 해결을 잘 하기 위한 Tip #1 - '본질찾기'

공항이야기에서 우리가 느끼는 또 다른 교훈은 결국 문제 해결을 잘 하기 위해서는 핵심이 되는 문제가 무엇인가를 잘 찾아야 한다는 것입니다. 그리고 우리가 어떤 목표를 가지고 해결을 해야하는지를 잘 설정하는 것이 중요합니다.

문제의 시작은 "수화물을 대기하는 시간이 너무 길어서 불편해요." 라는 민원이었습니다. 문제의 본질이 아닌 문제들은 파생되는 문제로 파생되는 문제에 대응하는 식으로만 처리하면 해결이 안되는 경우가 발생하곤 합니다. 단순히 '대기하는 시간이 길다고 하니 대기하는 시간을 줄이면 해결이 되겠군'과 같이 문제에 그냥 1차적으로 대응하는 해결방식은 본질적인 문제 해결이 아닐 수 있습니다.

사용자들의 불만은 "실제 대기시간"이 아니라 "체감시간"이었으며 공항이 혼잡한것은 단순히 1차적으로 시스템만의 문제가 아니라 전체적인 공항 동선 설계의 미흡과 경험제공의 부족이었던 것이었습니다.

문제 해결을 잘 하기 위한 Tip #2 - '모순을 찾아 해소하기'

본질적인 문제를 찾기 위해서는 어떻게 해야할까요? 그러기 위해서는 모든 상황들을 다 펼쳐놓고 살펴봐야 합니다. 이 문제가 다른 문제로 인해서 파생이 되고 있는 현상인 것인지 실제 문제의 본질인지 말이죠.

진짜 문제가 발생하는 순간은 두 가지의 입장이 대립이 되어 있거나 더 이상 해결을 할 수 없는 막혀있는 상황에서 발견할 수 있습니다. 얼핏 모순되어 보이고 교착되어 보이는 이 순간에서 우리는 진짜 문제해결을 할 수 있는 방법을 발견할 수 있게 됩니다.

'어떻게는 둘다 만족 시킬 수 있는 다른 방법은 없을까?'

두번째 이야기에서 캐싱과 보안은 서로 상충되는 가치처럼 보일 수 있엇지만 캐싱과 보안을 함께 처리할 수 있는 방안으로 고민을 하니 오히려 답이 쉽게 나와버리는 경우가 있습니다.

한쪽이 안될 거라고 하니까 안된다고 생각하는 순간부터 이 문제는 해결할 수 없는 문제가 되고 한쪽의 방향성으로 매몰이 되게 됩니다. 그 교착을 해결하는 방법이야말로 진짜 멋지게 문제를 풀 수 있는 열쇠가 되어줄것입니다.

문제 해결을 잘 하기 위한 Tip #3 - '함께 해결하기'

문제의 본질을 찾고 문제의 모순과 교착과 대립을 찾기 위해서는 다양한 시각과 다양한 전문성이 함께 필요합니다. 그러기 위해서는 우리는 팀으로써 함께 해야합니다.

어떤 문제들은 특정 직군의 전문성만으로는 해결하지 못하는 문제들이 있습니다. 혹은 다른 직군의 전문성으로 인해서 훨씬 더 쉽게 해결할 수 있는 방법이 존재하는 경우도 많습니다.

내가 하면 더 쉬워지는 문제가 있고, 내가 하면 더 어려워지는 문제도 있습니다. 반대의 경우도 마찬가지입니다. 개발 문제를 디자인이 풀어줄 수도 있고, 디자인 문제를 기획이 풀어줄 수도 있는 것이 바로 협업이라고 생각을 합니다.

그러기 위해서는 지금의 문제는 각자의 입장이 아니라 우리의 상황이며 우리가 함께 해결해나가야한다고 믿고 우리의 기준에서 더 나은 방법을 선택할 수 있어야 합니다.

협업이라고 하는 것은 단순히 함께 일하는 것이 아니라 서로의 전문성과 지식을 통합해서 더 큰 가치를 창출해내는 과정인 것이죠.

---

5. 협업을 잘하는 개발자가 되기 위한 커뮤니케이션 Tip

문제해결과 협업이라는 주제로 실질적인 팁을 드리고 있으니 협업에 대해서도 한번 이야기 해보려고 합니다만, 협업을 잘하는 방법을 얘기하기에는 정말로 많은 이야기를 해야합니다. 개발에 있어 협업의 정수라고 하는 애자일에 대해서도 해야할 얘기도 그리고 방법론이라는 측면에서 어설프게 적용을 하면 더 부작용이 생기는 경우가 많습니다.

협업을 잘하는 사람이 되기 위해서는 같이 일하기 편한 사람이 되어줘야 됩니다. 그래서 이번 글에서는 협업을 잘 하기 위해 필요한 첫번째 단추인 커뮤니케이션을 잘하는 팁에 대해서만 한번 다뤄볼까 합니다.

'심리적 안전감' 만들어주기 - 마음의 치안

협업을 잘하기 위해서는 심리적 안전감을 만들어주는 것이 제일 중요합니다. 심리적 안전감이란 내가 이 사람과 함께 있을때 내가 어떤 말을 해도 별로 개의치 않다라고 느끼는 것을 의미합니다.

심리적 안전감은 마음의 치안과 같은 것입니다. 치안이 좋은 곳에 있으면, 마치 우리가 대한민국에서 테이블에 휴대폰이나 노트북을 두고 화장실에 다녀오거나 자리를 잠깐 비워도 불안하지 않지만, 외국에 나가서 치안이 불안한 곳을 지나갈때면 배낭도 앞으로 매고 지갑도 휴대폰도 매번 잘 있는지 챙기게 되는 것은 생각해보시면 좋을 것 같아요.

한번 떠올려보세요. 내가 심리적 안전감을 느끼고 대화하는 상대와 그렇지 않은 상대와 이야기를 할때는 내가 얼마나 달라지는 지는 내가 불편하다고 느끼는 사람 1명만 떠올려서 같이 있다고 생각을 해봐도 알 수 있을 거라고 생각합니다.

적어도 나는 내가 함께 하는 사람과는 이러한 심리적 안전감을 만들어주지 못하는 사람이 되면 안되겠죠. 나에게 어떤 이야기를 하는 데 있어서 불편함을 느끼지 않도록 만들어주는 것이 협업을 시작하는데에 있어서 정말 중요합니다. 그러기 위해서는 친해지고 잘 들어주는 사람이 되어야 합니다.

협업이라는 관점에서 친하다라고 하는 것은 사적인 친함과는 다른 의미입니다. 사적인 이야기나 비밀등을 공유하고 편을 만든다고 친해지는 것이 아닙니다. 심리적 안전감의 워딩 그대로 내가 어떤 이야기를 하건 간에 비판없이 비난없이 불편함 없이 들어 줄 수 있을 거라는 믿음에서 친하다라는 것이 시작됩니다.

또한 잘 들어준다고 하는 것들은 시키는 대로 한다고 하는 것들과 전혀 다른 의미입니다. 시키는대로 잘 하지 않더라도 서로 대화만 잘 할 수 있다면 충분히 심리적 안전감은 제공할 수 있습니다. 시키는대로만 해도 표정이나 대화가 잘 되지 않는다면 여전히 말을 하는데 불편함을 느낄 수 있습니다.

심리적 안전감은 좋은 팀이 갖춰야 중요한 항목인데 적어도 일단 나부터 심리적 안전감을 생각하며 갖출수 있도록 생각을 해봅시다.

추가) '심리적 안정감'이라는 워딩을 썼다가 '심리적 안전감'으로 수정했습니다. 실제로 혼용해서 쓰이고 있으나 개인의 관점에서 느끼는 '안정감'이라는 표현보다는 팀과 타인이 조성해줘야 하는 '안전감' 이라는 표현이 내가 타인에게 만들어줘야 한다는 뉘앙스를 더 잘 전달한다고 생각했습니다.

안된다고'만' 말하지 않기

원래는 "안된다고 말하지 않기" 라고 제목을 지으려고 했다가 오해의 워딩이 될 것 같아서 '만'를 붙여보았습니다ㅋ

개발자의 특성상 안된다라고 말을 해야 하는 경우가 너무나 많습니다. 그때마다 무조건 된다고 말했다가는 자발적 야근과 번아웃으로 직행하게 되는 것이죠. 여기서 말하는 것은 그 반대의 경우입니다.

협업이 잘 안되는 개발자들의 안된다는 다음과 같습니다. 이걸 개발해야 하는 이유나 비즈니스 가치에 대한 관심은 전혀 없이 오로지 개발의 관점에서 현재 구조에서 구현이 가능한가와 복잡도가 높아지는지에 대한 이야기만 하거나 일정에 대해서 보수적으로만 잡으려고 하는 것들이 있죠.

비즈니스의 가치에 관심이 없는 개발자와 함께 협업을 하는 것은 참 쉽지 않습니다. 내가 만드는 서비스를 더 낫게 만들고자하는 과정에서 문제를 해결하고자 하는 방법을 함께 찾으려고 하기 보다는 일을 개발을 하기 위한 의뢰이며 코드 속에서 묻혀있다면 외부에 있는 사람들은 언제나 새로운 것을 하기 위해서는 그 사람의 세계에서 가능한지 물어보고 허락을 받으러 가야합니다.

그러다보면 새로운 가치를 만들어보려고 해도 '이거 가능하다고 할까?' 하면서 자기검열이 빠지게 되고 이런 것들을 가져갔는데 안된다고 하는 경험들이 많아지다보면 이것들에 지쳐서 그냥 생각을 넘겨버리거나 고집을 부리면서 대립으로 이어지게 됩니다.

또한 개발자가 허락을 해야만 할 수 있는 상황들이 쌓이면 어느 순간 권력이 되어버리게 되고 일정과 개발을 좌지우지하려고 하는 상황이 겹쳐지면 나도 모르게 나쁜 사내 정치라고 불리는 형태에 빠지게 됩니다. 그래도 본인의 업무에 열정적이라면 협의라도 가능하지만 나쁜 마음을 먹고 일을 안하려고 하는 식으로 가게 된다면 협업에 있어서 최악의 상황을 맞이하게 됩니다.

그러니 우리는 처음부터 "안된다"라고 하는 말을 먼저 하기전에 왜 이 과제를 해야하는지 어떤 문제를 해결하고자 하는지를 이해하고 이 과제의 비즈니스 가치를 공감하여 다른 관점에서 새롭게 해결할 수 있는 대안을 함께 고민을 하는 개발자가 되고자 노력을 합시다.

그럼에도 "안된다"라고 말을 해야하는 경우라면, 내가 덜 귀찮고 싶어서 코드구조를 방패막이로 하는 것인지, 진짜 안될수 밖에 없는 상황인지, 아니면 내가 개발에 매몰에 되어 있어서 다른 해결방법이 보이지 않는 것인지 검증하고자 어떻게든 하려고 하는 방향으로 함께 고민을 한다는 전제로 지금의 방식은 이러한 이유로 안되는 것이기 다른 방법을 찾아보자는 식으로 얘기를 해보고자 노력해야합니다.

시켜서 해야 하는 일이 아니라 '나(우리)에게 주어진 해결해야 하는 문제'라고 인식하기

일을 하게 되면 업무를 분배하고 진행을 하기 위해서 Task라는 형태로 업무를 하달받게 됩니다. 그렇지만 우리는 이 업무를 시키니까 하는 일이다 라고 생각을 하면 어떻게든 해내야 하는 거라고 생각을 하게 되는데 그러지 못하는 상황이 겹치게 되면 안된다라고 말하는 것도 아니고 나를 갈아넣어서 해야 되는 것도 아닌 것 같아서 불합리하다라는 생각에 빠지게 됩니다.

그리고 이러한 생각들에 갇히다보면 나와 같이 일을 하려고 하는 사람들이 모두 나에게 일을 떠 넘기려고 하는 사람들처럼 보이게되면서 협업을 하지 않으려 하게 되고 주어진 일이 아닌 일이 더 벌려지는 형태를 꺼리게 됩니다.

하지만 모든 과제들은 나에게 시키는 일이고 나는 시켜서 일을 하는 존재라고 생각하지 않고, Task는 그저 문제와 해결방안을 하나의 세트로 형상된 형태이며, 우리가 해결해야할 문제들 가운데 내가 할 수 있을거라고 생각해서 나한테 부탁하는 거다 라고 생각을 하면 훨씬 더 주도적으로 업무를 하고 나아가 필요하다면 충분히 협업을 시도할 수 있게 됩니다.

이게 나의 일이 아니라 우리의 일이며 함꼐 해결해야하는 문제라면 해결하는 방법에 대해서도 일정조정에 대해서도 얼마든지 편하게 얘기를 나눠볼 수 있게 됩니다. 조금 더 큰 관점에서 주도적으로 함께 일을 할 수 있다고 인식해주세요.

'지식의 저주'에 빠지지 않기- 맥락의 차이가 오해를 만든다.

우리가 특히 타직군과의 협업이 잘 되지 않고 커뮤니케이션이 잘 되지 않는 이유는 서로가 알고 있는 맥락과 사전지식의 차이가 나기 때문입니다. 그리고 우리는 당연히 이 사실은 잘 알고 있습니다. 기획자와 개발자와 디자이너가 배우고 알고 있는 지식은 다르다라는 것은 너무 자명하지요.

그럼에도 우리는 언제나 '지식의 저주'에 빠지게 됩니다. '지식의 저주'란 내가 어떤 이야기를 할때 상대방도 당연히 이러한 배경을 알거라고 생각을 하고 말을 하게 되는 것을 말합니다. 이건 특히 내가 어떤 분야에 대해서 전문가일 경우에 더 많이 발생이 됩니다. 자기도 분명 모르고 있던 시절이 있었을텐데 알고 나면 너무나 당연하다고 생각하는 세상이 되면서 대화를 하다보면 상대방에게 '아니 이것도 몰라?' '아... 너무 당연한건데 왜 이게 이해가 안되지?' 하면서 내가 가지고 있는 지식이 저주가 되어 공감하지 못하는 사람이 되곤합니다.

심지어 같은 직군내에서도 내가 회사에서 어떤 정보를 얼만큼 알고 있는지에 따라서 같은 이야기를 전혀 다르게 말할 수 있고 오해를 할 수 있게 됩니다. 분명 서로 알고 있는 맥락이 같을 수 없는 것인데 맥락을 알고 있는 사람은 내가 알고 있는 만큼 상대방도 알고 있을 거라고 생각을 하면서 얘기를 나도 모르게 하게 됩니다.

사람이라면 어쩔 수 없이 빠지게 됩니다. 특히 우리가 같이 지식을 기반으로 전문가의 길을 걸어야 하는 사람에게는 더더욱 그렇습니다. 나도 모르게 비개발자에게 쉽게 설명하겠다면서 시작했지만 어느순간 개발용어를 남발하면서 설명하곤 합니다. 개발을 잘하는 사람이 개발을 가르치는 강사보다 설명을 더 잘 못하는 이유이기도 합니다.

우리는 지식의 저주라는 내용을 기억하면서 협업과 커뮤니케이션을 할때 '왜 이걸 모르지? 왜 이게 이해가 안돼?' 라는 생각이 든다면 그 원인이 나에게는 있지 않을지 항상 생각을 할 수 있도록 해서 '지식의 저주'를 극복할 수 있도록 노력해본다면 좋겠습니다.

의도와 맥락을 분명히 하고자 하기

우리가 얘기를 할때에는 실제로 그 뜻이 아니더라도 맥락이 공유한다면 알아들을 수 있는 말들을 주로 쓰곤합니다.

가령, "밥 먹었어?" 라고 하는 말은

1. 실제로 밥먹을 먹었는지 궁금하다.
2. 밥 안먹었으면 같이 먹으러 가자.
3. 그냥 안부 인사 대신.
4. 밥을 챙겨먹어야 하는 시간이라 챙겨주려고 물어봤다.
5. 등등..

반대로 이렇게 얘기를 할 경우 맥락이 공유되지 않았다면 어떤 의도로 얘기를 했는지 추측을 해야하고 이러한 추측이 틀렸을때에는 커뮤니케이션의 오해가 발생하곤 합니다.

일상생활에서는 이러한 오해는 큰 문제가 아닐 수 있지만 협업을 하는 과정에는 이러한 불필요한 오해를 만들어내는 과정을 최소화해야합니다. 커뮤니케이션 과정중에 의도와 맥락을 추측해야 하는 일들이 빈번해지고 그러한 추측을 잘 못했을때 오해나 피해를 입는 상황이 누적이 된다면 주객이 전도되어 커뮤니케이션을 더 신경을 써야 하는 문제가 발생하게 됩니다. 무엇보다 협업을 하는 상황이라면 서로의 맥락이 같을 수 없기 때문에 더더욱 힘들게 됩니다.

그렇기에 협업을 할 때의 커뮤니케이션에서는 의도와 맥락을 항상 포함해서 말을 하려고 노력해야합니다. 의도는 말을 하는 목적을 의미하고 맥락은 나는 알고 있지만 상대방은 모를 수 있는 내용을 적어주어야 합니다.

커뮤니케이션에 항상 의도와 맥락을 포함시키자.

• 무슨 목적을 가지고 이야기를 하는지 - 의도
• 목적을 이행하기 위해서 상대방이 알아야 하는 정보 - 맥락
• 어떤 정보를 상대방이 모르기에 알려줘야 하는지 - 맥락

또한 이거, 그거, 전에 했던거 와 같이 맥락을 알아야만 추측이 가능한 말은 가급적 쓰지 말도록 합시다.

맥락을 통해 추측해야하는 말은 쓰지 말자.

• "그거 이번주 까지 되요." (X)
• => 화면공유기능은 기능 구현은 이번주 목요일까지는 완료됩니다. (O)

'지식의 저주'로 인해서 나는 의도와 맥락을 가지고 커뮤니케이션을 했지만 실제로는 의도와 맥락이 사라져서 상대방으로 인해 말의 목적과 정보를 추측하도록 만들게 하는 것은 잘못된 커뮤니케이션 방식입니다. 언제나 커뮤니케이션을 할때에는 내가 의도와 맥락을 분명히 했는지 스스로 확인할 수 있도록 해야겠습니다.

설득이 아니라 생각의 주파수를 맞추는 것이다.

협업의 커뮤니케이션은 결국 서로간의 맥락의 차이를 메꿔가는 것이 중요합니다. "생각의 주파수를 맞춘다" 라고 하는 것은 이러한 과정을 참 멋있게 표현한 말이라고 생각합니다.

특히 대립이 되어 있는 상황에서 문제해결의 방법이 나온다는 사실을 떠올려보신다면, 협업의 커뮤니케이션은 상대방을 설득시키고 내 생각을 관철시키는 것이 아니라는 것을 기억해주세요.

설득이 아니라 큰 틀에서 맥락을 공유하면서 다르다고 생각하는 부분, 미처 몰랐던 부분들을 함께 맞춰보다보면 우리가 서로를 관철시키려고 하는 것이 아니라 함께 우리의 문제로 인식하고 바라볼 수 있게 되고 같은 문제를 각자의 전문성으로 각자의 시각으로 바라보게 되면 신기하게도 문제를 풀 수 있는 방법을 새로운 방법을 찾게 됩니다.

---

끝으로...

성장을 하다 보면 가치관도 사고도 함께 성장합니다.

처음에는 이론 개발을 배우면서 공부를 하다 보니 이론보다는 구현이 더 중요하다고 생각을 했고, 구현을 잘하게 되니 단순히 구현만 하는 것이 아니라 좋은 품질의 코드를 만드는 게 중요하다는 것을 알게 되었습니다.

좋은 품질의 코드를 만드는 것을 고집하게 되면 제품의 가치나 시간 마감을 맞추지 못하면서 내가 잘 만든 코드보다도 무엇을 만들었는지에 따라서 내 가치가 달라지는 것을 느끼면서 비즈니스의 가치를 높일 수 있는 것이 중요하다는 것을 느꼈습니다. 특히 비즈니스가 망하고 코드의 의미가 사라지는 것을 느끼면서 개발은 비즈니스의 가치를 만들기 위한 도구라는 생각을 하게 되었습니다.

그렇다고 비즈니스 가치만 챙기다 보면 코드의 품질을 소홀히 하게 되면서 기술 부채로 인해 중요한 타이밍에 비즈니스의 가치를 챙기지 못하고 떨어뜨리게 됩니다. 더 이상 이 프로젝트를 하고 싶어하는 사람들을 찾기가 힘들어지고 프로젝트의 생명을 꺼지는 것들도 보았습니다. 여전히 비즈니스 가치를 유지시키기 위해서 나의 전문성인 코드를 잘 만들고 관리하는 것은 중요합니다.

그럼에도 내가 만들어내는 것은 코드이지만 그 가치는 코드에 있는게 아니라 비즈니스의 가치를 만들어내는 것이기에 궁극적으로는 비즈니스의 가치를 높이고자 해야합니다. 그러기 위해서는 비즈니스의 가치를 올려줄 수 있는 사람들과 협업을 해야합니다.

코드가 만드는 가치로 내가 평가를 받는 것이라면 코드를 작성하지 않아도 코드가 만들어 내는 가치를 높이는 행동 또한 개발이라고 볼 수 있습니다. 그렇기에 우리는 프로그래머를 넘어서 문제해결사라는 인식을 가져야 합니다.

그렇기에 코드를 잘 작성하는 것을 넘어 일정 마감, 기술 교체, 기술 부채에 대한 해결, 사용자의 니즈 파악, 팀원 간의 의사소통, 협업까지고 잘 할 수 있는 사람이 잘하는 개발자입니다.

그렇기에 코드는 우리가 가지고 있는 소중하고 멋진 도구 중 하나일 뿐이며 궁극적으로는 어떻게 문제를 해결하고 어떤 가치를 창출하고 어떤 것들을 할 것인지에 대한 결정하는 것과 마음가짐과 접근 방식이 중요하다는 얘기를 드리고 싶습니다.

내 가치를 높이는 과정이 코드 밖에도 있다는 것을 알게되면 훨씬 더 일을 하는 과정에서 주체적으로 일을 할 수 있게 됩니다. 일정의 마감을 지켜줘야 하고 구현을 해줘야 하는 것이 아니라 우리의 문제를 함께 논의하며 풀어나가는 것입니다. 이러한 마인드는 일 자체와 모든 과정을 다 즐겁게 할 수 있게 만들어 줄 것입니다.

당장의 현실은 그렇지 않게 느껴지더라도 생각이 바뀌면 관점이 바뀌고 관점은 태도를 바꿀 수 있습니다. 내 태도는 주위에 반드시 영향을 주게 됩니다.

이 글이 개발자가 협업을 잘해야하는 이유에 대한 대답과 앞으로의 함께 문제해결사가 되어가는 과정에 도움이 되기를 바랍니다.

감사합니다.