퇴근 직전 Jira를 열었는데, 티켓이 있었습니다. 수신된 메일은 없었습니다. Jira에서 담당자로 배정된 티켓은 메일로 알 수 있지만, 작업자는 달랐습니다. 메일이 오지 않았습니다. 그동안은 작업 중간마다 Jira 대시보드에 들어가거나, Cursor의 Atlassian 플러그인을 통해 제가 작업자로 들어간 티켓이 있는지 직접 확인해야 했습니다. 이건 단순히 직접 들어가서 봐야 되는 귀찮은 일의 수준이 아니었습니다. 하루에 1시간 간격으로(혹은 그 이상) 업무 흐름이 끊기는 문제였습니다. 다시는 퇴근 직전에 Jira 티켓을 발견하지 않겠다. 다짐하는 순간 밈 하나가 떠올랐습니다. "@@이 온다는 표현은 수동적인 듯 내가 @@에게 간다." 저는 여기에서 아이디어를 얻었습니다. 티켓이 온다는 표현은 너무 수..

우리 서비스 포탈에는 SonarQube 점검 결과를 조회하는 기능이 있는데, 개발자가 SonarQube에 직접 들어가지 않아도 포탈에서 프로젝트별 이슈와 품질 점검 결과를 확인할 수 있도록 만든 기능이었다. 그러던 어느 날, 담당 Front End 개발자분께서 AI에게 물어봤더니 SonarQube 점검 결과는 10,000건 이후의 이슈가 보이지 않을 수 있다고 답했다고 알려주셨다. AI가 알려준 내용을 그대로 믿기보다는, 사용자에게 실제로 왜 그런지, 어떻게 우회해야 하는지 설명해야 했기 때문에 그 답의 근거를 직접 찾아보기 시작했다. 1. 문제 상황SonarQube 이슈 조회 API는 다음 엔드포인트를 사용한다.GET /api/issues/search 일반적인 목록 API처럼 page, ps 값을 넘..

올 초 맥미니 열풍이 불었고, 맥미니를 사기 위해(?) OpenClaw에 관심이 생겼다. 그러던 중 제로초님의 호스팅어 VPS 할인 이벤트를 알게 되었다. 처음부터 맥미니를 바로 사기에는 조금 부담스럽기도 했고, 일단 내가 원하는 AI 비서 환경이 어느 정도 사양에서 돌아가는지 확인해보고 싶었다. (그리고 내가 얼마나 잘 쓸지 모르기도 하고,,) 그래서 맥미니를 사기 전 사양을 확인해 보는 느낌으로 1년짜리 VPS를 결제했다. 거창한 목표를 가지고 시작해본 건 아니었고, 그냥 나도 AI 비서가 있었으면 좋겠다.. 에서 시작된 마음이었다.내 일상과 작업 흐름 옆에 붙어 있는 비서가 필요했다. 일정을 정리해주고, 할 일을 기억해 주고, 메모를 받아주고, 내가 귀찮아서 미루는 일을 대화로 넘길 수 있는..!!..

목차HMAC이란 무엇인가SonarQube에서 HMAC secret을 설정하는 방법Spring Boot webhook endpoint에서 HMAC을 검증하는 방법Postman으로 HMAC webhook을 테스트하는 방법작성 배경보안 리포트를 받았는데, SonarQube 웹훅에서 HMAC을 검증하지 않는 이슈가 하나 잡혔다. 심각도도 High였다.고치는 것도 중요했지만, 이번 기회에 HMAC이 뭔지, 왜 필요한지, 그리고 실제로 어떻게 붙였는지 한 번 정리해 봤다. SonarQube webhook은 분석이 끝났을 때 특정 서버로 JSON payload를 보낼 수 있다.처음에는 HMAC을 왜 이렇게까지 해야 하는지 잘 와닿지 않았다.그냥 SonarQube webhook을 endpoint에서 받기만 하면 되는..

