[쏘카 류석문 CTO] 회사가 망하길 바라는 개발자를 위한 팁

본 포스트는 쏘카 류석문 CTO께서 링크드인을 통해 올려주시는 재미있는 팁들을 정리한 페이지입니다.

저의 지분은 단지 단편적으로 올라오는 CTO님의 팁을 한군데로 모아놓을 뿐입니다.

회사의 주가를 하락시키는 둘리가 되어보자..!

다음 팁들을 따라하시면 그림처럼 회사의 주가를 하락시키는 둘리가 될 수 있어요!

우리 모두 열심히 숙지하고 회사를 망하게 해봅시다...ㅎㅎ

---

Tip1

기존 코드를 복사&붙여넣기 하고 조금만 변경하세요. 이렇게 만들어진 중복코드는 다른 개발자의 시간을 낭비 시키고 유지보수 비용을 높여 조직 전체의 생산성을 낮춥니다. 해당 코드에 버그가 있다면 금상첨화. 한 곳 고치고 안도하다 여기저기 널린 비슷한 코드 때문에 유사 장애가 꾸준히 발생합니다. 당연히 고객 신뢰는 빠이빠이. 제대로 망할 수 있습니다.

Tip2

이름을 개떡 같이 지으세요. temp1, temp2 같이 맥락 없는 이름은 코드 가독성을 낮추어 개발자의 생산성을 저하 시킵니다. 비슷한 의미를 가진 단어를 섞어 쓰면 효과가 더 좋습니다. 어디에선 user 어디에다간 customer로 쓰면 뭘 불러야 할지 헷갈리다 실수하게 만듭니다. 다른 개발자가 뭐라 하던 내 스타일로 작성하면 혼자서도 코드베이스 전체를 망칠 수 있습니다.

Tip3

함수의 파라미터는 일관성 없게 만드세요. getInfo(string name, string address), setInfo(string address, string name) 처럼 같은 타입의 파라미터라면 효과가 좋습니다. 변수이름을 의미 없는 p1, p2 처럼 쓰면 더 좋습니다.
디폴트값이 있는 파라미터를 여러개 만드는 것도 아주 좋은 선택입니다. 어떻게 사용할지 모르는 개발자는 기본값으로 호출할 테고 개발자 테스트는 통과 하지만 예외는 고려 못할거라 사용자가 버그를 발견하게 만들 수 있습니다. 역시나 합법적으로 회사를 망하게 할 수 있습니다.

Tip4

장애 상황에 빠르게 대응하고 싶다면 코드 수정을 실서비스 환경에서 하세요. 언제 무슨 목적으로 변경했는지 이력이 남지 않아 혼자만의 비밀로 간직할 수 있습니다. 이후 누군가 버전관리 시스템에서 배포를 하면 변경 내용이 날아가 버려 다시 장애가 발생합니다. 배포한 개발자가 패닉이 되는건 덤입니다. 개발자 간 신뢰는 사라지고 그런 회사는 오래 못갑니다.

Tip5

예외가 발생하면 지저분하죠? 반면 모든 예외를 무시하면 출력창도 깨끗하고 보기에 좋습니다. 머리 파묻은 타조 처럼 모르면 됩니다. 다른 개발자도 모르니 문제는 발견하기도 어렵고 가끔씩 이상하다는 고객의 불만은 신뢰도 저하로 나타납니다. 다른 방법으로는 모든 예외를 전파하면 됩니다. 예외 처리를 호출한 사람한테 맡기니 코드에는 어찌 처리해야 할지 모르는 예외를 처리하느라 잘못 쓰인 방어코드가 넘쳐나게 됩니다. 지저분하고 불필요한 코드만 생산하는 회사는 당연히 망하게 되고요.

Tip6

코드리뷰를 받지 마세요. 변경 내용을 나만 알고 있어야 장애도 나만 해결할 수 있습니다. 혼자 변경 하고 바로 커밋하면 됩니다. 다른 개발자의 코드리뷰 요청은 무시하거나 온갖 비난과 사소한 꼬투리를 잡으며 상대의 기분을 나쁘게 하면 됩니다. 당연히 모든 사람이 코드리뷰를 안하게 되고 장애 대응이 오래 걸리니 고객 불만은 하늘을 찌르고 개발자간 상호불신도 커집니다. 그 결과는 당연히 망합니다.

Tip7

잘못된 설계를 봐도 그 안에서 해결책을 찾으세요. 예를 들어 유효기간이 정해진 자료를 삭제하지 않으면 의미 없는 여러자료를 뒤져 유효한 값을 찾아내는 불필요한 로직이 생겨납니다. 시간이 지날 수록 속도는 느려지는데 그걸 빠르게 하겠다고 검색방법을 개선하는 또다른 불필요한 일을 하게 만들 수 있습니다. 그걸 왜 해야하는지 고민하지 않는 개발자들은 점점 더 복잡하게 비효율을 최선을 다해 만들어 냅니다. 운이 좋아 비즈니스가 잘되도 확장 가능하지 않은 시스템은 성장 속도를 따라가지 못합니다. 어떻게 되냐고요? 망합니다.

Tip8

자신이 개발한 기능의 검증은 모두 QA에게 맡기세요. 그러라고 QA가 있는거라 우기세요. 당연히 동작해야 할 기능이 동작하지 않는 상황이니 QA는 개발자가 무한히 만들어내는 버그를 찾다 지칩니다. 그 와중에 개발자는 버그를 고치느라 바쁘게 일하며 많은 버그를 수정한 유능한 사람이라 포장할 수 있고 스스로 할 일을 무한히 증식 시킬 수 있습니다. 회사의 모든 자원을 자신이 지속적으로 만들어내는 버그에 매몰 시킬 수 있습니다. 게다가 다들 바빠서 번아웃되는 것은 덤입니다. 원수 자식이 가도 한번은 말리고 싶은 회사로 만들 수 있습니다.

Tip9

개발은 손 맛이죠. 모든 반복 작업은 손으로 해야 확실합니다. 반복적으로 디버거를 켜고, 반복적으로 리그레션 테스트를 손으로 하세요. 그리고 모든 사람이 그렇게 하도록 전파하세요. 자동화테스트는 수동 테스트 하느라 너무 바빠서 만들 시간이 없다고 하세요. 리그레션 오류가 발생하면 테스트가 불충분했다고 더 많은 수동테스트와 확인 단계를 만들겠다고 하세요. 세상에서 가장 비효율적이고 느린 개발 프로세스를 갖춘 회사로 만들 수 있습니다. 결과는요? 망하죠.

Tip10

자동화 테스트는 통합테스트가 최고라고 우기세요. 모든 시스템이 다 같이 동작해야 실제 검증이 되는 거니 네트워크도 개입 시키고 DB도 개입 시키세요. 가끔 타임아웃이 나는 경우는 네트워크가 불안정해서였다고 신경 쓰지 않아도 된다고 하세요. 자동화 테스트가 깨질 때 다른 시스템이 잠시 불안정해서 였다고 핑계를 대면 됩니다. 그 순간부터 누구도 깨진 테스트에 관심을 갖지 않게 됩니다. 엄청난 자원을 낭비 시킬 수 있고 버그를 발견하지 못하게 만들 수 있습니다. 테스트 시간이 오래 걸릴 수록 좋습니다. 테스트를 기다리다 지친 개발자는 딴짓을 하거나 테스트를 실행 안하게 될 것이고 버그가 발생할 확률은 더 높아 집니다. 곧 망할 일만 남습니다.

Tip11

무조건 다 할 수 있다고 하세요. 최후의 순간까지 최선을 다한 뒤 못했다고 하면 됩니다. 의존성 있는 업무를 하던 모든 사람의 시간을 낭비 시킬 수 있어요. 누군가 문제 제기를 하면 최선을 다하다 못한 건데 그런 것을 비난한다며 열정 없는 사람이라고 쏘아 붙이세요. 결국 완성에 가깝지만 동작하지 않는 기능 천지가 되고 회사는 망합니다.

Tip12

한번에 여러가지 일을 하세요. 이거했다 저거했다 자주 바꿀 수록 좋습니다. 50%, 90% 완성도로 여러일을 하며 하나도 끝내지 않으면 최고입니다. 자원은 최대한 끌어쓰고 고객에게는 단 한가지도 줄 수 없습니다. 회사는 돈 벌 방법은 없고 돈만 쓰는 상황이 됩니다. 어찌 버텨요 망해야지.

Tip13

