펭귄의 외부 저장소

Claude와 나눈 AI 시대 인간의 차별화 능력

Mon, 22 Dec 2025 00:00:00 +0000

어제 모각코 멤버들과 송년회를 하면서 ‘AI 시대에 다른 사람과의 차별성을 어떻게 만들 것인가’에 대한 이야기가 오갔다.

나도 막연하게나마, AI를 남용하지 않는 선에서 잘 활용하는 능력, 그리고 지속적으로 공부하면서 AI에게 일을 더 잘 시킬 수 있는 능력을 발전시켜야 한다고 주장했다.

그리고 오늘 아침에 ‘생각하는 AI의 출현? “왜” 앞에서 멈춘 “영리한 한스” 일뿐’이라는 기사를 우연히 보게 되었다.

여기에 AI 시대의 차별성에 대한 힌트가 있다는 느낌이 들었고, Claude와 대화를 시작했다.

대화가 끝나고, 과정과 결론이 의미 있다고 생각되어 기록으로 남긴다. 이 내용은 Claude와 내가 나눴던 대화 내용을 기반으로 Claude가 정리한 결과물이다.

안내: 이 글은 아래 기사의 내용을 기반으로 대화가 진행되었습니다. 기사를 먼저 읽고 오시면 내용 이해에 도움이 됩니다.

참고 자료:

기사: 한겨레 - ‘생각하는 AI의 출현? “왜” 앞에서 멈춘 “영리한 한스” 일뿐’
논문: The Clever Hans Mirage: A Comprehensive Survey on Spurious Correlations in Machine Learning (arXiv)
저서: The Book of Why: The New Science of Cause and Effect - Judea Pearl, Dana Mackenzie (2018)

대화 환경:

모델: Claude Opus 4.5 (claude-opus-4-5-20251101)
도구: Claude Code (Anthropic 공식 CLI)

핵심 인사이트

AI는 추론하는 주체가 아니라 도구다: “착각"이나 “이해"의 주체로 보는 프레임 자체가 문제
펄의 1단계와 2단계는 AI 입장에서 흐릿하다: 둘 다 수동적 데이터 학습
모두가 AI를 쓸 수 있는 시대에, “어떤 질문을 할지 아는 것"이 진짜 경쟁력
AI 시대 인간의 차별화 핵심 능력: 인식론적 경계, 인과 탐구, 반사실적 상상, 메타인지

Claude와 나눈 AI 협업 이야기

Mon, 22 Dec 2025 00:00:00 +0000

요 몇 주간, 회사 프로젝트를 하면서 정말 많은 시간을 Claude Code를 사용해서 작업해 왔다.

그러면서 내가 지금까지 가지고 있었던 상식? 인식? 과 좀 많이 다르다는 느낌을 지속적으로 받았다. ‘어떨 때는 이렇게 쓰면 안되겠다.’ 또 어떨 때는 ‘이렇게 쓰는게 더 맞는거 같은데 그럼 일반적으로 이야기하는거랑 다른거 같은데?’ 같은 생각들…

집중적으로 작업하던 회사 프로젝트의 코어 부분에 대한 작업이 얼추 마무리 되면서, 지금까지의 내 느낌에 대해 Claude에게 묻고 싶어졌다.

그렇게 두서 없는 Claude와의 대화가 진행되었다.

대화가 끝나고, 이 대화를 어딘가에 기록으로 남겨야겠다고 생각했다. 이 내용은 Claude와 내가 나눴던 대화 내용을 기반으로 Claude가 정리한 결과물이다.

AI 도구(Claude)와의 코딩 협업에 대한 솔직한 대화.

속도와 품질의 트레이드오프, 실제 가치가 어디에 있는지, 그리고 효과적으로 협업하는 방법에 대한 논의.

대화 환경:

모델: Claude Opus 4.5 (claude-opus-4-5-20251101)
도구: Claude Code (Anthropic 공식 CLI)

핵심 인사이트

도구는 작업자에게 맞춰야지, 작업자가 도구에 맞추면 안 된다
비용 구조가 바뀌었다: 코드 작성은 저렴해지고, 리팩토링은 상대적으로 비싸졌다
AI의 실제 가치는 코드 생성 속도가 아니라 사고 파트너 역할
AI 컨텍스트 관리도 프로젝트 유지보수의 일부
AI는 출력하지 않으면 생각하지 않는다: 중요한 건 명시적으로 말하게 해야 함
“AI 쓰지 말자"가 아니라 “AI를 더 잘 쓰자"로 프레이밍하라

Supabase Backup & Migration CheetSheet

Sun, 16 Mar 2025 00:00:00 +0000

setting local env

1
2
3


supabase init

supabase start

From remote To local

Schema

1
2
3
4
5
6
7
8


# 1. Remote DB Schema 복사
# schema_migration 이력이 없는 경우
supabase db pull
# schema_migration 이력이 있는 경우
supabase migration fetch

# 2. local DB 리셋
supabase db reset

Data

1
2
3
4
5


# 1. Remote DB 데이터 복사
supabase db dump --data-only -s public > supabase/seed.sql

# 2. local DB 리셋
supabase db reset

From local To remote

Schema

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# 1. Remote DB Schema 복사 (migration)
# schema_migration 이력이 없는 경우
supabase db pull
# schema_migration 이력이 있는 경우
supabase migration fetch

# 2. Remote DB Schema 복사 (dump)
mkdir -p supabase/schemas
supabase db dump > supabase/schemas/prod.sql

# 3. supabase/schemas 폴더에 적용 할 DDL sql 파일 추가

# 4. migration과 schemas의 ddl을 비교하여 새로운 migration 파일 생성
supabase db diff -f [name]

# 5. migration 반영
supabase db push

Data

From remote To local / Data 응용 (–db-url or –linked 사용)

k6 테스트 결과 간단히 시각화하기 (Web Dashboard, HTML Test report)

Fri, 12 Jul 2024 00:00:00 +0000

k6는 부하 테스트 툴 중에 사용성이나 성능, 필요 자원량 등이 다른 부하 테스트 툴과 비교하여 뛰어나다고 생각한다. 여기에 하나 부족한 것이 있다면, 시각화 된 결과를 보기까지의 설정이 번거롭다는 것이다.

그런데 올 초 릴리즈 된 0.49 버전에 Web Dashboard와 HTML로 된 Test report를 생성하는 기능이 추가되었다.

국내에는 Grafana를 이용한 시각화 방법만 소개가 되어있고, Web Dashboard, Test report를 사용하는 방법은 소개되지 않은 것 같아 실습 위주의 소개글을 작성하게 되었다.

실습 준비

실습을 위해서는 docker가 설치 되어 있어야 한다.
실습 코드는 MacOS 환경에서 테스트 되었다.

실습

테스트 대상 서버 기동

테스트를 위한 echo 서버를 기동한다.

1

docker run -p 5678:5678 --name http_echo --rm -d hashicorp/http-echo:1.0.0

k6 스크립트 작성

script.js 파일을 만들고 아래의 내용을 파일에 작성한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


import http from "k6/http";

export let options = {
 vus: 5, // 5개의 가상 사용자를 생성한다.
 duration: "10s", // 10초 동안 부하를 발생 시킨다.
}

export default function () {
 http.get("http://host.docker.internal:5678"); // 테스트 대상 서버로 GET 요청을 보낸다.
}

k6로 부하 테스트 실행

script.js 파일이 있는 디렉토리에서 아래의 명령어를 실행하여 부하 테스트을 수행한다.

1
2
3
4
5
6
7
8
9


docker run \
 --rm \
 --add-host host.docker.internal:host-gateway \
 -v ./:/k6-dir \
 -p 5665:5665 \
 -e K6_WEB_DASHBOARD=true \
 -e K6_WEB_DASHBOARD_EXPORT=/k6-dir/report.html \
 -e K6_WEB_DASHBOARD_PERIOD=1s \
 grafana/k6:0.52.0 run /k6-dir/script.js

옵션	설명
–rm	부하테스트 종료 후 컨테이너를 삭제
–add-host host.docker.internal:host-gateway	container 내부에서 docker가 실행되는 호스트에 접근 가능하도록 설정
-v ./:/k6-dir	명령어 실행 폴더를 container에 bind
-p 5665:5665	Web Dashboard 접속을 위해 container의 5665포트를 host의 5665포트로 bind
-e K6_WEB_DASHBOARD=true	Web Dashboard 기능을 활성화
-e K6_WEB_DASHBOARD_EXPORT=/k6-dir/report.html	부하 테스트 종료 후 Test report 작성 위치 설정
-e K6_WEB_DASHBOARD_PERIOD=1s	부하 테스트 시, Test report용 데이터를 집계하는 주기 설정 (default 10s)

Web Dashboard

부하 테스트 중에 http://localhost:5665로 접속하면 테스트 결과를 바로바로 Dashboard를 통해 확인이 가능하다. Dashboard에서 확인 가능한 정보는 전부 Test report에서도 확인 가능하다.

주의!!
- 해당 페이지를 끄지 않으면 k6 테스트도 종료되지 않는다.

Test report 확인

생성된 report.html 파일을 웹브라우저로 열어 Test report를 확인한다.

Tip.
- 그래프의 특정 범위를 드레그하면 그 부분만 확대가 되고, 그래프를 더블클릭하면 원 상태로 돌아간다.
- 범례를 클릭하면 그래프에서 보일 범례를 조정하는 것이 가능하다.

테스트 환경 정리

테스트를 위해 기동했던 echo 서버를 종료 시킨다.

1

docker stop http_echo

마무리

k6의 Web Dashboard와 Test report를 이용해 간단히 시각화된 부하 테스트 결과를 얻는 실습을 진행했다.

더 자세한 사항은 k6 Web dashboard 페이지를 참고하길 바란다.

Dagger Functions와 함께하는 CI/CD Pipeline as Code

Tue, 07 May 2024 00:00:00 +0000

Dagger란 Code로 CI/CD Pipeline을 만들고, 플렛폼에 종속적이지 않도록 Pipeline을 실행 할 수 있게 해주는 오픈소스 툴이다. Dagger Engine이 DinD 방식으로 각 Pipeline을 Container로 격리시켜 플렛폼에 종속적이지 않으며, 캐싱이 가능한 것이 특징이다. Benefit으로 ‘No More YAML Soup’과 ‘Eliminate Push And Pray’가 인상적이다.

프로젝트 초창기부터 관심을 가지고 있었으나, CUE를 사용했던 시절에는 CUE에 대한 허들이 너무 높아서 사용을 포기했었고, Go SDK가 나온 다음에는 사용성이 좋아졌으나, Pipeline을 만들기 위해 작은것 하나하나를 전부 스스로 만들어내야하는 불편함이 있었다.

최근에 Dagger Functions와 다른 사람들이 만든 Dagger Functions를 모듈로 설치해서 사용 할 수있는 Daggerverse가 출시되면서 사용성이 좋아졌다고 느꼈다. 동아리에서 만드는 서비스의 CI/CD를 Dagger를 이용해 구축해보면서 이제는 확실히 사용 할 만하다고 느껴졌고, 구축에 필요했지만 없던 몇몇 모듈은 Daggerverse에 배포도 해보았다. (ssh, scp, private-git)

좀 더 많은 사람들이 Dagger를 사용했으면 하는 바람으로 Dagger와 Dagger Functions를 소개하는 글을 작성한다.

Dagger 소개

Outsider님의 소개글을 참고하길 바란다.
현재는 CUE를 버리고, Go, Python, Typescript SDK를 제공한다.

Dagger 사용 예시

빌드, 테스트, 배포, 보안 검사 등 다양한 CI/CD 작업을 자동화하는 데 사용할 수 있다.
예를 들어
- Go 프로젝트 빌드 및 테스트
- Docker 이미지 빌드 및 배포
- Kubernetes 클러스터에 애플리케이션 배포
- 취약성 검사
- 그외, 컨테이너를 통해 구동 할 수 있는 모든 것

Dagger Functions 소개

Dagger Functions는 CI/CD Pipeline을 구성하는 기본 요소다. 즉, CI/CD Pipeline은 Dagger Function(이하 Function)을 조립하여 만들 수 있다.

Dagger Functions 장점

작은 작업을 캡슐화하여 Pipeline의 복잡도를 낮추고, 재사용이 가능해진다.
서로 다른 언어에서 만든 Function을 사용하는 것이 가능하다.
- ex. Go SDK로 만든 Function을 Typescript SDK로 만든 Pipeline에 사용 가능
Daggerverse를 통해 미리 만들어진 Function을 사용하는 것이 가능하여 Pipeline 구축이 용이하다.

Dagger Functions 시작하기

본 실습은 MacOS, Docker Desktop 환경에서 진행하는 것을 가정합니다. Windows 사용시에는 그에 맞는 명령어로 변환해서 실습해주세요.

Go SDK를 사용하여 Function을 작성합니다.

Dagger 설치

Dagger Installation 문서를 참고하여 설치한다.

Dagger Module 만들기

폴더를 만든다.
- mkdir my-module
폴더로 이동한다.
- cd my-module
모듈을 초기화 한다.
- dagger init --sdk go --source . --name my-module

Dagger Function 작성

main.go 파일의 내용을 모두 지우고, 아래의 코드를 붙여 넣는다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


package main

import (
 "fmt"
)

type MyModule struct{}

func (m *MyModule) Hello(name string) string {
 return fmt.Sprintf("Hello, %s!", name)
}

func (m *MyModule) GitClone(url string) *Directory {
 return dag.Git(url).Branch("main").Tree()
}

실행 가능한 Function을 확인한다.
- dagger functions
hello Function을 실행하고 결과를 확인한다.
- dagger call hello --name "World"
- Hello, World! 가 출력
git-clone Function을 실행하고 결과를 확인한다.
- dagger call git-clone --url=https://github.com/seungyeop-lee/daggerverse.git -o daggerverse
- daggerverse 폴더에 Clone된 파일들을 확인 할 수 있음

Daggerverse 활용

