블로그 이름 뭐하지??

CSRF 공격 방지 - SameSite 쿠키, CSRF 토큰

Potwings — Tue, 7 Oct 2025 16:28:10 +0900

인증과 관련하여 Spring Security에 대해 학습하던 중 CSRF라는 키워드에 갑자기 궁금증이 생겼다.

최근에는 대부분의 백엔드 서버가 REST API 형식으로 데이터를 제공하여 CSRF에 대한 검증을 하지 않는다 하였다.

REST API 서버에서 CSRF에 대한 검증이 disable 상태인 모습

그렇다면 기존의 세션 방식으로 인증을 진행할 때는 왜 CSRF 공격에 대한 대비를 해야했을까??

CSRF 공격이란?

Cross-Site Request Forgery의 줄임말로 사이트 간 요청 위조라는 의미이며,

공격자가 인증된 사용자의 권한을 악용하여 사용자가 의도하지 않은 요청을 다른 사이트로 보내도록 하는 공격 기법이다.

CSRF 공격 테스트

우선 테스트를 위해 공격 대상이 될 게시판 서비스를 생성하였다.

그리고 CSRF 공격을 시도하기 위해 피싱 페이지를 제작하였다.

피싱 사이트 화면

이 둘은 서로 다른 서비스임을 가정하기 위해 게시판 서비스는 localhost로 접근, 피싱 사이트는 127.0.0.1로 접근하였다.

이제 게시판 서비스에 로그인한 사용자가 피싱 사이트에 접근할 경우 사용자의 인증 정보를 활용하여 공격자가 의도한대로 게시글이 등록되게 할 것이다.

이 때 CSRF 공격을 두가지 방법으로 구현하였다.

1. form을 활용한 CSRF 공격

페이지 로딩 시 자동으로 csrfForm을 submit 하도록 하여 사용자의 인증 정보를 활용하여 게시글을 작성하는 방식이다.

<!-- 방법 1: Form & iframe 활용 -->
<form id="csrfForm" action="http://localhost:8080/board/new" method="POST" target="hiddenFrame">
  <input type="hidden" name="title" value="Form CSRF ATTACK">
  <input type="hidden" name="writer" value="hacker">
  <input type="hidden" name="content" value="게시판 중학생한테 털렸죠 ㅋㅋㅋㅋㅋ">
</form>

<!-- iframe 추가 - 폼 제출 결과 여기로 이동 (사용자가 공격 사실 모르도록) -->
<iframe name="hiddenFrame" style="display:none;"></iframe>

<script>
  // 노출되지 않은 form에서 진행된 요청 전송
  document.getElementById('csrfForm').submit();
 </script>

form을 submit할 경우 자동으로 페이지 이동이 진행되는데

hiddenFrame을 생성하여 페이지 이동을 hiddenFrame에서 발생시켜 사용자가 알아차리지 못하도록 하였다.

2. ajax를 활용한 CSRF 공격

두번째 방법은 ajax를 활용하여 페이지 로딩 시 게시글이 작성되도록 하는 방식이다.

  <!-- 방법 2: ajax를 활용한 CSRF 공격 -->
  <!-- 요청 시 credentials: 'include' 옵션을 추가하여 쿠키(세션) 포함 -->
  function sendCSRF() {
    var formData = new FormData();
    formData.append('title', 'JS CSRF ATTACK');
    formData.append('writer', 'hacker');
    formData.append('content', '게시판 중학생한테 털렸죠 ㅋㅋㅋㅋㅋ');

    fetch('http://localhost:8080/board/new', {
      method: 'POST',
      body: formData,
      credentials: 'include',  // 쿠키(세션) 포함
    }).then((result) => {
      document.getElementById('status').innerHTML = '<p style="color: green;">AJAX 요청 전송 완료</p>';
    });
  }

  sendCSRF();

게시판 서비스에서 사용자의 인증된 세션 정보는 쿠키에 저장하고 있으므로 ajax 요청 시 인증 정보도 같이 전달하기 위해 credentials: 'include' 옵션을 추가해주었다.

실행 결과

위와 같이 공격자는 게시판 서비스에서 접근 권한이 없음에도 사용자 인증 정보를 활용하여 글을 등록할 수 있었다.

그렇다면 이는 어떻게 방지할 수 있을까??

대처 방안

1. 쿠키 SameSite 정책을 설정

첫번째 방법은 공격자의 사이트에서 사용자 인증 정보를 활용할 수 없도록 하는 것이다.

이를 위하여 우리는 사용자 인증 정보 쿠키에 SameSite 속성을 추가하면 된다.

SameSite 속성이란?
브라우저가 해당 쿠키를 어떤 상황에서 요청에 포함시킬지를 제어하는 정책

SameSite 속성은 총 3종류가 있다.

1. SameSite = None

모든 cross-site 요청에도 쿠키를 전송

제3자 서비스에서도 쿠키를 사용할 수 있기 때문에 위와 같은 CSRF 공격에 취약하다.

2. SameSite=Lax (기본값)

비교적 보안상 안전한 GET 방식의 요청에서만 쿠키를 전송

POST 요청, iframe, 이미지, AJAX 등 cross-site 컨텍스트에서는 쿠키를 전송하지 않음.

Chrome 80 버전부터는 별도의 정책이 수립되어있지 않은 경우 Lax를 기본값으로 사용한다.

(localhost의 경우 브라우저에서 테스트 환경으로 판단하여 이 정책에 포함되지 않았다)

3. SameSite=Strict

가장 보수적인 설정으로 같은 사이트 내에서의 요청에서만 해당 쿠키를 사용할 수 있다.

예시에서 CSRF 공격은 iframe, AJAX 요청을 통해 진행되었으므로 SameSite를 Lax로 설정하여 CSRF 공격을 예방할 수 있다.

SameSite Lax 설정 추가

SameSite가 Lax로 설정된 모습

인증 정보 쿠키가 없으므로 글이 등록되지 않고 login 페이지로 redirect 되는 것을 확인할 수 있다.

2. CSRF 토큰 활용

두번째 방법은 CSRF 토큰을 활용하는 것이다.

CSRF 토큰이란 서버에서 암호화된 랜덤값을 생성 후 브라우저와 주고 받아 사용자의 의도에 따라 정상적으로 발생된 요청인지 검증하는데 쓰이는 토큰값이다.

글을 시작할 때 보았던 Spring Security의 CSRF 속성은 CSRF 토큰을 활용할지에 대한 설정값이다.

CSRF 토큰 사용 여부

해당 설정값을 disable 하지 않을 경우 POST 요청 시 CSRF 토큰이 같이 넘어왔는지 검증을 진행하고 토큰이 없을 경우 요청은 거부된다.

CSRF 토큰 없이 요청 할 경우 거부

아래와 같이 form에 CSRF 토큰 값 추가하여 같이 전송해주면 정상적으로 요청이 처리된다.

정상적으로 CSRF 토큰 값 추가

정상적으로 요청이 처리된 모습

REST API에서 CSRF 토큰을 disable 하는 이유?

REST API의 경우 무상태(stateless)라 이전 요청에서 발생한 내용을 기억하지 않는다.

쿠키나 세션에 인증 정보를 저장하지 않기 때문에 브라우저에 저장된 인증 정보를 악용하는 CSRF 공격에 당할 위험이 적다.

따라서 Spring Security의 CSRF 토큰 설정값을 disable 할 수 있는 것이다.

비개발자도 할 수 있는 구글 시트로 웹 앱 만들기

Potwings — Sun, 30 Mar 2025 17:35:00 +0900

개발 동기

최근 비개발자인 친구가 회사에서 업무 부담을 줄이기 위해 기업들의 데이터를 각 기업의 담당자들이 직접 수정할 수 있도록 하고 싶어 방법을 찾고 있다는 이야기를 들어 시작하게 되었다.

물론 실제 어플리케이션을 개발하면 쉽게 제작할 수 있는 내용이나 아무래도 비개발자가 이를 운영하기 위한 인프라 및 유지보수를 진행하기엔 무리가 있다 판단하였다.

그러던 중 구글 스프레드 시트로 웹앱을 제작할 수 있다는 것을 알게되어 이를 활용하여 진행하게 되었다.

개발 과정

구글 스프레드 시트의 앱 스크립트를 활용하여 개발을 진행하였다.

스프레드 시트의 [확장 프로그램] 메뉴에서 [Apps Script]에서 시작할 수 있다.

프로젝트 초기 생성 시 아래와 같이 gs 파일를 마주하게 되는데

gs 코드의 정확한 문법을 알지 못하지만 걱정할 필요 없다. ChatGPT를 활용하면 되니까.

Apps Script 기본 파악

우선 기본적인 동작 방식을 알아보기 위해 간단한 데이터로 기능만 동작할 수 있도록 구현해달라 요청하였다.

GPT가 작성해준 코드 확인 [클릭]

Code.gs

function doGet() {
  return HtmlService.createHtmlOutputFromFile('Index');
}

function include(filename) {
  return HtmlService.createHtmlOutputFromFile(filename).getContent();
}

function loginUser(projectNumber, bizNumber) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");
  const data = sheet.getDataRange().getValues();

  for (let i = 1; i < data.length; i++) {
    if (data[i][0] == projectNumber && data[i][1] == bizNumber) {
      return {
        success: true,
        name: data[i][2],
        phone: data[i][3],
        email: data[i][4],
        rowIndex: i + 1
      };
    }
  }

  return { success: false, message: "일치하는 정보가 없습니다." };
}

function updateUser(rowIndex, name, phone, email) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");
  sheet.getRange(rowIndex, 3).setValue(name);
  sheet.getRange(rowIndex, 4).setValue(phone);
  sheet.getRange(rowIndex, 5).setValue(email);
  return { success: true };
}

Index.html

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
    <style>
      body { font-family: Arial; margin: 20px; }
      input { margin-bottom: 10px; display: block; }
    </style>
  </head>
  <body>
    <h2>로그인</h2>
    <input type="text" id="projectNumber" placeholder="과제번호">
    <input type="text" id="bizNumber" placeholder="사업자번호">
    <button onclick="login()">로그인</button>

    <div id="userInfo" style="display:none;">
      <h3>내 정보</h3>
      <input type="text" id="name" placeholder="담당자명">
      <input type="text" id="phone" placeholder="휴대폰번호">
      <input type="text" id="email" placeholder="이메일">
      <button onclick="update()">정보 수정</button>
    </div>

    <script>
      let currentRow = null;

      function login() {
        const projectNumber = document.getElementById('projectNumber').value;
        const bizNumber = document.getElementById('bizNumber').value;

        google.script.run.withSuccessHandler(function(response) {
          if (response.success) {
            currentRow = response.rowIndex;
            document.getElementById('userInfo').style.display = 'block';
            document.getElementById('name').value = response.name;
            document.getElementById('phone').value = response.phone;
            document.getElementById('email').value = response.email;
          } else {
            alert(response.message);
          }
        }).loginUser(projectNumber, bizNumber);
      }

      function update() {
        const name = document.getElementById('name').value;
        const phone = document.getElementById('phone').value;
        const email = document.getElementById('email').value;

        google.script.run.withSuccessHandler(function(res) {
          if (res.success) alert('정보가 수정되었습니다!');
        }).updateUser(currentRow, name, phone, email);
      }
    </script>
  </body>
</html>

해당 파일들을 내 프로젝트에 추가해 주고 정상적으로 동작할 수 있도록 이에 맞춰 스프레드 시트에 데이터를 추가해주었다.

