Epilogue

코드 짜는 비용이 0에 가까워질수록 비싸지는 것들

Wed, 29 Apr 2026 16:00:00 +0000

“코드리뷰는 너무 오래 걸린다”는 말을 들을 때마다 그래도 해야 한다고 했다. 테스트코드도 중요하다고 했다. 기본기 이야기를 많이 했다.

그런데 막상 AI가 등장하고 나서, 테스트코드는 예상보다 빠르게 해소됐다. AI가 테스트를 꽤 잘 작성해준다. 하지만 코드리뷰는 오히려 더 어려워졌다. AI가 짠 코드가 많아지면서 리뷰해야 할 양은 늘었고, 코드를 충분히 이해하지 못한 채 올라오는 PR도 생겼다. 병목이 심해졌다.

지난주에 GeekNews 위클리를 읽다가 Kernighan의 법칙을 인용한 문장이 눈에 박혔다. 디버깅은 코딩보다 두 배 어렵다. AI가 코딩을 빠르게 대신하고 있다면, 검증의 난이도는 상대적으로 더 높아진다는 이야기다.

맞는 말인데, 읽으면서 드는 생각은 조금 달랐다. 검증이 어려워진 것보다, 빠르게 만들 수 있게 되자 확인하는 단계를 건너뛰게 됐다는 것이다.

AI 리뷰 도구가 높은 점수를 준 PR이 있었다. 나는 바빴고, 작업자는 “잘 동작한다”고 했다. 그게 전부였다. 한 달쯤 후에 다른 기능을 작업하다가 그 PR의 선택이 약간 걸림돌이 됐다. 치명적인 건 아니었지만, 점수 말고 다른 질문을 한 번이라도 했더라면 피할 수 있는 부분이었다.

뭘 물어봤어야 했을까. 왜 이렇게 짰는지. 일정 압박 때문은 아닌지. 더 나은 방법을 알면서도 포기한 건 아닌지. AI는 코드가 테스트를 통과하는지, 컨벤션에 맞는지는 판단할 수 있다. 하지만 그 선택 뒤에 있는 맥락은 알 수 없다.

코드 수준만의 이야기도 아니다. 구현이 빨라지다 보니 “정말 필요한 기능인가”를 충분히 묻지 않고 개발이 늘어나기 시작했다. 만들 수 있으니까 만들게 된다. 어설픈 검증으로 쌓인 기능들은 결국 고객을 피로하게 만든다.

빠르게 할 수 있게 되자, 확인하는 단계가 비싸 보이기 시작했다.

마틴 파울러가 세 가지 부채를 이야기했다. 기술 부채는 코드의 문제고, 인지 부채는 팀의 공유된 이해가 사라지는 문제고, 의도 부채는 왜 이 시스템이 이렇게 만들어졌는지 기록이 없는 문제다. AI가 빠르게 코드를 만들수록 인지 부채와 의도 부채가 더 빠르게 쌓인다.

반응은 양 극단으로 갈리는 것 같다.

어떤 회사들은 아예 AI가 리뷰하고 AI가 approve까지 한다고 들었다. 실행력이 더 중요한 곳에서는 이쪽으로 가게 될 것 같다. 반대로 AWS는 한때 코드리뷰를 생략하는 방향으로 갔다가 다시 시니어가 반드시 코드리뷰를 해야 하는 구조로 바뀌었다고 한다. 안정성이 더 중요한 회사에서는 사고 하나로 신뢰를 꾸준히 잃어가기 때문이다.

어느 쪽이 맞는지는 모르겠다. 다만 두 선택 모두 의식적인 결정이라는 점에서는 같다. 그 중간 어딘가에서 아무 생각 없이 흘러가는 게 가장 위험할 것 같다.

Addy Osmani가 70% 문제라는 표현을 썼다. AI가 70%를 만들고 나머지 30%의 품질을 판단하는 건 사람이라는 이야기다.

그 30%가 새로 생긴 일처럼 느껴졌다. 그런데 생각해보니 아니었다. 왜 이렇게 구현했는지 물어보는 것. 이 선택이 다음에 어떤 영향을 줄지 짚어보는 것. 코드가 동작한다는 것과 잘 만들었다는 것의 차이를 구분하는 것. 이 기능이 지금 만들어져야 하는가를 묻는 것. 이건 AI가 등장하기 전에도 시니어가 해오던 일이었다.