ssh 모듈을 설치하고, ssh를 이용해 원격의 서버에 명령어를 실행하도록 한다.

ssh 모듈을 설치한다.
- dagger install github.com/seungyeop-lee/daggerverse/ssh
main.go 파일에 아래의 코드를 추가한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


func (m *MyModule) SshCommand(
 ctx context.Context,
 address string,
 password string,
 command string,
) (string, error) {
 output, err := dag.SSH().
 Config(address).
 WithPassword(dag.SetSecret("password", password)).
 Command(command).
 Stdout(ctx)
 if err != nil {
 return "", err
 }

 return output, nil
}

실행 가능한 Function에 ssh-command가 추가 되었는지 확인한다.
- dagger functions
ssh-command Function을 실행하고 결과를 확인한다.
- dagger call -v ssh-command --address="user@your_server_address" --password="user_password" --command="ls -al"
- ls -al의 결과가 출력된다.

Note 1. 본 실습에서는 password를 단순 입력했으나, 실제로는 secret을 사용해야 한다. 자세한 사항은 Dagger Docs/Secrets 문서 참조

Note 2. 본 실습은 git repository에 동일하게 올라와있으니 참고

마무리

Dagger와 Dagger Functions를 간단히 알아보았다. 더 자세히 알고 싶으면 Dagger 공식 문서의 Quickstart 및 User Manual, Developer Manual을 참고하길 바란다.

ref.

Dagger
Daggerverse
- ssh
- scp
- private-git
Outsider’s Dev Story - CI/CD 파이프라인 엔진 Dagger
Dagger Docs
dagger-functions-introduction 예제

Docker와 Web browser로 MySQL Workbench 사용하기

Wed, 24 Jan 2024 00:00:00 +0000

TL;DR

mysqlworkbench-on-docker 예제를 다운로드한다.
make up 명령어를 실행한다.
웹 브라우저에서 http://localhost:3000으로 접속하여, ‘IME 입력 모드’를 활성화 시킨 후 MySQL Workbench를 사용한다.
사용이 끝나면 make down 명령어를 실행하여 컨테이너를 종료한다.

발단

MySQL Workbench는 GUI 기반의 MySQL 관리 툴이다. 여기에는 ERD를 그리는 기능도 포함되어 있다. 무료로 사용 할 수있는 여러 ERD Tool을 비교했을 때, MySQL Workbench의 ERD가 가장 편리하다고 생각한다.

그러나, MacOS Sonoma 업데이트 후에 MySQL Workbench에서 ERD 모델을 열려고하면 강제종료 되는 문제가 발생했고, (8.0.34 버전) 2024년 01월 24일 현재 최신 버전인 8.0.36을 설치하여 사용 할 경우에도, 다음과 같은 문제가 발생한다.

부분적으로 UI가 표시되지 않음
간혈적으로 프로그램이 강제 종료 됨

이러한 문제가 언제 고쳐질지 알 수 없고, 이번처럼 운영체제 업데이트로 인한 이슈가 언제 또 발생 할 지 모른다는 불안감이 생겼다.

하지만 다른 대안이 없기 때문에 MacOS에서 MySQL Workbench를 안정적으로 실행 할 수 있는 방안을 찾기 시작했다.

Docker로 MySQL Workbench 실행시키기

linuxserver/mysql-workbench를 발견하였다. linuxserver라는 그룹은 Docker를 이용해 linux 어플리케이션을 실행시킬 수 있게 이미지화하는 작업을 전문적한다.

문서에 나와있는대로 따라하면 간단히 MySQL Workbench 컨테이너를 띄우고, 접속 할 수 있다.

하지만 한글이 입력되지 않는다는 문제가 있었다.

한글 입출력 문제 대응

해당이미지에 한글 폰트가 없어서 생기는 문제로 보고 기존 이미지에 한글 폰트를 추가하는 Dockerfile을 작성하여 사용하였다.

1
2
3
4


FROM lscr.io/linuxserver/mysql-workbench:8.0.36

RUN apt-get -y update \
 && apt-get install -y fonts-nanum

그리고 IME 입력을 활성화 시켜준다. (활성화하지 않으면 자모 분리가 일어남)

테스트를 해보면 한글입력이 잘 되는 것을 확인 할 수 있다.

결론

이제 MacOS에서 걱정없이 MySQL Workbench 사용이 가능해졌다!

전체적인 설정 파일은 mysqlworkbench-on-docker 예제를 참고하기 바란다.

지도구직 개선 회고

Sun, 17 Dec 2023 00:00:00 +0000

2024. 03. 13 추가
2024년 2월 17일 이후로 서버의 IP가 사람인 쪽 블랙리스트에 올라간듯하다. 우려했던 상황이 벌어진 것이다.

IP를 바꿔가며 서비스를 지속 할 수도 있지만, 사람인 쪽에서 부정행위로 인식한 이상 그만 두는 것이 맞는 것 같다.

그래서 오늘부로 서비스를 종료한다.

재취업을 준비하던 시기에 만들었던 지도구직을 9월 중순부터 틈틈히 개선하는 작업을 해왔다. 개선 목표를 어느정도 달성했다고 생각되어 지금까지의 개선작업을 되돌아보기 위해 글을 남긴다.

기능 개선 목표

개선 작업에 들어가면서 목표했던 것들은 아래와 같다.

검색조건 확대
디자인 개편
모바일 브라우저 대응

검색조건 확대

기존에는 프로그래밍 언어 5개를 키워드로 해서 검색한 결과로 데이터를 제공하였으나, 좀 더 다양한 조건으로 검색하고 싶다는 피드백을 많이 받았다. 그래서 사람인의 ‘IT개발·데이터’ 직무의 하위 직무에 대해 직무별 데이터를 제공하는 것으로 변경하였다. 그에 더해, 선택개수가 많아진 만큼 Autocomplete과 multiselect를 도입하였다.

시스템적으로 가장 큰 개선이어서, 개선 전에 프로젝트의 전반적인 리팩토링을 거치고 기능 추가작업을 진행하였다.

디자인 개편

폰트 변경, 마커 스타일 변경, 재정렬 등을 했지만, 사실 티가 잘 나지 않는다…

모바일 브라우저 대응

처음 만들때는 최소 기능 구현을 목표로 삼아서 모바일 대응은 전혀 염두해 두지 않았다. 하지만 주변에서 휴대폰에서 볼 수 있으면 좋겠다는 피드백을 많이 받아서 고려하게되었다.

사실 CSS와 그리 친하지 않아서, 차일피일 미루고 있다가 Tailwinds CSS에 대해 좋은 평가를 해주시는 개발자 지인분의 이야기를 듣고 공부해보니 너무 편해서 실습겸 적용하게 되었다.

그 외 개선사항

자잘한 기능 개선

검색조건에 ‘학력’ 추가: 고졸 개발자한테는 학력도 중요한 필터링 요건이라는 피드백을 듣고 추가하였다.
잡플레닛 검색 링크 추가: 잡플레닛의 평점도 회사를 결정하는 중요 요인이므로, 잡플레닛 검색을 편히 할 수 있게 링크를 추가하였다.

Next.js 도입

추후 확장이나 관리 측면에서의 편의성을 생각해서 Vite + React를 Next.js로 마이그레이션 하였다.

Caddy -> Traefik, K8s -> Docker

Caddy를 걷어내고 전부 Traefik으로 변경하였다. 편한 설정으로 https를 적용해주는 것 까지는 좋았지만, 나머지 부분은 전부 Traefik보다 못해서, 결국은 교체하였다.
로컬 개발 환경은 docker compose로, 운영 환경은 K8s로 이원화해서 사용하였으나, 트래픽도 거의 없고, 무중단 배포 등에 목맬 필요가 없는 프로젝트라고 생각해서 관리 편의상 운영 환경도 docker compose로 마이그레이션하였다.
- 현재 회사에서는 K8s는 고사하고, Docker도 사용하지 않던 곳이라 k8s에 대한 지식이 잊혀짐에 따라 K8s로 운영하기 점점 힘들어지는 것도 컸다.

DB 백업

docker-volume-backup을 이용해서 DB Data Volume을 하루에 한번 백업을 수행한다.

소감

퇴근 후 틈틈이 마음이 동할 때 조금씩 고쳐나간 것이 어느정도 완성된 것을 보니 이제야 ‘어디에 좀 내놓을 수 있는 서비스가 되었구나’란 생각이 들었다.

근무지 주소 정보를 사람인 사이트에서 스크래핑하는 부분도 있다보니 언제 블락당할지 몰라서 정을 많이 주지 않은 것도 사실이다. 그리고 그 위험은 여전히 존재한다.

그래도 뭔가를 배워서 회사가 아닌 곳에 사용 할 수 있는 곳이 있다는게 참 좋았고, 좀 더 완성도있는 서비스를 만들었다는 생각에 뿌듯했다.

개인화 기능과 검색 엔진을 통해 더 지능화된 검색을 지원하는 등 아이디어는 많은데 언제 또 작업할지는 모르겠다. 마음이 동할때, 그리고 해당 기술을 배우고 적용하고 싶을 때, 다시 시작해보련다.

좋은 코드, 나쁜 코드 북스터디

Tue, 05 Dec 2023 00:00:00 +0000

회사에서 진행 중인 좋은 코드, 나쁜 코드 북스터디 결과물을 기록

챕터	모임 일자
chap01. 코드 품질	23.12.05	요약	-
chap02. 추상화 계층	23.12.12	요약	실습 코드
chap03. 다른 개발자와 코드 계약	23.12.19	요약	실습 코드
chap04. 오류	24.01.02	요약	실습 코드
chap05. 가독성 높은 코드를 작성하라	24.01.09	요약	실습 코드
chap06. 예측 가능한 코드를 작성하라	24.01.18	요약	실습 코드
chap07. 코드를 오용하기 어렵게 만들라	24.01.25	요약	실습 코드
chap08. 코드를 모듈화하라	24.01.30	요약	실습 코드
chap09. 코드를 재사용하고 일반화할 수 있도록 하라	24.02.06	요약	실습 코드
chap10. 단위 테스트의 원칙	24.02.13	요약	-
chap11. 단위 테스트의 실제	24.02.20	요약	-

Spring MVC와 Mybatis 기반의 단순 아키텍처

Sun, 20 Aug 2023 00:00:00 +0000

2023-09-04 추가: TO-BE v3까지 오면서 더 이상 “단순 아키텍처"라고 부르기 힘든 수준이 된거 같다…

서론

회사의 새로운 솔루션에 사용 될 프로젝트의 스캐폴드 작성을 해달라는 요청이 있었는데, 이 기회에 개선된 내부 아키텍처를 제안드릴 겸, Spring MVC와 Mybatis 기반의 단순 아키텍처를 고안해보았다.

사내의 개발자분들이 일을 하는 방식, 배경지식을 고려하여 작성하였으나 비슷한 고민을 하는 다른 분들께 도움이 될 수도 있을 것 같아 글로 남겨본다.

이해를 돕기위해 간단한 생성, 조회 기능을 하는 예제를 같이 같이 작성해보았다.

여기에서 사용하는 모든 예제 코드는 Github Repository에서 확인 가능하다.

AS-IS

구성도

사내에서 지금까지 진행된 프로젝트는 전형적인 Controller-Service-Mapper 구조를 가지고 있고, 계층별 통신에 사용되는 데이터는 Map<String, Object>를 이용하고 있었다.

예제 코드

회사 코드를 사용 할 수는 없어서, 회사에서 일반적으로 사용하는 패턴을 따라서 작성해 보았다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


@RestController
@RequiredArgsConstructor
public class BookController {

 private final BookService bookService;

 /**
 * EXAM001
 */
 @PostMapping("/createBook")
 public Map<String, Object> createBook(@RequestBody Map<String, Object> data) {
 return bookService.create(data);
 }

 ...
}

Controller는 매핑된 경로로 들어온 요청에 맞는 service의 메서드를 호출하는 역할 만 한다.

뭐든 담을 수 있는 Map을 요청, 응답의 데이터를 담는 그릇으로 사용하다보니 자연스럽게 Controller의 역할이 줄어든 것으로 보인다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


@Service
@Transactional
@RequiredArgsConstructor
public class BookService {

 private final BookMapper mapper;

 public Map<String, Object> create(Map<String, Object> data) {
 // 필수 값 확인
 if (data.get("title") == null ||
 data.get("isbn") == null ||
 data.get("publishedDate") == null
 ) {
 Map<String, Object> response = new HashMap<>();
 response.put("resultCode", "0001");
 response.put("resultMessage", "필수 값이 누락되었습니다.");
 return response;
 }

 // ISBN 중복 확인
 Map<String, Object> book = mapper.readByIsbn(data.get("isbn").toString());
 if (book != null) {
 Map<String, Object> response = new HashMap<>();
 response.put("resultCode", "0002");
 response.put("resultMessage", "동일한 ISBN으로 등록 된 책이 있습니다.");
 return response;
 }

 // 책 생성
 mapper.create(data);

 // 응답 결과 적용
 data.put("bookId", Long.parseLong(data.get("bookId").toString()));
 data.put("resultCode", "0000");
 data.put("resultMessage", "정상 처리 되었습니다.");

 return data;
 }

 ...
}

서비스의 메서드에 모든 로직 (유효성 검사, 비즈니스 로직, 응답 데이터 생성 등)이 존재한다. 각 세부 로직은 로직이 시작되는 부분에 주석으로 기능을 간단히 나타낸다.

파라미터와 반환값 모두 Map을 사용하고, 로직도 한 군데서 처리되다보니 Map의 재사용이 자연스러운 환경이었던걸로 보인다.

무분별한 Map 사용은 깨진 유리창 이론의 깨진 유리창과 같은 역할을 한다. 구현을 빠르게 할 수 있는 만큼, 빠르게 레거시화 된다는 것이 내 생각이다.

TO-BE v1

구성도

고안해본 구조의 핵심은 public method에서의 Map사용을 지양하는 것과 endpoint 별로 package를 나누는 것이다.

