스토리 홈

인터뷰

피드

뉴스

조회수 758

순서대로 척척, ORDER BY

ORDER BY 는 원하는 순서대로 자료를 출력하고 싶을 때 사용합니다. 편의를 위해 이전 글의 예제에서 MBR_NM 의 INDEX 인 IX_MBR_BAS_02 를 제거하고 진행하겠습니다. 이번 글에서는 이해-적용-출력-활용의 순서로 살펴볼게요. 지난 글 보기: 단일 TABLE을 SELECT하자!이해: ORDER BY의 오름차순과 내림차순SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 기본적인 ORDER BY는 위와 같이 사용합니다. 오름차순과 내림차순으로도 정렬할 수 있습니다. 오름차순일 때는 컬럼 뒤에 옵션을 넣지 않거나 ASC를 사용하고, 반대로 내림차순일 때는 DESC를 사용하면 됩니다.[오름차순]ORDER BY      MBR_NM ORDER BY      MBR_NM ASC [내림차순]ORDER BY      MBR_NM DESC 위의 Query(오름차순) 의 실행계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)내림차순 Query의 실행 계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)오름차순과 내림차순 정렬 Query를 보면 실행계획은 같고 결과는 다르게 나타납니다.실행계획을 보면 이렇게 표시됩니다.- table : TB_MBR_BAS - type : ALL - Extra : using filesort Extra의 using filesort는 DBMS에서 정렬을 한다는 의미로 퀵소트 알고리즘을 사용합니다. 실행계획의 내용을 풀어보면 “TB_MBR_BAS 을 전부(ALL) 읽은 후 정렬한다(using filesort)” 정도로 보면 됩니다.적용: INDEX와 정렬의 관계이번에는 삭제했던 MBR_NM의 INDEX인 IX_MBR_BAS_02를 다시 생성하고 수행해보겠습니다.CREATE INDEX IX_MBR_BAS_02 ON test.TB_MBR_BAS (MBR_NM); SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; INDEX를 생성하고 실행계획을 보면 아래와 같이 표시됩니다.실행계획을 보면 몇 가지 달라진 게 눈에 띕니다.1. type : ALL -> index 2. key : 없음 -> IX_MBR_BAS_02 3. Extra : using filesort -> Using index 특히 Extra는 using filesort에서 Using index 로 바뀐 것을 알 수 있습니다. using filesort가 정렬을 한다는 것인데, 정렬을 하지 않고 어떻게 정렬해서 보여준다는 것일까요? INDEX를 이해하면 바로 알 수 있습니다. 일반적인 INDEX는 기본이 BTree INDEX 입니다. MySQL의 BTree INDEX는 오름차순 정렬 상태로 저장되어 있습니다. 이미 정렬한 상태로 저장되어 있는 INDEX를 사용하기 때문에 Query를 수행할 때 다시 정렬할 필요가 없죠. 그래서 using filesort가 나타나지 않는 겁니다.출력: Query 실행다음으로 성이 김 씨인 사람들의 이름을 순서대로 출력해보겠습니다. 여기서는 두 가지 Query를 이용해 비교해보겠습니다.예시 1)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE MBR_NM LIKE '김%' ORDER BY     MBR_NM  ; 예시 2)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE SUBSTR(MBR_NM,1,1) = '김' ORDER BY     MBR_NM  ; 예시를 보면 WHERE 절이 다릅니다. 예시1은 “MBR_NM이 ‘김’으로 시작하는 것을 오름차순 정렬해 보여주라는 것”이고, 예시2는 “MBR_NM의 첫 번째 글자가 ‘김’인 것을 오름차순 정렬해 보여주라는 것”입니다.이제 두 개의 Query 실행계획을 비교해보겠습니다.예시 1)예시 2)여기서 주의 깊게 봐야 할 컬럼은 type입니다. 다른 컬럼들은 TB_MBR_BAS의 테이블을 조회하면서 IX_MBR_BAS_02 INDEX만을 사용해 보여주겠다는 내용을 갖고 있습니다. IX_MBR_MAS_02 INDEX가 MBR_NM으로 정렬되어 있기 때문에 using filesort가 나타나지 않은 것입니다. 그렇다면 type에 range와 index는 어떤 차이가 있는 것일까요?range : where 조건에 조회하는 범위가 지정된 경우 나타납니다.예시1은 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX의 MBR_NM에서 ‘김’이 시작되는 위치부터 끝나는 위치까지 조회해 보여주라는 의미입니다. IX_MBR_BAS_02 INDEX를 이용해 ‘김’이 시작되는 위치로 바로 접근할 수 있는 것이 핵심입니다.index : index를 처음부터 끝까지 읽는다는 의미입니다.예시2는 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX를 순서대로 읽어서 MBR_NM의 첫 글자가 ‘김’인 것을 보여주라는 의미입니다.두 개의 차이점을 꼽자면, range는 원하는 범위로 바로 접근해 값을 가져올 수 있는 것이고, index는 처음부터 끝까지 읽어서 그 값이 조건에 맞을 경우 가져오라는 것입니다. 따라서 예시1이 휠씬 성능이 뛰어난 Query라고 볼 수 있습니다. 결과는 모두 아래와 같이 출력됩니다.수행시간은 차이를 보였습니다. 예시1은 0.0041초, 예시2는 0.5초였는데요. 예시에서는 건수가 적기 때문에 큰 차이가 없는 것처럼 보이지만, 자료가 10배 또는 100배 많아진다고 생각해보세요. 엄청난 차이겠죠.활용: Query를 만들고 DISTINCT !마지막으로 Query 하나를 만들어보겠습니다. 1) MBR_NM의 중복을 제거하고2) 김 씨이면서3) 이름이 ‘혜’로 시작하는 사람을 먼저 출력하고4) 이외의 사람은 그 다음부터 오름차순으로 출력하려면 어떻게 만들어야 할까요?중복을 제거할 때는 일반적으로 DISTINCT 와 GROUP BY 두 가지를 사용합니다. 이번 글에서는 DISTINCT를 사용하겠습니다. 다음으로는 오름차순 정렬할 때 김 씨를 먼저 출력하는 것인데 조건문을 사용하여 김 씨인 것과 아닌 것을 구별해 우선순위를 주겠습니다. 다른 것은 위의 Query를 이행하면 됩니다. 먼저 DISTINCT를 넣고 수행해 보겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 실행계획은 다음과 같습니다.DISTINCT를 수행하면 Extra가 나타나며 group by로 표시됩니다. 여기서는 IX_MBR_BAS_02를 이용하여 gorup by(중복제거)하여 보여준다는 의미입니다. 수행하면 다음과 같은 값이 나옵니다.다음으로는 MBR_NM이 ‘김혜’로 시작하는 것을 먼저 보여주기 위해 ORDER BY 절에 CASE WHEN문을 사용하겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     CASE         WHEN MBR_NM LIKE '김혜%'    THEN 0         ELSE 1     END     ,MBR_NM  ; 실행계획은 다음과 같습니다.ORDER BY에 조건이 들어가면서 INDEX의 순서대로 정렬한 것을 그대로 보여줄 수 없기 때문에 Extra에 Using temporary, Using filesort가 나타납니다. Using temporary는 가상 테이블을 만들어 사용하는 것인데, 다시 말해 가상 테이블을 만들어 다시 정렬하는 것입니다. 이에 대한 출력값은 다음과 같습니다.‘김혜’로 시작하는 사람이 먼저 나왔군요.글을 마치며지금까지 ORDER BY와 연관된 조건 처리를 알아봤습니다. 데이터를 더욱 체계적으로 나타내고 싶으신가요? ORDER BY를 이용해서 원하는 목적을 달성해보세요.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유
조회수 2648

스타트업 CTO의 일

