2015년 5월 29일 금요일

흥분하지 않는 이유

최근 회사에서 주변 사람들이 나에게 이런 말을 몇번 들었다. 흥분하는 모습을 한 번 보고싶다고, 기분에 up and down이 별로 없지 않냐고.

집에서도 와이프한테 한번인가 들었던 말이어서 딱히 놀라진 않았다. 그리고 그런 내 성격이 나름 인생살이에서 좋은 점이라고 생각하고 있었다. 그래서 그런 모습으로 나를 보는 사람이 있다는 것도 기분이 괜찮았다.

나는 왜 그런 성격을 가지게 됐을까? 당연한 말이지만 처음부터 그렇진 않았다.  회사에서 개발을 하고 여러 사람들과 같이 업무를 하다보니, 나만의 기준이 생기고 그 기준에 따라서 행동하다보니 성격으로 굳어진 듯 하다.

아래 3가지는 내가 진리라고 믿고, 따를 만한 가치가 있다고 여기는 기준이다. 즉, 인생에 대한 가치관이고 삶에 대한 행동양식이다.

1. 모든 사건에는 그럴만한 이유가 있다고 믿는다.

2. 내가 바꿀 수 없는 것은 고민하지 않는다.

3. 객관적인 사실을 확인하고 결정한다.

이라한 것들이 흥분하지 않는, 기분의 동요가 적은 나를 만든다고 생각한다.

위에 언급한 번호 하나하나에 대해서 다른 블로그에서 자세하게 쓰겠다. 안그러면 블로그가 너무 길어질 것 같다.

2015년 5월 25일 월요일

delacourt at a glance 만들면서...

최근에 취미 코딩으로 회사 지하식당의 메뉴를 좀 더 보기 좋게 제공하는 사이트를 만들었다. 이걸 만들면서 경험한 내용을 블로그로 남겨놓는다. 아마도 내용이 제법 길어질 수 있을므로 여러개의 블로그로 올릴 것 같다.

1.
처음에는 생각만 했었다. 지하1층 메뉴와 지하2층 메뉴를 한 페이지에서 확인 할 수 없고, 한번씩 링크를 눌러서 2개의 페이지에서 메뉴를 확인한다는게 좀 불편했었다. 아~ 좀 불편하네~ 좀 길어져도 한 페이지에 해 놓으면 페이지 전환없이 편하게 볼텐데...

2.
전혀 상관없는 계기로 웹페이지를 긁어서 원하는 데이터를 뽑아내고 원하는 형식으로 표시하는 작업을 2번 정도 진행했다. 첫번째는 로컬시스템의 html파일에서 JQuery의 ajax를 이용해서 작업했고, 두번째는 nodejs로 만든 서버를 AWS에 띄워서 request로 호출하고, 결과 html 문자열은 cheerio로 파싱해서 작업했다. 더 상세한 내용은 다른 블로그에서....

3.
비슷한 작업을 2번정도 연습하고, 그 와중에 AWS에 서버도 셋팅을 하고 나니, 식당 메뉴를 보기 좋게 만드는 작업을 해보고 싶어졌다.

4.
소스는 GitHub에 올렸다. 서버는 AWS를 쓰기로 했다. 자바스크립트로 nodejs로 구현해서 별도 웹서버는 필요없었다. 도메인은 생각하지 않고 시작했는데, 결국 여기에서 kr.pe의 서브도메인을 무료로 받았다.

5.
단순히 서버를 하나 띄워서 사용자의 요청이 들어올 때마다 공식홈페이지에서 데이터를 가져와서 뿌리기로 했다. 접속주소도 루트로 들어올때만 준비한 페이지를 보여주게 하고 그 외의 주소는 아무 표시없이 무시했다.

2개 페이지의 결과를 합쳐서 응답해야 해서, async라는 모듈을 사용했다. html template을 쉽게 만들기 위해 swig도 썼다. 위에서도 언급했지만, html 파싱은 cheerio를 썼다.

6.
하루 정도 서비스를 해보니까 하루에 몇명이나 들어올까가 궁금해졌다. 좀 찾아보니 구글 어날리틱스가 있어서 출근길에 붙였다. 하루종일 통계가 안나와서 답답했는데 하루가 지나니 자 나온다.

7.
빌드를 자동화해야 할 것 같아서 travis를 붙이긴 했는데, travis에서 실제로 AWS 서버에 배포하는 것 까지 붙이진 않았다. 대신 AWS 콘솔에서 사용할 작은 shell 프로그램만 하나 만들었다. nodejs 프로세스를 죽이고(kill), git pull 한다음 nohup으로 실행하는 것 까지 한다.

8.
공식홈페이지에서 제공하던 기능은 다 포함했기에 GitHub에서 1.0.0으로 릴리즈를 했다. 현재 버전이기도 하다. 현재 버전에 포함되지 않은 기능들은 GitHub의 Issue로 등록했다. 앞으로는 Issue 기반으로 작업할 생각이다.

