1. 프로그래밍 학습 관점

1. <프로그래밍> 목적

→  "프로그래밍 언어"와 "개발 기술"은 프로그램을 만들기 위한 것입니다.

- 프로그래밍은 학생, 초보자, 신입를 고려한 교육과 학문의 영역이 아닙니다.

 

"프로그래밍"은 '프로그램'을 만들기 위해 등장했습니다.

그리고 좀 더 효율적으로 프로그램을 만들기 위해, 기술을 개선하고, 새로운 기술이 등장합니다.

 

여러분이 배워야 할 프로그래밍 기술은 "현장의 개발자"를 위한 참고자료 입니다.

초보자를 위한 것이 아닙니다.

 

 

 

 

 

2. <프로그램> 을 만들어야 합니다.

→  이론 학습 >> 실습 >> 체득

- 프로그래밍 문법은, 실제 프로그램을 만드는 방법이 아닙니다.

 

영어 문법만 열심히 공부했다고 해서, 영어 소설을 쓰고, 영어 에세이를 쓰고, 영어 연설을 할 수 있을까요?

혹시 가능하다면, 그건 우리가 한글로 된 소설이나 에세이, 연설문을 접하고 써본 경험이 있기 때문입니다.

즉, 글을 쓰는 방식과 구조를 이미 알고 있기에, 언어만 바뀌었을 뿐 본질적인 표현 방식은 낯설지 않기 때문이죠.

 

노래를 한 번도 불러보지 않고, 발성 이론만 공부해서 가수가 될 수 있을까요?

그림을 한 번도 그려보지 않고, 미술 이론만 배워서 화가가 될 수 있을까요?

요리를 직접 해본 적 없이, 조리법 이론만 익혀서 요리사가 될 수 있을까요?

운동을 몸소 해보지 않고, 운동 이론만 공부해서 운동선수가 될 수 있을까요?

 

 

[1단계] 한국어나 영어의 문법을 배운다고 해서 바로 훌륭한 글을 쓸 수 있는 것은 아닙니다.

[2단계] 논설, 비평, 연설, 각본 등의 글쓰기 방법을 따로 배우고,

[3단계] 그 과정을 통해서야 비로소 실제 결과물을 만들어낼 수 있습니다.

 

[1단계] 마찬가지로 C, C++, C# 등의 프로그래밍 언어의 문법을 익히는 것만으로는 프로그램을 만들 수 없습니다.

[2단계] 문법 이후에는 프로그램을 만드는 방법을 따로 학습해야 하며,

[3단계] 그 과정을 통해서 실제 결과물이 만들어지는 것입니다.

 

 

이론 >> 실습 >> 체득

 

 

 

 

3. <이론 학습> 을 먼저 하고 싶으신가요?

→ 프로그래밍 문법은 초보자가 이해 할 수 있는 영역이 아닙니다.

- 프로그래밍 문법은 초보자가 이해 할 수 있는 영역이 아닙니다.

 

우리는 한국어로 의사소통을 해 본 경험이 직,간접적으로 있기 때문에, 

영어 문법 학습만으로 영어 의사소통을 할 때 어디에 사용되는지 알 수 있습니다.

 

하지만 프로그래밍은, 

단편적인 문법 기술들이, 프로그램을 만드는 과정에서 어디에 사용되는지 알 수 없습니다.

 

프로그래밍 기술은 수십 년에 걸쳐, 보다 효율적인 개발을 위해 지속적으로 보완되고 발전해 왔으며, 각각의 개념들이 유기적으로 얽혀 있어 정해진 순서대로 체계적으로 배우기 어려운 구조를 가지고 있습니다.

 

예를 들어, 인터페이스, 추상 클래스, 콜백, 종속성 문제와 같은 개념들 문법책에서 배웁니다.

하지만 실제 팀 단위 협업과 소스코드로 구현하는 프로젝트를 수행하면서 부딪히는 경험 없이 그 필요성과 사용처를 체감할 수 없습니다.

 

따라서, 모든 기본 개념들을 단편적으로라도 먼저 익힌 뒤, 실제로 프로그램을 만들어가는 과정 속에서
해당 기술이 어떤 맥락에서 사용되는지를 직접 경험하고 이해하는 방식으로 학습해야합니다.

 

 

 

 

- 시험은 정답이 있지만, 여러분이 앞으로 마주하는 모든 것에는 정답이 없습니다.

 

이론은 중요합니다. 하지만 그것이 전부는 아닙니다.

 

영어로 실제 대화하는 것을 배우는 것보다, 영어 문법 이론을 배우는 것이 더 마음이 편할 때가 있습니다.
왜냐하면 문법 문제에는 정답이 있지만, 실제 영어 대화에는 정답이 없기 때문입니다.

 

마찬가지로, 프로그램을 직접 만드는 것보다 프로그래밍 문법을 공부하는 것이 더 편하게 느껴질 수 있습니다.
프로그래밍 문법 문제는 정해진 정답이 있지만, 실제 프로그램을 만드는 과정에는 정답이 존재하지 않기 때문입니다.

 

개발자 지망생이 프로그래밍 문법 기술을 배웠다면,

