• Naming
  
  ?XxxxRes -> 여기서 Res가 무엇을 뜻하는 것일까? Resource? 나는 처음에 코드를 보고 Resource로 알았다. 하지만 약 1달이 지난 지금 전체적인 동작을 이해할 때쯤이 되어서야 Response인 것을 알았다. 내가 처음부터 Response로 알았다면 더 짧은 시간에 전체적인 동작을 이해하는데 도움이 되었을 것이다. Res와 같은 축약어를 절대로 사용하지마라. ?XxxxResponse로 표기하는 것이 뒤에 그 코드를 보는 사람을 도와주는 것이다.
  

• 밑에 사람 쪼아서 성공하기
  
  사람을 쪼아서 일을 하면 실제로 빨리 일이 진행되는 경우가 많다. 회사내에서건 회사 사이의 관계에서든 쪼아서 일을 진행시키는 경우가 많다. 하지만 좀 시간이 지나면 쪼는 것만으로는 한계가 있다는 것을 깨닫게 된다.
  

• Code 읽기/수정
  
  내가 하는 일의 대부분은 새로운 code를 개발하기 보다는 기존의 코드를 가지고 문제가 나는 부분을 수정하거나 기능 변경으로 인한 코드 수정이 대부분이다.
  

• 누구를 위한 Code
  
  code는 작성할 때부터 그 code를 후에 접하게 될 사람(시간이 지난 뒤 코드를 다시 볼 자기 자신을 포함)을 위해서 이해하기 쉽고 보기 좋게 작성해야 한다. code는 자신의 것이 아니라 그 코드를 유지관리할 사람의 것이라는 생각을 갖자.
  

• 눈으로 디버깅
  
  회사에는 천만원짜리의 디버깅 장비가 있다. 나는 아직까지 눈으로 디버깅하는 것을 좋아한다. ?마이클의 영향으로 디버깅 장비 없는 디버깅을 선호한다. 디버깅 장비를 이용한다는 것은 운전할 때 항상 네비게이션을 이용하는 것과 같다. 네비게이션이 편하지만 매일 자신이 다니는 길에 대해서도 네비게이션이 없으면 마음이 불안해지는 운전자와 같은 모습이 되는 것이 싫다. 디버깅 장비가 있기 때문에 code를 대충 짜게 되는 것은 아닌지 모르겠다. '디버깅 장비가 없으니 알아서 개발하시오' 이런 조건이라면 좀더 code에 공을 들이지 않을까?
  

• 말은 적당히 해야한다
  
  말이 많으면 오해가 생기고 말이 적으면 사람과의 관계 형성이 어렵다.
  

• SW공장
  
  공장에 가본적이 있는가? 공장에 자주 갈 기회는 없지만 그래도 가끔 공장을 가면 작업장의 정돈상태나 작업 동선이 짧은 것을 보면 감탄이 나온다. 최근에 내가 하는 sw개발도 실제 공장에서 물건을 만들어 내는 것과 비슷하다는 생각이 든다. 'sw개발은 다른 생산활동과는 확연히 다른 독특한 활동이다'라고 개발자들은 말한다. 하지만 나는 점점 경험이 쌓일수록 모든 생산활동이 동일하다는 느낌이 든다. sw개발의 특수성보다는 다른 생산활동의 좋은 특징들을 충분히 sw개발에도 접목시킬 수 있겠다는 확신이 든다. 최적화된 생산 공장의 모습을 관찰하여 sw공장을 만들어 보는 것도 재밌겠다.
  단지 생산공장과 sw 공장의 가장 큰 차이는 생산 공장의 경우 생산모습이나 생산량의 파악이 눈에 보인다는 것이다. 하지만 sw개발팀의 경우 진행에서의 품질 평가가 쉽지 않고 결과물이나 유지보수에 대한 것까지 고려하여 판단해야하기 때문에 가시적인 모습을 확인하기 힘들뿐만 아니라 꽤 오랜 시간이 지나야 어느 정도 가시적인 평가가 가능하다는 것이다.
  

