[개발] 개발을 하면서 알아둬야 할 것들 (SI, SM프로젝트, 프리랜서 개발자) ver 2.0

 예전에 작성한 내용의 글에서 시간이 흐르면서 조금씩 변경되거나 추가된 내용에 대해서 다시 정리하는 시간을 가졌습니다. 프리랜서 IT 개발자, 웹개발, 모바일 프로그래머들에게 도움이 되기를 바랍니다. 지극히 개인적이고. 객관적인 내용이므로 대다수가 공감하거나, 무조건 내용이 옳다는 것은 아닙니다 긴 시간을 통해 경험 한 내용에 대해서 공유드립니다.

 

 

 

 

목차

 

 

---

개발을 하면서 알아둬야 할 것들 (SI, SM프로젝트, 프리랜서 개발자)  ver 2.0

 먼저 이전에 작성한 내용에 대해서 링크를 첨부드립니다. 포스팅한 내용에 대해서 너무 과거이므로, 현 상황이나 트렌드에 맞지 않는 내용에 대해서 업데이트하는 위주로 글을 작성하려고 합니다. 

https://junibugi.tistory.com/15

[개발] 개발 일을 하면서 알아둬야 할 것들(SI 프로젝트, 프리렌서 개발자) ver 1.0

 

---

1. 용어정리 

 

- 운영서버 : 실제 고객, 고객사 회사원 또는 사용자들이 사용하는 실제 서버를 말합니다. (오픈 후 실 운영되는 서버)

- 스테이지 서버 or 품질 서버(검증서버 등등): 회사마다 있고 없는 곳도 있는데, 운영 반영전 최종적으로 체크하는 서버를 말하고, 보통 DB를 운영서버 쪽을 사용하고 화면만 개발된 것 적용하여 테스트하는 경우가 많습니다. 용어는 조금 다를 수도 있습니다. 운영에 반영 전에 개발서버에서 테스트 한 내용을 품질 서버에 반영해서 통합테스트를 진행하는 경우가 많습니다.

-개발서버 :로컬에서 개발된 것을 테스트하는 용도의 서버, 보통 운영환경과 동일하게 만들어 놓습니다. 하지만, API 통신 또는 EAI 등 최근에 외부의 REST FULL api를 사용하면서 개발 서버에서는 실제 테스트가 불가하거나, 품질기로 소스를 올려서 테스트하는 경우도 있습니다. 예를 들어 카카오 알림톡 서비스를 개발하여 테스트를 할 때, 메일 데몬 또는 메일 솔루션에서 메일 발송 테스트를 할 때, 전자계약 또는 전자사인 솔루션 등등의 기능에서 개발 서버까지 통신테스트를 구축하는 곳도 있지만, 비용적인 문제로, 품질 및 운영서버에만 반영하는 경우가 존재하므로, 실제 테스트는 품질 서버에서 진행하는 경우도 있습니다.

- 형상관리 GIT 또는 SVN: 소스의 형상관리를 담당하는 형상관리 툴로서 예전에는 SVN을 많이 사용 했으며, 최근에는 GIT을 사용하고, 해당기능에 대해서는 업무를 진행하면서 익히거나 미리 공부를 조금 해 두는 편이 편합니다. GIT의 브렌치 전략이 프로젝트마다 상이하고 제각각이라 그에 맞춰서 대응하는 것이 중요하고, 소스의 충돌 등에 머지처리를 하는 부분이 익숙하면 도움이 됩니다.

---

 

2. 투입 및 환경세팅

 

  개발 포지션에 따라 투입기간은 차이가 납니다. 하지만, 환경 셋팅은 거의 동일하게 이루어지고 있습니다. 이전 글에서 처럼 개발자가 알아서 세팅하는 경우인 방치형이 있고, 개발세팅 가이드 문서를 제공해 주면서 환경 세팅을 조금 더 편하게 하는 곳이 존재하기 때문에 이것 또한 그에 맞춰서 대응하면 되고, 앞서 투입된 분들에게 많이 물어보고 세팅하는 게 도움이 됩니다. 잘 모르는 부분에 대해서 이것저것 알아보면서 시간을 허비하는 일은 줄이는 게 옳겠죠...

 개발 포지션은 보통 기획자, 분석 설계자, 개발자 등으로 나뉘는데, 프로젝트 기간에 따라 보통 기획 설계가 먼저 투입되고, 설계가 마무리 되는 시기에 맞춰서 개발자를 투입하는 곳도 있으며, 해당하는 프로젝트의 상황과 개발 일정에 따라 투입 인원은 유동적인 경우가 많습니다. 

 개발서버(또는 파일 서버 NAS)등에서 업무에 필요한 개발 일정이나 이슈를 확인할 수 있는 경우도 많고, 최근에는 JIRA, 노션, Confluence 등으로 개발에 필요한 정보를 정리 및 일정관리 진행 또는 해당 이슈를 관리하는 협업 툴을 사용하는 경우도 많습니다. 어려운 부분은 아니므로 업무 프로젝트에 따라 대응하면 됩니다. 