그 기술을 프로그램을 만들며 어디에 사용되는지 경험해야 합니다.

 

 

 

 

 

4. <회사에서 원하는 인재>란?

→ 실패해도 괜찮습니다. 

- “현장에 가면 다 다시 배워야 해.”

 

이 문장은 제가 이 세상에서 제일 혐오하는 문장입니다.

 

이 말은 공과대학 어느 학과에서든 흔히 들을 수 있는 이야기입니다.

그런데 잘 생각해 봅시다. 이게 과연 말이 되는 이야기일까요?

내가 피같은 등록금 내며, 밤새워가며 공부했는데, 왜 현장에 가서 모든 걸 다시 배워야 하는 걸까요?

 

현장이 과연 4년 이상 나를 체계적으로 교육시켜 줄까요?

회사는 자선봉사단체인가요? 월급도 주고, 교육도 시켜주나요?

현장에서 1년도 안 되어 배울 수 있는 내용이라면, 애초에 그걸 대학에서 가르칠 수 있었던 건 아닐까요?

 

 

 

 

- 초등학교, 중학교, 고등학교

 

공부 좋아하시나요?

 

초중고, 공교육의 목적은 학습 능력 함량입니다.

학습 능력 함량, 즉, 스스로 배우고 탐구하고, 문제를 해결하는 방법 차제를 배우는 곳입니다.

개인에게 맞는 공부 습관을 찾고 발전시키는 곳입니다.

 

시험이 중심인 이유는,

학생들이 공부를 하지 않기 때문이고,

교사가 너무 많은 학생들을 관리해야 하기 때문입니다.

 

 

 

- 대학교

 

대학교는 실무를 가르치는 곳이 아닙니다.

대학은, 박사님들이 학문 탐구, 지식 창출, 진리 탐구를 위한 연구 기관입니다. 

 

학부생들이 좋은 직장을 얻기 위한 타이틀을 얻거나, 현장 경험을 미리 쌓는 곳이 아닙니다.

공부가 하고 싶어서 가는 곳이 대학입니다.

 

대학에서 현장 실무 지식을 원하는 것은, 

운전 면허 시험장에서 경주용 자동차로 레이싱하길 원하는 상황입니다.

 

일반적인 전문 기술 지식은 최소 학사, 석사 과정을 이수한 지식을 의미합니다.

최소한 그정도의 기간과 노력이 필요합니다. 그리고,

그렇기 때문에 실무자들은 신입에 대한 기대가 없습니다. 

 

 

 

 

- 회사와 신입 개발자

 

저는 이 이야기를 개발자를 꿈꾸는 모든 분들께 꼭 전하고 싶습니다.

왜냐하면 저뿐만 아니라, 많은 신입 개발자들이 공통적으로 겪는 현실이기 때문입니다.

 

개인적으로,

전공 학부생 중 약 30% 정도만 실제로 신입 개발자로 취업하며,

그 중 절반은 5년 이내에 개발 직무를 떠난다고 생각합니다.

 

이들이 실패하거나 낙오한 것은 아닙니다.
대부분은 개발 역량을 바탕으로 한 관리직이나 IT 행정, 기획 등의 직무로 자연스럽게 진로를 확장해 나갑니다.

그 결과, 순수 개발 직무를 꾸준히 이어가는 인력은 언제나 부족합니다.

 

저는 그 이유를 크게 두 가지라고 생각합니다.

 

 

 

첫번째, 실패해도 괜찮다고 알려주는 사람이 없습니다.

 

현업 실무자들은 신입이 처음부터 기능을 구현할 수 있다는 기대가 없습니다.

오히려, 회사는 신입 개발자는 아무것도 못하기 때문에, 실수를 통해 배우고, 성장하길 기대합니다.

 

문제는, 이 사실을 알려주는 사람이 거의 없다는 점입니다. 초·중·고 교육에서 이어진 정답 중심의 학습 습관은 모든것이 완벽하고, 실패는 곧 평가 절하로 이어진다는 환경 속에서 실패를 통한 성장을 죄악시해왔습니다.

 

 

두번째, 그렇기 때문에 이론 위주의 학습에서 실무 위주의 학습 방법으로 전환할 수 있는 사람이 적습니다.

 

가수가 되기 위해, 음악 이론이 아닌 수없이 노래를 부르며 잘못된 습관을 고쳐가듯

개발자가 되기 위해, 프로그래밍 이론이 아닌 프로그램을 만들며 실패를 경험하고, 실수 속에서 배우며 성장해야 합니다. 그 길 외에는, 진짜 개발자가 되는 방법은 없습니다.

첫 프로그램보다 두 번째가 나을 것이고, 두 번째보다 세 번째가 더 나아질 것입니다.

시작이 완벽할 필요는 없습니다. 시작 자체가 가장 중요합니다.

 

 

 

 

5. 어른

- 이번 생은 처음이라..

 

시험에는 정답이 있지만, 여러분이 앞으로 마주할 대부분의 상황에는 정해진 정답이 없습니다.

 

