최근 개발 리듬에 맞춰서 이것저것 개발해본 사용기 올려봅니다~
너무 개발덕후 냄새가 나는 글이될 것 같아서 최대한 기술용어나 영문을 피해서 작성해봅니다..
클리앙에 개발자분들이 많으셔서 한번 남겨봅니다~
개발 동향
제가 생각하는 최근 개발 트렌드는 패턴(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주만에 조잡하고 단순한 앱을 완성했습니다.
이제는 코틀린 안드로이드 준비하며 코틀린 들어갈 준비중입니다.
개발한 것을 슬슬 정리해 봐야할 시간이 왔습니다~
결론
개발자는 변화를 두려워하면 안됩니다.
작은 목표부터 새우고 차근차근 하면 언젠가는 할 수 있습니다.
시대의 개발 리듬에 몸을 맡기고 즐기세요~
그래서 더 어려운것같아요
산으로가서 제목도 적당한 걸 못찾아서 좀 이상해져버렸네요...
정말 스위프트는 욀케 업데이트를 하는지 ㅡㅡ;;
플랫폼들은 결국 유저(이때 유저는 개발자)를 편하게 해주기 위해 나온 기술들이고
왜 편하냐를 느끼려면 결국 깊게 알아야 되는 것 같습니다.
현업이 아니라서 수박 겉핥기였지만요...
그에비해 임베디드는 너무 정체되어있어서...내가 너무 뒤쳐진거 아닌가 하는 불안감이 크네요.
아시죠? 이제 늦었다고 생각할 때가?
두려워할 필요는 없고, 이런 기술들이 별거가 아닌게 아니다 정도로만 받아들이면 됩니다.
사장되는 기술도 많구요 유행하면 공부하면 됩니다.
결국 많이 쓰는 기술/플랫폼을 알아야 되는거고, 많이 쓰는 기술은 어렵지 않습니다.
지속적으로신기술에 대한 관심만 놓지 마세요 :)
이런건 어떻게 하면 얻을 수 있는
통찰력 + 글솜씨입니까?
감사하면서도
배우고싶네요. 하........
개발자는 아니지만 잘 읽었습니다:)
고객이 원하면 스파게티든 하드코팅도 합니다.
잘 하는 거 하나면 됩니다.
swift가 자주 업데이트 되는 탓도 있겠지만, 서드파티 라이브러리들 지원이 잘 되는지 신경 써야겠더라구요.
전 안드 공부 하고 싶은데 시간이 없다는 핑계만 대고 있는데.. 대단하십니다
스위프트는 2,3주 써본게 전부인데 역시나 자주 업데이트 되며 문제가 생기는군요...
매번 하다 때려치지만 오늘도 다시 블로그를 만드네요..ㅎㅎ
이 문구에 감탄을 금치 못하고 갑니다. 마치 친구를 다루시는듯한 표현이네요.. 많이 배웠습니다!
스크랩 해야 겠어요 ^^
도움이 되었다니 다행입니다~
모두 즐거운 개발하세요
/Vollago
가끔 https://d2.naver.com/helloworld 같은 곳만 봐도 동향 파악에 도움이 됩니다~
제가 가장 존경하는 개발자는 자신의 경험을 공유할 줄 아는 개발자입니다.
속도..생산성도 중요하지만 결국에는 가독성좋은 코드가 사랑스럽더라구요.
오픈소스 쓰면 편한데 os버전업과 동시에 지원이 끊기면 답이없어 한땀한땀 수작업하는 방망이깎는 1인이 여기있어요.
저도 한참을 윈도우 프로그램(델파이 or 씨빌더) 제작이 메인이었는데요..
다른 툴이나 플랫폼은 저도 생각도 못하던 시절이었어요
늘 가독성 좋게 만들려고 매번 노력을 기울였죠~ 나름 다음 플젝에는 속도도 조금씩 붙었고요..
다행히도 저는 앱들이 일반인용이 거의 없어서.. 요청사항이 작고, 좀 실수해도 크게 문제될 것이 없는 플젝들만 해서 여유가 있었던 것 같아요..
그런데 리스크가 큰 앱이라면 신경이 곤두서서 여러가지로 힘들 수 있을 것 같아요..
감사합니다.
경력 개발자 뽑을 때는 결국 꼭 요구하는 언어를 중요시 하더라구요.. + 서비스 경험은 기본
쩝.. 업무 외로 공부 백날 해봐야 실제 필드 경험 없으니 다른 언어로 바꿔보고 싶어도 마땅치가 않네요
7년동안 한 제조업에서 MFC 한 우물만 파서 다른것 좀 해보고 싶은데 여의치 않네요..
초반 진입장벽만 넘어서면 확 다른 세계가 올 수 있습니다~
항상 궁금한게 있는데 python이 시스템 개발 분야에서 쓰이는 경우가 있나요?
요새 python의 단점을 보완하는 julia라는 것도 뜨고 있던데
엄청 씁니다. 자바 스크립트도 엄청쓰구요
심지어 게임 개발에도 씁니다.
IOT 디바이스 개발에도 쓰구요
julia 라고 말씀 하시는걸로 봐서 혹시 매트랩같은데서 파이썬 사용하시나요?
전 개발자라서 잘 모르지만, 비 개발자들 사이에서도 수학같은거 용으로도 많이 쓰더라구요
이쪽 방향에 대해서 어떻게 생각하세요?
감사합니다.
좋다는거 다 갔다가 써서 만들어봤습니다.
node.js mongodb express Graphql react
저는 국내 웹개발자분들 저거 다 아는줄 알았는데
의외로 잘모르는 사람이 많더군요...
모바일은 모르겠는데 웹쪽은 엄청 고인물이란걸 느꼈습니다
저도 일단 좋다는 거 다 갔다 써보고 검토후 프로젝트에 맞는 후보 나눠서 추출..
저같은 경우 웹쪽은..
node vs python vs go -> node
express vs koa -> express
react vs vue -> vue
곧 또 바뀔테지만 새로 뭐 해도 그렇게 러닝커브가 크지 않게 만드는 것 같아요 요새는...