바뀐 건 그 30%에 가격표가 새로 붙었다는 것이다. AI가 70%를 담당하면서 이 확인들의 비용이 상대적으로 더 비싸졌다. 건너뛰기도 더 쉬워졌다.

기본기가 뭔지 잘 모르겠다는 생각이 든다. 늘 중요하다고 했는데, 막상 AI 시대가 오니 어떤 건 해소됐고 어떤 건 더 어려워졌다. 다만 그 30%의 자리, 건너뛰기 쉬운 것들을 건너뛰지 않는 자리는 기본기의 일부인 것 같다.

그래서 나는 앞으로 이런 질문을 하려고 한다.

코드 수준에서: 왜 이런 코드를 짜게 됐는가. 일정의 압박 때문은 아니었는가. 관성적으로 존재하는 아키텍처를 그냥 고른 건 아닌가. 타협하진 않았는가.

기능 수준에서: 이 기능이 지금 정말 필요한가. 어설픈 완성도로 전달됐을 때 고객이 얻는 게 있는가.

이 질문들은 AI 점수가 아무리 높아도 대신 해줄 수 없다. 그걸 발견하는 데 꽤 오래 걸렸다.

BuildKit Secret Mount로 Docker 빌드 보안 강화하기

Sun, 11 Jan 2026 01:00:00 +0000

이전에 Docker 멀티 스테이지 빌드에 대해서 알아보자라는 글에서 멀티 스테이지 빌드를 활용해 민감 정보를 최종 이미지에서 제거하는 방법을 다뤘었다.

하지만 기존 방식에는 한 가지 문제가 있었다.

기존 방식의 문제점

이전 글에서 사용했던 방식을 다시 보자.

ARG GITHUB_USERNAME
ARG GITHUB_PERSONAL_ACCESS_TOKEN
RUN echo "machine github.com\nlogin ${GITHUB_USERNAME}\npassword ${GITHUB_PERSONAL_ACCESS_TOKEN}\n" > ~/.netrc

이 방식은 멀티 스테이지 빌드 덕분에 최종 이미지에는 민감 정보가 포함되지 않는다. 하지만 문제는 빌드 레이어 캐시에 민감 정보가 남을 수 있다는 점이다.

Docker는 각 명령어를 레이어로 저장하는데, ARG와 RUN 명령어가 실행된 레이어에 토큰 정보가 그대로 남게 된다. docker history 명령어로 확인하면 해당 값이 노출될 수 있다.

BuildKit의 –mount=type=secret

Docker BuildKit은 이 문제를 해결하기 위해 --mount=type=secret 기능을 제공한다. 이 방식은 시크릿을 빌드 시점에 임시로 마운트하고, 빌드가 끝나면 레이어에 전혀 남지 않는다.

개선된 Dockerfile

# syntax=docker/dockerfile:1
# 첫 번째 스테이지: 빌드 환경 구성
FROM python:3.9 AS builder

WORKDIR /app

# Secret mount를 사용하여 .netrc 파일 생성 및 의존성 설치
# --mount=type=secret으로 마운트된 파일은 레이어에 남지 않음
RUN --mount=type=secret,id=netrc,target=/root/.netrc \
    pip install pipenv

COPY Pipfile* /app/
RUN --mount=type=secret,id=netrc,target=/root/.netrc \
    pipenv install --system --deploy --ignore-pipfile

# 두 번째 스테이지: 런타임 환경 구성
FROM python:3.9-slim

WORKDIR /app

# 빌드 환경에서 설치한 의존성 복사
COPY --from=builder /usr/local /usr/local

# 애플리케이션 코드 복사
COPY . /app/

CMD ["python", "manage.py", "runserver"]

빌드 명령어

시크릿 파일을 생성하고 빌드 시 전달한다.

# .netrc 파일 생성
echo "machine github.com
login ${GITHUB_USERNAME}
password ${GITHUB_PERSONAL_ACCESS_TOKEN}" > .netrc

# BuildKit 활성화 후 빌드
DOCKER_BUILDKIT=1 docker build \
  --secret id=netrc,src=.netrc \
  -t myapp:latest .

# 빌드 후 로컬 .netrc 파일 삭제
rm .netrc

기존 방식 vs BuildKit Secret Mount

구분	기존 ARG 방식	BuildKit Secret Mount
최종 이미지	민감 정보 없음	민감 정보 없음
빌드 레이어 캐시	민감 정보 남음	민감 정보 없음
docker history	토큰 노출 가능	노출 없음
설정 복잡도	낮음	약간 높음

