BEYOND SW 캠프 15기 3주차 회고

SW 캠프 3주차가 끝났다. 처음으로 5일 모두 교육 받은 주였다. 다음과 같은 내용을 학습하였다.

학습 내용

1. SQL - view, index, procedure, trigger
   SQL에서 생성할 수 있는 테이블 외의 다른 객체들이다. 정보 보안 및 성능 개선과 관련이 있다.
2. SQL - DCL
   데이터베이스에 관한 권한을 관리하는 명령어이다.
3. 데이터 모델링
   데이터 모델링에 관한 이론 학습 및 실습을 진행하였다. 특히, ERD 작성 및 정규화를 실습하였다.

이번주에는 ERD 작성 실습이 가장 기억에 남는다. 이를 포함하여 배운 내용을 정리해본다.

배운 점

1. ERD 실습 - 문제 2

1주차 회고에서 언급한 실습의 중요성을 다시 한 번 깨달을 수 있었다. 이렇게 실습을 할 수 있는 기회를 제공해준 캠프 측, 강사님께 정말 감사하다.
관계의 개념은 이론적으로 알고 있었지만, 실습문제를 풀며 직접 관계차수가 얼마인지 결정하려니 많이 헷갈렸다. 엔터티 도출, 속성 도출, 관계 설정의 순서로 문제를 해결하는 데 각 단계마다 짝 분과 의견이 다른 부분이 있었다. 꽤 오랜 시간의 논의 끝에 하나로 합의하였는데, 다행히도 모범 답안과 근접하였다.

배운 점: 시스템 밖의 영역에 해당하는 부분은 엔터티를 생성하지 않는다.

2. ERD 실습 - 문제 3

3번 실습 문제는 물리적으로 구현이 불가능한 $M:N$ 관계를 교차 엔터티를 생성하여 $1:M$, $1:N$ 관계로 분리하는 게 핵심인 문제였는데, 관계 차수 개념을 헷갈려하다가 아예 잘못된 관계를 도출하였다. 이 외에도 몇 가지 문제가 있는 답안이었는데, 하필 이 문제를 수업시간에 발표하게 되었다.(!)

배운 점: 필요하다면 인조 식별자를 만드는 것도 좋은 방법이다.

문제에 제시된 지문에 "강사코드", "학생코드"와 같은 항목이 없어서 제시된 내용만으로 식별자를 구성하려다보니 전화번호를 주 식별자로 사용했는데, 이는 길이가 길어서 식별자로 사용하기에 적합하지 않다. (쿼리문이 길어짐) 따라서 AUTO_INCREMENT를 이용한 인조 식별자를 생성하여 관리하는 것이 좋다. 사실 생각해보면 이 이유가 아니더라도 전화번호는 식별자로 적합하지 않다. (이는 본문 맨 마지막에 설명해보겠다.) 아무튼 너무 남용하면 안되겠지만, 모델링 과정에서 없던 인조 식별자를 만드는 것을 꺼려할 필요는 없겠다.

학습 과정에서는 모범 답안을 보는 것도 좋지만, 잘못된 답을 반면교사 삼아 어디에 문제가 있는 지를 파악하는 것이 분명히 도움이 된다고 생각한다. 부디 본인이 발표한 오답이 수강생 여러분들에게 도움이 되었기를 바란다.

이 외에도 한 분께서 본인이 맞게 풀었는지 확인받고 싶다며 발표자로 뽑히지 않았음에도 발표를 자원하셨다. 기회를 주셔서 감사하다며 발표를 하셨는데, 모범 답안과 거의 일치하였다. 발표를 두려워하지 않는 자세가 참 멋지다고 느꼈다. 그래서 노션 페이지에서 그 분의 답안 아래에 엄지 척 날려드렸다.
어떤 사람의 현재 모습은 과거의 행동으로부터 굴러온 스노우볼이라고 생각하는데, 이렇게 실패를 두려워하지 않고 자신감 있는 태도로 임해온 덕분에 좋은 실력도 갖추게 되신 것으로 보인다. 나중에 프로젝트에서 같은 팀으로 만나게 된다면 그 분께 정말 많이 배울 수 있을 듯하다.

