[TIL] Udemy 5일차 프론트엔드/백엔드 - HTML & CSS 레이아웃 및 포지셔닝 이해

강준호·2023년 12월 19일
개발부트캠프백엔드유데미유데미부트캠프유데미취업부트캠프유데미큐레이션프론트엔드

Udemy

목록 보기
6/44
post-thumbnail

CSS 속성들

overflow

  • 넘친 부분을 통제할 수 있게합니다.

  • 컨테이너를 초과하는 무언가를 고정시켜줌.

  • visible(기본값), hidden

CSS 그리드

CSS 그리드

  • 2차원 레이아웃에서 주로 사용
display: grid;
/* 그리드의 컨테이너가 두개의 열로 나눠진다 */
  grid-template-columns: 1fr 1fr;

fraction

  • 그리드 내 사용가능한 영역의 사용가능

li:nth-of-type(){}

li:nth-of-type(3){
    grid-column: 1/span 2;
}
  • 첫 번째 열 행부터 시작하여 그리드 레이아웃의 두 열에 걸쳐 있음

gap

  • 행과 열 사이의 간격을 설정할 수 있다.
  • grid-gap
  • grid-row-gap
  • grid-column-gap

정렬

  • 내부 정렬을 위해
  • align-items
  • justify-items
  • align-content
  • justify-content 사용가능

그리드 참고 블로그
https://studiomeal.com/archives/533

UTF-8 특수기호

  • Ex) Explore →

추가 공부

위치 속성에 대한 추가 정보

=>https://academind.com/tutorials/the-position-property/

플렉스박스 - 플렉스 컨테이너

=> https://academind.com/tutorials/flexbox-basics-container/

플렉스박스 - 플렉스 아이템

=> https://academind.com/tutorials/flexbox-flex-items/

플렉스박스와 그리드 비교

=> https://academind.com/tutorials/css-grid-vs-flexbox/

반응형 디자인

px

  • 픽셀은 절댓값을 사용하는 고정된 크기의 단위

  • 장점: 이해하기 쉽고 정확합니다.

  • 단점: 사용자의 글꼴 크기 설정을 무시해 버리는 것과 같이 심각한 접근성 문제가 발생할 수 있습니다. 가끔 짜증나게 글씨 작은 컨텐츠들.

%

  • 백분율 값은 상위 요소의 동일한 속성을 기준으로 합니다. ex) 요소의 너비가 50%면 해당 요소의 너비는 상위 요소의 절반.

  • 백분율은 레이아웃 구조에 이상적이므로 전체 디자인이 화면 크기에 반응

  • 백분율은 상위 요소의 글꼴 크기를 기준으로 합니다. 부모에 종속적

  • 단순한 글꼴 크기 조정(예: 너비 및 높이) 이상의 용도로 사용.

  • 장점: 상위 요소의 글꼴 크기에 따라 크기가 조정되어 일정 수준의 확장성을 제공합니다.

  • 단점: 계산된 크기는 상위 글꼴 크기에 따라 달라지므로 예측할 수 없게 될 수 있습니다.

  • 예시: 상위 요소의 글꼴 크기가 20px이고 하위 요소의 글꼴 크기가 'font-size: 50%;'인 경우 하위 요소의 글꼴 크기는 10px(20px의 50%)가 됩니다.

em

  • 글꼴 크기에 따라 크기가 조정됨으로 인쇄 요소,텍스트에 사용하면 적합하다.

  • 상위 요소의 글꼴 크기를 기준으로 합니다. 1em은 요소의 현재 글꼴 크기 또는 브라우저 기본값과 같습니다. 부모에 종속적.

  • 장점: 확장성과 반응성이 뛰어납니다. 구성 요소 내에서 상대적인 크기를 만드는 데 적합합니다.

  • 단점: 크기 조정이 복잡해질 수 있습니다(em 값이 중첩 수준에 따라 증가하여 예상치 못한 크기가 발생함).

  • 예시: 각각 '글꼴 크기: 2em;'이 포함된 중첩된 요소가 있고 기본 글꼴 크기가 16px인 경우 첫 번째 요소의 글꼴 크기는 32px이고 해당 요소의 하위 요소에는 글꼴이 있습니다. 32px가 아닌 64px(2 * 32px) 크기입니다.

