최근 개발 흐름 따라가보기

최근 일이 좀 바빠져서 강좌를 쉬고 있습니다.

개발하며 느꼈던 부분을 남겨봅니다.

최대한 기술용어나 영문을 피해서 작성해봅니다..

개발 동향

제가 생각하는 최근 개발 트렌드는 패턴(MVC, MVVM등)이니 언어(C, Java, kotlin, python등) 같은 것으로 표현하기 보다는 속도=생산성라고 생각합니다.

결국 빠른 생산성이 중요한 시대입니다.

개발 속도가 붙으려면 꼭 필요한 것은..

플랫폼, sdk가 쉽고 탄탄해야 하죠~

특히 메이저 플랫폼(google, apple, ms, facebook)들은 개발자 마다 다른 개성(코드 스파게티화)을 반 강제적인 패턴과 예외처리(옵셔널,델리게이트등)로 막아내고 있는 것 같습니다.

아무나 개발하라고 개발툴도 다 무료로 제공하니 얼마나 좋은 환경인가요~(예전엔 컴파일러들이 정말 비쌌답니다)

버전 극복

플랫폼 키우려는 기업들은 절대~ 개발자들을 괴롭힐 생각이 없습니다.

그런데 스위프트1, 2, 3, 4, 곧 5도 나올정도로 미친드시 버전업을 하기 때문에 사실 개발자들은 괴롭습니다.

당연히 기본 라이브러리는 비교적 쉽게 마이그레이션이 가능하지만..

괴로운 이유 중 하나는 하위 호환이 그리 좋지 못하기 때문에 버전이 올라가면 에러나는 3rd파티 라이브러리가 생기는 것이 큰 문제입니다.

결국 라이브러리 선정이 매우 중요하다고 할 수 있습니다.

당장 급해서 돌아가는 아무개의 라이브러리는 나중에 큰 말썽을 일을킬 가능성이 높습니다.

최대한 3rd파티 라이브러리 사용을 금해야하지만 필요할 경우 메인플랫폼을 따라가며 같이 갈 동반자(updated가 최소 2달 이내의 라이브러리)를 찾아야합니다.

버전업은 두려워해야 할 대상이 아닌 즐거워야 할 대상이고 그것이 곧 개발자의 능력 향상입니다.

버전업 히스토리의 what’s new는 두근두근 합니다~ 이번에는 async가 도입되었을까? 이번에 string이 개선되었을까?등

무엇을 잘해야할까

사람마다 탤런트는 다릅니다.

요리를 잘 하는 사람, 운동을 잘 하는 사람, 언변이 뛰어난 사람등 다양합니다.

요리를 잘 하는 사람은 한식을 잘 하는 사람, 파스타를 잘 하는 사람등으로 나뉘어지고..

한식을 잘 하는 사람은 찌개를 잘하는 사람, 김치를 잘 하는 사람으로 계속 세분화됩니다.

개발을 잘 하는 사람 역시 마찬가지죠..

디비를 잘 다루는 사람, 언어를 잘 다루는 사람, 화면을 잘 다루는 사람등이 있습니다.

디비를 잘 다루는 사람은 RDBMS 잘 하는 사람, NoSQL 잘 하는 사람, 관리를 잘 하는 사람등으로 나눠지고 또 세분화됩니다.

특정 기술 개발자들을 만나서 이야기해보면 탁월하게 잘한다는 느낌이 있습니다.

문제는 경우(주로 밥벌이)에 따라서 시각이 좀 달라야 된다고 생각합니다.

주제 넘지만 제 의견을 얘기해보면..

큰조직의 경우

큰조직의 경우 외주 없이 직접 운영한다면 디비에 ?명 백엔드에 ?명 프론트에 ?명 모바일에 ?명 품질 ?명 엄청난 개발자들이 잘게 분산되어 일하고 있을 것입니다.

프론트만 하나만 봐도 화면구현, 모듈, 콤포넌트, 배포, 품질등 각각의 인원이 필요합니다.

그래서 무언가를 만드려면 많은 인력이 필요합니다.

큰조직의 경우는 그 많은 인권비가 충당될 만한 수익이나 있거나 투자를 받는 상황일 것입니다.

CTO등 상위 계급이나 인사부서등은 혼자 많은 기술들을 둘러봐도 되지만..

일반적으로는 특정한 기술 스택 한개(혹은 +옵션)를 전문적으로 잘해서 밥벌이를 해야하는 상황이 많습니다.

디비하던 사람이 어느날 프론트 좀 익혔다해서 해당팀으로 옮기는 일이 쉽지가 않습니다.

큰조직은 다 잘하는 만능 풀스택인간 보다는 강인한 톱니바퀴형 인간이어야 조직에 도움이 될 것입니다.(깃 커밋 개수로 업무 판단이 가능)

