프로덕트

아티클

전체 보기
김민혁

김민혁

나는 아직도 협업이 어렵다...!

그냥 함께 일하는 것이 아닌, 함께 최대한의 시너지를 내는 것

이렇게 나는 협업을 정의했다.

무엇이 협업인지는 인지했으나, 어떻게 협업을 할 것인지는 매 프로젝트마다 달랐다.

매번 다른 성격을 가진 사람들, 다른 능력을 가진 사람들, 다른 열정을 가진 사람들.

매번 다른 내용의 프로젝트, 다른 상황들.

이 '다름'에 익숙해지고 잘 협업을 하기란 정말 어려웠고, 지금도 어렵다.

나조차도 매번 다른 내용의 프로젝트 이기에 다른 능력과 열정으로 프로젝트에 임하는데, 같은 사람과 일을 한다고 해서 똑같은 방식으로 협업한다면 실패할 가능성이 높다.

매번 다르기에 협업에서 가장 중요했던 것은 '투명한 공유' 라고 생각한다.
성격이 어떤지, 어떤 능력 치를 가지고 있는지, 얼만큼의 열정을 쏟을 수 있는지 등을 서로 공유하는 것으로 시작해야, 어떻게 협업할 것인지 파악할 수 있기 때문이다.

투명한 공유가 이루어지지 않고 협업을 시작한다면, 협업을 하는 도중에 투명한 공유가 이루어지지 않는다면,

'쟤는 왜 저래?', '나만 일 하는건가?' 등 사소한 갈등과 의문이 각자의 머릿속에 하나 둘 떠오르게 될 것이다.

결국, 투명한 공유가 되지 않으면, 신뢰도 떨어질 뿐더러, 점차 모든 팀원이 지쳐가는 상황에까지 이를 수 있다.

이전에 있었던, 나의 프로젝트 경험을 예로 들자면,

유독 나와 의견이 많이 부딪히는 사람이 있었다. 그래서 나는 못된 마음으로 그 사람이 말하면 더 반박하고 싶었고, 다시는 같이 일 하고싶지 않다는 생각까지 들었다. 결국 프로젝트는 산으로 갔고, 완성하지 못한 채 흐지부지 되었다.

그때를 생각하면, 다시는 그렇게 일 하고싶지 않다. 많은 지나고나서 그 사람과 대화할 기회가 생겼는데, 우리는 그때 일했던 기억을 이야기했다.

우리는 그때의 감정과 생각을 서로 공유했고, 어떠한 마음으로 프로젝트를 임했는지 나누었다. 그래서 그 사람에 대해 평소에 어떠한 말투로 소통을 하는지, 궁금한 것이 있으면 끝까지 물고 늘어져서 질문하는 성격 등등 에 대해서 알 수 있었다.

이러한 것들을 알고 그때로 돌아간다면, 나는 절대로 잘못 생각하고 행동하지 않았을거라 생각한다. 프로젝트 또한 더 원활하게 진행될 수 있지 않았을까?

그 사람도 마음이 어려웠을 텐데, 나는 이 대화가 정말로 고맙고 소중한 시간이었다고 생각했다.

투명한 공유, 협업을 할 때에 영향이 가는 모든 것에 대한 공유가 중요하다. 나에 대한 공유 뿐만 아니라, 상대방에게 좋지 않은 의문점이 든다면, 말을 좋게 바꾸어서라도 상대방이 어떤 생각을 하고 있는 것인지 공유받는 것이 중요하다.

그러나, 나도 아직 이것이 어렵다. 그래서 협업이 어렵다.

잘 되진 않지만, 노력하자는 다짐을 하고자 끄적여보았다.

8
0
김민혁

김민혁

해야한다면, 다 하게 되더라.

지난 3년간 내가 성장할 수 있었던 가장 큰 마음가짐 이었던 것 같다.

해야한다면, 다 하게 되더라.


전역 후 앱개발자가 되겠다고 다짐하고 난 후 개인, 팀 단위의 프로젝트를 시작할 때마다

사소한 부분부터 큰 부분까지 정말 막막하고 벅차보일 때가 많았다.

다 처음 해보는 일이기 때문이다.

매번 새로운 것을 경험하고 싶었다.

안드로이드, 크로스플랫폼, iOS 개발을 거쳐오면서,

하나만 팔걸, 후회가 되는 부분도 있고, 새로운 것에 지친 적도 있었지만,

