기록

목줄을 채우는 일 - 하네스 엔지니어링과 멀티 에이전트에 대하여

개발 6년 차. 요즘 가장 많이 하는 생각은 "내가 짜는 코드"보다 "AI가 짜는 코드를 어떻게 다룰 것인가"다.처음엔 프롬프트 몇 줄로 끝날 줄 알았는데, 실제로 프로덕션에 AI를 들이고 나서 깨달은 건 단순했다.프롬프트는 설득이고, 하네스는 설계다.목줄이라는 비유하네스(harness)는 원래 동물을 묶는 가슴줄, 목줄이다. 목줄 안에 있는 개는 마당을 자유롭게 뛰어다닐 수 있다.공을 쫓든, 땅을 파든, 짖든 다 자기 선택이다. 대신 목줄이 허락하지 않는 범위 "도로로 나가는 것, 옆집 마당을 넘는 것" 은 물리적으로 불가능하다.목줄을 당기면 제지당하고, 반복해서 벗어나려 하면 더 짧은 줄로 바뀐다.내가 이해한 하네스 엔지니어링은 정확히 이 구조를 AI 에이전트에 적용하는 일이다.규격을 정한다 - 이 ..

평소 사이드 프로젝트를 만드는 것을 좋아합니다.하지만 아이디어는 많아도 실제 서비스를 출시하는 과정은 생각보다 쉽지 않았습니다. 백엔드 개발자인 저에게는 모바일 앱 개발과 디자인이 큰 장벽이었고, 혼자서 하나의 서비스를 완성하기에는 시간도 많이 부족했습니다.그러던 중 「AI가 다 하고 내가 돈 버는 APP 만들기」라는 책의 서평단에 선정되어 읽어볼 기회가 생겼습니다.제목만 보면 다소 자극적으로 느껴질 수도 있습니다.'정말 AI가 다 만들어줄까?''앱을 만들면 정말 돈을 벌 수 있을까?'반신반의하며 책을 펼쳤지만, 읽고 난 후의 느낌은 제목보다 훨씬 현실적이고 실용적인 내용이라는 것이었습니다.백엔드 개발자인 제가 이 책을 읽은 이유현재 저는 6년 차 백엔드 개발자로 Java와 Spring 기반의 서버 개발..

"언젠가는 게임을 만들어보고 싶다"는 생각만 했다면, 이 책이 좋은 시작점이 될 수 있습니다.백엔드 개발자로 일한 지도 어느덧 6년이 되었습니다.평소 업무에서는 Java와 Spring 기반의 서버를 개발하고 있지만, 한 가지 아쉬움이 있었습니다. 바로 직접 게임을 만들어보고 싶다는 로망이었습니다.Steam이나 모바일 게임을 하다 보면 "이런 시스템은 어떻게 만들었을까?", "나도 언젠가는 작은 게임 하나쯤 만들어보고 싶다."라는 생각을 자주 했지만, 막상 시작하려니 무엇부터 해야 할지 몰랐습니다.그러던 중 좋은 기회로 『Do it! 유니티 6로 게임 제작 & 출시하기』를 서평단으로 읽게 되었습니다.게임 개발 입문자가 가장 어려워하는 부분을 잘 알고 있는 책처음 유니티를 접하면 프로젝트 생성부터 컴포넌트,..

# 프로젝트 구조 분석 프롬프트**당신은 [시니어 아키텍트]이자 [프로젝트 분석 전문가]입니다.**당신의 임무는 사용자가 제공하는 **[1. 프로젝트 정보]**를 바탕으로 **[2. 분석 대상 코드베이스]**의 구조와 설계를 심층 분석하는 것입니다. 분석 시에는 6년차 개발자가 새로운 프로젝트를 빠르게 이해하고 효과적으로 기여할 수 있도록, 아키텍처 결정의 배경, 핵심 비즈니스 로직의 흐름, 그리고 주의해야 할 기술적 제약사항을 **[3. 프로젝트 분석 리포트]** 형식에 맞춰 제시해야 합니다.---## 1. [여기에 '프로젝트 정보'를 입력하세요](프로젝트의 목적, 주요 기능, 기술 스택, 배포 환경, 팀 구성 등 프로젝트의 맥락을 이해하는 데 필요한 정보를 명시합니다.)> (입력 예시)> > - **..

