[AUSG] ⛅︎ 퍼블릭 BIGCHAT 후기

Sangho Han·2025년 6월 27일

🤝🏻 컨퍼런스 & 네트워킹

목록 보기

8/8

🏁 서론

2025년 06월 26일(목) 18시 50분, AUSG에서 진행하는 퍼블릭 빅챗에 다녀왔다.

퍼블릭 빅챗?

빅챗은 AUSG 멤버들이 참여하는 지식 공유의 창으로 격주로 발표를 하고 개발, 클라우드, 커리어 등 다양한 주제로 함께 토론하는 AUSG의 정기 모임이다.

퍼블릭 빅챗은 정기적으로 열리며, 외부인들이 함께 참여할 수 있는 구조인 것 같다.

참여하면 세션과 더불어, AUSG 구성원들과 교류하는 시간을 보낼 수 있다.

장소는 역삼 센터필드였고, AWS 층에서 진행을 해서 처음으로 들어가 보았다!
시설이 굉장히 좋았고 세미나를 할 만한 공간이 많아 보였다.

참가비는 5,000원이었으며, 추첨은 아니었고 선착순으로 참가할 수 있는 것 같다.

입장할 때 귀여운 키링과 스티커를 나누어 주셨다.

개인적으로도 요즘 인프라에 관심이 많아 공부를 하고 있기도 했고, 대학생들이 하는 IT연합동아리 중에서 AUSG이 좋은 퍼포먼스를 보인다고 느껴서 궁금하기도 해 참석하게 되었다.

아래에서는 각 세션 내용과 느낀 점을 적어보려고 한다.

🎙️ 세션 1 : 홈서버 위에서 쿠버네티스 기반 호스팅 서비스 만들기

소개

부제 : 홈서버 환경을 바탕으로 Platform As A Service 만들어보기
연사 : 김보겸님(AUSG 8기, Lablup Software Engineer)

홈 서버 배포

proxmox
Helm Chart

요구 사항

1. 애플리케이션 개발자(Front-Back-DB)는 form 제출만으로도 배포할 수 있다

단, 도커 이미지 빌드는 개발자가 진행한다

2. DB 영속성은 무조건적으로 유지한다

3. 애플리케이션 개발자는 인프라에 대해 알 필요가 없음 (HTTPS 설정) + 애플리케이션 상태 UI를 통해 알 수 있다

어떤 것을 궁금해할까?
- 배포에 대한 메타데이터
- 배포 관련 세부 데이터
- 잘 배포되었는지, 정상적인지 등의 앱 상태
  - 비정상일 때?

4. 자신이 설정한 도메인을 입력하면 → 의도한 애플리케이션으로 라우팅 된다

Virtual Hosting을 이용해 → 하나의 서버에서 여러 도메인을 운영
- Nginx 사용
- Traefik의 서비스 디스커버리 활용
Nginx
- ssl_preread 옵션 → ssl/tls 인증을 하지 않은 상태에서 client hello에 필요한 정보를 추출함

개선할 점

KubeConfig를 어떻게 더 잘 관리할 수 있을까?
- 권한 별 생성
API 서버만, DB만 배포할 수 있는 서비스 기능
- 웹 서비스 전체 중, 일부만 배포하고 싶은 니즈가 더 컸음
더 강력한 모니터링 서비스 제공
- 컨테이너 로그
- 사이드카로 모니터링을 위한 pod를 띄우고 → 이를 통해서 지표 수집 및 제공
Helm Chart에 의존하지 않는 배포

플랫폼이 어디까지 책임질 것인가?

DX와 자율성은 어느정도 반비례한다
- 모든 정보를 보여주면 편하지만 → 플랫폼이 존재하는 이유가 있는지?
- 이미지 빌드까지 플랫폼에서 책임진다면?
  - 빌드가 실패한다면 → 인프라 관리자가 봐야 할까, 애플리케이션 관리자가 봐야 할까?
결론 : 정확하고 명확한 기준은 없다. 모든 것은 목표, 목적에 따라 다르다.

🧑🏻‍💻 첫 번째 세션은 홈 서버 위에서 호스팅 서비스를 구축하신 일대기에 대해서 말씀해주셨다.

최근에 스타트업에서 프리랜서로 일을 시작하게 되었는데, 온프레미스로 인프라를 구축해야 하는 상황이라 이것저것 알아보고 있었다. 설계부터 많은 시간을 쏟고 있는 상황이었기 때문에 해당 세션이 굉장히 흥미로웠다.

인프라에 대해 많은 지식이 있지 않아서 내용 자체는 3~40% 정도 밖에 이해하지 못 한 것 같지만, 어떤 식으로 사고를 하고 설계해야 하는지에 대해서 고민해볼 수 있었다.
특히, 설계 시에 요구사항을 확실하게 정하고 그에 따라서 차근차근 구축하신 모습이 인상적이었다. 나도 이런 식으로 필수적인 부분들을 정리하고, 설계를 진행해 봐야겠다는 생각을 하게 되었다.

