판교 삼평동

유사 도메인 검색 기능 중, 검색된 도메인의 파비콘이 노출되는 경우가 존재한다. 그러면서 가끔 파비콘이 정상적으로 로드되지 않는 것처럼 로고가 뜨지 않는 현상이 몇몇보였다. 그런데 인프라 수집 단에서 수집하는 서비스의 OS 설정 모드에 따른 파비콘이 다크모드에 대응되는 색상만 수집한다는 것을 알게되었다. 실제로, 다크모드로 전환해서 로고를 확인하게 되면 잘보인다. 사실 로고는 정상적으로 출력되지만 배경색과 파비콘의 로고색이 동일하여 보이지 않는 것처럼 노출되는 현상이었다. 인프라 파트에서는 시스템에 맞는 로고를 모두 가져올 수 있도록 수집 스크립트를 수정하면 되는 일이지만, 작업 시간이 조금 걸리기에 인프라 + 클라이언트의 수정 공수가 모두 들어가는 것보다 클라이언트에서 자체적으로 처리할 수 있는지에 대한 고민을 했다. 백그라운드 색상으로 처리해보기 CSS를 이용해 배경 색상을 줌으로 처리하는 것이 제일 단순한 방법이다. 파비콘이 서버에서 제공되면 백그라운드 이미지로 처리하면 무조건 보이게 된다. 그런데 이 방법에서 내가 생각하는 우려점은 아래와 같다. 고정된 백그라운드 색상을 적용하게 되면, 어찌되었든 백그라운드 색상과 동일한 색상의 파비콘이 나오게 되면 똑같이 정사각형의 단색으로 나오게 될 것이다. 투명 배경의 파비콘 아이콘으로 설정한 도메인들의 경우에는 강제로 백그라운드 색상이 적용되어 보이게 될 것이다. 이 방법은.. 가장 간단한 방법이긴하지만.. 브랜드 아이콘 디자인을 해치는 것 같아 절레절레.. 했다. 캔버스로 파비콘을 읽어 픽셀로 검토해보기 백그라운드 색상으로 처리하는 방법은 빠르게 처리할 수 있다는 장점이 있지만, 그다지 좋은 선택지는 아닌 것 같았다. 그래서 이미지는 Base64 형태로 제공이 되며, 파비콘을 캔버스 엘리먼트의 픽셀 단위로 검토하여 로고가 흰색인지 여부에 대한 판단을 하기로 했다. 만약 로고가 흰색이라면 클래스 네임을 추가해 로고의 색상을 반전시켜주면 되는 일이다. 코드는 컴포저블로 재사용 가능하도록 만들었고, 자세한 코드는 아래와 같다.

왜 이 기능이 필요할까? 이전 콘텐츠에서 위협 탐지룰을 AI · 수동으로 생성 및 추가하는 과정에서 해당 위협 탐지룰이 다른 콘텐츠에서도 연관된 내용으로 존재할 수 있기 때문에, 연관 콘텐츠를 이어줌으로써 그물 형태의 위협 행위들을 조금 더 다양하게 탐지할 수 있다. 기능에서 요구하는 필수 구현 사항 자사 보고서 콘텐츠 조회 기능 현재 백오피스에서는 모든 콘텐츠 제목을 검색하는 기능을 제공하고 있기 때문에, 자사 보고서의 코드들을 통해 클라이언트에서 `filter` 메서드를 통해 처리를 하도록 한다. 해당 조회 기능의 경우, 백엔드에서 페이징을 지원하지 않는다. 그래서 키워드에 따라 몇백개의 게시글이 조회되는 경우가 있는데 매번 조회를 하기보다는 디바운스를 통해 검색 과정에서 성능 최적화를 진행한다. 연관 콘텐츠 연결 기능 위협 탐지룰이 배포된 상태에서만 연관 콘텐츠를 연결할 수 있다. 연결 시간 동안 사용자에게 기다리는 유저 인터페이스를 제공하기 보다는, 낙관적 업데이트를 통해 빠르게 업데이트 사항을 보여준다. (단, 실패할 경우에는 이전 낙관적 업데이트 전 백업 리스트로 되돌린다) 연관 콘텐츠 연결 취소 기능 위협 탐지를이 배포되지 않은 상태에서만 연관 콘텐츠의 연결을 취소할 수 있다. 연관 콘텐츠 연결 기능과 유사하게 기능 개발을 진행한다. 도전적이었던 점 해당 기능에는 딱히 어려운 점은 없었다. 조회 및 관련 데이터를 컨트롤 하는 기능의 경우에는 수도 없이 만들어보았기 때문에 이번 기능은 초기 설계도 간단하고 명료하게 할 수 있어서 빠르게 개발에 착수할 수 있었다. 어려웠던 점 비교적 간단한 기능이라 어려웠던 점은 없었으나, ”백오피스의 이 기능을 어떻게 녹일 수 있는가?“, “어떻게 하면 사용자가 편하게 사용할 수 있을까?”에 대한 고민을 했었던 것 같다. 그래서 레이아웃을 기획하고 개발한 결과물을 스테이징 서버에 반영하여 팀원들에게 보여주고, 피드백을 받는 과정이 필수적이었던 것 같다. 결과물 연관 콘텐츠 조회 기능 연관 콘텐츠 조회 기능 > 키워드 검색 시 (Kimsuky)