아무데도 쓰이지 않는 데드코드를 만드세요. 아이디어가 넘쳐나니 미래를 예측하여 미리 만들어둔 코드라고 우기면 됩니다. 불리는 데가 없으니 장애를 일으킬 없어 다들 무시할거라 걸릴 위험도 낮습니다. 그런데 코드를 읽어야 하는 개발자는 데드코드인지 모르니 읽느라 시간 낭비를 합니다. 그런 시간이 쌓이고 쌓이면 엄청난 낭비를 만들어 낼 수 있습니다. 오랜 시간 천천히 치명상을 입힐 수 있는 비기입니다.

Tip14

정성스럽게 코멘트를 다세요. 코드가 복잡하면 더 효과가 좋습니다. 코드만 보고 이해가 안되니 코멘트를 읽느라 시간을 낭비하게 됩니다. 그리고 코드는 계속 변하지만 코멘트는 처음 쓰여진 상태로 남게 됩니다. 이때 부터 진가가 발휘됩니다. 코멘트를 읽느라 시간을 썼지만 코드와 내용이 다르니 코멘트 잘못인지 코드가 잘못인지 헷갈립니다. 이걸 코드를 보는 모든 개발자가 겪게 할 수 있습니다. 코멘트가 상세하면 할수록 신뢰도가 높아 안읽고는 못 배깁니다. 회사를 망하게할 뿐 아니라 타인의 인생도 낭비시킬 수 있는 최고의 무기입니다.

Tip15

통합개발환경 기능은 복사 붙여넣기만 쓰세요. undo, redo 까지는 써도 됩니다. 나머진 쓸데 없이 뭘 그리 만들었냐고 무시합니다. 변수이름 바꿔야 하면 검색해서 하나씩 하나씩 바꿉니다. 인생은 길고 뭐라도 할 일이 있어야 하니 1970년대 개발 하는 방법 그대로 전통을 지키는 일이라 자랑스럽게 생각해도 됩니다. 나 혼자 느린거니 별로 영향이 없다고 실망할 수 있지만 조직은 참으로 기묘해서 한명이 이 난리를 치면 다른 사람들도 비슷한 수준의 난리를 치게 됩니다. 그럼 어쩌겠어요 망하겠죠.

Tip16

얼리어댑터도 느리고 시대에 뒤쳐진다며 언제나 최신 기술의 최전선에 있어야 한다고 주장하세요. 새로 나온 기술을 실 서비스에 바로 적용하고 이런 일을 논의 없이 혼자 마음대로 할 수 있는 문화를 만들면 됩니다. 기술 선택이 자유로운게 개발자를 위한 최고의 문화라고 주장하며 실천하면 됩니다. 기술 스택은 조각 나고 관리와 유지보수가 불가능한 상태가 됩니다. 그게 뭐냐고요? 망한다는 이야기입니다.

Tip17

개발자라면 모름지기 최고의 기술력을 뽐내야 합니다. 비즈니스가 아무리 빨리 성장해도 선형으로 확장 가능한 서비스를 디자인 할 수 있어야 한다고 그러기 위해 뛰어난 실력의 개발자가 필요한거라고 주장하세요. 대규모 설계를 한번에 끝낼 수 있다며 엄청난 서비스를 만들 수 있다며 오랜 시간을 쓰세요. 고객에게 아무런 기능도 제공하지 못하고, 시간은 흘러 흘러 서비스가 시장상황에 맞는지도 알 수 없게 되고, 뭔가 많이 만든 것 같은데 쓸 수 있는 것은 하나도 없게될 때 즈음이면 회사는 자금 압박에 시달리게 됩니다. 오버엔지니어링에 몰두 할 수도록 빠르게 망하게 할 수 있습니다.

Tip18

의존성을 외부에서 통제할 수 없게 만드세요. 의존성주입(Dependecy Injection)은 생성을 어렵게 만들어 생산성을 낮춘다고 주장하세요. 의존성을 테스트 할 수 없게 되어 버그가 창궐하고, 문제가 발생해도 누가 작성한 코드에서 발생한건지 식별하기 어렵고, 자동화 테스트를 작성할 수 없으니 디버거를 켜는 개발자가 늘어나게 됩니다. 아주 효과적으로 생산성을 망칠 수 있습니다.

Tip19

조건문을 복잡하게 만드세요. &&, || 연산을 여러개 붙이고 괄호로 감싼 다음에 !을 붙이면 최상입니다. 아주 손쉽게 개발자의 실수를 유도할 수 있습니다. 조건문을 별도의 함수로 만드는 일은 불필요한 함수를 늘리는 일이고 조건문도 제대로 이해 못하는 역량이 낮은 개발자라 주장하세요. 코드 가독성이 낮아지며 생산성은 저세상으로 보낼 수 있습니다. 중복코드도 많이 생겨나니 망하게 하는데 이보다 좋은 방법이 없습니다.

Tip20

함수 하나가 여러 기능을 하게 만드세요. 파라미터로 조정해서 여러가지를 처리하면 코드를 효과적으로 활용하는 거라고 주장하세요. 함수는 자연스레 커질테고 내부에 조건문이 많아지며 가독성은 최악이 되니 어찌아니 좋겠습니까. 물론 회사를 망하게 하는데요. 유지보수하기 어려우니 실수하는 개발자가 늘어나고 실 서비스에는 언제나 버그가 득시글 거립니다. 어느 한명이 그런 함수를 만들기 시작하면 이후에 그 코드를 보고 원래 이런갑다 하고 무지성으로 따라하는 개발자가 조직에 늘어나며 생산성은 지수적으로 감소합니다. 어찌 버티겠어요 망해야지.

Tip21

코드 품질이 나쁘면 리팩토링을 해야죠. 기왕 하는 김에 왕창 크게 하자고 하세요. 몇개월 단위면 좋습니다. 회귀오류를 확인할 방법은 만들지 마세요. 그러면 엄청나게 많은 버그가 나오고 예전에 되던 것도 안되는 서비스가 만들어집니다. 코드 품질도 당연히 좋아지지 않습니다. 비즈니스에 아무런 도움도 안주면서 몇개월을 낭비했으니 회사가 이걸 버티면 체력 좋은 겁니다. 그럴 때는 몇번 더 하면 됩니다. 이걸 지속적으로 버틸 회사는 없거든요.

Tip22

중첩은 많을수록 좋습니다. for, while 안에 다시 loop가 들어가고 if 구문이 들어가고 break로 루프를 자주 탈출 시키면 코드를 이해할 수 없게 됩니다. 복잡하다 보니 compose method로 분리하기 어렵고 그러다 보니 비슷한 코드가 여기저기 생겨납니다. 이렇게 어려운 로직은 뛰어난 개발자만 작성할 수 있는 거라 우기고 중첩에 중첩을 더하세요. 회사의 앞날은 첩첩산중이 됩니다.

Tip23

개성의 시대에 맞게 자신의 개성이 듬뿍 풍겨나는 코드를 작성하세요. 누가봐도 한눈에 작성자를 구분할 수 있으면 좋습니다. 공동 작업에서 각자의 스타일이 혼재된 명품을 만들 수 있습니다. 가독성은 저세상으로 가버리고 사람이 늘수록 다양성이 추가 되니 점점 더 혼란스러워 집니다. 뭐라 하는 사람이 있다면 다양성과 포용의 가치를 모르고 하는 소리라 쏘아붙이세요. 넘쳐나는 개성 만큼이나 회사의 상황도 파란만장해 집니다.

Tip24

빡빡한 코드리뷰 체크리스트를 만들고 꾸준히 추가 하세요. 리스트가 길수록 좋습니다. 결국 아무도 체크리스트에 관심을 두지 않게 되고 코드리뷰는 서로의 주장을 날카롭게 겨루는 대결의 장이 됩니다. 상호신뢰는 산산조각 나고 열심히 코드리뷰를 할 수록 상황은 악화됩니다. 내 리뷰를 통과하지 못하면 커밋은 불가능하다며 장판교 장비처럼 굴수 있으면 더 좋습니다. 회사 네트워크 트래픽의 대부분이 구직 사이트 접속이 되게 만들 수 있습니다.

Tip25

assert가 없는 테스트를 만들고 코드 커버리지를 측정하세요. 테스트가 깨질 일 없고 코드 커버리지는 높아 보여 코드 품질이 높다는 착각을 하게 만듭니다. 테스트 실행 속도가 느리면 기다리느라 많은 시간을 낭비 시킬 수 있어 더욱 효과적입니다. 이걸 따라하는 개발자가 늘어날수록 회사는 빨리 망합니다.

