긴 글이지만 대상자가 프로그래밍을 하려는 들 사람인 만큼 이정도 긴글에 대한 피로도는 인내로 넘어갈 수 있을 거라 믿습니다.
저는 아이폰 앱스토어와 맥앱스토어에 몇개의 앱을 출시하긴 했지만 취미개발수준으로 남아있는 비전공자입니다. 실력이 비루하다는 소리죠 (빈수레)
그래도 전기/전자공학을 하며 C/C++ 언어 수업을 들었으니 비전공자라기보단 관련공자(?)라 하겠습니다 (그래봤자 시작할때 goto문과 for문 밖에 기억에 없었어요)
지금은 몇개 언어와 프레임워크를 다루고 있습니다. 이런 글을 쓰는 건 제가 처음 프로그래밍을 익히려든 때의 고충을 누군가 여전히 겪고 있을 거라 생각이 들어서 언젠가 써보고 싶었습니다.
이 글은 실용적이지 않겠으나 첫 프로그래밍을 경험하려는 혹은 하고 있는 사람에게 앱 프로그래밍 학습에 대한 개괄적인 안목을 갖을 수 있길 바라는 마음에 작성합니다.
첫 공부를 하면서 자신이 어디를 향해가고 있고 어디즘에 있는지 아는 것은 좋은 것이니까요. 미지의 세계에 내던져져도 나침반이라도 있으면 마음의 의지가 되는 것과 같죠.
응용 프로그래밍 분야
앱은 스마트폰 앱만이 앱인 것은 아닙니다. Application의 약자 App이죠. 이 애플리케이션은 한국사람들은 ‘어플리케이션’이라고 하곤합니다. 그래서 ‘어플’이라고도 하죠. (왜 ‘어’발음인지…)
애플리케이션은 우리말로 ‘응용 프로그램’입니다. 네, 응용 분야입니다.
-응용분야 프로그래밍
-시스템분야 프로그래밍
-임베드분야 프로그래밍 (하드웨어)
-연구분야 프로그래밍
-데이터과학 및 기계학습 분야 프로그래밍
등등 딱부러지게 나누진 못해도 핵심은 앱개발자는 ‘응용’할 뿐인 프로그래머라는 겁니다.
아마도 대부분의 프로그래밍 입문자는 ‘응용 프로그램’을 만들기위해 입문할 겁니다. 컴퓨터용이든 모바일용이든 Web 브라우저용이든 말이죠.
컴퓨터에서 돌아가는건 ‘Desktop 애플리케이션’,
스마트폰같은 핸드헬드 기기에서 돌아가는 건 ‘Mobile 애플리케이션’
서버에서 돌아가는 건 ‘Web 애플리케이션’
게임도 결과물로 치자면 앱이죠.
눈에 보이고 익숙하게 사용해본 건 저런 애플리케이션이기 때문에 그걸 위해 입문하는게 보통인거죠.
요새 핫한 AI 프로그래밍 예를 들자면 ‘AI 프로그래밍’이라고 다같은 분야가 아니란 사실입니다.
연구분야는 AI가 합습하기위한 머신러닝/딥러닝 논리를 만들고 모델을 학습시키고 발전시키죠. 근데 이쪽은 유의미한 결과를 내려면 돈이 많이 들겠죠 (저역시도 쥐뿔 모르고요).
배워서 취업하려고해도 관련전공 학력이 우선되는데 연구분야는 학사 레벨로는 연구 안시켜줄겁니다. 이력서도 안받아줘요.
하지만 응용프로그래밍 분야에선 그 수준이 아니라 더 쉽게가능합니다.
예를들어 ChatGPT를 만든 OpenAI는 자기네 서버에 학습모델을 올려두고 API를 제공합니다. 우린 그 API 사용료를 내고 이미 학습된 AI 모델이 내주는 결과를 가져다 쓸 수 있습니다. (혹은 공개된 다른 AI모델 사용)
API에 입력하고 나오는 출력만으로 그럴싸한 AI모바일앱/웹앱을 만들어 서비스합니다.
이런 경우도 과연 AI프로그래밍이냐?는 프로그래머들끼리의 논쟁 일 뿐이고, 일반인시점엔 결과물만 볼 수 있기때문에 이거나 저거나 그냥 다 AI프로그래밍으로 보일 뿐예요.
파이썬이 AI프로그래밍에 좋다고하죠? 그러니까 누군가가 AI 앱 개발을 목표로 첫 프로그래밍을 공부 할 때, 원론적인 연구분야 AI프로그래밍으로 입문한다면 원하는 결과와 배우는 것의 괴리감이 매우매우 클겁니다.
모바일 앱을 만들고 싶은건데 파이썬배운다? 기술선택을 잘 못하는 겁니다. 어떻게든 AI를 모델도 학습시키고 했다쳐도 앱 개발은 따로공부하고 따로 만들어야합니다.
모바일앱개발이 목적이면 모바일앱 프로그래밍을 먼저 익히는게 좋습니다. 아쉽게 파이썬으론 적합한 프레임워크가 없습니다.
다만, AI프로그래밍에도 중간지점은 있습니다.
이미 어느정도 학습된, 학습방식정도는 프로그래밍해둔 걸 써서 추가학습시키는 AI프로그래밍 정도는 연구분야보다는 더 쉽게 할 수 있는데, 이정도는 다른 언어에서도 프레임워크로 제공합니다. 그거 가져다 하면됩니다.
프로그래밍 학습에 가장 중요한 두 가지 분류
첫 응용프로그래밍을 학습하기위해 알아야 할 중요한 두가지가 있습니다. 언어와 프레임워크입니다.
-언어(문법) & 라이브러리
-프레임워크 & 플랫폼
(라이브러리는 어디끼는 게 좋나 애매하긴하지만 프레임워크와는 구분을 하였습니다.)
더 세세히 나누자면 학습 장벽이 1) 비객체지향문법, 2)객체지향문법, 3)프레임워크사용, 4)프레임워크를 위한 제반지식 이런식으로 나누어 볼수 있겠습니다.
정석적으로 하자면 언어를 배우고 목적하는 프레임워크를 배웁니다. 하지만 둘을 동시에 할 수도 있습니다.
가장 효율적인 건 인내심이있다면 정석대로 하는 것이고 , 초기에 흥미를 더 오래 지속할 수 있는 건 목적하는 프레임워크로 언어를 동시에 배우는 것인데(물론 좋은 인강으로 시작한다는 전제에서) 처음부터 불필요한지식이 너무 많이 달라붙게되고 언어에대해 깊이들어가기 힘든경우가 많습니다.
하지만 중요한 사실은 뭐가되었든 ‘언어’ 문법을 공부해야한 다는 것입니다.
거꾸로했다간 6개월 걸릴거 2년 걸릴 수도 있습니다.거꾸로 시작한 사람도 결국 언어를 이해하지못해 때려치고 그 필요성으로 언어공부를 진지하게 시작하는 사람도 있습니다.
이편은 그래도 자기가 왜 언어공부를해야하는지, 언어가 차후 프레임워크를 다룰때 어떻게 작용하는지 정도는 알고합니다. 앞서 해봤으니까요. 근데 그해봤던 시간 비용이 크죠. (대충 인터넷세계 둘러보니 게임개발 독학하는 지망생들이 그런 경향을 많이 보이는 것 같습니다.)
플랫폼 또는 프레임워크 종속의 언어
플랫폼과 프레임워크는 아래에 다루겠지만,
대부분 언어의 실상은 어떤 플랫폼이나 프레임워크를 위해서 존재하는 언어라는 말이 과언이 아닐정도로 그 분야 아니면 쓸모가 없어요.
swift는 오픈소스지만 애플의 플랫폼 앱개발을 위해서 말고는 쓰는 사람이 없고,
코틀린은 안드로이드 앱개발에만 쓰이고
Dart는 플러터로 크로스플랫폼 모바일 앱개발로만 인기일뿐입니다.
이런 언어로 서버개발도 할 수있다는 말이 돌아봤자 말그대로 “할 수 있다”는 것뿐입니다. 널리 쓰인다는 것을 의미하진 않아요.
swift로 서버에서도는 웹애플리케이션을 만들려고 공부하는건 그냥 선구자이든가 자아실현이나 호기심목적의 멋진(?) 영역에 지나지 않고 성능과 신뢰성 검증도 안되어있죠.
이것은 개발커뮤니티(오픈소스, 써드파티 라이브러리, 블로그, 깃허브, 유튜브,세미나 등등)가 충분한가의 문제입니다.
하다보면 공부할게 많고 해결해야할 문제가 많은데 아무도 안쓰는건 학습자료, 문제해결을위한 자료가 턱없이 부족하고 인터넷의 도움도 없이 문서보면서 자기혼자 알아내야합니다. 초보자에겐 불가능한 영역이죠.
상대적으로 언어선택이 자유로워 보이는 플랫폼은 서버(백엔드) 프로그래밍입니다. 서버프로그래밍은 되려 언어선택에 고민이 많아지고 한편으론 원하는걸 쓰면되기도합니다.
그래서 서버 개발은 춘추전국시대고 변화도 빠르고 새로운것도 자주나오며 애플이나 구글같은 주체자의 부재도 큽니다. 내 서버 내가 쓰니 자유롭죠.
웹 벡엔드는 누군간 자바로만들고, 누군가는 자바스크립트 , 누군가는 Go언어… 파편화되어있습니다.그런데 그마져도 각자의 프레임워크에 종속되어있습니다.
결국 목적에따라 널리쓰이는 프레임워크를 선택해야하고 거기에 종속된 언어를 다뤄야합니다.
그러니까 정확히는 자기목적에 가장 적합할 프레임워크를 고르는 거고 어떤언어인가는 거기에 따라 올 뿐인거죠. 그러니 언어의 기능보다 프레임워크의 기능이 목적에 적합한지 그리고 그 커뮤니티의 규모가 충분한가가 중요하단 겁니다.
예로 애플의 네이티브 프레임워크를 선택하면 swift로 하는거고, 크로스를 하기로했고 그중 플러터를 선택했다면 Dart인거죠.
언어공부
프로그래밍 언어 기초 공부는 영어공부의 문법공부와 같은 포지션입니다.
문법만 공부했다고 영어를 쓸 수 있는 건 아니지만 반대로 천대해도 영어를 못합니다. 대부분의 성인은 그래요. 문법공부없이 했다면 그건 진짜 언어 재능이 있는겁니다.
갓난아기면 3년되어서야 말을 하기 시작하는데 성인이 갓난아기 따라하려다간 말한마디 못하는 1년을 보내기도 전에 포기하고맙니다.
하지만 성인은 문법공부하면 한 달 만에 여러 단어를 읊조리기 시작해서 3개월이면 기본 인사말은 나누게됩니다. 그게 문법공부를 통한 효율이죠.
이게 문법만 공부했다고 되는건 아니고 반복숙달하는 과정을 따로 거치게 되어있습니다.
프로그래밍도 마찬가지입니다. 언어공부는 문법공부에 지나지 않지만 중요하고 언어기초 학습 단계에는 단지 문법을 공부하는 것에 지나지 않습니다. 목표하는 프레임워크단계에서 숙달하든지 수많은 예제로 익혀야합니다. 그러니 언어기초공부 만으로는 실제 할 수 있는 건 아무 것도 없다고 생각하면 됩니다.
많은 언어책, 인강을 보면, ‘콘솔’이라고 하는 까만화면에 글자를 출력하고 거기서 입력하는 식으로 가르치는데 이 단계에서는 그게 할 수 있는 전부예요.
콘솔 출력으론 아이폰 앱을 만들 수도 없고, 웹사이트를 만들 수도 없습니다.
사실 “콘솔앱” 프로그래밍이 따로 있습니다. 그걸 위해선 유효하죠. 하지만 대부분의 입문자는 그게 목적이 아니거든요. 결국 언어 책 한 권, 인강하나를 통해 문법을 다 이해해도 자기목적은 전혀 이루어지지 않는다는 걸 아셔야합니다.
좀 두꺼운 언어책은 900페이지, 그것도 이해하려면 실습 따라해보면서 정신바짝차리고 봐야할 방대한 페이지예요. 그런데 당장은 아무것도 이룰수 없는 공부를 그만큼 해야해요. 그래서 인내가 필요합니다.
이단계에서 포기하는 사람이 많습니다. 어렵고, 오래 공부해도 할 줄 아는 건 없고. 콘솔창에나 출력되는 걸로 뭘 할 수 있다는 건지 모르겠고 지겹죠.
그런데 말이죠, 목적은 ‘문법’을 익히는 거지 실용이 아닙니다. 아직 여러분은 반복숙달을 하지 않은거예요.
프로그래밍 공부에서 언어 문법공부가 차지하는 학습량은 제 뇌피셜로 10분의 1도 안됩니다. 뻥좀 섞어서 100 분의 1 입니다.
반대로 그 열배를 공부하고 앞으로도 계속 공부해야할 것 중 일부가 프레임워크입니다.
프로그래밍을 배우려들면 언어공부를 하면서 점검해볼 수 있는 부분이 ‘적성’인데, 내가 과연 이런 공부를 하는 인내심을 지속적으로 발휘할 수 있는가?라는 점이죠. 그게 프로그래머의 자질이라고 전 생각합니다.
코드를 이해하는 것보다 더 중요한게 그 공부습관과 인내라고 생각해요. 앱개발자는 머리가 똑똑해서 프로그래머되는게 아니라 책상에 몸을 앉히는 엉덩이가 프로그래머로 성장시킵니다.
하지만 언어공부 단계에서 안맞는다고 생각해도 벌써 포기하긴 이릅니다. 프레임워크 학습에 들어서면 자신의 목적에 가까운 프로그래밍을 배우게되면서 재미있기도 하니까요. 그런 공부가 재밌어지는 반전이 기다리기도 합니다 (저는 그랬어요).
프로그래밍 포기하는 사람이나 영어포기하는 사람이나 원리가 똑같아요. 문법공부만 해놓고는 어렵다면서 사용을 안하니까 까먹고 마는 겁니다. 그마져도 쓸줄모르는단계에 완벽히 이해하려드니까 어려운거지 코딩이든 영어든 깝깝하겠지만 목적에따라서는 쉬운부분만 쓸 수도 있습니다. 해외 관광지가서 밥사먹으려면 몇몇단어만 쓰면되고,영어토론참석하려면 정확한 의사전달을 위해 어려운문법에도 통달해야 하는것 처럼요.
객체지향 – 언어공부의 가장 큰 장벽
객체지향 언어 한정으로,
프로그래밍 초보들에대한 조언으로 C언어를 먼저해라, 할필요없다 말은 많은데 전 “굳이?”라는 생각을합니다. 그러면서도 한편으론 “C언어는 쉬우니까 시간과 인내심이 있으면 까짓거 해라” 라는 입장입니다.
진짜는 객체지향이니까요.
모든 언어의 책 앞에 나오는 변수, if, for문 같은 첫부분은 바보아니면 다 알아듣습니다. 기초자료형도 그렇고요.
하지만 클래스,인스턴스 나오고 상속하고등등 객체지향 개념이 시작되면 어려워집니다. 거기서 델리게이트며 이벤트 나올때 대부분 이해하기를 포기할 지도 모릅니다.
C언어 문법이 쉬운 이유기도한데 C언어에는 객체지향이 없기때문입니다. 한 편으로 객체지향 언어가 목표라면 굳이 C언어로 선행학습을 할 필요없는 이유기도 합니다.
어차피 C언어책에 초중반에 나오는 많은 것들을 객체지향언어책에서도 다 다룹니다. 메모리 주소를 직접 다루는 포인터정도는 C언어책이 더 잘 다룰 뿐이죠.
포인터도 사실 그 응용 예제가 천차만별 어려운거지 기본개념은 쉽습니다.. for문 사용법은 쉬운데 그걸로 별별 *을 그려보라는 예문을 만나면 머리가 멈추는 거랑 같을 뿐입니다.
다만 C언어는 공부할 수있는 자료가 넘쳐납니다. 자료구조나 알고리즘 학습의경우도 C언어로 많고요. 고전자료도 많습니다. 그림이며 도식까지 잘 되어있는 배우기 좋다고하는 기초책이나 자료가 많아요.
언어공부 단계에서도 반복숙달해 볼 수 있는 수 많은 예제가 넘치게 있습니다. 그래서 여러예제로 연습할 시간만된다면 C로 입문하기 좋아요. (요샌 그 포지션이 파이썬이라고들 하더군요)
그런데 c언어책 한권 읽고 만다? 그정도 선행학습은 안해도 됩니다.
프레임워크로 넘어가면 한동안 GUI다룰거라 책에서 처럼 어려운 연습문제는 한동안 오래 만날일 없을 공산이 큽니다. 그런 머리많이 돌려야하는 어려운 언어 연습문제는 일단 언어에 익숙해진 뒤에 다시봐도 됩니다.
객체지향부터는 논리적으로 개념적으로 어려워지는데 언어공부단계의 책이든 인강이든 코드가 실용적이질 못합니다.
왜냐하면 그 챕터를, 그 문법을 이해시키기위한 예제코드일 뿐이기 때문입니다.
웬만하면 언어공부 단계에서 이해하고 넘어가길 권장하지만, 사람에 따라서는 프레임워크 단계에서 직접 실용적인 걸 써보면서 이해하는 편이 이해가 더 잘 될 수도 있습니다. 객체지향은 목적프레임워크 공부할 때 실용적인 예시코드들이 언어책에서보다 더 많으니까요
플랫폼과 프레임워크
언어공부를 마쳤다면 다음단계로 자신이 목표하는 프레임워크입니다. 이것은 ios앱개발로 치면 xcode 깔고 아이폰 시뮬레이터에 UI를 제어하는 단계입니다. 서버백엔드 아니고선 초심자 대부분 GUI앱개발이 목표다보니 눈에보이는 UI프레임워크를 통한 개발로 시작 하게됩니다(ios는 UIkit/swiftUI 프레임워크).
거기가 진짜 프로그래밍 언어숙달, 자기 목적을 이루기위한 공부가 시작됩니다. 그리고 이젠 ‘앱이 이렇게 만들어지는 구나’ 이해할수 있죠. 자기가 하려던걸 하니까 이제 재밌습니다.
플랫폼이란 소프트웨어 개발 및 실행에 필요한 하드웨어, 운영 체제, 프로그래밍 언어, 라이브러리, 도구 등의 통합환경입니다.
플랫폼이 iOS 라고 한다면, 이를 위한 개발환경은 보통 여러 프레임워크로 이루어져있고 프레임워크의 집합이 플랫폼의 일부를 형성합니다.
iOS에서 UIKit도 하나의 프레임워크이고 SwiftUI도 별도의 프레임워크이며 Foundation, ARKit등등 여러 프레임워크가 통합되어있습니다.
프로그래머는 그 프레임워크들을 다뤄 해당플랫폼의 기술을 이용하게되어있습니다. 그것이 무엇인지, 어떻게 쓰는지 알기위해 플랫폼/프레임워크 제공자가 내주는 문서를 공부해야합니다 (프로그래밍가이드, API 레퍼런스).
그리고 그양은 어마어마하게 많으며 자기 전문 분야에따라 필요한 것만 익히게됩니다. 공통적으로 쓰이는 UI만으로도 구현모습이 끝도 없기때문에 방대하죠.
프레임워크 기초사용법을 알기 좋은 건 먼저 ‘라이브러리’를 써보는 겁니다. 둘은 핵심을 제외하곤 API사용한다는 것에서 모호할 정도로 같으니까요.
언어공부 단계에서 부터 라이브러리를 쓰게 되는데 가장 기본이 되는 건 C언어 표준 라이브러리로, 다른 언어에도 그와같은 기본기능을 갖춘 라이브러리들이 있습니다. 입문단계에서 언어공부를 할때 이미 기본 라이브러리와 함께하는 예제들을 만나게됩니다. 저자가 그것이 라이브러 임을 소개하지 않더라도 말이죠. 보통, 라이브러리에대한 소개는 언어 책 중반이나 후반에 나오기 마련입니다.
하나의 프로젝트에서 여러 라이브러리를 쓰는 것처럼(이미 기본포함이거나 써드파티를 추가하거나), 플랫폼에는 이런 저런 프레임워크가 통합 되어있는 거죠.
프레임워크에서 가장 핵심적인 개념 그리고 라이브러리와는 다른점은, 제어역전을 부르는 ‘정해진 규칙’입니다. 제공자(제작자)가 정해둔 이 규칙에는 방대한 문서가 포함됩니다.
라이브러리는 언어공부를 할 때처럼 아무때나 호출하면 되지만 프레임워크에서는 정해진 규칙을 따라야하는, 프레임워크가 프로그래머(내코드를) 를 제어하는 제어역전이 일어납니다. 그 규칙을 따르지않고선 해당 프레임워크를 위한 애플리케이션을 만들 수 없습니다.
사실 언어공부단계에서도 기본 프레임워크로 개발환경이 시작되는데, 많은 C계열 컴파일 언어공부를 하면 가장 처음 만나는 그 규칙이 main()함수입니다.
‘모든 코드의 시작은 static의 main이란 이름의 함수에서 시작한다’
라는 규칙에 따라 거기서부터, 보통 그 안에서만 언어문법을 배웁니다. 기본프레임워크의 다른 규칙은 문법교수에 필수가 아니니까요.
그리고 프레임워크에서 알아야 할 게 라이프사이클과 메시지콜백입니다.
애플리케이션의 라이프사이클(생명주기)에서 각각의 상태 (시작, 종료, 백그라운드 진입, 포어그라운드 활성등)에따른 이벤트를 프레임워크는 ‘메시지’로 전송하거나 델리게이트로 콜백을 호출합니다.
프로그래머는 그 이벤트 메시지를 받아 그때 어떤 동작을 할것인가라는 정해진 콜백함수를 작성하게됩니다.
이 특징은 모바일 앱개발에서는(iOS UIKit에서는) 테이블뷰 API를 다룰때 실시간으로 아주 잘 나타납니다.
그런 프레임워크의 메시지 제어에 나의 코딩이 끌려다니는 코드가 작성되는 것이 기본구조입니다. 이를위해 객체지향 언어는 공부때 델리게이트/이벤트부분을 이해하고 넘어오는게 좋습니다.프레임워크의 코드는 안보여도 같은언어로 제작한거다보니 그런원리로 동작하니까요.
어쨌든 응용프로그래밍 입문자는 플랫폼이 제공하는 프레임워크를 사용하면서 자기 목적에 맞는 프로그래밍을 이해하게 됩니다. 즉, 프레임워크 공부가 진짜 프로그래밍 공부라는 것입니다.
프로그래밍은 언어하나 잘하면 다른 언어 쉽게 배운다고하죠?
실제로 제 경우 새로운 언어는 언어책 사다가 정독하면 길게잡아도 한달이면 그 언어의 문법을 뗍니다.
대부분 경력 프로그래머는 그조차도 필요없을때가 많은데 비슷한 언어는 인터넷에서 대충 이 언어에선 이런부분은 어떻게 작성되는지 비교하는 글 검색해보는 정도로 익힐수도 있습니다. 이를 위한 언어:언어 비교 cheat sheet라는 표도 나돌아 다닐 정도예요.
그런데말예요. 언어를 안다는게 프레임워크를 다룰 줄 안다는 의미는 아닙니다. 기존 프로그래머도 새로운분야로 넘어가려는게 결코 쉽지 않습니다.
새로운 분야가되면 새로운 프레임워크와 새로운 규칙, 새로운 패러다임, 그분야에서 쓰이는 개발방식, 디자인패턴등이 달라집니다. 공부해야 할 양이 거기서 많다고 했죠? 그래서 쉽게쉽게 전향할 수 없습니다.
C#과 닷넷이 가장 대표적인데 C#하나로 윈도우프로그램도 만들고(WPF), 모바일앱도 만들고(MAUI) 게임도 만들고 (유니티/고도엔진) 합니다.
언어만으로 쉬웠다면 세상 모든 개발은 C#이 통일하겠죠. 하지만 전혀요.
게임개발자는 닷넷코어(웹앱개발) 개발을 바로 할 수 없습니다. 배우고 잘쓰려면 많은 시간이 걸려요. 둘은 개발방식부터 프레임워크가 완전히 달라서 통하지 않습니다.
예를들어 전혀모르는 웹개발로 전향한다치면 닷넷코어보다는, 그냥 한달안에 js 언어 공부 해버리고 남들많이쓰고 커뮤니티가 무르익어있는 node.js 프레임워크 다루는게 사정에 따라선 더 나을 수 있습니다
실상이 이렇다보니 프로그래머들이 여러언어를 쓰게 됩니다.
이전단계와 다음단계사이의 아리송한 경계
제가 가장 힘들었던 부분입니다. 한 쪽에서 다른 쪽으로 넘어가는 부분의 지식을 연결시키는 건 어려운 일입니다. 아마 어느분야를 공부해도 같을 겁니다.
제가 젊은시절 전기/전자공학을 할 때만도 저는 그때도 논리회로를 다루며 기계어 쪽을 다뤘고 CPU쪽에 가깝게 있었습니다.
전 그때도 ‘개발’을 하고 싶었습니다. 어릴적 꿈이 발명가였는데 지금도 이어지고 있는 셈이죠.
이렇게 CPU/GPU에 (기계어에) 가까운쪽이 ‘저수준’이고 언어는 ‘저급언어’로 분류됩니다. C언어는 고급언어죠.
그리고 당시 C언어를 하려고 해봤습니다. 달랐죠. 이걸로 뭘 어째야 컴퓨터로 제가 가진 MCU를 제어할 수 있을지 몰랐습니다. 당시엔 인터넷도 그렇고 초기단계였고 영어도 전혀 할 줄 몰랐고 가르쳐줄 사람도 없었고.. 컴파일러도 비쌌고 그 경계를 연결시키지 못했기에 결국 포기했습니다.
지금은 하드웨어 프로그래밍 접근하기도 참 싸고 쉬워졌죠.
제가 앞서 프로그래밍 학습에 중요한 가장 큰 두 분류로 나눈 이유가 이겁니다. 언어학습 측면에서 문법공부와 프레임워크 사용은 그 단계 구분으로 나누어진겁니다.
문법만을 위한 공부 vs 실제사용을 통한 반복학습
응용프로그래밍 처음 학습자는 최소한 그 경계가 있다는 것을 인식하고는 있어야합니다. 전자만으론 아무것도 할 수 없다는 것, 후자를 통해 익숙해지지 않으면 공부한 언어문법도 까먹게 된다는 것.
그 경계의 인식이 학습의 ‘나침반’이 됩니다.
“아 이쯤되면 문법을 좀 알것같으니 나중에 다시 공부하더라도 이만 넘어가자”
“이 설명은 아무리봐도 책을 봐도 모르겠다. 다음단계에 좀더 이해할만한 예제가 있으면 그때 다시봐야지.”
“이것만으로도 재밌는데? 좀 더 깊이 공부해볼까?”
또는 여유를 가질수도 있습니다
기초단계에선 언어공부만으로 뭘 할 수 없다는 거, 다음단계가 있고 그걸 위한 초석이라는 걸 아니까 초조해하지 않고 지겨우면 잠시쉬고 머리식힙니다.
판단과 행동. 목적을 이룰수 없는 지겨운 언어문법공부에서 스스로 결정할 수 있습니다.
제가 처음 프로그래밍을 공부할 때 국내에서 자료가 별로 없는 언어였는데 저에겐 그 나침반이 없었고 문법공부의 사막에서 헤멨습니다.
요즘은 유튜브니 뭐니 실용예제다루는게 하도 많아서 그런분 별로 없겠지만 이글을 쓰는 주된 이유가 누군가 그런 나침반도 없이 헤메고 있을 것 같아서예요.
API
모니터에 보이는 버튼과 메뉴는 GUI이고 여기서 ‘I’는 ‘인터페이스’ 약자이며 단계와 단계, 즉 경계를 이어주는 다리입니다.
사람이 화면의 버튼을 누르면 버튼은 짜여진 코드에 따라 신호를 보냅니다. 그렇게 우리 코드와 유저를 연결해주는 버튼은 인터페이스인 것이죠.
키보드/마우스와 모니터도 마찬가지로 인터페이스입니다. 사람과 컴퓨터(의 IO: 인풋/아웃풋)를 연결해주는 다리인데 이 또한 UI(유저 인터페이스)죠.
유저가 인터페이스를 이용 할 때 (버튼을 눌렀을때) 그뒤로 무슨 로직이 어떻게 동작해서 결과가 나오는지 몰라도 됩니다. 그래도 동작하죠.
그럼 우리코드와 남의 코드(프레임워크, 라이브러리)를 연결해주는 걸 뭐라고 할까요? “애플리케이션 프로그래밍 인터페이스”, API라고 합니다.
단어를 좀 다르게 생각하면 ‘응용 프로그래밍을 위한 인터페이스’ 또는 ‘앱 개발을 위한 인터페이스” 이죠.
그러니까 이번엔 유저가 아니라 ‘개발자 인터페이스’입니다.
우리 코드와 프레임워크를 연결할때 뿐만 아니라 응용프로그램끼리 통신할때, OS와 연결 할 때, 서버와 연결 할 때 모두 API가 있습니다.
그 인터페이스가 언어공부에서 배우는 클래스이고 함수이고, 연결점이며 프레임워크 사용을 위한 수단입니다. API 외에도 알아야할 기초지식이 많은데 (예: 웹에선 HTTP 프로토콜 등) 그러한 지식이 경계를 넘어가게 돕습니다.
라이브러리와 프레임워크에는 이런 API가 있고 그 사용법을 공식 문서를 통해 알게되며 이 문서를 API ‘레퍼런스’라고도 합니다.
MS는 MSDocs (과거 MSDN) 웹사이트에 함수 하나하나 설명을 해놨고, 구글, 애플도 자기네 개발자 웹페이지에 있습니다. 모든 프레임워크 개발사들은 그 문서사이트를 만들어 공개합니다.
둘째론 실제 프레임워크 파일내에 그 문서가 주석으로 작성되어있습니다. 코드에디터에서 ‘정의보기’로 따라가보면 함수위에 주석설명을 달아놨죠.
우린 남이 만든 라이브러리/프레임워크에 속한 함수의 시그니처(이름과 반환타입, 매개변수가 적힌부분)만 작성해서 호출할 뿐
{…} 블록 그안에서 무슨일이 일어나는지 몰라도 됩니다. 함수 사용법만 알면 (버튼을 누를 줄만 알면) 되는 인터페이스니까요
세세하게 어떻게 동작하는지는 캡슐화 되어있고 숨겨져있기때문에 어떻게 돌아가는지 알고 싶어도 알수 없습니다(컴파일언어 한정).
아이폰의 카메라촬영 함수가 어떻게해서 실제 하드웨어의 카메라를 제어하는지 우린 몰라요. 다만 애플이 “카메라 촬영하려면 이 프레임워크의 이 함수를 호출해라” 하니까 그 사용법을 따를 뿐입니다. 제공하지않는 기능은 못 씁니다. 비공개 API는 루팅/탈옥하지 않으면 쓸수 없어요.
프로그래머는 플랫폼이 제공하는 프레임워크의 API를 문서를 통해 많이 알고, 익숙해지도록 익혀야할 뿐입니다.
그러다보니 프레임워크의 규칙과 API에 대해 공부할 양이 많습니다. 거기다 새로운게 추가되기도하고 오래된건 없어지기도 합니다.
프레임워크와 그 API 뿐만 아니라 개발패러다임(객체지향, 함수형프로그래밍등), 알고리즘, 프로그래밍 디자인패턴 등등 공부할 양이, 언어문법공부에 비교해서 어마어마하게 많습니다.
개발자의 자질과 미래는 언어가 아니라 문제해결과 더불어 모두 이런 공부에서 갈린다고 생각합니다. 그 공부와 실력향상을 위해 영어와 AI 도움, 다른 도구들이 강한무기로 작용하고요.
이전의 언어문법공부를 단계를 이제 막 지나 실제의 프레임워크 API를 보면 눈에 안들어옵니다. 그러한 API는 그 언어의 문법에따라 누군가 작성한 클래스이고, 함수인데 지은 이름이 무궁무진하거든요. 익숙하지 않은 단어는 언어의 문법구조만으로 이게뭔지 판단합니다.
그래서 처음엔 당황스럽습니다. 프레임워크 API는 모든게 언어책에서 보던 함수명이 아닌 누군가 만든 이름의 함수로 채워져있는데 내놓으라하는 고수가 만든거다보니 그 언어의 고급기능까지 자유롭게 사용했다보니 못알아볼 요지가 큽니다.. 그래서 되도록이면 언어문법공부때 책 끝까지 하고가는게 좋습니다. 요샌 ChatGPT한테 문법적 설명해달라고 하면되니까 편리합니다.
첫 학습자가 그 언어를 진짜로 익히는 시점이 바로 이렇게 목적하는 플랫폼의 프레임워크를 통해 진짜 내 목적을 위한 코딩을 하게되면서입니다. 작성한 API, 실용예제, 자기목적에 필요한 코드를 익힘을통해 익숙해져가는 거죠.
언어의 구조도 눈/머리에 익숙해지며 안까먹게됩니다. 이름짓기 규칙에따라 함수 기능에따라 자주쓰이는 이름도 어느정도 통용되어 있다보니 자꾸 접하면 머리에 들어옵니다.
이는 영어공부와 같습니다. 문법공부만으로 끝내지않고 연습하고 말하고 스스로 쓰면서 영어를 할 줄 알게 되거든요.
우리의 몸과 영혼을 하드웨어와 소프트웨어로 비유하곤 하는데 실상은 소프트웨어라는 건 개념적인 것입니다. 그 또한 물리에 종속되어 있습니다.
프로그래밍에서 고수준, 저수준 레이어를 나누지만 반도체 물리과학 수준까지 내려가면 결국 (원자의구조에서) 전자의 흐름이 만들어내는 것인데 그것을 제어하는 물리소자가 반도체, 그것을 모아 논리를 구성한게 CPU같은 칩입니다. 프로그램은 그것이 어떤순서로 동작할지 코드로 작성된 것이고요.
그런의미에서 우리가 생각하는 영혼도 결국 DNA단위의 움직일뿐 사실 영혼이란건 인간의 생각일뿐인지 모르겠단 생각을 합니다.
CPU뿐만 아니라 그래픽칩셋인 GPU를 만드는 반도체칩 제작사 (인텔, AMD, Nvida)는 데이터시트라는 프로그래밍으로따지면 API와 같은 문서를 내놓습니다. 이 비트에 어떤 기계어(혹은 어셈) 무엇을 넣으면 어떤 동작을하는지 적혀있죠.
고수준 언어의 컴파일러는 사람이 읽기좋은 텍스트를 그런 데이터시트에 맞춰 기계어로 변환해줍니다. OS커널 역시도 CPU의 데이터시트 규칙에 맞춰 프로그래밍 된것이고 그래서 아키텍쳐가 다른 CPU에선 동작하지 않는 겁니다.
프로그래밍을 하다보면 오픈소스 하대 성향을 만나곤합니다. 그게 남이든 자기자신이든요.
자기자신이 처음부터 끝까지 직접 만드는 걸 선호하는 사람, 그렇지 못한 사람을 무시하는 사람.
누구나 학습하다보면 원리이해의 욕구가 있습니다. 그렇지만 아직 완성하지 못한 입문자처럼 완성까지 전체그림을 그리지 못한 사람은 그걸 참을 줄도 알아야합니다.
앱개발 분야에선 결국 남이 만들어둔 API사용하는 걸 벗어나지 못하거든요.
깊이파고드는 성향의 사람도 이미 있고 검증되고 잘 돌아가고 자기가 만들것보다 성능도 뛰어난, 기본 라이브러리의 수학함수를 하나하나 다시 만들어 쓰는 사람은 없을 겁니다.
그럼에도 불구하고 결과는 같은데 자기가 만든 프로그래밍이 5만줄이이네 어쩌네 바닥부터 다 할 줄 안다고 내세우는 사람도 있습니다. 그런사람은 되려 오픈소스를 활용할 줄 모르거나 프레임워크에대한 이해가 떨어집니다. 인간의 시간은 한정되어있는데 그 시간을 그쪽에 쏟았으니까요. 응용프로그래밍 측면에서는 되려 공부를 안한 사람입니다.
자신 스스로 바닥부터 프로그래밍한다는 것은 착각이며 오만입니다. 그럴거면 CPU 데이터시트보면서 언어와 컴파일러부터 만들어야겠죠.
하지만 말했듯 그마저도 결국 단계별 인터페이스를 사용하는 건 벗어날 수 없어요. 더욱 심하게는 반도체부터 만들어야겠지만 그럴수 있는 사람도 할 이유도 없겠죠.
저수준으로 내려갈수록, 타이어를 다시 발명할 줄 아는 사람일 수록 밑바닥 코드에대한, 원리에대한 이해력이 높아지는 건 부정할 수 없겠으나 그것이 결과를 내기 유리하다는 건 아닙니다.
그리고 대부분은 그 저수준에서 이미 나온 라이브러리와 동일한 기능, 성능을 구현하는 것 조차 실패합니다. 애초에 그마저도 한 집단이나 개발커뮤니티 전체가 오랫동안 쌓아오며 만든 거고, 그 전부를 개인이 혼자 다시 만들정도 능력자는 드물어요.
이것은 마치 외국어공부에서 ‘어원’을 공부하는 것과 같을거예요. 이해력은 높아지고 도움은 되는 것 같지만 영어를 말하고 듣기위해선 안해도 문제없이 가능하고 되려 시간만 많이 뺏기는 그런 것이죠.
그럼에도 불구하고 시간이 된다면 타이어를 다시 발명해보는 것은 실력 향상과 자아실현, 이해의 목적으로 좋은 시도라고 생각합니다. 때론 그런 시도를 해본사람만이(이해하고 있는 사람만이) 풀 수 있는 문제가 나타나기도 하니까요.
이미 말했듯 프로그래머의 실력은 언어든 프레임워크든 끝없는 공부와 반복적인 숙달, 문제해결로 늡니다. 단지 그것으로 오만하여 목적의 본질을 잊지말아야겠습니다(결과를 잘 내는 게 중요).
이를 통해 하고 싶은 말은 입문자로서는 너무 알고리즘, 수학 이런것들에 얽매이지 말란 것입니다. 코딩테스트가 목적이 아니라면 말이죠. 차라리 컴퓨터기본지식, 프레임워크, API 학습에 유리한 영어공부를 먼저하는게 낫습니다.
CLI 개발툴
얘기하고 싶은 개발툴 분류 두가지가 있습니다.
-CLI
-IDE
겉모습을 보자면 명령줄(CLI)과 GUI로 나눌 수 있습니다.
요즘 텍스트에디터는 확장도 많이 붙고 사실 경계가 애매하지만 여전히 텍스트 에디터로 분류합니다. VS Code 같은 것들이요.
많은 입문자들나 가르치는 사람들이나 GUI 툴을 많이 씁니다. 그편이 직관성이 높고 실제 개발에서도 대부분 쓰이니까요.
이얘기를 하는 이유가 CLI 때문인데 간단히 얘기하면 cmd 또는 터미널 사용입니다. 개발자 아닌사람들도 컴퓨터 좀 다뤄본 사람들은 ip config나 cd.. 같은 명령어를 컴퓨터에 입력해봤을 거예요. 개발자들은 git 명령어 많이쓰죠.
앞서 언어공부 부분 얘기할때 ‘콘솔앱’에 대해 얘기했는데 응용프로그래머가 콘솔앱을 만들수 있습니다. 여러 언어에서, 배울때 제일먼저 만드는 응용프로그램이, Hello World를 작성한 자신의 첫 응용프로그램이 바로 이 콘솔앱이죠.
C같은 많은 언어가 언어학습단계에서 데스크탑 콘솔앱 개발 프레임워크에서 코딩을 가르칩니다. 기초학습하기엔 그 환경으로 충분하기도하고요. 보통 자기가 목적하는 프레임워크가 아니기때문에 동떨어진거고요. Xcode는 여러플랫폼 프레임워크가 다 있는 IDE라서 그것만으로 해결, 비효율적으로 과하지만 애초에 아이폰 프레임워크로 기초를 가르칠수도 있죠.
터미널에 입력하는 명령어는 사실 사용할 콘솔앱을 지명하고(앱을 더블클릭해서 실행하듯) 거기에 명령어 옵션을나열해 그 앱에 전달,시작 하는 것입니다. 그러면 프레임워크는 main함수의 args 매개변수로 넘겨주고 그걸로 나머지를 코딩합니다. GUI가 없을뿐이지 일반적인 응용프로그램이라는 사실입니다. GUI앱은 보통은 그런 인자 전달없이 시작(더블클릭)하니 args를 사용안하는거고요
지금이 DOS시대도 아니고 왜 아직까지 이런 텍스트로 다루는 CLI가 널리 쓰이는가? 이유는 개발이 간편하고 환경을 덜 타기 때문입니다. GUI라는 무겁고 구현어렵고한 것을 안써도 되는거죠.
또한 여러분이 자기 컴퓨터에서 돌릴수 있는 어떤 자동화 도구를 만든다고 했을때 GUI없이 가벼운 콘솔앱으로 만들수도있죠.
단지 윈도우/맥에서 돌아갈 프레임워크에대한 지식이면 됩니다. 기본프레임워크의 파일입출력만 알아도 콘솔앱으로 많은 걸 할 수 있습니다.
이미 한 언어에 익숙해지고나면 사이드프로젝트로 데스크탑 콘솔앱 배포가 가능한 언어/프레임워크 잠깐 배워서 만들어도 됩니다. GUI없다보니 딱 필요한 로직만 있으면되거든요.
디스플레이가 없는 서버벡엔드 개발의 기본적인 부분이 이렇습니다. 웹프레임워크가 아니더라도 콘솔앱으로도 어딘가로 파일을 전송할 수 있죠
앞으로 30년이 지나도 CLI는 건재 할 거예요.
웹개발처럼 입문분야에 따라서는 CLI도구에대한 이해도 필요합니다.
CLI 개발툴도 이 콘솔앱으로 만들어져 CMD/터미널에서 동작하는 거예요.
닷넷 개발자는 VS나 VS Code같은 GUI가 아니라 닷넷 프레임워크 개발툴인 csc.exe확장자를 가진 개발툴콘솔앱이 있습니다. (닷넷5이상에서는 dotnet )
그래서 터미널에 명령어를 통해 프로젝트 패키지(폴더)를 빌드하고 런할 수 있죠.
애플플랫폼 앱개발하는 사람들은 Xcode를 통해서 콘솔개발툴이 설치되는데 Xcode말고 별도로 CLI개발툴만 설치할 수도 있습니다.
이런 콘솔명령줄 개발툴은 .swfit, .cs 같은 확장자를 가진 텍스트파일에 지나지 않는 파일들을 가져다 컴파일합니다. 그래서, vs code나 Xcode가 아닌, 메모장같은 텍스트편집기로도 코딩이 가능합니다.(옛날엔 다 이렇게 했대요)
하지만 많은 데스크탑,모바일앱 개발자들은 CLI 쓸일 없는건 물론이고 개발툴로서는 그 존재자체도 모릅니다. 또다른 도구 사용법이지 프로그래밍 실력과 상관도 없고 몰라도 되거든요.
VS나 Xcode같은 IDE에는 이런 빌드&런 뿐만아닌 SDK라고하는 프레임워크와 문서, 시뮬레이터, 메모리 프로파일러, 디버깅도구, 등 여러 도구들이 통합되어있습니다. 그래서 ‘통합 개발 도구’, IDE입니다.
대부분은 이런 IDE나 VS Code같은 GUI 개발툴을 쓰면 될뿐입니다.
반면 서버개발자/배포자는 일단 서버 배포때문이라도 명령줄을 많이 다룹니다. 서버에 접속해야하는데 이를위한건 죄다 CLI 콘솔앱으로 만들어져있습니다.
그러다보니 이와 밀접한 Web앱 개발자 커뮤니티는 CLI앱을 많이 다루고 만듭니다. 그래서 개발툴도 CLI 개발툴을 이용하는 때가 많아요. 대부분의 강좌에서 CLI로는 어떻게 프로젝트 템플릿을 만들고 빌드하고, 런, 배포하는지 할 줄 알면 도움이 됩니다.
하지만 뭐 이런게 있다는 것만 알아두고, 밀접한 분야아니고선 입문단계에선 불필요하게 CLI툴을 학습할 필욘 없습니다.
사이드
클라와 서버의 용어가 갈리다보니 ‘Side’란 용어로 설명합니다.
웹개발 분야에서는 front-end 개발과 back-end 개발,
모바일앱/데스크탑 앱 분야에서는 클라이언트 개발, 서버개발로 불립니다.
사실 같은데 이 두분야에서는 각각 다르게 부르는데 어떤 막연한 개념, 그러니까 서버와 클라이언트 기준으로 어느쪽이냐(side)에 따라 나누어 볼 수 있습니다.
어느게 서버고 어느게 클라이언트냐는 구분에 명확히 따지자면 사실 연결되는 앱의 서로의 입장의 차이인데, 여기서는 GUI 기준으로 얘기하겠습니다.
GUI가 있고 엔드유저(사용자)와 상호작용을 하면 클라이언트 사이드고, 서버에서 도는 앱이면 서버사이드입니다.
서버 코드는 주로 데이터만 다루기때문에 보통은 GUI를 만들지 않습니다(만드는게 요즘 유행이긴해요).
웹개발 분야에서는 여러분이 쓰는 크롬, 엣지, 사파리같은 ‘웹브라우저’가 클라이언트입니다. 웹개발분야에서는 이걸위한 프로그래머를 프론트엔드 프로그래머라고 하죠.
서버사이드는 그냥 넘어가고, 클라이언트 사이드(프론트엔드) 프로그래밍에대해 말해주고 싶은게 있습니다.
배우려는 언어가 자기가 이루려는 목적에 부합하지 않을 수도 있습니다. 아무것도 모른다면 그럴 공산이 커요.
웹개발은, 인터넷에 떠드는 거의 모든 웹개발분야에서 프론트엔드가 하는게 UI 정도로 매우 한정적입니다. HTML/CSS/자바스크립트로 하는 대부분은 이거예요. 웹 프론트엔드는 UI 개발이다라고 해도 과언이 아닙니다.
하지만 사실은 자바스크립트로도 클라이언트사이드 DB도 다루고 물린엔진도 만들 수 있고 웹게임도 만들수 있고 포토샵을 만들수도 있습니다. 그런데 그런 시장(혹은 취업처)이 별로없어서 자료도 그렇고 할 줄아는 사람도 매우 적습니다.
오늘날 대부분 취업처를 보면 프론트엔드는 쇼핑몰같은 사이트의 데이터만 표시하고 회원가입/로그인 구현이면 그만인 취업처가 많을겁니다. 서비스사업이 발전하다보니 시장규모가 커서 어쩔수 없어요.
시장의 요구사항이 프론트엔드는 서버의 데이터나 잘 출력하면 그만인 곳이 많다보니 사실 프로그래밍 능력 그 자체로는 천대 받는게 현실일 겁니다. 애플 홈페이지 제품소개 페이지마냥 막 뭐 멋지고 애니메이션 부드럽고 이런것 조차 잘 안하거든요.
대부분의 웹페이지 요구는 그런 동적요소가 적고 요샌 그런 간단한 UI는 서버사이드 개발자가 자바스크립트 없이 프론트엔드 UI를 렌더링하는게 유행이니 더 그렇습니다. 하물며 왠만큼 정해진 UI는 부트스트랩, 리액트등 라이브러리 가져다 조립하면 그만이예요.
반면 모바일 앱개발은 다릅니다.
클라이언트 사이드만으로도 UI 프로그래밍을 별도로 나눠도 될정도예요.
여기도 UI가 간단하게 만드는 경우가 많지만 그외 로직도 많이 다룹니다. 되려 서버클라와 서버 백엔드보다 더 다양하게 다뤄집니다.
목적에 따라서는 UI가 전부인, 지극히 웹 프론트엔드 같아질 수도 있고 ,
저수준 그래픽 프로그래밍 까지 할 수도 있습니다.
로컬DB를 다룰수도 있고요.
게임을 만들 수도 있습니다. (참고로 게임개발은 무조건 게임엔진으로 하세요)
이런 클라이언트 개발은 기술도,도구도 다양하지만 다음 두가지를 생각해 볼 수있습니다.
-개발에 한계가 없는 기술
-개발에 분명한 한계가 있는 기술
전자는 ‘네이티브’이고 후자는 크로스플랫폼개발이나 하이브리드 같은 것들입니다.
OTT앱, 쇼핑앱, 오픈API이용 등 이런 단순히 서버의 내용을 보여주는 용도로는 플러터같은 크로스개발도구로 빠르게 안드로이드와 아이폰 모두 만들 수 있습니다.
대부분의 크로스플랫폼 개발 프레임워크는 전부 이쪽에 집중해있다고 보면됩니다. 그외 최신기능이나 성능을 최대로 이끌어내야하는 프로그래밍에는 적합하지 않습니다.
그래서 만들려는게 AR앱이라거나, 영상편집앱이라거나, 새 iOS버전에 발표된 새로운 기능이라거나, 게임이라면 플러터로 못하거나 하기 힘듭니다.
그러니 사진필터, 동영상 편집이 목적이라면 네이티브를, 데이터표시가 전부라면 크로스개발툴을 쓰는 선택을 하는게 좋습니다.
다만 서버사이드도 이해를 하는게 좋은데 AI 그림앱이 대표적일겁니다. 대부분의 이런 AI그림 앱은 서버에서 만들고 데이터를 전송해줄뿐이니 플러터로도 되죠.
결론
문법 이해하기 어렵고 프레임워크/API 공부할 량이 상당히많지만 아이러니하게도 그 방법이 앱개발이라는 목적을 이루기위한 가장 효율적이고 빠른 방법입니다.
그 이후로는 자기기준에 충분하다면 멈춰있을 수도 있고 성장하고 싶다면 제가 말한 걸 무시하고 깊이 파고들면 됩니다. 목적을 이룰 수만 있다면 나머진 선택입니다.
목적을 명확히 하고 무엇을 해야하는지 조언을 받을 것
이렇게 말했듯 프로그래밍 분야는 넓고 모든 목적에 필요한 기술엔 ‘적합성’이 있습니다.
자신이 뭔갈 만들고 싶어서 하는거라면 그 목적을 경험자에게 말하고 무엇을 공부해야하는지 조언을 얻는 게 좋습니다.
예를들어 모바일앱이면 아이폰만해도되는지 안드로이드만 해도 되는지,혹은 둘다 해야하는지.
어쩌면 프로그래밍이 필요없는 목적을 바랄 수도 있어요. 액셀로 그만일 수도 있고 노코딩툴을 쓸 수도 있죠. 다만 이런 부분은 프로그래머들은 잘 모를수 있기때문에 적절한 조언은 못 해줄 수도 있습니다.
또다른 관점으로는
단지 돈버는게 목적인지
취업이 목적인지
자아실현이 목적인지
에따라 달라질 수 있습니다.
그러니, 자신의 목표가 있다면 그에 적합한 기술(프레임워크)과 언어가 무엇인지 아는게 좋고 그걸 결정하는 일이 힘듭니다. 그러니 더욱 경험자에게 자기 목표(아이디어)를 분명히해서 묻고 시작하는 게 좋습니다.
그런데 목표가 모호한 입문자들도 많습니다. 일단 개발이라는 걸 해보고 싶은사람도 있죠. 그런분들은 대략적인 분야만 정하고 재밌게 공부할 수 있는 거, 배워서 후회없이 여기저기 써먹기 좋은 기술 혹은 자기 일상에 도움이 되는 언어와 프레임워크로 입문하면 좋겠습니다. 그런분들은 C/C++,파이썬으로 콘솔앱제작을위한 프레임워크도 시작하기 좋은 선택입니다.