IT 이야기2014.12.04 04:54

몇 달 전 투자도 많이 받고 주목도 받고 있는 한 스타트업 대표로부터 질문을 받은 적이 있다. 개발 일정이 의도한대로 끝나지 못한 책임을 누가 가져가야 하느냐에 대한 질문이었다. 나는 주저 없이 그것은 일정을 제대로 계획하지 못한 프로젝트 매니저와 회사의 책임이 가장 크다고 말했다.

하지만 그 대답을 들은 대표는 별로 탐탁지 않아했다. 그의 생각은 어느 그룹이든 열심히 하는 개발자들도 있는 반면에 요령을 피우는 개발자도 있지 않냐는 것이다. 그런 개발자들의 잘못도 매니저가 가져간다는 것은 부당하다는 것이었다

이런 생각이 이 회사의 대표만의 생각은 아닐 것이다. 대부분의 비즈니스 사람들은 개발자들이 태만하거나 능력이 월등하지 못할 경우에 일정에 차질이 생길 수 있다고 오해를 하는 경우가 많다. 결국 이런 오해로 서로에 대한 신뢰관계를 무너뜨리고 같은 목표와 비전을 가지고 일하는데 있어서 큰 장애가 되고 만다.




개발자들은 느리지 않았다.


실제 프로젝트의 통계를 살펴보면 대부분의 개발 프로젝트는 개발자들의 능력보다도 어떤 의사결정이 늦어지거나 테스트 프로세스가 미흡할 경우의 이유로 늦어지는 경우가 더 많다. 이것을 뒷받침 해주는 데이터가 Sprintly라는 회사에 의해서 발표되었다.

Sprintly는 애자일 기반의 프로젝트 관리 툴을 제공하는 회사로 클라우드 환경에서 많은 개발 팀들이 그 툴을 이용하고 있다. 때문에 그들의 툴을 사용하고 있는 개발팀들의 데이터들을 통해서 특정 패턴들을 발견할 수 있었다.

먼저 개발자들이 티켓을 처리하는 속도가 결코 느리지 않았다는 것이다. 그들은 굉장히 다양한 회사들의 개발 프로젝트들을 조사하였다. 그들은 약 75%의 티켓 즉, 업무 리스트들이 평균 175시간에 해결되는 것을 추출해낼 수 있었다. 즉, 전체 프로젝트가 완료되는 시간에 비추어 굉장히 짧은 시간이었다. 

두 번째로는 실제로 티켓의 개발이 시작 되기 전에 티켓이 수정되거나 우선순위를 조정하기 위해서 굉장히 많은 시간을 보내는 경우가 많았다. 이것을 칸반 이라는 애자일 방법론에서는 리액션 타임이라고 부르는데 주로 티켓을 만들고 우선순위를 정하기 위해서 걸리는 시간을 이야기 한다.

마지막으로 그들의 데이터를 통해서 실제 각각의 업무가 “완료” 단계의 상태에서 “배포준비”로 가는데 까지 시간이 꽤 오래 걸린다는 것을 볼 수 있었다. 이 데이터가 의미하는 것은 실제로 개발된 스펙이 원하던 것인지 검토하고 다시 수정하는 시간이 오래 걸린다는 것이다.


그렇다면 왜 실제 개발 프로젝트가 지연되고 느려지는 것일까?



업무의 잦은 스위칭


먼저 개발자들을 느리게 하는 것은 한꺼번에 다양한 일을 처리해야 하는 경우이다. 즉, 처리해야 할 우선순위가 바뀌거나 먼저 처리해야 될 우선순위의 업무가 생겼을 경우이다. 개발자가 아니고서는 이해하지 못하는 사실이 있다. 

만약 A라는 업무를 50% 정도 완료한 뒤에 B라는 업무를 진행했다고 하자. B의 업무를 진행하고 A를 다시 진행한다며 그 업무는 과연 50%일까? 다른 업무에 머물러 있는 시간과 업무 성격에 따라서 적어도 70% 정도의 업무가 될 때가 많다. 

다양한 실험을 하고 알고리즘을 개발하는 업무라면 더더욱 그 업무에만 집중하는 것이 효율이 좋다. 실제 리드 개발자들은 다양하게 업무들을 스위칭하며 일하는 경우가 많다. 코드리뷰를 수행하고 짝 프로그래핑 그리고 여러 미팅을 다니게 되는데 이런 개발자가 실제 핵심 모듈을 개발하는 역할까지 수행해야 한다면 그 생산성을 보장받기가 어렵다.

조엘 스폴스키 또한 이것에 대한 자신의 의견을 피력한 적이 있다. 

“개발자들에게 한번에 하나 이상의 업무를 할당해서는 안 된다. 좋은 매니저라면 개발자들을 한가지 업무에 집중해서 좋은 생산성을 보장해줄 필요가 있고 그 외의 여러 장애물도 같이 제거해 주어야 한다. 어떤 급하게 처리해야 할 업무가 있다면 스스로 처리할 수 있는 문제인지를 한번 생각해봐야 한다.”



불분명한 요구사항


실제 요구사항들은 지나치다 싶을 정도로 자세하게 작성 되어야 한다. 만약 개발자들이 그 요구사항을 이해하고 있지 않다면 어떻게 개발이 가능할 것인가? 실제 많은 프로젝트들을 보더라도 개발을 시작할 때 보다 자세한 스펙들을 작성하는 경우가 상당하다.

그리고 더 중요한 것은 제품에 대한 책임 결정권자가 그 기능에 대해서 정말 심각하게 고려하지 않은 경우가 많다. 그럴 경우에 개발자들은 왜 이 기능이 사용자에게 필요한지에 대한 이해가 없이 시작한 개발은 결코 창조적인 아이디어가 나올 수 없을뿐더러 그들 스스로도 개발자인지 아님 코더인지에 대한 정체성에 혼란이 오기 마련이다.

요구사항에서는 적어도 기능에 대해서 어떤 기능을 누가 왜 필요한지에 대한 이야기를 풀어내야 하고 더불어 다양한 상황에 대한 테스트 케이스들을 작성해주어야 하는 것이 가장 기본적인 스펙이 된다.

여기서, 요구사항이 터무니 없이 추상적이라면 그것은 더 세부적으로 나눠서 작성해야 한다는 뜻이 된다.



요구사항들의 변경

마지막으로 개발자들에게 있어서 가장 큰 불만 중 하나는 실제 업무가 시작된 뒤에 그것이 다시 바뀌는 경우이다. 개발자들이 변경하는 것 자체를 싫어하는 것은 아니다. 비즈니스 전략과 반응에 따라서 얼마든지 스펙은 변경될 수 있다. 하지만 그런 구체적인 사유와 데이터가 아닌 단지 시작 전에 정확하게 분석하지 못해서 오는 변경이라면 분명 시간적으로 낭비가 되는 것이다. 

물론, 개발자들은 정신적인 데미지도 함께 느끼면서 내가 만드는 것이 없어지거나 바뀔 수 있다는 불안감 때문에 코드 퀄리티에도 영향을 주게 될지도 모른다.

실제 개발을 시작하기 전에 중간 레벨 정도의 목업 프로토타입만 먼저 구현하는 것도 한가지 대안이 될 수 있을 것이다. 포켓웍스(Pocketworks)의 토빈 해리스(Tobin Harris)는 다음과 같이 이야기 했다.


“어떤 프로젝트에서는 프로타입을 통해서 철저히 분석하는 것이 더 빠를 수 있다. 우리는 개발 전에 사용자와의 인터렉션과 흐름에 대해서 충분히 생각하지 못한다. 그래서 결국 구현 후에 다시 그것을 생각해보게 되고 다시 개발하게 되는 것이다.”


