Call Me Maru

2025 회고

Mon, 22 Dec 2025 00:07:58 +0900

1월

AI 코드 리뷰 도입을 고민 하기 시작 했다. 25년에는 AI를 통해 생산성을 향상 시키는 방향을 많이 고민 해보고 싶었다.
3년 전에 사용 했던 datadog을 재도입 하는 것을 고려 했다. 좋은 툴이지만 과거에 비용 문제가 있었고, 3년이 지난 시점에 비용 세이브 할 수 있는 방향을 제안 받았다. PoC를 진행 하기로 했다.

2월

신규 서비스가 오픈 했다. 24년부터 반년에 한 번 씩 신규 서비스가 오픈 하는 것 같다. 개발 속도도 좀 더 빨라지는 것으로 보면 역량이 향상 된다는 증거인 것 같다.
22년부터 앱 내에 이벤트(인기 상품 오픈 등)이 있으면 서버가 불안정해졌다. 이번 년도에는 부하를 많이 일으키는 상품 리스트 쪽을 반드시 개선 해야겠다는 생각을 했다.
데일리샷 프로덕트팀에서 팀 활동으로 1박 2일 해커톤을 진행 했다. 개발을 하는 참가자는 아니였고 기획하고 운영 하는 포지션이였다. 2018, 19년에 개인적으로 해커톤을 만든적이 있었는데 옛날 생각이 났다.
대부분의 팀원들이 회사 일에서만 개발과 디자인을 하다가 해커톤에서 만들고 싶은 제품을 만들다 보니 리프레쉬를 할 수 있는 시간이였다.
아무리 바빠도 리프레쉬 할 수 있는 시간을 가진다는 것은 중요한 것 같다.

1등을 위한 상패

2024 회고

Mon, 22 Dec 2025 00:07:54 +0900

1월

데일리샷 앱에서 도입 될 신규 서비스를 시작 했다.
AI를 업무에 어떻게 적용 시킬지 고민하기 시작 했었다.
서버 파트의 업무 과다가 많이 있었던 달이였다.
누적 회원 수가 100만을 바라보고 있었다.

2월

비즈니스 서비스에 집중을 하다 보니 내부 서비스(어드민)에 많은 신경을 못 썼다. 이를 해소 하기 위해 일정을 통으로 비워서 어드민 개선을 진행 했다.
스타트업은 달리는 기차의 바퀴를 갈아 끼우는 일들을 많이 한다.

3월

다시 테니스 레슨을 시작 했다.
좋은 글을 읽었다. 이 시기에 인프라는 내가 모두 관리 했는데, 많은 도움이 되었다.
오랫동안 서버 파트에 있었던 TO 한 자리가 채워졌다. 오랜 시간 보충 되지 않은 상황에서도 맡은 일들을 잘 해준 서버 파트 팀원들에게 감사함을 느낀다.

4월

처음으로 도쿄를 가봤다. 굉장히 매력적인 도시였다. 그 이후로 몇 번 더 갈정도로 마음에 들었다.
이때까지도 구글링이라는 단어를 썼다. 26년 지금은 구글링이라는 단어를 언제 썼는지 기억도 안난다.

5월

MongoDB의 소규모 세션에서 발표를 했다
오래동안 감기를 달고 있었던 기록이 있다. 건강은 항상 중요 하다..

6월

1월에 시작한 신규 서비스 개발이 마무리 되었다. 해당 서비스의 담당 개발자가 분이 프로젝트를 잘 마무리 할 수 있게 일을 잘 해주셨다. 성장 하신 것 같아서 기분이 좋았다.

7월

반년만에 돌아온 어드민 개선(어드민 데이)를 진행 했다.

8월

서버 파트에 신규 팀원이 합류 했다.

9월

MongoDB.local에서 연사로 발표를 했다. 23년 MongoDB.local 참석 했을 때 발표에 대한 꿈이 있었는데 1년 만에 이뤄서 좋았다.
하반기 목표 설정이 9월에 이루어졌다. 목표 설정을 한지 오래 됐지만 제 시간에 하는 것은 참 어렵다.

