한국에서 SW 개발자로 산다는것

사용기 - Large Context Analysis 스킬 적용기: CodeGraph로 컨텍스트를 적게 읽게 만들기

2026-06-16T10:28:09.078+09:00

MIT CSAIL의 논문 「Recursive Language Models」는 긴 컨텍스트 문제를 다른 방식으로 접근한다. 이 논문은 OOLONG-Pairs처럼 입력 전체의 많은 쌍을 비교해야 하는 작업에서, GPT-5 기본 모델과 compaction agent가 각각 0.1 F1 수준에 머무른 반면 RLM depth=1은 58.0 F1을 기록했다는 결과를 제시한다.

이를 바탕으로 논문은 긴 프롬프트를 LLM 컨텍스트 창에 직접 넣거나 반복 요약하는 대신, 외부 환경에 두고 필요한 부분을 프로그램적으로 탐색·분해·재귀 호출하는 Recursive Language Models, RLMs를 제안한다.

* OOLONG-Pairs : 논문에서 RLM 성능을 검증하기 위해 사용한 긴 컨텍스트·고밀도 추론 벤치마크

* compaction agent : 긴 입력을 그대로 넣지 않고, 중간에 요약하거나 압축해서 더 짧은 컨텍스트로 만든 뒤 답하게 하는 방식의 에이전트

* F1 : 정답을 얼마나 잘 맞혔는지 보는 평가 지표

* RLM depth=1: 재귀 호출의 깊이를 1단계까지 허용

Headroom을 사용하면서 성능 리포트상으로는 토큰 절감 효과가 크게 표시되었지만, 컨텍스트를 줄인다는 것은 결국 모델에게 전달되는 정보가 줄어든다는 뜻이기도 하다. 특히 성능 지표에서 TOIN retrieval이 0%로 표시되는 상황에서는, 압축된 정보가 필요할 때 원문을 다시 꺼내 검증하는 루프가 실제로 동작하고 있는지 확신하기 어려웠다.

이 지점에서 앞서 언급한 Recursive Language Models 논문이 주는 시사점이 있었다. 논문은 긴 컨텍스트 문제를 단순히 더 큰 컨텍스트 창에 넣거나, 반복적으로 요약·압축하는 방식만으로 해결하기 어렵다고 본다. 특히 OOLONG-Pairs처럼 입력 전체의 많은 조합을 비교해야 하는 고밀도 추론 작업에서, GPT-5 기본 모델과 compaction agent는 각각 0.1 F1 수준에 머무른 반면, RLM depth=1은 58.0 F1을 기록했다. 이 결과는 긴 입력을 무조건 넣거나 줄이는 것보다, 외부 환경에 두고 필요한 부분을 탐색·분해·재귀 호출하는 방식이 더 효과적일 수 있음을 보여준다.

이 내용을 Codex 사용 방식에 그대로 적용하기는 어렵지만, 실무적인 힌트는 얻을 수 있었다. 코딩 에이전트들은 대부분 기본적인 파일 검색, 코드 탐색, 부분 읽기, 요약 기능을 제공한다. 그렇다면 반드시 Headroom처럼 컨텍스트를 프록시에서 압축하지 않더라도, 작업 절차 자체를 바꿔 불필요한 컨텍스트 생성을 줄일 수 있다.

기본적으로 CodeGraph를 사용하고 있기 때문에 CodeGraph를 RLM식으로 쓰는 스킬을 적용해보기로 했다.

*CodeGraph : 코드베이스를 미리 분석해서 클래스, 함수, 호출 관계, 파일 구조를 그래프로 만들어두고, 코딩 에이전트가 필요한 코드 위치를 빠르게 찾도록 도와주는 도구

1. 스킬 생성하기

스킬 생성은 코덱스 앱을 사용했고 적용 모델은 GPT-5.5 매우 높음을 사용 plugin-creator 플러그인을 사용하여 다음 내용으로 생성을 요청했다.

코덱스의 create-plugins 에 의하여 생성된 결과물은 ~/plugins/large-context-analysis/.codex-plugin/ 경로에 자동으로 생성되었다.

생성된 사용자 플러그인은 플러그인 메뉴 내가 만든 항목에서 확인 할 수 있고 "추가" 버튼을 클릭하여 바로 사용할 수 있다.

새로운 플러그인 생성을 위해 @plugin-creator 채팅으로 이동
생성 후 플러그인 메뉴에서 내가 만든 항목으로 이동
생성된 목록에서 새로운 스킬을 추가

2. 스킬 테스트 하기

다음으로 실제 테스트를 진행해보았다. 문제는 Large Context Analysis 스킬의 효과를 확인하기 어렵다는 점이다.

큰 파일/데이터을 다룰때는 large-context-analysis 사용해.
첨부한 로그를 분석해줘.
전체 로그를 한 번에 읽지 말고,
최초 ERROR, 반복 stack trace, root cause 후보를 먼저 분리해줘.
그 다음 CodeGraph로 관련 클래스와 호출 경로를 찾고,
필요한 소스 구간만 확인해줘.
마지막에는 원인, 수정 후보, 검증 방법을 정리해줘.

보통은 간단하게 아래와 같은 작업 기준을 전달하는 것으로도 충분했다.

큰 파일·긴 로그·대형 diff·복잡한 데이터 분석 시 `large-context-analysis` 스킬을 사용하고, CodeGraph로 작업 대상 코드를 먼저 선정한 뒤, 작업 완료 후 `Context Usage Report`를 반드시 제시한다.

~~Headroom처럼 토큰 절감률이나 압축률이 숫자로 표시되는 것이 아니기 때문이다. 그래서 작업 요청에 추가 조건을 넣었다.~~

단순히 로그를 분석하게 하는 것이 아니라, 작업 완료 후 `Context Usage Report`를 제출하도록 했다. 이 보고서에는 사용한 검색어, CodeGraph 탐색 단계, 읽은 파일 목록, 전체 파일을 읽었는지 또는 일부 구간만 읽었는지, 확인한 주요 라인·메서드·SQL ID, 불필요하다고 판단해 읽지 않은 파일, 최종 원문 검증 여부를 포함하도록 했다.

이렇게 하면 스킬의 효과를 “토큰이 얼마나 줄었는가”가 아니라 “Codex가 얼마나 불필요한 파일과 로그를 덜 읽었는가”, “관련 후보를 먼저 좁혔는가”, “최종 결론을 원문 기준으로 검증했는가”로 판단할 수 있을 것으로 기대했다. ( 테스트 과정에서 SKILL 에 Report 기능을 추가하여 아래 추가 설명없이도 확인이 가능하게 했다).

~~"Context Usage Report"를 작성해줘.~~
~~Context Usage Report에는 다음을 포함해줘.~~
~~- 사용한 검색어~~
~~- 사용한 CodeGraph 쿼리 또는 탐색 단계~~
~~- 읽은 파일 목록~~
~~- 전체 파일을 읽었는지, 일부 구간만 읽었는지~~
~~- 확인한 주요 라인/메서드/SQL ID~~
~~- 불필요하다고 판단해 읽지 않은 파일~~

~~- 최종 판단 전 원문 검증 여부~~

Context Useage Report

이번 테스트 결과를 보면 Large Context Analysis 스킬은 어느 정도 의도한 방식으로 동작했다. Codex는 처음부터 전체 코드베이스를 읽지 않고, search-visualization, VectorSearchVisualizationService, VectorStorePort, PgVectorStoreAdapterV2, PgVectorMapper, metadataFilter, includeText, includeMetadata 같은 기능과 관련된 구체적인 검색어를 사용해 관련 범위를 좁혀 갔다.

CodeGraph 탐색도 /search-visualization에서 시작해 Controller → Service → VectorStorePort → PgVectorStoreAdapterV2 → PgVectorJdbcMapper → PgVectorMapper.xml 경로로 진행되었다. 즉 단순히 파일을 많이 읽는 방식이 아니라, 기능의 호출 흐름을 먼저 따라가며 후보 파일을 좁힌 것이다.

실제로 읽은 파일도 구분되었다. DefaultVectorSearchVisualizationService.java와 PgVectorSearchParameter.java는 전체를 확인했고, PgVectorJdbcMapper.java, PgVectorMapper.xml, 테스트 파일은 관련 SQL 또는 테스트 구간만 부분적으로 확인했다. 반면 RAG 일반 검색 Controller/DTO, SkillGraph/Markdown 파일, projection 생성 및 point 저장 관련 파일은 이번 작업 범위와 직접 관련성이 낮다고 판단해 재검토 대상에서 제외했다.

이 점은 Large Context Analysis 스킬의 효과를 보여주는 부분이다. 효과가 토큰 절감률처럼 숫자로 표시되지는 않지만, Codex가 검색과 CodeGraph를 먼저 사용해 후보를 좁히고, 필요한 파일과 구간만 확인했으며, 불필요한 파일을 읽지 않도록 유도했다는 점에서 컨텍스트 사용을 줄이는 방향으로 동작했다고 볼 수 있다.

또한 최종 판단 전 CodeGraph 결과를 원문으로 확인하고, rg로 SQL 패턴을 재확인했으며, 대상 Gradle 테스트와 git diff --check까지 통과시켰다는 점도 중요하다. 이는 요약이나 CodeGraph 결과만 믿지 않고 원본 파일과 테스트 결과를 기준으로 검증했다는 의미다.

다만 효과를 더 명확히 보려면 다음부터는 후보 파일 수, 실제 읽은 파일 수, 전체 읽기 파일 수, 부분 읽기 파일 수, 제외한 파일 수를 함께 기록하는 것이 좋다. 그렇게 하면 Large Context Analysis 스킬의 효과를 “느낌”이 아니라, 실제 탐색 범위 축소 결과로 비교할 수 있을 것 같다.

* 앞에서 언급되는 이름들은 테스트에 적용된 프로젝트 소스 이름이다.

마지막으로 이번 실험의 결론은 Headroom이 불필요하다는 것이 아니다. Headroom은 긴 로그나 반복 tool output을 줄이는 데 여전히 유용할 수 있다. 다만 압축된 컨텍스트 품질이 찜찜하다면 (개인적인 생각), 먼저 CodeGraph와 스킬을 이용해 “처음부터 필요한 것만 읽게 만드는 방식”을 적용해볼 만하다. Large Context Analysis 스킬은 토큰 절감 도구라기보다, 코딩 에이전트의 조사 습관을 바꾸는 절차적 안전장치에 가깝다.

사용기 - Headroom으로 Codex 토큰 사용량 줄이기

2026-06-15T17:07:23.629+09:00

코딩 에이전트를 사용하여 코드를 분석하고 수정하다보면 가장 먼저 부딪치는 문제는 컨텍스트(모델이 답변을 만들기 위해 한 번에 참고하는 입력 정보 전체)와 토큰 사용량이다.

LLM 은 텍스트를 글자 단위가 아닌 토큰(token) 단위로 처리하는데 토큰은 대략 단어 조각, 기호, 코드 조각에 해당한다. 즉 컨텍스트가 길어질 수록 LLM 에 전달되는 토큰 수도 증가하게 된다.

1. Headroom

Headroom은 AI 코딩 에이전트가 LLM에 전달하는 컨텍스트를 압축해 토큰 사용량을 줄이기 위한 오픈소스 프로젝트다. 공식 README에서는 Headroom을 다음 문장으로 설명한다.

Compress everything your AI agent reads.
Same answers, fraction of the tokens.

즉, AI 에이전트가 읽는 파일, 로그, tool output, RAG chunk, 대화 이력 등을 LLM에 전달하기 전에 압축해서, 가능한 한 같은 답변을 더 적은 토큰으로 얻는 것이 목표다.

Codex 같은 AI 코딩 에이전트는 사용자의 질문만 LLM에 보내지 않는다. 문제 해결을 위해 소스 파일, 오류 로그, 터미널 명령 결과, git diff, 프로젝트 문서, 이전 대화 이력 등을 함께 전달한다. 이 정보들이 모두 컨텍스트가 되고, 컨텍스트가 길어질수록 토큰 사용량과 비용도 증가한다.

Headroom은 이 지점에서 Codex와 LLM 사이에 위치하는 컨텍스트 압축 레이어로 동작한다. 기술적으로 보면 Headroom은 Codex가 LLM Provider로 요청을 보내기 전에 중간에서 요청을 받아 컨텍스트를 정리한다.

Codex가 파일을 읽거나, 터미널 명령을 실행하거나, 검색 결과와 로그를 수집하면 이 결과들은 그대로 LLM 입력에 포함될 수 있다. Headroom은 이 입력을 가로채서 중복 제거, 요약, 필터링, 구조화 같은 처리를 수행한 뒤 더 짧은 형태의 컨텍스트로 다시 구성한다.

아키텍처 및 동작방식

이 구조에서 중요한 점은 Headroom이 최종 답변을 직접 생성하는 모델이 아니라는 것이다. Headroom은 Codex와 LLM 사이에서 입력 컨텍스트를 최적화하는 계층이다. 즉, “무엇을 답할 것인가”는 여전히 LLM이 담당하고, Headroom은 “LLM에게 어떤 정보를 얼마나 효율적으로 전달할 것인가”를 담당한다.

예를 들어 Codex가 테스트 실패 원인을 찾기 위해 수천 줄의 로그와 여러 개의 소스 파일을 읽었다고 가정해보자. 이 정보를 그대로 LLM에 보내면 토큰 사용량이 크게 증가한다. Headroom은 이 중 반복되는 stack trace, 중복 로그, 관련성이 낮은 출력 등을 줄이고, 오류 원인 분석에 필요한 핵심 정보를 중심으로 컨텍스트를 다시 구성한다.

따라서 Headroom의 기술적 역할은 단순히 텍스트 길이를 줄이는 것이 아니다. 컨텍스트 안에서 의미 있는 정보는 유지하고, 반복되거나 덜 중요한 정보는 줄여서 LLM이 더 적은 토큰으로 문제를 이해하도록 돕는 것이다.

이 때문에 Headroom은 특히 다음과 같은 작업에서 효과를 기대할 수 있다.

긴 빌드 로그 분석
테스트 실패 원인 추적
대형 코드베이스의 여러 파일 분석
큰 git diff 검토
검색 결과가 많은 작업
이전 대화 이력이 길게 누적된 Codex 세션

반대로 다음과 같은 경우라면 굳이 사용할 필요가 없다.

짧은 파일 수정
간단한 질문
작은 버그 수정
정확한 원문 로그 전체가 중요한 장애 분석
보안/권한/결제/마이그레이션처럼 작은 차이가 중요한 작업

2. 설치하기

환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.3.1 (24D70)
AI Coding Agent : Codex

Headroom은 Codex 앱에 직접 붙는 도구라기보다, Codex CLI를 감싸거나 proxy로 연결하는 도구이다. 공식 README도 Headroom을 “AI agent가 읽는 tool output, logs, RAG chunks, files, conversation history를 LLM에 도달하기 전에 압축하는 도구”로 설명하고, Codex 같은 coding agent와 함께 사용할 수 있다고 안내하고 있다.

먼저 Codex CLI 와 파이선이 설치되었는지를 아래 명령으로 확인한다.

python3 --version
pip3 --version
which codex
codex --version

참고로 Codex 앱만 사용하고 있더라도 Codex CLI 설치는 별도이다. 설치는 아래와 같은 명령으로 진행한다. (OpenAI 공식 문서 기준)

curl -fsSL https://chatgpt.com/codex/install.sh | sh

다음으로 python 패키지 형태로 headroom 을 설치한다.

python3 -m pip install -U "headroom-ai[all]"

3. 사용하기

설치가 완료 되었다면 아래 명령으로 실행할 수 있다.

headroom wrap codex

성능 리포트 기능을 사용하여 컨텍스트 압축이 효과가 있는지를 확인해 볼 수 있다.

headroom perf

위 리포트 결과를 보면 압축후 토큰 사용량이 0 이 된점을 보아 좀 과장되었다고 생각을 하게 되었다. 또한 Retrievals 비율이 0% 인것으로 보아 패턴을 학습하고는 있지만, 그 학습된 패턴을 다시 꺼내 재사용하지는 못하고 있음을 알 수 있다. 이 결과는 사용 시간이 너무 잛아서 그런거라고 예상하고 있다.

좀더 긴 시간을 사용후에 확인 해보았지만 필요할 때 원문을 꺼내 사용한 기록은 존재하지 않았다.

아쉬운 점은 /status 을 사용해도 요금 한도부분을 확인 할 수 없었다. (추측하건데 headroom warp API 가 이를 지원하지 않아서 인것 같다.) 사용하다 갑짜기 limit 에 도달했다는 메시지를 받았다.

headroom wrap 명령이 codex 설정을 자동으로 모델 provider , openai_base_url 정보를 수정하기 때문에 headroom 을 사용하지 않는 경우에는 unwrap 으로 다시 설정을 원복 해줘야 한다.

headroom unwrap codex

4. 결론

개인적으로 Headroom을 사용하면서도 품질에 대한 찜찜함을 완전히 버리기는 어려웠다. 성능 리포트상으로는 토큰 절감 효과가 크게 표시되었지만, 컨텍스트를 줄인다는 것은 결국 모델에게 전달되는 정보가 줄어든다는 뜻이기도 하다. 특히 TOIN retrieval이 0%로 표시되는 상황에서는, 압축된 정보가 필요할 때 원문을 다시 꺼내 검증하는 루프가 실제로 동작하고 있는지 확신하기 어려웠다.

사용기 - CodeGraph 사용하여 Codex 가 코드를 구조화된 코드 그래프로 이해하게 만들기

2026-06-12T16:01:34.347+09:00

AI 코딩 도구를 사용하면 자주 경험하는 문제는 "프로젝트 구조를 파악하는 데 시간이 많이 걸린다" 였다. 특히 멀티 모듈이나 대규모 코드로 구성된 프로젝트의 경우 기존 소스를 검색하여 파악하는데 많은 시간이 걸린다.

CodeGraph 는 소스 코드를 분석해서 코드베이스를 그래프 형태로 인덱싱하는 오픈소스 프로젝트이다.

CodeGraph는 AI 코딩 에이전트가 프로젝트 소스코드를 매번 grep, find, Read로 처음부터 탐색하지 않도록, 코드베이스를 미리 인덱싱해 코드 지식 그래프로 제공하는 도구다. 로컬 코드베이스를 분석해 .codegraph/ 디렉터리에 인덱스를 저장하고, Codex CLI, Claude Code, Cursor, Gemini CLI, Antigravity IDE 같은 AI 에이전트가 MCP를 통해 이 그래프를 조회할 수 있도록 해준다. 공식 설명에서도 CodeGraph는 tree-sitter 기반으로 코드베이스를 파싱하고, 심볼·엣지·파일 정보를 SQLite/FTS5에 저장하며, MCP를 통해 AI 에이전트에 제공하는 로컬 우선 코드 인텔리전스 도구라고 설명한다.

CodeGraph 는 AST(Abstract Syntax Tree) 결과를 이용하여 코드 그래프를 만들어 사용하고 있는데 관련하여 2026년 arXiv 논문 "Codebase-Memory:Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP" 에 따르면Tree-sitter 기반 코드 지식 그래프 + MCP 방식이 **토큰은 10배 적게, tool call은 2.1배 적게 사용했지만, 답변 품질은 파일 탐색형 agent 92% 대비 83%**였다고 보고한다. 즉, 그래프 기반 탐색은 효율성은 높지만, 원본 파일을 충분히 읽는 방식보다 품질이 낮아질 수 있다는 문제를 보여주고 있다.

CodeGraph는 이런 품질 이슈를 “자동 정답화”로 해결하지 않고, AST 기반 그래프 + context/trace/impact + 원본 body 제공으로 사실 확인 비용을 줄이는 방식으로 완화하고 있다.

1. 설치하기

환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.3.1 (24D70)
AI Coding Agent : Codex

설치는 npm 을 사용하여 전역으로 설치하는 방식을 사용했다. (여러 프로젝트에서 사용할 수 있도록)

npm install -g @colbymchenry/codegraph

설치 이후에는 다음 명령으로 확인 할 수 있다.

codegraph --version
which codegraph

2. AI 코딩 에이전트에 MCP 연결

CodeGraph는 MCP 서버로 동작한다. 따라서 Codex, Claude Code, Cursor 같은 AI 코딩 도구에서 사용하려면 먼저 MCP 설정을 연결해야 한다. Codex 를 주력으로 사용하고 있어 Codex 에 MCP 로 등록했다.

codegraph install

이 명령은 현재 개발환경에 설치된 AI 에이전트를 감지하고, CodeGraph MCP 서버 설정을 자동으로 추가한다. 공식 README 기준으로 자동 설정 대상에는 Claude Code, Cursor, Codex CLI, opencode, Hermes Agent, Gemini CLI, Antigravity IDE, Kiro 등이 포함된다.

기본적으로 설치는 전역으로 설치하고 각 프로젝트 경로에서 초기화를 해주것이 좋다. (여러 프로젝트에서 사용할 수 있게)

성공적으로 연결되었다면 아래와 같이 확인하거나 codex 도구에서 /mcp 명령으로 확인 할 수 있다.

grep -A 3 -B 1 "codegraph" ~/.codex/config.toml

Codex 앱에서 /mcp 입력

3. 로컬 프로젝트 초기화 및 인덱스 생성

로컬 프로젝트 루트로 이동하여 init 명령을 사용하여 초기화를 실행 합니다. 최초 초기화인 경우 -i 옵션을 사용하여 코드 분석 인덱싱까지 함께 진행하는 것이 일반적이다.

codegraph init -i

코드가 추가 되거나 수정되면 index 명령을 사용하여 인덱스를 갱신한다.

codegraph index

status 명령으로 초기화 또는 인덱싱 상태를 확인할 수 있다.

codegraph status

4. 사용 방법

5. 사용 후기

CodeGraph 을 코덱스에 사용한 결과 코드 검색 속도는 아주 빨라졌다. 작업 하기 전에 관련 코드를 검색하는 작업을 하는 것이 일반적인데 codegraph 을 사용하여 검색하고 해당 파일들을 기준으로 수정작업을 진행하기 때문에 상당한 속도 개선은 있는 것 같다.

추가로 CodeGraph 는 아주 빠른 속도록 업데이트 되고 있기 때문에 다음과 같이 설치된 버전과 최신 버전을 확인해서

echo "installed: $(codegraph --version)"
echo "latest: $(npm view @colbymchenry/codegraph version)"

최신 버전으로 업데이트 할 수 있다. (전역 설치의 경우에)

npm update -g @colbymchenry/codegraph

CodeGraph 버전을 업데이트했다면 필수는 아니지만 최신 분석 로직 반영을 위해서 index 을 다시 실행한는 것이 좋다.

codegraph index
codegraph status

사용기 - ChatGPT 에서 설계 하고 개발은 Codex 에서

2026-05-06T09:54:57.829+09:00

Codex 와 대화 하면서 구체적인 설계를 진행하는 것 보다 ChatGPT 에서 설계를 하고 대화 결과를 코덱스에 공유하여 구현을 하는 것을 테스트 해보았다. 실험의 목적은 코덱스의 토큰 사용량을 최소화하기 위한 경제성이다.

모델은 5.5 Pro 을 사용하였고 대화를 통하여 원하는 설계를 구체화 했다. Codex 전달용 작업 계획을 요청했지만 한번에 복사하여 사용하기는 어려운 점이 있었다.

대화에 대한 공유 링크를 생성하고 링크를 Codex 에 전달하여 진행을 시도하였다. 다만 이경우 전체 대화 내용을 읽어서 작업 계획을 수립하기 때문에 진행 과정의 대화 까지 읽어 들여 비효율적이며 토큰을 낭비하게 된다.

좀더 효과적은 작업 내용 전달을 위해서 ChatGPT 대화에서 최종 결과에 대한 md 파일 생성을 요청하여 Codex 에 공유하여 작업을 진행하게 했다.

생성된 md 파일을 통한 작업 지시의 장점은 md 파일 계획이 1차, 2차 구현으로 구분되어 있는 경우 Codex 는 1차 구현만 진행하게 되는데 작업이 완료된 이후에 다시 2차 를 구현하도록 지시할 수 있다는 점이다. (또한 미리 작업 계획 초안을 검토하는 것이 용이)

이번 작업을 통해 느낀 점은 AI 코딩에서 중요한 것은 단순히 좋은 모델을 사용하는 것이 아니라, AI가 안정적으로 이해하고 작업할 수 있도록 작업 자체를 구조화하는 것이라는 점이다.

특히 ChatGPT에서 충분히 설계와 정리를 수행한 뒤, 최종 내용을 md 기반 작업 계획으로 압축하여 Codex에 전달하는 방식은 예상보다 효율적이었다.

공유 링크 방식은 전체 대화 흐름까지 모두 포함되므로 불필요한 컨텍스트 증가와 토큰 낭비가 발생하기 쉽다.

반면 md 기반 작업 문서는:

