2025 GDG 인천 devfest 후기

subtitle

AI와 개발자의 미래

세션 2. Upstage: 작은 팀에서 AI로 생존하는 방법

AI로 디버깅하기

문서 처리 파이프라인

Document AI Controller 컴포넌트는 다음 역할을 수행한다.

•

문서 파일의 전처리 수행

•

파일 종류별로 적합한 AI 모델로 라우팅

•

전체 파이프라인의 안정성 관리

해당 컨트롤러는 Go로 구현되어 있었고, 내부적으로 C 기반 문서 처리 라이브러리를 호출하고 있었다. 이 구조는 성능 면에서 유리하지만, 동시에 고질적인 C 라이브러리 기반 불안정성에 컨트롤러가 영향을 그대로 받는 구조이기도 했다.

Segmentation Fault: 단일 오류가 전체 서비스 장애로 번지다

첫 번째 문제는 다음과 같이 시작되었다.

문서 처리 과정에서 segmentation fault가 발생했다. 이 오류가 Document Parse 내부에서만 발생한 것이 아니라, 전체 서비스 프로세스를 죽이는 치명적인 형태로 확장되었다. 결국 문서 처리 모듈이 전체 서비스를 오염시키지 않도록 업스테이지는 아예 docmate라는 별도 컴포넌트로 분리하기로 했다.

3. 하루 만 건의 docMate 에러

다음 문제는 에러의 규모였다. 하루 만 건 이상의 에러가 발생했고, 로그만으로는 원인을 특정할 수 없었다.

문제는 이렇다. 내부에서 사용하는 오픈소스 문서 처리 엔진에서 에러가 발생하고 있었다. Go 코드만으로는 원인을 명확히 파악할 수 없었고 결국 C 라이브러리와 Go wrapper 소스까지 모두 내려가서 분석해야 했다.

그러나 현실적으로는 모든 코드를 완전히 파악하기 어려웠고, 실제로 한 개발자가 하루 안에 들여다보기에는 난도가 높았다.

그래서 결국에는 재현 가능한 에러 데이터를 기준으로 엣지 케이스를 직접 대응했다고 한다.

4. 단건일 때는 정상, 동시 요청에서만 segment error가 나는 문제

특정 PDF는 단건 요청 시 아무 문제 없이 처리된다. 그러나 동일 파일을 여러 요청에서 동시에 보내면 segmentation fault가 발생한다. 이 현상을 분석하기 위해 사용된 도구는 Cursor였다.

패턴은 이렇게 진행되었다.

에러를 일으키는 PDF, 정상 PDF, 서비스 코드, 문서 처리 라이브러리, C library 전체를 로컬에 클론

Cursor 컨텍스트에 모두 넣어서 관련 코드 흐름을 집중적으로 확인

동시성 상황에서 어떤 경로에서 메모리 접근이 충돌하는지 추적

여기서 드러난 근본 원인은 다음과 같다.

•

C 엔진은 원래 외부에서 lock을 전달받아 thread-safe하게 동작하도록 설계되어 있었다.

•

그러나 이 C 엔진을 사용하는 Go 라이브러리가 이 lock을 주입하지 않고 있었다.

•

그 결과 동시 접근 시 메모리 충돌이 발생했다.

정리하면, Go에서 concurrency-safe라고 믿었던 부분이 실제로는 C 단계에서 잠겨 있지 않아 발생한 classic race condition 문제였다.

또 다른 사례: PDF 뷰어에서는 열리는데 추론은 실패하는 파일

또 다른 흥미로운 문제도 있다. PDF 뷰어에서는 아무 문제 없이 열리는 파일이 inference API를 호출하면 415 unsupported error를 반환하는 문제였다.

해결 방식은 우리가 평소에 AI로 디버깅하는 방식과 다를 것 없이 평범했다. 실패하는 PDF와 정상 PDF를 비교군으로 삼고 문서 처리 로직의 일부와 함께 전체 컨텍스트를 AI에게 제공했다. AI가 두 파일을 비교하며 문제 지점을 찾도록 시도했다. 시도는 평범했지만 결과는 매우 효율적이었다. 개발자가 파악하기 힘든 원인을 AI는 한번에 찾았다고 한다.

