짬을 내서 앱을 하나 만들었습니다.

(https://play.google.com/store/apps/details?id=com.dextto.fivehundredeng)

아내에게 '미국인이 많이 쓰는 문장'이라는 링크를 보내주었더니 좋아 하길래 앱으로 만들어 들고 다니면서 공부할 수 있도록 해 주고 싶었습니다. 허접한 앱이지만 만들고 보니 애정이 생겨 마켓 등록 1호 앱이 되었네요. 컨텐츠는 원문에서 원저자께서 공유를 허락하셨으니 감사히 가져다 썼습니다. :)


안드로이드로 개발을 시작한게 2010년 초였으니, 안드로이드 개발자임에도 불구하고 4년 반이 되도록 마켓에 앱을 하나도 등록해 보지 않았다는 게 부끄러울 따름입니다.

회사일이 바쁘다는 것과 너무 허접한 앱은 마켓에 올리기가 부끄러웠고, 실력이 쌓인 후 나름 기발한 아이디어를 떠올려 검색을 했을 때엔 이미 마켓에 유사한 앱이 너무나도 많았다는 게 핑계가 되지 않음을 잘 알고 있습니다. 그래도 앱 등록 경험을 해 보는 게 중요한 것을 알기에 늦게나마 하나 올려봅니다.


사실 앱의 컨셉은 너무 간단합니다. 컨텐츠가 동적으로 바뀌는 것도 아니고 정해진 데이터로 화면을 구성하기만 하면 되니까요.

기능은 아래 화면만 보시면 딱 아실거고, 문장을 클릭하면 음성(TTS)로 읽어 줍니다.


    


TTS는 폰에 설정되어 있는 것에 따라 다르니까, 원하시는 것으로 설정하시면 됩니다. 개인적으로는 Google TTS를 추천합니다.



     

피드백 남겨 주시면 다음 업데이트에 반영하겠습니다. 여건이 되면 서버에 컨텐츠를 올릴 수 있는 메뉴도 추가하고요. ^^


그럼 영어공부 즐겁게들 하십쇼~!

저작자 표시 비영리 변경 금지
신고

'개발자 Life' 카테고리의 다른 글

500 English - 미국인이 많이 쓰는 문장 500  (2) 2014.07.19
커뮤니케이션2 - 말 줄이기  (1) 2013.05.28
커뮤니케이션1 - 용어와 발음  (0) 2013.01.30
행복한 개발자  (0) 2013.01.20
프로그래밍을 배우자  (0) 2012.02.06
10만원짜리 수표의 가치  (6) 2011.07.14


  자신이 이야기할 때 주위가 갑자기 조용해지는 것을 경험해 본 적이 있는가? 주위 사람들이 입을 닫은 이유가 이야기에 집중해서 들으려고 한 것이라면 다행이지만, 어서 이야기가 빨리 끝나기만을 기다리려고 한 것이라면 슬픈 일이다. 더군다나 당신이 그걸 못 느낄 정도로 무디거나 그걸 알고 있음에도 계속 자기만의 이야기를 이끌어 간다면, 고위 간부인데다 같은 말을 반복해서 이야기 하는 스타일이라면 그것은 슬프다 못해 듣는 사람에게는 지옥이다.


  사사건건 남의 의견에 토를 다는 사람이 있다. 상대가 한 마디 하면 자기도 꼭 한 마디 덧붙여야 직성이 풀린다. 말허리를 자르고 들어와서 "아니, 그게 아니고"로 말을 시작한다. 서로의 의견을 주고받는 토론 자리가 아니라, 일상의 대화에서, 어제 있었던 연예인의 가십거리를 이야기 할 때에도, 오늘 먹을 점심 메뉴를 고를 때에도 자기만의 확고한 생각을 한 마디 거들어야 한다. 주제에 대해 아는 것이 많고 상식이 풍부해 질수록 이런 성향은 더 심해진다.


  그 대화 자리에서는 자신이 똑똑하게 느껴지고 위트도 있는 것 같이 느낄 수도 있다. 하지만 이런 대화술은 대화의 물길을 막을 뿐이다. 물길을 막으면 둑이 넘치고 새로운 물길이 생긴다. 결국 원래 주제의 이야기는 거기서 단절이다. 처음 그 대화 주제를 꺼내서 이야기를 끌어가고 싶어 했고, 좀 더 많은 대화를 나누기를 원했던 사람은 자신의 이야기를 못다 한 게 아쉽다. 자연스레 대화의 단절을 가져온 당사자에게 좋지 않은 감정이 생긴다.


  상대의 이야기를 들어주는 훈련이 필요하다. 내 의견과 다른 단어들이 입과 귀를 드나들면 참기 어렵다. 반대 의견을 내거나 더 재밌는 예를 들고 싶어 입이 근질거린다. 하지만 상대 이야기가 끝나기를 참고 기다려라. 그러고 나서 자기 말을 하자. 물론 상대의 의견을 무시하지 말고 부드럽게 받아 넘겨서. 말이야 쉽지 부단히 연습하지 않으면 어려운 일이다.


  오늘 옆의 동료가 점심메뉴로 해장국을 먹고 싶다고 하면 내 의견을 꺾고 동참해 보라. 그 친구는 어제 저녁 과로로 인해 속이 괴로울 지도 모른다. 그리고 콜을 외쳐준 당신을 속 깊은 사람으로 기억할 지도 모른다.

