2010 NHN DeView에 다녀왔습니다. TH's inked Berry

  데뷰에 다녀와서 후기를 빨리 쓰고 싶었는데 나만의 블로그를 개설해서 쓴다는 것이 시간이 많이 지체되었네요. 덕분에 9월 8일날 발생한 이벤트를 13일날 적습니다. 기억력이 굉장히 나쁜 편인데 추억을 더듬어 가며 글을 적는 것이므로 세그 폴트 에러가 날지도 모르니 조심하세요. 여러분은 별나라 DeView를 보고 계실지도 모르니까요. 잡소리가 길었나요?



불안한 스타트

  NHN에서 DeView라는 이벤트를 준비했다길래 기쁜마음에 사전예약을 등록했습니다. 네이버가 공짜로 세미나를 해준다는데 개발자라면 만사 던져놓고 달려가야죠. 대구에 사는 저는서울 차편을 고민하고 있던 차에 NHN이 버스를 보내준다고 합니다. 와우! 그런데 9월 6일 밤 10시가 되도록 이 차를 어디서 어떻게 누가 탄다는 통보 메일이 없습니다. 낙동강 오리알 미운오리새끼... 23시가 되니까 메일이 날아오기 시작합니다. 뒤늦은 소식이 이메일 문자 합쳐 쓸데 없이 10통 정도는 온 것 같습니다만 그것은 사전예약 한 우수한 인재들이 빠짐없이 오기를 바라는 마음에 보낸 것이라 생각합니다. 다만 조금 더 빨리 연락을 주었으면 어떨까 싶네요. 꽤나 걱정했습니다.



희망찬 출발

  아침 7시에 동대구 고속터미널 정문에 모이라고 NHN으로부터 통보를 받았습니다. 약속시간에 대한 편의를 봐줄 수 없으니 알아서 오라는 문구도 포함되 있었죠. 새벽 5시에 일어나 부랴 부랴 출발해 도착했더니 아직 차가 안왔더군요. 기사 분과 통화해 우리가 미아가 된 것이 아니란 것을 알았습니다. 덕분에 우리는 최초로 탑승했네요. 참고로 동대구 고속버스 터미널에는 정문이라는 개념이 없습니다. 장소 통보에 약간 문제가 있었습니다.


NHN에서 대절해준 버스차량. 이곳은 동대구 고속터미널 정문??

충격과 공포

  꽤 이른시간에 일어났기에 차 안에서는 거의 대부분의 시간을 숙면과 함께 했습니다. 도착 예정시간이 넘어 데뷰 시작시간이 다되어가는데 서울바닥은 차가 어찌나 막히는지 거의 가질 못하더군요. 행사가 시작되기 약 10분 전쯔음에나 겨우 행사장에 도착할 수 있었습니다. 강단 앞에 들어서니 사람이 바글바글한게 뭔가 불안감이 엄습해오기 시작합니다. 아니나 다를까!! 1200명 한정 기념품 및 식권이 모두 바닥나고 말았군요. 기념품에 포함된 이름표에 무엇을 쓸지  여자친구와 함께 고민했던 저는 바보가 된 듯 하였습니다.




  우리는 모든 것을 포기하고 맛집을 찾아봐야겟군 궁리를 하고 있을 무렵이었습니다. 주위에서는 식권내놓아라!는 항의가 나오기 시작하더군요. 항의의 내용을 한 마디로 요약하면 이렇습니다. 대체 사전예약이 다 무슨 소용이냐? 밥을 달라! 저는 그분들이 순간 서울에 식사하러 오신 분들 처럼 보였습니다. 이 분들의 강력한 항의가 먹힌 것인지 관계자 협의 후 통보해주겠다며 일단 트랙안으로 들어가라고 안내를 받았습니다.


도착하고 났을 때는 행사 시작 직전!! 이미 대부분의 사람들은 트랙안에서 자리를 잡고 있었습니다.




  트랙안으로 들어온 우리는 새로운 충격에 빠졌습니다. 사람이 너무너무 많았습니다. 의자? 그게 뭔가요. 통로면 통로, 길이면 길 모두 사람이 아주 꽉꽉차 발디딜 틈이 없었습니다. NHN의 인기가 발바닥 통증으로 느껴지기 시작하더군요. 우리의 자리는 맨 뒤에 설치된 스피커보다도 더 멀리 동 떨어져 위치했기 때문에 뭐라고 말을 하는지 제대로 알아듣기도 벅찰 지경이었습니다. 화면에 ㄱㄹㅈㅁㄴ라는 글을 띄우고 개발자는 얼룩말 티셔츠를 입는다는 이야기를 하며 착석하신 분들과 웃고 떠들때 우리는 진흙탕을 벗어나기 위한 혈투를 펼치고 있었습니다.


