article/frontend_architecture/

[utterances-bot]

2023-10-05 우리는 정말 프론트엔드 '엔지니어'일까? | saengmotmi's blog

전혀 스윙... 아니, 엔지니어링을 하고 있지 않아...?

https://saengmotmi.netlify.app/article/frontend_architecture/

[endmoseung]

RSC에 대한 블로그글을 보다가 여기까지 왔어요! 저는 스타트업에 재직중인 1년차 프론트엔드 개발자인데 처음에 회사에 왔을때 난잡한 코드를 보고 고치는데 상당히 애를먹고 화가 났었어요. 그리고 그런 코드드를 보면서 나름의 코딩원칙을 정하고 설계해가려고 노력했었어요. 아직은 경험이 많지 않아 뭐가 맞는것인지 명확히 알지는 못하지만 이 글을 보고 나름의 결심이 선 것 같습니다. 좋은 글 감사드립니다:)

[pelly-ryu]

안녕하세요 우연히 streaming 관련 이야기를 찾다가 블로그에 방문해서 글들을 매우 즐겁고 유익하게 잘 읽었습니다. 좋은 포스트들을 나눠주셔서 감사합니다.

이 포스트의 내용에 공감합니다. 저도 그냥 한 명의 헤매고 있는 엔지니어지만, 평소 고민해 본 문제라서 생각을 적어보고 싶네요.

좋은 코드란 건 사실 매우 현실적이고 실천적인 것인것 같아요. 해당 소프트웨어 조직이 가장 문제를 잘 해결할 수 있는 형태가 좋은 코드(구조)인 것이고, 나머지는 전부 부차적인 것이 아닐까, 그런 생각을 합니다. 시간이 지날수록, 도발적일 수도 있다고 말씀주신 책 인용들에 더 깊이 공감하게 되고, 반대로 SOLID 원칙이나 클린(또는 레이어드, 헥사고날, MVC) 아키텍쳐 같은 특정 방법론에는 예전과 달리 열정이 많이 생기지 않는 것 같아요.

비슷한 버그가 반복되거나, 기능을 추가하기 힘들거나하는 문제 상황을 맞닥뜨리고 최소 리소스 투자(line diff일 수도 있겠고, 업무 시간, 팀의 학습 비용, 아니면 라이브러리 변경일 수도)로 해결하려고 고민하다 보면, 천재들의 방법론과 원칙들이 머리를 스쳐가고 많은 도움을 받기는 하지만 정답을 콕 집어주진 않을 때가 많더라고요.

아마 제 미숙함 때문일 때가 많겠지만요. 그런 미숙함마저 포함한, 해당 조직의 현재 역량이 좋은 코드를 정의하는 데에 영향을 준다는 생각을 하게 됩니다. 극단적인 예로, 경험이 부족한 어떤 학생들의 프로젝트라면, 하나의 페이지가 하나의 파일에 모두 작성되는 것이 좋은 코드일 수도 있다는 생각입니다. 그들이 직접, “아, 이건 매번 git conflict이 나서 너무 힘들다” 같은 깨달음을 공유한 후에야 파일을 나누는 것이 그들에게 좋은 코드가 되는 게 아닐까 하는 거죠. (결론이 “우리 git같은 이상하고 어려운 거 쓰지 말고 구글드라이브로 코드 관리하자”일 수도 있겠지만요 ㅋㅋ)

비슷한 이유로, ”문제가 아직 느껴지지 않는다면 구조에 문제가 없다“라고 생각합니다. 오버엔지니어링은 소중한 리소스를 좀먹고 비지니스를 느리게 만든다고 생각해요. 물론 이 ”문제“란, 반드시 말씀하신 ”근본적인 부분에 대한 문제“를 포함해야 하겠지만요. 다만, 느낄 수 없는 사람이 느끼려고 억지로 노력한다고 해서 제대로 문제를 정의하고 풀 수는 없는 것 같다는 생각입니다. 기술적으로 학습하고 성장하는 조직은 굳이 억지로 하지 않아도, 도메인과 사용하는 기술에 대한 전문성이 올라감에 따라 문제를 자연스럽게 느끼게 되고, 구조에 개선을 가하게 되는 거 같아요.

