입사 후 3개월간의 백엔드 엔지니어 여정 회고

목차

1. 입사한지 벌써 3개월! ⭐

2. 회사에서의 나의 역할은? 👨‍💻

3. 신입 온보딩, 비지니스를 이해하기 위한 과정 🐥

4. 본격 실무 수행, 차근차근 배워나가는 과정 🏃‍♂️
  4-1. Http Client 전환을 통해 서버 성능을 개선해보았다! ☕
  4-2. 여러 비지니스 요구사항들에 대응해보았다! 🛴
  4-3. 기존에 잔재된 소소한(?) 버그들을 발견 & 해결해보았다! 🔎
  4-4. 적극적으로 협업을 해보았다! 👋

5. 개인적으로 배울 수 있었던 것들
  5-1. MySQL 의 트랜잭션 격리수준에 대해 깊게 알아보았다!
  5-2. Git 에 대한 이해도를 높일 수 있었다!
  5-3. 리액티브 프로그래밍에 대해 학습해보았다!
  5-4. SQL 튜닝을 위해 인덱스에 대해 깊게 알아보았다!
  5-5. 그외 여러가지...

6. KPT(Keep - Problem - Try) 회고
  6-1. Keep
  6-2. Problem
  6-3. Try

7. 앞으로의 여정에 있어 마음가짐과 목표

 

1. 입사한지 벌써 3개월! ⭐

현재 회사에 백엔드 엔지니어로 취업한지도 그리고 웹 개발자로 새로운 커리어를 시작한지도 벌써 3개월이 지났다. (2023. 8. 7. ~ 11. 6.) 매번 회고를 쓸 때마다 느끼는 거지만 체감상 시간은 항상 빠르게 흘러간다. 👀 지난 7월 즈음에 "공기업 퇴사 이후 개발자가 되기까지의 여정"에 대한 회고를 작성한 이후로는 이번이 첫 회고인데, (매주 작성하는 WIL 도 일종의 회고라고 볼 수 있지만..? 👀) 입사 전부터 나는 수습이 종료되면 회고를 작성하겠다는 마음을 가지고 있었다.

 

나에게 있어 회고 작성은 하나의 스테이지(stage, 관문)를 넘었을 때 이루어지는 일종의 의식(지난 시간 되돌아보기)과도 같다. 👀 수습 종료도 나름대로 하나의 스테이지를 넘은 것이라고 볼 수 있으므로, 아울러 지난 3개월은 새로운 커리어를 시작해나가는 뜻깊었던 순간들이었던 만큼 2023년이 가기 전 마지막 회고를 작성해보고자 한다. ✍ (근데, 곧 있으면 2023년에 대한 회고도 작성해야되는데...? 👀)

 

 

2. 회사에서의 나의 역할은? 👨‍💻

우선, 나는 업무에 임하기 전 백엔드 엔지니어로서 현 회사에서의 나의 역할에 대해 생각해보았었다. 현 회사에서 개발자가 존재하는 이유는 소프트웨어를 기반으로 비지니스를 영위함으로써 사용자에게 가치(편익 등)를 제공하기 위한 것이라고 생각했다.

 

이때, 백엔드 엔지니어로서 나의 역할은 소프트웨어 특히, 서버 내부 로직을 프로그래밍하여 비지니스 요구사항에 유연하게 대응하고 소프트웨어 품질을 향상시키는 것이라고 생각했다.

 

아울러, 이러한 과정에 있어 다수의 사람들과의 협업은 필연적이기에 협업 시 시너지 효과를 낼 수 있도록 소프트 스킬(문서 작성, 존중 등)에 대해 고민하고 익히는 것 역시 나의 역할에 포함되어 있다고 생각했다.

 

경력상 아주 짧은 시간이지만 지난 3개월간 나름대로 백엔드 엔지니어로서 역할을 수행해왔던 것들에 대해 되돌아 보고자 한다. ✍

 

 

3. 신입 온보딩, 비지니스를 이해하기 위한 과정 🐥

