GopherCon Korea 2024 Day 1 정리

이 포스트는 2024년에 진행된 GopherCon Korea 2024의 Day 1을 정리한다.

텍스트의 추출은 Voice2Text를 사용했으며, 내용 정리는 LLM의 도움을 받았다.

https://www.youtube.com/live/zdMuLvK0pNg?si=4m-Ox2pDcwikgGij

전체적인 진행 순서는 다음과 같다.

✅ 진행 순서 안내

변규현 – “고언어 프로젝트 가이드 A to Z”
백경준 – “고랭으로 4일 만에 이미지 서버 성능 72% 개선”
이오민 – “차량 업데이트 파일의 안전한 관리”
정겨울 – “디터미니스틱 테스팅”
최정민 – “Gin 프레임워크 모니터링 APM 만들기”
김정민 – “쿠버네티스 LMA 벤티스택 개발기 Part2”

🎤 변규현 (당근, 채팅 조직 리드)

주제: 고언어 프로젝트 가이드 A to Z

🧩 핵심 요약

1. 작은 프로젝트 vs 큰 프로젝트

작은 프로젝트는 빠른 릴리즈, 단순한 기능, 불확실성 있는 요구사항을 가진 MVP나 실험적인 서비스가 많음.
이런 프로젝트에선 과한 구조보다는 단순하고 빠르게 구현하는 것이 핵심.

2. 작은 프로젝트 개발 전략

CLI는 외부 라이브러리 없이 hello.go 같이 단순하게 시작.
API 서버도 기본 패키지로 작성하여 필요 최소한만 구성.
의존성이 적은 구조를 선호하며, 변경에 유연한 코드 설계를 강조.

3. 핸들러 패턴 비교

Handler Struct 방식: 복잡한 상태 관리에 좋음. 구조가 명확함.
Handler Func 방식: 간단하고 빠르게 구현 가능. 의존성 주입이 쉬움, 함수형 개발에 적합.

비교 항목	Handler Struct	Handler Func
구조 관리	명확함	유연함
테스트 용이성	보통	쉬움
확장성	좋음	제한적
사용 추천	복잡한 로직	단순한 로직

4. 코드 유지 보수 관점

의존성은 최소화하는 것이 좋고,
메서드별로 필요한 의존성만 주입하여 코드의 명료성과 테스트 용이성 확보.
기능 단위 분리와 코드 독립성을 강조.

5. 결론

무조건 복잡한 설계보다, **"단순함에서 시작해서 필요에 따라 확장"**하는 것이 중요.
고언어의 구조적 유연성과 명확한 의존성 모델은 이를 잘 지원함.
“핸들러 방식 vs 핸들러 펑크 방식”은 목적과 상황에 맞게 선택할 것.

🎤 백경준 (백패커 / 데브옵스 & 데이터 엔지니어)

주제: 고랭으로 4일 만에 이미지 서버 성능 72% 개선한 이야기

🧠 발표 요약

1. 문제 배경

기존 이미지 서버는 PHP 기반, CDN 캐시 만료 시 리사이즈 요청 폭주 → CPU 스로틀링, OOM 문제 발생.
오토스케일링도 제대로 동작 안 함. 리소스는 낭비되고 요청은 처리 못 하는 구조.

2. 개선 목표

성능 2배 이상 개선
다른 개발자 리소스 없이 본인의 리소스만으로 해결
유지보수 가능한 기술 스택 → Go + Gin 선택

3. 첫 번째 실패

nfnt/resize 사용 → PHP보다 성능 나쁨
CPU 사용률↑, 레이턴시↑, 메모리 효율 비슷
원인: nfnt/resize는 성능 최적화 X

4. 해결 방법

bimg (libvips 기반) 라이브러리로 교체
이후 성능 대폭 개선:
- 레이턴시 50% ↓
- CPU 사용량 절반
- 메모리 사용량 80% 절감

5. 부하 테스트 & 배포

Locust로 스루풋/응답시간 테스트
Istio 기반 Canary 배포 전략 → 실시간 트래픽으로 실험
장애 발생 시 빠른 롤백 가능

6. 기술 스택

