들어가기 전에
- 인턴으로 일했더라도 직장이라고 할 수 있겠지?
- 이번 회고에는 DAKI(Drop, Add, Keep, Improve) 방식을 사용한다. 아직 회고를 ‘잘’ 하는 법을 몰라서 이것저것 해보는 중.
했던 것 요약
- 매거진 리뉴얼
다노 앱에는 탭 4개가 있다. 매거진이 그 중 하나인데, 기존 매거진 사용성을 개선하기 위해 매거진을 전면 개편하기로 했다. 인턴으로 처음 맡은 업무가 바로 이 매거진 리뉴얼 프로젝트다.
인원은 프론트 1명, 서버 1명으로, 서버 쪽은 나 혼자 진행했기 때문에 많은 부분을 다뤄볼 수 있어서 몹시 몹시 몹시 좋았다.
- 기존 서비스 유지보수 + 기능 개발
매거진 리뉴얼 프로젝트 종료 이후 기존 유닛에 합류했다. 어드민 기능 추가, 어드민 사용성 개선, 서비스 버그 픽스, (소소한) 기능 추가 업무를 진행했다.
이미 돌아가고 있는 서비스에 손을 댄다는 것이 어떤 무게가 있는 일인지, 어떻게 접근해야 하는지 배웠다.
Drop, 다음에는 이러지 마
- 코드 첫 번째 줄부터 순서대로 읽어내려가기
기존 서비스 파트로 옮겨가면서 가장 부담을 느꼈던 부분은 코드를 파악하는 일이었다. 간단한 티켓을 처리하려고 해도 그 기능이 이 코드 어디쯤에 있는지, 이 함수는 어디에서 온 건지 파악을 해야 잘 돌아가던 서비스를 죽이는 일이 없을 것이다.
그래서 코드를 첫 번째 줄부터 읽었다.(그러지마) 그러다보니 하루만에 끝낼 일을 이틀, 사흘, 나흘 붙잡고 있었다. 실제 기능을 써보고 코드 어느 부분을 타는지, 어떤 함수를 어떤 순서로 호출하는지 흐름을 따라갔어야 했다. 각잡고 정독한답시고 이래저래 비효율적으로 일했다.
- 능력 밖 일도 혼자서 다 해결하려고 하기
‘삽질하는 시간만큼 실력이 는다’, ‘잠깐 고민하고 바로 물어보려고 하지말고 혼자서 해결하려고 해봐라’
안타깝게도 인턴 생활 중 상당 기간 이렇게 생각하면서 혼자 끙끙 앓았다. 좋은 말이고 맞는 말이다. 하지만 회사 일에는 약속한 기한이 있다. 주어진 일을 정확하게 처리하는 것만큼이나 약속을 지키는 것도 중요하다.
Add, 다음에는 이런 시도를 해보자
- 기한을 정하고 그 시간까지 문제를 해결하지 못하면 도움 요청하기
(Drop 두 번째 항목과 연결된다.)
내 일이니 내가 해결해야 하는 것은 맞지만 적어도 진척도나 상태는 틈틈이 공유하자.
회사는 협업으로 굴러가는 것을 명심해야 한다. 지금 어떤 일을 하고있는지, 이 일이 얼마나 걸리는지, 어디까지 진행했는지, 어디까지 알아봤는지(얼마까지 알아보고 오셨어요?), 어느 부분에서 어떻게 어려움을 겪고있는지 동료와 자주 소통해야한다. 혼자 삽질해보겠다고 끌어안고 있으면 동료는 도움을 주고싶어도 줄 수가 없다. 동료가 느끼는 답답함은 덤이고.
Keep, 이대로만 잘해다오
- 일단 해보기
매거진 프로젝트를 하면서 많은 동료에게 도움을 받았지만, 일단은 서버 파트 담당이 나 혼자였으므로 부족한 실력을 메꿀 방법은 엉덩이 붙이고 앉아있기, 될 것 같은 건 다 시도해보기 뿐이었다. 사용해야 하는 기술을 당장 이해하지는 못해도 매뉴얼 내지는 블로그 글을 보면서 직접 돌려보고 나중에 이해한 게 많았다.
하지만 이 부분은 개운치 않다. 기술을 빠삭하게 알고 쓰는 사람이랑 겉핥기로 알고 쓰는 사람은 결국 격차가 점점 벌어질텐데 시간에 쫓겨서 휘뚜루 마뚜루 쳐낸 것 같기에…
- 지독하게 매달리기
거시적으로 봤을 때 일을 잘하려면 적절한 휴식이 필수지만 아는 게 너무 없어서 없는 시간도 만들어내서 일했다.
9월 둘째 주에 매거진 프로젝트를 시작해서 11월 말 즈음에 라이브했으니 약 3개월 걸렸다. 그 3개월간 근태를 떠올려보면, 추석 연휴 출근, 한글날 출근, 토일 출근… 흑흑. 당연히 매번 이렇게 살 수는 없지만 그때는 필요하니까, 해야하니까 그렇게 했다. 너무 절실했다. 그리고 모든 것이 새로워서 짜릿하고 재미있었다.
Improve, 이번에는 아쉬웠지만 다음에는 이렇게 해보자
- 작업 소요일 예상하여 기한(due date) 산정하는 연습하기
인턴 끝까지 고전했던 부분이다. 메타인지가 떨어지는 상황에서 작업 종료 기한을 예상한다는 건 생각보다 어려운 일이었다. 설산에서 화이트아웃을 마주했는데 앞으로 얼마나 더 가야 목표 지점에 도달하는지 동료한테 무전을 쳐줘야 하는 상황 같달까…
이 부분은 CTO님이 해결책을 주셨다. 사수나 팀장에게 해당 작업 소요일 기준을 물어보는 것이다. 1. 잘하는 사람 기준 소요일 2. 보통 실력 기준 소요일 3. 이 기한을 넘기면 좀… 에 대해 의견을 듣고 잘하는 사람을 내 목표로 삼고 일을 처리하는 것이다. (물론 버그 픽스는 아삽이겠지)
- 리팩토링
많은 개발자가 가진 부채가 아닐까… 다음에는 시간을 잘 쪼개서 머리로 나는 비둘기를 날개로 나는 비둘기로 고쳐보도록 하자.
- 로그 잘 보기, 그러기 위해 길목에 print 잘 찍어두기
로그를 언제, 왜, 어떻게 봐야하는지 인턴 기간 막바지쯤 서서히 깨달았다. 이 에러 메시지를 통해 뭐가 문제인지 추론하는 것, 담당 범위 안 문제인지 다른 파트에 확인 요청을 해야하는 문제인지 판단하는 것 등을 연습했다. 진작 로그를 볼 줄 알았으면 좋았을걸!
- 지독하게 매달리되 몸을 보살피기
(Keep 두 번째 항목과 연결된다.)
다음번에는 충분히 휴식을 취하면서 완급조절을 해야겠다. 이때 요통이 너무 심해져서 한 발짝 뗄 때마다 미칠듯이 아팠고 그때부터 능률이 수직하락했다.
개발일 하루이틀하고 말 것 아니니까 매번 마지막 비명을 지르듯이 불사르지 말고 몸도 마음도 잘 돌봐야겠다. 오래오래 효율 좋은 개발자가 되고싶다.