[🚀 Today I Learn 페이지 만들기] 해니 미션 제출합니다.

[janghw0126]

배포링크

https://janghw0126.github.io/web-today-i-learn/

생각해 보기

HTML

1. 나만의 갤러리에서 사진 9장은 HTML 태그 중 어떤 요소로 표현하는 것이 좋을까? 이유는 뭐라고 생각했는가?

• 사진은 반복되는 콘텐츠이기 때문에 ul > li > img 또는 figure > img + figcaption 구조로 표현하는 것이 적절하다고 생각했다. 특히 figure는 이미지와 설명을 함께 담을 수 있어 의미적으로 더 명확하다고 생각한다.

2. 뼈대 코드를 기반으로 이미지를 로드하는 방식은 크게 2가지로 나뉘는데 무엇이고 어떻게 사용하고 있는가?

• 이미지를 로드하는 방식은 HTML에 직접 로 작성하는 방식, JavaScript로 createElement를 사용해 동적으로 생성하는 방식이 있다. 이번 구현에서는 TIL과 동일하게 JavaScript로 DOM을 생성하는 방식도 활용할 수 있다고 생각했다.

3. 시맨틱 태그로 문서를 구분할 때, 어떤 기준으로 섹션을 나누고 태그를 적용하는 것이 좋을까?

• 디자인이 아니라 콘텐츠의 의미를 기준으로 나누는 것이 중요할 듯하다. 예를 들어, header는 소개/네비게이션, main은 핵심 콘텐츠, section은 주제별 묶음, footer는 하단 정보로 구분하는 것이 적절하다.

4. 태그의 alt 속성은 왜 필요하며, 어떻게 작성하는 것이 좋을까?

• alt는 이미지가 보이지 않을 때 대체 텍스트를 제공하고, 스크린 리더를 위한 접근성을 높이기 위해 필요하다. 이미지가 전달하는 핵심 내용을 간결하게 작성하는 것이 좋다.

5. 이미지를 로드할 때, 상대 경로(relative path)와 절대 경로(absolute path)를 혼용하면 어떤 문제가 발생할 수 있을까?

• 두 경로를 혼용하면 배포 환경(GitHub Pages 등)에서 경로가 깨질 수 있다. 따라서 프로젝트 내에서는 일관된 기준으로 사용하는 것이 중요하다.

6. 태그의 viewport 설정과 Open Graph 태그는 각각 어떤 역할을 하는가?

• viewport: 모바일 환경에서 화면 크기와 비율을 제어한다,
• Open Graph: SNS 공유 시 제목, 설명, 썸네일 등을 설정한다.

CSS

1. 나만의 갤러리에서 9장의 이미지를 보기 좋게 배치하려면, Flexbox와 CSS Grid 중 어떤 것이 더 적합할까? 그 이유는?

• 9장의 이미지를 배치하는 경우, 행과 열을 동시에 제어할 수 있는 CSS Grid가 더 적합하다. 특히 grid-template-columns: repeat(3, 1fr)로 간단하게 3x3 구조를 만들 수 있다.

2. 태그 선택자, 클래스 선택자, ID 선택자는 각각 언제 사용하는 것이 적절할까?

• 태그 선택자: 공통 기본 스타일일 때
• 클래스 선택자: 재사용 가능한 스타일일 때
• ID 선택자: 유일한 요소 (주로 JS에서 사용)일 때

3. CSS를 HTML 내에 직접 작성하는 것과 별도 파일로 분리하는 것의 차이는 무엇일까?

• HTML에 직접 작성하면 빠르지만 유지보수가 어렵다. 별도 파일로 분리하면 구조와 스타일이 분리되어 재사용성과 가독성이 좋아진다.

JavaScript

1. document.getElementById()와 document.querySelector()의 차이는 무엇인가?

• getElementById: id만 선택한다. 빠르다.
• querySelector: CSS 선택자 기반이다, 더 유연하다.

