코딩짜는 일상

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 23차 - KDT 과정 수료 후기

Remily — Wed, 24 Dec 2025 23:49:08 +0900

서론

6월 30일부터 12월 19일까지,

무려 6개월에 걸친 현대이지웰 풀스택 개발자 아카데미가 드디어 끝났습니다!

Finally!!! 드디어!!!

이제 아침에 푹 잘 수 있다는 해방감도 있지만!

... 한편으론 매일 아침 얼굴 보고 인사하던 사람들과 헤어진다는 사실이

조금은 섭섭하고... 아쉽긴 하네요...ㅎㅎ

~~줌으로만 봐서 아닐 줄 알았는데 나름 정 들었었나봐요ㅠ~~

아침마다 조금은 쓸쓸해...

단순히 지인의 추천으로 시작하게 된 부트캠프였지만

완전히 끝난 지금은 진짜 잘 한 선택이라고 생각됩니다!

저는 비전공자로 개발을 시작한 탓에 개발 용어 자체에 익숙하지 않아

의존성, 컴포넌트, 상속, 추상화 같은 단어에 진입 장벽을 느끼고 성장이 멈춰 있었는데요.

지금은 자연스럽게 해당 단어를 사용할 정도로 익숙해졌습니다!

거기다 개인 프로젝트를 시작할 때 구성부터 막혀서 막막했던 것에서

이제는 스스로 기술스택을 선택하고 실제 구현까지 해볼 수 있는 수준으로 성장했습니다!

완벽주의라 시작이 어려우셨던 분들은 이게 얼마나 큰 성장인지 공감하실걸요? ‍↕️

아무튼 그만큼 좋았던 부트캠프였던 만큼 마지막 TIL은 후기로 마무리해보도록 하겠습니다!

좋았던 점

1️⃣ 커리큘럼

우선... 저는 제일 처음 국비 교육으로 개발자를 시작했었습니다.

거기선 php, 자바, 파이썬, C, 리눅스 등을 아주 짧게 배웠고 CRUD 정도만 구현해서 포트폴리오를 만들어 취직했습니다.

이후엔 회사에서 이름 모를 선배 개발자의 코드를 보고 조금씩 응용하며 기능을 구현했었기에

기존에 것을 응용하거나 개선하는 작업은 잘 해도 프로젝트 구조를 처음부터 스스로 시작하는 건 막연한 수준이였습니다.

하지만 이번에 들은 풀스택 개발자 아카데미는 웹 애플리케이션 구현이라는 목적을 갖고

기술이 어떻게 발전해왔는가를 짚어가며 수업이 진행되었기에 단순히 기술들간의 차이점 뿐만이 아니라

이 기술이 왜 필요한지, 왜 쓰는지를 알게 되어 이후 팀 프로젝트때 사용할 기술 스택을 확정지을 수 있었습니다.

새삼 모아놓고 보니까 어떻게 다 들었지 싶은 커리큘럼 ‍↕️

초보 개발자를 위한 성장이라는 주제로 진행되는 강의들을 보면, 주로

하나의 언어를 완벽하게 익혀라. 개발의 역사를 알아야 한다. 공식 문서를 읽어라.

같은 이야기를 자주 들을 수 있는데, 이번 풀스택 과정을 들으면서 이유를 깨달을 수 있었습니다!

~~뭔가 더 잘 와닿을 수 있도록 설명해드리고 싶은데 어렵네요...ㅎㅎ~~

2️⃣ 다양한 초청 강사

본 강사님도 좋았지만 특정 과목들은 초청 강사님을 초빙하여 수업을 진행했었습니다.

커리큘럼 중에 요 부분!

이게 특별히 좋았던 이유는 수업이 끝난 마지막 날엔 취업에 관련한 다양한 견해를 들어볼 수 있었기 때문입니다!

현재 실무 환경은 어떤지. 채용 시장 상황은 어떤지.

각 강사님들마다 배경도 다 다르고 견해도 다 달라서 다양하게 접해보고 그중 내 상황에 맞는 것만 취사 선택하기 좋았습니다.

3️⃣ 다양한 이벤트(?)

강좌를 주관하는 주최측이라고 해야 할까요...?

멀티캠퍼스에서 매달 한 번 정도는 채용 설명회를 진행하고 가끔 수업 외 취업특강도 열어주셔서 좋았습니다.

프로젝트에 AI를 어떻게 활용해야할지 알려주신 귀한 강의...!

저는 AI 관련 개발자 실무 트렌드 강연을 들었었는데

이것 덕분에 팀 프로젝트를 할 때 AI를 어떻게 활용해야할지 감을 잡을 수 있었습니다.

특히 TIL 첼린지가 매우! 매우! 좋았는데요!!

매주 배운 내용중에 특히 중요하다고 생각했거나 햇갈렸던 개념을 포스팅으로 한 번 더 정리하면서

복습도 확실히 되고 무엇보다 이력서에 보여줄 번듯한 기술 블로그를 만들 수 있어서 좋았습니다.

이건 필수 참여도 아니고 중간에 하차하시는 분들도 많아서 졸업까지 가시는 분도 적지만

끝까지 참여하고 나면 진짜 성취감 하나는 최고에요! 진짜 꼭 추천드립니다!!

이런것 말고도 간식 이벤트도 자주 열어주셔서 참여하는 재미가 쏠쏠했던 것 같습니다.

맛있는 간식~ 행복한 간식~

4️⃣ 취업 컨설팅과 현직자 멘토링

과정의 가장 큰 목적이 취업이다보니 취업에 관한 지원 서비스가 좋았습니다.

따로 취업 컨설턴트님이 계셔서 이력서와 자소서 서류 컨설팅을 해주셨고

팀 프로젝트를 시작하면서부턴 현직자 멘토링도 진행하게 되어 프로젝트 피드백을 받고

개인적으로 이력서나 포트폴리오를 피드백 받을 수 있어 좋았습니다.

과정 중간중간 이력서/자소서 과제도 제출하고 상담도 받고~

요거는 개인적인 상담이 많았어서 더 디테일하게 말씀드리기 어렵군요...

아무튼 좋았습니다

아쉬운 점

1️⃣ 빠듯한 일정

본 과정은 오전 9시부터 오후 6시까지, 하루 8시간동안 진행됩니다.

거기에 앞서 소개드린 취업특강에 취업 컨설팅에 이벤트까지 하면...

진짜 시간이 원망스러울 정도로 빠르게 지나갑니다.

저는 자바 배우기 시작하면서 특히 잠을 못 잤는데

진짜 단 하루라도 복습이 밀리면 수업을 따라가기 힘들어서 잠을 꾹꾹 참아가며 복습했었습니다..,

TIL 제출 일에는 새벽에 자는 일이 흔해서 여러번 중도 하차할까 고민도 했었고

팀 프로젝트를 할 때도 시간이 모잘라서 진짜 딱 일주일만 더 있었으면!!! 하고 얼마나 바랬는지 모릅니다...

~~잠죽자 싫어요... 하루 8시간 수면 안 하면 이해력이 뚝뚝 떨어진다구요...ㅠㅠ~~

진짜 TIL 챌린지는 복습이랑 디깅 학습 되는거 아니었으면 진즉 포기했을지도 몰라요.

2️⃣ 온라인 수업의 한계

전면 온라인 수업으로 진행되었는데 zoom 문제로 소리가 튀거나 끊길 때가 있어서 듣기 힘들었습니다.

자세히 들으려고 이어폰을 얼마나 키워두었는지 요즘은 귀가 좀 얼얼하더라구요...,,

그리고 오프라인이면 질문 생길 때 바로바로 손 들어서 질문할텐데

온라인은 강사님 말을 끊을 수도 없고 채팅에 쳐도 바로 못 보실때가 있어서 질문하기 불편했습니다.

대안으로 FT 보조강사님이 계셔서 주 강사님 설명하는 사이에 보조강사님께 질문해서 해결하기도 했고

매니저님이 강의 다시보기를 남겨주셔서 놓쳤거나 이해 안 되는 부분 복습할 수 있어서 큰 문제는 아니었습니다.

그래도 익숙해지기 전까지 시간이 좀 걸렸던 것 같아요...,,

결론

되돌아 볼 수록 진짜 어떻게 다 따라갔나 싶을 정도로 바쁘게 살았네요...ㅎㅎ

살면서 이렇게 열심히 공부해본 게 손에 꼽아서 오래도록 기억에 남을 것 같습니다.

~~아시는 분이 어디 대학원이라도 가려고 그렇게 열심히냐고 하셨던 기억이...하핳...~~

그래도 열심히 한 덕분인지 쑥쓰럽지만 우수수료생에도 뽑히고... 진짜 뜻 깊은 시간이었어요...!

시험때마다 함정 문제에 열심히 낚여서 기대 안 하고 있었는데 진짜 너무 기뻤습니다 ㅠㅠ

이름 뜨는거 보고 얼떨떨했는데 다 끝나고 나니까 울컥했어...

최근에 채용시장이 안좋다는 이야기가 많이 들려와서 아직은 불안하지만...

그래도 긴 시간 든든하게 배운만큼 잘 준비해서 이직에 성공해 보겠습니다!

같이 수업 들었던 친구들에게도 좋은 직장과 좋은 직장 동료들이 생기길 바라며!

다들 메리 크리스마스!! 좋은 일들만 가득하길 바랍니다!

메리크리스마스! 해피 뉴 이어!!

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 22차 - 리엑트 api BaseUrl 관리 전략

Remily — Tue, 16 Dec 2025 23:57:50 +0900

서론

저희 팀은 프로젝트를 프론트와 백엔드로 나누어

백엔드에선 DB와 통신하여 데이터를 가공하거나 api로 결과값을 전달하고

프론트에선 api의 데이터를 받아 클라이언트를 구성하도록 구조를 짰습니다.

하지만 로컬에서 개발할 땐 localhost:8080이 기본 도메인이 되는 한편

배포를 하면 해당 서버의 도메인으로 바뀌어야 합니다.

이걸 배포할 때마다 전부 찾아서 바꿔 넣는 건 매우 비효율적이죠...

배포할 때마다 무한 반복 작업...

그래서 이번 포스팅에선 api의 기본 도메인, base url을 어떻게 관리할 것인지

몇 가지 방법을 정리하여 소개하려고 합니다.

Config 파일로 분리해 관리

구조가 단순해서 초보자도 이해하기 좋은 방식입니다.

설정 관련 내용은 전부 config 파일에 모아두기 때문에

해당 파일만 읽어도 프로젝트의 중요 내용 대부분을 파악할 수 있다는 장점이 있습니다.

1️⃣ config.js 파일 생성

config.js파일 구성. 매우 간단하다!

일반적으로 src 폴더에 config 폴더를 추가해 config.js 파일을 만들어 사용합니다.

만약 설정 내용이 많다면 apiConfig.js, orderConfig.js 처럼

파일을 세분화 하여 사용해도 됩니다.

// src/config/apiConfig.js
const apiConfig = {
  baseURL: "https://api.example.com", // or "http://localhost:8080"
};

export default apiConfig;

이처럼 단순한 기본 객체 형태로 만들어 사용하는데

개발할 땐 로컬 주소로 두고 쓰다가 배포할 때 해당 파일만 수정하면 됩니다.

아니면 조건문을 추가해 환경에 따라 알아서 바꿔 쓸 수 있도록 할 수 있습니다.

// src/config/apiConfig.js
const apiConfig = {
  baseURL:
    process.env.NODE_ENV === "development"
      ? "http://localhost:8080"
      : "https://api.example.com",
};

export default apiConfig;

