아는만큼 보이고, 보이는 만큼 모자른 것을 알게 된다.

이 글은 어쩌면 내가 현재 속해있는 조직에만 한정된 얘기일지도 모르겠다. 프로젝트를 수행한 다수의 결과물 중 특히 코드를 검수 하려면 크게 두 가지 내용을 봐야 한다. 다했는지 잘했는지 다했는지는 정량적 판단이 가능하기 때문에 비교적 쉽게 판단이 가능하다. 잘했는지는 정성적으로 판단해야 하는 영역이기 때문에 판단하기 조금 애매하다. 정성적 평가로 가장 좋은 방법은 소스 리뷰이다. 하지만 소스리뷰는 오랜시간과 비용이 들어가기 때문에, 그나마 싸게 할 수 있는 방법이 강도 높은 테스트와 정적 코드 분석 툴을 이용하는 것이다. 내가 속한 조직의 대다수 클라이언트들은 싼 가격에 최대한 빨리 오픈 하는 것을 우선으로 생각한다. 사실상 다했는지에 대한 판단조차 제대로 하지 않는 편이라 잘했는지는... 말할 것도 없..

프로젝트를 성공적으로 수행하기 위해서는 여러 조건들이 충족되어야 한다. 오늘은 그 중 하나인 의사 결정권자와 프로젝트 수행팀간 물리적인 거리에 대한 이야기를 해보려고 한다. 결론부터 말하자면 의사 결정권자가 근거리에 있어야 업무가 더욱 효율적으로 진행되고, 생산성도 증가되며 더 정확한 산출물이 나올 수 있다는 얘기이다. 대부분의 요구사항은 처음부터 명확하게 누락없이 완벽한 경우가 거의 없다. 추상적이거나 예외상황은 고려되지 않았다거나 등등 다양한 이유로 실제 구현을 하는 과정에서 이런 경우 어떻게 처리해야 할지 의사결정이 필요한 상황이 발생한다. 이런 경우 Project Leader(PL) 또는 Project Manager(PM)에게 물어봤을 때 곧바로 답이 나오는 경우는 거의 드물다. 대부분 고객(또는..

그간의 경험에 비추어 볼 때 이슈를 해결 하는 여러가지 방법 중 하나는 다른 사람에게 이슈를 설명하는 것이다. 이게 무슨 말이냐면, 혼자 낑낑대며 원인도 찾지 못한채 의심가는 코드를 찾아 디버깅도 해보고, 로그를 추가 하기도 하고, 수정해서 테스트도 해보고 이런 저런 다양한 시도를 해도 해결되지 않는 이슈가 있다. 결국 혼자 해결하기 힘들겠다는 결론을 내리고 커뮤니티에 질문을 작성 한다거나 동료에게 도움을 구하기 위해 메일을 작성하거나 또는 구두로 그 현상과 결과를 정리하는 과정에서 스스로 해결방법이나 원인을 알아채게 되는 것이다. 협업과 소통이 중요하다는 것은 아무리 강조해도 지나치지 않는 것 같다.

나는 사실 만족할만한 어느 정도의 수준까지는 Android 개발에만 정통하고 싶었다. 그리고 나서 Landscape를 늘려가는 것이 더 쉬울거라 판단했기 때문이다. 하지만 전 직장도 그렇고 재직중인 회사도 그렇고, 내가 원하든 원하지 않든, 필요에 따라 계속 다른 분야도 할 수 밖에 없는 상황이 전개 된다. 이 곳에서 개발자로 살아남으려면 결국 풀스택을 다룰 수 있어야 한다는 결론을 내렸다. 그렇지 않으면 결국 어느정도 연차가 쌓인 후에는 관리직으로 빠져야 되기 때문이다. 내가 하고 싶고 할 수 있는 일을 더 발전시킬 수 있는 회사인지 아닌지에 따라 커리어의 방향성이 자칫 내가 생각했던 것과는 다르게 흐를 수 있다. 이처럼 개발자에게 있어 회사를 선택하는 문제는 매우 중요하다고 생각된다. 구직중이거나 이..

트러블 슈팅을 할 때 명확한 원인을 찾아 해결되는 케이스도 있지만 그렇지 못한 케이스도 종종 발생한다. 이런 경우 가능성이 높다고 추정되는 부분부터 이런 저런 다양한 방법으로 수정을 시도 하곤 한다. 가장 좋은 방법은 무언가 새로운 시도를 할 때마다 행위와 결과를 기록하는 것이다. 이런저런 다양한 시도를 하다보면 어떻게 해결 됐는지도 모른채 이슈가 클리어되기도 하기 때문이다. 결국 기록없이 해결한 이슈는 다음에 같은 이슈가 발생했을 때, 또 똑같은 일을 반복해야 하는 것이다. 하지만 당장 이슈를 해결해야 하는 급박한 상황에서 위의 방법은 그닥 현실적이진 못하다고 할 수 있다. 그렇기 때문에 이슈를 해결하고 난 후에는 이와 같은 상황이 다시 발생할 것을 상정하고, 회고하며 정리하는 과정이 반드시 필요하다.

수많은 기술들이 그야말로 홍수처럼 쏟아져 나오고 있고, 그와 관련된 다양한 정보들도 인터넷에 많이 존재한다. 더보기 물론 완전히 새로나온 기술이라면 예외겠지만 새로운 기술이나 방법론 등을 접할 때 기술의 소개나 사용 방법 등.. 나의 경우는 공식 문서만 보고도 이해할 수 있다면 다행이겠지만 개념 자체가 생소한 경우라면 그렇지 않은 경우가 다반사이기 때문에 여러 정보(블로그, 기술 매거진, 서적 등)들을 봐야 이해할 수 있는 경우가 많았다. 이는 작성한 이나 독자가 처한 상황이나 관심사에 따라 주관적인 시선으로 작성되거나 읽히는 경우가 많기 때문에 어찌보면 당연하다고 볼 수 있다. 이러한 경험들이 반복되다 보니 내가 이해한 내용을 나만의 언어로 다시 한 번 더 정리하지 않으면, 당시에 다 이해했다고 생각했..