최근 다음과 같은 고민이 깊어졌다."나는 잘하고 있을까?""내가 지금 해야만 하는 중요한 일은 무엇일까?""나의 역할은 어디까지고, 무엇을 위임해야 할까?""어떤 사람을 채용해야 할까?"팀의 구성원이 떠나기도 했고, 회사도 여러 가지 도전을 받고 있으며, 나 자신의 정체도 느끼는 것이 고민의 시작이다. 위 질문들의 공통된 뿌리는 “나의 일은 무엇인가?”라는 질문이다.'나의 일'이라는 것은 '스타트업 CTO의 일'이다. 하지만 모든 스타트업의 CTO가 하는 일이 나와 같지는 않다. 스타트업은 다양한 단계가 있고, 목표로 하고 있는 시장도 제각각이다. 가지고 있는 기술, 목표로 하는 기술도 다르고, 구성원 또한 제각각이기 때문이다. 하지만 어느 정도 공통점이 있을 거라 생각한다. 혹시 이 글을 어느 스타트업의 CTO가 읽으신다면 자신의 일과 비교를 해봐 주시길 부탁드린다.본격적으로 시작하기 전에 이 글은 내가 앞으로 겪을 경험에 따라 많이 바뀔 수 있음을 미리 알려둔다.CTO?Chief Technology Officer의 준말이다. 경영진 중의 한 명으로 회사에서 기술과 관련된 모든 일을 관리, 책임진다. 여기에서 '기술과 관련된 모든 일'이라는 모호한 것을  들여다보기 위해서는 CTO의 역할을 좀 더 나눠 볼 필요가 있다. 다음과 같이 나눠보고 각각에 대해서 살펴보자.Technical Leader - 최고의 엔지니어Technical Businessman - 기술조직과 사업조직의 가교Team Manager - 팀장Product Manager - 프로덕트 관리자Technical Leader보통 CTO라 하면 가장 먼저 떠올리게 되는 역할이다. 기술기업의 경우 핵심 기술역량을 보유하고 있거나, 서비스 기업의 경우 주도적으로 서비스를 개발/운영해본 경험이 있어야 한다. 다음과 같은 역할이 요구된다.1) 기술 비전과 로드맵회사의 기술 비전을 세우고, 그 비전을 달성하기 위한 로드맵을 정하고 실행해야 한다. 실행을 위해서 기술 조직에 비전을 전달하고 공감을 얻어 낼 수 있어야 한다.2) 아키텍트회사가 만드는 서비스 아키텍처를 만들고 발전시켜 나가야 한다. 동시에 이 서비스가 동작하는 인프라 아키텍처를 셋업하고 견고하게 만들어야 한다. 이를 위한 개발 스택들을 결정하고 적용해야 한다.3) 좋은 기술 코치팀이 기술적으로 성장할 수 있는 환경을 갖추고 코칭을 해야 한다. 팀의 구성원이 기술적 목표를 높게 유지할 수 있도록 해야 한다.4) 시니어 개발자시니어 개발자로 다음과 같은 역할을 해야 한다.· 팀이 현재 겪고 있는 가장 어려운 문제를 풀 수 있어야 한다.· 회사의 핵심 기술을 이해하고 높은 퍼포먼스로 제품을 만들어야 한다.· 개발 효율을 높일 수 있는 환경을 갖춰야 한다. (DevOps)· 문서화를 해야 한다.Technical Leader로서 위와 같은 일들을 잘 하게 되면· 고도화되더라도 효율이 떨어지지 않는 시스템· 높은 제품의 성능· 높은 기능적 완성도· 경쟁력 있는 기술과 그 기술을 갖춘 팀을 얻을 수 있다. 위 일들은 조직이 커지게 되면 팀의 시니어 개발자들이 점점 나누어 가지게 된다. (단, '기술 비전과 로드맵'을 제외하고) 다르게 말하면 반드시 위의 역할을 잘 나누어 가질 수 있는 사람을 시니어 개발자로 채용해야 한다.Technical Businessman대부분의 스타트업은 기술을 기반으로 시장의 문제를 해결(=사업)한다. CTO는 기술조직과 사업조직이 함께 잘 굴러가기 위한 가교 역할을 해야 한다. 이를 위해서는 회사의 사업에 대한 이해와 사업적인 센스가 필요하다.1) 기술적인 조언시장의 문제를 기술적으로 해결하고자 한다면, 기술조직에서 아이디어가 나와야 한다. CTO는 보통 가장 많은 아이디어를 사업조직에 제공해야 한다. 또한 회사가 새로운 일을 시작하고자 할 때, 그 일이 기술적으로 가능한 일인지, 어느 정도 크기의 일인지를 추정해야 한다. 비록 추정이 조금 부정확하더라도 추정이 있어야 사업적 판단을 할 수 있다. 그리고 회사에서 그 추정을 가장 잘 해야 하는 사람이 CTO다.2) 사업을 기술조직에 전파“나는 왜 이것을 개발해야 하는가?”에 대한 개발자의 질문에 답을 해주어야 한다.(정확히는 물어보기 전에 알려주어야 한다.) 이 일을 하는 사업적인 이유를 충분히 설명해 주어야 개발자는 동기를 얻고, 정해진 것 이상의 것을 만들어 낼 수 있다.3) 기술을 다른 조직에 전파회사가 가진 기술을 다른 조직에 전파해서 충분히 이해할 수 있도록 해야 한다. 그래야 기술이 아이디어를 만나 빛을 발하고 회사의 가치가 높아진다.Technical Businessman으로 위와 같은 일들을 잘하게 되면 회사가 가진 기술이 사업에서 효과적으로 사용된다. 그리고 사업을 위해 필요한 기술이 기술조직에서 발전하게 된다. 이 일들은 조직이 커지게 되면 역시 시니어 개발자와 프로젝트 관리자에 의해서 대체될 수 있다.Team Manager일반적인 팀장/조직장이다. 이 역할을 잘 수행하기 위해서는 커뮤니케이션 능력, 시간/리소스 관리 능력을 갖추어야 한다.1) 채용좋은 개발자를 채용해야 한다. 이를 위해서는 다음과 같은 기본적인 일을 해야 한다.· 채용 공고를 작성하고 올린다.· 면접을 진행하고 채용을 결정한다.· 좋은 사람을 소개받고 만난다.채용을 위해서는 장기적으로는 회사의 '기술 브랜드', '기업 문화'를 만들어 나가는 것이 도움이 된다. 물론 이런 것 보다 회사가 로켓처럼 날아가는 게 효과는 훨씬 더 좋다.2) 인력의 유지어렵게 뽑은 인력을 잘 유지해야 한다.  · 개인의 비전과 회사의 비전을 일치시키기 위해 노력한다. 다른 말로는 동기부여라고 한다.· 개인의 조직 내 성장을 돕는다.· 개인이 회사에서 만나게 되는 문제를 해결해 준다.물론 충분한 대우를 해주는 것도 중요하다.3) 자원의 산정과 확보프로젝트가 시작되기 전에 프로젝트에 필요한 인적, 물적 자원을 구체적으로 산정한다. (위의 Technical Leader가 하는 초기 결정을 위한 추정과는 다르다.) 대부분의 경우 어떤 사람이 어떤 일을 할 것인가를 결정짓는 일이다. 그리고 개발 혹은 운영에 필요한 추가적인 자원들을 준비한다. 장비가 될 수도 있고, 외부 서비스가 될 수도 있다.4) 일정의 계획과 관리일정을 계획하고, 관리한다. 다른 팀 혹은 외부와 의존성이 있는 경우 특히 이런 부분들을 잘 관리해서 일정이 차질 없이 진행이 될 수 있도록 한다. 프로젝트의 진행상황은 시각화하여 공개적으로 확인할 수 있도록 한다.5) 업무 프로세스 개선업무 프로세스를 개선해서 효율적으로 일할 수 있도록 해야 한다. 이를 위해서는프로젝트 관리 도구의 도입이슈 트래킹 시스템 도입스크럼/칸반등의 개발 방법론을 도입하고 운영등이 필요하다.3), 4), 5)는 우리가 일반적으로 프로젝트 관리자(PM)라 부르는 사람의 역할이기도 하다.이 일을 잘하게 되면회사에 필요한 인적 구성/역량을 갖춘 기술 조직을 유지할 수 있다.팀이 효율적으로 일할 수 있다.타 팀과 조화롭게 일할 수 있다.팀이 진행하는 프로젝트를 성공으로 이끌 수 있다.이 일들은 조직이 커지게 되면 중간 관리자, PM, HR 담당자가 생기면서 대체될 수 있다.Product Manager팀이 고객들이 원하는 제품을 전달하게 한다. 이 역할을 잘하기 위해서는 사업, 기술에 더해 UX에 대한 이해가 추가로 필요하다. (인터넷 서비스의 경우)1) 고객에 대한 이해고객을 보다 잘 알기 위한 노력을 해야 한다. 이를 위해서는 서비스에 관련된 지표들을 지속적으로 관찰해야 한다. 또는 인터뷰, 고객 대응 등을 통해 고객의 소리를 직접 듣는다.2) 고객의 대변자고객이 원하는 바를 명확하게 적은 스펙 문서를 작성해서 메이커에게 전달해야 한다. 또한 애매한 사항들이 있을 때 이를 최종적으로 결정해야 한다. 때로는 고객을 대신해서 제품에 대한 쓴소리를 해야 한다.3) 제품의 비전과 로드맵"우리는 어떤 제품을 만들어 갈 건가요?"라는 질문에 답을 할 수 있어야 한다. 즉, 제품의 비전을 구축해야 하고 이를 위한 구체적인 로드맵을 만들고 실행해야 한다. 이 비전을 조직에 전파하고 공감을 얻어야 한다.4) 우선순위의 결정사업, 고객의 측면에서 때로는 기술/디자인 부채를 없애기 위한 메이커의 입장에서 우선순위를 결정해야 한다.각 구성원 간의 이해관계가 부딪치는 부분이다. 효과적인 커뮤니케이션을 통해 슬기롭게 해결해 가야 한다.5) 제품의 퀄리티제품의 퀄리티를 책임진다. 직접 QA도 하고 디테일을 챙겨서, 구성원들이 높은 퀄리티를 목표로 할 수 있도록 해야 한다.이 역할을 잘하게 되면 좋은 제품을 만들어서 고객들의 호응을 이끌어 낼 수 있다. 또한 제품을 만드는 구성원들이 만족감을 얻을 수 있다. 이 역시 조직이 커짐에 따라 기획자, UX 디자이너가 일부 역할을 대체할 수 있으며 Product Manager를 뽑을 수도 있다.마치며스타트업의 CTO가 해야 하는 일은 이렇게 많다. 사실 스타트업 초기에는 위에서 말한 모든 것이 필요하지는 않다.(일단 컴퓨터를 사고, WIFI 설정도 하고..) 하지만 회사와 조직이 성장함에 따라 각각의 역할은 점점 중요해진다. 적당한 시기에 이 역할들을 위임하지 못하면 구멍이 생기기 시작하면서, 결국 여러 가지 중 하나도 제대로 챙기지 못하는 상황이 발생하게 된다. 이렇게 일을 정리하고 보니 지금의 내가 그런 상황이 아닌가 싶다.그럼 이제 내가 해야 하는 일은 동료들에게 적극적으로 도움을 요청해야 하는 것이다. 동료들도 내가 손을 내밀기를 기다리고 있을 거라 생각한다. :)  · 마지막으로 타이틀 이미지는 최근 프로덕트 그룹 워크샵에서 디자이너님의 타이포 세미나 때   제가 직접 그려 본 것입니다.#8퍼센트 #에잇퍼센트 #스타트업CTO #CTO #일상 #하루 #관리자
조회수 1815

안드로이드 스튜디오

안녕하세요. 크몽 개발팀 입니다.오늘의 포스팅 주제는 "안드로이드 스튜디오" 입니다.안드로이드 스튜디오는 구글이 직접 만든 안드로이드 앱 개발 도구를 말하는데요.안드로이드 스튜디오는 2013년 5월 개발자 컨퍼런스를 통해 프리뷰 버젼을 처음 공개하였습니다.1년 6개월 정도의 기간동안 베타버전이였지만  지난달 8일에  안정화된 정식버전 1.0이 공개되었습니다.안드로이드 개발자 사이트에 가시면 공식적으로 다운받아서 안드로이드 앱을 개발 할 수 있습니다.( Eclipse로 앱을 개발중인데 개발자 사이트에 배포중인 ADT가 내려가서 당황했던 기억이 나네요^^ ) 안드로이드 스튜디오는 IntelliJ 기반으로 만들어 졌는데요.IntelliJ는 워낙 유명한 개발도구인지라 많은 개발자분들이 알고 계실겁니다.Eclipse 와 같이 통합개발툴인데 안정성과 속도면에서 Eclipse보다 뛰어나기때문입니다.하지만 Eclipse가 안드로이드 초기부터 개발자들이 이용해 왔기 때문에 대부분의 개발들에게 익숙하고현재 나온 가이드 or Tip 들이 Eclipse에 기준이 되어있어서 여러부분에서 시행착오를 겪을거 같습니다.그래서 그런지 안드로이드 스튜디오 정식버젼이 나왔지만 아직은 익숙한 Eclipse에 손이가는데요.앞으로 구글에서 공식적으로 ADT에 대한 지원을 끊었으니 조만간 안드로이드 스튜디오로 갈아탈려고 합니다.Android 개발자 사이트 링크 : http://developer.android.com/index.html----------------------------------------------------------------------------------------새롭게 나온 안드로이드 개발도구 "안드로이드 스튜디오"에 대하여  소개하는  포스팅 해보았습니다.다음에는 안드로이드 스튜디오를 직접 사용해보고 각각의 특징들에 대해좀 더 자세히 설명해드리겠습니다. ^_^#크몽 #개발팀 #인턴 #인턴생활 #팀원소개 #업무환경
조회수 1625

PyCon2017 첫번째날 후기

