되고자 하는 개발자의 방향성

 

요즘 개발직군이 아니더라도 AI에 대체된다는 말이 굉장히 많습니다.

단순히 먼 미래라고 하기엔 미국의 빅테크부터 우리나라의 전문직들에 대한 정보도 종종 접하게 됩니다.

 

https://www.news21tongsin.co.kr/news/285125

마이크로소프트(MS), 9000명 해고 발표. . .AI로 대량 해고가 현실화

 

https://www.youtube.com/watch?v=7AWHmCQq35Q&t=124s

 

IT 개발자는 오프라인의 작업을 효율적으로 처리하는 방법을 찾아온 직군이고,

AI라는 도구를 잘 써서 어떻게 발전할지에 대해서 잘 고민해보는게 앞으로의 방향성이라고들 말합니다.

제가 생각을 해보고 내린 결론은 어떤 도메인이든 빠르게 적응하고, 그에 맞는 설계를 할줄 아는 사람이 되는 것입니다.

솔루션 개발에 대한 고민

저희 회사도 나름 도메인에 대한 솔루션을 구축하고, 내부 프레임워크화를 통해 이 기술에 익숙해진 사람이 어떤 기능을 구현하는 데 생산성이 좋다고 생각합니다. 하지만 B2B 도메인 특성상 설계된 데이터 모델링 기반에서 도메인 업무를 구현하는 정도의 요구사항이 대부분이여서 대용량 데이터와는 거리가 멀기에 성능, 동시성에 대한 설계는 찾아보기 힘들고(업무 채번 하는 정도) 가끔 네트워크 지연이나 에러로 인해 데이터에 이상현상이 발생하는 경우도 모니터링되는게 아니라 고객이 이상함을 느끼고 문의를 하면 데이터 보정으로 처리하는 프로세스입니다. 회사 입장에서는 이렇게 운영되는게 더 정답일 수 있습니다. 오버 엔지니어링을 통해 프로젝트 기간 내 공수를 오버하거나 유지보수가 힘들 수 있으니까요.

 

고객사의 ERP나 그룹웨어와 연동할 때도 SAP JCO, API, 파일 전송, 중계 DB 등의 방식을 통해 연동되고, 만약 해당 요청이 실패했을 경우에 재처리할껀지, 취소할껀지에 대한 설계 없이 데이터가 이상하다면 보정을 통해 운영되고 있습니다.

 

그리고 오픈된지 7년된 서비스이지만, 테스트에 관련된 클래스도 없고, CI/CD가 구축되어 있지만 Maven 빌드시 -DskipTests=true가 켜진 상태로 배포되고, 기능이 변경되면 사람이 전수 테스트를 하고, 테스트 하는 범위도, 기준도 애매합니다.

 

제가 일을 할 때도 성능을 고려하지 않고 요구사항을 구현만 하면 되니까 지금까지 일정이 빡빡한게 아닌 경우에 기술적으로 어려움을 느낀적은 없습니다. 아직 연차가 얼마되지 않아 그렇게 느낄 수도 있지만 회사 선배님들을 보면 연차가 쌓여도 기술적인 이해보다는 도메인에 대한 이해도가 높아지면서, 고객사와 커뮤니케이션 하는 역량이 발달되는 것 같은 느낌을 받습니다.

 

도메인과 기술

도메인과 기술에 대해서 고민할 때 생각해보게 되는 건

누군가는 이제 기술은 AI가 맡고, 도메인 역량을 키워야 한다고 말하기도 합니다.

 

하지만 저는 조금 다르게 생각합니다.

항공모함을 몰 줄 아는 선장은 통통배를 몰게 되었을 때 금방 적응할 수 있지만, 그 반대는 쉽지 않다고 생각합니다.

결국 기술적인 이해도가 높은 사람은 새로운 도메인을 접하더라도 구조를 빠르게 파악하고 적응할 수 있고,
더 복잡하고 규모가 큰 도메인도 상대적으로 어렵지 않게 이해할 수 있다고 생각합니다.

 

회사의 관리자 중에 많은 분들은 지금 회사의 서비스보다 규모가 작은 곳에서 이직을 하신 분들이 더 많을 거라고 생각합니다.
그러면서 점점 지금 회사가 규모가 큰 설계로 나아가기보다, 짬바로 쌓이는 도메인 역량을 통해 운영되고 있는 상태라고 느낍니다.

실무를 하다 보면 누구나 도메인 역량은 자연스럽게 쌓입니다. 하지만 이런 환경에서는 서비스 규모가 커질 때 필요한 설계나 기술적인 이해는 따로 공부하지 않으면 성장하기 어렵다고 생각합니다.

그리고 이런 기술적인 기반이 부족하면, 새로운 도메인을 이해하는 속도나 깊이에서도 한계가 생긴다고 느꼈습니다.

스프링을 공부할 때 많은 개발자들이 Spring Core와 Spring MVC를 헷갈리기도 하고,

스프링 시큐리티 역시 필터 기반으로 동작하지만, 필터와 매니저 간의 관계를 정확히 이해하지 못한 채 사용하는 경우도 많습니다.

심지어 쿼리를 짤 때도 인덱스 선두 컬럼과 쿼리의 조건절 순서와는 관련이 없다는 사실처럼, 이런 부분들은 단순히 사용만 해서는 알기 어렵습니다.

 

결국 사용하는 기술이 추상화될수록 그 내부 구현에 대한 이해도가 높은 사람이 더 빠르게 도메인을 이해하고, 더 큰 규모의 문제도 다룰 수 있는 무기를 가지게 된다고 생각합니다.

 

어떤 걸 공부해야하나?

현재 계속 발전하는 AI 기술과 그 외의 기술(DB, Java, 시스템 설계) 중 어떤걸 공부해야하나에 대한 고민이 많습니다. 제 생각은 취업을 하려면 후자쪽이 더 유리하고, 뛰어난 분들의 기술블로그를 보면서 어떤걸 공부하냐보다 어떤 것이든 어떻게 공부하는 게 중요하다는걸 배웠습니다. 일단 앞으로 3개월정도는 SQLP 시험전에 짬짬히 공부하던 오라클에 대한 아키텍쳐와 데이터 모델링에 대한 부분을 깊게 파보려고 합니다.

 

마무리

DB에 대한 공부와 시스템 설계에 대한 부분을 조금 더 의식적으로 가져가려고 합니다.

 

우선 Oracle 기반에서 실행계획을 직접 분석하고,
인덱스 설계나 쿼리 개선을 통해 실제 성능을 개선해보는 경험을 쌓으려고 합니다.
단순히 동작하는 SQL이 아니라, 왜 이 쿼리가 이렇게 실행되는지까지 이해하는 방향으로 공부해보려고 합니다.

 

그리고 시스템 설계 측면에서도
지금 환경에서는 많이 접하기 어려웠던 동시성 처리나 트랜잭션, 장애 상황을 고려한 구조를 따로 정리하고,
작게라도 직접 설계해보는 연습을 해보려고 합니다.

 

이런 과정들을 쌓아가면서 단순히 요구사항을 구현하는 개발자를 넘어서,
조금 더 큰 규모에서도 통할 수 있는 설계를 해볼 수 있는 환경으로 가는 것을 목표로 하고 있습니다.