📌 지원하게 된 계기

나는 공부를 좋아한다. 스스로 찾아 흥미있는 다양한 분야의 지식을 익히고 그것이 나에게 미치는 영향을 좋아한다. 개발관련공부도 그렇게 시작하였다. 그 동안 사이버대학컴공과에 다니며 독학을 계속해나가나가 이왕 할거 빨리 공부마치고 취직해보는 것이 게 낫지 않을까? 라는 생각이 들었다. 슬슬 취업할 시기이기도 하고. 그래서 적당히 부트캠프를 알아보다가 마침 지원시기도 맞고 걸려들은 데가 여기라서 들어왔다. 어차피 프론트엔드관련 부트캠프는 기술스택도 비슷할테니 상관없겠지라는 생각이었다.

📌 코트캠프가 공부하는 방식

부트캠프특징답게 진도가 무섭게 빠르다. 하지만 능동적으로 열심히 하시는 분들은 무리없게 따라올 수 있도록(물론 머리는 많이 깨지겠지만)커리큘럼이 설계되어 있어서 이 부분은 문제없어 보인다. 오전 3시간동안 개발관련 수업을 진행하고, 이후에 자습과 블로깅, 알고리즘문제풀기등을 하다가 5시쯤에 알고리즘세션을 진행하고 오후 9시까지 과제를 하는 식으로 이루어진다. 오전에 듣는 수업은 자바스크립트,리액트,graphql 그 외 코드캠프에서 기재한 기술스택에 따른 수업을 진행한다(꽤 최신스택들이 많다). 수업방식은 온라인강의와 비슷하게 현직개발자가 실무관련 개념과 실습을 진행한다. 배울내용이 엄청많지만 그래도 아는대로 상세하게 설명하려는 노력이 보인다. 이후 배운내용에 관한 실습과제가 주어지고 수강생들은 이 과제를 다음날 오전 9시까지 완료하여야 한다. 하지만 이 과제내용은 수업만 제대로 들었다면 코드복붙수준으로 거의 다를 게 없는지라 과제자체는 중요한 게 아니고 그날배운 개념을 정리하는 용도로만 생각하면 되겠다. 또한, 알고리즘관련해서 프로그래머스에서 출제하는 문제로 40일동안 알고리즘세션을 진행한다. 아마 40일 이후에는 팀프에 들어가는 것 같으므로 이 40일동안의 알고리즘문제가 이곳에서 진행하는 알고리즘의 전부라고 할 수 있을 것같다. 기술면접이나 가고자 하는 회사에 코테가 있는 경우 부족한 점이 많으므로 별도의 준비가 필요해 보인다. 배운 내용을 바탕으로 포트폴리오를 제작한다. 강사가 알려준 기능이나 코드를 자신의 포트폴리오나 팀프로젝트에 적용하여 결과물을 내는 것인데, 여기서는 강사가 샘플포폴을 제공하기 때문에 거기서 보고 붙이기만 해도 그럭저럭 기능하는 포폴이 완성되고, 팀프로젝트에서 구현되는 기능도 크게 여기에서 벗어나지 않는 것으로 보인다.

📌 코트캠프 장점

빠르게 실무관련 기술스택과 기능구현을 해보고 싶다면 적당한 곳이다. 이에 관한 집중할 수 있을 만한 환경과 과제들이 주어지기 때문이다. 따라서 정말 필요시되는 실무관련 내용만 빠르게 준비해서 취업하고 싶은 사람에게는 유리한 과정이다.

📌 코트캠프가 단점

• 페어프로그래밍의 부재 여기서는 1주일에 한번씩 책상을 옮기면서 페어를 바꾸고 주에 한번씩 페어리뷰를 한다.

   하지만 말만 페어고 페어와 하는 일은 사실상 없다. 페어와 퀴즈를 푼다거나 같이 과제를     해결한다거나 그런건 없고 그냥 두루두루 친하게 지내라는 의도로 보였다.