아침에 느지막이 일어났다. 어제 회사일로 피곤하기도 했지만 왠지 컨디션이 좋은 상태로 발표를 하러 가야지!라는 생각 때문에 깼던 잠을 다시 청했던것 같다. 일어나 아침식사를 하고 아이 둘과 와이프를 두고 집을 나섰다. 작년 파이콘에는 참가해서 티셔츠만 받고 아이들과 함께 그 옆에 있는 유아교육전을 갔었기에 이번에는 한참 전부터 와이프에게 양해를 구해둔 터였다.코엑스에 도착해서 파이콘 행사장으로 가까이 가면 갈수록 백팩을 메고, 면바지를 입고, 영어 글자가 쓰인 티셔츠를 입은 사람의 비율이 높아지는 것으로 보아 내가 제대로 찾아가고 있구나 라는 생각이 들었다.늦게 왔더니 한산하다.지난번에는 입구에서 에코백과 가방을 나눠줬던 것 같은데 이번에는 2층에서 나눠준다고 한다. 1층이 아무래도 복잡해지니 그런 것 같기도 하고, 2층에서 열리는 이벤트들에도 좀 더 관심을 가져줬으면 하는 것 같기도 하다. 우선 스피커 옷을 받고 싶어서 (솔직히 입고 다니고 싶어서) 2층에 있는 스피커방에 들어갔다.허락 받지 않고 사진찍기가 좀 그래서 옆방을 찍었다첫 번째 키노트는 놓쳤지만 두 번째 키노트는 꼭 듣고 싶었기에 간단히 인사만 하고 티셔츠를 들고 나왔다. (외국에서 오신 연사분과 영어로 대화를 나누고 있어서 자리를 피한것은 아니다.) 나가는 길에 보니 영코더(초등학교 5학년 부터 고등학생 까지 파이썬 교육을 하는 프로그램)을 진행하고 있었다. 의미있는 시도를 하고 있다는 생각이 들었다.이 친구들 2년 뒤에 나보다 잘할지도 모른다.키노트 발표장에 갔더니 아웃사이더님이 뒤에 서 게셨다. 지난 파이콘 때 뵙고 이번에 다시 뵈었으니 파이콘이 사람들을 이어주는 역할을 하는구나 싶었다.키노트에서는 현우 님의 노잼, 빅잼 발표 분석 이야기를 들을 수 있었다. 그리고 발표를 통해 괜히 이것저것 알려줘야만 할 것 같아 발표가 부담스러워지는 것 같다는 이야기를 들었다. 나 또한 뭔가 하나라도 지식을 전달해야 한다는 압박감을 느끼고 있었던 터라 현우 님의 키노트 발표를 듣고 나니 좀 더 오늘을 즐겨야겠다는 생각이 들었다.오늘은 재미있었습니다!현우님 키노트를 듣고 같은 시간(1시)에 발표를 하시는 경업님과 이한님 그리고 내일 발표이신 대명님, 파이콘 준비위원회를 하고 계신 연태님과 함께 식사를 하러 갔다. 가는 길에 두숟갈 스터디를 함께 하고 계신 현주님과 희진 님도 함께했다. 사실 이번에는 발표자도 티켓을 사야 한다고 해서 조금 삐져 있었는데 양일 점심 쿠폰을 주신다고 해서 삐진 마음이 눈 녹듯이 사라졌다.부담 부담식사를 하고 발표를 할 101방으로 들어가 봤다. 아직 아무도 없는 방이라 그런지 괜히 긴장감이 더 생기는 느낌이다. 발표 자료를 열어 처음부터 끝까지를 한번 넘겨 보고 다시 닫았다. 처음에는 가장 첫 발표라 불만이었는데 생각해보니 발표를 빨리 마치고 즐기는 게 훨씬 좋겠다는 생각이 들었다. 발표 자료를 다듬을까 하다가 집중이 되지 않아 밖으로 나갔다. “열린 공간” 현황판에 충동적으로 포스트잇을 하나 붙이고 왔다. 어차피 발표는 나중에 온라인으로도 볼 수 있으니까 사람들과 이야기를 나눠 봐야 겠다 싶었다. (내 발표에는 사람이 많이 왔으면 하면서도, 다른 사람의 발표는 온라인으로 보겠다는 이기적인 생각이라니..)진짜 궁금하긴 합니다다시 발표장으로 돌아왔다. 왠지 모르는 분들은 괜찮은데 아는 분들이 발표장에 와 계시니 괜히 더 불안하다. 다른 분들은 발표자료에 짤방도 많이 넣으셨던데.. 나는 짤방도 없는 노잼 발표인데.. 어찌해야 하나. 하지만 시간은 다가오고 발표를 시작했다.얼굴이 반짝 반짝리허설을 할 때 22분 정도 시간이 걸렸던 터라 조금 당겨서 진행을 했더니 발표를 거의 20분에 맞춰서 끝냈다. 그 뒤에 몇몇 분이 오셔서 질문을 해주셨다. 어리버리 대답을 한 것 같다. 여하튼 내 발표를 찾아오신 분들께 도움이 되었기를. 그리고 앞으로 좀 더 정확한 계산을 하시기를.대단히 발표 준비를 많이 하지도 못하면서 마음에 부담만 쌓아두고 있는 상황이었는데, 발표가 끝나니 아주 홀가분한 마음이 되었다. 발표장을 나가서 이제 부스를 돌아보기 시작했다. 매해 참여해 주고 계신 스마트스터디도 보이고 (정말 안 받고 싶은 ‘기술부채’도 받고 말았다.) 쿠팡, 레진 등 친숙한 회사들이 많이 보였다. 내년에는 우리 회사도 돈을 많이 벌어 여기에 부스를 내고 재미있는 이벤트를 하면 좋겠다는 생각이 들었다.부스를 돌아다니다가 이제 파이콘의 명물이 된 내 이름 찾기를 시작했다. 이름을 찾기가 쉽지가 않다. 매년 참여자가 늘어나서 올해는 거의 2000명에 다다른다고 하니 파이썬 커뮤니티의 성장이 놀랍다. 10년 전에 파이썬을 쓸 때에는 그리고 첫 번째 한국 파이콘이 열릴 때만 해도 꽤 마이너 한 느낌이었는데, 이제 주류가 된 것 같아 내 마음이 다 뿌듯하다. (그리고 내 밥줄이 이어질 수 있는 것 같아 역시 기쁘다)어디 한번 찾아보시라다음으로는 박영우님의 "Django admin site를 커스텀하여 적극적으로 활용하기” 발표를 들으러 갔다. (짧은 발표를 좋아한다.) 알고 있었던 것도 있었지만 커스텀이 가능한지 몰랐던 것들도 있어서 몇 개의 기능들을 킵해 두었다. 역시 컨퍼런스에 오면 내게 필요한 ‘새로운 것’에 대한 실마리를 주워가는 재미가 있다.익숙하다고 생각했지만 모르는것이 많다4시가 되어 OST(Open Space Talk)를 하기로 한 208B 방으로 조금 일찍 갔다. 주제가 뭐였는지는 잘 모르겠는데 주식 투자, Tensor Flow, 비트코인, 머신러닝 등등의 이야기들이 오가고 있었다. 4시가 되어 내가 정한 주제에 대해 관심 있는 사람들이 모였다. 괜히 모일 사람도 없는데 큰방을 잡은 것이 아닐까 하고 생각하고 있었는데, 생각보다 많은 분들이 오셨다.각 회사들이 어떤 도구를 사용하는지 설문조사도 해보고, 또 어떤 개발 방법론을 사용하는지, 코드 리뷰, QA는 어떻게 하고 있는지에 대한 이야기를 나눴다. 다양한 회사에서 다양한 일을 하는 사람들이 모여 있다 보니 생각보다 꽤 재미있게 논의가 진행되었다. 사실 내가 뭔가 말을 많이 해야 할 줄 알았는데, 이야기하고 싶은 분들이 많이 있어서 진행을 하는 역할만 하면 되었다. 마지막으로는 “우리 회사에서 잘 사용하고 있어서 다른 회사에도 추천해 주고 싶은 것”을 주제로 몇 가지 추천을 받은 것도 재미가 있었다.열심히 오간 대화를 적어두긴 했다5시에 OST를 마치고는 바로 집으로 돌아왔다. 오늘 저녁에 아이들을 잘 돌보고 집 청소도 열심히 해두어야 내일 파이콘에 참여할 수 있기 때문이다. 기대된다. 내일의 파이콘도.그리고 정말 감사드린다. 파이콘을 준비해주시고 운영해주고 계신 많은 분들께.#8퍼센트 #에잇퍼센트 #개발자 #개발 #파이썬 #Python #파이콘 #Pycon #이벤트참여 #참여후기 #후기
조회수 1561

[Tech Blog] Compare Software Architectures: Monoliths, SOA and Microservices

요즘 Software architecture 라는 단어를 들으면 아마도 Client engineer 분들은 MVC, MVP, MVVM 이 먼저 떠오를 것이고, Server engineer 분들은 Microservice architecture 를 먼저 떠오를 것 같네요. Clean architecture 나 Event-driven architecture 등을 떠올리는 분들도 계실 것 같구요. Software architecture 를 어떻게 정의할 수 있을지에 대해서는 Software architecture: The important stuff 에 적어 봤으니 여기에선 넘어가도록 하죠. https://mherman.org/blog/developing-microservices-node-react-docker/ Microservice architecture 는 대세라고 말할 수 있습니다. Netflix, Amazon 등 굴지의 기업들이 성공적으로 적용해서 운영하고 있고, 국내 기술적으로 뛰어난 많은 기업들 역시 이미 적용했거나 시도하고 있습니다. “남들 다 하는데 이러다 도태 되는거 아냐?” 라는 생각이 들 정도로 말이죠. 그러나 이전 글에서 얘기했듯이 정답은 없으며, Microservice architecture 역시 예외는 아닙니다. 모든 선택에는 Tradeoff 가 있고, Microservices 는 다른 architecture 에 비해 어떤 장점이 있는지 살펴봐야 합니다. 이와 관련하여 정말 많은 좋은 글들이 이미 있으니, 이 글에서는 몇 가지 Software architecture 들을 가볍게 정리 및 비교해 보도록 하겠습니다. Monolithic Architecture Monolithic architecture 는 Microservice architecture 의 장점을 얘기할 때 반드시 언급될 정도로 대척점에 있는 architecture 입니다. Monolithic architecture 는 하나의 큰 덩어리로 구성되어 있고, 모든 기능이 하나의 프로젝트에 집중되어 있습니다. 쉽게 구성이 가능하고 초기에 기능을 빠르게 추가하기에 용이하나, 복잡도가 늘어날수록 기능 추가 속도가 느려지고 문제가 발생할 가능성이 높습니다. PoC(Proof of Concept)를 위한 가벼운 프로젝트나 아주 초기 프로젝트에 적용 가능합니다. Semi-Monolithic Architecture Monolithic architecture 보다는 작지만, 여전히 기능들이 몇 개의 프로젝트에 집중되어 있는 architecture 입니다. 예를 들어 frontend 와 backend 프로젝트를 나누었지만 각 프로젝트가 monoliths 인 경우 semi-monolithic architecture 라고 볼 수 있습니다. 다만 Semi-monoliths 의 경우 몇 군데에서 언급한 것을 볼 수 있지만, 일반적으로 사용되는 architecture 용어는 아닌 듯하고, Semi-monoliths 로 구분될 수 있는 경우 Monolithic architecture 라고 분류할 수 있을 듯합니다. 단순 frontend / backend 보다 좀 더 많은 수의 service 로 분할된 architecture 를 구성하더라도 각 service 가 monoliths 로 구분될 수 있다면 여전히 monolithic architecture 를 구성하고 있다고 할 수 있습니다. Service-Oriented Architecture 여러 조직이 다수의 application 사이에서 로직과 데이터를 공유하기 위해 제안된 architecture 입니다. Monolithic architecture 와 달리 기능을 나눠서 여러 개의 서비스로 구성하고, 서비스 사이는 API 를 통해서 통신합니다. Microservice architecture 와 Service-oriented architecture (SOA) 를 비교하기 위해 Enterprise Service Bus (ESB)가 많이 언급됩니다. ESB는 Enterprise Application Interface (EAI) 와 대조적으로 가볍고 흔한 통신을 위해 제안되었으나, 통제와 관리를 위해 점점 무거운 방향으로 진행되면서 최초의 의도와 달라졌습니다. SOA 가 무거워짐에 따라 최초의 의도였던 빠른 적용, 민첩한 개발 및 적은 통합 비용과 멀어지게 되면서 자연스럽게 도태되었습니다. 서비스 사이에 데이터베이스를 공유할 수 있느냐 아니냐로 Microservice 와 구분을 짓는 의견도 있습니다만, SOA의 정의가 넓어서 이 부분에 대해서는 이견들이 있습니다.   https://dzone.com/articles/microservices-vs-soa-2 SOA가 넓은 범위에서 정의됐기 때문에 ESB 나 DB 공유 여부로 SOA 를 규정 짓기는 어렵습니다. 정의 상으로 보면 Microservice architecture 역시 SOA 의 일종이라고도 볼 수 있습니다. Microservice 의 예시로 자주 등장하는 Netflix 와 Amazon 역시 Microservice 라는 단어가 사용되기 전에는 스스로의 시스템을 SOA 라고 지칭했습니다. Microservice Architecture: The O’Reilly Book 의 공동 저자 Matt McLarty 는 Learn from SOA: 5 lessons for the microservices era 라는 글에서 SOA 와 Microservice architecture 가 같은가 다른가는 그다지 중요한 것이 아니며, 우리가 SOA 로부터 어떤 것들을 배웠는가가 중요하다고 강조합니다. Microservice Architecture Microservice architecture는 규모가 빠르게 커져도 제품 생산 속도를 빠르게 유지하고 안정성을 가질 수 있는 architecture 입니다. 충분히 작은 서비스들이 서로 통신하면서 기능을 수행합니다. Microservice architecture 를 SOA의 잘 구현된 형태라고 보는 시각도 있지만, micro 라는 단어가 SOA 에서 정의하는 서비스보다 작은 크기의 서비스임을 명시적으로 표현하기 때문에 매우 다르다는 의견 역시 있습니다. Microservice architecture 는 각 서비스의 크기를 작고 가볍게 유지함으로써 더 깔끔하고 명확하게 서비스를 유지할 수 있습니다. 잘 구성될 경우 특정 서비스에 장애가 생겨도 다른 서비스에 영향을 적게 미치거나 유연하게 대응할 수 있기 때문에 전체 시스템 오류(e.g Single Point of Failure)를 방지할 수 있습니다. 각 서비스는 독립적으로 배포 및 확장 가능하기 때문에 기능 배포가 빠르고 많은 트래픽에 유연하게 대처할 수 있습니다. 한편 Microsoft architecture 는 구조적인 면에서 복잡도가 증가하며, 많아진 서비스 및 서비스 간 통신에 대한 유지 보수 비용이 추가됩니다. 이를 대응하기 위해서 충분히 자동화되고 잘 구성된 시스템이 필수적으로 필요합니다. Conclusion 판단과 결정은 근거를 필요로 합니다. 가끔 감을 믿고 밀어붙여야 할 때(e.g 오늘 점심은 해장국을 먹어야 한다던가)도 있다는 점은 인정합니다. 하지만 그 역시 설득력을 가지지 못하면 하나의 목표를 향해 모두가 미친듯이 달려가기는 어렵겠죠. Software architecture 를 결정하기 위해서는 추구하는 비전과 비지니스를 이해하고 그에 맞는 근거 하에 모든 팀원을 판단하고 설득해야 합니다. 버즈빌 에서는 더 빠르고 큰 성장을 위해 Architecture Task Force 팀을 구성하였습니다. ATF 팀은 버즈빌에 최적인 Software architecture 를 판단하고, 구성하고, 실행하기 위해 바쁘게 움직이고 있습니다. Buzzvil Services Characteristic:  제품이 다양하고 제품별로 제공해야 할 기능이 많다. 각 제품이 공통적으로 필요로 하는 기능이 많다. 서비스 혹은 기능별로 대응해야 하는 트래픽이 다르다. 전체 서비스 장애 발생 시 많은 후속 문제가 발생한다. 트래픽 변동이 특정 이벤트에 의해 크게 일어날 수 있다.  Buzzvil 의 제품과 비지니스는 위와 같은 성격을 가지고 있습니다. 이를 바탕으로 우리는 Microservice architecture 가 가장 적절하다고 판단하였고, 현재 microservices 의 장점을 살리면서 안정적이고 빠르게 우리가 원하는 목표에 도달할 수 있도록 다양한 방면에서 변화를 가져가고 있습니다. References  Learn from SOA: 5 lessons for the microservices era Microservices vs. SOA On monoliths, service-oriented architectures and microservices Microservices.io Microservices Resource Guide Design Microservice Architectures the Right Way Developing Microservices – Node, React, and Docker    *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”
조회수 2837

