이다은

건빵 안드팀은 이렇게 작업하고 있어요 💚🥐



저는요 지금,,

저는 현재 SOPT라는 IT 연합 동아리의 꽃인 장기 해커톤, "앱잼"을 통해 만난 건빵 팀과 함께하고 있어요,

"건빵"이라는 서비스는 개인 맞춤형 건강빵집 정보 제공 서비스로, 저는 현재 안드로이드 개발자로 참여하고 있습니다! 제가 사랑하는 2명의 안빵이들(주영, 지현)과 함께 사랑과 열정 속에서 6월부터 지금까지 건강하고 빵빵하게 개발 중에 있어요. 이 아티클에는 우리 안빵이 팀의 개발적인 협업 부분보다는 어떻게 함께 개발해왔는지를 담아볼까 해요!

처음해보는 안드로이드 리드

리드로써 팀빌딩을 마치고, 안드 노션페이지를 만들고 킥오프를 준비했던게 정말 엊그제 같아요. 그 당시에 저는 개발적으로도 리드로써도 많이 부족하다는 느낌을 많이 받았어요. 스스로에 대한 확신이 없었고, 어떻게 하는게 좋은 협업이고 좋은 리드인지 몰랐거든요. 프로젝트 세팅부터 시작해서 타파트와의 소통까지 하나하나가 저에게는 챌린지고 어려움이었요.

하지만, 전 이런 팀을 만들어나가고 싶었어요!

🔝 모두가 성장할 수 있는 팀

❓ 개인의 힘듬, 어려움, 궁금증을 편하게 말하고 질문할 수 있는 환경

🔜 명확한 계획속에서 쫓기지 않는 마김기한

✅ 철저함과 사전, 현재, 사후 checking

이외에도, 저 스스로는 팀을 관리하고 테스크를 분배할 줄 아는 힘과 논리적이고 유지.보수가 용이한 코드를 짜고 싶었고 팀원들에게는 협업이란 무엇인지를 느끼게 해주고 스스로 해내고 스스로 질문할 줄 아는 자발성, 본인의 것을 책임지는 책임감을 알려주고 싶었어요! 또한 세 명 모두 해보지 못한 것을 경험해내고 싶었어요.

그래서 우리 안빵이들과!

모두의 성장을 위해 본격적인 프로젝트를 시작하기 전, 프로젝트에 적용해보면 좋을 기술에 대해 각자 공부하는 시간을 가졌어요! 데이터바인딩, 좋은 아키텍처, coroutine 등 이번 프로젝트에 적용해보고 싶은 기술들을 공부하고 코드리뷰를 달고 이야기하는 시간을 가졌어요.

프로젝트 중에는, 모두의 성장을 위해 각 팀원의 부족한 부분을 확인하고 그 부분 위주로 task를 나눠 갖으려고 노력했어요! 뷰를 많이 안 짜본 팀원에게는 다양한 뷰를 경험해볼 수 있는 뷰를, 로직에 능숙하지 않은 팀원에게는 로직을 짜보면 좋을 뷰를 나눠주며 모두가 부족한 부분을 채워나갈 수 있도록 분배 했어요.

또한, 공유하기 페이지를 운영해 서로가 찾은 좋은 블로그, 내용 혹은 개인이 작성한 아티클 등을 공유했어요.

어려움을 말하고 질문을 편하게 하는 환경을 만들기 위해서는 일적인 이야기보다도 감정적인 소통이 필수적이라고 생각해요. 그렇기에 저희 안드팀은 정해진 회고 일정뿐만 아니라 평소에도 이야기를 많이 했어요.

안빵이 팀은 현재 KPT 회고를 진행하고 있어요! KPT 회고를 통해 스스로의 상태, 개발 습관에 대해 체크하고 앞으로 어떻게 개선해나가면 좋을지를 서로 이야기 하고 있어요!

