⚙️Backend

관리자 페이지 버그 수정 및 안정성 개선: 백엔드 개발자 필수 체크리스트

관리자 페이지 버그 수정 및 안정성 개선: 백엔드 개발자를 위한 필수 체크리스트. 실제 문제 해결 경험 공유.

📅 2026년 6월 1일·📖 6분 읽기·👁 6

관리자 페이지 버그 수정 및 안정성 개선: 백엔드 개발자 필수 체크리스트

관리자 페이지에서 운영 관련 기능들이 불안정하거나 비효율적이라고 느껴지는 경우가 종종 발생하곤 합니다. 특히 블로그 시스템을 운영하다 보면 이런 문제들이 쌓여 업무 효율을 저해할 수 있죠. 이 글에서는 제가 겪었던 몇 가지 문제와 해결 과정을 공유하며, 비슷한 상황에 놓인 개발자분들께 도움이 될 만한 내용을 담았습니다.

시도와 함정

처음에는 블로그 전체 페이지 비활성화를 축소판 통합으로 변경하는 것부터 시작했습니다. 그런데 블로그 축소판 탭에 자동 운영 모니터링 기능을 추가하는 과정에서 예상치 못한 문제에 부딪혔습니다. 메모 모니터링에서 '실패처럼 보이던' 버그가 계속 발목을 잡더군요.

# 예시: 메모 모니터링 관련 코드 (실제 동작하는 코드)
def monitor_memory_usage():
    # ... 메모리 사용량 체크 로직 ...
    if memory_exceeded:
        log_error("Memory usage critical!")
        return False # 이 부분이 잘못된 로직으로 이어짐
    return True

실제 문제: monitor_memory_usage()가 True를 반환해야 하는데,

특정 조건에서 False를 반환하여 '실패'로 오인되는 상황

이후 deploy_status의 git/pgrep PATH 문제도 해결해야 했습니다. PATH 환경 변수가 제대로 설정되지 않아 git이나 pgrep 명령어를 찾지 못하는 상황이었죠. 이 문제를 해결하기 위해 스크립트 내에서 직접 PATH를 설정하거나, 시스템 환경 변수를 조정하는 방법을 시도했습니다.

# 예시: deploy_status 스크립트 내 PATH 설정
export PATH=$PATH:/usr/local/bin:/usr/bin:/bin
/usr/bin/pgrep -f "my_process"

또한, 운영 요청의 과거 데이터를 일괄 백필하고 개선 이력 공개 토글 기능을 추가하는 작업도 진행했습니다. 이 과정에서 feedback_items 스키마의 정합성도 확보해야 했습니다. 특히 priority 컬럼은 제외하고, related_commitstext[] 리스트로 전달하도록 수정했습니다.

-- 예시: feedback_items 스키마 변경
ALTER TABLE feedback_items
DROP COLUMN priority;

-- related_commits를 text[] 타입으로 변경 (PostgreSQL 기준)
ALTER TABLE feedback_items
ALTER COLUMN related_commits TYPE text[];

원인

메모 모니터링의 '실패처럼 보이던' 버그는 사실 로직상의 미묘한 오류였습니다. 특정 조건에서 예상과 다르게 동작하여 마치 실패한 것처럼 보이게 만들었죠. deploy_status의 git/pgrep PATH 문제는 실행 환경의 PATH 설정이 스크립트에서 기대하는 경로와 달랐기 때문에 발생했습니다. 스키마 정합성 문제는 데이터의 일관성을 유지하고 효율적인 관리를 위해 필요한 조치였습니다.

해결

블로그 전체 페이지 비활성화를 축소판 통합으로 변경하고, 블로그 축소판 탭에 자동 운영 모니터링 기능을 추가했습니다. 메모 모니터링 버그는 해당 로직을 면밀히 검토하여 정확한 원인을 파악하고 수정했습니다. deploy_status의 git/pgrep PATH 문제는 스크립트 실행 전에 명시적으로 PATH를 설정하거나, 시스템의 PATH 설정을 조정하여 해결했습니다.

운영 요청의 과거 데이터 일괄 백필 및 개선 이력 공개 토글 기능은 기존 데이터를 보강하고 투명성을 높이는 데 기여했습니다. feedback_items 스키마는 priority 컬럼을 제거하고 related_commitstext[] 타입으로 변경하여 데이터 구조를 최적화했습니다.

# 예시: 수정된 메모 모니터링 로직 (가정)
def monitor_memory_usage():
    # ... 메모리 사용량 체크 로직 ...
    if memory_exceeded:
        log_error("Memory usage critical!")
        return False
    elif potential_issue_detected: # 새로운 조건 추가 및 로직 수정
        log_warning("Potential memory issue detected, but within limits.")
        return True # 이 경우에도 True 반환하도록 수정
    return True

결과

  • 관리자 페이지 운영 기능의 전반적인 안정성이 향상되었습니다.
  • 자동 운영 모니터링 기능 추가로 시스템 상태 파악이 용이해졌습니다.
  • 데이터 백필 및 개선 이력 공개로 운영 투명성이 증대되었습니다.
  • 스키마 정합성 확보로 데이터 관리 효율성이 개선되었습니다.

정리 — 같은 함정 안 빠지려면

  • [ ] 운영 모니터링 로직은 항상 면밀히 검토하고, 예상치 못한 동작에 대한 예외 처리를 꼼꼼히 합니다.
  • [ ] 외부 명령어를 사용하는 스크립트 실행 시, PATH 환경 변수가 올바르게 설정되었는지 확인합니다. 필요하다면 스크립트 내에서 명시적으로 설정합니다.
  • [ ] 데이터 스키마 변경 시, 데이터 일관성과 향후 확장성을 고려하여 신중하게 결정합니다.
  • [ ] priority와 같이 사용 빈도가 낮거나 불필요한 컬럼은 과감히 제거하여 스키마를 간결하게 유지합니다.
  • [ ] related_commits와 같이 여러 값을 가질 수 있는 필드는 배열(list, text[]) 타입으로 저장하는 것을 고려합니다.

태그

#백엔드 개발#관리자 페이지#버그 수정#안정성 개선#메모리 모니터링#PATH 설정#DB 스키마