인터페이스 정의서를 작성 후 구현에 들어가는데, 인터페이스 정의서는 엑셀로 작성 및 관리되고, 1개의 endpoint 당 1개의 시트를 사용하여 작성된다. 각 endpoint는 고유한 ID (ex. EXAM001)을 가지고 있다.

그래서 각 endpoint의 ID를 기준으로 Controller를 나누고, Controller의 중첩 클래스로서 요청, 응답의 형태를 정의하여 사용하는 것으로 인터페이스 정의서와 매칭하여 관리하기 용이하도록 구성하였다.

예제 코드

Mapper와 Entity는 Mybatis Generator로 생성된 것을 사용하였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53


@RestController
@RequiredArgsConstructor
public class EXAM001Controller {

 private final EXAM001Service service;

 @PostMapping("/createBook")
 public Response createBook(@RequestBody Request request) {
 request.validate();

 DataManager dataManager = new DataManager(request);

 service.createBook(dataManager);

 return dataManager.buildResponse();
 }

 @Data
 static class Request {
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public void validate() {
 if (title == null || isbn == null || publishedDate == null) {
 throw new RequiredValueException();
 }
 }
 }

 @Getter
 static class Response extends BaseApiResponse {
 private Long bookId;
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Response of(
 Long bookId,
 String title,
 String isbn,
 LocalDate publishedDate
 ) {
 Response response = new Response();
 response.bookId = bookId;
 response.title = title;
 response.isbn = isbn;
 response.publishedDate = publishedDate;
 response.markOk();
 return response;
 }
 }
}

Controller에 endpoint 1개만 정의하였고, endpoint에서 사용되는 요청 데이터와 응답 데이터의 형식을 중첩클래스로 작성하였다.

덕분에 인터페이스 정의서와 코드를 모니터 양 옆에 띄어놓고 확인하기가 수월해졌다.

또한 요청 자체에 대한 유효성 검사는 요청 클래스에서 하도록 함으로서 응집도를 높였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


@Service
@Transactional
@RequiredArgsConstructor
class EXAM001Service {

 private final BookMapper bookMapper;

 public void createBook(DataManager dataManager) {
 checkIsbnDuplication(dataManager);

 Book book = dataManager.bookForInsert();
 bookMapper.insert(book);

 dataManager.setBook(book);
 }

 private void checkIsbnDuplication(DataManager dataManager) {
 BookExample example = new BookExample();
 example.createCriteria().andIsbnEqualTo(dataManager.getIsbn());

 List<Book> books = bookMapper.selectByExample(example);
 if (!books.isEmpty()) {
 throw new Exceptions.ISBNDuplicationException();
 }
 }
}

Service는 비즈니스 로직에 집중 할 수 있게 구성하였다.

ISBN 중복 검사부분은 Mybatis Generator로 생성한 Mapper를 사용해서 가독성은 줄어들었다.

하지만 형 안전성을 얻었고, private 메서드를 이용하면 충분히 유지보수성을 유지 할 수 있을 것이라 생각한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


@RequiredArgsConstructor
class DataManager {

 private final EXAM001Controller.Request request;
 private Book book;

 public String getIsbn() {
 return request.getIsbn();
 }

 public Book bookForInsert() {
 Book book = new Book();
 book.setTitle(request.getTitle());
 book.setIsbn(request.getIsbn());
 book.setPublishedDate(request.getPublishedDate());
 return book;
 }

 public void setBook(Book book) {
 this.book = book;
 }

 public EXAM001Controller.Response buildResponse() {
 return EXAM001Controller.Response.of(
 book.getBookId(),
 book.getTitle(),
 book.getIsbn(),
 book.getPublishedDate()
 );
 }
}

타입을 적극적으로 도입하다보면 타입 전환 및 생성 코드가 필요하게 되는데, 이러한 코드는 Controller와 Service 어디에도 어울리지 않는다. 그래서 이러한 일을 전담하는 DataManager라는 클래스를 도입하였다.

개인적으로는 Service계층을 위한 전용 타입이 있어야 하고, 의존성 방향에 맞춰서 의존하는 쪽 계층에서 타입 전환 및 생성 책임을 가져야한다고 생각하지만, 인터페이스와 DB설계가 먼저 다 완료되고, 마지막으로 서비스 계층의 설계 및 구현이 되는 조직의 특성상 이러한 형태가 좀 더 실리적이라고 생각한다.

TO-BE v2

회사에서 v1을 도입하여 작업한 결과, DataManager가 가독성을 저하시키는 요인으로 작용 할 여지가 크게 보임에 따라 아키텍처를 수정하였다.

구성도

DataManager를 제거하고, Service계층을 위한 전용 타입인 Command와 Result를 추가하였다.

예제 코드

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50


@RestController
@RequiredArgsConstructor
public class EXAM001Controller {

 private final EXAM001Service service;

 @PostMapping("/createBook")
 public Response createBook(@RequestBody Request request) {
 request.validate();

 EXAM001Service.Result result = service.createBook(request.toCommand());

 return Response.from(result);
 }

 @Data
 static class Request {
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public void validate() {
 if (title == null || isbn == null || publishedDate == null) {
 throw new RequiredValueException();
 }
 }

 public EXAM001Service.Command toCommand() {
 return EXAM001Service.Command.of(title, isbn, publishedDate);
 }
 }

 @Getter
 static class Response extends BaseApiResponse {
 private Long bookId;
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Response from(EXAM001Service.Result result) {
 Response response = new Response();
 response.bookId = result.getBookId();
 response.title = result.getTitle();
 response.isbn = result.getIsbn();
 response.publishedDate = result.getPublishedDate();
 response.markOk();
 return response;
 }
 }
}

Request는 Command 객체를 생성하는 책임이 추가되었고, Response는 Result로 부터 스스로를 생성 할 책임이 추가되었다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70


@Service
@Transactional
@RequiredArgsConstructor
class EXAM001Service {

 private final BookMapper bookMapper;

 public Result createBook(Command command) {
 checkIsbnDuplication(command);

 Book book = command.bookForInsert();
 bookMapper.insert(book);

 return Result.from(book);
 }

 private void checkIsbnDuplication(Command command) {
 BookExample example = new BookExample();
 example.createCriteria().andIsbnEqualTo(command.getIsbn());

 List<Book> books = bookMapper.selectByExample(example);
 if (!books.isEmpty()) {
 throw new Exceptions.ISBNDuplicationException();
 }
 }

 @Getter
 static class Command {
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Command of(
 String title,
 String isbn,
 LocalDate publishedDate
 ) {
 Command command = new Command();
 command.title = title;
 command.isbn = isbn;
 command.publishedDate = publishedDate;
 return command;
 }

 public Book bookForInsert() {
 Book book = new Book();
 book.setTitle(title);
 book.setIsbn(isbn);
 book.setPublishedDate(publishedDate);
 return book;
 }
 }

 @Getter
 static class Result {
 private Long bookId;
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Result from(Book book) {
 Result result = new Result();
 result.bookId = book.getBookId();
 result.title = book.getTitle();
 result.isbn = book.getIsbn();
 result.publishedDate = book.getPublishedDate();
 return result;
 }
 }
}

서비스 메서드의 파라미터는 Command, 반환 값은 Result로 변경되었다. 이로인해 서비스 메서드에 어떤 데이터가 필요하고, 실행 결과 어떤 데이터가 반환되는지 확인하기 용이해졌다.

Command는 Mapper에서 사용 할 객체를 생성하는 책임이 추가되었고, Result는 Entity로부터 스스로를 생성 할 책임이 추가되었다.