Tip26

테스트 환경과 실환경이 다르게 만드세요. 별 신경 안쓰면 저절로 달라지므로 실천하기도 쉽습니다. 모든 문제는 고객이 발견하게 되고 내부에선 재현도 할 수 없어 낭비란 낭비는 다 유도할 수 있습니다. 개발자는 바쁘지만 쓸데 없이 바쁘기만 할 뿐 문제는 해결하지 못하고 고객 가치는 구현할 수 없습니다. 그럼 어찌될까요? 망해야죠.

Tip27

배포는 아무 때나 하세요. 고객에게 가능한 빨리 기능을 제공하는게 좋으니 그래야 한다고 설득하면 됩니다. 배포가 중첩되면 문제 원인도 파악 못하고 서비스는 항상 일부 장애 상태가 됩니다. 롤백도 할 수 없으니 여러 추정이 난무하며 개발자들은 당연히 되야할 일이 안되는 것을 해결하느라 시간 낭비를 하게 됩니다. 고객은 알아서 떠날테니 효과가 좋습니다. 안망하고는 못배깁니다.

Tip28

코드리뷰는 버그를 찾는 일이라고 주장하세요. 버그를 찾기 위해 엄청난 시간을 쓰게 만들면 효과적입니다. 코드의 유지보수성, 가독성은 무시하세요. 코드리뷰에서 버그가 많이 발견되는 것을 리뷰를 잘해서라고 칭찬하세요. 버그를 많이 만들어내는 개발자가 어떤 어려움에 처해있는지 관심을 갖지 않으면 코드리뷰는 매우 잘동작하는 우수한 방법으로 오인됩니다. 시간이 지날수록 코드 품질은 나빠지고 개발자의 시간은 버그 찾는데 낭비됩니다. 낭비는 언제나 망하는 지름길이니 제대로 가고 있는 겁니다.

Tip29

코드리뷰 코멘트를 공격적으로 남기세요. “이거 이러면 안됩니다.”, “몰라서 그런 모양인데", “이런식으로 해야 효과적인데 이것도 몰랐나요"와 같은 코멘트를 받은 개발자는 되갚아줄 기회를 노리게 되고 코드리뷰는 인신공격과 사소한 것에 모두가 달려들어 서로를 죽이려 드는 결투장으로 변합니다. 당연히 협업은 멀어지고 상호불신만 가득 피어납니다. 이런 사람들끼리 무슨 일이 되겠어요. 그냥 망하는거죠.

Tip30

switch 문은 복잡한 처리를 일목요연하게 정리할 수 있는 좋은 수단이니 여러개를 사용하세요. 다형성은 불필요하게 클래스를 만들어 내서 코드를 읽기 어렵게 만드는 원인이라고 주장하세요. 그렇게 만들어진 swtich문은 시간이 갈수록 커지고 커지고 커져서 유지보수 하기가 어려워집니다. 그리고 교묘하게 중복되는 코드가 늘어나는데 마땅히 처리할 방법이 없어 공통 코드로 뽑아 보겠다고 섣불리 도전했다 버그만 잔뜩 만들고 실패하는 개발자가 늘어 납니다. 결국 누구도 손대지 말라는 경고가 붙게 되고 개발 속도를 늦추는 주범이 됩니다. 코드베이스에 이런 괴물이 늘어나면 망하기 좋은 조건이 됩니다.

Tip31

기술은 성숙도가 높은 오래된 것을 사용해야 안정적인 서비스가 가능하다며 현재 사용중인 기술만을 고집하세요. 문제를 해결하는 방법이 바뀌고 세상은 빠르게 변하지만 독야청청 세상 흐름과 상관 없이 옛것을 지키며 전통을 유지하는 개발자가 되세요. 프레임워크는 공식지원이 종료된 것을 유지하면 보안 문제등 다양한 위협에 노출 되기에 더욱 좋습니다. 업그레이드를 해야 한다는 주장이 들리면 버전 차이가 커서 동작하지 않는 코드가 많아 위험하다고 막으면 됩니다. 옛날 기술만 집착하다 보면 다른 개발자들 조차 성장하지 못하게 할 수 있으니 타인의 인생도 함께 망칠 수 있습니다. 회사는 말할 것도 없고요.

Tip32

코드리뷰는 모두가 함께 모여 오프라인에서 하는게 효과적이라고 하세요. 오래 하면 더 효과적으로 개발자의 시간을 낭비할 수 있습니다. 그렇게 모여 서로에게 날선 비난을 주고 받으면 조직 문화는 신문 기사에 나도 이상할 것 없을 정도로 나빠집니다. 조직 내에 공유하는 문화는 자취를 감추고 모두가 상처 받지 않기 위해 홀로 일하게 됩니다. 망하기 딱 좋은 환경입니다.

Tip33

장애를 어떻게 해결 했는지 알리지 마세요. 얼마나 창피한 일이에요 얼른 숨기고 모른척 하는게 최선입니다. 많은 비용을 지불했으나 실수에서 조직이 배울 수 없으니 비슷한 장애는 꾸준히 발생합니다. 나만 당할 수는 없으니 타인도 실수하는 것을 보며 나만 그런게 아니라고 위안 삼으세요. 괜히 실수한 내용을 공개했다 남들에게 비난을 들을 필요는 없다고 합리화 하면 됩니다. 혹시라도 누가 물어보면 별거 아니라고 알 필요 없다고 하면 됩니다.

Tip34

기획 의도를 묻지 마세요. 어련히 알아서 잘 했겠지 생각 하거나 말해봐야 입만 아프지 하며 외면하면 됩니다. 제품에 대한 이해도가 높은 개발자가 대안을 제시하지 않고 기획자의 말을 무조건 수용하면 마찰 없이 빨리 제품을 만들 수 있고 주변에서 협조적인 사람이라는 평판을 얻을 수 있습니다. 그러는 사이 제품은 기획자 홀로 책임져야 할 대상이되어 발전하지 못합니다. 내부 구현을 모르는 기획자가 이런저런 기능을 추가하며 구조가 복잡해지며 신규 기능 추가는 점점 어려워집니다. 그렇게 점점 끝이 다가오게 됩니다.

Tip35

새로운 시도를 해보자는 이야기가 나오면 예전 하던 방식대로 해야 한다고 주장하세요. 새로운 시도를 하다 실수가 나오면 “거봐 그럴줄 알았어. 내가 하던 대로 하자는 말 안듣더니 꼴 좋다"라고 비난하세요. 그이후로는 누구도 개선을 위한 시도를 하지 않고 그저 하던대로 하면서 세상이 앞서나가는데 홀로 엎드려 버티는 조직을 만들 수 있어요. 엎드려 있기만 해도 살아 남으면 다행인데 세상은 그렇게 친절하지 않아요. 한때 잘 나갔다는 소리를 술안주로 올리며 사는 초라한 회사를 다닐 수 있게 됩니다. 뭔 소리냐고요? 망했단 이야기죠.

Tip36

많은 사람이 참여하는 회의를 잡으세요. 애매하다 싶으면 다 부르면 됩니다. 무엇을 논의할지 뾰족하게 정리하지 못한 상태로 두서없이 이야기를 하면 모든 사람의 시간을 낭비 시킬 수 있습니다. 관련 없는 회의에 불려 간 경우라면 그냥 아무소리 없이 앉아 계세요. 관련 없으니 나가겠다고 말해 눈총 받을 필요 없습니다. 회의는 아무 소득 없이 끝날 것이고 그런 종류의 회의는 지속적으로 잡힐 거에요. 회의 하느라 일할 시간이 없는 신기한 일을 겪게 될텐데 그럴수록 회사도 망하는 신기한 경험을 하게 됩니다.

Tip37

누군가 질문을 하면 해보지도 않고 물어 본다고 타박 하세요. 스스로 하고 있는 사람에게는 왜 묻지도 않고 마음대로 하냐고 타박하세요. 잘한 일에는 당연한 걸 뭘 칭찬 하냐고 말하고 잘못된 일에는 그 사람 개인의 문제로 몰아 가세요. 이렇게 구는 사람을 조직에 방치하고 나아가 상위 리더의 신뢰를 받는 모범사례로 만드세요. 지옥이 회사에 강림하는 장면을 목격할 수 있습니다.

Tip38

