stream-handbook(1/2)

네트워크를 통한 서비스를 제공하는 시스템을 만드는것은 매우 어렵습니다

특히 리얼타임 서비스는 더 그렇습니다. 프로세스, 프로세스간의 통신, 동기화, 트랜잭션 같은 시스템과 연관된 저레벨의 문제에서 시작하여 재사용성, 가용성, 디자인 패턴 같은 높은 레벨의 이해 그리고 각각의 프로그래밍 언어들이 어떻게 이를 지원하는 지, 어떻게 메모리를 관리해야하는지에 대한 이해를 동시에 필요로하기 때문입니다.

Java, C, C++ 같이 범용적인 언어들의 영역에서는 시스템과 관련한 저레벨한 문제들을 감추고 사용자들이 손쉽게 사용할 수 있도록하는 라이브러리들과 미들웨어들로 추상화하는 다양한 솔루션들이 존재하며, Blocking에서 NonBlocking으로 변화 등등 같은  트랜드의 변화에 따라 다양하게 등장합니다. 계속 읽기 “stream-handbook(1/2)”

Advertisements
stream-handbook(1/2)

NOSQL 데이터 모델링 기법들(1)

최근 조그만 첼린지가 시작되었다. 어떤 소프트웨어 서비스의 데이터 저장 기반을 관계형 DB로 할 것인가? NoSQL저장소로 할것인가? 에 대한 것이다. 관계형으로 해결 했을 때의 scalability 문제 때문이다.

그래서 일단 NoSQL의 모델링 기법을 살펴 보기로 했다. 찾아보니 많은 글들의 참조로 사용된 글이 있어 먼저 이글을 옮긴다. 원문은 https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/   에서 볼 수있을 것이다.

NoSQL 데이터베이스는 흔히 확장성(scalability), 성능(performance), 일관성(consistency) 같이 다양한 비기능적인 척도를 가지고 비교됩니다.  이런 비기능 특징들이 NoSQL의 사용과, ‘CAP 정리’ 같이 분산시스템에 기초적인 원리와 NoSQL이 잘 맞는다는 사실을 정당화하기 때문에, 현장에서 그리고 이론적으로 많이 연구되고 있습니다.  반면에, NoSQL  데이터 모델링은  관계형 데이터 베이스와 같은 체계적인 이론이 없습니다. 이 글은 데이터 모델링 관점에서 NoSQL 류 시스템을 간단히 비교하고 몇가지 공통적인 모델링 기법을 다룰 것입니다.

계속 읽기 “NOSQL 데이터 모델링 기법들(1)”

NOSQL 데이터 모델링 기법들(1)

더도 말고 덜도 말고 한가위만 같아라…

아래 위로 소매가 긴 옷을 걸치기엔 아직 무거운 듯하고, 그렇지 않으면 피부에 와닫는 바람의 기운이 차가운 계절. 이맘때면 난 긴 소매 셔츠에 짧은 바지를 걸치고 돌아다니기를 좋아하게 된다. 주위의 나무들도 여름의 흔적을 벗어나지 못한 체 가을을 맞이하는 모양세다. 이쯤… 한 낮의 햇살이 여유로운 계절이다.

최근 난 또 한번의 선택을 했다. “충성과 성과” 멋지게 포장된 말들에서 내가 찾은 핵심이다. 내 답변은 이랬다. “성과와 정당한 댓가” 세상에 존재하지 않는 언어를 들은 듯한 이들의 표정에서 스폰지 밥의 집게 사장이 떠올랐다. 재미있는 순간이었다. 그들이 제시한 조건은 그들에겐 매우 파격적이었고 내겐 선택해야 할 유혹이었다. 그리고 나의 답변은 “내가 아직 이렇다 할 성과를 내게 보인적이 없어서 이 길을 더 가보겠습니다” 이었다. 그러자 가을이 와있었다.

근래들어 주변 사람들을 볼 때마다 다들 지나치게 여유를 빼앗기고 있다는 생각을 하게된다. 일상에 조금씩 스며들어 모든 것을 적시듯 자신들도 모르게 달리는데 익숙해져버린, 그렇지 않으면 안돼도록 몰아가는 더 큰 쳇바퀴 속의 사람들. 여러분은 1년전 혹은 2년전 그렇게 거슬러 올라가서 언제까지의 가을을 기억하는가? 그리고 그 때의 업무량과 지금의 업무량을 비교해 본적이 있는가? 간단하게 출근과 퇴근시간으로라도 말이다. 마치 인플레이션 현상과 같이 천천히 자기도 모르게 일에 도취됨을 강요 받은것은 아닌가? 지금! 추석을 맞아 가족과 함께하자. 회사 따위 알게 뭔가? 지금 만큼은 가족과 행복하고 풍성하게 늘어지자. 온 나라의 논과 밭이, 산과 들이, 계곡과 바다가 많고 적음을 떠나 자신들이 품어왔던 결실을 내놓으며 우리를 위로하는데, 무엇을 더 바래 책상에 앉아 있는가? 이 축제가 끝나도 그 일들은 당신을 기다리고 있을 테니 지금은 가족과 함께 추석을 즐기자. 조금 늦어도 죽지 않는게 정상이다.

친구들 올해도 행복한 추석으로 웃음이 끊이지 않기를… ^^

더도 말고 덜도 말고 한가위만 같아라…

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(3/3)

SRS(Software Requirements Specification)

