이월엔 DevBloom 참여 후기

이번 달에는 컨퍼런스 참여를 쉬려고 했지만, 이월에 열리는 DevBloom 컨퍼런스에서 비개발자 직군을 위한 세션도 있다는 걸 본 동생이 함께 가자고 해서 참여하게 되었다. 처음엔 발표 목록을 보면서 크게 끌리는 세션이 없다고 생각했지만, 실제로 절반 이상을 재미있게 들을 수 있었다. 동생과 함께 가니 내가 듣지 못한 발표 중 궁금한 내용을 동생에게 물어볼 수 있어 유용했다.

 

<내가 들었던 세션들>

1. Rust 동시성 개념 정리
2. 앱에 AI로 생기를 띄워볼까요? (Semantic Kernel)
3. 멀티 에이전트의 구현 및 활용
4. 9명의 제품팀이 45명이 되기까지의 여정
5. Stack Overflow 25,000점까지 내가 얻은 것들

 

Introduction to Rust Concurrency - 옥찬호

Rust에서 동시성을 다루는 방법을 정리한 내용이다. Java에서 동시성을 깊이 있게 다뤄본 경험이 없어서 처음에는 이해하기 어려운 부분도 있었지만, 추후 Java에서 동시성을 다루는 법에 대해서 좀 더 깊게 공부해 보고 Rust의 동시성 개념을 비교해보면 더 재미있을 것 같다는 생각이 들었다. 동시성을 다루는 방법은 내가 생각한 것보다 많았고, 각각 다른 장단점을 가지고 있다는 것이 흥미로웠다. 이전에 나 역시 동시성 문제를 겪어 블로그에 포스팅한 적이 있었다. 이번 기회에 Java에서 동시성을 다루는 방법을 찾아보고 코드를 수정해 봐도 좋을 것 같다는 생각이 들었다.

Rust의 동시성 개념을 다루는 주요 방법으로 다음과 같은 방법을 소개해 주셨다.

1. Rust에서 스레드를 사용하는 방법 (1) - Fork & Join
   • Rust의 std::thread::spawn을 이용하여 여러 개의 스레드를 실행한 뒤, join()을 사용하여 스레드가 종료될 때까지 기다리는 방식
   • 데이터 레이스 방지: 같은 데이터를 여러 스레드에서 변경할 경우 컴파일러가 이를 탐지하여 에러를 발생시키기 때문에 동시성을 방지할 수 있다.
   • 일반적인 다른 언어(Java, C++ 등)에서는 자식 스레드에서 오류가 발생하면 전체 프로그램이 종료되거나 예외가 터미널에 출력될 수 있지만 Rust에서는 자식 스레드의 패닉이 메인 스레드로 전파되지 않는다 하였다.
2. Rust에서 스레드를 사용하는 방법 (2) - 채널 (Channel)
   • 채널은 하나의 스레드에서 다른 스레드로 데이터를 전달할 수 있도록 도와주는 스레드 세이프한 큐(Queue) (단방향 방식)
   • Unix 파이프(pipe)와 유사한 개념
   • std::sync::mpsc모듈을 사용해 구현하고 여러 개의 Sender가 하나의 Receiver로 데이터를 보낼 수 있는 구조다.
   • 반복문을 사용하여 여러 개의 데이터를 보낼 수도 있다.
   • 락을 사용하지 않는 방법이고 스레드 간 작업을 기능별로 분리할 수 있기에 Rust에서 많이 채택되는 방식이라고 하셨다.
3. Rust에서 스레드를 사용하는 방법 (3) - 뮤텍스 (Mutex)
   • 뮤텍스는 여러 개의 스레드가 동시에 공유 데이터를 변경하려고 할 때, 한 번에 하나의 스레드만 접근할 수 있도록 제어하는 것
   • std::sync::Mutex<T>를 이용해 구현하며, Mutex<T> 가 일종의 락이 된다.
   • C++에서는 데이터와 락이 별개의 객체라 실수로 락을 획득하지 않고 데이터를 변경할 위험이 있지 Rust에서는 뮤텍스가 데이터와 함께 저장된다.