클래스를 상호순환참조 시키세요. 클래스 두 개로 하면 너무 쉽게 티가 난다 싶으면 여러 클래스를 거쳐 삥삥 돌리면 됩니다. 유지보수 하기는 어려워 지고 닭이 먼저인지 달걀이 먼저인지 심오한 고찰을 하느라 개발자의 시간을 낭비할 수 있으며 의도치 않은 버그는 덤입니다. 빙글빙글 도는 상황에 회사가 멀쩡할리 없습니다.

Tip39

트래픽이 낮을 때는 높은 트래픽을 감당할 걱정을 하고 트래픽이 높을 때는 새로운 기능 출시를 고집하세요. 트래픽 없을 때는 오버엔지니어링 하느라 고객 가치를 못 만들고 트래픽이 높을 때는 감당을 못해 고객 가치를 못 만듭니다. 트래픽 감당도 못하면서 새로운 기능 추가한다고 노력 하면 잘도 망하게 됩니다. 트래픽 낮을때 오버엔지니어링 하면 필요한 기능을 제때 제공 못하니 서비스가 커보기도 전에 사망선고를 받게 할 수 있습니다.

Tip40

고객 관련 정보를 누구나 접근할 수 있게 암호화 하지 마세요. 어차피 사내에서만 접근 가능한거니 안전하다 우기면 됩니다. 그러면 망하는 정도가 아니라 법적 책임지고 구속 될 수 있습니다. 정보보안팀은 귀찮은 존재라 여기고 맘대로 편리한 방법을 쓰면 됩니다. 지금까지는 회사만 망하는 건데 이건 개인도 같이 망합니다.

Tip41

함수의 파라미터 리스트는 길게 만드세요. 한번에 다 처리할 수 있으니 얼마나 좋아요. 함수는 여러 기능을 할 것이고 긴 파라미터 리스트를 어떻게 채워야 할지 모르는 개발자는 헤맬 것이고 함수를 부를 때 마다 파라미터 리스트를 채우느라 진절머리를 치며 개발 속도는 계속 느려질 것입니다. 매개변수에 따라 동작이 달라지는 함수라면 실수해서 버그 만들기 딱 좋습니다. 이런 문제를 피하겠다고 파라미터 클래스를 만드는 일은 불필요한 클래스를 생성하는 일이니 가능한 피해야 한다고 주장하면 됩니다. 그래도 파라미터 클래스를 만들게 되었다면 속성이 달라질 때 마다 새로운 클래스로 만들어 버리세요. 다형성 따위 누가 신경이나 쓰겠어요? 그냥 그런가 보다 하고 데이터 저장 용도로 사용하고 버려지는 무수한 클래스를 생산 하고 유지보수하느라 회사 자원을 왕창 낭비시킬 수 있습니다. 코드 베이스는 산소호흡기 겨우 붙어 있는 상태가 됩니다. 회사도 그렇게 될 것이고요.

Tip42

테스트의 실행 순서를 만드세요. 꼭 먼저 실행 해야만 되는 테스트를 만들어 두면 실행 순서를 바꿨다가 테스트가 깨지는 경험을 하게 만들 수 있습니다. 테스트 사이에 강한 결합이 생기고 실수 하기 좋으니 슬슬 테스트가 깨져도 누구도 신경을 쓰지 않게 되며 이후에는 테스트를 무시하고 작성하지 않게 됩니다. 코드 품질은 당연히 나락으로 가죠. 실천 방법은 쉽습니다.어떤 테스트의 수행결과를 이어 받아 테스트를 하게 만드세요. 단위 테스트에 DB 같은 자원을 활용하면 됩니다. 테스트 제대로 만들던 사람마저 포기하게 만들 수 있습니다.

Tip43

테스트가 깨지면 주석 처리 해버리세요. 테스트 수정은 생산성 있는 일이 아니라 치부해 버리면 됩니다. Junit 4의 Ignore, Junit 5의 Disabled 어노테이션을 자주 사용하면 됩니다. 젖과 꿀이 흐르던 코드도 순식간에 황폐화 시킬 수 있고 저런 어노테이션이 있는 줄 몰랐던 개발자가 너도나도 가져다 쓰기 시작하면 일상의 노력으로 회복 불가능한 수준이 됩니다. 이때 코드품질을 높이기 위해 몇개월간의 리팩토링을 하겠다 선언하면 치명타가 됩니다. 그 코드베이스에서는 풀한포기 자라지 못하게 될테니까요.

Tip44

한군데 밖에 쓰이는 곳이 없는 변수를 그대로 방치하세요. 인라인으로 처리하면 어렵게 작성한 변수가 하나 날아가 버리니 얼마나 아까워요? 문법적으로도 완벽하고, 오류가 날 일도 없고, 혹시나 변수가 필요한 미래가 오면 활용할 수 있으니 주의 깊게 대응하는거라 주장하세요. 하지만 인간은 미래 추정에 취약하기에 생각한 미래는 오지 않고 코드는 지저분한 상태로 남게 됩니다. 별거 아닌 것 같지만 깨진 유리창 효과를 유발할 수 있어 누구도 깨끗한 코드를 추가 하지 않고 마음대로 어질러도 좋은 곳이라 생각하며 난장판을 만듭니다. 사소하게 출발하지만 그 끝은 멸망으로 대단하게 됩니다.

Tip45

배포는 중요한 일이니 전문 담당자를 배정해서 처리하세요. 장인이 한땀한땀 수동배포하고, 이것저것 체크해야 하고, 비숙련자가 하면 바로 장애가 나는 고도의 집중력을 요하는 작업으로 만들면 됩니다. 배포담당자는 전문가 대우를 받을테고 그사람 없이는 배포도 못하니 24시간 상시대기조로 살아야합니다. 중요한 사람으로 대우 받는 거니 그쯤은 참아야죠. 덕분에 배포는 어려운 일이 되어 자주 안할테니 고객가치 전달은 늦어지고, 장애대응도 늦어지고, 회사 성장은 늦어지는게 아니라 못하게 됩니다. 버튼 하나 눌러 누구나 배포할 수 있게되면 개나소나 배포하다 큰장애가 날수 있다고 하면 됩니다. 그런 말이 통할 정도면 빨리 망하기 좋은 곳입니다.

Tip46

사용자가 갑자기 늘어 서비스가 불통이 되었을 때 자랑하고 마케팅 용도로 사용하세요. 급작스러운 사용자 증가에 대응하는 것은 평소에 낭비를 유발하므로 어쩔 수 없다고 하면 됩니다. 늘어난 트래픽에 대응하기 위해 아키텍쳐의 대대적인 수정이 필요하다며 리팩터링 몇개월 하겠다고주장하는 기회로 활용하세요. 성능테스트는 장애 분석에나 사용하고 전문가만 하는 일이라 하면 됩니다. 장사가 안될 때는 안되서 망하고 잘되려고 할 때는 대응을 못해서 망하니 이래저래 망하기 딱입니다. 무조건 높은 트래픽을 예상하고 인프라를 과다 투자하여 평소에 자원을 낭비하는 것도 좋습니다. 돈을 못 벌면서 펑펑 쓰기만 하니 안망하면 이상한겁니다.

Tip47

전역변수를 많이 사용하세요. 필요하면 언제 어디서나 손쉽게 접근 가능하니 개발 하기가 매우 편해집니다. 그 결과 이 놈의 것을 어디서 갑자기 바꾼건지 알 수 없게 되고 버그가 발생하면 찾아 내느라 많은 시간을 헤매게 됩니다. 값을 설정하고 읽는 함수로 땜빵을 해두면 디버거나 로그로 어디서 바꾸는지는 적어도 확인할 수 있으나 디버거 켜서 매번 확인하고 눈이 빠져라 로그를 쳐다 보고 있다면 개발 생산성은 지옥에 간 상태입니다. 전역변수가 아닌 클래스 변수, 싱글톤을 사용 중이니 별 상관 없다고 생각 한다면 좋습니다. 제대로 망해가고 있는 것이니까요. 클래스는 덩치가 커지기 십상이고 우주 전체는 아니더라도 은하계 내에서 뭔가를 발견하느라 헤매고 있다면 효과는 동일합니다. 싱글톤은 테스트 하기도 어렵고 번거로우니 어찌 아니 좋겠어요. 물론 망하는데 말입니다.

Tip48

