• 변경사항
  • 2016.10.26 - 초안 작성
  • 2016.10.27 - 수정

나는 서버를 썰 터이니 너는 개발만 하여라

개발 업무를 전담하기 위해선 개발자는 '인프라' 혹은 '시스템'과 별개로 분리되어야 합니다. 종속변수가 아니라 독립변수로 존재해야 합니다. 개발자가 '인프라'나 '시스템'과 결합되어(강결합?) 어떤 관계가 만들어져서 종속변수로 존재하게 되면 생산성의 저하를 막을 방법이 ~~(전혀)~~없습니다. 서비스 품질을 높이고 싶다면 혹은 생산성의 저하를 막아보고 싶다면 개발팀의 구성원이 자신의 작업에 더 많은 '주의'을 기울여야 합니다. 그러기 위해선 개발자의 '컨텍스트 스위칭(Context Switching)'을 최소화 해야 합니다.

국내의 개발 문화에서 개발팀이나 개발자가 인프라와 완벽하게 분리할 방법이 (사실상)'거의' 없기 때문에 개발자가 불필요하게 소비해야 할 활동은 '자동화'를 통해서 개발자의 업무 영역에서 철저히 격리해야 합니다. 자동화를 통해서 개발팀 자체를 DevOps 형태로 변화시키는 것도 충분히 가치있는 도전이지만, 적은 인원으로 서비스를 만들어가는 개발팀의 경우 자동화 가능한 영역은 '인식의 영역'에서 분리시키는 노력을 꼭 필요하다 생각합니다.

사내 컴퓨터가 고장이 나거나, 프린터등의 문제로 개발팀의 누군가를 호출하거나 그들의 인식영역 안으로 들어오는 일이 비일비재한 상황은 회사의 C-클래스에서 충분히 '자동화(필요한건 Cash!)'를 할 수 있는데 반해서 '인프라'나 '시스템'의 자동화는 Cash로 해결되는 일이 아니기 때문에 많은 고민과 약간의 어려움을 겪고 있습니다. 나는 서버를 썰 터이니 너는 개발만 하여라 세션은 그러한 노력과 고민을 조금 덜어줄것이라 생각한다. 세션을 들으면서 생각하고 고민했던 내용을 정리해봅니다.

자동화의 필요성

Lean Startup, Agile등과 같은 개발 프로세스를 회사에 정착시키기 위해서는 시스템이 뒷받침 되어야합니다. 하위 구조가 상부 구조를 결정한다는 Karl Marx의 주장을 다시금 상기 할 필요가 있습니다.

칼 막스의 경구를 하나 차용한다면 '하나의 유령이 스타트업을 떠 돌고 있다. 효율적인 개발 프로세스(=야근?)라는 유령이!' 자동화 되어있지 않은 시스템에서 '개발 프로세스'란 (많이) 무의미한것 아닌가 생각해봅니다.

자동화 과정

현재 회사에서 진행하는 과정 중에서 자동화가 가능한 부분을 선정해서 차근 차근 진행해야 합니다. 자동화를 목적으로 없던 일을 자동화 하는 것이 아니라, 기존의 업무 중에서 불필요한 부분을 자동화 시키는게 효율적인 것 같습니다.

자동화의 이점

인프라를 자동화 해서 얻을 수 있는 이점은 적은 인원으로 대규모의 서비스를 운영 할 수 있다는 점입니다. 자동화를 진행하게 되면 1명이 관리할 수 있는 인프라의 영역이 넓어지기 때문에 개발팀 전체가 인프라에 대한 고민없이 개발을 진행해 나갈 수 있을 듯 싶습니다.

자동화를 통한 또 다른 이점은 서비스가 급격하게 성장하는 과정에서 개발팀의 안정성과 생산성을 담보하기 때문에 서비스 품질을 보장하는데 많은 기여를 할 수 있을 것입니다.

자동화를 선정하기 위한 도구

Ansible, Chef 등과 같은 프로비저닝 도구를 도입하려고 했는데, 우리팀에서 활용 가능한 도구가 있다면 그것을 선택하는 것이 좋다는 확신을 얻게 되었습니다. Bash로도 충분히 좋은 서비스를 구현할 수 있다는 점에서 기존의 레퍼런스를 참고하면서 우리팀에 걸맞는 방법을 생각해 볼만한 마음의 여유가 생긴 것 같습니다.

이번 세션에서 가장 큰 깨달음 입니다. 바퀴를 새로 만드는건 문제가 있지만, 좀 더 다양한 관점에서 고민 할 수 있는 여유가 생긴 것 같아서 한결 마음이 놓였습니다. 나도 힙한척 개발하는 것 아닌지 반성도 하였습니다.

무엇을 자동화해야 하는가?

필수적인 자동화 부분

서비스에 꼭 필수적이지만 부수적인 것들은 최대한 자동화를 진행할 수 있도록 해야합니다. 특히 모니터링 및 Log 관련 부분은 AWS와 같은 클라우드 서비스에서 지원하는 것을 이용하든, 개발팀 내부 역량을 활용하든 필수적으로 자동화를 진행하는 것을 서비스의 품질과 개발팀의 업무 효율을 위해서 적극 권장합니다. 이건 돈을 들여서라도 진행해야 합니다.

서비스가 성장하고 있다면 시스템 이중화 및 Test에 관련된 작업은 필수적으로 진행해야 될 항목입니다.

업무를 위한 자동화 부분

배포의 경우 개발자가 직접 배포 할 수 있는 환경을 만듬과 동시에 QA에서도 스테이징 서버를 만들 수 있도록 지원하면 훨씬 더 수준높은 서비스를 고객에게 제공할 수 있습니다.

