[GN#110] Agile 20주년 : 실패한 반란

2021-08-09 ~ 2021-08-15 사이의 주요 뉴스들
Agile Manifesto(애자일 선언문)이 발표된 지 20년이 되었습니다. 저는 90년대에 소프트웨어 공학을 배우고 나서 취업을 한지라, 애자일이 나오던 2000년대 초에는 회사 일에만 집중하느라 놓쳤던 것 같아요. 그당시엔 새로운 기술 뉴스들을 접할 쉬운 채널이 없었기도 해서, Agile 그리고 XP에 대한 것을 알게 된 2005년 쯤에 헐레벌떡 관련 문서와 책들을 찾아봤었던 것으로 기억합니다. 그때 사실 늦었다는 것에 적잖이 충격을 받아서, 저만의 기술 뉴스를 습득하는 경로를 구축해두는 게 중요하단 걸 깨닫기도 했구요. 어쨌거나 20년이 지난 지금에 와선 SW개발회사들은 마치 애자일이 기본인 것처럼 얘기가 됩니다만, 실제로 회사에서 일하는 걸 유심히 보면 전혀 애자일하지 못한 회사들도 많습니다. 왜 이런 상황이 되었는지를 나름의 시각으로 정리한 "Agile 20주년 : 실패한 반란" 이란 제목의 글이 있어서 간단히 번역해봤습니다. "'Agile'을 포기하더라도 'Agility(민첩성)'를 유지할 수 있기를 바랍니다."

화려한 GUI 도구들이 많이 나오고 있지만, 아직도 터미널은 개발자들에게 최고의 환경입니다. 그리고 요즘은 Go 와 Rust 같은 언어를 통해서 빠르고 유용한 CLI 바이너리를 편하게 만들 수 있게 되면서 다양한 개선 도구들이 나오고 있는데요. "Modern Unix" 는 우리가 주로 사용하던 Unix 명령의 최신 대체제 도구들을 정리해서 소개합니다. 참고하셔서 손에 익은 도구들을 더 좋은 것들로 바꿔보세요.

Mosh는 SSH의 진화된 버전입니다. SSH는 보통 서버에 접속하고 IP가 변경되면 연결이 끊어지거나 하는데요. SSH와 같은 방식으로 접속하지만, 내부에서 별도로 서버를 실행해서 UDP로 전송하는 방식을 통해서 연결도 유지되고, 네트워크 랙 없이 커맨드 전송이 가능한 장점을 가지고 있습니다. 심지어 크롬에서도 사용 가능합니다. 4년째 새로운 업데이트가 없어서 프로젝트가 중단된 것 처럼 보이기도 하지만, 개발자인 Keith Winstein 은 이렇게 얘기합니다.
"릴리즈가 필요하다고 느끼지 않습니다. Mosh는 보안 허점을 가진 적이 없고, 그걸 자랑스럽게 생각합니다. 언젠가는 24비트 컬러나, MacOS 시계 우회 등의 이슈로 릴리즈 하긴 해야겠지만, 급하지는 않다고 생각합니다. 오만해 보일 수도 있지만, 어떤 소프트웨어가 목표의 95%를 달성했다면 더 기능을 추가함으로써 생기는 보안 위험에 대해서 가중치를 두고 생각해야 합니다."

목표를 95% 달성한 소프트웨어라.. 멋진 것 같아요.

온라인으로 강좌를 제공하는 경우들이 많은데요. 이런 강좌를 직접 만들어서 호스팅하고 싶을 때 사용하는 LiaScript 라는 오픈소스를 찾아서 공유해봅니다. 개발은 2017년 9월부터 되었으니 꽤 오래 개발된 프로젝트 이고요. 별도의 도구 없이 MarkDown을 이용해서 강의를 작성하면 그 데이터만으로 브라우저가 렌더링 해서 온라인 강좌를 볼 수 있게 해줍니다. 강의자료가 MD파일이다 보니 원격으로 간단히 불러서 강의를 볼 수 있는 장점이 있습니다. 텍스트뿐만 아니라, 비디오/오디오, Text2Speech, 퀴즈/설문조사 등의 기능도 제공하므로 다양한 용도로 사용 가능할 것 같습니다.

HTML5 초기에 얘기되었던 Web SQL Database 스펙은, SQL을 직접 사용하는 것이 웹에 어울리지 않는다고 Web StorageIndexedDB API를 지원하는 것으로 변경되어서 스펙 개발이 중단 되었습니다. Indexed DB 역시 내부에서는 Sqlite를 이용하긴 하지만, 너무 느리고 사용이 불편하다는 얘기들이 있었는데요. 개발자 James Long이 "A future for SQL on the web" 이라는 글을 통해서, SQLite 의 브라우저용 버전인 SQL.js를 후킹하여 DB데이터를 IndexedDB에 저장하는 absurd-sql 이라는 오픈소스를 공개했습니다. 이렇게 함으로써 브라우저에서 10배이상 빠르게 DB를 접근할 수 있다고 합니다. 복잡한 데이터를 다뤄야 하는 PWA 개발 시에 참고하시면 좋을 것 같아요.

[ 금주의 Ask ]


"이달의 구인공고 - 멤버를 찾고 계신가요 ?" 글은 매달 첫번째 월요일에 고정적으로 등록되며, 구인하고 계시는 모든 회사들이 자유롭게 댓글로 구인공고를 올릴 수 있습니다. 현재 15개의 구인 공고가 등록되어 있으니 참고하시기 바랍니다.

✓ 사내 커뮤니케이션 도구들에 GeekNews Bot을 추가해서 편하게 새 글을 받아보시고, 멤버들에게도 공유해주세요. : Slack Bot, 잔디 Bot, MS Teams Bot, Discord Bot
✓ 주위분들께 긱뉴스 위클리 - https://news.hada.io/weekly 를 추천해 주세요.

매주 월요일 아침, 지난 일주일간의 GeekNews 중 엄선한 뉴스들을 이메일로 보내드립니다.


Agile 20주년 : 실패한 반란

- Agile Manifesto(애자일 선언문)가 발표된 지 20년이 지난 지금, 명백한 두가지 사실은
ㅤ1. Agile이란 이름 붙이는데는 승리했음. 누구도 non-Agile 이라고 불리기를 원하지 않음
ㅤ2. Agile의 실행에 있어서는, 파운더들의 혁명적인 아이디어에 비해 많이 부족함
- "모두가 Agile을 한다고 얘기하지만, Agile한 사람은 거의 없음" 왜 이런 상황이 되었을까 ?

[ Whence The Manifesto : 선언문은 어떻게 시작되었나 ]
- 2001년 2월, 17명의 소프트웨어 전문가 그룹이 유타의 스키리조트에서 미팅
- 며칠간의 토론을 통해 "Agile Software Development Manifesto"를 공동으로 작성

- 중요한 점은 그들이 "Practitioner(실무자)" 였다는것. 그들은 PM이나 CTO, VP Engs 등이 아니었음. 그들은 개발자, 프로그래머, 과학자, 엔지니어 였음. 그들은 그때도 계속 코드를 쓰고, 이해관계자들과 협력하여 문제를 해결하고 있었음. 이게 정말 중요함.
- 다른 포인트는 Agile Manifesto가 아무것도 없는 상태에서 만들어지지 않았다는 것. 이들 중 여럿은 다들 자신이 만들었거나 전파중인 방법론을 가지고 있었음.
ㅤ→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming

- 그룹의 모든 사람들이 소프트웨어 개발 경력이 많았고, 그들은 그 당시 시장의 주류였던 문서 주도의 무거운 소프트웨어 개발 프로세스를 대체할 것을 찾고 있었음.
- 선언문의 핵심은 4가지의 가치에 대한 설명

"우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
- 공정과 도구(processes and tools)보다 개인과 상호작용(Individuals and interactions)을
- 포괄적인 문서(comprehensive documentation)보다 작동하는 소프트웨어(Working software)를
- 계약 협상(contract negotiation)보다 고객과의 협력(Customer collaboration)을
- 계획을 따르기(following a plan)보다 변화에 대응하기(Responding to change)를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다."

[ A New Hope : 새로운 희망 ]
- 2021년의 관점에서 보면 현대적인 소프트웨어 개발 관행을 당연한 것처럼 받아들이기 쉽지만, 2001년에는 이런 아이디어들이 매우 급진적이었음.
- 요구사항을 모두 수집하고, 모든 기능을 평가하기전에 소프트웨어를 개발하기 시작한다구요? 미쳤군요!
- 잊혀져 가는 중요한 점은 Agile이 초기에는 공개적이고 전투적으로 반 관리적(anti-management) 였다는 것

- 예를 들어 Scrum의 공동 창시자인 Ken Schwaber는 모든 프로젝트 매니저를 없애자고 주장하면서 , 프로젝트에서 PM을 빼는 것만이 아니라, 업계 자체에서 해당 직업을 없애야 한다고 했음.

"우린 프로젝트 관리자의 역할이, 복잡하고 창의적인 작업에서는 비생산적이라는 것을 발견했습니다.
프로젝트 계획으로 표출되는 프로젝트 매니저의 생각은,
문제를 가장 잘 해결하기위해 모든 사람의 지능을 모으는 것이 아닌,
계획에 적혀 있는 것으로 모든이의 창의성과 지능을 제한합니다."

- 스크럼 마스터는 거의 권한이 없었고, 이슈에 투표권도 없었습니다. 그들은 서번트 리더*였으며, 팀을 보호하고 장애물을 치워주지만, 팀을 관리하지 않았음.
ㅤ→ 서번트 리더 : 부하를 섬기는 자세로 그들의 성장 및 발전을 돕고, 리더와 부하간의 신뢰를 형성시켜 조직 목표 달성에 부하 스스로 기여하도록 만드는 리더
- XP에도 원래 Tracker 와 Coach가 있었는데, 비슷하게 동작했음.

- Crystal과 Hexagonal 아키텍처의 창시자인 Alistair Cockburn은 최근 트윗 쓰레드에서 이런 얘기를 한바 있음
"스크럼은 적대적인 지역에서 엄청난 거래를 성사 시켰음:
ㅤ- 경영진들은 1년에 12번, 각 스프린트후에 원하는 방식으로 방향을 바꿀 수 있었음
ㅤ- 팀은 무거운 생각과 작업을 하기 위해 인터럽트나 방향 변경없이 완전히 조용한 한달이라는 기간을 얻었음
ㅤ- 팀은 경영진의 간섭없이, Bid(우선순위를 결정하기 위한)에서 한달동안 할 수 있는 것과 할 수 없는 것을 발표할수 있었음
ㅤ- 어떤 경영진도 이보다 더 나은 거래를 해본 적이 없었음
ㅤ- 어떤 개발팀도 이보다 더 나은 거래를 해본 적이 없었음
"
(역자 주: 이 트윗쓰레드는 처음에 "스크럼 팀은 스프린트에 할당된 모든 아이템을 100% 끝내야 한다는 아이디어는 어디서 나온건가요? 이건 말도 안되는데요." 라는 질문에서 시작된 답변입니다. 원문 쓰레드 전체를 보시는 걸 권해드립니다.)

- 15년 이상 Agile 팀에서 일한 공인 스크럼 마스터이고, 이 분야의 인기 있는 책을 많이 있었지만, 스크럼에 대한 아이디어를 이렇게 명확하고 간결하게 설명한 것을 본적이 없음.
- 스크럼은 적대적인 환경에서 작동하도록 만들어졌음. 생각하고 탐색할 시간이 필요한 개발자들과 강압적인 관리자들간의 계약임

[ The Empire Strikes Back : 제국의 역습 ]
- 어떤 면에서 Agile은 풀뿌리 노동 운동이었음. 실무자에서 시작해서 경영진까지 올라갔음. 이게 어떻게 성공했을까?
- 부분적으로는 개발자의 수가 늘고, 비즈니스에 주는 가치가 증가했기 때문
- 더 큰 이유는 전통적인 워터폴 개발방식이 제대로 작동하지 않았기 때문
- 소프트웨어가 더 복잡해지고, 비즈니스의 속도가 빨라지고, 사용자의 수준이 높아지면서 모든 것을 미리 계획하는 것이 불가능 해짐.
- 반복적인 개발은 수용하는 것은 논리적이었지만, 모든걸 계획했던 관리자들에게는 약간 두려운 일이 었음.

- 2000년대 중반에는 경영진들이 받아들이지는 않았었음.
- 그러다 "엔지니어들이 계속 이야기 하는 이 미친 아이디어를 한번 시도해보자. 우리 지금 데드라인 어차피 못 맞추는데 얼마나 나빠지겠어?" 라는 얘기가 나옴.
- 하지만 놀랍게도 워킹하기 시작. 팀은 처음에는 살짝 움츠러 들었지만(느렸지만) 점차 어떤 패턴이 각 팀에 동작하는지 알게 되면서 속도가 붙기 시작했음
- 몇번의 스프린트 후에는 작동하는 소프트웨어, 협업, 검사 및 적응하는데 시간을 들이는 것과, 그외 모든 것들의 우선순위를 정하는 것의 힘을 알게 됨

- 약 5년간은 Agile은 들어봤던 방법론에서 모든 사람이 익숙하지는 않은 것으로 바뀌어 갔음.
- 2005년에는 Agile과 TDD가 진정한 차별화 요소였음
- 2010년에는 최신 소프트웨어팀들은 다 어떤 형태로든 Agile을 하고 있었음.
- 적어도 컨설팅업계에서는 버블이었음. 대기업은 항상 느리게 움직였지만.

"우리가 해냈어요! 우리가 이겼어요! 모두 축하합시다"
이게 이야기의 끝이고, 브라우저의 탭을 닫아도 됩니다.

"Winning was easy, young man. Governing’s harder."
"이기는 건 쉬웠어, 젊은이. 통치가 더 어려워"
ㅤ→ 해밀턴(뮤지컬) 에서 묘사된 조지 워싱턴

- 불행하게도 많은 혁명과 마찬가지로, 애자일의 역사는 창시자들이 구상한 방식으로 전개되지 않았음.
ㅤ→ "개인과 상호작용"을 우선시 하는 것은 Sell하기 어려운 개념이라는 것이 밝혀졌음. 프로세스와 도구를 Sell하는 것이 훨씬 쉬움
ㅤㅤ(역자 주 : 여기서 Sell 은 판매라기 보다는 남들에게 이해시킨다는 의미여서 그대로 뒀습니다.)
ㅤ→ "작동하는 소프트웨어"는 비현실적인 계획과 많은 문서보다 더 만들기가 어렵다는 것이 밝혀졌음.
ㅤ→ "고객과의 협업"은 신뢰와 취약성(vulnerability)이 필요하지만, 비즈니스에서 항상 존재하지는 않음.
ㅤ→ "변경에 대응하기"는 종종 장기계획을 세우고 통제해야하는 경영진들에게 더 무게가 실렸습니다.

"Agile이 제대로 수행되지 않으면 종종 혼돈처럼 느껴진다는 것이 밝혀졌음"

- 하지만 이 4가지 가치가 잘못된 것은 아님
- 이 모든 것이 제대로 되려면 약간의 노력이 필요하고, 소프트웨어가 본질적으로 어지럽고 혼란스럽다는 것을 받아들이는 용기가 필요하다는 것을 의미함
- 계속 배우고 적응하고 개선하고 출시하다보면 결국에는 폭포수보다 훨씬 더 나은 곳, 훨씬 더 정직하고 현실적이고 생산적인 곳으로 갈 수 있다는 것을 이해하고 믿어야함.

"애자일 운동은 반방법론(Anti-methodology)이 아닙니다.
실제로 우리중 많은 사람들은 "방법론" 이라는 단어에 대한 신뢰가 회복되기를 원합니다. 균형이 회복되기를 원합니다.
모델링을 수용하지만, 먼지쌓인 회사 창고에 다이어그램을 넣어두기 위함이 아닙니다.
문서화를 수용하지만, 유지보수 되지 않고 거의 사용 되지 않는 수백페이지의 책을 수용하는 것은 아닙니다.
계획은 만들지만, 격동적인 환경에서 계획의 한계를 인식합니다.
XP, Scrum 또는 기타 애자일 방법론의 지지자들을 'Hacker'로 낙인 찍는 사람들은 "방법론"과 "해커" 용어의 원래 정의에 대해 무지한 것입니다."
- Jim Highsmith, History: The Agile Manifesto

- 이게 중요한 포인트들임. 우리는 여전히 계획과 문서를 만들고, Agile에 엄격해야함. 이건 균형에 대한 것임.
- 그러나 당신의 조직이 Agile 전환에 어려움을 겪고 있고, 혼돈에 빠져있다면, 누군가가 인증,프로세스,도구 같은 구명정을 제공한다면 그리로 점프하게 됨.
- 경영진은 "자기 조직화 팀" 보다 프로세스와 도구를 훨씬 잘 이해함.

[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : 로그 원(의 귀환) ]
- 여기서 내 3막 구조가 약간 무너짐. 왜냐면 Agile 이름을 달지 않고 돌아오는 용감한 반군은 보이지 않기 때문
(역자 주: 스타워즈 시리즈 이름에 빗대어, Agile이 아닌 다른 무언가는 나오지 않았다는 것)

- 도구 벤더, 프로세스 컨설턴트 및 전문가가 절대 제공할 수 없는 약속을 하는 경우가 많음.
- 우리가 SAFe(Scale Agile Framework for Enterprise) 나 Scaled Scrum 및 다른 엔터프라이즈용 Agile 버전을 만들게된 이유
- 이런 프레임워크들은 악의적인 의도로 만들어진게 아니고, 아마도 적절한 맥락에서는 어느정도 가치가 있을 것.
- 하지만, 나는 그들을 Agile이라고 부르지 않을 것
- 개인과 상호작용에 중점을 둔 방법론을 확장하려고 하면 필연적으로 문제가 발생하고 방법론의 원래 가치가 손상됨.

- 애자일 선언문 서명자이자, XP 공동 창시자인 Ron Jeffries가 2018년에 쓴 유명한 글

"개발자는 Agile을 포기해야 합니다.
'Agile' 아이디어가 제대로 적용되지 않으면, 개발자에게 더 많은 간섭을 하고, 작업시간을 더 적게 주고, 높은 압력을 주고, '더 빠르게 진행' 하는 것을 요구하게 됩니다. 이건 개발자들에게 좋지 않으며, 궁극적으로는 회사에도 좋지 않습니다. 'Agile'을 제대로 수행하지 않으면 실제 달성할 수 있는 것보다 훨씬 더 많은 결함과 더 느린 진행이 자주 발생하기 때문입니다. 종종 우수한 개발자가 그런 회사를 떠나게 되면서, 결과적으로는 "Agile"을 도입하기 전보다 효율성이 떨어지는 기업이 됩니다."

- 다른 서명자이자, 실용주의 프로그래밍의 공동 창시자인 Dave Thomas가 2014년에 쓴 유명한 글

"Agile 은 죽었다. (Agility여 영원하라)
'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다. Manifest가 대중화 되면서 Agile 이라는 단어는 지지할 것이 있거나, 청구할 시간 이나 판매할 제품이 있는 모든 것들을 끌어들이는 자석이 되어버려서, 마케팅 용어가 되었습니다.

그래서 'Agile' 이라는 말은 이제 은퇴시켜야할 때라고 생각합니다."

[ Retro : 과거로의 회귀 ]
- 정말 슬픈 것은 젊은 개발자가 Agile을 폄하하고, 경영진들이 비현실적인 약속들을 도출하고, 개발자들이 엄청 많은 시간을 일하도록 부추기도록 하는 수단으로 생각하는 것을 보는 것.
- 그들이 아는 유일한 Agile은 그들에게 부과된 통제 메커니즘이지, 기쁘게 받아들였던 자기 권한 부여의 도구가 아님.
- 하지만, 역사와 원래의 비전에 대해 토론을 시작하는 것이 우리가 앞으로 어떻게 나아가야 할지를 기억하는데 도움이 되길 바람.

- 이럼에도 좋은 소식은 Agile Manifesto의 원칙이 20년 전과 마찬가지로 오늘날에도 현명하고 적절하다는것. 그리고 Jeffreies 나 Thomas 같은 배교자(apostates, 종교를 버린사람) 로 추정되는 사람들도 여전히 그렇게 생각함.

- 위에 언급된 글에서 Jeffries는 이렇게 얘기함
"그러나, Manifesto for Agile Software Development 의 가치와 원칙은 여전히 내가 아는 최고의 소프트웨어 구축 방법을 제공하며, 나의 길고 다양한 경험을 바탕으로 더 큰 조직에서 어떤 방법론을 사용하든 그 가치와 원칙을 따를 것입니다."

- 이 의견에 나는 동의함
- 지금 애자일에 대해 이야기 하는 것은 힙하거나 멋진 일이 아님. 애자일은 지루함.
"다들 애자일 하시죠?"
- 지금은 지난 20년을 되돌아보고 스스로에게 몇 가지 질문을 던질 수 있는 완벽한 시간
ㅤ→ 무엇이 제대로 되었나요?
ㅤ→ 무엇이 잘못되었나요?
ㅤ→ 다음번에는 어떻게 다르게 하고 싶은가요?
- 다음 몇달간 원래의 12 애자일 원칙을 다시 돌아보고, 원래 의미를 맥락화하고, 현재 소프트웨어 개발환경에서 그 가치를 고려하려고 계획중

"내 희망은 창립 원칙을 연구함으로써, 과거로부터 배우고, Dave Thomas 의 말처럼 'Agile'을 포기하더라도 'Agility(민첩성)'을 유지할 수 있기를 바랍니다."

- 왜 (일부) 개발자들은 Agile 을 싫어하는가 https://news.hada.io/topic?id=661
- 왜 어떤 구글 개발자들은 애자일 개발이 무의미하다고 하는가에 대한 (전) 구글 엔지니어 디렉터의 답변 https://news.hada.io/topic?id=265
- Spotify의 Squad 팀 모델은 실패였다 https://news.hada.io/topic?id=2191
ㅤ→ 2012년 유명했던 스포티파이의 "Scaling Agile" 백서는 그들의 희망이었을 뿐 완전히 구현되지 않음.

- What is Agile? | Atlassian - 아틀라시안이 알려주는 애자일 A to Z https://news.hada.io/topic?id=4389

저는 아래 설명에는 공감하며, 나머지는 그려러니 합니다.

> "'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다."

그 이유는 이미 모두 아는 바와 같이 어떤 방법이 상업적(혹은 프로젝트)의 성공을 보장하지는 않기 때문입니다. 심지어 게임 한정으로 애자일이 다른 접근법들보다 통계적으로 더 유의미한 결과를 내지는 않는다는 연구도 있었습니다:

"위대한 게임 개발팀은 모든 구성원이 스튜디오의 개발 방법론을 잘 훈련하여 따르도록 합니다 [1]. 또한 게임 개발 중에도 지속적으로 수고를 들여 개발 방법을 갈고닦아 개선합니다. 그럼에도 불구하고 우리는 애자일과 애자일-스크럼, 혹은 워터폴 개발 방법 사이에서 통계적으로 유의미한 성과 차이를 발견하지 못 하였습니다 [2]. 개발 방법론 중 성과에 차이를 보인 것은 아무런 개발 방법론이 없는 경우였습니다: 우리의 연구는 팀원이 많던 적던 개발 방법론이 없는 것은 재앙적이라는 사실을 발견하였습니다.

개발 방법론에 보편적인 정답은 없습니다. 스스로 생각하기에 여러분의 팀과 프로젝트에 가장 적절하다고 판단되는 개발 방법론을 선택하세요."

(출처: https://masterfarseer.blogspot.com/2015/03/5.html )

그럼에도 불구하고 제가 애자일의 접근법(좀 더 정확히는 스크럼, XP와 칸반)을 선호하는 이유는 제가 당면한 문제를 해결해주기 때문입니다(It works!) 같은 이유로 "애자일 선언문"에서 제가 가장 좋아하는 대목은 "우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다."입니다. 그것은 어떤 이론에 근거해서 방법론을 만든 게 아니라, 실제로 '내가 해보고 효과를 봤고, 다른 사람들에게도 추천했더니 역시 효과가 있었다.'는 것을 기초로 하기 때문입니다. 켄 슈와버와 마이크 비들이 쓴 Agile Software Deveopment with Scrum에서도 실천법을 먼저 발명하고, 나중에 그 이론적 근거를 발견하는 여정이 언급됩니다. 그리고 그 관점이라면, 언젠가 누군가가 애자일을 더 발전시킬 수도 있고, 애자일보다 더 나은 것을 발명할 수도 있다고 생각합니다.

다른 모든 도구들과 마찬가지로 애자일은 만병통치약이 아니니, 누군가에게는 효과를 낼테고, 누군가에게는 효과가 없을 거라고 생각합니다. 그래서 이제는 누군가가 애자일로 성공했다고 특별히 더 용기를 얻거나, 혹은 실패했다고 해서 특별히 낙담하지 않습니다. 동시에 더 나은 방법이 있다면, 언제든 시험하고 적응할(inspect and adapt) 의사가 충만합니다. 그게 스크럼이 제게 준 진정한 교훈이니까요.

 
Modern Unix - 유닉스 명령들의 최신 대체제

더 빠르고 쓰기 편한 대체 명령어들
cat → bat
ls → exa, lsd
diff → delta
du → dust
df → duf
tree → broot
find → fd
grep → ripgrep
ack → ag
history → mcfly
cut,awk → choose
sed (json) → jq
sed → sd
man → cheat, tldr
top → bottom, glances, gtop
ping → gping
ps → procs
curl → curlie
cd → zoxide
dig → dog

fzf - fuzzy finder
hyperfine - CLI benchmarking tool
httpie - CLI HTTP client for API
xh - 더 빠른 httpie

 
Mosh : Mobile Shell - 진화된 SSH

- IP변경 / 재연결시에도 연결을 유지하는 오픈소스 SSH 대체 앱
- SSH로 기존 인증방식을 이용해서 접속한 후, 원격에서 mosh-server를 실행하고 UDP로 연결
ㅤ→ 네트웍 버퍼를 사용하지 않으므로, Ctrl-C가 항상 빠르게 잘 동작
ㅤ→ 서버의 응답을 대기하는 SSH와 달리 네트워크 Lag없는 빠른 응답
- Tmux 및 어떤 터미널에서도 이용 가능
- 별도의 데몬 필요없음
- Linux/BSD/맥/안드로이드/크롬/iOS
ㅤ→ 윈도우에서는 Mosh for Chrome 또는 Cygwin용 사용
- UTF-8만 지원 (다른 터미널 과 SSH의 유니코드 버그를 수정)

 
LiaScript - 마크다운으로 온라인 강좌 만들기

- 별도의 도구없이 텍스트 에디터 만으로 온라인 강좌를 만들수 있는 오픈소스
ㅤ→ 마크다운으로 작성된 코스를 브라우저가 렌더링
ㅤ→ 자바스크립트를 이용해서 자유롭게 확장 가능
- 마크다운을 확장
ㅤ→ 비디오/오디오 등 멀티미디어
ㅤ→ Text2Speech & 애니메이션
ㅤ→ 퀴즈 & 설문조사 : 텍스트 입력, 단일/다수 선택, 매트릭스 에서 선택, 힌트
ㅤ→ 설문조사 기능
ㅤ→ 코드블록 : 편집 및 실행가능
ㅤ→ 테이블 데이터의 자동 시각화
ㅤ→ <script> 태그 지원
- Elm + TypeScript 오픈소스

LiaScript 로 만든 LiaScript 가이드
- https://liascript.github.io/course/…

가이드 둘러보니 기능이 엄청 많네요. 간단한 퀴즈나 튜토리얼은 이걸로 만들어봐야 겠어요.

 
웹용 SQL의 미래

- absurd-sql : SQL.js(SQLite)로 IndexedDB에서 데이터를 조금씩 읽고 쓰는 형태
ㅤ→ DB데이터를 다른DB에 저장하는 황당한 방식이라 absurd
ㅤ→ IndexedDB는 느리고 기능도 별로 없으나, 이 방식으로는 10배 이상 빠름
- sql.js를 후킹해서 IndexedDB에 데이터를 저장
ㅤ→ 아직 SQLite 네이티브 보다는 50~100x 느림
ㅤ→ 이건 IndexedDB를 이용했지만, Storage Foundation API도 이용 가능할 듯(테스트 예정)
- 장/단점
ㅤ→ 유일한 단점은 gzip된 WASM(SQL.js) 파일을 다운받아서 사용한다는 것
ㅤ→ SQLite의 모든 기능 활용 가능 : 트랜잭션, 완전한 Query 시스템, View, CTE, 트리거, Full-text Search, 캐슁 등

특히 일렉트론의 존재때문에 더 그런거 같아요.

웹버전과 똑같이 IndexedDB 쓰다가 일렉트론 버전에서는 SQLite 로 갈아타서 훨씬 살만해졌다는 Notion의 후기도 있더라고요.

https://www.notion.so/blog/faster-page-load-navigation

이런 경험이 웹으로 역수출되는 것 같기도 하고 그러네요.

제목은 원 저자의 "A future for SQL on the web" 을 그대로 가져왔습니다.

sql.js-httpvfs - GitHub Pages에서 SQLite DB 호스팅 하기 https://news.hada.io/topic?id=4226
이 글이 다양한 영감을 주고 있네요.

편법이지만, W3C가 웹에서는 SQL이 맞지 않다며 중단해버린 WebSQL의 귀환이네요. 사실 개발자한테는 훨씬 편할듯.

 
Slip - 프로그래밍 강의를 만들어서 판매하기

- 누구나 인터랙티브 프로그래밍 강의를 만들어서 팔 수 있게 해주는 SaaS
ㅤ→ Python, Go, Ruby, Rust, Node/JavaScript 지원
ㅤ→ 마크다운, 비디오, 코드 스니펫(ACE 에디터), CodeSandbox 및 Figma 임베딩 지원
ㅤ→ 코드 실행은 원격 Docker로
- 모바일 지원
- 월 비용 없이 판매 수수료 10% + 결제 수수료(Stripe)

개발자가 VIM 온라인 강의인 https://vim.so 를 만들어서 한달만에 $10k 수익을 내고, 그 경험을 바탕으로 더 확장해서 만들었다고 하네요.
특정 언어나 프레임워크에 능숙하신 분들은 한번 강의로 만들어서 팔아보면 좋을 듯 합니다.

 
Never Install - 데스크탑 앱을 설치없이 브라우저에서 사용하기

- 클라우드 기반 앱 스트리밍 플랫폼
- 크롬,FF,IntelliJ,PyCharm,VS Code,Eclipse,Jupyter,Android Studio 등을 설치 없이 브라우저에서 실행
ㅤ→ 실행시에 위치 지정가능 (미국,인도,싱가폴) : VPN 처럼 사용
ㅤ→ 여러개의 워크스페이스 생성 지원
- 무료사용자도 2vCPU, 4GB 램, 5GB 저장소를 무제한 사용 가능
ㅤ→ 유료 플랜은 더 좋은 성능,램 제공 예정
- 여러 사용자가 같이 보면서 사용하는 실시간 협업 기능 제공 (이메일로 초대)
- 워크스페이스는 30분동안 미사용시 자동으로 멈추고, 4일간 사용 안하면 자동으로 삭제

 
Systemizer - 시스템 디자인 시각화 도구

- 분산시스템의 하이레벨 아키텍처 디자인을 쉽게 표현하기 위한 다이어그램 도구 오픈소스
ㅤ→ 웹서버, LB, API GW, Pub/Sub Model, DB(SQL,NoSQL), Cache, MQ, CDN 등
- JSON 형식 문서로 저장
- PNG/SVG로 Export 지원
- IFrame으로 문서를 다른 곳에 임베드 지원

 
오픈소스 Health Icons

- 자유롭게 편집 및 재배포 가능 (CC0)
- 건강에 관련된 1000+개의 아이콘들
ㅤ→ 혈액형 : ABO, RH+-
ㅤ→ 신체 : 뇌,팔,다리,관절,심장/신장/폐/척추/간..
ㅤ→ 컨디션 : 알러지, 기침, 요통, 설사, 감기, HIV, HPV, 비만, 구토..
ㅤ→ 의료기기 및 용품 : 혈압계, CT, X-Ray, 제세동기, 침대, 산소통, 수액팩, 수술 마스크, 수술복, 주사, 휠체어..
ㅤ→ 이모지 : 붕대, 기침, 열, 어지러움..
ㅤ→ 사람 : 태아(8~12주, 24~26주), 아기(2~3개월,3~6개월,1~5세..), 의사, 간호사..
ㅤ→ 진료과 : 중환자, 심장, 내분비, 산부인과, 혈액, 종양, 외래, 약국, 안과, 방사선과...
ㅤ→ 진단, 가족계획, 약, 장소..
- Figma 플러그인 제공

 
ots - 1회성 URL로 e2e 암호화된 Secret 공유하기

- API Key, 암호 등을 남과 공유할 때 사용하는 도구
- 한번 보거나, 안봐도 특정 시간이 지나면 자동으로 삭제
- 로컬에서 암호화된 뒤 전송됨
- CLI/웹 버전으로 사용가능 (셀프호스트 버전은 개발중)

$ ots new -x 2h
Enter your secret:
ㅤ→ 한번 보거나, 안보더라도 2시간이 지나면 지워지는 1회용 URL이 생성됨

 
코드베이스 시각화 하기

- GitHub OCTO 개발자경험팀의 새 실험 프로젝트 (오픈소스로 공개)
- 저장소를 한 눈에 볼 수 있는 "fingerprint" 이미지로 자동으로 만들어서 보기
ㅤ→ 폴더 = 원, 파일 = Dot, 파일크기 = Dot 크기, 파일종류 = 색상
- 자신의 Repo에 적용해서 보기 지원
- GitHub Action을 이용해서 README에 최신 svg 파일로 보이도록 추가 가능
- 차후엔 파일간의 연결, 최근 업데이트된 파일 보기, 코드 변경 이력 보기 등으로 확장 가능할 것

비디오로 시각화 하는 도구도 있어요. https://gource.io/

 
현대 신경과학은 과연 동키콩을 이해할 수 있는가 (2016)

Chapter 1 : 디지털 고고학

- Greg James 라는 프로그래머가 청소도중 아타리2600과 애플2를 발견.
- 둘다 MOS6502 라는 마이크로프로세서를 사용한다는걸 알게 됐고, 해당 칩을 개선하고자 설계에 대한 정보를 찾았지만 관련 정보가 하나도 남아있지 않았음.
- MOS는 모토롤라에서 일하던 몇명의 엔지니어가 설립한 회사로, 그 당시의 반도체 설계는 제도판 위에 트랜지스터 하나하나를 손으로 그려넣는 수작업의 결과물이었음. 설계도면은 유실되었고, 디지털화된 자료나 문서도 남아있지 않다는걸 알게 됨.
- 그렉은 자신의 친구들과 디지털 고고학 프로젝트를 시작, 리버스 엔지니어링 통해 해당 마이크로프로세서를 발굴해내기로 마음 먹음.
- 마이크로프로세서를 화학처리 해가며 섬세하게 분리하고 수백배로 확대해 물리적 구성요소들을 일일이 관찰해 가며 모델링을 시작
- 5년간의 집념끝에 칩의 하드웨어적인 구조를 완벽히 파악한 후 모든 정보를 자바스크립트로 옮겨 완벽한 에뮬레이션을 만들어냄  (http://visual6502.org/JSSim/index.html).
- 해당 정보를 FPGA(Field Programmable Gate Array, 회로변경이 가능한 반도체)에 넣어 작동시키니 정말 MOS6502 처럼 작동하는 것을 확인할 수 있었음

Chapter 2 : 신경과학으로 마이크로프로세서 분석하기

- 두 신경과학자 Konrad Kording 과 Eric Jonas 는 디지털 고고학 작업이 뇌신경과학자들이 하는 작업과 유사하다는 것을 발견
- 마이크로프로세서 칩의 상세한 도면사진을 세밀하게 찍어가며 특정 구역별로 구분짓고, 커넥션들을 확인해가며 맵을 그리는것이 마치 오늘날 신경과학자들이 뇌를 localization 해가면서 구분된 영역에 이름을 붙이고 뉴런의 네트워크를 그려가며 모델링하는 것과 유사
- 그렇다면 6502 칩을 뇌신경과학 방법론으로 분석하면 어떻게 될까?
- 마이크로프로세서의 하드웨어적인 전기 신호를 분석하는걸 통해 동키콩이나 스페이스인베이더 같은 소프트웨어적 특성을 알아낼 수 있을까?
- Kording 과 Jonas 는 6502칩을 각종 뇌신경과학 분석법을 시도함.

Result: Epic fail. 아무런 정보를 얻어내지 못함.

- MOS6502 는 뇌에 비하면 훨씬 단순한 구조이고 실험자가 모든 것을 통제할 수 있었음에도 불구하고, 칩이 실제로 어떻게 정보를 처리하고 작동하는지 이해하는데 필요한 정보를 얻지 못함.
- 뇌와 마이크로프로세서는 근본적으로 다르기에, 이런 분석만으론 기존의 신경과학적 접근방법을 완전히 부정할 수는 없음.
- 하지만 시스템의 모든 데이터를 얻는 것이 시스템을 이해하는 것으로 이어지지는 않을 수 있다는 것을 시사.

 
JSii - 어떤 언어든 JS 클래스와 인터랙션 가능하게 만드는 컴파일러

- AWS CDK가 싱글 코드베이스에서 Polyglot 라이브러리를 제공할 수 있게 만드는 기술
ㅤ→ TypeScript로 작성한 클래스 라이브러리 하나만 가지고 Python, Java, C#(.NET 패밀리), Go 등 다양한 언어에서 호출 가능하게 만듦
ㅤ→ 각각의 언어용 SDK를 만들 필요가 없어서 빠르게 기능 추가 및 개선 가능
- JSON 마샬링 비용 문제나, 분산GC 기능이 없어서 성능이 중요한 어플리케이션들 보다는 "개발/빌드 도구"에 적합

 
SMSHub - 안드로이드폰을 이용한 SMS 전송/수신용 Gateway

- 안드로이드폰에 설치하는 SMS Gateway 앱 오픈소스
- 정해진 시간마다 웹서버의 URL에서 JSON을 읽어서 자동으로 SMS를 송신
ㅤ→ JSON : 보낼 내용, 전화번호, 메시지ID
ㅤ→ 읽을 URL, 인터벌, 전송 결과 보고용 URL 설정 가능
- SMS 수신시 특정 URL에 내용/전화번호 전달

안드로이드 폰을 이용한 SMS Gateway들 앱은 여러개 있는데
이건 앱 자체가 웹훅형태로 서버에 연동하는 거라, 폰과 서버의 연결부분이 간단해서 좋은거 같아요.

 
github.dev - GitHub코드를 VS Code로 1초만에 둘러보기

https://news.hada.io/topic?id=3719
(이 글과 제목을 맞추었습니다)

위 링크에서도 소개되었던 github1s 라는 서비스가 있었는데, GH를 인수한 MS에서도 같은 서비스를 낸 듯 합니다. 일단은 github1s 가 오히려 더 안정적이라는 평이 있긴 하지만, GH와 VS Code를 둘 다 보유한 MS인만큼 앞으로가 기대되네요.

github에서 키보드로 . 을 누르면 바로 넘어가는 단축키가 적용되어 있네요.
github1s는 플러그인이 전혀 설치가 안되는데, github.dev는 플러그인 검색 시 사용 가능한 플러그인이 구분되어서 보이고 설치도 잘되서 개인적으론 github.dev가 훨신 좋은것 같습니다.

 
Bytebase - 웹 기반 DB스키마 변경 및 버전 관리도구 오픈소스

- Team을 위한 DB 스키마 변경 관리도구
ㅤ→ UI 기반의 SQL 리뷰
ㅤ→ 버전관리 기반 스키마 마이그레이션 (Database-as-Code)
- MySQL 지원. PostgreSQL 지원 예정
- VCS : GitLab EE/CE 지원. GitHub/GitLab/GitHub Enterprise 지원 예정
- Go + SQLite + Vue + TailwindCSS 오픈소스

 
LINE, FIDO2 서버 오픈소스로 공개

- FIDO2(Fast IDentity Online, WebAuthn)
ㅤ→ FIDO2는 UAF+U2F 표준을 통합하고 모바일+웹등 어디서나 사용가능하게 개선한 표준
ㅤ→ 얼굴이나 지문 등의 생체정보, Yubikey, Google Titan key와 같은 외부 인증 장치로 손쉽고 빠르게 로그인과 인증을 진행
- LINE의 FIDO2 서버
ㅤ→ FIDO2 표준을 구현하고 FIDO Alliance에서 공식 인증
ㅤ→ FIDO2 서버, FIDO2-spring-boot-starter, FIDO2 RP 서버 샘플 제공
ㅤ→ SpringBoot + Gradle + Java

 
소셜미디어 너머의 미래로 향하는 페이스북 [번역]

- 광고 사업은 소셜 네트워크 기업인 페이스북을 수조 달러 규모의 공룡 기업으로 만든 원동력
- 페이스북이 새로운 시도를 바탕으로 더 성장할 수 있을까?
- 첫 번째 시도는 “크리에이터 경제”
- 두 번째 프로젝트는 전자상거래 플랫폼
- 가장 큰 프로젝트는 메타버스 : 게임과 몰입형 엔터테인먼트를 넘어 사람들이 생활하고 일하는 공간이 될 것

 
Unpaywall - 오픈 액세스 논문 검색엔진

원래 논문들의 오픈 액세스 버전을 찾아주는 사이트
Sci-Hub와 같은 사이트를 사용하지 않고 저작권법을 준수
직접 검색이나 Firefox/Chrome Extension, REST API를 통해 사용가능

Sci-Hub 가 현재 8500만건인데, Unpaywall 은 2900만건 이네요. 이정도면 훌륭한듯

 
OpenAI Codex 공개 및 파이썬 퍼즐 챌린지 예정

- 자연어를 코드로 변환하는 AI 시스템
ㅤ→ GitHub Copilot의 기반이 된 기술
ㅤ→ 비공개 베타 API로 공개해서 다른 회사/개발자도 이용 가능
- GPT-3를 확장
ㅤ→ 기존 자연어 데이터와 공개 GitHub Repo의 코드를 포함하여 공개적으로 사용가능한 수십억줄의 코드 포함
ㅤ→ Python 에서 가장 잘 동작하지만 Javascript, Go, Perl, PHP, Ruby, Swift, TypeScript 및 Shell 을 포함한 12개 이상의 언어를 지원
ㅤ→ GPT-3는 4KB 였던데 반해, 파이썬 코드를 위해 14KB 메모리를 가지고 있어서 작업수행중 상황정보를 3배이상 고려 가능
- OpenAI Codex 는 범용 프로그래밍 모델로 모든 프로그래밍 작업에 적용 가능
ㅤ→ 언어간 번역, 코드 설명, 리팩토링등에 성공적으로 사용했지만, 이건 할 수 있는 일의 아주 일부만 건드린 것이라고 생각함
ㅤ→ API를 통해서 빨리 안전하게 확장하는 것을 목표로 함
ㅤ→ 초기 기간중에는 무료로 제공될 것
- Waitlist 에 등록 받는 중

- OpenAI Codex Challenge 예정
ㅤ→ 8/12 오전 10~1시 (태평양 표준시)
ㅤ→ Codex를 경쟁상대 또는 팀 동료로 삼아서 빠르게 Python 퍼즐을 푸는 대회

 
GDC 2011 동굴 이야기 강연 : 게임개발시 주의할 5개 요소 (번역)

동굴이야기는 2004년 프리웨어로 배포된 1인 개발 인디게임으로, 높은 비평적 평가와 함께 닌텐도 스위치, 리눅스, 맥 등으로 이식돼 판매되고 있습니다.

동굴이야기의 개발자 아마야 다이스케의 Game Developers Conference 강연

게임의 비주얼
- 알기 쉬운 비주얼이 중요.
- 주인공을 눈에 띄게 하기 위해 빨간색은 거의 주인공에게만 사용.
- 주인공의 표정을 알기 쉽게 하려고 머리를 크게, 팔동작을 쉽게 보여주려고 신체는 작게.
- 플레이어의 시야는 제작자의 시야보다 좁으니 처음부터 여러가지를 보여주지 말 것.

쌍방향성
- 베히모스라는 적은 주인공을 먼저 공격하지는 않지만, 주인공이 공격하면 화내면서 반격하러 온다. 플레이어의 행동에 응답하는 게임 디자인은 플레이어의 흥미를 부른다.

사운드
- 사운드는 적은 노력으로 큰 효과를 줄 수 있는 요소.
- '무거운 문' 을 표현하고자 할때, 비쥬얼로 표현하는 것은 어려운 일이지만 소리를 사용하면(부딪혔을때 둔탁한 소리를 낸다던지) 쉽게 표현할 수 있다.
- 아마추어 게임에서는 사운드에 대한 고려가 부족한 경우가 많음. 사운드는 가능한 많이 들어갈 수록 좋다.

BGM
- BGM의 3가지 기능 : 전경묘사, 상태전달, 스며듦.
- 전경묘사 : 같은 스테이지라도 BGM이 바뀌면 분위기가 달라진다.
- 상태전달 : 보스전에서는 위기감을 부추기는 음악을 사용한다.
- 스며듦 : 좋아하는 음악은 마음에 남는다. 마음에 남은 음악이 한번 더 등장하면 플레이어는 매우 기뻐한다.

스토리
- 스토리 자체보다는 플레이어에게 전달되는 것이 중요.
- 게임 시작 직후에 스토리를 담아선 안된다.
- 플레이어는 우선 '플레이 하고 싶다' 라고 생각한 뒤에 스토리를 즐기고 싶다고 느끼게 된다.

- 이러한 요소를 사용해 플레이어를 컨트롤하는 것이 중요.
- 스테이지가 외길이라면 플레이어는 게임에 작업감을 느껴버린다.
- 2가지 길을 만들어 한쪽 길을 적으로 채워 두면, 플레이어는 판단하고 선택을 내린다.
- 플레이어가 '조종되고 있다'고 느끼게 하면 안된다. '스스로 해결했다'고 생각할 수 있도록 주의를 기울일 것.

- '무거운 문' 을 표현하고자 할때, 비쥬얼로 표현하는 것은 어려운 일이지만 소리를 사용하면 쉽게 표현할 수 있다.

이 부분을 읽고 완전 설득당해버렸습니다.

"- 스테이지가 외길이라면 플레이어는 게임에 작업감을 느껴버린다.
- 2가지 길을 만들어 한쪽 길을 적으로 채워 두면, 플레이어는 판단하고 선택을 내린다."

횡스크롤형 게임에서 시작하자 마자, 뒤로 가면 뭔가 숨겨진 아이템을 찾게 되는 기믹 하나만으로도 기분이 좋아지는 거도 같은 거네요. 이게 버릇 되어버려서 뭔가 정해진 길이 있으면 꼭 다른데를 가려고 시도해 보게 됩니다.

 
eBPF 재단 출범

- Linux 재단의 일부
- 페이스북, 구글, MS, 넷플릭스, ISOValent가 창립멤버로 참여
"eBPF의 강력한 기능을 확장하고, Linux를 넘어 성장하기 위해 기여할 것.
오픈소스 eBPF 기술의 홈이 될것이며, Summit 및 기타 행사들을 통해 커뮤니티 육성 예정"
- eBPF Summit : 8/18~19에 무료/온라인으로 개최예정

eBPF설명은 제가 예전에 긱뉴스 팟캐스트에서 설명한게 있습니다.
- https://www.youtube.com/watch?v=aCw0YwEHpCU&t=1892s

- eBPF rethinking the Linux Kernel - https://news.hada.io/topic?id=1958
- BPF : 새로운 타입의 소프트웨어 - https://news.hada.io/topic?id=1011
- bpf를 이용한 성능분석 - https://news.hada.io/topic?id=88
- eBPF 공식 사이트 오픈 https://news.hada.io/topic?id=2661
- eBPF Summit Recap https://news.hada.io/topic?id=3117
- eBPF on Windows https://news.hada.io/topic?id=4240