여기까지가 큰 흐름이고, 자세한 내용은 번호마다 다른 블로그에서 더 자세하게 다루겠다.

2015년 5월 21일 목요일

java feature toggle

프로그램이 가지고 있는 특정 기능을 상황에 따라서 켜고 끄는 기능이 필요하다. 구글링을 조금 해보니 이런 걸 feature toggle이라고 하는 듯 하다. 지금 개발중인 시스템에서 이런 기능이 자주 필요해졌고, 이번에도 나 혼자 이런게 필요한 건 아니겠지라는 생각에 구글링을 시작.

1.
feature toggle의 구글링 첫번째 결과는 마틴 파울러의 블로그이다. 글 중반에 feature toggle의 유형을 다시 2가지로 나눈다. release toggle과 business toggle이다.

release toggle은 새로 개발된 기능을 일부 적용하고 손쉽게 되돌릴 수 있게 릴리즈하는 장치이다. 이건 내가 찾던 것은 아니다. 새로운 기능이 안정적으로 안착되면 toggle을 지우라고 권장하고 있다. 이게 시간이 지나면 Technical dept이 된단다.

business toggle이 내가 필요한 유형이라고 할 수 있겠다. 프로그램 runtime 시점에 특정 기능을 적용하거나 적용된 기능을 제외시키는 기능이고, 이게 관리자 역할의 사용자에게 권한이 부여되서 직접 시스템의 기능을 제어할 수 있어야 한다. (오피스 프로그램의 옵션처럼)

2.
feature toggle java로 검색해봤다. 이 기능을 쉽게 구현하게 도와주는 프레임웍들을 모아놓은 페이지가 있다. 4개의 프레임웍에 대한 링크가 존재하고, 구글링 검색결과와도 대략 일치한다. 이것들만 검토해보고 1개를 선택하거나, 직접 구현하는 경우에 대비해서 insight를 얻을 수 있을 것 같다.

3. Togglz
http://www.togglz.org/ 구글링 검색에서도 처음으로 링크되어 있고, 문서화도 잘 되어있고, 기능도 많다. 2014년 12월이 마지막 릴리즈이니까 죽은 상태도 아닌 듯. ENUM을 활용하고, enable/disable 개념과 active/inactive 개념을 가지고 있다. enable이어도 user나 time등의 기준에 의해서 inactive한 상태도 제어가 가능하다. admin기능을 자체적으로 web view와 함께 제공한다. feature들을 memory/file/DB에서 관리가 가능한데, DB는 테이블을 알아서 만들어서 사용하는 듯.

4. FF4J
http://ff4j.org/ 최근 한달전까지 커밋이 있었다. PDF로 된 문서는 잘 작성되어 있는데, 막판에 DB쪽이 나오면서 미작성된 부분이 있다. FeatureStore를 직접 구현하면 DB로도 가능할 듯. feature을 String으로 지칭한다. 설정없이 초기화하여 동적으로 feature를 추가할 수 있다.

5. Fitchy
https://github.com/akomtur/fitchy 프러퍼티 파일 기반이고 특정 interface를 구현한 클래스에 toggle이 필요한 메서드에 annotation을 달아서 특정값 또는 null을 리턴하도록 하는 구성이다. 리턴이 boolean이 아니고 Object가 가능하다는 게 특징인 듯. 마지막 커밋이 2년전인데, 실제 소스는 3년 전인 듯.

6. Flip
https://github.com/tacitknowledge/flip 3년전이 마지막 커밋이고 문서화도 부족함.

7.
기존 프레임웍들을 보면 xml이나 DB에서 feature 기본값을 읽어서 ENUM이나 Proxy Interface로 On/Off를 체크하는 방식을 모두 사용하고 있다. 그리고 Web Page를 통해서 그 값들을 변경가능하게 만들었다. 현재 개발중인 시스템에 구현한 내용도 동일하다. 굳이 추가적인 프레임웍을 붙여서 구현할 필요는 없을 듯.

8.
feature가 추가되면
-> DB에 행 추가
-> 관련VO에 member field, getter/setter 추가
-> Util의 메서드 추가
-> js object에 property 추가
이런 식으로 진행이 될 것 같다.


2015년 5월 11일 월요일

솔루션의 git branch 전략

지금 진행하고 있는 솔루션에서 갑작스럽게 git을 적용하다보니 branch를 어떻게 운영해야 할지에 대해서 막막했는데, 여러 자료들을 보면서 나름의 branch 전략을 세우려고 한다.

당연히 누군가는 이런 고민을 했겠지라는 생각으로 구글링을 시작.

