최근 달라진 나의 아키텍쳐

Facebook Server Side Architecture Group #SSAG

최근 변화된 나의 프로젝트 환경을 보면 “웹 어플리케이션 프로젝트” 보다 “데몬형태의 프로젝트”를 더 많이
생성하고 있다.

이러한 이유는 기존에는 “비즈니스 Flow”가 웹 어플리케이션의 컴포넌트로써 존재를 했지만

최근에는 “비지니스 Flow” 가 서버 to 서버로써 구성이 되어 가고 있다.

“웹 어플”은 단지 노출용으로 사용 되어지는 느낌.. 그러다 보니
light 하게 구성을 하는 것 같다.

개인적으로 이런 성향의 프로젝트들을 해서 그렇긴 해서 일반화 하긴
힘들지만.. 모든 서버를 다
“웹 어플리케이션”으로 구성해야
하는지 곰곰히 생각할 필요가 있을듯
싶다..

또한 얼마전 “최진호”님 과 얘기 했듯이 “앞으로 플랫폼 사이즈”의 플젝이
많이 나오지 않을 것에 대해서 공감한다.

예전엔 작게는 몇십억에서 크게는 몇백억을 투자해서 많은 개발자,
많은 어플리케이션, 일정이 긴 프로젝트들을 많이 했었다..

소위 “플랫폼” 프로젝트들…
크게 만들어서 크게 먹을수 있었기
때문에..

때론 수익성이 떨어져도 마이너스는
아니기 때문에 그래도 “플랫폼” 이었다..

하지만 지금 상황이 많이 달라졌다..
크게 만들어서 성공을 장담 할수가
없다..

엄청난 물량(개발자, 일정, 비용,마케딩)를 쏟아도 과연 성공을 할수 있을까…?

이건 마치 공중파 시청률 하락과
매우 흡사하다..

더 이상 고객은 “브렌드”, “마켓팅”에
흔들리지 않고, 좋으면 좋은거다..
케이블 TV라도..

그러다보니 예전 보다
작게, 빨리 고객에게 먼저 보여주고,
추후 잘 되면 크게 고도화 방향으로
가려는 것 같다.

그러다 보니 “스타트업”을 하는 느낌이 든다.

그래서 나의 아키텍쳐링도 시대의
흐름에 조금씩 바뀌고 있다.

예전에는 견고함, 표준화, 획일화등
오와열이 정확한 각진 엔터프라이즈
모델을 준수 했다.

이것이 오버 엔지니어링이라고 생각
하지 않는다. 나름 괜찮다고 생각한다. 큰 플랫폼에서는 쿨한것 보다
규범이 더 중요하기 때문에..

하지만 작은 사이즈에서는 이런 모델이 정작 배보다 배꼽이 더 클수 있다.

그래서 최근에는 상당히 군살을 빼고, Rapid 하게 아키텍쳐링을 한다.

예를 들어서 예전에는 5개 프로젝트를 만들었다면 지금은 한개의 프로젝트로 환경변수에 따라 5개의 프로젝트로 변화할수 있도록..

또한 개발 레퍼런스 문서도 정말 필요한 것들만 기술 하도록..

이런것들이 더 쉬울수 있다고 하지만
사실 추후 고도화를 고려하면서 rapid한 아키텍쳐링은 쉽지 않다.
많은 경험이 필요하고, 틈틈히
테스트도 많이 해야 한다.

또한 요새는 업무 설계보다 기술에 대한 요구 사항이 늘어 나고 있다.

정책서, 요구사항 정의 보다 기술관련 자료를 보고, 근무시간에 틈틈히
스터디를 할정도니..

목소리는 좋지만 “올드한 보이스”는
시장에서 외면 당하니..
“항상 현 시대를 반영하는 보이스”를
갖는 노력하는 개발자가 되어야 할것
같다.

항상 2~3년 주기로 아키텍쳐의
큰 변화를 겪는데.. 지금이 그 시기가 아닌가 곰곰히 생각 한다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중