[우아한테크세미나] 개발자 원칙 후기

3/29일 온/오프라인에서 진행된 "우아한 테크 세미나 : 테크리더 3인이 말하는 개발자 원칙"을 듣고 정리한 글입니다.

야호야호 ^___^

 
어느 날 딩동 온 메일! 주제가 흥미진진해서 냉큼 신청한 세미나인데, 운 좋게 당첨이 되었다 😄
원티드 리쿠르팅도, 네이버 deview도 연달아 떨어져서 슬퍼하고 있었는데 오랜만에 당첨되어 행복...
오후 반차 쓰고 호다닥 다녀온 우아한 테크 세미나 후기를 글로 남겨본다!
 

---

 

1️⃣ 동욱 님의 "제어할 수 없는 것에 의존하지 않기"

🧑‍💻 일정을 잘 지키면서 버그는 많은 개발자 vs 일정은 못 지키지만 버그는 없는 개발자

두 명의 개발자가 있다고 가정하자. 
 
A씨는 일정을 칼같이 지킨다. 단 한 번도 릴리즈 일정을 어긴 적이 없고, 협업할 때도 재깍재깍 맡은 일을 기간 내 수행한다. 근데 이제 개발 결과물을 보면 세네 개씩 자잘한 버그가 있거나, 코드의 전체적인 완성도가 떨어진다. (유지보수성이나 가독성 등등)
 
B 씨는 반대로 버그가 하나도 없다. 완벽하다. 심지어 코드의 구조와 기능의 설계가 클린코드, 오브젝티브 그 자체다. 근데 원래 고지된 일정에서 한 3-4일은 지난 다음에야 넘겨준다. 이로 인해 팀원, 유저, 고객은 예정보다 몇일씩 더 기다려야 한다.
 
과연 어떤 개발자가 더 좋은 개발자일까? 👀

엔지니어는 고객이 원하는 기능을 고객이 원하는 시점에 서빙해야 한다!

적어도 실무에선 A 씨가 좋은 팀원이다. 항상 일정이 제1순위이며, 주어진 기간 내에 완성된 결과물을 릴리즈하는 게 중요하다.
 
하긴 이건 학교 과제를 생각하면 명확하다. 대학교 과제 제출하던 시절을 떠올려보자. 내가 문제 좀 못 풀었어도, 일단 기간 내에 제출해야 적은 점수라도 받을 수 있다. 제출 기한 다 지났는데 아 제 완벽한 십 점만점에 십점 과제를 보세요~ 해봤자 교수님은 내 과제를 안 받아주실 거다 😇
 
그렇다고 성능을 포기할 순 없다. 100점 만점에서 10-20점짜리 제품을 고객한테 돈 주고 팔 순 없으니까..! 
아무리 급해도 고객에겐 80-90점짜리 프로덕트를 제공해야 한다. 일정 안에 80-90점짜리 프로덕트를 안정적으로 제공하는 방법은 뭘까?
 

일정을 잘 지키는 개발자의 공통점 = 더 좋은 코드를 선택하는 기준이 있다!

• A 코드와 B 코드 중 뭐가 더 좋은지 고민하지 않고, 원칙에 따라 바로 선택한다. 
• 정말 중요한 부분, 설계가 필요한 부분에서만 고민하는 시간을 갖자.

고민 그거 뭐 얼마나 한다고? 할 수도 있지만, 나는 정말 크게 공감했다. 아주 사소하게는 변수나 메소드명부터, 크게는 코드 재활용성이나 성능 최적화까지 코드를 짜는 순간 순간 정말 아주 많은 생각이 들기 때문이다.
 
우리가 코딩 컨벤션을 정해두듯이, 동료 개발자에게 의견을 구하듯이, ChatGPT에게 어떤 방법이 더 좋은 방법인지 물어보듯이 나만의 좋은 코드 선택 원칙을 만들어두면 개발 시간을 아주 많이 단축할 수 있을 것 같다! 
 

✏️ 내 원칙은 "제어할 수 없는 것에 의존하지 않기"

현실 세계와 설계 사이의 결합도를 줄여야 한다.
-  실용주의 프로그래머 -

 
절대 변하지 않는다고 생각한 기능도 언젠간 바뀐다. 심지어 기능은 변하지 않더라도, 그 기능이나 데이터를 가져다 쓰는 방법에도 변화가 생긴다. (ex. 2014년 기준으로 주민등록번호의 무분별한 수집이 금지되면서, 유저를 주민등록번호로 구별하던 서비스들은 식별자를 모두 수정해야 했다.)
 
