프론트엔드 개발자들

프론트엔드 개발자들

프론트엔드 개발자들을 위한 커뮤니티 클럽입니다.

공개 178 멤버

가이드라인

["개인 또는 단체, 속한 조직을 비방하는 글을 '금지'합니다.","타인의 글을 공유할 땐 왜 공유하려고 하는지 이유도 함께 적어주면 좋습니다.","\b작성한 글을 공유할 땐 어떤 내용인지 간단하게 요약해주면 좋습니다.","기술 관련 질문을 올릴 땐 '문제 상황', '시도한 방법' 등을 적어서 답변하는 분에게 충분한 정보를 제공해줍니다.","조직 문화 등 비기술 관련 질문을 올릴 땐 정확히 어떤 내용이 궁금한지 '명확'하게 '요약'되어 있으면 좋습니다."]

준프

준프

덕 타이핑(duck typing)에 대해 아시나요?

덕 타이핑에 대해 아시나요? 덕 타이핑은 자바스크립트와 같은 동적 프로그래밍 언어에서 객체의 타입을 결정하는 데 사용하는 방법입니다. 정말 오래전에 덕 타이핑을 활용한 사례를 제외하고 여지껏 개념도 가물가물 했을 정도로 알아도 그만 몰라도 그만인 개념으로 취급됩니다.

하지만 얼마전 웹뷰를 다루다가 덕 타이핑으로 이슈를 해결한 사례가 있었습니다. ES5로 변환하고 난 후에 Map, Set 인스턴스를 순회하지 못하는 문제가 있었고 덕 타이핑을 통해 임시로 해결했습니다.

공부를 하다보면 어떤 개념의 경우엔 활용하기가 어려워 그냥 지나가는 경우가 있는데요, 한 번쯤 이해만 해놓는다면 나중에 정말 희소하더라도 활용하는 기회가 생기기 마련인 것 같습니다.

관련해서 설명하려다보니 잘 정리된 아티클을 찾기가 어려웠는데, 이번 글에선 이렇게 저렇게 찾아본 글을 공유드립니다 :)

이 글들은 자바스크립트 입장에서, 특히 iterator를 예시로 덕타이핑을 보여줍니다. 그리고 나머지 하나는 오리를 예시로 쉽게 설명하는 덕타이핑입니다.

0
0
준프

준프

리파지토리 패턴에 대해 아시나요?

리파지토리 패턴(Repository Pattern)에 대해 아시나요? 이번에 소개해드릴 두 개의 글은 리파지토리 패턴에 대한 글입니다.

먼저 첫 번째 글을 소개합니다.

리파지토리 패턴은 데이터를 영속적으로 유지해주는 문제를 추상화합니다.

“The Repository pattern is an abstraction over persistent storage. It hides the boring details of data access by pretending that all of our data is in memory.” (Architecture Patterns with Python, chapter 2)

예를 들어, 아래와 같은 API 요청이 있을 때,

fetch('/store', {
  // ...
  body: JSON.stringify({
    // ... data
  }),
});

아래와 같이 추상화합니다.

// 정의
const StoreRepository = {
  create(...data) {
    fetch('/store', {
      // ...
      body: JSON.stringify({
        // ... data
      }),
    });
  }
};

// 호출부
// fetch를 직접 호출하는 대신 메서드 호출
StoreRepository.create({ ... });

추상화를 했다는 건, 같은 인터페이스를 가진 다른 구현체로 바꿀 수 있다는 걸 의미하기도 합니다. 그리고 추상화 전과 달리 세부 구현을 숨기는 캡슐화도 되기 때문에 변경이 발생했을 때 대응이 수월합니다. 물론 구현체가 중복해서 존재하는 경우 중복 제거도 가능합니다.

다른 구현체로 바꿀 수 있다는 건 테스트도 전과 달리 더 수월하게 할 수 있다는 걸 의미합니다. 그래서 아래와 같은 장점이 있습니다.

  • 도메인 로직(비지니스 로직)과 데이터 영속 로직 분리

  • 코드를 테스트하는 게 수월해집니다.

  • 데이터를 다루는 로직을 교체할 수 있습니다.

    • 예를 들어, API 호출이 아닌 쿠키, localstorage 등의 방법으로 바꾸기 수월합니다.

하지만 추상화를 통해 데이터 계층이 추가되면

  • 데이터를 사용하는 곳과 리파지토리 계층 간의 데이터 구조 매핑이 필요합니다. 즉, 장점으로 가져온 유지보수성 향상을 깎아먹게 됩니다. 그래서 결국 득인지 실인지는 따져봐야겠습니다.

  • 계층이 늘어나면 코드를 살펴볼 때 복잡성이 올라갑니다.

프론트엔드 개발을 하면서 리파지토리 패턴은 익숙하지 않을 수 있습니다. 그리고 당장 필요하지 않을 수도 있습니다. 하지만 복잡한 애플리케이션을 개발 해야 할 일이 생길 때, API 호출에 사용하는 라이브러리를 교체해야 할 때 등 리파지토리 패턴이 필요한 순간에 생각이 난다면 충분하지 않을까 합니다.

프론트엔드에서 리파지토리 패턴을 사용하는 것, API 요청을 추상화 하는 것과 관련해선 제가 쓴 글도 있으니 필요하시면 참고하셔도 좋을 거 같습니다.

그리고 마지막으로 소개해드리는 글은 '리파지토리는 안티 패턴인가?'라는 주제의 글입니다. 글의 분량도 그렇고 내용도 읽기 수월하진 않을 정도로 어렵기도 합니다. 하지만 기존에 잘 활용되고 있는 패턴에 대해 다시 한 번 돌아보게 하는 글은 옳고 그름을 떠나 한 번쯤 읽어볼만 하다고 생각합니다.