신규 프로젝트를 빠르게 이해하기 위한 프로젝트 분석 프롬프트개발을 하다 보면 어느 순간 새로운 프로젝트를 맡게 되는 일이 꼭 생긴다.특히 기존 서비스에 투입되거나 다른 팀에서 운영하던 시스템을 인수받는 경우라면 더 그렇다. 저장소를 처음 열어보는 순간 대부분 같은 생각을 한다."이 프로젝트… 어디서부터 봐야 하지?" 나 역시 실무에서 여러 번 이런 상황을 겪었다. 처음에는 가장 정석적인 방법으로 접근했다.Controller부터 시작해서 Service, Repository를 하나씩 따라가며 구조를 이해하려고 했다. 하지만 실무 프로젝트는 생각보다 훨씬 크고 복잡하다. Spring Boot 기반 프로젝트 하나만 해도 수백 개의 클래스가 존재하고, 여기에 인증, 캐시, 메시징, 외부 API 연동 같은 요소까지..

2026년 1월 7일 오전부터 Logi Options Plus를 사용하던 사람들이 동시에 같은 문제를 겪기 시작했다.마우스 버튼 커스터마이징이 전혀 먹히지 않고, 앱을 실행하면 무한 로딩 화면에서 멈춘 채 아무 동작도 하지 않는 상태가 되는 증상이었다.나 역시 평소처럼 Mac을 켜고 업무를 시작했는데, 즐겨 쓰던 마우스 단축키가 하나도 동작하지 않았다. 처음엔 “재부팅하면 되겠지” 수준으로 생각했는데, 재부팅 → 앱 재실행 → 권한 확인까지 다 해도 상황은 동일했다.검색을 해보니 같은 시각에 동일 증상을 겪는 글들이 한꺼번에 쏟아지고 있었고, 이쯤 되니 개인 환경 문제가 아니라 전역적인 장애라는 확신이 들었다.아래는 내가 실제로 겪은 상황과, 임시로 문제를 해결했던 방법을 정리한 글이다.같은 문제로 헤매..

새로운 프로젝트의 아키텍처를 분석하면서 Hexagonal Architecture(육각형 아키텍처)를 처음 제대로 마주했다.사실 이름은 몇 번 들어봤지만, 실제 코드로 구현된 것을 보니 솔직히 첫 느낌은 "이거 너무 복잡한 거 아냐?"였다.인터페이스가 너무 많고, 모듈도 쪼개져 있고, AutoConfiguration까지... 패키지 분리만으로도 충분히 레이어를 나눌 수 있는데 왜 이렇게까지 해야 하나 싶었다. 하지만 깊이 파고들수록 "아, 이래서 이렇게 만들었구나" 싶은 순간들이 있었다.이 글은 Hexagonal Architecture를 처음 접하는 분들, 그리고 나처럼 "이게 정말 필요한가?" 의문을 가진 분들을 위한 실무 개발자의 시선에서 쓴 기록이다.Hexagonal Architecture가 뭔데?H..

캘린더를 만들게 된 계기개발을 하다 보면 늘 필요한 도구들이 있다. 그중에서도 **캘린더(Calendar)**는 업무와 일상 모두에서 필수적인 도구다. 하지만 시중에 있는 캘린더 앱은 대부분 기능이 과하거나, 내가 원하는 방식과는 거리가 있었다. 그래서 직접 만들기로 결심했다.가장 큰 계기는 개인화된 근무 일정 관리였다. 일반 캘린더는 회의나 약속을 기록하기엔 좋지만, 나처럼 주주야야휴휴 같은 특수한 근무 패턴을 직관적으로 관리하기엔 부족했다. 매번 수동으로 등록하는 것도 번거롭고, 내가 원하는 뷰를 제공하는 앱은 없었다. 그래서 ‘없으면 만들자’라는 마음으로 시작했다.내가 원했던 기능들근무 패턴 자동화반복되는 근무 사이클(주간, 야간, 휴무)을 미리 정의해 두면, 캘린더가 자동으로 해당 패턴을 표시해준..