타 컴포넌트에서 사용할 땐 간편하게 config 파일을 import 하면 됩니다.

// src/components/OrderList.js
import { useEffect, useState } from "react";
import axios from "axios";
import apiConfig from "../config/apiConfig";

function OrderList() {
  const [orders, setOrders] = useState([]);

  useEffect(() => {
    axios
      .get(`${apiConfig.baseURL}/orders`)
      .then((res) => {
        setOrders(res.data);
      })
      .catch((err) => {
        console.error("API Error:", err);
      });
  }, []);

  return (
    <div>
      <h2>주문 목록</h2>
      {orders.map((order) => (
        <p key={order.id}>{order.name}</p>
      ))}
    </div>
  );
}

export default OrderList;

2️⃣ Redux 활용

하지만 저는 새로운 컴포넌트 마다 config 파일 위치를 일일이 찾아서 import 하는 방법이 번거로워서

Redux를 사용하는 김에 store를 통해 base url을 받아올 수 있도록 했습니다.

redux를 활용한 config. 처음보다 구성이 더 많아졌지만 세분화를 많이 해도 redux로 전부 간편하게 호출!

구조는 src/app에 store.js를 두고

src/features/config에 Slice.js를 만듭니다.

저는 관리자 페이지, 사용자 페이지의 url이 따로여서 2개를 만들었습니다.

// src/app/store.js
import { configureStore } from '@reduxjs/toolkit';

import userConfigReducer from 'features/config/userConfigSlice';

import admConfigReducer from 'features/config/admConfigSlice';

export const store = configureStore({
  reducer: {
    userConfig: userConfigReducer,

    admConfig: admConfigReducer,
  },
});

// src/features/config/admConfigSlice.js
import { createSlice } from '@reduxjs/toolkit';

const admConfigSlice = createSlice({
  name: 'admConfig',
  initialState: {
    apiBaseUrl: "http://localhost:8080",
  },
  reducers: {},
});

export default admConfigSlice.reducer;

사용할 땐 useSelector를 임포트 하고

store에 adminConfigSlice를 매핑 한대로 admConfig를 불러서

adminConfigSlice에 정의해둔 apiBaseUrl을 가져다 쓰면 됩니다.

세분화를 아무리 많이 해도 컴포넌트에서 가져다 쓸 땐

react-redux만 import 하면 되서 간편합니다!

// src/components/OrderList.js
import { useEffect, useState } from "react";
import axios from "axios";
import { useSelector } from 'react-redux';

function OrderList() {
  const [orders, setOrders] = useState([]);
  
  const apiBaseUrl = useSelector(state => state.admConfig.apiBaseUrl);

  useEffect(() => {
    axios
      .get(`${apiBaseUrl}/orders`)
      .then((res) => {
        setOrders(res.data);
      })
      .catch((err) => {
        console.error("API Error:", err);
      });
  }, []);

  return (
    <div>
      <h2>주문 목록</h2>
      {orders.map((order) => (
        <p key={order.id}>{order.name}</p>
      ))}
    </div>
  );
}

export default OrderList;

더 간단하죠?

환경 변수(.env)로 관리

다음으로 소개드릴 방법은 환경 변수를 저장해두는 .env 파일을 이용한 관리입니다.

리액트는 빌드 시점에 .env파일을 가장 먼저 읽고

모든 JS코드에서 process.env.REACT_APP_***로 된 부분을 찾아 문자열로 치환하기 때문에

로컬용, 배포용으로 .env를 만들고 api base url을 각각 다르게 저장해두면 됩니다.

참고로 해당 파일에 api key를 저장해 쓰기도 하므로

절대!! 깃에 올리지 않도록 조심해야 합니다!!!

주의! 또 주의!

1️⃣ .env 파일 생성

.env는 리엑트 프로젝트 루트 최상단에!

.env는 리엑트 프로젝트의 최상단에 만들어야 합니다.

참고로 파일 이름에 따라 환경별로 나눠서 쓸 수 있는데요.

.env는 공통으로 사용되는 환경 변수고

.env.development는 npm start 명령어로 개발용 번들을 빌드할 때만 사용되는 환경 변수고

.env.production은 npm run build 명령어로 배포용 번들을 빌드할 때만 사용되는 환경 변수입니다.

파일을 만들었다면 안에서 환경 변수를 정의해줘야 하는데요.

반드시 REACT_APP_으로 시작해야 하고

=기호 양 옆에 띄워쓰기가 있으면 안됩니다.

위 규칙을 지키지 않으면 무시되거나 잘못 인식될 수 있으니 주의하세요!

# .env.development 파일 예시
REACT_APP_API_BASE_URL=http://localhost:4000 # 개발 도메인

# .env.production 파일 예시
REACT_APP_API_BASE_URL=https://api.example.com # 배포 도메인

2️⃣ 컴포넌트에서 사용

사용은 더 간단해졌습니다.

import도 필요 없이 바로 process.env.변수명으로 접근하면 됩니다.

// src/components/OrderList.js
import { useEffect, useState } from "react";
import axios from "axios";

function OrderList() {
  const [orders, setOrders] = useState([]);
  
  useEffect(() => {
    axios
      .get(`${process.env.REACT_APP_API_BASE_URL}/orders`)
      .then((res) => {
        setOrders(res.data);
      })
      .catch((err) => {
        console.error("API Error:", err);
      });
  }, []);

  return (
    <div>
      <h2>주문 목록</h2>
      {orders.map((order) => (
        <p key={order.id}>{order.name}</p>
      ))}
    </div>
  );
}

export default OrderList;

응용: axios 인스턴스 만들기

지금까지 배운 방법대로면 가장 간편한 방법은 .env를 이용하는 방법입니다.

하지만 baseUrl을 가져오고, axios를 이용해서 api에 데이터를 요청하고

받은 데이터를 처리하는 과정까지 통틀어 생각해보면 어떨까요?

거기다 토큰을 추가하거나 공통 헤더를 추가해서 요청을 보내야 하거나

에러 코드에 따라 공통적으로 처리해야 할 작업이 있다면 axios 구문이 더욱 더 길어질 것입니다.

이러한 반복되는 api 관련 설정을 하나의 파일에 모아두고 사용하면 어떨까요?

api 인스턴스 구조. 처음에 설명한 config.js와 비슷하다.

구조는 처음에 설명했던 config.js 파일을 만들어 쓰는 방법과 유사하며,

인스턴스 파일을 api에 모아두고 쓸 컴포넌트에서 import 해서 쓰면 됩니다.

저는 사용자 api와 관리자 api의 base url이 다르기 때문에 2개를 만들었습니다.

1️⃣ axios 인스턴스 파일 구성

파일의 구성은 base url과 요청 시간 제한이 있는 기본 설정부

요청이 서버로 나가기 전 추가할 작업이 있는 요청 인터셉터

응답을 받은 후 에러 처리나 공통 작업이 있는 응답 인터셉터

이렇게 3개로 나눌 수 있습니다.

코드 형식은 아래 코드를 참고하시면 됩니다.

// src/api/userApi.js
// * 기본 설정부 *
import axios from "axios";

const api = axios.create({
  baseURL: process.env.REACT_APP_USER_API_BASE_URL,
  timeout: 5000, // 요청 제한시간
});

// * 요청 인터셉터 *
api.interceptors.request.use(
  (config) => {
    const token = "토큰";
    
    // 헤더에 토큰 추가
    if (token) config.headers.Authorization = `Bearer ${token}`;
    // 헤더에 요청 데이터 타입 설정
    config.headers.Content-Type = "application/json";
    
    return config;
  },
  (error) => Promise.reject(error)
);

// * 응답 인터셉터 *
api.interceptors.response.use(
  (response) => response,
  (error) => {
  	// http 상태코드에 따라 응답 회신
    if (error.response?.status === 401) {
      console.log("로그인이 필요합니다.");
    }
     if (error.response?.status === 403) {
      console.log("권한이 필요합니다.");
    }
    
    return Promise.reject(error);
  }
);

export default api;

2️⃣ 컴포넌트 사용

앞서 인스턴스에서 axios를 import 해서 객체를 만들고 설정들을 미리 등록해두었기에

사용할 때는 해당 인스턴스를 변수에 담아 import 해서 사용하면 됩니다.

// src/components/OrderList.js
import { useEffect, useState } from "react";
import api from "../api/userApi";

function OrderList() {
  const [orders, setOrders] = useState([]);
  
  useEffect(() => {
    api.get('/orders')
      .then((res) => {
        setOrders(res.data);
      })
      .catch((err) => {
        console.error("API Error:", err);
      });
  }, []);

  return (
    <div>
      <h2>주문 목록</h2>
      {orders.map((order) => (
        <p key={order.id}>{order.name}</p>
      ))}
    </div>
  );
}

export default OrderList;

헤더 설정과 에러 처리 설정이 추가되었지만 코드는 더 짧아졌습니다.

더는 api base url을 신경 쓸 필요도 없이 남은 api 경로만 써주면 됩니다.

결론

일단은 현재 팀 프로젝트에서 쓰는 기준으로 글을 작성하다보니

proxy와 api 호출 라이브러리는 설명이 빠졌습니다.

할 게 너무 많기도 했어요...

원래는 config, .env, proxy를 다루려고 했는데

글을 쓰려고 공부를 더 하다 보니 axios 인스턴스를 알게 되서

이건 꼭 써야겠다!!!

하고 포스팅 하게 되었습니다...ㅎㅎ

이번 팀 프로젝트에 도입하기엔 늦었지만

개인 프로젝트를 하게 된다면 반드시 쓰게 될 것 같습니다.

이런 좋은 방법은 대체 어떻게들 떠올리는거람!

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 21차 - DTO 미사용으로 인한 API 필드명 스타일 불균일성 이슈

Remily — Tue, 9 Dec 2025 23:54:23 +0900

서론

이번주는... 제가 최근에 어마어마한 업보 청산을 당해서...

...그것에 대해 기록 해볼까 합니다.

이것 때문에 반나절 날린거만 생각하면... 후...(속상)

시작은 2개 이상의 테이블을 JOIN하여 데이터를 가져올 때

2개 테이블들의 필드가 전부 있는 별도의 DTO를 만들어야 하는 번거로움에서 시작되었습니다.

이때 강사님께 Map<String, Object>를 사용하여 데이터를 받는 방법도 있다고 조언 받았고

단일 테이블을 조회하는 게 아니면 대부분 Map을 이용하여 서비스를 구현하게 되었습니다.

프로젝트 초반에는 별 문제가 없었는데

중반 쯤 지나 구현할 리엑트 컴포넌트가 늘어나면서

작업을 좀 줄여보려고 컴포넌트를 분리하고 재사용하면서 문제가 생겼습니다.

1️⃣ 필드명 스타일 통일의 필요성