3. 실전 경험의 중요성

다음주 금요일에 프로젝트 발표가 예정되어 있어, 팀원들과 이를 준비하고 있다. 아무래도 개발 프로젝트가 처음이다보니 어떻게 해야 하는 지 막막해서 헤맸는데, 대부분 프로젝트를 해보고 오신 분들이어서 많은 도움을 받고 있다. 이론 공부도 어느 정도 필요하지만, 실력이 늘기 위해서는 역시 실전 경험이 필수적이다. 좋은 팀을 만난 덕분에 정말 많이 성장하고 있는데, 자세한 내용은 아마 프로젝트가 끝난 다음주에 작성할 수 있을 듯하다. 글이 너무 길어진다 싶으면 아예 프로젝트 회고를 분리해서 작성할지도?

개선할 점

이번 주는 노션 페이지 개념 정리, 프로젝트 준비 등으로 바쁘게 보내다보니 한 주 내내 4-5시간 정도밖에 못 잔 채로 이후 교육을 받으러 오게 되었다. 그러다보니 이번 주 수업 중 약 3-4시간 정도를 집중하지 못해 놓쳤다. 그나마 2시간 분량은 공부한 적 있는 내용이라 다행이었지만, 모르는 내용을 배울 때는 수업을 놓치는 일이 없어야 할 것이다. 열심히 하는 것도 좋지만 지치지 않고 오래 가기 위해, 수면 시간을 더 확보할 방법에 대해 고민해봐야겠다.

문제 상황

사소하지만 이번주에도 겪은 문제 상황이 있어 정리해본다.

HeidiSQL에서 한 줄 실행 시 오류 발생

사실 오류 발생에서 높은 빈도를 차지하는 건 보통 오타 또는 세미콜론 누락인데, 이번에 발생한 오류는 후자에 해당했다. 단축키 Ctrl+Shift+F9의 기능이 "한 줄 실행"인데 이 줄을 구분하는 기준이 세미콜론이라고 한다. 사실 1주차에 팀원 중 한 분이 말씀하신 적 있지만 말로만 듣다보니 정확한 상황을 이해하지 못했는데, 그게 이 상황이었구나 싶었다. 백엔드 개발 단계에서는 IDE가 이런 오류를 알아서 잡아주지만, 그렇지 못한 시스템도 분명히 있으니 역시 타이핑은 주의하는 걸로. (코딩 테스트 또한 IDE의 도움 없이 치러진다.)

느낀 점

유독 깨달음을 많이 얻은 한 주였다. 특히, "개발자로 취업하려면 프로젝트 경험, 포트폴리오가 중요하다" 이런 이야기를 들을 때마다 막연하게 느껴지곤 했는데, 프로젝트 준비를 한 번 해보니 이를 어떻게 살릴 수 있을 지 조금은 알 것 같았다. 여전히 부족한 점이 많은 개발자 준비생이지만, 정말 내가 성장하고 있다는 걸 체감하게 되어 뿌듯했다. 많은 개발자 및 준비생들이 성장이라는 단어를 쓰다보니 이제는 식상한 표현이 되어버렸지만, 말 뿐이 아닌 진정한 성장을 이루었다고 자신있게 말할 수 있도록 앞으로도 열심히 나아갈 것이다.

전화번호가 PK일 수 없는 이유

다음과 같은 시나리오를 생각해볼 수 있다. 편의상 전화번호는 한 자리 수로 가정하였다.
위의 시나리오에서 A의 실제 전화번호가 2임에도, PK 제약조건으로 인해 번호 수정에 실패하였다. 극단적인 edge case로 여겨질 수도 있지만 그렇다고 아예 불가능한 건 또 아니다. 심지어 동명이인의 가능성까지 고려한다면 (이름, 전화번호) 쌍 조차도 PK가 될 수 없다.(!) 특정 열이 PK가 될 수 있는 지는 꽤 신중하게 판단해야 한다.