Woojin Kim

어차피 지금도 와이파이로 홈랩을 운영하는데 이거 모바일 인터넷 붙이면 진짜 전기만 있으면 아무데나 둘 수 있는 거 아닌가

... 기계가 알아서 DR 훈련하는거 보니 왜이리귀엽지

콜르드에게 개인 퍼포스 전권을 맡긴 후 체인지리스트 올라가는 속도가 회사 프로젝트보다 빨라졌다.

今日

@eeruwang 불행한 나라는 모두 같은 원인(UK)을 가지고있는 거 아니었나요

대강 도쿠위키 마이그레이션한 이야기라도 써야겠다.

아니 핸드오프파일 쓰라니까 왜 급정색하는건데

앗. 주말에 글쓸거 하나도 준비 안했다.

이번 퍼포스 서버 버전은 시큐리티레벨 최소값이 3에서 4로 강재변경됩니다. 패스워드 복잡도 요구수준도 올라가 관리자 패스워드가 약하면 업그레이드 후 로그인이 불가능해질 위험 있으니 주의.

... 기계에게 휴리스틱 흉내내라고하는거 왜이렇게재밌지

너무나 일어나기싫어 10분씩 세번 스뉴즈했다.

내 토큰사용패턴을 보니 현재 사용량의 125%정도만 있어도 리밋에 잘 안걸릴거같음.

ai를 적극적으로 쓰라고 해놓고 '그거 ai 딸깍한거아님?' 이라고 함부로 물으면 안되는것이다.

지금은 앞서 말한 플러그인이 없어서 렌더랑 안되는 부분을 감지해서 알아서 플러그인 설치해서 정상 출력 확인한 다음 이 결과로 컨플루언스 페이지를 다시 수정하고있다. ...... 이런게 된다니 하면서도 어처구니가 없음.

심지어 마이그레이션 후 비교도 텍스트로 비교하고 dom 구조로 비교하고 양쪽의 브라우저 출력 결과를 시각적으로 비교해 유사성을 확인하는 등 진짜 이전엔 상상도 안했을 방법들을 아무렇지도 않게 쓰고 있다. ...... 아.. 넷플릭스가 컨플루언스 서버를 클라우드로 옮길때 이걸 1년씩 했겠구나 싶은데 이제 그걸 나혼자 그냥 하루에 시간 조금씩 내서 할 수 있다.

도쿠위키 to 컨플루언스 컨버터를 만들고있는데 이전엔 생각하지 못했던 방식과 과도한 요구사항을 구현해내는게 재밌다. 가령 컨버터를 실행하면 알아서 도커에 도쿠위키 설치하고 데이터만 주입하고 직접 데이터 스캔해서 설치되었던 플러그인 찾아 설치하래 최대한 같은 환경을 만든 다음 브라우저로 렌더링한 결과 기준으로 컨플루언스에 마이그레이션하고 또 도쿠위키의 구성요소를 컨플루언스에 어떤 형태로 옮길지 하나하나 지정할 수 있게 하고 있다. 이번에 시도했던 마이그레이션에 비해 기술수준도 매우 높아졌고 내 요구수준도 굉장히 높아졌다.

https://github.com/neoocean/dokuwiki-to-confluence-cloud

하 ...... 맥미니랑 외장하드 몇개 넣어둘 전기랑 인터넷 들어오는 곳 없나 ...... 하다가 ...... 문득 그런걸 코로케이션이라고 한다는걸 깨달음.

비가 온다. 와이파이에 물려있는 홈랩 속도가 느리다.

7분남았다 ...

...... 사대보험 됐으니 토큰을주세요. 이게뭡니까.

아 않되 ...

아 쫄린다 .......

토큰이얼마안남았다. 업무속도를 줄여!!

아니 컨플루언스는 아직도 데이터베이스에 외부입력 api가 없어???

웹서비스는 전부 클라우드플레어 터널, 그 외에는 전부 테일스케일 뒤에 있으니 아무 네트워크에나 물리고 켜면 그냥 끝이네

...... 보안 규칙을 반대로 걸어서 모든사람들을 밴해버렸다.

... 클로드 느려 ........