우리는 모두 이번 생을 처음 살아가고 있습니다.
그리고 ‘처음’이라는 말에는 언제나 실수와 실패가 함께합니다.

 

프로그래밍뿐만 아니라, 어른이 된 우리 모두에게도 마찬가지입니다.
실패는 피해야 할 것이 아니라, 반드시 거쳐야 할 성장의 과정입니다.

 

실패를 통해 우리는 문제를 더 깊이 이해하게 되고, 기술과 상황의 본질을 체감하며, 점점 더 나은 방향을 모색할 수 있게 됩니다.

 

배움이란 결국, 수많은 실패 위에 쌓이는 것입니다.

그래서 처음부터 잘하지 못해도 괜찮습니다.

 

중요한 것은 포기하지 않고 계속 시도하는 것,
그리고 시행착오를 겪으며 스스로의 방식으로 정답을 찾아가는 과정입니다.

 

저는 학업과 경력을 합쳐 10년이 넘었습니다.
하지만 지금도 배워야 할 이론은 끝이 없고, 저 역시 여전히 정답을 찾아가는 중입니다.

 

어른이란, 정답이 없는 세상 속에서 자신만의 해답을 찾기 위해 매일 노력하는 사람이라고 생각합니다.

그리고 여러분도 그 길 위를 걸어가는 어른이 되셨으면 합니다..

 

 

 

 

 

6. 역사

→ 문제 해결

- 기술은 언제나 어떤 문제를 해결하기 위해 등장합니다.

 

수많은 프로그래밍 언어들, 복잡한 문법들, 새로운 프로그래밍 기법과 기술들은
프로그래밍을 더 효율적이고, 더 효과적으로 만들기 위한 끊임없는 시도와 발전의 결과입니다.

 

따라서 기술을 학습할 때 가장 먼저 해야 할 일은,
그 기술이 왜 등장했는지, 즉 어떤 문제를 해결하기 위해 만들어졌는지를 이해하는 것입니다.

 

 

예를 들어,
“컴퓨터란 무엇인가요?”라는 질문에 답하려면,

컴퓨터의 등장 배경—과거에 어떻게 계산을 하고 있었고, 어떤 비효율이 있었는지—를 이해하는 것에서 출발해야 합니다.

 

“C언어란 무엇인가요?”라고 묻는다면,
C언어가 등장하기 이전에 어떤 한계나 문제들이 있었고,
C언어가 그것을 어떻게 해결했는지를 함께 살펴보아야 진짜로 이해할 수 있습니다.

 

객체지향 프로그래밍(OOP) 역시 마찬가지입니다.
OOP 이전에는 어떤 어려움이 있었고,
객체지향이 어떻게 그 문제를 해결했는지에 대한 맥락과 변화의 흐름을 파악해야 합니다.

 

 

그래서 기술을 공부할 때는 단순히 문법이나 사용법보다 그 기술이 등장한 역사적 맥락을 먼저 이해하고 납득해야 합니다.

 

7. 용어

→ 기술의 핵심 개념

- 기술의 핵심 개념은 용어 그 자체에 담겨 있는 경우가 많습니다.

 

기술을 공부할 때 용어의 사전적 정의, 즉 언어적 의미와 어원을 정확히 살펴보는 것이 매우 중요합니다.

 

예를 들어,

class는 흔히 ‘학급’이라고 알고 있지만,

프로그래밍에서의 class는 "분류"를 의미하는 영어 단어의 본래 뜻에서 출발합니다.

 

OOP에서 말하는 ‘추상화(抽象化)’도 마찬가지입니다.
이는 한자 의치처럼, ‘여러 요소에서 공통된 개념을 끌어내는 과정’을 의미하며, 객체지향의 핵심 철학을 정확히 드러냅니다.

 

thread 또한 단순히 기술 용어가 아닌 ‘실’이라는 뜻의 영어 단어입니다.
이는 실행 흐름이 실처럼 길게 이어진다는 의미를 그대로 담고 있으며, 실행 개념을 직관적으로 설명해 줍니다.

 

WPF에서의 DataBinding 역시 마찬가지입니다.
데이터를 ‘묶는다’는 의미 그대로, UI 요소와 데이터 간의 연결을 설정하는 작업을 의미합니다.

 

 

 

 

- 용어는 기술의 이정표입니다.

 

기술을 배우고 익히는 과정에서, ‘용어’는 단순한 이름이 아니라, 기술 명칭 만으로 수많은 개념과 설명을 압축해서 전달할 수 있는 강력한 도구가 됩니다.

 

(예를 들어, “의존성 주입(Dependency Injection)”이라는 용어 하나에는
객체 간 결합도, 유지보수성, 테스트 가능성 등 여러 소프트웨어 설계 원칙이 내포되어 있으며,
이 용어를 아는 것만으로도 그 개념에 대해 깊이 있는 대화를 나눌 수 있습니다.)

 

정확한 용어를 알고 있으면 관련된 문서, 자료, 강의, 코드 예제를 훨씬 빠르고 효과적으로 탐색할 수 있습니다.

 

결국, 용어는 기술을 표현하는 언어이자, 학습과 소통의 기준점입니다.