저는 진짜 문제가 무엇인지, 왜 해야 하는지를 먼저 고민합니다.
널리 쓰이는 기술도 정말 제 상황에 적절한지 따져보고, 더 쉽고 단순한 방법이 있으면 그쪽을 택합니다.

자격 / 인증  정보처리기사 SQLD 삼성전자 SW 역량테스트 B형(Professional) TOPCIT

Backend

Frontend

Infra / Tools

매일 문제를 푸는 루틴을 유지하고 있습니다. 알고리즘은 주어진 제약 안에서 무엇을 포기할지 고르는 훈련이라고 생각합니다. 그렇게 쌓은 감각은 실무에서 코드를 검증하고 더 나은 방법을 찾는 밑바탕이 됩니다.

[KB] IT's Your Life 코딩테스트 스터디 Repository (2025.03 ~ 2025.06)
SSAFY 코딩테스트 스터디 Repository (2026.02 ~ 2026.04)

• 팀원이 가져다 쓸 공통 기반을 만드는 역할 — 팀원마다 따로 만든 중복 컴포넌트를 하나로 합치고, 너무 커진 화면을 책임 단위로 쪼갰습니다. 이런 정리는 기능이 끝난 뒤 몰아서 하지 않고 개발 중에 꾸준히 하는 편이고, 세 프로젝트에서 같은 역할을 반복해 맡았습니다.
• 프로젝트의 빈틈을 메우는 역할 — 드러나지 않은 위험은 없는지 살피고, 회색지대에 남은 일을 상기시키는 편입니다. 팀원들에게 "거기까지 생각 못 했다"는 말을 들을 때가 많았습니다.
• 판단 근거를 남기는 커밋과 PR — 무엇을 왜 바꿨는지 기능 단위로 나눠 적고, 구조를 바꿀 때는 왜 다른 방법을 안 골랐는지까지 함께 적습니다. PR은 작업 내역 / 변경 사항 / 테스트 플랜 형식으로 씁니다.

처음엔 AI를 부분적으로만 썼습니다. 같은 입력에도 다른 답을 내는 확률적 특성을 믿기 어려웠고, 예기치 못한 사고로 이어질 위험이 크다고 봤기 때문입니다. 그런데 최근 프로젝트에 조금씩 들여보니 결과가 생각보다 훨씬 좋았고, 관점이 바뀌었습니다 — 사람도 실수하고 AI도 실수한다면, 생산성이 높은 쪽을 쓰되 틀린 부분을 짚어낼 수 있으면 되지 않나.

그래서 AI를 그냥 쓰는 게 아니라 신뢰할 수 있는 구조를 만드는 데 집중했습니다. 반복해 쓰는 작업은 스킬로 만들고, AI가 반복해서 실수하는 부분은 시스템 프롬프트로 못 박고, 중간 과정을 계속 검토하며 워크플로우 자체를 다듬어 갑니다.

🔗 이 과정을 정리한 개인 설정을 공개해 두었습니다 — claude-dotfiles

이 변화는 테스트에 대한 생각도 바꿨습니다. TDD의 가장 큰 걸림돌은 늘 생산성이었는데, AI가 테스트 작성 비용을 크게 낮추면서 그 부담이 사라졌습니다. 실제로 테스트를 먼저 두르고 개발해보니 직접 손으로 짤 때보다 오히려 실수가 줄었고, 검증 가능한 구조가 사고를 미리 막는다는 걸 겪어서 알게 됐습니다.

ICT 학점연계 프로젝트로 참여한 SI 웹개발 인턴십입니다. 실제 클라이언트에게 납품되는 서비스를 다룬 첫 경험이었습니다.

담당 업무

• 한국MICE협회 웹사이트 개발 및 유지보수
• Artitutor(발레 온라인 수강 · 콩쿨 신청 플랫폼) 기능 개발
• AI 기반 웹빌더 Zaemit / Z-Studio QA