이런 잦은 변화가 수반될 수 있다는 점에서 애자일 방법론에서 이야기하는 짧은 주기를 통해서 만든 결과물을 리뷰하고 다시 일정을 조정한다는 것은 큰 의미가 있다.

매니저들은 개발자들이 성공적으로 그들의 개발 역량을 잘 발휘할 수 있는 환경을 제공해줄 책임을 가지고 있다. 먼저 개발자들에게 딜레이 된 개발일정을 불평하기 보다는 먼저 그들 스스로 자신이 제공한 일정과 환경에 대한 책임을 먼저 생각해 보면 어떨까? 


성공적인 개발팀을 만들기 위해서는 명확한 비전이 공유되어야 하고 비즈니스 사람들과 같은 목표 아래 프로젝트가 진행되어야 할 것이다. 개발자들 또한 자신의 할 일을 줄이기 위해서 토론하고 일하기 보다는 그 목표를 같이 만들어가기 위한 적극적인 참여가 필요하다. 왜냐하면 우리는 코더가 아니라 창작물을 다루는 개발자들이기 때문이다.



저작자 표시
신고
Posted by 박경훈
IT 이야기2014.11.07 09:13

필자가 6년전 처음으로 영국의 개발문화를 체험하기 전에는 한국 출신 개발자라는 자부심이 있었다. 종종 한국 개발자들은 여러명이 해야 할 작업을 혼자서 처리하는 다재 다능한 개발자로 비유되어왔다. 타이트한 일정 속에서도 야근을 감수하며 어떤 플랫폼이나 언어를 만나도 두려워하지 않는 이들이라는 이미지도 강했다. 그래서 하루에 8시간씩만 일해온 영국 보다는 하루 최소 10시간 이상을 개발에 전념해 온 한국의 개발자들이 당연히 나을 것이라고 생각했다. 

 

하지만 정작 외국 개발문화를 체험하면서 한국에서 쌓아온 경럭에 대한 자신감은 사라졌다. 영국에서 고급 개발자들에게 거는 기대와 한국에서 고급 개발자들에게 거는 기대가 확연히 달랐기 때문이다. 6년전 필자는 7년 정도의 실무 경력이 있었기에 당연히 시니어 레벨이나 개발 팀을 이끄는 리드개발자가 되지 않을까 싶었지만 그들의 기준에서는 턱없이 부족한 실력이었다. 

 

한국에서 개발자 실력이라고 하면 개발 속도와 임무완수 여부에 초점이 맞춰지는 경향이 많다. 즉, 적어도 실력있는 개발자는 일정을 밀리지 않고 잘 끝낼 수 있어야 한다. 하지만 영국에서 실력 있는 개발자라고 하면 주니어 개발자들이 막힌 문제들을 잘 풀어 줄 수 있어야 할 뿐만 아니라 속도보다는 얼만큼 코드를 객체지향 관점에서 적재적소의 패턴들을 적용하며 잘 작성할 수 있느냐로 평가된다. 



이 차이를 실감하면서 기존에 내가 생각했던 슈퍼 개발자의 능력과 방향이 조금 잘못되었다는 것을 느낄 수 있었다. 그렇다면 실무에서 20~30년 이상의 개발경력을 가지는 백발 개발자는 어떻게 커리어를 쌓아 왔을까? 

 

먼저 개발 분야의 전문성 레벨을 드라이퍼스 모델(Dreyfus Model)에 비교해 보자. 이 모델은 80년대 초 드라이퍼스 라는 두 형제에 의해 발표된 것으로 어떤 기술을 습득하는데 있어 거치게 되는 진화과정을 5단계로 나누고 있다. 5단계는 초급자(Novice), 초중급자(Advanced Beginner), 능숙자(Competent), 숙련자(Proficient) 그리고 전문가(Expert)로 분류된다. 

 

초급자는 언어와 개발 도구에 대해 경험이 전무한 초급 개발자에 해당한다. 때문에 어떤 매뉴얼을 따라 결과를 만들어 내는 것은 가능하지만 혼자서 창의적으로 코드를 작성하기 어려운 단계로 분류할 수 있다. 

 

매뉴얼이 없이 어느정도 개발이 가능한 단계가 바로 초중급자다. 어려운 로직이 아닌 범위 안에서 자유롭게 코드를 작성할 수 있는 단계다. 능숙자는 언어와 툴에 대해서 모두 익숙해진 단계이고 어떤 프로그램 로직이라도 원하는 결과물을 만들어 내는 것이 가능하다. 

 

능숙자까지는 소스 품질이 외국이나 한국이나 큰 차이가 없다.하지만 국내의 경우 품질보다는 결과를 더 중시하는 문화 때문에 숙련자로 성장해야 된다는 필요를 느끼지 못하는 경우가 많다. 즉, 5~7년이 지나면 개발자 레벨이 평준화된다고 이야기하는 것을 종종 듣는 것과 같은 맥락이다. 

 

하지만 능숙자와 숙련자는 만드는 결과물이 같지만 그것을 어떻게 만들었는지에 대해서는 분명한 차이가 있다. 보다 많은 예외 상황들을 고려하고 향후에 확장될 수 있는 가능성들을 검토해 보다 언어적으로는 객체지향적이고 또 관점지향적인 설계가 가능한 것과 더불어 시스템이나 플랫폼적인 설계도 가능하게 되는 단계이다. 많은 개발 패턴들을 알고 있고 실제 어떤 상황에서 적용하면 좋고 안 좋은지에 대한 이해가 있는가?그렇다면 숙련자 레벨이 된 것이다. 

 

숙련자 레벨을 넘어서게 되면 전문가 레벨로 가게 되는데 주로 외국에서는 개발자들의 코드를 리뷰하는 아키텍트가 바로 여기에 해당된다. 아키텍트의 역할은 주로 소프트웨어 품질을 관리하는 것이다. 그런만큼 숙련자들이 할 수 있는 실수들을 줄여줄 수 있는 능력을 가지고 있어야 한다. 즉 ,그들이 하게 되는 실수들을 미리 경험해보고 다양한 경우에 대한 설계 노하우를 갖고 조언할 수 있어야 한다. 

 

이렇게 전문가로 가는 길을 방해하는 것은 국내의 잘못된 개발문화 때문일 것이다. 하지만 그렇다고 이런 문화에 저항하지 않고서는 전문가의 커리어를 걷기 어렵다. 즉, 빠르게 결과를 전달하는 개발 문화에 순응하여 자기계발을 멈추게 되면 그 개발자는 능숙자에서 발전하지 못하고 정체될 수 밖에 없다. 이렇게 되면 개발자의 슬럼프가 시작되는데 이 단계에서 적성과 다르게 관리자로서의 커리어를 받아들이는 경우를 많이 보았다. 

 

지금 나의 위치는 어디인가?혹시 능숙자에서 성장이 멈추어 있는 자신의 커리어에 대해서 고민하고 있지는 않은가? 그렇다면 조금 더 예술적인 코드를 만드는 것에 투자해 보는 것은 어떨까? 한 예로 DRY(Don’t Repeat Yourself), KISS(Keep It Simple Stupid)와 같은 마인드 셋으로 SOLID와 같은 개발패턴들을 공부해 보는 것이다. 그리고 현업에서 직접 적용해보면서 상황에 따른 장단점들을 연구해보길 추천한다. 아무리 좋은 패턴이라고 하더라도 환경에 따른 다양한 상황 앞에서는 모두 완벽할 수 없기 때문이다.


Zdnet Korea에 기고한 글입니다.

저작자 표시
신고
Posted by 박경훈
IT 이야기2014.10.20 13:12

개인적으로 ZDNET 컬럼으로 기고한 글입니다.


