블로그도 많이 밀리고 강의도 많이 밀렸다. 뭐 앞서 말했듯 많은 이벤트가 있었어서, 밀린 거 따라가기 벅차다^_^,, 스터디 플래너라도 써야할 판이다.

어쨌든 우여곡절 끝에 미션 1~5를 끝냈다. 그런데 아무래도 강의는 진짜 기초강의만 들은 상태에서 했고, (대충 처음 TODO에 있던 자바스크립트 강의 중 첫번째 파트만 들었고 나머지는 못 들었다는 뜻이다) 그냥 내 기억에 의존해 기존에 알던 지식 + 구글링으로 최대한 미션 요구 사항을 맞추기에 급급해서 저번 미션처럼 잘 되었는지는 확신이 없다.

JavaScript를 공부하며 느낀 점

우선 제일 큰 것은, 역시 시간 투자를 많이 해야겠다는 점이다. 앞서 언급했듯 강의를 충분히 듣지 못했고, 밀려있다. 거의 한 달(두달치인것 같기도 하다)치는 밀려있다. 또 HTML/CSS와는 다르게 기본 지식이 충분하지 않다. 그래서 진짜 어려웠다. 아직도 구글링을 해서 정보를 얻으면, 어떤 원리인지 100% 이해가 가진 않는다. 이건 내가 따로 시간을 투자해야 할 몫이라고 생각한다.

제공된 첫번째 자바스크립트 강의는 쉬웠고, 만족스러웠다. 개념을 이해하기 좋게 쉽게 풀어줬다. 물론 모르고 넘어가는 부분, 개념으로만 보면 뭔지 모르겠는 부분(ex 이벤트 버블링 등)이 존재하지만, 이것은 두번 세번 다른 자바스크립트 강의를 하며 내 이해에 빈 곳을 채우는 형식으로 공부하면 될 것 같다.

아직 두번째 것은 듣고 있어서 모르겠다. 자바스크립트의 역사부터 설명해주는데 개인적으로 a부터 z까지 다 알고 싶은지라 넘기지 않고 필기하며 공부하고 있다. 아직 제대로 들어가진 않았지만 더 디테일하게 알려주는 강의같다. 기대하고 있다.

가장 중요한 강의는 아무리봐도 토이프로젝트 관련 강의같다. 여러모로 얻어갈 게 많아보여 기대된다.

전반적으로는 이번 기회에 개념을 확실히 잡고 갈 수 있을 것 같다는 생각이 들었다.

JavaScript 공부하면서 어려웠던 개념과 이유

이 부분은 내가 지금 말을 할 수 있는 상태인지 잘 모르겠다. 충분히 공부하지 않았다.

다만 미션을 하며 제일 어려웠던 부분은 역시 자바스크립트의 구조 이해였다. 이 파일이 어떻게 저 파일에 있는 데이터에 접근할까, 이벤트 위임을 어떻게 해야할까 등등 계속하면서도 매번 헷갈리고 머리를 싸매기도 했다.

data down, action up의 방식이 익숙해서 그렇게 미션을 하다가도 요구사항에서 다르게 하라는 말을 보고 처음부터 다시 해야 하는 상황 등등 많이 어려웠다.

제로베이스 온라인 강의 중 가장 도움이 되었던 강의와 이유

자바스크립트 강의라면 아직 안 들었다만 토이 프로젝트가 가장 도움이 될 것 같다. 깃허브 채우기도 용이하며 토이플젝 강의에 있던 내용들이 미션에 많이 등장했다. 아마 내가 강의만 안 밀렸다면 더 수월했을지도 모르겠다. 그리고 개념만 주구장창 익히는 것보단 실습이 훨씬 도움되는 건 사실이지 않나. 따라서 이런 이유로 토이프로젝트 강의가 가장 도움이 된다고 생각한다.

나만의 공부팁

무조건, 실습을 해야한다. 개념정리만으로는 내것으로 만들 수 없다. 라고 HTML/CSS 후기에 말했는데, 변한거 하나도 없다.

실습이 제일 중요하고 수술 이슈, 이사 이슈, 건강 이슈 등으로 1월을 통으로 날리고 미션 한다고 2월을 2주를 그냥 날렸다.

이정도 밀리면 답 없다. 이월할 생각은 더 없다.

하루 빨리 생활 패턴을 찾고, 스터디플래너를 작성해서 따라잡아야 한다.

React는 써봤지만, Vue는 진짜로 초면이라, 3번째 미션하려면 죽어라 공부해야할 것 같거든,,,,,

아 그리고 1월에 아프면서 느꼈다. 밤은 새지 말자.. 건강관리도 능력이다.

​

2개월 차 좋았던 점

자바스크립트를 둘러볼 수 있었다. 이미 HTML/CSS는 유연하게 할 줄 알던 편이라고 자부한다. 실제로 제로베이스에서 미션을 하며 우수과제로 선정되기도 했다. 그치만 난 그동안 코딩을 했던 모든 순간을 다 HTML/CSS에만 사용했으니 어찌보면 대단한 성과는 아니다. 그만큼 다른 부분이 다 부족하다는 것을 너무 잘 알기에 빨리 알고리즘 공부를 하고 싶었고 자바스크립트를 배우고 싶었다. 1월에 정말 많은 일이 있었다. 예상치도 못한 일들이라 강의를 말도 안되게 많이 밀렸는데..... 이걸 언제 다 따라잡냐... 싶다. 정말 계획대로 지켜진 게 하나도 없는 2개월 차, 그나마 만족스러운 점은 자바스크립트를 처음부터 끝까지 개념을 스윽 익혔단 것.

1개월 차에 수정한 학습 계획대로 공부하고 있는가?

아니다.

우선 한 일주일은 게을렀던 것 같다. 그리고 남은 기간동안 충분히 따라잡을 수 있을 것이라 생각했던 것도 사실 있던 것 같다. 근데 1월 중순 즈음 갑작스럽게 아팠다. 감기인지 뭔지,, 컨디션이 너무 좋지 않았다. 밤샘이 잦았던 게 원인인지,, 그렇게 3일 정도를 날릴 수밖에 없었다.

엎친 데 덮친 격으로, 예상치 못하게 1월 말에 어떤 수술을 하게 됐고, 그 회복기로 1주일은 정말 아무것도 못했다.

또 최종적으로는, 2월 중에 이사를 하기로 결정하게 됐다. 집을 보러 가고, 계약을 하고, 집 정리를 하고, 이사 업체를 찾고... 이사를 한다는 게 쉬운 일은 아닌데 이 모든 게 1월에 한번에 일어났다.

블로그를 밀려서 쓰는 이유이기도 하다. 강의도 어마어마하게 밀렸고, 자바스크립트 미션이나, 코딩테스트, CS퀴즈 등만 버겁게 따라갔다.

이제 슬슬 모든 게 마무리가 되고 있으니 하루빨리 다시 페이스를 찾아 늦더라도 천천히 한단계 한단계 따라잡아야 한다.

나머지 4개월 간의 학습 계획

어찌보면 앞의 내용도 핑계라고 생각한다. 더 할 수 있는데 안 한 것도 분명히 있겠지. 충분히 쉬엄쉬엄 했다고 생각해..

그래서 나머지 4개월 간의 학습 계획은....! 하루에 체크리스트 3~4개씩 지우기. 빡센 날도 있고 아닌 날도 있겠지만, 그렇게 하다보면 어느 순간 진행율을 따라잡을 수 있을 거라 생각한다.

뭐가 됐든, 나는 중도 포기는 하기 싫다. 기수 이월제도 있는 걸로 아는데, 그것도 하기 싫다. 이왕 하기로 했으면, 최선을 다해 성공시켜보고 싶다. 분명 제로베이스 이거 빡세고, 힘들다. 근데 더 힘든 게 살면서 얼마나 많겠어, 본격적인 취준은 더 힘들지 않을까!