• SW공장의 특징
  
  • 정돈
    
    공장에서 사용하는 도구와 장비가 잘 정리정돈 되어 있는 모습을 쉽게 확인할 수 있다. sw에서는 소스 code나 lib등의 정리정돈 상태와 비슷하지 않을까?
    
  • 재활용
    
    공장에서 사용하고 남은 재료를 재활용하는 경우가 많고 가용 인력을 다른 일에 투입하는 것이 용이하다. sw에서는 코드의 재사용성이 문서나 lib 형태로 존재하더라도 검색시스템이나 개발자들의 교류가 적다면 재사용이 불가능하다. 실제로 동일한 동작의 code를 얼마나 많이 중복하여 생산하고 있을까?
    
  • 일정
    
    20초당 1대의 에어콘이 나온다. 그렇다면 1시간에는 몇 대의 에어콘이 생산될까? 공장에서는 큰 사고가 없는 이상 생산물의 양을 예측할 수 있다. sw의 경우 동일한 일을 하는 경우가 아니면 예측이 어렵다.
    
  • Man month
    
    몇 명을 투입해야할까? sw개발에서 숙련도와 개발인원에 대한 산출이 더 어렵다.
    

• 회의
  
  8시 30분부터 12시까지 2건의 회의에 참석했다. 회의가 끝나고 나니 점심시간이네.. T_T
  

• 의견공유
  
  회의가 길더라도 혼자서 일하는 시간을 단축시킬 수 있는 가치를 제공한다면 길어질 수도 있다. 하지만 지치지 않는 수준이어야 한다.
  

• code보다는 history
  
  code는 현재의 상황을 설명해 준다. 어떻게 해서 여기까지 와서 현재 상태의 code로 표현되었는지에 대한 정보가 부족하다. SW개발에서는 새로온 사람이나 다른 도메인의 경험을 가진 사람에 대해서 무시하는 경향이 있다. '신입사원 받아서 써먹지도 못해요.', '이쪽 개발경험이 없군요. 그럼 힘들겠는데요.' 마치 자기가 하는 일은 오랜 시간에 걸친 경험의 결정체라는 인상을 준다. 하지만 막상 일을 해보면 그 사람들이 두드러지게 일을 잘 하고 있다고 할 수 없으며 자기들의 동굴에 갇혀 있다는 느낌을 받는다. 나는 운좋게도 매번 다른 일을 맡아서 다양한 도메인의 개발자들과 함께 일할 기회가 있었다. 각 도메인에서 일하는 모습을 관찰할 수 있었으며 또 그들을 흉내낼 수 있는 기회도 주어진 것에 감사하게 생각한다. 그렇다면 왜 다른 도메인의 사람들을 받아도 쓸모가 없다고 생각하는 것일까? 일을 보면 대부분이 신기능을 추가하기 보다는 기존 code를 수정하거나 변경하는 일이다. 특정 code 부분이 지저분 하게 되어 있는 경우가 있는데 그 이유는 그 당시 어떤 버그가 발생했는데 그것을 해결하기 위해서 땜빵으로 그 부분을 수정하여 넘어간 부분이다. 따라서 처음 접하는 사람이 그 부분을 다른 방식으로 수정하다가 side effect를 발생시키는 경우가 많아서 아예 신입사원이나 다른 도메인의 개발자를 도움을 받을 수 있는 사람으로 여기지 않고 짐으로 여긴다. 현재 상태까지 오게된 code의 history를 설명하는 자료도 부족하고 history 공유하는 일 자체도 잘 하지 않기에 짐으로 여긴다.
  

• define
  
  define의 남발로 코드의 가독성이 떨어지는 문제.
  define 지옥.
  코드 중간중간에 ifdef, ifndef를 사용하여 실제로 내가 원하는 부분이 수행되는 부분인지 아닌지 알아보기가 힘들다. 실제로도 define으로 인해 발생하는 버그가 끊이지 않는다.
  define을 완전히 쓰지 않고 개발하기가 사실상 어렵다면 가독성을 높일 수 있는 방법은 유지하면서 사용해야 한다.
  함수 내부에서 ifdef/ifndef를 남발하기보다는 define에 따라 사용 function을 정의하는게 좋지 않을까?
  ifdef/ifndef를 사용하는 경우에도 들여쓰기를 하자.
  메모장을 이용하더라도 눈에 쉽게 들어오는 소스를 작성하자.
  

