코딩공부방

첫 개발자 커리어는 중소기업에서 시작해 약 2년 5개월간 자사 앱 서비스를 유지보수하는 역할을 맡았다. 그러나 점차 개발자로서의 역량 부족을 느끼며, 코드를 작성하는 데 부담감을 가지게 되었고, 결국 퇴사를 결정했다. 이후 부족한 부분을 채우기 위해 삼성청년소프트웨어아카데미(SSAFY)에서 1년간 교육을 받았으며, 그 후 외국계 SI 기업에 백엔드 개발자로 다시 커리어를 시작하게 되었다. 현재까지 약 10개월간 SI 백엔드 개발자로 근무했고, 진행 중인 프로젝트가 마무리되는 시점에 회고를 남기게 되었다.

SI 기업에 처음 취업하면서 알게 된 점

1. SI 기업은 인력을 Man/Month(맨먼스) 단위로 표현한다. 말 그대로 ‘한 사람이 1개월 동안 수행할 수 있는 작업량’을 의미하지만, 이 단위가 실제 개발자의 능력을 반영하는 것은 아니라는 점이 인상 깊었다. 개발자의 등급과 맨먼스를 통해 단가가 책정되는 구조였다.
2. 취업 후에도 고객사 파견을 위한 별도의 면접을 보게 된다. 이는 고객사의 요청이 있을 경우에 진행되는 것으로 보이며, 면접 없이 파견되는 경우도 존재했다.
3. 고객사에 파견된 이후에는 본사에서 큰 관심을 가지지 않는 듯한 느낌을 받았다. 일단 고객사에 인력이 투입되면, 복귀하기 전까지는 실질적인 케어가 거의 없었다.

프로젝트를 진행하며 알게 된 점

1. 물류 도메인의 프로젝트를 진행하면서 실제 로봇의 이동이 알고리즘에 의해 제어되는 모습을 직접 확인할 수 있었다. SSAFY에서 학습했던 다익스트라 알고리즘이 실제 환경에서 사용되는 것을 보며, 그 중요성을 다시금 느꼈다.
2. 폐쇄망 환경에서 Jenkins를 구성하면서 다양한 네트워크 이슈를 경험했다. 예를 들어 Git 서버에서 Webhook 송신은 불가능했지만, Jenkins 서버에서 Pull 방식은 가능했다. 이는 방화벽 설정 등 네트워크 제약에 따른 현상으로 보였다.
3. 고객이 Teams를 통해 빌드 결과를 받고 싶어 하셨고, Jenkins Plugin으로는 원활하게 동작하지 않아 Webhook 엔드포인트를 직접 받아 curl 명령어를 통해 메시지를 전송하도록 구성했다.
4. SI 프로젝트에서 가장 번거로운 점은 문서화 작업의 양이었다. 특히 API 명세서를 따로 생성해야 했기에, Swagger 데이터를 파싱하여 Excel 문서로 자동 생성하는 스크립트를 작성하였다. 이 과정에서 TypeScript와 유사한 ExcelScript를 사용해볼 수 있었다.
5. Jenkins, SonarQube, Nginx를 온프레미스 Windows 환경에 구축해야 하는 고객 요청이 있었는데, 이 과정에서 예기치 못한 이슈도 발생했다. 특히 Windows 명령줄에서 명령어 실행 시 대문자가 자동으로 소문자로 변환되는 문제가 있었고, 이는 보안 프로그램 때문으로 추정되었다. 결국 PowerShell과 Bash를 활용해 우회하는 방식으로 해결했다.
6. 자사 서비스의 품질 검증 프로세스를 거치며 보안, 아키텍처, 테스트 각 팀으로부터 다양한 컨설팅을 받았다. 보안 측면에서는 프론트엔드와 백엔드의 역할 구분을 명확히 해야 함을 느꼈고, 아키텍처 측면에서는 고가용성을 위한 구조 설계에 대해 다시 고민하게 되었다. 테스트 측면에서는 사용자 친화적인 UI/UX의 중요성을 체감했다.
7. 좋은 고객을 만나는 것이 얼마나 중요한지를 느낄 수 있었다. 파견 전에는 '갑을' 관계에서 오는 어려움이 있을 거라 예상했지만, 다행히 현재 고객사에서는 팀원들을 잘 챙겨주셔서 늘 감사한 마음이다. 앞으로도 팀에 더 많은 기여를 하고 싶다.

앞으로 어떻게 할까

단기 목표

이번 분기에는 개발 공부를 많이 하지 못했다. 가장 가까운 목표는 KCNA 자격증 취득이다. 현재 프로젝트는 대용량 트래픽을 처리하지 않기 때문에 상대적으로 간단한 아키텍처로 구성되어 있지만, 앞으로 대용량 트래픽을 다뤄야 하는 상황이 온다면 꼭 사용해보고 싶은 기술이기 때문에 지금부터 개념 정리를 해두고 싶다.

커리어 목표

그동안 항상 "CTO가 되고 싶다"는 목표를 가지고 있었지만, 문득 왜 그렇게 생각했는지를 되짚어 보게 되었다. 개발자의 커리어는 제너럴리스트와 스페셜리스트 두 방향으로 나뉠 수 있다고 생각한다. 나는 지금까지 제너럴리스트로 살아온 것 같다. 앱 개발자로 시작해, 백엔드, 풀스택 등 다양한 영역을 경험하면서 자연스럽게 CTO라는 꿈을 꾸게 된 것 같다.

