continuousdelivery (18) 썸네일형 리스트형 Bomb Merge 우리는 조직 내에서 의사소통 비용이 많은 비중을 차지 하는 지 이미 알고 있다. 그래서 문서 작성 및 공유, 데일리 스크럼 등의 다양한 방법을 통해 소통과 합의 문제를 해결하려고 노력해 왔다. 소프트웨어 개발 및 운영도 사람이 하는 일이다보니 같은 문제를 겪고있다. 어떤 기능을 개발하고 있는 지, 어떤 방식으로 동작하는 지, 진행상황이 어떤 지 파악하기 위해서 수 많은 회의를 하고 보고서를 작성한다. 규모가 더 커지면, 이러한 소통의 복잡도는 더 높아진다. 이러한 문제를 해결하기 위한 아주 직관적인 방법이 있는데, 감독관이 검토하고 승인하는 절차를 만들고 지키도록 강제하는 것이다. 소프트웨어 개발과 관리의 효율성과 품질을 높이기 위해서는 소통의 문제는 반드시 풀어야 한다. 그러나 모두가 힘들면서 속도도 .. Serendipity 2012년 4월 초, 갑자기 부서장이 불렀다. 컨텐츠 전송 네트워크(CDN, Content Delivery Network)관련 워크샵이 있는데 다녀와 보라는 것이었다. 뜻밖의 일이라 놀랍고 얼떨떨했다. 새로운 것을 배울 수 있는 소중한 기회를 얻었다는 기쁨도 있었지만, 연차가 있는 높은 직급의 직원들이 주로 다녀오는 기술 세미나에 입사한 지 1년도 안된 대리가 참석하게 되었으니 어안이 벙벙했다. 어쨌든 하루의 외근과 외근을 통한 지식의 확장은 행운이었기 때문에 기쁘게 다녀왔다. 세미나 장소는 대학교의 대강당 처럼 생긴 곳이었다. 강의장에는 이미 많은 사람들이 앉아있었다. 앞 뒤로도 좌우로도 중간 정도 되는 위치에 자리를 잡았다. 커피로 정신을 깨우지 못한채로 첫 순서가 시작되었다. 외국인 강사가 나와서.. Agile 애자일(Agile)은 예측하기 쉽지 않고 계속 변화하는 사장의 요구사항에 맞게 소프트웨어를 지속적으로 개선해가는 실용주의 철학이며, 실천운동이자 방법론이다. 애자일 매니페스토(Manifesto)를 살펴보면, 절차나 도구 보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를 가치있게 여긴다고 언급한다.전통적인 소프트웨어 개발에서 중요하게 여겼던 왼쪽의 요소들(절차, 문서, 계획, 계약)도 중요하지만 사실 그것보다는 소프트웨어를 만드는 궁극적인 목적에 더 집중하겠다는 선언을 담고 있다. 설계문서가 세밀하고 꼼꼼하더라도 생산된 결과물이 제대로 동작하지 않으면 무용지물이다. 설계도는 우수했으나 생산문제라고 싸우는 봤자 아무 의미가 없다... Stress Test 성능 검증(Performance Test) 방법 중 하나인 스트레스 검증(Stress Test)에 대한 이야기를 해보려고 한다. 시스템의 성능을 가늠하고 측정하는 방법에는 여러 가지가 있을 수 있지만, 대표적으로 많이 활용하는 3가지는 부하 검증(Load Test), 스트레스 검증(Stress Test), 내구성 검증(Endurance Test)이 있다. 클라우드 환경이 널리 퍼지면서 확장성 검증(Scalability Test)도 성능 검증의 범주에 포함되고 있다.내 주변의 통계는 늘 틀린다는 것을 알고있지만, 실무에서 많은 소프트웨어 개발자들을 만나다보면 시간부족을 이유로 검증 과정을 대충 넘기는 것을 자주 볼 수 있었고, 테스트에 대해 잘 모르는 개발자들도 의외로 많았다. 성능 검증과 성능 분석을 혼.. Code Review, Thumbs-up 단체 채팅에서 '봉'을 달라고 부탁하는 경우를 자주 봤다. 여기서 말하는 '봉'이란 리뷰 승인과 동의를 표현하는 엄지척의 애칭이다. 이러한 '봉' 요청 몇 번은 애교로 넘어갈 수 있었지만, 시간이 흐를수록 '봉'을 받아야 다음으로 넘어간다는 암묵적인 인식이 퍼져가는 것을 느낄 수 있었다. 때로는 '봉'을 못받아서 다음 업무를 수행하지 못한다는 말도 들었다. 이러한 방식은 건전한 코드 리뷰를 방해한다. 리뷰와 승인을 받는 과정이 왜곡되기 때문이다. '봉'만 얻으면 다음 단계로 진행할 수 있다는 생각은 다음과 같은 몇 가지 문제를 만든다. 첫째, '봉'만 요청하면 된다는 문화가 정착되면, 형식에 치중하게 만들어서 '봉'을 남발하게되고 결국 최종 코드의 품질을 떨어트린다. 시간이 촉박하다는 이유만으로 리뷰 승.. GitHub Workflow 버전 관리 체계(Version Control System)를 사용하는 것이 어떤 장점을 가질 수 있는 지 그리고 여러가지 도구 중에서 깃(Git)이 어떤 특징과 장점을 가지는 지 살펴봤다. 이번에는 실제 깃을 어떻게 사용하면 좋을 지에 대한 이야기를 하려고 한다. 깃헙 또는 깃허브(GitHub)이라고 부르는 서비스가 있는데, 전 세계의 개발자들이 공동 작업을 위해 자주 사용하고 있다. 깃헙은 소스코드 버전을 관리하는 깃과 협업 문서 도구인 위키(Wiki), 사용자 접근제어 등을 제공하는 프로젝트 통합관리 도구로써 유명하다. 그러면 깃헙을 이용해서 어떻게 공동작업을 진행하는 지 그 절차에 대해 살펴보기로 한다. 깃헙을 이용할 때 크게 두 가지 방법이 있다. 마스터 브랜치(Master Branch)에서 새로.. Asynchronous Code Review 코드 리뷰(Code Review)는 생각보다 어려운 일이다. 사람들끼리 대화를 주고 받아도 협업이 잘 안되는데 글로 공유하면서 협업을 잘 할 수 있을 지 미지수다. 아마도 회의실에 모여서 그림을 그리며 설명하는 편이 훨씬 더 생산적일 것이다. 깃허브(GitHub)에 코드 말고 그림을 한 껏 올려서 리뷰를 한다면 모를까 소스 코드(Source Code)와 댓글로 이루어진 리뷰 과정을 보면 협업을 위한 코드리뷰의 장점에 대해 회의감이 드는 것은 당연하다. 아마도 코드 리뷰의 목적에 대해 이야기한 것을 읽고 공감하는 사람도 있겠지만, 피부에 닿지 않고 멀게 느껴지는 사람도 꽤 많이 있었을 것이다. 그래서 코드 리뷰를 접근하는 방법에 대해 생각해보고 실천해 보면 좋겠다고 생각해서 숙제 검사 이야기와 형식적인 규.. Git 깃(Git)은 버전관리체계(Version Control System)이며, 소포트웨어(Software)개발 또는 버전관리 작업을 위한 위한 도구이다. 깃은 2005년 리누스 토발즈(Linus Torvalds) 가 리눅스 커널(Linux Kernel) 개발 협업을 위해 만들었다. 역사리눅스 커널은 굉장히 규모가 큰 오픈소스 과제(Opensource project)다. 리눅스 커널개발의 대부분 기간 동안(1991-2002) 패치(Patch)와 아카이브(Archive)로만 관리했다. 2002년에 리눅스 커널은 비트키퍼(BitKeeper)라는 상용 분산형 버전관리체계(DVCS: Distributed Version Control System)를 사용했다. 그러다가 2005년에 비트키퍼와 관계가 나빠지면서 리눅스 .. 이전 1 2 3 다음