파워 J인 저는 확실한 계획 속에서 움직이는 팀을 만들어 나가고 있어요. 또한 마감기한에 쫓기는 것은 코드 퀄리티뿐만 아니라 개인의 생활도 망친다고 생각해 마감기한에 넉넉하게 작업을 마치려고 하고 있어요.

이를 위해 우리 안빵이팀은 데드라인은 크게, 세세한 계획은 작게 세우고 있어요. 뷰 작업 데드라인, api 연동 데드라인, 1, 2차 스프린트로 전체 일정을 크게 잡고 매스프린트 첫 날 각 스프린린트에 마무리 해야할 거 같은 분량을 리드인 제가 작성해가요!( 제가 팀원들의 실력과 작업 스타일에 맞게 분배하려고 노력하고 있어요. ) 그리고 다시 팀원들이 매주 혹은 스프린트가 짧을떄는 매일의 계획을 세웁니다!

또한 안빵이팀은 코드리뷰를 중요시하기에 데드라인의 2일 전까지는 작업을 마무리하는 거를 목표로 하고 있답니다 :) 이런 계획적인 루틴 덕분에 저희 안빵이팀은 항상 넉넉하게 마감기한을 맞춰나가고 있어요! ☺️

제가 가장 중요하게 생각하고 이거 정말 우리팀 잘하고 있어!라고 자랑할 수 있는 부분인 철저함과 사전, 현재, 사후 checking이에요!

✅ 1. 흔들리지 않기 위해 가장 중요한 사전 Checking

저희 안빵이 팀은 뷰가 나오고 뷰 작업을 시작하기 전 뷰 뜯어보기와 뷰 스케치를 필수적으로 진행했어요!

뷰 뜯어보기를 통해 해당 뷰의 플로우, 챌린징 요소 등을 체크했고 뷰 스케치를 통해 뷰의 컴포넌트들을 어떤 식으로 구성할 것인지를 미리 계획했어요! 이 모든 과정은 안빵이들 모두와 이야기하며 확실히 해나가고 수정해 나갔어요. 이런 사전작업을 통해 뷰 작업할때 아예 뷰를 다시 짜는 일을 막고 더 좋은 뷰 구성에 대해 고민했어요.

특정 뷰의 로직을 고민할 때도 서로 이야기를 나누며 이런 로직이 좋은 로직일지 그리고 구현 가능성이 있는지 대해 끊임없이 사전 체크를 진행했어요 :)

✅ 2. 마감기한과 작업 속도 check를 위한 현재 Checking

사전 체킹을 통해 각자 뷰에 친숙해지고 개발 가능성을 높여 놨다면, 현재 중요한건 개발에 대한 업무 트래킹이라고 생각했어요. 업무 트래킹을 하지 않으면 마감기한을 지키지 못할 수 있고, 어려움에 있는 팀원을 발견하기 어렵기 때문에 이 부분을 매우 중요하게 생각했어요.

모든 시간을 함께한 합숙 시기와 다르게 합숙이 끝난 후 업무 트래킹은 어려워졌죠.

업무 트래킹을 위해 우리 건빵팀은,

데일리 스크럼을 초반부터 계속하고 있고, 현재는 스프린트 트래킹 보드를 만들어서 서로의 업무 정도를 파악하고 있어요!

또한 우리 안빵이 팀은,

피그마에 진행전, 진행중, 완료 태그를 만들어 뷰 구현 정도를 파악하고 있고, API 표에 구현 완료 태그를 만들어서 API 작업 정도를 파악하고 있어요. 또한 피그마에 앞으로 해야하는 모든 task를 댓글로 달아 task를 할때마다 solve 함으로써 스스로 어느정도 작업이 남았는지 확인하고 서로의 작업 속도도 확인할 수 있게 했어요. 이를 통해 빠짐 없이 꼼꼼하게 서로의 속도를 확인하고 있어요!

✅ 3. 마지막으로 서로 서로 꼼꼼하게 확인해주는 사후 Checking!

