일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |
- iam user
- spring
- error
- @Transactional
- jpa
- nosql
- Exception
- SQL
- aws
- 로그 시스템
- MongoDB
- Redis
- 에러 모니터링
- 테스트 주도 개발
- Spring Boot
- AWS IAM
- java
- TDD
- exceptionHandler
- aws 접근 권한
- 로그
- crud-update
- iam user 새성
- 예외 처리
- gradle
- 카카오 소셜 로그인 에러 #카카오 소셜로그인 redirect #카카오소셜로그인 프런트 연동 에러
- SENTRY
- Today
- Total
목록분류 전체보기 (12)
zini's blog
엔티티 조회 후 수정 vs 쿼리문으로 수정기본적인 crud 중 수정시, 엔티티 조회를 통해 객체를 가져와 수정하는 방법과, 쿼리문을 통해 update하는 방법의 차이가 뭘까? 그리고 어떤 방법을 사용해야 할까?(공부하며 작성한 글이라 틀린 부분이 있을 수 있습니다!) 1. 엔티티 조회 후 수정 (Dirty Checking)📌 작동 방식 - (@Transactional사용한 경우로 설명)엔티티를 DB에서 조회한 후, 해당 엔티티의 값을 변경함.JPA의 Dirty Checking(변경 감지)을 통해 트랜잭션 커밋 시점에 수정된 내용을 DB에 반영함.🧩 코드 예시@Transactionalpublic void updateOrder(Long orderId) { // 엔티티 조회 Order order = ..
들어가며스프링은 기본적으로 JAVA의 예외 처리 메커니즘(try-catch, 예외 던지기 등)을 기반으로 동작하지만, 스프링만의 예외 처리 구조와 핸들러를 통해 예외를 더 체계적이고 세밀하게 처리할 수 있도록 확장하였다.자바 예외 처리 메커니즘: 예외 발생 → 예외 전파(상위 메서드로) → 예외 처리 [JAVA] Error와 ExceptionJava에서는 오류를 Error(오류)와 Exception(예외)로 나눈다. 둘 다 모두 Object 클래스를 상속받는 Throwable 클래스를 상속받고 있다. Throwable 클래스: 모든 에러나 예외의 최상위 클래스: 오류나 예외에 대한 메시지를 담고(getMessage()), 예외 발생시에는 예외의 정보를 기록(printStackTrace()) Error..

도입 배경프로젝트의 배포와 사진 업로드 등에 aws 서비스를 이용해 진행하였다. ec2, RDS 뿐만 아니라 S3, CodeDeploy 등 aws의 여러 서비스를 이용하였고, 다른 백엔드 팀원과 협업하는 과정에서 의문이 생겼다. 처음엔 계정의 아이디와 비밀번호를 공유하며 진행하다 한 달뒤 2단계 인증이 의무적으로 도입되면서 나 이외의 다른 팀원은 로그인이 불가능한 상황이 생긴 것이다. '여러 팀원이 작업해야하는 상황이 매우 많을 것인데 어떤 방식으로 클라우드 서비스를 이용하는 거지?'이 의문을 가지고 있을 때 마침 전공과목인 [CloudComputing] 과목에서 AWS의 IAM을 배우게 되었다. IAM을 통해 적절히 접근을 제어하고 부여하며 협업을 진행할 수 있음을 알게되었고 이를 우리 프로젝트에 도입..

도입 배경프로젝트를 진행하면서 에러가 발생했을 때 가장 아쉬웠던 부분이 바로 로그 보기였다. 특히 여러명이 작업하던 중 프론트엔드에서 로그를 봐달라는 요청이 들어오면 여러 로그들이 섞여있어 해당 로그를 찾는데 시간이 소요되었다. 또한 어느 정도 시간이 흐른뒤 로그를 보려면 로그 페이지에서 열심히 스크롤을 내리거나 grep 등의 쉘 명령어로 찾아야 했다. 이러한 상황을 겪고 로그 시스템 또는 에러 모니터링 시스템 구축의 필요성을 느끼게 되었고, 같은 백엔드 팀원과의 회의 끝에 에러 모니터링 시스템인 Sentry를 사용해보기로 결정하였다. Sentry란?: 애플리케인션의 오류 및 성능 문제를 추적하고 모니터링할 수 있도록 돕는 오픈 소스 오류 추적 및 모니터링 도구: 애플리케이션에서 발생하는 오류를 실시간으..

📌 프로젝트 소개Howkiki - 생성형 AI를 활용하여 자연스러운 대화 흐름으로 주문 및 매장 관련 질문을 처리하는 '직원'의 역할을 하는 매장 고객 응대 챗봇 서비스📌 기술 흐름최종 목표 : 생성형 AI를 활용한 프롬프트 엔지니어링을 통해 가게에 대한 질문과 주문을 처리하는 챗봇과 백엔드 API 및 서버의 DB를 연결하여 챗봇에 실시간 정보 제공 및 작성이 가능하도록 한다. 우선 핵심기능이자 데모 시현을 위한 기술 구현 흐름은 다음과 같다. AI 챗봇에서 사용자와의 대화를 통해 최종적으로 주문 내역을 받고, 이를 json형식의 requestBody로 포함해 POST 메소드 형식으로 백엔드 주문 생성 API를 호출한다. 서버의 DB에 새로운 주문이 등록되고 프론트에서는 주문 조회 API를 통해 ..

동아리 프로젝트 백엔드 개발이 마무리되어 가고 프론트에서 API연결을 시작하고 일주일 쯤 되었을 때,프론트 팀원으로부터 지금 디스코드로 들어와 줄 수 있는지 연락을 받았다. 다름이 아니라 이때 로그인 연동이 안되서 담당 프론트, 백 팀원이 고생하고 있었는데 잘 해결이 안되서 요청이 온 것 이었다. (나도 로그인 경험이 있으나 기억이 가물가물한 상태..ㅎ) 우리는 카카오 소셜 로그인을 사용하기로 했는데 프론트에서 리다이렉트 페이지로 안넘어간다는 얘기를 들었다. 나중에 돌아보니 이게 정말 큰 힌트이자 주요 원인이였는데 다들 정확한 문제 원인을 알지 못해 한참 헤맸었다. 결론을 먼저 말하자면, application.yml 에 redirect uri를 변경하지 않아 생긴 문제였다. 이 경험을 토대로 카카오 ..

NoSQL기본 개념“Not Only SQL”, 즉 비관계형 데이터베이스를 의미관계형 데이터베이스(RDBMS)와 데이터를 저장하는 방식이 다름스키마를 미리 정의하지 않아도 데이터를 저장할 수 있는 유연성이 특징키-값 쌍, 문서, 그래프, 열 기반 등 다양한 유형 존재높은 확장성과 가용성실시간 웹 애플리케이션이나 빅데이터를 처리하는데 널리 사용됨RDBMS vs NoSQL DBMS데이터 구조 차이RDBMS : 테이블 형식으로 데이터 저장, 각 테이블은 행과 열로 구성NoSQL DBMS : 고정된 스키마 없이 데이터 저장 가능, 다양한 데이터 모델 저장 가능스키마 유연성RDBMS : 미리 정의된 스키마에 따라 저장해야 하며 스키마 변경이 복잡NoSQL DBMS : 스키마 없이도 동적으로 데이터 구조 변경할 수 ..
JUnit 5 모듈 구성JUnit은 크게 세가지 요소로 구성JUnit 플랫폼 : 테스팅 프레임워크를 구동하기 위한 런처와 테스트 엔진을 위한 API 제공JUnit Jupiter : JUnit 5를 위한 테스트 API와 실행 엔진 제공JUnit Vintage : JUnit 3,4 로 작성된 테스트를 Junit 5 플랫폼에서 실행하기 위한 모듈 제공JUnit Jupiter API를 테스트 구현으로 사용하도록 설정사용 위해선 주피터 모듈을 의존성에 추가 (maven, gradle 파일에 추가)junit-jupiter 모듈에는 테스트 코드를 작성하고 실행하기 위한 junit-jupiter-api, params, engine 모듈을 포함하고 있음JUnit 플랫폼을 이용해서 테스트를 실행하도록 설정JUnit 5를 ..
기능 명세기능 구현을 위해서 기능을 크게 입력과 출력으로 나눠서 생각할 수 있음입력: 기능을 실행하는데 필요한 값메서드와 파라미터로 전달결과: 여러 형식으로 정의할 수 있음리턴 값, Exception변경 ex. DB에 데이터를 추가하는 등의 시스템 상태의 변경설계는 기능 명세로부터 시작요구 사항 문서를 이용해서 기능 명세를 구체화하는 동시에 입력과 결과를 도출 → 도출한 기능 명세를 코드에 반영 설계 과정을 지원하는 TDD테스트 코드를 만들기 위해 무엇이 필요?테스트할 기능을 실행클래스, 메서드, 함수 이름 결정파라미터 (이름 & 인자의 타입과 개수) 결정실행 결과를 검증리턴 값이름은 설계에서 매우 중요! 이름을 고민하는 시간을 아까워하지 말자! 필요한 만큼만 설계하기필요할 것으로 예측해서 미리 설계를 ..
테스트 코드 작성 순서테스트 코드 작성 순서쉬운 경우에서 어려운 경우로 진행예외적인 경우세서 정상인 경우로 진행초반에 복잡한 테스트부터 시작하면 안되는 이유초반부터 복잡한 상황을 테스트로 추가하면 해당 테스트를 통과시키기 위해 한 번에 구현해야 하는 코드 증가구현 어려움, 버그 발생 증가, 시간 소모....구현하기 쉬운 테스트부터 시작하기암호 강도 측정에서 가장 쉬운 것?모든 조건 충족하는 경우 -> 그냥 STRONG 리턴하면 됨모든 조건 충족 X -> 그냥 WEEK 리턴하면 됨모든 조건 충족하는 경우로 시작해보자그 다음으로 쉬운 것?모든 규칙 충족X -> 복잡한 규칙만 충족 -> 그 중에서도 길이 조건이 제일 쉬워보임두 규칙 충족 -> 한 규칙 충족하는 경우 다음으로이런 식으로 점진적으로 수 분내 구현..