https://noc.social/@cloudflare/116595715712015674

핵심 내용

• Mythos Preview의 가장 큰 진전은 두 가지입니다: 여러 작은 버그를 이어 실제 공격 경로를 구성하는 능력, 그리고 PoC 코드를 직접 작성·실행·수정하며 취약점의 악용 가능성을 스스로 검증하는 능력입니다.
• 이전의 범용 프런티어 모델들도 버그 자체는 어느 정도 찾았지만, 그 버그들을 하나의 실제 익스플로잇으로 엮는 단계에서 자주 멈췄습니다.
• 그래서 예전에는 우선순위가 낮아 보이던 작은 결함들이, Mythos 같은 모델을 통해 실제로는 더 심각한 취약점 체인으로 드러날 수 있다고 봅니다. 한계와 문제점
• 모델이 때때로 위험한 요청을 스스로 거부하는 경향은 있었지만, 그 기준이 일관적이지 않았습니다. 같은 작업도 표현 방식이나 실행 맥락이 조금만 달라지면 거부하거나 허용하는 결과가 달라졌습니다.
• 따라서 이런 “자연 발생적 가드레일”만으로는 안전 경계로 삼기 어렵고, 일반 공개용 모델에는 별도 보호장치가 반드시 더해져야 한다고 주장합니다.
• 또 취약점 탐지의 큰 문제는 노이즈입니다. 특히 C/C++처럼 메모리 안전성이 낮은 언어에서는 허위 양성이 많고, 모델은 확신이 낮은 추측성 결과도 많이 내놓아 인간 검토 비용을 키웁니다.

왜 일반 코딩 에이전트로는 부족한가

• 저장소 전체를 대상으로 “취약점 찾아라”라고 지시하는 방식은 커버리지가 낮고 비효율적이라고 설명합니다.
• 보안 연구는 넓고 막연한 탐색이 아니라, 특정 기능·신뢰 경계·취약점 유형을 좁게 잡고 병렬로 반복 조사해야 하는 작업인데, 일반 코딩 에이전트는 한 번에 하나의 가설을 오래 붙드는 방식에 최적화돼 있습니다.
• 결국 중요한 것은 단일 대화형 에이전트가 아니라, 좁은 범위의 작업을 대량 병렬 처리하고 결과를 검증·중복 제거·추적하는 하네스라는 결론입니다.

Cloudflare의 하네스 구조 Cloudflare는 대략 이런 파이프라인을 사용했다고 설명합니다.

• Recon: 저장소 구조, 빌드 방법, 진입점, 신뢰 경계를 파악.
• Hunt: 여러 에이전트를 병렬로 돌려 좁은 범위의 취약점 가설을 탐색.
• Validate: 다른 프롬프트·다른 모델 계열의 검증 에이전트가 반박 시도.
• Gapfill / Dedupe / Trace: 놓친 영역 재탐색, 중복 제거, 실제 외부 입력이 취약점에 도달하는지 추적.
• Report: 최종 결과를 정형화된 스키마로 보고. 핵심은 “많은 좁은 작업 + 독립 검증 + 도달 가능성 추적”이 한 명의 똑똑한 에이전트보다 실전에서 더 낫다는 점입니다.

보안팀에 주는 메시지

• 글은 “더 빨리 스캔하고 더 빨리 패치하자”만으로는 부족하다고 강조합니다.
• 회귀 테스트, 배포 구조, 서비스 분리, 경계 방어처럼 취약점이 있어도 실제 악용이 어렵도록 만드는 아키텍처적 방어가 더 중요하다고 봅니다.
• 즉 앞으로는 패치 속도 경쟁만이 아니라, 취약점이 공개돼도 공격 성공까지 이어지지 않게 만드는 시스템 설계가 핵심 과제가 된다는 이야기입니다.

원격 지원 안하는 클로드에 원격으로 메시지를 보내게 만들었는데 ...... 그걸 받는 클로드가 코워크라 할수있는게 없다.

마음에 드는게 없으면 만들어 쓰면 된다. (아직 만드는중)

https://github.com/neoocean/dokuwiki-to-confluence-cloud