국가, 서드파티, 기획자 등.... 내가 만들지 않는 값, 그러니까 내가 제어할 수 없는 값에 의존하면 안 된다.
심지어는 DBMS에도 의존하면 안 된다. 지금 RDB를 쓴다고 그거 평생 쓸까? 분산 환경, DBMS 교체 등의 상황을 고려했을 때 SQL보다는 애플리케이션에서 값을 다루는 것이 더 안전하다.
 

예를 들면, 테스트 코드에서 LocalDateTime.now()로 현재 시간을 받아오는 행위!

 
날짜는 변한다. 매일매일, 매시 매분 매초! 매주 일요일에 할인을 하는 코드를 작성한다고 가정했을 때, 현재 시간을 직접 받아오면 해당 테스트코드는 일요일 단 하루에만 성공할 것이다.
 
js-joda, jest 등을 이용해 날짜 라이브러리와 모킹을 이용한다고 해도 동일하다. 라이브러리나 프레임워크가 교체되거나 스펙이 변하면 모든 테스트 코드를 전부 고쳐야 하니까..! 라이브러리, 프레임워크, 날짜 등 내가 제어할 수 없는 값에 의존했기 때문에 발생한 문제다.
 

그럼 그 테스트 코드, 어떻게 수정해야 할까?

 
제어할 수 없는 값은 Default Parameter 등을 이용해 의존성을 주입받아 사용하자. 테스트 코드 안에서 현재 시간을 받는 게 아니라, 테스트 메서드를 호출할 때 일요일 객체를 만들어서 던져주는 거다. 메인은 이거다. 제어할 수 없는 현재 시간이 아닌, 내가 제어할 수 있는 날짜 객체를 이용했고, 이를 통해 테스트 코드는 완전히 내 통제 아래에 동작하게 된다.
 

제어할 수 없는 코드들은 다른 기능에까지 전파된다.

 
PG 서비스를 이용해 결제하는 거대한 메소드가 있다. 이제 소스코드가 너무 많아서 난 불-편해진 거다.
 
클린코드 원칙을 준수해서 하나의 함수가 하나의 책임만 갖도록 함수를 추출해 리팩터링 했다고 치자. 과연 잘 고친 걸까? 아니다. 분리한 모든 함수에서 PG 서비스를 호출하게 되며, 의존성이 모든 함수로 전파된다.
 
따라서 제어할 수 없는 요소 하나가 있으면, 해당 요소가 사용된 코드를 사용하거나 해당 코드에 의존하는 모든 코드를 전부 제어할 수 없게 된다.
 

그럼 어떻게 수정하지?

 
제어할 수 없는, 그러니까 외부 결제 PG를 호출하는 메서드만 분리하자. 즉, 순수하지 않은 코드 = 제어할 수 없는 코드를 분리하는 게 중요하다!
 
백엔드 레이어 아키텍처, UI / Business Logic / Data가 있다고 치자. UI와 Data는 외부에 의존해야 하니 제어할 수 없는 친구들이다. 여기서 내가 제어할 수 있는 친구는 Business Logic 밖에 없다. 따라서 제어 가능한 코드 영역을 최대한 늘리고, 그렇지 않은 영역을 최대한 줄이는 방향이 좋은 리팩토링 방향일 것이다.
 
개인적으로 SOLID의 단일 책임 원칙과 의존성 역전 법칙을 생각하면서 들었다ㅋㅋ 로버트 마틴이 흡족하게 웃고 있는 상상..
 

💡 그럼 좋은 테크 리더가 되는 방법은?

지금까지 좋은 개발자, 좋은 코드를 작성하는 방법에 대해 기준에 대해 알아보았다. 그럼 한 발자국 더 나아가, 좋은 테크 리더가 되는 방법에 대해 알아보자. (나는 아직 개발 돌멩이지만...! 언젠가 써먹을 날이 오겠지 ^___^)
 

현실 세계도 객체 세계와 마찬가지로 내가 제어할 수 있는 요소와 내가 제어할 수 없는 요소가 있다.

회사의 매출, 투자, 연봉, 권고사직은 내가 제어할 수 없는 행위다. 이런 것들에 매달려선 정신 건강만 나빠진다. 그럼 이 혼란스러운 우당탕탕 뒤죽박죽 환경에서 테크 리더가 제어할 수 있는 요소는 뭘까?

바로 팀원들이 성장할 수 있는 환경을 만들어주는 거다!

 
회사 매출이 안나오고, 투자 상황이 나빠져서 연봉 인상도 상여금도 못 주는 상황이 되었다고 치자. 당연히 팀원들은 생계를 걱정하게 될 거고, 이 회사에 남아있는 게 좋은 선택인지에 대해 의문을 가지게 될 것이다. 테크 리더가 팀원들에게 월급을 주고 직접적인 복지 혜택을 안겨줄 순 없으니, 다른 곳에서 팀원들을 독려할 수 있는 포인트를 찾아야한다. 그리고 매일매일 새로운 공부거리가 생기는 개발자들에게 그 포인트가 성장이 될 수 있을 것이다. 아래와 같은 방법을 시도해보자.
 