최근 서비스 품질 검증 과정에서 아키텍처 팀의 검증을 받으며, 내가 생각한 이상적인 CTO의 모습을 확인할 수 있었다. 서비스에 대한 배경지식 없이도 문제를 정확히 짚고, 서버에 직접 접근해 원인을 분석하는 모습이 매우 인상 깊었다.

이 경험을 바탕으로 다음 커리어는 아키텍트가 되었으면 한다. 그리고 그 이후, 변함없이 CTO가 되고 싶다.

2024 회고

1. 취업

2024년 6월에 SSAFY 10기를 수료하고 운 좋게도 취업이 되어 지금 회사로 취업(이직?) 하게 되었다. 처음으로 SI 기업에서 일을 하게 되었는데, 악명이 높은것과 별개로 현재 워라밸, 기술스택, 고객과의 관계 모두 순조롭고 만족스럽다.
 
아쉬운점은 두가지가 있는데, 첫번째로 업무에서의 아쉬운 점은 SI 하도급으로 프로젝트에 참여하면서 보안상의 이유로 서비스의 전체 소스코드를 확인할 수 없는 점에서 기여할 부분들이 한정적이라는 점이다. 웹 개발 뿐만 아니라, 인프라 및 클라우드 관련 공부도 했었기에 지식들을 써먹을 수 없어서 조금 아쉬운 부분이 있다.
 
두번째로는 회사의 문제이다. 우리회사는 SI 기업의 해외 지사이므로 해외 개발 인원들과 협업을 해야하는데, 소통을 하는것이 정말 어렵다. 백엔드 개발을 담당하면서 프론트 개발자들을 위한 문서를 작성해야 하는데, 내 생각처럼 개발이 매끄럽게 진행되지는 않는 것 같다. 물론 문서를 보기좋게 작성하지 못한것이 가장 큰 문제겠지만, 서비스에 좀더 관심을 가져주고 적극적으로 소통할 수 있었다면 더 좋지 않았을까 생각한다.

1. 생활

생활은 워라밸이 크게 달라진 것 같다. SSAFY로 출퇴근 할 때에는 역삼역으로 출퇴근 했기에, 지옥이 따로 없었다. 지금은 발산역으로 출퇴근 하면서 비교적 쾌적한 출퇴근 길을 만끽하고 있다. 지금 살고 있는 집 계약이 10월에 만료되고, 직장도 강서구쪽에 계속 지낸다면 강서구로 이사가서 자리를 잡으면 좋을 것 같다.

1. 공부

올해 취업하고 나서는 두가지에 초점을 두고 공부를 했던 것 같다. 바로 자격증과 오픈소스이다. 6월에 취업하고 나서 7월, 9월, 11월 세가지의 자격증을 땄다. AWS의 Solutions Architect Associate, Developer Associate 그리고 Github Foundations다. AWS 자격증의 경우 클라우드 관련 지식이 부족하다 느껴져 좀 더 자세하게 알고 싶어서 공부를 시작했는데, 비록 필기 시험이지만 클라우드 아키텍쳐를 구축하는데 필요한 디테일한 부분들을 맛볼수 있었다. 지인들에게도 꼭 추천하고 싶은 자격증이었다. 반면 Github Foundations의 경우 구글에서 검색했을 때 국내에서 이 자격증을 딴 사람을 본적이 없어서 1호 블로그 포스팅을 하고자 자격증을 취득했다. 하지만 감독관 없는 시험이고, 비용도 50달러 (6~7만원) 정도 하므로 굳이 돈주고 칠 시험은 아니라는 생각이 들었다.
 
오픈소스의 경우 다양한 오픈소스에 기여하고자 노력했다. SSAFY 10기 자율 프로젝트를 Lunit 기업연계 프로젝트로 하면서 피쳐플래깅 서비스를 만들게 되었는데, 이 때 레퍼런스로 자주 참고했었던 Unleash라는 피쳐플래깅 서비스의 문서화에 기여했다. 내부적인 흐름에 기여하지는 못했지만 첫 오픈소스 기여라는 점이 인상깊었다.
 
또한 fxSound라는 이퀄라이저 Windows App의 한글화에도 기여했다. 이 기능도 비교적 중요도가 낮은 기능이지만, 기여하려고 서비스를 찾은게 아니라 서비스를 쓰다보니 한글화가 잘 되어있지 않았고 찾아보니 신기하게도 오픈소스 였다. 그래서 수정하여 PR을 요청 드렸는데 다행히도 merge 되었다.
 
이 외에도 Spring Data JPA와 여러 서비스에 기여하고자 했지만 이름을 남기지는 못한게 아쉽다.

1. 건강

연말이 되면서 살이 조금 쪘다. 술을 많이 먹게 되서 그런 것 같다. 그리고 11월 부터는 집에서 혼술하는 습관을 버리려고 노력하고 있다. 아직까지는 순조롭게 지켜지고 있는 듯 하다.

2025년 목표

1. 취업

가능하다면 현재 진행하고 있는 물류 프로젝트와 비슷한 도메인의 자사 서비스 회사 또는 원청사로 이직을 하고 싶다. 좀 더 주도적으로 내가 가진 역량을 펼치고 싶다. 2025년에는 이직을 준비할 것 같다.

1. 생활

10월달에 원하는 집으로 이사를 가기 위해서는 역시 저축을 잘 해야한다. 정치 경제가 어지러운 만큼, 내년에는 올해보다 더한 빙하기가 올것이라고 생각한다. 10월에는 아마 다시 월세로 이사를가게 될 것 같다. 10월에 올바른 선택을 하기 위해서는 경제 공부도 잘 해야 나은 선택을 할 수 있겠지? 잊지말고 공부하자..