동일한 소스코드를 다른 환경의 SonarQube에서 정적분석을 수행하고 있었는데, 환경에 따라 분석 시간이 크게 차이 나는 이슈가 있었다.이번 글에서는 SonarQube 정적분석 시간이 급격히 느려진 원인을 어떻게 추적했고, 최종적으로 어떤 설정을 변경해서 해결했는지 정리해 봤다. 문제 상황동일한 소스코드, 동일한 분석 조건으로 SonarQube 정적분석을 수행했는데 환경에 따라 수행 시간이 14배가 차이가 났다. - A 개발 환경: 약 1분- B 개발 환경: 약 14분 그래서 먼저 A 환경과 B 환경의 차이를 하나씩 비교해 보기 시작했다. 처음 의심한 원인: 서버 리소스 차이가장 먼저 확인한 것은 서버 리소스였다.두 환경의 서버 스펙을 비교해 보니 CPU는 동일했지만 메모리 차이가 있었다.환경CPUM..

"판단하는 사람이 살아남는다." 전 직장 상사분이 항상 하시던 말씀이었다.그때는 "세종대왕 맥북 사건"이 있을 정도로 할루시네이션이 심했을 때가 체감이 잘 안 됐는데, n년이 지난 지금에서야 뼈저리게 실감하게 됐다. "딸-깍"으로 뭐든 뚝딱 만들 수 있는 시대가 됐어도, 결국 판단은 인간의 몫이라는 걸.그러다 인스타 광고로 JOBKOREA DEVCON을 접했다. 주제를 보자마자 고민 없이 신청했다."AI 시대, 개발자 고민 완전 정복" 3시간 동안 진행된 강연을 3가지 키워드로 요약해보았다. 나만의 철학과 태도기본기아이디에이션1. 나만의 철학과 태도배휘동 연사님 말씀 중 인상 깊었던 것 "사람의 말이든, 에이전트의 말이든 언제나 2차 검증을 하세요.""탁월한 개발자의 핵심 역량은 AI 시대에도 유효합..