1. 좋은 시니어 개발자에게 사내 강연 부탁하기

아는 개발자, 친구가 아는 개발자, 인터넷에서 유명한 개발자 등등.... 을 우리 회사에 모셔오진 못해도, 그분의 노하우는 흡수할 수 있도록 외부 시니어 강연을 실시해 보자. 이런 강연 문화를 확장한 결과, 팀원들이 먼저 필요한 노하우 / 강연을 먼저 부탁하는 경우도 생기더라! 
 

2. 잦은 피드백을 줄 수 있는 환경 만들기

스타트업은 개발자 수가 비교적 적고 일정이 빡빡하니, 즉각적이고 상세한 코드 리뷰를 제공해 주기 힘들 수 있다. 따라서 아래와 같은 시스템을 구축해 코드 리뷰, 직접적인 개발 피드백 비슷한 효과를 얻을 수 있게 해 보자.

• 정적 분석 툴
• 테스트 코드
• Lint, 코드 포맷팅

 

🌊 마무리

미국에서 88연승을 거둔 어느 야구 감독은 수년동안 160 km 떨어진 곳으로 팀을 데려가 연습을 해야 했다고 한다.
 
이 불편하기 짝이 없는 환경에서 어떻게 감독은 팀원들을 설득하고 격려했을까? 매일 새로운 환경에서 연습해서, 어떤 산만한 환경에서도 평정심을 유지할 수 있는 능력을 키운자고 동기 부여를 줬다고 한다. 경기장이 멀리 있는 환경도, 매번 왔다 갔다 하는 불편함도 감독이 제어할 수 없는 행위다. 그래서 감독은 그나마 그 안 좋은 환경에서도 좋은 점을 찾는 걸 시도한 거다.
 
이렇게 우리가 제어할 수 없는 요소, 안 좋은 환경, 상황은 너무 깊게 생각하지 말자.
안 좋은 일이 생겼으니 좋은 일도 생기겠지! 내가 운을 축적했다고 생각하며 내가 컨트롤할 수 있는 요소에만 집중해 보자 :)
 

---

2️⃣ 미정님의 "실패를 축하합니다"

실패가 내 성장의 동력이 되려면 어떻게 해야 할까?

💁‍♀️ 실패를 이야기하게 된 계기

미정님께선 "개발자 원칙"에서 이직에 대한 이야기를 다루셨는데, 되돌아보니 이직이라는 수단을 사용하기까지 다양한 시도와 실패를 거듭하셨다고 한다. 이제는 지났지만 한때는 내가 겪었던 장애 상황, 트러블 슈팅 등 크고 작은 실패 경험들을 서비스의 성장 단계와 연결해서 돌이켜보자.

여기서 말하는 실패는?

 
내가 계획했지만 내 뜻대로 되지 않는 모든 행위들!

• 내일부터 미라클모닝 하려고 했는데 눈뜨니까 10시네?
• PM한테 오늘까지 된다고 했는데 안 되겠네?
• 개인 또는 팀이 목표를 세웠는데, 그걸 못 이뤘네?
• 성장하고 싶은데 마음과 다르게 난 계속 멈춰있네?
• 등등...

정말 친숙한 예시들..! 사소하게는 오늘 운동을 하려고 했는데 못했다~ 까지 나 또한 일상에서 숱하게 겪고 있는 실패들이었다 😇
아래는 미정님이 실제 업무 중 겪으셨던 실패와, 그에 대한 결과들이다.
 

역할	실패 내용	결과
개발자	버그 있는 코드의 배포	사용자가 서비스 이용할 때 문제 발생
	운영 DB 테이블 삭제	데이터 복구 작업을 했는데도 데이터 손실됨ㅠㅠ
	코드 배포 후 성능 문제 발생	서버 다운! 매출에 손실 생김
	언제나 발전이 없는 것 같은, 기시감 있는 코드 작성	자괴감.....
제품 생산자	나는 개발자니까 기술만 중요해!	코드는 견고해져도 사용자는 서비스를 떠난다
	개발 문화만 너무 소중해	개발팀만 으쌰으쌰고 제품, 서비스는 후퇴
관리자 (테크 리더)	팀의 역량 파악 전 일 계획	프로젝트 중단
	개발 팀 과잉 보호	외부 팀과 소통과 신뢰가 어려워진 개발팀. 왜 너네끼리만 뭉쳐있어? 왜 맨날 안된대?
	팀원을 이해하기보단 판단하는 태도	크고 작은 이슈를 공유하기 어려운 분위기 형성

 