그때마다 프로젝트를 완수하기 위해 나에게 많이 외쳤던 것 같다.

“해야한다면, 다 하게 되더라”

내가 벌린 일, 내가 결심한 일이기에 해야했다.

그런데, 돌이켜보면 “해야한다.” 라고 나에게 줬던 압박이

언제나 처럼 내가 생각한 나의 한계를 넘게 해주고,

“다 하게 되더라.” 라고 나에게 줬던 용기가

계속해서 나를 나아가게 했던 것 같다.

지금도 “PARD”라는 동아리의 운영팀으로 있으면서,

프로그램의 기획에 대해서 생각하고, 여러 서류를 작성하고,

아직 부족하지만, 해야할 일을 스스로 찾아야하고,

4년 내내 코딩만 했던 감자에게는 모든 것이 새로운 일이고 도전이다.

내게 맡겨진 일이 생전 처음해보고 겁도 나고, 때론 너무 많더라도

그것 때문에 스트레스 받으면 끝도 없다.

해보지도 않고 겁만 먹으면, 아무것도 못하기 때문이다.

내게 맡겨진 책임감을 위해, 나의 성장을 위해

해야하니까, 해보자. 어차피 다 하게 되니까.

8
3
김민혁

김민혁

아무것도 할 수 없다는 막막함

안녕하세요 포항시 IT 협업 동아리 PARD 3기 iOS파트 김민혁입니다.

지난주 금, 토요일 간 진행된 동아리 내 무박 2일의 해커톤. 일명 숏커톤에 참여하게 되었습니다.

저에게는 1기와 더불어 두번째 숏커톤 참여였는데요. 그때와는 또다른 경험을 할 수 있었습니다.

사실상 이번 숏커톤에서는 저는 제가 할 수 있었던 것이 거의 없었습니다.

그 이유는 제 맥북의 Xcode의 iOS 버전이 팀원들과 맞지 않았고,

제가 가진 MacOS의 버전이 해당 버전을 지원하지 않아서 OS를 업그레이드 하고, Xcode까지 업그레이드 하기 위해서는 많은 시간이 소요될 것이라 판단 되었기 때문입니다.

1기 때에는 몇일 전 어느정도 팀원이 누구인지 파악이 가능했기에, 숏커톤 전 팀원들과 버전을 맞추고, 코드스타일 및 파일구조, git 사용 등에 대한 것들을 어느 정도 align 할 수가 있었지만, 이번에는 팀원의 정보를 숏커톤 시작 전까지 알 수가 없었기에 이러한 것들을 미리 맞춰 놓을 수가 없었습니다.

저는 절망했습니다. 1기보다 더 성장한 모습으로 더 많은 자신감을 가지고 시작했고, 여러 UI 프레임워크들을 사용해 봄으로써 생긴 자신감으로 인해, 기획단계에서 나오는 어떠한 아이디어든 다 해낼 수 있다고 믿고 있었기 때문입니다. 몰라서 못하는 것보다 아는데 하지 못한다는 점이 저에게는 너무나도 큰 절망감을 주었습니다...

아무튼!!

기획 단계, 개발 첫단계에서의 이러한 상황들로 인해서 제가 개발을 시작할 수 있었던 시간은 새벽 2시가 조금 넘은 시각부터였습니다. OS를 업그레이드 하는 부분은 포기를 했고, 다른 버전의 프로젝트이기에 당연히 팀원들과 동일한 github repository를 사용하는 것또한 포기할 수 밖에 없었습니다.

저는 팀원들에게 너무나도 미안했지만, "어쩔수 없다. 할 수 있는 것이라도 하자"라는 마음으로 제 개인 프로젝트를 만들어서 제 코드를 공유하여 팀원들이 복사 붙여넣기 하는 식으로라도 참여를 할 수가 있었습니다.

결과적으로는, 우리팀은 프로덕트를 완벽히 완성할 수 없었습니다. 모든 사람이 1인분의 역할을 하더라도 좋은 프로덕트를 완성하는 것이 쉽지 않은 일이며, 저는 1인분의 역할을 하지 못했기 때문입니다. 이번 경험을 통해서 저는 경험의 부족에 대해 깨달을 수 있었습니다. 처음 겪는 어려움에 당황하여서 어떻게 해결해야할 지 판단하는 능력이 흐려졌고, 그것은 바로 무의미한 시간의 소비와 이어졌습니다. 4학년인 저는 아직도 습득해야할 지식이 많지만, 현업에 들어가기 전, 더 다양한 경험을 해야할 필요성을 느낄 수 있었습니다.