오라클은 큰따옴표(")를 쓰지 않는 한 대소문자 구분을 하지 않습니다.

때문에 테이블을 만들때도 테이블명, 필드명에 큰따옴표를 쓰지 않으면

모든 알파벳이 대문자로 통일됩니다.

이 상태에서 Map으로 데이터를 받게 되면 대문자인 테이블 필드명을 그대로 따라

서비스로 전달되는 데이터도 필드가 전부 대문자로 통일됩니다.

그런데 저는 가독성을 위해 DTO를 만들 땐 필드명을 카멜타입으로 작성했기에

리엑트에서 보면 어떤 건 only 대문자, 어떤 건 카멜타입으로 데이터가 들어오기에

컴포넌트가 많아질 수록 햇갈릴 수 밖에 없었습니다.

팀 프로젝트 페이지. 한 페이지에 각 컴포넌트마다 받는 필드명 스타일이 다름...

그래서 통일하기 위해 DTO의 모든 필드명을 대문자로 바꾸면서 새로운 문제가 발생합니다.

2️⃣ 필드명 스타일 섞임

필드명을 전부 대문자로 통일한 DTO

필드명 스타일이 섞인 API 데이터

DTO의 모든 필드명 스타일을 대문자로 통일했지만

결과는 위 사진처럼 필드명이 전부 소문자 스타일로 나오고

날짜만 대문자 스타일로 한 번 더 출력됩니다.

DTO를 보면 ODREGDATE에만 @JsonFormat 어노테이션이 붙어있는데

날짜 포맷을 처리하는 과정에서 DTO에 명시된 필드명 스타일을 인지하고

대문자로 한 번 더 출력한 것이 아닌가 싶습니다.

자, 그럼 다른 필드는 왜 전부 소문자로 스타일이 통일된 것일까요?

원인 : Lomboc과 Jackson의 환장의 콜라보

1️⃣ 롬복의 Getter/Setter 네이밍 규칙

롬복(Lomboc)은 주로 DTO, VO, Entity 같은 클래스에서 Getter/Setter 또는 생성자 또는 toString 같은

반복적인 코드를 자동으로 생성해주는 자바 라이브러리 입니다.

저는 주로 Getter와 Setter를 만드는 데 사용했는데 필드명이 전부 대문자 스타일이면

Getter는 getODREGDATE(), Setter는 setODREGDATE()가 됩니다.

2️⃣ JavaBeans 규칙

잭슨(Jackson)은 자바 객체를 JSON문자열로 전환해주는 라이브러리 입니다.

JavaBeans 규칙을 적용해서 자동으로 프로퍼티명을 만들고 api 응답에 회신하기 위해

결과 객체를 JSON으로 자동 변환해줍니다.

JavaBeans규칙을 차근차근 살펴보면 우선 get/set/is 같은 접두사를 제거한 뒤

첫 글자를 소문자로 변경해 주는데, "앞의 두 글자가 모두 대문자면 그대로 둔다"는 규칙이 있어서

getODREGDATE() 를 통해 자동으로 생성되는 프로퍼티명은 계획대로 ODREGDATE이 됩니다.

그런데 여기서 로우 카멜 케이스(LowerCamelCase)를 기본으로 하는 Jackson의 자체 규칙이 추가로 적용되고

ODREGDATE가 결과적으로 odregdate가 되면서 API의 모든 필드명은 소문자 스타일로 통일됩니다.

해결책들

여러가지 해결책이 있습니다.

전부 AI들이 추천해준 방식이죠...

먼저 Jackson의 네이밍 규칙을 어퍼 카멜 케이스(UpperCamelCase)로 변경하는 방법입니다.

하지만 이 방법은 모든 API에 통합 적용되는 것이며

팀 프로젝트 중반인 지금와서 변경하면 모든 API를 다시 검수해야 하므로 부적절합니다.

그 다음으로는 @JsonProperty 어노테이션을 붙여서 명시적으로 JSON 필드명을 지정하는 것입니다.

하지만 어노테이션을 따라 만든 대문자JSON 필드명 하나, Jackson이 자동으로 만든 소문자JSON 필드명 하나,

이렇게 총 2개가 각 필드마다 생겨나므로 주고 받는 데이터 패킷이 2배가 되어 부적절 합니다.

다음은 DTO를 소문자 스타일로 바꾸고 Map<String, Object>으로 받는 데이터도 소문자 스타일로 변경하는 것인데요.

이 방법은 resultMap에서 오라클 필드명과 매핑해줄 소문자 스타일의 필드명을 정의해주거나

약어(AS) 문법으로 각 필드마다 소문자 스타일의 필드명을 정의해주면 됩니다.

SELECT PRDNAME prdname, PRDPRICE prdprice, PRDSTOCK prdstock, ...
FROM PRODUCT

하지만 모든 필드명을 일일이 언급해주면 필드를 찾는 연산에서 쿼리 실행 시간이 증가할 수 있고

차라리 DTO를 만드는 편이 가독성이 더 좋을 것이므로 Map을 쓰는 의미가 없어집니다.

아니 왜 이런 방법만 알려주는데!! 전부 안되잖아!!!

최종 해결책 : DTO를 카멜 스타일로 통일하고 Map 방식을 배제

그리하여 최종 선택한 해결책은 다시 처음으로 돌아와

Map<String, Object>로 받는 방식을 전부 DTO로 변경하고

DTO의 필드명 스타일을 카멜 스타일로 통일하는 방식을 채택했습니다.

~~일과가 끝날 쯤 되어서야 카멜 스타일로 만든 DTO는 카멜 스타일 그대로 받았다는 걸 떠올린 덕분이었어요...~~

소문자나 대문자로 통일하면 필드명 가독성이 떨어지니까 카멜 스타일로 통일했고

Map을 쓰는 의미가 없어졌으니 DTO로 데이터를 받도록 변경한 것입니다.

돌고 돌아 겨우 찾은 해답...

결론

위 에피소드를 겪으면서... 차라리 처음부터 DTO를 쓸껄 하고 얼마나 후회 했는지 모릅니다.

그냥 얌전히 DTO를 썼으면 @JsonFormat을 이용해 편하게 날짜형식을 바꿀 수 있었을텐데

괜히 Map으로 받아온다고 for문으로 KST포맷터를 만들어 일일이 적용하는 방식도 추가했었거든요.

// KST 포맷터
private static final DateTimeFormatter KST_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
.withZone(ZoneId.of("Asia/Seoul"));
// 날짜 필드 목록 (필요 시 추가 가능)
private static final List<String> DATE_FIELDS = Arrays.asList(
    "ODREGDATE"
    , "USERREGDATE"
);

// 불러온 데이터에 for로 포매터 사용...
List<Map<String, Object>> resultList = dao.메소드(params);
for (Map<String, Object> row : resultList) {
    for (String field : DATE_FIELDS) {
        Object value = row.get(field);
        if (value instanceof Timestamp ts) {
            row.put(field, KST_FORMATTER.format(ts.toInstant()));
        }
    }
}

~~어짜피 롬복 쓸 거... getter/setter 만드는 귀찮음도 없는데 진짜 왜 그랬지...~~

저는 DTO가 필요한 이유를 단순히 계층간에 데이터 전달을 위해서라고만 생각했는데

주고 받는 필드에 무엇이 있는지 바로 확인할 수 있어 테이블을 외우고 있지 않은 사람도 api를 쓰기 쉬워졌고

2개의 DTO를 필드로 갖고 있는 별도의 DTO를 만들어줌으로써

모든 필드명을 언급하지 않아도 다른 DTO의 모든 필드를 사용할 수 있는 등

사용하는 방법이 생각보다 유연해서 답답하지 않았습니다.

역시 대선배님들이 만들어 쓰시는 이유가 다 있다!!

프로젝트 하면서 별의 별 에피소드를 다 겪는 것 같은데

내일은 또 무슨 에피소드가 기다리고 있을지 기다...려...지네요...

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 20차 - 프로젝트에서 MyBatis 사용하기2 (feat.Oracle)

Remily — Mon, 1 Dec 2025 00:29:16 +0900

서론

지난주에 이어 프로젝트에서 MyBatis로 기능을 구현할 때 php와의 차이점을 정리해 보겠습니다.

php는 디테일하게 언급 안 할거라 써보신 분들을 독자로 가정하고 쓴 글이라고 보시면 될 것 같습니다.

주인공은 어디까지나 MyBatis와 오라클이니까요!

mybatis의 새 아이콘 귀엽더라구요...ㅎ

INSERT 직후 기본키(Primary key) 가져오기

현재 저희 프로젝트의 상품 데이터에는 일반적인 상품 데이터 외에도

그 상품에 포함되는 성분에 대한 데이터도 저장되고 있습니다.

성분 데이터는 저희 프로젝트의 핵심이라

상품 데이터 외에도 여러 테이블과 JOIN되어야 하기 때문에

별도의 매핑 테이블을 만들어 JOIN할 때 참조로 사용하고 있습니다.

그래서 새로운 상품을 등록하려면,

먼저 상품을 등록한 후에 기본키(Primary key)를 가져와서

성분 데이터와 매핑해주는 과정을 거치는 것이 일반적입니다.

상품 등록 과정 1차 흐름표

하지만 이 방법은 상품 등록에 2번의 과정을 거쳐야하므로 매우 번거롭습니다.

그래서 주로 등록과 동시에 기본키를 가져와서

매핑까지 한 번에 등록하는 식으로 작업을 진행합니다.

상품 등록 과정 2차 흐름표

php + MySQL 조합에선 INSERT 쿼리를 실행한 직후 mysql_insert_id(); 함수를 사용하여

자동 증가한 기본키 값을 받아오는 방식을 사용했었는데요.

보안 이슈가 있어서 PHP7 이상에선 제거되었고

7 이상부턴 PDO의 $pdo->lastInsertId()를 쓴다고 합니다.

그럼 스프링 부트 + MyBatis + 오라클 조합에선 어떻게 가져올까요?

1️⃣ <selectKey> 태그 활용 - 시퀀스 사용

오라클에는 MySQL의 AUTO_INCREMENT가 없고

대신 숫자를 자동으로 만들어주는 시퀀스(sequence)를 만들어서 그 값을 받아와 사용합니다.

Oracle 12c 부터는 GENERATED 구문을 추가해서

테이블 생성시 시퀀스도 자동으로 생성할 수 있는데요.

기본키가 될 필드명과 자료형 옆에

GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY

를 추가하면 새로운 래코드를 생성할 때 자동으로 기본키가 추가되고 필요하면 직접 지정도 가능합니다.

BY DEFAULT를 ALWAYS로 바꾸면 자동 생성되는 값만 허용되고 직접 입력은 안 됩니다.

다시 selectKey로 돌아와서...

<selectKey>는 <insert>태그 실행 전에 특정 값을 조회해

파라미터 객체에 자동으로 세팅해줄 때 사용하는 기능입니다.

우리는 이것을 시퀀스의 .CURRVAL를 사용해서 insert 후의 기본키를 가져오는데 쓸건데

만약 직접 시퀀스를 만들어 썼다면 시퀀스 이름을 직접 지정했을테니 찾기 쉬울 겁니다.

하지만 위와 같은 방법으로 자동 생성되는 시퀀스를 썼다면 이름이 ISEQ$$_숫자로 되어있어서

어느 테이블의 시퀀스인지 쉽게 찾기 어렵습니다.

이 경우 아래 쿼리를 사용하면 원하는 테이블의 기본키 시퀀스를 확인할 수 있습니다.

SELECT table_name, column_name, generation_type, sequence_name
FROM  user_tab_identity_cols
WHERE table_name = '테이블명';

시퀀스 확인!

시퀀스를 확인했다면 <insert> 태그 안에 아래와 같이 <selectKey> 태그를 추가해 줍니다.

<selectKey keyProperty="{반환할 변수명}" resultType="int" order="AFTER">
	SELECT {시퀀스명}.CURRVAL FROM dual
</selectKey>

해석하자면 시퀀스의 현재값(.CURRVAL)을 반환할 변수명에 int형으로 담으라는 것인데

order="AFTER"이기 때문에 insert를 진행한 후에 실행되어 직전에 생성된 레코드의 기본키를 반환할 것입니다.

order="BEFORE" 옵션을 쓰고 시퀀스의 다음값(.NEXTVAL)을 쓸 수도 있는데

이때는 값 반환과 동시에 시퀀스값도 오르기 때문에

반드시 이때 받은 다음값을 insert할 때 기본키로 삽입해주어야 합니다.

안 그러면 NEXTVAL때 한 번 오르고 기본키를 자동으로 생성받을 때 또 한 번 오름으로써

총 2번씩 기본키가 오르므로 주의해야 합니다! ~~(유경험자)~~

2️⃣ <selectKey> 태그 활용 - 일반 select문 사용

만약 시퀀스를 사용하지 않는다면 어떻게 해야 할까요?

간단합니다!

insert 실행 전에 조회한 특정값을 파라미터 객체에 세팅해주는 기능답게

해당 테이블의 최고 기본값을 알아낸 뒤 거기에 1을 더해주면 되겠죠!

<insert id="dao명칭" parameterType="map" useGeneratedKeys="false">
  <selectKey keyProperty="기본키 필드명" resultType="int" order="BEFORE">
    SELECT NVL(MAX(기본키 필드명), 0) + 1 AS 기본키 필드명
    FROM 테이블명
  </selectKey>
  INSERT INTO 테이블명 (
  	기본키 필드명, ...
  )
  VALUES (
    #{기본키 필드명}, ...
  )
</insert>

시퀀스를 사용하지 않으니까 기왕 받아온 다음 기본키 값을

기본키 필드에 파라미터로 넣어주시는 것도 잊으시면 안됩니다!

3️⃣ oracle의 RETURNING INTO 구문 활용

Oracle의 RETURNING INTO 구문은 INSERT, UPDATE, DELETE문을 실행할 때

영향을 받은 레코드의 특정 필드값을 바로 변수로 담아주는 기능입니다.

아래와 같이 쿼리를 작성하면 insert할 때 영향을 받은 레코드(생성된 행)의 기본키를 반환받겠죠.

<insert id="dao명칭" parameterType="파라미터 타입">
    INSERT INTO 테이블명 (기본키 필드명, ...)
    VALUES (시퀀스명.NEXTVAL, ...)
    RETURNING 기본키 필드명 INTO #{기본키 필드명}
</insert>

단, JDBC 드라이버와 MyBatis 버전에 따라 RETURNING INTO 구문 지원여부가 달라

충분히 테스트를 해보고 써야 합니다.

저는 프로젝트가 아직 호스팅 되기 전이라 환경이 바뀔수도 있다고 해서

일단은 selectKey를 사용했습니다.

시퀀스 기반이라면 selectKey가 가장 안정적이지만,

RETURNING INTO는 오라클의 고유기능이라 성능상 유리할 때가 있어서

둘을 잘 비교해보고 선택해서 써야 겠습니다.

GROUP BY 규칙

오라클은 MySQL보다 규칙을 꼼꼼하게 따지는데

대표적으로 group by를 수행할 때 select절에 나오는 모든 필드가

집계 함수(count, sum, ...) 또는 group by절에 포함되어야 한다는 규칙이 있습니다.

아래와 같은 쿼리를 작성했다고 해보죠.

SELECT p.*, COUNT(*) cnt
FROM product p JOIN comments c ON c.no = p.no
GROUP BY p.no;

MySQL이라면 상품 테이블(product)의 각 행에 댓글 갯수만 추가해서 결과를 반환해줬을 겁니다.

하지만 오라클은 group by 규칙을 꼼꼼히 따지므로

no외의 모든 필드가 group by에 들어있지 않으면 오류로 판단합니다.

ORA-00979 에러 발생! select절에 있는 모든 필드를 group by절에 넣어주세요!

그래서 모든 필드를 group by절에 언급해주거나

SELECT p.*, COUNT(*) cnt
FROM product p JOIN comments c ON c.no = p.no
GROUP BY p.no, p.name, p.price, ...;

좀 더 간결하게 p.*을 쓰지 않고 필요한 필드만 언급해주거나

SELECT p.no, p.name, COUNT(*) cnt
FROM product p JOIN comments c ON c.no = p.no
GROUP BY p.no, p.name;

서브쿼리를 활용해 집계 결과만 따로 뽑아낼 수 있습니다.

SELECT p.*, c.cnt
FROM product p
JOIN (
    SELECT no, COUNT(*) AS cnt
    FROM comments
    GROUP BY no
) c ON p.no = c.no;

사실 따지고보면 오라클의 방식이 맞을 수 있습니다.

저야 습관이 되어서 기본키를 기준으로 group by절을 사용하지만

쿼리에 익숙하지 않은 사람이 고유값인 기본키가 아닌 다른 필드를 기준으로 group by절을 사용한다면

MySQL의 경우 묶는 행들의 가장 첫번째 행만 기준으로 남기므로

의도한 데이터가 아닐 확률이 생깁니다.

이름으로 묶으면 3번 행이 소멸;;

NULL의 정렬

오라클에서 또 한 번 기함했던 것이 NULL값의 정렬입니다.

사실 이런 정렬 문제 때문에 문자열에는 빈값( '' )을 기본으로 두고 숫자는 0을 기본으로 두지만

오라클에서는 문자열이 빈값( '' )일 때 자동으로 NULL처리 하므로 완전히 배제하기가 힘듭니다.

그런 와중에 오라클에선 NULL을 가장 큰 값으로 취급하므로

내림차순 정렬 시 null이 가장 상위에 위치하게 됩니다.

내림차순에 null이 최상위 정렬...!

이것이 싫다면 NULLS LAST 를 추가해

ORDER BY 필드명 DESC NULLS LAST

으로 사용해주면 null값을 가장 아래로 보낼 수 있습니다.

FIRST로 바꿔서 반대로 가장 최상위로 보낼 수도 있습니다.

결론

오라클은 쓰면 쓸 수록 쿼리 규칙에 매우 까다롭다는 생각이 듭니다.

물론 그만큼 조회가 빠른 점은 장점이라고 할 수 있겠지만

지금 저희 프로젝트 처럼 작은 서비스를 만들 때는 가끔 힘겹게 느껴지네요...

난 슬플 때 음악을 들어...

하지만 저희 팀은 대규모 서비스를 운영하는 회사를 목표로 하고 있으니까.

이 경험이 나중에 도움이 될거라고 생각하면 아주 조금 재밌게 봐줄수도 있을 것 같아요!

틀린그림 찾기 같기도 하고...ㅎㅎ

차이점이 생각보다 많아서 나중엔 하나의 포스팅으로 정리 해봐야겠네요! ✨

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 19차 - 프로젝트에서 MyBatis 사용하기 (feat.Oracle)

Remily — Tue, 25 Nov 2025 23:25:40 +0900

서론

과거 PHP를 쓸 때는 sql_query() 함수를 사용해 DB 통신을 구현했었습니다.

쿼리를 문자열로 작성해 param으로 제공하면 되는 간단한 방식이기에

if문을 이용한 문자열 편집으로 간단하게 쿼리를 조립할 수 있었지만...

사실 이건 인젝션 공격에 취약하기 때문에 그리 현명한 선택은 아니었습니다.

물론 자체적으로 입력값에 UNION을 차단하는 기능을 추가해 방어했지만 여전히 위험요소가 있었죠...

PDO를 왜 안 쓰셨는지는 모르겠지만...?

현재 팀 프로젝트에선 MyBatis를 채택해 DB 통신을 구현하고 있습니다.

SQL을 직접 작성할 수 있어서 복잡한 쿼리 작성이 번거롭지 않고

쿼리는 모두 XML에 모아두기 때문에 유지보수나 협업에도 용이하고

무엇보다 값 바인딩 #{} 을 통해 입력값을 쿼리에 삽입하기 때문에 SQL 인젝션을 방지할 수 있습니다.

물론 sql_query()를 이용해 직접 쿼리를 작성할 때에 비하면

동적 SQL태그를 이용해 쿼리를 조립해야 하는 정도의 차이는 있습니다.

이번 포스팅에선 이런 MyBatis를 이용해 실제 기능을 구현할 때

어떤 식으로 쿼리를 작성하고 데이터를 다루는지에 대해 정리해 보겠습니다.

ORDER BY절 동적으로 안전하게 쓰기

순서를 따지자면 WHERE절 추가에 대해서 먼저 이야기 해야 할 것 같지만

값 바인딩 이야기가 나온 김에 ORDER BY절에 대해 먼저 이야기 해보겠습니다.

예시로 가져온 네이버 가격비교의 제품목록 정렬

흔히 쇼핑몰이던 게시판이던 사용자가 원하는 순서로 목록을 볼 수 있도록

정렬 방식을 선택하는 기능을 제공하곤 합니다.

이 경우 선택된 조건에 따라 ORDER BY절이 동적으로 바뀌어야 하는데

service에서 ORDER BY절을 만들어 mapper로 넘기면

값이 바인딩 되면서 SQL문법이 아닌 문자열로 인식되어 오류가 발생합니다.

ORA-00933 에러 발생

위 에러 메시지는 제가 service에서 order_sql이라는 파라미터를 만들고

ORDER BY 상품번호 DESC 라는 문자를 담아서 넘긴 뒤 쿼리 맨 마지막에 바인딩해줘서 생긴 에러입니다.

제 의도는 서비스에서 작성한 ORDER BY절이 본래의 기능대로 쓰이는 것이었지만

제가 넘긴 order_sql 파라미터는 문자열로 인식되어 최종적으로 아래와 같은 쿼리가 실행된 것입니다.

SELECT *
FROM 상품테이블
WHERE 조건
'ORDER BY 상품번호 DESC'

MyBatis에서 동적으로 쿼리를 작성하려면 동적 SQL 태그를 활용해야 합니다.

ORDER BY절은 맞는 조건에 따라 하나만 추가되어야 하고

조건이 안 맞아도 기본적으로 적용되어야 하는 정렬순서(=기본값defult)가 있으므로

switch문과 유사한 <choose>, <when>, <otherwise>를 쓰는 것이 가장 적합합니다.

사용 예시는 다음과 같습니다.

SELECT *
FROM 상품테이블
WHERE 조건
<choose>
  <when test="type == 상품명순">ORDER BY 상품명 ASC</when>
  <when test="type == 낮은가격순">ORDER BY 가격 ASC</when>
  <otherwise>ORDER BY 상품번호 DESC</otherwise>
</choose>

위 방식대로 쿼리를 작성하면

상품명순으로 정렬을 선택했을 때 상품의 이름을 기준으로 정렬하고

낮은가격순으로 정렬을 선택했을 때 상품의 가격이 낮은 순으로 정렬하고

그 외엔 최근 상품이 먼저 보일 수 있도록 쿼리를 동적으로 작성할 수 있습니다.

조건에 따라 WHERE절 추가

쇼핑몰 검색 기능을 보면 검색어 외에도 다양한 조건을 추가해서

원하는 제품을 빠르게 찾을 수 있는 검색 기능이 존재합니다.

예시로 가져온 네이버 가격비교의 상세검색

이번에는 조건이 맞을때만 WHERE절에 해당 조건이 추가되어야 하므로

if문과 유사한 <if>를 쓰는 것이 가장 적합합니다.

최대한 간단하게 제품의 색상, 가격 정도만 추가해서 예시를 보여드리겠습니다.

SELECT *
FROM 상품테이블
WHERE 1 = 1
  <if test="색상값 != null">AND 색상 = #{색상값}</if>
  <if test="가격값 != null">AND 가격 &lt;= #{가격값}</if>
ORDER BY 상품번호 DESC

WHERE절에 1=1을 추가하는 이유는 검색 조건이 아무것도 없을 경우를 대비한 것입니다.

아무것도 없이 WHERE만 있으면 문법 오류가 발생하지만 항상 참인 1=1이 있으면

검색 조건이 없을 때 문법 오류를 방지하면서 동시에 조건에 따라 추가되는 문법에 영향을 주지 않습니다.

특이한 점이 하나 더 있는데 XML이나 HTML 같은 마크업 문서는

< 기호를 태그의 시작으로 인식하기 때문에 <= 같은 등기호를 곧장 사용할 순 없습니다.

이때는 엔티티로 변환해서 < 가 문자 그대로 출력될 수 있도록

< 로 바꿔서 쿼리를 작성해줘야 합니다.

~~이걸 몰라서 어디에 문법을 틀렸는지 한참 찾았어요...~~

이것 외에도 컬렉션(List, Array)을 반복해 쿼리를 추가해주는 <foreach>가 있고

UPDATE문에서 갱신할 컬럼을 동적으로 추가할 때 사용하는 <set>도 있습니다.

날짜 포맷 추가

이번건 오라클 세션 타임존과 자바(저희 프로젝트는 스프링 부트) 서버의 타임존을 맞추면 발생하지 않는 문제지만

팀 프로젝트를 하게되면 모든 작업자의 로컬PC 타임존을 일일이 손보기 번거로워서 추가한 날짜 포맷 추가입니다.

이 문제를 간단히 설명하자면 오라클 세션 타임존은 Asia/Seoul으로 설정된 반면

자바 서버 타임존은 UTC기준 ISO 8601포맷으로 설정되어 발생했습니다.

문제가 발생한 날짜값. 원본값은 2025-11-05 00:00:00.

해결 방법은 서버와 DB의 타임존을 일치시키거나

API 응답 반환 전에 DateTimeFormatter로 직접 변환해 주거나

// KST 포맷터
private static final DateTimeFormatter KST_FORMATTER = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")
        .withZone(ZoneId.of("Asia/Seoul"));
// 날짜 필드 목록 (필요 시 추가 가능)
private static final List<String> DATE_FIELDS = Arrays.asList(
        "regdate"
);

public List<Map<String, Object>> listProduct(param){
	List<Map<String, Object>> resultList = dao.listProduct(param);
    
    for (Map<String, Object> row : resultList) {
        for (String field : DATE_FIELDS) {
            Object value = row.get(field);
            if (value instanceof Timestamp ts) {
                row.put(field, KST_FORMATTER.format(ts.toInstant()));
            }
        }
    }

	return resultList;
}

DTO를 만들어 날짜 필드에 @JsonFormat 어노테이션으로 포멧을 지정해주면 됩니다.

public class ProductDTO {
  @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "Asia/Seoul")
  private Date regdate;
}

