일하면서 행복하기- '소프트웨어 엔지니어링 문화'
현재 필자는 전통적인 기업(제조업,유통업)에서 업무용 프로그램을 개발 운영하는 SW개발 회사에서 관리자로 일하고 있습니다. 최근 사업 환경이 급변하면서 글로벌, SNS 활용, Mobile 환경, Online trade와 OMNI 채널 확장 등 IT활용 능력 자체가 곧 기업 경쟁력이 되었고, IT조직도 이러한 변화에 맞춰 유연하게 대응해야 합니다. 그러나 우리 회사는 이런 필요에 한참 못미치는 실정이라 전향적인 변화가 필요했습니다.
이제 겨우 변화를 체험하게 되었지만 최근 3년간 기존 조직을 새로운 IT요구에 맞게 바꿔보자고 변화를 시도하면서 겪은 경험을 조금 공유하려고 합니다. 글을 통해 변화를 시작하시는 분들께 자그마한 용기라도 드렸으면 좋겠습니다.
솔루션 도입과 외주개발에만 의존해서는 '답이 없다'
기업 SI업체에서 근무하는 직장인들 하는 얘기를 들다보면 '답이 없다'는 생각이 많이 든다.
하루 종일 회의 쫓아 다니다 보면 퇴근시간이 다 됩니다. 어떤 때는 팀원 얼굴 한번 못볼 때도 있습니다. 나름 용기내서 해보려고 제안을 해보지만, 시간과 인원을 할당받을 수 없어서 야근으로 하고 싶은 일을 했어요. 그런데 만들어도 팔 수 없더라구요. 운영할 인원도 할당받을 수 없어서. 결국은 외주가 만들고 외주가 운영해줄 수 있는 것만 개발할 수 밖에 없어요. 어쨋든 팀원들이 성과를 인정받을 것은 있어야 하니까.
이런 조직에서 IT 시스템을 운영하는 방식은
- IT예산에 맞춰 현업 요구사항을 솔루션 도입으로 해결하려고 한다
- 개발팀과 운영팀을 분리하여 각각 따로 운용하기 때문에 직원들은 성과 평가 받기 좋은 개발 프로젝트 업무를 선호한다(집중할 수 있고 배울 기회도 되고 성과 평가 잘 받을 수 있다)
- 프로젝트할 때도 성과 크기에 민감하고 책임 소재가 애매한 일을 기피하며, 단기 성과 위주 단발성 프로젝트를 주로 한다.
- 외주업체를 활용하여 개발 운영하기 때문에 직접하는 실무는 적고 미팅이 많다
결국 현업에서 느끼게 되는 IT조직에 대한 인식은
- 의사결정과 실행이 느리고(1-2주 해보고 어떻게 할지 결정하고 싶은데, 꿈도 못꿔!)
- 요구사항 해결에 주도적이지 않으면서 제안서에는 일정과 금액을 부풀려서 가져온다(당연히 30%깍아야지! 악순환)
- 개발 완료되어 사용하기 까지 시간이 많이 걸리는데( 3개월 그것도 짦은 것 ), 더 문제는 오픈하고 새로 개발한다.(대안이 없지)
- 대안도 없어서 할 수 없이 기존에 해오던대로 해야 한다.(불공정 독점이야!)
우리 회사도 이와 비슷했습니다. 더 심각한 것이 있는데, 이런 회사 문화가 개발자로부터 제일 중요한 개발 능력을 빼앗아 가는지도 몰랐다는 것입니다. 4년전까지는.
고통받는 개발자를 구출해서 개발 능력을 다시 살려내자
4년전 겨울 다행히도(?) '개발자의 고통'을 직접 제 귀로 듣게 되었습니다. 개발 리더 한 명이 '우리 회사는 개발회사가 아니다' 라고 말했습니다. 그것도 경영계획하는 자리에서. 그 개발리더(관리자?)가 한 말의 뜻은 '개발자로 인정받으며 승진했다. 그런데 승진하면 관리를 하라고' 하기 때문에 개발을 계속할 수 없게 되고 점점 기술력이 떨어지니 밑에 직원 말에 의존하여 관리만 하게 되고 결국 다른데도 가기 어려워진다는 뜻이었다. 아차! 내가 의도한 것이 이것이었단 말인가?(개챙피! 자책 ㅠㅠ)
이 사건(?)이 계기가 되어 망하더라도 우리 스스로 '개발하는 회사'로 바꿔는 보자고 마음 먹었다. 어차피 유능한 개발자를 계속 잃게 되는 구조를 바꿔야 하고, 못바꿔도 악순환으로 망할거니까!
노력에 비해 실효없이 2년이 흘렀습니다. 그리고 나서 '진짜 개발을 해본 실력자'들과 함께 다시 시작했습니다. 변화는 이때 시작되었습니다. 오늘도 계속 변하고 있고, 우리 스스로 어떻게 변화해 갈지 모릅니다. 그러나 '개발하는 회사'가 되어 가는 것은 느껴집니다. 이제는 함께 일하는 거래처도 우리가 변화했다는 것을 느끼기 시작했습니다. 리더의 일부지만.
조직이 변화한다는 것은 문화가 바뀐다는 것이다
변화한 것이 있다고 느껴지는 현재의 일하는 방식은 이전과 많이 다릅니다.
- 개발자는 독립적인 기능을 수행하는 Micro Service를 개발하고 지속적으로 개선합니다. Micro Service 여러개가 엮여서 하나의 Product Service가 만들어집니다.(Service 구축에 특정 솔루션이 알맞다고 판단될 때는 포함하여 개발한다)
- Service 개발에 필요한 기술 세트, 설계, 아키텍처, 인터페이스 규격 등을 팀에서 스스로 정합니다.(개발과 운영을 나누어서 생각하지 않는다. 운영하는 것이 서비스를 더 가치있게 하기 때문에)
- 개발된 code는 공개되어 동료들이 검토해 줍니다. 중요한 code는 senior가 직접 검토해 줍니다.(이웃 개발자가 살아야 내 서비스도 산다. 심각해!)
- Product Service운영자는 고객 욕구와 개발팀 사이에서 소통 조율하며 서비스 품질을 책임집니다.(구성원간에 필요할 때 소통하고, Service도 소통기능을 구현한다)
요즘 우리와 같이 협업을 경험한 현장의 인식은
- 피드백이 빠르고 서비스 비용이 싸다.
- 조금씩 만들어 써보고 범위나 기능을 늘려갈 수 있어서 부담이 없다.
- 운영에 필요한 데이터에 직접 접근할 수 있고, 필요시 기능도 직접 만들어 쓸 수 있다. 물론 잘된 것을 보고 베껴도 되고. ㅋㅋ
- 사업효과를 확인하면서 요구할 수 있다. 요즘은 희망적이다. ㅎㅎ
소프트웨어 엔지니어링 문화
필자는 이것을 가능하게 한 변화된 일하는 방식을 '소프트웨어 엔지니어링 문화'라고 부릅니다.
- 구성원들은 각자가 주체이고 주도적으로 일하고
- 서비스 운영에 필요하다면 가능한 모든 영역에서 책임지고 구축 개발하며( 모르면 물어보면 되고 찾기만 하면 해보면 된다 )
- 공개하고 검토받으면서 본인의 성장을 맛보고 이웃 개발자의 성장을 도와서 같이 살아간다
- 같이, 원하는 모양으로, 할 수 있는 것을 계속 하면서, 성장 발전한다
'소프트웨어 엔지니어링 문화'. 글자 그대로만 보면 무슨 뜻인지 바로 알아채기 힘들 수 있습니다. '서울 광화문 문화'처럼 선명하지도 않고, '동양 문화'처럼 학술적이지도 않습니다. '문화'[1]를 사람들이 어울려 살면서 드러나는 공동체의 모습이라고 생각하고 지그시 눈감고 느껴보면 이렇게 말하는 것이 들립니다.
나는 지금 이 서비스를 잘 만들고 싶다. 많은 사람들이 쓸 수 있게 해서 누가 무엇을 하려고 내 서비스를 쓰는지도 알고 싶다. ... 사람들이 내 서비스를 써서 원하는 것을 얻고 행복해지면 좋겠다. ... 그래서 계속 업그레이드 중이다.ㅎㅎ
행복은 같이 누릴 이웃이 있을 때 의미 있으니까요.
[1] 문화라는 용어는 라틴어의 'cultura'에서 파생된 'culture'를 번역한 말로 본래의 뜻은 '경작(耕作)'이나 '재배(栽培)'였는데, 나중에 교양, 예술 등의 뜻을 가지게 되었다. 다만 좁은 의미의 문화와 넓은 의미의 문화는 조금 다른데, 좁은 의미로는 교양과 발전된 의식 등을 의미하는 한편 넓은 의미로는 생활 양식 전반을 지칭하는 말이다.(원본:나무위키)