일본경제신문 자체개발 전환사례 소개

 오늘날 모든 기업활동과 사회활동에서 IT는 이미 핵심 영역으로 자리를 잡은지 오래이다. 특히 2010년대에 들어서며 등장한 스마트폰은 IT를 생활과 완전히 한 묶음으로 만들어 버렸다. 그 결과, 과거의 IT가 기업활동이나 공공서비스의 핵심영역을 보조해주는 역할에 불과했다면, 오늘날에는 비즈니스 핵심영역과 결합되거나 아예 핵심영역 그 자체가 되어버린 경우도 쉽게 찾아볼 수 있다.

 특히 TV와 라디오, 신문, 잡지, 출판과 같은 미디어 영역은 스마트폰이나 타블렛과 같은 인터넷과 결합된 스마트 기기가 빠르게 생활속에 자리잡아감에 따라 플랫폼 자체를 변화 시켜야만 하는 선택의 기로에 놓여있다.

 이러한 가운데 주목받고 있는 흐름이 바로 인하우스 개발(=자체개발)로의 회귀이다.
 초창기 기업들의 IT시스템은 자체개발로 시작한 곳이 많았으나 점차 전문 IT서비스 기업들이 등장함에 따라 비 IT기업들은 비용과 전문성, 지속성의 문제로 시스템 개발을 외주에 의존하여 개발하는것이 서서히 일반화 되었다. 하지만 최근들어서 속도와 품질, 그리고 비용이라는 측면에서 IT부서의 규모를 확대하고 개발자를 사원으로 채용하려 하는 움직임이 표면화 되기 시작한 것이다.

 이번 포스팅에서는 일본의 대표적인 경제전문 미디어인 일본경제신문사(이하 닛케이)의 디지털 편성국에서 근무하는 스즈키 요스케씨가 2015년 8월 15일 BPStudy에서 발표한  인하우스 개발 전환 사례를 통해 자체개발로의 전환에 필요한 요소들과 주의해야 할 위험 요소들에 대해 살펴보고자 한다. 포스팅의 내용은 Speaker Deck에 올라온 슬라이드에 기반하고 있으며, 한국내 개발자들이 이해하기 쉽도록 약간의 해설을 가미하였다.

 본격적으로 이야기에 들어가기 앞서 번역을 허락해 주신 닛케이의 스즈키 요스케씨께 감사의 말씀을 전한다.

닛케이전자판의 자체개발화에의 도전

원문: 日経電子版　開発内製化の取り組み

• 자기소개

• 스즈키 요스케(鈴木陽介)
• 일본경제신문사 디지털편성국 소속
• 2001년 입사
• NIKKEINET의 컨텐츠 운영, 산업부기자, 인터넷판 컬럼의 편집자등을 거쳐 2009년경 부터 디지털판 기획/개발 담당
• Python을 중심으로, JavaScript(Coffee), Go등을 일과 개인적인 용도로 사용하고 있습니다. Pebble로도 즐기고 있습니다.

• 앱 자체개발에 대한 이야기를 공개했었습니다.

• 닛케이디지털판 자체개발 비화 by Natsuki Akama
• 특히 신문 업계의 반향이 엄청났습니다

• 일본경제신문(닛케이)에 대해서

• 1876년 설립, 2016년으로 140주년을 맞이하는 미디어 전문회사
• 1000명 이상의 기자와 편집자가 근무
• (역자주) 특히 인터넷과 IT에 관련한 신문,잡지,서적등의 출판을 활발히 펼치는 미디어로서 일본내에서 독보적인 위치에 있음.

• 닛케이디지털판에 대해서

• 40만명이 넘는 유료회원
• 유료 뉴스서비스로서 세계4위
• 아이폰과 안드로이드에 대응하는 모바일 서비스를 강화
• 서비스계의 개발부문은 약 40명 정도가 근무

• 닛케이의 시스템개발 역사

• 1972년 세계최초의 신문제작 시스템을 개발
• 1984년 데이터베이스 서비스 '닛케이텔레콘' 개시
• 1996년 인터넷 서비스인 NIKKEINET개시
• 2010년 닛케이전자판 창간

• NIKKEINET시절에는 내부개발이 주로 이뤄졌었습니다

• 영문기자출신이신분이 비주얼 베이직으로 만든 CMS가 애용되고 있었습니다
• Perl로 억세스로그의 집계,분석 툴을 개발
• CloudFusion으로 서비스용 서버어플리케이션 제작
• PHP와 비슷한 녀석입니다
• 의외로 성능이 좋았습니다
• 결국 사람에 의존한 개발 체제였기 때문에 점차 외주개발로 바뀌어가게 됩니다
• (역자주) 사내의 개발에 열정을 지닌 사람들이 시작한 프로젝트였으나 퇴사나 근무처 이동등에 의해 지속성을 지니기 힘든 구조였을듯 합니다.