1. 공부

2025년에는 어떤 공부를 해야할 지 아직 정하지 못했다. 생각했던 다양한 후보들은 아래와 같다.

• 영어 공부 (전화영어)
• 경제 공부 (방법은 아직 생각해보지 않았다.)
• 자격증 공부 (빅데이터분석기사 or AWS 자격증 or Kubernetes 자격증)
• 알고리즘 공부 (이직을 위해서..)

우선 2월 부터 알고리즘 공부를 조금 해볼 생각이다. 다른 내용들은 차차 생각해보고자 한다.

1. 건강

요즘 잦은 음주로 인해 체중이 증가했고, 웨이트는 너무 재미가 없다. 1월부터 바로 MMA 체육관을 등록 할 것이다. 건강한 신체에 건강한 정신이 깃드니까, 좀더 차분한 사람이 되어보자..
 
힘내자!

개요

SAA-C03, Github Foundations에 이어 올해 마지막으로 DVA-C02 자격증을 취득했다. SAA-C03를 공부하면서 다양한 AWS 서비스의 존재 여부와 전체적인 틀에 대해서 알 수 있었고, DVA-C02의 경우는 이 서비스들 중에 특정 서비스를 다루는 방법이라고 들어 자격증을 준비했다. SAA-C03에 비해 느슨하게 준비했었지만 간단한 후기를 올려본다.

공부방법

SAA-C03 취득 이후 약 4개월이 지났는데, 공부는 회사 업무가 끝나고 틈틈히 공부했다. 아마 3주정도 공부한 것 같다. 나는 별도로 Udemy강의는 듣지 않았고, examTopics의 덤프 문제를 1.5회독 했다.

dump문제가 약 400개 있었는데, 시험치기 전까지 1회독 이후 200번 정도까지 한번 더 본 것 같다.

헷갈리는 문제는 examTopics의 댓글들을 보며 답변을 비교해봤고, 답변을 봤을때도 어려운 문제는 구글링을 통해 서비스에 대해서 조금 더 살펴봤다.

후기

DVA-C02는 SAA-C03보다 특정 서비스에 대한 질문들이 많이 있었던 것 같다. 주로 Lambda, Cloudformation, CDK, Elastic Beanstalk, API Gateway, KMS, DynamoDB, SQS, Kinesis 등등..의 서비스의 지식에 대해서 물어본 것 같다.

SAA-C03를 이미 취득한 사람이라면, DVA-C02 공부를 하지 않더라도 문제의 절반은 맞을 수 있을 것 이라고 생각한다.

그리고, 이번 시험은 처음으로 온라인 시험인 OnVue를 통해 시험을 치뤘는데, 감독관님과 소통을 영어로 해야하는점이 어려웠다. 잘 못 알아들어서 텍스트로 보내달라고.. 계속 말했었다. 영어공부를 먼저 해야하는건가??

AWS 자격증 배지가 하나 더 생겨서 기분이 좋다 ^^

개요

갑자기 예전에 만들었던 Android 앱을 Github Release로 배포하는 Github Action 스크립트를 누군가가 사용하고 있는지 궁금해서 검색해봤다. 그런데 정말 사용하는 사람이 있네??

왠지모를 내적 친밀감이 생겨 해당 레포지토리를 조금 탐색해봤다.

안드로이드 앱 런쳐 프로그램인 것 같은데, 그냥 보기만 해서는 잘 모르겠다.테마??를 적용하는 프로그램 인 것 같다.

해당 프로그램은 꽤나 많은 사람들이 유지보수 하는 오픈소스로 보인다. (11명의 contributer, 37개의 frok, 181개의 star..)

내가 작성한 릴리즈 스크립트가 다른 오픈소스 활동에 도움을 줄 수 있다는 것이 기쁘다. 앞으로도 오픈소스 기여를 통해 전 세계의 개발자들과 소통하고, 사람들에게 도움을 줄 수 있게 노력해야겠다!

마지막으로, 안드로이드 Release 빌드 앱을 Github Release를 통해 쉽게 배포하고 싶다면, 아래의 링크를 통해 아주 간단하게 배포할 수 있다 ^^

https://github.com/marketplace/actions/github-action-release-apk  

헥사고날 아키텍쳐

목표 : 응용 프로그램의 비즈니스 로직을 외부 세계로부터 격리시켜 유연하고 테스트하기 쉬운 구조를 만드는 것

핵심 비즈니스 로직은 중앙의 도메인 영역에 위치하며, 입력과 출력을 처리하는 포트와 어댑터를 통해 외부와 소통한다.

헥사고날 아키텍쳐의 장단점

장점

• 유연성 : 외부 시스템이나 인프라와의 의존성을 낮추어, 구성 요소를 쉽게 교체하거나 업데이트 할 수 있다.
• 테스트 용이성 : 비즈니스 로직을 독립적으로 테스트할 수 있어 품질 향상과 개발 속도 향상에 도움이 된다.
• 유지보수성 : 책임이 분리되어 있어, 코드의 이해와 수정이 용이하며, 변화에 빠르게 대응할 수 있다.

단점

• 구현 복잡성 : 포트와 어댑터를 구성하고 관리하는데 약간의 복잡성이 따른다.
• 초반 개발 시간 증가 : 아키텍처를 처음 구축할 때 시간과 노력 필요

헥사고날 아키텍쳐 구조

