공부하자

• 3차 프로젝트: GameLog 회고 팀별로 프로젝트 회고를 진행했다. 이번 프로젝트에서 좋았던 점은 AI와 스킬을 적극적으로 활용해볼 수 있었다는 것이었다. 구현과 코드 정리에 도움을 받았지만, 생성된 양이 많아질수록 검토가 어려워졌다. 직접 확인한다고 하면서도 일부는 대충 넘어갔던 점이 아쉬웠다. 테스트도 돌아봤다. AI를 활용하면서 불필요한 테스트까지 많이 작성한 것 같았고, GitHub CI 실행 시간도 길어졌다. 앞으로는 테스트의 목적과 중복 여부를 확인하고, 매번 실행할 테스트와 별도로 실행할 테스트를 구분할 필요가 있다고 생각했다. Kotlin의 특징을 더 이해하고 사용했으면 좋았겠다는 아쉬움도 있었다. 호환 코드가 여전히 남아 있다는 피드백을 받으며, 전환된 코드를 읽고 판단할 수 있는 이해가 필요하다고 느꼈다. 다음에는 AI.. 2026.10.30
• 3차 프로젝트: GameLog - 마무리 이날은 발표 자료를 정리하고 팀 발표를 진행했다. PPT는 작업한 코드와 팀원별 담당 기능을 바탕으로 AI를 활용해 초안을 만든 상태였다. 초안이 있어 시작하기는 편했지만, 그대로 발표에 사용하기에는 손볼 부분이 있었다. 어려운 용어가 들어간 문장도 있었고, 한 장에 글이 많아 내용을 한눈에 파악하기 힘든 부분도 있었다. 자료를 보면서 표현을 쉽게 바꾸고, 글이 많은 부분은 핵심만 남기도록 정리했다. 발표자가 말로 설명할 내용까지 슬라이드에 모두 넣으면 오히려 보기 어려웠다. 어떤 내용을 화면에 남기고 어떤 내용을 말로 전달할지 나눠야 했다. 발표자 대본도 함께 다듬었다. 슬라이드에 적힌 문장을 읽는 것과 실제로 말하는 것은 달랐다. 글로 보면 괜찮았던 표현도 소리 내어 설명하려고 하면 길거나 어색하게 .. 2026.10.29
• 3차 프로젝트: GameLog - 알림 서비스 직접 호출로 변경 이날은 알림 처리 구조를 수정했다. 좋아요나 팔로우 같은 작업과 알림 저장 사이의 트랜잭션 경계를 분리하는 작업이었다.기존에는 이벤트를 발행하고 리스너에서 알림을 저장했다. 하지만 이벤트를 사용한다고 해서 원래 작업과 알림 처리가 자동으로 분리되는 것은 아니었다. 기존 리스너는 동기적으로 실행되며 원본 트랜잭션에 참여하는 구조였다.알림 저장 중 문제가 생기면 좋아요나 팔로우까지 실패할 수 있었다. 알림은 사용자의 활동을 알려주는 기능인데, 알림을 저장하지 못했다는 이유로 원래 활동까지 취소되는 구조를 수정했다.원본 작업이 성공한 뒤 알림을 저장하도록 수정이벤트 발행과 리스너 대신 각 서비스에서 알림 서비스를 직접 호출하도록 변경했다. 호출하는 코드에서 어떤 알림을 요청하는지 확인할 수 있도록 했다.다만 .. 2026.10.29
• 3차 프로젝트: GameLog - 알림 서비스 추가 사용자 활동 알림을 추가하고, 사용자 게임 도메인의 프로필 기능을 분리했다. 팀에서는 Java 테스트의 Kotlin 전환과 기존 Kotlin 코드 정리도 함께 진행했다.하루 작업을 돌아보니 두 가지 질문이 연결되어 있었다. 새 기능이 기존 기능과 어떤 관계를 가져야 하는지, 그리고 기능이 늘어난 뒤 코드를 어떤 단위로 나누어야 하는지였다.알림은 생성 이후의 상태까지 설계좋아요나 댓글, 팔로우가 발생하면 알림을 저장하는 것만으로 끝날 것 같지만, 실제로는 결정할 조건이 많았다.내가 내 글에 좋아요를 눌렀을 때도 알림을 보낼 것인가? 좋아요를 취소하면 기존 알림은 어떻게 할 것인가? 댓글이나 사용자가 사라진 뒤에도 알림 링크를 유지할 것인가?이번에는 본인의 활동으로 생기는 알림을 제외하고, 취소된 활동에 대.. 2026.10.26
• 백엔드 데브코스 12기 68일차 이 날은 GameLog 3차 프로젝트의 기획서를 작성하고, Java 백엔드를 Kotlin으로 전환했다. 먼저 AI를 활용해 운영 코드를 한 번에 전환한 뒤, 각자 맡은 기능의 코드를 직접 살펴보며 기존 동작이 유지되는지 검증했다.생각보다 AI가 코드를 잘 바꿔줘서 놀랐다. 프로젝트 전체를 전환하는 작업을 빠르게 진행할 수 있었고, 덕분에 변환된 코드의 구조와 동작을 확인하는 데 집중할 수 있었다.다만 그대로 사용하기에는 정리할 부분이 남아 있었다. 담당한 usergame 코드를 확인하면서 불필요한 ?, Java 컬렉션 사용, 수정이 필요하지 않은데도 MutableList로 선언된 부분을 직접 바꿨다. 값이 실제로 없을 수 있는지, 컬렉션을 변경할 필요가 있는지를 기준으로 타입을 정리했다.변경 후에는 관련.. 2026.10.22
• 백엔드 데브코스 12기 67일차 이 날은 터미널에서 Bash 명령어를 직접 사용하며 파일과 디렉토리를 관리하는 방법을 실습했다. pwd, ls, cd로 현재 위치를 확인하고 이동했으며, 파일 생성·복사·이동·삭제 명령어도 익혔다.또한 find와 grep으로 필요한 파일과 내용을 검색하고, ps와 kill로 프로세스를 확인하고 종료하는 방법을 배웠다. 명령어를 직접 실행하고 결과를 확인하니 각각의 역할을 이해하기 쉬웠다.앞으로도 터미널을 꾸준히 활용하면서 익숙해지고, 삭제나 덮어쓰기 작업 전에는 경로와 대상을 확인하는 습관을 들여야겠다. 2026.10.21
• 백엔드 데브코스 12기 66일차 이 날은 기존 Java 프로젝트의 회원, 게시글, 댓글 Controller와 관리자용 Controller를 Kotlin으로 전환했다. 앞서 공통 처리와 서비스 영역을 바꿨다면, 이번에는 사용자의 요청을 받고 응답을 반환하는 부분까지 전환 범위를 넓혔다.회원가입과 로그인, 게시글·댓글의 조회 및 수정 기능을 옮기면서 Controller가 서비스와 연결되는 흐름을 다시 살펴봤다. 필요한 객체는 주 생성자로 전달받고, 요청과 응답 데이터는 data class로 표현했다. 기존 기능을 유지하면서 Kotlin 문법으로 구조를 정리하는 과정이었다.게시글 요청 데이터에서는 @field:NotBlank, @field:Size처럼 검증 어노테이션의 적용 대상을 명시했다. Java에서 사용하던 어노테이션도 Kotlin으로.. 2026.10.19
• 백엔드 데브코스 12기 65일차 이 날은 전날에 이어 Java 기반 Spring Boot 프로젝트를 Kotlin으로 전환했다. DTO와 요청 처리 클래스에서 시작했던 작업을 보안 설정, 인증 필터, 예외 처리 등으로 확장하면서 프로젝트 전반에서 공통으로 사용하는 코드의 역할을 살펴봤다.먼저 Spring Security 설정과 사용자 인증 정보를 담는 클래스를 Kotlin으로 바꿨다. 보안 설정에서는 Kotlin DSL로 URL별 접근 권한을 표현했고, 인증 필터에서는 헤더와 쿠키에서 인증 정보를 가져와 사용자를 확인하는 흐름을 살펴봤다. 코드를 옮기는 과정에서 API 키와 액세스 토큰이 어떻게 사용되고, 인증된 사용자 정보가 어디에 저장되는지 정리할 수 있었다.전환 과정에서 발견한 문제를 수정하며 Kotlin의 프로퍼티와 null 처리.. 2026.10.16
• 백엔드 데브코스 12기 64일차 이 날은 기존 Java 기반 Spring Boot 프로젝트를 Kotlin으로 점진적으로 전환하는 방법을 배웠다.먼저 Kotlin을 사용할 수 있도록 Gradle에 플러그인과 의존성을 추가하고, Spring과 JPA를 위한 설정을 구성했다. 기존 프로젝트에 Kotlin을 도입할 때는 코드의 문법을 바꾸는 것뿐 아니라, 프레임워크와 함께 동작할 수 있는 환경을 준비하는 과정도 필요하다.이후 애플리케이션의 시작점과 HomeController를 Kotlin으로 바꾸고, 회원·게시글·댓글 DTO와 공통 응답 객체, 요청 처리 클래스도 차례로 전환했다. DTO에서는 data class와 주 생성자를 활용해 필요한 데이터를 한눈에 볼 수 있도록 표현했다. Java 코드와 비교하면서 Kotlin의 프로퍼티와 생성자가 .. 2026.10.14