OID 등록 신청 화면의 상위 OID 트리가 스피너도 없이 빈 상자로 한참 멈춰 있었습니다. 트리 요청은 0.6초에 끝났는데 페이지의 DOMContentLoaded 처리가 16.1초였어요. 같은 폼에 있는 참조 선택 상자가 항목 7,099개를 하나씩 DOM에 붙였고, 페이지 전체를 감시하는 FontAwesome이 그 변경 기록을 처리하느라 메인 스레드를 잡고 있었습니다. 모아서 한 번에 붙이게 바꾸니 0.06초가 됐습니다.
클래스·용어 관리 화면에서 네임스페이스를 고르면 소속 용어가 표로 쭉 나옵니다. 가장 큰 것이 117건인데 찾을 방법이 눈으로 훑는 것뿐이었어요. 목록이 페이지 나눔 없이 통째로 그려져 있어서 서버를 부르지 않고 그려진 행만 걸렀습니다. 대신 "전부 렌더돼 있다"는 전제에 기대는 구현이라, 언젠가 페이지 나눔이 생기면 이 검색칸은 그날부터 거짓말을 합니다.
인스턴스 트리를 가상 스크롤로 바꾼 뒤로, 이름을 고쳐 저장하면 선택이 풀리고 트리가 클래스 맨 위로 가는 증상이 있었습니다. 여드레 뒤에야 고쳤는데, 이름을 안 바꾼 저장은 멀쩡해서 간헐적으로 보였어요. 원인은 트리 갱신이 첫 창만 다시 받는다는 것이었고, 같은 전제를 쓰는 자리를 전수로 훑었더니 선택은 하는데 화면 밖에 그리는 곳이 네 군데 더 있었습니다.
필터를 하나 좁힐 때마다 화면이 하얘지고 스크롤이 맨 위로 튀었습니다. 서버와 주소 계약은 그대로 두고, 같은 주소를 fetch로 받아 달라지는 조각 아홉 개만 갈아끼우도록 바꿨어요. 이음매에서 조용히 새던 두 가지를 소리 나게 고쳤고, 응답 순서가 요청 순서와 어긋나는 문제를 사흘 전 데이터 맵에서 잡았던 것과 같은 방식으로 또 잡았습니다.
데이터 통계 화면의 워드클라우드 세 탭이 전부 빈 채로 떴습니다. 서버가 내려준 JSON을 템플릿 리터럴 안에 넣고 JSON.parse로 다시 읽고 있었는데, 값에 든 줄바꿈을 리터럴이 먼저 실제 줄바꿈으로 바꿔 parse가 죽고 렌더 함수 전체가 멈춘 거였어요. tojson은 그 자체로 JS 리터럴이라 그냥 놓으면 됩니다.
등록 신청서의 항목 모달이 화면 4.1개 길이였습니다. 재 보니 67%가 체크박스 상자였고, 한 번 여는 데 체크박스 2,178개를 그리고 후보 조회가 20번 나갔어요. 후보가 많은 슬롯만 접힌 검색칸으로 바꾸고, 접힌 슬롯은 펼칠 때 조회하게 해서 2회로 줄였습니다.
인스턴스 관리 화면에서 같은 날 41분 간격으로 두 가지를 고쳤습니다. 하나는 객체 슬롯이 있는 데이터를 저장하면 TypeError가 나면서 저장이 통째로 죽던 것이고, 하나는 다른 화면에서 구성 속성 순서를 바꿔도 이미 열려 있는 탭은 옛 순서로 계속 그리던 것이었어요. 원인은 달랐지만 둘 다 "이 화면이 한 번 정해 둔 것을 계속 믿는다"는 같은 자리에서 나왔습니다.
상세에서 상세로 두 번 건너가면 목록 버튼이 검색 조건을 통째로 잃었고, 필터를 만질 때마다 뒤로가기 이력이 하나씩 쌓였습니다. 복귀 주소는 받은 것을 그대로 이어달리게 하고, 조건 변경은 덮어쓰고, 화면 안에서 다른 데이터로 건너뛰는 것만 이력에 쌓도록 나눴어요. 기준은 하나입니다. 다른 곳으로 갔나, 같은 화면의 상태가 바뀌었나.
관계도와 데이터 맵은 응답을 기다리는 동안 빈 캔버스였습니다. 트리 화면이 쓰던 waitMe를 그대로 가져다 덮으려 했는데, 그 플러그인이 jQuery에 붙어 있다는 사실 하나 때문에 세 가지가 연달아 걸렸어요. jQuery를 한 번 더 실으면 앞의 플러그인이 지워지고, defer로 실으면 그림 자체가 안 그려지고, 켠 스피너를 끌 때는 캔버스가 이미 다른 객체로 바뀌어 있었습니다.
관리 화면의 jsTree가 클래스 하나에 인스턴스 수천 건을 매달고 있었습니다. 오후에 더 보기 노드를 고치고, 스크롤 자동 적재까지 갔다가, 저녁에 창 하나만 DOM에 두는 가상 스크롤로 확정했어요. 창 밖은 padding으로 높이만 세우는데, 그 여백을 인라인이 아니라 우리가 소유한 style 규칙으로 줘야 했고, jsTree 펼침 애니메이션은 꺼야 했습니다.
온톨로지 옆 패널의 관계 목록은 무엇과 이어졌는지는 말하는데 그 이음이 무슨 뜻인지는 안 말합니다. 트리플을 주어·서술어·목적어 문장으로 풀었어요. 기계 틀 하나로는 뜻이 안 잡혀 술어 18종의 문장을 손으로 다듬었고, 조사는 받침을 세서 골랐습니다. 서버는 한 줄도 안 고쳤습니다.
드릴다운으로 세 단계 파고들어간 뒤 상세로 갔다가 돌아오면 늘 맨 처음이었습니다. 탐색 단계를 pushState로 주소에 남겼는데, 그 주소가 상세의 복귀 파라미터로 실려 가면서 서버 필터에 통째로 버려졌어요. 값을 한 번 더 인코딩해 통과시켰고, 복원이 중간에 끊기면 거기까지만 그리고 주소를 화면에 맞췄습니다.
인스턴스를 편집하다 왼쪽 트리의 다른 노드를 누르면 입력한 게 전부 날아갔습니다. confirm으로 되묻는 것까지는 쉬웠는데, "취소"를 눌러 선택을 되돌리는 그 동작이 다시 select 이벤트를 쏴서 결국 화면이 지워졌어요. 이어서 같은 화면의 e2e가 간헐 실패하던 것도 jstree refresh()가 비동기라는 같은 뿌리였습니다.
OID 트리 노드 이름 뒤에 [신청중] 같은 상태를 붙이던 코드를 76줄 지웠다가 일주일 뒤 되살렸습니다. 되살린 커밋 메시지에 지운 커밋의 해시를 "깃 참고"로 적어 뒀어요. 그런데 되살린 건 같은 것이 아니었습니다. 워크플로 상태 대신 모델 필드, 모두에게 대신 관리자에게만. 35분 뒤엔 공용 파서에서 빼서 화면 전용 후처리로 옮겼습니다.
트리 화면 셋의 오류 처리를 손보던 오후였습니다. 커밋 둘이 합쳐 600줄 가까이 바뀐 것처럼 보이는데, 공백을 무시하고 보면 120줄이에요. 실제로 한 일은 오류 alert에 어느 요청이 실패했는지 한 줄 붙이기, 관리자 버튼 바인딩을 감싸던 if를 풀기, 세 파일의 버튼 id를 맞추기였습니다. 정작 handleAjaxError 함수 본문은 한 글자도 안 바뀌었습니다.
입사 석 달째, 파일 33개에 1,228줄을 더하고 823줄을 지운 커밋을 올렸습니다. 제목은 스크립트 하나를 바꿨다는 한 줄이었어요. 지금 세어 보니 그 안에 이름 바꾸기, 새 모듈 다섯, 인라인 스크립트 분리, 설정 변경, 뷰 정리가 같이 들어 있었습니다. 그중 하나는 두 달 뒤 팀원이 지웠고, 하나는 1년 뒤 버그로 돌아왔습니다.
속성을 편집하고 저장하면 트리 화면이 늘 첫 노드로 돌아갔습니다. 성공 주소에 ?selected_node=를 붙여 편집하던 클래스로 돌아오게 했어요. 이틀 뒤 저녁에 setTimeout과 no-cache 헤더를 넣었다가 두 시간 뒤 전부 지우고 페이지 새로고침으로 바꿨습니다. 그때 만든 파라미터 이름이 1년 뒤에도 그대로 쓰입니다.
입사 두 달째에 메타데이터 클래스 트리를 처음 만들었습니다. 템플릿 하나에 스크립트 550줄을 넣었고, 공개 화면에는 같은 것을 한 벌 더 넣었어요. 아흐레 뒤 스크립트를 파일로 빼면서 노드를 고를 때마다 페이지를 통째로 이동하게 만들었다가, 다음날 그걸 걷어내고 트리를 목록 화면으로 옮겼습니다. 첫 판이 어디서 무너졌는지를 커밋 셋으로 되짚습니다.
useState를 바닐라 JS로 흉내 내봤던 스터디 글입니다. 다시 보니 두 가지가 보여요 — 내가 만든 건 사실 useState가 아니라 구독 기반 외부 스토어(zustand 쪽)였다는 것, 그리고 진짜 useState의 핵심(훅 호출 순서로 상태 슬롯을 찾는 커서)은 하나도 구현하지 않았다는 것. 원 코드를 두고 그 간극을 정리했습니다.
useEffect를 바닐라 JS로 흉내 냈던 스터디 글입니다. 개고하며 돌려보니 버그가 둘 있었어요 — deps 비교가 "배열 전체 vs 항목 하나"를 비교해 항상 변경으로 판정되고, 정작 첫 호출에는 effect가 실행되지 않습니다. 원 코드와 버그 분석, 그리고 커서 모델로 고친 버전을 실었습니다.
debounce와 throttle은 짧은 시간 동안 빈번하게 발생하는 이벤트의 처리를 제어하여 성능을 최적화하는 기술입니다.
Sync(동기)에서는 요청을 보내고 해당 요청에 대한 응답을 기다립니다. 이 방식에서는 하나의 작업이 끝나기 전까지 다음 작업을 시작할 수 없습니다.
function gfn(x) { var v1 = 3; const c2 = 4; g1 = 11; function fn(y) { const c2 = 5; console.log(x + v1 + g1 + c2 + y); } fn(6); }
자바스크립트에서 실행 컨텍스트는 코드가 실행되는 환경을 의미하며, 각각의 실행 컨텍스트는 특정한 상태와 관련된 정보를 포함합니다. 실행 컨텍스트에는 전역 컨텍스트, 함수 컨텍스트, 블록 컨텍스트가 있습니다.
함수를 호출 하면 함수 코드가 평가되어 함수 실행 컨텍스트가 생성된다. 이 때 생성된 함수 실행 컨텍스트는 실행 컨텍스트 스택, 콜스택에 푸시 되고 함수 코드가 실행 된다.
"불특정의 사람들을 모아 놓고 개최하는 잔치"
찜한 병원까지의 거리가 NaN으로 나오는 경우가 있었습니다. Places 응답의 location.lat을 typeof로 검사해 함수면 호출하고 숫자면 그대로 쓰는 분기를 넣고, LatLng 객체로 다시 감싸 거리를 계산하게 바꿨어요. 문서를 지금 읽어 보면 location은 늘 LatLng 객체라 lat은 늘 함수인데, 그날은 둘 다 대비했습니다. 실제로 어느 쪽이 왔는지는 기록에 없습니다.
카카오톡 공유 카드에 로고가 안 나와서 같은 네 파일을 한 시간 동안 여섯 번 커밋했습니다. 첫 커밋을 4분 만에 GitHub에서 Revert했고, 이미지 주소를 절대 경로, 상대 경로, 다시 절대 경로로 오갔어요. 카카오 쪽에서 이미지를 가져가 그리니 상대 경로는 애초에 될 수 없었는데, 그날은 그걸 몰랐습니다.
숙소 목록 카드에 "할인가 ~"를 보여 주려는데, 숙소 타입 하나에 가격 필드가 네 쌍 여덟 개였습니다. 이름이 비슷한 네 쌍 중 무엇이 원가이고 무엇이 할인가인지, 화면은 어느 쌍을 믿어야 하는지를 서버 서비스와 직렬화기까지 따라가서 정했어요. 최대라는 이름의 필드에 최솟값이 들어가는 것도 그때 알았습니다.
면접 대비로 정리했던 이벤트 루프·V8·마이크로태스크 문답입니다. 당시엔 "면접용 지식"이라고 생각했는데, 이후 실무에서 정확히 이 지식으로 풀린 버그들이 있었어요 — 렌더 직후 getBBox가 0을 주던 문제, 구독 콜백의 stale closure. 문답 정리 뒤에 그 순간들을 붙였습니다.
숙박 큐레이션 플랫폼의 번역 리소스는 TypeScript 객체 한 파일 5,091줄이었고, 키의 상당수가 "가격 범위"처럼 한국어 원문이었습니다. 한국어 키는 한국어 리소스를 거의 안 써도 되게 해 주지만, 그 대가로 영어 리소스가 한국어의 2.7배가 됐고 일본어에는 빠진 키가 1,539개였어요. 경력기술서에 적은 "JSON 관리·동적 로딩"은 코드에 없었습니다.
공항 보안 검색 판독 화면에서 AI가 찾은 물체 상자는 클래스마다 색·임계값·표시 여부 세 값으로 그려집니다. 당시 지원서를 보면 임계값을 직접 입력하는 것과 레이블 위치·상자 표시 옵션은 납품처 한 곳의 요구로 들어온 것이었어요. 그 세 값은 서버 설정 한 벌에서 오는데, 화면 쪽 열두 파일이 각자 같은 주소를 부르고 같은 조회 함수를 복사해 갖고 있었습니다. 보일지와 울릴지를 정하는 경계 비교가 파일마다 달랐던 것까지, 남은 코드로만 되짚었습니다.