김성령

김성령님의 아티클

김성령

김성령

GPT4가 분석한 1970~2024년 환율변동 분석

대학생때 입상했던 자산운용 대회에 후배들과 함께 올해 다시 한번 나가기로 하였습니다. 오랜만에 거시경제를 분석하는데, GPT4를 활용하면 어떨까 싶어서 로우데이터 전달하고 데이터 시각화 및 주요 사건 및 영향 정리 시켜보았는데 투입한 시간대비 결과가 좋네요 ㅎㅎ

아래는 미국 달러가치 변동에 대한 분석 자료인데, 과거 사실에 기반한 사례중심적인 분석입니다. 이제 올해 하반기 환율 전망에 대해 뇌피셜을 적으러 가보아야겠습니다.
*금리 및 물가 혹은 지정학적 이슈에 대한 분석도 필요하실까요? 반응이 있다면 다른 거시경제 데이터도 분석하여 업로드 해보겠습니다 (서비스화가 가능할까요? ㅎㅎ)

[데이터] 1970~2024 미국 달러 인덱스 변동 추이

Complete_Final_Historical_USD_Index_and_Major_Events.png

달러 지수 과거 데이터 수정.csv

[결론] 환율 변동에 미치는 영향 분석:

  • 경기(경제 상황): 금융 위기나 경제적 충격 이벤트는 환율에 큰 변동을 초래할 수 있습니다. 투자자들은 위기 시에 위험 회피 행동을 취하고, 이는 통화 가치의 변동을 가져옵니다.

  • 정책: 통화정책, 재정정책, 국제 합의 등 정책 변화는 통화 가치에 직접적인 영향을 미치며 환율 결정에 있어 중요한 역할을 합니다. 특히 금리 변화는 자본 흐름과 투자 결정에 영향을 주어 환율 변동성에 큰 역할을 합니다.

  • 지정학적 사건: 전쟁, 정치적 긴장, 대규모 보건 위기 등 지정학적 사건은 불확실성을 증가시켜 환율에 영향을 미칩니다. 안전 자산으로 여겨지는 통화의 수요가 증가하는 경향이 있습니다.

가장 강력한 영향 요인:

장기적으로 보았을 때, 정책 변화, 특히 중앙은행의 금리 결정과 같은 통화정책은 환율에 가장 강력한 영향을 미치는 요인 중 하나로 간주됩니다. 금리는 국제 자본의 흐름과 직접적으로 관련되어 있으며, 투자자들은 높은 수익률을 추구하기 때문에 이에 크게 반응합니다. 그러나 단기적으로는 경제 위기나 지정학적 사건이 예기치 못한 환율 변동을 초래할 수 있습니다. 이는 통상적으로 갑작스럽고 예측하기 어려운 변화를 동반하며, 시장의 빠른 반응을 유발합니다.


1. 1971년 닉슨 쇼크

  • 문제 상황: 1971년에 미국은 점증하는 무역 적자와 금유출 문제에 직면했습니다. 이는 국제 금융 시장에서 미국 달러에 대한 신뢰를 하락시켰고, 금본위제 하의 달러 태환 약속을 지키기 어려운 상황으로 몰아넣었습니다.

  • 원인: 제2차 세계대전 이후 확립된 금본위제에서는 각국의 통화 가치가 일정량의 금에 고정되어 있었습니다. 그러나 미국의 지속적인 경상 계정 적자와 해외에서 미국 달러에 대한 금 태환 요구가 증가함에 따라, 미국의 금 보유량이 급격히 감소했습니다.

  • 대응방안: 리처드 닉슨 대통령은 1971년 8월 15일 달러와 금의 직접 태환을 중단하는 정책을 발표했습니다. 이로써 해외 중앙은행이 미국 달러를 금으로 교환하는 것이 일시적으로 중단되었습니다.

  • 해결방안: 닉슨 정부는 통화 가치의 조정, 즉 평가절하를 통해 미국의 수출 경쟁력을 높이고 무역 적자를 줄이고자 했습니다. 또한, 국내 경제 조치를 통해 인플레이션을 억제하려고 노력했습니다.

  • 결과: 이 정책은 금본위제의 종말과 함께 변동환율제로의 전환을 촉발했습니다. 달러의 가치가 시장에 의해 결정되기 시작했으며, 이는 초기에 달러 가치의 하락을 가져왔지만, 장기적으로는 더 유연한 통화 정책 운용을 가능하게 했습니다.

//변동환율제: 각국의 통화 가치가 시장의 수요와 공급에 의해 자유롭게 결정되는 제도.

//금태환: 정부가 자국 통화를 일정 비율의 금으로 교환해주겠다는 약속을 말합니다.