최근 몇 달간 나는 새로운 개발 습관을 실험해봤다. 바로 바이브코딩(Vibecoding) 이다. 간단히 말해, 코드를 작성하고 문제를 해결하는 과정에서 AI 도구(ChatGPT, Cursor)를 적극 활용하는 방식이다. 단순한 검색을 넘어, 코드 리뷰어이자 협업 파트너처럼 AI를 옆에 두고 코딩을 진행하는 경험이었다.바이브코딩을 시작한 이유개발을 하다 보면 새로운 기술을 빠르게 익혀야 하거나, 사소하지만 시간을 많이 잡아먹는 문제에 부딪히곤 한다. 이때 AI가 제공하는 즉각적인 코드 예시, 에러 분석, 리팩토링 제안은 큰 도움이 된다. 실제로 ChatGPT와 Cursor를 통해 많은 시행착오를 줄였고, 반복적인 구글링 시간을 절약할 수 있었다.특히 구글 검색 대비 장점은, 맥락을 이어가는 대화가 가능하다..

"에러는 언제나 발생한다. 중요한 건 예쁘게, 일관되게, 의미 있게 처리하는 것."문제 상황: 예외는 늘 예상치 못하게 찾아온다실무에서 API 개발을 하다 보면, 가장 골치 아픈 것 중 하나가 바로 예외 처리다.처음엔 간단한 try-catch나 throw new RuntimeException() 정도로 시작하지만, 프로젝트 규모가 커지고 클라이언트가 붙기 시작하면 얘기가 달라진다.어떤 API는 500 에러를 내고,어떤 API는 그냥 null 리턴하고,어떤 API는 메시지도 없이 400만 띄운다.결국 클라이언트 개발자는 혼란스럽고, 서버 로그엔 에러 메시지가 뒤섞여 보기 어려워진다.나도 과거에 그런 문제를 겪었고, 그때부터 Spring Boot에서의 예외 처리를 통합적으로 설계하는 법을 정리하게 됐다.내가..

"개발자의 시간을 아끼는 진짜 문서 자동화 방법, ChatGPT로 시작해보자"문제 상황: API 명세서 작성, 늘 뒤로 미뤄지는 이유API 문서 작성은 대부분 개발자에게 ‘하면 좋은 일’이 아니라 ‘귀찮은 일’이다.Swagger도 있고 Spring REST Docs도 있지만, 막상 손을 대려면 생각보다 준비할 게 많다.Swagger는 편하긴 하지만 문서화의 유연성이 떨어지고,REST Docs는 예쁘지만 세팅부터 문서화까지 손이 많이 간다.결국 팀에서 "나중에 쓰자"며 README에 메서드 설명 몇 줄 달고 끝나는 경우가 많다.나도 그랬다. 그런데 그게 쌓이면 나중에 진짜 큰 문제가 생긴다.클라이언트랑 사소한 필드 하나 때문에 실랑이 벌이고, 예외 응답 안 맞아서 디버깅하는 데 반나절 쓰기도 했다.그래서 ..

"복잡한 로직, 반복 코드, 고민할 시간 줄이고 바로 리팩토링하기"문제 상황: 리팩토링은 늘 뒷전이다개발자로 일하면서 가장 귀찮지만 중요한 작업 중 하나가 바로 "리팩토링"이다.처음 기능을 만들 땐 빨리 동작만 하게 만들기 바쁘다 보니, 나중에 보면 코드가 엉망이 되어 있다. 변수명은 중구난방, 로직은 길고, 중복도 가득하고...“나중에 정리하자” 하고 넘어가지만, 실은 그 ‘나중’은 영영 오지 않기도 한다.나도 그런 경험이 많았다. 실제로 컨트롤러 메서드 안에 서비스 로직을 절반 이상 때려 넣고, 그대로 배포한 적도 있었다. 나중에 기능이 하나 더 붙으면서 그 코드를 손보는데, 도저히 뭘 건드려야 할지 감도 안 잡히더라.그래서 그때부터 ChatGPT를 코드 리뷰 파트너처럼 활용하기 시작했다. 혼자 고민..

