데이로그: 근황

59INU·2022년 11월 7일
0

데이로그

목록 보기
1/1
post-thumbnail

버블 찍먹

노코드 이야기만 듣고 실제로 생태계가 어떻게 구성되어 가는지, 누가 관심이 있는건지 살펴볼 기회가 되어서 재밌다. 현재 활발하게 유입되는 사람들의 배경이나 요구를 봐서는, 프론트엔드 개발 혹은 웹개발자의 경쟁자라기 보다 직접 개발자를 채용하거나 아웃소싱하기 위한 비용이 부담되는 극초기 스타트업에서 시장 테스트용 MVP를 직접 만들기에 아주 좋아보였다. 차라리 직접 만들고 싶어 답답해하던 기획자 디자이너 마케터 등등 다양한 배경을 가진 사람들이 까다로운 요구 사항들을 직접 찾아 어떻게든 만드는 걸 지켜보면서 심지어 약간의 반성도 했다. 개발자를 채용하거나 아웃소싱의 비용을 결심하는 단계까지 도달하는 과정에 좋은 툴이 되겠다고 생각했다. 그렇게 더 많은 사람들이 쉽고 빠르게 시장 테스트를 진행하고 개발자를 채용하는 스테이지에 도달하는 기업들이 늘어난다면 너무 좋은일이지.조금만 워크플로우가 복잡해지거나 로드할 자원이 많아지면 퍼포먼스가 떨어지는 게 조금 아쉽긴 한데. 이 아이디어 될까, 낮은 비용으로 유연하게 초기 모델 시장 테스트 하기에 넘나 좋은 도구구나. 누군가에게 너무 너무 필요했던 솔루션이구나 싶었네.
더불어 찍먹 과정에서 개인 맥락에서도 몇 가지 인상 깊은 지점들이 있다.

  1. Early staged
    단일 상품에서 플랫폼 구조가 되려는 타이밍이라 상품 정의와 구조부터 정규화해야 하는 상태라서 극초기 스타트업 조인한 기분이 들었다. 상품 정의, 기능 정의나 사이트 구성 등 전반적인 기획에 대해서도 듣고 말할 기회가 많아서, 처음엔 내가 잘 몰라 시작을 썩 잘못 뀄구나 했는데 재미있었다.

    pre-A 시리즈로 초기 단계였던 첫 회사에서 업무 강도나 심적 부담도 어려웠지만, 매일 무시무시한 속도로 적층하는, 갈수록 확장과 유지 보수가 어려워지는 엉망인 코드를 보면서도 근미래에라도 개선할 수 있는 방법이나 방향에 대해 논의할 수 있는 선임개발자가 없는 상황, 그 가운데 돌아가기만 하는 코드를 쓰는데 머물러있다는 좌절감이 너무 속상했는지 은연 중에 얼리스테이지는 이제 피해야한다는 생각을 자꾸 했는데, 음 재미있었다. 끝내 정말로 답이 없다고 결론 내리기 전까지 첫회사도 그 와중에도 재밌었다.

    시니어가 된다면, 그 때까지 살아남는다면, 지금보다야 숙련된 기술을 바탕으로 얻은 기술적 자유를 가지고 다시 작은 스타트업에 조인해서 정말로 제로투원 빌드업을 해보고 싶었는데, 언젠지도 모를 그게 문제가 아니라 당장에 극초기 스타트업을 가지 않겠다면 새로 시작하는 사업부라도 들어가면 재미있어 하는 게 아닐까 싶다.

  1. Linear
    원체 다이어리도 잘 못쓰고 블로그도 꾸준히 못하는 타입이라. 막연하게 좋은 것 같긴한데 언제 어떻게 써보려나 싶더니, 쌩 혼자서 요건 정리하고 일정 세워 중간 중간 피드백 조율까지 하느라 이 때다 싶어 써봤다. 이상적으로 생각하는 포맷과 방향을 뚜렷하고 간결하게 제시하는 느낌이라서 오히려 너무 많은 기능을 어떻게 써야 효율적인지 고민하지 않는 게 좋았다. 대략의 일정과 이슈 사이즈를 파악하고 있으며 혼자 일하고 있는 이번 경험에는 너무 좋았는데 협업툴로 사용해도 괜찮으려나.

    자리에 앉으면 일단 Linear 프로젝트 화면을 시작점으로 삼자고 생각했는데 기대보다 쾌적하고 좋았다. 와이어프레임, 디자인, 로우코드 에디터, 에어테이블, Notion 등 관련 링크를 모두 몰아두었다. Feature, Config, Data, Meeting 등 편의에 맞게 몇가지 라벨로 이슈를 구분했다. 프로젝트 화면에서 내가 알아야 할 모든 관련 링크와 현재 이슈 티켓, 전반적인 진척도를 한 눈에 확인할 수 있어서 띄워두기에 간결하고 충분했다.

    아마 미숙해서 더 그랬겠지만 Jira를 사용할 때 느꼈던 기능이 100개는 더 있는 거 같은데 내게 뭐가 더 필요한지조차 모르겠던 그 고민이 없어서 좋았네. 생산성을 위한 관리툴인데 가끔 툴이 목적이 되는 순간들을 느낄 때가 있다. 기왕 주변에 있는 거 뭐든 기깔나게 멋있게 쓰고 싶은. 얼마 전에 SNS에서 조직은 체계적이라는 명목의 복잡성과 낭비를 경계하지 않으면 단순성의 원칙을 잃기 쉽다는 맥락의 글을 본 것 같은데 살면서 많은 영역에서 기억해둘 말 같다.

  2. 취업... 하고 싶을지도
    2년 반동안 고질병이 되어버린 조급증과 불안도 끊고 가고 싶었고, 첫 회사 이후 멘탈과 함께 요단강 건너버린 건강과 체력도 어느정도 궤도에 올려놓고 싶었고, 성급한 마음 없이 3년 근속을 이룰 회사를 찾아야지 했는데.
    잘 놀고, 성급한 운동으로 인하여 허리 디스크가 악화되고, 잘 놀고, 어쩌다 화면도 만들고, 잘 놀고 이제야 공부를 하는 척 하기는 하지만.
    PM과 디자이너와 옆자리 개발자와 말을 하고 싶다. 혼자 해서 편하고 혼자 해서 덜 재밌다. 하지만 어떤 환경을 좋아하는지에 대해서 좀 더 알게된 기분이 든다.