하해(河海)를 이룬 트랙 안. 김평철 CTO의 인사말





KEYNOTE. 어떻게 하면 건강한 소프트웨어를 만드나? Staged Build, 반복점진개발 방법 적용사례


김정민 이사의 키노트(반복, 점진적 개발 방법론 적용사례). 실제로는 굉장히 먼 거리입니다.


  제대로 말이 들리기 시작한 것은 키노트 시간부터 였습니다. 발바닥 통증과 싸우는 무리의 맨 앞으로 올 수 있었기 때문이죠. 그렇다고 무턱대고 뒷사람의 시야를 가리는 파렴치한 행위는 하지 않았습니다. 다리 통증에 항복한 이들이 나가며 빈자리를 만들어 주었는데 그때마다 조금씩 전진했을 뿐입니다. 아무튼 키노트부터는 조금씩 흥미로운 이야기를 하기 시작합니다. NHN 개발자들이 어떠한 소프트웨어를 지향하고, 개발 일정을 맞추기 위해 어떠한 노력을 하고 있으며 iterative-incremental development를 어떻게 적용하고 있는지와 같은 software engineer로서 관심깊은 내용들이 줄줄이 나왔거든요. 오늘은 정말 개발자를 위한 세미나구나를 확실히 느낄 수 있었습니다.

  키노트시간에는 기존의 NHN의 개발 모형을 폭포수로 잡고, 방법론 속에 개발의 일정을 늦추는 요인들을 꼬집어 이부분을 개선해나가는 자신들의 모습을 이야기합니다.


개발완성을 지연시키는 요인들. 위에 숫자 29는 앞으로 29페이지 남았다는 이야기입니다. 페이지가 끝나면 밥먹으러 가야죠.



  NHN이 폭포수 모형을 개발 프로세스로 적용했었다구요? 저는 도저히 믿을 수가 없군요! 네이버라면 최첨단 프로토점진반복릴리즈오토메틱 메서드를 이용하지 않나요? 라고 이야기 하고 싶습니다. 아찌됫건기존의 방식을 워터풀에 포커스를 맞추고 그에 대한 문제점을 짚어 나가는데 핵심을 콕콕 찝어나가는 점과 매끄러운 진행이 아주 인상적이었습니다.


건강한 소프트웨어는 건강한 소스코드에 기인한다.




  소프트웨어의 생산성을 저하시키는 원인들 중 낮은 품질 코드에 대한 이야기가 나왔습니다. 이에대한 해법으로 Quality Practice를 이야기했죠. QP에는 6가지 지표가 있습니다. 제가 아래 슬라이드 설명보다 더 쉽게 이야기 해드리죠. ①코딩 표준 정해 준수하고, ②코드에 대한 이해를 돕고, ③충분한  테스트를 할 것이며, ④그에 따른 테스트 도구도 사용하고, ⑤코드의 복잡도를 낮추고, ⑥중복 코드를 제거 하라는 이야기입니다.


한 마디로 요약합니다. 코딩 표준, 코드에 대한 충분한 이해돕기, 코드에 대한 테스트, 테스트 도구 활용, 복잡도 저하, 중복 제거.



  김정민 이사는 학교에서는 이러한 것을 가르치지 않는다. 그렇기 때문에 잘 듣고 우리의 책을 사라 ('NHN은 이렇게 한다! 소프트웨어 품질관리')  는 말을 우스갯소리로 이야기 했습니다만. 우리 학교에서는 코드 스타일 즉 네이밍과 아키텍쳐-①, 중복 제거-⑥, 복잡도 하락-④과 같은 연습을 상당히 많이 하는 편입니다. 주말에 한명 한명 학교에서 소스코드 발표수업-② 을 하면서 교수님께 평생 먹을 욕을 다 듣거든요. 토요일 오전 10시에 시작해서 일요일 오전 7시까지 논 스톱으로 달리던 기억이 납니다. 물론 경험치는 잘 오르는 편입니다. 


  이러한 네이밍이나 엉터리 구조가 사실상 성능에 문제가 되는 것은 아닙니다. 그러나 큰 프로젝트, 유지보수에서 치명적인 문제가 발생하게 되죠.  블록 중첩의 지옥에 빠져 보셨나요? 개발자의 혀를 뽑아버리고 싶습니다. 무슨 의민지 알 수 없는 변수의 늪에 빠져보셨나요? 빠져나올 구멍이 안보입니다. 이러한 소스 코드는 상호작용을 막고 개발 특히나 유지보수를 지연시킵니다. 그렇기 때문에 모 교수님은 이렇게 이야기 하시죠. 소스코드는 수필과 같다. 위에서 아래로 죽 읽어 내려감으로서 이해가 되는 readability가 높은 코드가 되어야만 한다.