온라인 청취자들이 자신의 실패 경험을 공유해주셨는데, 개인적으로 수능에 실패했다는 사연이 인상깊었다ㅋㅋㅠ
 

개발자로서의 실패는 익숙한 내용인데, 생산자 / 관리자로서의 실패는 또 새로운 내용이어서 신선하더라..! 생산자로서의 나는 어떤지, 나 또한 이런 실패를 경험하고 있는게 아닌지, 그런데도 스스로 인지하지 못하고 있는게 아닌지 되돌아볼 수 있었다.

 
어쨌든 실패는 누구나 한다! 중요한 건 실패를 흐린 눈하고 넘기느냐, 실패로부터 배우고 성장하느냐다.
미정님은 위와 같은 실패를 경험하고, 그로부터 아래와 같은 것들을 얻으셨다고 하셨다. 😄
 

역할	실패로부터 얻은 것들
개발자	코드 리뷰 문화 강화
	인프라 보안 강화
제품 생산자	사용자 관점에서 고민하는 태도
	동일한 목표를 바라보는 원팀으로서의 협업 태도
관리자	일과 사람을 냉정하게 바라보고 현실을 판단하는 태도
	주도적으로 일을 찾는, 그리고 의문을 제기하는 걸 어려워하지 않는 팀 문화

 
사실 실패 하나하나가 사소한 이슈는 아니다. 운영에 영향을 미친 것도 있고, 매출에 직결되는 이슈도 있다. 하지만 그로 인해 얻은 것들은 절대 무가치하지 않다. 코드 리뷰 문화를 도입할, 인프라 보안에 리소스를 투자할 당위성과 경험을 통해서야 깨닫는 마음가짐도 얻었다. 
 

물론 실패 없이 얻을 수 있었다면 더 좋았겠지만, 실패하지 않았다면 이런 것들에 대해 고민할 수 있었을까? 해보지 않았는데 싫은지 어떻게 알겠어. 책에 쓰여진 글귀를 읽는 것과 실제 경험을 통해 필요성을 깨닫는 것엔 하늘과 땅 정도의 차이가 있다고 생각한다. 실패는 썼지만 값진 것을 얻었으니 의미있는 경험을 했다고 생각해도 되지 않을까 🤔

 

✨ 돌이켜보니 실패를 회피하는 것보단, 실패를 마주하는 게 중요하더라!

 

그러니까 결국, 실패를 했다고 아 난 뭘 해도 안될거야~~ 아 그건 어렸을 때 한거라 그래~~ 하고 회피하는게 아니라, 내 실수와 부족함을 인정하고 그걸 보완하기 위해 노력하는 과정이 중요한거다. 근데 이제 그러기 힘드니까ㅋㅋ 미정님의 실패를 마주하는 방법을 참고해보자.

 

나만의 루틴을 통해, 실패를 어려워하지 말고 실패로부터 배워보자.

 

1. 실패로 인해 우울해진 감정을 회피하지 말고 충분히 느끼자
   • 우울함.... 무력감..... 절망감.... 피하지 말고 만끽하기! 
   • 응 별거 아냐~ 난 이딴 실패에 매몰되지않고 나만의 길을 간다는 마인드도 좋지만, 얼마 안가 실패했던 경험을 홀라당 잊을 수도 있다. 실패를 인정한다는 느낌으로 감정을 느끼자.
2. 그리고 그 감정에서 빠져나오자.
   • 아 그렇다고 언제까지고 과거에 매달릴 순 없으니까~~ 평생 침울하게 살 순 없잔어
   • 어느 순간, 실패에 대해 똑같은 생각을 반복하고 있는 나를 발견할 수 있을거다. 그때가 빠져나올 시간이야 🔫
     • 내가 왜 그랬지? 00할 수 있었는데 왜 그랬을까? 등 비슷한 자책만 맴도는 그 순간!
     • 빠져나올 타이밍을 캐치했으면, 코노를 가든, 책을 읽든.. 나만의 루틴으로 감정에서 빠져나오자. 
3. 실패를 제대로 마주하자
   • 이제 감정이 좀 가라앉았으니까, 이성적으로 실제 실패 경험을 마주해 보자.
   • 최대한 감정은 배제하고, 잘한 것, 놓친 것만 현실적으로 적어보자.
     • 아니 근데 진짜 나만 잘못했냐?? 다들 다 이럴거 아냐   :: ❌
     • 이번엔 00한 상황이었고, 내가 DD는 잘 했는데 ㅁㅁ은 놓쳤다 :: ⭕️
4. 실패를 반복하지 않을 수 있는 단 한 가지 방법!
   • 실패하기 전의 시점으로 돌아간다면 이렇게 할꺼야 싶은 단 한 가지 방법을 고민해서 뽑아보자.
   • 실패를 반복하지 않기 위한 방법은 많다. 그중 전파 속도가 제일 빠르고, 실패 반복 가능성이 제일 낮아지는 것에 우선순위를 둔다.

 