• 사라진 "왜" 라는 질문 코드스테이츠나 42서울처럼 자발적으로 학습하지 않으면 안되는 환경과는 정 반대이다. 멘토나 강사들은 수강생들이 시간은 부족해도 이것저것 하나라도 알려주려는 타입이고, 수업중에 모르는 게 있으면 그냥 손을 들어 멘토님을 부르면 된다. 이것은 장점으로 보일 수 있겠지만 나에게는 오히려 큰 단점으로 보였다. 스스로 학습할 줄 모르는 개발자가 당장에 취업은 가능하더라도 과연 필요할까? 아니, 그게 내가 원하는 개발자인가? 라는 의문이 들었던 것은 사실이다. 하지만 그동안 한국식 주입식교육에 익숙해져 있는 사람들에게는 편하긴 할 것이다. 처음보는 지식을 되는 대로 상세히 알려주기 때문에 배우는 과정에 대해 의문을 가지고 스스로 찾아 학습하는 학생은 여기서는 그다지 메리트있는 학생은 아니다.

• 왜 있는 지 모르겠는 멘토링모임과 티타임 2주에 한번씩 있는데 수강생과 멘토가 모여 수다를 떤다. 많은 명목과 의도가 있었겠지만 사실상 친목성 수다타임이다.

• 일관된 수강생들의 포트폴리오 자율적인 분위기에서 제작하는 포트폴리오가 아니라 기능구현과 상세까지 전부 주입당한 상 태로 제작하는 포트폴리오이기 때문에 사실상 공장식이 아닐까 의심된다. 이 부분은 내가 그 포폴을 받아보는 면접관입장이 아니기 때문에 단언할 수는 없지만 상당히 디메리트로 작용한 건 사실이다. 여기의 과정은 배우는 기능과 구현을 포트폴리오에 (필수!!)로 적용하게끔 설계되어있기 때문에 같은 과정을 밟는 수강생들의 포폴은 디자인에 큰 차이는 있을 수 있어도 그다지 다르지 않을 것이다. 그리고, 최종팀프에서 배우지 않는 기능을 활용하는 사람은 아마... 전에 배웠던 사람일 확률이 매우 높다.

📌 총평

여기서부터는 진짜 내 개인적인 판단이므로 여기까지 봐도 무방하다.

부트캠프는 특정한 목적을 가지고 모인 곳이니만큼 각각의 성향과 장단점이 확실하는 것을 이번 경험을 통해 느꼈다. 실무적인 것을 빠르게 배워서 취업한다는 면만 살펴보면 여기도 꽤 괜찮다고 여길 수 있을 것이다. 모든 것을 커버할 수 있는 부트캠프는 없으므로. 하지만 여기서 공부하면서 내가 지향하는 학습방향과 개발자상에는 심하게 맞지 않는 괴리를 자주 느꼈고 그 과정에서 내가 목표로 하는 것을 더 명확하게 할 수 있었다. 그리고 여기서 추구하는 목표가 나와는 상반된 것이라는 것을 깨달았다. 그걸 부트캠프에 들어가기 전에 판단했어야 하는데 판단하지 못하고 무자각하게 발을 들인 것은 내 최대의 실수이다. 그래도 짧은 시간동안 꽤 괜찮은 실무지식과 동료를 얻었으므로 나에게 손해만 있는 경험을 아니었다고 생각한다. 이 경험을 바탕으로 앞으로 회사나 어떤 모임에 들어가기를 고려할때 어떤 자세를 가져야 하는지 배웠다. 그리고 그것에 대한 책임까지도.