예로, ”이 컴포넌트는 너무 길고 다루는 정보가 많아서 쪼개야 해“는 가짜 이유(=리소스 낭비)이고, ”이 컴포넌트의 일부를 다른 곳에 넣어야 하는데 이 구조로는 불가능해“는 진짜 이유라고 생각합니다. 가짜 이유를 사용하면 리뷰 과정에서 불필요한 갈등이 생기고, 진짜 이유로 리뷰를 주고 받다 보면, 모두가 어느샌가 ”처음부터 이런 식으로 짜놓으면 나중에 편하겠다“라는 공감대가 생기는 거 같아요.

사실 오버엔지니어링인지 아닌지 경험이 부족한 상태에서는 판단하기 힘들고, 구조의 문제를 어떻게 해결해야 하는지도 직접 구조를 엎거나 망쳐 보아야 깨닫는다는 지점에서 제가 적어놓은 의견도 별로 의미 없을 수 있다는 한계가 있다고는 생각합니다만.. 그리고 어느 레벨까지 멘토가 있는 조직인가에 따라서도 많이 달라지겠고요.

암튼 전 이런 느낌의 결론을 나름대로 내려 놓고 있어서, 나눠 보고 싶었습니다. 좋은 블로그 운영해주셔서 감사합니다.

[saengmotmi]

@pelly-ryu 이 글을 쓰던 때는 '나 스스로 정리되는 것'이 중요했다면, 지금은 언급해주신 내용.. 그러니까 팀원들과 어떻게 보폭과 방향성을 맞추며 나아갈 수 있을지가 화두인 상태네요.

그런 측면에서 '느낄 수 없는 사람이 느끼려고 억지로 노력한다고 해서 제대로 문제를 정의하고 풀 수는 없는 것 같다'는 말씀은 여러 생각이 들게 하는 문장인거 같습니다. 시간과 자원이 무한하다면 느낄 때까지 기다릴 수도 있겠지만 대체로 시장은 우리를 기다려주지 않으니까요... 그렇다고 내가 정답을 알고 있냐 하면 그건 또 아니라 더 어렵고요. '기술적으로 학습하고 성장하는 조직은 굳이 억지로 하지 않아도, 도메인과 사용하는 기술에 대한 전문성이 올라감에 따라 문제를 자연스럽게 느끼게 되고, 구조에 개선을 가하게 되는' 선순환이 가능하도록 하는 공식을 발견하고 싶은 마음입니다 ㅎㅎ

가짜 이유를 기반으로 주고 받는 리뷰의 폐해에 대해 언급해주신 부분들도 참 공감이 되네요. 여러모로 다 겪어보고 경험에서 하시는 말씀인 것 같아 읽으면서 편안함 마저 느껴지는데 저는 아직 그정도 까지는 지식과 경력이 없어서 그나마 교과서적 원칙이라고 할 수 있을 만한 것들에 대해 공부해나가야겠다 싶긴 합니다. 말씀해주신 대로 좋은 코드란 실천적인 것이겠지만 또 한편으로는 어디로 나아가야 할지 어디쯤 와있는지 인지한 상태에서 실천적인 것은 또 다르니까요. 다만 처음만큼 재미가 있진 않네요 ㅋㅋㅋ ㅠ

장문의 댓글 남겨주셔서 감사합니다. 뻔한 글들이 많이 올라오지만 그래도 종종 들러주시면 반가울 것 같습니다. 멋진 주말 보내시길 바랍니다 :)

[pelly-ryu]

GitHub 로그인을 쓰는구나 했는데, 이슈에 댓글이 달리는 거였군요? 이거 재미있네요.

저도 @saengmotmi 님도 화이팅입니다. 블로그 종종 보겠습니다. 그럼 저는 이제 월요일이 되어 이슈의 산으로... 😭