저도 필요할 때 몇 번은 더 읽어봐야 할 거 같습니다 :)

리파지토리 패턴과 무관하지만 이 글에서 의미있는 문장이 있는거 같아 인용합니다.

Developers are really stubborn people. To become a software engineer, you should have a mindset of “everything is possible” guy. When something is not working the way we want it, we would just put more effort into it. The more effort we invest, the harder it is to let it go.

You know, how they said: habits prevent any progress. (습관은 진전(또는 개선)을 방해합니다.)


0
0
준프

준프

어떻게 더 좋은 리액트 컴포넌트를 만들까요? - 확장 가능성 그리고 재사용성

글 소개

컴포넌트를 잘 만드는 방법은 너무도 많습니다. 그래서 그런지 언제부턴가 컴포넌트를 잘 만드는 방법이라면 의심부터 먼저 하게 됩니다.

하지만 이번에 소개해드릴 글은 아주 기본적인 것 부터 점검해보는 기회를 제공한다고 생각합니다.

그럼 천천히 살펴보겠습니다.

Bit을 사용하여 기본 UI 컴포넌트를 만들기

블로그를 보다보면 사용하는 기술에 대한 홍보(?)가 많아서 건너뛰는 편입니다. 그럼에도 이렇게 소개해드리는 이유는, Bit을 사용하는 이유에 대해선 짚어볼만 하다고 생각하기 때문입니다.

혹시 코드를 작성하면서, 특히 컴포넌트를 만들면서 다이어그램을 작성해보시나요?

videocomponent.png

(저도 복잡해질 가능성이 있는 그리고 많은 기능을 갖고 있는 컴포넌트는 위 이미지처럼 다이어그램을 그려보며 점검하곤 합니다.)

컴포넌트는 의존관계를 파악하기 수월하고 컴포넌트의 수가 많아지면 의존성 때문에 유지보수성이 떨어질 수 있기 때문에, 한 번 쯤은 컴포넌트 의존성 다이어그램을 그려보면 많은 도움이 됩니다. 컴포넌트 숲속을 헤매다가 숲을 보기 시작하면 얼마나 헤매고 다녔는지 확인할 수 있고, 개선 지점도 찾을 수 있습니다.

저자도 의존성 그래프를 그려보는 게 많은 도움이 된다고 어필하고 있습니다.

With Bit, you can use its dependency graph to understand how your components interact. It illustrates the interconnectedness of components.

This dependency graph is particularly beneficial in large-scale projects involving multiple teams. It aids in efficient change management, guaranteeing that updates within a scope are in sync and align with the broader organizational standards.

컴포넌트 API 노출하기

아마 많은 프론트엔드 개발자에게 API와 인터페이스는 백엔드 개발자의 전유물처럼 느껴질텐데요, 이 소주제를 통해 프론트엔드 개발자에게 API와 인터페이스는 어떤 걸 의미하는지 돌아볼 기회가 생깁니다.

내용은 아주 단순합니다. '컴포넌트와 그 컴포넌트의 인터페이스를 노출하라'

전 여기에 하나 더 붙이려고 합니다. '그 밖에 것은 노출할 때 주의하라'

테마 컴포넌트를 활용한 스타일 일관성을 위한 테마

페이지를 만들 땐 테마가 정말 중요합니다. 대부분 서비스의 경우 일정 테마를 갖고 있는데 이걸 일괄로 관리할 수 있어야 합니다.

To maintain a consistent look and feel, base components are designed to be themeable.

커스터마이징과 확장성 향상 시키기

컴포넌트의 커스터마이징과 확장성을 향상 시키는 방법을 공유합니다. 너무 단순하고 모두 아는 방법이지만 효과는 확실합니다. 'className'과 '구조 분해 할당' 사용하기 인데요, 원글을 보시면 단번에 이해할 수 있습니다.

마무리

좋은 말, 도움되는 말은 반복해서 듣고 새겨야하지 않을까 합니다. 이 외에 컴포넌트 분리 기준에 대해 제가 쓴 글도 남기는 걸로 마무리합니다 !

0
2
문지웅

문지웅

Astro로 blog 만들어보기

Astro 공식 문서 및 블로그를 만들었던 경험 등을 토대로, gitbook을 사용해서, Astro로 블로그를 만드는 방법에 대한 튜토리얼을 작성해보았습니다. 추가했으면 하는 내용이 있다면 댓글 남겨 주세요 :)

0
2
조성원

조성원

Next.js 14 버전과 함께 공개된 공식 튜토리얼 따라하기

저의 Disquiet에서의 첫 글이네요 🎉

제목 그대로 튜토리얼을 따라 학습해본 매우 짧은 후기 글입니다.

CleanShot 2023-12-08 at 23.21.43@2x.png

우선 웹을 개발할 때 눈에 보이는 UI 제작 외에도

  1. SEO를 위한 Metadata

  2. 스트리밍

  3. 리액트의 서버 컴포넌트와 훅

  4. Next.js가 이미지나 폰트 등을 어떻게 최적화 했는지

  5. 사용자 인증에 사용되는 Next Auth 라이브러리

  6. CSR인 리액트와는 어떻게 다른지

  7. 그 외에 스켈레톤같은 UX 향상을 위한 UI 제작 등

여러가지 전에 알지 못했던 것들을 학습할 수 있어서 좋았습니다.

웹에 대한 전반적인 내용을 다루고있어서 큰 틀을 잡는데 도움이 많이 되었어요.

내용들을 딥하게 다루진 않지만 가볍게 한번 따라해볼만한 튜토리얼이라고 생각합니다!

제가 공부하면서 번역한 튜토리얼 링크를 공유드리면서 글을 마무리하려고 합니다.

원래 개인적으로 학습하려던 목적으로 만든 리포지토리입니다.

