• 위클리 스크럼 모두 보기

참고로 저의 최애는 "AI 연구자를 위한 클린코드" 포스트입니다. 저희가 읽었던 세미나 자체가 매우 퀄리티가 높았고, 다양한 예시도 들어가 있어서 의견 토론하기도 매우 좋았습니다.

이제 중간고사를 지나고, 기획 및 개발의 MVP가 완성이 되면서 본격적으로 추가 개발만 해야 하는 시기가 도달했는데요, 이에 따라서 기존의 아티클을 읽던 위클리 스크럼에서, 모각코를 하는 위클리 스크럼으로 변경하기로 결정했습니다. 아티클 리딩을 통해서 저희가 몰랐던 분야를 접할 수 있는 input을 늘렸다면, 이제 우리가 알고 있는 부분을 완성도가 높게, 모멘텀을 가지고 개발하면서 output을 늘릴 예정입니다.

학습 성취율에 대한 표를 보면 알 수 있듯이, 읽고 받아들이는 input 뿐만 아니라 직접 체험하면서 개발하는 output도 많은 성취를 만들어 낼 수 있기 때문이죠. 하지만 아티클 리딩을 통해서 팀원들의 다양한 의견, 선호하는 시각을 알 수 있었던 만큼, 개발이 끝나면 꼭 다시 아티클 리딩을 진행해보고 싶습니다☺️

참고로 이번 주의 글을 팀원들이 대화하는 형식으로 작성해보았습니다. 의식의 흐름대로 따라가면서 글을 읽는 것을 추천드립니다😉

이번 주 읽은 글

• https://www.slideshare.net/KennethCeyer/ai-gdg-devfest-seoul-2019-187630418

슬라이드를 읽으며 나눈 팀원들의 의견

❤️‍🔥cathy: 평소에 일단 클린하지 않더라도 개발하기 급급한 사람으로서 깨진 유리창 이론, 매우 굉장히 찔리는데요.

❤️‍🔥cathy: 맞아요. 이렇게 분기가 너무 많아지면 파이썬은 depth를 괄호로 묶지 않기 때문에 정말 힘들었어요. 이 부분을 깔끔하게 처리하는 게 매우 중요할 것 같아요(실제로 depth 깊은 분기 때문에 치명적 실수를 했던 사람의 당사자성 발언). 🍒chaen: 파이썬은 타입 선언도 하지 않아도 될 만큼 대충 코드를 작성해도 어떻게든 돌아가기 때문에 코드악취가 일어나기 쉬운 것 같아요.

❤️‍🔥cathy: 이런 식으로 if문을 쓰는 것을 코드 악취라고 하시네요. 굉장히 찔립니다. 제가 구현한 OAuth 로그인이 바로 딱 이런 방식이라서요!🤣 꼭 고쳐야겠어요.

❤️‍🔥cathy: 제 눈에는 이 코드에서 하이퍼파라미터 선언하는 부분이 너무 더러워보여요. 이렇게 바꿔줘야 하는 변수는 따로 설정으로 묶어서 보여줘야 할 것 같아요. 🍒chaen: 그런가요? 저는 하도 AI 개발하면서 이상한 코드를 많이 봐서 그런지 하이퍼파라미터는 괜찮아 보여요.

❤️‍🔥cathy: 코드가...더 길어졌어...! 🍒chaen: gin-config가 뭘까요? 처음 보는 거네요. (찾아 본 후) 구성 파일에서 매개변수를 제공해주는 거라고 하네요. 신기하다! 다음에 써보고 싶어요.

• https://github.com/google/gin-config

❤️‍🔥cathy: 처음 보는 게 또 나왔어요. IDSIA가 뭘까요? 🍒chaen: 실험을 구성, 구성, 기록 및 재현하는 데 도움이 되는 도구라고 깃허브에 나와있네요. ☕cora: 비슷한 역할인지는 모르겠지만, 프론트에도 커밋 날리기 전에 문법 등을 확인해주는 도구가 있어요.

• https://github.com/IDSIA/sacred

☕cora: 이거 정말 공감하는 부분이에요. 중복 코드 관련해서 최근에는 객체 처리하는 게 매우 중요하다는 생각을 해요. 프론트에서 하나의 객체를 만들어두면 굉장히 편리하게 재활용할 수 있는 경우가 많아서요.

☕cora: 근데 저만 이렇게 생각하나요? 오히려 이렇게 lambda를 쓰는 게 무슨 뜻인지 한눈에 알기 힘들어서 별로인 것 같아요(웃음) 🍒chaen: 저도요. 개인적으로는 이렇게 map안에 lambda가 있고, 그 람다는 item을 리스트로 만들어주고, 이렇게 구구절절해 보이는 게 조금 별로에요. print문을 찍어가면서 디버깅하기도 힘들 것 같고요.

🍒chaen: csv 파일을 타입을 정해놓은 건 처음보는 것 같아요. 이렇게 타입을 명확하게 결정해야 할 이유가 있을까요? 오히려 에러가 나지 않을까요? ❤️‍🔥cathy: 저는 좋은 것 같아요. 빅데이터를 다루는 csv 파일은 엄청 무거워서 GUI로 안 열리는 경우가 아주 많고, 데이터를 열어보기도 힘든데, 이렇게 타입을 결정해놓으면 코드단에서 데이터의 형식을 확인할 수 있다는 장점도 있을 것 같아요. ☕cora: 이 부분은 고민되긴 하네요. 저도 프론트를 다룰 때 데이터 타입을 any로 할지, 아니면 백이랑 데이터 타입 다 결정해서 맞춰놔야 할지 항상 고민이라서요. 데이터 타입 관련해서는 고민되는 게 많은 것 같아요.

❤️‍🔥cathy: 이거 매우 좋은 질문에 좋은 답변이네요. csv일 경우에는 그냥 데이터가 유효할 것이라고 가정하는게 좋다는 게 실용적인 접근인 것 같아요. 실제로 AI 모델 개발할 때 만들어지는 csv는 깔끔하게 전처리한 데이터인 경우가 많고요.

읽은 글 : https://medium.com/aimonks/8-chatgpt-prompts-that-will-blow-your-mind-and-transform-your-life-43bade1cc33e

개인적으로, AI 그중에서도 chatGPT와 같은 대형 모델을 이용해 제품을 개발하면서 가장 까다로운 부분 중 하나가 바로 이 prompting이라고 생각합니다. 사실, 개발의 묘미는 마치 수학 공식처럼 제가 만드는 대로 딱딱 떨어지는 결과물 아니겠어요? 하지만, Prompting을 하다 보면 정말 사람과 대화하는 것처럼 내가 예상치 못한 대답을 하고, 어쩔 땐 어떻게 제어를 해야 항상성을 높일 수 있을지 막막해지더라고요.

그래서 prompting engineer에 대한 수요도 높아진 지금인데요, 정말 제품을 개발할 때 사용하는 promt들을 보면 예상보다 훨씬 더 정교하고 체계적인 방식을 사용합니다. 사실, 이 글도 medium을 항해하다 어? prompt? 8가지? 이거다..! 하고 제가 냅다 링크를 보냈는데, 사실 prompt engineering 보다는 chatGPT를 어떻게 하면 더 유용하게 사용할 수 있을지에 대한 글이었습니다. 평소에 사용하던 방법들도 있고, 어 이걸 이렇게? 하면서 앞으로 써먹을 것을 다짐하게 만드는 방법들도 있었는데요, 함께 살펴보시죠.

Prompt 1: Learning from your own mistakes
Prompt:

“ I made a mistake. I was practising [insert skill here], and it failed when I [insert failure here and narrate what happened].

Could you please explain what happened and what went wrong, as well as how I can avoid making the same mistake in the future and evolve?“

첫 번째는 바로, 실수로부터 배우는 법입니다! 사실 저희가 코딩할 때 가장 많이 써먹는 방법이기도 하죠.

내가 이 줄을 이렇게 바꿨는데, 그러니까 여기서 이런 오류가 나고, 결과물은 이렇게 됐어. 나는 저렇게 만들고 싶은데 어떻게 할까?

이 prompt에 대해 팀원들과 이야기를 하면서도, 사실 어떻게 보면 당연한 거지만, 우리가 앞으로 개발 뿐 아니라 여러 가지의 일을 함에 있어 꼭 가져야 하는 자세라는 얘기를 했습니다. 특정 문제나 실패를 맞닥뜨렸을 때, 어떠한 원인이 부정적인 결과로 이어졌는지 그 인과 관계를 명확히 파악한다면, 다음번엔 그 원인만 해결하면 되겠죠? 그런데 점점,,, 얽히고 섥힌 실들 속 꼭 필요한 인과 관계만 골라내기가 어려워 진다는 게 문제인데, 과연 코드 뿐 아니라 다른 일들 속에서도 ChatGPT의 prompt가 도움이 될 수 있을지, 제가 사용하게 된다면 꼭 공유하도록 하겠습니다 ㅎㅎ

Prompt 3: Train ChatGPT to learn your Style
Prompt:

“Analyze the text below. It’s the text that I have written. Take note of the writing style, my voice, the way I type and my tonality.

Create a prompt to write a new paragraph in the same style, voice and tone.

[Insert your text here]”

다음은, chatGPT에게 나의 스타일을 학습시키기 입니다. 이전 나의 창작물들을 chatGPT에게 학습시키고, 이를 바탕으로 새로운 창작물을 마치 내가 만드는 것처럼 chatGPT가 만들어내게 하는 거죠. 8가지의 prompt 중 저희가 가장 열띠게 토론했던 주제이기도 한데요, 사실 gpt의 대작이 상당히 큰 문제로 떠오르고 있습니다. 이로 인한 저작권 침해도 상당히 심각하고요. 그런데, 나의 창작물을 학습해서 나의 스타일로 chatGPT가 만들어준 새로운 창작물. 물론 이 글에선 이렇게 만들어낸 결과물을 통해 우리가 도움을 받을 수 있는 부분에 대해 이야기해줬지만, 앞으로 인공지능이 더욱 발전하고 상용화가 된다면 이렇게 만들어진 창작물의 권리와 '창작'의 정의에 대해 여러 의견들이 상충할 것이라고 팀원 모두가 입을 모았습니다.

특히 cathy 팀원은 이렇게 챗gpt를 이용해 계속해서 창작물을 만들어내다 보면, 언젠가부터는 chatGPT에게 학습시킬 나만의 창작물 자체가 없어질 것이란 통찰력 깊은 주장을 했습니다.

또한 cherry 팀원은 기업이 지금도 생성형 AI를 이용한 코드 또는 자기소개서를 선별해내고자 노력하고 있고, 이걸 탐지하기 위한 기업도 실제로 존재하는데, 앞으로 AI가 발전할 수록 점점 창과 방패의 싸움이 될 것 같다는 새로운 화두를 던져주었습니다.

이렇게 의견을 모아놓고 보니, 사실 완전히 새로운 창작물이란 없고, 약간의 모방과 약간의 참고, 그리고 나의 영감을 받아 작품이란 결과물이 만들어진다고 생각하는데, 앞으로 나의 영감을 받은 생성형 AI가 사회에서 어떻게 자리잡을지, 궁금해지는 요즘입니다.

여러분의 생각은 어떠신가요?

이번 주 읽은 글

• https://johngrib.github.io/wiki/orange-juice-test/

오랜지 주스 테스트란?

오랜지 주스 테스트란 다음과 같습니다. 테스트를 받는 사람은 아래 문제를 해결해야 합니다.

• 연례 영업 회의를 할 장소를 선정해야 한다.
• 적어도 700명은 수용할 수 있는 공간을 찾아야 한다.
• 해당 공간에서 매일 700명의 아침 식사로 토스트와 오렌지 주스가 서빙되어야 한다.
• 정확히 오전 7시에 회의를 시작하고, 아침을 먹을 수 있어야 한다. 700명 모두 갓 짜낸 신선한 오렌지 주스를 큰 컵으로 마실 수 있어야 한다. 그냥 큰 컵이 아니라 패스트푸드점에 있는 진짜로 큰 컵. 오렌지 주스는 갓 짜낸 신선한 것이어야 한다(대략 2시간 이내).

오렌지 주스 테스트의 답

오랜지 주스 테스트의 답은 다음과 같습니다.

• 무리한 요구를 받았을 때 "아니오"라고 이야기하면 안 된다.
• 무리한 요구를 받았을 때 "예"라고 이야기해도 안 된다.
• 그것을 하려면 얼마만큼의 비용이 필요하며 대안은 이러저러 하다고 대답하는 것이 오렌지 주스 테스트를 통과하는 방법이다.

즉, 훌륭한 개발자라면 요구사항에 대해서 "예", "아니오"로 단순하게 대답하는 것이 아니라면

Cora의 코멘트

먼저 cora님은 요구사항을 보니 PTSD가 온다고 호소하셨습니다. cora님은 인턴 경험이 있으신데, 그 경험이 PTSD를 유발한 것 같습니다😇

오렌지 주스 테스트에 대해서 코라님은 일단 "해보겠습니다. 그런데 돈 얼마나 지원해주나요?"라고 답변할 것 같다고 하셨습니다. 회사에서 면접볼 때 이런 부분을 살려서 답하는 게 필요한 것 같다고 하셨는데요, 창의력을 중요하게 여기는 회사에는 질문에 "예", "아니요"만 대답하는 것보다, 어떤 부분을 할 수 있고, 얼마나 금액이 든다 등을 줄줄 말할 수 있는 사람을 더 좋아할 것 같다고 말씀하셨습니다.

Chaen의 코멘트

chaen님은 우선 이렇게 간 보는 질문이 싫다고 하셨습니다🤣 또한 chaen님은 예전에 들으셨던 말 중에, "면접을 볼 때 회사가 나를 테스트한다고 생각하지 말고, 나도 회사를 테스트한다고 생각하라"는 말이 기억난다고 하셨습니다. 면접관이 궁금한 것 없어요?라고 했을 때 궁금한 게 있어야 한다고 설명하셨는데요, 그래서 회사도 나랑 함께 할 수 있는지, 그리고 나를 더 설명할 기회를 얻을 수 있는지를 테스트할 수 있다고 하셨습니다.

