아이패드로 블로깅을 하자.

한달전에 아이패드를 구매하였습니다. 회사를 옮기면서 옮기게 된 회사의 복지에 아이패드 지급이 있어서였는데요. 약 한달이 된 지금 너무나도 잘 활용하고 있습니다.

특히 업무용으로 활용을 활발하게 하는데, 작게는 회의시간에 아아패드를 가져가서 매모를 한다던지 하는 것에서 업무메일 확인이나 일정관리 등에도 활용하고 있습니다.





위 사진과 같이 이 글도 아이패드를 이용하여 쓰고 있는데요. 제가 사용하는 워드프레스라는 블로그 프로그램을 위한 앱이 존재하여 활용하여 글을 작성하고 있습니다.





위와 같이 앱스토어에서 wordpress로 검색하시면 아이패드용을 찾을 수 있습니다. 워드프레스는 설치형 블로그이기 때문에 웹호스팅들을 이용하여 설치해야 하지만 워드프레스 사이트에서 호스팅을 제공하기도 하기 때문에 이를 이용하셔도 됩니다.

이번 글에서는 이미 워드프레스를 설치하여 사용하는 경우를 알아보겠습니다.

일단 앱스토어애서 검색하여 프로그램을 다운 받습니다. 그리고 자신의 블로그를 등록합니다.





프로그램 화면에서 왼쪽상단 My Blog를 선택 후. 나오는 화면에서 +버튼을 눌러 새로운 블로그를 동록합니다. 설치형 블로그의 경우는 가장 하단의 Add self-hosted wordpress blog를 선택하여 본인의 블로그 주소와 관리 계정을 입력합니다.





이후, 입력된 블로그를 선택하면 블로그에 등록된 코맨트나 글들을 살펴볼수 있습니다. 더불어 Post 항목에서 새로운 글을 입력할 수 있습니다.

구글이 나쁜가 삼성이 나쁜가?