이 후에도 단계적 빌드, 반복점진 개발 이야기가 나옵니다만 아직 5교시까지 가려면 갈길이 머니 이쯤에서 키노트는 마무리지어야 겠네요. 대략 뒷 부분 내용을 짧게, 쉽게 요약하자면 NHN에서는 빌드의 범위가 local부터 global, 나아가 실 서버에 적용시키기 까지 여러단계에 거쳐 나뉘어져 있는데 이렇게 나누어 놓으면 앞 단계의 빌드일수록 빠르고 자주 빌드를 할 수 있으니 버그를 빨리 많이 잡을 수 있다는 이런 이야기입니다. 작은 범위상에서 문제부터 해결해나간다고 볼 수 도 있구요. 조엘 스폴스키 아저씨의 '일일 빌드는 하고계신가요? '(또 세그폴트가 일어나는 군요) 와 일맥상통한 이야기 입니다. Enterprise Architecture, Architecher Engineering에서도 자주나오는 그런 이야기와 비슷하죠. 한마디로 적은 비용으로 극대효과를 보기 위해 문제의 해결을 최대한 쉬운 앞 단계로 모두모두 당겨라는 이야기입니다. 그리고 반복점진 개발을 위해 적당한 feature 크기가 중요하다 뭐 그런 내용들입니다. 이상 KEYNOTE 끝.





Overflow! 점심시간

  키노트 시간이 채 끝나기도 전에 스믈스믈 빠져나가던 사람들이 눈에 많이 띄였습니다. 보나 마나 먼저 밥 먹으러 가는 무리들이겠지요. 사실 정말 인산인해였기 때문에 그렇게 먼저 나가서 빨리 먹는 것이 트랙에 일찍 리턴해 좋은 자리를 선점하기 좋은, 뛰어난 판단입니다. 저도 그러고 싶었구요. 하지만 우리는 식권 협의 통보를 기다려야만 했기에 그럴 수가 없었습니다. 지방사람들은 정말 서러워서... 눈물 콧물 찔끔 나려고 했지요. 키노트가 끝나고 나니 다행히 식권을 나눠준다고 해서 또 줄서서 기다리고... 지연에 지연을 거쳐 정해진 식당으로 이동하니 이미 줄은 50미터가넘어버렸습니다. 전 이곳에서 50미터를 30분정도면 주파했다죠


여러분은 이 사진을 보면 무슨 말이 떠오르시나요? 저는요? 음.. 빙산의 일각 이라는 말 아세요?


이것이 바로 간이 식권! 이건 갤S라 화질이 좀 구려요.


사람이 많으니 식당안도 전쟁터에... 찜닭덮밥을 먹는데 닭이 살아 움직일거 같습니다. 맨날 50여명의 점심 손님을 맞이하던 주방 아줌마분들도 200여명이 줄서서 기다리는  일일 맛집 체험은 거의 처음이실테니까요..

그렇게 식사를 마치고 우리는 다시 진흙탕으로 돌아갔습니다.




Session 1. 네이버는 이렇게 테스트 한다 -웹서비스 UI 테스트 자동화(블로그 서비스 사례)



  A 트랙에 도착했습니다. 여전히 상황은 기립청취입니다. 한 번 앉으면 다른 트랙으로 이동은 꿈도 꾸지 말아야겠더군요. A트랙의 지박령이 될 각오로 조금씩 앞으로 나아가기 시작했습니다.
  첫번째시간은 저의 색안경 탓에 기대와 달리 실망이 컸습니다. 버그는 예상치 못하는 곳에서 튀어 나오는 것 아닌가요? 아무튼 네이버는 자동화 스크립트를 통해 거의 90%의 버그를 잡는 다고 합니다. 퍼센테이지는 훌륭해요. 하지만 이번 시간은 제 관심너머로 떠나버려 반환되어버렸습니다.