Cathy의 코멘트

이번 아티클은 제가 먼저 읽자고 했었는데요, 제가 개인적으로 이 아티클이 인상 깊었던 부분은 저 또한 시간이나 저의 능력을 초과한 요구사항이라도 일단 주어지면 "무조건 해보겠습니다."라고 말하는 경우가 많기 때문입니다. 하지만 요구사항을 주는 사람을 위해서라도, 이 요구사항은 cost가 얼마나 되는지를 확실하게 말하는 게 중요한 것 같습니다. 그래야 그 요구사항이 정말로 원했던 목표가 뭔지를 공유받고 그에 적합하게 개발할 수 있기 때문입니다. 코라님과 chaen님도 이러한 말에 깊게 공감하셨습니다.

후기

이번 주차의 아티클은 가볍지만 논의해볼 만한 것들이 많은 내용이었습니다. 덕분에 팀원들과 면접, 취직, 프로젝트, 기획 등등 다양한 부분에 대해서 논의해보았습니다. 저 또한 팀장으로서 의사소통을 하는 방법에 대해서 돌아보기 좋은 시간이었습니다.

👩🏻‍💻 자기 소개 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 팀 re:cording은 “사람들이 정말 쓸만한 서비스를 만들고 싶다”라는 열정 아래에서 만들어졌습니다. 좋은 서비스를 만들기 위해서 저희 팀은 끊임없이 다시 코딩하고, 새롭게 코딩하고, 또 새로운 것을 코딩하려 합니다.

이번 주 읽은 글

• https://medium.com/@parklaus1078/medallion-architecture-bfc755c9dada
• https://aws.plainenglish.io/making-sense-of-the-aws-lake-house-architecture-ef0d8bc47897

  작성 시 참고한 자료

• https://medium.com/@junshan0/medallion-architecture-what-why-and-how-ce07421ef06f

레이크 하우스

레이크 하우스의 등장 배경

빅 데이터는 그 규모(Volume), 속도(Velocity), 다양성(Variety), 정확성(Veracity)의 네 가지 특징을 가집니다. 기업은 점점 더 많은 데이터를 생성하고 있으며, 이 데이터는 다양한 형태와 빠른 속도로 축적됩니다. 이러한 데이터의 폭발적인 증가는 기존의 데이터 처리 방식으로는 관리와 분석이 어렵다는 문제에 직면했습니다.

데이터 웨어하우스는 잘 구조화된 데이터에 대한 빠른 쿼리와 분석을 위해 설계되었습니다. 그러나 빅 데이터의 다양성과 복잡성은 데이터 웨어하우스가 처리하기에는 너무 크고 복잡하다는 특징을 가지죠. 보다 유연한 데이터 저장 및 관리 방식이 필요해짐에 따라 데이터 레이크가 등장했습니다. 데이터 레이크는 모든 유형의 데이터를 원시 형태로 저장할 수 있는 대규모 저장소로, 필요에 따라 데이터를 가공하고 분석할 수 있는 구조입니다.

비록 데이터 레이크가 데이터 웨어하우스의 한계를 극복하고 빅 데이터를 수용할 수 있는 유연성을 제공했지만, 여전히 데이터 레이크도 빅데이터를 처리하기엔 단점이 존재했습니다. 데이터 레이크 내의 데이터는 '데이터 스왐프(data swamp)' 혹은 '데이터 그레이브야드(data graveyard)'로 전락할 위험이 있습니다. 데이터 레이크에서 원하는 결과를 얻어내려면 전문적인 지식과 기술이 필요했기 때문에, 대부분의 사람들은 데이터 레이크 내의 데이터가 가치없다고 생각하게 된다는 것입니다. 또한, 데이터 웨어 하우스의 데이터가 이미 잘 정리가 되어있었기에 여기에서 벗어나기 어렵다는 점도 존재합니다.(data gravity)

데이터 레이크 하우스란

이러한 문제를 해결하기 위해 등장한 것이 데이터 레이크 하우스 아키텍처입니다. 데이터 레이크 하우스는 데이터 웨어하우스의 구조화된 분석이 편리하다는 장점과 데이터 레이크의 유연성을 결합하여, 빅 데이터의 가치를 활용할 수 있는 접근 방식입니다. 이를 통해 복잡한 데이터 환경에서도 확장성, 유연성, 그리고 실시간 분석을 지원하면서도, 데이터 관리와 거버넌스를 강화할 수 있게 되었습니다.

메달리온 아키텍처란

메달리온 아키텍처(Medallion Architecture)는 데이터 레이크하우스 환경에서 데이터를 체계적으로 관리하는 데 사용되는 데이터 디자인 패턴입니다. 이 아키텍처는 데이터의 구조와 품질에 따라 동(Bronze), 은(Silver), 금(Gold)의 세 가지 레이어로 분류하여 저장합니다.

Bronze Layer (Raw Data)

Bronze 레이어에는 외부 소스로부터 수집된 날 것의 데이터(raw data)가 저장되며, 이 데이터는 결측치나 분석 불가능한 값, 비정형 데이터를 포함할 수 있습니다. 데이터를 수집한 그대로(as-is) 저장합니다. 이 레이어는 빠른 변경 데이터 캡처(Change Data Capture, CDC)를 수행하고, 원본 데이터를 안전하게 보관하여 필요 시 언제든지 접근할 수 있도록 합니다.

Silver Layer (Cleansed & Conformed Data)

Silver 레이어는 정제되고 표준화된 데이터를 저장합니다. 결측치 보완, 중복값 제거, 데이터 타입의 일치화 등의 처리가 된 데이터가 저장됩니다. 분석가나 데이터 과학자가 사용하기에 적합한 형태로, Databricks에서는 이 상태의 데이터를 'just-enough' 처리된 상태라고도 합니다.

Gold Layer (Curated Business-Level Tables)

Gold 레이어는 비즈니스 분석에 사용이 가능한, 고도로 정제되고 구조화된 데이터를 저장합니다. 최종 사용자와 의사결정자가 쉽게 이해하고 사용할 수 있도록 데이터를 구조화하고, 데이터의 가치가 극대화된 형태입니다.

후기

이 주제는 제가 한 번 공부해보고 싶다고 제시하였는데요! 사실 학생의 입장에서 엄청나게 큰 데이터셋도, 혹은 장기적인 서비스 개선이나 분석을 위한 프로젝트 설계도 아직 경험해본 적이 없어 조금 생소했습니다. 팀원들과 함께 이 주제에 대해 이야기 해볼 수 있어서 훨씬 즐겁게 공부했던 것 같네요. 이 위클리 스크럼이 장기적으로 저희의 발전에 도움이 되길 바랍니다😍

졸업 프로젝트 과목을 수강하면 필수적으로 관련 분야에 종사하고 계신 현업자 분들께 저희 작업에 대해 멘토링을 받아야 하는데요, 이를 위해 학교 내 자체적으로도 멘토링이 가능하신 분들을 알려주시기도 하고, 직업 연락을 드려 만남을 요청하기도 합니다.

저희 리코딩 팀은, Cathy가 링크드인에서 평소 즐겨 보던 글을 올려주시는 분께 조심스럽게 연락을 드려봤는데요..! AI 분야에서 굉장히 유명하시고, 또 그만큼 바쁘신 분이라 사실 긍정적인 대답을 기대하진 않았습니다..

하지만 저희의 간절한 마음이 통했을까요! 너무나도 흔쾌히 멘토 요청을 수락해주셨고, 그 결과 두 번의 아주 알찬 만남을 가질 수 있었습니다.

1차 만남

10월 11일에 이루어진 1차 만남! 멘토님께서 일하시는 강남으로 리코딩 팀원 모두가 모여 열심히 만든 질문지도 점검하고, 사회의 웃어른을 어떻게 대해야 하는지에 대해서도 긴급 토의가 열렸습니다.

그렇게 조금은 긴장되고 설레는 시간 끝에 만나게 된 우리의 멘토님! 오자마자 너무나 멋있는 포스로 저희 모두의 음료수를 사주시더니, 본래 예정이었던 2시간을 넘어 무려 4시간이나 저희를 멘토링 해주셨습니다!

사실 저희는 그 당시 기술적인 부분에 있어 어떻게 하면 AI를 효율적으로 쓸 수 있는지에 대해 여쭤보고 싶은 마음이었는데요, 멘토님께서 정말 여러 회사와 사업을 맡아오셨던 만큼, 기술 그 이상의 것을 얻어갈 수 있었습니다.

특히, 그 당시 D2SF를 준비하고 있던 공대생 3명에게, 굉장히 기획적인 부분의 insight를 전달해주신 점이 정말 감명 깊었습니다. 우리 리코딩 팀이 [왜 일정관리를 선택했는지], [어떠한 일정관리 앱을 만들고 싶은지], [생성형 AI가 무엇이고, 어떻게 사용하고자 하는지], [피드백을 어떤 식으로 해나가야 되는지] 와 같은 근본적인 서비스의 정체성을 찾아주시려 하셨는데요. 사실, 그 서비스를 딱 떠올렸을 때 연상되는 무언가가 있다는 게 바로 정체성이고, 사람들이 그 서비스를 찾게 하는 유도점인 거잖아요? 저희가 실제 창업을 염두에 두고 있는 만큼, 가장 중요한 가르침이 아니었나 생각합니다.

뿐만 아니라, [빙 이미지 크리에이터], [deepL], [Copilot], [위스터], [autoML] 등과 같은 정말 다양하고 깊이 있는 기술에 대한 통찰력으로 AI가 무엇인지, 그 정수를 조금이나마 맛보고 왔던 것 같습니다.

2차 만남

2차 만남 역시 10월 18일에 강남에서 이루어졌습니다. 이번 만남은 1차 만남과는 달리 저희가 질문 드린 것을 바탕으로 답변해주시고, 서로 질의응답 하며 점점 깊이 있는 얘기를 나누었던 시간이었습니다.

특히 현존하는 구글 캘린더나 네이버 서비스와 같은 타 서비스와의 경쟁에서 우리 서비스가 가질 수 있는 특징, 그리고 타 서비스와의 연동을 통해 우리가 얻어내야 할 것들을 기술과 기획 모두의 관점으로 분석해볼 수 있었습니다. 이와 더불어, 취업에 대한 힌트까지 주고 가신 멘토님!😏 꼭 성공해서 다시 뵙겠습니다... ㅎㅎ

그리고 이 날은, 멘토님께서 끝나고 함께 저녁을 먹자고 하셔서 저희가 아주 긴장된 마음으로 식당들을 엄선해놧었는데요, 막상 식당에 들어가니 쿨하게 결제만 먼저 해주시고, 멘토님은.. 가셨습니다...

이게 바로 학생들을 보는 사회인의 마음일까요? 절대 모두가 쉽게 할 수 있는 일은 아니라 생각하는데.. 지식 뿐만이 아니라 그 태도에서도 정말 많이 배울 수 있는 시간이 아니었을까 싶습니다. 저도 멋진 개발자가 돼서 또 다른 세상을 꿈꾸는 후배들에게 길을 제시해줄 수 있는 선배가 되고 싶네요 ㅎㅎ

여러분도, 새해 복 많이 받으시고 여러분 앞에 꿈꿔온 길을 걸어갈 수 있는 단단한 꽃길이 펼쳐지길 기원하며, 오늘의 포스팅 여기서 마치겠습니다.

이 자리를 빌어, 멘토님 다시 한 번 정말 감사했습니다!

네이버 D2SF 캠퍼스 창업 공모전

지원계기

저희는 챗봇을 도입한 서비스를 기획하고 있는 만큼 어떤 LLM을 사용할 것인지도 다양하게 고려를 해보았는데, 그 중 네이버의 하이퍼 클로바 X가 상당히 매력적으로 다가왔습니다. 하이퍼 클로바의 논문을 인상깊게 읽기도 했고, 한국어에 강점을 보이는 모델이라고 생각했기 때문이죠. 그러나 해당 모델은 B2B로만 제공되어 저희로서는 사용이 어려운 상황이었습니다. 그런데 D2SF 창업 공모전에 선발이 되어 인큐베이팅 단계에 들어가면, 하이퍼 클로바 X의 크레딧과 네이버 엔지니어 분들의 멘토링까지 받을 수 있다는 소식에 해당 공모전을 준비해보게 되었습니다.

디자이너 섭외

이 공모전에 지원하기 위해서 팀 리코딩은 디자이너를 모셔왔습니다😆 Cora 님께서 팀 프로젝트로 알게된 분인데요, 흔쾌히 참여해주시겠다고 하셔서 정말 감사했답니다. 지원 기간에 중간 시험이 겹쳐 많이 힘들었지만, Cora님과 디자이너님은 밤새 시험공부를 하고, 저와 cathy님은 옆에서 지원 자료를 만드는 방식으로 정말 열심히 준비했답니다👍 한 차례 만든 IR 자료를 디자이너님께서 정말 가독성 좋게, 세련되게 다듬어 주셨어요.

교수님과의 피드백

저희가 이 공모전에 지원한다고 하니, 졸업 프로젝트의 담당 교수님께서 감사하게도 IR 자료의 검토를 도와주시겠다고 하셨습니다. 공모전 마감이 얼마 안남은 시점이었던지라, 무려 밤 11시에(!) 줌미팅으로 피드백을 받게 되었어요. 정말 꼼꼼하게 피드백 해주셔서 한 차례 지원서와 자료를 업그레이드 할 수 있었습니다.

탈락의 고배를 마시다

과정은 정말 힘들었지만, 공모전을 위해 IR 자료를 다듬고 저희 서비스를 검증하기 위한 질문을 스스로에게 수도 없이 던지면서 팀 리코딩은 모두가 성장할 수 있었습니다. 그러나 아쉽게도 공모전 합격은 하지 못했답니다😂

교내 SW 창업 경진 대회

또 다른 도전

