대표 번역가 : 오치문


개발자는 문제를 해결하는 사람이라고 믿는, 카페모카를 좋아하는 평범한 개발자.

현재 카카오 검색팀에서 일하고 있으며 문제를 깔끔하게 해결하는데 관심이 많다.


원문 링크





고통기반 프로그래밍 Suffering-oriented Programming

전에 누군가 저에게 흥미로운 질문을 던졌습니다. "스타트업을 하면서 Storm(Storm은 실시간 처리 시스템입니다.)을 만들 때 어떻게 엄청난 위험을 무릅쓰고 진행할 수 있었나요?" 외부 투자자 관점에서 볼 때 스타트업에서 이런 거대한 프로젝트는 매우 위험해 보인다는 것을 저는 알고 있습니다. 하지만 제가 볼때, Storm을 만드는 것은 전혀 위험하지 않았습니다. 그것은 도전적이었지만 위험하지는 않았습니다.

저는 Storm과 같은 거대한 프로젝트를 진행할 때 위험을 크게 줄이는 개발 스타일을 따르는데 이 스타일을 "고통기반 프로그래밍"이라고 부릅니다. 고통기반 프로그래밍은 다음과 같이 요약될 수 있습니다.

  • 어떤 기술이 없어서 고통받는 경우가 아니라면, 그 기술을 구축하지 말아라.

이것은 매일 겪는 프로그래밍에서의 사소한 의사결정뿐만 아니라 대규모의 아키텍처를 결정할 때도 적용됩니다. 고통기반 프로그래밍은 항상 중요한 작업을 하고 있음을 보장함으로써 위험을 크게 줄이고 대규모 투자를 시도하기 전에 문제 영역에 정통할 수 있도록 해줍니다.

고통기반 프로그래밍을 위한 나만의 주문이 있습니다.

  • “일단 돌아가게 만든 다음, 아름답게 만들어라. 그런 다음 빠르게 만들어라."

일단 돌아가게 만들어라 First make it possible 

여러분이 익숙하지 않은 도메인을 만났을 때 바로 '보편적인' 혹은 '확장가능한' 솔루션을 구축하려고 시도하는 것은 실수입니다. 왜냐하면 앞으로 무엇이 필요하게 될지 충분히 예상할만큼 문제 도메인을 잘 이해하고 있지 못하기 때문입니다. 쓸데없이 일반적인 것을 만들게 될 것이고, 이것은 복잡도만 높이고 시간을 낭비하는 것입니다.

그것보다는 바로 '부딪히는 것' 그리고 당면한 문제를 바로 해결하는 것이 더 낫습니다. 이것이 해결하고 싶었던 것을 끝내고 낭비되는 작업을 피할 수 있게 해줍니다. 부딪혀가면서 문제영역의 복잡성에 대해 더 많이 배우게 됩니다.

Storm의 경우 "돌아가게 만들기" 단계는 1년이 걸렸고 큐와 워커를 사용하여 스트림 처리 시스템을 만들었습니다. 우리는 'ack' 프로토콜을 사용해서 데이터 처리를 보장하는 방법을 배웠습니다. 또 큐와 워커로 구성된 클러스터를 이용해서 실시간 처리 시스템을 확장하는 방법을 배웠습니다. 때로는 여러 가지 방법으로 메시지 스트림을 분할해야 하는 경우가 있다는 것을 배웠고, 어떤 때는 무작위로 어떤 때는 동일한 엔티티가 항상 동일한 워커에게 전달되도록 hash/mod 기술(역자 주. 나누기 연산 결과로 얻은 나머지를 워커의 ID처럼 이용해서 특정 워커에게 전달하는 것) 을 사용하는 것을 배웠습니다.

우리는 심지어 "돌아가게 만들기" 단계에 있다는 것조차 모르고 단지 제품을 만드는 데 집중했습니다. 큐와 워커 시스템의 고통은 매우 빠르게 커졌고 시스템을 확장하는 것은 지루한 작업이었으며 내결함성은 우리가 원했던 곳에 없었습니다. 큐와 워커 패러다임은 올바른 추상화 수준에 있지 않았음이 분명했습니다. 대부분의 코드는 우리가 신경썼던 비즈니스 로직보다는 메시지 라우팅과 직렬화와 관련되어 있어야 했습니다.

