[2편] 개발자를 춤추게 만드는 커뮤니케이션 기법.

 

저는 지금 모외국항공사 GSA를 하는 회사에서 IT개발팀장으로 있다가, 최근 여행업으로 사업범위를 넓혀보고자 고민하시는 리더덕에 신규로 설립한 여행사 개발팀장으로 소속을 옮긴 상태입니다. 외국항공사에 있는 사람들은 모두 본사와의 커뮤니케이션 때문에 모두 영어를 잘 합니다.  때문에 입사면접 시에 영어면접이 있습니다만 저는 예외로 면접하지 않고 입사한 케이스입니다.

 

경력직이기도 하지만, 시스템상으로 본사와의 커뮤니케이션을 할 일이 그닥 많지 않기 때문이기도 하기에, 전직원 중 유일하게 외국 사람과 프리토킹이 되지않는 일인이었죠.(지금은 부사수들이 생겨서 일인은 아니구요...^^;) 어느 날 항공권 프로모션을 진행하는 영업팀 사원과 운영에 관련한 이야기를 하게 됐는데, 그 친구가 제자리에 왔다가 울트라에디터를 통해 코딩 중인 화면을 보고 "팀장님, 영어 잘 못하시죠?" 라고 한마디하며..

 

 

"어휴.. 전 이런거 못해요. 이걸 어떻게 해요. 보니까 논리따지고 원리따지는 사람은 영어를 못하고, 저처럼 단순한 애들이 영어를 하더라구요. 그냥 외우거든요. 근데 이건 외워서 되는게 아니잖아요. 그쵸?"

"지금....나 칭찬하는거니...영어 못한다고 욕하는거니..??"

"에이...팀장님 그게 아니구요~. 그렇더라구요. 영어든 다른 언어든 무작정 외우기만 하면 반이상은 하거든요. 그런데 이런건 외워서 하는게 아니라 규칙이 있어서 그걸 생각하면서 해야하는 거잖아요. 아후 전 못해요 못해요. 그냥 대충 내뱉어도 되는 영어가 편해요."

이 이야길 듣고 좀 신선한 충격이었습니다.  영어로 대화할때 조금 실수한다고 문제가 되진 않지만, 개발할때는 코딩을 조금만 잘못짜도 바로 오류가 떨어지죠.  그래서 늘 정확하거나 명확하게 프로그래밍을 해야하긴 합니다만, 이 친구가 이야기하는 대로 생각해본 적은 없었기 때문이죠.  그래서 생각하게 됐죠. 프로그래밍은 어찌보면 또 하나의 제2외국어라고..

 

프로그램 언어는 또 하나의 제2 외국어!?

웹프로그래머라고 해서, ASP, PHP, JSP 모두 다 하는건 아니거든요.  각자 자기가 주 종목으로 하는 분야가 있고, 그 외의 언어는 경험이 있다면 소스 조금 읽고, 메인 모듈개발은 아니어도, 일반적인 유지보수 정도는 할 수 있는 정도??  마치 영어를 제2외국어로 능숙하게 하면서, 중국어는 약간의 의사소통이 가능한 정도로 하는 것 처럼요.

 

기획자가 준 기획안으로 프로그래밍 언어라는 제2외국어로 웹사이트를 표현해내는 일을 하는 사람이 개발자 즉 프로그래머입니다.  그러다보니, 모국어보다 프로그램언어가 더 익숙한 사람이 더러 있어서, 대화방법에 많은 오류를 내죠.기획하시는 분들은 이점을 유념하셔서, 개발자와의 대화를 통해 그들만의 생각, 그들만의 소통법을 이해해 주셔야 합니다. ^^;

 

혹시, 기획자 분들이 기획안을 그리던 도중에 과연 컨텐츠의 이런 기능 구현이 가능할까 싶으실때가 있으시죠?  혹은 현재 사이트에서 이런 데이터를 뽑아내서 새로운 컨텐츠 구성이 가능한지도 궁금하실거구요.  그럴 땐 당연히 담당 개발자에게 질문을 하셔야할텐데요.  그래서 개발자에게 이러저러한 내용을 설명하며 개발자에게 가능여부를 묻게 됩니다.  그럼 담당개발자는 아마도 이렇게 대답 할 겁니다.

"글쎄요. 일단 좀 봐야 알 것 같은데요."

"안돼요." 아마도 가장 많이 들어보신 대답일지도...

"가능은 하지만, 지금 우리 사이트 구조상으론 데이터 구조가... 전체 구성이 복잡해서 이걸 구현하려면 시간도 많이 필요한데 지금 걸려 있는 프로젝트가 있어서 그거 끝내봐야 가능할지도 잘 모르겠고... 어쩌고저쩌고.."