Session 2. 꾸준히 자라나는 소프트웨어 만들기 - 테스트 자동화, 리팩토링


가운데 아래 모자가 바로 접니다. 앞 쪽 라인에 주저앉은 사람들이 보이시나요? 저희는 맨 앞 땅바닥 얼리어답터였답니다. 여러분의 소중한 초상권은 보호되었습니다.


  두번째 시간은 굉장히 재미있었습니다. 다만 사진을 남기지 못한게 조금 아쉽습니다. 자리를 조금씩 앞으로 가다가 큰 맘먹고 아무도 앉지 않는 자리들의 맨 앞으로 가서 땅에 털썩 주저 앉았습니다. 저희가 거의 맨 처음이었지요. 이내 주위에 한 둘 모이시더니 아예 관계자분이 앞에 앉으라고 마이크로 이야기 해주시네요. 저는 이곳에 터를 잡고 하루를 보내야 겠다고 각오했습니다. 비록 엉덩이는 조금 아프지만 다리는 이미 한계였고 이 자리는 아이맥스로 볼 수 있어서 더욱 좋습니다. 약간은 홈리스 체험이었던거 같기도 하군요.

  소프트웨어 개발에 사용되는 대부분의 용어는 건축에 사용되는 용어를 그대로 따왔습니다. Architect, Architecture, Design, Build.. 실용주의 프로그래머의 저자 앤드류 헌트와 데이비드 토마스는 소프트웨어를 건축물이 아닌 정원에 비유했다고 합니다. 이 발표시간에 나온 이야기는 아니지만 이해를 위해 덧붙이자면 실용주의 프로그래머 책에는다음과 같은 이야기가 나옵니다. 한 신사가 아름다운 잔디밭을 가꾸고 있는 정원사에게 도대체, 어떻게, 이렇게, 훌륭한 정원을 가꿀 수 있는지 물었습니다. 그러자 정원사는 말했죠.  그것은 아주 쉽다. 매일 아침 이슬을 털어주고 조금씩 손봐주면 된다. 그렇게 500년만 지나면 너의 정원도 훌륭해질 것이다.

  이 이야기는 소프트웨어를 건축물이 아닌 정원에 비유함으로서 죽은 소프트웨어의 자라나는 생명력을 나타내면서 잘 가꾸고 손질하였을 때 비로서 훌륭한 프로그램이 될 수 있음을 시사합니다. 마찬가지로 박종민 팀장은 소프트웨어를 정원에 빗대며 잘 가꾸어 주어야 한다는 것을 이야기 하셨습니다.


건물보다는 정원에 어울린다는 소프트웨어. 하지만 아직은... Design Pattern이라느니... 패턴의 아버지 크리스토퍼 알렉산더라느니...



  여기서부터는 정말 재미있는 이야기가 나옵니다. 기대하세요. 두근두근. 용기 만빵의 NHN 개발자 이야기 랍니다.

  그럼 시작합니다.


  옛날 옛날에 에니악으로 따뜻히 겨울을 보내던 날에 한 신입사원이 회사에 들어왔습니다. 그의 임무는 회사의 핵심 서비스인 배포코드의 유지보수 담당이었더랬죠. 그 회사는 상당히 큰 회사라서 1일 방문자는 7백만이구요. 1일 페이지뷰는 9천만이나 되었답니다.




넘치는 에너지로 소스로 돌입한 신입사원! 그런데 유지보수를 하려고 코드를 들여다 보니 뭔가 심상치 않은 오라가 뿜어져 나왔어요. 쉽게 말해 구멍이 슝슝난 양말같았죠. 구멍이라도 없으면 냄새를 조금이라도 막아줬을려나요?




이 코드는요 정말 불가사의 했어요. 블록의 Depth는 너무 깊어서 한 페이지에도 잘 안들어오구요. 논리곱의 합과 합의 곱을 뒤섞어 놓은 듯한 조건문, 중이적 중삼적 의미를 내포한 변수들이 두터운 보호막 처럼 자리잡고 있었던 것이죠. 하지만 불타는 의지의 신입사원은 일단 무라도 썰 기세였답니다.