2. 1979년 볼커의 인플레이션 정책

  • 문제 상황: 1970년대 말, 미국은 두 자릿수에 달하는 인플레이션과 경제적 스태그플레이션(경기 침체와 인플레이션 동시 발생)에 직면했습니다. 이는 국내외에서 달러 가치에 대한 신뢰를 크게 하락시켰고, 경제적 불안정을 초래했습니다.

  • 원인: 인플레이션의 원인은 복합적이었습니다. 1970년대의 두 차례 오일 쇼크와 더불어, 확장적인 통화 및 재정 정책이 높은 인플레이션을 유발했습니다. 또한, 경제적 생산성이 정체되었고, 글로벌 경제의 변화가 가격 상승 압력을 가중시켰습니다.

  • 대응방안: 연방준비제도(Fed) 의장이던 폴 볼커는 금리를 대폭 인상하여 고금리 정책을 시행했습니다. 이는 인플레이션을 억제하기 위한 급진적인 조치로, 유동성을 제한하고 돈의 가치를 높이는 효과를 노렸습니다.

  • 해결방안: 고금리 정책은 신용 비용을 증가시켜 소비와 투자를 억제했습니다. 이는 단기적으로 경제 활동의 감소를 가져왔지만, 장기적으로는 인플레이션을 현저히 감소시켜 경제적 안정성을 회복하는 데 기여했습니다.

  • 결과: 초기에는 경제에 심각한 침체를 가져왔지만, 1980년대 중반으로 가면서 인플레이션은 크게 감소했고, 경제는 안정되기 시작했습니다. 볼커의 고금리 정책은 인플레이션에 대한 Fed의 강력한 대응을 상징하게 되었고, 향후 수십 년 간의 낮은 인플레이션 기간을 위한 기초를 마련했습니다.

//고정환율제: 국가가 자국 통화의 환율을 고정하거나 특정 범위 내에서만 변동하도록 하는 제도.


3. 1981년 레이건 감세 정책

  • 문제 상황: 1980년대 초, 미국 경제는 고금리 정책으로 인한 불황과 더불어 높은 인플레이션, 에너지 위기 등의 영향을 받으며 성장이 정체되어 있었습니다.

  • 원인: 경제적 스태그플레이션과 고금리 정책은 기업의 투자를 억제하고 소비자의 구매력을 감소시켰습니다.

  • 대응방안: 로널드 레이건 대통령은 '레이거노믹스'라 불리는 경제 정책을 시행했습니다. 이는 광범위한 감세, 정부 지출 삭감, 규제 완화를 통해 민간 부문의 활동을 촉진하려는 시도였습니다.

  • 해결방안: 감세는 개인과 기업의 이용 가능한 수입을 증가시켜 투자와 소비를 촉진했습니다. 이는 경제 활동의 증가를 가져와 더 많은 세수를 창출하고 경제 성장을 자극하는 효과가 있었다는 주장이 있습니다.

  • 결과: 감세 정책은 단기적으로는 재정 적자를 증가시켰으나, 1980년대 중반 이후 미국 경제는 본격적인 확장 국면에 접어들었습니다. 이는 고용 증가와 함께 투자 확대, 생산성 향상으로 이어졌습니다. 그러나 재정 적자 증가에 대한 우려는 이후 재정 정책의 중요한 쟁점으로 남아 있습니다.


4. 1985년 플라자 합의

  • 문제 상황: 1980년대 중반, 미국 달러 가치는 주요 통화에 비해 과도하게 강세를 보였고, 이로 인해 미국의 대외 무역 적자가 심화되었습니다.

  • 원인: 강력한 경제 성장과 높은 금리는 해외 자본을 끌어들여 달러 강세를 유발했습니다. 그러나 이는 미국의 수출 경쟁력을 저해하고 대외 무역 적자를 확대시키는 부정적인 효과도 함께 가져왔습니다.

  • 대응방안: 1985년, 주요 5개국(G5)은 달러 가치를 인위적으로 절하시키기로 합의했습니다. 이는 달러의 과도한 강세를 수정하고 무역 균형을 재조정하기 위한 조치였습니다.

  • 해결방안: 플라자 호텔에서 이루어진 이 합의는 주요 국가들이 외환 시장에서 달러를 매도하고 다른 주요 통화를 매수함으로써 달러 가치를 낮추는 시장 개입을 수반했습니다.

  • 결과: 달러 가치는 합의 이후 몇 년간 크게 하락했으며, 이는 미국의 수출 증가와 무역 적자 감소로 이어졌습니다. 그러나 일부 국가들에서는 달러 약세가 지나치게 빠르게 진행되어 새로운 경제 문제를 일으킬 수 있다는 우려를 낳기도 했습니다.


5. 1994년 멕시코 페소 위기

  • 문제 상황: 멕시코는 갑작스런 페소의 평가절하와 금융 위기에 직면했습니다. 이 위기는 멕시코 경제에 심각한 영향을 미쳤고, 미국을 비롯한 다른 국가들에도 파급 효과를 가져왔습니다.

  • 원인: 위기의 주된 원인 중 하나는 멕시코가 고정환율제를 유지하려 했던 것입니다. 이는 단기 외채에 의존하는 동안 외환 보유고의 급격한 감소로 이어졌고, 신뢰 상실과 자본 도피를 촉발했습니다.

  • 대응방안: 멕시코 정부는 페소의 자유로운 변동환율제로 전환했으나, 이는 단기적으로 통화 가치의 급락과 인플레이션 상승을 가져왔습니다.

  • 해결방안: 미국 정부와 국제통화기금(IMF)은 멕시코에 대한 긴급 금융 지원을 제공함으로써 위기를 해결하고자 했습니다.

  • 결과: 멕시코 경제는 단기적으로 위기를 극복했으나, 장기적으로는 구조적인 개혁을 통해 경제 안정성을 강화할 필요가 있었습니다. 이 사건은 신흥 시장에서의 금융 위기가 글로벌 경제에 어떻게 영향을 미칠 수 있는지를 보여주는 사례로 기록되었습니다.