안녕하세요, 오늘은 Java 백엔드 실무 면접을 준비하시는 분들을 위해 제가 실제 경험한 면접 질문들과 그에 대한 모범 답변을 정리해보려고 합니다. 저도 면접을 준비하면서 블로그나 깃허브 등을 많이 참고했었는데, 실제로 실무에서 많이 나오는 질문과 그 의도를 이해하는 게 무엇보다 중요하더라고요. 이 글이 여러분의 면접 준비에 작은 도움이 되길 바라며, Java, Spring Boot, JPA, REST API, Redis, JWT 인증 같은 키워드 중심으로 정리해볼게요.1. Java 백엔드 실무 면접에서 자주 나오는 질문들Q1. Java에서 HashMap과 ConcurrentHashMap의 차이점은?의도: 멀티스레드 환경에 대한 이해도를 보려는 질문이에요.모범 답변:HashMap은 쓰레드에 안전하지 않아..

개발자라면 누구나 한 번쯤은 이런 생각을 해봤을 거예요."오늘 이거… 내가 안 해도 될 수는 없을까?"요즘은 진짜로, 내가 안 해도 될 일들이 점점 많아지고 있어요. 바로 ChatGPT 덕분이죠. 처음엔 그저 코딩 도우미 정도로만 생각했는데, 어느새 하루 업무의 절반 이상을 이 친구에게 맡기고 있는 나를 발견하게 됐습니다. 이 글에서는 제가 실제로 ChatGPT를 활용해 업무 시간을 줄인 방법을 공유해보려고 해요. 단순히 코드 짜주는 걸 넘어서, 문서화, 테스트, 커뮤니케이션까지 확장된 활용법들을 소개해볼게요.1. 반복적인 업무? ChatGPT에게 넘기자개발 일을 하다 보면 반복적인 업무가 정말 많죠. 예를 들면:API 명세서에 맞는 컨트롤러 메서드 작성서비스/레포지토리 템플릿 반복 생성공통 예외 처리 ..

최근 개발자 커뮤니티를 보면 "테스트 코드 어떻게 작성해야 할까요?"라는 질문이 정말 자주 보입니다. 사실 저도 초창기에는 테스트 코드 작성이 너무 어렵게 느껴졌고, 귀찮기도 했습니다. 그런데 요즘은 ChatGPT 덕분에 테스트 코드 작성이 꽤 편해졌어요. 실무에서 직접 사용해본 경험을 바탕으로, ChatGPT로 테스트 코드를 자동 생성하는 방법과 팁들을 공유해보려고 합니다.문제 상황: 테스트 코드를 쓰기 귀찮거나, 시간이 없다우리 모두 알죠. 테스트 코드는 중요하다는 걸. 그런데 바쁜 일정에 치이다 보면 테스트 코드는 늘 후순위로 밀립니다. 특히 기존 레거시 코드에 테스트를 붙이려고 할 때는 어디서부터 손을 대야 할지도 모르겠고, 의욕이 뚝 떨어지죠.그리고 또 하나. JUnit, Mockito, Web..

Spring Boot 개발을 하다 보면, 외부 API를 호출해야 하는 일이 정말 자주 생기죠. 이때 사용할 수 있는 대표적인 HTTP 클라이언트가 바로 RestTemplate과 WebClient입니다. 그런데 둘 중 뭘 써야 할지 고민해본 적 없으신가요? 저도 처음엔 "RestTemplate도 잘 되는데 굳이 WebClient로 바꿔야 하나?" 싶었거든요.이번 글에서는 실제로 제가 겪은 실무 경험을 바탕으로, RestTemplate과 WebClient를 비교해보고 어떤 상황에서 어떤 걸 쓰는 게 좋은지 정리해볼게요. 이 글이 여러분의 선택에 조금이라도 도움이 되었으면 좋겠습니다!문제 상황: API 호출, 어떤 방식으로 할까?몇 달 전, 외부 인증 서버와 통신해야 하는 기능을 개발하게 되었어요. 이 기능은..