한 차례 탈락의 고배를 마셨지만, 그것으로 좌절할 우리 팀이 아닙니다! 저희는 교내 SW 창업 경진 대회에도 네이버 D2SF 공모전에 출품했던 자료를 보충하여 지원했답니다. 그 결과 본선에 진출할 수 있었어요🥳

본선

본선은 현직에서 활동 중이신 VC 선배님들을 모시고 진행되었습니다. VC분들 앞에서 직접 저희의 프로젝트를 소개할 시간을 갖고, 질의응답을 하는 자리였죠. 이번 발표는 cora 님께서 맡아주셨는데, 연극 동아리 경력을 살려 유창하고 생동감이 넘치는 발표를 해주셨습니다.

입상

이 경진 대회에서 저희 팀은 장려상으로 입상하게 되었습니다! 이때 탄 상금으로 즐겁게 회식도 했답니다🙌 하지만 이것으로 만족할 팀 리코딩이 아니기에, 방학 때 더 구체적으로 서비스를 발전시켜 보려고 합니다.

우리의 정기 회의 날짜

저희는 방학 동안의 정기 회의 날짜를 정했습니다. 기존에는 졸업 프로젝트 수업 후에 자연스럽게 정기 회의를 진행했다면 방학에는 각자의 일정을 고려해서 새롭게 회의 날짜를 잡아야했습니다.

모두의 일정을 고려한 결과, 일주일 간 프로그래스 공유 및 회의 미팅은 금요일 오후 6시로, 개발 및 기타 작업을 진행하는 미팅은 일요일 오후 1시로 정해졌습니다. 일요일에 진행하는 미팅은 거의 모같코(모여서 같이 코딩)에 가까운 미팅입니다. 오후 1시부터 저녁까지 쭉 진행하고, 저녁 식사도 같이 하는 미팅인데요, 저희 팀이 지난 주 일요일에 먹은 맛있는 볶음밥도 같이 공유해드립니다👍

방학 스프린트 계획

정기 미팅일이 정해진 후에는 방학을 2주 스프린트로 나누어 계획을 짰습니다. 마침 방학이 딱 목요일에 끝나기 때문에, 금요일 회의~다다음주 목요일까지 4번의 스프린트를 만들 수 있었습니다.

각 스프린트에는 저희가 완성해야 하는 중요한 기능이 있는데요, 이 기능은 깃허브 [feat] 보다는 좀 더 큰 단위이고, 전체 프로젝트보다는 좀 더 작은 단위입니다. 몇 개의 feature 모음이라고 보시면 될 것 같습니다.

방학 동안에는 프로젝트의 MVP를 완성하는 것이 목적인 만큼, 주로 AI 관련해서 스프린트를 구성해보았는데요, 저희 팀의 스프린트 계획을 공유해드립니다.

참고로 코라님이 굉장히 마음에 들어하신 스프린트 계획이었습니다.😀

지금까지의 1주차 스프린트 진행상황

그럼, 지금까지의 스프린트 진행상황은 어떻게 될까요? 저희는 지금 첫 번째 스프린트의 절반을 진행했는데요, 첫 번째 스프린트의 상세한 계획은 다음과 같았습니다.

이중에서 저희는 지금 요구사항 명세서 작성을 마치고, 화면 구성을 진행하고 있는 단계입니다. 각 기능 별 요구사항의 디테일, 담당자, 태그, 최종 승인 여부, 그리고 마감일까지 설정해 놓았는데요, 저희 팀이 섬세하게 작성한 요구사항 명세서의 일부분을 보여드립니다.

이 뿐만 아니라 저희는 좀 더 효율적인 협업을 위해서, 방학 온보딩 때 깃허브 컨벤션 또한 정리했습니다. 제가 일차적으로 정리하고, Chaen님과 코라님의 적극적인 의견 제시로 완성된 깃허브 컨밴션의 일부를 살짝 보여드립니다.

cathy가 관찰한 각자의 방학 생활

그럼, 졸업 프로젝트 이외에도 팀 리코딩은 어떤 삶을 보내고 있을까요? 놀랍게도 다들 정말 빡빡한 일정을 소화하고 있습니다...!

먼저 코라님은 겨울방학 기업 인턴에 합격해 FE 개발자로 일하고 있습니다🎉 저희 팀에서 유일하게 이번 겨울 방학 때 기업 인턴을 진행하게 된 코라님인데요, 덕분에 9-6라는 규칙적인 삶을 살게 되어 매우 건강해지셨다고 합니다. 코라님은 이번 겨울 방학 때 클라이밍도 하고 계신데, 방학이 끝나면 정말 저희 팀의 최강이 되실 것 같습니다.

Chaen님은 놀랍게도 인공지능 랩실에서 3개의 프로젝트(!)를 진행하고 계십니다. 제가 Chaen님처럼 프로젝트를 진행하려면 몸이 3개쯤은 있어야 할 것 같습니다. 더불어서 저희 학교에서 진행하는 코칭 프로그램에 지원해 맨토로써 인공지능을 다른 학우들에게 가르쳐주신다고 하는데요, 저도 개인적으로 정말 배우고 싶습니다.🤓

저는 우선 팀장인만큼 졸업 프로젝트를 열심히 진행하고 있습니다. 여기에 더불어, Chaen님과 같은 인공지능 랩실에서 2개의 프로젝트를 진행하고 있습니다. 그리고 스케이트보드 동아리의 회장이 되어, 이번 겨울 방학 동안 동아리를 운영하고 있습니다.

또한, 저희 모두 개발 동아리에서 겨울 방학 동안 진행하는 공모전이 있는데요, 짧은 시간안에 기획~개발까지 모두 완료해야 하는 만큼 매우 집중적으로 프로젝트를 진행해야 할 것 같습니다🔥🔥

여기까지가 팀 리코딩의 방학 생활이었습니다. 여러분들의 겨울 방학 계획은 어떠신가요?👍

중간 발표

저희 팀은 기획 내용을 간단하게 1분 30초 내로 정리하는 중간 발표를 진행했었습니다. 엘레베이터 스피치에 가까운 발표였고, 발표는 제가 진행했었습니다.

발표에서 가장 강조하고 싶었던 부분은 "메모장과 같은 간편함"이었습니다. 같이 졸업 프로젝트를 진행하는 다른 팀들이 청취자인 것을 고려해 졸업 프로젝트 일정 관리가 어렵다는 공감대를 형성하고, 이를 NESS의 메모장과 같은 간편함으로 해결할 수 있다는 솔루션 제공을 하고자 하였습니다. 저희 팀의 많은 고심이 드러나는 발표 스크립트는 아래와 같습니다.

📌 발표 스크립트 안녕하세요, 37팀 리코딩입니다. 저희는 편리한 일정 관리를 원하는 2030을 위한 생성형 AI 기반 스마트 스케줄링 웹 서비스를 만들고 있습니다. 여러분, 요새 중간발표 준비하느라 다들 할 일이 많으셨죠? 저도 일정이 너무 많아서 깜빡하고 놓치기도 하고, todomate나 구글 캘린더에 정리하다가 포기하기도 했습니다. 이런 문제점이 생기는 이유는 기존 서비스들은 단순히 일정을 기록하는 역할만 보조할 뿐, 능동적으로 관리해주지 못하기 때문인데요, 이때 생성형 AI 기반 스마트 스케줄링을 통해 일정 관리를 혁신적으로 개선할 수 있습니다. 사용자는 마치 메모장에 쓰는 것처럼 입력창에 자유롭게 일정을 적으면 됩니다. 그러면 AI가 해당 일정을 언제, 어디서, 누구와 일정을 할지 자동으로 정리하고 카테고리로 분류해줍니다. 이 뿐만이 아니죠, 마감일이 가까워진 일정은 리마인드 시켜주기도 하고, 사용자의 일정을 기반으로 스트레칭 등의 활동을 추천해주기도 합니다. 이렇게 저희 서비스는 메모장의 단순함과 전문 스케줄링 서비스의 기능성을 하나의 플랫폼에서 통합해 제공합니다. 단순한 일정 관리를 넘어서 인공지능 비서와 가까운 서비스를 제공하는 것이 목표인데요, 이를 달성하기 위해 추후 음성인식으로 사용할 수 있는 앱 어플리케이션 출시 또한 목표하고 있습니다. 이런 서비스가 있으면 졸프 관리도 정말 편해지겠죠? 지금까지 37 팀 리코딩이었습니다. 감사합니다.

NESS의 아키텍쳐

중간 발표때는 메모장과 같은 간편함을 강조했지만, 이내 저희는 사용자가 입력한 내용의 에러 충돌 등을 해결하기 위해서는 AI가 피드백을 다시 전달하는 과정이 필수적이라는 것을 알게 되었습니다.

또한, 사용자 맞춤형 개인 비서를 만들기 위해서는 사용자의 기존 데이터를 LLM이 전달 받을 수 있는 방법이 필요하다는 결론에 도달했습니다. 이에 따라서 저희는 1) 챗봇 형식의 비서로 변경하게 되었고, 2) 사용자의 기존 데이터를 제공해 줄 수 있는 Vector DB를 사용하게 되었습니다.

이런 과정을 통해 만들어진 저희 서비스의 아키텍쳐와 기술 설명은 아래 글에서 좀 더 자세하게 확인하실 수 있습니다.

글 바로가기: NESS의 1차 아키텍쳐 구성

깃허브 & 노션 정리

최종 발표에는 간단한 데모 영상을 보여줬어야 했는데요, 저희 서비스의 MVP인 ChatGPT API를 사용한 채팅을 데모로 보여주기 위해서 개발을 진행했었습니다. 시간관계상 데모에서는 프론트에서 바로 API를 호출했지만, 깃허브에는 AI 백엔드에서 Langchain을 통해 OpenAI API를 호출하는 코드도 올라와 있습니다.

깃허브 바로가기: 팀 RE:CODING의 깃허브

참, 그리고 저희 팀의 노션 페이지가 정리 되었습니다. 슬로건은 "Build for better world!"입니다. 노션 페이지를 정리하고 나니 좀 더 체계가 잡힌 기분인데요, 이제 개발이 본격적으로 시작되면 여기에 깃허브 컨벤션이나 API 명세서 같은 내용이 추가될 예정입니다.

최종 발표

최종 발표는 그동안 저희 팀의 기획부터 기술 탐색까지의 모든 과정을 다 담아내는 일이었습니다. 5분 정도 되는 발표였고, 발표는 chaen님이 진행해 주셨습니다.

먼저 저희 팀의 기획이 녹아 있는 엘리베이터 스피치를 확인해보실까요?

또한, 저희 팀이 기획하고 있는 최종 아키텍쳐는 다음과 같습니다. 프론트엔드는 코라님이, AI는 chaen님이, 그리고 백엔드는 제가 담당할 예정입니다. 앞으로 방학 동안에는 이렇게 역할을 분담하고 서비스의 MVP를 만드는 것이 목표입니다. 그 중에서도 저희 서비스의 핵심인 AI 관련해서 많은 시간을 투자하게 될 것 같습니다.

여기까지가 저희 팀의 2학기 진행상황이었습니다. 2학기는 기획 마무리 및 기술 탐색(그리고 팀원들 각각의 학업)에 많은 시간을 쏟았는데요, 방학 동안에는 개발에 더 많은 시간을 쓰려고 합니다.

그럼 나중에 방학 회고록으로 다시 돌아오겠습니다😊

👩🏻‍💻 자기 소개 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 팀 re:cording은 “사람들이 정말 쓸만한 서비스를 만들고 싶다”라는 열정 아래에서 만들어졌습니다. 좋은 서비스를 만들기 위해서 저희 팀은 끊임없이 다시 코딩하고, 새롭게 코딩하고, 또 새로운 것을 코딩하려 합니다.

아키텍쳐 구상도

어느 정도 기획이 마무리가 됨에 따라서 서비스의 아키텍쳐도 일차적으로 완성되었습니다. 완성된 아키텍쳐는 아래와 같습니다.

그럼 지금부터 각 요소를 살펴보겠습니다.

기술 요소

⛓️Langchain

Langchain은 LLM 기반 어플리케이션을 구축하게 쉽게 해주는 파이썬 라이브러리입니다. 여러 LLM 모델을 Chain으로 연결하는 것도 가능하고, LLM이 적절한 툴을 쓰게 하는 것도 가능합니다.

혹시 LLM이 수학 계산을 정확하게 하진 못한다는 점을 아시나요? LLM의 기반인 트랜스포머 모델은 가장 정확도 또는 유사도가 높은 문장을 출력해주는 것일 뿐, 정확한 정보를 출력해주진 않습니다. 이를 할루시네이션(Hallucination, AI가 잘못된 정보나 허위 정보를 생성하는 것)이라고 하죠. 유명한 사례로는 '세종대왕 맥북프로 던짐 사건'이 있겠습니다.

그러나 Langchain을 쓴다면 LLM이 수학 도구인 'llm-math'를 사용하게 만들 수 있습니다. 이를 통해서 LLM의 할루시네이션을 줄일 수 있습니다.

from langchain.agents import load_tools
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
# LLM에게 툴 제공
tools = load_tools(["llm-math"], llm=llm)

물론, Langchain은 수학 도구 뿐만 아니라 다른 많은 기능들을 제공합니다. 이렇게 AI 모델을 사용하기 편리하게 만들기 위해서 Langchain을 도입하려고 합니다.

⚡FastAPI

Langchain을 도입함에 따라서 AI 백엔드로는 파이썬 기반 프레임워크가 필요했습니다(물론, Langchain을 쓰지 않더라도 AI를 다루려면 파이썬을 써야 하는 것은 당연합니다). FastAPI는 flask보다는 더 발전된 기능을 가지고 있고, Django보다는 간단한 최신 파이썬 웹 프레임워크라고 할 수 있습니다.

API 문서를 자동 생성해준다는 점, 파라미터 기반 API 입력 설계로 간단하다는 점에서 저희 팀은 FastAPI를 선택했습니다. 물론, 무엇보다 중요한 점은 저희 팀에 Django 개발자가 없고, 그렇다고 Flask를 선택하기에는 AI 백엔드로써는 다소 부족한 점이 많다는 것이 선택의 가장 큰 이유였습니다.

