우테코 Level2 회고록

Level2의 핵심 주제는 나만의 공부법 찾기였다. 

이 목표를 잘 달성했는지, 또 핵심 주제 외적으로 어떤 걸 배웠는지 기록을 남기고 싶어 회고록을 작성하게 되었다.

---

기술적 성장

Level2는 기존의 콘솔 환경에서 벗어나, 웹사이트를 띄우고 배포하는 것을 목표로 하는 커리큘럼이다. 다음과 같은 핵심 기술들을 배웠다.

 

Spring + WEB 통신

Spring이 뭔지, 왜 사용하는지, 클라이언트와 서버가 어떻게 통신하는지에 대해 전반적으로 학습할 수 있었다. 예전에 같이 작업하던 동료 개발자분이 Spring은 왜 사용하는 거예요?라고 물어본 적이 있는데, 제대로 답변하지 못했었다. 지금 Spring을 왜 사용하는 거냐고 물어본다면, 수많은 장점이 있지만 컨테이너가 객체를 관리해주기 때문에 개발하기 편하다라고 답할 것 같다.

 

만족하는 부분

이전에 Spring으로 프로젝트를 해봤지만, 스프링이 뭔지 설명을 하라고 하면, 설명할 수 없었다. 즉 스프링에 대한 이해도가 아예 없다고 해도 해도 무방하다. 이번 Level2를 통해 스프링이 뭔지, 어떤 식으로 동작하는지 얼추 감을 잡을 수 있었다. 특히 스스로 꼬리질문을 하며 내가 어디까지 알고, 어느 부분을 모르는지 파악한 게 좋은 공부법이지 않나 싶다.

https://codingmasterlsw.tistory.com/42

Spring Core 꼬리 질문 해보기

 

 

아쉬운 부분

깊이 있게 학습할 시간이 없었다. 기본적인 것만 이해하는 데에도 벅찼다. Spring이 무엇이고, 어떤 흐름으로 굴러가는지에 대한 이해만 했다고 생각한다. 기본적인 어노테이션의 역할, 사용법 정도 익혔다고 생각한다.  또한 커리큘럼 내에서 배운 ArgumentResolver, Interceptor에 대해 아직 이해도가 부족하고, 추가로 공부해야 한다고 생각한다. 이해하지 못 한 이유는 Spring의 통신 과정에 대한 학습이 부족하기 때문이라고 생각한다.

 

앞으로 학습해볼만한 내용

Spring 통신 과정에 대해 우선 학습하려고 한다. ex) Tomcat이 뭔지, Dispatcher Servlet이 뭔지, 클라이언트가 요청을 보내면 어떤 순서로 서버에 도착하는지

 

+ 미션 설명에 나와있는 Deep Dive 내용을 추가로 공부해 보면 좋을 것 같다

• build.gradle에 새로운 의존성을 한 줄 추가하면 어떤 일이 발생하는가?
• gradle에서 제공하는 build와 clean은 무엇인가?
• XHR
• library, web framework 를 모르는 사람에게 뭐라고 설명하면 이해하기 좋을까?
• 웹서버 vs 웹 애플리케이션 서버
• HTTPS
  • 대칭키 암호화(Symmetric Key Cryptography)
  • 공개키 암호화(Public Key Cryptography)
  • TLS(Transport Layer Security)
• Sesssion
  • Client-Side Session
  • Server-Side Session

 

JPA

 

JPA가 뭔지, Hiberate가 무엇인지, JdbcTemplate을 사용했을 때와 비교해 JPA를 사용하면 어떤 이점이 있는지에 대해 배울 수 있었다. 간략히 말하자면 영속성 컨텍스트, Entity의 연관관계, fetchType, transaction을 배울 수 있었다. 더 자세히 말하자면 dirty checking 동작원리, Entity 객체를 생성하는 방법, EntityManager의 동작 방식, JPA의 쿼리 생성 방식, @GenerateValue의 전략, N+1 문제 해결방법 등에 대해 학습할 수 있었다.

 

만족하는 부분

스프링과 마찬가지로 JPA라는 기술을 왜 사용하는지, 장단점은 어떤게 있는지, 내부적으로 어떻게 동작하는지에 대해 감을 잡을 수 있어 만족한다. 과거에는 책을 처음부터 끝까지 읽으려니 학습이 지루하기도 하고 쉽게 포기했는데, 내가 궁금한 부분만 책에서 찾아 읽으니 집중도가 훨씬 높아 만족스러웠다.

 