팀 프로젝트에선 개발환경 설정 시간을 최소화 하고자

DateTimeFormatter와 @JaonFormat을 이용하였습니다.

결론

처음으로 다뤄보는 기술스택이라 그런지 생각보다 다양한 문제가 발생하는 것 같습니다.

비즈니스 로직만 문제인 줄 알았는데 이런 자잘한 문제가 계속 나오면

기간을 맞추기 위해 밤샘을 해야 할 수도 있겠네요...

내가 웃는게 웃는게 아니야~

음... 그치만 벌써 걱정해봐야 소용 없겠죠!?

최대한 밤샘을 안 할 수 있도록

모든 코드를 최대한 재사용 가능한 형태로 작성해서

빠르게 기능을 복제하는 방법을 써야겠습니다!

3년 경력이 뭔지 보여주겠어...!

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 18차 - MSA

Remily — Tue, 18 Nov 2025 23:58:30 +0900

서론

이번 주 포스팅은 MSA (MicroService Architecture)에 대해 써보겠습니다.

사실 특강은 몇 주 전에 했는데 그땐 내용 정리도 덜 됐고

무엇보다 오라클 비교글이 너무 잘 써진 바람에 어쩔 수 없었습니다...

~~덕분에 ERD를 몇 번을 갈아엎었는지...~~

