논의해 볼만한 재미있는 주제이네.. 세부 내용들은 나도 좀 더 고민한 후에 다시 한번 정리할께.

이 주제도 재미있지만 상품화를 위한 서비스 환경을 어느 시점부터 고민하고 준비하는 것이 좋을 것인가에 대해서도 같이 한번 이야기해 보면 재미있겠다. 물론 빠르면 빠를수록 좋다는 의견이 많이 나올 수도 있겠지만 그로 인한 단점도 많을테니..

@자바지기 ^^ 네. 좋든 싫든 지금 회사에서 기획부터 상품화하여 납품하는 과정을 경험해본 건 나쁘지 않았습니다. ㅎ 문제는.. ㅡ_-);; 윗선이 다 나가서 정리하고 말고할 시간이 없네요. 우흠.

@김지헌 오늘 오후에 정신 없이 많은 회의를 하느라 정리하지 못했는데 퇴근하고 한번 정리해본다. 잘 정리가 되려나 모르겠지만 지금 생각나는 부분들만 먼저 공유해본다. 빠진 부분 있으면 지헌이나 다른 사람들이 공유해 주리라 생각한다.

실 서비스에 배포하기 전에 개발자 로컬 PC와 개발 서버의 개발 환경이 다르기 때문에 로컬 PC와 개발 서버의 환경 설정 파일을 분리해서 빌드할 수 있는 환경을 반드시 마련해야 한다. 이 환경만 잘 만들어 놓아도 실 서비스 환경으로 갈아타는데 많은 수고를 덜 수 있다. 예를 들어 내가 쓴 메이븐 책에서 Profile별로 설정 파일을 나누어 관리할 수 있는 부분이 필요하다.

src/main/resources-development : 로컬 PC src/main/resources-integration : 개발 서버

일단 위와 같이 개발자 PC와 개발 서버와 같이 개발 환경별로 설정 파일을 분리할 수 있는 환경이 필요하다. 한 개에서 두 개로 분리하는 것이 어렵지 두 개에서 세 개로 분리하는 것은 생각보다 쉽고 많은 시간이 소요되지 않는다.

일단 위와 같이 분리된 환경이라고 가정하고 실 서비스를 하는 시점에 고려해야 하는 요소들을 살펴보면 다음과 같지 않을까 생각한다.

• ORM을 쓰고 있다면 create나 update 설정을 반드시 validate로 변경. 이 부분은 실서비스 바로 직전에 해도 괜찮음.
• 데이터베이스 스키마를 관리할 수 있는 기능 추가. carbon5와 같이.. 이 부분은 연습이 필요한 부분이기 때문에 실서비스하기 몇 주 전에 적용해서 연습하는 것이 좋겠음
• logging 프레임워크 설정 파일의 log level을 debug에서 info와 같은 형태로 변경한다.
• 데이터베이서 Connection Size 고려해야 한다.
• 캐시를 사용한다면 캐시 설정도 개발과 실서버가 달라야 한다. 개발 단계에서는 캐시 설정은 0이어야 한다.
• 도메인도 개발 서버와 실 서버를 분리해서 관리하는 것이 좋다. 예를 들어 로컬 PC는 local.slipp.net, 개발 서버는 dev.slipp.net, 실 서버는 www.slipp.net. 특히 도메인이 많아질 경우에는 반드시 필요하다. 매번 host 설정 변경하기 힘들고 장애날 가능성이 높다.
• web server(nginx)나 web application server(tomcat과 같은)의 thread count 등에 대한 설정을 고려해야 한다.
• 기존 개발 단계에서는 개발 서버에 빌드와 배포를 같이한다. 하지만 실 서비스의 경우에는 빌드 서버와 배포 서버가 달라지는 경우가 많다. 따라서 여러 대의 서버에 배포를 할 수 있는 자동화된 배포 스크립트가 필요하다. 현재 내가 진행하는 프로젝트에서 배포는 Capistrano 활용하고 있다. 특히 load balancing을 한다면 이 부분이 특히 중요할 것으로 생각한다. 할 수 있는 범위 내에서 최대한 자동화를 하고 자동화하지 못한 부분은 일단 서비스를 오픈한 이후에 지속적으로 자동화할 수 있도록 한다.

