기운바다

java 로 web application server 를 개발할때 주로 사용하는 was 로는 tomcat 과 jetty 가 있다.

이들은 사용자 세션 관리 환경을 제공하여 사용자별로 개인화된 데이터 관리가 가능하게끔 설계 되어 있다.

그리고 이들은 '서블릿 표준 세션 인터페이스'인 jakarta.servlet.http.HttpServletRequest 의 getSession() 함수를 이용하여 jakarta.servlet.http.HttpSession 의 인스턴스를 취할 수 있다. 

그런데 위 표준 인터페이스 외에 다른 형태의 세션 인터페이스가 있는지 궁금하였고, gpt 에게 그것을 물어보게 되었는데 각 was 들은 표준 세션 인터페이스의 구현체로 별도의 내장 클래스가 존재 하는 것을 알게 되었다.

다음은 주요 웹 어플리케이션 서버들에 대한 내장 세션 클래스 목록이다.

그 외에 GlassFish, Payara, WildFly(JBoss) 서버들이 있는데 위와 유사하다.

위 서버들의 세션 클래스들은 내장된 고유의 클래스들로써 표준 인터페이스를 구현한 구현체이기 때문에 해당 내장 객체를 개발자가 직접 제어하는 경우는 흔치 않다고 한다.

그래서 위에 나오는 서버들은 모두 '서블릿 표준 세션 인터페이스'를 사용하여 세션 객체에 접근하여 제어하면 된다. 

하지만 '서블릿 표준 세션 인터페이스'를 지원하지 않아서 getSession() 사용이 불가한 was도 있다고 gpt가 알려주었다.

그래서 getSession() 함수가 불가한 was 또는 경우를 물어보니 다음의 경우는 사용이 불가하다고 한다.

getSession() 사용 불가 또는 제한

일반적으로 모든 Servlet 기반 WAS에서 지원되지만, 다음과 같은 경우 getSession()이 정상적으로 동작하지 않을 수 있습니다.

1. Session 관리가 비활성화된 경우
   • web.xml 또는 application.properties에서 session-config가 비활성화되어 있는 경우
   • Spring Boot에서 server.servlet.session.timeout=0 설정 시
2. Undertow가 Servlet 모드가 아닌 경우
   • Undertow는 기본적으로 Non-Blocking 서버로 동작하며, servlet 모듈을 명시적으로 추가해야 getSession() 사용 가능
   • Gradle에서 아래처럼 추가해야 함:
      

     dependencies {

         implementation("io.undertow:undertow-servlet")

     }
3. Netty 기반 서버 사용 시
   • Netty는 Servlet 기반이 아니므로 getSession()을 직접 사용할 수 없음
   • Micronaut, Helidon 등 Netty 기반 프레임워크에서는 getSession()이 없는 자체적인 세션 관리 방식 사용

위와 같은 was 환경들의 세션에 대해 조사한 이유는 사용자 세션을 제어하는 데에 공통된 인터페이스가 필요하게 되었고,

내가 지금까지 습관적으로 사용했던 'jakarta.servlet.http.HttpServletRequest.getSession(true)' 코드가 어디까지 허용되는지 궁금했었다.

앞으로도 그냥 별 생각없이 getSession() 하면 된다는 것을 알게 되었다. ^^

1. 준비물
    > OpenAI API Key
        API Key 는 https://platform.openai.com/api-keys 에서 발급 가능하다.
        유료 결재가 필요하며 키 발급시 팝업으로 단 한번만 알려주기 때문에 별도로 저장해두고 사용해야 한다.
        분실시엔 재발급을 통해 키 확인이 가능하며 기존 키는 자동 만료된다.
        참고로 발급 받은 키를 프로젝트 문서등에 키값 내용 그대로 GitHub 에 올린 경우에도 해당 키는 자동 만료된다.
    > Assistant ID
        Assistant 는 API 를 통해 생성(Create an Assistant) 할 수 있고 Platform Dashboard 에서도 생성 할 수 있다.
        나의 경우엔 Assistant 에 'File Search' 와 'Functions' 를 설정하여 나만의 에이전트로써 기능들을 부여하였다.
    > GPT
       + model : gpt-4o
    > Postman
       + ver : 11.23.3