문제 원인은 ‘실패하는 PDF는 파일 끝(eof) 마커 바깥에 예상하지 못한 값이 포함되어 있었다’는 것이었다. 이 방식은 중요한 시사점을 준다. AI가 문제 원인 분석을 직접 수행하도록 만들면 개발자가 파일 구조까지 전부 파헤치지 않아도 된다.

이 사례를 보면서, ‘디버깅 파이프라인’을 만들어서 문제가 생기는 PDF 파일을 파이프라인으로 보내서 AI가 문제 원인을 분석하게 하면 어떨까? 라는 아이디어를 떠올렸다.

바이브 코딩으로 엔터프라이즈 포털 개발한 사례

업스테이지가 온프레미스 사업하면서 겪었던 문제

업스테이지에서는 모델, 서빙 엔진, 어플리케이션 등 50+ 종의 서비스 컴포넌트가 있었는데, 모델팀, 플랫폼 개발 팀, 앱 개발 팀 각각 제품을 전달하는 방식이 달랐다. 고객사별로 나가야할 제품을 패키징하고 설치하는 과정이 너무 번거로웠다. 오픈소스 같은 경우 어떤 버전이 딜리버리 되었는지 버전을 기록해두는 곳도 없었다. 카탈로그들을 usb, 구글 드라이브, s3 등 일원화되지 않은 채널 통해 고객사나 파트너사에 딜리버리했고, 표준화된 설치 매뉴얼도 없었다.

솔루션 패키징 과정

•

document parse에 필요한 모델들, 라이브러리들 리스트 업하고

•

노션에서 document parse에 필요한 모델들의 경로 확인 후 NAS에서 아티팩트들을 압축해서 준비

•

깃헙 레포에 올라가있는 dockerfile로 docai-viewer를 직접 빌드해서 도커 이미지를 챙김

•

주먹 구구식으로 진행되던 패키징

그래서 나온 것이 카탈로그 서비스와 엔터프라이즈 포탈

•

고객사별 패키지 버전관리

•

누가 무엇을 올리고 다운로드 받았는지 audit 로그 확인 가능

•

표준화된 매뉴얼 관리

솔루션 관련 질문이 들어와서 이것도 AI가 대응할 수 있도록 함 → 회사 내부의 AI 스페이스 사용

•

AI 스페이스에 문서를 업로드해서 데이터를 쌓고

•

문서에 대한 질의 응답 가능

•

share 기능으로 url에 모두 접근해서 질의 가능

엔터프라이즈 포탈이 도입된 후로는

•

클릭 몇번으로 필요한 카탈로그(데브옵스 분들이 만들어주신)를 패키징한 것을 다운 받을 수 있다.

•

파트너사에게 이관도 가능해짐. 엔터프라이즈 포탈에서 다운 받음

•

어떤 카탈로그가 어느 파트너사 고객사에 나갔는지 필터 검색이 용이하여 관리가 수월해짐.

결론

•

AI를 생산성 툴로 이용한 것에 그치지 않고, AI로 생산성을 높이는 툴을 만드는 것도 가능하다!

•

대체되는 사람이 아니라, 확장되는 개발자가 되자.

팁

•

기획서 작성 대신 cursor로 UI 뼈대 먼저 만들어보기

•

AI의 도움을 받아 역할 구분 없이 작은 것 하나라도 넘나들기 (기획자도 코드 조금, 개발자도 디자인 조금)

•

AI에게 위임할 수 있는 일 찾아보고 위임하기

◦

PR 리뷰, 로그 분석, 문서 정리, 간단한 툴 개발 

GDG devfest를 통해 느낀 점: AI와 개발자의 미래

예전에도 개발자 행사를 많이 참여했지만 이번 GDG devfest를 통해 느낀 것은, 개발자들이 예전에는 기술 자체에 대한 인사이트나 경험담에 대해 많이 공유했다면, 이번에는 AI를 활용하는 방법과 경험, 어떤 모델들이 좋고, AI가 개발자를 대체하게 될지 등 AI와 관련된 주제가 많았다는 것이다. 기술 자체에 대한 것보다는 AI를 어떻게 활용할 것인가에 대한 현 개발자들의 관심사가 반영된 것 같다.

AI를 통한 바이브코딩이 유행하면서 개발자, 비개발자 할 것 없이 ‘AI가 개발자를 대체하는 것 아니냐’는 우려가 많이 나오고 있는데, 요즘 AI가 없으면 생산성 자체가 매우 떨어지기 때문에 이런 우려가 나오는 것이 당연하다는 생각도 든다.