다행히(?) 입사하자마자 바로 실무에 투입되지 않고 동기와 함께 온보딩을 가졌었다. 🐥 해당 온보딩 시간 동안 서비스의 주요 로직들을 살펴보며 비지니스를 이해하는 시간을 가졌었는데, 그 과정에서 주석을 작성하는 요구사항이 있었기에, 그냥 눈 대중으로 코드를 보는 것보다 면밀하게 살펴볼 수 있었다. 아울러, 동기가 있었기에 궁금한 점이나 자기가 이해한 내용을 서로 공유할 수 있었고, 무엇보다 현 회사에서 오랫동안 근무하셨던 사수 분께 질문을 드리면 답변해주는 형식으로 진행됐었기에 비지니스를 이해하는 것 뿐만 아니라 기술적인 부분에서도 정말 많은 도움을 받을 수 있었다. ☕ 이 과정에서 기존 코드 상 개선되어야 할 부분들도 파악할 수 있었다. 🔧

 

 

4. 본격 실무 수행, 차근차근 배워나가는 과정 🏃‍♂️

신입 온보딩을 마친 이후에는 본격적으로 이슈를 하나씩 배정받으면서 실무를 수행했다. 사실, 2주간의 신입 온보딩만으로 비지니스 전반에 대해 온전히 이해할 수는 없었지만, 이슈를 하나씩 처리해나가는 과정에서 비지니스에 대한 이해도를 차츰차츰 쌓아갈 수 있었다. 🎁

 

4-1. Http Client 전환을 통해 서버 성능을 개선해보았다! ☕

가장 먼저 배정받은 업무는 서비스 내 RestTemplate 기반의 Http Client 들을 WebClient 로 전환하는 업무였다. 해당 작업의 궁극적인 목적은 기존 blocking I/O & Synchronization 방식의 네트워크 통신을 non-blocking I/O & Asynchronization 방식으로 전환하여 사용자 latency 및 서버 유휴 스레드를 절감하는데 있었다.

 

1. Research

 

본격적인 개발에 앞서 먼저 WebClient 에 대한 Research 를 수행했다. 처음 배정받은 업무였었던 만큼 동기와 함께 해당 작업을 수행하게 되었는데, 각자 WebClient 에 대해 학습하고 작업과 관련해서 조사해온 내용들을 공유 및 취합하여 사수분들께 보고드리는 시간을 가졌다. 이때, 동기와 함께 의논하는 과정에서 의사소통적으로 시간 비용이 발생하긴 했지만, 서로 부족한 점을 보충해줄 수 있는 좋은 시간이었다.

 

2. Design

 

이후에는 WebClient 기본 설정 작업을 수행했다. 먼저 앞서 Research 간 숙지했었던 Timeout, Connection Pool, MaxInMemorySize 등 WebClient 의 각각의 세부 설정 내용들에 대해 데브옵스 팀과 논의하여 결정했다. 이 설정 값에 따라 운영 시 DataBufferLimitException, PrematureCloseException 등의 예외가 발생할 수 있었기에 유의했어야 했다. 아울러, target server 의 응답 데이터 처리 전략 및 예외 처리 전략을 수립한 후 마찬가지로 사수분들께 보고드리는 시간을 가졌다. 취업 전 RestTemplate 이나 WebClient 를 사용해본 적은 있었으나, 이렇게 운영을 고려하면서 세부 설정까지 하나하나 신경 쓰면서 사용한 적은 없었기에 나름대로 뜻깊었던 시간들이었다.

 

3. Development & Test & Code Review

 

그리고 앞서 설정했었던 WebClient 기반으로 기존 RestTemplate 기반의 Http Client 들을 non-blocking I/O & Asynchronization 방식으로 전환하는 작업을 수행했는데, (이 당시 동기는 다른 업무를 배정받아 수행하는 중이었다.) 해당 과정을 수행하면서 사수분들의 코드 리뷰를 통해 기존에 작성했던 코드들이 구조적으로 많이 개선될 수 있었다. 🔧 (nested callback 구조를 chained callback 구조로 개선, Client 와 Service 로직의 역할 분리 등) 아울러, 발생할 수 있는 케이스들을 추린 후 로컬 환경에서 Test Server 를 target 으로 하여 테스트를 진행했다. 다만, 작업 순서에 의존적인 Http Client 의 경우 non-blocking I/O & Asynchronization 방식으로 전환할 수 없었기에 단순히 RestTemplate 을 WebClient 로 전환하는데에만 그쳤다.

 