본인이 진보적이어도 무언가 도입하는 것은 엄청나게 고달픕니다.(총대도 매야함..)

예를 들어 git이 아무리 좋아도 이미 회사에서 다른 코드관리를 하고 있다면 엄청난 제안서, 품의등의 서류전형과 마이그레이션등 시간이 필요합니다.

당장은 이미 가진 기술로 밥벌이에 걱정이 없지만 역시 한가지 기술만으로는 노후가 두렵다고합니다.

항상 인력시장에서 본인이 어느 위치인지 돌아보고 여유시간 총동원해서 현재 가지고 있는 기술의 높이를 올리거나 다른 방향의 미래를 그려봐야 할 것입니다.

예를 들어 프론트라면 네이티브자스 -> jquery -> react 식으로 한 줄기의 노선중 가장 핫하고 안정적인 기술스택을 가져가야할 것 같습니다.

작은조직, 프리랜서의 경우

작은조직의 경우는 작은 인원에서 많은 것을 해야해서 대부분 열악한 상황입니다.

적은 인원에 이것저것 하다보니 한사람이 백엔드+디비, 프론트+모바일, 백엔드+프론트+배포, 전부하기 등으로 자동 묶음 상황이 허다하게됩니다.(한편으로는 기회?)

게다가 일부를 외주로 매꿔야하기 때문에 외주와 인터페이스하다 또 다른 어려움을 겪게됩니다.

특히 오너가 신뢰와 이해가 없다면 무한 수렁에 빠지게 되는 것이 큰 문제입니다.

대부분 사내 시스템 또한 주먹구구이기 때문에 인수인계와 코드관리가 엉망일 수 밖에 없습니다.

문제가 있는 조직 이지만 일에 대한 흥미로 버티는 경우라면 장점을 잘 살리는 것이 좋지만..
아닐 경우 학력세탁?으로 큰조직에 문을 두드려 보는 것도 방법이라고 생각합니다..(물론 극도로 어렵지만..)

장점은 진보적인 것들을 큰조직보다 쉽게 도입할 수 있습니다.

덜 복잡한 절차와 구조가 신규 도입을 도울 수 있는 구조가 될 수 있습니다.

예를 들어 git을 도입한다고 하면 우선 혼자 써보고 습득한 후 가능한 사람에 한해 별 절차 없이 전파시킬 수 있습니다.

작은 조직은 단점이 너무 많기 때문에 장점인 다양한 시도와 변화로 커리어을 끌어 올려야 됩니다.

시간을 쪼개서 다양한 시도를 하고 프로젝트에 반영시켜야합니다.

멍하니 주어진 일하다가 10년 내내 같은 일만 하는 분들 많이 봤습니다.

신기술? 도입에 대한 제 견해

제 강좌를 보시는 분들 중 자주 얘기하시는 것 중 하나가.. 회사 프로젝트(php+jquery, spring등) 를 절대 바꿀 수 없다고 하는 것입니다.

당연히 당장 바꿀 수 없습니다.

이중화 구현으로 깨야합니다.

본업을 진행하면서 새로운 기술로 다른 곳(서버, 다른앱)에 나만의 둥지를 만들어 놓고 적당한 시기에 오픈하고 비교합니다.

물론 시간과 노력을 할애해야만 가능합니다..

시간과 노력이 말이 쉽지 재미가 없으면 힘듭니다..

결국 제일 중요한 것은 일에 재미가 있어야 한다는 것입니다.

검색: 구글링

개발자는 구글+스택오버플로 하면 끝난다고들 합니다.

맞는 말이긴 한데 문제는 이해를 하지 않고 주워온 코드들이 스파게티를 이루게 되는 상황을 많이 봤습니다.

구글+스택오버플로 참고는 할 수 있으나 그대로 사용하면 안된다는 것입니다.

언어나 기술도 시험과 마찬가지 입니다.

출제자의 의도가 가장 중요합니다.

예를 들면 출제자는 애플&스위프트고 의도는 값이 없어서 에러가 나던 것들을 사전 방지하는 것입니다.

당연히 제조사, 제작사의 개발자 데이터시트, 문서가 최고의 정답이 나와있습니다.

최고의 정답이긴 한데.. 대부분 영어인데다가 시작부터 데이터시트 보며 공부하면 너무 어렵다는 것이죠.(물론 능력 되는 분들은 기본 문서로도 잘 하심..)

제일 좋은 방법이라 생각하는 것은

구글링 -> 스택오버 예제 -> 내 프로젝트에 적용(되는 것만 확인) -> 해당 내용(클래스등)을 공식 개발자 사이트에서 검색 -> 취합해서 최신화된 코드로 내 코드에 적용

