Last updated on 1월 25th, 2021 at 04:56 오후
필자가 얼마전에 기고한 글 “프로그래밍이 좋아서 전공을 포기하겠다고?”에서 소프트웨어 자체만으로는 고객에게 가치를 전달하기 어렵고 비즈니스 도메인 지식이 결합되어야 하기 때문에 과거에 어떤 공부를 했더라도 프로그래밍을 하는데 있어 큰 도움이 될 수 있다고 말했다.
그런데 지난 번 글에서는“데이터 분석”에 대한 이야기를 펼치다보니 상대적으로 성격이 다른 “소프트웨어 개발” 분야에 대한 이야기가 부족했었다. 그래서 이번 글에서는 소프트웨어 개발에 대해서, 그 중에서도 비전공자가 소프트웨어 개발에 있어 꼭 필요한 이유에 대해 설명해보고자 한다.
소프트웨어 개발 프로젝트에 투입되는 다양한 역할과 책임
주변을 가만히 살펴보면 매우 다양한 소프트웨어들이 우리의 삶에 직/간접적으로 영향을 미치고 있는 것을 알 수 있다. 지금 여러분의 주머니에 들어가 있는 스마트폰만 하더라도 하드웨어 제어를 위한 펌웨어, 사용자의 쉬운 조작을 돕기위한 운영체제(iOS, 안드로이드), 소셜 네트워크 앱, 게임 등 모든 것이 소프트웨어의 집합체이다. 지하철을 타기 위해 개찰구를 통과할 때나 주민등록등본을 출력하기 위해 접속한 웹 사이트, 연말 정산을 위해 접속하는 연말 정산 간소화 시스템 등, 다양한 형태의 소프트웨어가 있고 이들은 조금씩 다른 형태의 프로젝트를 통해 만들어진다. 회사의 규모나 운영 방식, 조직의 성향이나 팀의 구성에 따라 차이는 있지만 보통 큰 규모의 엔터프라이즈급 프로젝트에서는 아래와 같은 역할들이 필요하다.
- 프로젝트 관리자 (PM, Project Manager) : 전체 프로젝트를 책임지는 총괄 관리자로, 대부분의 의사결정을 주도하며 일정, 예산, 리스크 등을 관리하고 고객과의 커뮤니케이션의 최전방에 있는 역할이다. 프로젝트를 기한내에 완벽하게 끝내기 위해 이용 가능한 자원/비용을 산정하고, 필요한 인적, 물적 자원을 확보하며 작업 할당 및 진척 관리를 한다.
- 프로젝트 관리 조직 (PMO) : 프로젝트 규모가 큰 경우, 프로젝트 관리자 혼자서 모든 것을 할 수가 없다. 프로젝트 관리자의 일을 돕는 조직을 뜻하며 어떤 경우에는 외부 컨설팅 업체에게 이 역할을 위임하는 경우도 있다.
- 프로젝트 리더 (PL, Project Leader) : 프로젝트 관리자의 바로 아래에 위치하며, 본인이 담당하는 영역의 소프트웨어 개발을 책임진다. 팀을 이끌어가는 실질적인 리더이며, 프로젝트 관리자의 방향성에 맞춰서 개발 팀이 일을 완수할 수 있도록 프로젝트를 이끈다.
- 아키텍트 (Architect) : 어느 정도 규모가 큰 프로젝트에는 아키텍트들이 투입된다. 아키텍트도 경우에 따라 테크니컬 아키텍트, 소프트웨어 아키텍트, 데이터 아키텍트 등으로 나눠지기도 하는데, 필자의 전 직장인 경우가 그랬다. 아키텍트들은 프로젝트 초반에 투입되어 개발을 하기 위한 큰 그림을 그리고 개발을 할 수 있는 준비를 한 뒤, 실제 개발이 진행될때 개발자들에게 가이드를 주고 기술 지원을 해주거나 트러블 슈팅을 돕는 역할을 한다.
- 업무 분석가 (BA, Business Analyst) : 이 역할은 업무의 요구사항을 명확하게 분석하는 역할로 업무 도메인 영역의 지식이 많을수록 정확한 업무 수행이 가능하다. 해외에서는 반드시 존재하는 역할이나, 국내에서는 PL이 대신하거나, 설계자와 같이 불리기도 한다.
- UI/UX 디자이너 (Designer) : 고객의 요구사항을 이해하여 화면을 그리는 주체이다. 여기서 화면은 개발하는 것이 아니라, 포토샵이나 일러스트레이터와 같은 도구로 그림을 그린다. 여기서 확정된 화면 기안은 개발자에게 전달된다.
- UI/UX 퍼블리셔 (Publisher) : 디자이너가 그린 그림을 개발을 할 수 있게 퍼블리싱(Publishing)하는 역할이다. 그림을 소스 코드에 반영하기 위해 필요한 스타일 가이드를 작성하며, 직접 화면에 옷을 입히는 작업을 하기도 한다.
- 개발자 : 개발자는 경우에 따라 화면을 그리는 프론트엔드 개발자와 눈에 보이지 않는 로직을 개발하는 백엔드 개발자로 나눠지거나, 둘 다 함께 하는 풀스택 개발자로 분류된다. 이들은 화면 혹은 설계 사양서와 개발 가이드를 전달받아 소스 코드를 작성하는 주체이다. 일반적으로 이 인력이 프로젝트에 가장 많다.
- 테스터 (Tester) : 개발자는 본인이 개발한 소스 코드의 단위 테스트에 대한 책임을 지지만, 전체 개발자가 개발한 소프트웨어를 테스트하는 것은 개발자의 힘으로 부족하다. 이때, 테스트만 전담하는 테스터들이 투입된다. 통합 테스트를 하기위한 시나리오를 정의하고, 테스트를 직접 수행한 뒤 테스트 결과를 알려준다. 버그를 찾아주는 사람들인 셈이다.
- 품질 관리 담당자 (QAO, Quality Assurance Officer) : 품질 관리 담당자는 소프트웨어 개발을 하기 위한 단계 단계마다 품질을 보장하기 위한 활동들을 주도한다. 주요 일정(마일스톤)에 따라 예상되는 산출물들을 챙기고 직접 작성하기도 한다. 여기서 산출물은 요구사항 명세서, 화면 설계서, 테스트 시나리오와 같은 문서들이 대부분이다.
물론, 이렇게 세세하게 역할을 나눌수 없는 프로젝트도 많다. 이런 경우는 여러 개의 역할을 함께 수행하는 경우도 있고 처음부터 역할을 넓게 가져가는 경우도 많다. 하지만 위에 언급된 역할들은 소프트웨어 개발을 하기 위해 누군가는 반드시 해야하는 것들이다.
프로그래밍이 필요한 역할?
자, 그렇다면 위 역할 중에 프로그래밍을 해야하는 역할은 무엇일까? 물론 가장 많은 비중을 차지하고 있는 개발자들은 당연히 프로그래밍을 해야 한다. 하지만 다른 역할들은 어떨까?
위 역할 중 “아키텍트”는 개발자에게 가이드를 해야하기 때문에 어느 정도 프로그래밍을 해야 한다. (물론 그림만 그리는 사람도 있긴 하다.) UI/UX 퍼블리셔 같은 경우도 화면의 스타일을 입히기 위한 프로그래밍은 직접 하는 편이다. 이외에 다른 역할들은 대부분 프로그래밍이 주 업무가 아니다. 흥미롭지 않은가? “소프트웨어 개발” 이라는 프로젝트에 투입된 사람들이 프로그래밍을 전혀 하지 않기도 한다니 말이다. 하지만 이런 의문이 들 수도 있다. 아무리 그래도 소프트웨어 개발 프로젝트인데 참여하는 사람들은 모두 일정 수준 이상의 프로그래밍 실력은 갖추어야 하지 않을까?
필자는 그렇게 생각하지 않는다. 물론 프로그래밍에 대한 깊은 이해가 도움이 될수도 있겠지만, 컴퓨터를 전공해야 할 정도로 깊은 지식을 가질 필요까지는 없다. “업무 분석가”의 역할을 보자. 모든 프로젝트의 누군가는 업무를 분석하여 프로그래밍을 할 수 있게 비즈니스 요구사항을 정리하는 책임이 있다. 만약, 이 프로젝트가 은행 시스템 전체를 새롭게 리뉴얼하는 차세대 프로젝트라고 해보자. 이 프로젝트에서 “업무 분석가” 역할을 “컴퓨터 전공자”가 잘 소화할 수 있을까? 물론, 컴퓨터 전공을 한 개발자가 오랜 시간의 은행 근무를 통해 도메인 지식을 잘 쌓아왔다면 가능할 수도 있다. 하지만 은행 업무와 관련이 깊은 전공을 이수하고 은행 업무를 ‘직접’ 하는 사람만큼 이해할수는 없을 것이다. 게다가 어떤 경우에는 지나치게 많은 소프트웨어 개발 지식으로 인해 정작 중요한 비즈니스 요구사항에 집중하지 못하는 경우도 발생한다. 가령, 본인 판단에 구현이 너무 어렵기 때문에 필요한 기능을 구현하지 않는 경우나, 구체적인 요구사항이 없음에도 불구하고 그저 한번 새로운 기술을 적용하려고 하는 경우를 들 수 있다.
위에서 언급하지는 않았지만 새로운 프로젝트를 기획하는 “기획자”의 경우는 어떨까? 필자가 소속되어있는 부서에서는 전기를 생산하는 발전소의 안정적이고 효율적인 운영을 돕기 위한 디지털 솔루션을 기획하여 발전사 고객에게 서비스를 제공하고 있다. 어떤 솔루션이 발전소에 도움이 될 지를 기획하는 사람에게 요구되는 기술은 무엇일까? 솔루션을 개발할 때 사용하는 프로그래밍 기술보다는 발전소의 생태계를 이해하고 전력 생산을 하는 보일러, 터빈, 발전기와 같은 주요 설비에 대한 깊은 지식이 요구되며, 발전소 운영상의 이슈에 대한 이해가 더 중요할 것이다. 모든 소프트웨어 프로젝트는 이러한 기획이 반드시 선행되어야 한다. 필자의 경험상, 소프트웨어 개발 전문가에게 이런 기획 업무를 맡기면 무척 힘들어할 가능성이 높다.
조금 다른 시각으로도 보자. 프로젝트 관리자나 프로젝트 리더에게 가장 중요한 역량 중 하나는 리더십일 것이다. 큰 프로젝트일수록 이들의 리더십에 따라서 프로젝트가 산으로 갈수도 있고, 성공적으로 끝날수도 있을 것이다. 이러한 리더십을 “컴퓨터 전공”을 통해서 배울수는 없다. 결국 소프트웨어 개발을 위한 사람들이 모이지만, 모두가 꼭 소프트웨어 개발 기술을 수준 높게 알 필요는 없다는 것이다. 소프트웨어 개발에도 다양한 측면이 있고, 측면마다 요구되는 능력이 다르다. 이것이 프로그래밍 비전공자가 프로그래밍 분야에 진입할 수 있는, 아니 꼭 필요한 이유이다.
그리고 프로젝트에는 많은 사람들이 함께 모여서 일을 한다. 프로그래밍을 굉장히 잘하는 사람이라도 혼자 책상앞에 앉아서 묵묵히 코딩만 하는 사람이 대부분이라면 이 프로젝트는 성공할 수 있을까? 학교가 아닌 사회에서 수행되는 소프트웨어 개발은 혼자서 할 수 있는 규모가 아니다. 그리고 제대로 된 소프트웨어 제품을 낭비 없이 짧은 기간내에 개발을 하기 위해서는 프로젝트 구성원간의 활발하고 투명한 의사소통은 반드시 필요한 것이다. 이는 구성원간의 업무 방식을 점진적으로 개선하는 데 기여하며, 의사소통 비용을 최소화하고 올바른 제품을 개발하는 데 기여한다. (여기서 의사소통 비용은 구성원 간에 의사 전달을 하는 시간 및 노력을 의미한다. 가령, 의사소통 비용이 크다라는 것은 일을 하는 사람들이 해야할 일에 대해서 서로 다르게 이해하고 있거나, 작업 지시 내용이 사람을 거치고 전달되어서 왜곡이 심하게 되는 경우 등으로 볼 수 있겠다.)
그렇기 때문에 소프트웨어 개발을 하기 위해서 “구성원 간의 이해”도 굉장히 중요하며, 올바른 제품을 개발하기 위해 사용자에 대한 깊은 이해도 반드시 필요하다. 그리고 소스 코드를 작성하는 개발자는 로봇이 아닌 사람이다. 결국, 사람이 사람을 이해해야 하는 일이라는 것이다.
공감을 통한 의사소통이 가장 중요하다.
사람을 잘 이해하기 위해서는 그 사람의 감정을 이해하고 공감할 줄 알아야 한다. “소비자들이 가치 있게 평가하고 시장의 기회를 이용할 수 있으며 기술적으로 가능한 비즈니스 전략에 대한 요구를 충족시키기 위하여 디자이너의 감수성과 작업방식을 이용하는 사고 방식”으로 근래에 잘 알려진 “디자인 씽킹(Design Thinking)”의 5 단계 중 첫 단계도 바로 “공감”이다.
출처 : https://www.slideshare.net/hyojung.jung/prologue02-60081774
“공감”을 하기위해서는 상대방의 의견을 경청하고, 본인의 의견을 상대방에게 오해 없이 전달하는 능력이 가장 중요하다. 말은 쉽지만 생각보다 어려운 일이다. 특히, 고집이 센 개발자들간의 의견 충돌이나, 고객과 업무 범위를 재조정하기 위한 업무 회의, 관리자와 개발자 간의 업무 할당 및 진척 사항 확인을 위한 대화는 언제나 쉽지 않은 일이다. 하지만 반드시 필요한 것들이다. 이러한 의사소통 없이는 프로젝트가 진행이 될 수 없고, 이 비용이 높으면 높을수록 프로젝트의 진행은 고통스러울 것이며 프로젝트 결과에도 좋지 않은 영향을 끼친다.
현업에서 일을 하다 보면 프로젝트에서 이런 의사소통 능력이 돋보이는 분들이 꼭 존재한다. 이 분들은 상대방의 이야기를 끝까지 듣고 상대방의 의도를 정확하게 파악한 뒤, 교통 정리를 하거나 다음 단계로 나가기 위한 합의된 결정을 이끌어내는 중요한 역할을 한다. 재미있는 사실은 이런 분들 중에는 소스 코딩을 하는 개발자가 있는 경우가 많지 않다. 물론 개발자의 주 업무가 명확하게 정의된 요구사항을 구현하는 것이기 때문에 다른 역할에 비해서 사람과 대화할 시간이 적을수도 있겠지만, 현재 많은 회사에서 찾는 개발자들에게 요구하는 역량에는 “원활한 의사소통 능력”이 항상 빠지지 않고 있다. 그만큼 사람간의 공감을 바탕으로 한 의사소통 능력은 어느 위치에서나 반드시 필요한 역량이다.
필자의 동료중에 의사소통을 굉장히 잘하는 친구가 있다. 이 친구는 워낙 뛰어난 언변과 경청하는 습관 덕분에 팀내 사람들과 좋은 관계를 맺고 있으며, 소프트웨어 개발 프로젝트의 리더로서도 훌륭하게 업무를 수행하고 있다. 이 친구의 전 직장은 대형 SI 업체였고, 학부시절 전공은 “경영학”이었다. 앞 글에서도 잠시 언급했지만, 필자가 신입사원 시절 사수였던 선배의 전공은 “철학”이었다. 그 당시 회사를 다니면서 “소프트웨어 공학” 석사를 파트타임 형식으로 공부한 것이 다였다. 절대 프로그래밍 지식이 높다고는 할 수 없는 것이다. 하지만 그 선배는 회사에서 일을 잘하기로 소문이 났다. 그 당시 부서가 전사 표준 방법론을 제정하여 현장에 확산하는 것이 주요 업무였으며, 이 분은 뛰어난 언변과 논리적인 사고 및 의사 전달을 통해 현장 인력의 반발이 많을수 있는 어려운 업무를 훌륭히 소화해 냈다. 그리고 항상 회사의 주요한 프로젝트에서 찾는 핵심 인력으로 인정을 받고 있었다. 주위를 잘 살펴보면, 컴퓨터를 전공하지 않았지만 누구나 쓰고 있는 소프트웨어 개발 과정에 깊숙이 관여하고 있는 사람들을 쉽게 접할 수 있다. 이외에도 개발자 세계에서 유명한 분들을 보면 비전공자의 비율이 굉장히 높다. 이런 분들은 보통 사람들이 한 가지씩 가지고 있는 무기를 두 개는 기본으로 장착하고 있는 거다.
마무리
지금까지 소프트웨어 개발을 하기 위해서 필요한 역할과 책임에 대해서 살펴보고, 프로젝트가 잘 진행되기 위해서 업무 도메인 지식을 잘 아는 사람들이 반드시 참여해야 하며, 구성원간의 공감을 통한 의사소통이 무척 중요하다고 하였다. 또한, 사용자에게 제대로 된 제품을 만들기위해서 사용자에 대한 공감도 중요하다고 하였다. 그리고 비전공자들이 전공자들이 갖추지 못했을 수도 있는 것들 – 업무 분석 능력, 기획 능력, 공감 능력 등-을 무기로 삼으면 소프트웨어 개발 프로젝트에서 오히려 더 큰 도움이 될 수 있다고 말했다.
“익스트림 프로그래밍”의 저자이자 JUnit이라는 자바 프로그래밍 언어의 테스트 프레임워크를 만든 켄트 벡은 다음과 같이 말했다.
“소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.”
변화는 반드시 일어나기 때문에 문제가 되는 것은 변화가 아니며, 이를 극복하지 못하고 대응하지 못 하는 우리의 무능력이 문제라는 것이다. 소프트웨어 개발은 사람들이 모여서 특정 영역의 사람들을 위해 수행하는 행위이다. 눈에 보이지 않는 것을 누군가에게 쉽게 사용할 수 있도록 만들어나가는 것이다. 이 과정속에 엄청나게 많은 변수들이 존재하며, 이 변수들로 인해 프로젝트가 성공할 수도 있고, 실패할 수도 있다. 이 수많은 변수들에 휘둘리지 않으려면, 앞서 말한 여러가지 능력들이 필요하다. 비단 프로그래밍 능력 뿐이 아니라 말이다.
p.s : “공감” 능력을 키우는 방법은 무엇이 있을까?
실은 개발자인 필자는 이 영역을 어떤 방식으로 키워나갈 수 있는지 설명하기가 쉽지 않다. 입력값에 따라 원하는 출력값을 확인해야 직성이 풀리는 개발자들에게는 더더욱 쉽지 않은 일이다. 필자 생각에는 가장 중요한 것이 “인문학적 소양”이라고 생각한다. 특히, 본인에게 잘 맞는 인문서를 찾아 읽음으로써 책을 쓴 사람의 의도를 이해하려고 노력하고, 주인공의 현재 상황을 공감하는 연습이 도움이 많이 된다. 필자는 얼마전까지만 하더라도 전공 서적이나 개발자의 조언들이 가득한 수필형 책이나 처세술과 같은 책 말고는 거의 관심이 없었다. 특히, 소설을 읽는 것은 정말로 관심이 없었다. 하지만, 근래에는 누구나 한번쯤은 읽어 봤을만한 장편 소설을 천천히 읽고 있다. 매일 밤 조금씩 읽다보니 어느새 책의 한 장면을 머리속에 그리면서 주인공의 아픔을 느낄수 있었고, 조금씩 조금씩 사회 생활에서도 긍정적인 영향을 미치고 있다고 본다. 본인이 관심을 가질만한 쉬운 소설이나 수필을 한권 골라서 읽어 보자. 그리고 “공감”해보자.
입문자부터 실무자까지, 패스트캠퍼스 프로그래밍 강의 자세히 보기 >>> [클릭]
*본 글은 패스트캠퍼스의 객원 필진으로 참여하여 작성한 글입니다.