ChatGPT의 도움을 받아 빠르게 번역 후 수정한 글들이어서 번역이 매끄럽지 않을 수 있습니다.

그럼에도 다른분들에게 도움이될까 싶어 공유해봅니다 :)

+++

React Foundations 부분이 그새 업데이트됐네요 😂

공식 홈페이지의 내용과 꽤 다를 수 있으니 참고 부탁드립니다.

Github: (PR 환영합니다!)

1
4
Jiheon Choi

Jiheon Choi

JavaScript Async 함수의 선언은 Promise를 반환하지 않습니다.

우리는 자바스크립트에서 일반적으로 잘 알려진 'async/await'를 사용해서 비동기 처리를 구현하게 됩니다. 이렇게 구현하는 과정에서 단순하게 'async 함수는 Promise 객체를 반환한다'라고 이해하는 것도 좋지만, async 함수를 정의하는 것은 Promise 객체를 반환하지 않습니다. 이것에 대해 자세히 글을 정리해 보았습니다.


요약: async 함수를 정의하면 'AsyncFunction' 객체의 인스턴스가 생성됩니다.

이렇게 정의된 함수를 실행할 때, 'AsyncFunction' 인스턴스는 함수의 결과를 평가하여 Promise 객체를 반환합니다.

0
1
준프

준프

도커 네트워크 - 브릿지에 대해 아시나요?

근래 특정 이슈를 해결하기 위해 도커를 살펴보는 중입니다. 특히 컨테이너 간에 데이터를 주고받기 위해선 네트워크에 대한 이해가 필수인데요, 성격상 당장 문제를 해결하더라도 원하는 수준까지 이해하지 못하면 근질근질해서 잘 못 참곤 합니다.

특히 최근 브릿지의 동작에 대해 이런저런 글을 찾아봤지만, 초보자인 제게는 뭔가 부족하다는 느낌을 많이 받았습니다. 그러던 중 정말 잘 설명해주는 글을 소개합니다.

이 글은 브릿지 네트워크 드라이버에 대해 설명하고 있습니다. 브릿지 네트워크 드라이버는 무엇인지, 언제 사용하면 좋은지 그리고 정말 간단한 예제도 있습니다. 특히 시리즈로 나와있는 글들도 도커 네트워크의 개념을 가볍게 이해하기에 정말 좋은 것 같습니다. 이 글들을 토대로 조금 더 심화된 내용을 읽는 것도 좋겠다는 생각이 들었습니다.

도커 네트워크를 이해하는데 어려움이 있으시다면 한 번 참고해보시는 걸 추천드립니다 :)

0
0
준프

준프

리액트에서 Proxy 디자인 패턴 사용하기

Proxy 패턴에 대해 아시나요? Proxy는 메세지를 주고받는 두 대상 사이에 위치해서 여러가지 역할을 합니다. Javascript의 Proxy는 대상 객체의 앞에 위치하여 객체에 대한 외부 요청을 제어합니다.

Proxy 객체를 사용하면 한 객체에 대한 기본 작업을 가로채고 재정의하는 프록시를 만들 수 있습니다.

이번에 소개해드리는 글은 이러한 Proxy를 어떻게 활용할 수 있는지 공유하고 있습니다.

먼저 Proxy를 통해 얻을 수 있는 이점은 아래와 같다고 소개합니다.

  • 데이터 캐싱

  • 보안 개선

  • 자원 소모 감소(게으른 로딩, 캐싱, 접근 제한 등)

  • 네트워크 최적화

  • 동시성 제어

그리고 각 이점에 대한 예시를 소개합니다.

  • API를 통해 가져온 사용자 데이터에 비밀번호(민감정보)가 포함되어 있다면, 서비스를 사용하고 있는 사용자가 어드민이 아니라면 접근해서 수정할 수 없도록 합니다.

    • 이 경우 말 그대로 '보안'이 아니라 데이터에 접근해서 수정하거나 하는 등의 동작을 불가능하게 만드는 '접근 제어'가 더 적절할 것 같습니다.

  • API를 통해 데이터를 이미 가져왔다면 다음에 데이터를 가져올 땐 API를 호출하지 않고 기존 데이터를 제공합니다.

  • 그리고 구체적이진 않지만 다른 사용예를 소개합니다.

    • 추상화 및 코드 재사용

    • 데이터 검증 및 sanitization

    • 퍼포먼스 모니터링 및 최적화

Proxy와 관련해 잘 몰랐는데, 이 글을 이해하기 위해 Proxy에 대해 공부하게 된 계기가 되었습니다. 관련해서 많은 도움이 된 글을 여기에 더해 소개합니다.

0
0
준프

준프

모듈 페더레이션 - 의존성을 공유하기 전 한 번 더 생각하세요.

이번에 소개해드릴 글은 모듈 페더레이션을 사용할 때 의존성에 대해 고민해봐야 한다는 내용의 글입니다.

웹 페이지가 그리고 서비스의 규모가 점점 커지면서 서버 뿐만 아니라 프론트 역시 마이크로서비스를 채택하는 조직이 점점 많아지고 있습니다.

이 글에서 소개하는 것처럼 한 페이지의 컨텐츠 뿐만 아니라 모든 서비스에서 공유하여 사용하는 요소들 역시 모듈 페더레이션을 통해 런타임에 가져와서 사용하곤 합니다.

그렇게 모듈을 공유할 때 의존성 역시 고려해야하는데요, 이 글에선 다소 극단적이긴 하지만 거대한 의존성을 두 애플리케이션이 공유할 때 어떤 점을 주의해야 할지 경험을 공유합니다.

요약하자면

웹팩이 트리 셰이킹을 할 수 있도록 우리가 도와줘야 한다.

