웹앱의 배포 과정은 크게 작업물 커밋, 빌드, 테스트, 배포의 과정으로 나뉘어져 있습니다. 우리는 이런 의문을 가질 수 있습니다.

"이렇게 짜여진 과정들을 단 한번에 해결할 수 없을까?"

이러한 의문에서 출발하여 CI/CD라는 개발 전략이 등장하였습니다. 이를 활용하면 자잘한 과정으로 나뉘어진 배포 작업을 단 한번의 커밋으로 해결할 수 있다는 이점이 있습니다. CI/CD 전략을 사용하면 커밋을 할 때 마다 따라오는 빌드, 테스트 배포 같은 반복적인 작업이 생략되기에 어플리케이션의 배포 속도가 훨씬 빨라집니다.

이제 우리는 CI/CD라는 개념이 어디서 왜 출발했는지는 알게 되었습니다. 그럼 CI/CD가 정확히 무엇인지 조금 더 알아보도록 할까요?

1. CI란?

CI는 Continuous Integration(지속적 통합)의 약자이며 소프트웨어 개발 속도를 촉진시키는 개발 전략 중 하나입니다. 개발자들이 작은 단위로 작업물을 커밋하면, 공유 레포지토리에 머지 되기 전 *빌드와 테스트가 자동화 되어 실행됩니다. *

한 줄로 요약하자면, 아무리 작은 단위의 커밋일지라도, 커밋을 하게 되면 새로운 빌드와 테스트가 트리거 됩니다.

CI를 적용하는 이유는 하나의 어플리케이션을 개발 할 때 다수의 개발자들이 공유 레포지토리에 커밋을 했을 경우 일어나는 충돌을 즉시 해결하기 위함입니다. 만약 자잘한 충돌이 즉시 해결되지 않는다면 충돌이 중첩되어 더 큰 충돌을 야기하고, 그로 인해 충돌을 해결하는 시간이 기하급수적으로 늘어나게 됩니다.

CI는 다수의 개발자가 공동작업을 하는 과정에서 생기는 충돌을 즉시 해결하는 데에 목표를 두고 있기 때문에 배포의 자동화 과정은 포함하지 않습니다. 배포 과정이 포함된 자동화 프로세스는 CD를 설명할 때 다루겠습니다.

2. CD란?

CD는 Continuous Delivery(지속적인 서비스 제공)와 Continuous Deployment(지속적인 배포) 두 가지를 의미합니다. 두 가지 개념은 서로 관련성이 있지만 동의어는 아닙니다. 같은 CD이지만 서로 다른 것을 의미하므로 좀 더 자세히 알아보겠습니다.

2.1 CD as Continuous Delivery

Continuous Delivery(지속적인 서비스 제공)은 개발중인 어플리케이션이 항상 배포 준비가 되었음을 의미합니다. 배포 따라서 Continuous Delivery는 앱 배포가 준비된 "상태" 입니다. 따라서 이 용어는 앱의 실질적 배포 과정은 포함 되어 있지 않으며, 실제 배포를 위해서는 추가적인 과정이 필요한 "상태" 입니다. 그리고 개발자는 Continuous Delivery를 추구함으로써 어플리케이션을 항상 배포 가능한 상태로 유지 시킬수 있음을 목표합니다.

2.2 CD as Continuous Deployment

Continuous Deployment(지속적인 배포)는 빌드, 테스트, 배포의 자동화를 의미합니다. Continuous Deployment는 CI 처럼 "개발 전략" 중 하나입니다. 만약 CI를 적용시킨 상태에서 새로운 커밋을 하고, 빌드되고, 모든 테스트를 통과한다면 배포까지 자동화되어 이루어 지는게 Continuous Deployment의 핵심 개념입니다. Continuous Delivery와 Continuous Deployment의 차이에 대해 더 정확하게 이해를 하기 위해 아래 이미지를 볼까요?

해당 이미지에서 CI에 Continuous Delivery만 적용되었을 경우, 제품을 deploy 하기 위해 메뉴얼적인 스텝을 밟아야 합니다. 왜냐하면 Continuous Delivery는 배포 전 배포 가능한 "상태"를 의미하기 때문입니다. 그러나 CI에 Continuous Deployment가 적용 되었을 경우는 제품의 배포가 자동적으로 이루어 집니다. 왜냐하면 *Continuous Deployment는 커밋 이후 배포까지의 "자동화"를 의미하기 떄문입니다. *

3. CI/CD는 다르지만 서로 겹쳐있는 개념이다

Continuous Integration이 잘 구축되어 있다면 Continuous Delivery의 목적을 잘 달성할 수 있고, Continuous Deployment의 바로 전 과정까지가 완성되고, 또 Continuous Delivery를 잘 유지한다면 Continuous Deployment를 적용시키는게 가능해 지는 등 CI와 CD는 조금씩 다르지만 서로에게 영향을 주는, 어떻게 보면 조금씩 겹쳐있는 개념입니다. 그러므로 용어가 조금씩은 헷갈릴 수 있습니다. 그럴때 마다 위에 제가 작성해 놓은 서로간의 차이점을 기억해 주세요! :)

4. CI/CD 파이프라인

앞서 말했듯, 웹앱의 배포 과정은 크게 작업물 커밋, 빌드, 테스트, 배포의 과정으로 나뉘어져 있습니다. 아래 이미지와 같이, CI/CD 파이프라인도 웹앱의 대략적인 배포 과정을 따릅니다. 단지 커밋만 하면 이후 과정들은 자동적으로 처리가 되기 때문에 신경 쓸 필요가 없다는 점만 빼면 말이죠.

5. Github Action을 통한 CI/CD 구축

Github Action은 깃허브 레포지토리에 존재하는 코드의 CI/CD 구축을 도와주는 기능입니다. Github Action을 사용하기 위해서는 CI/CD 과정에서 어떤 작업을 할지 미리 정해주는 yml 파일 작성이 필요한데, 레포지토리의 Actions 탭에서 작성 할 수 있습니다.
yml파일을 처음 작성한다면 파일에서 사용되는 yaml문법이 익숙하지 않을 수 있는데, 작성법은 아래 링크를 참조해주세요. https://www.codeproject.com/Articles/1214409/Learn-YAML-in-five-minutes

5.1 Github Action 사용 과정

1. 레포지토리의 Actions 탭에서 New workflow를 클릭합니다.

2. set up a workflow yourself를 클릭합니다.

3. yml파일의 이름을 지정하고 내용을 작성합니다(yml 파일은 디폴트 브랜치에 생성됩니다. 예시에서의 디폴트 브랜치의 이름은 reference입니다).

4. 이름과 내용을 모두 작성 뒤 start commit을 클릭해 yml파일을 커밋합니다.

5. 커밋이 되면 레포지토리에서 Action이 실행됩니다(노란색 원은 실행중, 초록색 원은 Action이 에러없이 성공적으로 완료되었다는 뜻 입니다. 빨간색 원이 뜨면 yml파일 실행 도중 에러가 났다는 뜻 입니다.)

참조 문헌: https://circleci.com/continuous-integration/ https://stackify.com/continuous-delivery-vs-continuous-deployment-vs-continuous-integration/

1. 화면에 콘텐츠가 표시되기 까지의 시간 소요
2. 콘텐츠 표시 후 사용자와 상호작용을 하기 까지의 시간 소요
3. 화면에 불안정한 요소들이 있는지의 여부 이 외에도 다양한 항목들이 등이 성능 측정의 기준이 된다.

performace기능은 opportunities라는 부기능을 제공하는데, *opportunities는 개발자가 웹페이지의 더 나은 performance를 위해 어떤 점을 개선시킬 수 있는지 제안해 준다. *

다음은 opportunities의 세부 항목을 살펴보겠다.

구글 라이트하우스 공식문서에는 opportunities 항목을 17가지로 구분하고 있다.

1. Eliminate render-blocking resources
2. Properly size images
3. Defer offscreen images
4. Minify CSS
5. Minify JavaScript
6. Remove unused CSS
7. Efficiently encode images
8. Serve images in modern formats
9. Enable text compression
10. Preconnect to required origins
11. Reduce server response times (TTFB)
12. Avoid multiple page redirects
13. Preload key requests
14. Use video formats for animated content
15. Reduce the impact of third-party code
16. Avoid non-composited animations
17. Lazy load third-party resources with facades

출처: https://developer.chrome.com/en/docs/lighthouse/performance/