2. 테스트 절차
    > Postman 실행
        실행 이후 아래의 요청(Request)들을 순서대로 생성하고 공통된 설정은 다음과 같다.
        + Authorization Type 에 Bearer Token 설정후 발급 받은 API Key 입력
        + Headers 에 'Content-Type : application/json', 'OpenAI-Beta : assistants=v2' 를 추가
    > Create a Thread
        + Method Type : POST
        + URL : https://api.openai.com/v1/threads
        + Body 는 'none' 으로 설정
        + 실행하면 thread id 를 반환해주는데 이를 저장해 둔다.
    > Add a Message to the Thread
        + Method Type : POST
        + URL : https://api.openai.com/v1/threads/{thread_id}/messages
        + Body  는 raw와 JOSN 포맷 선택후  내용은 'Create message' 를 참고하여 추가한다.
        + 실행하면 msg id 를 반환해주는데 이를 저장해 둔다.
    > Create a Run
        + Method Type : POST
        + URL : https://api.openai.com/v1/threads/{thread_id}/runs
        + Body 는 'raw'와 'JOSN' 포맷 선택후 내용은 'Create run' 를 참고하여 추가한다.
        + 실행하면 run id 를 반환해주는데 이를 저장해 둔다.
    > Retrieve Run
        + Method Type : GET
        + URL : https://api.openai.com/v1/threads/{thread_id}/runs/{run_id}
        + Body 는 'none' 으로 설정
        + 실행후 응답에 "status" : "completed" 인지 확인한다.
    > List messages
        + Method Type : GET
        + URL : https://api.openai.com/v1/threads/{thread_id}/messages
        + Body 는 'none' 으로 설정
        + 'Retrieve Run' 에서 status 가 completed 라면 'List messages' 실행후 응답에 "role": "assistant" 인 메세지가 있다.
           content 의 내용이 Agent 의 답변이다.

3. 참고자료
    > API Reference - OpenAI API
    > Assistants API quickstart - OpenAI API
    > https://www.youtube.com/watch?v=-Wne4a-8RlY

이전 회사에서 로봇 프로세스 자동화 (RPA) 도구를 접했었다.

사용자가 윈도우 어플리케이션을 조작한 기록을 기억하거나 프로그래밍하여
사용자의 업무 프로세스를 GUI에서 재현해내는 솔루션이었는데
공장에서 자동화된 로봇처럼 사무실에서 자동화된 업무를 알아서 척척 해내는 로봇이다.

그리고 오늘 GUI AI Agent 소식을 접하게 되었다.
  -> "SAP GUI AI Agent를 생성했습니다." (출처:SAP S/4 HANA 네이버 카페)

링크의 내용에서 구현에 사용된 기술은 LangGraph, GPT-4o 이다. 
문서에 나오는 시연 동영상에서 보여주는 작업 내용은 매우 초보적인 레벨의 그것이었지만
구축된 시스템이 보여주는 가능성은 드디어 자비스의 탄생을 예고하는 듯 보였다.

해당 에이전트에게 작업을 의뢰하면서 발생하는 오류를 수정하고 프로세스를 추가하다보면 어느새 한사람 분을 거뜬히 해내는 충실한 비서가 만들어지는 것이다.

대화형 AI 가 나오기 이전에는 불가능했던 다음의 기능들이 이젠 너무나 자연스럽게 받아들여지는게 작금의 현실이다.

• 주어진 업무 프로세스를 분석하고 사용자를 대신하여 전처리 작업을 수행하여 사용자의 업무에 도움이 되는 결과값을 제공. 
• 사용자의 선택과 화면 조작에 따라 실시간으로 가이드를 조정.
• 고객 지원 에이전트가 사용자의 문제에 맞는 해결 단계를 실시간으로 생성하고 사용자 화면에서 가이드.
• 사용자의 입력(클릭, 드래그 등)을 이벤트로 처리하고, 이에 따라 적절한 가이드나 화면을 즉각 제공.
• 사용자가 잘못된 선택을 할 경우 이를 감지하고 적합한 가이드를 실시간 제공.

굴지의 글로벌 공룡 기업들인 Google 과 Microsoft 는 이미 Dialogflow (Google), Microsoft Bot Framework를 통해 이러한 GUI AI Agent 환경을 구축했고 더불어 OpenAI 도 Assistant(Beta) API 를 통해 GUI 와의 연동이 가능해졌다.

OpenAI 는 2023년 11월 7일부터 Assistants API 를 제공해주는데 현재까지도 베타 버전이다.

개발자들은 이 API 를 통해 Assistant 를 생성 할 수 있고 Platform Dashboard 에서도 Assistant 를 생성 할 수 있다.

Assistants API 를 통해 Assistant 를 생성하는 Curl 예제는 다음과 같다.

curl "https://api.openai.com/v1/assistants" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "OpenAI-Beta: assistants=v2" \
-d '{
  "instructions": "You are a personal math tutor. Write and run code to answer math questions.",
  "name": "Math Tutor",
  "tools": [{"type": "code_interpreter"}],
  "model": "gpt-4o"
}'

