우리는 조직 내에서 의사소통 비용이 많은 비중을 차지 하는 지 이미 알고 있다. 그래서 문서 작성 및 공유, 데일리 스크럼 등의 다양한 방법을 통해 소통과 합의 문제를 해결하려고 노력해 왔다. 소프트웨어 개발과 운영 과정에서도 같은 문제가 있다. 어떤 소프트웨어를 소비자에게 전달했고, 어떤 기능이 동작하고 있는 지, 문제가 발생했을 때 원인이 무엇인 지 파악하기 어렵다. 그래서 문제의 원인 파악과 조치 방법에 대해 아무도 답을 줄 수 없거나 맥락과 답이 제각각인 경우가 있다. 규모가 더 커지면, 이러한 소통의 복잡도는 더 높아진다. 이러한 문제를 해결하기 위한 아주 간단한 방법이 있는데, 모든 구성원이 이해하고 만장일치할 때까지 소프트웨어를 제공하지 않도록 절차를 만들고 지키는 것이다. 소프트웨어 개발과..
플랫폼 엔지니어링(Platform Engineering)은 소프트웨어 수명주기를 관리하기 위해 개발자가 스스로 개발, 배포, 운영을 할 수 있도록 셀프 서비스 환경을 구축하는 것을 말한다. 내부 사용자, 일반적으로 소프트웨어 개발자 및 엔지니어에게 공유 플랫폼을 제공하여 서비스 운영 효율을 높이는 것이 목적으로 하며, 최종 사용자에게는 드러나지 않는다. 공유 서비스(Shared Service), 데브옵스 툴(DevOps Tool) 또는 단순히 도구(Tool)라고 부르기도 한다. 플랫폼 엔지니어링이 중요한 이유는 개발자가 스스로 무엇인가를 만들고 시도해 볼 수 있는 효율적인 환경을 제공하되, 걸림돌 또는 병목 지점이 되지 않는 다는 것이다. 넒게 보면 이러한 장점은 서비스 개발 및 배포 간격을 짧게 해주며..
포카요케(Poka-yoke)는 일본어이며, 실수를 사전에 방지한다는 의미를 갖고 있다. 이 단어를 처음 들었던 곳은 지속적 전달(Continuous Delivery) 저자인 Jez Humble의 워크샵이었다. 지속적 전달의 개념과 파이프라인, 검증 자동화, 버전 관리, 인프라스트럭처 관리, 안전한 배포방법, 모니터링에 대한 이야기를 들었다. 워크샵이 거의 끝날 때 쯤, 강사였던 Jez는 ATM기기에서 카드 리더기 방향이 한쪽으로만 가능하도록 설계된 그림을 보여주었다. 그림을 설명하면서 소프트웨어 엔지니어링에도 비슷한 설계가 필요하다고 강조했다. 소프트웨어를 개발하고 운영하는 과정에서 시스템이 문제를 일으키는 경우 보다는 사람의 실수에 의해 일어나는 문제들이 많다고 말했다. 그래서 사람이 실수하지 않는 시..
너무 오래 전 있었던, 게으름으로 인하여 기록하지 못했던 이야기를 남겨본다. AWS RDS(Relational Database Service)가 베타 버전이었을 때였다. 당시 우리 팀에서 RDS에 대한 우려가 많았던 시절이었고, 그래서 AWS RDS 엔지니어가 직접 한국을 방문했다. 그래서 우리는데이터베이스 관련한 다양한 질문을 주고 받았다. 그 중에서 기억에 남는 일화를 가져와봤다. RDS 엔지니어를 만났을 때의 첫인상은 다음과 같았다. 젋어보였고 짙은 갈색 머리를 가진 백인이었다. 뽀얀 피부에 수염을 길렀고, 진한 검정색이 매력적인 씽크패드를 들고 왔다. 잘 차려입은 격식있는 모습은 아니었지만 단정하고 깔끔한 인상이었다. 사실 그의 모습이 중요한 것은 아니었지만, 너무 인상깊었기 때문에 언급하고 싶었..
성능 검증(Performance Test) 방법 중 하나인 스트레스 검증(Stress Test)에 대한 이야기를 해보려고 한다. 시스템의 성능을 가늠하고 측정하는 방법에는 여러 가지가 있을 수 있지만, 대표적으로 많이 활용하는 3가지는 부하 검증(Load Test), 스트레스 검증(Stress Test), 내구성 검증(Endurance Test)이 있다. 클라우드 환경이 널리 퍼지면서 확장성 검증(Scalability Test)도 성능 검증의 범주에 포함되고 있다. 내 주변의 통계는 늘 틀린다는 것을 알고있지만, 실무에서 많은 소프트웨어 개발자들을 만나다보면 시간부족을 이유로 검증과정을 대충 넘기는 것을 자주 볼 수 있었고, 테스트에 대해 잘 모르는 개발자들도 의외로 많았다. 성능 검증과 성능 분석을 혼..
단체 채팅방에서 '봉'을 달라고 부탁하는 경우를 자주 봤다. 여기서 말하는 '봉'이란 리뷰 승인과 동의를 표현하는 엄지척의 애칭이다. 이러한 '봉' 요청 몇 번은 애교로 넘어갈 수 있었지만, 시간이 흐를수록 '봉'을 받아야 다음으로 넘어간다는 암묵적인 인식이 퍼져가는 것을 느낄 수 있었다. 때로는 '봉'을 못받아서 다음 업무를 수행하지 못한다는 말도 들었다. 이러한 방식은 건전한 코드 리뷰를 방해한다. 리뷰와 승인을 받는 과정이 왜곡되기 때문이다. '봉'만 얻으면 다음 단계로 진행할 수 있다는 생각은 다음과 같은 몇 가지 문제를 만든다. 첫째, '봉'만 요청하면 된다는 문화가 정착되면, 형식에 치중하게 만들어서 '봉'을 남발하게되고 결국 최종 코드의 품질을 떨어트린다. 시간이 촉박하다는 이유만으로 리뷰 ..
버전관리체계(Version Control System)를 사용하는 것이 어떤 장점을 가질 수 있는 지 그리고 여러가지 도구 중에서 깃(Git)이 어떤 특징과 장점을 가지는 지 살펴봤다. 이번에는 실제 깃을 어떻게 사용하면 좋을 지에 대한 이야기를 하려고 한다. 깃헙 또는 깃허브(GitHub)이라고 부르는 서비스가 있는데, 전 세계의 개발자들이 공동 작업을 위해 자주 사용하고 있다. 깃헙은 소스코드 버전을 관리하는 깃과 협업 문서 도구인 위키(Wiki), 사용자 접근제어 등을 제공하는 프로젝트 통합관리 도구로써 유명하다. 그러면 깃헙을 이용해서 어떻게 공동작업을 진행하는 지 그 절차에 대해 살펴보기로 한다. 깃헙을 이용할 때 크게 두 가지 방법이 있다. 마스터 브랜치(Master Branch)에서 새로운 ..
코드 리뷰(Code Review)는 생각보다 어려운 일이다. 사람들끼리 대화를 주고 받아도 협업이 잘 안되는데 글로 공유하면서 협업을 잘 할 수 있을 지 미지수다. 아마도 회의실에 모여서 그림을 그리며 설명하는 편이 훨씬 더 생산적일 것이다. 깃허브(GitHub)에 코드 말고 그림을 한 껏 올려서 리뷰를 한다면 모를까 소스 코드(Source Code)와 댓글로 이루어진 리뷰 과정을 보면 협업을 위한 코드리뷰의 장점에 대해 회의감이 드는 것은 당연하다. 아마도 코드 리뷰의 목적에 대해 이야기한 것을 읽고 공감하는 사람도 있겠지만, 피부에 닿지 않고 멀게 느껴지는 사람도 꽤 많이 있었을 것이다. 그래서 코드 리뷰를 접근하는 방법에 대해 생각해보고 실천해 보면 좋겠다고 생각해서 숙제 검사 이야기와 형식적인 규..
클라우드(Cloud Computing) 환경을 기반한 서비스의 안정적이고 효율적인 운영을 위한 데브옵스(DevOps) 사례를 소개하는 발표를 했었다. 당시에 발표자료를 준비하면서 문득 떠오른 생각이 있었다. 클라우드 환경의 시스템을 코드로 관리하는 방법에 대한 개념과 실천 방법에 대한 소개였다. 이 것을 잘 설명하는 비유를 생각하다가 '직지'가 떠올랐다. 우리가 자랑스럽게 생각하는 현존하는 세계 최고(最古, 가장 오래된)의 금속활자와 그 활자로 출판한 책이다. 우리나라 사람이라면 대부분 직지에 대해 들은 적이 있다. 직지와 인프라스트럭처 코드(Infrastructure as Code)는 닮은 점이 있다. 반복적인 작업을 피하고 대량의 결과물을 효율적으로 생산한다는 같은 목적을 갖는다. 그리고 틀을 만드는..
깃(Git)은 버전관리체계(Version Control System)이며, 소포트웨어(Software)개발 또는 버전관리 작업을 위한 위한 도구이다. 깃은 2005년 리누스 토발즈(Linus Torvalds) 가 리눅스 커널(Linux Kernel) 개발 협업을 위해 만들었다. 역사 리눅스 커널은 굉장히 규모가 큰 오픈소스 과제(Opensource project)다. 리눅스 커널개발의 대부분 기간 동안(1991-2002) 패치(Patch)와 아카이브(Archive)로만 관리했다. 2002년에 리눅스 커널은 비트키퍼(BitKeeper)라는 상용 분산형 버전관리체계(DVCS: Distributed Version Control System)를 사용했다. 그러다가 2005년에 비트키퍼와 관계가 나빠지면서 리눅스..