자신이 개발하는 서비스를 이용하지 마세요. 돈 벌려고 어쩔 수 없이 하는 일인데 뭐하러 사용을 하겠어요. 기획자가 만들라고 하는대로 만들어 주기만 하면 할일 다한거죠. 서비스를 이용 안하니 고객이 뭘 불편해 해도 공감도 못할 것이고 개선사항을 스스로 찾아내는 일도 없으니 그냥 남이 시키는 일만 하며 살게 됩니다. 만든 사람도 관심 없어 하는 서비스를 사랑해줄 고객은 없으니 회사는 망할테고 남이 시키는 일만 하느라 개인성장도 못할테니 개인도 망하는 일석이조입니다. 회사는 다른 개발자를 뽑거나 투자를 받거나 망해도 그만인데 개인의 삶 특히 성장하지 못한 개인은 복구할 방법도 없어 제대로 도태될 수 있습니다.

Tip49

예전 코드가 지저분해도 잘 동작하고 있다면 방치하세요. 괜히 이름 바꾸거나, 메소드 시그니처 바꾸다 실수하면 문제만 생기니까 아무리 지저분해도 동작하면 방치하면 됩니다. IDE에서 제공하는 자동화 리팩토링 도구는 사용할 줄 모르고 눌러 본적도 없으니 무시하면 됩니다. Rename을 이용해서 안전하게 레퍼런스까지 다 바꿀 수 있고, Change Method Signature를 이용해 메소드 이름 부터 파라미터, 리턴타입까지 안전하게 변경하고 레퍼런스까지 바꿀 수 있지만 사용하지 마세요. 어쩔 수 없이 바꿔야 하는 상황이면 찾기 해서 한땀한땀 바꾸다 실수하면 됩니다. 누군가 개선 작업을 하려고 하면 “그거 내가 해봤는데 괜히 실수해서 곤란해지기나 하니까 하지마"하면 조직 전체를 망칠 수도 있습니다. 시간이 지날수록 망할 이유만 늘어나게 됩니다.

Tip50

여러 클래스에 중복 코드가 발견되면 OOP의 목적에 맞게 개발한 거라 우기세요. 슈퍼클래스를 만들어 상속관계를 만들거나 인터페이스를 이용해 언제나 적합한 클래스로 대체할 수 있게 만드는 것은 불필요한 자유도를 주어 헷갈리기만 하다고 주장하면 됩니다. 클래스들은 계속 쓸데 없이 비대해 질테고 개발 생산성은 그만큼 낮아집니다.

Tip51

코드를 읽는 개발자가 유추하게 만드세요. 읽고 이해하는게 아니라 추정을 하게 되면 확인하기 위해 많은 시간을 쓰게 되고 바쁘면 확인 없이 추정을 기반으로 개발을 하게 되어 버그가 생겨납니다. 버그를 해결해도 개인 경험으로만 쌓이게 되어 담당자 없으면 일처리 못한다 도메인 지식이 많이 필요한 분야라고 주장할 수 있게됩니다. 개발 속도는 느려지고 개인에 대한 의존성이 높으니 고인물 천지가 되어 망하기 좋은 냄새가 나기 시작 합니다. 코드에 하드코딩된 숫자를 넣는 정도로도 충분합니다. 이미 많이들 하고 있죠? 잘하고 있는 겁니다.

Tip52

문서는 길게 작성하세요. 얼마나 고민하고 연구해서 작성했는지 아는게 얼마나 많은지를 뽐낼 수 있고, 많은 정보를 줘야 오해하는 일이 없을테니까요. 왜 해야 하는지 알려 주는게 중요하니 배경부터 온갖것을 다 적고 그럴싸하지만 쓸모 없는 도표까지 넣으면 됩니다. 표지, 목차, 간지도 잊지 마세요. 읽는 사람의 시간이 낭비되고 뭐가 많으니 오래걸릴거란 짐작에 과다추정하게 되고 다른 급한 일에 밀려 시작도 못해볼 가능성이 올라갑니다. 작성하느라 낭비된 작성자의 인생은 덤입니다. 문서가 의사소통을 방해하고, 쌓여만 가는 문서에 눌려 회사는 이러지도 저러지도 못하고 망해갑니다.

Tip53

건강 관리를 하지 마세요. 무리하고 주말에도 일하고 절대 쉬지 마세요. 어쩔수 없이 자주 아파 중요한 순간에 자리를 비울테고, 피곤해서 잘못된 의사결정을 할테고, 결국 소진해서 조직을 떠나면 회사는 대체인력을 찾느라 고생하고, 개인에게 쌓인 전문성도 잃어버려 어려움을 겪게 됩니다. 회사를 옮기며 이런 행동을 반복하면 산업계 전반에 상당한 피해를 입힐 수 있습니다. 물론 그전에 개인의 삶이 먼저 황폐화됩니다.

Tip54

자신보다 역량이 떨어지는 사람을 뽑으세요. 그래야 계속 왕노릇을 할수 있죠. 아니면 급하다고 아무나 뽑으세요 그리고 안맞으면 방치하면 됩니다. 조직에 이상한 사람이 넘쳐나니 빠르고 효과적으로 망하게 할 수 있습니다.

Tip55

개발자만 알아 들을 수 있는 용어를 사용하세요. 비즈니스 담당자들이 알아 듣지 못해 대화를 포기하게 만들수 있습니다. 가능한 이유와 불가능한 이유를 서비스 아키텍쳐, 기술의 장단점 때문이라고 장황하게 이야기 하면 얼마나 유능해 보이겠어요? 이런 기본적인 용어 조차 알아 듣지 못하는 사람을 기술회사에 다니며 기초조차 배우려 하지 않는 사람으로 매도하면 더욱 효과가 좋습니다. 인류가 바벨탑을 완성하지 못한 이유를 현실에 재현할 수 있습니다. 뭔소리냐고요? 망한다는 이야기입니다.

Tip56

성능 테스트를 특별한 이벤트로 전문가만 할 수 있게 만드세요. 기능 구현에만 집중하다 보면 점차 느려지는 서비스는 어느 순간 지속적인 장애를 일으키고 확장이 불가능한 상태가 됩니다. 구현이 다 끝난 상태에서 성능 테스트를 하면 문제 개선에 어려움을 겪을 확률이 높고 출시가 임박하면 문제를 알고도 기도만 하는 상황에 빠지기 일쑤입니다. 성능 테스트 환경을 실환경과 차이가 나게 구성하는 것도 좋은 방법인데 가정에 가정을 더하며 추정을 하다 보니 정확한 상태를 진단할 수 없게 되어 오버엔지니어링을 하거나 충분한 성능을 확보할 수 없게 됩니다. 이 모든 일이 신경 안쓰면 저절로 발생하게 되므로 딱히 뭐를 하지 않아도 망하게 할 수 있습니다.

Tip57

경쟁사 제품을 사용하지 마세요. 어차피 우리가 최고이고 남들 것 봐야 시간 낭비일 뿐이라고 하면 됩니다. 새로운 아이디어는 기획자가 내는 것이고 벤치마킹도 기획자의 역할인데 개발자가 괜한 시간 낭비를 할 필요가 없죠. 상대는 비슷한 문제를 어떻게 고민하고 해결하는지 알아봐야 뭐하겠어요? 그냥 내 할일만 열심히 하면 되죠. 제품의 특징을 가장 잘 이해하고 있는 개발자가 제품에 대한 아이디어를 내지 않고 상대의 장점과 단점을 모르니 점차 우물안 개구리로 변하게 됩니다. 경쟁사가 뛰어나지 않다면 회사가 망하지는 않겠지만 고인물은 썩기 마련이고 시간이 걸릴 뿐 도태 되기는 매한가지입니다.

Tip58

힘들게 개발자로 성장하여 리더 역할을 맡게 되면 피플리더십과 프로젝트 관리만 담당하세요. 리더는 조율하고 의사결정하는 역할이니 실무를 할 이유도 시간도 없다고 하면 됩니다. 바쁘게 회의만 쫓아 다니고 회의에서 결정된 사안을 팀원들에게 통보만 하면 됩니다. 모든 의사소통은 오류가 발생하기 마련이고 실무 역량이 점차 감소하여 담당하는 서비스의 구조조차 이해 못하는 상황이 되면 내리는 의사결정 마다 잘못되어 팀뿐만 아니라 회사 전체를 아수라장으로 만들 수 있습니다. 리더에게 보고 배울 것이 없다고 느끼는 역량 있는 개발자는 이직할 것이고 아무 비판 없이 리더의 의견만 추종하는 사람만 남아 서로를 보살피고 의지하는 공생관계가 만들어집니다. 이런 사람들로 가득찬 회사가 뭐하겠어요? 망하죠.

Tip59

