React를 배우기에 앞서 그 기반이 되는 언어인 JavaScript에 대해서 배우고 있습니다. 제가 백엔드 부트캠프때 배우지 못했던 JavaScript의 특징을 조금 더 깊게 알 수 있어서 기뻤습니다. 조금 놀라웠던 것은 var 보다 let, const를 사용하도록 권장한다는 것입니다. var는 스코프의 문제가 있어 행위가 예측 불가한 상대적 단점이 있다고 합니다. 반면에 let과 loose는 블럭 레벨에서 스코프가 지정되어 스코프가 변동되지 않아 조금 더 안정적이고 유지보수가 용이하다고 합니다. 이 것이 C#등 다른 언어에도 적용되는지 궁금하기도 합니다. 이외에도 JavaScript에서는 Java에서처럼 sout같은 데이터 출력 명령어인 console.log()에 대한 단축기가 없다는 것이었습니다. 하지만 VSCode상에서 Keyboard Shortkey 를 JSON 형태로 직접 설정할 수 있는 법을 알아냈습니다. 굉장히 유용한 기능이라는 생각이들어 관심이 있으신 분들은 제 블로그를 참조하시면 좋을 것 같습니다.
JavaScript가 웹 프론트엔드의 영역을 넘어서서 nodejs등 백엔드 부분까지 구현할 수 있을 정도로 그 영향력이 커졌다는 사실이 매우 놀랍습니다. 스크립팅 언어로써 한계가 있을 것이라는 의견이 많기도 했지만, 그것을 부정하듯 점점 웹 기술이 모든 분야에 도입되어 백엔드를 구현하는 부분까지 풀스택을 JavaScript 기반 기술로 구현할 수 있는 시대가 되었다는 것에 매우 놀랍기도합니다. 이 언어의 무한한 가능성과 확장성에대해 점점 더 알면 알수록 놀라워지는 요즘입니다. 그 점에서 JavaScript나 Nodejs등을 다룰 수 있는 분들에게 굉장히 많은 기회가 있을 것이라는 생각이드네요.
JavaScript의 조건문, 반복문, 문자열 다루기 및 함수와 스코프에 대해서 알아보았습니다. 흥미로웠던 점은 Java/C#과는 다르게 string이 JavaScript에서는 참조형데이터가 아닌 기본형자료라는 점이며 또 JavaScript만의 특이한 데이터 유형인 null, symbol, undefined 등도 기본형자료에 속한다는 점입니다. 문자열이 “”, ‘’. ``안에서 모두 정의될 수 있다는 것도 조금 신기했습니다. 이런 점을 보니 백엔드 언어인 Java/C#와는 패러다임이 꽤 다른 언어라는 생각이드는데, 왜 이렇게 다르게 언어가 설계되었는지 궁금해지기도 했습니다.
또 하나 중요한 배움은 언어를 떠나서 반복문의 사용 이유였습니다. if/else 문은 특정 조건을 기준으로 참과 거짓을 판단하여 작업을 수행할 때 유용하고, for문은 몇 번 반복을 해야하는지 확실히 알 때 , while 문은 특정 조건이 참일 때 코드를 수행하면서도 얼마나 반복해야할지 확실히 알지 못할 때 사용하는 것이 좋고, do-while 문은 while과 비슷하나 반드시 처음 한번은 코드가 실행되어야할 때 사용하는 것이 좋다는 것을 다시 한번 더 상기하게 되었습니다. 각각의 반복문의 장점을 잘 이해하고 필요할 때 활용할 수 있어야겠다는 생각이 들었습니다. 이 것은 C#/Java를 활용함에 있어서도 통용될 수 있는 가치있는 지식이라는 생각이듭니다.
또한 함수(function)와 스코프의 개념을 잘 이해하고 적용할 수 있어야 에러의 가능성을 줄이고, 가독성이 좋으면서도 유지보수가 용이한 프로그램을 만들 수 있다는 사실을 다시 한번 더 깨닫게 되었습니다.
이번 주에는 JavaScript의 웹 마법 문서인 DOM(Document Object Model)에 대해 배워보았습니다.
이 마법 문서는 웹 사이트가 유저와 상호작용하면서 더 역동적이고 동적인 웹 서비스를 제공하기위해 만들어진, JavaScript로 웹 요소들을 조작할 수 있는 표준이라고 할 수 있습니다. 예를 들어서 유저가 버튼을 클릭하거나, 키를 누르는 것, 혹은 특정한 입력바에 값을 입력하거나 어떠한 요소에 마우스를 가져다대는 방식으로 특정한 이벤트를 발생시킬 수 있죠. 이러한 유저의 행위에 대한 반응으로 웹 페이지가 특정한 함수를 통해 어떠한 작업을 수행하는 것을 이벤트(event)라고 합니다.
이 DOM이라는 API(Application Programming Interface)로 인해 웹 페이지에 대한 조작이 표준화되었고, 따라서 웹 서비스를 구현하는 것이 매우 용이해졌습니다. JavaScript를 배우면 배울 수록 선구자들이 이렇게 편리한 프로그래밍 기법을 구현하기 위해 얼마나 많은 시행착오를 겪었을지 상상이 가지 않네요. 동시에 그들의 헌신에 대해 감사하게됩니다. 그들 덕분에 그렇게 많은 컴퓨터 배경지식을 갖지 않아도 누구나 웹 프로그래밍을 할 수 있게 되었기 때문이죠.
AJAX(Asynchronous JavaScript and XML)은 말그대로 "JavaScript와 XML 포맷을 비동기적으로 이어주는 프로그래밍 기법"입니다. 새로운 기술이나 언어라기보다는, 기존에 존재한 JavaScript기술을 새로운 개념으로 활용하는 방식입니다. 마치 Docker가 새로운 기술이라기보다는 기존에 존재하는 기술을 조금더 획기적으로 활용하여 성공한 것처럼 말이죠.
AJAX를 통해서 특정 API를 활용해 데이터를 가져와 처리하는 작업이 매우 용이해졌습니다. 또한 웹 페이지를 새로고침 할필요없이 동적으로 수정된 내용들을 로딩할 수 있게 되었죠. AJAX를 통해서 외부의 원하는 데이터를 쉽게 가져오고 웹 사이트에 반영한 변경 내용을 실시간으로 업데이트해 볼 수 있는 것입니다. 정말 유용하고 강력한 JavaScript의 마법 주문이 아닐 수 없네요.
또한 try-catch문이 JavaScript에서도 예외 처리를 위해 유용하게 활용된다는 것을 알았습니다. 덕분에 try문 내에서는 정상적인 상황에서의 연산을 정의하는 작업과 예외를 발생(throw)시키는 코드를 정의하고, catch문에서는 발생된 예외에 대한 처리 코드를 작성해야한다는 것을 다시한번 더 상기하게 되었습니다. 이런 개념들을 리뷰하게되니 언어마다 조금씩 활용되는 기법과 사용되는 데이터 구조나 문법이 조금씩 다르지만, 궁극적으로 전체적인 프로그래밍 패러다임에 대해서는 많은 언어들이 교집합을 가지고 있다는 생각을 다시 한번 더 하게되었습니다.
지난 몇 일간 추가적인 DOM 메서드, try-catch 문을 활용한 예외처리, 그리고 AJAX에 대해 발견한 내용을 공유합니다.
React를 배우기 위해 꽤 긴 사전준비 기간이 필요했습니다. JavaScript를 먼저 알아야 React를 배울 수 있었기 때문이죠. Spring을 배우기전 Java를 배우고, Flask/Django/FastAPI를 배우기 전 Python을 배워야하듯, 또 글을 잘 쓰기 위해서 펜을 잡는 법을 배워야하는 것처럼 모든 일에는 단계가 필요하다고 생각했습니다. 그래서 JavaScript를 다루는 와중에도 제 블로그 제목이 “React를 알아보자“였던 것은 서사상 타당하다고 생각합니다.
React는 JavaScript를 기반으로 개발자에게 유저 인터페이스를 더욱 편리하게 구현할 수 있게 만든 라이브러리입니다. 그에 대한 가장 설득력 있는 이유 중 하나는 JSX(JavaScript 상에서 HTML 문법을 혼용해서 웹 프로그래밍을 할 수 있게 해주는 확장 도구)를 지원한다는 것 같습니다. React 덕분에 HTML 페이지에서 DOM요소를 JavaScript코드와 별도로 구성하지 않고도 JavaScript상에서 같이 프로그래밍을 할 수 있다는 것이죠.
또한 JavaScript가 가지고 있는 Virtual DOM이라는 개념역시 이를 가능하게 해주죠. Virtual DOM은 실제 DOM을 조금 더 가볍게 표현한 것으로써 브라우져상의 메모리를 활용하고, 재조정(Reconciliation)이라는 기법을 활용해 특정 UI요소가 유저의 입력에 반응해 속성이 변경되면 자동적으로 업데이트됩니다.
JavaScript내에서 HTML DOM요소들을 직접 코딩할 수 있고, Virtual DOM을 통해 UI요소를 간편하게 유저의 입력에 따라 갱신할 수 있다는 매우 큰 간편성 덕분에 이 도구가 사랑받고 있는 것은 아닐까하는 생각이 들었습니다. 앞으로 몇 주간 발견하게될 React의 비밀들이 더욱 궁금하고 기다려집니다.
지난 몇 일간 React의 더 많은 보물들을 발견했습니다. JavaScript에서 HTML 코딩을 할 수 있게 해주는 JSX 뿐만아니라, React내에서 Props라는 것을 사용해 데이터를 전달하여 브라우져에 표현할 수 있는 방법도 알게되었고, 상태 변수를 통해 유저 입력에 대한 상태 변화 데이터를 저장해 UI를 동적으로 변화시킬 수 있는 React State라는 것도 배울 수 있었습니다. 동시에 이러한 기법들을 함수형/클래스 컴포넌트로 구현할 수 있다는 것을 깨달았습니다. 흥미로운 점은 클래스 컴포넌트가 문법이 더 복잡하고 함수형 컴포턴트보다 무거워 앞으로는 퇴화(Deprecated)될 수 있다는 것입니다. 이미 실제로 React를 사용해 대규모 어플리케이션을 개발하는 곳은 대부분 상대적으로 성능이 우수한 함수형 컴포넌트를 많이 사용한다고 합니다. 따라서 앞으로 React 컴포넌트는 함수형 컴포넌트만을 의미할 날이 머지 않았다고 생각합니다.
React는 또한 디렉토리 구조상 각각의 컴포넌트를 별도의 스크립트로 분리하는 것이 권장되어 보다 정돈된 프로그래밍을 할 수 있게끔 유도하는 것 같습니다. eslint라는 JavaScript의 에러를 잡아낼 수 있는 유용한 도구를 기본적으로 지원하여 React 프로젝트 환경을 구성하면 자동적으로 이러한 도구들을 설치합니다. 정말 개발자 친화적으로 잘 다듬어진 프레임워크라는 느낌이 많이 들었습니다. 여기서 멈추지 않고, 앞으로도 조금 더 React의 숨겨진 비밀들을 파헤쳐 볼 생각입니다.
함수 컴포넌트의 부작용을 시험할 수 있게 해주며 fetch API나 Axios등을 통해 HTTP 요청을 날려 데이터를 수신할 수 있는 useEffect라는 도구와 useContext를 활용해 부모 컴포넌트에서 자녀 컴포넌트로 데이터를 수신할 수 있게 해주는 useContext, 그리고 마지막으로 React Redux라는 상태 관리를 용이하게 해 주는 라이브러리를 만났습니다.
이러한 보물들을 발견하고보니 React내에서 예외처리나 문제를 사전에 방지하면서도 효율적인 데이터 송수신과 상태 변화를 관리할 수 있게 해주는 여러 유용한 장치들이 많다는 것을 알게되었습니다. 이는 유저 인터페이스를 구현할 때 안정적이면서도 성능높은 프로그램을 작성할 수 있게 해준다는 점에서 React가 프론트엔드 개발자에게 상당한 매력을 가질 수 밖에 없는지 이해할 수 있었습니다.
한편으로는 언어의 발전 속도가 무시무시하다는 생각도듭니다. 특히 프론트엔드 기술의 발전은 정말 놀라움을 넘어 무서울 정도라고 느껴집니다. 지난 몇 주간 React를 공부하면서 내가 프론트엔드 개발자였다면 과연 이 굉장한 속도의 발전을 따라갈 수 있을까라는 두려움과 걱정을 하게되기도 했습니다. 수 주간 학습했던 React관련 개념들에서 파생된 세부 정보들 중 아직까지도 완전히 이해하지 못한 부분들이 많기 때문입니다.
그래서 지난 부트캠프때 프론트엔드 지망생 분들이 배우고 구현한 것들이 정말 아름다우면서도 도전적이라는 생각을 했습니다. 잘 모르는내가 프론트엔드를 너무 안이하게 생각한 것은 아닐까 크게 반성하게 되기도 했습니다. 프론트엔드에서 유저와의 상호작용 기능을 구현한다는 것이 얼마나 멋지면서도 어려울 수 있는 일인지 다시한번 더 깨닫게 되었고, 지난 최종 프로젝트때 디자이나님과 백엔드 지망생들 사이에서 고생한 프론트엔드 지망생 분들에게 큰 감사함을 느끼게 되었습니다.
혹시라도 백엔드를 다루는 분들이 있다면, 당연히 이해하고 계시는 분들도 있으시겠지만, 프론트엔드의 일이 결코 가볍고 쉬운일이 아니라는 것을 말씀드리고 싶습니다. 어쩌면 유저 상호작용을 구현해야하는 일이 백엔드에서 데이터를 처리하는 것보다 특정 면에서는 더 어려울 수도 있다는 것을 저는 개인적으로 느꼈습니다.
좋은 팀워크는 서로의 입장을 이해하는 태도에서 나오는 것이라고 생각합니다. 제가 그동안 작성한 React관련 글들이 백엔드 엔지니어분들께도 프론트엔드에 대한 이해를 높이는 것 뿐만 아니라, 그들이 맞이할 수 있는 어려움과 도전을 상상할 수 있는 계기가 되기를 바라며 React 개념관련 마지막 블로그 글을 공유합니다.
이 게임은 스도쿠같이 9개의 균일한 정사각형으로 이루어진 큰 사각형 내에서, 두 명 이상의 플레이어가 턴을 바꾸어가면서 연속된 3개의 정사각형을 마킹할 경우 이기는 게임입니다.
구현 자체는 매우 간단했습니다. 먼저 게임의 레이아웃을 잡아주고, 각 정사각형이 마우스가 놓여지면 색을 바꾸도록 동적 UI를 구현한 후, App.css 파일을 통해 디자인을 꾸며주었습니다. 다음으로 각 플에이어가 “X” 혹은 "O"로 마킹할 수 있도록 구분해주고 한 플레이라도 한 열/행/대각선을 3개 연속으로 마킹 성공하면 승자로 판별할 수 있는 로직을 구현합니다.
이 게임을 만들면서 함수 컴포넌트 단위로 기능을 구분하고 useState와 props를 활용해 유저 입력에 반응하는 동적 UI를 손쉽게 만들 수 있었습니다. React를 배우는 그 누구나 시도해 볼 수 있는 첫 프로젝트라는 생각이 들었습니다.
배운 것을 직접 써보는 것 만큼 확실한 방법은 없습니다. 프로그래밍에서는 그것이 얼마든지 가능하기에 직접 자신의 손으로 만들어보면서 더 많은 것들을 발견하고 배울 수 있습니다. 그래서 논리적인 사고력을 효과적으로 키울 수 있는 프로그래밍이 매력적일 수 밖에 없다는 생각이듭니다.
React의 간편성과 우수한 성능을 이번 프로젝트를 진행하면서 확실히 깨닫게 되었습니다. 이전에 JavaScript와 HTML 그리고 CSS를 모두 구분해서 작성했던 경험이 있던 저에게는 정말 새로운 문물처럼 느껴졌습니다. 백엔드 엔지니어링을 공부했던 사람의 입장으로써 프론트엔드 분야가 얼마나 매력적이면서도 도전적일 수 있는지 알 수 있었던 소중한 시간이었습니다.
React를 활용한 프로젝트를 하나 더 해보기로 했습니다. 지난 번에 React기반 "Tic-Tac-Toe"라는 게임을 만들었지만 매우 간단한 수준이었고 따라서 그것으로 만족하기에는 React를 활용한 연습이 충분치 못하다고 판단했습니다. 그래서 이번에는 유저로 하여금 각종 데이터를 열람할 수 있는 대시보드를 만들어 보는 프로젝트를 하려고합니다.
이번 장에서는 yarn 및 npm을 활용해 프로젝트에 필요한 환경 설정을 하는 과정을 담아보았습니다. 이렇게 하고보니 먼저 어떤 프로젝트를 하기전에 필요한 환경을 갖추는 것조차 결코 쉬운일은 아니라는 생각이 들었습니다. 그러나 이러한 환경 설정을 하면서 yarn과 npm을 어떻게 활용하고, 나아가서 React내 라이브러리내 환경 변수를 설정하는 것과 이미 작성한 라이브러리를 수입하는 방식에 대해서 조금 더 자세히 알 수 있었던 의미있는 시간이었다고 생각합니다.
React 대시보드 프로젝트를 위한 올바른 환경 설정을 하기위해 고군분투한 저의 기록을 공유합니다.
React로 대시보드(Dashboard) 게시판 UI를 구성해 보았습니다.그동안 온라인 과정을 통해 React를 배웠으나 막상 내 손으로 처음부터 게시판 UI를 만들어 보려하니 막막했습니다. 그래서 너무 시간을 지체하고 싶지않아 꽤 유용한 유튜브 자료(https://lnkd.in/gY7mEgKy)를 보면서 따라해 만들어보았습니다.
따라서 해보니, 수업했을 때보다 더 React의 특징이 눈에 잘 보이기 시작했습니다. 이벤트 처리 로직이나 CSS 상에서 클래스 및 id selector 등을 정의해 스타일링을 HTML 요소에 입히는 것, 또 props를 활용해 수입(import)한 외부 라이브러리 혹은 스크립트의 객체를 브라우져상에 렌더링하는 것 등 과정에서 배웠던 것들을 훨씬 더 생생하게 프로젝트를 진행하면서 배울 수 있었습니다.
프로그래밍 세계에서는 역시 이론을 공부하면 반드시 프로젝트를 해 보아야 그것이 나한테 훨씬 잘 흡수가 되는 것 같다고 느낍니다. “써먹지 않는 지식은 죽은 지식“이라는 말의 의미는 프로그래밍을 하면서 정말 크게 와 닿는 것 같습니다.
이제 기본 UI틀을 마련했으니 이후 글에서는 해당 UI페이지를 동적으로 만들어 데이터를 입출력할 수 있는 단계로 나아가려고합니다. 그 무엇보다도 UI자체를 만드는데 있어 가장 큰 우려가 있었는데 그것을 해결할 수 있어서 정말 감사하게 생각합니다. 이제 기본틀이 잡혔으니 비로소 본격적으로 내가 원하는대로 어플리케이션을 다듬을 수 있는 준비가 되었습니다.
마지막으로 또 한번 느끼게 된 것이지만, UI를 만드는 작업은 결코 간단하지 않았다는 것입니다. 백엔드만 경험했던 사람으로써 프론트엔드 엔지니어분들이 얼마나 수고로우면서도 중요한 작업을 하는지 매우 크게 느낍니다. 유저 인터페이스를 멋지게 만들어주시는 프론트엔드 개발자들에게 다시 한번 감사하게된 지난 몇 주였습니다.
지난 번에 React과정을 배우면서 Redux의 활용방법에 대해 짚고 넘어가지 못한 것이 못내 아쉬웠습니다. 그래서 이 번 글에서 다루어보기로 했습니다. Redux의 개념에 대해 다시 짚어보았고 어떤 방식으로 사용되는지에 대해 알아보았습니다.
Redux는 기본적으로 React에서 지원하는 상태관리(state management) 도구입니다. 기존에 useContext 및 useReducer를 혼용하여 상태관리를 구현한 방법을 쉽게 자동화할 수 있도록 만든 툴이죠. 흥미로운 것은 이 Redux가 상태를 어플리케이션의 각 컴포넌트 단위로 보는 것이 아니라 어플리케이션 그 자체의 상태를 본다는 점이었습니다.
갈수록 프로그래밍 관련 기술은 진화하고 있습니다. 모든 기술의 진보는 "개발할 때 어떤 불편한 점이 있는데 그것을 자동화 혹은 단순화할 수 있지 않을까?"하는 고민에서부터 시작합니다. 우리가 사용하는 모든 편리한 라이브러리나 패키지들이 이러한 고민을 해결하는 솔루션으로 등장했다는 사실을 다시 한번 더 상기하게 되었습니다.
Redux를 리뷰해 보면서 앞으로 개발을 배우면서 만나게되는 답답하거나 불편한 점들에 대해서 반드시 그걸 해결한 어떤 솔루션을 누군가가 만들지 않았을까하는 생각을 더 하게될 것이라고 생각합니다. 혹여나 아직 특정 문제에 대한 솔루션이 만들어지지 않았다면, 그 문제를 해결할 수 있는 솔루션을 직접 만들어보는 것이 굉장히 포트폴리오나 이력에 도움이 될 수 있을 것 같다는 생각도 하게 되었습니다.
Redux의 개념 리뷰와 사용 방법을 짚은 글을 공유합니다. 다음 글에서는 이 Redux를 실제로 활용해 본 예제를 다룰 계획입니다.
Redux는 기존 prop-drilling에서 비효율적이던 상태(state) 관리 방법을 개선한 솔루션입니다. Redux가 도입되기 이전에는 부모 컴포넌트가 자녀 컴포넌트를 위해 React 상에서 사용하지 않아도 자녀 컴포넌트를 위해 상태 정보를 들고 있어야했습니다. 마치 부모가 교과서를 읽지 않아도 아이가 나중에 쓸떼를 대비해 가지고 있어야하는 것이랄까요? 정작 필요한 사람이 정보를 가지고 있는 것이 아니라, 필요하지 않은 주체도 필요한 다른 주체를 위해서 모두 정보를 가져야한다는 사실 자체는 비효율적일 수 밖에 없었습니다. 이 때문에 Redux를 활용하지 않았을 때에는 어플리케이션이 무거워지고 성능이 느려지는 문제가 있었습니다.
반면 Redux는 중앙 저장 개념인 Store에 상태 정보를 저장하고, 이를 action과 reducer를 통해 업데이트하는 개념입니다. 상태 정보를 관리하는 주체가 컴포넌트가 아닌 독립된 주체가 된 것이죠. 부모는 더 이상 아이를 위해 교과서를 가지고 있는 것이 아니라, 책장에 꽂아 놓을 수 있게 된 것이죠. 이 덕분에 상태 정보를 별도로 관리해 여러 컴포넌트가 사용하지 않아도 가지고 있을 필요가 없어졌고, 전역(global)으로 모든 컴포넌트가 어플리케이션의 상태 정보를 원할 때 언제든지 접근할 수 있도록 했습니다. 결과적으로 어플리케이션 개발의 효용성과 성능을 높였습니다.
이런 솔루션을 고안해내는 사람들에게 매우 감사하다는 마음을 다시 한번 가지게되었습니다. 이러한 문제들이 해결된 상태에서 웹 개발을 배울 수 있음에 감사합니다. 그렇지 않았다면 제 프로그램은 매우 비효율적으로 작성되었을테니까요. 요즘 React가 지원하는 수많은 유용한 도구들에 감탄하는 중입니다. 제가 모르는 또 어떤 것이 있고, 또 어떤 것이 발견되고 해결될지 앞으로 React 생태계의 발전이 기대됩니다.
React를 배워 프로젝트에 활용하던 중 몇 가지 의미있는 에러를 마주했습니다. 다른 모든 소프트웨어 개발자나 지망생들이 그렇듯 구글링을 통해 문제를 해결해 나갔습니다. 그럼에도 불구하고 비슷한 문제를 마주하게될 경우 다음에는 더 빨리 해결할 수 있도록 기록해 놓자는 생각이 들었습니다.
VSCode상에서 React를 활용하고보니, Git을 제대로 초기화하지않거나 잘못된 경로로 초기화하여 10000만개가 넘는 변경 사항이 한꺼번에 감지된 상황이 있었습니다. 또한 React의 특정 컴포넌트를 수입(import)해 놓고 정작 메인 코드에서는 사용하지 않거나, 사용하더라도 Key prop 규칙을 준수하지않아 Eslint가 에러를 출력하는 상황도 발생했습니다.
이러한 상황들을 마주하고보니, 개발에 있어 상당히 많은 안전장치가 존재한다는 것을 깨달았습니다. Git은 사용자에게 현재 작업하는 폴더가 제대로 된 경로에 있는지를 체크하게하고, Eslint는 React 개발자로하여금 코드가 안정적으로 작성되었는지 확인하게 끔 합니다. 결국 이러한 에러를 유저에게 보여주는 것은 프로그램을 더욱 안정적이고 효율적으로 작성하게끔 유도하는 일종의 가이드 역할이기도 하다는 것을 알게 되었습니다.
그러니 에러를 미워하지 말자는 생각이 들었다. 그 모든 에러들은 오직 내가 더 좋은 코드를 작성하게끔 도와주려는 것 뿐이니까, 오히려 프로그래밍 세계처럼 내가 잘 못한 것을 바로 바로 이야기해주는 존재가 있다는 것이 많은 개발자에게는 상당히 감사하게 받아들여 질 것 같다는 생각을 했습니다. 실패가 성공의 어머니라는 것은 어쩌면 진부한 말일지 모르나, 프로그래밍을 공부하다보면 부정할 수 없는 사실이라는 생각을 하게됩니다.
오늘도 모든 에러나 문제와 맞서는 모든 이들을 응원하며, 나의 React 실패 및 문제 해결 기록을 공유합니다.