rem

  • 원하는 글꼴 크기를 지정 + 크기를 변경하고 싶은 사용자의 요구 => 유연하게 반응할 수 있다는 것

  • em과 유사하지만 항상 상위 요소가 아닌 루트 요소(html)를 기준으로 합니다.

  • 장점: 항상 루트 글꼴 크기를 기준으로 하므로 페이지 전반에 걸쳐 일관성을 제공합니다. 페이지 전체의 크기 조정을 단순화합니다.

  • 단점: em에 비해 개별 구성 요소 내 유연성이 떨어집니다.

% vs em

  • em과 %는 모두 상대 단위이지만 서로 다른 것(em은 글꼴 크기, %는 상위 요소 크기)에 상대적이고 웹 디자인에서 다른 목적을 제공하기 때문에 별도로 사용됩니다.

em vs rem

  • 루트 글꼴 크기가 16px로 설정된 문서를 가정.
  • 단락의 글꼴 크기를 2em으로 설정하고 상위 요소를 1.5em으로 설정하면 단락의 글꼴 크기는 2 1.5 16px = 48px가 됩니다.
  • 그러나 단락의 글꼴 크기를 2rem으로 설정하면 상위 글꼴 크기에 관계없이 2 * 16px = 32px가 됩니다.

그럼 언제 무엇을 사용해야할까?

px

  • 고정 너비 요소에. ex) 경계선 곡률.

%

  • 레이아웃 요소에 사용하여 다양한 화면 크기에 맞게 조정합니다.

em

  • 상대적인 크기를 유지하려는 확장 가능한 구성 요소에

rem

  • 웹사이트 전체에서 일관된 확장성을 유지하려면 대부분의 글꼴 크기에 rem을.

이러한 단점에도 px 이 사용되는 이유?

  • 스케치나 피그마와 같이 가장 진보한 UI 소프트웨어에서조차도 현재 rem/em 단위로 지원하지 않는다고 한다. => 2023년 7월 패치로 시작!

  • UX/UI 디자이너는 px 를 사용해야한다.

멘토링 QnA

Q. DBMS의 Stored Procedure 사용에 있어 베스트 프랙티스 또는 가이드 라인에 대해 질문 드립니다! Stored Procedure는 주로 비즈니스 로직을 구현하고자 할 때 사용된다는 내용을 접하게 되었습니다. 그리고 이는 3 tier achitecture를 기준 삼아 보았을 때, ‘data tier에서 logic을 처리하게 된다는 면에서 단점이 명확하다’라고 공부를 하였는데요. 허나 실무에서는 그럼에도 불구하고 비즈니스 로직의 복잡도나 기타 여러가지 사정에 의해 Stored Procedure를 사용하는 팀도 있을 것 같다는 생각도 하게 되었습니다. 이와 관련해 멘토님은 백엔드 개발에 있어 Stored Procedure에 대해 어떤 관점을 가지고 계신지 궁금합니다!

  • 스토어드 프로지셔는 과거 회사 규모가 작아도 DBA 가 꼭있는 구조에서 주로 쓰임. JPA 코드는 하나의 스토어드 프로시져라고 봐도 무방해. 전체의 로직을 하나의 함수로 구워낸다라고보면 해당되거든. 현재 NoSql 이 나온 이후에 다들 'SQL 아닌거 써도 괜찮네...' 하다보니 백엔드 개발자가 DBA 권한까지 뺏어가는중. ORM (JPA typeORM, 장고, 루비온레일즈, 마이바티스) 등 이 대세가 될수록 DBA 분들의 역할이 줄어들고 있는 추세야.

  • 지금은 그래서 스토어드 프로시져를 잘 사용하지 않는다. 로직 레이어가 하나 더 생기거든. 이는 오류가 생길 여지가 하나 더생기게해.

  • 어차피 백엔드 단에서 디비에 오류가 나니까 어차피 코드레이어에서 데이터베이스를 관리하고 책임감을느끼는게 훨 좋아. 이게 장기적으로 백엔드 개발자에게 요구하는 사항들이야. 그렇기에 주니어때는 아직 아니지만 시니어로 갈수록 DB공부를 많이 해야해.

