아침 8시 노션 워크스페이스 뉴스레터

notionto.email은 하루동안의 노션 업데이트를 보내주는 서비스입니다. 이번 업데이트로 이메일 발송 시점을 자정에서 아침 8시으로 변경하게 되었습니다. 이 글에서는 그 이유와 과정을 정리하고자 합니다.

처음에는 하루동안의 업데이트 즉 일자에 따른 업데이트가 중요하다고 생각해서 자정을 그 기준으로 삼았습니다. 그날의 업데이트라는 의미가 있었지만 실제로 이용하는 사람에게 이게 중요한가는 다른 문제죠. 주변의 의견과 디스콰이엇에서 받은 댓글 하나가 이번 업데이트의 트리거였습니다. 댓글의 내용대로 밤에는 일에서 벗어나고 싶을텐데 다시금 이를 알려주는건 피하고 싶을겁니다.

그렇다면 언제가 좋을까?

워크스페이스라는 컨텐츠를 가공해서 매일 보내준다는 점이 제게는 신문처럼 느껴졌습니다. 일을 시작하기 전 전날 일어난 일들을 파악하는 신문 말이죠. 그런 점에서 아침을 선택하게 되었습니다. 오전 10시에 일어나는 저이지만 일반적으로 일을 시작하는 아침 8시가 적절해 보였습니다.

댓글을 남겨주신 분이 영국에 계신다는 점이 눈에 들어왔는데요.

한국의 오전 8시는 영국의 자정입니다. 한국이 8시간 빠른데요.

다른 시간대에서도 오전 8시에 매일을 받아볼 수 있도록 timezone을 반영했습니다.

이번 업데이트를 하면서 시간대가 UTC -12부터 +14까지 24시간 범위보다 넓게 있다는 사실을 알게 되었네요.

노션 사용자를 위한 조간신문.

서비스의 정체성에 도움이되는 업데이트를 하게 된 것 같아 뿌듯합니다.

Notion, 뻗어나가는 페이지 파악하기

노션의 장점은 자유로운 페이지 구성입니다.
생각을 정리하면서 페이지를 추가하다보면 어느새 복잡한 구조를 가지게 됩니다. 복잡한 구조 속에서 페이지가 생기다보면 자연히 놓치는 정보가 생깁니다. 이런 업데이트 중에는 중요한 정보들이 있는 경우가 종종 있습니다.

모든 페이지들의 업데이트를 파악하기 위해 Inbox의 모든 업데이트를 보기에는 우리의 시간이 아깝습니다. 한 페이지씩 들어가서 업데이트를 확인하기도 어렵구요. 이런 문제를 해결하려면 구조를 몰라도 노션 워크스페이스의 업데이트를 한눈에 파악할 방법이 필요합니다. 다행히 이런 업데이트를 한눈에 파악할 방법이 있습니다.

notionto.email은 하루동안의 업데이트를 한눈에 볼 수 있도록 이메일로 보내줍니다. 작성자가 일일이 공유하지 않아도 업데이트를 자동으로 파악할 수 있죠. 하나씩 공유받고 직접 찾아다니지 말고 편하게 파악하세요. 노션 속 중요한 정보를 놓치지 않고 파악하는 일잘러가 될 수 있습니다.

[잡플래닛 임원은 어떤 생각을 하는가 / 인기기사 리마인드 2021/10/27]

잡플래닛은 2012년 설립됐습니다. 잡플래닛은 그동안 우리나라 기업 문화에 큰 영향을 미친 플랫폼인데요. 잡플래닛 운영 책임자는 어떤 철학으로 사업을 운영해왔을까요?

1. 잡플래닛 탄생 후 변화가 있었는데요. 회사를 고르는 기준입니다. 이제 많은 사람이 회사를 고를 때 사내 문화나 기업 분위기를 봅니다. 잡플래닛의 MAU는 약 300만명입니다. 대기업들이 수시 채용으로 바꾸면서 평균 트래픽이 올라갔습니다.

2. 핵심 서비스는 기업리뷰입니다. 허위사실이라면 다른 기업과 마찬가지로 신고 절차를 거칩니다. 관련 에피소드가 많습니다. 어느 날 '야근이 많다'는 리뷰가 올라왔는데요. 그 기업이 밤 10시에 리뷰를 신고하면서 신빙성을 더했던 적이 있습니다.

3. 논란도 많습니다. 장, 단점이 분명한 플랫폼인 만큼 운영 방식이 중요한데요. 이용자 불만은 끊이지 않습니다. 무료 데이터로 수익화, 리뷰 첫 페이지 편집권 판매, 리뷰 작성 권한 필터링 부재 등에 대해 직접 물었습니다.

(위 기사는 아웃스탠딩 기사 요약문입니다. 기사 본문은 아래 댓글 링크를 통해 볼 수 있습니다)

https://outstanding.kr/jobplanetcoo20211027

파드 3기 숏커톤 회고

안녕하세요 저는 파드 3기 iOS 파트 김민준입니다.

2024년 5월 24일부터 25일동안 무박 18시간으로 숏커톤이 있었습니다. 숏커톤이 끝난 지금 무척이나 피곤하지만 개인적으로 실력에 대해 아쉬웠어서 더 나은 모습으로 롱커톤에 임하고자 바로 회고를 쓰게 되었습니다.

아니 벌써 숏커톤이라고? 망했다

사실 매주 파드 과제에 허덕이는 저는 숏커톤 3주 전 계획을 세우게 됩니다.

'아 내가 CollectionView 와 URL session이랑 데이터 전달이 어려우니까 미리 공부하고 오토레이아웃 잡기 힘들고 시간이 많이 걸리니 스냅킷을 연습해가자!'

하지만 밀린 과제로 5월 1,2 주차는 금방 지나가고 예비군을 다녀오고 나니 과제와 공부해야 할 것들이 산더미처럼 쌓였죠. 심지어 숏커톤이 있는 주간에 화요일 중간고사 , 목욜 중간고사, 퀴즈라는 충격적인 스케쥴이 나오게 됩니다. 게다가 운전을 하게 된 이유로 버스를 타면 좀 힘들어서 자차를 끌고 가자니 18시간 숏커톤을 하고 운전은 해서 오자니 졸음운전할 것 같고 버스를 타자니 숏커톤때 지친 상태로 시작할 것 같아 걱정이 되어 며칠간은 고민을 하다가 컨디션 관리를 빡세게 하고 자차타고 가자고 생각했습니다.

그때는 컨디션 관리가 가능할줄 알았는데 막상 시험기간에 닥치니 지금 잠을 자는게 맞을지 iOS 공부를 해야할지 고민이 되었습니다. 결국은 안전을 위해 잠을 택했는데 목요일 시험치고 오후부터 부랴부랴 복습하고 난리를 쳤네요.. ㅋㅋㅋㅋ

심지어 숏커톤을 하러 장소 도착을 하고 조를 확인했는데 프론트개발자가 보통은 3명인데 저희 조는 저 포함 두명인 것을 보고 걱정이 한가득 쌓이기 시작합니다. "와 1.5인분을 해도 부족한데 과연 내가 1인분을 할 수 있을까?"

아쉬웠던 점

이러한 걱정때문에 저는 더 숏커톤에 집중을 하지 못했던 것 같습니다. 팀에서 아이디어 회의를 할때도 마음 한 켠에선 지금 들리는 것들을 구현할 수 있을까 미리 걱정했습니다. 당연한 것이지만 코딩을 할 때도 공부를 제대로 못한 URLSession이나 데이터 전달에서 막히기 시작했고 나름 자신있다고 생각했던 UI구현도 실수를 계속해서 하면서 시간도 많이 지체되었습니다. 그래서 포기하는 부분들이 많아지게 되니 팀원들에게 너무 미안했습니다.

그래도 좋았던 점

많은 걱정들이 있었지만 팀원들이 너무 너무 잘해줘서 (불사조 팀 최고!) 2등을 해서 좋았습니다. 그리고 진짜 협업이란 이런것이구나 라는 것을 확실히 느끼게 되었습니다. 최대한 제가 할 수 있는 일을 하면서 어플의 로고 화면이나 스플래시 설정하는 법도 새로 알게 되고 디자

인,서버, 기획 파트와 무엇을 이야기해야하는지, 같은 iOS 파트와는 어떻게 일을 진행하는지에 대해 배웠습니다.

노력할 점

숏커톤을 마치고 돌아온 지금은 이제 롱커톤이 얼마 남지 않았네요. 숏커톤 3주전에 많이 뚜두려 맞았으니 이번에는 부족한 부분(url 세션과 데이터 전달, 세부적인 UI조절 연습)을 보완하고 아이디어 회의때도 조금 더 적극적으로 참여해보려고 합니다.

모두 수고하셨습니다!!! (장소 너무 좋았어요~~~🌊🌊)

30일 만에 팔로워 36만명을 모았습니다.

30일 동안 1억을 벌지 못하면 치킨을 뿌린다는 인스타그램 계정 보셨나요?

제가 그 주인공입니다.

저는 지난 60일 동안 제한된 자원 (시간, 돈, 인력)으로 폭발적인 임팩트를 내기 위해 소셜 콘텐츠에서 가설 -> 실험을 무수히 반복하였습니다.

이러한 관점을 "Hacker's Mindset"이라고 정의하고, 이 다음 도전을 위해 해당 관점으로 단 20명의 분들과 함께 소셜 콘텐츠 (인스타, 틱톡, 유튜브)에서 말도 안되는 임팩트를 함께 내보려고 합니다.

이름하여 해커스 클럽! 선착순 20명 모집합니다.
(합격을 위한 지원서와 참가비가 존재합니다. 참가비는 미션 100% 완료시 전액 환불됩니다.)

디스콰이엇 여러분들과 더 자세한 비하인드 스토리를 공유하기 위해 글을 썼습니다.

자세한 내용은 하단 링크에서 확인해주세요!

[인스타]무료로 광고해드릴게요!

안녕하세요! 저에 대해 간단히 소개해드릴게요 😊

저는 6년 차 IT 개발자 직장인이에요. 재택근무하면서 개발만 하다 보니 너무 갇혀 사는 것 같아서 새로운 도전을 해보고 싶다는 생각이 들었어요. 저도 인스타 팔로우를 키우고 싶어서 오늘부터 할 수 있는 건 뭐든지 해보려고 해요!

제가 주변에 사업하시는 분들이 몇 분 계세요. 보드게임 카페, 분위기 있는 카페, 애견 카페, 볼링장을 운영하시는 분들이 있거든요.

매번 초대해 주셔서 가보면 정말 혼자 알기 아까울 정도로 좋은 곳인데, 평일에는 장사가 잘되지 않는 것 같더라고요. 그래서 요즘에는 무조건 SNS를 통해서 광고를 해야 한다고 말해도 시간이 없다고 하시더라고요.

그래서 제가 문득 든 생각이, "아~~~ 내가 광고를 해줄게!!!" 였어요. 매번 맛있는 거 사주시는데 이 정도는 해드려야죠 😄

“형, 누나! 가게/카페/볼링장 사진이랑 위치, 그리고 자랑하고 싶은 점 간단히 써서 줘!!” 라고 자신 있게 말하고 광고해준다고 했어요.

저는 물론 6년 동안 개발만 했는데, 글을 얼마나 잘 쓰겠어요? 😅 그래도 해준다고 했으니 해야죠!

명색이 개발자인데 AI 좀 써봐야 하지 않겠어요? 오늘부터 저는 하루에 하나씩 광고 글을 써서 제 인스타에 올리고, 게시글과 간단히 작업한 사진을 지인분들께 드릴 거예요.

물론 올리기 전에 지인분들께 1차, 2차 검토를 받아서 마음에 들 때까지 수정할 겁니다. 나중에는 이렇게 작업한 분들이 많아지면 게시글마다 링크로 올려서 모두가 저로 인해 대박 났으면 해요! 🎉

물론 제 목표는 인스타그램 팔로워를 늘리는 것이니까 서로 윈윈 아니겠어요? 😉

혹시 저한테 광고 요청하고 싶은 분 계신가요? 돈은 일절 받지 않고, 게시글과 사진 수정 작업을 마친 후 검토를 요청드릴게요. 요청자분께서 마음에 드시면 그때 제 인스타에 게시할 거고요! 📸

요청자분도 작업물을 받으면 본인 계정에 올리고 광고 효과가 2배! 작업은 니가 선배~~ 술술 잘도 들어간다. 너무 아재 같았지… 미안요.

어쨌든 관심 있는 분은 아래 링크로 보내주시면 멋지게 작업해서 드릴게요!! ✨

https://forms.gle/4qYr2hqZS3UaL5EY7

요청하신 분께만 제 인스타 계정을 공유해드릴 예정이니 많은 참여 부탁드려요~~~