레코딩 플러그인 이야기

마음챙김명상앱 '마보'의 콘텐츠들은 모두 Waves 플러그인으로 프로세싱된다.(처음과 마지막을 제외하면) Waves에 대해 간단한 생각을 정리하자면 다음과 같다.머큐리 구입시 UAD와도 고민을 많이 했지만 소프트웨어로만 비교를 한다면 waves가 훨씬 편하게 사용이 가능하다. 그 중에서도 CPU로 돌릴 수 있다는 점이 제온 CPU 에서 강력하게 작용한다.(Waves 하드웨어가 필요하다면 영국콘솔회사 DiGiCo와의 합작품인 DiGiGrid라는것도 있다.)근데 문제는... 맥에서는 더이상 CPU파워가 따라주지 않는다는 것이다.이런 상황에서 밖에서 작업하기에 딱 좋은 솔루션이 있었다. Soundgrid라는 waves의 DSP솔루션이다.이 사운드그리드에 대해 요약하면 waves의 플러그인만 따로 모아서 랜케이블로 Soundgrid 연결을 하면 CPU의 부담을 주지 않고 Daw에서 똑같은 프로세싱이 가능하다.이번에 BLS에서 데모로 받은 Waves Soundgrid IMPACT SERVER를 까페에 들고 나왔다.문제는 예상했던 사이즈가 아닌 맥북보다 훨씬 커서 카페에 가지고 다니기 부담스러운 크기... 휴대성이라는 측면에서는 역시 좀 무리가 있지 않나 싶다.(사진참조)어쨌든 카페에서 작업이 가능하게 되었다는 점. 다만, 카페에 가는데 차가 필요하다는 점이 있겠다.앞서 말했듯 마보 콘텐츠는 waves외에 플러그인의 시작과 끝을 Izotope 플러그인을 쓴다.마지막에는 라우드니스를 위해 오존을 사용한다. 오존은 너무 유명한 플러그인이니 설명도 생략.녹음이 끝나면 바로 첫단에 오디오스위트로 걸어주는 RX5라는 플러그인이 있다.이 플러그인은 보이스를 녹음한다면, 혹은 볼륨이 크지 않은 클래식 악기를 녹음한다면 정말 요긴하다.첫째로 입에서 발생하는 립노이즈들을 효과적으로 빠르게 제거해 준다. 콘덴서 마이크에서 타는 쩝쩝거리는 소리들을 손으로 하나씩 잡을 필요가 없다. 그저 한번 클릭으로 모든 파형의 클릭소리들을 제거해준다.Waves Mercury에도 X-Click이있지만 Izotope의 RX5가 훨씬 퀄리티가 좋다.두번째로 De-noise의 강력한 기능이다. 녹음시에 발생되는 팬소음들은 사실 EQ를 통해 어느정도 제거가 가능한 험의 형태로 발생한다면, 전기적 접지의 부재로 인한 핑크노이즈는 쉽게 제거가 불가능하다.하지만. 이 De-noise의 노이즈 LEARN기능으로 노이즈를 분석한 후 노이즈를 획기적으로 제거할 수 있다.칭찬일색으로 보이지만 RX5는 유튜브 믹싱채널을 운영하는 Alan JS Han님도 추천을 하실 만큼 유명하다.(근데 Izotope는 품질은 정말 유명하나 CPU를 정말 힘들게 한다.)자세한 이야기는 각 사진 속에보다시피 크기가 생각보다 크고 3kg에 육박하는 mini-itx PC이다.. 공연장비가 베이스이기 때문에 랜케이블로 연결한다.프로툴 유저라면 한번쯤 겪어본 창프로툴 유저라면 한번쯤 겪어본 창보이스가 없는 부분을 선택해 기본으로 깔리는 노이즈를 분석한다.전 구간에 분석한 노이즈 커브를 적용한 모습.깔끔하게 정리되었다.(SSL프리에서 오는 하모닉스들도 제거)#마보 #콘텐츠 #프레임워크 #스택 #인사이트 #일지
조회수 1088

개발자의 경력관리란?

경력이 아닌 업력이 되는 단계에 이르러야 가능한 것 아닌가 합니다.대부분의 경력은 '어느 회사의 누구'라는 표현에서 만들어진 것이 아닙니다.진정한 경력의 결과는 '자신의 이름'이 곧 브랜드화 되는 것입니다.매우 당연하게,하루 이틀, 한 두해 한다고 해서 얻어지는 것이 아닙니다."10년 경력!"10년 이상 한 분야나 하나의 도메인, 하나의 테크, 하나의 경력, 하나의 경험을 꾸준하게 파고들었을 때에 얻어지고, 그러는 경험속에서 인사이트, 통찰력이 생기게 됩니다.물론. 그래서, 20대에도 명성을 얻을 수 있는 '경력관리'가 가능하다고 이야기합니다.(실제 얻은 사람을 많이 봤습니다. 그들은 10대에 시작했죠. )회사의 테두리 내에서 얻을 수 있는 '경력'은 '경험'일뿐입니다.자신의 이름을 중심으로 기술할 수 있을 때에 '경력'이라고 이야기할 수 있습니다.개발자라면...글을 써서도 얻을 수 있고,강연을 해서도 얻을 수 있고,GitHub에 오픈소스를 공개하면서도 얻을 수 있습니다.현재 30대와 그 이전의 개발자라면...10대와 20대도 똑같습니다.40대, 50대 이후를 준비하세요.반복적인 일, 똑같은 일, 회사의 프로세스의 하나인 일만 하는 '사람'이라면...그냥, 그 회사의 톱니바퀴가 되는 것입니다.대부분 '경력관리'가 잘 안됩니다.앞으로 50대 이후에도 '브랜드'를 얻을 사람이 되려면...자신의 '경력'관리를 잘 해야 얻을 수 있습니다.나중에 닭 튀기거나 치킨 배달할 것이 아니라면...관리를 잘해야 합니다.경력관리가 가능하려면 어떤 회사를 찾아야 할까요.다음을 기억하세요.1. 구루급 개발자가 있는 회사를 찾으세요.2. 자신이 주도적으로 무언가를 만들 수 있는 권한과 책임을 줄 수 있는 회사를 찾으세요.3. 커뮤니티나 외부 강연, 외부 오픈소스 개발 행사에 적극 참여할 수 있는 기회를 주는 회사를 찾으세요.4. 반복적인 업무와 정체된 마켓에서만 반복적으로 서비스를 하는 회사는 회피하세요.5. 우리 도메인은 원래 이래, 이 일은 원래 이래... 이런 식으로 이야기하는 '상급자'가 있는 회사를 피하세요.6. 쉽게 설명할 수 있도록 준비하고, 리뷰를 할 수 있는 기회와 시간이 주어지는 회사를 찾으세요.그리고, 마지막으로...비전은 누가 주거나 만들어 주지 않습니다.결국, 자기 자신이 찾아야 하는데...이것도, 주변에 이야기가 통하는 '구루급 개발자'가 있어야 그나마 방향성을 찾기 좋습니다.혼자 고민하거나,주변에 비슷한 사람들끼리 고민해봐야 답이 안 나옵니다.꼭, 기억하세요!'구루급 개발자'와 상의하세요.그분들은 실패와 성공, 포기와 단념, 선택과 집중에 대해서 알고 있답니다.퇴근시간이라면..구루급 개발자에게 치맥 한잔 하자고 하세요!
조회수 1181

스푼 라디오 오디오 랩 팀의 Jason을 만나보세요!