아직 2개월밖에 안 지났다. 다시 정신차리기. 만회할 수 있다.

내용이 어렵다기보다는.. 뭐라고 설명해야 할까, 아무래도 프론트엔드 개발 경험이 있다보니, 자꾸 더 쉽게 갈 수 있는 길이 머릿속에 떠올랐다. 미션에서 요구하는 조건, 방법 등을 보면서도,

'아, 이건 flex를 이용하면 해결되는 건데 굳이 이 방법을 사용해야 하나?' '이건 grid로 해결할 수 있는 건데 굳이 float를 사용해야 할까?' '자바스크립트의 코드만 살짝 고치면 되는데 이걸 꼭 css로 다 구현해야 할까?'

하는 이런 '굳이?'라는 마음을 버리는 게 어려웠다. ​ 나는 제대로 배우지 않은 상태에서 프론트엔드개발을 시작했다보니 안 좋은 습관이 많이 있어서, 미션 요구사항을 읽어가며 그 습관을 버리는 것도 시간이 많이 소요됐다.

결론적으로는 미션당 짧으면 4시간 길면 8시간 정도를 소요해서 어렵사리 끝냈다. ​ 오늘은 미션 하나하나에 대한 회고보다는 전반적인 HTML/CSS를 공부하며 느낀 점에 대해 적어보려 한다.

HTML/CSS를 공부하면서 느낀점

전반적인 강의나 공부 내용은 만족스러웠다. 이전에는 항상 마음 한 켠에 제대로 알고 넘어가지 못한다는 부분이 걸렸었는데, 그 부분에 있어서는 걱정과 갈증이 확실히 많이 해소된 것 같다. 제일 처음 들었던 생각은, 나는 그동안 정말 잘못된 코드를 작성했었구나 였다. ​ 나는 항상 inline style을 사용했었다. 별 이유가 있는 건 아니었고, 처음에 배울 때 그렇게 배웠었다. 아무래도 별도의 less 파일을 만들지 않고 코드 내에서 바로바로 확인할 수 있었으니까. 물론 요즘은 css파일이나 less 파일보다도 tailwind css를 더 많이 이용하는 추세라 나중에가서 어떤 식으로 내가 프로젝트를 할지는 모르겠으나, 일단 좋지 않았던 습관 중 하나를 버릴 수 있었던 것 만으로도 꽤 큰 수확이 있었다고 생각한다. ​ 내가 큰 수확 중 하나라고 생각하는 또 다른 부분은, 선택자에 대해 배운 것이다.

대충 hover, focus, active, [data-state]와 같은 선택자 빼고는 딱히 사용해 본 적이 없었다. 그래서 nth-of-type이라던지, before, after 등등을 배울 수 있던 것이 좋았고, 다중선택 선택자, 범용 선택자 등 여러 종류의 선택자를 배울 수 있어서 좋았다.

늘 하위 요소를 선택하는 것, 형제 요소를 선택하는 방법 등등이 헷갈렸는데, 그 부분을 다 배울 수 있어 다행이라는 생각이 들었다.

(잊을 때쯤에 또 다른 종류의 HTML/CSS강의가 과제 체크리스트에 있어서, 기억의 유효시간이 지나기 전 복습할 수 있다는 게 얼마나 다행인지) ​ 조금 느릴 수도 있지만, 무작정 높이 쌓아올리는 것이 아닌 기초를 다지면서 쌓는 것이 중요하다는 걸

머리로는 알았지만, HTML/CSS 공부를 하면서 체감할 수 있었다.

HTML/CSS 공부하면서 어려웠던 개념과 이유

솔직히 말하면.. 쉽다고 느껴지는 부분은 없었다. 쉬운 개념도 깊게 파헤치다보면 너무 많은 경우의 수가 있어서, 모든 걸 이해하기보다는 어느정도 개념을 이해한 후, 그때그때 구글링하며 배워가는 것이 효율적일 것 같다는 생각이 들었다. 예전에 같이 일했던 개발자가 모든 것을 이해하고 넘어가는 건 불가능하다고 한 이유를 알 것 같다. ​ flex로 모든 걸 해결하는 게 익숙해, grid가 나오면 한번씩 버벅거리거나 내가 정리해 놓은 문서를 읽어본다. 미션을 하면서 그래도 어느정도 익숙해지긴 했으나, 지속적인 연습이 필요할 것 같다. ​ 근데 이제 float가 정말..^^ 그래도 해야지,,,

그건 아직도 완전히 이해가 가지는 않는다. 공부를 하며 대충 어떤 경우 사용하는지 개념을 이해했는데, 미션으로 넘어가니, grid의 역할을 float를 통해서 작성하라고 되어있었다.

마침 해당 부분 강의를 듣고 있어서 다시 실습을 따라해보며 다시 이해한 후 미션은 성공적으로 마무리했으나 시간이 흐른 뒤 또 이런 과제나 미션을 받게 되면 또 헷갈릴 것 같아 조만간 다시 HTML/CSS 복습을 해야겠다. ​ 그 외에는 선택자 before과 after가 조금 헷갈렸고, 아직 자바스크립트를 완전히 익히지 못해, 자바스크립트와 연계된 미션을 수행할 때 시간이 다른 미션보다는 오래 걸렸던 것 같다.

제로베이스 온라인 강의 중 가장 도움이 되었던 강의와 이유

HTML/CSS 중에서는 역시, 기본부터 끝까지 러닝메이트 HTML/CSS 강의가 가장 도움이 되었다. 재차 말하지만 나는 CSS를 기본 배경부터 배운 것이 아니라 냅다 실전 업무를 하며 익힌 케이스였다. 그래서 이런 상황에 이렇게 하면 되는구나~는 알지만, 이게 어떤 원리로 해결되는지는 잘 모르는 상태였다.

이 강의가 제로베이스 커리큘럼상 첫 강의였는데, 솔직히 말해서 미션을 다 끝낸 지금까지도, 다른 HTML/CSS 강의들도 물론 도움이 되었지만, 기본부터 끝까지 러닝메이트 HTML/CSS 강의가 나에게 필요한 부분을 채울 수 있었다고 생각한다.

나만의 공부팁

무조건, 실습을 해야한다. 개념정리만으로는 내것으로 만들 수 없다. ​ 그리고 솔직히 나도 잘 지키지 못하고 있지만, 제로베이스를 본격적으로 시작한지 한달이 조금 넘었는데, 아무래도 부트캠프 특성상 다양한 내용(HTML/CSS, JavaScript, CS이론 등등)을 한번에 머리에 욱여넣다보니 뭐랄까, 하루동안 들어오는 정보량이 과하다. ​ 그래서 무작정 강의만 듣고 필기만 하는 것으로는 절대 충분하지 않다. 지금으로써는 제로베이스에서 제공하는 커리큘럼을 따라가는 것만으로도 벅차지만, 그리고 미션이 생각보다 시간이 소요돼서 강의가 밀리기 시작했지만.. 더 밀리기 전에 이제부터 며칠 밤을 새서라도 밀린 강의를 다 듣고, 하루빨리 복습의 시간을 만들어야한다는 생각 뿐이다.

폰트 프리로드는 웹 페이지 성능을 향상시키기 위한 기술로, 실제로 필요한 시점보다 먼저 폰트 파일을 불러와 미리 캐시하는 방법이다.

즉, 프리로드 링크를 사용해 폰트를 불러오면, 폰트 파일이 페이지의 나머지 부분이 로딩되는 동안 백그라운드에서 다운로드 된다.

이 말은, 텍스트 렌더링에 소요되는 시간을 줄여, 폰트가 필요한 시점에 사용자가 다운로드를 기다릴 필요 없이 바로 사용이 가능함을 의미한다.

​

​

​

​

폰트의 preload 방법

일반적으로, HTML의 link 요소를 이용해 폰트를 preload한다.

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

