기술이야기 | 브레인즈컴퍼니

메인 페이지로 이동
블로그
기술이야기

블로그

브레인저가 되면 누릴 수 있는 것들 ㅣ (4) 동호회 편

최순정 2023.01.27

브레인즈컴퍼니는 브레인저들이 일에만 묻혀 지내지 않고, 동료와 교류를 통해 일상에 활력을 불어넣을 수 있도록 사내 동호회를 운영하고 있습니다.

동호회 활동은 단순한 놀이에 그치지 않고, 자연스럽게 업무에도 적용되고 있는데요.

서로 다른 팀의 동호회원들은 끈끈한 동료애를 바탕으로, 협업 시 서로 배려하며 협동심을 발휘할 수 있습니다.

동호회는 업무와 별개인 것 같아 보이지만, 타 부서와의 소통을 통해 업무 생산성을 올릴 수 있는 수단이 되기도 합니다.

이를 통해 브레인저들은 더욱 행복한 회사 생활을 할 수 있겠죠?

브레인즈컴퍼니는 동호회 활동에 지원을 아끼지 않고 있습니다.

5인 이상이 모이면 누구든지 동호회를 만들 수 있고, 사측에서는 달마다 인당 활동비를 지원하고 있는데요.

(선근님이 본인 지갑을 열 때도 있다는 소문이...

)

브레인즈컴퍼니의 동호회 활동을 살펴볼까요?

첫 번째로, 보드게임 동호회 '하드보드지'

"열심히 보드게임 하지"라는 뜻의 하드보드지는 2016년 12월에 인프라코어팀 용관님의 제안으로 만들어진 동호회입니다.

현재 동호회 회장은 인프라코어팀 동조님이, 총무는 용관님이 맡고 있습니다.

하드보드지의 멤버는 총 13명으로, 인프라코어팀을 비롯해

TC팀, 프리세일즈팀, 영업그룹, 경영기획실 등 다양한 부서와 직급으로 구성돼있습니다.

하드보드지는 보통 한 달에 2~3회 정도 모여 게임을 즐긴다고 하는데요.

플레이타임이 20~30분 정도일 땐 점심 시간을, 30분 이상인 게임을 할 땐 퇴근 이후 시간을 활용한다고 해요.

점심 시간에는 여러 명이 간단하게 즐길 수 있는

텔레스트레이션, 디렉사우, 다크호스, 애비뉴, 사보타지, 스시고파티, 텀블링 다이스 등의 파티게임 위주로 하고,

저녁 시간대는 여유롭다 보니 파티게임뿐만 아니라

데드오브윈터, 모노폴리, 클루, 티켓투라이드, 카르카손, 뱅, 돌팔이약장수 등의 게이머스한 보드게임을 즐긴다고 하네요.

총무 용관님은 보드게임의 매력에 대해

"게임을 보기만 하지 않고 직접 만지고 굴려가며, 같이 플레이하는 사람들과 대화를 하면서 즐길 수 있어요.

또 남녀노소 모두 함께 즐길 수 있다는 것이 큰 장점입니다"라고 전해왔습니다.

필자도 올 1월에 하드보드지에 가입했는데요. 퇴근 후 동료들과 함께 게임을 즐기다 보면, 어느새 스트레스가 해소되는게 느껴졌습니다.

또, 평소 얼굴만 알고 지내던 동료들과 좀 더 친해질 수 있는 계기가 되기도 했고, 끈끈한 동료애가 생기는 것 같아 좋았습니다.

특히, 이번에 가입하면서 생각치도 못했던 보드게임을 선물 받아 설 연휴 때 가족들과 함께 게임을 즐겼습니다. 다음 게임이 또 기다려집니다! :)

두 번째로, 일상에 활력을 불어 넣어 준다는 '풋살 동호회'

풋살 동호회는 2018년 전략사업본부 회식 때 이야기가 나와 만들어 졌다는데요.