최근 개발자들의 이직률이 여전히 높다라는 조사 결과가 인크루트(Incruit)를 통해 발표됐다. 조사에 따르면 응답자의 40%가 1~2년 마다 회사를 옮긴다고 답했다. 흥미로운 것은 이직 이유에 있다. 이직을 결정하는 가장 큰 이유는 연봉 때문일 것이라고 생각했지만 연봉이라고 답한 개발자들은 20% 정도밖에 되지 않았다. 70%는 자기계발을 위해서 그리고 회사의 불투명한 비전 때문이라고 이직한다고 답했다. 

 

영국 취업 사이트 포털인 잡스에서 발표한 자료를 보면 이직의 이유가 국내와는 많이 다르다. 영국은 개발자들이 이직하는 빈도가 2.7년에 한번 정도일 뿐만 아니라 이직 이유도 연봉이 가장 큰 영향을 미쳤다. 이같은 결과는 아직도 국내 많은 IT 기업들이 개발자들에게 적절한 비전을 제시해주지 못하고 있을 뿐만 아니라 소통도 많이 부족하다는 것을 보여주는 대목이다. 

 

국내 기업의 경우 외형적으로는 어느정도 성장을 이뤄낸 것은 분명하나 선진국의 개발문화는 아직 제대로 흡수하지 못하고 있는 셈이다. 

 

IT업계에선 새로운 개발 트렌드와 플랫폼들이 계속 쏟아져 나온다. 이 때 개발자도 변화만큼의 새로운 무언가를 공부하고 같이 발전하고 있다는 생각이 들지 않으면 자신의 비전에 대한 불안감이 싹틀 수 밖에 없다. 회사에서 중요한 것은 조직과 개인이 함께 성장해 나가는 문화다. 

 

그러려면 회사는 더 이상 일정과 사람중심의 개발문화가 아닌 개발자와 함께 성장할 수 있는 회사 고유의 시스템에 의해 움직여져야 한다. 그 시스템은 바로 회사가 가지고 있는 개발 문화들에 의해서 형성된다. 외국에서는 이미 익숙하지만 국내에서는 아직 도입이 더딘 몇가지 개발 문화들을 살펴보도록 하겠다. 

[Zynga 오피스 풍경]

 

■ 코드 리뷰


국내 개발문화를 보면 대부분 프로젝트 매니저가 개발자들에게 작업들을 전달한다. 개발자들이 일을 완료하면 PM이나 테스터들이 결과에 대한 확인을 요청할뿐 코드를 점검하는 프로세스는 거의 빠져있다. 이렇게 결과 위주의 작업 프로세스로 일을 진행하다가 보면 소프트웨어 품질은 보장하기 어렵다. 어떤 작업을 처리하는데 있어 미래에 몇 가지 기능이 추가될 수 있다는 가정을 가지고 만든 것과 무조건 빠르게 결과를 보여주기 위해서 만든 것은 품질에 차이가 나게 마련이다 

 

이런 문제를 해결하기 위해 필요한 문화가 바로 '코드리뷰' 다. 코드리뷰는 어떤 작업을 시작하기전에 리드 개발자나 아키텍트가 정확한 요구사항을 분석하고 그걸 개발자들에게 전달하면서 시작된다. 전달 과정에서 복잡한 업무나 지시가 필요할 경우 TDD를 이용해 테스트 코드를 아키텍트가 직접 작성하거나 짝 프로그래밍을 통해서 함께 작성한다. 물론 테스트 코드 작업 없이 어떻게 개발하면 좋겠다라는 큰 그림들을 설계들을 정의하여 토론할 수도 있다. 

 

이렇게 개발자에게 전달된 작업은 새로운 작업영역(Branch 같은)에서 진행한다. 해당 작업이 완료됐다고 생각될 때 개발자는 다시 아키텍트에게 소스를 업데이트 해도 되겠느냐는 요청을 보내게 된다. 이것은 git 시스템에서는 풀 리퀘스트(Pulll Request)에 해당된다. 요청을 받은 아키텍트가 코드를 리뷰하고 피드백을 보내거나 문제가 없으면 기존 소스에 그 작업을 반영하게 되는 것이다. 

 

이같은 작업이 가져다 주는 가장 큰 이익은 개발 표준에 따른 일관성을 유지 하기 쉽다는 것이다. 그리고 개발자들은 자신이 만든 코드에 대한 확신을 갖고 잠재적인 버그를 최소한으로 줄일 수 있다. 아키텍트의 피드백을 통해서 많은 설계 및 코딩 능력들을 흡수하는 것도 가능하다. 즉, 코드리뷰 프로세스를 통해서 품질과 개발자들의 개발능력을 증진시킬 수 있는 두 가지 토끼는 잡는 것이 가능하다는 것이다. 

 

국내 개발자들은 이론과 기본기에 많이 약하다는 평가가 많다. 올바르게 코드를 작성하는 것을 공유하고 서로 토론하는 문화 자체가 없다는 것과 무관치 않을 것이다. 

 

요즘은 Bitbucket이나 Github와 같은 프로젝트 관리 툴을 이용하면 이런 개발 환경을 쉽게 설정할 수 있기 때문에 코드리뷰를 위한 프로세스를 도입한 것은 어렵지 않다. 개발 프로세스가 하나 더 추가되어 개발 생산성을 우려할 수도 있지만 잠재적인 버그를 점검하는 과정과 팀에게 공통된 표준을 적용하는데 따른 이익을 생각한다면 당장 눈에 보이는 빠른 성과보다 값진 작업일 것이다. 

 

■테스트 자동화 


TDD를 통해서 유닛 테스트를 작성하면 좋은 소프트웨어 품질을 유지할 수 있다는 것은 이미 많은 사례들을 통해서 검증되었다. 하지만 모든 유닛별로 테스트 코드를 생산한다는 것은 많은 손 코딩을 필요로 하다보니, 생산성과 효율 관련해 많은 논란이 있는 것도 사실이다. TDD가 익숙한 개발자들은 생산성에 큰 문제가 없다고 볼 수 있다. 그러나 TDD에 모든 개발자가 익숙한 건 아니다. 

 

영국의 경우 SW개발 회사들은 대부분 TDD개발 방법론을 사용한다. 이게 가능한 것은 모두가 100% 코드 커버리지를 갖는 유닛테스트를 작성하는 것이 아니기 때문이다. 예민하고 필수적인 프로그래밍 로직은 당연히 각 유닛별로 테스트 코드를 작성하지만 그렇지 않은 경우에는 여러 유닛들을 묶어서 최종 결과를 확인하는 통합 테스트 코드만 작성하는 경우가 많다. 

 

국내의 경우 아직도 자동화된 코드를 이용해서 소프트웨어를 테스트하기 보다는 테스트 그룹이나 고객이 만든 제품을 사용해보면서 테스트를 진행하는 경우가 많다. 하지만 자동화 된 테스트 코드 없이 사람에 의존하다 보면 작은 수정에도 모든 기능을 테스트 해야 하는 비효율이 발생한다. 

 

소프트웨어 품질에서 중요한 것중 하나는 새로운 기능을 추가하거나 수정할 때마다 계속 그 코드들의 구조를 수정하는 리팩토링 작업이 수반되어야 한다는 것이다. 하지만 자동화된 테스트가 없을 경우 코드 구조를 바꾸면 다른 작업에도 영향을 주어 버그를 만들어 낼 수 있다는 가능성 때문에 혹은 다시 모든 기능을 테스트 해야한다는 번거로움 때문에 리팩토링에 소극적이게 마련이다. 

 

이러한 시나리오 때문에 리팩토링과 개발자가 멀어지면 자신의 코드에 대한 자부심이 떨어질 수 있다. 때문에 불필요한 테스트 작업을 자동화시킴으로써, 개발자가 자신의 코드 품질에 조금 더 집중할 수 있는 환경을 만들어 주는 것이 중요하다. 

 