사용 기술  jQuery PHP MariaDB Git Docker

jQuery·PHP 기반 사내 프레임워크 위에서 개발해야 했는데, 언어도 프레임워크 개념도 처음이라 각 함수의 역할과 데이터 흐름을 파악하는 데 초반 시간을 많이 썼습니다. 출력문으로 짐작하는 대신 브라우저 중단점과 PHP 디버거로 실행을 따라가는 방식에 익숙해졌습니다. 기존 코드 흐름과 회사 컨벤션에 맞추며, 이론과 다른 선택이 실무에서 쓰일 수 있음을 겪어 트레이드오프를 더 깊게 생각하게 됐습니다.

인턴십 도중, 제 선에서 처리할 수 없는 일을 하루 종일 붙들고 있다가 일정을 늦춘 적이 있습니다. 협업에서는 무엇보다 빠른 소통이 중요하다는 걸 깨닫고, 그 뒤로는 막히거나 의문이 생기면 바로 팀과 공유합니다.

6인 팀 (전공자 4 · 비전공자 2) · 2개월 · KB IT's Your Life 6기 Final 담당: 실거래가 외부 API 연동 구조, 동네 검색 성능 개선, 관심 목록, 공용 컴포넌트, 백엔드 환경 구성, 설치 가이드 Backend · Frontend

전세사기 피해자의 75%가 2030이라는 데이터에서 출발해, 주소만 넣으면 실거래가·건축물대장·재정 안정성을 종합한 안심 리포트를 주는 서비스입니다. 규모 있는 데이터를 처음 다뤄본 실전 팀 프로젝트였습니다.

Java 17 Spring Framework 5.3.38 MyBatis MySQL Spring Security JWT Vue 3 TypeScript 공공데이터포털 CODEF Naver Cloud

공공데이터 API의 아파트 / 연립다세대 / 오피스텔 / 단독다가구 × 매매 / 전월세 — 엔드포인트도 응답 구조도 조금씩 달랐습니다. 8개를 각각 구현하면 호출·파싱·저장 흐름이 유사하게 복제됩니다.

응답 타입만 다르고 흐름은 거의 같다는 데 착안해, 저장 동작을 SaveHandler<T> 함수형 인터페이스로 뺐습니다 — 마침 자바 인터페이스를 배운 참이라 실제로 적용해보고 싶기도 했습니다. 각 API는 VO 타입과 매퍼 메서드 레퍼런스만 넘기고, XML 응답은 XmlMapper + constructParametricType으로 제네릭 DTO 하나가 8종을 다 받게 했습니다.

insertCommon(APT_TRADE_ENDPOINT, lawdCd, dealYmd,
    ApartmentTradeVO.class, mapper::insertApartmentTradeBatch, "아파트 매매");

응답 구조가 같은 이 8종 안에서는 중복을 줄이는 효과가 있었습니다. 다만 나중에 성격이 다른 API(법정동 코드·건축물대장)를 붙일 때는 이 구조가 그대로 맞지 않아 결국 별도 경로로 갔습니다.

지금 보면 "이 8개를 어떻게 묶을까"만 봤지 "앞으로 어떤 API를 더 삼킬까"는 묻지 않아, 저장만 추상화한 좁은 구조가 됐습니다. 눈앞의 중복을 줄이는 것과 시스템이 자랄 방향을 보는 건 다른 문제라는 걸 배웠습니다.

실거래가 데이터 적재가 한 번에 2분 넘게 걸려, 병목이 호출인지 저장인지 실측했습니다. 원인은 단건 INSERT였습니다.

I/O를 한 번에 묶는 게 낫다는 걸 알고는 있었지만, 그 차이가 실제로 이렇게 크다는 걸 처음 경험했습니다. 이후 나머지 API 적재도 전부 bulk로 바꾸고, 측정치를 주석으로 남겨 나중에 이 값을 건드릴 사람이 근거를 보게 했습니다.