위 내용 이외에도 프로젝트 환경에 따라 고려해야할 부분이 많을텐데 각 개발 환경별로 설정을 분리할 수 있는 기반만 잘 마련해 놓는다면 실 서비스할 때 어렵지 않게 설정을 분리해서 관리할 수 있다. 실서비스는 점검을 걸고 여러 대의 서버에 배포를 자동화할 수 있는 기반을 마련하는 것이 무엇보다 중요하다고 생각한다. 또한 데이터베이스에 대한 스키마 관리도 개발 단계와는 달리 drop table이 아닌 alter table을 통해 지속적으로 리팩토링해 나갈 수 있는 연습이 무엇보다 중요하다고 생각한다. 이외에도 많은 고려사항이 있겠지만 일단 여기까지 정리하고 패스..나머지는 다른 친구들이 추가해 주리라 믿는다.

@박재성 @김지헌 기획 -> 상품화 -> 납품 이라는 과정을 들어 보니, 서비스 라기 보다는 솔루션 쪽에 가까운 느낌이네요.

@박재성 형이 말씀하신 과정은 서비스/솔루션과 상관 없이 중요한 부분이라고 보입니다.

솔루션 만을 놓고 본다면, 추가되는 고려 사항 들이 생기겠네요.

버전 관리

# 기본적으로, 자체 운영 서비스와 타 업체에 판매하는 솔루션이 달라지는 부분은 버전 관리 입니다.

# 자체 서비스는 한벌의 소스 코드로 지속적으로 운영이 가능하지만, 타 업체에 납품하는 솔루션은 그렇게 하기 어렵죠

# 사업 진행 상황에 따라, 예를들어 10개 업체에 솔루션 납품을 했다면 소스코드가 10벌이 되는 상황이 벌어집니다.

# 따라서, 솔루션 납품 상황에 따라 달라질 수 있는 파일들 (ex: asset 이라고 부르는 static 파일들)에 대한 별도의 관리 규칙이 필요합니다.

# 게다가, 말 안듣는 영업들이 개별 업체 별로 미묘하게 다른 기능들을 추가해 달라고 하면 아에 다른 소스코드가 되어 버리죠

# 버전 관리 정책에 branch / tag 등을 활발하게 사용해야 하고, 개별 납품처에 따라 달라질 수 있는 부분들은 전부 별도의 저장소로 관리하는 정책이 필요합니다.

배포 정책

# 솔루션 배포는 서비스 배포와 미묘하게 다른 부분이 생깁니다.

# 대표적으로, 예를 들어 10개 업체에 솔루션 납품을 했다면, 계약 관계에 따라 직접 배포를 할 수도 있고, 해당 업체에 바이너리 전달 형태로 배포가 이뤄질 수도 있습니다.

# 이전에 이야기 했듯, 개별 납품처에 따라 다른 기능이 추가 되었다면, 해당 부분도 역시 따로 관리되어야 하겠지요.

# 직접 배포 / 바이너리 전달 / 소스 전달 등의 상황을 미리 산정하고, 해당 부분에 대한 배포 정책을 별도로 만들어야 합니다.

# 직접 배포시에는 DB 스키마 변경등에 대한 관리도 직접 가능하겠지만, 바이너리 전달이나 소스 전달의 경우 고객사에 시스템 업데이트 방법에 대해 상세하게 전달하지 않으면 소송의 대상이 될 수 있습니다.

정상적으로 만들어진 서비스라면, 버전 관리 정책과 배포 정책이 적절하게 정의되어 있다면 솔루션 판매에 큰 문제는 없을 것입니다.

단지, 일반적으로 고객사에서 원하는 기능을 개별 구현해야 하는 경우가 많기 때문에, 이에 대한 관리 경험 여부는 실제 솔루션 판매시에 심각한 타격을 가져올 수 있습니다.

이 부분은 전체 사업적인 관점에서 다뤄져야 할 듯 하네요.