2. 이벤트 리스너를 사용해서 "어떤 일이 일어났을 때 어떤 동작을 실행"하게 만들 수 있다. 자기소개 페이지에서 활용할 수 있는 이벤트에는 어떤 것들이 있을까?

• submit: TIL 등록을 할 수 있다.
• click: 버튼 클릭, 다크모드 등이 가능하다.
• input: 실시간 입력을 반영할 수 있다.
• scroll: UI 변화가 가능하다.

3. innerHTML로 DOM을 조작할 때 주의해야 할 점은 무엇일까?

• XSS(보안 문제) 위험 가능성이 있다.
• 기존 DOM 구조가 깨질 수 있다.

배포

1. GitHub Pages로 배포한 페이지에서 TIL을 작성하면, 새로고침하거나 재배포했을 때 데이터가 유지될까? 그 이유는?

• JavaScript로 DOM에 추가한 데이터는 브라우저 메모리에만 존재하기 때문에, 새로고침하거나 재배포하면 유지되지 않는다.

2. JavaScript로 추가한 데이터를 영구적으로 저장하려면 어떤 방법이 있을까?

• localStorage: 간단한 데이터 저장
• sessionStorage: 세션 동안만 유지
• 서버/DB(Firebase 등): 여러 기기에서 공유 가능

[janghw0126]

🤔 생각해 보기

1. 기본키란 무엇이고 왜 필요한가?

• 기본키는 테이블에서 각 행을 고유하게 식별하는 컬럼입니다. 기본키가 없으면 동명이인처럼 중복 데이터가 생겼을 때 어떤 레코드인지 구분할 수 없습니다.

2. MySQL에서 사용되는 AUTO_INCREMENT는 왜 필요할까?

• INSERT할 때마다 ID를 직접 지정하면 번거롭고, 동시에 여러 요청이 들어올 때 중복 ID가 생길 수 있습니다. AUTO_INCREMENT는 DB가 자동으로 고유한 숫자를 생성해줘서 이 문제를 해결해줍니다.

3. 학생이 등교는 했지만 하교 버튼을 누르지 않았을 때, end_time에 NULL이 저장된다. NULL 값을 처리할 때 주의할 점은?

• SQL에서 NULL은 = NULL로 비교하면 안 되고 IS NULL을 사용해야 합니다. 연산 시 NULL이 포함되면 결과도 NULL이 됩니다. 프론트엔드에서는 NULL을 그냥 표시하면 "null"이 텍스트로 보일 수 있으니 "하교 전", "-" 등으로 처리해야 합니다.

4. crew와 attendance 테이블의 관계를 ER 다이어그램으로 시각화해보자. 이 관계를 일상 생활의 예시로 비유한다면 어떤 것이 있을까?

• 1:N 관계입니다. crew 1명이 attendance 여러 개를 가질 수 있습니다. 실생활 비유로는 고객(1)과 주문(N), 학생(1)과 수강과목(N) 관계를 들 수 있습니다.

5. 출석 시스템에서 동시에 100명이 등교 버튼을 누른다면 어떤 일이 일어날까?

• 동시에 INSERT가 발생하면 충돌이 생길 수 있습니다. 원자성 측면에서 각 출석 등록이 완전히 성공하거나 완전히 실패해야 하고, 격리성 측면에서 동시에 처리되는 100개의 트랜잭션이 서로 간섭하지 않아야 합니다. 격리성이 없으면 같은 attendance_id가 중복 생성될 수 있습니다.

6. 출석 데이터가 파일(CSV)이 아닌 데이터베이스에 저장되는 이유는 무엇일까? 파일 시스템으로 출석을 관리했다면 어떤 문제가 생길까?

• 파일 시스템은 동시 접근 시 데이터 손상 위험이 있고, 중복 데이터가 발생하기 쉬우며, 검색과 정렬이 느리고 보안 관리가 어렵습니다. 반면 데이터베이스는 동시성 제어, 제약 조건을 통한 중복 방지, 인덱스를 통한 빠른 검색, 권한 관리가 가능합니다.

