Android 란? 2편

6. 안드로이드 역사

현재 가장 최신 버전은 9.0 버젼이다. 코드 네임은 Pie다.

안드로이드는 2008년 1.0을 발표한 후 거의 매년 새로운 버전을 발표하고 있다.

현재 출시되는 대부분위 단말기는 8.0 Oreo 버젼을 기반으로 하고 있다.

코드네임이라고 불리는 이름은 모두 탄수화물로 만들어 과자이름이다. 많은 회사들이 직원들 복지 차원에서 과자를 비치해 두고 있는데 복잡한 문제를 풀면서 생기는 스트레스를 완화 시켜 주지만 뱃살이 늘어나는 원이이 되기도 한다.

구글 개발자 들도 과자를 좋아 하나 보다. 

개발 입문을 하기에는 Lollipop이면 충분하다. 롤리팝은 막대사탕을 의미한다. 추파춥스도 막대 사탕의 일종이므로 롤리팝이다.

물론 새로 나온 최신 기능을 사용하려면 높은 버젼의 단말기가 필요하겠지만 그런 기능은 고급 과정에서 필요하다.

본인 단말기를 개발에 사용해서 지저분하게 되는 것이 싫은 개발자는 중고 단말기를 구입해서 사용하면 된다.

현재 시중에 Note3 같은 5~6년 전에 출시된 중고 단말기는 10만원 대에 구매할 수 있다. 이때 출시된 단말기들이 버젼업이 되어서 롤리팝까지는 지원한다.

7. 안드로이드에서 앱 개발하기

A 기획하기

먼저 어떤 앱을 만들지를 결정해야 한다.

보통 이 단계에서는 사용자가 어떤 기능이 필요한 지 알아내고 그 기능을 상세하게 문서화 하는 단계이다.

대부분 초보 개발자는 이 단계를 건너 뛰거나 아주 조금 작업을 하고 다음 단계로 넘어 간다. 이 단계에서 제대로 된 작업을 하지 않으면 원하는 정도의 완성도 있는 결과물을 만들기는 어렵다. 어떤 기능이 필요한 지 명확하지 않다면 당연히 다음 단계에서 문제를 일으킬 수 밖에 없다.

그렇다고 모든 기능을 다 넣게 되면 회사의 개발 역량으로는 개발이 완료 되지 않을 수도 있다.

선택과 집중이 필요하다.

물론 힘든 작업이긴 하다 존재하지도 않는 기능을 상상력만으로 구체화 시키고 써보고 다시 또 변경하고 다시 구체화 시키는 작업을 해야 하기 때문이다.

상상력 만으로 기능을 정리하고 구체화 시키기는 어렵다. 이런 작업은 직접 눈으로 보지 않으면 아주 힘든 작업이 된다. 그래서 많은 도구들이 사용되고 현재도 개발되고 있다.

많은 사람들이 기획 단계에서 스토리 보드 같은 형식을 사용한다.

어떤 기획자는 PowerPoint를 자기만의 규칙으로 사용해서 스토리 보드를 만든다. 또는 스트리 보드를 지원하는 전문 제작 툴들이 있다.

이런 툴들 중에는 반응형으로 제작 가능한 도구들도 있다. 물론 코딩 능력이 어느 정도 필요하고 시간도 많이 걸린다. 하지만 그만큼 기능정의에 있어서 스토리 보드는 중요하다.

내가 생각한 기능을 스토리 보드를 이용해서 실제 사용하는 것처럼 구체화 시켜 보기 바란다. 규칙은 따로 정해진 것이 없다. 자신만의 스토리 보드를 통해서 기능을 구체화 하고 나열하기 바란다.

B. 개발자와 기술적인 부분 확인하기

나 혼자 개발 하는 개발자는 이 부분을 스스로 하게 된다. 이 부분은 구현하기 어려운 핵심 기능이 어느 정도의 시간에 어느 정도까지 개발이 가능한지 확인 하는 시간이다. 디자이너는 실제 필요한 화면 디자인을 보고 제작 시간과 난이도를 확인하다.

이 과정에서 나온 문제를 토대로 다시 기획을 하게된다. 개발 일정을 늘이기도 하고 기능을 변경하기도 하고 기능을 더 고도화시켜서 다시 기획 하기도 한다.

프로젝트는 항상 시간과 인원의 제약이 있다. 시간과 인원에 맞는 기획을 하되 프로젝트 도중에 격는 시행 착오를 최대한 줄여 개발 해야 한다. 시행 착오를 많이 결다 보면 결국 기획과는 다른 결과물이 나오거나 계획한 기간을 지나서 결과물이 나오게 된다.

C. 구체적인 설계 후 개발 기간 확정하기

 B 단계에서도 개발 기간은 확정되지 않는다. 핵심 기능만 확인했을 뿐 대부분의 시간을 차지하는 나머지 부분들에 대한 설계 및 기간 산정을 하지 않았기 때문이다.