Docker Compose에서 사용하기

Docker Compose v2에서도 build secrets를 지원한다. docker-compose.yml에서 다음과 같이 설정할 수 있다.

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      secrets:
        - netrc

secrets:
  netrc:
    file: .netrc

빌드 시 Compose가 자동으로 시크릿을 전달한다.

# .netrc 파일 생성
echo "machine github.com
login ${GITHUB_USERNAME}
password ${GITHUB_PERSONAL_ACCESS_TOKEN}" > .netrc

# Docker Compose로 빌드
docker compose build

# 빌드 후 .netrc 삭제
rm .netrc

환경 변수로 시크릿 전달하기

파일 대신 환경 변수에서 직접 시크릿을 가져올 수도 있다.

secrets:
  netrc:
    environment: NETRC_CONTENT

이 방식은 CI/CD 환경에서 파일을 생성하지 않고 바로 환경 변수로 전달할 때 유용하다.

실제 적용 후기

기존 ARG 방식을 사용하면서 “최종 이미지에는 안 남는다지만, 빌드 캐시에는 남아있지 않을까?” 하는 찜찜함이 있었다. 실제로 확인해보니 그 우려가 맞았고, --mount=type=secret 옵션을 통해 이 문제를 깔끔하게 해결할 수 있었다.

설정이 조금 더 복잡해지긴 하지만, 보안 측면에서 확실히 안심이 되는 방식이다.

마무리

보안은 “최종 결과물만 안전하면 된다”가 아니라 전체 과정이 안전해야 한다. BuildKit의 secret mount는 빌드 과정에서도 민감 정보가 노출되지 않도록 보장해준다.

참조 사이트:

2025년을 돌아보며

Thu, 08 Jan 2026 14:50:00 +0000

어느 순간부터 회고를 작성하지는 않았는데 왜인지 2025년은 되돌아보고 싶었다.
Cursor 돌풍에서부터 Claude Code, Codex 등.. AI로 바이브 코딩 돌풍도 불었고, 나의 용도 변경이 자주 발생했던 해였다.

돌아보면 성장통의 해였다.
힘들었지만, 그만큼 배운 것도 많았던 한 해를 정리해본다.

갑작스러운 리더십 전환

1월 초에 글로벌 서비스를 개발하는 스쿼드에 참여했다.
2024년 말에 급하게 기존 서비스에 만들었던 글로벌 서비스를 신규 글로벌 레포에 격리시켜 구현하는 작업을 했는데, 꽤 많은 고생도 하고 야근도 하고 주말 출근도 했었다.
고생 끝에 런칭을 마쳤을 때는 나름의 성취감이 있었다.

그러다 3월이 되는 시점에 내가 속한 서비스 파트의 파트리드가 정리해고로 퇴사하게 되었다.
이미 2023년에 희망퇴직으로 진행된 정리해고가 한 번 있었기 때문에, 1년 몇 개월 만에 발생한 정리해고로 인해 사기가 꺾였다. 심적으로 힘든 시기였다.

내가 맡은 건 이 분들이 그럼에도 일에 더 집중할 수 있도록, 회사로 인해 겪은 상처를 극복할 수 있도록 돕는 것이었다.
업무에 집중할 수 있도록 스쿼드 외적인 업무를 도맡아했고, 원온원을 통해서 다양한 문제들을 들어줬다.

다만 스쿼드 중심이라는 미션 조직으로 힘이 쏠려 있기 때문에 기능 조직의 파트장이 해줄 수 있는 것은 별로 없었다.
중간의 중간 관리자이기에 힘도 별로 없었다. 그렇지만 최대한 이야기를 듣고, 해소해줄 수 있도록 팀 리더와 스쿼드 PO에게 자주 전달했다.

롤러코스터 같은 역할 변화

2025년 한 해 동안 내 역할은 계속 바뀌었다. 생각해보면 입사하고 3년간 계속 역할이 바뀌었다.

맡은 일은 누군가는 해야 한다는 생각이었기에, 필요하다면 다 했다.
원래 리더십과 매니지먼트에도 관심이 많았고, 반대로 개발 자체도 재밌기에 어떤 역할이든 좋고 잘 할 수 있다고 생각하고 있다.