7. 출석 데이터를 관계형 DB가 아닌 NoSQL(예: MongoDB)로 저장한다면 테이블 구조가 어떻게 달라질까? 어떤 장단점이 있을까?

• 크루 정보와 출석 데이터를 하나의 문서에 중첩해서 저장할 수 있어 한 번에 조회가 가능하고 구조가 유연하다는 장점이 있습니다. 하지만 출석 데이터만 따로 집계하거나 JOIN이 필요할 때 복잡해집니다. 출석처럼 구조가 명확한 데이터는 RDBMS가 더 적합합니다.

🧐 더 생각해 보기 (심화)

1. 왜 crew 테이블에서 nickname을 기본키로 하지 않은 걸까? attendance 테이블에 attendance_id가 존재하는 이유는 무엇일까?

• nickname은 자연키로, 나중에 변경될 수 있습니다. 기본키가 바뀌면 이를 참조하는 모든 외래키도 수정해야 해서 매우 복잡해집니다. 반면 crew_id 같은 대리키는 업무적 의미 없이 오직 식별만을 위해 존재하므로 변경될 일이 없습니다.

2. 데이터베이스 제약 조건 중 RESTRICT, CASCADE는 무엇인가?

• RESTRICT는 참조되고 있는 데이터 삭제 시 오류를 발생시킵니다. 예를 들어 출석 기록이 있는 크루는 삭제가 불가능합니다. CASCADE는 부모 삭제 시 자식도 자동 삭제합니다. 예를 들어 크루 삭제 시 해당 크루의 출석 기록도 전부 삭제됩니다. 실무에서는 회원 탈퇴 시 게시글을 삭제할지, 남길지를 정책적으로 결정해서 선택합니다.

3. 다음 두 쿼리는 동일한 결과를 반환하지만 성능에 차이가 있다. 어떤 차이가 있으며, 어떤 상황에서 각각 유리할까?

• 서브쿼리(IN)는 서브쿼리 결과를 메모리에 올려두고 비교하며 데이터가 적을 때 가독성이 좋습니다. JOIN은 DB 엔진이 최적화하기 유리하고 데이터가 많을 때 일반적으로 더 빠릅니다. 대부분의 경우 JOIN이 성능상 유리하고 실무에서도 더 많이 사용합니다.

4. attendance 테이블을 완전히 정규화하면 어떤 장점이 있을까? 반대로 일부 비정규화를 적용한다면 어떤 쿼리 성능 이점을 얻을 수 있을까?

• 정규화는 데이터 중복을 제거하고 일관성을 유지하지만 JOIN이 많아져 쿼리가 복잡해질 수 있습니다. 비정규화는 자주 조회하는 데이터를 한 테이블에 합쳐두면 JOIN 없이 빠르게 조회할 수 있지만 데이터 중복으로 수정 시 여러 곳을 바꿔야 합니다.

5. 출석 시스템이 수백 명의 사용자에 의해 동시에 접근된다면, 연결 풀링(connection pooling)은 무엇이고 왜 필요한가?

• DB 연결을 맺고 끊는 작업은 비용이 큽니다. 연결 풀링은 미리 여러 개의 연결을 만들어 풀에 보관해두고, 요청이 올 때마다 꺼내 쓰고 반납하는 방식입니다. 수백 명이 동시에 접근해도 매번 새 연결을 만들지 않아서 성능이 크게 향상됩니다.

6. 실습에서 수행한 INSERT, UPDATE, DELETE를 하나의 트랜잭션으로 묶는다면 어떻게 작성할 수 있을까? 만약 DELETE 도중 오류가 발생하면 앞서 수행한 INSERT와 UPDATE는 어떻게 되어야 할까?

• START TRANSACTION으로 시작해서 INSERT, UPDATE, DELETE를 순서대로 실행한 뒤 모두 성공하면 COMMIT, 오류가 발생하면 ROLLBACK으로 전부 취소합니다. DELETE 도중 오류가 발생하면 앞서 실행한 INSERT와 UPDATE도 모두 취소되어야 데이터 일관성이 유지됩니다.