rel="preload" : 리소스를 프리로드 해야 함을 나타냄. href="font.woff2" : 폰트 파일의 URL을 지정 as="font" : 프리로드되는 리소스의 유형, 이 예시의 경우 폰트. type="font/woff2" : 리소스의 MIME 유형 crossorigin : 브라우저에게 요청이 교차 출처인 경우에도 폰트 파일을 가져오도록 허용

​

다른 방법으로는 CSS의 @font-face를 사용하여 폰트를 정의하고, preload를 통해 프리로드할 수 있다.

아래 예시 첨부:

@font-face {
    font-family: 'YourFontFamily';
    src: url('your-font.woff2') format('woff2');
    font-weight: normal;
    font-style: normal;
}


/* 프리로드를 위한 스타일시트 */
[rel="stylesheet"][href="your-font.woff2"] {
    as: font;
    type: font/woff2;
    crossorigin;
}

​

이 CSS 코드에서 @font-face는 폰트를 정의하며, 그 아래의 스타일시트 부분에서 폰트를 프리로드한다.

as, type, crossorigin 속성을 이용하여 프리로드와 관련된 설정을 추가할 수 있다. 관련 설정은 HTML과 같다.

​

​

​

​

로컬 폰트가 있을 때 로딩 방법

위에 언급한대로 CSS 코드에서 @font-face를 사용해 로컬 폰트를 불러올 수 있다.

​

@font-face {
    font-family: 'Poppins';
    src: local('Poppins') url('Poppins.woff2') format('woff2');
    font-weight: normal;
    font-style: normal;
}

​

​

​

​

웹폰트만 로딩해야하는 상황에서 최적화

앞서 말한 HTML link를 이용한 프리로드를 진행한다.

​

​

​

​

폰트 파일 최적화 방법

1. 웹 폰트를 사용한다. : 특정 폰트가 사용자의 브라우저에서 지원되지 않을 경우 대체할 수 있는 폰트를 지정할 수 있다

2. 폰트 서브셋을 사용한다. : 웹 페이지에서 사용되지 않는 글자를 제거하고 폰트 파일 크기를 최소화할 수 있다.

3. 폰트 포맷을 WOFF나 WOFF2로 사용한다.

​

이 외에도 여러 방법들이 있겠지만, 대표적인 방법만 나열했다.

내가 부트캠프를 찾았던 이유는, 혼자하면 나태해질 것을 알았기 때문이다. 그런 의미로 관리형으로 운영되는 곳이 필요했고, 사람 일이란 게 어떤 일이 생길지 모르기 때문에, 그리고 각자의 생활 패턴이 다르기 때문에, 오프라인보다는 온라인으로 운영되는 곳을 찾다보니 제로베이스가 되었다. ​ 우선, 느낀점은, 생각보다 관리를 막 엄청나게 하지는 않는다. 근데 내가 모르는 것일지도 모른다. 항상 화면 인증 미션이나 투두리스트 등이 있고, 그걸 매니저님이 체크하고 있는데 말은 안 하실지두,, ​ 근데 개인적으로는 이 정도면 만족한다. ​ 투두리스트에 날짜도 적혀있고 그 안에서 자유롭게 조율해가며 하는 거라, 실제로 며칠씩 밀리기도 한다. 근데 그건 개인의 의지 문제고, 그 정도도 스스로 안 챙기면.. 애초에 취준을 할 의지가.. 없는 거라고 생각한다. 제로베이스 측에서는 매일매일의 목표치를 짜주는 걸..? ​ 밀릴만 하면 미션도 넣어놔서 웬만하면 크게 밀릴 일도 없다. ​ 자세히 알아보진 않았지만 피치 못할 사정이 있으면 기수 이월도 할 수 있다고 알고 있다. ​ 내 기수는 12월부터 시작한 기수라 그런지.. 다들 열심히 한다. 그도 그럴것이 12월이면 연말이고, 휴일이 많은데 1월 1일이라는 선택지가 있음에도 불구하고 그 때 부트캠프를 시작하겠다고 마음먹은 거니까.. 다들 취준/이직이 간절하신 분들인 것 같다. 나 또한 그렇고.. ​ 그리고 은근 양이 많아서 다른 일이랑 병행은 쉽지 않다. 또 온라인의 특성상 게을러지기도 하고, 어느 날은 공부를 저녁 시간이 지나고서야 시작해서 밤을 샐 때도 많다.(이건 내 문제긴 하다) 그래서 일단.. 카페든 스카든 나가서 하는 걸 추천한다.

첫날 작성한 학습 계획표대로 공부하고 있는가?

우선 난 J형 인간이지만, 내 계획이 틀어지는 것에 스트레스를 받는 편이라.. 무리한 학습 계획은 세우지 않았다. ​ 그냥 투두리스트 따라가기, 밀리지 않기, 밀린다면 주말을 사용해 다 메꾸기 ​ 위 세가지가 내 학습 계획이었고, 지금까지는 그래도 잘 지키고 있다고 생각한다. 하루이틀 밀리는 날도 있지만, 어쨋든 한 주가 지나기 전에 다 채워둔다.

이제 1개월이 지났다. 나머지 5개월 간의 학습 계획은:

이제 이론 수업은 조금 줄고, 실습 위주로 진행된다. 그래서 그런지 전보다는 시간이 덜 걸리는 것 같고, 그걸 내가 알아서 게을러질 것 같다. ​ 그래서 이제 슬슬 복습이라는 것도 시작해야겠다.

사실 이 블로그에 올리지 않는 모든 내용들은 따로 개인 노션에 정리하고 있다. 이제 강의 필기가 아닌 내가 잘 이해하지 못하는 부분에 대해 더 공부하고 정리하는 시간이 필요할 듯,, ​ 특히 CS 파트는 몇 번은 더 봐야 완전히 내 걸로 만들 수 있을 것 같다. ​ 그래서 목표는 최대한 당일, +1일 내애 투두리스트를 끝내고 남는 하루동안 개인공부하기. 하루에 몰아서 하기 힘들다면 할일을 끝낸 뒤 시간이 남으면.. 조금씩이라도 개인공부하기. ​ 아, 그리고, 밤새지 않기. 지난 한달간 생각보다 양이 많고 하나하나 다 적으려 하다보니 3시간 걸리는 강의도 89 시간 이상 소요됐고, 밤을 많이 샜다가 한번 크게 아팠다. 며칠간 컨디션이 돌아오지 않아서,, 다시는 밤을 새진 않기로 다짐.. ​ 할 게 많아도 일단 11시쯤 자러간다 무조건, 그 때 자고 새벽 23시에 기상해서 하는 게 훨씬 낫다,,

힘내렴 나자신..

Semantic: 의미의, 의미론적인

즉, 시멘틱 태그란, 특별한 의미를 가지고 있는 태그를 말한다.

그렇다면 이 시멘틱 태그를 사용하는 이유는 무엇일까?

​

시멘틱 태그를 사용하면 나타나는 이점, 즉 시멘틱 태그를 사용하는 이유는 여러가지가 있는데, 그는 다음과 같다:

1. 검색 엔진은 의미론적 마크업을 분석해 페이지의 검색 랭킹에 영향을 줄 수 있는 중요한 키워드로 간주하므로 시멘틱태그를 사용해 검색 엔진을 최적화할 수 있다.

2. 스크린리더로 페이지를 탐색할 시 이 시멘틱 태그를 푯말로 사용할 수 있다. 즉, 웹 접근성은 향상시킨다.

3. 시멘틱 태그의 가장 큰 목적이자 이점으로, 코드를 보는 개발자에게 명확하게 해당 요소의 의미나 목적을 전달하는 역할을 한다.

이를 통해 개발자에게 태그 안에 채워질 데이터의 유형을 제안하는 등, 협업 시 유용하게 사용된다.

웹 표준(Web Standards)

HTML5는 2014년에 W3C에서 공식으로 표준화 되었고,

