일단 하고 보는 사람

나중보단 지금에 집중하되, 지금보단 나중에 완벽해지자💪🏻

전체 글 144

[IE to Chrome/Edge] 브라우저 마이그레이션: CSS/JS 호환성(easy편)

기존에 Internet Explorer(IE) 기준으로 맞춰져 있던 내부 시스템/UI 요소들을 Chrome/Edge 전환하는 작업을 하게 됐다.각 브라우저의 기본 스타일 차이와 CSS 선택자/전역 객체 의존성 때문에 생각보다 다양한 UI 깨짐과 JS 오류를 마주치고 있는 중이다지난주 작업에서 직면했던 대표적인 이슈들과 원인, 그리고 해결 과정을 정리해보려고 한다 1. 전역 event 객체 참조로 인한 JavaScript 오류문제: 브라우저 전환 후 드롭다운 메뉴 외부를 클릭할 때 콘솔에 아래와 같은 에러가 발생하며 닫힘 로직이 동작하지 않는 현상이 발생했다Uncaught TypeError: Failed to execute 'contains' on 'Node': parameter 1 is not of ty..

[PostgreSQL/Java] 대용량 데이터 조회 성능 최적화부터 방어적 코딩까지의 기록..🧾

8월 어느 날 있었던 일.. -개발 과정에서 쿼리 성능 저하, DB 부하 집중, 그리고 예외 상황으로 인한 데이터 누락 등 다양한 문제를 만나버렸다.단순히 "기능이 동작하게 만든다"를 넘어 "어떻게 하면 더 빠르고 안전하게 동작시킬 것인가"를 고민하며 개선했던 7가지 이슈와 해결 과정을 3가지 주제로 (AI가) 정리해 보았다 1. DB 계층: SQL 최적화 및 조회 로직 재설계가장 먼저 해결해야 했던 문제는 특정 시간 데이터를 조회할 때 발생하는 SQL 성능 이슈와 데이터 누락 문제였다1-1. JOIN 구조 및 인덱스 최적화 (이슈 1)문제 상황: A_TABLE과 B_TABLE을 JOIN 하여 시간 정보를 조회하는 쿼리의 성능이 현저히 떨어짐원인 분석:JOIN 조건이 WHERE 절에 위치하여 암시적인 ..

[JAVA] 분기 최적화 if-else vs switch / String.replace() 주의점

2026.07.21 작성(if-else vs switch 그리고 String.replace() 주의점)2026.08.09 배포 ㅋㅋ,, 1년 반 만에 자바 프로젝트 복귀라니.. 내년의 나는 또 뭘 하고 있을까 -1. 사용 조건이 2개일 때: if-else vs switch - 뭐가 더 효율적일까switch문을 보여줬는데 조건이 딱 2개일 때는 if-else가 훨씬 낫다는 차장님의 말씀을 듣고 찾아봤다. 성능 관점에서 봤을 때:요즘 자바(12-21)에선 switch가 JIT 최적화 과정을 거치면서 더 효율적이라고 한다근데 조건이 딱 2개일 때는 if-else나 삼항 연산자가 바이트코드 수준에선 직관적이기도 하고 분기 예측, 읽는 속도 면에서 더 깔끔하긴 함 2. 치환로직: if-else vs Strin..

only 해피패스 테스팅만 하면 벌어지는 일: 코드가 잘 돌아가는데 데이터가 왜 사라질까요?;;

🧩 배경: 코드를 또 뜯어봤습니다..팀 내에서 비동기로 수집한 데이터를 LLM 전처리 과정에 태우고 이를 최종 병합하는 로직이 있었다.겉보기에는 결과물도 잘 나오고 큰 문제가 없어 보였다.하지만 데이터 처리의 핵심은 겉보기에 멀쩡한 것이 다가 아니지 않은가..?데이터가 누락 없이 정확하게 흘러가는가에 있기에 기존 코드를 깊숙이 보게 되었다. 💭 내 고민: 눈에 보이지 않던 시한폭탄들( 👆🏻 이 소제목은 내 이야기를 들은 gemini의 답변에서 따왔다 ㅋㅋㅋㅋㅋㅋ) 실제로 코드를 뜯어보니 생각보다 꽤 아찔한 구조적 결함들이 숨어 있었다(난 왜 이걸 이제야 발견했지..?) 1. 불명확한 식별 기준데이터를 취합할 때 기준이 되는 식별 키의 레벨이 너~무 상위 개념을으로 뭉뚱그려져 있었다이로 인해 ..

WHERE절로 때려 넣기 전에 '이것'부터 고민했어야 했다

🧩 배경 최근 팀에서 새로운 AI 서비스 개발에 착수했다. 그중 프롬프트 엔지니어링을 제대로 하려면 기준이 될 '레퍼런스 데이터'가 필요했고, 전체 데이터 중 특정 조건에 맞는 샘플 10여 개를 뽑아보자는 의견이 나왔다. 사실 이때까지만 해도 금방 끝날 아주 가벼운 업무라고 생각했다. 💭 고민의 내용문제는 단순했다. 특정 조건(seq=0, nm!='NONE')에 맞는 최근 한 달 데이터 cnt 상위 10개를 조회하는 쿼리였는데조회 기간을 1주일로 설정하면 0.7초 만에 나오던 결과가 1개월로 늘리는 순간 50초가 넘어도 응답이 없었다. "내 쿼리가 잘못됐나? 조건이 복잡한 것도 아닌데 왜?"답답했다. 특히 COUNT(*)만 하면 무한 로딩에 빠지는 화면을 보며 내 실력의 밑바닥을 마주한 기분이었다...