작업의 사후 체크의 끝은 코!드!리!뷰! 라고 생각해요:) 꼼꼼한 작업을 위해 코드리뷰는 매우 중요하다고 생각해요! 안빵이팀은 아주 급한 사항이 아니라면 😅 머지해도 될 정도로 완벽해졌을 때 어프룹을 남기고 머지할 수 있게 했어요!

컨벤션부터, 뷰의 구성, 로직까지 꼼꼼하게 서로의 것을 확인해요! 최근에는 스프린트가 바빠지면서, 1. 뷰 디자인 확인 2. 피알을 올린 사람이 리뷰어에게 검토 받고 싶은 부분을 작성하고, 리뷰어는 이를 바탕으로 확인! 이렇게 두 가지 스탭을 적용해 꼼꼼하게 코드리뷰를 진행하고 있어요.

우리 안빵이팀은,,

우리 안빵이팀은 오늘도 멋진 협업과 멋진 프로덕트를 위해 나아가고 있어요:) 협업을 진행하면서 아쉬운 부분도 많았지만 프로젝트 초기보다 점점 우리 모두가 성장하고 있고 프로덕트에 빠져들고 있음을 느낍니다! 전 우리 팀원들이 성장하고 있음을 느낄 때 가장 뿌듯함을 느끼는 거 같아요:) 안빵이들아! 릴리즈까지 화이팅하고 지금까지 잘해왔고! 릴리즈 이후에는 더 잘해보자!!! 고마워!!!! 곧 나올 건빵도 많이 사랑해주세요!

안빵이팀의 코드를 보고 싶다면? 🔽🔽

GEON-PPANG/GEON-PPANG-AOS: 오다은 선생님과 두 빵쪽이들 (github.com)

건빵에 더 알아보고 싶다면? 🔽🔽

gunbbang_official | Instagram | Linktree

나는 어떤 개발자가 되고 싶은가?



"나는 어떤 개발자가 되고 싶은가?" 최근 이 질문을 던지기 시작했습니다.

작년 이맘때쯤, 스스로 "난 개발자가 될 수 있을까?'라고 물었던게 생각납니다.

전 그때 개발자가 될 수 없을 거라고 생각했습니다.

겉보기에 멋있어 보였던 개발은 생각보다 너무 어려웠고

주변에 앞서나가는 사람들, 재능이 있는 사람들을 보며 부럽기만 했습니다.

이 생각은 '새로운 개발을 해보자' 라는 작은 생각으로 시작된 SOPT를 만나고 완전히 뒤바뀌게 됐습니다.

SOPT 얘기는 다른 글에서 다시 다루겠습니당,,,

이 글의 본론인 "나는 어떤 개발자가 되고 싶은가"에 대한 최근의 생각 변화에 대한 글을 시작하겠습니다!

"건빵"이라는 프로덕트를 통해 협업을 진행하기 전

(건빵은 제가 현재 런칭 준비 중인 서비스입니닷 헤헷)

"나는 어떤 개발자가 되고 싶은가?", 다른 말로 "어떤 개발자가 진정한 개발자인가?" 에 대한 저의 답은

말그대로 코드를 잘 짜는, 코드의 본질을 아는 개발자였습니다.

건빵이라는 프로덕트를 진행하는 초기에만 하더라도 온전히 개발적으로 최고의 아웃풋을 뽑아내는 것만이 개발의 전부라고 생각했고 흔히 말하는 "퀄리티 높은 코드"만이 개발자의 최고 소양이라고 생각했습니다.

건빵이라는 프로덕트를 만나고 처음으로 앱의 "사용성", "유저가 원하는 것"에 대해 진지하게 고민했습니다.

이전까지는 "사용성"은 개발자가 아닌 기디에서 완성하는 것이라는 생각이 강했습니다. 이는 온전히 기디의 영역이며 우리가 생각할 건 아니라고 생각했죠. 또한 개발을 할 때 디자인적으로 골치아픈일이 너무 싫었습니다.