10월

한 번 더 신규 서비스 도입을 시작 했다. 24년에는 신규 서비스 도입이 많았다.

11월

전사 팀원의 숫자가 늘어남에 따라 이전보다 좀 더 회사 같은(?) 분위가 되고 있다는 피드백이 있었다. 당연한 현상일까.. 아니면 해결 할 수 있는걸까?

12월

CTO 모임을 알게 되어 나가봤다. CTO들은 다 비슷하게 일을 하고 고민을 하는구나를 느꼈다.
처음으로 대장 내시경을 했는데 작은 용종이 나왔다. 심각한 것은 아니지만 건강 관리 잘 해야겠다.

24년은 23년과 마찬가지로 해야 되는 일이 생기는 속도에 맞춰 가기 위해 많은 노력을 했던 해였다. 그리고 리드로써 경험이 축적 되면서 방향성을 잡아가기 시작 했던 해이기도 했다.

2023 회고

Mon, 22 Dec 2025 00:05:36 +0900

1월

올해도 한 번 더 서비스 구조 개편, 대규모 리팩토링으로 시작 했다.
동시에 특정 도메인을 외주로 진행 해야 해서 소통에 정신이 없었다.
나의 전문성이 없는 분야의 팀원들의 역량을 제대로 평가하기 위해서 파트 리드 제도 도입을 제안 했다.
웹 도메인에 대한 요구 사항이 늘어나기 시작 해서 웹파트 신설을 제안 했다.
고객들의 따듯한 관심이 생기기 시작 했다. 기능 제안도 해주시고 새로운 술을 소싱 해달라는 메일들이 종종 왔다.

2월

팀 내에도 chatgpt 키워드가 들어나기 시작 했다.
notion에서 AI 솔루션을 출시 했다. 이때까지만 해도 AI가 이렇게 발전 할줄은

AI 붐이 시작 하는 시기였던 것으로 기억한다. 그에 맞게 스터디 그룹도 했었다.

3월

1월에 신설한 웹파트에 첫 번째 팀원이 합류 했다.
길고 길었던 서비스 구조 개편의 마무리가 보였다.

4월

앱스토어의 데일리샷 앱의 리뷰가 1000개를 돌파 했다.

5월

팀원 모두 각자 관심 있는 분야의 스터디를 했다. 지금 생각 해보면 오래 가진 않았던 것 같다.

6월

동시에 여러 프로젝트를 정신 없게 진행 했던 시기였다. 슬랙 메세지를 보면 다양한 도메인의 프로젝트들을 소통 하는 기록이 남아 있다.

7월

가족사진을 찍었다. 지금 생각 해보면 잘한 결정이라고 생각 한다.

8월

번아웃이 온 것을 깨달았다. 쉼이 필요 했다.
개발자와 리드로써의 일들이 아주 많았다.

9월

새로운 웹 파트 개발자가 합류 했다.
슬랙 메세지를 보니 예민한 시기였던 것 같다. 번아웃이 지속 되고 있었나보다

10월

개발팀에 온콜 제도를 도입 했다. 이슈가 많아서 혼란스러울 때가 많은 시기였던 것 같다.
휴가로 미국을 다녀왔다. 리프레쉬도 됐고 번아웃이 많이 해소 되었다.

11월 ~ 12월

커피 내기를 많이 졌다..
그것 외에 회고할 만한 내용은 보이지 않았다.

23년은 내용이 많지 않은데 번아웃을 일으킬 정도로 일만 해서 그런게 아닐까 싶다. 사실 회고를 통해 했던 일에서 레슨런이 있어야 하는데 시간이 많이 지나서 할 수 없었다.

2022 회고

Mon, 22 Dec 2025 00:04:56 +0900

21년부터 지금까지 개발자로 보내는 시간의 대부분은 회사 일이였다. 아마도 회사가 계속 성장하고 개발팀과 서비스의 규모가 커지면서 신경 써야 할 부분들이 기하급수적으로 늘어나서 그랬을 것 같다.

