안녕하세요 어딘가의 신입으로 일하게 된 접니다.
즐거움 반 걱정 반으로 첫 직장에 어느정도 적응을 마쳐가고 있습니다. (미쳐가고 있습니다가 맞을수도 있어요)
팀의 도메인 비즈니스를 공부하고 코드를 보면서 구현 과정을 살펴보면서 어떤 논리와 흐름으로 기능이 작동하는지 많이 감상하게 됩니다.
볼때마다 복잡하고 어렵게 느껴지지만, 그 안에서 배울점도 많이 느끼고, 학구열도 불타오르는 그런 열정 넘치는 단계에 있습니다!
어느회사나 코드를 보면 정말 오랜 세월동안 쌓인 방대한 분량의 로직들이 있을 겁니다. 그것도 몇년 동안 여러 사람을 거쳐온, 각자만의 생각으로 구현된 내용이 있는지라 그동안 배워온 기본 상식에 맞지 않고, 가독성이 떨어지고, 직관적인 코드를 많이 보게 될 겁니다.
(어떤 회사에서는 8중 for문을 쓰고 있다는 이야기도 들었습니다 ㅋㅋㅋㅋ)
신입의 입장에서 열정이 넘쳐서 이런 코드들을 전부다 뜯어 고치겠다고 생각하면 큰일납니다. 잘돌아가는 건 괜히 건드리지 말란 이야기가 있는게 아니에요. 당시에 있어보지 못했지만, 그때에 할 수 있는 최선이었을지도 모른다고 생각합니다. 시간이 촉박하고, 효율보다는 결과를 내야하는 코드였다면, 저라도 그런 레거시를 생상하지 않았을까 싶습니다. 그러다 DDD라는 주제에 대해 발표를 준비하게 되면서 이런 레거시를 다르게 바라보게 되었습니다. 우리가 DDD를 추구해야 하는 이유에 대해서 알게된 적 사실중 하나로 레거시와의 공존이 있었습니다.
현재 우리가 가지고 있는 현실 세계의 문제를 소프트웨어 세계로 가져오면서 '어떤것을 정의할 것인가'에 대해 생각하게 되었습니다. 기존에는 분명 '기능'중심의 사고가 정답이었을 것입니다. Top-Down 형식의 요구사항을 정의하고, 그 기능에 맞게끔 코드를 작성하는 것이 정답이었을 것입니다. 그러다보니 체계가 부족했고, 장애가 빈번하고 문제가 발생하면 해결에 시간이 오래걸렸을 것입니다. 하지만 '기능' 관점에서 벗어나 우리가 '도메인' 을 어떻게 정의할 것인지 생각을 하게 되면서 많은 변화가 찾아왔다고 생각합니다.
개발자는 현실세계의 문제를 소프트웨어의 세계로 가져와서 문제를 해결하는 사람들입니다. 소프트웨어의 세계는 현실세계와 달리 우리가 말로 해결하는 것보다 훨씬 더 복잡하고 어려운 과정을 거쳐야 합니다. 그렇기에 문제를 정의하는 과정이 무엇보다 중요합니다. 어떻게 도메인을 정의할 것인지 유비쿼터스 언어, 바운디드 컨텍스트 등 기획에 가까운 관점에서 Bottom-Up 방식으로 '이벤트 스토밍'을 하는 것이 중요하다고 DDD에서는 설명합니다.
사실, 그렇다고 DDD를 맹신하고 이것처럼 레거시와 공존하라는 의미는 아닙니다. ㅎㅎ 저 또한 DDD를 오히려 하나의 고착화된 방법론으로 여기지 않았으면 좋겠다고 생각합니다. 적어도 레거시 코드가 어떤 이유로 저렇게 짜여졌는지를 이해해보고, 그것들을 마냥 싫어하기 보다 이것들과 어떻게 협력하면서 나의 비즈니스 로직을 담아내볼까 고민하는 과정이 더욱 중요하다고 생각합니다. (물론 이 안에서 수많은 토론과 타협을 다른 개발자들과 보아야겠죠?? 저도 아직 토른을 못해봤지만 기대됩니다)
그래서 앞으로 여기에는 제가 배운 개발 방법을 정리해보려고 합니다. 적어도 내가 왜 이렇게 코드를 작성했는지 생각하기 위해선 충분한 학습과 경험이 있어야 한다고 생각합니다. 그러니 앞으로도 실험실과 병행해서 기록해볼 테니 많은 분들과 여러 생각을 공유할 수 있었으면 좋겠습니다. 모든 취준생 신입 분들 화이팅..!
'개발 생각' 카테고리의 다른 글
| 개발 생각 2 : 테스트를 위한 대량 더미 데이터 삽입 방법 (0) | 2024.12.17 |
|---|