글또 프론트엔드 / 모바일 반상회를 다녀오고

 

4월 4일, 어제 글또에서 진행하는 프론트엔드 / 모바일 반상회를 다녀왔다. 

신청을 제 때 못했었는데 양해해주신 성윤님 정말 감사합니다 🙏

 

감사하게도 잡플래닛에서 공간 대여를 해주셔서 잡플래닛 사무실도 잠깐 구경할 수 있었다. 이전에 취업할 때 잡플래닛 많이 사용했었는데 뭔가 더 반갑고 신기한 느낌.. ㅎㅎㅎ

 

아래처럼 굿즈(글또 + 잡플래닛)도 준비해주셨다.

 

간단하게 잡플래닛 소개도 해주셨는데 AI 팀을 따로 운영 중인 것도 신기했고, 잡플래닛이 현재 사용 중인 기술스택(레이아웃은 FlexLayout / PinLayout / Then)도 들을 수 있어 좋았다. 

(현재 회사도 일정 부분 비슷한 서비스를 진행 중이라 어떤 기술을 사용하고 어떻게 일하는지 좀 더 관심있게 봤다)

 

1부 발표.

View를 대하는 클라이언트 개발자의 자세 (신해나라님)

클라이언트 개발자라면 User Application (프론트엔드 / 모바일 + Flutter, React Native) 개발을 할 것이고 그렇다면 대부분 뷰를 개발하고 있을 것이다. 

 

나 또한 클라이언트 개발자로서 항상 뷰를 다루고 있었지만 `뷰`라는 것 자체에 고민을 크게 해본 적은 없었는데, 개발하면서 놓치기 쉬운 접근성 같은 것들을 언급해주시며 `뷰`에 대해 조금 더 생각해볼 수 있었던 세션이었다. 

 

일단 View는 어플리케이션과 사용자가 만나는 인터페이스로 사용자에게 정보를 제공하고, 사용자에게 정보(User Interaction)를 다시 받는다.

 

신해나라님은 크게 2가지 관점으로 뷰를 말씀해주셨다. 

 

사용자 관점에서의 뷰

뷰 만큼이나 빈번하게 사용하는 말이 바로 UI / UX인데 여기서 UX는 단순히 사용자가 느끼는 경험 정도로만 생각했다. 

User Experience의 줄인 말이니 말이다. 물론 틀린 말은 아니지만 좀 더 세부적으로 UX에 대해 설명을 해주셨다. 

 

 

UX를 말할 때 한 번쯤은 언급되는 이미지라고 하셨는데... 부끄럽지만 어제 처음 봤다 😅 

그래도 UX를 말할 때 다양하게 고려해야할 부분을 잘 설명해주는 이미지라고 생각해서 가져왔다. 

 

신해나라님은 아래 4가지 측면에서 UX 적으로 고려할 수 있다고 말씀주셨다. 

• 어떤 사용자가 
• 어떤 환경에서
• 가장 필요한 것을
• 가장 좋은 방법으로 

요런 가치들을 잘 제공하고 있으면 좋은 UI / UX라고 볼 수 있을 것이다.

 

하지만 여기서 우리 클라이언트 개발자가 기여할 수 있는 부분은 여전히 Surface 단, 즉 뷰를 개발하는 것이다. 

어쨌든 대부분의 업무 플로우가 기획자가 제공하는 기획을 토대로 개발이 되기 때문이다.

그렇기 때문에 할 수 있는 것들 2가지를 말씀주셨다. 

 

사용성 개선하기

   

    옆에 이미지와 같은 더보기 버튼이 존재한다고 생각을 해보자. (SF Symbol ellipsis 이미지)

 

저 이미지 영역만큼 딱 맞게 버튼을 생성한다면 탭 이벤트를 인식하는 영역이 너무 작을 것이고 그렇다면 사용성이 떨어질 것이다. 

그래서 여기에 패딩을 넣어서 탭 이벤트 영역을 넓힌다면 사용성이 좀 더 개선이 될 수 있을 것이다.

 

접근성 개선하기

접근성은 애플에서도 강조하는 부분이긴 하나.. 항상 제대로 안되고 있는 부분이긴 했는데 말씀해주셨다. 

 

일단 접근성이란 장애인에 한정되어 사용하는 것이 아닌 모든 사람에게 적용이 되는 부분이다. 

• 소음이 심한 상황
• 일시적으로 깁스 등을 해서 제약이 생긴 경우
• 운전 중인 경우

 

이런 상황들에선 신체를 자유롭게 사용하지 못하는 환경에 처할 수 있으며 이런 상황은 모든 사람들이 겪을 수 있는 부분이기 때문이다. 

따라서 요런 부분까지 신경을 써줄 때 조금 더 나은 UX가 될 수 있을 것이다.

 

개발자 관점에서의 뷰

어떻게 뷰를 개발하는지에 대해 말씀해주셨다. 