1월

서비스가 커가는 것을 느낀다. 점점 타 기업에서 협업 요청이 들어오기 시작 했다
서버 개발자를 1명 더 채용 하기 시작 했다.
현재는 스토어 서비스라고 불리는 바로 픽업 서비스 MVP 제작을 시작 했다. 사이드 프로젝트에서 잠깐 써봤던 React로 만들기 시작 했는데, 지금 생각 해보면 무슨 자신감으로 숙련도도 없는 툴로 2주만에 서비스를 만들겠다고 했는지 모르겠다.(어찌저찌 만들긴 했다. 지금도 노력하고 있지만 이때는 맨땅에 헤딩하기에 익숙한 시기였던 것 같다)
- 대표님이랑 둘이 서비스를 런칭 했었는데, 26년 지금 관점에서 보면 참 용감한 의사 결정들과 과정들이 많았다. 겁 없는 시절에 할 수 있던 일이였던 것 같다.

2월

신규 서비스(바로 픽업)을 만들면서 심심하면 다운 되는 서버도 계속 대응하는 작업의 반복이였다. 남일 같지 않은 타 회사 경험담을 스크랩한 기록이 있다.
이 시점에서 개발팀원은 나를 빼고 3명이였고, 1명을 신규 채용 하려고 했던 시기 였다. 개발자 연차로는 5년차이지만 나름 팀의 리드였고 부담감에 다양한 자료와 책 그리고 행사들을 찾아보고 공유 했던 기록들이 있다.
이때 당시 팀원들은 내가 공유 하는 자료들에 리액션이 별로 없었던 것 같다. 지금 보니 좀 쓸쓸해 보이는 공유 메시지가 많은데 지금 팀원들이 공유 해주면 잘 리액션 해줘야겠다.

3월

테니스를 열심히 친다. 이 시기에 필드를 처음 나갔는데, 확실히 밖에서 경기를 하는 것이 더 재밌더라
데일리샷 팀원들과 만취 해서 찍은 사진이 있다. 살면서 손에 꼽을 정도로 만취 했던 경험인데.. 이때 이후로 어른 답게 술을 먹으려고 노력한 기억이 떠오른다.
어떤 회사에 지원서를 썼었다. 이직 준비는 아닌 것 같아 찾아보니 나에 대한 평가가 궁금해서 지원 했다는 나의 생각을 팀원에게 공유한 기록이 있다. 지금 보면 나 뿐만 아니라 4~5년 차에 시장에서 나에 대한 평가를 확인 하고 싶은 니즈가 누구에게나 있는 것 같다.

이쁘게 말해줘서 감동

2021 회고

Mon, 22 Dec 2025 00:04:36 +0900

2025년에 적는 5년 전 회고.

1월

메타버스에서 지인들과 2020년 회고를 했었다. 메타버스가 지금(2025년)의 AI와 같이 성장할 줄 알았지.

새해 첫 날부터 지인이랑 프로젝트를 시작했다. 새롭게 시도해보는 것을 좋아했던 시기였던 것 같다.

목업 이미지. 예쁘다고 생각했는데..

1년 가까이 했던 파이썬 스터디가 끝났다. 지금(2025년)까지 파이썬만 계속하고 있을 거라는 생각은 안 했던 것 같다. 처음 시작했을 때는 현실의 제품과 관련 없는 지식이라고 생각했는데, 끝날 무렵에는 언어에 대한 이해가 늘어나면서 현실의 제품을 좀 더 깊게 바라볼 수 있었던 것 같다.

Permission error when push to GitHub Pacakges by GitHub Actions

Sun, 21 Nov 2021 16:47:01 +0900

이 글은 나처럼 공식 문서를 전체적으로 파악하지 않은 상태에서 GitHub Actions으로 GitHub Packages에 push 하는 사람들의 삽질을 방지하기 위한 글이다.

