[MLOps] 코드 품질 관리(Quality Control) 관련 개념
Model 개발 시 보통 From scratch로 코드를 작성하기보단, Github에서 괜찮은 구현체를 가져다가 Ctrl + C, V 를 활용해 개발을 하는 경우가 많다.
그래서 다음과 같은 코드 품질 문제가 발생한다.
1. 리서치 코드는 각자의 개인 컴퓨터에 저장되어 있다.
2. 코드는 매번 복사 붙여넣기로 개발하여 코드 중복이 많다.
3. 연구 결과는 재연이 불가능하다. (실험 관리가 안 돼있다)
4. 수많은 코드 악취가 남아있다. (한 파이썬 파일에 모든 코드가 다 들어있다든지..)
코드 관리를 하지 않으면, 깨진 유리창의 법칙에 의해 전체 리서치 조직의 코드 품질도 떨어지게 되므로 이는 중대한 문제이다.
1. 코드 중복
소프트웨어 취약점이 있는 코드가 복사될 때,
개발자가 이러한 사본을 알지 못하는 경우 취약점은 계속해서 복사된 코드에 남아있게 된다.
코드 중복을 사용하면 다음 이점들을 달성할 수 있다.
- 컴파일 시간의 단축
- 인지 부하의 감소
- 인적 오류의 감소
- 코드를 잊거나 간과하는 일의 감소
코드 재사용성
설계, 요구멍세, 검사, 아키텍쳐, 코드 등 재사용가능한 소프트웨어 또는 지식을 활용 / 코드의 재사용은 장황한 작업에 소비하는 시간과 에너지를 절약하는 전형적 기법. 라이브러리 추상화가 좋은 예시이다.
리서치에서 전처리는 중복이 자주 되니, 리서치 코드를 만들어보자
2. 많은 전역변수
전역 변수는 당장 쓰기에는 편할 수 있지만, 항상 사이드이펙트를 가져온다.
가능하면, 환경 값들은 환경 변수를 활용하고함수에 명시적으로 파라미터를 전달하고 받아오는 방식으로 고쳐야 한다.
3. 너무 긴 코드
너무 긴 코드는 디버깅하기 불편하고, 각 함수와 클래스의 구분이 명확하지 않게되는 경향이 있다.
각 python 파일은 500라인 이하로 유지해보자.
4. 이상하게 꼬여있는 import
python의 relative import를 여기저기서 사용하게 되면,
서로 참조 관계가 얽혀서 나중에는 디버깅이 어려운 수준까지 가게 된다.
PYTHONPATH 환경변수를 활용하여 현재 시작 지점을 명확하게 하고, absolute import를 사용하자.
5. 명확하지 않은 변수명
너무 축약어를 쓰다보면, 나밖에 못알아보는 코드가 된다.
혼자 개발할 때는 문제가 없지만, 팀웍을 위해서는 변수명을 이해하기 쉽게 만드는 게 중요하다.
Code lint
Linting is the automated checking of your source code for programmatic and stylistic errors.
Python black
Python black은 reformat 및 자동 검사까지 포함하기 때문에, 일반적으로 black을 쓰고 추가적인 lint를 단계적으로 추가한다.
Flake8
코드 정적 분석기 / Google coding style 지향
mypy
타입 체크 강제 - python이 대표적인 다이나믹 타입 언어 (변수가 어떤 타입인 지 딱 보면 모름)
python3에 타입 힌트 개념이 도입되면서, 타입을 명시적으로 선언할 수 있게 되었다.
예시 (1)
- a: str = "1"
- b: int = 1
예시 (2)
- def fn(a):
- def fn(a: int) -> bool:
위의 예시는 a의 타입, 그리고 return 값이 무엇인 지 명확하지가 않다.
프로젝트 규모가 커지게 된다면, 버그 유발의 주범이 된다.
Continuous Integration
리서치 분야에서는 어려운 기법보다 기초적인 것들만 잘 잡아주더라도 생산성이 올라간다.
소프트웨어 공학에서, 지속적 통합은 지속적으로 Quality Control을 적용하는 프로세스를 실행하는 것이다.