4. Deploy & Monitoring

 

이후 production 에 배포까지 마쳤는데, non-blocking I/O & Asynchronization 로 전환된 Http Client 를 포함하는 API 의 경우 side-effect 없이 서버의 유휴 스레드를 절감할 수 있었을 뿐만 아니라 사용자 latency 를 85% 낮출 수 있었다. 개인적으로는 이러한 작업들을 통해 기존 요청 당 스레드 할당 방식과 이벤트 루프 방식의 차이와 리액티브 프로그래밍 프로세스에 대해 이해할 수 있었던 것도 큰 수확이었다.

 

5. Error & Improve (Go to 3)

 

물론, 좋은 일만 있었던 것은 아니었다. 💦 앞서 WebClient 로 단순 전환만 했었던 일부 Http Client 의 경우, 인코딩 이슈로 인해 배포 시 예상치 못한 여러 장애들이 발생했다. 그 중에는 기존 RestTemplate 와 WebClient 초기화 시 설정되는 encodingMode 의 차이로 인함도 있었고, 응답 데이터를 parsing 하는 전략의 변경으로 인함도 있었다. 단순히 Client 라이브러리만 변경하는 작업이었다고 안일하게 테스트했었던 것이 패인이었다. 💦 이러한 경험을 통해 좋은 교훈을 얻었다고 생각한다. 🐥

 

4-2. 여러 비지니스 요구사항들에 대응해보았다! 🛴

아직 사용자에게 제공되는 서비스 상 굵직한 신규 기능을 도맡아 구현해본 경험은 없었으나, 기존 기능 변경에 대응해보거나 신규 기능을 구현하는 정도의 경험을 할 수 있었다. 🐥

 

프론트엔드 개발팀과 소통하며 개발하는 경험을 할 수 있었다. 프론트엔드 개발팀에서 작성한 인터페이스 정의서를 참고하며 API 명세를 작성하는데 문서 상 명확하게 나타나지 않은 부분들에 대해 대충 넘겨짚고 작업하기 보다 질문을 통해 요구사항을 구체화함으로써 기존 API 에서 불필요하게 수행되고 있었던 작업들을 제거할 수도 있었다.

 

아울러 변경 작업을 수행하면서 논리적으로 JPA 동작 상 join fetch 와 pagination 이 함께 일어날 필요가 있었는데, 이 경우 애플리케이션에서 페이징 처리를 문제가 있어 (Out of memory risk 위험) Lazy Loading 및 @BatchSize 설정을 통해 해당 문제를 보완할 수도 있었다. 또한, 로컬 환경에서 테스트 중 기존 쿼리 중 불필요하게 2중 조인이 발생하는 쿼리가 있어 1 조인 쿼리로 개선해보는 소소한 경험도 해볼 수 있었다. 😅

 

또한, 간단한 SQL 튜닝 경험도 해볼 수 있었다. 또 다른 요구사항으로 DB 에 오랜 시간 축적된 많은 데이터들에 대해 일괄적으로 Update 하는 작업이 필요로 했었는데, 연관 관계가 있는 다른 테이블에 있는 데이터를 기반으로 수정되어야 했기에 2번의 JOIN 이 발생하여 성능이 저하될 여지가 많았다. 결론적으로, 최초 작성된 SQL 에 대한 실행계획을 통해 문제 진단을 하고 데이터 분포도 분석을 통해 불필요한 CAST 연산을 제거함으로써, 기존에 1시간 이상 걸렸던 쿼리가 5초만에 실행되도록 최적화할 수 있었다.

 