■ 코드 워크샵


코드 워크샵은 1~2주에 한번씩 개발 팀이 모여 진행하는 미팅으로 한 명씩 돌아가며 일하면서 자신이 새롭게 알게 된 지식들이나 작업을 하면서 생겼던 이슈들을 짧게 공유하는 시간이다. 한 사람당 길어야 1~2분 정도 공유할 내용을 준비한다. 형식은 PPT 1~2장을 짜리 자료일 수도 있고, 코드를 보여주기도 한다. 

 

이 미팅은 무조건 새로운 것만을 공유하면서 지식을 전달하는 세미나 같은 자리가 되어서는 안 된다. 이 미팅의 목적은 2주 동안 개인 입장에서 새롭게 알게 된 것을 공유함으로써 각자 배우고 성장하고 있는지를 점검할 수 있게 하는 것에 있다. 그러면서 자연스럽게 자신이 알고 있는 지식들을 나누고 토론할 수 있는 문화로 발전해 나갈 수 있는 것이다. 

 

토론과 공유 문화가 부족한 한국 개발 환경에 반드시 필요한 문화라고 생각한다. 개발자들에게는 이런 토론과 공유를 통해서 무언가 계속 배우고 습득하고 있다는 느낌을 전달해 줄 수 있다. 그리고 2주에 한번씩 자신이 배운 것들을 되짚어 본다는 점에서도 큰 도움이 될 것이다. 

 

■ 짧은 개발주기

한국에서 고객 혹은 어떤 제품을 기획하는 기획자라고 한다면 요구사항을 정리해서 전달해주는 것이 자신의 업무라고 생각하는 경우가 많다. 하지만 자신이 원하는 것에 가장 가까운 제품을 만들기 위해서는 짧은 개발주기를 반복함과 동시에 끊임없는 커뮤니케이션을 통해서 제품을 만들어 나가야 한다. 

 

이게 개발자들에게 중요한 건 개발자들에게는 자신의 작업을 리뷰하고 팀들과 소통할 수 있는 주기가 필요하기 때문이다. 그 주기 없이 긴 일정속에서 개발만 하다 보면 결국 팀원들과의 소통보다는 어떻게든 자신에게 할당된 일에만 몰두하게 된다. 

 

어떤 짧은 목표를 팀원들과 함께 해결하기 위한 과제가 부여되지 않는다면 그들은 소통해야 할 이유가 갖게 못하게 된다. 당연히 서로 지식을 나누고 공유하는 문화와도 자연스럽게 멀어질 것이다. 

 
■ 정리


개발 회사에서는 회사의 비전과 더불어 개발자들이 숨쉬며 소통할 수 있는 문화들을 제공해 줄 필요가 있다. 개발자들의 의욕을 고취시키고 또 회사와 같이 성장시키기 위해서는 좋은 품질의 소프트웨어를 개발할 수 있는 환경을 만들어 주는 것이 중요하다. 또 개발자들끼리의 지식나눔 문화를 통해서 새로운 지식들을 끊임없이 배우게 해야 한다. 

 

개발자들의 생각도 변할 필요도 있다. 예를 들어 이어폰을 끼고 독립된 공간에서 폐쇄적으로 개발에만 집중하는 것보다는 팀들과 소통하려는 자세가 필요하고 또 다른 사람이 작성한 코드라고 하더라도 같이 주인의식을 갖는 공동체 의식도 필요하다. 

 

개발자들의 토론문화도 보다 성숙해질 필요가 있다. 국내의 주입식 교육 환경의 영향으로 내가 듣고 생각하는 것이 틀릴 수 있다는 것을 인정하는 것이 익숙하지 않은 것은 사실이다. 하지만 누구나 다른 생각을 가질 수 있는 것이 당연한 것인데 그것에 적대감을 가지거나 자신이 잘못된 것을 쉽게 인정하지 못하는 성향은 버리는 것이 좋다. 그래야 팀과 같이 성장하는 것이 가능하다. 

 

개발자들이 먼저 의식을 바꾸고 새로운 문화를 맞이할 준비가 되지 않으면 소수 매니저들이 주도하는 노력만으로는 좋은 결과를 맺기 어렵다.

저작자 표시
신고
Posted by 박경훈
IT 이야기2014.06.04 18:04

I just share the slide xp anti-practice which I summarized from a Japanese community. 



Agile - XP anti-practice

저작자 표시
신고
Posted by 박경훈
IT 이야기2013.08.21 11:04

아직도 개발자 고민 토론방에서는 자신의 실력과 진로에 대해서 많은 고민들이 오고 간다.

그 고민들 중에서 최근에 자주 올라오는 질문을 보자면,,
아직도 많이 모르고 어려운데 상사가 없다며 혹은 어떤 사람은 상사가 있어도
잘 안가르켜 준다고 만들어 내라는데 못할것 같고 뭐 그런 내용들이 생각보다 많다.


같은 내용을 자주 답변을 달다 보니 한번 블로그로 정리해 본다.
먼저, 혼자서 프로젝트를 진행하는 것을 두려워 하는 개발자를 주니어 개발자라고 하겠다.

그 주니어 개발자들 중에서 잘못된 접근들이 있는데 그 중에 하나가
상사가 많은 것을 해결해주고 풀어 줄 수 있는 키라고 생각한다는 것이다.


물론, 심성이 착하고 가르켜주것을 너무 좋아하는 그런 상사를
만나서 하나하나 열심히 챙겨줄 수도 있겠지만,
보다 지혜로운 상사는 어떻게 문제를 해결하는지를 갈켜주는 상사이다.

우리는 상사가 없어도 수많은 이슈들이 이미 구글로 커넥팅되어 있고
검색어를 어떻게 입력해서 어디서 어떻게 찾아야 할지만 익숙해지면 된다.

필자의 경우도 그랬다. 2002년 처음 회사 생활을 했을 때가 정확히 기억이 난다.
T-SQL 문법이 익숙하지 않아서 상사에게 이러한 상황에서의 예제가 없냐고 물어보면
엉뚱하게 도움말을 열어서 이렇게 찾아라 라고 알려주시고는 했다.
그때는 저걸 그냥 가르켜주면 되지 왜 이렇게 시간 걸리게 찾으라고 하는 것인지
그 당시의 그 상황에서는 이해가 어려웠다.

하지만 나중에 생각해보면 참 감사한 상사였다.
그 상사는 어떻게 문제를 해결해 나가는 지에 학습을 시켜준 것이었다.

즉, 상사와 계속 같이 일하면 그만큼 자신의 케이스에 따라서 많은 것들을 배울 수 있겠지만
그와 마찬가지로 혼자서 일했을때 또한 굉장히 많은 것들을 부딛치면서 얻게 된다.

그렇다면 일단, 케이스 대로 생각해보자.

Case1. 난 도저히 어디서 시작해야 할지 모른다.
혼자 프로젝트를 맡게 되었다. 기획서대로 만들어 달라는 것이다.
그런데 어디서 어떻게 시작해야 할지 모르는 경우이다.
뭐 이유는 정말 부족한 신입개발자이거나 주력이 아닌 처음 접하는 플랫폼이라서 그럴 수도있다.

정말 이 프로젝트 플랫폼에 대한 지식이 없는 경우인데
이 경우라면 프로그래밍 참고서를 보는 것이 빠르다.
아니면 동영상 강좌를 보면서 따라해보는 것도 좋다.

필자도 닷넷 프로그래밍이 주력이었지만 아이폰을 개발할때 먼저 책을 보면서
어떻게 접근하고 어플리케이션이 만들어지는지를 살펴봤다.

