함께 성장하는 개발 문화: 좋은 개발 문화란 무엇일까?

최근에 이직을 했다. 취업 후 지금껏 계속 같은 동료들과 함께 일을 했었는데, 새로운 동료들을 만나고 일을 함께 한다는게 아직까지는 어색하다. 기존에 함께 했던 동료들과는 당연하게 생각했던 부분들이 여기에서는 당연하지 않은 부분들도 많이 있다. 그것도 그럴 것이 개발, 테스트, 배포, 모니터링, 커뮤니케이션 등 많은 부분이 다르다. 이직한지 얼마 되지 않아 다 알 수는 없지만 지금까지 느낀 것은 주변 업무 환경, 동료 등이 바뀌니 그 분위기, 문화도 확실히 다르다는 점이었다. 그러면서 생각이 든 것이, 그럼 좋은 문화는 무엇일까? 좋은 문화라는 것은 있는걸까? 좀 더 나은 업무 환경, 개발 문화를 만들기 위해서는 어떤 노력을 해야 할까? 등 조직 문화에 대해 고민을 하게 되었고, 짧게 나마 이에 대한 생각을 정리하고자 한다.

WHY. 굳이 개발자가 조직 문화까지 관심을 가져야 할까?

조직 문화가 무엇일까? 왜 중요할까? 등 조직 문화에 대해 찾아보기 시작하면서 들었던 의문이 두 가지가 있다.

• 1) 조직 문화는 컬쳐팀이나 인사팀에서 관심을 가지고 주도해야 하는게 아닐까? 개발자가 관심을 가지는 것이 맞는걸까?
• 2) 개발자니까 "개발" 그 자체, 기술적인 부분을 잘하는 것에 집중하는 것이 맞지 않을까?

위 두 가지 의문에 대해서 알아보도록 하자.

조직 문화는 컬쳐팀에서 담당해야 한다?

화난 원숭이 실험을 아는가? "시대를 앞서는 미래경영전략, Competing For the Future, 1994" 라는 책에서 인용된 내용은데, 조직이 커질 수록 창의성은 고갈되고, 소통은 단절된다 라는 현상을 비유한 실험이다. (실제로 이 실험을 했는지 안했는지는 모름) 이 실험의 내용은 다음과 같다.

5마리의 원숭이가 한 방에 있다. 그리고 방 중앙 천장에는 바나나가 하나 매달려있고, 그 바나나를 가지러 갈 수 있도록 사다리가 존재한다. 한 마리의 원숭이가 사다리를 타고 바나나에 손을 뻗는 순간, 천장에서는 찬물이 나온다. 깜짝 놀란 원숭이는 바닥으로 떨어져 버리고, 나머지 원숭이들도 바나나를 가지러 가보려고 하지만 매번 실패하게 된다.

실험자들은 5마리의 원숭이 중 한 마리를 새로운 원숭이로 교체한다. 신입 원숭이는 바나나를 보고 사다리를 타고 올라가려고 하는 순간, 기존에 있던 원숭이들이 어차피 올라가도 바나나는 가질 수 없고 찬물만 나온다며 화를 낸다. 

그 후, 모든 원숭이가 교체되고 찬물이 나오는 샤워기가 제거된 이후에도 어느 누구도 감히 사다리를 오르려고 하지 않는다. 어느새 방 한가운데 바나나는 만져서는 안되는 금기의 대상이 되어 버린다.

화난 원숭이 실험, https://bit.ly/44uAjNA

화난 원숭이 실험에서처럼, 그 어느 누구도 바나나를 금기의 대상으로 만들지 않았다. 금기의 대상으로 만든 것은 다섯마리의 원숭이다. (물론 찬물이 나오는 그 주변 환경이 없었더라면 바나나는 금기의 대상이 안되지 않았을까?) 