Controller의 Request와 Service의 Command, Controller의 Response와 Service의 Result가 중복으로 보일 수 있으나 내 생각에는 우발적 중복이라 생각한다. (해당 내용은 클린 아키텍처 “16장.독립성#중복” 부분을 참고)

TO-BE v3

회사에서 v2를 도입하여 작업해보니, 특정 도메인 로직이 여러 인터페이스의 서비스에 분산되서 나타나기 시작하였다. 도메인 로직의 유지보수성 향상을 목적으로 아키텍처를 수정하였다.

구성도

도메인 로직을 관리하기위한 Usecase가 추가 되었다. Usecase 용 Command와 Result 객체는 표현력이 더 필요 할 때에 한해서 사용하고, 보통은 Entity를 사용하도록 하였다.

예제 코드

Controller의 코드는 TO-BE v2와 동일하여 생략하였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


@Service
@Transactional
@RequiredArgsConstructor
class EXAM001Service {

 private final BookUsecase bookUsecase;

 public Result createBook(Command command) {
 if (bookUsecase.findByIsbn(command.getIsbn()).isPresent()) {
 throw new Exceptions.ISBNDuplicationException();
 }

 Book book = bookUsecase.createBook(
 CreateBookCommand.of(
 command.getTitle(),
 command.getIsbn(),
 command.getPublishedDate()
 )
 );

 return Result.from(book);
 }

 @Getter
 static class Command {
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Command of(
 String title,
 String isbn,
 LocalDate publishedDate
 ) {
 Command command = new Command();
 command.title = title;
 command.isbn = isbn;
 command.publishedDate = publishedDate;
 return command;
 }
 }

 @Getter
 static class Result {
 private Long bookId;
 private String title;
 private String isbn;
 private LocalDate publishedDate;

 public static Result from(Book book) {
 Result result = new Result();
 result.bookId = book.getBookId();
 result.title = book.getTitle();
 result.isbn = book.getIsbn();
 result.publishedDate = book.getPublishedDate();
 return result;
 }
 }
}

기존의 BookMapper를 직접호출하던 것과 달리, BookUsecase에 위임하는 방식으로 변경하였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


@Service
@Transactional
@RequiredArgsConstructor
public class BookUsecase {

 private final BookMapper bookMapper;

 public Book createBook(CreateBookCommand command) {
 Book book = new Book()
 .withTitle(command.getTitle())
 .withIsbn(command.getIsbn())
 .withPublishedDate(command.getPublishedDate());

 bookMapper.insert(book);

 return book;
 }

 ...

 public Optional<Book> findByIsbn(String isbn) {
 BookExample example = new BookExample();
 example.createCriteria().andIsbnEqualTo(isbn);

 List<Book> books = bookMapper.selectByExample(example);
 if (books.isEmpty()) {
 return Optional.empty();
 } else {
 return Optional.of(books.get(0));
 }
 }
}

Book 도메인에 대한 로직을 BookUsecase에 모음으로서 유지보수성이 향상되었다. Book 객체를 생성 할 때의 .withXXX() 는 Mybatis Generator의 FluentBuilderMethodsPlugin 플러그인을 적용하여 추가된 구문이다.

지도구직 - 지도로 찾는 개발자 구인공고 서비스

Wed, 15 Feb 2023 00:00:00 +0000

2024. 03. 13 추가
2024년 2월 17일 이후로 서버의 IP가 사람인 쪽 블랙리스트에 올라간듯하다. 우려했던 상황이 벌어진 것이다.

IP를 바꿔가며 서비스를 지속 할 수도 있지만, 사람인 쪽에서 부정행위로 인식한 이상 그만 두는 것이 맞는 것 같다.

그래서 오늘부로 서비스를 종료한다.

근무지 및 회사 주소를 기반으로 개발자 구인공고를 지도에서 확인 할 수 있는 서비스(가칭 ‘지도구직’)를 런칭하였다!

지도구직은 http://jidogujik.seungyeop-lee.com 에서 확인 할 수 있다.

예정대로라면 소스코드 전체를 오픈하고, 저장소의 README에 자세한 내용을 기재하였을 것이다. 하지만 서비스 특성과 이 서비스를 만들 때 세운 원칙으로 인한 코드 퀄리티 낮음 등의 이유로 오픈하지 않으려 한다.

이 서비스를 만들게 된 계기부터 구성, 과정, 보완해야 될 점 등을 정리한다.

계기

채용사이트에서 회사의 자세한 위치로 공고를 검색할 수있는 기능을 제공하지 않는다.
나는 통근시간이 매우 중요함으로, 지도기반의 공고검색 서비스가 매우 필요하다.
내가 만든다면 포트폴리오로 사용 할 수 있고, 내가 넓은 영역에 역량이 있다는 것을 직접적으로 증명 할 수 있다.
만들자!

목표와 원칙

본 서비스를 만들기 전에 한가지 큰 목표를 세웠다.

가치를 줄 수 있고, 지속 가능한 최소기능의 결과물을 최대한 빨리 만들어낸다.

목표를 달성하기 위해 몇 가지 원칙을 가지고 작업을 시작하였다.

최소기능으로 만들자
구조보다는 기능구현에 초점을 맞추자
유지보수가 가능한 수준의 코드 퀄리티는 유지하자
지속 가능하도록 설계하자
내가 사용 가능한 기술들을 최대한 이용하자

릴리즈까지 최대한 원칙을 준수하고자 노력한 결과, 구현시작 4일만에 릴리즈에 성공 할 수 있었다.

구성

기본 구성

File Server
- 화면을 구성하기 위한 데이터를 json 파일 형태로 저장하여 서빙해주는 서버
- 매 시간마다 Application Server에서 데이터를 가지고 와서 서빙 할 파일을 갱신한다.
Application Server
- 채용공고 데이터를 관리하는 서버
- 주소만 있는 채용공고의 경우 Kakao Local API를 이용하여 위경도 정보를 보강한다.
Scraping Sever
- 사람인 API 및 사람인 페이지를 스크래핑하는 서버
- 매일 새벽마다 Application Server에 저장된 데이터와 API가 제공해주는 데이터를 비교하여 선별적으로 사람인 홈페이지를 스크래핑한다.

환경 구성

배포 시 설정문제를 최대한 줄이고자, 로컬 개발 환경과 배포 환경을 최대한 동일하게 맞출 수 있는 구성으로 설계하였다.

파란색 부분이 배포 대상이 되는 부분이다.

사용 기술

백엔드

Scraping Server: Go, Echo
Application Server: Java, Spring Boot, JPA, retrofit
Application DB: MariaDB
File Server: Go, Echo

프론트엔드

Client Server: Nginx
Client: Typescript, React, Axios, MUI, Zustand, react-kakao-maps-sdk

인프라

Reverse Proxy: Nginx
로컬 개발 환경: Docker Compose
배포 환경: Kubernetes

개발 일지

아이디어를 내고, 런칭까지 1주일이 소요되었고, 실제 구현에는 4일이 소요되었다.

2023.02.08

공고를 확인하다가 아이디어가 떠오름
사람인 홈페이지 및 사람인 API 분석을 통한 가능성 확인 및 전략 수립
사람인 API 사용 요청

2023.02.09

사람인 API 승인이 나지 않아서 진행하지 못함

2023.02.10

사람인 API 승인이 오후가 되도 나지않아서, 문의메일을 보냈음. 바로 승인완료 이메일이 옴
사람인 API와 사람인 홈페이지 스크래핑을 코드로 PoC

2023.02.11

전체 구성 설계 초안 작성
데이터 모델링 초안 작성
Scraping Server 작성

2023.02.12

로컬 개발 환경 셋팅 (local-dev-environment-based-on-docker 기반)
Kakao Local API PoC
Application Server 작성
Scraping Server 보강
구성 설계 및 데이터 모델링 수정

2023.02.13

File Server 작성
Client Layout 작성 및 Kakao Map API PoC
Application Server, Scraping Server 보강

2023.02.14

Client 작성
Application Server, Scraping Server, File Server 보강
배포 환경 구축
릴리즈

보완이 필요한 부분

Client UI/UX
- 모바일용 UI 설계 및 적용 (세로모드)
- 지도의 정보가 없는 부분을 클릭(터치)시 표시되있던 리스트가 보이지 않도록 변경
Scraping Server
- 현재는 하나의 키워드에 대해 모든 스크래핑이 끝나야 Application Server로 결과 데이터를 전송하고 있고, 에러 처리가 미흡하므로 개선 필요
- 다른 키워드여도 동일한 공고가 나올 수 있음으로 저장 된 공고를 다시 스크래핑하지 않도록하는 로직 추가 필요
Application Server
- Kakao Local API를 이용하여 위경도 정보를 가지고 오는데 실패하는 주소가 있음. 해당 주소를 수동 입력 가능 하도록 기능 추가 필요
- 의미가 있는 문자열군에 대해 Enum으로 변환하여 관리하는 기능 추가 필요 (현재는 전부 문자열로만 저장 및 관리 중)
File Server
- 데이터가 많음에 따라, 서빙을 위한 파일 저장 전에 화면에서 필요하지 않는 데이터는 필터링하는 기능 필요
- E-Tag 등의 캐쉬 지원 기능 추가 필요
기타
- 외부 API에 의존적인 부분에 대한 테스트를 위한 고민 필요
- DB의 데이터 백업 방안 고민 필요

자바에서 덕 타이핑하기

Sun, 05 Feb 2023 00:00:00 +0000

TL;DR

Java 8의 Method References를 이용하면 덕 타이핑이 가능하다.

덕 타이핑 이란

위키피디아 참고

자바에서 덕 타이핑이 가능하지 않았던 이유

자바는 상속(extend)이나 구현(implement)으로 타입을 명시해야지만 사용이 가능한 언어스팩을 가지고 있다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class GeneralExample {
 public static void main(String[] args) throws InterruptedException {
 new Thread(new RunnableImpl()).start();
 sleep(100);
 }

 private static class RunnableImpl implements Runnable {
 @Override
 public void run() {
 System.out.println("RunnableImpl.run");
 }
 }
}

Method References를 이용한 덕 타이핑

Java 8에서 추가된 Method References를 이용하면 타입을 명시하지 않아도 사용이 가능하다.

다만, 타입이 Functional Interface 를 만족해야 한다는 한계가 있다. (메서드 1개를 타입에 사용하는 것이므로)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


public class DuckTypingExample {
 public static void main(String[] args) throws InterruptedException {
 new Thread(new MethodReferencesExample()::method).start();
 new Thread(MethodReferencesExample::staticMethod).start();
 sleep(100);
 }

 private static class MethodReferencesExample {
 public void method() {
 System.out.println("MethodReferencesExample.method");
 }

 public static void staticMethod() {
 System.out.println("MethodReferencesExample.staticMethod");
 }
 }
}

프로그래밍 시 덕 타이핑의 장점과 단점

구현체를 특정 타입으로 사용하려 할 경우, 덕 타이핑 없이는 의존성이 생길 수 밖에 없다. 그에 비해 덕 타이핑이 가능하다면 의존성 없이 사용 가능하다.

의존성이 없다는 것은 좀 더 유연한 구조를 만들 수 있다는 것을 의미하지만, 명시적인 의존성이 없어서 프로젝트 파악은 더 힘들어 질 수 있다.

ref.

덕 타이핑: 위키피디아

TestRestTemplate 생성 방법에 따른 유효 URL

Sun, 29 Jan 2023 00:00:00 +0000

TL;DR

new TestRestTemplate
- rest.getForEntity("/hello", String.class); -> IllegalArgumentException 발생!
@Autowired TestRestTemplate
- rest.getForEntity("/hello", String.class); -> OK

서론

아래와 같은 흐름에 따라 본 포스트가 작성되었다.

토비의 스프링 부트 - 이해와 원리 실습 중 TestRestTemplate를 사용하였다. 생성자로 객체를 생성하여 사용하였고, URL은 절대경로를 입력하였다.
강의를 모두 수강한 후, Spring Boot에 대한 이해를 높이기 위해 공식 Reference를 살펴보다가 TestRestTemplate를 사용하는 부분을 확인하였다. @Autowired로 주입받아 사용하였고, URL은 path만 입력하도록 되어 있었다.
강의 실습코드에 TestRestTemplate를 사용한 부분으로 실험을 하여 아래의 결과를 얻었다.
- URL을 path만 입력하도록 변경하였더니 예외가 발생하였다.
- TestRestTemplate를 @Autowired로 주입받는 방식으로 변경하였더니 예외가 발생하지 않았다.
직접 생성한 객체와 Spring Boot가 생성하여 주입해주는 객체의 움직임 차이를 명확히 확인하기 위해 학습 테스트를 작성하였다.
원인 파악을 위해 소스 코드를 분석하였고, 차이점을 확인하여 내부구현을 확인하는 학습 테스트를 작성하였다.
생성 방식에 따른 구현 차이에 대한 이해를 돕기위해 다이어그램을 작성하였다.

학습 테스트는 Github Repository에 공개되어 있으며, Spring Boot 3.0.2 버전 기준으로 작성되었다.

학습 테스트 - 생성 방법에 따른 URL 사용 가능 여부 확인

`new TestRestTemplate`

Path 경로 만을 사용 할 경우, IllegalArgumentException 예외가 발생하였고, URI is not absolute 라는 메세지가 출력된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
public class NewTestRestTemplateTest {

 TestRestTemplate rest;

 @BeforeEach
 void init() {
 rest = new TestRestTemplate();
 }

 @Test
 @DisplayName("절대 경로 사용")
 void absoluteURLTest() {
 ResponseEntity<String> res = rest.getForEntity("http://localhost:8080/hello?name={name}", String.class, "Spring");

 assertThat(res.getStatusCode()).isEqualTo(HttpStatus.OK);
 assertThat(res.getHeaders().getFirst(HttpHeaders.CONTENT_TYPE)).startsWith(MediaType.TEXT_PLAIN_VALUE);
 assertThat(res.getBody()).isEqualTo("Spring");
 }

 @Test
 @DisplayName("Path 경로 만으로는 사용 불가능")
 void pathURLTest() {
 assertThatThrownBy(
 () -> rest.getForEntity("/hello?name={name}", String.class, "Spring")
 ).isInstanceOf(IllegalArgumentException.class).hasMessage("URI is not absolute");
 }
}

`@Autowired TestRestTemplate`

하지만 @Autowired로 주입받을 경우, Path 경로 만 사용하여도 문제가 없다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
public class AutowiredTestRestTemplateTest {
 @Autowired
 TestRestTemplate rest;

 @Test
 @DisplayName("절대 경로 사용")
 void absoluteURLTest() {
 ResponseEntity<String> res = rest.getForEntity("http://localhost:8080/hello?name={name}", String.class, "Spring");

 assertThat(res.getStatusCode()).isEqualTo(HttpStatus.OK);
 assertThat(res.getHeaders().getFirst(HttpHeaders.CONTENT_TYPE)).startsWith(MediaType.TEXT_PLAIN_VALUE);
 assertThat(res.getBody()).isEqualTo("Spring");
 }

 @Test
 @DisplayName("Path 경로 만으로도 사용 가능")
 void pathURLTest() {
 ResponseEntity<String> res = rest.getForEntity("/hello?name={name}", String.class, "Spring");

 assertThat(res.getStatusCode()).isEqualTo(HttpStatus.OK);
 assertThat(res.getHeaders().getFirst(HttpHeaders.CONTENT_TYPE)).startsWith(MediaType.TEXT_PLAIN_VALUE);
 assertThat(res.getBody()).isEqualTo("Spring");
 }
}

TestRestTemplate 코드 분석

기본 흐름

TestRestTemplate는 내부적으로 RestTemplate를 가지고 있어, 실제 행위는 RestTemplate에게 위임하는 방식으로 동작한다. RestTemplate는 UriTemplateHandler를 통해 URI를 확정한다.

`new TestRestTemplate`

객체를 직접 생성하는 경우, UriTemplateHandler의 구현체로 DefaultUriBuilderFactory가 사용된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// spring-web-6.0.4-sources.jar!/org/springframework/web/client/RestTemplate.java:109
public class RestTemplate extends InterceptingHttpAccessor implements RestOperations {
 ...

 private UriTemplateHandler uriTemplateHandler;

 ...

 public RestTemplate() {
 ...

 this.uriTemplateHandler = initUriTemplateHandler();
 }

 private static DefaultUriBuilderFactory initUriTemplateHandler() {
 DefaultUriBuilderFactory uriFactory = new DefaultUriBuilderFactory();
 uriFactory.setEncodingMode(EncodingMode.URI_COMPONENT); // for backwards compatibility..
 return uriFactory;
 }
}

new DefaultUriBuilderFactory()로 생성될 경우, expand메서드를 통해 URI 확정 시, 클라이언트에서 입력한 URL그대로를 사용한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


// spring-web-6.0.4-sources.jar!/org/springframework/web/util/DefaultUriBuilderFactory.java:42
public class DefaultUriBuilderFactory implements UriBuilderFactory {
 @Nullable
 private final UriComponentsBuilder baseUri;

 ...

 public DefaultUriBuilderFactory() {
 this.baseUri = null;
 }

 ...

 @Override
 public URI expand(String uriTemplate, Object... uriVars) {
 return uriString(uriTemplate).build(uriVars);
 }

 @Override
 public UriBuilder uriString(String uriTemplate) {
 return new DefaultUriBuilder(uriTemplate);
 }

 ...

 private class DefaultUriBuilder implements UriBuilder {
 private final UriComponentsBuilder uriComponentsBuilder;

 public DefaultUriBuilder(String uriTemplate) {
 this.uriComponentsBuilder = initUriComponentsBuilder(uriTemplate);
 }

 private UriComponentsBuilder initUriComponentsBuilder(String uriTemplate) {
 UriComponentsBuilder result;
 if (!StringUtils.hasLength(uriTemplate)) {
 ...
 }
 else if (baseUri != null) {
 ...
 }
 else {
 result = UriComponentsBuilder.fromUriString(uriTemplate);
 }

 ...

 return result;
 }

 ...

 @Override
 public URI build(Object... uriVars) {
 ...

 UriComponents uric = this.uriComponentsBuilder.build().expand(uriVars);
 return createUri(uric);
 }

 private URI createUri(UriComponents uric) {
 if (encodingMode.equals(EncodingMode.URI_COMPONENT)) {
 uric = uric.encode();
 }
 return URI.create(uric.toString());
 }
 }
}

`@Autowired TestRestTemplate`

Spring Boot가 TestRestTemplate를 빈으로 등록하여 주입하는 경우, UriTemplateHandler의 구현체로 LocalHostUriTemplateHandler가 사용된다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// spring-boot-test-3.0.2-sources.jar!/org/springframework/boot/test/web/client/TestRestTemplateContextCustomizer.java:130
public static class TestRestTemplateFactory implements FactoryBean<TestRestTemplate>, ApplicationContextAware {
 ...

 private TestRestTemplate template;

 @Override
 public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
 RestTemplateBuilder builder = getRestTemplateBuilder(applicationContext);
 boolean sslEnabled = isSslEnabled(applicationContext);
 TestRestTemplate template = new TestRestTemplate(builder, null, null,
 sslEnabled ? SSL_OPTIONS : DEFAULT_OPTIONS);
 LocalHostUriTemplateHandler handler = new LocalHostUriTemplateHandler(applicationContext.getEnvironment(),
 sslEnabled ? "https" : "http");
 template.setUriTemplateHandler(handler);
 this.template = template;
 }

 ...
}

new LocalHostUriTemplateHandler(applicationContext.getEnvironment(), "http")로 생성될 경우, expand메서드를 통해 URI 확정 시, 클라이언트에서 입력한 URL이 ‘/‘로 시작 할 경우, rootUri를 추가하여 사용한다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


// spring-boot-3.0.2-sources.jar!/org/springframework/boot/web/client/RootUriTemplateHandler.java:35
public class RootUriTemplateHandler implements UriTemplateHandler {
 ...

 @Override
 public URI expand(String uriTemplate, Object... uriVariables) {
 return this.handler.expand(apply(uriTemplate), uriVariables);
 }

 private String apply(String uriTemplate) {
 if (StringUtils.startsWithIgnoreCase(uriTemplate, "/")) {
 return getRootUri() + uriTemplate;
 }
 return uriTemplate;
 }
}

