(번역) 프런트엔드 개발의 종말 : AI에 발전으로 인해 개발자의 일자리가 줄어들 것이라고 걱정을 많이 하는데 웹 개발자가 사라지지 않을 거라는 생각을 정리한 글이다. 1990년대부터 노코드 도구들이 등장하고 웹 개발자는 쓸모없어졌다고 하는 얘기는 계속 있었지만 그런 일은 일어나지 않았고 GPT가 만들어 준 웹사이트는 놀랍지만 이미 지금도 이런 일에는 웹 개발자가 필요하지 않고 AI가 계속 발전하겠지만 AI의 환각 현상을 알아내거나 제대로 만들려면 여전히 웹 개발자가 필요하다. AI를 낙관적으로 보고 있고 AI로 인해 생산성이 높아질 것이고 오히려 더 많은 개발 일자리를 만들 수도 있다고 하고 있다. 미래가 어찌 될지는 모르지만, 개인적인 내 생각과 비슷하다.(한국어)
Why I regret using Ionic for app development : Ionic으로 앱을 개발했는데 Flutter를 사용할 걸 그랬다며 Ionic의 문제점을 정리한 글이다. Ionic은 문서화가 너무 안 되어 있고 내부적으로 Cordova를 쓰는데 이를 대체할 Capacitor로 대체되었지만, 문서가 너무 정리가 안 되어 있고 어떤 내용은 Ionic 문서에 어떤 내용은 Capacitor 문서에 있어서 사이트에서 찾기보다는 구글링하는 게 나을 정도라고 한다. 그리고 Cordova 플러그인이 다 Ionic에서 사용할 수 있는 것은 아니라서 개발자가 직접 호환성을 체크하면서 써야 하고 Ionic을 개발하면 제품을 더 좋게 만드는 것보다 문서 찾고 버그 수정하는데 너무 많은 시간을 써야 했고 실제 문제를 해결하려면 Ionic뿐 아니라 Capacitor도 알아야 했다고 한다. 글쓴이는 React Native도 비슷한 상황이고 비슷한 접근이라면 Flutter가 제일 나은 선택이라고 한다.(영어)
그 밖의 개발 관련
매일 배포하는 팀이 되는 여정(1) — 브랜치 전략 개선하기 : 잦은 배포를 위해서 브랜치 전략을 공부하고 배포 과정을 개선해 나간 경험이다. Git Flow 전략을 쓰면서 정기 배포일을 정해놓고 배포하고 있었는데 한 번에 너무 많은 변경 사항이 같이 나가다 보니 추적도 어려웠고 배포도 점점 부담되어서 Git Flow의 단점이 보이기 시작해서 브랜치 전략을 공부했다. main 브랜치를 mainline으로 사용하는 GitHub Flow와 Trunk-Based 브랜치 전략을 공부하고 GitHub flow를 선택하고 배포 과정이 훨씬 나아졌다고 한다. 개인적으로 Git Flow는 안 좋게 보기 때문에 이런 글이 더 많이 퍼졌으면 좋겠다.(한국어)
코어 빌드 시스템은 언어 규칙에 대한 지식을 가지지 않는다. 코어는 Rust로 작성되었고 언어 규칙은 Starlark로 작성되어 언어 규칙과 코어를 분리했다.
하나의 증분 의존성 그래프로 빌드 시스템이 동작해서 버그를 줄이고 병렬성을 높인다.
규칙 API는 성능을 위한 고급 기능을 가지도록 설계되었다.
오픈소스 릴리스도 내부 버전과 거의 같다.
Buck2는 원격 실행과 통합되도록 작성되었고 Bazel과 동일한 API를 사용한다.
Buck2는 가상 파일 시스템과 통합되도록 작성되어 전체 레파지토리를 체크아웃하지 않고 필요할 때 파일을 가져올 수 있다.
Building GitHub with Ruby and Rails : Ruby on Rails로 만들어진 GitHub.com은 이제 200만 줄의 코드로 구성되어 1,000명이 협업하고 있다. 매주 월요일 GitHub Actions 워크플로우가 Rails 프로젝트 메인 브랜치의 최신 커밋으로 Rails 버전을 업데이트해서 모든 빌드를 새 버전으로 돌린다. 전에는 새 버전 업데이트에 여러 달이 걸렸지만 이제 1주일 이내로 완료할 수 있게 되었는데 이 이점으로 Rails에 패치를 보내고 기다리거나 할 필요없이 Rails 프로젝트에 바로 패치를 보낼 수 있게 되었고(머지되면 다음 주에 바로 적용될 테니) 보안에도 좋으며 빅뱅 마이그레이션이 없어지게 되었다고 한다. 비슷한 업그레이드가 Ruby에도 적용하고 있어서 Ruby 3.2때는 한 달 만에 업그레이드했지만 3.2.1을 당일날 업그레이드했다고 한다.(영어)
DEVOPS VS SRE: DELAYED COVERAGE OF THE DUMBEST WAR : DevOps와 SRE에 관한 2016년 글이라 좀 지났지만 지금도 유효해 보여서 가져왔다. Gareth Rushgrove가 2016년 West Coast Velocity 컨퍼런스에서 "The Two Sides of Google Infrastructure for Everyone Else(GIFEE)"라는 발표했다. 이 발표에서 GIFEE가 구글 외 모두가 가져야 할 목표인지 구글이 아니면 상관없는지 찬성 반대 의견을 모두 얘기하면 제일 중요한 것은 컨텍스트라는 얘기를 하고 있는데 발표 자료만 봐도 흥미롭다. 이 글을 쓴 honeycomb의 CEO인 Charity Majors도 자신이 그전에 올렸던 트윗을 정리하며 DevOps와 SRE의 철학적 논쟁은 컨텍스트의 힘을 무시했기 때문에 발생하며 Google SRE 원칙을 규범적인 모델로 적용하려고 하면 낭패를 볼 것이고 그런 획일적인 솔루션은 없다고 하고 있다.(영어)
Pod rebalancing and allocations in Kubernetes : Kubernetes에서 Pod을 균형 있게 스케쥴하는 옵션을 설명한 글이다. antiaffinity는 같은 레이블을 가진 Pod을 다른 노드에 배치되도록 하고 topology spread constrains는 클러스터 전체에 Pod이 확산하는 정책을 정할 수 있다. 이 둘은 스케줄링할 때만 결정하기 때문에 이미 스케쥴링되었다면 조정하기 위해서 수동으로 재시작해야 한다. 동적으로 Pod을 재조정하려면 Descheduler를 사용해서 계속 조정되게 할 수 있다.(영어)
컨테이너의 구조와 오픈소스의 생태계에 관한 리서치(feat. 도커는 적폐인가?) : 컨테이너 이미지 관련해서 리서치하면서 정리한 글이다. 처음에는 직접 pivot_root와 OverlayFS로 컨테이너의 구조를 살펴보고 CRI, OCI가 무엇이고 Docker와는 어떻게 연결되어 있는지를 설명한다. 이 컨테이너를 빌드하는 도구 중 jib, kaniko, BuildKit을 간단히 설명하면서 컨테이너가 표준화가 많이 되어있지만, Dockerfile은 따로 표준이 없기 때문에 Dockerfile을 사용한다면 Docker와의 의존성은 끊기 어렵다고 설명하고 있다.(한국어)
모던 테라폼 (Modern Terraform) : 박병진 님이 Terraform 1.0 이후 1.5까지 도입된 주요 변경 사항과 최근에 쓰고 있는 Terraform 관련 도구를 정리한 발표 자료이다.(한국어)
[Skrr] 출시 3일만에 카카오톡을 제치고 앱스토어 2위를 달성한 사이드 프로젝트 : 한국 디지털미디어 고등학생들이 미국에서 인기 있던 익명투표 앱 Gas를 카피해서 국내에 릴리스해서 큰 인기를 끈 Skrr를 만든 과정을 정리한 글인데 진행 과정을 보면 정말 잘한다고 하는 생각이 든다. Gas 같은 익명 투표 앱이 국내에서도 동작할까 하는 가설을 검증하기 위해 Skrr를 만들었고 베타 테스트를 통해 투표 받으면 기분이 좋고 특성상 바이럴 될 수밖에 없으며 누가 투표했는지 알려면 돈을 내야 하는데 이 부분이 실제로도 너무 궁금해졌다고 한다. 학교 안에 쪽지를 남기는 마케팅을 진행하게 해 397명의 디미고 학생을 모으고 다른 학교에서 퍼지기 시작해서 16,000명의 사용자를 모았다고 한다.(한국어)
Here’s the latest version of our Engineering Career Framework : Dropbox가 각 직무의 레벨과 각 레벨에서 요구되는 역할을 정의한 Dropbox Engineering Career Framework를 2년 전에 공개했는데 이번에 업데이트가 되었다. 기존 프레임워크가 크고 주목할 만한 성과에 평가와 승진이 치우쳐 있다는 인식이 있고 사내 설문조사 결과 각 역할의 Core Responsibilities가 수행 중인 업무를 반영하지 않는다고 25% 이상 대답하고 20%는 다음 단계로 가기 위해 뭘 해야 하는지 모르겠다고 대답했다. 커리어 프레임워크는 승진을 위한 체크리스트가 아니라고 했지만 실제로 그렇게 쓰이고 있었기에 프레임워크의 명확성과 정확성을 개선했다.(영어)
Calling all open source maintainers : 오픈소스 메인테이너가 서로 교류할 수 있도록 GitHub에서 비공개 공간을 만들었다. 메인테이너를 위한 이벤트, 베타/프리뷰 기능에 대한 조기 접근, 오픈소스에 대한 워크숍을 진행할 예정이고 오픈소스 메인테이너라면 해당 저장소에 직접 초대를 요청할 수 있다.(영어)
Comments