2019년에 WHATWG에 의해 HTML Living Standard가 표준화 되었다.

HTML이 표준화 되기 이전에는 익스플로러의 엑티브X처럼 독자적인 플러그인이 존재하기도 했다. 이 때는 이를 위해 엑티브X를 위한 프로그램을 따로 만들어야 하는 등의 수고가 필요했다.

웹 표준을 준수해서 코드를 작성하면, 운영체제와 브라우저마다 의도된 대로 보여지는 웹페이지를 만들 수 있기 때문에 웹 표준을 지켜야 한다.

그래도 몇년간 일했던 경험도 있고.. 꿈꿔온 부분도 있다. 앞으로 어떻게 바뀔지는 모르겠으나 확실히 느낀 건, 내가 기여할 수 있는 부분, 내 몫이 확실히 있는 회사.

사람은 뭐랄까, 특히 나는 성취감으로 움직이는 것 같다. 그런 면에서, 지난 몇년간 일을 했던 것중에, 백엔드 개발자 한 명과 둘이서 일한 적이 있다.

그는 나에게 네가 지금 할 수 있는 건 없으니 그냥 내가 코드 쓰는 걸 지켜보고 있어라. 나는 누가 지켜봐야 효율이 오른다며 나를 옆에 앉혀두고 하루종일 코딩을 한 적이 있다.

며칠동안 백엔드가 다 구현될 때까지 의미도 알지 못하는 코드를 바라만 보다보니 나는 계속 시간을 땅에 버리는 느낌이었다. 차라리 그 시간에 document라도 읽어보고, 이용할 라이브러리라도 한번 쓱 보고 싶었는데 가만히 앉아있으니 무력함을 많이 느꼈던 것 같다.

​

코딩을 처음 시작할 때도 이런 무력감을 많이 느꼈다. 저번 포스팅에도 작성했듯이 나에게 개발을 처음 알려준 사람은 늘,

너가 코딩을 다 아는 건 불가능하니, 개념을 이해할 생각 말고 일단 코딩을 해라

라는 말을 했다.

아무것도 모르면서 냅다 다른 사람의 예시를 보며 하나씩 작성하는 것은 많이 힘들었다. 그 무력감을 최대한 느끼고 싶지 않다. 무력감이 아닌 성취감을 느끼고 싶다.

따라서 내 몫이 분명히 정해진 회사를 가고싶다.

​

​

회사를 선택하는 기준

첫째, 나는 명예욕이 있는 사람이다.

내 명예욕을 채워줄 수 있는 회사, 즉, 이름들으면 알 법한 대기업에 가고싶다. 검증된 유능한 사람이 되어, 유능한 사람들 사이에서도 유능하고 싶다.

​

둘째, life's work를 하고 싶다.

이 표현도 어느 미국 회사와 일을 하며 배운 표현이다. life's work란 "something I can remember my career by when I retire", 즉, 내가 은퇴를 하고 나서도 이것을 통해 내 업적을 기억할 수 있는 것이다.

나는 사회를 바꿀만한, 많은 사람들이 사용할 무언가를 만들 수 있는 기회가 있는 회사에서 일하고 싶다. 또한 이런 대규모 프로젝트를 수행하는 다른 개발자들 사이에서 일하며, 그들에게서 많이 배워가고 싶다.

확실히 경험을 해본다는 것만큼 많은 걸 배울 수 있는 일은 없다.

​

셋째, 이것도 성취감에서 비롯된다.

나를 필요로 하는 회사에서 일하고 싶다. 나를 필요로 하는 회사라면, 나도 책임감을 더 갖고 임할 수 있을 것이다.

​

마지막으로, 내가 되고 싶은 모습을 실현할 수 있는 회사이다.

나는 팀 내에서 잘 활동하며 의사소통이 뛰어난 사람이 되고 싶다.

또한 여러가지 방법으로 리더십을 보여줄 수 있는 사람이고 싶다. 개인적으로는 프레젠테이션, 이메일 작성, 문서 작성 등, 주도적으로 온라인(document, 코드 리뷰)과 오프라인(다른 사람들)의 리소스를 모두 찾아 일을 처리하는 사람이고 싶다.

그리고 이러한 모습을 실현하기 위해선 모두가 열정적으로 일하는, 다양한 의사소통이 이루어지는 회사여야 한다.

​

웹페이지를 구성하고 있는 요소(element) 하나하나를 ‘태그’라는 표기법을 사용해 작성. 태그를 통해 어떤 요소인지(제목, 본문, 이미지, 비디오 등) 명시하며, 태그의 이름은 HTML5 웹 표준에 맞게 작성한다.

요소(element): 여는 태그, 닫는 태그, 내용을 통틀어 이르는 말

Opening Tag(여는 태그): <요소의 이름>

Closing Tag(닫는 태그): </요소의 이름>

Content(내용): 요소의 내용

→ex) <p>Content</p>

태그의 경우 대소문자를 구분하지는 않으나, HTML5에서는 *모두 소문자로 작성하는 것을 권장**한다.

빈 요소(empty elements)

빈 요소(empty elements): 내용이 없는 요소. ex) 이미지 <img>, 수평선 <hr>, 줄바꿈 <br> 등

이 경우는 닫는 태그를 추가로 명시할 필요가 없다.

Empty element, Self-Closing element<img />, Void element, Single tag 등등이라고도 불림.

<p></p> 처럼 태그 사이에 내용이 없는 건 빈 요소가 아님.

HTML5에서는 <img>, <img /> 둘 중 뭘 써도 됨. 선택적임.

XHTML(HTML5 전)에서는 더 엄격하게 해야해서 빈 요소는 self-closing tag를 쓰도록 했었음.

HTML5에서는 뭘 써도 상관 없으나 일관성 있게 아예 empty로 쓰거나, self-closing tag로 쓰거나 하기. 나는 self-closing tag 써야지~

요소의 중첩(Nesting)

요소 안에 다른 요소가 들어가는 포함관계를 성립할 수 있다.(태그 안에 또 다른 태그도 넣을 수 있다)

서로의 포함관계를 분명히 구분하기 위해 들여쓰기 사용. 열린 순서 반대로 닫혀야 함.

<1>

    <2>

        <3></3>

    </2>

</1>

<h1>요소 안에 <strong>다른 요소가</strong> 들어갈 수 있다.</h1>

주석(Comments)

브라우저는 주석을 무시하여 사용자에게 주석이 보이지 않도록 함.

주석의 목적은 코드에 메모를 추가하거나, 사용하지 않는 코드를 임시로 처리하기 위함임.

<!— <p> Content </p> —>

HTML 문서의 구조

<!DOCTYPE html>     // 문서의 타입이 html이다. 버전 명시하는 역할. 사실상 HTML5기에 생략 가능하나 관습화됨.

<html>     // 태그의 실제 시작부분. 페이지 전체의 컨텐츠를 감싸는 루트(root) 요소(최상위 요소)

<head>     // 웹 브라우저 화면에 직접적으로 나타나진 않는 웹 페이지의 정보

<!— HEAD 입력 —>

- meta tag: 문서의 일반적인 정보와 문자 인코딩을 명시
- title

</head>

<body>     // 웹 브라우저 화면에 나타나는 모든 콘텐츠

<!— BODY 입력 —>

</body>

</html>

HEAD 태그

head mdn 구글 서치

: The Document Metadata (Header) element - HTML: HyperText Markup Language | MDN

HTML <head> 요소는 기계가 식별할 수 있는 문서 정보(메타 데이터)를 담음. 정보로는 문서가 사용할 제목<title> 필수！, 스크립트, 스타일 시트(css) 등이 있음.

사용자에게 보여주고 싶으면 <body> 내에서 <header>을 사용할 것.

BODY 태그

*body mdn 구글 서치 * : The Document Body element - HTML: HyperText Markup Language | MDN