사용하기 쉽게 만드는 것이 옳은 방법이니 모두 public으로 선언 하세요. 누가 언제 가져다 쓰는지 확인하기 위해서 디버거를 자주 켜게 될 것이고 코드는 손쉽게 난장판이 되고 오래 지나면 바로 잡는 일도 많은 비용이 들게 만들 수 있습니다.

Tip60

기존 로직을 대체하여 신규 로직을 작성해야 하면 대체할 부분을 다 지워 버리고 새로 만드세요. 어차피 작업하는 동안 해당 기능을 사용하지 못하는 것이니 아무 상관이 없다고 하면 됩니다. 안전하게 변경한다고 기존 구현 나두고 대체할 것을 만든 다음에 완료가 되면 기존 코드를 삭제하는 방법은 낭비일 뿐이라고 하세요. 중간에 길을 잃고 헤매는 일이 생겨도 어려움을 극복하는 멋진 개발자라면 대규모 산탄총을 들고 덤비는 것이 멋진 일이라 주장하면 됩니다.

Tip61

작업 중에 다른 문제가 보이면 얼른 눈에 보일 때 처리해야 한다고 그래야 근면한 개발자라며 관심을 바꾸세요. 자주 작업전환이 발생하며 낭비가 발생하게 됩니다. 코드 리팩토링 하다 버그를 수정하고, 신규 기능 개발하다 관련 없는 기능을 리팩토링 하면 됩니다. 인간은 멀티태스킹이 가능하다 굳게 믿으면 됩니다. 지저분하고 완료되지 못한 일이 넘쳐나는 세상을 만들 수 있습니다.

Tip62

의사결정은 리더의 역할이므로 실무자의 권한을 가능한 축소하세요. 리더십이 강화되고 일관된 의사결정을 할 수 있어 조직 효율이 높아진다고 주장하면 됩니다. 의사결정을 받기 위해 대기하는 시간이 늘어나고 남이 시키는 일만 하며 수동적인 태도를 취할 수 밖에 없으니 조직은 느려지고 조직원은 스스로의 존재가치를 부정하고 성장하지 못하게 됩니다. 리더가 모든 일을 가장 잘 아는 사람일 수 없으니 잘못된 의사결정이 이루어져도 잘 알고 있는 실무 담당자는 입조차 뻥끗하지 못하게 됩니다. 조직간 협의가 필요한 사항은 주기적으로 개최되는 회의에서 결정한다고 해버리면 전체 조직의 속도는 더할 수 없이 느려집니다. 세상은 날아가고 있는데 조직 홀로 기어가고 있는데 어찌 살아남겠어요? 망해야죠.

Tip63

새로운 기능이 많을수록 고객 가치를 높이는 것이라 주장하며 가능한 많은 기능을 만들어내세요. 핵심 기능의 성숙도를 높이는 것 보다 별로 중요하지도 않은 기능을 만들고 함께 배포하기 위해 출시를 지연 시키는 것도 최선입니다. 무엇이 MVP(Minimum Viable Product)인지 모르니 우선순위를 정하지 않고 되는대로 일을 하게 될테고 조직역량은 효과적으로 낭비 됩니다. 땅을 못파지만 라디오를 들을 수 있는 삽을 만들어 내는 회사가 살아남는 세상이 오기만을 기다리며 내부자원을 모두 소진할 때까지만 생존가능합니다.

Tip64

승진 제도를 만들고 모두가 승진만을 목표로 일하게 하세요. 자리를 차지 해야만 보상하고 그렇지 않으면 아무리 뛰어난 성과를 올려도 적합한 보상을 받을 수 없게 만들면 됩니다. 조직원들은 자리를 차지하는데 혈안이 되어 내부 경쟁을 하게 될테고 협업은 애초에 불가능한 일이 됩니다. 서로 상대방 탓을 하며 일이 안된 이유를 찾으려 할 뿐 완료하려는 동력은 없습니다. 사내정치가 횡행하고 정보는 독점됩니다, 서로 경쟁만 하는 내부 조직이 살아남는 일은 오로지 행운일 뿐이므로 역량이 뛰어난 조직원은 이탈하고 내부경쟁을 사랑하거나 모든 것을 포기하고 핍박을 감수하는 사람만 남은 조직은 망합니다.

Tip65

미래를 완전히 예측하고 대응할 수 있다고 주장하세요. 서비스의 모든 기능을 프로젝트 초기에 상세화 하고 계획에 따라 착착 구현만 하면 된다고 주장하면 됩니다. 상세화 하느라 오랜 시간이 걸릴테고 그동안 대기하는 자원이 늘어날 테고 막상 구현에 들어가면 초기에 고려하지 못한 여러 변수가 발견되면서 도저히 계획대로 수행할 방법이 없게 되는데 실무자들이 근면하지 않고 이해를 못하는 것이라 탓하면 됩니다. 이런 우여곡절을 겪고 도착한 끝에는 처음 예상과 다른 세상이 존재하게 될테고 자원을 잔뜩 쓰고도 무엇하나 만족스러울 것 없는 제품을 만들게 됩니다. 아직 회사가 망하지 않았다면 더욱 거창한 미래비전을 제시하며 더 큰 규모의 프로젝트를 왼뱍하게 계획할 수 있다고 주장하면 됩니다.

Tip66

당장 하지 못할 일이 확실해도 분석하고 우선순위 정하고 필요한 리소스와 일정을 추정하세요. 모여서 논의하고 일어나지 않을 미래를 걱정하느라 현재 하고 있는 일에 집중할 수 없게 만들 수 있으며 수시로 업무전환을 하게 만들 수 있습니다. 온갖 낭비란 낭비는 다 시킬 수 있으므로 주기적으로 모여 개발하지 못할 기능을 검토하고 백로그에 담아두고 누구나 볼 수 있게 하면 됩니다. 새로운 일을 열심히 추진하는 모습을 보여주니 조직에서는 뛰어난 인재란 소리를 듣게 되지만 회사 자원을 쓸데 없이 낭비 시키는 대재앙을 일으켜 망하게 할 수 있습니다.

Tip67

효과적인 의사소통을 하려면 아주 상세하게 작성한 문서를 이용해야 한다고 주장하세요. 타이틀을 크게 적어 한장을 차지하게 하고 필요하지도 않은 목차를 넣고 여기저기서 찾은 레퍼런스 문서를 추가하면 됩니다, 무엇을 하자는 건지는 미괄식으로 문서 끝에 주장하고 문서의 앞에는 이런저런 시장상황과 타사 사례를 잔뜩 가져다 넣어두면 됩니다. 무엇을 하자는 건지 파악할 수 없으니 합의를 이끌어 내기 어렵고, 쓸모 없는 문서를 읽느라 시간이 낭비되고, 긴 문서를 보고는 복잡하고 큰일이라 추정하게 되어 자원을 과다 투입하게 됩니다. 잘나 보이기 위해 멋진 문서를 두껍게 만들어 내면 빨리 망하게 할 수 있습니다. 개발자라면 자동화 문서 생성기를 이용해 두꺼운 다이어그램을 많이 뽑아내면 되므로 쉽게 만들수 있습니다.

Tip68

일정을 추정할 때 자신의 의견을 빠르게 밝히세요. 리더라면 더 유리합니다. 제시한 의견은 다른 사람의 판단을 제약하게 되고 다양한 의견이 나오기 어렵게 만듭니다. "이거 얼마나 걸릴까요? 내 생각에는 1주일 정도면 충분할 것 같은데"와 같은 방식이면 됩니다. 강력한 닻내림 효과로 일정 추정은 누구도 책임질 필요 없는 외부에서 주어진 목표가 되며 스스로 동기부여하며 몰입할 수 없게 만듭니다. 지키고 싶은 이유가 없는 일정에 따라 움직이는 조직은 무엇 하나 제때 만들어 내지 못합니다. 제약사항은 뒤늦게 발견 되기 일쑤이고 늦어진 일정은 노력이 부족한 구성원 탓이라며 비난이 생겨나고 회사는 망하기 좋은 상태가 됩니다.

Tip69

인프라 자원을 모니터링 하지 마세요. 어떤 것이 실행되고 얼마나 많은 자원을 활용하고 있는지 효율적으로 활용되는지 관심을 갖지 않으면 자연스럽게 그렇게 됩니다. 불필요한 자원 낭비가 많이 발생하고 부족한지 넉넉한지도 알지 못하니 사업이 안되면 비용을 낭비하게 되고 잘되면 대응을 하지 못해 장애가 발생하게 됩니다. 현황을 모르니 최적화를 할 수도 없고 운에 의지하여 운영되다 망하게 됩니다.

Tip70