Q. 개발자도 연차와 실력이 쌓여 리더급 개발자가 된다면 실제 개발을 하는 것보다는 팀원들을 관리하고 프로젝트를 조율하는 업무가 많아진다고 알고 있습니다. 멘토님께서 생각하시는 혹은 경험해보신 좋은 리더들의 특징은 무엇인지, 그리고 좋은 리더가 되기 위해서는 무엇이 필요하다고 생각하시는지 궁금합니다.

  • 실무 트리를 계속 밟게 해주는 회사가 있긴하지만 관리자로 많이 가긴한다.

  • 좋은 리더의 특징은 의도를 설명하고, 그 의도가 옳든 나쁘든 개선을 할 줄 아는 리더가 좋은 리더야. 그 시기에는 옳다고 생각한게 바뀔수있어.

  • 내가 뭘잘했고, 뭘 못했고 판단할줄알아야 성장할 수 있어. 어떠한 근거 기반으로 이유를 설명해야해.

Q. 데브옵스 엔지니어와 클라우드 개발자 직무의 전망에 대해 궁금합니다. 아직 그 직무가 정확히 어떤 일을 하는지 와닿지 않기도 하고, 실무에서 주니어 개발자가 바로 이러한 직무를 맡는 경우가 있을까요?

  • 데브옵스 엔지니어 이전에 원래는 시스템엔지니어라는 포지션이 있었어. 서버장비,네트워크 장비 다루고. 네트워크 세팅을 하던 시대가 있었어. 그분들은 하드웨어를 다루는 일에 특화되어있어. 랜선이 엄청나게 많아 관리하고, 서버 이슈 찾는 직종이였어.

  • 클라우드 자원을 관리하는 포지션이 필요했는데, 개발 역량을 가진 직군이 필요했던거야. 데브 + 옵스. 해외에서는 개발역량이 아주 높은 오퍼레이터인지 or 오퍼레이터 역량을 가진 개발자인지를 지칭하는데, 한국에서는 시스템 엔지니어를 하는 사람이 넘어가는 경우가 많은거같아. 단순한 bash 스크랩팅 정도만 가능한 데브 옵스 포지션이 많아.

  • AWS 클라우드 서비스의 이해도를 파고가는것도 많고, 회사가 원하는 포지션의 데브옵스는 개발역량이 있어서, AWS를 잘쓰는거에서 나아가 편하게 쓸 수 있는. 쿠버네티스 환경설정을 어떻게하면 더 좋은지 디테일하게 관리를 해주는. 전반적인 오퍼레이터를 소화해주는 역할. 그 과정에서 코딩을 역량을 기대한다.

  • 당연히 뽑긴하지만, 한국에서 개발 포지션이라고 보기에 애매해. 커리어 패스적인 측면에서 고민이 필요해. 오퍼레이터 비중이 훨 크기 때문에 너의 커리어가 애매해질 수 있어. 첫 직무가 아예 안중요하지는 않으니까. 개발자의 커리어를 시작하는게 훨 유리할거야.

  • 한국에 클라우드 개발자는 많지는 않지. 외부적으로 클라우드 개발자를 두는 경우도 있어. 애저, 구글 클라우드 플랫폼이 있더라도, 이걸 그대로 쓰기에는 귀찮고 코스트가 많거든. 그래서 가상 레이어를 두어서 코스트를 낮추는 클라우드 개발자가 있어. 물리서버를 클라우드로 전향하는 일도있고, 클라우드로 상용 서비스 하는 일도 있고.

  • 배포,서버 가동, 모니터링을,비용,장애 리스크 편하게 하고 싶어서 고용할때도 있어.

  • 사실 AWS도 종속되어 있는 기술을 배우는거고. 그러한 부분에서 도와주는 포지션이야. 실제 플랫폼도 재사용되는 기술의 집합이니.

  • 어느정도의 네트워크, 가상화 이해도나 다루는 클라우드 플랫폼의 내부 원리를 이해하는 포지션이야. 그러다 보니 일반 웹서비스 개발에서 넘어서 재사용가능한 시스템을 만드는 일. 다른 개발자가 쓰기 편하게 기능을 재구성하는 일. 다른 플랫폼을 분석하는 일.

  • 엔지니어의 본질에 좀더 집중해서 일할수있는 직군. 주니어 개발자를 당연히 채용하기도 함. 클라우드 플랫폼 개발자가 사용자와 밀접하지는 않지만, 경험했을때 성장을 많이 할수 있는 포지션이야. 리눅스가 친숙한 사람이 별로 없거든. 서버이슈를 만날수 있고, 리눅스 이해도가 높아지고, 다양한 이슈들을 겪으면서 성장의 폭이 높아져서 직무전환에도 유리해. 추천하는 직무야.

  • 공고가 있을때 지원해보는것도 나쁘지 않은 포지션이야.