항목이 너무 많으니 이 중 아래 이미지에 있는 세 가지 항목을 자세히 알아보도록 하겠다.

1. reduce unused javascript

사용하지 않는 자바스크립트 코드를 삭제하거나 필수적이 아닌 whitespace를 없애는 것은 자바스크립트 코드를 최적화 시키는데 도움을 줄 수 있다. 그리고 최적화된 JavaScript코드는 코드를 parse하는 시간과 payload의 크기를 줄일 수 있다.

리액트의 경우, npm run build로 코드가 자동으로 최적화 된다면, production 모드로 빌드를 하고 있는지 꼭 확인해야 한다.

2. preload largest contenful paint image

큰 파일은 불러오는데 많은 시간이 소요될 수 있다. 따라서 불러올 수 있는 즉시 불러와 주는게 빠른 화면 렌더링에 도움이 된다. 예를 들어, 웹페이지의 critical request chain이 아래와 같다고 가정해 보자.

index.html |--app.js |--example.jpg

1. index.html에서 script(app.js)를 불러온다.
2. app.js 내에서 fetch를 통해 example.jpg를 불러오게 된다.

이 경우, example.jpg은 앞선 두 가지 체인이 완료 되어야만 불러와진다. 그러나 app.js파일을 불러오는 동시에 example.jpg도 불러와 진다면 이미지가 로딩되는 시간을 줄일 수 있을것이다. 방법은 JS 내부에서 fetch를 사용하지 말고, html 내부에서 아래와 같이 link 태그로 이미지를 불러온 뒤 rel = "preload" 속성을 부여하면 된다.

<link rel="preload" as="image"  href="example.jpg" />

이 방법을 사용하면 app.js와 example.jpg가 동시에 요청이 된다.

3. reduce unused css

자바스크립트 코드와 마찬가지로, 사용하지 않는 CSS 코드의 삭제, 필수적이지 않은 whitespace의 삭제는 CSS를 최적화 시키는데 도움을 줄 수 있다. 그리고 합쳐질 수 있는 CSS 코드는 아래 이미지와 같이 합쳐주는게 추천된다.

아래 링크에는 CSS 최적화 가이드 이다. https://web.dev/minify-css/

리액트의 경우, npm run build로 코드가 자동으로 최적화 된다면, JavaScript의 경우와 마찬가지로 production 모드로 빌드를 하고 있는지 꼭 확인해야 한다.

0. 서론

섹션 2를 끝내고 나서 회고록을 작성했던 때가 기억난다. 그 때는 섹션 1에서 다짐했던 것들을 어느정도 실천할수 있게 되어서 기뻤었다. 그러나 현재는 완전히 다른 느낌이다. 지쳐버린 것인지 뿌듯함과 후회 둘 중 어느쪽의 감정도 들지 않는다. 그냥 나는 주어진 것을 해 나갔을 뿐 뭔가 잘했고 못했고를 따질 심적 에너지가 없다.

그래서 나는 이 회고록을 어떻게 작성해야 할지 갈피를 잡을 수 없다. 생각이 정리되질 않는다. 그러나 박스에 색깔대로 바르게 나열된 물감세트보다 캔버스에 흩뿌려져 뒤섞여버린 그런 모양이 더 아름다워 보일때도 있는 법이다. 그러므로 나는 이 회고 글을 마음대로 막 쓸것이다. 이런것도 나름의 재미가 있을것이다.

1. 체력적, 심적 연소와 교환된 것

나를 지금 힘들게 하는 이 '지침'의 감정은 무엇과 교환되었을까? 플러스도 있고 마이너스도 있었는데 차례대로 알아보자.

1.1 실력과의 교환

얻은것은 코딩실력이다. 물론 아직도 많이 부족하지만 예전의 나 보단 코드를 완성하는 속도가 빨라졌다. 부트캠프 특성상 진도가 너무 빠르고 이것저것 학습하다 보니 정신이 없어진다. 그리고 정신이 없는 와중에도 복습을 해야한다. 어렵고 서로 관계성이 크지 않은 개념들을 연속해서 배우다 보면 잊어버리기 쉽다. 그러므로 복습은 필수이다.
그 과정에서 많이 연습했고 많이 실패했고 많이 해결했다. 그리고 그런 과정을 겪었던 덕분에 파이널 프로젝트에서 이전보다 작업속도가 월등히 빨라졌음을 느낄 수 있었다.

1.2 창의성과의 교환

체력적, 심적 연소와 교환한 또 다른것이 있다. 창의력이다. 아쉽게도 이건 얻은것이 아니라 잃은 것이다. 현재의 나는 지쳐버려서 창의적인걸 생각하기가 싫어져 버렸다. 그리고 나는 새로운 것을 시도하지 않는 내 자신이 매우 싫다. 창의성이 샘솟으려면 새로운 경험과 영감이 필요하다. 안타깝게도 지금 나는 그런것들에 노출되어도 원래의 나처럼 반응하지 않는다. 새롭고 신선한 자극을 느끼는 기능을 하는 심리적 receptor가 둔화되어 버렸다. 그리고 나는 이런 내가 나같이 느껴지지 않는다. 자아를 잃어버린 느낌이다.

2. 휴가

마음의 연료를 채워넣기 위해서 위해서 난 내일부터 여행을 떠날것이다. 마침 부산에서 지스타가 열린다. 내가 좋아하는 게임도 지스타에 참여한다고 한다! 부산에서 친구도 만나고 생각없이 아무 길이나 걷기도 할 예정이다. 바닷바람에 잡생각을 실어 날려보내고 싶다.
오고가는 시간이 꽤 길어서 다녀오고 나면 꽤 지칠수도 있겠다 생각이 들어 걱정되기도 하지만 일단 기대되는 마음이 더 크다.
이번 여행이 심적 전환이 되어주길 바란다.

3. 감사한 분들

섹션 3을 시작하면서부터 너무 감사한 분들이 많아졌다. 스터디에 참가하게 되었는데 다들 너무 잘하시고 열심히 하셔서 굉장한 자극을 받는다. 그리고 분위기가 어색해질까봐 다들 티는 잘 안내시지만 이타적이고 사려깊으시다는 것도 잘 알고 있다. 내가 힘들때면 걱정해주시는 것도 아주 잘 느끼고 있다. 이분들 때문에 그래도 어찌저찌 섹션 3을 버티는걸 성공하지 않았을까?

이분들께 간결하게 한마디만 드리고 싶다.

진심으로 감사드립니다.

오늘은 웹 접근성과 웹 표준성에 대해 알아보겠다.

먼저, 웹이란 단어를 정확히 정의,파악해야 웹 접근성과 표준성에 대해 더 잘 이해할 수 있다. 웹이란 무엇일까?

1. Web의 정의: 웹과 인터넷은 다르다!

techopedia 에서는 웹에 대해 아래와 같이 정의하고 있다.

"The Web is the common name for the World Wide Web, a subset of the Internet consisting of the pages that can be accessed by a Web browser. Many people assume that the Web is the same as the Internet, and use these terms interchangeably. However, the term Internet actually refers to the global network of servers that makes the information sharing that happens over the Web possible. So, although the Web does make up a large portion of the Internet, but they are not one and same." 출처ㅣ https://www.techopedia.com/definition/5613/web

(셀프번역함. 의역 오역 주의) 웹은 World Wide Web의 좀 더 보편화된 이름이며, 웹 브라우저를 사용하여 접근할 수 있는 페이지들로 이루어져 있는 인터넷의 "부분집합"입니다. 많은 사람들이 웹과 인터넷이라는 용어가 동일하며, 그 이유로 두 용어들이 서로를 대체할수 있다고 생각합니다. 그러나 "인터넷"은 웹 상의 정보 공유를 가능하게 해주는 서버들의 전역 네트워크를 의미합니다. 따라서, "웹"은 인터넷의 큰 부분을 차지하지만 인터넷의 동의어라고 볼 수는 없습니다.

이처럼 웹과 인터넷이라는 용어는 다르다. 웹은 다양한 형태의 정보를 타인과 공유할 수 있는 공간이다. 그러면 웹을 사용함에 있어서 왜 접근성과 표준성이 중요할까?

2. 웹 표준

2-1. 웹 표준이란?