그 후 우측 상단의 [배포] 버튼을 통하여 웹앱을 배포할 수 있다.

[배포] > [새 배포] > [유형 선택] 우측 톱니바퀴 > [웹 앱] 후 아래와 같이 작성

(설명은 개발자가 알아보기 위한 설명이라 내용 무관하다)

만일 액세스 허용을 요청하는 문구가 나온다면 허용을 진행해주자.

배포를 완료한다면 아래와 같이 URL이 나오고 접속하면 HTML로 구현된 화면을 확인할 수 있다.

그 후 스프레드 시트에 등록된 정보를 입력하면 아래와 같아 정상적으로 조회/수정이 가능하며 시트에도 변경된 내용이 반영된 것을 확인할 수 있다.

고도화 진행

이제 어느정도 어떻게 동작하는지에 대해 이해하였으니 정확한 요구사항을 전달하여 요청하였다.

GPT가 작성해준 코드 확인[클릭]

Code.gs

function loginUser(projectNumber, bizNumber) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");
  const data = sheet.getDataRange().getValues();

  for (let i = 1; i < data.length; i++) {
    if (data[i][4] == projectNumber && data[i][5] == bizNumber) {
      // No 제외한 나머지 정보 (index 1부터)
      const userInfo = {
        연도: data[i][1],
        과제명: data[i][2],
        차수: data[i][3],
        과제번호: data[i][4],
        사업자번호: data[i][5],
        기업명: data[i][6],
        대표자명: data[i][7],
        대표자휴대폰번호: data[i][8],
        대표자이메일: data[i][9],
        담당자명직책: data[i][10],
        담당자휴대폰번호: data[i][11],
        담당자이메일: data[i][12],
      };

      return {
        success: true,
        data: userInfo,
        rowIndex: i + 1
      };
    }
  }

  return { success: false, message: "일치하는 과제번호 및 사업자번호가 없습니다." };
}

function updateUser(rowIndex, updatedData) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");

  // No는 건너뛰고 2번째 열(B열)부터 M열까지 갱신
  const values = [
    updatedData.연도,
    updatedData.과제명,
    updatedData.차수,
    updatedData.과제번호,
    updatedData.사업자번호,
    updatedData.기업명,
    updatedData.대표자명,
    updatedData.대표자휴대폰번호,
    updatedData.대표자이메일,
    updatedData.담당자명직책,
    updatedData.담당자휴대폰번호,
    updatedData.담당자이메일,
  ];

  sheet.getRange(rowIndex, 2, 1, values.length).setValues([values]);

  return { success: true };
}

Index.html

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
    <style>
      body {
        font-family: 'Segoe UI', sans-serif;
        background-color: #f0f2f5;
        padding: 40px;
      }
      .container {
        max-width: 500px;
        margin: auto;
        background: white;
        padding: 30px;
        border-radius: 12px;
        box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
      }
      h2 {
        text-align: center;
        color: #333;
      }
      label {
        display: block;
        margin-top: 10px;
        font-weight: bold;
        color: #555;
      }
      input {
        width: 100%;
        padding: 10px;
        margin-top: 5px;
        border: 1px solid #ccc;
        border-radius: 6px;
        box-sizing: border-box;
      }
      button {
        width: 100%;
        margin-top: 20px;
        padding: 12px;
        background-color: #4CAF50;
        color: white;
        border: none;
        border-radius: 6px;
        font-size: 16px;
        cursor: pointer;
      }
      #userInfo {
        display: none;
        margin-top: 30px;
      }
    </style>
  </head>
  <body>
    <div class="container">
      <h2>사용자 로그인</h2>

      <label for="projectNumber">과제번호</label>
      <input type="text" id="projectNumber" placeholder="예: PRJ-1234">

      <label for="bizNumber">사업자번호</label>
      <input type="text" id="bizNumber" placeholder="예: 123-45-67890">

      <button onclick="login()">로그인</button>

      <div id="userInfo">
        <hr>
        <h2>과제 정보</h2>
        <div id="form-fields"></div>
        <button onclick="update()">정보 저장</button>
      </div>
    </div>

    <script>
      let currentRow = null;
      let userData = {};

      function login() {
        const projectNumber = document.getElementById("projectNumber").value.trim();
        const bizNumber = document.getElementById("bizNumber").value.trim();

        if (!projectNumber || !bizNumber) {
          alert("과제번호와 사업자번호를 입력해주세요.");
          return;
        }

        google.script.run.withSuccessHandler(function (response) {
          if (response.success) {
            currentRow = response.rowIndex;
            userData = response.data;

            const form = document.getElementById("form-fields");
            form.innerHTML = "";

            for (const key in userData) {
              const label = document.createElement("label");
              label.textContent = key;
              const input = document.createElement("input");
              input.id = key;
              input.value = userData[key];
              form.appendChild(label);
              form.appendChild(input);
            }

            document.getElementById("userInfo").style.display = "block";
          } else {
            alert(response.message || "로그인 실패");
          }
        }).loginUser(projectNumber, bizNumber);
      }

      function update() {
        const updated = {};
        for (const key in userData) {
          updated[key] = document.getElementById(key).value;
        }

        google.script.run.withSuccessHandler(function (res) {
          if (res.success) {
            alert("정보가 성공적으로 저장되었습니다.");
          } else {
            alert("수정 실패");
          }
        }).updateUser(currentRow, updated);
      }
    </script>
  </body>
</html>

GPT가 작성해준 코드를 활용하여 기존 코드의 loginUser, updateUser 함수의 내용을 변경해주고 변경된 HTML을 적용해주고, 스프레드 시트의 내용도 이에 맞춰 변경해주었다.

수정 사항이 반영되어 정상적으로 기능이 동작하는 것을 확인할 수 있엇다.

추가 개선

이후 사용자가 수정하는 데이터를 검증하고, 데이터 포맷에 대한 가이드를 추가하여 한번 더 개선을 진행하였다.

최종 결과

코드

code.gs

function doGet() {
  return HtmlService.createHtmlOutputFromFile('Index');
}

function include(filename) {
  return HtmlService.createHtmlOutputFromFile(filename).getContent();
}

function loginUser(projectNumber, bizNumber) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");
  const data = sheet.getDataRange().getValues();

  for (let i = 1; i < data.length; i++) {
    if (data[i][4] == projectNumber && data[i][5] == bizNumber) {
      // No 제외한 나머지 정보 (index 1부터)
      const userInfo = {
        "연도": data[i][1],
        "과제명": data[i][2],
        "차수": data[i][3],
        "과제 번호": data[i][4],
        "사업자 번호": data[i][5],
        "기업명": data[i][6],
        "대표자명": data[i][7],
        "대표자 휴대폰 번호": data[i][8],
        "대표자 이메일": data[i][9],
        "담당자명(직책)": data[i][10],
        "담당자 휴대폰 번호": data[i][11],
        "담당자 이메일": data[i][12],
      };

      return {
        success: true,
        data: userInfo,
        rowIndex: i + 1
      };
    }
  }

  return { success: false, message: "일치하는 과제번호 및 사업자번호가 없습니다." };
}

function updateUser(rowIndex, updatedData) {
  const sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName("시트1");

  // 수정 가능한 필드만 업데이트 (8~13번째 열 = I~M 열)
  const editableValues = [
    updatedData["대표자 휴대폰 번호"],
    updatedData["대표자 이메일"],
    updatedData["담당자명(직책)"],
    updatedData["담당자 휴대폰 번호"],
    updatedData["담당자 이메일"]
  ];


  // rowIndex 행의 I열(9번째 열)부터 5개 열을 덮어쓰기
  sheet.getRange(rowIndex, 9, 1, editableValues.length).setValues([editableValues]);

  return { success: true };
}

Index.html

<!DOCTYPE html>
<html>
  <head>
    <base target="_top">
    <style>
      body {
        font-family: 'Segoe UI', sans-serif;
        background-color: #f0f2f5;
        padding: 40px;
      }
      .container {
        max-width: 500px;
        margin: auto;
        background: white;
        padding: 30px;
        border-radius: 12px;
        box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
      }
      h2 {
        text-align: center;
        color: #333;
      }
      label {
        display: block;
        margin-top: 10px;
        font-weight: bold;
        color: #555;
      }
      input {
        width: 100%;
        padding: 10px;
        margin-top: 5px;
        border: 1px solid #ccc;
        border-radius: 6px;
        box-sizing: border-box;
      }
      button {
        width: 100%;
        margin-top: 20px;
        padding: 12px;
        background-color: #4CAF50;
        color: white;
        border: none;
        border-radius: 6px;
        font-size: 16px;
        cursor: pointer;
      }
      #userInfo {
        display: none;
        margin-top: 30px;
      }
    </style>
  </head>
  <body>
    <div class="container">
      <div style="text-align: center;">
        <h3>사용자 로그인</h3>
      </div>

      <label for="projectNumber">과제번호</label>
      <input type="text" id="projectNumber" placeholder="예 : 12345678">

      <label for="bizNumber">사업자번호</label>
      <input type="text" id="bizNumber" placeholder="예: 123-45-67890">

      <button onclick="login()">로그인</button>

      <div id="userInfo">
        <hr>
        <h2>과제 정보</h2>
        <div id="form-fields"></div>
        <button onclick="update()">정보 저장</button>
      </div>
    </div>

    <script>
      let currentRow = null;
      let userData = {};

      // 표시 순서와 일치하도록 배열로 순서 지정
      const fieldOrder = [
        "연도",
        "과제명",
        "차수",
        "과제 번호",
        "사업자 번호",
        "기업명",
        "대표자명",
        "대표자 휴대폰 번호",
        "대표자 이메일",
        "담당자명(직책)",
        "담당자 휴대폰 번호",
        "담당자 이메일"
      ];

      const readOnlyFields = [
        "연도",
        "과제명",
        "차수",
        "과제 번호",
        "사업자 번호",
        "기업명",
        "대표자명"
      ];


      function login() {
        const projectNumber = document.getElementById("projectNumber").value.trim();
        const bizNumber = document.getElementById("bizNumber").value.trim();

        if (!projectNumber || !bizNumber) {
          alert("과제번호와 사업자번호를 입력해주세요.");
          return;
        }

        google.script.run.withSuccessHandler(function (response) {
          if (response.success) {
            currentRow = response.rowIndex;
            userData = response.data;

            const form = document.getElementById("form-fields");
            form.innerHTML = "";

            fieldOrder.forEach((key) => {
              const label = document.createElement("label");
              label.textContent = key;

              const input = document.createElement("input");
              input.id = key;
              input.value = userData[key] || "";

              // 포맷 안내 텍스트
              const hint = document.createElement("small");
              hint.style.fontSize = "12px";
              hint.style.color = "#888";

              if (readOnlyFields.includes(key)) {
                input.setAttribute("readonly", true);
                input.style.backgroundColor = "#f0f0f0";
              } else {
                // 유효성 포맷 힌트 표시
                if (key.includes("휴대폰")) {
                  hint.textContent = "예: 010-1234-5678";
                } else if (key.includes("이메일")) {
                  hint.textContent = "예: example@example.com";
                }
              }

              form.appendChild(label);
              form.appendChild(input);
              if (hint.textContent) form.appendChild(hint);
            });


            document.getElementById("userInfo").style.display = "block";
          } else {
            alert(response.message || "로그인 실패");
          }
        }).loginUser(projectNumber, bizNumber);
      }

      function update() {
        const updated = {};
        let isValid = true;
        let errorMessage = "";

        const phoneRegex = /^\d{3}-\d{3,4}-\d{4}$/;
        const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

        fieldOrder.forEach((key) => {
          const value = document.getElementById(key).value.trim();
          updated[key] = value;

          if (!readOnlyFields.includes(key)) {
            if (key.includes("휴대폰") && value && !phoneRegex.test(value)) {
              isValid = false;
              errorMessage = `${key} 형식이 올바르지 않습니다. (예: 010-1234-5678)`;
            }
            if (key.includes("이메일") && value && !emailRegex.test(value)) {
              isValid = false;
              errorMessage = `${key} 형식이 올바르지 않습니다. (예: example@example.com)`;
            }
          }
        });

        if (!isValid) {
          alert(errorMessage);
          return;
        }

        google.script.run.withSuccessHandler(function (res) {
          if (res.success) {
            alert("정보가 성공적으로 저장되었습니다.");
          } else {
            alert("수정 실패");
          }
        }).updateUser(currentRow, updated);
      }

    </script>
  </body>
