내가 보는 숲 🌲
숲은 나무 한 그루, 꽃 한 송이, 풀 한 포기가 모여 이루어진 큰 합입니다.
제가 개발에서 보는 숲도 다르지 않습니다.
사용자의 니즈 하나,
기획자의 의도 하나,
디자이너의 표현 하나,
그리고 그 아래를 단단히 연결하는 구조라는 뿌리.
숲은 멀리서 보면 하나의 흐름처럼 자연스럽게 이어져 보이지만,
가까이에서 보면 각 요소가 제 역할을 다하고 있어야 한다고 생각합니다.
저는 개발 역시 그렇다고 믿습니다.
‘나무를 보지 말고 숲을 보라’는 말처럼,
제 손을 거친 결과물이 단편적인 페이지가 아니라
조화롭게 연결된 하나의 숲을 만들고 싶습니다.
구조가 없으면 노력은 누적되지 않는다는 것을 배웠습니다
처음에는 퍼블리셔로 시작해 디자인 구현에 집중했습니다.
하지만 페이지마다 간격과 규칙이 제각각인 시안을 반복적으로 마주하며
일관성이 없는 결과물은 쉽게 무너진다는 것을 체감했습니다.
그때부터 단순히 구현하는 사람이 아니라
규칙을 정의하는 사람이 되어야겠다고 생각했습니다.
공통 클래스를 정리하고, 버튼 수준을 나누고,
반복되는 스타일을 체계화하며 점점 컴포넌트 관점으로 사고하게 되었습니다.
이후 레거시 환경에서 대규모 ERP를 유지보수하며
구조의 중요성을 더욱 절실히 느끼게 되었습니다.
같은 역할의 함수가 여러 파일에 흩어져 있고,
전역과 지역의 경계가 모호하며,
하나의 수정이 여러 페이지에 영향을 미치는 구조.
그 경험은 저에게 명확한 기준을 남겼습니다.
- 기능은 흩어지지 않아야 한다
- 상태와 규칙은 한 곳에서 관리되어야 한다
- 수정 비용을 낮추는 것이 진짜 생산성이다
그 이후 저는 구현 속도보다
“변경 가능성”을 먼저 생각하는 개발자가 되었습니다.
방향이 없는 실행은 사람을 소모된다는 것을 배웠습니다.
무엇을 만들어야 하는지,
왜 만들어야 하는지 정해지지 않은 상황에서
실행은 계속되지만 축적은 남지 않았습니다.
명확한 기준 없이 반복되는 수정과 재작업은
프로젝트를 앞으로 나아가게 하기보다
같은 자리를 맴돌게 만들었습니다.
그 경험을 통해 저는
실행 이전에 ‘기준’을 세우는 일이
얼마나 중요한지 깨달았습니다.
방향이 정리되면
결정은 빨라지고,
수정은 줄어들며,
팀의 에너지는 한 곳으로 모입니다.
그래서 저는 기능을 구현하는 데서 멈추지 않고,
흐름과 기준을 함께 정리하는 개발자가 되고자 합니다.
혼자 잘하는 방식보다, 함께 남는 방식을 지향합니다
대규모 ERP를 혼자 관리하며
많은 문제를 빠르게 해결해야 했습니다.
그 과정에서 기술적으로는 성장했지만,
한 가지 한계도 분명히 보였습니다.
지식과 맥락이 한 사람에게만 집중되면
업무는 점점 개인에게 과중되고,
팀의 역할은 확장되지 않습니다.
기능은 완성될 수 있지만,
자산은 남지 않습니다.
혼자 해결하는 방식은
단기적으로는 빠를 수 있어도
장기적으로는 지속 가능하지 않다는 것을 배웠습니다.
그래서 저는
문제를 해결하는 것에서 멈추지 않고
그 해결 과정이 공유될 수 있는 구조를 고민하게 되었습니다.
- 기준은 문서로 남고
- 규칙은 코드에 드러나며
- 맥락은 팀이 함께 이해할 수 있어야 한다고 생각합니다
개인의 역량이 아니라
팀의 자산으로 축적되는 환경.
저는 그런 구조 안에서
함께 성장하는 개발을 지향합니다.