10/17 박성철님 강연 (레벨 4)

https://lnkd.in/p/ghV5vKEy

“요즘 우테코 사람들 다 똑같다더라.” 최근 이런 말을 들었습니다. 꽤 충격이었고, 마음이 조

 

한번은 코로구가 이런 글을 링크드인에 올린 적이 있었다. 대략적으로 "우테코 사람들 다 비슷하더라" 라는 말을 많이 들으셨고, 그 얘기에 충격이여서 본인은 뭐가 다른지 생각해보게 되었다는 뜻이였다. 그리고 크루들 모두 같은 교육을 받았지만 다 다른 개성을 갖고 있는 사람들이여서 왜 그렇게 생각하는지 궁금하다고 했다.

나도 코로구의 말에 동감했다. (사실 외부 사람들을 잘 안만나서 우테코 크루들 다 비슷하다는 말을 잘 못들어봤다) 우리는 모두 다 다른 색을 가지고 개성이 강하고 되게 강한 자아의 사람들이 많은데, 160명이 비슷하다는 말이 무슨 뜻일까? 라는 생각이였고, 나는 어떤 개발자인지, 나는 어떤 사람인지 나중에 생각해봐야지~ 하고 말았다.

최근에 프로젝트를 하면서 진로에 대해서도 고민하던 중, 나는 어떤 사람인가? 나는 뭘 좋아하는가? 나는 왜 개발을 하는가? 와 같은 질문을 하게 되었고, 코로구가 질문과 관련된 내용의 강연을 들고 와주셨다. 

---

강연

4줄 요약

소프트웨어 개발은 복잡하고 불확실해서, 처음부터 구현 방법과 사용자에게 필요한 가치를 모두 알기 어렵다.
그래서 작게 만들고 피드백으로 가설을 검증하며, 계속 개선할 수 있도록 코드 품질을 지켜야 한다.
우테코에서 배운 원칙은 이 과정을 돕지만, 모든 상황에 그대로 적용할 수 있는 정답은 아니다.
수파리처럼 원칙을 익히고 경험으로 한계를 이해하며, 맥락에 맞는 판단으로 사용자에게 가치를 만드는 개발자로 성장하라는 이야기다.

 

강연 내용

강연은 개발자라는 직군에 대한 내용이였다고 생각한다. 강연의 흐름이 너무 커서 모두 따라가기는 살짝 힘들긴 했다. 다만 큰 흐름 자체는 파악한 것 같은 느낌? 개발자는 어떤 일을 하는 사람인지, 어떻게 성장해야할지. 에 대한 내용이였던 것 같다.

코로구가 말했던 것 처럼, 왜 다 비슷한 것 같을까? 라고 생각했을 때, 성철님은 교육 과정에서 포비가 강조한 몇 원칙이 강하게 우리 기억에 남고, 면접에서도 그게 공통적으로 나오다보니 비슷하게 느껴질 수 있는 것 같다고 말씀하셨다. 이게 잘못된 것은 아니지만, 배운 내용을 자기 경험과 판단으로 발전 시키지 못하면 한계가 있을 수 있다는 말씀이셨다. 

그래서 이 한계를 넘어 배운 원칙을 더 잘 활용하고 나만의 가치를 만들어 나가는 개발자로 성장하는 이야기라는 느낌이였다.

 

https://johngrib.github.io/wiki/No-Silver-Bullet/

은총알은 없다(No Silver Bullet)

개발은 왜 어려울까, 생각해보면 두 가지 문제가 있다. 본질적인 어려움과 부수적인 어려움인데, 본질적인 어려움은 도메인에 해당하는 것 같다. 

1. 본질적인 어려움 - 해결하려는 문제 자체에 있는 어려움

2. 부수적인 어려움 - 문제를 해결하기 위해 사용하는 언어, 라이브러리, 플랫폼, 프레임워크, 개발 방법 등에서 생기는 어려움

최근 들어 AI 의 등장으로 부수적인 어려움은 어느정도 많이 줄어든 것 같다. 지금 하고 있는 프로젝트도, AI가 없었다면 정말 어려웠을 것 같고, 내가 건들지도 못했을 것 같다. 다만 본질적인 어려움은 되게 곤란했다. 우리가 정책을 정해야할 일도 많고, 또 레벨 3동안 프로토타입 검증을 했을 때 "카드 혜택"을 주제로 했었는데, 전월 실적, 얼마 썼는지 등등 고려해야할게 너무 많아서 어떻게 해야할지 감이 안잡혔던 기억이 있었다. 카드 혜택의 조건이 복잡하다는 것은 본질적인 어려움일 것이다. 그리고 어떤카드를 써야 제일 할인을 많이 받는지 해당 장소로 가면 카드를 알려주는 프로토타입이였는데, 이걸 구현하는 어려움은 부수적인 어려움일 것이다.

