1. 프론트엔드만 알고 있는 프론트엔드 개발자는, 일개 코더에 불과하다.
1.1. 프론트엔드 개발자는 프론트엔드만 공부해선 안된다.
1.2. 백엔드, 앱 등의 소프트웨어 기반의 대부분의 개발자들이 다루는, 일반적인 기술 지식을 총괄적이며, 심층적으로 학습하여 활용할 줄 알아야, 뒤쳐지지 않는, 경쟁력 있는 개발자가 될 수 있다.
1.21. 그러나 백엔드, 앱 등의 일반적인 소프트웨어 기술만 학습하게 된다면, 충분히 경쟁력 있는 개발자가 될 수 없다.
1.22. 인공지능, XR 기술, 물리 엔진 등의 대부분의 개발자들이 다루지 않는, 비일반적인, 전문적인 지식이 요구되는, 고차원적인 소프트웨어 기술 학습을 통해, 충분히 경쟁력 있는 개발자로 도약할 수 있다.
1.3. 비트겐슈타인의 “내 언어의 한계는 내 세계의 한계를 의미한다.”라는 말이 있다. 이처럼, “당신의 소프트웨어 기술적 한계는 당신의 프로그래머로서의 한계를 의미한다.”
2. 책, 인강 등 2차 창작물로서 개발 공부를 해나가는 것은, 경쟁력 있는 유연한 개발자가 결코 될 수 없다.
2.1. 경쟁력 있는 전문적인 개발자가 되기 위해서는, 영어 공식 문서, 개발자 저술 원전서(TCPL 등), 원전, 원강 등의 영어로된 1차 창작물로서 공부를 해나가야 한다.
2.11. 1차 창작물이, 공식 개발 문서 등과 같이, 공식적인 자료만을 의미하지 않는다는 것을 필히 유의한다.
2.111. 1차 창작물은 영어로 작성된 자료를 의미한다.
2.112. 영어 자료로 공부를 해야하는 이유는, 주로 전문적인 개발자들은 영미권에 분포한다. 영미권에 거주하지 않더라도, 주로 영어를 사용하여 정보를 전달한다.
2.113. 하지만 영어 외의 자료가 더 나은 경우도 있을 것이다. 그러나 내가 개발 공부를 하면서 이런 경우는 거의 못 보았다.
2.114. 그러므로 전문적인 자료가 주로 많이 있는, 영어 자료로 공부를 진행해야 하는 것이다.
2.12. 영어 공식 문서가 어럽다고, 번역된 공식 문서로 공부해선 안된다.
2.121. 영어 공식 문서를 잘 읽는 방법은, 어학연수 외에는, 많이 읽는 것 밖에는 없다. (참고: https://www.youtube.com/watch?v=vdNwLK7hnPY)
2.122. 많이 읽어라. 그리고 영어적 형태(both A and B 등)에 익숙해져라. 이것이 유일한 답이다.
2.123. 그러나 1차 창작물을 이해를 잘하고 싶다면, 독해만 신경쓰면 된다. 영어 회화 같은 것은 아무런 상관이 없다.
2.13. 처음부터 개발자 저술 원전서로 공부를 시작하는 것은 옳지 않다.
2.131. 개발자 저술 원전서는 해당 기술에 익숙하거나, 친숙하지만, 기술을 사용하면서, 원리적인 부분에서 부족함을 느낄때 읽어라.
2.132. 해당 기술에 친숙하지도 않으면서, 바로 원전서를 읽는것은 아무런 소용이 없다. (참고: https://www.youtube.com/watch?v=gr3H3LSK10s&t=234s)
2.123. 해당 기술에 익숙하거나, 친숙하지 않다면, 일단 2차 창작물로서 공부를 먼저하라. 친숙해진 후에, 1차 창작물로 다시 공부하라.
2.2. 학습 초반에 시간이 많이 소요되더라도, 1차 창작물로서 공부를 하는 것 만이 경쟁력 있는 개발자가 될 수 있는 유일한 지름길이다. 즉, 깊이 있게 공부한 개발자만이 경쟁력 있는 개발자가 될 수 있다.
2.21. 1차 창작물로서 공부하지 않은 개발자는, 언젠간 프로그래밍할 때 결함을 지닌 코드를 작성할 수밖에 없다. 이러한 실수는 프로그램의 핵심적인 부분을 개발할 때 여실히 나타난다.
2.3. 경쟁력 있는 개발자가 되기 위해선, 언제든 1차 창작물로써 공부하는 것을 지향해야 한다.
2.4. 그러나 1차 창작물로 공부할 수록 이해가 안되고, 시간이 부족하다면, 불가피하게 2차 창작물로 공부를 일단 하되, 빠른 시일 내에 꼭 1차 창작물로 다시 공부를 해야 한다. 그래야 진정한 경쟁력 있는 개발자가 될 수 있다. 그렇지 않다면 그 개발자는 코더에 불과하다.
2.41. 이해가 안된다는 것은, 최소 10번 이상 1차 창작물로 학습을 시도했으나 이해가 제대로 이뤄지지 않았음을 의미한다.
2.42 시간이 부족하다는 것은, 해당 기술 사용까지 1달도 채 남지 않았음을 의미한다.
2.43. 2.41 같은 경우가 아닌데도, 1차 창작물로서 공부하는 것이 어렵고 귀찮다면, 당신은 개발자로서 자격 미달인 것이다. 당신은 일개 코더에 불과한 것이다.
2.5. 그러나 개발 기술의 근간이 되는 정수 기술만 1차 창작물로서 개발 공부를 해야 한다. 부수적인 개발 기술을 학습할 때는, 1차 창작물로 공부해선 안된다.
2.6. 부수적인 개발 기술은 자신에게 맞는 가장 빠른 방법으로 공부를 해나가야 한다. 부수적인 개발 기술조차 1차 창작물로 공부한다는 것은, 엄청난 시간 낭비며, 미친 짓이다.
2.61. 시간이 많이 소요된다는 것을 알고, 자신의 개발 전문성을 비약적으로 향상시키지 못한다는 것을 지각하더라도, 부수적인 개발 기술을 1차 창작물로 공부하고 있다면, 그건 자신이 전문적으로 열심히 공부하고 있다는 정신병적 자기도취에 빠진 것이다.
2.62. 절대로 부수적인 개발 기술을 공부하는 것은 개발 전문성을 비약적으로 향상시킬 수 없다. 개발 기술에 근간이 되는 정수 기술을 공부할 때, 결코 개발 전문성은 향상될 수 있다.
3. 빠르게 기술을 학습할 수 있는 개발자만이 경쟁력을 갖춰 살아남을 수 있다.
3.1. 어떤 기술이건 빠르게 학습하지 못한 개발자는, 결코 경쟁력을 갖출 수 없고 시장에서 살아남을 수 없다.
3.2. 그러나 2.2.에서 제시한 바를 어겨선 안된다. 개발 기술의 핵심적인 부분은, 시간이 많이 걸리건 뭐 어떻든, 결코 1차 창작물로서 공부해야만 한다.
3.3. 1차 창작물로서 어떤 것을 공부할 때는 노력보단 발악을 하라. 어떤 순간이든, 어떤 장소이든 간, 학습할 수 있는 기회가 생길 때마다, 매사 고개를 숙이고, 매사 경청의 태도로, 당신이 학습하고자 하는 것을 모조리 학습해야 한다.
3.4. 매사 무엇에 쫓기는 듯한 발악 없이, 전신이 편안하게 공부해서는, 당신은 결코 정수 기술에 대한 학습을 완수할 수 없다. 자존감이 깎이고, 침을 뒤집어써도, 당신은 학습 완수 전까지, 매사 발악을 해야만 한다. 완수 전까지 편안, 평안, 안위 등은 일체 추구하지도 말라.
4. 생성형 인공지능을 사용하는 개발자는, 절대 성공할 수 없다.
4.1. 만약 생성형 인공지능을 남용한다면, 그 개발자는 실패한 개발자이다.
4.11. 남용의 기준은 이와 같다. (1) 문제 해결을 위해 아이디어를 생각하는 것이 귀찮거나 어떻게 아이디어를 낼지를 모르겠다. (2) 시간을 들이면 문제 해결을 할 수 있을 것 같긴 하지만, 정보를 찾는 것이 귀찮다. (3) 생성형 인공지능에게 맡기는 것이, 나보다 더 코드를 잘(효율적, 안정적 등) 작성해줄 것 같다.
4.12 생성형 인공지능을 남용(1) 한다는 것은, 문제 해결을 위해 몇 초 이상 아니면 몇 일 이상 생각하는 것조차 할 수 없다는 것을 의미한다. 이는 개발자의 필수 역량인 “문제해결능력”과 “구현력”이 없다는 것을 보여주는 것이다.
4.13. 그리고 남용(2) 한다는 것은, 문제 해결을 위해 정보를 찾는 것조차 하기 싫다는 것을 의미한다. 이는 개발자의 필수 역량인 “자기주도 능력”과 “탐구능력”이 없다는 것을 보여주는 것이다.
4.14. 그리고 남용(3) 한다는 것은, 자신이 가지고 있는 프로그래밍 지식이 빈약하다는 것을 의미한다. 이는 개발자의 필수 역량인 “학습능력”이 없다는 것을 보여주는 것이다.
4.15. 즉 남용한다는 것은, 자신의 개발자의 필수 역량이 남들과 뒤쳐서, 생성형 인공지능에 책무(문제 해결)를 전가하는 것이다.
4.16. 즉 남용한다는 것은, 개발자 역량의 결여를 증명하는 것이다. 그러므로 이는 자신이 타개발자에 비해 경쟁력이 뒤처진다는 것을 의미한다.
4.17. 만약 당신이 생성형 인공지능을 남용한다면, 당신은 개발자가 아닌 일개 코더에 불과하다는 것을 스스로 증명하고 있는 것이다.
4.2. 코드를 작성하기 전에, 생성형 인공지능을 먼저 사용해 보는 것조차, 실패한 개발자라고 볼 수 있다.
4.21. 나는 개발자라면 스스로 문제 해결을 위해 코드를 작성할 줄 알아야 한다고 생각한다. 프로그램의 로직에 대해 윤곽은 잡을 수 있어야 한다고 생각한다.
4.22. 그러나 로직에 대해 윤곽을 잡을 수 없고, 어떤 문제 해결을 위한 “기본적인 아이디어”를 도출할 수 없어서, 생성형 인공지능의 도움을 받고 있다면, 나는 그 개발자는 결코 실패한 개발자라 생각한다.
4.23. 개발자란 한 마디로 문제 해결을 위한 아이디어를 떠올리고, 이를 코드로 옮기는 사람이다. 그러나 이런 매우 원초적인 것조차 할 수 없다면, 그 개발자는 생성형 인공지능을 “남용” 하고 있는 것이다.
4.24. 만약 당신이 문제 해결을 하기 전에 생성형 인공지능을 사용한다면, 당신은 일개 코더에 불과하다.
4.3. 생성형 인공지능은 이미 구현한 아이디어, 이미 작성한 코드 등의 이미 개발자가 수행한 어떤 것을 검증 내지 평가 등을 받기 위해 사용되어야 한다.
4.31. 검증 및 평가 등을 위해서 사용하는 것이 아니라면, 당신은 일개 코더에 불과하다.
5. 개발 기술에 대해 학습만 하는 개발자는, 결코 해당 기술에 대해 학습할 수 없다.
5.1. 개념적 차원에서, 개발 기술 학습만 주구장창하는 개발자는, 진정 해당 기술에 대해 학습할 수 없으며, 더 나아가 개발 실력 향상조차 할 수 없다.
5.2. 진정 기술에 대해 잘 알기 위해서는, 개념을 공부하면서 함께 사이드 프로젝트를 개발해야 한다. 충분한 개발 기술 학습에 충분한 개발실습이 뒷받침되지 않다면, 해당 기술 학습은 효용이 없다. 개발 실습을 통해 완전한 기술 학습을 완수해나가야 한다.
5.21. 절대 학습에서만큼은, 결코 “안다고” 생각하지 마라. 만약 어떤 프론트엔드 기술을 안다는 것을 증명하기 위해서는, 구글에 "리액트 프로젝트 추천"을 검색하고 하나의 프로젝트를 정해서 똑같거나 더 나은 방향으로 개발해 보아라.
5.22. 만약 당신이 능숙하게 그 프로젝트를 개발해 낼 수 있다면 당신은 해당 기술에 대해서 깊이 있게 아는 것이며, 만약 개발하면서 버벅거리며, 수시로 책을 확인하고, 구글링을 하는 것 등을 자주 반복한다면, 그건 해당 기술을 아는 것이 아니라는 증거이다.
5.23. 그러나 낙담하지 마라. 다시 해당 기술을 학습할 기회라고 생각하라. 원론적인 예긴듯싶지만, 늦었을 때가 가장 “빠른” 것이다.
5.3. 또, 진정 기술에 대해 잘 알기 위해서는, 다른 사람의 코드를 많이 읽어야 한다.
5.31. 다른 사람의 코드를 통해, 개념적으로만 학습한 기술이, 실제로 어떻게 사용되는지 직접적으로 알 수 있다.
5.32. 더불어, 다른 사람의 코드들을 많이 읽게 된다면, 나의 코드 스타일도 좋아질뿐더러, 프로그래밍 실력도 같이 증가하게 된다.
5.33. 이처럼, 개발 실력 향상을 위해서, 코드를 많이 읽는 것은 매우 중요하다.
6. 프론트엔드의 핵심은 UI/UX이다.
6.1. 요즘 들어 많은 프론트엔드 개발자가 간과하는 사실이 있다. 바로 UI/UX 적 측면이다. 근래 많은 프론트엔드 개발자들은 웹페이지 동작 기반 측면(React, Vue.js 등)만 너무 신경 쓰는 것 같다. 많은 개발자들이 Next.js 학습은 불이 나게 하고 있으면서, Web Animation API, CSS 등 UI를 다루는 기술적 측면은 간과하고 있다.
6.2. 나는 프론트엔드의 근간은 UI와 UX에 있다고 생각한다. 프론트엔드 개발자를 설명하는 말조차 “software developer who creates the user interface (UI) and user experience (UX) of websites and application”라고 표현하고 있기 때문이다.
6.3. 그러므로 프론트엔드의 본질에 집중하는 프론트엔드 개발자가 되어야 한다. 본질에서 벗어난다면, 결코 경쟁력을 갖춘 프론트엔드 개발자가 될 수 없다. 본질을 더욱더 깊이 있게 파고드는 프론트엔드 개발자만이, 경쟁력을 갖출 수 있다. 프론트엔드의 본질을 아는 프론트엔드 개발자는, 결코 대체될 수 없다.
6.31. 본질에 집중하기 위해서는, 최대한 사용자의 관점에서 바라보고 개발해야 한다.
6.311. 개발은, 내가 구현하고 싶은 로직을 구현하고 싶어서, 개발하는 것이 아니다. 내가 편하게 스타일 로직을 구현하고 싶어서, 쉽게 마크업을 구성하는 것은, 개발이 아니다.
6.312. 그것은 내가 구현하고 싶은 기능과 레이아웃이며, 결코 사용자를 위한 로직과 레이아웃이 아니다.
6.313. 모든 기능과 레이아웃 들은 사용자를 위해 개발되어야 한다.
6.314. 만약, 사용자의 측면을 고려하지 않고서, 무시된체 개발된다면, 해당 프로덕트는 결코 성공하지 못할 것이다.
6.135. 그러나, 만약 해당 프로덕트가 성공하였다고 해도, 그것과 기능적인 측면은 비슷해도, 사용자 친화적인 부분을 더 고려한, 다른 프로덕트로 사용자들은 언젠가 넘어갈 것이다.