요즘 안드로이드, iOS 가릴 것 없이 핫한 선언형 UI부터 클린 아키텍쳐 등 말이다. 

 

특히 공통된 뷰는 커스텀으로 만들어서 처리를 하는 것을 권장하셨다. 

아무래도 공통된 부분을 분리해놓지 않고 있다가 해당 뷰에서 공통적인 변경 사항이 생긴다면 커스텀이 되어 있지 않은 경우 사용하는 곳을 전부 찾아서 다 바꿔줘야 하기 때문이다. 

 

이 부분 역시 공감이 되는 부분이었다. 한 번 커스텀을 잘 해놓으면 사용하는 사람들도 편하고 리팩토링 내성도 갖게되니 말이다. 

 

개발자 관점에서의 뷰의 핵심은 경험치를 많이 쌓는 것이었다. 

다양한 뷰를 직접 많이 개발해본다면 조금 더 좋은 뷰를 빠르게 개발할 수 있게 되기 때문이다. 

 

클라이언트 개발자라면 뷰를

• 많이 개발해보고
• 기본 컴포넌트도 많이 사용해보자 (좋은 기본 컴포넌트들이 많다. 어떻게 구현이 되어 있을 지도 생각해보자)

 

미래의 클라이언트 개발자

그러면서 요새 유튜브 주제로도 많이 올라오는 AI 시대에 클라이언트 개발자에 대해 말씀해주셨다. 

 

다른 직종들의 경우도 오히려 반복 작업의 경우 아직 사람들이 하는 경우가 많고 오히려 창의적인 것을 요구하는 예술, 음악 쪽에서 AI가 활약하고 있는 경우도 많기 떄문에 오히려 클라이언트 개발자는 수명이 더 길수도 있지 않을까 말씀해주셨다. 

 

그리고 Vision OS도 등장하면서 새로운 형태의 것을 요구하는 클라이언트 개발자가 생길 수도 있고 말이다. 

Vision OS는 나도 관심이 있고, 최근 컨퍼런스에서 종종 시도해보시는 분들도 계시던데... 역시 SwiftUI를 좀 더 공부해야 하나 싶다 ㅎㅎ

 

그러면서 미래 클라이언트 개발자들은 아래 일을 할 수 있지 않을까 언급해주셨다. 

• 앱 배포 (시기 결정)
• 뷰 이슈 대응
• 기종별 호환성 검사
• 새로운 View 프레임워크가 나온 경우 이를 AI에 데이터 학습 시킴

 

항상 내가 하는 일과 맞닿아 있고, 알고는 있었지만 깊게 신경쓰진 못했던 부분을 다시 한 번 듣고 상기할 수 있다는 측면에서 되게 좋았다! 그리고 특정 플랫폼에 묶이지 않고 모두가 잘 들을 수 있는 발표를 너무 잘 준비해주셔서 좋았다. 

 

 

기술 블로그를 위한 SEO (정종윤님)

https://wormwlrm.github.io/2023/05/07/SEO-for-Technical-Blog.html

기술 블로그를 위한 SEO - 재그지그의 개발 블로그

 

요건 발표 제목만 보고 정말 관심이 갔던 부분이었다...

블로그에 140개 정도 글을 올렸지만 아직 조회수가 너무 미비했기 때문이다...

 

물론 기술 블로그에 글을 올리는 것이 내가 이해한 것을 글로써 정리하며 이해도를 높이는 목적도 있겠지만 가장 큰 이유는 내가 알게된 지식을 다른 사람들에게 잘 공유하기 위해서이니 요런 상황이 조금 더 아쉽게 다가왔다...

구글 서치 콘솔 추가한 뒤로는 그래도 조금 나아지긴 했지만 많은 수치는 아니다.

 

그래서 종윤님은 어떻게 SEO 작업을 하셨는지 더욱 궁금해졌다. 

(내용적인 부분은 이미 종윤님이 블로그에 잘 정리해주셔서 확인해보시면 좋을 것 같습니다! 저는 이해한 것 기반으로 요약해볼게요...!)

 

 

SEO는 검색 엔진 최적화로, 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정이다.

 

여기서 개선할 수 있는 부분을 3가지로 나눠서 말씀해주셨다.

 

• 온 페이지 SEO : 콘텐츠의 구성요소를 개선
  • 양질의 콘텐츠 제작
    • 직접 경험
    • 주제에 대한 이해도가 높은가
    • 작성자가 얼마나 저명한가
    • 위 모든 것을 종합해서 믿을 수 있는가
  • 분량은 콘텐츠 품질에 직접적인 영향을 주진 않음
  • 다루고자 하는 주제를 나의 관점에서 바라본 콘텐츠로 제작
  • HTML 태그 수정 (타이틀 태그 / 메타 태그 / OG 태그 - 미리보기)