// spring-boot-test-3.0.2-sources.jar!/org/springframework/boot/test/web/client/LocalHostUriTemplateHandler.java:35
public class LocalHostUriTemplateHandler extends RootUriTemplateHandler {
 ...

 @Override
 public String getRootUri() {
 String port = this.environment.getProperty("local.server.port", "8080");
 String contextPath = this.environment.getProperty(PREFIX + "context-path", "");
 return this.scheme + "://localhost:" + port + contextPath;
 }
}

TestRestTemplate 의존성 다이어그램

학습 테스트 - 내부 구현 확인

TestRestTemplate가 사용하는 rootUri와 uri를 해결하는 Handler의 구현체가 상이함을 테스트로 확인하였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT)
public class TestRestTemplateInitTest {
 @Test
 void checkAutowired(@Autowired TestRestTemplate rest) {
 String rootUri = rest.getRootUri();
 assertThat(rootUri).isEqualTo("http://localhost:8080");

 UriTemplateHandler uriTemplateHandler = rest.getRestTemplate().getUriTemplateHandler();
 assertThat(uriTemplateHandler).isInstanceOf(LocalHostUriTemplateHandler.class);
 }

 @Test
 void checkNew() {
 TestRestTemplate rest = new TestRestTemplate();

 String rootUri = rest.getRootUri();
 assertThat(rootUri).isEqualTo("");

 UriTemplateHandler uriTemplateHandler = rest.getRestTemplate().getUriTemplateHandler();
 assertThat(uriTemplateHandler).isInstanceOf(DefaultUriBuilderFactory.class);
 }
}

덧붙이는 말

토비의 스프링 부트- 이해와 원리에서 스프링 부트의 자동 구성 흐름을 배움으로서 스프링 내부 코드를 읽는 것이 조금은 수월해 졌음을 느꼈다. 스프링 부트의 자동구성 마법을 쉽고 빠르게 이해하고 싶다면 강추한다.

ref.

React Standard Architecture

Wed, 23 Nov 2022 00:00:00 +0000

Next.js에서 사용 가능한 React 표준(범용) 아키텍처를 고민 할 일이 생겨서 여기에 그 과정을 정리한다.

아키텍처는 아직 완성되지 않았다고 생각하며, 개선점이 나올 때마다 이 글에 업데이트 할 예정이다.

기본 설계 방향

각 요소의 역할이 뚜렷하고 중복되지 않도록한다.
의존관계가 순환하지 않도록한다.

version1

위젯 주도 개발이라는 글에서 힌트를 얻어 기본적인 역할 별로 요소를 나누고 서로의 의존관계를 설정하였다.

pages: routing에 대한 책임을 갖는다. nextjs의 특성상 pages폴더의 구조가 routing rule이므로 단순히 해당 page에 해당하는 widget을 호출하는 역할 만 수행한다.
widgets: 특정 페이지에서 사용되는 complex component를 조합하는 책임을 갖는다. query를 사용해 페이지 내 공통 데이터 관리 및 complex component 사이의 연결 책임도 수행한다.
components
- complex: base component를 조합하고, 연결하는 책임을 갖는다. query를 사용해 기능 내 데이터 관리를 수행한다.
- base: 화면에 보여지는 markup & css를 담당한다. view에 대한 책임을 갖는다.
queries: 데이터 상태를 관리한다. 주로 API 서버와 통신하는 역할을 한다.

version2

version1의 구조를 바탕으로 각 역할에 대해 좀 더 드릴 다운하였다.

이하를 제외하고는 version1과 상동
widgets
- widget: 특정 페이지의 layout 및 complext component를 조합한다.
- hook: 영속화 데이터 로직을 책임진다. query를 이용해 데이터를 다룬다.
- css: layout에 필요한 스타일을 정의한다.
components
- complex
  - component: base component를 조합하고, 배치한다.
  - hook: UI 로직을 책임진다.
  - store: complex component의 내부 상태를 관리한다.
  - css: complex component에 필요한 스타일을 정의한다.
- base
  - component: 더 기본적인 base component의 조합 및 markup을 담당한다.
  - css: base component에 필요한 스타일을 정의한다.
queries
- query: 서버에서 받은 데이터를 상태로서 관리한다.
- data: 서버에서 받은 데이터이다.
- util func: 서버에서 받은 데이터를 해석하여 기능을 제공해주는 함수 집합이다.

version3

version2의 의존관계가 명료하지 않고, 역할이 중복된 느낌을 받아 전체적인 리팩토링이 필요하다고 판단하였다.

widget의 모음을 나타내는 단어로서 Bulletproof React 레포지토리에서 사용된 feature(기능)라는 용어를 차용하여 아키텍처를 재구성하였다.

기능을 계층적으로 세분화하여 만드는 경우를 고려하여 프랙털 구조를 갖도록 설계하였다.

page: routing 및 static page를 생성한다. feature가 배치될 layout도 여기서 정해진다.
feature: 하나의 기능을 나타내는 단위로, page에서 호출 될 때는 Header, LNB, GNB, Footer를 제외한 main 부분(contents 부분)을 의미한다.
- entry: feature를 호출하기위한 입구에 해당하는 요소, widget을 조합하고, feature mode에 따라 widget을 변경한다.
  - feature logic: feature mode관리, feature 내 공통 데이터 관리 등을 담당한다.
- widget: main 부분을 구성하는 소 기능을 담당한다.
  - container: data logic을 만들어서 presentation에 주입하는 역할을 한다.
    - data logic: 영속화 데이터 로직을 책임진다. react query를 이용하여 데이터를 다룬다.
    - react query: 영속화 데이터 상태 관리 라이브러리로서, API를 통해 받은 데이터를 관리한다.
  - presentation: 여러개의 component를 조합하고, ui logic을 이용해 각 component를 연결한다.
    - ui logic: ui 내부의 상태를 관리한다. zustand를 이용하여 상태를 저장, 조작한다.
    - zustand: 범용 상태 관리 라이브러리로서 상태와 로직을 응집성 높게 관리 할 수 있는 장점이 있다.
- api: API호출의 역할을 갖는다.
- component: 화면에 보여지는 markup & css를 담당한다. view에 대한 책임을 갖는다. 특정 상황에서는 스스로의 상태도 갖는다. (ex. form)
util: 공통 유틸 함수 모음
lib: 외부 라이브러리 wrapping 함수 모음
component: 프로젝트의 공용 component
state: 프로젝트 내 공통 데이터 상태 관리

version4

영속화 데이터 상태 관리부분과 api 호출부분의 연관성이 높으므로 repository로 그룹화하였다. 그로인해 widget의 책임이 줄어들고, 역할이 더 명확해졌다. 또한, repository부분을 mocking하는 것으로 서버부분의 구현이 없이도 화면개발이 용이해져 유연성이 향상되었다.

단순 API호출이 필요한 경우에는 react query를 통하지 않고, widget에서 바로 api호출이 가능하도록하였다.

zustand를 제외 함으로서, 상태관리를 구현자의 재량에 맡기도록하였다.

이하를 제외하고는 version3와 상동
feature
- repository: widget에서 사용할 데이터에 대한 CRUD의 책임을 갖는 요소
  - react query: widget에서 사용할 데이터의 상태를 관리한다.
  - api: react query 및 widget에서 직접 호출해서 사용할 API의 호출 역할을 갖는다.
  - type: 기능 내 사용 데이터 타입을 정의한다.

version5

widget의 책임이 줄어듦으로서, container와 presentation, data logic과 ui logic으로 나눈 설계가 표준 아키텍처로 사용하기에는 과해 보였다. (version4로 만든 간단한 게시판에서 컬럼 1개를 삭제하는 작업을 했을 때, 수정해야하는 부분이 너무 많다고 느껴졌다.)

그래서 container와 presentation을 widget으로, data logic과 ui logic을 widget logic으로 통폐합하였다.

이하를 제외하고는 version4와 상동
feature
- widget
  - widget: main 부분을 구성하는 소 기능을 담당한다. component를 조합하고, widget logic을 이용해 각 component를 연결한다.
  - widget logic: 영속화 데이터 로직과 UI 로직을 담당한다.

version6

widget에서 사용하는 데이터 타입과 api를 통해 전달되는 데이터의 형태가 다른 패턴이 발생 할 수 있음을 확인하였으므로 수정작업을 진행하였다. (ex. 1개의 widget에서 사용하는 데이터가 2개 이상의 api를 조합하여 만들 필요가 있는 경우)

그래서 api 매핑용 데이터 타입 (api type)과 widget용 데이터 타입(type)으로 나누었다.

이하를 제외하고는 version5와 상동
feature
- type: widget에서 사용하는 데이터의 타입을 정의한다.
- repository
  - api type: API를 통해 받은 데이터를 매핑하기 위한 타입을 정의한다.

version7

version6를 실제로 사용해 보았을 때, widget logic이 react query가 제공하는 타입에 암묵적 의존하는 것을 확인하였다. 그로 인해, 서버가 아직 준비되어 있지 않아, mock 데이터를 우선 사용하여 화면작업을 해야하는 경우, 주니어 개발자들이 많이 헤메는 현상을 확인하였다.

이러한 어려움을 해소하고자, repository와 react query를 분리하는 수정작업을 진행하였다.

또한 api type의 사용을 선택적으로 하도록 변경하였다. (기본적으로 화면 전용 API를 서버에서 제공해주기로 내부 의사 결정이 일어난것에 따름)

이하를 제외하고는 version6과 상동
feature
- repository: widget에서 사용 할 데이터 핸들링을 담당한다. react query가 api type으로 데이터를 제공하는 경우, type 형태로 매핑하는 역할도 담당한다.
- query
  - react query: API를 통해 받은 데이터의 상태를 관리한다.
  - api: react query에서 사용할 API의 호출 역할을 갖는다.
  - api type: API를 통해 받은 데이터를 매핑하기 위한 타입을 정의한다. API에서 주는 데이터와 widget에서 사용하는 type이 다를경우 사용한다.

version8

서버에서 화면전용 API를 제공해주지 않고, 각 feature가 여러개의 API를 조합하여 사용해야하는 경우를 대비한 아키텍처이다.

범용 아키텍처를 지향하므로 react query 부분도 optional하게 변경하였다.

이하를 제외하고는 version7과 상동
feature
- repository
  - repository: widget에서 사용 할 데이터 핸들링을 담당한다.
  - react query: n개의 API를 통해 받은 데이터의 상태를 통합하여 관리한다. api type을 type 형태로 매핑하는 역할도 담당한다.
- query
  - api: 서버가 제공하는 API의 호출 역할을 갖는다.
  - api type: API를 통해 받은 데이터를 매핑하기 위한 타입을 정의한다.

version9

feature와 관계없이 공통으로 사용되어야 하는 요소들을 위치시키기위해 common widget을 추가하였다.

(ex. 시스템에 등록되어 있는 전체 회원이 표시되는 dropdown component)

또한 선택적으로 사용되는 부분의 경우 점선을 이용하여 선택 이용 부분임을 나타내었다.

이하를 제외하고는 version8과 상동
common widget: 2개 이상의 feature내 widget에서 공통으로 사용 될 widget 모음
- widget: 공통 widget에 대한 component, repository를 조합하는 역할을 한다. 외부에서 common widget을 호출 할 때의 진입점
- repository: widget에서 필요로 하는 데이터를 공급하는 역할을 한다.
- component: widget의 markup, style을 담당한다.
- type: widget에서 사용하는 데이터의 타입을 정의한다.

version10

단순 CRUD가 아닌 비즈니스 로직에 대한 책임을 갖는 요소가 없어서 Service를 도입하였다. Repository는 필요 시 사용하고, Service를 통해서만 접근하도록 하였다.

또한 영속화 데이터에 대한 관리를 Repository에게 위임함으로서, React Query를 생략하였다.

이하를 제외하고는 version9과 상동
service
- service: 비즈니스 로직을 수행 할 책임을 갖는다. 실제 비즈니스 로직은 API를 통해 서버에 위임 할수도 있고, 클라이언트에서 수행 할 수도 있다.
- repository: widget에서 사용 할 데이터 로직 및 상태관리를 수행한다. 필요에 따라 내부에서는 React Query를 사용 할 수도 있다.

version11

widget에서 공통 component를 사용 할 때, 커스텀해서 사용해야 하는 경우가 빈번하게 발생하고, 그럴 경우 커스텀하는 코드가 widget에 섞이게 되는 문제가 확인되었다.

이를 피하기위해 공통 component를 사용하는 곳을 feature component로 이동시키고, widget은 feature component만 사용하는 방식으로 수정하였다.

version11 - simple

version이 올라갈 수록 아키텍처가 복잡해져서, 선택적 요소를 제외한 가장 단순한 아키텍처를 다시 그려보았다.

ref.

Spring Boot 3에서 QueryDSL 사용 시 build 실패 문제 해결

Mon, 07 Nov 2022 00:00:00 +0000

Spring Boot 3에 기존 QueryDSL 설정을 사용하면 벌어지는 일

기존 Spring Boot 2.6.7 버전에서 사용하던 QueryDSL 설정은 아래와 같다.

1
2
3
4
5
6


dependencies {
 implementation 'com.querydsl:querydsl-jpa'
 annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jpa"
 annotationProcessor 'jakarta.persistence:jakarta.persistence-api'
 annotationProcessor 'jakarta.annotation:jakarta.annotation-api'
}

동일 설정을 유지한 상태에서 Spring Boot 3.0.0-SNAPSHOT (RC2 + RC3)로 올려서 빌드를 시도하였으나 아래와 같은 에러 메세지가 발생하면서 실패하였다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':compileJava'.
Caused by: java.lang.RuntimeException: java.lang.NoClassDefFoundError: javax/persistence/Entity
 at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:168)
 at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
 at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
 ...