인상이 좋은 비결은.. 원래 이렇게 생겼어요 (찡긋)오디오 랩 팀의 막내, 알고 보니 세상 모든 매력을 덕지덕지 붙이고 다니는 Jason을 인터뷰해보았습니다.근데 대체 왜 이렇게 인상이 좋은 거예요? 출처: 알파카 월드 - 제이슨 닮은꼴"그냥 정말 원래 이렇게 생겼어요 하하. 웃는 상이예요. 사실 어릴 땐 눈이 좀 더 찢어지고(?) 올라가 있어서 좋은 인상이 아니었는데, 좋은 인상으로 변하더라고요..(나이 탓인가..) 웃는 게 습관이 되어버렸어요"인싸도 아싸도 아닌 '그럴싸'"인싸요? 아니에요 인싸. 그냥 저는 좀 알고 보면 반전도 많고 '모순덩어리' 일뿐이에요. 그래서 저를 표현하는 한 마디도 저는 '모순덩어리'라고 할래요. 예를 들면, 저는 해병대 출신인데 수영을 못하고요. 이성적인 것 같은데 또 되게 감성적이에요. 발라드를 되게 좋아하는데 제 노래방 18번은 '거꾸로 강을 거슬러 오르는 저 힘찬 연어들처럼'이에요. 사색하는 거 좋아하는데 또 가만히 있는 건 싫어요. 시간 아깝더라고요. (빵긋) 사내 제이슨 feat. 카이와 헤이든 듣고 싶은 당신의 스푼 라이프오디오 랩팀은 어떤 부서인가요?"오디오 랩팀은 스푼 라디오에서 오디오 방송 통신 기술을 연구하고 개발하는 부서입니다. 저희의 궁극적 목표는 세계 최고 오디오 기술 플랫폼이 되는 것이에요. 그리고 오디오 랩에서 제가 하고 있는 업무는 안드로이드 OS 클라이언트에 오디오 기술 개발하는 업무를 맡고 있어요. 오디오 랩팀에 막내이긴 한데.. 재간둥이 역할은 제가 맡고 있지 않아요 하하.. 저희 팀의 재간둥이 역할은 Ben님께서 하고 계십니다"스푼에 입사하기까지"제 입으로 말해도 되나요? 저는 수학을 좋아하진 않았는데, 잘했어요. 국어랑 사회 같은 문과계열 과목을 싫어했는데 이공계 쪽이 저와 적성에 맞더라고요. 수학 1등급 나왔는데 메가스터디 박 XX 선생님께 이 자리를 빌려 감사드립니다. 인강이 저를 만들어주셨어요.저의 원래 장래희망은 항공기 정비사였어요. 언제부터 비행기를 좋아했는지 모르겠지만 초등학교 때부터였던 것 같아요. 고3 때 진로를 정해야 하는데 항공정비과와 전자공학과와 고민을 했었어요. 그러다가 결국엔 전자 공학과 에 진학하게 되었고 자연스럽게 꿈 하고 멀어지게 되더라고요. 사실 항공 소프트웨어 쪽으로 일을 하게 될 줄 알았는데 다른 쪽으로 방향이 틀어지다 보니 어느덧 30대가 되어 있었어요. 사실 처음에 저는 스타트업에서 일하게 될 줄 몰랐어요. 이직을 준비하던 차에 제가 직접 스푼 라디오를 사용해보고, 기사도 읽게 되었고 Neil(대표)의 세바시 강연을 보고 이곳에서 일하고 싶다! 비전이 있다!라고 생각해서 오게 되었어요"내가 함께 일하고 싶은 사람서글서글한 사람을 좋아해요. 제가 그렇게 잘 못하는 편이라서요. 낯을 좀 많이 가리는데 저와는 다른 성향인 사람이라면 시너지 효과가 날 것 같아요파일럿 제이슨알고 싶은 Jason의 이야기해병대 출신부터 비행기 조종사까지"제가 안 그래 보이지만.. 사실 해병대 출신이에요. 해병대 왜 갔냐고 물어보신다면, 멋있어 보여서 가게 되었어요. 그게 전부예요. 복식 호흡하는 게 멋있어 보이더라고요. 원래 하고 싶은걸 다 하면서 살자라는 위주인지라, 꼭 무엇이든 하고 말거든요. 원래 꿈이 비행기 조종사였는데 꿈을 못 이루었으니 취미로도 해보자!라는 생각이 들어서 시작하게 되었어요. 한국에서도 할 수 있는데 제약이 너무 많아서 회사를 그만두고 미국에 갔어요. 여태 모아둔 돈 다 쓰고 왔어요. 4개월 정도 미국에서 하루 10시간씩 비행을 했었는데, 정말 행복했어요. 고등학교 때는 사실 실용음악도 준비했었어요. 아카펠라 중창단에 속해있었는데 2학년이 되고 이걸 진로로 결정하기엔 아니라고 판단이 들어서 그만두긴 했지만요. 그래서 대학교에 들어가고 밴드부에 들어가서 보컬을 맡았었어요. 저 점심시간에 혼자 코노가요. 같이 가기엔 부끄러워서.. 혼자 갑니다"유노윤호의 열정, 최강창민의 쿨함"제가 원래 자소서에 경청을 잘하는 사람이라고 적었는데 사실 가끔 듣는 것도 귀찮아요 하하.. 그리고 본인 이야기하는 것도 민폐라고 생각해서 잘하지 않는데 인터뷰하다 보니 엄청 많이 하게 되었네요. 근데 또 제가 남한테 지는 거 안 좋아해서 벤이랑 운동 누가 더 많이 하나 내기해서 요즘 매일 아침 출근 전에 수영 배우고 있고 화, 목은 영어학원을 다니면서 자기 계발을 하고 있어요. 목표가 없으면 안 되는 것 같아서 늘 목표를 일부러 세워요. 그래서 예전엔 사진도 배우러 다녔어요. 아 참! 수영을 배우다 보니 요즘 새로운 목표는 '라이프 가드'를 하고 싶어 졌어요. 이렇게 하고 싶은걸 하면서 열정적이게 살게 된 계기는 아마 아버지의 영향이 큰 것 같아요. 아버지가 매일 이렇게 말씀해주셨거든요"꿈을 꾸고 살아라, 돈은 따라온다! 반려견 '나무'의 아빠 Jason"저희 집 강아지 이름이 '나무'인데요. 식목일이 생일이라서 나무라고 지었어요. (나무 이야기할 때 눈빛이 초롱초롱해지면서 나무의 사진 보여주시던 제이슨) 나무는 귀엽고요. 비가 오나 눈이 오나 항상 저를 반겨줘요. 그래서 고마운 친구예요. 회사랑 집이 거리가 좀 멀어서 자취를 할까 생각했는데, 그러면 강아지가 혼자 집에 있어야 하니 안쓰러워서 하고 싶지 않았어요. 제가 없더라도 다른 가족들이 나무를 보살펴 줄 수 있어서 다행이라고 생각해요.팀원들이 Jason을 한마디로 표현한다면?Ian: JSON - "가볍고 빠르고 효과적이어서"*JSON [JavaScript Object Notation] :경량의 DATA교환 형식Ben: 알파카계의 알파치노 - "알파카처럼 온순한 외모의 소유자이지만 속엔 야망과 강한 카리스마를 가진 남자라서"
조회수 2712

Good Developer 2 | 커뮤니케이션 잘하는 개발자가 되는 방법