속성(Attribute) 부분 확인. 옆에 trash 아이콘이 있으면 사용하지 않는 것을 권장

head 태그와 마찬가지로 모든 브라우저에서 지원함.

태그를 구분짓는 특성

body 영역에 들어가는 태그들만 아래 기준으로 나눌 수 있다.

1. 구획을 나누는 태그

   • 레이아웃을 위해 섹션별로 분리하거나 아이템을 담는 용도. 컨테이너 역할

   • 단독으로 사용했을 때에는 눈에 보이지 않음.

   • 여러가지 요소들을 묶어서 그룹화.

2. 그 자체로 요소인 태그

   • 단독으로 사용했을 시에도 눈으로 확인할 수 있음.
   • <button>, <text> 등등
     
     
     
     

     블록과 인라인

3. 블록(Block)

   • 블록 레벨 요소는 언제나 새로운 줄에서 시작하고, 좌우 양쪽으로 최대한 늘어나 가능한 모든 너비를 차지함.(부모가 허용한 가로의 최대를 차지). 가로길이를 지정하지 않았을 때 기본 성질임. CSS 없다고 가정

   • 상자를 아래로 쌓는 것

   • w-full flex flex-col 느낌？ 위에서 아래로.

4. 인라인(Inline)

   • 인라인 요소는 줄의 어느 곳에서나 시작할 수 있다.
   • 바로 이전 요소가 끝나는 지점부터 시작하여, 요소의 내용만큼만 차지한다.

*포함 규칙

• 같은 형태의 다른 요소를 안에 포함할 수 있음. ex) 블록 > 블록, 인라인 > 인라인

• 대부분의 블록 요소는 다른 인라인 요소도 안에 포함할 수 있음
• 인라인 요소는 블록 요소를 포함할 수 없음.
  
  
  
  

  콘텐츠 카테고리

HTML5 부터 비슷한 특징을 가진 요소끼리 묶어 7가지 카테고리로 세분화

하나의 HTML 요소가 여러 콘텐츠 카테고리 내의 포함관계에 들어갈 수도 있음.

3.2.5 Content models — HTML5

⬆️

위 링크의 다이어그램을 통해 어느 부분이 겹치고, 교집합이 있는지 알 수 있음.

Flow Content- Metadata 일부를 제외하고 다 포함하고 있음.

*HyperText Markup Language * ​

HyperText: 하이퍼링크로 한 문서에서 다른 문서로 접근할 수 있는 특수한 형태의 문서.

Markup: 마크, 즉 표시를 하다

Language: (컴퓨터)언어

-> 하이퍼텍스트를 표시해주는 마크업 언어

​

​

​

HTML, CSS, JavaScript

[구조] HTML: 웹 문서의 기본적인 골격을 담당

[표현] CSS: 각 요소들의 레이아웃, 스타일링을 담당

[동작] JavaScript: 동적인 요소(사용자와의 인터렉션)을 담당

​

HTML과 CSS가 구분돼있기 때문에 하나의 HTML만으로도 두개의 레이아웃을 만들 수 있음.

​

​

​

웹 표준과 웹 접근성, 호환성

똑같은 html 문서를 다른 브라우저에서 연다면?

→ 약간씩 디자인은 다르지만, ‘버튼’에 대해 버튼의 기능을 함

만약 표준을 지키지 않는다면? 해당 브라우저를 위해 개발자가 따로 코드를 작성해야 하는 일이 발생함

​

웹 표준(Web Standards)

HTML5는 W3C에서 2014년에 공식 표준화.

2019년에 WHATWG에 의해 HTML Living Standard가 표준화 됨.

HTML이 표준화 되기 이전에는 익스플로러의 엑티브X처럼 독자적인 플러그인이 존재하기도 하였음.(이를 위해 엑티브X를 위한 프로그램을 따로 만들었음)

웹 표준을 준수하여 작성한다면 운영체제, 브라우저마다 의도된 대로 보여지는 웹 페이지를 만들 수 있음.

​

웹 접근성(Web Accessibility)​

장애를 가진 사람과 장애를 가지지 않은 사람 모두가 웹사이트를 이용할 수 있게 하는 방식으로 모든 사용자들이 정보와 기능에 동등하게 접근할 수 있도록 함.

개발 시 접근성을 높이는 것이 중요.

웹 브라우징에 쓰이는 보조과학기술: 스크린리더, 화면 돋보기, 음성 인식 등

​

웹 호환성(Cross Browsing)

웹 브라우저 버전, 종류와 관계없는 웹사이트 접근

웹 표준 준수를 통한 브라우저 호환성 확보

• HTML, CSS 문법 준수

• 동작, 레이아웃, 플러그인 호환성

​

+) 크로스 브라우징이란 웹 호환성을 나타냅니다. 웹 페이지 제작 시 모든 브라우저에서 깨지지 않고 의도한 대로 올바르게 나오게 하는 작업입니다.

웹 표준을 준수함으로써 브라우저의 호환성을 확보할 수 있습니다.

크로스 브라우징이 필요한 이유는 브라우저마다 렌더링하는 엔진이 다르기 때문입니다.

브라우저 별로 때때로 해석하지 못하는 CSS코드나 작동하지 않는 javascript 등이 존재할 수 있습니다.

git clone [원격 저장소 주소]

git status: 저장소의 상태를 보여줌

git add [파일 경로]

git add -i : 추가되지 않은 파일들 모두 한번에 staging area에 추가

git rm —cached [파일경로]: staging area에 add된 파일을 다시 working directory로 내린다.

git rm ‒r --cached : Staging Area의 모든 파일을 Working Directory로 내린다.

git commit -m “”

git push

git log --decorate --graph

VScode에서 사용하기

편집기 내에서 Git을 지원

로컬에서 작업하기 위해 remote repository를 복제해 내 PC에 local repository로 저장하는 것

소스트리를 이용해 Clone하기.

1. Github 원격 저장소에서 SSH 주소 복사
2. URL에서 복제 선택
3. 복사한 SSH 주소 입력, 복사할 폴더 설정, 이름 설정
4. Clone 완료!

Add, Commit, Push, Pull

Add

변경된 파일 중 Repository에 올릴 파일들을 등록한다.

working directory에서 staging area로 올림

Commit

Add로 등록된 파일들을 한 덩어리로 만들고 메시지 추가해 로컬 저장소에 올린다.

staging area에서 local repository에 반영됨.

Push

Commit되어 로컬 저장소에서 변경이 된 파일들을 원격 저장소로 전달한다.

local repository에서 remote repository로 전달됨.

push 완료 후 없던 origin(원격 저장소를 의미)이 생김

Pull

원격 저장소의 변경 사항을 로컬 저장소로 가져옴과 동시에 내 작업 소스에 합친다.

원격 저장소에서 내 로컬 저장소로 가져오는 것 = Fetch

그 로컬 저장소에서 내 작업 폴더로 가져오는 것 = Merge

Pull = Fetch + Merge

• Fetch: 원격 저장소의 소스를 로컬 저장소로 받아와 일치시킴.
  • 내 작업 소스에는 반영하지 않음
• Merge: Fetch해온 로컬 저장소의 소스를 내 작업 소스에 합친다.
  • 합칠 때 같은 부분의 소스가 다를 경우 충돌이 발생

Pull 하는 상황은 언제 발생할까?

• 원격 저장소는 여러 프로젝트의 개발 인원들이 동시에 사용.
• 다른 개발자가 변경 상태를 Push해 원격 저장소에 반영한다면 내 입장에서는 원격 저장소에 변경 상황이 발생한 것.
  
  
  
  

  Branch

나무가지를 의미. 기존에 만들어 놓은 버전(main)에서 복사해 새로운 가지를 만들어 다른 방향으로 작업을 이어 나가는 것을 말한다.

분업을 위해 사용.

Branch 생성

브랜치 이름 작성 후 생성. 새 브랜치 체크아웃 박스 클릭하기.

Merge