6. 2001년 9/11 테러 공격

  • 문제 상황: 2001년 9월 11일, 미국은 역사상 최악의 테러 공격을 받았습니다. 이는 미국 뿐만 아니라 전 세계에 광범위한 충격을 주었습니다.

  • 원인: 국제 테러리스트 그룹 알카에다가 미국의 주요 랜드마크를 공격하여 미국 내부에 공포와 혼란을 야기했습니다.

  • 대응방안: 미국 정부는 국토 안보 강화, 국제 테러와의 전쟁 선포 등 강력한 대응책을 마련했습니다.

  • 해결방안: 금융 시장의 안정을 위해 연방준비제도는 유동성을 대폭 공급했고, 여러 경기 부양책을 도입했습니다.

  • 결과: 9/11 테러 직후 미국 경제는 큰 타격을 받았으나, 이후 부양책과 강력한 안보 정책으로 회복되기 시작했습니다. 달러는 단기적으로 약세를 보였으나, 이내 안전 자산으로서의 역할을 다시 수행하면서 회복되었습니다.


7. 2008년 글로벌 금융 위기

  • 문제 상황: 미국에서 시작된 서브프라임 모기지 위기가 전 세계적인 금융 위기로 확산되었습니다.

  • 원인: 미국의 부동산 시장 붕괴와 금융 기관의 부실화, 리스크 관리 실패, 금융 파생상품의 복잡성 증가 등이 복합적으로 작용했습니다.

  • 대응방안: 미국 연방정부와 연방준비제도는 은행과 금융 기관을 구제하기 위해 대규모 구제 금융 프로그램을 시행했습니다.

  • 해결방안: 경기 부양을 위한 양적 완화, 금리 인하, 경제 부양책 등이 도입되었습니다.

  • 결과: 당시의 위기 대응은 단기적으로 금융 시스템의 안정화와 경제 회복을 가져왔으나, 장기적인 국가 부채 증가와 글로벌 경제의 구조적 변화라는 새로운 도전을 낳았습니다. 위기 이후 달러는 변동성을 겪었으나, 결국 세계의 주요 예비 통화로서의 지위를 유지했습니다.


8. 2020년 COVID-19 팬데믹

  • 문제 상황: 2020년, 코로나바이러스 감염증-19(COVID-19)의 전 세계적인 대유행이 시작되었습니다.

  • 원인: 전염성이 매우 높은 코로나바이러스의 신종이 전 세계로 확산되었습니다.

  • 대응방안: 각국 정부는 봉쇄 조치를 시행하고, 경제적 충격을 완화하기 위해 재정 및 통화 정책을 채택했습니다.

  • 해결방안: 대규모 재정 지출, 기업 및 개인에 대한 직접적인 재정 지원, 금리 인하, 양적 완화 등이 포함되었습니다.

  • 결과: 달러는 팬데믹 초기에 안전 자산으로서 수요가 증가하여 가치가 상승했습니다. 그러나 팬데믹이 장기화되면서, 경제 활동이 둔화되고 국가 부채가 증가함에 따라 달러 가치는 다시 변동성을 보였습니다.


9. 2023년 러시아-우크라이나 전쟁

  • 문제 상황: 러시아의 우크라이나 침공으로 인한 지정학적 위기가 발생했습니다.

  • 원인: 러시아와 우크라이나 사이의 오랜 갈등과 복잡한 지정학적 관계가 전쟁으로 이어졌습니다.

  • 대응방안: 서방 국가들은 러시아에 경제 제재를 가하고, 우크라이나에 군사 및 재정 지원을 제공했습니다.

  • 해결방안: 대규모 제재와 국제사회의 지원으로 전쟁의 영향을 최소화하고자 했습니다.

  • 결과: 전쟁으로 인한 불확실성은 세계 경제, 특히 에너지와 식량 시장에 큰 영향을 미쳤습니다. 달러는 안전 자산으로서 수요가 증가하면서 가치가 강세를 보였습니다.

1
0
김성령

김성령

Become a product maker beyond a product manager (1)



[서론]

IT 회사에서 PM으로 근무한지 3년, 이제는 내 스스로 내가 해결하고 싶은 문제를 해결하는 제품을 만들고 싶어졌다. 그렇게 2023년 9월 사이드 프로젝트 팀을 결성하게 되고, 지난 반년 간 TODA라는 다이어리 서비스를 출시하기 위해 노력해왔다. 하지만, 내가 해결하고 싶은 문제를 해결하는 제품을 만드는 팀이기에, 내가 설정한 목표에 대해 팀원들이 공감하는 깊이는 매우 얕거나, 매우 깊었다.

