백엔드 개발자의 인프콘 2024 후기 - 2 (장문 주의)

1편에 이어서 나머지 세션에 대해 후기를 이어가도록 하겠다.

경력이 늘 수록 CS 이론이 중요해지는 이유 - 최호성 님

경력이 늘수록 CS이론이 중요해지는 이유 - 최호성 님

최호성님은 개인적으로 내가 정말 좋아하는 분이다.

유튜브에 올려주시는 네트워크 및 데이터베이스 강의는 대학시절부터 지금까지도 큰 도움이 되었다.

세션은 주로 발표자 소개와 CS가 왜 필요한지, 시간이 갈 수록 CS를 공부하는게 얼마나 더 어려움이 되는지 등을 발표해 주셨다.

 

신입 개발자보다는 경력 개발자를 위한 세션이라는 생각이 들었다. 또한 몇년전에 아주 핫했던 국비지원에 대한 사견도 말씀해 주셨다.

가장 중요한건 역시 '강사'를 잘만나는 것.

나 역시 13년 정도 운동선수 생활을 하다가 대학으로 편입하여 공부를 힘들게 해왔기 때문에, 남일이라고 전혀 생각되지 않았다.

 

고민 상담(?) 메일에 대한 발표자님의 답변

최호성님께 많은 사람들이 메일을 보내는데, 그 중에서 몇가지 사례를 소개해 주셨다.

그 중 하나가 바로 비전공자 출신 개발자 분께서 나름 유명한 IT 기업으로 이직 후에 자신의 경력에 대해 고민하는 내용과 최호성님의 답변을 공유해 주셨다.

 

질문자 분께서는 SI 업체에서 수년간의 경력을 쌓으시고 다른 회사로 이직하게 되셨는데, 그 회사가 기술성이 대단히 중요한 업체였다고 한다. 그런데 입사 후에 멘붕이 오신 케이스였다.

지금까지는 기획서만 보고 기계적인 코딩을 해왔고 그러다 보니 웹의 성능이라던가 운영에 대한 노하우가 조금 부족해서 어려움이 있었던 듯 하다.

 

경력이 5년정도 되는데 이러한 노하우가 부족하기 때문에 개발자를 계속 해야하나..? 이러한 고민을 하시게 되었던 케이스이다.

결론적으로 발표자 분께서는 '이제라도 CS이론을 공부해야 한다' 라고 말씀하셨다.

 

또 하나의 사례로는, 컴퓨터 공부 순서에 대한 고민이다.

취업 혹은 이직을 하려면 공부를 해야한다. 코딩 테스트, CS이론, 프레임워크 등.. 정말 많은 양의 학습을 해야하는데, CS이론으로 다시 돌와서 공부를 할때 갈피를 못잡는다는 이야기였다.

 

예를 들어, 컴퓨터 구조와 운영체제 둘 중 뭐를 먼저 공부해야 하는가?

나는 속으로 '컴퓨터 구조 먼저 아닐까?' 라고 생각을 했다. 실제 대학에서도 컴퓨터 구조는 보통 저학년때 배우는 수업이다.

운영체제는 프로그램이고 프로그램은 컴퓨터 위에 올라가고 그럼 컴퓨터 구조를 아는게 먼저라고 생각했다.

 

결론적으로 말하면 순서는 없다고 한다.
컴퓨터 구조 공부하다가 운영체제로 가고, 운영체제 공부하다 보면 다시 컴퓨터 구조와서 다시 운영체제를 공부해야한다.

여기서 이해와 암기의 경계를 말씀하셨는데, 이해는 어떤 결과적인 현상으로 보이는 것이고, 그것에 도달하기 위해 일정 수준의 암기는 어쩔수가 없다. 고통스럽게 외워야 한다.

그걸 외웠다가 다른 걸 보니까 그것에 의해 이해로 이어지는 경우가 많다고 하고, 그것이 반복이 될 수 밖에 없다고 한다.

운동선수와 개발자의 차이