저작자 표시 비영리 변경 금지
신고

'개발자 Life' 카테고리의 다른 글

500 English - 미국인이 많이 쓰는 문장 500  (2) 2014.07.19
커뮤니케이션2 - 말 줄이기  (1) 2013.05.28
커뮤니케이션1 - 용어와 발음  (0) 2013.01.30
행복한 개발자  (0) 2013.01.20
프로그래밍을 배우자  (0) 2012.02.06
10만원짜리 수표의 가치  (6) 2011.07.14

"온 땅의 구음(口音)이 하나이요 언어(言語)가 하나이었더라 이에 그들이 동방으로 옮기다가 시날 평지를 만나 거기 거하고 ....... 서로 말하되 자, 성과 대를 쌓아 대 꼭대기를 하늘에 닿게 하여 우리 이름을 내고 온 지면에 흩어짐을 면하자 하였더니 ..... 여호와 께서 가라사대 이 무리가 한 족속이요 언어도 하나이므로 이같이 시작하였으니 이 후로는 그 경영하는 일을 금지할 수 없으리로다 ..... 자, 우리가 내려가서 거기서 그들의 언어를 혼잡케 하여 그들로 서로 알아듣지 못하게  하자 하시고 여호와께서 거기서 그들을 온 지면에 흩으신 고로 그들이 성 쌓기를 그쳤더라 그러므로 그 이름을 바벨이라 하니 이는 여호와 께서 거기서 온 땅의 언어를 혼잡케 하셨음이라 여호와께서 거기서 그들을 온 지면에 흩으셨더라"
- 창세기 11 : 1 ~ 9

  성경을 보면 신의 노여움으로 인해 인간이 다른 언어를 쓰게 된다는 일화가 나온다. 만약 이게 사실이라면 사람들과의 커뮤니케이션은 이 때 부터 더욱 어렵고 복잡해지고 힘들어 졌으리라. 같은 언어를 사용해도 말하는 사람이 사물에 대해 이해하는 바와 듣는 사람의 그것이 다른데 다른 언어를 사용한다면 오죽하겠는가.

  소프트웨어 개발업무 역시 커뮤니케이션이 업무의 큰 비중을 차지하며, 일을 풀어나가는 데에 열쇠가 된다.[각주:1] 개발자는 고객(또는 고객을 대표하는 부서), 테스터, 다른 개발자들과 주로 커뮤니케이션을 한다. 메일을 주고 받고, 회의를 하거나 기술문서를 작성한다. 게시판에 공지사항을 올리기도 하고, 사내 블로그를 통해 어떤 사안에 대해 의견을 개진하거나 토론을 하기도 한다. 이슈 트래커 역시 테스트 부서와의 중요한 커뮤니케이션 도구다. 
  이러한 커뮤니케이션 과정에서 소프트웨어 업계에서만 사용하는 공통의 언어, 일명 노가다 용어를 암묵적으로 사용하기도 하고, 특정 회사 내에서만 통용되는 용어를 쓰기도 한다. 중요한 것은 용어 자체가 아니라 그 용어가 지니고 있는 뜻을 서로 100%이해하고 있느냐는 것이다. 같은 현상을 바라보고도 서로 다른 언어를 사용해서 설명한다면 대화는 이어질 수 없다. 같은 언어를 사용하고도 상대방이 이해하지 못하는 용어를 사용하는 것은 오해를 일으킬 소지가 크다.

  같은 개발자끼리에서의 대화도 원활하게 진행되지 않는 경우가 많은데, 대화가 겉돌거나 반복되는 경우는 대부분 상대의 눈높이에 맞추지 않은 설명 때문이다. 자기가 아는 전문용어를 사용하는 것은 물론이거니와 대화 주제에 대한 이해도가 자기와 같다는 생각으로 설명을 하기 때문이다.
  필자가 대학 연구실에 있을 때 박사과정에 있던 선배는 세미나 시간 때마다 "여자친구에게 설명하듯이 발표해라"고 주문했다. 화자는 상대방이 이해하기 쉽게 풀어서 설명해야 한다. 물론 듣는 사람의 자세도 중요한다. 화자가 이야기 한 것을 이해하지 못했을 때 바로 다시 설명해 달라고 이야기해야 한다. 모르는 것을 부끄럽게 여기고 대화를 계속 이어나간다면 서로의 이해도가 달라져 서로 딴 이야기를 하게 되는 경우가 종종 있다.

  예전에 한글로 코딩이 가능한 컴파일러[각주:2]가 릴리즈 된 적이 있다. 하지만 개발자들의 호기심을 끌기만 했을 뿐 바로 시장에서 사장되고 말았다. 소프트웨어 기술의 대부분은 영어 문화권에서 발전되었기 때문에 소프트웨어 코드는 대부분 영어로 작성되고 사용되는 용어도 대부분 영어다. 즉 한글로 작성한 코드는 우리에게 너무나도 낯설었던 것이다. 
  그렇다면 코드나 어떤 용어를 읽을 때에도 최대한 영어 발음과 비슷하게 하는 게 맞지 않을까? 우리나라 개발자끼리의 대화에서 발음을 굴리는 게 쑥스럽다면 적어도 전국민에게 통용되는 콩글리쉬 발음으로 읽는 게 옳다고 생각한다.
  10년 전쯤 어떤 큰 공개 세미나에 갔었는데 한 발표자가 코드를 설명하면서 false [fɔːls]를 "뺄스"로 읽었다. 미국식이든 영국식이든 'ɔ' 발음기호를 "애"로 읽을 수는 없다. 더군다나 f의 발음이 쌍비읍은 아니질 않나. 차라리 피읖으로 읽었다면 그나마 나았으리라. 어쨌든 그 때부터 내 입에서는 미소가 떠나질 않았고 내 귀는 계속해서 그 괴상한 발음에만 집중하고 있었다. 그 발표자가 코드로 설명하고자 했던 내용이 더 이상 귀에 들어오질 않았다. 그는 적어도 나에게는 그가 전달하고 했던 예시 코드에 대한 설명은 실패했다.

  다음은 최근에 내가 겪은 이와 유사한 경우다.


