프리랜서 개발자 또는 개발자들이 프로젝트에(보통 여기서는 SI 개발 프로젝트에 대해서 설명할까 합니다.) 투입될 때 알아두면 나쁘지 않을 저의 경험을 소개합니다.
먼저 약간의 용어를 좀 알고 가야 쉽게 설명이 될 듯해서 작성합니다
- 운영서버 : 실제 고객, 고객사 회사원 또는 사용자들이 사용하는 실제 서버를 말합니다.
- 스테이지 서버: 회사마다 있고 없는 곳도 있는데, 운영 반영전 최종적으로 체크하는 서버를 말하고, 보통 DB를 운영서버 쪽을 사용하고 화면만 개발된 것 적용하여 테스트하는 경우가 많습니다. 용어는 조금 다를 수도 있어요
-개발서버 :로컬에서 개발된 것을 테스트하는 용도의 서버, 보통 운영환경과 동일하게 만들어 놓습니다.
보통 이렇게 분류되어 있고,
프로젝트를 진행하는 곳마다 다르지만 개발서버에 직접 개발자가 올려야 되는 곳도 있고 (이때는 FTP/텔넷 사용으로 직접 개발서버에 개발된 파일 적용하는데, 이경우 Free FTP 소프트웨어 파일 질라(FileZilla)라는 프로그램을 많이 사용하고 사용하기 쉽고 인터넷에 검색하면 자료가 많습니다.
- 규모가 큰 회사의 프로젝트인 경우 개발환경(또는 세팅) 교육을 해주는 곳도 있습니다. (프로젝트 중간에 투입될 경우엔 교육해주는 일이 없다고 생각해도 됩니다. 이것도 케바케인 듯합니다. )
1. 프로젝트에 투입된 회사에 들어가면 환경 세팅 유형..
일단 타입이 두 종류로 분류되는 거 같습니다. (아닌 경우도 있어요...)
- 방치형 : 세팅하는 파일 위치 정도만 가르쳐 주고 거의 알아서 환경 세팅하라고 하는 곳..
그나마 환경설정 가이드라도 만들어 놨으면 다행인데, 그렇지 않은 곳은 가이드 파일조차 없고 IDE툴인 이클립스 자바 버전 정도만 알려주고 알아서 설치하라는 곳도 있었네요..
이경우는 세팅하다가 막히면 미리 세팅한 개발자에게 물어보고 설치해야 되고, (초기 투입이라 세팅 한 사람이 없으면 PL 또는 PM과 같이 세팅을 해야 되겠죠..) 안되면 구글링 하면서 세팅해야 될 수도 있습니다.
- 담당형 : 프로젝트 규모가 크거나 시간의 여유가 있다면 환경 세팅해주는 개발자분이 한 명 있음.
그분이 세팅하라는 대로 하면 됩니다. 이경우엔 보통 환경설정 가이드 파일이 존재하고 잘 작성되어있고요,
이경우라 하더라도 어느 정도 기본적인 설정은 할 줄 알아야 합니다. 경험이 그래서 중요한 듯해요..
2. 환경 세팅이 끝나면 프로젝트 개발 시 준비해야 될 것들이 있는데요...
- 파일서버 IP 및 접속 방법(ex..파일 탐색기 경로표 시창에 \\192.198.1.120 접속 > id/pw로 접속) ->이때 아이피 권한 또는 액세스 권한도 풀려야 되는 경우도 있습니다.
파일서버에는 보통 프로젝트 개발에 필요한 요구사항 정의서/ 화면 개발/ 프로그램 목록 / 개발 가이드 / 환경설정 가이드 등의 자료나 파일들을 모아놓고 있으며, (시간 날 때 미리 다 읽어보는 게 도움되고요, )
- 개발 프로젝트 위치(svn 주소) 및 체크아웃 방법.. 실제로 개발될 프로젝트 소스의 위치라고 생각하면 됩니다. 다른 개발자들과 함께 사용하며 개발 후 커밋/업데이트로 형상관리를 한다고 보시면 됩니다.
(이것도 프로젝트 회사마다 사용하는 것이 다른 경우가 많고요, 보통 이클립스에 SVN을 사용하지만 CVS, git 등등 다른 형상관리 툴을 사용하는 곳도 많고, 구글링 해서 어느 정도 찾을 수 있습니다.)
- 개발서버가 구축되어 있다면 개발서버 로그 보는 법은 보통 리눅스 서버에 구축이 되어있으며, (리눅스 접속할 수 있는 putty로 보통 확인이 가능합니다. / 리눅스 명령어로 사용할 줄 하고, 사용하고 보는 방법은 회사마다 다양하기 때문에 그때그때 알아서 할 수 있으면 좋습니다.)
- 환경 세팅이 모두 끝났다면 담당 프로젝트 개발범위(업무 또는 모듈)가 어떤 건지 확인하고 업무소스를 파악해야 됩니다.
- 보통 개발기간 동안 주간회의 날짜가 잡혀 있을 것인데 (개발자가 참석하는 경우도 있고 pm/pl만 참석하는 경우도 있어요) 개발자가 참석하는 경우 시간 잘 파악해야 되고, 보통 이때는 WBS(전체 개발 일정)에 따라 진척도나 개발 시 이슈사항에 대해서 회의를 하는 경우가 많습니다.
- 전체적인 개발 일정(WBS) 관련해서는 당연히 알려줄 테지만 알려주지 않는다 해도 어느 정도는 알고 있는 게 좋습니다.
(보통은 분석/설계 일정, 개발 일정, 단위 테스트 일정, 통합 테스트 일정, 오픈 일정, 안정화 일정 이렇게 나뉘는 경우가 있고, 개발 규마가 크다면 1차 오픈, 2차 오픈처럼 분할 오픈하는 프로젝트도 있습니다.)
3. 개발 중..
- 형상관리 툴을 잘 사용해야 됩니다.. 개발자 간 소스 동시에 변경할 경우 충돌(Conflict) 일어나는데 변경한 개발자와 상의 후 해결해야 함( SVN툴인 경우는 보통 commit / update/override and update / merge 가있습니다)
- 개발 소스/쿼리 간에 서로 비교해야 할 경우가 종종 생기는데.. 이경우엔 윈머지(WinMerge)
(인터넷 검색 오픈소스 url은 https://winmerge.kr.uptodown.com/windows) 프로그램받아서 두 파일 비교하면 좀 더 쉽게 확인할 수 있습니다. 사용법 쉬워요
- 보통 저 같은 경우엔 하루 단위로 개발 및 작업한 내역을 정리해서 작성해놓는데요.. 일정관리 차원(일일 업무 보고 하는 곳이 가끔 있는데 이건 보통 프로젝트 일정 및 상황이 매우 안 좋을 때 요구합니다.)
- 주석은 열심히 적어두는 것이 좋습니다.. 귀찮아서 안 할 경우 다음에 내가 봐도 뭔지 모를 경우 생김(주석 다는 양식이 프로젝트를 하는 회사마다 틀린데 양식에 맞춰 달아 주면 됩니다.)
- 개발된 소스 테스트 같은 경우엔 자기가 생각하는 경우의 수 외에도 다양한 경우의 수가 존재하므로 여러 방향을 생각해서 테스트하는 것이 좋음(보통 단위 테스트/통합 테스트 때 가장 잘 아는 현업이 테스트 결과 넘겨줄 것임)
대신 가장 기본적인 CRUD가 작동하는지는 당연히 테스트해야 함.. 이것조차 안되면 다른 테스트를 못하기 때문에.. (이것조차 제대로 테스트 안 하고 다했다고 놀고 있는 개발자들이 있음..)
4. 단위 테스트/통합 테스트 중..
- 단위 테스트/통합 테스트 기간을 길게 잡을수록 보통 여유로운 프로젝트입니다. (테스트 기간이 짧을수록 헬일 경우가 많았어요)
- 단위 테스트는 보통 개발자들과 현업 유지보수/운영 인력이 같이 테스트하는 단계 (테스트 결과 나오면 바로바로 수정해 주는 것이 좋아요)
- 통합 테스트는 보통 현업(실제 사용자)에서 테스트하는 단계(실제 사용자이기 때문에 다양한 케이스로 테스트합니다. 마찬가지로 문제점 바로바로 수정해 주는 것이 좋아요, 이때 앞서 말한 주석이 효과를 봅니다. )
- 통합 테스트 일정이 빡빡하면 보통 야근/ 주말출근 강요하는 곳도 많아요..(통합 테스트 전 주말은 무조건 나오게 하는 곳도 가끔 있고요, 이런 곳을 피하려면, 프래 젝트 투입 전 인터뷰 때 잘 파악하거나, 투입 후 1주일 안에 파악하는데 어렵죠..)
5. 오픈 중..
- 오픈 계획서나 마이그레이션 등 오픈에 필요한 작업은 pl/pm이 하기 때문에 이때엔 보통의 개발자들이 거의 일이 없을 수도 있는데,
하지만 오픈 일정(사용자들 제일 적은 새벽에 오픈/ 오후에 퇴근시간 이후에 오픈)에 따라 야근/ 밤샘 / 새벽 출근할 수도 있죠.(이건 회사에 따라 틀려서 어쩔 수 없어요)
- 이때는 오류나 문제점이 발견되면 거의 즉시즉시 수정 후 반영을 하는 것이 좋습니다. 보통 오픈 후 긴급한 수정으로 긴급 반영을 하거나, 정기 반영 등이(프로젝트 소스 수정) 있는데 잘 대처할 수 있으면 좋습니다.
- 단위 테스트/통합 테스트에서 잘해놓으면 오픈 후 할 일 거의 없음(이때 별 문제없으면 휴가나 그런 거 요구해도 됩니다.. 보통 생각 있는 pl/pm이라면 챙겨주겠죠...)
6. 산출물
프로젝트 개발한 것에 대해서 문서화시키는 것이고, 보통 개발 중간중간에 작성을 하는 경우도 있고, 또는 개발 후에 작성하는데 서식이나 양식 등이 프로젝트 회사마다 달라서 그에 맞춰서 작업하시면 돼요.
7. 철수...(프로젝트 종료)
프로젝트 수행할 때 보통 계약 기간이 있는데 계약기간이 오픈 직전 또는 후 아니면 오픈 후 한 달(보통 안정화 기간이라고 합니다.)인데, 전체 개발 일정에서 잘 파악하고, 그에 따라서 마무리하시면 됩니다.
ps. 생각나는 데로 작성을 해서 조금씩 수정하면서 글을 보완하겠습니다. 위의 글이 모든 개발자들이 100% 경험한 것이 아니기 때문에 참고만 해주시면 될 듯합니다.
참고 자료
이 포스팅의 내용을 조금 더 업데이트 한 부분에 대해서 링크를 남깁니다.
2023.08.15 - [개발 및 프로그래밍 관련] - [개발] 개발을 하면서 알아둬야 할 것들 (SI, SM프로젝트, 프리랜서 개발자) ver 2.0
[개발] 개발을 하면서 알아둬야 할 것들 (SI, SM프로젝트, 프리랜서 개발자) ver 2.0
예전에 작성한 내용의 글에서 시간이 흐르면서 조금씩 변경되거나 추가된 내용에 대해서 다시 정리하는 시간을 가졌습니다. 프리랜서 IT 개발자, 웹개발, 모바일 프로그래머들에게 도움이 되기
junibugi.tistory.com
'개발 및 프로그래밍 관련' 카테고리의 다른 글
| 개발용 키보드 교체, 레오폴드 FC750R PD 저소음 적축 모델 (0) | 2021.11.22 |
|---|---|
| 설문 조사 시스템 구축했던 썰.. (0) | 2021.10.13 |
| 현재의 개발환경? (0) | 2019.08.22 |
| [프로그래밍 기초] 코드 에디터 서식을 그대로 가져오는 Color Scripter (0) | 2018.02.05 |