</html>

화면

로그인

조회 및 수정

수정 시 데이터 검증

Github : https://github.com/Potwings/Google-Sheet-WebApp

GitHub - Potwings/Google-Sheet-WebApp: 구글 스프레드 시트를 활용하여 제작한 웹 앱

구글 스프레드 시트를 활용하여 제작한 웹 앱. Contribute to Potwings/Google-Sheet-WebApp development by creating an account on GitHub.

github.com

SOLID 원칙이란?

Potwings — Tue, 31 Dec 2024 23:57:11 +0900

객체지향에서 소프트웨어를 변경에 유연한 구조, 이해하기 쉬운 구조로 만들기 위한 5가지 원칙으로 각 원칙들의 앞글자를 따서 SOLID 원칙이라 불린다.

SRP - 단일 책임의 원칙

하나의 클래스에서 하나의 책임만 가져야 한다

책임은 매우 주관적인 단어라 이해하기 조금 어려울 수 있는데

좀 더 쉽게 표현하자면 하나의 클래스의 변경은 오직 하나의 이유만으로 이루어져야 한다라고 말할 수 있다.

만일 SRP 원칙을 지키지 않을 경우 어떤 문제가 발생하는지 예시를 통해 알아보자

YG쇼핑몰에서는 회원가입을 했을 경우 가입 환영 이메일을, 주문을 완료했을 경우 주문 내역 알림 메일을 발송해준다.

각각 sendWelcomeMail, sendOrderMail 메소드로 기능을 제공하며,

둘 다 메일을 발송해야 하므로 sendMail을 공통으로 사용한다.

    public class EmailSender {

      public void sendWelcomeMail() {
        // 가입 환영 메일 발송 - sendMail 메소드 활용
      }

      public void sendOrderMail() {
        // 주문 내역 알림 메일 발송 - sendMail 메소드 활용
      }

      public void sendMail() {
        // 이메일 발송 메소드
      }
    }

어느 날 sendOrderMail 메소드를 수정하는 과정에서 sendMail 메소드의 내용도 변경이 발생하였다.

sendMail 메소드에 변경사항이 발생해 이에 맞춰 sendWelcomeMail 메소드도 변경이 불가피해졌다.

sendWelcomeMail 기능에는 변경사항이 없는데도 변경해야 하는 불필요한 작업이 발생한 것이다.

또, 해당 클래스에 또 다른 기능들이 있었더라면 클래스의 변경이 발생함에 따라 기능이 수정되지 않은 메소드들도 불필요하게 컴파일이 발생하게 된다.

만일 하나의 클래스에서 하나의 책임만 가지고 있도록 분리해두었더라면,

주문 내역 알림 메일 발송 기능을 수정하였을 때 sendWelcomeMail 메소드의 수정은 발생하지 않았을 것이고,

불필요한 컴파일도 발생하지 않았을 것이다.

OCP - 개방 - 폐쇄 원칙

클래스는 확장에는 열려있어야하며 수정에는 닫혀있어야 한다.

확장에는 열려있어야 한다는 건 새로운 요구 사항이 발생할 경우 유연하게 기능을 확장할 수 있어야 한다는 내용이고,

수정에는 닫혀있어야 한다는 건 새로운 기능을 추가 시 기존의 코드는 수정이 발생하면 안된다 라는 내용이다.

그렇다면 어떻게 유연한 기능 추가가 가능하되 기존 코드의 수정이 발생하지 않도록 할 수 있을까?

우린 객체 지향의 특징 중 추상화, 다형성을 활용하여 쉽게 해결할 수 있다.

예시를 통해 더 자세히 알아보자

YG쇼핑몰에서는 결제 수단을 추가하려고 한다,

기존에는 신용카드, 계좌이체만 지원하였으나 이제 카카오페이 결제도 추가하고자 한다.

먼저 OCP를 고려하지 않고 작성한 코드를 보자

    // OCP 위반 예시
    // 결제 처리기
    public class PaymentProcessor {
        public void doPayment(String type, int amount) {
            if (type.equals("CREDIT_CARD")) {
                  // 신용카드 결제 처리
                processCreditCardPayment(amount);
            } else if (type.equals("BANK_TRANSFER")) {
                // 계좌이체 결제 처리
                processBankTransferPayment(amount);
            }
        }
    }

위와 같이 코드가 작성되어 있다면 우리는 매번 if문에 조건을 추가하여 결제 수단을 추가해야 한다.

그렇게 되면 기능이 추가될 때마다 기존 코드의 변경이 발생하며 이는 곧 OCP를 위반하는 것이 된다.

이제 추상화와 다형성을 활용하여 OCP를 준수하도록 수정해보자

결제 수단의 공통되는 기능을 인터페이스로 추출하여 추상화를 진행하고,

PaymentProcessor에서 각각의 어떤 결제 수단 구현체든지 활용할 수 있도록 다형성을 적용할 것이다.

    // OCP 준수 예시
    // 결제 처리를 위한 인터페이스
    public interface PaymentStrategy {
        void processPayment(int amount);
    }

    // 신용카드 결제 구현체
    public class CreditCardPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("신용카드 결제: " + amount + "원");
        }
    }

    // 계좌이체 결제 구현체
    public class BankTransferPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("계좌이체: " + amount + "원");
        }
    }

    // 결제 처리기
    public class PaymentProcessor {
        private PaymentStrategy paymentStrategy;

        public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
            this.paymentStrategy = paymentStrategy;
        }

        public void processPayment(int amount) {
            paymentStrategy.processPayment(amount);
        }
    }

이제 새로운 결제 수단을 추가하고 싶다면 기존 코드를 수정할 필요 없이 PaymentStrategy 인터페이스를 구현하는 새로운 클래스만 만들면 된다.

    public class KakaoPayPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("카카오페이 결제: " + amount + "원");
        }
    }

이렇게 결제 시스템을 구현해두면 우리는 기존 코드의 수정 없이 새로운 결제 방식을 얼마든지 추가할 수 있다.

LSP - 리스코프 치환 원칙

자식 타입은 언제나 부모 타입으로 교체될 수 있어야 한다.

서브 타입은 항상 부모 타입이 가지고 있는 기능들을 동일하게 수행할 수 있어야 한다는 말이다.

이는 객체 지향의 특징 중 다형성의 오버라이딩을 좀 더 잘 활용하기 위한 원칙으로 보면 된다.

부모 타입으로 선언한 변수에 자식 타입의 구현체를 할당한 후 메소드를 실행하면 오버라이딩한 메소드를 실행하게 된다.

만일 각각의 구현체들이 부모와 다른 기능을 수행하게 된다면,

우리는 구현체를 변경 할 때마다 변경되는 구현체의 동작을 매번 확인해야하며 이는 매우 비효율적이다.

따라서 우리는 LSP 원칙을 준수하여 이러한 비효율적인 일이 생기지 않도록 하는 것이다.

예시를 통해 자세히 알아보자

YG쇼핑몰에서는 일반 고객에게는 5%의 기본 할인을, VIP 고객에게는 15%의 기본 할인을 제공한다.

이를 아래와 같이 코드를 작성하여 구현하였다.

    // LSP 위반 예시
    class Member {
            public void login() {
                // 공통 로그인 로직
            }

        public int discount(int price) {
          return (int)(price * 0.95); // 5% 할인
        }
    }

    class VIPMember extends Member {
        @Override
        public int discount(int price) {
          return (int)(price * 0.85); // 15% 할인
        }
    }

이 코드는 얼핏 보기에는 문제가 없어보이나, LSP 원칙을 위반하고 있다.

부모 타입인 Member 클래스에서 5%의 할인을 제공하고 있는데,

만일 여기서 자식 타입인 VIPMember로 구현체가 교체될 경우 15%의 할인이 적용되며 기존과 기능이 달라진다.

이 경우 구현체마다 기능이 다르므로 부모 타입에 있는 기능임에도 불구하고 구현체를 변경할 때마다 동일하게 동작하는지 확인이 필요하게 될 것이다.

이제 LSP를 준수하도록 기능을 수정해보자.

    // LSP 준수 예시
    abstract class Member {

      boolean login() {
        // 공통 로그인 로직
      }

        // 고객마다 다른 할인율은 각 클래스에서 구현
      abstract int discount(int price);
    }

    class NormalMember extends Member {

      @Override
      int discount(int price) {
        return (int) (price * 0.95); // 5% 할인
      }
    }

    class VIPMember extends Member {

      @Override
      int discount(int price) {
        return (int) (price * 0.85); // 15% 할인
      }
    }

공통되는 기능인 login은 부모 클래스인 Member에서 관리하되,

경우에 따라 다른 discount 메소드는 각 회원 타입이 자신에게 맞는 할인 정책을 구현하여 사용하도록 수정하였다.

이렇게 할 경우 부모 타입인 Member를 자식 타입인 NormalMember와 VIPMember가 대체하더라도 기존 부모 타입에서 제공하는 기능은 기존과 동일하게 동작한다.

ISP - 인터페이스 분리의 원칙

인터페이스의 동작을 고려하여 인터페이스를 잘 분리해야 한다.

언뜻보면 위에서 보았던 SRP와 유사하다 볼 수 있지만 조금은 다르다.

구현체에서 사용하지 메소드를 구현하면 안된다는 것이다.

만일 사용하지 않는 메소드가 인터페이스에 있어 구현해야 한다면 인터페이스 분리를 통해 구현체에게 필요한 메소드만 제공해야 한다는 내용이다.

아래 코드를 통해 더 자세히 이해해보자

UserOperations라는 인터페이스를 생성하여 유저들(판매자, 구매자, 관리자)들이 사용하는 기능들을 정의해두었다.

이 중 구매자에 대해 구현을 예시로 들어보자

    // ISP 위반 예시
    interface UserOperations {
        void purchase();      // 구매자 기능
        void sell();         // 판매자 기능
        void manageUsers();  // 관리자 기능
    }

    // 구매자 클래스 구현
    class Buyer implements UserOperations {
        @Override
        public void purchase() {
            // 구매 로직
        }

        @Override
        public void sell() {
                // 구매자에게 불필요한 로직
            // Do nothing
        }

        @Override
        public void manageUsers() {
                // 구매자에게 불필요한 로직
            // Do nothing
        }
    }

만일 하나의 인터페이스에서 유저의 모든 동작을 관리할 경우 위와 같이 구매자에게 불필요한 메소드까지도 구현을 해두어야한다.

이 상태에서 sell이나 managerUsers 메소드가 변경사항이라도 생긴다면 Buyer는 이 메소드를 사용하지도 않음에도 다시 빌드되거나 영향을 받을 수 있다.

