리서치 결과물이 실제 제품이 되는 과정에서 가장 많이 무너지는 지점은 팀이 바뀌는 순간이다. 논문을 읽고 PoC를 만든 팀과 그 결과물을 실서비스로 옮기는 팀이 다르면, 기술 판단의 맥락이 사라진다. 나무숲은 그 단절을 없애는 방식으로 일한다. 연구부터 배포까지 같은 팀이, 처음 잡은 구조 그대로 끝까지 가져간다.
리서치와 실서비스 사이에서 어떤 문제가 생기는가?
리서치 단계와 운영 단계 사이에는 대개 이런 단절이 있다.
- 맥락 손실: PoC에서 특정 모델을 선택한 이유, 학습 데이터의 전처리 결정, 실패한 접근법의 이유가 문서화되지 않은 채 다음 팀에 넘어간다.
- 재현 불가: 논문 재현 코드는 실험 환경(GPU 사양, 라이브러리 버전, 데이터 형식)에 강하게 의존한다. 새 팀이 이를 처음부터 파악하는 데만 수 주가 걸린다.
- 요구사항 번역 오류: "정밀도 0.92 이상"이라는 연구 지표가 실제 서비스에서 어떤 사용자 경험으로 이어지는지, 이 번역을 잘못 하면 모델 성능 자체가 무의미해진다.
- 운영 요건 반영 실패: 실서비스는 응답 지연(latency), 비용, 배포 환경이 연구 환경과 다르다. 뒤늦게 이를 반영하려면 아키텍처를 다시 설계해야 한다.
가장 흔한 패턴은 이렇다. 외주 업체 A가 리서치를 마쳤다. 그 결과물을 인수한 외주 업체 B가 "이 코드는 우리가 처음부터 다시 써야 합니다"라고 한다. 발주처는 이미 리서치 비용을 지불했다. 이 문제는 기술력의 문제가 아니라 구조의 문제다.
POSTECH·KAIST·서울대 출신 엔지니어들이 논문 기술을 제품으로 옮기는 방법
논문을 읽을 수 있는 것과 그 안의 기법을 실제 제품에 쓸 수 있는 것은 다른 능력이다. 나무숲 엔지니어들이 논문 기반 기술을 구현할 때 따르는 흐름은 대략 이렇다.
1단계 — 재현 가능한 실험 환경 고정
논문 재현의 첫 단계는 환경을 코드로 고정하는 것이다. 라이브러리 버전, 시드값, 데이터 전처리 파이프라인을 처음부터 버전 관리한다. 실험 관리에는 MLflow 같은 오픈소스 도구를 활용해 각 실험의 파라미터와 결과를 추적한다.
# 실험 환경 고정 예시
pip freeze > requirements.txt
git tag experiment/baseline-v1
mlflow run . --experiment-name "paper_repro_baseline"
2단계 — 서비스 제약을 리서치 단계에 미리 반영
응답 속도, 비용, 배포 환경은 연구 단계부터 제약 조건으로 다룬다. 예를 들어 Transformer 기반 모델을 도입할 때, GPU 추론 비용이 허용 범위를 넘으면 ONNX Runtime이나 quantization 적용 가능성을 리서치 단계에서 함께 검토한다.
3단계 — PoC 코드를 서비스 코드로 전환하는 기준 명시
PoC 단계가 끝날 때 "이 코드의 어느 부분이 서비스 코드로 그대로 가고, 어느 부분이 다시 써야 하는가"를 명시적으로 판단한다. 이 판단이 없으면 PoC 코드가 그대로 프로덕션에 들어가거나, 반대로 멀쩡한 코드를 처음부터 다시 쓰는 낭비가 생긴다.
이 흐름이 유지되는 이유는 단순하다. 리서치를 한 사람이 서비스 구현도 맡기 때문에, 무엇을 지키고 무엇을 바꿔야 하는지 판단할 수 있다. 나무숲의 에이전틱 AI 서비스처럼 여러 모델이 협업하는 복잡한 시스템일수록 이 연속성이 더 중요해진다.
처음부터 끝까지 한 팀이 맡으면 개발 속도가 어떻게 달라지는가?
단절 없는 개발이 속도에 영향을 주는 구체적인 이유가 있다.
컨텍스트 전달 비용이 사라진다. 팀이 바뀌면 새 팀은 결정의 이유가 아니라 결과물만 본다. 왜 이 구조를 선택했는지, 어떤 접근법을 먼저 시도했다가 포기했는지를 파악하는 데 시간이 든다. 같은 팀이 계속 가져가면 이 비용이 없다.
재작업 범위가 줄어든다. 리서치 단계에서 서비스 제약을 이미 반영했기 때문에, 배포 직전에 "이 아키텍처로는 latency를 맞출 수 없다"는 결론이 나오는 경우가 드물다.
전원이 같은 AI 개발 환경을 표준으로 사용한다. 나무숲 팀원 전원은 Claude Code Max를 기본 개발 환경으로 쓴다. 코드 리뷰, 문서 작성, 테스트 케이스 생성 모두 동일한 도구 위에서 진행한다. 이 표준화 덕분에 팀 내 속도 편차가 작고, 신규 태스크 착수 시간도 단축된다.
아래는 팀 규모와 개발 방식에 따른 일반적인 속도 차이를 보여주는 비교 프레임이다. 특정 숫자를 보장하는 표가 아니라, 구조적 차이를 이해하기 위한 참고 프레임이다.
| 구분 | 팀 분리 방식 (리서치 팀 → 구현 팀) | 한 팀 연속 방식 |
|---|---|---|
| 컨텍스트 전달 | 별도 인수인계 필요 | 없음 |
| 서비스 제약 반영 시점 | 구현 단계 시작 후 | 리서치 단계부터 |
| 아키텍처 재설계 빈도 | 높음 | 낮음 |
| 착수 기준 | 인수인계 완료 후 | 리서치와 동시 |
| 책임 경계 | 팀 간 분산 | 단일 팀 |
대형 SI 업체가 2~6개월 걸려 착수하는 프로젝트를 나무숲이 2주 안에 시작할 수 있는 구조적 이유가 여기 있다. 빠른 것이 아니라, 느리게 만드는 단계가 없는 것이다.
실제 운영 중인 포트폴리오 8선이 말해주는 것
나무숲이 운영 중인 AX 포트폴리오 8개 중 일부를 구조 관점에서 살펴보면 패턴이 보인다.
여행사 백오피스 자동화: 예약 데이터 수집부터 정산 처리까지 이어지는 흐름을 단일 파이프라인으로 구성했다. 여러 시스템을 잇는 에이전트 구조가 핵심이다. 이 구조는 리서치 단계에서 데이터 형식과 API 스펙을 미리 파악한 팀이 아니면 처음부터 설계하기 어렵다.
항공우주 견적 AI: 도면 파일에서 부품 정보를 추출하고 견적을 자동 생성하는 시스템이다. 컴퓨터 비전 모델과 도메인 특화 규칙 엔진이 결합된 구조로, 리서치에서 나온 모델을 운영 환경의 응답 속도 요건에 맞게 최적화하는 과정이 중요했다.
도면 부품 추출 AI: 기계 도면에서 부품 리스트를 자동 추출한다. OCR과 객체 탐지 모델을 결합하고, 도메인별 예외 처리 로직을 레이어로 쌓는 구조다. 이 레이어를 어디까지 모델로 처리하고 어디서부터 규칙 기반으로 넘길지 판단하는 것이 리서치와 구현 경험이 동시에 필요한 지점이다.
이 세 가지 사례의 공통점은 "모델 하나를 잘 쓰는 것"이 핵심이 아니라는 점이다. 도메인 데이터 이해, 운영 환경 제약, 예외 처리 로직이 모두 초기 설계에 반영되어야 했고, 그게 가능했던 이유는 리서치부터 배포까지 같은 팀이 판단했기 때문이다. AI 자동화 서비스에서 이런 아키텍처 접근 방식을 더 확인할 수 있다.
자주 묻는 질문
리서치 단계부터 외주를 맡기는 것이 비효율적이지 않은가?
리서치 단계를 외부에 맡기면 내부 노하우가 축적되지 않는다는 우려는 타당하다. 다만 리서치와 구현을 같은 팀에 맡기면, 리서치 결과가 실제 구현에 바로 반영된다. 리서치만 따로 맡기고 구현은 다른 팀에 주는 것이 오히려 비효율이다. 무엇을 내재화할지 판단하는 것이 먼저다.
논문 기반 기술을 실제 서비스에 적용할 때 가장 흔한 실패 원인은 무엇인가?
서비스 제약을 리서치 단계에 반영하지 않는 것이다. 정밀도, 재현율 같은 연구 지표만 보고 배포 단계에서야 latency나 비용 문제를 인식하면 아키텍처를 처음부터 다시 설계해야 한다. 이 문제는 리서치 팀과 구현 팀이 분리될 때 특히 자주 발생한다.
팀이 하나라도 도메인 전문성이 부족하면 어떻게 하는가?
도메인 지식은 대부분 발주처가 갖고 있다. 중요한 것은 그 지식을 빠르게 흡수해서 기술 판단에 반영하는 구조다. 나무숲은 리서치 단계부터 발주처와 긴밀하게 작업하며, 도메인 예외 케이스를 초기 설계에 반영하는 방식으로 접근한다.
착수 2주라는 기준은 어떤 조건을 전제하는가?
요구사항이 어느 정도 명확하고, 데이터 접근이 가능한 경우를 전제한다. 데이터 수집 자체가 리서치의 일부인 프로젝트는 착수 기준이 다르다. 첫 상담에서 이 조건을 명확히 확인하는 것이 나무숲의 기본 진행 방식이다.
오픈소스 자산(★120+)은 실제 프로젝트에 어떻게 활용되는가?
공개된 오픈소스 자산은 주로 반복 사용 가능한 파이프라인 컴포넌트와 실험 유틸리티다. 새 프로젝트에서 이미 검증된 컴포넌트를 재사용하면 처음부터 만드는 시간을 줄일 수 있다. 검증된 부분은 재사용하고, 새로운 판단이 필요한 부분에 집중하는 방식이다.
리서치 논문에 머물러 있는 기술을 실제 운영 가능한 제품으로 옮기려면, 그 전 과정을 하나의 팀이 책임지는 구조가 가장 빠르고 안전하다. 중간에 팀이 바뀌지 않기 때문에 기술 판단의 맥락이 유지되고, 운영 제약이 처음부터 설계에 반영된다. 연구 결과를 실제 고도화된 제품으로 바로 운영하고 싶다면 나무숲에 문의하세요.
더 보기: treesoop.com
Top comments (0)