이 대목이 특히 재밌었음 SCCS/RCS 표기법이 2005년 Windows 커널 코드에 나온 건, 요즘 사무실에서 다이얼식 전화기를 보는 수준이라는 비유였는데 꽤 설득력 있었음
2006년에 일했던 천체물리 연구실도 여전히 svn을 쓰고 있었고, 코드베이스에는 70~80년대 시스템 흔적이 남은 Fortran이 많았음
그래도 최신 최적화 컴파일러 덕분에 잘 돌아갔고, 90년대에 Vax에서 Linux로 옮긴 과정도 놀랄 만큼 매끄러웠음
예전에 들은 do over or make due 발표가 떠오르는데, 대체로 멀쩡히 돌아가는 큰 코드베이스를 통째로 다시 쓰는 건 현대 도구로 겨우 이어 붙여 쓸 수 있다면 그만한 가치가 없다는 뜻이었음
2012년쯤까지도 RCS 기반 SCM을 쓰던 회사에서 일했는데, 공유 파일 서버 위에 RCS를 억지로 감싼 해킹성 시스템이었음
이름은 MKS였고, 특정 리비전 트리를 "project file"로 관리하는 방식이었는데 Java EE로 다시 만든 버전조차 아닌 90년대 구버전 같았음
파일 상단엔 $Revision: 1.3 $ 같은 태그와 changelog가 들어갔지만, 새 파일 상당수는 태그 자체를 안 넣어서 치환도 안 됐고 일관성은 엉망이었음
대상 디바이스 계열은 90년대 중반부터 시작됐지만, 그 시점 코드 자체는 실질적으로 5년 넘은 게 거의 없었음
엔지니어가 수십 명뿐이어도 커밋 충돌이 잦았고 전체 트리가 자주 망가졌음
재미로 전체 히스토리를 읽어 git으로 가져오는 스크립트를 썼는데, 몇 년만 거슬러 올라가도 기록이 완전히 난장판이었음
왜 그때까지 그걸 썼는지는 모르겠지만, 하드웨어 회사들은 생각보다 최근까지도 소스 관리를 "원격 공유 폴더" 정도로 여기는 경우가 있었고, 그래서 소프트웨어 쪽 버전 관리가 우선순위가 아니었던 듯함
2026년에 R를 쓰고 있다면, 어딘가에서는 70~80년대 Fortran에서 컴파일된 코드를 거의 반드시 호출하고 있을 가능성이 큼
수치 계산 세계에서 그 계보가 아직도 기반 역할을 함
예전엔 Stuxnet의 정부 배후설을 좀 의심했는데, 이런 메모를 보면 왜 그런 추정이 나왔는지 이해가 됐음
2000년대까지도 RCS를 쓰는 곳은 실제로 있었고, 도구 자체로는 SVN이나 CVS보다 나은 점도 있었음
그렇다면 그런 3글자 약어 기관들이 악성코드 유형마다 해당 분야 출신 인력을 끌어올 수 있었다는 뜻일까 궁금함
예를 들어 fast16은 원래 과학 계산 소프트웨어를 만들던 사람이, Stunex는 Siemens에서 일하던 사람이 썼을 수도 있겠다는 상상도 듦
리팩터링이 만병통치약은 아님
처음에 코드가 리팩터링이 필요해진 원인이 그대로 남아 있으면, 결국 같은 상태로 다시 돌아오게 됨
그런 원인은 개발자의 습관, 신념, 직업적 트라우마 같은 심리적 층위까지 깊게 박혀 있는 경우도 많음
여기에 Conway의 법칙까지 겹치면 팀은 결국 더 큰 조직 구조를 닮은 소프트웨어를 만들 수밖에 없고, 조직이 안 바뀌면 리팩터링 결과도 대체로 반복됨
예외는 다른 팀의 코드베이스나 전임자의 코드를 맡아 구조를 다시 잡을 때쯤임
하지만 같은 사람들이 자기 코드 리팩터링을 선언하면, 대개는 자기들에게 더 편한 쥐덫을 하나 더 만드는 데 그치기 쉬움
자기 사고방식의 산물을 반복 개선하는 건 괜찮지만, 회전목마에서 내리려면 나쁜 아키텍처의 원인을 적어 보고 스스로를 냉정하게 점검해야 함
많은 개발자가 믿고 싶어 하는 것처럼 "조심하고 성실하면 다소 나쁜 설계도 잘 구현할 수 있다"는 말은 대개 맞지 않음
결국 뿌리는 설계고, 거기서 자라난 나무를 받아들이든 베어내든 해야지 가지치기만으로는 한계가 큼
이 글은 꽤 오싹하게 다가옴
이 악성코드가 20년 동안 탐지망 아래에 있었다는 사실만으로도 충분히 불길함
IEEE-754는 +-*/와 sqrt에 대해서만 올바른 반올림을 강제함
sin/cos/exp/log/pow 같은 초월함수는 마지막 몇 ULP 차이를 허용하고, glibc, musl, MSVC, Intel SVML도 실제로 그렇게 동작함
PID는 기본 연산만 써서 libm 차이 영향을 덜 받지만, 모터 벡터 제어나 센서 선형화는 매 사이클 이런 함수들을 건드리기 때문에 작은 불일치가 누적됨
그래서 소스 코드 diff가 전혀 없어도, 링크된 libm만 바뀌어서 현장 동작이 드리프트할 수 있음
이런 차이는 Payne-Hanek argument reduction이나 최악의 table-maker's dilemma 경계에서 실제로 드러남
아마 그래서 안전 필수 시스템 가이드는 그냥 "IEEE-754 준수"라고 쓰지 않고 특정 libm 빌드를 고정하는 듯함
정말 대단한 발견임
이 규칙들이 정확히 어떤 대상을 겨냥했고 결과를 어떻게 바꿨는지 몹시 궁금함
혹시 원자로처럼 아주 특정한 시뮬레이션 조건에서만 차이를 만들도록 설계된 건지도 모르겠음
LS-DYNA 같은 소프트웨어가 어떻게 변조될 수 있는지 좀 파봤음
예를 들어 공개 매뉴얼 [1]에 있는 EOS_JWL 방정식은 LS-DYNA가 구현하는 식인데, 다른 식들과 함께 쓰면 미사일 탄두의 기폭장치가 주폭약을 터뜨려 20m 거리에서 특정 압력파를 만들기까지 걸리는 시간 같은 걸 계산하는 데 쓸 수 있어 보임
그 결과를 거꾸로 이용하면 필요한 신관 타이밍도 추정할 수 있음
LS-DYNA에 들어가는 식과 파라미터는 [2] 같은 과학 연구에서 오는데, 이건 1980년대 미국 정부의 고폭약 실험 연구임
여기엔 폭약이 이를 감싸는 다양한 재료와 마찰하는 특성을 측정한 실험도 들어 있음
폭약 모델링용 식이 이미 준비돼 있으니, 그런 식만 살짝 건드려 마찰계수에 ±20% 노이즈를 얹어도 과학자나 엔지니어는 소프트웨어 조작보다 강재 제조 품질 문제를 먼저 의심할 가능성이 큼
현대판 비유로는 어떤 적성국이 중국 크래킹 그룹이 중국 게시판에 올린 Ansys Autodyn 2026 R1 불법 복제본을 러시아 ISP 뒤의 소수 시더에게서 받아 쓰는 상황을 떠올릴 수 있음
그러다 나중에 실험값과 계산값이 자꾸 어긋나면 그제야 복제본이 고의로 변조됐을 수 있다고 의심할 수 있음
다만 지금은 그 적성국이 랜덤한 대학이나 항공우주·방산 컨설팅 회사의 해킹된 네트워크에서 정식 사본을 빼오는 쪽이 더 쉬울 수도 있음
2026년의 적성국이 소프트웨어를 아예 처음부터 만들지 못할 거라고 보는 것도 순진할 수 있고, 수작업 계산이나 실험에 의존해서도 원하는 결과에 도달할 수 있음
결국 제조 품질을 검증하려면 실험 장비와 역량은 원래부터 필요함 시뮬레이션 소프트웨어는 주로 모형 제작과 물리 실험 횟수를 줄여 비용과 시간을 아껴 줄 뿐임
예를 들어 [3]처럼 포탄이 장갑판에 맞는 상황을 1000번 돌리는 건 싸지만, 현실에서 그걸 반복하는 건 훨씬 비싸고 오래 걸림
[1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
[2] https://www.osti.gov/servlets/purl/6530310
[3] https://www.youtube.com/watch?v=_dv2PecKUBM
내가 공개하는 것들에 RCS 리비전 데이터가 붙어 있는 걸 보면, 사람들이 잠깐이라도 멈칫했으면 좋겠음
최근에 읽은 책은 Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, Andy Greenberg 저작임
꽤 좋았고, 새 정보들이 계속 나오고 있으니 후속 시리즈가 필요할 수도 있겠다고 봄
Guix와 재현 가능한 컴퓨팅이 PowerPC나 레거시 머신까지 이식 가능해지는 걸 보면, 정부나 1984 같은 기관들, 그리고 중동의 몇몇 조직은 진짜 싫어할 것 같음
환경이 더 이기종적일수록 유리함
핵심 수는 웜임
다른 컴퓨터에서 검사해도 잡히지 않는데, 애초에 깨끗한 두 번째 컴퓨터 자체가 없기 때문임
재밌는 발견이긴 한데, 소스 관리 관련 코멘트는 약간 어긋난 느낌도 듦
그 시절에도 SCCS 비슷한 것들은 아직 남아 있었을 테고, CVS가 비슷한 스타일이었는지 잠깐 헷갈리기도 함
그 코멘트는 아마 Windows 소프트웨어에서 그게 드물다는 뜻이었을 거라고 봄
개발자들이 원래는 UNIX 쪽 작업도 하던 사람들임을 시사하는데, SCCS/RCS는 그쪽에선 흔했기 때문임
Hacker News 의견들
이 대목이 특히 재밌었음
SCCS/RCS 표기법이 2005년 Windows 커널 코드에 나온 건, 요즘 사무실에서 다이얼식 전화기를 보는 수준이라는 비유였는데 꽤 설득력 있었음
2006년에 일했던 천체물리 연구실도 여전히 svn을 쓰고 있었고, 코드베이스에는 70~80년대 시스템 흔적이 남은 Fortran이 많았음
그래도 최신 최적화 컴파일러 덕분에 잘 돌아갔고, 90년대에 Vax에서 Linux로 옮긴 과정도 놀랄 만큼 매끄러웠음
예전에 들은 do over or make due 발표가 떠오르는데, 대체로 멀쩡히 돌아가는 큰 코드베이스를 통째로 다시 쓰는 건 현대 도구로 겨우 이어 붙여 쓸 수 있다면 그만한 가치가 없다는 뜻이었음
이름은 MKS였고, 특정 리비전 트리를 "project file"로 관리하는 방식이었는데 Java EE로 다시 만든 버전조차 아닌 90년대 구버전 같았음
파일 상단엔
$Revision: 1.3 $같은 태그와 changelog가 들어갔지만, 새 파일 상당수는 태그 자체를 안 넣어서 치환도 안 됐고 일관성은 엉망이었음대상 디바이스 계열은 90년대 중반부터 시작됐지만, 그 시점 코드 자체는 실질적으로 5년 넘은 게 거의 없었음
엔지니어가 수십 명뿐이어도 커밋 충돌이 잦았고 전체 트리가 자주 망가졌음
재미로 전체 히스토리를 읽어 git으로 가져오는 스크립트를 썼는데, 몇 년만 거슬러 올라가도 기록이 완전히 난장판이었음
왜 그때까지 그걸 썼는지는 모르겠지만, 하드웨어 회사들은 생각보다 최근까지도 소스 관리를 "원격 공유 폴더" 정도로 여기는 경우가 있었고, 그래서 소프트웨어 쪽 버전 관리가 우선순위가 아니었던 듯함
수치 계산 세계에서 그 계보가 아직도 기반 역할을 함
2000년대까지도 RCS를 쓰는 곳은 실제로 있었고, 도구 자체로는 SVN이나 CVS보다 나은 점도 있었음
예를 들어 fast16은 원래 과학 계산 소프트웨어를 만들던 사람이, Stunex는 Siemens에서 일하던 사람이 썼을 수도 있겠다는 상상도 듦
처음에 코드가 리팩터링이 필요해진 원인이 그대로 남아 있으면, 결국 같은 상태로 다시 돌아오게 됨
그런 원인은 개발자의 습관, 신념, 직업적 트라우마 같은 심리적 층위까지 깊게 박혀 있는 경우도 많음
여기에 Conway의 법칙까지 겹치면 팀은 결국 더 큰 조직 구조를 닮은 소프트웨어를 만들 수밖에 없고, 조직이 안 바뀌면 리팩터링 결과도 대체로 반복됨
예외는 다른 팀의 코드베이스나 전임자의 코드를 맡아 구조를 다시 잡을 때쯤임
하지만 같은 사람들이 자기 코드 리팩터링을 선언하면, 대개는 자기들에게 더 편한 쥐덫을 하나 더 만드는 데 그치기 쉬움
자기 사고방식의 산물을 반복 개선하는 건 괜찮지만, 회전목마에서 내리려면 나쁜 아키텍처의 원인을 적어 보고 스스로를 냉정하게 점검해야 함
많은 개발자가 믿고 싶어 하는 것처럼 "조심하고 성실하면 다소 나쁜 설계도 잘 구현할 수 있다"는 말은 대개 맞지 않음
결국 뿌리는 설계고, 거기서 자라난 나무를 받아들이든 베어내든 해야지 가지치기만으로는 한계가 큼
이 글은 꽤 오싹하게 다가옴
이 악성코드가 20년 동안 탐지망 아래에 있었다는 사실만으로도 충분히 불길함
궁금한 사람을 위한 다운로드 링크임
https://bazaar.abuse.ch/sample/9a10e1faa86a5d39417cae44da5ad...
아마 먼저 Windows XP VM부터 만들 것 같음
저건 로더로만 보임
IEEE-754는 +-*/와 sqrt에 대해서만 올바른 반올림을 강제함
sin/cos/exp/log/pow 같은 초월함수는 마지막 몇 ULP 차이를 허용하고, glibc, musl, MSVC, Intel SVML도 실제로 그렇게 동작함
PID는 기본 연산만 써서 libm 차이 영향을 덜 받지만, 모터 벡터 제어나 센서 선형화는 매 사이클 이런 함수들을 건드리기 때문에 작은 불일치가 누적됨
그래서 소스 코드 diff가 전혀 없어도, 링크된 libm만 바뀌어서 현장 동작이 드리프트할 수 있음
이런 차이는 Payne-Hanek argument reduction이나 최악의 table-maker's dilemma 경계에서 실제로 드러남
아마 그래서 안전 필수 시스템 가이드는 그냥 "IEEE-754 준수"라고 쓰지 않고 특정 libm 빌드를 고정하는 듯함
정말 대단한 발견임
이 규칙들이 정확히 어떤 대상을 겨냥했고 결과를 어떻게 바꿨는지 몹시 궁금함
혹시 원자로처럼 아주 특정한 시뮬레이션 조건에서만 차이를 만들도록 설계된 건지도 모르겠음
예를 들어 공개 매뉴얼 [1]에 있는 EOS_JWL 방정식은 LS-DYNA가 구현하는 식인데, 다른 식들과 함께 쓰면 미사일 탄두의 기폭장치가 주폭약을 터뜨려 20m 거리에서 특정 압력파를 만들기까지 걸리는 시간 같은 걸 계산하는 데 쓸 수 있어 보임
그 결과를 거꾸로 이용하면 필요한 신관 타이밍도 추정할 수 있음
LS-DYNA에 들어가는 식과 파라미터는 [2] 같은 과학 연구에서 오는데, 이건 1980년대 미국 정부의 고폭약 실험 연구임
여기엔 폭약이 이를 감싸는 다양한 재료와 마찰하는 특성을 측정한 실험도 들어 있음
폭약 모델링용 식이 이미 준비돼 있으니, 그런 식만 살짝 건드려 마찰계수에 ±20% 노이즈를 얹어도 과학자나 엔지니어는 소프트웨어 조작보다 강재 제조 품질 문제를 먼저 의심할 가능성이 큼
현대판 비유로는 어떤 적성국이 중국 크래킹 그룹이 중국 게시판에 올린 Ansys Autodyn 2026 R1 불법 복제본을 러시아 ISP 뒤의 소수 시더에게서 받아 쓰는 상황을 떠올릴 수 있음
그러다 나중에 실험값과 계산값이 자꾸 어긋나면 그제야 복제본이 고의로 변조됐을 수 있다고 의심할 수 있음
다만 지금은 그 적성국이 랜덤한 대학이나 항공우주·방산 컨설팅 회사의 해킹된 네트워크에서 정식 사본을 빼오는 쪽이 더 쉬울 수도 있음
2026년의 적성국이 소프트웨어를 아예 처음부터 만들지 못할 거라고 보는 것도 순진할 수 있고, 수작업 계산이나 실험에 의존해서도 원하는 결과에 도달할 수 있음
결국 제조 품질을 검증하려면 실험 장비와 역량은 원래부터 필요함
시뮬레이션 소프트웨어는 주로 모형 제작과 물리 실험 횟수를 줄여 비용과 시간을 아껴 줄 뿐임
예를 들어 [3]처럼 포탄이 장갑판에 맞는 상황을 1000번 돌리는 건 싸지만, 현실에서 그걸 반복하는 건 훨씬 비싸고 오래 걸림
[1] https://ftp.lstc.com/anonymous/outgoing/jday/manuals/LS-DYNA...
[2] https://www.osti.gov/servlets/purl/6530310
[3] https://www.youtube.com/watch?v=_dv2PecKUBM
내가 공개하는 것들에 RCS 리비전 데이터가 붙어 있는 걸 보면, 사람들이 잠깐이라도 멈칫했으면 좋겠음
최근에 읽은 책은 Sandworm: A New Era of Cyberwar and the Hunt for the Kremlin's Most Dangerous Hackers, Andy Greenberg 저작임
꽤 좋았고, 새 정보들이 계속 나오고 있으니 후속 시리즈가 필요할 수도 있겠다고 봄
Guix와 재현 가능한 컴퓨팅이 PowerPC나 레거시 머신까지 이식 가능해지는 걸 보면, 정부나 1984 같은 기관들, 그리고 중동의 몇몇 조직은 진짜 싫어할 것 같음
환경이 더 이기종적일수록 유리함
핵심 수는 웜임
다른 컴퓨터에서 검사해도 잡히지 않는데, 애초에 깨끗한 두 번째 컴퓨터 자체가 없기 때문임
재밌는 발견이긴 한데, 소스 관리 관련 코멘트는 약간 어긋난 느낌도 듦
그 시절에도 SCCS 비슷한 것들은 아직 남아 있었을 테고, CVS가 비슷한 스타일이었는지 잠깐 헷갈리기도 함
개발자들이 원래는 UNIX 쪽 작업도 하던 사람들임을 시사하는데, SCCS/RCS는 그쪽에선 흔했기 때문임