작업 범위를 제한하고
구현 단계를 분리하며
필요한 정보만 압축 전달하고
검토 가능한 형태로 유지할 수 있다.

결국 AI 시대의 개발 생산성은 “얼마나 긴 프롬프트를 작성했는가”보다, AI가 일하기 좋은 구조와 흐름을 어떻게 설계했는가 에 더 크게 좌우된다고 느꼈다.

사용기 - 프롬프트는 시작이고, AI는 환경에서 일한다

2026-04-30T09:45:55.405+09:00

Feedback Loop Engineering은 2026년 1월 다니엘 데멜(Daniel Demmel)이 AI 코딩 에이전트의 품질을 높이는 핵심을 “검증 가능한 반복 구조”로 설명하면서 제시한 개념이다.

이후 2026년 2월 OpenAI는 Codex 활용 사례를 통해 하네스 엔지니어링(Harness Engineering)이라는 표현을 사용하며, 에이전트가 안정적으로 일할 수 있도록 실행 환경·검증 체계·피드백 구조를 설계하는 접근을 소개했다.

두 개념은 별개라기보다, Feedback Loop Engineering이 “무엇을 반복해야 하는가”를 설명하고 하네스 엔지니어링(Harness Engineering)이 “그 반복이 가능하도록 어떤 환경을 설계해야 하는가”를 설명한다고 볼 수 있다.

많은 사람들이 AI 코딩 에이전트를 잘 사용하는 방법은 “프롬프트를 잘 쓰는 것”이라고 생각한다.
하지만 최근 흐름은 다르다. “스스로 검증하고 개선할 수 있는 구조를 만드는 것”이다.

프롬프트 중심에서는 결과가 프롬프트 품질에 크게 의존하며 사람이 계속 개입해야 한다. Feedback Loop Engineering은 완전히 다른 방향을 제시한다. AI가 스스로 결과를 개선하는 구조를 통하여, 결과 품질이 프롬프트가 아니라 테스트와 검증에 의해 결정되도록 만든다. 이러한 구조에서는 사람이 모든 과정을 직접 통제할 필요가 없다. AI는 실행 결과와 오류를 기반으로 스스로 수정하고, 반복적으로 품질을 높여간다.

결국 중요한 것은 더 정교한 질문이 아니라, 잘못된 결과를 빠르게 발견하고 수정할 수 있는 피드백 루프를 설계하는 것이다.

결정적으로 최근 Codex에서 지원하기 시작한 “Computer Use”, “Browser Use” 기능을 직접 경험하면서 생각이 완전히 바뀌었다.

그동안은 좋은 프롬프트, 정교한 스킬, 다양한 서브에이전트를 만드는 것이 핵심이라고 생각했다.
하지만 실제로는 전혀 다른 결과를 보게 되었다.

단순한 명령만으로도

테스트 후 수정하고
서버를 재시작하고
브라우저에서 직접 화면을 확인하고
테스트 결과를 바탕으로 다시 수정하는

전체 작업 흐름을 AI가 스스로 수행하는 경험을 하게 되었다. 이 과정에서 느낀 것은 명확했다.

중요한 것은 프롬프트가 아니라 “일을 할 수 있는 환경”이었다.

프롬프트를 아무리 잘 작성해도 AI가 실행하고, 확인하고, 실패를 인지하고, 다시 수정할 수 없다면
결국 사람이 계속 개입해야 한다. 반대로, 환경만 제대로 갖추어지면 아주 간단한 명령만으로도 AI는 스스로 작업을 이어가고 결과를 개선해 나간다.

이 경험은 정말 충격적이었다.

에이전트가 테스트하고 수정하고 벡엔트 파트 작업는 이슈로 등록

에이전트가 이슈를 확인해서 처리하고 서버를 재시작해서 확인

결국 중요한 것은 질문을 잘하는 능력이 아니라, AI가 스스로 실행하고 검증하며 반복할 수 있도록 프로젝트와 환경을 설계하는 것이다.

AI는 왜 사용자를 잘못된 확신으로 이끄는가 — Sycophancy 논문에서 본 대화형 AI 의 위험

2026-04-08T14:04:00.001+09:00

Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians

최근 공개된 Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians 논문은 ChatGPT와 같은 대화형 AI가 가질 수 있는 구조적 위험을 설명한다. 이 논문이 말하는 핵심은 단순하다.

AI의 위험은 단지 틀린 답을 하는 데만 있지 않다. 사용자의 현재 믿음을 반복적으로 정당화하면서 잘못된 확신을 점점 더 키울 수도 있다.

여기서 핵심 개념은 비위를 맞추는 성향(sycophancy) 이다. 이는 AI가 사용자의 말에 과도하게 동조하거나, 사용자가 기대하는 방향으로 답을 맞추려는 성향을 의미한다. 사용자는 이를 친절하고 공감적인 응답으로 받아들일 수 있지만, 반복적인 대화에서는 오히려 잘못된 방향의 자기 확신을 강화하는 결과로 이어질 수 있다.

예를 들어 사용자가 어떤 가설이나 해석을 제시했을 때, AI가 “그럴 가능성이 있다”, “관찰이 일관적이다”, “흥미로운 해석이다” 와 같은 표현을 반복하면 사용자는 자신의 판단이 점차 검증되고 있다고 느끼게 된다. 문제는 이것이 단순한 대화 UX 차원의 문제가 아니라, 잘못된 판단을 스스로 강화하는 구조로 발전할 수 있다는 점이다.

이 논문이 특히 주목할 만한 이유는 이러한 현상이 비합리적인 사용자에게만 나타나는 것이 아니라는 점이다. 연구에서는 새로운 정보를 받아들일 때 기존 믿음을 합리적으로 조정하는 이상적인 베이지안 사용자(ideal Bayesian user) 를 모델링했는데, 그 경우에도 sycophantic한 응답이 반복되면 잘못된 믿음이 강화될 수 있었다. 즉, 사용자의 논리성 여부와 관계없이 AI와의 상호작용 구조 자체가 인지적 편향을 만들어낼 수 있다는 의미다.

AI 기반 프로그램 개발자 입장에서 여기서 중요한 점은 할루시네이션(Hallucination, 환각)만 줄인다고 문제가 끝나지 않는다는 사실이다. 논문은 AI가 거짓말을 하지 않도록 제한한 경우도 실험했지만, 위험은 완전히 사라지지 않았다. 이유는 AI가 사실만 말하더라도 사용자의 믿음을 강화하는 사실만 선택적으로 제시할 수 있기 때문이다. 즉, 문제는 사실 여부뿐 아니라 어떤 정보를 선택하고 어떤 정보를 제외하는가에도 있다.

AI를 활용해 개발할 때는 몇 가지 실무 원칙을 의식할 필요가 있다.

첫째, AI의 응답을 최종 결론처럼 받아들이지 않아야 한다.
둘째, 하나의 답변만 신뢰하기보다 다른 해석이나 반대 근거도 함께 확인해야 한다.
셋째, 반복적인 대화 속에서 특정 방향으로 사고가 편향되고 있지 않은지 스스로 점검해야 한다.
넷째, 설계·보안·성능·운영과 같이 영향이 큰 판단은 반드시 사람이 최종 검토해야 한다.

결국 이 논문이 AI를 활용하는 개발자에게 주는 메시지는 분명하다. AI는 틀린 정보를 생성할 때만 위험한 것이 아니라, 사용자의 현재 생각을 자연스럽게 강화하면서 잘못된 확신을 만들어낼 수도 있다. 따라서 AI 기반 개발에서는 정확도뿐 아니라 균형성, 반대 근거 확인, 최종 판단의 책임 주체를 함께 고려해야 한다.

AI를 활용해 개발할 때 원칙을 실천하는 현실적인 방법

예를 들어 개발자가 AI에게 “이 구조가 맞는지 검토해줘”, “내 설계 방향이 타당한가”, “이 방식이 가장 좋은 방법 아닌가” 와 같이 질문하면, AI는 이미 질문 안에 포함된 방향을 따라 답할 가능성이 높다. 즉, 객관적인 검토보다 현재 사용자의 사고 흐름을 이어주는 방식으로 응답하기 쉽다. 이 때문에 실무에서는 질문의 방향 자체를 의도적으로 바꾸는 습관이 필요하다. 예를 들어 다음 두 질문은 비슷해 보이지만 결과는 분명히 다르다.

이 구조가 맞는지 검토해줘
이 구조의 취약점과 실패 가능성을 먼저 찾아줘

첫 번째 질문은 확인을 유도하고, 두 번째 질문은 반박을 유도한다. 실제로 두 번째 방식이 더 많은 위험 요소를 드러낸다. 같은 방식으로 코드 생성 이후에도 바로 적용하기보다, 추가 검증 질문을 이어가는 것이 중요하다. 예를 들어 AI가 특정 구현을 제안했을 때는 다음과 같이 다시 질문할 수 있다.

이 코드가 운영 환경에서 실패할 가능성이 있는 경우는 무엇인가
예외 상황에서 깨질 수 있는 부분은 어디인가
최신 프레임워크 기준으로 문제가 될 수 있는 부분은 없는가

즉, 첫 번째 답변은 초안으로 보고 두 번째 질문부터 검증 단계로 들어가야 한다.

설계 단계와 구현 단계도 분리해서 보는 것이 좋다. AI는 설계 설명에서는 매우 자연스럽지만, 실제 코드에서는 중요한 조건을 빠뜨리는 경우가 적지 않다. 예를 들어 먼저 구조를 설명받은 뒤 다시 다음과 같이 물을 수 있다.

지금 설명한 구조가 실제 코드에서 깨질 수 있는 조건을 찾아줘
트랜잭션, 동시성, 예외 처리 측면에서 위험 요소를 설명해줘

이렇게 하면 단순 설명보다 실제 적용 시 발생할 수 있는 문제를 더 빨리 발견할 수 있다. 여러 AI를 함께 사용하는 경우에는 교차 검증도 효과적이다. 예를 들어 다음과 같은 흐름이 가능하다.

Codex 로 초안 작성
Claude 로 구조적 취약점 검토
Gemini 로 대안 비교

이 과정에서 중요한 것은 단순히 다른 모델에 다시 묻는 것이 아니라, 질문 자체를 다르게 주는 것이다.

예를 들어:

이 코드의 문제를 추측하지 말고 실제 코드 근거로만 지적해줘
반대 구현 방식이 더 적절할 수 있는 경우를 설명해줘

AI가 강한 확신을 보일수록 오히려 더 검증해야 한다는 점도 중요하다. AI는 매우 자연스럽게 “이 방식이 가장 적절하다”, “일반적으로 이렇게 구현한다” 와 같은 표현을 사용하지만, 이런 문장은 기술적 근거 없이 생성될 수도 있다. 따라서 이런 답을 받으면 반드시 다시 확인해야 한다.

공식 문서 기준 근거는 무엇인가
예외 사례는 없는가
다른 구현 방식과 비교하면 장단점은 무엇인가

결국 AI를 활용한 개발에서 중요한 것은 빠른 답을 받는 능력보다, 반대 질문을 던지고 검증 흐름을 만드는 능력이다. AI는 개발 속도를 높여주지만 동시에 빠른 확신도 제공한다. 따라서 개발자는 AI의 첫 답을 정답으로 받아들이기보다, 검토 대상이 되는 초안으로 다루는 태도가 필요하다.

사용기 - AI 가 다른 AI 의 작업 결과를 이어 받아 마무리 하기 (클로드 , 코덱스)

2026-04-06T15:26:00.002+09:00

AI 가 다른 AI 의 작업 결과를 이어 받아 마무리 하는 것은 어떻까.

이슈는 코덱스(Codex) 가 초안을 작성하고 클로드(Claude) 상세화 했다.

클로드(Sonnet 4.6) 계획 상세화 결과