포트 (인터페이스)

포트는 애플리케이션 코어의 경계를 정의하며, 애플리케이션 코어가 제공해야 할 기능을 나타내며 어댑터를 통해 애플리케이션 코어에 접근하는 인터페이스이다.

Input Port : 외부 요청이 애플리케이션 코어로 들어오는 경로를 정의한다. 예를 들어, 웹 요청, GUI 이벤트, 스케줄링 이벤트 등이 인커밍 포트를 통해 애플리케이션 코어로 들어올 수 있다.

• Spring Web MVC의 Controller와 Service 사이의 인터페이스

Output Port : 애플리케이션 코어가 외부 세계에 서비스를 제공하기 위한 경로를 정의한다. 예를들어 데이터베이스, 메시징 시스템, 웹 서비스 등에 데이터를 전송하거나 요청하는 경우에 사용한다.

• Spring web MVC의 Repository와 Service 사이의 인터페이스

어댑터 (구현체)

어댑터는 포트를 통해 애플리케이션 코어와 외부 세계를 연결한다. 어댑터는 특정 외부 기술이나 프레임워크에 의존적인 로직을 담당하며, 이를 통해 애플리케이션 코어는 외부와의 결합도를 최소화하고, 어댑터를 통한 교환 가능성을 확보한다.

Input Adapter : 사용자 인터페이스, 테스트 또는 외부 시스템으로부터의 요청을 애플리케이션 코어로 주도하는데 사용된다.

• Spring Web MVC의 Controller

Output Adapter : 애플리케이션 코어에서 외부에 데이터를 전달하는 역할을 담당한다. 예를들어, 데이터베이스에 데이터를 저장하거나 외부 시스템에 메세지를 전송하는 등의 역할을 한다.

• Spring Web MVC의 Repository

유즈케이스

Clean Architecture에서 사용하는 용어로 Spring Web MVC의 Service 영역에 해당한다.

헥사고날 아키텍쳐 예시

Kafka와 같은 외부 시스템과 연동하는 경우 헥사고날 아키텍쳐의 장점을 알 수 있다.

3계층 아키텍쳐에서 kafka 적용

// KafkaProducer.java
public class KafkaProducer {
    public void send(User user) {
        // 카프카에 사용자 정보 전송
    }
}

// UserService.java
public class UserService {
    private UserRepository userRepository;
    private KafkaProducer kafkaProducer;

    public UserService(UserRepository userRepository, KafkaProducer kafkaProducer) {
        this.userRepository = userRepository;
        this.kafkaProducer = kafkaProducer;
    }

    public void createUser(String name, String email) {
        User user = new User(name, email);
        userRepository.save(user);
        kafkaProducer.send(user);
    }
}

헥사고날 아키텍쳐에서 kafka 적용

// OutputPort.java
public interface OutputPort {
    void sendMessage(User user);
}

// KafkaAdapter.java
public class KafkaAdapter implements OutputPort {
    private KafkaProducer kafkaProducer;

    public KafkaAdapter(KafkaProducer kafkaProducer) {
        this.kafkaProducer = kafkaProducer;
    }

    public void sendMessage(User user) {
        kafkaProducer.send(user);
    }
}

// CreateUserUseCaseImpl.java
public class CreateUserUseCaseImpl implements CreateUserUseCase {
    private UserRepository userRepository;
    private OutputPort outputPort;

    public CreateUserUseCaseImpl(UserRepository userRepository, OutputPort outputPort) {
        this.userRepository = userRepository;
        this.outputPort = outputPort;
    }

    public void createUser(String name, String email) {
        User user = new User(name, email);
        userRepository.save(user);
        outputPort.sendMessage(user);
    }

}

기존 아키텍쳐의 경우 UserService 클래스가 카프카와 직접 연결되어 있다. 이 경우 UserService는 Kafka에 대한 의존성을 가지게 된다.

반면 헥사고날 아키텍쳐에서는 OutputPort 인터페이스를 통해 외부 시스템과의 의존성을 분리한다.

이러한 구조를 통해 외부 시스템 변경이 있을 때에도 비즈니스 로직에 영향을 최소화 하고 유연성을 확보할 수 있다.

만약 메세지 서비스를 Kafka에서 RabbitMQ로 변경한다고 생각해보자.

기존 3계층 아키텍쳐의 경우 KafaProducer라는 클래스를 직접 의존하고 있기에, RabbitMQProducer라는 새로운 클래스를 생성하고 이를 사용하게 될 것이다.

하지만 핵사고날 아키텍쳐에서는 Output Port의 구현체를 KafkaAdapter 에서 새로 생성한 RabbitMQAdapter로 변경해주면 비즈니스 로직의 변화 없이 구현체만 바꾸는 것으로 빠르게 대응할 수 있을 것이다.

마무리

블로그 탐색중에 헥사고날 아키텍쳐라는 새로운 키워드를 발견하여 이에대해 간단히 조사해 보았다. 키워드를 발견했을때는 아키텍쳐에 깜짝 놀랄만한 변화가 있을 것 같았지만, 읽어보니 느낀점은 Spring 웹 서비스에서는 메세징 서비스와 같은 외부와 통신하는 부분을 한번 더 인터페이스로 감싸서 접근하는 방식으로 의존성을 줄인 것이라는 느낌이 든다.

