최신이야기 | 브레인즈컴퍼니

주메뉴 바로가기 본문 바로가기

메인 페이지로 이동
블로그
최신이야기

블로그

최신이야기

기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 기술이야기 [Zenius Case#2] 서버관리, 서버가 왜 이렇게 느리지? 평온한 오후 퇴근 준비가 한창인데 불길한 전화가 걸려 옵니다. “서비스가 먹통이어서 확인 좀 해야 하는데 서버가 엄청 버벅거리고 반응이 느려요!! 이거 왜 이러죠??” 왜!! 도대체 왜!! 한 번쯤은 겪어보았을 급작스러운 Linux 서버의 상태 이슈! 불행하게도 무척이나 다양한 원인으로 인해 발생하게 됩니다. 우리의 목표는 이 다양한 원인 중 실제 발생 원인을 빠르게 특정하는 것! 기본적인 항목들의 체크리스트를 통해 빠르게 원인을 파악 해 봅시다. Linux 서버 상태 이슈 체크리스트 1. 서버의 CPU 부하 확인하기 2. BUFFER, CACHE, SWAP 상태 확인하기 3. 디스크 상태 확인하기 Zenius를 통한 데이터 추이 분석!! 장애의 발생은 순식간에 일어나지만, 장애 발생 시점의 데이터만을 확인해서는 원인을 파악하기가 쉽지 않은 경우가 많습니다. Zenius를 활용하여 앞서 정한 체크리스트를 빠르게 확인해 봅시다. 1. 서버의 CPU 부하 확인하기 - CPU 부하 확인의 Point는 Load Average Load Average는 CPU 사용 대기 중인 프로세스와 I/O 완료를 대기하고 있는 프로세스의 수를 의미합니다. 따라서, Load Average가 높다는 것은 CPU가 바쁘며 시스템에 걸리는 부하가 있다는 뜻입니다. 화면과 같이 1분, 5분, 15분의 로드 평균을 확인 해 보도록 합시다. 1분 로드 평균은 순간적으로 증가하는 경우가 있지만, 5분 15분 데이터상에도 이전과 비교하였을 때 높은 수치를 보인다면, CPU의 부하가 의심스러운 상황입니다. 그렇다면 CPU의 사용률과 I/O 대기율은 어떨까요? user가 사용한 CPU 사용률은 일정하지만, Iowait 수치가 올라간 것을 볼 수 있습니다. 이 경우 CPU의 리소스 부족이기보다는 I/O로 인한 부하로 판단할 수 있고, 자세히는 메모리나 프로세스의 현황 확인이 필요한 경우입니다. 반대로 user 수치가 높은 경우에는 물리적인 CPU 자체의 리소스 부족이라 볼 수 있습니다. 2. BUFFER, CACHE, SWAP 상태 확인하기 - 메모리 사용률과 Swap, Buffer, Cache 메모리 사용률이 높다 = 서버에 부하가 있다?? 답은 No !! Linux 서버의 메모리 사용률은 Buffer/Cache의 사용량이 포함되어 표현되게 됩니다. 따라서, 우리는 그 추이를 통하여 이슈를 확인하는 것이 중요합니다. 위의 검은 바탕의 그래프는 메모리 사용률이 높지만, 일정한 수치를 유지하고 있습니다. 이런 경우 서버의 메모리 사용은 안정적인 영역에서 이루어진다고 판단이 가능합니다. 그 이유는 실제 메모리 사용량과 Buffer/Cache에 할당량의 수치가 할당 가능한 수치 내에서 이루어지기 때문에 사용률이 유지된다고 볼 수 있기 때문입니다. 반면 흰 바탕의 그래프는 메모리 사용률이 점차 증가하며 결국 100%까지 도달한 것을 확인할 수 있는데요, 이경우에는 프로세스가 연산에 필요한 공간을 할당받지 못하여 프로세스 행이 발생하게 됩니다. 그렇다면 Buffer Cache Swap은 어떨까요? 먼저 Buffer Cache에 관해 확인 해 보도록 하겠습니다. *Buffer – 메타데이터를 메모리에 저장. *Cache – Page Cache, Slab을 메모리에 저장. 쉽게 말해, 둘 다 용도에 맞는 정보를 저장하여 수행 속도에 도움을 주는 영역입니다. 메모리 사용량이 늘어나면 이 Buffer, Cache 영역이 줄어들게 되고, 저장 영역이 줄어든다는 것은 속도가 떨어져 성능 저하로 이어지게 됩니다. 아래 그래프는 메모리 사용률이 올라가고 있는 상태의 서버 데이터입니다. 다음으로 이 시점의 Buffer, Cache의 영역을 확인해 보겠습니다. 추이 그래프를 통해 메모리 사용률이 올라갈수록 Buffer, Cache 영역이 줄어드는 것을 확인할 수 있습니다. 그렇다면 이 시점의 I/O는 어떨까요? 보시는 바와 같이 Iowait 수치가 급격히 올라갔음을 확인 할 수 있으므로, “메모리 사용률의 상승은 Buffer, Cache 영역을 줄어들게 하여 속도 저하를 발생시킨다.” 라는 결론을 도출할 수 있습니다. 또한, 메모리 사용률의 상승은 Swap에도 영향을 끼치게 됩니다. *Swap – 디스크 공간에 할당하여 메모리 역할로 사용하는 공간. 따라서, Swap 영역의 사용은 실제 메모리가 아닌 디스크를 사용하기 때문에 속도 저하가 발생 됩니다. 위 그래프는 Swap 사용률이 증가하고 있는 서버의 데이터입니다. 이 시점의 디스크의 상태를 보면 Read와 Write가 점차 Swap과 동일하게 상승하는 것을 볼 수 있습니다. 이렇게 메모리 대신 디스크 영역을 사용하면서 속도가 저하하게 되는 것입니다. 3. 디스크, 확인하기 - Mount Point 별 디스크 사용량, 작업량 추이 확인 디스크의 여유 공간이 없으면 시스템이 파일 생성을 못 하게 되고 결국엔 서버의 운영에 영향을 끼치게 됩니다. 각각의 마운트 지점의 사용률을 체크하여 여유 공간을 확보하는 것이 필요합니다. 디스크의 사용량이 급작스럽게 늘어난 경우는 신규 파일이 업로드되었다거나, 로그파일이 급작스럽게 많이 쌓이는 경우가 있습니다. 그렇기에 각 Mount Point의 사용률을 확인하고 해당 지점의 이슈 사항을 파악하는 것이 가장 좋습니다. 위 그래프와 같이 1시간 이내에 /data 지점의 사용률이 급등하였다면, 해당 지점에 쌓이는 데이터나 로그파일이 급격하게 증가한 것이므로 확인이 필요합니다. 다음으로는 디스크 사용 추이를 확인 해 보도록 하겠습니다. 서버에서 사용하는 물리 디스크는 각각의 성능의 한계가 있습니다. 이 한계를 직관적으로 확인할 수 있는 데이터로는 Disk Busy Rate(작업률)와 Disk Wait Rate(대기율)이 있는데요, Read 및 Write의 양이 한계치까지 치솟게 된다면 Busy Rate 값이 증가하게 되고, 이에 따른 Wait Rate 가 늘어나면서 서버의 성능 저하를 불러오게 됩니다. 어떻게 관리해야 할까? 앞서 확인한 서버의 상태 이슈들, 물론 급작스럽게 발생하는 경우는 어쩔 수 없지만 미리 대비가 가능한 것들은 Zenius-EMS를 이용하여 임계치 기반의 사전 모니터링과, 모니터링 페이지를 통한 직관적인 관리가 가능합니다. 각각의 항목들에 세부적으로 단계별 임계치를 걸어서 서버의 상태 이슈를 사전에 인지하고, 요약 페이지를 통해 빠르게 상태를 파악하여 우리의 퇴근 시간을 사수해 보는 건 어떨까요? 2023.08.08
기술이야기 서버 모니터링, 서버 관리, 서버 관리자 기술이야기 서버 모니터링, 서버 관리, 서버 관리자 서버는 기업의 IT 인프라를 구성하는 필수 요소입니다. 서버는 클라이언트에게 네트워크를 통해 정보나 서비스를 제공하는 컴퓨터 시스템으로, ▲파일 저장 및 공유 ▲웹사이트 및 애플리케이션 호스팅 ▲프린터 및 스캐너와 같은 네트워크 리소스 관리 ▲이메일 서비스 제공 등 다양한 기능을 수행합니다. 일반적으로 Microsoft Windows Server, Linux 또는 Unix와 같은 다양한 운영 체제를 실행하며, 가동 중지 시간을 최소화하면서 지속적으로 실행되도록 설계됐습니다. 오늘날과 같이 급변하는 비즈니스 환경에서의 서버 중단은 상당한 수익 손실과 평판 손상으로 이어질 수 있습니다. 이에 따라 기업은 서버 모니터링 및 관리를 위해 문제를 신속하게 식별하고 해결할 수 있는 강력한 서버 모니터링 시스템을 필수적으로 갖춰야합니다. 서버 모니터링과 서버 관리는 서버의 성능을 최적화하고 가용성을 보장하는데 중요한 관련이 있습니다. 이 블로그에서는 서버 모니터링과 서버 관리에 대해서 알아보고, 마지막으로 서버관리자가 어떤 일을 하는지 논의해 보고자 합니다. 먼저, 서버 모니터링과 서버 관리의 차이점은 다음과 같습니다. ------------------------------------------ 서버 모니터링이란? 서버 모니터링에는 도구와 소프트웨어를 사용해 서버의 성능, 상태 및 가용성을 추적하는 작업이 포함됩니다. 여기에는 CPU 사용량, 메모리 사용량, 디스크 공간, 네트워크 트래픽 및 애플리케이션 성능과 같은 모니터링 지표가 포함됩니다. 서버 모니터링의 목표는 문제가 발생하기 전에 잠재적인 문제를 감지하고, 문제가 발생할 때 문제 해결을 위한 데이터를 제공하는 것입니다. 서버 모니터링은 일반적으로 특수 도구를 사용해 자동화되는 프로세스입니다. 서버 관리란? 서버 관리는 서버가 최적으로 작동하도록 서버를 능동적으로 유지∙관리하고 구성하는 프로세스입니다. 여기에는 운영 체제, 소프트웨어 및 응용 프로그램의 설치 및 구성, 사용자 계정 및 사용 권한 관리, 백업 및 복원 수행, 서버 환경의 보안 및 규정 준수 보장 등의 작업이 포함됩니다. 서버 관리의 목표는 서버가 최고의 효율성으로 실행되고 안전하며, 사용자에게 필요한 서비스를 제공할 수 있도록 하는 것입니다. 요약하면, 서버 모니터링은 관찰 및 경고에 중점을 두는 반면, 서버 관리는 성능을 최적화하고 가용성을 보장하기 위해 서버를 능동적으로 구성하고 유지∙관리하는데 중점을 둡니다. 서버 모니터링은기업의 서버 관리자가 담당합니다. 서버 관리자는 기업의 비전과 전략을 달성하기 위해 서버를 비롯한 IT 시스템의 방향을 수립하는 IT 전문가입니다. 서버 관리자는 높은 수준의 가동 시간과 가용성을 보장하고 서버, 시스템 및 애플리케이션의 소프트웨어 및 하드웨어 기능과 같은 구성 요소를 평가합니다. 서버 관리자의 주요 업무는 조직의 규모와 특정 요구 사항에 따라 다를 수 있지만, 일반적으로 아래와 같습니다. 서버 관리자의 주요 업무 1. 서버 설치 및 구성 서버 설치 및 구성은 서버 관리자의 필수 업무로, 서버 하드웨어, 소프트웨어 및 네트워크 인프라에 대한 기술적 전문 지식, 세부 사항에 대한 주의 및 철저한 이해가 필요한 복잡한 작업입니다. 서버 관리자는 최적의 성능, 보안 및 안정성을 제공하는 동시에 서버가 조직의 요구사항을 충족하도록 올바르게 설치 및 구성됐는지 확인해야 합니다. 2. 서버 모니터링 및 유지보수 서버의 안정성과 성능을 유지하기 위한 핵심 업무입니다. 서버 관리자는 서버 하드웨어 및 소프트웨어를 유지∙관리해, 서버가 효율적이고 안전하게 실행되도록 하고 시스템 성능을 모니터링해 잠재적인 문제를 식별합니다. 3. 서버 보안 서버 보안 관리는 서버에 저장된 데이터의 기밀성, 무결성 및 가용성을 손상시킬 수 있는 잠재적인 보안 위협으로부터 서버를 보호하는 것과 관련된 업무입니다. 서버 관리자는 서버가 잠재적인 보안 위협으로부터 보호되고 서버가 관련 규정 및 표준을 준수하는지 확인하기 위해 적극적으로 노력합니다. 4. 서비스 제공 및 지원 서비스 제공 및 지원은 서버 서비스 및 응용 프로그램의 배포, 유지 및 지원 관리와 관련 있습니다. 이 업무는 서버 가용성을 유지하고 사용자 요구 사항을 충족하는데 중요하며, 서버 관리자는 사용자가 필요할 때 시기 적절하고 효과적인 지원을 받을 수 있도록 합니다. ------------------------------------------ 이처럼 서버 관리자는 서버가 원활하고 안전하며 효율적으로 실행되도록 하는데 중요한 역할을 합니다. 서버 관리자는 복잡한 기술적 지식을 보유해야 하고 빠른 대처 능력을 요구받으며, 보안 대응 및 최적화 작업 등에서 많은 어려움을 겪습니다. 더욱이 서버가 기능에 따라 세분화돼 일반 서버, 웹 어플리케이션 서버, 데이터베이스 서버 등으로 나뉘게 되면 각 기능별로 웹 애플리케이션 서버관리자나 데이터베이스 서버관리자 등으로 관리자의 역할이 세분화되기도 합니다. 서버의 수나 종류가 많아지고 구성이 복잡해지면 모니터링과 관리가 어려워집니다. 이를 돕기 위해 브레인즈컴퍼니의 Zenius(제니우스)와 같은 통합 서버 모니터링 및 관리 소프트웨어가 필요하게 됩니다. 2023.05.09
기술이야기 [통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기 기술이야기 [통합로그관리] Filebeat에서 안정적으로 하드웨어 자원 사용하기 Filebeat는 Elastic Stack에서 사용하는 경량(light-weight) 데이터 수집기로 logstash 대비 상대적으로 리소스(CPU와 RAM)를 상당히 적게 소모한다는 장점이 있습니다. 또, Filebeat는 간단한 필터 기능도 제공합니다. 하지만 말 그대로 간단한 필터 기능이라 한번에 대용량의 파일을 관리해야 하는 경우 호스트 서버에 부담이 갈 정도로 많은 리소스를 사용할 수 있습니다. 따라서 브레인즈컴퍼니가 운영하는 통합로그관리 에이전트는 호스트의 서버 환경에 따라 filebeat 에이전트의 설정 파일을 수정해서 안정성을 제공하고 있습니다. 본 내용은 Filebeat 리소스 점유율이 높을 때 트러블슈팅 관련 설정 수정사항입니다. 수정에 필요한 기본 파일 위치 linux : /etc/filebeat/filebeat.yml docker: /usr/share/filebeat/filebeat.yml filebeat 프로세스 메모리 확인하는 방법 top -d 1 | egrep "PID|filebeat" 수정에 앞서 filebeat의 메인 컴포넌트인 harvester의 개념을 간략하게 설명하겠습니다. 하나의 harvester는 하나의 파일을 읽어드립니다. harvester가 실행 중인 경우 파일을 한 줄씩 읽습니다. 각 파일 당 하나의 harvester가 실행됩니다. 상단의 이미지를 보면 filebeat의 컴포넌트인 input과 harvester가 보입니다. 또한 filebeat이 harvester를 관리하며 어느 파일을 읽을지 관리하는걸 알 수 있습니다. harvester가 실행 중인 경우 파일 설명자(File Descriptor) 열린 상태로 유지됩니다. 이는 파일이 삭제되거나 파일명이 변경된다 하더라도 파일을 계속 읽게 해줍니다. 하지만 파일 설명자는 harvester가 닫힐 때까지 디스크 공간을 예약합니다. 1. filebeat.inputs: 2. - type: filestream 3. id: my-filestream-id 4. paths: 5. - /var/log/system.log 6. - /var/log/wifi.log 7. - type: filestream 8. id: apache-filestream-id 9. paths: 10. - "/var/log/apache2/*" 11. fields: 12. apache: true 13. fields_under_root: true <filebeat에서 제공하는 input example> 1. scan_frequency 파일비트가 설정된 filebeat_inputs의 path에 있는 파일들의 갱신 여부를 체크하는 주기입니다. 너무 길게 설정하면 한번에 많은 파일들을 수집하게 됩니다. 반대로 너무 짧게 설정하면 스캔을 너무 잦게 해서 CPU점유율이 올라갑니다. 적당한 조절이 필요합니다. 기본값은 10초입니다. Scan_frequeny가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency 만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 2. backoff Backoff 옵션은 파일비트가 얼마나 더 적극적으로 크롤링 하는지 지정합니다. 기본값은 1인데 1일 경우 새 줄이 추가될 경우 1초마다 확인한다는 의미입니다. Backoff가 동작하는 방식은 아래와 같습니다. harvester 읽기 종료 또는 파일 삭제 → scan_frequency만큼 대기 → 파일 갱신 확인 → 파일 갱신 시 새 harvester 시작 → 파일 갱신 시 Backoff 시간 마다 다시 확인 3. max_procs 파일비트에서 동시에 사용 가능한 최대의 cpu코어의 숫자를 설정합니다. 예를 들어32 CPU코어 시스템에서 max_procs를 1로 설정한다면 cpu사용률은 3.2%(1/32)를 넘지 않습니다. max_procs 설정돼 있으면 harvester가 아무리 많이 생성돼도 cpu의 코어 수만큼 CPU를 점유합니다. 4. harvester_limit harvester의 수가 OS가 감당할 수 있는 파일 핸들러 개수를 초과할 때 사용합니다. 한 input마다 설정되므로 inputs이 5개 선언돼 있으면 해당 input 컴퍼넌트의 harvester 개수 최대치는 5개입니다. 기본값은 0인데, 0일 경우 harvester가 무제한으로 생성 가능합니다. 리소스 관리 최적화에도 유용한데 예를 들어, input1이 input2보다 파일 개수가 3배 많고 중요성이 높을 때 3배 높은 값을 설정하는 것이 좋습니다. 5. close_eof harvester에 의해 파일이 수집되고 있을 때, EOF(End of File)에 도달하는 즉시 파일을 닫습니다. 파일이 계속 갱신된다면 데이터가 유실될 수 있는 여지가 있습니다. [참조] https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-log.html 2022.11.17
기술이야기 통합로그관리가 필요한 3가지 이유 기술이야기 통합로그관리가 필요한 3가지 이유 로그는 IT 인프라에서 발생하는 모든 상황들을 기록한 데이터입니다. 쉽게 말해 사용자가 어떤 루트로 사이트에 접속했고, 접속한 시점부터 어떤 행동을 취했는지가 모두 기록으로 남게 되는데, 이 기록들이 로그입니다. 로그는 IT 환경에서 가장 많이 발생하지만, 데이터 처리 기술이 발달하지 않았던 시기에는 처리 비용에 비해 가치가 낮은 데이터로 여겨졌습니다. 하지만 최근들어 IT 서비스와 인프라가 다양해지고 디지털 트랜스포메이션이 가속화되면서, 로그의 양이 기하급수적으로 증가하고 사물인터넷(IoT), 빅데이터 등과 같은 신기술이 발전하면서 그 효용성 또한 날로 증가하고 있습니다. 그렇다면, 이 로그는 실제로 어떻게 활용될까요? 개발 영역에서는 버그 혹은 크래시율 수집 및 상시 트래킹, 이슈 발생 후 롤백 및 대응, 특정 기능에 대한 사용성 진단에 활용됩니다. 마케팅 분야는 채널별 ROI 진단 및 비용 최적화, 배너/프로모션/이벤트 효과 측정, 유저 세그멘테이션 및 타게팅에 사용합니다. 기획 및 디자인 영역은 기능 개선을 위한 A/B 테스트, 유저 Journey 경로 분석을 통한 UX/UI 최적화 등에서 쓰이고 있습니다. 이처럼 여러 영역에서 다양하게 쓰이는 로그를 관리하지 않고 방치해두면 어떤 일이 발생할까요? 통합로그관리가 필요한 이유에 대해 알아보겠습니다. ----------------------------------------------- I. 보안 대응체계 구축 저장만 하고 관리되지 않은 로그는 IT 시스템의 장애나 문제 발생 시 그 원인을 찾아내기가 어렵습니다. 또, 로그 데이터의 중요 정보가 외부로 유출될 위험도 커집니다. 끊임없이 발생하는 보안 사고에 대비하기 위해 통합로그관리는 반드시 필요합니다. 관리된 로그는 장애나 사고 발생 시에 그 원인을 파악하고 빠른 대처를 위한 근거 데이터로 사용할 수 있으며, 보안 체계를 마련하는 데에도 활용가능 합니다. 기업들은 로그관리 제품을 사용해 사이버 침해위협을 예방 및 감시하고, 정기적인 로그분석을 통해 강력한 보안대응체계를 구축하고 있습니다. 통합로그관리 솔루션은 보안장비(Firewall, IDC, IPS 등)의 로그와 해킹, 악성코드 등 보안/침해 관련 로그를 지속적으로 분석해 예방 체계를 구축합니다. 또, 대용량 로그의 상관분석을 통해 보안위협을 탐지하고 이상징후를 모니터링하는 등 강력한 보안 대응체계를 구축할 수 있습니다. II. 컴플라이언스 준수 로그는 보안 사고가 발생했을 때 가장 기본적인 증거 및 모니터링 자료로 활용됩니다. 이에 따라 정부에서는 데이터 관리에 대해 각종 법률을 규정하고 있어, 공공기관을 비롯한 개인정보를 다루는 온라인 사업자 및 기업 등은 해당 법규를 준수해야 합니다. 안전한 데이터 이용을 위해 2018년에 발의된 '데이터 3법' 개정안은 2020년 1월 9일 국회 본회의를 통과했습니다. 데이터 3법은 개인정보 보호법, 정보통신망 이용촉진 및 정보보호 등에 관한 법률, 신용정보의 이용 및 보호에 관한 법률 등 3가지 법률을 통칭합니다. 로그 관리 관련 규제의 주요 내용은 다음과 같습니다. i. 개인정보보호를 위해 접근 권한 부여, 변경 또는 말소 기록을 3년 이상 보관해야 합니다. ii. 개인정보 취급자는 개인정보처리시스템의 접속기록을 월 1회 이상 점검해야 하고, 그 활동의 증거를 남기기 위해 시스템에 접속했다는 기록을 1년 이상 보관해야 합니다. iii. 정보통신서비스 제공자는 접근 권한 내역을 5년간 보관하고, 접속 기록의 위·변조 방지를 위해 반드시 백업 보관해야 합니다. III. 빅데이터 처리 플랫폼 IT 인프라 확대 및 기타 비정형 로그 유입에 따라 대용량 로그에 대한 관리가 요구되고 있습니다. 특히 수집된 로그를 실시간으로 분석∙판단해 IT 서비스의 안정적 운영을 도모해야 하는 수요가 증대되고 있는데요. 오늘날의 데이터는 기존 데이터에 비해 양이 매우 방대해 기존 방법이나 도구로는 관리가 어렵습니다. 따라서 빅데이터 기술을 기반으로 하는 대용량 통합 로그관리 솔루션은 이제 IT 운영을 위한 필수 솔루션으로 자리잡았습니다. ----------------------------------------------- 이처럼 기업은 보안위협 및 이상징후 대응/컴플라이언스 준수/대용량 로그 관리를 위해 통합로그관리 솔루션을 필수로 갖춰야합니다. 브레인즈컴퍼니의 통합로그관리 솔루션 '제니우스(Zenius) Logmanager'는 이기종 장비에서 발생되는 정형∙비정형 로그 데이터의 수집/분석/관리 등을 위한 빅데이터 플랫폼입니다. 제니우스 로그매니저가 어떻게 구성돼 있는지 살펴보겠습니다. 제니우스 로그매니저는 정형/반정형 또는 비정형 로그에 대한 실시간 수집 및 신속한 분석 기능을 제공하며, 이러한 정보들을 다양한 차트와 대시보드를 통해 직관적으로 가시화합니다. 특히 로그매니저는 독보적인 인덱싱 및 검색 속도를 제공하며 확장성, 편의성, 효율성, 호환성 등의 특장점을 보유한 제품입니다. 로그 이벤트 발생 시 즉각적인 알람을 통해 빠른 문제 해결과 높은 가용성을 확보하도록 지원합니다. 2022.11.10
사람이야기 디자이너를 그만두고 개발 일을 하는 이유 사람이야기 디자이너를 그만두고 개발 일을 하는 이유 브레인즈컴퍼니에는 5개의 개발그룹이 있습니다. 그 중 브레인즈 대표 제품인 Zenius EMS의 웹 개발을 총괄하고 있는 개발2그룹의 그룹장, 성준님을 만나봤습니다. 성준님은 학석〮사로 산업디자인을 전공했는데요. 디자인 전공자가 어떻게 개발그룹장을 맡게 됐을까요? 성준님이 개발 일을 하게 된 사연 그리고 다양한 팀이 모여 있는 개발2그룹의 일하는 방식 등에 대해 이야기를 나눠봤습니다. ---------------------------------------------------------------------------- Q. 안녕하세요, 성준님. 자기소개 부탁드립니다. 연구개발본부 개발2그룹 그룹장으로, Zenius EMS의 웹개발을 책임지고 있습니다. 브레인즈컴퍼니에는 2010년 12월부터 근무하기 시작해 현재 12년째네요. 브레인즈에 오기 전에도 주로 웹개발을 했고, 때에 따라 SI프로젝트 PM도 했습니다. Q. 전공이 산업디자인이라고 들었습니다. 디자인 전공으로 석사까지 하신 후 개발자로 전향하신 계기가 있을까요? 대학교 1학년 때는 디자인 전공이 아니었고, 당시 학부별로 신입생을 뽑아서 자연과학부로 입학했어요. 2학년 때부터 산업디자인을 해야겠다는 마음을 먹고 겨울방학 때 한두 달 정도 미술학원에서 드로잉의 기초적인 것들을 배운 후, 대학 3년과 대학원 2년 동안 산업디자인 공부를 했습니다. 당시에 사용자 인터페이스에 관심이 많았고, 석사 논문도 사용자 인터페이스가 주제였어요. 석사 2년차 때, 대우전자와 삼성SDS에서 근무하던 선배를 통해 입사제안을 받았습니다. 그런데 행운인지 불행인지 두 회사의 면접일이 같아, 한 곳을 선택해야만 했어요. 대우전자에 가게 된다면 제품 디자인을, 삼성SDS는 소프트웨어 개발 관련 디자인 업무를 할 수 있었어요. 저는 사용자 인터페이스와 같은 소프트웨어 개발 쪽의 디자인 업무를 하고 싶어 삼성SDS로 면접을 갔고 삼성에 입사하게 됐습니다. 당시 삼성SDS(前 삼성데이터시스템)는 SI 사업도 하고 삼성 그룹 계열사의 SM 업무도 했습니다. 또 하이텔, 천리안과 같은 유니텔이라는 PC 통신 서비스도 제공하고 있어서, 입사 전에는 유니텔의 GUI를 담당하거나 UI 관련 업무를 할 것이라고 예상했어요. 그런데 제가 병역특례 전문연구요원으로 근무하는 것이라서, 제 예상과는 다르게 연구소 소속으로 소프트웨어 연구 및 개발 업무를 하게 됐습니다. 당시 삼성SDS에 입사하면 수 개월 동안 PowerBuilder, Oracle 같은 개발 교육을 받은 후에 부서로 배치됐고, 이런 교육 덕분에 소프트웨어 개발 업무에 쉽게 적응할 수 있었죠. 또, 학부 때 컴퓨터 프로그래밍 과목을 여러 개 수강하면서, 디자인보다는 소프트웨어 개발이 제 적성에 더 맞는다고 생각하고 있었고, 이렇게 첫 직장 생활을 소프트웨어 개발자로 시작하게 됐습니다. 이후 27년 동안 쭉 소프트웨어 개발을 하고 있습니다. Q. 이제 부서 이야기를 해볼게요. 개발2그룹에서는 어떤 업무를 진행하고 있나요? 개발2그룹은 인프라웹팀, ITSM팀, 디자인팀으로 구성돼 있습니다. 먼저 인프라웹팀은 우리 회사매출의 90% 이상을 차지하고 있는 Zenius EMS의 웹 업무를 담당하고 있어요. 신규 인프라 혹은 장비의 성능을 모니터링하는 기능을 추가하거나, 사용자 편의성 개선 등의 고도화 업무, 보고서/대시보드 같은 고객사별 커스터마이징 개발 등의 업무를 주로 하고 있습니다. ITSM팀은 IT 부서에서 IT 서비스를 운영하는데 필요한 업무 프로세스를 돕는 Zenius ITSM 제품을 개발하고 이를 기반으로 고객사에 구축하는 프로젝트를 수행하는 팀입니다. ITIL이라는 표준을 바탕으로 장애처리, 서비스요청과 같은 업무를 IT 부서에서 원활하게 수행할 수 있도록 프로세스를 구축하고 이를 시스템으로 처리할 수 있게 합니다. 최종적으로 IT서비스 수준을 한 단계 높이는 일을 하고 있어요. 마지막으로 디자인팀은 브레인즈의 모든 제품과 솔루션의 디자인을 책임지고 있습니다. 고객사별 대시보드 디자인을 하고, 모든 브레인즈 제품의 GUI 디자인, UI/UX 기획, 정보시각화 등의 업무를 합니다. Q. 팀마다 분위기가 다를 것 같은데요. 각 팀별 일하는 방식에 대해 설명해주세요. 아무래도 팀별로 업무가 아주 다르다 보니, 일하는 방식도 업무에 맞춰서 변하는 거 같습니다. 인프라웹팀은 코드리뷰와 공유 회의를 통해서 업무가 진행됩니다. 다양한 고객사로부터 다양한 요구사항이 들어오기 때문에 이전에 했던 유사한 개발 업무가 무엇이었는지, 어떻게 개발했는지 개발자끼리 공유하는 일이 매우 중요해요. 회의를 통해서도 공유하지만, 다음 개발자를 위해 개발 이력도 문서화를 잘 해놓고 있어요. ITSM팀은 팀장이 주도적으로 제품 개발을 리딩하면서, 개발자 모두가 하나의 목표로 똘똘 뭉칠 수 있게 개발자 한 명 한 명을 독려하면서 일하고 있습니다. 디자인팀의 경우, 결과물은 눈에 보이지만 고객의 요구사항은 눈에 보이지 않고 설명하기 어렵기 때문에, 타 부서 및 팀 내에서도 커뮤케이션이 활발하게 이뤄지고 있어요. 또, 브레인즈의 디자인 아이덴터티를 견고하게 만들기 위해서 디자인 크리틱도 자주 합니다. Q. 개발2그룹에 신규 입사자가 들어온다면, 어떤 스타일의 동료가 합류했으면 하는지 궁금합니다. 신뢰할 수 있는 동료. 제가 지금까지 직장생활을 하면서 가장 중요하다고 생각하는 것은 신뢰입니다. 항상 솔직하게 말하고, 자기 말에 책임지는 행동을 하는 동료였으면 좋겠어요. 아무리 실력이 좋더라도 신뢰할 수 없다면, 그 실력도 신뢰하기 어렵게 되는 거 같아요. 모든 인간이 완벽할 수 없기 때문에 조금 실력이 부족하더라도 신뢰할 수 있는 사람이라면, 동료와 서로 부족한 부분을 채워 나가며 무슨 일이든 해낼 수 있다고 생각합니다. Q. 신규 입사자는 브레인즈컴퍼니에서 어떤 성장을 기대할 수 있을까요? 인프라웹팀에서 일하게 되면 1,000여 개의 레퍼런스를 가진 제품은 어떤 모습이어야 하는지를 배울 수 있습니다. 많은 고객들의 다양한 요구사항을 어떻게 제품에 녹여야 하는지, 그리고 그 많은 사이트를 어떻게 관리해야 하는지를 배울 수 있어요. 또, 성능상의 문제없이 방대한 양의 성능 데이터를 어떻게 다뤄야 하는지도 배울 수 있습니다. ITSM팀에서는 다양한 회사에서 IT서비스를 어떻게 관리하는지 직접 경험하고, 이를 제품에 어떻게 포함하는지 배울 수 있어요. 현재 최신 버전의 Zenius ITSM이 고객을 하나씩 늘려가고 있는데요. 새 버전의 제품이 어떻게 업그레이드돼 가는지, 고객의 요구사항은 무엇이고 이것을 제품에 어떻게 녹이는지도 경험하면서 제품과 함께 자신도 성장해 나가는 경험을 할 수 있습니다. 디자인팀에서는 패키지 소프트웨어의 GUI 디자인을 직접 경험할 수 있고, UI/UX 기획도 해 볼 수 있습니다. 다양한 고객들이 원하는 디자인은 무엇인지, 고객과 커뮤니케이션은 어떻게 하는지 등도 경험해 볼 수 있어요. 아무래도 대시보드 디자인 업무를 많이 하다 보니, 다양하고 많은 정보를 어떻게 시각화해야 하는지 연구하고 디자인할 수 있습니다. Q. 브레인즈에 장기근속 중이신데요. 입사 초와 현재를 비교해 보자면? 입사 초기의 브레인즈가 중학생이었다면, 현재는 대학생이 된 것 같습니다. EMS가 성공하면서 상장한 회사가 됐다는 점이 가장 큰 변화라고 생각해요. 또, 상장을 했다는 건 기업이 갖춰야 할 투명성과 성장성이 검증된 것이라고 봅니다. 지금까지 그래 왔듯이 브레인즈는 앞으로도 꾸준히 발전할 것이라고 믿습니다. Q. 그동안 가장 힘들었던 순간과 보람을 느꼈던 순간은요? Zenius EMS 7.0을 개발하고 오픈할 시점이 가장 힘들었습니다. 일이 정말 많았거든요. (웃음) 개발해야 할 인프라가 열 개가 넘었고, 프리랜서 개발자까지 포함해서 30여 명 정도가 매달려서 일했습니다. 개발 업무가 많아 야근하는 것도 힘들었지만, 그룹장이기 때문에 많은 개발자를 관리하는 일이 개발 업무보다 더 힘들었어요. 또, “새 버전이 이전 버전처럼 많은 매출을 울릴 수 있을까”하는 걱정도 한몫 했습니다. 정말 정신없던 때였네요. 반대로 가장 보람찼던 순간은 상장했을 때입니다. 우리 회사가 상장하는 데 제가 5% 정도는 기여하지 않았을까 생각합니다. (웃음) 사실 다니던 회사가 상장한다는 건 일생에 한 번 경험할까 말까 한 일이라고 생각합니다. 단지 운이 좋아서 입사하자마자 상장한 게 아니라, 10년 동안 브레인즈에서 열심히 일해왔고, 그래서 상장하는 데 작은 기여를 했다고 생각하기 때문에 더 기뻤어요. 그 밖에도, 우리 제품이 장애를 미리 발견해 큰 사고가 발생하는 것을 막았다는 이야기를 들을 때면, “내가 한 일이 다른 누군가에 실질적인 도움이 되는구나”라는 성취감을 느껴요. 고객사 기사에서 우리 제품이 기사 사진에 보이거나, 간접적으로 소개되는 것을 볼 때도 보람을 느낍니다. Q. 앞으로 브레인즈컴퍼니에서 꼭 이뤄보고 싶은 목표가 있을까요? 공개할 수 없지만, 현재 브레인즈에서는 새로운 기술로 새로운 제품을 만들고 있는데요. 제가 작게나마 기여를 했으면 좋겠고, 이왕이면 그 제품이 대박을 터트리면 더욱 좋겠습니다. (웃음) 그리고 소박한 목표가 하나 더 있어요. 브레인즈에서 정년까지 일하고 싶습니다. (웃음) 2022.09.16
기술이야기 [Zenius Case#1] 내일까지 서버관리 현황 부탁할게요! 기술이야기 [Zenius Case#1] 내일까지 서버관리 현황 부탁할게요! 퇴근을 준비하는 어느 날, 부장님이 갑자기 요청합니다. “내일까지 서버관리 전반 현황 보고해야 되니 준비 부탁할게! 그럼 고생하고 낼 보자고” 어떤 내용들로 자료를 준비해야 하는 걸까요? 이번에는 Zenius SMS를 활용한 서버관리현황 파악에 대해 살펴보겠습니다. 서버관리 현황 파악의 포인트 1. 얼마나 많은 대상을 관리하고 있으며 종류는 어떤 것이 있는가? 2. 관리가 필요한 주요 성능지표 항목은 어떤 것이 있는가? 3. 주요 성능지표 관련해 현재 상태는 어떠한가? 4. 이슈가 존재하는 서버의 현황과 어떤 이슈를 가지고 있는가? 5. 어떻게 필요한 자료를 쉽고 빨리 확보해 보고할 것인가? 6. 향후 지속적으로 제공 가능한 범위인가?(내일까지 해야 하는데….) 7. 추가적인 요청사항에 대한 대응이 가능한가? 상기 사항들 모두 중요하지만, 그 중에서도 “지속적으로 제공 및 관리가 가능한가?”라는 부분에 집중해야 합니다. 아무리 훌륭한 자료라도 자료구성을 위해 과도한 공수가 발생하는 자료는 사실상 향후 지속적인 관리측면에서 실효성을 상실하게 돼 1회성 보고자료로 끝나게 되는게 현실입니다. 실제 업무에 필요한 자료는 지속적인 관리가 가능해야만 합니다. Zenius로 1분 만에 서버현황 보고자료 정리하기 Step 1. 기본 데이터 취득(10초) Step 2. 현황정보 정리(10초) 저희가 운영하는 대상은Total 12대입니다. OS 별로 Linux 6, Solaris 1, AIX 1, HPUX 1, Window 3 관리 운영 중에 있습니다. Step 3. 주요 성능지표의 상태정리(20초) 먼저 서버(OS) 측면의 주요 성능지표에 대해 알아보도록 하겠습니다. 정보시스템 성능관리 지침에서는 서버 성능관리의 목적을 아래와 같이 정의하고 있습니다. 서버 성능관리의 목적 “서버 성능관리 업무는 최적의 용량을 적시에 확보하기 위한 용량계획의 시점을 제공하고 성능 관련 문제를 사전에 예방함으로써, 사용자의 시스템 활용도 및 만족도를 향상시키기 위하여 수행된다.” 또한 정보시스템 성능관리 지침에서 서버의 주요 성능관리 구성요소는 아래와 같이 정의하고 있습니다. 구성요소 내용 CPU 총 CPU사용률, 시스템 모드 사용률, 사용자 모드 사용률, Run Queue, Pri Queue, 사용자수 등 메모리 총 메모리 사용률, 시스템 및 버퍼 캐쉬, Page In/Out, Swap 공간 사용률 등 디스크 Disk 사용률, Disk I/O Busy, Disk Queue 프로세스 CPU를 집중적으로 사용하는 프로세스, Zombie 프로세스 커널 커널 파라미터 설정을 통한 자원의 적절한 분배 파일시스템 파일시스템 IO Rate, 파일시스템 공간 사용률 네트워크 I/O In 패킷률, Out 패킷률, Collision률, Error률 해당 성능관리 구성요소 중 실제 시스템운영 시 체크가 필요한 몇 개 항목에 대해 간단히 정의하고 넘어가겠습니다. CPU 사용률(%) 서버의 성능을 의미하는 척도로 사용되는 항목으로 CPU의 사용률이 일정 이상을 넘어가면 서비스에 영향을 주기 시작합니다. 순간적으로 급격히 높아질 수 있기 때문에 일반적으로 임계값과 지속시간을 함께 지정해 감시합니다. *여기서 CPU란? Central Processing Unit의 약자로 명령을 해독하고 산술논리연산이나 데이터 처리를 실행하는 장치입니다. Memory 사용률(%) 메모리의 사용량이 너무 빨리 소모되거나 또는 지속적으로 사용량이 떨어지지 않는다면 조치가 필요한 부분입니다. *여기서 Memory란? 기억소자를 지칭하는 것으로 보다 빠른 처리를 위한 프로그램 또는 데이터를 저장하거나 계산된 결과를 임시 또는 반영구적으로 보관하는 기억장치입니다. Disk I/O Busy Rate(%) Disk의 경우 데이터 처리 속도가 메모리나 CPU에 비해 너무 느리기 때문에 Disk I/O Busy Rate의 경우 일정 임계치 이상 지속되는 경우 과다한 입출력이 발생시킴을 의미하며 시스템 성능에 영향을 줄 수 있습니다. *여기서 Disk I/O란? Disk의 입출력 양을 의미합니다. 이제 기본 취득 데이터 기준 주요 성능지표를 정리해 보겠습니다. CPU 사용률(%) 저희가 운영하는 서버 중 CPU 사용률은 다음과 같으며, CPU 사용률이 가장 높은 대상은 Cent7x64 장비입니다. 전일 기준 Peak 치가 59% 정도이며 현재 36%정도의 사용률을 보입니다. Memory 사용률(%) Memory 사용률 현황은 다음과 같으며, Memory 사용률이 가장 높은 대상은 Solaris11 장비 입니다. 전일 기준 Peak 치가 97% 정도이며 현재도 96%정도의 사용률을 보입니다. 해당 장비의 경우 상세분석 진행 예정입니다. Disk I/O Busy Rate(%) Disk I/O Busy Rate 기준으로 모니터링이 필요한 대상은 다음과 같으며 현재 전반 양호한 상태입니다. 가장 높은 대상은 Zenius6.1 장비입니다. 현재 37% 정도를 보이고 있으며 한시적 증가로 요소가 존재하는 상태입니다. 저장장치 사용률(%) 저장장치 사용률의 경우 시스템 전체의 사용률보다는 파티션 별 사용률 관점에서 정리가 필요합니다. 95% 이상 사용중인 파티션 영역이 존재하고, AIX72-ORA, Suse11-x64, Solaris11 장비의 경우 현재 조치 진행 중이며 용량증설 계획도 함께 고려하고 있습니다. Step 4. 이슈사항 정리(20초) 전체관리대상 중 긴급 1건, 위험 4건, 주위 4건의 이슈가 발생해 있는 상태이며 등급 별 상세내역은 다음과 같습니다. 이슈 발생 후 지속시간 2일 이상 지속중인 항목들은 단기 조치 불가 항목으로 조치방안에 대해 논의중인 항목입니다. 이상으로 Zenius를 활용해 1분만에 서버현황 보고자료를 구성해봤습니다. 그럼 이제 다음과 같이 보고를 진행했을 때 추가적으로 유입될 수 있는 요청사항을 Zenius SMS를 활용해 대응해보겠습니다. Zenius SMS를 활용해 추가 요청사항 대응하기 Q. CPU 사용률 높은 장비의 CPU 추이는 어떤가요? 전반 추이와 전일 대비 사용률을 확인해볼 필요가 있습니다. A. 해당장비의 CPU 사용률 추이는 다음과 같으며 전일대비 비교 했을 때 거의 유사한 범위내에 사용률 추이를 보여주고 있습니다. 3단계의 임계라인 기준으로 감시를 수행하고 있습니다. Q. 특정 파티션의 파일시스템 사용률이 높은 장비의 타 파티션의 사용률은 얼마나 되나요? 저장장치 사용률 추이도 함께 검토가 필요해보입니다. A. /nshome40 96% 이외 /home 파티션도 사용률이 90% 이상인 상태입니다. 사용률 추이를 확인했을 때 급격한 증가는 발생하지 않는 상태입니다. 2022.09.02
기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 기술이야기 벽을 넘어서고 싶은 신입 개발자의 브레인즈 생활기 지원 이유와 여정 대학교 졸업 후, 부족한 웹개발 역량을 쌓기 위해 5달간의 풀스택 부트캠프 교육을 수료하고 1달간의 기업 협업 인턴을 마쳤습니다. 이후, 제 역량을 마음껏 펼쳐내며 지속적으로 성장할 수 있는 회사에서 일하고 싶다는 생각이 들었습니다. 그러다 풀스택 기술뿐만 아니라, 빅데이터 및 AI 기술을 활용해 차세대 기술을 개발하는 브레인즈컴퍼니의 채용공고를 발견했습니다. 이 회사에서라면 많은 것을 배워 역량을 키우고 성장하며 일할 수 있겠다는 생각에 지원했고, 면접 끝에 첫 직장에 취업하게 됐습니다. 웹개발도 재밌지만 개발자로서 지속적으로 새로운 기술들을 습득하며 성장하는 것에서 성취감과 보람을 느끼는 것이 컸고, 그럴 수 있는 부서에서 첫 회사 생활을 시작할 수 있다는 생각에 기뻤습니다. 채용 과정 면접에서 기억에 남는 질문은 "우리 부서는 프론트엔드 보다 백엔드를 더 추구하는 편이라 함께 일을 하게 된다면, 프론트엔드와 백엔드 모두를 아울러 사용할 것인데 할 수 있습니까?"였습니다. 풀스택 개발자로서 일을 하게 된다는 질문이었고, 저는 이 부분에 대해 긍정적이었기 때문에 자신 있게 할 수 있다고 대답했습니다. 백엔드 개발자보다 많은 영역에서 발전하며 성장할 수 있다는 생각에 더욱 기대되고 설렜던 기억이 있습니다. 그렇게 저의 첫 직장 생활이 시작됐습니다. 입사 후, 지난 3달간의 일대기 채용이 된 후, 출근까지 2주간의 자유 시간이 주어졌습니다. 졸업 후 부트캠프 교육을 이수하면서 줄곧 달려왔고, 즐겁게 공부했지만 지쳐있는 심신을 달래기 위해 여행도 다녀오고 친구들과 가족들과 시간을 보내면서 출근 준비를 했습니다. 그렇게 2주 후 첫 출근을 하는 날이 됐고, 본격적으로 사원으로 근무하는 날이 다가왔습니다! 브레인즈컴퍼니의 개발 그룹은 1~5그룹으로 나눠져 있으며, 저는 개발4그룹에 소속됐습니다. 개발4그룹은 프론트엔드와 백엔드 개발뿐만 아니라, 빅데이터 및 AI 기술을 동원한 신기술 개발을 담당하고 있어, 배울 점도 많고 나아가야할 길도 멀리 펼쳐져 있다고 느꼈습니다. 1st Month_적응기 입사 첫 달은, 개발4그룹에서 집중적으로 개발 진행 중인 로그매니저와 Zenius AI의 제품 매뉴얼과 웹페이지에서 실제로 사용되고 있는 각각의 기능들을 학습하며 제품을 파악하고 익숙해지는 기간을 가졌습니다. 그렇게 한 달 간은 개발에 투입되기보다는 제품 및 사용된 기능들에 대한 학습과 공부를 하는 기간이었습니다. 단순히 제품의 매뉴얼만을 보며 학습을 했다면 집중도가 떨어졌을 수 있지만, 제품에서 사용하고 있는 다양한 기술들, Elasticsearch, Kibana, Kafka, Cluster 등 스택들에 대해 공부하면서 흥미와 재미를 느끼며 학습을 이어갈 수 있었습니다. 잘 몰랐던 신 기술들을 접하면서, 앞으로도 배우게 될 다양한 기술들에 대해 기대감이 부풀었던 한달이었습니다. 이외에도 학습을 진행하면서 원래 사용하던 스택인 JavaScript와 Linux의 Base부터 차근차근 다시 복습하며 결점을 보완하고, 제 자신을 Refactoring하기도 했던 한 달이었습니다. 2nd Month_개인정보 마스킹 기능 개발 입사 두 달째 부터는, 로그매니저와 Zenius AI의 기능들과 매뉴얼에 대해 전반적인 이해를 갖게 됐고, 각 사이트 기능들의 동작 원리 등을 대략적으로 파악할 수 있었습니다. 두 달이 된 이 시점부터 프론트엔드와 백엔드 모두를 사용하는 프로젝트가 주어졌습니다. 주어진 프로젝트는 ‘개인정보 마스킹 기능 개발’ 이었습니다. 로그매니저 내에서 수집되는 대용량의 로그들 안에 개인 정보가 포함될 경우가 있는데, 개인정보가 그대로 노출되는 것을 방지하기 위해 개인정보에 해당하는 정보는 마스킹처리를 자동적으로 진행하는 기능 개발을 진행하게 됐습니다. 예를 들어, 로그에 ‘961219-1234567’, ‘서울시 성동구 성수이로’, ‘010-1234-5678’ 등과 같은 주민등록번호, 주소, 연락처 뿐만 아니라 다양한 개인정보들을 지정한 특수문자(Default로는 *을 사용) 로 마스킹 처리를 해주는 기능을 개발하는 과정이 중점이 되는 프로젝트였습니다. 풀스택 공부를 하면서, 백엔드는 Node.js와 MySQL, PrismaOrm 등을 사용해 기능 개발을 진행했지만, 이번 프로젝트는 Elasticsearch, Kafka.js, Cluster.js 및 커스텀마이징된 다양한 메소드와 함수들을 통해 진행했기 때문에 배울 점이 매우 많았고, 성장하는 것을 느낄 수 있었습니다. 이외에도 프론트엔드에서 Ace.js를 통한 텍스트 편집기를 개발하고, 개인정보유형에 해당하는 정보가 입력되면 Syntax Highlighting 기능을 통해 해당 부분에 형광펜 효과를 적용시켜주는 기능의 개발을 진행했습니다. 개인정보 유형에 해당하는 정보에 대응되는 정규표현식, 그리고 백엔드에서 마스킹 처리될 특수문자 타입의 데이터 등은 Elasticsearch의 Index를 통해서 데이터의 저장과 반환작업 처리를 진행해줬으며, 이 데이터들을 기반으로 프론트엔드와 백엔드에서 모두 정상적인 마스킹 기능과 Syntax Highlighting 기능을 개발할 수 있었습니다. 새로운 기술을 활용해 프로젝트를 진행하면서 어려운 점도 많았고 시행착오도 겪었지만, 그만큼얻어가고 배워가는 것이 많았던 첫 업무였습니다. Elasticsearch, Kibana, Cluster, Kafka 등 새로운 기술 스택에 대해 배우고 적용할 수 있었다는 점이 매우 흥미로웠고 뿌듯한 경험이었습니다. <사진 설명: 개인정보 유형과 마스킹 여부, 정규표현식 관리와 마스킹 기능 ON/OFF가 가능한 페이지> <사진 설명: 선택한 개인정보 정규표현식에 해당되는 데이터 Syntax Hilighting 기능 구현> 3rd Month_데몬프로세스 그룹화 작업 및 테스트케이스 입사 세 달째 부터는, 어느 정도 회사 생활에 적응이 된 상태가 됐습니다. 아침 일찍 일어나는 것에도 적응이 됐고, 초반에는 어색했던 업무회의와 주간업무보고서 작성도 이제는 자연스럽게 하고 있는 모습을 발견할 수 있었습니다. 첫번째 프로젝트를 마친 후, 두번째로는 로그매니저의 데몬프로세스 기능을 그룹별로 정렬하는 업무를 맡게 됐습니다. 데몬프로세스가 각각의 그룹 속성을 지니고 있지만, 이를 그룹별로 나눠서 보여준다면 좀 더 가독성과 가시성이 높아질 것이기 때문에, Elasticsearch에서 반환 받는 데이터를 그룹의 조건에 따라 분류해주는 작업이 주가 됐습니다. 두번째 개발 후에는 로그매니저의 각 기능들에 대한 테스트 케이스 및 오류 사항 확인의 과정을 거쳤고, 제가 개발한 ‘개인정보 관리’ 기능에 대한 테스트 케이스 작성도 진행했습니다. 개발자가 개발을 잘하는 것도 중요하지만, 이렇게 자신이 개발한 기능에 대해 테스트케이스를 작성하면서 유저가 해당 테스트케이스를 확인하고, 개발한 기능을 자연스레 사용할 수 있게 해야 하는 것은 개발만큼이나 중요하다고 생각하기 때문에 기분 좋게 테스트케이스 작성을 진행할 수 있었습니다. 또, 로그매니저 제품 각 기술들의 테스트케이스들을 확인하며 각각의 기능들을 모두 테스트해볼 수 있는 기회가 됐으며, 개발하고 서비스되고 있는 기술들에 대해 좀더 명확하게 인지하고 확인할 수 있어 제품 이해에 큰 도움이 됐습니다. 이를 기회로 개발만이 중요한 것이 아닌 테스트케이스의 중요성을 절실히 깨닫고, 제가 개발하는 기술들에 대한 테스트케이스 작성이 필수불가결하다는 것을 느끼게 됐습니다. 느낀 점 브레인즈컴퍼니 개발4그룹에 입사 후, 3달간 근무하며 느낀 점은 제가 만족하며 회사를 다니고 있다는 점입니다. 그룹의 모든 구성원분들이 잘 적응할 수 있도록 도와주고 챙겨주셨고, 문제가 될 수도 있는 실수가 발생해도 모든 그룹원들이 다 잘 다독여 주셨습니다. 또, 좋은 피드백을 줘서 지속적으로 배워가고 성장할 수 있는 회사의 성장할 수 있는 부서라고 생각합니다. 그룹의 상래님, 신후님, 천웅님, 태민님 모두 제게 좋은 피드백과 도움을 주시고, 개선돼야할 점과 공부해야 할 부분, 그리고 개발을 하면서 고쳐야 할 습관들을 알려주셔서 점차 앞으로 나아갈 수 있다고 생각합니다. 일을 하면서 빼놓을 수 없는 게 워라밸일 것이라고 생각합니다. 첫 회사에서 일과 삶의 밸런스가 매우 적절하다고 생각하고 만족하며 근무를 하고 있습니다. 퇴근을 한 뒤에도 운동을 할 수 있고, 식단 관리도 병행하며 몸을 기르고 있습니다. 만약, 워라밸이 좋지 않았더라면 이렇게 삶을 유지할 수 없을 거라는 생각이 듭니다. 글을 마치며 면접에서 제가 했던 말이 있습니다. 저는 앞에 벽이 있다면 돌아가 다른 길을 찾으려 하기보다는 그 벽을 넘을 수 있는 방법을 생각합니다. 앞으로 나아갈 수 있고 성장할 수 있는 삶을 추구하고 있습니다. 비록 그 벽을 넘지 못하더라도, 다음에 그 벽보다 낮은 벽은 넘을 수 있을 것입니다. 시도조차 하지 않으면 당연히 발전도 없다고 생각합니다. 매번 도전하고 또 도전하며 발전하는 개발4그룹의 일원이 돼, 신기술 개발에도 큰 보탬이 되는 개발자로 성장하고 싶습니다. 그리고 브레인즈컴퍼니 개발4그룹에서 반드시 실현 가능하다고 생각합니다. 다양한 기술들을 배우고 학습해 제 것으로 만들고, 그룹과 회사에 보탬이 되는 개발자로 성장하겠습니다! [출처] https://twitter.com/gom_translate https://me2.kr/wvu3p http://jjaltoon.gallery/?p=11311 https://me2.kr/eq144 2022.08.25
기술이야기 Java APM 기반 기술에 대한 간략한 설명 기술이야기 Java APM 기반 기술에 대한 간략한 설명 몇 년 전부터 미국 실리콘밸리에서 불어온 스타트업 광풍이 인플레이션과 경기 침체가 동시에 예상되는 최악의 전망 속에서 조금 사그러드는 모습입니다. 그러나 빠른 속도로 퍼지기 시작한 IT 관련 유행들은 아마 꽤 오랜 시간 우리들 근처에 남아 그 영향이 지속되지 않을까 예상해봅니다. 그 중 한 부분을 차지하는 것이 새로운 혹은 인기가 급상승한 Go, Python, R, Julia, Kotlin, Rust, Swift 등의 컴퓨터 언어들입니다. 이렇게 많은 언어들이 새로 등장해 번쩍번쩍하는 장점을 뽐내고 있는 와중에도, 아직 세상의 많은 부분, 특히 ‘엔터프라이즈 IT’라 불리는 영역에서 여전히 가장 많이 사용되는 것은 Java입니다. 절대적이지는 않지만 컴퓨터 언어의 인기 순위 차트인 TIOBE 인덱스에 따르면, 2022년 6월 현재도 Java의 인기는 Python, C의 뒤를 잇는 3위입니다. Java 역시 Java 9부터는 십 수년간 고수하던 백워드 컴패티빌리티 정책을 포기하고 여러가지 반짝거리는 장점을 받아들이면서 버전업을 계속해, 올해 9월에는 Java 19가 나올 예정입니다. 그러나 아직도 우리나라 ‘엔터프라이즈 IT’에서 가장 많이 쓰이는 버전, 그리고 작년까지는 세계에서 가장 많이 쓰이는 버전은 Java 8이었습니다. 이렇게 많은 Java 어플리케이션의 성능을 모니터링하고 관리할 수 있는 솔루션을 통상적으로 APM(Application Performance Management)이라고 합니다. 위에서 서술한 것처럼 다른 컴퓨터 언어들의 인기가 올라가고 사용되는 컴퓨터 언어가 다양해지면서 많은 APM 제품들이 Java외의 다른 컴퓨터 언어로 작성된 어플리케이션도 지원하는 경우가 늘어나고 있으나, 이 글에서는 APM을 Java 어플리케이션의 성능을 모니터링하고 관리할 수 있는 솔루션으로 한정하도록 하겠습니다. 어플리케이션의 성능을 보다 깊이 모니터링하는데 필수적인 것이 Trace[i]입니다. Trace는 어플리케이션이 실행되는 과정에 중요하다고 생각되는 부분에서 중요하다고 생각되는 어플리케이션의 상태를 기록으로 남긴 것입니다. 전통적인 어플리케이션에서는 실행 Thread를 따라가면서 순차적인 Trace가 남게 되고 유행에 맞는 MSA(Micro-Service Architecture) 어플리케이션에서는 서로 연관됐지만 직선적이지는 않은 형태의 Trace가 남게 됩니다. 이러한 Trace를 수집하고 추적하고 분석하는 것이 APM의 주요 기능 중 하나입니다. 그런데, 여기서 문제가 하나 생깁니다. Trace는 누가 남길 것인가 하는 문제입니다. 개발 리소스가 충분하고 여유가 있는 경우, 개발시 성능에 대한 부분에 신경을 써서 개발자들이 Trace를 남기며 이를 분석하고 최적화하는 것이 정례화, 프로세스화 돼있겠지만, 많은 경우 개발 리소스를 보다 중요한 목표 달성을 위해 투입하는 것도 모자랄 지경인 것이 현실입니다. 아무리 분석 툴인 APM이 좋아도, 분석할 거리가 되는 Trace가 없으면 무용지물이 돼 버립니다. 그래서 APM에는 미리 정해진 중요한 시점에 어플리케이션에서 아무 것도 하지 않더라도 자동으로 Trace를 남기도록 하는 기능이 필수적으로 필요합니다. Java 어플리케이션의 경우 이러한 기능은 Java Bytecode Instrumentation이라고 하는 기반 기술을 사용해 구현됩니다. 서론이 매우 길어졌지만, 이 글에서는 Java Bytecode Instrumentation에 대해 조금 상세히 살펴보도록 하겠습니다. Java Bytecode Instrumentation을 명확히 이해하려면, 먼저 Java가 아니라 C, C++, Rust등의 언어들로 작성된 프로그램이 어떤 과정을 거쳐서 실행되는가, 그리고 Java 프로그램은 어떤 과정을 거쳐서 실행되는가를 살펴보는 것이 도움이 됩니다. Java가 세상에 나오기 이전에는 ‘컴퓨터 학원’이나 고등학교 ‘기술’ 과목, 그리고 대학의 ‘컴퓨터 개론’ 등에 반드시 이런 내용이 포함돼 있었지만 요즘은 그렇지도 않은 것 같습니다. 컴퓨터에서 프로그램을 실행시키는 것은 CPU, 즉 Central Processing Unit입니다. 지금 이 글을 작성하고 있는 컴퓨터의 CPU는 Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz입니다. CPU는 메모리의 프로그램이 있는 영역을 읽어 들여, 미리 정해진 값에 따라 정해진 동작을 수행하게 됩니다. 이때 어떤 값이 어떤 동작을 수행하는지 규정해 놓은 것을 Machine Language라고 합니다. Machine Language는 100% 숫자의 나열이므로 이를 좀더 사람이 읽기 쉬운 형태로 1:1 매핑 시킨 것이 Assembly Language입니다. (그렇다고 읽기가 많이 쉬워지지는 않습니다.) 이 글에서는 이 두 단어를 구분없이 혼동해 사용합니다. C, C++, 그리고 나온 지 벌써 10년이나 된 Go, 요즘 인기가 계속 상승하고 있는 Rust 등의 언어로 작성된 프로그램은, 이들 언어로 작성된 소스 코드를 Machine Language로 미리 변환해서[ii] 실행 파일을 만들고 이를 실행하게 됩니다. 이 변환을 수행하는 것을 Compile한다라고 하고 이 변환을 수행하는 프로그램을 Compiler라고 부릅니다. 한편, 소스 코드를 완전히 Machine Language로 변환시킨 실행 파일을 실행하는 것이 아니라 Interpreter라 불리우는 프로그램이 소스 코드를 읽으면서 그 의미에 맞게 동작을 수행시키는 언어들도 있습니다. ‘스크립트 언어’라 불리는 bash, Perl, PHP, Ruby, Python 등이 이에 해당되면, 요즘은 잘 쓰이지 않지만 그 옛날 Bill Gates가 직접 Interpreter를 만들기도 했던 BASIC 등이 이에 해당합니다. 본론으로 돌아가보겠습니다. 그렇다면, Java 프로그램은 어떤 방식으로 실행이 되는가? 기본적으로는 Interpreter 방식이라고 생각해도 이 글의 주제인 Java Bytecode Instrumentation을 이해하는 데는 무리가 없습니다.[iii] 여기에 더해 Java의 실행 방식에는 몇 가지 큰 특징이 있습니다. 첫째로, Java는 소스 파일을 직접 읽어 들이면서 실행하는 것이 아니라 소스 파일을 미리 변환시킨 Java Class File을 읽어 들이면서 실행합니다. 하나의 Java Class File에는 하나의 Java Class 내용이 모두 포함됩니다. 즉, Class의 이름, public/private/internal 여부, 부모 클래스, implement하는 interface 등의 Class에 대한 정보, Class의 각 필드들의 정보, Class의 각 메서드[iv]들의 정보, Class에서 참조하는 심볼과 상수들, 그리고 이 글에서 가장 중요한 Java로 작성된 각 메서드의 내용을 Java Bytecode 혹은 JVM Bytecode라고 하는 중간 형태의 수열로 변환시킨 결과 등이 Java Class File에 들어가게 됩니다. 이 Java Bytecode는 실제 실행 환경인 CPU 및 Machine 아키텍처에 무관합니다. 똑같은 Java 소스 코드를 Windows에서 Compile해 Java Class File로 만들건, Linux에서 Compile해 Java Class File로 만들건 그 내용은 100% 동일하게 되고 이 점은 C, C++, Rust 등 Compiler 방식의 언어와 큰 차이점입니다. Java의 가장 큰 마케팅 캐치프레이즈 “Write Once, Run Anywhere”는 이를 표현한 것입니다. 둘째, Java Bytecode는 일반적인 CPU의 Machine Language와 많은 유사점을 지닙니다.[v] 어찌 보면 Java Bytecode는 실제 존재하지는 않지만 동작하는 가상의 CPU의 Machine Language라고 볼 수 있는 것입니다. 이러한 이유에서 Java Class File을 읽어 들여 실행시키는 프로그램을 JVM이라고 (Java Virtual Machine) 부릅니다. Java 소스 파일을 Java Class File로 변환시키는 프로그램을 Java Compiler라고 부르며, 가장 많이 쓰는 Java Compiler는 JDK(Java Development Kit)에 포함된 javac라고 하는 프로그램입니다.[vi] JVM은 JDK에 포함된 java라고 하는 프로그램을 가장 많이 씁니다. 한편 사용 빈도는 그렇게 높지 않지만, Java Class File을 사람이 알아볼 수 있는 형태로 변환해서 그 내용을 보고 싶은 경우도 있습니다. 이런 일을 하는 프로그램을 Java Bytecode Disassembler[vii]라고 부르며, JDK에는 Java Bytecode Disassembler인 javap가 포함돼 있습니다. 혹은, Eclipse나 Intellij IDEA 같은 IDE에서 Java Class File을 로드하면 사람이 알아볼 수 있는 형태로 변환해 보여줍니다. Java Bytecode의 실제 예를 한번 살펴보도록 하겠습니다. 설명을 간단히 하기 위해, 클래스나 메서드 선언 등은 다 제외하고, 오직 메서드의 내용에만 집중하면,  System.out.println(“Hello, World.”); 라는 Java 프로그램은 다음과 같은 Java Bytecode로 변환됩니다. (전통적으로 16진수로 표시합니다.)  b2 00 0b 12 09 b6 00 0f b1 이를 javap를 사용해, 혹은 JVM Reference[viii]를 보고 좀더 사람이 보기 쉬운 형태로 표현하면 다음과 같습니다.  0: getstatic #11 // Field java/lang/System.out:Ljava/io/PrintStream;  3: ldc #9 // String Hello World  5: invokevirtual #15 // Method java/io/PrintStream.println: (Ljava/lang/String;)V  8: return JVM Reference의 Chapter 7을 참고하면, Java Bytecode를 javap의 결과에 어떻게 대응되는지를 알 수 있습니다. javap의 결과를 조금 더 살펴봅시다. 먼저 콜론 앞의 숫자는 인스트럭션의 offset으로서 Bytecode 시퀀스의 0번째, 3번째, 5번째, 8번째를 의미합니다. 0번째의 getstatic은 그 다음 숫자에 해당하는 필드를 스택의 맨 위에 저장하도록 합니다. 3번째의 ldc는 “Hello, World”라는 상수값을 스택의 맨 위에 저장하도록 합니다. 5번째의 invokevirtual은 println 메서드를 호출하고, 8번째의 return은 메서드에서 리턴해 호출한 곳으로 실행을 넘깁니다. Java 프로그램은 (정확히는 Java 소스 코드로 작성된 프로그램을 Compile한 결과) 통상적으로 많은 수의 Java Class File로 이뤄집니다. JVM은 이러한 Java Class File을 한꺼번에 읽어 들이는 것이 아니라 실행을 하다가 필요한 순간이 되면 그 때 읽어 들입니다. JVM은 이 로딩 과정에 사용자가 개입할 여지를 남겨 뒀는데, 이것이 Java Bytecode Instrumentation입니다. 이에 대한 개요는 https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/package-summary.html에 설명돼 있습니다. 요약해서 설명하면 다음과 같습니다. (1)사용자는 미리 정해진 규약대로 Java Agent라는 프로그램을 작성하고 이를 JVM 실행시에 옵션으로 명기합니다. (2)JVM은 Java Class File을 읽어 들여서 JVM이 처리하기 좋은 형태로 저장하기 전에, 그 파일 내용을 Java Agent의 ClassFileTransformer 클래스의 transform 메서드[ix]에 전달합니다. (3)JVM은 Java Class File의 원래 내용이 아니라 (2)의 메서드가 반환하는 결과를 저장하고 실행합니다. 이 과정을 Java Bytecode Instrumentation이라고 합니다. 사용자는 Java Bytecode Instrumentation을 구현해, 즉 Java Agent를 잘 작성헤 무엇이든 원하는 바를 달성할 수 있는 것입니다![x] 이러한 Java Bytecode Instrumentation은 APM, 그리고 Aspect-Oriented Programming의 기반 기술이 됩니다. 우리나라에서 Java로 프로그래밍을 한다고 하면 누구나 다 알고 있을 것 같은 Spring Core의 핵심 요소 중의 하나가 Aspect-Oriented Programming입니다. 예를 들어 Spring에서 @Transaction 이라고 annotation된 메서드가 있으면, Spring은 그 메서드의 맨 처음에 transaction을 시작하는 코드, 정상적으로 return하기 직전에는 transaction을 commit하는 코드, 그리고 익셉션에 의해 메서드를 빠져 나가기 직전에는 transaction을 rollback하는 코드를 삽입해 주게 되는데 이를 Java Bytecode Instrumentation을 이용해 구현하는 것입니다. 그럼, Java Agent에 거의 무조건적으로 필요한 기능은 무엇일까요? Java Agent는 Java Class File 내용을 그대로 전달받기 때문에 이를 해석할 수 있어야 무언가를 할 수 있습니다. 불행히도, java 스탠다드 라이브러리에는 Java Bytecode를 직접 다루는 기능은 없습니다.[xi] 그래서 de facto standard로 사용되는 것이 asm이라는 라이브러리입니다. 이 라이브러리는 수많은 java 라이브러리와 어플리케이션에 포함돼 있습니다. 그러나 asm이 훌륭한 라이브러리이긴 하지만, 이를 직접 사용하려면 각 상황에 맞게 코드를 삽입하는 프로그램을 작성해서 사용해야 하므로 자유도가 떨어집니다. 그래서 Zenius APM에서는 asm을 사용하되 삽입될 코드를 설정 파일에서 지정할 수 있는 suji(Simple Universal Java Instrumentor)[xii]라고 이름 붙인 라이브러리를 직접 만들어 사용하고 있습니다. suji를 사용하면 yaml 형식의 설정 파일에서, 어떤 클래스의 어떤 메서드의 어느 부분에 삽입할 것인지에 대한 조건과 삽입될 코드를 yaml의 list 형태로 지정하는 것만으로 (이는 Lisp와 비슷한 방식으로, 이렇게 하면 파싱 과정을 생략하면서 쉽게 코드를 넣을 수 있습니다.) Java Bytecode Instrumentation을 손쉽게 처리할 수 있습니다. 예를 들어, Zenius APM에서 JDBC getConnection을 처리하기 위해서 다음과 같은 부분이 설정 파일에 포함돼 있습니다. JDBC.DataSource.getConnection: IsEnabled: true ClassChecker: [ HasInterface, javax/sql/DataSource ] MethodName: getConnection IsStatic: false IsPublic: true IsDeclared: false ReturnType: Ljava/sql/Connection; Locals: [ Ljava/lang/Object;, Ljava/lang/Object; ] AtEntry: - [ INVOKE, dataSourceGetConnection, l1, [] ] AtExit: - [ INVOKE, poolGetConnectionEnd, l2, [ l1, ^r, true ] ] - [ LOAD, l2 ] - [ CAST, Ljava/sql/Connection; ] - [ STORE, ^r ] AtExceptionExit: - [ INVOKE, endByException, null, [ l1, ^e ] ] 간략하게 설명하면, Class가 만약 javax.sql.DataSource를 implement하고 메서드가 스태틱이 아니고 public이면서 java.sql.Connection을 리턴하는 getConnection이라는 이름을 가진 경우에 메서드 시작 시, 리턴 시, 그리고 익셉션에 의해 메서드를 나갈 때 위의 예제에 규정된 코드를 삽입하라는 의미입니다. 이상으로 Java Bytecode Instrumentation에 대한 간략한 설명을 마칩니다. 다음에는 실제로 APM이 중점적으로 추적하고 분석하는 것은 어떤 것들인가에 대해 설명하겠습니다. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [i] Sridharan, Distributed Systems Observability, O’Reilly, 2018의 Chapter 4. The Three Pillars of Observability 참조. 번역본은 없는 듯합니다. [ii] 이 외에 여러가지 과정을 거치지만 이 글의 목적과는 무관하므로 과감하게, 자세한 설명은 생략합니다. [iii] 실제로는 Java 프로그램이 100% 이렇게 interpret되어 실행되는 것은 아닙니다. 특정 메쏘드 혹은 메쏘드의 일부분이 자주 실행돼 interpret하는 것보다 미리 컴퓨터(=CPU)가 바로 실행할 수 있는 형태(=Machine Language)로 변환(=compile)해 놓는 것이 더 낫다고 JVM이 판단하는 경우, 미리 이런 변환 과정을 한번 거쳐 그 결과를 기억해 놓고, 그 기억된 결과를 컴퓨터(=CPU)가 바로 실행합니다. 이렇게 변환하는 과정을 Just-In-Time Compile 혹은 JIT라고 합니다. 또 이 때문에 JVM을 단순한 interpreter로 부를 수는 없는 것입니다. [iv] 국립국어원은 메서드가 맞는 표기라고 합니다. [v] 물론 많은 차이점도 지닙니다. (1) JVM은 register가 존재하지 않고 오로지 stack에만 의존한다. (2) JVM은 Class, Method의 개념을 포함하고 있지만 일반적인 범용 CPU에는 그런 상위 개념은 없습니다. [vi] 보통 IDE를 써서 개발을 하기 때문에, javac를 직접 사용하거나 Java Class File을 직접 다룰 일은 잘 없고, jar 파일이 이 글을 읽는 여러분에게 훨씬 더 익숙할 지도 모릅니다. Jar 파일은 그냥 zip으로 압축된 파일이니 그 압축을 한번 풀어 보길 바란다. 확장자가 class인 수많은 파일을 찾을 수 있을 것입니다. [vii] Assembly는 Assemble의 명사형이며, Assemble의 반대말은 Disassemble입니다. [viii] JVM에 대한 모든 것은 The Java Virtual Machine Specification에 나와 있습니다. 이 중 'Chapter 6. The Java Virtual Machine Instruction Set'를 참고하면 각각의 instruction에 대해 상세히 알 수 있습니다. [ix] https://docs.oracle.com/javase/8/docs/api/java/lang/instrument/ClassFileTransformer.html#transform-java.lang.ClassLoader-java.lang.String-java.lang.Class-java.security.ProtectionDomain-byte:A- [x] 쉽다고는 하지 않았습니다. 또 몇가지 제약 사항은 있습니다. [xi] 참고로 최근에는 asm을 대체할 수 있는 기능을 스탠다드 라이브러리에 넣을 계획이 진행되고 있습니다. https://openjdk.org/jeps/8280389 [xii] 명명이 아이돌 그룹 출신 모 여배우와 관계가 아주 없지는 않음을 조심스럽게 밝혀 둡니다. 2022.08.04

1 2