어떤 테스크를 해결하기 위해 도커라이징 한 파일을 GitHub Packages에 올릴 일이 생겼다.

매번 이미지를 빌드 할 때 마다 푸시하기 귀찮았고, 이미 GitHub Actions을 CI 용으로 쓰고 있기 때문에 GitHub Actions로 docker 이미지를 푸시 하는 것을 구현하였다.

GitHub Actions에서 docker 레지스트리에 로그인하고 빌드한 뒤 푸시하는 예제는 공식 문서에 아주 잘 나와 있어 구현하기 편했다.

Cookiecutter - 지겨운 프로젝트 세팅은 이제 그만하자..!

Sun, 27 Jun 2021 01:00:00 +0900

나는 새로운 프로젝트를 생성할 때마다 똑같은 상황에 부딪히곤 한다. “분명히 예전에 해봤던 세팅들인데?” 라는 생각과 동시에 기억이 흐릿해져, 결국 예전에 했던 프로젝트들을 뒤적이며 프로젝트 세팅에만 에너지를 다 쏟아 정작 비즈니스 로직은 하나도 못 짜고 내일을 기약하는 경험이 한 두번이 아니였다.

고통에 몸 부리치던 와중.. react에서 template이라는 기능을 통해 미리 세팅해놓은 프로젝트를 터미널에서 커맨드 한 줄로 바로 생성했던 것이 기억 났다. 요즘은 django나 fastapi 프로젝트를 주로 하고 있어서, 비슷한게 없나 찾아보다 역시나 개발 세상에는 없는게 없드라..

[정리] 1인 기술 스타트업의 아키텍처 스택

Sat, 24 Apr 2021 14:34:02 +0900

최근에 GeekNews에서 재밌는 글을 봤다. SaaS를 운영하는 1인 개발자가 설계한 아키텍처에 대한 설명인데, GeekNews에 공유해주신 분이 요약 해주신 내용만으로도 굉장히 퀄리티 높은 글인 것을 느낄 수 있었다. 그래서 나도 원문을 읽으며 나름대로 정리를 해볼려고 한다.

참고로 본인이 1인 기술 스타트업을 만들 생각이 없어도 개발자라면 한 번쯤 읽어보면 도움이 되는 글이라고 생각한다.

원문 글: https://anthonynsimon.com/blog/one-man-saas-architecture/

서론

원문 글의 필자는 독일에서 1인 기업을 운영하고 있고 스트레스 없이 자기 자본으로만 천천히 운영하고 있다고 한다.
혼자서 운영하는 만큼 다양한 오픈 소스와 서비스들을 사용하게 되었는데, 이것 없이는 목표를 이룰 수 없었고 이걸 사용함에 있어서 거인의 어깨에 서있는 느낌을 받았다고 한다.(개인적으로 이 표현이 좋았다.)

쉘 로딩 시간 개선하기

Sat, 06 Mar 2021 23:00:18 +0900

어느 순간부터 터미널의 시작 시간이 오래 걸리는 느낌이 들었다. 터미널을 자주 끄고 키고 하는 습관이 있어서, 시작할 때마다 3~~4초동안 검은 화면에 비춰지는 내 얼굴을 봐야 했다. 1분 1초가 아까운데 3~~4초의 시간을 내 얼굴을 보는데 사용하는 것은 너무 아깝다. 원인을 찾고 해결해서 속도를 개선하고 싶은 니즈로 구글링을 해봤다. 다행히, 나와 같은 니즈를 가지고 있는 사람의 잘 정리한 블로그 글을 발견했다. 방법만 알고 싶으면 해당 글을 봐도 좋지만, 나는 shell에 대한 지식이 하나도 없어서 글에 나오는 shell의 개념들을 이번 글에서 정리하며 노트북에서 3~4초 동안 검은 거울이 생기는 문제를 좀 더 짧게 나오도록 해보고자 한다.

[GitHub Actions] React Deploy

Sat, 06 Feb 2021 14:07:16 +0900

React 프로젝트를 GitHub Actions와 GitHub Page를 이용해서 배포해보자.