많은 기획자는 이 단계를 기다리지 못한다. 사실 개발이 어떤 식으로 이루어지는 지 모르기 때문에 바로 코딩 작업을 하지 않으면 개발을 시작하지 않은 것으로 생각하기 쉽다.

이 단계에서는 개발자가 설계한 구조와 방식으로 기획자가 의도한 기능이 처리 가능한 지를 맟추어 보면 어떤 부분이 빠졌는 지 어떤 부분에 대한 설계가 없는 지가 명확해 진다.

우리는 이 단계에서 제작하게 될 앱의 기본 구조를 정의 하게 된다. 대부분 필요한 기능, Thread 추가와 Sync 문제, 화면 업데이트 문제, Architecture 관련 해서 Layer를 나누는 문제 관련된 것들이다.

Class의 이름과 기본 동작도 정의하게 된다. 상당히 지루한 작업이다. 동작 시켜 보고 하는 것도 아니고 그림 그려 가면서 상상력으로 어떤 일을 처리하는 구조물을 만들어야 하는 것이다.

시스템 또는 프로그램을 만드는 일은 CEO 없이도 일 처리가 가능한 시스템화된 회사를 만드는 것과 비슷하다. 전체 기능이 동작하도록 큰 기능 단위로 부서를 만들고 기능이 동작하도록 부서원을 채용해서 일을 시키는 것과 같다. 회사는 시스템화 되어서 각 부서는 자기가 맡은 기능만 하고 결과물을 반복적으로 내면 문제 없이 일이 처리되고 회사는 잘 돌아간다.

당연히 부서간에 이루어 지는 협업도 시스템에서 정의를 해야 한다.

부서간 오고 가는 데이터와 데이터를 주고 받는 행위는 시스템 설계에서 매우 중요하다.

업무가 시스템화 된 회사는 스스로 동작하는 프로그램과 같다.

D. 이제 본격적으로 코딩

설계 안이 나왔으면 개발자는 작업 시간을 고려해서 스케쥴을 짜야 한다.

아이템을 개발자의 실력에 맞게 나누어 주고 아이템을 맡은 개발자는 각자 분석 후 스케쥴을 정한다.

자기가 잘하는 분야와 핵심 부분은 본인이 하고 나머지는 외주는 주는 방식도 좋고 한땀 한땀 자기가 모두 개발하는 것도 좋다. 

소비자의 욕구와 사용 패턴을 알기 어렵다는 가정하에 근래에 애자일 방식으로 많이 개발 한다. 기능 개발을 여러 단계로 나누고 1차 개발된 결과물을 기획자와 소비자가 실제 사용 및 점검해 보고 다시 기획을 수정하고 개발 설계를 바꾸고 개발을 하는 이 과정을 빠르게 반복하면서 개발하는 방식이다.

많은 작업 시간을 들인 후 기획이 잘못 되었거나 기회과 다른 결과물이 나오는 것을 방지 하기 위한 방식의 개발 방법론이다.

개인적으로 좋아한다.

물론 기초 설계 단계에서 설계를 잘 해서 설계의 큰 틀이 바뀌지 않는 다는 가정하에 오버헤드도 생각 보다 크지 않다.

이제 본격적으로 개발 환경을 설치하고 개발을 시작하자. 동료들과의 협업은 언제나 즐거운 놀이다.

안드로이드 플랫폼을 선택했으니 개발 언어는 Java 또는 Kotlin을 사용한다.

E. 테스트

개발 하다 보면 에러를 찾는 것도 상당히 고된 작업 중에 하나다.

테스트도 하나의 분야로 여러 가지 방법론이 나와 있다.

기본적으로 앱은 유저가 사용하는 방식으로 모든 기능을 직접 사용하면서 테스트 한다.

하지만 소프트웨어가 변경 될 때마다 이런 방식으로 테스트 하는 것은 너무나 비효율적이다.

그래서 어느 정도 프로그래밍에 익숙해 지고 나면 테스트 자동화 하는 방법에 대한 공부가 필요하다.

물론 이런 방법으로 테스트를 모두 하기는 여렵지만 테스트에 들어가는 노동력을 생각한다면 꼭 사용해야 할 방법이다.

F. 앱 배포하기

테스트가 끝나면 앱을 사용자들에게 전달해야 한다.

앱은 안드로이드 마켓에서 배포를 하게 된다.

안드로이드 마켓은 개발자로 일단 등록을 한 후에 앱을 등록하고 여러 가지 정보를 입력한다.

입력 후 일정 시간이 지나면 승인이 완료 되어 사용자들이 개발자가 개발한 앱을 다운로드 할 수 있고 인앱에서 결제를 통해 아이템을 살 수도 있다.

이로써 당신도 초보 개발자가 된 셈이다.

이제 부단한 노력으로 개발 방법과 기술 그리고 분야를 넓혀 뛰어나 개발자가 되기를 바란다.

1편으로 가기