이제 ISP를 준수하도록 인터페이스를 분리해보자.

    // ISP 준수 예시
    interface BuyerOperations {
        void purchase();
    }

    interface SellerOperations {
        void sell();
    }

    interface AdminOperations {
        void manageUsers();
    }

    // 구매자는 필요한 기능만 구현
    class Buyer implements BuyerOperations {
        @Override
        public void purchase() {
            // 구매 로직
        }
    }

    // 판매자는 필요한 기능만 구현
    class Seller implements SellerOperations {
        @Override
        public void sell() {
            // 판매 로직
        }
    }

    // 관리자는 필요한 기능만 구현
    class Admin implements AdminOperations {
        @Override
        public void manageUsers() {
            // 사용자 관리 로직
        }
    }

이렇게 인터페이스를 분리하면 구현체들은 자신에 유형에 맞는 기능만 구현하면 된다.

또한 코드의 가독성과 유지보수성이 향상된다.

DIP - 의존성 역전의 원칙

다른 클래스에 의존할 경우 추상화에 의존해야하며 구현체에 의존하면 안된다.

개발을 하다보면 다른 클래스에 있는 기능이 필요할 때 다른 클래스를 참조(의존)하여 메소드를 불러올 일이 많다.

이 때 다른 클래스를 직접 참조하는 것이 아닌 그의 추상화(추상 클래스 or 인터페이스)를 참조해야 한다는 것이다.

왜 구현체가 아닌 추상화를 참조해야할까?

구현체는 변동성이 크기 때문이다.

만일 기능에 변경이 발생하여 다른 구현체를 참조해야하는 경우가 발생한다 생각해보자.

그 경우 구현체에 의존하고 있다면 우리는 다른 구현체를 바라보도록 코드의 변경도 발생할 것이다.

허나 추상화에 의존하고 있다면 같은 추상화를 구현하는 구현체로는 얼마든지 치환이 가능하다.

결제 상황을 예시로 들어 확인해보자

현재 우리 쇼핑몰은 신용카드 결제만 지원하여 결제를 담당하는 클래스인 PaymentProcessor를 아래와 같이 구현해두었다.

    // DIP 위반 예시
    // 신용카드 결제 구현체
    public class CreditCardPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("신용카드 결제: " + amount + "원");
        }
    }

    // 결제 처리기
    public class PaymentProcessor {
        // 신용카드 결제 구현체에 의존
        private CreditCardPayment paymentStrategy;

        public void setPaymentStrategy(CreditCardPayment paymentStrategy) {
            this.paymentStrategy = paymentStrategy;
        }

        public void processPayment(int amount) {
            paymentStrategy.processPayment(amount);
        }
    }

이 상태에서 계좌 이체를 통한 결제까지 지원하려한다면 계좌 결제 처리를 진행하는 별도의 결제 처리기를 또 추가해야하는 작업이 발생할 것이다.

허나 구현체가 아닌 인터페이스(추상화)에 의존을 하고 있었다면 어떻게 되었을까?

    // DIP 준수 예시
    // 결제 처리를 위한 인터페이스
    public interface PaymentStrategy {
        void processPayment(int amount);
    }

    // 신용카드 결제 구현체
    public class CreditCardPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("신용카드 결제: " + amount + "원");
        }
    }

    // 결제 처리기
    public class PaymentProcessor {
        private PaymentStrategy paymentStrategy;

        public void setPaymentStrategy(PaymentStrategy paymentStrategy) {
            this.paymentStrategy = paymentStrategy;
        }

        public void processPayment(int amount) {
            paymentStrategy.processPayment(amount);
        }
    }

현재 결제 처리기에서 인터페이스를 바라보고 있기 때문에 우리는 해당 인터페이스를 구현하는 계좌 결제 구현체를 구현한 후 주입해주기만 한다면 무리없이 계좌 결제까지 처리할 수 있게 된다.

    // 계좌이체 결제 구현체
    public class BankTransferPayment implements PaymentStrategy {
        @Override
        public void processPayment(int amount) {
            System.out.println("계좌이체: " + amount + "원");
        }
    }

참고자료

https://tech.kakaobank.com/posts/2411-solid-truth-or-myths-for-developers/

https://inpa.tistory.com/entry/OOP- -객체-지향-설계의-5가지-원칙-SOLID#단일_책임_원칙_-_srp_single_responsibility_principle

AI의 두 번의 겨울 - XOR 문제, 기울기 소실 문제

Potwings — Tue, 29 Oct 2024 19:31:58 +0900

ChatGPT 등장 이후 지금까지 AI는 뜨거운 화두이다. 이전까지는 상상도하지 못했던 것들이 AI를 활용하여 가능해졌고 하루가 멀다하고 새로운 역할을 하는 AI는 출시되고 있다.

AI는 이떻게 이렇게 발전하게 되었을까?

인공지능의 탄생

초기의 인공신경망은 단순 on/off 기능의 인공 신경을 그물망 형태로 연결하면 뇌에서 동작하는 간단한 기능을 흉내낼 수 있다는 이론에서 시작되었다.이 신경망 내에서 반복적인 시그널이 발생할 때 신경 세포들은 그 시그널을 기억하는 학습 효과가 있음을 바탕으로 최초의 퍼셉트론이 탄생하게 된다.

AI의 첫번째 겨울

허나 퍼셉트론을 통해 AND와 OR 같은 선형 분리가 가능한 문제는 해결할 수 있었지만 XOR 문제에는 적용할 수 없다는 것이 밝혀졌다.

이로 인해 인공지능은 첫번째 겨울을 맞이하게 된다.

XOR 문제란?

선형 모델을 활용하여 OR, AND 문제는 해결할 수 있으나 XOR 문제를 해결할 수 없는 문제를 말한다.

해결 방안

이후 발견된 XOR 문제의 한계를 극복하는 방법은 바로 좌표 평면 자체에 변화를 주는 것이다. 그러기 위해서는 두 개의 퍼셉트론을 한 번에 계산할 수 있어야 한다. 다층 퍼셉트론을 이용하면 은닉층으로 두개의 퍼셉트론을 한번에 계산할 수 있게 되고 은닉층에서 공간을 외곡해 두 영역을 구분하는 직선을 구할 수 있게 되었다.

AI의 두번째 겨울

다중 퍼셉트론과 역전파의 등장으로 XOR 문제가 해결되었으나 신경망이 적용될 수 있는 범위는 한정적이었다. 크고 복잡한 데이터를 다루려면 은닉층을 여러개 연결해야 하는데 이 둘만을 활용해서는 한계가 보이기 시작했다. 또 기울기 소실 문제도 발생하게 되며 AI의 두번째 겨울이 시작된다.

기울기 소실 문제란?

역전파 과정에서 출력층에서 멀어질 수록 기울기 값이 매우 작아지는 현상을 말한다. 이는 활성화 함수의 기울기와 관련이 깊은데 그 중 sigmoid함수를 예시로 들어 자세히 알아보자

아래는 sigmoid 함수의 그래프와 그의 도함수의 그래프 이다.

sigmoid 함수

sigmoid의 도함수

미분 그래프를 확인해보면 sigmoid 함수의 기울기가 최대 0.25이고 최소가 0으로 수렴한다. 역전파에서 입력층에 가까운 앞쪽의 layer로 갈수록 기울기의 값은 거의 0에 가깝게 작아져 가중치 업데이트가 정상적으로 진행되지 않는 것이다.

해결방안

이를 해결하기 위해 ReLU 함수가 등장하였다. ReLU 함수와 그의 도함수 그래프는 아래와 같은데

ReLU 함수 그래프

ReLU의 도함수 그래프

ReLU 함수를 활성화 함수로 사용하면 입력값이 0 이상인 경우 기울기가 0이 되지 않으므로 기울기 소실 문제를 해결할 수 있었다.

현대의 딥러닝

이후 2000년대에 이르러 제프리 힌튼의 Deep Belief Network를 기반으로 비지도학습 방법이 가능해진다. 이로 인해 딥러닝이라는 방법론이 인공신경망이라는 명칭을 대체하며 유일하게 여겨지는 방법론으로 칭해진다. 그 이후 Deep-CNN은 이미지 인식 성능 평가에서 2011년에는 26%의 인식 오류율을 4년만에 3.5%로 개선하는 놀라운 성과를 보였다.

이런 가능성이 나타나자 구글이 딥마인드 사를 인수하며 시장에 뛰어들었고, 알파고를 개발하여 딥러닝이 많은 사람들에게 알려지게 되었다.

그 후 2017년 구글에서는 트랜스포머를 출시하는데, 트랜스포머는 자연어 처리 분야에서 혁신적인 변화를 가져오게 된다.

이와 관련된 내용은 아래 글에서 자세히 알아보도록 하자.

[작성 후 링크 추가 예정]

참고 자료

- https://www.samsungsds.com/kr/insights/091517_cx_cvp3.html
- https://www.letr.ai/ko/blog/story-20211029-1
- https://www.letr.ai/ko/blog/story-20211105-1

어노테이션은 사실 깡통이다.

Potwings — Sun, 22 Sep 2024 19:48:17 +0900

이전글 : https://potwings.tistory.com/66

[Spring MVC] Filter에서 파라미터 처리하는 방법

Servlet의 Filter를 구현하는 Filter클래스에서 POST로 전달되는 Body에서 JSON을 불러와 처리해야할 일이 있었다.따라서 Filter에서 아래와 같이 Request에서 값을 불러왔다. @Override public void doFilter(ServletRequ

potwings.tistory.com

이전 글에서 Request에서 JSON으로 된 파라미터를 불러올 때 아래와 직접 코드 작성하여 파라미터를 받아왔었다.

허나 평소에 Controller에서 JSON을 전달받을 때는 파라미터 앞에 @RequestBody를 추가해주는 것 만으로 불러올 수 있었다.

따라서 @RequestBody는 어떻게 처리를 해주길래 위와 같은 코드를 생략할 수 있는지 궁금해 그 내부를 확인해보게 되었다.

근데 막상 열어보니 RequestBody에는 아무 내용이 없었다.

@Target(ElementType.PARAMETER) // 적용 대상 - 파라미터
@Retention(RetentionPolicy.RUNTIME) // 컴파일러에 의해 class 파일에 기록 & 런타임에 유지
@Documented // javaDoc에 자동으로 기록
public @interface RequestBody {

	boolean required() default true;
}

그렇다면 내용이 아무것도 없음에도 불구하고 @RequestBody는 어떻게 Body의 데이터를 불러와 처리해줄까?

@RequestBody는 단순 마킹 용도이다.

이를 확인하기 위해 그 과정을 직접 디버깅 해보았다.

근데 생각보다 너무 복잡하니 궁금한 사람만 확인해보자

파라미터에 대한 처리를 진행하기 위해서 HandlerMethodArgumentResolverComposite의 resolveArgument 를 진행한다.

  @Nullable
  public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
    HandlerMethodArgumentResolver resolver = this.getArgumentResolver(parameter); // 사용할 resolver 탐색
    if (resolver == null) {
      throw new IllegalArgumentException("Unsupported parameter type [" + parameter.getParameterType().getName() + "]. supportsParameter should be called first.");
    } else {
      return resolver.resolveArgument(parameter, mavContainer, webRequest, binderFactory); // 파라미터 처리
    }
  }