단어

발음 기호

(미국식)

잘못된

한국식 발음 

destroy

distrɔ́i

디스토리

disable

 diséibl

디저블

stub

stʌb

스툽 

App.

æp

옙 

Height

hait

헤이트 

 Width

 widθ

 위드스

Floating 

flóutiŋ 

플루팅 

 Flag

flæg

플러그


  물론 사람마다 그 차이는 있겠지만 발음이 어눌하거나 평소에 익숙하지 않은 발음이 들리게 되면 뇌는 그 이상한 발음에 집중하게 된다. 문맥 속에서는 분명히 무슨 뜻인지는 알고 있고 어떤 단어를 이야기 했는 지를 이해했지만 머리 속에는 계속 그 단어가 맴돌고 발음에 신경이 쓰인다. 커뮤니케이션에 집중력이 떨이지는 것이다. 만약 당신이 이런 부류에 속한다면 당장 발음 교정에 신경을 써야 할 것이다. "저는 영어실력이 딸려요", "발음을 굴리기가 민망해요" 이런 것은 자기 변명에 불과하다.

  내가 너무 까탈스럽다고 생각한다면 그건 나도 어쩔 수 없다. 다만 커뮤니케이션에 있어 청자가 화자의 내용에 집중하도록 하는 하나의 팁을 제안할 뿐.

  1. 프로그램도 다양한 언어(Language)로 작성된다. [본문으로]
  2. http://myeveryday.tistory.com/entry/최초의-한글-컴파일러-씨앗 [본문으로]
저작자 표시 비영리 동일 조건 변경 허락
신고

'개발자 Life' 카테고리의 다른 글