우리는 아침 9시에 출근해서 6시에 퇴근할 때까지 주변 동료들과 협업하며 지내게 되는데, 필연적으로 영향을 서로가 서로에게 끼칠 수 밖에 없다. 내가 만들어내는 제품과 서비스는 내가 어떤 생각을 하고 만들었는지로부터 나오게 되며, 내 생각은 내 생각도 있지만 주변 동료들의 생각에도 영향을 받게 된다. 다시, 내가 만들어내는 제품은 우리 팀의 결과물인것이다.

"앞서가는 조직은 왜 관계에 충실한가" 라는 책을 보면 이런 말도 나온다.

혼자 모든걸 다 할 수는 없다.
우리는 혼자서 모든 걸 다 하도록 회로화되어 있지 않고, 세상도 그런 식으로 동작하지 않는다.
우리는 모두 서로 연결되어 있다.

따라서, 조직 문화라는 것은 결국 컬쳐팀, 인사팀에서 원하는 방향으로 설정은 할 수 있겠지만 결국 그 문화를 만들어가는 주체는 우리 모두이다. 조직에 화난 원숭이가 생겨나지 않도록 주변 동료들에게 좋은 영향을 주려고 하고, 나 자신도 기존 관성에 젖어버리는 화난 원숭이가 되지 않도록 노력해야 한다.

개발자니까 "개발" 자체에 집중해야 한다?

배달의 민족 CEO 로 계시는 김범준 님이 나온 영상을 보면 이런 말이 나온다.

개발자라고 한다면 스스로를 코딩하는 사람으로 정의하지 않았으면 좋겠다.
결국은 우리에게 주어진 비즈니스 문제를 해결하는 사람으로 생각하는 것이 좋겠다.
때로는 문제를 해결하는 가장 좋은 방법이 정책을 바꾸고 프로그래밍을 안 하는 것일 수도 있다.

개발자는 주어진 목표, 비즈니스 문제를 해결하는 사람으로 정의한다면 우리가 집중해야 한다고 생각하는 프로그래밍 스킬, 개발 기술은 그 목적을 달성하기 위한 수단일 뿐이다. 그것이 전부는 아니다. 프로그래밍 스킬 뿐만 아니라, 업무에 대한 태도, 커뮤니케이션 방법 등 소프트 스킬적인 부분도 목적을 달성하기 위한 수단이 될 수 있다. 따라서 이런 부분을 아우르는 조직 문화를 잘 만들어가는 것도 중요하다.

WHAT. 개발 문화는 무엇일까?

그럼 개발 문화는 뭘까? 한마디로 정의할 수는 있을까? 힌트를 좀 얻어보고자 블라인드에 찾아보았다.

블라인드에서 검색한 "개발 문화"