입니다. 웹팩은 모듈 페더레이션을 통해 공유하려는 모듈 또는 의존성의 어떤 부분이 어떻게 사용될지 알 수 없기 때문에 트리 셰이킹을 하지 않고 그대로(글에선 node_modules에 있는 그대로) 공유하게 됩니다.

해결 방법은 간단하지만, 모두에게 적용할 수 없다는 단서도 달아 놓고 있습니다.

이번을 기회로 모듈 페더레이션, 트리 셰이킹 등의 개념에 대해 한 번 더 짚고 넘어가면 좋을거 같습니다 :)

0
0
준프

준프

소프트웨어 개발에서 삼체문제

삼체문제에 대해 아시나요? 역학에서 한 물체 또는 두 물체의 움직임을 설명하는 건 가능하지만 단 세 개로 물체의 갯수만 늘어나도 그들의 움직임을 설명하는 건 불가능해집니다.

소프트웨어 개발도 비슷한데요, 한 기능, 두 기능 등 초기 기능 개발은 수월한 방면 기능이 늘어나다보면 각 기능의 상호작용을 그려보는 건 점점 더 어려워집니다.

이번에 소개해드리는 글은 소프트웨어 개발에서 왜 결합도가 중요한지, 문제를 작게 쪼개서 해결하는 방법론이 왜 중요한지 삼체문제를 비유로 설명하는 글입니다. 이런 비유는 어렵게 느껴지는 개념을 이해하기 쉽게 만드는 효과를 가진 것 같습니다. 그리고 실제로 너무 잘 성명해주는 거 같아요 !

저 역시 프론트엔드 개발을 하다보니 조금만 시간이 지나도 문제가 지나치게 복잡해지는 경우를 많이 봐왔습니다. 그래서 어떻게 하면 프론트엔드 사이드의 문제를 단순화할 수 있을지 계속해서 고민하고 있습니다. 또 ! 한 문장이긴 하지만 삼체문제와 관련된 문장도 있답니다 :)

이렇게 되면 기능 간에 결합이 강하게 발생해서 수정이 쉽지않습니다. 이건 마치 삼체문제와 비슷해서 서로 상호작용하는 기능이 많아지는 것보다 문제의 복잡성이 더 빨리 어려워진다는 것을 의미합니다.

관련해서 제가 쓴 글도 참고해보시면 좋을거 같아요 :)

0
0
Jeff Gu Kang

Jeff Gu Kang

서비스의 소셜 로그인을 붙이실때 이것만은 조심하세요.

image.png

기존에 페이스북 로그인을 제거하는 결정을 내린 기업들이 있습니다. 꼭 필요하지 않다면 소셜로그인 사용시 페이스북 로그인 제외를 고려해보시길 바랍니다.

현재 서비스에 소셜 로그인을 붙이려면 몇가지 옵션이 있습니다.

일반적으로 붙이는 소셜 로그인은

  • 카카오톡(한국)

  • 구글

  • 페이스북

  • 라인

  • 애플

이 있고 여기서 iOS로 서비스 출시를 원하신다면 애플 로그인은 필수로 붙이셔야만 심사 통과가 됩니다.

다만 페이스북 로그인은 다음과 같은 이유로 사용을 할지 잘 고민해야 합니다.

  • 갑작스러운 정책 위반 경고

  • 짧은 경고 주기

  • 위의 이유로 인한 갑작스러운 API 사용 제한(로그인 사용 불가)

  • 거의 없다시피한 한국 지원

썸원 역시 똑같은 상황을 겪어 현재 유저들에게 불편을 야기하고 있습니다. 찾아보니 국내에서 비슷한 류의 피해를 당한 유명 서비스는

  • 밀리의 서재

  • 원티드

정도를 찾을 수 있었고

둘 모두 페이스북 로그인을 제거하는 결정을 내렸습니다.

image.png

출처: 원티드

image.png

출처: 밀리의서재

로그인 수단을 변경해주는 작업은 유저 수에 따라 엄청난 공수를 필요로 합니다. 일이 발생하기 전에 방지하는 것도 좋은 방법이 될 수 있으니 위 정보를 바탕으로 모두 해당이슈는 겪지 않으시기를 바래요.


포스트 아포칼립스에 던져져도 굴하지 않고 앞으로 나아가실 수 있으신가요? 서로의 발목을 잡는것이 아닌, 서로의 추진력이 되어 주는 팀원들과 함께 로켓처럼 성장하고 싶으신가요? 전 세계의 인류를 상대로 인간의 관계와 가치에 대한 중요성을 전파하고 싶으신가요?

당신이 바로 그 사람이라면 주저없이 모니모니의 문들 두드리시거나 커피챗을 요청해주세요.

1
1
문지웅

문지웅

이런 디자인은 어떤가요...?

여러분은 어떤 디자인을 선호하시나요???

포트폴리오의 UI를 수정해보았는데요

여러분의 의견이 궁금해서 글 남겨봐요 😎

기존 디자인은 https://woongsnote-portfolio.vercel.app 에서 확인하실 수 있고,

신규 디자인은 https://portfolio-git-dev-woongsnote.vercel.app/ 에서 확인 가능해요 :)

많은 의견 부탁드려요.

감사합니다.

0
7
준프

준프

서프라이즈 없는 안정적인 동료가 되기

오늘은 함께 일하는 사람으로서 어떤 사람이 '안정적'인 사람인지 공유하고 관련 글을 소개하려고 합니다. '나는 다음 번에는 "안정적인 엔지니어"를 고용하라고 HR에 구체적으로 말했습니다.'라는 제목을 가진 이 글은 사실 '엔지니어'라는 단어를 넣긴 했지만 직무 관계 없이 어떤 사람이 '안정적'인 사람인지 소개하고 있습니다.