프로그래머와 개발자는 다르다.커뮤니케이션에 대한 이야기를 하기 전에 프로그래머와 개발자의 차이에 대해 명확히 하려 한다. 먼저 프로그래머는 컴퓨터를 이용해서 프로그램을 만들거나 수정하는 일을 하는 사람이다. 프리랜서로 일하면서 외주 프로젝트를 맡거나 학교 과제를 하면서 프로그래밍을 하는 사람들 모두 프로그래머라 할 수 있겠다.반면, 개발자는 회사나 조직에 소속이 돼서 다른 사람들과 함께 일하면서 개발을 사는 사람이다. 즉 어딘가에 소속이 돼서 규칙이나 규율 혹은 그 조직의 원칙을 가지고 일을 한다면 개발자로 볼 수 있는 것이다. 정리해 보자면 모든 개발자는 프로그래머지만 모든 프로그래머는 개발자는 아니다. 프로그래머와 개발자를 굳이 나누어서 말하는 이유는 개발자에게는 커뮤니케이션 능력이 절대적으로 필요하기 때문이다. 이와 관련해 아주 적절한 비유를 소개하려고 한다. 이 비유는 칼럼니스트 임백준 님의 '개발자의 생명은 커뮤니케이션 능력'에서 가져왔다.(이 글도 아주 좋으니 읽어보는 것을 추천)비유를 해보자면 이렇다. 프로그래머나 해커는 강호를 떠돌면서 혼자서 행동하는 무사라고 한다면 개발자는 군대에 소속되어 있는 정규군이다. 칼럼에서는 정확이 이렇게 표현한다.외톨이 무사에게 생명은 칼 솜씨고 정규군의 생명은 규칙과 규율이다.칼 솜씨는 코딩 실력이 되겠고, 규칙과 규율은 다른 사람과의 커뮤니케이션 능력이라 볼 수 있겠다. 이것이 개발자에게 있어 코딩 실력이 중요하지 않다는 것은 아니다. 코딩 실력은 기본이요. 커뮤니케이션 능력도 반드시 필수적이라는 뜻이다. 군대에 속해서 전투를 치르기 위해서는 기본적인 전투능력이 필요하다. 즉, 개발자는 자기가 맡은 프로그래밍 업무를 성공적으로 수행할 수 있는 능력을 가져야 하고 이것 은 기본이다!좋은 개발자가 되기 위한 첫 번째 방법, '소통'많은 시니어 개발자들이나 개발 관련된 직종에서 오래 근무한 사람들이 가장 많이 하는 말 중 하나가 바로 커뮤니케이션에 대한 이야기다.  개발자를 뽑을 때 중요한 것이 커뮤니케이션 능력이라고 한다. 커뮤니케이션이 원활하지 않아 개발 업무에 차질이 생기는 일이 다반사며 원활한 커뮤니케이션은 막혔던 문제를 훨씬 더 빠른 속도로 풀릴 수 있게끔 만든다.그럼 구체적으로 좋은 커뮤니케이션을 하기 위해 어떻게 해야 하는지 알아보자. 한 번쯤 들어봤을 이야기들이긴 하지만 구체적인 실행방안들을 추가해서 실제 기업이나 조직에서 바로 적용할 수 있도록 했다.건설적인 대화를 하라!너무나 당연한 말이지만, 이 말이 얼마나 업무 현장에서 지켜지고 있는지는 의문이다. 먼저 건설적인 대화의 방법들을 살펴보기 전에 어떤 대화들이 건설적인 대화가 아닌지를 살펴보자. 그리고 그것을 어떻게 건설적인 대화로 바꿀 것인지 말할 것이다.(1) 대화가 끝났어도 명확한 합의점이나 결과, action item, 해결책이 나오지 않았다.- > 이 문제는 두 가지 이유에서 비롯된다. 첫 번째는 대화의 목적(대화를 하는 이유)이나 목표(해결하고자 하는 것)가 불문명해서 대화가 어느 방향을 전개되야 하는지 갈피를 못 잡기 때문이다. 그리고 두 번째는 대화가 끝난 후 테스크로 전환하는 일을 하지 않은 것이다.==> 대화의 목적과 목표를 분명히 하라! 이야기를 시작할 때는 목적과 목표를 분명히 하라. '우리 지금 이 문제를 해결하기 위해 이야기하는 거죠?' '이 문제를 어떻게 처리할지에 대해 이야기해 봐요.' 일차원적일 수도 있겠지만 이렇게 직접적으로 이야기하는 것이 원활한 커뮤니케이션을 하는데 더 효과적이다. 목적과 목표를 정하지 않고 이야기를 하게 되면 이야기가 중간에 표류할 공산이 크다.==> 대화가 끝난 후에는 반드시 대화에서 얻어낸 결과물들을 테스크로 전환하고 각자에게 배분하라! 업무적 성격의 대화인 경우 문제 해결에 대한 이야기일 가능성이 크다. 이때 액션 아이템이나 합의점이 도출되지 않았다면 건설적인 대화가 이루어지지 않은 것이다. 업무 관련 일이 아닐 경우, 단순 아이디어 회의일 경우에는 대화하면서 나온 아이디어를 적고 문서화시켜야 한다. 그래야 나중에 '너 그때 이렇게 말했잖아!' 하면서 싸우는 일이 없다. 결론이나 결과가 없는 대화는 나중에 그 문제로 인해 다시 대화하게 될 가능성이 크다. 그리고 그것은 곧 리소스의 낭비다.(2) 논쟁을 하다 삼천포로 빠지고, 논쟁이 논쟁을 위한 논쟁으로 변질된다.-> 대화를 하다 보면 항상 좋게 좋게만 흘러가는 것이 아니다. 또 원활한 커뮤니케이션이 의견 충돌이 없는 소통을 의미하는 것도 아니다. 의견이 충돌하되 그것을 건설적이고 긍정적인 방향으로 풀어내는 것이 커뮤니케이션 능력이다. 이 케이스는 목적과 목표의 설정이 제대로 이루어지지 않아서이기도 하지만 대화를 하는데 있어서 서로가 명확히 해야 할 부분을 하지 않아서이기도 하다.==> 논쟁의 지점을 분명히 하라! 특히, 논쟁 지점이 여러 가지라면 뒤죽박죽 이 얘기 저 얘기 다 하면서 시간 소모를 할 공산이 크다. 건설적인 논쟁을 위해서는 우리가 어떤 포인트 때문에 논쟁을 하는지 서로 동의하는 부분은 무엇이고 동의하지 않는 부분은 무엇인지 명확히 해야 한다. ==> 용어를 분명히 하라! 서로 쓰는 용어의 의미가 달라서 논쟁이 되는 경우도 많다. 같은 문제를 바라봐도 다르게 말할 수 있고, 다른 문제를 이야기하는데 같은 용어를 통해 이야기할 수 있다. 원활한 커뮤니케이션의 기본은 용어 통일, 논의의 통일이다. 같은 수준에서 이야기할 때 비로소 원활한 소통을 할 수 있다.커뮤니케이션에 있어서 핵심은 '당신'이다.물론, 커뮤니케이션은 쌍방의 문제다. 내가 문제일수도 있고 상대방이 문제일 수도 있다. 하지만, 원활한 커뮤니케이션에 있어서 상대방을 바꾸는 것은 매우 어렵지만, 나를 바꾸는 것은 상대방을 바꾸는 것보다는 수월하다. 그리고 진정으로 커뮤니케이션을 잘하는 사람은 커뮤니케이션을 못하는 사람과도 '잘' 하는 사람이다. 커뮤니케이션을 잘하는 개발자로 인정받고 싶다면 그 누구와도 잘 할 준비가 되어 있어야 한다.그럼 어떻게 바뀌어야 커뮤니케이션을 잘 할 수 있게 되는지 세 가지 조건을 통해서 알아보자.(1) 자신과 상대방의 커뮤니케이션 스타일을 파악한다.서로 누구의 잘못이라기보다는 방식의 차이 때문에 싸우는 경우가 다반사다. 말투, 어투, 말하는 방식, 시기 등 자신의 스타일을 모르고 상대방의 스타일을 이해하지 못할 때 커뮤니케이션은 막혀버린다. 가장 좋은 것은 글로 적어보는 것이다. 나는 이렇고 상대방은 이렇다. 직접적으로 적어본다면 보다 커뮤니케이션 스타일을 이해하기 쉬워진다. 그리고 커뮤니케이션 스타일을 이해하는 것만으로도 커뮤니케이션을 할 때 많은 도움이 된다.(2) 상대방이 당신에게 망설임 없이 커뮤니케이션할 수 있게 하라!어떤 사람과는 커뮤니케이션 시작 자체를 하기가 어려운 사람들이 있다. 바쁘거나 시작하면 논의가 이루어지지 않거나 많은 조건들이 있을 것이다. 특히, 이 부분에 대해서는 스스로를 돌아보기가 매우 힘들다. 이때는 딱 두 가지의 것을 확인하면 된다.첫 번째로는 주변에 커뮤니케이션하기 망설여지는 상대를 찾아보라. 그리고 그 사람과는 왜 커뮤니케이션이 망설여지는지 생각해 보고 나를 돌아보면 된다. 타산지석(他山之石)이라 했던가. 혹시 내가 커뮤니케이션이 망설여지는 사람이 아닌지 다른 사람을 통해 되돌아보자.두 번째로는 다른 사람에게 솔직하게 물어보는 것이다. 이 방법이 사실 제일 중요하다. 내가 커뮤니케이션에 있어서 부족한 점은 없는지 상대방에게 물어보는 것이 가장 효과적인 방법이다. 물론, 솔직한 말을 듣는 것이 처음에는 두렵고 상처가 될 수도 있다. 하지만, 이것은 당신을 가장 성장시켜줄 대화 중 하나다. 동료만큼 당신과 커뮤니케이션을 많이 하는 사람도 없을 테니 바로 옆자리의 동료에게 자신의 커뮤니케이션에 있어서 부족한 점을 솔직히 말해달라고 부탁하라!(3) 동료와 친밀한 관계를 형성하고 공감하는 것은 중요하다.여기 회사 동료와 친할수록 일의 효율이 올라간다는 연구결과가 있다. 커뮤니케이션의 기본은 열린 마음이다. 그리고 마음은 상대방에게 호의가 있을 때 더 쉽게 열린다. 좋은 커뮤니케이션을 위해서라면 사전에 좋은 관계를 형성하는 것도 중요하다. 좋은 관계와 좋은 커뮤니케이션은 서로 밀접한 상관관계가 있다.대화가 커뮤니케이션의 전부가 아니다.대화만으로 모든 커뮤니케이션을 할 수는 없다. 효율적이지도 않고 물리적으로 불가능한 상황이 있을 수도 있다. 원활한 커뮤니케이션을 위해서라면 적절한 도구의 사용이 필요하다. 즉, 협업 툴을 효과적으로 사용하여 자신이 하고 있는 일들을 상대방에게 알려주고 상대방의 업무를 파악하려고 노력하라!도구의 사용은 커뮤니케이션에 사용하는 비용을 엄청나게 절감해 준다. 자신이 커뮤니케이션에 자신이 없고 언변이 부족하다 생각한다면 도구를 잘 쓰는 방식으로 커뮤니케이션 능력을 향상시킬 수 있다. 지금까지 위에서 언급한 것들은 쉽게 바뀔 수 있는 것들이 아니다. 왜냐하면 지금까지 몸에 체화된 자신만의 대화 방식을 바꾸는 것이기 때문이다. 하지만 커뮤니케이션 도구의 사용은 프로그램이다. 프로그램은 사용법을 배우면 된다.예를 들어, ASANA라는 협업 툴로 자신과 동료의 업무를 리스트화하고 체크할 수 있다. 또는, 구글 캘린더에 자신의 스케줄을 올려서 일정을 공유할 수 있다. 협업 툴을 이용하면 일의 진행사항들을 쉽게 공유하고 상대방의 일정을 파악할 수 있다. 그리고 이런 정보의 공유는 원활한 커뮤니케이션의 기본이다. 이런 도구들을 통해 커뮤니케이션이 부족한 사람들도 충분히 좋은 '커뮤니케이터'가 될 수 있다.커뮤니케이션도 실력이다.다시 처음으로 돌아가 커뮤니케이션의 필요성에 대해 다시 강조하려고 한다. 어떤 사람은 개발자의 핵심은 개발 능력이고 커뮤니케이션은 잘하면 좋은 것이라 생각한다. 위에서도 언급했지만, 개발자는 떠돌이 무사나 용병이 아니다. 조직에 소속되어 있는 개발자라면 소통하고 커뮤니케이션을 하는 능력이 핵심이다.그래서 개발자가 되려는 사람들에 항상 하는 말 중 하나가 다른 사람과 함께한 협업 프로젝트를 해보라는 것이다. 함께 프로젝트를 하는 경험은 프로그래밍 능력을 향상시킬 뿐만 아니라 어떻게 함께 개발하는지에 대해 많은 고민을 할 수 있게 해준다. 단순히 프로그래머가 되려면 코딩 실력에만 집중하라! 그러나, 다른 사람들과 함께 개발을 하는 개발자를 지향한다면 반드시 커뮤니케이션 역량도 향상시켜라!Good Developer 두 번째는 커뮤니케이션에 대해서 다루었다. 다음 Good Developer 는 나쁜 개발자에 대해서 알아볼 것이다.
조회수 1136

안드로이드 개발자의 고민 Fragment (2)

이전 글 보기: 안드로이드 개발자의 고민: Fragment이번 글에서는 Fragment stack 관리와 Fragment 데이터 Lifecycle 관리 이슈를 줄일 수 있는 해결 방법을 찾아보겠습니다. 이전 글에서는  Fragment를 하나의 View로 관리하는 오픈소스를 검토했었습니다.하지만 검토하는 중에 기존 오픈 소스의 변경과 버전업 관리 이슈의 문제를 그냥 넘어갈 수는 없었습니다. 상용 소스에 바로 적용하기에는 리스크가 크다고 판단해 좀 더 신뢰할 수 있는 방법을 선택하기로 했는데요.요즘은 작년 6월에 Google IO 에 발표한 AndroidX의 내용을 다시 검토하고 있습니다. Deeplink를 통한 목적 화면과 Fragment 스택 관리가 중요한데, 이 기능을 도와주는 것이 AndroidX Navigation이기 때문입니다. 화면 전환을 UI 기반으로 사용하여 화면 관리를 용이하게 만들었습니다. 물론 코드 기반에 익숙한 저는 적용하는데 시간이 걸렸죠.기존의 Fragment 관리는 FragmentManager를 통하여 개발자가 직접 코드 상에서 관리했습니다. 하지만 Navigation의 경우에는 아래와 같이 직관적으로 설정할 수 있습니다.firstFragment -> secondFragment -> thirdFragment 로 화면 간의 흐름을 설정합니다. 하나의 Navigation 파일은 하나 이상의 Activity 에서 사용할 수 있습니다.이 방식은 오히려 현재 사용하는 브랜디 소스와 비슷합니다. 하나의 Activity에 ActivityFragment를 만들어서 1:1 매핑으로 화면을 Fragment를 관리하는 방식과 유사합니다. Navigation 의 세부내용은 Google Developers에서 확인할 수 있습니다.Deeplink 를 통한 Fragment Stack 관리도 간단합니다.Notification 또는 Serice 등에서 PendingIntent를 사용하여 테스트할 수 있습니다. Navigation Fragment stack 순서대로 화면을 쌓은 다음 최종 destination Fragment 로 도착합니다. 이와 같은 방법으로 Push를 통한 화면 관리를 쉽게 할 수 있습니다. 이 내용은 여기에서 자세히 확인할 수 있습니다.신속한 마무리기존 Android 에서 화면 관리가 불편했다면 Navigation으로 직관적이고 쉽게 화면을 관리할 수 있을 겁니다. 브랜디는 아직 적용할 준비 중이지만, 꼭 kotlin과 Navigation을 적용해보려 합니다. 그럼 다시 개발의 숲으로 들어가보겠습니다.글고재성 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만
조회수 1253

새로운 슬로건도, 어반베이스답게