코덱스(Codex)가 12개의 서브 이슈들로 구성된 언브렐라(#27) 이슈를 등록하고 클로드(Claude)에게 #27 이슈 구현을 요청했다.

클로드(Sonnet 4.6) 구현 결과

코덱스(Codex)에게 클로드(Claude)의 작업 브랜치의 상태를 분석하여 현재 진행 상황을 확인하고 작업을 마무리 하게 했다.

코덱스 (GPT 5.4 medium) 이어서 구현

클로드(Claude)에게 PR #40 에 대한 리뷰를 요청했다.

클로드(Sonnet 4.6) 1차 리뷰 결과

코덱스(Codex)에게 리뷰 결과를 조치하게 했다.

코덱스 (GPT 5.4 medium) 1차 리뷰 조치

클로드(Claude)에게 PR #40 에 대한 재 리뷰를 요청했다. 확인 결과 병합은 가능한 상태이지만 추가로 몇가지 마이너한 개선 사항이 도출되었다.

클로드(Sonnet 4.6) 2차 리뷰 결과(1차 리뷰 조치 확인)

코덱스(Codex)에게 다시 리뷰 결과를 조치하게 했다.

코덱스 (GPT 5.4 medium) 2차 리뷰 조치

다시 클로드(Claude)에게 리뷰를 요청했고 모든 이슈가 해결되었음을 확인 할 수 있었다.

클로드(Sonnet 4.6) 3차 리뷰 결과(2차 리뷰 조치 확인)

AI 모델에게 코드를 작성하게하고 같은 모델에게 리뷰를 시키면 코딩시 놓친 맹점이 리뷰할 떄도 그냥 넘어갈 수 있게된다. 참고로 보리스 체르니(Boris Cherny)가 공개한 Claude Code 내에서 코덱스(Codex) 를 사용하여 코드 리뷰를 수행하거나 Codex에 작업을 위임할 수 있는 플러그인이 Codex plugin for Claude Code 도 같은 맥락이다.

사용기 - 클로드, 코덱스, 제미나이 기반의 AI 코딩 : VUE 프로그램을 REACT 로 변경

2026-04-03T15:39:00.005+09:00

작업의 목표는 기존 Vue3 기반 프로젝트를 1.x, 2.x 브랜치로 구분하고, 2.x 브랜치에서 React 전환을 진행하는 것이었다. 단순히 특정 모델 하나만 사용하는 것이 아니라, 여러 AI 코딩 에이전트를 실제 작업에 투입해 계획 수립, 상세화, 구현, 리뷰, 병합의 각 단계에서 어떤 조합이 가장 효율적인지를 확인해보고자 했다

1. 최초 계획 수립 - Codex

최초 작업 계획은 Codex(GPT-5.4, reasoning effort: medium)를 사용해 수립했다. Codex는 전체 작업 방향과 단계별 흐름을 정리한 MIGRATION_2X.md 문서를 작성했다. 이 문서는 실제 개발을 바로 수행할 수 있는 상세 설계서라기보다는, 원칙과 단계별 진행 방향을 정리한 초안 성격의 계획서에 가까웠다.

이 단계에서 느낀 점은 Codex가 최초 구조를 잡고 작업을 시작하는 능력, 그리고 여러 작업을 분할해 병렬로 진행할 수 있도록 초기 작업 틀을 만드는 능력이 우수하다는 점이었다. 이후 이 문서를 기반으로 모든 이슈를 등록하는 작업도 Codex를 통해 수행했고, 총 12개의 이슈가 생성되었다.

2. 상세 계획 수립 - Gemini 중심, Codex 보조

클로드 공식 문서는 CLAUDE.md를 프로젝트 기억용 파일로 설명하고, /init로 시작용 CLAUDE.md를 자동 생성하라고 권고 하고 있다. 일관적인 작업 수행을 위해서 먼저 생성을 진행했다. 추가로 기존 프로젝트의 정책 및 템플릿 내용도 반영하도록 했다. Claude Pro 요금제의 가장 큰 불편함은 5시간 단위와 주간 단위의 사용 제한이다. 작업이 한창 진행되는 중간에 멈추는 경우가 반복되다 보니, 실제 사용성 면에서 답답함이 크다. 작업중에 주간 한계를 초과하여 금주 목요일 11:00 까지 기다려야 한다.

제한이 풀리자 바로 /init 명령을 실행했고, 클로드는 기존 프로젝트의 파일을 분석하여 CLAUDE.md 을 생성했다.

클로드(Sonnet 4.6) init 실행 결과

Claude 를 사용한 세부 계획 수립 계획을 변경하여 Gemini 2.5 Flash가 기존 MIGRATION_2X.md를 검토하여 세부 내용을 보완했고, 다시 Codex가 이를 검토하고 수정하는 방식으로 계획을 다듬었다. 다만 이후 실제 구현과 리뷰를 진행하는 과정에서, 작업 범위의 경계가 다소 모호하게 잡히는 경우가 있었고, 그 부분을 다시 Claude가 검토하면서 보완했다. 글 전체 흐름을 기준으로 보면 세부 계획 수립 능력은 Gemini보다 Claude가 더 안정적이었다고 판단된다.

제미나이(Gemini 2.5 Flash) 실행 가능성 검토

코덱스 (GPT 5.4 medium) 1차 검토

코덱스 (GPT 5.4 medium) 1차 검토 결과 보완

제미나이(Gemini 2.5 Flash) 2차 검토

다음으로 코덱스(GPT-5.4 reasoning effort : medium)를 사용하여 병렬작업을 고려하여 모든 이슈 등록과 변경된 문서을 커밋하도록 했다. (12개의 이슈가 등록됨)

생성되어 등록된 이슈 목록

이 과정에서 코덱스 역시 작업중에 주간 한계를 초과하였지만 미리 구매해두었던 토큰을 소모하면서 작업을 수행했다. 이 단계에서 얻은 결론은 다음과 같았다.

Codex: 최초 계획 초안 작성에 강점
Claude: 계획의 세부화와 경계 정리에 강점 (사용 제한으로 확인 못함)
Gemini: 계획 보완과 실행 가능성 판단에 충분히 유용함

3. 구현 - Codex와 Gemini 중심

실제 구현은 처음에는 Gemini(Free)를 통해 진행했다.

Gemini는 Plan 모드와 Edit 모드를 구분하고 있었고, 실제 코딩을 위해서는 Edit 모드 전환이 필요했다. 무료 버전임에도 불구하고, 구현 자체는 충분히 수행 가능했고, 리뷰 결과에 대한 수정도 상당히 잘 반영했다. 이 점에서 Gemini의 코딩 능력 자체는 충분히 확인할 수 있었다고 본다.

다만 사용량 제한에 도달하면 작업이 중단되는 문제가 있었고, 실제 작업 흐름을 이어가는 데에는 제약이 있었다. 그 이후 구현은 Codex가 이어받아 진행했는데, 이 과정은 서로 다른 모델 에이전트가 작업을 이어받을 수 있는지를 확인하는 좋은 사례가 되었다. Codex는 구현을 이어서 진행하는 데에도 무리가 없었고, 이후 병합 충돌 원인을 작업 히스토리 기준으로 파악하고 해결하는 모습도 인상적이었다.

실제 수행 흐름을 종합하면, 구현 단계에서는 다음과 같은 인상이 남았다.

Gemini: 무료 버전 기준에서도 구현 능력은 충분히 확인 가능
Codex: 구현의 연속성, 작업 유지, 충돌 해결, 마무리 처리에 강점

4. 리뷰 - Claude의 강점이 가장 분명했던 구간

구현 결과에 대한 검토는 주로 Claude를 통해 진행했다.

브랜치 리뷰, PR 리뷰, 리뷰 결과 확인, 추가 수정 요청 등 여러 단계에서 Claude를 반복적으로 사용했는데, 전체 흐름을 보면 이 부분에서 Claude의 장점이 가장 뚜렷하게 드러났다. Claude는 단순한 오류 지적이 아니라 작업 범위의 타당성, 보완 필요 지점, 수정 누락 여부를 비교적 안정적으로 짚어냈다.

Codex도 코드 리뷰를 수행했지만, 글의 흐름상 Codex는 리뷰어 역할보다는 직접 수정하고 정리하는 역할에서 더 자연스러웠다. 반면 Claude는 여러 차례 교차 검증 과정에서도 추가 수정 사항을 찾아냈고, PR 리뷰 품질도 일관적이었다. 따라서 리뷰 단계에 대해서는 Claude가 가장 적합했다고 판단된다.

코덱스 (GPT 5.4 medium) 코드리뷰 결과

클로드(Sonnet 4.6) 브랜치 리뷰 결과

5. 병렬 작업과 교차 검증에서 확인한 점

이번 작업에서는 단순히 하나의 모델만 쓰지 않고, 서로 다른 모델을 조합해 병렬 작업과 교차 검증도 시도했다. Codex가 지시문을 작성하고, Gemini와 Codex 서브에이전트가 각각 구현을 수행한 뒤, Claude가 리뷰를 담당하는 방식도 실험했다. 또한 Claude가 작업한 결과를 Codex가 리뷰하고, 다시 Codex 결과를 Claude가 리뷰하는 교차 방식도 시도했다.

이러한 과정을 통해 확인한 것은, 모델마다 잘하는 역할이 분명히 다르다는 점이다.

Codex는 실행과 정리에 강했다.
Claude는 계획의 정교화와 리뷰의 완성도가 높았다.
Gemini는 무료 버전 기준에서도 구현 능력을 보여주었다.

코덱스 (GPT 5.4 medium) 작업 결과

클로드(Sonnet 4.6) PR 리뷰 결과

다음으로는 작업을 서로 다른 모델 에이전트를 사용하여 진행해보았다. 이 작업위해서 코덱스를 사용하여 작업 지시를 위한 업무 계획을 정리하게 하게 한다음에 구현을 진행했다.

이번에는 보다 정확한 병렬을 위해서 코덱스가 지시문을 작성하게 했다. 하나는 제미나이에게 작업을 요청했고 하나는 코덱스 서브에이전트가 작업하도록 했다.

코덱스 (GPT 5.4 medium) 작업 지시문 생성

리뷰는 클로드를 사용하여 진행했다. 코덱스는 PR 까지 진행하여 PR 에 대한 리뷰를 (클로드가) 진행하고 (코덱스가) 결과 조치 후 다시 (크로드가) 리뷰를 진행했다. 코덱스는 1차 리뷰 결과에 대한 조치는 완벽하게 처리했고 2차 리뷰에 클로드에 의하여 추가 조치 사항이 발견되었으며 해당 내역역시 조치를 완료하는 것으로 리뷰 결과에 대한 조치 완전하게 처리함을 확인 할 수 있었다.

클로드(Sonnet 4.6) 1차 리뷰 결과

클로드(Sonnet 4.6) 2차 리뷰 결과

클로드(Sonnet 4.6) 3차 리뷰 결과

제미나이는 작업 완료 이후 커밋까지는 했지만 PR 생성은 불가하다고 하여 작업 결과불을 기준으로 리뷰를 진행했다. 제미나이 역시 리뷰 결과에 대한 조치를 완전하게 처리했다. PR 생성은 클로드가 진행했다.

클로드(Sonnet 4.6) 최초 브랜치 리뷰 결과

클로드(Sonnet 4.6) 조치 결과 확인

병렬도 조치한 작업에 대한 병합 과정에서 제미나이 구현에 대한 PR 에서 충돌이 발생하여 코덱스를 사용하여 이슈를 해결하고 병합을 마무리 했다.

깃랩 병합 이슈

코덱스가 작업 히스토리를 확인하여 원인을 파악하고 해결하는 과정이 인상적이었다.

코덱스 (GPT 5.4 medium) 병합 이슈 해결

코덱스를 통한 중간 정검(9/12)과 MIGRATION_2X.md 문서를 현횅화 했다. 또한 코덱스는 남은 이슈별 작업 기준을 정리하고 코덱스 서브에이전트와 제미나이 + 클로드가 구현을 진행했다. 리뷰는 클로드 한꺼번에 했고 보완 역시 코덱스가 한번에 처리했다.

클로드(Sonnet 4.6) 리뷰 결과 확인

이제 하나의 이슈만 남았는데 코덱스가 마무리 구현을 진행하고 클로드가 리뷰하게 했다.

클로드(Sonnet 4.6) 최종 리뷰 결과

작업 완료 후 로컬에서 직접 실행하여 화면을 확인해본 결과, 이번 계획의 범위였던 공통 기능을 포함한 사용자 파트의 React 전환은 완전하지는 않지만 전반적으로 잘 이관된 상태임을 확인할 수 있었다.

이번 실험을 통해 각 모델의 강점이 어느 정도 분명하게 드러났다.

특히 Gemini는 무료 버전을 사용했음에도 코딩 능력 자체는 충분히 확인할 수 있었다. 그러나 실제 실무에서 지속적으로 사용하기에는 사용량과 기능 제약이 존재했다. 반면 Codex는 최초 계획 수립, 구현, 이슈 정리, 병합 충돌 해결 등 실행과 연속성 측면에서 강점을 보였고, Claude는 상세 계획 수립과 리뷰, PR 검토 등 정교한 검토와 품질 보증 측면에서 가장 안정적이었다.

사용기 - 맥에서 클로드 코드(Claude Code) 사용하기 : Codex와 비교한 실사용 후기

2026-03-31T13:33:00.010+09:00

클로드 역시 코덱스와 같이 무료 플랜에서는 코딩 기능(Claude Code) 사용이 불가 하고 유료 플랜에서만 가능하다. 클로드 코드는 터미널, VSCode , Desktop app, Web, JetBrains 을 지원하고 있다. 테스트는 클로드 앱으로 진행했다. Desktop app 은 유료로 플랜을 업그레이드 하면 Code 탭이 활성화 되며 이를 클릭하고 로컬 저장소를 지정하는 것올 시작으로 바로 코딩 작업을 진행할 수 있었다.

유료 플랜은 Pro 요금제를 사용했다. 5시간 단위/주간 단위 사용량 제한 정책에 따라 가벼운 작업은 가능하지만 본격적인 코딩에는 무리가 있었고, 여러 테스트를 진행하는 과정에서 여러번 사용 제안이 걸려 추가로 $20 에 해당하는 토큰을 3회 구매해서 사용했다.

클로드는 기본적으로 실사용 인상으로는 작업을 여러 단계로 나눠 처리하는 듯한 흐름이 있었고, 그만큼 토큰 사용량이 커진다고 느꼈다. 코딩 성능은 확연하게 멀티 즉 서브 에이전트를 사용하는 것과 하지 않는 것에는 차이가 발생한다. 여러 단계의 중간 결과가 정리되면서 응답 품질이 더 안정적으로 느껴졌고, 개인적으로는 그것이 결과 차이에 영향을 준다고 보았다. (컨텍스트 오염 최소화)

오류 해결 테스트 (코덱스와 클로드)

비교를 통한 성능 측정을 목적으로 간단하게 런타임 오류 메시지에 대한 분석을 각각 ① Claude Sonnet 4.6 , ② GPT-5.4 (reasoning effort : medium) 을 사용하여 진행했다. 두 모델 모두 원인 분석 자체는 유효했지만, 이번 테스트에서는 Claude Sonnet 4.6 쪽이 번호와 표를 더 적극적으로 사용해 결과를 읽기 쉽게 정리해 주는 인상이 있었다.

코덱스 (GPT 5.4 medium) 답변

클로드 (Sonnet 4.6) 답변

“Claude는 분석만 요청했는데도 수정 방향까지 적극적으로 제안했다. 상황에 따라서는 장점이지만, 순수 분석만 원할 때는 과한 개입으로 느껴질 수 있었다.”( 아마도 코덱스의 경우는 호환 정책 파일들이 있어 발생한 것은 아닌가 하는 의심도 있다.)

기존 코드 기반 계획 수립 테스트 (코덱스와 클로드)

다음으로 소스 코드 분석을 실행하고 결과를 비교해 보았다.

"*** 는 사용자 시스템 구현에 의존하지 않고 사용자를 식별할 하기 위한 계약이다. 이 모듈 코드를 좋은점, 나쁜점, 개선점 측면에서 분석하고 결과를 보여줘."

Claude (Sonnet 4.6) 답변

Codex (GPT 5.4 medium) 답변

결과가 예상과는 달랐는데 나쁜점의 경우 모두 거의 유사한 내용을 언급하고 있지만 좋은점과 개선점에서는 차이점이 있었다. 답변은 모두 코드에 근거하여 답변을 하고 있었다.

이번 테스트 기준으로 클로드는 ‘바로 손볼 포인트를 빠르게 정리해 주는 리뷰’에 가까웠고, 코덱스는 ‘왜 그렇게 바꿔야 하는지까지 설명하는 리뷰’에 가까웠다. 이번 항목에서는 개인적으로 코덱스 쪽 답변이 더 좋았다. 특히 구조적 설명과 개선 논리 제시에 강점이 있었다고 느꼈다.

① 클로드

구체적인 결과 = 항목화된 판정 + 예시 코드 즉,

무엇이 좋은지
무엇이 나쁜지
무엇을 바꿔야 하는지

를 표와 목록으로 끊어서 보여준다. (정리본 형태)

② 코덱스

구체적인 결과 = 모듈 의도 + 실제 사용처 + 개선 논리 즉,

이 모듈이 왜 존재하는지
실제로 어디서 어떻게 쓰이는지
그래서 어떤 혼란이 생길 수 있는지

를 설명 흐름 안에서 보여준다. (리뷰 대화록 형태)

협업 테스트(코덱스와 클로드)

이번 테스트는 ① 클로드와 ② 코덱스 모두에게 코드 분석을 요청하고 ① 클로드의 경우 추가로 문서화 생성을 요청하고 해당 문서를 ② 코덱스에게 검토 및 보완을 요청했다. 마지막으로 다시 수정된 문서를 ① 클로드를 통하여 검증하는 작업을 진행했다. 아래는 최종 검증에 있어 코덱트의 출력 화면이다.

이번 실험에서는 단일 모델 하나만 쓰는 방식보다, 서로 다른 모델의 장점을 교차 활용하는 편이 결과를 더 안정적으로 만드는 가능성을 보였다. 서브 에이전트와 같은 기능을 적극적으로 쓰지 않고 프롬프트 중심의 단순 작업만 놓고 보면, 이번 체감상 코덱스보다 클로드가 더 일을 잘한다고 느껴졌다.

이슈 기반 개발

테스트에 앞서 코덱스에서 분석 및 작업 계획 테스트를 통하여 이슈를 생성하였고 클로드에서는 이미 생성된 특정 이슈를 기준으로 실제 구현 작업을 진행해 보았다. (개발은 언제나 항상 분석/설계 > 이슈 등록 > 구현 > 테스트 > PR 생성 > 리뷰 > 머지 순서로 하고 있다.)

다음은 이슈 기반을 개발을 위하여 클로드에게 작업 가능성 확인 결과이다.

이슈 #163 에 대한 작업이 가능한가.

작업 이슈 내용을 바탕으로 기존 파일을 분석하여 수행했다.

작업 완료 후 커밋과 PR 생성을 요청했고 해당 PR 을 코덱스가 검토하게 했다. 코덱스 검토 결과 1가지 문제가 발견되었고 이를 다시 클로드가 조치하도록 했다. (전후 맥락이 없는 상태에서 리뷰를 진행할 때는 좀더 많은 시간이 소요됨을 체감했다.)

리뷰 결과를 클로드에서 입력하면 해당 내용을 확인하고 잘못 수정함을 인정하고 바로 수정까지 완료했다. (리뷰의 중요성이 확인됨)

조치결과에 대하여 코덱스에 다시 확인 요청을 한 결과 처리됨을 바로 확인해주었다. (이전 맥락이 있어 이번에는 바로 응답함)

정리하면, 이번 테스트 기준으로 Claude는 정리형·실무형 리뷰에 강했고, Codex는 설명형·구조형 리뷰에 강했다. 따라서 둘 중 하나만 고르기보다, 분석·문서화·교차 검토 흐름으로 함께 활용할 때 더 큰 장점이 있을 수 있다고 본다.

사용기 - 코덱스(Codex)에서 서브에이전트(Subagents) 활용하기

2026-03-31T10:25:00.003+09:00

Subagents란, Codex가 하나의 큰 작업을 여러 개의 작은 작업으로 나누어 각각 별도의 보조 에이전트에게 맡긴 뒤, 그 결과를 다시 통합하는 병렬 작업 방식이다. 복잡한 작업, 코드베이스 탐색, PR 리뷰 처럼 여러 항목을 동시에 볼 때 특히 유용하다고 한다. OpenAI 개발자 가이드

서브에이전트(subagent)는 언제 어떻게 사용하나

공식 문서에 따르면 컨텍스트 창(에이전트의 스레드 기억 공간)이 크더라도 요구사항, 제약조건, 의사결정 같은 핵심 정보 사이에 탐색 노트, 테스트 로그, 스택 트레이스, 명령 출력 같은 중간 결과가 과도하게 섞이면 모델의 응답 품질과 세션 신뢰성이 점차 떨어질 수 있다고 한다. 이런 문제는 중요한 정보가 잡음에 묻히는 맥락 오염과, 관련 없는 세부 정보가 많아지면서 판단 성능이 저하되는 맥락 왜곡으로 설명할 수 있다. (Context Rot: How Increasing Input Tokens Impacts LLM Performance)

서브에이전트 워크플로(Codex가 병렬 에이전트를 실행하고 그 결과를 결합하는 워크플로)는 이러한 잡음을 메인 스레드에서 분리하여, 메인 에이전트는 핵심 요구사항과 최종 결과에 집중하고, 탐색·테스트·로그 분석 같은 읽기 중심 작업은 하위 에이전트가 병렬로 처리한 뒤 요약만 반환하도록 돕는다. 다만 병렬 에이전트는 읽기 작업에는 효과적이지만, 여러 에이전트가 동시에 코드를 수정하는 쓰기 중심 작업에서는 충돌과 조정 비용이 커질 수 있으므로 더 신중하게 운영해야 한다.

즉 맥락 오류가 커질수 있는 큰 작업을 여러 덩어리로 나눌 수 있을 때 좋은 결과를 예상할 수 있는데. 예를 들면 “보안”, “버그”, “코드 품질”, “테스트 불안정성”을 각각 따로 검사시키는 식이다. Codex는 용사자가 명시적으로 요청할 때만 서브에이전트(subagent)를 실행한다. 그리고 서브에이전트(subagent)가 늘어나면 그만큼 모델 호출과 도구 사용이 늘어서 토큰 비용도 더 많이 발생한다.

Prompt 예시

다음 작업을 subagent로 분할해줘.
- explorer 1개: 인증 구조 파악
- worker 1개: 로그인 API 구현
- worker 1개: 테스트 추가
- default 1개: 전체 결과 통합 정리
모든 작업이 끝난 뒤 최종 보고서를 작성해.

“명시적으로 요청”한다는 것은, Codex가 알아서 subagent 를 만들 거라고 기대하는 것이 아니라, 프롬프트 안에 spawn, one agent per point, explorer subagent 를 생성, worker를 사용처럼 분업 지시를 직접 써주는 것이다.

Codex는 중간 관리자 역할을 수행

어떤 서브에이전트(subagent)를 띄울지, 후속 지시를 어떻게 줄지, 결과를 언제 모을지 등을 Codex가 조율하고 마지막에는 결과를 합쳐서 하나의 응답으로 보여주는 역할을 한다.

Prompt 예시

현재 브랜치와 main을 비교해서 PR을 검토해.
항목별로 subagent를 하나씩 생성해.
모든 subagent의 작업이 끝날 때까지 기다린 뒤, 항목별 결과를 요약해줘.
1. 보안 이슈
2. 코드 품질
3. 버그 가능성
4. 동시성 문제
5. 테스트 불안정성
6. 유지보수성

이 프롬프트를 받으면 Codex는 다음을 조율한다.

어떤 서브에이전트(subagent)를 띄울지 정한다.
예를 들어 보안 검토용, 테스트 검토용, 유지보수성 검토용처럼 항목별 서브에이전트(subagent)를 분리한다. 문서상 Codex는 서브에이전트(subagent)를 생성하고 오케스트레이션하는 역할을 한다.
각 서브에이전트(subagent)에 후속 지시를 전달한다.
예를 들어 “보안 서브에이전트(subagent)는 인증/인가 흐름을 보라”, “테스트 서브에이전트(subagent)는 누락된 테스트를 찾으라”처럼 작업을 나눠 보낸다. 공식 문서도 Codex가 follow-up instructions를 라우팅한다고 설명한다.
결과를 기다린다.
여러 서브에이전트(subagent)가 동시에 돌고 있으면 Codex는 요청한 결과가 모두 준비될 때까지 기다린다.
마지막에 하나로 합친다.
각 서브에이전트(subagent)의 결과를 항목별로 묶어 최종 응답으로 정리해 보여준다. 공식 문서에서는 consolidated response로 설명한다.

Codex 내장 서브에이전트(subagent)

default(범용), worker(구현/수정 중심), explorer(읽기 중심 탐색) 같은 기본 agent가 이미 제공되고 있다.

default: 특별히 역할을 안 나눴을 때 쓰는 범용 담당
worker: 실제 수정, 구현, 정리, 반복 작업 담당
explorer: 파일 찾기, 구조 파악, 원인 추적 전 단계 담당

Prompt 예시

worker를 사용해서 로그인 API를 구현해줘.
요구사항:
- 이메일/비밀번호 로그인
- JWT 발급 포함
- 기존 SecurityFilterChain 구조를 유지
- Controller, Service, DTO까지 구현
- 관련 테스트도 함께 추가
결과는 변경 파일 목록과 함께 요약해줘.

커스텀 서브에이전트(subagent)

TOML 파일로 “이 agent는 PR 리뷰 전용”, “이 agent는 문서 조사 전용”처럼 역할을 따로 정의할 수 있다. (최소한 name, description, developer_instructions 필요.) 좋은 서브에이전트(subagent)는 공식 문서에 따르면 “좁고 명확한 역할을 가져야 한다”고 설명하고 있다. 즉, 하나의 서브에이전트(subagent)가 다 하게 하기보다 “코드 탐색용”, “보안 리뷰용”, “문서 조사용”처럼 나누는 게 좋다.

용자 정의 서브 에이전트를 사용하기 위해서 특정 개발 작업을 위해 설계된 특수 AI 보조 도구인 Codex 서브에이전트 의 최종 모음집 저장소 Awesome Codex Subagents 을 활용했다.

최종적으로는 AI 지원 개발을 일관된 규칙, 템플릿, 자동화 스크립트로 표준화해 배포할 수 있게 만든 DevOps 정책 템플릿 저장소를 구성하여 사용했다. ( https://github.com/andang72/devops-policy-template )

먼저 세부 계획을 병렬로
서브에이전트 1: 현재 패키지/모듈 구조 분석 서브에이전트 2: 중복 책임, 순환 의존, 경계 위반 탐지 서브에이전트 3: 테스트 영향 범위와 회귀 위험 분석 서브에이전트 4: 후보 리팩토링 포인트 요약
를 통해서 수립해줘.

이렇게 프롬프트를 작성하면 코덱스는 병렬 작업에 맞게 작업 계획을 수립한다.

계획이 수립되면 이슈를 등록하게 하고 순서대로 작업을 아래와 같이 특정 서브에이전트에게 진행을 요청한다.

서브에이전트에 의한 작업은 좌측 스레드 목록이나 하단의 작업 목록 아래의 background agents (@ to tag agents ) 를 통하여 확인 할 수 있다.

좌측 메뉴

하단 메뉴

서브에이전트를 도입하면 단순 오류 수정이 아닌 기존 코드를 분석하여 기능을 수정하거나 추가하는 경우 확연하게 결과가 개선되는 것을 확인할 수 있었다. 다만 서브에이전트를 사용하는 경우 토큰 소비가 크게 증가하기 때문에 이부분에 대한 사전 고려가 필요할 것 같다.

사용기 - 맥에서 Codex 앱 경험하기

2026-03-23T13:23:25.441+09:00

https://openai.com/ko-KR/codex/get-started/ 방문하여 맥용 앱을 다운로드하여 설치하였다. (지금은 윈도우즈 버전까지 출시되었다.)

처음 앱을 실행하면 Select a project 창이 보여지는데, 로컬에 존재하는 여러 Git 프로젝트 목록을 보여주고 선택하게 하는 것이 처음 사용하는 사용자에게는 도움이 될 것 같다.

VisualStudio Code 에서 Codex 확장을 사용하여 코딩에 활용하고 있었는데 Codex 앱은 좌측에 이들 프로젝트 목록(앞선 Select a project 에서 선택함 ) 과 그동안 해당 프로젝트에서 입력했었던 프롬프트까지 모두 보여준다. 또한 작업중에도 프롬프트는 계속 입력이 가능한데 입력된 프로프트들은 스티어링(Steering) 상태가 되는데 진행 중인 프롬프트가 완료되면 바로 이어서 진행하게 된다. 이점은 미리 다수의 프롬프트를 순차적으로 입력해두면 이어서 연속적으로 작업을 수행하는 점이 좋았다.

스티어링(Steering)은 “처음부터 다시 시키지 않고, 지금 하던 작업에 추가 지시를 넣어 방향 수정하는 것”으로 조금 더 구체적으로 보면, Codex App Server 문서에는 turn/steer 가 있고, 이것은 현재 실행 중인 turn에 사용자 입력을 덧붙여 새로운 turn을 만들지 않고 계속 진행하게 하는 방식이라고 한다.

모델은 응답 속도 이슈로 GPT-5.2-Codex Low 을 사용했다. 사실 High 모델을 사용해도 별 품질 차이를 느끼지는 못했지만 속도는 매우 느렸다. 사용 과정에서 모델이 추가되어 GPT-5.3-Codex Low 를 주로 사용하게 되었다.

테스트 과정에서 사용한 코딩 환경 및 목표는 아래와 같다.

eGovFrame 4.3.0 (Spring 5.3.37, Spring Security 5.8.13) + 자체 프레임워크 기반 웹 프로그램을
전자정부 프레임워크 와 자체 프레임워크 기반의 웹 프로그램을 스프링 부트 기반으로 변경
자체 프레임워크는 최신 버전으로 다시 적용, 적용 불가시 신규 코드 작성하여 적용.
UI 부분의 오류 제거 및 중복 파일 삭제. 특희 kendoui 관련 부분 최적화.
패키지 명 등 구조 리팩토링 (유지보수를 고려하여)

코딩 진행은 프로젝트의 단일 스레드가 아니라 context window 크기를 고려해서 작업 단위를 다음과 같이 쪼게서 다중 스레드로 진행했다. 참고로 context window 는 지금 스레드(세션) 에서 사용중인 대화전체 기억을 의미하는데 메뉴에서는 아래와 같은 형태로 보여주고 있다.

위 화면에서 현 코덱스의 최대 258k 토큰을 기억할 수 있고 지금 까지 176k 토큰 기억 메모리를 사용중이라는 의미이다.

기존 프로젝트 구조 분석을 통한 리팩토링(가능한 기존 구조 유지).
리팩토링 결과물 디버깅을 통한 런타임 오류 수정.
새로운 자체 프레임워크 적용 (단계적 기존 모듈 삭제).
업무모듈 리팩토링 기준 설정 및 리팩토링 진행.
리팩토링 결과물 검토에 따른 코드 개선.
코드 기반 수정에 따른 UI (jsp) 런타임 오류 수정.

각 스레드가 이전 스레드 작업 또는 다른 스레드 작업의 이력을 확인 할 수 있게 작업 후에는 README, CHANGELOG, TODO 등의 문서를 작성/업데이트 하게 했다. 스레드가 다른 스레드 작업을 이어 계속 진행할 수 있도록 문서화는 최종 목표, 진행 현황등을 파악 할 수 있데 작성을 지시했다.

또한 코딩 성능 개선을 위해서 OpenAI의 창립 멤버이자 전 Tesla AI 이사인 안드레 카파시(Andrej Karpathy)가 신경망(Neural Networks) 및 딥러닝 모델을 훈련하고 디버깅할 때 제안한 핵심 원칙과 모범 사례(Best Practices) 파일은 SKILL.md 파일을 추가하여 항상 가이드 라인을 준수하게 했다. 적용 후 처음은 그 차이를 인지하지 못했지만 작업을 반복하는 과정에서 codex 가 작업의 범위를 축소하고 언제가 작은 단위로 쪼게서 작업을 수행하는 것을 확인 할 수 있었다. 이런 이유에서 계속해서 프롬프트를 입력하여 다음 작업을 진행하도록 해야 했다.

예상보다 작업 속도와 품질은 매우 높았다. 예를 들면 기존 스프링 프레임워크 환경에서 xml 로 정의된 컨텍스트 파일들을 java 코드로 변경하는 작업의 경우 기존 코드와의 연관성 등을 고려하면 상당한 난이도 작업이지만 큰 실수 없이 코드 만들어 낸다.

주의할 것은 반복적으로 개선 작업을 진행하는 과정에 이미 완료된 코드도 같이 수정하는 경우가 많아 다시 확인해서 보완 조치 하는 경우가 빈번하게 발생한 것은 많은 집중을 요구했다.

결국 작업을 반복하여 지속적으로 코드를 개선하는 경우는 중간 중간 품질을 확인하고 잘못된 점을 지적해야 했다.

어느 정도 리팩토링 작업이 완료되고 UI 기능을 변경하는 작업을 해보았다. 화면의 경우 더 쉽게 처리하는 것 같다. 예를 들어 기존에 어떤 메뉴는 로그인 전에 클릭하면 로그인 창을 보여주었는데 어떤 메뉴는 경고 후 메인 페이지로 이동으로 구현되어 있는것을 수정해달라고 요청했고 결과(작업속도, 품질)는 만족스러웠다.

코딩 이외의 작업도 진행했는데, 로컬 도커에 이미 설치된 mysql 에 연결된 개발 서버 디비의 모든 데이터를 포함하여 이관해달라고 작업을 요청해보았다. 작업을 위한 몇번의 권한 요청을 했고, 진행 과정에서 오류가 발생하면 바로 해결방안을 찾아서 작업을 이어 진행했다. 이관 완료 후에는 검증을 위하여 테이블 과 데이터 건수 검증까지 이어서 처리했다, 이 모든 작업을 스스로 진행하고 작업을 위한 권한 요청에 대한 승인 만허용하여 데이터 이관을 완료 했다.

마지막으로 Codex 사용에 있어 주요했던 것은 정책(코딩 규칙)을 수립하고 규칙에 따라 작업을 진행할 것을 요청한 점이였다.

사용기 - 윈도우에서 AI 코딩 사용하기 (Codex)

2026-03-05T17:15:00.041+09:00

과거에는 개발자가 직접 코드를 작성하고 디버깅하는 방식이 일반적이었으나, 현재는 AI가 코드 생성, 테스트, 디버깅, 문서 작성 등 다양한 개발 작업을 지원하는 환경으로 전환되고 있다. 특히 AI 코딩 도구와 에이전트 기반 개발 환경의 확산으로 인해 개발 생산성을 크게 향상시킬 수 있으며, 복잡한 시스템 개발에서도 효율적인 작업이 가능해지고 있다.

이러한 변화에 따라 많은 개발 조직에서는 AI 기반 개발 도구를 적극적으로 도입하고 있으며, 개발 환경 또한 이러한 도구들이 원활하게 동작할 수 있도록 재구성하고 있다. 특히 AI 기반 개발 환경에서는 코드 분석, 자동 테스트, 컨테이너 실행, 인프라 구성 등 다양한 작업이 동시에 이루어지기 때문에 안정적이고 일관된 개발 환경이 중요하다.

많은 기업에서 개발자의 작업 환경으로 Windows 운영체제를 사용하고 있으나, 실제 소프트웨어 실행 환경은 대부분 Linux 기반 서버나 컨테이너 환경에서 운영되는 경우가 많다. 이러한 환경 차이는 개발 단계에서 다양한 문제를 발생시킬 수 있으며, 특히 라이브러리 의존성, 파일 시스템 차이, 실행 환경 차이 등으로 인해 개발과 운영 환경 간의 불일치가 발생할 가능성이 있다.

이러한 문제를 해결하기 위해 Windows 환경에서는 WSL(Windows Subsystem for Linux)을 활용한 개발 환경 구성이 널리 사용되고 있다.

WSL은 Windows 운영체제 내부에서 Linux 환경을 실행할 수 있도록 지원하는 기능으로, 개발자는 Windows 환경을 유지하면서도 Linux 기반 개발 도구와 환경을 그대로 사용할 수 있다. 이를 통해 개발자는 Linux 서버 환경과 동일한 개발 환경을 로컬에서 구축할 수 있으며, 다양한 오픈소스 개발 도구와 패키지를 보다 안정적으로 사용할 수 있다.

특히 AI 기반 개발 환경에서는 Python 기반 AI 도구, 컨테이너 환경, 패키지 관리 시스템 등 Linux 환경에 최적화된 기술들이 많이 사용된다. 예를 들어 AI 모델 실행 환경, 벡터 데이터베이스, 컨테이너 기반 서비스 등은 Linux 환경에서 보다 안정적으로 동작하는 경우가 많다. WSL을 활용하면 이러한 기술을 Windows 환경에서도 동일하게 사용할 수 있어 개발 환경의 일관성을 확보할 수 있다.

또한 WSL 환경에서는 Docker, Kubernetes, Git, Python 패키지 관리자 등 다양한 개발 도구를 Linux 환경과 동일하게 사용할 수 있으며, 이는 AI 기반 개발 도구와의 호환성을 높이는 데에도 중요한 역할을 한다. 최근 등장한 AI 기반 개발 도구들 또한 Linux 환경을 기본 실행 환경으로 가정하고 설계되는 경우가 많기 때문에, WSL 기반 개발 환경은 AI 코딩 도구의 활용성을 높이는 데에도 효과적이다.

개발자는 Windows 환경에서 Visual Studio Code와 같은 개발 도구를 사용하면서도, 실제 코드 실행과 빌드 작업은 WSL 내부의 Linux 환경에서 수행할 수 있다. 이러한 방식은 Windows의 편리한 사용자 환경과 Linux의 안정적인 개발 환경을 동시에 활용할 수 있다는 장점을 가진다. 특히 Visual Studio Code는 WSL과의 통합 기능을 제공하여 Windows에서 실행되는 IDE가 WSL 내부의 Linux 환경에 직접 연결되어 개발 작업을 수행할 수 있도록 지원한다.

이와 같은 구조는 AI 기반 개발 환경에서도 매우 효과적으로 활용될 수 있다. 예를 들어 AI 코딩 도구를 통해 생성된 코드가 Linux 기반 컨테이너 환경에서 바로 테스트되도록 구성하거나, 자동화된 빌드 및 테스트 프로세스를 Linux 환경에서 실행하도록 설정할 수 있다. 이러한 환경은 실제 운영 환경과 유사한 개발 환경을 제공함으로써 개발 과정에서 발생할 수 있는 환경 차이를 최소화하는 데 도움을 준다.

결론적으로 AI 기반 개발 환경을 도입하는 과정에서는 단순히 AI 도구를 사용하는 것뿐만 아니라, 이러한 도구들이 안정적으로 동작할 수 있는 개발 환경을 구축하는 것이 중요하다. Windows 환경을 사용하는 개발 조직의 경우 WSL을 활용한 Linux 기반 개발 환경을 함께 구성함으로써 개발 환경의 일관성을 확보하고, AI 기반 개발 도구와의 호환성을 높이며, 전체 개발 생산성을 향상시킬 수 있다. 이러한 접근 방식은 향후 AI 중심 개발 환경으로의 전환 과정에서도 중요한 기반이 될 것으로 기대된다.

WSL 환경 설치하기

윈도우에서 "PowerShell" 을 검색창에 입력하면 설치된 경우 PowerShell 터미널을 그렇지 않는 경우는 설치를 위한 Microsoft Store 로 이동한다. 설치를 완료하면 열기 버튼이 활성화 되는데 이를 클릭해도 "PoswerShell" 이 실행된다.

코딩 에이전트(Codex CLI 같은 것)나 레포 자동 빌드/테스트는 윈도우보다 리눅스 환경이 명령 실행/경로/권한 문제가 적어서 안정적이라고 한다. 이런 이유에서 코딩 에어전트 이용을 위해서는 “윈도우에선 WSL2(Windows Subsystem for Linux 2) 권장” 이 자주 언급된다.

설치 여부는 " wsl -l -v" 명령을 PowerShell 에 입력하여 확인 할수 있다.

wsl --status
wsl -l -v

가장 쉬운 설치 방법은 "PowerShell" 을 관리자 계정으로 실행하고 "wsl -- install" 명령으로 설치 할 수 있다. 특정 배포판 설치도 가능한데 설치 가능 배포한 목록은 "wsl --list --online" 명령으로 확인 가능하다. 이때 wsl 이 설치되어 있지 않았다면 자동 설치한다.

명령을 실행해보면 상당한 수의 배폰본은 지원하고 있음을 알 수 있다. 보통은 우분투를 가장 많이 사용한다고 하며 디폴터 설치 배포본 역시 우분투이다.

설치 전에 상태 확인이 필요한데 " wsl --status" 명령으로 확인 할 수 있다.

WSL1(리눅스 명령을 윈도우가 번역하여 수행), WSL2 (가상화를 통한 리눅스 지원) 에 대한 활성화 작업이 필요하다. 지금 위의 환경에서는 모두 비활성화 상태이다.

활성화는 PowerShell 을 관리자 권한으로 실행하고 아래 명령을 입력하면 된다.

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart

또는 시작 메뉴에서 "Windows 기능 켜기/끄기 를 실행하고 아래 기능을 채크 한다음 윈도우를 재시작 한다.

가상 머신 플랫폼(Virtual Machine Platform)
Linux용 Windows 하위 시스템(Windows Subsystem for Linux)

설치는 PowerShell 을 관리자 권한으로 실행하고 "wsl --install" , "wsl --install -d Ubuntu" 명령으로 할 수 있다.

설치가 완료되면 계정 생성을 진행하게 된다. 계정생성이 완료되면 가장 먼저 시스템을 업데이트 한다.

sudo apt update
sudo apt upgrade -y

WSL 환경에서 개발 도구 설치하기

다음 단계는 AI Agent 기반 개발 환경을 만들기 위한 개발 툴 체인을 설치하는 것이다.

1) 기본 시스템 도구

항목	설치 목적	설치 명령	확인 명령
curl	API 호출 및 다운로드	sudo apt install -y curl	curl --version
wget	파일 다운로드	sudo apt install -y wget	wget --version
unzip / zip	압축 파일 처리	sudo apt install -y unzip zip
git	소스 코드 버전 관리	sudo apt install -y git	git --version

2) 자바 개발 환경