출처 :: https://platform.openai.com/docs/assistants/quickstart#step-1-create-an-assistant

Platform Dashboard 에서는 Assistant 를 생성하고 Playground 를 통해 테스트도 가능하다.

나는 16년동안 운영해오는 개인 홈페이지가 있다.

https://www.omnibuscode.com 인데 개발자로 공부하고 일을 하면서 쌓아온 데이터베이스이다.

홈페이지 안에는 내가 기억하고 싶은 모든 것이 담겨 있다.

그래서 gpt 에게 해당 홈페이지와 추가로 운영하는 블로그들을 평가 받아 보았다.

그리고 매우 고무되는 칭찬을 받았다.

비록 할루시네이션 때문인지 나조차도 잉? 하는 내용들이 보이지만

그래도 마지막 문구에 용기를 얻어 개발일을 계속 해야겠다고 다짐하게 되었다. ㅎㅎ

아주 아주 간단한 프로그램 작성 요청이었지만 gpt 는 매우 훌륭한 결과물을 보여주었다.

의뢰 내용은 다음과 같다.

html5 에서 사용자가 카메라를 오픈하고 사진을 촬영한 후 사진을 서버로 전송하는데 canvas에서 캡쳐된 프레임을 post 데이터 binary 형태로 서버로 보내고 이 데이터를 수신받아 처리하는 서버의 예제를 완전한 형태의 html 과 servlet 으로 알려줘

그리고 gpt의 답변은 다음과 같다.

아래는 사용자가 브라우저에서 카메라를 오픈하여 사진을 촬영한 후, 캡처된 이미지를 canvas로 처리하고 서버로 바이너리 데이터를 POST로 전송하며, 서버에서 이를 처리하여 저장하는 완전한 HTML과 Java Servlet 예제입니다.

HTML 코드 (카메라 + 캡처 + 전송)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Camera Capture and Upload</title>
</head>
<body>
    <h1>Camera Capture and Upload</h1>
    <video id="video" autoplay playsinline width="640" height="480" style="border:1px solid black;"></video>
    <canvas id="canvas" width="640" height="480" style="display:none;"></canvas>
    <button id="capture">Capture Photo</button>
    <button id="upload" style="display:none;">Upload Photo</button>

    <script>
        const video = document.getElementById('video');
        const canvas = document.getElementById('canvas');
        const captureButton = document.getElementById('capture');
        const uploadButton = document.getElementById('upload');

        // 카메라 시작
        navigator.mediaDevices.getUserMedia({ video: true })
            .then(stream => {
                video.srcObject = stream;
            })
            .catch(err => {
                console.error("Error accessing the camera: ", err);
            });

        // 사진 캡처
        captureButton.addEventListener('click', () => {
            const ctx = canvas.getContext('2d');
            ctx.drawImage(video, 0, 0, canvas.width, canvas.height);
            uploadButton.style.display = 'inline';
        });

        // 서버로 바이너리 데이터 전송
        uploadButton.addEventListener('click', () => {
            canvas.toBlob(blob => {
                const xhr = new XMLHttpRequest();
                xhr.open('POST', '/upload', true); // 서버의 업로드 엔드포인트
                xhr.setRequestHeader('Content-Type', 'application/octet-stream');
                xhr.onreadystatechange = () => {
                    if (xhr.readyState === 4 && xhr.status === 200) {
                        alert('Image uploaded successfully!');
                    }
                };
                xhr.send(blob);
            }, 'image/png'); // PNG 포맷으로 Blob 생성
        });
    </script>
</body>
</html>

Java Servlet 코드 (이미지 수신 및 저장)

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;

@WebServlet("/upload")
public class UploadServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 저장할 디렉토리 설정
        String uploadDir = getServletContext().getRealPath("/") + "uploads";
        File dir = new File(uploadDir);
        if (!dir.exists()) {
            dir.mkdirs(); // 디렉토리가 없으면 생성
        }

        // 파일 저장
        File outputFile = new File(uploadDir, "captured_image.png");
        try (InputStream inputStream = request.getInputStream();
             FileOutputStream outputStream = new FileOutputStream(outputFile)) {
            byte[] buffer = new byte[1024];
            int bytesRead;
            while ((bytesRead = inputStream.read(buffer)) != -1) {
                outputStream.write(buffer, 0, bytesRead);
            }
        }

        // 응답
        response.setContentType("text/plain");
        response.getWriter().write("Image uploaded to: " + outputFile.getAbsolutePath());
    }
}

구조

