🤖 Backend

@DataJpaTest를 이용한 Repository 테스트 중 본 어플리케이션 실행에서 발생하지 않던 DDL에서 예외가 발생했다. H2 ↔️ MySQL 문법 차이로 인해 테이블이 제대로 생성되지 않는 것으로 보여서 application-test.properties 를 계속 수정했지만 해결되지 않았다. 문득, 지난 번에도 @DataJpaTest 테스트에서 발생하는 에러를 @AutoConfigureTestDatabase으로 해결한 기억이나서 시도하였고 해결되었다. 그때도 디버깅 과정 기록을 미뤄두고 있었는데, 이 참에 블로깅하고 장기 기억으로 가보자. 문제 분석 시도할 때마다 다양한 예외가 발생하고 인터넷에도 다양한 예외 케이스가 있는데, 데이터베이스 설정 문제이거나 DDL 혹은 SQL 문법 오류다. 공통적..

다 모르겠고, 가장 이상적인 아키텍처만 보고 싶은 사람은 현실적인 소규모 아키텍처 섹션을 보면 된다. 퍼블릭 클라우드를 사용할 때 영어로 하든 한국어로 하든 기능 이해하기도 어렵고 가이드가 복잡하더라도 AWS 사용하는데는 여러가지가 이유가 있다. 많은 회사가 AWS를 사용하고 있어서 경험싶은 것도 있지만, 학생으로서 가격이 큰 이유였다. AWS에는 수 많은 서비스들이 존재하고 완벽한 아키텍처를 구성하기 위해 많은 기능들을 추가할 수 있다. 하지만 의외로 일부 서비스를 제외하고는 합리적인 가격이거나 일정 범위 내에서 무료인 경우가 많다. NCP 아키텍처 NCP는 한국 클라우드이기도 하고 후발주자라 그런지 문서화가 굉장히 잘 되어있다. 가끔 AWS의 한국 도큐먼트를 보면 한국어를 읽고 있는데도 이해가 안되고..

디프만 14기에서 참여 중인 프로젝트에서 백엔드 리드 분이 엔티티의 id를 UUID, ULID로 설정한 것을 보았다. 늘 IDENTITY로 설정하여 MySQL이 AUTO_INCREMENT로 관리하도록 위임했기 때문에 기존 방식과 대비해서 어떤 장점이 있길래 사용하는지 알아보았다. AUTO_INCREMENT 전략의 단점 외부에서 예측하기 쉬운 PK PK가 선형적으로 증가하는 정수이기 때문에, 특정 데이터의 PK를 예측하기 쉬워진다. 실제로 request들의 파라미터를 테스트할 때 종종 느꼈던 것이다. 현재 유저의 id 2000이면 1 ~ 1999까지의 id를 가진 유저가 존재할 확률도 높은 것이다. 이는 단순히 노출된다의 문제를 넘어 SQL Injection 공격에도 취약해진다. DB에 의존적인 PK 개발..

사실 백엔드 공부를 하면서 인프라 단에서만 보안과 해킹 방어를 조심했지만, 어플리케이션 단에서의 보안은 크게 알아본 적은 없었던 것 같다. 프레임워크에서 기본적인 설정은 전부 되어 있어였지만, 알고 있지만 안하는 것이 아니라 아예 모르는 것은 문제가 될 수 있을 것 같다. 최근 참여한 모 기업의 채용 필기 테스트에서 이와 관련된 문제가 나왔었고, 최근 진행 중인 프로젝트에서 서버 리드가 UUID/ULID를 DB PK로 사용하는 것을 보고 찾아보던 중 이와 연관되어 한 번 정리해보고자 한다. SQL Injection 워낙 유명해 다들 한 번쯤은 들어봤을텐데, 임의의 SQL문을 주입하고 실행되게 하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위이다. 다양한 공격법이 있지만, 가장 대표적인 Error..

Install $ sudo apt update && sudo apt-get -y upgrade $ sudo apt-get install -y mariadb-server $ sudo mysql Configuration Environment setting $ sudo mysql mysql> use mysql mysql> SHOW VARIABLES LIKE 'c%'; (utf8 OR utf8mb4) mysql> SELECT now(); (KST 이여야함) mysql> exit; $ sudo timedatectl set-timezone 'Asia/Seoul' $ date $ sudo service mysql restart User setting $ sudo mysql mysql> use mysql; mysql..