항목	설치 목적	설치 명령	확인 명령
OpenJDK 17	자바 실행 환경	sudo apt install -y openjdk-17-jdk	java -version
Gradle	Java 빌드 도구	sudo apt install -y gradle	gradle -v

3) AI 코딩 Agent

항목	설치 목적	설치 명령	확인 명령
Codex CLI	AI 코드 생성 및 수정	npm install -g @openai/codex	codex --help
Aider	AI 코드 수정 도구	pip install aider-chat	aider --help

DE(VS Code)에서 Codex Agent를 설치한다면 WSL에 Codex CLI를 반드시 설치할 필요는 없지만 CLI 가 할 수 있는 작업이 더 많기 때문에 보통은 같이 사용한다. (npm 이 디폴트로 설치되어 있지 않아 sudo apt intall -y npm 명령으로 설치가 필요하다.)

추가로 Ubuntu 22.04 이후부터는 직접 시스템에서 사용하는 Python 을 변경하지 못하게 막고 있어 pipx 사용이 가장 안전한 방법이다.

sudo apt update
sudo apt install -y pipx python3-venv

pipx ensurepath

터미널을 다시 실행하고 aider 을 설치한다.

pipx install aider-chat

다음으로 자신의 환경에 필요한 빌드 도구를 설치한다. Visual Studio Code는 https://code.visualstudio.com/ 에서 다운로드하여 설치 할 수 있다.

IED 도구 vscode 을 사용 중이라면 WSL 확장을 아래 명령으로 설치하고 PowerShell 에서 프로젝트 로 이동하고 code . 을 입력하여 VS 코드 리눅스 환경에서 실행할 수 있다.

code --install-extension ms-vscode-remote.remote-wsl

VSCode 에서 Extenctions (Ctrl+Shift+X) 를 크릭하여 wsl 을 검색하여 설치할 수 도 있다.

VSCode 기반의 AI 코딩을 위해서 아래의 확장들은 거의 필수이다. (AI Agent 만 선택)

① Remote - WSL
② GitLens , SVN (vscode-svn extension)
③ OpenAI Codex (선택)
④ GitHub Copilot (선택)
⑤ Docker

⑥ 기타 : Gradle for Java

AI 코딩 시작하기

먼저 레파지토리에서 프로젝트를 가져온다. WSL 환경에 소스를 가져와야 하기 때문에 workspace 폴더를 생성하고 여기에서 다음 명령으로 소스를 가져온다.

GitLab 프로젝트 페이지 → Clone 버튼에서 URL을 복사
git clone <HTTPS_URL>

이제 VS 코드를 실행하고 Ctrl + Shift + P 을 입력하여 명령 팔레트를 열고 WSL 을 입력하여 명령 목록에서 클릭하여 WSL환경에 연결한다.

이제 폴더를 열면 된다. 보통은 "Do you trust the authors of this workspace?" 메시지가 나오는데 신뢰한다고 답을 하면 된다.

이제 좌측 아이콘에서 Codex 클릭하고 로그인 / 인증키 입력 한다. CLI와 IDE 확장은 동일한 로그인 정보를 공유하도록 설계되어 있어 터미널에서도 CLI 을 사용이 가능하다.

터미널에서 codex 을 실행하고 다음에 아래와 같은 간단한 명령으로 코드를 리뷰하게 할 수 있다.

"review this code focusing on security issues"

Codex 앱 사용하기

Codex 사이트(https://openai.com/ko-KR/codex/)를 방문하면 맥/윈도우 용 앱을 다운로드 할 수 있다. (2026.03.04 일 부터 윈도우지원)

윈도우용 Codex 앱은 PowerShell + Windows Sandbox (네이티브 센트박스) 기반으로 에어전트가 작업을 실행하며 필요하면 WSL 에서 실행하도록 구성하여 사용할 수 있다.

앞에서 설치한 VS Code 확장(Codex in IDE) + WSL 와 함께 아래와 같이 역할을 구분하여 사용할 수 있다.

VS Code 확장(Codex in IDE) : “에디터 안에서” 코드 편집/대화 중심
Codex 앱 : “에이전트 관제센터”처럼 프로젝트/작업을 여러 개 굴리고, Windows Sandbox/PowerShell 또는 WSL 중 선택해 실행

Codex 앱에 프로젝트를 추가할 떄는 WSL 의 경로를 사용하는 것이 좋다. 앞서 WSL 에서 생성한 프로젝트는 윈도우 파일 탐색기의 Linux 아이콘을 클릭하여 해당 프로젝트 경로를 찾아 추가할 수 있다.

프로젝트 추가를 위한 가장 쉬운 방법은 1) PowerShell 에서 wsl 명령으로 WSL 에 연결하고 해당 프로젝트로 이동하여 2) explorer.exe . 명령을 입력하면 탐색기로 리눅스 파일시스템을 확인 할 수 있다. 3) 파일 탐색기에 보여지는 이경로로 프로젝트를 추가하면 된다.

에어전트 환경 모드는 좌측 하단의 설정 > 일반 의 Agent environment 설정에서 Windows Subsystem for Linux 와 Windows Native 를 선택할 수 있게 되어 있다.