4. 특정 조건이 필요할 때 - 조건 변수 (Condvar)
   • 특정 이벤트가 발생할 때까지 스레드를 대기시키는 동기화 메커니즘이다.
   • std::sync::Condvar을 사용해 구현 가능하다.
5. 원자적 연산 (Atomic Operations)
   • 락 없이도 여러 스레드가 안전하게 공유 데이터를 수정할 수 있는 방법이다.
   • std::sync::atomic 모듈을 사용하면 성능을 높일 수 있다.

각 방법에 대한 예제 코드는 아래 저장소로 추후 올려주신다 하셨다. https://github.com/utilForever?tab=repositories

소개한 방법 중 각각의 목적에 맞춰서 적절한 방식을 사용하는 것을 권장해 주셨다.

 

앱에 AI로 생기를 띄워볼까요? (나야~ Semantic Kernel) - 유저스틴 (마이크로소프트)

Microsoft에서 제공하는 Semantic Kernel에 대한 세션을 들었다. Semantic Kernel은 가벼운 오픈 소스 프로젝트로, 기존 애플리케이션과 AI 모델을 쉽게 연결할 수 있도록 도와주어 지능형 앱을 만들 수 있다는 것을 알려주셨고 실제로 Semantic Kernel을 활용한 예제들을 보여 주셨다.

Semantic Kernel의 주요 특징:

• .NET/Python/Java 지원
• 다양한 AI 모델 오케스트레이션 가능
• 플러그인 기반 확장 가능
• 기업용 앱 개발 친화적

특히 여러 개의 LLM(대형 언어 모델)을 동시에 사용할 수 있도록 지원하며, 각 모델에서 나오는 응답을 조합할 수도 있다. 또한, 프롬프트 플러그인과 네이티브 코드 플러그인을 통해 애플리케이션에 쉽게 AI 기능을 추가할 수 있다.

사실 잘 RAG나 에이전트 개념을 잘 몰라서 이해 안가는 부분이 많았지만, 멀티 에이전트 예시를 광고에 비유해 주신 부분은 재미있었다. 전반적으로 잘 모르는 분야라 이해가 쉽지 않았지만 AI가 빠르게 발전하고 있는만큼 나 역시도 이런 부분에 대해서 공부해 봐야 겠다는 생각이 들었다.

 

 

멀티 에이전트의 구현 및 활용 - 정유선 (신세계)

정유선 발표자님의 세션에서는 AI 에이전트의 개념과 활용 방안을 다루었다.

• 에이전트의 핵심 요소: 모델, 툴, 오케스트레이션
• Reasoning (논리적 사고) 와 Inference (결과 도출 과정)
• 멀티 에이전트 오케스트레이션

위와 같은 내용들을 다뤄 주셨다.

지금까지 단순히 AI를 사용하고 있다고만 생각했는데, 모델과 에이전트의 차이가 있다는 점을 새롭게 알게 되었다.

또한, AI가 ANI → AGI → ASI로 발전해 나간다는 설명도 흥미로웠다. AI의 성능이 단순히 점진적으로 향상되는 것이 아니라, 이러한 개념적 단계로 발전해 나간다는 점이 신기하게 느껴졌다.

 

 

9명의 제품팀이 45명이 되기까지의 여정 - 이동욱 (인프랩(인프런/랠릿))

인프랩(인프런/랠릿) 이동욱님은 스타트업의 성장 과정에서 겪은 조직 변화와 시행착오에 대해 공유해 주셨다. 초기에는 9명으로 운영되던 제품팀이 45명(현재는 47명)까지 확장되면서, 조직 구조 및 업무 방식에 대한 많은 변화를 극복해 온 과정에 대해서 발표해 주셨다.