왜 이 기능이 필요할까? 최신 트렌드 위협 탐지룰인 Sigma 룰을 통해 위해 안랩도 위협 탐지 솔루션에 대한 트렌드에 발 맞추기 위함이며, 동시에 다른 자사 솔루션에서 자체 룰로 변환할 때 사용하고자 콘텐츠에서 위협 탐지룰 등을 추출해낸다. 시그마(Sigma) 룰이란? 다양한 보안 솔루션에서 사용할 수 있도록 위협 탐지 로직을 표준화한 오픈소스 포맷이다. 최근 아래와 같은 이유들로 인해 시그마 룰이 각광을 받기 시작하고 있다. 탐지 로직 표준화 SIEM(통합 보안 관제 시스템)마다 사용하는 쿼리 언어(Splunk, ELK, QRadar 등)가 모두 다릅니다. 시그마 룰은 YAML 형식의 공통 포맷을 사용하여 한 번만 작성하면 어떤 시스템에서든 변환해 활용할 수 있습니다. 대응 시간 단축 새로운 사이버 공격이나 랜섬웨어 유행 시, 위협 인텔리전스(IoC)를 빠르게 시그마 룰로 작성 및 배포하여 신속하게 공격을 차단할 수 있습니다. 규칙(Rule)의 공유 및 재사용 전 세계 보안 커뮤니티(SigmaHQ 등)에서 검증된 최신 위협 탐지 규칙을 쉽게 가져와 내 환경에 맞게 적용할 수 있습니다. 유연한 확장성 온프레미스(사내 구축형) 환경부터 Microsoft Sentinel, Google Chronicle 같은 클라우드 환경까지 파편화된 인프라 전체를 일관된 기준으로 모니터링할 수 있습니다. 기능에서 요구하는 필수 구현 사항 AI 룰 생성 기능 현재는 Sigma만 지원을 하며, 인프라 파트에서 Yara와 Snort 기능을 지원해주면 그때 추가 연동을 진행한다. 수동 룰 작성 이때, 수동 룰 작성의 경우 Yara · Sigma · Snort 모두 작성 지원을 한다. 문법 검증 룰의 로우 데이터와 타입을 서버에 넘겨주면, 서버에서는 룰 문법 검증 결과를 받아 검증 결과를 알려준다.

기존에 Vue2에서 아래 코드가 존재한다고 가정해보자, 여기서 watchIocList는 업데이트되는 iocList의 value 값을 통해 추가 작업을 하는 무언가의 함수이다. 여기서 그대로 Vue3로 코드 베이스를 옮겼다고 추가로 가정을 해보자, 그러면 아래 코드와 같이 watch 코드를 옮길 수 있다. 그런데 여기서 문제가 하나가 발생한다, 아래 코드를 실행했을 때 Vue2와 Vue3에서 같은 동작을 하지만 실행 결과는 다르게 나오게 된다. Vue2에서는 watchIocList를 통해 정상 동작을 하던 코드가, Vue3에서는 동작하지 않는 이슈가 발생한다, 왜 그럴까? Vue2의 Watch 특성 Vue2는 Vue3와 다르게 Proxy를 사용하지 않으며, Object.defineProperty를 통해 관련 상태 값들을 관리한다. Vue2는 인덱스 직접 접근 arr[0] = val나, length 변경은 감지하지 못하지만 Vue3는 Proxy가 배열 및 객체의 접근 자체를 추적하기 때문에 이런 것들이 가능하다. 이 방식의 단점은 배열이나 객체에 새롭게 추가되는 요소를 감지하지 못한다는 치명적인 단점을 가지고 있는데, Vue2에서는 이를 해결하기 위해 내부적으로 배열 인터셉트를 제공한다. 배열의 mutation 메서드들을 직접 래핑하여 사용하는 것이다. 총 7가지의 메서드를 래핑하여 제공을 하고있다. push pop shift unshift splice sort reverse watch는 기본적으로 참조가 변경되어야 트리거되면서 동작을 하게 되는데, 위와 같이 직접 래핑되어 사용을 하면서 Vue2에서는 this.iocList.push({ value: abcd }) 통해서도 참조 변경 없이 동작이 되는 것이다. Vue3에서는 기본적으로 이러한 배열 메서드가 없이 오로지 Proxy로 관리되기 때문에 Vue3에서는 Vue2의 push를 통한 트리거가 동작되지 않는다. 그렇기 때문에 Vue3에서는 deep 메서드를 통해 배열 객체 내부까지 감시를 해줘야한다. 내가 처음부터 코드를 작성했다면 코드가 많아질 수록 watch 의존성 추적이 힘들어서 최대한 자제를 했겠지만, 마이그레이션을 하면서 사이드 이펙트를 줄이기 위해 그대로 사용하면서..