사실 AI로 인해서 부수적인 어려움 조차 제대로 해결되었다고 보지도 못한다고 말씀하셨지만, 내가 느끼기론 어느정도 구현에 대한 어려움은 많이 나아졌다고 느꼈다.

 

소프트웨어는 본질적인 어려움과 부수적인 어려움 때문에 복잡하고 불확실하다(복합성은 여러 성격의 요소가 얽혀 있는 것이고, 불확실성은 앞의 일을 명확하게 알기 어려운 것이다.). 처음부터 우리가 모든 것을 알기 어렵다. 폭포수 모델은 소프트웨어의 저런 특성을 해결하지 못한다는 문제가 있다.

그러면 어떻게 해결해야할까, 개발을 할 때 두가지 작업을 통해서 두 종류의 일을 분리해서보자. 

- 연산적 작업: 무엇을 해야하는지와 답을 이미 알고 있어서 정확하로 빠르게 수행하는 것이 중요한 일

- 탐색적 작업: 답을 몰라서 여러 가능성을 시도하고 결과를 보며 해결 범위를 좁혀나가는 일

개발할 때 우리는 대부분의 경우 처음부터 답을 알고 있지 못한다. 답을 아는 것 처럼 행동하기 보다, 탐색을 통해 여러 가능성을 보고, 작은 시도를 통해서 피드백을 얻고, 판단을 수정해야한다.

그 예시로 성철님은 스티브 맥코넬이라는 사람의 인터뷰를 말씀해주셨다. 2주 과제가 주어지면, 처음 6일은 일단 코딩하면서 여러 방법을 시도하고 실수도 하고 버그도 낸다. 그리고 그 코드를 버린다. 그 다음 3일은 처음 시도하면서 배운 점을 반영해 다시 작성하고 버린다. 마지막 남은 날은 두 시도에서 얻은 이해를 바탕으로 최종 코드를 작성한다. 시도를 통해서 문제와 설계를 이해해 마지막 구현이 빨라지고, 더 잘 만들 수 있을 것이다.

https://newsletter.pragmaticengineer.com/p/code-complete-with-steve-mcconnell

Code Complete with Steve McConnell

상향식, 하향식도 같은 맥락이다. 하나가 옳은게 아니라, 상황에 맞게 오가는 것이다. 아래 개념에서 구현 가능성이 불분명한 부분이 있다면 먼저 실험해보고, 반대로 전체 흐름을 어떻게 연결할지 모르겠다면 상향식으로 내려오면서 구조를 보는 것이다. 이렇게 보면서 전체 구조를 본다.

그래서 애자일이 페어 프로그래밍, 단위 테스트, 미팅, 테스트 출시 등등을 통해서 여러 시간에 걸친 피드백을 많이 받을 수 있는 방식이라고 말씀하셨다. 애자일에서 중요한 것은, 불확실한 문제를 작은 시도와 피드백으로 해결하는 구조를 만드는 것이다.

 

다만 우리의 개발 과정만 개선하는 건 충분하지 않다. 우리가 프로그램을 만드는 이유는, 사용자에게 가치를 전달하기 위해서이다. 우리가 유지보수하기 쉬운 소프트웨어를 만드는 목적은, 결국 소프트웨어가 유용하게 쓰이도록 하기 위해서이다. 하지만 우리는 대부분 로컬에서만 잘 돌아가면 되지. QA만 잘 통과하면 된다는 목표를 갖기 쉽다.

실제 운영에선 예상치 못한 사용과 공격, 주변 서비스의 장애, 자원의 한계, 변화하는 부하와 환경 (예를 들자면, 배민이면 식사시간때 부하가 많이 걸릴 것이다.)와 같은 것들을 감당해야한다. 또, 제품의 유용성도 가정으로 확정할 수 없다. 가설을 세우고 기능을 구현해 운영한 뒤 데이터를 통해 실제 사용자의 반응을 배워야 한다.

그 과정은, 가설 수립 -> 구현과 운영 -> 데이터 수집 및 분석 -> 학습 -> 다음 가설 이다.

하지만 사용자 피드백을 받아도 코드를 바꾸는데 오래 걸린다거나, 바꿀때마다 새로운 문제가 생기면 다음 시도를 하기 어려워진다. 그래서 코드 품질이 중요해진다. 읽기 쉬운 코드, 테스트, 적절한 구조는 새롭게 알게 된 사실을 제품에 빠르게 반영할 수 있게 해주는 기반이다. 우테코에서 이런 원칙들에 대해서도 배웠다.

 

하지만 이 원칙들을 그대로 지키기엔 애매하다. 실제 문제에 저런 것들을 적용하면 효과가 있는 상황도 있지만, 비용이 너무 크거나, 다른 접근이 필요한 상황도 만나게 된다. 그때마다 우리는 원칙의 목적과 조건을 이해하면서 조정을 해야한다.