아쉬운 부분

미션을 진행하며 양방향 관계를 최대한 지양했다. 그러다보니 양방향 관계로 설계했을 때 어떤 단점이 있고, 어떤 장점이 있는지 직접 몸으로 느껴보지 못했다. 그러다 보니 Cascade를 어떻게 사용해야 하는지, 양방향 관계로 설계했을 때 얼마나 복잡해지는지 등을 경험해 보지 못해 매우 아쉽다. 또한, N+1 문제가 발생했을 때 Fetch Join을 사용해 해결할 수 있다 하는데, 실제로 내 코드에 사용해 보지는 못 해 아쉬웠다.

 

앞으로 학습해볼만한 내용

- 양방향 관계를 직접 사용해 보며 어떤 장단점이 있는지 느껴보는 게 1순위라고 생각한다. 그 과정에서 cascade의 용도 또한 자연스럽게 알 수 있을 것 같다.

- Fetch Join의 동작 원리, 장단점

 

외부 API 사용 / 배포 및 로깅

해당 섹션은 그래도 해본 경험이 있어 그렇게 어렵게 느껴지진 않았다. 외부 API를 사용하는 과정에서 외부 서버와 통신할 수 있는 기술들을 배웠다. ex) RestClient, RestTemplate, Shell Script 작성 방법

 

만족하는 부분

외부 API를 사용할 때 어떤 식으로 요청이 왔다갔다 하는지 전반적인 흐름을 이해할 수 있어서 좋았다.

 

아쉬운 부분

비즈니스 로직 일부에 꽃혀 시간을 많이 사용했다. 결과물이 만족스럽긴 하지만, 많은 크루들이 고민한 외부 API에서 오류가 발생하면 어떻게 처리해야 할까? 에 대해 깊이 있게 고민해 보지 못했다. 또한 많은 크루들이 외부 API 테스트 코드에 대해 깊이 고민을 하는 모습을 볼 수 있었는데, 테스트 코드에 대한 학습이 전반적으로 부족하다고 느꼈다. 귀찮기도 하고, 그냥 눈으로 대충 확인하고 넘어가는 습관을 가지고 있는데, 꼭 고쳐야 하는 부분이라고 생각한다. 또한 http request, response에 대한 로그를 찍을 때 Spring AOP를 사용한 크루들도 있는데, AOP를 아예 모르기에 추가로 공부해 보면 좋을 것 같다. (필자는 filter를 이용해 로그를 찍었음)

 

앞으로 학습해 볼 만한 내용

- 외부 API에서 오류가 발생하면 어떻게 처리해야 할지 고민해 보기

- 외부 API 테스트 및 통합 테스트 코드에 대해 나만의 기준 만들어보기

---

소프트 스킬의 배움

 

내가 몰랐던 나를 발견한 순간

 

수업 중 이해가 되지 않는 부분이 있어 코치님께 질문을 했다. 코치님은 나에게 '혹시 화난 건 아니죠?'라고 여쭤봤다. 그때, 내 말투와 억양에 문제가 있다는 것을 알았다. 이후 유강스 시간에 크루들에게 내 억양에 대해 직접 피드백을 구했고, 몇 가지 의견을 들을 수 있었다. 질문할 때나 이해되지 않는 부분을 설명할 때, 무의식 중 억양이 강해져 상대방에게 공격적으로 느껴질 수 있다는 것이었다. 단어 자체는 문제가 없지만, 억양이 화난 것처럼 전달된다는 피드백이었다.

이 문제를 해결하기 위해 억양이 강하다고 느낀 크루에게 벌금을 내는 방법을 시도해 봤다. 의식적으로 억양을 신경 써 대화를 하니 억양이 부드러워졌고, 스스로도 많이 고쳐지고 있다고 느꼈다. 추가로, 리사 코치님의 조언으로 나만의 쿠션어를 사용하려고 연습 중이다. 쿠션어는 핵심적인 말을 하기 전, 상대방을 배려하는 차원에서 사용하는 완곡한 표현이다. 오 좋은 생각이네요 공감합니다, 그렇게 생각할 수도 있겠네요. 좋은 고민이에요.라는 쿠션어를 말하기 전에 해당 사용하려고 노력 중이다. 추가로 억양과 말투를 조절하기 위해 다른 방법도 찾아볼 생각이다.

 