• 닛케이전자판의 개발(창간무렵까지)

• 초거대SI업체가 대거 참여하여 개발
• 성능(레스폰스)는 좋았음
• 변경 비용이 증대
• 테스트는 기본적으로 수동, 테스트 비용의 증가로 예산이 오버되어 계획이 실현 되지 않았던 경우도 있었음

• 내부개발화로의 흐름

• 2010년 당시
• 자그마한 변경에도 꾀나 번거롭고 시간과 돈이 들어가는 구조

버튼 하나 추가에 2주의 기간과 수십만엔의 비용이 발생하는 비효율적인 구조 

• 기획을 올려도 아주 작은부분만이 실제 구현되었음 
• 이대로 괜찮은건가? 라고 초보처럼 생각했다
  (이러저러한 이유가 있었으나 당시엔 알지 못했음)

• 거의 맘대로 두사람으로 개발을 시작해 보았다

• 처음에는 PHP+Ruby+MySQL로 사내 서버를 만들었다
• 2010년 여름경
• 성능은 그저그랬음
• PC판의 일부 페이지ㅡ를 구현함
• 1개월 반정도 소요
• UI는 바꿔 보았다
• 결국 이 버전은 창고행으로...

• 스마트폰 브라우저 버전(베타)의 개발

• 창고에 넣어 두었던 버전은 존재의미가 그다지 없었다
• 2011년 당시, 스마트폰 브라우저 버전이 없었던 관계로 그것을 만들어 보기로 함
• Google App Engin(이하GAE)을 사용해서 인프라를 포함해 단 두명이 만들었음
• HTML5의 기능을 풍성하게 집어넣은 엣지있는 서비스가 만들어졌다

• 자체개발한 서비스가 정식으로 서비스됨

• 2012년에 윈도우8용 앱을 자체 개발
• 2013년에 인프라, 프론트엔드 모두 새로만든 모바일 브라우저 버전을 공개
• 프론트엔드의 자바스크립트는 당시 신입사원이 자체 개발했다
• 지금은 다른 신입사원이 개발중
• 도급형이 아닌, 외부 개발자가 사내에 상주하며 개발하는 스타일도 늘었다
• 아직 주류는 아니지만 자체 개발에 대한 분위기가 슬슬 나오기 시작함

• 좀 더 모던한 개발이 하고싶다!

• 자체 개발을 좀 더 발전시켜보고 싶었음
• 2013년 12월경 한 스터디 모임에서 naoya씨(역자주:일본의 유명 개발자로 AB테스트 플랫폼인 Kaizen platform의 개발자로 유명)에게 기술고문을 부탁했더니 OK해 주셨습니다!
• 이걸로 삐까뻔쩍모던한 개발이 바로 시작될줄 알았으나...

• 하지만, 기술이 문제가 아니었다!

• 우선 개발팀의 체제를 변경
• 눈이 튀어나올것 같은 엑셀 어사인표에 직면
• 여러 업무에 대한 겸임을 가능한 해소함
• 자체 개발의 범위를 좁힘
• 우선은 프론트엔드를 중심으로
• 개선팀을 만들어 적극적으로 활동
• 정보를 공유함
• 회의 아젠다를 시간을 들여 작성함
• 회의 참석 인원은 최소한으로
• 맴버들의 자기 주장이 부족함
• 등등, 나오야씨에게는 기본적인것에서 많이 꾸중을 듣기도 했습니다만
• 내부의 인원만으로는 타성에 젖기 쉬웠으므로 감사한 마음으로 받아들였습니다

• 개선팀의 운영에 도전한 결과

• 정보공유
• 엔지니어 채용
• GitHub&Pull Request도입
• 프로퍼티 자동화
• 자동 테스트
• 내부적으로는 문제에 대처해 나가면서, 매번 테마를 정해 naoya씨와 토론을 진행해 나갔습니다

• 커뮤니케이션 툴의 도입

• 슬랙
• 사내외 맴버를 포함해 270명이 넘는 인원이 사용
• Qiita:Team(역자주: 일본에서 인기있는 개발자대상 정보공유 플랫폼인 Qiita의 기업용 버전. Markdown을 지원하며 코드를 손쉽게 글 안에 포함시킬 수 있는것이 특징임. 아틀라시안의 컨풀루언스와 마찬가지로 KM플랫폼으로 주로 사용되고 있음)
• 사내외의 100명이 넘는 인원이 참가
• 회의에서 'Qiita에 적혀져 있습까?'라고 말해지는 경우가 늘어났다
• 1000개가 넘는 게시물이 등록!
• 처음에는 좀체로 사용해 주시지 않았습니다만 끈질기게 침투시켰습니다