아무튼 이 부분은 굉장히 기초가 부족한 부분인데
동영상강좌를 보면서 같이 만들어 보거나 프로그래밍 참고서를 보면서 먼저
가상으로 체험해 보는 것이 좋다.

Case2. 책보고 따라는 했는데 맞는건지도 모르고 불안하다. 
그럴수 있다. 필자도 처음 프로젝트에서 그랬다.
완성이라고 주고 프로젝트를 테스트 하는데 여기저기 에러가 나는 것이었다.
그렇기 때문에 불안한 만큼 테스트 기간을 최대한 많이 가져야 한다.

이때 물론, 책이 정석일 수는 있지만 실무에서는 더 많은 트릭들이 존재하기 나름이다.
예를 들면 DB연결이나 인터넷 커넥션을 오픈소프 컴포넌트를 사용하는 것들 말이다.

이런 경우에는 커뮤니티를 통해서 네트워킹이 필요하다.
주변에 자신보다 더 뛰어난 개발자들이 없으면 실력은 늘수가 없다.
즉, 이 분야에서 일하는 사람 한두명만 만나도 자신의 소스나 방법들을 충분히 나눌 수 있다.
오프라인 미팅이 어려우면 자신의 케이스를 질의하거나 비슷한 케이스를 구글신에게 빌어보면 된다. 

Case3. 책이 말하고 있지 않는 이슈들이 터졌을때
대부분의 참고서들은 책은 A부터 Z까지 차례대로 나열한다.
각각의 알파벳들을 활용해서 단어를 만들거나 하는 것은 대부분 개발자의 몫인 샘이다.
역시나 이 경우에는 당황할 수밖에 없다.

플랫폼이 지원하고 있지 않는 것들은 꼼수와 같은 트릭을 이용해서 해결해야할 경우가 많다.
이 트릭들은 인터넷에 역시나 존재한다.
내가 만난 대부분의 이슈들은 전세계의 개발자들도 충분히 만나는 이슈들이다.

필자의 경험으로는 99%가 그렇다.(단, 어느정도 개발자의 파이가 있다면)
필자가 검색을 해서 관련된 질문조차가 없으면 한참을 잘못 온 것이라고 해석한다.
정말 작은 실수를 한 것이라서 질문할 가치가 없는 것들이라고 생각하고 다시한번
코드나 문제를 살펴보면 해결한 경우가 많다.

아무튼 이러한 경우에 필요한 것은 구글 검색에 의존해서 해결할 수 있어야 한다.
먼저 에러 메세지를 검색하면 정말 쉽게 찾을 수 있다.

에러 메세지가 아니라 지금 상황이 A와B를 이용해서 D를 만들어야 하는데
지금은 C밖에 만들지 못하고 있는 상황이라면 A,B,D의 검색어들을
조합해서 각각의 키워드로 검색을 시도해야 한다.

물론, 한국어 리소스도 충분히 많다.
어떤 사람은 번역 사이트를 이용해서 일본 웹사이트를 검색하는 사람도 있었다.
또한, 기술 영어는 크게 어렵지 않기 때문에 쉽게 검색할 수 있을 것이라고 생각하고,
영어가 어려워도 간단한 리딩 스킬 정도는 개발자들이 가지고 있어야 할 능력이다.

저작자 표시
신고
Posted by 박경훈
IT 이야기2013.08.17 10:15

한국은 모르겠지만 영국에서는 루비온레일스가 참 잘팔린다.
지난 번 스타트업 페어를 갔다와서 그 인기를 다시 한번 실감했다.

그렇게 보면 스타트업에게는 더할나위 없이 좋은 옵션은 분명하다.
가볍고 생산성 빠르고 서버 싸고, 심플하고 거기에 몽고DB 같은 noSQL도 붙여주면 금상첨화
(물론, 은행 Backend나 그룹웨어처럼 복잡한 시스템이라면 자바나 닷넷이겠지만,,)

아무래도 성공요인은 개발 컨셉을 정말 잘 잡은 것 같다.
웹 시스템의 80%는 DB넣고 뿌리는거 아닌가?
이 부분에 대한 가려움을 정말 잘 긁은 케이스 같다.
거기에다가 크로스 플랫폼이니 뽀대나게 iMac 27인치 하나 두고 심플하게 개발하면
얼마나 좋을까? (ActiveX 안쓰고 살아서 그런지 윈도우 보다 맥이 더 편한건 사실이다)

가려움을 잘 긁어주는 것에 둘째가라면 서러워 할 기업이 떠오른다. 아마도 존?(아마존-_-;)
아이패드가 높은 가격으로 밀어붙이니 킨들파이어를 헐값에 딜하고
구글 앱스토어가 양으로 밀어붙이니 킨들 스토어는 퀄리티로 밀어붙이고
(뭐 여튼 이야기 새지 말고 -_-;)

닷넷의 ASP.NET MVC의 경우도 물론, 
Razor + LINQ + Entity Framework 정도를 사용해서 데이터처리에 대한
부분을 조금 더 쉽게 딜할 수 있을지 모르겠지만
뭐랄가 아직도 서버단이 무겁고 복잡한 기분이다.

윈도우 플랫폼에서도 아니 이왕 크로스 플랫폼으로 ASP.NET MVC Light
정도로 해서 가볍고 심플한 프로젝트로 나와주면 어떨까 생각해본다.
IIS도 IIS for Linux 형식으로 배치시켜 주면서 말이다.

그러면서 필요한 것만(엔티티프레임워크, LINQ등) 기본셋이 되어 있는 것이다.
DB연결하면 반자동으로 클래스들 매칭 시키고 (자동 되면 안씀-_-)

아무튼 다음 프로젝트는 루비 온 레일스 + MongoDB로 해볼까 하다가
잠깐 잡념에 빠져봤다.

저작자 표시
신고
Posted by 박경훈
IT 이야기2012.08.06 14:10

- 하드웨어 완제품을 만들어 돈을 버는 애플
- 광고로 돈을 버는 구글
- 컨텐츠로 돈을 버는 아마존
- 소프트웨어 판매로 돈을 버는 마이크로소프트



아이패드
애플의 아이패드는 일찍이 태블릿 시장에 나서서 저만치 가고 있다. 처음 아이패드를 가지고 나와 발표를 하던 그 당시 그냥 아이폰이 커졌구나 정도로만 예상을 했었지 아무도 태블릿 시장에서의 태동을 예상하지 못했다. 하지만 지금은 태블릿 시장에서 약 70% 넘게 아이패드가 시장을 잡고 있을 정도로 거의 독무대를 달려왔다.


킨들 파이어
아마존은 방대한 컨텐츠를 가지고 있다. 아마존의 킨들 파이어는 당시 정말 파격적인 가격을 제공하여 태블릿 기기의 판매 수익보다 방대한 아마존의 컨텐츠를 이용한 수익을 노리는 효과로 지금 한국을 제외한 해외시장을 초토화 시켰다고 해도 과언이 아니다.


넥서스7
이걸 보고만 있을 구글도 아니다. 킨들파이어 보다 조금 더 파격적인 가격의 넥서스7을 출시하였고, 출시하자마 지금 물량이 없어서 못파는 사태가 되었다. 이 넥서스7의 가격은 그동안 공생과 개방을 강조해오던 신념과 달리 정말 사할을 건 출사표라고 할 수 있다. 이런 무리수를 통하여 구글은 테블릿 확산을 통해서 광고 수익을 조금 더 높이고, 또한 구글플레이를 통한 컨텐츠 판매를 기대하면서 테블릿 시장을 선점하려고 하고 있다.