1.
A successful Git branching model 번역 이게 제일 유명한 포스팅인 듯 하다. 특별한 이름은 없고 대부분 "성공적인 모델"이라고 지칭하는 듯. 길지 않은 글이지만, 한글로 짧게 요약한 글도 있다. 이게 더 잘 요약한 것 같다. 이 전략을 기반으로 gitflow라는 것도 누가 만들었다. 그리고 적용후기 (한글)

2.
branch 전략은 아니지만 분산 저장소들을 어떻게 관리할지에 대해서 그림으로 설명한 글도 있다. 같은 블로그에서 비공개 소규모 팀 운영을 위한 예제 시나리오도 읽어볼 만 하다.

이제 회사업무에 적용할 생각을 해보면...

3.
사내 ALM시스템을 사용하면 자연스럽게 1번에서 언급한 "성공적인 모델"을 사용하게 된다. master, develpoment, release-*, feature-* 까지는 그대로 사용하고, hotfix-*만 bugfix-*라는 prefix를 사용하게 된다. 아마도 master에서만 가져오는게 아니라 development나 release-*에서도 가져올 수 있는 구조이므로 일부러 이름을 다르게 잡은 것 같다.

4.
우리 솔루션만의 문제가 더 있다. 솔루션이 고객사 시스템에 설치되는 구축형이다 보니 고객사마다 릴리즈된 버전을 관리할 필요가 있다. 아직 버전에 대한 경험이 없어서 특정 시점의 소스형상으로 설치가 된다. 그 시점의 소스형상을 "고객사A" branch로 만든다. 고객사가늘어날 때마다 만들어지는 branch인데, 고객사가 많아지기 전에 고객사에 "특정 시점의 소스형상"이 아니라 "특정 버전의 소스형상"을 릴리즈하는 형태가 만들어져야 할 것 같다.

5.
팀내의 퍼블리셔가 만드는 이미지 파일과 HTML소스는 "publish" branch에서 관리된다. 언듯 생각하면 퍼블리셔에게 퍼블리싱하는 대상 기능에 맞는 feature-*에 commit하라고 하면 될 것 같지만, 그렇게 하지 못 하는 이유가 있다. 이미지 파일의 경우 여러 이미지를 합쳐서 하나의 이미지로 만들고 잘라서 쓰는 경우가 있고, css 파일도 하나의 파일에서 모든 css를 관리하고 있기 때문이다. 즉, branch를 나눠서 얻는 이점보다 merge할때 생기는 conflict를 해결하는 게 더 힘들어질 것으로 예상했다. 게다가 퍼블리셔 입장에서도 여기 저기 feature-*를 변경하면서 개발하는 것은 너무 번거롭다.

6.
결국 지속적으로 관리되어야 하는 branch가 4개가 된다. master, "고객사A", developement, publish. 
"고객사A" branch는 버전관리를 잘 해서 특정 버전 branch가 되도록 유도하여 결국에는 branch자체를 없에야 겠다. publish는 그냥 두고 진행한다. 퍼블리싱 대상 소스만를 위한 devleopment처럼 개념을 잡고 수시로 development쪽으로 merge를 수행하도록 해야 겠다.

7.
ALM에 bug가 등록되면 hotfix인지 여부를 제품책임자와 개발리더가 판단하여 branch를 hotfix면 master에서, 그렇지 않으면 development에서 가져오도록 해야 겠다. hotfix인 경우, 사내 ALM시스템에서 새로운 patch version을 생성해서 릴리즈 절차를 진행할 수 있도록 해야겠다. (그런 의도의 기능이라면) patch version의 bug에서 branch를 생성할 때 기본적으로 master에서 가져오는지 확인해야 한다. [TODO]

8.
6번과 7번처럼 정리가 되면 한번 사용한 branch들은 "성공적인 모델"에서 언급한 것 처럼 merge된 직후에 삭제되어도 된다. merge request를 개발리더가 accept한 직후에 삭제해버리면 될 듯. git remote repo에서 삭제한 branch를 이클립스 eGit에서 pull할때 자동으로 삭제되도록 개발자로컬환경 셋팅이 필요하다. 그래야 없어진 branch에서 개발하는 실수를 막을 수 있을 듯 하다. 이렇게 eGit의 버전을 올리고 prune 옵션을 설정해서 해결하면 된다.

3줄정리
- branch 전략은 "성공적인 모델"을 따른다.
- "고객사A" branch는 특정 version의 branch로 대체한다.
- publish는 상시 유지하고 수시로 development에 merge한다.

회사업무 중 문제해결 시나리오 정리 시작~

회사업무를 진행하면서 만나게 되는 문제들을 블로그로 정리하려고 한다. 어떤 문제들이 있는지, 어떤 과정을 거쳐서 해결책을 찾아내는지, 최종 선택은 무엇이고 그 근거는 무엇인지를 정리할 예정.