🛰 SIA 입사 상반기 회고

주니어 개발자의 상반기 회고

시간이 정말 빨리간다. 벌써 1년중 절반이 지났다는게 믿기지 않는다 🥹

입사를 결정하며 혼자 되새겼던 생각들이 있다. 

 

1. 주어진 업무만큼은 제대로 이해하고 끝까지 맡은 역할을 충실히 해내기

2. 의사 소통을 활발히 하기

3. 무조건적인 수용보다는 내 주관을 가지고 뚜렷하게 의견을 표현하기

 

시간을 뒤돌아보니 그래도 꽤 실천하며 열심히 회사생활을 했다는 생각이 든다.

인턴을 할 때보다 업무의 난이도가 높아졌고 수많은 레거시 코드들을 만나기도 하고 크고 작은 챌린지들이 있었다.

문제들을 하나씩 해결해나가며 스스로 얻는 깨달음도 있었고 어느정도 노하우가 생긴 것 같기도 하다.

팀원분들이 도와주셔서 업무에 잘 적응할 수 있었고 추후에 누군가 들어온다면 나도 받은 도움을 남들에게 마찬가지로 전할 수 있는 사람이 되어야겠다는 생각이 들었다.

 

상반기를 마치며 느꼈던 생각들과 배운 것들을 정리해보려 한다. 

 

 

제품을 바라보는 개발자의 관점

좋은 제품을 만들기 위해서는 개발자가 가지는 관점을 잘 활용할 수 있어야 한다. 주어진 문제들을 기술적으로 어떻게 해결할 수 있을까 고민하고, 기술적으로 접근했을 때 좀 더 쉽게 해결할 수 있는 방향을 찾아 제안을 했을 때 뿌듯함을 느낀다.

근본적인 문제를 해결하기 위해서는 ‘왜’ 에 대한 생각이 필요한 것 같다. ‘고객에게 이러한 기능이 왜 필요한가’에 대해서 생각하다보면 더 나은 해결책이 나오기도 한다. 무조건적인 수용보다는 그 이유를 궁금해하면서 새로운 시각과 해결 방향을 발견할 때가 많다.

또한 개발자의 입장에서만 바라보기보다 고객의 입장이 되어 기능을 생각해보는 것도 필요하다.

기능을 사용하는 고객의 입장이 되어 추후 어떤 기능이 추가될 수 있을지 생각해본다. 이런 고민의 시간을 가지며 도메인을 설계하고 구현했을 때 확장성을 고려한 더 좋은 설계와 구현이 나오는 것 같다.

 

사내 레거시 코드 개선하기

레거시 코드를 직면하면서 이걸 어떻게 하면 개선할 수 있을지 고민하게 되었다. 잘 돌아가는 코드를 건드렸을 때 발생할 수 있는 side effect를 확실히 고려해야하기 때문이다.

그럼에도 불구하고 작은 부분부터 하나씩 바꿔나가고 있다.

 

- 도메인 클래스 리팩터링 : 객체 래핑, 일급 컬렉션 적용, 풍부한 생성자

- 서비스의 복잡한 비즈니스 로직 개선 : 비즈니스 로직은 도메인 클래스의 책임으로 위임

- 너무 많은 역할과 책임을 가진 클래스 쪼개기 : 테스트에 용이하도록 클래스 분리 및 의존성 주입

 

추가로 예전 서버들의 경우 Spring을 사용하지 않고 Netty + Hibernate + Armeria 를 사용하다보니 트랜잭션 처리, 의존성 주입, AOP등 Spring의 소중함을 느끼기도 하고 어떤 부분들이 다른지 배울 수 있었던 것 같다.

위성 영상과 GIS 데이터를 다루는 도메인이다보니 꽤 복잡해 작은 부분들을 위주로 건드리고 있는데 조금씩 도메인을 이해해나가며 큼직한 부분들도 개선시켜나가고 싶다.

 

 

MSA를 향한 여정기

기존의 구조를 전부 갈아엎는 새로운 기능 요구사항이 생겨나면서 이 부분에 대해 도맡아 완전히 서버 분리를 하기로 결정했다.

서버를 분리하며 새롭게 API를 20개를 넘게 짠 것 같다.

특정 UI에 Fit 하지 않고 재사용성이 높은 API들을 만들기 위해 고민이 많아 시간이 꽤 오래 걸렸다. 재사용성과 성능이라는 트레이드오프를 생각하며 API를 설계하는 것이 어려웠다.

추가로 서버를 분리하며 크게 고려했던 부분은 아래와 같다.

• 도메인 간 애그리거트 잘 분리하기
• 도메인 중심의 헥사고날 아키텍처를 도입해 확장성과 유지보수성을 고려한 구조 설계하기
• 데이터 유실 없이 다른 서버들과 데이터 정합성 맞추기

서버가 중간에 다운되거나 재시작되었을 때 데이터 유실이 일어나지 않도록 메시지 큐를 사용하였다.

아직 완벽히 배포하지는 못했지만 크기가 큰 기능 요구사항이다보니 언제든 변화에 대응할 수 있도록 설계에 고민을 했고 여전히 대비하고 있다.

 

 

돌아보며

회사 생활을 하며 많은 것들을 배운 것 같다. 

스프린트 단위로 업무를 진행하면서 기능 구현을 빠르게 해내는 것이 필요했지만 처음에는 코드의 품질과 객체지향설계를 위해 많은 것들을 고려하다 보니 구현이 늦어지는 상황이 발생했다.

스프린트 업무 기간을 맞추기 위해 여러 시행착오를 겪으며 구체적인 설계를 바탕으로 빠른 기능 개발과 리팩터링을 적절히 상황에 따라 판단하며 진행하는 나만의 방법을 찾을 수 있었다. 실무에서는 객체지향원칙을 지키는 것도 반드시 필요하지만 어느 정도 타협이 필요한 상황이 있을 수 있다.

매번 트레이드오프를 생각하며 현재 상황에서 최선의 방법을 찾기 위해 고민하다 보면 조금씩 개발자로서 성장해나갈 수 있지 않을까 생각한다.