올해만 생각해도 처음엔 글로벌 서비스를 런칭하고 있었고, 파트리드를 맡았고, 연말에는 다시 커머스와 광고 영역을 맡은 스쿼드에 개발자로 참여하게 되었다.

파트리드를 맡은 시점에도 생각이 많았다.
파트라는 개념이 있다는 것은 파트마다 경계가 있다는 이야기인데, 백엔드 개발 인원은 충분하지 않기 때문에 파트의 개념을 없애야만 했다.

어느 시점엔 파트도 없는데 존재하는 파트 리드가 되어 있었다.
그럼에도 원온원과 팀 평가 등은 해야 하고, 기술적인 리더십은 가져야 하는.. 조금은 이상한 매니지먼트를 해야 했다.

이 과정에서 허무함을 많이 느꼈다.
내가 소속되지 않은 파트의 업무를 해야 하는 상황도 있었고, 이 회사에서 나의 쓰임이 다 되어가는 것 같다는 생각도 들었다.

연말에 다시 IC로 돌아갔을 때는 복잡한 심정이었다.
어설프게 리드를 맡는 것보다는 홀가분했지만, 낯선 파트의 개발을 해야 한다는 점은 걱정이 되었다.
무엇보다 지쳐 있었다.

AI와 개발 방식의 변화

어느덧 바이브 코딩이 유행이 되었다.
처음엔 ChatGPT로 묻고 붙여넣는 수준의 코드들이었는데, 이제는 프로그래밍 언어를 타이핑하지 않는 수준까지 왔다.

팀원들의 생산성이 오른 만큼 봐야 할 리뷰는 늘었고, 품질을 더 신경 쓰게 되었다.
어떤 경우에는 고민도 없이 작성한 코드 때문에 리뷰를 하는 게 맞는지 회의감이 들기도 했다.

그럼에도 생산성을 위해 고심했다.
다양한 Agent를 대응할 수 있도록 Custom Instruction을 레포별로 세팅하고자 했고, 해당 문서에 컨벤션을 잘 살려서 코딩을 할 때도, AI가 코드 리뷰를 할 때도 도움이 되도록 세팅했다.

여전히 풀어야 할 숙제가 있다. 가드레일도 잘 설정해야겠다.

AI를 잘 쓰기 위해 다양한 편법을 많이 활용하고자 했는데, 날이 갈수록 LLM 자체가 성능이 좋아져서 고생한 보람이 없을 만큼 개선이 빨라졌다.
유행도 계속 바뀔 것 같지만 (지금 글을 쓰는 중에도 Claude Code보다 OpenCode가 낫다는 이야기가 나오고 있다) 아직은 승자는 없다는 생각에 Claude Code를 위주로 뚝심 있게 사용해보고자 한다.

2026년에는…

2026년에는 조금 더 내면의 안정감을 찾고 싶다.

AI도 더 잘 활용하려 한다.
일자리를 없애는 도구가 아니라, 나를 더 특별한 사람으로 만들어주는 도구로 쓸 생각이다.
협업에서 더 잘 쓸 수 있는 방법을 찾아 공유하고, 함께 할 수 있는 환경을 만들어가려 한다. AI에 대한 마인드셋도 정비할 필요가 있다.

그리고 업무와 상관없이 1인 개발자로서 뭔가를 만들어보려 한다.
사이드 프로젝트를 통해 순수하게 개발하는 재미를 되찾고 싶다.

새로운 시작이 필요한 시점이다.
시장이 좋은 상황은 아니지만, 새로운 거처를 찾아보고 싶기도 하다.

어떤 형태가 되든, 2026년은 조금 더 나다운 한 해가 되길 바란다.

1년에 글 하나는 써야겠다는 마음으로

Sun, 27 Jul 2025 14:55:00 +0000

오랜만에 블로그 테마를 업데이트했다. 뭐 특별하게 아름답게 바꾸거나 하진 않았다.
v0에서 프롬프트를 요청해서 기본 레이아웃을 만들었고, Claude Code를 이용해서 블로그 프로젝트에 맞게 코드를 수정했다.