자동차가 만들어져, 정상적으로 전후좌우로 움직이기 위해 수만개의 부품이 결합되어야 하듯이, 하나의 제품을 만들기 위해선 각 직군에서 수많은 작업을 진행해야 한다. 이것은 어느 한 직군이라도 완료해야할 작업을 완료하지 않는한, 다른 직군이 얼마나 빠른 속도를 내어 얼마나 빠르게 작업을 마무리하던지 그것은 의미가 없다. 이것은 생산관리에서 누누이 강조하게 되는 제약조건으로, 하나의 제품이 만들어지는 기한을 줄이기 위해선, 작업별 능률의 최대치를 높여야 하는 것이 아니라, 작업별 능률의 최소치를 향상시켜야 한다.

다만 아쉬운 점은, 내가 팀원들에게 해줄 수 있는것은 무엇도 없다는 것이다. 정당한 대가를 지불하여 외주 계약을 한 것도 아니며, 그렇다고 정부지원 사업이나 VC로부터 투자금을 받아온 것도 아니었다. 또한 내가 의도한 바를 업무화하여 팀원들에게 정확하게 분담하는것 역시 매우 어려웠다. 이러한 상황속에서 나는 항상 내가 배워서 만들어볼까? 내가 모든것을 할 수 있다면 적어도 커뮤니케이션 비용과 노력으로 발생하는 제약조건 딜레이를 최소화 할 수 있을것이라는 생각이 들었다.

결과적으로 프론트앤드, 백앤드에 대한 지식을 쌓기 위해 정보처리기사, SQLD와 같은 기본적인 개발 지식을 배울 수 있는 자격증을 공부하였고, 직접 마크업 언어를 익혀 나의 포트폴리오 사이트를 제작해보기도 하였다. 주변에서는 기획자가 개발공부를 할 필요가 없다는 얘기를 종종하였지만, 지금에와서 생각해보면 업무적으로도, 내가 앞으로 진행할 사업적으로도 꽤나 만족할 만한 선택이었다는 생각이 든다. 어떠한 점에서 나에게 도움이 되는지 아래 상세 설명을 추가하도록 하겠다.

[개발 공부의 이점]

  1. PM으로서 상황 파악 후 문제 대응하는 시간이 단축된다.

하나의 프로젝트에 앱과 웹과 서버개발자가 모두 관여되어있다고 해보자. 실제 운영되고 있는 서비스의 경우, 가장 중요한 것은 앱 배포 주기이며, 해당 주기에 맞추어 어떻게 일정을 관리할 것인가가 PM의 주요 업무이다. 이 경우, 현재 우리가 진행하는 프로젝트의 목표 달성을 위해 앱 배포가 필요한 작업, 웹 배포가 필요한 작업, 서버 배포가 필요한 작업이 있으며, 서로 어떻게 연관이 되어있느냐에 따라 배포의 순서가 달라지기도 한다. 예를 들면, 앱에서 서버로부터 받아와야 하는 정보가 바뀌는 경우 두 가지 케이스가 있는데, 하나의 케이스는 앱에서 이미 서버로 요청하고 있는 데이터를 받아오는 API가 수정되는 경우이며, 다른 케이스는 앱에서 서버로 요청하는 데이터를 받아오는 API를 새로 생성해야하는 경우이다. API를 수정하는 경우에는, 서버 작업만이 필요하고, 앱 개발자는 이미 해당 API를 연동해두었기 때문에 별도의 작업 및 배포가 필요가 없다. 결국 서버 배포만 필요하니, 앱 배포를 위한 심사 및 배포 주기가 필요 없는것이다. 반면에 새롭게 API를 생성하는 경우에는, 서버에서 작업하여 개발한 API를 앱에서 용도에 맞는 위치에 연동해주어야 하는데, 이러한 작업이 실제 상용 서버의 유저들에게 도달하기 위해서는 API를 연동한 앱 개발자의 코드가 상용 서버에 적용될 수 있도록 앱 심사 및 배포가 필요하다.

이 과정에서 의사결정은 복잡한 편인데, 기존 API 수정하여 활용하는 것이 앱 배포가 없어 일정관리에 수월한 방안이지만, 해당 방안을 활용할 경우 우리의 사용성 측면 혹은 사업성 측면에서의 목적 달성에 완전히 부합하는가, 제약은 없는가, 사이드 이펙트가 발생하지는 않는가 굉장히 많은 정보들을 파악하고 정리할 수 있어야 한다.

결론적으로, 개발자 및 디자이너와 직업 소통하고 일정 관리 측면에서 의사결정을 내리고, 회사의 대표나 이해관계자들에게 보고 및 컨펌을 받아내야하기 때문에 PM으로서 개발 및 디자인 지식을 알면 알수록 좋고, 해당 지식을 쌓기 위해 노력해야하는 것은 필수적이라는 생각이다.

2. 기획자로서 앱/웹을 설계할 때 정해주어야 할 정책의 범위를 파악할 수 있다.

IT 업계에서 처음 일을 시작할 때에 개발자 혹은 디자이너의 질문에 내가 이런거까지 결정을 해주어야 하는가? 에 대한 의문이 종종 들었던 적이 있다. 결론부터 말하면, 디자이너와 개발자가 기획자에게 질문하는것의 대다수는 기획자가 답변을 정확히 해주어야 한다. 왜냐하면 그들이 물어보는 질문이 사소한 것이든 중요한 것이든, 모두 우리의 서비스와 관련이 되어있으며,서비스에 대한 사용성&사업성 측면에서 가장 이해도가 높아야만 하는것은 기획자이기 때문에 그들에게 정해주어야할 정책에 대한 정확한 가이드라인을 제공해주어야 한다.