주로 TC팀과 영업팀 위주로 구성됐고, 회장 정대님의 운영 하에 13명의 멤버가 활동하고 있다고 합니다.

경기는 월 1회 정도, 주로 목요일 저녁 7시에 진행하고 있습니다.

정대님은 풋살의 매력에 대해

"직장 생황을 하며 운동을 하기가 참 쉽지 않습니다. 더욱이 혼자라면 엄두가 안 나죠.

브레인즈의 풋살 동호회는 한 달에 한 번 정도 부담가지 않는 선에서, 중고등학교 시절처럼 공 하나 놓고 즐기는 분위기로 운영되고 있어요.

그래서 꼭 운동 목적이 아니더라도 일상에 활력이 필요한 분들에게 적극 권유드려요"라고 전해왔습니다.

다들 체력이 좋지 않아, 10분 경기하고 20분 간 경기장에 드러누워 있었던 적도 있다고 하네요.

이처럼 풋살 동호회는 건강 뿐만 아니라 소통과 친목을 위해 진행되고 있으니 실력과 체력에 자신이 없는 분들도 자유롭게 참여할 수 있다고 해요.

풋살 경험이 없어 망설이고 있다면, 일단 가입하시고 가장 풋살을 잘하고 득점을 많이 한 멤버인 TC팀 기열님에게 배워봐도 좋을 것 같아요!

이처럼 브레인저들은 동호회 활동을 통해 행복한 회사 생활을 하고 있습니다.

이 글을 읽고 있는 예비 브레인저 분들!

브레인즈컴퍼니에 합류하게 된다면, 동호회에 가입하고 끈끈한 동료애를 쌓아가시길 바랍니다!

최순정경영기획실(PR매니저)

브레인즈컴퍼니의 소식, 조직문화, 브레인저 이야기를 대내외에 전파하고 있습니다.

필진 글 더보기

추천 콘텐츠

eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링 eBPF로 구현하는 TCP 상태 추적 기반 네트워크 모니터링 예전에는 네트워크 성능을 모니터링할 때 tcpdump로 패킷을 캡처하거나, netstat으로 연결 상태를 확인하거나, NetFlow/sFlow 기반 분석을 많이 사용했습니다. 하지만 네트워크 환경이 복잡해지고 암호화 트래픽이 늘어나면서, 그리고 컨테이너·MSA 환경으로 서비스가 쪼개지면서 기존 방식의 패킷 기반 모니터링은 점점 한계를 드러냈습니다. 성능 부하는 커지고, 세부 가시성은 부족했습니다. 이 문제를 해결해 준 게 바로 eBPF(extended Berkeley Packet Filter)입니다. eBPF는 커널 내부 함수에 직접 훅(Hook)을 걸어서 데이터를 가져올 수 있기 때문에, 서비스에 큰 영향을 주지 않고도 운영 환경에서 실시간 성능 분석이 가능합니다. 쉽게 말해, 예전에는 netstat으로 “포트가 지금 어떤 상태인지”만 볼 수 있었다면, eBPF를 쓰면 “그 포트의 상태가 어떻게 변하고 있는지”까지 관찰할 수 있습니다. 그래서 최근 클라우드 네이티브 환경이나 초저지연 서비스 운영에서는 eBPF가 차세대 네트워크 모니터링 기술로 주목받고 있습니다. eBPF란? eBPF는 커널 안에서 안전하게 실행되는 작은 프로그램으로, 네트워크·시스템 동작을 실시간으로 추적하는 데 강점을 가집니다. 네트워크 모니터링 관점에서 자주 쓰이는 기능은 다음과 같습니다. • kprobe/kretprobe: 커널 함수 진입·종료 시점 후킹 • tracepoint: 커널 이벤트 발생 시점 후킹 • BPF Map: 커널과 사용자 공간 간 데이터 공유 • BPF Helper 함수: 커널 리소스 접근 API eBPF는 Verifier(검증기)가 프로그램의 안전성을 보장하지 못하면 로드를 거부합니다. 과거에는 Verifier가 루프의 종료를 판별하지 못해 루프 사용이 전혀 허용되지 않았지만, 최근에는 단순 반복문은 사용할 수 있게 되었습니다. 또한 BTF(BPF Type Format)와 CO-RE(Compile Once – Run Everywhere) 기술 덕분에, 커널 버전이 달라져도 동일한 eBPF 프로그램을 별도 빌드 과정 없이 그대로 운용할 수 있습니다. eBPF 사용 방법 제가 공부하면서 가장 흥미로웠던 예제는 BCC 툴셋에 포함된 **tcpstates**입니다. TCP 연결 상태 변화를 추적하는 예제인데, 구조를 간단히 정리하면 다음과 같습니다. • bpf.c: 커널에서 실행되는 함수 중 “어떤 걸 관찰할지”와 “관찰 시 어떤 데이터를 수집할지” 정의 • .h: 커널과 유저 공간이 공유하는 데이터 구조체 정의 • .c: 수집된 데이터를 가공해서 사용자에게 출력 예를 들어, tcpstates.bpf.c에서는 커널 tracepoint inet_sock_set_state를 후킹해서 TCP 상태 변화를 잡아냅니다. 아래 코드를 보면 이해가 쉬우실 겁니다. int handle_set_state(struct trace_event_raw_inet_sock_set_state *ctx) { struct sock *sk = (struct sock *)ctx->skaddr; __u16 family = ctx->family; __u16 sport = ctx->sport; __u16 dport = ctx->dport; __u64 *tsp, delta_us, ts; struct tcpstates_t tcpstates = {}; if (ctx->protocol != IPPROTO_TCP) return 0; ts = bpf_ktime_get_ns(); tcpstates.skaddr = (__u64)sk; tcpstates.ts_us = ts / 1000; tcpstates.pid = bpf_get_current_pid_tgid() >> 32; tcpstates.oldstate = ctx->oldstate; tcpstates.newstate = ctx->newstate; tcpstates.family = family; tcpstates.sport = sport; tcpstates.dport = dport; bpf_get_current_comm(&tcpstates.task, sizeof(tcpstates.task)); if (family == AF_INET) { bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_rcv_saddr); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_daddr); } else { /* family == AF_INET6 */ bpf_probe_read_kernel(&tcpstates.saddr, sizeof(tcpstates.saddr), &sk->__sk_common.skc_v6_rcv_saddr.in6_u.u6_addr32); bpf_probe_read_kernel(&tcpstates.daddr, sizeof(tcpstates.daddr), &sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32); } // 상태가 변경되면 유저 공간에 알리는 부분 bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU, &tcpstates, sizeof(tcpstates)); return 0; } 핵심 로직은 단순합니다. 커널에서 inet_sock_set_state가 호출되면 handle_set_state 함수가 실행되고, 이때 변경된 TCP 상태를 잡아내 사용자 공간으로 전달합니다. 언뜻 보면 복잡해 보일 수 있지만, 사실 bpf.c의 역할은 데이터를 가공하는 것이 아니라 수집하는 것입니다. 결국 중요한 것은 “내가 원하는 값이 구조체의 어디에 들어 있는지”를 정확히 찾아내는 일입니다. 그 값을 Map에 담아 사용자 공간으로 넘기면 됩니다. netstat으로 보이는 출력은 아래와 같죠. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 192.168.0.10:22 192.168.0.55:54321 ESTABLISHED 2048/sshd: user@pts/0 netstat은 사용자가 명령어를 실행한 시점의 상태만 스냅샷 형태로 보여줍니다. 그래서 LISTEN, ESTABLISHED, CLOSE_WAIT처럼 비교적 오래 유지되는 상태만 주로 확인할 수 있습니다. 반면 tcpstates를 활용하면 커널 내부에서 발생하는 모든 TCP 상태 변화를 이벤트 단위로 추적할 수 있습니다. 덕분에 기존 툴로는 관찰하기 어려웠던 3-way handshake와 4-way handshake 과정까지 실제로 확인할 수 있다는 점이 흥미로웠습니다. 조금 더 실무적으로 활용하자면, CLOSE_WAIT이 비정상적으로 쌓이는 경우 커넥션 누수를 빠르게 탐지할 수 있고, TIME_WAIT이나 FIN_WAIT2 패턴을 분석하면 리소스 사용량 문제를 조기에 파악할 수 있습니다. 관측용 예제지만, 확장하면 운영 환경에서도 충분히 유용한 진단 도구가 될 수 있습니다 다음으로 유저 공간의 tcpstates.c는 커널 eBPF 프로그램이 보낸 이벤트를 받아서 보기 좋게 출력하는 역할을 합니다. 흐름은 단순합니다. ①eBPF 오브젝트 열기 (tcpstates_bpf__open()) ②프로그램 커널 로드 (tcpstates_bpf__load()) ③훅 부착 (tcpstates_bpf__attach()) ④필요 시 cgroup 필터 등록 (open(), bpf_map_update_elem()) ⑤주기적으로 Map을 읽거나 이벤트를 받아 상태 출력 현재는 TCP 상태 변경 이벤트가 발생할 때마다 화면에 출력하는 방식으로 동작하지만, 필요하다면 일정 주기마다 netstat을 호출하듯이 현재 상태를 스냅샷 형태로 출력하도록 구현할 수도 있습니다. 마무리하며 이처럼 간단한 코드만으로도 tcpdump나 netstat보다 훨씬 세밀하게 네트워크 흐름을 분석하는 프로그램을 만들 수 있습니다. tcpstates 같은 예제는 단순하지만, eBPF의 장점을 잘 보여줍니다. • 저부하 eBPF는 패킷 전체를 캡처하지 않고, 연결 상태나 세션 정보 같은 핵심 메타데이터만 선택적으로 수집합니다. 이로 인해 CPU와 메모리 사용 부담이 최소화되며, 운영 중인 서비스에 성능 저하를 거의 일으키지 않습니다. 즉, 실서비스 환경에서도 안정적으로 적용 가능한 경량 모니터링 방식입니다. • 높은 가시성 단순히 IP와 포트 수준의 정보만 보여주는 데 그치지 않고, 프로세스명·PID·서비스 단위까지 트래픽을 구분할 수 있습니다. 이를 통해 “어떤 서비스가 얼마만큼의 네트워크 자원을 소비하는지”를 즉시 파악할 수 있으며, 서비스별 자원 사용 현황을 보다 세밀하게 모니터링할 수 있습니다. • 확장성 기본적인 송·수신량 분석을 넘어, RTT(왕복 지연시간), 재전송률, 패킷 드롭률 등 다양한 지표를 손쉽게 확장할 수 있습니다. 필요한 메트릭을 커널 훅(Hook)에 연결해 Map에 저장하기만 하면, 곧바로 시각화와 분석에 활용할 수 있습니다. 이 덕분에 환경 변화나 분석 요구에도 유연하게 대응 가능한 구조를 제공합니다. 브레인즈컴퍼니 역시 이 기술을 Zenius NPM(Network Performance Monitoring)에 적용하면서 기존 방식으로는 확인하기 어려웠던 세밀한 성능 데이터를 확보할 수 있었습니다. 이를 통해 단순한 모니터링을 넘어 서비스 간 통신 병목을 실시간으로 파악하고, 장애 분석 시간을 크게 줄일 수 있는 솔루션을 완성할 수 있었던 점이 큰 성과였습니다. 앞으로도 이러한 경험을 바탕으로 eBPF 활용을 더 넓혀가고자 합니다. 2025.09.18