앱 개발 개척시대
K리그 프로그래머
[요즘 프론트엔드, 정답이 있을까?]
프론트엔드에서 '설계'라고 하면 주로 이런 것들이 논의된다.
1. 저장소 아키텍처: 폴더 구조를 위시한 저장소 구조
2. 컴포넌트 구조: 재사용 가능한 UI 컴포넌트를 어떻게 구성할지, 컴포넌트를 가져다 쓰는 측에 얼마만큼의 자유도를 부여할지 등
3. 상태 관리: 애플리케이션 내부에서 데이터가 어떻게 흐를지, 상태는 어떻게 관리할지, 라이브러리(react-query, redux-toolkit 등 선택)는 무엇을 쓸지 등
4. 기타: 테스트 전략, 성능 최적화 전략, 코드 스플리팅 및 번들링 전략, 라우팅 설계, API 통신 전략, 반응형 디자인, 접근성 고려 등
여기에 더하여 인프라에 접근 권한이 있는 조직이라면 프론트엔드 엔지니어는 이런것 까지 추가 고려해야 한다.
5. 배포 파이프라인: 빌드용 인스턴스 선정 및 관리, 스토리지 선정 및 관리(주요 헤더 설정), CDN 선정 및 관리
6. 보안 설정과 모니터링 및 로깅: CSP 등의 설정, 성능/에러 추적을 위한 도구 선정 및 관리
다양한 조직을 겪어본 분들은 아시겠지만, 이런 부분은 상황에 따라 정해지는 것이기 때문에 합의의 영역에 가깝지 정답은 없다.
그런데 요즘 매주 주니어로 구성되어있는 멘티 그룹과 소통을 하다 보니 정답을 찾는 분들이 꽤 많은 것 같다는 생각이다.
사실 나도 몇 개 밖에 조직 경험을 하지 못했을 때 그랬었다. 인터넷에서 본 외국인이 쓴, 조회수가 많은, 동의(좋아요, 하트 등)를 많이 받은 글에 적혀있는 전략이 우리 조직의 전략과 다를 때면 속으로 '옛날 기술에 머물러 있는 것은 아닌가' 라는 생각으로 조바심이 났었다.
그런데 소프트웨어 공학 연구자들이 로켓을 쏘면서, 위성을 만들면서, 전 세계인들이 쓰는 클라우드 서비스를 만들면서 축적한 노하우를 방법론으로 정립한 베스트 프랙티스를 모두 지키는 조직은 없다. 프론트엔드 측에도 마찬가지이다.
'정답은 없지만, 각 상황에 맞는 최선의 선택이 있을 뿐'이다.
요즘은 대학원에서 소프트웨어 공학을 전공할 때 전 세계인 누구나 알만한 조직에서 오신 연사님이 해주셨던 강연이 머릿속에 자주 떠오른다.
마지막에 강조해주셨던 부분이 '소프트웨어 공학에 정답은 없다'였다. 그때는 프로젝트 경험이 거의 전무하다 싶어 말이 와닫지 않았지만 말이다.
요즘은 정답을 찾는 분들께 어떻게 코칭을 해드려야 나은 방향일지 고민을 자주 하게 된다. 나에게도 적용되는 고민이기도 하고.
일단은 다양한 레퍼런스(글, 저장소)를 보여드리면서 정답이 없다(이 방법도 쓰이고, 저 방법도 쓰임)는것을 알려드리고 '구성원들이 납득할만한 (유연한) 규칙'이 세팅되면 그걸 토대로 발전시켜 나가는것이 좋겠다라는 가이드를 드리는 편이다.
왜 우리 세대는 '정답'을 찾는 방향으로 사고를 하고 있는지에 대한 이야기도 해드리는 편이고.
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 7월 6일 오후 6:23
댓글 0
함께 읽은 게시물
<일이 많다>
스타트업의 CTO는 해야하는 일이 정말 많다.
어떤 때는 인프라를 다루기도 하고,
어떤 때는 플랫폼을 만들기도 하고,
어떤 때는 프론트엔드 개발을, 어떤 때는 백엔드 개발을,
어떤 때는 모바일 개발을 하기도 한다.
여러 사람을 채용할 수 있다면 좋겠지만,
작은 회사에서 채용이란 쉽지 않은 의사결정이다.
<일 할 시간 벌기>
매니저가 해야 하는 일이 여러가지가 있는데,
주된 일 중 하나는 아무래도 미팅일 것이다.
의미있는 미팅도 있지만 당연히 그냥 들어가야만 하는 미팅도 존재하고,
내가 그 자리에 앉아있는 것만으로도 효과가 발생하는 미팅도 있다.
그러나 그렇게 하다보면 자연스럽게 실제 업무를 할 시간,
그러니까 내가 일을 할 시간이 부족해지는데 그런 케이스를 방지하기 위해
Block 일정을 만들어 둘 필요는 있다.
<야근에 대해서>
나도 처음에 가장 못하던 일이 아닐까 싶은데,
디테일에 과도하게 매몰되다가 자연스럽게 야근을 하게 되었다.
예를 들어 2주 정도를 야근하면, 1주 정도는 그냥 내리 쉬어야만 했고,
그 뒤로 2주는 그에 대한 여파로 업무 효율이 떨어지는 식이 많았다.
단순히 체력적인 피로도 뿐만 아니라,
2주간의 야근으로 인한 정신적인 피로도가 잘 회복이 안되더라.
그래서 내가 야근한 건 2주였지만, 실제로는 3주를 손해본 거나 다름없었다.
간혹 일정이 급할 때 그렇게 할 때가 있기는 하지만,
그럼에도 만약 야근을 해야만 해결할 수 있는 문제가 있다면,
애초에 플래닝이 잘못된 건 아닐 지 고민해보면 좋겠다.
특히 매니저라면 더욱 그런 시야가 필요하다.
'지금 당장 필요한 기능인 지' 체크해보는 게 의미가 있다고 생각한다.
<신뢰 자산의 관리>
조직에서 신뢰 자산은 그 무엇보다 중요한 자산이라고 생각한다.
나와 팀원간의 신뢰, 나와 다른 매니저간의 신뢰, 경영진 사이의 신뢰 등 다양한 신뢰 관계를 잘 맺어두는 것이 업무의 효율을 높이는 데 큰 도움을 준다.
신뢰도가 낮아질 수록 조직은 불신을 기반으로 한 조직 관리를 하게 되는데,
그렇게 하게 될 경우 조직 구성원들의 만족도가 떨어지게 된다.
특히 조직에 대한 애정도가 높았던 구성원일 수록 더 그렇게 되는 듯 하다.
일을 잘 할 수 있는 인재가 신뢰를 받고 일을 잘 할 수 있게 만들어 주는 것이,
어떻게 보면 관리자의 주된 역할이라고 할 수 있다.
신뢰를 잃는 순간 모든 걸 잃는다.
GraphRAG 에 대한 생각
2000년 초반부터 온톨로지 연구를 해왔고, 관심을 갖고 있는 사람으로서 GraphRAG 에 대해 갖고 있는 생각을 적어봤습니다.
... 더 보기Next.js 프로젝트를 AWS EKS에 배포하며 배운 것들
최
... 더 보기
