2018 M03 16

나는 어떻게 불과 10년만에 수천가지 방법으로 잘못된 코드 작성하는 법을 배웠나 (How I learned thousands of ways to write bad code in just ten years)

번역 중 bad code 를 악성코드 에서 잘못된 코드 로 바로 잡습니다.
오역으로 인해 혼란을 드린점 사과드립니다.

추후 번역은 이런 오해가 없도록 더욱 신경쓰겠습니다~



이거 저만 그런거에요? 비슷한 헤드라인 글들이 넘쳐나는거 같은데 말입니다:
나는 어떻게 단지 { 몇(number) } {시간 안에(unit of time) } { 프래임워크, 라이브러리, 명령어(command), 유행하는 기술(fad technology) 등등.. } { 배웠나(learned), 마스터했나(mastered), 등등.. }
자, 자, 그래요. 이해합니다! 한번 확인해 보세요. 저 장님 아닙니다! 물론 “Bla-bla-bla 를 개선하기 위한 X 가지 방법들” 그리고 “당신은 어떤 { 해리포터, 프랜즈, 왕좌의 게임 등등.. } 캐릭터 인가?” 는 이미 식상하다는 걸 잘 압니다. 이제 우리는 이런 식상함으로 자비를 바라는게 아닌 전혀 새로운 비유가 필요합니다. 정말이에요. 사실 이건 하향식 경쟁이거든요. 예를들어 누군가 “10분만에 머신 러닝 (machine learning) 마스터하기” 또는 “2주 안에 직원 500명 고용하기” 마지막으로 “나는 어떻게 10초만에 블록체인(blockchain) 전문가가 되었는가?” ... 이건 진짜 아니라는 거죠.
사실 우숩게도 저는 이 현상을 질투하는 걸지도 몰라요. FOMO (좋은 기회를 놓지고 싶지 않은 마음) 는 언제든 불쑥 찾아오잖아요. 이런 현상은 누구에게나 일반적인걸요. 좀 우숩지만 저도 이 현상에 동참하기로 마음 먹었어요. 저랑 아주 적합한 주제 입니다! 아주 따끈따끈 해요!
제가 세상에 제안할 주제는: 나는 어떻게 불과 10년만에 수천가지 방법으로 잘못된 코드(bad code) 작성하는 법을 배웠나?

처음에는...

저는 컴퓨터과학(CS) 학위 취득 후 평범한 개발자로 중소기업 운영팀 업무를 시작하게 됐습니다. 제 일은 급여시스템, IT 재고관리, 인트라넷.. 소위 말하는 땜방 (hacked) 개발자 였어요. 여기서 저는 자타공인 최고 code-and-fix(일단 짜고 보는...) 전문가 였답니다. 당연히 제 코드(code)에 테스트란 사치일 뿐이죠. 작성된 코드 대부분 구글링 + CV 였고 마지막을 화려한 진흙 구덩이로 감싸곤 했으니까요.
혹시 스파게티 코드 좋아하세요? 저는 심지어 Java 에서 조차 goto 문을 활용했답니다. 뭐 이건 기막힌 위치에 예외(exception) 처리 하는 것 만으로 충분해요.
음, 제가 뭐라고 했죠? 아하! 그럼 이어서 갈께요. 게다가 제 끔찍한 코드(code) 위에 다른 사람들의 나쁜 습관까지 녹여냈죠. 저는 뭐 과거에 “정적 상수(static constants) 를 위해 인터페이스 (interface)를 사용하자”“컬렉션(collection) 반복을 통해 아이템(items)을 TreeSet 에 추가 한뒤 이를 불러오자” 를 신뢰할 정도 였으니 말 다했죠. 사실 그 당시 빌어먹을 제 매니저는 프로덕션 SSH 액세스 (production SSH access) 가 가능했고 문제가 발생하면 프로덕션 서버 (production server) 에서 직접 코드를 편집, 컴파일 및 배포(deploy) 해 주시는 아주 모범적인 모델 이였습니다.

중반...

어느 순간, 새벽 2시 에스컬레이션(escalation) 관리 혹은 프로젝트 마감 후 심야 배포(deployment) 라도 하는 날엔 제 작업분에 대한 극심한 스트레스로 인해 말 한마디 못하는 머저리가 돼버렸습니다. 이내, 저는 인정할수 밖에 없었죠: 내 쓰레기 같은 코드 가 너무 싫다 .

presentation
저도 한번 정도는... 뭐라고요? 아... 들켰네요... 여러번 이랬죠.