프레임워크: Go + Gin
이미지 처리: bimg (libvips)
운영: Kubernetes + Istio, DataDog, Prometheus

7. 메시지

문제 정의 → 빠른 범위 설정 → 가벼운 솔루션으로 효과적 해결
Go는 실무에서 매우 유효한 선택지
(특히 빠르게 성능 개선이 필요한 시스템에서)

🔐 차량 OTA 업데이트 파일의 안전한 관리 (이오민, 42dot)

1. 발표 개요

주제: 차량용 소프트웨어 OTA 업데이트 파일의 보안 관리 및 이를 위한 Go 언어 활용 사례 소개.
목표: 기밀성, 무결성, 가용성(CIA)을 충족하는 OTA 업데이트 시스템 설계와 구현 방법을 공유.
대상: IoT/자동차 시스템, 보안, Go 기반 서버 개발에 관심 있는 개발자.

2. 42dot과 SDV 소개

회사: 42dot – 현대차 자회사로 자율주행 및 모빌리티 플랫폼 개발.
SDV(Software Defined Vehicle):
- 자동차 기능이 소프트웨어로 정의되는 시스템.
- 예: 테슬라 사이버트럭 핸들도 기계적 연결 없이 소프트웨어 제어.
OTA(Over-The-Air):
- SD카드 등을 통한 수동 업데이트의 단점 극복.
- 무선 네트워크를 통한 소프트웨어 자동 업데이트 방식.
- 보안 결함 수정, 리콜 비용 절감에 핵심적인 역할.

3. CIA 트라이어드: 보안의 3요소

요소	의미	차량 OTA 업데이트에 적용
Confidentiality (기밀성)	정보 접근 제어	업데이트 파일 암호화 (AES 등)
Integrity (무결성)	데이터 변조 방지	메타데이터 서명 및 검증
Availability (가용성)	시스템 지속 동작	앱 개발 통한 내부 테스트

4. 기밀성 – 파일 암호화 방식

🔒 대칭키 암호화 (AES)

사용 이유: 빠르고 대용량 처리에 적합.
구현 방식:
- crypto/aes, cipher 등 Go 기본 패키지 활용.
- io.Reader, io.Writer 사용 → 스트리밍 처리 가능, 메모리 절약.
실제 코드:
- 암호화된 파일은 .enc 확장자.
- 메모리 전체를 올리는 방식 대신 스트림 암호화 사용.

🔐 비대칭키와 Invelop Encryption

문제점: 비대칭키(RSA 등)는 속도 느림, 온디맨드 암호화 어려움.
해결책: 인벨롭 암호화
- 파일은 **대칭키(AES)**로 암호화.
- 대칭키는 클라이언트의 공개키로 한 번 더 암호화.
- 클라이언트(차량)는 자신의 개인키로 대칭키를 복호화 후 파일 복호화.
이점:
- 서버는 평문 데이터 노출 없음.
- 키 유출 위험 분산 및 관리 효율성 ↑

5. 무결성 – 메타데이터 검증

📦 TUF / Uptane 보안 프레임워크

항목	설명
TUF (The Update Framework)	소프트웨어 업데이트 보안 설계도
Uptane	TUF 기반 차량용 확장 버전 (CNCF 소속)

구성 요소:

- 이미지 저장소: 업데이트 바이너리 및 정적 메타데이터 저장.
- 디렉터 저장소: DB 기반 동적 메타데이터 생성.
검증 방식:
- 차량은 이미지 서버와 디렉터 서버 모두의 메타데이터를 비교.
- 하나라도 다르면 공격 감지 가능.
메타데이터 구조:
- 해시, 사이즈 등 포함된 target.yaml 파일로 관리.
- Go에서 YAML 처리도 서드파티 라이브러리로 손쉽게 구현.

6. 가용성 – 내부 앱 구축

실제 차량 OTA 클라이언트는 Rust로 작성.
그러나 사내 테스트 및 디버깅을 위해 Go로 된 앱 클라이언트 작성.
내부 앱 기능:
- 암호화 파일 다운로드
- 메타데이터 파싱 및 검증
- 키 체인 연동 확인