나는 에디터를 거의 켜지 않고 LLM을 이용해서만 코드를 작성했다.
그래서 더 빠르게 개발할 수 있었냐고 하면 편했지만 빠르다고 보긴 어려웠다.
하지만 개발에 대한 플래닝을 하면 LLM이 먼저 공식 도큐먼트를 검색하고, 작업할 내용을 정리하고, 로컬에서 돌아가지 개발 환경까지 동작하도록도움을 받았다.
커밋과 푸시도 직접 하고 GitHub Actions에서 실패한 로그까지도 LLM이 알아서 확인하고 해결해줬다.
가끔은 완전히 엉뚱한 방향으로 문제를 해결하려고 해서 /clear 명령어를 통해 리셋을 해줘야 했지만, 그럼에도 불구하고 꽤 유익한 경험이었다.
아직은 어린 아이를 어르고 달래는 느낌으로 많은 기다림이 필요하지만 앞으로의 개발에 변화가 있을 것 같다는 생각이 든다.

물론 부작용도 큰 것 같다.
코드를 리뷰할 때 LLM으로 작성한 코드가 많이 보인다. 문제는 가끔 아쉬운 코드가 발견되는데 물어보면 작성자가 AI의 코드를 검수하지 않고 리뷰를 요청해서 발생하는 경우가 있다.
결국 나는 AI의 코드를 리뷰하는 리뷰어가 되어버렸다. 물론 AI가 작성한 코드가 항상 나쁜 것은 아니다. 하지만 AI가 작성한 코드를 검수하지 않고 리뷰를 요청하는 것은 문제가 있다고 생각한다.

요즘 내가 하고 있는 고민은 AI가 코드를 비교적 빠르게 작성해주기 때문에, 리뷰를 하면서 컨벤션이나 코드 품질을 높이는 것에 집중하는 것이 좋을지, 테스트코드에 따라 동작을 잘하고 성능이나 운영에 문제만 없다면 코드가 조금 아쉽더라도 용인하는 것이 좋을지에 대한 고민을 하고 있다.
결국은 사람이 운영하기 때문에 코드 품질이 여전히 중요하다고 생각하지만, 이제는 장애가 발생해도 코드를 빨리 읽고 에러를 빨리 찾는 것을 AI가 대신 할 수 있는 상황이 오지 않을까 하는 생각도 들고 있다.
그럼에도 아직은 사람이 코드를 작성하고, 리뷰하고, 운영하고 있기 때문에 코드 품질을 유지하는 것이 중요하다고 생각한다.

이런 고민들이 있음에도AI가 코드 작성에 도움이 되고 그 덕에 이것저것 만들어보는 재미가 생긴 것도 사실이다. 간단한 사이드 프로젝트를 만들거나, 운영 업무에 필요한 간단한 도구를 만들 때 AI가 큰 도움이 되고 있다.

AI는 컨텍스트가 더 중요하다는 이야기를 한다. 그럴 수록 더 자세한 커밋과 테스트코드가 코드 내의 중요 컨텍스트가 될 것 같다.
나 같은 경우에는 아예 LLM 가이드 라인 문서에 꼭 코드를 추가할 때는 테스트케이스를 작성하고, 실제로 테스트가 통과하는지 확인하고 커밋을 자세히 작성하라고 명시해두었다.

올 해는 블로그 업데이트를 잘 하지 않았는데, 이제는 AI가 대부분의 검색을 대체하고 있기 때문에 블로그에 글을 쓰는 것에 대한 동기부여가 많이 떨어진 것 같다.
또, 그렇게 얻은 정보들은 빠르게 휘발되고 또 AI에게 물어보고를 반복하고 있다보니 블로그에 글을 잘 안쓰게 되는 것 같다.

그래도 가끔 내가 내 글을 찾아보면서 도움이 되는 경우도 있기 때문에 한번씩 블로그를 써야겠다는 생각은 하고 있다.
다만, 형식을 갖추고 글을 쓸 필요가 있을지에 대한 생각은 든다. 그냥 필요한 내용을 메모처럼 남기는 정도로 바뀌어야 할지도 모르겠다.

아무튼 오늘은 여기까지. 메모를 남기는 것 처럼 더 편하게 글을 쓰는 방향으로 바꿔야 할 것 같다.
그리고 최근에 리더십에 대한 고민이 많이 생겼는데, 사적인 영역의 고민이 많아서 블로그에 쓰기에는 적절하지 않은 것 같다.
그러다보니 글 쓰는게 참 쉽지가 않다. 그래도 1년에 글 1개는 쓰고 싶어서 오늘 이렇게 글을 남긴다.

터미널에서 관리자 비밀번호 대신 Touch ID 로 로그인하기

Sat, 16 Nov 2024 01:40:00 +0000

