개발에 대한 나의 현재 생각

1. 개발 역량을 쌓는게 진짜 중요한 일일까?

물론 개발자인 입장에서 아름다운 구조 , 견고한 테스트 코드, 읽기 쉬운 코드로 이루어진 프로젝트를 만드는 일이나

그러한 프로젝트를 만드는 방법을 학습하는 것은 매우 재미있는 일입니다.

 

그러나 그런 기술적으로 아름다운 프로젝트를 만드는 일이 곧 돈으로 직결되지는 않는 경우가 많습니다.

기술적으로 매우 큰 도전을 성공해낸 프로젝트보다 사람들이 필요로하는 프로젝트가 더 돈이 잘 될 확률이 높죠

코드를 아무리 아름답게 짜봐야 사용자가 아무도 없다면 그 코드는 가치를 창출할 수 없을 것 입니다.

 

그렇게 생각을 하고나니 개발 역량이라는 것 자체가 중요한것일까? 라는 생각이 듭니다.

제품을 잘 만들수 있는 "일정 수준 이상의 기술력"만 갖추어졌다면 그 이상이 필요할까요?
(물론 그 일정 수준 이상까지 도달하는 것도 제게는 먼얘기지만..)

 

원칙을 지키며 좋은 품질로 개발하는 것은 분명히 장기적인 생산성에 도움이 됩니다.

하지만 당장 생존에 실패한다면 "장기적인 관점" 자체가 의미 없을 것입니다.

---

2. 기술 부채는 안좋은걸까?

익히 들어본 성공한 스타트업들도 많은 기술부채를 가지고 있는 경우가 많은 것 같습니다.

그런데 그 스타트업에서 개발하고 있는 개발자분들이 실력이 부족해서, 혹은 좋은 코드를 짤 능력이 없어서 기술 부채가 쌓이는 걸까요?

물론 절대란 건 없겠지만 대부분의 경우 기술부채가 생기는 것을 용인하면서 스피드를 챙긴 경우일 것입니다.

 

그래서 기술팀을 이끄는 입장에서는 기술부채가 팀 전체의 생산성을 잡아먹는 수준까지 쌓이지 않도록 컨트롤하는

즉 "용인 가능한 수준의 기술부채" 를 유지할 수 있도록 하는 것이 중요하지 않을까 싶습니다.

 

어차피 기술 부채의 발생은 막을 수 없습니다.  기술 부채는 개발자가 성장했기 때문에 발생하기도 하니까요.

오히려 기술 부채가 전혀 없는 조직이 만약 존재한다면 그 조직의 개발자는 더이상 성장하지 않는 것일 수도 있겠다는 생각을 합니다.

---

3. 돈을 버는 코드는 좋은 코드다

이 부분은 지극히 제 개인적인 생각입니다만 저는 돈을 버는 코드가 좋은 코드라고 생각합니다.

아름다운 코드가 유저에게 뛰어난 가치를 전달해줄 수 있다면 우리는 아름다운 코드를 작성하는 데에 시간을 들여야할 것입니다.

 

하지만 실제로 우리는 어떤 서비스를 이용할 때 서비스 자체를 이용하지 그 서비스가 만들어진 코드를 보고 이용하지 않습니다.

예를 들어 제가 토스라는 앱을 사용하는 이유는 송금, 금융자산 관리, 온라인 결제와 같은 귀찮은 부분들을 해결해주기 때문이지

토스의 앱이 마이크로 프론트엔드로 구현되었으며 디자인시스템을 통해 통일감있는 UI를 제공해서 사용하는 것이 아니기 때문입니다.

 

물론 많은 사용자들이 불편함 없이 제품이 제공하는 가치를 100% 200% 전달받으며 사용하기 위해서는

혹은 제품이 제공해야하는 가치 자체가 하나의 커다란 기술적인 챌린지인 경우에는 기술적인 역량이 많이 필요할 것입니다.

그러나 제품의 가치를 잘 전달하기 위해 기술이 필요한 것과 기술을 사용하기 위해 제품을 만드는 것에는 큰 차이가 있다고 믿습니다.

 

어떤 코드가 돈을 번다는 것은 곧 "누군가는 그 코드가 창출하는 가치에 기꺼이 지갑을 열었다"라는 뜻이라고 생각합니다.

그렇기 때문에 코드가 기술적으로 어떤 문제를 가지고 있든 돈을 버는 코드는 그것대로 가치가 있지 않을까 싶습니다.

물론 고객의 지속적인 만족이라는 측면에서 너무 퀄리티가 낮은 코드는 지금 당장 돈을 벌더라도 향후 문제가 되겠지만요

---

4.  코드는 고객에게 가치를 전달할 때 의미를 가진다.

라는 관점에서 바라보았을 때 코드를 잘 작성해야하는 이유는

"그래야 고객에게 더 빠르게, 더 좋은 효용의 제품을 제공 할 수 있으니까"가 되어야 한다는 생각이 들었습니다.

 

TDD를 해야하기 때문에 테스트 코드를 쓰는 데에 시간을 많이 사용했다면 그것은 그만큼 다른 작업을 할 시간을 소모한 것입니다.

그럼에도 불구하고 TDD가 필요한 경우에는 해야하겠지만 비즈니스적으로 치명적인 부분만 테스트 할 수 있겠죠

 

?? 아니 그러면 뭣하러 TDD ,DDD , 클린코드 ,클린아키텍처 이런거 하나요 다 필요없는거아님?

이라는 생각이 들수도 있지만.. 할 줄 아는데 일부러 안하는 거랑 몰라서 못하는거랑은 또 차이가 나는 것 같습니다.

---

5. 맞으면서 배운다.

회사에서 일을 한지도 약 반년이 되었습니다.