아직 경험이 많이 부족하여 크게 와닿지 않는 것 같지만, 소스코드 탐색중에 Port, Adapter, UseCase와 같은 생소한 단어가 나와도 대응할 수 있는 얕은 지식이 생겼다. 또한, 다음 서비스를 개발 할 때 위 처럼 외부와 통신하는 서비스의 변경을 고려한 설계를 하게 된다면, 헥사고날 아키텍쳐를 도입하는 것을 고려해 볼 수 있을 것 같다.

Reference

https://tech.osci.kr/hexagonal-architecture/
https://velog.io/@coconenne/%ED%97%A5%EC%82%AC%EA%B3%A0%EB%82%A0-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%EC%96%B4%EB%8C%91%ED%84%B0%EC%99%80-%ED%8F%AC%ED%8A%B8-%EA%B2%B0%ED%95%A9%EB%8F%84%EB%A5%BC-%EB%82%AE%EC%B6%B0%EB%B3%B4%EC%9E%90

개요

회사에서 JPQL을 통해 테이블 조인 및 검색 조건을 추가하는 쿼리를 작성하고 있었는데, 쿼리 성능 개선을 위하여 inlineView(from 절 subquery)를 작성해야 할 필요가 있었다.

많은 게시글에서 JPA에서 inlineView를 사용하지 못한다는 글을 봐서, 사용할 수 있는 다양한 샘플과 함께 회사 코드에서는 사용이 어려웠던 이유, Spring Data JPA 레포지토리에 이슈를 생성한 것 까지 모두 작성해본다.

JPA에서 inlineView, 사용가능한가?

사용가능하다. 이전에 작성한 글에서 이미 말했듯이, Hibernate 6.1 버전부터 inlineView가 사용가능 하다.

다만, 다양한 케이스를 테스트 하면서 알게 된 점은 데이터를 Entity, Interface Projection, Class Projection, List 형식 모두 상관없이 쿼리를 작성할 수 있지만,
PageRequest와 함께 inlineView 쿼리를 작성하게 되면 JPA가 제공하는 count 쿼리만으로는 오류가 발생한다.

이 부분에 대해서는 Spring-Data-JPA 레포지토리에 이슈를 작성하여 문제가 맞는것인지, 해결 가능한 문제인지를 천천히 살펴 본 후 공유할 생각이다.

라이브러리를 유지보수 하시는 개발자께서는 이를 countQuery를 직접 작성하는 방법으로 문제를 해결하시길 권유하셨고, 이슈는 closed 상태가 되었다. 아마도 이 부분에 대해서 따로 지원하실 계획은 없는것으로 보인다.

아래에 해당 이슈를 함께 첨부한다.

https://github.com/spring-projects/spring-data-jpa/issues/3662

JPA에서 inlineView 사용 쿼리

먼저 작성한 테스트 케이스는 다음과 같다.

[Spring JPA][Interface Projection] inline subquery with join - 가능

[Spring JPA][Class Projection] inline subquery with join - 가능

[Spring JPA][Interface Projection] multiple Join inline subquery with join - 가능

[Spring JPA][Interface Projection] multiple Join inline subquery with join and param - 가능

[Spring JPA][Interface Projection] page request without subquery - 가능

[Spring JPA][Interface Projection] page request without join - countQuery 추가 작성 필요

샘플을 직접 확인하고 싶은 경우 아래의 레포지토리에서 샘플을 테스트 할 수 있다.

https://github.com/gogoadl/spring-jpa

Page Request와 함께 InlineView 요청

샘플 쿼리를 디버깅하면서 page타입으로 데이터를 수신할 때에만 Spring-Data-JPA의 AbstractJpaQuery 클래스의 createCountQuery에서 호출이 실패하고 오류 로그가 발생하는 것을 알 수 있었다.

아래는 호출에 실패한 count Query와 오류 로그이다.

SELECT count(T) FROM (SELECT T2.id as id, T2.name as name, T2.address as address FROM Member T2 ) T

org.hibernate.query.SemanticException: The derived SqmFrom[id, name, address] can not be used in a context where the expression needs to be expanded to identifying parts, because a derived model part does not have identifying parts. Replace uses of the root with paths instead e.g. `derivedRoot.get("alias1")` or `derivedRoot.alias1`

생성한 카운트 쿼리를 실제로 실행해봐도 정상적으로 동작하지 않는것을 알 수 있었는데, 위의 카운트 쿼리에서 InlineView 쿼리까지는 정상적으로 동작하지만 결과 테이블을 T라는 alias로 접근 가능하도록 했고 이를 바깥 쪽 SELECT 할 때 alias 테이블 이름만 사용했기 때문에 문제가 발생하는 것으로 보인다. 이를 T.id 처럼 alias와 함께 필드 이름을 적용하면 정상적으로 카운트 쿼리가 동작한다.

마무리

Spring-Data-JPA에 기여하는 것은 실패했다. 내 샘플 코드와 함께 문제를 찾고, 이를 통해 비슷한 문제를 겪었던 사람들에게 도움이 되길 바랬는데.. (Spring 기여자가 되고 싶은 마음이 제일 크긴하다) 아쉽지만 다음 기회를 노려야겠다 ㅎㅎ

결국에는 countQuery를 직접 입력하여 inlineView 쿼리문을 작성할 수 있었고 이를 통해 기존 쿼리 응답의 경우 822.2ms, 수정된 쿼리의 경우 489.9ms 로 67.83%의 성능 개선을 얻을 수 있었다

성능 개선율은 아래의 위키 페이지를 참고했다.

https://zetawiki.com/wiki/%EC%84%B1%EB%8A%A5_%EA%B0%9C%EC%84%A0%EC%9C%A8