터미널에서 관리자 패스워드가 필요한 경우 매번 입력하기 귀찮을 때가 있다. Touch ID 로 로그인하는 방법을 알아보자

방법은 간단하다. /etc/pam.d/sudo 파일에 Touch ID 인증 모듈을 추가하면 된다. 단, 관리자 권한이 필요하므로 sudo로 접근하여 Overwrite 하거나 사전에 권한을 755 정도로 바꾼 다음 다시 권한을 수정해줘야 한다.

다행히도 sudo 를 통해서 vi로 접근했을때 overwrite(!)가 가능해서 나는 이 방법을 통해서 수정하였다.

sudo vi /etc/pam.d/sudo

auth       sufficient     pam_tid.so

이 문구를 2번째 라인에 추가한다. 그리고 overwrite로 저장한다 (:w!)

최종 완료된 예시

auth       sufficient     pam_tid.so
auth       include        sudo_local
auth       sufficient     pam_smartcard.so
auth       required       pam_opendirectory.so
account    required       pam_permit.so
password   required       pam_deny.so
session    required       pam_permit.so

이렇게 터미널에서 매번 관리자 패스워드를 입력할 필요 없이 Touch ID를 이용해 간편하게 인증할 수 있다.
나의 경우는 Touch ID가 없는 맥북에서는 설정하지 않고 주로 노트북으로 작업하는 서브용 맥북 에어에 설정해서 사용하고 있다.

만약 모니터를 덮었거나 해서 Touch ID를 사용할 수 없는 경우에 Touch ID로 설정한 경우 확인 다이얼로그에서 패스워드를 입력하거나 Apple Watch로 비밀번호를 해제할 수도 있다.

Docker 멀티 스테이지 빌드에 대해서 알아보자

Sat, 15 Jul 2023 01:40:00 +0000

도커를 통한 서비스를 배포해 본 경험이 있다면 은근히 빌드한 이미지의 용량을 줄이는 것에 대해서 스트레스를 많이 겪었을 것이다.
예전에는 별도의 빌드용 도커파일과 그 빌드용 도커파일이 만든 이미지를 베이스로 다시 도커파일로 경량화 된 아웃풋을 만들어주는 방법을 많이 사용했었는데 우연히 지인을 통해 도커에 멀티 스테이지 빌드 방식이 있다는 것을 알게 되었다.
이 방법을 이용하면 굳이 불필요하게 도커 파일을 여러개를 관리 할 필요 없이 의존성 주입 단계와 런타임용 이미지를 만드는 단계를 하나의 도커파일로 관리할 수 있다.

나의 경우 참조해야 하는 파이썬 패키지 중 일부가 GitHub의 Priviate Repo에 있어서 GitHub 민감 정보도 함께 주입을 해야 하는 경우가 있는데, 이럴 때도 멀티 스테이지 빌드를 쓰면 최종 결과물에는 민감 정보가 넘어가지 않아 온전히 빌드 단계에서만 민감 정보를 참조하고 버릴 수 있어서 장점이 있었다.

물론 장점만 있는 것은 아니다. 도커파일이 복잡해진다. 스테이징 별로 AS를 이용하여 별명을 지정해야 하고 여러 단계를 거치기 때문에 어느 시점에 --from=AliasName 이 붙는지 흐름도 봐야한다. 빌드 시간도 서로 블로킹이 없는 부분까지는 비동기로 진행되지만 빌드 시간이 더 걸릴 수 있다.

아래 예시는 GitHub 민감 정보를 주입했고, 이를 통해 Pip 파일의 의존성 패키지를 모두 빌드 한 뒤 종료한다.
이후 runtime 용 도커 파일 라인에서 COPY –from=builder를 통해 빌드 스테이지에 /usr/local 파일을 복제하여 빌드된 결과물을 가져온다.

# 첫 번째 스테이지: 빌드 환경 구성
FROM python:3.9 AS builder

WORKDIR /app

# Inject GitHub credentials for private repos
ARG GITHUB_USERNAME
ARG GITHUB_PERSONAL_ACCESS_TOKEN
RUN echo "machine github.com\nlogin ${GITHUB_USERNAME}\npassword ${GITHUB_PERSONAL_ACCESS_TOKEN}\n" > ~/.netrc

# Pipenv 설치
RUN pip install pipenv

# Pipfile 복사 후 의존성 설치
COPY Pipfile* /app/
RUN pipenv install --system --deploy --ignore-pipfile

