2021-03-24-TIL

게시 2021/03/24 수정 2026/10/07 작성자 August

조회 8 분 읽는 시간

2026-10-07 docs(posts): separate the sections of every post with a thematic break +8 −0
2026-10-06 docs(til): turn the bookmark-only tils into notes (part 2) +35 −32
2021-03-24 처음 게시

커밋 메시지에 이슈 번호 달기

커밋 메시지나 PR 설명에 이슈 번호를 적으면 GitHub가 둘을 연결한다. GitHub 문서에 따르면 close, closes, closed, fixes, resolve, resolves, resolved 같은 키워드 뒤에 #이슈번호를 쓰면(Closes #10) 해당 PR이 기본 브랜치에 머지될 때 이슈가 자동으로 닫힌다. 다른 저장소의 이슈는 Fixes octo-org/octo-repo#100처럼 저장소 이름까지 적는다. 기본 브랜치가 아닌 브랜치를 대상으로 하는 PR에서는 이 키워드가 무시된다.

좋은 커밋 메시지에 관한 글은 제목과 본문을 한 줄 띄워 분리하고, 제목은 영문 기준 50자 이내의 명령조로 쓰고, 본문은 어떻게보다 무엇을, 왜에 맞춰 쓰라고 정리한다. 이슈 번호를 제목이나 본문에 붙이는 것도 그 약속 중 하나다.

MySQL DATETIME과 TIMESTAMP

둘 다 날짜와 시간을 함께 저장하지만 범위와 시간대 처리가 다르다. MySQL 문서 기준으로 DATETIME의 범위는 '1000-01-01 00:00:00'부터 '9999-12-31 23:59:59'이고, TIMESTAMP는 '1970-01-01 00:00:01' UTC부터 '2038-01-19 03:14:07' UTC까지다. TIMESTAMP는 저장할 때 현재 세션의 시간대에서 UTC로 바꾸고 읽을 때 다시 현재 시간대로 바꾸며, DATETIME은 이런 변환을 하지 않는다. 그래서 세션의 시간대를 바꾼 뒤 TIMESTAMP 값을 읽으면 저장할 때와 다른 값이 보인다.

JPA 엔티티에서 컬럼 타입을 TIMESTAMP로 지정하려면 @Column의 columnDefinition에 DDL 조각을 넣는다. 메모에는 @Column(coulumDef..=“TIMESTAMP”)로 줄여 적었는데, 실제 속성 이름은 columnDefinition이다.

  
@Column(columnDefinition = "TIMESTAMP")
private LocalDateTime createdAt;

옵티마이저와 인덱스

옵티마이저가 인덱싱을 해주는데, 기본적으로 안 해주는 이유는 인덱싱을 했을 때의 이점이 무조건 있는게 아니기 때문! 예를 들어, 본문 검색에서 굳이 인덱싱을 사용하면 오히려 느려질 수도 있다.

정확히 말하면 인덱스를 만드는 것은 개발자이고, 옵티마이저는 쿼리마다 인덱스를 쓸지 테이블을 순차로 읽을지를 고른다. MySQL 문서는 작은 테이블이나 대부분의 행을 읽는 쿼리에서는 인덱스를 거치는 것보다 순차 읽기가 빠르다고 설명한다. 순차 읽기는 디스크 탐색을 줄이기 때문이다.

페어 프로그래밍으로 느낀 점

안녕하세요? 호눅스! 항상 감사합니다. 페어 프로그래밍을 아직 얼마 안 해봤지만 나름의 느낀 점을 말씀드리겠습니다.

처음 페어 프로그래밍으로 진행할 때는 ‘이게 정말 효과가 있나?’ 하는 생각이 들 정도로 진행이 더뎠습니다. 왜냐하면 제가 네비게이터 역할을 하면서 제가 부족함을 많이 느꼈습니다. 그리고 오프라인이 아니라서 의사소통과 통신 자체의 문제도 약간씩 발생했습니다. 화면이 끊긴다든지, 빠르게 로그를 확인하려고 하는데 바로바로 확인이 어렵다는 점 등이 있었습니다. 그러한 문제들로 인해 아무래도 미션의 진행속도는 더딜 수밖에 없었습니다.

하지만 계속 한 단계씩 진행해갈수록 뭔가 성취감은 더 크다고 느꼈습니다. 그리고 가장 좋은 점은 나 혼자 했다면 좀 이따가 해야겠다고 생각하면서 잠시 덮어놓았을 문제인데, 같이 해결될 때까지 머리를 싸매고 같이 해결할 수 있다는 것입니다. 포기가 힘들다(?)는 점이 좋은 것 같습니다. :)

한 가지 궁금한 점은 과연 실무에서는 페어 프로그래밍을 많이 하는지, 그리고 한다면 어떤 식으로 진행이 되는지 매우 궁금해졌습니다. 실제로 그렇게 진행하는 모습을 예시로 볼 수 있다면 좋을 것 같습니다.

실무 사례로 찾아본 매스프레소의 글은 페어 프로그래밍의 장점으로 지식 공유, 같이 고민하기, 업무 집중도 상승, 실시간 코드 리뷰, 특정 팀원만 다룰 수 있는 코드가 줄어드는 점을 든다. 같은 글은 페어를 하는 날은 지치고 체력 소모가 크다는 점도 함께 적는다.

Spring Boot QnA Wiki

Commit convention

{commit header}: {commit title} (#{issue number})

commit header rule
- feat : 새로운 기능에 대한 커밋
- fix : 버그 수정에 대한 커밋
- build : 빌드 관련 파일 수정에 대한 커밋
- chore : 그 외 자잘한 수정에 대한 커밋
- ci: CI 관련 설정 수정에 대한 커밋
- perf: 코드 성능 개선에 대한 커밋
- docs : 도큐먼트에 수정에 대한 커밋
- style : 코드 문법 또는 포맷에 대한 수정에 대한 커밋
- refactor : 코드 리팩토링에 대한 커밋
- test : 테스트 코드 수정에 대한 커밋
example : feat: Add Question create logic (#12)

제목 끝의 (#12)가 앞에서 본 이슈 번호 연결이다. 다만 #12만 적으면 이슈와 연결되기만 하고, 머지 시 이슈를 닫으려면 Closes #12처럼 키워드가 있어야 한다.

Error Report

Circular view path error

참고한 자료외부 출처 8

외부 출처

Link to the issue number on GitHub within a commit messageStack Overflow
Linking a pull request to an issueGitHub Docs
좋은 git 커밋 메시지를 작성하기 위한 8가지 약속djkeh
MySQL Datetime, Timestamp 차이에 대해Nesoy Blog
The DATE, DATETIME, and TIMESTAMP TypesMySQL 8.0 Reference Manual
How MySQL Uses IndexesMySQL 8.0 Reference Manual
Column (Jakarta Persistence API)Jakarta EEcolumnDefinition
Mathpresso 개발방법론 — 1. 페어 프로그래밍(pair programming)Mathpresso 팀 블로그

TIL, 2021-TIL

TIL