나는 기존에 오픈 소스로 개발 중인 프로젝트를 사용했다.

이 글은 GitHub Actions를 이해하고 있다는 가정하에 작성한다. 만약 GitHub Actions에 관해 공부해보고 싶다면 블로그에 정리해놓은 글 또는 공식 문서를 보자.

전체 코드

전체 코드를 먼저 보고 하나씩 의미를 알아 가보자.

name: Deploy

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v2.1.2
        with:
          node-version: "12.x"

      - name: Cache dependencies
        uses: actions/cache@v2
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      - name: Install dependencies
        run: npm install

      - name: Make env file
        run: |
          touch .env
          echo REACT_APP_MODE=prod >> .env
          echo REACT_APP_GA_ID=${{ secrets.REACT_APP_GA_ID }} >> .env

      - name: Build app
        run: npm run build

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./build

workflow 이름 및 이벤트 정의

name: Deploy

on:
  push:
    branches:
      - master

workflow의 이름은 Deploy로 정의하고, 이벤트는 master 브랜치로 푸시하는 것으로 정의하였다.

[GitHub Action Learning] #3 Workflows에서 변수 사용하기

Wed, 27 Jan 2021 00:10:06 +0900

개발을 하다보면 세팅이 불가피한 기능 또는 프로그램을 사용할 때가 있다. 예를 들어 PostgreSQL 같은 데이터베이스에 연결 할 때 HOST, PORT, USERNAME, PASSWORD 같은 환경 변수를 세팅해야 할 때가 있다. 또는 job을 이용해서 어플리케이션을 빌드한 다음에 내가 작성한 script를 돌리고 싶을 때도 있다.

이렇게 커스텀하게 GitHub Actions를 다뤄보는 방법에 대해 알아보도록 하자.

환경 변수

일단 각 workflows가 실행 될때 마다 GitHub Actions가 가지고 있는 기본 환경 변수가 제공 된다.

물론 개발자가 원하는 환경 변수를 설정 할 수도 있다. 환경 변수는 step, job, 그리고 workflow 전체의 범위로 사용 할 수 있다. 아래 예제는 step과 job에 환경 변수를 사용한 경우다.

[GitHub Action Learning] #2 GitHub Actions 예제

Tue, 19 Jan 2021 23:52:15 +0900

GitHub Actions는 YAML로 events, jobs, 그리고 steps를 정의한다. 그리고 YAML 파일은 레포지토리의 .github/workflows에 저장된다. 이 YAML을 직접 작성하고 Actions를 실행 시켜보자.

만들 예제는 npm으로 bats를 설치하고 bats -v를 실행하는 간단한 액션이다.

예제 만들기

1. 레포지토리 생성 및 YAML 파일 작성

GitHub에서 레포지토리를 새로 만들고 .github/workflows에 YAML 파일을 작성한다.

# https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions#create-an-example-workflow
name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
      - run: npm install -g bats
      - run: bats -v

편의상 GitHub에서 바로 작성 했다.

[GitHub Action Learning] #1 GitHub Actions 소개

Sun, 10 Jan 2021 01:58:03 +0900

최근에 개인 프로젝트를 여러 개 시작 했다. 배포에 대한 걱정을 좀 줄여보고자 처음으로 CI/CD를 공부해보자 마음 먹었다.

CI/CD에 대해서 아는게 하나도 없어서, 서칭을 하다가 그저 탭으로만 마주한 GitHub Actions이 CI/CD 툴인걸 알게 되었다. 굉장히 많은 툴들이 있었는데, GitHub Actions은 GitHub에서 CI/CD에 대한 고민도 바로 해결 해주는 느낌이였다.

이렇게 툴은 결정했고 GihHub Actions Learning 문서를 보면서 공부한 내용을 블로그에 정리했다.

문서의 내용이 많으니 블로그 글은 나눠서 게시하겠다.

CI/CD 란?