기업의 슬로건은 기업의 이미지를 좌우할만큼 중요하다고 할 수 있습니다.나이키의 'Just Do It' 이나 아디다스의 'Impossible Is Nothing'과 같이 대중의 머릿속에 이미지 그 자체로 각인될 수 있기 때문이죠. 어반베이스가 3D 공간데이터 플랫폼으로서 전 세계의 모든 실내공간정보를 자유롭게 활용할 수 있는 코어 기술과 서비스를 런칭하게 되면서 미래를 향한 메시지를 내포할 수 있는 새로운 슬로건을 만들게 되었습니다. 어반베이스는 과연 어떤 방법으로 새로운 슬로건을 만들었을까요?슬로건도 '어반베이스'답게 만들다어반베이스는 IT 기술 기반의 스타트업인만큼 직원 중 절반 이상이 개발자입니다.그렇다보니, 출퇴근기록 계산기부터 점심알람봇(bot)까지 일상에서 조금이라도 불편한 점이 있다면 개발자분들이 출동하여 프로그램을 만들어 주시곤 합니다.  이러한 문화를 가지고 있는 어반베이스는 슬로건 만드는 방법 또한 '어반베이스'답게 만들어 냅니다. 슬로건에 대한 다양한 아이디어를 얻기 위해 어떤 방법이 좋을지 고민하다가, 진우님(진우님=대표님=건축가 출신 프로그래머)께서 룰렛 하나를 만들었습니다. 같이 살펴볼까요?만들어 공유해 주신 링크를 타고 들어가면 이렇게 깔끔한 룰렛하나가 나오는데요참여방법은 간단합니다.1. 랜덤버튼을 2회 누르면 문장이 완성됩니다. 마음에 드는 문장이 나타나면 아래의 세이브 버튼을 누릅니다. 그 리고 그 문장은 저장되어 하단의 그래프로 반영이 됩니다. 'RANDOM'버튼을 한 번 눌러보았더니 클릭 두번에 슬로건 하나가 탄생합니다.'We Generate Urban'조금 더 나은 슬로건을 위해 RETRY 해 봅니다.이번엔'We Reform The Next World' 가 탄생했습니다.2. 그래도 마음에 드는 문장이 안나오면 보라색 '후리스타일' 버튼을 누르셔서 직접 입력해주시면 우측 리스트에 반영됩니다. (무기명입니다)'후리스타일' 버튼을 누르고 입력한 문장들입니다.이렇듯, 룰렛을 사용해 간단하고 간편하게 많은 문장들을 만들어냈습니다. 몇몇 단어를 가지고 고민하는 것보다, 룰렛을 최대한 많이 돌려서 저장하는 방법을 선택했습니다. '이런식으로도 슬로건을 만들 수 있다니' 재미 반 진지 반으로 어반피플들이 모두 참여하여 슬로건 짓기에 동참했습니다.그러하여 나온 최종 두 가지 안 입니다. We Invent the Next WorldWe Reinvent the World우리는 이 최종 두 가지 안을 가지고 다시 투표를 하였습니다. (다수결의 원칙) 그 결과, 아주 근소한 차이로 우리의 슬로건 탄생!어반베이스의 새로운 슬로건'We Invent The Next World'4차 산업혁명의 시대, 국내 뿐 아니라 전 세계적으로 공간데이터의 높은 활용 가능성에 주목하고 있습니다.3D 공간데이터 플랫폼 어반베이스는 앞으로 “We Invent The Next World” 라는 모토 아래, 보다 앞선 새로운 삶의 모습을 제시하고자 합니다. 2D 도면 이미지를 단 몇 초만에 3차원 공간으로 자동 변환해주는 기술부터가상의 인테리어를 돕는 3D HomeDesign, 3D데이터를 증강현실로 경험할 수 있는 AR Viewer, 머신러닝과 인공지능을 이용한 공간 기반 추천 서비스까지. 전 세계의 모든 실내공간정보를 하나의 플랫폼 안에서 자유롭게 활용할 수 있는 코어 기술 및 서비스를 선보이고자 하오니 많은 기대 부탁드립니다.*2019.01 어반베이스 개발자 사이트 런칭 예정 *2019.02 AR SCALE 런칭 예정출처: https://blog.naver.com/urbanbaseinc 
조회수 1437

8퍼센트 CTO 1년 차 회고