# 두 번째 스테이지: 런타임 환경 구성
FROM python:3.9-slim

WORKDIR /app

# 빌드 환경에서 설치한 의존성 복사
COPY --from=builder /usr/local /usr/local

# 애플리케이션 코드 복사
COPY . /app/

CMD ["python", "manage.py", "runserver"]

도커 파일에서 사용하는 이미지를 보면 알겠지만 python:3.9이미지를 쓰다가 python:3.9-slim을 기준으로 의존성 패키지만 복제해서 최종 결과물을 내놓는다.
이를 통해 조금 더 경량화 된 이미지를 기반으로 런타임용 이미지를 만들 수 있었다.
주의 해야 할 점은 RDB 등을 사용하면 DB 클라이언트 라이브러리가 필요할 수 있는데 이 부분은 직접 잘 챙겨봐야 한다.

참조 사이트: Docker Docs

macOS에서 아이폰 백업 디렉토리를 외부 폴더로 옮기기

Sun, 04 Jun 2023 14:48:00 +0000

맥에서 파인더로 아이폰을 백업하게 될 경우 맥의 저장공간 때문에 아이폰 백업이 어려운 경우가 있다.

이럴 땐 넉넉한 용량을 가진 외장 하드나 NAS에 저장하면 된다. 대신 백업 경로를 따로 지정해줄 수 없어서 기존 백업 경로를 심볼릭 링크로 연결해주면 된다.

터미널 앱을 열고 다음과 같이 명령어를 입력해주면 된다.

ln -s <외부 볼륨> ~/Library/Application\ Support/MobileSync/Backup

Tip: 터미널에 외부 경로를 가져오기 어려운 경우 그냥 터미널 창에 파인더에 열어둔 외부 경로의 디렉토리를 복사해서 붙여넣으면 경로가 복사가 된다.

실제 사용해 본 결과 외장하드나 나스로 백업을 할 경우 너무 오래 걸리고, 외장 SSD 정도는 되어야 조금 덜 답답할만큼의 백업 성능을 보이니 참조하면 좋을 것 같다.
체감상 맥 내장 SSD > 외장 SSD > 외장 하드 > 나스 순 이었음. 아무래도 개별 조각파일이 많아서 더더욱 하드 성능이 영향을 미쳤던 것으로 보인다.

TablePlus 앱에서 aws session manager 접속이 안되는 문제

Tue, 30 May 2023 12:52:00 +0000

회사에서는 JetBrains 지원을 해주기 때문에 DataGrip을 사용하고 있지만 개인적으로는 TablePlus를 사용하고 있다. 그리고 더 이상 PEM키를 발급받아 서버 인증을 하지 않고 AWS Session Manager를 통해서 ssh를 접근하고 있는데 이때 터널링을 하기 위해 ssh_config에서 ProxyCommand에 ssm을 호출하여 접근할 수 있도록 설정하고 있다.

근데 TablePlus에서는 이게 적용이 안되는 문제가 발생해서 찾아보니 Debug 모드로 실행해보라고 했고, 놀랍게도 Debug 모드에서는 잘 접근이 되었다.

많은 검색 끝에 ProxyCommand에 패스를 잡아주니 해결이 되었다.

원인은 모르겠지만 그냥 실행할때는 잡히던 패스가 TablePlus 에서 실행할때는 잡히지 않는 문제였던 것 같다.

Host hostname
    ProxyCommand sh -c "PATH=/usr/local/bin:$PATH aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

apple slicon의 경우 PATH가 아래와 같음

Host hostname
  ProxyCommand sh -c "PATH=/opt/homebrew/bin/:$PATH aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

Git 원격 기본 레포 자동으로 설정하기

Tue, 30 May 2023 12:42:00 +0000

늘 별 생각없이 git push origin으로 push를 하면 아래와 같이 원격지를 설정하라는 안내를 받게 된다.

fatal: The current branch feature/branch_name has no upstream branch. To push the current branch and set the remote as upstream, use

git push –set-upstream origin feature/branch_name

이럴때 곧이 곧대로 원격지를 --set-upstream {remoteName} {branchName}으로 설정을 했었다.

근데 최근에 안내 메세지를 보니 다음과 같은 안내가 추가 되었다.

To have this happen automatically for branches without a tracking upstream, see ‘push.autoSetupRemote’ in ‘git help config’.