• 고집이 센 사람
  
  아래와 같은 일들로 고집이 센 사람이 되었다.
  
  • 변수이름에 신경쓰자.
    
  • 소스코드부터 정리하자.
    
  • 코드 정리 후 현재 기능구현을 하느냐 현재 기능구현을 끝낸 후에 정리하느냐.(내가 봤던 책에서 정리가 안된 코드에서 하는 모든 일이 낭비라고 했고 나도 동감한다.)
    
  • extern변수 사용하지 맙시다.
    

• extern 변수
  
  왜 extern 변수를 사용하면 안되는걸까?
  extern 변수를 참조 혹은 수정하는 것으로는 의도를 표현하기가 어렵다.
  포팅을 어렵게 하더라.
  다른 이유들도 찾아봐야겠다.
  

• Real Machine vs. Emulator
  
  개발에서 모든 작업을 Real Machine에서 한다면 엄청난 시간낭비다.
  compile 시간, 폰으로의 download시간, 디버깅을 위한 break point 등을 설정하는데 걸리는 시간이 만만치 않다.
  Emulator에서 가능한 작업과 Real Machine에서 가능한 작업을 분리하여 테스트 코드를 만들고 동작을 확인하는 것이 중요하다.
  Emulaotr에서 할 일 : 이미지 표시, 좌표 수정, Logic에 관련된 코드
  Real Machine에서 할 일 : device에 대한 제어 api 동작에 관련된 코드
  logic이나 event에 관련된 버그의 경우 Emulator에서 쉽게 재현이 가능하다.
  Call관련 기능을 개발하는 경우 버그의 재현이 힘들지만 Emulator로 쉽게 재현시켜서 동작의 수정 후 확인이 용이하다.
  

• 긴장감
  
  일정이 촉박하게 느껴지면 긴장을 하게 된다.
  집중력도 떨어지고 마음도 조급해진다.
  긴장을 풀어주고 집중할 수 있는 자신만의 방법을 찾는 것이 중요하다.
  

• 자기만의 의식적 행위
  
  하루를 시작하는 의식적 행동이 있는가?
  커피 한 잔을 타서 자리에 올려놓고 하루를 시작한다.
  

• 자기에게 주문걸기
  
  세상에 내가 개발 못할만큼 어려운 code는 없다.
  

• 차근차근 방법찾기
  
  시간이 촉박하면 차근차근 생각하기가 힘들다.
  냉정함, 마음의 평화를 지속적으로 유지하자.
  

• 개발문서의 의미
  
  개발문서도 필요하다.
  문서를 의미있게 만들려는 노력이 필요함.
  새로운 개발 소스코드를 받았는데 만든 사람만이 이해할 수 있겠더라. 정말 미치겠군. T_T
  복잡성의 증가로 인해 디버깅 장비를 통해서만 어떤 경우 어떤 함수를 호출하는지 알수 있음.
  개발에 관련된 history를 기록으로 남겨뒀으면 고생을 안할텐데...
  문서를 안만드는 이유 -> 몇 년에 걸쳐 이일을 하므로 개발문서에 대한 필요성을 느끼지 못함. 새로 일을 맡는 사람을 코드보면서 공부하라고 함.
  이런 경우에는 기존 개발자를 불러서 전체적인 구조에 대해서 물어보는게 최선책. 하지만 대부분의 경우 전체적인 맥을 짚어주는 경우가 드물더라.
  

• Call관련 개발
  
  Call관련해서는 문서가 필요하겠더라. Call은 대부분 state 머신으로 구성되어 있어 망과 단말기 사이의 state와 event를 간략화한 그림을 제공한다면 좋으리라 생각함.
  예전에 망관련 system s/w를 개발한 상사가 있었는데 그 사람이 문서를 강조한 이유가 있었다.
  간략하게 표현이 어렵고 많은 내용을 이해해햐 하는 경우 문서는 반드시 필요하다.
  

