이제 다른 이야기를 하기 전에 나의 두 번째 회사에 대한 이야기를 해야 한다. 우선, 내 경력 중 가장 이질적이고 설명이 어렵다. 어떠한 목표를 두고 입사한 것도 아니었고 일을 배울 환경이 잘 조성된 것도 아니었다. 하지만 그때 배운 것은 아직도 잘 활용하고 있다. 더불어 일을 하다 보면 그 시절을 계속 참고하고 있는 나를 발견한다. 이 시리즈를 적는 큰 이유다. 약 20년 전 일했던 그곳은 백 명이 좀 넘는 직원이 일하던 전자회사였다. 크게 보면 인원의 대부분을 차지하는 생산조직과 하드웨어와 소프트웨어를 설계하던 연구조직 그리고 영업팀 총무팀을 포함하는 사무조직이 있었다. 그리고 나는 총무팀 소속으로 그리고 입사 직후 신규사업팀과 그리고 얼마 지나지 않아 모회사가 투자한 스타트업과의 JV를 만들기 위한 화학산업에 기반한 신사업 TFT로 파견되었다. 기술과는 무관한 사무직, 자료조사와 문서 작성이 주 업무였다. 각종 뉴스를 검색하고 수백 장 짜리 보고서를 읽고 파워포인트 문서를 만들어 공유하고, 회의에 참여해서 회의록을 기록하고 메일을 작성했다. 생각과 지식을 문장으로 정리하는 기초를 학교 신문사에서 배웠다면, 이를 소위 말하는 업무용 언어로 바꾸는 것은 이곳에서 배웠다. 두 회사의 각 임원들만 들어가 있던 TFT의 유일한 사원으로 문장을 정리한다는 것은 단순히 말을 적는 것뿐 아니라 비정형적으로 표현되는 정치적 언어를 어떻게 받아들이고 다시 남길 것인가에 대한 문제이기도 했다. ...
아마도 이력서에 적지는 않겠지만 - 2. OBS
처음부터 긴 시리즈로 적겠다고 마음먹었기 때문에, 다음 이야기는 어느정도 정해져 있었다. 다만, 또 너무 예전의 이야기라, 지루할까 걱정되고 적는 내가 재미가 없었다. 그래서 시간도 벌 겸, 새로운 것들도 좀 할 겸 시간을 보내다, 가벼운 주제가 보여서 적는다. 최근에 OBS Studio를 만질 일이 있었다. 다니는 교회의 예배를 YouTube를 통해 중계하는데 방송 중에 자꾸 끊기는 일이 생겨서다. 현장에 설치된 공유기부터 각 방송용 장비, 컴퓨터 그리고 각종 소프트웨어를 이리저리 만지며 설정하다 보니 내가 왜 이런 걸 알고 만지고 있나 싶다. 방송용 프로그램을 개발할 일이 있었던 것도 아닌데 말이다. ...
아마도 이력서에 적지는 않겠지만 - 1. 말림비
이력서를 적으려고 하다 보니, 분명 지금의 나를 만드는데 많은 역할을 했지만, 이력서에는 기록되지 않을 일들이 참 자잘하게 많다. 이야기들을 소소하게 정리해서 블로그에 올려두려고 한다. 많은 이야기 중에도, 모든 이야기를 풀어가기 전에 말림비 이야기를 해야 한다. 저 유치하고도 올드한 이름은 2000년 가을에 시작해 2003년 어드매쯤 까지 내가 학교 내에서 운영했던 BBS의 이름이다. 2000년의 나는 지금 돌아보면, 트롤과 야생 원숭이 정도가 아니었을까. 학내에서 가장 큰 BBS였던 포스비(PosB)에 그렇게나 많은 글들을 도배하던, 천천클럽에 가입하겠다며1 아무 말을 쏟아내던 시절이었다. 결국, 전원이 기숙사 생활을 하는 학교의 특성항 온라인과 오프라인이 구분되지 않는 환경에서 여러 잡음(혹은 잔소리)이 들리기 시작했고, 나는 좀 더 자유롭게 말할 수 있는 환경을 직접 만들어야겠다고 생각했다. 말림비의 시작이었다. ...
서비스를 위한 도메인
이런 이야기를 굳이 남겨야 하나 싶지만, 누군가에게는 몰랐던 이야기가 될 수 있어서 몇 자 남겨둔다. 서비스 개발시 도메인은 충분히 많이 상위 도메인 하나로 모든 개발환경을 사용하는 팀들이 있다. 개발환경을 sub 도메인으로 분리라도 하면 다행인데, uri의 일부 prefix 정도로 구분하는 경우도 있다. 이런 경우 몇 가지 상황이 발생한다. 하나, 각종 브라우저 및 여러 인터넷 관련 도구들은 도메인 정확히는 eTLD - https://developer.mozilla.org/en-US/docs/Glossary/eTLD 혹은 Public Suffix를 기준으로 각종 정책을 적용한다. 대표적인 예는 브라우저의 쿠키다. 모든 개발환경에 도메인을 같이 사용하는 경우 각 환경이 이런 부분에서 서로에게 영향을 주게 된다. 또 각 환경별 도메인의 eTLD level(sub domain의 레벨, example.com = eTLD+1, sub.example.com = eTLD+2)가 달라지는 문제도 있다. 이로 인해 버그가 재현되지 않거나, 불필요한 기능을 추가하거나, 개발환경 때문에 생기는 문제를 버그로 오인할 수 있다. ...
강남역에서 부산역으로 가려면 서쪽으로 가야 하나 동쪽으로 가야 하나?
강남역에서 부산역으로 가려면 서쪽으로 가야 하나 동쪽으로 가야 하나? 이런 질문을 받는다면 어떻게 답할 것인가? 쉽게는 경부고속도로를 타기 위해서 서쪽으로 간다고 말할 수도 있다. 혹은 동쪽으로 가서 중부 고속도로를 타는 것이 낫다고 말할 수도 있다. 동도 서도 아닌 일단 남쪽이라고 말하는 사람도 있겠고 서울역쪽으로 가서 기차를 타겠다고 말하는 사람도 있을 것이다. 하지만, 누군가 한겨울에 반팔에 자전거를 타고 이런 질문을 한다면 조금 다른 것들을 답하게 될 것이다. 지금 바로 출발할 것인지, 왜 부산에 가려고 하는지, 예산은 어떻게 되는지 등 더 많은 질문과 현황을 파악한 다음에야 답을 하게 될 것이다. 그리고 그 답은 교통에 대한 정보 일 수도 있지만, 가까운 자전거 보관소에 대한 정보가 될 수도 있고, 내 옷을 벗어주는 것이 될 수도 있다. ...
점찍기 (혹은 제사 지내기)
쉬는 시간이 다시 찾아왔다. 이번 휴식기엔 3d 프린터를 이용해서 스도쿠 푸는 것을 만들었다. 어떻게 지내냐고 묻는 사람들에게 로봇의 동작하는 영상을 보여줬었다. 어떤이들은 ‘오오’하며 놀래는 반응을 보이고 어떤이들은 탄식에 가까운 그러니깐 또 쓸데없는걸 열심히 만들었구나 하는 반응이었다. 사실 내가 만든 것은 기존의 방식으로 테스트할 수 없는 앱을 테스트하기 위한 도구를 만든 것이었고, 수도쿠를 푸는 것은 예시중 하나였다. 해외에는 관련 서비스를 서비스하는 회사도 있고, 사실 몇몇은 이런 포인트를 이해해서, 가볍게 이야기 하기도 했었다. 관련 내용은 별도로 적어 두었다. ...
레시피: 하드웨어 기반의 저비용 모바일 앱 테스트 자동화
Table Of Contents Introduction Background 3D프린터 / plotter G-code 터치 디스플레이 3D 프린터를 이용한 테스트 준비 예시 닫는 글 Introduction 모바일 앱을 테스트하고 버그를 찾는 것은 어렵습니다. 모바일 환경 특성상 변수가 많고, 폐쇄적이기 때문입니다. 물론, 각 제조사들은 테스트를 위한 다양하고도 적극적으로 디버깅을 위한 도구와 API를 제공하고 있습니다. 또, 이를 더 쉽게 활용가능하게 해주는 appium과 같은 자동화 framework의 개발과 활용도 활발히 진행중입니다. 그러나 이러한 UI 자동화 테스트에는 한계가 있습니다. 우선 보안과 저작권 침해와 같은 시스템의 악용과 같은 다양한 이유로 모든 제어 방식에 대해서 API가 제공되는 것은 아닙니다. 여러 앱을 오가거나, 개발용앱과 상용앱을 오가는 경우를 생각해 볼 수 있습니다. 3rd party library/service를 사용하는 경우나 새로운 주변기기를 개발하는 경우에도 API를 이용한 테스트는 어렵습니다. 또, 각종 보안모듈은 API를 오동작하게 만들거나, 동작이 불가능하도록 설계되어 있습니다. ...
슬랙으로 에어컨을 켜고 끄는 것의 의미
계절이 바뀌면 글을 좀 올려야지 했는데, 계절이 이렇게 한바퀴라 돌 줄은 몰랐다. 오래간만에 2017년 여름 facebook에 올렸던 글을 조금 손봐서 올린다. 그때 만든 IR LED with Raspberry PI 며칠 전에 오래간만에 또 원격으로1 에어컨을 켜고 끄는 장치를 만들었다. 여름이 오는 소리가 들리면 누구는 매실을 담그고 누구는 여름옷을 살 텐데 내게는 에어컨 리모컨을 만드는 것이 여름을 맞는 행동이 된 거 같다. 2년 만에 만들고 나서 보니 왜 내가 처음 채팅으로 에어컨을 켜고 끄는 것을 만들었는지 이제는 이야기해도 될 것 같다는 생각이 들어서 이렇게 몇 마디 남긴다. 페이스북이 그 이야기를 올릴지 3년 되었다고 말도 해주었고 말이다. ...
버스와 사람
버스 팩터는 사람이 갑자기 자리에서 빠지는 경우 몇 명이 동시에 빠져야 인원의 부재가 팀에 문제가 되는가에 대한 지표이다. 보통의 1인 기업은 모든 면에서 버스 팩터가 1이고, 미국 대통령직은 승계 제도가 있으니 17 정도 될 것 같다. 이 단어의 어원1을 그리 좋아하지는 않지만, 그렇다고 복권 팩터2라고 적으면 왠지 느낌이 살지 않는다. 버스 팩터가 크다는 것은 그만큼 팀이 유연하다는 것이다. 하지만 버스 팩터를 늘리는 데는 비용3이 들고, 보통은 원하는 버스 팩터가 크면 클수록 더 많이 들어간다. 그러니 버스 팩터가 크면 클수록 좋다라거나 버스 팩터를 무한히 키워야 한다 라고 쉽게 말할 수는 없다. ...
좋은 코드
기준과 현실 좋은 코드에 대한 다양한 기준이 있지만, 나는 좋은 코드를 논할 때 가장 기본이 되어야 하는 것은 문제 해결의 여부라고 생각한다. 문제를 정의한 다음 해결을 위한 방법을 논한 프로그램의 구조와 구현에 대해서 논해야 한다. 그렇지 않으면 단순한 코드의 미에 대한 평가 그 이상은 힘들다. 문제를 해결 못하는 코드가 나오는 대표적인 이유 중 하나는, 문제 정의가 부실하기 때문이다. 책이나 과제와 달리, 현실에서는 문제 정의가 없거나, 부분만 되어 있거나, 문제가 변하는 속도를 고려하지 않거나, 협업자들이 같은 정의를 공유하지 못하는 일 들이 생긴다.1 구조를 만들고 코드를 짜기 전에 문제와 주어진 조건은 어떤 것인지 충분히 질문하고 목표를 고정해야 하지만, 욕심이 앞서 있거나, 질문에 실패했거나, 경험이 부족하거나, 현재가 불안한 이들은 문제 해결을 위한 목표 대신 자신을 위한 목표나 자신이 할 수 있는 것을 담는다. 조건보다 과한 오버 테크놀로지, 지적 과시를 위해 과하게 축약된 코드, 확장성이 보장되지 않아 수정을 위해서 처음부터 다시 작성해야 하는 1회성 코드, 필요한 성능이 안 나오는 설계는 이렇게 나온다. ...