다른 사람들의 소프트스킬 배우기

우테코 크루들은 각자의 개성이 뚜렷하다. Level2 마지막 미션을 머피와 함께 했는데 기술적으로도, 소프트스킬적으로도 머피에게서 배울 점이 참 많았다. 머피는 다른 사람들의 코드를 보고 어떤 의도로 작성했는지 파악하는 능력이 뛰어났다. 의도를 파악한 이후, 그 사람의 의도와 코드를 존중하는 모습이 너무 인상 깊었다. 나였다면, 이 부분 고치죠?라고 제안하고, 상대방이 거절하면 설득해 볼 것 같아 머피의 존중이 신기했다. 강요 대신 존중 하는 머피의 모습을 배워야겠다고 생각했다. 또 상대방을 배려하는 능력 또한 뛰어났다. 개인적으로 누군가 내 코드를 실시간으로 지켜보고 있다면 부담감이 있어 평소보다 잘 작성하지 못하는 경우가 있는데, 머피가 이를 빠르게 눈치채고 의도적으로 잠깐 자리를 비워준 경험이 있다. 이 모습을 보고 상대방을 정말 많이 배려해 준다는 것을 느꼈다. 누군가와 함께 협업을 하는 과정에 있어 소프트 스킬은 어떻게 보면 기술적인 부분만큼이나 중요하다는 것을 머피와의 페어프로그래밍을 통해 느꼈다.

 

Level3에 들어가기에 앞서 어떻게 다른 사람들의 의견을 존중하고, 배려할 수 있는지 나만의 방법을 생각해 봐야겠다.

---

나만의 공부법은 찾았나?

 

AI 적극 활용하기

완벽하지는 않지만, 공부법의 실마리를 찾은 것 같다. 우선, 인강이나 서적을 처음부터 끝까지 쭉 듣거나 보는 것은 내 공부법이 아니라는 결론이 나왔다. 내가 찾은 나만의 공부법은, 생성형 AI를 적극적으로 활용하는 공부법이다.

 

Level2 끝날 때 까지도, 나는 생성형 AI를 사용하는 것을 극도로 경계했다. 생성형 AI를 사용했을 때 안 좋은 결과가 너무 많았기 때문이다. 생성형 AI가 전부 코드를 짜줘서 Spring이 뭔지도 모르고 프로젝트를 한 말도 안 되는 경험도 있고, 코드에 대해 누군가가 물어봤을 때 GPT가 짜줘서 저도 잘 모르겠어요라고 대답한 말도 안 되는 경험도 해봤다. 지금 와서 생각해 보면 정말 말도 안 되는 상황이다ㅎ..  또 프리코스 4주 차(편의점) 때 특정 로직을 GPT를 이용해 작성했고, 이후에 GPT가 작성해 준 코드의 흐름을 놓쳐 하루 전에 전부 날리고 처음부터 다시 작성한 경험도 있다. 위와 같은 기억들이 내 머릿속에 남아있었기에, 생성형 AI 사용을 최대한 지양하면서 우테코 생활을 하고 있었다.

 

하지만 주변 크루 + 코치님들이 생성형 AI를 잘 활용하는 모습을 보고 내 생각은 바뀌게 되었다. 중요한 건 의존이 아니라 활용이었다. 코드에서 에러가 발생했을 때 바로 AI에게 원인을 묻기보다 에러 메시지를 먼저 분석하고 스스로 원인을 유추한 뒤, 검증받는 용도로 AI를 사용했을 때 매우 효과적이었다. 또한, 모르는 개념이 나왔을 때 Perplexity와 같은 검색 기반 AI에게 공식 문서나 Baedung을 참고해서 설명해줘 라고 요청하면, 단순 검색보다 훨씬 빠르고 정확하게 문제를 해결할 수 있었다.

 