• ifndef, ifdef 젠장
  
  코드에서 추방했으면 하는 것 중에 ifndef가 있다.
  코드를 읽는데 엄청난 병목현상을 일으키는 부분이다.
  edit프로그램인 source insight에서 제법 정확한 소스 코드 파싱이 가능해서 define 값에 따라서 ifndef/ifdef 부분에 대해서 회색(disable)으로 코드 부분을 표시해 주지만 보기가 쉽지 않다.
  만약 edit프로그램이 이런 파싱을 해주지 않는다면 개발자들은 좀더 코드를 작성할 때 신경써서 작성하지 않을까 하는 생각을 해 봤다.
  조금 어렵거나 지저분하게 나둬도 edit프로그램이 가독성을 어느 정도까지 올려주는 기능을 담당하기에 코드작성시 신경을 덜 쓰게 하는 부작용이 있다.
  편한게 좋은 것은 아니다.
  

• 불러서 해결
  
  낭비제거하기 위한 실험으로 혼자서 문제를 해결하는 것이 아니라 담당자나 기존에 경험자를 찾아서 현재까지의 진행상황을 듣고 문제해결을 시도함.
  이미 경험한 문제에 대해서 중복의 비용지출을 막기 위함이다.
  

• 다른 사람의 소스코드
  
  가져다 쓰는 사람을 항상 생각하라.
  쉽게 포팅되도록 하라.
  추가 기능을 쉽게 구현할 수 있도록 하라.
  어떤 기능을 추가하거나 수정할 때 직관적으로 '아 여기다 추가/수정하면 되겠지'라는 생각이 들도�� 코드를 구성하라.
  

• 리팩토링
  
  '우리 파트는 리팩토링을 합니다.'
  회사내에서 리팩토링을 했다고 하면 보통 함수이름을 바꾸거나 코멘트로 처리된 부분을 삭제하는 수준을 의미한다.
  가장 불만족스러운 부분이 함수 array를 사용하여 함수 포인터를 이용하는 것이다. -> 눈으로 디버깅이 어렵다.
  가장 기본이 되는 원칙은 지키지 않는다.
  

• Tool
  
  개발 후 소스를 분석해 주는 Tool에 대한 세미나에 참석.
  개발 후 문제가 있다고 알려주는 것보다는 개발전에 개발을 진행중에 문제가 되는 부분을 지속적으로 알려주는 tool이라면 더 좋을 것이다.
  소스가 어려워 분석 tool을 사용해야 한다는 것도 근본적인 문제보다는 사후 문제해결에 포커싱을 두고 있다.
  개발중에 지속적인 feedback을 받을 수 있는 tool.
  '당신은 지금 제대로 code를 개발하고 있소'라고 알려주는 것.
  

• 파서
  
  소스코드를 파싱하는 파서를 만든 경험이 있다.
  코딩스타일이 저마다 달라서 각 모듈마다 예외적인 파서에 기능을 추가해야 한다.
  코딩스타일이 같다면 몇 줄이면 파싱이 가능하지만 한가지 예외를 처리하기 위해서 파서의 개발시간과 코드가 늘어나 파서에 버그가 추가될 확률이 높아진다.
  결국 모든 코드에 대해서 파싱하는게 어려워지는 문제가 발생한다.
  회사 소스분석 Tool을 만드는 사람에게 해주고 싶은 충고.
  

• 여유
  
  한동안 골치 아팠던 문제가 해결됐다.
  잠시 여유를 갖게 되었다.
  

• PL(Project Leader)의 고독
  
  점심시간에 혼자서 식사하는 PL.
  팀원들에게 싫은 소리도 해야하고 상사에게 꾸지람을 듣기도 한다.
  아래에서 위에서 샌드위치 신세.
  내가 처음 일을 시작했을 때 PL에 편한 직책이라 생각했다. 어떤 일을 해야하는지 조금씩 보이면서 스트레스를 상당히 많이 받는 위치라는 것을 실감한다.
  진급하는 것이 즐겁고 자기 시간이 많아지는 것이 아니라 책임과 무게가 더욱 가중되는 것 같다.
  내가 IT를 업종에 종사하는 한 PL이 나의 미래 모습이 될텐데...
  

