데이터 과학 프로젝트의 가치 창출 시간 단축 방법 소개

데이터 과학 프로젝트의 가치 도달 시간 단축: 파트 1 데이터 과학 프로젝트의 실험 및 개발 단계는 데이터 과학자가 돋보일 수 있는 영역이다. 다양한 데이터 처리, 특성 조합, 모델 선택 등을 시도하는 것이 이 단계의 핵심으로, 이러한 과정을 통해 비즈니스 요구사항에 맞는 최종 솔루션을 도출한다. 데이터 과학자들은 이러한 실험을 수행하고 비판적으로 평가할 기술적 역량을 갖추고 있으며, 비즈니스는 가능한 한 빠르게 프로덕션화된 솔루션을 제공하기를 기대한다. 이 단계에서 소요되는 시간을 '가치 도달 시간'이라고 한다. 그러나 개인적인 경험에 따르면, 실험 단계가 큰 시간 낭비가 될 수 있으며, 프로젝트가 시작되기 전에 완전히 탈선될 위험까지 있다. 주피터 노트북에 대한 과도한 의존, 수동으로 병렬 실험을 수행하는 것, 그리고 소프트웨어 베스트 프랙티스를 제대로 구현하지 않는 것 등이 원인 중 일부다. 이로 인해 실험과 아이디어의 반복이 불필요하게 길어지며, 비즈니스에 가치를 제공하는 시간이 늦춰진다. 이 글은 일련의 시리즈 중 첫 번째로, 실험을 더 체계적이고 집중적으로 수행하는 데 도움이 되는 원칙을 소개한다. 이를 통해 대규모 병렬 실험을 효율적으로 수행할 수 있으며, 여유 시간을 이해관계자와의 협의, 새로운 데이터 소스 확보, 프로덕션화를 위한 준비 등의 다른 영역에 투자할 수 있게 된다. 결과적으로 프로젝트의 가치 도달 시간을 줄임으로써 비즈니스에 더 빠르게 기여할 수 있다. 노트북의 문제점 주피터 노트북은 데이터 과학자들에게 매우 익숙하다. 코드를 대화식으로 실행하고 시각화를 생성하며, 마크다운으로 코드와 설명을 섞어 쓸 수 있어 매우 유용한 자원이다. 새로운 프로젝트나 데이터셋을 다룰 때, 처음 단계는 대부분 노트북을 실행하여 데이터를 로드하고 탐색하는 것이다. 그러나 노트북이 잘못 사용되면 많은 문제가 발생한다. 동기화되지 않은 코드 블록 실행, 블록 내에서 함수를 정의하고, 자격 증명 정보나 API 키를 변수로 하드코딩하는 것 등이 그렇다. 특히, 노트북 내에서 함수를 정의하는 것은 여러 문제를 야기한다. 함수를 쉽게 테스트할 수 없으며, 베스트 프랙티스가 적용되었는지 확인하기 어렵다. 또한, 해당 노트북 안에서만 사용할 수 있어 재사용성이 떨어진다. 이 코드 실크로를 벗어나는 것이 대규모 실험을 효율적으로 실행하는 데 중요하다. 로컬 vs 글로벌 기능 일부 데이터 과학자들은 이러한 나쁜 습관을 인식하고 더 나은 코딩 실천을 한다. 예를 들어, 함수를 별도의 Python 파일로 분리하여 저장하고 필요할 때 가져다 사용하는 방법이 있다. 이는 노트북 내에서 함수를 정의하는 것보다 크게 향상되었지만, 여전히 부족한 점이 있다. 경력 내내 여러 프로젝트에서 많은 코드를 작성하게 되는데, 종종 이전 프로젝트에서 작성한 코드를 재사용하려는 경우가 많다. 재사용성을 위해 코드를 공유하는 방법은 대부분 한 리포지토리에서 다른 리포지토리로 전체 코드를 복사하고 붙여넣는 방식이다. 이는 유지 보수 측면에서 큰 골칫거리가 된다. 하나의 함수에서 문제가 발견되면 모든 복사본을 찾아 수정해야 하는 노동집약적인 작업이 필요하다. 또한, 함수가 특정 작업에 너무 특화되어 있으면 복사 및 붙여넣기 작업에도 작은 수정이 필요하다. 그 결과, 90% 이상 코드가 동일하면서 약간의 변경만 있는 여러 함수들이 생겨난다. 이와 같은 접근법은 스크립트가 점점 기능으로 부풀어지고, 서로 관계가 없는 기능들이 증가하는 문제를 일으킨다. 현재 프로젝트를 넘어 장기적으로 코드를 어떻게 저장할지 고민하는 것이 미래의 성공을 위해 중요하다. 비즈니스 요구사항을 효율적으로 해결할 수 있는 재사용 가능한 구성 요소를 만드는 것을 목표로 외부 리포지토리를 생성하는 것을 제안한다. 구성 요소에 초점을 맞추기 '구성 요소'란 무엇을 의미하는 걸까? 예를 들어, 모델에 데이터를 입력하기 전에 여러 데이터 준비 기법을 수행해야 할 때, 결측치 처리, 숫자 스케일링, 범주형 인코딩, 클래스 균형(분류 모델의 경우) 등을 고려해야 한다. 결측치 처리에만 집중해도 여러 방법이 있다. 실험을 수행하면서 이러한 방법들을 모두 시도하려면 어떻게 해야 할까? 각 실험마다 코드 블록을 수동으로 수정하는 방법은 간단하지만, 관리가 어려워진다. 어떤 실험에서 어떤 코드 설정을 사용했는지를 기억하는 것이 어렵기 때문이다. 더 나은 방법은 조건부 문장을 작성하여 쉽게 전환할 수 있도록 하는 것이다. 그러나 이도 여전히 재사용성에 문제가 있다. 대신, 모든 기능을 하나의 래퍼 함수로 추상화하고, 사용하고자 하는 처리 방법을 인수로 지정할 수 있도록 하는 방법을 권장한다. 이렇게 하면 실험 간에 코드를 변경할 필요가 없으며, 함수는 일반적이어서 다른 곳에서도 사용할 수 있다. 이렇게 기능 구현을 추상화하는 과정은 데이터 과학 워크플로를 효율화하는 데 도움이 된다. 비슷한 기능을 다시 작성하거나 기존 코드를 복사 붙여넣기 할 필요가 없기 때문에, 프로젝트 간에 재사용이 용이하다. 데이터 변환 과정의 여러 단계를 쉽게 추가하여 하나의 일관된 기능을 형성할 수 있다. 이는 모델 생성 과정의 모든 단계로 확장될 수 있다. 설계 고려 사항 외부 코드 리포지토리를 구조화하기 위해 고려해야 할 설계 결정이 많다. 최종 구성은 요구사항에 따라 다르겠지만, 다음과 같은 몇 가지 고려 사항을 제시한다: 각 구성 요소별로 별도의 디렉토리를 만들자. 각 구성 요소가 필요한 모든 기능을 포함하도록 클래스를 정의하자. 단일 실행 메서드를 만들어 단계를 수행하자. 기능 선택은 구성 파일을 통해 제어하자. 이 설계 체크리스트는 완전한 목록은 아니지만, 리포지토리 설계를 위한 출발점이 될 수 있다. 중앙화된 중립 리포지토리의 강점 공통적인 데이터 과학 단계를 담은 도구함은 좋은 아이디어처럼 들린다. 그러나 왜 별도의 리포지토리가 필요한가? 이 질문에 대한 부분적인 답은 위에서 다뤘다. 구현 세부 사항을 비즈니스 응용 프로그램에서 분리하여 더 유연한 코드를 작성하고 다양한 시나리오에서 재배포할 수 있도록 하는 것이다. 이 접근법의 진정한 강점은 조직 내의 동료들과 팀원들을 고려할 때 더욱 두드러진다. 회사의 모든 데이터 과학자가 생성하는 코드의 양을 상상해보라. 얼마나 많은 코드가 특정 프로젝트에만 독점적인가? 물론 일부는 그러하겠지만, 모두가 아니다. 재구현된 코드의 양은 눈에 띄지 않지만, 곧 자원의 큰 낭비로 이어질 것이다. 반면, 공통 데이터 과학 도구를 중앙에서 위치시키면, 데이터 품질, 특성 선택, 하이퍼파라미터 튜닝 등의 단계를 즉시 사용할 수 있어 실험 시작 속도가 크게 빨라질 것이다. 같은 코드를 사용하면 더 신뢰성 있고 일반적인 도구를 만들 수 있는 기회가 열린다. 사용자가 많아지면 이슈나 버그가 검출될 확률이 높아지고, 여러 프로젝트에서 배포되면서 더 일반화된 코드가 되도록 강제된다. 하나의 리포지토리에 대해서는 하나의 테스트 스위트만 필요하며, 충분한 커버리지를 갖춘 포괄적인 테스트를 수행할 수 있다. 리포지토리에서 기능을 사용하는 것은 간단하다. 필요한 메서드를 쉽게 임포트하고 호출할 수 있다. 리포지토리에 필요한 기능이 없거나, 자신만의 기술을 구현하고 싶다면, 이 중앙화된 코드 리포지토리에 기여하는 것이 어떨까? 같은 비즈니스 목표를 달성하기 위해 팀이나 회사 전체가 함께 기여하고 중앙화된 리포지토리를 구축하면, 다양한 가능성이 열린다. 각 데이터 과학자가 자주 사용하는 기술을 기여함으로써, 내부 오픈 소스 환경이 조성되고 협업이 촉진된다. 결론적으로, 이 글은 비즈니스 가치를 크게 저하시키는 일반적인 데이터 과학 오류를 다루는 일련의 시리즈 중 첫 번째이다. 여기서는 프로젝트와 무관한 모듈화되고 분리된 코드를 작성하고 저장하는 방법에 초점을 맞추었다. 이러한 구성 요소는 여러 프로젝트에서 재사용할 수 있어 솔루션 개발이 더 빠르고 결과에 대한 신뢰성이 높아진다. 이러한 코드 리포지토리를 구축하면, 조직 내 모든 구성원이 이를 활용하여 강력하고 유연하며 견고한 도구를 만들 수 있다.