⭐️ 중요한 건 실패를 대하는 루틴이 너무 무거워지지 않는 것!

 
나 지금 우울하고 너무 슬프고 힘들어 죽겠는데, 해야 할 일을 수십 가지 만들어 두면 실패가 아니라 실패 대응 루틴이 싫어질 수 있다..! 최대한 간단하지만 임팩트 있는 루틴을 만들어보자 ❗️
 
덧붙여 팀/팀원이 실패를 했을 때도, 내 실패와 동일한 루틴을 거치며 팀원을 이해하고 고민을 공유해 보자. 나 혼자가 아니라 팀원 전체가 실패를 두려워하지 않고, 실패로부터 배우는 분위기를 만들어야 전체적인 팀 개발 문화를 향유할 수 있을 것이다. 회고글을 작성하여 실패 경험을 공유하고 함께 성장하는 것도 좋은 방법인 것 같다. (미정님의 실패 회고글 링크는 👉 여기)
 

실패로부터 배우는 루틴은 TDD에도 담겨있다!

 
※ 혹시나 TDD를 모르시는 분이 계시다면? 

Test Driven Development (테스트 주도 개발)

 

기능 개발을 완료한 이후 테스트 코드를 짜는 것이 아니라, 테스트 코드를 먼저 짠 후 테스트에 통과하는 것을 목표로 기능을 개발하는 소프트웨어 개발 방법론이다. 실제 기능에 필요한 기능 위주로 컴팩트하게 개발할 수 있어 불필요한 예외 처리, 설계 등을 방지할 수 있어 개발 효율이 좋아진다.

 

TDD의 개발 주기

위의 그림과 같이 총 3 단계의 과정을 갖는다.

1. Red 단계 : 실패하는 테스트 코드 작성
2. Green 단계 : 테스트 코드를 성공시키기 위한 실제 코드 작성
3. Blue 단계 : 중복 코드 제거, 모듈화 등의 리팩토링 

 
TDD의 RED 단계는 실패하는 테스트 코드를 작성하는 것이다. 우리는 실패하는 테스트 코드를 작성하고, 그 실패를 이겨내기 위한 방향을 찾아 코드를 수정한다. 이 마음가짐을 우리의 현실에도 그대로 반영하는 마음가짐을 가져보자.
 

🌊 마무리

살다보면 난 평생 단 한번도 실패해본 적이 없다는 사람이 가끔 보인다. 와 저 사람은 항상 완벽한데 나는 왜 이 모양일까, 하고 자책할 필요가 없다. 그 사람은 그냥 실패하지 않는 안전한 길만 찾아서 걸은, 도전하지 않는 사람이니까. 
 
중요한건 실패하지 않는게 아니라, 똑같은 실패를 반복하지 않는 거다. 실패를 하지 않는 사람이 되기보다는, 실패와 결점을 인정하고 성장의 발판으로 삼아 더 나은 사람이 되는 태도가 멋있는 태도지 않을까! 😎
 

실패는 우리가 어떻게 실패에 대처하느냐에 따라 정의됩니다.
Failure is defined by our reaction to it.

- 오프라 윈프리 Oprah Winfrey -

 
그렇다고 또 모든 실패를 극!! 뽁!!! 이겨낸다!!!! 지지 않아!!! 하는 강박을 가질 필요는 없다ㅎㅎ 너무 내달리면서 모든 것에서 배움을 얻으려다가 금방 지쳐서 그만두지 않게, 내 스스로에게 부끄럽지 않을 정도의 루틴을 지키는 것에 집중해 보자.
 

관련하여 미정님께서 추천해주신 메타인지 심리학 책 링크는 👉 여기

 
 

---

 

3️⃣ 성철님의 "<덕업일치를 넘어서>에서 하고 싶었던 이야기"

 

삶은 고해다. 
이것은 삶의 진리 가운데서 가장 위대한 진리다.

- M. 스캇 펙 Morgan Scott Peck -

 
살기... 힘들다! 하드 모드인 내 인생ㅠ 하지만 인생이 힘든 건 내가 제어할 수 없다.. 앞서 동욱님이 말씀하셨던 것처럼, 우리는 제어할 수 없는 것이 아니라, 내가 제어할 수 있는 것에 집중해야한다. 그럼 이 살기 힘든 세상 이겨내기 위해 우린 뭘 해야 할까? 🤔
 

성철님께선 소프트웨어로 사람들에게 도움이 되자는 원칙을 가지고 개발자로의 여정을 시작하셨다고 한다. 나는 어떤 원칙을 가지고 개발자의 길을 걷고 있나? 솔직히 큰 생각 없이 개발을 하고 있는 것 같다ㅋㅋㅠ 우테세를 계기로 나도 나만의 개발 원칙을 고민해봐야겠다.

 