"아휴.. 당연히 돼죠!!  원하시는거 다 가능해요. 기획안 멋지게 그려주세요." 아주 희박한 가능성...

뭐 위의 내용은 케이스 일 뿐이고, 실제로 개발자에게 질문하면 위의 대답외에도 많은 대답을 들으셨을거라 생각합니다. 분명히 될 것 같은데 물어보면 안된다고 하고, 안될 것 같지만 일단 질문이나 해보자하고 물어보면 또 된다그러고.  분명 된다 했는데 하루나 이틀정도 지나서는 안된다고 하는 경우도 있을거에요.

 

안된다고 했다가 마찬가지로 하루나 이틀 정도 지나서 된다고 하는 경우도 있을거구요.(사실 이런 경우는 가능함을 확인했더라도 그 사실을 정직(?)하게 전달하는 개발자는 애석하게도 거의 없는 걸로 알고 있습니다.)  그 이유는 제가 생각하기에앞서 말씀드린데로, 개발언어라는건 제2외국어와 같기 때문입니다.

 

제2외국어를 모국어처럼 자유자재로 구사하기는 생각보다 쉽지 않다는 것 알고 계시죠?  그런 것처럼 머리속에 떠오른 개발구성 상으로는 될 줄 알았는데, 막상 소스를 열고 디비를 확인해보면 불가능하다는 걸 확인하게 되는거죠.  만약 개발자가 질문한 사이트와 별개의 프로젝트를 하고 있다면 해당 사이트의 구성이 머리속에 빨리 떠오르지 않기 때문에 일단 안돼요. 라고 대답하는 걸 수도 있습니다.

 

개발자와 기획자 사이에 이런 화기애애한 분위기 조성이 가능하기는 한걸까... 

 

된다고 했다가 안되는것 보다는 차라리 안된다고 먼저 말하는게 낫다고, 저도 프로그래밍 처음 배울 때 사수들이 누누히 강조했던 부분이기도 합니다. "기획자가 되냐고 물어보는건 일단 안된다고 해라." 정말 개소리죠?  물론 기획적인 마인드를 바탕으로 하시는 분들은 안 그런 분들도 많습니다.  저 같은 경우에도 무조건 안된다고 하지 않고, 일단 들어보고 소스 확인하고 판단하고 대답해주는 편입니다.  바로 대답할 수 있는 경우엔 바로 대답해주고, 더 좋은 방법이나 아이디어가 있다면 이야기해주는 편이죠.

질문을 들으면 그에 해당하는 개발요소를 떠올리고, 많은 생각을 하는 개발자.  그렇기 때문에 뭔가 명확한 대답이 떨어지지 않아 불편하셨다면,  "이거 되나요? 안되나요?" 라고 질문하시기전에 "내가 이런 걸 만들고 싶은데, 가능할지 확인해주실 수 있나요?"라고 물으시는게 훨씬 긍정적인 결과를 가져올 수 있는 질문이지 않을까 싶습니다. 

 

개발자들 머리속에 해당 내용에 대한 정보나 구성이 담겨져 있다면 바로 대답해주겠지만, 그게 아니라면 확인해보겠다는 대답이 나올 수 있거든요.  그렇다면 그 때 또 놓치시지 말아야할게, 언제까지 대답해줄 수 있는지도 받으셔야 한다는거죠. 개발자는 질문을 받은 뒤 만약 하고 있던 개발이 있었다면, 그게 메일이나 메모로 남아있지 않는 이상, 하고 있던 일이 머리속에 계속 남아있어서 잊어버리는 수도 있습니다.

 

따라서 메일소통이 원활한 곳이라면 언제까지 알려달라는 확인사살 메일을 보내신다거나, 해당하는 날짜에 피드백이 없다면, 먼저 오늘까지 확인해주기로 했는데 혹시 확인하셨느냐, 알려줄 수 있냐. 라는 질문을 꼭 하셔야합니다. 대답을 들을 수 있는 시간은 가급적 하루이상 넘기지 않으시는게 좋구요.  확인하는게 물론 어떤 질문이냐에 따라 다르겠지만, 하루정도의 기한이면 충분하니, 잊지 않고 회신기한 받아서 마감일자에 재차 확인해서 궁금하셨던 사항에 대해 해소하고 다음 기획안을 그리기 위해 달려가셔야 합니다.

 

야메군의 덧붙임 말 - "기획의 책임 역시도 개발자와 공유하라."

 

이 이야기는 단순히 개발자나 디자이너에게 책임을 전가하라.. 라는 의미가 아니고, 기획의 모든 부분을 기획자 혼자서 고민하기 보다는, 기획요소 중 개발자가 잘하는 부분.. 혹은 디자이너가 잘하는 부분에 대해서 그들의 의견을 들어보고, 그들의 의견을 적극 반영하는 기획을 해야 한다는 것 입니다. 

 