‘요구사항 명세’, ‘요구사항 정의’ 어떻게 부르던 SRS는 요구사항 정의 활동의 산출물이다. 요구사항 정의서를 작성하는 중요한 목적 중 한 가지가 이해 당사자들에게 검토를 요청하고 피드백을 받는 것이기 때문에 쉽게 읽고 검토 할 수 있는 형식을 가져야한다. 요구사항 정의서는 높은 수준의 설계를 포함하게 되는데, 이는 당연한 것이다. 요구사항 정의서는 설계 활동에 꼭 필요한 입력이면서 설계의 아웃라인을 제공하기 때문이다.  요구사항 정의를 어떻게 기술 할 것인가에 대해 SWEBOK에는 다음과 같이 기술되어 있다.

계속 읽기 “서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(3/3)”

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(3/3)

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(2/3)

비즈니스 도메인 이해

나는 모든 업무에서 문제를 해결할 때 가장 좋은 시작 방법은 문제를 나누어 분류하는 것(Categorizing)이라고 생각한다. 문제를 분류하고 체계를 세우면 문제의 본질이 명확해지고, 큰 덩어리로 있을 때 보이지 않던 문제의 접근점이 보이게 된다. 이렇게 문제를 정의하고 분류하려면 문제에 대한 기본적인 이해를 가져야한다. 마찬가지로 효과적인 아키텍처를 위해서는 기술 뿐만이 아닌 대상 문제의 비즈니스 도메인의 이해가 필요하다. 비즈니스 도메인을 이해하지 못하면 비즈니스의 문제, 목표, 요구를 이해하기 힘들어 요구사항을 충족하는 효과적인 아키텍처를 설계하기 힘들다. 보통 이것은 아키텍트의 롤이다. 그렇다면 아키텍트만이 해당 비즈니스 도메인에 대한 이해를 가지면 될까? 답은 그럴수도, 아닐수도 있다는 것이다.

계속 읽기 “서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(2/3)”

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다.(2/3)

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다. (1/3)

요구사항 정의 없이 할 수 있는 유일한 일은 요구사항을 정의하는 것이다.

소프트웨어 공학에서 고객의 요구사항 정의는 도출(elicitation), 분석(analysis), 정의(specification), 검증(validation)의 단계를 거처 정의하고 관리(management)한다고 한다. 결과적으로 요구사항을 정의하고 관리하기 위함이니 나는 이 과정을 통틀어 ‘요구사항 정의’라고 하겠다. 사실 업무용 소프트웨어를 만드는데 소프트웨어 공학의 모든 활동과 절차를 지키는 것은 무리한 요구일 수 있다. 나는 소프트웨어 공학의 경우 항공, 에너지, 국방 등 산출물의 기대 품질이 매우 높고 규모가 거대한 프로젝트에서 실패하지 않고자하는 노력의 산물이자, 이를 일반화한 것이기 때문에, 규모와 형편에 따라 필요한 활동과 절차를 알맞게 적용하는 것이 올바르다고 생각한다. 하지만 무엇을 효과적으로 사용하기 위해서는 그 무엇에 대해 이해하고 있어야 한다. 그런 관점에서 소프트웨어 개발 프로세스, 소프트웨어 개발 프로젝트 관리에 대한 공학적인 지식을 갖추는 것이 중요하다. 알기도 전에 들은 이야기를 빌어 어떤 것은 필요하지 않다거나, 그건 꼭 따라야 한다는 것은 얼마나 유아적이고 어리석은 짓인가?

계속 읽기 “서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다. (1/3)”

서비스는 고객의 요구를 만족시키기 위한 노무를 제공하는 것이다. (1/3)

소프트웨어 개발 프로젝트라는 열차의 앞 칸에서는 도대체 무슨 일이 벌어질까?

IT 서비스에서 소프트웨어 개발이 실행될 때 까지는 어마 무시하게 많은 과정이 앞서 진행된다. 물론 개발 후에도 많은 과정이 존재한다. 나는 “사업”이 어떤 목적을 달성하기 까지의 총괄적인 과정이라면 “프로젝트”는 목적을 위한 목표를 달성하는 과정, 즉, 사업의 부분 집합으로 수행의 의미가 강하다고 생각하여 “사업”과 “프로젝트”의 의미를 다르게 사용한다. 여기서는 일단 “사업”이라는 면에서 살펴보자. 소프트웨어 개발을 실행하는 사람들의 입장에서는 별반 와닫지 않는 과정일 수 있다. 그도 그럴것이 발주처 측이 수행하는 조직의 목표 수립, 전략 수립, 사업 계획, 마케이팅 같은 경영학 용어나 행정 표준 지침은 복잡하고 고루해 보이며 수주업체가 수행하는 기술검토, 손익분석, 제안서 작성, 실행계획은 알고 싶지 않은 머나먼 이야기 처럼 들릴것이니 말이다. 그러나 발주처와 수주처의 수행 결과가 만나 평가를 통해 사업이 실행된다. 또 이 과정의 산출물이 프로젝트의 뼈대를 제공하므로 어떻게 만들어지는지 아는 것이 유익할 것이라 생각한다. 계속 읽기 “소프트웨어 개발 프로젝트라는 열차의 앞 칸에서는 도대체 무슨 일이 벌어질까?”

소프트웨어 개발 프로젝트라는 열차의 앞 칸에서는 도대체 무슨 일이 벌어질까?