47 |
48 | ### 6. 도메인 등록 완료
49 |
50 | 아래와 같은 창이 표시되면 등록이 완료됩니다!
51 |
52 |
53 |
54 |
55 |
56 | ## IP 주소 등록 (A record)
57 |
58 | ### 1. TECH domain 홈페이지
59 |
60 | [TECH domain 홈페이지](https://get.tech)로 이동해서 Account를 클릭하세요. 로그인되어있지 않다면 로그인도 진행해주세요.
61 |
62 |
63 |
64 |
65 |
66 | ### 2. Account 페이지
67 |
68 | Jump to Domain 칸에 본인의 도메인을 입력해주세요.
69 |
70 |
71 |
72 |
73 |
74 | ### 3. 도메인 관리 페이지
75 |
76 | 도메인 관리 페이지에서 아래로 스크롤하여 DNS 관리 페이지로 이동합니다. 'Manage DNS'를 클릭하세요.
77 |
78 |
79 |
80 |
81 |
82 | ### 4. DNS 관리 페이지
83 |
84 | DNS record들을 확인할 수 있습니다. (예: \.dotoleeoak.tech) A record는 IPv4 주소를 등록할 수 있는 record입니다. 'Add A record'를 클릭하세요.
85 |
86 |
87 |
88 |
89 |
90 | ### 5. A record 등록
91 |
92 | Root 도메인(\.tech)을 등록하기 위해 Host Name은 빈 칸으로 둡니다. Destination에 원하는 IP 주소(Elastic IP 등)를 등록하고, 'Add Record'를 누르세요.
93 |
94 |
95 |
96 |
97 |
98 | ### 6. 동작 확인
99 |
100 | 도메인이 잘 동작하는지 확인합니다.
101 |
102 |
103 |
104 |
105 |
--------------------------------------------------------------------------------
/content/docs/backend/8. GraphQL.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "8. GraphQL"
3 | description = "REST API의 단점을 보완하고자 등장한 GraphQL에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2023-09-08"
7 | weight = 180
8 | +++
9 |
10 | 마지막 시간에는 API를 위한 새로운 쿼리 언어인 **GraphQL**에 대해 알아봅시다!
11 | > 양이 조금 많을수도 있어요 😂
12 |
13 | ## 공부할 내용 📚
14 |
15 | ### 1. GraphQL이 무엇일까요?
16 |
17 | GraphQL은 **'API를 위한 쿼리 언어'**라는 이름과 같이, 기존의 REST API를 대체할 수 있는 새로운 쿼리 언어입니다.
18 |
19 | 지금까지 REST API에 적응하고 있었는데.. GraphQL이라는 새로운 언어를 도대체 왜 배워야할까요?
20 |
21 | GraphQL이 무엇인지, 그리고 그 장단점에 대해서 알아봅시다.
22 |
23 | - **GraphQL 개념**
24 | - [GraphQL 개념잡기](https://tech.kakao.com/2019/08/01/graphql-basic/): GraphQL의 개념에 대해서 잘 설명한 블로그입니다.
25 | - [GrpahQL 소개](https://graphql-kr.github.io/learn/): 공식 홈페이지의 '소개' 부분입니다. 짧으니 주의하기!
26 | - **GraphQL 장단점**
27 | - [GraphQL vs REST](https://www.prisma.io/docs/concepts/overview/prisma-in-your-stack/is-prisma-an-orm): GraphQL과 REST API가 어떻게 다른지 설명합니다.(영어 주의)
28 | - [GraphQL 도입시 주의할 점](https://yozm.wishket.com/magazine/detail/2113/): 장단점에 어떨때 도입하면 좋을지 설명합니다.
29 | - [GraphQL 단점과 대안](https://www.bangseongbeom.com/graphql-downsides-alternatives.html)
30 | - **GraphQL 실사용 예제**
31 | - [Naver Deview 2023 'GraphQL 잘 쓰고 계신가요?'](https://www.youtube.com/watch?v=9G2vT4C4sAY): 네이버 MY플레이스에서 어떻게 GraphQL을 사용하고 있는지, 왜 선택했는지에 대해서 설명한 Deview 영상입니다.
32 | - [Naver Deview 2020 'GraphQL API 까짓것 운영해보지 뭐'](https://deview.kr/2020/sessions/347): 이번에는 GraphQL의 기본 개념, 그리고 어떻게 운영하는지에 초점을 맞춰 소개합니다.
33 | - [Naver Deview 2021 'Domain Graph Service를 활용한 광고 서비스의 GraphQL API 구현 사례'](https://tv.naver.com/v/23652389): 여기에서는 Spring Boot를 사용하는 백엔드 개발자의 관점에서 GpraphQL를 도입한 사례를 소개합니다. 프레임워크는 다르지만, 느낌 점 위주로 보시면 얻어가는 점이 있을거에요.
34 | - 참고로, GraphQL Conf도 매년 열린답니당!
35 | + [얄팍한 GraphQL과 Apollo(인프런)](https://www.inflearn.com/course/얄팍한-graphql-apollo#curriculum): GraphQL에 대해서 소개하는 무료 인프런강의입니다. 잘 이해가 되지 않으신다면 보시는 걸 추천해요!
36 |
37 | ### 2. Nestjs & GraphQL
38 |
39 | 이제 GraphQL의 개념에 대해서는 이해가 조금 되시나요?
40 |
41 | 그런데... Nestjs에서는 어떻게 이러한 GraphQL을 구현할까요...? 더 자세히 알아봅시다!
42 |
43 | - 어떻게 구현하는지 살펴보기 이전에, GraphQL 사용법에 대해서 더 자세히 알아봐요!
44 | - [쿼리 & 뮤테이션](https://graphql-kr.github.io/learn/queries/): 여기에서는 GraphQL 서버에 쿼리하는 방법에 대해 살펴봐요.
45 | - [스키마 & 타입](https://graphql-kr.github.io/learn/schema/): 여기에서는 GraphQL 타입 시스템과 데이터를 표현하는 방법에 대해 살펴봐요. 이때, 여기에서는 세부적인 구현이 아니라 개념에 대해서만 얘기하는 점, 참고하세요!
46 | - Nestjs에서 어떻게 GpraphQL을 사용해 디자인할 수 있는지 살펴봐요.
47 | - [Code first vs Schema first](https://velog.io/@zoeyul/Graphql-code-first-vs-schema-first): GraphQL을 사용하는 방법은 크게 두 가지가 있습니다. 두 방식의 개념 및 차이점에 대해 알아봅시다.
48 | - 코드당 프로젝트에서는 현재 Code first의 방식을 사용하고 있습니다. 😆
49 | - [공식 Nestjs & GraphQL](https://docs.nestjs.com/graphql/quick-start): Nestjs에서 어떻게 GraphQL을 사용하는지 소개합니다.
50 | - Nestjs docs에 GraphQL 챕터가 많은데요, **Quick Start** 부분만 확인해주세요!
51 |
52 | ## 프로젝트 실습 🎈
53 |
54 | 이번 주차는 저번 주차에서 만들었던 REST API 기반의 Nest.js 웹서버를 GraphQL 기반 웹서버로 옮기는 것입니다. 😇
55 |
56 | 이때, **Code First** approach를 사용해서 진행해주세요! 😍
57 |
58 | - Nestjs **Quick Start** 부분을 참고해서 진행하시면 쉬울거에요!
59 | - 만약 어떻게 하실지 막막하시다면 [Nestjs Graphql Code first example](https://github.com/nestjs/nest/tree/master/sample/23-graphql-code-first)의 코드 예제를 참고해주세요!
--------------------------------------------------------------------------------
/content/docs/frontend/6. Data Fetching.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "6. REST API & GraphQL"
3 | description = "REST API와 GraphQL을 이용해 외부 데이터를 받아봅니다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 260
8 | +++
9 |
10 | {{< figure src="../images/web.png" alt="메인 페이지" >}}
11 |
12 | 지금까지는 포켓몬 데이터를 코드 또는 로컬 파일에서 가져왔어요. 이번 시간에는 외부에서 데이터를 가져오는 방법에 대해 알아보아요!
13 |
14 | 여러분의 공부를 돕기 위해 준비한 자료들이에요. 따라서 꼭 준비된 자료만 공부할 필요는 없어요! 자신만의 방식으로 공부하고 과제만 잘 수행하면 돼요! 😄
15 |
16 | ## 📚 공부할 내용
17 |
18 | - Background
19 | - [HTTP 메소드 총정리](https://inpa.tistory.com/entry/WEB-%F0%9F%8C%90-HTTP-%EB%A9%94%EC%84%9C%EB%93%9C-%EC%A2%85%EB%A5%98-%ED%86%B5%EC%8B%A0-%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC)
20 | - 주요 메소드 위주로 공부해 주세요!
21 | - [자바스크립트 비동기, Promise, async, await 맛보기](https://springfall.cc/article/2022-11/easy-promise-async-await)
22 | - [자바스크립트 Promise, async/await](https://javascript.info/async)
23 |
24 |
25 | - REST API
26 | - [REST API가 뭔가요? - 얄팍한 코딩사전](https://www.youtube.com/watch?v=iOueE9AXDQQ&ab_channel=%EC%96%84%ED%8C%8D%ED%95%9C%EC%BD%94%EB%94%A9%EC%82%AC%EC%A0%84)
27 | - Axios
28 | - HTTP 요청을 보내는 라이브러리에요.
29 | - [Axios 총정리](https://inpa.tistory.com/entry/AXIOS-%F0%9F%93%9A-%EC%84%A4%EC%B9%98-%EC%82%AC%EC%9A%A9)
30 | - [React에서 axios 사용하기](https://www.youtube.com/watch?v=9-OrcyggmKQ&ab_channel=%EC%BD%94%EC%A7%80%EC%BD%94%EB%8D%94KossieCoder)
31 | - [Axios 공식 문서](https://axios-http.com/kr/docs/intro)
32 | - GraphQL
33 | - [GraphQL이 뭔가요? - 얄팍한 코딩사전](https://www.youtube.com/watch?v=EkWI6Ru8lFQ&ab_channel=%EC%96%84%ED%8C%8D%ED%95%9C%EC%BD%94%EB%94%A9%EC%82%AC%EC%A0%84)
34 | - [Apollo client 공식 문서](https://www.apollographql.com/docs/react/)
35 | - Introduction, Get started, Queries 부분을 읽어보세요!
36 | - 즉 ApolloClient 초기 설정을 하고 useQuery를 사용해서 데이터를 가져오는 방법을 익히면 됩니다!
37 |
38 | axios는 [XMLHttpRequest](https://ko.javascript.info/xmlhttprequest)를 기반으로 만들어진 라이브러리에요. 더 최신 기술인 fetch API를 사용해보고 싶다면 [여기](https://ko.javascript.info/fetch)를 참고해주세요! 보통 호환성 문제와 사용하기 편하다는 이유로 아직 axios를 많이 사용하지만 stream과 같은 기능(chatgpt처럼 계속 데이터를 받아오는 기능)은 XMLHttpRequest로는 구현할 수 없기 때문에 fetch API 또한 나중에 공부해 보는 것을 추천해요!
39 |
40 | > 나중에 nextjs를 배우면서 더 확장된 기능을 가진 fetch API를 사용할 거니 미리 공부해 두면 좋아요!
41 |
42 | ## 프로젝트 실습 🎈
43 |
44 | 1. 메인페이지에 있는 포켓몬 리스트를 REST API를 통해 가져와 보아요.
45 | 1. [PokeAPI v2](https://pokeapi.co/docs/v2)를 통해 필요한 API를 찾아보아요.
46 | 2. 이를 통해 REST API 문서를 읽는 법을 배워보고 Axios 또는 Fetch API를 사용해서 HTTP 요청을 보내 보아요.
47 | 2. 포켓몬 디테일 페이지에서 필요한 포켓몬 정보는 GraphQL을 통해 가져와 보아요.
48 | 1. [PokeAPI GraphQL Playground](https://beta.pokeapi.co/graphql/console)를 통해 쿼리를 유추해 보아요.
49 | 2. 만약에 REST API로 구현 했으면 어떠한 상황이 발생했을 지 생각해보고 GraphQL의 장점을 느껴보아요.
50 |
51 | ### 프로젝트 실습 Tip 📌
52 |
53 | 1. 무료 API라서 너무 많은 요청을 보내면 IP 영구 밴을 당할 수 있기 때문에 렌더링 될 때마다 요청이 되지 않게 cache 기능을 사용하거나 useEffect를 잘 활용해보아요!
54 | 2. Compoenent와 Effect는 pure하게 만드는 것이 권장돼요! React 18에서는 이를 더 잘 지킬 수 있도록 Strict mode(개발 환경에서는 기본적으로 strict mode가 활성화 되어 있음)에서는 두 번 렌더링해서 이 성질을 잘 지키고 있는지 확인해요! 따라서 useEffect 안에 있는 코드가 두 번 실행되는 것은 정상이니 걱정하지 마세요!
55 | 3. `GraphQL: Language Feature Support`, `GraphQL: Syntax Highlighting` vscode extension을 설치하면 syntax highlighting과 auto complete등의 편리한 기능을 사용할 수 있어요!
56 |
--------------------------------------------------------------------------------
/content/docs/plan/1. Domain.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "1. Domain"
3 | description = "'Codedang', 뭐 하는 사이트인가요?"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 410
8 | +++
9 |
10 | ## **🎯이번 주 학습 목표🎯**
11 |
12 | ✅SKKUDING의 메인 프로젝트, CODEDANG의 도메인 알아보기
13 | ✅온라인 저지 시스템의 원리에 대해 이해하기
14 |
15 | 💫 **Keyword**: 도메인, 도메인 지식, 온라인 저지
16 |
17 | ---
18 |
19 | ## 도메인(Domain)
20 | > 공간(영역)이라는 이름을 갖고 여러 분야에서 사용되는 용어
21 |
22 | 보통 인터넷 프로토콜 주소(IP)를 사람들이 기억하기 쉽게 만든 이름을 의미하지만,
23 | 여기서는 '서비스가 가진 영역', 즉 **서비스가 속한 분야** 또는 **서비스가 다루는 문제 영역**을 말합니다.
24 |
25 | 도메인에 대한 이해도를 **도메인 지식(Domain Knowledge)** 이라고 하는데요.
26 | 이 도메인 지식을 갖추면 CODEDANG이 제공하고자 하는 서비스를 잘 이해할 수 있어요. 뿐만 아니라, 사용자의 니즈와 페인포인트를 파악해 CODEDANG을 더 좋은 프로젝트로 발전시키는 데 큰 도움이 된답니다. 따라서 기획자에게는 가장 필수적인 역량 중 하나예요!🧐
27 |
28 | ---
29 |
30 | ### ‘CODEDANG’의 도메인 💻
31 |
32 | CODEDANG(코드당)은 **성균관대학교만의 온라인 저지(Online Judge)** 서비스예요!
33 | 코드당은 최종적으로 “**입학부터 졸업까지 성균관대학교 학생들의 성장 여정을 함께 하는 온라인 저지 서비스**”로 성장하고자 해요.
34 | 따라서 성균관대학교 학생들이 프로그래밍 실력을 꾸준히 향상시킬 수 있도록, 학습 성장의 과정을 지속적으로 돕는 것을 핵심 목표로 하고 있답니다.
35 |
36 | 코드당을 현재 사용하고 있는 사용자들은 아래와 같은 특징을 가지고 있어요!
37 |
38 |
39 | ## 온라인 저지(Online Judge) 시스템이란?
40 |
41 | ‘온라인 저지’는 온라인에서 프로그래밍 문제를 풀고 채점을 받을 수 있는 시스템을 의미해요.
42 | 여기 온라인 저지 시스템의 동작 과정을 정리해봤어요:
43 |
44 | 1️⃣사용자가 서비스의 화면에서 문제를 확인해요.
45 | 2️⃣자신이 작성한 코드(답)을 제출해요.
46 | 3️⃣컴퓨터는 제출된 코드를 컴퓨터가 이해할 수 있도록 0, 1을 사용해 번역해요(이 과정을 컴파일이라고 해요!).
47 | 4️⃣**테스트케이스**를 적용해 제출된 코드를 실행해요.
48 | 5️⃣테스트케이스의 결과 값과 코드에서 실제로 출력된 결과 값을 비교해 정답 여부를 판단해요.
49 | 6️⃣사용자에게 서비스 화면을 통해 채점 결과를 출력해요.
50 |
51 | (아래 그림을 보면 더 이해가 빠를 거예요!)
52 |
53 |
54 | 테스트케이스란?
55 | 코드의 정답 여부를 판별하기 위해 사용하는 입출력 데이터 세트를 의미해요!
56 |
57 | 온라인 저지는 **알고리즘 경연대회**, **프로그래밍 강의** 등 여러 곳에서 활용될 수 있어요.
58 | 코드당도 온라인 저지를 활용해서 프로그래밍 실력 향상을 위한 여러 가지 기능들을 지원할 수 있도록 노력하고 있어요! 🙂
59 |
60 | **직접 온라인 저지를 사용해 보면서 이해해 볼까요? 🤗**
61 | [유사 레퍼런스 사이트](https://www.notion.so/768071ee3e5742edbb505c56392ec623?pvs=21) 👉 노션 SKKUDING > 기획 페이지에 ‘유사 레퍼런스 사이트’를 모아 두었어요!
62 |
63 | [도메인 지식 확보 방법](https://www.instagram.com/p/DDAAnavyr38/?igsh=MWpvM2x5anZhcjc3cA%3D%3D) 👉 도메인 지식을 얻기 위한 학습 방법에 대해 설명하고 있는 카드뉴스예요.
64 | 레퍼런스 사이트를 직접 사용해 보면서, 이러한 학습 방법을 적용해 본다면 더 논리적으로 분석할 수 있을 거예요!
65 |
66 | [브랜드 핵심경험의 정의](https://brunch.co.kr/@likenoothers/38) 👉 '도메인'을 어떻게 활용해야 할지 생각해보고 싶다면 참고해 보아요. '도메인'과 '브랜드'는 접근 방법상 차이가 있지만, 둘 다 유저의 핵심 경험을 중심으로 서비스의 정체성을 발전시키는 데 필요해요. 서비스 기획 단계에서 유저 핵심 경험을 어떻게 활용했는지 살펴봐요!
67 |
68 | ---
69 |
70 | ## **✏️ 과제 안내**
71 |
72 | 1주차에는 코드당이 아닌, 다른 온라인 저지 사이트를 이용하고, 리뷰해 보는 시간을 가져 보아요 😎
73 |
74 | TIP: 어떻게 리뷰해야 할지 잘 모르겠다면, 온라인 저지 사이트를 필요로 하는 유저가 되어 보아요! 유저에 대한 기본 정보, 이 사이트를 사용하게 된 맥락과 니즈에 대해 생각해보면서 접근해요. 사이트에 있는 문제의 정답을 맞추는 것보다는 전체적인 흐름과 사용성에 집중해주세요!
75 |
76 | 리뷰는 아래와 같은 내용이 포함되면 좋아요.
77 |
78 | - 서비스의 목표 (상업적 사이트라면, 비즈니스 목표 포함)
79 | - 서비스가 해결하고자 하는 문제
80 | - 문제를 해결하기 위한 핵심 기능
81 | - 편리하다고 느꼈던 경험
82 | - 불편하다고 느꼈던 경험
83 | - 다른 사용자의 리뷰 (실제 후기)
84 |
85 | 최대한 많은 사이트를 경험해 보는 것이 좋아요. ‘유사 레퍼런스 사이트’에 없는 사이트라도 여러분이 직접 찾은 온라인 저지 사이트가 있다면 이용해 보고, 사용 경험을 공유해 주세요 👀
86 |
--------------------------------------------------------------------------------
/layouts/partials/head.html:
--------------------------------------------------------------------------------
1 |
2 |
3 | {{- .Site.Title }}
4 | {{- if not hugo.IsProduction }}
5 |
6 | {{- end }}
7 |
8 |
9 |
10 |
11 |
12 |
13 |
14 |
15 | {{ block "head/favicon" . }}{{ partialCached "head/favicon.html" . }}{{ end }}
16 |
17 | {{- partial "google-fonts" . }}
18 |
19 | {{ template "_internal/opengraph.html" . }}
20 |
21 | {{- $options := dict "enableSourceMap" true }}
22 | {{- if hugo.IsProduction}}
23 | {{- $options := dict "enableSourceMap" false "outputStyle" "compressed" }}
24 | {{- end }}
25 | {{- $style := resources.Get "/scss/style.scss" }}
26 | {{- $style = $style | resources.ExecuteAsTemplate "/scss/style.scss" . | css.Sass $options }}
27 | {{- if hugo.IsProduction }}
28 | {{- $style = $style | minify | fingerprint "sha384" }}
29 | {{- end -}}
30 |
31 |
32 | {{ $js := resources.Get "js/bootstrap.js" }}
33 | {{ $params := dict }}
34 | {{ $sourceMap := cond hugo.IsProduction "" "inline" }}
35 | {{ $opts := dict "sourceMap" $sourceMap "minify" hugo.IsProduction "target" "es2018" "params" $params }}
36 | {{ $js = $js | js.Build $opts }}
37 | {{ if hugo.IsProduction }}
38 | {{ $js = $js | fingerprint "sha384" }}
39 | {{ end }}
40 |
41 |
42 | {{ if ($.Scratch.Get "image_compare_enabled") }}
43 | {{ $imagecompare := resources.Get "js/image-compare-viewer.min.js" }}
44 | {{- if not hugo.IsServer }}
45 | {{- $js := (slice $imagecompare) | resources.Concat "/js/image-compare.js" | minify | fingerprint "sha384" }}
46 |
47 | {{- else }}
48 | {{- $js := (slice $imagecompare) | resources.Concat "/js/image-compare.js" }}
49 |
50 | {{- end }}
51 | {{- end }}
52 |
53 | {{- if not hugo.IsServer }}
54 | {{ if and (.Site.Params.plausible.scriptURL) (.Site.Params.plausible.dataDomain) -}}
55 | {{- partialCached "head/plausible" . }}
56 | {{- end -}}
57 | {{- end -}}
58 |
59 | {{- if not hugo.IsServer }}
60 | {{- if .Site.Config.Services.GoogleAnalytics.ID }}
61 | {{- template "_internal/google_analytics.html" . -}}
62 | {{- end -}}
63 | {{- end -}}
64 |
65 |
--------------------------------------------------------------------------------
/.gitignore:
--------------------------------------------------------------------------------
1 | # Created by https://www.toptal.com/developers/gitignore/api/node
2 | # Edit at https://www.toptal.com/developers/gitignore?templates=node
3 |
4 | ### Node ###
5 | # Logs
6 | logs
7 | *.log
8 | npm-debug.log*
9 | yarn-debug.log*
10 | yarn-error.log*
11 | lerna-debug.log*
12 | .pnpm-debug.log*
13 |
14 | # Diagnostic reports (https://nodejs.org/api/report.html)
15 | report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
16 |
17 | # Runtime data
18 | pids
19 | *.pid
20 | *.seed
21 | *.pid.lock
22 |
23 | # Directory for instrumented libs generated by jscoverage/JSCover
24 | lib-cov
25 |
26 | # Coverage directory used by tools like istanbul
27 | coverage
28 | *.lcov
29 |
30 | # nyc test coverage
31 | .nyc_output
32 |
33 | # Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
34 | .grunt
35 |
36 | # Bower dependency directory (https://bower.io/)
37 | bower_components
38 |
39 | # node-waf configuration
40 | .lock-wscript
41 |
42 | # Compiled binary addons (https://nodejs.org/api/addons.html)
43 | build/Release
44 |
45 | # Dependency directories
46 | node_modules/
47 | jspm_packages/
48 |
49 | # Snowpack dependency directory (https://snowpack.dev/)
50 | web_modules/
51 |
52 | # TypeScript cache
53 | *.tsbuildinfo
54 |
55 | # Optional npm cache directory
56 | .npm
57 |
58 | # Optional eslint cache
59 | .eslintcache
60 |
61 | # Optional stylelint cache
62 | .stylelintcache
63 |
64 | # Microbundle cache
65 | .rpt2_cache/
66 | .rts2_cache_cjs/
67 | .rts2_cache_es/
68 | .rts2_cache_umd/
69 |
70 | # Optional REPL history
71 | .node_repl_history
72 |
73 | # Output of 'npm pack'
74 | *.tgz
75 |
76 | # Yarn Integrity file
77 | .yarn-integrity
78 |
79 | # dotenv environment variable files
80 | .env
81 | .env.development.local
82 | .env.test.local
83 | .env.production.local
84 | .env.local
85 |
86 | # parcel-bundler cache (https://parceljs.org/)
87 | .cache
88 | .parcel-cache
89 |
90 | # Next.js build output
91 | .next
92 | out
93 |
94 | # Nuxt.js build / generate output
95 | .nuxt
96 | dist
97 |
98 | # Gatsby files
99 | .cache/
100 | # Comment in the public line in if your project uses Gatsby and not Next.js
101 | # https://nextjs.org/blog/next-9-1#public-directory-support
102 | # public
103 |
104 | # vuepress build output
105 | .vuepress/dist
106 |
107 | # vuepress v2.x temp and cache directory
108 | .temp
109 |
110 | # Docusaurus cache and generated files
111 | .docusaurus
112 |
113 | # Serverless directories
114 | .serverless/
115 |
116 | # FuseBox cache
117 | .fusebox/
118 |
119 | # DynamoDB Local files
120 | .dynamodb/
121 |
122 | # TernJS port file
123 | .tern-port
124 |
125 | # Stores VSCode versions used for testing VSCode extensions
126 | .vscode-test
127 |
128 | # yarn v2
129 | .yarn/cache
130 | .yarn/unplugged
131 | .yarn/build-state.yml
132 | .yarn/install-state.gz
133 | .pnp.*
134 |
135 | ### Node Patch ###
136 | # Serverless Webpack directories
137 | .webpack/
138 |
139 | # Optional stylelint cache
140 |
141 | # SvelteKit build / generate output
142 | .svelte-kit
143 |
144 | # End of https://www.toptal.com/developers/gitignore/api/node
145 |
146 | ### Hugo ###
147 | # Generated files by hugo
148 | /public/
149 | /resources/_gen/
150 | /assets/jsconfig.json
151 | hugo_stats.json
152 |
153 | # Executable may be added to repository
154 | hugo.exe
155 | hugo.darwin
156 | hugo.linux
157 |
158 | # Temporary lock file while building
159 | /.hugo_build.lock
160 |
161 | # Mac OS
162 | .DS_Store
163 |
--------------------------------------------------------------------------------
/content/docs/backend/1. Network.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "1. Network"
3 | description = "기본적인 네트워크 이론을 공부합니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2025-03-24"
7 | weight = 110
8 | +++
9 |
10 | 백엔드의 주요 업무는 DB에 있는 정보들을 프론트엔드에서 활용할 수 있도록 요청에 맞게 알맞은 응답을 보내주는 것입니다.
11 |
12 | 이러한 '요청'은 자유롭게 오는 것이 아닌, 일정한 규칙을 통해 전송됩니다. 그리고 요청에 따른 '응답'도 정해진 규칙을 지켜 전송해야 합니다.
13 |
14 | 물론 코드를 작성하는 것도 중요하지만, 이러한 기본적인 개념들을 먼저 알고 있어야지 더욱 효율적으로 개발을 진행할 수 있습니다.
15 |
16 | 그래서 이번 시간에는 이러한 **규칙**들에 대해 공부해보려고 합니다.
17 |
18 | **아래의 모든 자료는 참고 자료일 뿐이고, 자유롭게 검색해서 공부하셔도 됩니다! 😎**
19 |
20 | **이미 알고 있는 내용이라면 복습겸 정리하셔도 되고, 아니면 평소 궁금했던 부분을 찾아 다른 분들에게 소개하는 느낌으로 정리해주셔도 괜찮습니다.**
21 |
22 | ## 공부할 내용 📚
23 |
24 | ### 1. HTTP
25 |
26 | HTTP는 텍스트 기반의 통신 규약으로 인터넷에서 정보를 주고받을 수 있는 프로토콜입니다. 이러한 규칙을 통해 우리는 서로 소통하며 정보를 주고 받을 수 있습니다.
27 |
28 | - **[HTTP 개요](https://developer.mozilla.org/ko/docs/Web/HTTP/Overview)**: HTTP에 대해서 간단히 정리한 글입니다. 어떤 흐름으로 통신이 오고가는지, 어떠한 메세지를 통해 통신하는지 읽어보시면 좋을 듯합니다.
29 |
30 | - **[HTTP 헤더](https://developer.mozilla.org/ko/docs/Web/HTTP/Headers)**: HTTP의 헤더는 요청 및 응답을 보낼 때 부가적인 정보를 담아두는 부분입니다. 헤더를 통해 우리는 어떤 타입의 정보를 보낼 것인지, 어떤 인증을 사용하는지, 어디에서 보내는지 등등의 정보를 알 수 있습니다. 양이 많아서 대충 보면서 이런 부분도 있구나~ 정도로만 읽어주세요!
31 |
32 | - **[HTTP 요청 메소드](https://developer.mozilla.org/ko/docs/Web/HTTP/Methods)**: HTTP는 요청 메서드를 정의하여, 주어진 리소스에 수행하길 원하는 행동을 나타냅니다. GET, PUT, POST, DELETE는 많이 들어보셨을 것이지만, 이외에도 HEAD, OPTIONS 등 다양한 메서드가 존재합니다. 이 기회를 통해 각각의 메서드의 개념 및 특징에 대해 다시 살펴보면 어떨까요?
33 |
34 | - **[HTTP 상태 코드](https://developer.mozilla.org/ko/docs/Web/HTTP/Status)**: HTTP 응답 상태 코드는 특정 HTTP 요청이 성공적으로 완료되었는지 알려줍니다. 404, 400 많이 보셨죠? 사실, 상태코드는 이것말고도 다양한 코드들이 존재합니다. 이런 상태코드들을 잘 활용하면 구구절절 에러 내용을 적을 필요없이 코드만으로도 에러 내용을 유추할 수 있도록 할 수 있습니다.
35 |
36 | ### 2. DNS, Domain Name, Hosting
37 |
38 | 우리는 어떻게 https://codedang.com 을 주소창에 치자마자 코드당 홈페이지로 들어갈 수 있을까요? 어떻게 웹을 접속할 수 있는지 DNS, Domain Name, Hosting의 개념에 대해 짧게 살펴봅시다.
39 |
40 | - **[DNS](https://aws.amazon.com/ko/route53/what-is-dns/)**: DNS은 Domain Name System으로, 우리가 읽을 수 있는 도메인 이름을 IP 주소로 변환해줍니다. 어떻게 도메인 이름을 IP 주소로 변경해서 우리가 접속할 수 있게 하는지 라우팅 흐름에 대해서도 살펴봐주세요.
41 |
42 | - **[Domain Name 등 용어목록](https://support.google.com/a/answer/2573637?hl=ko&ref_topic=3540977&sjid=13810701382978918483-AP)**: 도메인 이름, 하위 도메인, 네이키드 도메인 등등의 용어를 정리한 페이지가 있길래 넣어보았습니다.
43 |
44 | - **[Web Hosting](https://aws.amazon.com/ko/what-is/web-hosting/)**: 웹 호스팅은 서버 컴퓨터의 전체 또는 일정 공간을 이용할 수 있도록 임대해 주는 서비스를 뜻합니다. 이 서비스에 관련해서 간단히 알아보고, 만약 우리 codedang이 어떻게 호스팅하는지 궁금하다면 '인프라 팀'에게 물어보면 친절히 가르쳐줄 거에용
45 |
46 | ### 3. Rest API
47 |
48 | 백엔드가 하는 업무 중 가장 중요하고, 많이 하는 것은 API를 설계하고 개발하는 일입니다. API가 도대체 뭘까요?
49 |
50 | API는 application programming interface로, 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의합니다. 그리고 이러한 API를 조금 더 체계적으로 관리하기 위해서 Representational State Transfer(REST)라는 API 작동 방식에 대해 조건을 다는 software architecture가 등장하였으며 현재까지도 보편적으로 쓰이고 있습니다.
51 |
52 | 이러한 Rest API의 특징에 대해 살펴봅시다.
53 |
54 | - **[RestAPI 제대로 알기](https://meetup.nhncloud.com/posts/92)**
55 |
56 | Rest API의 설계 규칙을 자세히 봐주세요!
57 | 이러한 Rest API의 설계 규칙을 잘 따르는 API를 Restful 하다고 얘기하고, 저희 백엔드 팀에서 API를 설계할때는 최대한 Restful하게 하는 것을 원칙으로 하고있습니다.
58 |
59 | 위 링크 외에도 찾아보시면 다양한 정보들이 나올거에요!
60 |
61 | ## 코드당에서는...
62 | 저희 코드당도 Client쪽은 Rest API를, Admin쪽은 나중에 배울 GraphQL을 사용하고 있습니다.
63 |
64 | Client는 일반 학생 유저, Admin은 교수님/조교님 또는 스꾸딩 개발자들이 주로 사용한다고 생각해주시면 됩니다. Admin은 왜 GraphQL을 사용하는지..... 마지막 주차에 배워보아요~!
65 |
66 | ### 코드당 웹사이트의 동작을 간단하게 요약하면 이렇습니다✨
67 |
68 | - 유저가 웹브라우저에 URL을 입력
69 | - 웹브라우저는 DNS 서버에 resolve 요청
70 | - DNS 서버가 알려준 IP 주소로 HTTP 요청 전송
71 | - 요청을 받은 프론트엔드 서버는 백엔드 서버에 API 요청을 보내 필요한 정보를 획득
72 | - 획득한 정보를 이용해 프론트엔드 서버에서 HTML 페이지를 렌더링 한 뒤 유저에게 전송(이걸 SSR이라고 합니다😇 ~~자세한 내용은 프론트 스터디로...~~)
73 | ---
74 | 그럼 첫번째 스터디때 뵙겠습니다! 파이팅💪
75 |
--------------------------------------------------------------------------------
/content/docs/frontend/assets/pokemon.js:
--------------------------------------------------------------------------------
1 | const data = [
2 | {
3 | name: 'Bulbasaur',
4 | height: '7',
5 | weight: '69',
6 | types: ['grass', 'poison'],
7 | 'base-Experience': '64',
8 | abilities: ['overgrow', 'chlorophyll'],
9 | hp: '45',
10 | attack: '49',
11 | defense: '49',
12 | 'special-attack': '65',
13 | 'special-defense': '65',
14 | speed: '45',
15 | },
16 | {
17 | name: 'Ivysaur',
18 | height: '10',
19 | weight: '130',
20 | types: ['grass', 'poison'],
21 | 'base-Experience': '142',
22 | abilities: ['overgrow', 'chlorophyll'],
23 | hp: '60',
24 | attack: '62',
25 | defense: '63',
26 | 'special-attack': '80',
27 | 'special-defense': '80',
28 | speed: '60',
29 | },
30 | {
31 | name: 'Venusaur',
32 | height: '20',
33 | weight: '1000',
34 | types: ['grass', 'poison'],
35 | 'base-Experience': '236',
36 | abilities: ['overgrow', 'chlorophyll'],
37 | hp: '80',
38 | attack: '82',
39 | defense: '83',
40 | 'special-attack': '100',
41 | 'special-defense': '100',
42 | speed: '80',
43 | },
44 | {
45 | name: 'Charmander',
46 | height: '6',
47 | weight: '85',
48 | types: ['fire'],
49 | 'base-Experience': '62',
50 | abilities: ['blaze', 'solar-power'],
51 | hp: '39',
52 | attack: '52',
53 | defense: '43',
54 | 'special-attack': '60',
55 | 'special-defense': '50',
56 | speed: '65',
57 | },
58 | {
59 | name: 'Charmeleon',
60 | height: '11',
61 | weight: '190',
62 | types: ['fire'],
63 | 'base-Experience': '142',
64 | abilities: ['blaze', 'solar-power'],
65 | hp: '58',
66 | attack: '64',
67 | defense: '58',
68 | 'special-attack': '80',
69 | 'special-defense': '65',
70 | speed: '80',
71 | },
72 | {
73 | name: 'Charizard',
74 | height: '17',
75 | weight: '905',
76 | types: ['fire', 'flying'],
77 | 'base-Experience': '240',
78 | abilities: ['blaze', 'solar-power'],
79 | hp: '78',
80 | attack: '84',
81 | defense: '78',
82 | 'special-attack': '109',
83 | 'special-defense': '85',
84 | speed: '100',
85 | },
86 | {
87 | name: 'Squirtle',
88 | height: '5',
89 | weight: '90',
90 | types: ['water'],
91 | 'base-Experience': '63',
92 | abilities: ['torrent', 'rain-dish'],
93 | hp: '44',
94 | attack: '48',
95 | defense: '65',
96 | 'special-attack': '50',
97 | 'special-defense': '64',
98 | speed: '43',
99 | },
100 | {
101 | name: 'Wartortle',
102 | height: '10',
103 | weight: '225',
104 | types: ['water'],
105 | 'base-Experience': '142',
106 | abilities: ['torrent', 'rain-dish'],
107 | hp: '59',
108 | attack: '63',
109 | defense: '80',
110 | 'special-attack': '65',
111 | 'special-defense': '80',
112 | speed: '58',
113 | },
114 | {
115 | name: 'Blastoise',
116 | height: '16',
117 | weight: '855',
118 | types: ['water'],
119 | 'base-Experience': '239',
120 | abilities: ['torrent', 'rain-dish'],
121 | hp: '79',
122 | attack: '83',
123 | defense: '100',
124 | 'special-attack': '85',
125 | 'special-defense': '105',
126 | speed: '78',
127 | },
128 | {
129 | name: 'Caterpie',
130 | height: '3',
131 | weight: '29',
132 | types: ['bug'],
133 | 'base-Experience': '39',
134 | abilities: ['shield-dust', 'run-away'],
135 | hp: '45',
136 | attack: '30',
137 | defense: '35',
138 | 'special-attack': '20',
139 | 'special-defense': '20',
140 | speed: '45',
141 | },
142 | ]
143 |
--------------------------------------------------------------------------------
/content/docs/infra/8. GitHub Actions.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "8. GitHub Actions"
3 | description = "CI/CD 도구인 GitHub Actions에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-11-16"
6 | lastmod = "2023-11-16"
7 | weight = 380
8 | +++
9 |
10 | 여러 명의 개발자들이 협업하면 자연스럽게 서로의 코드를 합치는 작업이 빈번하게 일어나요. CI/CD는 코드를 합치는 merge 과정에서 코드에 문제가 없는지, 빌드는 잘 되는지 등을 자동으로 확인하고, 자동화된 배포를 진행하는 과정이예요. GitHub Actions는 CI/CD 파이프라인을 YAML 파일로 직접 정의해 실행해 실행할 수 있도록 도와주는 도구로, 이번 주차에는 이를 활용해 CI/CD 환경을 구축해볼 거예요.
11 |
12 | ## 공부할 내용 📚
13 |
14 | ### 1. GitHub Actions
15 |
16 | DevOps의 핵심인 CI/CD가 무엇인지 이해하고, GitHub Action을 이용해서 CI/CD를 구성하는 방법을 배워봅니다.
17 |
18 | - CI/CD의 개념과 과정을 이해합니다.
19 | - GitHub Actions의 구성 요소를 알아봅니다. (workflows, events, jobs, actions)
20 | - GitHub Actions의 문법을 이해하고 workflow를 직접 작성해봅니다.
21 | - GitHub Action에서 secret을 관리하는 방법을 알아봅니다.
22 |
23 | #### 참고 자료
24 |
25 | - **[CI/CD란 무엇일까?](https://jud00.tistory.com/entry/CICD%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C)**: CI/CD의 개념과 과정을 정리한 글입니다.
26 | - **[Dalseo "GitHub Actions의 소개와 핵심 개념"](https://www.daleseo.com/github-actions-basics/)**: GitHub Actions의 개념과 구성 요소를 정리한 글입니다.
27 | - **[Dalseo "GitHub Actions 첫 워크플로우 생성해보기"](https://www.daleseo.com/github-actions-first-workflow/)**: GitHub Actions의 workflow를 작성하는 방법을 정리한 글입니다.
28 | - **["Secrets으로 환경변수 사용"](https://wooono.tistory.com/693)**: GitHub Actions에서 secret을 사용하는 방법을 정리한 글입니다.
29 | - **["Code QL에 대하여"](https://thfist-1071.tistory.com/313)**: 코드당에서도 사용 중인, 코드의 보안 취약점과 버그를 자동으로 탐지해 주는 도구인 CodeQL에 대해 알아봐요.
30 |
31 | ## 프로젝트 실습 🎈
32 |
33 | 총 두 개의 workflow를 작성합니다.
34 |
35 | {{< alert context="info" text="코드당 repository를 참고하면 도움이 될 거예요! https://github.com/skkuding/codedang/tree/main/.github/workflows" />}}
36 |
37 | ### 1. ci.yml
38 |
39 | - CodeQL을 이용해서 코드의 취약점을 검사해볼 거예요.
40 | - `main` branch에 push되거나 Pull Request가 생성되었을 때 workflow를 실행해야 해요.
41 | - workflow가 실행되면, CodeQL을 이용해서 JavaScript 코드의 취약점을 검사해요.
42 | - 참고 자료: **["컨테이너에서 CodeQL 코드 검사 실행"](https://docs.github.com/ko/enterprise-server@3.10/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/running-codeql-code-scanning-in-a-container)**
43 |
44 | ### 2. cd.yml
45 |
46 | `main` branch에 push되었을 때 workflow를 실행해야 해요. 총 세 개의 job을 실행합니다.
47 |
48 | #### Job 1: AWS S3 Sync
49 |
50 | - HTML, CSS, JS 파일을 S3에 업로드해요.
51 | - GitHub Actions에서 AWS에 접근할 수 있도록 IAM User를 만들어주세요.
52 | - 이 플러그인으로 로그인 해주세요: [aws-actions/configure-aws-credentials](https://github.com/aws-actions/configure-aws-credentials)
53 | - **OpenID Connect를 이용해서 AWS에 로그인해야 해요. (중요!)**
54 | - `aws s3 sync` 명령어를 이용해서 파일을 업로드해요.
55 |
56 | #### Job 2: Build & Push Image
57 |
58 | - 6주차 실습 내용대로 Node.js 이미지를 만들고, 원격 저장소로 push합니다.
59 | - 아래 Option A(AWS ECR) 또는 Option B(GitHub Container Registry) 중 하나를 선택해서 진행하세요.
60 | - Option A: AWS 서비스 간의 통합이 매끄럽고, IAM 권한 관리가 용이합니다.
61 | - Option B: GitHub Actions에서 별도의 인증 토큰 생성 없이 기본 제공되는 GITHUB_TOKEN으로 바로 접근할 수 있어 설정이 간편합니다.
62 | - **Option A: AWS ECR 사용**
63 | - Job 1과 마찬가지로 OpenID Connect를 이용해 AWS에 로그인 해주세요.
64 | - 이 플러그인으로 ECR에 로그인해주세요: [aws-actions/amazon-ecr-login](https://github.com/aws-actions/amazon-ecr-login)
65 | - 이 플러그인으로 Docker를 빌드해주세요: [docker/build-push-action](https://github.com/docker/build-push-action)
66 | - **Option B: GHCR (GitHub Container Registry) 사용**
67 | - 별도의 가입 없이 GitHub 계정으로 사용 가능합니다.
68 | - docker/login-action을 사용하여 로그인합니다. (별도 Secret 등록 불필요)
69 | - docker/build-push-action을 사용하여 이미지를 빌드하고 ghcr.io/사용자명/이미지명 형식으로 Push합니다.
70 |
71 | #### Job 3: Terraform apply
72 |
73 | - Terraform 파일에 변경된 내용을 적용해요.
74 | - Job 1, 2가 성공적으로 끝난 이후에 실행되어야 해요.
75 | - Job 1, 2와 마찬가지로 OpenID Connect를 이용해서 AWS에 로그인 해주세요.
76 | - **Terraform Backend로 S3를 사용하세요. (중요!)**
77 | - 이 플러그인으로 Terraform을 실행해주세요: [hashicorp/setup-terraform](https://github.com/hashicorp/setup-terraform)
78 |
--------------------------------------------------------------------------------
/content/docs/frontend/2. JavaScript, DOM.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "2. JavaScript, DOM"
3 | description = "JavaScript로 웹의 동적인 부분을 다뤄봅니다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 220
8 | +++
9 |
10 | 저번 시간에는 HTML, CSS를 통해 웹의 구조와 디자인와 같은 정적인 부분을 다뤄봤어요. 이번 시간에는 JavaScript를 통해 웹의 동적인 부분을 다뤄볼 거예요!
11 |
12 | 여러분의 공부를 돕기 위해 준비한 자료들이에요. 따라서 꼭 준비된 자료만 공부할 필요는 없어요! 자신만의 방식으로 공부하고 과제만 잘 수행하면 돼요! 😄
13 |
14 | ## 공부할 내용 📚
15 |
16 | ### JavaScript
17 |
18 | Javascript는 객체 기반의 스크립트 프로그래밍 언어로 웹 브라우저 내에서 사용하기 위해 태어났어요! 다만 최근에는 V8, Node.JS 등장으로 다양한 런타임 환경에서 사용할 수 있어 활용도가 높아지고 있어요.
19 |
20 | 평소에 사용하던 C, JAVA와 비슷한 Syntax를 가지고 있어요! 덕분에 배우기 쉬울 거예요!
21 |
22 | > Java와 JavaScript는 전혀 다른 언어예요! 그저 마케팅의 하나로 이름을 비슷하게 지었을 뿐이에요!
23 | > "The choice of the JavaScript name has caused confusion, implying that it is directly related to Java. At the time, the dot-com boom had begun and Java was the hot new language, so **Eich considered the JavaScript name a marketing ploy by Netscape**." (출처: [Wikipedia](https://en.wikipedia.org/wiki/JavaScript))
24 |
25 | - [JavaScript 100초 소개](https://www.youtube.com/watch?v=DHjqpvDnNGE&ab_channel=Fireship)
26 | - JavaScript가 무엇인지, 왜 중요한지 100초만에 알려줘요!
27 | - [Javascript.info 튜토리얼](https://ko.javascript.info/)
28 | - 파트 1. 코어 자바스크립트
29 | - 1.1 ~ 5.12
30 | - 프라미스와 async, await 맛보기!
31 | - [자바스크립트 비동기, Promise, async, await 확실하게 이해하기](https://springfall.cc/article/2022-11/easy-promise-async-await)
32 | - 나머지는 선택!
33 |
34 | ### DOM
35 |
36 | DOM(Document Object Model)은 HTML 문서의 구조를 트리 형태로 다루는 인터페이스에요. 해당 챕터를 배우면 여러분들은 HTML 문서 조작, 이벤트, 브라우저 API 등을 통해 더 다양한 웹 페이지를 만들 수 있어요!
37 |
38 | - [Javascript.info 튜토리얼](https://ko.javascript.info/)
39 | - 파트 2. 브라우저: 문서, 이벤트, 인터페이스
40 | - 1.1 ~ 5.3
41 | - 파트 3. 추가 주제
42 | - 4.2 localStorage
43 | - [Javascript활용 DOM, EVENT](https://www.youtube.com/watch?v=uK6uExrg7Ww&list=PLZKTXPmaJk8JVQv3XSNF8yJMdsxbFrO3S&index=1)
44 | - DOM & EVENT 튜토리얼 영상
45 | - [브라우저 동작원리](https://d2.naver.com/helloworld/59361)
46 | - 이번 스터디에서는 필요 없지만, 다음에 읽어보면 좋아요!
47 |
48 | ## 프로젝트 실습 🎈
49 |
50 | 이번 주차에는 저번에 만들었던 포켓몬 도감 사이트를 업그레이드해 볼게요! 업그레이드될 사항은 아래와 같아요.
51 |
52 | 1. 주어진 포켓몬 데이터를 사용해서 메인페이지 리스트를 만들어요.
53 | 2. 하나의 html 파일로 디테일 페이지를 만들어요.
54 |
55 | 데모 사이트는 [링크](https://dayongkr.github.io/skkuding-fe-study/4w/)를 통해 확인할 수 있어요!
56 |
57 | ### 1. 포켓몬 데이터를 사용해서 메인페이지 리스트 만들기
58 |
59 | {{< figure src="../images/week4-main.png" alt="메인 페이지" >}}
60 |
61 | 위와 같이 디자인은 똑같지만 기존 방법과 달리 javascript 파일에서 포켓몬 데이터 배열을 **매핑**하여 리스트를 만들어요.
62 |
63 | > 즉 HTML 파일에 직접 작성하는 것이 아니라 JavaScript파일(script이용)에서 HTML 요소를 만들어서 추가해 주는 방식이에요!
64 |
65 | 포켓몬 데이터는 [assets/pokemon.js](https://study.skkuding.dev/docs/frontend/assets/pokemon.js)에 있어요. 이 데이터를 사용해서 메인페이지 리스트를 만들어 보아요!
66 |
67 | - 메인페이지 Tip 📌
68 | - 리스트를 만들 때는 `map` 배열 메소드를 사용하여 포켓몬 데이터를 html 요소로 변환해 주세요.
69 | - html 요소를 만들 때는 `document.createElement`를 사용해 주세요.
70 | - [문서 수정하기](https://ko.javascript.info/modifying-document) 해당 링크 참고
71 | - 만들고 나서 `appendChild`를 사용하여 부모 요소에 html 요소를 추가해 주세요.
72 | - 만들어진 html 요소에는 `addEventListener`를 사용하여 클릭 이벤트 디테일을 추가해 주세요.
73 | - 클릭 이벤트가 발생하면 `window.location.href`를 사용하여 디테일 페이지로 이동해 주세요. 또한, 디테일 페이지로 이동했을 시 포켓몬 정보 표시를 위해서 `window.localStorage.setItem`를 통해서 정보를 저장해주세요.
74 | - localStorage에 저장되는 데이터는 문자열이기 때문에 `JSON.parse`를 사용하여 객체로 변환해 주세요.
75 |
76 | ### 2. 하나의 html 파일로 디테일 페이지 만들기
77 |
78 | {{< figure src="../images/week4-detail.png" alt="디테일 페이지" >}}
79 |
80 | 디테일 페이지도 디자인은 변함없어요! 다만 기존에는 포켓몬별로 디테일 페이지(html)를 만들었다면 이번에는 하나의 html 파일이 여러 포켓몬의 디테일 페이지를 보여줘야 해요!
81 |
82 | > 즉 이전에는 1 : 1 (html 파일 : 포켓몬) 관계였다면 이번에는 1 : N 관계에요!
83 |
84 | - 디테일 페이지 Tip 📌
85 | - 주소를 통해서 어떤 포켓몬을 보여줘야 하는지 알아낼수도 있지만 live server의 redirection 문제로 `localStorage`를 사용했어요!
86 | - 위 메인페이지 `addEventListener` 통해 저장한 포켓몬 정보를 `window.localStorage.getItem`을 이용해서 표시해보세요.
87 |
88 | ---
89 |
90 | 개발자 도구를 사용하면 제가 작성한 스크립트 파일을 볼 수 있어요! 하지만 공부한 내용을 바탕으로 직접 만들어 보는 것이 중요하기 때문에 최대한 스스로 해결해 보아요! 😄
91 |
--------------------------------------------------------------------------------
/content/docs/infra/3. Docker.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "3. Docker"
3 | description = "컨테이너 기반 가상화 도구인 Docker에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 330
8 | +++
9 |
10 |
11 |
12 | 이번 주차부터는 본격적으로 인프라다운(!) 주제를 공부해볼 거예요. 요즘 배포할 때 빼놓을 수 없는 Docker는 응용프로그램을 격리해주는 컨테이너를 관리해줍니다. 가볍고 빠른 가상머신으로 생각하면 될 거예요.
13 |
14 | 이번 주차에는 Docker가 무엇인지와 왜 쓰는지를 이해하고, Docker CLI와 Docker Compose로 컨테이너를 관리해볼 거예요.
15 |
16 | ## 공부할 내용 📚
17 |
18 | ### 1. Docker
19 |
20 | 서버를 배포할 때 가장 문제를 많이 일으키는 부분 중 하나는 개발 환경과 서버 환경의 차이입니다. 이를 막기 위해서 기존에는 VMWare 같은 가상 머신을 주로 사용하였다면, 요즘은 더 빠르고 가벼운 컨테이너인 Docker를 많이 사용합니다. Docker는 환경 문제나 보안, 성능 등 다양한 문제를 해결해줍니다.
21 |
22 | 우선 [Docker 설치 가이드](Install%20Docker.md)를 참고해서 설치해주세요.
23 |
24 | - Docker가 무엇인지, 기존의 가상머신과의 차이점을 이해합니다.
25 | - Docker CLI를 이용하여 컨테이너를 관리하는 방법을 배웁니다.
26 | (알아볼 명령어: run, ps, stop, rm, exec, logs, images, pull)
27 | - Docker Compose를 이용하여 여러 컨테이너를 관리하는 방법을 배웁니다.
28 | (알아볼 속성: image, build, command, ports, volumes, environment, depends_on, restart, networks)
29 | - Dockerfile을 이용하여 이미지를 만들고 배포해봅니다.
30 | (알아볼 속성: FROM, RUN, COPY, CMD, ENV, WORKDIR, ENTRYPOINT, ADD, HEALTHCHECK)
31 |
32 | #### 참고 자료
33 |
34 | - **[코딩애플 도컥 바꾼 개발바닥 (약 6분)](https://www.youtube.com/watch?v=e0koWWAmXSk)**: 도커가 무엇인지, 왜 쓰는지를 간단하게 설명해줍니다.
35 | - **[subicura "초보를 위한 도커 안내서" (글)](https://subicura.com/2017/01/19/docker-guide-for-beginners-1.html)**: 도커 입문 때 빼놓을 수 없는 자료로 언급되는 글입니다. 총 세 편으로 이루어져있고, 튜토리얼도 차근차근 설명되어있어 추천드립니다. ([2편](https://subicura.com/2017/01/19/docker-guide-for-beginners-2.html), [3편](https://subicura.com/2017/02/10/docker-guide-for-beginners-create-image-and-deploy.html))
36 | - **[Freecodecamp "Docker Tutorial for Beginners" (약 2시간)](https://youtu.be/fqMOX6JJhGo?si=rud5_lyC_N53ZO7x)**: 영상이 더 편한 분들을 위한 강의입니다.
37 |
38 | ### 2. Nginx
39 |
40 | Nginx는 웹 서버로, 요즘은 대부분의 서버가 Nginx를 사용합니다. Nginx는 매우 빠르고 확장성이 좋아서 많이 사용됩니다. Nginx의 주 용도인 reverse proxy와 load balancing을 배우고, Nginx를 설정하는 방법을 알아봅니다.
41 |
42 | - Nginx의 역할과 특징을 이해합니다.
43 | - Proxy(reverse vs. forward)와 Load Balancing의 개념을 이해합니다.
44 | - Nginx를 설치하고 설정하는 방법을 배웁니다.
45 |
46 | {{< alert context="warning" text="Nginx 연습은 Docker로 하는 걸 권장합니다! 로컬에 설치한 Nginx는 기존에 설치된 서버와 충돌할 수 있고, 원복이 어려울 수 있습니다. [Nginx 이미지](https://hub.docker.com/_/nginx)로 컨테이너를 만들고, 로컬의 nginx.conf 파일을 볼륨으로 연결해보세요." />}}
47 |
48 | #### 참고 자료
49 |
50 | - **[우아한테크 "피케이의 Nginx" (약 16분)](https://youtu.be/6FAwAXXj5N0?si=G7JUxntHPVx7L8gb)**: 웹 서버의 역사와 Nginx의 특징을 간단하게 설명해줍니다.
51 | - **[Nginx 공식 문서](https://nginx.org/en/docs/beginners_guide.html)**: Nginx 공식 문서입니다. 영어로 되어있지만, 매우 자세하게 설명되어있어서 참고하기 좋습니다. (Beginner's guide 읽어주세요!)
52 | - **["docker로 nginx 설정하기" (글)](https://middleearth.tistory.com/49)**: Docker로 Nginx를 설정하는 방법을 설명한 글입니다.
53 |
54 |
55 | ## 프로젝트 실습 🎈
56 |
57 | 지난 번에 만든 Express 어플리케이션을 Dockerize(Docker Image를 만들어서 배포)해봅니다. Express만 Dockerize하면 재미없죠...! Nginx도 Dockerize해서 Express 앞에 두고, Nginx가 Express로 요청을 전달하도록 설정해봅니다. (Reverse Proxy로 쓸 거예요!)
58 |
59 | ```mermaid
60 | flowchart LR
61 | subgraph Docker Compose
62 | Nginx -- localhost:3000 --> Node.js
63 | end
64 | Client -- localhost:8000 --> Nginx
65 | ```
66 |
67 | - docker-compose.yml 파일을 작성해주세요.
68 | - Express 어플리케이션을 수정해주세요!
69 | - Express 어플리케이션의 포트를 3000번으로 변경해주세요.
70 | - HTML을 반환하는 endpoint는 없애주세요. Nginx가 HTML을 반환하도록 해주세요! (`GET /`)
71 | - Express 어플리케이션을 Dockerize합니다. [공식 Node.js Docker Image](https://hub.docker.com/_/node/)를 Dockerfile에서 `FROM`으로 사용해주세요.
72 | - Nginx 이미지는 공식 이미지를 그대로 사용하면 됩니다. nginx.conf와 index.html 파일을 볼륨으로 연결해주세요. (week2.html의 이름을 변경해주세요!)
73 |
74 | {{< alert text="**Dockerize란,** 서비스 코드와 의존성을 container에 담는 Dockerfile을 작성하고, Docker CLI를 이용하여 이미지를 빌드하고 컨테이너를 실행하는 과정입니다." />}}
75 |
76 | > **Challenge! 🔥 (선택)**
77 | > Express 컨테이너를 두 개 띄우고, Nginx에서 load balancing 기능을 사용해보세요.
78 | > Hint: Node.js의 포트를 외부로 노출하면 충돌이 나겠죠? 노출시키지 않고 컨테이너끼리 요청을 주고받는 방법을 알아보세요!
79 |
80 | ```mermaid
81 | flowchart LR
82 | subgraph Docker Compose
83 | Nginx -- localhost:3000 --> A("Node.js(1)")
84 | Nginx -- localhost:3000 --> B("Node.js(2)")
85 | end
86 | Client -- localhost:80 --> Nginx
87 | ```
88 |
--------------------------------------------------------------------------------
/content/docs/infra/Observability(1).md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "Observability (1)"
3 | description = "모니터링 시스템의 데이터 '수집/처리'에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2025-07-23"
6 | lastmod = "2025-07-23"
7 | weight = 391
8 | +++
9 |
10 | 📖 세션 목표: 애플리케이션과 인프라에서 발생하는 모든 텔레메트리 데이터(메트릭, 로그, 트레이스)를 수집하고, OTEL Collector를 통해 각각의 전문 저장소로 전달하는 파이프라인을 구축한다.
11 |
12 | ## 공부할 내용 📚
13 |
14 | ### 1. OpenTelemetry(OTel)
15 |
16 | OpenTelemetry는 애플리케이션과 인프라에서 발생하는 텔레메트리 데이터 데이터를 수집하고 처리하는 오픈 소스 프로젝트입니다. OTel은 다양한 언어와 플랫폼을 지원하며, 데이터 수집을 **표준화**하여 모니터링과 관측 가능성을 향상시킵니다.
17 |
18 | - **OpenTelemetry란?**: OpenTelemetry의 개념과 등장 배경을 이해합니다.
19 | - **OTel의 구성 요소**: OTel의 주요 구성 요소(Collector, SDK, API 등)를 이해합니다.
20 |
21 | #### 참고 자료
22 | - **[OpenTelemetry in 180 seconds](https://youtu.be/vnE_DfNB97w?si=Z7txE1RqcUgluh8X)**: OpenTelemetry부터 OTel Collector의 개념과 필요성을 간단하게 설명하는 영상입니다.
23 | - **[OpenTelemetry 공식 문서](https://opentelemetry.io/docs/what-is-opentelemetry/)**: OpenTelemetry의 개념에 대한 공식 문서입니다.
24 | - **[OpenTelemetry란 무엇인가?](https://medium.com/@dudwls96/opentelemetry-란-무엇인가-18b6e4fe6e36)**: OpenTelemetry의 개념과 필요성, 나아가 아키텍처 및 구성 요소에 대한 설명입니다.
25 |
26 | ### 2. 텔레메트리 데이터 소스 심층 탐구
27 |
28 | 애플리케이션에서는 메트릭, 로그, 트레이스 등 다양한 텔레메트리 데이터를 생성합니다. 이 데이터들은 시스템의 상태를 모니터링하고, 문제를 해결하는 데 중요한 역할을 합니다.
29 |
30 | - **데이터 종류**: 각 텔레메트리 데이터의 종류(메트릭, 로그, 트레이스)와 그 역할을 이해합니다.
31 | - **수집 방법**: 코드 변경 없이 수집하는 방법(Zero-code solutions)과 코드 변경을 통해 수집하는 방법(Code-based solutions)을 이해합니다.
32 |
33 | #### 참고 자료
34 | - **[Elastic "What is Telemetry Data?"](https://www.elastic.co/kr/what-is/telemetry-data/#types-of-telemetry-data)**: 텔레메트리 데이터의 종류와 수집 방법에 대한 설명입니다.
35 | - **[OpenTelemetry "Instrumentation"](https://opentelemetry.io/docs/concepts/instrumentation/)**: OpenTelemetry에서의 계측 방법에 대한 설명입니다.
36 |
37 | ### 3. 중앙 허브, OTEL Collector
38 |
39 | 모든 텔레메트리 데이터의 중앙 허브 역할을 하는 OTEL Collector에 대해 알아봅니다.
40 |
41 | - OTEL Collector의 역할과 필요성을 알아봐요.
42 | - OTEL Collector의 아키텍처를 알아봐요. (Receivers, Processors, Exporters)
43 | - 텔레메트리 데이터의 종류에 따라 사용되는 리시버(Receiver)와 익스포터(Exporter)를 알아봐요.
44 |
45 | #### 참고 자료
46 | - **[OTel 공식 문서 "Collector를 사용해야 하는 이유"](https://opentelemetry.io/docs/collector/#when-to-use-a-collector)**: Collector를 통한 중앙화, 데이터 처리의 필요성을 설명합니다.
47 | - **[OTel 공식 문서 "Collector 아키텍처"](https://opentelemetry.io/docs/collector/architecture/)**: OTEL Collector의 아키텍처와 구성 요소에 대한 설명입니다.
48 | - **[OTLP Receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver#readme)**: 코드당에서도 사용하는 OTLP 형식의 텔레메트리 데이터를 처리하는 리시버입니다.
49 |
50 | ### 4. 역할별 전문 저장소(백엔드) 소개
51 |
52 | 텔레메트리 데이터는 종류별로 전문 저장소에 저장됩니다. 각 데이터 유형에 맞는 저장소를 알아봅시다.
53 |
54 | - 텔레메트리 데이터의 종류 별로 어떤 저장소가 사용되는지 알아봐요.
55 | - 메트릭: Prometheus
56 | - 로그: Loki
57 | - 트레이스: Tempo
58 | - 각 전문 저장소는 Collector에서 어떤 방식으로 데이터를 수집하는지 알아봐요. (Pull, Push 방식)
59 | - 각 전문 저장소가 수 많은 데이터를 어떻게 효율적으로 저장하고 검색하는지 알아봐요. (Indexing)
60 | - 각 전문 저장소가 쌓인 데이터를 넘치지 않게 관리하는 방법을 알아봐요. (Lifecycle Management)
61 |
62 | #### 참고 자료
63 | 설치 및 실습 부분에서 쿠버네티스 관련 내용이 많이 나오는데, 간단히 참고만 해주세요.
64 | - [\[Prometheus\] 란?](https://wlsdn3004.tistory.com/35)
65 | - **[Prometheus in 120 seconds](https://youtu.be/owcPJBvyU8Y?si=24aA88dyiJFRGNis)**: Prometheus의 개념과 작동 방식을 간단하게 설명하는 영상입니다.
66 | - [\[Grafana Loki\]란? 개념부터 설치까지](https://wlsdn3004.tistory.com/48)
67 | - [\[Grafana Tempo\]란? 개념부터 설치까지](https://wlsdn3004.tistory.com/49)
68 |
69 | ## 프로젝트 실습 🎈(작성 중)
70 | OTel SDK를 사용하여 애플리케이션에서 텔레메트리 데이터를 수집하고, OTEL Collector를 통해 전문 저장소로 전달하는 파이프라인을 구축해볼 거예요.
71 |
72 | ### 모니터링 대상 어플리케이션에 OTel SDK 코드 삽입
73 |
74 | 어플리케이션 코드에 OTel SDK를 삽입하여 텔레메트리 데이터를 수집합니다. 예를 들어, Node.js 애플리케이션에서는 `@opentelemetry/sdk-node` 패키지를 사용하여 메트릭, 로그, 트레이스를 수집할 수 있습니다.
75 |
76 | - 핵심 패키지인 [@opentelemetry/sdk-node](https://www.npmjs.com/package/@opentelemetry/sdk-node)를 설치합니다.
77 | - [@opentelemetry/resources](https://www.npmjs.com/package/@opentelemetry/resources)를 활용하여 모니터링 대상 어플리케이션에 대한 정보를 설정합니다.
78 | - 이 때 [@opentelemetry/semantic-conventions](https://www.npmjs.com/package/@opentelemetry/semantic-conventions)를 사용하여 표준화된 속성을 사용합니다.
79 | - (선택 사항) [@opentelemetry/instrumentation](https://www.npmjs.com/package/@opentelemetry/instrumentation) 패키지를 사용하여 자동 계측을 설정합니다.
80 |
81 | ### Collector 및 백엔드 설정
82 |
83 | OTel Collector와 여러 저장소 처럼 많은 서비스들을 설정해야 하기 때문에 이전에 배운 Docker Compose를 사용하여 각 서비스를 컨테이너로 실행합니다.
84 |
85 |
86 | #### OTel Collector 설정
87 |
88 | OTel Collector를 설정하여 OTel SDK에서 보낸 텔레메트리 데이터를 수집합니다.
89 |
90 | #### Loki, Prometheus, Tempo 설정
91 |
92 | 로그, 메트릭, 트레이스 데이터 모두를 수집하는 것은 양이 방대하기 때문에 이번 실습에서는 로그만 수집해볼거에요.
93 |
--------------------------------------------------------------------------------
/content/docs/infra/6. Kubernetes.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "6. Kubernetes (k8s)"
3 | description = "컨테이너 오케스트레이션 도구인 Kubernetes에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-10-30"
6 | lastmod = "2025-07-07"
7 | weight = 360
8 | +++
9 |
10 | Kubernetes는 컨테이너 오케스트레이션 도구로, 여러 개의 컨테이너를 관리하고, 배포할 수 있도록 도와줍니다.
11 | 이번 시간에는 많은 기업에서 인프라 팀이라면 필수인 Kubernetes에 대해 알아보겠습니다.
12 |
13 | ## 공부할 내용 📚
14 |
15 | ### 1. YAML 문법
16 |
17 | Kubernetes는 YAML 파일로 리소스를 정의합니다.
18 | YAML은 데이터를 표현하기 위한 포맷으로, JSON과 비슷하지만 더 간결하고 읽기 쉽습니다.
19 |
20 | #### 참고 자료
21 |
22 | - **[쿠버네티스 안내서 "YAML 문법"](https://subicura.com/k8s/prepare/yaml.html)**: YAML의 기본 문법을 정리한 글입니다.
23 | - **[인파 'YAML 개념 & 문법 마스터 하기'](https://inpa.tistory.com/entry/YAML-%F0%9F%93%9A-yaml-%EA%B0%9C%EB%85%90-%EB%AC%B8%EB%B2%95-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%F0%9F%92%AF-%EC%B4%9D%EC%A0%95%EB%A6%AC)**: JSON과 비교하며 YAML의 내용을 자세히 설명한 글입니다.
24 |
25 | ### 2. Kubernetes
26 |
27 | Kubernetes는 여러 서버에서 많은 컨테이너를 관리하기 위한 도구입니다.
28 | Kubernetes가 복잡한 도구로 많이 알려져 있지만, **'원하는 상태와 실제 상태를 동기화하는 도구'라는 핵심 철학**을 이해하면 어렵지 않게 사용할 수 있습니다.
29 |
30 | Kubernetes 자체를 설치하는 것은 매우 까다롭기 때문에, minikube나 k3s를 설치해서 실습하는 걸 추천드립니다.
31 |
32 | 아래 핵심 개념들은 꼭 익혀두는 걸 추천드립니다.
33 |
34 | - kubectl 명령어
35 | - Cluster, Node, Pod, Container의 관계
36 | - Control Plane(Master Node)와 Worker Node의 역할
37 | - Ingress와 Service를 통한 네트워크 설정
38 | - Deployment, ConfigMap, Secret, Volume 등의 리소스
39 |
40 | 조금 더 깊이 알아보고 싶다면, 내부 구조도 공부해보면 좋습니다.
41 |
42 | - Control Plane과 Worker Node를 이루는 내부 components
43 | - Control Plane: kube-apiserver, etcd, kube-controller-manager, kube-scheduler
44 | - Worker Node: kubelet, kube-proxy, container runtime (Docker, containerd 등)
45 |
46 | #### 참고 자료
47 |
48 | - **[Subicura "쿠버네티스 시작하기"](https://subicura.com/2019/05/19/kubernetes-basic-1.html)**: Kubernetes의 기본 개념을 다루는 글입니다.
49 | - **[쿠버네티스 안내서](https://subicura.com/k8s/)**: Kubernetes의 기본 개념들을 실습과 함께 자세히 정리한 글입니다. 분량이 조금 많지만, Kubernetes를 처음 접하는 분들에게는 좋은 자료입니다.
50 | - **[삼성 SDS 쿠버네티스 알아보기](https://www.samsungsds.com/kr/insights/kubernetes-3.html)**: Kubernetes의 내부 구성 요소들을 정리한 글입니다.
51 |
52 | ## 프로젝트 실습 🎈
53 |
54 | 이번 주에는 Kubernetes를 이용해서 Node.js 컨테이너를 스케일링해볼 거예요.
55 | 아래 그림처럼 EC2 내에 Docker compose로 구성했던 Node.js 서버를 Kubernetes로 구성해볼 거예요.
56 |
57 | {{< alert context="warning" text="사실 EC2에 직접 Kubernetes 클러스터를 구성하는 것은 일반적이지 않아요. AWS에서는 EKS 등의 서비스를 쓰는 것이 더 일반적이지만, 복잡성과 비용을 감안해 이번 실습은 간단하게 k3s를 활용해보기로 해요." />}}
58 |
59 | ```mermaid
60 | flowchart LR
61 | subgraph AWS
62 | subgraph EC2
63 | subgraph Kubernetes
64 | Ingress --> Node.js
65 | end
66 | end
67 | style Kubernetes fill:#ffaa90
68 | ALB -- localhost:3000 --> Ingress
69 | CloudFront -- /api/* --> ALB
70 | CloudFront -- /* --> S3
71 | end
72 | Client -- http://[domain-name] --> CloudFront
73 | ```
74 |
75 | ### EC2 인스턴스는 새로 생성해주세요.
76 |
77 | - [k3s의 최소 요구사항](https://docs.k3s.io/installation/requirements)에 맞게 아래 조건을 지켜주세요.
78 | - **운영체제**: Ubuntu 20.04 LTS 이상 (24.04 LTS 권장)
79 | - **인스턴스 타입**: t3.small 이상 (2 CPU, 2GB RAM 이상)
80 | - **스토리지**: SSD 20GB 이상 할당
81 | - **보안 그룹**: 22(SSH), 6443(Kubernetes API) 포트가 inbound로 열려있어야 합니다.
82 | - EC2 인스턴스 내부에 Docker와 k3s를 설치해주세요.
83 |
84 | ```bash
85 | # Docker 설치
86 | curl -fsSL https://get.docker.com | sudo sh -
87 |
88 | # k3s 설치
89 | curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --tls-san=$(curl ifconfig.me) --write-kubeconfig-mode=644" sh
90 | ```
91 |
92 | ### 원격 kubectl 접속을 설정하세요.
93 |
94 | - 로컬 환경에 kubectl을 설치하세요. ([공식 가이드](https://kubernetes.io/docs/tasks/tools/))
95 | - 서버에서 명령어 `sudo cat /etc/rancher/k3s/k3s.yaml`로 kubeconfig를 확인하세요.
96 | - 출력된 kubeconfig를 복사해 로컬의 `~/.kube/remote-config` 파일에 저장하세요.
97 | - kubeconfig 파일에서 `server` 항목의 IP 주소를 EC2 인스턴스의 퍼블릭 IP로 변경하세요.
98 |
99 | ```yaml
100 | server: https://[EC2-PUBLIC-IP]:6443
101 | ```
102 |
103 | - KUBECONIFG 환경 변수를 설정하세요.
104 |
105 | ```bash
106 | export KUBECONFIG=~/.kube/remote-config
107 | ```
108 |
109 | - kubectl 명령어로 EC2 인스턴스에 접속이 잘 되는지 확인하세요.
110 |
111 | ```bash
112 | kubectl get all
113 | ```
114 |
115 | ### Deployment를 YAML 파일로 작성하세요.
116 |
117 | - Node.js 컨테이너를 실행하는 Deployment YAML 파일을 작성하세요.
118 | - 2개의 Node.js 컨테이너를 실행하도록 설정하세요.
119 | - kubectl 명령어로 잘 배포되었는지 확인해보세요.
120 |
121 | ### Service를 YAML 파일로 작성하세요.
122 |
123 | - Node.js 서비스를 외부에 노출할 수 있도록 Service를 작성하세요.
124 | - 외부에 31000 포트로 노출되도록 설정하세요. (EC2 보안 그룹에서도 31000 포트를 열어주세요.)
125 | - 직접 curl 명령어로 Node.js 서비스를 확인해보세요.
126 | - ALB의 target group에 EC2 인스턴스의 31000 포트를 추가하세요.
127 |
--------------------------------------------------------------------------------
/data/landing.yml:
--------------------------------------------------------------------------------
1 | # Note: Template blocks require a 'weight' parameter so they're correctly ordered on the landing page
2 |
3 | # Hero
4 | hero:
5 | enable: true
6 | weight: 10
7 | template: 'hero'
8 |
9 | # backgroundImage:
10 | # path: 'images/templates/hero'
11 | # filename:
12 | # desktop: 'gradient-desktop.webp'
13 | # mobile: 'gradient-mobile.webp'
14 |
15 | # badge:
16 | # text: v0.0.2
17 | # color: primary # primary, secondary, success, danger, warning, info, light, dark
18 | # pill: false # boolean
19 | # soft: true # boolean
20 |
21 | titleLogo:
22 | path: 'images'
23 | filename: 'logo.png'
24 | alt: 'SKKUDING Logo'
25 | height: 80px
26 |
27 | title: 'Cookbook'
28 | subtitle: 스꾸딩의 신입 팀원들을 위해 스꾸딩의 개발 레시피를 모아둔 곳입니다! 필요한 기술 지식을 익히고 프로젝트에 적용해보세요.
29 |
30 | image:
31 | path: 'images' # path to image under configured assets directory. default 'images'
32 | filename: 'notion.png' # filename of your hero image (including file extension)
33 | alt: 'Lotus Docs Screenshot' # Optional but recommended
34 | # boxShadow: true # default 'false' (excludes .svg images)
35 | # rounded: true # round the image corners? default 'false' (excludes .svg images)
36 |
37 | ctaButton:
38 | icon: rocket_launch
39 | btnText: 'Get Started'
40 | url: '/docs/'
41 | # cta2Button:
42 | # icon: construction
43 | # btnText: 'In Development'
44 | # url: 'https://github.com/colinwilson/lotusdocs'
45 |
46 | # info: '**Open Source** MIT Licensed.'
47 |
48 | # Features Grid
49 | featureGrid:
50 | enable: true
51 | weight: 20
52 | template: 'feature_grid'
53 |
54 | title: 스꾸딩의 스터디는 어떻게 진행되나요?
55 | subtitle: 신입 팀원들은 프로젝트에 참여하기 전, 한 학기 동안 스터디를 진행해요. 프로젝트에 필요한 기술을 익히고, 실제 프로젝트에 적용해보는 시간을 가질 수 있어요.
56 |
57 | items:
58 | - title: 8주간의 스터디
59 | icon: event_available
60 | description: 총 8주 동안 진행되며, 매주 1회씩 스터디를 진행해요. 팀별로 정한 시간에 매주 모여서 스터디를 진행해요.
61 |
62 | - title: 스터디 주제
63 | icon: book
64 | description: 차근차근 배울 수 있는 순서로 멘토들이 주제들을 준비했어요. 각 주제는 이론과 실습으로 구성되어 있어요.
65 |
66 | - title: 진행 방식
67 | icon: group
68 | description: 정해진 주제를 각자 일주일 동안 공부하고 스꾸딩 노션 페이지에 정리해요. 스터디 시간에는 각자 공부한 내용을 공유해요.
69 |
70 | - title: 점진적인 프로젝트
71 | icon: trending_up
72 | description: 스터디를 통해 배운 내용을 실습할 수 있는 미니 프로젝트를 진행해요. 8주동안 이어서 진행되니까, 이전 주차 내용을 놓치지 않도록 꾸준히 따라와주세요.
73 |
74 | - title: 권장 사항
75 | icon: lightbulb
76 | description: 스터디 내용들은 프로그래밍 언어를 하나쯤 배워본 사람들이 따라올 수 있게 준비되어 있어요. 프로그래밍 언어 경험이 없다면, JavaScript를 미리 공부하는 것을 추천해요.
77 |
78 | - title: 궁금한 점이 생기면
79 | icon: help
80 | description: 스터디 중에 궁금한 점이 생기면, Teams 채널에 자유롭게 질문해주세요. 멘토들이 최대한 도와드릴 거예요!
81 |
82 | # Image compare
83 | imageCompare:
84 | enable: false
85 | weight: 30
86 | template: 'image_compare'
87 |
88 | # title: Customise The Lotus Docs Appearance
89 | # subtitle: Much of Lotus Docs' appearance can be customised. Dark mode is optional (enabled by default) and you can choose a Google font that suites you via the config parameters.
90 |
91 | # items:
92 | # - title: Dark Mode
93 | # config:
94 | # {
95 | # startingPoint: 50,
96 | # addCircle: true,
97 | # addCircleBlur: false,
98 | # showLabels: true,
99 | # labelOptions: { before: 'Dark', after: 'Light', onHover: false }
100 | # }
101 | # imagePath: 'images/screenshots'
102 | # imageBefore: 'lotusdocs_dark_v0.8.webp'
103 | # imageAfter: 'lotusdocs_light_v0.8.webp'
104 |
105 | # - title: Custom Fonts
106 | # config:
107 | # {
108 | # controlColor: '#3C4257',
109 | # startingPoint: 25,
110 | # addCircle: true,
111 | # addCircleBlur: false,
112 | # showLabels: true,
113 | # labelOptions: { before: 'Inter', after: 'Life Saver', onHover: false }
114 | # }
115 | # imagePath: 'images/screenshots'
116 | # imageBefore: 'lotusdocs_google_font_demo_inter_screenshot.webp'
117 | # imageAfter: 'lotusdocs_google_font_demo_lifesavers_screenshot.webp'
118 |
119 | # - title: Accent Color
120 | # config:
121 | # {
122 | # startingPoint: 25,
123 | # addCircle: true,
124 | # addCircleBlur: true,
125 | # showLabels: true,
126 | # labelOptions: { before: 'Blue', after: 'Cardinal', onHover: false }
127 | # }
128 | # imagePath: 'images/screenshots'
129 | # imageBefore: 'lotusdocs_blue_theme_colour.webp'
130 | # imageAfter: 'lotusdocs_cardinal_theme_colour.webp'
131 |
--------------------------------------------------------------------------------
/content/docs/frontend/1. HTML, CSS.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "1. HTML, CSS"
3 | description = "HTML, CSS에 대해 알아봅시다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 210
8 | +++
9 |
10 | {{< figure src="../images/frontend-roadmap.png" alt="로드맵" >}}
11 |
12 | > ref. [frontend roadmap (beginner version) - roadmap.sh](https://roadmap.sh/frontend?r=frontend-beginner)
13 |
14 | HTML, CSS는 프론트엔드 개발의 기초이예요! 해당 내용들을 잘 이해하지 않고 넘어가면 나중에 큰 어려움을 겪을 수 있어요. 양이 많지만 꼭 시간 투자를 아낌없이 해서 이해하고 넘어가 보아요! 😄
15 |
16 | ## 공부할 내용 📚
17 |
18 | 여러분의 공부를 돕기 위해 준비한 자료들이에요. 따라서 꼭 준비된 자료만 공부할 필요는 없어요! 자신만의 방식으로 공부하고 과제만 잘 수행하면 돼요! 😄
19 |
20 | ### HTML
21 |
22 | HTML은 "프로그래밍 언어"가 아닌 마크업 언어로 웹 페이지의 구조를 정의하는 언어에요. 여러분이 브라우저 주소창에 "skku.edu"를 입력해서 서버에 요청을 보내면 가장 먼저 받는 파일이 HTML 문법으로 작성된 파일이에요. 즉 웹의 시작이니 정말 중요하겠죠!
23 |
24 | - [HTML 100초 소개](https://www.youtube.com/watch?v=ok-plXXHlWw&ab_channel=Fireship)
25 | - HTML이 무엇인지, 왜 중요한지 100초만에 알려줘요!
26 | - [생활코딩 HTML 강의](https://opentutorials.org/course/2039)
27 | - 정보로서의 HTML 이전까지의 내용은 필수! 이후 내용은 선택!
28 | - [HTML 시작하기 - MDN](https://developer.mozilla.org/ko/docs/Learn/HTML/Introduction_to_HTML/Getting_started)
29 | - [HTML reference - MDN](https://developer.mozilla.org/ko/docs/Web/HTML)
30 | - HTML 요소들에 대한 설명이 잘 되어있어요. 필요할 때 참고하면 좋아요!
31 |
32 | 모든 태그를 외울 필요는 없어요! 필요할 때 구글링을 통해 찾아보면 돼요! 😄 다만 대충 어떤 태그가 있는지는 알아두면 좋아요!
33 |
34 | ### CSS
35 |
36 | HTML에서 구조화를 잘했지만 아직은 단순히 문서일 뿐이에요. CSS는 HTML 문서를 꾸며주는 역할을 해요. CSS를 잘 이해하고 사용하면 웹 페이지를 성능적으로도, 디자인적으로도 더욱 효과적으로 만들 수 있어요!
37 |
38 | - [CSS 100초 소개](https://www.youtube.com/watch?v=OEV8gMkCHXQ&ab_channel=Fireship)
39 | - CSS가 무엇인지, 왜 중요한지 100초만에 알려줘요!
40 | - [생활코딩 CSS 강의](https://opentutorials.org/course/2418)
41 | - 레이아웃까지의 내용은 필수! 이후 내용은 선택!
42 |
43 | ---
44 |
45 | ### 중요 🫣
46 |
47 | - [Flex - 정리 영상](https://youtu.be/7neASrWEFEM?si=U2LohIYVtd_pqLCh)
48 | - Flex에 대해서 정리해놓은 영상이에요!
49 | - [Flex - 1분코딩](https://studiomeal.com/archives/197)
50 | - Flex는 CSS의 레이아웃을 잡는 속성이에요. 정말 중요하니 꼭 공부해 보세요!
51 | - [Grid - 정리 영상](https://www.youtube.com/watch?v=nxi1EXmPHRs)
52 | - Grid에 대해서 정리해놓은 영상이에요!
53 | - [Grid- 1분코딩](https://studiomeal.com/archives/533)
54 | - Grid는 Flex와 비슷한 레이아웃을 잡는 속성이에요. 정말 중요하니 꼭 공부해 보세요!
55 |
56 | ---
57 |
58 | - [CSS 시작하기 - MDN](https://developer.mozilla.org/ko/docs/Learn/CSS/First_steps)
59 | - [CSS reference - MDN](https://developer.mozilla.org/ko/docs/Web/CSS)
60 | - [Flexbox froggy](https://flexboxfroggy.com/) (optional)
61 | - 재미있게 Flex를 공부할 수 있는 게임이에요!
62 | 레이아웃을 짜는 flex와 grid는 정말 중요한 내용이에요! 꼭 공부하고 넘어가세요! 최소한 flex라도 꼭 잘 이해하고 넘어가야 해요!
63 |
64 | ## 프로젝트 실습 📝
65 |
66 | 매주 배운 내용을 복습 및 활용하기 위해 프로젝트를 진행해요. 저희가 준비한 프로젝트는 아래와 같아요.
67 |
68 | {{< figure src="../images/week3-main.png" alt="메인 페이지" >}}
69 | {{< figure src="../images/week3-detail.png" alt="디테일 페이지" >}}
70 |
71 | 위와 같이 **포켓몬 도감(?) 사이트**를 만드는 것이 이번 스터디 프로젝트에요.
72 |
73 | 포켓몬 도감 사이트는 메인 페이지와 디테일 페이지로 구성되어 있어요. **메인 페이지에서는 포켓몬의 이름, 이미지, 간단한 정보를 보여주고 디테일 페이지에서는 포켓몬의 이름, 이미지, 상세 정보**을 보여줘요.
74 |
75 | 이번 주는 **HTML, CSS만을 사용해서 메인 페이지 하나와 디테일 페이지 10개**를 만드는 것이 목표예요!
76 |
77 | 깃과 깃헙을 반드시 사용해서 프로젝트를 관리해주시고 프로젝트를 완성하면 Github Page를 통해 배포해 주세요! 😄 이와 관련된 설명은 [9. Git, Github.md](./9.%20Git,%20Github.md)를 참고해 주세요!
78 |
79 | > 다른 기술 스택을 사용할 줄 알더라도 HTML, CSS만을 사용해서 만들어 보세요! 😄
80 |
81 | ### 프로젝트 실습 Tip 📌
82 |
83 | 몇 가지 팁을 알려드릴게요!
84 |
85 | #### 1. VSCode를 사용해요
86 |
87 | VSCode는 HTML, CSS를 작성하기에 정말 좋은 에디터예요. [VSCode 설치하기](https://code.visualstudio.com/)
88 |
89 | 추가로 [Live Server](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer) VSCode Extension을 사용하면 HTML, CSS를 작성하면서 바로바로 결과를 확인할 수 있어요.
90 |
91 | - [Visual Studio Code 기본 사용법 - 생활코딩](https://www.youtube.com/watch?v=K8qVH8V0VvY&ab_channel=%EC%83%9D%ED%99%9C%EC%BD%94%EB%94%A9)
92 |
93 | #### 2. 프로젝트 구조
94 |
95 | ```text
96 | - 3w : root 폴더
97 | - pokemon
98 | - 1.html : detail 페이지
99 | - 2.html
100 | - 3.html
101 | - ...
102 | - 10.html
103 | - style.css : detail 페이지 공통 CSS 파일
104 | - index.html : 메인 페이지
105 | - style.css : 공통 CSS 파일
106 | - reset.css : CSS 초기화 파일
107 | ```
108 |
109 | 본인이 원하는 구조로 프로젝트를 구성해도 괜찮아요!
110 |
111 | #### 3. 데모 사이트 분석
112 |
113 | 매주 [데모 사이트](https://dayongkr.github.io/skkuding-fe-study/3w/)를 제공할 거예요. 데모 사이트를 분석해서 어떻게 만들어야 할지 참고해 보세요!
114 |
115 | {{< figure src="../images/week3-devtool.png" alt="데모 사이트 분석" >}}
116 |
117 | 처음에는 그냥 외관만 보고 따라 만들다가 막히는 경우 위 사진과 같이 개발자 도구를 통해 분석하면서 만들어 보세요! (사진 링크도 개발자 도구 참고해서 얻을 수 있습니다!)
118 |
119 | - [개발자 도구 사용법 - 생활코딩](https://www.youtube.com/watch?v=2Sp9rGmQsBA&list=PLuHgQVnccGMB-cpwPv6dIcvW6DnZzWM4f)
120 | - 맥 개발자 도구 창 열기 : command + option + i
121 | - 윈도우 개발자 도구 창 열기 : F12
122 |
123 | ---
124 |
125 | 질문, 토론은 언제나 환영입니다🤗
126 |
--------------------------------------------------------------------------------
/content/docs/backend/4. TypeScript.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "4. TypeScript"
3 | description = "JavaScript의 확장판인 TypeScript에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2023-09-08"
7 | weight = 140
8 | +++
9 |
10 |
11 |
12 | {{< figure src="../../frontend/images/typescript.png" alt="TypeScript" >}}
13 |
14 | > ref. [Learn Typescript from Scratch - Jatin Sharma](https://j471n.in/blogs/ts)
15 |
16 | 2012년 마이크로소프트가 발표한 타입스크립트(TypeScript)는 자바스크립트(JavaScript)를 기반으로 정적 타입 문법을 추가한 프로그래밍 언어입니다.
17 |
18 | 이번 시간에는 JavaScript에서 정적 타입 문법을 추가한 TypeScript에 대해서 알아봅시다.
19 |
20 | ## 공부할 내용 📚
21 |
22 | ### 1. Why TypeScript?
23 |
24 | 우리는 왜 JavaScript 대신 TypeScript를 공부해야될까요?
25 |
26 | TypeScript의 특성상 JavaScript로 변환하는 컴파일 과정을 거쳐야하는데, 이런 수고를 하면서까지 TypeScript를 사용해야할 이유가 있을까요?
27 |
28 | 그 이유에 대해 알아봅시다. (이 부분은 분량이 짧으니 간단하게만 살펴봐주세요!)
29 |
30 | - [Why TypeScript?](https://joshua1988.github.io/ts/why-ts.html) : 타입스크립트 핸드북 중 'Why TypeScript?' 파트를 가져왔습니다.
31 | - [TypeScript는 어떻게 공부해야 하나요?](https://yozm.wishket.com/magazine/detail/1376/) : TypeScript의 탄생배경, 단점과 그 극복과정, 공부하는 방법 등 자세하게 나와있어서 참고하기에 좋은 것 같습니다.
32 |
33 | ### 2. TypeScript를 배워볼까요
34 |
35 | 이제 왜 TypeScript를 배워야하는지도 알았으니, 공부해볼 단계입니다!
36 |
37 | TypeScript는 앞서 살펴보았듯이 JavaScript에 정적 타입을 입힌 언어이기 때문에, 새로운 언어를 공부한다는 부담감을 가질 필요 없이 JavaScript의 확장판을 배운다는 느낌으로 공부하시면 더 편할 것 같습니다.
38 |
39 | - [TypeScript 핸드북](https://joshua1988.github.io/ts/) : TypeScript에 대해서 잘 정리해놓은 문서입니다.
40 | - 목차 중에서 **Fundamentals** 부분만 보시면 될 것 같습니다.
41 | - [TypeScript Playground](https://www.typescriptlang.org/play) : TypeScript를 직접 실행시켜볼 수 있는 공간입니다.
42 | - [TypeScript 공식문서](https://www.typescriptlang.org/docs/handbook/utility-types.html) : 영어로 되어있기 때문에 필요한 부분만 그때그때 찾아보는 것을 권장합니다.
43 |
44 | ## 프로젝트 실습 🎈
45 |
46 | 이번 주차는 저번 주차에서 만들었던 javascript 코드를 typescript 코드로 변환해볼 예정입니다. 실습 이전에 아래 환경설정 단계를 따라서 진행해주세요.
47 |
48 | ### 환경설정 ⚙️
49 | - 저번 주차와 같이 `npm init`을 해준 뒤, `npm install --save-dev typescript @types/node @types/express`를 통해 TypeScript 관련 모듈을 설치해줍니다.
50 | - 자바스크립트로 만들어진 써드 파티 라이브러리를 타입스크립트에서 사용하려면 각 기능에 대한 타입이 정의되어 있어야 합니다. 이러한 역할을 해주는 라이브러리가 `@types` 라이브러리입니다.
51 | - 타입스크립트 설정파일인 `tsconfig.json`을 추가해줍니다. (`tsc -init`을 통해 추가해줄 수도 있습니다.)
52 | - 다양한 옵션이 존재하는데, 자세한 내용은 [컴파일 옵션(다양한 옵션에 대해 한국어로 자세히 설명해줍니다.)](https://yamoo9.gitbook.io/typescript/cli-env/tsconfig), [TypeScript TsConfig Reference](https://www.typescriptlang.org/tsconfig)를 확인하시면 도움이 되실 겁니다.
53 | - 설정파일은 기본적으로 마음대로 설정하셔도 괜찮습니다. 다양한 옵션들을 설정해보며 어떻게 컴파일이 되는지 이해해보시면 좋을 것 같아요. 밑에 예시 `tsconfig.json`을 남겨두니 참고하세요!
54 | ```json
55 | {
56 | "compilerOptions": {
57 | "strict": true,
58 | "module": "commonjs",
59 | "declaration": true,
60 | "removeComments": true,
61 | "allowSyntheticDefaultImports": true,
62 | "esModuleInterop": true,
63 | "target": "ES6",
64 | "sourceMap": true,
65 | "outDir": "./dist",
66 | "baseUrl": "./src",
67 | "incremental": true,
68 |
69 | "noImplicitAny": true,
70 | "strictNullChecks": true,
71 | "strictFunctionTypes": true,
72 | },
73 | "exclude": ["node_modules", "test", "dist", "**/*spec.ts"],
74 |
75 | }
76 | ```
77 | - 위와 같이 `tsconfig.json`을 설정해주시고 빌드하시게 되면 밑 사진과 같이 `dist`폴더가 생성되며 안에 변환된 파일이 위치하게 됩니다. (밑 사진은 참고용으로 폴더 구조를 그대로 따라하지 않으셔도 괜찮습니다.)
78 |
79 |
80 |
81 |
82 | - 저번 주차에 만들었던 `.js` 파일들을 모두 위 사진처럼 `.ts` 파일로 수정해주세요.
83 | - 그리고 `tsconfig.json` 파일에서 밑의 설정들을 추가해주세요. (타입 체크를 엄격하는 하는 것과 관련한 설정들입니다.)
84 | ```json
85 | {
86 | "strict": true,
87 | "strictNullChecks": true,
88 | "strictFunctionTypes": true,
89 | "strictBindCallApply": true,
90 | "strictPropertyInitialization": true,
91 | "noImplicitThis": true,
92 | "alwaysStrict": true,
93 | }
94 | ```
95 | - 그럼, 이제 파일에서 빨간 줄이 뜰겁니다. 이 에러들을 고쳐나가보세요.
96 |
97 | - 마지막으로, 실행은 `package.json`의 `scripts` 부분에 밑의 명령어를 추가해줍시다.
98 | ```json
99 | {
100 | "start": "node dist/app.js",
101 | "build": "npx tsc"
102 | }
103 | ```
104 | - `build`는 타입스크립트 파일을 자바스크립트로 변환하고, `start`는 이렇게 변환한 자바스크립트 파일을 실행합니다.
105 |
106 | - `ts` 환경에서 `json` 파일을 이용하는 것이 번거로울 수도 있어서(경로 문제 때문에..) 밑의 파일과 같이 선언해주셔도 됩니다.
107 | - `json` 파일은 field를 추가하는 등 자유롭게 변형해주셔도 괜찮습니다.
108 | ```typescript
109 | export interface Restaurant {
110 | // ??
111 | };
112 |
113 | export const Restaurants: Restaurant[] = [
114 | // 해당 파일을 넣어주시면 됩니다.
115 | ]
116 |
117 | ```
118 |
--------------------------------------------------------------------------------
/content/docs/plan/6. IA, Flow Chart.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "6. IA, Flow Chart"
3 | description = "서비스의 정보 구조와 흐름을 만들어요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 460
8 | +++
9 |
10 | ## 📑 **이번 주 학습 내용**
11 |
12 | 이번 주는 기획을 실제 서비스로 만들기 위한 뼈대를 만드는 일을 배워볼게요.
13 |
14 | 과제가 조금 많을 수도 있지만, 프로젝트를 위해 반드시 익히고 넘어가야 하니 잘 따라와 주세요! 💪
15 |
16 | 💫 **Keyword**: IA, Flow Chart
17 |
18 | ---
19 |
20 | ### IA가 무엇인가요?
21 |
22 | IA는 Information Architecture의 약자로, 서비스의 정보 구조도를 의미해요.
23 |
24 | IA를 잘 설계하면 디자이너와 개발자가 서비스의 기능이 어떻게 묶여 있는지, 어떤 경로를 통해 접근할 수 있는 지 등을 쉽게 파악할 수 있어요!
25 |
26 |
27 |
28 | [웹, 모바일을 위한 I.A](https://plavement.tistory.com/27) 👉 IA를 전반적으로 쉽게 설명한 글이에요.
29 |
30 | ### IA를 그리는 두 가지 방법
31 |
32 | 1. 앞서 살펴본 바와 같이, 메뉴 트리 형식으로 IA를 작성할 수 있어요.
33 |
34 |
35 | 메뉴 트리 형식 IA는 정보의 구조를 매우 간단하게 표현할 수 있고 Depth를 줄일 수 있다는 장점이 있지만, 복잡한 내용까지 정리하는 데에는 한계가 있어요.
36 |
37 | 3. 아래 이미지처럼, 엑셀 형식으로도 IA를 작성할 수 있어요.
38 |
39 |
40 | 엑셀 형식 IA는 정보의 상하위 구조를 한 눈에 확인하기는 다소 어려움이 있지만, 각 페이지의 기능과 정책, 요구 사항 등을 더욱 상세하게 정리할 수 있다는 장점이 있어요!
41 |
42 | [IA는 어떻게 쓰는 것이 맞을까](https://habwa.tistory.com/entry/IA%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%93%B0%EB%8A%94-%EA%B2%83%EC%9D%B4-%EB%A7%9E%EC%9D%84%EA%B9%8C) 👉 엑셀 형식 IA의 장점을 설명한 글이에요.
43 |
44 | ‘어떤 것이 맞는 형태인지’에 대한 답은 없어요. 다만, 디자이너와 개발자가 이해하기 편한 형태로 작성하는 것이 중요하겠죠? 😉
45 |
46 | [신입디자이너를 위한 IA 알아보기](https://story.pxd.co.kr/1600) 👉 IA를 작성하는 방법을 간단하게 설명한 글이에요.
47 |
48 | 처음 IA를 설계하는 건 막막하고, 어려울 수도 있어요. 그러니, 기존 서비스의 IA를 먼저 그려본 후에 새로운 서비스의 IA를 그려보기를 추천해요!
49 |
50 | ---
51 |
52 | ### Flow Chart가 무엇인가요?
53 |
54 | Flow Chart는 ‘순서도’, ‘흐름도’라고도 말해요.
55 |
56 | 서비스의 전체 프로세스가 어떻게 작동하는지 파악할 수 있는 다이어그램이죠!
57 |
58 | 특히, 상세한 기획을 하기 전에 서비스의 여러 가지 케이스를 누락 없이 챙길 수 있다는 점에서 매우 중요한 작업이에요 👍
59 |
60 | [서비스 기획자라면 꼭 알아야 하는 서비스 IA 활용 방법!](https://zero-base.co.kr/event/media_insight_contents_PM_IA) 👉 IA와 플로우 차트를 비교하여 설명한 글이에요.
61 |
62 | 코드당의 ‘로그인’ 기능을 예시로 플로우 차트를 더 자세히 알아볼까요? 😊
63 |
64 |
65 |
66 | 사용자가 ID와 비밀번호를 입력하고, 로그인 버튼을 누르면 로그인이 되는, 비교적 간단한 프로세스예요.
67 |
68 |
69 |
70 | 플로우 차트를 처음 그려보면, 이렇게 그릴 수 있을 거예요. 물론 이것도 좋은 플로우 차트예요! 전체 프로세스를 한 눈에 파악하는 데에 용이해 보여요.
71 |
72 | 하지만 플로우 차트를 조금 더 고도화하기 위해 다음과 같은 질문을 던지면 좋아요.
73 |
74 | - ID, 비밀번호를 잘못 입력하면 어떻게 해야 하지?
75 | - 로그인 성공 시에는 어떤 페이지로 이동해야 하지?
76 |
77 | 위와 같은 질문을 하고 나면, 아래와 같은 플로우 차트를 그릴 수 있어요.
78 |
79 |
80 |
81 | 이처럼 플로우 차트를 그릴 때는 전체적인 흐름을 보는 것도 중요하지만, 서비스의 데이터 처리 과정과 사용자의 흐름을 고려하여 다양한 분기를 표현하고 로직을 세분화하는 작업도 반드시 필요해요 😁
82 |
83 | ### Flow Chart를 그릴 때 지켜야 하는 약속
84 |
85 | 아래 이미지는 플로우 차트를 그릴 때 가장 기본적으로 사용되는 도형들이에요!
86 |
87 |
88 |
89 | 더 많은 기호 규칙이 있을 수 있지만, 조직 및 기획자에 따라서 규칙이 종종 달라지기도 하기 때문에 공통적인 5가지 도형만 알고 있어도 좋아요 😀
90 |
91 | (도형이 아니라 색을 구분하여 플로우 차트의 규칙을 정의하기도 한답니다!)
92 |
93 | 단, 플로우 차트를 보는 다른 팀원도 플로우 차트에 사용된 도형/색/기호가 어떤 것을 의미하는지 알 수 있도록 규칙을 명시해 두는 게 좋겠죠? 😉
94 |
95 | [플로우 차트(Flow Chart) 그리](https://elevatorlaboratory.tistory.com/225) 👉 더 많은 기호 규칙을 알고 싶다면 참고해 보세요!
96 |
97 |
98 |
99 | 피그마에서 ‘FigJam board’를 만들면 기본적인 도형 툴을 쉽게 꺼내서 사용할 수 있어요!
100 |
101 | 빠르게 플로우 차트를 그리고 싶다면, 피그잼을 활용해 보는 것도 좋아요 😄
102 |
103 | (Miro 등에서도 플로우 차트의 도형들을 제공하고 있지만, 현재 스꾸딩에서 사용하고 있는 협업 툴이 아니어서 제외했어요. 되도록 피그마와 많이 친해져 주세요!)
104 |
105 | ---
106 |
107 |
108 | ## ✏️ **과제 안내**
109 |
110 | 6주차부터 Figma를 사용해서 과제를 진행해야 해요.
111 |
112 | 1. 피그마의 기초 사용 방법을 모른다면, 아래 강의를 참고하며 피그마 사용 방법을 익혀주세요.
113 |
114 | [피그마 입문 인프런 오리지널 2024](https://www.inflearn.com/course/%ED%94%BC%EA%B7%B8%EB%A7%88-%EC%9E%85%EB%AC%B8-%EC%9D%B8%ED%94%84%EB%9F%B0-%EC%98%A4%EB%A6%AC%EC%A7%80%EB%84%90-2024)
115 |
116 | (섹션 3의 38강까지만 들어도 충분해요! 어려운 툴이 아니니, 강의에 의존하기 보다는 직접 이것저것 만져보며 기능을 익히는 편이 더 좋아요.)
117 |
118 | 2. 피그마 혹은 피그잼을 활용해서, 4주차에 구상했던 코드당 개선 아이디어를 구체화하여, IA와 플로우 차트로 그려보세요.
119 | - TIP 1) 기존 코드당의 IA 구조를 그려보는 것부터 시작해 보세요! 😊
120 | - TIP 2) 플로우 차트는 사용자가 메인 화면부터 해당 페이지 혹은 기능까지 도달하는 과정을 그려보세요. 이때, 예외 케이스를 생각하는 것을 잊지 마세요!
121 |
--------------------------------------------------------------------------------
/content/docs/infra/4. AWS: EC2, Network.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "4. AWS: EC2, Network"
3 | description = "클라우드 서비스 AWS의 기본적인 내용과 EC2, 네트워크 서비스를 배워봅니다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 340
8 | +++
9 |
10 |
11 |
12 | AWS(Amazon Web Services)는 클라우드 컴퓨팅 플랫폼으로, 현재 전세계에서 가장 많이 사용되고 있는 클라우드 서비스입니다. Microsoft Azure와 Google Cloud Platform과 함께 세계 3대 클라우드 서비스로 꼽히고 있어요. 이 중에서도 AWS는 가장 오래되었고, 가장 많은 사용자를 보유하고 있습니다. (TMI: FBI에서도 AWS를 사용한다고 해요!) 그래서 다른 서비스들도 AWS를 기준으로 지원하고 있고, AWS를 먼저 배우면 다른 클라우드 서비스도 배우기 쉬워요.
13 |
14 | 이번 시간부터 3주 간 AWS를 활용한 클라우드 서비스를 배워볼 거예요. 이번 시간에는 AWS의 가장 기본적인 서비스인 EC2를 배워보고, EC2를 사용하기 위한 AWS의 네트워크 서비스를 배워볼 거예요.
15 |
16 | ## 공부할 내용 📚
17 |
18 | ### 1. AWS
19 |
20 | 본격적으로 AWS를 사용해보기 전에 AWS란 무엇이고, 어떤 서비스들이 있는지 알아봅니다. 회원가입도 해보고 AWS를 살펴보면서 주의할 점들도 배워봅니다.
21 |
22 | - AWS의 배경과 특징, 제공하는 서비스들을 알아봅니다.
23 | - AWS에 회원가입을 하고, AWS Console에 로그인해봅니다.
24 | - 해킹 예방을 위해 AWS 계정에 MFA(Multi-Factor Authentication)를 설정합니다.
25 | - AWS free tier가 무엇인지 **간단하게** 알아봅니다.
26 |
27 | #### 참고 자료
28 |
29 | - **[44BITS "아마존 웹 서비스(AWS, Amazon Web Serivces)란?"](https://www.44bits.io/ko/keyword/amazon-web-service)**: AWS의 개요와 특징, 주요 서비스들을 설명합니다. 나열식으로 정리되어있어서 분량이 많은데, '이런 서비스가 있다!' 느낌으로 참고하세요. 차차 공부할 내용들이니, 전부 알 필요는 없어요.
30 | - **[AWS Console](https://console.aws.amazon.com/console/home)**: AWS에 회원가입하고, AWS Console에 로그인해봅니다.
31 | - **[아마존 웹 서비스 AWS 2단계 인증 활성화하는 방법](https://www.lainyzine.com/ko/article/how-to-enable-multi-factor-authentication-on-amazon-web-service/)**: AWS 계정에 MFA를 설정하는 방법을 설명합니다.
32 |
33 | {{< alert context="danger" text="AWS 계정을 소중하게 다뤄주세요! AWS 계정이 해킹되면 순식간에 수천만원이 과금될 수 있습니다. MFA 설정을 꼭 해주시고, 각종 secret과 token이 외부에 노출되지 않도록 각별히 유의해주세요. **(GitHub에 절대 올리면 안 돼요!)**" />}}
34 |
35 | {{< alert context="warning" text="앞으로 AWS 실습하면서 최대한 free tier 한도 내에서 실습하겠지만, 일부 실습은 소정의 요금이 발생할 수 있습니다. 요금이 발생할 수 있는 실습은 주의해서 진행해주세요!" />}}
36 |
37 | ### 2. Amazon EC2
38 |
39 | AWS의 가장 기본 서비스라고 할 수 있는 EC2를 사용해봅니다. EC2는 가상 머신을 대여해준다고 생각하면 됩니다. EC2를 사용하면 가상 머신을 빠르게 생성하고, 삭제하고, 관리할 수 있습니다.
40 |
41 | - EC2의 개념과 특징을 알아봅니다. (instance type, 구매 옵션, life cycle)
42 | - EC2 인스턴스를 생성하고 접속해봅니다. (t3.micro 추천 -> 프리티어 한도 내에서 사용해봅시다.)
43 | - Security Group이 무엇인지 알아보고, SSH로 접속할 수 있도록 포트를 설정합니다.
44 | - Instance Connect와 SSH로 EC2에 접속해봅니다. (두 방법 각각 해보세요!)
45 | - Elastic IP가 무엇인지 알아봅니다. **(실습하면서 과금이 많이 되는 부분이라 과금 정책 확인해주세요!)**
46 |
47 | #### 참고 자료
48 |
49 | - **["AWS EC2 개념 정리" (글)](https://velog.io/@server30sopt/AWS-EC2-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%AC)**: EC2의 다양한 개념들이 정리되어있습니다.
50 | - **[생활코딩 "AWS - EC2 기본 사용법" (약 15분)](https://youtu.be/Pv2yDJ2NKQA?si=QaQlK6SNN_hZ03Cx)**: EC2를 세팅해보는 실습 영상입니다. 영상의 UI가 최신이 아니라서 실제 UI와 좀 다를 수 있지만 감안하면서 따라해보세요.
51 | - **["EIP(탄력적 IP) 개념 & 사용 세팅 정리" (글)](https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-%ED%83%84%EB%A0%A5%EC%A0%81-IP-Elastic-IP-EIP-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80)**: Elastic IP의 개념과 사용 방법을 정리한 글입니다.
52 |
53 | {{< alert icon="💡" text="TIP: 아래 링크에서 EC2 instance type을 쉽게 비교해볼 수 있어요. https://instances.vantage.sh" />}}
54 |
55 | ### 3. AWS Network
56 |
57 | AWS에는 다양한 네트워크 설정이 있습니다. 너무 방대해서 내용을 모두 다루기는 어렵고, 기초적인 내용만 다루어봅니다.
58 |
59 | - Region과 Availability Zone(가용 영역)이 무엇인지 알아봅니다.
60 | - Amazon VPC 서비스의 개념과 subnet, route table, internet gateway에 대해 알아봅니다.
61 |
62 | #### 참고 자료
63 |
64 | - **[갓대희 "리전(지역)과 가용영역(Availability Zone)" (글)](https://goddaehee.tistory.com/178)**: AWS의 리전과 가용 영역의 개념과 use case를 설명한 글입니다.
65 | - **[Inpa Dev "VPC 개념 & 사용" (글)](https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-VPC-%EC%82%AC%EC%9A%A9-%EC%84%9C%EB%B8%8C%EB%84%B7-%EC%9D%B8%ED%84%B0%EB%84%B7-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4-NAT-%EB%B3%B4%EC%95%88%EA%B7%B8%EB%A3%B9-NACL-Bastion-Host)**: VPC와 subnet, routing table, internet gateway를 설명하고 직접 구성해봅니다.
66 |
67 | #### 더 공부해보면 좋을 개념(선택)
68 | VPC는 AWS에서 중요하면서도 꽤 어려운 내용이에요. 아래 영상에서 VPC를 잘 설명하고 있으니, 관심이 있다면 한 번 보세요. (약 46분)
69 | https://youtu.be/R1UWYQYTPKo?si=RzDLMDB2E2ulDJRi
70 |
71 | ## 프로젝트 실습 🎈
72 |
73 | 지난 주에 세팅했던 Docker container들을 EC2에 올려서 배포해볼 거예요! EC2에 Docker를 설치하고, Docker container를 구성한 다음, 휴대폰에서 EC2의 public IP로 접속해보세요.
74 |
75 | ```mermaid
76 | flowchart LR
77 | subgraph Amazon EC2
78 | subgraph Docker Compose
79 | Nginx -- localhost:3000 --> Node.js
80 | end
81 | end
82 | Client -- http://[domain-name] --> Nginx
83 | ```
84 |
85 | - Nginx container에서 listen하는 port를 80번(HTTP)으로 변경해주세요.
86 | - Linux에 Docker를 설치할 때 아래 script를 이용하면 쉽게 설치할 수 있어요. (amazon linux를 사용중이시라면 yum install docker 을 사용해주세요!)
87 |
88 | ```sh
89 | curl -fsSL https://get.docker.com | sudo sh -
90 | ```
91 |
92 | - 설치 이후에 Docker를 사용하기 위해서는 root 권한이 필요합니다. root 권한 없이 Docker를 사용하려면 다음 링크를 참고해서 Docker 그룹에 현재 사용자를 추가해주세요. https://docs.docker.com/engine/install/linux-postinstall/
93 | - Elastic IP로 고정 IP를 할당해보세요.
94 | - [도메인 등록 가이드](Free%20Domain.md)에 따라 무료 도메인(.tech)를 발급받아 Elastic IP를 등록해보세요.
95 |
96 | {{< alert text="브라우저에 IP 주소나 도메인을 입력하면 기본적으로 HTTPS 연결을 시도합니다. HTTPS 연결을 위해서는 SSL 인증서가 필요한데, 이번 실습에서는 SSL 인증서를 발급받지 않고 HTTP로만 연결합니다. 반드시 앞에 `http://`를 붙이고 접속을 시도해주세요!" />}}
97 |
98 | > **Challenge! 🔥 (선택)**
99 | > EC2를 VPC 내부에 구성하고, internet gateway로 외부와 통신할 수 있도록 설정해보세요.
100 |
--------------------------------------------------------------------------------
/content/docs/infra/1. Node.js.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "1. Node.js"
3 | description = "Javascript와 Node.js에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-05"
6 | lastmod = "2023-10-19"
7 | weight = 310
8 | +++
9 |
10 | 스꾸딩에서 가장 많이 사용하는 언어는 JavaScript입니다. JavaScript는 웹 브라우저에서 동작하는 언어로 시작했지만, Node.js를 통해 서버에서도 동작할 수 있게 되었습니다. Node.js는 서버에서 JavaScript를 읽고 실행할 수 있게 해주는 런타임입니다.
11 |
12 | 이번 주에는 JavaScript의 문법을 공부하고, Node.js를 통해 간단한 서버용 프로그램을 만들어보는 것을 목표로 합니다.
13 |
14 | **아래의 모든 자료는 참고 자료일 뿐이고, 자유롭게 검색해서 공부하셔도 됩니다! 😎**
15 |
16 | ## 공부할 내용 📚
17 |
18 | ### 1. JavaScript & Node.js란?
19 |
20 | JavaScript는 웹 브라우저에서 동작하는 언어로, 원래 프론트엔드에서 많이 쓰이는 언어였습니다. Node.js는 서버에서 JavaScript를 동작시킬 수 있게 해주는 런타임으로, Node.js 덕분에 백엔드에서도 JavaScript로 서버 프로그램을 작성할 수 있게 되었습니다.
21 |
22 | JavaScript와 Node.js의 탄생 배경과 특징에 대해 알아봅니다.
23 |
24 | - **드림코딩 "자바스크립트 배우기 전 꼭 봐야할 영상"(약 16분)**: JavaScript의 역사와 특징을 정리한 영상입니다.
25 | https://youtu.be/wcsVjmHrUQg?si=fR4oIIQ_LH-73jEq
26 |
27 | - **코딩애플 "Node.js가 뭔지 알아보자" (약 5분)**: Node.js의 특징을 간단하게 정리한 영상입니다.
28 | https://youtu.be/pTm5E3jcOeY?si=z6zhwPS3GHO35rmu
29 |
30 | - **하나몬 "Node.js 개념 이해하기" (글)**: Node.js의 특징과 원리, 이벤트 루프에 대해 가볍게 정리한 글입니다.
31 | https://hanamon.kr/nodejs-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/
32 |
33 | ### 2. JavaScript 문법
34 |
35 | JavaScript의 문법을 공부합니다. 아래 개념들을 검색하고 정리해보세요. 각종 method들은(`length`, `push` 등) 자세하게 정리할 필요는 없고, 간단하게 어떤 기능을 하는지만 훑어두면 됩니다.
36 |
37 | - 변수 (var, let, const)
38 | - 자료형 (Number, String, Boolean, Array, Object)
39 | - 연산자 (산술 연산자, 비교 연산자, 논리 연산자)
40 | - 조건문 (if)
41 | - 반복문 (for, while)
42 | - 함수 (function, arrow function)
43 | - 객체 (Object)
44 | - 배열 (Array)
45 | - **비동기 (Promise, async/await)** → 중요! 🔥
46 |
47 | 아래는 JavaScript 문법을 공부할 수 있는 관련 자료입니다.
48 |
49 | - **드림코딩 자바스크립트 입문**: 빠르게 코드만 보고 싶은 분들을 위해 문법을 정리한 repo입니다. 더 자세한 설명을 위해서는 유튜브 영상도 참고해주세요.
50 | https://github.com/dream-ellie/learn-javascript
51 | - **코어 자바스크립트**: 분량이 많아 전부 읽는 것은 어렵고, 필요한 부분을 찾아서 읽어보세요. '자바스크립트 기본', '객체: 기본', '자료구조와 자료형', '프라미스와 async, await', '모듈' 정도를 읽어보면 좋을 것 같아요.
52 | https://ko.javascript.info/js
53 | - **"비동기, Promise, async, await 확실하게 이해하기" (글)**: 비동기와 Promise, async/await에 대해 자세하게 정리한 글입니다. 비동기와 Promise, async/await를 정확히 이해하고 싶다면 읽어보세요.
54 | https://springfall.cc/article/2022-11/easy-promise-async-await
55 |
56 | ### 3. Node.js만의 기능
57 |
58 | 웹 브라우저의 JavaScript 런타임에는 없는 Node.js만의 기능들을 알아봅니다. 아래와 같은 내용들을 공부해보세요.
59 |
60 | - os 모듈
61 | - fs 모듈
62 | - path 모듈
63 | - http 모듈
64 |
65 | ## 프로젝트 실습 🎈
66 |
67 | OS 정보를 출력하는 간단한 서버를 만들어봐요. 서버를 실행하고 [http://localhost:3000](http://localhost:3000)에 접속하면 아래 사진처럼 OS 정보가 출력되어야 합니다.
68 |
69 |
70 |
71 |
72 |
73 | - http 모듈로 서버를 만들어보세요. 포트 번호는 3000번으로 지정해주세요.
74 | - Express를 쓰지 않고 http 모듈만으로 구현해보세요. 파일 하나(server.js)면 충분해요!
75 | - HTML 파일은 `assets` 폴더에 있는 `week1.html`을 사용해주세요. [Github 링크](https://github.com/skkuding/cookbook/blob/main/content/docs/infra/assets/week1.html)
76 | - 요청이 오면, HTML 파일을 읽은 다음 `os` 모듈을 사용하여 OS 정보를 읽어서 HTML에 넣어주세요. 예를 들어 `{{type}}` 부분에는 `os.type()`의 결과가 들어가야 합니다. (🔍 힌트: `String.replace`를 써보세요!)
77 |
78 | ## 설치 & 실행 ⚙️
79 |
80 | ### WSL 설치 (윈도우만)
81 |
82 | WSL(Window Subsystem for Linux)은 윈도우에서 리눅스를 실행할 수 있게 해주는 기능입니다. 앞으로 리눅스 명령어를 사용할 일이 많아지기 때문에 WSL을 설치하고 사용하는 것을 추천합니다. 가이드를 참고하여 WSL을 설치해주세요. ([WSL 설치 가이드](Install%20WSL.md))
83 |
84 | ### Visual Studio Code 설치
85 |
86 | Visual Studio Code는 Microsoft에서 만든 텍스트 편집기입니다. 스꾸딩의 개발 환경은 주로 Visual Studio Code를 사용합니다. 아래 링크를 통해 Visual Studio Code를 설치해주세요.
87 | https://code.visualstudio.com/
88 |
89 | {{< figure src="https://code.visualstudio.com/assets/docs/languages/typescript/overview.png" alt="Visual Studio Code" >}}
90 |
91 | ### Node.js 설치
92 |
93 | #### 1. NVM 설치
94 |
95 | nvm은 Node.js의 버전을 관리해주는 도구입니다. 보통 nvm을 통해 Node.js를 설치하고 사용합니다. 아래 명령어를 입력하여 nvm을 설치합니다.
96 |
97 | ```bash
98 | curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
99 | ```
100 |
101 | 이후 터미널을 재시작하거나 아래 명령어를 입력하여 nvm을 사용할 수 있게 합니다.
102 |
103 | ```bash
104 | source ~/.bashrc
105 | # zsh를 사용하는 경우
106 | # source ~/.zshrc
107 | ```
108 |
109 | nvm이 정상적으로 설치되었는지 확인합니다.
110 |
111 | ```bash
112 | nvm --version
113 | # 0.39.5
114 | ```
115 |
116 | 공식 가이드는 아래 링크에 있습니다.
117 | https://github.com/nvm-sh/nvm#install--update-script
118 |
119 | #### 2. Node.js 설치
120 |
121 | nvm을 통해 Node.js를 설치합니다. 아래 명령어를 입력하여 Node.js를 설치합니다.
122 |
123 | ```bash
124 | nvm install --lts
125 | # LTS 버전 대신 최신 버전을 설치하고 싶은 경우
126 | # nvm install node
127 | ```
128 |
129 | Node.js가 정상적으로 설치되었는지 확인합니다.
130 |
131 | ```bash
132 | node --version
133 | # v18.17.1 (버전은 다를 수 있습니다)
134 | ```
135 |
136 | ### JavaScript 실행해보기
137 |
138 | JavaScript는 여러 방법으로 실행할 수 있습니다. 아래 두 가지 방법을 통해 JavaScript를 실행해보세요.
139 |
140 | #### REPL로 실행하기
141 |
142 | 아래 명령어를 입력하여 REPL을 실행합니다.
143 |
144 | ```bash
145 | node
146 | ```
147 |
148 | REPL에서 아래 코드를 입력하고 엔터를 누르면 코드가 실행됩니다.
149 |
150 | ```javascript
151 | console.log('Hello, world!')
152 | // Hello, world!
153 | ```
154 |
155 | #### 파일로 실행하기
156 |
157 | 아래 코드를 `hello.js`라는 이름으로 저장합니다.
158 |
159 | ```javascript
160 | console.log('Hello, world!')
161 | ```
162 |
163 | 아래 명령어를 입력하여 `hello.js`를 실행합니다.
164 |
165 | ```bash
166 | node hello.js
167 | # Hello, world!
168 | ```
169 |
--------------------------------------------------------------------------------
/content/docs/infra/2. Express.js.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "2. Express.js"
3 | description = "웹 프레임워크인 Express.js에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-11"
6 | lastmod = "2023-10-05"
7 | weight = 320
8 | +++
9 |
10 | Express.js는 웹 서버를 만들기 위한 Node.js의 웹 프레임워크입니다. Node.js의 http 모듈로도 웹 서버를 만들 수 있지만, Express.js를 사용하면 더 쉽고 편리하게 만들 수 있습니다.
11 |
12 | 이번 주에는 HTTP, REST 등 네트워크의 기본적인 개념을 배우고, Express.js를 사용하여 웹 서버를 만들어보며 이론을 직접 적용해볼 거예요.
13 |
14 | ## 공부할 내용 📚
15 |
16 | ### 1. 네트워크 이론 (HTTP, TLS, REST)
17 |
18 | 서버와 인프라 구축을 위해 알아야 할 기본적인 지식인 네트워크에 대해 배워봅니다. 네트워크의 내용은 매우 방대하기 때문에, 이번 주에는 HTTP와 SSL, REST에 대해서만 배워보고, 나머지는 추후에 필요할 때 배워보도록 합니다.
19 |
20 | 아래의 개념들을 공부해보세요. 검색으로 찾을 수 있는 자료가 많으니, 자신에게 맞는 자료를 찾아보세요. GPT에게 물어보는 것도 좋은 방법입니다!
21 |
22 | - HTTP의 개념과 흐름, HTTP 메서드, HTTP 상태 코드에 대해 배웁니다.
23 | - HTTP 헤더와 HTTP 쿠키에 대해 배웁니다.
24 | - TLS(SSL)의 개념과 인증서, HTTPS에 대해 배웁니다.
25 | - REST의 개념과 특징, HTTP를 기반으로 한 REST API에 대해 배웁니다.
26 |
27 | > 더 공부해보면 좋을 개념(선택): CORS, JWT
28 |
29 | 직접 자료를 찾아보는 것이 어렵다면, 아래 자료들을 참고해보세요.
30 |
31 | - **[우아한테크 "헌치, 써머의 HTTP" (약 18분)**](https://youtu.be/IjxkKQvn8Bc?si=FXWQT6fR3UtzvyUE)**: 우아한테크코스에서 수강생들이 학습 내용을 공유하는 영상입니다. 전반적인 개념이 이해하기 쉽게 잘 정리되어있습니다.
32 | - **[MDN 문서](https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP)**: 웹의 다양한 개념들이 상세하게 정리된, 매우 유명한 사이트입니다. 설명이 다소 딱딱할 수 있지만, 확실하고 정확한 내용을 찾고 싶을 때 유용합니다.
33 | - **[얄팍한 코딩사전 "HTTPS가 뭐고 왜 쓰나요?" (약 11분)](https://youtu.be/H6lpFRpyl14?si=vzsj-FajZTCp9Vcy)**: HTTPS와 TLS에 대해 쉽게 설명해줍니다.
34 | - **["그림으로 쉽게 보는 HTTPS, SSL, TLS" (글)](https://brunch.co.kr/@swimjiy/47)**: HTTPS와 TLS 조금 더 상세하게 설명한 글입니다.
35 | - **[얄팍한 코딩사전 "REST API가 뭔가요?" (약 7분)](https://youtu.be/iOueE9AXDQQ?si=Q59Rsccs_ZrT9_J9)**: REST에 대해 쉽게 설명해줍니다.
36 | - **[NHN Cloud "REST API 제대로 알고 사용하기"](https://meetup.nhncloud.com/posts/92)**: REST API의 개념을 구체적으로 정리한 글입니다.
37 |
38 | ### 2. Express.js
39 |
40 | Express.js를 이용하면 쉽고 편리하게 웹 서버를 만들 수 있습니다. Express.js를 사용하여 웹 서버를 만들어보고, 앞서 배운 HTTP와 REST를 적용해봅니다.
41 |
42 | Express.js의 다음 개념을 공부해봅니다.
43 |
44 | - Express.js 설치와 실행
45 | - 라우팅
46 | - JSON 형식
47 | - 미들웨어
48 | - 오류 처리
49 |
50 | 아래 자료들 중 원하는 자료를 골라서 공부해보세요. 다른 자료를 찾아봐도 좋아요.
51 |
52 | - **[Express.js 공식 문서](https://expressjs.com/ko/)**: 간결하게 핵심 기능들이 잘 정리되어있습니다. '시작하기'와 '안내서'의 라우팅, 미들웨어, 오류 처리를 공부해보세요.
53 | - **[생활코딩 Express.js 강의](https://opentutorials.org/course/3370)**: 조금 오래되었지만 인기 있는 강의입니다.
54 |
55 | ### 3. (선택) npm, package.json, 모듈
56 |
57 | 이 내용은 Node.js를 더 알아보고 싶은 분들을 위한 내용입니다. 꼭 공부해야하는 내용은 아니지만, Node.js를 사용하면서 자주 접하게 될 내용이니 관심이 있다면 공부해보세요.
58 |
59 | - 모듈의 개념과 Node.js에서 모듈을 사용하는 방법을 알아봅니다.
60 | - npm CLI의 기본적인 명령어들을 실습해봅니다. (`init`, `install`, `run`, `npx`)
61 | - node_modules, package.json과 package-lock.json의 역할과 구조를 알아봅니다.
62 | - CommonJS와 ESModule의 차이를 알아봅니다.
63 |
64 | > 더 공부해보면 좋을 개념(선택): MonoRepo, pnpm
65 |
66 | 참고할만한 자료들입니다.
67 |
68 | - **[Fireship "JavaScript Modules in 100 Seconds" (약 2분)](https://youtu.be/qgRUr-YUk1Q?si=HMhLnfetlbfIExcN)**: 간결하게 모듈을 설명한 영상입니다. (영어 주의!!)
69 | - **["JavaScript Module System" (글)](https://velog.io/@doondoony/JavaScript-Module-System)**: JavaScript 모듈과 ESM, CommonJS 등에 대해 상세하게 다룬 글입니다.
70 | - **["모듈화와 npm" (글)](https://poiemaweb.com/nodejs-npm)**: npm 기능들을 실행해보며 배울 수 있는 글입니다.
71 | - **["Package.json과 Package-lock.json의 차이를 아시나요?" (글)](https://velog.io/@songyouhyun/Package.json과-Package-lock.json의-차이)**: package.json과 package-lock.json을 이해하기 쉽게 설명한 글입니다.
72 | - **["모듈 내보내기/불러오기 (CommonJS vs ES6)" (글)](https://it-eldorado.tistory.com/92)**: CommonJS와 ES6의 차이를 간단하게 정리한 글입니다.
73 | - **["npm, yarn, pnpm 비교해보기" (글)](https://yceffort.kr/2022/05/npm-vs-yarn-vs-pnpm)**: npm의 대체재인 yarn, pnpm과의 차이를 비교한 글입니다.
74 |
75 | ## 프로젝트 실습 🎈
76 |
77 | 지난 주에 만들었던 웹 페이지에서 API 서버를 분리하여 데이터를 동적으로 전달하는 서버를 만들어봅니다.
78 |
79 | - ES6 import를 사용해보세요. package.json의 `type`을 `module`로 설정해야 합니다. (`import express from 'express'`)
80 | - (선택) nodemon을 설치해 코드가 바뀌면 자동으로 서버가 재시작되도록 해보세요.
81 | - API 응답을 테스트해볼 때, [Postman](https://www.postman.com/)이나 [Hoppscotch](https://hoppscotch.io/) 같은 도구를 사용하는 걸 추천드립니다.
82 | - 아래와 같은 endpoint들을 구현해보세요.
83 |
84 |
85 |
86 | ### `GET /`
87 |
88 | HTML 파일을 수정 없이 그대로 반환합니다. (assets/week2.html)
89 |
90 | ### `POST /api/signup`
91 |
92 | 사용자 정보(아이디, 비밀번호)를 받아서 JSON 파일에 작성합니다. 성공하면 201을 반환합니다.
93 |
94 | #### Request Body
95 |
96 | ```json
97 | {
98 | "username": "test",
99 | "password": "test",
100 | "email": "test@example.com"
101 | }
102 | ```
103 |
104 | ### `POST /api/login`
105 |
106 | 사용자 정보(아이디, 비밀번호)를 받아서 JSON 파일에 작성된 정보와 일치하는지 확인합니다. 일치한다면 200, 일치하지 않는다면 401을 반환합니다.
107 |
108 | #### Request Body
109 |
110 | ```json
111 | {
112 | "username": "test",
113 | "password": "test"
114 | }
115 | ```
116 |
117 | ### `GET /api/users`
118 |
119 | JSON 파일에 저장된 사용자 정보를 읽어서 반환합니다. 비밀번호는 반환하지 않습니다.
120 |
121 | #### Response Body
122 |
123 | ```json
124 | [
125 | {
126 | "username": "test1",
127 | "email": "test1@example.com"
128 | },
129 | {
130 | "username": "test2",
131 | "email": "test2@example.com"
132 | },
133 | {
134 | "username": "test3",
135 | "email": "test3@example.com"
136 | }
137 | ]
138 | ```
139 |
140 | ### `GET /api/os`
141 |
142 | OS 정보를 반환합니다. (`type`, `hostname`, `cpu_num`, `total_mem`)
143 |
144 | #### Response Body
145 |
146 | ```json
147 | {
148 | "type": "Linux",
149 | "hostname": "DESKTOP-123456",
150 | "cpu_num": 8,
151 | "total_mem": "16384 MB"
152 | }
153 | ```
154 |
155 | > **Challenge! 🔥 (선택)**
156 | > 로그인 시 인증 정보를 쿠키로 발급해, 인증 정보가 유효할 때에만 `/api/users`와 `/api/os`를 사용할 수 있도록 해보세요.
157 |
--------------------------------------------------------------------------------
/content/docs/plan/8. QA.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "8. QA"
3 | description = "서비스가 배포되기 전, 문제가 될 상황을 점검해요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 480
8 | +++
9 |
10 | ## 📑 **이번 주 학습 내용**
11 |
12 | 이번 주는 서비스를 프로덕션에 배포하기 전에 구현 사항을 점검하는 방법을 배워 볼게요.
13 |
14 | 프로젝트 전 마지막 스터디네요! 마지막까지 힘내보아요 💪
15 |
16 | 💫 **Keyword**: QA, Testcase
17 |
18 | ---
19 |
20 | ### QA, 그게 뭐예요?
21 |
22 | **QA**는 ‘Quality Assurance’의 약자로, 품질을 보증한다는 의미를 가지고 있어요. 우리가 만든 서비스를 실제 사용자들에게 배포하기 전, 서비스의 품질을 검증하고 보장하기 위한 과정을 거치는 거죠 😀
23 |
24 | QA의 목적은 실제 서비스가 정상적으로 동작하는지 확인하는 것이에요. 이때, 단순히 화면이 깨지거나 에러의 발생 유무만 체크하지는 않아요. 기획자가 정의한 기능, 흐름, 예외 조건 등이 제대로 구현되었는지 관찰하고 사용자가 의도대로 서비스를 이용할 수 있는지 점검하기도 해요.
25 |
26 | [지금은 테스트 기간입니다.](https://www.instagram.com/p/DJAhkwRS-m4/?igsh=MWx2NGR2OWtxcnRzbg%3D%3D&img_index=2) 👉 본격적으로 QA를 알아보기 전, 가볍게 만화 하나 보고 갈까요? 🤗
27 |
28 | [검증은 어떻게 진행될까?](https://www.instagram.com/p/DJkl-aGTTX-/?igsh=MTk5eXJ2dHR3aHFsNw%3D%3D&img_index=11) 👉 실무에서는 QA 엔지니어가 따로 있는 경우도 있어요. 하지만 스꾸딩에서는 QA 전담 팀이 없기 때문에, 대체로 기획자의 몫이 됩니다.
29 |
30 | ### 귀찮아 보이는데… 꼭 해야 하나요?
31 |
32 | 당연하죠! QA는 배포 전 서비스의 완성도를 향상하는 것 뿐만 아니라, 여러 내부 리소스를 줄이는 역할도 한답니다 😉
33 |
34 | 1. QA를 통해 명세에 정의된 **모든 기능과 흐름이 실제 화면에서 똑같이 작동하는지**를 점검할 수 있어요. 이는 단순히 기능의 완성도를 넘어서 사용자 경험, 전체적인 서비스 목표의 달성에도 영향을 줄 수 잇어요.
35 | 2. QA를 거치며 **숨겨진 예외 케이스**를 찾아낼 수도 있어요. 기획이나 개발 과정에서 미처 생각하지 못했던 케이스를 발견하기도 한답니다! 이를 통해 QA의 가장 핵심적인 목적인 서비스의 안전한 동작을 실현할 수 있어요.
36 | 3. QA는 **유지보수의 부담을 완화**해 주기도 해요. 문제가 커지기 전에 문제를 발견하고 해결하는 것이 훨씬 효율적이기 때문이죠! 만약 배포 후 에러를 발견했다면 이후 긴급하게 버그에 대한 핫픽스를 거치고, 다시 배포하는 번거롭고 정신 없는 절차를 거쳐야 할 거예요.
37 | 4. QA를 하다 보면 기획 단계에서는 미처 떠올리지 못한 개선 포인트가 보이기도 해요. 기획자 관점뿐 아니라 사용자 관점에서 테스트해 봄으로써 더 나은 개선 아이디어를 얻을 수도 있어요.
38 |
39 | ### QA 전 준비해야 할 것들이 있나요?
40 |
41 | 원활하고 효율적인 QA를 위해서 준비해야 할 것들이 몇 가지 있어요. 지금부터 하나 씩 알아보도록 해요.
42 |
43 | 1. 구현 완료 사항 확인
44 | - 이전 스터디에서 알아봤 듯이, QA는 스테이지 서버에서 진행돼요. 따라서 QA 전, 이번 스프린트에서 목표했던 기능들이 모두 스테이지 환경에 머지가 되었는지를 미팅을 통해 확인해야 해요.
45 | 2. 주요 시나리오 설계
46 | - 이번 배포에 포함될 기능들을 사용자들이 어떻게 사용하게 될지 생각해 보고, 시나리오를 정리해요. 이때 서비스 혹은 서비스 내 기능의 흐름을 도식화 한 플로우 차트를 유용하게 사용할 수 있어요. 만들어진 시나리오는 QA의 핵심이 될 거예요.
47 |
48 | [테스트 시나리오(Test Scenario) 이해하기](https://rae-gi.tistory.com/83) 👉 시나리오 설계에 대해 조금 더 알아봐요. 기능이 누락되지 않도록, 아티클의 예시보다 더 자세하게 절차를 설계하는 것을 권장해요.
49 |
50 | 3. QA용 계정 생성하기
51 | - 시나리오대로 QA를 위해 특정한 권한을 가진 계정이 필요할 수 있어요. 이를 위해 해당 계정들을 미리 만들어 놓는 작업이 필요해요. 시나리오를 다시 한 번 살펴보며 어떠한 계정들이 필요한지, 같은 권한을 가진 계정이 여러 개 필요하지는 않을지 정리해요. 필요할 경우, 백엔드 팀원과 협업할 수 있어요.
52 | 4. QA Sheet 작성하기
53 | - 마지막으로, 시나리오를 기반으로 여러 가지 검증 조건을 세부적으로 나눈 QA 시트를 작성해요. 이렇게 나누어진 시트의 행 하나하나를 **테스트케이스**라고 말해요. QA 시트의 작성 방법에 대해서는 아래에서 더 자세하게 설명할게요!
54 |
55 | [QA란? 프로젝트 진행 시 QA가 필요한 이유와 개선 사례](https://www.elancer.co.kr/blog/detail/300) 👉 준비부터 실행까지, 전체적인 QA 과정을 훑어봐요.
56 |
57 | ### QA Sheet는 어떻게 작성하나요?
58 |
59 | 스꾸딩에서는 **노션**을 통해 QA 시트를 작성하고 있어요.
60 |
61 |
62 | 각 Column의 역할과 작성 방법에 대해서 알아봐요.
63 |
64 | - **`ID`** : 각 케이스의 고유 번호를 의미해요. '속성 편집’ 기능으로 고유한 접두사를 생성할 수 있어요.
65 | - **`GNB`** : 테스트할 메뉴를 표시해요.
66 | - **`1~3 Depth`** : 페이지에 접근하는 방법을 순서대로 표시해요.
67 | - **`Section`** : 페이지 내 특정 영역을 나타내요.
68 | - **`조건`** : 해당 테스트케이스의 전제 조건을 나타내요. 특정 권한이나 콘텐츠의 상태 등이 포함될 수 있어요.
69 | - **`액션` :** 사용자가 수행할 동작을 명시해요. 클릭, 입력 등과 같은 것들이 액션에 포함돼요. 여러 에러 케이스를 검증하기 위해 일부러 틀린 값을 넣어보거나, 예상 밖의 행동을 할 수도 있어요.
70 | - **`검증조건`** : 사용자가 해당 액션을 수행했을 때 기대되는 결과값을 명시해요.
71 | - **`결과`** : 실제 결과를 나타내요. 검증조건과 결과가 일치하면 `O`, 일치하지 않으면 `X`로 표시해요. 만약, 부분적으로 일치한다면 세모로 표시하기도 해요.
72 | - **`비고`** : 해당 테스트케이스 결과에 대한 설명을 메모해요. 테스트가 검증 조건을 통과했을 경우, 공란으로 남겨도 무방해요.
73 | - **`Task`** : 해당 테스트케이스가 검증조건을 통과하지 못했다면, 바로 task를 만들어 주세요. 만들어진 task는 이 칸에 복사 및 붙여넣기 해 주세요.
74 |
75 | QA 시트를 작성할 때 주의해야 할 점을 함께 알아보아요 😃
76 |
77 | 1. QA 시트는 최대한 자세하게 작성해 주세요. 여러 가지 **분기점, 에러 케이스, 엣지 케이스 등**을 미리 생각해 보고 정리해 보세요!
78 | 2. **하나의 테스트케이스에는 하나의 검증조건만** 넣어주면 좋아요. 이후 결과 표기 및 task 관리에 용이하답니다!
79 | 3. 작성해 둔 **명세서**를 다시 한 번 읽어보면서 QA 시트를 작성해 주세요. QA 시트에 명세해 둔 기능이 미포함되었는지 확인하는 용도이기도 하지만, 명세를 적을 때 미처 생각하지 못했던 엣지 케이스를 QA 시트를 작성하면서 파악할 수도 있어요. 이럴 때는 명세에 해당 내용을 추가하고, 팀원들에게 알려주세요.
80 |
81 | [웹사이트 구축의 마지막 단계, QA를 진행해보자.](https://brunch.co.kr/@yuneuichoi/19) 👉 실무에서는 QA 시트를 어떻게 작성하고 있는지 확인해 봐요. 지금 스꾸딩에서 사용하고 있는 QA 시트 양식을 수정/보완해도 좋을 것 같아요! 😜
82 |
83 | ### QA를 진행할 때 주의해야 할 점이 있나요?
84 |
85 | 1. 가능하다면 오프라인 환경에서 모든 팀원이 함께 진행하는 것을 권장해요. 문제 상황 공유가 훨씬 더 용이해지고, 현장에서 문제 원인을 파악할 수도 있어요.
86 | 2. 만약 온라인으로 QA를 진행하게 된다면, **문제 상황을 재현하는 방법**을 task 설명에 반드시 기록해 주세요.
87 | - 어떠한 경로를 통해 액션을 취했을 때 문제가 발생하는지, 경로를 최대한 자세하게 명시해주세요.
88 | - 어떠한 계정을 사용했을 때 문제가 발생하는지 알려 주세요.
89 | - 어떠한 브라우저를 사용했는지 알려 주세요.
90 | - 매번 동일하게 발생하는지, 특정 상황에서만 발생하는지 알려 주세요.
91 | - 스크린샷이나 영상을 첨부하는 것도 좋아요. 이때, **개발자 도구의 콘솔 창**을 열어둔 상태로 화면 캡처나 영상 녹화를 진행하면 빠른 문제 원인 파악에 매우 큰 도움이 돼요! 😲
92 | 3. **테스트 환경의 차이**를 반드시 확인해 주세요. 간혹, 브라우저나 OS 별로 동작이 다른 경우도 있기 때문이에요. 예를 들어, Windos에서는 정상적으로 작동되지만 Mac에서는 작동이 안 되거나 UX가 불편해지는 경우도 있어요.
93 | 4. QA 시트에 있는 모든 테스트를 마쳤다면, **미운 4살**이 되어보세요. 예를 들어, 문제를 풀고 있다가 갑자기 Settings로 페이지로 이동하는 것처럼요!
94 |
95 | [‘테스트 케이스’로만 테스트하면 안되나요?](https://tech.devsisters.com/posts/not-enough-testcase/) 👉 랜덤한 테스트를 진행해야 하는 이유를 재미있게 설명한 글이에요.
96 |
97 |
98 | [초보 기획자 혹은 PM을 위한 QA 가이드](https://yozm.wishket.com/magazine/detail/1451/) 👉 QA 진행 시 고려해야 할 점을 아티클로 알아봐요.
99 |
100 | ---
101 |
102 | ## ✏️ **과제 안내**
103 |
104 | 이번 주는 **코드당의 ID/PW 찾기 기능 검증**을 위한 QA 시트를 개인 노션에 작성해 보아요! 😊
105 |
106 | - 스쿼드 페이지에 있는 QA 시트를 복사하여 사용해도 되지만, 되도록 시트의 틀부터 만들어 주세요.
107 | - 시트를 작성하기 전, 기능 및 정책 명세서를 반드시 먼저 읽어 보세요!
108 | - 노션 데이터베이스를 활용하는 것에 익숙하지 않다면, 아래 가이드를 먼저 읽어보세요.
109 | - [데이터베이스 생성하기](https://www.notion.com/ko/help/create-a-database) 👉 노션의 공식 가이드 문서예요.
110 | - 데이터베이스는 새 페이지에 `/데이터베이스`를 입력한 후에, `표 보기`를 눌러도 생성할 수 있어요.
111 |
--------------------------------------------------------------------------------
/content/docs/plan/3. User Research.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "3. User Research"
3 | description = "사용자에게 직접 데이터를 얻어 문제를 해결해요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 430
8 | +++
9 |
10 | ## **📑 이번 주 학습 내용**
11 |
12 | User Research는 사용자의 불편함을 해소하는 서비스를 만들기 위해 수행하는 조사예요.
13 |
14 | 이번 주는 사용자의 목소리를 듣고, 그들의 불편함과 필요를 파악하는 방법을 배워볼게요!
15 |
16 | 💫 **Keyword**: 설문조사, 인터뷰, A/B 테스트
17 |
18 | ---
19 |
20 | ### 어떤 사용자에게 데이터를 얻어야 할까?
21 |
22 | 사용자에게 데이터를 얻는 방법은 다양하지만, 어떠한 방법이든 ‘어떤 사용자에게 데이터를 얻을 것인지’ 결정하는 작업은 반드시 필요해요! 이처럼 사용자를 선정하는 과정을 ‘Screening’이라고 말해요.
23 |
24 | [리서치와 꼭 맞는 대상자 선정하기](https://blog.naver.com/uiux_lab/222802018947) 👉 스크리닝을 매우 상세하게 작성한 글이에요.
25 |
26 | 위 글에서는 문제 가설을 바탕으로 Persona를 만들고, 페르소나(퍼소나)를 기반으로 스크리닝을 진행하고 있어요. 페르소나를 설계하는 과정은 다음 주에 더욱 자세히 알아보도록 할게요!
27 |
28 | ### 사용자에게 데이터를 얻는 두 가지 방법
29 |
30 | 데이터는 크게 수치 등으로 측정할 수 있는 ‘정량적 데이터’와 언어나 문자로 표현된 ‘정성적 데이터’로 분류할 수 있어요. 데이터를 수집하는 목적과 리소스 등에 따라 두 가지 데이터를 모두 수집할 수도 있고, 두 가지 데이터 중 하나만 수집할 수도 있어요! 둘 중 더 ‘나은’ 것은 없답니다 😉
31 |
32 | ### 정량적 데이터를 얻는 방법 1 : Survey
33 |
34 | Survey는 미리 구조화되어 있는 설문지를 사용자들에게 배포하여 자료를 수집하고 분석하는 조사 방법이에요.
35 |
36 | 시간과 공간의 제약 없이 많은 사용자를 대상으로, 빠르게 데이터를 확보할 수 있다는 것이 가장 큰 특징이에요! 하지만 사용자의 경험, 행동, 감정 등에 대한 구체적인 맥락을 파악하는 것은 비교적 어려워요.
37 |
38 | **설문조사 설계 및 진행 시 주의 사항**
39 |
40 | - 하나의 질문에 두 가지 이상의 내용을 물어서는 안 돼요!
41 | - 두 가지 이상의 내용을 한 질문에서 모두 물어보면 정확한 값을 측정할 수 없을 뿐더러, 사용자가 답변하는 데에도 혼란을 줄 수 있어요. 예를 들어, ‘피자를 먹는 것과 치킨을 먹는 것을 좋아하십니까?’와 같은 질문은 ‘피자를 먹는 것을 좋아하십니까?’, ‘치킨을 먹는 것을 좋아하십니까?’와 같이 두 개의 질문으로 분리하는 것이 좋아요.
42 | - 사용자가 이해할 수 없는 복잡하고 기술적인 용어는 피해야 해요.
43 | - 질문에 사용되는 문장은 명확해야 해요.
44 | - ‘여러 개’, ‘대다수’, ‘보통’과 같이 모호한 표현은 최대한 피하는 것이 좋아요!
45 | - ‘~하지 않다’와 같이 부정적인 문장으로 질문을 설계하는 것을 피해야 해요.
46 | - 사용자가 실제로 답할 의견과 정반대되는 답을 하는 실수를 할 수 있기 때문이에요. 부득이하게 부정적인 문장을 사용할 경우 ‘~않는’, ‘~하지 않다’와 같은 부정적인 표현에 Bold나 Italic으로 반드시 강조해 주어야 해요!
47 | - 이미 답이 정해졌거나 편향된 질문을 피해야 해요.
48 | - [CX 설계하기: 고객이 끝까지 답하는 설문, 응답률 높이는 5가지 원칙](https://blog.opensurvey.co.kr/research-tips/cx-action-guide-3/) 👉 설문조사의 질을 더 높여보고 싶다면 참고해요!
49 |
50 | ---
51 |
52 | ### 정량적 데이터를 얻어보자 2 : A/B Testing
53 |
54 | A/B Testing은 서비스의 실제 사용자가 될 수 있는 두 집단에 각각 A안과 B안을 제공하고, 이에 대한 결과 차이로 A안과 B안 중 더 나은 쪽을 찾아내는 방법이에요. 서비스를 초기 기획하는 단계보다, 기존 서비스의 UX 등을 개선하고자 할 때 주로 사용돼요.
55 |
56 | **A/B Testing 진행 방법**
57 |
58 | 1. 정량적인 목표 설정
59 | - 기존 A안의 문제점을 분석하고, 어느 정도의 수치를 기록하는 것을 목표로 할지 설정해요. 예를 들어, ‘버튼 클릭을 20%에서 50%로 증가’, ‘메인 페이지의 상품 섹션까지 스크롤 도달률을 10%에서 30%로 증가’ 등으로 설정할 수 있어요.
60 | 2. 문제의 원인 분석하기
61 | - 앞서 알아 본 설문조사와 인터뷰를 이 단계에서도 사용할 수 있어요! 만약 버튼 클릭율이 낮은 것을 문제로 삼았다면, 설문조사나 인터뷰를 통해 사용자가 어떻게 서비스를 사용하고 있는지, 사용자가 서비스를 사용하는 주된 목표는 무엇인지 등을 파악함으로써 문제의 원인을 발굴할 수 있어요.
62 | - 혹은, 사용자에게 일정한 미션을 주고 사용자가 미션을 수행하는 방법을 지켜보는 테스트를 할 수도 있어요! 이러한 테스트를 ‘UT(Usability Test)’라고 말해요.
63 | ['사용성 평가'로 생생한 유저 피드백 수집하기](https://yozm.wishket.com/magazine/detail/2044/) 👉 UT의 진행 방법을 설명한 글이에요.
64 | [사용성 테스트, Maze로 그냥 해보기](https://yozm.wishket.com/magazine/detail/1465/) 👉 대표적인 UT 도구인 ‘Maze’를 사용하는 방법에 대한 글이에요.
65 |
66 | 3. 가설 수립 및 B안 제작하기
67 | - 분석된 원인을 바탕으로 가설을 세우고 B안을 만들어요. 이때, A안과 B안의 차이가 두 가지 이상 존재하지 않도록 주의해야 해요! 두 가지 이상의 차이가 존재하면 정확한 결과 분석이 진행되지 않을 수 있기 때문이에요.
68 | 4. A/B Testing 진행하기
69 | - 사용자의 ID를 기반으로 사용자를 두 가지 그룹으로 나누고 한 그룹에는 A안을, 나머지 하나의 그룹에는 B안을 노출해요. 이러한 방식이 가장 일반적으로 사용되고 있어요.
70 | 5. 결과 비교하기
71 | - A안에 비해 B안에서 사용자의 행동, 지표 등이 어떻게 달라졌는지 파악해요.
72 |
73 | [AB Test 기본부터 심화까지](https://brunch.co.kr/@digitalnative/19) 👉 A/B 테스트의 전반적인 내용을 자세히 설명한 글이에요.
74 | [기업에게 중요한 AB 테스트란? AB 테스트 사례로 알아보기](https://elice.io/ko/newsroom/abtest) 👉 성공적인 A/B 테스트 사례를 담은 글이에요.
75 |
76 | ---
77 |
78 | ### 정성적 데이터를 얻는 방법 : 인터뷰
79 |
80 | 정성적 데이터는 많은 데이터를 빠르게 수집하기는 어렵지만, 사용자의 행동과 감정 등에 대한 맥락을 파악할 수 있다는 점이 장점이에요. 인터뷰는 한 번에 대면하는 사용자의 수에 따라 두 가지 방식으로 나눌 수 있어요.
81 |
82 | **인터뷰 종류**
83 |
84 | 1. In-Depth Interview (IDI)
85 | - 심층 인터뷰라고도 불리는 In-Depth Interview는 사용자와 1:1로 직접 대화하며 서비스를 이용하는 데에 영향을 미치는 요인을 알아내는 방식의 인터뷰예요.
86 | [유저 인터뷰를 5명만 해도 충분하려면](https://brunch.co.kr/@hsso/13) 👉 인터뷰 대상자 선정 과정에 대해 설명한 글이에요. 몇 명의 사용자를 인터뷰하는 것이 좋을지 고민하고 있다면, 읽어보세요!
87 |
88 | 2. Focus Group Interview (FGI)
89 | - Focus Group Interview는 소수의 참여자를 모아 서비스를 주제로 참여자 간 자유롭게 대화를 하도록 주최하고, 그 과정에서 유용한 정보를 얻는 방식의 인터뷰예요. 심층 인터뷰에 비해, 더 많은 사용자의 의견을 한 번에 들을 수 있는 게 가장 큰 장점이에요. 하지만 여러 명의 사용자를 컨트롤하기 쉽지 않기 때문에 진행자의 역할이 매우 중요하게 여겨져요!
90 | [포커스 그룹 인터뷰 진행법](https://brunch.co.kr/@sweetsavasana/41) 👉 FGI 설계부터 진행까지의 과정을 담고 있는 글이에요.
91 |
92 | **인터뷰 진행 시 주의 사항**
93 |
94 | - 2명의 인터뷰어(Interviewer)가 함께 하는 것이 좋아요.
95 | - 한 명은 질문에 집중하고, 한 명은 기록에 집중하는 역할을 담당해요. 인터뷰어가 1명이라면 사용자의 답변을 기록하기 어렵고, 3명 이상이라면 사용자가 인터뷰에 대해 부담감 혹은 거부감을 느낄 수 있기 때문이에요.
96 | - 사용자가 편안한 마음으로 인터뷰에 임할 수 있도록 해야 해요.
97 | - 사용자의 진정성 있는 답변을 얻기 위해, 사용자가 최대한 많은 이야기를 하기 위해 인터뷰 분위기를 편안하게 만드는 것은 매우 중요해요! 인터뷰 전 따뜻한 음료나 작은 간식을 준비하거나, 인터뷰 초반에 가볍게 아이스 브레이킹을 하는 방법도 좋아요.
98 | - 이미 답이 정해졌거나 편향된 질문을 피해야 해요.
99 | - 인터뷰어가 원하는 답변을 유도하면 사용자에게 양질의 답변을 얻기 매우 힘들어요. 같은 맥락에서, ‘일반적으로’, ‘통상적으로’와 같은 표현을 사용하는 것도 피해야 해요.
100 | - 비언어적인 단서에 주목해야 해요.
101 | - 사용자의 말 뿐만 아니라, 답변을 하는 중의 사용자의 눈빛, 표정, 손짓, 심지어 침묵까지도 중요한 자료가 될 수 있어요! 인터뷰를 기록할 때도 이러한 비언어적 표현까지 함께 기록하는 것이 좋아요.
102 | - 사용자가 최대한 많이 말할 수 있도록 유도해야 해요.
103 | - 사용자가 피로를 느끼지 않도록, 인터뷰는 30~60분 사이에서 진행하는 것이 좋아요. 이 시간 동안 최대한 많은 자료를 얻기 위해서 인터뷰어는 최대한 질문을 짧게 구성해야 해요. 사용자의 이야기를 더욱 잘 파악할 수 있도록 “왜?”라는 꼬리 질문을 많이 던지는 방법도 좋아요.
104 |
105 | ---
106 |
107 | ## **✏️ 과제 안내**
108 |
109 | 3주차에는 리서치 대상을 정하고, 정량적 데이터와 정성적 데이터 중 한 가지 데이터의 리서치 방법을 선택해서, 직접 리서치를 설계해 보아요! 🤓
110 |
111 | 1️⃣ 스크리닝을 통해 리서치 대상을 정해요. 여러 가지 페르소나를 고려해봐요!
112 | 2️⃣ 정량적 데이터 리서치(설문조사, A/B Testing), 정성적 데이터 리서치(인터뷰) 방법 세 가지 중 하나를 선택해 설계해 보아요.
113 | 3️⃣ 리서치 설계의 목적은 ‘코드당 서비스의 개선’으로 설정해 주세요. 1주차와 2주차의 과제를 돌아보며 레퍼런스 사이트들과 코드당의 경험을 비교해서 도출된 문제를 기반으로 설계하면 더 의미 있는 과제가 될 것 같아요 😄
114 |
115 | 리서치를 설계하면서 흥미로웠던 점, 어려웠거나 궁금했던 점을 함께 정리해 보세요! 정리한 내용 또한 스터디 시간에 같이 이야기 해 보아요 😉
116 |
--------------------------------------------------------------------------------
/content/docs/infra/7. Terraform.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "7. Terraform"
3 | description = "프로비저닝 도구인 Terraform에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-11-09"
6 | lastmod = "2023-11-09"
7 | weight = 370
8 | +++
9 |
10 | Terraform은 HashiCorp에서 만든 인프라 프로비저닝 도구입니다. Terraform을 사용하면 코드로 인프라를 관리할 수 있어요. 이번 시간에는 IaC(Infrastructure as Code)를 구현할 수 있는 Terraform에 대해 알아보겠습니다.
11 |
12 | ## 공부할 내용 📚
13 |
14 | ### 1. Terraform
15 |
16 | Terraform을 사용하면 코드로 인프라를 관리할 수 있어요. Terraform은 다양한 클라우드 서비스를 지원하고, 다양한 리소스를 관리할 수 있습니다.
17 |
18 | - IaC(Infrastructure as Code)란 무엇인지 알아봐요.
19 | - Terraform이 어떤 도구인지 알아봐요.
20 | - Terraform의 주요 용어를 알아봐요. (Provider, Resource, State)
21 | - Terraform의 주요 명령어를 알아봐요. (init, plan, apply, destroy)
22 |
23 | #### 참고 자료
24 |
25 | - **[44bits "테라폼(Terraform)이란?"](https://www.44bits.io/ko/keyword/terraform)**: Terraform의 배경부터 개념, 튜토리얼까지 정리해놓은 글입니다.
26 | - **[인프런 Terraform & AWS 101 "Terraform 기본"](https://terraform101.inflearn.devopsart.dev/preparation/terraform-basic/)**: Terraform의 용어와 명령어들을 정리한 글입니다.
27 |
28 | ### 2. HCL 문법
29 |
30 | Terraform은 HCL(HashiCorp Configuration Language)이라는 독자적인 언어를 사용해요. HCL은 JSON과 비슷한 문법을 가지고 있어요.
31 |
32 | - HCL의 기본 문법을 알아봐요. (Block, Argument, Expression)
33 | - HCL의 주요 함수를 간략하게 알아봐요. (for_each, lookup, file, templatefile)
34 |
35 | #### 참고 자료
36 |
37 | - **[GeeksForGeeks "Terraform Syntax With Examples"](https://www.geeksforgeeks.org/terraform-syntax-with-examples/)**: HCL의 기본 문법을 정리한 글입니다.
38 | - **[Terraform Functions](https://developer.hashicorp.com/terraform/language/functions)**: HCL의 주요 함수들을 정리한 공식 문서입니다. 아래 내용은 자세히 볼 필요 없고, 각 함수의 예시를 보면서 어떤 함수가 있는지만 확인해주세요.
39 | - **[Terraform for_each Meta-Argument](https://developer.hashicorp.com/terraform/language/meta-arguments/for_each)**
40 | - **[Terraform lookup Function](https://developer.hashicorp.com/terraform/language/functions/lookup)**
41 | - **[Terraform file Function](https://developer.hashicorp.com/terraform/language/functions/file)**
42 | - **[Terraform templatefile Function](https://developer.hashicorp.com/terraform/language/functions/templatefile)**
43 |
44 | ## 프로젝트 실습 🎈
45 |
46 | 그동안 AWS에 구성한 인프라를 Terraform으로 관리해봐요. 다만 일주일 안에 전부 Terraform으로 옮기기엔 양이 너무 많아서 **CloudFront와 S3만** Terraform으로 옮기는 걸로 해요.
47 |
48 | ```mermaid
49 | flowchart LR
50 | subgraph AWS
51 | subgraph EC2
52 | subgraph Kubernetes
53 | Ingress --> Node.js
54 | end
55 | end
56 | ALB -- localhost:3000 --> Ingress
57 | CloudFront -- /api/* --> ALB
58 | CloudFront -- /* --> S3
59 | style CloudFront fill:#ffaa90
60 | style S3 fill:#ffaa90
61 | end
62 | Client -- http://[domain-name] --> CloudFront
63 | ```
64 |
65 | ### AWS CLI를 설치하세요. (AWS의 서비스들을 터미널 명령어만으로 제어할 수 있게 해주는 도구입니다.)
66 |
67 | 1. [공식 가이드](https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html)를 참고해 설치하세요.
68 | 2. 설치가 완료되면, `aws --version` 명령어를 실행해 설치가 잘 되었는지 확인하세요.
69 | 3. Management Console에서 IAM User를 생성하세요. (`AmazonEC2ContainerRegistryFullAccess` 권한 필요)
70 | 4. 생성된 IAM User의 "Security Credentials" 탭에서 access key를 생성하세요. (CLI 모드)
71 | 5. 터미널에서 `aws configure` 명령어를 실행해 access key를 등록하세요.
72 |
73 | ### Terraform을 설치하세요.
74 |
75 | - [Terraform 공식 사이트](https://www.terraform.io/downloads.html)에서 Terraform을 다운받아 설치하세요.
76 | - VSCode에 "HashiCorp Terraform" 확장 프로그램을 설치하세요.
77 |
78 | ### AWS Provider로 S3를 구성하세요.
79 |
80 | {{< alert context="info" text="Terraform을 쓰다보면 문서 볼 일이 아주 많을 거예요. 한 쪽 창은 문서, 다른 쪽 창은 에디터를 띄워놓고 개발하는 걸 추천드립니다. 😺" />}}
81 |
82 | > AWS Provider 공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs
83 |
84 | - [공식 문서 예시](https://registry.terraform.io/providers/hashicorp/aws/latest/docs#example-usage)처럼 파일을 만들어주세요. (예: main.tf) Region은 `ap-northeast-2`로 설정하세요.
85 | - `terraform init` 명령어로 AWS Provider를 설치하세요.
86 | - `terraform plan` 명령어로 AWS에 적용할 내용을 확인하세요.
87 | - `terraform apply` 명령어로 AWS에 적용하세요.
88 | - AWS에 VPC가 잘 생성되었는지 확인하세요. [VPC Console 링크](https://ap-northeast-2.console.aws.amazon.com/vpcconsole/home?region=ap-northeast-2)
89 | - `terraform destroy` 명령어로 AWS에 생성한 리소스를 삭제하세요.
90 |
91 | #### 1️⃣ S3 Bucket을 생성하세요.
92 |
93 | [aws_s3_bucket 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket)를 참고해서 S3 Bucket을 생성하세요.
94 |
95 | #### 2️⃣ S3에 파일을 업로드하세요.
96 |
97 | [aws_s3_object 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_object)를 참고해서 S3에 파일을 업로드하세요.
98 |
99 | - 5주차 실습의 HTML, CSS, JS 파일을 각각 올려주세요.
100 | - content_type을 `text/html`, `text/css`, `application/javascript`로 설정해주세요.
101 | - etag를 설정해주세요. 그래야 파일 내용이 변경됐을 때 다시 업로드할 수 있어요.
102 |
103 | #### 3️⃣ S3 website를 구성하세요.
104 |
105 | [aws_s3_bucket_website_configuration 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_website_configuration)를 참고해서 S3 website를 구성하세요.
106 |
107 | - IAM Policy를 5주차 내용처럼 설졍해주세요. [aws_iam_policy_document 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/iam_policy_document)
108 | - IAM Policy Document를 S3에 연결해주세요. [s3_bucket_policy 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_policy)
109 | - Public Access Block을 해제해주세요. [aws_s3_bucket_public_access_block 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket_public_access_block)
110 | - 웹사이트 접속이 잘 되는지 확인해보세요.
111 |
112 | #### 4️⃣ CloudFront를 생성하세요.
113 |
114 | [aws_cloudfront_distribution 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudfront_distribution)를 참고해서 CloudFront를 생성하세요.
115 |
116 | - 생성에 시간이 좀 걸릴 수 있어요.
117 | - S3 Bucket을 Origin으로 설정해주세요.
118 | - 지난 주차 실습에서 만든 ALB를 data source로 가져와 Origin으로 설정해주세요. [aws_lb 문서](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/lb)
119 | - `default_cache_behavior`에 S3를, `ordered_cache_behavior`에 ALB를 추가해주세요.
120 | - CloudFront 접속이 잘 되는지 확인해보세요.
121 |
--------------------------------------------------------------------------------
/content/docs/infra/5. AWS: S3, IAM.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "5. AWS: S3, IAM"
3 | description = "AWS의 S3와 IAM에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-10-26"
6 | lastmod = "2023-10-26"
7 | weight = 350
8 | +++
9 |
10 | Amazon S3는 AWS에서 제공하는 파일 스토리지 서비스입니다. 작게는 HTML, CSS 같은 웹 사이트 정적 파일을 저장하고, 크게는 수십 테라바이트의 데이터를 저장할 수 있어요.
11 |
12 | IAM은 AWS의 Identity and Access Management의 약자로, AWS의 사용자, 그룹, 권한을 관리하는 서비스입니다. 보안 뿐만 아니라 프로그램의 예상치 못한 동작을 방지하기 위해 IAM을 사용해요.
13 |
14 | ## 공부할 내용 📚
15 |
16 | ### 1. Amazon S3
17 |
18 | Amazon S3의 기본적인 용어들을 알아보고, S3 버킷을 생성하며 관련 설정들을 알아봐요.
19 |
20 | - S3의 개념과 특징을 알아봐요.
21 | - S3의 용어들을 알아봐요. (bucket, object, key, ACL)
22 | - S3 버킷을 생성하고, 버킷에 파일을 업로드해봐요.
23 | - S3의 요금을 알아봐요.
24 | - S3의 버저닝 기능을 알아봐요.
25 |
26 | #### 참고 자료
27 |
28 | - **["AWS Amazon S3 버킷 생성하기" (글)](https://zzang9ha.tistory.com/358)**: S3의 다양한 개념들이 정리되어있습니다.
29 | - **["Amazon S3 요금"](https://aws.amazon.com/ko/s3/pricing/)**: AWS의 S3 요금 페이지입니다. S3의 요금을 알아보세요.
30 | - **["S3 버킷에서 버전 관리를 사용하면 무엇이 달라질까?" (글)](https://dev.classmethod.jp/articles/jw-what-would-it-make-a-difference-to-use-version-management-in-an-s3-bucket/)**: S3의 버전 관리 기능에 대해 알아보세요.
31 | - **["AWS S3 요금으로 한 놈 담궈버리는 방법 "](https://www.youtube.com/watch?v=propgtDEMgM)**: S3와 관련된 재미있는 내용입니다. 재미로 가볍게 봐주세요.
32 |
33 | ### 2. Amazon CloudFront
34 |
35 | Amazon CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network) 서비스입니다. CDN은 전 세계에 분산된 서버를 통해 정적 파일을 빠르게 전송할 수 있도록 도와줍니다.
36 |
37 | - CloudFront의 개념과 특징을 알아봐요.
38 | - CloudFront의 용어들을 알아봐요. (distribution, origin, TTL, invalidation)
39 | - CloudFront의 요금을 알아봐요.
40 |
41 | #### 참고 자료
42 |
43 | - **["CloudFront" (글))](https://velog.io/@combi_areum/AWS-CloudFront)**: Cloudfront 개념과 특징을 정리한 글입니다.
44 | - **["CloudFront 요금"](https://aws.amazon.com/ko/cloudfront/pricing/)**: AWS의 CloudFront 요금 페이지입니다. CloudFront의 요금을 알아보세요.
45 |
46 | ### 3. AWS IAM
47 |
48 | AWS IAM의 용어들과 구성, 문법을 알아봐요.
49 |
50 | - IAM의 용어들을 알아봐요. (User, Group, Role, Policy, Permission)
51 | - User를 새로 생성하고, 직접 로그인해봐요.
52 | - IAM Policy의 JSON 문법을 알아봐요. (Statement, Effect, Action, Resource)
53 | - Identity-based Policy와 Resource-based Policy의 차이를 알아봐요.
54 |
55 | {{< alert context="warning" text="AWS의 Best Practice 중 하나는 root 계정을 직접 쓰지 않고 IAM User로 접근하는 것입니다. 앞으로 가능하면 IAM User로 연습해보세요!" />}}
56 |
57 | #### 참고 자료
58 |
59 | - **["IAM이란 (정책, 역할, 권한 경계)" (글)](https://yoonchang.tistory.com/93)**: IAM의 다양한 개념들이 정리되어있습니다.
60 | - **["AWS IAM Identity base 와 resource base policy 의 차이" (글)](https://going-to-end.tistory.com/entry/AWS-IAM-Policy%EC%A0%95%EC%B1%85-Role%EC%97%AD%ED%95%A0-%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90)**
61 |
62 | ## 프로젝트 실습 🎈
63 |
64 | 이번 주에는 아래 그림처럼 클라우드 서비스를 구성해봐요. Client의 요청은 CloudFront로 전달되고, `/api` 요청은 EC2의 Node.js로, 그 외 요청은 S3로 전달됩니다. ALB는 AWS의 Load Balancer 서비스로, 스터디에 없었던 내용인 만큼 세팅 방법은 아래를 참고해주세요. 실습 내용이 많은 만큼, 힌트를 많이 드릴게요!
65 |
66 | ```mermaid
67 | flowchart LR
68 | subgraph AWS
69 | subgraph EC2
70 | subgraph Docker
71 | Node.js
72 | end
73 | end
74 | ALB -- localhost:3000 --> Node.js
75 | CloudFront -- /api/* --> ALB
76 | CloudFront -- /* --> S3
77 | end
78 | Client -- http://[domain-name] --> CloudFront
79 | ```
80 |
81 | - 해당 링크에 있는 HTML, CSS, JS 파일을 다운로드 받고 S3 업로드하세요. (파일 링크:
82 | 실습 파일)
83 |
84 |
85 | - S3에서 Static Website Hosting을 설정하고, Permisson을 public으로 바꾼 다음 접속이 잘 되는지 확인하세요. Permission은 아래 순서로 바꿀 수 있어요.
86 |
87 | 1. Bucket 선택 > Permissions 탭 > Block public access 편집 > ACL 들어간 항목 제외한 두 가지 모두 체크 해제 ('Save changes'가 안된다면, 왼쪽 탭에서 'Block Public Access settings for this account' 클릭 후 마찬가지로 체크 해제)
88 | 2. Bucket Policy 편집 > 아래 JSON을 붙여넣기 > `YOUR_BUCKET_NAME`을 자신의 버킷 이름으로 바꾸기
89 |
90 | ```json
91 | {
92 | "Version": "2012-10-17",
93 | "Statement": [
94 | {
95 | "Sid": "PublicReadGetObject",
96 | "Effect": "Allow",
97 | "Principal": "*",
98 | "Action": "s3:GetObject",
99 | "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
100 | }
101 | ]
102 | }
103 | ```
104 |
105 | - CloudFront를 생성하고, S3를 origin으로 설정하세요. 이후 CloudFront의 Domain Name으로 접속이 잘 되는지 확인하세요.
106 |
107 | - EC2에 기존의 Node.js Docker Container를 올리세요. Nginx 컨테이너는 사용하지 않습니다. docker-compose.yml 파일에서 Nginx 컨테이너를 제거하고, Node.js 컨테이너의 포트 3000을 열어주세요.
108 |
109 | ```yml
110 | version: '3'
111 |
112 | services:
113 | nodejs:
114 | container_name: nodejs
115 | build:
116 | context: .
117 | dockerfile: Dockerfile
118 | # 또는 `image: /:`
119 | ports:
120 | - 3000:3000
121 | ```
122 |
123 | - EC2의 3000번 포트를 Security Group으로 열어두세요. 직접 URL을 입력해서 접속이 잘 되는지 확인하세요. (예: `http://123.456.789.123:3000/api/os`)
124 |
125 | - ALB를 생성하기 전, Target Group을 생성하세요.
126 |
127 | 1. 왼쪽 탭의 'Target Groups'를 클릭하세요.
128 | 2. 'Create target group'을 클릭하세요.
129 | 3. Target type은 'Instances'를 선택하고, Target Group Name을 설정하세요. 나머지는 기본값으로 두고, Next를 클릭하세요.
130 | 4. 실행 중인 EC2 인스턴스를 선택하고, 포트 번호는 3000으로 설정하세요. 'Include as pending below'를 클릭하고, 'Create target group'을 클릭하세요.
131 |
132 | - EC2 화면에서 왼쪽 탭의 'Load Balancers'를 클릭하여 ALB를 생성하세요.
133 |
134 | 1. 세 가지 옵션 중 'Application Load Balancer'를 선택하세요.
135 | 2. Scheme은 'Internet-facing'으로 설정하세요.
136 | 3. 'Mapping' 중 'Availability Zones'에서 최소 두 개의 Availability Zone을 선택하세요. **Target Group의 Availability Zone을 포함해야합니다.**
137 | 4. 나머지는 그대로 두고, "Listeners and routing"에서 HTTP:80에 target group을 이전 단계에서 생성한 target group을 선택하세요.
138 | 5. 'Create load balancer'를 클릭하세요.
139 | 6. Load balancer를 선택하고, Security 탭에서 Security Group을 수정하세요. Inbound 규칙에 HTTP:80을 추가하세요.
140 | 6. Load balancer의 정보 중 'DNS name'을 찾아 api 요청(예: `/api/os`)이 잘 되는지 확인하세요. 구성되는 데 시간이 걸릴 수 있어요. (**잊지 말고 http:// 붙여서 요청하세요!**)
141 |
142 | - CloudFront에서 ALB를 origin으로 설정하세요. `/api/*` 요청은 ALB로, 그 외 요청은 S3로 전달되도록 설정하세요. 이후 CloudFront의 Domain Name으로 접속이 잘 되는지 확인하세요.
143 |
--------------------------------------------------------------------------------
/content/docs/plan/7. Wireframe, Functional Specification.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "7. Wireframe, Functional Specification"
3 | description = "서비스의 화면과 정책을 설계해요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 470
8 | +++
9 |
10 | ## 📑 **이번 주 학습 내용**
11 |
12 | 이번 주는 사용자에게 보일 화면을 그리는 방법과 그 안의 기능을 정의하는 과정을 알아 볼게요.
13 |
14 | 스터디가 끝나기까지 얼마 남지 않았으니, 조금만 더 힘 내 보아요! 🥹
15 |
16 | 💫 **Keyword**: Wireframe, Functional Specification, Service Policy
17 |
18 | ---
19 |
20 | ### Wireframe이 뭔가요?
21 |
22 | 와이어프레임은 각 화면에 어떤 기능이 들어갈지 배치하고, 기초적인 레이아웃을 잡는 도구를 말해요. 말 그대로 선(Wire)으로 화면의 틀(Frame)을 세운다는 의미랍니다!
23 |
24 |
25 | ### Wireframe은 왜 그려야 하나요?
26 |
27 | 와이어프레임은 **비용 및 일정 리스크를 사전에 줄여 주는** 안전장치와도 같아요.
28 |
29 | 스쿼드에 소속된 사람들은 본인의 역할에 따라 집중적으로 고민하는 부분이 달라요. 예를 들어, 기획자는 정보 및 기능의 구조와 흐름을 최우선으로 고민하고, 디자이너는 시각적 완성도를 중요하게 여기고, 개발자는 기술적인 제약이나 구현 볼륨을 고려하게 될 거예요.
30 |
31 | 이렇게 서로 다른 입장을 가진 사람들이 IA나 플로우 차트만을 보면 각자가 모두 다른 화면을 머릿속에 그려낼 수 있어요. 그렇게 되면 요구사항 누락이나 오해가 빈번히 발생하고 말죠. 따라서 와이어프레임은 **화면 구성의 시각적 기준**을 제공해 모든 팀원이 같은 그림을 보며 대화하게 만들어 주는 역할을 해요.
32 |
33 | [[서비스기획] 와이어프레임의 특징과 작성방법에 대해 알아보자](https://youngplan.tistory.com/entry/%EC%84%9C%EB%B9%84%EC%8A%A4%EA%B8%B0%ED%9A%8D-%EC%99%80%EC%9D%B4%EC%96%B4%ED%94%84%EB%A0%88%EC%9E%84Wireframe%EC%9D%98-%ED%8A%B9%EC%A7%95%EA%B3%BC-%EC%9E%91%EC%84%B1%EB%B0%A9%EB%B2%95%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90) 👉 와이어프레임의 정의와 중요성을 다시 한 번 살펴 보아요.
34 |
35 | [나의 대충 그려졌고 소중한 와이어프레임](https://blog.gangnamunni.com/post/communication-with-wireframe) 👉 와이어프레임으로 팀과 효율적으로 소통한 실무 사례를 알아 보아요.
36 |
37 | [UX의 기본, 와이어프레임은 어떻게 작성하는 것일](https://brunch.co.kr/@second-space/27) 👉 와이어프레임을 그리는 과정을 구경해 보아요.
38 |
39 | ### Wirframe의 세 가지 단계
40 |
41 | 와이어프레임은 완성도에 따라 3가지 단계로 나뉘어요.
42 |
43 | 1. **Lo-fi Wireframe (Low-fidelity Wireframe)**
44 | 정말 간단하게 표현된 러프 스케치예요. 공책이나 화이트보드에 투박하게 화면 설계의 초안을 그리는 것에 그치는 경우가 많아요.
45 | 그렇기에 수정이 용이하여, 아이디어를 자유롭게 발산하고 적용할 수 있다는 장점이 있어요.
46 |
47 |
48 | 2. **Mid-fi Wireframe (Middle-fidelity Wireframe)**
49 | Mid-fi는 Lo-fi를 깔끔하게 정리하여 디지털로 옮긴 단계까지를 말해요. 단, 구조나 정보 위계를 정확하게 보기 위하여 회색 톤 이외의 컬러는 사용하지 않아요. 이 과정에서 임시 텍스트나 더미 데이터를 배치하며 이미지, 글자 수, 정렬 등에 대한 정책을 한 번 더 고민하기도 해요.
50 |
51 | 3. **High-fi Wireframe (High-fidelity Wireframe)**
52 | 디자인 요소를 조금 더 활용하여 프로토타입으로 활용할 수 있을 정도로 다듬어진 와이어프레임을 말해요. 브랜드 컬러를 적용하거나, 실제 디자인 가이드에 명시된 스타일을 적용해 보며 시각적인 요소를 검토해 보기도 해요.
53 | 보통 기획자는 Mid-fi까지 완성하여 디자이너에게 전달하고, High-fi부터는 디자이너가 주로 담당하곤 한답니다 😉
54 |
55 |
56 | ### Wireframe, 쉽게 그릴 수 있는 방법은 없을까요?
57 |
58 | 기획자는 와이어프레임을 그릴 때 디자인 요소를 배제하고 서비스의 흐름과 구조, 사용성에만 충실하면 충분하지만, 그래도 머릿속에 있는 레이아웃이나 컴포넌트도 표현하고 싶을 때가 있죠! 🫠
59 |
60 | 그럴 때, 피그마를 잘 다루지 못하거나 그림을 잘 그리지 못해도 와이어프레임의 완성도를 높일 수 있는 방법을 소개할게요 😊
61 |
62 | 1. 피그마에서 ‘Templates and tools’로 들어간 다음, **shadcn**을 검색해 주세요.
63 |
64 |
65 | 2. 첫 번째 파일을 클릭 후, Open in Figma를 눌러주세요.
66 | (’Where would you like to open it?’이 나오면 SKKUDING을 클릭해 주세요. 본인만 볼 수 있는 Draft 폴더로 이동하니 걱정하지 마세요!)
67 |
68 | 3. 이 파일 안에는 여러 가지 완성된 컴포넌트들이 있어요.
69 | 원하는 컴포넌트를 선택해서 와이어프레임에 적용하면, 더 빠르고 쉽게 Mid-fi까지 완성할 수 있을 거예요!
70 |
71 |
72 | ---
73 |
74 | ### 기능 명세서가 무엇인가요?
75 |
76 | 기능 명세는 우리가 **무엇을 어떻게 만들지** 정의하는 것을 말해요. 주로 이러한 내용들이 담겨요.
77 |
78 | - 기능의 역할
79 | - 기능의 접근 경로
80 | - 기능이 동작하는 상황
81 | - 어떻게 동작하는가?
82 | - 동작 성공 시 어떻게 동작하는가?
83 | - 동작 실패 시 어떻게 동작하는가?
84 | - 입력 데이터 및 출력 데이터
85 | - 다른 화면/페이지와의 연결
86 | - 엣지 케이스 (예외 상황)
87 |
88 | 이러한 기능 명세는 와이어프레임 옆에 배치된 순서대로 작성되기도 해요. 이를 **화면 설계서** 또는 **스토리보드**라고 불러요.
89 |
90 | 화면 설계서는 개발자와 디자이너가 모두 시각적으로 화면의 기능과 그 기능의 역할 등을 시각적으로 쉽게 이해할 수 있다는 장점이 있어요!
91 |
92 |
93 | [서비스 기획 절차의 이해(下)](https://brunch.co.kr/@socandy/19) 👉 아티클을 읽으며 기능 명세와 화면 설계서 작성을 다시 한 번 이해해 보아요!
94 |
95 | ### 정책은 어떻게 설계하나요?
96 |
97 | 정책은 그 **기능에 적용되는 규칙이나 조건**을 말해요. 주로 이러한 내용들이 포함되거나 고려되어요.
98 |
99 | - 해당 기능에 접근할 수 있는 권한
100 | - 각 권한에 대한 정의 및 역할
101 | - 리스트 정렬 기준
102 | - 기간 등에 의한 제한
103 | - 정책 충돌 시 우선 순위
104 | - 법적 이슈 (개인정보, 저작권 등)
105 |
106 | 정책 설계는 모든 예외 케이스, 개발 리소스, 외부 인프라와의 충돌, 정보 및 개인정보 보호, 서비스 목표 등을 전부 고려해야 하는 작업이어서 매우 까다로워요. 하지만 이에 대한 부분을 기획자가 정확하게 정의하지 않고 넘어간다면, 분명 구현 중 혹은 운영 중에 팀원 모두가 혼란에 빠질 거예요. 😫
107 |
108 | [[꼬기집개] #8 그림만 그릴 거면 기획자가 왜 필요해?](https://www.youtube.com/watch?v=9H0CwTHlmRQ) 👉 정책 관리의 중요성에 대해 설명한 영상이에요.
109 | ~~(볼 때마다 저는 뜨끔합니다…)~~
110 |
111 | 좋은 정책은 재사용이 용이하고 추후 QA나 테스트에서도 유의미하게 사용될 수 있기 때문에 서비스의 유지보수를 원활하게 만들어 주어요. 그러니 정책을 꼼꼼하게 설계하는 습관을 잘 들여보아요!
112 |
113 | [[정책 기획] 서비스 정책서 작성하기](https://germweapon.tistory.com/412) 👉 정책 설계에서 고려해야 하는 것들을 자세히 설명한 글이에요.
114 |
115 | ---
116 |
117 | ## ✏️ **과제 안내**
118 |
119 | 이번 주는 총 2가지의 과제를 진행할게요.
120 |
121 | 1. 지난 과제에서 설계하나 IA와 플로우 차트를 기반으로, 본인의 아이디어에 대한 **Lo-fi 와이어프레임**을 그려 보세요.
122 | - 조금 더 완성도 높은 과제를 제출하고 싶다면 Mid-fi까지 그려 보아도 좋아요!
123 | 2. 와이어프레임 뿐만 아니라, **기능 명세 및 정책 설계**도 함께 진행해 보세요.
124 | - 별도로 정해진 양식은 없어요. 막막하다면, 노션에 있는 ‘기능 및 정책 명세서’ 페이지를 참고해 주세요!
125 | - 완벽하지 않아도 괜찮아요! 미처 생각하지 못했던 부분들은 스터디 시간에 함께 채워 나가 보아요.
126 |
127 | 추가로, 이번 주부터 방학 프로젝트 전까지 기존 기능 및 정책 명세서를 꾸준히 읽어보고 스테이지 서버에서 사이트를 자주 사용해 주세요!
128 | 현재 구현되어 있는 서비스를 잘 이해하고 있어야 유지보수는 물론 신 기능 구축도 수월해 진다는 것을 꼭 기억해 주세요. 🫡
129 |
--------------------------------------------------------------------------------
/content/docs/backend/3. Express.js.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "3. Express.js"
3 | description = "웹 프레임워크인 Express.js에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2023-09-08"
7 | weight = 130
8 | +++
9 |
10 |
11 |
12 | Express.js는 웹 서버를 만들기 위한 Node.js의 웹 프레임워크입니다. Node.js의 http 모듈로도 웹 서버를 만들 수 있지만, Express.js를 사용하면 더 쉽고 편리하게 만들 수 있습니다.
13 |
14 | 사실 코드당에서는 NestJS를 사용하지만 NestJS를 배우기 전 Express.js에 대해서 먼저 공부를 하는 이유는, NestJS는 Express를 기본으로 채택하고 그 위에 여러가지 기능을 미리 구현해놓은 프레임워크이기 때문입니다. Express.js에 대해서 먼저 배웠을 때, NestJS를 조금 더 쉽게 이해할 수 있을 것입니다. 그리고 왜 NestJS를 쓰면 편한지도 좀 더 명확하게 느끼게 되실거에요🦭✨
15 | > Under the hood, Nest makes use of robust HTTP Server frameworks like Express (the default) and optionally can be configured to use Fastify as well! [NestJS 공식문서](https://docs.nestjs.com/)
16 |
17 | 이번 주차에는 Express.js에 대해서 알아보며 간단한 웹서버를 만들어볼 예정입니다.
18 |
19 | - 인프라 스터디 2주차를 참고하여 작성되었습니다 (@dotoleeoak 감사합니다 🥺)
20 |
21 | ## 공부할 내용 📚
22 |
23 | ### 1. Express.js
24 |
25 | Express.js는 Node.js의 핵심 모듈인 http와 Connect 컴포넌트를 기반으로 하는 웹 프레임워크입니다. 기존 Node.js를 이용하여 웹서버를 만들었을 때에는 다양한 문제들이 존재했었습니다(Request Body 파싱, 중복된 에러 처리 코드, 복잡한 if 조건을 통한 라우팅 구성 등). 하지만 Express.js를 사용하면 이러한 문제들을 해결할 수 있음은 물론 더욱 간편하게 웹서버를 만들 수 있습니다.
26 |
27 | Express.js의 다음 개념들에 대해 공부해봅시다.
28 |
29 | - Express.js 설치와 실행
30 | - 라우팅
31 | - JSON 형식
32 | - 미들웨어
33 | - 오류 처리
34 |
35 | 아래 자료들 중 원하는 자료를 골라서 공부해보세요. 다른 자료를 찾아봐도 좋아요.
36 |
37 | - **[Express.js 공식 문서](https://expressjs.com/ko/)**: 간결하게 핵심 기능들이 잘 정리되어있습니다. '시작하기'와 '안내서'의 라우팅, 미들웨어, 오류 처리를 공부해보세요.
38 | - **[생활코딩 Express.js 강의](https://opentutorials.org/course/3370)**: 조금 오래되었지만 인기 있는 강의입니다.
39 |
40 | ### 2. npm, package.json, 모듈
41 |
42 | 이 부분은 Node.js를 사용할 때 자주 살펴보게 될 내용이니 너무 깊게는 아니더라도 조금씩은 공부해보시길 바랍니다.
43 |
44 | - 모듈의 개념과 Node.js에서 모듈을 사용하는 방법을 알아봅니다.
45 | - npm CLI의 기본적인 명령어들을 실습해봅니다. (`init`, `install`, `run`, `npx`)
46 | - node_modules, package.json과 package-lock.json의 역할과 구조를 알아봅니다.
47 | - package-lock.json 때문에 협업에서 자주 충돌하는데.. 이 파일이 뭘 의미하는 건지 한 번 알아보세요.
48 | - CommonJS와 ESModule의 차이를 알아봅니다.
49 |
50 | > 더 공부해보면 좋을 개념(선택): MonoRepo, pnpm
51 |
52 | 참고할만한 자료들입니다.
53 |
54 | - **[Fireship "JavaScript Modules in 100 Seconds" (약 2분)](https://youtu.be/qgRUr-YUk1Q?si=HMhLnfetlbfIExcN)**: 간결하게 모듈을 설명한 영상입니다. (영어 주의!!)
55 | - **["JavaScript Module System" (글)](https://velog.io/@doondoony/JavaScript-Module-System)**: JavaScript 모듈과 ESM, CommonJS 등에 대해 상세하게 다룬 글입니다.
56 | - **["모듈화와 npm" (글)](https://poiemaweb.com/nodejs-npm)**: npm 기능들을 실행해보며 배울 수 있는 글입니다.
57 | - **["Package.json과 Package-lock.json의 차이를 아시나요?" (글)](https://velog.io/@songyouhyun/Package.json과-Package-lock.json의-차이)**: package.json과 package-lock.json을 이해하기 쉽게 설명한 글입니다.
58 | - **["모듈 내보내기/불러오기 (CommonJS vs ES6)" (글)](https://it-eldorado.tistory.com/92)**: CommonJS와 ES6의 차이를 간단하게 정리한 글입니다.
59 | - **["npm, yarn, pnpm 비교해보기" (글)](https://yceffort.kr/2022/05/npm-vs-yarn-vs-pnpm)**: npm의 대체재인 yarn, pnpm과의 차이를 비교한 글입니다.
60 | - **[npm 공식문서](https://docs.npmjs.com)**: npm 공식문서 링크입니다. 영어로 되어있고, 양이 많으니 궁금한 부분만 골라서 확인해주시면 될 것 같습니다.
61 |
62 | ## 프로젝트 실습 🎈
63 |
64 | 이번 주차에는 Express.js를 활용하여 율전 근처의 맛집들을 관리하는 간단한 웹서버를 만들어볼 것입니다. 이번에는 다양한 메서드를 사용하고 에러 처리도 할 수 있게끔 할 예정이에요.
65 |
66 | **유의사항**
67 | - ES6 import를 사용해보세요. package.json의 `type`을 `module`로 설정해야 합니다. (`import express from 'express'`)
68 | - (선택) nodemon을 설치해 코드가 바뀌면 자동으로 서버가 재시작되도록 해보세요.
69 | - (선택) npm, yarn, pnpm 등을 사용해보면서 package manager를 어떻게 사용하는지 알아보세요. (참고로 코드당에서는 pnpm을 사용한답니다^^)
70 | - API 응답을 테스트해볼 때에는 앞 주차와 같이 Postman이나 Bruno 같은 API 테스팅 툴으로 시험해보는 것을 권장합니다.
71 | - 폴더 구조는 마음대로 설정하셔도 괜찮습니다.
72 | - `routes` 폴더를 만들어서 라우팅 소스를 분리하시거나 `services` 폴더를 만들어 비즈니스 로직을 따로 빼주는 등 자유롭게 폴더를 설정하시면서 어떻게 해야지 조금 더 편리하게 개발할 수 있을지 생각해시면 좋을 것 같아요.
73 | - 아래와 같은 endpoint들을 구현해보세요.
74 | - 현재는 데이터베이스를 연결하지 않았으니 json 파일을 이용해서 과제를 진행해주세요! (`/backend/data/restaurants.json`)
75 | - Path, 에러 코드는 따로 적지 않았는데요, 1주차에 공부한 부분 + 각 endpoint의 설명을 생각하시면서 채워나가주세요!
76 |
77 | ### `GET ?`
78 |
79 | 전체 맛집 목록을 반환합니다.
80 |
81 | ```json
82 | {
83 | "restaurants": [
84 | {
85 | "name": "봉수육",
86 | "address": "경기 수원시 장안구 율전로108번길 11 1층",
87 | "phone": "0507-1460-0903"
88 | },
89 | ...
90 | ]
91 | }
92 | ```
93 |
94 | ### `GET ?`
95 |
96 | 특정 맛집 정보를 이름(name)을 통해 접근할 수 있도록 합니다.
97 | Query, Parameter, Body 중 자유롭게 선택해 name을 전달해주세요.
98 |
99 | > 만들어 보면서 Query, Parameter, Body를 각각 어떠한 Context에서 사용하면 좋을지 생각해보세요.
100 |
101 | - **성공시**
102 |
103 | ```json
104 | {
105 | "name": "봉수육",
106 | "address": "경기 수원시 장안구 율전로108번길 11 1층",
107 | "phone": "0507-1460-0903"
108 | }
109 | ```
110 |
111 | - **만약 해당 맛집 정보가 존재하지 않을시**
112 |
113 | ```json
114 | {
115 | "error": "해당 맛집 정보가 존재하지 않습니다."
116 | }
117 | ```
118 |
119 |
120 | ### `POST ?`
121 |
122 | 특정 맛집 정보를 생성합니다.
123 |
124 | #### Request Body
125 |
126 | ```json
127 | {
128 | "name": "맛집이름",
129 | "address": "맛집주소",
130 | "phone": "전화번호"
131 | }
132 | ```
133 |
134 | - 성공시 (생성한 맛집 정보를 반환합니다.)
135 |
136 | ```json
137 | {
138 | "name": "맛집이름",
139 | "address": "맛집주소",
140 | "phone": "전화번호"
141 | }
142 | ```
143 |
144 | - 이미 해당 맛집 정보가 존재할시
145 |
146 | ```json
147 | {
148 | "error": "이미 해당 맛집 정보가 존재합니다."
149 | }
150 | ```
151 |
152 | ### `DELETE ?`
153 |
154 | 특정 name의 맛집 정보를 삭제합니다.
155 | Query, Parameter, Body 중 자유롭게 선택해 name을 전달해주세요.
156 |
157 | - 성공시 (삭제한 맛집 정보를 반환합니다.)
158 |
159 | ```json
160 | {
161 | "name": "봉수육",
162 | "address": "경기 수원시 장안구 율전로108번길 11 1층",
163 | "phone": "0507-1460-0903"
164 | }
165 | ```
166 |
167 | - 만약 해당 맛집 정보가 존재하지 않을시
168 |
169 | ```json
170 | {
171 | "error": "해당 맛집 정보가 존재하지 않습니다."
172 | }
173 | ```
174 |
175 | ### `PATCH ?`
176 |
177 | 특정 name의 맛집 정보를 수정합니다.
178 |
179 | > '수정'과 관련된 동작에는 PUT, PATCH 두개를 많이 쓴답니다. 이 두 메서드 쓰임새의 차이에 대해서도 한 번 살펴보세요.
180 |
181 | - **성공시** (수정한 맛집 정보를 반환합니다.)
182 |
183 | ```json
184 | {
185 | "name": "봉수육",
186 | "address": "경기 수원시 장안구 율전로108번길 11 1층",
187 | "phone": "0507-1460-0903"
188 | }
189 | ```
190 |
191 | - **만약 해당 맛집 정보가 존재하지 않을시**
192 |
193 | ```json
194 | {
195 | "error": "해당 맛집 정보가 존재하지 않습니다."
196 | }
197 | ```
198 |
199 | > **Challenge! 🔥 (선택)**
200 | > 사실 이번과제는 쉽게 끝낼 수 있을 텐데요, 시간이 남는다면 아래와 같은 기능들을 직접 추가해보세요!
201 | > * 미들웨어 추가 (request의 IP logging, 찾는 페이지가 없을시 404 에러 반환)
202 | > * 새로운 api 추가 (로그인, 회원가입 등등)
203 |
--------------------------------------------------------------------------------
/content/docs/plan/2. Web Development Process.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "2. Web Development Process"
3 | description = "웹 개발 프로세스를 이해하고 다른 팀과 협업해요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 420
8 | +++
9 |
10 | ## 📑 **이번 주 학습 내용**
11 |
12 | 우리가 기획한 페이지와 기능들은 어떤 과정을 거쳐서 웹에 배포될까요?
13 |
14 | 그리고 그 과정에서 각 팀은 어떤 역할을 할까요?
15 |
16 | 이번 주에는 이 두 가지 질문에 대한 답을 함께 찾아가 봐요! 😊
17 |
18 | 💫 **Keyword**: 개발 프로세스, 프론트엔드, 백엔드, 인프라, 서비스 기획, PM
19 |
20 | ---
21 |
22 | ### 프론트엔드? 백엔드? 인프라?
23 |
24 | 개발 프로세스를 알기 전, 서비스가 동작하는 간단한 원리와 각 팀의 역할을 아는 것이 매우 중요해요!
25 |
26 |
27 |
28 | 이해를 돕기 위해서, 공연에 비유해서 각 팀의 역할을 설명할게요.
29 |
30 | 하나의 공연이 성공적으로 진행되기 위해서는 여러 사람들의 노력이 필요해요. 이때, 관객에게 직접적으로 보이는 부분을 꾸미는 사람들도 있고, 무대에는 직접적으로 보이지는 않지만 무대의 뒤에서 여러 가지 효과를 관리하고 조정하는 사람들도 있을 거예요. 이 모든 과정에서 사용되는 모든 장비와 공연장 전체를 유지 및 보수하는 사람도 있을 거예요.
31 |
32 |
33 |
34 | 서비스도 마찬가지예요! 사용자에게 보여지는 화면을 만드는 팀과 사용자에게 보이지 않는 곳에서 데이터베이스를 관리하는 팀, 그리고 서비스가 배포되는 서버를 관리하는 팀이 유기적으로 협업하여 하나의 서비스를 만들고 있어요.
35 |
36 | 이때, 사용자에게 보이는 화면에서 일어나는 기능을 개발하는 팀을 ‘프론트엔드팀’, 사용자와 서비스의 데이터를 관리하고 처리하는 팀을 ‘백엔드팀’, 서버가 안정적으로 작동할 수 있도록 관리하는 팀을 ‘인프라팀’이라고 말해요.
37 |
38 | [[꼬기집개] #1 개발자 구분하기, 서비스의 기본 알기](https://www.youtube.com/watch?v=gjS9w7oTAUc)
39 | 👉 서비스의 구조와 개발자의 역할을 전체적으로 설명하는 영상이에요. 이 영상을 본 후에 아래 내용을 따라간다면 이해가 더 쉬울 거예요!
40 |
41 | ---
42 |
43 | ### 서비스 기획자와 PM, PO은 다른 직무인가요?
44 |
45 | 서비스 기획을 공부하다 보면, ‘서비스 기획자’와 ‘PM’, ‘PO’이라는 직무가 자주 언급되는 것을 볼 수 있어요.
46 |
47 | 비슷해 보이면서도 조금씩 달라 보이는 세 가지 직무는 어떤 차이가 있을까요?
48 |
49 | **서비스 기획자**
50 |
51 | 먼저, 서비스 기획자는 직무명 그대로, 서비스가 해결해야 할 문제를 정의하고 해결 방안을 도출하여 서비스를 설계하는 사람을 말해요. 경쟁사와 시장을 조사하고, 사용자와 만나 문제를 발견하고, 서비스의 앞단과 뒷단을 모두 고려하여 서비스의 뼈대를 만들어 가는 역할을 해요.
52 |
53 | [지도 잘 모르면서](https://fficial.naver.com/contentDetail/55) 👉 서비스 기획자의 역할을 전반적으로 설명하고 있는 글이에요.
54 |
55 | **PM**
56 |
57 | PM은 ‘Product Manager’의 줄임말로, 서비스 기획을 넘어 하나의 서비스의 개발 및 운영 체제를 전체적으로 관리하는 사람을 말해요. (여기서 프로덕트는 앱, 웹과 같은 IT 서비스를 의미해요!) 하나의 서비스 뿐만이 아니라 프로덕트의 탄생과 유지 및 보수, 업무 프로세스 등에도 집중해야 해요.
58 |
59 | **PO**
60 |
61 | PO는 ‘Product Owner’의 줄임말로, 서비스의 모든 결정권을 갖고 전략 및 로드맵을 수립해 새로운 사업을 시도하는 사람을 말해요. PM이 현재 우리의 프로덕트를 사용하는 사용자에 집중한다면, PO는 더 나아가 프로덕트의 확장을 바라보고 잠재적 사용자의 문제와 필요까지 파악해야 해요. 그래서 PO를 ‘미니 CEO’라고 부르기도 해요!
62 |
63 | [PM과 PO는 뭐가 다를까?](https://post.naver.com/viewer/postView.naver?volumeNo=33736454&memberNo=39727918&vType=VERTICAL) 👉 PM과 PO의 차이를 아주 명확하게 설명하고 있는 글이에요!
64 |
65 | ---
66 |
67 | ### 웹 서비스는 어떻게 만들어 지나요?
68 |
69 | 기획부터 개발까지, 웹 개발은 어떤 방식으로 진행될까요?
70 |
71 | 프로젝트의 성격과 조직 구성에 따라 조금씩 달라질 수 있지만, 기본적인 방식을 설명할게요.
72 |
73 |
74 |
75 |
76 | 1. 프로젝트의 목표를 규정해요.
77 | - 서비스의 목적, 조직의 비전 등을 참고해요.
78 | - 프로젝트 목표를 달성하기 위해 필요한 구성 요소 - 프로젝트 일정, 미팅 장소, 인적 자원, 인프라 등도 고려해요.
79 | 2. 문제 상황을 정의하고, 태스크를 구체화해요.
80 | - 프로젝트에서 해결하고자 하는 문제와 기대 목표를 최대한 명확한 언어로 정의하도록 해요.
81 | - 클라이언트의 요구 사항, 프로젝트의 도메인, 타겟 사용자 등을 분석해 구체적인 목표를 수립할수록 좋아요.
82 | - 대략적으로 구상했던 프로젝트의 일정을 세분화하고, 계획을 수립해요.
83 | [OKR이란? 뜻, 의미 1분 만에 이해하기](https://flow.team/blog/ceo/18672/?gad_source=1&gad_campaignid=21752715097&gbraid=0AAAAADggZVwCbNJJ77H3jMM5J40qhcQrn&gclid=CjwKCAjwq9rFBhAIEiwAGVAZP2hgGlNqxn7QT-yrL51PMI6XbpDrf4f0gJ-VRz3wZDgWgfP2gjEsOxoC0h0QAvD_BwE) 👉 스꾸딩에서 체계적인 일정 관리를 위해 사용하고 있는 'OKR'에 대해 알아보아요!
84 | 4. 세부적인 화면을 기획하고 정책을 설계해요.
85 | - 각 기능의 위치, 형태, 정책 등을 충분히 고민해요.
86 | - 각 기능과 페이지 등의 에러 케이스, 예외 상황 등을 고려해 데이터 처리 과정 등을 보완해요.
87 | 5. 화면을 디자인해요.
88 | - 디자인팀은 기획된 화면을 기반으로 실제 서비스에 보여질 화면을 디자인해요.
89 | - 컴포넌트를 만들고 디자인 가이드를 만드는 과정이 포함될 수 있어요.
90 | 6. 개발을 진행해요.
91 | - **백엔드팀**은 정책이 설계된 후 바로 데이터베이스 구조, API, 로직 등을 설계하기도 해요.
92 | - **프론트엔드팀**은 디자인된 화면을 실제 서비스에 구현하고, API를 연결해요.
93 | - **인프라팀**은 각 개발팀이 구현한 기능 등이 원활하게 배포되고 운영될 수 있도록 자동화된 시스템을 구축해요.
94 | [API란? 비개발자가 알기 쉽게 설명해드립니다!](https://yozm.wishket.com/magazine/detail/53/) 👉 API를 아주 쉽게 설명한 글이에요. API에 대해 잘 모른다면, 꼭 읽어보세요!
95 | 7. 테스트를 위한 환경을 만들어요.
96 | - 기획팀은 구현한 기능이 정상적으로 작동하는지, 사용자가 사용하기에 불편함은 없는지 등을 점검하기 위한 문서를 사전에 작성해요.
97 | - 인프라팀은 테스트를 진행하기 위한 서버를 배포해요.
98 | 8. 개발이 완료된 기능들을 테스트하고, 서비스를 보완해요.
99 | - 서버에서 직접 기능들을 사용해 보며 기능 상의 문제점과 개선점을 발견해요.
100 | - 발견된 문제에 따라 기능을 수정하고, 다시 테스트하는 과정을 거쳐요.
101 | 9. 사용자에게 서비스를 배포해요.
102 | - 실제로 사용자가 사용하는 서버에 완성된 서비스를 공개해요.
103 |
104 | [IT 프로젝트 전과정 설명](https://www.youtube.com/watch?v=5GXVuPrvF4I) 👉 전체적인 개발 프로세스를 훑어볼 수 있는 아주 좋은 강의예요!
105 | ※ 강의에서는 다른 회사에서 프로젝트를 제안 받아 진행하는 회사의 개발 프로세스를 설명하고 있어요.
106 | 따라서 ‘프로젝트 진행 전반 계획’ 단계부터 집중해서 들으면 좋아요!
107 |
108 | ---
109 |
110 | ### 개발 서버와 프로덕션 서버의 분리
111 |
112 | 앞선 웹 개발 프로세스에서, ‘개발이 완료된 기능들을 테스트’하는 과정이 있음을 배웠어요.
113 |
114 | 하지만 실제 사용자들이 있는 사이트에서 테스트 전 기능을 바로 배포하고, 그 사이트에서 테스트를 한다면 어떻게 될까요? 아마 사용자들은 당황스러워하고 서비스 이용에 큰 불편을 느끼며 서비스를 이탈하게 될 거예요 😮💨
115 |
116 | 이를 위해, 웹 개발 프로젝트를 진행할 때에는 실제 사용자들이 이용하고 있는 사이트와 그 사이트에 기능을 배포하기 전 테스트하는 사이트를 분리해요. 이때, 전자를 ‘프로덕션 서버’, 후자를 ‘개발 서버’라고 말해요.
117 |
118 | 개발 서버는 목적에 따라 여러 개로 분리되고 각 프로젝트와 조직마다 다르게 사용될 수 있어요. 여기에서는 코드당이 사용하고 있는 개발 서버들을 알아볼게요.
119 |
120 | 1. 로컬 서버 (Local Server)
121 | - 개발을 위해, 각 개발자마다 설치된 서버 환경이에요.
122 | 2. 스테이징 서버 (Staging Server)
123 | - 각 개발자들이 만든 기능을 한 곳에 합칠 수 있도록 운영되는 서버 환경이에요.
124 | - 배포 전, 테스트를 할 때 주로 사용해요.
125 | 3. 프로덕션 서버 (Production Server)
126 | - 실제 사용자들이 이용하는 서버예요. ‘운영 서버’라고도 말해요.
127 | - 사용자들의 정보가 담겨있기 때문에, 데이터베이스 관리 등 운영에 각별히 주의해야 해요!
128 |
129 | 지금은 운영 서버가 아닌, 스테이지 서버에서 테스트를 해야 한다는 것만 알고 있어도 괜찮아요 😁
130 |
131 | [개발환경에 대하여](https://velog.io/@k7nsuy/%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD%EC%97%90-%EB%8C%80%ED%95%98%EC%97%AC-devstageprod) 👉 더 많은 서버 환경이 궁금할 때 읽어보세요!
132 |
133 | ---
134 |
135 | ## ✏️ **과제 안내**
136 |
137 | 2주차에는 스테이지 서버에서 코드당을 사용해 보고, 리뷰해 보는 시간을 가져 보아요 😎
138 |
139 | (저번 주와 마찬가지로, 사이트에 있는 문제의 정답을 맞추는 것보다 **사용자의 행동 흐름**과 **사용성**에 집중해 주세요!)
140 |
141 | 학생, 교수, 대회 출제자 등의 여러 사용자의 측면에서 코드당을 경험해 보고, 아래와 같은 내용을 포함해서 리뷰해 보면 좋아요 😀
142 |
143 | - 서비스의 목표
144 | - 서비스가 해결하고자 하는 문제
145 | - 문제를 해결하기 위한 핵심 기능 (사용자의 특징 별로 나누어서 작성해도 좋아요!)
146 | - 편리하다고 느꼈던 경험
147 | - 불편하다고 느꼈던 경험
148 |
149 | 스테이지 서버는 실제 운영 서버가 아니기 때문에, 마음껏 강의나 대회, 문제를 새로 만들거나 풀어봐도 괜찮아요!
150 | 스테이지 서버를 사용하기 위한 사이트 주소, ID, PW는 1주차 스터디가 끝난 후 스터디 단톡방에 공유할 예정이에요. 외부에 유출되지 않도록 주의해 주세요! ⚠️
151 |
--------------------------------------------------------------------------------
/assets/docs/scss/custom/structure/_content.scss:
--------------------------------------------------------------------------------
1 | // Docs main content
2 | //
3 | // _content.scss
4 | //
5 |
6 | :root {
7 | --content-icon-color: var(--primary);
8 | --content-icon-bg: var(--sidebar-icon-bg);
9 | --content-icon-border: var(--sidebar-icon-bg);
10 | --content-link-color: var(--primary);
11 |
12 | --ordered-list-bg: var(--gray-300);
13 | --ordered-list-color: var(--gray-800);
14 | --blockquote-border-color: var(--gray-300);
15 |
16 | --code-block-bg: #212d63;
17 | --inline-code-bg: var(--gray-100);
18 | --inline-code-border: 1px solid var(--gray-400);
19 | }
20 |
21 | [data-dark-mode] {
22 | --content-icon-color: var(--primary-200);
23 | --content-icon-bg: hsl(var(--primary-hsl), 0.15);
24 | --content-icon-border: var(--primary-800);
25 | --content-link-color: var(--primary-300);
26 |
27 | --ordered-list-bg: var(--gray-700);
28 | --ordered-list-color: var(--gray-200);
29 | --blockquote-border-color: var(--primary-200);
30 |
31 | --code-block-bg: var(--gray-900);
32 | --inline-code-bg: var(--gray-800);
33 | --inline-code-border: 1px solid var(--gray-600);
34 | }
35 |
36 | .docs-content {
37 | order: 1;
38 | }
39 |
40 | // Links
41 | .docs-content .main-content a {
42 | font-weight: 600;
43 | color: var(--content-link-color);
44 | &:hover {
45 | text-decoration: underline 2px var(--primary-200);
46 | text-underline-offset: 2.5px !important;
47 | transition: 0s !important;
48 | }
49 | // &.anchor i {
50 | // transform: rotate(-45deg);
51 | // }
52 | code {
53 | color: var(--content-link-color);
54 | }
55 | }
56 |
57 | .docs-content .main-content {
58 | #edit-this-page a,
59 | #list-item a {
60 | &:hover {
61 | text-decoration: none !important;
62 | }
63 | }
64 | }
65 |
66 | .docs-content .main-content li {
67 | color: var(--text-default);
68 | }
69 |
70 | .docs-content .main-content h1,
71 | .docs-content .main-content h2,
72 | .docs-content .main-content h3,
73 | .docs-content .main-content h4,
74 | .docs-content .main-content h5 {
75 | font-weight: 700;
76 | color: var(--body-color);
77 | }
78 |
79 | .docs-content .content-title {
80 | font-weight: 700;
81 | align-self: center;
82 | }
83 |
84 | i {
85 | &.title-icon {
86 | width: 44px;
87 | height: 44px;
88 | color: var(--content-icon-color);
89 | background-color: var(--content-icon-bg);
90 | display: inline-flex !important;
91 | align-self: center;
92 | align-items: center;
93 | justify-content: center;
94 | font-size: 24px;
95 | // border: solid 1px var(--content-icon-border);
96 | border-radius: 5px;
97 |
98 | @media (max-width: 768px) {
99 | align-self: auto;
100 | }
101 | }
102 | }
103 |
104 | .docs-content p {
105 | &.lead {
106 | color: var(--text-muted);
107 | font-weight: 400;
108 | }
109 | }
110 |
111 | @media (max-width: 1199px) {
112 | .docs-content {
113 | padding-left: calc(var(--bs-gutter-x) * 1.05);
114 | padding-right: calc(var(--bs-gutter-x) * 1.05);
115 |
116 | h2 {
117 | margin-bottom: 1rem;
118 | }
119 |
120 | p {
121 | &.lead {
122 | font-size: 1rem;
123 | }
124 | }
125 | }
126 | }
127 |
128 | // Images
129 | .docs-content .main-content {
130 | img,
131 | svg {
132 | max-width: 100%;
133 | /* disabled by custom */
134 | // height: auto;
135 | }
136 | // External link icon
137 | a svg {
138 | vertical-align: middle;
139 | padding-bottom: 0.25rem;
140 | margin-left: 3px;
141 | }
142 | }
143 |
144 | // Unordered List Styling
145 | .docs-content .main-content ul {
146 | padding-left: 0;
147 |
148 | > li {
149 | position: relative;
150 | padding-left: 32px;
151 | // margin-bottom: 5px;
152 | }
153 |
154 | > li::before {
155 | content: '';
156 | position: absolute;
157 | width: 6px;
158 | height: 6px;
159 | left: 8px;
160 | top: 10px;
161 | border-radius: 30%;
162 | background: var(--gray-500);
163 | }
164 | }
165 |
166 | // Ordered List Styling
167 | .docs-content .main-content ol {
168 | counter-reset: listitem;
169 | > li {
170 | counter-increment: listitem;
171 | position: relative;
172 | padding-left: 32px;
173 | }
174 |
175 | > li::before {
176 | content: counter(listitem);
177 | background: var(--ordered-list-bg);
178 | color: var(--ordered-list-color);
179 | font-size: 12px;
180 | font-weight: 500;
181 | line-height: 10px;
182 | text-align: center;
183 | padding: 5px 0;
184 | width: 20px;
185 | height: 20px;
186 | border-radius: 5px;
187 | position: absolute;
188 | left: 0;
189 | top: 3px;
190 | }
191 | }
192 |
193 | // Universal List Styling
194 | .docs-content .main-content ol,
195 | .docs-content .main-content ul {
196 | list-style: none;
197 | line-height: 26px;
198 | }
199 |
200 | // Blockquote
201 | .docs-content .main-content blockquote {
202 | margin-bottom: 1rem;
203 | /* disabled by custom */
204 | // font-size: 1.25rem;
205 | border-left: 3px solid var(--blockquote-border-color);
206 | padding-left: 1rem;
207 | }
208 |
209 | // Code
210 | .docs-content .main-content div.highlight {
211 | margin: 16px 0;
212 | padding: $code-block-padding-top;
213 | background: var(--code-block-bg);
214 | border-radius: 4px;
215 | pre {
216 | padding: 0;
217 | }
218 | }
219 |
220 | .docs-content .main-content code {
221 | font-size: inherit;
222 | // color: var(--text-default);
223 | font-weight: 400;
224 | padding: 1px 2px;
225 | background: var(--inline-code-bg);
226 | border: var(--inline-code-border);
227 | border-radius: 4px;
228 | }
229 |
230 | .docs-content .main-content pre {
231 | margin: 0;
232 | // background-color: var(--code-block-bg) !important;
233 | border-radius: 4px;
234 | padding: $code-block-padding-top;
235 |
236 | code {
237 | // color: #f5fbff;
238 | font-size: 0.8rem;
239 | display: block;
240 | // background: var(--code-block-bg);
241 | border: none;
242 | overflow-x: auto;
243 | line-height: 1.5;
244 | padding: 0 2.5rem 1.25rem 2.5rem;
245 | tab-size: 4;
246 | scrollbar-width: thin;
247 | //scrollbar-color: transparent transparent;
248 | }
249 | }
250 |
251 | // bold code
252 | .docs-content .main-content strong {
253 | code {
254 | font-weight: 700;
255 | }
256 | }
257 |
258 | // Chroma Highlighter CSS
259 | .docs-content .main-content td pre {
260 | code {
261 | overflow-x: unset !important;
262 | }
263 | }
264 |
265 | .docs-content .main-content .alert ul {
266 | font-size: var(--font-size-sm);
267 | }
268 |
269 | //
270 |
271 | .docs-content figcaption {
272 | font-size: small;
273 | }
274 |
--------------------------------------------------------------------------------
/content/docs/infra/assets/week2.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
5 | OS Information
6 |
87 |
88 |
89 |
93 |
179 |
180 |
181 |
182 |
193 |
194 |
195 |
About OS
196 |
197 |
OS Type
198 |
Loading...
199 |
Name
200 |
Loading...
201 |
CPU Number
202 |
Loading... Core
203 |
Total Memory
204 |
Loading...
205 |
206 |
207 |
208 |
209 |
--------------------------------------------------------------------------------
/content/docs/plan/4. UX Modeling.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "4. UX Modeling"
3 | description = "데이터가 한 눈에 파악되도록 정리해요!"
4 | icon = "article"
5 | date = "2025-03-05"
6 | lastmod = "2025-03-05"
7 | weight = 440
8 | +++
9 |
10 | ## 📑 **이번 주 학습 내용**
11 |
12 | 이번 주는 수집한 데이터를 분석하고 문제를 정의하는 방법을 알아볼게요! 😉
13 |
14 | 💫 **Keyword**: 어피니티 다이어그램, 페르소나, 사용자 여정 지도, 5 whys
15 |
16 | ---
17 |
18 | ### UX Modeling, 그게 뭐예요?
19 |
20 | UX Modeling은 사용자 경험의 분석하고 보기 쉽도록 정리하는 작업을 말해요. 우리가 앞서 조사한 사용자의 행동, 맥락, 감정 등에서 규칙성이나 패턴을 발견하고 이를 한 눈에 알아볼 수 있도록 만드는 일이죠!
21 |
22 | 단순히 정리하는 과정이 아니라, 이러한 작업을 통해 여러 가지 인사이트를 도출하기도 한답니다 😄
23 |
24 | [UX 디자인이란? (개념편)](https://brunch.co.kr/@youngwookly/12) 👉 UX를 처음 들어봤다면, 이 글을 참고해 주세요!
25 |
26 | [UX 모델링](https://brunch.co.kr/@yan117/110) 👉 UX 모델링의 장점과 필요성을 정리한 글이에요.
27 |
28 | ### Affinity Diagram
29 |
30 | Affinity Diagram은 데이터를 모아 패턴을 파악하고 그 안에서 인사이트를 도출하는 방법이에요. 특히, 서비스를 기획하기 전에 전체적인 방향성을 설계하는 데 매우 큰 도움이 되는 방법이에요!
31 |
32 | 어피니티 다이어그램을 진행하는 순서는 다음과 같아요.
33 |
34 | 1. 인터뷰 기록본 등 수집된 데이터와 네 가지 색의 포스트잇, 펜을 준비해 주세요.
35 | - FigJam, Miro와 같은 디지털 도구를 사용해도 좋아요!
36 | - 네 가지 색이 명확하게 구분될 수 있다면 어떤 색이든 상관 없어요! 여기에서는 노란색, 주황색, 초록색, 파란색을 준비했다고 가정할게요.
37 | 2. 수집한 데이터 중 유의미한 데이터를 선별해 노란색 포스트잇에 적어 주세요.
38 | - 내용을 요약하기 보다는, 최대한 있는 그대로 적어 주세요.
39 | - 한 장의 포스트잇만 보고도 내용이 이해될 수 있도록, ‘의미 단위’로 적어 주세요.
40 | 3. 노란색 포스트잇을 읽어보면서 공통점을 가진 포스트잇끼리 묶어주세요.
41 | - 서로 공통점이 있는 포스트잇을 묶는 과정에서, 새로운 아이디어가 떠오르면 주황색 포스트잇에 함께 적어주세요.
42 | - 이 과정은 가능한 많은 구성원이 함께 참여해야 양질의 결과를 이끌어 낼 수 있어요! 또한, 시간을 두고 다양한 관점에서 패턴을 발견하려 노력해야 해요.
43 | 4. 각 묶음을 대표하는 헤더를 초록색 포스트잇에 작성해 주세요.
44 | - 헤더는 해당 묶음을 가장 잘 나타낼 수 있는 한 문장으로 작성하면 좋아요. 모든 노란색 포스트잇의 요약이 될 필요는 없어요!
45 | - 추가적인 아이디어가 있다면 주황색 포스트잇, 혹은 초록색 포스트잇 근처 등에 적어주세요.
46 | 5. 초록색 포스트잇(헤더)을 여러 가지 조합으로 연결한 결과를 파란색 포스트잇에 작성해 주세요.
47 | - 초록색 포스트잇을 그룹화한다는 생각보다는, 아이디어 도출의 과정이라고 생각하면 좋아요.
48 | - 예를 들어, '작은 목표나 습관으로 가볍게 공부를 시작하는 것이 좋다’라는 헤더와 ‘공부 계획을 세우는 것부터 어렵다’라는 헤더를 합쳐 ‘가장 작은 공부 루틴부터 계획해 주는 기능에 대한 니즈’라는 아이디어를 떠올릴 수 있어요.
49 |
50 |
51 | 깔끔하게 정리하는 것보다는, 여러 시각으로 패턴을 발견하고 그 패턴들을 조합해보려고 시도하는 과정이 더 중요해요. 모든 묶음을 해체하고 처음부터 다시 그룹화하는 과정을 거치는 것을 두려워하지 마세요!
52 |
53 | ### Coding
54 |
55 | 코딩이라는 말에 겁 먹지 마세요! 😂 정성적 데이터 분석에서 사용자의 답변을 요약하고 해석하는 과정을 의미해요. (프로그래밍 언어를 사용하는 것이 아니예요!)
56 |
57 | 코딩을 진행하는 순서는 아래와 같아요.
58 |
59 | 1. 인터뷰 내용 기록본과 새 Excel 파일을 준비해 주세요.
60 | 2. 인터뷰 내용을 의미 단위로 분리해서 엑셀 파일에 적어 주세요.
61 | - 반드시 문장 단위로 쪼개지 않아도 괜찮아요! 같은 문장에 의미가 다른 말이 있다면, 쪼개 주세요.
62 | - 사용자의 비언어적 표현과 (의미 파악에 필요하다면) 인터뷰어의 질문도 함께 적어 주세요.
63 | - 코딩에 있어서 가장 중요한 작업이에요. 하루에 완성하기 보다는, n일에 거쳐 재분류하는 과정을 거치면 좋아요!
64 |
65 |
66 | 3. 분류한 내용을 아주 짧은 문장으로 요약해 주세요.
67 | - 요약된 문장은 ‘code’라고 말해요.
68 | - 해당 내용의 의미를 가장 잘 파악할 수 있는 문장으로 요약하는 것이 좋아요!
69 | - 사용자의 니즈, 활동, 행위, 현상에 대한 이해, 경험, 감정 등이 드러나는 문장이면 좋아요
70 | - 인터뷰어의 주관적인 판단이 가장 많이 개입되는 부분이에요! 혼자서 진행하는 것도 좋지만, 여러 사람이 함께 진행하면 더 좋아요.
71 |
72 |
73 | 4. 코드를 공통된 키워드로 다시 한 번 분류해 주세요.
74 | - 코드의 패턴을 찾는 과정이에요. 키워드가 너무 많으면 패턴을 찾기 어려울 수 있어요! 최대 5개의 키워드를 설정하는 것이 좋아요.
75 | - 키워드는 단어로 구성하는 것이 가장 좋아요.
76 |
77 |
78 | 5. 키워드와 코드, 인터뷰 내용을 검토하면서 다음과 같은 인사이트를 추출해 보세요.
79 | - 같은 키워드 내에 있는 코드들은 어떠한 유사성이 있나요?
80 | - 같은 키워드 내에서 있는 코드들을 봤을 때, 사용자의 행동, 감정 등에서 차이가 존재하나요?
81 | - 서로 연관성이 있는 키워드가 있나요?
82 | - 사용자의 행동, 태도는 어떻게 변화하고 있나요?
83 | - 사용자의 감정이나 기분은 어떻게 변화하고 있나요?
84 | - 사용자가 가장 많이 언급한 키워드는 무엇이었나요?
85 | - 사용자가 가장 크게 부정적인 감정을 느낀 키워드는 무엇이었나요?
86 | - 사용자가 가장 크게 긍정적인 감정을 느낀 키워드는 무엇이었나요?
87 |
88 | 이 외에도, 정말 많은 인사이트를 코딩을 통해 추출할 수 있어요! 특히 사용자의 행동, 감정에 대한 규칙성과 패턴을 파악할 때 정말 유용한 분석 방법이에요 😄
89 |
90 |
91 | [ChatGPT를 활용한 논문쓰기(3): 질적연구 코드 뽑기](https://youtu.be/6MiKdda_DZ4?si=LB2_7jELIdlEsCHS) 👉 Chat GPT를 활용해서 코드를 추출하는 프롬프트를 설명한 영상이에요.
92 |
93 | ---
94 |
95 | ### Persona
96 |
97 |
98 | 페르소나는 사용자를 대표하는 가상의 인물이에요.
99 | 실제 인물이 아니지만, 어디선가 살아 있을 것만 같은 생생한 인물을 만드는 것이 가장 중요한 포인트죠! 😉
100 |
101 | **Persona에 포함될 수 있는 내용**
102 |
103 | - 페르소나의 사진
104 | - 태그라인
105 | - 인구통계학적 정보 (나이, 성별, 거주지, 직업, 자산 등)
106 | - 성향 (요즘은 MBTI로 나타내기도 해요!)
107 | - 행동 양상, 생활 패턴, 스토리
108 | - 취미, 관심사
109 | - 자주 사용하는 서비스, 브랜드 등
110 | - 불편함(Pain Point)
111 | - 필요(Needs)
112 | - 목표(Goal)
113 |
114 | [가상의 사용자를 만드는 방법, 페르소나(persona)](https://brunch.co.kr/@axdfc/11) 👉 페르소나를 설정하는 방법을 알려주는 글이에요.
115 | [고객 페르소나 : 어떤 타겟에 집중해야 할까?](https://apcreative.kr/persona) 👉 가상의 페르소나를 설계하는 사례를 담은 글이에요. 페르소나 설정이 막막할 때 예시로써 참고하면 좋아요!
116 |
117 | ### User Journey Map
118 |
119 |
120 |
121 | User Journey Map은 사용자가 서비스를 이용하는 과정을 시각적으로 표현한 지도예요. 사용자가 서비스를 접하는 순간부터 최종 목표를 달성할 때까지의 과정을 분석하면서, 사용자가 불편함을 느끼는 시점을 더욱 면밀하게 파악할 수 있다는 것이 가장 큰 장점이에요! 일반적으로 페르소나를 설정한 후에 제작하곤 해요.
122 |
123 | [사용자의 경험 최적화를 위한 고객여정지도](https://office-life.tistory.com/50) 👉 사용자 여정 지도를 만드는 방법과 구성 요소를 담고 있는 글이에요.
124 |
125 | [디자인 씽킹 ⑪ - 뷰카월드(VUCA World)를 현명하게 대처하기 1](https://www.samsungsds.com/kr/insights/vuca_world.html) 👉 실제 기업의 사용자 여정 지도가 궁금하다면, 이 글도 참고해 보세요!
126 |
127 | 사용자 여정 지도는 설계하는 목적, 설계하는 사람 등에 따라 조금씩 달라질 수 있어요. 여러 가지 사용자 여정 지도의 사례를 비교해 보세요!
128 |
129 | **Persona, User Journey Map을 제작할 때 주의할 점**
130 |
131 | 1. 페르소나와 사용자 여정 지도는 반드시 각각 1장으로 만들어야 해요.
132 | - 페르소나와 사용자 여정 지도의 핵심은 ‘한 눈에 파악할 수 있어야 한다’는 것이에요.
133 | - 특히, 사용자 여정 지도가 2장 이상으로 제작되면 사용자 행동의 흐름을 파악하기 어려워 져요.
134 | 2. 반드시 리서치 데이터를 기반으로 만들어야 해요.
135 | - 나, 혹은 팀원의 추측이나 주관적인 의견이 들어가는 것을 가급적 피해야 해요. 실제 사용자를 이해하는 데에 오류가 생길 수 있기 때문이에요.
136 | 3. 페르소나와 사용자 여정 지도는 2가지 이상의 케이스로 제작될 수 있어요.
137 | - 예를 들어, 온라인 쇼핑몰 서비스에는 상품을 판매하는 판매자와 상품을 구매하는 구매자로 사용자의 유형이 분류될 수 있어요. 이때, 하나의 페르소나 혹은 여정 지도만 만들면 판매자 혹은 구매자 중 한 유형의 사용자는 전혀 고려할 수 없게 돼요.
138 | - 하지만 너무 많은 케이스를 만들면 주요 사용자 층에 집중할 수 없게 되어요. 따라서 4가지 이상의 케이스를 제작하는 것은 최대한 피해 주세요!
139 |
140 | ### 5 Whys
141 |
142 | 서비스를 기획할 때 가장 중요한 것은 '진짜 문제'를 정의하는 것이에요.
143 |
144 | 단순히 사용자가 ‘불편하다’라고 말하는 것을 있는 그대로 문제 삼는 것이 아니라, ‘왜’ 불편한지에 대한 근본적인 원인을 찾았을 때, 우리는 문제를 정의했다고 말할 수 있어요. 5 Whys는 문제의 근본적인 원인을 찾기 위해 사용할 수 있는 좋은 방법론이랍니다 😊
145 |
146 | [다섯 개의 '왜' The five Whys](https://deep-wide-studio.tistory.com/17) 👉 5 Whys에 대한 기본적인 설명과 주의할 점이 담겨있어요.
147 |
148 | [5 Whys 기법이 잘못된 이유](https://brunch.co.kr/@p3tree784/105) 👉 5 Whys의 근본적인 필요성과 새로운 접근 방식에 대한 제안이 담긴 글이에요!
149 |
150 | [5 Whys로 '진짜' 문제 찾기](https://brunch.co.kr/@famelee/8) 👉 5 Whys를 실무에 적용한 사례가 담긴 글이에요. (꼭 읽어보세요!)
151 |
152 | 언뜻 보면 단순하고 쉬워 보이지만, 막상 해 보면 고민이 가장 많이 필요한 방법론이에요!
153 | 형식 상으로 대충 진행하다 보면 ‘시간이 부족해서’, ‘자원이 부족해서’, ‘투자가 부족해서’와 같은 원론적이고 추상적인 원인 도출로 결론이 날 수도 있어요. 기획은 창의적인 해결 방안 도출보다 정확한 문제 정의가 우선이어야 한다는 것을 꼭 기억하세요!
154 |
155 | ---
156 |
157 | ## ✏️ 과제 안내
158 |
159 | 4주차에는 아래와 같은 과제를 차례대로 수행해 보아요! 🤗
160 |
161 | 1. 내가 코드당을 사용했던 경험을 사용자 여정 지도로 나타내 보세요.
162 | 2. 사용자 여정 지도를 기반으로 코드당에서 가장 먼저 해결하고자 하는 문제를 하나 선정해 보세요.
163 | 3. 해당 문제의 원인을 5 whys로 분석해 보세요.
164 | 4. 분석된 문제를 해결하기 위한 아이디어를 구상해 보세요.
165 | - 반드시 한 가지의 아이디어를 결정할 필요는 없어요. 다양한 아이디어를 구상해 보고, 스터디 시간에 함께 이야기를 나누며 문제 해결에 가장 적절한 아이디어를 선정해 보아요! 😉
166 |
--------------------------------------------------------------------------------
/content/docs/backend/7. Prisma.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "7. Prisma"
3 | description = "데이터베이스를 쉽게 쓰도록 도와주는 ORM인 Prisma에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2023-09-08"
7 | weight = 170
8 | +++
9 |
10 | 이번 시간에는 Node.js & TypeScript의 ORM 중 하나인 Prisma에 대해 알아봅시다.
11 |
12 | ## 공부할 내용 📚
13 |
14 | ### 1. Prisma가 무엇인가요?
15 |
16 | ORM...?? ORM은 뭐고, Prisma는 또 무엇일까요?
17 |
18 | ORM의 의미와, Prisma가 어떤 서비스인지 한 번 알아봅시다!
19 |
20 | - [ORM이 뭘까?](https://velog.io/@gndan4/ORM이란): ORM이 뭔지 간단히 알아봅시다!
21 | - 이외에도 구글링하면 ORM에 대해서 많은 정보들이 나오니 참고해주세요! 😀
22 | - [Is Prisma an ORM?](https://www.prisma.io/docs/orm/overview/prisma-in-your-stack/is-prisma-an-orm): Prisma 공식문서에서 Prisma가 무엇인지, 어떤 원리로 작동되는지에 대해서 간단히 소개해줍니다.
23 | - [Prisma란?](https://velog.io/@hwisaac/Prisma-%EB%9E%80): 한글로도 짧게 정리한 블로그 글도 가져와봤습니다!
24 |
25 | ### 2. Prisma
26 |
27 | 이제 ORM이 무엇이고, Prisma는 어떤 서비스인지 알아보았으니 구체적으로 어떻게 사용할 수 있는지 알아볼까요?
28 |
29 | - [What is Prisma?](https://www.prisma.io/docs/orm/overview/introduction/what-is-prisma): Prisma의 작동 원리에 대해서 알아봅니다. 꼭 읽어봐주세요!! ⭐️
30 | - [Prisma schema](https://www.prisma.io/docs/orm/prisma-schema/overview): Prisma는 schema 파일을 통해 다양한 설정 정보를 얻고 어떠한 데이터 모델을 생성할지 파악합니다. schema 파일이 어떻게 구성되어 있고, 데이터 모델은 어떻게 작성할 수 있는지 살펴봐야겠죠? 😆
31 | - [Prisma CRUD](https://www.prisma.io/docs/orm/prisma-client/queries/crud): Prisma에서는 아주 많은.... 기능들이 있는데요, 이번에는 그중 실습때 쓰이는 CRUD관련 기능만 살펴봐주세요 🙂
32 | - [Prisma Playground](https://playground.prisma.io): Prisma에서는 Playground를 통해 웹에서도 테스트할 수 있도록 해줘요! Playground를 통해 한 번 테스트해봐도 좋아요!
33 | - [Prisma Client API reference](https://www.prisma.io/docs/orm/reference/prisma-client-reference): API reference인데, 궁금하신 부분있으면 찾아봐도 괜찮을 것 같아요!
34 |
35 | ## 프로젝트 실습 🎈
36 |
37 | 이번 주차는 저번 주차에서 만들었던 Nest.js 웹서버에서 실제 데이터베이스(PostgreSQL)에 prisma를 이용하여 CRUD 코드를 작성해보는 과제입니다.
38 |
39 | > 환경 설정 관련해서 아래 지시사항을 따라해주세요!
40 | > 물론 꼭 그대로 따라하실 필요는 없고 자신의 데이터 구조에 따라 바꾸셔도 괜찮습니다!
41 |
42 | ### 실습 세부 설명 ⚙️
43 |
44 | 환경세팅과 관련해서 도와드릴게요!
45 | 밑의 절차를 따라와주세요
46 |
47 | > 참고 : https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmOL0
48 |
49 | 시작 전, [Docker 설치 가이드](../infra/Install%20Docker.md)를 참고하여 Docker를 설치해주세요!
50 |
51 | Root 디렉토리에 `docker-compose.yml`를 생성하고, 아래 파일을 복사-붙여넣기 해주세요.
52 | ```docker
53 | # docker-compose.yml
54 |
55 | version: '3.8'
56 | services:
57 | postgres:
58 | image: postgres:13.5
59 | restart: always
60 | environment:
61 | - POSTGRES_USER=myuser
62 | - POSTGRES_PASSWORD=mypassword
63 | volumes:
64 | - postgres:/var/lib/postgresql/data
65 | ports:
66 | - '5432:5432'
67 |
68 | volumes:
69 | postgres:
70 | ```
71 | 그 뒤, 터미널에서 `docker-compose up -d` 을 실행하고(`-d`는 백그라운드에서 실행하는 옵션) , 정상적으로 컨테이너가 생성되고 실행되는지 확인해주세요
72 |
73 | - 터미널에 Running 표시 혹은 docker gui 에서 실행되고 있다면 성공입니다
74 | - **🛠️ 백그라운드에서 정상적으로 작동해야지 밑의 과정에서 오류가 생기지 않습니다!**
75 |
76 |
77 | 다음으로 터미널에 `npm install -D prisma` 을 입력해 prisma 를 설치해줍니다.
78 |
79 | 루트 디렉토리에서 `npx prisma init` 를 입력하면, prisma 폴더와 Schema 파일이 생성된 것을 확인할 수 있습니다.
80 |
81 | - 루트 폴더에 ***.env*** 파일이 생성되었는 것을 볼 수 있는데요, 안에는 database_url 이 들어있을 건데 밑과 같이 변경해줍니다.
82 |
83 | ```docker
84 | // .env
85 | DATABASE_URL="postgres://myuser:mypassword@localhost:5432/median-db"
86 | ```
87 |
88 | `prisma/schema.prisma` 에 들어가 맨 밑에 restaurant model 을 추가해줍시다!
89 | - 자신의 데이터구조에 맞게 자유롭게 작성해주시면 됩니다! 제가 작성한 예시를 남겨드립니다.
90 |
91 | ```docker
92 | // This is your Prisma schema file,
93 | // learn more about it in the docs: https://pris.ly/d/prisma-schema
94 |
95 | generator client {
96 | provider = "prisma-client-js"
97 | }
98 |
99 | datasource db {
100 | provider = "postgresql"
101 | url = env("DATABASE_URL")
102 | }
103 |
104 | model Restaurant {
105 | id Int @id @default(autoincrement())
106 | name String @unique
107 | address String
108 | phone String
109 | createdAt DateTime @default(now())
110 | updatedAt DateTime @updatedAt
111 | }
112 | ```
113 |
114 | 다음, 우리가 생성한 데이터 모델을 migrate하기 위해 아래 명령어를 입력해줍니다.
115 | ```shell
116 | npx prisma migrate dev --name "init"
117 | ```
118 | - 성공적으로 되었다면 terminal에 `Your database is now in sync with your schema`라는 문장과 함께 `prisma` 안에 `migration` 폴더가 생성되는 것을 확인할 수 있어용
119 |
120 | 원활한 테스팅을 위해 데이터베이스에 미리 seed 데이터도 심어놓읍시다.
121 | - 아래 `seed.ts`를 생성해주세요! (데이터 구조는 자신의 것과 일치하게 수정해주셔도 됩니당)
122 | ```jsx
123 | // prisma/seed.ts
124 |
125 | import { PrismaClient } from '@prisma/client';
126 |
127 | // initialize Prisma Client
128 | const prisma = new PrismaClient();
129 |
130 | async function main() {
131 | // create two dummy articles
132 | const restaurant1 = await prisma.restaurant.upsert({
133 | where: { name: '봉수육' },
134 | update: {},
135 | create: {
136 | name: '봉수육',
137 | address: '경기 수원시 장안구 율전로108번길 11 1층',
138 | phone: '0507-1460-0903',
139 | },
140 | });
141 |
142 | const restaurant2 = await prisma.restaurant.upsert({
143 | where: { name: '청년밥상' },
144 | update: {},
145 | create: {
146 | name: '청년밥상',
147 | address: '경기 수원시 장안구 서부로2136번길 10 1층',
148 | phone: '0507-1307-1822',
149 | },
150 | });
151 |
152 | console.log({ restaurant1, restaurant2 });
153 | }
154 |
155 | // execute the main function
156 | main()
157 | .catch((e) => {
158 | console.error(e);
159 | process.exit(1);
160 | })
161 | .finally(async () => {
162 | // close Prisma Client at the end
163 | await prisma.$disconnect();
164 | });
165 | ```
166 |
167 | 그리고 `package.json`에 아래 명령어를 추가해주세요.
168 | ```jsx
169 | // package.json
170 |
171 | // ...
172 | "scripts": {
173 | // ...
174 | },
175 | "dependencies": {
176 | // ...
177 | },
178 | "devDependencies": {
179 | // ...
180 | },
181 | "jest": {
182 | // ...
183 | },
184 | **"prisma": {
185 | "seed": "ts-node prisma/seed.ts"
186 | }**
187 | ```
188 | 그리고 터미널에 `npx prisma db seed`를 입력해주시면 귀여운 새싹모양 아이콘이 뜰거에요ㅎ.ㅎ
189 |
190 | prisma를 연결해주기 위해
191 |
192 | ```shell
193 | npx nest generate module prisma
194 | npx nest generate service prisma
195 | ```
196 |
197 | 를 입력해주시고, `prisma.service.ts` 파일을 조금 수정해줍니다.
198 |
199 | ```jsx
200 | // src/prisma/prisma.service.ts
201 |
202 | import { INestApplication, Injectable } from '@nestjs/common';
203 | import { PrismaClient } from '@prisma/client';
204 |
205 | @Injectable()
206 | export class PrismaService extends PrismaClient {
207 | async enableShutdownHooks(app: INestApplication) {
208 | this.$on('beforeExit', async () => {
209 | await app.close();
210 | });
211 | }
212 | }
213 | ```
214 |
215 | 그리고 `prisma.module.ts` 도 수정해줍니다. (exports에 추가)
216 |
217 | ```jsx
218 | // src/prisma/prisma.module.ts
219 |
220 | import { Module } from '@nestjs/common';
221 | import { PrismaService } from './prisma.service';
222 |
223 | @Module({
224 | providers: [PrismaService],
225 | exports: [PrismaService],
226 | })
227 | export class PrismaModule {}
228 | ```
229 |
230 | 마지막으로 저희 Restaurant 모듈에서 쓰기 위하여 service, module 파일을 조금 수정해주세요!
231 | - 밑에는 예시 코드입니다.
232 | ```jsx
233 | //restaurant.module.ts
234 | import { Module } from '@nestjs/common';
235 | import { PrismaModule } from 'src/prisma/prisma.module';
236 | import { RestaurantController } from './restaurant.controller';
237 | import { RestaurantService } from './restaurant.service';
238 |
239 | @Module({
240 | controllers: [RestaurantController],
241 | providers: [RestaurantService],
242 | imports: [PrismaModule],
243 | })
244 | export class RestaurantModule {}
245 | ```
246 |
247 | ```jsx
248 | //restaurant.service.ts
249 | import { Injectable } from '@nestjs/common';
250 | import { PrismaService } from 'src/prisma/prisma.service';
251 |
252 | @Injectable()
253 | export class RestaurantService {
254 | constructor(private prisma: PrismaService) {}
255 |
256 | //example
257 | async getAllRestaurants() {
258 | return await this.prisma.restaurant.findMany({
259 | select: {
260 | name: true,
261 | address: true,
262 | phone: true,
263 | },
264 | });
265 | }
266 | }
267 | ```
268 |
269 | 이제 직접 CRUD 코드를 작성하면 됩니다. 😆
270 | - 참고로, `npx prisma studio` 를 입력하면 5555포트에서 정말 간편하게 db 를 눈으로 확인할 수 있으니 애용해주세요 😻
271 |
--------------------------------------------------------------------------------
/content/docs/backend/2. Node.js.md:
--------------------------------------------------------------------------------
1 | +++
2 | title = "2. Node.js"
3 | description = "JavaScript와 Node.js에 대해 알아봅니다."
4 | icon = "article"
5 | date = "2023-09-08"
6 | lastmod = "2023-09-08"
7 | weight = 120
8 | +++
9 |
10 |
11 |
12 | 스꾸딩에서 가장 많이 사용하는 언어는 JavaScript입니다. JavaScript는 웹 브라우저에서 동작하는 언어로 시작했지만, Node.js를 통해 서버에서도 동작할 수 있게 되었습니다. Node.js는 서버에서 JavaScript를 읽고 실행할 수 있게 해주는 런타임입니다.
13 |
14 | 이번 주에는 JavaScript의 문법을 공부하고, Node.js를 통해 간단한 서버용 프로그램을 만들어보는 것을 목표로 합니다.
15 |
16 | 특히 백엔드분들은 문법 관련해서 꼼꼼히! 읽어보시는 것을 권장드립니다 (정리는 꼼꼼히 안하셔도 괜찮아요)
17 |
18 | **아래의 모든 자료는 참고 자료일 뿐이고, 자유롭게 검색해서 공부하셔도 됩니다! 😎**
19 |
20 | ## 공부할 내용 📚
21 |
22 | ### 1. JavaScript & Node.js란?
23 |
24 | JavaScript는 웹 브라우저에서 동작하는 언어로, 원래 프론트엔드에서 많이 쓰이는 언어였습니다. Node.js는 서버에서 JavaScript를 동작시킬 수 있게 해주는 런타임으로, Node.js 덕분에 백엔드에서도 JavaScript로 서버 프로그램을 작성할 수 있게 되었습니다.
25 |
26 | JavaScript와 Node.js의 탄생 배경과 특징에 대해 알아봅니다.
27 |
28 | - **드림코딩 "자바스크립트 배우기 전 꼭 봐야할 영상"(약 16분)**: JavaScript의 역사와 특징을 정리한 영상입니다.
29 | https://youtu.be/wcsVjmHrUQg?si=fR4oIIQ_LH-73jEq
30 |
31 | - **코딩애플 "Node.js가 뭔지 알아보자" (약 5분)**: Node.js의 특징을 간단하게 정리한 영상입니다.
32 | https://youtu.be/pTm5E3jcOeY?si=z6zhwPS3GHO35rmu
33 |
34 | - **하나몬 "Node.js 개념 이해하기" (글)**: Node.js의 특징과 원리, 이벤트 루프에 대해 가볍게 정리한 글입니다.
35 | https://hanamon.kr/nodejs-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/
36 |
37 | ### 2. JavaScript 문법
38 |
39 | JavaScript의 문법을 공부합니다. 아래 개념들을 검색하고 정리해보세요. 각종 method들은(`length`, `push` 등) 자세하게 정리할 필요는 없고, 간단하게 어떤 기능을 하는지만 훑어두면 됩니다.
40 |
41 | - 변수 (var, let, const)
42 | - 자료형 (Number, String, Boolean, Array, Object)
43 | - 연산자 (산술 연산자, 비교 연산자, 논리 연산자)
44 | - 조건문 (if)
45 | - 반복문 (for, while)
46 | - 함수 (function, arrow function)
47 | - 객체 (Object)
48 | - 배열 (Array)
49 | - **비동기 (Promise, async/await)** → 중요! 🔥
50 |
51 | 아래는 JavaScript 문법을 공부할 수 있는 관련 자료입니다.
52 |
53 | **저는 개인적으로 코어 자바스크립트 한 번 훑어보는 것을 추천드려요.**
54 |
55 | - **드림코딩 자바스크립트 입문**: 빠르게 코드만 보고 싶은 분들을 위해 문법을 정리한 repo입니다. 더 자세한 설명을 위해서는 유튜브 영상도 참고해주세요.
56 | https://github.com/dream-ellie/learn-javascript
57 | - **코어 자바스크립트**: 분량이 많아 전부 읽는 것은 어렵고, 필요한 부분을 찾아서 읽어보세요. '자바스크립트 기본', '객체: 기본', '자료구조와 자료형', '프라미스와 async, await', '모듈' 정도를 읽어보면 좋을 것 같아요.
58 | - 그리고 '함수 심화학습' 중 '나머지 매개변수와 스프레드 문법', '오래된 var', '화살표 함수 다시 살펴보기'도 읽어주시면 좋을 것 같아요!
59 |
60 | https://ko.javascript.info/js
61 |
62 | ### 3. Node.js만의 기능
63 |
64 | 웹 브라우저의 JavaScript 런타임에는 없는 Node.js만의 기능들을 알아봅니다. 아래와 같은 내용들을 공부해보세요.
65 |
66 | - os 모듈
67 | - fs 모듈
68 | - path 모듈
69 | - http 모듈
70 | - http모듈 참고용: https://nodejs.org/ko/docs/guides/anatomy-of-an-http-transaction
71 | - 공식문서: https://nodejs.org/api/
72 |
73 | ### 4. API Testing Tool
74 |
75 | 백엔드의 주요 업무가 API를 설계하고 개발하는 일인만큼, 직접 API를 보내고 테스트할 수 API Testing Tool을 설치해 사용해보는 것을 권장드립니다.
76 |
77 | 다양한 API Testing Tool이 있는데, 자유롭게 선택하셔서 설치해주시면 됩니다.
78 |
79 | 예시로, 유명한 툴 중 하나가 'Postman'인데요, 아래 사진처럼 원하는 API를 직접 전송하고 응답까지 확인할 수 있습니다.
80 |
81 | https://www.postman.com
82 |
83 |
84 |
85 |
86 |
87 | 그...런..데
88 | 사실 저희 스꾸딩에서는 Bruno를 쓴답니다?ㅎㅎ
89 |
90 |
91 | Postman은 원할한 협업을 위해선 결제가 필요하여.. 오픈소스인 Bruno를...
92 |
93 | 스터디를 하는 동안에 실습을 위해선 Postman을 사용하셔도 무방하지만, 본격적으로 개발을 시작하시게 되면 Bruno를 사용하셔야하니 지금부터 Bruno로 해주시는게 좀 더 좋을겁니다✨
94 |
95 | 아래의 링크에서 다운받으시면 돼유~!
96 |
97 | https://www.usebruno.com/downloads
98 |
99 |
100 | ## 프로젝트 실습 🎈
101 |
102 | 이번 백엔드 프로젝트는 간단하게 judger를 만들어봐요. 서버를 실행하고 [http://localhost:3000](http://localhost:3000)에 접속하면 아래 사진처럼 파이썬 코드를 보냈을 때, local에서 코드를 실행하고 결과값을 돌려주도록 하면 됩니다.
103 |
104 | > 여기에서는 python이 local에 설치되어 있다는 전제하에 진행됩니다. (다들.. 있으시죠?)
105 |
106 | 실습하신 내용 또한 Notion에 같이 정리해주세요!
107 |
108 |
109 |
110 |
111 |
112 | **조건 및 힌트**
113 | - http 모듈로 서버를 만들어보세요. 포트 번호는 3000번으로 지정해주세요.
114 | - 요청 메서드는 `POST`, 코드 데이터는 body에 담아서, 그리고 URL은 `/code`로 설정해주세요.
115 | - 요청이 오면, 코드를 읽은 다음 `fs` 모듈을 사용하여 파이썬 파일을 생성해주세요. 그 다음, node.js에 있는 [`child_process` 모듈](https://nodejs.org/api/child_process.html)을 이용하여 command(ex.`python3 `)를 실행시킨뒤, 출력을 응답에 담아 보낼 수 있도록 해주세요. (양식은 자유입니다.)
116 | - 에러핸들링은 자유입니다.
117 |
118 | 혹시 처음부터 하려니 너무 막막하실까봐 관련된 예제코드를 하나 보여드립니다.
119 | 정~~~~~~~~말 모르겠을때만 보고 참고해주세요!
120 |
121 |
122 | 예제코드
123 |
124 | 아래의 코드는 http://localhost:3000/run으로 POST 메서드를 사용해 명령어를 담아 HTTP 요청을 보내면
125 |
126 | 서버 컴퓨터에서 명령어가 실행된 후 결과를 반환하는 간단한 코드입니다
127 |
128 | ```js
129 | const http = require('http');
130 | const { exec } = require('child_process');
131 |
132 | const server = http.createServer((req, res) => {
133 | if (req.method === 'POST' && req.url === '/run') {
134 | let body = '';
135 | req.on('data', chunk => (body += chunk));
136 | req.on('end', () => {
137 | const { command } = JSON.parse(body);
138 | if (!command) {
139 | res.writeHead(400, { 'Content-Type': 'application/json' });
140 | res.end(JSON.stringify({ error: 'No command provided' }));
141 | return;
142 | }
143 |
144 | exec(command, (error, stdout, stderr) => {
145 | res.writeHead(200, { 'Content-Type': 'application/json' });
146 | res.end(
147 | JSON.stringify({
148 | stdout,
149 | stderr,
150 | error: error ? error.message : null,
151 | })
152 | );
153 | });
154 | });
155 | } else {
156 | res.writeHead(404);
157 | res.end();
158 | }
159 | });
160 |
161 | server.listen(3000, () => {
162 | console.log('Server listening on port 3000');
163 | });
164 |
165 |
166 | ```
167 | 이 코드를 실행하고 ls 같은 명령어를 보내보시면 응답이 올겁니당🦭✨
168 |
169 | ~~절대절대절대 sudo rm -rf / 같은건 보내보지 마세요?^^~~
170 | 오히려 하지말라니까 더 하는 사람 있을까봐 걱정돼서 그러는데 진짜하지마요...
171 |
172 | 아무튼 위의 코드를 실행해보시면 대략 감이 잡히실겁니다~!
173 |
174 | 사실상 저기다가 fs를 이용해서 파이썬 코드 저장만 하면 되잖아유~?행운을 빌어요
175 |
176 |
177 |
178 | ## 설치 & 실행 ⚙️
179 |
180 | ### WSL 설치 (윈도우만)
181 |
182 | WSL(Window Subsystem for Linux)은 윈도우에서 리눅스를 실행할 수 있게 해주는 기능입니다. 앞으로 리눅스 명령어를 사용할 일이 많아지기 때문에 WSL을 설치하고 사용하는 것을 추천합니다. 가이드를 참고하여 WSL을 설치해주세요. ([WSL 설치 가이드](../infra/Install%20WSL.md))
183 |
184 | ### Visual Studio Code 설치
185 |
186 | Visual Studio Code는 Microsoft에서 만든 텍스트 편집기입니다. 스꾸딩의 개발 환경은 주로 Visual Studio Code를 사용합니다. 아래 링크를 통해 Visual Studio Code를 설치해주세요.
187 | https://code.visualstudio.com/
188 |
189 | {{< figure src="https://code.visualstudio.com/assets/docs/languages/typescript/overview.png" alt="Visual Studio Code" >}}
190 |
191 | ### Node.js 설치
192 |
193 | #### 1. NVM 설치
194 |
195 | nvm은 Node.js의 버전을 관리해주는 도구입니다. 보통 nvm을 통해 Node.js를 설치하고 사용합니다. 아래 명령어를 입력하여 nvm을 설치합니다.
196 |
197 | ```bash
198 | curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.5/install.sh | bash
199 |
200 | 이후 터미널을 재시작하거나 아래 명령어를 입력하여 nvm을 사용할 수 있게 합니다.
201 |
202 | ```bash
203 | source ~/.bashrc
204 | # zsh를 사용하는 경우
205 | # source ~/.zshrc
206 | ```
207 |
208 | nvm이 정상적으로 설치되었는지 확인합니다.
209 |
210 | ```bash
211 | nvm --version
212 | # 0.39.5
213 | ```
214 |
215 | 공식 가이드는 아래 링크에 있습니다.
216 | https://github.com/nvm-sh/nvm#install--update-script
217 |
218 | #### 2. Node.js 설치
219 |
220 | nvm을 통해 Node.js를 설치합니다. 아래 명령어를 입력하여 Node.js를 설치합니다.
221 |
222 | ```bash
223 | nvm install --lts
224 | # LTS 버전 대신 최신 버전을 설치하고 싶은 경우
225 | # nvm install node
226 | ```
227 |
228 | Node.js가 정상적으로 설치되었는지 확인합니다.
229 |
230 | ```bash
231 | node --version
232 | # v18.17.1 (버전은 다를 수 있습니다)
233 | ```
234 |
235 | ### JavaScript 실행해보기
236 |
237 | JavaScript는 여러 방법으로 실행할 수 있습니다. 아래 두 가지 방법을 통해 JavaScript를 실행해보세요.
238 |
239 | #### REPL로 실행하기
240 |
241 | 아래 명령어를 입력하여 REPL을 실행합니다.
242 |
243 | ```bash
244 | node
245 | ```
246 |
247 | REPL에서 아래 코드를 입력하고 엔터를 누르면 코드가 실행됩니다.
248 |
249 | ```javascript
250 | console.log('Hello, world!')
251 | // Hello, world!
252 | ```
253 |
254 | #### 파일로 실행하기
255 |
256 | 아래 코드를 `hello.js`라는 이름으로 저장합니다.
257 |
258 | ```javascript
259 | console.log('Hello, world!')
260 | ```
261 |
262 | 아래 명령어를 입력하여 `hello.js`를 실행합니다.
263 |
264 | ```bash
265 | node hello.js
266 | # Hello, world!
267 | ```
268 |
--------------------------------------------------------------------------------
22 | 
30 | 
38 | 
46 | 
54 | 
64 | 
72 | 
80 | 
88 | 
96 | 
104 | 
80 | 
71 | 
85 | 
110 |