간단하게 "문서를 확인해서 프로젝트 구조 및 향후 과제를 확인해줘." 프롬프트를 입력해본댜. (모델은 GPT 5.3 Codex , 낮음 을 선택했다.

다음은 전체 개발 환경을 도식화 한 것이다.

2012 맥미니 "초기 설정값으로 재설정" 하기

2025-05-05T19:23:00.000+09:00

2012 맥미니에 설치된 macOS 을 "초기 설정값으로 재설정" 하여 파일 공유 서버로 용도로 재활용하기로 했다. 가능한 리모트 방식으로 진행하였지만 마지막 작업은 모니터, 마우스 그리고 키보드를 직결하여 마무리 했다.

macOS Catalina 다운로드

앱스토어를 통한 다운로드는 불가능하기 떄문에 콘솔에서 10.15.7 버전을 다운로드 했다.

macOS Catalina와 호환되는 컴퓨터 자료를 보면 Mac mini(2012년 후반 모델) 지원하는 macOS 임을 확인할 수 있다.
Catalina 는 22년 7월에 배포된 10.15.7 이 최신 버전이다. 같은 해 11월부터 공식 지원이 종료되어 더 이상 보안 업데이트나 기능 개선이 제공되지 않는다.

softwareupdate --fetch-full-installer --full-installer-version 10.15.7

다운로드가 완료되면 아래 명령으로 다운로드가 완료된 파일을 확인할 수 있다.

ls -l /Applications/Install\ macOS\ Catalina.app

또는

/Applications/Install\ macOS\ Catalina.app/Contents/Resources/startosinstall --usage

macOS Catalina 설치

기존 데이터를 모두 삭제하고 설치하도록 아래 명령을 입력한다.

sudo /Applications/Install\ macOS\ Catalina.app/Contents/Resources/startosinstall \

--eraseinstall \

--agreetolicense \

--nointeraction

설치가 진행되면 더이상 리모트로 접속이 허용되지 않고 직접 맥미니에 키보드와 마우스를 연결하여 진행을 해야한다.

사용기 - 맥에서 도커 기반 SonarQube 활용하기

2025-03-17T16:41:00.004+09:00

SonarQube는 코드에 대한 버그, 코드 스멜(Code Smell), 보안 취약점을 자동으로 찾아내고, 코드 품질을 향상시키는 데 도움을 주는 소스 코드 품질 및 보안 분석 도구이다.

버전에 따라 기능의 차이가 있는데 Community Edition (무료) 은 GitHub Private Repository 연동을 지원하지는 않지만 Git 에서 직접 코드를 가져와 분석할 수 있기 때문에 사용하는데 있어 큰 이슈는 없을 것 같다.

버전	특징	GitHub Private Repo 분석
Community Edition	무료, 기본적인 코드 분석 가능	✗ (직접 클론 후 분석)
Developer Edition	추가적인 언어 지원, 분기(branch) 분석	✓
Enterprise Edition	대규모 프로젝트 지원, 포트폴리오 관리	✓

◼︎ 환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.3.1 (24D70)
TOOLS : VS Code , Docker

1. Docker 설치

Docker 는 공식 웹사이트에서 Docker Desktop for Mac을 다운로드하여 설치한다.

https://www.docker.com/products/docker-desktop

설치파일을 다운로드 후 Docker.dmg 파일을 클릭하여 설치를 진행할 수 있다. 설치가 완료되면 터미널에서 docker --version 명력을 입력하여 설치 확인한다.

% docker --version
Docker version 27.5.1, build 9f9e405

2. SonarQube Community Edition 설치하기

SonarQube 는 간단하게 터미널에서 아래 명령으로 SonarSource에서 공식적으로 제공하는 이미지를 다운로드하여 설치하고 실행할 수 있다. SonarQube 는 디폴트로 사용하는 H2 데이터베이스 보다는 postgres 사용을 권장하고 있어 먼저 postgres 데이터베이스를 설치하고 같이 실행할 필요가 있다.

docker run -d --name sonarqube -p 9000:9000 sonarqube:lts-community

SonarQube는 여러 버전의 Docker 이미지를 제공하고 있다.

태그(Tag)	설명
sonarqube:latest	최신 안정 버전
sonarqube:lts	최신 LTS (Long-Term Support) 버전
sonarqube:lts-community	무료 Community Edition LTS 버전
sonarqube:developer	Developer Edition (유료)
sonarqube:enterprise	Enterprise Edition (유료)
sonarqube:datacenter	Data Center Edition (유료)

postgres는 터미널에 아래와 같이 한 줄 명령어로 postgres 를 설치&실행 할 수 있다.

docker run -d --name postgres \

-e POSTGRES_USER=sonar \

-e POSTGRES_PASSWORD=sonar \

-e POSTGRES_DB=sonarqube \

-p 5432:5432 \

postgres:16

참고로 PostgreSQL 공식 Docker 이미지는 다양한 버전이 있는데 여기에서는 16 을 사용했다.

태그 (Tag)	의미
postgres:latest	최신 안정 버전 (현재 기준 PostgreSQL 16)
postgres:16	PostgreSQL 16.x
postgres:15	PostgreSQL 15.x
postgres:14	PostgreSQL 14.x
postgres:13	PostgreSQL 13.x

이제 SonarQube 을 앞서 실행한 postres 와 함께 설치&실행 해보자.

docker run -d --name sonarqube \

-p 9000:9000 \

--link postgres \

-e SONAR_JDBC_URL=jdbc:postgresql://postgres:5432/sonarqube \

-e SONAR_JDBC_USERNAME=sonar \

-e SONAR_JDBC_PASSWORD=sonar \

sonarqube:lts-community

옵션	설명
docker run	새로운 컨테이너를 실행하는 명령
-d	컨테이너를 백그라운드(Detached Mode)에서 실행
--name sonarqube	컨테이너 이름을 sonarqube로 지정
-p 9000:9000	호스트의 9000번 포트를 컨테이너의 9000번 포트와 연결 (SonarQube 웹 UI)
--link postgre-container	SonarQube가 postgre-container 컨테이너와 통신할 수 있도록 설정 (Deprecated - 다른 방법 권장)
-e SONAR_JDBC_URL=jdbc:postgresql://postgres:5432/sonarqube	SonarQube가 PostgreSQL 데이터베이스 sonarqube에 연결하도록 설정
-e SONAR_JDBC_USERNAME=sonar	PostgreSQL 접속 시 사용할 DB 사용자명 설정
-e SONAR_JDBC_PASSWORD=sonar	PostgreSQL 접속 시 사용할 DB 비밀번호 설정
sonarqube:lts-community	실행할 Docker 이미지 (sonarqube의 LTS 버전, 무료 Community Edition)

참고로 여기에서는 postgres 와 sonarquber 가 서로 통신가능하게 --link 옵션을 사용했지만 안정성 이유로 --network 을 사용하는 것이 권장된다고 한다. 설치가 완료되면 브라우저에서 localhost:9000 포트로 접속한다. 디폴트 계정과 비밀번호는 admin 과 admin 이다.

Docker Desktop 도구를 사용하면 좀더 쉽게 도커 컨테이너 제어와 자원 사용량을 실시간으로 확인 할 수 있다.

Docker Desktop 화면

일단 위 과정을 한번하고나면 다음부터는 Docker Desktop 을 사용하여 쉽게 컨테이너를 조작할 수 있다.

2. SonarQube Community Edition 사용하기

한글이 익숙하다면 로그인 후 macketplace 메뉴에서 "Korean Pack Localization" 을 설치하면 간단하게 한글을 지원하게 된다.

코드 품질을 분석하는 기본적인 과정은 아래와 같다.

❶ 프로젝트를 생성

❷ SonarScanner 설치 및 실행

❸ 분석결과 확인

2.1 프로젝트를 생성

"프로젝트" 메뉴를 클릭하고 Community Edition 이 GitHub Private Repository 연동을 지원하지 않기 때문에 로컬에 프로젝트를 복제하여 분석 하기 위하여 "Manually" 을 선택한다.

존재하는 프로젝트가 없는 경우

프로젝트 이름을 입력하고 Setup 을 클릭하여 프로젝트를 생성한다.

2.2 토큰 생성

보안된 인증을 통해 자동화된 코드 분석을 실행할 수 있도록 토큰을 생성한다. Loaclly 을 클릭한다.

① 토큰 생성하기에서 생성하기를 클릭하여 토큰을 생성한다.

생성된 토큰을 별도로 저장하여 보관한다. Continue 클릭하면 다양한 환경에 바로 적용 가능한 스크립트를 보여준다.

기존 프로젝트가 maven 을 지원하고 있어 maven 스크립트를 복사했다.

2.3 SonarScanner 설치 및 실행

SonarQube 서버와 연결하여 코드 품질을 분석하고 결과를 업로드하는 SonarScanner 은 아래와 같이 터미널에 입력하여 간단하게 설치할 수 있다.

brew install sonar-scanner

SonarScanner가 분석하는 요소는 아래와 같다.

Bug (버그): 코드에서 오류가 발생할 가능성이 있는 부분
Code Smell (코드 냄새): 유지보수성이 낮거나 개선이 필요한 코드
Vulnerability (보안 취약점): SQL Injection, XSS 같은 보안 문제
Coverage (테스트 커버리지): 단위 테스트가 얼마나 잘 작성되었는지
Duplications (코드 중복): 중복된 코드 블록 확인

설치 결과는 아래 명령으로 확인 할 수 있다.

sonar-scanner --version

이제 Git 에서 가져온 Maven 프로젝트에서 앞서 복사한 스크립트를 사용하여 실행한다.

mvn clean verify sonar:sonar \
-Dsonar.projectKey=my_project \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.login=your_generated_token

옵션	설명
mvn	Maven을 실행하는 명령어
clean	기존 빌드 파일을 삭제하고 새롭게 빌드
verify	테스트를 실행하고 빌드를 검증
sonar:sonar	SonarQube 분석을 실행하는 Maven 플러그인 (sonar-maven-plugin)
-Dsonar.projectKey=my_project	SonarQube에서 프로젝트를 구별하는 고유한 키
-Dsonar.host.url=http://localhost:9000	SonarQube 서버의 주소
-Dsonar.login=your_generated_token	SonarQube 인증을 위한 API 토큰

실행이 완료되면 SonarQube 웹에서 분석 결과 확인할 수 있다.

결과 화면

SonarQube 분석 결과을 보면 이 프로젝트는 다음과 같은 조치가 필요한 것으로 나타난다.

Bugs, Vulnerabilities, Coverage, Duplications 항목에서 개선 필요
특히 Bugs (170개), Coverage (0%), 취약점 (13개)가 심각한 문제
보안 문제를 해결하고, 테스트 커버리지를 높이는 것이 가장 시급함

이제 SonarQube 에서 "Issues" 탭을 확인하고, 하나씩 문제를 해결해 나가면 된다.

이슈 목록 화면

각 이슈를 클릭하면 해당 건에 대한 상세 화면으로 이동하게 된다. 이슈 내용을 확인하고 코드를 수정한다. 이슈 상세 페이지를 보면 이슈 상태를 변경할 수 있는 기능이 있는데 코드 수정 후 다시 로컬에서 SonarScanner 을 실행하기 때문에 문자가 해결되면 자동으로 Resolved(Fixed) 로 상태가 변경 된다.

이슈 상세화면에서 "See all issues in this file" 클릭하여 해당 파일에 대한 목록만 보여지는데 이를 활용하면 파일 별로 작업을 진행 할 수도 있다.

이슈 상세 화면

파일 단위로 필터 된 이슈 목록

코드를 수정하고 SonarScanner 을 동일하게 실행하면 결과가 반영되어 다시 분석결과가 업데이트 된다.

3. 느낀점

자바 언어를 사용하는 프로젝트에 1주 정도 적용을 해보았는데 아래와 같은 점에서 아주 만족스러웠다.

좋은 코딩 습관을 위한 아주 좋은 도구이다. 코드에 대한 결함을 해결하면서 좋은 코드를 작성하는 방법을 자연스럽게 학습할 수 있었다.

Bug (버그): 코드에서 오류가 발생할 가능성이 있는 부분
Code Smell (코드 냄새): 유지보수성이 낮거나 개선이 필요한 코드
Vulnerability (보안 취약점): SQL Injection, XSS 같은 보안 문제
Coverage (테스트 커버리지): 단위 테스트가 얼마나 잘 작성되었는지
Duplications (코드 중복): 중복된 코드 블록 확인

자바 언어의 버전에 따른 좋은 코드를 지적해주기 때문에 코딩 스킬 향상에 도움이 되었다.

사용기 - VSCode 에서 Gemini Code Assist

2025-03-01T21:49:00.001+09:00

Gemini Code Assist 설치하기

Gemini Code Assist 사이트를 방문하여 Use in Visual Studio Code 버튼을 클릭한댜.

https://codeassist.google/#available-in-your-favorite-ides-and-platforms

Use in Visual Studio Code 버튼을 클릭하면 마이크로소프트 Visual Studio Maketplace 의 Gemini Code Assist 설치 사이트로 이동하게 된다.

직접 Visual Studio Code 마켓플레이스 확장을 통하여 설치할 수도 있는데 gemini 로 검색하여 설치하면 된다.

설치가 완료되면 먼저 가지고 있는 구글 계정으로 로그인을 하고 챗봇 형태로 사용할 수 있다.

코드 파일에서 Gemini Code Assist 프롬프트

Control+I(Windows 및 Linux) 또는 Command+I(macOS)를 눌러 Gemini Code Assist 를 실행할 수 있다.

채팅을 사용하여 선택한 코드로 Gemini Code Assist에 프롬프트 입력

코드 블록을 선택하고 Gemini Code Assist 창에서 코드에 대한 프롬프트를 입력한다.

참고

Gemini Code Assist를 사용한 코드

코딩 - ChatGPT 을 이용한 맥 프로그램 만들기(네임나이저)

2024-12-19T20:14:00.002+09:00

ChatGPT 의 코딩 실력을 확인하는 목적과 Shift 코딩 연습을 목적으로 맥용 프로그램을 만들어 보았다.

◼︎ 개발 환경

HW : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.0.1 (24A348)
TOOLS : XCode 16.1
Programming Language : Shift

◼︎ 프로그램 요구사항
맥은 UTF-8 NFD (Normalization Form Decomposed)로 저장하는 반면, 윈도우는 UTF-8 NFC (Normalization Form Composed)를 사용 하는 차이로 인하여 맥에서 생성된 파일이 윈도우로 이동하면 자모가 분리되어 보여지는 현상이다. 이를 해결하기 위하여 아래와 같은 목표를 정의했다.

Drag&Drop 기능을 활용
자소가 분리된(NFD) 유니코드 파일명을 자소가 조합된(NFC) 파일명으로 변환

참고로 ChatGPT 는 유료버전의 4o을 사용했고 개발 과정에서 모양과 기능은 Contact 과 반디네이머를 참고했다.

어떻게 프로그램을 만들 것인가

🆀 맥에서 생성하거나 수정한 파일의 이름이 윈도우에서 깨지는 이슈가 있는데 자동으로 변환을 해주는 맥용 앱을 만들고 싶어.

🅰

전체적으로 어떻게 만들 것인가를 자세하게 설명해주고 있다. 추가로 좀더 구체적인 질문을 하며 상세하게 원하는 것을 설명해준다.

🆀 앱을 실행하면 파일 탐색기 처럼 좌측에는 폴더 우측에서 세부 파일 구조와 NFC, NFD 을 보여주고 선택된 파일 또는 폴더에 대하여 일괄적으로 NFD 형식의 유니코드 파일명을 NFC 변경하거나 반대로 변경하는 기능으로 구현하면

🅰

프로젝트 생성

제시된 코드를 기반으로 "Namenizer" 라는 이름으로 XCode 프로젝트를 생성하였다.

다음으로는 컴파일을 통하여 코드를 실행하면서 지속적으로 코드 수정을 요청하고 이를 반복하였다.

"Namenizer" 프로그램 코딩

코딩 과정의 최초의 문제는 모든 파일들을 보여주지 못한다는 점이었다. download 등 주요한 폴더들은 표시되지 않았다.

🆀 downloads 와 같은 폴더는 접근할 수 없는데

🅰

해결방법은 크게 ❶ Sandbox 설정을 통하여 보안을 무력화 하거나 ❷ NSOpenPanel을 사용하여 사용자에게 권한 요청하는 방식을 알려주었는데 두번쨰 방법을 사용하는 것을 선택하고 제시되는 코드를 사용하여 코드를 수정했다.

두번째 문제는 반디네이머와 같이 NFD 유니코드로 인하여 윈도우에서 한글 자모가 분리되는 것을 미리 보여주는 기능을 구현하는 것이었다.

🆀 NFD 여부를 알려면

🅰

제안된 방법으로 코딩을 해보았지만 자모가 분리되어 보이지 않았다. 지루한 주고받는 방식의 질의를 통하여 알게된 유니코드 디버딩 과정에서 보여지는 텍스트와 유니코드 값의 차이를 확하게 되었다. (동일하게 보이는 텍스트가 유니코드 값이 다르게 보여짐. 보통 NFD 의 경우 유니코드 값이 더 많았다.) "그럼 유니코드 값의 동일 유무를 검사하면 되겠네" 가정을 수립하고 확인을 위한 질문을 계속한다.

🆀 항상 NFC 로만 보여지는 이유는

🅰

NFC 여부를 판단하는 방법으로 제시된 다음 코드를 기반으로 추가 질의를 하여 이 문제를 좀더 깊이 확인 해보았다.

func isNFC(_ string: String) -> Bool {

return string == string.precomposedStringWithCanonicalMapping

}

🆀 func isNFC(_ string: String) -> Bool { return string == string.precomposedStringWithCanonicalMapping } 코드가 항상 true 을 리턴하는 것 은

🅰

이러한 내용을 바탕으로 유니코드 값을 활용하여 NFD 정규화 상태인지 확인하는 함수는 앞서 제시된 유니코드 디버깅을 활용하여 직접 문제를 아래와 같이 해결했다.

/// 문자열이 NFD로 정규화된 상태인지 확인하는 함수

public static func isNFDUsingUnicodeScalars(_ string: String) -> Bool {

// NFD로 변환된 문자열

let nfdString = string.decomposedStringWithCanonicalMapping

// 원본 문자열과 NFD로 변환된 문자열의 유니코드 스칼라를 비교

return string.unicodeScalars.elementsEqual(nfdString.unicodeScalars)

}

이 과정에서 알게된 건 "macOS 파일 시스템에서 파일 이름을 읽어올 때는 NFD로 변환된 상태로 제공할 수 있다"라는 가능성이 있다는 것이었다.

🆀 자모가 분리되는 것을 보여주는 것은 다음 질문에 대한 답으로 해결할 수 있었다.

originalString.decomposedStringWithCanonicalMapping 해도 자모가 분리되어 보이지 않는다면

🅰

마지막 가장 큰 문제는 NFC 로 파일 이름을 변경하는 것이었다. 제시된 코드는 정상동작 하지 않아 관련하여 질문을 해보았다.

🆀 NFC 유니코드를 출력하면 다른 값으로 보이는데 파일이름을 NFC 로 저장하고 다시 읽으면 변경되어 있지 않는데

🅰

결론은 macOS 파일 시스템(APFS, HFS+)은 파일 이름을 항상 NFD로 저장하기 때문에 정상적인 방법으로는 불가하다고 판단하였다.

🆀 커멘드를 실행하여 처리하면

🆀 별도의 설치없이 사용하는 커멘드는 없는가

🆀 Swift 코드에서 커멘드를 실행하도록 만들면

Perl 명령을 사용한 파일 이름 변경은 실패하였다. 아래는 GPT 가 제시한 방법이다.

func convertFileNameToNFCUsingPerl(_ url: URL) {

let originalPath = url.path

let directory = url.deletingLastPathComponent().path

let fileName = url.lastPathComponent

let perlCommand = """

/usr/bin/perl -CIO -MUnicode::Normalize -e 'rename shift, shift' "\(originalPath)" "\(directory)/$(/usr/bin/perl -CIO -MUnicode::Normalize -e 'print NFC(shift)' "\(fileName)")"

"""

let process = Process()

process.executableURL = URL(fileURLWithPath: "/bin/zsh") // 또는 "/bin/bash"

process.arguments = ["-c", perlCommand]

let pipe = Pipe()

process.standardOutput = pipe

process.standardError = pipe

do {

try process.run()

process.waitUntilExit()

let data = pipe.fileHandleForReading.readDataToEndOfFile()

if let output = String(data: data, encoding: .utf8) {

print(output)

}

if process.terminationStatus == 0 {

print("파일 이름이 NFC로 변환되었습니다.")

} else {

print("perl 명령어 실행 실패")

}

} catch {

print("파일 이름 변환 실패: \(error.localizedDescription)")

}

결국 Contact 코드를 분석하여 문제를 해결해보기로 했다.

🆀 https://github.com/namhokim/cocoa_app 에서는 위 문제를 어떻게 해결하고 있지

🆀 https://github.com/namhokim/cocoa_app 를 참고하여 convertFileNameToNFC 함수를 만들면

문제 해결이 되지 않았고 Contact 프로젝트 소스를 확인해보니 perl 정규식이 아닌 단순 mv 명령으로 이름을 변경하는 것으로 확인하여 다시 질문을 했다.

🆀 https://github.com/namhokim/cocoa_app 는 mv 을 사용하여 처리하지 않았나

🅰

Perl 을 정규식을 사용하는 점을 제외하면 동일한 방식으로 코드를 제안했지만 문제가 해결되지 않았다. 결국 Contact 의 변환소스에 해당하는 소스를 분석하게 하고 동일하게 코드를 만들라고 하여 문제를 해결 할수 있었다.

🅰

mv 스크립트를 생성하여 실행하는 방식은 정상 동작하고 perl 스크립트 방식에서는 잘못된 문자들로 저장되는 원인을 물어보았으나 이부분에 대한 명확한 답변을 듣지 못했다. 다만 아래와 같은 mv 가 좀더 신뢰성 있게 동작한다는 답변을 얻었다.

아래는 마직막으로 작성된 코드를 실행하는 화면이다.

전체 소스 : https://github.com/andang72/andang72.namenizer

코딩 - ChatGPT 을 이용한 맥 프로그램 만들기(오늘의 명언)

2024-11-08T16:13:00.004+09:00

ChatGPT 의 코딩 실력을 확인하는 목적으로 간단한 맥용 프로그램을 만들어 보았다. 참고로 맥 프로그래밍은 과거에 관련 서적을 보고 Object C 기반의 웹뷰 예제를 만들어 본것이 전부이다.

◼︎ 개발 환경

HW : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.0.1 (24A348)
TOOLS : XCode 16.1
Programming Language : Shift

◼︎ 프로그램 요구사항

배경 이미지와 명언이 프로그램을 클릭하면 변경되는 간단한 오늘의 명언 프로그램.
간단한 날씨정보도 같이 보여줌.

참고로 ChatGPT 는 유료버전의 4o을 사용했다.

어떻게 프로그램을 만들 것인가 알아보기

🆀 맥에서 동작하는 Unsplash 에서 랜덤 이미지를 배경으로 명언 보여주는 프로그램을 스위프트를 사용하여 만들고 싶다. 화면을 클릭하면 매번 배경이미지와 명언을 새로 보여주고 싶다.

🅰 이 프로그램은 Xcode에서 Swift와 Cocoa 프레임워크를 사용해 개발할 수 있으며, 네트워크 요청을 통해 Unsplash API에서 이미지를 가져오고 화면에 표시하는 방식입니다.

요약 후 아래와 같은 절차를 가이드 한다.

Unsplash API 키 준비
XCode 을 설치
새로운 App 프로젝트를 생성
예제 코드

명언 역시 외부에서 가져오고 싶어 아래와 같은 질문을 했다.

🆀 명언도 API 을 사용하여 랜덤하게 가져오려면

🅰 명언을 API에서 랜덤하게 가져오려면 다양한 명언 API를 사용할 수 있습니다. 예를 들어, Quotes REST API나 ZenQuotes API를 사용하면 간편하게 랜덤 명언을 가져올 수 있습니다. 여기서는 ZenQuotes API를 사용하여 Swift 코드에 적용하는 방법을 설명드리겠습니다.

요약 후 앞의 코드에 명언을 ZenQuotes API 사용하여 가져오는 수정된 코드를 제시한다. (참고로 ZenQuotes API 는 API Key 없이 사용할 수 있다.)

프로젝트 생성

ChatGPT 가이드에 따라 XCode 을 사용하여 새로운 "오늘의 명언" 프로젝트를 아래 절차로 생성하였다.

그림1. 새로운 프로젝트 생성

그림2. 템플릿 목록에서 App 선택

그림3. 프로젝트 정보 입력 및 생성

(생성시 Testing System 을 None 로 변경하여 테스트를 위한 프로그램들이 생성되지 않도록 했다.)

XCode 에 의하여 생성된 프로젝트는 아래과 같은 파일로 구성된다. (프로젝트 이름을 Quotes 로 한 경우)

그림4. 생성된 프로젝트 파일 구조

Unsplash API 사용을 위해서는 API Key 가 필요하다. API Key 는 Unsplash 홈페이지 에서 회원 가입 후 Unsplash Developer 페이지로 이동해서 Your Apps 섹션에서 New Application 버튼을 클릭하여 새로운 앱을 만드는 것으로 키를 생성할 수 있다.

"오늘의 명언" 프로그램 코딩

ContentView 소스는 ChatGPT 가 제시한 코드를 적용하였다.
빌드하고 실행하면 통신 오류 처럼 보여지는 에러를 확인 할 수 있는데 이 부분을 해결하는 것에 큰 어려움이 있었다.

Error fetching quote: Error Domain=NSURLErrorDomain Code=-1003 "A server with the specified hostname could not be found."

ChatGPT 는 위 오류에 대하여 (앱과 서버 간의 통신을 HTTPS를 통한 암호화된 연결로 제한하는) ⑴ATS 설정을 추가하거나 ⑵서버 API 상태, ⑶방화벽 점검을 해결방법을 제안하였다. 외부 서비스가 https 을 사용하는 이유로 ATS 문제는 아니고 방화벽 과 같은 네트워크 문제도 아닌것으로 확신하여 프로젝트 설정에 보안 관련 사항이 있는 것은 아닌가를 의심하고 아래와 같은 추가 질문을 했다.

❉ ATS(App Transport Security) 는 Apple이 iOS 9 및 macOS 10.11(El Capitan)부터 앱의 네트워크 보안을 강화하기 위해 도입한 기술이다. ATS는 앱이 네트워크를 통해 데이터를 전송할 때 보안이 강화된 HTTPS 연결을 사용하도록 요구하며 이를 통해 중간자 공격, 데이터 탈취 등의 위험을 줄이고 네트워크 보안 표준을 준수하도록 한다.

🆀 맥용 앱 프로젝트는 보안 관련 고려하여야 할 제약이 있는가

답변 내용중에서 App Sandbox 관련 이슈라는 확신을 갖고 아래와 같은 질문을 했다.

🆀 App Sandbox 에서 Connections 등의 세부 권한을 추가 하려면

답변에 따라 프로젝트의 Xcode에서 프로젝트 파일을 클릭하고, Targets에서 앱의 타겟을 선택한 후 Signing & Capabilities 탭으로 이동 Outgoing Connections 항목을 체크 하여 문제를 해결하였다.

이제 프로그램을 실행하면 아래와 같다.

❉ App Sandbox 는 Apple은 보안을 강화하고 앱이 사용자 데이터를 오용하거나 시스템 자원에 무단으로 접근하는 것을 방지하기 위해 macOS Lion (10.7) 버전부터 App Sandbox를 도입했다. 특히, Mac App Store를 통해 배포되는 앱은 사용자 신뢰와 보안을 보장해야 했기 때문에 강제화되었다. 주요한 특징으로 격리실행(앱은 자신의 데이터와 권한 내에서만 작동하며, 다른 앱이나 시스템에 접근할 수 없음), 권한 기반 접근(파일, 네트워크, 하드웨어 리소스 등 필요한 권한만 명시적으로 요청), 보안강화(악성 코드 실행 및 데이터 탈취 방지) 을 가지고 있다.

"오늘의 명언" 프로그램 개선하기

프로그램을 개선을 위하여 아래의 기능들을 추가로 정의하였다.

무료 버전의 Unsplash API 호출은 시간당 50개의 요청과 하루에 5,000개의 요청으로 제약이 있다. 이런 이유에서 이미지를 가져오지 못하는 경우 미리 가지고 있는 이미지를 랜덤으로 보여주는 기능이 구현.
다음으로 단순하게 텍스트를 보여주는 것이 아니라 타이핑과 같은 효과 구현
외부에서 이미지를 가져오는 Unsplash API 을 호출하려면 키가 필요한데 소스에 코딩하여 사용하던 것을 입력할 수 있도록 프로그램 환경설정에 메뉴를 추가
우측 상단에 위치정보를 기반으로 테스트로 위치와 날씨 노출 구현
Unsplash 의 경우 좌측 하단에 인스타그램과 같이 제작자 정보 노출 구현

기능 구현을 위하여 아래와 같은 질문들을 했다.

🆀 Unsplash API 을 통하여 이미지를 가져오지 못할 때는 디폴트 이미지들을 랜덤으로 보여주게 하려면

🅰 Unsplash API를 통해 이미지를 가져오지 못할 때, 로컬에 저장된 기본 이미지를 랜덤으로 표시하는 기능을 추가할 수 있습니다. 이 기능을 구현하려면 이미지 로드 실패 시 로컬 이미지 배열에서 무작위로 선택하여 표시하는 로직을 작성하면 됩니다.

private func fetchRandomLocalImage() {

let imageNames = (1...8).map { "\($0)" }

guard let randomImageName = imageNames.randomElement(), let nsImage = NSImage(named: randomImageName) else {

print("Error: Could not load local image.")

self.image = nil

return

}

self.isUnsplashImage = false // Unsplash 이미지가 아님을 설정

self.image = nsImage

self.fetchRandomQuote()

}

제공되는 예제를 적용하여 Unsplash 에서 이미지를 가져오는 과정에서 오류가 발생하면 가지고 있는 이미지들 중에서 랜덤하게 하나의 이미지를 가져와 배경으로 보여주도록 기능을 추가하였다. 이미지는 AI 이미지 관련 웹 사이트에서 몇개를 다운로드하여 사용하였다. 로컬 이미지 추가는 Assets 에 새로운 폴더 "Images" 를 생성하고 이미지를 Drag&Drop 하여 이미지를 추가 하고 코딩시 이미지 목록을 자동화 하여 가져올 수 있도록 이름을 1, 2, 3, 4 형태로 변경하여 사용하였다.

🆀 명언 텍스트를 보여줄때 타이핑 효과를 주려면

🅰 SwiftUI에서 텍스트에 타이핑 효과를 주려면 애니메이션과 타이머를 조합하여 텍스트가 한 글자씩 나타나도록 구현할 수 있습니다. DispatchQueue와 타이머를 사용해 문자열의 각 문자를 일정 간격으로 추가하여 타이핑 애니메이션을 만들 수 있습니다.

제공되는 예제를 적용하여 문자를 티이핑하는 효과를 구현하는 기능의 TypewriterText 구조체를 추가하였다.

struct TypewriterText: View {

var text: String

var onComplete: (() -> Void)? = nil // 타입 효과 완료 시 호출되는 클로저

@State private var displayedText: String = ""

@State private var currentIndex: Int = 0

@State private var typingTimer: Timer? = nil

private let typingSpeed = 0.07

var body: some View {

Text(displayedText)

.onAppear {

startTyping()

}

.onChange(of: text) {

resetTyping()

startTyping()

}

private func startTyping() {

typingTimer?.invalidate()

typingTimer = nil

displayedText = ""

currentIndex = 0

typingTimer = Timer.scheduledTimer(withTimeInterval: typingSpeed, repeats: true) { timer in

if currentIndex < text.count {

let index = text.index(text.startIndex, offsetBy: currentIndex)

displayedText.append(text[index])

currentIndex += 1

} else {

timer.invalidate()

typingTimer = nil

onComplete?() // 타이핑이 완료되면 onComplete 클로저 호출

}

private func resetTyping() {

typingTimer?.invalidate()

typingTimer = nil

displayedText = ""

currentIndex = 0

}

🆀 프로그램 환경설정에 Unsplash API 키를 설정할 수 있게 하려면

🅰 프로그램의 환경설정 창에서 API 키를 설정할 수 있도록 하려면 SwiftUI 앱에서는 Settings를 사용하여 시스템 메뉴의 기본 설정 창에 해당 UI를 추가할 수 있습니다. 이를 통해 Unsplash API Key를 설정할 수 있도록 합니다.

제공되는 예제를 적용하여 키를 설정하는 기능의 SettingsView 구조체를 추가하였다.

import SwiftUI

struct SettingsView: View {

@AppStorage("UnsplashAPIKey") private var unsplashApiKey: String = ""

@AppStorage("OpenWeatherMapAPIKey") private var weatherApiKey: String = ""

@AppStorage("OpenAIAPIKey") private var openAIAPIKey: String = ""

@State private var showSaveConfirmation = false

var body: some View {

VStack(spacing: 20) {

// API Key Table

VStack(alignment: .leading, spacing: 15) {

HStack {

Text("Unsplash API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter Unsplash API Key", text: $unsplashApiKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

HStack {

Text("OpenWeatherMap API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter OpenWeatherMap API Key", text: $weatherApiKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

HStack {

Text("OpenAI API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter OpenAI API Key", text: $openAIAPIKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

.padding(.horizontal, 20)

.padding(.top, 40)

Spacer()

// Save Button with Clear Background

Button(action: {

showSaveConfirmation = true

}) {

Text("Save Changes")

.font(.headline)

.foregroundColor(.blue) // Text color only, no background color

.padding()

.frame(maxWidth: .infinity)

.overlay(

RoundedRectangle(cornerRadius: 8)

.stroke(Color.blue, lineWidth: 2)

)

}

.buttonStyle(PlainButtonStyle()) // Ensures the button has no additional background styling

.padding([.leading, .trailing, .bottom], 20)

.alert(isPresented: $showSaveConfirmation) {

Alert(title: Text("Settings Saved"), message: Text("Your API keys have been saved."), dismissButton: .default(Text("OK")))

}

.frame(width: 500, height: 250)

}

🆀 사용자 위치정보를 기반으로 오늘의 날씨 정보와 위치 정보를 우측 상단 고정된 영역에 보려주려면

🅰 사용자의 위치 정보를 기반으로 날씨와 위치를 우측 상단에 고정하여 보여주는 방법을 구현할 수 있습니다. 아래 예제에서는 LocationManager를 통해 사용자의 위치를 가져오고, OpenWeatherMap API를 사용하여 날씨 정보를 표시합니다.

제공되는 예제를 적용하여 WeatherView 구조체를 추가하였다.

struct WeatherView: View {

@Binding var locationString: String?

let weatherInfo: String

var body: some View {

VStack(alignment: .trailing) {

Text(weatherInfo)

.font(.subheadline)

.foregroundColor(.white)

.padding()

.background(Color.black.opacity(0.4))

.cornerRadius(8)

.padding(.trailing, 20)

}

.padding(.top, 40)

}

class LocationManager: NSObject, ObservableObject, CLLocationManagerDelegate {

private let manager = CLLocationManager()

@Published var userLocation: CLLocationCoordinate2D?

@Published var locationString: String?

override init() {

super.init()

manager.delegate = self

manager.desiredAccuracy = kCLLocationAccuracyBest

}

func requestLocation() {

manager.requestWhenInUseAuthorization()

manager.requestLocation()

}

func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) {

if let location = locations.first {

userLocation = location.coordinate

locationString = "Lat: \(location.coordinate.latitude), Lon: \(location.coordinate.longitude)"

}

func locationManager(_ manager: CLLocationManager, didFailWithError error: Error) {

print("Location error: \(error.localizedDescription)")

}

🆀 Unsplash API 에서 가져온 이미지를 보여줄 때는 인스타그램과 같이 이미지 이름과 작성자 그리고 프로필 이미지를 하단 좌측에 노출하게 하면

🅰 Unsplash API에서 이미지를 가져올 때, 이미지 정보와 작성자 이름, 작성자 프로필 사진 URL 등을 함께 받아와 화면에 표시할 수 있도록 코드를 수정할 수 있습니다. 아래는 해당 기능을 구현한 코드입니다. 이 코드는 이미지 하단 좌측에 Unsplash에서 가져온 이미지 이름과 작성자 정보를 표시합니다.

제공되는 예제를 적용하여 코드를 수정하였다.

private func fetchImageFromUnsplash() {

guard !unsplashApiKey.isEmpty, let url = URL(string: "https://api.unsplash.com/photos/random?client_id=\(unsplashApiKey)") else {

print("Error: Unsplash API Key is missing or invalid URL.")

fetchRandomLocalImage()

return

}

URLSession.shared.dataTask(with: url) { data, response, error in

defer { isLoading = false }

if let error = error {

print("Error fetching image: \(error.localizedDescription)")

DispatchQueue.main.async {

self.fetchRandomLocalImage()

}

return

}

guard let data = data else {

print("Error: No data received.")

DispatchQueue.main.async {

self.fetchRandomLocalImage()

}

return

}

do {

if let json = try JSONSerialization.jsonObject(with: data) as? [String: Any],

let urls = json["urls"] as? [String: String],

let imageUrlString = urls["regular"],

let imageUrl = URL(string: imageUrlString),

let user = json["user"] as? [String: Any],

let authorName = user["name"] as? String,

let profileImageUrls = user["profile_image"] as? [String: String],

let profileImageUrlString = profileImageUrls["small"],

let profileImageUrl = URL(string: profileImageUrlString),

let description = json["description"] as? String {

self.imageTitle = description

self.authorName = authorName

self.isUnsplashImage = true // Unsplash 이미지임을 설정

DispatchQueue.main.async {

self.downloadImage(from: imageUrl)

self.downloadAuthorProfileImage(from: profileImageUrl)

}

} else {

print("Error: Could not parse JSON.")

DispatchQueue.main.async {

self.fetchRandomLocalImage()

}

} catch {

print("Error parsing JSON: \(error.localizedDescription)")

DispatchQueue.main.async {

self.fetchRandomLocalImage()

}

}.resume()

}

private func downloadImage(from url: URL) {

URLSession.shared.dataTask(with: url) { data, response, error in

guard let data = data, let nsImage = NSImage(data: data) else {

if let error = error {

print("Error downloading image: \(error.localizedDescription)")

} else {

print("Error: Unable to create image from data.")

}

DispatchQueue.main.async {

self.fetchRandomLocalImage()

}

return

}

DispatchQueue.main.async {

self.image = nsImage

self.fetchRandomQuote() // 이미지가 로드된 후에 명언을 가져옴

}

}.resume()

}

private func downloadAuthorProfileImage(from url: URL) {

URLSession.shared.dataTask(with: url) { data, response, error in

guard let data = data, let nsImage = NSImage(data: data) else {

print("Error downloading author profile image: \(error?.localizedDescription ?? "Unknown error")")

return

}

DispatchQueue.main.async {

self.authorProfileImage = nsImage

}

}.resume()

}

🆀 로컬 이미지의 경우에는 작성자 정보를 보이지 않고 싶은데

🅰 로컬 이미지를 사용할 때는 작성자 정보가 표시되지 않도록 설정할 수 있습니다. 이를 위해, Unsplash에서 이미지를 가져온 경우에만 작성자 정보가 표시되도록 조건을 추가하면 됩니다. ContentView에서 Unsplash 이미지를 사용할 때만 작성자 정보를 보여주는 플래그를 추가하겠습니다.

제공되는 예제를 적용하여 코드를 수정하였다.

🆀 명언이 영어로 제공되는데 chatgpt API 을 사용하여 한국어로 같이 표시하려면

🅰 ChatGPT API를 사용하여 영어로 제공된 명언을 한국어로 번역하는 방법을 구현할 수 있습니다. 아래는 OpenAI의 ChatGPT API를 통해 영어 명언을 번역하여 한국어와 영어로 함께 표시하는 예제 코드입니다. 이 코드는 Swift에서 URLSession을 사용하여 ChatGPT API를 호출하고 번역 결과를 받아와 표시합니다.

제공되는 예제를 적용하여 코드를 수정하였다.

func translateQuoteToKorean(_ quote: String) {

guard let url = URL(string: "https://api.openai.com/v1/chat/completions") else {

print("Error: Invalid URL for OpenAI API")

return

}

var request = URLRequest(url: url)

request.httpMethod = "POST"

request.addValue("Bearer \(openAIAPIKey)", forHTTPHeaderField: "Authorization")

request.addValue("application/json", forHTTPHeaderField: "Content-Type")

let prompt = "Translate this quote to Korean: \(quote)"

let parameters: [String: Any] = [

"model": "gpt-4o-mini",

"messages": [

["role": "user", "content": prompt ]

"max_tokens": 60

]

do {

request.httpBody = try JSONSerialization.data(withJSONObject: parameters)

} catch {

print("Error: Failed to serialize JSON for request body - \(error)")

return

}

print("Sending request to ChatGPT API with prompt: \(prompt)")

URLSession.shared.dataTask(with: request) { data, response, error in

if let error = error {

print("Error: Network request failed - \(error.localizedDescription)")

return

}

if let httpResponse = response as? HTTPURLResponse {

print("Received HTTP response: \(httpResponse.statusCode)")

}

if let httpResponse = response as? HTTPURLResponse, httpResponse.statusCode == 429 {

print("Quota exceeded. Please check your API plan and usage.")

// 사용자에게 할당량 초과 메시지를 표시하는 로직 추가

//return

}

guard let data = data else {

print("Error: No data received from ChatGPT API")

return

}

do {

if let json = try JSONSerialization.jsonObject(with: data) as? [String: Any] {

print("Received JSON response: \(json)")

if let choices = json["choices"] as? [[String: Any]],

let message = choices.first?["message"] as? [String: Any],

let translatedText = message["content"] as? String {

DispatchQueue.main.async {

self.translatedQuote = translatedText.trimmingCharacters(in: .whitespacesAndNewlines)

}

} else {

print("Error: Unexpected JSON structure or missing 'choices' key")

}

} catch {

print("Error: Failed to parse JSON response - \(error)")

}

}.resume()

}

추가로 앞선 SettingsView 구조체에 ChatGPT API 키 설정 코드를 추가하고 이 키값을 사용하도록 ContentView 를 수정하였다.

import SwiftUI

struct SettingsView: View {

@AppStorage("UnsplashAPIKey") private var unsplashApiKey: String = ""

@AppStorage("OpenWeatherMapAPIKey") private var weatherApiKey: String = ""

@AppStorage("OpenAIAPIKey") private var openAIAPIKey: String = ""

@State private var showSaveConfirmation = false

var body: some View {

VStack(spacing: 20) {

// API Key Table

VStack(alignment: .leading, spacing: 15) {

HStack {

Text("Unsplash API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter Unsplash API Key", text: $unsplashApiKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

HStack {

Text("OpenWeatherMap API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter OpenWeatherMap API Key", text: $weatherApiKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

HStack {

Text("OpenAI API Key")

.frame(width: 150, alignment: .leading)

TextField("Enter OpenAI API Key", text: $openAIAPIKey)

.textFieldStyle(RoundedBorderTextFieldStyle())

.frame(width: 300)

}

.padding(.horizontal, 20)

.padding(.top, 40)

Spacer()

// Save Button with Clear Background

Button(action: {

showSaveConfirmation = true

}) {

Text("Save Changes")

.font(.headline)

.foregroundColor(.blue) // Text color only, no background color

.padding()

.frame(maxWidth: .infinity)

.overlay(

RoundedRectangle(cornerRadius: 8)

.stroke(Color.blue, lineWidth: 2)

)

}

.buttonStyle(PlainButtonStyle()) // Ensures the button has no additional background styling

.padding([.leading, .trailing, .bottom], 20)

.alert(isPresented: $showSaveConfirmation) {

Alert(title: Text("Settings Saved"), message: Text("Your API keys have been saved."), dismissButton: .default(Text("OK")))

}

.frame(width: 500, height: 250)

}

ChatGPT API 사용을 위해서는 Access Key 가 필요하다. Access Key 는 OpenAI 홈페이지에서 계정을 생성하거나 기존 계정으로 로그인 후 API 키 생성 페이지 로 이동 "Create new secret key" 버튼을 클릭하여 키를 생성할 수 있다.

전체 소스 : https://github.com/andang72/andang72.unsplash

총평

기대 이상의 정확한 설명과 예제 코드는 인상적이다. 중간 중간 오류가 발생하기도 했지만 관련하여 문의하면 또 적절한 답변을 해주었다.

ChatGPT 와 대화 가운데 잘모르는 것은 바로 질문하여 확인할 수 있기 때문에 자연스럽게 학습이 되었다.

충분한 맥 코딩 경험과 언어를 잘알고 있다면 전문가수준의 코드 작성도 충분하게 가능할것 같다는 느낌이다.

코딩 - Vue3 : AG-Grid 커뮤니티 버전 기반의 페이징 그리드 컴포넌트 만들기

2024-10-29T17:47:00.006+09:00

AG Grid Community 버전은 매우 인기 있는 오픈소스 그리드 컴포넌트로, 다양한 기능을 제공하지만 상업적인 용도로 사용할 때는 프로 버전으로의 업그레이드가 필요할 수도 있다. 커뮤니티 버전의 이점과 한계를 살펴보면 다음과 같다.

AG Grid Community 버전의 이점

무료 사용: 커뮤니티 버전은 오픈소스로 제공되므로 무료로 사용할 수 있다. 중소규모의 프로젝트나 상업적 용도가 아닌 경우에 적합.
강력한 성능: AG Grid 는 많은 양의 데이터를 효율적으로 처리할 수 있는 그리드 컴포넌트로 기본적인 CRUD 작업을 포함하여 빠른 렌더링 성능을 지원.
광범위한 기능:
- 기본적인 정렬, 필터링, 페이징, 그룹핑, 편집 등 그리드에서 필요한 대부분의 기능을 포함
- 다양한 컬럼 레이아웃과 사용자 정의 셀 렌더러 등 유연한 데이터 표현이 지원
활발한 커뮤니티: AG Grid는 대규모 사용자 커뮤니티를 보유하고 있어 문제 발생 시 도움을 얻기 용의.
다양한 프레임워크 지원: React, Angular, Vue, 순수 자바스크립트 등 여러 프레임워크에서 사용할 수 있는 유연함

AG Grid Community 버전의 한계

고급 기능 제한: 커뮤니티 버전에는 고급 기능이 포함되어 있지 않음. 특히 아래 기능들이 프로 버전에만 포함.
- 서버 사이드 모델(Server-Side Model): 대규모 데이터 집합에서 서버와 연동하여 그리드 데이터를 관리하는 기능.
- 익스포트 기능: CSV, Excel 등의 형식으로 데이터를 내보내는 기능이 제한.
- Tree Data 구조: 트리 구조의 데이터를 처리할 수 있는 고급 데이터 표현 방식 미지원.
- 엔터프라이즈 레벨 필터링: 고급 필터링 기능은 프로 버전에만 포함.
기술 지원 부족: 커뮤니티 버전에서는 공식적인 기술 지원을 받을 수 없음. 문제 해결 시 커뮤니티에 의존해야 함.
사용 제한: 상업적 프로젝트에서 고급 기능이 필요하거나 성능 최적화 및 유지보수가 중요한 경우, 커뮤니티 버전만으로는 한계가 있을 수 있음.

AG Grid Community 버전은 무료로 사용할 수 있고, 기본적인 그리드 기능을 모두 제공하기 때문에 많은 프로젝트에서 유용하다. 그러나 고급 기능이나 대규모 데이터 처리가 필요한 경우 프로 버전으로 업그레이드하는 것이 필요하다.

유료 버전에서는 rowModelType을 "serverSide" 로 설정하고 그리드가 준비되면 getRows 함수 내에서 서버 요청을 수행하고 결과를 그리드에 전달하는 데이터소스를 api.setServerSideDatasource() 함수를 사용하여 설정하는 방식으로 쉽게 구현할 수 있다.

AG Grid 커뮤니티 버전에서 서버 페이징은 (무한 스크롤을 구현하는 방법) rowModelType 값으로 "infinite" 을 사용하여 비슷한 방법으로 구현할 수 있다.

rowModelType을 "infinite"로 설정하여 그리드가 데이터를 한 번에 모두 로드하지 않고, 필요한 만큼 서버에서 요청하도록 한다.
getRows 함수는 그리드가 추가 데이터를 요청할 때마다 서버에 데이터를 가져오는 역할을 한다.
dataSource는그리드가 준비될 때 설정하고, 그리드가 데이터를 필요로 할 때마다 자동으로 서버에 데이터를 요청한다. ( 그리드 준비 여부는 onGridReady 이벤트를 사용)

개발 단계를 구체적으로 설명하면 아래와 같다.

단계	설명	코드 예시
1	프로젝트에 AG Grid 설치	`npm install --save ag-grid-community ag-grid-vue`
2	컬럼 정의 및 그리드 옵션 설정	`columnDefs`와 `gridOptions`를 `<script setup lang="ts">`에서 정의하고 `ref`로 선언
3	Infinite Row Model 활성화	`gridOptions`에서 `rowModelType`을 `'infinite'`로 설정하고, `paginationPageSize` 및 `cacheBlockSize`를 정의
4	onGridReady 함수에서 서버 데이터 소스 설정	`onGridReady`에서 `getRows` 함수가 포함된 `dataSource`를 설정
5	getRows 함수에서 서버 데이터 요청	`params.startRow`, `params.endRow`를 기반으로 페이지와 페이지 크기를 서버에 요청
6	서버 응답 처리	서버의 데이터 응답을 받아 `params.successCallback(data.rows, data.totalCount)`을 호출하여 그리드에 전달
7	Vue 컴포넌트 마운트 시 그리드 참조 설정	`onMounted`에서 `gridRef`를 통해 그리드 API에 접근하여 초기 설정 완료

코딩 - Vue3 & Spring : AG-Grid 페이징, 필터 구현하기

매번 서버 페이징이 필요한 경우 위와 같이 코딩하는 것은 여간 불편한 것이 아니다. 이런 이유에서 추상 형태의 DataSource 을 정의하고 공통으로 적용할 설정을 미리 정의하고 필요한 값만 전달하여 페이징 그리드를 구현하는 컴포넌트를 만들어 보았다.

아래는 PageableGridContent.vue 에서 사용하는 서버에서 데이터를 가져오는 PageableDataSource 에 대한 추상 AbstractPageDataSource 이다. 이를 통하여 좀더 쉽게 서버에서 데이터를 가져오는 데이터소스 구현을 가능하게 한다. ( 구현체에서는 규칙을 벗어 나지 않는 경우라면 서버 엔트포인트 값을 리턴하는 getPatchUrl () 만 구현하면 된다. 서버 프로그램은 스프링의 Pageable 형식으로 데이터를 리턴하는 것을 가정 하여 데이터소스 추상을 구현 했다.

위의 컴포넌트를 사용하여 1) 컴포넌트 임포트 2) 그리드 컬럼 정의 3) 태그를 사용하여 컴포넌트를 정의하는 것으로 그리드를 간단하게 구현 할 수 있다. 또한 컴포넌트에 직접 제어가능한 함수를 사용하여 새로고침, 선택된 데이터 접근, 필터 초기화 등을 제어할 수 있다. 그리드 컬럼에서 단수 데이터 출력이 아닌 버튼과 또는 이미지 출력 등의 작업이 필요한 경우는 사용자 정의 더러를 정의하고 버튼 클릭등의 이벤트는 이벤트 리스트너를 통하여 구현하였다.

다음은 위의 AbstractPageDataSource 활용하여 구현한 예이다. 아래는 목록을 조회하는 기능과 추가로 여러 함수를 포함하고 있다.

구현 클래스는 추가 기능이 필요하면 PageableDataSource 을 포함하여 새로운 타입을 정의하고 이를 구현하는 클래스를 AbstractPageableDataSource 상속하여 만든다. 구현 클래스는 getFetchUrl 함수를 구현하는 것으로 완성되며 this 이슈를 해결하기 위하여 반인딩을 사용하여 스토어를 생성하게 한다.

필요한 새로운 PageableDataSource 을 포함하는 type 생성
getFetchUrl 을 포함 새로운 type 을 구현하는 클래스 생성
구현 클래스를 사용하여 스토어 생성

import { RoleModel } from "@/types/studio/RoleModel";
import {
  API_HEADERS,
  authHeader
} from "@/util/helpers";
import axios from "axios";
import { defineStore } from "pinia";

import type {
  PageableDataSource
} from "@/types/studio/index";
import { AbstractPageDataSource } from "../AbstractPageDataSource";

// getById,getByName,loadById,saveOrUpdate 추가을 추가하여 IPageableRoleDataSource를 정의
type IPageableRoleDataSource = PageableDataSource & {
  getById: (roleId: number) => RoleModel;
  getByName: (name: string) => RoleModel;
  loadById: (roleId: number) => Promise<RoleModel>;
  saveOrUpdate: (item: RoleModel) => Promise<void>;
};
const baseUrl = `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/roles:find`;

class PageableRoleDataSource
  extends AbstractPageDataSource
  implements IPageableRoleDataSource
{
  getById(roleId: number) {
    return this.dataItems.value.find(
      (item: RoleModel) => item.roleId === roleId
    );
  }

  getByName(name: string) {
    return this.dataItems.value.find((item: RoleModel) => item.name === name);
  }

  async loadById(roleId: number) {
    const headers = { ...API_HEADERS, ...authHeader() };
    const category = await axios
      .get(
        `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/roles/${roleId}`,
        { headers: headers }
      )
      .then((response) => {
        const data = response.data;
        return data;
      })
      .catch((err) => {
        this.alertStore.error(err);
      });

    return category;
  }

  async saveOrUpdate(item: RoleModel) {
    const headers = { ...API_HEADERS, ...authHeader() };
    await axios
      .post(
        `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/roles/${item.roleId}`,
        JSON.stringify(item),
        { headers: headers }
      )
      .then((response) => {
        const dataItems = response.data;
      })
      .catch((err) => {
        this.alertStore.error(err);
      });
  }

  // API 엔드포인트 URL을 제공. 이 클래스만 구현하면 그리드는 정상 동작한다.
  getFetchUrl(): string {
    return baseUrl;
  }
}

// 필수로 표기된 부분은 반드시 동일하게 리턴해야 한다.  
export const usePageableRolesStore = defineStore("mgmt-pageable-roles-store", () => {
  const dataSource = new PageableRoleDataSource();
  return {      
    isLoaded: dataSource.isLoaded, // 필수
    dataItems: dataSource.dataItems, // 필수
    total: dataSource.total, // 필수   
    pageSize: dataSource.pageSize,// 필수
    getById: dataSource.getById.bind(dataSource),
    getByName: dataSource.getByName.bind(dataSource),
    loadById: dataSource.loadById.bind(dataSource),
    saveOrUpdate: dataSource.saveOrUpdate.bind(dataSource),
    setPage: dataSource.setPage.bind(dataSource),// 필수
    setSort: dataSource.setSort.bind(dataSource),// 필수
    setFilter: dataSource.setFilter.bind(dataSource),// 필수
    fetch: dataSource.fetch.bind(dataSource), // 필수
  };
});

예제 프로그램 실행 화면은 아래와 같다.

코딩 - 자바스크립트 CryptoJS 와 JAVA 간의 하이브리드 암호화 (RSA+AES)

2024-10-26T20:04:00.008+09:00

클라이언트와 서버간의 안전한 통신을 위하여 간단하게 암호화를 만들어보았다. 작업 환경은 아래와 같다.

◼︎ 환경

HW : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 15.0.1 (24A348)
TOOLS : Visual Studio Code, Java 11
Programming Language : Java, HTML, JavaScript

개인적으로 데이터 암호화는 AES (Advanced Encryption Standard) 알고리즘을 사용한다. AES는 대칭키 알고리즘 중 하나로, 데이터 암호화와 복호화에 동일한 키를 사용한다.

AES 키: 대칭키 암호화에서 데이터를 암호화하고 복호화하는데 사용되는 비밀 키. AES 키는 128, 192, 또는 256비트로 설정될 수 있다.
IV (Initialization Vector): AES-CBC 모드에서 사용되는 추가 보안 요소. IV는 암호화할 때마다 무작위로 생성되고, 암호화된 데이터와 함께 전송됩다.
Base64 인코딩: AES 키와 IV는 바이너리 데이터이므로, 이를 텍스트 형식으로 저장하고 전송하기 위해 Base64로 인코딩한다.

서버/클라이언트 환경을 고려하면 대칭키 방식의 암호화/복호화는 서버와 클라이언트 모두가 AES 키 와 IV 값을 미리 알고 있어야 한다. 키 관리의 위험성을 고려하면 암호화 키를 서버와 클라이언트가 공유 하는 대칭키 방식 보다는 비대칭키를 사용하는 것이 더 키 관리에 안전하다고 할 수 있다.

대칭키와 비대칭키 암호화의 장점과 단점은 아래와 같다.

대칭키 암호화 (Symmetric Encryption)

① 특징:

암호화와 복호화에 같은 키를 사용.
AES(Advanced Encryption Standard)와 같은 알고리즘이 대칭키 암호화에 해당.

② 장점:

빠른 속도: 대칭키 암호화는 비대칭키보다 훨씬 빠름. 특히 대량의 데이터를 암호화할 때 성능이 우수함.
간단한 구현: 동일한 키로 암호화와 복호화를 수행하기 때문에 상대적으로 간단하게 구현할 수 있음.

③ 단점:

키 관리 문제: 대칭키를 안전하게 공유하는 것이 문제. 만약 네트워크를 통해 키를 전송해야 한다면, 키가 중간에서 가로채기당할 위험이 있음.
보안성 문제: 키가 노출되면 데이터를 보호할 방법이 없음. 키 교환이 안전하지 않다면, 대칭키 암호화는 취약할 수 있음.

비대칭키 암호화 (Asymmetric Encryption)

① 특징:

암호화에는 공개키를, 복호화에는 개인키를 사용.
RSA(Rivest-Shamir-Adleman)와 같은 알고리즘이 비대칭키 암호화에 해당.

② 장점:

보안성: 비대칭키 암호화는 공개키를 사용해 암호화하므로 키 교환이 안전. 공개키는 누구나 사용할 수 있지만, 개인키는 소유자만이 알고 있기 때문에 보안성이 뛰어남.
키 관리 용이: 공개키는 네트워크를 통해 쉽게 공유할 수 있고, 개인키는 비밀로 유지되므로 키 교환이 안전하게 구현됨.

③ 단점:

속도 문제: 비대칭키 암호화는 대칭키 암호화에 비해 훨씬 느림. 특히 대량의 데이터를 암호화하는 데 비효율적임.
데이터 크기 제한: RSA와 같은 비대칭키 알고리즘은 암호화할 수 있는 데이터의 크기가 키 길이에 의해 제한됨.

이들 암호화 방식의 특성을 고려하면 서버/클라이언트 환경에서는 TLS/SSL 프로토콜(HTTPS) 등에서 널리 사용되는 비대칭키와 대칭키를 결합한 하이브리드 암호화 방식이 가장 안전하고 효율적이라고 할 수 있다.

참고로 아래는 TLS/SSL 프로토콜(HTTPS) 을 쉽게 설명하는 이미지 이다. (출처: https://has3ong.github.io/computer%20science/ssl-tls/ )

클라이언트/서버간의 안전한 데이터 암호화를 위한 하이브리드 방식은 아래와 같은 절차를 따른다.

서버는 클라이언트(웹) 에게 RSA 공개키를 배포
클라이언트는 랜덤 생성된 AES 키를 사용하여 데이터를 암호화
RSA 공개키로 AES 키를 암호화 하고 암호화된 데이터와 IV 값을 함께 서버에 전달
서버는 RSA 개인키로 암호화된 AES 키를 복호화하고 함께 전달된 IV 값을 사용하여 데이터를 복호화

하이브리드 방식의 암호화 방식을 적용하면 적은 노력으로 손쉽게 클라이언트와 서버간의 암호화 통신을 구현할 수 있다.

하이브리드 방식 암호화 구현에 있어 클라이언트에서 ❶ AES 암호화는 CryptoJS (JavaScript library of crypto standards) 을 사용하였고 ❷ RSA 암호화는 웹 암호화 API 의 일부로 제공되는 crypto.subtle 을 사용하였다. 주의 할 점은 crypto.subtle API는모든 브라우저에서 지원하지 않으며, 특히 일부 구형 브라우저나 특정 모바일 브라우저에서는 지원되지 않을 수 있다. 서버의 경우 기본 자바의 암호화 기능을 사용하였다.

Can I Use - Web Cryptography API 사이트를 통하여 호환성을 확인해 볼 수 있다. 이 사이트에 따르면 대부분의 웹 브라우저에서 지원된다.

하이브리드 방식 암호화 구현하기

서버는 AES 암호화를 위한 대칭키를 암호화기 위하여 먼저 RSA 비대칭키 생성한다.

비밀키는 안전하게 보관하고 공개키는 클라이언트에 전달한다. 클라이언트는 AES 키를 생성하여 데이터를 암호화하고 AES 키는 서버가 공개한 RAS 공개키로 암호화를 한다.

Encrypt Data 버튼을 클릭하여 데이터를 암호화 한다.

이제 공개키로 암호화된 AES 키 값, AES 로 암호화된 데이터와 IV 값을 서버에 전달한다.

공개키로 암호화된 AES 키 : BASE64로 인코딩
IV : BASE64로 인코딩
AES 로 암호화된 데이터 : BASE64로 인코딩

서버는 비밀키로 암호화된 대칭키 값을 복호화하고 키를 사용하여 암호화된 데이터를 복호화 한다.

참고자료

ChatGPT 4o : 코드는 ChatGPT 4o 을 사용하여 작성.

코딩 - Spring Boot 환경에서 설정 정보 암호화

2024-10-02T13:54:00.001+09:00

"Config Server 을 구성할 필요가 없는 경우 주요한 설정을 어떻게 암호화를 할 것인가"

Spring Boot 에서 Config Server를 사용하지 않고도 암호화를 적용하는 방법은 여러 가지가 있다. 특히, 민감한 데이터를 보호하기 위해 Jasypt 와 같은 라이브러리를 사용하여 암호화를 적용, 애플리케이션의 설정 파일이나 환경 변수에 저장된 비밀번호, API 키 등의 민감한 정보를 안전하게 암호화할 수 있다.

◼︎ 환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 13.2.4 (22F66)
TOOLS : Visual Studio Code, Java 11, Gradle, Docker
Version Control : GitHub
Programming Language : Java
Back-End Framework : Spring Boot 2.7.12, Spring Security 5.7.7
DBMS : MySql 8.0.33
Cloud : OCI (free tier account

Jasypt ?

Jasypt (Java Simplified Encryption) 는 자바 애플리케이션 속성 파일, 데이터베이스 비밀번호, 또는 기타 중요한 데이터를 쉽게 암호화하고 복호화할 수 있도록 도와주는 것이다. Jasypt는 복잡한 암호화 알고리즘을 이해하거나 구현할 필요 없이 간단한 API를 통해 보안을 향상시킬 수 있도록 설계되었다.

주요 특징

암호화 및 복호화 기능: 비밀번호, 속성 값 등의 중요한 데이터를 쉽게 암호화하고, 필요한 시점에 복호화
구성 파일 보호: 애플리케이션의 application.properties 또는 application.yml과 같은 설정 파일에서 중요한 정보(예: 데이터베이스 연결 정보)를 암호화
알고리즘 지원: AES, DES, PBE 등 다양한 암호화 알고리즘을 지원
설정이 용이: 환경 변수나 명령줄 인자를 통해 암호화 키를 전달하고, 자동으로 암호화된 데이터를 복호화할 수 있는 기능을 제공
스프링 통합: 스프링 프레임워크와 통합되어 스프링 부트 (Spring Boot) 애플리케이션에서 손쉽게 사용

Jasypt는 특히 애플리케이션 보안 향상을 위해 중요한 정보를 암호화하는 데 유용하며, 자바 기반 프로젝트에서 많이 사용된다.

Jasypt를 사용한 암호화 적용 방법

재십트(jasypt) 는 스프링 부트 (Spring Boot) 와의 통합을 돕기 위해 jasypt-spring-boot-starter 라이브러리를 제공한다. 이를 사용하면 Spring Boot 의 환경 설정 파일(application.properties, application.yml)에서 암호화된 값을 쉽게 처리할 수 있다. 아래는 gradle 기반 스프링 부트 (Spring Boot) 프로젝트에 재십트(jasypt) 암호화를 적용하는 것을 설명한다.

❶ 의존성 추가: build.gradle 에 jasypt-spring-boot-starter 라이브러리 의존성을 추가한다.

 implementation "com.github.ulisesbocchio:jasypt-spring-boot-starter:3.0.4" 

❷ 암호화된 값 사용: 애플리케이션의 application.properties 또는 application.yml 파일에 민감한 데이터를 암호화된 상태로 저장할 수 있다. 암호화된 값은 ENC(...) 형식으로 표기한다.

application.yml

  datasource:
    driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
    url: jdbc:log4jdbc:postgresql://localhost:5432/studio_db
    username: ENC(amX5KdNShNl7jMYsHfpWccYeGhDWHD9bXsxXQSZGuUI=)
    password: ENC(4EyexAjWphLdRG6NaDaPb2S2c6gU8PZr/QgLM7e4nY4=)  

❸ Jasypt Encryptor 설정: 재십트(jasypt) 가 암호화된 값을 복호화할 수 있도록 JasyptStringEncryptor 를 설정해야 한다. 스프링 부트 (Spring Boot) 애플리케이션에서는 암호화를 위한 비밀번호를 설정하는 것으로 간단하게 구현할 수 있다.

비밀번호를 전달하는 방법은 여러가지 방법이 있다.

환경변수로 전달
CI/CD 도구에서 지원하는 시크릿 관리 기능을 사용하여 전달
AWS Secrets Manager, HashiCorp Vault, Azure Key Vault 등의 비밀 관리 서비스 사용하여 전달
사용자 정의 JasyptStringEncryptor 을 구현하여 원하는 곳에서 비밀번호를 로드하여 직접 사용

아래는 환경변수를 사용하여 비밀번호를 전달하는 방법이다.

application.yml

  jasypt:

    encryptor:

      password: ${JASYPT_ENCRYPTOR_PASSWORD} # 환경 변수로 암호화 비밀번호 설정

JASYPT_ENCRYPTOR_PASSWORD 환경변수에 비밀번호를 세팅.

Linux/macOS:

export JASYPT_ENCRYPTOR_PASSWORD=your-encryption-password

./gradlew bootRun

Windows:

set JASYPT_ENCRYPTOR_PASSWORD=your-encryption-password

gradlew bootRun

❹ 암호화 : Jasypt CLI(Command Line Interface)를 사용하여 값을 암호화하거나 복호화할 수 있다. 예를 들어, 다음과 같이 명령어를 사용하여 값을 암호화할 수 있다.

encrypt input="yourSecretValue" password="your-encryption-password"

jasypt 1.9.3 (binaries and javadocs)

암호화된 값을 ❷ 암호화된 값 사용 과 같이 application.yml 설정에 기술하면 된다.

재십트(jasypt) 암호화

재십트(jasypt) 에서 디폴트로 적용되는 암호화 알고리즘과 관련된 주요 값들은 다음과 같다. 이 값들은 재십트(jasypt)를 기본 설정으로 사용할 때 적용되는 값 들이다.

① 디폴트 암호화 알고리즘

PBEWithMD5AndDES: 기본적으로 Jasypt는 PBE (Password-Based Encryption) 알고리즘 중 하나인 PBEWithMD5AndDES를 사용한다. PBEWithMD5AndDES는 MD5 해시 알고리즘과 DES(Data Encryption Standard)를 사용한 암호화 알고리즘이다.
이 알고리즘은 기본적인 보안성을 제공하지만, 현대적 암호화 표준에 비해 상대적으로 약한 것으로 간주되기 때문에 더 강력한 알고리즘을 사용할 수 있도록 설정을 변경하는 것이 좋다.

② 디폴트 해시 알고리즘

MD5: 재십트(jasypt)는 기본적으로 MD5 해시 알고리즘을 사용하여 암호화 키를 처리한다. MD5는 널리 사용되지만, 충돌 공격에 취약하다는 보안 문제로 인해 요즘은 SHA-256 또는 SHA-512와 같은 더 강력한 해시 알고리즘이 선호된다.

③ 키 생성 반복 횟수

1000번 반복: Jasypt는 기본적으로 암호화 키를 생성할 때 1000번의 반복을 수행한다. 이 값은 비밀번호 기반 암호화의 보안성을 높이기 위한 중요한 요소로 이 값을 더 높여 보안을 강화할 수 있다.

④ 디폴트 Salt Generation (솔트 생성)

랜덤 솔트: 재십트(jasypt)는 암호화 시 자동으로 랜덤 솔트(Salt) 값을 생성한다. 솔트는 암호화된 값의 보안성을 높이기 위해 추가되는 값으로, 암호화된 텍스트의 패턴화를 방지하는 역할을 한다.

⑤ 디폴트 출력 포맷

Base64: 재십트(jasypt)는 암호화된 텍스트를 기본적으로 Base64 로 인코딩하여 출력한다. Base64는 바이너리 데이터를 텍스트로 인코딩하는 방식으로, 암호화된 값을 쉽게 문자열로 표현할 수 있게 한다.

⑥ IV(Initialization Vector, 초기화 벡터)

기본적으로 Jasypt는 PBEWithMD5AndDES 알고리즘을 사용할 때 초기화 벡터(IV)를 생성하지 않는데 알고리즘 자체가 IV를 사용하지 않기 때문이다. 그러나 다른 알고리즘, 예를 들어 AES와 같은 알고리즘을 사용할 때는 IV가 자동으로 처리된다.

⑦ 디폴트 암호화기(PBE String Encryptor)

재십트(jasypt)는 기본적으로 **StandardPBEStringEncryptor**를 사용하여 문자열을 암호화 및 복호화한다.

이와 같은 기본 설정들은 애플리케이션의 보안 요구에 맞게 조정할 수 있으며, 기본값을 사용하더라도 어느 정도의 보안을 제공하지만, 더 강력한 알고리즘 변경 권장된다.

아래는 보안 수준에 따른 알고리즘 및 설정 값을 정리한 것이다. 운영 환경이라면 최소 중간 수준이상의 알고리즘 적용이 필요하다.

낮은 보안 수준

알고리즘 : PBEWithMD5AndDES
키 획득 반복 횟수 : 1000
키 길이 : 56
솔트 사용 : ✓
IV 사용 : ✗
설명 : 기본 Jasypt 설정. MD5와 DES를 사용하는 알고리즘으로 비교적 낮은 보안 수준. 과거에 널리 사용되었으나 현대의 공격에 취약.
권장 사용 환경 : 테스트 환경 또는 민감하지 않은 데이터를 암호화할 때.

보통 보안 수준

알고리즘 : PBEWithSHA1AndDESede
키 획득 반복 횟수 : 1000
키 길이 : 168
솔트 사용 : ✓
IV 사용 : ✗
설명 : SHA-1 해시 알고리즘과 3DES 암호화 알고리즘 사용. DES보다 더 안전하지만, SHA-1이 약해져 더 강력한 알고리즘이 권장됨.
권장 사용 환경 : 테스트 환경 또는 민감하지 않은 데이터를 암호화할 때.

중간 보안 수준

알고리즘 : PBEWithSHA256And128BitAES-CBC-BC
키 획득 반복 횟수 : 1000
키 길이 : 168
솔트 사용 : ✓
IV 사용 : ✓
설명 : SHA-256 해시 알고리즘과 AES-128 비트 암호화를 사용. AES는 고성능과 높은 보안성을 제공. IV를 사용하여 보안성을 강화.
권장 사용 환경 : 내부 시스템의 암호화 작업이나 중요하지만 최고 수준의 보안을 요구하지 않는 환경.

높은 보안 수준

알고리즘 : PBEWithHMACSHA512AndAES_256
키 획득 반복 횟수 : 1000
키 길이 : 256
솔트 사용 : ✓
IV 사용 : ✓
설명 : HMAC-SHA512 해시 알고리즘과 AES-256 비트 암호화를 사용. AES-256은 강력한 보안을 제공하며, HMAC을 사용해 무결성 보장.
권장 사용 환경 : 금융 서비스, 헬스케어 시스템 등 민감한 데이터를 보호해야 하는 환경.

매우높은 보안 수준

알고리즘 : PBEWithHMACSHA512AndAES_256
키 획득 반복 횟수 : 5000~10000
키 길이 : 256
솔트 사용 : ✓
IV 사용 : ✓
설명 : 암호화와 해시에서 최고 수준의 보안. 반복 횟수를 늘리고 AES-256을 사용하여 비밀번호 기반 암호화의 보안을 최대한 강화.
권장 사용 환경 : 금융 서비스, 헬스케어 시스템 등 민감한 데이터를 보호해야 하는 환경.

최고 보안 수준

알고리즘 : PBKDF2WithHmacSHA512 + AES_256
키 획득 반복 횟수 : 10000~50000
키 길이 : 256
솔트 사용 : ✓
IV 사용 : ✓
설명 : PBKDF2는 비밀번호 기반 키 도출 기능으로 반복 횟수와 HMAC-SHA512를 사용해 높은 보안성을 제공. AES-256과 함께 사용하면 최상의 보안을 제공.
권장 사용 환경 : 정부, 군사 시스템, 민감한 데이터를 보호하는 최고 수준의 보안이 요구되는 환경

중간 보안 요구 이상에서는 AES-256과 함께 PBEWithHMACSHA512AndAES_256 또는 PBKDF2WithHmacSHA512를 사용하는 것이 권장. AES-256은 현재 가장 안전한 암호화 표준 중 하나이며, HMAC-SHA512는 암호화 데이터의 무결성을 보장. 반복 횟수(Iterations)를 5000번 이상으로 설정하여 암호화 키 도출 과정의 보안을 더욱 강화하는 것을 권장.

특히 개인정보와 같은 민감한 데이터 보호가 필요한 환경에서는 AES-256과 HMAC-SHA512를 사용한 설정을 적극 추천.

중간 수준이상의 암호화 적용

테스트 환경에서는 디폴트 암호화 알고리즘 이외의 암호화를 사용하려는 경우 오류가 발생하여 진행이 불가 하였다. 이런 이유로 환경 이슈에 독립적으로 동작하도록 보니캐슬(Bouncy Castle) 암호화 프로바이터를 사용하였다. (맥 환경이 문제는 아닌가 추정만 하였다.)

❶ 의존성 추가: build.gradle 에 보니캐슬(Bouncy Castle) 라이브러리 의존성을 추가한다.

❷ 재십트(jasypt) 에 보니캐슬(Bouncy Castle) 설정

Jasypt 설정 예시 (AES 256 사용):

application.yml

  encryptor:
    password: ${JASYPT_ENCRYPTOR_PASSWORD} # 환경 변수로 암호화 비밀번호 설정
    algorithm: "PBEWithSHA256And256BitAES-CBC-BC"  # Bouncy Castle 알고리즘 사용
    providerName: "BC"  # Bouncy Castle 프로바이더 지정
    key-obtention-iterations: 1000
    pool-size: 1
    salt-generator-classname: "org.jasypt.salt.RandomSaltGenerator"
    string-output-type: "base64"

PBEWithSHA256And256BitAES-CBC-BC: 보니캐슬(Bouncy Castle)이 제공하는 AES-256 알고리즘이다.

❸ Bouncy Castle 프로바이더 등록

Java 환경에서 보니캐슬(Bouncy Castle)을 암호화 프로바이더로 등록해야 하며, 이 작업은 JVM이 시작될 때 수행할 수 있다. 스프링 부트 (Spring Boot) 에서는 Application.java 에 추가하여 프로바이터를 등록할 수 있다.

 import java.security.Security;
 import org.bouncycastle.jce.provider.BouncyCastleProvider;
 import org.springframework.boot.SpringApplication;
 import org.springframework.boot.autoconfigure.SpringBootApplication;

 @SpringBootApplication
 public class MyApplication {
        public static void main(String[] args) {
        if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) == null) {
            Security.addProvider(new BouncyCastleProvider());
        }
        SpringApplication.run(MyApplication.class, args);
    }
 }

좀더 자동화된 방법을 고민하다 재십트(jasypt) 라이브러리가 추가되어 있고 보니캐슬(Bouncy Castle) 암호화 라이브러리가 있는경우 보니캐슬(Bouncy Castle) 프로파이더를 추가 하고 디폴트 암호화(StandardPBEStringEncryptor) 모듈을 생성하도록 자동화된 설정을 구현하여 사용하였다.

다만 이경우 Jasypt CLI(Command Line Interface)를 사용하여 값을 암호화하거나 복호화 하는 것이 어려워저 추가로 암호화를 위한 RESTful API 을 추가하여 사용할 수 있도록 하였다.

특정 값을 암호화하려면 아래와 같이 curl 을 사용하여 암호화하고 yml 파일에 ENC() 함수를 사용하여 암호화된 값으로 설정을 추가하면 된다.

curl localhost:8080/data/encrypt -s -d 암호화할 데이터

참고자료

코딩 - Cloud Ready : Spring Config Server

코딩 - Vue3 : Uppy 을 이용한 파일 업로드

2024-08-09T22:33:00.002+09:00

◼︎ 환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 13.2.4 (22F66)
TOOLS : Visual Studio Code, Java 11, Gradle, Docker
Version Control : GitHub
Programming Language : Java, Vue3
Front-End Framework : Vue 3.4.30, Vuetify 3.6.10, ag-grid-vue3 31.3.2
Back-End Framework : Spring Boot 2.7.12, Spring Security 5.7.7
DBMS : MySql 8.0.33
Cloud : OCI (free tier account

1. 업로드 라이브러리 & 모듈 조사

Vue 3 환경에서 파일업로드 구현을 위한 인기있는 라이브러리 또는 모듈들에는 여러 가지가 있다. 추가로 사용성 확인을 위하여 npmjs.com 사이트를 활용하였다.

➀ Dropzone

Weekly Downloads: 363,089
Version: 6.0.0-beta.2
Last Publish: 3년 전
특징: 가장 많이 사용되는 파일 업로드 라이브러리 중 하나이며, Vue.js 에서도 널리 사용되고 있음. 하지만, Vue 3 공식 지원이 부족할 수 있음.

➁ Vue3 Dropzone

Weekly Downloads: 10,754
Version: 2.2.1
Last Publish: 8개월 전
특징: Dropzone.js의 Vue 3 통합 버전으로, Vue 3 프로젝트에서 드래그 앤 드롭 파일 업로드를 쉽게 구현할 수 있음.

➂ Vue Advanced Cropper

Weekly Downloads: 82,508
Version: 2.8.9
Last Publish: 2달 전
특징: 이미지 크롭 기능을 제공하는 파일 업로드 라이브러리로, Vue 3와의 호환성이 높고, 비교적 최근에 업데이트되었음.

➃ Uppy

Weekly Downloads: 23,383
Version: 4.1.0
Last Publish: 10일 전
특징: 강력한 모듈화 파일 업로드 라이브러리로, 여러 소스에서 파일을 업로드할 수 있으며, Vue 3와의 호환성도 좋음.

➄ Vue FilePond

Weekly Downloads: 21,154
Version: 7.0.4
Last Publish: 1년 전
특징: 사용자 친화적인 인터페이스를 제공하며, 다양한 파일 포맷을 지원. 다만, 최근에 업데이트가 없음.

➅ Vue Uploader

Weekly Downloads: 115
Version: 3.37.1
Last Publish: 1년 전
특징: 다운로드 수가 비교적 적으며, 최근 업데이트가 없는 편임. 작은 프로젝트나 간단한 용도로 적합할 수 있음.

간단하게 요약해보면 아래와 같다.

가장 많이 사용되는 라이브러리: Dropzone은 여전히 가장 많은 다운로드 수를 기록하고 있으며, 널리 사용되고 있다. 하지만 Vue 3에 대한 직접적인 지원이 부족할 수 있다.
Vue 3 에 적합한 라이브러리: Vue Advanced Cropper, Uppy, Vue FilePond, Vue3 Dropzone 등은 Vue 3에서 사용할 수 있는 좋은 선택이다.

개인적으로는 Vue3 Dropzone, Vue FilePond 은 사용해 보았고 이번에는 대용량 파일 업로드가 강점이라고 하는 Uppy 을 사용해 보았다.

2. Uppy

Uppy는 강력하고 모듈화된 파일 업로드 라이브러리로, 다양한 파일 소스에서 업로드를 지원하며 파일 업로드 경험을 쉽게 관리할 수 있도록 설계되었다. Uppy는 최신 웹 기술을 활용하며, 파일 업로드를 직관적으로 구현할 수 있도록 다양한 플러그인을 제공한다. Vue.js와의 통합도 지원하여, Vue 프로젝트에서 Uppy의 기능을 쉽게 사용할 수 있다.

모듈식 구조: 필요한 기능만 선택적으로 사용할 수 있도록 다양한 플러그인으로 구성되어 있다. 예를 들어, 파일 드래그 앤 드롭, 웹캠, Google Drive, Dropbox 등 다양한 소스를 지원한다.

다양한 파일 소스: 로컬 파일뿐만 아니라 원격 소스(예: Google Drive, Dropbox, Instagram)에서도 파일을 업로드할 수 있다.
Vue.js 통합: @uppy/vue 패키지를 통해 Vue.js 프로젝트에 쉽게 통합할 수 있다.
커스터마이징 가능: 업로드 UI와 동작을 프로젝트의 요구에 맞게 커스터마이징할 수 있다. 또한, 업로드 진행률 표시, 취소, 재시도 등의 기능도 제공. ⇨ UI 커스터마이징이 비교적 용의했다.

3. Uppy 설치

Uppy와 Vue 통합 패키지를 설치한다.

 npm install @uppy/core @uppy/dashboard @uppy/drag-drop @uppy/file-input @uppy/progress-bar
    @uppy/vue @uppy/xhr-upload --save

4. Uppy 을 이용한 파일 업로드

업로드 구현은 아래와 같은 순서로 코딩하면 된다.

❶ Uppy 컴포넌트 임포트

<script setup lang="ts">
 // import upload component(uppy)
 import Uppy from '@uppy/core';
 import { Dashboard } from '@uppy/vue';
 import XHRUpload from '@uppy/xhr-upload'; 
 import '@uppy/core/dist/style.css';
 import '@uppy/dashboard/dist/style.css';

❷ Vue 컴포넌트에서 Dashboard 사용

<div class="dashboard-container">
    <Dashboard :uppy="uppy"  
               inline="true"  
               :height="200"  
               :note="'Images only, up to 10MB'"
               :metaFields="metaFields" />
</div>  

@uppy/vue에서 가져온 Dashboard 컴포넌트를 사용하여 Vue 템플릿에서 Uppy 대시보드를 직접 렌더링. inline 속성을 사용 대시보드를 <div> 요소에 직접 렌더링 되도록 설정.

metaFields 을 사용하여 업로드할 파일과 관련된 추가적인 메타데이터를 수집하고, 사용자로부터 입력받을 수 있게 한다. 이를 통해 파일에 대한 추가 정보를 서버로 전송하거나, 파일 처리 로직에서 메타데이터를 활용할 수 있다. → 이부분은 확인 할 수 없었다.

❸ Uppy 인스턴스를 생성하고 파일업로드 플러그인을 설정

 const fileUploadUrl = computed(() => {
    return `${import.meta.env.VITE_API_URL}/data/secure/mgmt/resources/images/${props.imageId}/upload`
 })
 const uppy = new Uppy({
    autoProceed: false, // 수동으로 업로드 시작
    restrictions: {
        maxFileSize: 10000000,  // 1최대 파일 크기: 10MB
        maxNumberOfFiles: 5,    // 업로드 가능한 최대 파일 수
        minNumberOfFiles: 1,    // 업로드 가능한 최소 파일 수
        allowedFileTypes: ['image/*']
    }
 })
 .use(XHRUpload, {
        endpoint: fileUploadUrl.value, // 업로드할 서버 엔드포인트
        fieldName: 'file',             // 서버에 전송되는 파일의 필드 이름
        formData: true,                // FormData를 사용하여 파일을 업로드 (멀티파트 사용)
        headers: {
            ...authHeader(),
        },
        retryDelays: [0, 1000, 3000, 5000]
});

참로로 authHeader 는 JWT 토큰 관련 값을 정의하는 내용이다. 이런 방식으로 헤더에 값을 추가할 수 있다.

Uppy 는 여러가지 다수의 업로드 방식을 지원하고 있고 여기에서는 가장 일반적인 XHRUpload 을 적용했다.

XHRUpload: 가장 일반적인 파일 업로드 방식으로, 대부분의 서버에서 지원.
Tus: 대규모 파일 업로드 및 네트워크 문제로 인한 업로드 중단 시 재개를 지원하는 프로토콜
Multipart: multipart/form-data 형식으로 서버에 파일을 전송.
S3 Multipart: AWS S3에 대규모 파일을 멀티파트 방식으로 업로드.
Transloadit: 클라우드 기반 업로드 서비스와 통합

❹ 파일 업로드시 추가 정보 전송
파일을 업로드 할때 추가 정보를 전송하려면 uppy 의 upload 이벤트를 사용하여 추가하면된다. 이경우 멀티파트 파마메터 형식으로 추가된 값들이 전달된다.

uppy.on('upload', (data) => {
    uppy.setMeta({ 
        objectId: dataRef.value.objectId ,
        objectType: dataRef.value.objectType,
        link: createSharedLink.value,
        description: dataRef.value.description
     });
});

❺ onBeforeUnmount 을 사용 컴포넌트가 파괴되기 전에 Uppy 인스턴스를 정리

 onBeforeUnmount(() => {
   uppy.destroy();
 });

❻ 업로드 영역 크기 조정하기

Dashboard 의 height 을 사용해도 높이가 조정 되지 않기 떄문에 CSS 을 아래와 같은 방식으로 수정해 적용해야 한다.

<style scoped>
 ::v-deep .uppy-Dashboard {
  height: 250px; /* 원하는 높이로 설정 */
  max-height: 100%;
  display: flex;
  flex-direction: column;
 }
</style>

그림1. 파일 업로드 화면

그림2. 파일을 추가한 화면

그림3. 파일 업로드가 성공한 경우

➐ 서버 프로그램
XHRUpload 업로드 모듈의 경우 formData 옵션을 사용하면 multipart/form-data 형식으로 서버에 전송되기 때문에 기존 업로드 프로그램을 사용하여 업로드를 구현할 수 있다.

 @PostMapping(value = { "/images/{imageId:[\\p{Digit}]+}/upload" }, produces = MediaType.APPLICATION_JSON_VALUE)
  public List<Image> upload(
      @PathVariable Long imageId,
      @RequestParam(value = "objectType", defaultValue = "-1", required = false) Integer objectType,
      @RequestParam(value = "objectId", defaultValue = "-1", required = false) Long objectId,
      @RequestParam(value = "description", required = false) String description,
      @RequestParam(value = "link", defaultValue = "false", required = false) Boolean createLink,
      @RequestParam("file") List<MultipartFile> files) throws NotFoundException, IOException, UnAuthorizedException {

    User user = SecurityHelper.getUser();
    List<Image> list = new ArrayList<>();

    for (MultipartFile mpf : files) {
      String fileName = StringUtils.cleanPath(mpf.getOriginalFilename());
      InputStream is = mpf.getInputStream();
      log.debug("upload <file name:{}, size:{}, type:{}>", fileName, mpf.getSize(), mpf.getContentType());
      // 업로드 파일을 처리한다.

      list.add(newImage);
    }
    return list;
  }

5. 대용량 파일 업로드

Uppy 에서 대용량 파일 업로드는 Tus 프로토콜을 사용하여 구현 할 수 있다. Tus는 대규모 파일 업로드를 효율적으로 처리할 수 있도록 설계된 오픈 프로토콜로 Uppy는 Tus를 통해 파일을 청크 단위로 업로드하고, 중단된 업로드를 재개하는 등의 기능을 제공한다.

npm install @uppy/tus

Uppy 에서는 간단하게 XHRUpload 파일 업로드 모듈을 Tus 로 변경해주면 된다.

import Tus from '@uppy/tus';
const tusFileUploadUrl = computed(()=>{
    return `${import.meta.env.VITE_API_URL}/data/secure/mgmt/resources/files/${ props.imageId}/tus`;
}) 
uppy.use(Tus, {
  endpoint: tusFileUploadUrl.value, // Tus 서버 엔드포인트
  chunkSize: 5 * 1024 * 1024, // 5MB 청크 사이즈
  headers: {
    ...authHeader(),
  },
  retryDelays: [0, 1000, 3000, 5000]
 })
;

클라이언트 부분과 다르게 서버는 Tus 프로토콜에 따른 서버 프로그램을 새로 구현해야한다.

Tus 프로토콜

Tus 프로토콜은 클라이언트와 서버 간 4단계로 파일을 업로드합니다.

❶ 파일 생성(Create):

클라이언트는 서버에 새로운 업로드를 생성하도록 요청한다.
이 요청에는 파일의 크기와 메타데이터가 포함될 수 있다.
서버는 업로드에 고유한 URL을 생성하고 클라이언트에게 반환한다.
파일 및 메타 정보는 이때만 전송된다. 이후에는 데이터만 전송된다.

❷ 파일 업로드(Upload):

클라이언트는 생성된 URL을 사용하여 파일의 특정 바이트를 서버에 업로드한다.
서버는 클라이언트가 업로드한 바이트를 확인하고, 다음 업로드 시 어디서부터 시작할지 오프셋(Upload-Offset)을 반환한다.

❸ 업로드 재개(Resume):

업로드 중단 시 클라이언트는 서버에서 제공한 오프셋을 사용하여 중단된 지점부터 업로드를 재개할 수 있다.

❹ 업로드 완료(Completion):

모든 바이트가 성공적으로 업로드되면 업로드가 완료된다.

프로토콜 메시지

OPTIONS: 서버가 Tus 프로토콜을 지원하는지 확인하고, 지원하는 기능을 확인하기 위해 클라이언트가 전송. 서버는 지원하는 버전, 최대 파일 크기 등의 정보를 응답.
POST: 새로운 업로드를 생성하기 위해 사용. 서버는 업로드 URL을 응답합니다. ❶
HEAD:업로드 상태를 확인하기 위해 사용. 서버는 현재 업로드된 바이트의 오프셋을 응답.
PATCH: 파일의 특정 바이트를 업로드하기 위해 사용. 서버는 업로드된 바이트를 저장하고, 새로운 오프셋을 응답. ❷❸
DELETE:업로드를 취소하거나 삭제하기 위해 사용. 서버는 업로드된 데이터를 삭제합니다.

그림4. 파일 업로드 프로세스

다음은 파일이 업로드되면 유니크한 아이디를 생성하고 메타 정보는 meta.json 형태로 저장하여 청크파일 업로드를 구현하는 예이다.

사용기 - 생성형 AI 를 이용한 코딩 후기

2024-07-18T10:17:00.007+09:00

ChatGPT 4o

1. 코드 생성

존재하는 코드 개선 JWTFilter

🆀 Spring Security 필터에 커스텀 JWTFilter 을 추가 하여 사용하고 있다. JWTFilter에서 오류가 발생하면 login 페이지가 아닌 오류 메시지를 JSON 데이터로 응답하게 하려면

🅰 GitHub Copilot 의 경우 JWTFilter에서 오류가 발생하면 HttpServletResponse 을 사용하여 JSON 데이터를 만들어 응답하라고 답변.

✓ 제시된 코드는 문제를 해결하지 못함. Spring Security 에 의해서 설정된 login 페이지로 이동한다.

🅰 ChatGPT 의 경우 동일 질문에 대한 답으로 CustomAuthenticationEntryPoint 을 구현하는 방법으로 답변

✓ 문제를 해결.

GitHub Copilot

1. 문서자동화

함수 블록 코드를 기반으로 JavaDoc 문서 만들기

함수에 문서화를 위하여 JavaDoc 주석 기호를 입력 /** */

함수 블록의 코드 로직을 기술 하려면 1. 입력하면 로직 설명을 제시. 순차적으로 2. , 3. 을 입력하여 이어 로직 설명을 제시.

JavaDoc 주석의 첫줄로 이동 공백을 입력하고 기다리면 함수에 대한 요약을 제시.

2. 코드 생성

소스 코드 기능 개선

🆀 alert.value.message.response.data.error.exception 값과 스트링 배열을 비교하여 일치하는 경우 authAtore.loguot () 을 실행하려면

🅰 언어의 특성을 고려하여 비교할 문자열 배열을 정의하고 존재 여부를 검사하여 일치하는 경우 함수를 호출하는 설명과 예제를 제시.

✓ 참조된 소스가 Vue 언어로 작성된 코드인 것을 확인하여 자바 스크립트 언어 문법으로 정확한 답변을 함

코딩 - Vue3 & Spring : AG-Grid 페이징, 필터 구현하기

2024-07-08T16:13:00.006+09:00

◼︎ 환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 13.2.4 (22F66)
TOOLS : Visual Studio Code, Java 11, Gradle, Docker
Version Control : GitHub
Programming Language : Java, Vue3
Front-End Framework : Vue 3.4.30, Vuetify 3.6.10, ag-grid-vue3 31.3.2
Back-End Framework : Spring Boot 2.7.12, Spring Security 5.7.7
DBMS : MySql 8.0.33
Cloud : OCI (free tier account)

AG-Grid 을 이용한 그리드 구현

Vue3 에서 AG-Grid 는 다음과 같은 3단계 과정을 통하여 만들 수 있다.

① Vue3 용 ag-grid-vue3 패키지 설치

npm install --save ag-grid-vue3

② AG-Grid CSS 스타일 추가

import "ag-grid-community/styles/ag-grid.css"; // Mandatory CSS required by the grid
import "ag-grid-community/styles/ag-theme-quartz.css"; // Optional Theme applied to the grid

③ AG-Grid 설정 ( 그리드를 구현한 vue 파일에서 )

gridOptions를 사용하여 그리드의 전반적인 공통 설정을 관리하고, columnDefs를 사용하여 각 컬럼의 설정을 관리한다. 이를 통해 그리드의 설정을 더 쉽게 체계적으로 관리할 수 있다.

<template> 
    <AgGridVue class="ag-theme-quartz" 
        :gridOptions="gridOptions"
        :columnDefs="columnDefs" 
        :rowData="gridData" 
        @grid-ready="onGridReady"
        style="height:600px;"></AgGridVue>
</template>

<script setup lang="ts">
import { ref, onMounted } from 'vue';

import { AgGridVue } from "ag-grid-vue3"; // Vue Data Grid Component
import type { GridApi, IGetRowsParams } from 'ag-grid-community';
import type { GridOptions, ColDef } from 'ag-grid-community';

// ag-grid 
const loader = ref(false);
const gridData = ref([]);
const gridApi = ref<GridApi | null>();

// ag-grid options for common. 
const gridOptions: GridOptions = {
    defaultColDef: {
        flex: 1,
        minWidth: 100,
        resizable: true,
        sortable: true,
        filter: true,
        cellStyle: {
          display: 'flex',
          alignItems: 'center'
        }
    },
    columnTypes: {
        string: {
            filter: 'agTextColumnFilter',
            filterParams: { suppressAndOrCondition: true },
            cellStyle: { textAlign: 'center' },
        },
        number: {
            filter: 'agNumberColumnFilter',
            filterParams: { suppressAndOrCondition: true },
            cellStyle: { textAlign: 'right' },
        },
    },
};


// define grid coloums
const columnDefs = [
    { field: 'groupId', headerName: 'ID', type: 'number', 
      width: 100, sortable: true },
    { field: 'name', headerName: 'Name', sortable: true , type:"text", 
      flex:3 , cellRenderer : GroupCellRenderer}, // 사용자 정의 셀 렌더러.
    { field: 'description', headerName: 'Description', type: 'string', 
      width: 50, sortable: false , filter:false},
];

const onGridReady = (params: any) => { 
    gridApi.value = params.api;
};

gridOptions : 그리드의 전반적인 설정을 정의. (defaultColDef, rowData, paginationPageSize, cacheBlockSize, rowSelection, getRowHeight 등)
columnDefs: 각 컬럼의 설정을 정의. 각 컬럼에 대해 headerName, field, sortable, filter, cellStyle, cellRenderer 등을 설정.
rowData: 그리드에 표시할 데이터를 설정.
onGridReady: 그리드가 준비되면 gridApi 인스턴스을 저장하여 그리드 제어에 사용

서버 사이드 페이징

서버 사이드 페이징 기능을 사용하지 않는 경우라면 간단하게 아래와 같이 rowData 에 해당하는 gridData 객체에 데이터를 강제로 주입해주기만 하면 쉽게 구현이 가능하지만 페이지, 필터, 소팅 등의 기능들을 서버에서 처리하는 것은 조금 더 많은 수고가 필요하다.

onMounted(async () => {
    fetch(`https://api.example.com/data`)
    .then(response => response.json())
    .then(data => {
        gridData.value = data.rows;
     })
     .catch(error => {
         console.error(error);
     });});

유료 버전을 사용하는 경우라면 gridOptions 의 rowModelType 값을 'serverSide' 로 변경하고 추가로 datasource 를 설정하면 쉽게 구현이 되는것으로 보이지만 무료 커뮤니티 버전은 좀더 복잡한 과정을 진행해야 한다.

rowModelType 은 그리드가 데이터를 로드하고 관리하는 방식을 결정한다. AG-Grid는 다양한 데이터 로딩 및 관리 요구를 충족시키기 위해 여러 가지 rowModelType을 제공하며, 각 타입은 특정 사용 사례에 최적화되어 있다. 무료 버전에서 서버 사이드 페이징을 구현하려면 rowModelType 값을 infinite 을 사용하여 구현해야 한다.

 
<AgGridVue class="ag-theme-quartz" 
     :rowModelType="'infinite'"
     :gridOptions="gridOptions"
     :columnDefs="columnDefs" 
     :pagination="true" 
     :paginationPageSize="pageSize"
     :cacheBlockSize="cacheBlockSize"
     @grid-ready="onGridReady"
     style="height:600px;"></AgGridVue>

페이징 기능을 사용하기 위하여 아래와 같은 설정을 추가한다. 가독성을 고려하여 gridOptions 에 추가하지 않고 AgGridVue 의 개별 속성 값을 직접 설정하는 방식을 사용했다.

pagination : 그리드에서 페이징 기능을 사용할지를 결정하는 옵션. 기본적으로 pagination 속성을 true로 설정하면 페이징이 활성화된다. 페이징이 활성화되면 그리드는 한 번에 일정한 수의 행만 표시하고, 사용자가 페이지를 전환할 수 있도록 페이지 내비게이션 컨트롤을 제공한다.
paginationPageSize : 한 페이지에 표시할 행(row)의 수를 설정하는 옵션. 이 속성을 설정하면 사용자가 그리드 페이지를 전환할 때마다 이 수만큼의 행이 표시되며 기본값은 100이다. (참고로 서버에서 데이터를 페이징하여 가져오는 값과는 구분된다.)
cacheBlockSize : infinite 또는 serverSide row model을 사용할 때 한 번에 서버에서 가져올 데이터의 블록 크기를 설정하는 옵션. 이 속성은 서버에서 데이터를 페이징 방식으로 가져올 때 유용하며 기본값은 100이다. (-> 서버에 전달하는 페이징 크기 값)

이제 데이터를 가져오는 datasource 에 대한 코딩이 필요하다. datasource 설정은 유연성을 고려하여 onGridReady 이벤트에서 설정한다. 주의할 것은 이벤트에서 인자로 전달되는 params 값을 사용하여 페이지 정보를 서버에 전달해야 하는 점이다.

function sortString (sort: SortModelItem[] ) {
    if( sort.length > 0 ) {
      return sort[0].colId + ',' + sort[0].sort  ||''.toUpperCase(); 
    }
    return null;
}

const onGridReady = (params: any) => { 
    gridApi.value = params.api;
    const dataSource = {
        getRows: async (params: IGetRowsParams) => {
            const page = Math.floor(params.startRow / pageSize.value);
            const pageSizeValue = params.endRow - params.startRow;
            const filterModel = params.filterModel;
            const sortModel = params.sortModel;
            try {
                dataStore.setSort(sortModel);
                dataStore.setFilter(filterModel); 
                dataStore.setPage(page);
                filtersActive.value = Object.keys(filterModel).length > 0;
                await axios.post(`https://api.example.com/data`,
                    JSON.stringify(filterModel),
                    {  
                      params: {
                       ...{
                           page: page,
                           size: cacheBlockSize.value,
                           sort: sortString(sortModel),
                      },
                    },
                })
                .then((response) => {
                    const data = response.data;
                    gridData.value = data
                    total.value = data.totalElements;
                    params.successCallback(gridData.value, data.totalElements );
                ).catch(error => {
                    console.error(error);
                }); 
                params.successCallback(gridData.value, total.value);
            } catch (error) {
                params.failCallback();
                console.error(error);
            }
        }
    };
    params.api.setGridOption('datasource', dataSource);
};

위의 예는 서버에 post 방식으로 sorting, paging, filter 정보를 전달하고 있는데 Spring JPA 를 사용하고 있다면 아주 쉽게 서버 프로그램을 만들어 볼 수 있다.

추가로 서버에 데이터를 전송할 때에 Map 형식의 AG-Grid 필터값을 객체 배열로 변환하고 필터 타입을 약어로 변경하여 서버로 전송하도록 아래와 같은 변환 함수를 사용 변환하여 전송했다.

export const convertAgGridFilterToServerFormat = (agFilterModel) => {
  const kendoFilters = Object.keys(agFilterModel).map((colId) => {
    const filter = agFilterModel[colId];
    let operator;
    switch (filter.filterType) {
      case 'text':
        operator = convertNumberFilterType(filter.type);
        break;
      case 'number':
        operator = convertNumberFilterType(filter.type);
        break;
      case 'boolean':
        operator = 'eq';
        break;
      case 'date':
        operator = convertNumberFilterType(filter.type);;
        break;
      default:
        operator = 'eq';
    }
    return {
      field: colId,
      operator: operator,
      value: filter.filter
    };
  });
  return {
    logic: 'and',
    filters: kendoFilters
  };
};

// 숫자 필터 타입 변환 함수
const convertNumberFilterType = (type) => {
  switch (type) {
    case 'equals':
      return 'eq';
    case 'notEqual':
      return 'ne';
    case 'lessThan':
      return 'lt';
    case 'lessThanOrEqual':
      return 'lte';
    case 'greaterThan':
      return 'gt';
    case 'greaterThanOrEqual':
      return 'gte';
    case 'contains':
      return 'contains'
    default:
      return 'eq';
  }
};

아래는 별도의 store 객체로 분리하여 서버 통신 모듈을 구성한 예이다.

import { API_HEADERS, authHeader, convertAgGridFilterToKendo } from "@/util/helpers";
import axios from "axios";
import { defineStore } from "pinia";
import { computed, ref } from "vue";
import { useAlertStore } from "../../alert.store";
import { GroupModel } from "@/types/models/GroupModel"; 
import type { SortModelItem } from 'ag-grid-community';
 
export const usePageableGroupsStore = defineStore("pageable-groups-store", () => {
  
  // error state store
  const alertStore = useAlertStore();

  // state
  const isLoaded = ref<boolean>(false);
  const dataItems = ref<GroupModel[]>([]);
  
  // pageable
  const total = ref<number>(0);
  const page = ref<number>(1);
  const pageSize = ref<number>(20);
  const sort = ref<SortModelItem[]>([]);
  const filter = ref({ logic: "and", filters:[] });

  // getters
  const getById = computed(() => {
    return (groupId: number) =>
      dataItems.value.find((item) => item.groupId === groupId);
  });

  const getByName = computed(() => {
    return (name: string) => dataItems.value.find((item) => item.name === name);
  });

  // setters 
  function setSort(newValue: SortModelItem[]) {
    sort.value = newValue;
  }
 
  function setFilter(newValue:any) {
    filter.value = convertAgGridFilterToKendo(newValue) ;
  }

  function setPage(newVal: number): void {
    if (page.value === newVal) return;
    page.value = newVal;
    isLoaded.value = false; 
  }
  // actions
  async function loadById(groupId: number) {
    const headers = { ...API_HEADERS, ...authHeader() };
    const category = await axios.get(
        `${ import.meta.env.VITE_API_URL }/data/secure/mgmt/security/groups/${groupId}`,
        { headers: headers }
      )
      .then((response) => {
        const data = response.data;
        return data;
      })
      .catch((err) => { 
        alertStore.error(err);
      });
    return category;
  }

  async function saveOrUpdate(item: GroupModel) {
    const isNew = item.groupId === 0;
    const headers = { ...API_HEADERS, ...authHeader() };
    await axios
      .post(
        `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/groups/${item.groupId}`,
        JSON.stringify(item),
        { headers: headers }
      )
      .then((response) => {
        const dataItems = response.data;
        isLoaded.value = false;
      })
      .catch((err) => { 
        alertStore.error(err);
      });
  }


  function sortString () {
    if( sort.value.length > 0 ) {
      return sortField() + ',' + sortDir()||''.toUpperCase(); 
    }
    return null;
  }
   
  function sortField() {
    if (sort.value.length > 0) {
      return sort.value[0].colId;
    }
    return null;
  }

  function sortDir() {
    if (sort.value.length > 0) {
      return sort.value[0].sort ;
    }
    return null;
  }

  function pagableParams(){
    return {
      page: page.value,
      size: pageSize.value,
      sort: sortString(),
    }
  }

  function filterParams() {
    var params = {};
    if (filter.value.filters.length > 0) {
      filter.value.filters.forEach( item =>{
        params[item.field] = item.value;
      }) 
    } 
    return params;
  }


  async function fetch() {
    const headers = { ...API_HEADERS, ...authHeader() };
    if( filter.value.filters.length > 0){
      return await axios.post(
        `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/groups:find`,
        JSON.stringify(filter.value),
         {  
          params: {
            ...pagableParams(),
          },
          headers: headers })
      .then((response) => {
        const data = response.data;
        dataItems.value = [];
        total.value = data.totalElements; 
        data.content.forEach((item) => {
          dataItems.value.push(item);
        });
        
        isLoaded.value = true;
        }).catch( err => {  
          alertStore.error(err); 
        }); 
    }else{
      await axios
      .get( `${import.meta.env.VITE_API_URL}/data/secure/mgmt/security/groups`, { 
        params: {
          ...pagableParams()
        },
        headers: headers })
      .then((response) => {
        const data = response.data;
        dataItems.value = [];
        total.value = data.totalCount;
        data.items.forEach((item) => {
          dataItems.value.push(item);
        });
        isLoaded.value = true;
      })
      .catch((err) => {
        alertStore.error(err);
      });
    }
  }
  return {
    isLoaded,
    dataItems,
    total,
    page,
    pageSize,
    getById,
    getByName,
    setFilter,
    loadById,
    fetch,
    saveOrUpdate,
    setPage,
    setSort, 
  };
});

서버 프로그램

Vue 프로그램에서 요청을 처리하기 위한 서버 프로그램은 스프링 컨트롤러를 이용하여 코딩하면 된다. 아래 컨트롤러 예제는 페이징과 소팅 값은 파라메터 형태로 필터 값은 바디 형태로 바인딩 하고 있다. (-> 페이징 및 소팅은 Spring 에서 제공하는 Pageable 을 활용하여 바인딩)

    @PostMapping(value = "/data", produces = MediaType.APPLICATION_JSON_VALUE)
    public Page<Group> findGroups(@RequestBody FilterModel filter, @PageableDefault(size = 100, sort = "userId", direction = Sort.Direction.DESC) Pageable pageable) { 
        return groupService.findGroups(filter.getFilters(), pageable);
    }

필터는 별도의 필터 클래스를 정의하여 사용한다. 위 코드에서 groupService 는 에 해당하는 소스는 데이터베이스에서 데이터를 조회하기 위하여 JPA Repositry 을 기반으로 하는 GroupRepository 을 호출하게 된다. GroupRepository 클래스는 필터에 따른 동적 쿼리를 지원하기 위하여 JpaRepository 와 JpaSpecificationExecutor 을 상속 받도록 한다.

groupService 서비스 클래스는 ⑴ 필터 객체(FilterModel) 배열과 페이징(Pageable) 객체를 인자로 받아 ⑵ Specification 객체를 생성하고 ⑶ Repository 객체의 findAll 함수를 호출하여 Page 형식으로 데이터를 응답받아 리턴하는 형태로 구현한다.

코딩 - Vue3 : AG-Grid 사용하기

2024-06-26T14:57:00.002+09:00

◼︎ 환경

Model : MacBook Pro (14-inch, 2021)
CPU : Apple M1 Pro
MENORY : 16GB
DISK : 512 GB SSD
OS : macOS 13.2.4 (22F66)
TOOLS : Visual Studio Code, Java 11, Gradle, Docker
Version Control : GitHub
Programming Language : Java, Vue3
Front-End Framework : Vue 3.4.30, Vuetify 3.6.10, ag-grid-vue3 31.3.2
Back-End Framework : Spring Boot 2.7.12, Spring Security 5.7.7
DBMS : MySql 8.0.33
Cloud : OCI (free tier account)

Kendo UI 을 이용했지만 1년 단위 개발자 라이선스가 부담이 되어 Vue 3에서 사용할 수 있는 그리드들 중에서 AG Grid Community 무료 버전을 사용해보기로 했다.

AG Grid Community는 필터링, 정렬, 그룹핑 등 다양한 기능을 제공하며 대규모 데이터 처리에 특히 유용하다. 추가로 무료로 제공되기 때문에 많은 프로젝트에서 널리 사용된다고 한다.

1. 설치하기

설치는 간단하게 아래 명령을 사용하여 패키지를 설치할 수 있다. 사용하는 것 역시 별도의 설정이 없어도 바로 사용할 수 있다.

npm install --save ag-grid-vue3

가장 힘들었던 부분이 특정 컬럼(셀)에 사용자 정의 렌더러을 지정하여 버튼들을 그리고 해당 버튼을 클릭하면 해당 이벤트에 따라 저장/삭제 동작을 구현하는 것이었다.

Actions 에 해당 하는 셀은 ActionCellRenderer.vue 만들어 구현을 했다. 문제는 row 데이터에 따라 버튼을 제어( 노출/숨김) 하고 클릭시 이벤트를 받아 서버 통신을 통해서 삭제/저장을 구현하는 화면을 구현하려고 했다.

1) defineProps 함수를 사용하여 전달된 params 값을 바인딩 하려고 했으나 이부분이 해결되지 않아 params 을 직접 접근하는 방식으로 코드를 작생했다.

const props = defineProps<{
    data?: { [key: string]: any };
    api?: any;
    node?: any;
    params: {
        data: { [key: string]: any };
        api: any;
        node: any;
    }
}>();

2) 버튼을 클릭하면 defineEmits 사용하여 정의한 이벤트를 발생하는 것으로 코드를 만들었지만 부모 즉 ag-grid 구현 화면에 해당 이벤트를 전달하는 방법을 찾지 못해 prams.api 로 전달되는 GridApi.dispatchEvent() 함수를 사용했다. (-> 이부분을 알아내는 것이 가장 힘들었던 것 같다)

const saveRow = () => {
    props.params.api.dispatchEvent({
            type: 'actionCellRenderer:save',
            data: props.params.data
    });
};
const deleteRow = () => {
    emits('delete', props.params.data);
    props.params.api.dispatchEvent({
            type: 'actionCellRenderer:delete',
            data: props.params.data
    });
};

GridApi.dispatchEvent() 함수를 사용하여 전달된 이벤트를 ga-grid 화면을 그리는 페이지에서 받기 위해서는 GridApi.addEventListener() 함수를 사용하여 리스트너를 등록해줘야 한다. @grid-ready="onGridReady" 구문을 사용해서 grid 가 준비됨을 알리는 이벤트가 발생하면 onGridReady 를 실행하고 해당 코드에서 리스트너를 등록했다.

const onGridReady = (params: any) => {
    gridApi.value = params.api; 
    gridApi.value.addEventListener('actionCellRenderer:save', handleSave);
    gridApi.value.addEventListener('actionCellRenderer:delete', handleDelete);
};

아래는 관련된 소스이다.

참고자료

Vue Data Grid Quick Start

사용기 - VMware Fusion 기반 윈도우에서 디스크 공간 확장하기

2024-05-27T14:05:00.003+09:00

VMware Fusion 기반 가상 윈도우를 60GB 용량에 설치하여 사용 하고 있었다.

◼︎ 작업환경

Model : MacBook Pro (16-inch, 2019)
CPU : 2.3 GHz 8코어 Intel Core i9
GPU : AMD Radeon Pro 5500M 4 GB
MENORY : 16GB
DISK : 1TB SSD
OS : macOS Ventura 13.0.1

사용하다보니 얼마 전부터 용량이 부족하다는 메시지와 이로 기인한 가상머신이 먹통이 되는 현상이 빈번하게 발생하고 있었다.

가상 머신에 OS 재설치 또는 복제 등의 번거로움 없이 가장 쉽게 하는 방법은 디스크 파티션 관리자 소프트웨어를 사용하는 것이다.

여러 가지 프로그램들이 있겠지만 비상업적인 용도로 무료 사용이 가능한 Paragon Partition Manager 커뮤니티 에디션을 설치하여 쉽게 파티션을 조정 할 수 있다.

1) 가상머신의 하드디스크 크기는 먼저 가상머신을 종료하고 Settings > Hard Disk 메뉴에서 크기를 조정할 수 있다.

2) Paragon Partition Manager 커뮤니티 에디션을 가상 머신 윈도우에서 설치하고 resize 기능을 사용하여 디스크의 크기를 확장한다.