웹 표준은 W3C(World Wide Web Consortium)에서 정의하고 있으며, 웹에서 표준적으로 사용되는 기술이나 규칙을 의미한다. 그렇다면 우리는 왜 웹 표준을 따라야 할까? 우리는 개인별로 각기 다른 환경에서 웹을 사용한다. 우리가 웹에 접속하기 위해 사용하는 운영체제, 웹 브라우저나 디바이스는 개인의 선택에 따라 다양하다. 웹 표준을 준수하는 이유는 이렇게 다양한 환경에서 웹페이지가 시각적, 기능적으로 동일하게 작동할 수 있도록 하는 규칙이다.

2-2. 웹 표준과 Semantic HTML

웹 표준을 지키기 위해서는 HTML 내부에서 Semantic 태그를 사용하는 것이 매우 중요하다. 왜 중요할까? 이유는 아래와 같다.

1. 접근성 툴(스크린리더 등)의 사용성에 영향을 주기 때문. 스크린 리더는 CSS와 JavaScript가 어떻게 짜여있는지는 모두 무시하며, HTML에만 의지한다. 이런 환경에서 스크린 리더 사용자는 HTML 태그가 주는 정보로 각 내용이 어떤 목적으로 쓰여졌는지 파악할 수 있다.

2. 검색 엔진에서의 검색 결과에 영향을 미치며, 시맨틱 요소가 잘 활용된 HTML은 검색 엔진 상위에 노출될 수 있다.

3. semantic 태그의 디폴트 스타일과 기능을 사용하기 위함 각 태그에는 디폴트 스타일과 기능이 부여되어 있는데 이를 사용하려면 div나 span같이 non-시맨틱한 태그보다는 시맨틱 태그를 사용해야 한다.