동시에, 제품 개발을 통해 우리는 '실시간 계산' 문제 영역에서 새로운 유스케이스를 발견했습니다. 우리는 트위터에서 URL의 도달 범위를 계산할 수 있는 기능을 개발했습니다. 도달 범위는 트위터에서 URL에 노출된 고유 사용자 수입니다. 이것은 한 번의 계산을 위해 수 백 번의 데이터베이스 호출과 수 천만 번의 노출을 필요로 하는 어려운 계산 방법입니다. 단일 시스템에서 실행된 초창기 구현은 hard URL들을 처리하는데 1분 정도 걸렸으므로, 계산을 병렬화하여 빠르게 수행할 수 있는 분산 시스템이 필요하다는 것이 명확해졌습니다.

Storm을 촉발시킨 중요한 깨달음 중 하나는 '도달 문제'와 '스트림 처리' 문제가 단순한 추상화로 통일 될 수 있다는 것이 었습니다.

그 다음 아름답게 만들어라 Then make it beautiful

문제를 해결하기 위해 부딪혀가면서 문제 영역의 '지도'를 만들어갑니다. 시간이 지남에 따라 문제 영역 내에서 점점 더 많은 유스케이스들을 습득하고, 이런 시스템을 구축하는 과정에 대해 깊이 이해하게 됩니다. 여기서 얻은 깊은 이해는 기존 시스템을 대체하고, 고통을 덜어 주며, 이전에 구축하기에는 너무 힘들었던 새로운 시스템/기능을 사용한 '아름다운' 기술의 창출을 이끌어낼 수 있습니다.

'아름다운' 솔루션을 개발하는 열쇠는 이미 가지고 있는 구체적인 유스 케이스들을 해결하는 가장 단순한 추상화들의 집합을 찾는 것입니다. 실제로 가지고 있지 않은 유스케이스를 예상하려고 시도하는 것은 실수이며, 솔루션이 오버엔지니어링 될 것입니다. 일반적으로 여러분이 만들려는 것에 투자가 많을수록 문제 영역을 더 깊이 이해해야 하고 사용 사례가 다양해야 합니다. 그렇지 않으면 second-system effect(역자 주. 이전 시스템에서 아쉬웠던 점을 추가하면서 불필요하게 비대한 결과가 만들어지는 것)가 발생할 위험이 있습니다.

'아름답게 만들기'는 디자인과 추상화 기술을 사용하여 문제 영역을 함께 조합될 수 있는 단순한 추상화 집합으로 정제하는 것입니다. 저는 통계적 회귀와 유사한 아름다운 추상화의 진화를 봅니다. 그래프 위의 점들(유스케이스)을 가지고 그 점에 맞는 가장 단순한 곡선(추상화 집합)을 찾고 있습니다.

여러분이 가진 유스케이스가 많을수록 그 점에 맞는 올바른 곡선을 찾을 수 있습니다. 충분한 점을 갖지 못하면, 이상적인 그래프보다 올라가거나(overfit) 내려가기(underfit) 때문에, 헛된 작업과 오버엔지니어링으로 이어지게 됩니다.

아름답게 만드는 단계에서 큰 비중을 차지하는 부분은 문제 영역의 성능 및 리소스 특성을 이해하는 것입니다. 이것은 "돌아가게 만들기" 단계에서 배우는 복잡함 중 하나이며, 아름다운 솔루션을 디자인 할 때 학습한 것을 활용해야만 합니다.

저는 Storm을 사용하여 실시간 컴퓨팅 문제 영역을 스트림, 스파우트, 볼트 및 토폴로지와 같은 작은 추상화 집합으로 정제 했습니다. 저는 시스템에서 가장 복잡하고 고통스러운 부분인 중간 메시지 브로커가 필요 없으면서도 데이터 처리를 보장할 수 있는 새로운 알고리즘을 고안했습니다. 표면상으로 볼 때 매우 다른 스트림 처리와 도달 문제가 너무 우아하게 매핑되었고 Storm은 제가 대단한 일에 몰두하고 있다는 강력한 지표였습니다.

저는 Storm에 대한 더 많은 유스케이스를 확보하고 디자인을 검증하기 위해 추가 조치를 취했습니다. 다른 엔지니어들이 실시간 문제에서 다루었던 상세한 내용들을 배우기 위해 조사했습니다. 아는 사람들에게 바로 물어보지 않았습니다. 저는 또한 새로운 실시간 시스템을 만들고 있다는 것과 다른 사람들의 유스케이스에 대해 배우고 싶다는 것을 트위터에 올렸습니다. 이로 인해 흥미로운 토론이 많이 이뤄져서 문제 영역에 대해 더 많이 배울 수 있었고 저의 디자인 아이디어들을 검증할 수 있었습니다.