그렇게 속 썩인 것 치곤 테이블 생성 이후엔 별다른 차이점은 없습니다.

테이블 생성에만 이렇게 차이가 나는 걸 보면...

어쩌면 데이터베이스의 핵심은 테이블 구조에 있는 걸지도 모르겠네요.

음? 그러니까 갑자기 DB구조가 궁금해지는데..? 나중에 찾아볼까?

MSA 탄생 배경

전통적인 웹 애플리케이션 구조는

프론트 엔드, 백엔드, 데이터베이스로 나뉘는 3계층 아키텍처입니다.

셋이서 일심동체!

예시로 홈페이지에 게시판을 하나 추가한다고 해보죠.

가장 먼저 DBA에서 게시판의 데이터를 담을 테이블을 생성할 것이고

백엔드에서 만들어진 테이블에 연결해 데이터를 가져오거나 추가, 생성, 삭제하는 API를 만들고

프론트 엔드는 API를 이용해 클라이언트가 조작할 수 있는 화면을 만들어줄 것입니다.

~~경우에 따라선 혼자 다 하는 경우도 있고요...~~

이 방식은 구조적으로는 깔끔했지만 서비스가 커질수록

팀원끼리 코드 충돌도 자주 일어나고

한 기능만 수정해도 전체를 다시 빌드해야 하거나

트래픽이 몰리면 전체 시스템을 확장해야 하고

장애가 발생하면 애플리케이션 전체가 멈춰버리는 일이 생기기도 했습니다.

단 하나만 잘못해도 애플리케이션 전체가 안 돌아가...

이러한 문제를 해결하고자

비즈니스 기준으로 서비스를 나눠 관리하자는 아이디어가 생겨났고

이것이 바로 마이크로 서비스 아키텍쳐(MSA)입니다.

Gateway

서비스를 나눠 관리하는 건 좋은데 그러자면 URL 경로가 달라지게 됩니다.

클라이언트가 알아서 이용하려는 서비스에 맞춰 찾아갈 수도 있겠지만 제법 번거롭겠죠?

그래서 등장한 방책이 게이트웨이(gateway)입니다.

게이트웨이는 클라이언트의 요청을 가장 먼저 마주하는 컴포넌트입니다.

클라이언트의 요청을 확인한 후 적절한 경로에 알아서 포워딩(=요청을 다른 곳으로 넘기는 것) 해줍니다.

가장 먼저 마주하는 컴포넌트이므로 인증, 로깅 같은 공통 기능을 처리하기도 합니다.

강사님이 스프링 부트 공식 문서를 통해 실습하는 방법을 알려주셨기에

공식 문서를 참고해 간단한 Gateway 예제를 실습해 보겠습니다.

1️⃣ Initializr를 이용해 Gateway 프로젝트 생성

스프링 부트 공식 문서 가이드에서 Building a Gateway를 검색하면 게이트웨이에 대한 가이드를 볼 수 있습니다.

https://spring.io/guides/gs/gateway

그중 Starting with Spring Initializr 항목을 확인하면 필요한 의존성을 선택해둔

Initializr로 이동할 수 있는 링크가 있습니다.

pre-initialized project 클릭!

필요 의존성이 추가된 initializr 페이지

필수적으로 필요한 의존성은 Reactive Gateway이며 Resilience4J와 Contract Stub Runner는

실습에 사용할 샘플(=서비스 단위로 별도의 포트로 분리된 프로젝트)을 대신할 의존성입니다.

저는 샘플로 쓸 프로젝트 2개를 만들어둔 상태이므로 Resilience4J와 Contract Stub Runner는 제외해주었습니다.

필요에 따라 Group, Artifact, Name, Package name 등을 수정해도 되고

저처럼 초기 상태 그대로 GENERATE를 해서 압축파일을 다운로드 해줘도 됩니다.

생성된 프로젝트 압축파일 다운로드

2️⃣ 게이트웨이 테스트 해보기

압축파일을 해제한 다음 IDE로 프로젝트를 열어줍니다. (저는 인텔리제이를 사용했습니다.)

Writing Test

공식문서를 살펴보면 Writing Test 항목이 있는데

여기에 적힌대로 Application.java 파일을 찾아 빈을 추가해줘야 합니다.

저는 프로젝트명을 gateway로 하였으니 GatewayApplication.java 파일을 찾으면 됩니다.

src/main/java/기본 패키지 경로로 들어가서 GatewayApplication.java 파일을 찾고

GatewayApplication 클래스 내부 가장 하단에 공식문서에서 추가하라는 빈을 복사해 붙여넣습니다.

추가해야하는 빈

빈에서 필요한 최소 요소는 route와 그 안의 path와 uri 입니다.

그 외에는 전부 삭제한 다음 매핑할 패스와 해당 패스로 들어왔을 때 포워딩할 경로를 적어줍니다.

경로 하나당 route 하나를 작성해야 하므로 분리한 서비스 수만큼 route를 작성해야 하고

마지막에는 .build()를 반드시 붙여줍니다.

완성한 빈

추가로 앞서 만든 서비스 프로젝트들과 포트를 분리하기 위해 게이트웨이 포트를 8888로 설정해주었습니다.

포트 설정

이제 완성한 게이트웨이 프로젝트를 실행하고

이어서 분리된 서비스 프로젝트들도 실행해주면

localhost:8888/posts/ 경로로 요청하면 자동으로 localhost:8081로 포워딩 되고

localhost:8888/comments/ 경로로 요청하면 자동으로 localhost:8082로 포워딩 됩니다!

MSA의 단점

1️⃣ 운영 복잡도 증가

게이트웨이를 이용해 자동으로 포워딩까지 해줬지만 문제는 이제부터 시작입니다.

서비스가 점점 더 많이 분리되면 그만큼 연결해야 하는 route가 늘어나고

보안을 위해 경로를 게이트웨이에 직접 언급하지 않도록 별도의 공간에 저장해야 할 필요성이 생깁니다.

이를 위해 Config Server를 추가하고

나중에는 클라이언트 분산을 위해 Eureka Server도 추가해줘야 할 것입니다.

MSA는 앞서 이야기 했던 전통적인 3계층 아키텍쳐의 문제점들을 해결해줄 수 있지만

파생되는 문제를 해결하고자 또 다른 해결책을 필요로 하게 되면서 점점 더 복잡한 구조를 가집니다.

복잡한 구조만큼 모니터링, 배포, 로깅 방식도 복잡해집니다.

2️⃣ 개발 난이도 상승

복잡한 구조만큼 개발 난이도도 상승하게 됩니다.

3️⃣ 데이터 일관성 문제

또한 서비스가 분리되어 DB에 접속하는 경로가 늘어난 만큼

데이터에 일관성을 유지하는 문제도 신경써야 합니다.

예를 들어 주문과 결제로 서비스가 나뉘었다고 가정해 보겠습니다.

주문을 접수하는 동시에 결제를 진행하게 된다면

접수된 주문 내역을 DB에 업데이트하면서 동시에 결제정보도 DB에 저장해야 할 것입니다.

나뉜 두 서비스가 동시에 DB를 업데이트 하려고 하면 누가 먼저 수정할지,

중간에 오류라도 생겨 둘 중 하나의 작업이 누락되면 어떻게 롤백할지 등등... 트랜잭션 처리가 꽤나 복잡해집니다.

4️⃣ 네트워크 비용 증가

뿐만 아니라 각각의 서비스가 별도의 프로젝트로 실행되므로

정보를 주고 받는데 발생하는 네트워크 비용도 함께 증가하게 됩니다.

결론

MSA는 분명 문제를 해결하고자 시작한 개념이었는데

거기서 파생되는 문제로 인해 또 다른 새로운 방책이 생겨나면서 점점 더 복잡해졌습니다.