7. 구현 시 유의사항 및 팁

키 분리 설계: 파일마다 다른 데이터 키 사용 → 유출 피해 최소화.
키 저장소 분리:
- 암호화된 데이터키는 스토리지에 저장.
- 원본 키는 KMS (Key Management Service) 또는 클라우드 키 매니저에 보관.
자동차 공개키 전달:
- 클라이언트(차량)가 자신의 공개키를 서버에 전달 → 서버가 데이터 키를 암호화해서 응답.

8. 결론 및 교훈

보안은 개발의 후순위가 아니라 시작점이 되어야 함.
OTA 시스템의 신뢰성을 위해서는 암호화 + 메타데이터 검증 + 안전한 키 관리가 필수.
Go 언어는 다음의 이유로 시스템 구현에 매우 적합:
- crypto, io, yaml, 클라우드 SDK 등 내장 패키지 풍부.
- 간결하고 명확한 코드 스타일.
- 스트리밍 기반 처리에 용이.

9. 추가 리소스

CNCF Uptane 프레임워크: https://uptane.github.io
Go crypto 패키지 문서: https://pkg.go.dev/crypto
YAML in Go: https://github.com/go-yaml/yaml

✅ 디터미니스틱 테스팅: 테스트를 더 예측 가능하게 만드는 방법 (정겨울, 당근)

1. 발표 개요

주제: 테스트의 안정성과 신뢰성을 높이기 위한 디터미니스틱(Deterministic) 테스트 기법 소개.
목표: 테스트가 랜덤하게 실패하는 상황을 줄이고, 예측 가능한 테스트 코드를 작성하는 방법을 공유.
대상: Go뿐 아니라 테스트 품질에 관심 있는 모든 개발자.

2. 디터미니스틱 테스팅이란?

디터미니스틱(Deterministic): 실행할 때마다 결과가 동일한 테스트.
반대는 논디터미니스틱(Nondeterministic) → 간헐적으로 실패(Flaky Test).
테스트가 실패하는 이유:
- 랜덤값 사용
- time.Now() 같은 시간 의존성
- 네트워크 요청, 파일 시스템
- 고루틴 등 비동기 처리
- 맵 순회 순서 (비결정적)
- 외부 시스템 (서버, DB 등)

3. 왜 디터미니스틱해야 하는가?

Flaky Test의 문제점
- 신규 개발자가 코드를 신뢰하지 못함
- 실패한 테스트를 무시하거나 반복 실행
- 릴리즈 속도 및 품질 저하
- 예측 불가한 장애로 이어질 수 있음

4. 문제 상황과 해결 전략

(1) 랜덤값 문제

문제: ID 생성, 샘플링 등에서 랜덤을 사용 → 테스트 시 예측 불가.
해결:
- rand.New(rand.NewSource(seed))로 고정된 랜덤 인스턴스를 주입.
- Sampler 인터페이스를 정의해 AlwaysSampler, NeverSampler 같은 구현체로 테스트 유연성 확보.

(2) 시간 관련 문제

문제: time.Now()를 테스트 시점마다 호출 → 값 예측 어려움.
해결: 시간 생성 함수 (nowFunc()) 또는 Clock 인터페이스를 의존성 주입.

(3) UID / Nonce 생성

문제: UID는 매 실행마다 바뀜.
해결:
- 고정된 UID를 반환하는 제너레이터 주입.
- 테스트 전용 UID 제너레이터를 만들어 사용 (AtomicInt, FixedUIDFunc 등).

(4) 고루틴과 타이밍 문제

문제: 비동기 퍼블리셔, time.Sleep()으로 동기화.
해결:
- 고루틴 완료 신호를 채널로 대체.
- 채널에서 값을 읽고 동기화하는 구조 사용.

5. 테크닉 요약

문제 요소	해결 방법
랜덤 값	고정된 랜덤 인스턴스 주입 (rand.New)
시간 (time.Now())	시간 생성 함수 또는 인터페이스 주입
UID / Nonce 생성	고정값 반환 함수 또는 제너레이터 주입
고루틴 / Sleep	채널 동기화로 대체
맵 순회	슬라이스에 저장 후 sort → 순서 보장
JSON 인코딩	문자열 비교 대신 구조체 필드 값 비교