(출처: https://www.jungledisk.com/blog/2017/12/04/should-i-bother-with-semantic-html/)

*왼쪽 보다는 시맨틱 요소가 잘 적용된 오른쪽 형태의 HTML 작성법이 권장된다.

HTML 내의 시맨틱 태그 이외에도 W3C가 제시하는 웹 표준은 여러가지가 있다. CSS, SVG, WOFF, XML 그리고 여러 API를 사용하는데에 있어 웹 표준이 존재한다. (출처: https://www.w3.org/standards/)

3. 웹 접근성

3.1 웹 접근성이란?

개인별로 다양한 환경에 있더라도 웹 상 정보의 전달성을 유지하게 도와준다는 점에서 웹 접근성과 웹 표준의 목표는 어느정도 닮아있다. 그러나 웹 표준은 기술적 환경에 중심을 두는 반면, 웹 접근성은 사용자에 중심을 두고 있다.

W3C는 웹 접근성에 대해 이렇게 정의하고 있다.

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.

(셀프번역함. 의역 오역 주의) 웹 접근성이란 장애를 갖고 있는 사람들도 웹사이트나 도구, 그리고 기술을 이용할 수 있도록 웹이 디자인되고 개발되는 것을 의미한다.

그리고 웹 접근성이 필요한 대상은 아래의 장애를 일시적, 영구적으로 가지고 있는 사람들을 모두 포괄한다.

• 청각적(auditory)

• 인지적(cognitive)
• 신경적(neurological)
• 신체적(physical)
• 언어적(speech)
• 시각적(visual)

그러나 장애를 가지고 있는 사람들 뿐만 아니라 비장애인들 에게도 도움을 줄 수 있다. 아래는 예시이다.

• 작은 스크린 혹은 보편적이지 않은 조작 모드를 채택하고 있는 디바이스를 사용하는 사람들

• 노화로 인하여 신체적 능력이 저하되고 있는 사람들
• 팔이 부러지거나 안경을 잃어버리는 등의 일시적 장애를 겪고 있는 사람들
• 너무 밝은 햇빛 때문에 화면을 볼 수 없거나 소음 때문에 청각적 자료를 듣기 어려운 등 환경적 요인 때문에 정상적인 디바이스 사용에 제한을 겪고 있는 사람들
• 느린 인터넷이나 제한적인 대역폭을 사용하고 있는 사람들

이처럼 웹 접근성은 사용자의 환경에 상관 없이 필요한 정보를 동등하게 전달할 수 있도록 하는 것에 의의를 두고 있다.

(출처: https://www.w3.org/WAI/fundamentals/accessibility-intro/)

3.2 웹 접근성 추구의 장점

알아보았듯, 웹 접근성 가이드라인을 잘 따른다면 다양한 환경의 사람들에게 정보를 제공할 수 있다. 안타깝게도, 전체 웹사이트 중 약 98%가 W3C의 웹 접근성 가이드라인을 충족하지 못하고 있다.

그러나 비즈니스 목적의 웹사이트들은 웹 접근성 가이드라인을 준수함으로 인하여 웹 접근성의 본질적 목표(다양한 환경의 사용자들에게 정보를 동등하게 제공)를 추구할 수 있을 뿐만 아니라, 사업상으로도 많은 이점을 취할 수 있다. 어떤 이점들이 있을 수 있는지 알아보자.

1. 웹 접근성 준수는 더이상 권고 사항이 아니며, 비즈니스들은 의무적으로 준수해야만 한다(미국한정. 국내상황은 잘 모름). 그렇지 않으면 소송이 들어올 수 있다.

   • 예시로써, 넷플릭스는 National Association of the Deaf(미국 청각장애인 연합?)의 소송에 따라 모든 영상물의 청각적 정보들을 시각적 자료로 해석 할 수 있게끔 관련 서비스(자막 등)를 제공하기로 동의했다.

2. 사업적 이득 추구에 도움이 된다.

   • 비즈니스의 사용자층을 더 확장시킨다
     • 비장애인 뿐만 아닌 더 폭넓은 사용자층을 확보할 수 있다. 영국의 한 리포트에 따르면, 장애를 가지고 있는 71%의 사용자가 사이트 이용에 어려움을 느끼면 바로 닫기나 뒤로가기를 눌러버린다고 한다. 웹 접근성을 준수하지 않음으로 인해 잠재 고객들을 놓쳐버리고 있을 수 있다.
   • SEO에 영향을 미친다.
     • 웹 접근성을 준수하게 되면 인간들 뿐만 아닌 웹 크롤링 로봇이나 검색엔진으로의 정보 전달성도 향상된다. SEO를 향상시킬 수 있는 웹 접근성 향상 방법은 아래와 같다.

    * 페이지 제목과 meta 속성 추가 
    * img 태그 사용 시 alt 태그에 적절한 설명 추가
    * 적절한 header 태그의 활용
    * 가독성 향상을 위한 색상 대비 규칙 준수 
    * 내용을 기계들도 읽을 수 있게 보장하기 
    * 사용자가 내용에 대해 유추할 수 있는 link 텍스트 제공

(출처: https://www.aztekweb.com/blog/post/what-is-website-accessibility-and-why-it-matters/)

UX/UI 디자인에 대해 알아보겠습니다. UX(User Experience)와 UI(User Interface) 디자인, 이 두 가지 용어는 흔히 같이 붙어 다닙니다. 그렇기 때문에 우리는 종종 두 가지가 같은 개념이라고 혼동합니다. 그러나 엄연히 따지면, 두 용어는 프로덕트 개발의 서로 다른 영역을 지칭합니다.

UX와 UI, 두 개념은 서로 다른 개념입니다. UX는 UI를 포괄하는 개념이지만, UI는 모든 UX를 다루지 않습니다.

🧿1. UX

🔵 1.1 UX란?

UX는 사용자가 서비스를 이용하는 과정에서 일어나는 모든 형태의 상호작용을 포함합니다. 따라서 UI는 UX에 포함될 수 있지만, 그 반대는 아닙니다(아래에 UI의 정의가 설명되어 있으니 참조). 우리는 해당 용어가 디지털 영역에서 많이 사용되기 때문에 그 쪽에서 쓰이는 전문적 용어인가? 하고 의문을 가질 수 있습니다. 그러나 UX는 디지털 영역에 한정되지 않으며, 엄밀히 말하자면 인지과학쪽 영역에 속합니다. 아래는 UX 요소의 예시입니다.

🔵 1.2 UX의 예시

• 구매한 물건이 불량일 경우 환불 절차는 중요합니다. 절차가 복잡하거나 아예 되지 않을 경우 사용자는 부정적 경험을 하게 됩니다. 때문에 물건의 환불 절차가 어떻게 짜여 있는지도 UX적 요소에 포함됩니다.
• 마트에서 물건을 살 때 가격표의 가독성은 중요합니다. 가격표가 읽기 힘들게 작성되어 있으면 좋은 쇼핑 경험을 이끌어 내는 과정에서 마이너스 요소가 될 수 있기 때문에 가격표의 작성 형태도 UX적 요소에 포함됩니다.

이 외에도, 제품의 색깔이 주는 심리적 영향 등 굉장히 많은 부분이 UX에 포함 될 수 있습니다.

🔵 1.3 UX 디자인의 목적

좋은 UX 디자인을 하는 궁극적 목적은 쉽고, 효율적이고, 전반적으로 유저에게 편안하고 만족스러운 사용 경험을 선사하는 것입니다. UI와도 목적성을 공유하는 부분이 있지만 디지털적 영역만 한정하고 있는 UI와 달리, UX는 사용하는 과정에서의 총체적 경험을 모두 포함합니다.

🧿2. UI

🔵 2.1 UI란?

UI는 앞서 말했듯 UX에 포함되며, 좋은 UI 디자인은 UX를 보완해 줄 수 있습니다. UI는 UX와 달리 디지털 영역에서 쓰이는 용어입니다. UI 디자인은 유저가 디지털적 제품을 사용함에 있어 편리성, 상호작용의 용이함이 고려됩니다. UI에는 사용자가 마주하는 모든 디지털적 경험이 포함됩니다(마우스와 키보드같은 물리적 요소와 사용 프로그램같은 비물리적 요소 모두 포함). 아래는 UI 요소의 예시입니다.

🔵 2.2 UI의 예시

• 스마트폰을 사용 할 때 그립감은 중요합니다. 너무 크거나, 작거나, 각진 스마트폰은 사용에 편리하지 않습니다. 때문에 스마트폰 형태의 디자인은 UI적 요소에 포함됩니다.
• 앱에서 내용이 얼마나 보기 쉽게 나열되어 있는가는 중요합니다. 정보가 알아보기 어렵게 작성 되어있다면 유저는 정보를 소화하는데 시간적 딜레이를 경험합니다. 때문에 정보나 내용이 나열/정렬되어 있는 형태는 UI적 요소에 포함됩니다.

  🔵 2.3 UI 디자인의 목적

  좋은 UI 디자인은 유저가 제품과 상호작용을 하는 과정에 있어 심플하고 효율적이어야 합니다. UX와의 차이점은 사용자 경험 중 디지털적 영역 외의 다른 부수적인 요소들을 포함하지 않는다는 점 이며, 상호작용의 편리성과 직관성에 더욱 중점을 둡니다. 심미성도 UI 디자인의 목적이 될 수 있지만 해당 항목은 상호작용의 편리성과 직관성에 해가 되지 않아야 합니다.

참고 출처: https://careerfoundry.com/en/blog/ux-design/the-difference-between-ux-and-ui-design-a-laymans-guide/

0. 서론

벌써 오늘이 섹션 2의 마지막 날이다.

저번 섹션보다 내용이 어려웠기 때문인지 이번 내용을 공부하면서는 이런 저런 생각들이 많이 들었다. 그리고 생각이 복잡해진 탓인지 여러가지 부정적 감정이 몰려왔다.

내용들을 깊게 공부해 보기엔 진도가 빨라서 아쉽다는 생각도 하고, 원하는 대로 공부가 진행이 되지 않을때, 그리고 개념들이 이해가 되지 않을 때에는 다소 자기 비하적인 생각이 들기도 한다. 따라서 내가 현재 어떻게 생각하고 느끼는지 되돌아 보면서 멘탈을 정리하는것이 필요하다고 느낀다.

위와 같은 이유로, 이번 회고는 나의 목표를 이루기 위한 플랜 작성에 중심을 두었던 저번과 달리 공부하면서 들었던 나의 감정과 생각을 다루는 데에 비중을 더 할애하려고 한다.

꽤 난이도가 있었던 섹션2 회고를 시작해 보겠다.

1. 공부 과정 되돌아보기

코드스테이츠 과제를 진행하면 우리는 스스로의 힘으로 무언가를 만들었다는 착각에 빠지기가 쉽다.

아래 이미지는 섹션2의 twittler 과제 이다.

예쁘고 아름다운 것을 만들면 기분이 좋다. CSS에 공을 들였고, 작은 기능과 추가적인 특이 케이스 핸들링을 구현했다는 이유로 대단한 게시판이라도 만든 듯한 착각에 빠진다.

그러나 이런 기분을 느끼는 것이 뭔가 잘못 되었음을 느꼈다. 나는 우매할 뿐이었다. 나의 실력을 객관적으로 되돌아 본 결론은 "나는 기본적인 게시판도 만들지 못한다" 였다. 중요한 부분들이 모두 짜여진 코드를 clone하고, 거기에 라인 몇개를 추가하고 테스트를 모두 통과한다고 해서 내가 그것을 다 만든 것이 아니라는 것이다.

내 실력에 대해 생각하고 그 결론에 뼈를 맞은 뒤, react로 아고라 스테이츠를 만들어 보았다. 의도치 않게 section2 솔로 과제를 미리 해 본 꼴이 되었는데, 덕분에 파이널 프로젝트를 조금 더 수월하게 할 수 있었다.

기본 틀이 전혀 없이 아예 처음부터 시작하니 막막했다. section 1에서 구현하지 못해서 아쉬웠던 부분(하드코딩을 쓰지 않은 진짜 페이지네이션, 로컬 스토리지)도 리액트로 추가 해 보려니 많이 힘들었다.

아래는 react로 게시판을 구현하고, 추가로 더미데이터 대신 서버에서 fecth로 데이터를 불러와 적용한 솔로 프로젝트 과제이다.

• 페이지 네이션
• 로컬 스토리지

못생겼다. 특이 케이스 핸들러도 없고, 예쁘지도 않지만 이걸 만들면서 정말 많이 배웠다.

그러나 아직도 모르는 부분이 너무나도 많다. 내가 만들었는데 왜 작동이 되는지 이해가 가지 않는 부분도 있고, 더 나은 방법을 쓸 수 있는데 지식적으로 모자라 쓰지 못한 방법도 있다. 또한, 결정적으로 내가 직접 공부하고 이해해서 구현을 했지만 지금은 까먹은 부분이 많은데 다시 복습이 필요하다.

*익숙하지 않은 정보에 대한 뇌의 휘발성은 엄청나다. *

개발 공부를 할 때에는 수학문제를 푸는 것 처럼 같은 개념을 계속해서 꾸준히 접해봐야 어느정도 익숙해 지는 것 같다. 그런 부분에서 원래 복습을 하기 싫어하는 나 자신을 좀더 채찍질 할 필요가 있다. 예습보다 복습이 훨씬 더 중요한 것 같다.

아래는 더 깊이 계속 복습해야 할 주제들이다.

• 프로미스
• 클로저
• 네트워크와 서버 기초

2. 공부, 생활 습관 되돌아보기

저번 섹션1 회고에서는 효율적인 공부를 하기 위해선 좋은 생활 습관이 필수라고 적었었다. 그리하여 첫째로, 그곳에서 최우선 순위에 두었던 To-do list를 살펴 보려고 한다.

2-1. Section 1의 다짐 되돌아보기

• 스트레스 받으면 집 청소하기
• 공부 하루 양 계획, 매일 지키기
• 요리 재료 소분

모두 나름 잘 지켜왔지만, 조금 아쉬웠던 부분은 하루에 공부할 양을 계획하고 그걸 지키기 이다. 아주 가끔 급발진 해서 주말에 공부를 하다가 새벽 6시에 잔 적도 있다. 그리고 다음날은? 늦은 오후에 일어나서 기분이 좋지 않고, 체력이 없고, 집중력도 떨어져 당연히 아무것도 하지 못했다. 그래도 예전에 비해 이런 일이 일어나는 빈도가 훨씬 줄었다는 점에서 잘 하고 있다고 생각한다.

2-2. Section 2의 공부, 생활습관

둘째로, Section 2에서 공부를 하면서 느꼈던 나의 잘한 점, 못한 점을 되돌아 보려고 한다.

• 잘한 점
  • 명상 시작
  • 복습에 대한 거부감이 조금 극복됨
  • 게임하는 시간이 줄었음(게임 실력도 줄었지만 코딩 실력과 교환 했다고 치면 오히려 좋다.)

• 못한점
  • 블로그에 조금 소홀함
  • 유어클래스 화면만 들어가면 심리적인 요인 탓인지 독해능력이 저하되어 글을 읽지 못하겠음
  • 예전보다는 나아졌다지만 여전히 식사를 잘 챙겨먹지 않음.
  • 평균적으로 잠자리에 드는 시간이 새벽 2시임. 차라리 빨리 자고 일찍 일어나는 편이 나을듯 함.

잘한 점 중에서 베스트는 단연 명상이다. 시작한지 일주일 조금 넘었지만, 꾸준히 할 수 있겠다는 생각이 든다. 매일 10분 즈음 촛불을 켜고 명상을 하는데, 하루를 보내면서 생겼던 복잡한 생각과 감정들이 정돈된다. 마음이 심란할 때 명상을 하고 나면 신기하게도 하기 싫었던 청소도, 공부도 할 용기가 생긴다. 그리고 내일을 더 잘 준비할 수 있게 한다.

못한 점 중 1위는 유어클래스를 잘 안보는 것이다. 보통 유어클래스에선 공부해야 할 키워드만 훑고 인터넷에 검색해 영상 자료나 문서를 참고해서 공부를 했는데, 유어클래스를 대충 보고 넘어가니 꼭 배워야 할 부분을 빠뜨렸던 적도 있다. 이상하게 유어클래스 문서는 잘 읽히지 않는다. 앞으로는 외부 자료로 공부를 하더라고 꼭 마지막엔 유어클래스를 정독해야겠다.

3. 마치며

공부를 하면 할 수록 공부를 해야하는 부분이 더 많이 보여서 앞으로 잘 해낼 수 있을까 걱정이 많이 된다. 걱정을 조금이나마 극복하려면 나 자신에게 항상 강조했던 멘탈과 체력 관리가 앞으로도 계속 중요 할 것이다.

멘탈, 체력관리 측면에서 섹션1의 나와 지금의 나를 비교하면 분명 약간 더 잘하긴 했다. 앞으로도 계속 조금씩 나아지도록 노력할 것이다. 최근에 시작한 명상도 계속 하고, 가끔은 운동을 하면서 체력 관리도 하고, 공부하는 데에 신경쓰이지 않게 환경을 만드는 데에 집중할 것이다.

한달 후 다음 회고를 할 때까지 내가 크게 나아질 것이라고 기대치 않는다. 내가 다짐한 것들을 모두 지킬 수는 없을 것이다. 다만, 지금보다 개선되기만 하면 충분하다고 생각한다.

나는 공부를 할 때 체력과 시간이 충분하면 진도를 미리 나가놓는 편이다. 내가 예습을 하는 경우는 크게 두 가지가 있다.

1. 어떠한 주제가 흥미로워서 빨리 배우고 싶을때
2. 흥미가 없는 주제일 때, 그리고 일을 미루거나 잘 해내지 못했을 경우 생기는 죄책감과 패닉을 경험할 위험도를 줄이고 싶을때

나에게 문제가 되는 경우는 2번이다. 흥미가 없으면 당연히 일의 효율이 떨어진다. 그리고 효율 저하를 극복하기 위한 목적의 예습이 왜 문제가 되는지 서술하겠다.

미룸의 사이클. 미루기 ➜ 죄책감 ➜ 패닉상태 ➜ 핑계거리 생성 ➜ 또 미루기의 반복.

나는 위 사이클을 경험할 때 죄책감과 패닉이 나에게 얼마나 크게 다가오는지 알고 있다. 이러한 감정들 속에서 단순히 정신적으로 힘든 것을 넘어서 신체적인 증상을 경험할 때도 종종 있다. 인정할 수 밖에 없다. 나는 멘탈이 약하다. 남들은 부정적 감정들을 나보다 잘 극복하는 것 같은데 나에게는 그것들이 훨씬 극대화 되어 느껴지는 것 같다.

그러한 이유 때문에 나는 일을 미리 해 놓는 편이다. 정신적 고통을 방지하기 위한 일종의 회피 수단이다. 어떤 사람들은 일의 마감 기한이 다가오기 시작하면 그 아슬함이 오히려 촉진제가 되어 일이 잘 된다지만, 나는 기한에 비해 진행 상황이 많이 더딘 경우에 불안함, 죄책감의 늪에 빠져 아무것도 하지 못한다.

이 감정들이 왜 나에게는 훨씬 무거운 것인지 나를 잘 들여다 보자. 개인적으로 죄책감, 패닉 중 후자가 훨씬 힘들기 때문에 이 글에서 더 중점을 두려고 한다.

2. 나는 왜 패닉하는가?

패닉이라는 감정이 나한테 크게 다가오는 이유가 무엇일까? 그 이유를 알기 위해서는 나 자신에게 많은 질문을 할 필요가 있고 그것에 솔직하게 답해야 한다.

2-1. 나는 왜 두렵고 불안한가?

왜 나는 마감기한이 다가오면 두려운 것일까? 이는 아마 나의 완벽주의 성향이랑 관련이 큰 것 같다. "완벽주의"라는 단어만 들으면 이 사람은 항상 완벽할 것 같다. 그러나 절대 아니다. 내 특성 중 정말 싫어하는 것을 몇 개 꼽으라면 그 중에는 완벽주의가 반드시 있다. 나는 내가 완벽하지 못할 상황이 무섭다. 내가 준비가 되지 않은 상태라면 난 완벽할 수 없다. 준비를 할 수 없으면 아예 그 일을 하지 않는다. 완벽을 추구하려다 결과물을 아예 내놓지 못하는 상황이 발생하는 것이다. 그렇기에 미리 일을 한다.

2-2. 나는 내가 왜 완벽해야 한다고 생각하는가?

생각해보면 사실 내가 완벽해 보여야 할 이유는 전혀 없다. 나도 허점 투성이인 인간이기 때문이다. 그럼에도 불구하고 나 자신과 남들에게 뛰어나다는 인상을 주고 싶어한다. 이 욕구는 내가 원해서 드는 것이 아니다. 성장 과정에서의 몇 가지 요인들이 내가 그런 욕구를 좀 더 느끼도록 영향을 미쳐 왔다고 생각한다. 나는 이 욕구가 굉장히 불편하며 별로 느끼고 싶지 않다. 그러나 느끼기 싫다고 해서 내 마음대로 컨트롤이 되는 것이 아니다. 다스리는 것을 조금 연습하면 나아지려나?

3. 왜 죄책감과 패닉을 방지하는 목적으로써의 예습은 문제가 되는가?

내가 싫어하는 나의 성향을 되려 독려하는 꼴이 된다. 완벽하게 보이고 싶어서 예습을 하고, 그것이 성공할 경우 뿌듯함이라는 보상이 생기기 때문이다.

3-1. 보상과 패널티

내가 느끼는 나의 단점에 관련된 것(좋은 평가, 좀 더 완벽하게 보일 수 있기 위함을 위해 예습하기)을 행하면 패널티가 있어야 한다. 그래야 그 행동을 하지 않게 된다. 그러나 완벽주의에서 기인한 예습을 하는 경우, 반대로 보상이 생긴다.

3-2. 보상의 위험

본능적으로 우리는 보상을 받을 수 있는 행동을 하는 것을 추구하지 않는가? 뿌듯함이라는 보상을 받으면 나는 그 달콤한 감정을 다시 느끼기 위해서 다시 예습이라는 행동을 할 것이다. 순수한 지식욕이 아닌, 나와 남들에게 잘 보여야 한다는 목적으로 하는 예습을 반복할 경우 나의 완벽주의 성향은 계속 강해질 것이며 나아가 타인의 평가와 시선에 더 민감해 질 것이다. 그렇게 되면 나는 갖가지 정신질환에 노출 될 수 있다. 완벽주의라는 성향도 건강하지 않다고 생각하는데 그에 더하여 정신질환에 의한 고통까지 느끼게 될 것이다.

4. 마치며

나는 전혀 완벽한 사람이 아니라는 것을 항상 상기해야 한다. 관심 없는 일, 하기 싫은 과제는 귀찮을 수 있다. 귀찮음을 느끼는 것은 당연하다. 왜냐하면 나는 불완전하기 때문에 모든 것에 흥미를 느낄 수 없기 때문이다.

별로 하고 싶지 않은 일이 주어졌을 경우, 완벽하게 보이기 위해서 보다는 이 일을 하지 않으면 생길 나 자신 혹은 타인의 피해와 불이익에 대한 적절한 책임감만 가지고 일을 해 나가면 된다.

나 스스로에 대한 생각을 종종 하는 편인데 오랜만에 그것을 글로 옮겨 보았다. 항상 기억하고 싶다.

Open API는 말 그대로 오픈 되어있는, 누구나 이용할 수 있는 API를 말한다.

공공데이터 처럼 모두가 접근할 수 있는 정보의 배포 목적으로 Open API가 쓰인다. Private API에 비해 비교적 사용 제약이 적다. 그러나 제약이 없는 것은 아니며, API 마다 제약이 다르니 주의해야 한다.

API Key

API Key는 API 사용을 위해 필수적이며, API와 연결된 서버를 연다.

정보에 접근하기 위해 Key가 필요 없는 경우도 있지만 API Key가 필요한 API로 데이터를 요청하는 경우, 로그인한 사용자에게 데이터 접근 권한이 API Key로 제공된다. 사용자는 개인, 혹은 프로젝트가 될 수 있다.

사용자는 데이터를 요청할때 API Key를 같이 전송해야만 한다. Key는 쿼리, request의 헤더, 쿠키 등의 형태로 전송될 수 있다.

REST API에 대해 설명하기 전, API가 무엇인지 잠깐 훑고 가겠다.

클라이언트는 원하는 정보/기능에 접근하기 위해 일종의 명령 메뉴얼이 필요하다. 서버는 이 메뉴얼을 제공하는데, 이를 API(Application Programming Interface)라고 한다. 이 말이 잘 이해가 안간다면 아래 예시를 보자.

최근 장을 보러갔는데 무 가격때문에 놀랐던게 갑자기 생각나서 무를 예시로 들겠다. 요새 동물의숲 무트코인 마냥 현실 무값도 굉장히 올랐는데, 오늘 무 요리를 하기 위해 무를 사야한다고 가정해보자. 나의 전재산이 1000원밖에 없어서 무가 그보다 비싸면 살 수 없기 때문에 서버를 통해 데이터베이스(무 현재 가격)에 접근해 오늘 무를 살지 말지 결정하려고 한다.

그런데 서버한테 "님 오늘 무 얼마임?"라고 물어봐야 할지, "금일 무의 개당 시세는 얼마입니까?"라고 물어봐야 할지 모른다. 이 상황에서 API는 무 가격을 확인할 수 있는 올바른 방법을 지정해 준다. 서버에서 무 값을 확인하기 위해서 "오늘 무값 알려줘"라고 말해야 한다고 API가 정해줬다고 가정하면 나는 서버에 문장 그대로 물어보면 된다.

🔵REST API

REST(Representational State Transfer) API는, 로이 필딩(엄청 유명한 컴퓨터 공학자)의 논문에서 처음 소개 되었다. REST API는 웹에서 사용되는 데이터/자원을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의하는 방식을 말한다.

🔵REST 성숙도 모델

REST 성숙도 모델은 레너드 리처드슨(REST API 전문가)에 의하여 창시되었으며, 0-3단계가 있다. 좋은 REST API를 만들기 위해서는 이 모델을 참조하면 된다.

다음은 각 단계를 알아보자.

🟣 0단계

클라이언트와 서버의 request/response 과정에서 HTTP 프로토콜을 사용하기만 하면 0단계는 충족된다.

성숙도 모델의 0단계를 적용한 병원 예약 예시의 그래프다. 해당 예시는 3단계 까지 계속 쓰인다.

🔴클라이언트의 HTTP 메세지(request message): 예약 가능 슬롯 요청

POST /appointmentService HTTP/1.1
[various other headers]

<openSlotRequest date = "2010-01-04" doctor = "mjones"/>

클라이언트(정보 요청자)는 mjones라는 의사에게 진찰을 받고싶어 한다. 클라이언트는 위 HTTP 메세지를 통해 예약 가능한 시간대 슬롯을 요청하고 있다. /appointmentService라는 엔드포인트를 이용해 필요한 정보에 접근한다.

🔴서버의 HTTP 메세지(response message): 예약 가능 슬롯 리턴

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot start = "1400" end = "1450">
    <doctor id = "mjones"/>
  </slot>
  <slot start = "1600" end = "1650">
    <doctor id = "mjones"/>
  </slot>
</openSlotList>

서버(응답자)는 예약 가능한 슬롯들을 XML 형식으로 리턴해주고 있다. 예시에서 XML을 사용하였을 뿐, 그 이외의 다른 형태의 정보(JSON 등)여도 상관없다.

⚫클라이언트의 HTTP 메세지(request message): 예약 요청

HTTP/1.1 200 OK
[various headers]

<appointment>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

클라이언트 jsmith는 예약하고 싶은 슬롯을 골라서 정보를 보낸다.

⚫서버의 HTTP 메세지(response message): 예약 확인

HTTP/1.1 200 OK
[various headers]

<appointment>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

서버는 jsmith가 원하는 슬롯에 예약이 되었다고 응답한다.

🟣 1단계

개별 리소스와의 통신을 준수해야 한다. REST API는 웹상의 모든 데이터/자원을 HTTP URI로 표현하는데, 모든 자원은 특정 데이터/자원에 맞는 엔드포인트를 사용해야 하며 요청/전달되는 데이터/자원에 대한 정보를 응답으로 전달해야 한다.

이전 0단계 예시에서는 예약 슬롯의 요청과 슬롯을 골라 예약하는 과정 모두 /appointmentService라는 단일 엔드포인트를 사용하였다. 그러나 REST Maturity Model의 1단계에선 두 리소스에 접근하는 엔드포인트를 구분해야 한다.

🔴클라이언트의 HTTP 메세지(request message): 예약 가능 슬롯 요청

POST /doctors/mjones HTTP/1.1
[various other headers]

<openSlotRequest date = "2010-01-04"/>

mjones라는 의사는 그 의사만의 리소스를 가지고 있으며, 0단계에서 모든 request에 동일한 엔드포인트를 사용했음과 대비, 엔드포인트도 '/doctors/mjones' 로 개별화 된다.

🔴서버의 HTTP 메세지(response message): 예약 가능 슬롯 리턴

HTTP/1.1 200 OK
[various headers]


<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

리턴되는 슬롯도 아이디가 부여되어 개별화 되어있는데 이 아이디는 밑 예시인 예약 요청 endpoint에 사용된다.

⚫클라이언트의 HTTP 메세지(request message): 예약 요청

POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

역시 id가 1234인 슬롯을 예약하기 위해 그 슬롯만을 위한 엔드포인트인 '/slots/1234' 를 사용하고 있다.

⚫서버의 HTTP 메세지(response message): 예약 확인

HTTP/1.1 200 OK
[various headers]

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

예약이 되었다는 응답을 주고 있다.

🟣 2단계

2단계에서는 HTTP 문법을 사용해야 한다. 이는 CRUD에 맞는 HTTP 메소드 사용이다. 0단계, 1단계 에서는 모든 요청에 POST를 사용했지만 2단계 에서는 실행하는 동작에 따라 다른 메소드를 사용한다.

🔴클라이언트의 HTTP 메세지(request message): 예약 가능 슬롯 요청

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

이전에는 정보 요청에도 POST 메소드를 사용하였지만, 이제는 정보를 요청(CRUD 중 READ)하는 동작에 맞게 GET 메소드를 쓰고 있다.

🔴서버의 HTTP 메세지(response message): 예약 가능 슬롯 리턴

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

response는 이전 단계와 같다.

⚫클라이언트의 HTTP 메세지(request message): 예약 요청

POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

예약을 요청하는 HTTP request는 이전과 같이 POST 메소드를 사용하고 있다. 슬롯의 예약 여부 정보를 생성(CRUD 중 CREATE) 해주어야 하기 때문이다.

⚫서버의 HTTP 메세지(response message): 예약 확인

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

예약이 되었다는 응답을 주고 있다. 여기서 201이 뜨는데, 이 HTTP 코드 속성에는 나중에 누군가 GET 메소드로 해당 정보를 읽어올 수 있게 위치 속성이 포함된다.

🟣 3단계

REST API Maturity Model의 마지막 단계인 3단계에서는 HATEOAS(Hypertext As The Engine Of Application State)라는 개념이 등장한다. 이 개념을 활용한 3단계 에서는 리턴되는 정보가 추가적인 URI를 포함해야만 한다.

🔴클라이언트의 HTTP 메세지(request message): 예약 가능 슬롯 요청

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

request는 2단계와 같다.

🔴서버의 HTTP 메세지(response message): 예약 가능 슬롯 리턴

HTTP/1.1 200 OK
[various headers]

<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/1234"/>
  </slot>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
     <link rel = "/linkrels/slot/book" 
           uri = "/slots/5678"/>
  </slot>
</openSlotList>

그러나 response에 새로운 것이 생겼다. 어떤 URI로 가야 해당 슬롯을 예약할수 있는지의 추가 정보를 담고 있다.

⚫클라이언트의 HTTP 메세지(request message): 예약 요청

POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

레벨 2와 같다.

⚫서버의 HTTP 메세지(response message): 예약 확인

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]

<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "/linkrels/appointment/cancel"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/addTest"
        uri = "/slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "/slots/1234/appointment"/>
  <link rel = "/linkrels/appointment/changeTime"
        uri = "/doctors/mjones/slots?date=20100104&status=open"/>
  <link rel = "/linkrels/appointment/updateContactInfo"
        uri = "/patients/jsmith/contactInfo"/>
  <link rel = "/linkrels/help"
        uri = "/help/appointment"/>
</appointment>

슬롯 정보 response와 같이 이번 response로 추가 URI 정보를 담고있다. 예약 취소, 검사 추가, 시간 변경 등 리턴된 정보에서 파생될 수 있는 추가적인 action을 위한 URI가 있다.

출처: https://martinfowler.com/articles/richardsonMaturityModel.html

- HTTP는 HyperText Transfer Protocol
    ○ HTML과 같은 문서를 전송하기 위한 프로토콜임
    ○ 웹 브라우저와 웹 서버의 소통을 위해 디자인 된 프로토콜
    ○ 클라이언트-서버 모델과 HTTP 프로토콜
        § 클라이언트가 HTTP Messages 양식에 맞춰 요청을 보낸다(Requests) --> 서버는 HTTP Messages 양식에 맞춰 응답한다(Responses). 

- HTTP Messages의 구조
    ○ 리퀘스트와 리스폰스는 다음과 같은 유사한 구조를 지님. 
        § Start line: 요청이나 응답의 상태를 나타내며 항상 첫 줄에 위치함. 응답에서는 status line이라고 부름. 리퀘스트에서는 HTTP 메소드가 포함
        § HTTP headers: 요청을 지정하거나, 메시지에 포함된 본문을 설명하는 헤더의 집합
            □ 클라이언트(리퀘스트): 이거 내가 필요한 정보 속성이니까 찾아 주셈
            □ 서버: ㅇㅋ 내가 주는 정보 속성이다 
        § Body: 요청과 관련된 데이터나 응답과 관련된 데이터/문서 포함. 요청과 응답의 유형에 따라 선택적으로 사용.
    ○ 응답의 head
        § Start line / HTTP headers를 포함
    ○ 응답의 body
        § Payload

- Stateless
    ○ HTTP의 가장 큰 특징이며, 상태를 가지지 않는다는 뜻
    ○ 통신 과정에서 HTTP가 클라이언트나 서버 상태 확인 안함.
        § 클라이언트에서 발생한 모든 상태를 추적 안함. HTTP는 통신 규약일 뿐, 상태를 저장하지 않기 때문임. 
        § HTTP 대신 쿠키, 세션 API등이 상태 저장(추적)의 역할을 함

- IP주소를 지번, 도로명 주소에 비유하면 Domain name은 해당 주소에 위치한 상호로 비유 가능. 
- 터미널의 nslookup 명령어를 통해 특정 domain name의 IP주소 확인 가능 

- DNS
    ○ 네트워크상의 모든 PC는 IP주소가 있지만, 모든 IP주소가 도메인 이름을 가지는 것은 아님. 
    ○ 도메인 이름을 입력하며 해당 사이트로 이동을 위해 해당 도메인 이름과 매칭된 IP주소를 확인하는 작업이 반드시 필요함. 
    ○ 네트워크에서는 해당 작업을 위한 서버가 별도로 존재하며, 이를 DNS(Domain Name System)이라고 함. 
        § DNS는 호스트의 도메인 이름을 IP주소로 변환, 혹은 반대의 경우를 수행할 수 있도록 개발된 데이터베이스 시스템. 

- IP address(Internet Protocol address): 네트워크에 연결된 특정 PC의 주소를 나타내는 체계

- IPv4
    ○ "." 으로 구분된 네 덩이의 숫자로 구성됨. 
    ○ 2^32인 약 43억개의 주소 표현 가능. 
    ○ Localhost, 127.0.0.1: 현재 사용중인 로컬 PC
    ○ 0.0.0.0, 255.255.255.255: broadcast address, 로컬 네트워크에 접속된 모든 장치와 소통하는 주소임
        § 서버에서 접근가능 IP주소를 broadcast address로 지정하면 모든 기기에서 서버에 접근할 수 있음. 
- IPv6
    ○ IPv4와 표기 방법이 다름
    ○ 2^128개의 주소 표현 가능

- PORT

    ○ "localhost:3000"같은 주소의 :3000이 PORT임. 
    ○ 포트 번호는 0 ~ 65535까지 사용 가능. 
    ○ 0 ~ 1024 번호는 주요 통신을 위한 규약에 따라 이미 정해져 있음.
        § 22: SSH
        § 80: HTTP
        § 443: HTTPS
    ○ :80 이나 :443같은 포트는 URI주소에서 생략 가능. 그러나 잘 알려지지 않은 포트(e.g. 임시포트)는 반드시 주소에 포함시켜야 함. 

- URL은 Uniform Resource Locator
    ○ 네트워크에서 웹페이지, 이미지, 동영상 파일이 위치한 정보를 나타냄. 
- Scheme, hosts, url-path로 구분됨. 
- Scheme: 통신방식을 결정. 일반적인 브라우저에선 http/https 사용.  
- Hosts: 웹 서버의 이름이나 도메인, ip를 하용하며 주소를 나타냄. 
- Url-path: 웹 서버에서 지정한 루트 디렉토리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타냄

- URI는 Uniform Resource Identifier
    ○ 브라우저의 검색창을 클릭하면 나타나는 주소가 URI임. 
    ○ Scheme, hosts, url-path에 더해 query, fragment를 포함. 
    ○ URL을 포함하는 상위개념임.
- Query는 웹 서버에 보내는 추가적인 질문임. 
- Fragment는 일종의 북마크 기능을 수행하며 URL에 fragment(#)와 특정 HTML요소의 id를 전달하면 해당 요소가 있는 곳으로 스크롤을 이동 가능. 

-클라이언트와 서버간 통신에서는, 요청이 있어야 응답이 돌아옴.

- 프로토콜
    ○ 프로토콜은 통신 규약, 즉 약속임. 
        § 같은 일을 하기 위해 다양한 방법이 존재할 수 있으나 특정 방법을 사용하기로 약속한것임.
    ○ 웹 앱 아키텍처에서는 클라이언트/서버가 HTTP라는 프로토콜을 이용하여 대화를 나눔. 
        § HTTP를 이용해 주고받는 메시지는 HTTP 메세지 라고 부름

- API

    ○ 우리는 서버가 어떻게 구성되어 있는지 모르고, 서버의 자원도 확인 불가하다. 
    ○ 서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스를 제공해주며, 이를 API(Application Programming Interface)라고 한다.   
    ○ 보통 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있다. 

- 위 예제처럼 어떠한 프로토콜?명령어를 사용해야 클라이언트가 원하는 자원을 얻을 수 있는지 정해 놓은것이 API임.  

- HTTP API 디자인 잘하는 방법

    ○ 예시: 사용자 관리 API
    ○ HTTP 요청에는 메소드라는 것이 존재함. CRUD 각각의 행동과 일치하는 HTTP 메소드의 종류가 존재함.

- HTTP의 5가지 메소드
    ○ GET, POST, PUT(or PATCH), DELETE 

- 개요
    ○ 앱은 정보를 서버에서 받아옴.
    ○ 서버가 없을 경우 불러와지는 데이터가 내장되어 있기 때문에 위해 끊임없이 앱을 업데이트 해야함.
        § 서버가 없다면 "결제"도 불가. 은행 서버에서 데이터를 받아와야 하기 때문임.
        § 이렇게 상품 정보같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍쳐, 또는 클라이언트-서버 아키텍쳐라고 부름. 
    ○ 클라이언트/서버 아키텍쳐에서는 요청이 선행되고 그 후에 응답이 옴. 
    ○ 서버는 리소스를 전달해주는 역할만 담당. 
    ○ 리소스를 저장하는 공간은 데이터베이스라고 부름. (서버실? 같은건가)
    ○ 클라이언트, 서버, 데이터베이스가 모두 포함된 아키텍쳐를 3티어 아키텍쳐라고 부름


- 클라이언트의 종류
    ○ 웹 플랫폼에서의 클라이언트는 웹사이트 혹은 웹 앱
    ○ IOS/ 안드로이드와 같은 스마트폰/태블릿 플랫폼, 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있음. 

- 서버의 종류
    ○ 파일 서버: 파일을 제공하는 앱
    ○ 웹 서버: 웹사이트에서 필요로 하는 정보들을 제공하는 앱
    ○ 메일 서버: 메일을 주고받을 수 있도록 도와주는 앱
    ○ 데이터베이스: 데이터 제공자로서 일하므로 일종의 서버라고 볼 수 있음 (분류되는 개념이 아니었던가…?)

로컬 git 설정에 등록된 이메일 혹은 사용자 이름이 다르면 커밋이 잔디에 반영이 되지 않는다고 한다. *두 개를 일치시켜 주면 정상적으로 반영된다고 한다. 터미널에서 본인의 깃허브 계정 정보와 일치하는지 확인해 보자. *

git config --global user.email // 이메일 확인
git config --global user.name //사용자 이름 확인

git config user.email // 개별 프로젝트의 이메일 확인
git config user.name  // 개별 프로젝트의 사용자 이름 확인

만약 두개가 다르다면 아래 명령어로 터미널에서 바꿔주면 된다.

✨PC의 모든 이메일과 사용자 이름을 바꾸고 싶은 경우✨
git config --global user.email "이메일"
git config --global user.name  "사용자 이름" 


✨개별 프로젝트의 이메일과 사용자 이름을 바꾸고 싶은 경우✨
git config user.email "이메일"
git config user.name  "사용자 이름" 

🍋2. 레포지토리의 default 혹은 gh-pages 이외의 branch에 푸쉬함

디폴트 branch나 gh-pages 이외의 branch에 푸쉬를 하면 커밋이 잔디에 반영되지 않는다고 한다.

*이 경우 레포지토리의 settings에 들어가서 디폴트 branch를 바꿔주면 된다. pull request를 통해 커밋을 메인 브랜치에 반영 시키는 방법도 있다. *

(gh-pages가 뭔지는 사용해보지 않아서 잘 모르겠지만 프로젝트 사이트가 있는 레포지토리?라고 한다.)

🍋3. 커밋이 24시간 이내에 발생했을 경우

분명 올바르게 커밋을 했는데 잔디가 심어져 있지 않은 경우, 커밋이 깃허브 잔디에 반영되기 까지 최대 24시간 소요 될 수 있다고 한다. 나는 과제를 제외한 커밋의 경우 긴 시간을 기다리지 않아도 즉각적으로 반영이 되어 있었다.

나는 위 세가지 경우 모두 해당이 되지 않았지만 과제를 할때 레포지토리를 fork해서 새 레포지토리를 생성 할때 빼고는 깃허브 잔디에 commit이 전혀 업데이트 되지 않았다. 잔디가 심어지지 않는다고 해서 과제를 못하는 건 아니지만 내가 공부에 투자한 시간 대비 초록초록한 잔디를 못심으니까 괜히 아쉬운 느낌이 들었다. 조금 더 알아보니 내 경우는 4번 이었다.

🍋4. fork해온 레포지토리에 커밋할 경우

나는 초기 틀이 짜여진 코드를 fork 해서 업데이트 하는 방식으로 과제를 하는데, 남의 레포지토리에서 fork해온 레포지토리에는 아무리 commit을 해도 잔디가 심어지지 않는다고 한다.

해결책은 *새로운 레포지토리를 생성 후 그곳에 push 해 주면 깃허브 잔디에 반영이 된다. *

출처: Github Docs

아래 이미지 처럼 클래스에는 프로토타입이 있다고 했다. 프로토타입은 클래스의 메소드와 속성을 담고 있다.

이 이미지에서 lemon은 클래스 Fruit의 인스턴스인데, Fruit의 프로토타입에 접근하려면 lemon.__proto__를 써서 알 수 있다.

상속되는 클래스의 예시를 들어보자.

부모클래스 --> 자식클래스 --> 자식의자식클래스 --> 응애클래스

응애클래스._proto_.constructor = 자식의자식클래스 응애클래스._proto_._proto_.constructor = 자식클래스 응애클래스._proto_._proto_._proto_.constructor = 부모클래스 응애클래스._proto_._proto_._proto_._proto_.constructor = Object

_proto_.constructor로 계속 타고 올라가다 보면 Object라는 클래스가 나옴. Object는 모든 클래스들의 조상임.

이렇게 상속되는 클래스의 메소드와 속성은 상위 클래스에서 부터 내려오는데 올라가는데 이를 프로토타입 체인이라고 함.

프로토타입은 클래스의 "원형객체" 이다. 원형 객체라는 말이 좀 헷갈리는데 클래스 안에 원형객체(프로토타입)이 있고, 원형객체(프로토타입) 안에는 클래스의 속성과 메소드가 정의되어있다.

class Fruit {
  constructor(color, taste, shape) {
    this.color = color;
    this.taste = taste;
    this.shape = shape;
  }
  squeeze(){
    return `You've squeezed ${this.color}, ${this.taste} juice.`
  }
}

const lemon = new Fruit('yellow', 'sour', 'oval');
lemon.squeeze();//prints "You've squeezed yellow, sour juice."

위 코드에서 클래스, 프로토타입, 인스턴스의 관계는 아래 그림과 같다.

객체지향 프로그래밍이 등장하기 이전에는 절차지향 프로그래밍라는 컨셉이 있었다. 이는 모든 데이터와 데이터의 프로세싱 과정을 단계별로 작성하는 것을 말한다. 단계간 이동은 고작 함수로 접근하는 것 밖에 없었다.

그러나 객체지향 프로그래밍에서는 데이터와 데이터의 프로세싱(기능)을 한꺼번에 묶어서 처리할 수 있다. 데이터와 기능은 객체로 묶이며, 메모리상에서 반환되기 전까지 객체 내의 모든 것이 유지된다.

메소드와 속성이 클래스라는 큰 틀로 감싸지는 것을 상상해 보면 이해가 쉽다.

2. 객체지향 프로그래밍의 4가지 특성

객체지향 프로그래밍에는 캡슐화, 추상화, 상속, 다향성 이라는 4가지 특성이 있다. 각 특성이 무엇을 의미하는지 차례대로 알아보겠다.

2-1. 캡슐화

캡슐화는 절차지향 프로그래밍에서 처럼 데이터와 기능을 코드 내 따로 정의하지 않고 한꺼번에 묶어서 클래스에 넣는 것이다. 각 객체별로 필요한 기능과 데이터가 모두 다른데, 이를 결합 시키는 것이다. 캡슐화는 "은닉화"라는 부차적인 특성도 포함하고 있는데, 이는 데이터나 기능의 구현이 외부로 노출되지 않게 하는 것이다.

2-2. 추상화

추상화는 캡슐화의 "은닉화"와 겹치는 부분이 약간 있는데, 객체 내부에는 복잡한 데이터와 기능의 구현이 있을지라도, 외부에서 보았을 때 노출되는 부분은 간단하게 만든다는 개념이다. 그래야 객체를 사용하기 쉬워진다. 은닉화와 다른 점은 은닉화는 객체 안의 데이터와 데이터의 구현을 숨기는데 중심을 맞춘다면, 추상화는 객체를 사용하기 쉽게 단순화 한다는 데에 의의를 둔다.

2-3. 상속

상속은 부모 클래스가 가지는 특성을 부모 클래스에서 파생된 자식 클래스도 갖는다는 의미이다. 자식 클래스는 부모 클래스가 가지는 속성과 메소드를 모두 가지고 있으며, 이에 더하여 추가적인 속성과 메소드를 갖는다.

2-4. 다향성

다향성은 같은 이름의 메소드일지라도 객체의 종류와 그 목적에 맞춰서 조금씩 다르게 작동하는 것을 의미한다. 예를들어 식물에 물을 주는 메소드, water()가 있다고 상상해 보자. 그리고 식물 클래스의 자식 클래스인 방울토마토와 선인장 클래스가 있다고 상상해 보자. 방울토마토를 키울때는 3일에 한번, 선인장을 키울때는 30일에 한번 물을 줘야 한다고 가정하자. 이 경우 water()메소드는 방울토마토이냐, 선인장이냐 여부에 따라 다르게 작동한다.