각각의 브랜치에서 작업이 완료된 후 통합 브랜치(main)로 모아 합치는 작업

• Merge할 커밋 시점을 선택해 Merge하는 것도 가능!
  
  
  
  

  Conflict 해결

Conflict 발생

• Branch를 merge할 때 발생할 수 있다.
• 같은 파일의 같은 부분을 수정한 브랜치들을 merge할 때 발생

merge 시 충돌이 일어나면?

메인 브랜치의 소스와 다른 브랜치의 소스 중 하나를 선택하도록 함.

** 다른 작업자가 작업한 브랜치를 머지할 땐 해당 작업자와 충분히 논의할 것.

Fork 복제

Fork

다른 사람의 원격 저장소에서 어떤 부분을 수정하거나 추가 기능을 넣고 싶을 때 해당 원격 저장소를 내 원격 저장소에 그대로 복제하는 것, 전문용어로 “포크뜬다”라고 한다.

사용법

• 다른 계정으로 깃허브 접속
• 원하는 레포지토리에 깃허브 페이지 접속 후 Fork 버튼 클릭
  
  
  
  

  Pull Request

다른 사람에게 내 브랜치를 merge 해달라고 하는 요청.

어떤 부분을 어떻게 수정했는가, 피드백을 요청하는 부분은 정확히 어떤 파일의 어느 부분인지 기입할 것.

사례: 한 원격 저장소에서 내 브랜치를 merge 하기 전 피드백을 요청

사례2: Fork 뜬 저장소에서 원본 저장소에 개발 완료 후 원본 저장소에 Merge를 요청

파일이나 폴더를 저장하는 곳. Git 저장소는 파일 변경 이력 별로 구분되어 저장됨.

Local Repository

내 PC에 파일이 저장되는 개인 저장 공간

생성하기

1. 원하는 폴더 생성
2. 해당 폴더에서 git init 명령어 입력
3. .git 폴더 생성 확인

** 원격 저장소(Remote Repository)에서 복사해 Local Repository를 생성할 수도 있음.

** .git 폴더 안에가 Local Repository고, 그 폴더에 있는 소스 부분이 working directory라고 생각하는 것이 쉬울 듯.

Remote Repository

파일이 전용 서버(Github)에서 관리되며 여러 사람이 함께 공유

Github를 통해 생성한다.

Working Directory

작업하는 파일이 있는 디렉토리 소스코드 작업을 하고 있는 폴더 자체

Staging Area

Git에 등록(커밋)할 파일들이 올라가는 영역 변경사항이 있는 파일, 폴더, 리소스 등

Local Repository

로컬 Git 프로젝트의 메타데이터와 데이터 정보가 저장되는 영역 Git의 저장소. 여기 있는 내역들은 Git에 등록되었다고 볼 수 있음. 컴퓨터 안에 저장된 내용.

Remote Repository

Github 등의 서비스를 통한 온라인 상의 저장소 온라인 상의 공간

*Working Directory, Staging Area, Local Repository는 PC에 존재. Remote Repository는 온라인상에 존재 *

기본 용어

• origin: 원격에 있는 코드. Remote Repository에 저장되어 있는 코드
• head: 내가 지금 작업하고 있는 로컬 branch
• add: Working Directory에서 Staging Area로 등록하는 것을 의미
• commit: Staging Area에 등록된 파일을 Local Repository로 등록
• Commit Message: commit 시 함께 저장하는 메시지(메모)
• push: Local Repository에서 변경된 파일들을 Remote Repository로 등록
• fetch: Remote Repository의 변경된 파일들을 Local Repository로 전달
• merge: Local Repository의 변경 사항을 Working Directory로 전달
• Branch: 독립적으로 어떤 작업을 따로 진행하기 위한 가지(브랜치)
• checkout: 사용할 다른 브랜치를 지정

Git 저장소 호스팅을 지원하는 웹 서비스 GitHub: Let’s build from here

내 깃허브 주소 ⬇️ aekyung11 - Overview

SourceTree 설치

Git을 더 쉽게 활용하기 위한 GUI 툴 https://www.sourcetreeapp.com/

사용자 설정 및 세팅

Git의 사용자 설정

로컬에서 사용할 Git 사용자 이메일과 이름을 설정

• git config: Git에 관한 설정을 추가/변경/삭제하는 명령어
• 설정파일 - System 설정 파일 / Global 설정 파일 / 로컬 설정 파일
  • System 설정 파일: 모든 시스템 사용자에게 적용. git config --system
  • Global 설정 파일: 한 사용자의 전체 Git Repository에 적용. git config --global
  • Local 설정 파일: 하나의 Repository에만 적용. git config --local

Global Git 사용자 설정

git config --global user.email “abc@abc.com” git config --global user.name “Hong Gil-dong”

설정 확인

git config --list

Github 계정에 ssh key 등록하기

1. ssh key 만들기 -> Git - SSH 공개키 만들기

2. Github 접속 후 오른쪽 상단 프로필 클릭 Setting -> SSH and GPg Keys

3. New SSH Key 클릭해 Title과 복사한 Key 입력 후 Add SSH Key 클릭

깃 초기화 및 삭제

Git 초기화

명령어: git init

초기화 할 대상 폴더에서 명령어 (git init) 입력

Git 초기화 시 폴더 안에 숨김 폴더로 .git 폴더 생성 (Local Config 등으로 구성)

Git 삭제

명령어: git init

단순히 .git 폴더를 삭제 mac의 경우 폴더를 삭제하는 명령어 입력 : rm ‒rf .git

gitignore이란

프로젝트에 원하지 않는 백업 파일이나 로그파일 혹은 컴파일 된 파일들을 Git에서 제외할 수 있는 설정 파일

사용자가 git에 등록(커밋)되지 않길 원하는 파일 또는 폴더들의 목록을 저장 .gitignore 에 등록된 파일(폴더) 들은 커밋 시 자동으로 제외됨

**VScode에서 해당 폴더에 .gitignore 파일을 생성한 후 아래 작성법의 양식을 이용해 gitignore을 적용할 폴더/파일 등을 입력함.

작성법

• #은 주석의 역할
• 폴더: /폴더명
• 파일: 파일명.확장자
• 폴더 안 파일: /폴더명/파일명.확장자
• 폴더 안 특정 확장자 파일 전부: 폴더명/*.확장자
• 폴더 하위 모든 특정 확장자 파일 전부: 폴더명/**/*.확장자

https://www.toptal.com/developers/gitignore

1. Git SCM 접속해 설치 파일 다운로드(공식 사이트에서 다운)

2. 설치파일 클릭해 설치

3. 시작프로그램에서 Git Bash 실행

4. Config 설정 (User Name / User Email 설정)

5. 설치 완료
   
   
   
   

   Git설치(Mac)

사전 준비가 필요함.

0. Homebrew(Mac에서 제공하지 않는 유용한 패키지를 설치할 수 있도록 도와주는 패키지 관리자) 설치 ⬇️

   https://brew.sh/

1. 터미널 실행
2. brew install git 입력
3. git --version 입력해 확인
4. Config 설정 (User Name / User Email 설정)
5. 설치 완료

버전 관리 시스템(VCS: Version Control System)으로 소프트웨어의 시간 및 버전을 관리하고 통제하는 시스템을 말함.

프로젝트의 변경 내역, 프로젝트 버전 등을 쉽게 관리해주는 프로그램

problem: 일정 단위의 작업을 취소하고 이전 버전으로 되돌려야 할 때

solution: 버전 관리 시스템으로 버전을 저장, 되돌리기, 각각 작업의 진행 등을 기록해 체계적 관리 가능

​

Git: 오늘날 가장 인기있는 버전 관리 시스템.

• 프로젝트를 버전별로 백업, 관리하여 프로젝트를 유지보수 하면서 발생할 수 있는 여러 문제들을 미연에 방지하고 해결하는 역할을 함.