(아직 팔로워가 한 자리 숫자지만, 두고 보세요. 제가 얼마나 빨리 4자리, 5자리로 만드는지!!) 🚀

오늘 2024/05/24 기준으로 꾸준히 인사드리겠습니다.~

[TroubleShooting] 스프링 부트 2에서 Instant 사용하기 2탄 - DB에 올바른 시간 입력하기

들어가며... & 이전 이야기

부크부크에서 LocalDateTime를 Instant로 변경하기로 한 나그!

여러 문서를 보고 Instant로 변경에 성공한다.

하지만 DB에 UTC 적용시가 아닌 이상한 시간(타임존이 적용된 시간)이 입력되는데...

일단 화면을 볼까...

이전의 코드에 더해 시간 조회 기능도 만들었고, data.sql을 통해 DB(Mysql)에 CURRENT_TIMESTAMP로 DB의 현재 시간도 찍었다. (코드는 여기에 있다. https://github.com/nag0124/laboratory)

그리고 테스트를 해보면...

• DateTimeTest.java

@Test
void postNGet() {
    // given
    RestAssured.post("/date-time"); // 일단 시간을 찍고

	// when & then
    RestAssured.get("/date-time") // 조회하서 로그를 띄워주어라
            .then().log().all();
}

빨간색 부분이 data.sql을 통해 DB의 현재 시간을 찍은 것이고, 노란색 부분이 스프링에서 찍은 시간이다.

여기에서 알 수 있는 점을 정리해보면, (참고로 스프링의 타임존은 KST(+09:00)고 DB의 타임존은 UTC이다.)

1. Spring에서 Instant를 찍어도 DB에는 Spring의 타임존이 적용되어 저장된다. (Spring 7시 입력 -> DB에 16시 저장) 

2. 시간을 DB에서 찍고 Spring에서 Instant로 가져오면 Spring의 타임존이 역으로 적용된다. (DB 7시 저장 -> Spring에 전날 22시 입력)

3. Spring에서 DB로 시간을 저장하고, 저장된 시간을 Spring에서 읽으면 값에 변동이 없다.(Spring 7시 입력 -> DB에 16시 저장 -> DB의 16시 읽음 -> Spring에 7시로 입력)

어...? 그러니까 쓰는데는 지장이 없는거 아닌가...?

위의 3번의 상황을 그림으로 그려보면 아래와 같다.

1. Spring에서 Instant.now()메서드를 통해 7시의 Instant 객체를 만든다.

2. 이 객체는 DB에`TIMESTAMP` 타입으로 16시의 데이터를 저장된다.

3. DB에서 16시의 TIMESTAMP 데이터를 전달한다.

4. Spring에서 이 데이터를 7시의 Instant 객체로 변환한다.

한마디로 지금 쓰는 데는 지장이 없다. 

이상한 값이 저장되기는 하지만, Spring에서는 값을 읽고 쓸 때 올바른 UTC값이 들어간다.

그리고 지금은 DB에서 시간을 찍지도 않는다.

하지만 안정적인 시스템이냐고 물어보면 그건 아닌 것 같다.

스프링의 타임존이 바뀐다면...? DB에서 시간을 찍게 된다면...? DB에 저장된 값들을 사용하기 위해선 따로 처리를 해야 할 것이다.

결국 나는 결정을 해야 했다.

양념이냐 후라이드냐, 짜장이냐 짬뽕이냐, 그냥 쓸 것인가 문제를 해결할 것인가...

나는 변동과 확장에 안정적인 시스템을 만들기 위해 나는 문제를 더 파기로 했다.

문제가 어디에서 발생할까?

디버깅을 해보고 로그를 확인해보니 Spring과 DB 사이에 이상한 점이 있었다.

• Spring 로그

Hibernate: 
    insert 
    into
        date_time
        (created_time) 
    values
        (?)
2024-05-22 17:13:12.070 TRACE 6378 --- [o-auto-1-exec-2] o.h.type.descriptor.sql.BasicBinder      : binding parameter [1] as [TIMESTAMP] - [2024-05-22T08:13:12.040609Z]

• DB 로그

2024-05-22T08:13:09.845061Z	  229 Query	SELECT @@session.transaction_read_only
2024-05-22T08:13:09.846066Z	  229 Query	INSERT INTO date_time (created_time) VALUES (CURRENT_TIMESTAMP)
2024-05-22T08:13:11.915183Z	  229 Query	SET autocommit=0
2024-05-22T08:13:12.088538Z	  229 Query	insert into date_time (created_time) values ('2024-05-22 17:13:12.040609')
2024-05-22T08:13:12.129760Z	  229 Query	commit
2024-05-22T08:13:12.133393Z	  229 Query	SET autocommit=1
2024-05-22T08:13:13.276707Z	  229 Quit

Spring에서는 로깅 옵션을 주어 쿼리에 바인딩되는 값을 출력하도록 했고, DB에서는 generl.log를 저장하도록 옵션을 주었다.

로그의 시간이 다른건 스프링은 OS 시간(KST)을 찍고 있고, DB는 Docker로 UTC 타임존을 셋팅 했기 때문이다.

DB 로그의 4번째 줄이 실제 INSERT 쿼리인데, 쿼리의 값이 Spring의 로그에서 보여주는 값과는 다르다.

(스프링: 2024-05-22T08:13:12, DB: 2024-05-22 17:13:12)

한마디로, Spring과 DB의 통신 과정에서 타임존이 적용되는 문제가 발생한다.

Instant 클래스는 타임존 정보를 가지고 있지 않지만, DB에 저장될 때는 타임존이 적용되어서 저장이 된다.

해결해보자.(1편)

이 문제에 대해서 검색을 하고 여러 글들을 참고해서 3가지의 해결책을 찾을 수 있었다.(셋 다 성공한다.)

1. spring.datasource.url에 serverTimezone=UTC을 추가하여 서버 타임존 설정하기

2. spring.jpa.hibernate.jdbc.time_zone=UTC을 추가하여 Hibernate의 JDBC의 타임존을 UTC로 설정하기

3. Java 어플리케이션을 실행할 때 -Duser.timezone=UTC로 어플리케이션의 타임존 자체를 변경하기

이렇게 문제를 해결할 수는 있었지만, 찜찜했다.

어느 부분이, 어떻게 문제인지 모르고 "아~ 이렇게 하면 되는구나~" 이렇게 넘어가는 느낌이었다.

그래서 원인을 파악하고자 더 파보기로 했다.

문제를 해결한 지금 다시 생각해보면, 나는 여기서 멈췄어야 했다.

아니야... 그거 아니야... 하지마!!!!! 멈춰!!!!!!!!!!!

더 파보자...

검색하다 Mysql Connector/J의 개발자 가이드의 이 문서를 찾았다.

잠깐! Mysql Connector/J란?
자바는 DB 사이의 연결을 위해 JDBC(Java DataBase Connectivity) API를 사용한다.
이 중 Mysql을 쓰기 위한 JDBC 구현체가 Mysql Connector/J이다.

https://dev.mysql.com/doc/connector-j/en/connector-j-time-instants.html

이 글에서는 Mysql Connector/J를 사용하여 Mysql 특정 시점을 DB에 어떻게 보존할 수 있는지를 알려준다.(원제: Preserving Time Instant)

그리고 이 글에서 얻은 내용을 바탕으로 문제를 파악, 해결할 수 있었다. (아래 내용은 거의 이 문서의 번역본이다.)

문제 심층 해부

이 글을 읽고 정리해본 지금 상황은 아래와 같다.

7시의 Instant 객체가 DB에 저장하는 과정을 살펴보면, 

1. Instant를 DB에 저장하기 위해 16시의 Timestamp 객체로 변환된다. (Instant는 UTC이고 Timestamp는 KST로 설정되이기에 9시간이 더해진다.)

2. Connector/J의 시간대가 Spring과 동일하기에 16시를 변환하지 않고 그대로 DB Session에 전달한다.

3. DB의 Timezone과 Session Timezone이 같기 때문에 변환하지 않고 UTC 16시가 저장된다.

4. DB에서 Spring으로 값을 보내주는 것은 이 과정의 역순이다.

이 과정에서 내가 파악한 문제의 핵심은 Connector/J(KST)에서 넘겨주는 시간 값을 DB Session(UTC)에서 변동하지 않고 값을 그대로 읽는다는 것이다.

문제 해결 방안 탐색

먼저 DateTime과 관련된 Mysql의 여러 옵션을 살펴봤다.

• connectionTimezone: Connector/J의 타임존을 설정하는 속성

  • LOCAL(default): 스프링(원문에서는 JVM이라고 지칭)의 타임존을 사용한다.

  • SERVER: 서버(DB)의 타임존을 사용한다.

  • User Defined Timezone: 서버, 로컬 타임존을 사용하지 않고 자유롭게 지정할 수 있다.(ex: connectionTimezone=Europe/Moscow)

• preserveInstants: 시간을 보존하기 위해 Connector/J와 Spring(JVM)의 사이에서 값을 변환하는 속성

  • TRUE(default): Connctor/J와 Spring의 타임존이 다르다면 값을 변환한다.

  • FALSE: Connctor/J와 Spring의 타임존이 다르더라도 값을 변환하지 않는다.

  • 만약 connectionTimeZone=LOCAL 옵션을 사용하고 있다면 이 옵션이 적용되지 않는다.

• forceConnectionTimeZoneToSession: Session Timezone을 Connection Timezone으로 변환하는 옵션

  • FALSE(default): Session 타임존을 DB 타임존으로 설정한다.

  • TRUE: Session 타임존을 Connection 타임존으로 설정한다.

  • 만약 connectionTimeZone=SERVER 옵션을 사용하고 있다면 이 옵션이 적용되지 않는다.

  • 이 속성을 TRUE로 변경한다면, CURRENT_TIMESTAMP 같은 DB의 함수가 영향을 받을 수 있으니 주의해야 한다.

이 정보와 DB의 특성을 바탕으로 생각했을 때, 값을 변환할 수 있는 부분은 두 군데라고 생각했다.

• Spring과 Connector/J 사이: preserveInstants 과 connectionTimeZone 속성을 설정해 변환할 수 있다.

• DB Session과 Table 사이: DB session의 타임존이 DB 타임존과 다르면 DB에서 값을 변환하기에 이를 이용하면 된다.

안타깝게도 내가 찾아봤을 때 Connector/J에서 Session으로의 변환방법은 없었다.

해결해보자(2)

아래 방법들에서 사용한 테스트 코드는 아래와 같다.(전체 코드는 여기서 볼 수 있다. 링크)

@Test
    void postNGet() {
        // given
        RestAssured.post("/date-time"); // 미리 만들어 놓은 함수로 Spring의 timestamp를 찍는다.

        // when & then
        RestAssured.get("/date-time") // 찍힌 모든 Timestamp를 가져온다.
                .then().log().all();
    }

1. Spring과 Connector/J 사이에서 변환

• application.yml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/laboratory?preserveInstants=TRUE&connectionTimeZone=SERVER // preserveInstants 속성은 default가 TRUE이기에 넣어주지 않아도 된다.

• 흐름도

• DB 쿼리

UTC로 변환된 값이 들어갔다.

• 테스트 결과

위의 창은 DB의 table을 조회한 것이고, 아래 json은 테스트 결과이다.

1번 레코드는 data.sql에서 CURRENT_TIMESTAMP로 찍은 값이고 2번 레코드가 Spring에서 생성해서 보낸 값이다.

시간이 잘 변환되고 잘 저장된다.

2. DB Session과 Table 사이에서 변환

• application.yml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/laboratory?preserveInstants=FALSE&forceConnectionTimeZoneToSession=TRUE // connection time zone이 LOCAL이기에 preserveInstants 속성은 안 넣어도 된다.

• 흐름도

• DB 쿼리

Session을 Asia/Seoul로 설정했고, INSERT 쿼리도 KST시간으로 들어갔다.

• 테스트 결과

위의 창은 DB의 table을 조회한 것이고, 아래 json은 테스트 결과이다.

1번 레코드는 data.sql에서 CURRENT_TIMESTAMP로 찍은 값이고 2번 레코드가 Spring에서 생성해서 보낸 값이다.

시간이 잘 변환되고 잘 저장된다.

3.Spring과 Connector/J 사이에서 변환 + DB Session과 Table 사이에서 변환 (변환이 두개!)

Connection 타임존으로는 모스크바 타임존(Europe/Moscow)를 골랐다.

• application.yml

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/laboratory?preserveInstants=TRUE&connectionTimeZone=Europe/Moscow&forceConnectionTimeZoneToSession=TRUE // preserveInstants 속성은 생략해도 된다.

• 흐름도

그림과 같이 Spring(KST)에서 Connector/J(MSK)로, DB session(MSK)에서 DB table(UTC)로 변환이 2번 일어난다.

• DB 쿼리

Session 타임존이 Europe/Moscow로 설정되었고, DB에 모스크바 타임존이 적용된 값이 잘 전달됐다.

• 테스트 결과

잘 들어갔다.

결론

1. Connector/J, DB Session, DB의 타임존을 일치시키면 특정 시점을 보존할 수 있다.(DB, Spring 등 어떤 시간대가 변동되어도 시점은 영향 받지 않는다)

2. Connector/J와 DB Session 시간을 Spring(JVM)과 일치시키면 특정 시점을 보존할 수 있다.

3. 변태같긴 하지만 3번 해결책과 같이 두 번 변환해서 시점을 보존할 수도 있다.

4. 생각해보니까 Spring, DB의 타임존을 UTC말고 다른 타임존으로 설정하는 것 자체가 이상하다. (굳이...?)

5. 아 참, 그리고 Instant외에도 OffsetDateTime, ZonedDateTime 같이 자바에서 타임존 정보가 있는 시간 클래스는 위의 해결책들을 사용하여 시점을 보존할 수 있다.

6. 하루만에 글을 번역하고 실험하고 글을 쓰는 짓은 하지 말자.

++조금만 더...

이전에 찾았던 3가지 해결방법을 생각해보면 이런 결론이 나온다.

1. spring.datasource.url에 serverTimezone=UTC을 추가하여 서버 타임존 설정하기

• Mysql 8.0.23 버전 이상에서 serverTimezone과 connectionTimeZone 속성은 같은 속성이다.(링크: )

• 그렇지만 connectionTimeZone을 UTC로 하드코딩한다면 DB의 시간대가 UTC에서 다른 타임존으로 바뀌었을 때 시점을 보존할 수 없다.

• 만약 이걸 쓴다면 connectionTimeZone=SERVER로 변경해서 쓰겠다.

2. spring.jpa.hibernate.jdbc.time_zone=UTC을 추가하여 Hibernate의 JDBC의 타임존을 UTC로 설정하기

• 1번과 마찬가지의 이유로 UTC로 하드코딩은 위험할 수 있다.

• 하드코딩 외에 hibernate의 JDBC 타임존을 DB 타임존으로 설정하는 기능은 없기에 차라리 1번 옵션을 쓰겠다.

3. Java 어플리케이션을 실행할 때 -Duser.timezone=UTC로 어플리케이션의 타임존 자체를 변경하기

• EC2의 타임존이 UTC가 아니라면 괜찮을 것 같은데, EC2가 UTC말고 다른 타임존을 쓸 이유가 있을까...?

Reference

- https://dev.mysql.com/doc/connector-j/en/connector-j-time-instants.html(Preserving Time Inststans)

- https://dev.mysql.com/doc/connector-j/en/connector-j-connp-props-datetime-types-processing.html#cj-conn-prop_connectionTimeZone (JDBC URL의 시간 관련 속성)

- https://dev.mysql.com/doc/refman/8.4/en/time-zone-support.html#time-zone-upgrades (Mysql에서 어떻게 Timezone 속성을 관리하는가)

- https://chung-develop.tistory.com/143 (해결 방법 소개글)

[TroubleShooting] Spring Boot 2에서 Instant 사용하기 1탄

들어가며

부크부크에서는 LocalDateTime 클래스로 생성 시간, 수정 시간을 관리하고 있었다.

여기서 LocalDateTime은 서버 시간(Spring 타임존)의 영향을 받기에 유저, DB 등 특정 시간대에 영향을 받지 않는 시간을 저장해 타임존 의존성을 제거하고 싶었다.

타임존 의존성을 제거하여 유저가 영국에 있던 한국에 있던 상관 없이 유저의 위치에 알맞은 시간을 표시하고 싶었다. (다만 돌이켜보면 타임존이 꼭 고쳐야하는 문제는 아닌 것 같다. 현재 상황으로는 굳이 고치지 않아도 될 부분을 고친 것 같다.)

그래서 Instant라는, 특정 시점을 UTC 기준으로 저장하는 Java의 시간 클래스로 LocalDateTime을 대체했다.

이 과정에서 정말 많은 삽질이 있었는데, 이 과정에서 배운 걸 정리해보려고 한다.

Spring Boot 2의 JPA에서는 기본적으로 Instant를 지원하지 않는다.

미안하다... 왠지 모르겠는데 없다...

깃허브의 jarkartaee의 persistence 레포지토리에는 Instant와 관련하여 아래와 같은 이슈가 있다.

(이슈 링크: https://github.com/jakartaee/persistence/issues/163)

글을 쓰신 분은 JPA의 contributor이다.

여기서 중요한 부분을 번역해보면,

이슈 #63에서 java.time.Instant에 대한 지원에 관해 언급되어 있는데 최종 2.2 버전에는 없다. 나도 이게 왜 빠졌는지 모르겠다.
다만 Hibernate에서는 Instant를 이미 지원한다. 그리고 hibernate.jdbc.time_zone을 변경하여 데이터베이스의 타임존을 변경할 수 있다.

만약 JPA 2.2에서 특정 시점을 다루고 싶다면 다음과 같은 옵션이 있다.
1. java.util.Date 클래스 사용하기
2.OffsetDateTime 클래스 사용하기 - 그런데 이 방법은 offset을 골라야하는데, ZoneOffset.UTC를 offset으로 하면 offsetDateTime을 Instant처럼 사용하는 것이다. 다만 이 경우 DB에서 timestamp 칼럼에 offset을 저장하는 걸 지원하지 않을 수 있는데, 이럴 때는 @javax.persistence.TemporalTimeZoneColumn을 사용하여 칼럼을 2개로 쪼개 저장해라.
3. Instant를 사용하기 - JPA 2.2 버전 이전부터 사용하고 있겠지만, AttributeContributer와 함께 사용해라.

그래도 각각 옵션보다 Instant를 지원하는게 가장 좋은거 같다.

그래서 어떤 JPA 버전부터 Instant를 지원해 주는데...?

예... 23년 11월 8일 출시된 3.2.0 버전부터 지원한다.

한마디로 Spring Boot 2에서는 못쓴다.

이제 사용해 보자.

만약 이렇게 코드를 짜고 (소스코드는 여기에 다 여기에 있습니다, 커밋 별로 기능이 바뀝니다.)

• DateTimeController.java

package nag.laboratory.datetime;

import java.util.List;

import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import lombok.RequiredArgsConstructor;

@RestController
@RequestMapping("/date-time")
@RequiredArgsConstructor
public class DateTImeController {

    private final DateTimeService dateTimeService;

    @PostMapping
    public ResponseEntity<DateTimeResponse> createDateTime() {
        DateTimeResponse response = dateTimeService.createDateTime();

        return ResponseEntity.ok()
                .body(response);
    }

}

• DateTimeService.java

package nag.laboratory.datetime;

import java.time.Instant;

import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import lombok.RequiredArgsConstructor;

@Service
@RequiredArgsConstructor
public class DateTimeService {

    private final DateTimeRepository dateTimeRepository;

    @Transactional
    public DateTimeResponse createDateTime() {
        DateTime dateTime = dateTimeRepository.save(new DateTime(Instant.now()));

        return new DateTimeResponse(dateTime.getCreatedTime());
    }

}

• DateTimeRepository.java

package nag.laboratory.datetime;

import org.springframework.data.jpa.repository.JpaRepository;

public interface DateTimeRepository extends JpaRepository<DateTime, Long> {

}

• DateTime.java

package nag.laboratory.datetime;

import java.time.Instant;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class DateTime {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(columnDefinition = "TIMESTAMP")
    private Instant createdTime;

}

• DateTimeResponse.java

package nag.laboratory.datetime;

import java.time.Instant;

import lombok.Getter;
import lombok.RequiredArgsConstructor;

@RequiredArgsConstructor
@Getter
public class DateTimeResponse {

    private final Instant createdTime;

}

• DateTimeTest.java

package nag.laboratory;

import static org.assertj.core.api.Assertions.*;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.server.LocalServerPort;

import io.restassured.RestAssured;
import io.restassured.response.Response;
import nag.laboratory.datetime.DateTime;
import nag.laboratory.datetime.DateTimeResponse;

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT) // RestAssured를 사용하기 위해 스프링을 띄웁니다.
public class DateTimeTest {

    @LocalServerPort
    private int port;

    @BeforeEach 
    public void setUp() {
    	// RestAssured에 스프링 포트를 설정합니다.
        RestAssured.port = port;
    }

    @Test
    void post() {
        // when
        Response response = RestAssured
                .given().log().all()
                .when()
                .post("/date-time")
                .then().log().all()
                .extract().response();

        // then
        assertThat(response.jsonPath().getString("createdTime")).isNotNull();
    }

}

위의 테스트 코드를 실행하면... 테스트가 통과한다.

???????????? 뭐죠? 왜죠? 왜 통과하죠?

Hibernate에서는 Instant를 지원한다.

여러분들은 테스트가 통과하지 않을 거라 예상하셨겠지만, 실제로는 통과한다.

이 테스트가 성공하는 이유는 Hibernate에서 Instant를 지원하기 때문이다.

위의 표는 Hibernate 5와 JPA 2.2의 시간 객체 지원 여부를 보여주는 표다.

Hibernate와 JPA는 공통으로 LocalDate, LocalTime, LocalDateTime, OffSetTime(UTC 시간에 시간 오프셋이 적용된 시간 ex: 16:10:14.368917+09:00), 'OffsetDateTime'(ex: 2024-05-20T16:11:31.266075+09:00)을 지원한다.

HIbernate에서만 Duration(시간의 크기), ZonedDateTime(`OffsetDateTIme`에 타임존 위치 정보가 추가된 클래스), Instant를 지원한다.

Hibernate가 JPA의 구현체이기 때문에, JPA가 지원하지 않는대도 Hibernate에서 지원하면 쓸 수 있다.

그리고 내가 쓰고 있는 Spring Boot 2.7.18 에서 Hibernate 5.6.15 Final 버전을 지원하니까 Hibernate를 통하여 Instant를 사용할 수 있다.

생성시간을 자동으로 관리해보자.

이제 Instant를 자동으로 관리하도록 코드를 짜보자.

1. JPA Auditing을 사용하기

JPA Auditing은 Spring Data JPA에서 제공해주는 누가, 언제 엔티티를 생성, 변경했는지 자동으로 추적해주는 기능이다.

이 기능을 사용하면 상속을 통하여 내가 원하는 엔티티에 자동으로 생성 시간을 넣어 줄 수 있다.

코드는 위의 코드에서 일부분만 변경하면 된다.

아래는 변경된 부분 중 핵심 부분이다.

• BaseTimeEntity.java

package nag.laboratory.datetime;

import java.time.Instant;

import javax.persistence.EntityListeners;
import javax.persistence.MappedSuperclass;

import org.springframework.data.annotation.CreatedDate;
import org.springframework.data.jpa.domain.support.AuditingEntityListener;

import lombok.Getter;

@MappedSuperclass // 엔티티 간의 공통 정보를 정의하기 위해 쓰인다. BaseTimeEntity를 상속 받으면 createdTime이 자동으로 엔티티에 추가된다.
@EntityListeners(AuditingEntityListener.class) // 이벤트의 종류에 따라 자동으로 이벤트를 처리한다.
@Getter
public abstract class BaseTimeEntity {

    @CreatedDate // 생성 시간을 넣어준다.
    private Instant createdTime;

}

• LaboratoryApplication.java

package nag.laboratory;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.jpa.repository.config.EnableJpaAuditing;

@SpringBootApplication
@EnableJpaAuditing // 어노테이션을 추가해야 JPA Auditing을 사용할 수 있다.
public class LaboratoryApplication {

    public static void main(String[] args) {
        SpringApplication.run(LaboratoryApplication.class, args);
    }

}

2. Hibernate의 @CreationTimestamp 사용하기

Hibernate에서 제공 해주는 @CreationTimestamp를 사용해도 JPA Auditing과 똑같이 생성시간을 자동화해서 넣어줄 수 있다.

JPA Auditing과 비교하면 어노테이션 하나만 추가하면 되기에 간단하다.

BaseTimeEntity라는 클래스를 생성 하지않고 어노테이션 하나만 추가하면 된다.

• DateTime.java

package nag.laboratory.datetime;

import java.time.Instant;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

import org.hibernate.annotations.CreationTimestamp;

import lombok.AccessLevel;
import lombok.Getter;
import lombok.NoArgsConstructor;

@Entity
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Getter
public class DateTime {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    // 어노테이션 하나면 된다.
    @CreationTimestamp
    private Instant createdTime;

}

마무리하며

글을 요약해보면 3줄이 나온다.

1. Spring Boot 2에서 Instant를 사용할 수 있는 건 Hibernate 덕분이다.

2. JPA Auditing과 @CreationTimestamp를 통해 생성 시간을 자동으로 넣어줄 수 있다.

3. JPA Auditing은 상속을 통하여 필드를 입력하고, @CreationTimestamp는 필드에 어노테이션을 붙여 자동으로 입력한다.

그리고 무엇보다 아직 끝난 건 아니다.

저렇게 JPA Auditing, @CreationTimstamp를 활용해도 DB에 UTC 적용 시간이 저장되지 않는 이슈가 있다.

저... 선생님...? 왜 그러시죠? 불만이 있으시면 말로하세요...

그리고 이 이슈에 관해서는 다음 글에서 다루겠다. (솔직히 저 이슈를 파다보니까 이 글을 작성하게 되었다. 이럴 줄 알았으면  LocalDateTime쓸 걸...)

Reference

- https://stackoverflow.com/questions/49309076/why-jpa-does-not-support-java-time-instant (JPA에서 왜 Instant를 지원해주지 않는가?)

- https://github.com/jakartaee/persistence/issues/163 (JPA에서 Instant를 지원해주지 않는 것에 대한 이슈)

- https://docs.oracle.com/en/java/javase/11/docs/api/index.html (오라클 Javadoc, Instant, OffsetTime, ZonedDateTime 등 시간 클래스 참고)

- https://suhwan.dev/2019/02/24/jpa-vs-hibernate-vs-spring-data-jpa/ (위의 JPA, HIbernate 관계 그림 출처)

- https://thorben-janssen.com/hibernate-jpa-date-and-time/ (Hibernate와 JPA의 시간 객체 지원 차이)

살려 마땅한 프로젝트 #1

살려 마땅한 프로젝트 #0

숨은 붙여 놓아야지 치료를 하던가 하지요.

살리기로 결정한 이상 우선 다시 기능을 하게 만들어야겠습니다.

먼저 서비스를 중지한 가장 큰 이유인 비용 문제를 해결했습니다.

달마다 지출하는 4만원은 작은 프로젝트에 부담이더군요.

정기적으로 나가는 비용을 어떻게 해결했냐면…

그냥 초기 비용을 많이 썼습니다.

비용은 20만원 정도 썼네요.

구체적으로는 개인 서버를 하나 구축했습니다.

미니 컴퓨터 하나 사서 리눅스 깔고 서버로 만들었습니다.

개인 서버는 다 용도로 오래 사용할 수 있다는 장점이 있습니다.

이 정도면 뭐 합리적인 소비였다고 생각합니다.

이것저것 많이 했으나 재미 없으니 간단히 줄이겠습니다.

로드벨런서를 이용한 https연결을 자체적으로 해결했습니다.

개인 서버에 필요한 이런저런 보안 처리를 했습니다.

필요한 시스템과 코드를 옮겼습니다.

마지막으로 전원을 연결하고

서비스를 다시 기능하게 만들었습니다.

다시 기능하는 서비스를 보면서 드는 생각은

'참 맘에 안 든다' 였습니다.

기능을 새로 만들기도 하고 많이 뜯어 고칠 생각입니다.

고로 어떻게 고칠지 생각하는 시간이 필요하겠습니다.

어떻게 고칠지 생각하고 조만간 다음 글로 오겠습니다.

이상이었습니다.

이렇게 글로 하는 기록과 함께

실패한 프로젝트를 피드백하며 다시 진행해보는 중에 있습니다.

실패를 고치는 과정은 읽는 분에게 도움이 되리라 확신합니다.

짧은 주기로 기록할 테니 원하신다면

글을 읽으며 같이 해주시면 감사하겠습니다.

오늘의 스몰스텝 160 / 755

- 독서실 이용을 10시간에서 4시간으로 줄여봤습니다

- 의도적으로 제약을 통해 창의성을 만들 수 있는지 궁금했습니다

- 억지로 시간을 줄인다고 해서 마법같이 변하진 않았습니다

- 그냥 하던대로 열혈 c책 공부를 좀 하고 릿코드 데일리 문제를 풀었습니다

- 재능 부족이 정확하게 맞는것 같은데 코딩은 계속 하고 싶은게 고민인 것 같습니다.

- 전에 말씀하신대로 항상 시장성이 보장되는 것도 아니고, 결국 언젠가 끝이 날 걸 알지만 그래도 해온게 있어서 하던건 하려고 합니다

- 시작을 했으면 얼마나 오래가는지, 끝은 어떤지를 보고싶습니다

- 추가로 릿코드 1.two sum 문제를 다시 풀었습니다

- 기존에 솔루션을 보고 푼 문제들을 주기적으로 다시 풀려고 하고 있습니다

블로그 저품질 OUT! 금칙어 & 상업성 키워드 무료 검사 사이트

IT 전문 블로그 마케팅 팀, 윙블입니다. :)