6. 부가 사례 및 고려사항

몽키 패칭은 비추천: 고에서는 지원이 미비하거나 불안정.
인터페이스 설계 장점:
- 테스트 목적에 맞는 구성요소를 주입 가능.
- Mock 객체 없이 명확한 역할 기반 테스트 가능.

7. 결론 및 교훈

결론: 테스트의 예측 가능성과 재현성을 높이기 위해 디터미니스틱하게 작성하라.
핵심 팁 요약:
- 비결정적 요소를 식별하고, 외부로부터 주입받는 구조로 리팩토링.
- 테스트는 결과를 예측 가능하게 만들어야 한다.
적용 대상: 특히 유닛 테스트 단계에서 효과가 크며, 통합 테스트와 E2E 테스트에도 부분 적용 가능.

8. 참고 자료

당근 개발 블로그: https://medium.com/daangn
개인 블로그, Twitter 등에서 Golang 관련 글 다수 작성 중

📊 Gin 프레임워크 기반 APM 모니터링 개발기 (최정민, 한화비전)

1. 발표 개요

주제: Go의 인기 웹 프레임워크인 Gin을 대상으로 한 APM(Application Performance Monitoring) 시스템 자체 개발기.
목표: 오픈소스 APM이 있음에도 직접 만들면서 배운 아키텍처와 구현 방식 공유.
대상: 웹 프레임워크 성능 모니터링, MSA 환경에서 추적/분석을 하고 싶은 개발자.

2. 발표 배경 및 동기

발표자는 DevOps 엔지니어로, 서비스가 잘 돌아가게 만드는 일에 집중.
기존에도 서버 모니터링 프로젝트를 수행했으나, 이번에는 더 직관적인 APM 개발에 도전.
Gin은 Go에서 가장 널리 사용되는 웹 프레임워크 → 모니터링 대상 1순위.
목표: 오픈소스 없이 순수 Go로 만든 경량 APM 시스템!

3. Gin 프레임워크란?

Go 언어의 고성능 웹 프레임워크.
장점:
- 사용자 수, GitHub 스타 수 기준 가장 인기 많음.
- 경량 + 미들웨어 지원 + 퍼포먼스 최적화에 집중.
최근 업그레이드에서 20% 성능 향상 발표.
실제 현업에서도 다양한 REST API, MSA 환경에서 폭넓게 사용됨.

4. 왜 APM 모니터링이 중요한가?

MSA 구조에서는 서비스 간 호출이 복잡하게 얽혀 있음.
하나의 지연이 어디서 발생했는지 식별이 어려움.
따라서:
- 매트릭(Metrics): 요청 횟수, 응답 시간 등 수치 정보
- 트레이싱(Tracing): 서비스 간 호출 흐름 추적
- (참고) **로그(Log)**는 회사별 규격이 다르므로 이번 발표에서는 제외

5. 매트릭 수집 구조

구성 요소

미들웨어: Gin의 요청 전/후 흐름에 개입 → 리퀘스트 타이밍 측정
공유 메모리 리소스: 수집된 매트릭을 저장
익스포터(Exporter): HTTP API(/metrics)로 매트릭을 외부에 제공

측정 항목

요청 경로 (Path)
상태 코드 (200, 400, 500 등)
요청 응답 시간 (Duration)

처리 흐름

요청 도착 → 미들웨어가 startTime 기록
요청 처리 → 핸들러 수행
응답 전 → duration 계산 + 상태 코드 수집
recordMetrics() 함수 호출 → 결과 저장

동시성 처리

여러 요청이 동시에 들어올 수 있으므로 mutex를 사용하여 데이터 보호

6. 트레이싱 수집 구조

트레이스 vs 스팬

Trace: 하나의 요청 흐름 전체 (예: A → B → C)
Span: 개별 서비스 또는 구간의 단위 작업

목표

Trace ID, Span ID, Parent Span ID를 요청 컨텍스트에 삽입
요청이 다른 서비스로 전파될 때도 트레이스 정보 유지

구현 방법