이것도 생각보다 노가다네요. 새벽에 무슨 짓이람..




불타는 의지의 신입사원은 열심히 수정하고 저장해버렸데요.




그 결과요? 기대하시라 짜자잔




아아 어쩌죠? 상사가 분노의 폭풍을 일으킬지 몰라 일단은 맛이 간 프로그램을 돌아가게 수정해야 겠네요.


조금 더 손을 봅시다. 뚝딱뚝다닥



결국 신입사원은 20분간이나 전체 웹서버를 다운시키는 공로를 세웠답니다. 상사에게는 죽도록 혼났겠네요. 오늘의 교훈은? 냄새나는 코드를 만나면 뒤도 돌아보지 말고 도망쳐라입니다. 짝짝짝


신입사원 이야기 끝-




  재미있으셨나요? 전 너무너무 재미있는데 말이죠. 실제로 제가 저 상황이었다면 데드락에 빠졌을지도 모릅니다. 이럴수가!! 내가 네이버를 망가트렸어!!... 식스나인 안녕~


  리팩토링이란 외부의 동작을 바꾸지 않고 내부의 구조를 개선하는 것이라고 머틴 파울러가 말했습니다. 뭐 내부구조의 개선이라는 것에 의미가 퍼포먼스의 향상도 살짝 가미된 거 같지만 그보다도 스파게티 소스를 먹기 좋게 수정하라는 점이 메인디쉬라고 생각됩니다. 박종민 팀장은 시간관계상 이러한 아름다운 코드를 짜려면 요렇게 요리해야 됩니다하고 깊이 이야기 해주진 않았지만 if문을 분리하고 중첩된 조건을 보기좋게 하고 의미가 있는 변수 및 함수명을 부여해야한다고 말했습니다. 


  이후의 이야기는 테스트 자동화인데요. 저는 이쪽으로는 무지한지라... 대략 요지는 기능이 추가됨에 따라 테스트해야할 사항이 배수로 증가하기 때메 충분히 테스트가 안되니 이를 자동화함으로서 극복해야 된다는 것입니다. 그리고 코딩중에 버그를 잡아야 비용도 적게 들고 쉽게 찾을 수 있다 뭐 그런 이야기입니다. 그 뒤로도 이야기가 있습니다. 키 노트와 동일한 내용이네요. QP가 곧 리팩토링의 밑거름이 된다는 이야기와 거기에 따른 사용되는 도구들을 소개해줍니다. 퀴즈도 나왔었는데 상품이 키노트때 소개되었던 책이었습니다. 그래도 갖고 싶었는데... 너무 소극적이었나봐요. 

  리팩토링이 많은 비용이 든다고 생각하지만 이미 검증된 코드를 다시 재구성하는 것일 뿐이므로, 전체 개발시간에 비해 큰 비용을 들이지 않고 유지보수성을 대폭 향상시킬 수 있는 훌륭한 전략이라고 생각합니다. 불도저 처럼 항상 새로 만들기만 해서는 언제 500년짜리 왕국을 지어보겠어요?


리팩토링도 할 말이 많은 분야이지만 갈길이 머니 이것으로 정리하겠습니다. 사실은 이미 반환된 메모리라서... 복구가 안되는군요.



Session 3. 개발자가 좋아하는 기획서 만들기

어느 덧 세번째 시간으로 들어왔습니다. 저는 꽤 기대하고 있었습니다. 이를테면 '이렇게 써야 상위 개발자가 좋아할만한 Documentation이다! 하위 개발자는 알아서 기어라' 는 내용인 줄 알았거든요. 그래서 대체 디자인 스튜디오라는 HTML 위지윅 툴과 비슷한 것을 왜 이 시간에 소개하는 건가 하고 의문을 품고 있었습니다. 아무래도 저는 너무 편협한 시각을 가졌었나봅니다. 이야기를 듣는 중 이상하다 싶어 눈 씻고 다시 보니 개발자가 좋아하는 '기획서' 만들기네요. 제목을 잘못 이해하고 있었습니다.  이번 시간의 이야기를 한마디로 요약하자면 기획팀에서 개발팀에 문서를 넘겨줄 때는 제발 이따위로 만들어 보내지말라는 소리입니다. 너희 인간들이 하는 자연어는 모호해 빠졌고 도통 무슨소린지 하나도 모르겠으니 우리 간결하고 명확한 프로그래밍 언어로 대화하자 라고 하면 더 와닿으시나요?