손웅전 감독님의 자서전에 보면 '모든 것을 기본에서 시작한다' 라는 책을 소개하시면서 거기에 나오는 내용중에 예체능을 하는 사람들은 타이밍이 있다고 한다. 어느 나이대 어느 수준에서 그걸 그 나이에 성장기에 갖춰주는 것. 그건 되돌리기가 힘든것이라고 한다.

 

그럼 소프트웨어 개발은 어떤가?

다행히 조금 다르다고 한다. 소프트웨어 개발은 꼭 어렸을 때부터 할 필요는 없다. 하지만 경력이 5년 6년이 쌓인 시점에서 다시 CS 이론 공부하는건 어지간한 결심으로는 쉽게 되지가 않을 것이다.

나이가 30대 중반이거나 결혼해서 아이라도 있다면 상황은 더욱 좋지 않다. 운동선수 처럼 꼭 어렸을 때 해야하는건 아니지만 분명히 적절한 시간대가 있는건 맞는 것 같다고 한다.

CS 의존 관계

CS이론에 대한 이해가 부족하면 현상만 배우게 된다. 즉, 근간적인 지식은 똑같지만 경력이 쌓일 수록 변화에 적응하기 어려워진다.

그래서 시간이 있다면, 그리고 적절한 시기라면 CS를 게을리 하면 안된다.

세션 중에는 CS 의존 관계에 대한 내용이 나왔는데 무척 공감이 되었다.

프로그래밍 언어, 즉 컴퓨터 구조에서 직접적으로 의존하게 되는건 C언어를 본다. 그런데 컴퓨터 구조에는 스택이라는 말이 기본적으로 들어있고 스택은 자료 구조다. 그런데 자료 구조의 어떤 논리를 프로그래밍 언어로 써놓는다. 그래서 프로그래밍 언어를 공부하려고 했더니 컴퓨터 구조와 운영체제에 대해서 알아야 한다.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

 

그렇게 공부를 하다보면 데이터베이스를 만나게 되는데, 데이터 베이스는 앞으로 청중들을 가장 많이 괴롭히게 된다고 한다.

의존성으로 따지자면 데이터베이스라는 시스템은 IT 시스템에서 근간이 되는, 뿌리에 해당한다.

 

만약에 이 DB가 흔들리게 된다면 엄청난 후폭풍이 날라오게 되어있고 그게 결제랑 연동되는 순간 초 대형 사고가 되는것.

그래서 운영 체제 및 컴퓨터 구조를 잘 알게 되면 장애 대응 해결 능력이 굉장히 뛰어나 진다고 한다.

데이터베이스도 결국 프로그램이고 운영체제도 결국 프로그램이다. 그래서 컴퓨터 구조를 잘 알아야한다.

결론

이 외에도 전산학의 근간적인 이야기가 많이 나온다. 아주 재밌고 유익한 시간이였고. 개발자로 약 3년 7개월정도 근무하고 있는데, 그동안 놓치고 있었던 CS책을 펼쳐볼 수 있는 계기가 된 것도 같다. 확실히 연차가 늘어날 수록 일은 바빠지고 개인 공부를 하기에는 더 어려워 지는 것 같다.

 

추가적으로, 최호성님은 네트워킹 세션에도 참여하시고, 다른 연사자분의 강의도 열심히 참여하셨다!

성장에 대한 부분이 지금까지도 대단하신 것 같다. 정말 배울점이 많다고 느껴지게 되었고 나에게 동기부여가 되었다.

 

클린 스프링:  스프링 개발자를 위한 클린코드 전략 - 이일민(토비) 님

클린 스프링 세션

아주 유명한 강사분이시다. 저자분이 '토비의 스프링' 이라는 아주 유명한 책을 집필하신 저자신데, 인프런에도 강의가 있다.

첫 인상은 아주 인상이 좋으셨고 그리고 의외로 굉장히 유머러스 하셨다.

그리고 3시에 세션이 시작이였는데 해당세션은 2시 30분부터 줄을 서있었다.

사실 클린 스프링(?) 이라고 해서 궁금해서 들어보았다. 그런데 스프링 이야기보단 클린 코드 이야기가 주가 되었다.

 

 

클린 코드?

클린 코드

'작동하는 깔끔한 코드'