데이터베이스에 누구나 직접 연결해서 사용하세요. 개발 자유도가 높아 효과적인 개발이 가능하다고 주장하면 됩니다. 데이터베이스를 중심으로 복잡하게 얽힌 서비스는 어느 순간 데이터베이스가 병목이 되어 성장하지 못하며 관련 장애가 우후죽순 발생합니다. 데이테버이스 변경이 발생하면 모든 서비스 코드가 따라서 변경되어야 하는 상황이 되어 개선도 어렵습니다. 개발자가 실수로 테이블을 드랍 시키는 일도 발생할 수 있어 서비스가 안정된 상태가 되는 일은 일어나지 않습니다.

Tip71

충분한 교육과 사전 준비 없이 코드리뷰 프로세스를 도입하세요. 자존심 쎄고 상대에 대한 배려 없이 자기 하고 싶은 말을 끝까지 하는 구성원들이 있다면 최상의 조건입니다. 서로 잘났다고 우기며 서로에게 상처를 입히고, 싸우느라 일 안하고, 코드 품질도 개판이 되고, 조직 분위기도 박살이 나니 이 어찌 좋지 않을 수 있겠습니까.

Tip72

비교하세요. 기존에 다녔던 직장과 비교하고 다른 회사와 비교하며 문제점을 지적하세요. 문제점만 부각되는 회사에 소속감이 생길리 없으니 새로운 기회를 찾아 떠나려고 하는 사람과 불만만 가득한 사람이 가득한 회사가 됩니다. 

Tip73

공식 채널이 아닌 비공식 채널을 적극 활용하세요. 불만이 있다면 이사람 저사람 따로 불러내서 하소연을 하면 됩니다. 이견이 있을 경우 그자리에서 설명하고 합의점을 도출하기 위해 노력하는 대신 침묵 하고 있다가 의사결정이 이루어 지고 난 다음에 불만을 표출하세요. 여러 추정을 더한 이야기를 여러 사람에게 하면 이야기는 점차 확대 재생산 되어 출처도 알수 없고 바로잡을 수도 없는 괴물이 되어 회사를 집어 삼키게 됩니다.

Tip74

지속적 통합(Continuous Integration)을 사용하지 마세요. 코드의 문제는 늦게 발견될 것이고 빌드 조차 되지 않는 코드베이스를 가지게 됩니다. 배포는 어려운 일이 되고 커밋될 때마다 혼란만 가중될 것이라 독재자가 나타나 문앞을 지키며 의욕을 저하 시키는 온갖 이상한 수동 프로세스를 추가하게 될 것입니다. 일하는 시간 보다 불필요한 프로세스를 지키느라 더 많은 시간을 쓰는 조직이 어떻게 살아 남을 수 있겠어요? 열심히 일할 수록 빨리 망하는 조직이 됩니다.

Tip75

동료에 대한 평가를 주변에 알리세요. 누가 “일을 잘한다. 못한다”, “협조적이다. 아니다"와 같은 말을 하면 선입견이 만들어지고 이는 사람에 대한 이해를 좁은 틀에 가두게 됩니다. 긴밀한 협업이 필요한 상황에서 강한 선입견은 부정적인 영향을 주거나 근거 없는 낙관론에 빠져 제대로 논의하지 않은 상태에서 과도한 기대를 하여 실망하게 됩니다. 기피하려고 하고 너무 믿어 실수가 일어나는 환경이라면 성장하기 보단 망하기 좋습니다.

Tip76

개발자를  교육하지 마세요. 새로운 기술, 커뮤니케이션, 협업 등은 오로지 개인의 역량에 의존해야 한다고 믿으면 됩니다. 스스로 성장하는 방법은 찾은 극소수만이라도 생존하면 다행이지만 방향성을 잃고 헤매는 사람들에 치여 스스로 성장하는 사람은 조직을 떠나게 됩니다. 결국 모두 번아웃 되고 정체된 사람만 남아 있는 조직에 생기가 돌리 없습니다. 살아도 죽은 조직이 됩니다. 신규 입사자가 효과적으로 조직에 안착할 수 있도록 돕는 역할과 책임을 개인이나 소속 부서에 한정시키는 경우에도 같은 효과가 발생합니다. 신규 인력을 교육할 여력이 없거나 방법을 모르는 개인과 조직은 실수를 반복해서 저지르게 되어 시간과 자원은 낭비되고 신규 입사자는 방치 됩니다. 사람을 뽑을 수록 조직이 느려지는 기적을 목격할 수 있습니다.

Tip77

일하는 방식을 결정하는 별도의 조직이나 개인을 두세요. 업무 당사자 간의 긴밀한 협업과 논의를 통해 점차 더 효과적인 방법을 찾아 가는 대신 실무에 참여하지 않는 사람이 객관적인 시각으로 정교하게 설계한 프로세스가 개인의 이해 관계와 얽히지 않아 효과적이라고 주장하면 됩니다. 직접 참여 하지 않는 사람은 이상적인 방법을 정해 놓을 것이고 현업에서는 이를 지킬 수 없는 수많은 예외 상황을 제시하게 되어 있으나 누구도 지키지 않는 상황이 됩니다. 예외 상황을 관리한다며 부가적인 문서작업까지 추가하면 일하는 대신 프로세스를 지키지 못한 이유에 대한 문서나 작성하며 자원을 낭비할 수 있습니다. 이런 조직에서 자발성을 기대할 수 없으니 모두가 노예의 심정으로 극도의 비효율로 일을 하게 됩니다. 당연히 망하겠죠.

Tip78

깨진 빌드를 방치하세요. “누군가 고치겠지”, “내 책임은 아니니까"라고 생각 하면 됩니다. 로컬환경에서 테스트 다 해서 올린건데 통합빌드가 깨진건 내 잘 못이 아닌거죠. 연달아 깨어진 빌드가 방치되기 시작하면 누구도 관심을 갖지 않게 되고 최고로 안전해야할 코드베이스는 엉망이 되어 버리고 배포라도 한번 하려면 온갖 어려움을 겪으며 난리를 쳐야 합니다. 어려운 일을 하는 사람이니 빌드/배포 담당자의 어깨에 힘이 들어가고 조직을 어려움에서 구하는 영웅처럼 자리매김 할 수 있습니다. 조직에는 영웅이 넘쳐난다는 의미는 난세에 빠졌다는 것이니 어련히 망하겠죠.

Tip79

기본형 데이터만 활용하세요. 전화번호는 단순 문자열로 취급하고 특정 의미를 가지는 길이, 면적, 넓이 등은 숫자로 취급하면 됩니다. 전화번호에서 지역 번호를 추출하는 등의 작업을 하기 위해 자주 단순 문자열 연산을 하게 될 것이고 숫자로 취급된 데이터는 단위가 명시 되어 있지 않으니 cm로 다루는 것과 m로 다루는 것이 섞여 많은 실수를 유발할 수 있습니다. 다른 개발자를 헷갈리게 하고 비슷한 작업을 반복적으로 하게 만드니 효과적인 낭비 방법입니다. 요렇게 조금씩 새어 나가는 낭비는 잘 보이지 않아 누구도 관심을 갖지 않고 코드베이스에 그런 처리가 많아질수록 남들도 따라하게 되니 효과적으로 망하게 할 수 있습니다.

Tip80

메소드를 하나만 가진 클래스, 구현이 하나 밖에 없는 인터페이스를 방치하세요. 확장될 것이라 기대하고 만들어 놨으나 오랜 시간이 지나도 그런 일이 일어 나지 않았다면 앞으로도 일어날 가능성이 없지만 누군가 이유가 있어 만들어 놨으려니 하며 그대로 두면 됩니다. 이런 변경에 무관심 하게 되면 다른 영역에도 무관심하게 되고 오직 자신이 하는 일만 신경 쓰게 됩니다. 결국 전체 코드는 무질서해지고 이를 읽고 이해하여 유지보수 하는 개발자의 시간은 손쉽게 낭비 됩니다. 자기 일만 하면 저절로 실천 되는 것이라 누구나 이미 하고 있을 수 있습니다. 흥하게 하기는 어려워도 망치기는 이처럼 쉽습니다.

Tip81

