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

React Native를 이용해 개발하던 중, Android에서는 괜찮은데 iOS에서만 유독 다음과 같은 오류가 발생하며, 실행되지 않는 현상이 발생했다. 오류 문구 : Unhandled JS Exception: Invalid regular expression: invalid group specifier name no stack. 어떤 지점에서 발생하는 에러라는 정보라도 있어야 의심가는 부분을 찾아 수정해볼텐데, 어디에서 발생하는 오류라는 정보가 전혀 나오지 않아(no stack) 난감했다. 구글링을 하니 쉽게 답을 찾을 수 있었다. 원인은 iOS에 포팅된 Safari에서 지원하지 않는 lookbehind assertions 표현식(? 이슈 참고: stackoverflow.com/questions/569..

가트너에 의하면 2022년까지 전세계에서 사용중인 데이터베이스의 75%가 클라우드로 이전되거나 혹은 처음부터 클라우드 위에 구축 될 것이라는 전망을 발표했다. (https://www.gartner.com/en/newsroom/press-releases/2019-07-01-gartner-says-the-future-of-the-database-market-is-the) 그럼에도 불구하고 아직도 많은 국내 기업들은 보안, 비용 등을 이유로 퍼블릭 클라우드로의 전환을 망설이고 있다. 퍼블릭 클라우드가 좋다는 건 알겠는데 우리가 왜 퍼블릭 클라우드로 가야하는지에 대해서는 실무자가 아닌 윗선을 설득하기 어렵기 때문이다. 단지 다들 좋다 좋다 다른 곳도 그렇게 하니까 우리도 가야 하는거 아니냐는 말만으로는 C-Le..

Show Stopper는 IT 분야에서만 사용 되는 용어는 아니다. 공연을 멈추게 만드는 박수갈채를 부르는 "명연기", "명연설" 또는 "명연주" 등을 가르키는 용어이다. 하지만 IT쪽에서 이 용어는 조금 다른 의미로 쓰인다. 어떤 소프트웨어나 솔루션 또는 서비스를 더 이상 사용할 수 없게 만드는 치명적인 결함이나 기능의 부재 등을 지칭할 때 이 용어를 사용할 수 있다.

tech savvy는 다음의 두 용어를 합친 신조어이다. technology (과학 기술, 공학) + savvy (이해하는, 알다) 직역하면 과학 기술을 이해하는, 기술 적응력이 높은 등으로 해석할 수 있다. 즉, 최신기술을 빠르고 쉽게 터득하는 사람을 지칭할 때 사용 할 수 있다.

오라클에서 제공하는 Java 1.6 버전은 다음 링크를 통해 다운로드가 가능하다. https://www.oracle.com/java/technologies/javase-java-archive-javase6-downloads.html 하지만 아무리 눈씻고 찾아봐도 페이지에는 Mac OS용 JDK 또는 JRE가 따로 제공되지 않는다. Linux 64bit를 다운 받으면 된다고들 하는데, bin 파일을 다운로드 받아 압축을 풀려고 해도 내가 사용중인 macOS 에서는 압축을 풀 수 없다는 오류 메시지만 나온다. ~/Downloads ❯ chmod 777 jre-6u45-linux-x64.bin ~/Downloads ❯ ./jre-6u45-linux-x64.bin Unpacking... Checksumming...

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

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

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

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

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