이런 걸 보면 세상에 완벽한 아키텍처란 없는 것 같습니다.

하지만 상황에 가장 적합한 아키텍처는 찾을 수 있겠죠?

그걸 위해선 열심히 개발 근육(?)을 키워야겠지!

최선의 방법을 찾을 수 있도록

나중에는 MSA 뿐 아니라 다양한 아키택쳐를 접해봐야겠습니다.

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 17차 - 오라클과 MySQL의 차이

Remily — Tue, 11 Nov 2025 23:55:26 +0900

서론

이번 주는 제가 장기간 써오던 MySQL과

현재 참가중인 풀스택 개발자 과정에서 배운 오라클의 차이점을 알아보겠습니다.

사실 둘 다 SQL을 베이스로 하기 때문에 달라봐야 얼마나 다르겠냐 싶었는데

프로젝트를 시작하고 실제로 테이블을 만들어보니까 차이점이 확연히 와닿았습니다.

그리고... 오라클이 다소... 조금... 까다로운... 편인 것 같습니다...

어쩌면 많이...?

그래도 어렵고 까다로울수록 사람보단 기계(?) 친화적이라는 뜻이니까

잘만 쓸 수 있다면 사용자에게 더 좋은 서비스를 제공할 수 있을 겁니다!

실제로도 MySQL 보다는 오라클이 복잡한 계산이나 대량의 데이터 분석에 강하다고 합니다.

대량의 텍스트 정보에서 원하는 서치를 빠르게 해주는 CTXSYS.DRITHSX.SN 같은 기능도 제공하고 있습니다.

~~(비록 Error based Injection 공격에 주로 쓰이긴 하지만... 그래도 잘 쓰면 좋은 기능인데... )~~

아무튼 엄청 디테일하게 많은 걸 다뤄볼 건 아니고

프로젝트를 하면서 알게 된 만큼만 간단하게 다뤄보겠습니다.

별거 없지만 일단 시작해볼게요...ㅎㅎ

자료형

MySQL에선 그냥 편하게 썼던 자료형이

오라클에서 쓰려고 보면 없거나 많이 달랐던 경우가 종종 있었습니다.

덕분에 막 완성했던 ERD를 테이블 만드는 시점에 한 번 싹 갈아엎었습니다...

내 억장도 와르르...!

만약 이 포스팅을 보는 분이 계시다면 저와 같은 일은 겪지 않으셨으면 좋겠네요...

1️⃣ 숫자 자료형

먼저... 오라클에는 INT가 없습니다.

오라클에서 쓸 수 있는 숫자 자료형에는 NUMBER, BINARY_FLOAT, BINARY_DOUBLE이 있고

그중에서 INT와 가장 비슷하게 쓸 수 있는 게 NUMBER 입니다.

NUMBER는 정수와 실수를 모두 저장할 수 있으며

그냥 NUMBER를 쓰면 최대 38자리까지 정수/실수를 모두 허용하는 형태로 쓸 수 있습니다.

NUMBER(a)를 쓰면 최대 a자리 정수만 허용하도록 쓸 수 있고

NUMBER(a, b)를 쓰면 전체 a자리 중 b자리는 소수점 이하로 쓰도록 허용할 수 있습니다.

ex) NUMBER(7, 3) → 총 7자리 중 4자리는 정수 3자리는 소수점 이하

2️⃣ 문자 자료형

오라클에도 VARCHAR2가 있습니다.

심지어 메모리에 효율적이라며 오라클에서 사용을 권장하는 자료형입니다.

하지만 VARCHAR2(a)를 사용해도 a자리 숫자만큼 문자를 입력할 순 없습니다.

오라클에서 VARCHAR2(a)는 a bytes만큼 문자를 입력할 수 있다는 뜻입니다.

문자 수가 아니라 bytes가 단위입니다. ~~(선생님.. 제가 bytes를 어떻게 계산해서 문자를 입력할 수 있겠습니까...!)~~

물론 문자 수 기준으로 입력도 가능합니다.

유니코드에 기반한 NVARCHAR2(a)를 쓰거나

숫자 옆에 CHAR를 붙여서 VARCHAR2(a CHAR)를 쓰면 문자 수 만큼 입력하도록 제한할 수 있습니다.

장문의 게시글을 저장할 때 오라클에는 TEXT가 없어서 사용할 수 없습니다.

대신 LONG과 CLOB를 제공하는데 LONG은 구형이라 오라클에선 CLOB를 권장합니다.

CLOB는 대용량의 문자 데이터를 저장할 수 있으며 최대 4GB까지 저장할 수 있습니다.

6만5천자 정도 저장할 수 있었던 MySQL의 TEXT보다 너무나 큰 용량이라서 좀 놀라웠습니다.

~~(물론 MySQL에도 LONGTEXT가 있긴 한데 한 번도 쓰는 걸 못 봤어요...)~~

텍스트로 4GB를 채우려면 얼마나 써야하는거지;;;

3️⃣ 날짜 자료형

ERD를 싹 갈아엎고도 한 번 더 갈아엎게 만든 대망의 날짜 자료형입니다...

오라클의 TIMESTAMP는 MySQL의 TIMESTAMP와 의미가 완전히 다릅니다.(두둥 )

MySQL에서 TIMESTAMP는 날짜와 시간만 포함하지만

오라클의 TIMESTAMP는 날짜 + 시간 + 최대 9자리의 소수초를 포함합니다.

그냥 그대로 두고 쓸 때 소수초만 날려서 쓸까도 생각했지만

이 경우 MyBatis를 쓰면 mapper에 sql.Timestamp를 임포트 한 다음 날짜 필드의 자료형을 Timestamp 로 설정해주는 resultMap을 만들어서 쿼리 태그에 결과값 형식으로 지정해주라는 말을 듣고 바로 포기했습니다.

~~(그냥 ERD를 한 번 더 갈아엎는 게 시간이 절약될 것 같았습니다...)~~

MySQL은 날짜만 저장할 때 DATE를 사용하지만 오라클은 날짜만 저장하는 형식이 없습니다.

오라클의 DATE 는 날짜 + 시간을 포함하며 형식은 YYYY-MM-DD HH24:MI:SS 입니다.

추가로 오라클에는 NOW() 함수는 없지만

서버 기준과 세션 기준을 구분해서 사용할 수 있는 다른 함수들이 있습니다.

SYSDATE : 서버 시간 기준. 현재 날짜와 시간.
CURRENT_DATE : 세션 시간 기준. 현재 날짜와 시간.
SYSTIMESTAMP : 서버 시간 기준. 날짜 + 시간 + 소수초 + 타임존
CURRENT_TIMESTAMP : 세션 시간 기준. 날짜 + 시간 + 소수초

쿼리 문법

이번에는 MySQL과 오라클의 쿼리 문법 차이를 정리해보겠습니다.

1️⃣ 대소문자 구분

오라클에서는 큰 따옴표( " )안에 필드명을 넣으면 대소문자를 구분합니다.

테스트를 위해 만든 테이블 쿼리

만들어진 테스트 테이블의 필드들

반대로 말하자면 큰 따옴표( " ) 안에 필드명을 넣지 않으면 대소문자를 구분하지 않는데

오라클에서는 필드명을 자동으로 대문자로 인식해 처리합니다.

큰 따옴표를 쓰지 않아서 필드값을 못 찾는 모습...

쿼리를 작성할 때마다 큰 따옴표를 써주는 건 생각보다 번거롭습니다.

그래서 생각을 바꿔 테이블을 생성할 때 큰 따옴표를 제외하고 만들었습니다.

테스트를 위해 만든 테이블 쿼리2

큰 따옴표를 쓰지 않으면 대문자로 필드명이 변환된다

그러면 테이블 생성 쿼리에 필드명을 소문자로 써줬어도 자동으로 대문자 처리하기 때문에

조회 쿼리를 작성할 때 큰 따옴표 없이 자유롭게 조회할 수 있게 됩니다.

자동 대문자 처리되므로 필드명을 소문자로 쓰던 대문자로 쓰던 상관 없다!

2️⃣ 문자열 인식

오라클은 문자열을 작성할 때 작은 따옴표( ' )에 감싸줘야만 인식합니다.

큰 따옴표 사용

작은 따옴표 사용

테이블에 DEFULT 값을 설정해줄 때도 문자를 설정할 땐 작은 따옴표에 감싸줘야 합니다.

ex) DEFULT '기본값'

3️⃣ DEFULT 공백 처리

이건 확실히 MySQL보다 오라클이 더 좋은점이라고 할 수 있을 것 같습니다.

MySQL은 공백 ( "" )과 NULL을 다르게 보기 때문에

보통 NOT NULL과 DEFULT "" 를 함께 설정해주어 검색할 때 편의성을 높입니다.

ex) 이름이 없는 레코드를 찾을 때 : select * from 테이블 where 이름=""

하지만 오라클은 공백과 NULL을 동일하게 취급하기 때문에

문자열 필드에 공백을 입력해도 자동으로 NULL로 처리됩니다.

다시 말해서 입력값에 오류가 있는 레코드를 찾을 때 NULL만 고려해서 조회하면 된다는 것입니다!

이건 확실히 오라클이 낫다!

확실히 오류로 값이 누락된 채 저장되었다면 null이 더 직관적이니까

이건 오라클이 더 나은 부분이라 할 수 있겠습니다. ✨

4️⃣ AS

오라클에선 AS를 사용하지 않습니다.

그냥 공백을 두고 약어로 쓸 단어를 입력하는 식으로 약어 기능을 사용합니다.

AS를 인식 못 함.

한 칸 띄우는 식으로만 약어 사용 가능.

5️⃣ WHERE절 더미 조건

검색 기능을 구현하게 되면 검색 조건이 있을때만 where절에 동적으로 조건이 추가되기 때문에

쿼리 오류가 생기지 않도록 더미 조건을 쓰고 이후 추가되는 검색 조건을 AND를 사용해 붙입니다.

ex) select * from 테이블 where 더미조건 and 검색조건

그런데 MySQL에선 1만 입력해도 더미 조건으로 부합하는데

오라클에선 1=1까지 입력해야 더미 조건에 부합합니다...

더미 조건 1

더미 조건 1=1

사소하지만 이런것까지 다른점이 신기해서 작성해보았습니다.

결론

DUAL 테이블 이야기는 제외했는데도 막상 정리하고 보니 생각보다 차이점이 많은 것 같습니다.

분명 가볍게 쓰려고 했는데...?

좀 더 복잡한 쿼리를 작성하게 되면 또 새로운 차이점을 발견하겠죠...?

그럼 그때가서 업데이트 하는 것으로 하고 이번 글은 여기서 마무리 해보도록 하겠습니다.

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 16차 - 깃허브 그룹 프로젝트(이슈 생성, 커밋, 풀 리퀘스트)

Remily — Wed, 5 Nov 2025 00:40:20 +0900

서론

과거 제가 깃을 활용하던 방법은 브런치명을 추가하려는 기능명으로 만들어서

완성되면 main에 Merge 하는 식의 매우 단순한 운용이었습니다.

그러다 이번 팀 프로젝트를 진행하면서 좀 더 자세히 다루게 되었는데요.

저희팀은 GitFlow 전략을 일부 채택해서 main과 develop 브런치를 기본으로 두고

깃허브에서 이슈를 생성, 이슈번호를 토대로 브런치를 만들어 작업 내용을 Commit하기로 했습니다.

기능을 완성한 후에는 pull request를 생성해 develop과 Merge하고

문제가 없으면 다시 pull request를 생성해 main과 Merge하는 방식입니다.