SDK 를 변경하는 작업을 수행하기도 했다. 단순히 SDK 를 변경하는 작업이었기에 큰 어려움은 없었지만, 기존에 작업과 연관된 유틸 클래스 코드에 오류가 있어 개선하고 JUnit5 기반 테스트 코드를 작성해보기도 했다.

 

새로운 기능을 추가하면서 동적 쿼리(다중 조건 검색)를 구현해보기도 했다. 취업 전에는 Querydsl 을 이용하여 동적 쿼리를 구현해본 경험이 있었지만, 이번에는 JPA 에서 제공하는 Specification 을 이용하여 구현해보았다. (사실, 현재 서비스 프로젝트에 Querydsl 을 새롭게 접목해보려고 했으나, 원인 모를 빌드 에러가 발생해 시간 관계상 다음으로 미루었다. 😅) 또한, 검색된 데이터들을 엑셀로도 응답해야하는 요구사항도 있었기에, apache 의 POI 라이브러리에서 제공하는 Workbook 을 활용하여 excel 데이터를 처리하기도 했다.

 

4-3. 기존에 잔재된 소소한(?) 버그들을 발견 & 해결해보았다! 🔎

성능 개선 작업과 비지니스 요구사항들을 처리하는 과정에서 나의 실수는 아니었지만 기존 서비스 상에 잔재되어있었던 소소한(?) 버그들을 발견하고 해결해볼 수 있었다. 🛒

 

대표적으로, 트랜잭션 애노테이션이 붙어있음에도 불구하고 JPA 영속성 컨텍스트에서 제공하는 Dirty Check 기능이 활성화되지 않았었던 이슈가 있었다. 이로 인해 update 쿼리가 나가야할 때 나가지 않는 문제가 있었다.

 

결론적으로, 해당 이슈의 원인은 해당 객체가 Spring Bean 으로 관리되지 않았기 때문이었다. 해당 객체는 @Configuration 클래스에서 Bean 으로 등록해주는 것처럼 보였지만, 실상은 아래와 같이 단순히 new 연산을 통해 실제 Bean 으로 등록되는 객체에 의존성이 주입되고 있을 뿐이었다. 

 

@Configuration
public class TestConfig {

    @Bean
    public TestService testService() {
    	return new TestService(new NotSpringBean());
    }
}

 

따라서, 위 예시에서 든 NotSpringBean 객체는 싱글톤으로 존재하기는 하나, Spring 컨테이너에서 관리하는 Bean 이 아니었던 것이다. 그렇기에 트랜잭션 애노테이션을 붙여도 Spring AOP 가 동작하지 않기에 트랜잭션이 적용되지 않았고, 트랜잭션이 적용되지 않았으니 영속성 컨텍스트로도 관리되지 않았던 것이다. 해결책은 단순히 new 연산을 통해 생성하는 객체를 Bean 으로 등록해주기만 하면 될뿐이었다.

 

클라이언트 측에서 페이지네이션 검색 API 를 호출해도 서버에서 페이지네이션 처리가 되지 않는 이슈가 있었다.

 

원인은 단순했다. 서버에서는 네이티브 쿼리를 이용하고있었는데, SQL 상 페이지네이션을 처리해주는 부분이 없었기 때문이었다. 💦 전임자의 바쁜 일정으로 인한 단순 누락이었을 것으로 보였다. 😅 다만, 헷갈릴 수도 있었을 것 같았던 부분으로는 로직 처리 시 PageImpl 객체를 사용하는 부분이 있었는데, 해당 객체를 생성 시 인자로 페이징 객체(Pageable)를 받고 있기에 마치 PageImpl 객체 자체가 페이징 처리를 해주는 것처럼 보일 수 있었다. 아니나 다를까, 이와 관련해서 스택오버플로우나 spring 오픈소스 리포지토리에서도 PageImpl 객체가 페이징 처리를 안해준다는 글이 일부 보였다. 👀 해결책은 단순히 SQL 상에 페이지네이션 처리 부분을 추가하는 것이었다.

 