하지만 개발을 진행하면서 저도 모르게 유저의 사용성을 고민하게 되었고, 그제서야 클라이언트 개발자는 누구보다 유저와 가까운 사람이라는 것을 깨달았고, 결국 좋은 사용성을 가진 앱이 잘 될 수 밖에 없으며, 나의 가치는 코드로만 이야기되는 것이 아니라, 나의 서비스에 대한 가치 역시 제 가치임을 알았습니다.

사실 건빵이라는 프로덕트를 진행하며, 정리되지 않았던 이런 저의 생각들은 저를 정말 힘들게 했었습니다.지금에서야 저 말을 깨달은 듯이 말하고 있지만 그 당시에는 "내가 왜이러지,,?"라는 생각이 많았기 때문입니다.

저는 한동안 다음과 같은 생각의 순환에 갇혔있었습니다.

개발자란 "개발"만 잘하면 되는 것인데 너무 프로젝트를 이해하려고 드는 것일까? -> 하지만 이 프로덕트를 잘 이해해야, 클라이언트 개발자로써 최고의 사용성을 제공할 수 있다고 생각하는데.. -> 하지만 이 사용성 생각, 고민 때문에 일정 진행이 더뎌지는 것은 아닌가?, 이런 커뮤니케이션, 일정 조절 등으로 발생하는 서로의 시간.감정 비용 어쩌면 필요치 않은 비용 아닐까? -> 난 그냥 코드를 찍어내는 기계인가..? -> 아 난 그냥 "개발" 그니까 코드만 예쁘게 짜면 되는거 아니라? 이런 고민의 순환,, 또 순환,,

이런 고민을 하는 제가 그 당시에는 너무 바보같았습니다 ㅋ.ㅋ 아마쓸떼 없는 생각을 한다고 생각했습니다. 앞으로도 이런 고민을 자주 하게 되겠지만, 의미 없는 고민은 없다라는 걸 깨달았습니다.

그래서 현재 이 고민에 대한 답변은 무엇이냐고요?

키득키득 제 말이 정답은 아니겠지만, 8월 27일에 진행된 SOPT MIND에서 멋진 강연을 해주신 테오(유용태) 연사님의 말씀을 듣고 어느정도 제 생각을 정리할 수 있게됐고 너무 좋은 말씀이라 함께 공유하고 싶어 글을 씁니다.

연사님의 말씀 그대로가 아니며 제 생각이 가미된 표현들임을 전합니다!

글솜씨가 없어 와다다다 줄번호로 적어봅니다.

1. "프로그래머가 되지 말고 문제 해결사가 되라!

이는 강연의 주제이기도 했는데요, "개발"은 결국 어떠한 문제를 해결할 수 있는 하나의 무기임을 다시 한 번 생각하게 됐습니다. 어떤 문제에 대한 해결책 중 하나가 "개발"인 것이지, 개발을 하기 위해 프로덕트가 탄생하는 것이 아님을 알았습니다. 우리는 결국 한가지의 문제를 해결하기 위해 모인 사람들이므로, 커뮤니케이션 시간, 프로덕트에 대해 이해하는 시간, 테스크를 관리하고 마감을 잘 지키는것까지 이 모든 과정을 잘 해내가는 것이 개발자의 소양임을 알았습니다.

2. 사람들은 코드 내부에 대해 들여다보지 않는다. 결국 개발자의 가치는 프로덕트의 가치로 결정된다. 팀의 성공이 곧 나의 성공이다.

앞에서 말했듯이, 개발자는 코드, 로직으로만 대화한다고 생각했습니다. 하지만 저 역시도 서비스를 선택할 때 얼마나 쓰기 편하고 나에게 필요한지를 생각한다는 것을 알았습니다. 그렇기에 개발자에게도 서비스, 사용성에 대한 고민은 필수적이지 않나라는 생각을 다시 하게 됐습니다. 특히 사용자와 가까운 클라이언트, 프론트엔드 개발자는 더욱이 필수라고 생각했습니다. 또한 좋은 UX를 위한 디자인임을 무시하고 그 시간에 로직을 한 번 더 점검하고자 했던 저의 자세를 반성하게 됐습니다.