📚 "개발자 원칙"을 기획한 의도

성철님께서 개발자 원칙을 쓰게 되신 계기. 이런 책을 쓰고 싶었어!
👉 Programmers at Work
👉 영혼을 잃지 않는 디자이너 되기

 

👀 하고 싶었던 말들

1. 덕업일치를 넘어, 전문가의 길을 걸어보자!

개발자는 왜 다 애 같을까? 그리고 왜 다 애 취급을 받을까? 
 
제주도에 있는 넥슨 컴퓨터 박물관과, 실리콘밸리에 있는 컴퓨터 역사 박물관에 가보면 두 박물관에서 전시해둔 최초의 컴퓨터가 서로 다른 것을 볼 수 있다. 어떤게 컴퓨터인지를 가르는 기준마저 아직 명확하지 않은 것이다. 그러니까 따지고보면, 일단 컴퓨터 자체가 역사가 오래되지 않은거다 🧐
 

성철님 발표 자료에서 발췌

컴퓨터가 등장한 이후에도 그 길이 순탄치는 않았다. 인터넷 나오고 한번 떴다가 단절, 스마트폰 나오고 또 떴다가 다시 단절... 이렇게 골드 러시를 반복하다보니 각 분야에 깊이 있는 개발 전문가가 많이 존재하지 않는거다. 지금만 해도 그렇다. 한동안 개발 직군이 완전 핫하고 연봉도 쑥쑥 올랐는데, 최근 ChatGPT가 개발되면서 이젠 데이터 / 인공지능 직무가 강세고 개발 쪽은 한파가 몰아치고 있다 🥶
 
성철님은 대학에서 토목공학을 전공하시고, 졸업을 하면서 개발자로의 커리어를 시작하셨다고 한다. 당시 처음 개발 직군에 뛰어들었을 때 성철님보다 나이가 많은 / 경력이 많은 선배들의 수가 굉장히 적었다고 하니, 새삼 타 직군에 비해 개발 역사가 그리 길지 않구나 싶다.
 

전문가로서의 프로그래머는 뭘까??

 
위에서 전문가 전문가 했는데, 대체 왜 우리는 전문가가 되어야 할까? 전문가 말고 그냥 개발자 하면 안돼? 철학적인 이유를 잘 모르겠다면, 그냥 현실적으로 눈 앞에 닥친 위기만 생각해보자ㅋㅋ 언젠가 다시 골드러시가 올 수도 있잖아! 그럼 냉큼 다른 직무로 갈아탈거야?

아무래도 먹고 살려면 혹한기에서도 살아남을 수 있어야 한다. 줏대를 가지고, 남들과는 차이를 가져야 권고사직의 불상사에서 벗어나 안정적인 사회 생활을 영유할 수 있을 것이다😂 전문가가 되려면 애초에 전문가가 뭔지도 알아야겠지. 전문가로서의 태도에 대해 고민해보자.
 

전통적인 전문가의 정의는 "특정 직업의 구성원 또는 특정 직업 활동에 종사하는 사람"!

영화나 드라마에 나오는 해커, 개발자들은 항상 멋있어 보인다. 체크 셔츠를 입고 이상한 돋보기 안경을 쓰고 형광 초록색으로 덮인 화면을 바라보며 키보드를 부술듯이 두드린다. 전통적인 정의가 그렇다. 지나치게 개인의 기예를 강조하거나, 개발자를 대상화하곤 한다. 마치 개발자가 커다란 시스템에 녹아든 하나의 부품인 것처럼 ⚙️
 
(참고 서적 👉 소프트웨어 장인 정신 / 👉 Professional 소프트웨어 개발)
 

요즘의 전문가는? "스스로 성과의 방향을 설정하는, 자기 경영 능력을 가진 지식 근로자"!

하지만 요즘의 개발 문화는 많이 달라졌다! 전통적인 waterfall 개발 방법론이 최근에는 Azile 방법론으로 많이 대체되고 있다. 애자일은 개인을 중심으로 프로젝트를 구성하며, 팀 구성원들은 환경과 자원에 맞춰 스스로 행동을 조율하고 조정한다. 즉 협력을 중심으로 개발하는 문화가 정착된 것이다. 
 
(참고 서적 👉 구글 엔지니어는 이렇게 일한다 ⭐️⭐️⭐️ / 👉 The Clean Coder)
 
 

2. 나를 잃어버리지 않는 삶

우리 대부분은 문제를 회피하려는 경향이 있기 때문에 (중략)
자기의 문제를 피해 쉬운 길을 찾으려다, 오히려 건전한 길에서 멀어지게 된다.