이슈와 별개로, 해당 쿼리는 동적 쿼리로서 조건절에 따라 쿼리를 생성해주고 있었는데, 쿼리문이 String 타입으로 관리되어 조건에 따라 + 연산을 하는 것이었다. 이때, 여러 조건이 있었기에 잦은 + 연산으로 불필요한 String 객체 생성 비용이 발생할 수 있어 StringBuilder 를 사용하는 것으로 개선했다.

 

4-4. 적극적으로 협업을 해보았다! 👋

부트캠프(코드스쿼드, SSAFY)를 하면서 팀원들과 프로젝트 경험했을 때와 마찬가지로, 실무에서도 원활하고 효과적인 의사소통 능력 즉, 소프트 스킬을 필요로 했다. 💫 지난 3개월간 어떻게 하면 협업을 잘 할 수 있을까에 대해 고민하고 실천한 것들에 대해 되돌아 보고자 한다. ✍

 

 

1. 모두가 잠재적 협업 대상자

 

현재 나는 백엔드 팀에 있지만, 백엔드 팀 외에도 회사 내 모든 직원분들이 잠재적인 협업 대상자라고 생각한다. 🍺 협업이라는 것도 결국 사람 간에 이루어지는 것이기에, 평상 시 서로에 대한 인상이 무의식적으로 협업에 영향을 끼치리라 생각한다. 전 직장에서부터 습관이 배인 것이지만, 나는 회사 내에서 지나다니다 만나는 모든 직원분들께 인사드리며, 가급적 모두와 좋은 관계를 유지하고자 노력했다. 보통 술 & 담배를 통해서도 친밀도를 쌓는 경우도 많은데, 나의 경우 모두 하지 않기에 직원분들과 등산이나 러닝 같은 취미를 공유하기도 했다. 🏃‍♂️ 이러한 노력 덕에 처음 협업하는 상대에게도 자연스럽게 다가갈 수 있었으며, 원활한 소통을 통해 기존 기능에 잔재되어있던 불필요한 코드들을 제거할 수 있었다.

 

2. 동기와의 협업, 생각의 차이 존중 그리고 설득과 양보의 균형

 

지난 3개월 동안 절반 가량은 동기와 페어 프로그래밍 내지 분업하여 개발하는 시간들이었다. 그만큼 동기와 협업을 하면서 많은 의사소통들이 있었는데, 코드스쿼드를 하던 당시의 페어 프로그래밍 경험들이 많은 도움이 되었다. 동기와 개발 스타일에서 여러모로 많은 차이가 있었으나, 나의 확증 편향에 유의하고 생각의 차이를 존중하고자 노력했다. 나의 방식의 장단점을 논리적으로 제시하며 설득함과 동시에 상대방의 의견을 경청하며 나의 부족한 점을 인정했고, 결정하기 애매한 사항들에 대해선 서로 간 양보하기도 했다. 결론적으로 서로의 부족한 점을 보완해가면서 보다 완성도 있는 결과물을 창출할 수 있었다. 🔔

 

3. '잘' 질문하기!

 

입사 전 코드스쿼드 동기로부터 사수분들께 질문을 많이 하라는 조언을 받을 수 있었다. 이때, 나는 질문을 많이 하는 것이 중요하다고 생각하면서도 어떻게 하면 질문을 '잘' 할 수 있을까에 대해 고민했었다. 나의 경우, 단순히 '이거 뭐에요? 이거 어떻게 해요?' 식의 질문 보다는 '제가 ~ 에 대해 알아보았고 저는 ~ 라고 생각했는데 ~ 부분이 이해가 잘 되지 않는데 이 부분에 대해 설명해주실 수 있을까요?' 식의 질문을 하려고 노력했다. 이러한 질문을 하려는 노력 덕에 사수께서 질문을 잘 한다고 칭찬(?)해주셨고 보다 성심성의껏 답변해주시기도 했다. ⭐

 

추가적으로, 개발할 때 질문하기에 뭔가 애매한 부분이 있는 경우도 종종 있었는데, 이 경우에는 대충 넘겨짚고 넘어가지 않고 사수분들께 즉각 물어보는 것이 좋은 결과로 이어질 때가 많았다. 👀

 