여기서 getArgumentResolver는 해당 파라미터를 처리할 수 있는 resolver를 탐색하는 역할을 한다.

  @Nullable
  private HandlerMethodArgumentResolver getArgumentResolver(MethodParameter parameter) {
    HandlerMethodArgumentResolver result = (HandlerMethodArgumentResolver)this.argumentResolverCache.get(parameter);
    if (result == null) {
      Iterator var3 = this.argumentResolvers.iterator();

      while(var3.hasNext()) {
        HandlerMethodArgumentResolver resolver = (HandlerMethodArgumentResolver)var3.next();
        // 해당 resolver 지원 여부 확인
        if (resolver.supportsParameter(parameter)) {
          result = resolver;
          this.argumentResolverCache.put(parameter, resolver); // 캐싱 진행
          break;
        }
      }
    }

    return result;
  }

이 메소드에서는 파라미터의 어노테이션을 확인하여 어떤 resolver를 통해 처리할지 결정한다.

또 결정 후에는 캐싱 진행하여 이후의 요청에 대해선 좀 더 빠르게 처리할 수 있게 해준다.

RequestBody는 RequestResponseBodyMethodProcessor를 통하여 처리되는데 아래와 같이 파라미터에 RequestBody가 있는지를 확인한다.

  public boolean supportsParameter(MethodParameter parameter) {
    return parameter.hasParameterAnnotation(RequestBody.class);
  }

사용할 resolver를 결정하였으면 이제 resolver의 resolveArgument 메소드를 진행한다.

우리는 RequestBody에 대해 확인하고 있으므로 그 resolver인 RequestResponseBodyMethodProcessor의 resolveArgument메소드를 확인해보자

  public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer, NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {
    parameter = parameter.nestedIfOptional();
    // 파라미터에 대한 처리 진행
    Object arg = this.readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());
    String name = Conventions.getVariableNameForParameter(parameter);
    
    //... 이하 생략
}

여기서는 파라미터들만 확인 후 실제 파라미터에 대한 처리는 readWithMessageConverters에서 진행한다.

이제 실제 처리를 위해 contentType(application/json)과 targetClass(변환할 자바 클래스)를 확인한다.

그리고 resolver를 찾을 때와 동일하게 지원하는 converter를 결정 후 변환을 진행한다.

  @Nullable
  protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter parameter, Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException {

	//... 생략

        HttpMessageConverter converter;
        Class converterType;
        GenericHttpMessageConverter genericConverter;
        while(true) {
          if (!var11.hasNext()) {
            break label94;
          }

          converter = (HttpMessageConverter)var11.next();
          converterType = converter.getClass();
          genericConverter = converter instanceof GenericHttpMessageConverter ? (GenericHttpMessageConverter)converter : null;
          // converter 확인
          if (genericConverter != null) {
            if (genericConverter.canRead(targetType, contextClass, contentType)) {
              break;
            }
          } else if (targetClass != null && converter.canRead(targetClass, contentType)) {
            break;
          }
        }

        if (message.hasBody()) {
          HttpInputMessage msgToUse = this.getAdvice().beforeBodyRead(message, parameter, targetType, converterType);
		  // Converter를 통한 변환 진행
          body = genericConverter != null ? genericConverter.read(targetType, contextClass, msgToUse) : converter.read(targetClass, msgToUse);
          body = this.getAdvice().afterBodyRead(body, msgToUse, parameter, targetType, converterType);
        } else {
          body = this.getAdvice().handleEmptyBody((Object)null, message, parameter, targetType, converterType);
        }

		// ...생략
}

이와 같은 처리를 통해서 @RequestBody는 전달받은 json을 자바 객체로 변환하여준다.

간단히 설명하자면 파라미터에 @RequestBody가 존재하면 해당 파라미터는 변환이 필요하다 체크를 해둔 후 resolver를 통하여 데이터 변환을 진행해주는 것이다.

즉 @RequestBody는 실제 처리를 하는 것이 아닌 "이 파라미터 처리 부탁드려요~" 하는 역할로 보면 되겠다.

그럼 다른 어노테이션은?

java 공식문서의 어노테이션 부분을 확인해보면 (https://docs.oracle.com/javase/tutorial/java/annotations/)

"어노테이션은 주석이 달려있는 코드에 직접적으로 영향을 미치지 않는다." 라고 나와있다.

모든 어노테이션을 확인해보진 못했으나 lombok 같은 경우도 실제 동작하는 내용은 없었다.

결론

어노테이션은 직접 동작하는 주체가 아닌 다른 주체(컴파일러 등등)에게 동작을 요청하는 지시자로 생각하면 되겠다.

Spring Boot main 2배 버그 팝니다@@@@@

Potwings — Wed, 18 Sep 2024 21:21:11 +0900

최근 cli로 된 어플리케이션을 개발하였다.

어플리케이션 실행 후 사용할 DB 정보를 입력을 통하여 받고 싶었으나 Spring의 경우 DataSource가 우선 생성되어야 어플리케이션이 실행될 수 있었다.

따라서 Spring 구동 이전의 main 메소드에서 DB 정보를 받아오도록 아래와 같이 진행하였다.

  public static void main(String[] args) {
    try {

      br = new BufferedReader(new InputStreamReader(System.in));

      String dbUrl = validDBURL(); // IP PORT 연결 테스트
      String schema = validInputString("DB 스키마");
      jdbcUrl = "jdbc:mysql://" + dbUrl + "/" + schema;
      dbUser = validInputString("DB 계정");
      dbPassword = validInputString("DB 패스워드");

      new SpringApplicationBuilder(MainDoubleApplication.class)
          .sources(DataSourceConfig.class)
          .run(args);
    } catch (Exception e) {
      System.err.println("Error: " + e.getMessage() + e);
    }
  }

허나 해당 어플리케이션을 실행해보니 Main 메소드의 내용이 2번 실행 후 Spring이 실행되었다.

검색을 해보니 매번 아무생각없이 추가한 spring-boot-devtools로 인해 main이 두번 실행되고 있던 것이었다.

해당 의존성을 제거하니 정상적으로 Main 메소드 한번 실행 후 Spring이 실행되었다.

왜?

그렇다면 spring-boot-devtools는 왜 main 메소드를 두번 실행할까?

이는 devtools의 핵심 기능인 Automatic Restart 기능을 위해서이다.

※ Automatic Restart - 서비스 기동 중 코드 변경사항 반영

devtools 공식 문서를 보면 이렇게 나와있다.

https://docs.spring.io/spring-boot/reference/using/devtools.html#using.devtools.restart.restart-vs-reload)

정리하자면 아래와 같다.

devtools 사용 시 두 개의 클래스 로더를 사용하여 어플리케이션이 기동된다.
base 클래스로더 - 변경이 발생하지 않는 클래스 관리 (ex. 외부 jar파일)
restart 클래스로더 - 개발을 진행하면서 변경되는 클래스 관리

이후 클래스 변경이 일어나면 기존 restart 클래스로더가 변경된 클래스를 반영한 후 소멸된다. 그 후 새 restart 클래스로더가 생성된다.
이렇게 하면 base 클래스로더에서 관리하는 변경사항이 발생하지 않는 클래스들은 다시 로딩하지 않으므로 restart 시간이 줄어든다.

따라서 빠른 Automatic Restart 진행을 위해 어플리케이션 기동 시 두 개의 클래스 로더를 생성하고 이로 인해 main 메소드가 두번 실행되는 것이다.

테스트

main 메소드가 실행되는 것을 보기 위해 실행 시 "Main Method Run"을 출력하도록 해두었고

@SpringBootApplication
public class MainDoubleApplication {

  public static void main(String[] args) {
    System.out.println("================== Main Method Run ==================");
    new SpringApplicationBuilder(MainDoubleApplication.class)
        .run(args);
  }

}

Controller에서는 "/test" path호출 시 before change를 반환하도록 해두었다.

@RestController
public class TestController {

  @GetMapping("/test")
    public String test() {
        return "before change";
    }
}

초기 실행 후 "/test" 호출 시는 결과는 아래와 같았다.

이후 Controller에서 반환하는 내용을 변경하고 기다려 보니 console 창에는 아래와 같은 로그가 발생하였다.

Main Method Run이 출력되는 걸 보면 새 restart 클래스로더를 생성하기 위해 main 메소드가 다시 실행되었다는 것을 알 수 있었고

이후 "/test"를 호출해보니 Controller의 변경된 내용이 반영되어있었다.

결론

spring-boot-devtools에서는 빠른 Automatic Restart 진행을 위해 어플리케이션 기동 시 두 개의 클래스 로더를 생성한다.

클래스 로더 생성 시 main 메소드를 실행해야하고 이로 인해 main 메소드가 두 번 실행되는 것이다.

텍스트 전처리(1) - 토큰화, 정제, 정규화

Potwings — Tue, 3 Sep 2024 10:03:04 +0900

토큰화

주어진 문장에서의미 부여가 가능한 단위를 찾는 것

단순 공백 기준으로 잘라낼 경우 아래와 같은 이슈가 있다.

단어나 숫자에 특수 문자가 들어가는 경우 존재 (ex. AT&T, $45.55)
줄임말과 단어 내에 띄어쓰기가 있는 경우 존재 (ex. We’re, I’m)

이와 같은 이유로 인해 섬세한 알고리즘이 필요하다.

품사 태깅

단어가 어떤 품사로 사용되었는지 구분해놓는 것. 토큰화 후 진행 가능하다.

어떤 품사로 쓰였는지에 따라 단어의 의미가 달라질 수 있어 진행한다.

ex) fly - [동사 : 날다], [명사 : 파리]

실습

영어 - NLTK 라이브러리 활용

from nltk.tokenize import word_tokenize
from nltk.tag import pos_tag

text = "I'd like to stay at home all day long. I love my house."
tokenized_sentence = word_tokenize(text)

print('단어 토큰화 :',tokenized_sentence)
print('품사 태깅 :',pos_tag(tokenized_sentence))

## 실행 결과 ##
단어 토큰화 : ['I', "'d", 'like', 'to', 'stay', 'at', 'home', 'all', 'day', 'long', '.', 'I', 'love', 'my', 'house', '.']
품사 태깅 : [('I', 'PRP'), ("'d", 'MD'), ('like', 'VB'), ('to', 'TO'), ('stay', 'VB'), ('at', 'IN'), ('home', 'NN'), ('all', 'DT'), ('day', 'NN'), ('long', 'RB'), ('.', '.'), ('I', 'PRP'), ('love', 'VBP'), ('my', 'PRP$'), ('house', 'NN'), ('.', '.')]

한글 토큰화와 그 문제점

한글화 진행 시에는 토큰화에 더 큰 문제점이 있다.

1. 한글은 조사, 어미 등을 붙여서 말을 만드는 교착어이다.

예를 들어 한국어의 ‘그녀(she/her)’라는 주어나 목적어가 들어간 문장이 있다고 해보자. 이 경우 단어에 ‘그녀가’, ‘그녀에게’, ‘그녀를’ 과 같이 다양한 조사가 붙을 것이다. 같은 단어임에도 서로 다른 조사가 붙어 다른 단어로 인식이 되면 자연어 처리가 힘들고 번거로워지는 경우가 많다.

따라서 한국어 자연어 처리에선 조사를 분리해줄 필요가 있고 이를 위해 형태소 기준 토큰화를 진행한다.

2. 한국어는 띄어쓰기가 영어보다 잘 지켜지지 않는다.

Tobeornottobethatisthequestion

영어는 띄어쓰기가 없으면 쉽게 알아보기 힘들다.

제가이렇게띄어쓰기를전혀하지않고글을썼다고하더라도글을이해할수있습니다.

반면 한국어는 띄어쓰기가 되지 않아도 어느 정도 내용을 알아볼 수 있다.