500 English - 미국인이 많이 쓰는 문장 500  (2) 2014.07.19
커뮤니케이션2 - 말 줄이기  (1) 2013.05.28
커뮤니케이션1 - 용어와 발음  (0) 2013.01.30
행복한 개발자  (0) 2013.01.20
프로그래밍을 배우자  (0) 2012.02.06
10만원짜리 수표의 가치  (6) 2011.07.14


  나의 학부 전공은 컴퓨터 공학이나 멀티미디어 공학이 아니라 기계공학이다. 기계공학과 학생들도 프로그래밍을 해야할 때가 있다. 새내기 때에는 교양과목으로 컴퓨터 프로그래밍을 배우고, 고학년이 되면 수치계산이나 전공과목에서의 과제를 위해 프로그래밍을 해야 할 일이 있다. 하지만 내가 SW 개발을 본격적으로 배우기 시작한  것은 대학원 입학 전 직업교육학교 때이니, 그 때 부터를 내 SW경력이라고 하면 10년 반 정도 개발자로서 살아왔다고 할 수 있다.


  삶의 목표는 사람마다 다르겠지만 결국은 행복해 지기 위한 것이라고 생각한다. 그렇다면 개발자로서 행복한 삶을 살기 위해 행복한 개발자가 어떤 것인지 부터 정리할 필요가 있다. 10년이 지났지만 더 늦기 전에 정의부터 해 보기로 했다.


  행복이라는 단어를 국립국어원 표준국어대사전[각주:1]에서 찾아보면 다음과 같이 나온다. 


행복01(行福)〔행복만[-봉-]〕

「명사」『불교』

삼복(三福)의 하나. 대승(大乘)의 행법을 지키며, 도심(道心)을 일으키어 인과의 도리를 믿으며, 대승 경전을 읽어서 이해하고, 다시 남에게도 권함으로써 얻는 복을 이른다. ≒행선03(行善)「2」.


행복02(幸福)[행ː-]〔행복만[행ː봉-]〕

「명사」

「1」복된 좋은 운수. ≒행우02(幸祐)「1」.

「2」생활에서 충분한 만족과 기쁨을 느끼어 흐뭇함. 또는 그러한 상태. ≒행우02「2」ㆍ휴복(休福).


  여기서 말하고 말하고자 하는 행복은 거창한 불교 용어로서의 행복(行福)이 아니라 "생활에서 충분한 만족과 기쁨을 느끼어 흐뭇함 또는 그러한 상태"의 행복(幸福)을 뜻한다. 즉, 개발자의 행복은 개발업무를 하면서 충분히 만족을 느끼는 상태를 말하고, 개발과 관련된 모든 행위를 하면서 그 행위에 만족을 느낀다는 말이다. 

  중요한 것은 대부분의 개발자들이 그나마 행복을 느끼는, 주어진 문제를 풀고, 사용자에게 유용한 프로그램을 만들어 내는 1차적인 행위만을 말하는 것이 아니다.


  답은 나왔다. 적어도 우리나라 개발 문화에서의 개발자로서의 행복은 막연한 환상이며 꿈일 뿐이다. 내가 10년간 보고 겪은 대부분의 개발자들에게 위 행복의 정의를 들이대었을 때자기 일에서 행복감을 느꼈다는 사람을 떠오르기는 힘들다얼마 전 SBS의 "리더의 조건"이라는 프로그램에서 나왔던 이원영 대표가 있는 제니퍼 소프트 같은 회사가 대한민국에 존재한다는 게 놀라울 뿐이다.

  일을 즐기면서 하는 사람이 몇이나 과연 몇이나 된단 말인가. 그렇게 행복이 쉬운 것이었다면 서점에 즐비하게 널려있는 자기계발서만 열심히 읽고 실천했어도 행복해 질 수 있었으리라.


  하지만 지금 행복하지 않다고 해서 행복을 추구할 권리까지 포기하지는 말자. 왜 개발업무에서 행복을 느낄 수 없는 지를 살펴보고, 그 원인을 하나씩 제거해 나간하면 행복에 조금씩 다가갈 수 있을 것이다.


  다음은 내가 그동안 개발업무를 하면서 받은 스트레스들이다. 이 것들의 원인을 하나씩 찾아서 없애보자. 원인을 없앨 수 없다면 스트레스를 동반하는 음(陰)의 기운으로 일을 하지 말고, 일을 하면 즐거워 질 수 있도록 방법을 찾아 보자.


. 개발부서는 항상 사내에서 "을"의 위치에 있다. 

  기획부서에서 환상적(?)으로 짜 온 아이디어를 구현하지 못해 비난을 당한다.

  테스트 부서로부터 품질 기준을 맞추지 못했다고 욕먹는다.

  마케팅 부서로부터 제품 출시일을 맞추지 못해 릴리즈가 연기되어서 왕창 깨진다.

. 프로젝트 막판에 바뀌는 요구사항

  일관성 없는 요구사항 변경 (본부장님의 지시다. 사업자 스펙이 바꼈다...)