그들의 가장 사소한 질문은 무엇인가? 설계도에 나타나지 않은 동적인 측면의 정책과 화면 뒤에서 일어나고 있는 백앤드 측면의 질문들이 대다수이다. 동적인 질문은 이러한 것들이다 "화면이 전환될 때, 다음 페이지가 아래에서 위로 오나요, 오른쪽에서 왼쪽으로 오나요, 위쪽에서 아래쪽으로 오나요?". 당황스럽다. 사실 어떻게 해도 상관 없을 것 같은데? 왜 나한테 물어보는 것일까? 왜냐하면, 그들은 모든것을 구현해줄 수 있기 때문에 선택지 중 어떠한 선택지가 우리의 서비스에 최적화된 경험인지, 어떠한 선택지로 구현해야만 하는 것인지 확인하는 것이다. 아이러니하게 모든것을 해줄 수 있기때문에 선택지 중 어떠한 것을 선택해야 최적인지 결정이 필요하다.

백앤드 측면의 질문은 무엇일까? 일기를 작성할 수 있는 화면이 있다. 이곳에는 이미지, 키워드, 텍스트, 이모티콘 총 4가지의 인풋을 작성할 수 있다. 백앤드 개발자는 질문한다. 모든 정보는 비어있을 수 있습니까? (Null이 허용이 됩니까?). 백앤드 개발자가 물어보는 것은 어떠한 정보가 필수로 입력되어야 하는 정보이고, 어떠한 정보가 선택으로 작성될 수 있는 정보인가가 궁굼한 것이다. 만약 유저가 텍스트를 입력하지 않을 경우에는, 일기가 발행될 수 없도록 만드록 싶다면, 백앤드 개발자에게는 텍스트는 필수 값이며, 나머지는 선택적으로 입력 가능하다는 정보만 전달해주면 백앤드 개발자가 알아서 설계해줄 것이다 (단, 보다 정확하게, 입력값별로 이미지는 URL로 받아올 것이고, 텍스트는 1,000자 이하로 작성될 것이고, 이모티콘은 1개만 입력할 수 있으며, 사진은 최대 5장 까지 저장이 가능하다라는 가이드라인을 미리 전달해준다면 개발자와 커뮤니케이션하는 횟수와 시간이 단축될 수 있을 것이다). 디자이너와 개발자가 질문하는것에 대해 다시 한번 생각해보면, 그들은 무엇이든 만들어줄 수 있기에, 무엇을 만들지 정확한 가이드라인을 세울 수 있는 정책에 대한 질문을 하는 것이다. 그들의 질문에 정확히 답변하기 위해 디자인과 개발에 대한 지식이 필요한 것이다.

3. 내 서비스를 만드는데에, 병목을 줄인다.

위에 서술한 1,2번과 같이 개발자 디자이너와 협업을 하기 위해서는 상당한 시간을 커뮤니케이션에 쏟아야 한다. 커뮤니케이션이 완료된다고 끝인것도 아니다. 그 후엔 실제 작업하는 시간이 필요하다. 모두의 동기부여가 동일하다면, 최대한의 효율로 작업이 마무리되겠지만, 작업자 한 명이 인생에서 보다 중요한 우선순위가 발생하여 작업이 지체되거나 중간에 이탈하게 된다면, 나머지 모두가 작업을 완료하였음에도, 우리 제품은 나머지 한 명의 작업자가 작업을 완료할때까지 기다려야만 한다.

나는 종종 위와 같은 상황에 두려움을 느끼곤 하였는데, 작업이 느린것까지는 괜찮지만, 중간에 이탈하는 경우 그가 작업해두었던 작업물을 인수인계 받아 이어서 작업하기가 굉장히 어려웠다. (돈받고 일하는 회사가 아니기에, 책임질 이유가 없다) 그렇기 때문에 나는 어떠한 작업이든 0으로 돌아가는 순간에 극심한 스트레스를 느꼇으며, 결과적으로 내가 하나하나 차근히 배워서 내가 직접만드는 것은 적어도 0으로 돌아갈 일은 없기 때문에 내 손으로 모든것을 직접 해보자는 생각이 들게 되었다.

지금은 다행히 마음이 맞는 동업자가 생겨 내가 기획 - 디자인 - 프론트앤드 개발까지의 과정을, 동업자가 백앤드 설계의 모든것을 담당하는 역할로 역할을 조금 쪼갤 수 있었다. 앞으로 좋은 동료들을 영입하여 서로 맡고있는 작업에 대한 책임을 조금씩 덜고, 보다 생산성이 높은 팀이 될 수 있도록 노력하겠지만, 나는 그 과정에서 무엇이든 0으로 돌아가는 순간만큼은 막기 위해 내가 직접 내 제품을 디자인하고 개발하기로 마음 먹었다.

결과적으로 이러한 선택은 내가 제품 출시를 포기하지 않고, 꾸준히 이어나갈 수 있는 원동력이 되었으며 앱/웹 서비스가 만들어지는 전 과정을 보다 깊게 이해할 수 있는 초석이 되어가고 있다.

[앞으로 할 것]

  1. 자격증 공부

