🛼 우아한 테크캠프 4주차 회고(0725~0729)

🎯 3, 4주차 미션

1. SPA 가계부 프론트엔드 구현(바닐라 JS, 옵저버 패턴 이용)

2. 가계부 백엔드 구현(ExpressJS, MySQL 이용)

3. AWS 이용 배포(스크립트 이용 지속 배포)

---

3주차에는 초기 설계를 중점으로 진행하고 4주차부터 본격적인 기능 개발에 들어갔습니다. 주요 기능은 다음과 같습니다.

• 거래내역 리스트 렌더링
• 거래내역 폼 컴포넌트 구현
• 거래내역에 따른 차트, 차트 애니메이션 구현
• 이벤트에 따른 상태 변경

다행히 초기 설계가 어느 정도 탄탄하게 잡혀있어 구현에 큰 무리는 없었습니다. 어려운 점이라면 이벤트에 대한 설계는 진행하지 않아 해당 부분을 구현하는데 있어 다소 코드가 어지럽게 작성되었다는 점이 있습니다...

이벤트에 대한 설계를 생각하지 못했기 때문인 것 같습니다. 구조에 대한 설계와 더불어 서비스에 대한 설계에도 조금 힘을 줬었더라면 더 좋았을 텐데라는 아쉬움이 있습니다. 😢

🍎 미션 진행 중 고려한 사항

🎀 프론트엔드

매직 넘버와 유틸 메소드 분리하기

이번 미션에서는 저번에 받았던 피드백을 토대로 매직 넘버를 최대한 줄이고 유틸 메소드들을 분리하려는 노력을 했습니다. 물론 그래도 어지러워지는 부분이 있지만, 저번 미션보다는 조금 성장한 느낌입니다! 😃

컴포넌트 나누기

하지만 이번에도 저번 미션과 동일한 문제가 생겼습니다.

하나의 컴포넌트가 무려 400줄 가까이 차지합니다. 이것이 위에서 말했던 이벤트 설계를 하지 않아 생긴 문제인데, 여러 개의 이벤트가 하나의 컴포넌트에서 호출되다 보니 이런 현상이 발생한 것 같습니다.

컴포넌트를 나눌 때 컴포넌트는 독립적이고 재사용 가능한 단위라고 생각하고 해당 기획에서 재사용 할 필요가 없다면 컴포넌트를 분리하지 않았습니다. 서비스의 확장을 고려하지 않고 기획에 매몰된 코딩의 안타까운 결과인 것 같습니다..

컴포넌트는 UI를 잘게 나눠 재사용이 가능하게 하고, 또 개발자가 생각을 독립적으로 나눌 수 있게 도와주는 개념인데 이것을 잘못 인지하고 오히려 잘못된 개념에 사로잡혀 억지스러운 개발을 했던 것 같습니다. 이번에 구현한 HistoryForm에서 그런 부분들이 두드러졌는데, 그렇기 때문인지 가장 난해한 코드가 되어버렸습니다.

항상 모든 패턴과 개념들은 개발자가 개발을 편하고 협업을 용이하게 할 수 있게 도와주는 것들이라는 생각, 그리고 요구사항이 언제든지 변할 수 있다는 생각을 가지고 유연하고 작은 단위의 인터페이스로 구성된 애플리케이션을 만들어야겠습니다.

🎉 백엔드

역할의 분리

백엔드와 프론트엔드를 구현하면서 다른 팀과 기술을 공유하는 시간을 가졌습니다. 개발을 진행하면서 저희 팀이 가진 의문이 있었습니다. DB에 저장된 데이터를 가공하는 로직을 어디서 수행해야 하는지에 관한 것입니다.

다른 팀의 캠퍼 분은 백엔드를 최대한 원형의 데이터만 전달해주도록 구성해 범용성을 높이는 구조도 괜찮다고 말씀하셨는데 당시에는 이것이 괜찮다고 생각해 저희 팀도 그런 방식으로 데이터의 가공을 프론트엔드에서 하는 식으로 개발을 진행했습니다.

하지만 조금 시간이 지나고 생각해보니 프론트엔드는 뷰에 관한 내용들만 중점적으로 처리하는 것도 좋겠다는 생각이 들었습니다. 백엔드로 쿼리 스트링 등을 통해 데이터의 가공을 요청하고 그것을 렌더링하는 방식으로 구현한다면 더 좋지 않을까 하는 생각이 듭니다.

여전히 정답은 모르겠지만 개발 서적이나 다른 참조물들을 보면서 생각을 하는 시간을 가져야겠습니다.

🛠 특강

김민태님과 우아한 테크캠프 3기 출신이신 장해민님의 특강을 들었습니다. 김민태님은 여러 매체를 통해 익히 알고 있던 분이셨고, 장해민님은 캠프에 대한 정보를 찾아보면서 처음 알게 된 분이었는데 우아한 형제들에 입사하고 얼마 되지 않아 핵심적인 서비스를 만드셨다는 말을 듣고 대단하다고 생각했습니다.