생각해보면 과거의 나는 중학생시절부터 불만히 굉장히 많았던 아이였다. 12~13세 즈음이었던가 굉장히 잘 상처받고 굉장히 미성숙하고 불안정했던 때 했던 경험이 인생자체에 있어 하나의 가치관 혹은 신념자체를 만들어버린 게 아닐까 싶다. 그때까지의 나는 스스로 무언가를 해서 성공해본다거나 본인의 의지로 뛰어들어 무언가를 얻어본 경험이 없었다. 우리집은 가난했었기때문에 나는 중학교를 들어가기 전까지 뚜껑달린 폴더폰을 사용했고 미디어의 사용은 가끔보는 티비콘텐츠를 제외하고는 거의 없었다. 사람을 만나고 친구를 만드는 게 시원찮았던 나는 거의 필연적으로 도피처를 찾듯 집근처에 있는 도서관을 찾아 시간을 보내곤 했다. 누구에게도 명령받거나 속박받지 않는 자율적인 공간에서 그 때 처음 배움이라는 걸 알게 되었다. 책을 읽는게 그 무엇보다 재미있었다. 그 때 이후부터 명확하게 표현하지는 못했지만 내 안에서 어느정도 고리타분하고 눈물고름이 앉아있는 현실에서 배움이 내게 주는 의미가 무엇인지 가슴시릴정도로 각인되었다. 다시 중학생때로 거슬러 올라가서, 생각과 신념에 조금씩 살이 붙은 미성숙한 나는 배움이 존재하지 않는 학교에 굉장히 불만이 많았다. 어떤 형식이든 지식을 전수하고 배움이라는 걸 실현하는 곳은 교육철학이 필요하고, 이 것에 심각한 부재가 일어난다면 그것은 더이상 교육이 아니라 세뇌다. 교육이란 생각하는 방법을 가르치는 것이라는 공식이 어느정도 자리를 잡은 상황에서 내가 처한상황에 대해 최대한 객관적으로(물론 미성숙한 그때의 나는 가능하진 않았겠지만,) 보려 노력하였을 때 거의 감옥이나 다름없는 공간이었던 것이다. 이건 나와 같은 생각을 가지지 않은 또래의 아이들에게도 비슷하게 여겨졌을 거라 생각한다. 나는 그 공간에서 과하게 감정적으로 억눌려져있음을 느꼈다. 그래서 나름의 해결책이랍시고 그동안 내가 느낀점과 현시스템에 대한 부정적인 영향등을 곰곰히 생각한 뒤 종이 한켠에 적어서 당시 학교에서 가장 젊고 생각이 열려있는(그렇게 생각되어지는) 선생님에게 편지를 보냈다. 그때가 중학교 2학년이었다. 그 당시 선생님에게서 받은 답변은 내가 기억하는 바로는 이랬다. "너의 생각에 대해선 충분히 이해하고 공감하고 있어. 하지만 이건 일개 선생이 어찌할 문제가 아니고 나로는 도와줄수있는게 없어" 이 말을 듣고나서는 학교에 대한 긍정적인 시각을 아예 버린 거같다. 사실 엄청 울었었다. 서두가 너무 길었는데 좀 거친 말투로 요약하자면 학생들에 비해 상대적으로 지식이 있다고 여겨지는 사람이 앞에 서서 자기가 하는 이야기가 모두 옳다는 마냥 열심히 떠들어대면, 학생들은 어떤 의문이나 스스로에 대한 사고없이 묵묵히 고개를 숙여 다 들어오지도 않는 그 이야기를 머릿속에 넣고 있으면, 그게 교육이고 학습이라는 것이 내가 처한 현실이었던 것이다. 다른사람들은 어떻게 느낄지 모르겠지만 그 사실은 내게 굉장히 끔찍하고 어떨때는 비인간적으로 느껴지기까지 했다. 거기에서 무시당하는 개개인의 사고가 어떨지 누구보다 잘 알고있으므로.