미들웨어 초기화:
- 요청 헤더에 트레이스 정보 없을 경우 생성
- 새 Trace ID, Span ID 생성 → context.Context에 삽입
로깅에 활용:
- 요청별 Trace 정보 포함 → 로그와 연계
다른 서비스로 전파:
- HTTP 요청을 날릴 때 RoundTripper 인터페이스를 활용
- 직접 구현한 커스텀 트랜스포트를 사용해 요청 헤더에 Trace 정보를 주입

7. 핵심 구현 포인트

기능	구현 방법
Gin 미들웨어	c.Next() 전후로 실행 시간 측정
요청 식별	Path + StatusCode 조합
매트릭 저장	map[string]MetricData + Mutex
트레이스 생성	UUID 생성기 or Atomic Integer
전파 (Outbound)	Custom http.RoundTripper 사용
상태 코드 수집	c.Writer.Status() 호출로 응답 상태 확인

8. APM 시스템 구조 요약

[Client]
   ↓
[Gin 미들웨어] ← Trace 생성 및 매트릭 측정
   ↓
[핸들러 함수] ← 실제 비즈니스 로직 처리
   ↓
[미들웨어 후처리] ← Duration 측정 완료, 상태 코드 파악
   ↓
[메모리 기록] → [익스포터] → /metrics 엔드포인트 제공

9. 실전 적용 팁

미들웨어는 핵심 로직 앞뒤에 꼭 개입해야 함
Trace 정보는 context.Context에 직접 삽입/추출 설계
전파 시 RoundTripper는 꼭 인터페이스 구현해서 교체
Mutex, atomic 등의 동시성 관리 필수
관측 데이터를 Prometheus 등 외부 툴과 연동도 고려 가능

10. 결론 및 교훈

핵심 메시지: APM은 선택이 아닌 필수, 직접 구현도 충분히 가능!
오픈소스 없이도 Go의 기본 기능만으로 APM 구성 가능
Gin + Middleware + Trace/Metric 관리 → 최소한의 구조로 효과적인 추적 실현
향후:
- 로그 연동, Prometheus 연계, Zipkin/OpenTelemetry 연계도 확장 가능

11. 참고 자료

Gin 공식 문서: https://gin-gonic.com/docs/
OpenTelemetry-Go: https://github.com/open-telemetry/opentelemetry-go
Go context 패턴 정리: https://blog.golang.org/context

☁️ 쿠버네티스 LMA 벤티 스택 개발기 (김정민, 삼성 SDS)

1. 발표 개요

주제: 쿠버네티스 기반 로깅/모니터링/알림(LMA) 시스템 “벤티 스택”의 개발 배경과 구조, 구현기.
목표: OSS 라이선스 문제로 자체 개발하게 된 로그 DB 및 비주얼라이저의 설계 과정을 공유.
대상: 쿠버네티스 운영자, DevOps, 관측성 도구에 관심 있는 Go 개발자.

2. 벤티 스택(Venty Stack) 소개

LMA: Logging, Monitoring, Alerting
벤티 스택 구성:
- 렛데(LETDE): 로그 수집 및 저장(DB)
- 벤티(Venty): 로그/메트릭 비주얼라이저
- Fluent Bit: 로그 수집기
- Prometheus: 메트릭 수집기
설치 방식: Helm Chart로 통합 설치 가능 (values.yaml 설정만으로 구성 가능)

3. 기존 시스템과 전환 배경

🔁 로그 시스템의 진화

시기	구성	문제점
2018	ElasticSearch + Kibana + Fluentd	메모리 과다 사용, 기동 느림, 라이선스 문제
2019	Open Distro for ES (Elastic OSS 버전)	안정성은 개선되었으나 제한적
2020	Grafana Loki 도입	경량화, 메트릭·로그 통합 조회 가능
2021~	자체 개발: 렛데 + 벤티	완전한 오픈소스 기반, 경량화, 사용성 향상

전환 이유:
- Elastic의 라이선스 변경 (X-Pack → SSPL/Elastic License)
- Grafana Loki의 라이선스도 변경됨 → AGPL 우려
- 지속 가능하고 자유로운 OSS 스택 필요