짧은 제 회고 및 푸념글 읽어주셔서 감사합니다.

11
0
김민혁

김민혁

개발자의 협업 🗒️코드 컨벤션

안녕하세요 Pard 1기 앱파트, 3기 iOS 김민혁입니다.

Pard는 협업이라는 키워드를 목표로 삼고 달려가고 있는 동아리입니다.

제가 이때까지 경험한 Pard는 나와 다른 분야의 학생들과 협업을 경험하기에 너무나도 좋은 기회이며, 그렇기에 다른 분야의 사람들이 어떠한 방식으로 생각하고, 또, 그들의 어려움은 무엇인지 많은 것을 배울 수 있었습니다.

그러나, 다른 분야와 협업을 하기에 앞서 하나의 프로젝트에는 여러 개발자가 참여하게 됨으로, 다른 분야 뿐만아니라 개발자 끼리도 협업을 잘하는 것이 중요합니다.

그래서 오늘 가져온 것은 코드 컨벤션에 관한 것입니다. 물론, 다른 여러 프로젝트나, 산학 프로젝트를 하고 있는 우리 Pard의 Pardy, Pardo들은 익히 알고 있겠지만, 아직 그렇지 못해 처음 협업을 할 개발자들(Pard 이외에도)이 코드컨벤션에 대하여 알았으면 좋겠다 하는 마음에 글을 작성해 봅니다...

코드 컨벤션이란,

코드를 읽고 이해하기 쉽게 하기 위한 개발자들의 코딩 스타일 규약입니다.

  1. 파일구조 및 파일 네이밍규칙

  2. import 규칙 (ex: 알파벳 순)

  3. 변수 네이밍 및 정의방법 (swift의 경우 let variable: type = value or let variable : type = value)

  4. 괄호, 들여쓰기, 줄바꿈, 공백 규칙

  5. 파일 구조, 변수 외 패키지, 클래스, 함수, 파라미터, 상수 등의 네이밍 규칙

이 외에도 많은 것들에 대한 규약이 포함되어 있는 문서를 뜻합니다.

코드 컨벤션이 중요한 이유

코드 컨벤션의 목표는 개발자가 '서로의 코드를 읽고 이해하기 쉽게 하자'입니다. 모두가 같은 스타일로 코드를 작성하기에 다른 사람의 코드를 더 이해하기 쉽고 이로써 불필요하게 시간을 들여 코드를 이해하는 일을 줄일 수가 있습니다.

파일명을 예로 들자면, 내가 productListView 와 같은 형식으로 파일명을 작성했는데, 같은 상황에서 다른 사람은 ListProductView와 같은 형식으로 작성을 한다고 하면, 나는 productListView에 해당하는 파일을 찾기 위해서 가장 앞의 글자인 p를 기준으로 파일을 찾기 시작할 것입니다. 또한 폴더 안의 파일들의 이름이 대소문자 가리지 않고 뒤죽박죽 이라면 정리되지 않은 느낌도 있으면서 일관성도 없을 것입니다.

이미 회사에 종사하시고 있는 분들께서는 물론 코드 컨벤션을 많이들 이용하고 계시겠지만, 디스콰이엇을 이용하고 있으신 많은 미래의 개발자 분들께서 코드 컨벤션에 대한 중요성을 아시고, 경험하시고 익숙해 질 수 있으시면 좋겠다는 마음이 이 글을 작성하게 되었습니다.

개발자의 협업에는 github와 같은 좋은 tool들이 있지만, 기획단계의 기본, 상세 설계서와 같은 산출물들 처럼 개발자들의 협업을 위해 이러한 약속들이 얼마나 중요한지를 느끼고 회고하게 되었습니다. 비록 자신의 코드가 훌륭하고, 깔끔하더라도 자만하지 않고, 협업을 잘하는 개발자로 함꼐 성장했으면 좋겠습니다.

사실 제가 적은 코드 컨벤션의 장점은 학생의 기준으로 작성된 것이지만, 저의 짧은 생각으로는 코드 컨벤션의 문서화에 대해 회사의 입장으로는 코드의 일관성으로 유지보수의 측면이 클 것이라 생각됩니다. 그러나 그보다도, 학생인 제가 생각하기로 코드 컨벤션은 개발자가 협업하기 위한 가장 첫번째 순서라고 생각합니다. 그저 말로만 하는 간단한 약속은 코드를 작성하면서 아차 하는 순간에 잊을 수 있으므로 협업읋 하는 학생 개발자들도 네이밍 규칙 및, 파일 구조와 같은 간단한 규칙이라도 코드 컨벤션으로 문서화 하여 개발자의 협업을 경험하며 함께 성장했으면 하는 바람입니다.

