쌩초보 신입사원 에이전시로 출근하다.v0.2
02. 나는 어떤 일을 하게 될까
모든 감각이 예민했던 입사 첫날.
유난히 크게 들린 알람 소리, 이상하리만치 길게 느껴졌던 지하철 시간 간격 차이, 나만 크게 들렸던 회사 바닥을 밟은 내 발걸음 소리, 타닥타닥 키보드 소리까지 모든 게 신경 쓰였던 하루였다. 다행스럽게도 긴장했던 신입사원은 팀장님과의 첫인사를 시작으로 기획, 개발, 디자인, 퍼블리싱 그룹까지 회사 라운딩을 무탈하게 마쳤다. 자리를 배정받고 앉은 책상에는 모니터 두 개와 노트북 한 개. 취업을 했다는 게 실감이 난다.
.
.
글쓴이가 첫 출근 날 느꼈던 감정들을 적어본 건데 여러분들도 크게 다르지 않을 것이다. 하지만 걱정하지 않아도 된다. 누누이 말했듯이 회사가 신입사원에게 거는 기대는 크지 않기 때문이다. 그리고 첫 출근부터 신입사원에게 회사의 주 업무를 맡기는 곳은 드물 것이다(찾아보니 당장 인력이 부족하거나 해당 업무를 수행할 수 있는 인력이 없는 경우에는 어쩔 수 없다. 부딪혀 보는 수밖에...).
? 그러면 회사에서 신입사원은 과연 어떤 일부터 시작하게 되는 것일까?
! 아니다. 일이 아닌 회사에 맞는 직무교육을 받게 된다. 이를 OTJ(On The Job *Training), OJT라고 한다. 취업 전 익혔던 문서작성 능력은 회사에 맞는 가이드(용어, UI, UX 가이드 등)에 맞춰 활용할 수 있어야 하고, 회사 내 인력과 팀이 어떤 업무를 하고 있는지 파악하고 있어야 한다. 간단하게 말하면 회사가 요구하는 인력이 되기 위한 과정을 거치는 것이다.
그래서 이번 글에서는 글쓴이의 회사에서 진행했던 아래의 OTJ 일정을 이해하기 쉽게 풀어보려고 한다.
표준 업무 프로세스
개발의 이해
가상의 프로젝트 산출물 작성
1. 표준 업무 프로세스
프로젝트 A-Z회사가 돈을 벌기 위한 과정이 매번 다르다면 시간에 따라 바뀔 수 있는 인력에 탄력적으로 대응할 수 없다. 그렇기 때문에 회사는 그들의 업무가 표준화되어 있어야 한다. 에이전시에서의 업무의 표준화란 고객사의 프로젝트를 제안할 때부터 프로젝트를 착수하여 진행 후 완료되어 보고할 때까지 A-Z 모든 과정을 단계별로 구조화한 것이다. 하나의 프로젝트에 엄청 많은 산출물과 업무가 있지만 글쓴이는 다 설명할 수 있는 능력이 되지 않아 간단한 설명과 산출물에 대해서만 설명을 하고자 한다.
1) 제안
- 고객을 선정하고 프로젝트를 제안
- 제안 전략 수립, 제안 OT 및 Review, 제안 TFT 구성 진행
- 산출물: 제안서, 벤치마킹 문서 등
- 제안에서 계약이 진행되면 구축계획 단계로 넘어감
2) 구축계획
- 수주 보고, 초기 계획, 산출물 목록 정의, 내부 킥오프/투입인력 OJT, 고객 킥오프 및 업무 협의
- 산출물: 수주보고서, 순익분석표, 초기계획서, 산출물 목록 정의서, 수행계획서, 마일스톤 등
3) 분석
- 요구사항 수집/분석, 사용자/자사/경쟁사/환경·트렌드 분석, 요구사항 정의 및 검토 - 확정, IA 설계, 서비스 콘텐츠 분류, 추진 일정 확정(상세 WBS 수립)
- 산출물: 사전질의서, 분석결과서, 요구사항 정의서, IA, 콘텐츠 수급 리스트, 일정계획서 등
4) 설계
- 벤치마킹, UI/UX 가이드 설계, 주요 기능 프로세스 정의, 스토리보드 작성, 중간보고
- 산출물: 분석결과서, 표준 가이드, 메뉴구조도, 화면목록, 화면설계서, 플로우차트, 중간보고서 등
5) 구현
- 모듈별 단위테스트 진행, 테스트 계획 수립 및 실행, 보안 점검, 소스 배포
- 산출물: 테스트 시나리오/결과서(단위, 통합) 등
6) 이관
- 사용자/운영자 교육, 매뉴얼 작성
- 산출물: 사용자/운영자 매뉴얼
7) 완료
- 완료 산출물 정리
- 산출물: 완료 산출물 원본소스 CD/출력물 바인더
8) 관리/보고
- 회의록 작성
- 산출물: 회의록
2. 개발의 이해
개발 용어는 무수히 많은데표준 업무 프로세스에 대한 교육을 받고 나서 개발자 출신의 이사님께서 직접 교육하셨던 내용이다. 때문에 지극히 주관적이고 자극적인 표현을 사용하셔서 인상 깊게 들었던 기억이 난다. 보통 기획자가 다른 직무와 대화를 해야 하는 상황이 온다면 그 직무는 아마도 개발자였기 때문에 이런 교육을 마련해주신 게 아닐까 싶었는데 두 번의 프로젝트를 거친 지금은 이 교육을 다시 들어보고 싶다는 생각이 든다. 때문에 다음 내용만 이해하고 있다면 프로젝트를 수행할 때 큰 어려움은 없을 것이다.
1) 개발을 지금보다 조금이라도 더 알게 된다면
- Deep Dive 할 필요 x, 얕고 넓게 알아야 함, 개발 관련 용어 위주로 공부
- 개발자와 원활한 대화 가능 -> 원만한 오류/이슈 해결 가능
- 설계 시 보이지 않는 흐름에 대한 인지 가능
- 위험 감수 및 문제 해결에 효율적 대응 가능
2) 개발자(Developer)의 종류
- Front-end: UI Dev.
- Back-end: Server Side Dev.
- Dev-Ops: Development + Operation
- Full-Stack: All round Dev.
3) 이해관계자
- 어떻게 대응하느냐에 따라 프로젝트의 성패가 갈림
(1) 고객사, 현업 IT 담당
- 현업, 현업 지원 담당, IT전략, IT담당, 인프라SE, SM개발자
(2) 팀 내부
- 기획자, 퍼블리셔, 디자이너, 개발자
4) 개발 용어
- OS, DB Server, WEB Server, WAS, Server, 언어, Framework, Cloud, Internet, 응용어플리케이션 등
5) 웹의 구성 및 원리
- 클라이언트 - 서버 간 응답 및 요청의 이해
- 웹 채널 시스템 구성: 사용자 - DMZ - 내부망 간 WEB, WAS, Storage, Core 등 구성 이해
3) 가상의 프로젝트 산출물 작성
긴 교육을 듣고 난 후 마지막으로 기획팀장님이 과제를 내주셨다. 가상의 서비스를 설계하여 산출물을 제출하는 과제였고 제출해야 할 산출물은 사전질의서, 요구사항정의서, 메뉴구조도, 화면목록, 화면설계서, 단위/통합 테스트 시나리오였다. 당시 글쓴이는 1대 1 문의 게시판 서비스를 담당했는데 지금 생각해 보면 정말 작은 부분이었는데도 불구하고 그때는 많이 허덕였던 기억이 난다. 이 문서들에 대한 작성요령을 모두 작성하기엔 글쓴이의 실력이 아직 부족하다 보니 이 중 프로젝트 투입 시 신입 기획자가 주로 다루는 문서인 요구사항정의서, 메뉴구조도, 화면목록, 화면설계서, 테스트시나리오에 대해서는 따로 주제를 다르게 잡아 글을 써보려 한다.
비록 가상의 작은 프로젝트였지만 이런 기획 단계를 거쳐 구현이 되어 출시가 된다는 것을 알게 되었고 기획자는 Front 단도 생각해야 하지만 발생한 데이터를 Back 단에서 어떻게 처리할 것인지에 대해서도 염두해야 한다는 점도 깨달았기 때문에 좋은 경험이 되었다.
이렇게 신입사원은 첫날부터 첫 프로젝트에 투입되기 전까지 약 1달 정도의 기간 동안 직무교육을 받았고 그토록 기다리던 첫 프로젝트로 파견을 나가게 된다. 다음 글에서는 첫 프로젝트에서의 경험을 신입 기획 사원의 관점에서 공유할 예정이다.
추가로 프로젝트에 투입하면 실제로 기획 문서를 접하게 된다. 하지만 대부분의 신입이라면 어떤 내용을, 어떻게, 왜 해야 하는지에 대해 알기 힘들어 문서작성요령에 대한 글을 발행하기로 했으니 아래의 링크에서 참고했으면 한다.
참, 글을 쓰는 지금도 과거를 되짚어 보며 최고의 공부를 하고 있다.
學而時習(학이시습): 배운 것을 항상 복습(復習)하고 연습(練習)하면 그 참 뜻을 알게 됨
