IT의 중심에서

나이 든 개발자가 살고 있는 IT 현장 이야기

IT 프로젝트 종류와 특징

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

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

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

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


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

새로운 기술은 쓰지 않지만, 여러 기술분야의 체계성을 배우기 좋다.
그래서 경력자를 선호한다.

2. 보험사 프로젝트
구현 업무가 대부분 10년이상 장기 상품들이다.
하지만, 삼성생명 ‘종신보험’과 신한생명 ‘종신보험’은 비슷하지만 다르다.
종료되고 폐기되는 상품은 거의 없다.
신상품은 과거 상품들을 조합 재배치 하는 경우가 많다. (금리, 보장, 약관 등)

상품특성이 비슷해서 소스코드 재활용률이 높다.
하지만, 똑같지 않으므로 모듈레벨의 재활용은 거의 없다.
대부분 덧붙이기 식으로 개발한다.

장기 상품이 많아서 재개발 수준의 고도화는 거의 없다.
업무 전문성이 높은 개발자를 우대한다. 기존 소스코드가 자산이 된다.
트렌디한 기술을 사용하는 경우는 많지 않다.

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

3. 공공부문 프로젝트
전국 데이터는 기본이다. 규정(보안 등)을 준수하는 개발이 중요하다.
재기발랄하고 창의적인 분야는 거의 없다. 트렌디하지 않다. 공공의 편의성이 우선이다.

법제도나 규제가 정기적으로 신설되므로 신규개발이 항시 발생한다.(국회, 내각개편 등)
큰 정부정책이 내려오면 대부분 큰 시스템의 개발이나 고도화가 동반된다.
시스템 신규 구축이 압도적으로 많다.

깔끔한 개발보다는 일정준수가 중요하다. (대부분 제도 시행과 맞물려 일정이 잡힌다.)
기술보다는 업무목표 완성이 중요하다. 필요에 따라서 신기술도 자주 쓴다.

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

4. 이통사 내 부가서비스 프로젝트
24*365서비스가 기본이다. 실제로 새벽 트래픽도 많다.
배포된 단말을 고칠 수 없기 때문에 대부분 서버 중심의 기술 환경이다.
레거시(기존 시스템)가 많아서 시스템 간 연동이 많다.
그래서 동일 개발언어를 선호한다.(Java Spring…)

나도 모르게 가입된 부가 서비스가 2~3년 간다.
폐기되는 서비스는 거의 없다. 월 500원이라도 들어오면 살려둔다.

기본적으로 인프라를 제공하는 플랫폼형 서비스다.
그래서 외부 업체를 통제할 수 없다. (완전 다른 회사이고, 개발자가 없는 회사도 있다.)
대부분 예외처리로 해결을 하는데, 상용반영하다가 장애나는 경우가 허다하다.
따라서, 상용반영, 장애 추적절차가 중요하다.
기능 장애와 데이터 장애까지 함께 봐야 한다.

레거시가 오랫동안 살아있는 반면, 매뉴얼이 거의 없고 개발업체도 다양해서 유지보수하기 쉽지 않다. 작은 서비스를 계속 개발해서 런칭한다.

서버 개발 기술(API, 연동, 통신 등)을 마스터하려면 이통사 프로젝트를 해보길 추천한다.
예측되지 않는 대량 트랜잭션 처리가 많고, 현금이 실시간으로 흘러 다녀서 긴장감이 높은 편이다.(미터링, 건당 과금 등)

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

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

6. 웹포털 프로젝트
고객 화면의 중요성이 크다. (안 예쁘거나 불편하면 안 온다.)
그래서 프론트엔드 기술이 중요하다.

서비스가 끝나면 빠른 폐기도 중요하다. (무료 서비스는 돈을 아껴야 하니까)
전통적이고 무거운 개발환경보다 2 Tier 중심의 가벼운 개발환경을 선호한다.
그래서 백엔드도 웹 기반 기술을 많이 쓴다.

트렌드를 따라가는 서비스가 많아서 빠른 오픈을 선호한다. (개발 3개월? 1주? 2주?)
그래서 기술 난이도가 높지 않고, 소스나 모듈의 재활용도가 높은 편이다.
오픈 후 고객 반응에 따라 변경 개발이 필수적으로 자주 발생된다.
따라서 튜닝,최적화보다 변경 유연성이 높은 레고블럭형 개발을 선호한다.

무료 대량 트래픽 서비스를 지향하기 때문에 라이센스 비용에 민감하다.
내부 개발과 변경 개발이 많기 때문에 소스관리의 중요성이 높아지고 있다.

웹서비스의 성공과 실패를 경험해보고 싶어하는 개발자들이 많이 지원한다.
현실적으로 포털이 네이버와 다음 밖에 남지 않아서, 입사하기 어렵기도 하다.
스타트업은 어려운 기술이 필요해지기 전에 망하는 경우가 많아서 공력을 높이기 힘들다.

7. 스마트폰 앱기반 프로젝트
서버와 클라이언트(앱)로 기술이 나뉜다.
그런데 하나의 기능을 나누어서 구현해야 한다.
그래서 이해해야 할 기술의 폭이 넓고 다양하고, 복잡하다.
반면, 빠른 개발속도가 필요해서 초급자가 도전하기 쉽지 않다.
소규모 팀의 팀웍이 중요하다.
기술장벽을 극복하기 위해 기술 트렌드 변화가 심하다.
초보자가 복잡한 온라인 앱을 구현하기는 어렵다.

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

8. 폰게임 프로젝트
대작게임은 1년 정도의 개발이지만, 대부분 3개월 개발 1개월 정도 반짝한다.
빡세다. 빨리 개발해야 하므로 업무 체계성이 상대적으로 부족하다.
개발자 개인의 능력에 많이 좌우된다.

실패율도 높다. 출시 후 뜨더라도 6개월 가기 힘들다.
다작으로 승부하는 분야다. 체력 좋은 젊은 개발자 중심이다.
게임에 관심이 많은 개발자들이어야 한다.

온라인 게임보다는 단독형 게임이 주류라 클라이언트 개발이 대부분이다. 서버기술을 배울 기회가 많지 않다.

9. 대형 온라인 게임 프로젝트
기획도 좋아야 하고 개발도 체계적으로 해야 한다.
분업화하지 않으면 성공적으로 런칭하기도 힘들다.
돈이 많이 든다.

메인 게임에 Oracle, MySQL같은 RDB는 안쓴다.
빠른 ISAM DB(File DB)를 쓴다.
물론 회원정보 등은 RDB.
빠른 통신과 동접처리, 게임엔진 등이 중요하다.

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

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

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

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

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

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

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

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

Advertisements

IT 프로젝트 종류와 특징”에 대한 11개의 댓글

  1. junee01
    2017년 4월 13일

    감사합니다!

    • subokim
      2017년 4월 13일

      별말씀을. 도움이 된다면 제가 더 감사합니다.

  2. 푸름
    2014년 2월 27일

    오~~ 이런 정리를.. 퍼갑니다.

답글 남기기

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

WordPress.com 로고

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

Twitter 사진

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

Facebook 사진

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

Google+ photo

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

%s에 연결하는 중

정보

이 엔트리는 2013년 1월 23일에 님이 IT 산업이야기에 게시하였으며 , , , , , , , , 태그가 지정되었습니다.

내비게이션

%d 블로거가 이것을 좋아합니다: