AI는 생각보다 자주 실수한다

최근 Claude Code 같은 AI 에이전트를 활용해 개발하는 사례가 늘고 있다.

나도 Spring Boot + React 기반 AI 전자책 생성 서비스 Remon을 개발하면서 Claude Code를 꽤 적극적으로 썼는데, 초반에는 같은 요청을 해도 결과가 들쭉날쭉했다.

AI가 반복했던 실수들을 나열해보면 이렇다.

• 백엔드 작업인데 프론트 파일을 건드리거나, 반대로 프론트 작업인데 백엔드 코드를 수정하는 경우
• Book 엔티티를 Controller에서 그냥 반환해버리는 코드 생성 (DTO 쓰라고 했는데)
• 커밋 요청도 안 했는데 알아서 커밋하려는 시도
• 요청하지 않은 리팩토링을 같이 해버려서 기존 구조가 바뀌는 경우
• 굳이 필요하지 않은 라이브러리를 추가하는 경우

처음엔 AI 성능 문제인가 싶었는데, 곰곰이 생각해보니 그게 아니었다.
AI가 작업할 환경 자체가 제대로 정의되어 있지 않았던 것이다.

하네스 엔지니어링이란?

찾아보니 이걸 하네스 엔지니어링(Harness Engineering) 이라고 부르더라.

AI에게 좋은 프롬프트를 주는 것과는 다른 개념이다.
프로젝트 규칙을 정의하고, 작업 범위를 제한하고, 코드 스타일을 통일하고, 보안 취약점 방지 규칙을 명시해서 AI가 올바른 방향으로 일하도록 환경 자체를 설계하는 것이다.

한 마디로, AI한테 일을 맡기기 전에 일하는 방식을 먼저 정해두는 것.

CLAUDE.md로 작업 환경을 설계하다

Remon은 백엔드(Spring Boot), 프론트엔드(React), 앱(React Native) 세 영역으로 나뉜다.
각 영역마다 별도의 CLAUDE.md를 만들어서 작업 규칙을 문서로 정리했다.

작업 범위 제한

## 작업 범위
- 이 파일이 있는 backend/ 폴더 내부만 읽고 수정한다.
- 상위 디렉터리나 frontend/는 접근하지 않는다.

이 한 줄이 생각보다 효과가 컸다.
백엔드 작업 중에 프론트 파일을 건드리는 문제가 바로 사라졌다.

코드 수정 원칙

## 코드 수정 원칙
1. 파일을 먼저 Read한 뒤 수정한다. 읽지 않은 파일은 수정하지 않는다.
2. 요청된 범위 외 수정(리팩터링, 주석 추가 등)은 하지 않는다.
3. 새 라이브러리는 꼭 필요한 경우에만 추가한다.
4. 보안 취약점(SQL Injection, XSS, 하드코딩된 시크릿 등)을 도입하지 않는다.

특히 2번이 중요했다. AI가 요청하지 않은 리팩토링을 같이 하는 습관이 있었는데, 이 규칙을 명시하고 나서 딱 요청한 것만 처리하게 됐다.

커밋 규칙

## Git / 커밋 규칙
- 사용자가 명시적으로 요청할 때만 커밋한다.
- 커밋 메시지: feat: / fix: / refactor: / test: / docs: / style:

이게 없을 때는 AI가 알아서 커밋을 해버리거나, 메시지 형식이 매번 달랐다.
명시해두고 나서는 내가 원하는 타이밍에, 원하는 형식으로 커밋이 이루어졌다.

실제로 달라진 것들

가장 크게 달라진 건 컨텍스트를 매번 설명하지 않아도 된다는 점이었다.

CLAUDE.md 적용 전에는 작업을 시작할 때마다 이런 설명을 반복해야 했다.

"이 프로젝트는 Spring Boot 기반이고, 패키지 구조는 이렇게 되어있고, DTO를 꼭 써야 하고..."

적용 후에는 Claude Code가 CLAUDE.md를 먼저 읽고 프로젝트 맥락을 유지한 채 작업했다.

사례 1 — Gemini API 재시도 로직

Gemini API에서 간헐적으로 500/503 오류가 발생했을 때의 일이다.
CLAUDE.md에 기술 스택과 코드 원칙이 명시되어 있었기 때문에, AI가 새 클래스를 만들거나 구조를 바꾸지 않고 기존 OpenAiService 안에 재시도 로직을 정확히 추가했다.

// maxAttempts=3, 3초 대기 재시도 로직
// 규칙이 없었다면 새 클래스를 만들거나 구조를 바꿨을 가능성이 높다

사례 2 — 레몬 차감 비관적 락

동시 요청 시 레몬이 중복 차감되는 문제를 해결할 때도 비슷했다.
@Lock(LockModeType.PESSIMISTIC_WRITE) 위치를 Repository로 정확히 잡고, LemonService의 consumeLemon에만 @Transactional을 명시했다.
패키지 구조가 CLAUDE.md에 정의되어 있었기 때문에, AI가 구조를 임의로 바꾸지 않고 기존 흐름 안에서 처리했다.

프롬프트보다 중요한 건 컨텍스트

이걸 적용하면서 가장 크게 느낀 점이다.

좋은 프롬프트 하나를 고민하는 것보다, 프로젝트 구조와 규칙을 문서로 정리해두는 게 훨씬 효과적이었다. 같은 모델인데 환경을 어떻게 설계하느냐에 따라 결과 품질이 완전히 달랐다.

마무리

AI 도구를 쓰면서 느낀 건, 결국 AI를 잘 쓰는 개발자는 프롬프트를 잘 쓰는 사람이 아니라 AI가 올바르게 일할 수 있는 환경을 만드는 사람이라는 것이다.

앞으로 AI 기반 개발이 더 일반화될수록, 이런 환경 설계 능력이 더 중요해질 것 같다.

실제 CLAUDE.md가 궁금하다면 아래 레포에서 확인할 수 있다.

👉 https://github.com/RaymondYoon/remon-service

MyBatis

장점

• SQL을 직접 작성 -> 쿼리 제어가 자유롭다
• 복잡한 JOIN, 동적 쿼리 처리에 강하다
• 어떤 SQL이 실행되는지 명확하게 보인다

단점

• SQL을 전부 직접 작성해야 해서 생산성이 떨어질 수 있다.
• 테이블 변경 시 SQL도 수정해야 하므로 유지보수가 힘들 수 있다.
• 객체지향적인 설계에는 조금 약한 느낌..?

  <!-- UserMapper.xml -->
  <select id="findByUsername" resultType="User">
  SELECT * FROM users WHERE username = #{username}
  </select>

  // UserMapper.java
  User findByUsername(String username);

MyBatis는 이런 곳에서 유용한듯

• 통계, 분석 등 복잡한 쿼리가 많은 기능
• 성능 튜닝이 중요한 조회 중심 서비스
• SQL 작성이 익숙한 팀원들과 협업할 때

  ---

JPA

장점

• 기본적인 CRUD는 쿼리 없이도 가능 -> 생산성이 좋다
• 엔티티 중심의 객체지향 설계가 가능하다
• 지연 로딩, 변경 감지 같은 고급 기능도 지원한다

단점

• 처음엔 개념이 많고 어렵다(영속성 컨텍스트, 지연 로딩 등)
• 복잡한 쿼리 작성이 불편하고 성능 튜닝이 까다로울 수 있음
• 어떤 쿼리가 나가는지 감이 안 잡힐 때가 있을수도..?

  // UserRepository.java
  public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
  }

JPA는 이런 곳에서 유용한 것 같다.

• CRUD가 주로 이루어지는 일반적인 웹 서비스
• 도메인 중심의 객체지향 모델링이 중요한 경우
• 빠르게 개발하고 유지보수까지 고려해야 할 때

  ---

정리하며

결국 선택은 상황에 따라서

개인적으로 CRUD 위주의 서비스는 JPA, 복잡한 통계성 쿼리나 성능이 중요한 부분은 MyBatis로 나눠서 쓰는게 좋았다. 둘 중 하나만 고집할 필요는 없고, 상황에 따라 선택하거나 혼합해서 사용하는 것도 좋은 방법이었다.

그럼 MyBatis랑 JPA는 어떻게 돌아가는 걸까?

• MyBatis는 XML에 SQL을 직접 작성하고, 인터페이스랑 연결해서 사용하는 방식이다

resources/mapper/ 같은 경로에 XML 파일을 만들고, SQL을 <select>, <insert> 등으로 작성해준다.
그리고 인터페이스 파일에서 XML의 id 값과 같은 메서드를 선언하면 된다.

<!-- UserMapper.xml -->
<select id="findByUsername" resultType="User">
  SELECT * FROM users WHERE username = #{username}
</select>

// UserMapper.java
@Mapper
public interface UserMapper {
    User findByUsername(String username);
}

이렇게 매핑하면 UserMapper의 메서드를 호출할 때 XML 안의 쿼리가 실행된다. SQL을 내가 다 짜야 하긴 하지만, 그만큼 컨트롤도 확실히 가능하다. 복잡한 조건이 필요한 쿼리나 성능 튜닝이 필요할 때 직접 건드릴 수 있다는 점이 꽤 큰 장점이다.

JPA는 Repository 인터페이스만 만들어도 기본적인 CRUD는 다 된다

Spring Data JPA에서 제공하는 JpaRepository를 상속받으면 별다른 설정 없이도 데이터를 저장하고 조회할 수 있다.

public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByUsername(String username);
}

메서드 이름만 지어도 내부적으로 쿼리가 생성돼서 실행된다. 만약 복잡한 쿼리가 필요하다면 @Query 어노테이션을 써서 JPQL을 직접 작성할 수도 있다.

코드를 객체 중심으로 작성할 수 있다는 게 가장 큰 장점이고, 설계가 잘 되어 있다면 유지보수나 확장도 수월하게 할 수 있다.

이렇게 동작 방식까지 살펴보니, JPA는 편리함과 구조적인 설계를 지향하고, MyBatis는 쿼리 제어의 유연함과 성능 중심의 설계에 가깝다는 게 확실히 보인다.

둘 다 장단점이 확실해서 프로젝트 상황에 따라 적절히 고르는 게 중요한 것 같다.

기본 타입(Primitive Type)과 참조 타입(Reference Type)

스프링에서 엔티티(Entity)를 만들 때, 필드 타입을 지정하는 과정에서 기본 타입과 참조 타입 중 어떤 것을 선택해야 할지 고민할 때가 있다. 이 둘의 차이를 알면 더 적절한 선택을 할 수 있다.

기본 타입 (Primitive Type)

기본 타입은 가장 단순한 데이터 타입으로, 메모리에서 직접 값을 저장하는 방식으로 동작한다. 대표적인 기본 타입은 다음과 같다.

• byte, short, int, long (정수형)
• float, double (실수형)
• char (문자형)
• boolean (논리형)

기본 타입은 고정된 크기의 메모리를 차지하며, 값을 직접 저장한다. 예를 들어 int a = 10;이라고 선언하면, a에는 실제 숫자 10이 저장된다.

참조 타입 (Reference Type)

반면, String과 같은 참조 타입은 실제 값을 저장하는 것이 아니라, 객체의 주소(Reference)를 저장한다. 즉, String str = "Hello"; 라고 선언하면, "Hello"라는 문자열 객체가 메모리에 생성되고, str 변수는 그 객체의 주소를 가리킨다.

Java에서 String은 클래스이므로 대문자로 시작하며, 이는 객체 지향 프로그래밍에서 일반적인 네이밍 규칙이다. 반면 int와 같은 기본 타입은 더 가볍고 메모리를 효율적으로 관리하기 위해 소문자로 지정되어 있다.

스프링에서의 적용

스프링 프로젝트에서 엔티티(Entity) 클래스의 필드를 정의할 때, 기본 타입과 참조 타입 중 어떤 것을 사용할지 고민할 수 있다. 예를 들어:

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private int age; // 기본 타입
    private String name; // 참조 타입
}

위 코드에서 age는 기본 타입 int를 사용했으며, name은 String 참조 타입을 사용했다. int와 같은 기본 타입은 null 값을 가질 수 없지만, Integer와 같은 래퍼 클래스(Wrapper Class)를 사용하면 null 처리가 가능하다.

private Integer age; // null 값 허용 가능

정리

스프링 프로젝트를 진행하면서 이런 차이를 이해하면 더 적절한 타입을 선택할 수 있다. 앞으로도 프로젝트를 하면서 궁금했던 점들을 정리해보려고 한다. 😊

해커톤 후기

해커톤을 처음 가봤는데 사람이 진짜 진짜 많았다.. 다른 학교들 사람들도 보면서 내가 이런 경험도 해보다니 너무 좋은 경험이라고 생각했다.

친구들이랑 이런 사진도 찍구

날씨도 너무너무 좋았다~ 여러가지 부스 체험도 해보고 팀원끼리 이야기도 나누면서 새벽을 보내고 좋은 경험이였다~

내가 백엔드로 가고 첫 프로젝트였는데 간단한 CRUD 구현과 네이버 뉴스 API 활용하는 담당을 맡았다. 솔직히 지금도 모르겠지만, 저 때는 내가 할 수 있을까? 라는 생각이 들었던것 같다. 간단한 CRUD 구현조차 구글링과 gpt의 도움을 받고, 네이버 뉴스 API 활용하는것은 구글링과 네이버 공식 문서 및 gpt를 쓰는데도 시간이 많이 걸렸다. 하지만 이렇게 하면서 성장을 많이 한것 같다.

내가 맡은 부분 중 2가지를 봐볼건데 좋아요 기능과 네이버뉴스 API를 활용하는 것이다.

첫 해커톤 프로젝트 리뷰 : 좋아요 기능과 네이버 뉴스 API 활용기

Code Review : 좋아요(Like) 기능 구현 및 개선 포인트

• 프로젝트 구조

  like/
  ├── common/ │ └── ResponseResult.java
  ├── controller/ │ └── LikeController.java
  ├── dto/ │ └── LikeRequestDTO.java
  ├── entity/ │ └── Like.java
  ├── exception/ │ └── CustomException.java
  ├── repository/ │ └── LikeRepository.java
  └── service/ ㅒ └── LikeService.java

프로젝트 구조는 각 계층별 역할을 분리하여 유지보수와 확장에 용이한 구조가 아닐까 생각한다! (GPT 최고!) 근데 나중에 프로젝트할때 같이 하는 사람마다 다르게 분류할 수 도 있다는 것을 깨달았다!

<각 파일 및 코드 리뷰>

(common)

• ResponseResult.java
• 역할:* API 응답 구조(성공 여부, 데이터, 에러 메시지) 통일 관리
• 아쉬운 점:* 응답에 타임스탬프 등 추가 메타 정보 부족

(controller)

• LikeController.java
• 역할:* 클라이언트의 좋아요 추가/삭제 요청을 받아 서비스 호출 및 결과 반환
• 아쉬운 점:* 중복 try-catch로 인한 코드 반복, 글로벌 예외 처리 미적용

(dto)

• LikeRequestDTO.java
• 역할:* 좋아요 요청에 필요한 postId 데이터 캡슐화
• 아쉬운 점:* 향후 확장 대비 추가 데이터 고려 부족

(entity)

• Like.java
• 역할:* 좋아요 정보를 DB에 매핑, Board와 Member와의 연관관계 관리
• 아쉬운 점:* 양방향 연관관계 설정 미검토, 로깅 기능 부재

(exception)

• CustomException.java
• 역할:* 좋아요 기능 관련 예외 상황 전달
• 아쉬운 점:* 에러 코드 등 상세 예외 정보 미포함

(repository)

• LikeRepository.java
• 역할:* DB에서 Like 관련 CRUD 및 존재 여부 확인
• 아쉬운 점:* 복잡한 쿼리 최적화나 커스텀 쿼리 고려 미흡

(service)

• LikeService.java
• 역할:* 좋아요 생성/삭제, 중복 체크, 트랜잭션 관리 및 추천수 업데이트
• 아쉬운 점:* boardService 의존성으로 인한 도메인 간 결합, 이벤트 기반 처리 미고려, 로그 기록 미흡

Code Review : 좋아요(Like) 기능 구현 및 개선 포인트

• 프로젝트 구조

  healthnews/ ├── client/
  │ └── JsoupCrawling.java ├── controller/
  │ └── HealthNewsController.java ├── dto/
  │ ├── HealthNewsResponseDto.java │ ├── NewsApiResponseDto.java │ └── NewsSummaryDto.java ├── entity/
  │ └── HealthNews.java ├── exception/
  │ ├── NaverApiCallException.java │ ├── NewsControllerAdvice.java │ └── NewsNullException.java ├── repository/
  │ ├── HealthNewsRepository.java │ └── NewsApiResponseRepository.java └── service/
  ㅐ └── HealthNewsService.java

<각 파일 및 코드 리뷰>

(client)

• JsoupCrawling.java
• 역할:* Jsoup을 사용해 URL의 HTML을 파싱하고, 지정된 쿼리로 요소(Elements)를 추출하여 반환
• 아쉬운 점:* 예외 발생 시 단순 e.printStackTrace()에 의존, 로깅 및 재시도 메커니즘 미구현

(controller)

• HealthNewsController.java
• 역할:* 키워드 기반 건강 뉴스 검색과 사용자 건강 상태 기반 뉴스 제공 API 엔드포인트 관리
• 아쉬운 점:* 검색과 사용자 뉴스 조회 기능이 혼재, 입력 검증 및 예외 처리 보완 필요

(dto)

• HealthNewsResponseDto.java

• 역할:* 뉴스 응답 데이터(제목, 링크, 설명, 이미지 URL)를 캡슐화하고 이미지 링크 유효성 검사 제공

• 아쉬운 점:* 추가적인 메타 정보나 확장 시 고려할 필드 부족

• NewsApiResponseDto.java

• 역할:* 뉴스 API 응답 데이터를 담고, Naver 뉴스만 필터링 및 HealthNewsResponseDto 변환 제공

• 아쉬운 점:* JsoupCrawling 인스턴스를 직접 생성하여 DI(의존성 주입) 미적용, 테스트 용이성 저하

• NewsSummaryDto.java

• 역할:* 뉴스 요약 정보를 담고, 이미지 크롤링을 통해 HealthNewsResponseDto로 변환

• 아쉬운 점:* JsoupCrawling 의존성을 외부 주입 대신 내부 처리하여 유연성 부족

(entiry)

• HealthNews.java
• 역할:* 건강 뉴스 엔티티로, DB 테이블과 매핑되어 뉴스 저장 관리
• 아쉬운 점:* 기본 CRUD 외에 추가 검색이나 비즈니스 로직 반영 미흡

(exception)

• NaverApiCallException.java

• 역할:* 네이버 API 호출 실패 시 발생하는 커스텀 예외 정의

• 아쉬운 점:* 디버깅을 위한 추가 정보 제공 미흡

• NewsControllerAdvice.java

• 역할:* NewsNullException과 NaverApiCallException에 대한 전역 예외 처리

• 아쉬운 점:* 추가 예외 유형 처리 및 통일된 응답 포맷 적용 필요

• NewsNullException.java

• 역할:* 뉴스 결과가 없을 경우 발생하는 커스텀 예외 정의

• 아쉬운 점:* 상세 메시지 및 예외 코드 부여 미흡

(repository)

• HealthNewsRepository.java

• 역할:* HealthNews 엔티티에 대한 CRUD 작업을 수행하는 Repository

• 아쉬운 점:* 기본 CRUD 외 추가 검색 조건 및 페이징 기능 미구현

• NewsApiResponseRepository.java

• 역할:* 네이버 뉴스 API 호출 및 응답 데이터를 Optional 형태로 반환

• 아쉬운 점:* RestTemplate 사용 시 커넥션 타임아웃, 에러 핸들링 개선 필요

(service)

• HealthNewsService.java
• 역할:* 네이버 뉴스 API를 통해 뉴스 데이터를 수집, 필터링, 가공하여 최종 HealthNewsResponseDto로 반환 및 DB저장
• 아쉬운 점:* 반복 API 호출 시 매직넘버(2000, 100, 4)사용, API 제한 고려 및 효율성 개선 필요

마무리 한마디

이번 리뷰를 통해서 좋아요 기능과 네이버 뉴스 API 모두에서 전역 예외 처리, 로깅, 의존성 관리 및 API 호출 최적화 등 개선할 부분이 많음을 확인했으니 앞으로 이러한 점들을 보완해 더 안정적이고 확장 가능한 시스템을 만들어보자잇~ 나의 코드를 보는 눈을 더 키워 봅시다!

취업을 하여 실무를 경험하고 싶은 요즘 스펙도 없고 요즘 자존감이 떨어지고 불안한 시기인 아무것도 아닌 나를 위해 좀 더 성실하고 열심히 살기위해 글을 쓴다. 스티브 잡스분께서 말씀하신 "어제를 뒤돌아보는 건 그만하자. 그 대신 내일을 발전시켜 나가자." 라는 말을 생각하며 나는 더 나은 내일을 위해 발전시켜 나가는것이다! 취업하고싶다아

자료구조란 무엇?

프로그래밍에서 효율적인 데이터 관리와 처리를 위해 필수적으로 알아야 하는 개념이 바로 자료구조라고 생각한다. 자료구조는 데이터를 저장하고 조직화하는 방법을 의미하고 알고리즘과 결합하여 프로그램의 성능을 최적화할 수 있다. 이 글에서는 자료구조의 기본 개념과 몇 가지 주요 자료구조를 살펴볼 것이다.

1. 자료구조의 필요성

자료구조는 다양한 형태의 데이터를 적절히 조직화하여 더 효율적인 연산을 가능하게 한다. 예를 들어 특정 데이터를 빠르게 검색해야 할 때 적합한 자료구조를 사용하면 검색 속도를 크게 향상시킬 수 있다. 효율적인 자료구조를 선택함으로써 시간과 메모리를 절약하고 프로그램의 성능을 최적화할 수 있다.

2. 자료구조의 종류

2-1 배열 (Array)

배열은 같은 데이터 타입의 요소들을 연속된 메모리 공간에 저장하는 자료구조이다. 각 요소는 고유한 인덱스를 통해 접근할 수 있다.

장점

• 빠른 접근 속도: 인덱스를 통해 O(1) 시간 복잡도로 빠르게 특정 요소에 접근할 수 있다.
• 간단한 구조: 메모리 구조가 단순하고 이해하기 쉬워 자주 사용된다.

단점

• 고정된 크기: 선언 시 크기를 지정해야 하므로 크기 변경이 어렵다.
• 비효율적인 삽입/삭제: 중간에 데이터를 삽입하거나 삭제할 경우에 데이터를 이동해야 하므로 시간 복잡도가 O(n)이다.

  ---

2-2 연결 리스트 (Linked List)

연결 리스트는 각각의 노드가 데이터와 다음 노드를 가리키는 포인터를 포함하는 구조이다. 노드를 동적으로 추가 및 삭제할 수 있어 유연성이 높다.

장점

• 동적 크기 조절: 필요에 따라 크기를 유연하게 변경할 수 있다.
• 효율적인 삽입/삭제: 중간 삽입 및 삭제 시 데이터를 이동할 필요가 없어 O(1) 시간 복잡도로 처리할 수 있다.

단점

• 느린 접근 속도: 배열과 달리 인덱스로 접근할 수 없기 때문에 특정 노드에 접근하려면 처음부터 순회해야 한다.
• 추가 메모리 필요: 각 노드마다 다음 노드를 가리키는 포인터를 저장해야 하므로 메모리 사용량이 증가한다.

  ---

2-3 스택 (Stack)

스택은 데이터를 한쪽 끝에서만 삽입하고 제거하는 자료구조로, LIFO(Last In, First Out) 원칙을 따른다. 대표적으로 함수 호출, 되돌리기 기능 등에 사용된다.

장점

• 간단한 구현: 삽입 및 삭제가 한쪽 끝에서만 이렁나기 때문에 구조가 단순하다.
• 빠른 삽입/삭제: O(1) 시간 복잡도로 삽입과 삭제를 할 수 있다.

단점

• 제한된 접근 방식: 마지막에 삽입된 요소만 접근 가능하여 중간 요소를 접근할 수 없다.

  ---

2-4 큐 (Queue)

큐는 FIFO(First In, First Out) 원칙을 따르는 자료구조이다. 데이터를 앞쪽에서 제거하고 뒤쪽에 삽입한다. 대기열과 같은 구조에 적합하다.

장점

• 순서 유지: 먼저 들어온 데이터가 먼저 나가는 구조로, 순서가 중요한 작업에 유리하다.
• 빠른 삽입/삭제: 삽입과 삭제가 양쪽 끝에서만 일어나므로 O(1) 시간 복잡도로 효율적이다.

단점

• 제한된 접근 방식: 중간에 있는 요소에 직접 접근할 수 없다.

  ---

2-5 트리 (Tree)

트리는 계층 구조를 가지는 비선형 자료구조로, 노드 간 부모-자식 관계가 존재한다. 이진 트리, AVL 트리, B-트리 등 다양한 형태가 있으며 데이터 구조와 알고리즘 문제에서 자주 사용된다.

장점

• 빠른 탐색: 정렬된 트리 구조에서는 원하는 데이터를 빠르게 탐색할 수 있다. 예를 들면 이진 탐색 트리는 O(log n) 시간 복잡도를 가진다.
• 계층적 데이터 표현: 트리 구조를 통해 계층적으로 데이터를 나타낼 수 있어 파일 시스템이나 조직도 표현에 적합하다.

단점

• 복잡한 구현: 삽입, 삭제, 균형 조정이 복잡할 수 있고 메모리와 연산 성능이 요구된다.
• 비용이 많이 드는 균형 유지: 자가 균형 트리(BST)의 경우 삽입과 삭제 시 균형을 맞추기 위해 추가 연산이 필요하다.

  ---

2-6 그래프 (Graph)

그래프는 노드(정점)와 그 노드들을 연결하는 간선(엣지)으로 이루어진 자료구조이다. 방향 그래프, 무방향 그래프, 가중치 그래프 등 다양한 종류가 있고 네트워크, 경로찾기 등의 문제에 활용된다.

장점

• 복잡한 관계 표현 가능: 그래프는 네트워크, 지도 등 복잡한 데이터 간의 관계를 표현하는데 유리하다.
• 유연한 구조: 장점과 간선의 관계를 자유롭게 설정할 수 있어 다양한 문제를 해결할 수 있다.

단점

• 높은 메모리 사용량: 노드와 간선을 모두 저장해야 하므로 메모리 소모가 크다.
• 복잡한 구현: 경로 탐색, 최단 거리 등 다양한 알고리즘이 필요해 구현이 복잡할 수 있다.

이처럼 각각의 자료구조는 특정한 장점과 단점을 가지고 있으므로 용도에 따라 최적의 자료구조를 선택하는 것이 중요하다.

백엔드 스터디 (4)

목차

1. 기본 키(PK) 어노테이션
2. 필드/컬럼 어노테이션
3. 객체와 테이블 매핑
4. REST API 개념
5. 컨트롤러에서 사용하는 어노테이션

1. 기본 키(PK) 어노테이션

• @Id: 엔티티의 기본 키를 선언하는 어노테이션
• @GeneratedValue: 기본 키 값을 자동으로 생성하는 전략을 설정하는 어노테이션
  • GenerationType.AUTO : 자동으로 키를 생성
  • GenerationType.IDENTITY : 데이터베이스에 의해 키를 생성

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

2. 필드/컬럼 어노테이션

• @Column : 필드를 테이블 컬럼에 매핑할 때 사용되는 어노테이션
  • name : 테이블의 컬럼명
  • nullable : null 값을 허용할지 여부
  • length : 문자열의 최대 길이 설정

@Column(name = "username", nullable = false, length = 50)
private String name;

• @Enumerated : 자바의 enum 타입을 데이터베이스에 매핑할 때 사용

  @Enumerated(EnumType.STRING)
  private RoleType roleType;
  