클린 코드는 개발자라면 한번쯤 들어봤을법한 키워드이다. 말 그대로 깨끗한 코드, 유지보수성 높은 코드,  읽기 쉬운 코드를 작성하는 방법론이다. 이러한 클린코드는 TDD와 아주 깊은 관련이 있다.

클린 코드는 구현 시작단계에서 100퍼센트 완벽하게 클린한 코드를 작성하라는 개념이 아니다.

하지만 지금도 이 클린 코드에 대한 갑론을박이 이어진다. 바로

 

'클린 코드를 지향할 수록 구현능력이 떨어진다'

 

심지어 클린 코드, TDD 등의 키워드를 이력서에 넣으면 주의 딱지를 붙이는 곳도 있다고 한다.

나도 개발을 하다보면, 이 코드는 클린한가? 라는 생각이 들 때가 있다. 그때마다 Chat GPT에게 리뷰를 받거나, 동료에게 물어보기도 하는데, 확실히 그런 고민들을 하다보면 구현 속도가 느려지는건 사실이다. 그렇다. 나 조차도 클린 코드의 핵심적인 부분을 놓칠때가 있다.

 

클린 코드는 유지보수성을 위한 것이라고 할 수 있다. 그렇지만 클린 코드를 작성하면 개발 생산성이 떨어진다고 한다.

발표자 분께서는 이런 말씀을 하셨다. 개발생산성과 유지보수성은 서로 배타적이지 않다.

 

'유지보수성을 지나치게 추구하면 생산성이 떨어지고 그렇다고 생산성만을 추구하면 유지보수성이 떨어진다.'

예를 들면 이런 사례이다. 

??: "가장 클린하고 유연하고 깔끔하고 어떤 변화에도 대응할 수 있는 회원 가입 기능을 6개월 동안 개발하겠습니다!"

이렇게 된다면 좀 곤란할 수 있다.

그렇다고 유지보수성을 완전히 배제하고 생산성만을 추구한다면 나중에 유지보수성이 매우 떨어져서 결국 개발 생산성이 떨어져 버리는 문제도 있을 것이다.

 

발표자 분께서는 분명히 개발 생산성과 유지보수성은 서로 영향을 주고 이 두가지가 더 둘 다 좋은 쪽으로 영향을 줄 수 있는 그런 관계로 만들 수 있다고 생각한다고 말씀하셨다.

그럼 어떻게 하느냐?

위에서 언급했던 '기술부채' 이야기가 이 세션에서도 나온다.

우리가 개발하는 소프트웨어에 대한 현재의 이해를 반영하고, 코드를 빠르게 작성하고 그리고 빠르게 출시해라. 그리고 이러한 시간을 그만큼 빌려오는 것이다.

여기서 중요한건 현재의 이해이다. 여기까지는 분명하다 싶은 부분만 가지고 출시하는 것이다.

이제 어느정도 시간이 지나고 나면 '아 이게 아니였구나' 라는 것들을 발견하게 되고 그것을 다시 코드에 반영을 하는게 '부채를 상환한다' 라고 이야기한다.

부채상환은 '리팩터링' 이라고 표현하고 이러한 리팩터링을 해서 부채를 갚지 않으면 결국엔 나중에는 감당하지 못하는 수준이 되버리는 것이다.

 

기술 부채라는 것은 코드를 대충 작성해도 된다는 것이 아니다. 부채는 나쁜 코드에 대한 변명이 될 수 없고, 부채를 갚으려면 리팩터링을 해야되니 처음부터 리팩터링하기 좋은 코드를 만들어야 한다는 논리이다.

다만, 소프트웨어가 어떻게 발전해 나갈지를 다 알 수 없으니 현재 우리가 알고있는것을 기반으로 코드를 빠르게 만들어야 한다는 것.

 

유지보수성이 좋은 코드는 변경 가능성이 좋은 코드다. 변경 가능성이 좋은 코드는 빠르게 변경할 수 있고, 빠르게 변경된 코드는 개발 생산성이 좋다고 이야기 할 수 있다. 그리고 이 코드는 다시 유지보수성이 좋은 코드로 만들어야 한다.