서피스
이제 남은 것은 마이크로소프트의 서피스의 출시가 남았다. 윈폰때와 같이 출시일이 늦은감이 없지 않아 있다. 아직 가격이 발표되지 않았기 때문에 어떤 전략으로 시장에 출사표를 던질지가 궁금한 상황이다. 사실 수익 부분에서 어떻게 그림을 그려나갈지 모르는 상황에서 지금 MS가 강조할 수 있는 부분은 바로 윈도우 운영체제와 연계할 수 있는 하이브리드 기능 정도라고 할 수 있을 것 같다. 이 경우에 인텔 CPU를 이용하기 때문에 많은 발열과 PC가 무거워질 수 밖에 없는 딜레마가 있기 때문에 실제로 승부수는 암계열의 PC가 될 것이라고 예측해본다. 음, 아이패드도 솔직히 처음 이용했을 때 앱이 별로 없다는 느낌을 지울 수 없었는데 사용자들에게 어떻게 어필해 나갈 수 있을지는 조금더 지켜봐야 할 것 같다.



다음 그림은 http://visualign.wordpress.com/2012/02/06/side-by-side-apple-microsoft-google-amazon/ 에서 발췌한 자료로 위 4개의 회사(마이크로소프트 vs 애플 vs 아마존 vs 구글의 수익)별로 수익 비중과 현재 매출 등을 보여주고 있다.


네개의 회사별로 수익구조를 보여주고 있습니다.



빨간 영역은 회사가치 즉, 시가총액을 나타내고, 파란영역은 매출, 그리고 연두색 영역은 순수 매출입니다.



신고
Posted by 박경훈
IT 이야기2011.09.27 23:10
IT 이야기2011.01.18 19:14

다음 글은 마소에 기고한 원고(모바일 글로벌 서비스 도전일기) 내용 중 한 단락을 발췌한 것입니다.



먼저 IT벤처라고 한다면 꿈과 열정이라는 단어들이 먼저 상징적으로 들려온다. 하지만 성공으로 가기 위해서는 보다 냉철한 통찰력과 함께 상황에 맞는 최선의 결정을 내릴 수 있는 냉정한 가슴을 품어야만 하는 것이 현실이다. 그럼 IT 벤처라는 환상의 굴레를 벗어나 진정한 현실에 대한 오해와 진실들을 한번 살펴보도록 하겠다.


1. 벤처는 재미있다. 돈을 직장인보다 더 많이 벌 수 있다?

먼저 상당수의 개발자들은 “자기회사”와 “자기일”에 대한 동경을 가지고 있다. “자기일”을 시작하게 되면 즐겁게 일할 수 있을 것이라는 생각과 동시에 큰 돈을 벌 수 있다는 착각이 있는 것이다. 하지만 가장 중요한 사실은 창업을 하게 된 순간 하고 싶은 일보다는 해야만 하는 일이 압도적으로 많다는 것이다. 때문에 창업이라고해서 항상 재미있다고는 할 수는 없다. 

그리고 창업을 시작함과 동시에는 돈을 모을 생각은 버려야 한다. 벤처는 “도전” 이라는 말의 근원이 되듯이 자신의 모든 것을 걸어 모험을 하는 직업이다. 더군다나 통계상 성공확률이 가장 낮은 분야가 바로 IT 분야로 나타나고 있다. 닷컴 버블 시대부터 수많은 아이디어들과 서비스들이 사람들의 이목을 잠깐 끌었다가도 금방 사라져갔다. 즉, 실생활에 유용한 서비스를 만드는 것에는 성공했을지 몰라도 그것을 수익모델과 연결하는 부분에서 실패해버리고 만 것이다. 그런 생각들을 해봤을 것이다. "왜 이런 서비스는 없는거지? 정말 대박 날것 같은데?" 이유는 간단하다. 정말 좋은 서비스라고 하더라도 그 서비스가 비지니스 모델로 이어지기 힘든 경우가 많기 때문인것이다.

2. 경쟁자는 생각보다 두렵다?

알고보면 경쟁자는 생각보다 두려운 존재가 아니다. 경쟁자들을 분석하다 보면 다른 목표와 다른 지향점을 가지고 있기 마련이다. 필자가 AppCookr라는 서비스를 오픈할 때만 하더라도 굉장히 많은 경쟁자가 있다는 것을 깨닫고 많은 좌절을 가지기도 했다. 하지만 실제로 경쟁자들의 서비스를 비교해보고 분석해보면서 정말 경쟁자라고 할 수 있는 곳은 많아야 한두 군데 밖에 되지 않았다. 오히려 강력한 경쟁자가 많을수록 우리에게는 연구하고 분석할 수 있는 기회가 생기는 것이므로 오히려 고마워해야 한다. 우리나라는 1등이 있으면 어떻게든 그 1등을 끌어내리려는 문화가 팽배하다. 하지만 오히려 1등의 존재를 통해 2,3등의 수준도 끌어올릴 수 있는 것이다.

그리고 가장 중요한 것은 보이는 것이 다가 아니라는 것이다. 굉장한 찬사를 받고 있다 하더라도 과대선전이 난무한다는 것이다. 때문에 신경써야 할 것은 그런 기사들과 선전에 휘둘리는 것이 아닌 냉철한 통찰력을 가지고 컨텍스트에 맞는 상황분석이 필요하다.


3. 수치가 모든 것일까?

수치는 서비스의 비전과 가설을 객관적으로 증명해주는 자료이다. 수치가 거짓말을 하고 있는 것처럼 느껴진다면 그 이면에는 우리가 알아내지 못한 것들을 존재한다는 뜻이다. 무엇보다도 재무와 회사 운영에 있어서는 수치화가 더욱더 중요하다. 우리의 방향이 올바른지 판단할 수 있게 해주는 유일한 잣대이기 때문이다. 때문에 경영자는 항상 모든 것을 수치화해야 하며 수치를 근거로 항상 1년 뒤를 바라볼 수 있어야 한다.


4. 서비스의 확장이 중요한가?

서비스의 확장 보다 중요한 것이 있다. 바로 비즈니스의 확장이다. 예를 들어 “대용량 서비스 기술”이나 “서버 스케일링” 등과 같은 기술을 확장하는 것보다 새로운 비즈니스 모델로의 확장이 우선순위가 되어야 한다는 것이다. 멋진 기술과 화려한 기술을 제공해 줄 수 있다고 하더라도 비즈니스와 연결이 힘든 확장은 크게 도움이 되지 않는다.


5. 변화보다는 지속이 중요한가?

때로는 “변화”가 “지속” 보다 더 중요하다. 물론, 장기적인 사고방식과 방향설계가 중요한 것이 사실이고 목표를 이루는 것이 생각보다 오래 걸리는 것도 사실이다. 하지만 서비스와 조직이 함께 성장하게 되면 비즈니스와 관련된 업무도 증가하게 되고 의도와 다르게 R&R(역할과 원칙)도 변하기 마련이다. 때문에 기업의 비전과 사명도 변할 수 있는 가능성은 언제나 열어두어야 하며 현실을 보다 냉정하게 판단하여 민첩하게 대응해 나갈 수 있는 자세가 필요하다.


6. 서비스는 무조건 빨리 출시해야 할까?

IT쪽의 서비스는 무엇보다 “선점”이 상당히 중요하고 또, 어떤 시기에 누가 먼저 자리를 잡느냐에 따라 사업의 성패가 좌우되는 것은 사실이다. 그렇기 때문에 모든 서비스를 빨리 출시한다기 보다는 핵심만 갖춘 안정적인 서비스를 최대한 빨리 출시하는 것이 최선이라 할 수 있다. 이 부분에 대한 의견은 엔지니어와 경영자 사이에서 빈번하게 부딪치게 되는 문제이다. 이 문제를 예방하기 위해서는 기획단계에서 너무 기능에 대한 욕심을 과감히 버려야 하고 개발자 또한 완벽한 설계와 구조에 대한 포기가 어느 정도 필요하다.