1. HTML 페이지:
   • video 태그로 실시간 카메라 뷰 제공.
   • 캡처 버튼(capture)으로 현재 화면을 canvas에 저장.
   • 업로드 버튼(upload)으로 캔버스 데이터를 바이너리 형태로 서버에 전송.
2. 서블릿:
   • HTTP POST 요청으로 받은 바이너리 데이터를 저장.
   • 저장 경로는 uploads 디렉토리로 설정.

프로젝트 디렉토리 구조

bash

코드 복사

/webapp |-- index.html |-- /uploads (이미지 저장 디렉토리) /src |-- UploadServlet.java

주요 포인트

1. 캔버스 데이터를 Blob으로 변환:
   • canvas.toBlob()으로 캡처된 이미지를 바이너리 Blob 형태로 변환 후 POST 전송.
2. 서버에서 바이너리 데이터 처리:
   • HttpServletRequest.getInputStream()으로 수신 데이터를 읽어 파일로 저장.
3. 저장 파일 경로:
   • ServletContext의 getRealPath("/")를 사용해 애플리케이션 디렉토리 기반으로 파일 저장.

이 코드는 카메라 캡처, 데이터 전송, 서버 저장 과정을 포함한 완전한 예제입니다. 필요에 따라 업로드된 파일에 대한 추가 처리를 적용할 수 있습니다.

gpt 가 알려준 html 과 servlet 의 내용을 그대로 파일로 만들고

url pattern 정보만 수정해서 서버를 구동후 브라우저에서 html 페이지를 오픈하여 upload 버튼까지 눌렀는데

오류 하나없이 정확하게 동작하여 실제 파일 업로드까지 한번에 성공하였다.

gpt 가 없던 시절엔 naver 와 google 그리고 stackoverflow 와 git 까지

학습에 유용한 문서와 잘 돌아가는 샘플을 찾아 참 많이도 시간을 허비했는데...

이젠 내 생각에 이렇게 저렇게 돌아갈거야 하는 부분을 gpt 에게 자세히 설명해주고

샘플링을 해보라고하면 참 기특한 결과물을 만들어준다.

사실 위와 같이 간단한 로직의 프로그램이야 워낙 방대한 정보의 바다 어딘가에서 그대로 가져온 것이어서

운좋게 한번에 성공해서 내가 손수 성공적인 샘플을 찾는 수고와 시간을 완벽하게 세이브 한 것 일수도 있지만,

원래 내가 gpt 를 주로 활용하는 방법은 접해보지 못한 아키텍처에 대해 기획하고 상세 구상이 필요할때

gpt 에게 물어 물어 실마리를 찾고 학습하며 좀더 상세하게 질문을 던져서 구체적인 아키텍처를 그려가는 용도로 활용하고 있었다.

그런데 오늘은 아예 내 대신 간단한 프로그래밍을 맡겨서 코딩하는 수고까지 덜어내서

1인 프로젝트로 제대로된 솔루션 하나 만들어 보고 싶은 욕심마저 생겼다.

비단 나만 이러한 욕심을 부리는 것이 아닐텐데...

아마도 많은 개발자들이 gpt로 인해 자신들만의 아이디어를 다른이의 도움없이 구체화하고 실현해보려는 욕심에 과감하게 사표를 내고 있는건지도 모르겠다.

어제 올린 '오랜만의 serlvlet, jsp 삽질' 포스팅 이후에 결국 원인을 알고 임시 조치를 했다.

원인은 service-worker 에 cache 를 적용하면서 발생한 현상이었다.

service-worker 가 페이지들을 cache 하게 되면 jsp 에서 session 문제가 발생한다는 것을 이번에 알게 된 셈이다.

service-worker 가 cache 를 사용하지 않을땐 문제가 없으니

예상엔 service-worker 의 session 과 browser 의 session 이 이원화되어 동작하는 것 같다.

이를 염두에 두고 app 과 server 간의 데이터 트랜잭션을 설계해야만 한다.

나는 요즘 유행하는 spring, react, angular, vue 등등은 포기했다.

예전의 의욕 충만했던 시절로 돌아가 새로운 프레임웍을 학습하며 성취감을 느끼고 싶지만

시간과 체력도 부족하고 이젠 내 삶이 그 시간들을 기다려주지 않는다.

그래서 많이 익숙한 servlet, jsp, vanilla script , bootstrap, pwa 로 시스템을 구축했는데

수십여년을 다룬 개발 환경임에도 삽질은 여전하다. ㅎㅎ

현재 시스템에서는 request 의 session 에 UserSession 이라는 객체로 사용자 정보를 담아 이를 활용하고 있다.