- 전체적인 개발 일정(WBS) 관련해서는 당연히 알려줄 테지만 알려주지 않는다 해도 어느 정도는 알고 있는 게 좋습니다.
(보통은 분석/설계 일정, 개발 일정, 단위 테스트 일정, 통합 테스트 일정, 오픈 일정, 안정화 일정 이렇게 나뉘는 경우가 있고, 개발 규모가 크다면 1차 오픈, 2차 오픈처럼 분할 오픈하는 프로젝트도 있습니다.)

---

 

3. 구현 및 개발진행 

 

  일정에 맞춰서 개발을 진행. 구현 단계 전에 설계 기획자와 많은 얘기를 통해서 정확하게 개발 범위와 구현 요건에 대해서 파악하는 것이 중요합니다. (개발 일정을 진행하면서 해당 부분에 대해서는 개발 요구사항이 자주 변경되는 경우도 있고, 그에 맞춰 일정이 늘어나거나, 미뤄지는 경우도 많으므로 히스토리를 잘 알고 개발 이슈에 대해서 관리를 잘하는 것 또한 중요합니다.)

 개발에 필요한 스킬이나 기술에 대해서는 본인의 업무 파악 능력과 스킬, 개발경험에 따라 많은 차이가 나므로 해당 내용에 대해서는 열심히 노력하는 방법 말고는 왕도가 없습니다. 하지만, 프로젝트 진행에 대해 큰 틀을 안다면(설계-> 구현 -> 검증 및 테스트 후 오픈 등) 해당 일정의 시기에 따라 필요한 부분에 대해 파악할 수 있지 않을까 싶습니다. 

- 보통 저 같은 경우엔 하루 단위로 개발 및 작업한 내역을 정리해서 작성해 놓는데요.. 일정관리 차원(일일 업무 보고 하는 곳이 가끔 있는데 이건 보통 프로젝트 일정 및 상황이 매우 안 좋을 때 요구합니다.)

- 주석은 열심히 적어두는 것이 좋습니다.. 귀찮아서 안 할 경우 다음에 내가 봐도 뭔지 모를 경우 생김(주석 다는 양식이 프로젝트를 하는 회사마다 틀린데 양식에 맞춰 달아 주면 됩니다.)

 최근에는 단순히 웹개발 뿐만아니라 모바일 쪽 개발범위도 확대되고, 업무에 따라서 api나 인터페이스, 배치개발, 메일 또는 알림톡, 문자 전송 서비스, 또는 리포트 등의 다양한 업무 파트가 있으므로 해당 요구사항에 맞는 스킬을 공부하고 자기 것으로 만드는 것 또한 중요합니다.

 

4. 검증 및 개발테스트 (단위, 통합테스트) 

 

- 단위 테스트/통합 테스트 기간을 길게 잡을수록 보통 여유로운 프로젝트입니다. (테스트 기간이 짧을수록 헬일 경우가 많았어요)

- 외부와 연계 테스트를 하는 경우도 많은데, 해당 부분의 일정을 잘 파악해야 합니다. 외부 테스트 진행에 필요한 사항 또는 이슈사항에 대해서는 잘 공유하고 진행해야 나중에 문제가 없습니다. 해당 문제로 일정을 다시 조율하거나 다시 테스트 및 보완을 하는 경우가 많으므로 좀 우선순위에 두는 것이 좋습니다.  

- 단위 테스트는 보통 개발자들과 현업 유지보수/운영 인력이 같이 테스트하는 단계 (테스트 결과 나오면 바로바로 수정해 주는 것이 좋아요)

- 통합 테스트는 보통 현업(실제 사용자)에서 테스트하는 단계(실제 사용자이기 때문에 다양한 케이스로 테스트합니다. 마찬가지로 문제점 바로바로 수정해 주는 것이 좋아요, 이때 앞서 말한 주석이 효과를 봅니다. )

