2016년의 작은 기록들

2016년 4월, “개발이나 여행이나 이것저것 적는 메모장”으로 블로그를 열었어요. 첫 글들은 완성된 에세이라기보다 그날 시작한 일과 나중에 더 알아볼 질문을 붙잡아 둔 메모에 가까웠습니다. 흩어져 있던 짧은 글을 지금 다시 읽을 수 있도록 한곳에 모았습니다.

봄에 시작한 것들

처음 자전거로 오류역에서 신촌역까지 출근했을 때는 한강을 따라 약 1시간 40분을 달렸어요. 꽤 긴 거리였지만 봄바람과 꽃 덕분에 길이 지루하지 않았다는 기억이 남아 있습니다.

회사에서는 Android에 이어 iPhone 앱도 맡게 되어 Swift를 처음 살펴보기 시작했고, 교회에서 일렉기타를 치다가 통기타 온라인 강의도 등록했어요. 필요한 순간에 다시 볼 수 있다는 점이 온라인 수업의 장점으로 느껴졌습니다. 개발과 취미 모두 “일단 시작하고 배우면서 채운다”는 방식이 닮아 있었어요.

가르치며 배운 것

비전공자를 위한 Android 프로그래밍 강의를 준비하면서는 아는 것과 설명할 수 있는 것이 다르다는 걸 확인했습니다. 첫 수업 뒤에는 다음 기준을 적어 두었어요.

• 학습자가 비전공자라는 사실을 설명의 출발점으로 삼기
• 전체 순서와 쉬는 시간, 질문 시간을 먼저 안내하기
• 예제 코드를 실행하기 전에 무엇을 만드는지 설명하기
• 진도를 고정하고, 개념마다 따라 해볼 예제를 충분히 마련하기
• 배포 자료에서 개인 정보가 노출되지 않는지 확인하기

교회 유초등부의 종이컵 쌓기 게임, 예배 전 활동 목록, 전교인 체육대회와 성탄 전야제 계획도 비슷했습니다. 참가 인원과 시간, 준비물, 진행 순서를 먼저 나누고 현장에서 바뀔 수 있는 부분을 남겨두는 것이 중요했어요. 내용은 달라도 작은 프로그램을 운영하는 기본은 같았습니다.

초기 프로젝트에서 남은 질문

당시에는 모바일 서비스, 음악 관련 아이디어, 불법 주정차 신고 보조 앱, IT 서비스의 수익 모델처럼 여러 프로젝트를 동시에 메모했습니다. 서버 설정과 인수인계, 회의 내용도 섞여 있었지만 지금 공개 글에는 오래된 운영 정보나 담당자 정보 대신 반복해서 등장한 질문만 남깁니다.

살펴본 영역	당시의 질문	지금 남길 기준
서비스 기획	누구의 어떤 문제를 해결하는가	기능보다 사용자와 문제를 먼저 적기
수익 모델	광고·구독·중개 중 무엇이 맞는가	비용 구조와 지불 주체를 함께 보기
개발 일정	알파·베타 같은 이름을 어떻게 붙일까	명칭보다 기간과 완료 조건을 명확히 하기
인수인계	무엇을 빠뜨리기 쉬운가	실행 절차, 의존성, 복구 방법을 분리해 기록하기
실험 프로젝트	새로운 기술을 어디까지 써볼까	작은 검증 범위와 중단 기준을 먼저 정하기

특히 마일스톤을 처음 적용하며 얻은 결론은 단순했어요. 0.1, 0.2, someday처럼 칸을 나누는 일보다 각 시점까지 무엇을 왜 끝낼지 합의하는 일이 더 중요했습니다.

오래된 메모를 다시 묶으며

짧은 글 하나만 보면 덜 완성돼 보이지만, 이어서 읽으니 공통된 태도가 보입니다. 모르는 기술은 작게 시작하고, 직접 해본 뒤 피드백을 남기고, 다음번에 다시 쓸 수 있는 기준으로 바꾸려 했어요. 그때의 세부 일정은 지나갔어도 이 방식은 지금도 유효한 기록으로 남습니다.

보안과 개인정보를 위해 과거 서버 주소, 설치 환경, 담당자 이름, 이력서 이미지와 내부 업무 목록은 이 통합 글에 옮기지 않았습니다.

이어 읽기

• 개발자로 성장하며 남긴 질문들 — 2016년의 작은 시작이 이후 이직과 학습 기준으로 어떻게 이어졌는지 볼 수 있어요.
• 코드를 잃고 시작한 Git 공부 — 당시 코드 복구 경험에서 시작한 버전 관리 학습을 따로 정리했습니다.
• 스프린트를 도입하기 전에 맞춰야 할 것 — 초기 프로젝트에서 고민했던 마일스톤을 팀의 학습 주기로 확장해봅니다.