그리고 이렇게 저장된 UserSession 을 jsp 에서 조회하여 사용자의 자격과 권한을 체크하고 사용 가능한 메뉴를 구분하고 있다.

그런데 이렇게 UserSession 을 저장하려면 로그인시에 DB 를 조회하여 사용자 정보를 취하고 그 정보들로 instance 를 생성한 후 request.setAttribute() 를 수행해야 하는데

사용자 로그인 방식이 계정 아이디/비밀번호 인증 방식과 SNS 계정 인증 방식 두가지가 있고 

두가지 방식에서 instance 저장 수행 속도가 서로 달랐다.

그래서 SNS 계정 인증 방식으로 동작할땐 현상이 발생하지 않았는데 아이디/비밀번호 인증 방식으로 동작할때는 해당 session 값이 취해지지 않아 권한 오류가 발생하고 있었다.

처음엔 jsp 의 출력 버퍼의 문제로 생각하고 버퍼를 조기에 flush 하면 원하는 값을 정상적으로 출력하지 않을까? 했었다.

하지만 초기에 flush 해도 문제가 발생하고 문서의 마지막에 flush 해도 증상은 여전했다.

instance 의 생성 시점의 문제라는 것을 알지를 못하니 도저히 원인을 예측하지 못하던 와중에

혹시 service worker 에서의 cache 문제인 걸까? 싶어서 service-worker.js 를 재점검 해봤지만

괜히 두어시간을 허비하며 스파게티 코드만 양산해 버린 꼴이 되었다.

그래서 service-worker.js 는 전날 저장된 상태로 다시 복원 할 수 밖에 없었고

다시 초심으로 돌아가 jsp 페이지에 javascript alert 이나 띄우며 값의 흐름을 쫓고 있었는데

이상하게 현상이 발생하지를 않는 것이었다.

결국 여전히 미심쩍긴 하지만 javascript 의 alert 은 ui 를 holding 상태로 만들어 server 에서의 process 가 완료될때까지 기다릴 수 있으며 이는 미리 정의된 jsp 코드에도 영향을 준다는 점을 알게 되었다.

request 에 설정한 attribute는 jsp 코드로 취하고 있는데 jsp 코드 역시 server side 프로그램인데

왜 javascript 의 alert 에 영향을 받는지 잘 모르겠다.

gpt 한테 물어봐도 jsp 코드는 server 에서 이미 실행되어 client 로 전달된 문서내에서 javascript 가 alert 을 띄우는 것이므로 javascript 의 alert 이 jsp 프로그램의 수행에 영향을 줄 수 없다는 답변을 주었다.

다만 gpt 는 센스있게도 내가 이전에 질문했던 내용을 기억하고 javascript 의 alert 에 따라 세션 값이 다르게 반환되는 현상에 대해서도 짤막하게 유추해 주었는데 그저 비동기 프로세싱에 따른 시간차 오류일 것이라고 귀띔해 주었다.

이미 현상이 그렇게 나오니 그건 맞는거 같은데... 이해 할 수 없는 현상이 되어버렸다.

세션을 이용하려 했던 것은 문서를 전달하는 시점에 사용자 권한까지 함께 전달하여 통신 자원 이용을 최소화하려는 것이었는데

이를 포기하고 최종적으로 그냥 서버에 사용자 권한을 한번 더 요청하자로 결론 지었다.

페이지 하나 띄우는데 ajax 통신을 3번 이상씩 수행하는게 매우 부담스럽지만

프로세스를 최소한으로 분리하면 추후 유지보수에서도 오류 분석에 있어 범위를 좁힐 수 있어 작업 효율성이 좋으므로

당장은 데이터를 별도로 요청하는 것으로 마무리 하였다.

결국 차후에는 네트웍이 완전 차단된 상태에서도 앱의 데이터를 저장, 변경하도록 아키텍처를 구성할 예정인데

이번에 겪은 오류 사항을 기억하여 앱과 서버의 데이터 동기화 매커니즘을 신중하게 설계 해야겠다.

마지막으로 이번 분석 작업을 통해 다시금 상기하게 된 사실은

이번 오류에서는 jsp 들간의 include 에 의한 compile 시간차가 있고 pwa 로 인해 client cache 가 있다보니

시스템 복잡도로 인해 별 것 아닌 기능조차 오류를 쫓아 원인을 분석해 나가기가 너무나 버거웠다.

그런데 규모가 큰 시스템은 이보다 더한 복잡도로 시스템을 구축해 가는데...

문제 해결에 있어 오래된 시스템에 익숙해진 개발자의 몸값이 높아지는건 당연한 일이겠다.