🔵chroma

Chroma는 Vector 기반 데이터베이스입니다. 그렇다면 Vector는 무엇일까요? 이는 백터 임베딩이라고도 하며, 데이터 객체의 수치 표현입니다.

예를 들어, 현재 입력한 채팅 내용과 비슷한 과거의 채팅 내역을 찾아주고 싶다고 가정해보겠습니다. RDB에 String 값으로 채팅 내역을 저장한다면, 어떻게 비슷한 과거 채팅 내역을 찾을 수 있을까요? 유사도 알고리즘을 따로 구현해주어야 할까요? ML/AI 모델로 유사도를 검사해야 할까요?

Vector DB는 자산(채팅 내역)의 의미와 컨텍스트를 백터로 저장하기 때문에 이러한 문제를 쉽게 해결할 수 있습니다. Vector DB를 통해 인접 데이터 포인트(즉, 유사한 과거 채팅 내역)을 쉽게 찾아내고 그 결과를 반환할 수 있기 때문입니다.

저희 팀에서는 사용자 맞춤형 인공지능 비서를 만들고자 하는 만큼, 사용자의 과거 채팅 내역 등의 정보를 LLM에 프롬프트와 같이 전달해야 합니다. 따라서 Vector DB를 도입하기로 결정했습니다.

🤖RAG Based LLM

위에서 언급한 LangChain, Vector DB와 함께 다음과 같은 패턴을 구현할 수 있습니다.

LLM에 프롬프트를 보내기 전에, 먼저 1) 관련 데이터를 Vector DB에 검색하고, 2) 관련 데이터를 프롬프트와 함께 LLM에 요청하는 것입니다. 이러한 패턴을 RAG(Retrieval-Augmented Generation)라고 합니다.

저희 팀에서는 사용자가 프롬프트를 보내면, 1) 먼저 Vector DB에서 관련 사용자 데이터를 검색하고, 2) 그 결과와 프롬프트를 함께 LLM에 전송하여, 3) 사용자 맞춤형 인공지능 비서를 만들기 위해서 위와 같은 패턴을 선택하게 되었습니다.

RAG와 관련된 더욱 자세한 설명으로는 저희 팀의 AI 엔지니어이신 chaen님(별명: 루비언니)이 작성하신 티스토리 글을 첨부합니다. 📝 RAG이란?: https://chaerryos.tistory.com/3

🪣S3 Standard

S3는 AWS의 데이터 가용성, 보안 및 성능을 제공하는 객체 기반 스토리지 서비스입니다. 저희 서비스에서는 이미지 파일 등을 저장할 때 사용할 예정입니다.

그렇다면 왜 S3일까요? 알다시피, AWS에는 EBS라는 블록 기반 스토리지도 있습니다. EBS는 EC2를 생성할 때 자동으로 부착되는 SSD입니다. 왜 블록 스토리지를 쓰지 않을까요?

가장 큰 이유는 S3 버킷의 경우 무한 확장이 가능하다는 점입니다. 컴퓨터를 사용할 때 가끔 저장공간이 부족해 문제가 생기셨던 경험이 있다면 이해가 쉬울 것 같습니다. 그러나 S3 버킷은 무한확장이 가능하기 때문에 위와 같은 문제를 고민할 필요가 없습니다. 또한, AWS S3에서는 각 객체(즉, 이미지)에 대한 URL을 생성해줍니다. 이 URL만 DB에 저장해준다면 사용자들은 하나의 엔트포인트로 이미지에 접근하는 것이 가능해집니다.

저희는 이 중에서 자주 액세스하는 데이터를 위한 클래스인, Standard Class를 사용하려고 합니다.

🛣️Route 53

Route 53은 AWS에서 제공하는 DNS입니다. DNS란 도메인 이름에 대한 적절한 IP 주소를 알려주는 서버입니다.

저희가 일반적으로 알고 있는 'google.com'과 같은 이름은 도메인 이름이라고 합니다. 그러나 구글의 서버 IP 주소는 따로 있습니다. 원래대로라면 IP 주소를 입력해야 서버에 접근 가능한 것이지만, DNS를 통해 기억하기 쉬운 도메인 이름만 주소창에 입력해주면 적절한 IP 주소를 알 수 있습니다.

이러한 기능을 하는 것이 바로 AWS의 Route 53입니다. 간단하게 말해서, 저희 서비스에서는 저희 도메인 이름과 EC2의 IP 주소를 변환하기 위해서 Route 53을 사용합니다.

🤐ACM

저희 서비스에서는 AI 모델을 쓰는 만큼 보안이 중요합니다. 보안을 위해 HTTPS 프로토콜을 쓰기 위해서 AWS의 ACM을 사용하려고 합니다. ACM은 쉽게 말해서 보안 인증서로, 이 인증서를 통해서 secure한 HTTP 프로토콜, 즉 HTTPS를 사용할 수 있습니다.

마무리

여기까지 해서 NESS의 1차 아키텍처가 구상되었습니다. 물론, 아직 전체를 테스트한 것은 아니기 때문에 얼마든지 변경될 수는 있습니다. 그러나 코어 기능인 RAG 패턴은 반드시 구현하는 것이 이번 프로젝트의 목표입니다.

그럼, 아키텍쳐가 새롭게 변경되면 다시 포스팅으로 돌아오겠습니다!

👩🏻‍💻 자기 소개 안녕하세요! 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 팀 re:cording은 “사람들이 정말 쓸만한 서비스를 만들고 싶다”라는 열정 아래에서 만들어졌습니다. 좋은 서비스를 만들기 위해서 저희 팀은 끊임없이 다시 코딩하고, 새롭게 코딩하고, 또 새로운 것을 코딩하려 합니다.

👩🏻‍💻 자기 소개 안녕하세요! 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 팀 re:cording은 “사람들이 정말 쓸만한 서비스를 만들고 싶다”라는 열정 아래에서 만들어졌습니다. 좋은 서비스를 만들기 위해서 저희 팀은 끊임없이 다시 코딩하고, 새롭게 코딩하고, 또 새로운 것을 코딩하려 합니다.

방향 전환

지난 번 담당 교수님과의 회의(가차없는 피드백)을 통해 저희 팀은 방향성을 전면 수정하게 되었습니다. 그 동안의 서비스 방향성은 정말 애매하다는 생각이 많이 들었어요. 개인의 할 일 목록 정리도 해주고 싶고, 그런데 한편으로는 그룹 스터디도 지원하고 싶고, 그 와중에 인공지능도 넣어보고 싶고…

이런 방향의 서비스는 이도저도 아닌, 실제 사용자가 쓰고 싶어 하는 기능은 거의 없는 서비스가 될 것이라는 생각이 들었습니다. 또한, 1년 동안 프로젝트를 진행하는 만큼 팀원 모두에게 Challenge가 될 수 있는 부분이 분명히 있어야 한다는 생각이 들었죠. 지금의 프로젝트 방향성은 겨울 방학 동안 몰두하면 충분히 1~2달 만에 끝낼 수 있는 프로젝트가 될 텐데, 그럼 과연 이 프로젝트를 졸업 프로젝트로 하는 의미가 있는가? 사이드 프로젝트만으로 충분히 할 있는 서비스 아닌가? 라는 고민이 강하게 들었었죠.

팀원 모두에게 도전 과제가 될 만한 부분은 당연히 인공지능이 될 텐데, 담당 교수님이 인공지능은 개인화에 적합한 것이라는 지적을 수용하면 그룹이 아닌 개인에 집중해야 한다는 생각이 들었죠. 이런 고민을 하다가 저희는 예전에 했던 설문조사에서 76.2%나 되는 사람들이 핸드폰 메모장이나 캘린더 등의 기본 어플을 쓴다고 답변했던 내용이 기억났고, 이를 바탕으로 “사람들에게 일정 기록에 대한 측면에서 높은 자유도를 주자. 그 대신 인공지능이 개인 비서처럼 일정을 정리하게 만들어주자!”라는 결론이 나왔습니다.

타임라인을 정리해보면 다음과 같이 되겠네요.

• 9월 초: 설문조사 결과를 통해, 사람들이 기본 앱을 통해 일정을 기록한다는 사실을 알게 됨. 그 이유를 높은 자유도 덕분으로 생각함.
• 9월 중순: 기존의 그룹 스터디 지원 서비스로의 한계를 느끼고, 교수님과의 면담을 통해 인공지능을 서비스에 넣으려면 개인화에 집중해야 한다는 점을 깨달음.
• 9월 말: 서비스 방향을 인공지능을 통한 개인화 방향으로 대폭 수정함. “개인 비서”에 집중한 서비스를 만들기로 결정함.

물론 이러한 방향성은 저희가 의도했거나 예측한 것이 전혀 없었고, 그 당시에는 이런 식으로 타임라인이 정렬될 것이라는 것도 전혀 몰랐습니다. 그저 그 순간에만 최선을 다했을 뿐이죠😊 이렇게 두고 보니, 스티브 잡스가 스탠포드 대학에서 연설했던 내용 중 “Connecting the dots”가 생각나네요.

어쨌거나 저희 팀은 개인 비서로 방향성을 정한 후, 그럼 인공지능을 어떻게 활용할 것인 지에 대해서 논의하기 위해 하루 종일 회의하는 날짜를 잡기로 했습니다.

인공지능 활용 방안 회의(09/17)

하루 종일 회의하자고 제안한 사람은 저였는데요, 각 잡고 딱딱하게 하는 회의를 원한 것은 전혀 아니였고 오히려 느슨하면서 가끔 딴 짓도 하고 팀원들과 같이 밥도 먹으러 가는 그런 회의를 원했었습니다.

창의력이 부족하고 아이디어가 떠오르지 않을 때는 의외로 일상적인 일을 하는 것이 돌파구가 될 때가 있더라구요. 이런 일상적인 모임을 위해서 팀원들에게 긴 시간을 할애해 줄 것을 요청 드렸었습니다. 다행히 모두 동의해 주셔서 회의를 가지게 되었답니다🥰

우선 저는 그 동안 팀 내부에서 생각해 낸 인공지능 활용 방안을 좀 정리하는 시간을 가져야겠다는 생각이 들어, 아래 피그잼 보드를 회의 전에 만들었습니다. 그동안에 했었던 보고서 형식 정리가 아니라, 자유로운 토의 시간을 만들어 보고 싶어서 포스트잇을 붙이는 것 같은 템플릿을 선택했었죠. 그리고 저희가 방향성이 아직 정해지지 않은 만큼 보고서처럼 명료하게 정리하는 게 어려웠고요.

각 아이디어는 최우선 순위, 넣고 싶은 기능이지만 아직 애매함, 차순위, 기타로 분류해서 고민했습니다. 최우선 순위에는 위치 설정, 요약 기능, 사용자 맨션, 요일/시간 분류 및 루틴, 카테고리화 등이 있었는데요, 이것들은 다른 기능에 비해 간단하면서도 꼭 필요한 기능이라는 생각이 들었었습니다. 하지만 팀원들과 토의를 나누어보니 비교적 명확하지 않은 부분도 있었죠. 카테고리는 개발자가 미리 다 만들어 놓고, 인공지능을 통해 분류만 하는 건가? 아니면 인공지능이 카테고리까지도 생성해주는 건가? 이런 부분들을 토론하면서 저희는 2차 교수님 미팅을 가져야겠다는 생각이 들었습니다.

또한 넣고 싶은 기능이지만 아직 애매함 분류에 있는 것들은 “중요도로 할 일 정렬”, “추천 시스템”처럼 기능 자체는 굉장히 유용하지만, 기준이 무엇이 되어야 하는지나 인공지능이 사용할 feature는 무엇일지 등이 명확하지 않은 것이었습니다. 이 부분은 여러 기준을 더 고민해 보는 방향으로 생각해보기로 했습니다.

차순위 분류는 분석 리포트나 노션 연동처럼, 있으면 흥미로울 것 같지만 지금 당장 개발해야 하는 핵심은 아니고 나중에도 얼마든지 추가할 수 있는 부분이었죠. 우선 이 분류에 속하는 아이디어들은 기록만 해 놓고 자세한 부분은 아직 논의하지 않는 것으로 결정했습니다.

이렇게 기능 중심으로 토의를 하다 보니 자연스럽게 우리 서비스가 어떤 UI/UX를 가지고 있어야 할 지가 머릿속에 떠오르는 것 같았어요. chaen님과 cora님도 이런 생각이 자연스럽게 들으셨는지, 아무도 UI/UX를 그려보자고 말하지 않았는데 자연스럽게 화면 구성을 하고 있었죠. ChatGPT처럼 자유롭게 사용자가 자신의 할 일을 적는 메모장 구역+일정을 정렬해서 보여주는 캘린더 구역 구성으로 만들어졌고, 그 후에 좀 더 구체화가 되어 추천하기, 리마인드, 오늘의 할일 구역 등이 추가되었죠.

앞으로 나아가기

새롭게 정해진 서비스 방향은 저희가 기획 초기에 전혀 생각해 본 적 없는 방향이었지만 매우 마음에 들었어요. 저는 개인적으로 영화 <아이언맨>의 인공지능 비서 JARVIS를 꼭 만들어보고 싶다는 생각을 했었는데, 비슷한 서비스를 만들게 되어서 정말 신났습니다. 다른 팀원분들도 새롭게 바뀐 방향이 재밌겠다고 말씀해주셔서, 약간은 느슨해졌던 방향성이 확고하게 정해진 것 같습니다.

앞으로 저희는 여러 번의 지도 교수님 면담과 멘토님 면담을 바탕으로 서비스를 구체화하려고 합니다. 앞으로도 저희 re:coding 팀을 지켜봐주세요!

처음으로 아이디어를 선보였던 시간

졸업 프로젝트가 시작하기 전 방학 때부터 저희는 매주 회의를 통해 아이디어를 발전시켜왔습니다. 아이디에이션을 거쳐 대략적인 화면 구성을 짜고, 핵심 기능에 대한 설문조사까지 마쳤습니다. 기획 단계가 꽤 진전이 되었음에도 불구하고 여태까지 저희의 아이디어를 다른 사람에게 선보이고, 객관적인 평가를 들어볼 기회는 없었습니다. 마침 졸업 프로젝트의 지도교수님과의 컨택이 이루어져 저희 아이디어에 대한 조언을 구할 수 있는 시간을 가졌습니다.

