러시아 페인트공 알고리즘은 조엘 온 소프트웨어에 나오는 내용으로 코드를 확장성을 염두에 두지 않고 작성해서 작은 규모에서는 잘 돌지만 workload 가 커지면 큰 문제를 발생시키는 것을 의미합니다.
검색해 보니 원어는 "Schlemiel the Painter's Algorithm" 인데 "러시아 페인트공 알고리즘"으로 번역한 듯 하며 Schlemiel 는 이디시어로 바보나 덜 떨어진 사람을 의미한다고 합니다.
왜 저런 이름이 붙었는지 책에 나오는 예시는 다음과 같습니다.
Shlemiel 이라는 사람이 차선을 칠하는 일자리를 얻었는데 첫날은 300 야드를 칠했습니다.
관리자는 "훌륭해! 정말 빠르게 일하는군!" 이라고 외치고 페인트공에게 보너스를 주었습니다.
둘째 날은 150 야드를 칠했는데 관리자는 "어제만은 못 하지만 이정도면 잘하는거군" 이라면서 약간의 보너스를 주었습니다.
셋째 날은 30 야드만 칠해서 관리자가 "겨우 30야드야? 첫 날은 10배를 칠했는데 무슨 문제가 있는건가? 라고 물어보자 페인트공이 대답했습니다.
"저도 어쩔 수 없었습니다. 매일 페인트 통에서 점점 멀어지니까요"
책에 나오는 C 언어 예시 코드는 다음과 같습니다.
char string[1000];
strcpy(string, "one");
strcat(string, ", two");
strcat(string, ", three");
strcat(string, ", four");
CPP
char *strcat(char *dest, const char *src); 는 2개의 스트링을 연접하는 함수입니다.
작동은 dest 에 src 문자열을 연접하기 위해 dest 문자열이 NULL 문자가 나올때 까지 검색하고 마지막에 src 문자열을 붙인후에 결과를 포인터로 리턴합니다.
그런데 위 코드는 연접시마다 NULL 문자를 찾기 위한 검색을 매번 string 버퍼의 처음부터 시작하므로 문자열 길이가 늘어나면 그만큼 속도가 떨어지게 됩니다.
일단은 잘 동작하지만 서비스가 성공하게 되면 발목을 잡는 레거시 코드(legacy code)나 기술 부채등이 이런 방식으로 작성한 코드때문이므로 코드를 작성할 때 특정 상황만 염두에 두지 말고 향후 확장 가능하게 코드를 작성해야 합니다.
Framework 기반 개발을 장려하는 이유는 잘 설계한 Framework 은 추상화가 잘 되어 있고 여러 디자인 패턴과 방법론이 적용되어 있기때문입니다.
비록 초기 개발시에 날코딩에 비해 시간이 걸리는 듯 해도 좋은 품질의 코드를 작성할 확률이 높아지며 규모가 커질때 서비스의 확장이 쉽고 소스 코드의 유지보수도 용이해집니다.
예로 제가 선호하는 laravel framework 의 경우 File Storage 가 추상화되어 있어서 파일을 저장하고 삭제하는 부분을 다음과 같이 작성할 수 있습니다.
use Illuminate\Support\Facades\Storage;
Storage::makeDirectory($directory);
Storage::put('example.txt', 'Contents');
Storage::delete('file.jpg');
PHP
실제 파일과 디렉터리가 어디에 저장되고 삭제되는지는 Adapter 로 정의하면 됩니다.
만약 사업 시작을 local disk 에 저장하도록 했는데 서비스가 확장되어 용량이 부족해져서 AWS 의 Object Storage 인 S3 를 사용하도록 정책을 수립했다고 가정해 보겠습니다.
Laravel 같이 잘 추상화된 Framework 를 사용하여 코딩했다면 기존 코드를 변경할 필요없이 adapter 설정을 S3 로 변경하고 REGION 과 BUCKET 등 연결 정보만 설정해 주면 되므로 "러시아 페인트공 알고리즘"을 회피할 수 있습니다.
위 예시는 확장에 대비한 코드이며 data migration 작업은 별개로 필요합니다.
같이 보기
Ref