프로세스를 구성한다거나 혹은 UI나 UX의 세부적인 요소들은 당연히 기획자보다는 개발자나 디자이너의 능력이 더 낫다고 볼 때, 그들에게 조언을 구하고 그것을 적극 기획에 반영함으로서, '기획=기획자의 몫' 이 아닌, '기획=함께 만들어가는 것' 이라는 공식을 만들어 가는 것이, 단순히 책임소지를 따지는 것이 아닌.. 모두가 책임감을 가지고 서비스를 만듦으로서 협업 대상자 간의 업무만족도를 높이는 구조를 만들어가는 첫 걸음이라는 점, 꼭 기억하세요..!!

 

웹 개발과 DB개발은 달라요.

 

개발자가 웹사이트를 개발한다고 했는데, 간간이 DB가 어떻고, ERD가 어떻고, 테이블이 어떻고...이런 이야기를 들으신 적이 있으실 거에요.  모든 웹서비스는 DB를 기준으로 이루어집니다. 그 DB는 누적할 그리고 누적된 데이터들을 모아놓은 저장소인데요.  지금쯤 이렇게 생각하실 수도 있겠죠. 그래 프로그래밍은 그렇다 치자, 그럼 DB는 그냥 데이터라면서!! DB 개발은 또 뭔데!! 라고 하실거에요.

 

 

야메군님이 강의하는 내용 중에 있는 간단한 데이타베이스 설계서, DB 스키마 자료를 언급하는 경우가 있는데, 자신이 쓴 기획안에서 데이터라 지칭되는 것이 무엇인지, 설명하고 있습니다.  이중  테이블이라 지칭되는 데이터베이스의 공간 안에 차곡차곡 데이터가 쌓이게 되면  그 데이터를 불러올 수 있어야하는데요.  그건 웹 프로그래밍과는 별개로 DB언어인 SQL(Structured Query Language:구조화질의어)로 필요한 데이터들만 호출하게 됩니다.

 

더 나아가서 Stored Procedure(이후 SP)라고해서 자주 사용하는 SQL을 함수처럼 만들어 저장해놓고 사용하기도 합니다.  MS-SQL에서는 SQL언어를 직접 호출해서 쓰기 보다는 Stored Procedure를 만들어서 사용을 하는 경우가 더 많죠.  이 말이 무슨소란가 싶으시죠?  게시판 내용은 DB에 있고, 그 내용을 불러오기 위한 방법으로 SQL을 이용해서 불러오게되고 불러온 내용은 프로그램으로 표현하는 거라고 생각하시면 됩니다.

DB만으로도 여러가지 벌어지는 일들이 많습니다.  기획안을 보고 DB를 설계하고, 설계한 내용대로 데이터가 들어갈 테이블들을 DB에 만들어놓고, 그 데이터를 호출하기 위한 SQL과 SP를 만들고..  그 내용들을 개발자에게 전달해서 그것만 가지고 웹 프로그래밍을 진행할 수 있도록 하죠.  규모가 좀 있는 IT회사라면 DBA가 따로 있으니까요. DBA는 말 그대로 DB의 데이터만이 아니라 실질적인 데이터파일을 관리하고, 백업하고 문제가 생기면 복구도 하는..  그래서 관련 유지보수를 할때도 DB유지보수와 시스템 유지보수는 별개로 해서 관리한답니다.

하지만, 대부분의 회사들이 DBA를 따로 두지 않고, 개발자들이 DB 설계하고, SQL만들고 하죠.  그리고 그 정보로 프로그래밍을 하구요.  회사에 DBA가 있다면 이런 흐름을 어느 정도 이해하고 계시겠지만, 그렇지 않다면 개발자가 프로그래밍 외에도 DB에 대한 개발도 함께 한다는 걸 이해하고 계시면 됩니다.  개발자 별거 다 하는구나.. 라고 인지하고 계시면 되는거죠.

뭔가 복잡하고 골치아픈 일을 많이 하는 듯한 개발자에게 내 기획안을 어떻게 설명하고 잘 개발할 수 있도록 구슬릴 수 있는지에 대한 이야기는 다음편에 더 진행해보도록 하겠습니다.

 

 

미시깽. 토끼같은 귀여운 딸래미 둘과 사과같은 남편과 살고 있는 웹개발 13년차.  아이러브스쿨과 SK커뮤니케이션즈 등을 거쳐, 국회입법조사처와 한국지역정보개발원에서 IT관련 빡센 행정업무를 경험하고, 세훈항운(주)에서 다시 웹개발을 시작, 자회사인 (주)온필에서 기술개발팀장으로 있으면서, 여행업이라는 새로운 분야에 대해 배우는 마음으로 시스템 개발에 매진 중.