스위프트의 경우 구글 1년이내 검색을 해야합니다. 삭제(디프리케이트)된 기능들이 너무 많습니다..
공식 사이트에서 삭제 된 기능이 뭘로 대체(instead) 되었는 지 확인하는 것이 필요합니다.

화면(UI)과 코어 분리

화면이 들어가는 어떤 프로그램도 마찬가지 입니다.

화면과 로직은 분리해야합니다.

대부분 실수 하는 경우가 UI변경 남발입니다.

예를들어 0~100% 표시하는 프로그레스바의 경우인데

for (int i = 0; i < 100000000; i++) {
    test(i, x); // 비즈니스 로직
    ProgressBar.position = i * 100000000 / 100;
}

윈도우 프로그의 경우 무려 일억번을 다시그립니다. CPU점유율 100%입니다(4코어면 25%)

잘 생각해보면 알겠지만 사용자가 보고 싶은 것은 진행되는 경과 입니다.

일억번의 변화는 눈도 못 따라갑니다.

눈이 따라갈 수준의 UI변경만 있으면 됩니다.

    if (i % 1000000 == 0) ProgressBar.position = i * 100000000 / 100;

이렇게 100번 정도만 표시해도 충분하다 못해 과합니다.

꼭 프로그레스바 UI만의 문제는 아니긴 합니다. 일억번이면 새로운 태스크(thread)를 생성해서 따로 돌려야합니다.

모바일 개발을 하면서 시험을 해봤지만 윈도우처럼 곱게 CPU 자원 내주지 않습니다.

각 가이드라인에 맞는 UI 변경에 대한 설명을 잘 숙지하고 프로그램을 만들어야합니다.

기록

제가 강좌하고 있는 이유는 공헌도 있지만, 가장 큰 이유는 기록입니다.

꼭 블로그나 깃헙에 안올려도 됩니다.

실력이 좋지 못한 것을 부끄러워 할 필요 없습니다.

오히려 아무것도 안하는 게 더 부끄럽지 않을까요?

개발자라면 파워포인트건 노트패드건 최대한 간단히도 정리를 해놓는 것이 좋습니다.(생각보다 투자시간 별로 안듭니다.)

제가 작성한 지난 글들을 보면 거의 막가파식으로 맞춤법 다 무시 글들이 많이 보입니다.

사실 누구나 알고 있지만 실천이 어려운 것이기도 합니다.

귀찮지만 해놓으면 업무 전달, 복습, 나중에 기억을 더듬을 때 당연히 최고입니다.

부수적으로 커리어 운영에도 분명 큰 도움이 됩니다.(이직에 관심이 있다면…)

깃헙 포트폴리오나 npm 모듈 등록 같은 행위가 몇100장 이력서나 자소서 학력보다 훨씬 우대가 됩니다.(물론 저도 없지만..)

개발인원 축소

인력시장이 최근에는 angular, react, vue 같은 프론트만 전문으로 해도 몸값이 상당해졌습니다.

그런데 디비나 백엔드는 점차 감소세라고 합니다.

왜일까요?

과거 플랫폼

예전엔 모든 것을 물리서버에 깔아서 IDC센터에 넣었죠.

예를 들고자 대충 잡은 최소 업무 입니다.

• 로컬서버
• OS, 네트워크 및 서버관리
• 디비(oracle)
• 디비 설치 및 관리(DBA)
• 웹서버(apache)
• 백엔드(php)
• 프론트(jquery)
• 모바일

엄청난 인원이 들어갑니다. (사실 위에 열거한 내용보다 사실 더 많은 일이 있겠죠)

디비의 경우 운영이 더 중요하다고 생각합니다..(백업과 튜닝)

최근 솔루션

제가 강좌를 진행하는 NEMV(Node.js Express.js MongoDB, Vue.js)를 예를 들어봅니다.

• 로컬서버 : cloud 서버
• OS, 네트워크 및 서버관리 : cloud 방화벽 및 세팅
• 디비(Mongo)
• 디비 설치 및 관리(DBA) : cloud db관리
• 웹서버(node.js) : node 대체
• 백엔드(express.js)
• 프론트(vue.js)
• 모바일

클라우드가 전문인력을 완전 대체하긴 어렵지만 그럭저럭 대체할 수준 입니다.

디비의 경우 나름 주기 스냅샷 롤백 같은 것을 지원해서 적당한 규모에서는 DBA보다 클라우드 프로등의 상을 이용해서 지원(SLA)을 받는 것이 좋다고 생각합니다.

백엔드에 요청해서 프론트나 모바일(+푸쉬)의 내용에 변화를 주는 수준입니다.

파이어베이스 기반