사이드 프로젝트

깃헙에서 볼 수 있는 게 새삼 아무것도 없다.
개발자의 덕목과 다른 것을 나도 알고 있지만, 별 것 아닌 과정과 부분들을 공개된 장소에 누적하는게 아직도 어색한 것 같다. 한 때는 그럴 수 밖에 없었다고 하더라도 결과적으로 일 밖에 안한 게 잘한 일이 아니고 과거로 돌아가 볼기짝을 때려주고 싶지만. 시키지도 않은 야근하는 것으로 증명하고 싶은 것은 없었고 그냥 더 하고 싶었을 뿐이지만 스도쿠 풀듯이 일을 하지 말고 생각을 가지고 성장을 하자...

SolidJs

아티클 몇 개 읽다가 얼마 전에 지나가듯이 보고 뭐지 싶었던 SolidJs나 찾아봤는데 튜토리얼 따라하며 구경 중인데 약간 넘 좋은데... 가상돔이 없다는 점과 반응성 등 튜토리얼 구경 끝나고 나면 좀 더 봐야겠지만 튜토리얼만 보고 설레는 점들이 있어...

ㅎㅎ 부트캠프 수료하고 얼마 안됐을 때 너무 너무 만들어 쓰고 싶었지만 딱히 지지를 얻지 못해 생각만 하다 미뤄둔 패턴이었다. 어느 예제에서 실제로 돌아가는 코드인지, 아니면 예제용 코드인지 이런 커스텀 컴포넌트로 조건부 랜더링을 다루는 코드를 봤다. 당시 프로젝트 코드가 조건부 랜더링도 너무 많고 그 때마다 분기점이 너무 너무 많은데 리턴부 코드가 이렇게 읽기 힘든게 말이 되나 싶었다. 근본적인 문제는 리턴부 좀 보기 좋게 만든다고 될 게 아니었지만 그 때쯤엔 뭐가 어떻게 돌아가는건지 한 눈에 파악이라도 하고 싶었다. 어쩐지 다들 시큰둥한 반응이어서 접어뒀는데... 최근에 했던 작업들은 조건부 랜더링이 전보다 빈도가 줄었는지 내 코드 패턴이 좀 정리가 된건지 괴로운 일은 없었지만, 랜더링 될 컴포넌트 구조가 리턴부 내의 온갖 중첩 분기분과 상단의 함수와 리터럴 객체에 흩어져 있던 그 때를 생각하면 명령형 코드와 선언형 코드의 구분도 힘들었지만 어떻게든 선언형 코드 흉내라도 내고 싶었다.

라이브러리 추가해서 사용했던 편의 기능들 표준으로 제공하는 거 발견하면 rgrg 되자나. 물론 동적으로 클래스네임이 결정되어야 하는 구조를 요즘은 피하고 있지만. 아직 내부 원리나 리액트와의 차이점, 장단점 살펴보기 전이지만, 첫 인상.. 곱고 예뻐요... 쾌적해보여요. 왠지 찜찜하게 만드는 프레임워크 고유 문법도 거의 없는 것 같고. (이벤트 위임 부분에서는 외형상 비슷한 문법을 사용하는 것 같기도 한데 아직 다 안 봣다) signal 파생 부분에서 mobx 생각이 났는데 실제로 관련이 있는것 같고 내일은 튜토리얼 말고 좀 자세히 봐야겠다

profile
개랑 사는 개발자

0개의 댓글