몇몇 케이스는 동의가 안 되기도 하지만 몇몇 경우는 여러 글에서도 소개하는 만큼 다시 상기하기에 좋은 글이라고 생각합니다.

아래는 이 글에서 소개하는 안정적인 엔지니어는 어떤 사람인지를 요약했습니다.

  1. 아픈 날이 거의 없이 출석하는 사람

  2. 업무의 호불호가 거의 없는 사람

  3. 스스로를 잘 다루는 사람

  4. 긍정적인 사람

그리고 어떻게 안정적인 엔지니어가 되는지 소개하고 있는데요, 방법 중엔 술을 마시는 방법도 있습니다. 물론 다음 날 업무에 영향을 주지 않고, 조금 취하며, 술을 마시는 것 자체에 집중하지 않는 다는 조건이 있지만요.

전 이 글에서 '아픈 날이 거의 없이 출석하는 사람'이라는 주제가 가장 눈에 띄었습니다. 어딘가 아파서 결근을 하는 경우 프로젝트 진행에 영향을 줄 수 있다는 것인데요, 여기엔 두 가지 핵심이 있습니다.

  1. 건강은 프로젝트를 예정대로 진행하는 데 가장 기본이다.

  2. 갑작스런 결근은 프로젝트에 영향을 준다.

그리고 '갑작스런'은 꼭 건강이 아니더라도 아주 중요한 주제입니다. 프로젝트를 관리하는 관리자들, 그리고 함께하는 동료, 작업물을 기다리는 사람 모두 일정 대부분이 예정대로 진행되는 걸 기대합니다. 하지만 '갑작스런' 이벤트는 '나를 제외한 모두'에게 큰 스트레스를 안겨줍니다.

The fewer sudden breaks, the better.

이와 관련해 우미영님도 저서 <나를 믿고 일한다는 것>에서 서프라이즈를 줄이고 신뢰를 얻는 방법에 대해 소개하고 있습니다.

내가 가장 두려워하는 직원은 업무 지시에 아무런 토를 달지 않고 늘 '네'라고 대답하는 사람이다. 이들은 십중팔구 내가 의도한 것과 다른 결과물을 가지고 온다. 혼자 열심히 한다고는 하지만 마감 기한에 임박해서 수정할 시간도 주지 않고 결과물을 들이미는 직원은 가끔씩 나를 아연실색하게 한다. 의욕 자체를 문제 삼을 수는 없지만 회사는 혼자가 아니라 함께 일하는 곳이다. 상사의 입장에서는 피곤하기는 해도 질문을 많이 하고 이해되지 않는 것은 따져 묻는 직원이 오히려 고맙다. 그들은 나와 함께 중간중간 체크해가면서 일하기 때문에 엉뚱한 곳으로 빠지지도 않고 대체로 결과물도 잘 만들어낸다.

대부분의 상사들은 '서프라이즈'를 싫어한다. 작든 크든 조직을 책임지고 있는 사람에게 예측 불가 또는 불확실성만큼 두려운 것이 없다. 그래서 일의 진행 상황을 상사와 공유하는 것이 중요하다.

리스크와 성과를 효과적으로 관리할 수 있도록 도와주는 직원들이 믿음직스러울 수밖에 없다.

일하는 방법을 한 번 돌아보고 얼마나 안정적으로 작업을 진행했는지, 난 어떤 엔지니어인지 한 번 돌아보면 좋을 것 같습니다.

0
0
Jeff Gu Kang

Jeff Gu Kang

DAU 30만까지 개발자 한명이면 충분해요.

image.png

1년동안 북과 장구를 혼자서만 쳤다.

소프트웨어 기반의 스타트업을 시작하게 된다면 대부분

- 리소스 부족

- 시간 부족

- 확신할 수 없는 아이템

의 3박자를 고루 가지고 시작한다.

그나마 나은 상황이라면 자체적으로 결과물을 만들어 낼 수 있는 구성원들로 팀이 구성되어 있는 상황이다. 디자인과 개발 을 통해 일단 MVP을 만들고 그것을 기반으로 다음 단계를 고민하게 될 것이다. 모니모니는 디자이너와 개발자로 초기 팀원이 구성되어 있었으므로 외부 인력 없이도 MVP 제작이 가능한 상태였다.

어찌되었든 개발자가 유무와 관계없이 자원이 충분하지 않은 스타트업이라면 최대한 효율적인 방법으로 빠르게 개발을 진행해야 할텐데 이 때 몇가지 고려해야하는 점이 있다. 이 글에서는 다른 포지션은 제외하고 단순 개발 전략에 대한 내용만을 다룬다.

  • 백엔드, 프론트엔드 등 개발 언어(Programing Language) 통일

초기 스타트업은 백엔드, 프론트엔드의 완성도보다는 속도가 중요한 경우가 많다. 언어를 학습하는데 시간을 쓰지 말고 구현에 초점을 둬야하므로 언어는 하나로 통일하는 것이 좋은 방법이다. 개발 인원이 변경될 경우에도 비교적 쉽게 대응할 수 있다.

  • 모바일 앱 개발시 크로스 플랫폼 고려

위와 비슷한 맥락으로, iOS, Android를 별도로 개발하는 것 보다 크로스 플랫폼 프레임워크를 이용하여 한번에 개발하는 것이 좋다. 특정 서비스들은 웹뷰를 사용하여 웹페이지를 모바일 앱에서 불러다 사용하는 방법을 선택하기도 한다. 이것 역시 iOS, Android 각각의 언어로 개발하는 것을 지양하고, 한번에 여러 플랫폼을 개발하여 시간과 유지보수 면에서 이득을 얻을 수 있다.

  • 대중적인 클라우드 서비스 사용