Github: Git을 기반으로 소스코드를 온라인에 저장하고, 공유할 수 있게 하는 소스코드 관리 서비스

​

용어 정리

• 레포지터리(Repository, repo): 저장소. sw 파일이나 폴더 등 각종 정보 저장.

  깃허브를 통해 공개/비공개 레포 만들 수 있음

  
  

• 브랜치(branch): 독립적으로 어떤 작업을 진행하기 위한 ‘차원’

  하나의 폴더 안에서 여러 차원을 분기할 수 있음. 각각의 브랜치는 독립적, 여러 작업 동시 진행 가능

  따라서 새로운 기능을 추가하고자 할 때 새로운 브랜치에서 기능테스트 가능.

  
  

• 커밋(commit): 코드 수정사항을 기록하는 명령.

  커밋 생성하면 커밋한 시점의 작업 변경 이력을 저장할 수 있음. 내 컴퓨터에서 수정한 코드를 깃헙 레포로 올리기 전에 포장하는 작업

  
  

• PR(Pull Request): 수정한 코드가 있는 브랜치를 검토 후 병합해달라 요청하는 것

  원격 저장소에 모두 커밋한 뒤 팀원들에게 PR 보냄 → 다른 개발자들이 확인 후 문제없을 시 PR승인, main 브랜치에 병합

  → 코드 충돌 최소화 가능

  
  

• 코드 리뷰(code review): 다른 개발자의 코드 내용을 점검하고, 피드백을 주는 것

  • 피드백: 오타, 버그 가능성, 개발 표준 등에 대한 의견 or 좋은 코드에 대한 긍정적인 피드백

  • 장점: 버그의 조기 발견, 개발 표준 준수, 코드 중복 방지, 모듈 재사용성 증대, 좋은 코드에 대한 논의 등을 할 수 있음

    이를 통해 개발자 개인에게만 책임을 묻는 것이 아닌, 모두에게 책임이 있다는 문화 만듦.

    
    

• 오픈소스(open source software): 공개적으로 접근할 수 있게 설계되어 누구나 자유롭게 확인, 수정, 배포 가능한 코드.

  깃헙에 오픈소스 플젝 업로드 하여 다른 개발자들과 공유가능함.

  동료 평가와 커뮤니티 기반 프로덕션에 의지하며 협업 방식으로 개발, 유지보수가 됨.

형상관리도구, 즉 버전관리 시스템 중 하나. 프로젝트의 소스코드를 효과적으로 관리할 수 있는 시스템.

⬇️ 효과적인 관리란?

Git의 특징임.

여러 명이 동시에 작업하더라도 문제 없도록 함

소프트웨어의 여러 버전을 동시에 관리할 수 있다

프로젝트 진행의 모든 로그를 볼 수 있고, 해당 시점으로 되돌리는 것도 가능.

git-scm.com

** 사용법을 정확히 알고 싶거나 추가적으로 알고 싶은 부분이 있을 때, Documentation → Reference Manual에서 찾아보면 됨. ​

​

​

Git을 사용하는 이유

코드 관리 측면

• 변경된 이력 확인
• 이전 이력으로 되돌리기
• 다른 기능의 버전 코드 유지
• 현재 최종이 어느 시점인지 표현할 수 있음.(로그)

협업의 측면

• 분업 가능. 각자 하고 추후 합칠 수 있음.
• 같은 부분을 수정해 문제가 생길 때 안내해줌
• 협업으로 인한 실수를 예방
• 팀원 간 커뮤니케이션을 지원 ​

​

​

Git 기반의 서비스

프로젝트 소스코드 클라우드 호스팅, 특색에 맞는 기능을 제공

• Github
  • 가장 많이 씀
• Bitbucket
  • 협업을 위한 소프트웨어(Jira)와 연계가 잘 됨
• GitLab
  • 설치형 Git
  • 용량에 대한 비용을 절감
  • 소스코드의 보안이 좋음

‘프론트엔드’는 말 그대로 풀어보면 ‘프론트’는 앞이고 ‘엔드’는 끝, 즉 단면이라는 뜻을 가지고 있어요. 결국 ‘앞면’이라는 뜻이죠. 사업에서 ‘앞’이란 소비자들과 직접 만나는 활동을 의미해요.결국 ‘프론트엔드’는 사용자가 서비스를 이용하기 위해 웹페이지나 앱 내에서 만나고 경험하는 모든 부분을 말합니다. -제로베이스