3. 규모가 커질수록 이전에 보지 못한 테스크들을 만나게 된다. 그때 필요한건 얼마나 정교하게 코드를 짜냐가 아니라, 이 테스크에 얼마나 빨리 대응할 수 있느냐이다.

정교한 코드를 작성하는 것만이 개발자의 소양은 아니며, 이것만을 잘하는 것은 프로그래머에 그치지 못한다라는 생각을 했습니다. 개발자는 코더도, 프로그래머도 아닌 문제 해결사가 되야한다는 생각을 하게 됐습니다.

4. 그럼 서비스 완성! >>>>>>> 코드의 질인가? 이것은 아닙니다.

이에 대한 저의 생각은 다음과 같습니다. 개발을 하다보면 한 달 전에 내가 쓴 코드를 모르겠고,, 무슨 의도였지..?할 때가 있고, 다른 사람의 코드를 제가 받아 이어서 개발을 하거나 하는 일이 생깁니다. 서비스가 커지고 서비스를 유지하는 기간이 길어질수록 이런 일은 자주 발생하고 점차 유지.보수가 중요해진다 생각합니다. 그럴 때, 코드의 질이 엉망이라면 어떡할까요..? 정말 난감할 것입니다. 그렇기에 제가 생각하는 최소한의 코드의 질은 "다른 사람이 이해하기 쉬운(알아보기 쉬운) 코드(함수화, 통일된 컨벤션, 좋은 네이밍), 그리고 한 코드의 변화가 다른 코드들에 큰 영향을 주지 않는 코드입니다." 지금까지 이 생각은 변치않고,, 앞으론 물론 변할 수 있겠다만,, 헤헷 지켜나가고 싶은 부분입니다. 이 부분만큼은 놓치지 않아야 한다고 생각합니다

테오님의 강연에서는 개발과 관련된 이야기 뿐만 아니라 협업에 대한 좋은 말씀도 많이 해주셨습니다. 이에 대한 얘기는 또 다른 글에서 다루도록 하겠습니다..! 반드시..!

그래서 전 무슨 개발자가 되고 싶냐고요?

전 특정 분야를 하는 개발자 예를 들어 "안드로이드 개발자", "데이터 엔지니어" 가 아닌 "서비스 혹은 문제 상황의 본질을 파악하고 문제를 해결해나가는 능동적인 개발자"로 성장하고 싶습니다. 이를 해결해 나가는 과정에서 "안드로이드"라는 무기가 필요할 수도 있고, "데이터 분석" 혹은 "웹지식"이 필요할 수도 있을 것입니다. 하지만 이는 서비스를 해결해나가는 도구일뿐이라는 것을 명심하고 서비스를 해결하기 위해서 항상 도전하는 개발자가 되고 싶습니다. 물론 특정 분야에 스페셜리스트가 되고 싶은 저에게 어려운 일이라는 것을 알지만(스페셜리스트가 되어서 이 무기를 저의 대왕 무기로 사용하고 싶은 마음도 있숨당 ㅎ) 건빵이라는 서비스를 만나고 제가 진정으로 흥미를 느끼는 (물론 그만큼 스트레스도 받습니다만,,) 일은 문제를 해결해나가는 일이라는 것을 깨달은 거 같습니다. 앞으로 전 의미있는 코드에 대해서 공부할 것이고, 더 나아가 사용자에게 유용한 서비스에 도움이 되는 코드를 짜려고 노력할 것입니다.

긴 글을 읽어주신분이 있다면,, 정말 감사하구 정말 정말 정말 개발을 이제 시작한 개린이이니,, 말도 안되는 글이라도 어여삐 봐주시면 감사하겠습니다!