이번 발표에서 가장 흥미로웠던 부분은 개발 조직이 제대로 갖춰지기 전, 채용이 원활하게 이루어지지 않자 인프랩이 선택한 독특한 채용 방식이었다. 함수형 프로그래밍 강의를 수강하고 수강평을 남긴 개발자들에게 직접 메시지를 보내 채용 제안을 했다는 점이 인상적이었다. 비슷한 사례로, 문피디아 역시 자사 서비스를 활용해 소설 형식으로 채용 공고를 작성했다고 한다. 발표에서는 특히 B2C 회사의 경우, 기존 고객이 서비스에 대해 긍정적인 인식을 가질 가능성이 높기 때문에 이러한 방식이 효과적일 수 있다고 설명했다. 이를 들으며, 기업이 채용을 단순히 구인 공고를 내는 것이 아니라, 자사 서비스와 자연스럽게 연결해 접근하는 방식이 상당히 창의적이고 재미있다는 생각이 들었다.

또한, 내가 다녔던 회사가 인프랩과 비슷한 규모였던 만큼, 발표에서 언급된 문제들이 익숙하게 다가왔다. 조직이 성장하면서 겪는 혼란과 갈등들이 그대로 겹쳐져서 공감이 많이 되었다. 특히, 회사가 위기에 처할 때마다 문제를 분석하고 해결책을 도출하는 방식이 인상적이었다. 이를 보면서, 나 역시 문제를 마주할 때 단순한 해결책만을 찾는 것이 아니라, 문제의 본질을 정확히 정의하고 다각도로 접근하는 것이 중요하다는 점을 다시금 깨닫게 되었다.

 

 

Stack Overflow 25,000점까지 내가 얻은 것들 - 김영재 (LINE)

영재님께서는 개발자의 다양한 외부 활동 중 커뮤니티, 그중에서도 stackoverflow에 참여하시면 성장한 경험을 공유해 주셨다.

stackoverflow는 사실 이전에 구글링하면서만 종종 들어간 사이트일 뿐, 그곳에서 활동한 적은 없었다. stackoverflow는 단순히 질문과 답을 하는 사이트라고 생각했는데 활동을 하면서 좋은 질문하는 법을 배울 수 있고 상대방을 이해시켜 주기 위해 좋은 대답을 하는 방법을 공부할 수 있다고 하셨다. 이렇게 좋은 질문하고 좋은 대답하는 방식이 곧 좋은 엔지니어가 되기 위한 훈련이 될 수 있다고 하셨다. 특히 중요한 언어로 지식을 정리하여 전달하고 팀의 노하우로 만들 줄 아는 능력을 기를 수 있다고 말씀 주셨고, 이게 곧 AI 시대에 최적화된 훈련이 될 수도 있었다.(AI에게 질좋은 답변을 뽑아낼 수 있는 능력을 기를 수 있다고 하셨다.) 실제로 같은 React에 관한 문제를 해결할 때 초급자이신 영재님께서 좀 더 좋은 질문으로 질문을 하였기에 더 좋은 답을 얻을 수 있었다고 하셨다.

또 지식을 가공하는 능력을 훈련하기 위해 사내 블로그 도입을 추천주셨다. 개인 블로그보다 사내 블로그가 좀 더 강요된 메타포이며, 실무 해결을 다루기 때문에 상대에게 도움이 될 수 있음을 더 강조할 수 있다고 하셨다.

지금까지 나는 좋은 답변에 대해서는 생각해 본 적이 많았지만, 좋은 질문은 고려해 보지 못한 적이 많았던 것 같다. 영재님 말씀처럼 위와같은 능력을 기르는 것은 좋은 동료가 되기 위해서도 노력해야 하는 부분인 것 같다.

 

마무리하며....

이번 DevBloom 컨퍼런스에서는 Rust의 동시성 개념부터 AI, 제품팀 운영까지 다양한 주제를 다룬 세션을 들으며 새로운 시각을 얻을 수 있었다. 특히, Stack Overflow 활동을 통한 성장 이야기는 개발자로서의 방향성을 다시 한번 생각해보게 만들었다. 그리고 단순히 발표를 듣는 것에서 끝나는 것이 아니라, 발표 내용을 내 경험과 연결을 고민해 보는 과정의 필요성을 느꼈다. 이를 위해 기술적 성장뿐만 아니라, 문제 해결력과 협업 능력, 지식을 정리하고 공유하는 능력을 키울 수 있게 노력해야 겠다.