저희는 인공지능을 활용하여 개인화 된 경험을 제공할 수 있는 기능을 추가해보고 싶었고, 교수님께서도 인공지능에 조예가 깊으신 분이라 브레인스토밍을 통해 몇 가지 기능을 추려 준비해갔습니다.

저희가 생각하고 있는 핵심 아이디어, 대략적인 화면구성, 설문조사 결과와 그에 따른 인공지능 활용 방안을 간략히 말씀드렸습니다.

터닝포인트

교수님과의 면담에서 저희 아이디어에 대한 객관적인 평가를 들어볼 수 있었고, 저희가 프로젝트를 준비하며 가지게 되었던 고민들도 나눌 수 있었습니다. 또한, 인공지능 활용을 위해 생각했던 기술들에 대해서도, 충분히 알고리즘으로 구현할 수 있음에도 인공지능으로 비싸게 구현하려 하는 것은 아닐지, 과연 인공지능까지 사용할 가치가 있는 태스크일지 재고할 수 있는 시간이었습니다. 무엇보다 이 면담이 저희에게 터닝포인트가 되었던 점은, 저희의 핵심아이디어였던 그룹 스터디가 매력적으로 어필이 되지 않는다는 점이었습니다.😂

위기는 회의로 이겨내자

저희는 면담 이후 핵심 아이디어를 변경해야 할 필요성을 느끼고, 방향성을 재정비하기 위한 회의를 가졌습니다.

러프한 아이디어를 점점 구체적으로 발전시켜오며, 제게 두 가지 고민이 머릿속에 자리잡게 되었습니다.

1. 현재 우리가 핵심 아이디어로 내세우는 것은 스터디를 위해 그룹을 지어주는 것인데, 이 기능을 인공지능을 이용해 발전시키거나 보완하는 것은 한계가 있지 않을까?

   인공지능은 주로 개인화된 경험을 제공하기 위해 이용됩니다. 저희가 면담 전 생각했던 기능들도 자동 스케줄링, 요약, 태그 생성과 같은 기능들이었는데요, 이 기능들은 그룹 스터디보다는 개인 일정관리에 더 적합한 기능에 가깝죠. 그룹을 위한 인공지능 활용 방안은 ‘스터디 그룹 추천 기능’(매칭 시스템) 정도에 불과했습니다.

   사람들은 그룹스터디를 할 때는 자신의 개인적 목표는 드러내고 싶어하지 않기 마련입니다. 특히나 목표나 성취에 민감한 한국인이라면 더 개인적 목표를 드러내는 데에 민감한 사람들이 많겠지요?😕 그룹 단위로 관리가 이루어질 땐 개인정보는 생략되고 그룹으로 뭉뚱그려져 개인 각각을 관리하기 어려워집니다. 여기에 인공지능을 활용해보려니, 개인의 목표관리와 그룹의 목표관리 사이에서 길을 잃게 되었다는 생각이 들었습니다.

2. 그래도 졸업 프로젝트인데, 기술적으로 challenging한 부분이 부족한 것은 아닐까?

   저희는 올해 내에 프로토타입 제작을 마치고, 겨울부터 곧장 구현에 들어가려는 계획을 세우고 있었습니다. 기획 단계에서 고군분투하고 있기는 하지만, 막상 기획 단계가 끝나면 구현을 하는 일은 여타 사이드 프로젝트들과 다르지 않을 것이라는 생각이 들었습니다. 아무래도 학생들이 하는 프로젝트인만큼 엄청난 기술력이 있는 것도, 엄청난 자본이 있는 것도 아니니 보여줄 수 있는 것은 열정과 도전의식일텐데, 지금까지 나온 아이디어에서는 기술적으로 도전해볼 만한 부분이 부족했죠.

cora님과 cathy님도 면담 이후 각자 고민해왔던 부분을 공유해주었고, cathy님이 브레인스토밍을 위해 가져오신 노트에 다같이 낙서하듯이 자유롭게 의견을 나누어 보았습니다.

cathy님께선 사용자가 극단적으로 자유로운 입력을 줄 수 있도록 하여 일정관리의 번거로운 부분은 모두 인공지능이 처리할 수 있는 방향으로 전환하자는 의견을 주셨습니다.

cora님 역시도 저희 프로젝트에 challening한 부분이 부족하다는 의견을 주셨습니다. 이어, cathy 님의 의견을 발전시켜 인공지능이 비서와 같은 역할을 하면 좋겠다는 아이디어를 제시했습니다. 일정을 입력했을 때 기존이 일정과 총돌되는 부분을 해소해주는 것부터, 사용자의 효율적 시간관리를 위해 해야 할 미션을 적극적으로 제시해주는 방법까지 다방면으로 사용자를 서포트할 수 있도록 생각의 폭을 발전시켜 주었습니다.

회의를 통해, 저희는 여태까지 발전시켜왔던 아이디어의 원점으로 돌아왔습니다.

어떻게 하면 목표관리를 편하고 부담없이, 효율적으로 할 수 있을까?

저희 팀 전원이 핵심 아이디어를 바꾸는 방향으로, 인공지능 기술을 보다 적극적으로 활용할 수 있는 개인 목표 관리로 전환하는 것에 동의하였습니다. 여태까지 그룹 관리 기능을 위해 고민했던 시간들도 아깝게 느껴졌고, 설문조사까지 실행했음에도 불구하고 전혀 다른 방향으로 가야한다는 것이 뻐 아프게 다가왔습니다. 그러나 여태까지 열심히 해왔기에 이러한 좌절도 일찍 겪는 것이라 생각하며, 이 보 전진을 위한 일 보 후퇴라며 서로를 격려할 수 있었습니다.🤗

뭔가,, 정말 처음 보는 사람도 할 수 있게끔 자세하게 적으려다 보니까,, 굉장히 길어서 글을 좀 나눠야 될 거 같긴 한데,,, 그럼에도 뭔가 빠뜨린 부분이 있어서 헷갈리실 거 같기도 하고,,

네, 이렇게 밑밥을 깔고, Cora가 말아주는 Github 및 VS Code 사용법 1탄! 시작해보겠습니당~

ps. 이 게시글은 깃허브 계정은 만들어봤고, 깃이 노트북에 설치되어 있으며, 브랜치도 뭔지 대충 들어봤다, 느낌은 알겠다! 하시는 분들을 위한 글입니다

git과 github를 사용하는 데에는 수많은 방법이 있지만, 내가 쓰는 방법이 나는 제일 편해서(?) 쓰는 Tech Note.

1. 레포지토리 만들기

레포지토리라는 건 말 그대로 저장소를 뜻합니다. 우리가 만든 파일들을 웹 상에 저장해놓는 공간으로, 하나의 프로젝트를 진행할 때 필요 및 기능에 따라 레포지토리를 생성하곤 하죠. 저는 한 프로젝트 안에서 프론트엔드, 백엔드로만 나눠서 레포지토리 만들어봤는데, 필요에 따라 AI 레포가 생길 수도 있고, Android 레포가 생길 수도 있는 느낌!

깃허브 사이트에서, 이번 프로젝트에서는 개인 계정이 아닌 오랑이라는 Organization에 속해있다고 해봅시다! Organization이란, 그냥 여러 사람들이 함께 속해있는 account. Owner가 여러명이라는 것 외에 개인 계정과 (나한테 특별히 느껴지는) 큰 차이점은 없음. (배포할 때의 제약사항 등이 있는데, 이건 배포 편에서... to be continued~)

Orang2E 홈에서 Repositories 클릭 => Create a new repository 클릭

자, 이제 여기서!

Repository name : 말그대로 생성하는 저장소 이름. 다른 레포지토리랑 이름 안 겹치게 지어주면 되고 대충 우리가 만드는 프로젝트 이름이 Orang2E면 Orang2E-FE(프론트엔드가 쓰는 레포지토리) 이런 식으로 지음.

Public/Private : 레포지토리, 그러니까 여기에 올리는 파일들을 다른 사람들도 볼 수 있게 공개할 건지 안할 건지. 보통 나중에 포트폴리오 낼 때 깃허브 주소 내는데 소스코드를 많이들 보려하시기 때문에 + 개발자 사이의 염탐을 위해 public으로 많이들 해놓는 편인 것 같습니다.

Add a README file은 왠만하면 꼭 체크해주기로 합시다. 이 레포지토리로 한 프로젝트가 무엇인지 설명해줄 수 있는 아주 소중한 파일이 되기 때문이죠..

이런 느낌....이랄까! 심지어 동영상도 넣을 수 있음. (바리바리 안뇽!)

이러한 과정이 끝나고, 아래에 create repository를 누르면, (문구 다시 적어서 달라졌지만 쨌든 description에 적은 문장이 자동적으로 readme 파일에 추가됩니다.) 레포 생성 완성!!!

여기까진 별 문제 없이 오셨겠죠?!

그러면, 실제 프로젝트를 시작했다고 생각하고 VS code를 사용해서 파일을 생성 및 저장해 봅시다!

일단, 처음 만들면 main branch가 딱 하나 있습니다. 이 main 브랜치는 가장 root가 되는 브랜치인 만큼, 얘가 꼬였다? 그러면 그냥 새로 레포지토리 파는 게 나을수도.. 있을 만큼 노답이 되기 때문에 거의 프로젝트 막바지까지 왠만하면 건들지 않습니다. ❌❌❌❌❌

그 대신, 바로 밑 브랜치로 보통 dev 브랜치를 파서 거기서 뽕짝뽕짝 머지하고 뭐하고 해서 준최종본을 취합한 다음!! main 브랜치로 머지 시켜서 완성시켜 배포를 하곤 하죠.

그렇다면 dev 브랜치 밑에는?!?! github이란 자고로 협업을 위한 사이트. 사실 저 혼자 프로젝트 할 때는 그냥 dev 브랜치에서 다 만들고 main으로 머지만 시킬 때가 많습니다. 그게 편하고, 나는 다 아니까요!! 하지만, 남들과 같이 작업을 하는데 하나의 브랜치에서 같이 작업한다?

이거 네가 건드렸니...? 아니? 이거 네가 만들었어? 엥...?

(절망)

결국 브랜치는 따로 작업하고, 합치고, 이걸 더 편리하게 해주는 기능이랍니다!

그래서 보통은 기능별/페이지 별로 브랜치를 파고, 각자 역할을 맡아서 개발한 다음 좌자자작 합치게 됩니다.

그러니까, main | dev |--------------------|------------------| (feat/homepage-ui) (feat/Login-ui) (feat/info-ui)

대충 요롷게 되는 구조! (어, feat는 뭐에요? 아, 그렇게 많이 쓰더라고요. 네, 뭐 기능적 차이가 있는 건 아니고... 보기 편하고 구분하기 편하라고...)

그럼 이제 본격적으로 깃을 사용해볼까요?

처음 깃을 접하고,,, 저는 근본적인 의문을 품었죠.. 그래서 이게 뭔데? 왜쓰는데?

그리고 이제야! 저는 (저에게는) 깔끔한 대답을 찾게 됩니다.

대답 : 와이파이 되던 안되던 데이터 되던 안되던 내 노트북이건 남 노트북이건 언제 어디서든 작업 하려고요 ㅠ

와이파이 데이터 안돼요! : 아 일단 로컬에서 개발 갈기다가 나중에 연결되면 원격에 올려놔 헉 노트북 놓고 왔다... : 깃에서 다운 받아서 이어서 작업해 엥 나 저장공간 부족해서 3번째 버전 노트북에서 지웠는데 그때로 코드 되돌리고 싶어 ㅠ : 깃에 다 버전 저장 해놨으니까 그거 써

. . .

깃을 간단하게(?) 말하면, 어디서든 접근할 수 있는 원격(사이트)에도 저장소를 둬서, 내 작업, 나아가서 여러 명이서 하나의 서비스를 만드는 작업을 용이하게 만들어주는 서비스라고 생각해요.

그럼 이런 깃을, 저희는 vs code를 사용해서 쉽게 사용해봅시다.

일단, vs code를 킵니다. 그러면,

이렇게 Start에서 clone git repository가 보이는데요.

안보인다고요?? 아 그러면 깃을 안 다운받으신 겁니다. 설치 기릿기릿

설치를 끝내셨다면, 다시 깃허브 사이트로 돌아와서

상단의 초록색 code를 눌렀을 때 HTTPS에 뜨는 저 주소를 복사해줍니다..

그다음, 다시 vs code를 켜고,,!

[여기서 잠깐] vs code는 밑에 커서를 두고 클릭해 위로 올리면, 터미널 창이 생겨난다.

여기 보라색에 잘 커서를 올려보면, 파란색이 뜨면서 커서가 바뀌는 지점이 있습니다. 그대로 누르고 쭉 위로 당기면

이런 터미널이란 명령 프롬포트(명령어로 컴퓨터 작동시켜주는 거)가 뜹니다. 그럼 여기에 git clone (아까 복사한 주소) https://github.com/Orang2E/Test.git

이렇게 치면, 짜잔- 클론 완성!

또는,

Start 밑에 잇는 clone git repository를 누르면

이런 게 뜨는데, 여기에 https://github.com/Orang2E/Test.git 이것만 복붙해서 엔터를 눌러줘도 클론이 가능합니다!(짱편함)

대충 내 노트북 어디에 저장할지 선택하고, would you 블라블라 지금 열래? 이런 거 뜨면 open을 누르면,

요렇게 원격에 있던 저장소가 내 컴퓨터로 쇼숑 연결되어 들어와졌습니다!!

뭐가 바꼈냐고요? Open editors는 그냥 지금 열려져있는 창 말해주는 거고(컴터에서 웹페이지 창 여러개 띄워놓듯이!), 그 밑에! TEST 와 README.md 파일이 생겼습니다. 이것이 바로... 우리가 아까 만든 레포지토리가 그대로 내려온 것!