법정동 검색어 후보를 타이핑할 때마다 DB 조회가 발생하여 반응이 느렸습니다. 처음엔 디바운스·캐싱으로 호출을 줄이려 했지만, 그게 근본 개선인지 고민했습니다.

법정동 코드는 바뀔 일이 거의 없는 정적 데이터이고 5,000건·6필드의 소규모였습니다. 매번 왕복하는 것보다 처음 한 번 다 받아두고 검색은 브라우저에서 하는 게 싸다고 판단해 구조를 바꿨습니다.

데이터 규모가 더 크거나 동적 데이터였다면 백엔드 조회가 더 좋은 방식이었겠지만, 상황을 분석하고 판단하여 적절한 방법으로 개선한 경험이었습니다.

다만 마운트 시점에 받아 재방문마다 다시 받아오는 건 아쉽습니다. 지금이라면 타임스탬프로 만료를 관리하거나 HTTP 캐시에 맡겼을 것입니다.

주소는 표기가 제각각(서울시 / 서울특별시)이라 문자열로 비교하면 같은 건물이 다른 매물로 중복 저장됩니다. 그래서 주소를 좌표(위·경도)로 변환해 식별자로 쓰기로 팀에서 정했고, 저는 관심 목록에서 그 좌표를 기준으로 같은 매물의 중복을 막았습니다. 찜 해제도 row 삭제 대신 상태값(찜 / 해제)으로 관리해 기록을 한 줄로 유지하고 이력을 남겼습니다.

다만 좌표를 식별 기준으로 삼았으면서 정작 조회에 쓰는 위·경도 컬럼에는 인덱스를 걸지 않았습니다. 지도 조회가 WHERE 위도 BETWEEN ... AND 경도 BETWEEN ...인데 인덱스가 없어, 건물이 30만 건 가까이 쌓이자 매번 전체를 스캔하며 2~3초씩 걸렸습니다. 무엇을 식별자로 삼을지와, DB가 그걸 빠르게 찾게 만드는 건 다른 문제라는 걸 놓쳤고, 이후 프로젝트에서 데이터 규모와 조회 방식을 먼저 보게 된 계기가 됐습니다.

• "어떻게 최적화할까"보다 "이 데이터가 어떤 성격인가"를 먼저 묻게 됐습니다. 문제 해결이 아니라 문제 정의가 먼저라는 걸 배웠습니다.
• 반복되는 구조를 추상화할 때 무엇을 공통으로 묶고 무엇을 파라미터로 뺄지 판단하는 기준이 생겼습니다.

3인 팀 · 17일 · SSAFY 관통 프로젝트 담당: AI 연동 파이프라인, 임베딩·벡터 검색, 데이터 배치 적재, 추천·리포트 API, 백엔드·프론트엔드 공통 기반(응답 규격·전역 예외·JWT 인터셉터·인증 가드) Backend · Frontend

사진 한 장과 위치 정보로 문화유산을 식별해 AI 해설을 주고, 탐방이 끝나면 퀴즈와 리포트로 복습하게 하는 서비스입니다.

AI를 서비스 안에 넣어본 첫 프로젝트입니다. 해설을 쓰고 실제 데이터에서 퀴즈를 만들어내는 일이 LLM의 생성 능력에 정확히 맞는 문제라고 봤고, 확률적이라는 불확실성은 감수할 값어치가 있다고 판단했습니다. 그래서 고민은 생성 결과를 어디까지 믿을 것인가와 유한한 토큰을 어떻게 쓸 것인가로 모였습니다.

Java 21 Spring Boot 3.5.1 MyBatis MySQL(SRID 4326) Redis Stack Jedis Vue 3 TypeScript Kakao Maps

사진을 주고 "이게 뭐야?"처럼 열어놓고 물으면 모델은 그럴듯한 오답을 만들고, 없는 문화유산 이름이 나와도 서비스는 틀렸는지 알 수 없습니다. 그래서 모델이 낼 수 있는 답의 범위를 코드가 미리 정해두는 구조로 갔습니다.