• 아침에 해야할 일 목록작성
  
  아침에 출근해서 오늘 해야할 일을 간략하게 메모하기 -> 목표를 구체화
  

• 내가 이 나이에 코딩을 하고 있다니...
  
  나보다 몇 살 많은 분이 최근에 코딩을 하게 됐다고 투덜거리는 소리.
  코딩은 잘 해야 본전인가? 작업 시간대비 가치가 적은 일이며 직급이 올라갈 수록 피해야 할 일이라 생각한다. '삽질'이라는 표현을 많이 쓴다.
  코딩은 아무나 할수 있으며 특별한 지식이 필요한 것이 아니라. 시간이 필요할 뿐이다라고 말한다.
  내 개인적인 생각으로 코딩은 예술작품을 만드는 것과 같다. 아름다운 코드가 있고 다른 개발들이 함께 감상할 수 있는 코드가 존재한다.
  우아한 코드를 증명할 수 있는 방법이 없을까? 유지보수를 획기적으로 줄일 수 있다는 과학적인 증거를 제시할 수 있다면 좋을꺼 같다.
  물론 그 분이 자주 언급하는 문서화나 관리의 중요성에도 동감한다. 근본적으로 생산되는 코드의 질적개선이 없다면 훌륭한 문서가 무슨 소용이겠는가?
  나는 근본에서 출발하고 싶다. 아름다운 코드를 작성하는 것보다도 코드를 감상하는 방법에 대한 전파가 있으면 좋겠다.
  

• 깔끔한 소스의 기본
  
  팀원이 Tab size를 공통으로 맞추기 (추천 Space 4)
  사용하는 Edit 프로그램이나 설정에 따라서 표시가 다를 수 있음.
  

• MVC
  
  핸드폰 Application 구현을 위한 가이드의 필요성 -> '이렇게 개발하라'는 일종의 가이드로서 MVC모델이 적합하다고 생각한다.
  왜 MVC인가? -> 예제를 통해서 독립적인 개발과 Test에 대한 설명가능
  

• 시끄러운 개발자
  
  가끔씩 들리는 시끄러운 대화
  issue가 많은 생겼고 또 그것을 해결하기 위해 활발한 의사소통이 일어나는 듯한 착각.
  약 1달 정도 듣고나니 대부분이 별문제 아니고 충분히 시끄럽게 하지 않고도 해결가능한 문제들이라는 생각이 든다.
  항상 시끄러운 사람은 정해져 있다.
  조용한 개발자는 일이 없거나 쉬운 일을 하고 있다고 오해를 받기 쉬운거 같다.
  

• 암호화된 코드
  
  코드를 복잡하게 짜는 것은 자신의 영역을 지키기 위한 수단인가?
  누구나 자신이 작성한 코드를 이해하고 수정하고 쉽게 기능을 추가할 수 있다면 자신은 필요없는 존재가 된다고 생각하는 것일까?
  공유를 쉽게할 수 있는 코드를 작성한 사람에게 포상을 하는 제도가 주어진다면 유지보수에 드는 비용이 줄어들지 않을까?
  고용에 관련된 문제라 한편으로 이해도 되지만 암호화된 코드를 받아서 작업해야 하는 사람은 엄청난 스트레스를 받는다.
  자신도 이해못하는 코드를 작성하는 경우도 종종 본다.
  

• 토요일날 근무
  
  평소보다 편안한 느낌.
  개발에서 추가의 시간을 제공받은 느낌.
  주말에도 일을 해야하는 경우 일을 미루는 습관이 생길 수 있다.
  