이기현 생산도구개발팀장. 시연과 함께 데모의 법칙을 보여주셨습니다.





제 예상을 빗나간 내용이라 그런걸까요? 첫번째 시간과 비슷한 기운이 제 몸을 감싸더군요. 이번 시간은 순수하게 개발자의 입장에서 기획서를 받아보는 시각으로 마련되었습니다. 개발자를 괴롭히는 것 중 하나인 기획부와의 커뮤니케이션 부분을 해결해보자는 것이엇죠.


그렇지 않아도 인터럽트 거는 things들이 넘쳐나는데, 통보마저 모호해서야 개발 해먹겠습니까?


기능은 빼고 있는데로 표현하자. 뭐지요? 프로토타입이네요!




아아아아.. 저는 모호한 부분을 바로 잡아내고 의도를 끌어내는 것은 개발자의 중요한 역할이라고 생각했습니다. 하지만 모든 것을 개발자가 떠안을 수는 없죠. 기획자에게도 조금 넘겨보는 게 어떨까요? 너는 더이상 쓸 데 없는 소리 말고 이 툴 대로만 만들어서 우리에게 이야기 해줘!


디자인 스튜디오란 HTML 기반의 기획서를 작성할 때 사용할 수 있는 강력한 프로토 타이퍼 입니다.



시연 동영상까지 준비했으면 좋았겠지만 그 부분은 알아서 찾아보시길 바랍니다. 제가 지금 13일과 14일에 걸쳐 이틀 간 글을 쓰고 있는데 13일날 동영상이 올라왔네요. 하지만 저는 기억에 의존하여 글을 마무리 하겠습니다. 언능 마무리 하고 일 좀 해야죠.

이 툴은 시각 적인 요소 뿐만 아니라 엘리먼트의  가시성과 같은 기능도 프로토타이핑 할 수 있습니다. 자주 사용되는 템플릿도 제공하네요. 거의 클라이언트에서 동작하는 부분을 깔끔하게 구현할 수 있는 듯 합니다. 다만 프로토 타이핑에 중점을 두었기에 실제 코드로 사용하기엔 무리가 있으며 이를 보고 다시 코드를 재 생성해야 한다고 합니다. 계속 데모를 보니 생각 이상으로 굉장히 많은 부분을 명세할 수 있군요. 구현할 메커니즘 모든 부분을 기획서에 작성하는 느낌입니다. 어디까지나 클라이언트 단에 한해서요. 만약 프로토 타입이 완벽에 가깝게 구현되면 그걸 무어라고 부르는지 아세요? 제품입니다. 저는 이 툴이 사용할 수 있는, 웹 표준에 근접한 코드를 생산해내지 못한다면 기획자가 힘들게 명세해놓은 수 많은 노력이 또다른 노력으로 전환된다는 것을 꼬집고 싶습니다. 만약 이 프로토타입을 시각용으로밖에 사용할 수 없다면 노력이 줄어든 것이 아니라 옮겨간 것 뿐이니까요.

개발자로서 일을 덜어주는 멋진 툴인 것은 분명합니다!



Session 4. Goodbye 점검 공지 - 서비스 중단없는 점검 수행



네번째 시간인 서비스 중단 없는 점검 수행은 엔지니어의 느낌이 물씬한 재미있는 이야기가 많았습니다. 하루에 엄청난 접속자를 자랑하는 네이버가 언제부터인가 점검공지가 잘 안보이는 이유, 대체 무슨 방법으로 서버를 내리지 않고 가동율 식스나인에 도전하는 것인지 궁금하네요.


굿바이 점검공지. 김주관 카페서비스 랩장. 엔지니어의 포스가 감지됩니다.




기본 아이디어는 이렇습니다. 웹 서비스의 90%는 Write가 아닌 Read이므로 이 부분을 철저히 이용하자는 것이죠. 한마디로 사용자에게 조회만 제공해도 대부분 충분히 만족해 할테니 이용율이 낮은 이용시간대를 공략해 쓰기만 제한하여 점검을 수행하면 이들은 점검이 일어나는지조차 알기 어렵다는 것입니다. 이정도면 거의 98% 이상의 만족도를 보이지 않을까요?


아저씨 힘좀 쓰겠는데요? 누워서 노트북 하던 저도 뜨끔





