2026-05-08 일지

Spring AOP 관리가 쉬운 코드, 유지보수가 좋은 코드를 짜는 것이 중요, 코드의 재사용성을 높이고 중복도 최소화할 수 있는 방향으로 짜게 된다. 이를 위해 선언형 프로그래밍, 함수형 프로그래밍 등의 방법이 존재한다. 유지보수적 지향으로 프로그램을 짜게 되는 것이 있는데 그 중 하나가 관점지향 프로그래밍 Aspect object Programming이다. 어노테이션으로 관리를 하게되는데 이것의 원리가 관점지향 프로그래밍이다. 로깅에 관한 관리가 필요하다. 그 로깅에는 AOP가 들어갈 수 밖에 없다. 이것을 정확하게 이해를 할 필요가 있다. 관점지향 프로그래밍 커진 단위를 모듈단위로 구분을 하는데 레이어 단위로 구분을 하게 된다. mvc패턴을 사용하게 된다. 우리가 서블릿을 만들었을 때 이것을 보완하기 위해 나온것이 스프링, 스프링 부트이다. 4버전이라는 것은 새로운 방식을 받아드리고 업그레이드를 할 필요가 있다. 프로젝트가 복잡해졌을때 수행하는 것이 모듈화와 레귤러화이다. 이러한 모듈화로 해결하기 힘든 것이 반복되는 코드를 분리하는 것이다. 어떤 애플리케이션을 개발하던지 로깅을 할 필요가 있다. 시간과 같은 스톱워치를 포함한다. 웹에서는 요청이 들어왔을때 요청을 수행하고 내보내느 시점을 기록하게 된다. 요청이 튄다?는 경우가 존재하는데 여기서 30ms에서 줄어든다면 느려지는 것이다. 이러한 것을 기록하는 로깅을 하기 위해서는 어떤 것이든 로그를 만들 필요가 있다. 트랜잭션을 확인하는 것은 로깅이 중복된다. 여러 메서드이건 클래스이건 반복적으로 사용되어야 한다. 코드 여러곳에 퍼져있으면 누적이되고 유지보수성이 떨어지고 가독성이 떨어진다. 이를 위한 것이 관점지향 프로그래밍이다. 프로그램을 객체단위로 나누어서 나타낸다고 하면 프로그래밍 관점으로 분리를 하게된다. 관심사 하나의 프로그램에는 여러가지 관심사가 존재한다. 여러가지 관심사를 따로 만들어두고 적용하자어떤 기준으로 나눌 수 있을지 살펴봐야 와닿을 수가 있다. 관심사가 뭔지 살필 필요가 있다 횡단 관심사와 주 관심사가 있다. SW개발에서는 하나의 프로그램이 다양한 기능을 수행할 수 있는데 이것을 두가지로 나누면 주관심사와 횡단 관심사이다. 주 관심사 : 주된 기능 예: POST → 게시글 POST → 게시글 COMMENT→댓글 횡단 관심사 같은 경우는 트랜잭션이 적용되어 있지 않은경우랑 트랜잭션에 관한 작업 정의되지 않은 경우 우리는 그에 관한 처리가 된다. 또한 주관심사가 다루는 비지니스 로직이 이루어지는 과정도 하나의 트랜잭션이 된다. 애플리케이션의 관점도 주문에 관한 작업, 주문 아이템에 관한 관점이 있었다고 하면 롤백이 되면 다시 원래대로 돌릴 필요가 있다. 트랜잭션의 경우 비지니스 로직도 적용이 되는데 비지니스 로직을 롤백할 경우 다른 웹에 이에 관한 내용을 뿌릴 필요가 있다. 이렇게 여러 도메인에서 사용되지만 공통으로 적용되는 로깅, 트랜잭션 관리, 예외처리, 보안과 같은 것이 횡단관심사가 될 수가 있다. 한마디로 말하자면 애플리케이션 공통으로 적용하는 것이 횡단 관심사이다. 보안검사, 트랜잭션, 로그 -> 횡단 관심사 비지니스 로직 -> 주관심사 AOP는 이를 분리하는 기능을 제공해준다. AOP는 횡단 관심사를 코드에서 분리할 것을 제공해준다. 이를 관점지향 프로그래밍의 정의라고 볼 수 있다. 관심사가 뭔지 관심사를 분리할 줄 알아야 한다. 같은 물건을 관점을 다른 것으로 보고 있기 때문에 겹쳐 보이는 것이다. 객체지향 프로그래밍에서 자바에서 함수형 프로그래밍을 지원을 해주지만 엄밀히 말하면 아니긴하다. 함수형 인터페이스를 지원해주는 것이다. 자바는 객체지향 프로그래밍인데 주관심사를 클래스와 메서드로 나누어서 설계를 하게된다. 주관심사라는 친구는 가장 먼저 고려해야 되는 친구가 된다. AOP에서도 가장 먼저 보호를 해야한다. 횡단 관심사는 프로그램 여러곳에서 공통적으로 사용되지만 특정한 한 기능으로 속하지는 않는다. 전체 시스템에서 반복적으로 나타난다. 여기서 되는 것은 로깅과 트랜잭션이 필요하다. 공통적으로 나타나고 반드시 되어야 하는 것은 횡단 관심사가 된다. 이처럼 코드의 중복이 많이 일어나는 것을 분리하고 모으는 것도 AOP의 관점 중 하나이다. 관심사는 Concern이다. cutting은 자르는 뜻이 있다. Cross-Cutting Concerns 이 용어가 중요하다. 이 AOP에 관한 것을 어노테이션으로 제공하고 있다. Aspect 본질적인 작업과 부가적인 작업을 나누어서 생각할 수가 있다. 요리를 할 것이면 요리를 할 때 요리 자체가 핵심 요리가 된다. 부가적인 작업을 하나로 모듈화 해놓은 것이라고 봐도 된다. 반복적인 로직을 모아두고 특정시점에 한번에 시행되게 하는 것이다. 로그를 찍고 트랜잭션을 관리하고 하는 것을 하나의 Aspect라고 하고 특정시점을 지나면 이것을 진행하는 방식으로 진행된다. 핵심 로직은 건드리지 않고 로그, 트랜잭션, 권한 검사 같은 공통 기능을 분리해서 적용하기 위한 구조 spring에서는 aspect라는 어노테이션이 있다. 이 어노테이션을 통해 로직을 묶고 진행을 하게된다. advice advice는 aspect가 진행할 로직 aspect가 코드 뭉치이자 핵심개념이라고 보면 되고 이것을 실행하는 시점이 advice이다. Advice는 특정 시점에 실행되는 부가 기능 로직이라고도 생각해도 된다. afteradvice(@After), beforeadvice(@Before), afterThrowing(@AfterThrowing) 예외 발생한 후의 시점, advice는 aspect의 실행 시점이라고 봐도 된다. 간단한 Advice 종류 정리 Before Advice 메서드 실행 전 동작 ex: 로그동작, 권한 검사 @Before After Advice 메서드 끝난 후 동작 성공/실패 관계없이 동작 @After After Returning Advice 메서드가 정상적으로 종료된 후 실행 ex: 성공로그기록, 반환값처리 @AfterReturning After Throwing Advice 예외가 발생했을 때 실행 ex: 에러 로그 저장 @AfterThrowing Around Advice 메서드 실행 전후를 모두 제어가능 ex: 실행시간 측정, 트랜잭션 처리 @Around PointCut 우리가 모든 서비스 클래스에 메서드를 나뭇가지라고 한다면 pointcut은 위치라고 봐도 된다. 어느 시점에 어느 위치에 있는 aspect를 실행시킬때 pointcut이 수행된다. Spring AOP에서는 Pointcut을 지정할 때 주로 execution() 표현식을 사용한다. @Before("execution(* com.example.service.*.*(..))") 이런 식으로 진행을 하게된다. 참고 이 안에서 spel (spring espect language)에 있는 표현언어와 DSL(Domain Specific Language)를 공부하는 것이 좋다. spel을 공부하게 되면 dsl을 사용하고 이해하는 것이 좋아진다. 패키지 이름규칙, 어노테이션 이름규칙, 등 어떤대상의 이 aspect를 넣을 것인지를 정할 수가 있다. target Object Aop의 적용의 대상이 되는 object 프록시 패턴을 가지고 원본 패턴의 시작시점을 알 수가 있다. 상속을 이용한 방법, 리플렉션을 캐치해나가는 방면 이렇게 두가지 존재한다. 스프링에서는 상속방식이 쓰였으나 지금은 cglib라는 라이브러리를 통해서 동적 프록시를 제공하고 있다. Join Point aop가 실행될 수 있는 모든 시점, 지점이라고 보면 된다. pointcut이랑 비슷한 개념, pointcut이 join point를 잡아주는 것 Weaving 뭔가를 꿰메다는 의미로 aspect를 aop에 적용시켜서 진행하는방법이다. 프록시 패턴 스프링 AOP에서 관점이고 개념이다. 스프링에서는 이 AOP를 어떻게 구현했는가? 어떻게 이 코드를 변경하지 않고 가로채는데 성공할 수 있었나 public interface Service { void logic(); } public class RealService implements Service { @Override public void logic() { System.out.println("실제 로직 수행"); } } public class ProxyService implements Service { private final Service target; public ProxyService(Service target) { this.target = target; } @Override public void logic() { long start = System.currentTimeMillis(); System.out.println("프록시: 로직 실행 전"); target.logic(); System.out.println("프록시: 로직 실행 후"); long end = System.currentTimeMillis(); System.out.println("실행 시간: " + (end - start)); } } 프록시패턴은 대리인이다. 대신 무언가를 하는 사람이다. 프록시 패턴은 원본패턴을 대신할 무언가를 준 다음에 수행하는 것이다. 일을 시켰는데 일을 대신하는 존재, 일을 연예인하게 맡기면 매니저가 수행하는것과 비슷하게 흘러간다. 프록시 객체에 일을 지정하면 실제 일은 실제 객체가 직접 수행한다. 리얼 액터는 실제로 해야 할 일을 여기서 구현을 하는 것, 실제 액터를 품고 있다. 똑같은 기능을 구현하는데 부가적으로 일을 수행한 다음 실제 객체에다가 넘겨주는 것, 이것을 라이브러리에 사용하는 것을 보면 여러가지로 실행됨을 볼 수가 있다. JDK 동적 프록시, JDK Dynamic Proxy 프록시를 동적으로 만들 필요가 있다. AOP를 적용하여 로그를 남기는 기능을 추가하는 것을 추구하고 싶다면 동적으로 프록시 객체를 만들고 추가하는 방향으로 해주자. 스프링에서는 aop를 위해 CGLIB방식으로 전부다 바뀌었다. cglib는 인터페이스가 필요가 없다. 또한 @entity는 파이널이 붙은 클래스는 쓸 수가 없다 final이 붙은 상수는 상속이 되지 않는다. 자바는 상수가 없다. 상수형 변수로는 자바에서 값의 재활동을 막아놓는다. final이 붙으면 CGLIB를 할 수 가 없다.