개요

회사에서 쿼리작성도중 From절 Subquery가 필요한 상황이 있었는데, 서비스가 Spring Data JPA를 사용하고 있었는데, 아직 자료가 많이 없는 상황이라 도움이 되기를 바라며 쿼리를 작성한 경험을 공유하고자 글을 쓴다.

JPA에서의 From절 Subquery 사용가능 여부 확인

JPA에서 From절 Subquery로 많은 검색을 해봤지만, 쓸만한 내용이 없었고 검색 결과에 가장 많이 보이는 내용은
JPA의 한계라는 내용이었다. 많은 글에서 JPA는 From절 Subquery를 지원하지 않는다는 내용을 볼 수 있었고, 그 중 Hibernate 6.1 버전에서 Subquery에 관한 지원이 추가되었다는 사실을 알게 되었다.

이 사실을 통해 hibernate 문서를 뒤졌고, from절에서 subquery를 사용하는 예제를 찾을 수 있었다.

하지만, 현재 Spring Data JPA 버전에서 6.1버전 이상의 Hibernate를 사용했는지 여부를 확인해야 했기에, 프로젝트 내부에서 버전 정보를 확인했다.

보시다시피 Hibernate6.4.1 버전을 사용하고 있었기에, 충분히 JPA로 쿼리를 생성할 수 있겠다는 결론을 내렸고, From절 Subquery를 만들어 보기로 했다.

From 절 Subquery 작성

테스트를 위해 기존에 JPA 학습을 위해 생성한 레포지토리 내에서 몇가지를 수정하여 테스트를 시작했다.
파일 구성은 아래에 소개한다.

테스트 파일을 작성 할 수도 있겠지만, 있었던 controller를 수정하는 것이 더 빠를것 같아서 Controller를 아래처럼 수정했다.

package com.hyeonwoo.spring.jpa.springjpa;

import com.hyeonwoo.spring.jpa.springjpa.domain.Address;
import com.hyeonwoo.spring.jpa.springjpa.domain.Member;
import com.hyeonwoo.spring.jpa.springjpa.service.MemberService;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;

import java.util.ArrayList;

@Controller
@RequiredArgsConstructor
public class HelloController {
    private final MemberService memberService;

    @GetMapping("test")
    public void test(Model model) {
        memberService.testSpringMember();
    }

    @GetMapping("insert")
    public void insert() {
        Member a = new Member(1L,"박현우", new Address("Seoul", "Main Street", "12345"));
        Member b = new Member(2L,"차은우", new Address("Seoul", "Main Street", "12345"));
        Member c = new Member(3L,"장원영", new Address("Seoul", "Main Street", "12345"));
        Member d = new Member(4L,"카리나", new Address("Seoul", "Main Street", "12345"));
        Member e = new Member(5L,"홍윤기", new Address("Seoul", "Main Street", "12345"));

        memberService.insertTestDataSet(a);
        memberService.insertTestDataSet(b);
        memberService.insertTestDataSet(c);
        memberService.insertTestDataSet(d);
        memberService.insertTestDataSet(e);
    }
}

아래는 Service 클래스이다.

Service 클래스에서는 Spring Data JPA를 통해 쿼리를 생성하는 방법과 Entity Manager를 직접 다루는 방법 두가지를 시도해보았다.

package com.hyeonwoo.spring.jpa.springjpa.service;


import com.hyeonwoo.spring.jpa.springjpa.domain.Address;
import com.hyeonwoo.spring.jpa.springjpa.domain.Member;
import com.hyeonwoo.spring.jpa.springjpa.repository.MemberRepository;
import com.hyeonwoo.spring.jpa.springjpa.repository.SpringMemberRepository;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.ArrayList;
import java.util.List;

@Slf4j
@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class MemberService {

    private final MemberRepository memberRepository;
    private final SpringMemberRepository springMemberRepository;

    public void testSpringMember() {
        List<Member> test = springMemberRepository.findByInlineViewTest("박현우");
        log.info(test.toString());
        // EXCEPTION
    }

    public void testMember() {
        List<Member> test = memberRepository.findByInlineViewTest("박현우");
        log.info(test.toString());
        // EXCEPTION
    }

    @Transactional
    public void insertTestDataSet(Member a) {
        springMemberRepository.save(a);
    }
}

아래는 Spring Data JPA를 통해 서브쿼리를 사용해보는 Repository 예제 코드이다.

Select 조건에 new Member라는 생성자를 통해 데이터를 삽입했는데, 생성자를 사용하지 않을 시 오류가 발생하여 아래의 StackOverflow 포스팅을 참고했다.

https://stackoverflow.com/questions/67500203/failed-to-convert-from-type-java-lang-object-to-type-org-springframework-d

package com.hyeonwoo.spring.jpa.springjpa.repository;

import com.hyeonwoo.spring.jpa.springjpa.domain.Member;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Query;
import org.springframework.data.repository.query.Param;

import java.util.List;

public interface SpringMemberRepository extends JpaRepository<Member, Long> {

    @Query("SELECT new Member(T.id as id,T.name as name,T.address as address) FROM (SELECT T2.id as id,T2.name as name,T2.address as address FROM Member T2 WHERE T2.id = 1) T")
    List<Member> findByInlineViewTest(@Param("name") String name);
}

EntityManager를 사용하여 쿼리를 생성한 예제이다.

package com.hyeonwoo.spring.jpa.springjpa.repository;

import com.hyeonwoo.spring.jpa.springjpa.domain.Member;
import jakarta.persistence.EntityManager;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Repository;