비록 코드 컨벤션에 대한 설명은 짧을 수 있겠지만, 익히 많이 알려진 것이므로 검색하시면 많은 정보들을 찾을 수 있을 것입니다. 협업에서 필수적으로 사용되는 것인줄은 압니다만, 학생의 차원에서 많이 경험할 수 없다는 생각에 이렇게 글을 작성해 보았습니다.

읽어 주셔서 감사합니다:)

+. To developers in Pard, 숏커톤과 롱커톤 전 모인 개발자들이 이 코드 컨벤션에 대해서 한번 더 기억하며 간단한 문서로 정리하며 서로 약속을 문서화했으며 하며, 이로인해 더 좋은 협업을 할 수 있으시길 바랍니다. 또한, 우리 Pard에서 추구하는 협업을 힘껏 느끼셨으면 좋겠습니다.

11
0
김민혁

김민혁

🙊ChatGPT보단 재탕🙉

안녕하세요 1기 앱파트, 3기 iOS파트 김민혁입니다.

재탕

1. 한 번 달여 먹은 한약재를 두 번째 달이는 것. 재전(再煎).

2. 이미 써먹은 것을 다시 이용하는 일을 야유조로 이르는 말.

흔히 재탕이란 말은 안좋은 의미로 사용될 때가 많습니다. 그러나, 코딩에 대해서는 이 재탕이 그렇게 좋을 수가 없습니다.

수많은 생성형 AI의 등장으로 코드를 더 쉽게 만들 수 있게 된 것은 사실입니다. 이로 인해 더 빠른 Product들을 생산할 수 있게 되었고, 이러한 AI들의 이점을 무시할 수 없는 것은 사실입니다.

그러나, 코드를 짜거나 오류가 생길 때 무작정 Instruction이나 에러를 Prompt에 옮겨 적고 있지는 않나요? 어느새 AI에 의존하고 있는 나 자신을 발견하며 개발자로서 실력에 대한 불안함을 느끼지는 않나요?

1기 숏커톤, 롱커톤, 그리고 다른 다양한 프로젝트를 하면서 느낀 것은 "재사용" 할 수 있는 코드를 만들어야 한다는 것이었습니다. 그 이유는 다음과 같습니다.

  1. 내가 다 아는 것이라도 처음부터 만들어야 하기에 불필요한 시간이 소요된다.

  2. 새로 만들게 됨으로써 새로이 생기는 에러를 감당해야한다.

  3. 머리 속에 있는 Logic을 다시 꺼내오려면 더 많은 시간이 걸린다.

  4. 시간을 줄이기 위해 AI를 사용하다보면 코드가 더러워지고, 협업에 좋지 않다.

  5. 같은 이유로 AI를 사용하게 되면 제공된 코드를 이해하고 적용하는 것에 더 시간이 소요된다.

등등 다양한 이유로 a.k.a. 재탕 코드의 필요성을 크게 느낄 수 있었습니다. Pard에서는 모든 기수가 숏커톤, 롱커톤을 겪게 되는데, 한 학기라는 짧은 시간에 새로운 프레임워크를 배우며 성장하는 개발자들은 이 재탕코드가 큰 경쟁력을 가질 수 있을거라 생각합니다.

모든 프로젝트는 제한된 시간 안에서 이루어집니다. 그러나, 재탕 코드를 통해서 불필요한 시간을 줄일 수 있고, 한번 깔끔한 코드를 만들어 놓았다면 큰 노력을 들이지 않고도 깔끔한 코드를 만들어 낼 수 있을 것입니다. 그래서 저는 "재탕 코드 아카이빙"을 통해 쓸데 없는 prompt를 줄이고 빠르고 이해가 쉬운 저의 코드를 더 사용할 수 있도록 노력할 생각입니다.

짧은 글 읽어주셔서 감사합니다.

모두들 에러없는 나만의 재탕코드 아카이빙을 통해 경쟁력 있는 개발자가 되시길 바랍니다.

Pard 화이팅. Pard 개발자 화이팅. Pard iOS 화이팅.🐵

10
2

포스트

아직 포스트가 없습니다.