계란소년님 블로그(http://eggy.egloos.com/3695302)에서 ZDNet의 Breaking Android: Who is worse, Google or the OEMs? 라는 제목의 기사를 번역한 글을 보았습니다.
여러분들이 답글을 달아주기도 하고 그런데, 제조사에 몸 담았던 입장에서 개인적인 의견을 적어볼까 합니다.

일단, 기사에서는 삼성이나 엘지같은 안드로이드폰 제조사들을 OEMs라고 호칭하던데, OEM은 주문자 상표 부착 방식의 제조방법인데, 왜 그렇게 부르는건지 모르겠네요, 그냥 Android Handset Manufacturer 정도의 호칭이 적합할 듯 한데, 기사 저자의 의견이 있는 것 같습니다.

여튼, 제조사에서 운영체제의 핵심 부분을 수정하는 것은 이미 알려져 있는 사실입니다. 수정하는 이유는 간단합니다. 원하는 방식으로 동작하게 하기 위해서입니다.

그런데, 여기서 원하는 방식이라는게 누가 원하는 방식인지 중요하게 됩니다. 이를 알기 위해서는 휴대폰의 판매 경로를 알아야 하는데요. 휴대폰은 일반적으로 다음과 같은 과정을 거쳐 개발되어 판매됩니다.

1. 제조사에서 제품을 기획한다.


2. 기획안이나 목업폰(Mock-up : 형태만 만든 휴대폰)을 가지고 통신사에 제안을 한다.


3. 통신사에서 구매 의사를 보이면 개발에 착수한다. (개발을 하면서 구매 의사 타진을 하기도 합니다)


4. 휴대폰을 개발 후, 통신사로 납품한다.


5. 통신사는 휴대폰을 소비자에게 판매한다.

물론, Open Market에 판매되는 폰의 경우 제조사에서 통신사의 슈요와 관계없이 시장의 수요를 바탕으로 기획하는 경우도 있고, 전략적으로 혹은 수요를 창출할 계획으로 위 과정과 다르게 진행되는 경우도 있습니다. 하지만, 대부분의 경우 비슷한 과정으로 진행됩니다.

위 과정의 결론은 하나입니다. 제조사에서 휴대폰을 판매하는 대상은 통신사라는 것입니다. 즉, 통신사에서 원하는 기능과 요소들이 구현되어야 실제 판매될 수 있습니다. 그런데 그 통신사에서 원하는 기능이라는 것이 스펙을 벗어나거나 표준에 맞지 않는 경우도 있습니다. 이럴때 제조사의 선택은 가능하면 통신사의 요구사항을 맞춰주는 쪽으로 진행하게 됩니다.

안드로이드 핸드폰을 개발하는 과정에서 진행되는 대부분의 소프트웨어 수정은 이런 과정에서 발생합니다. 안드로이드가 스펙을 모두 구현했다해도 수정이 발생할 수 밖에 없는 이유이지요. 그리고 경우에 따라 제조사 내부의 전략이나 요구사항에 맞추어 변경도 되지만 이런 것들도 궁극적으로는 통신사에서 원하는 사항을 선반영 하는 경우가 많습니다.

제조사에서 핵심 부분을 수정하는것은 위와 같은 원리에서 시작하는 것입니다. 그런데, 기사에서와 같이 수정을 제대로 안해서 문제가 발생하는 것은 말 그대로 제대로 수정을 하지 않아서 입니다. 이건 앞으로 제조사에서 풀어야 할 숙제와도 관련이 있습니다.

안드로이드 핸드폰 개발이 제대로 시작된 것은 2년이 안 됩니다. 그 기간 동안 제조사들에서는 휴대폰을 만들어 내기 위해 버그를 수정하고 기능을 동작하게만 하는데 시간을 보냈을 뿐, 안드로이드에 대한 심도있는 분석이나 구글과의 협업이 거의 없었습니다. 즉, 제조사에서 찾아낸 안드로이드 자체의 문제점들은 대부분 구글에 feedback되지 않았고, 구글도 적극적으로 feedback을 받고자 하는 노력을 하지 않았습니다. 아직 제대로 된 의사소통장치가 없기 때문에 Engineer 레벨에서 공유되는게 거의 없는 상황입니다. 물론 제조사의 사업상의 문제로 공유가 안된 것도 많구요. 이런 과정에서 잘못된 수정이라도 제조사에서 검증이 안되었다면, 해당 문제를 내포한채로 출시가 된다고 할 수 있습니다.

다시 원점으로 돌아가서, 현재의 방식으로 운영한다면, 제조사에서 수정 한 소프트웨어에서 문제가 발생할 수 있는가? 물어본다면, 있다고 밖에 대답할 수 없습니다. 그리고 앞으로도 수정할 것인가에 대한 답변도 그렇다 일것입니다. 통신사와 제조사와의 관계가 존재하는 이상 통신사의 요구사항에 대한 반영은 지속적으로 이루어질 것입니다. MS는 Windows7에서 다른 방식의 정책을 진행하여 이를 해결한 바 있습니다. 통신사의 요구 사항에 대해서 MS가 직접 대응을 한 것이죠. 그런데 구글이 이런 방식으로 해결을 하지는 않을 것으로 보이므로 앞으로 같은 방식으로 개발은 진행될 것입니다.

다만, 안드로이드에는 점점 기존에 구현되지 않았던 기능이나 버그 등이 수정되고 있으므로 지금과 같이 제조사에서 대폭적으로 수정해야 하는 상황이 점점 줄어들 수 있습니다. 더불어 제조사에도 노하우가 쌓이고 전문가들이 증가하면서 수정을 하더라도 문제가 발생하지 않을 가능성이 높아질 것입니다. 하지만, 이 모든 변화들로 인해서 제품의 품질이 높아지고 문제가 줄어들더라도 단순히 사용자입장에서만 생각한 제품은 나오기 힘들 것입니다. 제조사에서 원하는 기능은 앞으로도 탑제될 것이고 통신사에서 원하는 기능들도 지속적으로 탑제될 것입니다.

소비자는 원하는 바를 지속적으로 어필하여 제조사와 통신사에서 변화하도록 해야할텐데 그 변화가 쉬울지는 모르겠습니다.



생각없이 써 내려간 이 글의 결론은 다음과 같이 되겠네요.

앞으로 딱히 많이 변하진 않을 것이고, 기사와 같은 불만이 나오는 건, 둘 다의 잘못이다.

최근의 이야기 : ACM Technews

얼마 전에 ACM에 가입했습니다. CACM 이라는 잡지를 받아보기 위해서였는데요, 가입을 했더니 ACM TechNews라는 메일을 보내오는데, 이게 내용이 쓸만한 게 좀 있더라고요. 막상 CACM은 아직 한 권도 안 왔지만, 메일만으로도 즐겁게 받아서 보고 있습니다.

어제 온 메일을 간단히 살펴보면, 아래와 같습니다. 종종 흥미로운 내용이 있으면 소개하는 시간을 가져보도록 하려고 합니다.


인텔이 층 구조를 이용하는 하는 방법으로 트랜지스터 스피드를 향상 시키다 (3D반도체 이야기지요. 기존에도 이미 레이어를 이용하여 쌓아서 표면적은 줄이고 집적도를 높이는 방법을 사용하고 있었는데, 좀 다른 방식으로 보입니다. 어디 반도체 전공하신 분 설명 좀)

현대의 정보기술을 이용하여 미래를 탐구하다 (컴퓨팅 기술을 이용하여 시뮬레이션을 통한 인류의 미래를 탐구하는 프로젝트에 관한 기사인데요. 앞으로 이런 식으로 대용량 처리를 통한 계산 기술이 많이 사용될 것으로 보입니다)

스마트폰과 타블렛 등을 위한 혁신적인 전자 종이가 보여주는 미래 (전자 종이는 우리 회사에서도 관심을 가지고 지켜보고 있는 소재입니다. 아마도 관련 팀도 있을 거라 생각되는데 출력 장치의 위치를 차지하게 될지 지켜봐야겠네요. 기술의 발전의 속도가 워낙 빨라서 전자 종이의 단점들이 지속적으로 해결되고 있으니 눈여겨 봐도 좋을 것 같습니다.)

생각하지 않는 기계들 : 전문가들에 따르면 인공지능은 다시 시작되어야 한다 (인공지능 연구의 대모 격인 MIT AI연구소에서 진행된 토론에서 지난 몇 십년 간의 인공지능 발전의 장애에 대해서 이야기하고 향후 전망을 이야기 합니다. 실제로 뉴런 네트워크나 유전자 알고리즘 등 현재 사용되는 기술들도 이미 예전에 나온 기술들이고 신기술이나 의미 있는 발전이 거의 보이지 않죠. 향후 현재의 난관을 어떻게 극복할지 궁금하네요)

카네기 멜론 연구소에서 만든 로봇이 신입 컴퓨터 과학자들과 만나다. (작은 로봇을 이용하여 대학 신입생들에게 프로그래밍을 학습하는 연구에 대한 글인 것 같은데요. 마인드스톰이라는 책에 보면 터틀이라는 언어를 이용하여 프로그래밍을 가르치는 방법에 대해서 나오는데, 이에서 아이디어를 얻은 것으로 보입니다)

멀티코어 프로그래밍을 둘러싼 벽들 (멀티코어 프로그래밍은 분명 기존 방식과 다릅니다. 효율을 극대화 하고 문제를 해결하기 위해서는 다양한 기술들이 적용되어야 하는데, 현재 존재하는 방법들 또한 어려움이나 기술적인 문제들이 혼재하고 있는 상황입니다. 하지만 분명 차세대 개발을 위해서는 멀티코어는 필수적입니다.)

HEADLINES AT A GLANCE
• Intel Increases Transistor Speed by Building Upward
• Exploring the Future With Modern Information Technology
• Calling for 2011-12 Computing Innovation Fellows
• Revolutionary New Paper Computer Shows Flexible Future for Smartphones and Tablets
• Unthinking Machines
• Robot Based on Carnegie Mellon Research Engages Novice Computer Scientists
• Top Indian Supercomputer Boots Up at Space Center
• Panel: Wall Ahead in Multicore Programming
• Rearranging the Furniture? Let Software Do It for You
• Leafsnap Combines Biometrics and Botany for Electronic Field Guide
• A Gentle Nudge in the Right Direction
• College Students' Use of Kindle DX Points to E-Reader's Role in Academia
• Chinese Chip Wins Energy-Efficiency Crown

평일 저녁, 후배들과 이야기를 나누다.

최근 진행하고 있는 프로젝트가 한참 막바지라서 간만에 야근 및 특근을 밥 먹듯이 하고 있습니다. 아마도 제가 블로그에 글을 쓰지 못하는 첫번째, 이유가 이것이 아닐까 한데요.

얼마전에 선배와 이야기해서, 대학 동아리 후배들을 위해, 현업 소개를 하는 시간을 만들었습니다. 개발 일정의 한가운대서 어떻게 시간을 내서 학교로 갔는데요. 변명일 수도 있겠지만, 출퇴근 시간이나 짬 날 때, 휴대폰으로 발표 내용을 만들어서 준비한 발표의 2/3정도 밖에 못하고 왔습니다.

일단, 그 내용을 여기에 올려 놓고, 조금씩 다듬어서 다시 글로 써보려고 합니다.

----
1. 벤처부터 대기업까지 소프트웨어 개발 경험
1.1 벤처기업 : 2008.07 3개월 : 검색엔진 웹 프론트 개발
1.2 중소기업 : 2005.01 9개월 : wipi 플랫폼 개발
1.3 오픈소스 : 2008.03 5개월 : 모인모인 위키 개발
1.4 대기업 : 2009.03 2년 : 휴대폰 usim 모듈 담당 및 시큐리티 담당

2. 나중에 유용하게 쓰이는 것
2.1 전공 수업. PL, Data Structure, Algorithm, Database, OS, Compiler, …
2.1.1 특이한 프로그래밍 언어들을 공부 해보면 좋다. Haskell, Lisp, Python, Erlang, Javascript..
2.1.2 교수님과 친해져 보자. 난 그러지 못해서 아쉬움. 가깝게 여기고 찾아뵙고 물어보고 해야 정말 가까워진다.
2.1.3 쉽다고, 혹은 아는 것 같다고 학교 수업 무시 말고 잘 듣자. 더불어 학점도 잘 받자. 공부의 시작은 겸손이며, 겸손은 앎으로부터 나오고, 자만은 무지로부터 나온다.
2.2 자람이나, 수업에서 발표, 프로젝트
2.2.1 대학교까지는 발표는 선택이었지만, 이후의 삶에서는 발표는 필수이며, 발표 스킬은 평생 동안 활용할 수 있는 무기가 된다. 학회에서 최대한 많은 기회를 가지기 위해서 노력하고, 수업에서도 마찬가지다. 그리고 다양한 발표 기법을 공부하고 실제로 활용해 보자!
2.2.2 Unittest, SVN(or GIT or Mercurial) 등의 도구를 최대한 활용해서 프로젝트를 진행해보라. 현업서도 아직 제대로 쓰고 있지 않지만, 학교에서 적응하고 활용한 경험은 나중에 큰 자산이 된다.
2.2.3 프로젝트를 진행할 때는 활용성에 대해서 항상 생각하고 유용한 프로그램을 만들어야 한다. 가능하면 자신이 직접 사용할 프로그램을 만들어라. 그래야 재미있고, 오랜 기간 진행할 수 있다. 결국 자신의 자산이 된다.
2.3 공모전, 경진대회, 컨퍼런스
2.3.1 공모전 두려워 말고 도전해라. 생각보다 수준이 낮은 경우도 많고, 실패를 통해 배우는 것도 많다. 가능하면 팀을 짜서 도전하고 사람이 없으면 혼자도 괜찮다.
2.3.2 공모전 정보를 얻을 수 있는 사이트들을 참고하여 일정을 잡아보고 하나의 작품으로 여러 공모전을 노릴 수 있는 방법을 생각해 봐라. 소프트웨어 분야는 의외로 중복 출품이 가능하거나 그런 규정이 없는 곳이 많다.
2.3.3 경진대회도 마찬가지다. 실패를 생각 말고 도전부터 해봐라. 그런데 난 경진대회 안 나가봐서 잘 모른다. 스스로 찾아보도록
2.3.4 각종 컨퍼런스들은 대학생 할인 제도들이 존재한다. 저렴하게 고급 경험을 얻을 수 있다. 많이 참여해보고 문제점도 스스로 찾아 봐라.

3. 소프트웨어 개발자로 살아 간다는 것. 여러가지 길
3.1 프로그래머
3.1.1 가장 많이 알고 있는 길, 그리고 인원도 가장 많은 길. 필요한 스킬은 평생 공부할 수 있는 기술. 이를 위해서는 즐겨야 한다. 그리고 즐기기 위해서는 노력을 해야 한다.
3.1.2 나중에 사회에 나가 개발자로 일을 하게 되면, 주변 사람들이 자기 직업을 비관하는 경우를 많이 본다. 프로그래머는 결코 쉬운 길은 아니며, 공부한 지식을 소모하기만 하는 삶을 살게 되면 5년도 안 되어 틀림없이 후회하는 인생을 살게 된다.
3.1.3 후회 없는 프로그래머가 되기 위해서는 끊임 없는 자기 발전과 이를 통해 즐거움을 느껴야 한다.
3.2 품질 엔지니어
3.2.1 잘 모르는 길. 하지만, 현업에서는 프로그래머 다음으로 많은 존재 중 하나.
3.2.2 세부적으로 테스트 엔지니어나 품질 엔지니어, 프로세스 엔지니어 등 다양하게 나뉘며, 소프트웨어의 품질을 높이고 검증하기 위한 다양한 기법들과 지식들을 개발과 유지보수에 적용한다.
3.2.3 개발자중 품질 엔지니어로 가는 경우도 많으며, 소프트웨어 품질에 대한 기업의 관심이 많아지고 있는 최근 들어 더욱 발전하는 추세.
3.3 아키텍처
3.3.1 소프트웨어 설계, 감리 등을 담당하는 업무.
3.3.2 대기업들에는 부분은 아키텍쳐 팀이 따로 존재하며, 많은 인원은 아니다. 프로젝트의 초반에 전체적인 설계를 구상하고, 진행 과정에서 설계를 유지 보수 하면서 프로젝트의 진행을 돕는다.
3.3.3 관련된 다양한 기법들이 존재하나, 소프트웨어 개발 자체가 설계라는 초반 과정이 쉽지 않고, 변경도 많기 때문에 어려움이 많은 분야. 이는 앞으로 발전 가능성도 많은 분야라 볼 수 있다.
3.4 컨설턴트
3.4.1 기업 내부에 컨설팅 팀을 보유하고 있는 경우도 있고, 소프트웨어 컨설팅을 전문으로 하는 업체들도 존재한다.
3.4.2 아키텍처도 일종의 컨설턴트이며, 소프트웨어 개발에서 발생하는 문제점들을 미리 예방하거나 해결하기 위해 도움을 주는 역할을 한다.
3.4.3 다양한 소프트웨어 공학 기법들이나 개발 지식을 활용하여 개발팀이 성공적으로 프로젝트를 마무리 할 수 있도록 돕는 역할.
3.5 프로젝트 매니저
3.5.1 PM은 직종이라기 보다는 직책이지만, 수행을 위해 필요한 지식들이나 업무의 형태를 보면 새로운 직종이라고 봐도 무방
3.5.2 보통 현업(개발이나, 품질, 컨설팅)에서의 경험을 쌓은 후, 맡기 됨. 프로젝트의 처음부터 끝까지 관여하면서 구성원들의 작업을 조율하고, 일정이나 요구사항, 개발목표 등에서부터 구현 방향이나 인원분배등의 문제들까지 다양한 프로젝트 관련 업무를 총괄한다.
3.5.3 처음부터 PM을 하는 것이 아니니 만큼 PM을 위한 지식들을 미리 열심히 공부할 필요는 없지만, 능동적으로 프로젝트에 참여하기 위해서는 스스로가 작은 규모의 PM이란 생각으로 관련 지식을 공부하고 적용해볼 필요가 있다. 여기서 중요한 것은 적용해볼 만한 것들을 공부한다는 것.

결혼합니다.

요즘 글이 뜸했는데, 그 사이 결혼을 준비하고 있었습니다. 라기 보다는 바빠서 글은 못 올렸지만, 결혼도 준비하고 있었습니다. ^^

2년 전 사랑하는 사람을 만났고 이제 평생을 함께하기 위한 언약을 기다리고 있습니다. 많은 분들의 축하와 축복으로 시작하고 싶네요.

일시 : 2011년 2월 12일 1시 (토요일)

장소 : 역삼역 6번출구 방향 Y타워컨벤션