2015년 11월 4일에 8퍼센트에 입사했으니 이제 1년이 되었다. CTO라는 직함을 달고 보낸 지난 1년을 뒤돌아 본다.1년전 첫번째 스프린트나는 무엇을 원했던가?회고를 할 때는 목표를 기준으로 지금을 살펴봐야 한다. 일 년 전에 썼던 8퍼센트에 입사하기까지 라는 글을 다시 꺼내어 보니 당시의 나는 이런 것들을 원했다. 성공하는 회사에 다닌다.개발 조직을 책임 지고 꿈꿔왔던 이상을 실험한다.회사 경영을 경험한다.사회에 도움이 되는 일을 한다.1) 성공하는 회사에 다닌다. 입사 전이라 "성공하는 회사에 다닌다”라고 적었지만 입사를 한 이상 “회사를 성공시킨다”라는 목표로 바꿔서 생각해도 좋겠다.2015년 10월 말을 기준으로 78.4억의 누적 대출액이 현재 기준으로 480억 가량 되니 지난 1년 동안 약 400억의 돈을 투자자로부터 대출자에게로 연결했다. 나는 이 돈의 크기가 정확히 8퍼센트라는 회사의 사회적인 영향력 그리고 고객들이 회사에 갖는 신뢰의 크기라고 생각한다. 또한 회사의 성공의 척도이다.그럼 이 400억이 성공을 이야기할 때 충분한가에 답을 해야 할터인데, 아직은 많이 부족하다. 하지만 어디인지 모르는 성공이라는 것에 다가갈 확률이 일 년 전에 비해 높아졌느냐라고 묻는다면 "그렇다"라고 자신 있게 말하겠다. 그리고 나 또한 그 확률을 높이는 것에 공헌하고 있다.입사할 당시에 대표님이 내세웠던 조건 중 하나가 올해 말 기준으로 500억이었는데, 그 기준은 넘기게 되었으니 80점을 주자.2) 개발 조직을 책임 지고 꿈꿔왔던 이상을 실험한다.입사 전에는 개발 조직만 맡을 것이라고 생각했으나, 현재는 더 넓은 프로덕트를 만드는 조직을 책임지고 있다. 1년 전에 꿈꿨던 이상이라는 것은 멋지게 일하는 조직이다. 입사 초기에는 이를 위해 꽤나 많은 노력을 했다. 회사 자체가 백지상태이기도 했고 의욕도 충만했다. 하지만 시간이 지나면서 나도 모르게 안주하게 되고 더 잘하기 위한 노력에 게을러졌다. 반성하자. 그래도 일 년 동안 데모를 한 번도 빠지지 않고 34차례 진행했다. (종종 프로젝트 진척이 잘 되지 않으면 데모에서 도망가고 싶다) 그리고 주기가 끝날 때마다 프로세스 개선을 위한 회고 회의를 해왔다. 비록 그 과정에 보완할 점은 많으나 포기하지 않고 프로세스를 일 년 동안 유지한 것에 점수를 주고 싶다. 이상에는 아직 멀었으나 이 조직이 내가 많은 것들을 실험할 수 있고, 그런 설득만 할 수 있다면 그 실험에 기꺼이 동참해 줄 수 있는 조직이라는 것을 깨달았다. 80점으로 시작해서 50점까지 내려갔다가 최근에 10점 정도를 얻었다. 60점을 준다.3) 회사 경영을 경험한다. 초기에 대표님의 신뢰를 얻는데 까지 시간이 꽤 걸렸다. 지금 생각해보면 서로 간의 신뢰를 쌓는데 시간이 걸리는 것은 자연스러운 것인데, 초기에는 의욕이 앞섰다. 왜 내게 더 많은 것을 맡기지 않는지가 불만스러웠다. 대표님이 내리는 결정의 많은 부분에 의심이 들었으며 딴지를 걸었다. 하지만 지금은 대표님의 선택과 결정이 대부분 이해되고 신뢰가 간다. 그리고 대표님이 내게 많은 것을 위임하고 믿어주는 것을 느낀다. 합이 맞아간다.생각보다 회사는 시장의 시간에 쫓겨  부족한 정보를 가지고 결정을 내려야만 했다. 회사의 결정이 모든 것을 좌우한다고 생각했었지만 이제는 결정에 따른 실행이 더 중요하다는 것을 알게 되었다. 4) 사회에 도움이 되는 일을 한다. 사회에 도움이 되는 일을 하는 것은 이 회사에 입사했을 때 결정이 되었다. 회사의 성장이 사회에 미치는 긍정적인 영향과 비례한다는 생각에는 변함이 없다. 이 회사의 존재가 이미 사회에 많은 영향을 미쳤다. 그리고 대부분은 긍정적인 영향이라고 생각한다. 90점을 주겠다.일하는 것의 변화 1) 일하는 양의 변화초기 반년은 후회가 없을 정도로 최선을 다해서 살았다. (내가 인생에서 이런 말을 할 수 있는 시기가 몇 번 없다.) 내 역량의 100%를 다하며 살았다. 그 6개월을 지난 이후에는 살짝 기어를 낮췄다. 좋게 말하면 마라톤을 위한 모드로 바꿨다고도 할 수 있고 어쩌면 6개월의 달리기로 조금 지쳤는지도 모르겠다. 2) 시간 분배의 변화처음 입사했을 때에는 시간의 50%를 개발에 사용했지만 지금은 10% 밖에 사용하지 못하고 나머지 40% 를 프로젝트 관리에 사용하고 있다. 30% 정도를 팀에 쓰고 있는데 처음에는 팀의 구조를 갖추는 데 사용했다면 지금은 팀을 운영하는 데 사용한다. 대체로 자리에 앉아 있는 시간이 많이 줄었고 내외부 사람들과 커뮤니케이션하는 시간이 늘어났다. (슬랙 통계를 보니 내가 압도적인 수다쟁이더라)나는 무엇을 배웠을까? 1) B2C 사업에서의 배움 기존에 일했던 회사는 B2B 회사였다. 손에 꼽을 수 있는 고객을 만족시키면 되었고 상대적으로 그들이 원하는 것은 명확했다. 혹은 커뮤니케이션을 통해 요구사항을 명확하게 만들 수 있었다. 상대적으로 긴 호흡으로 일을 했고, 성능이 중요했다.B2C 서비스는 달랐다. 고객은 어떤 면에서는 전혀 이성적이지 않았다. 놀라운 일이었다. 하지만 대부분 우리의 서비스는 냉정하게 평가되었다. 고객의 반응은 즉각적이지만 그 반응을 옳게 해석해서 제품에 반영하는 것은 어렵구나라는 것을 느꼈다. 지금 이 순간 고객을 최대로 만족시키는 선택이 회사에 있어 항상 옳은 선택은 아니라는 것도 알았다. 내가 개발하고 있는 서비스를 사용하는 많은 사람들이 있다는 것 그리고 사회에 직접적인 영향을 미친다는 것이 제품 개발을 지속할 수 있는 큰 동기가 된다는 것을 느꼈다.2) 프로덕트 책임자로서의 배움제품을 책임지고 있는 사람으로 B2C 서비스에 필요한 많은 역량이 부족하다는 것을 알게 되었다. 그리고 나의 부족한 역량이 완성도가 떨어지는 서비스에 많은 영향을 주고 있다는 것 또한 알게 되었다. 기획자와 일하는 경험, 디자이너와 일하는 경험 모두 처음이었다. 이를 통해 같은 회사에서 하나의 제품을 만들지만 그것을 바라보는 다양한 시각이 존재한다는 것을 알게 되었다.지난 회사의 CTO를 보며 제품의 문제를 어떻게 이렇게 잘 찾아낼까 생각했었는데 나 또한 그렇게 되더라. 통찰력이 아니라 관심을 얼마나 가지는가, 얼마나 책임감을 가지고 제품을 바라보는가에 대한 차이라는 것을 알게 되었다. 많은 기술적, 비즈니스에 기반한 결정을 했고, 그 결정의 결과를 지켜보고 있다. 그것에서 배웠다.3) 프로젝트 관리자로서의 배움 프로덕트팀이 일하는 방식으로 스크럼을 도입했다. 스크럼을 할 때 ScrumBut(우리는 스크럼을 해요. 하지만 이것저것은 하지 않아요.)을 유의하라는 말을 하는데 스크럼에서 요구하는 것들 중에서 하지 못한 것들이 꽤 있다. 예를 들면 업무의 양을 측정해서 번다운 차트를 제대로 그려가며 팀의 속도를 측정하거나,  업무를 항상 우선순위 기반으로 하는 것 등이다. 처음에는 시도했었으나 몇 번의 스프린트 후에는 적당히 스크럼을 적용하고 말았다. 프로젝트를 잘 관리하기 위해서는 많은 노력이 필요하다는 것을 알면서도 필요한 만큼의 노력을 기울이지 않은 것을 반성한다. 코딩을 포함한 회사에 많은 재미있을 것들에 우선순위를 두고 재미없음을 이유로 중요한 프로젝트의 관리를 뒤로 미루었다.4) 도구의 도입에서의 배움여러 가지 도구들을 도입했다. 모든 커뮤니케이션을 슬랙을 통하도록 여러 가지를 도입했다. 아마 우리 회사만큼 슬랙을 열심히 그리고 잘 쓰는 회사가 흔치 않을 것이라 생각한다.  컨플루언스를 도입해서 문서를 쓰는 문화를 만들어 갔다. 여전히 내가 제일 많은 문서를 쓰고, 대부분 내가 위키 가드닝(문서의 내용과 구조를 재조직하는 일)을 하고 있지만 사람들이 위키를 통해서 커뮤니케이션하는 것을 자연스럽게 생각하는 것을 보면 뿌듯하다. 트렐로도 도입해서 사용하고 있다. 최근까지는 엉성하게 쓰고 있었는 데 사용 가이드라인을 잡아서 한번 공유했으니, 앞으로 팀에 녹아들 것으로 기대한다.이렇게 도구를 도입하는 과정에서 변화를 이끌어 내는 방법을 연습했다. 사람들은 스스로 필요성을 느껴야 변화를 받아들인다. 탑다운식의 강압적인 도입은 결국 실패한다. 구성원들이 도구가 업무에 도움이 되는구나 라는 것을 느낄 때까지 선구자가 많은 노력을 기울여야 한다는 것을 알게 되었다. 사람들은 자신들이 필요한 정보를 컨플루언스에서 찾을 수 있을 때 자신도 정보를 컨플루언스에 남기기 시작했다. 자신들의 요청이 트렐로를 통해서 잘 처리된다는 것을 느꼈을 때 새로운 업무를 트렐로를 통해 전달해 주었다. 5) 개발에서의 배움초반에는 영역을 가리지 않고 개발을 했었다. 인프라 쪽도 정리하고 대출 프로세스도 개발하고 다른 금융업체와 연동도 하고 그리고 개발 환경도 갖추었다. 하지만 1년이 지난 지금 이미 내가 작성했던 코드는 절반 이상 다른 분들의 더 나은 코드로 대체되었다.타 금융권과 연계해서 개발을 하면서 이쪽 동네가 얼마나 기술 변화에 뒤쳐져 있는지를 알게 되었다. 취미로만 해봤던 웹 개발을 제품 레벨로 처음 해봤다. 프런트앤드 개발의 중요성과 어려움을 알게 되었다.개발팀의 효율을 올릴 수 있는 테스팅, 코드 리뷰, CI의 사용 등을 실제로 적용해 볼 수 있었다.마지막으로 회사에 좋은 분들을 모셔오면서 내가 얼마나 부족한 개발자인지를 알게 되었다.6) 금융업에서의 배움회사의 절반인 프로덕트를 만드는 사람들은 대부분 스타트업 출신이고, 나머지 절반은 금융권 출신으로 구성되어 있다. 금알못(금융을 알지 못하는 바보)으로 출발한 내가 이제 그들의 대화에 낄 수 있는 정도는 되었다. 하지만 여전히 하루가 멀다 하고 새로운 용어와 개념을 만나고, 대화가 끝나면 용어를 검색해보기 일쑤다.금융 동네는 어떤 경우에는 모든 것에 이유가 있어 딱딱 맞아떨어지는 것처럼 보이다가도 어떤 경우에는 도대체 이해가 안 되는 경우를 만나기도 한다. 여하튼 지난 일 년 동안 새로운 분야에서 일하면서 모르던 것(정확히는 모르는지도 몰랐던 것)들을  알아가는 즐거움을 느꼈다. 다음 회사를 가게 된다면 금융이 아닌 또 다른 분야에서 일하는 게 좋겠다는 생각이 들었다. 7) 채용에서의 배움입사했을 때 개발자 2명, 기획자 1명, 디자이너 1명이던 팀은 이제 개발자 9명에 기획자 2명, 디자이너 1명인 12명 팀이 되었다. 이 중 개발자 6명과 기획자 1명을 직접 채용했다. 이 과정에서 스타트업 채용의 어려움을 알게 되었고 조그만 노하우를 얻게 되었다. 그리고 채용에 따르는 책임이라는 것도 알게 되었다.채용 글을 쓰고 페이스북에 광고를 하고 구인 사이트에 올려보고 했지만 결국 대부분의 채용이 소개로 이루어졌다. 좋은 사람은 쉽게 다른 회사에 지원하지 않는다. 채용한 사람의 30배가 넘는 이력서를 받았고 5배가 넘는 면접을 보았다. 하지만 결국 소개를 받아 채용하는 것이 거의 유일한 방법인 것 같다. 회사에 대해 꾸준히 글을 써오고 있는데 이것이 채용에 많은 도움이 되었다.프로덕트팀 구성원은 내가 직접 채용을 결정하다 보니 이효진 대표에 의해서 내 인생이 바뀐 것처럼, 내가 채용한 사람들의 인생을 바꿨다. 그들이 자신들의 능력을 발휘해서 8퍼센트에 공헌할 수 있도록 하고 회사를 성공시켜서 그들의 노력에 답해 줄 수 있어야 한다는 생각을 한다. 8) 관리자로서의 배움 지난 회사에서 5명의 팀 리더를 할 때에는 내가 개발자인가 관리자인가라고 물으면 답하기가 쉽지 않았다. 하지만 지금 내게 묻는다면 나는 관리자라고 답하겠다. 나는 내 노력 50%를 들여서 전 구성원의 효율을 10% 더 올릴 수 있는 사람이 되어야 한다. 좋은 관리자였냐라고 하면 그렇지는 못했던 것 같다. 특히 구성원들에게 제때 필요한 피드백을 하지 못한 것은 아쉽다. 쓴소리를 해야 하는 위치에 있음에도 좋은 사람으로 남고 싶어서 적절한 때 적절한 피드백을 하지 못했다. 특히 같은 팀에 있는 디자이너와 기획자에게는 미안한 마음이다. 그들의 결과물에 대한 피드백도 쉽지 않았고, 커리어에 대해 해줄 수 있는 조언도 없었다. 그저 그들이 맡고 있는 좋은 프로덕트를 통해 성장해 나가길 바랄 뿐이다. 회사에서 1년 동안 "함께"라는 것을 기업 문화에 심기 위해 노력했다. 내가 시도했던 것들 중에 어떤 것들은 문화가 되어 정착이 되었고, 어떤 것들이 도태되어 사라졌다. 그 기준은 재미였다. 사람들에게 재미를 줄 수 있었던 슬랙의 #study 채널을 통해서 함께 공부하기, 브런치 매거진을 통해 함께 글쓰기, 2주에 한 번씩 오는 특별한 점심, 함께 하는 워크샵은 문화로 살아남았고 나머지는 사라졌다.  잃은 것은 무엇인가?1) 개발자로서의 경쟁력 개발자로서 경쟁력이 떨어지고 있다. 일반적으로 개발자가 망하는 과정을 다음과 같이 이야기한다.개발을 열심히 잘 하고 있음나이가 들면서 회사에서 관리자를 하라고 함관리자를 했더니 개발할 시간이 없어서 개발 실력이 떨어짐그 회사를 나오고 났더니 찾아 주는 곳이 없음치킨집내가 이런 과정으로 가고 있는 것은 아닐까? 에 대한 불안감이 있다. 전 회사에서는 새롭게 쏟아지는 기술들을 따라가며 공부를 해왔는데, 이제는 그런 공부 대신 당장 회사에 필요한 공부를 하게 된다. 이렇게 기술적인 경쟁력을 잃어 가게 되면 앞으로 먹고사는데 문제는 없을까?라는 생각도 들고, 당장 CTO라는 자리에서 옳은 결정들을 할 수 있을까 하는 생각 또한 든다.  2) 나와 가족체중을 얻었다. 운동할 시간이 없었기보다는 운동할 마음의 여유가 없었다. (둘 다 핑계이기는 매한가지다.) 체중이 늘어나다 보니 나 자신에 대한 자신감이 좀 떨어졌다. 가족들과는 입사 전에 비해 많은 시간을 보내지 못한다. 시간을 함께 보낼 때에도 핸드폰으로 슬랙을 확인하기 일쑤였다. 그리고 육체적/정신적으로 지친 상태라 100% 마음껏 놀아주지 못했다. 총평8퍼센트에 입사하기 전 일 년보다 훨씬 더 치열하게 살았다는 것만으로도 만족할 수 있는 1년이다. 내가 원하던 자리에서 원하던 경험을 할 수 있는 기회를 갖게 된 것만으로도 8퍼센트와 이효진 대표에게 감사한다. 자신 있게 추진하던 일 중 용두사미가 되어 버린 것들은 아쉽다. 하지만 용기 있게 많은 것들을 시도한 것은 잘했다. 내가 잘하는 것과 못하는 것이 여실히 드러난 1년이었다.   다음 1년은 무엇을 목표로 해야 할까?1) 회사를 성공시키자회사의 성장과 성공에 기대고 있는 것들이 너무나 많다. 지난 1년이 잽으로 탐색으로 해보는 1라운드였다면, 앞으로의 1년은 제대로 주먹을 뻗어보고 맞아보는 2라운드가 될 것으로 기대한다.  2) 그릇의 크기를 늘이자내 그릇의 크기에 따라 좋은 프로덕트, 구성원들의 성장, 채용이 좌우된다는 것을 알게 되었다. 그리고 입사 전보다 내가 갖춰야 할 역량들이 훨씬 명확해졌다. 꾸준히 갈고닦자.3) 더 멋지게 일하는 팀을 만들자 점점 손발이 맞아 간다. 더 많은 기회를 제공하고, 더 많은 것을 위임하자. 그리고 피드백을 잘하자. 이를 위해 끊임없이 실험하자.4) 손은 항상 더럽게지난 회사 CTO 님의 가장 큰 장점이 항상 손을 더럽게 유지하는 것이었다. 다시 말해 작더라도 일부 모듈을 직접 개발하고 다른 사람들의 코드들을 충분히 이해하셨다. 나 또한 다른 많은 일들이 있더라도 하루에 한 줄의 코딩은 할 수 있도록 하고, 다른 사람의 코드를 리뷰하는 데에도 시간을 쏟아야 하겠다.다시 맞이하는 1년회고를 통해 순식간에 지나간 지난 1년이 가볍지 않았다는 것을 알게 되었다. 다행이다. 이 글을 작성하면서 1년 전에 쓴  8퍼센트 입사 날을 읽어 보았다. 그날만큼은 아니지만 가슴이 두근거린다. 여전히 8퍼센트는 내게 모험이고 도전이다. 이제 새로운 마음으로 1년 1일 째를 맞이해야겠다. 지금 기분이라면 1년 뒤 더 멋진 회고글을 쓸 수 있을 것 같다.30번째쯤 스프린트의 데일리 미팅저와 함께 하고 싶은 개발자 분은 지원해 주세요! 기다리고 있습니다.#8퍼센트 #에잇퍼센트 #CTO #기업문화 #조직문화 #팀문화 #후기 #돌아보기 #개발자

기업문화 엿볼 때, 더팀스

로그인

/