초기에는 비용적으로 큰 차이가 나지 않으므로 어느정도 인지도가 있는 클라우드 서비스를 사용하여 인프라를 구축하는 것이 좋다. 인프라 이전은 리소스가 상당히 들어가는 작업이고 확장성이나 차후 채용에 있어 이점을 가져갈 수 있다.

  • 채용이 용이해야함

해당 기술 스텍이 대중적이거나 배우기 쉬워야 차후 인재 채용이 용이하다. 국내에서는 코틀린, 자바, 자바스크립트(타입스크립트), 파이썬 등이 대중적인 프로그래밍 언어로 생각된다.

썸원을 만들 때 내가 했던 선택은 다음과 같다.

- 프로그래밍 언어: TypeScript

- Backend 개발: Node.js 환경에서의 Express 사용 (TypeScript 언어)

- Mobile Client 개발: Node.js 환경에서의 React Native(iOS, Android 크로스 플랫폼 동시 개발, TypeScript 언어)

- Cloud Service: AWS(제일 유명한게 최고)

여기에서 React Native의 경우는 나온지 얼마되지 않았던 상황이라 채용이 용이한 상황은 아니였지만, 대중적인 JavaScript 언어 기반이기도 하였고 기존에 좋은 경험이 있었던 터라 선택을 하게 되었다.

사실 첫화면은 프로토타입에서 크게 변하지 않았다.

이로서 TypeScript 언어만을 사용하여 약 2달만에 서비스를 완성하여 빠르게 초기 모델 출시가 가능하였고 약 30만명의 DAU까지 개발자 한명으로 iOS, Android, API 서버, 인프라 모두 커버하며 버그 수정 및 업데이트를 지속할 수 있었다.

지금은 크로스 플랫폼 개발 프레임워크 중 React Native(TypeScript 언어)와 Flutter(Kotlin 언어)가 유명한대 초기 스타트업이라면 iOS, Android를 별도로 개발하는 것 보다 해당 프레임워크 중 하나를 사용하는 것이 여러가지 이점을 가져갈 수 있을 것이다.

p.s 개발자 한명은 사실 충분하지 않습니다. 최소한의 리소스를 사용했던 극초반 전략으로 생각해주세요.


포스트 아포칼립스에 던져져도 굴하지 않고 앞으로 나아가실 수 있으신가요? 서로의 발목을 잡는것이 아닌, 서로의 추진력이 되어 주는 팀원들과 함께 로켓처럼 성장하고 싶으신가요? 전 세계의 인류를 상대로 인간의 관계와 가치에 대한 중요성을 전파하고 싶으신가요?

당신이 바로 그 사람이라면 주저없이 모니모니의 문들 두드리시거나 커피챗을 요청해주세요.

1
7
문지웅

문지웅

Astro 생각보다 매력적이네 :)

기술 블로그와 관련해서 검색하던 중, 우연히 Astro에 대해 알게 되었다.

Contentlayer가 몇 달쨰, 업데이트가 없어, 고민하던 찰나에 알게 된 프레임워크였고, Next.js 보다 성능적으로 우수하다는 홈페이지의 내용이 관심을 끌어서 블로그에 적용해보게 되었다.

기존 Next.js + ContentLayer 때보다, 게시글을 추가했음에도 빌드 시간은 줄어들었고, 사이트도 더 빠릿빠릿해졌다는 느낌을 받았다.

공식 홈페이지도 잘되어있고, Integration 등으로 기존 React 코드도 사용이 가능한 점 등 장점이 많다고 생각이 들어서, 블로그는 이 프레임워크를 기반으로 계속 사용하면서 개선하나가려고 한다.

아직 100프로 전환된 상태는 아니라, 일부 기능들은 수정 중인 상황이지만 상당히 매력적인 프레임워크로 생각되서 글로 남긴다. :)

구현된 블로그 미리보기 ▼

www.woongsnote.dev_ (5).png

기술 블로그

개발 관련 학습한 지식을 공유하기 위해 직접 구현한 블로그

0
1
문지웅

문지웅

ASTRO..?

기술 블로그와 관련해서 검색하던 중. Astro 라는 프레임워크를 알게 되었습니다. 기존에 next.js 로 구현했던 블로그를 해당 프레임워크로 전환 중입니다 😎

혹시 이 프레임워크 써 보신 분 계신가요 ~~???

0
2
준프

준프

데스크탑 스크린 같은 건 없습니다. - 접근성

웹 페이지를 만들다보면 디자이너와 함께 아래와 같이 페이지를 쪼개곤 합니다.

/* Extra small devices (phones, 600px and down) */
@media only screen and (max-width: 600px) {...}

/* Small devices (portrait tablets and large phones, 600px and up) */
@media only screen and (min-width: 600px) {...}

/* Medium devices (landscape tablets, 768px and up) */
@media only screen and (min-width: 768px) {...}

/* Large devices (laptops/desktops, 992px and up) */
@media only screen and (min-width: 992px) {...}

/* Extra large devices (large laptops and desktops, 1200px and up) */
@media only screen and (min-width: 1200px) {...}

(출처: Typical Device Breakpoints)

이 방법은 정말 편하고 유용합니다. 페이지의 요소들을 특정 스크린에 맞춰 몇 가지만 고려하면 되기 때문입니다. 이번에 소개하는 글은 이런 브레이크 포인트, 즉 중단점은 존재하지 않는다는 걸 말합니다. 왜냐하면 같은 스크린 사이즈더라도 폰트사이즈를 키우거나 모바일에서 줌인 또는 줌아웃을 하기 때문입니다. (실제로 제가 만난 몇몇 기획자는 큰 폰트로 보기위해 항상 200%정도 폰트를 키워서 보곤 했습니다.)

이 글에선 사용자의 접근성을 개선하기 위해선 어떻게 하면 좋을지 소개하고 있습니다.

  1. 고정된 px을 사용하는 것보다 em, rem 등을 사용하기

  2. flexbox를 마스터하기

  3. 스크린 사이즈보다 컨텐츠의 크기를 기반으로 media query 작성하기