위 내용이 제로베이스 홈페이지(https://zero-base.co.kr/event/media_insight_contents_FE_frontend_job)에 쓰여있는 내용이다. ​

backend is data transformation, and the frontend is dealing with UI state. ​

그리고 위의 내용이, 현직 개발자에게 물었을 때 돌아온 대답이었다.

​ 나에게 프론트엔드 개발이란, 사용자 인터페이스, 즉 UI와 사용자 경험, 즉 UX를 구현하는 것에 중점을 두는 분야로, 다양한 웹 브라우저/앱에서 사용자에게 보이는 화면 전체를 개발하는 것이 주 목표이다. ​ ​ ​

프론트엔드 개발과 백엔드 개발의 차이점은?

이 또한, 위에서 언급한 현직 개발자의 의견에서 볼 수 있다. 프론트엔드와 백엔드의 가장 큰 차이점은, 사용자가 볼 수 있는 영역과 볼 수 없는 영역의 차이이다. ​

프론트엔드 개발은 앞서 말했듯, 사용자에게 보이는 화면 전체를 개발하는 것이다. 그에 반해 백엔드 개발은 프론트엔드와는 반대로, 사용자에게 직접적으로 드러나지 않는 영역, 즉 서버의 영역이다.

데이터 처리, 비즈니스 로직, 서버 관리, 보안, 데이터베이스 관리 등과 같은 서버 측의 작업을 백엔드 개발의 영역이라 볼 수 있다.

나는 일반적인 미대생이었고, 매년 2학기 학기 말마다 해야했던 전시회를 준비하며 어쩌면 이 전공이 내 길이 아닐지도 모른다는 생각이 들었다.

​

예고를 나와서 너무 당연하고 자연스럽게 미대 진학을 목표로 하게 되었고, 그렇게 미대에 오니 작업이 재미있긴 한데, 이걸 직업으로 했을 때 내가 과연 잘 해낼 수 있을까? 하는 의문이 들었다. 그렇게 나는 2학년을 마치고 휴학을 했다.

​

사실 휴학을 하고 일반적인 취업준비에 필요한 자격증을 하나씩 모을 생각이었다. 워드, 컴활, 포토샵 등등...

근데 알고 지내던 개발자가 자신이 사이드 프로젝트를 하고 싶은데, 주변에 디자인을 할 줄 아는, 미적감각이 있는 사람이 나밖에 없다며 혹시 같이 일을 하며 디자인을 맡아주지 않겠냐는 제안을 했다. 다달이 월급도 주겠다며.

그렇게 그의 사이드 프로젝트를 도와주기 시작했고, 내 디자인을 그대로 화면에 옮기고 싶은 욕심이 생겨 CSS를 배우게 되었다.

사실 전문적으로, 순차적으로 배우진 않았다.

나는 성격상 완벽주의가 심해 모든 개념을 알고 나서 실전에 투입되길 원했고, 내가 그렇게 말할 때마다 그는 이렇게 말했다.

​

"코딩은 너가 평생을 바쳐도 절대 모든 걸 알고 넘어갈 수 없어. 일단 해보고 막히면 그때 그때 구글링하며 배우는 거야"

​

사실 맞는 말이라고 생각은 하지만, 그의 이런 교육 방법이 나에게 100% 맞지는 않았다. 그래서 휴학한 1년동안 그와 같이 사이드 프로젝트 말고도 해외에서 외주를 받아 작업하는 등 일을 하다가, 내가 아무것도 모른다는 생각이 들었고 그렇게 컴퓨터공학과를 복수전공하기로 마음먹게 되었다.

아, 1년동안 일해본 결과, 미술보다 FE가 나에게 잘 맞는다는 것을 알게 돼서 그 쪽으로 일해보고 싶다는 생각이 들었다. 자세한 내용은 후술하겠다.

​ ​

프론트엔드 개발자가 되기로 결심한 이유.

우선 내가 미술이라는 전공이 맞지 않았던 가장 큰 이유는, 노력한 만큼 결과가 나오지 않는다는 것이다.

​

나는 대학교에서 미술 중에서도, 도예유리를 전공했다.

고등학교 시절 디자인과였던 나는 똑같이 그리는 것은 자신이 있었다. 실제로 성적도 잘 나왔고, 묘사를 하고, 1mm의 차이도 바로 알아볼 정도로 관찰력이 뛰어났다. 그런데 디자인과는 그것만으로는 충분하지 않았고, 매번 새로운 것을 만들어야 했다.

항상 내 기준에서 말도 안 되는 주제가 시험 문제로 나왔고 나는 내가 왜 '오렌지'라는 키워드 하나로 제품을 디자인 해야하는지 이해가 가지 않았다.

나는 그런 문제가 재미 없었고, 실용성도 없는 걸 매번 디자인하라는 과제가 버거웠다. 그 때 나는 디자인에는 소질이 없다는 걸 알게 되었다.

그래서 대학은 최대한 그런 문제를 없애고자, 공예 쪽으로 가야겠다는 생각을 했다.

​

대학을 오니 우선, 똑같이 형태를 만드는 것, 실용성 있는 걸 만드는 것, 이 두가지가 고등학교 때보다는 마음에 들었다.

그런데 문제가 다른 데에 있었다. 도자기와 유리가 너무 예민하다는 것이었다. 내가 아무리 잘 만들어도 가마에서 잘못될 수도 있고, 아무리 신경써도 갈라지는 부분이 생기고, 날이 추우면 춥다고 깨지고 건조하면 건조하다고 갈라지고...

내가 손쓸 수 없는 경우의 수가 너무 많았다.

​

그런데 프론트엔드 일을 하니, 내 관찰력도, 완벽주의 성향도 하나의 장점으로 작용했으며, 주어진 디자인 그대로 픽셀단위까지 맞출 수 있다는 점도, 때때로는 내 미감을 사용해 조금 더 융통성 있게 작업할 수 있다는 점도 매력으로 다가왔다. 그리고 우선 변화를 바로바로 눈으로 확인할 수 있다는 점 또한 좋았다.

내가 10시간을 작업하면 딱 그만큼 결과가 나오고, 노력한 그대로 결과가 되었고, 모든 작업 하나하나가 의미 있었다.

한번 몰두하면 시간이 지난 줄도 모르고 하루종일 할 때도 있고, FE 파트를 할 때마다 바로바로 보상처럼 내가 만든 화면과 내 로그 등이 남으니 성취감 또한 있었다.

​

결정적으로는 복수전공한 컴퓨터공학과의 졸업 프로젝트로 만들었던 반려견 건강관리 서비스의 제작과정이 정말 힘들면서도, 재미있었다.

그걸 발표할 때, 옆에 있던 다른 컴공 전공생들로부터 완성도가 높다, 확실히 미대 분들이 만든 건 퀄리티가 다르다는 등의 칭찬을 들었을 때는, 나도 할 수 있구나하는 뿌듯함을 느꼈고, 더 잘해내고 싶다는 욕심도 들었다.

​

말이 길었는데, 결론적으로는:

내가 긴 시간동안 해온 미술,

그리고 세상을 선도하는 컴퓨터 기술.

이 두가지가 조합된 것이 FE개발자라는 생각이 들어 FE개발자가 되기로 결심했다.

​ ​

제로베이스 프론트엔드 스쿨에 참여하는 다짐.

학교를 다니는 내내 일을 병행했기 때문에 다른 학생들처럼 학업에만 몰두할 수 없었고, 컴퓨터공학을 복수전공 하면서도 수강하지 못했거나, 제대로 수업을 듣지 못한 컴퓨터공학 과목이 많았다. 그래서 한 편으로는 늘 열등감을 갖고있다.

나는 저 전공생들보다 수준이 낮을 거야, 나는 전공생들보다 실무경험은 많지만, 그조차도 제대로 이해하며 하고 있는 건지 확신도 없는데.

나는 저 전공생들에게 알고리즘이나 코테에서 밀릴거야, 나는 전공생들보다 부족할거야 등등

​

일을 할 때도 같이 일하는 개발자는,

"하면서 배워, 이론은 쓸데없어, 실무하면서 익혀야 해"

라는 마인드였고, 이 부분이 사실 가장 힘들었다.

그의 의견은 어찌됐든 난 항상 스스로 기초작업이 필요하다 느껴서, 모든 졸업 전시가 끝나고 시간이 있을 때 바로 처음부터 배워보자는 마음으로 제로베이스 프론트엔드 스쿨에 참여하게 됐다. 커리큘럼도 괜찮아보였고, 강사진도 좋았고, 또한 취업 보장에, 초봉이 일정금액 이상 넘지 않으면 100% 환불해준다기에 나로써는 손해볼 게 없었다.

​

제로베이스에서의 목표는, 대체 불가능한 인재가 되는 발판을 마련하는 것이었고, 계속 그럴 것이다.

의미도 모르고 사용했던 여러 태그, 요소, 속성 등을 의미부터 알고 사용할 수 있는 것, 다양한 컴퓨터공학 지식을 쌓는 것, 누군가 나에게 관련 질문을 했을 때 막힘없이 대답할 수 있는 사람이 되는 것, 개인이 아닌 팀과 협업하는 방법을 배우는 것, 기업에서 필요로 하는 사람이 되는 것, 나아가 자신감을 얻는 것이 목표이다.

​

하고싶은 것도 줄이고, 열심히 해야지. 게을러지지 말아야겠다.

​ ​

반년간의 학습 계획.

제로베이스 FE 스쿨에 참여하고 공지사항을 읽어보는데, 제로베이스 측에서 올려준 스프레드시트가 있었다.

들어가보니 매일매일의 투두 리스트를 작성해서 공부에 막힘이 없도록 해뒀길래, 그 코스를 안 놓치고 따라가면 큰 문제는 없을 것으로 보인다.

별도로 수업자료에 더해 추가로 필기하고 싶은 내용을 적는 과정을 추가하면 보다 더 효율적일 것 같다.

다만 수업을 들으며 하나하나 노션에 필기를 하고 있어서, 남들 두시간만에 끝내는 강의도 나는 네시간, 다섯시간씩 소요된다.

그만큼 꼼꼼히 하고 있으니 도움이 되지 않을까 싶다.

​

커리큘럼을 보니 중간중간 프로젝트, 과제, 퀴즈 등이 있던데 이것들을 모두 올 패스한다는 생각과 각오로 임해야겠다.

지금도 하루 8시간 정도는 꼬박 학습에 소요하고 있으니, 지치지 않고 이 페이스만 유지할 수 있으면 될 것으로 보인다.

그냥 반년은 꼬박 죽었다 생각할란다.

​

주기적인 복습도 필요할 것 같은데, 이는 데일리 미팅을 통해 공부한 내용에서 서로서로 질문에 답을하는 시간을 이용할 생각이다.

우리 팀은 아침일찍 온라인으로 만나기로 했으며(생활습관을 바로잡기 위해 이 시간대로 신청했다),

제로베이스에서 뽑아준 질문이 아닌, 우리가 스스로 전날 강의 내용에서 문제를 다섯개씩 만들어 서로에게 돌아가며 질문하는 방식으로 하기로 했는데, 질문을 만들기 위해선 어떤 내용을 배웠는지 다시 봐야하니 자연스럽게 복습할 수 있다.

​

​

나 자신, 화이팅.​