Caused by: java.lang.NoClassDefFoundError: javax/persistence/Entity
 at com.querydsl.apt.jpa.JPAAnnotationProcessor.createConfiguration(JPAAnnotationProcessor.java:37)
 at com.querydsl.apt.AbstractQuerydslProcessor.process(AbstractQuerydslProcessor.java:82)
 ...
Caused by: java.lang.ClassNotFoundException: javax.persistence.Entity
 ...

해결책

QueryDSL 설정은 아래와 같이 변경하여 해결하였다.

1
2
3
4
5
6


dependencies {
 implementation "com.querydsl:querydsl-jpa:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
 annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
 annotationProcessor 'jakarta.persistence:jakarta.persistence-api'
 annotationProcessor 'jakarta.annotation:jakarta.annotation-api'
}

원인 및 해결 과정

빌드 실패의 원인은 기존 javax.persistence 패키지가 jakarta.persistence로 변경되면서 발생한 문제로 확인되었다.

QueryDSL의 github repository issue를 살펴보면 querydsl-apt에 대해서만 classifier로 jakarta를 설정하면 문제가 해결된다는 comment를 발견하였고, 실제로 적용하면 build 실패 문제가 해결되었으나, QuerydslPredicateExecutor를 이용하여 query를 실행 할 경우, runtime에서 아래와 같은 예외가 발생 함을 확인 할 수 있었다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


java.lang.ClassNotFoundException: javax.persistence.NoResultException
 at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641) ~[na:na]
 at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188) ~[na:na]
 at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) ~[na:na]
 at org.springframework.data.jpa.repository.support.Querydsl.createQuery(Querydsl.java:85) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.jpa.repository.support.Querydsl.createQuery(Querydsl.java:102) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.jpa.repository.support.QuerydslJpaPredicateExecutor.doCreateQuery(QuerydslJpaPredicateExecutor.java:256) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.jpa.repository.support.QuerydslJpaPredicateExecutor.createCountQuery(QuerydslJpaPredicateExecutor.java:225) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.jpa.repository.support.QuerydslJpaPredicateExecutor.findAll(QuerydslJpaPredicateExecutor.java:140) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) ~[na:na]
 at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
 at java.base/java.lang.reflect.Method.invoke(Method.java:568) ~[na:na]
 at org.springframework.data.repository.core.support.RepositoryMethodInvoker$RepositoryFragmentMethodInvoker.lambda$new$0(RepositoryMethodInvoker.java:288) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.RepositoryMethodInvoker.doInvoke(RepositoryMethodInvoker.java:136) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.RepositoryMethodInvoker.invoke(RepositoryMethodInvoker.java:120) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.RepositoryComposition$RepositoryFragments.invoke(RepositoryComposition.java:516) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.RepositoryComposition.invoke(RepositoryComposition.java:285) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.RepositoryFactorySupport$ImplementationMethodExecutionInterceptor.invoke(RepositoryFactorySupport.java:628) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.doInvoke(QueryExecutorMethodInterceptor.java:168) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.data.repository.core.support.QueryExecutorMethodInterceptor.invoke(QueryExecutorMethodInterceptor.java:143) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.data.projection.DefaultMethodInvokingMethodInterceptor.invoke(DefaultMethodInvokingMethodInterceptor.java:77) ~[spring-data-commons-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123) ~[spring-tx-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388) ~[spring-tx-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119) ~[spring-tx-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:137) ~[spring-tx-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodInterceptor.invoke(CrudMethodMetadataPostProcessor.java:163) ~[spring-data-jpa-3.0.0-RC2.jar:3.0.0-RC2]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:184) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:218) ~[spring-aop-6.0.0-RC3.jar:6.0.0-RC3]
 at jdk.proxy4/jdk.proxy4.$Proxy120.findAll(Unknown Source) ~[na:na]
 ...

1
2
3
4
5
6
7


// 예외가 발생했을 때의 QueryDSL 설정
dependencies {
 implementation 'com.querydsl:querydsl-jpa'
 annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"
 annotationProcessor 'jakarta.persistence:jakarta.persistence-api'
 annotationProcessor 'jakarta.annotation:jakarta.annotation-api'
}

코드를 확인해보니 org.springframework.data.jpa.repository.support.Querydsl에서 com.querydsl.jpa.impl.JPAQuery를 사용하고 있으나, data.jpa에서는 jakarta.persistence.EntityManager를 querydsl.jap에서는 javax.persistence.EntityManager를 사용하고 있어서 발생한 문제였다.

com.querydsl.jpa.impl.JPAQuery는 com.querydsl:querydsl-jpa의존성에 속해 있으므로, com.querydsl:querydsl-jpa에도 jakarta classifier를 추가하여 문제를 해결하였다.

현재 (2022년 11월 7일) 위의 내용은 공식 문서를 포함하여 어디에도 제대로 기재되어 있는 곳이 없고, 다른 분들은 나와 같은 삽질을 하지 않길 바라는 마음에 블로깅을 해본다. 많은 분들의 시간이 절약되기를…

ref.

CSS Tips

Fri, 23 Sep 2022 00:00:00 +0000

상속

부모로부터 상속받은 속성은 브라우저의 디폴트 CSS 속성보다 우선순위가 낮다.

여백 상쇄

여백 상쇄(margin collapsing)로 인해 margin이 설정한 것과 다르게 보이는 경우가 있다. (참조)

둘 다 margin을 가진 인접 형제 요소
첫째 및/또는 마지막 (혹은 유일한)의 자식 요소에 margin이 설정된 하나 또는 둘 이상의 자식 요소를 가진 부모 요소 (자식의 margin이 부모의 margin보다 클 경우 발생)

줄바꿈 문자

줄바꿈 문자도 문자로 판단하여, 그만큼의 공간을 차지한다.

예시

두 태그를 한 줄에 놓는 html 예제

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


<html>
 <head>
 <style>
 * {
 box-sizing: border-box;
 }
 .main-div {
 display: inline-block;
 width: 50px;
 }
 .main-nav {
 display: inline-block;
 /* main-div 50px + 줄 바꿈 기호(공백) 5px */
 width: calc(100% - 55px);
 }
 </style>
 </head>
 <body>
 <div class="main-div">
 내용1
 </div>
 <nav class="main-nav">
 내용2
 <nav>
 </body>
</html>

2개 이상의 클래스

2개 이상의 클래스가 1개의 태그에 설정 된 경우 클래스를 선택자로 하여 정의한 CSS 적용 룰

태그에 선언된 클래스의 선언 순서는 영향을 미치지 않는다.
태그에 선언된 클래스를 선택자로 한 CSS의 정의 순서만이 적용에 영향을 미친다.
- 나중에 정의된 CSS가 먼저 정의된 CSS를 덮어쓴다.

border vs. outline

border는 box model의 일부이며, outline은 box model에 속하지 않는다. outline은 border를 포함해서 요소를 완전히 둘러싼다. outline의 경우 해당 요소를 특별히 강조하기 위해 사용된다. (참고)

`margin: auto`

margin: auto로 할 경우, 해당 태그가 width나 height 기준으로 100%에 맞도록 자동으로 margin을 추가해준다. 일반적으로는 width를 % 단위로 줄이고, margin: auto를 사용하여 중앙 정렬을 할 때 많이 사용된다.

동일 z-index

position: fixed인 2개 이상의 태그가 동일한 z-index를 가진경우에는 나중에 정의된 태그가 더 위에 위치한다.

stacking context

형제 태그에 대한 z-index 적용은 서로 독립적이어서, 자식 태그의 z-index는 부모 태그에게만 영향을 줄 수 있다. (참고)

이미지와 컨테이너 사이에 공백이 생기는 문제 대응

컨테이너가 둘려진 이미지가 인라인 요소라면 컨테이너에 공백이 생기는 버그가 있다. 해결하기 위한 방법은 아래와 같다.

이미지에 vertial-align: top을 설정
이미지를 display: block으로 변경

프로그래머의 뇌 요약

Sun, 17 Apr 2022 00:00:00 +0000

프로그래머의 뇌란 책을 읽고, 인상 깊었던 내용을 정리한다.

코드가 초래하는 세 가지 종류의 혼란

지식의 부족
- 프로그래밍 언어나 알고리즘, 업무 영역에 대한 지식 부족
- LTM의 문제
정보의 부족
- 라이브러리, 모듈, 패키지 등의 정보 (ex. 움직임) 부족
- STM의 문제
처리 능력의 부족
- 코드가 너무 복잡해서, 두뇌의 처리 용량이 부족
- 작업 기억 공간의 문제

코딩에 영향을 주는 인지 과정

LTM (Long Term Memory)
- 기억이 아주 오랫동안 보관되며, 별 노력 없이 인출이 가능하다.
- 프로그래밍에서는 추상적인 알고리즘, 프로그래밍 언어의 문법 뿐 아니라 키보드로 입력하는 동작을 기억하는 것까지 포함한다.
- 컴퓨터의 하드 드라이브와 비슷
STM (Short Term Memory)
- 들어오는 정보를 잠시 보관하기 위해 사용
- 크기에 제한이 있으며, 최대 12개를 넘지 않는다고 알려져 있다.
- 코드에서 키워드, 변수명, 자료구조 등을 기억하는 것을 포함한다.
- 컴퓨터의 메인 메모리와 비슷
작업 기억 공간
- 실제 사고 작용이 일어나는 공간
- 컴퓨터의 프로세서와 비슷

코드를 읽는 동안 LTM, STM, 작업 기억 공간이 상보적으로 같이 일어난다.

정보 -> 필터 -> STM -> 작업 기억 공간 -> LTM

코드를 신속하게 읽는 방법

사람의 STM 용량은 2~6개 사이로 추정되며, 용량을 향상 시킬 수 없다. 그로 인해 생소한 코드를 읽는 것에 어려움을 느낀다. 청크를 이용하여 STM의 용량 한계를 극복할 수 있다.

청크 (chunk)

몇 개의 그룹으로 묶은 정보, 하나의 청크는 STM의 기억 공간 하나만 차지한다.

LTM에 지식이 많으면 그 지식으로 인해 청킹(chunking) 하기 용이하고, 결과적으로는 코드를 읽기 수월해진다.
반대로 뛰어난 프로그래머라도 LTM에 아직 저장되지 않은 지식을 이용한 코드 읽기에는 어려움을 겪는다.
- ex. 키워드, 구조, 도메인 개념 등

청킹 효율 향상 방법