• s/w 낭비제거 동호회
  
  s/w 낭비제거 정보 공유를 위한 동호회는 어떨까?
  이런 것들이 낭비다.
  
  1. 고객에게 전달되지 않는 것은 낭비다
     
  2. 참조되지 않는 code는 낭비다.
     
  3. 동일한 실수를 반복하는 것은 낭비다.
     
  4. 이해가 안되는 코드는 낭비다.
     
  5. 다른 사람이 수정할 수 없는 코드는 낭비다.
     
  6. 동일 동작이 기존 코드를 바로 활용하지 못하는 것은 낭비다.
     
  7. 동일한 일이 여러 개 진행되는 것은 낭비다.
     

• f/w개발의 어려운 점
  
  자신이 수정한 부분에 대한 확인/검증이 어렵다.
  특정 시나리오로 동작해야만 확인이 가능하다고 여기며 해당 상황을 재현하기 위해서 많은 노력이 든다.
  real time으로 처리되는 것들인 경우(Call, DMB, ...) 고정된 상태가 아니라 재현이 더욱 어렵다.
  

• dsp 버그
  
  UI입장에서는 그냥 interface를 호출할 뿐이다. 따라서 아래에서 어떤 일이 벌어지는지 알기 어렵다.
  

• 전문가라서 즐거운가 즐겁기 때문에 전문가가 되는 것일까?
  
  일반적으로 생각하기로는 일이 재밌어서 해당 분야에 전문가가 된다고 생각한다. 하지만 내가 봐왔던 많은 사람들은 전문가가 되었기에 개발일을 즐겁게 하는 것 같다. 처음에는 크게 흥미를 느끼지 못했지만 점차 인정을 받는 사실에 일을 즐겁게 하고 전문가라는 인정을 받는 경우도 많이 보인다. 상사나 주변인들의 칭찬이나 관심이 전문가로도 만들수 있고 또 꼴통으로도 만들 수 있다. ^^
  

• 소스 익히는 방법
  
  • 기존 s/w의 동작 확인
    
  • 에뮬레이터 동작
    
  • 개발문서 확인
    
  • 시나리오 문서 확인
    
  • 소스 보기
    
  • 소스를 이해하고 직접 전체구조도 그려보기
    
  • event flow 그려보기
    
  • 선임자의 설명듣기
    
  • 선임자가 과제를 내주기
    
  • 세미나 시키기
    

• 다이어리
  
  회사에서 나눠준 다이어리.
  모든 사람들이 회의에 들어갈때 이 다이어리를 들고 들어온다.
  

• 신입사원은 도움이 안된다?
  
  개발 일이 골고루 분산되면 좋겠지만 그렇지 않은 경우가 많다. 힘들어 하는 사람에게 '신입사원이라도 붙여줄까?'라고 팀장이 제안하면? 내가 봤던 반응은 모두 '언제 교육시키고 언제 일을 시켜요. 지금 이사항에 도움이 안돼요. 그냥 제가 할께요.' 였다. 이런 말을 한다면 전체 일을 독립적인 작은 부분으로 나누지 못하는 사람이다. 작고 독립적인 단위로 일을 나누기만 한다면 충분히 신입사원이라도 도움이 될 수 있다. 개발자에게 필요한 교육 중에 하나가 바로 개발일을 여러 사람이 나누어 작업할 수 있는 단위로 나누어 진행하는 훈련이다.
  

• 멘토
  
  새로운 업무에 가능한 빨리 적응하기 위해서 이전에 해당 기능을 담당했던 경험자를 멘토로 둔다. 업무를 주고 결과에 대해서 연대책임을 지는 경우 멘토가 적극적으로 활동하고 업무에 직접적인 도움을 주는 경우가 많더라.
  멘토는 해당 업무에 대해서 초급자가 통찰력을 가질 수 있도록 노력해야 한다. 어떤 식으로 접근하여 어떤 것을 알려줘야 하는지 이 방법으로 초급자가 쉽게 적응할까에 대한 질문을 자신에게 계속 해야한다.
  