이로 인해 띄어쓰기가 무시되는 경우가 많아져 자연어 처리에 어려움을 겪는다.

KoNLPy 라이브러리 활용하여 진행하며 KoNLPy 형태소 분석기들은 공통적으로 아래 메소드 제공한다.

morphs : 형태소 추출
pos : 품사 태깅(Part-of-speech tagging)
nouns : 명사 추출

from konlpy.tag import Okt

okt = Okt()
text = "아 퇴근하고 싶다. 월요일부터 집에 가고 싶다니 완전 럭키비키잖아"

# OKT 형태소 분석기 사용
print('OKT 형태소 분석 :',okt.morphs(text))
print('OKT 품사 태깅 :',okt.pos(text))
print('OKT 명사 추출 :',okt.nouns(text))

## 실행 결과 ##
OKT 형태소 분석 : ['아', '퇴근', '하고', '싶다', '.', '월요일', '부터', '집', '에', '가고', '싶다니', '완전', '럭키', '비키잖아']
OKT 품사 태깅 : [('아', 'Exclamation'), ('퇴근', 'Noun'), ('하고', 'Josa'), ('싶다', 'Verb'), ('.', 'Punctuation'), ('월요일', 'Noun'), ('부터', 'Josa'), ('집', 'Noun'), ('에', 'Josa'), ('가고', 'Verb'), ('싶다니', 'Verb'), ('완전', 'Noun'), ('럭키', 'Noun'), ('비키잖아', 'Verb')]
OKT 명사 추출 : ['퇴근', '월요일', '집', '완전', '럭키']

어떤 형태소 분석기를 사용하느냐에 따라 결과가 다르게 나온다.

필요 용도에 어떤 형태소 분석기가 가장 적절한지 판단하여 사용하면 된다.

from konlpy.tag import Kkma

kkma = Kkma()
text = "아 퇴근하고 싶다. 월요일부터 집에 가고 싶다니 완전 럭키비키잖아"

# 꼬꼬마 형태소 분석기 사용
print('꼬꼬마 형태소 분석 :',kkma.morphs(text))
print('꼬꼬마 품사 태깅 :',kkma.pos(text))
print('꼬꼬마 명사 추출 :',kkma.nouns(text))

## 실행 결과 ##
꼬꼬마 형태소 분석 : ['I', "'", 'd', 'like', 'to', 'stay', 'at', 'home', 'all', 'day', 'long', '.', 'I', 'love', 'my', 'house', '.']
꼬꼬마 품사 태깅 : [('I', 'OL'), ("'", 'SS'), ('d', 'OL'), ('like', 'OL'), ('to', 'OL'), ('stay', 'OL'), ('at', 'OL'), ('home', 'OL'), ('all', 'OL'), ('day', 'OL'), ('long', 'OL'), ('.', 'SF'), ('I', 'OL'), ('love', 'OL'), ('my', 'OL'), ('house', 'OL'), ('.', 'SF')]
꼬꼬마 명사 추출 : []

문장 토큰화

문장단위로 의미를 나누기 위해 사용한다.

영어 - NLTK의 from nltk.tokenize import sent_tokenize 로 진행

from nltk.tokenize import sent_tokenize

text = "His barber kept his word. But keeping such a huge secret to himself was driving him crazy. Finally, the barber went up a mountain and almost to the edge of a cliff. He dug a hole in the midst of some reeds. He looked about, to make sure no one was near."
print('문장 토큰화1 :',sent_tokenize(text))

## 실행 결과 ##
문장 토큰화1 : ['His barber kept his word.', 'But keeping such a huge secret to himself was driving him crazy.', 'Finally, the barber went up a mountain and almost to the edge of a cliff.', 'He dug a hole in the midst of some reeds.', 'He looked about, to make sure no one was near.']

한글 - KSS(Korean Sentence Splitter)를 추천

pip install kss # 패키지 설치

import kss

text = '딥 러닝 자연어 처리가 재미있기는 합니다. 그런데 문제는 영어보다 한국어로 할 때 너무 어렵습니다. 이제 해보면 알걸요?'
print('한국어 문장 토큰화 :',kss.split_sentences(text))

## 실행 결과 ##
한국어 문장 토큰화 : ['딥 러닝 자연어 처리가 재미있기는 합니다.', '그런데 문제는 영어보다 한국어로 할 때 너무 어렵습니다.', '이제 해보면 알걸요?']

정규화

표현 방법이 다른 단어들을 같은 단어로 통합하는 작업

정규화 기법

규칙에 기반한 표기가 다른 단어들의 통합

같은 의미를 가지고 있으나 표기가 다른 단어들을 하나의 단어로 정규화할 수 있다.
ex) (US, USA), (uh-huh, uhhuh)

대, 소문자 통합

대, 소문자를 통합할 경우 단어의 개수를 줄일 수 있다. 영어에서 대부분은 소문자로 작성되므로 소문자 변환 작업으로 이루어진다.
떄론 무작정 대문자와 소문자가 구분되어야하는 상황도 있다.
대안으로 문장의 맨앞의 단어만 대문자로 변경하고 나머지는 대,소문자 유지하는 방법이 있다.

표제어 추출

단어들로부터 표제어(기본 사전형 단어)를 추출하는 행위 어간과 접사로 단어를 나누어 준다.

from nltk.stem import WordNetLemmatizer

lemmatizer = WordNetLemmatizer()

words = ['policy', 'doing', 'organization', 'have', 'going', 'love', 'lives', 'fly', 'dies', 'watched', 'has', 'starting']

print('표제어 추출 전 :',words)
print('표제어 추출 후 :',[lemmatizer.lemmatize(word) for word in words])

## 실행 결과 ##
표제어 추출 전 : ['policy', 'doing', 'organization', 'have', 'going', 'love', 'lives', 'fly', 'dies', 'watched', 'has', 'starting']
표제어 추출 후 : ['policy', 'doing', 'organization', 'have', 'going', 'love', 'life', 'fly', 'dy', 'watched', 'ha', 'starting']

추출 결과에서의 dy와 ha처럼 의미를 알 수 없는 적절하지 못한 단어가 있다. 이런 경우 본래 단어의 품사 정보를 알아야 정확한 결과를 얻을 수 있다.
```
print(lemmatizer.lemmatize('dies', 'v'))
print(lemmatizer.lemmatize('watched', 'v'))
print(lemmatizer.lemmatize('has', 'v'))
```
```
## 실행 결과 ##
die
watch
have
```

어간 추출

표제어 추출보다 일반적으로 속도가 빠르다. 그 중 포터 어간 추출기는 정밀하게 설계되어 정확도가 높아 영어 자연어 처리에서 준수한 선택이다.그 외에도 NLTK에는 랭커스터 스태머 알고리즘이 있다.

from nltk.stem import PorterStemmer
from nltk.stem import LancasterStemmer

porter_stemmer = PorterStemmer()
lancaster_stemmer = LancasterStemmer()

words = ['policy', 'doing', 'organization', 'have', 'going', 'love', 'lives', 'fly', 'dies', 'watched', 'has', 'starting']
print('어간 추출 전 :', words)
print('포터 스테머의 어간 추출 후:',[porter_stemmer.stem(w) for w in words])
print('랭커스터 스테머의 어간 추출 후:',[lancaster_stemmer.stem(w) for w in words])

## 실행 결과 ##
# 둘은 서로 다른 알고리즘을 사용하기 때문에 다른 결과가 나온다
어간 추출 전 : ['policy', 'doing', 'organization', 'have', 'going', 'love', 'lives', 'fly', 'dies', 'watched', 'has', 'starting']
포터 스테머의 어간 추출 후: ['polici', 'do', 'organ', 'have', 'go', 'love', 'live', 'fli', 'die', 'watch', 'ha', 'start']
랭커스터 스테머의 어간 추출 후: ['policy', 'doing', 'org', 'hav', 'going', 'lov', 'liv', 'fly', 'die', 'watch', 'has', 'start']

허나 이런 규칙에 기반한 어간 추출은 제대로 된 일반화를 수행하지 못할 수도 있다.
ex) organization → organ (완전히 다른 단어임에도 이와 같이 어간 추출이 된다)

정제

갖고 있는 말뭉치로부터 불필요한 데이터를 제거한다.

정제 방식의 예시

등장 빈도가 적은 단어 제거

입력 받은 데이터 100000건 중에서 5번밖에 등장하지 않은 단어가 있다면 이는 직관적으로 분류에 도움이 되지 않는 데이터임을 알 수 있다.

길이가 짧은 단어 제거

영어에서는 길이가 짧은 단어의 대부분이 불용어라 제거하는 의미가 있다. 또 구두점들까지도 한번에 제거할 수 있다.
허나 한국어에서는 크게 유효하지 않을 수 있다. 이는 영어와 한국어 단어에서 각 한 글자가 가진 의미의 크기가 다르기 때문이다.

불용어 제거

큰 의미가 없는 단어(분석에 큰 도움이 되지 않음)를 제거한다.

예시

from nltk.corpus import stopwords
from nltk.tokenize import word_tokenize 

example = "Family is not an important thing. It's everything."
stop_words = set(stopwords.words('english')) 

word_tokens = word_tokenize(example)

result = []
for word in word_tokens: 
    if word not in stop_words: 
        result.append(word) 

print('불용어 제거 전 :',word_tokens) 
print('불용어 제거 후 :',result)

## 실행 결과 ##
불용어 제거 전 : ['Family', 'is', 'not', 'an', 'important', 'thing', '.', 'It', "'s", 'everything', '.']
불용어 제거 후 : ['Family', 'important', 'thing', '.', 'It', "'s", 'everything', '.']

한국어에서 불용어 제거 예시 [한국어 불용어 리스트 : https://www.ranks.nl/stopwords/korean]

from konlpy.tag import Okt

okt = Okt()

example = "고기를 아무렇게나 구우려고 하면 안 돼. 고기라고 다 같은 게 아니거든. 예컨대 삼겹살을 구울 때는 중요한 게 있지."
stop_words = "를 아무렇게나 구 우려 고 안 돼 같은 게 구울 때 는"

stop_words = set(stop_words.split(' '))
word_tokens = okt.morphs(example)

result = [word for word in word_tokens if not word in stop_words]

print('불용어 제거 전 :',word_tokens) 
print('불용어 제거 후 :',result)

## 실행 결과 ##
불용어 제거 전 : ['고기', '를', '아무렇게나', '구', '우려', '고', '하면', '안', '돼', '.', '고기', '라고', '다', '같은', '게', '아니거든', '.', '예컨대', '삼겹살', '을', '구울', '때', '는', '중요한', '게', '있지', '.']
불용어 제거 후 : ['고기', '하면', '.', '고기', '라고', '다', '아니거든', '.', '예컨대', '삼겹살', '을', '중요한', '있지', '.']

참고 원문 : https://wikidocs.net/21694

02. 텍스트 전처리(Text preprocessing)

텍스트 전처리는 풀고자 하는 문제의 용도에 맞게 텍스트를 사전에 처리하는 작업입니다. 요리를 할 때 재료를 제대로 손질하지 않으면, 요리가 엉망이 되는 것처럼 텍스트에 제대로 전…

wikidocs.net

[Spring MVC] Filter에서 파라미터 처리하는 방법

Potwings — Thu, 1 Aug 2024 21:26:38 +0900

Servlet의 Filter를 구현하는 Filter클래스에서 POST로 전달되는 Body에서 JSON을 불러와 처리해야할 일이 있었다.

따라서 Filter에서 아래와 같이 Request에서 값을 불러왔다.

  @Override
  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
  
	ServletInputStream inputStream = request.getInputStream();
	ObjectMapper objectMapper = new ObjectMapper();
	PersonDTO dto = objectMapper.readValue(inputStream, PersonDTO.class);
	System.out.println("name: " + dto.getName());
	chain.doFilter(request, response);
  }

