IT창업칼럼-6. 개발자를 찾기전에 미리 알아야 할 것
IT창업 쉽게보면 큰코 다친다
IT 프로젝트 개발 영역
IT 프로젝트를 구성하고 있는 각 개발 영역들을 구조화 해보았다.
Front-end
보통 UI 라고도 많이 부르며 사용자가 눈으로 확인할 수 있는 화면을 말한다.
그런데 왜 디자인이 아니고 개발 영역에 있는 걸까? 하는 의문이 들 수 있다.
디자인 영역에서 작업한 디자인 작업물을 개발 영역에서 전달 받아 별도의 작업도 없이
그대로 Back-end 나 Database 에 연동할 수 는 없다.
디자인은 말 그대로 눈으로 보여지는 색채, 질감 등을 표현한 버튼, 이미지, 레이아웃의 형태이다. ( jpg, png, gif 등등 )
이러한 디자인 결과물을 원하는 위치에 배치하고 링크를 연결하고
특정 상황에 따라 보여주고 감추고 하는 등의 기술적인 작업이 이루어져야 한다.
또한, 버튼 클릭의 다양한 효과나 화면 전환 애니메이션 작업도 추가될 수 있다.
이런 작업들은 디자인 툴이 아닌 코드로 작업을 하게 된다. ( html, javascript, css등 )
Front-end 의 관리 이슈가 점차적으로 커짐에 따라 angularJs, react.js, vue.js 등으로
기존보다 효율적이고 재사용성이 용이한 Front-end 기술이 등장했다.
Back-End
Back-end 와 Back-office 를 혼동하는 경우를 흔히 보게 되는데 엄연히 다른 영역이다.
업계에서는 종종 Front-end 를 "앞단, 화면단" 이라고 부르기도 하며
Back-end 는 "뒷단, 백단" 이라고 부르기도 한다.
좀 더 알맞은 명칭은 "서버 개발" 이다. (서버에서 이루어지는 개발 처리)
Back-office 는 관리자 로그인을 하고 서비스를 관리를 할 수 있는 별도의 웹페이지를 말한다.
호수를 헤엄쳐 가는 아름다운 백조 한마리가 있다고 하자.
사람이 육안으로 볼 수 있는 부분은 물 위에 떠서 유유히 움직이는 하얀 백조의 모습일 것이다.
하지만 백조가 실제로 움직일 수 있는 것은 몸체와 물에 가려 보이지 않는
바삐 움직이는 다리의 움직임 때문이다.
이 다리가 Back-end 의 역할이라고 생각하면 이해가 쉬울 것 같다.
위 그림에 있는 노란색 부분은 Front-end 에서 사용자에게 보여지거나 동작이 연결 된 부분이다.
회원가입, 로그인 폼에 정보를 입력해서 전송 버튼을 누른 후, 눈에는 보이지 않으나
입력한 내용이 올바른 형식인지를 체크하고 회원DB 와 통신을 하고
정상, 오류 등의 상태값을 Front-end 에 전달한다.
또한, 사용자의 요청 동작 연계가 없는 메인페이지에 우수판매 상품 목록을 구성하기 위해서
해당 데이터들을 Front-end 에 미리 보내줘야 한다.
참고로 개발 방식에 따라 Front-end 에서 주도적으로 요청을 먼저하는 방식도 있다. (Client Server Rendering)
이러한 데이터 통신 이외에도 파일 업로드, 외부 서비스와의 통신 (API, SOAP), 어플리케이션 보안을 포함하여
IT 프로젝트의 핵심이 되는 영역이라고 볼 수 있다.
이 밖에도 데이터베이스를 담당하는 DBA 와
서버 네트워크와 장비 관리를 담당하는 SE 직군도 존재 하는데
Front,Back end 가 나눠지기 이전부터 있었던 직군이다.
예전에는 서비스에 사용할 서버를 IDC 라는 데이터센터를 운용하는 회사를 통해 장비를
임대 또는 구매를 하였지만 아마존이나 구글에서 "클라우드 컴퓨팅 서버" 라는 환경을 출시한 이후로는
서버의 보안,관리,교체 등의 유지관리 이슈가 대폭 줄어들거나 편리해짐 으로서
Back-end 개발영역에서 서버와 데이터베이스 관리까지 가능한 상황이 되었다.
모바일 개발
보통 스토어에 출시가 되는 모바일 서비스를 모바일 Application(app) 이라고 부른다.
ios 의 경우 object c, Swift 라는 개발언어로 개발하고
android 의 경우 java, kotlin 이라는 개발언어로 개발한다.
xamarin, React-native, Flutter 라는 개발언어도 있는데 ios, android 의 버젼을 각각 다른 언어로
개발하지 않고 하나의 언어로 개발과 앱배포가 가능하다.
이 밖에도 웹브라우저에서 동작하는 모바일 web 을 만들고 속칭 "껍데기를 씌운다" 라는 작업으로
앱패키징 작업을 더해서 스토어로 출시 하는 경우도 있다.
개발직군
개발직군은 점차 다양해 지고 있다.
2000년대 초반까지는 Front-end, Back-end 영역이 세분화 되지 않았던 시절이었다.
개발자가 둘 다를 함께 담당하는 것이 당연한 때였고
간혹 디자인 영역에서 Front-end 를 부가적으로 담당하기도 했었다.
하지만 인터넷 기술들이 지속적으로 발전해 가면서 개발업무가 세분화 되기 시작했다.
우선 디바이스가 PC만 있었던 시대에서 태블릿, 모바일 등으로 다양해 졌다.
PC 웹브라우저는 다양해지고 버전별로 IT 프로젝트의 결과가 다르게 나올수도 있게 되어 세심한 관리가 필요했다.
게다가 프로젝트의 규모가 소규모가 아닌 수백, 수천만명이 이용하는 서비스도 생겨나는 규모의 변화가 오면서
더이상 개발자가 모든 영역을 전문성 있게 다루기에는 한계점에 도달하게 되었다.
그래서 Front 영역만을 전담하는 Front-end 개발영역이 생겨났다.
Back-end 의 경우 단순히 Front 의 요청사항만을 처리하고 데이터베이스와 통신하는 부분 이외에도
외부 서비스와의 통신 (API), 대용량 처리를 위한 분산 서버 네트워크, 실시간 응답 처리 등으로
개발 범위가 고도화 되었다.
IT 서비스는 1개로 보여 지지만 Back-end 인력이 다수 구성되는 상황도 많아지게 되었다.
또한, Front-end 와 Back-end 의 숙련도가 둘 다 골고루 갖춰지고 실무가 가능한 개발자를
풀스택(Full-stack) 개발자 라고 하는데 개발 영역은 조금씩 차이가 있을 수는 있다.
이를테면 Back-end 와 모바일앱 개발 까지 가능한 것을 풀스택 으로 보는 경우도 있고
Front-end 와 Back-end 만을 풀스택으로 보는 경우도 있다.
보통은 사업 초기에 이런 저런 인력을 다 구성하기가 부담스럽고
런칭하려는 서비스의 시장 평가, 고객만족도를 받아볼 수 있는 단기적인 결과물을 만들기 위해서
다소 빠른 진행을 해야 하는 경우가 많을 것이다.
이럴 때 Full-stack 개발자를 찾는 스타트업을 흔하게 볼 수 있다.
하지만, Front 와 Backend 를 함께 한다는 것은 그만큼 하나의 부분에만 집중할 수 없기 때문에
집약도가 떨어질 수 있고, 서비스가 동작은 하는데 작은 오류들이 지속적으로 발생할 수도 있다.
경력에 따라 서비스 완성도의 차이가 있을 수도 있고 그것은 고객에게 품질의 차이로 나타날 수도 있으니
적정시점에는 개발인력을 충원에 대한 판단을 반드시 해야할 필요가 있다.
개발자의 성향
희안하게 개발자들과는 대화 하는게 가끔 어려울 때가 많아요.."개발자와 대화 하는게 가끔 어렵다" 라는 타직종의 인식이 어느정도는 있는 것 같다.
개발자라는 직업을 갖고 있는 인구가 못해도 수만명 이상은 될텐데
그 분들의 성향을 내 관점으로만 어설프게 추려서 정의하는 것은 옳지 않을 것이다.
다만 나 자신을 포함하여 내가 실무에서 직접 경험한 개발자들에 대해서는 평균적인 느낌을 말해볼 수는
있을 것이고 나아가 그런 인식이 어떻게 생겼을까에 대해서는 얘기해 볼 수 있을 것 같다.
우선, 개발자라는 직업이 어떻게 일을 하는지 들여다 보자.
개발자는 컴퓨터가 이해하고 처리할 수 있는 프로그램 코드를 작성하고 코드를 실행하는 직업이다.
프로그래밍 작업이라고도 한다.
인간은 대화나 수화, 문자 등으로 소통을 하듯이
코드를 통해 컴퓨터와 소통을 하기 때문에 코드를 개발적인 "언어" 라고 할 수 있겠다.
그러한 개발언어의 종류는 한 가지가 아닌 매우 다양하게 존재한다.
영어,중국어 두가지에 모두 능통한 사람이 있는가 하면 영어,중국어,일본어 세가지에 능통까지는 아니어도
중급수준이 가능한 사람도 있고 개발언어도 이와 마찬가지이다.
하나의 서비스를 구현하면서 한 가지 개발언어만 쓸 수도 있지만
경우에 따라 두 가지 이상의 언어를 사용해야 할 때도 있다.
그리고, 언어만 다양한 것이 아니라 더 세분화된 기술적인 사항도 존재하며 도입과 배제 등을 고민한다.
이렇듯 개발자의 직무 수행과정에서 대다수의 시간은 컴퓨터 앞에서 머리를 짜내며(?) 보내게 된다.
반대로 대부분의 영업직은 사람과 소통을 많이 하는 편이다.
주변에 말을 유창하게 또는 재미있게 하는 사람이 있다면 저 사람은 영업쪽에서 일하나? 라는 생각을 첫번째로
떠올려보곤 하는데 들어 맞는 경우가 많다.
사람과 대화를 많이 할 수 밖에 없는 직업이니 대체로 화술이 좋을 수 밖에 없을 것이다.
또한 단순히 말하는 기술 뿐만 아니라 사람의 표정과 목소리를 통해 "감정" 이란 부분의 교감 능력도 높은 편이다.
컴퓨터에게 감정은 없다.
하지만, 개발자가 컴퓨터와 소통을 할 때 공학적인 피드백을 다양하게 받는다.
그것을 이해하고 분석하는 것 역시 프로그래밍의 과정이고, 공학적인 사고능력을 많이 사용하게 된다.
개발자가 다소 무미건조해 보이기도 하는 경우는 시간적으로 인생의 삼분의 일을 차지하는 "일하는 시간동안"
사람대상의 화술, 교류 보다 공학적 사고와 컴퓨터와의 접촉을 주로 하기 때문이라고 생각한다.
또한, 개발자는 신경이 날카로워져 보인다거나 예민해 보이는 경우를 종종 볼 수 있다.
IT 프로젝트는 개발자 뿐만 아니라 여러 직업군이 협력하여 만들지만
최종적으로는 개발자가 서비스 배포를 하고 향후 유지보수와 안정성 등, 관리 포인트 책임이 주어지는 편이라
작은 요소 하나라도 문제가 될 소지가 없는지 수시로 점검을 해야 한다.
이러한 과정은 고도의 집중을 요구한다.
집중의 지속 시간이 1시간, 2시간이 넘게 걸릴수도 있다.
주변에서 전화통화 하는 소리가 쉴새 없이 들린다거나 집중을 방해할 만한
소음에 지속적으로 노출되는 곳에서 집중력 높게 일할 수 있는 사람은 많지 않을 것이다.
하지만 개발자는 이럴 경우 직무 특성상 아예 일 진척이 하나도 안될 수도 있다.
직무에 상관없이 사람은 가능한한 미소를 잃지 않는 것이 중요하다고 생각한다.
이것은 개개인이 노력해야 할 부분이다.
그리고 서로 이해를 하는 폭이 클수록 오해와 분쟁은 줄어들 것이다.
다만, 나 스스로 개발자 이기 때문에 일부를 대변하자면 다음과 같다.
- 하루에도 여러차례 집중력을 요하는 작업을 하기 때문에 잘 웃지 않아 보일 수 있지만 사실 웃을줄 아는 사람이다.
- 공학적 사고와 분석을 통해 답을 해야 하는 상황에 "묻고 따지지도" 않고 답부터 달라고 한다면 "책임"질 수 없는 답변을 건넬수 도 있다.
- 꽤나 집중하고 있을 때 갑자기 던지듯 말을 걸어오면 말투부터에서 짜증날 때가 있다.
짜증내지 않아야 좋겠지만 이렇게 먼저 서두를 꺼내줬으면 참 좋겠다.
"잠깐 얘기 가능해요?", "시급한 건이라 그런데 잠깐 얘기 가능해요?", "사장님이 급히 얘기해서 그런데.."
이런 식의 먼저 의사를 물어오며,상황을 설명하며 꺼내는 대화가 비단 개발자 뿐만 아니라 동료들 사이에서도
상호 원활히 소통하는데 최소한의 도움은 될 거라고 생각한다.
세상에는 다양하고 많은 개발자가 있다.
각자의 성향이 제각기 다르기 때문에 이럴것이다 저럴것이다 미리 선입견을 갖을 필요는 없다.
사람 간에는 대화를 많이 해서 벽이나 선입견을 허물고 잘 알아가는 것이 중요하다고 생각한다.
간단한 작업..
회사에서, 프리랜서 잡에서 미팅을 하거나 작업요청 글을 볼 때 가장 많이 볼 수 있는 문장의 시작이 있다.
"간단한 게시판 수정 요청"
"간단한 쇼핑몰 개발 요청"
"카카오톡 같은 간단한 메신저 개발 요청"
그렇게 간단하면 너가 하던가여기서 "간단" 의 정의는 대체 무엇일까?
그리고 작업요청시 이 단어가 유독 많이 사용되는 이유는 무엇일까?
우선, "간단"의 정의는 제각기 다를 것이다.
작업요청 주체 입장에서는 무언가를 요청할 생각인데 작업 규모가 생각보다 크진 않으니
가급적 ok 사인을 받고 싶어하는 마음에 기능을 축소 하려는 심리에서 쓰게 되는 단어라고 생각된다.
그런데 개발이나 기획 업무 일선에서 수년이상 일을 해본 적이 없다면
실질적인 작업 난이도나 기간을 제대로 알 수가 없을 것이다.
개발자에게 복잡한 생각과 부담을 덜어 주기 위한 선한 의지에서
발현 되었다고도 볼 수 있으나 사실 굉장히 역효과를 부른다.
이 세상에 없는 최초의 서비스, 기능이 아닌 이상 이미 누군가 만들어서 세상에 내놓았기 때문에
어렵지는 않을것이라는 논리의 발상이 밑바탕에 깔려 있는것도 같다.
간혹 "뭐든 간단하게 여기는 질병"에 걸린건가 라고 생각 들 만큼 심하게 "간단" 단어를 남발하는 사람도 있다.
어떤 경우는 왠지 계산이 복잡하게 들어갈 것 같고 평소에 못본 기능(실제로 있다고 해도 본인은 못봤으니)은
난이도가 높을 것 같은 자체 판단 하에 그런 작업에는 "간단"을 안 붙이는 기준을 갖고 있기도 하다.
이 세상에 간단한 작업이란 없다.
누구에게는 1시간 짜리 작업이어야 간단할 수도 있고 누구에게는 1일짜리 작업이어야 간단하게 느낄 수도 있다.
현업 개발자 치고 "간단한 작업" 이란 단어를 안들어본 사람 없을 것이며
듣게 된 즉시, 불쾌감이나 언짢음을 느낀 사람도 많을 것이다.
성격이 까칠해서 불쾌한 것일까? 꼭 그렇지만은 않다. 추후에 상황이 뒤 바뀔수 있기 때문이다.
"네, 작업 진행하겠습니다" 라고 쿨하게 대답 한뒤에 실제 작업에 들어 간 뒤에
생각보다 난이도가 좀 있거나 기간이 오래 걸리는 경우가 생길 수 있다.
"간단한 건데 왜 그렇게 오래 걸리죠?"
"처음에 작업요청 받을 때 그럼 간단하지 않을 것다고 하셨어야죠. 별말 없길래 다 되는줄 알았죠."
" ...... "
하염없이 눈물이 흐른다그렇다. "간단" 을 여과없이 받아 들였을 때 부메랑으로 내 뒷통수를 가격당한 경험을 몇 번 한뒤에는
더 이상은 "간단" 공격에 무너지지 않으리라는 다소 예민해 보일 지도 모르는 방어적인 태도가 생기는 것이다.
"카카오톡 같은 메신저 서비스 이지만 A, B 기능은 굳이 안넣을 생각입니다. 어떻게 좀 간단해 질 수 있을까요?"
라고 묻는다면 개발자 입장에서는 간단해 질 수 있는 측면이 보이는 것에 대해서는 금방 답을 해줄 수도 있고
경우에 따라 분석의 시간을 거친 후 답을 주겠다고 할 수도 있다.
그러나 같은 질문이라도
"카카오톡 같은 메신저 서비스이지만 A,B 기능도 넣을 필요가 없는 간단한 개발 요청입니다. 어떻게 좀 작업이 가능할까요?" 라고 묻는 것은 개발자 입장에서 다르게 느껴진다.
작업을 하는 주체도 아닌 요청자가 이미 "이것은 간단한 작업" 이라는 전제를 깔고 들어오기 때문이다.
심한 경우 "그렇게 간단하다고 생각 한다면 그냥 당신이 개발하지 그래?" 라고 반문하고 싶을 때도 있다.
간단한지 아닌지에 대한 판단은 실제 개발을 담당해야 하는 쪽에서 확인도 해보고 정할 수 있다는 것을
질문 자체에 "간단"을 포함 시켜서 괜히 긁어 부스럼을 일으키지 말고 기억했으면 한다.
기술 총 책임자
울트라라이트 스타트업 이라는 책에는 다음과 같은 내용이 있다.
"기술을 맡는 공동 창업자(CTO)는 창업 전선에서 유니콘과 같은 존재다.
찾기도 어렵고 잡아두기도 어렵다.
대부분의 창업자가 어떤 CTO 를 찾아야 하는지를 모르기 때문이다."
IT 기반 스타트업에서 CTO 는 가장 중요한 자리임에 틀림 없다.
하지만, CEO 를 포함한 IT 경험이 없는 직군은 해당 분야 지식이 부족하기 때문에
말 그대로 찾기도 힘들고 인재 운용을 잘 하기도 어렵다.
나는 15년 이상 IT 부서에서 일해오며 여러 CTO 분들과 업무를 하였었다.
그 누구도 완벽했던 사람은 없었던 것 같다.
- 기술 지식과 프로젝트 관리는 우수했지만 소통과 조직 장악력은 부족 했던 분.
- 어느 하나 특출난 것도 없지만 그렇다고 부족한 것도 없는 분.
- 타고난 인품으로 팀원 관리와 대외 커뮤니케이션은 좋았지만 정작 기술지식과 판단력이 다소 아쉬웠던 분.
- 어떻게 기술 총책임자가 되었는지 의문밖에 안드는 분.
머릿속에 생각나는 분들을 위와 같이 묘사해 보았다.
종합 해보면 "보여지는 튀는 면이 있거나, 아쉬움이 있거나, 이도저도 아니거나, 이해가 안되는"
으로 요약이 된다.
그렇다면 위에서 묘사했던 것중, 단점만을 상쇄한다면 어떨까?
- 기술 지식과 프로젝트 관리 능력
- 팀원 관리와 팀내 원활한 소통, 대외 커뮤니케이션 능력
- 위기관리와 업무적 판단력
위 세가지 정도로 체크리스트가 축약될 수 있을 것 같으며 이 점을 기억하여
면접시에는 체크리스트 항목들을 감별해 볼 만한 질문들을 면접 시 질의 해야 할 것이고
채용 이후에도 체크리스트 항목에 잘 부합되고 있는지 지속적인 체크와 검토를 해야 될 것이다.
정 없어(?) 보일수는 있겠지만 회사의 미래와 방향성에 중요한 부분을 차지하고 있는 만큼
상호간에 신뢰와 검증이 되기 전까지는 필요하다고 생각된다.
다음글 > 7.앱으로 1인 기업을 다시 꿈꾸다
https://brunch.co.kr/@hidejjj/8
글로 읽는것보다 영상이 편하신 분들은 유투브 영상으로 봐주세요 ^^
https://www.youtube.com/watch?v=kuLS31LrO2A&t=85s
무료컨설팅 신청 및 대표사이트 http://itconsult.kr
지속적인 정보교류는 네이버카페에서도 가능합니다~! http://itconsult.kr/cafe