• 얼음조각가
  
  우연히 TV에서 중국의 얼음조각가 3인의 대결을 봤다. 최종 결승인듯 했고 최종 3인이 제한된 시간내에 작품을 완성해야한다.
  3인의 인터뷰 화면에 인상적이였다. 3명은 모두 웃는 표정이고 조각이 너무 재밌다고 말한다. '이 사람들 정말 일을 즐기는구나'라는 생각이 들었다.
  조각에 대해서 책임이나 일의 완료로 느끼기보다는 일자체에 대한 재미를 느껴야 한다.
  '더 잘하고 싶다'는 욕구가 드는 단계보다 한단계 높은 단계는 '더 즐기고 싶다'는 생각이 드는 단계이다. 이 단계야 말로 정말 자기 일을 사랑하는 단계가 아닐까? 경쟁보다는 일 자체를 즐겨라. 그것이 일이 주는 행복이 아닐까?
  
  • 나는 이럴때 좋다
    
    내가 만든 것이 자주 참조나 언급되는 경우
    내가 만든 것이 다른 것보다 이해하기 쉽다고 말해주는 경우
    전체적인 구조가 일관성 있게 유지되는 경우
    

  • 코드는 나의 피땀?
    
    다른 팀 사람이 자신의 code를 사용하는 것에 대해서 탐탁하게 생각하지 않는 경우가 있다.
    '내가 어렵게 한 일을 쉽게 낼름 먹으려 들다니' 이런 생각을 하는거 같다.
    

  • 삼세번
    
    code를 익히는 방법 중에 포팅을 여러 번 해보는 방법이 있다.
    전체적인 구조를 파악하거나 어느 위치에 어떤 일을 하는 파일들이 들어간다는 것을 익힐 수 있다.
    나는 보통 3번 정도의 포팅을 한다.
    

• 개발자는...
  
  • 월급에 의존하고 새로 나온 전자제품 구입을 즐긴다.
    
  • 다른 사람과의 접촉이 다른 직업에 비해 적고, 혼자서 생각하고 컴퓨터와 마주하는 시간이 많다.
    
  • 취업이 다른 직업에 비해 쉬운 대신 시간이 지나도 월급이 크게 오르지 않는 직업.
    
  • 경력이 많아져도 퇴근 시간이 유동적이다.
    
  • 실제로 신기술보다는 하나의 기술에 종속되는 경우도 많다.
    
• 개발자의 수입
  
  • 금융업에 종사하거나 서비스업에 종사하는 사람에 비해서 수입이 떨어진다.
    

• 누구와 일하느냐에 따라서 스트레스의 강도가 틀려진다.
  
• 불안감을 주는 사람과 함께 일하기
  
  왠지 잘 안될꺼 같은 분위기 확산시킨다. 사기저하.
  

• 새로운 시도에 대한 평가
  
  조직내에서 너무 적극적인 행동에 대해서는 경계
  결과가 좋더라도 이러쿵저러쿵 말이 많은 경우가 많다.
  좋은 방향으로 몰고 가기 위해서는 시간과 노력이 필요하다.
  

• 회식
  
  즐거운 회식은 회사생활에 활력을 준다.
  의욕적으로 참여할 필요가 있다.
  

• 필드테스트
  
  VT Call테스트를 위해서 서울 한강변을 돌다.
  

• 발로 뛰는 개발
  

• 긴 연휴뒤 출근
  
  뭐부터 시작해야하지?
  긴 휴식 뒤 업무복귀 쉽게하는 방법은?
  
• 물어보기
  
  검지팀에서 올리는 버그
  버그에 대한 현상이나 재현 경로가 불명확한 경우 버그 내용을 확인하기가 힘들다.
  '이게 문제라고 생각한걸까?' 가끔 오해가 생긴다. ex) 인디케이터 깜빡임 문제. 개발자 입장에서 문제라 생각하지 못했음.
  '무엇이 문제라고 생각하는가?' -> '아 이게 문제라고 생각하는군'
  빠른 해결이 가능.
  

• 발렌타인Day
  
  발렌타인Day라고 여사우들이 돈을 모아 초콜렛을 돌리다.
  
• 정상동작
  

• 메일
  
  읽고 처리할 일이 많다.
  