백오피스 서비스를 개발하다보면, 장시간 어드민 페이지에서 잔류할 경우가 많은데 이때 여러 다중 탭들을 많이 생성해서 띄어놓게 된다. 그 중에 가장 불편했던 점이 여러 탭들이 있으면 탭 별로 구분이 잘 안가서 탭을 하나씩 클릭하게 되는 상황이 발생한다. 같은 탭이 5개 이상 ^,^ 데스크탑에 많이 앉아있는 사람이라면 탭을 여러 개 띄어놓는 구조는 당연하다. 근데 기존에 구현되어있는 백오피스는 특히 새 창으로 띄워 상태를 관리하는 기능들이 참 많았고, 메뉴에 들어가 게시글 작성이나, 조회를 할 때마다 새 탭이 열리는 구조였다. 그러다보니, 엄청나게 많은 탭들이 개발을 마친 후나 테스트를 마친 후에는 정~말 많아진다 ^,^ 탭의 개수가 작으면 클릭할 탭이 몇개없어 문제가 되진 않으나, 탭이 정말 많아지면 이게 어떤 탭인지 공황장애 상태가 온다. 이 문제를 해결하는 방법은 현재 페이지의 상태를 외부로 노출을 시키는 것인데, 클릭을 하지 않고 확인할 수 있는 방법은 탭의 문서(HTML Document) 별 타이틀을 변경하는 것이다. 문서 (HTML Document) 타이틀 변경하기 페이지 단에서 접속할 때마다 단순하게 해당 페이지가 어떤 페이지를 의미하는지 변경만 해주면되는 간단한 작업이다. 나 같은 경우, 여러 페이지에서 다중적으로 사용하기 때문에 useSetDocumentTitle 컴포저블을 만들어 사용해주었다. 관련 옵션 및 매개변수들에 대한 내용들은 JSDOC 에 담아놓았다. 사실 페이지 별로 일일히 해당 컴포저블의 코드를 달기가 무척이나 힘들다. 구조를 어떻게 설계하느냐에 따라 다르겠지만, Vue 에서는 createRouter 에서 각 routes 에 name 값을 지정할 수 있기 때문에 사이드 바에 해당 컴포저블을 삽입해두고 (공통적으로 모두 들어가기 떄문에) 라우트가 변경될 때마다 현재 route 의 name 값을 가져와 문서의 타이틀을 변경해주는 형식으로 해결했다.