게다가 왼쪽 맨 아래를 보면,

이렇게 내가 지금 main 브랜치에 있음도 알 수 있습니다.

자, 그러면 브랜치 파서 작업한 후 합치는 작업을 한 번 해볼게요.

정석적인 방법은,

1) 로컬에서 A브랜치를 파고 거기서 작업을 하다가(원격엔 A브랜치 없는 상태) 2) 커밋을 날리면서 저 A브랜치 만들었어요! 하고 원격에 푸시를 해주면 3) 원격에도 A브랜치가 짜잔.. 하고 생기는 건데,

저는 뭔가 원격에 브랜치가 없는데 로컬에서만 작업을 하는 게 좀 무서워서(?) 깃허브 사이트(원격)에서 브랜치를 만들고, 얘를 pull 해서 로컬로 땡긴 다음, 거기서 작업하고는 합니다.

어쨌든, 그래요.. 정석으로 가보아요.

차례로

git branch dev (데브라는 이름의 브랜치를 만들어요. 하지만 저는 아직 main 브랜치에 있어요. 그래서 여기서 파일 작업을 한다면 dev가 아니라 main에 있는 파일이 수정되는 거랍니다)

git checkout (얘만 쳐주면 내가 지금 어느 브랜치에 있는지 알 수 있어요)

git checkout dev (데브 브랜치로 옮겨가겠습니다)

얘네를 터미널에 쳐주면,

이렇게 왼쪽 아래도 dev가 뜨고, 정상적으로 브랜치가 바꼈음을 알 수 있습니다.

어? origin/main 쟨 뭐예요?

아, origin이 붙어있다는 건, 원격(깃허브 사이트)에 있는 브랜치란 얘기입니다. 그래서 실제로 왼쪽 아래의 dev를 눌러보면,

origin/main은 있지만 origin/dev는 없는 것을 알 수 있습니다.(dev는 아직 로컬에만 있는 브랜치니까!)

자, 그럼 여기서... vscode의 편리한 점.

여기서 3번째, 저 신경망 같은 아이콘을 클릭해 보아요.

그럼 이런 화면을 볼 수 있는데, 이 창은 바로 원격에 업로드 되지 않은 모든 로컬의 변경 사항들이 어떤 게 있는지, 얘네를 원격에 푸시시켜줄 건지를 알려주는 창입니다. 원래는 터미널에서 텍스트로 봐야 되는 걸 조금 더 편리하게 만들어놓은 ui/ux 서비스인 거죠!

지금, 우리가 로컬에만 dev 브랜치를 만들었으니, 저 publish branch라는 것은 너의 변경 사항을 원격에도 반영할래? 라는 것이고,

쟤를 눌러주면, 빙글빙글 돌아가다가

요런 창이 뜨고,

이렇게 깃허브 사이트에도 dev 브랜치가 생겨납니다!

(짱편)

자, 그러면, 드디어 파일을 vs code로 커밋시켜 봅시다.

이 테스트 위에 마우스를 올리면 저렇게 파일이나 폴더를 추가할 수 있는 창이 뜨는데, 보통 pages/ images/ icon 등등의 폴더를 만들고, 그 아래에 파일을 만듭니다. 그러면, Home.html 이라는 파일을 한 번 만들어 볼게요.

대충 이렇게 파일을 생성시키면, 파일 오른쪽에 하얀색 동그라미가 생기는데 얘는 아직 변경 사항이 저장 안됐다는 소리니까 꼭 컨트롤 s 눌러서 저장해줍니다. 그러면 왼쪽 맨 위 아이콘의 1은 사라지고, 3번째 아이콘 연결망 친구에만 이렇게 1이 남는데요..! 이건 바로, 로컬에서 새롭게 바뀐 파일이 1개라는 것!

자, 원래라면

이렇게 터미널로 적어서

git status: 지금 커밋을 위한 저장소의 상태가 어떤가용? => 당신은 지금 dev 브랜치에 있고, pages/라는 untracked된, (아직 로컬에서만 저장되어 있고, 커밋하기 전 단계의 커밋을 위한 저장소에도 가있지 않은) pages/ 폴더가 있습니다. git add pages/: 아 그러면 pages/ 폴더 안의 새롭게 추가된 친구들 커밋을 위한 저장소에 넣어주세요. git status: pages 폴더의 Home.html이라는 파일이 새롭게 커밋을 위한 저장소에 추가되었습니다. git commit -m “feat: Home 페이지 추가” : feat: Home 페이지 추가 라는 메세지와 함께 커밋을 때릴게요

ps) commit 한다는 건, 무엇일까요? 저는 a little bit 느낌적으로 이해하는데, 로컬과 원격 그 사이에서 파일을 정리해주는...? 역할이랄까요? 왜 커밋이 필요하냐면,, 나중에 개발하다 보면 이거 개발하다 저거 개발하다 마구잡이로 왔다갔다 하는데, 그 때 그냥 한 번에 푸시시켜 버리면(원격에 올려버리면), 아 내가 저번에 로그인 만들던 기록이 어딨지? 하면서 엄청 찾아야 합니다..(아찔) 하지만, add와 커밋을 통해 로그인 만들던 파일들만 모아서 “fix: 로그인 기능 수정” 이런 식으로 커밋을 해주면, 찾기 편해지겠죠?!

git push : 오키오키 그럼 지금까지 커밋한 내역들 찐으로 깃헙 원격에 올립니다!! (원래 git push origin/dev, dev 뭐 이런 식으로 써줘야 하는데, 걍 git push 해도 잘 올라가더라... )

그리고 깃헙 가서 “dev 브랜치로 바꾸고”(중요) 보면

짜잔- 잘 올라가 있네용!

하지만,, 버뜨... 처음 이거 보면? 쏘 복잡쓰.... 머리 엉킴쓰... 먼지 모르겠음... 터미널 뭔가 무서움....

그럴 때 vs code 잘 사용하면? 넘나리 편해지는 것.

자, 그러면 이번엔 터미널 말고! vs code의 ui/ux들만 사용해서! login.html과 Info.html을 만들어 봅시다.

대충 이렇게 만들면, 파일 두개 추가했으니까 신경망(?) 아이콘에도 두개가 뜨겠죠? 그럼 여기서! 신경망 아이콘을 한 번 눌러봅시다.

짜잔. 저기 Changes에 있는 파일들은 위에서 말한

git status: 지금 커밋을 위한 저장소의 상태가 어떤가용? => 당신은 지금 dev 브랜치에 있고, pages/라는 untracked된, (아직 로컬에서만 저장되어 있고, 커밋하기 전 단계의 커밋을 위한 저장소에도 가있지 않은) pages/ 폴더가 있습니다.

에서 untracked된 파일들을 담당하고 있습니다.

여기서 각 파일 위로 마우스를 올리면,

저 플러스가 보이는데! 쟤를 눌러주면

요로코롬 뜨는 거, 보이시죠! 이 +는 git add와 같아서, 지금 commit을 위한 저장소에 Login.html을 넣어줬다는 뜻!!

그리고 저기 위에 Message에

이렇게 치면 얘가 아까 그 git commit -m “~” 물결에 들어가는 커밋 메세지이고,

커밋을 눌러주면, 커밋이 쇼숑 되고

Info.html만 남습니다.

여기서 잠깐! 이 상태에서 git push를 터미널에 쳐주면, 무슨 일이 벌어질까요(?)

The Answer is...

커밋해놓은 Login.html만 원격에 업로드 되고, Info는 커밋 안해놨으니까 아직 남아있음.

오, 방금 이 말이 이해가 됐다면, 당신은 커밋의 개념을 제대로 파악하고 계신 겁니다!

근데 이제 보통은 하나 커밋하고 푸시하고 하나 커밋하고 푸시하고 이러진 않고, 커밋을 쌓아놨다가 한 번에 푸시하고 그러기도 합니다. 완전 자기 마음.

그럼 마저 Info도 커밋하면,

이렇게 뜨게 됩니다! Sync 체인지즈 2. 2개의 커밋, 변화의 싱크를 맞춘다, 즉? 푸시 때려서 원격에 올려 원격과 로컬의 싱크를 맞춘다!

쟤를 클릭해주면

쇼쇼숑

여기서 오른쪽 위의 4 commits를 클릭해보면,

이렇게 커밋한 내역이 뜨게 됩니다. 커밋 성공!!

이제 우리는, 아... 코드 개꼬였다 어카지 싶을 때마다 내가 정리해놓은 코드의 변화 내역을 싸그리 다 감상하며, 리프레쉬한 개발을 할 수 있게 되는 것입니다!!

아, 그리고 마지막으로!!

저기 커밋 메세지 앞에 붙이는 feat은 무엇인가요?

라는 질문을 하고 싶으셨다면,,,!

간단히 말해 협업 규칙인데, 어떤 의미의 커밋 내역인지를 서로 쉽게 알 수 있도록 분류시키는 머릿말입니다! 팀마다, 사람마다 다를 수 있으므로 서로 초반에 정해놓고 통일시켜서 그대로 사용하면 되는데, 보통

feat: 기능 추가했을 때 fix: 오류나 잘못된 거 고쳤을 때 mod: 수정사항 있을 때 style: css 관련된 것

이 정도를 기본으로 두고 쓰는 것 같아요.

TMI로 feat: 이런 모양일 수도 있고 [feat] 이런 모양일 수도 있으니 팀에서 잘 정하기!!

자 그래서 이렇게 커밋 기능별로 잘 하면서 만들고, 풀리퀘 하고 머지 시키고 그렇게 그렇게,,, 쇼쇼숑 개발을... 같이 해나가면... 멋진 서비스가.. 완성되어 있겠지요...?

여러분의 개발 라이프에,, 건승과 희망과 건강과 머니가 깃들길 바라며,, 오늘의 긴 글을 마치겠습니다.... (여기까지 다 읽으신 그대에게 축복이...) 좋은 하루 되세요!

👩🏻‍💻 자기 소개 안녕하세요! 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 다른 한편으로 저는 스케이트보드에 열정이 가득한 사람이기도 한데요, 오늘은 특별히 팀 re:cording의 보드타는 날, 스포츠 데이를 다루고자 합니다.

우리 보드 타요

아무리 프로젝트를 하고 있더라도 가끔은 다른 활동도 좀 해줘야죠😉

저희 팀은 9월부터 스케이트 보드 동아리를 들어가 같이 운동을 하고 있는데요, 저는 이미 예전부터 들어가서 보드 연습을 하던 동아리지만, Cora님과 Chaen님은 처음이라 보드 위에 올라타는 부분부터 연습하고 계십니다.

이번 금요일은 저희 3명이서 함께 보드를 탔던 첫 수업이었는데, 사실 저는 여러 기물들이 있는 2층에서 주로 수업하고 Cora님과 Chaen님은 평평한 1층에서 주로 주행 연습을 하고 계셨습니다. 빨리 다들 자유롭게 주행을 할 수 있게 되면 좋겠습니다. 그 다음에 오는 어려운 기술들을 같이 연습해보고 싶어요.

아래 사진은 1층에서 주행 연습을 하던 Cora님을 제가 슬쩍 찍은 사진입니다!

보드장에서 서로의 보드를 자랑하는 사진을 한 번 찍어보았습니다. 제 스케이트 보드는 커스텀으로 맞춘 보드랍니다😎 다른 분들은 보드장에서 빌린 대여용 보드였는데, 나중에 본인 보드를 구매할 의사가 있다고 하시네요.

지금 보니 저희 모두 파란색 보드네요!

수업 끝!

수업이 끝나고 나서 저는 간단하게 펍에 가서 음료를 마셨습니다. 보드를 타고 난 후 마시는 술…아니 음료가 가장 맛있는 것 같아요.

Cora님과 Chaen님은 일요일 아침부터 알바가 있는 관계로 함께하지 못했습니다😢 하지만 보드는 매주 있으니 다음 기회를 노려보도록 하겠습니다.

너무 즐거운 수업이었고, 특히나 금요일 저녁이라서 더욱 기분 좋은 마음으로 집에 돌아갈 수 있었던 것 같습니다.

re:coding 팀은 저번주에 설문조사를 완성하여 주변 친구들에게 열심히 조사참여와 홍보를 부탁했습니다. 그 결과 127명이나 되는 분들이 조사에 참여해주셨습니다. 절대적인 수로는 부족해보일 수 있지만, 많은 분들이 시간을 내주어 조사에 참여해주셨기에 팀원들 모두가 기쁜 마음으로 미팅을 시작할 수 있었습니다.

이번 주에는 설문조사 결과를 보며 섹션 별로 분석해보는 시간을 가졌습니다.

섹션 1 : 공통문항

성별과 연령대에 대해서는, 20대 여성의 응답이 가장 많았습니다.

첫 질문으로는 계획을 관리하는 방법을 물어보았습니다.

저희가 놀랐던 점은 핸드폰, 메모장, 캘린더 등의 기본 어플의 이용 비율이 매우 높았다는 점입니다. 복수 선택이 가능했으므로 응답을 다시 검토한 결과, 핸드폰 메모장만 쓰는 사람은 10명으로 그리 많지 않았습니다. 즉, 다른 어플이나 기록장을 사용하더라도 기본 메모장을 함께 사용한다는 것을 알 수 있었습니다. 메모장 자체는 큰 기능이 많지 않아도 접근성이 뛰어난 어플이기에 사용 비율이 높다는 결과가 나왔다고 추측할 수 있었습니다. 급하게 기억해야 할 일이 있을 때, 빠르게 메모를 적어야 할 때는 이 내용을 어디에 적어야하는지 깊게 생각할 여유가 없으니 자연스럽게 메모장으로 손이 가게 되는 것처럼요.

따라서 메모장처럼 줄 글로 일정을 입력하면 알아서 해당 날짜에 일정이 추가되는 기능을 넣어보자는 아이디어가 나왔습니다.

다음은 목표 관리에 대해서 알아보았습니다.

cora님께서 항목 별 지켜지지 않은 목표의 비율을 계산해주셨습니다👍