- 통합 테스트 일정이 빡빡하면 보통 야근/ 주말출근 강요하는 곳도 많아요..(통합 테스트 전 주말은 무조건 나오게 하는 곳도 가끔 있고요, 이런 곳을 피하려면, 프래 젝트 투입 전 인터뷰 때 잘 파악하거나, 투입 후 1주일 안에 파악하는데 어렵죠..)

 

---

 

5. 오픈 및 안정화 (오픈 대응, 안정화, 산출물 마무리)

 

 단위, 통합테스트를 완료하고 나면 오픈일정 다가왔거나 오픈을 준비해야 되는 상황입니다. 개발한 범위의 퀄리티가 오픈 수준으로 충분히 테스트를 했을 수도 또는 부족할 수도 있지만, 오픈은 결국 오게 됩니다. 보통 개발 이슈나 테스트에서 이슈가 생겨서 일정을 미루거나 개발 공수를 더 보채는 경우도 있지만 항상 일정이라는 것이 무시 못하게 됩니다. 일정을 더 미루면 비용이 발생하기 때문에..

 업무에 따라서 일정을 맞추지 못해서 야근을 하거나 주말, 휴일 출근을 하는 경우도 많습니다. 근무시간 9 to 6을 지키고 싶어도 어쩔 수 없는 경우도 많고요 뭐 개발 프로젝트뿐만 아니라 학생 때 시험기간이나 리포트 제출 등등도 다 똑같다고 봐야겠습니다. 

 오픈시에는 중요한 것이 오픈 전 프리징(오픈을 하기 위해 시스템 점검을 하는 시간을 두면서 기존 시스템(As-Is)의 데이터와 개발한 시스템(To-Be) 통합등을 진행합니다. 이는 테스트 시 미리 진행하는 경우도 있으며  오픈과 동시에 이루어지는 경우도 있습니다. ) 이전 시스템에 있는 데이터들의 마이그레이션 하게 되고, 마이그레이션 데이터들과 이번에 오픈한 시스템 간의 데이터 정합성(테이블의 칼럼이 변경되거나 신규 추가 된 부분과, 과거의 데이터들이 문제없어야...) 등을 확인하게 됩니다. 

  저같은 경우는 프리징 한 데이터의 마이그레이션 된 부분과 신규 개발된 부분이 오픈 후 테스트 시 칼럼의 데이터 위치가 뒤바뀌는 경우도 있었으며, 해당 부분에 대해서 영향도를 파악하고 긴급 패치를 통해서 오류를 잡은 경우도 많이 있습니다.

 일단 오픈 후 오픈 대응을 하면서 시스템이 잘 돌아가는지 문제없는지 파악하며, 결함이 나오는 결함 정도에 따라 긴급배포 또는 정기배포를 통해 오류를 수정하게 되며, 이를 보통 안정화 기간이라고 표현합니다.

 프로젝트 일정에 따라 다양하지만, 이 시기에 안정화를 하면서 개발 산출물을 최신화하는 경우도 있고, 오픈 전에 사용자, 운영자 매뉴얼을 작성해 뒀지만, 잦은 오류 수정 또는 고객의 요청으로 인한 ui 변경에 맞춰서 매뉴얼도 최신화합니다.

보통 산출물 작업과 동시에 운영인력에게 개발한 업무에 대한 인수인계를 진행하고 프로젝트가 마무리됩니다. 

---

 

참고 사이트

 

 SI, SM개발자에 대해서 더 알고 싶으면 다음의 사이트에 정리한 글을 참고 하셔도 됩니다. 

SI 개발자 vs. SM 개발자, 역할과 차이점

SI 개발자 vs. SM 개발자, 역할과 차이점 - 데브준

 

IT 개발자가 하는일 (구현 단계) 소프트웨어 구현

IT 개발자가 하는일 (구현 단계) 소프트웨어 구현 - 데브준

---

 

마무리

 프로젝트는 기존의 구식 서비스를 대체 하여 최신 트렌드의 기술로 개발하는 '차세대 프로젝트' 또는 기존의 서비스에 기능을 추가하거나 고도화하는 '고도화 프로젝트' 등이 있으며, 그 외 성능개선이나 서비스 운영업무를 하는 프로젝트가 있습니다. 여기에 작성한 내용은 보통이 SI 프로젝트의 차세대 또는 고도화에서 많이 진행 한 내용입니다.