. 거지 같은 코드 베이스

  정말 가끔씩 나 혼자 작업했으면 하는 생각이 불쑥 솓아 오른다. 줄도 안맞는 코드를 들여다 보고 있으면 눈에 초점이 흐려진다.

. 사람 

  결국은 사람이 스트레스다. 

  인간 관계를 잘 맺는 것이 단지 커피 마시고 농담하는 사이가 되는 게 다인 것인지 의심스러울 때가 있다.

  싸놓은 X를 치워주는 것도 한 두번이지, 매번 문제만 일으키는 사람과 인간관계를 계속 좋게 가져가야 하나.

  고압적인 상사

. 동시 다발적으로 주어지는 업무. (데드라인도 없이 지급으로)

. 사라진 개인생활

일정우일정 (日停又日停)

  개발자는 매일 새로운 것을 배우는 것을 좋아한다. 하지만 일에 치여 살다보면 어느새 정체되어 있는 나를 발견한다. 내가 원했던 모습은 이게 아니었다.

  개발 문화는 선진국의 것을 가져다 쓴다. 하지만 주변 사람, 특히 파트장이 새로운 것을 배울 생각이 없으면 이것만큼 난감한 것이 없다.

. FUN이 대세다.

  즐거운 직장문화 만들기가 화두가 된 지는 꽤 되었다. 하지만 업무시간에 모여서 시시껄렁한 농담이나 주고 받는 게 FUN한 직장 문화는 아니다.


위 주제들에 대해 시간이 날 때 마다 하나씩 고민해서 포스팅을 할 예정이다.

물론 주제가 떠오를 때마다 추가도 한다. 위 네모 박스가 얼마나 길어질 지는 나도 모른다. 지금 머리에 저정도만 떠올랐을 뿐.

  1. http://stdweb2.korean.go.kr [본문으로]
저작자 표시 비영리 변경 금지
신고

http://www.codecademy.com 
초보자가 쉽게 따라올 수 있도록 꾸며진 웹사이트.

마이클 블룸버그 뉴욕 시장이 “새해에는 코드카데미(
www.codecademy.com)를 통해 컴퓨터 코드를 배우기로 결심했다”며 “함께 배우자”는 트윗을 게시 함으로서 코드카데미에 가입한 것이 확인. 기자 출신으로 경제 전문정보 블룸버그통신을 창업·성공시킨 60살의 뉴욕시장이 프로그래밍을 배우겠다고 나선 것.

코드카데미에는 1월 24일 현재 전 세계에서 36만 명이 등록해 프로그래밍을 배우고 있습니다. 프로그래밍을 처음 하는 사람도, 따라 하기만 하면 1년 뒤에 근사한 App을 만들 수 있게 된다고 합니다.
 


저작자 표시 비영리 동일 조건 변경 허락
신고

책장 정리를 하다 입사교육 수료식 때 지도 선배가 나눠줬던 A4지 한장에 적혀있는 좋은 글이 있어 옮겨봅니다.


명강사로 소문난 사람이 있었습니다.
수많은 사람이 모인 세미나에서 그 강사가 열변을 토하고 있었습니다.
그러다....... 그 강사는 갑자기 호주머니에서 10만원짜리 수표 한 장을 높이 쳐들고 말했습니다.
"여러분 이 돈을 갖고 싶지요?
어디 이 돈을 갖고 싶은 사람 손 한 번 들어 보십시오."
그러자 세미나에 참석한 그 수많은 사람들 대부분이 손을 들었습니다.
강사는 계속해서 말을 이었습니다.
"저는 여러분 중에 한 사람에게 이 돈을 드릴 생각입니다."
"하지만 먼저 나의 손을 주목해 주시기 바랍니다."

그러더니 갑자기 쳐들었던 10만원짜리 수표를 손으로 이리저리 마구 구겼습니다.
"여러분 아직도 이 수표를 가지기를 원하십니까?"
사람들은 갑작스러운 강사의 그 행동에 놀라면서도 역시 거의 모든 사람이 손을 들었습니다.
"좋아요."
그러더니 이번에는 그 10만원짜리 수표를 땅바닥에 던지더니 구둣발로 밟으며 더렵혔습니다.
그리고 땅바닥에 떨어져있는 구겨지고 더러워진 그 10만원짜리 수표를 집어 들고,
아직도 그 돈을 갖고 싶은 지를 물었습니다.
또 다시 거의 대부분의 사람들이 손을 들었습니다.