Q. 도메인이 여러개가 될수있는데, 배달,페이먼트나 등등 이경우 개발자 커리어 패스를 만들어나가는데 도메인이 일치하는게 영향을 미치는가?

  • 솔직히 도메인을 바꾸는게 많이 어려웠어. 커리어 초반 게임서버 개발에서는 실시간 서버를 잘짜는 쪽으로만 잘하지. 이걸 뒤집으려면 많은 노력이 필요한 경우가 일반적이야. 정산은 배치, 정합성이 중요한데 이게 계속 머리에 떠나지 않는거야. 습관이 생기는거지. 자꾸 옛날 습관이 나와서 변화하는게 힘들긴해.

  • 특히 3년차까지의 경험이 길게 영향을 주거든, 이를 뒤집으려면 엄청난 마인드가 필요해. 그러다보니 아무래도 맡게되는 도메인이 중요하다고 생각해.

  • 업무의 카테고리를 바꾸는 경우도 많은데 적정시기에 겪으면 성장에 도움이 많이돼. 이렇게 도메인을 넘어가도 잘할 수 있는 사람이다 를 말하는 면접에대한 대비도 필요하고.

Q. 개발 공부를 하는 방식이 다양한 것 같습니다. 책으로 공부하거나 인강으로 공부하거나 직접 실습을 하며 공부를 하는 등의 방식이 있다고 생각합니다. 개인적으로는 개발 기술이 계속 새로운 것이 나오고 변하지만 책은 ‘개발의 본질’을 다루고 있다고 생각하고 있습니다. 그런 점에서 멘토님께서 개발 공부를 하는 방식과 백엔드 개발자에게 추천해줄만한 책이 있으신지 궁금합니다.

  • RSS 구독과, 해커뉴스 등의 개발 뉴스레터들을 읽어보고. 정독하기는 어려우니 관심가는거 부터 하루 30분 정도 읽어.

  • 해커뉴스는 실리콘밸리의 트렌드를 알 수 있어. 남은 시간에는 데브 토이를 많이해. 내가 쓰고 싶은 제품을 관심가는 기술로 만들어. 토이 프로젝트가 성장에 도움이 많이 돼.

  • 인강사이트를 시작 페이지로 설정하거나, 나도 강제성있는 학습을 자주 하긴 했어.

  • 그래서 무조건 실습을 했어. 모든 어플리케이션을 따라 치기 힘들어. 그러니까 누가 만든걸 디버깅 하면서 실습을 하거나, 특정 부분을 이해한 부분대로 구현하거나, 토이프로젝트를 하거나.

  • 인강과 실습의 비율이 5:5 가 될 수록 좋은거같아. 실습이 0이면 절대 안돼. 디버깅이나 로그라도 찍어서 순서라도 보는게 낫지. 책으로만 보면 인지의 한계가 있어.

책추천

자바 성능에 관한 책
https://product.kyobobook.co.kr/detail/S000001032977

노드 성능에 관한 책
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=98320450

시스템 설계를 할때 어떻게 할지를 알 수 있음
https://product.kyobobook.co.kr/detail/S000001033116