CI/CD에 대한 개념은 굉장히 많은 자료가 있다. 그렇기 때문에 간단하게만 적고 넘어가겠다.

2020 회고

Mon, 28 Dec 2020 21:28:42 +0900

태어나서 처음으로 “나도 회고 글 써서 블로그에 포스팅 해야지"라는 다짐을 한게 2017년 12월이였다. 그리고 3년이 지난 지금 2017년의 다짐을 실천하고 있다. 이 글이 올라갈지는 2021년 1월 1일이 되어봐야지 알겠지만…

사실 2017년 12월 24일에 회고를 목표한 양 60%로 정도 쓰긴 했었다. 개인적으로 좋아하는 카페에서 맥북 13인치 2015년 형을 열어놓고 열심히 썼지만 밤에 약속이 잡혀 있어서 중간에 멈춰야 했다. 마침 25일 오전에 중국 청도에 갈 일정이 잡혀 있어서, 비행기에서 끝낼 생각으로 약속에 갔다.

Glide Error - You cannot start a load for a destroyed activity

Thu, 14 May 2020 13:45:11 +0900

Glide 관련 된 처음보는 오류가 발생했다.

You cannot start a load for a destroyed activity

다행히(?) 예전에 이슈가 된 에러였다.(https://github.com/bumptech/glide/issues/803)

이런 에러가 발생한 이유는 with() 함수가 lifecycle을 따르기 때문이다. 즉 Glide가 이미지가 로드 중 Glide.with()의 with()에 들어간 인자가 “activity 또는 fragment가 destroyed"되면서 영향을 받게 되고 위의 에러가 발생한 것으로 보입니다.

스택오버플로우에서 제안하는 방법으로는

아래와 같이 RequestManager를 변수에 담아주고 사용하는 것이다.

class MyAdapter extends WhichEveryOneYouUse {
    private final RequestManager glide;
    MyAdapter(RequestManager glide, ...) {
        this.glide = glide;
        ...
    }
    void getView/onBindViewHolder(... int position) {
        // ... holder magic, and get current item for position
        glide.load... or even loadImage(glide, item.url, holder.image);
    }
}

loadImage(Glide.with(this), url, findViewById(R.id.image));
// or
list.setAdapter(new MyAdapter(Glide.with(this), data));

Reference

[Maru의 Kotlin Tour - 공식 문서 편] #3 Returns and Jumps

Wed, 05 Feb 2020 00:28:44 +0900

kotlin에는 3가지 jump 표현식이 있다.

return : 제일 가까운 enclosing function으로 부터 return 합니다.
break : 제일 가까운 enclosing loop를 종료합니다.
continue : 제일 가까운 enclosing loop의 다음 단계(step)를 진행합니다.

Break and Continue Labels

Kotlin의 어떤 표현이든 label을 붙일 수 있다. @을 붙여서 라벨을 만들 수 있는데, 아래와 같이 쓰인다.

loop@ for (i in 1..100){
  // ...
}

이제, break에 label을 붙이면 아래와 같이 쓸 수 있는데

loop@ for (i in 1..100){
  for (j in 1..100){
    if (...) break@loop
  }
}

위의 코드 같은 경우는 break@loop에서 loop@로 점프 한 후 바로 다음 코드가 실행 된다고 한다. continue 같은 경우는 loop의 다음 반복자가 실행 된다고 한다.

[Maru의 Kotlin Tour - 공식 문서 편] #2 Control Flow

Sun, 02 Feb 2020 23:23:53 +0900

If Expression

if는 expression, 즉 값을 return 하므로 tenary operator(condition ? then : else)가 없다고 한다.(난 tenary operator 좋은데..)

그럼 if 표현식을 보자

// Traditional usage
var max = a
if (a < b) max = b

// With else
var max: Int
if (a > b) {
    max = a
} else {
    max = b
}

// As expression
val max = if (a > b) a else b

마지막 코드인 val max = if (a > b) a else b가 tenary operator와 비슷해보인다.

[Maru의 Kotlin Tour - 공식 문서 편] #1 Basic Types

Sun, 02 Feb 2020 23:23:40 +0900

해당 문서 첫 문장에 참 친근한 문장이 있다.

In Kotlin, everything is an object

그래서 모든 변수에서 member function과 properties를 부를 수 있다고 한다.

이 섹션에서는 numbers, characters, booleans, arrays, 그리고 strings을 다룬다.

Numbers

Kotlin에서 integer는 총 4가지, floating은 총 2가지 타입을 제공해준다.

Integer

Byte
Short
Int
Long

val one = 1 // Int
val threeBillion = 300000000 // Long
val oneLong = 1L // Long
val oneByte: Byte = 1

위의 코드에서 주목해야 할 점은 threeBillioin 변수이다.

[Maru의 Kotlin Tour - 공식 문서 편] #0 Intro

Sun, 02 Feb 2020 17:30:14 +0900

들어가기 앞서 코틀린의 정의와 Command Line Compiler를 설치하는 법을 알아보겠습니다.

코틀린의 정의

코틀린(Kotlin)은 JVM에서 동작하는 프로그래밍 언어이다. 2011년 7월, 젯브레인사가 공개하였다.

캇린으로 읽어야 한다. (캇린으로 읽어야 하는 것은 처음 알았습니다;;)

Install Command Line Compiler

Kotlin으로 작성한 파일을 실행하기 위해서는 몇 가지 방법을 Tutorial Getting Start에서 제안합니다. 저는 여기서 Working with the Command Line Compiler 방법을 선택 했습니다.

설치 방법도 여러가지 입니다. 저는 OS X를 사용하기 때문에 HomeBrew를 이용해서 설치하겠습니다.

다른 방법들은 문서를 참고 해주세요

$ brew update
$ brew install kotlin

[Maru의 Kotlin Tour] Prologue

Sun, 02 Feb 2020 17:28:36 +0900

Kotlin이라는 언어를 공부 해보겠습니다.

참고하는 자료에 따라 시리즈로 진행 할 계획입니다.

시리즈

공식 문서 편

Flutter State Management - Provider

Sun, 12 Jan 2020 17:33:13 +0900

Flutter에는 State가 있다. 사용자에 의해 이벤트가 발생 했을 때 state를 이용하여 UI를 업데이트 해준다.

예를 들자면, 우리가 Flutter Project를 처음 생성 했을 때 기본으로 있는 count 앱을 들 수 있다. 사용자가 Floating Button인 + 버튼을 누르면 화면 중앙에 있는 숫자가 1씩 증가한다. 아래 코드와 같이 state를 이용하여 _counter 변수를 업데이트하고 UI를 업데이틑 하는 것을 확인 할 수 있다.

int _counter = 0;

void _increment(){
  setState( () {
    _counter++;
  });
}

[Flutter] 토이 프로젝트 후기 - (1)

Fri, 17 May 2019 10:42:36 +0900

react-native가 출시 된 지 4년이 지났습니다.

모바일 애플리케이션 개발에서 크로스 플랫폼 동시 개발을 가능하게 해준 react-native는 굉장히 파워풀한 기술인 거 같습니다.

그렇게 2년이라는 시간이 지나 react-native와 마찬가지로 iOS와 Android를 동시에 개발할 수 있는 프레임워크인 flutter가 처음 등장했습니다.

구글이 만든 프레임워크고 밀어 주려고 하는 기술인 거 같아, 경험해 볼 겸 간단한 앱을 만들기로 했습니다.

이번 글에서는 flutter로 앱을 만들면서 느꼈던 점들을 공유해보겠습니다.

글은 1편과 2편으로 나누어 작성하겠습니다.

📑 간단한 기획

저는 웹에서 토이 프로젝트를 할 때 보통 블로그 형식을 구현했었습니다. 그래서 Flutter로 간단한 메모 앱을 만들어 보기로 했습니다.

[Flutter] 토이 프로젝트 후기 - (2)

Fri, 17 May 2019 10:42:36 +0900

1편에서 이어서 2편은 프로젝트를 진행 과정을 소개하고 후기를 마무리 하겠습니다.

🗂 Flutter

Widget

Flutter에서 대부분의 UI들은 Widget Class에 속해 있습니다. 예를 들어, AlertDialog 문서를 보면 AlertDialog가 어디에 속해있는지 확인 할 수 있습니다.

StatelessWidget & StatefulWidget

React를 사용해보신 개발자 분들에게는 친숙한 개념일 수도 있습니다. Flutter의 모든 UI 즉 Widget은 상태(state)를 가집니다.

Widget이 StatelessWidget을 상속 할 때는 상태가 변하지 않아도 되는 UI로 그려집니다.

Widget이 StatefullWidget을 상속 할 때는 상태가 변하는 UI로 그려집니다. Flutter에서 제공하는 setState 함수를 통해서 widget의 상태를 변화 시킬 수 있습니다. (최근에 알게 되었는데 setState 말고도 widget의 상태를 관리해주는 방법들이 제공된다고 합니다. 특히 provider라는 프레임워크가 2019 Google I/O에서 언급이 되었는데, 굉장히 잘 만들었으니 꼭 사용하라고 언급 되었습니다.)

[Kotlin] 범위 지정 함수

Fri, 12 Apr 2019 14:02:23 +0900

Kotlin에서 사용되는 함수 중에 범위 지정 함수라는게 있습니다. 이 함수들은 비슷한 모습을 하고 있어서, 약간의 혼란을 불러 일으키는 것 같습니다. 그러므로 이번 글에서는 이 범위 지정 함수들을 정리해보겠습니다.

apply, with, let, also, run은 전달받는 인자와 작동 방식, 결과가 매우 비슷하다. 이 5개는 범위 지정 함수라고 명칭한다.

이 함수들은 공통적으로 두가지 구성 요소를 가진다.

수신 객체
수신 객체 지정 람다

함수 타입의 receiver이다. 예시 :

val sum: Int.(Int) -> Int = { other -> plus(other) }

블로그의 목적

Sat, 06 Apr 2019 02:02:59 +0900

이전에 개발 블로그를 만들기 위한 두 번의 시도가 있었습니다.

두 번 다 글을 성실하게 이어가지 못 했던 이유를 생각 해보니, 블로그의 목적을 정하지 않고 시작해서 실패 했다는 결론을 내렸습니다.

그래서 이번 블로그에서는 목적을 정하기로 했습니다. 목적은 글을 써야할 주제들을 선정할 때 큰 도움을 줄 것이라고 생각했습니다.

목적을 정하기에 있어 임백준님의 칼럼의 도움을 많이 받았습니다. 칼럼의 내용 중 목적 설정에 도움이 된 문장을 적어보겠습니다.

어떤 일이 일어나지 알 수 없는 미래에 대한 두려움을 해소하자.
더 많이 알수록 자기가 모르는 것이 얼마나 많은지 알게 되는 것이 개발자의 숙명이다.
많은 내용을 다 알고 있는 사람이 존재하지 않는다는 사실을 깨달으면 된다.
개발자 중에는 자기가 얼마나 모르는지 모르는 사람, 그래서 공부의 필요성조차 느끼지 못하는 사람이 80% 이상이다.
깊이 아는 사람은 넓게 알지 못하고 넓게 아는 사람은 깊이 알지 못한다. 이 원리를 초월하는 사람은 세상에 없다.
자기가 이미 하고 있는 분야, 혹은 잘 알고 있는 분야에 집중해서 우물물을 파듯 최대한 깊이 들어가라. 들어가서 물이 아니라 원리(principle)를 퍼 올려라. 그렇게 퍼 올린 원리를 조금씩 다른 분야에 적용해보라. 하수는 자잘한 구현에 집중하고 고수는 언제나 원리에 집중한다는 사실을 기억하라.

마지막 문장이 목적의 핵심이 되는 문장입니다.

About

Mon, 01 Jan 0001 00:00:00 +0000

about