개발 공부와 PM으로서의 커리어 연관성을 높이기 위해 개발 자격증을 공부하고, 이직하는 순간에 객관적인 지표로 활용할 것이다.

2. 웹 개발 공부

내가 설게한 제품을 가장 빠르게 배포하고 개선할 수 있도록 직접 개발할 수 있는 능력을 갖출 것이다.

3. 외주 사업을 위한 팀빌딩

동업자와 프론트앤드, 백앤드 개발을 나누어 담당할 예정이며, 외주 개발을 받을 수 있도록 디자이너를 섭외하여 3인이서 부업으로 외주 사업을 시작하려고 한다.

4. 내가 해결하고 싶은 문제를 해결하는 제품 만들기

5. 개발 및 디자인 지식을 활용하여 부업 생산성 올리기

[4월 1주차 한것]

  1. 주 5회 이상 정보처리기사 20p 풀기

  • 7회 완료

2. 주 5회 이상 웹 개발 공부하기

  • 플러터 공부 2회 완료

  • 웹 개발 공부 5회 완료

3. 포트폴리오 준비하기

  • 2회 완료

  • 비사이드 포텐데이 1위 (포폴로 활용)

4. TODA 앱서비스 출시 일정관리

  • 4월 14일 백앤드 작업 완료

  • 4월 14일부터 네이티브에서 API 연동

  • 4월 말 TODA v1.0 배포

Group 44724.png

Group 44725.png

Group 44726.png



9
0
김성령

김성령

기획 잔다 심기

일기 쓰기 에디터

앞으로 매주 4월 중 iOS앱으로 출시될 TODA의 기획 과정을 공유합니다. 앱에 대한 소개보다는, 기능 단위의 요소를 기획할 때에 어떠한 과정으로 작업하였는지에 대한 기록을 작성합니다. (안드로이드 개발자분 구인하고 있습니다)

3be3a931b9fa67bd6fb102f73b411240c6d9a9614206ce52f488a0330c6c3dc7.webp

*시리즈에서 앞으로 소개할 기능 예시

1. 배경

일기를 작성해본 적이 없는 사람들은 다음과 같은 어려움을 겪습니다.

(1) 본인의 삶에 대해 무엇을 기록해야 하는지 모른다

(2) 어떻게 기록해야 하는지 모른다

(3) 왜 기록해야 하는지 모른다

2. 요구사항

가장 간편한 기록을 제공하면서도(What, How), 일기 작성의 효용(Why)을 느낄 수 있어야 합니다.

(1) 무엇을 기록해야하는지 알려주어야 합니다

(2) 어떻게 기록해야하는지 알려주어야 합니다

(3) 왜 기록해야하는지 알려주어야 합니다

3. 구현

위 세 가지 요구사항을 만족하기 위해 TODA에서는 다음과 같은 세가지 작성 툴을 제공합니다.

(1) 직접 작성하기

(2) 키워드로 작성하기

  • 오늘 하루 있었던 일을 키워드로 떠올려보고 (What)

  • 키워드를 입력하여 ai에게 전달하면

  • 약 1,000자 이내의 일기를 ai가 작성해줍니다.

  • ai가 작성해준 일기를 읽으면, 어떻게 일기가 작성되는지(How)를 학습할 수 있습니다.

  • ai가 작성해준 일기를 읽다보면, 본인의 실제 경험과 부합하는 문장과, 그렇지 않은 문장을 확인할 수 있고 본인에 대한 사실적인 경험이 무엇이었는지 되짚어보면서 일기 작성의 효용(Why)를 경험할 수 있습니다.

    • 본인도 모르던 사건에 대한 본인의 감정을 알 수 있고, 사실과 다르게 작성된 ai의 일기를 보면서 실제 느꼇던 경험이 무엇이었는지 되짚어 볼 수 있습니다.

(3) 대화하며 작성하기

  • ai와 아침부터, 밤까지 하루 있었던 일에 대해 대화합니다.

  • 아침, 오전, 점심, 오후, 저녁, 밤을 주제로 설정하고,

  • 각 주제에 대한 유저의 답변, 답변에 대한 ai의 공감, 답변에 대한 꼬리질문을 이어나가며

  • 오늘 하루 있었던 일을 떠올려 보고 (What)

  • 모든 대화가 종료된 뒤에, ai가 일기를 요약해 전달해주어 오늘 하루가 어떻게 작성되는지(How) 확인해보고

  • ai가 작성해준 일기를 읽다보면, 본인의 실제 경험과 부합하는 문장과, 그렇지 않은 문장을 확인할 수 있고 본인에 대한 사실적인 경험이 무엇이었는지 되짚어보면서 일기 작성의 효용(Why)를 경험할 수 있습니다.

  • 혹은 ai와 대화하는 과정에서도 하루를 기록해야하는 이유(Why)를 경험할 수 있습니다.

4. 협업하기

image 24.png

요구사항을 만족하기 위해 구현해야할 사항을 개발자에게 전달합니다.

ai 연동

(1) ai 작성 기능에 어떤 api를 활용할 것인지

(2) 해당 api를 활용하기 위해, 환경 세팅을 도와줄 것은 없는지

(3) api 통신 실패(타임아웃), api 실패값 전달 시 예외케이스는 어떻게 할 것인지