백,프론트 주니어 둘다에게 추천하는 책. 멘토님이 주니어일때 가장 도움을 많이 받은 책. 필독서.
https://product.kyobobook.co.kr/detail/S000001033128

노드의 필독서. 이벤트 루프는 이 책도 괜찮게 설명하지만, 꼭 숙지해야해. 노드를 쓸때 꼭 이해하고 사용해야하거든.
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=306783871

nestJs 책
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=306191959

나중에 시니어로 갈때쯤 읽어봐. 아직은 이해는 안갈거야.
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=317987700

DBA 관점에 좀 치우쳐있지만(opinion 은 별로지만) 기술적 내용은 좋아.
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=278488709

정말 쉽게 설명하는 컴퓨터 구조!
https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=299014282

실제 있던 해킹 사례. 소설같은.
https://www.yes24.com/Product/Goods/407021

  • 책 필독 1순위. 실용주의 프로그래머 -> 개발의 재밌는 포인트를 찾아보면 마인드셋+ 다른 책들을 읽는 방향이 잡힐 수 있어. 고통을 덜어주고, 힘들때 어떻게 해야되는지를 잘 잡아주는 책이야. 잘읽히는 책이라 금방 읽을 수 있을거야. 정독해도 매우 좋아.

Q. spring에서 모든 request에 특정 정적 리소스를 담아서 보내줄 수 있는 방법이 있을까요?--- 추가설명---Spring backend, React frontend 프로젝트에서 프론트와 백엔드 어플리게이션을 서버에서 각각 구동시키는것이 아닌, react 앱을 빌드 한 뒤 spring 어플리케이션의 정적 리소스에 담아서 보내고자 합니다.기존에 node 프로젝트애서 동일한 방법(프론트 앱 빌드 후 백엔드 서버의 resource로 전달)을 사용했던 경우에는 특정 정적 리소스를 모든 requerst에 담아서 보내도록 설정을 할 수 있어서 관련 설정을 해주었는데, spring에서도 모든 request에 특정 리소스를 담아서 보내줄 수 있는 방법이 있을까요?

  • 디스펙처 서블릿 설정이 있을거야. 특정 규칙 이하를 다 여는걸로 설정하는게 합리적일거야. 특정 패스 이하는 다 허용한다. 근데 애초에 이런식으로 구성하는건 문제가 많아. 취약점이야.

  • 모든 패스를 허용하니까 백엔드의 성능적 취약점이 되서 디도스를 맞을 수 있고 따로 띄우는게 좋아.

  • MVC 프레임워크를 덜쓰는게 트렌드. 성능측정의 이유도 있고. 특정 규칙에 결합도가 생겨버렸어. 어떤 운용이슈가 있을 수 있는 제약이 되어버릴 수가 있는거야.

  • 맥미니 or 리눅스로 쓸수있는 미니 pc로 집에서 서버를 직접 구성해서 하는것도 나쁘지 않아. 서비스할꺼면 어차피 프리티어에서 안되니까. 미니pc 세팅을 해. 저전력 저소음으로. vm 위에서 또 도커로 띄우면 손실이 크거든.

Q. 윈도우 pc 에 대한 포트를 열게 되면 다른 컴퓨터나 다른 요금에 대한 보안적인 부분도 문제가 될수있다는데?

  • 메이저 포트 ssh, mongodb포트 라던가 공격이 들어갈 수 있어.

  • 그런데 메이저 포트들을 안쓰면, 개인서버에 뭐를 안하고, 딱 쓰는 외부공개 포트만 열면돼. 로컬 테스트면 443 80 말고 다른 포트 써서 하면 공격 안들어오거든. 그 포트만 피해서 하면 보통 안들어와서 괜찮아.

  • 메이저 포트 다 닫는게 좋은 방법이야.

profile
강준호
이전 포스트

[TIL] Udemy 4일차 프론트엔드/백엔드 - HTML & CSS 레이아웃 및 포지셔닝 이해

다음 포스트

[TIL] Udemy 6일차 프론트엔드/백엔드 - 반응형 웹 디자인

0개의 댓글