또한 마지막 부분에서 플랫폼이 어느정도까지 책임질 것인지에 대해서 스스로 고민해 보신 부분도 좋았다. 추상화와 개발자의 자율성은 어쩔 수 없이 반비례하기 때문에, 모든 것은 목표 & 목적(=요구사항)따라 유동적으로 변화를 주어야 하는 것 같다.

ps. 야크 털 깎기 라는 재미있는 말도 알게 되었다 😄

🎙️ 세션 2 : “No, I don’t think so”

소개

부제 : 프로그래밍의 상식에 반박하기
연사 : 문성혁님(AUSG 3기, 쿠팡 Sr. Back-end Engineer)

It depends.

모든 것은 상황에 따라 다르다.
Principle & Truth

Ch1. HTTP & REST API는 따라야 할까?

Http Status Code의 문제점

낮은 표현력
- 200, 201, 400 …
클라이언트가 알 수 있는 정보가 너무 적다
모호함
- 401을 쓸 지, 403을 쓸 지?
- 401 스펙
  - 헤더에는 WWW 인증 헤더를 보내야 한다

RESTful API

낮은 표현력
- 비즈니스 로직은 훨씬 복잡하다
Soft Delete라면 → DELETE or PATCH?
비즈니스 로직이 API에 드러났으면 좋겠다
- RESTful < Businessful

Ch2. Comment(주석)를 지양하라?

좋은 코드에는 주석이 없다, 라는 착각

코드로 표현하기 어려운 주석들
- 코드 그 자체로는 예외, 함정, 특수상황, 맥락 등을 모두 넣을 수가 없다
주석은 코드와 가장 가까운 데이터임
- 멀어질수록 보기도, 최신화 하기도 어려움

근데 왜 주석을 적지 않을까?

문화적 거부감
관리 난이도
- 코드만 고치고, 주석은 안 고쳐서 문제? → 근데 그런 경우가 실제로는 거의 없음
- 주석 중요도 == 코드 중요도 가 되어야할 것
한정된 인원
- 리소스가 부족하다

No Comment < Bad Comment

코드로만 모든 것을 표현해야 한다? → 현실과는 너무 동떨어진 말 같음
오늘 들어온 사람이 바로 일하기 위해서는 → 충분한 양의 주석이 필요하다

Ch3. TDD는 취향의 문제다?

TDD가 옵션이 아닌 이유

Gen AI → 코드를 손으로 짜는 일이 너무나도 줄어드는 중
테스트 코드를 먼저 짜 → 테스트 코드 확인 → 그 이후에 구현을 해
- 이 정도까지 오면, TDD라는 말이 있을까?
- Planning Mode?
테스트 코드가 검증 수단을 넘어서 → AI에 넘기기 위한 Input이 되지 않을까?
코드에 대해서 아예 몰라도 되는 날이 올 수도 있겠다
- 블랙박스?

TDD is not Option

"계속 생각합시다."

🧑🏻‍💻 두 번째 세션은 인프라와는 조금 거리가 먼, 일반적인 프로그래밍 상식을 약간 비트는 내용이 이어졌다.

개발자는 항상 왜?라는 물음을 가져야 한다. 나도 그렇게 생각하면서 행동하려고 노력하지만, 어느 순간부터는 그러지 못 했던 것 같다. 대부분이 아무렇지 않게 사용하는 HTTP, REST API 등에 대해서도 의문점을 가지며 말을 하시는 모습을 보면서 멋있기도 했고 스스로 반성도 하게 되었다.

물론 그렇다고 REST API를 사용하지 않기는 어려울 것이다. 내가 그정도 실력이 있거나, 그보다 좋은 것을 만들 능력이 있지 않는 한.. 하지만 제일 중요한 것은 늘 당연하게 여기지 않고, 의문을 가지는 태도 일 것이다. 그래야만 더욱 발전이 있고, 기존보다 더 나은 것들이 탄생하기 때문이다.
그렇기에 말미에 말씀하신 "계속 생각합시다." 라는 말이 굉장히 와닿았고 공감되었다.

마침 최근에 클린 코드 책을 스터디에서 읽고 있었는데, 세션 중에서 이와 관련한 내용이 나왔다. 주석을 지양하는 것이 옳은 것일까?에 대해서 말이다.

주석을 적지 않고도 이해가 될 만큼의 좋은 코드를 만들려고 노력하는 것은 분명 좋은 자세일 것이다. 하지만 이 또한 분명히 한계는 있을 것이라고 생각한다. 모든 상황, 맥락을 코드에 녹여내기란 사실상 불가능하고, 시간이라는 자원도 한정적이기 때문이다. 그렇기에 나도 책을 읽으며 현실과는 조금 동떨어진 부분 이라고 느끼기도 했었다.