블로그 운영중이시거나, 공부해본 분들이라면 '저품질 블로그'에 대한 무서움을 잘 알고 계시리라 생각합니다.

한 번 저품질 걸린 블로그는 다시 살아날 확률이 매우 희박하기 때문이죠.

심지어 탈퇴했다가 블로그를 다시 만들어도 저품질은 탈출할 수 없다는 말이 있을 정도죠..🥲

실제 지인분은 약 5년간 꾸준한 맛집 포스팅으로 최적블을 유지하고 계셨는데요,

어느 순간 방문자가 확 줄어들어 확인해 봤더니 그제서야 블로그가 저품질 상태였단걸 알게 되셨다고 하더군요.

블로그는 역시 예방 또 예방이 중요하다는 생각이 듭니다.

저희처럼 여러 고객사분들 블로그를 관리하는 입장에서는 특히 더 많은 주의를 기울여야 하는 부분이기도 합니다.

금칙어나 상업성 키워드 그거 '카더라'라고 하시는 분들도 계시는데요, 물론 네이버의 정확한 알고리즘은 아무도 알 수 없습니다.

그러나 자체적으로 오랜 시간 연구와 테스트를 거친 결과, 저희는 금칙어와 상업성 키워드가 블로그에 악영향을 끼치는게 맞다는 결론을 내리게 되었습니다.