이 유지보수성이 좋은 코드로 만들때 하는 작업은 '리팩터링' 이다.

 

발표자 분께서는 위 과정을 '클린 코드 선순환'이라고 이야기 하고싶다고 했다.

클린코드는 결국에 유지보수성과 생산성 두가지를 다 추구할 수 있도록 하는 출발점이 되는 것.

 

하지만 어려운건 시작, 시작할 때는 이것저것 배운것도 넣고싶고 유행하는 것도 써보고 싶고 이런 생각 때문에 결국 사이즈가 커지게 되고 아까 언급했던 간단하게 시작하는 것 조차 잘 안되는 경우가 많다. 그래서 익숙한 기술로 간단하게 시작을 해야한다고 강조한다.

'핵심 기능에 집중하는, 그리고 동작하는 코드를 만들어야 한다.'

 

 

결론

구현, 테스트, 배포

 

결론적으로 리팩터링을 해서 부채를 갚아야 하는데, 이때 중요한건 '테스트'다. 리팩터링을 하려면 테스트를 작성해야 하고 테스트 생성이 시간을 오래 잡아먹으면 안된다. 클린코드 선순환 구조를 따를려면 절대 생산성이 저하되서는 안된다. 그럴려면 테스트를 빠르게 작성하는 노하우가 필요하다. 테스트 라는 것은 비지니스 로직보다 시간이 많으면 2배는 소요된다. 그래서 테스트 작성을 빠르게 하는 것을
토비님의 강의를 보면 알 수 있다고 한다(?)

 

세션을 듣고 나서 클린 코드에 대한 생각이 많이 바뀌었다. 나는 정말 발표자가 이야기했던 클린코드 선순환 구조를 따랐던 것인가?
책으로 봐서 모르던 내용은 아니지만, 다시한번 와닿게 되었다.

 

회사에서 업무를 할 때 잘 참고를 해서 적용을 해보면 좋을 것 같다.

 

한가지 또 인상깊었던 것은, 마지막에 발표자 분 께서 '교양있는 개발자'가 되라고 이야기 하셨다.

개발자를 하다보면 안되는건 정확하게 안된다고 해야하고 부정적인 의사를 표출해야 할 때가 많다.

하지만 똑같이 부정적인 말을 해도 기분나쁘게 말하지 않는 사람이 있다. 

본인도 회사에서 일을 하다보면 비슷한 경우를 겪는데, 가장 좋은건 건조하게 의사를 표현하는 것이 가장 좋다고 생각했다.

하지만 교양있는 개발자가 되어서 지금보다 더욱 더 같이 일하고 싶은 동료가 되는것도 좋다고 생각한다.

마치며

인프콘에서 제공한 굿즈 (더있다)

인프콘은 처음이었는데, 굿즈를 이정도로? 많이 준다고?? 싶을정도로 굿즈가 많았다.

사실 들고다니기 힘들어서 중간에 차에 두고왔다.

 

나는 이런 컨퍼런스가 있으면 모든 세션을 녹음하고 따로 저장한다. 이번에 알게되었는데 갤럭시 폰에는 통화 녹음 텍스트 번역과 요약 기능을 제공하고 있었다. 그래서 정리를 따로 하긴하지만 이번엔는 엄청나게 수월하게 정리했다. 하지만 블로그에 전체 내용을 전부 떄려넣어서 포스팅을 하지는 않는다. 뭔가 세션의 전체 내용을 요약을 하기에는 '이럴바엔 강의를 보는게 낫지않나..?' 라는 생각도 있기 때문에 (사실 글을 작성하는 것도 좀 힘들다) 강의 내용에 핵심만을 작성하려고 했다.

 

어쨌든 이번 인프콘 참여로 인해서 다시한번 동기부여가 생긴것 같다. 너무너무 즐거웠고 내년에 기회가 된다면 꼭 한번 더 참여하고싶다.

심지어 이 강의를 인프런에서는 따로 또 올려주신다. 얼마나 감사한가..!

 

내년에는 차라리 선착순이기를 바라며 마친다.