- M. 스캇 펙 Morgan Scott Peck -

우리는 앞서 미정님과 실패에 대한 이야기를 하면서, 실패를 회피하고 외면하는 것보다 인정하고 마주해야 한다고 했다. 마찬가지로 문제를 회피하는게 아니라 문제에서 배우는 태도가 중요할 것이다. 여기서 문제는 단순한 개발적 문제가 아니라, 내 인간적 특성과 관련이 있다.
 
예를 들어 내가 타인에게 부정적인 피드백을 주는 걸 어려워하는 성향이라고 가정하자. 너무 좋아하는 친구인데 그 친구의 한 번씩 나오는 욱 하는 성질이 너무 불편한거다. 근데 그걸 직접적으로 말하고 친구와 갈등을 빚는 것보단, 그냥 내가 참고 넘어가는 걸 선택한다면 어떨까? 참는 것도 한두 번이지, 언젠간 폭발하지 않을까? 이제 우리는 이런 상황을 피하기 위해 나 스스로의 특성에 알아야 한다.
 
최근 아주아주 유행했던 MBTI는 모두 한 번 씩은 해봤을 것 같다! MBTI, 그리고 인터넷에서 무료로 확인할 수 있는 에니어그램 테스트를 이용해 내 성격 유형과 강점, 약점에 대해 생각해 보자. (실제 유효한 검사인지는 제쳐두고, 그냥 대략적인 성향만 파악하는 용도로ㅎ.ㅎ)
 

에니어그램 테스트
: 사람을 9가지 성격으로 분류하는 성격 유형 지표. MBTI는 행동 자체에, 에니어그램은 행동의 동기에 초점을 맞춘다고 한다.
: MBTI는 강점과 선호 경향을 강조하고, 에니어그램은 약점과 내면의 집착을 강조하는 테스트라고 하니 참고하자.

 

내 에니어그램 테스트 결과

전문가는 결국 나를 경영할 수 있는 사람이다. 내가 누군지 알고, 받아들여서, 거기서부터 성장하는 태도가 필요하다.
내가 어떤 사람이고 어떤 걸 좋아하는지 계속 찾아보자. 회사에서의 나도 나고, 퇴근한 후의 나도 나다. 개발자라는 틀에 갇혀서 나를 잊지 말고, 수동적인 사람이 되는 게 아니라 나라는 사람이 어떤 사람인지 탐구하는 게 중요하지 않을까! 💁‍♀️ 
 
삶의 신조를 세우고, 나만의 자기 동기를 관리해서 삶에서 맞닥뜨리는 수많은 실패들을 이겨내고 전문가가 되어보자.
 

🌊 마무리

개발자는.. 멈추지 않아 🔥

공대를 나왔다면, 또는 공학에 관심이 있다면 한 번쯤 무어의 법칙에 대해 들어봤을 거다. 무어 아저씨가 말하길, 반도체 집적 회로의 성능은 24개월마다 2배로 증가한다고 한다. 이렇게 기술은 매우 빠르게 증가하고 있고, 컴퓨터와 소프트웨어도 예외는 아니다. 우리는 빠른 기술 흐름 속에서 이리저리 튕기고 있는 일종의 파편인거다 🧐
 
상어는 헤엄을 멈추면 가라앉는다. 멍게는 성충이 되면 뇌를 잡아먹고 한 곳에 정착한다. 네카라쿠배에 가면 끝일까? 그곳이 내 커리어의 종착역이라고 생각하고 성장을 멈출 것인가? 
 
00에 입사한다, 00 연봉을 받는다.. 는 정적인 목표보단, 나만의 신념을 가지고 그걸 이루기 위한 인생을 살아보자!
 

---

 

4️⃣ Q&A

테크 리더의 가장 중요한 역량 하나만 꼽아보자면?

• 성철님 : 공감 능력 (다양한 사람을 이끌어야 하니까!), 성장하는 리더 (리더도 실수를 한다!)
• 동욱님 : 위임(못하면 꽈락), 호들갑 떨기 (무적의 팀이 될 수 있는 역량! 와 너 이런 걸 했어?? 너 천재야?? 누가 봐도 쪼들리는 일이여도ㅋㅋ 주접을 떨어주자! 분위기가 좋아짐)
• 미정님 : 위임 22 (팀의 과부하가 되는 요소), 사람 관리 (팀원 케어, 이해, 개인에 맞는 리더십 보여주기)

 

유연성 있게 성장할 수 있는 개발 방법이나 습관