코드에서 자주 사용되고, 예상 가능한 흐름
- ex. 디자인 패턴, 프로그래밍 구성 요소, 도메인 지식
- 디자인 패턴을 교육 후, 해당 디자인 패턴으로 만들어진 코드를 수정하게 할 경우 더 짧은 시간에 수정을 완료하였다. 디자인 패턴이 적용되지 않은 코드를 수정할 경우에는 수정시간에 차이가 거의 없었다.
고수준 주석문
- ex. 이 함수는 주어진 이진 트리를 중위 순회하며 프린트한다.
- 저수준 주석문은 오히려 청킹 작업에 부담이 된다. (ex. i++; //i를 1만큼 증가)
표식
- 단순 표식: 식별자 (변수명, 클래스명, 메서드명), 연산자, 구조문 등
- 복합 표식: 2개 이상의 단순 표식을 합친 표식
- 청크보단 작은 범위를 나타냄

문법을 기억하는 것이 중요한 이유

문법 검색 등으로 업무가 중단되면 효율성에 큰 문제를 야기한다.

보통 코딩 중단 후 다시 업무로 돌아가는데 약 15분 정도가 걸림
메서드 수정 작업 도중 중단이 되고 나서 1분 이내에 하던 일을 다시 시작하는 경우는 10% 정도밖에 되지 않음
업무가 중단되면 그동안 코드에 대한 중요한 정보를 잊어버리기 때문

플래시카드를 통한 학습

플래시카드를 사용하기 좋을 때
- 새로운 프로그래밍 언어나 프레임워크, 라이브러리를 배울 때 나오는 새로운 개념 학습
- 어떤 개념을 검색할 때 (중요하다고 판단되는 개념만)
연속으로 카드의 내용을 맞추면 개수를 줄이자

오랫동안 기억을 유지하는 비결

오랫동안 학습한 만큼 더 오래 기억한다.
- 많은 시간 학습해야 한다는 것을 의미하는게 아님
- 계속 반복하는 것이 중요

저장 강도와 인출 강도

LTM으로부터 기억을 가져오는 두가지 기제가 존재한다.

저장 강도: LTM에 얼마나 잘 저장하고 있는가
인출 강도: 무언가를 얼마나 쉽게 기억할 수 있는가

두 강도의 상관관계

저장 강도는 감소하지 않고 늘어나는 반면 인출 강도는 시간이 흐를수록 약해진다.
학습을 추가로 하지 않고 정보를 기억하려고 능동적으로 노력하는 것만으로도 배운 것을 많이 기억할 수 있다.

문법을 기억하지 않음의 악순환

정보를 찾는 것이 쉽기 때문에 문법을 기억 할 필요가 없다고 생각
정보를 인출하려하지 않고, 검색하여 찾아 냄
인출 강도가 강화되지 않음
1번으로 돌아가 반복

스키마와 정교화

스키마(schema): 사고나 생각이 서로 관련되어 조직된 방식
- ex. 1, 3, 15, 127, 63, 31 => 이진수로 표현했을 때 모두 1로만 이루어진 숫자
정교화(eleboration): 기억하고자 하는 내용을 기존 기억과 연관 지으면서 생각하는 것, LTM에 이미 저장된 스키마타에 맞춰서 새로운 기억이 저장되는 것
- ex. java의 반복문을 알고있는 사람이 golang의 반복문을 학습하는 경우

인지 부하

작업 기억 공간은 ‘문제에 적용된 STM’의 의미로 정보를 처리하는 역할을 한다. 그렇기에 STM과 동일하게 한 번에 2 ~ 6개의 항목만 저장이 가능하다. 이 용량이 채워짐의 정도를 인지 부하라 하며, 넘치게 될 경우 과부하(overload) 상태가 된다.

인지 부하의 종류

내재적 부하: 문제 그 자체가 갖는 특성이 원인이 된 인지 부하
외재적 부하: 문제를 풀려는 과정의 복잡도가 원인이 된 인지 부하. 가지고 있는 지식에 따라 부하의 정도가 결정되는 특정이 있다.
본유적 부하: LTM에 새로운 정보가 저장 될 때 발생하는 인지 부하

인지 부하를 줄이는 기법

리팩터링 (인지적 리팩터링)
생소한 언어 구성요소를 다른 것으로 대치 (ex. 삼항 연산자 -> if)
플래시카드에 코드 동의어 추가

앱 헝가리안 vs. 시스템 헝가리안

헝가리안 표기법: 변수명에 변수에 대한 정보를 접두어나 접미어의 형태로 추가하는 표기법
시스템 헝가리안: 변수명에 타입을 나타내는 방식
앱 헝가리안: 변수명에 역할이나 목적을 나타내는 방식
현대의 타입 기반 프로그래밍 언어에서는 시스템 헝가리안을 사용하는 것이 권장되지는 않으나, 앱 헝가리안은 변수의 역할의 이해를 돕기때문에 여전히 유용한 방법이다.

텍스트 지식 vs. 계획 지식

텍스트 지식: 키워드가 하는 일이나 변수의 역할 같은 프로그램의 표면적인 이해를 돕는 지식
계획 지식: 프로그래머가 프로그램을 작성할 때 계획한 것이 무엇인지 혹은 무엇을 달성하려고 했는지에 대한 이해를 돕는 지식
기술 스택, 프레임워크 (ex. 의존성 주입 프레임워크) 는 초점을 분리하기 때문에 실제 구조의 이해를 저하시키며, 즉 ‘계획 지식’을 쌓기 어렵게 한다.
계획 지식을 얻기 위한 깊은 코드 이해를 위해서는 ‘초점’을 찾는 것이 중요하다.
- 초점은 main() 메서드같은 진입 점이나, 오류가 발생한 라인 등을 가리킨다.

인지 능력과 프로그래밍 능력의 상관관계

계산 능력(수학적 능력)을 통한 프로그래밍 능력 예측: 2% 분산(편차)
언어 능력을 통한 프로그래밍 능력 예측: 17% 분산(편차)
- 얼마나 빨리 프로그래밍 언어를 배울 수 있는지에 대한 예측력은 크다.
작업 기억 공간 용량과 추론 능력을 통한 프로그래밍 능력 예측: 34% 분산(편차)
%가 높을 수록 예측력이 높음을 의미

모델 사용의 장단점

모델은 문제의 특정 부분에만 집중하게 해주며, 이로인해 LTM이 관련된 기억을 찾는데 도움을 주기 때문에 문제 해결에 유용하다. 그러나 모델은 생각하는 방식을 제약하고, 생각을 특정한 방향으로 유도하기 때문에 오히려 문제를 어렵게 만들기도 한다.

정신모델

풀어야 할 문제에 대해 추론하기 위해 사용할 수 있는 작업 기억 공간 내의 추상화된 모델이다.
작업 기억 공간에서 먼저 만들어 지고, 경우에 따라 LTM으로 이동한다.
문제 풀이 시 사용 가능한 모델이 LTM에 있으면 그 모델을 이용하여 작업 기억 공간에서 모델을 재구축 한다. 이때 만들어지는 모델은 LTM에 저장된 모델과 같지 않을 수 있다.

정신모델의 예

파일 시스템의 폴더와 파일의 구조: 실제로는 0과 1만을 가지고 있을 뿐
코드의 특정라인이 실행: 실제로는 컴파일 되어 생성된 이진코드가 실행 되는 것임, 컴파일 타임에 최적화가 이뤄지는 경우 실제 동작은 코드와 다르게 수행 될 수 있다. (ex. case문의 최적화)

정신모델의 특징와 예

불완전: 변수를 박스로 생각하는 것이 변수의 모든 특징을 설명하진 못한다.
불안정: 처음에는 변수를 박스로 생각하지만, 변수에 대한 이해가 깊어지면서 이름표가 더 나은 모델이라고 생각한다.
- 나은 모델을 찾았다고 해서 먼저 만들어진 모델이 두뇌에서 삭제되지는 않는다.
모순이 있는 여러 개의 모델이 공존: 변수를 박스로도 이름표로도 생각 할 수 있다. 인지 부하가 높은 상황에서는 갑자기 오래된 모델을 사용 할 수도 있다.
- 오래된 모델이 상대적으로 더 단순한 모델일 가능성이 높고, 인지 부하가 높아지면 단순한 모델을 사용하는 것을 선호하기 때문
사용하지 않으려고 함: 디버깅 시 일반적으로 정신 모델을 만들어 해결하려하지 않고, 코드를 조금만 고치고 다시 돌려보고 버그가 해결됐는지 확인하는 것을 선호한다.

개념적 기계 (notional machine)

추상적 수준에서 컴퓨터가 코드를 실행하는 방법에 대해 추론할 때 사용하는 모델이다.
개념적 기계는 프로그래밍 언어 수준에서 작동하며 기저에 있는 시스템의 모든 세부 사항은 추상화 한다.

프로그래밍과 개념적 기계

프로그래밍에 관해 말할 때는 암시적으로 개념적 기계를 사용하며, 개념적 기계의 구성을 나타내는 단어는 개념적 기계를 만들때 사용한 특정 정신 모델에 영향을 받아 만들어진다. 예를 들어

파일의 열림과 닫힘 상태 => 파일: 열고 닫을 수 있는 박스
포인터가 특정 값을 가리킨다 => 포인터: 특정 값의 위치 정보
함수가 값을 반환한다 => 함수: 입력값을 넣으면 결과값이 나오는 기계

실제 세계의 객체와 동작을 이용하여 만든 개념적 기계로 정신모델을 구축 할 경우, 학습에는 용이하지만, 실제 코드의 움직임을 완전히 설명하지 못하거나 오해하게 만들 수 있다. 한번 저장된 정신 모델은 제거되지 않고, 지속적으로 사용되므로 실제 세계로부터 차용한 개념적 기계를 이용하여 학습하는 것은 신중하게 해야한다.

전이(transfer)

LTM에 저장된 프로그래밍 지식은 새로운 프로그래밍 개념을 배우는데 도움을 주며, 이러한 활동을 전이라 부른다.

학습 도중 전이: LTM에 저장된 정보를 사용해 새로운 내용을 쉽게 배우는 과정
- ex. 자바를 알고 있는 상태에서 파이썬의 메서드를 배울 때, 자바의 메서드가 생각 나면서 좀 더 빨리 학습 할 수 있는 것
학습 전이: 전혀 다른 환경에서 이미 알고있는 개념을 적용하는 과정
- ex. 노트북을 바꿔도 어떻게 키보드를 사용하는지 아는 것

전이의 용이에 영향을 주는 요인

숙달: 숙달된 지식일 수록 전이가 용이하다.
유사성: 두 작업 사이의 유사성이 높을 수록 전이가 용이하다.
배경: 작업을 실행하는 환경(ex. IDE)과 더 큰 범위에서의 환경(ex. 동료가 자신과 비슷한지)이 비슷 할 수록 전이가 용이하다.
중요 특성: 어떤 지식을 전이해야 효과적인지 알고, 적용하면 전이가 용이해 진다.
- 효과적인 지식의 선정은 누군가의 조언을 듣고 받아들이거나, 스스로 질문하여 답을 찾아야 한다.
연관: 두 작업이 얼마나 비슷하다고 느끼는지에 따라 전이가 용이하다.
감정: 작업에 대해 느끼는 감정이 긍정적일 수록 전이가 용이하다.
- 작업에 대해 부정적으로 느끼면, 그 작업 자체에 대해 깊이 생각하지 않으려하므로 전이가 일어나기 힘들어 진다.

범주에 따른 전이의 종류

저도 전이와 고도 전이
- 저도 전이: 새 편집기에서 Ctrl + C, Ctrl + V 사용
- 고도 전이: 변수 선언 방법
근거리 전이와 원거리 전이
- 근거리 전이: C#과 자바
- 원거리 전이: 프로그래밍과 철학

긍정적 전이와 부정적 전이

긍정적 전이: 기존 지식이 새로운 것을 배우거나 작업 할 때 도움이 되는 전이
부정적 전이: 기존 지식이 새로운 것을 배우거나 작업 할 때 방해가 되는 전이
- ex. 객체 지향 언어를 배운 후 함수형 언어를 배울 때 어려움을 겪음
- 부정적 전이는 새로운 언어를 배우고 사용 할 때 혼란을 야기하고 버그로 이어질 수 있음

전이의 어려움

일반적으로 전이가 될 거라 생각하는 것들이 사실은 전이되지 않는다.
- 체스 지식이 논리적인 추론 기술과 기억력, 일반 지능을 높여주지 않는다.
- 프로그래밍을 배운다고 인지 영역으로 전이되어 능력이 향상되지 않는다.
하나의 프로그래밍 언어를 숙달했다고 해서, 새로운 언어를 배우는데 항상 도음이 되는 것이 아니다.
- 즉, 새로운 프로그래밍 언어에서는 문법부터 차근차근 공부를 해 나가야 한다.
사고방식을 확장하기 위해서는 이미 습득한 지식과 근본적으로 다른 지식을 선택하는 것이 중요하다.
두 작업의 공통점과 차이점에 의식적으로 주의를 기울이면 전이가 쉬워 질 수 있다.

오개념(misconception; 오해)

부정적 전이의 결과로서 아래의 3가지가 모두 만족하면 발생한다.

사실과 다르다.
서로 다른 상황에서 일관되게 유지된다.
확신에 사로잡혀 있다.

오개념 교정

기존의 개념을 근본적으로 바꾸거나 대체하여 새로운 언어에 맞는 정신모델로 대체하는 과정을 개념 변화(conceptual change)라고 한다.
- 실제적으로 대체되는 것은 아니고 기존 개념의 인출 빈도를 줄이고, 새로운 개념의 인출 빈도를 늘리는 것이다.
개념 변화를 위해서는 기존의 지식을 떨쳐내야 하기 대문에 많은 에너지 소비와 시간이 필요하다.
억제의 통제 메커니즘을 통해 잘못된 개념대신 올바른 개념을 인출 할 수 있음이 밝혀졌다.
- 억제는 자의식, 머뭇거림, 수줍음과 연관이 있음

오개념 방지

자신이 옳다고 확신하더라도 여전히 틀릴 수도 있다는 것을 인지
- 즉, 열린 마음을 유지하는 것
흔하게 발생하는 오개념에 대해 의도적으로 연구
코드베이스 내의 테스트 및 문서화

식별자 이름 명명

명명이 중요한 이유

이름은 코드베이스의 상당 부분을 차지
코드 리뷰 시 이름의 역할
이름은 문서화의 가장 쉬운 형태
이름이 표식 역할을 할 수 있음 (인지 부하 감소)

명명의 인지적 측면

형식이 있는 이름은 인지 부하를 줄이고, 일관성 있는 이름은 청킹을 용이하게 한다.
식별자에서 사용되는 단어의 갯수도 작업 기억 공간의 최대 크기(2~6개)와 비슷해야 가독성이 좋아진다.
명확한 이름은 LTM에서 각 단어에 해당하는 지식을 검색하기 용이하게 한다.
이름에 대해 심사숙고하는 것은 코딩 후에 하는 것이 좋다. 코드 리뷰가 이름의 품질을 검토하기 좋은 타이밍이다.
- 코딩 시 문제 해결에 몰두해 있으므로 높은 인지 부하를 겪으며, 그럼 좋은 변수 이름을 생각할 여유가 없다.

단어 축약 유무에 따른 차이

식별자의 이름을 단어로 하는 것이 문자나 약자를 썼을 때보다 더 가독성이 좋다.
단일 문자는 변수로 흔히 사용되지만, 독자가 필자와 같은 의미로 단일 문자를 이해 할 가능성은 높지 않으므로 단어를 선택하거나 명명 규약을 따르는 것이 낫다.

스네이크 케이스 vs. 캐멀 케이스

캐멀 케이스로 써있으면 실수 할 확률을 줄여주지만, 인식하는데 좀 더 오랜 시간이 소요된다.
캐멀 케이스로 훈련받은 프로그래머들은 일반인보다 인식속도가 빠르다.
캐멀 케이스로 훈련받은 프로그래머들은 스네이크 케이스를 일반인보다 인식 속도가 더 늦다.

페이텔슨의 3단계 모델

더 나은 이름을 선택하는데 도움을 주기위한 목적으로 만들어진 3단계 모델

이름에 포함할 개념을 선택한다.
각 개념을 나타낼 단어를 선택한다.
- 프로젝트 어휘 사전(project lexicon)이 있으면 일관된 이름을 선택하는 데 도움이 될 수 있다.
이 단어들을 사용하여 이름을 구성한다.
- 자연어에 맞춰 이름 틀을 사용 (ex. 최대 점수 -> max_points)
- 전치사를 추가하는 것 (ex. indexOf, elementAt)

코드 스멜과 인지 부하

코드 스멜은 구조적 안티패턴(structural antipattern)을 가진 코드다. 코드 스멜을 가지고 있는 코드는 오류가 있을 가능성이 높은 것으로 밝혀졌다. 아래는 대표적인 코드스멜과 그에 따른 인지 부하를 나타낸 것이다.

긴 매개변수 목록, 복잡한 스위치 문: 작업 기억 공간의 용량 초과
신의 클래스, 긴 메서드: 효율적인 청킹 불가능
코드 클론: 청킹이 잘못됨

나쁜 이름과 인지 부하

나쁜 이름은 언어적 안티패턴(linguistic antipattern)이라고도 한다. 코드 내 언어적 요소가 수행하는 역할과 일치하지 않을 때 발생한다. 독자의 두뇌에 혼란을 초래해 인지 부하를 높인다.

문제 해결과 LTM

문제 해결을 위한 일반적 접근법

1945년 수학자 포여 죄르지는 ‘How to Solve It’ 이라는 책에서 아래와 같은 ‘사고 체계’를 제안했다.

문제 이해
계획 수립
계획 실행

연구 결과 아래의 이유로 위에 서술한 일반적 접근법이 효과적이지 않음이 밝혀졌다.

계획 수립과 계획 실행은 LTM에 저장된 지식에 크게 영향을 받는다.
- 저장된 지식이 없으면 어떻게 해결해야 하는지, 그리고 그 해결책을 어떻게 실행해야 하는지 모르기 때문이다.
풀고자 하는 문제를 위한 계획 수립에 알맞는 전략을 LTM에서 인출 할 수 있는 가능성이 희박하다.
- 지식의 전이 가능성도 낮기때문에, 다른 영역에서의 경험이 도움을 주기도 쉽지 않다.

문제 해결에 역할을 하는 기억

절차적(암시적) 기억: 의식하지 않고 발휘하는 기술에 대한 기억 (ex. 자전거 타는 법)
선언적(명시적) 기억
- 일화적 기억: 경험에 대한 기억 (ex. 버그 수정 과정)
- 의미적 기억: 의미, 개념, 사실에 대한 기억 (ex. 5 x 7 = 35)

암시적 기억은 다른 것을 배우는데 오히려 방해가 될 수도 있다. (쿼티 키보드 타이핑 -> 드보락 키보드 타이핑)

자동화(automatization)를 통한 문제 해결 능력 향상

암시적 기억에 저장된 정보를 인출 할 경우, 인지 부하가 거의 없기 때문에 더 어려운 문제를 해결하기 쉬워진다.

시간 경과에 따른 암시적 기억

암시적 기억은 반복에 의해 생성된다. 즉, 연습을 통해 만들어진다. 암시적 기억은 아래의 세 단계를 통해 형성된다.

인지 단계: 새로운 정보를 더 작은 부분으로 나누고 당면한 작업에 대해 명시적으로 생각한다.
연상 단계: 패턴이 나타날 때까지 새 정보를 받아들이는 것을 반복하는 단계, 패턴이 나타나면 완료된다.
자율 단계: 자동화 단계로 해당 기억을 인출해도 인지 부하가 증가하지 않는다.

인스턴스 이론(instance theory)

미국의 심리학자 고든 로건은 자동화는 LTM의 일화적 기억이 저장된 부분으로부터 기억을 인출함으로써 이루어진다고 주장한다. 이런 일화적 기억(인스턴스)들 하나하나는 어떤 기술(클래스)에 대한 기억으로 묶을 수 있고, 충분히 많은 일화적 기억이 있으면 더 이상 추론 없이 자동으로 해당 기억이 인출된다.(자동화)

암시적 기억 개선

자율 단계에 도달 하기 위해서는 반복적으로 실행하는 것이 좋다. 프로그래밍에서는 아래의 두가지 방법을 고민해보는 것이 좋다.

연습하고자 하는 기술이 필요한, 유사하지만 다른 프로그램을 많이 작성해보는 것
이미 작성된 프로그램을 수정하는 것

간격을 둔 반복은 학습의 핵심이며, 따로 시간을 떼어두고 연습하는 것이 좋다. 웨이트 트레이닝처럼 반복할 때마다 조금씩 더 강해진다.

풀이된 예제(worked example)를 통한 문제 해결 능력 향상

다른 사람들이 문제를 어떻게 해결했는지 의도적으로 연구함으로써 어려운 문제를 해결 할 수 있게 된다.

제공 받은 풀이된 예제를 가지고 문제를 풀 경우, 그 문제와 비슷한 문제 뿐만아니라 해당 레시피를 적용 할 수 있는 다른 문제도 잘 푸는 것으로 확인되었다.
- 수학, 음악, 체스, 스포츠, 프로그래밍을 포함한 다양한 연령 그룹과 주제에 대한 연구 결과에서 공통적으로 확인
사람들은 해답을 스스로 생각하지 않고, 제공해 주는 것이 실력 향상에 도움이 되지 않는다고 생각하지만 실제로는 그렇지 않다.
깃허브 리포지토리를 탐구하거나, 소스 코드에 대한 책 또는 블로그 게시물을 읽는 것이 프로그래밍 분야의 풀이된 예제 학습 경로이다.

본유적 부하

본유적 부하는 두뇌가 정보를 LTM에 다시 저장하기 위해 수행하는 노력을 의미한다. 다른 부하에 비해 우선순위가 낮으므로, 인지 부하가 높아질 경우 문제와 그 해결책을 기억할 수 없다.
- ex. 힘든 코딩 작업 후 때때로 자신이 한 일이 기억나지 않음)
풀이된 예제를 제공받으면 본유적 부하가 높지 않게 되고, 레시피를 응용 할 여유가 생겨서 비슷한 다른 문제도 잘 푸는 것이다.
프로그래밍에 대해서도 아이들에게 프로그램을 읽고 이에 대한 설명을 통해 배우는 것이 프로그램을 작성하며 배울 때보다 배우는 것이 더 많다는 연구결과도 있다.