Today I Learned · 2026-05-08

2026-05-07 일지

서론 프로젝트를 진행하면서 느낀 것과 피드백 받은 것을 간단하게 정리를 해보도록 하겠다. 발표 준비 일단 다른 팀원들이 구상해놓은 것에 대해 알아야 하고 구현한 핵심로직에 대해 설명을 해야겠다. 카테고리 모달바를 구현할 때 js를 활용하고 ajax를 통한 연동 사용 게시글 CRUD postId로 기존 게시물 탐색 Category.postMap에서 remove를 하게 된다. 물리 삭제 방식이라고 봐도 무방 현재 구조상 중요한 탐색 로직 게시글과 소속 카테고리를 함께 찾고 이를 수정 ,삭제, 카테고리 변경에 사용된다. 작성 요청이 Controller -> Service -> Repository -> Thymeleaf 로 흐름이 구성된다. 댓글 대댓글 댓글을 id, content, createdAt, updateAt 대댓글을 구사할 때 parentId, depth를 활용하여 tree구조를 갖게 된다. 게시판 리스트, 페이징 다음페이지 이전페이지를 반환하는 방식으로 구현 프로젝트 리뷰, 고쳐야 할 점 MemoryRepository로 레포지토리를 하나로 관리하는 것은 solid원칙을 위배하는 것 리포지토리는 인메모리 구조로 실행해서 설계 때 하나의 리포지토리를 두어도 큰 문제가 되지 않을 것이라고 생각했다. 하지만 이렇게 프로젝트를 시작하니 이후 리포지토리에 작성해야 할 코드를 충돌이 걱정되어서 다른 곳에 작성하는 일, 등 코드에 접근하기 꺼려지는 경향이 있다. 기능을 분리하고 도메인을 분리하지 말고 반대로 도메인부터 분리하자. 지금은 service, model, repository 이렇게 3개로 분류하고 안에서 각 도메인에 관한 것을 구현했다. 하지만 Comment , Post, PostList, Category 이렇게 도메인을 먼저 분리하고 그 안에서 service, model, repository를 구현하고 시행할 필요가 있다. Git을 너무 활용하지 않았다. 커밋메시지는 무조건 준수할 것 커밋할 때는 무조건 커밋메세지 양식을 지키도록 하고 여기에 대해 소통이 필요했던 것 같다. → 다른 사람이 내 커밋 메시지를 보더라도 그 의도를 알 수 있을 정도까지만 쓰는 것이 좋다. issue를 만들고 이에 관해 글을 정리하는 것을 하지 않았다. 문제가 있으면 이에 관해 소통하는 것이 필요했던 것 같다. project 활용이 적었다. 각 기능별로 구현하고 구현해야 할 기능에 맞게 branch를 만들어서 올리고 pull request를 수행할 때 코드리뷰를 시행했어야 했는데 이에 관한 것을 구두로만 해결하고 따로 comment에 적은 것이 없어서 안좋았다. URL에 id를 넣어서 전송을 하고 있다. 이 경우 데이터 캡슐화가 필요하고 DTO가 필요하다. DTO없이 넘기고 있는데 DTO를 만들어서 사용을 했어야 했다. REST에 관한 이해도를 높이도록 하자.

