[회고] 백엔드 공부 회고(2024)

목차

1. 백엔드 공부 시작 계기와 공부 방법
2. 프로젝트 이력과 느낀점

백엔드 공부 시작 계기 와 공부 방법

진로를 고민하던 2학년…

2학년 여름 방학 뭔가 학교 전공 시간에 배운 자료구조 , 알고리즘을 배우긴 했는데 뭘 해야할까 고민하던 시기였던거 같다.

전공 수업 시간에 배운 웹 기초 , 요즘 유행하는 인공지능 , 코테를 위해선 필수라고 소문이 자자한 자료구조까지.. 다 공부를 나름 열심히 했지만 시험을 위한 공부를 했던것인지 워낙 각각이 많은 내용인지 방학이 되면 뇌가 초기화 되는 것인지 남는게 없었다.

방학동안 뭐라도 공부하고 싶은데 진로가 안정해져 뭘 할지도 모르겠다는 생각이 들었다.

그렇게 스트레스가 쌓이던 와중에 내가 이렇게 진로를 못정하는 이유가 진로에 대해 몰라서 아닐까? 라는 생각이 들었다.

그래서 2학년 여름 방학 목표를 “분야 찍먹을 해보자” 로 목표를 잡았다.

분야를 어떻게 찍먹할까

우선 웹과 인공지능을 찍먹해보자라고 굳게 마음을 먹은 후 이제 해볼까? 라고 생각 해봤지만 막상 하려니 막막했다.

고등학교 때처럼 커리큘럼이 정해져있는 것도 아니고 구글링을 해봐도 어떻게 공부해라라는 말이 다 달라서 마치 여러가지 갈림길 속에 덩그러니 있는 듯 했다.

그렇게 여러가지 갈림길 속에 잘모르는 인공지능은 무료 유튜브 강의를 통해서 실습 위주로 그리고 웹은 전공 때 배웠었다 하지만 전공 수업에서는 실습 위주였기에 오히려 와닫지 않았다.

이 웹 페이지가 어떻게 무슨 공식이 있을까, 이 뒤에 세계에는 어떻게 작용하는 것일까라는 궁금증이 마치 웹이라는 검은 벽을 가로막는 듯함 느낌이 들었다.

따라서 좀 깊은 지식이 있으면 좋겠다 싶어서 책으로 공부하고자 했다. 그 중에서 평이 좋았고 깊은 내용을 담은 “HTTP 완벽 가이드 책”을 읽는 것을 선택했다.

분야에 대한 흥미

공부하는 방식이 인공지능은 강의 , 웹은 책이어서 책으로 공부하는 것이 따분하니까 더 흥미가 떨어지지 않을까? 라는 걱정을 했다.

하지만 걱정과 달리 오히려 웹에 대한 흥미가 더욱 생겼다. 사실 전공 수업 때 배운 웹 지식은 아주 미약했고(2학년한테 당연한거겠지만) js 가지고 페이지 꾸미기 같은 프론트 요소만 실습 했기에 흥미가 크지 않았는데 책으로 공부한 웹은 달랐다.

HTTP 완벽 가이드에서 배운 웹은 내가 웹에 대해 가려운 부분을 긁어 주었다.

어떻게 이페이지가 뜨고 어떻게 이 데이터가 보관되고 어떻게 서버와 내 화면(클라이언트)가 통신하는지를 이해할 수 있었다.

물론 HTTP 완벽 가이드에서 나오는 웹 지식은 매우 매우 어려웠다 (2학년이었던 network 지식같은 cs 지식이 없던 나로써는..)

하지만 어려웠어도 매일 읽을 정도로 재밌었고 이해안되는 부분은 몇시간을 걸쳐서 다시 보곤 했다.

백엔드 선택

웹에 대한 흥미와 관심으로 책을 읽고 지식이 쌓이니 이제 블로그 같은 커뮤니티에서 말하는 웹 관련 정보에 대한 이해가 가능했고 공부로써가 아닌 단순한 흥미로써 웹을 공부했고 재밌었다.

따라서 진로로 웹을 선택하게 되었다. 그리고 웹 분야 중에 프론트와 백엔드 중에서는 당연히 백을 선택했다 웹에 대한 흥미는 보여지는 컴포넌트를 배치하는게 아닌 동작하는 기술과 원리 그리고 발전하는 설계에 더 관심있고 흥미로웠기 때문이다.

백엔드 공부 방법과 아쉬운 점(야생형 vs 학자형)

공부하는 방법에는 야생형과 학자형으로 크게 구분한다.

나는 학자형에 매우 가까운 사람이다. 어떤 기술을 사용하기 전에는 그 기술을 많은 이해를 해야 사용할 수 있다고 생각을 많이 했다.

이러한 생각을 한 자주 했던 이유는 정확하지 않지만 웹에 대한 흥미를 책으로 시작해서 이러한 습관적인 생각이 드는거 같다.

이러한 공부 방식에는 과거에는 나름 자부심과 확신이 있었다. 똑같은 시간을 공부하더라도 내가 다른 사람보다 더 빠르게 공부하고 더 많이 공부했다고 생각 했었다.

실제로 백엔드 프레임워크로 스프링 프레임워크를 공부했을 때 스프링 프레임워크에 대한 깊이도 있게 공부했다고 다른 1년 공부했던 선배보다 더 많이 안다고 자부심이 있었던거 같다 .

이러한 깊이 있는 공부는 무조건 장점이 확실하다. 그리고 앞으로 깊이 있는 공부에 대해 부정하고 싶지는 않다.

하지만 이런식에 공부에 단점을 느끼기까지 얼마 지나지 않는다.

이러한 깊은 이론 중심 공부 강박은 불필요한 지식과 나 자신을 겁쟁이로 만드는 거 같다.