자동화의 원칙은?

사용자를 배려하자!

자동 배포를 적용하는 과정에서 현재 시스템이 중단 되지 않도록 준비해야합니다. 현재 서비스를 사용하는 사용자를 최대한 배려해야 합니다. 우리 서비스를 사용하는 단 1명의 사용자가 겪게될 불편함에 대한 배려가 절대적으로 필요합니다. SW 품질을 높이는 이유가 서비스를 사용하고 있는 고객 때문이라면 현재 서비스를 활용하고 있는 단 1명의 사용자는 1명이 아니라 '전부'라 생각해야 합니다.

(그러나 현실적으로... 가능할까? 싶은 의구심도 있긴 합니다.)

무중단 배포 시스템 구축하기 - p.29

자동화는 자동화를 통해서 변경한다.

개발자가 수동으로 인프라 시스템의 구성을 변경하지 못하도록 제한하고, 만약 설정을 변경하거나 확인하는 과정이 필요할 경우 별도로 인프라를 제공해야 합니다.

인프라가 구성 요소의 변경에 종속되지 않도록 시스템 또한 독립적으로 존재할 수 있도록 전체 인프라나 시스템을 표준화해야 합니다.

시스템 표준화 - p.17

네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유

우리 서비스에서 발생되는 데이터를 처리하면서 겪게 될 고민을 이번 세션(네이버 콘텐츠 통계서비스 소개 및 구현 경험 공유)에서 잠시 빌려올 수 있었습니다. 로그를 처리하기 위해서 고민한 흔적의 편린을 친절하게 설명하고 있기 때문에 동영상이 공개되면 꼭 한번 보셨으면 좋겠습니다.

실시간은 이제 필수다.

이제는 서비스를 사용하는 고객도 자신이 생산한 콘텐츠에 대한 반응과 결과를 실시간으로 확인하길 원합니다. 결론적으로 말해서, 콘텐츠를 제공하는 서비스의 경우 결과를 사용자에게 실시간으로 알려주는 것은 이제 필수적으로 만들어야 될 것 같습니다.

블로그 사용자 설문조사 개선사항 TOP3, 1) 실시간 통계 2) 게시글별 통계

"그때는 맞고 지금은 틀리다"

언제나 레거시 시스템은 항상 고민이 됩니다. 그 때 옳았던 결정이 지금은 틀렸을 경우도 있고, 그 때의 틀렸던 결정이 지금은 말도 안되는 부담감을 주는 경우도 있습니다. 무엇이 되었든 레거시는 우리에게 '애증'으로 다가옵니다.

경험이 없거나 역량이 부족하면 레거시 시스템을 더욱더 격렬하게 옹호하게 되는 원동력이 되기도 합니다. 그러나 우리의 모자람을 가려주는 레거시 시스템은 우리의 모자람만 가려다 줄 뿐, 우리를 다른 곳으로 움직여주진 못합니다. 단 한 발자국도 내딛지 못하는 상황에서 레거시는 언제나 짐입니다.

경험을 미리 할 수 있는 방법이 없으니, 레거시를 개선하고 계속해서 꾸준히 관리하면서 적절한 리팩토링과 아름다운 설계에 집착해야 하는 이유 중 하나라 할 수 있습니다.

계산 방법

서비스 로직이 명확하다면, 서버 자원을 적절하게 활용 할 수 있는 방법을 최대한 활용해야합니다. 특히 하나의 방향을 지양하기 보다는 적절히 섞어서 사용하는 묘(妙)가 필요합니다.

[...] 미리 계산, [...] 바로 계산

설계 방법론

효율적이로 훌륭한 시스템을 가지고 싶다면 설계나 아키텍처에 대해선 아낌없이 투자해야합니다. 이런 투자는 향후 레거시를 레거시답게 만들고, 솔루션을 서비스답게 만들어준니다. 개발팀 전체가 설계나 아키텍처에 대해서 더 많은 토론과 생각을 교환 할수록 좀 더 좋은 방법을 찾을 수 있습니다.

머리속으로 우주를 시뮬레이션 했던 '아인슈타인'과 하나의 상자로 전 우주를 묘사했던 '베르너 하이젠베르크'의 예를 들지 않더라도, 해당 설계와 아키텍처를 고민하고 상상하는 과정은 충분히 많은 경험과 역량을 키울 수 있습니다.

하지만, '하나의 설계, 하나의 아키텍처', '올바른 설계, 정확한 아키텍처'같은 이상적인 토론은 지향하도록 해야합니다. 계란을 한 바구니에 담지 않는 법입니다. 좋은 설계란 현실의 토론과 대화에서 나오지, 동굴의 그림자의 원형에서 나오지 않습니다.

http://lambda-architecture.net

M/R v.s SparkSQL

기존의 M/R이 가진 문제점도 있겠지만 SQL로 변환했을 때 가져올 이점이 훨씬 더 많아 보입니다. 기초적이고 기본적인 기술이나 방법에 대해서 한번쯤 관심을 가져볼 필요가 있습니다. 그것이 이제는 '로스트 테크놀러지'가 되어간다고 해도 관심의 끈을 놓지 말아야 합니다.

문제 해결을 위한 방법

하나의 솔루션으로 모든 것을 해결할 수 있는 방법은 없습니다(No Silver Bullet: Essence and Accidents of Software Engineering을 참고 할 것). 여러 가지 방법을 합쳐서 하나의 솔루션으로 만드는 과정은 필수적입니다.

그러기 위해서 서비스에 대한 이해를 바탕으로 올바른 설계 방법을 고민하고, 기존 시스템과 연동하는 효율적이고 합리적인 방법등을 팀원과 함께 공유하고 고민해여 합니다.