Today I Learned · 2026-05-07

2026-05-06 일지

대댓글 구현 서론 댓글 구현은 성공했고 이후 선택사항인 대댓글 구현에 관해 정리할 것이다. 프로젝트 동안 구현하느라 제대로 구현하지 못한 것을 정리 해볼 예정이다. 이번 프로젝트에서는 DB를 사용하지 않고 InMemory 구조로 저장을 했기 때문에 DB가 구현되지 않았다. 차이 트리 구조를 구현해야 하기 때문에 parentId가 필요하고 이후 대댓글의 깊이를 표현하기 위해 depth 값을 주어 관리하도록 했다. // 특정 게시물에 달린 댓글 목록을 조회하는 메서드 public List<Comment> getCommentsByPost(int postId) { Post post = memoryRepository.findPostById(postId) .orElseThrow(() -> new IllegalArgumentException("게시글 없음")); List<Comment> result = new ArrayList<>(); List<Comment> rootComments = post.getCommentMap() .values() .stream() .filter(comment -> comment.getParentId() == ROOT_PARENT_ID) .sorted(Comparator.comparing(Comment::getCreatedAt)) .toList(); //컨트롤러를 통해 post를 리디이렉트 시 comment를 구조에 맞게 삽입하는 기능 수행 for (Comment root : rootComments) { result.add(root); addChildren( root.getId(), post.getCommentMap().values(), result ); } return result; } // 특정 댓글에 대댓글을 추가하는 메서드 public void addReply(int postId, int parentId, String content) { Post post = memoryRepository.findPostById(postId) .orElseThrow(() -> new IllegalArgumentException("게시글 없음")); Comment parent = post.getCommentMap().get(parentId); if (parent == null) { throw new IllegalArgumentException("부모 댓글 없음"); } int depth = parent.getDepth() + 1; addCommentInternal(postId, content, parentId, depth); } // 댓글과 대댓글을 실제로 생성하고 저장하는 내부 공통 메서드 private void addCommentInternal( int postId, String content, int parentId, int depth ) { Post post = memoryRepository.findPostById(postId) .orElseThrow(() -> new IllegalArgumentException("게시글 없음")); int commentId = memoryRepository.nextCommentId(); if (commentId == parentId) { throw new IllegalStateException("댓글 id와 parentId가 같습니다."); } LocalDateTime now = LocalDateTime.now(); Comment comment = new Comment( commentId, content, now, now, parentId, depth, new LinkedHashMap<>() ); comment.setPost(post); post.getCommentMap().put(commentId, comment); MemoryRepository.comments.add(comment); } 댓글과 대댓글을 생성할때 사용하는 공통메서드는 중복요소가 있기 때문에 따로 빼서 만들어주었다.

