성능 검증(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)는 닮은 점이 있다. 반복적인 작업을 피하고 대량의 결과물을 효율적으로 생산한다는 같은 목적을 갖는다. 그리고 틀을 만드는..
지속적 통합(Continuous Integration)은 짧은 주기로 소프트웨어(Software/Application/Service)를 개발하고, 사용자에게 빠르게 전달한 다음, 개선사항을 제안받아 다음 번 개발에 반영함으로써 지속적이고 주기적으로 소프트웨어를 개선해 나가는 개발 방법을 말한다. 이렇게 하면 사용자의 요구사항이 변경되더라도 쉽고 유연하게 맞춰나갈 수 있다. 보통 소프트웨어 개발은 설계, 개발, 검증, 배포의 과정으로 진행하는데, 전통적으로 전 과정에서 각 단계는 분리되어 있었고 뒤로 되돌아 가기 어려웠다. 그래서 보다 꼼꼼하게 설계하고 많은 시간을 설계 문서 작성에 공을 들였다. 일부의 경우 이러한 방법이 잘 맞았다. 요구사항의 변화 폭이 크지 않은 경우엔 충분히 설계를 검토하고 문서를 ..
지속적 전달(Continuous Delivery)은 짧은 주기로 소프트웨어를 개발하고, 언제든지 안정적으로 배포할 수 있도록 하는 소프트웨어 공학(Software Engineering)이다. 모든 변경사항은 언제라도 운영가능한 상태(Production ready)가 되도록 만드는 것이다.작은 규모의 소프트웨어를 짧은 시간동안 개발해서 즉각적으로 사용자에게 전달하겠다는 도전은 도달하기 쉽지 않은 목표이지만, 이를 통해서 사용자(소비자, 고객)의 만족을 높일 수 있으므로 매우 중요하다. 그래서 지속적 전달이라는 용어가 정립되기 전에도 같은 목표(애자일 철학)을 이루기 위한 여러 시도가 있었다. 바로, 지속적 통합이다. 지속적 통합을 통해서도 사용자의 피드백을 지속적으로 반영하고 개선하는 노력을 하였고, 주로..
코드 리뷰(Code Review)의 목적에 대해서 이야기해 본 적이 있다. 코드 리뷰의 목적에 대해 말하면서 다음 번에는 코드 리뷰를 잘 하는 방법에 대해 이야기 하기로 했다. 그래서 코드 리뷰를 잘하기 위한 방법에 대해 공유해 보고자 한다. 가장 먼저 하고 싶은 이야기는 '숙제 검사 이야기'다. 코드 리뷰를 처음 접하는 사람들이 리뷰를 숙제 검사로 받아들이는 경우가 많았다. 어떤 일이 주어지면 그 것에 대한 기능을 개발하고나서 결과를 검사해 달라는 의미로 리뷰를 요청하였다. 보통 이런 경우는 몇 가지 특징이 있다. 예상 일정의 마감 직전에 풀 리퀘스트(PR; Pull Request)가 올라온다. 그리고 거기에는 꽤 많은 양의 코드가 포함되어 있다. 또한 코드에 대한 설명이 별로 없다. 보통 이런 코드 ..
2021년, AWS에서 제공하는 카오스 엔지니어링 서비스인 장애 주입 실험기(Fault Injection Simulator, FIS)를 출시하였다. 그래서 서비스 장애 주입 실험기를 활용하는 카오스 엔지니어링 테라폼 예제(https://github.com/Young-ook/terraform-aws-fis/)를 만들었다. EC2 오토스케일링 그룹, EKS 컨테이너 클러스터, RDS 데이터베이스 클러스터, Redis 클러스터, VPC 네트워크를 대상으로 장애를 주입하는 카오스 엔지니어링을 직접 실습 해볼 수 있다.카오스 엔지니어링(Chaos Engineering)이라는 이름만 들었다면, 여러가지 상상이 떠오를 것이다. 아니다, 어쩌면 모든 사람이 같은 생각을 떠 올렸을 수도 있다. 우주가 탄생하기 전 혼돈의..
버전 관리(Version Control)는 문서, 프로그램, 웹 페이지 등 어떠한 형태의 정보 집합이든지 그 변화를 기록하고 관리하는 것을 뜻한다. 이렇게 변화의 내용을 관리하면, 결과물의 편집본과 최종본을 쉽게 관리할 수 있으며, 여러 사람이 함께 공동으로 작업할 수 있게 해준다. 아마도 대부분의 사람들이 파일(File)의 이름을 바꿔가면서 이력관리 해본 경험이 있을 것이다. 이 방법이 가장 직관적이며 쉽게 떠올 릴 수 있는 방법이기 때문이다. 그러나 회사에서 여러 사람들과 공동의 작업을 진행하는 경우에도 같은 방법을 사용하게 되면 많은 불편함을 겪게 된다. 누가 작업하고 있는 것이 최종인지 확인이 어렵기 때문이다. 취합본이라는 메일을 받아 본 기억을 떠올려 보자. 현재 자신이 작업 중인 문서와 메일로..