먼저 기준 좌표에서 반경 500m 안의 후보를 DB에서 뽑고, 사진과 그 목록을 함께 넘긴 뒤 번호 하나만 받습니다. 출력이 숫자뿐이라 max_tokens를 50으로 묶었고, 후보에 없으면 0을 반환하도록 프롬프트에 규정했고, 서비스단에서도 범위를 벗어난 번호는 식별 실패로 끊습니다. 자유롭게 생성시킨 뒤 후처리로 거르기보다, 애초에 고를 선택지만 주는 쪽이 확실하다고 봤습니다.

후보를 좁히는 기준 좌표는 EXIF를 우선 썼습니다 — 찍은 곳과 서 있는 곳이 다를 수 있어, 사진에 촬영 좌표가 있으면 그것을, 없으면 기기 위치를 씁니다. 걸림돌은 아이폰이었는데, HEIC를 브라우저에서 JPEG로 변환할 때 캔버스 재인코딩 과정에서 EXIF가 유실되어 좌표는 변환본이 아니라 원본에서 읽도록 했습니다. 사진 자체는 512px · JPEG 70%로 압축해 보냈습니다 — 비전 입력은 해상도가 클수록 토큰을 더 먹기 때문입니다.

교육 과정에서 받은 AI 게이트웨이 토큰이 넉넉하지 않아, "되게 만드는 것"과 "싸게 되게 만드는 것"을 처음부터 같은 문제로 놓았습니다.

호출을 쪼개 캐시가 가능한 부분을 분리했습니다. 처음엔 분류와 해설을 한 요청에 담았는데, 문화유산을 식별하려면 사진이 필요하지만 해설을 쓰는 데는 필요 없었습니다. 사진이 걸린 분류는 사용자마다 달라 캐싱이 불가능하지만 해설은 문화유산 단위로 공유할 수 있습니다. 둘을 나누자 같은 곳을 방문한 두 번째 사용자부터 비싼 해설 호출이 0회가 됐고, 인기 있는 곳일수록 해설 비용이 방문자 수가 아니라 문화유산 1개당 1회로 수렴합니다. 캐시 저장소도 성격에 따라 갈랐습니다 — 해설은 계속 쓰는 반영구 데이터라 MySQL에, 리포트 요약이나 호출 카운터처럼 사라져도 되는 값은 Redis에 뒀습니다.

• 용도별 토큰 상한 차등 — 분류 50 / 요약 500 / 기본 해설 1500 / 심화 해설 2048 / 퀴즈 생성 4096
• 작업 성격별 모델 라우팅 — 정확한 비전 분류가 필요한 앞단은 GPT-4o, 출력이 크고 대량으로 생성되는 심화 해설·퀴즈는 저비용 모델(Claude Haiku)
• 사용자당 호출 제한 — Redis INCR + TTL 1분으로 해설 API를 분당 3회로 제한
• 동시 요청 중복 차단 — 같은 문화유산이 캐시 차기 전 겹쳐 들어오면 ID 단위 락으로 비싼 해설 호출을 한 번으로 (단일 인스턴스 전제)

의미가 비슷한 문화유산을 찾는 추천에는 벡터 유사도 검색이 필요했고, 코사인 KNN은 HashMap·RDB로 풀 수 없어 Redis Stack의 벡터 인덱스로 구현했습니다. 캐시·카운터·레이트리밋도 같은 Redis로 처리했습니다. 문화유산 전량을 text-embedding-3-small로 임베딩해 1536차원 벡터로 만들고 코사인 거리로 인덱싱했으며, Spring Data Redis가 RediSearch를 지원하지 않아 벡터 질의만 Jedis로 FT.SEARCH를 직접 호출했습니다.

이 인덱스를 추천 기능 두 개가 나눠 쓰는데, 둘 다 같은 유사도를 쓰면서 거리 조건은 정반대로 지정했습니다.