그래요. 좋은 코드 작성을 위해 꾸준히 노력하면 유능한 실력자도 따라 잡을 수 있을 거에요. 물론 저 역시 이런 짜릿한 유혹을 받아 들였답니다. 저는 조만간 입사할 “진짜 소프트웨어 회사”를 포기하고 허겁지겁 개발 관련 서적 및 비디오를 시청하기 시작했습니다. 저는 그때 Clean Code, Design Patterns, Code Compete, Programming Pearls 를 접하며 마음이 들떠있었어요. 그리고 린 (Lean) 소프트웨어 개발 : 애자일 툴킷 (Agile Toolkit) 을 접할때 쯤 저는 고객 요구를 충족하는 훌륭한 소프트웨어 구축 방법에 완전히 중독 되어 버렸습니다.
그러던 중 아주 끔찍한 실수를 저질렀네요! 제가 직접 접하고 느낀것을 매니저와 상의하기 시작했거든요. 왜 이런 머저리같은 짓을 했을까요! 아무튼, 이미 어떻게 됐을지 예상되죠? 뭐, 늘 그렇듯 결함 덩어리 소프트웨어를 가진 회사 경연진들은 린(Lean) 의 지속적 전달(continuous delivery) 의 꿈을 산산조각 내주셨죠. 우리는 이미 애자일(agile)을 도입했다고 하네요. 뭐, 소프트웨어를 분기마다 출시하는 그런거 있잖아요...

여전히 중반 . . .

이후 끔찍한 악몽이 시작되었습니다.
고객도 직원도 모두 떠나고 있었습니다. 그나마 남아있던 사람들은 테스트 자동화(automated tests)가 시간 낭비라며 저와 논쟁을 벌였고 그럴때마다 틈틈히 새로운 매니저를 만나 설득해가며 회사에 새로운 바람을 불어넣으려 꾸준히 노력 했습니다. 제가 제안한 아이디어(ideas)가 꾸준한 학습 및 수학 ( 아... 비참합니다. 저는 이게 문제(facts matter)라고 생각한 멍청하고 무식한 놈이에요! ) 을 통해 견고해질수록 관리자들은 매우 지루해하며 다른 관리자에게 떠 넘기기 바빴습니다.
게다가 저는 우리가 왜 분기마다 한번 이상 소프트웨어를 출시해야 하는지 우리 관리팀을 위해 논문까지 공동 집필하기도 했죠. 예전 직장 동료 중 한명은 아직까지 이걸로 저를 비웃긴 합니다만, 자자 각설하고! 이 논문은 MS 워드 템플릿으로 작성했습니다! 페이지(title page) 와 미주(endnotes) 도 있어요! 심지어 도표 및 참고 문헌도 풍성합니다! 흠... 정말 운좋게 저를 돌이켜보니 웃음이 나오더군요. 그도 그럴것이 저같이 불쌍한 멍청이도 좋은 아이디어가 정상까지 도달하려면 적어도 논리적 근거가 필요하다고 생각하게 됐잖아요. 그러던 중 제 아이디어를 진지하게 받아 들인 한 매니저가 이렇게 말했습니다.
“당신이 그렇게 신뢰한다면, 저도 당신의 아이디어를 찬성하는 쪽으로 주장하도록 하죠.”

여전히, 아직도, 여전히 중반 . .

이 시기를 넘기고 나니 일이 좀 나아졌어요. 이후 저는 끝을 모르고 침몰중인 지금 회사를 퇴사한 뒤 더 큰 회사로 이직 하게 됐습니다. 훨씬 큰 곳으로요. 이전 회사는 제가 퇴사할 시점에 인수/합병 및 정리 해고가 이뤄졌고 아주 서서히 사업을 중단 중 이라는 소식이 들려왔습니다. 저는 아주 적당한 시기에 잘 털고 나왔다고 생각했어요. 게다가, 지금 이렇게 큰 회사에 입사했다는 것이 매우 자랑스러웠습니다. 이들은 도메인 주도 설계 (domain-driven design) 및 해커톤(hackathons) 그리고 코드리트릿(code retreats)이 활성화 되어있었어요. 저는 지난 몇달간 정말 행복했습니다. DDD 원리를 활용해 우리 회사의 중요한 코드(code)를 작성할 수 있었고 이는 자연스럽게 회사의 일부가 되었거든요. 이게 끝이 아닙니다. 심지어 우리 회사는 매주 새로운 코드를 운영(production)에 반영까지 했어요! ( 믿겨지나요? )
행복도 잠시, 결국 일이 이상하게 돌아가기 시작했습니다.
제가 여러명의 수석 엔지니어(senior engineers) 가 떠난 팀으로 배치 됐거든요. 이 팀은 최근 중요 고객 데이터를 처리하는 3~4개의 서비스 구현을 아주 빠르게 완료 했습니다! 아니 이건 빠른 정도가 아니라 너무 초고속으로 구현됐어요! 보나마나 코드(code)는.. 역시 엉망징창입니다! 온전한 코드가 거의 없는걸 보니 대부분 새벽 3시 이후 종료 된 모양이에요. 하지만 걱정할거 없어요. 저에겐 기회 에요! 빠른속도라면 저도 뒤지지 않거든요. IoC 컨테이너(containers)에 순환 의존성(dependencies)을 숨기고 스택(stack) 가장 먼곳에 NullPointerExceptions 로 예외(throws) 처리 및 타임존(timezone) 이 뒤죽박죽이 된 시스템 클러스터(syatem clusters) 의 시스템 클럭(system clock) 에 의존해 타임 스탬프(time stamp)를 잡쳐 놓는 아주 새로운 방법을 신속하게 배웠거든요.
presentation
때로는, 꼬인 매듭을 풀어가는게 코딩의 전부에요.

