http://subokim.wordpress.com/2013/01/23/it-project-feature/

IT 프로젝트 종류와 특징

“IT프로젝트 is not 빔프로젝트”
Joke 입니다. (_ _)

IT에 입문하는 사회 초년생의 눈에 소프트웨어 개발이라는 것이 비슷해 보입니다.
하지만, 각 산업분야별로 그 프로젝트 특성들이 모두 다릅니다.
처음에 잘못된 길로 들어왔다가 적성에 맞지 않다고 소프트웨어 개발을 포기하지 않았으면 하는 마음에, 특징들을 모아서 정리해보았습니다.
궁금해하시는 분들께 참고가 되었으면 좋겠습니다.

혹시 제가 잘못 알고 있거나 첨언을 해주실 내용이 있으면 댓글을 부탁드립니다. (좀 오래된 경험도 있어서. 긁적)

그리고, 한 분야을 하다가 다른 분야로 넘어가는 것은 굉장한 도전이 됩니다.
IT를 천직으로 생각하시는 분이 있다면, 충분한 시간과 계획을 가지고 다양한 도전을 해보시길 권하고 싶습니다.(물론 한 분야를 깊이 파는 것도 좋습니다.)

---

1. 은행 프로젝트
검증된 기술만 쓴다. 기술보다는 업무처리가 중요하다. 검증되지 않은 새로운 기술을 이야기 하면 바보취급 당한다. ‘한 번 해봅시다.’ 식의 접근은 거의 없다.
기본이 안정성이다. 대부분 24시간 365시간 무중단 운용성은 기본이다.
레거시를 걷어낼 수 없다. 레거시를 두고 가능한 좋은 성능과 결과를 낼 수 있어야 한다.
코드가 깔끔해야 한다. 언제나 유지보수할 수 있어야 한다. 만료된 서비스는 적시에 종료되어야 한다.

새로운 기술은 쓰지 않지만, 여러 기술분야의 체계성을 배우기 좋은 곳이다.

2. 보험사 프로젝트
업무요건들이 대부분 10년이상 장기 상품들이다. 삼성생명 ‘종신보험’과 신한생명 ‘종신보험’은 같으나 다르다.
재개발 수준의 고도화는 거의 없다. 대부분 덧붙이기 식으로 개발한다. 종료되고 폐기되는 상품은 거의 없다. 상품특성이 비슷해서 소스코드 재활용률이 높다. 하지만, 똑같지 않으므로 모듈레벨의 재활용은 거의 없다.
업무 전문성이 높은 개발자를 우대한다. 기존 소스코드가 자산이 된다.
트렌디한 기술을 사용하는 경우는 많지 않다.

금융업무에 관심이 많은 개발자라면 해볼만 한다.

3. 공공부문 프로젝트
전국 데이터는 기본이다. 규정(보안 등)을 준수하는 개발이 중요하다.
재기발랄하고 창의적인 분야는 거의 없다. 트렌디하지 않다. 공공의 편의성이 우선이다.
법제도가 바뀌거나, 규제가 늘거나 하는 등에 의해 유지보수가 발생한다.
큰 정부정책이 내려오면 대부분 큰 시스템의 개발이나 고도화가 동반된다.
큰 고도화의 경우 대부분 재개발이다. 깔끔한 개발보다는 일정준수가 중요하다. (대부분 제도 시행과 맞물려 일정이 잡힌다.)
기술보다는 업무목표 완성이 중요하다. 필요에 따라서 신기술도 자주 쓴다.

SI 프로젝트 중심이다. 기술습득이 빠르고, 여러가지 기술을 배우기에 좋다. 폭넓게 기술전반을 이해하기 좋다.

4. 이통사 내 부가서비스 프로젝트
24*365서비스가 기반이다. 레거시가 많다. 빌링과 인증 연동이 까다롭다. 대부분 연동을 많이 해야 한다. 클라이언트보다 대부분 서버 중심의 기술환경이다.
shut down되는 서비스는 거의 없다. 돈이 한 푼이라도 벌리면 살려둔다.
플랫폼형 서비스가 많은데 외부 CP등 제어할 수 없는 요인들이 많다. 당연히 예외처리가 많다. 상용반영하다가 장애나는 경우가 허다하다.
레거시가 오랫동안 살아있는 반면, 매뉴얼이 거의 없고 개발업체도 다양해서 유지보수하기 쉽지 않다. 작은 서비스를 계속 개발해서 런칭한다.
이통사 서비스는 오픈하면, 대부분 어느정도 트래픽을 확보한다.

서버 개발 기술(API, 연동, 통신 등)을 마스터하려면 이통사 프로젝트를 해보길 추천한다.
대용량 트랜잭션 처리의 경우도 많고, 현금이 실시간으로 흘러다니는 경우가 대부분이어서 긴장감이 매우 높은 편이다.