처음엔 금칙어만 조심하면 되는줄 알았는데, 상업성 키워드 또한 스팸 지수가 쌓일 수 있다는걸 알게 되었죠.

상업성 키워드가 무엇인지 살짝 설명드리자면, 네이버에서 광고 시 활용되는 키워드를 말합니다.

이를테면 '대출'처럼 검색 시 네이버에서 광고로 팍팍 밀고있는 키워드들이죠.

문제는 금칙어 검사와 달리 상업성 키워드는 검사할 수 있는 사이트가 거의 없다는 점이었습니다.

있어도 매우 비싼 가격을 내야만 했죠.

그래서 저희가 직접 '금칙어와 상업성 키워드를 함께 체크할 수 있는 프로그램'을 개발하게 되었습니다.

비용은.. 대행사 뿐 아니라 블로그 운영하시는 개인분들도 부담 없이 사용할 수 있는 가격이어야 한다고 생각해 커피 한 잔값으로 정했습니다.

단, 유료 전환 전 5월 31일까지 무료 서비스하기로 결정을 내렸습니다.

유료 전환 시에는 금칙어 및 상업성 키워드 검사 뿐 아니라, AI를 활용해 자동으로 단어 및 문장을 고쳐주는 기능도 포함하려고 합니다.

마음껏 사용해 보시고 개선되었으면 하는 점이나, 좋은 아이디어 주시면 소정의 선물도 드릴 예정입니다. 😁

(참고로 단어 카운팅 기능도 고객분 아이디어로 추가되었습니다!)

혹,  프로그램 활용한 블로그 관리 전/후와 효과가 궁금한 분들은 이 포스팅을 참고해 주세요.

[금칙어 & 상업성 키워드 검사 프로그램 바로가기!]

비밀번호 : wingco_friends