👀 프론트엔드 개발자가 일하는 법

프론트엔드 시장은 변화가 심합니다. 이런 상황 속에서 프론트엔드 개발자는 지속적으로 좋은 생산성을 유지해야합니다. 새로운 툴이 나오고 빈번하게 변화하는 디자인 패턴 사이에서도 핵심적인 개념은 있습니다.

김민태님은 이것을 immutable한 지식들이라고 표현하셨는데, 예를 들면 CS 지식 등이 있습니다. 실제로 CS를 공부하다보면 Dead lock의 해결이라던가 연속적인 자원을 연결하는 것 등 유사한 개념들이 다양한 분야에 걸쳐 반복적으로 나타납니다. 겉모습은 바뀌더라도 기저에 깔린 핵심적인 내용들은 내심 비슷하다고 생각했었는데 프론트엔드 분야에서도 비슷한 양상을 보이는 것 같습니다.

이런 상황 속에서 프론트엔드 개발자가 가져야 할 역량은 구현의 자동화를 가능하게 하는 인터페이스의 구현이라는 생각이 들었습니다. 단순한 UI의 구현이 아닌 그것을 한눈에 파악하고, 확장과 유지보수에 용이한 코드를 작성하는게 좋은 프론트엔드 개발자가 가져야 할 능력인 것 같습니다.

그 외에도 기술을 선택했을 때 그 기술을 선택한 이유, 프레임워크나 라이브러리를 이용해 문제를 해결하지 못했을 때 얼마나 로우레벨까지 내려가 해결이 가능한지, 다른 분야와 의사소통하기 위한 기본적인 지식 등 자신이 알고 있는 것을 표현하고, 타인이 표현하는 바를 잘 이해하는 것 또한 프론트엔드 개발자가 가져야 할 역량에 포함된다는 생각이 들었습니다.

🧠 고민과 생각

1. 인터페이스의 구현

인터페이스를 구현할 때 try catch를 통해 에러 여부를 표시합니다. 단순히 console.log로 에러를 출력했었는데, 어떤 에러이고 어떻게 해결해야 하는지를 함께 표현하는 것도 포함해야할 것 같습니다. 보통 라이브러리를 이용하면 에러 발생 시 친절하게 예상 원인과 해결 방안을 표현해줍니다. 개발자가 사용하는 만큼 개발자 친화적인 문구를 함께 넣는 코드 작성을 해야겠습니다.

2. 코드의 분리

하나의 블록에서 너무 많은 작업을 하면 해당 코드를 파악하기 어려워집니다. 이때 코드를 분리해야하는데 문제는 공통된 데이터를 전달하는 방법입니다. 보통은 인자로 넣어 전달하지만 그렇게 된다면 가독성이 흐려질 위험이 있습니다. 이때 크롱은 객체로 감싸 키로 전달해주는 인자의 표현을 풍부하게 할 수 있다는 말을 했습니다. 코드가 조금 길어지더라도 그 뜻을 명확히하는 것을 항상 생각해야겠습니다.

3. 변화에 대응 가능한 코드

데이터의 형태에 의존적인 코드는 좋지 않습니다. 데이터의 구조가 바뀌게 되면 앱이 깨져버리기 때문입니다. 그렇기 때문에 고정된 클래스 이름이나, 관심사에 불필요하게 많은 정보가 들어가는 건 위험합니다. 콜백을 전달할 때에도 해당 콜백이 수행하는 이름 형태로 전달하는 게 좋지 콜백 자체를 넣는 건 좋지 않습니다. 그 콜백에 내부적으로 어떻게 동작하는지는 사용 측에서 가져야 할 관심사가 아니기 때문입니다.

최대한 추상화 계층을 제공해 인터페이스 위주의 구현을 해야겠습니다. 항상 생각하고는 있지만, 구현에 쫓기다 보면 쉽게 잊혀지는 것 같습니다. 🥲

🔥 후기

이번 미션은 많은 것들을 배울 수 있었습니다. 풀 리퀘스트를 날리면서 다시 푸시를 하면 변동된 내용이 해당 풀 리퀘스트에 자동적으로 반영된다는 것도 알았고, console.log를 통한 디버깅을 의식적으로 자제하고 디버깅 툴을 이용하면서 좀 더 효율적인 개발을 할 수 있었습니다.

구조에 대한 고민, 설계에 대한 고민 등 혼자서라면 하지 않았을 고민들을 할 수 있다는 점에서도 이번 미션은 스스로 생각하기에 큰 성장을 이룰 수 있었다고 느껴집니다.

자세한 구현 사항들을 다시 한번 정리하면서 얻은 지식들을 되새겨야겠습니다.