몇주 동안, 엉킨 코드를 풀고 매듭 지었습니다. 매듭 목록이 거의 마무리 될 즈음 또다른 업무가 떨어졌네요. “클라우드(the cloud)” 라는 광풍이 지나가니 높으신 분 중 누군가 클라우드 광신도가(drank cloud Kool-Aid) 되 버리셨거든요. 이거 정말 큰일입니다! 이 서비스들은 클라우드가 전혀 고려되지 않았거든요. 뭐가됐든 이미 이 업무를 “2분기(By Q2)” 까지 반영하도록 할당 받았습니다. 이를두고 일부 엔지니어들은 제공중인 서비스(services)를 “현 상태 (as is)” 그대로 클라우드에 올리면 큰 고통이 따를 것이라 주장했습니다. 결국 “이대로 옮기자!” 부터 “처음부터 다시 시작하자!” 까지 여러 완강한 주장의 대립으로 이어졌죠.
특히나 후자 그룹은 잡음이 많았습니다. “클라우드” 가 엔지니어들을 스쳐가니 “반응성(reactive)”, “서버리스(serverless)”, “CORS(Cross-Origin Resource Sharing)” 가 판치기 시작했습니다. 그도 그럴것이 그들은 이미 클라우드를 동경하고 꿈꿔왔으니까요.
이 문제를 어떻게 해결해야 했을까요? 혹시, 앞서 언급한 멍청하고 무식한게 문제(facts matter) 라는 말 기억하시나요? 그래요... 저는 잘못 배웠던거에요. 타협할 수 있다고 생각했거든요. 어쨋든 저는 이 난관을 엔지니어, 매니저 모두 합심해 해쳐 나갈수 있게 설득하려고 많은 노력을 했습니다. 그래요. 이번엔 왠지 정말 다를거라 생각했거든요.
하지만, 제 생각처럼 되진 않더군요.
상황이 진정된 후 매니저는 고민없이 “리프트 앤 쉬프트 (list and shift)” 을 지시했고 저는 결국 다른 직장을 찾아야했습니다.

끝이냐고요? 아니죠! 여전히 중반입니다...

뭐 어쨌든, 저처럼! 수천가지 방법으로 잘못된 소프트웨어를 배운 사람은 모든 기술을 남보다 더 빨리 습득할 겁니다. 저를 교훈 삼으셔야해요! 저는 수천명의 삶을 살아왔거든요. 그럼 여기서 제가 배운 가장 큰 교훈은 무엇일까요? 그건 바로 모두 잘못하고 있어요 (Everyone is doing it wrong). 이 교훈은 제 경험을 토대로 작성한 책 제목이 될 겁입니다. 돌이켜면 제가 지나온 길이 결코 참되고 올바른길이 아니란걸 알 수 있을만큼 나이든 것 같네요! 여러분, 저 뿐만 아니라 여러분 모두 잘못하고 있어요.
만약 여러분이 이에 대해 계속 논쟁을 하고 싶다면, 당연히 하셔야죠, https://www.whitehouse.gov/contact 방문하셔서 모든 불만 사항을 제출하세요. 분명 높으신 분들이 이를 읽고 무엇을 해야할지 알 것이라 확신하거든요.
자, 이제 여러분이 원한다면, “나는 어떻게 CS 시작 후 5분만에 가장 훌륭한 외판원 순회(traveling salesman) 알고리즘을 작성했는가” 또는 “나는 어떻게 외발자전거를 타며 머리위로 저글링을 하면서 수십억 달러 규모의 스타트업을 구축했을까” 같은 환상적인 글들을 만나보세요. 이런 글을 접하고 적당한 현실 도피는 결코 그 누구에게도 피해를 주지 않으니까요.


이글은 번역글입니다.
원문은 아래를 참고 바랍니다.