### 3. 객체와 테이블 매핑
Hibernate의 hbm2ddl.auto 설정을 통해 엔티티와 테이블 간의 매핑 및 자동 생성 여부를 설정할 수 있다.
* create, update, validate 등 다양한 옵션을 선택할 수 있으며, 실제 개발 환경에서 주의가 필요하다.

<hr>

### 4. REST API 개념
REST API는 웹 시스템에서 분산된 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐이다. HTTP 프로토콜을 사용해 다양한 리소스를 주고받으며 각 리소스는 URL로 식별된다.

### 5. 컨트롤러에서 사용하는 어노테이션

@Controller
* @Controller와 @ResponseBody를 결합한 어노테이션으로 JSON/XML 형식의 데이터를 반환할때 사용된다.
```java
@RestController
public class MyRestController {
    @GetMapping("/greeting")
    public String greeting() {
        return "Hello, World!";
    }
}

@RequestParam

• URL 쿼리 파라미터로 전달된 값을 메소드 매개변수에 바인딩한다.

  @GetMapping("/test")
  public void test(@RequestParam String name, @RequestParam int price) {
    System.out.println(name);  // 출력: spring
    System.out.println(price); // 출력: 20000
  }

@RequestBody

• HTTP 요청의 바디 부분을 자바 객체로 변환해준다. 주로 POST 메소드에서 사용된다.

  @PostMapping("/new")
  public void createQuestion(@RequestBody QuestionDTO dto) {
    // 처리 로직
  }

@PathVariable

• URL 경로에서 값을 가져올때 사용된다. 경로에 있는 변수를 메소드 매개변수에 바인딩한다.

  @GetMapping("/champions/{name}")
  public List<String> getChampionByName(@PathVariable String name) {
    return championService.getChampionByName(name);
  }

마무리

Spring Boot에서 제공하는 어노테이션들은 REST API 개발에서 매우 유용하게 활용된다. 이번 포스팅에서는 그중에서 자주 사용되는 기본 어노테이션들과 컨트롤러 어노테이션을 알아보았다.

백엔드 스터디 (3)

구조

애플리케이션 구조

Spring 애플리케이션은 다음과 같은 주요 구성들로 이루어져 있다. 여기서 각 구성 요소가 어떻게 상호작용하는지 이해하는것이 중요하다.

• Controller : 클라이언트로부터 HTTP 요청을 받아 처리한다.

• Service : 비즈니스 로직을 구현하며, 데이터를 처리하고 저장소와 상호작용한다.

• Repository : 실제 데이터베이스와 상호작용하며, CRUD 작업을 처리한다.

• DTO : 데이터 전송 객체로, 계층 간 데이터를 전달하는 역할을 한다.

패키지 구조

다음은 일반적인 Spring 프로젝트의 패키지 구조다.

• config : 애플리케이션 설정 파일이 위치하는 패키지

• controller : HTTP 요청을 처리하는 컨트롤러 클래스가 위치

• domain : 도메인 객체들이 정의된 곳

• repository : 데이터베이스와의 상호작용을 담당하는 리포지토리 클래스가 위치

• service : 비즈니스 로직을 담당하는 서비스 클래스가 위치

JPQL (Java Persistence Query Language)

JPQL은 객체를 대상으로 쿼리를 작성하는 Java Persistence API의 쿼리 언어이다. SQL과 문법이 비슷하지만 테이블이 아닌 엔티티 객체에 대한 쿼리를 수행한다.

JPQL 기본 예시

@PersistenceContext
EntityManager em;

public void main save(Board board) {
    em.persist(board);
}

EntityManager를 통해 Board 엔티티를 데이터베이스에 저장하는 방법을 보여준다. JPQL을 사용하면 SQL과 유사하게 엔티티 객체를 조회하고 수정할 수 있다.

JPQL로 데이터 조회

JPQL을 사용해 데이터를 조회할 때는 @Query 어노테이션을 사용할 수 있다.

@Query("SELECT c FROM ChatRoom c WHERE c.roomId = :roomId")
ChatRoom findChatRoomByRoomId(@Param("roomId") String roomId);

위 코드는 ChatRoom 엔티티에서 특정 roomId 값을 기준으로 데이터를 조회하는 JPQL 쿼리이다.

연결

Spring Data JPA와 데이터베이스를 연결하기 위해서는 설정 파일을 사용해 데이터베이스 관련 정보를 설정해야한다.

dependencies {
    implementation'org.mariadb.jdbc:mariadb-java-client:3.1.2'
    implementation'org.springframework.boot:spring-boot-starter-data-jpa'
}
-----------------------------------------------
spring:
  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost:8080/yourdb
    username: 사용자이름
    password: 비밀번호

Spring Boot 애플리케이션이 MariaDB와 연결되도록 설정한다.

JPA 실습

엔티티 클래스 정의

@Entity
@Getter
@NoArgsConstructor
@AllArgsConstructor
public class Gyumin {
    @Id
    @Column(name = "Mccc_id")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String roomId;
    private String fileName;
    private String code;

    // 생성자
    public Gyumin(String roomId, String fileName, String code) {
        this.roomId = roomId;
        this.fileName = fileName;
        this.code = code;
    }
}

위 클래스는 Gyumin 이라는 엔티티로 데이터베이스 테이블의 컬럼과 매핑된다. 각 필드는 id, roomId, fileName, code와 같이 정의되었고 @Id로 기본 키가 지정되었다.

Repository 인터페이스

JPA에서 데이터를 조회할 때 Repository 패턴을 사용한다. SnapshotRespository 인터페이스는 MongoDB와 JPA를 함께 사용하여 데이터를 다루는 방법을 보여준다.

public interface SnapshotRepository extends MongoRepository<Snapshot, String> {
    Snapshot findByRoomId(String roomId);
    List<Snapshot> findSnapshotsByRoomId(String roomId);
    Snapshot findByRoomIdAndFileName(String roomId, String fileName);
}

위 코드는 SnapshotRepository를 통홰 roomId로 데이터를 조회하는 쿼리를 작성하는 방법을 보여준다. findByRoomId는 roomId 값으로 데이터를 조회하는 기능을 수행하며 findSnapshotsByRoomId는 동일한 roomId로 여러 개의 Snapshot 리스트를 반환한다.

JPQL을 사용한 쿼리 작성

JPA에서는 @Query 어노테이션을 사용하여 JPQL 쿼리를 정의할 수 있다.

public interface ManageRepository extends JpaRepository<Manage, Long> {

    @Query("select m from Manage m " +
           "where m.team.id = :teamId " +
           "order by m.createDate")
    List<Manage> findManagesByTeamId(@Param("teamId") Long teamId);
}

위 코드에서는 @Query 어노테이션을 통해 직접 JPQL 쿼리를 작성하였고, teamId 파라미터를 사용하여 team.id에 해당하는 데이터를 조회한다. @Param 어노테이션을 사용하여 쿼리 매개변수를 바인딩한다.

벌크성 쿼리 (Builk Queries)

벌크성 쿼리는 다수의 데이터를 한번에 처리하는데 사용된다. 대용량 데이터를 업데이트하거나 삭제할 때 성능 최적화에 유리하다.

벌크 업데이트 예시

@Modifying
@Query("UPDATE Member m SET m.age = m.age + 1 WHERE m.age >= :age")
int bulkUpdateAge(@Param("age") int age);

위 쿼리는 age 값이 일정 수준 이상인 회원들의 나이를 일괄적으로 1씩 증가시키는 벌크 업데이트 쿼리이다. @Modifying 어노테이션을 사용하여 업데이트 쿼리를 처리할 수 있다.

지금은 멋쟁이사자처럼 대학 12th HACKATHON을 경험하고 온 후여서 그때 스터디할때는 이게 어떻게 쓰이지? 뭐지? 라는 생각이 해커톤을 경험한 후, 아 이렇게 쓰이는구나 이런식이구나 라는걸 많이 깨달았다. 역시 나는 몸으로 직접 부딪치면서 깨달아야한다는것을 알았다. 참 많은 도움이 된 해커톤이여서 빠른 시일 내에 회고를 해야겠다는 생각이 들었다.

백엔드 스터디 (2)

용어

연관관계 (Association)

엔티티 간의 관계를 의미하며, 데이터베이스의 테이블 간 외래 키 관계에 해당한다.

매핑 (Mapping)

객체 모델과 데이터베이스 모델 간의 관계를 정의하는 작업. JPA에서는 엔티티와 테이블을 매핑하고, 연관관계 매핑에서는 엔티티 간의 관계를 정의한다.

단방향 연관관계 (Unidirectional Association)

한 쪽 엔티티만 다른 엔티티를 참조하는 관계

양방향 연관관계 (Bidirectional Association)

두 엔티티가 서로를 참조하는 관계

일대일 (One-to-One)

한 엔티티가 하나의 다른 엔티티와 연관된 관계

일대다 (One-to-Many)

한 엔티티가 여러 엔티티와 연관된 관계

다대일 (Many-to-One)

여러 엔티티가 한 엔티티와 연관된 관계

다대다 (Many-to-Many)

여러 엔티티가 여러 엔티티와 연관된 관계

주인 엔티티 (Owner Entity)

연관관계에서 외래키를 소유하고 있는 엔티티

주인 아닌 엔티티 (Non-Owner Entity)

외래키를 소유하고 있지 않은 엔티티

연관관계의 필요성

객체 모델에서는 실제 비즈니스 로직을 구현하기 위해 엔티티간의 관계를 명확히 정의해야 한다. 데이터베이스의 테이블 간 외래키와 같은 관계를 객체 지향적으로 다루기 위해 연관관계가 필요하다.

매핑의 목적

객체 지향 코드와 관계형 데이터베이스의 구조를 일치시켜 데이터의 일관성을 유지하기 위함이다. 이를 통해 객체 모델을 통해 자연스럽게 데이터베이스 상호작용을 구현할 수 있다.

객체 연관관계는 간접적이고, 테이블 연관관계는 외래 키로 명확히 표현되며, JPA 매핑을 통해 이를 일관되게 연결할 수 있다.

연관관계 매핑의 종류

일대일(One-to-One) 관계

객체 연관관계

Member 객체와 Locker 객체가 1:1로 매핑되어 있다. 즉, Member는 하나의 Locker를 가질 수 있고, Locker도 하나의 Member에만 연결된다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 LOCKER_ID를 외래 키로 가지며, 이 키를 통해 LOCKER 테이블과 1:1 관계를 맺는다. LOCKER_ID 필드는 외래 키(FK)이면서 유니크(UNIQUE) 제약조건이 설정되어 있어, 각 Locker는 하나의 Member와만 연관될 수 있다.

일대일 관계는 두 엔티티가 서로 1:1로 매핑되는 관계로, 하나의 객체가 다른 하나의 객체에만 연관되는 구조이다. 데이터베이스에서는 외래 키와 유니크 제약조건을 사용해 이를 구현하며, 객체 모델에서는 필드 참조를 통해 연관관계를 표현한다.

다대일(Many-to-One) 관계

<단방향>

객체 연관관계

Member 객체와 Team 객체가 다대일 관계를 가진다. 즉, 여러 Member 객체가 하나의 Team 객체와 연관될 수 있다. Member 클래스는 Team team 필드를 통해 Team 객체를 참조한다. 이는 여러 Member가 동일한 Team 객체에 속할 수 있음을 나타낸다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID를 외래 키(FK)로 가지며, 이를 통해 TEAM 테이블과의 관계를 정의한다. TEAM_ID 필드는 MEMBER 테이블에 속하며, 이는 여러 MEMBER가 동일한 TEAM에 연결될 수 있도록 한다.

다대일 관계는 여러 엔티티가 하나의 엔티티와 연관되는 관계로, 객체 모델에서는 Member가 Team을 참조하는 방식으로 표현된다. 데이터베이스에서는 외래 키를 통해 이 관계를 구현하며, 여러 Member가 같은 Team에 속할 수 있다. 이 구조는 팀과 소속된 멤버들 간의 관계를 효율적으로 관리할 수 있게 해준다.

<양방향>

객체 연관관계

Member와 Team 객체가 서로 양방향으로 참조하고 있다. Member 객체는 Team team 필드를 통해 Team 객체를 참조하며, Team 객체는 List< Member > members 필드를 통해 여러 Member 객체들을 참조한다. 즉, 여러 Member가 하나의 Team에 속하고, Team은 자신에게 속한 모든 Member들을 참조할 수 있다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID 외래 키(FK)를 통해 TEAM 테이블과 연관되어 있다. 사진에서 표시된 것처럼, Team 객체에 추가된 members 필드는 테이블 구조에는 영향을 주지 않으며, 이는 객체 모델 상에서만 관리된다.

이 관계에서 Member 엔티티가 연관관계의 주인이다. 왜냐하면, 외래 키(TEAM_ID)가 MEMBER 테이블에 존재하기 때문이다. 연관관계 주인은 데이터베이스에서 실제로 외래 키를 관리하고, 해당 키를 업데이트하는 역할을 한다.

이 구조는 Member와 Team 간의 관계를 양방향으로 설정하여, Member가 Team을 참조할 뿐만 아니라 Team도 자신에게 속한 Member들을 참조할 수 있도록 한다. 이러한 양방향 관계는 데이터베이스 상에서 외래 키를 관리하는 주인 엔티티(Member)와 비주인 엔티티(Team)로 구분되어 구현된다.

일대다(One-to-Many) 관계

<단방향>

코드 구성을 보면 Team 클래스가 @OneToMany 어노테이션을 사용하여 Member들과 일대다 관계를 형성하고 있다. @JoinColumn(name = "TEAM_ID") 어노테이션은 members 리스트가 TEAM_ID 외래 키를 통해 Member들과 연관된다는 것을 나타낸다. List< Member > members 필드를 통해 Team 객체는 여러 Member 객체를 관리할 수 있다.

객체 연관관계

Team 객체는 여러 Member 객체와 연결되며, 이 관계는 단방향이다. 즉, Team은 Member들을 참조하지만, Member는 Team을 참조하지 않는다. 관계가 단방향이기 때문에 Member 객체에서는 Team에 대한 정보가 없다.

테이블 연관관계

데이터베이스에서 TEAM_ID는 MEMBER 테이블에 외래 키로 존재한다. 따라서 Member가 어떤 Team에 속해 있는지는 MEMBER 테이블의 TEAM_ID 컬럼을 통해 관리된다.

• 주의사항 <외래 키 관리> @JoinColumn을 통해 지정된 외래 키는 반드시 MEMBER 테이블에 존재해야 하며, 이를 통해 Team과 Member 간의 연관관계가 설정된다. team.getMembers().add(member) 메서드를 호출하지 않으면, Member의 TEAM_ID 필드가 null로 저장되어 관계가 설정되지 않는다.

  <Update 쿼리 발생> Team 객체에 Member 객체를 추가할 때마다 외래 키(TEAM_ID)를 업데이트하기 위한 쿼리가 발생합니다. 이로 인해 성능에 영향을 줄 수 있으므로, 이를 주의하여 관리해야 한다.

  <실수로 양방향 연관관계로 변환될 가능성> 만약 Member 객체가 Team 객체를 참조해야 하는 상황이 발생한다면, 단방향에서 양방향 연관관계로 변경해야 할 수 있다. 하지만 이 경우 Member 클래스에 Team 필드를 추가하고 @ManyToOne 어노테이션을 붙여야 한다.

  이 구조는 Team 객체가 여러 Member 객체와 일대다 단방향 관계를 가지도록 설정한다. 데이터베이스 상에서 외래 키는 MEMBER 테이블에 존재하며, 이 관계는 객체 모델에서 단방향으로 관리된다. 이 방식은 단순하지만, 외래 키 관리 및 업데이트 쿼리에 주의해야 하며, 필요에 따라 양방향 관계로 확장할 수 있다.

<양방향>

코드구성을 보면 Member 클래스는 Team 클래스와 다대일(Many-to-One)로 연결되어 있으며, @ManyToOne 어노테이션을 통해 이를 설정한다. @JoinColumn(name = "TEAM_ID") 어노테이션은 Member 테이블에서 외래 키로 TEAM_ID를 사용함을 나타낸다. insertable = false, updatable = false 설정은 이 필드를 읽기 전용으로 만들어, 데이터베이스에 값을 삽입하거나 수정할 수 없도록 제한한다. 이는 해당 관계가 양방향이지만, 데이터의 일관성을 유지하기 위해 한쪽에서만 외래 키를 관리하게 하려는 목적이다.

객체 연관관계

Team과 Member 간의 관계는 양방향이다. Team 클래스는 List< Member > 필드를 통해 여러 Member 객체들을 참조하고, Member 클래스는 Team 객체를 참조한다. 즉, Member가 어느 Team에 속하는지를 알 수 있으며, Team도 자신에게 속한 Member들을 알 수 있다.

테이블 연관관계

데이터베이스에서는 MEMBER 테이블이 TEAM_ID 외래 키를 통해 TEAM 테이블과 연결되어 있다. 이 외래 키는 Member 엔티티에 의해 관리되지만, 해당 필드는 읽기 전용으로 설정되어있다.

일대다 양방향 연관관계는 Team이 여러 Member를 참조하고, Member도 Team을 참조하는 구조를 가진다. 이 관계에서 Member 쪽에서 외래 키를 관리하지만, 읽기 전용으로 설정하여 데이터의 일관성을 유지하고, 특정 상황에서 관계를 안전하게 처리할 수 있도록 한다. 이를 통해 양방향 관계를 구현하되, 외래 키 관리를 한쪽에서만 책임지는 방식으로 설정할 수 있다.

다대다(Many-to-Many) 관계

객체 연관관계

객체 모델에서는 Member와 Product 간의 다대다 관계를 List< Product >와 List< Member >를 사용하여 구현한다. 이를 통해 Member는 여러 Product를, Product는 여러 Member를 참조할 수 있다. @ManyToMany 어노테이션을 사용하고, @JoinTable 어노테이션을 통해 중간 테이블(MEMBER_PRODUCT)을 설정하여 다대다 관계를 구현한다.

테이블 연관관계

데이터베이스에서는 다대다 관계를 직접적으로 표현할 수 없기 때문에, 중간 테이블(연결 테이블)을 사용한다. 이 중간 테이블은 두 엔티티의 외래 키로 구성되며, 각각의 외래 키는 양쪽 엔티티와 일대다[1:N]관계를 맺는다. 예시에서는 Member_Product라는 중간 테이블을 통해 MEMBER와 PRODUCT 간의 다대다 관계를 구현하고 있다.

• 주의사항 <실무에서의 사용> 실무에서는 다대다 관계를 직접 사용하는 것보다, 중간 테이블을 만들어 다대일 관계로 풀어내는 방식이 더 일반적이다. 이는 관리와 확장성을 높이고, 추가적인 컬럼을 필요로 할 때 유리하다. <성능 이슈> 다대다 관계를 직접 사용할 경우, 조인 쿼리가 복잡해지거나 성능 이슈가 발생할 수 있으므로, 필요에 따라 중간 테이블을 명시적으로 관리하는 것이 좋다.

다대다 관계는 두 엔티티 간의 다대다 연결을 설정하는 구조로, 이를 위해 중간 테이블을 사용하여 관계를 관리한다. 객체 모델에서는 @ManyToMany 어노테이션을 사용하며, 실무에서는 이를 다대일 관계로 풀어내어 관리하는 것이 일반적이다.

요약

연관관계 매핑은 객체 지향 설계에서 엔티티 간의 관계를 명확하게 표현하고, 이를 데이터베이스의 관계형 모델과 일치시켜 데이터의 일관성과 무결성을 유지하는 데 필수적이다. 올바른 연관관계 매핑을 통해 코드의 가독성과 유지보수성을 높일 수 있으며, 복잡한 비즈니스 로직을 효율적으로 구현할 수 있다.

특히, 적절한 매핑 설계는 성능 최적화에 큰 영향을 미친다. 잘못된 매핑은 불필요한 쿼리 발생이나 N+1 문제를 초래할 수 있지만, 올바른 매핑은 쿼리의 효율성을 극대화하고 데이터베이스와의 상호작용을 최소화할 수 있다. 따라서 연관관계 매핑은 시스템의 성능과 유지보수성을 고려하여 신중하게 설계해야 한다. 이를 통해 안정적이고 확장 가능한 시스템을 구축할 수 있다.

여튼 그래서 3월달부터 시작된 백엔드 스터디에 대해서 기록, 복습을 위해 velog에 기록하려고 한다. 내 미래, 꿈, 직업같은 것들은 velog에 기록하고, 취미인 클라이밍등등은 instagram, 일상은 blog에 저장하자는 목표가 있다. 추억하고 경험은 기록으로 남기는게 좋을 것 같다고 생각을 했다.

백엔드 스터디 (1)

용어

API

API (Application Programing Interface)는 다른 소프트웨어 시스템과 통신하기 위해 따라야 하는 규칙을 정의하는 것을 말한다.

한마디로 어떠한 응용프로그램에서 데이터를 주고 받기 위한 방법을 의미하는 것 같다.

인터페이스

인터페이스는 어떤 기계간의 장치끼리 정보를 교환하기 위한 수단이나 방법을 의미한다. 일종의 매개체로 스마트폰과 사람간의 어떠한 신호를 주고 받는 매개체가 되는 소프트웨어인것같다. UI(USER INTERFACE) 우리가 눈으로 보는 화면을 UI라 한다.

JPA

JPA (Java Persistence API)는 자바 애플리케이션에서 관계형 데이터베이스를 사용하는 표준방법을 제공하는 API이다. JPA는 객체-관계 매핑(ORM) 기술을 사용해서 자바 객체를 데이터베이스 테이블에 매핑한다.

JDBC

JDBC (Java Database Connectivity)는 자바 애플리케이션이 데이터베이스에 연결하고 SQL 쿼리를 실행하여 데이터를 검색하고 조작할 수 있게 하는 저수준 API 라고한다. JDBC는 데이터베이스에 저장된 데이터를 자바 애플리케이션에서 사용할 수 있게 한다.

ORM

ORM (Objcect-Relational Mapping)는 객체 지향 프로그래밍 언어의 객체를 관계형 데이터베이스의 테이블에 매핑하는 기술이다. 데이터베이스의 데이터를 자바 객체로 매핑하고, 자바 객체를 데이터베이스의 데이터로 매핑하여 프로그래밍 패러다임의 불일치를 해결한다.

JPA의 사용이유

1. 패러다임의 불일치 해결

   • 객체 지향 프로그래밍 언어와 관계형 데이터베이스의 데이터 모델 간의 불일치를 해소한다.

2. 객체 중심적 개발

   • SQL 중심의 개발 방식에서 벗어나 객체 중심으로 개발할 수 있게 한다.

3. 생산성 향상

   • 반복적인 SQL 코드 작성에서 해방되어 비즈니스 로직에 집중할 수 있게 한다.

4. 성능 개선

   • 1차 캐시, 지연로딩, 쓰기 지연등의 최적화 기능을 통해 성능을 개선한다.

5. 유지보수 용이

   • 객체 지향 모델을 사용하여 코드의 가독성과 유지보수성을 높인다.

구동방식 (GPT예시)

1. 프로젝트 설정

build.gradle:

plugins {
    id 'org.springframework.boot' version '2.6.6'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    runtimeOnly 'org.mariadb.jdbc:mariadb-java-client'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}

test {
    useJUnitPlatform()
}

2. application.properties 설정

src/main/resources/application.properties 파일을 생성하고, MariaDB 데이터베이스 연결 정보를 설정한다.

application.properties:

spring.datasource.url=jdbc:mariadb://localhost:3306/your_database
spring.datasource.username=your_username
spring.datasource.password=your_password
spring.datasource.driver-class-name=org.mariadb.jdbc.Driver

spring.jpa.hibernate.ddl-auto=update
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MariaDBDialect

3. 엔티티 클래스 정의

데이터베이스 테이블에 매핑될 자바 클래스를 정의한다.

User.java:

package com.example.demo;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Entity
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private String email;

    // Getters and setters
    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}

4. 리포지토리 인터페이스 생성

JPA를 사용하여 CRUD 작업을 수행할 리포지토리를 정의한다.

UserRepository.java:

package com.example.demo;

import org.springframework.data.jpa.repository.JpaRepository;

public interface UserRepository extends JpaRepository<User, Long> {
}

5. 서비스 클래스 구현

비즈니스 로직을 처리하는 서비스 클래스를 구현한다.

UserService.java:

package com.example.demo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

import java.util.List;

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    public User saveUser(User user) {
        return userRepository.save(user);
    }

    public List<User> getAllUsers() {
        return userRepository.findAll();
    }

    public User getUserById(Long id) {
        return userRepository.findById(id).orElse(null);
    }

    public void deleteUser(Long id) {
        userRepository.deleteById(id);
    }
}

6. 컨트롤러 클래스 구현

HTTP 요청을 처리하는 컨트롤러 클래스를 구현한다.

UserController.java:

package com.example.demo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/users")
public class UserController {

    @Autowired
    private UserService userService;

    @PostMapping
    public ResponseEntity<User> createUser(@RequestBody User user) {
        User createdUser = userService.saveUser(user);
        return new ResponseEntity<>(createdUser, HttpStatus.CREATED);
    }

    @GetMapping
    public ResponseEntity<List<User>> getAllUsers() {
        List<User> users = userService.getAllUsers();
        return new ResponseEntity<>(users, HttpStatus.OK);
    }

    @GetMapping("/{id}")
    public ResponseEntity<User> getUserById(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return user != null ? new ResponseEntity<>(user, HttpStatus.OK) : new ResponseEntity<>(HttpStatus.NOT_FOUND);
    }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> deleteUser(@PathVariable Long id) {
        userService.deleteUser(id);
        return new ResponseEntity<>(HttpStatus.NO_CONTENT);
    }
}

7. 애플리케이션 실행

DemoApplication.java:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

이제 애플리케이션을 실행하면, Spring Boot 애플리케이션이 시작되고 MariaDB 데이터베이스에 연결됩니다. Postman 또는 다른 HTTP 클라이언트를 사용하여 CRUD 작업을 수행할 수 있다.

Postman을 사용한 예제

1. Create User (POST 요청)

   URL: http://localhost:8080/users Method: POST Body (raw, JSON)

   {
     "name": "John Doe",
     "email": "john.doe@example.com"
   }
   

2. Get All Users (GET 요청)

   URL: http://localhost:8080/users Method: GET Get User by ID (GET 요청)

   URL: http://localhost:8080/users/1 Method: GET Delete User (DELETE 요청)

   URL: http://localhost:8080/users/1 Method: DELETE

이와 같은 방법으로 Gradle과 MariaDB를 사용하여 Spring Boot 애플리케이션을 설정하고, JPA를 활용하여 간단한 CRUD 애플리케이션을 구현할 수 있다.

나중에는 스터디에서 한 프로젝트로 활용해보겠다.

준비된 포폴도 없고 실력도 없는 만큼 더 열심히 해야한다. 시작하기를 두려워 했지만 시간은 흐르고 이제 물도 엎질러졌다. 오늘부로 물은 흐르기 시작한다.

첫 게시글은 미래의 내가 볼 수 있고, 동기부여가 될 수 있게 자유 형식으로 쓰고싶다. 나의 최종목표는 사람좋은 기업들어가기... 꿈은 크게 가질수록 좋다고 했다.

목표를 크게 잡아 실패하는 것은 문제가 되지 않는다고 생각한다. 오히려 목표를 낮게 잡아 실패하는것이 문제라고 생각한다.

이번년 나의 목표

1. 마지막 나의 학창시절을 잘 즐기는것
2. 사회로 나가기전에 준비 단단히 하기
3. 포트폴리오 쌓고, 실력 쌓고, 추억 쌓기
4. 인간관계 힘들어하지 않기
5. 부모님께 잘하기

나중에 학교를 졸업하고 다시보면 새로운 느낌일거라 생각한다.

다들 엄청난 속도로 나의 앞에서 가고있지만, 조금은 의식을 하되, 나의 속도에 맞춰서 날 믿고 가자.

이 글을 기점으로 다시 일어나자 파이팅..!!

사진은 내가 좋아하는 망그러진 곰 행운부적