[코드 리디자인 일지] Ep.3: 어제 배포한 내 코드 뜯어보기 - '운빨'요소 제거🧽🫧

🧩 배경배포 다음 날이라 간만에 찾아온 평화로운 시간~ 커피 한 잔 마시며 어제 배포한 코드를 다시 훑어봤다. 분명 기능은 잘 돌아가고 있었지만 어딘가 모르게 마음 한구석이 간지러웠다."지금은 문제없지만, 데이터 구조가 조금이라도 바뀌면 바로 터지는 거 아냐?" 하는 불안함도 있고 뭔가 더 좋은 구현방법이 있을 것 같고(100%)마침 시간도 좀 남겠다 이 찜찜함을 '근거 있는 코드'로 바꿔보기로 했다. 💭 고민의 내용가장 문제는 인덱스(i)에 의존하는 루프였다. LLM에 프롬프트를 던지고 응답을 받아올 때, 나는 당연히 보낸 순서대로 돌아올 거라 믿고 tmp_list[i] 같은 식으로 데이터를 매핑했다.그런데 문득 겁이 났다. "만약 네트워크가 튀어서 순서가 뒤바뀌면? 중간에 하나가 누락되면?" 내 ..

[커리어 설계] 옥타그노시스 검사 1주차: 나의 본연의 기질을 마주하다

주니어 개발자로서 앞으로의 방향성에 고민이 많아 진로설계 컨설팅을 시작했다. 옥타그노시스 검사옥타(8)+그노시스(진단하다) 검사는'나의 본연의 기질'을 객관적으로 알 수 있는 검사라고 한다.1. 내가잘하는것2. 좋아하는 것3. 타고난 기질4. 나의 심리상태를 알 수 있다. 또한,성격검사인 MBTI는 다르게 성향을 검사하는 것으로 성향 = 난 이런 태도로 삶을 살고 싶어삶의 태도=타고난 것=바꾸기 어려움 해설 전에, 강사님은 내 성격이 되게 독특하다고 표현하셨다. 🧩 옥타그노시스 결과 심층 해석 1. 복합형 (9/10) - 입체적 사고의 소유자복합형은 하나의 현상을 볼 때 한 가지 측면만 보지 않는다고 한다.구분내용특징여러 데이터 동시 연결을 잘함전혀 상관없어 보이는 것들 사이의 공통점을 찾아내..

RAG 성능 최적화: 규칙을 늘릴수록 망가졌던 이유

🧩 배경대화 데이터를 기반으로 특정 기준에 맞는 발화를 찾아내는 작업을 진행했다.기본 구조는 단순했다.등장해야 하는 특정한 키워드 리스트를 기준으로 발화를 검사하고해당 키워드가 모두 포함되면 조건을 충족한 것으로 판단여기에 실제 운영 환경을 반영하면서 조건이 점점 추가됐다.띄어쓰기 차이 허용어근 일치 허용의미 일치 허용숫자/금액/기간 표현 변형 대응(아라비아 숫자)처음에는 자연스러운 확장이라고 생각했다만...결과가 예상과는 너무 달라서,, 진짜 아찔했다. 💭 고민의 내용이상했던 점은 하나였다.단순하게 검색하면 잘 잡히는데,규칙을 넣으면 오히려 못 잡는다..? 예를 들어,특정 키워드 하나로 찾으면 정상적으로 추출됨그런데 여러 조건을 결합하면 동일한 발화가 제외됨(;;;)처음에는 규칙이 부족하다고 생각했..

🤖 AI & LLM 2026.04.12

[코드 리디자인 일지] Ep.2: "돌아가는 코드"에서 "이유 있는 코드"로!! 과거 코드가 부끄러워질 때 비로소 보이는 것들

입사 후 10개월 된 내가 끄적였던 생각들.. 지금 보면 또 아닌 것(?)들이 꽤 보이는데..노션에 짱박혀있던걸 이곳으로 꺼내본다.. 🧩 배경: 마주한 거대한 숙제 입사 후 약 10개월, 사수님이랑 이사님의 가이드 아래 RAG 시스템의 기초를 다져왔다. '제발 에러만 나지 마라..!' 초기엔 AWS Bedrock이랑 OpenSearch 기반이었고, 당시 목표는 일단 데이터가 들어가고 답변이 나오는 것이었다.하지만 서비스가 점차 구체화되고 있는 시점에서 회사의 인프라 전략이 Azure로 바뀌었다.그러면서 마이그레이션이라는 거대한 숙제가 떨어졌다😲 💭 고민의 내용: 내가 짰지만 좀 너무하네..ㅎㅎ;;과거의 나는 *FAQ를 그냥 '글자가 적힌 표'로만 봤다. HTML에서 테이블 보이면 기계적으로 긁어..

“대화”와 “검색”은 다르다 — RAG 설계를 바꾼 기준 (feat.설명끝~)

https://honge1122.tistory.com/144 질문을 그대로 검색하지 않는 이유 - 질문 재정의 단계https://honge1122.tistory.com/143 [RAG 채널별 설계] 세션 기반 RAG vs 단건 질의 RAG, 운영하면서 생긴 차이들🧩 배경회사에서 내부 지식문서를 기반으로 답변을 생성하는 자유질의 서비스를 운영하고 있honge1122.tistory.com애진작에 끝났는데 이제서야 업로드..ㅎㅎ 1. 서비스 설명을 준비하다 든 생각서비스 구조 설명을 준비하면서 한 가지 고민이 들었다.Azure AI Search의 filter를 설명하다 보니“이거 PostgreSQL의 WHERE 절과 같은 개념 아닌가?”라는 생각이었다.(참고로 다른 팀원분들은 PostgreSQL을 사용한다)..