업무 중단에 대한 팁

업무 중단을 피할 수 없으면 인지 부하가 적을 때 업무 중단을 하는 것이 업무에 도움이 될 수 있다.

한창 업무 중에 업무 중단을 당할 경우, 그렇지 않은 그룹보다 작업을 끝마칠 때까지 시간이 더 오래 걸렸고, 더 작업을 마치기가 어렵다고 인식했다.

멀티태스킹

사람은 깊은 인지 작업을 하는 동안 여러 가지 일을 할 수 없다.
- 단, 자율 단계에 도달 한 경우에는 두 개 이상의 작업을 동시에 수행 가능하다.

적응 지원(onboarding)

적응 지원의 문제

일반적으로는 아래의 과정으로 적응 지원이 진행된다.

코드베이스의 도메인, 워크플로, 코드베이스를 한꺼번에 소개한다.
소개가 끝난 후 질문을 하거나 과제를 준다.

이로인해 적응 지원을 받은 팀원은 아래와 같은 어려움을 겪는다.

너무 많은 정보의 양으로 인한 높은 인지 부하
도메인이나 프로그래밍 언어의 부족으로 인한 청킹의 어려움
자동화 기술 부족으로 인한 인지 부하

이러한 부하들로 인해 결국은 본유적 부하에 대한 여유 공간이 없어지므로 새로운 정보를 기억하는데 문제가 생긴다.

전문가의 저주

어떤 기술을 충분히 익히고 나면, 그 기술이나 지식을 배우는 것이 얼마나 어려웠는지 잊어버리는 것. 새 팀원이 처리할 수 있는 작업의 양을 과대평가한다.

전문가와 초보자의 차이

전문가의 뇌는 LTM에 관련 기억이 많이 저장되어 있다. 그러므로 문제에 대해 이미 알고 그것에 접근하는 방법을 알고 있을 가능성이 높다.
전문가는 코드 및 코드와 관련 있는 모든 사항을 매우 효과적으로 청킹할 수 있다.
- ex. 오류 메시지, 테스트, 문제, 해결책 등

신피아제주의 개발 단계

감각운동기
- 프로그램을 정확하게 추적할 수 없다.
- 코드와 분리해서 일반적인 원리를 설명하는 것이 유용하지 않다. 실행 모델에 대한 이해가 우선 필요하다.
전조작기
- 코드에 대해 귀납적으로 추론하므로, 그 코드의 의미를 설명하기는 어렵다.
- 코드 자체에 매우 집중하는 단계이므로 다른 결과물들 (ex. 도표)을 보는 것을 어려워하므로 도표 제공이 유용하지 않다.
- 코드를 깊이 이해하는 것이 어렵기 때문에 교육자가 보기에 일관적이지 않아 보인다.
구체적 조작기
- 코드 자체를 읽음으로써 코드에 대해 연역적으로 추론한다.
- 코드를 작성할 때 계획을 세우고 실행할 수 있다.
- 때때로 코드베이스에 대한 전체적인 이해가 부족할 수 있고, 처음 수립한 전략에 대해 과도하게 몰입하는 것이 나타날 수 있다.
  - ex. 특정 버그를 수정하려고 종일 시도했지만 계속 실패한 주니어 프로그래머는 원래 방식을 계속 시도하곤 한다.
형식적 조작기
- 논리적이고 일관적이며 체계적으로 추론할 수 있다.
- 세부 사항을 스스로 배우는 데 어려움이 없고 필요하면 도움을 요청할 것이다.

4개의 단계는 연속적이며, 새로운 프로그래밍 개념이나 코드베이스의 새로운 측면을 학습할 때 학습자는 일시적으로 하위 단계로 다시 떨어질 수 있다.

의미적 파동(semantic wave)

초보자가 무언가 이해하려 할 때는 오스트레일리아의 과학자 칼 메이튼에 의해 정의된 의미적 파동을 따른다.

사용하는 목적이나 이유와 같은 일반적인 개념을 이해
포장 풀기: 특정 개념에 대해 구체적인 세부 사항을 학습
재포장: 학습한 내용을 바탕으로 다시 추상적인 수준으로 되돌아옴, LTM에 통합하는 작업을 포함

이와 관련하여 3가지 안티패턴이 존재한다.

고 평면선: 추상적인 용어만 사용
저 평면선: 해당 개념이 왜 적절하고 유용한지 모르고 세부 사항만 지나치게 학습
하향 에스컬레이터: 일반적 개념을 이해하고, 세부 사항을 학습했으나 재포장 시간이 없어서 LTM에 통합되지 못함
- 새로운 개념과 예비 정보 사이에서 발견되는 공통점을 초보자에게 명시적으로 물어보는 것으로 도움을 줄 수 있음

적응 지원 개선 방안

작업은 하나의 프로그래밍 활동으로만 제한
- 탐구: 코드베이스의 전체적인 이해를 위한 코드 훑어보기
- 검색: 특정 인터페이스를 구현한 클래스 찾기
- 전사: 구현할 메서드에 대한 명확한 계획을 알려주기
- 이해: 코드의 여러 측면에 대해 이해하기 (ex. 특정 메서드 요약하기)
- 증가: 향후 계획을 포함해서 기존 클래스에 한 가지 기능을 추가하기
기억 지원
- LTM 지원: 관련 정보 설명
- STM 지원: 규모가 작고 집중할 수 있는 작업 준비
  - 만드는 것 보다 이해하는 것이 중요 (ex. 기존 클래스 요약, 특정 기능의 실행에 참여하는 모든 클래스를 기록)
  - 간단한 기능을 구현하는 것도 가능. but, 관련 코드를 미리 준비 하는 작업 등의 인지 부하 감소 활동이 동반되어야 함
- 작업 기억 공간 지원: 도표 그리기
  - 완전 초보자에게는 항상 유용하지는 않다.
코드 함께 읽기

hugo와 github pages로 간단히 블로그 만들기

Sat, 13 Feb 2021 00:00:00 +0000

목표

블로그 진입점을 github pages의 루트가 아닌, 서브 path로 합니다.
- ex. https://seungyeop-lee.github.io/test-blog/
하나의 repository에서 hugo의 소스파일과 생성된 html을 전부 관리합니다.
github actions를 이용하여 push 할 경우, 자동으로 배포가 되게 합니다.
utterances를 사용하여 댓글도 같은 repository에서 관리합니다.

실습전 확인 사항

주의

시간이 지남에 따라 내용이 정확하지 않을 수 있습니다. 화면이나 움직임이 다를경우 공식 문서를 참고해주세요.

전제 조건

git 설치
github 계정 준비

실습 환경

macOS 환경
brew, vscode 사용

Search

Sat, 06 Feb 2021 13:00:08 +0900

Links

Mon, 01 Jan 0001 00:00:00 +0000

펭귄의 외부 저장소

Claude와 나눈 AI 시대 인간의 차별화 능력

목차

1. 펄의 인과적 사고 3단계

2. AI는 도구다

3. 좋은 질문이란

4. 결론: AI 시대 인간의 핵심 능력

핵심 인사이트

Claude와 나눈 AI 협업 이야기

목차

1. AI 협업의 딜레마

2. 이해관계자 압박과 인식의 두려움

3. AI 시대의 아키텍처와 패턴

4. 실용적 전략

5. AI의 실제 가치

6. 효과적인 “같이 생각하기”

핵심 인사이트

Supabase Backup & Migration CheetSheet

setting local env

From remote To local

Schema

Data

From local To remote

Schema

Data

k6 테스트 결과 간단히 시각화하기 (Web Dashboard, HTML Test report)

실습 준비

실습

테스트 대상 서버 기동

k6 스크립트 작성

k6로 부하 테스트 실행

Web Dashboard

Test report 확인

테스트 환경 정리

마무리

Dagger Functions와 함께하는 CI/CD Pipeline as Code

Dagger 소개

Dagger 사용 예시

Dagger Functions 소개

Dagger Functions 장점

Dagger Functions 시작하기

Dagger 설치

Dagger Module 만들기

Dagger Function 작성

Daggerverse 활용

마무리

ref.

Docker와 Web browser로 MySQL Workbench 사용하기

TL;DR

발단

Docker로 MySQL Workbench 실행시키기

한글 입출력 문제 대응

결론

지도구직 개선 회고

2024. 03. 13 추가

기능 개선 목표

검색조건 확대

디자인 개편

모바일 브라우저 대응

그 외 개선사항

자잘한 기능 개선

Next.js 도입

Caddy -> Traefik, K8s -> Docker

DB 백업

소감

좋은 코드, 나쁜 코드 북스터디

Spring MVC와 Mybatis 기반의 단순 아키텍처

서론

AS-IS

구성도

예제 코드

TO-BE v1

구성도

예제 코드

TO-BE v2

구성도

예제 코드

TO-BE v3

구성도

예제 코드

`new TestRestTemplate`

`@Autowired TestRestTemplate`

`new TestRestTemplate`

`@Autowired TestRestTemplate`

`margin: auto`