우리 팀의 깃 전략!

그런데 여기서 또 문제가 생깁니다. (매일이 문제 해결의 연속... )

저는 깃허브에서 단순히 Repositories만 생성해봤지

이슈가 뭔지, 풀 리퀘스트가 뭔지, 전혀 몰랐던 겁니다.

그치만 어쩌겠어... 팀 프로젝트에 필요하면 어떻게든 해봐야지!

그래서 이번 포스팅에선 실제 작업을 예시로

어떻게 이슈를 작성하고 브런치를 만들고 풀 리퀘스트를 쓰는지 알아보겠습니다!

이슈와 브런치 만들기

팀 프로젝트 초기에는 사용자 화면 디자인과 DB설계가 완벽히 끝난 상태가 아니어서

우선 할 수 있는게 뭘까 생각하다가 관리자 페이지를 만들어보기로 했습니다.

간단하게 사이드바와 컨텐츠 영역을 분리하고

요구사항 정의서에 합의된 관리자 메뉴들을 카테고리로 집어 넣었습니다.

1️⃣ Projects 생성

팀원들에게 제가 관리자 페이지 작업을 시작하겠다고 알리긴 했지만

더 세부적으로 어떤 작업이 있고 그중 무엇을 진행중인지 알리기 위해 프로젝트를 만들기로 했습니다.

저희 팀 조직명은 BeautyRoutine!

깃허브에선 본인 아이디 외에 별도의 조직을 생성할 수 있습니다.

저희 팀은 BeautyRoutine이라는 조직을 만들어 공동 작업을 하기로 했는데요.

조직 메인 화면으로 들어와 상단의 탭을 보면 Projects 가 있습니다.

누른 후 프로젝트 목록에서 New Project 버튼을 찾아 눌러봅시다.

Project의 탬플릿을 정하는 화면

생성 화면으로 들어오면 여러가지 탬플릿을 보여주는데

일단은 가장 기본적인 Board를 선택 후 프로젝트 이름을 입력하고 Create 해줍니다.

포스트 작성 전에 테스트 겸 만든 프로젝트

저는 norangmoran's admin project라는 이름으로 프로젝트를 생성했습니다.

그 후 무슨 작업을 할 건지 Todo란의 Add item을 눌러 추가해줍니다.

내용 입력 후 Create a draft 또는 Ctrl + Enter를 눌러줍니다.

저는 할 일의 큰 기준을 메인화면 구성, 대분류 카테고리 명으로 잡았고

메인화면 구성은 테스트 겸 이미 완료했으니까 주문 관리 카테고리를 해보겠습니다.

Todo에 추가한 작업 중 시작할 작업을 In Progress로 드래그해 옮겨준 다음 클릭합니다.

할 일(영역)에 대한 세부 내용을 채우고 새로운 기능 추가를 이슈로 만들자!

클릭하면 좀 더 세부적인 분류를 추가할 수 있습니다.

Projects는 이미 프로젝트를 통해 만들었으므로 자동으로 추가되 있습니다.

Assignees는 담당자를 설정할 수 있는데, 클릭 후 제 아이디인 norangmoran을 설정했습니다.

Labels은 말 그대로 라벨입니다. 해당 영역의 시작점 이슈라는 뜻에서 good first issue를 선택했는데

팀원끼리 정해둔 규칙이 있다면 그것을 따르는 것이 좋습니다.

Type은 유형 분류인데 저는 작업영역을 만들었다는 뜻에서 Task를 선택했습니다.

2️⃣ 이슈 추가하기

분류를 수정했다면 이제 해당 작업 영역에 어떤 기능을 추가할 것인지

새로운 이슈를 추가해보도록 합시다.

먼저 방금 화면의 상단 오른쪽을 보시면 ... 표시가 있습니다.

이것을 눌러 Open in new tab을 눌러줍니다.

그러면 방금 만든 Task를 곧장 Issues 탭에서 열어볼 수 있고

여기서 다시 상단 오른쪽을 가셔서 New issue 버튼을 눌러 새로운 이슈를 추가합니다.

종류는 새로운 기능의 추가이므로 기능 제안(Feature Request)를 선택합니다.

팀장님이 이슈 탬플릿을 설정해주셔서 편하게 작성 가능하다!

팀의 탬플릿대로 내용을 작성해주고

담당자를 배정하고

새로운 기능의 추가이므로 라벨을 enhancement로 설정하고

타입도 기능 추가를 뜻하는 Feature로 설정하고

프로젝트를 선택해준 다음

Create 버튼을 눌러 이슈를 생성해줍니다.

3️⃣ 브런치 생성

브런치 생성 버튼

브랜치 이름 작성란

생성된 이슈의 상세내용으로 들어가서 오른쪽 목록을 보면 Development가 있습니다.

여기서 브런치를 생성할 수 있는데, 저희팀은 신규작업을 무조건 feature/에서 하기로 했고

develop 브런치에서 체크아웃하기로 했으므로 팀 규칙을 고려해 이름을 작성해줍니다.

여기서 브런치를 만들 수 있는 방법이 2가지가 있는데

하나는 Create brance 버튼을 누른 후 뜨는 깃 명령어를 복사한 후

프로젝트 폴더 내부로 가서 마우스 오른 클릭 => Open git bash here => 명령어 붙어넣고 실행

또는 깃 명령어를 무시한 후 본인이 쓰는 깃 관리 애플리케이션에서

develop에 체크아웃 => fetch => pull => 동일한 이름으로 브런치 생성 합니다.

저는 Soucetree를 쓰고 있어서 여기서 브런치를 만들었습니다.

이슈를 통해 브런치를 만들면 해당 이슈에서 커밋 내역을 자동으로 추척해준다!

이제 그렇게 만들어진 브런치를 통해 작업한 내용을 커밋하면

이슈에서 해당 브런치로 한 커밋을 전부 추적해 볼 수 있습니다.

풀 리퀘스트와 머지

작업이 전부 끝났다면 이것을 develop에 반영하기 위해 pull request를 작성합니다.

다른 팀원이 App.js에 사용자 화면의 라우터를 구성하면서

관리자 화면에도 사용자 화면에 있어야 할 헤더가 같이 뜨는 이슈가 있었는데요.

이건 빨리 반영되어야 관리자와 사용자 화면을 각각 나눠서 작업하기 편할 것 같아 PR을 올려봤습니다.

1️⃣ Pull request 작성하기

pull request는 내 작업량을 공용으로 사용하는 브런치(main 또는 develop)에 반영하고 싶으니

코드에 이상은 없는지 확인해주고 수정할 곳을 알려주거나 승인을 해달라는 요청을 올리는 작업입니다.

이슈를 만들었던 레포지토리의 상단 탭을 보면 Pull requests가 있습니다.

여기서 New pull request를 눌러 요청을 추가할 수 있고

이슈를 통해 생성한 브런치를 통해 커밋한 내용이 있다면 Compare & pull request를 통해 추가할 수도 있습니다.

PR 내용 작성중~

팀 규칙에 맞춰 내용을 작성하고

Reviewers에 리뷰해줬으면 하는 사람을 추가한 다음

Assignees에 이 작업을 담당한 사람을 선택해줍니다.

빠르게 응답해주는 팀원들

그러면 이런 식으로 팀원들이 코드를 확인했다는 표시를 달아줍니다.

2️⃣ 코드 리뷰 하기

오는 것이 있으면 주는 것도 있어야 하는 법!

팀원들이 코드 리뷰를 해줬으니까 우리도 어떻게 하는지 방법을 알아봅시다.

어짜피 코드 공개로 해놨는데 안 가려도 됐으려나...?

리뷰하려는 pull request로 들어가면 상단 탭에 Files changed가 있습니다.

여기서 수정된 내용을 한 페이지에 모아서 볼 수 있습니다.

수정된 내용을 확인하셨다면 바꿨으면 하는 내용을 적어 comment를 submit 할 수 있고

작업한 팀원에게 수고했다는 말과 함께 Approve를 submit 해서 승인할 수도 있습니다.

결론

혼자 마구잡이로 개발하던 것에 비하면 다소 번거로운 과정이 추가되었지만

issue를 생성해 개발을 시작하니 쉽게 원하는 작업의 버전을 찾을 수 있게 되었습니다.

물론 커밋 메시지를 확인할 수도 있지만 issue에 비해 많은 내용을 적을 수 없어 찾기 어렵습니다.

뿐만아니라 탬플릿을 따로 설정해둘 수 없으니 작성 내용도 제각각이라 검색도 어려웠죠...

분명 그 달에 했던 커밋인데 아무리 찾아도 원하는 버전을 찾을 수 없었던 그때의 막막함이 이랬달까...

기왕 배운거 앞으로도 쭉~ 유용하게 써먹어야 겠습니다!

아마 다음 포스팅에는 오라클과 MySQL의 차이를 쓰게 될 것 같아요.

DB 테이블 만들면서 어려움이 많았기 때문에 할 말이 또 많을 것 같습니다...

~~오라클 너무 까탈스러워...~~

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 15차 - 스프링 부트 프로젝트에 React 뷰 적용 방법

Remily — Wed, 29 Oct 2025 23:46:05 +0900

서론

스프링 부트로 프로젝트를 만들면 바로 실행할 수 있을만큼 대부분의 설정이 완료되어 있지만

뷰 파일 만큼은 특별히 강제하는 스타일이 없기 때문에 따로 설정해 주어야 합니다.

지금까지 강의를 배우면서 배운것이 JSP였기 때문에

이번 팀 프로젝트도 스프링 부트 프로젝트에 JSP의존성을 추가하였습니다.

근데 여기서 문제가 하나 생깁니다.

또... 무슨 문제가... 있나요...?

지난주 포스트였던 비동기 통신을 통해 데이터를 받아온 다음

직접 html태그를 작성하고 jQuery나 Javascript를 이용해 브라우저 화면에 삽입하도록 만들면

일단 만드는 작업이 너무 번거로운데다 내용이 조금만 더 길어지면 수정하는 일이 쉽지 않았습니다.

비동기 통신으로 가져온 검색결과를 7열짜리 테이블로 출력해주는 코드. 정리를 깔끔히 해도 알아보기 힘들다...

그래서 비동기 통신을 요청하면 데이터를 별도의 JSP 파일로 전달하고

거기서 html 태그를 구성한 다음 통째로 결과값으로 반환하는 방법을 써봤습니다.

확실히 코드를 유지보수하기 쉬워졌지만 결국 뷰를 서버가 만들기 때문에

요청한 데이터만 전달하여 주고 받는 패킷을 줄이고 속도를 높이자는 의도에선 벗어나게 되었습니다.

ajax로 반환할 별도의 뷰 파일. 그냥 여기로 클라이언트 데려와 그대로 출력하면 될 걸 서버 입장에선 왜 굳이 일을 두번으로 나눠서 시키나 싶을 듯...?

그리하여 서버는 데이터만 전달하고 뷰는 클라이언트에서 구성할 수 있도록

여러 태그를 통해 컴포넌트를 구성하고 이를 재사용해 화면을 구성해주는 리엑트를 프로젝트에 도입했습니다.

리엑트에 대해서는 수업 초창기에 배웠으니 이번 기회에 복습 해봐야 겠습니다.

수업 초기엔 리엑트를 왜 배우나 했지~

그래서 이번주 포스트엔 무얼 다룰 것인가!

바로 그렇게 만든 리엑트 코드를 어떻게 스프링 부트에 집어넣을 것인가! 입니다!

리엑트 빌드 파일 생성

리엑트 프로젝트를 스프링 부트에 연결하려면