그래서 나는 스스로 배움을 추구하고, 실현하고 성장할 수 있는 사람이 되고 싶었다. 아무리 못나고 미성숙하고 바보같아도 스스로 행동할 줄알고, 배울줄 알고, 성장할 수 있는 사람이라면 거기에 살아갈 가치가 있는게 아닐까? 더 나아가서 직업적으로 구애받지 않고 이러한 자신의 생각을 이어나갈 수 있는 일을 하며 살고싶었다. 굳이 말하자면 딱히 개발자가 아니어도 상관없었다는 의미이다. 하지만 작년 3월부터 뛰어든 개발관련 교육과정(어디라곤 말하지 않겠다)을 맛보면서 생각이 많이 바뀌었다. 처음으로 누군가와 열띄게 토론하며 지식을 얻고 내가 나서지 않으면 아무것도 얻을 수 없는 곳에서 스스로를 곱씹을 수 있었다. 내가 줄곧 생각해왔던 배움이 그곳에 있었던 셈이다. 그동안 굳게 마음속에 자리잡고 있었지만 이상만 떠들어대는 얼간이취급을 받을까 제대로 밖에 내지못했던 것들이 실제로 존재하고 심지어 내가 그 속에 뛰어들수 있다는 사실에 가슴이 뛰었다. 자신이 그동안 한 우물에서 원하던 것을 찾고 찾지못해 절망하고 있었다는 사실을 깨달았다.

요지는 이렇다. 나는 스스로 배우며 성장하는 사람이 되고 싶고, 개발자가 되려는 것은 그 목적을 위한 것이다. 내가 정말 될 수 있고 할 수 있냐는 문제는 뒤로하고, 내가 가려는 방향과 맞다고 생각하면 그걸 추구하는게 맞지 않을까?

게시판 포트폴리오를 작성하던 와중에, 새로운 게시판을 생성할 수 있는 버튼을 누르면, 팝업창처럼 밑에서부터 게시판작성창이 튀어나와 입력할 수 있는 구조로 만들어보고 싶다는 생각이 들었다. 그래서 해당 게시판 작성 conponent를 만든 뒤에 레이아웃에 이 콤포넌트를 배치하려고 하는데, 원하는 대로 구현되지 않아 난항을 겪었다. 이 콤포넌트를 현재페이지의 wrapper태그 안에 넣으면 원하는 옵션에 있어 css가 제대로 동작하지 않는 문제가 발생하였다. 이에 관련해 비슷한 방식으로 작성폼을 지원하고 있는 여러 사이트를 서치한 결과, 현재 보고있는 html엘리먼트 의 자식엘리먼트로 이 콤포넌트를 넣는게 아니라, 새로운 형제 엘리먼트를 생성한뒤, 이 엘리먼트를 z-index로 위로 쌓은다음, fixed포지션으로 뷰포트기준으로 크기와 위치를 고정시킨 다음에 그 안에 자식 엘리먼트로 원하는 게시물작성 콤포넌트를 넣었더니 제대로 동작하였다.

Differences between Functional Components and Class Components in React React Docs React Class Component vs. Functional Component: What’s the Difference Build the future of communications.

🔍 배경지식

• React에서는 두가지 방법으로 Component를 작성할 수 있는데, function Component와 Class componenet가 그 두가지이다.

• React 16.8에서 hooks가 등장하기 이전에는, 오직 Class Component에서만 state와 lifecycle methods에 접근할 수 있었지만 이제는 UI를 구성하는데 필요한 모든 기능을 hooks로 구현가능하게 되었다.

• 최근에는 function Componenet가 조금 더 대중적으로 사용되고 있다.

📍 클래스형과 함수형 컴포넌트의 차이

📎 function Componenet

    - JS의 함수와 같은 기능을 하는 컴포넌트로, props를 전달인자로 받아 React elements를 반환한다. 
    - Class Component 에서 사용되는 lifecycle메소드를 사용할 수 없는 대신,useState 또는 useEffect같은 hooks를 통해 간단하게 UI를 구현할 수 있다.



📎 Class Component 

    - Class Comnenet는 기본적으로 React로부터 상속받는다.그리고 Render()을 통해 React element를 반환한다. 
    - componentDidMount()같은 lifecycle methods를 사용할 수 있다. 
    - Constructor을 통해 state를 관리한다.