4. 코드 리뷰, 잘 부탁드립니다! 🙏 & 잘 하겠습니다! 🐥

 

내가 작업한 내용에 대해 팀원들로부터 Pull Request 를 통해 코드 리뷰를 받고자 할 때, 어떻게 하면 코드 리뷰를 잘 받을 수 있을까 고민했었다. 리뷰를 하는 사람 입장에서는 내가 작업한 내용에 대해 잘 모를 수도 있다. 나의 경우 Pull Request 를 올릴 때, '어떤 작업들을 수행했는지', '이 작업은 왜 하는지?',  '어떤 부분을 중점적으로 고려했는지' 등을 명기하곤 했다. 덕분에 사수분들께서 디테일하게 리뷰를 남겨주셨었고 좋은 피드백들을 많이 받아 기존 코드 구조를 좋은 방향으로 개선시킬 수 있었다.

 

아울러, 나 역시 팀원들의 코드를 성심성의껏 리뷰하고자 노력했다. 코드 변경이 필요한 경우에는 변경 예시를 들면서( (또는 시나리오와 함께) 기존 코드의 문제점과 변경 시 얻을 수 있는 이점들에 대해 언급하며 코드 변경의 필요성에 대해 느낄 수 있도록 리뷰했다. 시간적 여유가 있을 때에는 작업 브랜치를 pull 하여 로컬 환경에서 직접 테스트해보며 누락된 것들이 있는지 크로스 체킹하기도 했다.

 

5. 문서화 & 공유

 

작업을 하다가 이거는 팀원들에게 공유하고싶은 또는 공유해야겠다는 내용들이 있을 수 있다. 아울러, 에러를 해결하는 과정에서 미처 고려하지 못했었거나 새롭게 배운 내용들이 있을 수 있다. 이때 나의 경우 해당 내용들에 대해 나름대로 일목요연하게 문서화를 하여 팀원들에게 공유하곤 했다. 특히, 트러블 슈팅 과정에 대해 '문제 상황 - 원인 분석 - 해결' 과정을 정리하여 문서화하기도 했었는데, 팀원들로부터 많은 도움이 되었다는 피드백을 받을 수 있었다. 🚀

 

 

5. 개인적으로 배울 수 있었던 것들

회사 업무를 수행하면서 여러모로 기술적으로 배울 수 있었던 것들이 많았다. 모든 것을 글로 풀어내기에는 어려움이 있지만 특별히 인상적이었던 것 위주로 정리해보고자 한다. ✍

 

5-1. MySQL 의 트랜잭션 격리수준에 대해 깊게 알아보았다!

신입 온보딩 당시 서비스 계층의 메서드 상에 트랜잭션 격리수준이 Serializable 로 설정된 것을 보고, Serializable 로 설정해야만 했었던 이유가 궁금해져 MySQL 의 트랜잭션 격리수준에 대해 깊게 알아보았다. 취업 전 학습하던 시절에는 Serializable 로 설정하면 동시 처리 성능이 저하되 실무에서는 거의 사용되지 않는다고 막연하게만 알고 있었기에, 이번 기회에 제대로 알아가고 싶었다. (아울러, Read Uncommitted , Read Committed, Repeatable Read 에 대해서도!!) 이때, "Real MySQL 8.0" 기술서적이 해당 개념들을 면밀하게 파악하는데 정말 많은 도움이 되었다. (요즘 들어, 데이터베이스 학습에 재미가 들렸다. ✍)

 

 

5-2. Git 에 대한 이해도를 높일 수 있었다!

취업 전 프로젝트 시 백엔드 개발을 주로 혼자해왔었던터라 생각보다 Git 의 다양한 기능들을 사용할 경험이 부족했다. 본격적으로 실무를 하면서 여러 사람들간 브랜치를 공유하다보니 충돌 외에도 여러 이슈들이 발생했었는데, 그 과정에서 Git 이 익숙치 않다보니 헤매는 경우가 종종 있었다. 이에 Git 에 대해 제대로 숙지하고 넘어가기 위해 사놓고 안 읽고 있었던 (매번 우선순위가 뒤로 밀렸던) "팀 개발을 위한 Git, GitHub 시작하기" 기술서적을 완독하며, 부족했었던 Git 이해도를 높이고 그동안 제대로 사용해보지 않았었던 여러 기능들을 다뤄보았다. 현재는 실무에서 Git 때문에 걱정하는 일은 거의 없다. 😁 (역시, 환경이 중요하다..😅)

 

 

5-3. 리액티브 프로그래밍에 대해 학습해보았다!

WebClient 기반의 Http Client 를 개발하면서 Event Loop Model, 리액티브 스트림, 옵저버 패턴 등 리액티브 프로그래밍 관련 여러 키워드들에 대해 학습해볼 수 있었다. 단순히 WebClient 사용법만 숙지하고 쓰는 것 보다 내부적으로 어떻게 구현되고 동작하는지를 이해해야 제대로 된 개발을 할 수 있지 않을까 했다. 리액티브 프로그래밍의 경우 웹 상에 공개된 기술 블로그나 유튜브 영상들을 참고하여 학습했다. 추후에는 특정 기술서적을 붙잡고 학습하고싶은 욕심이 있다. ✍

 

5-4. SQL 튜닝을 위해 인덱스에 대해 깊게 알아보았다!

인덱스는 단연 백엔드 기술 면접 당골 질문인 만큼 개념적으로는 학습했었으나, 실제로 사용해본 경험이 많치 않아 당장 실무에서 SQL 튜닝 시 어려움이 많았다. 이때, "업무에 바로 쓰는 SQL 튜닝" 기술서적이 많은 도움이 되었다. 기존 SQL 의 실행계획과 데이터 분포도를 분석하며 성능 개선 포인트를 떠올릴 수 있었고 개선된 SQL 의 실행계획 분석까지 마칠 수 있었다. ☕

 

 

5-5. 그외 여러가지...

이외에도 CI(Connecting Information) 와 DI(Duplication Information), SRP 인증 프로토콜, Kafka, Rabbit MQ, 쿠버네티스, GRPC 등 실무를 하면서 자주 접했었던 여러가지 개념들과 기술들이 있었는데, 배정된 업무를 하나하나씩 수행해나가며 차근차근 알아가는 중에 있다. 🔎

 

 

6. KPT(Keep - Problem - Try) 회고

지금까지 지난 3개월간의 업무, 학습 등의 여정을 되돌아 보았는데, 이번에는 지난 3개월간 나 스스로에 대해 되돌아 보고자 한다. 🔎

 

6-1. Keep

운동을 하기 시작했다. 🐥 취업하기 전 나의 하루 운동량은 거의 없었다고 볼 수 있다. (개발에 온전히 집중하면서 운동도 소홀해져갔다.) 취업하고나서는 하루 30분 정도의 러닝을 틈틈이 해주었다. 러닝 덕에 스트레스도 풀리고 육체적인 건강도 많이 좋아진듯한 느낌을 받을 수 있었다. 🏃‍♂️

 

덕업일치할 수 있었다. ⭐ 비전공자였던 내가 개발자가 되기로 결심한 것은 개발이 즐거웠기 때문이었다. (전기전자제어공학 전공자로서 약간의 프로그래밍 경험이 있었다.) 전 직장에서는 업무의 목적에 공감할 수도 없었고 업무 자체 역시 큰 흥미를 느낄 수 없었지만, 현 직장에서는 업무를 함에 있어 더 잘하고 싶고 내 개인 시간을 투자할만한 가치도 느끼고 있다. (커뮤니티 상에선 신입 ~ 주니어 때는 원래 다 그렇다고 하는 시선도 있다.. 👀)

 

회사 업무 외로도 뭔가 하긴 했다. 🥤 대표적으로, 알고리즘 문제 풀기(백준 1일 1커밋 운동), 사이드 프로젝트(Pullanner 서비스), 자기개발 스터디(지식 & 경험 & 목표 공유), 기술블로그 운영(WIL, 회고 작성)이 있었다. 한동안 시간적 여유가 없어 기술블로그에 기술 주제의 글을 작성하지 못했었는데, 조만간 기술 주제의 글도 자주 작성하고자 한다. ✍

 

6-2. Problem

취업하고나서 유튜브 보는 시간이 너무 많아졌다. 😅 퇴근 후 혹은 주말에 밥 먹으면서 유튜브를 보다보면 어느새 수시간이 흘러가곤 했다. 💦 문제는 이러한 것이 습관이 되 점점 더 중독되어져 갔다. (도파민 과다 분비) 이 시간의 절반만이라도 학습에 투자했었더라면 이라는 뒤늦은 후회가 들곤한다. 👀

 

과식을 많이 했다. 👀 2021년에 소화장애 증상이 나타난 이후로 증상이 좋아졌다 나빠졌다를 반복하는 중에 있는데, 입사 후에도 과식으로 인해 소화시키고 자느라 늦은 시간까지 깨어있는 경우가 많았다. 💦 중간에 운동을 통해 많이 좋아지긴 했으나, 좋아진 만큼 각종 과자와 빵류 다수 섭취로 인해 소화가 안되는 경우가 많았다. 😅 (도파민 과다 분비) 절식하여 소화하는데 불필요한 시간을 쓰지 않았었더라면 컨디션 관리를 더욱 잘할 수 있었을 텐데 하는 후회가 든다. 💫

 

 

6-3. Try

하루 시간계획표를 세워 유튜브 보는 시간을 줄이고자 한다. 👀 나의 경우 딱히 정해진 스케쥴 없이 하루를 보내는 경우가 많은데, 앞으로는 유튜브 보는 시간을 딱 정해서 그 만큼만 보고 나머지 시간을 활용해 자기개발적인 일에 투자하고자 한다. ☕

 

과자를 끊어보고자 한다. 사실, 나름대로 위 건강을 생각해 (술 & 담배는 원래 안하고) 카페인, 탄산, 라면 등을 끊고 살았었지만, 과자에 중독되어 위 건강은 좋아질 기미가 없었다. 💦 그동안, No Nicotine, No Alcohol, No Caffeine, No Carbonate 구호(?)를 새기며 살아갔었는데, 앞으로는 No Snack 도 추가될 예정이다. 👀 (빵은 차마 못 끊겠다. 🤣)

 

 

7. 앞으로의 여정에 있어 마음가짐과 목표

지난 3개월은 현 회사와 실무에 적응하기 위한 시간들이었다고 생각한다. 하지만, 아직 배워야할 기술들도 많고 현 서비스의 비지니스 숙지도 부족하므로 갈 길이 멀다. 더욱이, 앞으로도 기술적으로나 비지니스적으로 많은 요구사항들이 있을 것인데, 이를 온전히 소화하기 위해서는 무엇보다 실력을 탄탄하게 갖추어야 할 필요성을 강하게 느끼고 있다. 따라서, 앞으로의 여정에서도 배움을 게을리 해서는 안된다. 이때, "천 리 길도 한 걸음부터"라는 말이 있듯이 차근차근 묵묵하게 주어진 일들을 처리하며 성장해나가고자 한다. 🍺

 

2023년 전체 회고를 제외하고 다음 회고를 쓴게 된다면 아마 근무일수가 만으로 1년이 차는 시점(내년 8월)이 되지 않을까 싶다. 그때까지의 목표는 업무적으로 온전히 자립하는 것이다. 현재는 업무를 수행함에 있어 많은 부분들에 대해 사수분들께 질문드려가며 배워나가고 있는데, 앞으로는 팀 내 한 명의 플레이어로서 제 역할을 할 수 있도록 아울러, 신입이 들어왔을 때에도 업무를 원활하게 가르쳐줄 수 있는 수준으로 성장해나가고자 한다. 🚀

 

 

 

인생은 속도가 아니라 방향이다.
조금 더디더라도 방향만 맡게 가고 있다면, 누구에게나 기회의 순간이 찾아오기 마련이고
당신에게도 인생의 황금기가 적절한 시기에 찾아올 것이다.

- 장자 -