예를 들어 프로젝트에서 mysql 을 사용하고 데이터의 동시성 제어를 할 필요 없는 프로젝트를 맡고있다고 가정하자

mysql 공부하는거 까지는 맞지만 mysql 의 락 프로토콜이나 mvcc 를 이해하지 않아도 프로젝트를 진행하는데 아무 에러 상황이 없다.

하지만 이론 중심 공부 강박이 발목을 잡기 시작했다.

똑같은 api 를 만들어도 다른 사람보다 2배 이상이나 느린 개발 속도를 가지는 걸 확인했다.

만약 이 프로젝트가 여러명이서 하는 프로젝트라면 더 최악이다. 내가 공부한다고 지연된 시간은 곧바로 다른 사람의 개발 속도에도 영향을 준다.

그래도 공부하는 학생 입장에서는 그게 맞지 않나요?

우리는 mysql 을 공부해서 시험을 치는 학생이 아니라 개발을 공부하는 학생이라는 걸 잊으면 안된다고 생각 한다.

어떤 기술을 사용할 때 팀원과의 상의 없이 혼자 그 기술에 대한 공부하겠다고 pr 을 미루는 것은 어리석다. 다른 팀원들과 review 나 토의를 통해서 조언과 피드백을 얻고 개발과 공부를 진행하는 것이 훨씬 빠르고 효율적이며 배움에도 도움되는다는 것을 깨달았다.

그리고 무엇보다 단기간에 사용하지 않는 지식을 깊게 공부하는 것은 어차피 다음번에 까먹어서 다시 공부해야한다는 것도 단점이라고 할 수 있다.

이러한 과정을 겪고 프로젝트에 필요한 기술을 공부한다면 사람들과 토의 후에 정확하게 필요한 기술의 영역을 특정하고 공부할 것이며 미련하게 책부터 피지 않고 필요한 지식만 공부하는 습관을 가지게 되었다.

그리고 평소에 공부하고 싶었지만 당장은 사용하지 않는 기술들은 프로젝트 외에 남는 시간인 잉여시간을 활용하게 되었다.

프로젝트 이력과 느낀점

이때까지 무슨 프로젝트를 해봤을까

<웹소켓으로 구현한 메타버스 재난 대피 플랫폼>

• spring
• mysql
• 웹소켓
• ec2

<감정 기반 책 추천 플랫폼 : 일심동책 >

• spring
• spring AI
• spring batch
• mysql
• mongoDB
• redis

< 성인 ADHD 를 위한 플랫폼 : todcuk>

<금오공대 IT 블로그 : 금오톡>

• spring
• cloud
• nginx
• obserability
• cicd
• db

와 프로젝트 많이 했네?

프로젝트를 많이 했지만 사실 남은게 없다.

남은게 없다는 표현이 이해가 안될 수 있다. 저 프로젝트를 진행하면서 많은 시행착오가 있었고 저기서 사용하는 기술 스택도 깊이 공부했을 거 아닌가.

물론 맞는 말이다 하지만 저 프로젝트들 중 실제로 운영중인 프로젝트가 1개 밖에 없다.

실제로 백엔드한테 가장 중요한 경험이 무엇일까?

다양한 기술스택을 개발한 경험? 물론 많은 기술 스택을 경험하면 다양한 도메인에 잘 적응 할 수 있을것이다.

네이티브 단위로 이해하는 프레임워크 기술 스택 이해도 ? 물론 깊은 기술 스택에 대한 이해도는 개발 혹은 운영 중에 발생하는 예외나 에러를 빠르게 대응하고 개발 생산성이 높아질 수 있을 것이다.

하지만 이러한 기술보다도 중요한 것은 장애에 대한 경험과 대응 경험 그리고 성능 최적화 경험이라고 생각한다.

실제로 백엔드의 많은 기술 스택을 장애 대응을 위해 혹은 성능 개선 때문에 생긴 기술이 많다.

예를 들면 로드밸런싱 , 샤딩, 다중화 , CQRS , RDB 인덱싱 , MVCC ….

하지만 이러한 기술을 아무리 따로 공부한다고 하더라도 실제로 적용해보지 못하면 무의미하다. 다시 말하지만 우린 개발자이지 공부한거 시험쳐서 등수 매기는 학생이 아니란 것이다.

그럼 프로젝트 운영만하면 좋은 개발자인가요?

그건 아니라고 생각한다. 앞선 많은 프로젝트 진행 과정에서 많은 것을 느꼈다.

예를 들면, 과한 오버 엔지니어링은 개발에 진행 속도에 심각한 영향을 준다는 것

그렇다고 당장에 프로젝트가 바쁘다고 기술을 적용안하다면(기술 부채) 나중에 큰 부담과 시간이 든다는 것

다른 사람과의 review 는 짧고 자주하는 것이 프로젝트 진행함에 더 효율적이라는 것

프로젝트의 기록은 팀과 나를 위한 것이라는 것 등등 많은 것을 배울 수 있었다.

끝으로

만약 내가 프로젝트를 하기 전으로 돌아간다면 지금까지 했던 프로젝트보다는 덜 하겠지만 많은 사람들과 다양한 도메인과 상황을 경험하고 싶다.

또한 최대한 시작은 작게 그리고 운영하면서 사용자의 피드백으로 키워나가는 경험을 하고 싶다.

아직은 어떻게 하면 프로젝트가 잘 진행될지 개발 속도가 빨라질지 유지보수 좋은 개발이 되는지 계속 경험하고 배워가는 중이라고 생각한다. 그리고 내가 공부하는 방식과 프로젝트 진행함에 따른 충돌에 계속 타협점을 찾아간다고 생각한다.