위 사진을 비롯하여 대부분의 글에서는 좋은 개발 문화를 가지고 있는 조직이란 TDD, 코드 리뷰, 개발 스터디, 수평적인 분위기 등이 있는 조직을 의미한다고 나왔다. 결국 개발 문화라는 것을 정의한다면 "개발자들이 어떻게 일 하는가?" 로 정의할 수 있고, 함께 더 나은 무언가를 만들기 위해 소통하고 성장하고 공유하는 일련의 생태계 혹은 방향성이라고 생각할 수도 있다. (https://bit.ly/44ARTj8)

나는 이 정의에서 "소통", "성장", "공유"가 중요하다고 생각되어 이 3단어에 집중하여 좋은 개발 문화를 만들 수 있는 방법을 찾아보았다.

HOW. 어떤 방법들이 있을까?

소통, 성장, 공유를 잘 하기 위해서 다양한 방법들이 있겠지만 나는 기술 블로그 작성, 코드 리뷰, 문서화를 통해 좋은 개발 문화를 만들어 갈 수 있다고 생각한다.

소통. 기술 블로그 작성

IT 회사라고 한다면 기술 블로그는 하나씩 있다. 글을 읽다보면 회사가 어떤 업무에 집중을 하고 있는지, 어떤 분위기인지 얼추 파악을 할 수 있다. 예를 들어, 네이버의 경우에는 논문 형식으로 기술 블로그를 작성하는 편인데 컴퓨터 공학을 깊은 수준으로 연구하는 개발 문화를 보여준다. 반면 배달의 민족 기술 블로그의 경우에는 좀 더 편안하고 자유로운 형식의 기술 블로그로 자기 지식을 잘 나누는 개발 문화를 보여 준다. 이렇듯, 기술 블로그를 통해 어떤 분위기인지, 어떤 것에 초점을 맞추고 있는지 알 수 있다. (https://dbr.donga.com/article/view/1203/article_no/10412/ac/magazine)

성장. 코드 리뷰

흔히 코드리뷰라고 한다면 리뷰를 요청하는 사람은 코드 변경사항에 대한 구체적인 설명을 적고 (배경, 작업 내역, 테스트 방법 등) 리뷰어는 변경 사항에 대한 피드백을 해주는 과정이라 생각한다. 하지만 코드리뷰는 좀 더 풍부한 성장을 목표로 할 수 있다. 먼저, 조직 관점에서는 코드리뷰를 통해 제품의 퀄리티를 높일 수 있다. 리뷰가 없는 것보다는 한번이라도 하는게 버그를 하나라도 잡을 수 있을 것이다. 또한, 팀 관점에서는 구성원간 기술적인, 도메인적인 지식 수준 격차를 줄 일수 있다. 만약 내가 어떤 기술에 대해 잘 알고 있으면 코드리뷰를 통해 공유함으로써 다른 동료들의 지식 수준을 끌어올릴 수 있다. 

버스팩터 (bus factor) 라는 지수가 있는데, 팀원이 버스에 치여 죽거나 크게 다쳤을 때 프로젝트가 "망할" 가능성에 대한 지수이다. 지수가 낮으면 프로젝트가 특정인에게 많이 몰려있다는 의미이고, 정보가 제대로 공유되지 않은 상황을 의미한다. 따라서, 코드리뷰를 통해서 이 지수를 높일 수 있다.

공유. 문서화

문서화를 하는 것은 되게 당연하고 무조건적으로 해야 한다고 다들 생각하겠지만 정말 "잘" 하기 어려운 부분이라고 생각한다. 문서화는 커뮤니케이션 비용 절감의 도구로 충분히 활용할 수 있는데, 코드 작업을 하기 이전에 서로의 생각을 맞춰감으로써 추후 발생할 수 있는 생각의 차이를 많이 줄일 수 있다. 초반에 1도, 2도가 다른 것은 크게 느껴지지 않을 수 있지만 그 차이가 나중에 멀리가서는 10도, 20도처럼 더 크게 느껴질 수 있다. 따라서 처음에 문서화를 통해 서로의 "생각 각도"를 최대한 줄이는 것이 중요하다. 뱅크 샐러드에서는 "테크 스펙" 이라는 문서를 통해 일을 한다고 한다. 코드 전에 문서로 먼저 일하는 개발 문화로 요약, 배경, 목표, 계획, 일정 등을 기술해두고 커뮤니케이션한다고 한다. (https://blog.banksalad.com/tech/we-work-by-tech-spec/)

마무리하며

좋은 개발 문화는 개발자가 소통, 성장, 공유를 잘 하기 위한 생태계를 의미하는 것이고 그 방법들로는 기술 블로그 작성, 코드 리뷰, 문서화 등의 방법이 있었다. 하지만 제일 중요한 것은 이런 방법들을 맹목적으로 수행한다고만 해서 좋은 개발 문화를 정착시킬 수는 절대 없다. 결국 개발 문화는 각 구성원 간 관계에서 만들어지는 것이기 때문에 서로에 대한 신뢰 없이 "문화"라는 것은 절대 만들어나갈 수 없다.