📍 함수형 컴포넌틀 주로 사용하는 이유

  ⬇️함수형⬇️

    const FunctionalComponent = () => {
       React.useEffect(() => {
         return () => {
           console.log("Bye");
         };
       }, []);
       return <h1>Bye, World</h1>;
      };

⬇️클래스형⬇️

 class ClassComponent extends React.Component {
     componentWillUnmount() {
       console.log("Bye");
 }

 render() {
   return <h1>Bye, World</h1>;
 }
}

Hook을 사용하면 컴포넌트로부터 상태 관련 로직을 추상화할 수 있습니다. 이를 이용해 독립적인 테스트와 재사용이 가능합니다. Hook은 계층의 변화 없이 상태 관련 로직을 재사용할 수 있도록 도와줍니다. 이것은 많은 컴포넌트 혹은 커뮤니티 사이에서 Hook을 공유하기 쉽게 만들어줍니다.

두 작성방법을 비교하였을 때, 더 간결하고 이해하기 쉬운 코드를 작성할 수 있고, 클래스에 비하여 상태관련로직에 있어서 유지보수가 쉬운 점 때문에 react docs에서 권장하고 있다. 이 때문에 불필요한 코드를 최적화하여 클래스보다 나은 성능을 기대할 수 있다. 또한, class에서 사용되는 this를 사용하지 않기 때문에 불필요한 혼동을 줄일 수 있다고 한다.

JS 엔진은 코드를 읽어 올 때,모든 변수를 스코프의 최상단으로 끌어올려 선언 한 뒤 런타임을 작동시킨다. 선언이 되었지만 아직 런타임이 동작하지 않아 할당되지 않은 변수의 초기값은 undefined로 초기화되고 만약 변수를 할당하기 전에 이 변수값을 콘솔로그에 불러왔다면, undefined라는 문구를 보게 될 것이다. 이것은 변수가 이미 선언되었지만 할당되지 않은 초기값을 불러왔다는 의미가 된다.

이를 호이스팅이라 부르고, JS는 let, function, class, const등의 모든 식별자를 호이스팅 하는 성질을 가졌다.

console.log(hoist); // Output: undefined

var hoist = 'The variable has been hoisted.';

이것이 함수나,변수를 런타임에서 직접 동작시키기 전에도 불러올 수 있는 이유이다. 이처럼, 식별자는 호이스팅 되어 초기값을 가져오는데, 변수가 선언과정에서 초기화 되기 전, TDZ(Temporal Dead Zone)동안에 불러와진 변수에 대해서는 ReferenceError 를 반환한다.

function do_something() {
  console.log(bar); // undefined
  console.log(foo); // ReferenceError
  var bar = 1;
  let foo = 2;
}

var의 경우에는 함수스코프를 제외한 스코프에 상관없이 변수를 호출할 수 있다는 기가막힌 단점이 있었지만, ES6에 추가된 문법 let 과 const의 경우에는 변수가 선언된 자리에 블록스코프가 적용되어 변수의 재할당의 문제에서 자유롭다는 장점이 생겼다. 이에 따라 let 과 const의 경우에는 실제 런타임에서 선언되기 전에 변수를 불러오면 referrenceError를 던져준다는 특징이 있다.

함수 호이스팅

함수 호이스팅은 변수호이스팅과 달리 선언즉시 함수객체가 생성되기 때문에 할당에 관여하지 않고 상단으로 호이스팅이 가능하다. 이 말은 선언된 함수를 그 위치에 상관없이 불러와 그 값을 불러오는게 가능하다는 의미이다.

하지만 여기에도 예외가 있는데, 함수표현식의 경우에는 선언과정에서 함수호이스팅이 아닌, 변수호이스팅이 작동하기 때문에, 런타임이전에는 값을 불러올 수 없다.

expression(); // Ouput: TypeError: expression is not a function

let expression = function hoisting() {
  console.log('Will this work?');
};

Error: Objects are not valid as a React child (found: object with keys {aaa}). If you meant to render a collection of children, use an array instead.