여느 회사나 다 마찬가지겠지만, 우리 회사도 PR 템플릿이 있음. PR 양식은 있지만, 파일에 템플릿 마크다운이 들어가있지 않아서 처음에는 직접 입력을 해야했음,, 우리 회사는 BitBucket 을 쓰고 있는데 이 녀석이 깃허브랑 유저 인터페이스가 달라서, 템플릿을 어떻게 추가해야하는지 몰라서 혼자 이것저것 추가하는 나를 보며 팀에서 권한이 없다는거를 알고 추가해주셨음 (권한이 없다는거를 늦게 알았 ^.^,,) 템플릿이 있다는 것은 체계적이어서 정말 좋았지만, 여기서 기능 하나가 뭉텅이로 들어갈 경우에 구현 내용 란에 모든 파일 이름을 적고, 구현 내용에 대한 세부 내용을 적어야하는게 너무 공수가 많이 들었음 예를 들어 개발을 3시간 했다면, 템플릿에 적는 시간은 10분~15분.. 이게 적은 시간 같아도 손가락도 아프고 정말 비효율적인 시간이었음, 그래서 인공지능이 나왔으니 이거를 활용해서 내 소중한 시간을 다른데서 더 효율적으로 써보자고하는 마음에 사내에서 제공하는 깃허브 코파일럿을 활용하기로 함. 먼저 가능한지부터 확인하기 위해 코파일럿에게 아래와 같이 프롬프트를 만들어서 제공을 해주었음 이렇게 프롬프트를 제공하니까 어느정도 결과가 도출되긴하는데 수정 내역을 그냥 대충 적는다거나 내용적인 부분에서 부실한 영역들이 있었는데 이 부분들은 프롬프트를 조금 더 자세히 비추상적으로 적으면서 해결을 할 수 있었음. 위의 .prompt.md 파일을 정의해두면, 이 파일을 기반으로 컨텍스트로 참조하게하여 프롬프트의 성향을 해당 마크다운 파일에 맞출 수 있음. 그래서 매번 정의할 필요없이 이 마크다운 파일 하나만 있으면 동일한 규격의 비슷한 결과들을 도출해낼 수 있다. 아래와 같이 실제 결과로 도출할 수 있었음. 이렇게 반자동화를 해놓으니까 직접 PR 템플릿을 적어나갈 필요 없이 결과물만 복사-붙여넣기 하면 되니까 효율이 넘사로 빨라졌음. 아직도 해결하지 못하는 문제는 개발을 마쳤으면 프롬프팅으로 한번 템플릿을 직접 요청을 해줘야한다는거임. 완전 자동화하려고 했는데 깃허브처럼 BitBucket 에 바로바로 깃액션을 붙일 수 있는 구조가 아니고, n8n 으로 자동화를 하려고 해도 신규 서버를 설치해야하는데 기존 빌드 서버들이 엄청 복잡해서 시니어들도 쉽게 건드릴 수 없는 구조.. (보안 회사라 뭐 하나 할때마다 품위올리고 안전 검사 받아야하고 사내 인프라 서비스가 엄청 거대하다보니, 오래 재직한 사람들도 모르는 경우가 많음)

현재 백오피스는 그나마 많이 레거시 코드를 청산하고 있지만, 아직도 처리해야할 것들이 많음 그 중에 하나가 유저 인터페이스가 정말 몇년 전 구닥다리 인터페이스라는 것인데, 이것들을 한번에 변화하기 보다는 점진적으로 변화해야하겠다고 마음 먹음 (한번에 하기에는 정말 양이 너무 많고, 그러다 비즈니스적인 이슈들을 제때 처리하지 못함) 우당탕탕 겁나 불편한 메뉴 구조 그 중에 메뉴가 점점 많아짐에 따라 기능 찾기가 어렵다는 생각이 들었음 (특히 슈퍼 관리자는 모든 메뉴를 볼 수 있음) 아래 사진을 보면 대메뉴들 아래 하위 메뉴들이 정말 많은데, 펼치면 펼칠수록 스크롤로 한땀한땀 찾아야함 그래서 아래와 같이 메뉴 구조의 사전에 정의해둔 메뉴 별 고유 key 값을 통해 자바스크립트로 찾는 로직을 구현해서 추가를 해두었음 (이 기능은 메뉴가 많은 슈퍼 관리자한테만 보이도록 하였고, 일반 사용자들은 안보임) 메뉴를 찾을 때는 사용자가 입력한 키워드에 형광펜 표시로 까막눈도 잘 보일 수 있도록 해놓았음 뭔가 3프로 부족한 느낌 5~6년전부터 존재해왔던 사이드바여서, 맨 하단의 사이드바를 접으면 아이콘만 나오는데 이 아이콘에는 툴팁도 없고 어떤 기능으로 쓰여지고 있는지 의문점이 들음. 그래서 과감히 하단의 사이드바 접기(아이콘만 볼 수 있는) 버튼을 없애고, 상단의 사이드바 전체 접기 버튼만 나올 수 있도록 레이아웃을 변경하고자했음. 또 하위 메뉴들에 아이콘이 노출되고 있지 않아 가독성이 떨어지는 부분도 해결을 하고 싶었음, 이 부분은 MDI에서 제공해주는 아이콘들이 있어서 이 아이콘들을 활용하여 작업을 하면 될 듯 함 추가로 나는 Arc 브라우저를 사용하는데, Arc 브라우저 처럼 Ctrl + S 를 누르면 오로지 커맨드로만 사이드바가 접히도록 구현하고 싶었음. 그래서 정리를 하자면 아래와 같은 기능들이 더 개선되어 추가될 예정이었고, 곧바로 추가하고자했음 메뉴의 불필요한 버튼 제거 및 기능 개선 메뉴 별 메뉴 컨셉에 맞는 아이콘 제공 Arc 브라우저 처럼 사이드바 커맨드 제공