허나 이 코드에는 문제가 있는데...

Request의 Body는 InputStream으로 이루어져있어 한 번 데이터를 읽으면 다시 사용할 수 없다.

이로 인해 Body의 값을 이미 Filter에서 한 번 사용하면 Controller에서는 정상적으로 값을 불러올 수 없었다.

해결 방법

이에 대한 해결법으로는 Body의 값을 읽어와 저장해둔 후 여러번 사용하는 방법이 있었다.

(참고 : https://www.baeldung.com/spring-reading-httpservletrequest-multiple-times)

HttpServletRequestWrapper을 상속받은 클래스를 구현하여 이 작업을 진행한다.

기존 Request의 Body는 한번밖에 못 불러오므로

해당 값을 불러와 RequestWrapper의 클래스 변수(requestData)로 저장해둔 후 여러번 사용한다.

public class RequestWrapper extends HttpServletRequestWrapper {

	//기존 Request의 Body 불러와 저장해두는 변수
	private String requestData;

	public RequestWrapper(HttpServletRequest request) throws IOException {
	  super(request);
	  requestData = requestDataByte(request);
	}

	private String requestDataByte(HttpServletRequest request) throws IOException {
	  ServletInputStream inputStream = request.getInputStream();
	  byte[] rawData = StreamUtils.copyToByteArray(inputStream); //Body 복제 진행
	  return new String(rawData);
	}

	@Override
	public ServletInputStream getInputStream() {
      // requestData에 있는 값 Stream으로 변환하여 return
	  ByteArrayInputStream inputStream = new ByteArrayInputStream(
	      this.requestData.getBytes(StandardCharsets.UTF_8));
	  return new ServletInputStream() {
	    @Override
	    public boolean isFinished() {
	      return inputStream.available() == 0;
	    }

	    @Override
	    public boolean isReady() {
	      return true;
	    }

	    @Override
	    public void setReadListener(ReadListener listener) {
	      throw new UnsupportedOperationException();
	    }

	    @Override
	    public int read() {
	      return inputStream.read();
	    }
	  };
	}

	@Override
	public BufferedReader getReader() {
	  return new BufferedReader(new InputStreamReader(this.getInputStream()));
	}
}

또 Filter 작업 완료 후 이후에 Request를 사용하는 작업에서 RequestWrapper를 사용할 수 있도록

chain.doFilter() 시 기존 Request가 아닌 RequestWrapper를 전달해준다.

public class CommonFilter implements Filter {
	....

	@Override
	public void doFilter(ServletRequest request, ServletResponse response,
	    FilterChain chain) throws IOException, ServletException {
	  // 필터 로직
	  HttpServletRequest httpRequest = (HttpServletRequest) request;
	  RequestWrapper requestWrapper = new RequestWrapper(httpRequest);
	  String method = httpRequest.getMethod();
	  try {
	    if (method.equals("POST")) {
	      ServletInputStream inputStream = requestWrapper.getInputStream();
	      ObjectMapper objectMapper = new ObjectMapper();
	      PersonDTO dto = objectMapper.readValue(inputStream, PersonDTO.class);
	      System.out.println("name: " + dto.getName());
	    }
	  } catch (Exception e) {
	    e.printStackTrace();
	  }

	  chain.doFilter(requestWrapper, response); //requestWrapper를 전달
	}
...
}

이렇게하면 Filter와 Controller 모두에서 Request의 Body값을 불러와 사용할 수 있었다.

작업 코드

https://github.com/Potwings/filter_want_request

GitHub - Potwings/filter_want_request: 필터는 request가 보고 싶다

필터는 request가 보고 싶다. Contribute to Potwings/filter_want_request development by creating an account on GitHub.

github.com

문자열 탐색 성능 개선

Potwings — Thu, 30 May 2024 22:01:05 +0900

필자는 웹메일 업체에서 스팸 차단 솔루션 개발을 담당하고 있다.

스팸 차단 솔루션의 특성상 관리자/사용자가 등록한 필터들을 활용한 많은 문자열 탐색이 일어난다.

이 기능을 개선하면 솔루션의 성능이 크게 향상될 것이라고 판단하여 진행하게 되었다.

우선 결론부터 말하자면 패턴 매칭의 성능 개선은 진행되지 못하였다.

허나 누군가가 나와 같은 고민을 하고 있을 경우 도움을 받을 수 있도록, 또 나와 같은 실수를 하지 않도록 하기 위해 기록하고자 한다.

시작 - 어떻게 개선하려 하였는가?

우선 회사에서 열심히 놀고 있는 도중 우아한형제 블로그의 아래 글을 보게 되었다.

https://techblog.woowahan.com/15764

고르곤졸라는 되지만 고르곤 졸라는 안 돼! 배달의민족에서 금칙어를 관리하는 방법 | 우아한형

{{item.name}} 안녕하세요! 셀러시스템팀에서 서버 개발을 하고 있는 김예빈이라고 합니다. 배달의민족에는 금칙어를 관리하는 "통합금칙어시스템"이라는 것이 있습니다. 금칙어란? 법 혹은 규칙으

techblog.woowahan.com

배민에서 금칙어 시스템을 어떻게 개선했는지에 대한 이야기였는데 그중 금칙어 찾아내기 부분의 내용을 보다 흠칫했다.

현재 우리 솔루션에서는 문자열 탐색은 String.contains(== String.indexOf)를 통하여 진행하고 있었고 성능이 좋지 않다는 것도 이미 알고 있었다.

따라서 배민에서 진행한 내용을 참고하여 아호코라식 알고리즘을 적용해 개선하고자 하였다.

1차 시도 - 아호코라식 알고리즘

아호코라식 알고리즘이란?

존재 여부를 확인할 문자열(이하 패턴)들을 Trie로 만들어둔 후

검사 대상 문자열(이하 원문)이 Trie를 따라가며 일치, 불일치 여부를 확인하는 것이다.

출처 : https://techblog.woowahan.com/15764

기존 패턴 매칭의 경우 패턴 하나당 한 번씩 원문과 매칭을 진행하므로 시간복잡도가 O(m(n1+n2+n3...))이다.

반면 아호코라식으로 진행할 경우 원문을 생성해 둔 Trie에 한 번만 대입하면 되므로 O(m+n1+n2+n3...)이 된다.

마침 자바에 아호코라식 라이브러리가 존재하여 이를 활용하였고

본문의 길이가 21397자인 메일 원문을 기준으로 100개의 문자열을 포함여부에 대해 테스트해 보았다.

기존(String contains)

아호코라식

기존의 방식은 36ms가 소요되었고 아호코라식을 활용할 경우 5ms가 소요되어 약 7배의 정도 성능이 더 좋았다.

여기까지 테스트하고 이제 적용하려 하였으나......

성능 개선 작업을 진행하던 중 운영 측에서 사칭 메일을 탐지하지 못한다는 신고가 접수되었다.

필터링 성능은 당장 서비스에 영향을 주는 문제가 아니었던 반면, 사칭 메일 차단은 즉시 해결이 필요한 사안이라 판단하여 복합 조건 필터 기능 개발을 먼저 진행하게 되었다.

복합 조건 필터 작업의 내용은 아래와 같다.

작업 전
각 필터당 하나의 조건으로 문자열 검사 진행 - 하나의 조건만 충족되면 해당 필터에 매칭
ex) 1번 조건(제목에 Test가 포함되는 경우) => 차단

작업 후
각 필터 당 여러 개의 조건으로 문자열 검사 진행 - 필터에 있는 모든 조건이 충족해야 해당 필터에 매칭
ex) 1번 조건(제목에 Test가 포함되는 경우), 2번 조건(아이디가 potwings로 시작되는 경우) => 1, 2번 모두 충족해야 차단

이전의 구조에서는 필터 하나에 조건이 하나 있어, 메일이 하나의 조건에만 충족할 경우 해당 조건을 가지고 있는 필터에 탐지된 것으로 처리하면 되었다.

따라서 "특정 문자를 포함하면"인 조건들로만 Trie를 생성하면 되었다.

허나 변경된 구조에서는 필터 하나에 여러 개의 조건이 있어, 특정 조건에 부합하는 경우에만 그다음 조건을 검사해야 한다.

예시를 통하여 설명해 보자, 아래와 같이 세 가지 조건을 가진 필터가 있다고 생각해 보자

1. 제목에 "subject"를 포함
2. 아이디에 "test"와 일치
3. 본문 "naver.com"을 포함

우선 제목에 대한 패턴들로 만들어 Trie를 통하여 1번 조건에 충족되었다 하자

그럼 그 후 2번 조건에 의해 아이디에 대해서는 test와 일치하는지 확인해야 하고 그다음 3번 조건으로 확인해야 한다.

따라서 본문 "naver.com"을 포함 조건은 1번, 2번 조건을 충족하는 경우에만 확인을 진행해야 하므로 Trie에 포함시킬 수 없다.

1번 조건들로만 Trie를 생성하면 어떨까? 도 생각하였으나.

1번 조건에 "포함하면"이 아닌 다른 조건들이 오는 경우가 많아 효율적이지 못하다 판단해 진행하지 않았다.

위와 같은 이유들로 인해 아호코라식을 적용할 수 없게 되었다.

2차 시도 - KMP 알고리즘

진행해야 하는 작업이 일대다 패턴 매칭이라 아호코라식보다는 성능이 좋지는 않으나

KMP 알고리즘을 활용하면 일대일 매칭에서 String의 contains(브루트 포스)보다는 성능이 좋다 하여 고려해 보았다.

KMP 알고리즘이란?

문자열 비교 시 효율적인 인덱스 조정을 통해 이미 비교했던 문자열을 최대한 다시 비교하지 않도록 하여 성능을 개선한 문자열 탐색 알고리즘이다.

KMP 알고리즘의 자세한 내용은 아래 글에 따로 정리해 두었다.

https://potwings.tistory.com/65

KMP - 문자열 탐색 알고리즘 (By Java)

문자열 탐색 성능 개선 중 KMP알고리즘을 사용하면 기존의 브루트포스 알고리즘보다 더 좋은 성능이 나온다는 이야기를 들었다.정확히 어떻게 성능을 더 빠르게 하는지가 궁금하여 자세한 내용

potwings.tistory.com

KMP 알고리즘은 자체의 index 조절 방식을 통하여 비교를 횟수를 줄이기 때문에 성능이 더 좋을 것이라 예상하였다.

허나 테스트 결과는 예상과 달리 String contains의 성능이 더 좋았다.

String contains보다 수행 시간이 무려 10배나 늘어났다.

왜 그럴까?

1. 혹시 String의 contains는 브루트 포스가 아닌 성능이 더 좋은 방식을 사용할까?

아니다 String의 contains(== indexOf)는 브루트포스 방식으로 비교하고 있었다.