등 입니다.

그리고 왜 이런 '좋은 방법'을 지키기 어려운지도 소개하고 있습니다. (원글 살펴보기!)

사실 접근성을 개선하는 이러한 방법은 자주는 아니더라도 종종 듣곤 합니다. 하지만 이 글에서 말하는 것처럼 지키기 정말 어렵습니다. 그럼에도 지킬 수 있도록 노력해야 하고 방법은 찾아봐야 한다고 생각합니다. 이 글에서 인상 깊었던 문장이 있어서 소개합니다.

The point is this, though: people do things you wouldn’t expect for all kinds of reasons. It’s not just about “accessibility” and “people with disabilities”. It’s high quality craftsmanship if your stuff just works™️.
(사람들은 온갖 이유로 기대하지 않는 일을 합니다. 이건 단지 '접근성'과 '장애인'에 관한 것이 아닙니다. 당신의 물건이 제대로 작동한다면 그것은 고품질의 장인정신입니다™️.)

그리고 접근성과 관련해 한 권의 책을 소개해드리려고 합니다. '인클루시브 디자인 패턴 접근성 있는 웹디자인하기 - 헤이던 피커링'은 접근성에 대해 소개하면서 굳이 '불편한 사람'을 강조하지 않습니다. 오히려 너무나도 현실적으로 '고객을 놓친다'는 관점을 강조합니다. 그리고 접근성을 고려하고 개선하는 좋은 방법들을 소개합니다. 또한 여전히 유효합니다 !

사용자가 커스텀하여 사용하는 스타일을 크롬에서 테스트해볼 수 있도록 하는 확장 프로그램도 소개하고 있습니다.

그리고 px을 rem으로 변환해주는 패키지도 소개합니다.

0
0
Jeff Gu Kang

Jeff Gu Kang

님아, 그 스타트업을 가지마오.

1675755583141899167669.jpg

찌들어야만 하는 초기 스타트업에 낭만은 있을지언정 이런 상큼함은 없다.


대기업과 공기업보다 스타트업에서 일을 하는 것을 선호하는 사람들이 있다. 높은 성장 가능성과 스타트업만의 문화를 매력적으로 느끼기 때문일 것이다. 나 또한 그런 사람이었고, 지금도 스타트업의 역동적인 생태계를 몹시 사랑하고 있다.

나는 10년 이상 스타트업에서의 실패, 좌절과 정신적인 괴로움, 쾌감 등등을 모두 직접 혹은 간접적으로 겪어보았다. 결실은 달콤할 수도(아닐 수도) 있지만 과정은 모두 쉽지 않다는 것이 명확한 사실이며 주변 지인들 또한 스타트업에 몸담고 있고 고생했던 사람들 또한 많은데, 굳이 스타트업이라는 힘든 길을 계속해서 선택한다는 것은 뭔가 그것만이 가지고 있는 매력이 있는 것일까?

스타트업에서 신입, 멘티, 멘토, 사수의 역할을 모두 경험하고 현재 100만 명의 DAU를 보유한 스타트업 운영을 하는 처지에서 지금 만약 초기 스타트업을 가게 된다면 고려할 것들을 다음과 같다. 물론 굉장히 주관적인 생각이며 다양한 상황과 요인에 의해 여러 가지가 바뀔 수 있다는 것을 염두에 두길 바란다.

초기 스타트업의 경우 내가 고려할 것들 (5명 미만)

1. 대표와 창업자

초기 스타트업은 당연히 창업자들의 역량에 따라 모든 것이 결정된다고 해도 과언이 아니다. 생각하고 있는 창업 분야에서 실전 경험이 충분하거나 엑싯 경험이 있는 대표라면 이번 스타트업도 잘 될 가능성이 상당히 높을 것이다. 물론 투자도 비교적 쉽게 받을 수 있다.

2. 사수

성장을 기대하고 가는 것이라면 사수가 있는 것이 필수이다. 삽질을 줄이고 빠르게 성장하기 위해선 누군가가 앞에서 끌어주거나 좋은 방향을 알려줄 수 있는 것이 정말 큰 도움이 된다. 경험이 부족한 상태로 초기 스타트업에서 초기 멤버로 일한다는 것은 0.5x0.5와 같은 결과를 초래할 수 있다. 물론 본인이 어느 정도 이상의 경험과 실력이 있다면 스스로가 사수가 될 수 있을 것이므로 이 항목은 무시될 수 있을 것이다.

3. 보수(Reward)

초기 스타트업의 경우, 보수와 계약서 없이 일하는 경우를 심심치 않게 볼 수 있다. 보수란 꼭 돈만을 의미하는 것은 아니지만, 희망만으로 아무런 계약도 없이 일을 하는 때는 없어야 할 것이다. 그리고 계약에 관해 계속 흐지부지 얼버무리는 스타트업은 당연히 다른 것들도 잘할 리가 없는 스타트업이므로 빨리 탈출하는 것이 이롭다.

4. 급여가 밀린다…?

초기 스타트업일수록 당연히 자금난에 시달릴 확률이 높다. 그 만큼 급여가 밀리는 일도 발생할 확률이 높은데, 이번달에 회사가 돈이 없다면 당연히 다음달에도 돈이 없을 수 있다고 생각을 해야 한다. 이번달은 사정상 급여를 주지 못하고 투자나 다른 방법을 통해 다음달에 같이 지급된다고 하는 말은 반은 진실일 수 있지만 반은 의도치 않은 거짓말일 수 있다.