import java.util.List;

@Repository
@RequiredArgsConstructor
public class MemberRepository {

    private final EntityManager em;

    public List<Member> findByInlineViewTest(String name) {
        return em.createQuery("SELECT T.id, T.name, T.address FROM ( SELECT T2.id as id,T2.name as name,T2.address as address FROM Member T2 WHERE T2.id = 1) T WHERE T.name = :name", Member.class)
                .setParameter("name", name)
                .getResultList();
    }
}

마지막으로 Entity 클래스이다. 특별한 내용은 없다.

package com.hyeonwoo.spring.jpa.springjpa.domain;

import jakarta.persistence.*;
import lombok.*;

import java.util.ArrayList;
import java.util.List;

@Entity
@Getter @Setter
@RequiredArgsConstructor
@AllArgsConstructor
public class Member {

    @Id @GeneratedValue
    @Column(name = "member_id")
    private Long id;

    private String name;

    @Embedded
    private Address address;

}

package com.hyeonwoo.spring.jpa.springjpa.domain;

import jakarta.persistence.Embeddable;
import lombok.Getter;

@Embeddable
@Getter
public class Address { // 값 타입은 변경 불가능하게 설계해야 한다.
    private String city;
    private String street;
    private String zipCode;
    protected Address(){} // 임베디드 타입은 자바 기본 생성자를 public 또는 protected로 설정해야 한다.


    // Setter를 사용하지 않고 생성자에서 값을 모두 초기화 해서 변경 불가능한 클래스로 제공
    public Address(String city, String street, String zipCode) {
        this.city = city;
        this.street = street;
        this.zipCode = zipCode;
    }
}

위처럼 파일 세팅 후 H2 데이터베이스에 데이터를 임시로 삽입하는 API를 호출했고, 이후 서브쿼리를 통해 데이터를 조회하는 부분에서 디버깅을 통해 데이터가 잘 들어오는지 확인할 수 있었다.

알게된 점

• hibernate 6.1버전 이상에서는 JPA를 통해 From 절 Subquery SQL을 작성 할 수 있다.
• Subquery 작성 시 alias를 작성하지 않으면 이름을 찾지 못하는 오류가 있는 것 같다. 예제에서도 alias가 필수적으로 붙어있는 이유로 보인다.
• Entity 타입으로 데이터를 조회할 수 있었지만, class Projection을 통해서는 데이터를 수신하는데 실패하고 있다. 이 부분은 좀 더 확인해보고, 공유할 만한 내용이 있다면 공유할 생각이다.

https://in.relation.to/2022/06/14/orm-61-final/

https://docs.jboss.org/hibernate/orm/6.1/userguide/html_single/Hibernate_User_Guide.html

개요

개인 프로젝트 기획 중 Google Colab을 통해 생성한 모델에서 API를 통해 프롬프트를 전달하고, 해당 정보로 API를 호출하는 서비스를 만들기 위해서 Stable Diffusion WebUI에서 API 호출을 확인해야 했다. 이를 어떻게 해결했는지 공유하고자 글을 작성한다.

API  호출하기

API를 호출하기 위해서는 검색해보니 python 코드를 수정해야 한다는 내용을 몇가지 찾을 수 있었는데, 별도의 코드 수정없이 간단하게 API를 호출할 수 있는 주소를 알아낼 수 있었다. 바로 Stable Diffusion WebUI 하단에 API를 클릭하면 사용가능한 API 목록을 swagger를 통해 알 수 있다.

Swagger 페이지를 통해 내가 호출하고자 하는 API를 확인했고, 나의 경우 txt2img API를 호출하기 위한 정보를 찾아봤다.

하지만 많은 파라미터가 있어 내가 설정했던 방법을 간단히 살펴보자.

{
  "prompt": "sparkling eyes, giving a playful, resembling a fantasy or magical theme, The character has a joyful and friendly expression, with a child-friendly design that uses soft curves and bright, smooth textures", // 프롬프트
  "negative_prompt": "Avoid dark or muted colors, no sharp or aggressive features, no realistic textures, avoid mature themes, no complex backgrounds, no human-like proportions, no gothic, horror, or creepy aesthetics, avoid exaggerated shadows or dramatic lighting, and no realistic animal features", // Negative 프롬프트
  "styles": [
    ""
  ],
  "seed": -1, // 시드 (-1 : 랜덤)
  "subseed": -1,
  "subseed_strength": 0,
  "seed_resize_from_h": -1,
  "seed_resize_from_w": -1,
  "sampler_name": "DPM++ 2M", // 샘플러 name
  "scheduler": "",
  "batch_size": 1,
  "n_iter": 1,
  "steps": 20, // Sampling Steps
  "cfg_scale": 7,
  "width": 512,
  "height": 512,
  "restore_faces": false, // default true여서 false로 변경
  "tiling": false, // default true여서 false로 변경
  "do_not_save_samples": false,
  "do_not_save_grid": false,
  "eta": 0,
  "denoising_strength": 0,
  "s_min_uncond": 0,
  "s_churn": 0,
  "s_tmax": 0,
  "s_tmin": 0,
  "s_noise": 0,
  "override_settings": {
      "sd_model_checkpoint": "Hyeonwoo/Hyeonwoo_5200.safetensors [d85b89c9ef]" // 사용할 model check point
  },
  "override_settings_restore_afterwards": true,
  "refiner_checkpoint": "",
  "refiner_switch_at": 0,
  "disable_extra_networks": false,
  "firstpass_image": "",
  "comments": {},
  "enable_hr": false,
  "firstphase_width": 0,
  "firstphase_height": 0,
  "hr_scale": 2,
  "hr_upscaler": "string",
  "hr_second_pass_steps": 0,
  "hr_resize_x": 0,
  "hr_resize_y": 0,
  "hr_checkpoint_name": "",
  "hr_sampler_name": "",
  "hr_scheduler": "",
  "hr_prompt": "",
  "hr_negative_prompt": "",
  "force_task_id": "",
  "sampler_index": "Euler",
  "script_name": "",
  "script_args": [],
  "send_images": true,
  "save_images": false,
  "alwayson_scripts": {},
  "infotext": ""
}