4. AGPL과 오픈소스 라이선스 고려

AGPL: 서버 소프트웨어도 소스코드 공개 요구 → 기업 입장에서 리스크.
벤티 스택: Apache 2.0 라이선스 사용 → 자유로운 사용 및 배포.
라이선스 검증 도구: golicense 사용, GitHub Actions에 연동.

5. 렛데(LETDE) – 경량 로그 DB

구조 개요

저장 방식: 플랫 파일
- 로그는 시간 단위로 파일화하여 저장
- 디렉터리 구조: /node/<node>/..., /pod/<namespace>/<pod>/...
읽기/쓰기 분리: 사이드카 구조
- LETDE Reader: 쿼리 처리 전담
- LETDE Writer: 로그 수집 및 저장 전담

주요 특징

경량화: Fluent Bit 사용 (메모리 사용량 1MB대)
시스템 의존성 없음: 단순 파일 기반 저장
LETDE QL:
- PromQL 기반의 로그 쿼리 언어
- 필터/정규식 연산자 제공 (|, !, =~, !~)
- 예: pod{namespace="foo", pod=~"nginx.*"} |~ "GET"

6. 벤티(Venty) – 로그/메트릭 통합 뷰어

역할: 메트릭 (Prometheus) + 로그 (렛데) 통합 UI 제공
특징:
- 한 곳에서 로그와 매트릭을 함께 조회 가능 (Loki의 장점 계승)
- 가볍고 빠름, 고유 쿼리 엔진 사용
구현 시 고려사항:
- 쿼리 실행 속도
- 리텐션 설정 (시간, 용량 단위)
- 사용자 정의 뷰 지원 예정

7. 개발 및 배포

MVP 개발 일정

총 4주 개발
- 렛데: 2주
- 벤티: 2주
Helm Chart 작성 후 오픈소스 배포
- GitHub: ko-oss/ventystack

Helm 설치 예시

helm repo add kooss https://ko-oss.github.io/helm-charts
helm install my-lma kooss/ventystack -f values.yaml

8. 기술적 구현 요소

로그 수집 파이프라인 (Fluent Bit)

로그 입력:
- Pod 로그: /var/log/containers
- Node 로그: journald 플러그인
가공/정제:
- 태그, 필드 정리
- 필터링 로직 삽입
출력:
- LETDE Writer로 전달 → 파일로 저장

Go 코드 구조 예시

Main 구조: main → app.Run() → config, router, rotator
핵심 모듈:
- config: 리텐션 설정, 경로
- router: HTTP 쿼리 엔드포인트
- rotator: 오래된 로그 정리

9. 명명 규칙 및 상징

컴포넌트	의미	상징
Prometheus	메트릭 수집	🔥 불 (불의 신)
렛데(LETDE)	로그 저장소	💧 물 (망각의 강)
벤티(Venty)	비주얼라이저	🌬️ 바람 (바람의 신)

명명 기준:
- 신화적 이름 사용
- 직관적인 알파벳 약자 (L: 로그, V: 비주얼라이저)
- 짧고 기억하기 쉬운 이름

10. 결론 및 교훈

OSS 라이선스는 선택이 아닌 필수 고려 사항
경량화된 로그 시스템도 충분히 자체 개발 가능
Go 언어는 시스템 구현에 매우 적합:
- 파일 기반 처리
- 고성능 HTTP 라우팅
- OSS 생태계 연동성

11. 추가 자료

벤티 스택 GitHub
golicense: https://github.com/google/go-licenses
Fluent Bit: https://fluentbit.io
Kubernetes 공식 LMA 구성: https://kubernetes.io/docs/concepts/cluster-administration/logging/

🚀 GopherCon Korea 2024 Day 1 총정리

📌 1. Go는 “단순함과 실용성”의 언어다

📍 대표 발표:

변규현 – Go 프로젝트 가이드 A to Z
정겨울 – 디터미니스틱 테스팅

Go는 더 이상 단순히 빠른 언어가 아니라, 작고 명확한 구조를 통해 빠르게 실용적인 서비스를 만들 수 있는 언어로 자리 잡고 있음.