간단히 예를 들면 급하게 30만원이 필요한 친구에게 돈을 빌려주고 일주일 뒤에 받기로 한 경우를 생각해보면 된다. 지금 30만원이 없는 친구는 일주일 뒤에도 그 돈이 없어 제때 받지 못할 가능성이 높다.

나 또한 같은 상황을 겪고 시간, 수천만원대의 금전, 정신적인 타격을 받은 경험이 있다.

급여가 밀린다고 해당 스타트업이 무조건 나쁘다는 것은 아니다. 대표나 회사에 대한 믿음, 나의 기여에 대한 믿음, 급여 외의 다른 보상 등 다양한 상황을 고려해서 나의 다음 행보를 결정할 수 있을 것이다. 다만 현실을 직시하고 무얼 할지를 결정해야 예상치 못한 피해를 최소화할 수 있을 것이라는 생각에 이렇게 고려할 사항에 넣게 되었다.

5. 아이템? 글쎄...

나에게 아이템은 오히려 중요하지 않다. 초기 멤버들의 팀워크와 역량만 받쳐준다면 아이템은 피벗이 충분히 가능하다고 생각하고, 실제로 투자하는 기업들도 아이템보다는 구성원을 보는 경우가 많기 때문이다. 에어비엔비를 포함한 세상의 수많은 스타트업들은 피벗을 통해 더 좋은 결과를 낸 경우도 많다. 생존과 성장을 위해서는 아이템에 목을 맬 것이 아니라 세상이 필요로 하는 것을 찾아야 할 것이다. 모니모니 또한 썸원 이전의 프로젝트에서 피벗을 한 케이스이다.

6. 워라벨? 글쎄...

칼퇴, 유연근무, 적은 근무시간, 재택 근무…

초기 스타트업이 이러한 것들을 가져간다면 난 아마 입사하지 않을 것이다. 초기 스타트업에서 제일 중요한 것들은 자본과 시간일 텐데 저러한 것들을 고려한다면 과연 치열한 경쟁에서 이길 수 있을까? 어느 단계에 이르기까지는 빠르게 MVP를 제작하고 지속적인 업데이트를 통해 궁극적으로 사람들이 원하는 것을 만들어내야만 일정한 궤도에 스타트업이 다다를 수 있을 것이다. 초기 스타트업일수록 해야할 것은 많고, 리소스는 모자른 것이 일반적이라는 것을 알아야만 한다. 초기일수록 상큼함 대신 시큼함이 있는 것이 당연하다.

초기 스타트업에게는 시간은 말 그대로 생명줄과 같다. 시간이 흐른다는 것은 자금이 소진될 뿐만 아니라 세상의 니즈가 변하거나 경쟁자들이 먼저 그럴듯한 제품을 선보인다는 의미이다. 이것을 이해하지 못한다면 초기 스타트업보다는 어느정도 궤도에 올라간 안정적인 스타트업들을 찾아보는것이 더 적성에 맞을 수 있다.

top-reasons-startups-fail-v2.png

자금 및 투자 문제, 잘못된 아이템 등으로 인해 스타트업이 실패한다. 이것을 직시하고 있는가? 지금 내가 있는 곳은 어떤가?

물론 지금까지 나열한 항목들은 다양한 요인에 의해 파괴되거나 뒤집힐 수 있다. 또한 여러 가지 리스크에도 불구하고 하이 리스크-하이 리턴 의 포텐셜을 가지고 있는 회사가 초기 스타트업이라고 할 수 있을 것이다. 그 만큼 초기 구성원들의 역할이 중요하고, 한명 한명의 영향력이 성공을 좌우하는 매력을 가지고 있는 것 또한 큰 이점이다.

당연히 선택과 결과에 대한 책임은 모두 자신의 몫이며, 단순 느낌만이 아닌 다양한 것들을 고려하며 좋은 선택을 한다면 어떤 결과가 나오든 많은 성장을 이룰 수 있을 것이다.

시큼한 곳에서 부대이며 하이 리턴을 기대해 볼 것인가?

상큼한 곳에서 우아하게 성장할 것인가?

정답은 없다. 선택만 있을 뿐.

다만 어떤 환경에서든 얻는 것이 있다면 의미 있는 경험이 될 것이다.


--------------

갑작스러운 포스트 아포칼립스 시대에 던져져도 굴하지 않고 앞으로 나아가실 수 있으신가요? 서로의 발목을 잡는것이 아닌, 서로의 추진력이 되어 주는 팀원들과 함께 로켓처럼 성장하고 싶으신가요? 전 세계의 인류를 상대로 인간의 관계와 가치에 대한 중요성을 전파하고 싶으신가요?

당신이 바로 그 사람이라면 주저없이 모니모니의 문들 두드리시거나 커피챗을 요청해주세요.

전 직군 채용중

  • Developer

  • Designer

  • PM

  • Marketer

1
1
이정환

이정환

우리가 어떻게 배워야 할까요?

"어디서부터 어디까지 공부해야 할지 막막해요"

"왜 해도 해도 끝이 안 보일까요?"

최근 개발자 취업을 준비하시는 분들(or 주니어 개발자 분들)을 대상으로 “어떻게 배워야 하는가” 라는 주제로 학습 전략에 관한 온라인 세미나를 진행한 적이 있습니다.

세미나를 준비하면서 많은 걱정을 했었는데요
생각보다 많은 분들께서 많은 도움이 되었다고 하셔서 참 다행이었고 뿌듯했습니다.
그래서 이번에는 더 많은 분들께 조금이나마 도움이 될 수 있도록 가벼운 글로도 함께 남겨보려고 합니다.

- 우리의 학습은 왜 이렇게 어려운 걸까요?
- 학창시절에는 어땠나요?
- 학교를 벗어난 이후의 학습
- 나만의 기준을 세우자
- 몰입 가능한 주제를 어떻게 찾을 수 있을까요?

본문 읽기

0
2