이러한 것은 복제DB를 통해 가능해 집니다. 실 DB의 내용을 복제 DB로 항상 카피 하다가 만약 점검이 필요하다면 실 DB를 막고 복제 DB와 커넥션을 맺는 것이지요. 복제 DB에서는 읽기만 가능하며, 점검이 완료되면 스키마나 데이터가 변경된 실 서버를 다시 연결해주고 복제DB를 후 처리해주므로서 사용자는 연속된 서비스로 느끼는 것입니다.


서비스 DB는 CRUD의 권한을 이용할 수 있지만 복제DB는 R만 가능합니다.





클래스 다이어그램을 보실까요? NHN은 아무래도 자바로 서비스하는 듯 하군요. DB가 점검 상태라는 것을 싱글턴 패턴으로 나타냅니다. 요청이 들어오면 인터셉터에서 이를 알아채구요. 그에 맞는 적절한 DAO로 대체 됩니다. 이 대체 DAO는 복제 DB과 커넥션이 맺어져 있으니 쓰기가 발생할 일은 없을 듯 싶군요. 점검중에는 댓글을 사용할 수 없으니 그에 맞는 View가 변경되겠습니다.


주황색 부분이 바로 점검이 일어나야할때 변경되어 적용되는 things들 입니다.




랩장님은 여기서 더 나아가 정말 요청이 잦은 액션에 대해서만 읽기모드를 지원하고 나머지 액션들에 대해서는 그냥 점검 공지를 띄워버리는 강경책으로 노력대비효과를 극대화하는 팁을 알려주셨습니다. 왜 이런짓을 하냐고요? 다양한 DB서버가 다양한 테이블을 다양한 기능과 함께 무수히 많은 경우를 만들어 냅니다. CRUD매트릭스가 3차원이 되어버리네요. 1%를 위해 99%의 노력을 들일 필요 있나요? 수확체감의 그래프를 그릴 뿐이죠. 그래서 이런 팁이 나오는 겁니다. 그리고 커넥션의 유연한 연결을 위해 미리 커넥션 풀을 두 개 만들어 쉽게 해결할 수 있다는 팁도 설명해주셨습니다.


여러 DB와 수많은 액션의 지옥. 완전 3차원 CRUD Matrix입니다.



  점검 중에 쓰기를 제한한 화면으로 대체된 모습입니다. 까짓거 대부분의 이용자들이 자는 시간에 잠깐 쓰기만 제한하지뭐!


쓰기 기능이 제한된 무중단 점검. 조회수와 댓글은 조금 안타깝지만 참아주세요.




사용자는 아무리 미리 점검공지를 띄워놓아도 먼나라 이야기일 뿐입니다. 그저 내 눈앞에 무언가 예상치 못한 화면이 뜬다면 화를 낼 뿐이죠. 이게 뭐야 점검이라고? 난 지금 옆집 순이의 글을 봐야만해. 이런건 내가 하지 않을때 하라고!

서비스 중단없는 점검은 이러한 부분을 해소하여 높은 만족도를 제공할 듯 싶네요. 그런데 질의응답 시간에 이런 질문이 나왔습니다. 이를 개선하여 쓰기까지 가능한 시스템을 구축할 수 없겠냐는 식이었죠. 당연히 가능합니다. 하지만 비용대비효과가 전혀 나오지 않겠는데요? 소프트웨어의 모든 버그를 잡는다면 분명 장인정신에 입각하는 것이지만, 까짓거 일년에 한 두번 터지는 사소한 버그에 궂이 큰 비용을 들여 고칠 필요가 없습니다. 재 실행하세요. 물론 높은 신뢰성을 필요로 하는 분야라면 다른 이야기이지만 말입니다. 그런 분야는 특수한 경우입니다. 하지만 새벽에 일어난 조회 몇 건이 올라가지 않는다고 큰 문제가 되진 않습니다. 그럼에도 불구하고 write가 가능하게 하려면 배에 달하는 비용이 발생하게 되지요. 기업은 이윤을 추구하므로 이러한 것은 당연한 결과입니다. 버그를 잡았을 때 얻는 이득보다 잡는 과정에 발생하는 비용이 더 크다면 어느 쪽의 장단에 놀아야 할까요? 참고로 로그인을 하는 과정에서 특별히 중요한 write는 일어나지 않는답니다.




Session 5. 모바일앱 모바일과 서비스를 함께 담는 그릇 만들기 체험기