에디터

image.png

(1) 입력값

  • 입력값 저장 시, 네이티브에서 서버로 전달하는 정보와 활용할 api

  • 입력값을 불러올 경우, 서버에서 네이티브로 전달하는 정보와 활용할 api

  • 필수 입력값, 선택 입력값에 대한 정책 및 예외케이스 정리

(2) CRUD (생성, 수정, 활용, 삭제)

(3) UI 배치

(4) 인터렉션

  • 입력값을 입력할 때에, 어떤 화면이 노출되는지

  • 화면 간 이동은 어떠한 방식으로 할지

  • 시스템 키보드가 노출될 때에는 UI가 어떤 화면이 되어야 하는지

  • 해당 화면으로 변할 때의 작동은 어떻게 할 것인지

(5) 결과

  • 결과적으로 작성된 일기는 유저에게 어떻게 보여질 것인지

5
2
김성령

김성령

기획 잔디심기 시리즈

첫번째 시리즈, 감정 캘린더

앞으로 매주 4월 중 iOS앱으로 출시될 TODA의 기획 과정을 공유합니다. 앱에 대한 소개보다는, 기능 단위의 요소를 기획할 때에 어떠한 과정으로 작업하였는지에 대한 기록을 작성합니다. (안드로이드 개발자분 구인하고 있습니다)

Group 719.png

*시리즈에서 앞으로 소개할 기능 예시

1. 배경

Frame 1003.png

하루콩, 투두메이트 등 다양한 기록 앱 서비스들은 캘린더에 감정을 기록하는 기능을 제공합니다. 캘린더에 감정을 기록하는 이유는 무엇일까요? 아래는 일반적인 캘린더 UI만을 제공했을때의 문제점입니다.

(1) 단지 날짜로만 표기된 캘린더는 나의 돌아보고싶은 과거를 찾기가 어렵습니다.

(2) 내가 해당 월에, 해당 주에, 해당 일에 어떠한 감정을 느꼈는지 찾아보기 어렵습니다.

2. 요구사항

(1) 해당 월, 해당 주, 해당 일에 어떠한 감정을 느꼈는지 찾기 쉬워야 합니다

(2) 내가 돌아보고 싶었던 과거가 있다면, 쉽게 찾을 수 있어야 합니다

3. 구현

위 두 가지 요구사항을 충족시키기 위해 총 15개 (5x3)의 상태값이 필요합니다.

  1. 해당 날짜에 어떠한 정보가 포함되어있는지 표현합니다.
    a. 해당 날짜에 어떠한 감정을 느꼇는지
    b. 해당 날짜가 특별한 날이었는지
    c. 해당 날짜가 몇일인지
    d. 해당 날짜가 오늘인지
    e. 해당 날짜를 선택하였는지

  2. 해당 날짜에 입력된 감정이 어떠한지
    a. 해당 날짜에 어떠한 감정을 기록하였는지
    b. 일기는 작성하였지만 감정을 기록하지 않았다면 어떤 ui를 표현해주어야 할지
    c. 일기를 작성하지 않았을 때에는 어떠한 ui를 표현해주어야 할지

4. 협업하기

image.png

요구사항을 만족하기 위해 구현해야할 사항을 개발자에게 전달합니다.

image.png

개발자가 클레스를 쉽게 정의할 수 있도록 컴포넌트와 프로퍼티가 정의되어있으면 더욱 좋습니다

4
0
김성령

김성령

GPT를 활용해 하루 3분 일상 흔적 남기기 (1)

ToDa라는 서비스는, GPT를 활용하여 유저가 일기를 작성하는 시간(귀찮음)을 줄여주는 솔루션입니다. 저는 기획자이자, 팀의 프롬프트 엔지니어로서 어떻게하면 INPUT을 입력하는 노력 대비, 결과물이 가져다주는 효용을 높여줄 수 있을지에 대해 GPT 4를 활용하며 다양한 시도를 하고 있습니다.


▮ GPT에게 일기 작성 세팅하기

  • 우선 SYSTEM에 OUTPUT으로 전달 받고 싶은 값이 무엇인지 명령문을 입력하고,

  • GPT 4에서 제공하는 간단한 커스터마이징 요소 (Temperature,Top P, Frequency penalty, Presence penalty)를 조작하여

  • <키워드를 입력할 때, 일기를 작성해줘>라는 부탁을 할 수 있도록 세팅해두었습니다.
    (자세한 조건들은 앞으로 6주 동안, 일기 작성 전용 프롬프트와 요소값을 직접 실험해보면서 차차 공유드리도록 하겠습니다.)

Group 154.png

결과물을 읽어보셨나요?
평소 영화를 보거나, 드라마를 봐도 크게 주인공들의 감정 상태에 공감하지 못하는 성격인데, AI가 제 일상에 대해 이정도로 감정을 서술해준다는 것이, 저는 제 일상이 공감받는 듯한 느낌을 받았습니다.

물론 거짓말이 종종 섞여 있으며, 제가 실제 느낀 감정과 다르게 서술된 부분들이 많았지만, 그러한 서술들을 읽으며 제가 정말 느꼇던 감정은 무엇이었는지 되짚어 볼 수 있어 좋았습니다.