그 다음 빠르게 만들어라 Then make it fast 

아름다운 디자인을 완성한 후에는 프로파일링 및 최적화에 시간을 투자할 수 있습니다. 최적화를 너무 일찍하면 시간을 낭비할 수 있는데 그 이유는 여러분이 여전히 디자인을 변경할 수 있기 때문입니다. 이것을 조숙한 최적화라고 합니다.

"빠르게 만들기"는 시스템에서 높은 수준의 성능 특성에 관한 것이 아닙니다. 이러한 문제들을 이해하는 것은 " 돌아가게 만들기" 단계에서 습득하고 "아름답게 만들기" 단계에서 설계 되어야 합니다. "빠르게 만들기"는 마이크로 최적화에 관한 것이고 코드를 강화하여 리소스를 보다 효율화하는 것입니다. 따라서 당신은 "아름답게 만들기" 단계에서는 점근적 복잡도와 같은 것을 고려하고, "빠르게 만들기" 단계에서는 상수시간 요소들에 대해 집중하게 될 것입니다.

개선 그리고 반복 Rinse and repeat 

고통기반 프로그래밍은 지속적인 프로세스입니다. 당신이 구축한 아름다운 시스템은 문제 공간의 새롭고 깊은 영역에서 "돌아가게 만들기"를 시작할 수 있는 새로운 가능성을 제시합니다. 이것은 기술에 대한 학습을 유도합니다. 여러분은 점점 더 많은 유스케이스를 처리하기 위해 이미 찾아낸 추상화를 조정하거나 추가해야 합니다.

Storm은 이런 식으로 많은 반복 작업을 거쳤습니다. Storm을 처음 사용하기 시작했을 때, 우리는 단일 구성 요소에서 여러 개의 독립적인 스트림을 방출 할 수 있는 기능이 필요하다는 것을 알았습니다. 우리는 'direct stream'이라는 특별한 종류의 스트림을 추가하면 Storm이 튜플의 배치를 개별 단위로 처리수 있음을 발견했습니다. 최근에 저는 Storm의 '최소 한 번 처리 보장'을 뛰어 넘으며 거의 임의의 실시간 계산을 위해 '정확히 한 번 메시징'이 허용되는 '트랜잭션 토폴로지'를 개발했습니다.

본질적으로, 여러분이 잘 이해하지 못하는 문제 영역에서 문제를 헤쳐나가고 계속해서 반복하다보면 코드가 엉성해질 수 있습니다. 고통기반 프로그래머의 가장 중요한 자질은 리팩토링에 끈질기게 주력하는 것입니다. 이것은 코드베이스를 망침으로 인해 발생하는 accidental complexity(역자 주. 엔지니어들에 의해 발생되고 고칠수 있는 문제)을 막기 위해 매우 중요합니다.

결론

유스케이스는 고통 기반 프로그래밍의 모든 것입니다. 유스케이스들은 마치 황금과 같은 가치가 있습니다. 유스케이스를 얻는 유일한 방법은 부딪혀가면서 경험을 쌓는 것입니다.

대부분의 프로그래머가 겪는 특정한 진화가 있습니다. 당신은 일을 시작하고 처음 코드에서는 구조란걸 찾아볼 수 없습니다. 코드가 엉성하고 복사/붙여넣기가 만연합니다. 마침내 구조화된 프로그래밍과 공유할 수 있는 로직의 이점에 대해 가능한만큼 배우게 됩니다. 그런 다음 포괄적인 추상화를 만들고, 캡슐화를 통해 시스템을 쉽게 추론 할 수 있는 방법에 대해 배웁니다. 그 후에 여러분은 프로그램이 미래에도 경쟁력을 갖출 수 있게 확장가능하도록 만드는 것과 코드를 일반화시키는 것에 사로잡히게 됩니다.

고통기반 프로그래밍은 여러분이 현재 가지고 있지 않은 요구를 효과적으로 예상할 수 있다는 것을 부인합니다. 이것은 문제 영역에 대한 깊은 이해없이 일을 일반화하려는 시도는 복잡성과 낭비로 이어질 것이라는 점을 깨닫게 해줍니다. 디자인은 항상 실질적이고 실제적인 유스케이스에 의해 주도되어야 합니다.


설정

트랙백

댓글