관점에 따라서 충분히 역량을 펼쳤을수도, 뭘 해보기엔 너무 짧은 시간일수도 있지만

제가 놓인 환경에서는 꽤 많은 것을 시도해볼 수 있는 시간이었습니다.

프론트엔드 개발자로서 거의 전권을 넘겨받고 작업을 할 수 있었기 때문인데요

 

신규 피쳐작업들을 제외하고 성과를 생각해보면

우선 기존 코드에서 치명적으로 성능 문제 / 비용 문제 / 안전성 문제를 부르는 부분들을 개선하였습니다.

상당히 많은 부분을 개선하는 데에 성공하였고 신규 기능들도 지금은 치명적인 에러없이 잘 배포되고있습니다.

 

그러나 앞에서 많은 부분을 개선했다고 했지만 기술부채를 청산하는 일은 계속 해야만하는 일로 남아있는데요

현재 청산중인 기술부채의 대부분은 제가 예전에 작성한 코드입니다.

분명히 그때에는 최선이라고 생각하며 작성했지만 지금 와서 보니 기술 부채가 된것입니다.

개인의 측면에서는 성장했기 때문에 기술부채가 된것이지만 그래도 기술부채인건 변하지 않습니다.

 

따라서 코드를 리팩토링하고, 죽은 코드를 제거하는 일이 아주 많아졌는데

이 과정에서

1. 너무 많은 코드들이 해당 코드에 의존하고있거나

2. 코드들의 의존관계가 복잡하게 꼬인 경우

3. 추상화가 한레이어도 입혀지지 않은 경우

 

리팩토링하는데에 시간이 상당히 많이 들었습니다.

예컨대 이런 상황을 생각할 수 있습니다.

 

직접 fetch에 의존하고 있는 코드가 100개 있을 경우 이를 모두 axios로 바꿔주는데에는 100번의 공수가 들어갑니다.

하지만 fetch에 직접 의존하는 대신 한번 래핑한 함수에 의존하게되면 그 함수의 구현을 axios로 바꿔주기만 해도 모든 구현이 바뀌죠

 

또 여러가지 문제들이 있는데 대표적으로는 리팩토링하면서 기존 기능이 깨지는 경우입니다.

특히 외부서비스와 실제 상호작용이 필요한 경우에는 테스트코드로 검증을 하더라도

그게 정말 기능을 안깨뜨리는지 확신을 가지기 어려운데요 따라서 회귀테스트를 수행할 수 밖에 없습니다.

 

한편으로는 모든 애플리케이션에 전역적으로 영향을 끼치는 코드가 있을 수 있죠

이런 경우에는 수정을 가하면 모든 애플리케이션에 영향이 가기때문에 회귀테스트의 범위도 앱 전체가 됩니다.

 

이러한 부분들은 사실 이미 나와있는 소프트웨어 방법론을 충분히 이해하고 실천했다면

발생하지 않았거나 , 수정이 필요해도 최소한의 노력으로 수정할 수 있었을 내용들입니다.

이런 관점에서 코딩실력을 기르는 것이 곧 장기적인 생산성과도 연결된다고 볼 수 있겠다는 생각이 듭니다.

 

현재는 기존의 문제에서 착안하여 여러가지 시도를 해보고있습니다.

 

1. 의존관계가 꼬인다 -> FSD 를 적용하여 의존성 방향을 한방향으로 정리한다

2. 레거시코드에 자꾸 의존하게된다 -> 레거시코드를 deprecated 폴더로 모는 것을 통해 사용을 자제하게한다.

3. 구현에 의존하면 리팩토링이 힘들다 -> 최소 1레이어 이상의 추상화를 통해 구현과 의존을 분리한다

 

그러나 그럼에도 불구하고 모든 기술부채를 청산하기는 어려울 것 같습니다.

왜냐하면 이제 제게 남은 기술부채들 중 일부는 다음과 같은 특징을 가집니다.

1. 개선을 위해 많은 회귀테스트가 필요하다.

2. 개선하려면 리소스가 굉장히 많이 들기때문에 팀 관점에서 우선순위가 낮다

 

이러한 기술부채들을 청산하는 것은 개발자로서 꽤 큰 챌린지이지만 이 개선을 통해서

유저에게 어떤 가치를 전달할 수 있는지가 명확하지 않으며 제 리소스가 무한대가 아니기 때문입니다.

 

따라서 이런 기술부채들은 그냥.. 안고 가는 형태를 생각하고있습니다.

---

6. 궁극적으로 되고 싶은 게 뭔가요?

간혹 면접에 들어갔을 때에 이런 류의 질문을 받아본 기억이 있습니다.

뭐.. 10년 뒤에 본인의 모습은 어떨 것 같나요? 같은 형태로도 나오지만 결국 본질은

"네가 궁극적으로 되고 싶은 모습이 뭐냐?"라는 것에 가깝다고 생각합니다.

 

궁극적으로 되고싶은 것...이라고 하면 되게 거창한 것 같아요

다만 저는 제 강점이 무언가를 설명하는 것에 있다라는 생각을 합니다.

그래서 제 강점을 살릴 수 있는 일을 해보고 싶다.라는 관점에서 넓게는 개발에 대한 강의를 찍는다거나

좁게는 다른 개발자들이 이해하기 쉽게 문서를 작성하거나 컨퍼런스를 하는 등의 활동을 하고 싶은 것 같아요

더 좋은 건 그렇게 제가 잘하고 좋아하는 일들로 많은 가치가 창출되는 것이겠죠?

 

궁극적으로 되고 싶은 것은 모르겠지만 방향성은 그런쪽으로 가지 않을까 싶어요

물론 절대라는건 없지만요

---