📝2회차 회고록ㅣBEYOND SW캠프
💻 2주차 학습 (2025.09.22 ~ 2025.09.26)
2주차 수업은 UML과 데이터베이스(DB), 그리고 SQL(기초) 내용을 담았다.
sw공학&UML, DB 개념, RDBMS 구조, 계정 관리부터 시작해 기본 SQL 문법과 JOIN, GROUP BY, 서브쿼리, DML까지 이어졌다.
처음에는 JOIN과 GROUP BY가 헷갈려서 문제 풀이에 시간이 걸렸지만, 강사님 설명과 예시를 따라가며 차츰 이해가 됐다. 특히, LEFT/RIGHT JOIN에서 기준 테이블을 어떻게 잡아야 하는지, GROUP BY에서 어떤 컬럼을 기준으로 집계해야 하는지를 반복 실습하면서 감을 잡을 수 있었다.
중간중간 실습 문제를 풀다 틀리기도 했지만, 오히려 그 과정에서 몰랐던 개념을 확실히 짚고 넘어갈 수 있어 좋았다. 무엇보다 “결과에서 무엇을 보고 싶은지 먼저 정리한 뒤 쿼리를 작성하라”는 팁이 큰 도움이 됐다.
수업 자료가 전부 노션이라 정리하기가 수월했고, 내가 쓰는 노션에도 적용할 수 있어 학습 효율이 높았다. 또한 첫 주보다 강의 시간표에 적응이 되어서 하루 9시~6시의 학습 리듬도 조금은 익숙해졌다.
아직은 SQL을 자유자재로 다루기에는 부족하지만, 2주차 동안 데이터베이스 기초와 SQL 기본기를 다질 수 있었던 의미 있는 시간이었다.
다음은 KNPT 방식으로 후기를 풀어내 보겠다.
👍 KEEP
-
수업 전 필기 자료를 미리 준비하고, 헷갈린 부분은 바로 질문하면서 이해도를 높였다. 쉬는 시간 때 강사님 붙잡고 질문하는게 못 쉬게 해드려 조금 죄송스럽긴 하지만... 질문 생기면 꼭 하자..!
-
노션 기반 수업 자료 덕분에 정리·복습이 수월했고, 내 노션에도 적용해 효율을 높였다. 강사님이 만들어준 데일리 스크럼 페이지도 잘 활용해보자.
✏️ NEW
LEFT / RIGHT JOIN 이해
-
절대적인 기준은 없다. 무엇을 기준(보존)으로 볼지를 먼저 정한다.
- 기준 테이블을 왼쪽에 두면
LEFT JOIN, 오른쪽에 두면RIGHT JOIN.
- 기준 테이블을 왼쪽에 두면
-
동일 쿼리를 다른 관점으로 표현할 수 있다. 중심 테이블이
watch_histories라면,-- 중심을 watch_histories로 두고 INNER JOIN만 사용 SELECT b.username, c.title FROM watch_histories a JOIN users b ON a.user_id = b.user_id JOIN videos c ON a.video_id = c.video_id LIMIT 10; -- 중심을 가운데 두고 RIGHT/LEFT로 표현 SELECT a.username, c.title FROM users a RIGHT JOIN watch_histories b ON a.user_id = b.user_id LEFT JOIN videos c ON b.video_id = c.video_id LIMIT 10;결과는 같았지만, NULL 보존 방식이 또 달라질 수 있으니 목적에 맞게 선택해야 한다.
Multiple JOIN에서의 기준 세우기
-
예) “사원 전체를 기준으로 부서/직급을 붙이기” → 사원이 기준이므로
employee LEFT JOIN department,JOIN job처럼 설계.SELECT a.EMP_NAME, b.DEPT_TITLE, c.JOB_NAME FROM employee a LEFT JOIN department b ON a.DEPT_CODE = b.DEPT_ID JOIN job c ON a.JOB_CODE = c.JOB_CODE; -
반대로 “부서 전체가 기준”이면 부서를 중앙에 두고 양옆을 붙인다.
SELECT a.EMP_NAME, b.DEPT_TITLE, c.JOB_NAME FROM employee a RIGHT JOIN department b ON a.DEPT_CODE = b.DEPT_ID LEFT JOIN job c ON a.JOB_CODE = c.JOB_CODE; -
헷갈렸던 것: 중간에
RIGHT로 넓혔다가 다시INNER JOIN을 쓰면 의도와 다르게 범위가 다시 좁아진다. 기준 보존이 목적이라면(NULL 포함시키기)LEFT/RIGHT로 일관되게 가져가야 한다.
ON vs WHERE 역할 구분
-
ON은 테이블을 연결하는 조건이다. 보통 PK–FK가 온다. ON 은 조건인 줄 알았는데, 테이블 간 연결고리 역할이 주된 역할임을 배웠다. -
WHERE은 연결된 결과에 대한 필터다.-- 올바른 흐름: 테이블 연결(ON) → 결과 필터(WHERE) SELECT a.title, a.view_count FROM videos a JOIN creators b ON a.creator_id = b.creator_id WHERE b.channel_name = '맛있는 요리';
GROUP BY와 HAVING
-
집계 기준 컬럼만
GROUP BY에 둔다. 세고 싶은 단위를 정확히 정한다.-- 비디오 3개 이상 올린 크리에이터 SELECT creator_id, COUNT(*) AS video_count FROM videos GROUP BY creator_id HAVING video_count > 3; -
잘못된 예:
GROUP BY에 개별 행을 유니크하게 만드는 컬럼(예:video_id)을 넣으면 그룹이 쪼개져서 집계가 왜곡된다.
서브쿼리
-
서브쿼리는 어떤 테이블에서 무엇을 가져올지를 머릿속에 확실히 그려야 한다.
-
단일행/다중행, 위치(IN, WHERE, SELECT 등) 구분이 중요하다.
-
예시 문제:
'코딩 아카데미' 채널의 비디오에 좋아요를 누른 사용자 조회SELECT username FROM users WHERE user_id IN ( SELECT user_id FROM video_likes WHERE video_id IN ( SELECT video_id FROM videos WHERE creator_id = ( SELECT creator_id FROM creators WHERE channel_name = '코딩 아카데미' ) ) );
- 이 문제에서 헷갈렸던 것은
이 쿼리를 기점으로 users까지 id를 매치시켜가며 찾아야 했지만,SELECT creator_id FROM creators WHERE channel_name = '코딩 아카데미''코딩 아카데미'를 통해 id를 먼저 찾지 않고'좋아요'를 기준삼아 먼저 찾았고, 문제가 풀리지 않았다.
💡 PROBLEM
-
노트 방식이 아직 고정되지 않아, 수업 중에 “어떻게 정리하지?”에 신경이 분산됐다.
-
중간중간 집중이 끊기는 순간이 있었다. 익숙한 내용이라고 방심하다 수업을 놓쳤다.
-
과도한 목표 설정으로 계획이 밀리거나 틀어졌었다.
-
아침 운동 루틴이 흔들렸다. 취침 시간이 늦어지면서 연쇄적으로 무너졌다. 건강+체력을 위해 운동을 해주어야 하는데 지난 주에는 1회 밖에 못나갔다🥲
🪛 TRY
노트 포맷 고정
- 노션 학습 자료를 복사해 와 자료를 하나로 통일시키자. 여기저기 분포해 있으면 나중에 또 정리해야 하니까..?
스크럼
- 하루 목표 최대 3개, 60-80분 안에 끝낼 수 있는 단위로 쪼개기 -> 어차피 시간이 얼마 없음 목표 3개도 많다..
복습
- 수업 중에는 개념·예시만 작성하고 설명에 집중하자.
Daily 회고는 빠뜨리지 말고 기록 습관 유지하자잉
생활 리듬
- 취침 시간 고정(23:30)
- 아침 운동 주 최소 3회 30분!!!!💪
그 외
- 캠프 외 해야 할 일은 전날 처리하거나 점심/쉬는 시간에만 처리하자.. 수업시간에 제발 생각 삼천포로 빠지지 마..
마무리
전반적으로 2주차는 적응하는 기간이었다. 동기들과 첫 주보다 대화도 많이 하고 반 분위기가 전체적으로 좋아지고 있다는게 느껴진다. 아래는 나의 분단 사람들과 함께 찍은 사진이다.
얼떨결에 이번 주 대표 회고록 선정자 이야기를 하다 사진 하나 같이 찍자 하며 회고록에도 꼭 올리자는 이야기를 나누었던 기억이 난다.
