Open API를 넘기면서 "운영 전에 백엔드가 정해 줘야 할 것"을 인수인계 문서에 적어 두었습니다. 그중 값을 정할 사람이 나중에 바꿀 수 있는 기본값으로 닫을 수 있는 일을 10월 28일에 했어요. 틀린 키로 계속 부르면 끝없이 쌓이던 접근 로그에 보존 기간과 정리 명령을 붙였고, 정해지지 않은 어휘 주소는 고치는 대신 배포 점검이 경고하게 했고, 프록시 뒤 호스트 설정은 기본값으로 켜 두었습니다. 값을 정하는 일은 그대로 남아 있고, 그 경계도 같이 적었습니다.
표준데이터 검색 카드·상세, OID 카드에 북마크 버튼을 달고 마이페이지에서 모아 보게 했습니다. 버튼은 뒤집기 대신 바라는 상태를 보내고, 저장할 수 있는 범위와 마이페이지에 보이는 범위를 공개 화면과 같은 모집단 함수로 묶었어요. 비로그인에게도 버튼을 보여 주되 CSRF 토큰은 로그인 사용자에게만 싣고, 카드 클릭과 겹치는 버튼은 캡처 단계에서 받았습니다. 테스트 8건과 함께, dev SQLite에서 난 500에 다시 보내기를 붙인 한계도 적었습니다.
관리자 방문 통계 화면을 9월 15일, 10월 12일, 10월 20일에 세 번 다시 짰습니다. 첫 번째에서는 한 번도 걸리지 않던 디버그 경로 제외 조건과, UTC 날짜로 칸을 만들어 새벽 방문이 사라지던 버그를 찾았습니다. 두 번째에서는 같은 회사의 다른 시스템과 화면을 맞추면서 수집기를 옮기지 않고 조회할 때 규칙을 거는 쪽을 골랐고, 세 번째에서는 서버 모니터링과 한 화면으로 합쳤어요. 10월 집계 함수는 다른 시스템 것을 옮겨 왔고, 9월에 잡은 회귀 사례는 새 테스트에 다시 심었습니다.
2020년 코멘토 부트캠프에서 만든 방탈출 리뷰 사이트를 2026년에 Django 6으로 다시 짰습니다. 옛 코드를 zip에서 꺼내 읽어 보니 로그인은 오타 하나로 항상 실패했고, 글쓰기·상세 화면은 URL에 연결조차 안 돼 있었습니다. 무엇을 고쳤는지, 그리고 다시 짠 코드에서 재현한 문제 둘을 테스트와 함께 고친 과정까지 적었습니다.
Open API 토큰은 관리자 직접 발급, 발급 신청 승인, 관리용 REST API 세 곳에서 만들어지고 있었고, 셋 다 그 사용자에게 이미 유효한 토큰이 있는지 보지 않았습니다. "사용자당 유효 토큰 1개" 규칙을 세 곳에 따로 넣지 않고 발급 함수 하나로 모은 뒤, 동시 발급을 막는 잠금은 새로 만들지 않고 계정 삭제가 쓰던 잠금을 같은 순서로 잡았습니다. 만료일을 바꿔 만료 토큰을 되살리는 네 번째 길도 같은 관문에 걸었습니다.
표준데이터 신청서가 원장과 분리된 뒤로는, 심사가 끝나면 등록관리자가 신청서 팝업과 관리 화면을 나란히 띄워 놓고 손으로 옮겨 적어야 했습니다. 그 사이를 한 화면으로 잇는 "신청서 기반 등록"을 만들었어요. 그리고 신청 → 7단계 심사 → 등록 → 공개까지 역할별 계정으로 실제로 끝까지 돌려 보니, 걸린 QA 소견 12건 중 새 화면 자체의 문제는 셋이었고, 절반(6건)은 새 화면이 아니라 그 앞 신청·심사 화면에서 나온 문제였습니다.
통합로그인 연계에는 약관 동의 단계가 어디에도 없었습니다. 어디서 받을지는 백엔드·기관과 정할 일이라 결정 대신 동의 위치별 목업을 먼저 만들었고, 그중 하나를 실제 가입에 붙이면서 개인정보처리방침의 두 조항이 실제 동작과 어긋나 있던 것을 고쳐 테스트로 묶었습니다. 다만 이 작업은 미리보기 브랜치에 남아 있고, 10월 말까지 다른 브랜치에 들어가지 않았습니다.
역할 배정 상세 화면에 2026-09-09 16:47:55.613497+00:00 이 그대로 찍혀 있었습니다. 반대로 설문 관리 화면은 제출일시를 서버 포맷으로 옮기자마자 9시간 앞선 값을 보여 줬어요. 증상이 반대인데 원인은 하나였습니다. 시간대를 서버가 바꾸는지 브라우저가 바꾸는지가 화면마다 달랐거든요. TIME_ZONE을 KST로 옮기고 화면 변환 경로를 전부 지운 뒤 표기를 두 형식으로 통일했습니다. 한 시간짜리 작업이었는데, 이 선택지는 11개월 전 글이 "검토하지 않았다"고 적어 둔 것이었습니다.
표준데이터 신청서는 메시지 한 건을 반드시 써야 제출됐습니다. 엘리먼트만, 프레임만 내는 신청도 있어서 조건을 "셋 중 최소 한 건"으로 풀었어요. 판정은 팀원이 한 입구로 묶어 둔 함수 안의 조건만 바꾸면 됐는데, 정작 어려웠던 건 안내를 어디에 두느냐였습니다. 조건이 세 단계를 가로지르는데 안내는 한 단계 조각 안에 있어서 다른 단계에서 항목을 넣어도 낡은 채 남았거든요. 그리고 같은 규칙을 말하는 자리가 네 곳이었는데, 한 곳이 75분 늦게 따라왔습니다.
신청 처리 이력에 찍힌 승인·반려 시각이 실제로 처리한 때보다 한 단계 앞이었습니다. 심사 액션 행은 대기 상태로 미리 깔리는데, timestamp의 default가 행을 만들 때 한 번 찍히고 완료 처리에서는 갱신되지 않았거든요. 타임라인이 이 값으로 정렬까지 하고 있어서 승인이 그 승인을 낳은 심사 의견보다 위에 설 수 있었습니다. 완료 처리 시점에 시각을 다시 찍고, 대기 행을 한 시간 전으로 밀어 둔 뒤 확인하는 테스트를 붙였습니다.
등록 신청 작성 예시 PDF를 만들어 올렸더니 운영에서 한글이 한 글자도 안 찍혔습니다. 템플릿이 지정한 글꼴이 윈도우와 맥 것이라 우분투에는 아무것도 안 걸렸고, 맥에서는 시스템 글꼴이 잡혀 정상으로 보였어요. 서버 글꼴에 기대지 않고 저장소의 Pretendard를 @font-face로 문서에 심었고, 운영 설정에서 글꼴 파일을 찾는지 테스트로 잠갔습니다. 2월부터 있던 설문 PDF 두 종도 같은 길을 지나게 됐습니다.
운영 인스턴스 7,083건을 dev에 미러링했더니 OID 검색 화면이 뼈대 9건으로 무너졌습니다. 미러가 OID 문자열은 복사하면서 OID 노드는 안 만들었고, 기존 채번 명령으로 채우면 번호를 새로 매겨 1,489건 중 1,107건이 운영과 어긋났어요. 운영 트리의 번호를 그 자리에 그대로 심는 명령을 따로 만들었습니다. 같은 배치에서 카탈로그에 메시지를 매단 다리는 하루 뒤 운영과 다르다는 이유로 다시 걷었습니다.
관리자 사이드바의 신청·심사 메뉴가 열흘 동안 세 자리를 옮겨 다녔습니다. 도메인별 그룹(제가) → 신청/심사 한 그룹(팀원) → 다시 도메인별 그룹(제가). 옮길 때마다 걸린 건 그룹 이름이 아니라 활성 메뉴 판정이었어요. 판정이 "현재 경로에 이 문자열이 들어 있나"여서, 상위 경로를 가진 메뉴가 하위 화면까지 삼켜 두 그룹이 같이 켜졌습니다. 이 글은 그 판정 위에서 메뉴를 옮기는 비용과, 세 번 바뀐 하위 메뉴 이름 규칙에 대한 기록입니다. 9월 2일 작업을 10월 말 이름 정리까지 묶어 정리했습니다.
관리자 상세·수정 화면 여덟 개가 없는 pk를 받으면 500을 냈습니다. 쿼리를 미리 로드하려고 get_object()를 덮으면서 404 처리 없이 .get(pk=)를 직접 불렀거든요. 덮어야 했던 건 "무엇을 가져오나"가 아니라 "어떤 쿼리셋에서 가져오나"였습니다. 여덟 뷰를 get_queryset()으로 옮기니 78줄이 26줄이 됐고, 제네릭 뷰가 원래 하던 404 처리가 돌아왔습니다. 같은 함정이 남은 화면 네 곳은 아직 그대로입니다.
상세 화면 세 곳의 필드명·M/O·최대 반복이 통째로 `-`로 서 있었습니다. 파서는 멀쩡했고 테스트도 34건 통과했는데, 값을 읽어 오려던 슬롯이 어느 클래스에도 등록돼 있지 않았어요. 출처를 필드 자신의 등록값으로 바꾸고, 줄 세우기도 한 곳이 정하게 모았습니다.
JS를 고치고 새로고침해도 화면이 안 바뀌는데 서버를 다시 띄우면 바뀌는 증상이 있었습니다. 범인은 캐시를 깨라고 만들어 둔 add_hash 필터 자신이었어요. 입력이 전부 상수라 Jinja가 컴파일 시점에 한 번 접어버렸고, 그래서 서버 기동 시각이 URL에 굳어 있었습니다. @pass_context로 접힘을 막고 값을 파일 수정시각으로 바꿨습니다.
신청서에서 엘리먼트·프레임·메시지를 직접 쓸 수 있게 했는데, 신청 시점에 만들어 버리면 반려된 신청의 찌꺼기가 목록에 남습니다. 작성분을 JSON 초안 한 칸에 두고 승인 시점에 자식부터 순서대로 재생하게 했어요. 그러다 초안 JSON이 PostgreSQL btree 색인 상한 2704바이트에 걸려 INSERT가 통째로 실패했습니다.
로그아웃 상태로 관리자 공지 목록 주소를 열었더니 화면이 그대로 떴습니다. 같은 파일 안의 분류 뷰 다섯은 막혀 있고 공지 뷰 다섯은 안 막혀 있었어요. 게다가 그중 둘은 GET 요청으로 정렬 순서를 저장하고 있었고, except 절의 bare return 때문에 500까지 났습니다. 믹스인을 붙이면서 붙인 권한 선언이 실은 아무도 안 읽는 값이었다는 것도 같이 적었습니다.
홈 "데이터 현황" 타일은 198건, 그 타일을 눌러 도착하는 목록 화면은 134건이었습니다. 닷새 전에 "타일이 목록으로 링크하니까 목록에 맞춘다"고 결정하고 주석까지 박아뒀는데도 회귀가 샜습니다. 원인은 결정이 아니라 그 결정을 지킨다던 테스트였어요. 기대값을 상수로 박아둔 정합 테스트는 목록 뷰가 조건을 하나 더 붙여도 계속 초록이었습니다.
FAQ와 1:1 문의를 공지사항 Post 모델 위에 얹었습니다. 게시판 종류를 Category 행으로 뒀더니 게시판 추가가 데이터 한 줄이 됐는데, 대신 "문의"라는 한글 문자열이 코드에 박혔어요. 그리고 넉 달 전 제가 "타인 글은 403보다 404가 안전하다"고 써놓고, 정작 이번 구현은 403으로 냈습니다. 왜 그랬는지 따져봤습니다.
엑셀 3개를 읽던 로더 3개를 워크북 1개를 읽는 로더 1개로 합쳤습니다. pandas가 못 읽는 2단 병합 헤더를 openpyxl로 직접 평탄화하고, 시트 순서 의존을 없애려고 유형별 4패스로 나눴어요. 853행에서 중복 6건이 나왔는데 그 승자 규칙에 아직 구멍이 남아 있다는 얘기까지 적었습니다.
카탈로그 PNG 다운로드가 500을 뱉어서 들어갔는데, 원인은 성능 최적화라고 믿고 있던 prefetch_related의 인자 하나였습니다. Dataset에 없는 관계명이라 QuerySet 평가 시점에 AttributeError가 났고, 지연 평가 때문에 선언부가 아니라 버튼 클릭에서 터졌어요. 같은 파일 안에서 따옴표 표기가 갈려 grep이 한쪽만 잡은 이야기와, AST로 인자 478건을 전수 대조한 기록입니다.
인스턴스를 수정해도 목록·다운로드·RDF는 옛 값을 보여줬습니다. 링크 시점에 한 번 복사하고 끝이었거든요. 캐시 제거·조회 시 재계산·쓰기 시 시그널 세 안을 놓고 마지막을 고른 이유와, 감사 로그가 폭발하지 않게 bulk_update로 일부러 시그널을 우회한 트레이드오프를 정리합니다.
로컬(SQLite)에선 멀쩡히 적재되던 메타데이터 로더가 운영(PostgreSQL)에서만 value too long으로 죽었습니다. 프런트 쪽을 주로 맡다가 모델·마이그레이션을 조금씩 만지기 시작한 입장에서, 원인을 어떻게 좁혀갔고 네 가지 선택지 중 왜 TextField를 골랐는지 정리합니다.
관리자가 오퍼레이션을 토글했는데 TTL이 지나야 반영되던 캐시 갭, 그리고 만료된 토큰의 신청 상태가 "승인됨"으로 남던 stale 문제를 정리합니다. 캐시 즉시 무효화와 진입 시점 sync_expired로 "보이는 상태 = 실제 상태"를 맞춘 이야기예요.
FAQ 게시판을 새 모델을 추가하지 않고 기존 Post 모델 + "FAQ" 카테고리로 구현한 회고입니다. 공지사항과 한 모델을 공유하면서 카테고리로 분리하고, 큐레이션 순서 노출·읽기 전용 본문·데이터 적재 커맨드까지 묶은 이야기예요.
항목 수가 늘면서 점점 느려지던 메타클래스 리스트 페이지의 쿼리를 분석하고, select_related/prefetch_related로 정리하면서 의식한 점들을 기록합니다.
백엔드 개발 전 mockup 데이터가 49개라서 페이지네이션·검색·필터 검증이 빈약했던 문제를, 엑셀 파일을 입력으로 받는 시드 스크립트를 만들어 478개로 늘린 과정을 정리합니다.
두 페이지가 따로 들고 있던 jstree 옵션과 이벤트 핸들러를 비교해 차이가 거의 없음을 확인하고, 공통 헬퍼 4종으로 추출한 리팩토링 회고입니다.
약관/방침 페이지와 소개·가이드 페이지에 흩어져 있던 마크업 중복을 base 템플릿 + 공용 매크로 + 외부 스크립트로 정리한 회고입니다.
본인과 관리자만 열람할 수 있는 1:1 비공개 문의 게시판을 Django로 구현한 과정을 정리합니다. 열람 권한, 답변 권한, 첨부파일 재사용 패턴을 다룹니다.
로그인 없이 이메일 한 줄로 구독하고, 발송 메일의 고유 링크로 해지할 수 있는 뉴스레터 시스템을 Django + DRF로 설계한 기록입니다.
일회성 스크립트 대신 Django management command로 crawl_news, send_newsletter, seed_editorial, backfill_urls 네 가지를 설계하며 얻은 기준과 패턴을 정리합니다.
한국어 5개 + 영어 4개 RSS 소스에서 Python/Django 관련 글만 골라 수집하고, HTML 정제와 자동 태깅까지 거치는 파이프라인을 Django management command로 정리한 기록입니다. 나중에 다시 읽으면서 키워드 부분 문자열 매칭과 한글 slugify에서 결함 세 개를 찾았고, 재현 스크립트까지 같이 적었습니다.
헤더에 "쪽지 N개"를 띄우기 위해 모든 뷰에서 카운트를 넘기는 대신, context processor로 전역 주입한 경험과 그 함정을 정리합니다.
시드 데이터를 data migration에 넣을지, 커스텀 management command로 뺄지. 두 방법의 차이와 실제로 언제 무엇을 택해야 하는지 정리합니다.
AbstractUser를 확장한 커스텀 User 모델에 카카오 OAuth 2.0을 얹어, 일반 이메일 가입과 소셜 로그인을 한 테이블에서 공존시키는 과정을 정리합니다.
common 앱에 섞여 있던 설문조사 모델을 독립 앱으로 분리하고 3-tier 아키텍처로 재설계한 과정, 그리고 weasyprint 기반 PDF 다운로드와 개인정보 마스킹 구현을 정리합니다.
OID 관리 화면에서 표준데이터를 연결하려는데 후보 목록에 없는 것이 있었습니다. 후보를 OID-표준데이터 관계 테이블에서 거꾸로 뽑고 있어서, 아직 어디에도 연결되지 않은 표준데이터는 나올 수 없었어요. 동료가 닦아 둔 REST 기반 위에 처음으로 엔드포인트 하나를 팠고, 같은 날 오후 설정 객체를 통째로 덮어써서 주소를 잃어버린 것도 고쳤습니다.
OID 수정 화면에서 상위 항목을 못 바꾸게 parent 필드를 disabled로 뒀더니 저장할 때마다 "유효하지 않은 부모"가 났습니다. clean_parent에 instance에서 부모를 꺼내는 대체 경로를 넣어 막았고, 주석에 "disabled 필드는 cleaned_data에 포함되지 않는다"고 적었어요. 1년 뒤 문서를 다시 읽으니 Django의 disabled는 제출값을 무시하고 initial을 쓴다고 돼 있습니다. HTML의 disabled와 폼 필드의 disabled를 같은 것으로 알고 있던 때의 기록입니다.
객체 식별자 하나를 점 표기법·ASN.1·IRI·URN 네 가지로 보여 줘야 했습니다. 동료가 만든 세 표기법에 IRI를 넷째로 더했는데, 조상 경로를 이어 붙이는 같은 계산이 모델·매니저·화면 스크립트 세 곳에 있었고 저는 세 곳에 한 줄씩 더 얹었어요. 왜 세 곳인지는 나중에 이해했고, 그때는 걷어내지 않았습니다.
django-treebeard의 MP_Node(Materialized Path)를 활용해 계층형 데이터를 DB에 저장하고 효율적으로 조회하는 방법을 정리합니다.
Django ORM에서 자주 발생하는 N+1 쿼리 문제를 진단하고 select_related, prefetch_related로 해결하는 방법을 정리합니다.
settings의 TIME_ZONE이 UTC라 소식지·공지 목록의 날짜가 9시간 어긋나 보였습니다. 첫날 저녁엔 제출할 때 브라우저에서 UTC로 바꾸는 스크립트를 네 필드에만 넣었고, 이튿날 오후엔 목록 세 곳이 innerText를 파싱해 시간대를 바꾸던 JS를 지우고 Jinja 필터가 서울 시간으로 바꾸게 했어요. 시간대 변환이 세 곳에 흩어져 있었다는 걸 그때 처음 봤습니다.
입사 여섯 달 만에 템플릿이 아니라 뷰와 URL부터 짠 첫 화면이 마이페이지였습니다. 첫날은 GET만 받는 TemplateView에 값을 박아 넣었고, 이튿날 입력칸을 열었는데 뷰는 여전히 GET만 받았어요. 사흘째에 UpdateView와 PasswordChangeView로 갈아탔고, 손으로 넣은 비밀번호 눈 아이콘이 스크립트가 붙이는 것과 겹쳐 지웠습니다. 그 과정을 커밋 일곱 개로 돌아봅니다.
카탈로그 관리 폼의 표준데이터 표에서 분류체계 열을 뺐다가 닷새 뒤 "운영에서 이상 없어서" 되돌렸습니다. 뺄 때는 동료의 진단을 따랐고, 되돌릴 때도 쿼리를 세지 않았어요. 그런데 되돌린 열은 그 사이에 뒷받침하던 프로퍼티가 지워져서 두 달 동안 빈 칸이었습니다. 입사 다섯 달째, ORM을 배우면서 화면을 고치던 때의 기록입니다.
Django 마이그레이션에서 RunPython을 사용해 필드 추가 후 데이터를 채우는 방법과 수동 마이그레이션 시 주의할 점을 정리합니다.
Django에서 여러 폼을 한 페이지에서 처리하는 Formset과 부모-자식 관계를 함께 처리하는 Inline Formset의 차이와 사용법을 정리합니다.
Django의 두 가지 뷰 작성 방식인 FBV(함수형 뷰)와 CBV(클래스형 뷰)의 차이점, 장단점, 언제 무엇을 쓸지 정리합니다.
워크플로 관리 화면의 인라인 폼셋 12쌍이 전부 can_delete=False였습니다. 5월에 jquery-formset 라이브러리를 넣으면서 삭제를 켰고, 두 달 뒤 항목을 지우고 다시 추가하면 저장이 어긋나서 폼 인덱스를 직접 다시 매기는 함수를 짰어요. 같은 날 저녁에 숨긴 행을 세지 않던 버그를 잡고 시나리오 20개를 커밋 메시지에 남겼습니다. 그 함수는 1년이 지난 지금도 그대로 돌고 있어요.
분류체계 그래프 화면이 뿌리 노드를 이름으로 찾고 있었습니다. 트리 JSON의 id는 enumerate 인덱스였고, 주소에는 이름이 실렸어요. 둘 다 pk로 바꿨는데, 함수 계약을 바꾸면서 호출하는 쪽 두 곳을 놓쳐 15분 동안 화면이 깨졌습니다. 그날은 "이름보다 pk"까지만 알았고, pk도 밀린다는 건 1년 뒤에 알았습니다.
Django ORM의 핵심 원리와 자주 쓰는 메서드를 표로 정리한 레퍼런스입니다. 뒤에 실무에서 실제로 걸린 지점들을 덧붙였습니다 — 지연 평가가 에러 위치를 속이는 문제, update()가 시그널과 auto_now를 건너뛰는 문제, only()가 오히려 쿼리를 늘리는 경우까지. 정리할 때는 몰랐고 운영하면서 배운 것들입니다.
Django는 MVT 패턴이라는데 MVC와 뭐가 다른지 정리했습니다. 결론은 이름 매핑 하나로 끝나는데(Django의 View = MVC의 Controller), 실무에서 정작 어려웠던 건 그 다음 — "그래서 이 로직은 View, Model, Template 중 어디에 두나"였습니다. 개념 정리 뒤에 그 경계에서 실제로 겪은 것들을 붙였습니다.
Django 폼 렌더링을 돕는 라이브러리 5종(crispy-forms, widget-tweaks, formify, bootstrap5, dynamic-formset)을 비교 조사했던 글입니다. 결말을 붙였어요 — 실제 프로젝트는 이 중 하나가 아니라 둘(crispy + widget-tweaks)을 역할을 나눠 같이 씁니다. 비교표를 만들 때는 후보들이 경쟁 관계인 줄 알았는데, 절반은 보완 관계였습니다. (원래 2022-08로 게시돼 있던 날짜는 본문이 Django 5.2 문서를 참조해 불가능한 날짜라 조사 시점 기준으로 교정했습니다.)
Jinja 템플릿의 문법·필터·상속·매크로를 표로 정리한 레퍼런스입니다. Django 프로젝트에서 Jinja2를 실제로 쓰며 배운 것들을 뒤에 붙였습니다 — url·static이 공짜가 아니라는 것, safe 필터가 사고의 지름길이라는 것, 그리고 원문 필터 표의 예시가 문법부터 틀려 있었다는 고백까지.
2021년 11월, 첫 회사에 다니면서 패스트캠퍼스 Byte Degree 과정 두 개를 수료했습니다. Python & Django Essential(장고스타그램 만들기)과 Data Science with Python(플레이스토어 데이터 분석). 프런트엔드로 일하던 시기에 백엔드를 처음 손댄 기록이라 수료증만이라도 남겨둡니다.