• 테크니컬 SEO : 크롤링이 잘되게 하고 인덱스를 생성하기까지 과정 개선
  • 사이트 맵 (웹사이트 구조가 담긴 XML 파일) → 티스토리는 기본 제공
  • RSS : 최근 발행한 컨텐츠 정보 → 티스토리도 제공
  • 라이트하우스 점수 향상
  • 구글 서치 콘솔에 등록
  • 네이버 서치 어드바이저에 등록
• 오프 페이지 SEO
  • 백링크(다른 사람들이 내 글의 링크를 자신의 콘텐츠에 넣었을 때)가 많을수록 평판이 좋다고 평가 (SNS에 올리는 것이 효과 좋음)
  • 기술 블로그는 평일 오전 9~10시 오후 2~4시에 가장 트래픽이 많음

 

여기서 가장 효과가 좋았다고 느끼시는 부분은 SNS 공유라고 하셨다!

역시 초기에는 다른 사람들이 많이 볼 수 있도록 직접 홍보를 하는 방법이 효과적인 것 같다. 

 

사이트맵 / RSS는 일단 기본적으로 제공되는 기능을 사용하고 있고 구글 서치 콘솔과 네이버 서치 어드바이저의 경우 이미 등록을 해놔서 요 부분에선 크게 개선할 부분은 많지 않다고 생각이 들었다. 

(사이트맵, RSS는 다시 한 번 점검해보긴 해야겠다)

 

콘텐츠의 양질 향상의 경우 종윤님의 포스팅을 보니 반성하게 되었다.

사실 지금까지의 포스팅은 단순히 특정 정보를 보고 요약 정리를 하는 내용이 많았다 보니 콘텐츠의 질이 약간 떨어지고, 어디서든 볼 수 있는 정보이지 않았나 싶다.

 

앞으로는 이런 부분도 고민하면서 작성을 해봐야겠다. 그리고 부끄럽지만 링크드인에서도 글 작성 후 홍보를 해봐야겠다.

 

2부 네트워킹 + 레크리에이션

오랜만에 카훗으로 퀴즈를 했다 ㅎㅎㅎ

 

진짜 이거 어떻게 아나 싶은 문제들이었는데 다른 팀들은 엄청 잘 맞추신... ㅋㅋㅋ 대단하시다는 생각이 들었다. 

(스티브잡스의 생일은? 약간 이런 느낌의 문제들이었다 ㅎㅎㅎ 오히려 이런 문제라 부담이 적어서 좋았다!)

 

레크리에이션이 끝나고는 네트워킹을 진행했다. 

내가 속했던 팀에는 따로 iOS 분은 안 계셔서 그 부분은 아주 조금 아쉬었지만 그래도 평소에 이야기를 잘 해보지 못했던 백엔드, Flutter, 프론트엔드 개발자 분들과 이야기를 해볼 수 있어서 좋았다. 

 

처음에 다짜고짜 이야기하려면 어렵기 때문에 주제도 개인별로 제공해주셨다 👍

 

우리 조에선 아래 주제로 이야기했다.

• 좋은 커리어란
• 좋은 코드란
• 주 100시간 연봉 50억, 주 20시간 연봉 5천

좋은 커리어는 사실 아직 잘 모르겠다... 나도 아직 만 1년 반 정도된 주니어 그 자체이고...

나는 성장 관점에서 커리어를 보고 있었는데 다들 나보다 연차도 높으시고, 오히려 다른 분야의 개발을 병행하는 커리어 등을 고민하고 계신 분들도 있었다. 

 

커리어를 너무 편협한 시각으로 보고 있었나라는 생각도 들었지만, 현재 내 연차에선 지금의 고민이 맞는게 아닐까 싶기도 했다.

아직 iOS 내에서도 못 해본 것들이 너무 많고 공부할 것도 아직 많기 때문에...

 

좋은 코드의 경우 하고 계신 분야와는 다르게 대부분 단순하고 가독성이 좋은 코드로 의견이 모아졌다. 

(과도한 추상화는 오히려 독이 될 수도 있는 이야기도 나눴다)

그리고 돈이 되는 코드가 좋은 코드라는 말씀도 해주셨다. 

 

주 100시간 연봉 50억, 주 20시간 연봉 5천, 이 주제는 앞선 주제보다는 좀 더 가벼운 주제였다 ㅎㅎㅎㅎ

나는 주 100시간까지 할 체력은 안된다는 생각에 후자지만... 전자는 폭발적인 성장이 가능할 것 같기도 하다. 물론 바쁘다고 좋은 코드를 잘 짜고 있다는 아니지만 말이다.

 

---

 

iOS 개발자가 아닌 개발자 분들과 이야기를 나눈 것은 회사를 제외하곤 없었는데 좀 더 다양한 관점을 배울 수 있었던 좋은 기회였다. 

 

역시 세상은 넓고 고수는 많다.. ㅎㅎㅎ

 

글또 덕분에 인사이트도 얻고 다른 분들의 생각도 들을 수 있었던 정말 좋은 기회였다.