기술 스택 고르기
사실, 처음에는 쓰고 싶은 기술에 맞춰 프로젝트를 찾았다.
솔직히 채용공고 보면 보이는 많은 것들...있지 않은가.
그래서 ChatGPT에 Redis, MSA, Kafka, RabbitMQ, Java 등 쓰고 싶은 기술 스택을 전부 나열하고, 이 기술들에 맞는 좋은 프로젝트를 추천해 달라고 했다.
Redis를 넣어야 할지, 메시지 큐가 필요할지, Kotlin과 Java 중 무엇을 고를지 한참을 고민했다. 그런데 돌아온 추천 프로젝트들은 어느 것도 마음에 들지 않았다.
핵심은 /"즐겁지 않았다"는 사실이다.
기술에 먼저 매몰되는 개발은 내가 원하던 방향이 아니었다는 사실을 문득 떠올렸다..
그래, 기술이 먼저가 아니라, 필요한 게 뭔지를 먼저 잡는 것.
이게 지금 내가 지향하는 개발자, 설계자로서의 태도다.
그리고 이 태도를 새로운 작업의 출발점으로 삼기로 했다.
다만 여기서 실제 사업성이나 혁신성이 검증됐다고 확대해서 말하고 싶지는 않다. 그냥 내가 일하는 방식이 바뀌었다는 이야기다.
그래서 추천을 기다리는 대신 아이디어를 하나씩 직접 떠올리기 시작했다.
그래서 방향을 바꿨다. 아이디어를 직접 떠올리고, 서비스에 필요한 것을 먼저 정한 뒤, 거기에 맞는 기술을 고르기로 했다.
구현 단계에서는 예전에 Java와 Spring으로 쌓았던 경험을 되살리고, 실제로 운영까지 해보는 것을 학습 목표로 삼았다.
경험하고 싶었던 것은 세 가지 전부다.
- 실제 사람들이 쓰는 서비스를 띄워보는 것
- 오류와 장애를 찾아서 고쳐보는 것
- 사용자 반응을 보고 개선해보는 것
그래서, 뭘 어떻게, 왜 골랐는데?
- Java: 예전 경험을 되살리면서 직접 손으로 코드를 작성하는 연습을 하기 위해 골랐다. 나에게는 Kotlin보다 Java가 이 목적에 더 맞았다.
- Spring: 기존 경험과 실력을 복구하면서 실제 서비스를 구현하고 운영해보기 위해 골랐다.
- 버전: 무조건 최신 버전을 따라가기보다, 현대 Java의 이점을 누릴 수 있는 버전을 쓰고 싶었고, Spring도 그에 맞춰 골랐다. (Java 21과 Spring Boot 4의 출시 시점, 호환성에 관한 설명은 글을 쓰기 전에 다시 확인할 예정이다.)
- PostgreSQL: 여러 DB를 직접 비교해서 고른 건 아니다. SQL 표준 문법을 잘 따르고 다재다능하다는 이야기를 듣고 골랐다. 비교 실험을 하거나 객관적인 우위를 검증한 것처럼 쓰고 싶지는 않다.
- 추가 기술: Redis, 메시지 큐, MSA 같은 기술을 포트폴리오 항목을 채우려고 끌어오지는 않는다. 실제로 필요한지를 먼저 판단하고 그다음에 도입한다.