하지만 우아한 형제들 개발자의 ‘AI 원시인의 바이브 코딩 경험기’에 따르면, 비개발자들도 충분히 코딩이 가능해졌지만 개발자들이 AI를 활용하는 것만큼의 효율성이나 안정성이 나오지 않을 것이다라는 생각이 들었다.

개발 환경을 세팅하는 것부터, 비개발자들은 수많은 관문을 만나게 된다. 또한, 프롬프팅할 때도 개발자 용어를 써서 구체적으로 명령을 내리면 AI가 더 작업을 잘 처리하게 된다.

하지만 비개발자가 이런 관문을 뚫고 첫 MVP를 만들었다 하더라도, 그 이후에 서비스를 고도화하는 과정에서 또 한번의 문제를 겪게 된다. AI가 한 문제를 해결하면 다른 문제가 터지는 풍선 효과가 나타나기도 하고, AI가 해결하지 못하는 문제를 만나면 더 이상 어찌할 줄 모르는 상태가 되는 것이다.

며칠 전 전 회사 팀장님을 만나서 바이브 코딩에 대해 얘기해봤는데, 프로젝트 초기에 80%까지는 AI로 빠르게 만들 수 있지만, 이 상태에서 AI로도 도저히 해결되지 않는 문제를 만나서 본인 스스로 문제를 해결하려고 하거나 원하는 기능을 붙이려고 하는 경우가 문제가 된다. AI가 너무 복잡하게 짜놓은 코드를 개발자가 이해하지 못하는 상태이기 때문에 프로젝트에 대한 통제권을 잃어버리는 것이다.

결국 AI를 통한 완전한 바이브코딩은 한계에 다다를 수밖에 없고, 아직 AI는 개발자의 대체재가 아닌 개발자의 생산성을 극대화하는 ‘도구’로서의 쓰임이 더 적절하다.

개발자 취준하는 사람들 사이에서는 종종 ‘AI가 개발자를 대체할 것 같다’는 우려의 목소리가 나오곤 한다. 세션 강연자는 이에 대해서 AI 시대에서 차별화되는 개발자가 되려면 ‘이럴 때일 수록 기술이라는 본질에 집중해야 한다’고 말했다. 모두가 AI를 통해 개발을 할 때, CS 지식 등 기본 지식에 대해 잘 알 수록 문제가 생겼을 때 AI를 잘 컨트롤 할 수 있는 힘이 생긴다는 것이다.

또한, AI가 이런 고민을 하지 않아도 될만큼 개발자를 능가할 만큼 발전하더라도 괜찮다.

개발자가 단순히 ‘기술을 많이 아는 사람’이 아니라 ‘문제를 해결할 줄 아는 사람’, ‘그 문제를 기술로 해결할 수 있는 사람’이 된다면 기술에 의해 대체되는 사람이 아니라 기술을 도구로 이용하는 사람으로서 계속 살아남을 수 있을 것이다.

GDG 인천 즐기기

체크인을 하고 굿즈, 스티커를 받았다. 굿즈는 devfest가 각인된 보온컵이었다. 사무실에서 요긴하게 써야겠다.

이외에도 GDG devfest 후원사에서 부스를 운영했는데 업스테이지에서는 회원가입하고 스포츠 양말을 받았다.

스팸네컷이라는 부스에서는 인생네컷을 찍어주고 있어서 찍어보았다. 여고생들이 운영하는 부스였는데 사진을 찍을 때 옆에서 사진 찍는 걸 도와주다가 프레임 안에 잡혔다. 다시 찍으실래요? 하고 재촬영을 권유했는데, 뭔가 그 귀여운 상황이 사진에 그대로 담긴 것 같아서 그냥 달라고 했다. ㅋㅋ

띠오 데 산타바바라 - 엔칠라다

안스베이커리 구경

송도에 온 김에 맛집에 가야겠다고 생각하고 멕시칸 요리집에 혼밥 하러갔다. 엔칠라다가 너무 맛있어서 15분만에 다 먹고, 근처에 있는 베이커리를 구경했다. 밥을 먹고 와서 그런지 먹고 싶은 빵이 없어서 그냥 찹쌀떡 하나를 사서 먹었다.