번외: 이번 router기능을 실습하고 오류코드를 분석하면서 어떤 방식으로 데이터를 주고받는지 약간이지만 감이 잡힌거 같다. 싱글벙글

Unhandled Runtime Error
Error: Objects are not valid as a React child (found: object with keys {data, status, statusText, headers, config, request}). If you meant to render a collection of children, use an array instead.

2.임포트.또 import.

Error: Minified React error #321; visit https://reactjs.org/docs/error-decoder.html?invariant=321 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

3. input의 빈태그에 값을 입력하면 이런 오류를 발견할 수 있다.

   Error: input is a void element tag and must neither have `children` nor use `dangerouslySetInnerHTML`.
   
   

``` 4. 코드에 브라켓 >> } <<를 제대로 닫지 않아서 생긴 오류 GraphQLError: Syntax Error: Expected Name, found <EOF>.

5. example.codebootcamp.co.kr/graphql:1 Failed to load resource: the server responded with a status of 400 (Bad Request) index.js?aa3d:29 Uncaught (in promise) Error: Response not successful: Received status code 400

1. 모듈을 설치안함
2. css파일을 밖으로 export안함
3. js파일 내부로 css엘리먼트를 임포트안함

//해결:결국 자동으로 import,export해주는 extension을 VSC에 추가했다.

4. npm intall안함
5. import에 문제가 있으면 이런 문구를 보게됨

Error: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: undefined. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

//해결:아래의 문구를 index파일에 추가하면 모든 요소들이 불러와짐. import * as All from './layout'; 3. 선언안하고 태그지정하면 아래의 오류메세지를 볼것.

ReferenceError: Main is not defined

This error happened while generating the page. Any console logs will be displayed in the terminal window.

6. 엘리먼트에 flex박스 설치안함
7. 돔사용법할당과 그 돔을 선언하는걸 동시에 했을 때 보이는 에러문구

Server Error

ReferenceError: document is not defined

This error happened while generating the page. Any console logs will be displayed in the terminal window.

8. useState에 초기값을 0000으로 난사했더니 나오는 오류.

“0000”으로했더니 괜찮아졌다.

ModuleBuildError

:

Module build failed (from ./node_modules/next/dist/build/webpack/loaders/next-swc-loader.js): Error: error: Legacy octal escape is not permitted in strict mode

./pages/quiz/02-state-quiz/number.js
Error: error: Legacy octal escape is not permitted in strict mode

  |
4 |     const [number,setNumber] = useState(000000);
  |                                         ^^^^^^

Caused by:
    0: failed to process js file
    1: error was recoverable, but proceeding would result in wrong codegen
    2: Syntax Error

9. padStart는 string 타입에만 적용된다.

10.가끔 알수 없는 오류로 코드에 문제가 없어보이는데도 페이지에 오류가 뜰때가 있는데, 오류메세지에 모듈어쩌고가 있다면 대부분 버전문제이거나, 필요한 기능을 install하지 않아서이다. 그럴 시에 해당폴더에 있는 package.json파일로 가서 필요한 모듈과 버전을 수정해주도록 하자. 그후 터미널에서 install하면 정상적으로 작동된다.

10. radio buttn에 onchecked여부에 따라 게시물업로드가능 상태를 지정하던 도중에 만난 오류. 대충 onchange hendler를 주지말고 form에 prop을 사용하여 처리하라는 뜻 같다. (오류메세지 너무 친절하다,..) radio태그에 chencked={}이 속성안에 맞지 않는 무언가를 부여한게 문제인거같은데 mdn을 살짝보고 오니 checked는 dom이 아니라 css관련 속성이었던 모양이다. 좀찝찝하긴하지만 아직 안 배우지 않은 내용이므로 onChange로 대신하기로 했다.

    react-dom.development.js?61bb:67 Warning: You provided a `checked` prop to a form field without an `onChange` handler. This will render a read-only field. If the field should be mutable use `defaultChecked`. Otherwise, set either `onChange` or `readOnly`.