이때 나오는 것이 수파리이다. 

- 수: 좋은 실천법을 따라하며 경험을 쌓는다.

- 파: 그 실천이 왜 효과적이였는지, 어떤 상황에서 한계가 있는지 확인한다.

- 리: 목적과 제약을 고려해 적절한 방법을 스스로 선택하고 결과를 확인한다.

"우테코에서 이렇게 배웠으니까"를 벗어나서 우리는 왜 이걸 해야하는지 생각을 하고, 각 문제 상황, 조직, 사용자 피드백에 따라서 지금의 품질과 구조를 결정할 줄 알아야 한다.

 

그 외 조언 및 질의응답

- 속도보다 방향이 중요하다

- 성장과 안정을 둘다 해야한다. 쉬는 것도 할 줄 알아야 한다. 몰아서 쉬지 말고, 번아웃이 오기 전에 주기적으로 쉬자.

- 리더십을 기르자. 리더십은 리더에 있을 때만 나오는 것이 아니라 팔로워일때도 나온다.

- AI시대의 인지 부하는 어떻게 다룰까? -> AI를 써서 더 많은 일을 할 수 있다는 것은 더 넓은 업무를 담당하게 된다는 뜻이다. 여러 작업의 맥락을 이해하고 지시하고 중간 판단을 내리고 작업 사이를 오갈 수 있어야 한다. AI를 코딩에만 쓰지 말고, 사람이 이해하고 판단하는 부담을 줄이는 데에 활용해야한다.

- 함께 일하고 싶은 동료는 누구인가? ->  훌륭한 사람들이랑 일해야한다. 기술적인 실력 뿐만 아니라, 인격적으로 좋은 사람, 함께 협력하는 사람, 실력이 있는 사람, 계속 성장하려는 사람이다.

- 문제를 파악하고 좋은 질문을 하려면?(경험이 적으면 무엇이 문제인지조차 알아보기 힘든 것 같다.) -> AI와 대화할 때 한번 더 파고드는 연습을 해보자. AI가 어떤 방식을 제시하면 수용하기보다 모르는 부분과 의심스러운 부분을 물어보자. (이것은 무엇인지, 왜 이 방식인지, 이 설명이 정말 맞는지, 그 이유는 무엇인지. ) + 5Why를 잘 써보자.

- 직접 써보고 실패해보자. 직접 써본건 책에서 읽은 것과 다르게 남는다. 그런 경험을 쌓다보면 판단력이 생기고, 자신의 경험을 말하고, 자신의 언어로 설명한다. 거대한 프로젝트만 생기기보다 당장 써먹을 수 있는 작은 프로그램을 만들어보자

- 개인적으로 인상 깊었는데, 복잡하고 복합적이고 불확실한 문제를 맞닥뜨렸을 때 해결 방법을 도와주는 매트릭스이다. 커네빈 프레임워크라고 하는데, 많이 써먹을 것 같다.

 

개인적인 깊생 및 느낀 점

군대에서 <차라투스트라는 이렇게 말했다> 를 읽은 적이 있었다. 물론 나에게 너무 어려워서 읽다가 그만 두었었는데, 앞장에 나오는 부분이, 처음엔 낙타처럼, 그 이후엔 사자처럼, 최종적으로는 아이처럼 행동하라는 뜻이다. 낙타처럼의 의미는 우선적으로 지식, 사회적 규범등을 낙타처럼 수용하고 받아들여라는 뜻이다. 사자처럼의 의미는 낙타의 삶(기존 권위, 지식, 규범)에 반기를 들고 왜라는 질문을 하는 단계이다. 아이처럼 행동하라는 뜻은 사자처럼 대한 후에는 나만의 가치를 스스로 만들어가라라는 의미이다. 강연에선 일본 가라데 수련자들이 하는 수파리 라는 내용으로 나왔던 것 같다. 

그게 상철님이 예시를 들어주신, 딱 폭포수 모델인 것 같다. 폭포수(탑다운)는 처음엔 별 생각없이 받아들여졌지만, 현업에 있는 개발자들이 사용자가 쓰기 좋은 소프트웨어를 만들지 못한다고 인식했고, 그 결과로 나온게 애자일(바텀업)인 것 같다.

나는 바텀업이라는 방법을 처음 들었을 때 이게 정답이다! 싶었다. 우테코에서 팀플에서 여러가지 시도를 해보면서 충분히 바텀업으로 잘 올라가고 있다고도 느꼈다.