5. 이통사 레거시 프로젝트
회원관리, 빌링과 인증이다. 레거시를 걷어낼 수 없다.
오래된 코드의 경우 제대로된 유지보수 매뉴얼도 없는 경우가 많다. 덧붙이기식으로 개발한다. 폐기하기 힘들다. 정밀한 운영프로세스가 필요하다.
원복시나리오 없이 반영하지 않는다.
오래된 기술이 남아 있는 곳도 있다. 복잡도가 매우 높다.

큰 시스템을 경험하고 싶다면 한 번쯤 도전 해볼만 하다.

6. 웹포털 프로젝트
웹페이지 중심의 빠른 개발이 중요하다. 서버기술보다 프론트엔드 기술이 중요하다.
서비스가 끝나면 빠른 폐기도 중요하다. 웹기반 연동방식을 많이 쓴다. 트렌디하다.
정통적이고 무거운 개발환경보다 2 Tier 중심의 가벼운 개발환경을 선호한다.
특정기간에 치고 빠지는 개발을 많이 한다.
기술난이도가 높지 않다. 무료의 대용량 트래픽이 많기 때문에 라이센스 비용 등에 민감하다. 소스의 형상관리 등은 중요하지 않다. 빠른 속도의 오려붙이기식 개발을 한다.

웹서비스의 성공과 실패를 경험해보고 싶어하는 개발자들이 많이 지원한다.
현실적으로 포털이 네이버와 다음 밖에 남지 않아서, 입사하기 어렵기도 하다.

7. 스마트폰 앱기반 프로젝트
서버와 클라이언트로 나누어 개발한다. 서비스 피쳐를 기능으로 만들고, 서버와 클라이언트로 나누어 처리한다.
아직 인프라가 부족해서 이해해야할 기술의 폭이 넓고 다양하다.
기술 난이도가 높고 복잡도가 높은 반면, 빠른 개발속도가 필요해서 초급자가 도전하기 쉽지 않다. 복잡한 온라인형 서비스보다 단순한 단독형 앱서비스를 선호한다. 소규모 팀의 팀웍이 중요하다.
기술장벽을 극복하기 위해 REST API 등 기술트렌드 변화가 심한 분야이다.

새로운 기술을 배우고 싶어하는 개발자들이 도전해볼만 하다.
하지만, 베테랑이 충분한 팀을 선택하시길.

8. 폰게임 프로젝트
대작게임은 1년 정도의 개발이지만, 대부분 3개월 개발하고 출시하면 1개월 정도 팔린다.
빡세다. 빨리 개발해야 하므로 업무 체계성이 상대적으로 부족하다.
개발자 개인의 능력에 많이 좌우된다. 실패율도 높다. 출시 후 뜨더라도 6개월 가기 힘들다.
다작으로 승부하는 분야다. 체력 좋은 젊은 개발자 중심이다.
게임에 관심이 많은 개발자들이 도전한다.
온라인 게임보다는 단독형 게임이 대부분이라 클라이언트 개발이 대부분이다. 서버기술을 배울 기회가 많지 않다.

9. 대형 온라인 게임 프로젝트
기획도 좋아야 하고 개발도 체계적으로 해야 한다. 분업화하지 않으면 성공적으로 런칭하기도 힘들다. 돈이 많이 든다.
메인 게임에 Oracle, MySQL같은 RDB는 안쓴다. 빠른 ISAM DB(File DB)를 쓴다. (물론 회원정보 저장 등을 위해 쓰기도 한다.) 빠른 통신과 동접처리, 게임엔진 등이 중요하다.

폐인 기질이나 스스로 천재라고 생각하는 개발자라면 도전해볼만 한다.

10. 솔루션 프로젝트
스펙(규격)이 중요하다. 제품전략이 중요하고, 기능하나가 수익과 밀접하므로 기능 하나 쉽게 더하기 힘들다. 아름다운 설계가 중요하다.
완성도가 매우 중요하다. 최적화와 다양한 시험케이스가 매우 중요하다.
한번 출시되면, AS 하기 힘든 경우가 많기 때문이다.

완성도 높은 개발을 어떻게 하는지 알고 싶은 개발자라면 도전해볼만 한다.

11. ERP 프로젝트
회사마다 조금씩 다를 뿐 업무가 정형화되어 있다. ERP 패키지를 주로 사용한다.
기술적 도전이나 성취감은 낮다. 그러나, 회사라는 기업이 어떻게 돌아가는지 아주 잘 이해하게 된다.(현실적으로)

한 번 참여해보게 되면, 자기 회사를 할 때 매우 큰 도움이 된다. 또는, 전산실을 노린다면 도전해볼만 하다.

12. 학생들 프로젝트
학점이 중요하다. 기능이 구현되면 신기하다.
내 손으로 만든 것이 돌아간다는 게 놀라운 경험이다.

IT에 입문하고 싶어하는 사람이라면 반드시 한번은 거쳐야 한다.
동아리나, 커뮤니티에 들어서 많은 프로젝트를 해보길 바란다.

13. 기타
물류 프로젝트. 고생이라고 들었다. 소프트웨어는 그냥 수단이다. 개발서버가 별도로 없는 경우가 많다고 들었다.
병원 프로젝트. 모르겠다.