// 브루트포스 방식으로 비교 진행중
public static int indexOf(byte[] value // 검사 대상 , int valueCount, byte[] str // 패턴, int strCount, int fromIndex) {
    byte first = str[0]; // 패턴의 처음 문자
    int max = (valueCount - strCount); // 둘의 길이 차이의 최대
    for (int i = fromIndex; i <= max; i++) {
        // Look for first character.
        if (value[i] != first) { // 패턴의 처음 문자와 일치하지 않는 경우 일치하는 문자가 나올 때까지 skip
            while (++i <= max && value[i] != first); 
        }
        // 패턴의 처음 문자를 찾을 경우 다음 매칭 진행
        if (i <= max) {
            int j = i + 1; // 패턴의 두번째 문자부터 비교 진행
            int end = j + strCount - 1; // 패턴과 비교해야하는 부분 문자열 마지막 인덱스
            for (int k = 1; j < end && value[j] == str[k]; j++, k++); // j,k를 증가시키며 비교 진행 불일치하면 중단
            if (j == end) {
                // 위의 반복문에서 패턴의 끝까지 비교가 완료되었을 경우 시작 인덱스 반환
                return i;
            }
            // 만일 도중에 불일치 발생했을 경우 다시 i를 증가시키며 비교 진행
        }
    }
    return -1;
}

2. KMP 알고리즘은 존재 여부만 판단할 경우 오히려 성능이 안 좋다.

만일 존재 여부만 판단하면 전체 문자열을 확인할 필요 없이 문자열 일치가 발생하면 탐색을 중단하면 된다.

허나 KMP의 경우 탐색을 진행하기 전 전체 문자열을 확인하여 lps 배열을 생성한다.

이때 불필요한 작업이 발생하기 때문에 오히려 contains보다 성능이 저하되는 것이었다.

허나 여기서 이상한 점이 있었다.

원문이 패턴을 포함하고 있지 않은 경우 전체 탐색을 진행하므로 KMP가 성능이 더 좋아야 하는데도 성능이 contains보다 떨어지는 경우가 발생하였다.

그래서 원인을 더 찾아봤는데...

3. JIT 컴파일러가 String의 indexOf의 성능을 향상시켜준다.

JIT(Just-In Time Compiler) 컴파일러란?

초기의 자바는 모든 바이트 코드를 실행 전 직접 기계어로 번역 후 실행해 성능이 떨어졌다.

이를 개선하기 위해 JIT 컴파일러가 등장하였고, 자주 쓰이는 메소드는 바이트 코드를 번역해 실행하는 것이 아닌 기계어로 캐싱해 둔 코드를 실행하여 성능을 개선하였다.

String의 contains에서 사용하는 indexOf는 여러 메소드에서도 이미 불러와 사용하고 있는 상태였고, 그로 인하여 JIT 컴파일러에 등록되어 있어 더 좋은 성능으로 실행될 수 있었던 것이다.

마치며

비록 이번에는 성능 개선을 이루지는 못했지만, 생각으로만 가지고 있던 "좋은 알고리즘을 활용하여 성능을 이렇게 개선할 수 있겠다"는 것을 직접 시도해 볼 수 있는 좋은 경험이었다.

향후 다른 기능에 적절한 알고리즘을 접목시킬 기회가 있다면, 확실한 결과물을 남길 수 있기를 기대한다.

추가로 글로 작성해 보니 작업할 땐 미처 생각하지 못했던 부분들에 대해 고려해 볼 수 있어 좀 더 많은 것들을 공부할 수 있었다. 앞으로도 꾸준히 기록하는 습관을 가져야겠다.

KMP - 문자열 탐색 알고리즘 (By Java)

Potwings — Wed, 29 May 2024 20:17:33 +0900

문자열 탐색 성능 개선 중 KMP알고리즘을 사용하면 기존의 브루트포스 알고리즘보다 더 좋은 성능이 나온다는 이야기를 들었다.

정확히 어떻게 성능을 더 빠르게 하는지가 궁금하여 자세한 내용을 정리해보고자 한다.

이 글은 아래 글을 참고하여 작성하였다.

https://bowbowbow.tistory.com/6

KMP : 문자열 검색 알고리즘

문자열 검색이 뭐지? 워드프로세서를 사용할 때 찾기 기능을 사용한적 있을 겁니다. 브라우저에서도 Ctrl+F 단축키를 눌러 검색할 수 있습니다. 아래 이미지는 브라우저에서 "테이프"를 검색했을

bowbowbow.tistory.com

KMP 알고리즘이란?

문자열 비교 시 효율적인 인덱스 조정을 통해 이미 비교했던 문자열을 최대한 다시 비교하지 않도록 하여 성능을 개선한 문자열 탐색 알고리즘이다.

더 자세한 설명을 위해 아래 예시를 통해 알아보자

우리는 ABAABAABAABAB라는 텍스트에서 ABAABAB 패턴을 찾는 작업을 진행할 것이다.

패턴(찾을 문자) : ABAABAB
텍스트(탐색 대상) : ABAABAABAABAB

브루트 포스 알고리즘(단순 문자열 탐색)을 활용한 문자열 탐색

KMP가 얼마나 효율적으로 동작하는지 확인하기에 위해 우선 브루트 포스 방식으로 문자열 탐색 진행 과정을 확인해보자

처음 비교를 시작하면 텍스트의 0번째 인덱스부터 순서대로 비교하다 아래와 같이 6번째 인덱스에서 불일치가 발생한다.

인덱스

텍스트

패턴

그 다음번에는 비교 시작 인덱스 +1한 텍스트의 1번째 인덱스부터 비교를 진행한다.

인덱스

텍스트

패턴

허나 시작하자마자 불일치가 발생해 바로 비교 시작 인덱스 +1 하여 텍스트의 2번 인덱스에 대한 비교를 진행할 것이다.

인덱스

텍스트

패턴

위와 같이 계속 비교 시작 인덱스를 1씩 증가시키면서 진행하다 6번째 검사 진행 시 텍스트의 일치하는 부분을 찾게 된다.

인덱스

텍스트

패턴

즉 텍스트에 패턴 존재여부를 확인하기 위해 6번의 문자열 비교가 발생한 것이다.

뿐만 아니라 텍스트가 길어질 경우 비교 작업이 배로 많아지며 시간복잡도는 O(n*m) [n: 텍스트의 길이, m : 패턴의 길이]이다.

KMP 알고리즘을 활용한 문자열 탐색

KMP 알고리즘을 활용하여 문자열 탐색을 진행할 경우 두 단계로 나누어 진행한다.

1. 패턴에 대한 접두사 접미사 최대 길이 배열(Longest Prefix Suffix 이하 lps) 배열을 생성

lps배열은 패턴의 0~i까지의 부분 문자열에서 서로 일치하는 prefix, suffix 중 가장 긴 것의 길이이다.

(단 prefix와 suffix는 부분 문자열의 전체가 되면 안된다)

현재 패턴에서 i = 5일 경우를 확인해 보자, 부분 문자열은 ABAABA이고 prefix와 suffix 집합은 아래와 같다.

prefix : {A, AB, ABA, ABAA, ABAAB}

suffix : {A, BA, ABA, AABA, BAABA}

prefix와 suffix가 일치하는 값은 A, ABA이고 이 중 가장 긴 것은 ABA이다. 따라서 lps[5] = 3이 된다.

lps 배열의 전체는 아래와 같다.

i	부분 문자열	lps[i]
0	A	0
1	AB	0
2	ABA	1
3	ABAA	1
4	ABAAB	2
5	ABAABA	3
6	ABAABAB	2

이제 생성한 배열을 활용하여 문자열 탐색을 해보자

2. lps 배열을 활용한 문자열 탐색

우선 처음은 브루트 포스와 동일하게 텍스트의 0번째 인덱스부터 비교를 진행한다.

인덱스

텍스트

패턴

첫 번째 매칭을 하는 과정에서 6번째에서 불일치가 발생하였다. 이를 통해 5번째 인덱스까지는 문자열이 일치한다는 점도 확인할 수 있다.

여기서 1번에서 생성해 둔 lps 배열을 참고하면 lps[5] = 3이므로 패턴의 0~5 인덱스의 부분 문자열에서 prefix와 suffix가 3개 일치한다는 것을 알 수 있다.

이를 활용하여 다음번 검사 시 패턴 시작을 텍스트의 3번째 인덱스로 조정한다.

또 인덱스 3,4,5는 이미 패턴과 일치하다는 것을 알고 있으므로 6번 인덱스부터 비교를 진행하면 된다.

허나 이번에도 패턴의 6번째 인덱스 즉 텍스트의 9번째 인덱스에서 불일치가 발생하였고, 이전과 마찬가지로 인덱스 조정을 진행할 수 있다.

그 다음 패턴 시작을 텍스트의 6번째 인덱스로 조정하였고, 이번에는 패턴과 문자열이 일치하는 부분을 찾게 되었다.

KMP 알고리즘을 활용하니 3번 만에 해당 문자열을 찾을 수 있었고, 6번 걸렸던 브루트 포스보다 비교 횟수가 무려 절반이 줄었다.

또한, 효율적인 인덱스 조정으로 인해 문자열 비교 횟수가 감소하여 시간 복잡도가 O(n + m)으로 개선된다.

자바 코드로의 구현

이제 KMP 알고리즘을 자바 코드로 어떻게 구현하는지 확인해 보자.

비교할 때와 동일하게 패턴에 대한 lps배열을 생성, lps 배열을 활용한 문자열 탐색 총 두 단계로 나뉜다.

1. 패턴에 대한 lps배열 생성

 public static int[] makeLps(String pattern) {
    int n = pattern.length();
    int[] lps = new int[n];

    int idx = 0; // 비교할 prefix의 인덱스

    // 부분 문자열의 크기 증가시키며 비교 진행
    for (int i = 1; i < n; i++) {

      while (idx > 0 && pattern.charAt(i) != pattern.charAt(idx)) {
        // 문자열이 연속 일치가 발생했을 때(idx>0), 연속적으로 더 일치하지 않으면 인덱스 조정
        /*
         * idx = lps[idx-1]으로 조정하는 이유
         * 문자열 탐색 시 lps 배열을 참고하여 인덱스 조정을 진행하는 것과 동일하게 생각하면된다
         * prefix는 패턴, 부분 문자열은 text라 생각하면 된다.
         */
        idx = lps[idx - 1];
      }

      if (pattern.charAt(i) == pattern.charAt(idx)) {
        idx++; // 문자열이 일치할 경우 연속으로 일치하는지 확인하기 위해 idx를 증가시킨다.
        lps[i] = idx; // 지금까지 일치한 개수 lps 배열에 저장
      }
    }
    return lps;
  }

2. lps 배열을 활용한 문자열 탐색

  public static void kmp(String text, String pattern) {

    int[] lps = makeLps(pattern); // lps 배열 생성

    int idx = 0; // 비교할 패턴의 현재 인덱스
    
    // text의 인덱스를 증가시키며 비교 진행
    for (int i = 0; i < text.length(); i++) {
      while (idx > 0 && text.charAt(i) != pattern.charAt(idx)) {
        // 패턴과 text 불일치 시 lps 배열을 활용하여 인덱스 조정
   		// 이전에 검사 시 패턴과 일치한 부분의 suffix를 prefix라 생각하고 인덱스 조정
        idx = lps[idx - 1]; 
      }

      if (text.charAt(i) == pattern.charAt(idx)) {
        // 글자가 일치할 경우
        if (idx == pattern.length() - 1) {
          // 패턴의 끝까지 비교한 경우
          System.out.println("패턴 시작 위치: " + (i - idx + 1) + ", " + "패턴 끝 위치: " + (i + 1));
          idx = lps[idx]; // 다음 비교를 위하여 인덱스 조정
        } else {
          // 패턴의 끝이 아닌 경우 패턴의 다음 값 확인하기 위해 idx++
          idx++;
        }
      }
    }
  }