• 공부 및 학습(37/83=45% )
• 다이어트 및 미용(5/19=26% )
• 생활습관(19/29=66%)
• 업무 및 커리어(4/42=10%)
• 운동(20/41=49%)

개별 인터뷰가 아니라 왜 해당 목표를 지키지 못했는지 자세히 알 수는 없었지만, 강제성이 높은 업무 관련 항목은 지켜진 비율이 높았던 반면 강제성이 낮은 생활습관 항목은 잘 지켜지지 못한 확률이 높았습니다.

즉, 저희가 개발하고자 하는 서비스에서 강제성을 부여해주는 기능이 필요하다고 느꼈습니다. 하지만 강제성이 부담감으로 이어지면 안되기에, 목표를 리마인드해주고 달성까지의 과정을 즐거운 게임처럼 느낄 수 있도록 디자인 되어야 한다고 생각했습니다.

섹션1의 마지막 질문은 그룹활동 경험의 유무에 대한 조사였습니다. 이는 섹션2와 섹션3에서 그룹활동 경험이 있는 사람과 그룹활동 경험이 없는 사람으로 나누어 설문을 받기 위한 질문이었습니다.

섹션 2 : 그룹 활동 경험이 있는 사람을 대상으로

섹션2에서는 그룹활동으로 목표관리를 하였던 방식을 조사했습니다.

설문 조사 결과 카카오톡 오픈 채팅방을 통한 비대면 그룹 활동이 많았고, 열품타 등의 목표 관리 어플리케이션을 사용한다는 응답이 가장 적었습니다. 시장 조사 결과와 합쳐서 생각해보면, 스터디만을 위한 독보적인 어플리케이션은 없는 것으로 보이고, 따라서 가장 친숙하고 편리하게 사용가능한 카카오톡을 주로 사용하는 것으로 보였습니다.

이 결과를 보고 저희는 각 스터디의 목적에 최적화된 기능을 제공할 수 있는 방법은 없는지 고민해보아야겠다는 생각이 들었습니다. 공부 스터디라면 시간 인증, 코딩 스터디라면 깃허브 링크 인증, 그림 스터디라면 그림 사진 인증을 할 수 있도록 뒷받침 해줄 수 있다면 좋을 것이라 생각했습니다.

그룹 활동 시 가장 어려움을 겪었던 점에 대해서도 조사해보았습니다.

조사 결과 스터디를 성실하게 참여하는 것과 스터디원들이 적극적으로 참여하지 않는 것이 가장 힘들었던 점으로 꼽혔습니다. 즉, 나 자신이 성실하지 않은 것+다른 사람들이 성실하지 않은 것이 힘든 점으로, 전부 성실하게 스터디에 참여하는 게 가장 큰 난관으로 보입니다.

이를 해결하기 위해서는 찌르기 기능이나, 게임형 요소 등 다양한 방식을 활용하여 지속적인 참여를 유도해야한다고 생각했습니다.

또, cathy 님이 챌린지 기능을 통해 그룹별 세부 목표를 설정하자는 아이디어를 제안했습니다.

그룹 활동 시 인증 방식에 대해서도 조사해보았습니다.

조사 결과 인증 사진을 통한 인증 방식이 -다른 모든 종류의 방식을 합친 것보다도 많았습니다. 따라서 예상 외로 특정 링크를 보내주는 식의 인증은 IT 계열 쪽에서나 많은 것으로 보이고(깃허브, 블로그 링크 등), 대부분은 사진 업로드를 통한 인증을 진행하는 것 같다는 결론이 나왔습니다.

사진 인증을 주 인증 방식으로 채택한다면, 사진을 편집할 수 있는 기능도 어플에 필요하다고 생각했습니다. 또한, 사진이 많이 업로드 됨에 따라 최적화를 잘해야겠다는 의견도 있었습니다. 한편으로는 인증사진은 하나하나가 특별한 의미를 지니기 보다는 반복적인 성격을 갖게 되므로, 모든 사진을 저장하기 보다는 일주일 분량만 저장하도록 제한하고 모든 사진의 저장을 위해서는 요금제 구독을 요구하는 BM이 제시되기도 했습니다.

인증방식의 효과를 묻는 질문에 대해 평균적으로는 효과적이라고 응답하였지만, 매우 효과적이었다는 답을 선택한 비율은 매우 적었습니다. 이는 인증 방식 자체의 문제였다기보다는 스터디 자체가 성공적으로 끝나지 않았기 때문에 매우 효과적이라는 답변은 없는 것처럼 보였습니다.

설문 조사 결과 인증이 필요하다고 생각하는(4~5) 비율이 전체의 80% 이상으로 굉장히 많았습니다. 인증에 대해 부담감을 느끼고 있을 거라는 예측과는 달리, 스터디 서비스를 사용할 유저들은 인증 과정을 필수로 생각하고 있었습니다. 효과적이되 부담감이 적은 인증 방식의 필요성이 다시금 강조되는 부분이었습니다.

그룹 스터디를 했었다는 사람 중에는 카카오톡 오픈채팅방을 통해서 목표 달성을 했다는 사람들이 압도적으로 많았습니다. 이는 카카오톡이 대부분의 핸드폰 사용자들에게 기본적으로 깔려 있고, 따라서 접근성이 편리하며 다양한 그룹방을 만들기도 편리하기 때문이라고 생각했습니다. 또한 그룹 스터디 특성상 가까운 지인과 진행하는 경우가 많은데, 이 경우 스터디 외의 사담을 나누기에도 카카오톡이 편리하기 때문입니다. 따라서 스터디 그룹마다 개별 채팅방을 제공하자는 아이디어가 나왔습니다.

섹션 3 : 그룹 활동 경험이 없는 사람을 대상으로

섹션3은 그룹 활동 경험이 없는 사람을 대상으로 한 질문들로 구성된 만큼, 가장 처음으로 그룹 활동에 참여하지 않는 이유에 대해 질문했습니다.

그룹 활동에 참여하지 않는 이유들이 대체로 고르게 분포되어 있었지만, 다른 사람들과 개인적인 목표를 공유하는 것이 불편하다는 이유가 가장 많았습니다.

이를 해결하기 위해서는 두가지 방향성이 제시될 수 있다고 생각했습니다. 첫번째 방향성은 목표관리를 극도로 단순화한 형태로 제공하는 것입니다. 현재 저희 어플의 방향성은 이쪽에 가까운, 반복 업무에 적합한 어플입니다. 두번째 방향성은 항목에 따른 공개/비공개 범위를 지정하여 개인적인 내용이 들어간 항목은 비공개로 전환할 수 있는 기능을 제공하는 것입니다. 이는 반복 업무보다는 개별 일정이나 이벤트 관리용 어플에 적합한 기능이라고 생각하기에, 이 솔루션은 보류하기로 했습니다.

위에서 선택한 불편한 사항이 해결될 경우, 그룹 활동을 통한 목표 관리 서비스를 사용할 의사가 있다고 응답한 사람이 과반수 이상이었습니다. 따라서 현재 그룹 활동을 하지 않는 사람이라도 우리 어플을 언제든지 사용할 가능성이 있는 잠재적 고객으로 간주하고, 앞서 언급되었던 불편한 사항들을 해결하기 위한 기능을 고안해보기로 하였습니다.

그룹 활동 경험이 없는 사람들 중에서는 인증이 필요하다고 생각하는 사람들이 압도적으로 많았지만, 그룹 스터디 경험이 있는 사람들의 응답과 비교했을 때 5점을 기록한 인원의 비율이 적었습니다.

공동의 목표관리를 선호하지 않는 사람들 또한 열품타, 투두메이트 등의 목표관리 어플을 사용한 사람들이 많았습니다. 이는 이 어플들이 개인 목표 관리 기능 또한 제공하기 때문인 것으로 판단되었습니다. 따라서 저희가 공동으로 목표를 관리할 수 있는 어플 개발을 목표로 하고 있지만, 그룹으로 목표를 관리하는 기능 뿐만 아니라 개인의 목표를 관리하는 기능이 필요하다고 생각했습니다.

설문조사를 마치며

막연하게 어렵지 않을 것이라 생각하고 시작했지만, 질문 선정부터 응답자 확보, 응답 분석까지 무엇 하나 쉬운 과정이 없었습니다. 최대한 주관성을 배제하고자 하였지만 조사 결과 분석 시에는 어디까지가 객관적인 시각인지 판단이 어려워 머리를 부여잡았답니다😂

설문조사까지 마친 re:coding은 여태까지 나온 의견들을 정리하여, 본격적으로 요구사항 명세서와 러프한 프로토타입을 만들고자 합니다.

(대충 이 옷 사고 싶다는 얘기)

------------------사담 절취선-------------------

이번 2탄에서는, 1탄에서 다뤘던 설문조사 작성 이후부터 설문조사 분석 전까지의 과정을 간단하게 적어보려 해요.

일단, 무엇보다도 가장 저희가 바랐던 건, 많은 표본을 확보하는 일이었는데요! 확실히, 설문조사를 마친 지금까지도 아쉬운 점은 대부분의 응답자가 20대였다는 것입니다. 그런데 또 어떻게 생각해보면 결국 제작하는 앱도 20대인 저희가, 문제점을 발견하고 IT 기술을 통해 편의성을 증진시키고자 하는 만큼 타겟 사용자도 첫 시작은 2030에 집중하여 진행하는 게 맞지 않을까 하는 생각도 했답니다.

그래서, 약 3주간의 기간 동안 응답자수를 늘리기 위한 눈물나는 노력이 펼쳐집니다.

이 이후로 우리의 디스코드 공지방은

와 같은 지인 콘테스트 인증 캡쳐글로 한동안 넘쳐났답니다

그 결과! 약 130여 개의 응답을 받을 수 있었는데요. 물론, 정식 설문조사에 비하면 그리 크지 않은 수치일 수 있으나 질문들이 복잡하지 않아 나름의 경향성을 찾아낼 수 있었는데요, 이게 정말 유의미한 수치였는지는 실제로 서비스를 배포해보면 알 수 있겠죠?

분석하는 과정에서도 굉장히 흥미롭고, 저희의 가설과는 사뭇 다른 의외의 점들도 발견할 수 있었는데요, 그 자세한 분석 관련 글은 chaen에게 맡기며, 저는 더 나은 서비스 제작을 위해(?) 떠나보겠습니다... 그럼, 모두들 좋은 하루 되세요!!

이번 글에서는,, 이제 저희가 대략적인 주제 선정과 기획 초안 제작을 마치고! 사용자들의 의중을 알아보고자,, 설문조사를 준비 및 진행해보았는데요!

처음부터 기획을 진행해 보니, 이 실 사용자가 될 수도 있는 대중들을 향한 설문조사의 중요성을 정말 절실히 느낀 것 같아요. 왜냐! 저희가 아무리 머리를 싸매고 고민해봤자 여기에 모인 머리는 셋... 경험도 셋... 제품을 팔아야 하는 판매자의 입장에서 실제 고객들이 우리의 서비스를 지속적으로 사용하게 만들기 위해 그들을 직접적으로 파악하고 싶다는 욕구가 컸고, 만약 실제 배포를 위해 투자 유치를 받아야 한다거나, (졸프 발표를 한다거나) 하려면 평가자들이 논리적으로 설득될 수 있는 배경 정보들이 필요할 거라 생각을 했어요! 그래서 저희에겐 두 가지의 목표가 생겼는데!

두둥- 탁!

1. 응답자들의 표본이 너무 치우치지 않는 상태에서 최대한 많은 응답을 받아보자.
2. 설문 조사의 원칙에 잘 맞는 좋은 질문들을 뽑아보자.

사실 저희가 속단 집단이 제한적이다 보니, 다양한 표본 집단의 질문을 받을 수 있는 방법에 대해 고민을 많이 했어요.. 사실은 현재 진행형이긴 한데~ 이건 저희가 멋있게 목표를 완수한다면 다시 글을 쪄보도록 하겠습니다... 이 글을 읽으시는 분들도 여기 설문조사 부탁드림다! (꾸벅)

그리고 두 번째, 좋은 질문들을 뽑아보자.... 이게 막상 설문지를 만들려 하니,,,, 공댕쓰 셋,,,, 통계도 수학으로 배우다...... 분명 치우치지 않고 좋은 데이터를 뽑아내기 위한 원칙과 베이스들이 있을 텐데, 너무 막막해서 저희는 각자 통계에 대해 공부를 하고, 각자 질문지를 만들어와보기로 합니다... (이 열정 뭐죠)

그 결과물=> 0823 회의록 (회의록도 꼬박꼬박 잘 쓰는 리코딩팀(팀장 쵝오))

여기에 정리된 것 외에도, 각자 통계에 대해 정리해온 부분을 발표하고, 얘기를 나누는데 설문조사... 어려워요... 하지만 우리 열쩡 팀원들과 함께 하니!! 겹치는 부분도 많고 어느 정도 가닥이 잡히더라고요!

그리고, 저희가 초반 기획이나 브레인스토밍할 때도 얘기를 한 거지만, 너무 조급해하지 말고 차근차근 단계를 기초부터 탄탄하게 밟아가기로 약속을 했는데요! 그래서 설문 조사도 너무 많은 질문을 담거나, 이 한 번에 모든 걸 파악하려 하기 보단, 여러 번 진행해도 좋으니 각 단계에서 정말 우리에게 필요한 정보들을 잘 정리해서 얻어보자 라는 결론을 얻었답니다!!

하지만 또 모든 과정이 쉽기만 하면 재미가 없죠...(과연?) 각자 공부해온 것들이 다양하고 방향성이 다채로운 만큼 그 모든 걸 하나로 합치려니 어느 순간 회의가 진행되지 않고 제자리를 맴도는 것 같더라고요... 이럴 때 필요한 게 뭐다? 바로 휴식!!

팀플 만렙 우리의 팀원들은 회의가 거의 3시간을 향해가자 ? : 우리... 이번 회의 여기서 끝내고 다시 각자 생각해본 다음에 다시 회의할까?
? : 아주 좋은 생각이야...