문제 상황개발을 하다 보면, 시간 복잡도에만 신경 쓰는 경우가 많다.나도 예전에 알고리즘 문제를 풀 때 항상 실행 시간이 얼마나 걸리는지만 봤지, 메모리를 얼마나 쓰는지는 잘 생각하지 않았다.근데 한 번은 프로덕션 서버에서 대용량 데이터를 처리하는 로직을 짜다가, 아무리 성능이 빨라도 메모리 사용량이 터져서 OOM(Out Of Memory) 이 나버린 적이 있었다.그때 느꼈다.아무리 시간이 빨라도, 메모리를 무지막지하게 쓰면 서비스가 뻗어버린다는 걸.그래서 오늘은 공간 복잡도가 무엇인지, 왜 중요한지, 어떻게 계산하는지 얘기해 보려고 한다.내가 처음 공부할 때 이해하기 어려웠던 부분을 최대한 풀어 써볼게.내가 시도한 방법처음에 공간 복잡도를 배우려고 했을 때, 정의만 보면 좀 딱딱했다."공간 복잡도(Sp..

문제 상황내가 개발을 시작하고 어느 정도 코드를 짜기 시작했을 때, 종종 이런 말을 들었다.“그 코드의 시간복잡도는 어떻게 돼?”솔직히 말하면, 처음에는 이 말이 너무 어렵게 느껴졌다.시간복잡도가 뭔데? 그냥 코드가 빠르면 빠른 거고 느리면 느린 거 아닌가?그러다가 어느 순간부터, “왜 내 프로그램은 데이터가 많아지면 급격하게 느려질까?” 하는 의문이 들었다.그때부터 조금씩 시간복잡도의 필요성을 깨닫게 됐다.시간복잡도는 프로그램이 처리해야 하는 데이터의 양이 커질수록, 걸리는 시간이 얼마나 늘어나는지를 설명해주는 개념이다.예를 들어, 내가 좋아하는 마트에 줄을 선다고 해보자.줄이 2명일 땐 금방 계산대에 간다.근데 줄이 200명이 되면?줄이 길어질수록 대기 시간도 비례해서 늘어나게 된다.이 늘어나는 속도..

요즘 Large Language Model(LLM), 예를 들어 GPT나 Claude 같은 모델들을 보면 정말 놀라울 정도로 많은 정보를 알고 있습니다. 그런데 가만히 살펴보면 이 모델들이 모든 지식을 자기 내부에만 담고 있지는 않습니다. 필요한 순간에 외부에서 최신 정보를 실시간으로 가져와 답변에 활용하기도 하는데요. 이때 외부 데이터를 제공하는 중간 역할을 하는 서버가 바로 MCP 서버입니다.MCP 서버의 정의아주 간단히 말씀드리면,MCP 서버는 LLM이 필요한 데이터나 문서, 지식을 꺼내 쓸 수 있도록 연결해주는 외부 정보 서버입니다.LLM 자체는 훈련 데이터를 기반으로 학습되지만, 세상 모든 최신 정보나 사내 시스템 데이터, 특정 API 결과까지 전부 알고 있지는 않습니다. 그래서 "MCP 서버에..

최근 새롭게 배정받은 프로젝트에서 신규 기능을 개발하게 되었다. 간단한 CRUD 작업이었지만, 이번엔 예전처럼 일일이 파일을 만들고 코드를 타이핑하는 방식이 아닌, 새로운 도구를 사용해보기로 마음먹었다. 그 도구가 바로 "커서(Cursor)"였다.문제 상황 : 반복적인 파일 생성과 코드 작성에 지친 나회사에서 작업하는 대부분의 서비스는 Spring Boot 기반이고, 구조도 뻔하다. Controller - Service - Repository로 이어지는 전형적인 구조. 기능 하나 만들자고 매번 이 세 가지 파일을 만들고, 인터페이스부터 구현체까지 반복해서 타이핑하자니 슬슬 피로가 쌓이기 시작했다. "이런 건 자동화할 수 없을까?"라는 생각을 하던 차에, 커서(Cursor)에 대한 이야기를 듣게 되었다.내..