유사도 점수만 보면 둘 다 맞는 답이지만, "다음 여행지"로 지금 있는 동네를 추천하는 건 사용자 맥락에서 완전히 쓸모없었습니다. 같은 유사도 지표라도 무엇이 좋은 결과인지는 쓰는 맥락이 정한다는 점을 깨달았습니다. 다음 코스 쪽은 멀리 떨어진 후보만 남긴 뒤 반경 25km로 클러스터를 묶어 "하루에 돌 수 있는 묶음"을 만들고, 경로는 TSP 근사로 정렬했습니다.

🔗 CourseService.java#L21-L22 — 클러스터 반경 25km · 최소 이격 거리 50km

국가유산청 데이터 8,313건을 배치로 적재해 기반 데이터로 삼았습니다.

네 개의 엔드포인트 중 이미지 API만 응답이 규격을 벗어났습니다. 한 항목 안에서 필드를 반복하고, 문화유산 이름 자체를 XML 태그로 씁니다(<대성전>, <권1-5>). 선언형 파서로는 읽다가 깨졌습니다.

LightHouse에서 성격이 다른 API를 억지로 기존 구조에 맞추려다 별도 경로로 돌아간 적이 있어, 이번엔 처음부터 갈랐습니다. 정상 응답 세 개는 XmlMapper로 두고, 이미지 API만 비정상 태그를 걷어낸 뒤 StAX로 순회해 필드 쌍마다 항목 하나로 세도록 따로 짰습니다. 깨진 케이스는 테스트로 고정했습니다.

🔗 HeritageApiClient.java

LightHouse에서 좌표에 인덱스를 안 걸어 지도 조회가 전체 스캔이 됐던 탓에, 이번엔 스키마 단계에서 챙겨 두 테이블 모두 좌표를 POINT(SRID 4326)으로 두고 공간 인덱스를 걸었습니다. 다만 이게 실제로 인덱스를 타는지까지 확인하지 못한 반쪽짜리 개선이었고, 그 이야기는 아래 아쉬운 점에서 이어집니다.

• 생성의 범위를 미리 좁히는 설계. 열린 질문을 던지고 결과를 검사하는 것보다, 답이 될 수 있는 것만 주고 고르게 하는 쪽이 훨씬 안전했습니다. 할루시네이션을 사후에 걸러내는 문제에서 애초에 생길 수 없게 만드는 문제로 바꿔 본 경험입니다.
• 비용이 구조를 정할 수 있다는 감각. 캐시를 어느 단위로 잡을지, 무엇을 어디에 저장할지, 어떤 작업을 어떤 모델로 보낼지를 전부 "얼마나 싸게 되는가"에서 역산했습니다. 성능이 아니라 비용이 설계를 끌고 간 첫 경험이었습니다.
• AI 응답은 믿을 수 없는 입력이라는 관점. JSON 형식을 강제하고, 마크다운 코드블록으로 감싸 오는 경우와 토큰 상한에 잘려 오는 경우까지 확인한 뒤에야 서비스에 반영했습니다. 잘린 응답은 조용히 넘기지 않고 명확한 예외로 바꿨습니다.

AI가 만든 결과의 품질을 제대로 검증하지 못했습니다. 입력이 같으면 출력이 같은 인증·퀴즈·배치에는 테스트를 깔았지만, 정작 핵심인 사진 판별 정확도와 해설·퀴즈 품질은 장소 10~20곳을 직접 찍어 눈으로 확인한 게 전부였습니다. 프롬프트도 안 되는 케이스를 보고 고친 뒤 그 케이스로 되돌려보는 식이라, 진짜 좋아진 건지 과적합인지 알 수 없었습니다. 지금이라면 정답을 붙인 평가셋을 먼저 만들어 고치는 케이스와 재는 케이스를 분리했을 것입니다 — AI를 서비스에 넣는 건 결국 정답이 하나가 아닌 출력을 어떻게 검증하느냐의 문제라, 이후 AI 기능에서 가장 먼저 챙기는 부분이 됐습니다.