Today I Learned · 2026-05-06

2026-05-05 일지

다시 해보는 mvc패턴 정리 서론 프로젝트를 시작하고 mvc 패턴과 내가 맡은 댓글 파트에서 구현할 비지니스 패턴에 대해 좀더 공부가 필요함을 느꼈다. mvc 패턴 애플리케이션 개발을 쉽게 하기위해 데이터, 프레젠테이션, 프로세싱을 분리 모델 핵심 데이터와 비즈니스 로직을 나타낸다 데이터 저장소와 상호작용, 데이터 처리 및 유효성 검사 수행 독립적으로 작동, 뷰와 컨트롤러와 직접 통신 x 뷰 사용자에게 보여지는 애플리케이션의 UI 일부 모델에서 데이터를 받아 사용자에게 표시 컨트롤러 사용자 입력을 처리 애플리케이션 흐름을 관리 뷰에서 전달된 사용자 입력을 분석 적절한 모델 기능을 호출, 데이터 조작 or 업데이트 다시 뷰로 전달하여 표시 비지니스 로직 처리 Controller 사용자의 요청을 Service Layer에 처리 위임, 이에 대한 결과를 View를 통해 반환받음 사용자에게 UI나 클라이언트, Response를 보내는 역할을 하는 모든 클래스를 포함한다. Client로부터 request를 받고 response를 하는 모든 API를 담는다. Service 비지니스 로직을 정의하는 레이어 담당, 서비스의 비즈니스 로직을 정의 사용자의 요청을 이행하기 위해 도메인 객체들이 협력하여 요청을 수행하도록 조정할 책임 Controller와 도메인 사이 추상화 계층을 제공 Controller가 요청한 작업을 수행하기 위해 호출할 수 있는 메소드 집합 제공 사용자로부터 전달받은 데이터를 가공하여 처리, JpaRepository를 상속하는 객체를 가져와 어떤 처리를 할 지 비즈니스 로직을 처리한다. Repository 스프링 4계층 구조에서 Infrastructure Layer 담당, 외부와의 통신 DB, 메세징 시스템 담당 해당 계층으로 부터 얻어온 정보를 ApplicationLayer 4-tier layer achitecture 사용자 인터페이스 계층 사용자에게 정보를 보여주고 사용작의 명령을 해석해주는 계층 Controller와 매핑 응용 계층 도메인 객체가 문제를 해결하게 사용 해당 계층에는 비지니스 로직 과 다른 시스템의 응용 계층 과 상호 작용을 하는 계층 Service와 매핑 도메인 계층 업무 단위의 개념, 상황에 다른 정보 , 업무의 규칙 등을 책임 지는 계층 비지니스 패턴이외의 조직이나 클라이언트의 요구를 매핑 인프라스트럭처 계층 상위 계층을 지원하는 일반화 된 기술적 기능을 제공 Repository와 매핑 테스트 코드의 필요성과 구현 필요 내 파트인 댓글 파트는 구현하려면 post가 있어야지 구현할 수 있는 것이라서 간단하게나마 테스트 코드를 구현할 필요를 느끼게 되었다. 그리고 내 코드에 대한 성능이 필요해 보여서 구현을 해보도록 했다. junit을 사용한 메서드 테스트 assertThat 사용 junit의 함수로 C언어의 strcmp를 사용과 유사하게 쓰인다. 원하는 결과가 나오면 true를 반환하고 다른경우 false가 나오게 된다. 다음은 임의로 assertThat의 결과를 false로 한 경우 나오는 실행창 결과이다. WARNING: A Java agent has been loaded dynamically (C:\Users\Admin\.gradle\caches\modules-2\files-2.1\net.bytebuddy\byte-buddy-agent\1.17.8\f09415827a71be7ed621c7bd02550678f28bc81c\byte-buddy-agent-1.17.8.jar) WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information WARNING: Dynamic loading of agents will be disallowed by default in a future release 필요:"수정 후 댓글" 실제 :"수정 전 댓글" <클릭하여 차이점 확인> org.opentest4j.AssertionFailedError: expected: "수정 후 댓글" but was: "수정 전 댓글" at io.thelogmaster.blogmaster.service.CommentServiceTest.댓글을_수정한다(CommentServiceTest.java:108) 이렇게 차이에 관해 나오게 된다. @Autowired 스프링 컨테이너에서 어노테이션으로 빈을 등록하는 방법은 크게 두가지이다. @bean을 통한 빈 등록(메서드 레벨) @Component를 통한 빈 등록(클래스 레벨) 그리고 @Component를 통해 등록된 빈은 다른 곳에서 @AutoWired를 사용해 의존성을 주입하는 것이 가능하다. 생성자 주입 클래스의 생성자에 @Autowired를 붙여 해당 클래스 타입의 필드들을 찾아 등록한다. 생성자가 하나인 경우는 @Autowired를 붙이지 않아도 자동 주입의 대상으로 인식한다. 수정할 때 Setter 주입 메서드에 @Autowired를 붙여 해당 클래스 타입의 빈을 찾아와 의존성을 주입한다. 필드 주입 코드는 간결하게 생성가능 but 인스턴스를 생성한 후에 의존성을 연결하여 순환참조가 만들어질 우려가 있다. 이경우 @primary, @Qualifier의 사용으로 우선적으로 주입할 클래스를 명시할 수가 있다. @ResponseBody의 사용 Controller의 메서드를 불러올때 가져오는 것이 뷰가 아닌 데이터인 경우 데이터는 json 데이터로 반환해야 한다. 이 경우를 위해 비동기로 데이터를 가져와 화면을 갱신하는데 사용해야 한다. CommentController의 getCommentstByPost()사용 이 경우 return하는 것이 redirection을 위한 http주소가 아닌 Comment에 관한 데이터이기 때문에 @ResponseBody를 사용해 첨부를 했다. springboot API document 참조하기 https://docs.spring.io/spring-boot/api/java/index.html gpt를 통해 테스트코드를 생성하는 중 import가 잘못되어 있는 함수가 있어서 이를 살펴보러 방문하였다. 만약 gpt에서 이상한 함수나 import가 잘못되어 있는 경우 api문서에서 확인을 받는 것도 좋은 것 같다. 참고 : ctrl + shift + r : IntelliJ에서 모두 바꾸기