파이어베이스 기반으로 바꾸어 보면

• 로컬서버 : firebase
• OS, 네트워크 및 서버관리 : firebase
• 디비(Mongo) : firebase
• 디비 설치 및 관리(DBA) : firebase
• 웹서버(node.js) : firebase
• 앱서버(Tomcat) : firebase
• 백엔드(php) : firebase
• 프론트(vue.js)
• 모바일

주의할 것은 파이어베이스 디비 사용은 적당한 양만 가능한 것 같습니다.(읽고 쓰는 비용이 어느 수준을 넘어가면 장난 아닌 금액이 나옵니다.)

프론트에서 백엔드 없이도 파이어베이스디비에 저장된 값을 읽을 수 있기 때문에.. 프론트만 하면 됩니다.

게다가 자주 쓰며 복잡한 기능이 패키지형태로 들어있습니다.(예를들어 누구나 고민하는 로그인 로직이 간편하고 안전하게 구현이 됩니다..)

물론 sdk가 답답하면 파이어베이스 호스팅으로 자유로운 백엔드를 구성(노드6,8)할 수도 있습니다.

이처럼 IT공룡들이 과거 복잡했던 구성들을 손쉽게 만들었다는 것입니다.

웹솔루션의 경우 소스코드 올려놓고, 디비 연결 따위 관심 없고 “쓴다 읽는다” 만 남는 것입니다.

파이어베이스가 성능이 어떤 지는 잘 모르겠으나 아무튼 프론트와 모바일의 생산성만 있으면 구현은 되기 때문에..

프론트가 강세인 이유인 것 같습니다.

모바일 개발을 시작하게 된 계기

모바일앱은 외주를 의뢰했습니다.

제가 해야할 일은 백엔드 서버에서 노티(fcm푸시) + 데이터만 제공(RESTful api)해 주면 끝입니다.

규격서를 만들어야 되는데 앱 입장에서 정확히 뭘해야 되는지 판단이 안되어서 직접 만들어봤습니다.

사실 웹개발을 하게된 계기도 외주 의뢰했다가 어떻게 돌아가는 것인지 파보다 하게된 것이죠..

프로젝트 성격상 안드로이드 먼저 해야함에도 굳이 iOS 먼저 한 이유는 집구석에 있는 기기들이 죄다 애플기기였기 때문입니다.

간단한 목표부터 달성해보기

앱개발은 사실 한가지 이유가 더 있는데..

아빠는 뭐하는 사람이냐고 묻는 딸에게 프로그래머라는 직업을 설명하고 보여주고 싶은 마음이 들었습니다.

앱스토어에 올릴 수준은 못되지만 “구구단 문제 풀이앱” 은 레이블, 텍스트필드, 버튼 정도면 정말 간단히 몇시간에 뚝딱 만들 수 있죠..

만드는 모습을 보여주고 실제 동작해서 써보니 확실히 프로그래머라는 직업을 이해를 시켜준 것 같아서 뿌듯합니다.

게임을 만들어 주면 더 뿌듯할텐데 실력이 안되어서 아쉽긴합니다~

신규언어를 익히며

스위프트, 코틀린 두개를 거의 동시에 익히고 있습니다.

익힌다는 말이 무색할 정도로 생기초만 하고 있지만..

역시 제가 구현할 앱이라면 좀 불편하겠지만 생기초만으로 충분히 무언가 만들 수 있다는 생각이 듭니다.

안드로이드의 경우 자바로 간단한 앱을 몇개 만들어 본 적이 있는데..

코틀린으로 만들어보니 비약적으로 코드가 줄어드는 것을 확인할 수 있었습니다.

아이폰은 완전 처음이라 오브젝트씨와 비교를 해볼 수가 없네요..

컴파일 언어이기 때문에 당연히 자스(자바스크립트) 보다 편의적이진 못하지만.. 예전 언어들(자바, C등) 보다는 많이 진보되었다는 것을 체감할 수 있었습니다.

강좌에 대해

기록과 학습을 위해 모바일 강좌와 현재 프로젝트 진행을 같이하는 것이 목적이었는데 하다보니 꽂혀버려서 프로젝트용 앱이 벌써 완성 되어버렸네요.

스위프트 ios 개발 시작한지 약 2주만에 조잡하고 단순한 앱을 완성했습니다.

이제는 코틀린 안드로이드 준비하며 코틀린 들어갈 준비중입니다.

개발한 것을 슬슬 정리해 봐야할 시간이 왔습니다~

결론

개발자는 변화를 두려워하면 안됩니다.

작은 목표부터 새우고 차근차근 하면 언젠가는 할 수 있습니다.

시대의 개발 리듬에 몸을 맡기고 즐기세요~