최근 소프트웨어 엔지니어링 업계에서 흥미로운 글 하나가 공유되었다. 핵심은 아무도 단순함을 이유로 승진시켜주지 않는다는 것이다. 복잡한 설계를 가져온 엔지니어는 화려한 기술적 서사를 써 내려가지만, 문제를 가장 단순하게 해결한 엔지니어는 구현했다는 한마디 외에 쓸 말이 없어진다는 문제 제기다.

기존의 이슈 등록, 커밋, 푸시, PR, 머지로 이어지는 방식은 90년대식 메커니즘에 가깝다. 사람의 실수를 방지하고 비동기 협업을 위해 설계된 이 과정은 컨텍스트를 완벽히 이해하는 AI 에이전트가 코딩을 주도하는 시대에는 오히려 낭비가 된다. AI 시대에 어울리는 새로운 개발 워크플로우를 제안한다.

AI 코딩 도구가 일상화되면서 풀 리퀘스트에 대한 회의론이 커지고 있다. PR 리뷰가 더 이상 이해와 책임을 넘기는 장치로 작동하지 않는다는 지적이다. 하지만 이 논의에 빠진 한 가지 가정이 있다. 코드를 쓰는 것과 리뷰하는 것이 같은 주체여야 한다는 전제 말이다.

GitHub 에서 오픈 소스를 사용하다병면 발견한 버그를 직접 수정하거나, 새로운 기능을 추가하고 싶을 때가 있습니다. 하지만 어디서부터 어떻게 시작해야 할 지 막막하기도 합니다. 이번 포스트에서는 오픈 소스에 컨트리뷰션(기여)하는 절차를 간단히 알아보겠습니다.

쿠버네티스(Kubernetes)에서 시시각각으로 변하는 오브젝트의 상태를 저장하고 관리하려면 어떻게 해야 할까요? 가장 먼저 생각할 수 있는 방법은 YAML 파일로 export 해서 저장하는 것입니다.

이번 포스트에서는 간단한 스프링 부트(Spring Boot) 애플리케이션을 만들고 컨테이너화(Containerize)하는 방법을 알아봅니다. 그리고 다양한 툴을 이용해 도커 이미지를 지속적으로 빌드하고 배포할 수 있는 CI/CD 환경을 구성하고 쿠버네티스(Kubernetes) 클러스터에 배포하는 과정을 살펴봅니다.

지난 포스트에서는 HTTPS 를 왜 사용하는지, 어떤 원리로 동작하는지에 대해 알아봤습니다. 이번 포스팅에서는 Hexo 블로그에 HTTPS 를 적용해보겠습니다.

이전 포스트에서 github 유저 혹은 리파지토리의 정보를 가지고 있는 네임카드를 Hexo 블로그에 달아봤습니다. 저는 사이드바에 달아서 지금 블로그를 보시면 네임카드를 확인해보실 수 있습니다. Github 관련 유용한 플러그인이 하나 또 있어서 추천드리려고 합니다.

Github Card