이 때 강상는 힘찬 어조로 다음과 같은 결론을 내렸습니다.
"제가 아무리 10만원짜리 수표를 마구 구기고 발로 짓밟고
더럽게 했을 지라도 그 가치는 줄어들지 않습니다.
10만원짜리 수표는 항상 10만원짜리 수표의 가치가 있는 것입니다." 



아름다운 4반 여러분!
여러분도 현업에서 생활하다보면 여러 번 바닥에 떨어지고, 밟히며, 더러워지는 일도 있을 것입니다.
물론 성공의 기쁨도 있지만, 패배라는 이름으로 겪게 되는 그 아픔들...
그런 아픔을 겪게 되면 사람들은 대부분 자신이 쓸모없는 사람이라고 평가절하 합니다.

허나 놀라운 사실은 여러분이 실패를 하는 한이 있더라도 여러분의 가치는 여전하다는 것입니다.
마치 구겨지고 짓밟혀도 여전히 자신의 가치를 가지고 있는 이 수표처럼 말입니다.

지도선배 남OO Dream


저작자 표시 비영리 변경 금지
신고

원문: 조성문의 실리콘밸리 이야기
새로운 플랫폼 위에 지어진 비즈니스, Airbnb
http://sungmooncho.com/2011/06/22/airbnb/

참 대단합니다. 아이디어를 끝까지 밀고 나가 결국 성공을 이루네요.

신고

(글을 쓰기에 앞서 저는 고부간의 갈등이 해소되었으면, 아니 그런 단어조차 없어져 버렸으면 하는 생각을 항상 가지고 있는 사람임을 밝혀둡니다. 여기서 지칭하는 시어머니는 제가 주위에서 듣고 드라마에서 보아왔던 고정관념을 기반으로 쓰여진 것입니다.)

일을 하다 보면 여러 부류의 사람을 겪게 됩니다.
어딜 가나 회사라는 조직에는 맘에 안 드는, 정확히는 자기와 맞지 않는 사람들이 있습니다.
여러 성격 유형 검사에서 말하는 서로 상극인 사람들이지요.

이처럼 상극인 사람들을 한 번 소개할까 합니다.
뒤를 돌아보면 저도 사춘기 부하직원처럼 굴 때도 있었습니다.
또 지금 배우고 있는 일이 관리업무다 보니 내가 시어미니 같이 시시콜콜 물어봐야 할 때가 많아 미안한 경우도 많습니다. 하지만 제가 그러지 않으면 제 상사가 또 나에게 질문을 퍼부어 대길래 할 수 없이 시어머니 짓을 합니다. 휴.. 먹고 사는 게 내 맘같지 않습니다.

시어머니 같은 상사

먼저 이런 상사의 특징은 처음 꺼내는 대화를 상대의 눈높이에 맞추지 않는다는 것입니다. 다른 사람의 생각이 자기와 같다고 가정하고 시작합니다.
처음엔 두서없이 업무 지시를 내립니다. 갑작스런 업무지시에 당황한 부하직원은 이해하지 못한 표정을 짓습니다.
그러면 시어미니 상사는 친절하게도 해당 업무를 A부터 Z까지 설명하고 상대가 제대로 이해했으리라 생각합니다.
사실 이것은 말을 하면서 자신이 무엇을 말하는지, 말하면서 실수는 없는 지 갈무리 하는 것일 뿐입니다.
세부적이고도 시시콜콜한 정보는 잡음으로 들리는 부하직원은 주의력이 떨어지고 정작 들어야 할 핵심 설명을 놓쳐 버립니다.
더군다나 처음 해 보는 일이라 배경지식이 부족한 상태에서 업무지시를 받은 부하직원은 떨어진 업무가 무엇인지 정확하게 판단하지 못했지만, 지루하고도 짜증섞인 A to Z 설명을 다시 들어야 하기에 다시 물어볼 엄두가 나지 않습니다.
일은 그렇게 엉뚱한 방향으로 진행되고 시어머니 상사는 속으로 한 마디 합니다.
"이렇게 자세히 설명해 줬으니 이제 알아서 잘 하겠지?"

두 번째 특징은 의심이 많다는 것입니다.
어느 정도 일이 진행되어야 보고할 거리도 생길 텐데 자꾸 작업 중에 진척상황을 물어봅니다.
SW 개발의 특성상 업무 중 인터럽트는 최악입니다. 인터럽트 걸리고 나서 다시 원래 작업으로 컨텍스트 스위칭시키는 데 걸리는 시간이 평균 20분이라는 데, 일명 '관리'라는 명목하에 시도 때도 없이 전화를 해 댑니다.