신재경 모바일앱개발팀장. OS가 백신프로그램도 아니고 왜이렇게 잦은 업데이트를 하는 건가요!!

마지막 시간이 돌아왔습니다. 이쯤 되니 정말 많은 분들이 빠져나가셨습니다. 덕분에 우리는 맨 앞자리 의자에 앉을 수 있었습니다! 엉덩이가 한결 편안해지는군요.

NHN에서 모바일 어플리케이션을 만드는데 어떠한 고충이 있는지를 털어놓고 계십니다. 잦은 OS 업데이트가 하위호환성을 지원하지 않아 정말 열받는다고 하셨습니다. UX때문에 고민도 많이 하시는 것 같구요. 사실 마지막시간이라 집중도가 떨어진 탓인지 세그폴트 일으킬 포인터 조차 반환되어 버렸네요. 기억이 잘 안납니다.. 죄송해요... 아무튼 재미있던 시간이었습니다. 저는 갤럭시S 씁니다.


일정 끗. 이제 집으로 돌아갈래요


서울은 좋은 곳 입니다. 스타크래프트2를 공짜로 최신사양에서 할 수 있어요. 의자는 조금 작군요. 다이아몬드에서 떨어져 이제 플래티넘 이랍니다.




두 판 정도 이기고 나니 이제 버스를 타러 가야할 시간입니다. 트랙 앞으로 되돌아가보니 저희처럼 버스를 어디서 타야하는지 궁금해하시는 분들이 계셨습니다. 우리는 NHN 분들의 도움을 받아 버스 타는 곳까지 안내를 받을 수 있었구요. 기념품을 못챙긴게 조금 아쉽지만 좋은 이야기 많이 들었는걸요. 그때까지만 해도 우리가 서울에서 얻은 기념품이라고는 스타크래프트2 초보자 가이드 두개가 전부인줄로만 알았습니다.





찬란하게 빗나는 NHN 종이가방!




그런데 버스에 타려는데 무언가 나누어 주시네요! NHN에서 직원들에게 나누어주었던 기념품들을 노획하여 버스를 타고 와서 못 받으신 지방분들에게 나누어준다고 합니다. 이럴수가! 그 분들에게는 미안하지만 정말 뜻밖의 선물이었습니다.


The Platform. 이 안에는 어려운 이야기들이 잔뜩 있습니다.


세상에나 이렇게나 많이 들었는 줄은 몰랐네요. 손목패드, 행사일정표, 로고가 박힌 볼펜, 노트, 그리고 머그컵!! 아까워서 아직 한번도 쓰지 못했습니다. 스타크래프트2 초보자 가이드도 일단은 기념품이니 함께합니다.

정말 고마웠습니다. 빼앗긴 분들의 마음은 어땟을까요? 머그컵 종이박스의 뚜껑이 열었다 닫은 흔적이 보입니다. 제가 눈물이 나네요. 대신 꼭 잘 써드리겠습니다!

대구에 도착하니 11시가량되었습니다. 생각보다는 일찍 도착했지요. 피곤에 지친 몸을 이끌고 집에 돌아와 푹 퍼졌답니다. 아 역시 집이 최고야




내년이 기대됩니다.

알고보니 작년에도 이러한 행사를 했다고 합니다. 전 작년에 이맘때 제초를 하고 있었던거 같네요. 첫 회를 함께 하지 못한 것은 아쉽지만 QP라던지, 리팩토링 혹은 NHN이 실제로 겪고 부딪히는 문제점과 그에 대한 솔루션을 공개하여 개발자에게 흥미로운 이야기를 잔뜩 해주는 NHN의 행사는 너무나 좋았습니다. 오죽하면 제가 이런 사항들을 다 기억할 정도라니까요. 왠만큼 재미가 없으면 메모리가 후져서 기억을 잘 못합니다. 다음 해에는 좀 더 레벨업을 해서 모든 시간을 머릿 속에 잘 담을 수 있도록 하겠습니다.


그때는 꼭 의자 수를 두배로 늘려주세요. 스타크래프트2 확장팩 행사도 하고 있으면 좋겠네요.

...식권도 주시려나요?




THinkBerry의 생각열매를 함께 나눠요. ThinkBerry.co.kr
TAG

Leave Comments


profileThinkberry에 오신것을 환영해요~ 

Recent Trackback

오늘:
4,166
어제:
3,552
전체:
76,325