과거에 바둑업계에서도 위와 같은 논쟁이 있었다고 한다. 알파고가 바둑기사들을 이겼을 때인데, AI를 활용해 바둑을 공부해야 한다 vs 인간만이 둘 수 있는 수를 계속 연구해야 한다 두 가지 파벌로 나뉘었다고 한다. 현시점에서, AI를 활용하지 않은 바둑기사들은 전부 도태되었고, AI를 활용해 인간이 생각하지 못 한 수를 공부한 사람들이 전부 상위에 랭크하고 있다고 한다. 나는 학습 측면에서 생성형 AI 사용이 효율적이라고 생각한다. 생각이 바뀌었다.  대신, AI에게 의존을 하면 안 되고 활용을 해야 한다. 같이 협업하는 성격 좋은 개발자라고 생각을 해야 한다고 할까...? 모르는 거 눈치 보지 않고 계속 물어보고, 왜 이렇게 짰는지 의도도 물어보고, 허점이 있으면 내가 고치고... 이런 식으로 사용해야 한다고 느꼈다. 무작정 이거 해줘. 이거 오류 나는데 고쳐줘. 가 아니라, 이 부분에서 ~~ 한 에러가 발생했는데 아마 ~~ 가 원인인 것 같아. 이 문제를 해결하기 위한 방법을 공식 문서나 신빙성 있는 블로그에서 찾아볼래? 와 같이 질문하고, 가져온 해결책을 내가 직접 이해하고 넘어가자!

 

해보고 싶은 건, 다 해보자!

 

오버엔지니어링에 대해 고민을 한 시기가 있었다. 물론 오버엔지니어링에 대해서는 부정적인 입장이다. 하지만 학습 측면에서 많은 양의 데이터를 고민해 보는 건 좋지 않을까?

 

내가 희망하는 기업은 많은 유저와, 많은 데이터를 다루는 서비스 기업이다. 하지만 내가 학습하고 있는 환경에서는 아무래도 큰 데이터를 다룰일은 굉장히 드물다. 레벨 3~4 때 팀프로젝트를 진행한다. 이때 만드는 프로젝트가 현실적으로 많은 유저와 많은 트래픽을 가져올 수 있을까? 난 아니라고 본다. 초기에는 아무리 많아도 20명 이내라고 생각한다. 그러면 내 프로젝트에서 할 수 있는 고민과 목표로 하는 기업에서 하는 고민이 달라진다고 생각했다. 예상 유저를 20명 이내로 측정했을 때 할 수 있는 값진 고민들 또한 많겠지만, 유저가 많고 데이터의 양이 많으면 아예 다른 고민을 해야 한다. 

 

나는 평소에 100만 개의 데이터를 머릿속에 항상 넣어둔다. 100만개를 동시에 조회한다면 속도가 느리지 않을까? 100만개를 한 번에 가져온다면 메모리가 터지지 않을까? 일어나지 않은 일들을 상상하고, 성능을 어떻게 하면 개선할 수 있을지에 대해 고민하는 걸 좋아한다. 하지만 레벨 3~4 프로젝트에서 현실적으로 100만개의 데이터를 고려할 이유가 있을까...? 고려하는 순간 오버엔지니어링이 될 것이고, 같이 협업하는 크루가 오버엔지니어링을 안 좋아하면 어떡하지?라는 생각 또한 들었다. 현실적으로 필요 없는 설계니깐.

 

이런 고민을 해결하기 위해 구구 코치님께 원온원을 신청했다. 코치님은 내 의견에 동의하면서 명쾌한 조언을 해주셨다. 좋은 고민인 것 같아요. 하고 싶은 거 하세요! 본인이 재밌어야죠. 내가 재밌으면 하라는 조언을 받았다. 만약에 팀프로젝트에서 팀원이 가상의 많은 데이터를 안 좋아한다면, 시간을 따로 내서 혼자 해보는 건 어떻냐는 조언을 받았다. 그리고 좋아한다면 같이 하면 되는 거고! 내 의견을 강요할 필요도 없고, 팀원의 의견을 존중하면서 하고 싶은걸 다 할 수 있는 아주 명쾌한 조언이었다.

 

결론은, 난 내가 재밌는 거 위주로 공부하려고 한다. 그래서 블로그에도 실험실이라는 카테고리를 따로 만들었다. 여기에 평소 해보고 싶었던 것을 이것저것 해볼 계획이다. 이 또한 나만의 공부방법 아닐까?