현재 문제가 뭔지 어떻게 돌아가고 있는지 시어머니는 기필코 설명을 들어야 직성이 풀립니다.
그나마 설명을 들으며 이해라도 하면 다행입니다. 설명을 하다 보면 개발 지식이 있어야만 이해할 수 있는 것들에 대해 설명하기 마련인데, 소위 '윗분'들에게는 5살짜리 조카에게 설명하듯 쉽고 차근차근하게 설명해야 된다고 강조합니다.
누구나 알아 들을 수 있는 말로 쉽게 설명하지 못하는 당사자의 문제라고들 이야기 하지만, 부하직원은 왜 같은 개발자 출신이면서 자신의 설명을 이해하지 못하는 지 의아해 합니다.
관리자가 되면서부터 현업에서 손을 놓아 버려서 감이 떨어진 듯 합니다.
하지만 인간의 기억력으로는 그 놈의 '중요한' 이슈들이 너무도 많기에 금방 잊어버리고, 또 다시 물어보고 담당자의 집중력을 분산시키는 악순환을 반복합니다.

사춘기 부하 직원

보통 회사 입사후 3~4년차가 되면 이런 증상을 많이 보입니다. 경력은 어느 정도 쌓였고 회사 돌아가는 일도 알고 소위 통빡도 굴릴 줄 압니다. 맡은 업무도 자신있게 하며 성과를 냅니다.

하지만 주위에 시어머니같은 상사로부터 시달림을 3년 정도 당하다 보니 이젠 이래선 안되겠다는 생각이 듭니다.
'아우..이놈의 회사를 때려쳐 버리던지 해야지..'
'일을 시키면 알아서 할텐데 왜 저렇게 난리를 쳐대지?'
이런 생각이 하루에도 수십번씩 들어서 스트레스는 쌓여만 갑니다.

우리의 열정 많던 신입사원은 이렇게 사춘기에 접어들면서 모든 업무에 벽을 치기 시작합니다.
자기와 다른 사람의 업무영역을 비자 없이는 들어오지 못하는 국경처럼 나누고, 선을 넘어온 요청을 다시 반사시킵니다.
팀내 동료가 업무량이 많아 허덕일 때도 자기 할 일 끝냈다고 모른체 합니다. Work & Life Balance를 맞추기 위해서입니다.
하지만 사실 이미 다른 업무가 들어오면 불쑥 화부터 치밀어 오르는 상태가 된 지라 주변을 돌아볼 여유 따윈 없어져 버린지 오래입니다.


사실 이 둘은 같은 목표를 가지고 있습니다. 안정된 제품(SW)를 정해진 기간 내에 고객에게 납품한다.
하지만 목표를 실천하는 방법에는 입장의 차이가 있습니다.
서로 양보하고 대화로 풀 수 있는 방법을 배우지 못한 우리는 이렇게 또 힘겹게 하루를 보냅니다.
 
요즘 애자일 서적을 많이 읽고 있는데 우리 정서에 너무 맞지 않는 것들이 많은 것 같아 아쉽습니다.
성공사례를 들고 있긴 하지만 똑 같이 따라했다간 왕따당하기 십상입니다. ㅎㅎ

칼퇴근 하면서 멋진 제품을 만들어 내는 날은 언제쯤 올까요?
제가 나중에 팀장이 되면 어떻게 해야 될까요? 이 주제로 한 번 글을 정리해 보는 것도 의미가 있어 보이네요 ^^ 


저작자 표시 비영리 변경 금지
신고

애자일 이야기 http://agile.egloos.com/4570504

내가 6년째 하고 있는 휴대폰 SW 개발 업무를 가지고 3가지 질문에 스스로 답해 봅니다.
정확히는 프로그래밍에 대한 답변입니다.

1. 좋아하는가?
네, 좋아합니다. 5학년때 학교 컴퓨터실에 있는 SPC3000(정확한 모델명은 기억나질 않네요;;)으로  베이직 프로그램을 만들던 때 부터 좋아했습니다. 대학 전공인 기계과에서 대학원을 전산쪽으로 바꾸었을 때도 이 질문은 결정에 큰 영향을 주었습니다.

2. 잘 하는가?
음... 답변하기 무지 어렵습니다. 중간 이상은 하는 것 같습니다. 사실 주위에 잘 하는 사람들이 너무 많고, 그렇지 못한 사람들은 더더욱 많습니다.