뭔가 새로운 옵션이 생긴 것 같아 확인해보니 git v2.37 버전부터 존재하는 기능인듯 하다. (릴리즈 노트에서 안보이는데 대부분의 페이지에서 그렇게 언급하고 있다.)
실제 동작은 push.default current 로 하는 것과 동일해보였다.

아래와 같이 push.autoSetupRemote 값을 true로 설정하면 된다. (repo 별로 설정을 다르게 하고 싶다면 –global 은 생략)

git config --global --add push.autoSetupRemote true

참고 링크

git-scm: push.autoSetupRemote

다섯 분의 온보딩을 마치며..

Fri, 19 Aug 2022 12:16:00 +0000

이직을 한지 얼마 안되었다고 생각했는데 벌써 한달 뒤면 버드뷰에 입사한지도 1년이 된다.

처음 계획은 개발 문화와 리더십에 대해서 경험해보고자 했는데 시기가 맞지 않아 명시적인 리더십 역할은 맡지는 못했다.
대신 개발 문화를 이끌고 지원하는 업무를 맡았고 이 일에 대해서는 리더십을 가지고 있다.

좋은 개발자를 뽑는 것도 중요하지만 이 분들이 제 역량을 뽑아낼 수 있도록 잘 적응하게 하는 것도 중요하다고 생각한다. 나는 예전부터 온보딩과 개발 문화에 관심이 많아서 이 일이 재미있다.

버드뷰 백엔드 팀은 4주차에 대한 온보딩 과정을 계획하고 있다. 4주차의 공통 온보딩 이후에는 각 미션 조직에 합류하여 온보딩을 한다.
나는 공통 온보딩 안내 과정을 맡고 있다.

간단하게 내가 개선했던 온보딩들을 설명하려고 한다.

1. 온보딩을 위한 체크리스트 (시각화)

신규 입사자가 오면 잘 적응하고 있는지 확인을 해야하는데 시각화가 잘 되지 않아서 알기 어려운 점이 많았다.
온보딩기간에 진행하게 되는 공통 과정은 스프레드 시트를 이용해 스스로 체크할 수 있도록 체크리스트를 만들었다.
이후에는 진척을 한눈에 볼 수 있어서 각각 잘 적응하시는지 또 불편한 포인트가 어떤 부분인지 확인할 수 있어서 좋았다.

2. 온보딩 문서 현행화

대부분의 온보딩은 문서로도 충분히 이해할 수 있도록 하기 위해서 팀에서 노력을 하고 있다. 문서화가 잘 된 팀이라고 자부하고 있는데 그래도 현행화가 잘 되지 않아서 어려운 지점이 종종 있다.
이런 문제를 해결하기 위해 나는 항상 신규 입사자분들에게 문서가 현행화가 되어있지 않다면 직접 업데이트하거나 업데이트 할 수 있도록 알려달라고 말씀을 드린다.
신규 입사자가 입사한 기간이 온보딩 문서를 최신화 할 수 있는 기회이기 때문에 놓치지 않으려고 노력한다.

3. 3. 3. Q&A 시간 및 시간 확보

입사 하면 궁금한 것도 많지만 다들 바빠보이고 질문하기 어려운 경우가 많다. 특히 재택근무를 도입한 지금은 어떤 분에게 질문을 해야할 지 고민되는 부분이 많을 수 밖에 없다.
그래서 새로 오신 분들에게 질문할 수 있는 시간을 충분히 할애하고 있다.
예를 들면 매일 오전 11시 부터 30분간은 질문을 할 수 있는 시간으로 비워두겠다고 약속한다. 이 시간에 질문 할 게 없다면 그냥 간단한 수다 시간을 가진다.

이를 통해 심리적 안정감도 드리려고 노력하고 있다. 재택 근무 중 고립감을 느끼지 않도록 하기 위해서 종종 헬스체크로 티타임을 가지기도 했다.

마치며

뭔가 거창한 이야기를 하려고 시작했는데 써보니 별게 없다.
팀 내 칭찬 문화가 있는데 온보딩 기간때 칭찬을 많이 확보하는 것도 보람차다.

사실 칭찬 받는 것보다 온보딩에서 가장 보람찬 부분은 신규 입사자분들께서 잘 적응하고 업무하는 모습을 볼 때인데
입사하신 분들 모두 잘 적응하셔서 각자의 조직에서 활약하고 있는 것을 보면 뿌듯하고 기분이 좋다.

이제 나만 잘하면 되는데… 엥..