netmarble

문제동일한 디자인 산출물을 여러 이미지 크기와 언어로 변형해야 하는 일이 많았는데, 기존 Figma 플러그인으로는 이 반복 작업을 매끄럽게 처리하기 어려웠다.

접근TypeScript와 Figma Plugin API로 UI(HTML/CSS)와 로직(code.ts)을 분리해 직접 플러그인을 만들었다. html-inline-css-webpack-plugin으로 경로 문제를 풀고, UI·code.ts 양쪽에서 입력을 이중 검증했으며 WAI-ARIA로 접근성을 챙기고 clientStorage로 입력값을 24시간 보존했다.

결과다국어 프레임 복제와 강조 구문 효과 등 핵심 기능에서 기존 대비 약 50% 이상 작업 속도와 효율이 개선됐고, 실제 디자인 업무에 안착했다.

문제Java 애플리케이션의 초기 구동 시간이 길어 클라우드 환경의 오토스케일링 효율이 떨어진다. MyBatis 같은 프레임워크 제약 탓에 GraalVM 네이티브 이미지는 도입이 어렵다.

접근Application Class-Data Sharing(AppCDS)으로 클래스 로딩 결과를 캐시한다. Spring Boot Layered Jar로 도커 이미지 계층을 분리해 빌드와 배포 캐시 효율도 함께 끌어올렸다.

결과초기 실행 시간을 83초에서 56초로 약 30% 단축했다. 큰 리소스 투입 없이도 JVM 구동 비용을 줄일 수 있음을 확인했다.

문제쿠버네티스의 무상태 파드 구조에서 특정 파드에만 기능을 켜고 파드 사이에 캐시를 공유하기 어려워 심볼리케이션 성능이 떨어졌다.

접근Apache Camel 클러스터링으로 MapReduce 구조를 잡고, 쿠버네티스 Lease 객체로 리더를 선출한 뒤 Hazelcast 분산 캐시로 파드 간 상태를 공유한다.

결과미처리 메시지 적체가 줄고 심볼리케이션 평균 시간이 50% 빨라졌으며, 재배포 후에도 캐시가 유지돼 초기 지연이 사라졌다.

문제워드프레스 업데이트를 검증할 때 웹 파일만 옮기면 DB에 저장된 플러그인 설정이 빠져 테스트 서버가 라이브와 달라진다.

접근셸 스크립트로 MariaDB 덤프와 웹 파일 tar 압축을 한 묶음으로 만들어 원격 서버로 전송하고, 복원 시 도메인 설정을 바꿔 테스트 환경을 자동 구성한다.

결과주 1회 자동 백업과 복원으로 라이브와 동일한 샌드박스를 유지해 분기마다 워드프레스 코어 업데이트를 안정적으로 검증한다.

문제WAS 로그는 공격 탐지와 장애 대응에 필수지만, 기본 설정 그대로 두면 로그 레벨이 부적절하거나 접근 권한이 느슨해 보안 위험과 운영 비효율을 만든다.

접근IIS, Apache, Tomcat, Nginx, Spring Boot, Node.js별로 적절한 로그 레벨과 포맷을 정리한다. Apache는 `LogLevel error`와 `combined` 포맷으로 IP·요청·User-Agent를 남기고, 파일 권한은 디렉터리 750, 파일 640으로 잠근다.

결과공격 탐지에 필요한 필드가 일관되게 쌓이고 WAS 전용 계정만 로그에 접근한다. 저장 공간 낭비와 보안 사고 위험을 함께 줄인다.

문제Windows 작업 관리자의 프로세스 탭과 세부 정보 탭이 같은 CPU 이용률 이름으로 다른 값을 보여 서버 성능 진단이 헷갈렸다.

접근Windows 8부터 도입된 두 가지 측정 방식을 구분했다. % Processor Time 기반 시간 측정인 Usage와 % Processor Utility 기반 주파수 측정인 Utilization을 공식과 함께 비교했다.

결과터보 부스트로 100%를 넘을 수 있는 Utilization과 코어 점유율인 Usage를 함께 봐야 정확한 성능 해석이 가능하다는 결론에 도달했다.

문제넷마블 크래시리포트 시스템은 게임 사용자가 급증할 때 새 파드 준비에 1분 이상 걸렸고 클라이언트 연결 대기는 10~20초라 데이터 유실이 발생했다.

접근Spring Boot 3.0 + GraalVM 네이티브 이미지로 JVM 없이 실행되는 바이너리를 만들고 Alpine Linux와 UPX 압축으로 이미지를 줄였으며 HPA로 자동 스케일링을 묶었다.

결과시작 시간을 50초에서 2초로 96% 줄였고 도커 이미지를 300MB에서 70MB로 77% 줄였으며 최대 파드 증설을 15초 이내로 끌어내려 OOM 발생도 일 1회 미만이 됐다.