3. 지속 가능한가?
피끓는 20대였을 땐 좋아하는 일만 쫓아다니며 할 수 있었습니다.
지금은 서울에서 결혼하고, 집사고 나중에 애들 키울 생각하니 좀 가슴이 시려오네요.
거기에 우리나라 대기업의 특성상 경력이 늘어날 수록 관리로 빠지게 되니 다음 휴가때 심각하게 진로 고민을 해 봐야 겠습니다. 
학교 후배이자 대학원/회사 동기인 누구는 회사 때려치고 벤처 회사 하나 꾸려가고 있는데.. 저만 제자리인 것 같은 생각도 들곤 하네요.


저작자 표시 비영리 변경 금지
신고

지난 이틀 간은 정말 오랜 만에 똥줄 타는 경험을 했습니다.
이번 주 내로 고객(휴대폰 개발을 하고 있으니 통신 사업자입니다)에게 전달 해 줄 버전을 릴리즈 하기로 되어 있었습니다.
그저께 빌드를 했는데 컴파일러가 에러 메세지를 뱉어내며 빌드를 멈추었습니다.
보통 에러 메세지가 나오면 그 위에 어느 파일에서 에러가 났는 지 알 수 있는데, 이 번 놈은 아주 악질이었습니다.
뭔가 알 수 있는 정보가 있어야죠.

결국 이틀 간 삽질하고 어제 밤을 꼴딱 새고서야 원인을 드디어 찾아냈습니다.
디폴트로 들어가는 APK(안드로이드 어플) 파일명에 있는 &(Ampersand)문자가 문제였습니다.
make에 쓰고 있던 명령어에 맞지 않는 문법이 들어온거지요.

순간 얼굴이 화끈거리더군요.
저 파일을 베이스 소스에 머지한 사람이 바로 저였거든요.. ㅠㅠ

왜 저 빌어먹을 사업자가 전달해 준 괴상한 파일의 이름을 꼼꼼하게 읽어보지 않았을까요.(사실 다른 APK에는 확장자 앞에 공백이 들어간 파일도 있었습니다)

사실 제가 머지한 부분이 문제가 되리라고는 꿈에도 생각하지 못했습니다.
아주 당연히 파일을 복사하기만 된다고 생각하고 verify(자기가 넣은 머지코드에 에러가 없는지 빌드해서 확인하는 것)과정을 생략했습니다. 
옆에 있던 동료가 make 파일에 echo로 로그를 마구 박아가며 디버깅해서 찾아줬지요.
동주 선임 땡큐. 역시 공인 아키텍트입니다. ^^

오늘 하고자 하는 이야기는 이 디버깅 과정에서 겪은 어려움을 토로하고 앞으로 조심하자는 게 아니라 문제를 찾는 과정에서 겪은 느낌을 적어보려고 합니다.

문제를 만들었을 때와 같은 사고방식으로는 그 문제를 해결할 수 없다. - 아이슈타인 -


내공이 낮은 저같은 사람들은 일반적으로 큰 문제가 생기면 아드레날린이 치솟아 오르면서 누가 에러를 저질렀는지 부터 찾으려고 합니다. 시간이 촉박할 경우에는 더하죠. 머리가 멍해지면서 사고가 경직되어 갑니다.
그리고 껀수라도 하나 발견하면 담당자를 찾아 마구 쪼아대죠. 이건 어떻게 보면 시간을 아끼기 위한 당연한 조치이긴 하지만요. 저도 먼저 에러 로그만 보고 빌드 에러가 났던 모듈 담당에게 확인해 달라고 요청부터 했으니까요.

내공이 깊은 고수들은 다릅니다.
증상만 보고 원인을 추측하지 않습니다. 하나 하나 다시 뒤집어 가며 살펴 보지요.
그리고 "직관"적으로 문제의 원인을 빠르게 짚어냅니다. 하수가 사용하는 직관(단순 현상만 보는)과는 그 질이 달라 보입니다.

요즘에 앤디 헌트가 쓴 책 "실용주의 사고와 학습(Pragmatic Thinking & Learning - Refactor Your Wetware)"을 읽고 있는데 바로 '2장 초보자에서 전문가에 이르는 여정'에 이러한 내용이 실려 있습니다.

다음 드라이퍼스 모델의 다섯 단계에서 숙련자라고 생각하고 있던 제 자신이 부끄러워 집니다.

단계1: 초보자
단계2: 고급 입문자
단계3: 중급자
단계4: 숙력자
단계5: 전문가

나무를 보지 말고 숲을 봐야겠습니다.


저작자 표시 비영리 변경 금지
신고

티스토리 툴바