• 성철님 : 성장하는 과정을 즐기기 :: 다음 단계로 나아가는 게 압박으로 느껴질 수도 있다. 그냥 즐겨~
• 동욱님 : "제가 틀렸네요" :: 내가 틀린 걸 인정하고 받아들이기. 주니어일수록 습관을 들여야 할 태도
• 미정님 : 내가 작성했던 코드 다시 작성해 보기/ 다시 설계해 보기!

 
이후 나온 질문은 오프라인 / 온라인에서 즉석으로 받은 질문이라 잘 안 들려서 받아 적질 못했다..! 😇 유튜브 라이브 영상을 참고하자.
아래는 세미나가 끝난 후 동욱 님께 개인적으로 여쭤본 질문이다.
 

Q. 아무래도 회사의 목적은 매출을 내는 거지, 구성원의 성장이 아니니 개발자가 개인적인 성장과 학습을 기대하긴 어려운 것 같다. 이런 상황에서 팀원이 어떤 방식으로 일과 성장을 동시에 이룰 수 있는지 테크 리더로서의 조언이 궁금하다.

A.
 
일단 일을 우선적으로 여기면서, 그 속에서 성장할 수 있는 방법을 찾는다!
 
동욱님 세션에서도 이야기했듯, 결국 회사에선 일정 안에 만족할 수 있는 성능을 뽑아내는게 1순위다. 개발자가 새로운 기술을 써보고 싶다며 개발 일정을 어기면 당연히 문제가 되지만, 반대로 얘기하면 일정 내 딜리버리만 가능하다면... 그 이후론 리더가 허용할 수 있는거다 😄
 
예를 들면, 신규 기능의 개발에 7일의 시간이 주어졌다고 치자. 7일 후에는 무조건 고객이 운영 서버에서 해당 기능을 사용할 수 있어야 한다. 그럼 개발자는 4-5일 동안 정신 빡차리고 개발 열심히 해서 일단 기능을 완성한다. 80-90점짜리의 정상 동작하는 코드를! 그러고 이제 남는 2-3일 동안 만들었던 기능을 다시 만들어보는 거다. 설계를 고치든, 코드를 리팩토링하든, 뭐가 되었든간에.
 
좋은 학습 방식 중 하나는 이미 한 것을 다시 해보는 것이다.

내가 이걸 처음 만들 때 왜 이렇게 했을까? 이건 이렇게 하면 좋을 줄 알았는데, 실제로 해보니까 이런 점에서 문제가 되더라. 지금 생각해보니 이렇게 하면 더 좋을 것 같아 등...

 
리더와 회사 입장에선, 어쨌든 일정 내에 기능을 제공할 수 있으니 문제가 없다. 그 이후에 개발자가 추가 공수를 들여 이 기능을 더 건들든 말든은 상관이 없어지는거다. 잘 되어서 최적화가 되면 이득인거고, 잘 안되어서 달라지는게 없대도 멀쩡히 돌아가는 기능은 이미 확보했으므로. (굳이 정해진 날짜보다 먼저 배포할 필요는 없잖어..!)
 
살짝 이 말씀을 듣고 정신이 아득해졌다. 맞는 말이다..! 나는 당장 어제 짠 코드인데도, 얘 대체 왜 이랬지???? 하곤 한다. 코드는 작성하는 순간부터 레거시라고 한다. 한정된 기간 안에 완성해야한다는 압박감을 가지고, 일단 무작정 짜내려간 코드의 완성도는 굳이 말 할 것도 없다ㅋㅋ 물론 그렇게 우다다 만들어도 완성도가 높게 빠져야 개발 실력이 좋은 거긴 할텐데.. 어쨌든 지금 당장의 내겐 불가능한 일이니까 😇
 
새로운 기술을 배우고, 최대한 많은 것을 경험해보는 것도 좋지만, 하나의 기술 요소에 대해 깊게 이해하는 것도 개발자가 성장하기 위해 중요한 요소라고 느꼈다. 나는 지금까지 개발 일정이 남을 것 같으면 적당히 여유를 가지고 일하거나, 그냥 빨리 끝내고 다음 태스크를 시작했는데, 동욱님의 조언을 참고해서 일과 개인의 성장을 병행할 수 있도록 좀 더 노력해야겠다! 😎
 

---

 

이렇게 퇴근 후 참여하는 우아한 테크 세미나에 대한 내용 정리를 마쳤다. 아무래도 주위에 미들, 시니어 개발자가 많이 없는 상황이라 선배분들은 어떤 생각과 어떤 고민을 하실까에 대한 막연한 궁금함이 있었는데, 우테세를 통해 많이 해결할 수 있었다 👍
 
나는 아직 돌멩이1이지만, 언젠가 연사분들처럼 누군가의 멘토가 되어 선한 영향력을 줄 수 있는 개발자가 되기 위해 노력하려고 한다. 3년 후엔 나도 저 트랙방에 서서 발표하는 목표를 세우며, 오늘도 화이팅~~!