그렇다면, 지금까지 제가 일기 전용 프롬프트를 작성하면서, 또는 앞으로 프롬프트를 개선하면서 어떠한 실험들을 해볼 수 있을까요?

▮실험. GPT에게 일기 작성을 부탁할 때 Frequency penalty & Presence penalty 조건은 어떤 값을 입력하여야 할까?

상황 : Frequncy penalty의 최적값을 찾아보자

Group 150.png


위 일기는 Frequency penalty를 0이라는 수치로 극단적으로 낮추었을 때 전달 받은 output입니다. <마치 ~와 같다>라는 서술이 매우 반복적으로 서술되어 있는것을 확인할 수 있습니다.

정의
Frequency penalty란, 결과물이 작성되고 있는 상황에서, 앞서 작성한 내용에 포함된 (단어, 어휘, 문장 형식)이 얼마나 자주 반복될 수 있는가와 관련된 지표입니다.

적용
Frequence penalty가 0이라는 것은 이전에 작성된 (단어, 어휘, 문장 형식이)이 앞으로 작성되는 내용에 반복적으로 포함되어도 상관없다는 뜻으로 간단하게 이해하였습니다.

개선

  • GPT가 키워드와 관련된 상황&감정적 서술을 더욱 풍부히 할 수 있도록 프롬프트에 비유와 은유를 가끔 활용하라는 명령을 작성하였습니다.

  • 하지만 Frequency penalty가 너무 낮은 값으로 설정되어 있다면, 이미 서술한 (단어, 어휘, 문장형식)이 이후에도 반복되어 output을 읽는 사람에게 피로감을 줄 수 있다고 판단하였습니다.

  • 이를 개선하기 위해 적절한 수준의 Frequnce penalty 값을 찾아야 했습니다.

상황 : Presence penalty의 최적값을 찾아보자

Group 152.png

반대로 위 일기는 Presence penalty를 0으로 극단적으로 줄였을 때의 결과입니다. 확실히 앞서 소개드린 Frequncy penalty값을 1.11정도로 많이 높인 상황이라, <마치 ~하다>라는 형식의 문장 서술은 눈에 띄게 줄어든 것을 확인할 수 있습니다. 대신 Presence penalty를 줄여버리니, "인용문(속담, 격언)"의 빈도가 확 높아졌습니다.

정의
사실 Presence penalty는 gpt가 output을 작성하는 과정에서, 이전에 작성하고 있던 내용이 앞으로 작성할 내용의 (주제, 맥락)에 어떤 영향을 미치는가에 중요한 지표입니다. Presence penalty가 높으면 높을 수록, 이전에 이야기하던 (주제, 맥락)에서 벗어난 새로운 이야기를 할 가능성이 높아집니다.

적용
일기 작성을 요청하는 과정에서, input으로 이미 다양한 상황을 나타내는 키워드를 전달하였기 때문에, 해당 값은 output에 큰 영향을 주지 못할 것이라고 생각했었습니다. 하지만 생각보다 결과에서 큰 차이가 났습니다. 거의 매 문장마다 "인용문"이 포함되어있는것을 발견하였습니다.

의문
제가 이해를 잘못한것이 아니라면, "인용문" 역시 (단어, 어휘, 문장형식)에 관련이 있어 Frequncy penalty값을 높인에 따라 반복되지 않았어야 하는데, (주제, 맥락)을 조절하는 Presence penalty를 낮춤에 따라서 반복되는 현상이 발견되어, 제가 무언가 놓치고 있다는 생각이 들었습니다.
*이 부분에 대해 자세히 공부해봐야 할 것 같습니다. 혹은 관련 지식이 있으신 분 첨언 부탁드립니다!

개선

  • 해당 현상 역시, GPT가 키워드와 관련된 상황&감정적 서술을 더욱 풍부히 할 수 있도록 프롬프트에 속담이나 격언을 가끔 활용하라는 명령을 작성하여 나타나는 문제였습니다.

  • 이를 개선하기 위해, Frequncy penalty를 높였던 것인데, 의외로 Presence penalty를 낮추니 "인용문"이 너무 자주 서술되는 현상을 확인할 수 있었습니다.

  • 결과적으로 유사한 <단어, 어휘, 문장형식>의 빈번한 활용을 막을 수 있도록 최적화된 Presence penalty값을 찾아야 했습니다.

▮결과. Frequncy penalty값과 Precense penalty 값

Group 154.png

글을 시작하며, 처음 여러분께 소개해드린 일기입니다. Freqency penalty가 0이었던 일기, Presence penalty가 0이었던 일기와 비교하여 보면 어떠신가요?

제가 일기 output을 얻어내기 위해 여러가지 실험하면서 얻은 힌트를 공유드리자면 아래 두가지와 같아요. 관심있으신 분들은 직업 실험해보시면 재밌을거에요!

  • Freqency penalty는 평균 이상으로 높아야 한다.

  • Presence penalty는 평균과 근접한 값이어야 한다.

    앞으로 ToDa앱의 키워드 일기 솔루션이 어떠한 점을 더욱 개선하면 좋을까요? 프롬프트에 많은 관심이 있다면 함께 일기에 적합한 프롬프트를 만들어가봐도 좋을것 같습니다.

19
2