• 합숙 워크샵을 개시

• 3~4개월에 한번씩 합숙워크샵을 개최
• 로드맵등을 공유

몰입적 사고를 위한 진지한 워크샾을 통해 성공에 대한 이미지를 공유

• GitHub

• 자체개발을 진행하고 있는 팀과 프론트엔드 주변 팀의 도입은 거의 완료
• 모바일앱, 인프라의 Ansible Playbook, Django의 API개발은 Pull Request로 개발
• 디자이너도 Pull Request를 이용하고 있음

• CI와 테스트자동화

• GitHub에 대한 push를CircleCI와 연동
• 모바일 앱의 유닛&e2e테스트 실시
• 인프라의serverspec실행

• 채용 블랜딩

• 스터디 모임에서 발표한다
• 지금 이 자료
• iOS 자체 개발담
• 스터디 모임의 회장 포스트를 이용
• Gocon(Go언어 개발자 컨퍼런스)
• Rebuild Meetup
• Ansible Meetup
• 해커톤
• Cookpad와 공동으로 개최

• 돌이켜 보니 중요했던 부분들

• 비전을 내걸고 그곳을 향해 팀을 개혁한다
• 특히 오래된 조직은 움직임이 느리고 방해가 끼어들기 쉬움
• 하지만 모두들 효율이 나쁜것을 하고싶다고 생각하지는 않음
• 열의를 가지고 이상을 향해 노력한다
• 생각하는 방식은 모두 다를 수 밖에 없다. 반복해서 정보를 발신한다
• Qiita등을 이용해 이러저러한 내용을 적으면, 제대로 읽고 건설적으로 코맨트를 해 주는 사람도 많았음
• 모던 기술의 도입도 중요하지만, 그것을 모두를 위해 실시하는것이 중요함 

• 일단 시작해 본다!

• 생각만 하고 있으면 앞으로 나갈 수 없다
• 타사의 사례같은것을 모아도 그것만으로는 진행 할 수 없다
• 어떻게 하면 가능한가? 가아니라 일단 시작 해 보자
• 우선은 손을 움직여서 실적을 만들어 내는것도 중요
• 무언가 만들어 자체개발이 가능한것을 증명했다
• 두사람만 있어도 의외로 가능하다
• 코드는 엉망이어도 우선 가능하다는것을 보여준다
• 사내 체제가 자체개발이 가능하게 되면 그때부터 코드리뷰를 도입한다
• 오히려 세세한걸 모르는 덕에 가능한것도 있다

• 왜 자체개발을 하려는지 제대로 설명한다

• 목적과 수단은 거꾸로되기 쉽다
• PDCA사이클을 고속으로 반복할 수 있는것이 자체개발의 강점임!
• 외주작업으로는 이것이 가장 어려움
• 사양검토->견적->발주작업등등
• 엔드유저의 의견이 다이렉트로 오는 프론트엔드를 우선적으로 자체개발 대상으로
• 사내에 노하우가 쌓인다
• 비용이 줄어든다
• 쓸데없는 회의가 줄어듦
• 낮시간에는 회의만 줄창 하다 저녁이 되어서야 작업하는 상황이 사라짐

• 맨토를 부른다

• 노하우가 없는 상태에서 자력으로 모든것을 개발하는것은 무리임
• 하지만, 통채로 외주를 해 버리면 사원에게는 노하우가 쌓이지 않음
• naoya씨의 '외부인의 의견을 듣는다'에서
• 외부인의 시각을 통해 무의식적으로 해 왔던 것들에 대해 수정/개선하는것이 가능해짐
• UI나기술에 대해서도
• 앱의 UI에 대해서는 fladdict씨
• 파이선의 개발에 대해서는 hirokiky씨
• 그외, 과거에 몇번인가 멘토를 불렀었음

• 어쨋거나 진흙탕은 피할 수 없다!

• 프론트엔드부터 한다
• 특히 모바일쪽
• 새로운것 부터 한다
• 새로운API군
• 뜯어 고치는 것 부터 한다
• 인프라의 AWS 이행시에 Ansible을 도입
• 운용을 강화
• 내부개발화에는 역시 우수한 엔지니어가 필요함
• 엔지니어 대상의 브랜드이미지를 개선한다
• 상층부와 이미지를 공유

• 닛케이전자판((닛케이본사)는 엔지니어 채용중!

• 편안한 마음으로 사내 견학도 OK!
• dg_lab@nex.nikkei.co.jp 으로 연락 주세요.
• 학생분들은 hack.nikkei.com으로 인턴 응모도 가능합니다.

• 닛케이전자판팀의 좋은점은?