Today I Learned · 2026-05-05

2026-05-04 일지

Figma 사용한 스토리보드 설계 서론 단순한 그림을 사용하는 것보다 피그마를 통해 블로그 구현에 대해 생각하고 있는 것을 공유하기 위해 사용했다. 스토리보드를 통해 해야 할 것 기본적인 레이아웃 구조 정의 기능 위치 정의 데이터 흐름 정리 위 3가지를 중점으로 실제 코딩 전 구조에 대한 논의를 완료하였다. 슬라이드 모드 단순 디자인 모드로 하는 것보다 상위 페이지에서 하위 페이지로 흘러가는 흐름을 표현할 수가 있고 이후 팀원들 간의 회의에서 활용할 자료로 활용할 수 있기에 유용하게 사용하였다. 그리고 각 기능에 대해 언급해야 할 사항 있다면 숫자 박스로 표시를 하고 이에 관한 설명을 오른쪽으로 빼서 구현하도록 했다. github를 활용한 파트정리 github 칸반보드를 통해 각자 구현하기로 한 파트를 나누었다. 칸반보드에는 내가 어떤 비지니스 로직을 구현해야 하는지에 대한 체크내용이 나와 있었고 공통 협업 규칙 주요 구현 미션 구현시 조심해야 하는 사항이 적혀져 있어서 조금 더 구상하기가 좋았던 것 같다.

Today I Learned · 2026-05-04

동현의 나불나불

Contact

2026_05_04~2026_05_08