다만 바탐업에도 약간의 문제가 있었다. 작은 부분들 하나하나에 집중하고 해결하다보니, 팀원들이 생각하는 우리의 큰 그림이 다 달랐다. 핵심 가치와 핵심 기능도 달랐다. 그래서 나는 다시 폭포수처럼 생각하기 시작했다. 그러다보니 머릿속에서 우리가 나아가야할 그림이 잘 보이고, 팀원과 이 그림을 일치시키려고 노력하기 시작했다. 새로운 가치(바텀업)도 무너지고, 아이처럼 생각해 다시 바텀업과 탑다운을 합친 형태의 사고를 시작했다.

<차라투스트라는 이렇게 말했다>를 읽으면서 들었던 생각은, 우리가 만든 가치 또한 결국 빛바랜 낙타의 지식이 될 수 도 있는데 그러면 그 가치를 다시 부숴야 하고, 새로운 가치를 만들고. 그 가치또한 무뎌지고, 새로운 가치를 만들고 무한 반복을 해야하는 것인가? 라는 생각이였다. 한때는 그러면 우리는 왜 새로운 가치를 만드는 것이지? 어차피 없어질 가치 왜 다시 만들고 적응해나가야 하지? 하는 질문이 들었다. 그리고 이 질문을 파도에게 그대로 물어봤다. 파도는 우리가 이 가치를 버리고 다시 만드는 이 행위 자체가 가치가 있는거라고 했는데, 와닿지 않았다.

오늘 강연을 들으면서 그런 허무주의적인 생각을 버렸다. 강연을 보면서 예시를 들어주시니, 파도가 말한 것 처럼 이 행위 자체가 가치가 있다고 느꼈다. 우리가 결국은 살아가야 하기 때문에, 변화에 적응을 적응 하기 위해서는 계속 이런 활동을 거칠 수 밖에 없다. 내가 탑다운이 답이라고 생각했다가, 바텀업을 답이라고 생각했는데 어쩌다 보니 두 방식 모두 생각해보는 방식은 내가 스스로 만든, 경험해본 가치였다. 어쩌면 우테코는 이런 생각 흐름을 변화시켜주는 유연성을 많이 길러주지 않았나 하는 생각도 있다.

 

여하튼 창조를 할 줄 알아야 할 것이다. 그래서 지금 당장 블로그도 쓰고 있는 것 같다. 머리에서 생각하는 것에서 벗어나 나만의 언어로 정리하고 말하는 것을 멈추기 않아야 할 것이다. 방과후 수업도 한다 한다 해놓고 1주정도 미루고 있는데, 다시 한번 일단 저지르고 봐야할 것 같다. 이제 사자에서 벗어나서 어린아이가 되어야지.

---

매번 느끼지만...인생 또한 TDD이다. 우테코에서도 매우매웅매우 체감중이고 내가 여태 살아온 걸 생각했을 때도 TDD를 계속 거쳐온 것 같다. 

또... 포비가 항상 말씀하신 반란군이 되어라는 말을 다시 한번 더 생각해봤다. 이건 다른 글에서...

 

나는 어떤 개발자일까?

강연의 내용은 사실 나만의 "가치"를 만드는 개발자라, 나는 어떤 개발자인지 고민하는 거랑은 다른 계열인 것 같다. 그래도 코로구의 질문을 생각했을 때, 나는 어떤 개발자인지 생각해보고 싶었다.

당장 생각하기로는 한 문장 내로 정리하기는 힘들 것 같다. 너무 다양한 모습을 갖고 있는 것 같아서... 우선 나열해보자면 아래와 같은 모습들을 가진것 같다.

- 사람들의 불편도 좋지만, 불행을 풀고 싶어하는 개발자이다. 

- 다른 사람과 함께 하는 것을 즐겨 하는 개발자이다. (사람을 좋아한다.)

- 다양하게 여러 시도를 하고 실험을 해볼 수 있는 환경을 좋아하는 개발자이다.

- 다양한 방안을 찾아보고 스스로 결정 내리는게 재밌는 개발자이다.

- 기술의 근본적인 철학을 좀 더 이해하고 왜 써야하는지 좀 더 생각을 해보는게 재밌는 개발자이다. "왜"를 정말 좋아한다. 

- 세세한 디테일도 좋아하고, 큰 구조에서 어떻게 변경을 적게 만들지 고민하는 것도 좋아하는 개발자이다. 

이 내용은 언제든지 바뀔수는 있는 내용이지만, 당장 내가 살면서 느낀 나의 특징이다. 이런걸 정리할 수 있는 시간을 가진 것 만으로도 되게 가치 있는 시간이였다.

 

++) 코로구 되게 멋있으시다. 나도 배워야겠다. 여러번 뭔가 마음을 먹어도 이게 쉽지 않달까,,, 코로구도 감사하고 성철님도 감사합니다..!

++++) 내용이 정리가 잘 안되서 다시 한번 생각해보려고 제미나이에게 강연 요약 시켰는데 이녀석 교육이 좀 필요할 것 같다.... 

꼭 제미나이는 뭐라해야 잘듣는다.