신고
Posted by 박경훈
IT 이야기2010.12.21 19:24

해외진출을 위한 스마트 앱 글로벌UX 디자인 전략

(연세대학교 정보대학원 – 디지털 컨텐츠트랙 최준오)


UX
전략 + 글로벌(문화적인 요소)

1. 문화를 정확하게 파악해야 하는 것이 첫 번째 요소

- 물건을 사게 될 경우

미국: 설명서와 박스를 간직한다.

이태리: 물건만 꺼내고 버린다.

독일: 매뉴얼을 다 읽어보고 버릴 때 차곡차곡 버린다.

인도: 박스 안내문까지 다 읽어본다.

중국: 매뉴얼을 보지만 절대 본 티를 내지 않는다.

 

문화 + Localization

 

UPA코리아 인터뷰 중

- 실력에서는 뒤떨어지지 않지만 UI부분에서 항상 실패를 당한다.

 

문화별 유저 경험 특성: 미국의 경우

: 기능이 복잡하고 작동 단계가 많은 것 보다 Simple한 작동방식을 좋아함

: SNS, E-mail의 사용 빈도가 높다.

: Wifi 환경이 보편화 되어있음

: SMS, Email에 대한 답장을 빨리 해줘야 한다는 의식이 강함(늦게 보내면 무시 당하는 느낌)

: 아이폰을 스마트폰 표준으로 인식하고 있으나, 유행에 민감하지 않고 개인주의 속성 강함 (앱을 만들어도 차별화할 수 있는 전략 필요)

: 위젯과 애플리케이션간의 개념적 구분이 약함

: 스마트폰을 오락용으로 사용하는 욕구가 많음, 데모버전 게임에 대한 불만 강함

 

UI 사용성 평가사례 (미국)

텍스트 인풋 피드백: 터치 스크린 입력시 소리, 진동 등이 약하다고 느낌(좀 더 강한 이펙트를 원함)

 

미국, 유럽 애플리케이션 평가 사례

-       발표자료 참고

 

스크린 넘어갈 때의 전환속도 선호파악

: 각 국가별로 속도 선호도가 다름(발표자료 참고)

 

Emerging Mobile Trend 세션

(게임 빌)

 

스마트폰 시장으로 진입장벽이 가장 낮아졌다.

하루에 50만명씩 가입자가 늘어나고 있다.

 

얼마를 벌 수 있을까?

앵그리버드(안드로이드 무료) – 광고로 벌어 드리는 돈이 1M$

 

어떻게 하면 좋은 앱을 만들어 팔 수 있을까?