문제WAS 운영에서 심볼릭 링크와 파일 업로드 제한 미흡은 시스템 권한 탈취나 서버 과부하를 유발한다.

접근IIS, Apache, Tomcat, NGINX, Spring Boot, Node.js 각 플랫폼별로 심볼릭 링크 비활성화와 요청 바디 크기 제한 설정을 정리한다. Apache는 FollowSymLinks 제거와 LimitRequestBody, Tomcat은 allowLinking=false와 maxSwallowSize, NGINX는 client_max_body_size로 통제한다.

결과5MB~50MB 범위의 업로드 한도와 심볼릭 링크 차단 가이드를 실무 설정값으로 제공한다. 보안 점검 항목을 플랫폼 단위로 표준화할 수 있다.

문제웹 문서에서 제목(H1~H6)을 시각적 꾸밈으로만 사용하면 계층 구조가 무너지고 TOC·접근성·SEO가 깨진다.

접근헤딩 태그를 의미 기반으로 사용한다. 하행은 한 단계씩만 내려가고 상행은 자유, 외형은 CSS에 맡긴다. 마크다운은 1:1 HTML 매칭을 따른다.

결과제목으로 자동 생성되는 TOC가 깔끔해지고 구분선·밑줄을 헤딩으로 흉내내는 안티패턴이 사라진다. 문서가 기둥과 보로 지탱된다.

문제WAS의 버전·종류·OS가 응답 헤더·샘플 파일·기본 에러 페이지로 노출되면 공격자가 알려진 취약점을 즉시 노린다.

접근세 단계로 정보 노출을 차단한다. IIS·Apache·Tomcat의 샘플/매뉴얼을 제거하고, Apache·NGINX·Spring Boot·Node.js의 Server 헤더를 숨기며, 기본 에러 페이지를 WAS 정보 없는 페이지로 교체한다.

결과WAS별 설정 예제와 적용 전후 비교가 정리돼, 관리자가 정보 노출 표면을 빠르게 줄일 수 있다.

문제Doxygen 기본 서버 검색은 공백·숫자 포함 검색어에서 정확도가 떨어지고 WAS별 CGI 실행 설정 가이드도 부족했다.

접근Doxygen 1.8.3 이상의 EXTERNAL_SEARCH 옵션으로 Xapian 검색 엔진을 붙였다. Apache는 CGI 실행 권한, NGINX는 FcgiWrap으로 FastCGI 변환, NGINX+Apache는 리버스 프록시로 구성했다. doxysearch.cgi와 doxyindexer로 인덱스를 생성했다.

결과검색 정확도가 향상되고 30분 안에 배포 가능한 절차를 마련했다. 테크니컬 라이터에게도 운영 환경 이해가 필수임을 강조한다.

문제리눅스 서버의 DNS 클라이언트와 서버 양쪽에 보안 취약점이 존재해 점검·관리 가이드가 필요했다.

접근클라이언트는 resolv.conf와 hosts 파일의 소유자·권한과 신뢰 DNS IP를 확인한다. 서버는 BIND·PowerDNS 패치를 관리하고 allow-transfer로 Zone Transfer 허용 IP를 제한한다. DNSSEC와 DNS 필터링 서비스 도입도 권장한다.

결과ACL 설정과 로그 모니터링으로 DNS 기반 공격 표면을 줄인다. 보안 기초 설정 시리즈의 일환으로 운영자가 바로 적용할 수 있는 절차를 제시한다.

문제WSL2에서 도커 설정 후 터미널을 닫으면 약 20초 뒤 WSL이 자동 종료됐고, Windows 업데이트로 wsl.exe·커널 버전이 바뀌며 기존 설정도 작동하지 않았다.

접근/etc/wsl.conf에 systemd=true를 켜고 /etc/docker/daemon.json에서 -H fd:// 옵션을 제거해 docker daemon 설정을 재구성했다. PowerShell의 start-process wsl.exe -WindowStyle Hidden으로 WSL을 백그라운드에서 살려둔다.

결과nohup 대신 PowerShell 명령어로 WSL을 유지해 도커 워크플로우가 끊기지 않게 했다. systemd 지원으로 도커 관리 효율도 개선됐다.

문제웹 서버의 디렉터리 인덱싱이 켜져 있으면 폴더 구조와 백업·소스 파일이 외부에 노출되는 보안 취약점이 생긴다.

접근WAS별로 인덱싱을 끈다. IIS는 디렉터리 검색 비활성화, Apache는 Options Indexes 제거, Tomcat은 web.xml의 listings=false, Nginx는 autoindex off로 설정한다. 상위 디렉터리 접근은 .htaccess·auth_basic 기본 인증으로 차단한다.

결과초기 서버 환경 설정 단계에서 인덱싱 여부만 확인해도 노출 위험을 크게 줄인다. 기본 정책으로 인덱싱 off를 명시할 것을 권장한다.