빌드 파일을 생성한 다음 그것을 스프링 부트 폴더에 넣어주면 끝입니다.

매우 간단하죠?

아 물론 자세히 설명해드릴거에요. 여기서 끝이 아니라구요...!

빌드 파일을 만들려면 우선 해당 리엑트 프로젝트가 있는 경로에 접근해야 합니다.

저는 테스트를 위해 작업폴더에 spring-react-app 이라는 리엑트 프로젝트를 작성했습니다.

작업폴더는 C폴더 안의 Workspace\reactWorkspace 폴더 안에 있습니다.

터미널에서 cd.. 를 입력해 최상위 폴더로 이동한 다음 cd 이동할폴더명 을 입력해 리엑트 프로젝트로 이동합니다.

빌드할 리엑트 프로젝트로 이동

그 다음 npm run build 명령어를 입력해 빌드를 진행하시면 됩니다.

빌드가 완료되면 배포에 대한 자세한 내용은 아래 url에서 찾아보라는 말과 함께 커멘드 입력 커서가 돌아온다.

스프링 부트에 리엑트 빌드 파일 적용

npm run build 명령어로 생성된 빌드 파일의 경로는

파일 탐색기 > 작업폴더 > 리엑트 프로젝트 폴더 > build 폴더 안입니다.

제 경우는 C:\Workspace\reactWorkspace\spring-react-app 가 됩니다.

만들어진 빌드 파일

이제 이 파일들을 스프링 부트 프로젝트에 옮기면 되는데

static 폴더만 제외하고 남은 파일을 전부 드래그 한 다음

src > main > webapp > WEB-INF > views 폴더에 옮겨줍니다.

그 후 스프링 부트에서 사용하기로 한 뷰 파일의 스타일이 JSP이므로

확장자가 html인 파일들을 전부 jsp로 바꿔줍니다.

최종적으로 이런 형태~ index2.jsp는 무시하세용~

그 후 남은 static 폴더는 src/main/resources > static 폴더 안에 폴더째로 옮겨줍니다.

static에 static...

이것은 리엑트에서 리소스 사용 경로가 ./static/파일명 이기 때문인데

스프링 부트에서 리소스의 contextPath는 src/main/resources/static/이기 때문에

리엑트에서 ./static/image.jsp 라는 경로를 사용했다면

스프링 부트에선 최종적으로 src/main/resources/static/static/image.jsp 이 되기 때문입니다.

결론

이렇게 딱 2단계를 거치면 리엑트에서 만든 뷰 파일을

손쉽게 스프링 부트로 옮길 수 있습니다!

이제 프로젝트 구상도 거의 다 끝나서 내일부턴 본격적으로 구현에 들어가겠네요~

그나저나 이력서 빨리 제출해야하는데 큰일났다...!

[현대이지웰 Java 풀스택 개발자 아카데미 6월] TIL 14차 - 비동기 통신

Remily — Tue, 21 Oct 2025 23:55:52 +0900

서론

지금까지 자바와 스프링을 거쳐 스프링 부트까지 배워보았는데요.

자바라는 언어를 이용해 웹 애플리케이션을 간편하게 구현하고자

기술이 서서히 발전하는 과정을 간접 체험하게 되어 즐거운 여정이었습니다.

가득 찍힌 비자 도장들처럼 돌이켜보면 조금 뿌듯해지는 과정이었어요 출처:giphy

현재는 팀을 꾸려 프로젝트를 준비하고 있는데요.

본격적으로 기능을 구현하려고 보니까 사용자의 매끄러운 서비스 이용 경험을 위해

비동기 통신이 생각보다 자주 쓰이는 것이 보였습니다.

그래서 이번 주 부터는 프로젝트 만들면서 자주 쓰인 기능을 소개해볼까 해요!

자! 시작할 준비 되셨나요? 출처:giphy

비동기 통신이란❓

클라이언트가 화면 전환 없이 서버측에 데이터를 요청할 때 사용하는 기술입니다.

회원가입을 할 때 내가 입력한 아이디를 사용할 수 있는지 없는지 확인하려고

별도의 페이지로 이동했다가 다시 입력창으로 돌아오면 좀 번거롭겠죠...?

뿐만 아니라 화면을 보던 사이에 새로 추가된 상품을 보려고

브라우저 화면 전체를 새로 불러오게 되면(=새로고침)

그만큼 화면을 구성하는 시간도 더 오래 걸리고 서버와 주고 받는 데이터도 크겠죠...?

그래서 바뀐 데이터만 서버가 클라이언트에 전달하고

클라이언트는 받은 데이터를 이용해서 결과를 출력하거나 화면을 부분적으로 새로 구성해줍니다!

바뀐 데이터로 새롭게 화면을 구성! 출처:giphy

가장 많이 쓰이는 구현 방법으로는

1. ajax

2. fetch

3. axios

이렇게 3가지가 있습니다.

Ajax

가장 오래된 방식이며 그만큼 많이 사용되고 다양한 브라우저를 지원합니다.

자바스크립트의 XMLHttpRequest 객체를 이용한 방식은 매우 복잡하고 장황하기에

보통은 jquery 라이브러리를 사용해 보다 간결한 문법으로 기능을 구현합니다.

예시를 보여드리기 위해 아래와 같이 상품 등록 폼을 만들었습니다.

[중복확인] 버튼을 누르면 입력한 상품 번호를 DB에 조회한 후

사용가능한 번호인지 알려주는 예제입니다.

Ajax GET

jquery 라이브러리를 이용한 GET방식의 ajax 예제입니다.

url에 요청할 주소와 전달하려는 데이터를 담아 전달합니다.

$(document).ready(function() {
	$("#prdNoCheckBtn").on('click', function() {
		event.preventDefault(); // submit 중단
		
		let prdNo = $('#prdNo').val(); //상품 번호 입력값 추출
		
		if(prdNo == "") {
			alert("상품번호를 입력하세요");
			return false;
		} else {
			$.ajax({
				type: "GET",
				url: "/contextPath/product/prdNoCheck1/"+prdNo,
				dataType: "text",
				success: function(result) {
					if(result == "available")
						alert("사용가능한 번호입니다.");
					else
						alert("사용 불가능한 번호입니다.");
				},
				error: function(data, textStatus) {
					alert("전송실패");
				}
			});
		}
	}); //on종료
}); //ready종료

그럼 컨트롤러에서 URL에 담긴 상품 번호를 읽기 위해 PathVariable을 사용합니다.

// 상품번호 중복 확인 처리
// ajax get : url에 상품번호가 포함
@ResponseBody //문자열 그대로 반환하기 위한 어노테이션
@RequestMapping("/product/prdNoCheck1/{prdNo}")
public String prdNoCheck1(@PathVariable String prdNo) {
	String prdNo_result = service.prdNoCheck(prdNo);
	
	String result = "available";
	if(prdNo_result != null)
		result = "no_available";
	
	return result;
}

최종적으로 DB에서 이미 사용한 상품 번호를 입력해준 뒤 [중복확인] 버튼을 클릭하면

ajax의 성공 함수에 설정한 내용대로 사용 불가능한 번호입니다. 라는 알람창을 띄우게 됩니다!

Ajax POST

이번에는 요청 방식을 POST로 바꿔보겠습니다.

type에 요청 방식을 post로 변경하고

전달할 데이터는 data 항목을 추가해서 key:value 형태로 전달합니다.

$(document).ready(function() {
	$("#prdNoCheckBtn").on('click', function() {
		event.preventDefault();
		
		let prdNo = $('#prdNo').val();
		
		if(prdNo == "") {
			alert("상품번호를 입력하세요");
			return false;
		} else {
			$.ajax({
				type: "POST",
				url: "/contextPath/product/prdNoCheck2",
                data: {"prdNo" : prdNo}
				dataType: "text",
				success: function(result) {
					if(result == "available")
						alert("사용가능한 번호입니다.");
					else
						alert("사용 불가능한 번호입니다.");
				},
				error: function(data, textStatus) {
					alert("전송실패");
				}
			});
		}
	}); //on종료
}); //ready종료

컨트롤러에서 POST로 전달된 데이터를 받으려면 RequestParam을 사용합니다.

// 상품번호 중복 확인 처리
// ajax post : body에 상품번호가 포함
@ResponseBody
@RequestMapping("/product/prdNoCheck2")
public String prdNoCheck1(@RequestParam("prdNo") String prdNo) {
	String prdNo_result = service.prdNoCheck(prdNo);
	
	String result = "available";
	if(prdNo_result != null)
		result = "no_available";
	
	return result;
}

Fetch

fetch는 자바스크립트에서 ajax를 대체하고자 만들어진 api입니다.

자바스크립트 내장 api이기에 별도의 라이브러리를 추가할 필요가 없습니다.

또한 JSON파싱이 내장되어 있어 json파일을 주고받을 때 특히 유용합니다.

Fetch GET

fetch의 기본형은 fetch("요청 url").then(데이터변환).then(결과 처리).catch(에러 처리); 입니다.

$(document).ready(function() {
	$("#prdNoCheckBtn").on('click', function() {
		event.preventDefault();
		
		let prdNo = $('#prdNo').val();
		
		if(prdNo == "") {
			alert("상품번호를 입력하세요");
			return false;
		} else {
			// 자바스크립트 내장함수 fetch() get
			fetch("/contextPath/product/prdNoCheck2/"+prdNo)
			.then(
				response=>response.text() //응답 객체를 text로 변환
			)
			.then(result=>{
				if(result == "available")
					alert("사용가능한 번호입니다.");
				else
					alert("사용 불가능한 번호입니다.");
			})
			.catch(err=>console.log(err));
		}
	}); //on종료
}); //ready종료

받은 데이터를 컨트롤러에서 처리할 땐 ajax와 동일하게 PathVariable를 사용합니다.

Fetch POST

fetch에서 post로 데이터를 전달할 땐 조금 다른데요.

fetch() 안에 method와 headers를 추가하고 body에 데이터를 담아 전달합니다.

$(document).ready(function() {
	$("#prdNoCheckBtn").on('click', function() {
		event.preventDefault();
		
		let prdNo = $('#prdNo').val();
		
		if(prdNo == "") {
			alert("상품번호를 입력하세요");
			return false;
		} else {
			// 자바스크립트 내장함수 fetch() POST
			fetch("/mybatis/product/prdNoCheck3", {
				method: 'post', //전달방식
				headers: {'Context-Type':'application/json'},
				body : prdNo //전달할 데이터
			})
			.then(
				response=>response.text() //응답 객체를 text로 변환
			)
			.then(result=>{
				if(result == "available")
					alert("사용가능한 번호입니다.");
				else
					alert("사용 불가능한 번호입니다.");
			})
			.catch(err=>console.log(err));
		}
	}); //on종료
}); //ready종료

받은 데이터를 처리할 때 컨트롤러에서 RequestParam을 사용합니다.

결론

스프링에서 어떤 방법을 선택해 비동기 통신을 시도하던

컨트롤러에서 데이터를 처리할 땐 GET 방식이면 PathVariable.

POST 방식이면 RequestParam를 사용합니다.

추가로 이번 포스팅에선 비동기 통신으로 데이터만 주고 받고

받은 데이터를 사용해 부분적으로 브라우저 화면을 재구성하는 부분은 제외하였는데요.

이때 개발자가 일일이 태그를 구성하지 않으면서 서버의 부담도 줄이고자

개발된 것이 React이기 때문에 다음 포스팅에 같이 묶어서 설명하도록 하겠습니다.

그나저나 React 아이콘을 볼 때마다 원자로가 떠오르는 건 나만 그런가...? 출처:giphy