1. 공부를 먼저 해야한다. (마켓 사이즈, 타겟 마켓, 타겟 소비자,

 

앱스토어에서 돈을 가장 많이 버는 게임 순위 20위개 중에 10개는 무료앱이었다.

è  WHY? HOW? 광고 시장을 이용

 

예전에는 당연히 유료 게임이었지만 요즘은 무료 게임 시장이 꽤 확장되어 가고 있다.

è  실제로 무료로 통한 수익이 더 많이 나타나고 있다.

 

가장 좋은 게임은 – Localization 없이 직관적인 UI를 가지고 있는 것이다.(앵그리 버드 처럼)

: 광고, 부분유료화, 유료화 각각의 특징이 다르므로 적합한 수익화 방법을 고민해서 적용

 

무료 마케팅 툴을 적극활용하자.

: 소셜 플랫폼, 애플의 게임센터, 트위터, Scoreloop, papaya, plus+

 

일본 스마트폰 진출 방향

 

일본

: 일본에서의 모바일 관련 시장 규모가 5년 앞서 있고, 모바일 인터넷 사용률이 더 높음

 

스마트폰 비율 17%, 아이폰 - 70% (소프트뱅크에서 밀고 있어서 가파른 성장을 보이고 있음)

안드로이드 점유율이 2003년에는 역전될 예정

 

 

선진국과 우리나라의 앱 차별화 전략

(포엠데이터 대표이사 자상철)

 

앱은 8년 전부터 있었던 개념이었다.

è  포엠데이터의 모기퇴치 앱은 8년 전부터 개발했고, 피쳐폰에서 200만 건이 다운로드 되었다. 외국에서도 팔렸고, 17개국에 수출하였다. 애플리케이션 자체가 MBC에도 나오고 CNN등 각지에서 활용되었다. 그 뒤에 여러 프로바이더들로부터 수출제안을 받았다.

 

안드로이드는 검증이 제도가 없기 때문에 지금 모기퇴치 애플리케이션이 10개 이상이 올라와있다. 우리는 임상실험을 통과하여 인정받은 앱인데 반해 다른 곳에서 올리는 앱들은 전혀 고려하지 않는다. 수출을 위해서는 실제 현지 모기와의 주파수 테스트가 중요하다.

 

다음 제품으로 스마트 비아그라를 출시하였다. 비아그라의 원인은 뇌를 자극하여 호르몬을 분비를 촉진시키는 것인데, 이번에서 임상실험을 통해서 이것을 증명하였다. , 실험이 가장 중요한 것이다.

 

안드로이드가 급성장하고 있지만 외국에서는 그래도 스마트폰 하면 아직은 아이폰이 대세임

외국에서는 나이에 상관없이 아이폰 개발을 공부해서 올리고 있는 실정

아이폰은 앱 품질검사를 해주기 때문에 안드로이드보다 더 선호하는 편

아이폰은 70%가 유료어플, 안드로이드는 35% 정도가 유료어플

1인당 스마트폰 트래픽 사용률이 한국이 굉장히 높음

해외 앱 – 재미 + 호기심을 줄 수 있게..

신고
Posted by 박경훈
IT 이야기2010.08.25 21:35

앱스토어에 등록은 Seller나 Company 이름은 한번 등록 하면 절대,절대 변경이 불가능하다.
이 정보는 첫 애플리케이션을 등록할때 설정할 수 있다.


Where do I set my company name that displays in the App Store and can I change that information once it is set?
Your company name is set by you when you upload your first app in iTunes Connect. This is part of your default settings and applies to all applications delivered through your account. The company name is also referred to as your artist name because this name displays on the App Store to organize all of your applications onto one product page. This allows App Store customers to view your entire catalog of apps in one location.

Your company name should be your legal entity name as contracted with the iPhone Developer Program. Once you enter your company name in iTunes Connect, it cannot be changed at a later date. This is a permanent setting.

신고
Posted by 박경훈
IT 이야기2010.08.16 05:40
HOONS 가 기고간 정부를 향한 개발자의 제언 글 이란 컬럼이 주간지에 실렸습니다. (^^;)







 


최근 이명박 대통령의 “IT를 책임질 대통령이 되겠다”는 반가운 발언과 함께 정부의 ‘IT 코리아 5대 미래전략’이 발표됐다. 2013년까지 총 사업비 14조1천억원을 투자하고 그중 가장 많은(28퍼센트) 4조4천억원을 소프트웨어에 투자한다고 했지만, 아직 구체성과 현실성의 부재 때문인지 소프트웨어 업계의 반응은 생각보다 조용하다. 발표 내용 중에는 글로벌 수준의 소프트웨어 기업 육성을 위해 소프트웨어 장학생을 선발해 차세대 소프트웨어 리더를 양성하고 소프트웨어 공학센터를 설립하겠다는 것도 있지만, 그보다는 IT 기술자로서의 비전을 제시할 수 있는 환경을 조성하는 것이 더 시급하지 않을까 생각된다.
 


‘이공계 기피현상’. 낯설지 않은 말이다. 현재 한국에서 이공계의 주가는 갈수록 하향세를 그리고 있다. 특히 컴퓨터공학과 분야는 더욱 암울한 실정이다. 많은 학생들이 전과(轉科)를 준비하거나 복수전공을 통해 다른 돌파구를 찾으려고 한다. 대한민국에서 소프트웨어 기술자로서의 비전이 밝지 않다는 사실을 선배나 미디어를 통해 충분히 알고 있기 때문이다.
 


대한민국 앞에는 항상 ‘IT강국’이라는 수식어가 붙는다. 하지만 그 말이 맞는지는 검증해봐야 한다. 무엇보다도 소프트웨어 분야의 침체가 결정적 이유다.
 


소프트웨어 분야는 모든 IT 분야의 혼이 되는 기술임에도 계속 쇠퇴하고 있을 뿐더러, 3D로 치부될 정도로 개발자들이 점점 기피하고 있는 분야이기도 하다. 하지만 소프트웨어 분야의 성공 없이는 IT강국으로 올라서기 힘든 것이 엄연한 현실이다. 미국 실리콘밸리에서도 중요한 사업은 하드웨어인 실리콘이 아닌 소프트웨어 분야다. 소프트웨어 분야는 무에서 유를 창조하는 일명 ‘논 제로 섬(Non-Zero-Sum)’산업에 가장 가깝기 때문이다.
 


보통 한국 개발자들의 정년은 30대 후반에서 40대 초반이다. 하지만 실리콘밸리나 다른 유럽 국가들에서는 백발의 개발자들도 흔히 볼 수 있다. 이는 한국 IT 기술자들의 삶이 얼마나 어렵고 힘든지, 처우 개선이 얼마나 시급한지를 보여주는 방증이다. 우리나라 소프트웨어 사업 중 90퍼센트 이상은 시스템 통합(SI·System Integration:기업이 필요로 하는 정보시스템에 관한 기획에서부터 개발과 구축, 나아가서는 운영까지의 모든 서비스를 제공하는 일) 사업이 주를 이루고 있는데, SI 분야에서 초·중급 개발자들이 명맥을 유지할 수 있는 길은 자신의 시간과 청춘을 바치는 것이 전부다. 즉, 주말이나 밤 시간을 투자하는 희생 없이는 할 수 없는 일이라고 보면 된다.
 


그렇다고 해서 초과근무수당과 같은 합당한 대우를 받는 것도 아니다. 부문별 편차가 있지만 초·중급 프로그래머는 낮은 대우를 받는 편이다. 하루 10시간 이상의 근무시간과 ‘월화수목금금금’으로 속칭되는 주 6, 7일 근무가 다반사지만 초·중급 개발자의 연봉은 대부분 대기업 생산직 근로자 연봉에도 훨씬 못 미친다. 또한 별도의 야근수당을 지급하는 것도 매우 이례적이다. 이 같은 환경에서 일하고 있는 개발자가 40대까지 버틸 수 있다거나 후배에게 같은 일을 권하는 것은 어불성설이다.

 




 

외환위기를 거치면서 정부는 청년실업에 대한 대안으로 IT 기술자들을 양성해왔으며 정부의 이번 정책에서도 인재 양성 지원책이 여전히 거론되고 있다. 물론 그 덕에 당장의 성과는 낼 수 있겠지만, 그렇게 양성된 개발자는 IT문화의 쓴 고배를 마신 후에 현실을 받아들이며 하나둘씩 업계를 이탈할지도 모른다.
 


이렇게 이탈과 양성이라는 악순환이 반복되기 쉬운 상황에서 인재 양성 지원책은 큰 의미가 없다는 것이 필자의 사견이다. 지금까지 시행한 정부의 인재 양성 지원책은 기업이 고급인력을 찾기보다는 저임금에 마음대로 부릴 수 있는 인력을 선호하게 만들었다. 중급 인력 한 명이 할 수 있는 일을 초급 인력 둘에게 맡기면 된다는 계산인 것이다.
 


이는 젊은 개발자가 청춘을 불사르며 일에 전념할 가능성이 더 높기 때문이기도 하다. 이 때문에 IT 구인 사이트를 뒤져봐도 2, 3년차의 초급 개발자를 원할 뿐 7, 8년 이상 된 중급 개발자를 원하는 예가 드문 것이 현실이다. 그렇게 설 자리를 잃은 일부 중·고급 개발자들은 해외 취업이나 전직을 통해 국내 IT업계를 떠나고 있다. 바로 이것이 한국 소프트웨어의 품질이 바닥을 치고 있는 까닭이자 해외에서 인정받지 못하는 이유다.
 


그렇기 때문에 지금은 더 이상 피해자가 늘지 않도록 국내 개발자들의 처우 개선이 급선무다. 우수한 소프트웨어 개발자가 왜 부족한지에 대한 분석이 필요한 것이다. 그리고 IT 전문가들의 현장 이탈을 어떻게 막을 수 있을지, 어떤 비전을 제시할 수 있을지에 대한 고민이 우선돼야 한다. 사람이 모이는 않는 곳에 비전이 없는 것은 당연한 이치다.
 


정부는 낙후된 소프트웨어를 집중적으로 육성해서 세계 1백대 기업 8개와 매출 1천억원 이상인 소프트웨어 기업 27개를 키우겠다고 발표했다. 하지만 이 제도는 양날의 칼이 될 수 있는 가능성을 가지고 있기 때문에 조심스럽게 정책을 펼칠 필요가 있다. 대기업과 중소기업의 공생이 중요하다는 것은 두말할 나위가 없으며 기업 모두 평등한 기회를 가지고 경쟁에 참여할 수 있어야 한다.
 


지금은 거창한 구호보다는 시행 중인 제도를 검토하고 IT업계의 무수한 폐단들을 바로잡기 위한 정책에 대한 점검이 필요한 시점이다. 선심성 구호에 머무는 것이 아닌, 실질적인 해결책에 초점이 맞춰진 더 지속적이고 일관된 정책이 추진되기를 기대해본다. 

글·박경훈(HOONS닷넷 커뮤니티 대표)

박경훈은 SI 전문가이자 프로그래머로 2002년 IT업계에 입문했다. 마이크로소프트 Visual C#의 MVP에 5년 연속 선정됐으며, 그가 2002년 개설한 HOONS닷넷 커뮤니티는 소프트웨어 개발자들을 대상으로 정기 세미나와 스터디 모임을 진행하고 있다. 저서로 <C# 게임 프로그래밍> 등이 있으며, 영국에 체류 중이다. 



신고
Posted by 박경훈
IT 이야기2010.08.16 05:38

지금까지 기술서적 4권을 번역하면서 가장 어려웠던 책이 바로 이 C# in Depth라는 책이었는데요. 기술적으로나 랭귀지 적으로다 둘 다 상당히 수준이 높았던것같습니다. (_ _);

아무튼 스킷 존 아저씨를 뵈러 아저씨가 일하고 있는 구글에 찾아갔습니다.




왼쪽이 번역서 오른쪽이 원서에요 (^^)
 


제가 들고 있는게 원서구요 오른쪽의 도서가 번역서 입니다. 책에 대문만한 싸인을 받았구요. 
그리고 구글 회사에서 점심을 먹었습니다. 그런데 이럴수가..

이게 진정 회사 직원 식당인지 내가 호텔 부페에 와 있는건지 순간 엄청난 혼란에 뒤싸이더군요.(-_-;) 
아쉽게도 사진은 보안상 허용이 안되서 못찍었지만 예전에 인터넷에서 보던 구글 본사와 여기도 
그렇게 크게 다르지는 않았습니다. (^ ^)



구글 방문증입니다.
신고
Posted by 박경훈