iOS 개발자 2년차 안효진 멘토
멀티미디어공학전공으로 혁신성장 인공지능 과정을 이수 후 SI업체 1년을 다닌 후 iOS 개발자로 2년째 일하고 있다고 한다. 종종 듣기로는 iOS개발자가 한국에서 큰 수요가 없다고 들었는데 실제로 만나서 듣다 보니 생각보다 다른점도 많았다. 멘토는 학과에서 얻을 수 있는 정보는 극히 일부로 현업에서 어떤 기술을 사용하는지, 관련 경험이 없는데 경쟁력이 있는지 고민했다고 한다. 취준생으로 충분히 공감이 가는 고민이다.
+ 이태승 멘토도 유사한 얘기를 했는데 직무 탐색이 되지 않은 상황에서 개발자로 취업을 하면 후회를 많이 한다고 한다. 그리고 주변에 알려줄 수 있는 사람도 없었다고 한다. 나는 이번 멘토링의 두 사람 덕분에 SI업체의 구조적 문제에 대해 현실감있게 듣기도 하였고 당장 외부에서 취업을 원하는 압박을 하더라도 좀 더 공부하고 자세한 직무 분석을 토대로 취업을 하여 후회하는 일이 없도록 준비할 것이다. 결국 두 사람다 1년이 채 못되어 퇴사를 했기 때문에 더욱 와닫는 말이다. 그래서 나에게 이런 질문을 던진다. 당장의 선택이 아닌 인생 전체에 걸친 개발자 커리어의 시작을 어떻게 실수를 줄이고 나에게 맞는 기업을 찾을 수 있을지,,
- 개발 초기부터 시작하여 프로세스를 알(할) 수 있는 곳(뒤 멘토도 똑같은 말을 함)
- 당장이 아닌 수요가 많고 트렌드에 맞는 개발 언어(잘 사용하지 않는 언어는 커리어가 쌓이기 힘듬)
- 사내 개발 문화, 복지, 경험을 쌓을 수 있는 곳(개인적으로 중요하다고 생각하는 부분)
4. 개발 포지션
5. 개발 트렌드
6. 개발 프로세스
첫 회사 참여 프로젝트 소개
OO 홈소핑
- 대형 프로젝트 운영 경험 -> 서비스 이용자가 많음. 트래픽 높음
- 다양한 사람들과의 협업 -> OO홈쇼핑, OO이커머스 및 정보통신, 협력사, 프리랜서 다양한 직업군, 직종 경험
- 대기업 개발 프로세스 -> 이미 만들어진 서비스를 유지보수 하거나 수정할 가능성이 높음, 개발 스택의 스위칭이 힘듬
- 리뉴얼 참여 ->새롭게 변경되는 UI와 기능을 구현함
이직 후
프로젝트 초기부터 참여하여 개발 ~ 운영
개발 언어 Obj-C 이후 Swift
테크니션 & BP 테크
B TO B 앱 서비스 -> 내부 스토어 배포용 / 서비스를 위한 교육 필요
웹 앱 -> Web to native, native to web에 대한 이해 필요
협력사와의 의사소통 -> 외부 개발 협력사 간의 의사소통 필요, 커뮤니케이션을 위한 툴, 문서 이해 능력
다른 서비스와 상호 작용하는 앱 -> 차량 정비 프로세스와 상호작용 하는 앱에 대한 이해 필요
사람들이 생각하는 프론트엔드
포토샵 파일, 이미지, 와이어 프레임 프로토타입 만들거나 이른 가지고 웹페이지 만드는 일
웹페이지 애니메이션 만들고 트랜지션 효과 주기 위한 자바스크립트와 HTML, CSS 작성
실제 프론트엔드가 하는 일
디자이너와 엔지니어간의 시각적 확립(공통 컴포넌트_간격, 글꼴, 아이콘, 여백 UI 정의, 개발 가능 범위)
컨벤션, 프레임워크, 요구사항, 시각적 언어, 앱 어플리케이션 기준 확립
백엔드와 API 통신, 백엔드 접속에 대한 안정성 확보 CORS, XSS, CSRF(보안 이슈)
다양한 해상도, OS에 대응하는 디바이스별 UI
Lazy Loading, 부드러운 애니메이션, UI/UX 비동기 처리, 기능 향상
버전 관리, 버전에 따른 UI-비즈니스 로직 의존성 관리
웹 개발 트렌드
SPA(Single Page Application)
single page를 사용하기 때문에 하나의 어플리케이션을 사용하는 듯한 사용자 경험을 줄 수 있음
필요한 데이터를 받아와서 부분적으로만 업데이트
현재 페이지를 동적으로 생성함
CSR(Client Side Rendering)
서비스에 필요한 데이터를 클라이언트에서 추가로 요청하여 재구성 하는 방식
초기 전송되는 페이지 속도가 빠름
페이지의 완료 시점은 SSR 보다 더 느린 편
페이지 로드 이후에 동적으로 콘텐츠를 생성
html에 모든 것을 구현하지 않고 js링크를 사용하여 처음 접속시 빈화면 -> js(프레임워크와 로직)을 다운로드 받는 시간 필요
콘텐츠를 빠르게 소비하는 사용자 요구사항을 충족 시키기 어렵다는 단점 -> 사용자가 첫 화면 보기까지 시간이 오래 거림
SSR(Server Side Rendering)
사용자에게 보여줄 페이지 전부를 서버에서 구성하여 사용자에게 보여주는 방식
인터렉션까지, 모든 데이터가 매핑되어 있기 때문에 서비스 페이지를 사용자에게 바로 보여줄 수 있음
CSR보다 느린편 이지만 이전에 비해 페이지 로딩이 빨라짐
CSR의 SEO 문제를 개선
하지만 전체를 서버에서 부터 받아 오기 떄문에 좋지 않은 사용자 경험
동적으로 제어 가능한 자바스크립트를 받아와야 인터렉션이 가능하기 때문에 실제 웹페이지를 볼 수 있는 시간과 인터렉션의 시간 차가 긴편
TypeScript, React, Angular, Vue.js
개발 프로세스(생명 주기)
요구분석, 시스템 명세, 설계, 구현(개발), 테스트, 유지보수
요구분석 SRS(Software Requirements Specification) 개발자는 거의 안함
고객사 혹은 사용자들이 원하는 서비스와 기능이 무엇인지 명세하는 단계, 소프트웨어가 수행해야할 기능들, 기능상의 제약조건, 합의 사항 등을 포함함
개발 비용 산정
소프트웨어 규모를 파악 후 필요한 비용을 산정하는 일
인력과 자원, 소모 시간등을 파악 -> 공수산정(소프트웨어 개발 시 소요되는 총 인원수, 개발 기간을 선정하는 일)
개발자가 할 일 -> 해당 소프트웨어를 개발하는 데 필요한 인력과 시간이 얼머나 소모되는지 피드백
와이어프레임
디자이너가 제품을 구성하는 레이아웃을 간단하게 시각적으로 표현한 것
소프트웨어의 골격과 구성을 간단하게 알아 볼 수 있으나 100% 반영되는 것은 아님
제한적인 요소만 담고 있음
고객사와 협의 혹은 프로토타입 등에 사용됨(의사소통 수단)
프로토타입
UI/UX 구현
시각화 화면 전환
개발에 참고하여 빠른 기능 구현 가능하게 할 수 있음
개발자, 기획자, 디자이너, 고객 간의 의사소통용으로 사용 가능
피그마는 디자인부터 프로토 타입까지 지원하고 있음
스토리보드(최종 프로젝트 3단원)
간략한 ui구성
ux나 인터렉션에 대한 정의
구현되어야 하는 사항
기능/비기능적인 사항들이 정의 되어 있음
전체적인 흐름, 플로우(전체적인 흐름이 어떻게 되는지)
세부적이며 구체적이어야 하고 상세히 기술되어야 함
이를 이용하여 디자이너들은 서비스를 디자인, 개발자들은 구현
소프트웨어에서 사용되는 개념들을 정의하고 로직을 구성
기획자가 맡아서 함
간혹 각 os에 대해 이해를 하지 못한 기획자가 기획하여 잘못된 경우빠르게 수정을 요청해야 함
잘못된 플로우로 개발 할 경우 추후에 더 큰 비용, 수정이 필요할 수 있음
제대로 정의된 방향으로 소프트웨어가 개발 되기 위해서 스토리보드의 역할이 중요함
디자인 툴
스케치, ADOBE XD, ZEPLIN, FIGMA
디자인
공통 컴포넌트, 글꼴, 자간, 메인 컬러 지정
모든 화면이 포함된 가이드라인
상세하게 디자인 된 앱 화면을 전달 받음
ui/ux중에서 ui
개발
[클라이언트]
안드로이드 앱, IoS앱, PC 프로그램, 웹 브라우저, IoT 장치
-> HTTP request [Get / coffees]
<- response
API 서버 - DB, 캐시 서버, APPLICAITON 서버 ,서비스
정의된 컴포넌트를 사용했는지
UI/UX 사용자 경험 중요
페이지 로딩, 새로운 데이터를 불러오거나 페이지 이동시 걸리는 로딩
웹브라우저와 OS에 대한 이해 필요
Permission, 보안 이슈 대응
= 다양한 종류의 기기와 OS 대응 이에 맞춰 웹도 변경할 필요가 종종 있음 플랫폼 별 개발자들과의 의사소통 필수
QA
소프트웨어 품질(Quality)을 보증(Assurance) 품질을 보증하는 다양한 업무를 수행함
테스터 종류
알파테스트(사내에서 운영, 폐쇄적인 테스트)
베타테스트(공개적이며 외부에서 진행함)
QA가 하는 일
스토리보드에 정의된 요구사항을 따랐는지
기능적 비기능적 요구사항이 잘 정의되어있는지
디자인에서 정의된 디자인적 요소에 결함은 없는지
테스트를 통해 개선사항은 없는지 확인
로딩이나 사용자 경험이 좋지 않은 경우 개선을 요청 받을 수 있음
버그를 발견
개발자들과 QA 간의 원활한 의사소통 필요
테스트케이스를 작성하고 테스트를 진행
협업 툴을 사용하거나 결과에 대한 보고를 통해 피드백
유지보수 및 운영(클라이언트가 요구)
출시 이후 추가 개발건 반영
사용자의 의견을 수집하고 반영 - 별점 등
버그 및 이슈 수정하여 배포
버전관리
이렇게 1일차가 끝났는데 많은 것을 배웠다. 혁신성장 멘토님에게 처음 배웠던 개발 프로세스가 그때는 막연히 이런 구조구나 라고만 생각했는데 멘토링을 통해서 구체적인 흐름과 예시를 통해서 예전 3개월 멘토링이 기억이 났다. 특히 스토리보드 양식을 주면서 처음부터 끝까지 우리가 제작 했던 세부내용을 작성했는데 그때 정말 좋은 경험을 한 것 같다. 그리고 디자이너와 프론트엔드가 협업을 한다고 했을 때도 막연히 잘 이해를 못했는데 예시사진을 보니 디자이너가 와이어프레임으로 색상, 모양, 등을 시각적으로 구성하고 개발자와 소통한다는 것이 어떤 것인지 이해했다. 그리고 제작 이후 여러 테스트를 거쳐 QA과정과 유지보수를 하는데 혁신성장 멘토님이 늘 하셨던 말씀이 기억이 난다. 내가 개발하기 편하고 만들기 쉬운 상태로 웹을 만드는 것이 아니라 항상 사용자 관점에서 내가 사용자라면 이 기능이 편할까? 더 편한 기능은 없을까? 라고 스스로에게 물으라고 했는것이 결국 QA를 거치기 전 개발자가 스스로 점검할 수 있는 방법이다.
+ 안효진 멘토는 웹에 대한 전반적인 지식과 예시를 적절히 설명해주어 모호했던 부분을 이해시켜주었다면 이태승 멘토는 바로 실습을 통해 현장경험을 해줌으로써 간접적으로 공부를 할 수 있게 해준다. 두 멘토를 선택한 것이 잘 한 것 같다. 남은 멘토링도 잘 배우고 많은 질문을 통해 좀 더 성장하는 내가 되어야겠다.