• 버그재현
  
  VT를 하면서 어려운 점 중에 하나는 버그 재현이 다른 모듈을 개발할 때보다 힘들다는 것이다.
  버그재현을 위해서 몇 일 동안 노력해야 하는 경우도 있다. 개발보다 버그재현이 더 힘든 경우도 있다.
  

• 필드테스트
  
  VT를 하면 필드테스트를 나가는 경우가 생긴다. 차를 타고 여러 지역을 다니면서 핸드폰을 사용하는데 이런 경우 생기는 문제점을 확인하고 해결하기 위함이다.
  

• 작업장
  
  노트북, 장비, 문서들로 어지러운 책상.
  

• 먹고 사는 것 vs. 하고 싶은 것
  
  먹고 사는 것도 중요하고 하고 싶은 것을 하면서 사는 것도 중요하다. 어느 것을 선택할 것인가? 우리는 항상 그것을 고민한다. 하고 싶은 것을 할때에는 큰(?) 용기가 필요하다는 것을 안다. 새롭게 시작해야 한다는 것에 대한 부담감. 결국 우리의 인생의 종착역은 어딜까?
  

• 처음으로 기능으로 구현하는 개발자가 가져야할 마음가짐
  
  내 코드를 받아서 쓰는 사람은 고객이다. 고객이 쉽고 편안하게 사용할 수 있도록 배려하는 마음이 필요하다. 개발일을 하다보니 돌아가는 코드로는 뭔가 부족하다. 코드를 가져다 쓰는 사람이 쉽게 기능을 추가하고 수정할 수 있게 만드는 것이 더 높은 수준의 개발자가 되는 길이다.
  

• 테크니컬라이터
  
  어떤 일에 필요할까? 개발자에게 어떤 식으로 도움을 줄 수 있을까? 개발에 필요한 문서 포맷 작성하고 불필요한 문서작업을 없애도록 건의하고 필요한 정보를 정리하는 방법에 대한 아이디어를 내는 일을 해준다면 도움이 되겠다.
  

• 남들이 꺼리는 사람과 일하기
  
  회사에서 매번 하는 일이 바뀌다보니 같은 경력의 동료보다 훨씬 다양한 사람들과 일할 기회가 많았다. 그 중 보람을 느낀 일은 남들이 꺼리는 사람과 함께 작업해서 좋은 성과를 낸 경우다.
  
  개인이 가지고 있는 능력도 중요한 요소지만 일을 처음 접하는 사람에게 용기를 주고 어떻게 성공적으로 끝낼지에 집중한다면 좋은 결과를 얻을 수 있다는 확신이 들었다. 내가 어떤 역할을 해야할지 또 그 역할을 통해서 상대방이 자신감을 가지고 일을 진행시켜 나갈 수 있을까에 대해서 많은 고민을 해봤던 기억. (송S 이야기)
  

어제 내가 지원하는 부서와 그 부서에서 요청한 것을 개발팀과 회의가 있었다.
내가 지원하는 부서에서 A라는 기능을 요청한 상태였고 이미 1달 이상의 시간이 지난 상태다.
'A 기능을 위해서 이러쿵저러쿵에 대한 상세 내용을 결정해 줘야 진행이 가능한데 그 부분에 대한 결정을 하지 않아서 진행을 못하고 있었습니다.'

이미 구현된 시스템에 추가하는 것이라 내가 봤을때는 상식적으로 현재와 동일한 방식이면 별다른 이견이 없는 상황 같아 보였다.

내가 지원하는 부서가 이전에 까다롭게 굴었던 경험이 있어서 그런건지 아니면 보통의 개발팀과 같이 최대한의 옵션을 주는 것 같지만 실제로는 고객에게 책임을 전가하는 것인지는 명확하지 않다.

개발자나 서비스를 제공하는 쪽은 고객이 똑똑한 판단을 할 수 있도록 최대한 정보를 제공하는 것이 옳지 않을까 생각한다.

개발자가 똑똑한 고객을 원하는 것처럼 고객도 똑똑한 개발자를 원하는지도 모른다.