최근 대량 데이터 등록 기능을 확인하던 중, 일정 개수 이상부터 요청이 정상 처리되지 않는 이슈를 확인했다.처음에는 단순 요청 건수 문제인가 싶었는데, 요청 구조와 바인딩 방식을 따라가 보니 원인은 Spring @ModelAttribute 컬렉션 바인딩 제한에 있었다.이번 글에서는 어떤 상황에서 문제가 발생했는지, 왜 이런 현상이 생기는지, 그리고 최종적으로 어떻게 해결했는지를 정리해보려고 한다.보안상 실제 제품명 및 필드명은 일부 마스킹하여 작성했다.1. 문제 상황폼 데이터 기반 요청에서 리스트 형태의 데이터가 대량으로 전달될 때 에러가 발생했다.요청 데이터는 대략 아래와 같은 형태였다.- `targetList[0]`- `targetList[1]`- ...- `targetList[255]`- `targ..

사이드 프로젝트에서 Supabase를 이용해 카카오 소셜 로그인을 구현했다.처음 구현해 보는 거라 삽질도 많이 하고, 시행착오도 많이 겪었다. 포스팅하면서 다시 해보니까 진짜 별 거 아닌데, 처음에는 다 별 거인 거 같다..ㅠㅋㅋㅋ… 미래의 나와 그리고 인터넷 세상 누군가(?)에게 도움이 되었으면 해서 정리해봤다. 📌참고: 이 글의 스크린샷은 2026년 2월 19일 기준으로 캡처되었습니다.카카오디벨로퍼스와 Supabase의 UI는 버전 업데이트에 따라 변경될 수 있으니, 현재 화면과 다를 수 있습니다.1. 카카오디벨로퍼스 앱 설정카카오 API 시작하기 문서를 참고하여 카카오디벨로퍼스에서 앱을 생성한다.카카오디벨로퍼스 사이트에 로그인한다.[앱] > [앱 생성]을 선택한다.앱 이름, 회사명, 카테고리 등을..

팀에서 작업 현황을 Confluence로 관리하고 있다. 템플릿은 동일한데, 매번 Confluence 페이지를 생성하는 반복 작업이 번거로웠다.파트 내부적으로 'Cursor에서 딸-깍하고 Confluence 페이지를 생성할 수 있는 방법이 없을까?'라는 니즈가 생겼고, 원하는 조건의 Jira 티켓을 조회한 뒤, 결과를 표 형태로 정리해서 Confluence 페이지를 생성/업데이트할 수 있도록 Atlassian MCP와 Cursor를 연동했다. 1. 설치 방법1.1 사전 요구사항Cursor (또는 MCP를 지원하는 AI 에디터)Jira Cloud / Confluence Cloud 계정Atlassian API 토큰1.1.1 UV 설치mcp-atlassian 패키지를 uvx로 실행하기 위해 uv를 설치한다..

A와 B는 서로 다른 요청 타입이지만, 상태 변경 전 검증 항목과 절차는 동일하다. 현재 상태를 조회하는 참조되는 테이블만 다른 상황이었다. 만약, A, B와 유사한 새로운 타입의 C 기능이 추가된다면? 혹은 다른 도메인에서 A, B의 검증 로직이 필요하다면? 이 상태에서 C 같은 새로운 타입이 추가되거나, 다른 도메인에서 동일한 검증 로직이 필요해지면 다음과 같은 일들이 발생한다.Validator가 타입별로 늘어나고거의 동일한 검증 메서드를 복사/붙여넣기 하며수정이 생길 때마다 모든 Validator를 동시에 수정해야 해서 유지보수가 급격히 나빠진다.미래의 나 혹은 동료들이 고통받게 된다. 1. 리팩토링 전 문제점❌ 1) 검증 로직이 모든 Validator에 중복ValidatorA / Valid..

회사2번의 릴리즈 2번의 QA여름과 겨울 두 번의 QA를 끝내고 맞이한 2번의 릴리즈.4-5개월가량 열심히 준비한 결과물이 얼마나 요구사항에 적합하게 만들었는지, 사용성에 불편함은 없는지, 논리적인 오류가 없는지 등을 시험하는 일은 아무리 겪어도 매번 떨린다. 열심히 만들었다고 하지만 나도 모르는 결함이 있을까 봐 물가에 내놓은 자식처럼 QA 기간은 늘 노심초사이다. 상반기 - QA는 첨부파일 관련 이슈가 많이 올라왔다. 기존 각 서버의 파일 시스템에 적재하던 첨부파일을 minIO로 전환 작업과 함께 첨부파일 로직을 공통화했고, 덕분에 12월에 진행한 QA에서는 첨부파일 결함이 올라오지 않았다.하반기 - UI 오류가 무려 33%를 차지했다. 변명을 하자면 한도 끝도 없다는 걸 알기에.. 겸허히 받아들이겠..

회사QA 진행상반기 - 기술적으로 해결하는 것에만 집착하지 말자. 엑셀 미리 보기 기능에 사용되는 라이브러리에서 이미지 파일에 대한 미리 보기는 지원하지 않았다. 해당 이슈는 당시 QA 지적사항은 아니었지만, 짚고 넘어가고 싶어서 파트장님께 보고 드렸다. 해당 기능의 중요도를 판단했을 때 중요도가 그리 높지 않은 기능이므로 이미지는 미리 보기 시 제공되지 않는다는 것을 사용자 가이드에 추가하여 문제를 해결하였다.하반기 - 1년 정도 제품을 개발하다보니 기술 부채를 체감하고 있다. 당시 기능 개발이 우선이라 유지보수성, 가독성등을 챙겨가지 못한 것들을 발견하고 있는데, 이런 것들을 해소하는 기간이 필요하다고 느꼈다.기술 부채 해소를 위한 팀의 노력은 상시적이고 지속적이어야 한다. 프로젝트 개발이나 피처 개..