전체 글

NotebookLM 업무에 활용하여 파편화된 문서 더미를 AI와 함께 정복한 두 가지 이야기 발표 자료 기획부터 국제 표준 요구사항 명세서 작성까지 — NotebookLM을 '보조 작가'이자 '요구사항 엔지니어'로 써본 경험을 공유합니다. 이 글은 실제 업무 프로젝트 경험을 바탕으로 작성되었으며, 일부 서비스명 및 내부 문서 세부 내용은 범용화하여 각색되었습니다.들어가며: 문서가 많을수록 막막한 이유개발자라면 이런 상황이 익숙할 겁니다. "이 프로젝트 히스토리가 다 어디 있더라? 위키에 반 쪽, 협업 도구에 반 쪽, 나머지는 퇴사자 문서함에..." 기획자도 마찬가지입니다. "SLA 계약서, 아키텍처 다이어그램, 회의록이 제각각인데 이걸 다 읽고 요구사항 명세서를 써야 한다고?" 문서가 많다는 건 그만큼 ..

서비스를 운영하다 보면 로그가 어느 순간 "너무 많은데 아무것도 알 수 없는" 상태가 된다. 우리 팀도 그랬다. 요청 하나를 처리할 때 35 KB의 로그가 쏟아지는데, 막상 장애가 나면 필요한 정보는 거대한 JSON 덩어리 안에 파묻혀 있었다. 이 글은 업무 중 레거시 서버의 로깅을 개선하면서 겪은 문제와 해결 과정을 정리한 글이다.문제 인식1. 로그 한 줄이 너무 크다 — ES 색인 실패외부 API를 호출할 때마다 요청·응답 전체를 직렬화해서 로그에 남겼다. 응답 JSON이 크면 Elasticsearch의 필드 크기 제한(32 KB)을 초과해 색인 자체가 실패했다. Kibana에서 검색되지 않는 로그가 생기는 것이다. 실제로 특정 API 응답 하나가 10,548 bytes였다.2. extra 필드가 로..

들어가며어느 날 팀 동료와 티타임 중에 떠오른 아이디어..."재생 중인 음악을 인식해서 찾아주는 기능, 더 잘 만들 수 없을까?"특히 차량 환경이 문제였습니다. 여러 스피커가 차량 내부에 분산되어 있고, 운전자 위치에 설치된 단일 마이크로 음원을 수음해야 하는 구조에서는 잡음·반향으로 녹음 품질이 크게 저하됩니다. 기존의 오디오 핑거프린팅 방식은 이런 환경에서 인식률이 떨어집니다.팀 내에서 LLM을 활용한 대안적 접근법이 제안되었고, 그 중 "Whisper로 가사를 추출해서 음악을 검색한다" 는 아이디어를 제가 직접 PoC로 구현해보기로 했습니다.배경: 어떤 접근법들이 논의됐나문제를 처음 정의할 때 크게 네 가지 방향이 검토되었습니다.LLM Audio Cleaning 서비스 기반: AI 기반 오디오 정제..

들어가며서비스를 운영하면서 제일 아찔했던 순간 중 하나는, 장애가 났는데 어떤 API가 문제인지 알아내는 데 10~20분이 걸렸을 때입니다.기존에도 자동화된 알림이 없었던 건 아닙니다. 정기적으로 실제 요청을 넣어서 서비스가 정상인지 확인하는 자동화 테스트가 10~15분 주기로 돌고 있었습니다. 하지만 이 방식에는 한계가 있었습니다.간헐적 장애를 놓침: 테스트 타이밍에 서비스가 복구되어 있으면 탐지하지 못합니다.범위를 특정하기 어려움: 여러 서비스에서 동시에 오류가 떴을 때, "전체가 문제인가, 특정 API만 문제인가"를 파악하는 데 또 시간이 필요합니다.알림이 오기 전까지 인지 불가: 이미 사용자 영향이 시작된 이후에야 알게 됩니다.그때 팀에서 나온 이야기가 "직접 만들어보자"였습니다. 약 2개월(24..

문제yum으로 설치가능한 OpenJDK는 11까지만 지원이 되기 때문에 17버전을 설치 할 수 없음 해결17버전이 필요하다면 아래와 같이 수동으로 설치할 수 있다. 1. 외부에서 소스를 받기 위한 패키지를 설치 (설치되어 있다면 생략)sudo yum -y install wget curl 2. 외부 링크에서 압축파일을 다운로드 후 해당 파일의 압축을 해제한다. https://download.java.net/java/GA/jdk17.0.2/dfd4a8d0985749f896bed50d7138ee7f/8/GPL/openjdk-17.0.2_linux-x64_bin.tar.gzwget https://download.java.net/java/GA/jdk17.0.2/dfd4a8d0985749f896bed50d7138e..

@NotNull -> null만 걸러냄 ("", " " 같은 데이터는 허용) @NotEmpty -> null, "" 걸러냄 (" " 데이터는 허용) @NotBlank -> null, "", " " 데이터 전부 걸러낸다 해당 어노테이션들에 대해 간단히 정리하자면 위와 같다. 하지만, 블로그로 다시 한번 정리하는 이유는 실무에서 개발을 하다가 놓친 부분이 있었기 때문이다. 바로, 허용되는 변수의 타입! @NotNull해당 필드가 null 값을 허용하지 않음을 나타냄. 이 어노테이션을 사용하면 메소드나 매개변수, 필드 등에서 null 값이 들어오지 않도록 강제할 수 있음. 특징:허용되는 타입: 모든 타입설명: 해당 필드가 null이 될 수 없다는 것을 의미public class User { @NotNull p..

모기업 인터뷰에서 받은 질문인데 순간적으로 다양한 답변이 생각나지 않아 대답을 만족스럽게 하지 못했다. 익숙함에 속아 중요한 걸 놓치지 말자! 아쉬운 마음에 블로그로 기록해본다. 1. 직관적인 방법 직접 == 연산으로 비교하는 방법이다. 가장 떠올리기 쉬운 방법! String str = null; if (str != null) { // 문자열이 null이 아닌 경우 } else { // 문자열이 null인 경우 } 2. equals() Objects 클래스의 equals 메서드를 사용하여 null 체크하는 방법 String str = null; if (Objects.equals(str, null)) { // 문자열이 null인 경우 } else { // 문자열이 null이 아닌 경우 } 이때 주의할 점은..

현재 직장에서 진행 중인 프로젝트에서 고민이 생겼다.이전에 개인적으로 팀 프로젝트를 진행했을때는 Req,Res 클래스를 매번 만들어 도메인 별로 관리를 했다. 그러나 실무에서 적용할 때는 가급적 관리할 클래스 수를 줄이고 싶었고, 중복코드를 줄이고 싶었다. 그렇게 고민 끝에 세가지 방안을 내놓게 되는데 .... (사실 서버단은 나 혼자이기 때문에 혼자 먼저 고민한 후 최종으로 클라이언트단과 합의하여 결정했다.)1.목적마다 DTO를 생성한다장점목적에 맞고 필요한 필드만 가지는 DTO를 생성추후 문제가 발생할 여지가 적음불필요한 필드를 프론트 쪽에 노출 시키지 않음각각의 DTO가 유의미한 이름을 가짐(이름으로 의도 파악 가능)단점클래스의 수가 많아짐중복된 코드 다수 발생재사용이 어려움클래스 수가 많아질수록 ..