이렇게 또 서로 생각이 다른 부분이 있다는 걸 느낀 저희는 빠르게 토론이 이뤄졌던 지점, 생각이 다른 지점, 생각지 못했던 지점들을 타다다닥 정리를 하고, 각자 생각해보자! 라는 말과 함께 회의를 종료했답니다!!

저는 이 부분이 정말 저희 팀의 큰 장점이자 좋은 점이라고 생각을 해요 ㅎㅎ 의견이 다를 때 바로 끝장을 보자거나? 내 의견만 고집한다거나? 아니면 이렇게 다음에 얘기해~ 하면서 회피해놓고 똑같은 논쟁 다음에 또 하는 게 아니라 상대방의 의견을 귀담아 듣고, 시간을 두고 자신의 생각과 비교하며 고민해본 다음, 더 나은 결과물을 들고 다시 모이는 거요!! 저희 팀원들 정말.. 사랑합니다^^

그렇게 제주 여행을 갔던 저는(TMI) 제주 공기를 마시며 힐링을 마치고

(급 사진 자랑)

현실로.. 돌아와 ㅠㅠ 다시 회의를 진행했는데요! 그 결과, 아래와 같은 (제가 보기엔 나름) 깔끔한 설문지를 만들어 배포할 수 있었답니다! 서비스 사용 조사 설문

간단하게 설명을 드리면,

저희는 각 연령대와 성별, 전공 및 직업에 따른 현 목표 관리 방식의 추이성을 확인할 필요가 있다고 생각했어요. 저희가 주 타겟으로 하고 있는 1020 세대는 주로 학업을 위한 목표 관리가 많을 것이고, IT 계열은 github 링크 같은 임베디드가 필요할 수 있고, 헬스나 건강을 위해서도 목표 관리를 많이 사용할 것이다 등등의 가설을 검증하고, 미처 생각하지 못한 부분을 보고자 했거든요. 그래서 위와 같은 기본 정보 질문을 통해 미리 파악하고자 했습니다.

그리고 아직은 저희가 세부적인 기획이 들어가기 전이기 때문에, 목표 관리 앱 사용이나 서비스 이용 여부에 대해 묻기 보단, 지금까지 응답자들이 어떤 목표들을 세워왔는지, 그 목표라는 것을 어떻게 대해왔는지, 관리해 왔는지 파악하고자 했습니다! (2탄에서 계속)

아이디에이션 이후…

아이디에이션 이후에는 우리가 공통적으로 넣고싶은 요소들을 추려보았습니다.

1. 커뮤니티 서비스 : 다른 사람들과 협력을 통한 유대감을 느낄 수 있을만한 요소기 있으면 좋겠다고 생각했습니다.
2. 개인맞춤형 서비스 : 인공지능을 활용하여 맞춤형 통계를 제공하거나, 사용자의 입맛에 맞게 커스터마이징을 할 수 있는 요소가 필요하다고 생각했습니다.
3. SNS에 공유할 만한 요소 : 기존 사용자가 사용 화면을 SNS에 공유하여 새로운 사용자를 끌어들일 수 있는 요소가 필요하다고 생각했습니다.

이 세가지 요소들을 기반으로 경쟁서비스를 분석하고, 브레인스토밍을 해보았습니다.

경쟁서비스 비교 분석

생산성 관련 서비스를 위주로 강점과 약점을 비교분석해보았습니다.

커뮤니티 서비스

커뮤니티 서비스의 비교분석 대상으로는 포레스트, 인아웃, 열품타가 제시되었습니다.

• 포레스트 : 협업이 중심인 어플은 아니지만, 협업의 결과를 시각화 할 수 있다는 점이 장점이다.
• 인아웃 : ‘그룹하우스’와 같은 게임요소를 도입하여 다이어트를 부담스럽지 않게 만들었고, 익명 소통이 가능하다. 단, 다이어트 강박이 심해진다는 후기들이 많았다.
• 열품타 : 실시간으로 공부시간이 반영되며, 익명으로 공부방에 참여 가능하다. 그러나 공부를 하는 척 위장하기가 쉽다.

개인맞춤형 서비스

개인맞춤형 서비스로는 웰마인드, 제페토, 썸원이 제시되었습니다.

• 웰마인드 : 직장인의 스트레스를 ai로 분석하여 멘탈케어를 제공하는 어플이다. 웨어러블 기기에서 받아온 생체정보와 환경 정보, 업무 및 스케줄 정보를 수집하여 사용자의 스트레스를 분석하고 예측한다. 업무 과부하를 인지하면 사용자의 스케줄을 재구성한다.
• 제페토 : 사용자가 원하는 대로 캐릭터 커스텀이 가능하다. 그러나 팬데믹이 끝나며 메타버스에 대한 수요가 줄고 있다.
• 썸원 : 연인들의 혈액형에 따라 캐릭터의 다양한 조합이 가능하다. 연애가 지속됨에 따라 캐릭터를 키워나갈 수 있다.

SNS에 공유할 요소

SNS 공유 요소가 들어간 비교분석 대상으로는 포레스트, mooda, 북모리, 내친소 개발자 테스트가 제시되었습니다.

• 포레스트 : 공부시간에 비례하여 나무가 많아지고, 원하는 나무들로 숲을 구성할 수 있다. 숲을 sns에 공유하여 공부시간을 인증할 수도 있다.
• mooda : 그날의 기분을 귀여운 아이콘 하나로 표현할 수 있다. 한 달을 채우면 아이콘으로 구성된 하나의 그림이 된다.
• 북모리 : 읽은 책을 기록하고, 원하는 부분을 이미지로 만들어 저장할 수 있다.
• 내친소 개발자 테스트 : 독특한 테스트 자체가 바이럴 마케팅으로 작용할 수 있다.

브레인스토밍

경쟁 대상 비교 분석과는 별개로, 저희가 꼽은 세가지 요소들을 발전시킬 수 있는 방향을 탐색하기 위해 브레인스토밍을 진행했습니다. 서로의 의견에 댓글을 달며 자유롭게 피드백을 주었습니다.

피드백이 끝난 뒤, 브레인스토밍한 내용에서 공통의 키워드를 찾아 다시 분류하는 작업을 거쳤습니다.

하고 싶은 것은 많지만…

경쟁서비스 분석과 브레인스토밍까지 마쳤지만, 넘쳐나는 아이디어를 하나로 모아줄 구심점이 없다는 문제에 부딪혔습니다.

긴급회의

구심점을 찾기 위해 저희는 두가지를 깊게 고민했습니다.

1. 우리의 핵심 아이디어는 무엇인가?

→ 공동의 목표 성취가 가능한 플랫폼을 만들자.

1. 우리가 여타 서비스들과 차별을 두고자 하는 부분은 무엇인가?

→ 그룹화, 거짓인증 방지, 장기 목표를 위한 동기부여.

이 두 가지에 중점을 두고 다시 아이디에이션을 한 결과, cathy님께서 가져오신 아이디어가 채택되었습니다.

👩🏻‍💻 자기 소개 안녕하세요! 팀 re:cording에서 팀장을 맡고 있는 cathy라고 합니다. 팀 re:cording은 “사람들이 정말 쓸만한 서비스를 만들고 싶다”라는 열정 아래에서 만들어졌습니다. 좋은 서비스를 만들기 위해서 저희 팀은 끊임없이 다시 코딩하고, 새롭게 코딩하고, 또 새로운 것을 코딩하려 합니다.

아이디에이션

1주차 미팅에서는 팀원들 모두가 앞으로 만들고 싶은 서비스를 고민하는 시간을 가졌습니다. 1주차에 주어졌던 가장 핵심적인 과제는 각자 만들고 싶은 서비스들을 생각해 오는 것이었는데요, 각 팀원들은 문제 인식, 현재 대안, 해결 방안, 비즈니스 모델을 기획해 왔습니다.

그럼 각 팀원이 생각해온 아이디어와 경쟁 서비스들을 아래 소개해드리겠습니다.

👩🏻‍💻 cathy

제가 생각해 왔던 서비스는 성취도 추적 및 공유 TodoList였습니다. 세상에는 정말 많은 투두리스트 관련 앱이 있지만 주로 개인에게만 초점이 맞추어져 있다는 점을 고려하여, SNS적인 기능과 성취도 추적 기능을 넣은 서비스를 만드는 것이 핵심이었습니다.

경쟁 어플리케이션으로는 대표적으로 투두메이트를 제시했는데, 해당 서비스는 투두리스트를 직관적으로 관리할 수 있고, 트랜디한 UI를 제공하지만 한편으로는 기능이 간단하고 타 SNS에 성과를 공유하기 어려운 방식이라는 문제점이 있었습니다.

이에 대한 해결 방안으로는 애플 피트니스 앱에서 제공하는 것처럼 직관적으로 성취도를 보여주는 UI를 만드는 것과, 스포티파이 앱에서 스크린샷을 찍을 경우 SNS에 공유할 수 있는 이미지를 생성해 주는 기능과 비슷한 공유 기능을 넣는 것이었습니다. 또한 노션처럼 다양한 맞춤형 기능을 넣고 싶다는 생각에 투두 탬플릿/테마 갤러리 기능을 제안해 보았죠.

비즈니스 모델로는 요새 가장 시장 지배적인 BM인 구독형 서비스를 생각해 보았고, 추가로 일정 관리 어플리케이션인 TimeBlock처럼 창작자들이 만든 테마를 구입할 수 있도록 하는 스토어 기능을 도입하는 방식을 제안했습니다.

👩🏻‍💻 cora

제가 생각했던 서비스가 주로 공유에 대한 것이었다면 cora님은 개인 맞춤형 서비스를 생각해오셨는데요, 인플루언서의 등장과 1인 콘텐츠 시장의 급격한 성장으로 인해서 미디어 플랫폼이 커졌지만, 개인 맞춤형 플랫폼은 없다는 것을 고려하여 서비스를 기획해오셨습니다.

경쟁 어플리케이션으로는 유튜브나 인스타그램처럼 대표적인 SNS를 생각해오셨는데요, 모두 성공적인 대규모 SNS 서비스이지만 한계점으로는 일률적인 서비스 방식으로 인해 개인의 특색이 부각되지 않는다는 단점이 있었습니다.

이에 대한 해결 방안으로는 심리 테스트, 퍼스널라이징 테마 제작 등의 개인 맞춤형 서비스 지원이 있었습니다. 그리고 또한 카테고리 페이지를 설정해 활동을 카테고리로 구분 지어 줄 수 있는 기능을 제안하셨습니다.

BM으로는 역시 대표적인 방식인 구독제와 광고 등을 제시해주셨습니다. 추가적으로 퍼스널라이징에 집중하신 만큼, 티스토리처럼 스킨을 판매하는 방식도 제안해 주셨습니다.

👩🏻‍💻 chaen

chaen님은 게임형 요소에 집중하셨는데요, 다양한 해빗 트래킹 서비스가 있지만 대부분의 경우 작심삼일로 끝난다는 점을 고려하여 이를 게임처럼 재미있는 방식으로 서비스하여 동기부여를 줄 수 있는 아이템을 생각해오셨습니다.

이에 게임형 요소를 도입한 수면 패턴 관리 서비스인 pokemon sleep를 제시해 주셨는데요, 포케몬이라는 강력한 캐릭터 IP에 기반한 서비스이긴 하지만 무언가를 키워내고, 도감을 채우는 등의 수집욕을 자극하는 아이디어 자체가 강력한 실행 동기가 될 수 있다고 설명해 주셨습니다.

해결 방안으로는 위에서 자세하게 설명했던 것처럼, 보상을 제공해주는 게임형 요소 도입과 게임 커뮤니티처럼 소셜 그룹을 형성하도록 하는 것이 있었습니다.

비즈니스 모델로는 흥미로운 기사와 함께 ‘부분유료화’라는 BM을 제시해 주셨는데요, 기본 기능은 무료로 제공하고 확장된 기능을 유료로 제공하는 방식이었습니다. 밀리그램, 노션, 열품타 등의 다양한 서비스가 해당 기능을 도입하고 있는 것으로 유명하죠. 아래에 chaen님이 소개하신 글의 링크를 달아드리니, 관심 있는 분은 확인해주세요.

부분 유료화란 무엇인가요?

피드백

각자의 아이디어 발표를 들으면서 즉각적으로 떠오르는 내용을 피드백하는 시간을 가졌습니다. 발표를 들으면서 생각나는 연관 서비스를 소개하기도 하고, 자신이 비슷한 서비스를 사용해봤던 경험을 공유하기도 하고, 발표에서 좋은 점을 언급하기도 했습니다. cora님은 몇몇 아이디어는 최종적으로 선택되지 않더라도 토이 프로젝트로 해보면 좋을 것 같다면서 열정적인 태도를 보여주셨죠.

아이디어를 구체화하다

각자 뚜렷한 아이디어를 생각해왔고, 전부 다 그럴듯한 아이템이라는 점에서 re:coding 팀은 어떤 아이디어를 선택해야 할지 고민에 빠졌습니다.

이에 아이템을 다시 차근차근 분석해보던 도중, 팀원들은 각자 만들고 싶은 서비스에 대한 아이디어가 어느 정도 공통점을 가지고 있다는 사실을 깨달았습니다. 이는 바로 1) 커뮤니티, 2) 퍼스널라이즈, 3) SNS 공유였는데요, 공통 분모가 도출 되었으니 이에 대해서 좀 더 자세하게 브레인스토밍을 하자는 의견이 나와 2주차는 아이디어 구체화를 하는 시간으로 가지기로 했습니다.

2주차에 주어진 업무는 다음과 같았습니다.

1. 지금까지 나온 아이디어에 대한 브레인스토밍, 넣고 싶은 기능들 2. 지금까지 나온 아이디어와 조금이라도 비슷한 서비스를 찾아 조사하기 3. 커뮤니티(콜라보레이션, 캐릭터 키우기), 퍼스널라이즈(테마, 템플릿), SNS 공유(UI) 이 세가지 정도를 찾아서 비교하기 4. 다른 팀원들이 조사해 온 것을 보고 피드백하기