추천도 같은 뿌리에서 아쉽습니다 — 무엇을 기준으로 비슷하다 할지 정하지 않고 이름·분류·시대·설명을 한 벌의 벡터로 뭉쳐 두 기능이 그대로 나눠 썼고, 품질 기준이 없으니 더 정교하게 만들 근거도 없었습니다. 공간 인덱스도 걸어두기만 하고 조회 쿼리에서 인덱스 컬럼을 함수로 감싸 정작 타지 못하게 짰는데, 실행 계획을 한 번도 확인하지 않은 탓입니다 — 8천여 건이라 문제는 안 됐지만 다음에 DB를 구성하면 꼭 챙길 부분입니다.

개인 프로젝트 Backend · Frontend · ▶ Live Demo

STOMP/SockJS 기반 실시간 대전 오목. Oracle Cloud에 직접 배포해 운영 중입니다. 1차는 부트캠프에서 배운 걸 복습하고 배포까지 직접 경험하려고, 2차는 AI 에이전트 활용을 시험하려고 진행한 프로젝트입니다.

Java 21 Spring MVC 6 WebSocket/STOMP Vue 3 Pinia Tomcat 10 GitHub Actions

렌주룰 금수(3-3, 4-4, 장목) 판정을 프론트와 백엔드 양쪽에 뒀습니다. 프론트는 클릭 즉시 피드백을 주기 위한 것이고, 백엔드는 신뢰 경계입니다. 클라이언트는 조작될 수 있으니 서버가 턴 순서·중복 착수·금수 여부를 전부 다시 검증한 뒤에만 상태를 반영합니다.

규칙 자체도 단순하지 않았습니다. 흑은 정확히 5목이어야 승리(6목은 장목 금수)이고 백은 5목 이상이면 승리라, 같은 함수로 처리할 수 없었습니다. 또 금수 조건이 성립해도 그 수로 5목이 완성되면 승리가 우선합니다.

🔗 GameService.java — 판정 로직 (버그 수정 근거를 주석으로 남겨둠)

모바일에서는 잠깐 터널에 들어가도 소켓이 끊깁니다. 즉시 퇴장시키면 억울하고, 무한정 기다리면 상대가 묶입니다. 30초 유예를 주고 그 안에 재접속하면 게임을 이어가되, 넘기면 자동 퇴장하도록 했습니다. 반면 나가기 버튼은 명시적 의사표현이라 유예 없이 즉시 처리합니다. 같은 "연결 종료"라도 의도가 다르면 다르게 다뤄야 한다고 봤습니다.

🔗 WebSocketEventListener.java#L68-L93 — 게임 중 끊김 vs 게임 외 끊김 분기

1차에서는 배운 걸 실전에 써보고 배포·운영까지 가볍게나마 겪었습니다. 도메인을 사서 연결하고, 외부는 HTTPS로 받아 내부는 HTTP로 넘기는 프록시를 두고, 로컬에선 되던 게 서버에선 안 되는 지점들을 하나씩 풀었습니다. 개발이 끝이 아니라 운영에서 신경 쓸 게 훨씬 많다는 걸 크게 느꼈습니다.

2차는 AI 에이전트를 개발에 본격적으로 써본 첫 프로젝트로, 개발 방식 — 특히 테스트에 대한 생각이 크게 바뀌었습니다. 1차에서 테스트를 건너뛴 건 생산성 때문이었는데, AI가 테스트 작성 비용을 확 낮추자 판정 로직에 테스트를 두를 수 있었고, 옛 로직이 3-3을 잘못 판정하던 버그도 그 과정에서 드러났습니다. 그래서 앞으로는 AI를 다루는 나만의 방식을 얼마나 단단히 갖추느냐가 개발을 크게 좌우하겠다고 생각하게 됐습니다.