경력·프로젝트 요약은 이력서에 있습니다. 여기는 최근 몇 달 사이 실제로 부딪혀서 고친 것들을, 원인을 찾아간 순서 그대로 적어뒀습니다.
노무관리에 가불금 같은 기타공제 항목을 새로 넣었는데, 며칠 뒤 국민연금 임의가입 처리에서만 공제액이 두 배로 빠진다는 제보가 들어왔습니다. 5만원이어야 할 게 10만원이 빠져 있었습니다.
파보니 급여를 확정하는 경로가 두 종류였습니다. 최종 금액을 통째로 계산해서 저장하는 쪽과, "기존 금액에서 얼마를 뺀다"는 식으로 저장하는 쪽. 기타공제를 추가하면서 이 두 경로가 같이 쓰는 SQL에 공제액을 한 번 더 빼는 코드를 넣었는데, 뒤쪽 경로는 이미 그 공제가 반영된 값을 넘기고 있었던 겁니다.
SQL에서 억지로 맞추는 대신 최종 금액을 만드는 함수 쪽에서 직접 계산하게 바꿨습니다.
현장 근로자 앱 API를 점검하다가 로그인 여부를 확인하지 않는 체크리스트 저장·조회 엔드포인트를 몇 개 찾았습니다. 요청값만 바꾸면 자기 배정 건이 아닌 것도 처리되는 구조였습니다.
같이 발견한 건 사진 업로드 쪽 버그였는데, 여러 장 찍으면 같은 파일명으로 저장돼서 앞서 찍은 사진이 덮어써지고 있었습니다. 로그인 가드와 소유권 검증을 넣고, 사진 파일명에 항목 번호를 넣어 분리했습니다. 제출이 중간에 끊기면 다음 태깅 때 다시 보내지도록 흐름도 고쳤습니다.
근무 이력을 대조해서 "이 사람 이미 다른 현장에서 일한 기록이 있다"고 걸러주는 기능이 있는데, 문제없는 근로자가 걸리고 심지어 낯선 현장 이름까지 화면에 뜬다는 제보를 받았습니다.
DB 하나에 여러 대행기관 사업장이 같이 들어있는 구조인데, 근로자 식별번호는 대행기관과 무관하게 시스템 전체에서 공통으로 씁니다. 문제의 조회 함수가 이 번호만으로 근무 기록을 찾다 보니, 다른 대행기관 현장 기록까지 같이 딸려 나오고 있었습니다. 조회 범위를 대행기관 코드로 좁혀서 고쳤습니다.
상용직 주민번호를 하이픈 없이 한 번에 붙여넣으면, 내국인 번호인데도 외국인으로 판정되는 문제가 있었습니다. 한 글자씩 치면 멀쩡했습니다. 제보가 들어와도 재현이 안 되던 이유였습니다.
입력값을 하이픈 넣은 형태로 다듬어 화면엔 그 값을 보여주는데, 국적 판정 로직은 다듬기 전 원본값을 보고 있었습니다. charAt(7)로 여덟 번째 자리를 보는 코드였는데, 이게 하이픈 있는 형식을 전제로 한 인덱스였던 겁니다. 하이픈 없이 13자리가 한 번에 들어오면 인덱스가 하나씩 밀려서, 뒷자리 두 번째 숫자가 5~9인 경우에만 틀렸습니다.
서비스워커가 설치될 때 정적 자산 358개, 71.6MB를 한 번에 받고 있었습니다. 배포마다 캐시 이름이 바뀌어서 처음부터 다시 받는 구조였고, 그 안엔 대부분 회원이 평생 안 여는 43MB짜리 소개 영상도 들어있었습니다. 접속이 몰리는 배포 다음 날 아침마다 사용자 브라우저 연결이 막혀서 "눌러도 반응이 없다"는 문의가 왔습니다.
설치 시 받는 걸 진입 스크립트와 CSS만으로 줄이고, 나머지는 실제로 필요할 때 캐시에 넣도록 바꿨습니다. 정적 자산은 어차피 브라우저 HTTP 캐시가 파일명 해시로 영구 캐싱하고 있어서, 서비스워커 프리캐시는 그 위에 중복으로 얹혀 있던 것이었습니다.
무료 회원이 6개월 지난 작업년월을 조회하면 서버가 403을 돌려주는데, 그 응답을 처리하는 코드가 소스 전체에 한 곳도 없었습니다. 호출부들이 응답 코드를 안 보고 바로 배열로 다루려다 보니 그 자리에서 에러가 나고, 로딩 스피너를 끄는 줄까지 못 가서 화면이 영원히 로딩 중으로 남았습니다.
같은 가드를 호출하는 곳이 22곳이었는데, 응답을 제대로 확인하는 곳은 한 곳뿐이었습니다. 공통 처리 함수를 하나 만들어 22곳(16개 파일) 전부에 적용했습니다.
신규 서비스를 처음부터 만들면서 초반 며칠은 속도를 내려고 DB 접속 정보를 코드에 바로 넣어뒀습니다. 배포 전에 스스로 점검하다가 알아채고 환경변수로 옮겼습니다. 감출 일은 아니라고 생각해서 그냥 적어둡니다.
직접 만든 퍼즐 게임 문제 181개를 다시 검수하다가, 의도한 것과 다른 답도 나올 수 있는 문제 19건을 찾았습니다. 그중 하나는 시소 그림이 물리 법칙과 반대로 그려져 있었는데, 좌표를 직접 넣어 모멘트를 계산해보니(왼쪽 24 : 오른쪽 12) 왼쪽이 내려가야 하는 게 맞았습니다. 그림이 틀린 거였습니다.
다른 하나는 받침 유무로 갈리는 문제였는데, 예시 단어들이 우연히 "고유어인지"로도 똑같이 갈려서 의도치 않은 규칙으로도 같은 답이 나왔습니다. 두 규칙이 서로 다른 답을 내는 단어를 예시에 추가해서 막았습니다.
뱃지가 붙은 사례는 최근 만든 에이전트 워크플로(원인 조사·초안 작성은 에이전트, 원인 검토·수정 범위 판단·머지는 직접)로 처리했습니다. 나머지는 코드를 직접 보고 고쳤습니다.
React·Vue는 실무로는 안 써봤습니다. 컴포넌트·상태 관리 개념은 SvelteKit과 겹치는 부분이 있어서, 필요하면 짧은 시간 안에 따라잡을 수 있다고 보고 있습니다.
게임 로직과 문제은행 무결성을 Vitest로 보증합니다. 출시 후에도 콘텐츠 확장·SEO·GA 분석·유튜브 쇼츠 자동 생성까지 직접 붙이며 운영 중입니다.
임현진 · 인하대학교 화학공학과 · 갱신 2026.09