불필요한 복잡도보다는 "작은 유니콘 만들기" 철학이 강조됨.
테스트, 프로젝트 설계, 아키텍처 선택 모두 “적절한 만큼”만 적용.
핸들러 vs 핸들러펑크 등 실용적인 선택지 제공.

✅ 시사점: "Go는 엔터프라이즈급 설계도 할 수 있지만, 본질은 빠른 실험과 명확성에 있음"

📌 2. 직접 만드는 모니터링/관측 도구의 부상

📍 대표 발표:

김정민 – 쿠버네티스 LMA 벤티 스택 개발기
최정민 – Gin 기반 APM 직접 구현기

기존의 APM/관측 툴(Elastic, Grafana 등)은 라이선스 제한 혹은 복잡도 증가로 인해 직접 구축하는 사례 증가.

오픈소스 도구에 대한 라이선스 회피 필요
Go의 성능과 간단한 구조를 활용해 LETDE (로그 DB), 벤티 (시각화 도구), APM 미들웨어 등을 자체 구현

✅ 시사점: "고성능+라이선스 자유로움 → Go로 나만의 운영툴을 만들 수 있는 시대"

📌 3. 성능 최적화는 추상보다 실험이다

📍 대표 발표:

백경준 – 이미지 서버 성능 72% 개선기
이오민 – 차량 OTA 암호화 및 무결성 검증 시스템

기존 시스템을 Go로 마이그레이션하며 단순히 “Go가 빠를 것”이라는 가설보단, 실측, 벤치마킹, 리소스 측정을 통한 개선 사례가 주를 이룸.

PHP보다 Go가 느렸던 케이스 → 이미지 리사이즈 라이브러리 교체로 극복
비즈니스 임팩트를 고려한 빠른 개선 범위 설정 → 카나리 배포, 가시적인 수치 개선 (74.7%)

✅ 시사점: "가설 → 실험 → 측정 → 반복의 정석적인 엔지니어링 마인드가 Go 생태계에서 매우 강조됨"

📌 4. Go에서의 설계는 목적 중심의 유연함이 핵심

📍 대표 발표:

변규현 – 서비스 규모별 설계 전략
이오민 – OTA 보안 구현 사례

Go로 대규모 서비스도 충분히 가능한데, 중요한 건 아키텍처를 '상황에 맞게' 설계하는 능력.

작은 기능 → 함수형 스타일, 간단한 패턴으로 빠르게
커지는 구조 → 도메인 주도 설계(Domain-Driven Design), 프레젠터-유즈케이스-도메인-레코더 분리
의존성 분리, 테스트 유연성 확보, 실제 운영에서 적용 가능한 레이어 기반 설계

✅ 시사점: "Go는 단순하되 얕지 않다 – 작을 땐 빠르게, 클 땐 구조적으로 대응 가능"

📌 5. Day 1 발표에서 공통적으로 나타난 가치

키워드	의미	등장 발표
작은 프로젝트의 효율성	빠른 개발, 빠른 배포, 작은 단위 설계	변규현, 백경준
직접 구현의 용기	APM, 로그 DB, 보안 등 시스템을 직접 Go로 개발	김정민, 최정민, 이오민
테스트와 품질	Flaky Test 제거, 의존성 분리, 레이어드 테스트 전략	정겨울, 변규현
정량적 지표 기반 개선	CPU, 메모리, 레이턴시 수치 기반 판단	백경준, 최정민

🧠 마무리 한 줄 요약

"Go는 단순하지만 강력하다 – 빠르게 만들고, 명확하게 나누고, 측정하면서 키운다."

2024년의 Go는 단순한 언어가 아니라, 모던 인프라와 운영, MSA, 성능 개선까지 아우르는 실전 개발 언어다.

저작자표시

'컨퍼런스 정리' 카테고리의 다른 글

GopherCon Korea 2023 정리 4편(최종) (0)	2025.03.18
GopherCon Korea 2023 정리 3편 (0)	2025.03.18
GopherCon Korea 2023 정리 2편 (0)	2025.03.18
GopherCon Korea 2023 정리 1편 (0)	2025.03.18

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`