It depends. 결국 모든 것은 상황에 따라 다르다.

🎙️ 세션 3 : Platform Engineering의 함정

소개

부제 : 'Magic Button'이 주는 장밋빛 환상을 벗어나려면?
연사 : 안지완님(AUSG 8기, 몰로코 Software Engineer)

Platform Engineering이란?

“You Build it, You Run it. With our tools.”
개발자는 비즈니스 로직에만 집중
소프트웨어는 Magic Button을 통해 Seamless하게 운영환경에 배포
- 심지어 Reliability를 유지한 채로!
True DevOps를 실현하는 길, 플랫폼 엔지니어링을 왜 도입하기가 어려울까?

DevOps 문화가 전파되는 과정

노하우가 쌓이며 → 목적지에 최대한 빠르게 다다를 수 있는 최적의 루트가 생성
일종의 “Golden Path를 모두가 함께 참여하여 형성하는 문화”
- 이미 형성된 Golden Path를 Seamless & Reliability 하게 유지하는 것

Platform Engineering의 실패 요인

플랫폼 엔지니어링의 장밋빛 환상
- 골든 패스를 확립하지 않은 채 → “좋은 도구, 오픈 소스, Best Practice에 매진한다”
DX를 높이는 것이 플랫폼 엔지니어링의 궁극적인 방향성
- 플랫폼의 주 고객은 개발자이다

Platform Engineering의 성공 사례

HCA Healthcare

팀 구성
1. Operation Team
  
  → 애플리케이션을 위한 Operation을 Best Practice대로 수행하며 → Golden Path를 형성
2. Engagement Team
  
  → 개발자의 요구사항을 알맞은 Operation Team에 전달
3. Platform Engineering Team
  
  → 형성된 Golden Path를 Inteface화
운영에 필요한 대부분의 요소를 일반화함
- 리소스를 레이어화
- 스펙을 템플릿화

Platform 개발은 길어야 한 달, Golden Path 형성에는 1년 이상이 걸림

숲에서 길을 만드는 것이 가장 어려움.
이미 만들어진 길을 포장하는 것은 쉬움.

멋들어진 UI와 기술이 아닌, DevOps 문화를 먼저 적극적으로 전파하자!

🧑🏻‍💻 마지막 세 번째 세션은 플랫폼 엔지니어링의 환상과 실패 요인, 그리고 성공 사례에 대해서 소개해주셨다.

플랫폼 엔지니어링을 하는 목적은, 목적지에 도달하는 최적의 루트, 즉 Golden Path를 만들기 위함이다. 그렇기 위해서는 그 이전에 무수히 많은 실패와 도전, 그리고 설계에 대한 깊은 고민이 필요할 것이다. 하지만 이러한 부분에 대한 충분한 논의와 합의가 없는 채로, 좋은 도구로 해결하려는 경향이 있기 때문에 플랫폼 엔지니어링이 성공하기 쉽지 않다고 한다.

HCA Healthcare의 Platform Engineering의 성공 사례를 보면, 각 팀이 유기적으로 움직이며 각자의 역할을 제대로 수행하고 있다. 또한, 개발은 길어야 한 달이었고, 골든 패스 형성에는 1년 이상이 걸렸다고 한다.

숲에서 길을 만드는 것이 가장 어려운 것처럼, 처음에 문제를 정의하고 설계를 제대로 하는 것이 가장 어려운 일인 것 같다. 하지만 생각을 최대한 많이 하며 설계에 많은 시간을 쏟을 수록, 이후에는 일이 더욱 편해짐을 자주 느꼈었다.

설계가 얼마나 중요한 요소인지, 구현은 이에 비하면 큰 요소가 아니라는 것을 다시 한 번 느끼게 된 세션이었다.

🎬 마무리

AUSG에서 진행하는 행사에 가본 것은 처음이었는데, 기대 이상의 퀄리티와 좋은 세션들을 들으며 오랜만에 스스로 생각을 해 볼 수 있었다! 이후에는 뒷풀이도 참여해서 새로운 사람들과 네트워킹도 하며 즐거운 시간을 보냈다.

세션에서 느낀 점을 정리하자면, "항상 생각하자." 와 "설계가 가장 중요하다." 일 것 같다.
이번에 느낀 점을 잊지 않고, 앞으로 더욱 좋은 개발자가 되기 위한 양분으로 삼으려고 한다.

진행하시고 발표하신 AUSG 분들 고생하셨다고 말해드리고 싶고, 앞으로도 행사가 있다면 더욱 관심을 가져봐야겠다 🙃

Sangho Han

안녕하세요. 비즈니스를 이해하는 백엔드 개발자, 한상호입니다.

이전 포스트