[라프디 창업기 #39] 유자랩스 사명 변경

유자랩스를 창업하며 많은 시행착오를 겪었다. 그중 만회하기 어려운 실수가 있었는데 ‘상표권’이다. 상표권은 상품분류부터 이해하기 어려운 개념이 많았다. ‘나중에 문제 되면 바꾸면 되겠지’라며 안일하게 생각했다. 그래서 ‘.com’ 확보만 신경썼고, 유자랩스 닷컴을 확보하는 걸로 사명을 정했다. 그게 만회하기 어려운 실수의 시작이었다.

유자랩스는 2023년 4월 법인을 설립했는데 그 전부터 사이드 프로젝트로 시작했다. 그리고 비슷한 시기에 ‘유자’라는 상표가 출원됐다. 아쉽게도 우리가 필요한 상품분류가 선점됐고, 변리사 사무소에 문의하니 언젠가 사명을 바꿔야 할 것 같다는 답변이었다. 그렇게 불편한 마음이 생겼다.

서비스명인 쇼핑파트너스는 ‘쇼핑’과 ‘파트너스’의 합성어인데, 두 단어가 변별력이 없어 상표권 등록이 어렵다고 했다. 우리가 필요한 상표권은 유자랩스와 쇼핑파트너스였는데, 두 가지 모두 상표권 등록이 어려웠다.

2023년에는 서비스를 바닥부터 만들며 많은 도전이 있었다. 인프라부터 시작해서 기술적인 도전은 물론 법인체가 운영되기 위한 각종 계약이 이어졌다. 은행, PG, 유선전화, 4대보험 등 모든 계약이 유자랩스라는 이름으로 이뤄졌다. 틈틈이 뿌려둔 언론 홍보 역시 유자랩스와 쇼핑파트너스 키워드로 차곡차곡 쌓였다.

언젠가 다 바꿔야 한다는 압박감과 함께 이렇게 쌓인 히스토리가 다 날아가야 한다는 아쉬움이 공존했다. 그럴거면 좀 더 빠르게 바꿔야 한다는 생각과 연초 여러 정부 과제에 지원하며 행정 처리가 많아 여유가 없기도 했다. 그렇게 시간이 빠르게 흘러갔다.

그 사이 우리는 지속해서 변경할 사명과 서비스명을 고민했다. 변수명을 정하는 것도 어려운데, 사명이라니. 더욱이 상표권을 우선 진행하려니 어지간한 단어는 다 불가능하다는 답변을 받았다.

과연 유자랩스의 정체성은 무엇일까. 마지막까지 단 하나의 가치를 지킨다면 나는 뭘 지킬까. 우리를 설명하는 가장 핵심적인 단어는 무엇일까. 어느날 깔깔대는 동료들을 보고 있자니 우리를 가장 잘 설명하는 건 ‘웃음(Laugh)’이라는 결론이 나왔다. 대표로서 이 회사에서 꼭 지키고 싶은 것은 웃음이다.

웃음을 뜻하는 영어인 라프(Laugh)를 짧게 라프(LAF)라 줄여 썼다. 평소 많이 사용하는 웃음 이모티콘(:D)을 뒤에 붙였더니 어감이 부드러워졌다. 라프디(LAF:D). 그렇게 라프디라는 사명이 만들어졌다.

그렇게 한 가지 이니셜을 따서 솔루션을 시리즈로 만들면 어떨까 싶었다. 웃음 이모티콘을 붙여서 모든 서비스를 ‘-디’로 만드는 아이디어. 이렇게 되면 디자인에 관한 걱정도 크게 덜어낼 수 있을 것 같았다.

쇼핑파트너스는 어필리에이트 마케팅 솔루션인데, 어필리에이트는 어떻게 줄여도 의미 전달이 어려웠다. 여러 아이디어를 떠올렸지만 상표권 등록이 어려웠다. 결국 가장 직관적인 ‘링크’를 붙여 ‘링크디(LINK:D)’가 됐다.

상표권 출원을 진행하고 이어서 로고 디자인을 맡겼다. 시안을 받아서 고르는 것도 굉장한 에너지를 필요로 했다. 고르고 골라서 꽤 마음에 드는 로고를 받았다. 그런데 이제 시작이었다.

사명, 정확히는 법인 상호명을 바꾸는 작업은 법인 등기부터 시작해 많은 행정 처리를 필요로 했다. 어차피 대리인을 보내봐야 한계가 있으니 대표자인 내가 다 진행하기로 했다. 법무사를 써야 하나 싶기도 했는데, 주소지를 옮기며 법인 등기를 해보니 크게 어렵지 않았던 것 같아 내가 진행하기로 했다. 그런데 주소지 이전과는 전혀 다른 난이도였다.

일단 법인 정관을 바꿔야 하니 정관을 다 프린트해 날인, 간인을 해야 했고 법인 설립때와 비슷한 작업이 필요했다. 보통 법인 인감 도장도 바꾼다는데, 이렇게 되니 바뀌지 않는 게 없었다. 은행, 4대보험, 통신사업자신고 변경, PG사 변경, 연구개발전담부서 변경, 포털사이트 변경, 명함 변경. 행정 처리가 끝이 없었다.

홈페이지와 서비스 도메인도 변경해야 했다. 그동안 유자랩스와 쇼핑파트너스 문구로 도배된 각 페이지를 다 변경해야 했으며, 서비스 가이드 캡쳐도 다시 따야 했다. 여기서 끝난줄 알았는데, 정작 내 짜증 게이지는 예상치 못한 곳에서 터졌다.

우리는 구글 워크스페이스를 기반으로 업무 환경을 꾸렸다. 구글 계정이 바뀌니 혹시 문제가 될까 싶었다. 그래서 SNS와 주변 지인들에게 물었는데 큰 이슈가 없을 거란 답변이었다. 구글 로그인은 이메일 계정 값도 있지만, 구글 내부에서 사용하는 키 값이 있을테니 합리적으로 처리해뒀겠지 싶었다. 문제는 서드파티 앱이었다.

문제가 된 건 슬랙과 허브스팟이었다. 이들은 구글 인증으로 회원가입과 로그인을 제공하는데 로그인 시 인증 키 값이 아닌 구글 이메일로 체크를 했다. 때문에 슬랙과 허브스팟 로그인이 되지 않았다. 노코드 툴인 리툴은 전혀 문제가 없는 걸 보면 슬랙과 허브스팟이 아쉬운 로직 처리를 한 것으로 추측한다.

가장 짜증이 치밀어 올랐던 건 슬랙의 대응이다. 허브스팟이야 무료 버전으로 사용하니 어쩔 수 없다 해도, 슬랙은 사업 초기부터 유료 결제를 했던 서비스다. 슬랙의 대응은 처참했다. 시작부터 한글로 대화하고 싶으면 이메일로 하라며 빠르게 채팅을 종료하려 하더니만, 영어로 이어가겠다고 했더니만 몇 차례 가이드를 주더니 더 이상 해줄 수 있는 게 없다며 이메일 답을 기다리란다. 3시간이 넘도록 답이 오지 않았다. 다시 채팅을 요청하니 다른 직원이 받았고 앞서 이메일을 기다리라고 했으니 그걸 기다려야 한단다. 서비스를 운영하는 입장에서 공감이 되지 않는 대응이었다. 게다가 다음날 아침 도착한 답변은 결국 구글 이메일을 원래대로 복구하라는 거였다. 결국 구글 이메일을 다시 복구하고, 슬랙에서 구글 인증을 풀고 이메일/패스워드 로그인으로 사용하는 걸로 마무리 했다.

법인 등기 준비부터 각종 행정처리, 구글 워크스페이스와 서드파티 앱 그리고 우리 서비스 도메인 변경까지 꼬박 3주가 걸렸다. 정말 다시는 하고 싶지 않다… ㅎㅎ

라프디 주식회사로 다시 시작한다. 서비스명은 링크디. 지난 1년 동안 쌓아둔 여러 데이터가 아쉽긴 하지만, 다시 시작하는 마음으로 차분히 달려 보련다! 앞으로는 라프디 창업기로 찾아 뵙겠다!

AI vs 인간, 경쟁인가 협력인가? 미래 비즈니스 IT 트렌드 [1탄]



"해를 등지고 다가오는 저 그림자가 개인가, 늑대인가?”

'개와 늑대의 시간'.

석양이 지평선 너머로 자취를 감추는 순간, 우리는 개와 늑대를 구분할 수 없는 혼돈의 시간 속으로 걸어 들어갑니다.

인간에게 순종하는 충직한 개와 인간을 위협하는 야생 늑대의 사이 경계가 무너지는 그때, 우리는 불안과 공포에 휩싸이곤 하죠.

지금 우리가 마주한 '인간과 AI의 시간' 역시 이와 다르지 않습니다.

인간과 AI, 두 존재 사이의 경계가 점점 희미해지고 있기 때문입니다.

우리가 만든 기술이지만, 어느새 우리 곁에서 스스로 진화하며 우리를 닮아가는 AI.

그것이 가진 무한한 가능성은 우리에게 기대감을 선사하기도 하지만, 동시에 알 수 없는 미래에 대한 불안감을 불러일으키기도 합니다.

과연 AI는 인간과 공존하며 더 나은 내일을 만들어갈 수 있을까요?

아니면 어느 순간 우리를 대체해버리고 ‘그들의 세상’을 만들어 버릴까요?

최근 제 지인은 AI와 관련된 흥미로운 경험을 들려주었습니다.

늘 이용하던 쇼핑몰에 문의 글을 남겼는데, 돌아온 답변의 주체가 사람이 아닌 AI 챗봇이었다는 것이죠.

사람인 줄 알았을 정도로 너무나 자연스러운 응대에 깜짝 놀랐다고 합니다.

둘러보면 우리가 일상에서 접하는 수많은 제품과 서비스는 이미 AI의 손길을 거쳐 탄생하고 있습니다.

특히 생산 현장에서 AI의 역할은 두드러지게 나타나고 있는데요, 제품 설계부터 생산, 품질 관리, 물류, 고객 서비스에 이르기까지 생산 과정의 전 단계에 AI 기술이 빠르게 스며들고 있기 때문입니다.

조만간 우리 삶을 둘러싼 모든 것들이 AI와 함께 하는 세상이 되리란 건, 예견된 수순인지도 모르겠습니다.

그렇다면 AI는 앞으로 우리의 생산 현장을 어떻게 변화시켜 나갈까요?

작년 말 발표된 가트너의 2024 IT 트렌드 예측 보고서가 그 해답의 실마리를 제공합니다.

이제부터 생산자의 관점에서 AI 기술의 현재와 미래, 그리고 우리가 나아가야 할 방향을 짚어보려고 합니다.

휘몰아치는 AI의 물결 속에서 이 글이 여러분께 나침반이 되어 드릴 수 있기를 바랍니다.

생산자의 무한한 가능성이 열리는 세상

'생산자의 부상(Rise of the Builders)'은 가트너 보고서에서 주목해야 할 핵심 트렌드입니다.

여기서 '생산자'란 단순히 제품을 만드는 사람이 아니라, 기술을 활용해 혁신적인 솔루션을 창조해 내는 사람을 의미합니다.

가트너는 이들이 미래 비즈니스 변화를 이끌 것이라 강조했는데요, 그 중심에는 바로 AI가 있습니다.

AI는 이제 단순한 도구를 넘어 생산자들의 창의력과 생산성을 극대화하는 핵심 동력으로 자리매김했죠.

그렇다면 AI 시대의 생산자들은 어떤 방식으로 일하게 될까요?

가트너 보고서가 제시한 핵심 기술 트렌드를 하나씩 살펴보겠습니다.

먼저 '플랫폼 엔지니어링(Platform Engineering)'의 진화입니다.

플랫폼 엔지니어링은 이는 마치 레고 블록처럼, 표준화된 부품을 조립해 애플리케이션을 만드는 방식을 말합니다.

쉽게 설명하자면 여러 개의 웹사이트나 앱을 만들 때 데이터베이스, 서버, 보안 체계 등 공통적인 부분을 미리 만들어 두고 개발자들이 이를 조립하듯 활용해 원하는 기능을 구현하는 거죠.

이렇게 하면 개발의 속도와 효율성이 크게 향상됩니다.

플랫폼 엔지니어링의 대표적 사례로는 아마존을 들 수 있습니다.

아마존은 상품 추천, 검색, 결제 등 각 기능을 독립적인 서비스로 구축해 놓고 이를 조합해 다양한 애플리케이션을 빠르게 개발하고 있죠.

여기에 AI를 결합하면 어떤 일이 벌어질까요?

'플랫폼 엔지니어링과 AI의 만남'은 제품 설계 과정에 혁신을 가져올 것으로 기대됩니다.

예를 들어 스마트폰 제조사가 새로운 모델을 설계한다고 가정해 보겠습니다.

과거에는 디자이너들이 수많은 스케치와 프로토타입을 거쳐 최적의 디자인을 찾아내야 했습니다.

이는 많은 시간과 비용을 필요로 하는 작업이었죠.

하지만 이제는 디자이너들이 스마트폰의 화면 크기, 배터리 용량, 카메라 성능 등의 요구사항을 입력하기만 하면 AI가 이를 바탕으로 최적의 설계 옵션을 자동으로 생성해 냅니다.

AI는 과거의 방대한 스마트폰 설계 데이터와 사용자 선호도 데이터를 분석하여 사용자 니즈를 충족시키면서도 기술적 실현 가능성과 생산 효율성까지 고려한 최적의 설계안을 제시하는 것이죠.

이는 과거에 비해 설계 과정의 속도와 정확도를 비약적으로 향상시킵니다.

또한 AI는 디자이너들이 생각하지 못했던 창의적인 아이디어를 제안함으로써, 혁신적인 제품 설계를 가능케 하죠.

또 다른 예로 건축 설계 분야를 들 수 있습니다.

전통적으로 건축 설계는 건축가의 창의성과 경험에 크게 좌우되는 영역이었습니다.

숙련된 건축가들은 오랜 경험에서 우러나오는 직관과 노하우를 바탕으로 독창적인 건축물을 설계해 왔죠.

하지만 이제는 AI 기술의 도입으로 이 분야에도 새로운 변화의 바람이 불고 있습니다.

건축가들이 건물의 용도, 규모, 예산 등의 설계 조건을 입력하면 AI는 그동안 축적된 방대한 건축 데이터를 바탕으로 최적화된 설계안을 제시합니다.

AI는 수많은 사례를 학습하여 공간 활용을 극대화하는 동시에 구조적 안정성을 확보하는 등, 건축 설계의 핵심 과제들을 효과적으로 해결하는 것이죠.

이는 마치 수십 년 경력의 베테랑 건축가들이 머릿속에 축적해온 경험과 노하우를 데이터화하여 AI에 주입한 것과 같은 효과를 냅니다.

AI를 활용해 건축가들은 공간 배치, 구조, 재료 등을 추천받을 수 있을 뿐 아니라 설계 과정에서 발생할 수 있는 문제점까지 미리 찾아내 대안을 제시할 수 있게 된 것이죠.

이렇듯 플랫폼 엔지니어링과 AI의 결합은 제품 설계뿐 아니라 건축 설계 분야에서도 혁신을 주도하고 있습니다.

방대한 데이터를 기반으로 한 AI의 설계 제안은 설계의 효율성과 정확성을 높이고, 나아가 건축가들의 창의력에 날개를 달아주고 있는 것입니다.

대중화된 생성형 AI가 불러올 변화

생산 현장에서의 AI 혁명은 이미 시작되었습니다.

특히 '대중화된 생성형 AI'는 제조 과정에서 엄청난 변화를 불러올 것으로 기대됩니다.

'대중화된 생성형 AI'란 ChatGPT나 Midjourney 같이 이제는 일반인들도 쉽게 접하고 활용할 수 있게 된 AI 기술을 의미합니다.

과거에는 AI가 전문가들만의 영역이었다면, 이제는 누구나 손쉽게 AI를 활용해 창의적인 결과물을 만들어낼 수 있게 된 것이죠.

일례로 작가의 재능이 없는 사람도 AI 작문 도우미를 활용하면 훌륭한 글을 쓸 수 있게 되었습니다.

디자인 감각이 부족한 사람도 AI 디자인 툴을 이용하면 전문가 수준의 디자인을 만들 수 있죠.

이렇듯 대중화된 생성형 AI는 창작의 영역에서 일반인들의 잠재력을 극대화시키는 혁신적 기술로 자리매김했습니다.

제조업 분야에서도 이런 대중화된 생성형 AI의 파급력은 실로 엄청날 것으로 보입니다.

기업들은 생성형 AI를 제품 디자인, 설계, 생산 프로세스에 도입함으로써 생산성과 창의성을 동시에 높일 수 있게 되었습니다.

숙련된 전문가가 부족해도 AI와 협업하면 고품질의 제품을 효율적으로 만들어낼 수 있게 된 것이죠.

제품 생산에서 AI의 역할이 커질수록 기업의 AI 활용 능력 자체가 경쟁력의 핵심 요소가 되는 셈입니다.

한편, 'AI 증강 개발'이라는 기술은 제품의 품질 관리 분야에 상당한 변화를 가져올 전망입니다.

AI 증강 개발은 제품 개발 프로세스 전반에 AI 기술을 접목해 '개발 효율과 정확성'을 높이는 것을 의미합니다.

전통적으로 소프트웨어 개발은 전적으로 인간 개발자의 역량에 의존해 왔습니다.

개발자가 직접 코드를 작성하고 버그를 찾아내며, 테스트를 수행하는 식이었죠.

그러나 AI 증강 개발 환경에서는 인공지능이 개발자들의 든든한 조력자로 변신합니다.

가령 개발자가 코딩을 하는 동안 AI가 실시간으로 코드를 분석해 오류를 찾아내고 개선안을 제시할 수 있습니다.

방대한 코드를 분석해 잠재적 버그를 찾아내고 코드 효율성을 자동으로 측정하는 것도 AI의 몫이죠.

이는 개발 속도를 높이고 실수를 최소화하는 데 결정적 도움을 줍니다.

나아가 이런 AI 증강 개발 기술은 품질 관리 분야에도 활용될 수 있습니다.

제품 생산 과정에서 쏟아지는 방대한 데이터를 AI가 분석하면 품질 이슈를 사전에 예측하고 대응할 수 있게 됩니다.

예컨대 생산 설비에 부착된 수많은 센서들이 보내오는 데이터를 AI가 분석해 기계 고장의 조짐을 미리 포착하고 정비를 제안할 수 있는 식입니다.

마치 노련한 장인이 직접 제품 하나하나를 꼼꼼히 검수하는 것과 같은 효과를 기대할 수 있는 거죠.

이를 통해 불량률은 낮추고 제품 신뢰도는 높일 수 있으며, 궁극적으로는 소비자 만족도 제고와 브랜드 가치 향상으로 이어질 수 있습니다.

이처럼 AI 기술은 제조 현장의 모든 영역에서 혁신을 주도하고 있습니다.

제품 설계부터 생산, 품질 관리에 이르기까지 AI의 역할은 점점 더 확대되고 있죠.

그러나 이는 AI가 인간을 대체한다는 의미가 아닙니다.

오히려 AI는 인간의 능력을 증강시키고, 인간과의 협업을 통해 더 큰 가치를 창출하는 방향으로 진화한다고 봐야겠죠.

단순 기능적 업무는 점차 AI에게 넘겨주되, 앞으로는 창의력, 감성 지능, 비판적 사고 등 인간 고유의 영역을 더욱 가치 있게 발전시켜 나가야 할 것입니다.

AI로 새롭게 탄생하는 물류와 CS 시장

물류와 고객 서비스, 이 두 영역은 기업 경쟁력의 핵심 요소임에도 그동안 기술 혁신의 손길이 좀처럼 미치지 않던 분야였습니다.

그러나 이제 'AI 지능형 애플리케이션'의 등장으로 게임의 판도가 바뀌고 있습니다.

'지능형 애플리케이션'이란 쉽게 말해 AI 기술로 무장한 스마트한 애플리케이션을 의미합니다.

사용자의 행동과 선호를 학습하고 분석해 개인화된 서비스를 제공하는 것이 특징이죠.

우리에게 익숙한 넷플릭스나 유튜브 같은 플랫폼이 대표적인 사례입니다.

여러분의 시청 이력을 분석해 취향에 꼭 맞는 영화를 추천하고, 개인별로 최적화된 콘텐츠를 제안하는 이들 서비스의 중심에는 AI가 있습니다.

넷플릭스는 AI 추천 엔진을 통해 고객 이탈을 방지하고 구독 유지율을 높이는 데 성공했죠.

이러한 개인화 경험은 AI 지능형 애플리케이션의 핵심 가치라고 할 수 있습니다.

그렇다면 이 기술은 물류 분야에 어떤 변화를 가져올까요?

주문량, 실시간 교통 상황, 날씨까지 모든 변수를 고려해 최적의 배송 경로를 찾아내는 AI 기반 물류 시스템을 상상해 보신 적 있나요?

이러한 시스템은 숙련된 베테랑 기사의 노하우를 알고리즘화해 배송 효율을 극대화할 수 있습니다.

실제 아마존은 이러한 AI 물류 시스템을 도입해 배송 시간과 비용을 크게 절감한 바 있죠.

AI는 재고 관리 영역에서도 혁신을 이끌고 있습니다.

과거 판매 데이터와 시장 트렌드를 종합 분석해 최적의 재고량을 예측하는 것이죠.

소위 '골디락스' 재고, 즉 과하지도 부족하지도 않은 적정 재고를 유지하는 것은 모든 기업의 숙원 과제였습니다.

AI는 이제 이 숙제를 훌륭히 해결하고 있는 셈이죠.

고객 서비스 분야에서도 AI의 활약은 눈부십니다.

24시간 운영되는 AI 챗봇은 이미 많은 기업의 고객 응대 최전선에 배치되었습니다.

간단한 문의사항은 물론 복잡한 문제 해결까지, AI 챗봇은 고객의 니즈에 철저히 최적화된 서비스를 제공하고 있죠.

이렇듯 지능형 애플리케이션의 확산은 물류와 고객 서비스 분야에 새로운 패러다임을 예고하고 있습니다.

이는 곧 전체 생산 프로세스에 걸친 대대적인 AI 혁명을 의미하기도 합니다.

지금까지 살펴본 바와 같이, 가트너가 제시한 트렌드들은 생산 프로세스 전반에 걸쳐 AI와의 협업이 확산될 것임을 시사하고 있습니다.

생산자들에게 AI는 이제 선택이 아닌 필수가 되어가고 있는 셈이죠.

하지만 이는 AI가 인간을 완전히 대체한다는 의미는 아닙니다.

오히려 AI와 인간이 각자의 강점을 살려 시너지를 만들어가는 새로운 협업 모델이 자리 잡을 것으로 전망됩니다.

단순 반복 업무는 AI에 맡기고, 인간은 보다 창의적이고 전략적인 역할에 집중하는 식이죠.

이런 변화의 소용돌이 속에서 기업들은 AI 시대에 걸맞은 방향성을 모색해야 할 때입니다.

단순히 AI 기술을 도입하는 것에 그치지 않고, 인간과 AI가 조화를 이루며 공존할 수 있는 방안을 고민해야 하는 것이죠.

더불어 우리는 '일'의 본질적 가치에 대해서도 새롭게 돌아볼 필요가 있습니다.

AI가 점점 더 많은 영역을 담당하게 되는 시대에 과연 인간은 어떤 가치를 창출하고 전달할 수 있을까요?

단순히 '무엇을 하느냐(What)'를 넘어 '어떻게 하느냐(How)'의 문제가 더욱 중요해질 것입니다.

'AI와 인간의 시대'라는 화두는 생산자에게만 국한되지 않습니다. 소비자 역시 이 변화의 한가운데 서 있기 때문이죠.

머지않아 소비자들도 AI를 활용해 상품을 분석하고 구매 의사결정을 내리게 될 것입니다.

소비자마저 기계화되어 가는 이 시대에 기업은 어떻게 진정한 '가치'를 전달할 수 있을까요?

다음 편에서는 'AI 시대의 소비자'라는 주제를 깊이 있게 살펴보고자 합니다.

빠르게 진화하는 AI 기술이 소비자들의 행동과 기대에 어떤 변화를 가져올지, 그리고 기업들은 이에 어떻게 대응해 나가야 할지 궁금하신 분들은 2탄을 기대해 주세요.

오늘 칼럼도 유익하셨길 바라며, 윙블 팀은 더 알찬 내용으로 다시 찾아뵙겠습니다.

감사합니다.



Written by.

[IT 전문 블로그 마케팅 팀 윙블]

작년 8월, 마지막 글 작성 후 9개월만에 다시 돌아왔습니다.

저는 매장 음악 브랜딩 및 큐레이팅 서비스를 운영하고 있는 박완입니다.

작년 8월, MVP를 테스트하는 과정을 글로 남기겠다는 말만 남기고 의지가 부족해 글을 작성하지 못했습니다.

결론적으로 말하자면, 저는 아직 서비스를 진행하고 있습니다....! (제가 계획한 대로 말입니다 ㅎ)

작년 8월 이후 남기지 못했던 저의 로그를 이곳에 남겨보려 합니다...!

그럼 20000

연봉 1억 개발자는 왜 자신을 구독서비스로 만들었나?

안녕하세요 메이커 여러분,

한때 연봉 1억 받던 개발자 이성관입니다. 😂😂😂

오늘은 제가 최근에 런칭한 Product201에 대해서 얘기해보려고 합니다.

Product201은 시니어 개발자(저 🤣)를 월 구독 멤버십 형태로 구독할 수 있는 서비스 입니다.

개발자 구독 서비스를 시작한 이유

저는 스타트업과 외주 프로젝트를 하면서 저와 고객사들이 반복적으로 경험하는 몇 가지 문제를 발견했습니다.

1. 추가 비용 협상 : 계약때 요구사항과 실제 요구사항이 달라지면서 생기는 추가비용에 대한 이슈는 항상 골치거리였습니다. 스타트업 제품의 특성상 비니지스 니즈에 맞게 빠르게 변화해야하는데, 이미 비용을 산정한 외주 프로젝트는 변경건마다 또다른 협상을 진행해야 했습니다.

2. 시니어 채용의 어려움 : 스타트업에서 외주 프로젝트로 진행하게 된 이유에는 믿고 맡길만한 시니어 개발자를 채용하기 부담스럽거나, 채용 자체가 어려운 경우가 많았습니다.
   

3. 여러가지를 만들고 싶은 나의 욕구 : 하나의 제품을 너무 오래 만드는것은 제 성향에 안 맞았습니다. 회사를 다닐때도 항상 신사업부서를 기웃기웃 거렸죠. 그래서 다시 취업을 하는게 아닌 외주 프로젝트와 솔로프러너로 활동을 하고 있었습니다.

이러던 와중에 조쉬님의 뉴스레터를 통해 DesignJoy를 알게 되었습니다.

DesignJoy는 디자이너의 작업을 구독 서비스화 시킨 서비스입니다.

월 구독료를 받고 어떤 디자인 작업이라도 요청할 수 있습니다.

필요없으면 넷플릭스를 해지하듯 해지하면 되었구요. 다시 필요하다면 재구독도 가능합니다.

DesignJoy처럼 개발자의 작업도 구독 서비스화 시킨다면 어떨까 하는 생각을 하게 되었습니다.

필요할때 구독하고, 필요없을때 해지할 수 있지만, 시니어 개발자의 퀄리티로 개발 태스크를 진행해준다면?

추가 기능에 대한 비용협상없이 내부 개발자에게 업무를 주듯 진행할 수 있다면?

분명 리소스의 한계가 있으니 DesignJoy를 레버런스 삼아, 개발자의 작업에 몇가지 제약사항을 추가하면서 서비스화 시키는 작업을 시작했습니다.

• 오프라인 미팅을 없애고, Trello로 소통

• Full remote

• 웹은 NextJS, 앱은 React Native로 기술스택을 고정

• 하나의 task에서 QA가 완료된 이후 새로운 task 시작

• 영업미팅은 “되는시간”을 통해 15분으로 단축

최대한 개발시간을 확보하기 위해서 불필요한 시간을 줄이려고 했고,

고객사마다 기술스택이 달라지면서 생기는 비효율을 없애려고 기술스택을 고정했습니다.

기술스택은 제 기준으로 가장 생산성이 높은 기술스택을 채택했구요.

초기 고객을 모집하는 과정

개발자를 필요하는 회사는 많습니다. 하지만 구독하고 싶은 회사는 어떤 회사일까 고민을 했습니다.

우선은 시니어개발자는 아주 초기 단계의 스타트업에 잘 채용이 되지 않습니다. 페이/스톡옵션/컬쳐핏 등등 맞춰야 될 조건도 많고, 스타트업이 시니어개발자에게 접근하기도 쉽진 않죠.

그리고 투자를 안받은 스타트업은 구독 비용을 아직 감당할 수 없을 것 같아서 아래와 같이 초기 고객 프로필을 정리했습니다.

• Seed혹은 PreA 라운드 투자를 유치한 스타트업

제 경험상 이 시기에 개발인력에 대한 채용 니즈가 생기고, 일도 많아져서 기존 인력의 피로도도 높아졌었습니다. 이런 고객사를 모집하기 위해 wanted와 혁신의숲을 이용해 영업 리스트를 만들고, 하루에 50개씩 콜드메일을 돌리면서 서비스를 알리고 있습니다.

• wanted에 시니어 개발자 채용 공고를 낸 스타트업

• 혁신의숲에서 투자이력이 있는 스타트업

프로덕트201의 초기고객의 성공을 통해서 입소문이 나도록 만드는것이 우선은 첫 목표입니다.

시니어 개발자의 리소스가 바로 필요하시다면 Product201을 구독해주세요!

https://product201.com

다음번 메이크로그에서는 성과를 가지고 돌아오겠습니다.

B2B 마케팅/세일즈 전략, 잘 배우고 갑니다!

EventUs 안영학 대표님의 포스팅을 보고 행사를 확인했습니다. 제겐 너무도 좋은 세미나가 될 것 같아 바로 신청했는데요. 소문난 잔치에 먹을 것 많았습니다.

마케팅과 세일즈의 연결성 및 연결 고리, 최신 추세를 배울 수 있었습니다. 그리고 매번 회자되는 이야기이긴 하지만 여러 업체들이 다 동일하게 마케팅을 하고 있음을 확인할 수 있었습니다. 결국 콘텐츠, 검색 광고, 오프라인 행사, 뉴스레터 등이 주효한 공격 루트임을 상기할 수 있었습니다.

많은 사람들이 비슷한 생각을 했을 것 같습니다. 바로 고상혁 대표님의 세일즈 강연이 참 유익했습니다. 콜드 메일과 링크드인 전략을 설명해주셨는데, 두 가지 모두를 진행하고 있는 저에게 큰 위안, 도움, 혜안이 되었습니다. 특히, 링크드인 전략이 굉장히 맛있었는데요(?). 각 유형별로 스크립트를 나누고 시간차를 두어 지속적으로 연락하는 것입니다. 저도 잘 활용해보고 직접 수정 및 개발도 해봐야겠습니다.

다음으로 세일즈맵 정혜영 대표님의 CRM 강연이 있었습니다. 파이프라인을 설계할 때, 여러 실수를 범할 수 있는데 실패한 리드이더라도 잘 관리하고 주기적으로 연락해서 회사를 알리는 것이 중요할 것 같습니다.

강연을 끝으로 네트워킹 시간이 있었습니다. 참 재미있는 것은 13년 전에 연합 동아리에서 만난 형을 또 만났다는 겁니다. 2011년 이후 만난 적이 없었고 연락도 끊겼는데, 같은 업계에서 만난다는 것이 참 신기합니다. 작년에 Market Fit Lab행사에서 인사했는데 또 만나게 되어 우린 인연입니다.

참고로 Market Fit Lab은 그로스해킹 컨설팅 회사로, 고객의 마케팅 문제를 해결해주고 있습니다. 또한, 리셀러 역할을 하고 있는데 Mixpanel을 중점적으로 판매하고 있습니다. 믹스패널을 통해 여러분의 마케팅 효과 분석을 진행할 수 있으니 참고하시면 좋겠습니다.

#B2B #마케팅 #세일즈

#AI 인사이트가 궁금하다면

🚀연고대 출신 팀원이 있는 스타트업에 2달 뒤 1.2억 투자합니다.

제 8회 공명전 연세대, 고려대 출신 스타트업 투자 유치 프로그램

💡 제 8회 공명전은 어떻게 활용하는 게 좋을까요?

활용법 ① 직접 투자를 확정적으로 집행합니다.

선정 기업에는 공명파트너즈가 직접 투자를 확정적으로 집행한다는 점이 매력적입니다. 본선 10개 팀이 두 달간 프로그램에 참여하며, 최다 득표 1개 스타트업에 직접 투자합니다.

활용법 ② 효용 있는 투자유치 사업

직접 참여했던 관계 기업에 따르면 실제로 효용이 있는 사업이라고 합니다. 선정 시 확정 투자가 집행되는 것도 매력적이지만, 공명전 두 달 동안 약 500명의 개인 투자자와 투자사를 만나 기업 정보를 공개하고 네트워킹 할 수 있기 때문에 1위로 선정되지 않더라도 충분히 사업 상의 다양한 기회를 만들 수 있는 프로그램입니다.

활용법 ③ 참석하는 것만으로 얻어가는 설명회

5월 16일(목) 마루180에서 오프라인 설명회를 진행합니다.(150명 수용) 설명회에 참석하는 것만으로도 연세대, 고려대 출신 스타트업 간 네트워킹을 기대할 수 있습니다. 또한 설명회 중 킹슬리벤처스, 스마일게이트 인베스트먼트 심사역 토크쇼 & 누적 투자액 750억 동문 창업가 특강 등 다양하고 유익한 프로그램을 진행합니다. 투자 유치를 희망하는 연세대, 고려대 대표님들이라면 설명회 참여만으로도 많은 것을 얻어가실 수 있으니 꼭 참석하셔서 좋은 경험과 인사이트를 얻어가시길 바랍니다.

👤 제 8회 공명전의 지원 대상은 이렇습니다.

기업 밸류 50억 이하 고려대, 연세대 창업가 출신 스타트업을 모집합니다.(재학,졸업 무관)

대표님 본인이 아니어도 C레벨에 각 학교 출신 팀원이 있다면 지원 가능합니다.

예비창업자, 기창업자 무관하며 전 분야 지원 가능합니다.

🎁 제 8회 공명전의 지원혜택은 어떤 것들이 있을까요?

지원혜택 ① 최다 득표 스타트업 투자 집행

공명전 참가 스타트업 중, 투자자 투표를 통해 최다 득표 스타트업을 선정합니다. 선정 스타트업에는 공명파트너즈가 직접 투자를 진행합니다.

평균 투자 금액은 1.23억원입니다. 투자 후 타 투자사의 투자 유치를 통해 해당 라운드의 투자 목표액(5억~10억)을 채우는 경우도 있습니다. 이는 기업 재량이나 공명파트너즈에서 투자사 미팅을 추천해드리는 등 유망 스타트업을 적극 지원하고 있습니다.

지원혜택 ② 투자사 미팅 기회 확보 & 투자자 직접 소통 통한 협업 구조

약 두 달간 진행하는 프로그램으로, 공명전 진행 기간 동안 약 500명의 개인 투자자와 투자사에 기업 정보가 공개되어 미팅 기회와 가능성을 확보할 수 있습니다. 또한 투자자와 직접 소통할 수 있어 사업 상의 여러 협업 구조를 만들 수 있습니다.

지원혜택 ③ 노하우 혜택

제 8회 공명전은 노하우 팀이 기획에 참여하게 되었습니다. 대표님들께서 더욱 풍성한 경험과 도움을 얻으실 수 있도록 노하우 팀에서도 다음과 같은 혜택을 준비하였습니다.

• 합격사업계획서 등 창업 관련 자료 & 지원사업 팁 등 제공

• 퓨처플레이, 카카오벤처스를 포함한 국내 VC 후속 투자 연결

• 본선 진출 팀 대상 인터뷰 콘텐츠 발행 및 홍보 지원

• 1차 선발된 기업 대상 무료 멘토링 진행

💌 참여만으로 혜택이 가득한 오프라인 설명회에 초대합니다!

공명전 프로그램 소개 뿐 아니라, VC 관점에서의 투자유치 방법과 꿀팁을 담은 특강, 동문 창업가 토크쇼 등 참여하는 것만으로 많은 혜택을 얻으실 수 있는 프로그램으로 구성하였습니다. 꼭 참여하셔서 투자에 대한 인사이트를 얻고 공명전 합격률도 높이시는 기회를 가지시면 좋겠습니다.

일시 : 2024.05.16 (목) 15:00 ~ 18:00 (약 3시간)

장소 : 마루180 (서울 강남구 역삼로180)

설명회 일정

① (프로그램안내) 공명전 소개 및 지원 혜택

② (특별강연) 고려대 출신, 누적 투자 750억 스타트업 대표의 투자 이야기

③ (투자토크쇼) VC 관점에서의 스타트업 투자 방법과 꿀팁

- 킹슬리벤처스 김주연 심사역

- 스마일게이트 인베스트먼트 조유진 팀장

- 공명파트너즈 심사역

④ (네트워킹) 연세대, 고려대 참가 스타트업 자율 네트워킹

설명회 신청 : 신청폼 접수

❓ 제 8회 공명전에 신청하고 싶으신가요?

신청방법

• 신청폼 접수

• 공고문 페이지 확인

• 공명전 준비 단톡방

제출서류

• 신청폼

• IR Deck

기타 사항

신청기간 : 2024.04.22 (월) ~ 2024.05.29 (수)까지

문의처 : ssonglike@gmail.com (공명파트너즈 김송이)

저희 노하우 팀은 스타트업과 관련한 모든 정보와 기회가 한 자리에 모이고,

창업가를 존중하는 문화가 확산될 수 있도록 오늘도 최선을 다하겠습니다🔥

대한민국을 실리콘밸리로 🚀 감사합니다.

스타트업 정보 제공 플랫폼 KNOWHOW

개인 카페 부터 프랜차이즈 카페까지 인스타그램 패턴 분석 (팔로워 2000~10만 계정 분석)

안녕하세요,

어제 10만 팔로워를 가진 인플루언서들의 인스타그램 계정을 분석하는 글을 올렸습니다.

아니, 업보트가 10개나 나오고, 좋아요도 7분이나 눌러주시고, 댓글도 3분이나 써주시다니,,!

제 인사이트를 공유하는게 참 보람차고 재미도 있네요.

이전 글

▶ 10만 팔로워 인스타그램 분석:

🔥선착순 10명 혜택🔥

제가 분석한 시트를 이메일로 보내드릴게요. 이전 시트보다 더 많은 내용들이 담겨있습니다!

(지난번 글에 그냥 공개했더니, 저는 나름 엄청 고민한 분석인데 너무 하릴없이 흘러간다,, 진짜 가치있어하는 분들께 전달드리고 싶다 생각들어서 이번부터 직접 전달드리는 형식으로 바꾸려고 합니다!)

지난 글에서 언급 했었지만, 저는 현재 10개월 때 건대에서 카페를 운영중에 있습니다.

가게 운영하시는 사장님들은 전부 공감 하시겠지만,,

와 이 인스타그램이라는게,,

사실 인스타그램이 그렇게 효과가 있느냐? 라고 말하면, 사장님들은 [글세,,] 라는 답이 올 거에요.

위 질문을 다시 말하면 -> 인스타그램을 보고 사람들이 내 가게에 오느냐? [글세,,] 거든요.

그런데 왜 [글세,,]라는 대답이 나올까요?

왜냐면, 인스타그램을 제대로 관리하지 않고 계시기 때문이에요.

지난 글 댓글에 이 내용이 있었어요. 인스타그램관리하는것 보다 리뷰 여러개 쌓는게 효과적이라구요.

저는 그 댓글을 보면서 또 어떤생각이 들었냐면요.

각각의 리뷰가 소비자들이 정성스럽게 작성한 리뷰였고, 그게 여러개 쌓인 효과가 있는것 아닐까요?

만약 인스타그램도, 제가 여러개 정성스럽게 쌓으면 그게 나비효과가 되어서 손님들을 불러모을 수 있지 않을까요?

사실 저도 잘 모릅니다. 마케팅 비전공자고, 인플루언서가 아니고, 10년째 장사나 사업을 하는 사람도 아니지만, 한번 실험해 보고 싶었어요. 인스타그램으로 사람들을 모을 수 있을까? 그럴려면 어떻게 해야하는걸까?

그래서 지금 매일 실험해보는중에 있습니다. 그 결과는 약 일주일이나 이주일 후에 데이터가 쌓이면 또 공유해드릴게요.

아직 실험한지 이틀밖에 안되었는데, 벌써 눈에 띄는 결과가 나오고 있어서 굉장히 흥미진진해요.

오늘은 저번 글 맨 마지막에 적었던것과 같이, 나는 카페를 홍보하고 싶은거지, 인플루언서가 되고싶은게 아니다..! (물론 인플루언서 계정이 되면 좋겠지만)

그래서 이번에는 카페 분석글을 가지고 왔습니다!

☕️카페 인스타그램 분석 ☕️

팔로워 수 최소 2000부터 13만이 넘는

카페 계정들의 인스타그램 포스팅 패턴 분석!

개인카페 계정 팔로워 수 2000명 & 12만명

카페와 주문배달 계정 팔로워 수 2000명 & 1만명

프랜차이즈 카페 본사 계정 팔로워 수 13만명 & 4만명

을 포함해서 총 10개 계정을 살펴봤습니다.

최대한 각 부문별로 2개 계정 이상 찾으려고 했고, 또한

1만 이하 팔로워수를 가진 계정들의 패턴과

1만 이상 팔로워수를 가진 계정들을 비교할 수 있을지 살펴봤습니다.



1. 팔로워 수와 좋아요 수의 상관 관계

비교군이 많아 제가 인사이트를 얻은 계정들만 집어서 분석해보도록 하겠습니다.

계정 a: 2000 팔로워 -> 좋아요 10개 (1/200 수준)

계정 b: 2500 팔로워 -> 좋아요 250개 (1/10 수준)

위 계정을 보면, 팔로워 수는 비슷한테 좋아요 수가 굉장히 확연히 차이가 많이 났습니다.

팔로워 수가 2000일 때 좋아요를 10개만 받는 계정은 -> 팔로워수는 많으나, 바이럴이나 혹은 팔로워들과 소통이 잘 되지는 않고있는 계정이라고 볼 수 있었고,

팔로워수가 2500인데 좋아요를 250개를 받는 계정은 -> 정말 팔로워들과 소통이 정말 잘 되는 계정이구나 를 볼 수 있었습니다.

그래서 왜 그럴까, 해당 계정들을 더 뜯어보니까

2000팔로워를 가진 계정 a의 경우 인스타그램 오픈 초기에는 매일 포스팅을 올렸었고, 그 때는 좋아요 수가 30~60 사이로 잘 받은걸 볼 수 있었습니다. 다만 중간에 1년간 포스팅을 하지 않고, 근래 다시 이틀에 1번씩 포스팅하는걸 볼 수 있었습니다.

팔로워 수 2500에 좋아요를 250을 받는 계정의 경우는 매일매일 일기와 같은 본인의 스토리 (스타 팬미팅을 갔다 왔다 등)를 올리고 있었고, 중간에 포스팅이 끊기지 않은걸 볼 수 있었습니다.

▶▶여기서 인사이트

1. 포스팅 매일 하다가 중간에 끊기면 그때부터 좋아요 수가 확연하게 끊기는구나.

2. 너무나 남들이 다 아는 어떤것 보다, 본인만이 들려줄 수 있는 스토리가 있으면 반응을 더 얻는구나

2. 좋아요 수와 댓글 수의 상관 관계

계정 b: 2500 팔로워 -> 좋아요 250개 & 댓글 3개

계정 c: 4000 팔로워 -> 좋아요 10개 혹은 2000개 & 댓글 1개 혹은 30개

계정 d: 10만 팔로워 -> 좋아요 300개 & 댓글 5개

저는 위에서 팔로워 수가 많고, 좋아요 수도 굉장히 높았던 계정 b의 경우, 본인의 스토리를 많이 올리니까 다른 사람들과 소통도 많이 하겠지라고 막연하게 생각하며 댓글도 많이 달릴것이라는 생각이 있엇는데, 반대로 댓글이 3개만 달리는 것을 볼 수 있습니다.

10만 팔로워를 가진 계정 d도 평균적으로 댓글이 5개 내외로만 달리는것을 볼 수 있었습니다.

카페 인스타그램에 댓글로 소통하는것은 그렇게 많이 있지는 않구나, 생각을 하며, 계정 c를 봤는데, 음? 좋아요 10개 혹은 2000개? 댓글도 너무나 양극화가 심했습니다. 그리고 예전 포스팅을 흘러흘러 살펴가보니, 좋아요 1개 좋아요 0개 더라구요.

음. 계정 c는 좋아요작업 혹은 팔로워 작업 (돈내고 좋아요 혹은 팔로워를 사는 것)을 했을수도 있겠다 생각이 퍼뜩 들었습니다.

그게 물론 나쁜것이 절대 아니고, 가게를 운영하는 입장에서, 특히 인스타그램 핫플이 되고 싶은 입장에서 당연히 할 수 있다는 생각이 들었지만, 한편으로 또 든 생각은, 만약 이런 작업을 한다면 얼만큼 지속할 수 있을까? 나중에는 힘이 들겠다 생각이 들었습니다. 실제로 근래에는 포스팅이 없기도 했구요.

▶▶여기서 인사이트

1. 아무리 팔로워 수 대비 좋아요를 많이 받아도, 이것은 댓글 수와는 크게 관련이 없는듯 하다.

2.돈주고 좋아요, 팔로워 수를 사게된다면 (이게 절대 나쁜건 아니지만) 얼만큼 지속할 수 있을까? 궁금하다 (가게는 결국엔 누가 얼마나 오래 버티느냐의 싸움인듯 하기에.)

3. 업로드 주기

포스팅 주기는 모든 계정을 통틀어서

좋아요를 팔로워 대비 많이 받는 계정의 경우 하루 1개

좋아요를 팔로워 대비 덜 받는 계정의 경우 3일에 1개

정도 되는것을 볼 수 있었습니다.

▶▶여기서 인사이트

1. 좋아요 수를 많이 받으려면, 결국엔 물량공세가 답인가?

4. 포스팅 패턴

포스팅 패턴의 경우 사진은 1장~2장 내외로 업로드 하는 계정들이 많았고,

그렇지 않다면 릴스를 올리는 계정들이 많았습니다.

릴스와 사진을 번갈아가면서 올려서 릴스 1개에 포스팅 3개정도를 번갈아가며 올리는 계정들이 대부분 이었습니다.

또한 태그의 경우 5개 내외라면 본문에 첨부를 하는 반면에 10개 이상의 태그를 올린다면 댓글을 통해 태그를 숨기는 경우가 많았습니다.

포스팅 패턴을 요약하자면;

- 사진: 1장 혹은 릴스

- #태그: 5개~ 30개 (10개 이상부터는 댓글로 숨김처리)

- 글자 수: 300자 ~ 450자

- 문단: 3개

그리고 지난번 글에서 언급했던 인플루언서의 경우 문장형태가 ~다. ~습니다. ~죠. 이렇게 끝나는 경우가 많았던 반면에 카페 인스타그램은 일괄로 전부 ~요. 로 끝나는 걸 볼 수 있었습니다. 아무래도 더 친근감 있게 다가가고 싶어서 그런듯 싶습니다.

▶▶여기서 인사이트

1. 태그를 본문에 넣고 싶다면 5개 내외로! 10개를 넘기지 말자!

2. 카페 포스팅의 경우 친근감이 중요하다! 어문은 ~~요 로 통일!

5. 사진

마지막으로 사진패턴 분석입니다.

굉장히 흥미진진 했습니다.

분석중 제일 흥미로웟어요.

차이점을 찾으셨을까요?

제가 발견한걸 알려드릴게요.

제가 6개 사진을 왼쪽 3개와 오른쪽 3개로 분리해 놓았는데요, 한번 왼쪽과 오른쪽을 비교해서 봐보세요.

무엇을 찾으셨나요?

바로 이전 글에서도 발견했듯이, 사진위에 글이 올라가 있느냐? 없느냐의 차이입니다.

오른쪽에서도 사진위에 글이 올라가지 않은 포스팅도 있지만.

동일 계정을 비교했을 때 사진 위에 글이 있는 포스팅과 없는 포스팅을 비교했을 때 사진위에 글이 있으면 좋아요 수가 2배에서 5배까지도 차이가 나는것을 볼 수 있었습니다.

반면에 왼쪽의 글이 없는 사진 위주의 포스팅의 경우, 그냥 꾸준히 동일한 개수의 좋아요를 받고 있었어요.

갬성 위주의 인스타그램을 할 것이냐, 활기찬 느낌의 인스타그램을 할 것이냐에 따라 다른 방향성을 가지고 가야할것 같다고 생각이 들었습니다.

▶▶여기서 인사이트

1. 카페 포스팅에서도 사진위에 글이 올라갔을 때 좋아요를 더 많이 받는다.

2. 하지만 글이 올라가는 순간 갬성이 떨어지기 때문에, 어떤 스타일의 인스타그램 계정을 만들고 싶은지 본인이 결정해야 한다. 그리고 중요한것은 일관성!

5. 인사이트 총합

1. 포스팅 매일 하다가 중간에 끊기면 그때부터 좋아요 수가 확연하게 끊기는구나.

2. 너무나 남들이 다 아는 어떤것 보다, 본인만이 들려줄 수 있는 스토리가 있으면 반응을 더 얻는구나

3. 아무리 팔로워 수 대비 좋아요를 많이 받아도, 이것은 댓글 수와는 크게 관련이 없는듯 하다.

4.돈주고 좋아요, 팔로워 수를 사게된다면 (이게 절대 나쁜건 아니지만) 얼만큼 지속할 수 있을까? 궁금하다 (가게는 결국엔 누가 얼마나 오래 버티느냐의 싸움인듯 하기에.)

5. 좋아요 수를 많이 받으려면, 결국엔 물량공세가 답인가?

6. 태그를 본문에 넣고 싶다면 5개 내외로! 10개를 넘기지 말자!

7. 카페 포스팅의 경우 친근감이 중요하다! 어문은 ~~요 로 통일!

8. 카페 포스팅에서도 사진위에 글이 올라갔을 때 좋아요를 더 많이 받는다.

9. 하지만 글이 올라가는 순간 갬성이 떨어지기 때문에, 어떤 스타일의 인스타그램 계정을 만들고 싶은지 본인이 결정해야 한다. 그리고 중요한것은 일관성!

많은 분들이 아시는 결과일 수도 있고,

새로 발견한 인사이트가 있으신 분들도 있을것 같네요.

이 분석 시트는 선착순으로 10분에게만 이메일로 전달드리도록 하겠습니다. (지난번 글에 첨부된 시트에서 많이 업데이트가 되었어요!)

(지난번 글에 그냥 공개했더니, 저는 나름 엄청 고민한 분석인데 너무 하릴없이 흘러간다,, 진짜 가치있어하는 분들께 전달드리고 싶다 생각들어서 이번부터 직접 전달드리는 형식으로 바꾸려고 합니다!)

https://forms.gle/q8iaLZNfVecwBn877

여기 구글폼에 이메일 남겨주시고, 댓글로 [제출]이라고 써 주세요!

오늘 저녁에 일괄적으로 이메일 전달드리겠습니다!

단톡방에서도 같이 소통해요! 지금 저밖에 없어서 너무 쓸쓸해요 🤣



[Tech for Impact] 포인핸드 LAB: 프로덕트 디자이너로서 내딛는 공식적인 첫걸음

이전부터 항상 기록을 남기겠다고 다짐만 하다가, 이제서야 저의 커리어 기록을 시작하게 되었습니다. 디자인 작업에 바쁘다보니 깨달은 점을 놓치고 있었던 것이 많았습니다. 이제는 조금씩이라도 습관을 들여 제 커리어를 기록해보고자 합니다.

다양한 디자인 프로젝트를 하며 깨달은 점은, 시간이 지날수록 성장과 배움의 과정이 무엇보다도 소중하다는 것입니다. 작은 프로젝트든 큰 프로젝트든, 모든 경험은 저를 더 나은 디자이너로 성장시켜주었습니다. 이러한 성장의 순간들을 기록했을 때, 나중에 돌아보며 어떤 변화와 발전을 거쳤는지 되새기고 더 나은 방향으로 나아갈 수 있을 것이라 생각합니다.

결과에 급급했던 과거의 저는 이런 과정 속에서 배우는 성장에 미처 신경쓰지 못했습니다. 비록 과거에는 놓친 기록들이 많았지만 이제부터라도 꾸준히 디자인 프로젝트를 진행하며, 블로그에 디자이너로써의 성장과 발전을 기록하고, 동시에 다른 이들에게 영감을 주는 프로덕트 디자이너가 되기 위해 노력해보고자 합니다.

최근 모두의연구소와 카카오임팩트가 함께 진행하는 [Tech for Impact] 포인핸드 LAB 프로젝트에 프로덕트 디자이너로 참여하게 되었습니다. 본격적인 프로덕트 디자이너 커리어를 이렇게 큰 프로젝트와 함께 시작할 수 있게 되어 정말 영광입니다.

간단한 제 소개를 드리면, 저는 디지스트에서 기계공학을 전공했습니다. 하지만 학문의 범주를 넘어서 다양한 분야의 문제를 해결하는 것에 관심을 가졌습니다. 자연스럽게 창업에 관심을 가지고 공부하게 됐고, 과학기술원 창업 커뮤니티에서도 운영진으로 활동했습니다. 이후 좋은 기회로 채용 스타트업에서 마케팅 업무를 담당하며 내가 어떤 분야에서 능력을 발휘할 수 있는지 고민하게 되었습니다. 그 결과, 디자인 분야로의 전환을 결심하게 되었고 다양한 프로젝트를 경험하며 디자인 역량을 키워왔습니다. 이런 경험들이 이번 프로젝트에 참여하는 데 큰 자신감과 힘을 주었습니다.

이전에도 다양한 디자인 프로젝트를 진행한 경험이 있었지만, 이번이 프로덕트 디자이너로서의 공식적인 출발이라는 점에서 매우 의미있는 프로젝트입니다. 사용자 규모가 큰 서비스를 디자인하는 일이라는 점에 큰 책임감을 느끼지만, 동시에 유기동물이 가정을 찾는 과정을 개선할 수 있는 기회가 주어짐에 매우 감사하고, 설레는 마음이 큽니다.

이번 프로젝트는 포인핸드 내 채팅 기능 고도화를 통해 유기동물 입양 절차를 개선하고, 유기동물과 사람을 연결하는 데 중점을 두고 있습니다. 제 디자인을 통해 유기동물의 입양 과정에서 더 나은 경험을 제공하는 데 기여하고 싶습니다. 사용자들에게 더 좋은 디자인을 제공하기 위해 항상 발전하고 성장하는 디자이너가 되겠습니다.

감사합니다.