반복문은 함수의 핵심 영역이니 반복문을 잘 작성하는게 정말 중요합니다. 복잡한 반복문을 작성할 줄 아는 것이 좋은 개발자의 역량이니 잘 활용해야죠. 옛날 컴퓨터 언어를 사용 중이라면 어쩔 수 없는 측면도 있습니다. 하지만 세상은 빠르게 발전했고 퍼스트 클래스 함수를 사용하여 컬렉션 파이프라인으로 반복문을 대체할 수 있지만 과거의 망령에 사로잡혀 있으면 모든 개발자를 석기시대에 머물게 할 수 있습니다. 가독성 높은 파이프라인 대신 과거의 유물인 반복문에 집착하면 코드 품질 높이기는 자연스레 어려워지고 깨진 유리창이 코드베이스 여기저기에 방치되고 자연스레 쓰레기는 쌓여만 갑니다. 망하겠죠?

Tip82

위대한 클래스라면 덩치도 커야겠죠. 오랜시간 개발하느라 노력해온 결과이니 메소드와 필드가 많은 클래스는 뛰어난 산출물입니다. 코드가 중복 되고 뭐하나 찾으려면 한참을 뒤져야 하는 낭비는 고려할 필요 없죠. 슈퍼클래스를 만들거나 비슷한 속성을 묶어 클래스를 독립 시키는 방법은 귀찮고 오류를 만들어낼 위험이 있다면 무시하면 됩니다. IDE에서 제공하는 기능만으로 실수 없이 처리할 수 있지만 귀찮게 그걸 뭐하러 하겠어요 지금도 잘 동작하는 코드인데 그냥 놔두는게 좋죠. 결국 점점 무거워지다 자기 무게에 깔릴 지경이 되면 훨씬 많은 시간과 비용을 들여 고쳐야 하는데 설마 내가 하겠어요? 누군가의 일이겠죠. 모두가 이런 마음을 가지게 되면 품질 좋은 코드란 뿔달린 말 보다 더 심한 환상이 되어 버리는 거죠.

Tip83

기술면접에서 지원자의 코드 작성 능력과 경험을 검증하는 대신 답이 정해진 퀴즈를 내거나, 아느냐 모르느냐 종류의 질문만 하세요. 이력서에서 출신학교와 회사를 중시하고 유명한 곳을 나왔으면 어련히 잘할거라 기대해서 설렁설렁 검증하고 자신이 잘 모르는 곳을 나왔으면 무시하고 열심히 노력하지 않은 것이라는 선입견을 갖으면 됩니다. 반짝 거리는 물건을 좋아하는 까마귀 처럼 이력서에 적힌 글자에 매료되고 지원자의 실제 모습과 능력을 등한시 하면 겉모습만 매력적인 괴물을 회사에 초대할 가능성이 높습니다. 잘못 채용한 한명이 알아서 팀을 망치고 회사를 망하게 할 수 있으니 따로 손을 보태지 않아도 되는 효과적인 방법입니다.

Tip84

컨퍼런스에서 들은 사례를 검증 없이 도입하세요. 컨설팅 업체에서 홍보하는 내용을 믿고 전권을 주는 것도 방법입니다. 도입 과정에 실무자는 배제하고 무조건 외부의 지시를 따라야 한다고 이미 다른 경쟁기업은 모두 활용하고 있어 우리만 뒤쳐지고 있다고 강조하면 됩니다. 실무자가 자발적으로 참여하지 않기에 저항할 가능성이 높고 점진적 개선이 아닌 빅뱅 방식의 접근은 큰 혼란만 만들어 냅니다. 성공하지 못하면 실무자 탓을 하면 됩니다. 문화도 망가지고 성과도 나지 않고 자원도 낭비되니 안 망할 수가 없겠죠.

Tip85

지원자를 을로 대하세요. 취업하고 싶어 온 사람이니 면접관이 아쉬울 것 없죠. 공격적으로 질문하고 답변이 마음에 안들면 인상 쓰면서 이것도 모르냐는 식으로 쳐다보면 됩니다. 무엇을 아느냐 모르느냐 식으로 질문하고 지원자의 경험을 비웃거나 가치 없는 일이라 치부하세요. 안좋은 경험을 한 지원자는 회사의 원수가 될 것이고 밖에 나가 만나는 사람들마다 회사의 문제점을 설명할테니 회사 평판은 엉망이 되고 누구도 오고 싶어 하지 않는 회사가 됩니다. 좋은 인재가 오지 않는 회사가 어찌 흥하겠어요? 망해야죠.

Tip86

면접 결과 애매하다 싶으면 면접 단계를 마음대로 추가하세요. 지원자의 동의도 받지 않고 회사가 갑이니 면접 단계를 마음대로 조정하면 됩니다. 지원자는 자신을 홀대하는 회사에 좋은 감정이 생길리 없으니 입사후에도 애사심과 업무 몰입을 기대하기는 어렵습니다. 지원하지도 않은 여러 직무에 조리돌림하듯이 이력서 돌려 보며 면접 오라고 통보하면 쉽사리 철천지 원수를 만들 수 있습니다.

Tip87

DB를 최대한 활용하세요. 모든 비즈니스 로직을 스토어드 프로시저에 넣으면 됩니다. DB에 대한 의존도가 극에 달하면 신규 기능 추가, 변경, 오류수정은 엄청나게 힘든일이 됩니다. 가비지 데이터가 들어가면 서비스에 전면 장애도 발생할 수 있어 서비스는 장애에 취약한 상태가 됩니다. 누군가 열심히 어플리케이션의 역할과 DB의 역할을 분리해 내더라도 순식간에 스토어드 프로시저가 다시 늘어나면 질려버린 개발자는 대탈출을 할 것이고 어쩌지 못할 레가시에 갇힌 회사는 성장하지 못합니다.

Tip88

자신의 입장을 유리하게 만드는 단어를 사용하세요. 표준과 통제 없이 각자 마음대로 하는 상태를 “선택의 자유"라 표현하면 모든 종류의 개선 시도를 자유를 탄압하는 “독재"로 정의해 반대할 수 있습니다. 오류를 줄이고 안정된 서비스를 유지하기 위한 행위를 개인의 자유를 박탈하는 잘못된 일로 치부하게 되면 실 서비스는 악귀 들린 상태가 됩니다. 뭐가 언제 들어갔는지, 누가 어떤 의도로 변경했는지 알수 없게 된 서비스는 소중한 자산이 아닌 쓰레기 처리장이 되고 개발자는 쓰레기 더미를 뒤져 먹을 것을 찾는 신세가 됩니다. 망했다가 정말 잘 어울리는 상태죠.

Tip89

사이가 좋지 못한 관계가 발견 되면 상호 교류가 적은 곳으로 옮겨 배치하세요. 각자 자기 몫을 하는 뛰어난 개발자인데 이들을 놓치는 것은 회사에 큰 손실이므로 개인 역량을 발휘할 수 있게 다른 부서로 배치하는 방법이 좋다고 주장하면 됩니다. 잠시 문제가 사라지는 것 처럼 보이지만 이내 개인 문제가 조직문제로 비화하게 됩니다. 문제를 해결한 것이 아니라 숨긴 것이라 개인이 가진 선입견이 조직원들에게 퍼지게 되고 상호 반목하고 협업이 불가능하게 됩니다. 좋은게 좋은거라 생각하며 사람 문제가 생길때 마다 재배치를 하다 보면 조직은 제 기능을 잃고 그저 친한 사람끼리 모이고 서로를 미워하는 상태가 됩니다. 망하지 않으면 이상하겠죠?

Tip90

예측 불가능하게 일하세요. 어떤 날은 몇 날 며칠 밤을 세워 엄청난 일을 해냈다고 믿게 하고 어떤 때는 이래저래 별로 한 일 없이 보내면 됩니다. 생산성이 들쭉날쭉 하니 계획을 세워 일정한 리듬을 가지고 일할 수 없고 상호 의존성이 있는 작업을 하는 사람은 언제는 시간에 쫓기고 언제는 마냥 기다리게 됩니다. 예측할 수 없으니 수시로 일정은 어긋나고 별것 아닐 것 같은 작은 물결이 파도가 되어 전체 조직의 생산성을 낮춥니다. 영감 넘치는 예술가처럼 생산성이 극대화 될 때와 바닥을 기어 어둠에 잠식된 상태를 빠르게 오가면 됩니다. 생산성이 높았던 때만 기억하고 이런 사람을 조직이 우대하면 조직의 불확실성은 높아지고 망하기 좋아집니다.

---

여기까지가 LinkedIn에서 연재된 내용이다.

CTO님께서 나머지 내용과 기존 연재된 내용은 잘 정리하여 책으로 출판하신다고 하셨다...!

아주 재미있게 보고 있던 연재 내용으로 책이나오면 꼭 구매해서 읽어봐야겠다.