위와 같이 설정 후 Stable Diffusion Web UI를 통해 생성한 데이터와 거의 비슷한 결과값을 얻을 수 있었다.

응답값은 image base64 인코딩 데이터와 생성에 사용된 메타데이터들이 응답으로 왔었고, 이미지 데이터는 base64 디코딩 사이트를 통해 확인할 수 있었다.

API를 통해 생성된 이미지

Stable Diffusion Web UI를 통해 생성된 이미지

Stable Diffusion Web UI를 사용할 때, DreamBooth extension이 정상적으로 설치된 경우 다음과 같이 Train 카테고리 옆에 표시 되어야 한다.

하지만 어느날부터 DreamBooth 카테고리가 사라져서 보였고, Stable Diffusion Web UI 실행 시 아래의 로그를 얻을 수 있었다.

*** Error executing callback app_started_callback for /content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions/sd_dreambooth_extension/scripts/api.py
    Traceback (most recent call last):
      File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/modules/script_callbacks.py", line 256, in app_started_callback
        c.callback(demo, app)
      File "/content/gdrive/MyDrive/sd/stable-diffusion-webui/extensions/sd_dreambooth_extension/scripts/api.py", line 534, in dreambooth_api
        model_cfg: DreamboothConfig = Body(description="The config to save"),
    NameError: name 'DreamboothConfig' is not defined

 위의 내용으로 chatGPT에게 물어본 결과, DreamBooth를 실행하기 위한 의존성의 문제처럼 보인다고 한다.

또한, 아래의 명령어를 알려주었다.

!pip install -r /path/to/requirements.txt

난 현재 Google Colab에서 Stable Diffusion을 사용하고 있었기에, sd/stable-diffusion-webui/extensions/sd_dreambooth_extension/requirements.txt 경로에서 해당 파일을 얻을 수 있었다.

requirements.txt 파일 선택 후 경로 복사를 해준다.

이후 임의의 위치에 코드 삽입 후 경로를 붙여넣고 실행시켜준다.

실행이 완료되었다면 Stable Diffusion Web UI 재시작 해주면 정상적으로 표시된다.

Github Foundations이 무엇이냐

https://gogoadl.tistory.com/166

글에서 짧게 소개했지만, Github Foundations Github에 대한 기초적인 지식을 검증하는 자격증을 따기 위해 며칠간 공부 했었고, 후기를 남기고자 글을 쓴다.

왜 Github Foundations?

1. 국내에서 Github Foundations를 가진 사람을 아직 본적이 없다. 1등으로 해보고 정보를 공유하고 싶었다.
2. Git 이라는걸 참 좋아하고 잘 사용한다고 생각해서, 스스로 증명하고자?
3. 자격증 비용이 꽤나 저렴했다. 99$로 표시되지만 실제 결제를 하니 의문의 바우처가 적용되어 45$ + 4.5$ 세금으로 총 49.5$에 자격증 시험을 볼 수 있었다.

좋았던 점

1. Github Foundations를 공부하면서 또다른 Open Source Contributor와의 접점이 생겼다.
2. Github의 다양한 기능들을 구경할 수 있었다. (submodule, issue form)
3. 아직 Github Foundations를 가진사람을 못봐서 약간 멋이난다.

안좋았던 점

1. 결제를 하면서 알았는데, 해당 시험은 non-protctored exam 이다. 컨닝해도 된다..
2. 번역 기능이 제공되지 않아서 영어에 익숙하지 않으면 굉장히 어렵다..
3. ghcertified와 같은 덤프 사이트의 문제로는 조금 버겁다. 확실히 자료가 부족한만큼 시험 난이도가 어렵게 느껴졌다.
4. 결제 할 때에도 한국 전화번호가 사용 불가능해서, 전화번호 인증 없이 바로 다음 섹션으로 넘어 갔었다. 전체적으로 영어권이 아니라면 불친절하게 느껴질 수 있다.

그래서, 추천하나?

나는 굳이 github foundations 자격증을 추천하지 않겠다. 감독관이 없는 시험은 크게 메리트가 있다고 느껴지진 않는다. 또한, Github는 git을 주요 기술로 사용하는 다양한 플랫폼 중 하나이다. (Github, Gitlab, Bitbucket..) 따라서 플랫폼마다 조금씩의 차이점이 있고, 회사에따라 각각 다른 플랫폼을 사용한다. 그래서 크게 인정받을 수 있는 자격증인가..는 잘 모르겠다.

그래도 Github Foundations를 통해 얻는점도 있었고, 블로그에 글을 쓸 수 있으니 좋다~

그리고 진짜 어렵다.. 영어 읽는데 한세월이고, 덤프에 없는 문제들이 많아서.. ㅠㅠ

자랑

이제 Credly 뱃지가 두개가 되었다! 유후~