앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기.

사용자의 목소리

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다.
예전에 누군가에게 들었던 이야기.

인상적이었습니다. 진짜 그럴까?

커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다.
말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다.

가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다.
하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다.
난 사용자들 목소리가 듣고 싶은 건데.

커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다.
발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻.
사용자들 목소리 듣기가 얼마나 어려운데…

이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다.

https://jeho.page/essay/2024/10/17/user-voice.html

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기. 인상적이었습니다. 진짜 그럴까? 커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다. 말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다. 가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다. 하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다. 난 사용자들 목소리가 듣고 싶은 건데. 커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다. 발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻. 사용자들 목소리 듣기가 얼마나 어려운데… 이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다. https://jeho.page/essay/2024/10/17/user-voice.html

K리그 프로그래머

앱 스토어 리뷰에 사용자의 목소리가 주로 표현되더라고요. 

사이드 프로젝트 30개 만들어 본 개발자가 느낀
팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지

1️⃣ 팀원은 최소한의 인원으로

- 많은 인원일 수록 더 많은 일들을 할 수 있을 것 같지만, 실제로는 그렇게 되지 못하는 경우가 많습니다

- 의사 결정이 느려지거나 시간을 맞추기 어렵거나 등등 빠르게 서비스를 출시해야 하는 상황일 수록 득보다는 실이 많은 경우가 생기게 됩니다.

- 그리고 서비스 개발 속도는 팀원 수에 꼭 비례하지 않습니다

- 팀원은 최소한으로 (ex. 2~3명)

- 팀 내에 그 일을 할 수 있는 사람이 없을 때 팀원을 1명씩 영입해야 합니다

2️⃣ 모두가 똑같은 속도로 가는 것은 어렵다

- 팀원 모두가 다 같은 속도로 서비스 개발에 참여하여 빠르게 프로덕트를 출시하면 가장 이상적일 것 입니다

- 하지만 현실적으로 팀원 모두가 같은 시간과 노력을 쏟는 것은 불가능 합니다.

- 본업 이외의 시간에 '사이드'로 프로젝트를 진행하기 때문에 임하는 시간이 상대적일 수 밖에 없다는 것을 인지 해야합니다

- 전체적으로는 느슨하게, 하지만 풀어지게 하지 않도록 해야합니다

- 주 1회 이상 정기 회의를 가져 팀 전체의 진행 상황을 공유하고, 타임 라인을 꼭 설정하여 마감 기한을 설정하시기 바랍니다

- 중요한 건 팀내의 동기부여를 얼마나 꾸준하게 지속적으로 가져갈 수 있는 지 입니다

3️⃣ 솔직한 소통이 중요하다

- 혼자하는 것과 팀원이 함께하는 것의 가장 큰 차이점은 커뮤니케이션이 많은 부분을 차지한다는 것 입니다

- 사람 대 사람의 관계가 있기 때문에 의견을 나누는데 있어 솔직하지 못하는 경우가 생깁니다

- '다 좋다고 하는데.. 내가 괜히 반대 의견을 내는 건 아닐까?', '이렇게 말하면 상대방이 무시한다고 생각하지는 않을까..?', '내 의견은 말하기 부끄러운데..' 등등

- 하지만 솔직하게 의견과 생각을 나누지 않는다면 아이디어 선정 단계에서 부터 막히는 모습을 볼 수 있게 됩니다

- 뿐만 아니라 생각했던 방향과 전혀 다른 방향으로 흘러가는 경우도 생기게 됩니다

- 팀원 들이 적극적으로 의견을 낼 수 있어야 합니다. 그러기 위해선 서로 경청할 수 있는 분위기와 문화, 규칙을 만들어 주어야 합니다

사이드 프로젝트 30개 만들어 본 개발자가 느낀팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지 1️⃣ 팀원은 최소한의 인원으로 - 많은 인원일 수록 더 많은 일들을 할 수 있을 것 같지만, 실제로는 그렇게 되지 못하는 경우가 많습니다 - 의사 결정이 느려지거나 시간을 맞추기 어렵거나 등등 빠르게 서비스를 출시해야 하는 상황일 수록 득보다는 실이 많은 경우가 생기게 됩니다. - 그리고 서비스 개발 속도는 팀원 수에 꼭 비례하지 않습니다 - 팀원은 최소한으로 (ex. 2~3명) - 팀 내에 그 일을 할 수 있는 사람이 없을 때 팀원을 1명씩 영입해야 합니다 2️⃣ 모두가 똑같은 속도로 가는 것은 어렵다 - 팀원 모두가 다 같은 속도로 서비스 개발에 참여하여 빠르게 프로덕트를 출시하면 가장 이상적일 것 입니다 - 하지만 현실적으로 팀원 모두가 같은 시간과 노력을 쏟는 것은 불가능 합니다. - 본업 이외의 시간에 '사이드'로 프로젝트를 진행하기 때문에 임하는 시간이 상대적일 수 밖에 없다는 것을 인지 해야합니다 - 전체적으로는 느슨하게, 하지만 풀어지게 하지 않도록 해야합니다 - 주 1회 이상 정기 회의를 가져 팀 전체의 진행 상황을 공유하고, 타임 라인을 꼭 설정하여 마감 기한을 설정하시기 바랍니다 - 중요한 건 팀내의 동기부여를 얼마나 꾸준하게 지속적으로 가져갈 수 있는 지 입니다 3️⃣ 솔직한 소통이 중요하다 - 혼자하는 것과 팀원이 함께하는 것의 가장 큰 차이점은 커뮤니케이션이 많은 부분을 차지한다는 것 입니다 - 사람 대 사람의 관계가 있기 때문에 의견을 나누는데 있어 솔직하지 못하는 경우가 생깁니다 - '다 좋다고 하는데.. 내가 괜히 반대 의견을 내는 건 아닐까?', '이렇게 말하면 상대방이 무시한다고 생각하지는 않을까..?', '내 의견은 말하기 부끄러운데..' 등등 - 하지만 솔직하게 의견과 생각을 나누지 않는다면 아이디어 선정 단계에서 부터 막히는 모습을 볼 수 있게 됩니다 - 뿐만 아니라 생각했던 방향과 전혀 다른 방향으로 흘러가는 경우도 생기게 됩니다 - 팀원 들이 적극적으로 의견을 낼 수 있어야 합니다. 그러기 위해선 서로 경청할 수 있는 분위기와 문화, 규칙을 만들어 주어야 합니다

팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지

초거대 언어 모델(LLM: Large Language Model)을 사용하는 애플리케이션의 개발 및 배포 과정에서 발생하는 문제들은 ML 모델의 개발과 배포 과정에서 생기는 문제들과 마찬가지로 매우 다양하다. 처음 한 번은 LLM 기반 서비스를 만들하고 배포할 수 있지만, 그 후 LLM이 업그레이드되거나 새로운 LLM을 써보려고 한다면 어떤 최적화 및 검증 프로세스를 갖고 있느냐가 굉장히 중요해진다. 여기서 차별화된 경쟁력이 나오며, 이를 LLMOps 엔지니어가 담당하게 된다.

LLMOps는 LLM을 활용하는 다양한 서비스 개발과 운영에 필요한데 보통 RAG(Retrieval Augmented Genenration)라는 모양을 갖는 것이 현재로는 일반적이며 도메인과 관련된 지식을 벡터DB로 별도로 저장하고 이를 최종 프롬프트 생성에 사용하게 된다. 몇 가지 예를 들어보면 다음과 같다.

 1. 대화형 AI 서비스: 챗봇 및 가상 비서 등등
 2. 콘텐츠 생성 및 편집: 작문, 자동 번역, 뉴스 기사 생성 등등
 3. 교육 및 학습: 개인화된 학습 보조 도구, 자동 채점 및 피드백 시스템, 언어학습 등등
 4. 비즈니스 인텔리전스: 데이터 분석 및 보고서 생성, 시장 트렌드 분석 등등
 5. 의료 및 헬스케어: 의료 기록 분석 및 요약, 보험사 청구서 자동 작성, 질병 진단 보조 등등
 6. 법률 및 규제: 법률 문서 분석 및 요약, 계약서 검토 자동화 등등
 7. 소프트웨어 개발: 코드 자동 생성 및 최적화, 버그 검출 및 수정 제안, 개발 문서 자동화
 8. 창작 및 엔터테인먼트: 음악 작곡, 게임 시나리오 및 캐릭터 생성 등등
 9. ...

LLMOps는 위와 같은 서비스를 만듬에 있어 LLM 관련 최적화와 운영, 관리를 책임지는 직군이다. 이 직무는 머신러닝 모델의 생애주기를 관리하는 MLOps와 아주 유사하지만, 머신 러닝 모델을 직접 만들고 그것의 생애를 관리하는 것이 아니라 누군가 만든 LLM(ChatGPT, Claude, Gemini 등등)을 가져다 쓰면서 프롬프트 관리와 RAG와 같은 서비스라면 벡터 DB 등 다른 시스템이 존재하게 되는데 이를 전체적으로 최적화하고 평가하고 배포 후에 비용 등을 관리하면서 운영한다는 점이 다르다.

아직은 LLMOps팀이 전체 프로세스에 걸쳐 사용할 수 있는 하나의 플랫폼은 존재하지 않다고 보여지고 (그런 방향성을 갖고 있는 툴들은 존재) 다양한 툴을 섞어 사용해야 한다.

 * RAG 빌딩 툴: LangChain과 Llama Index가 가장 대표적인데 이 둘의 성격이 많이 다르긴 하지만 LangChain은 너무 복잡한 느낌이 있어서 개인적으로는 Llama Index를 선호한다. 써본 적은 없지만 PromptFlow도 괜찮다는 이야기를 많이 들었다.
 * 벡터 DB: Pinecone, ElasticSearch, Weaviate, VESPA, FAISS, GCP Vertex 등등 아주 많다. 개인적으로는 벡터 임베딩을 통한 검색 뿐만 아니라 키워드 기반 검색도 같이 사용하는 것이 더 효율적이라 생각하기에 이 두 가지를 잘 지원해주는 VESPA가 개인적으로는 가장 마음에 든다
 * 프롬프트 실험 및 관리: 많이 사용해본 툴이 없긴 하지만 Vellum, Baserun이 가장 많이 쓰이는 것으로 보인다. LangChain은 이 부분을 어느 정도 커버하긴 한다.
 * 성능 평가 툴: LLM 기반의 앱의 성능을 평가할 수 있는 테스트셋이 필요하고 이를 버저닝하고 관리할 수 있는 툴이 필요하다. RAG라면 사용되는 벡터DB로부터 사용자 질의와 관련된 정보를 검색해야 하는데 결과 품질을 평가할 수 있는 테스트셋도 필요하다. Ragas, Haystack, Truelens 등이 있고 LangChain도 이 기능을 일부 지원한다

업무에 대해 더 이야기해보자면 보통 LLMOps팀은 개발자와 도메인 전문가 두 직군의 사람이 협업을 하는 형태로 일을 하게 된다.

 * 도메인 전문가 (프롬프트 엔지니어): 프롬프트를 바꿔가며 최적화를 수행하는 역할하는데 결국은 테스트 데이터를 만들어 벡터 DB 등의 검색 품질을 평가하고 최종적으로 RAG 시스템의 품질을 평가해야 한다. 이 과정에서 개발자와 밀접한 협업을 하게 된다.
 * 개발자 (RAG 시스템 개발자): 벡터 DB을 주기적으로 빌딩하고 검색을 수행하며 LLM을 API로 통해 관리(실패시 재시도하거나 다른 LLM 시도, 비용 관리 등등 운영적인 부분이 중요)하며 전체적인 아키덱처를 잡되 프롬프트와 관련된 부분이나 검색 최적화와 관계된 부분에 있어서 앞서 도메인 전문가와 긴밀하게 일을 하게 된다.

개발자 같은 경우 다양한 파이프라인을 만들어야 하는데 하나는 벡터 DB 등의 데이터베이스를 빌딩하는데 필요한 데이터 소스를 긁어오는 ETL 파이프라인과 이렇게 쌓인 데이터들로부터 최종 데이터를 만들고 이를 벡터 DB 등으로 로딩하는 ELT와 Reverse ETL 파이프라인등을 만들어야 하는데 여기서 바로 데이터 엔지니어링 스킬이 필요하다. 다른 파이프라인은 사용자 질의로부터 시작해서 최종적으로 사용자에게 응답을 리턴하는 런타임 파이프라인이며 여기에는 벡터 DB 질의와 LLM 질의 등이 포함되며 비용과 응답 시간 등등 관리해야할 항목이 많다.

LLMOps팀의 개발은 여러 사이클을 반복하는 형태로 이뤄지게 되는데 보통 아래와 같은 스텝을 필요로 한다.

 1. LLM 서비스 기획
 2. 개발
    1. 프롬프트 시스템 개발 (도메인 전문가)
    2. RAG 파이프라인 개발 (개발자). 여기에는 앞에 이야기한 데이터 파이프라인의 개발도 포함된다.
 3. 평가: 오프라인 테스트셋으로 검색과 최종 결과물 평가 두 종류를 가질 수 있다면 최적이다
 4. 스테이징 시스템 배포 후 다시 평가
    1. 이 때는 온라인 테스트도 수행
    2. 전체적인 응답속도 평가도 중요
 5. 만족할 만한 결과가 나올 때까지 2-4를 반복한다.
 6. 최종 배포 후 모니터링 (이때 비용 모니터링도 중요)

LLMOps팀이 궁극적으로 목표로 삼아야 하는 시스템은 도메인 전문가가 개발자와 아주 밀접한 의사소통 없이 셀프 서비스 형태로 원하는 LLM 기반 서비스를 만들 수 있는 No Code 혹은 Low Code 프레임웍을 만드는 것이다. 아직은 이 방향으로 뚜렷한 위너는 안 보이는데 곧 나오지 않을까 싶다. 혹시라도 알고 있는 서비스나 툴이 있다면 댓글 부탁!

다음 글에서는 데이터 웨어하우스에 관해서 프로덕션 데이터베이스와 비교해가며 더 설명해보고자 한다.

초거대 언어 모델(LLM: Large Language Model)을 사용하는 애플리케이션의 개발 및 배포 과정에서 발생하는 문제들은 ML 모델의 개발과 배포 과정에서 생기는 문제들과 마찬가지로 매우 다양하다. 처음 한 번은 LLM 기반 서비스를 만들하고 배포할 수 있지만, 그 후 LLM이 업그레이드되거나 새로운 LLM을 써보려고 한다면 어떤 최적화 및 검증 프로세스를 갖고 있느냐가 굉장히 중요해진다. 여기서 차별화된 경쟁력이 나오며, 이를 LLMOps 엔지니어가 담당하게 된다. LLMOps는 LLM을 활용하는 다양한 서비스 개발과 운영에 필요한데 보통 RAG(Retrieval Augmented Genenration)라는 모양을 갖는 것이 현재로는 일반적이며 도메인과 관련된 지식을 벡터DB로 별도로 저장하고 이를 최종 프롬프트 생성에 사용하게 된다. 몇 가지 예를 들어보면 다음과 같다. <ol ><li>대화형 AI 서비스: 챗봇 및 가상 비서 등등</li><li>콘텐츠 생성 및 편집: 작문, 자동 번역, 뉴스 기사 생성 등등</li><li>교육 및 학습: 개인화된 학습 보조 도구, 자동 채점 및 피드백 시스템, 언어학습 등등</li><li>비즈니스 인텔리전스: 데이터 분석 및 보고서 생성, 시장 트렌드 분석 등등</li><li>의료 및 헬스케어: 의료 기록 분석 및 요약, 보험사 청구서 자동 작성, 질병 진단 보조 등등</li><li>법률 및 규제: 법률 문서 분석 및 요약, 계약서 검토 자동화 등등</li><li>소프트웨어 개발: 코드 자동 생성 및 최적화, 버그 검출 및 수정 제안, 개발 문서 자동화</li><li>창작 및 엔터테인먼트: 음악 작곡, 게임 시나리오 및 캐릭터 생성 등등</li><li>...</li></ol> LLMOps는 위와 같은 서비스를 만듬에 있어 LLM 관련 최적화와 운영, 관리를 책임지는 직군이다. 이 직무는 머신러닝 모델의 생애주기를 관리하는 MLOps와 아주 유사하지만, 머신 러닝 모델을 직접 만들고 그것의 생애를 관리하는 것이 아니라 누군가 만든 LLM(ChatGPT, Claude, Gemini 등등)을 가져다 쓰면서 프롬프트 관리와 RAG와 같은 서비스라면 벡터 DB 등 다른 시스템이 존재하게 되는데 이를 전체적으로 최적화하고 평가하고 배포 후에 비용 등을 관리하면서 운영한다는 점이 다르다. 아직은 LLMOps팀이 전체 프로세스에 걸쳐 사용할 수 있는 하나의 플랫폼은 존재하지 않다고 보여지고 (그런 방향성을 갖고 있는 툴들은 존재) 다양한 툴을 섞어 사용해야 한다. <ul ><li>RAG 빌딩 툴: LangChain과 Llama Index가 가장 대표적인데 이 둘의 성격이 많이 다르긴 하지만 LangChain은 너무 복잡한 느낌이 있어서 개인적으로는 Llama Index를 선호한다. 써본 적은 없지만 PromptFlow도 괜찮다는 이야기를 많이 들었다.</li><li>벡터 DB: Pinecone, ElasticSearch, Weaviate, VESPA, FAISS, GCP Vertex 등등 아주 많다. 개인적으로는 벡터 임베딩을 통한 검색 뿐만 아니라 키워드 기반 검색도 같이 사용하는 것이 더 효율적이라 생각하기에 이 두 가지를 잘 지원해주는 VESPA가 개인적으로는 가장 마음에 든다</li><li>프롬프트 실험 및 관리: 많이 사용해본 툴이 없긴 하지만 Vellum, Baserun이 가장 많이 쓰이는 것으로 보인다. LangChain은 이 부분을 어느 정도 커버하긴 한다.</li><li>성능 평가 툴: LLM 기반의 앱의 성능을 평가할 수 있는 테스트셋이 필요하고 이를 버저닝하고 관리할 수 있는 툴이 필요하다. RAG라면 사용되는 벡터DB로부터 사용자 질의와 관련된 정보를 검색해야 하는데 결과 품질을 평가할 수 있는 테스트셋도 필요하다. Ragas, Haystack, Truelens 등이 있고 LangChain도 이 기능을 일부 지원한다</li></ul> 업무에 대해 더 이야기해보자면 보통 LLMOps팀은 개발자와 도메인 전문가 두 직군의 사람이 협업을 하는 형태로 일을 하게 된다. <ul ><li>도메인 전문가 (프롬프트 엔지니어): 프롬프트를 바꿔가며 최적화를 수행하는 역할하는데 결국은 테스트 데이터를 만들어 벡터 DB 등의 검색 품질을 평가하고 최종적으로 RAG 시스템의 품질을 평가해야 한다. 이 과정에서 개발자와 밀접한 협업을 하게 된다.</li><li>개발자 (RAG 시스템 개발자): 벡터 DB을 주기적으로 빌딩하고 검색을 수행하며 LLM을 API로 통해 관리(실패시 재시도하거나 다른 LLM 시도, 비용 관리 등등 운영적인 부분이 중요)하며 전체적인 아키덱처를 잡되 프롬프트와 관련된 부분이나 검색 최적화와 관계된 부분에 있어서 앞서 도메인 전문가와 긴밀하게 일을 하게 된다.</li></ul> 개발자 같은 경우 다양한 파이프라인을 만들어야 하는데 하나는 벡터 DB 등의 데이터베이스를 빌딩하는데 필요한 데이터 소스를 긁어오는 ETL 파이프라인과 이렇게 쌓인 데이터들로부터 최종 데이터를 만들고 이를 벡터 DB 등으로 로딩하는 ELT와 Reverse ETL 파이프라인등을 만들어야 하는데 여기서 바로 데이터 엔지니어링 스킬이 필요하다. 다른 파이프라인은 사용자 질의로부터 시작해서 최종적으로 사용자에게 응답을 리턴하는 런타임 파이프라인이며 여기에는 벡터 DB 질의와 LLM 질의 등이 포함되며 비용과 응답 시간 등등 관리해야할 항목이 많다. LLMOps팀의 개발은 여러 사이클을 반복하는 형태로 이뤄지게 되는데 보통 아래와 같은 스텝을 필요로 한다. <ol ><li>LLM 서비스 기획</li><li>개발<ol ><li>프롬프트 시스템 개발 (도메인 전문가)</li><li>RAG 파이프라인 개발 (개발자). 여기에는 앞에 이야기한 데이터 파이프라인의 개발도 포함된다.</li></ol></li><li>평가: 오프라인 테스트셋으로 검색과 최종 결과물 평가 두 종류를 가질 수 있다면 최적이다</li><li>스테이징 시스템 배포 후 다시 평가<ol ><li>이 때는 온라인 테스트도 수행</li><li>전체적인 응답속도 평가도 중요</li></ol></li><li>만족할 만한 결과가 나올 때까지 2-4를 반복한다.</li><li>최종 배포 후 모니터링 (이때 비용 모니터링도 중요)</li></ol> LLMOps팀이 궁극적으로 목표로 삼아야 하는 시스템은 도메인 전문가가 개발자와 아주 밀접한 의사소통 없이 셀프 서비스 형태로 원하는 LLM 기반 서비스를 만들 수 있는 No Code 혹은 Low Code 프레임웍을 만드는 것이다. 아직은 이 방향으로 뚜렷한 위너는 안 보이는데 곧 나오지 않을까 싶다. 혹시라도 알고 있는 서비스나 툴이 있다면 댓글 부탁! 다음 글에서는 데이터 웨어하우스에 관해서 프로덕션 데이터베이스와 비교해가며 더 설명해보고자 한다.

데이터 이야기 #9: LLMOps 엔지니어

Explore the top 10 web development trends for 2025. Gain valuable insights into the future of web design, technology, and user experience.

Top 10 Web Development Trends to Watch in 2025 - Tech Guide

생성형AI와 LLM이 핫트렌드인 현재이지만, 여전히 우리는 쇼핑이나 항공권 티켓팅, 블로그, SNS를 웹으로 접근하고 있습니다. 따라서 전략적 우위를 확보하기 위해서는 웹 개발 최신 트렌드를 이해하고 이에 적응하는 것이 무엇보다 중요합니다. 이와 관련하여 2025년 웹개발 트렌드를 함께 살펴보시죠!

🧲 맞춤형 비주얼(Customised Visuals)
 * 브랜드 아이덴티티를 반영하여 특별히 디자인된 일반적인 스톡 이미지에서 맞춤형 레이아웃과 이미지로 전환 필요
 * 사용자들은 창의적인 그래픽과 아이콘을 일관된 색상으로 조합하여 더욱 매력적인 경험을 제공하는 웹사이트를 기억하는 경향
 * 맞춤형 비주얼에 투자함으로써 온라인 시장에서 차별화 및 탐색 기능을 개선하고 사용자의 콘텐츠 접근성을 높일 수 있음
   
   
🧲 모바일 우선 디자인(Mobile-First Design)
 * 전 세계 웹 트래픽의 50% 이상이 모바일 디바이스에서 발생
 * 모바일 응답성을 우선시하는 직관적인 웹사이트는 사용자 참여도와 리텐션 향상 유도
 * 모바일에 맞게 작은 화면과 빠른 로딩 시간에 완벽하게 최적화 필요
   
   
🧲 다크 모드(Dark Mode)
 * 사용자가 기존의 밝은 색상의 배경에서 어두운 테마로 전환할 수 있는 다크 모드는 최신 웹 디자인의 필수 요소
 * 다크 모드의 인기는 미적 매력과 함께 저조도 환경에서 눈의 피로를 줄이고 OLED 화면의 배터리 수명을 절약하는 등의 이점
 * 다크 모드는 생생한 색상 및 이미지와 잘 대비되는 세련되고 현대적인 외관을 제공함으로써 사용자 경험을 향상시키고, 사용자 참여도를 높일 수 있음
   
   
🧲 AR/VR을 통한 몰입형 경험(Immersive Experiences with AR/VR)
 * 증강 현실과 가상 현실이 웹 개발에 통합되면서 2025년까지 사용자 상호 작용이 혁신적으로 변화할 것으로 예상
 * AR/VR 기술은 몰입도 높은 인터랙티브 경험을 제공하여 사용자를 더욱 깊이 참여시킴
   * 예) 소매업체는 가상 의류 시착 서비스를 제공하거나 고객이 구매 전에 제품의 3D 모델을 미리 볼 수 있어 보다 효과적임
   * 예) 부동산, 이커머스, 관광과 같은 산업에서는 브라우저를 통해 직접 실물과 같은 경험을 제공하는 데 AR과 VR이 중요한 역할
     
     
🧲 싱글 페이지 애플리케이션(Single Page Applications)
 * 빠른 로딩 시간과 간소화된 브라우징 경험 인기
 * 기존 웹사이트와 달리 SPA는 전체 페이지를 다시 로드할 필요 없이 단일 HTML 페이지를 로드하고 콘텐츠를 동적으로 업데이트
 * 빠르고 끊김 없는 브라우징 경험을 제공을 통해 방문자 유지 필수

🧲 혁신 기술과의 통합(Integration of Emerging Technologies)
 * 인공지능, 머신러닝, 블록체인과 같은 새로운 기술은 2025년에도 웹 개발을 계속해서 재편
 * 인공지능과 머신러닝은 각 사용자에게 개인화된 경험을 제공하는 더 스마트하고 직관적인 웹사이트를 만드는 데 사용
   * 예)AI 기반 챗봇은 실시간 지원 서비스 제공
 * 블록체인 기술 또한 웹 개발에 더욱 통합되어 보안, 투명성, 신뢰성을 강화

🧲 프로그레시브 웹 앱(Progressive Web Apps)
 * 웹 액세스의 편리함과 네이티브 앱의 기능을 결합하여 웹과 모바일 앱의 장점을 모두 제공
 * PWA는 브라우저를 통해 액세스할 수 있지만 모바일 앱처럼 작동하여 오프라인 기능을 제공
 * 모든 디바이스에서 원활하게 작동하는 PWA는 전용 앱을 개발하지 않고도 모바일 참여도를 향상시키고자 하는 경우에 이상적임
   
   
🧲 보안 강화(Enhanced Security)
 * 웹사이트는 다단계 인증, 암호화, 보안 프레임워크 등 더욱 강력한 보안 프로토콜을 구현하여 민감한 데이터를 보호하고 사용자 개인정보 보호 필요
 * 보안 위협이 진화함에 따라 웹사이트에 사전 예방적 보안 조치를 도입하여 취약점을 사전에 방지하는 것이 중요

🧲 마이크로 인터랙션(Micro Interactions)
 * 웹사이트를 통해 사용자를 안내하고 사용자 참여를 향상시키는 미묘한 디자인 요소
   * 예)애니메이션, 호버 효과, 버튼 누르기, 작은 피드백 표시기 등
 * 마이크로 인터랙션이 더욱 발전하여 전반적인 사용자 경험을 향상시키는 부드러운 전환과 동적 요소 제공
   
   
🧲 음성 검색
 * Siri, Alexa, Google Assistant와 같은 음성 비서를 사용하는 사용자가 증가함에 따라 음성 검색의 인기는 계속 높아짐
 * 웹사이트는 자연어 처리에 집중하고 음성 검색 친화적인 SEO를 구현하여 음성 검색을 통해 콘텐츠를 쉽게 찾을 수 있도록
 * 음성 검색을 통해 사용자는 타이핑 없이도 빠르고 효율적으로 정보를 찾을 수 있으므로 이러한 트렌드에 적응하면 경쟁 우위 제공
   
   

 * source: https://www.techguide.com.au/news/internet-news/top-10-web-development-trends-to-watch-in-2025/

생성형AI와 LLM이 핫트렌드인 현재이지만, 여전히 우리는 쇼핑이나 항공권 티켓팅, 블로그, SNS를 웹으로 접근하고 있습니다. 따라서 전략적 우위를 확보하기 위해서는 웹 개발 최신 트렌드를 이해하고 이에 적응하는 것이 무엇보다 중요합니다. 이와 관련하여 2025년 웹개발 트렌드를 함께 살펴보시죠! 🧲 맞춤형 비주얼(Customised Visuals)<ul ><li>브랜드 아이덴티티를 반영하여 특별히 디자인된 일반적인 스톡 이미지에서 맞춤형 레이아웃과 이미지로 전환 필요</li><li>사용자들은 창의적인 그래픽과 아이콘을 일관된 색상으로 조합하여 더욱 매력적인 경험을 제공하는 웹사이트를 기억하는 경향</li><li>맞춤형 비주얼에 투자함으로써 온라인 시장에서 차별화 및 탐색 기능을 개선하고 사용자의 콘텐츠 접근성을 높일 수 있음 </li></ul>🧲 모바일 우선 디자인(Mobile-First Design)<ul ><li>전 세계 웹 트래픽의 50% 이상이 모바일 디바이스에서 발생</li><li>모바일 응답성을 우선시하는 직관적인 웹사이트는 사용자 참여도와 리텐션 향상 유도</li><li>모바일에 맞게 작은 화면과 빠른 로딩 시간에 완벽하게 최적화 필요 </li></ul>🧲 다크 모드(Dark Mode)<ul ><li>사용자가 기존의 밝은 색상의 배경에서 어두운 테마로 전환할 수 있는 다크 모드는 최신 웹 디자인의 필수 요소</li><li>다크 모드의 인기는 미적 매력과 함께 저조도 환경에서 눈의 피로를 줄이고 OLED 화면의 배터리 수명을 절약하는 등의 이점</li><li>다크 모드는 생생한 색상 및 이미지와 잘 대비되는 세련되고 현대적인 외관을 제공함으로써 사용자 경험을 향상시키고, 사용자 참여도를 높일 수 있음 </li></ul>🧲 AR/VR을 통한 몰입형 경험(Immersive Experiences with AR/VR)<ul ><li>증강 현실과 가상 현실이 웹 개발에 통합되면서 2025년까지 사용자 상호 작용이 혁신적으로 변화할 것으로 예상</li><li>AR/VR 기술은 몰입도 높은 인터랙티브 경험을 제공하여 사용자를 더욱 깊이 참여시킴<ul ><li>예) 소매업체는 가상 의류 시착 서비스를 제공하거나 고객이 구매 전에 제품의 3D 모델을 미리 볼 수 있어 보다 효과적임</li><li>예) 부동산, 이커머스, 관광과 같은 산업에서는 브라우저를 통해 직접 실물과 같은 경험을 제공하는 데 AR과 VR이 중요한 역할 </li></ul></li></ul>🧲 싱글 페이지 애플리케이션(Single Page Applications)<ul ><li>빠른 로딩 시간과 간소화된 브라우징 경험 인기</li><li>기존 웹사이트와 달리 SPA는 전체 페이지를 다시 로드할 필요 없이 단일 HTML 페이지를 로드하고 콘텐츠를 동적으로 업데이트</li><li>빠르고 끊김 없는 브라우징 경험을 제공을 통해 방문자 유지 필수</li></ul> 🧲 혁신 기술과의 통합(Integration of Emerging Technologies)<ul ><li>인공지능, 머신러닝, 블록체인과 같은 새로운 기술은 2025년에도 웹 개발을 계속해서 재편</li><li>인공지능과 머신러닝은 각 사용자에게 개인화된 경험을 제공하는 더 스마트하고 직관적인 웹사이트를 만드는 데 사용<ul ><li>예)AI 기반 챗봇은 실시간 지원 서비스 제공</li></ul></li><li>블록체인 기술 또한 웹 개발에 더욱 통합되어 보안, 투명성, 신뢰성을 강화</li></ul> 🧲 프로그레시브 웹 앱(Progressive Web Apps)<ul ><li>웹 액세스의 편리함과 네이티브 앱의 기능을 결합하여 웹과 모바일 앱의 장점을 모두 제공</li><li>PWA는 브라우저를 통해 액세스할 수 있지만 모바일 앱처럼 작동하여 오프라인 기능을 제공</li><li>모든 디바이스에서 원활하게 작동하는 PWA는 전용 앱을 개발하지 않고도 모바일 참여도를 향상시키고자 하는 경우에 이상적임 </li></ul>🧲 보안 강화(Enhanced Security)<ul ><li>웹사이트는 다단계 인증, 암호화, 보안 프레임워크 등 더욱 강력한 보안 프로토콜을 구현하여 민감한 데이터를 보호하고 사용자 개인정보 보호 필요</li><li>보안 위협이 진화함에 따라 웹사이트에 사전 예방적 보안 조치를 도입하여 취약점을 사전에 방지하는 것이 중요</li></ul> 🧲 마이크로 인터랙션(Micro Interactions)<ul ><li>웹사이트를 통해 사용자를 안내하고 사용자 참여를 향상시키는 미묘한 디자인 요소<ul ><li>예)애니메이션, 호버 효과, 버튼 누르기, 작은 피드백 표시기 등</li></ul></li><li>마이크로 인터랙션이 더욱 발전하여 전반적인 사용자 경험을 향상시키는 부드러운 전환과 동적 요소 제공 </li></ul>🧲 음성 검색<ul ><li>Siri, Alexa, Google Assistant와 같은 음성 비서를 사용하는 사용자가 증가함에 따라 음성 검색의 인기는 계속 높아짐</li><li>웹사이트는 자연어 처리에 집중하고 음성 검색 친화적인 SEO를 구현하여 음성 검색을 통해 콘텐츠를 쉽게 찾을 수 있도록</li><li>음성 검색을 통해 사용자는 타이핑 없이도 빠르고 효율적으로 정보를 찾을 수 있으므로 이러한 트렌드에 적응하면 경쟁 우위 제공 </li></ul> <ul ><li>source: https://www.techguide.com.au/news/internet-news/top-10-web-development-trends-to-watch-in-2025/</li></ul>

Tech Guide

[TechGuide]2025년에 주목해야 할 10가지 웹 개발 트렌드

”프로그램의 구조는 그것을 만드는 조직의 구조를 반영한다“는 법칙이죠. 우리가 만드는 제품이 조직의 구조에 영향을 받는다는 의미에요.

저는 이 법칙을 온보딩에 활용해요. 낯선 코드에 기여해야 할 때 바로 코드를 보는 게 아니라 코드를 작성한 팀을 먼저 보는 거죠.

이렇게 하면 누구에게 질문하면 되는지 알고 있으니, 코드에 대한 이해가 빨라져요. 생산성 향상은 당연하고요.

콘웨이의 법칙, 여러분은 어떻게 활용하실 건가요?

”프로그램의 구조는 그것을 만드는 조직의 구조를 반영한다“는 법칙이죠. 우리가 만드는 제품이 조직의 구조에 영향을 받는다는 의미에요. 저는 이 법칙을 온보딩에 활용해요. 낯선 코드에 기여해야 할 때 바로 코드를 보는 게 아니라 코드를 작성한 팀을 먼저 보는 거죠. 이렇게 하면 누구에게 질문하면 되는지 알고 있으니, 코드에 대한 이해가 빨라져요. 생산성 향상은 당연하고요. 콘웨이의 법칙, 여러분은 어떻게 활용하실 건가요?

콘웨이의 법칙을 아시나요?

재직자 대상 커리어 성장 코스, INNER CIRCLE

패스트캠퍼스 : INNER CIRCLE | 패스트캠퍼스

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다.

“앞으로 5년 후에도 개발자로 살아남을 수 있을까?”
“사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?”
“풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.”
“회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.”

저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만
이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다.

이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다.

바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다.

📌 실무 중심의 팀프로젝트 커리큘럼
단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다.

📌 실시간 온라인 진행 가능
100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.
또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다.

📌 동료들과 함께 성장
이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.
프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다.

📌 업계 상위 1% 리더와 검증된 동료
IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.
개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다.

📌 비용
450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.
또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다.

📌 창업 및 프로젝트 지원
팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다.

성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲

10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.
(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.)

🔗 신청 바로 가기: https://bit.ly/3U5CQu3 

추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면
대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요.

🎁 추천인 코드 입력 방법
 1. 신청 바로 가기(https://bit.ly/3U5CQu3)에서 신청하기 버튼 클릭
 2. 신청 폼 작성
 3. 마지막 인지 경로 항목 작성 시 Other 클릭
 4. 주관식 문항에 추천인 코드 [이양일] 작성

이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다. “앞으로 5년 후에도 개발자로 살아남을 수 있을까?” “사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?” “풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.” “회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.” 저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다. 이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다. 바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다. 📌 실무 중심의 팀프로젝트 커리큘럼단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다. 📌 실시간 온라인 진행 가능100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다. 📌 동료들과 함께 성장이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다. 📌 업계 상위 1% 리더와 검증된 동료IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다. 📌 비용450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다. 📌 창업 및 프로젝트 지원팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다. 성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲 10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.) 🔗 신청 바로 가기: https://bit.ly/3U5CQu3&nbsp; 추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요. 🎁 추천인 코드 입력 방법<ol ><li>신청 바로 가기(https://bit.ly/3U5CQu3)에서&nbsp;신청하기&nbsp;버튼 클릭</li><li>신청 폼 작성</li><li>마지막&nbsp;인지 경로&nbsp;항목 작성 시&nbsp;Other&nbsp;클릭</li><li>주관식 문항에 추천인 코드 [이양일] 작성</li></ol> 이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

엘리스트랙

📢 실무 프로젝트로 성장하고 싶은 주니어 개발자 분들에게

Festa에서 당신이 찾는 이벤트를 만나보세요.,Festa에서 당신이 찾는 이벤트를 만나보세요.

Open Source Conference (오쏘콘) | Festa!,Open Source Conference (오쏘콘) | Festa!

오픈소스 기여는 개발자에게 도전적이면서도 명예로운 일입니다. 이러한 오픈소스의 경험을 공유하는 행사, '오쏘콘'이 개최되네요. 이번 컨퍼런스에서는 라인플러스, 토스 등 국내 주요 기업들 혹은 개인 개발자의 오픈소스 기여 사례를 들을 수 있습니다

행사 정보:
 * 일시: 11월 16일 토요일, 오후 1시 ~ 6시
 * 장소: 인천 스타트업 파크 인스타1 6층 커넥트홀

오픈소스 생태계에 대한 이해를 넓히고 관심 있으신 분들에게 유익한 시간이 될 것 같습니다.

https://festa.io/events/6160

오픈소스 기여는 개발자에게 도전적이면서도 명예로운 일입니다. 이러한 오픈소스의 경험을 공유하는 행사, '오쏘콘'이 개최되네요. 이번 컨퍼런스에서는 라인플러스, 토스 등 국내 주요 기업들 혹은 개인 개발자의 오픈소스 기여 사례를 들을 수 있습니다 행사 정보:<ul ><li>일시: 11월 16일 토요일, 오후 1시 ~ 6시</li><li>장소: 인천 스타트업 파크 인스타1 6층 커넥트홀</li></ul> 오픈소스 생태계에 대한 이해를 넓히고 관심 있으신 분들에게 유익한 시간이 될 것 같습니다. https://festa.io/events/6160

festa.io

오쏘콘: 국내 기업들의 오픈소스 기여 이야기

이런 이미 티켓이 다 팔렸네요ㅠㅠ

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다. 

테스트 프로세스
테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다. 
테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다. 

테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.
테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다. 

테스트 프로세스: 세부 단계별 활동의 정의와 수행방법
테스트 계획
테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다. 

①테스트 수행 계획은 테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.
② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.
③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.
  ▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정 
  ▶ 테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정
  ▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등
고려
④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다. 
▶ 테스트 시작 기준 
Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.
  ▶ 테스트 완료 기준 
제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가
테스트 일정을 조율합니다.
품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단
결과 오픈 가능 여부를 전달합니다.

[테스트 완료 기준 예시]
1. 계획된 품질 보증 활동을 모두 완료
2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함
3. Major 이상 잔존 결함 없음
4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함
5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련
6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 & 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의

⑤ 테스트 수행 환경 구성 및 구현
테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다. 테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다. 

[테스트 환경 예시]
▶ Dev : 개발 환경
▶ QA : QA 테스트 환경
▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)
▶ 각각의 환경과 연동된 테스트 빌드 

⑥ 테스트 수행 역할 선정
⑦ 테스트 단계별 산출물 정의
⑧ 계획된 테스트 전략을 바탕으로 QA Plan 작성 
QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다.

테스트 설계
테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다. 

테스트 케이스를 작성하기 위해 먼저 ①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다.

테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로 ②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다. 

테스트 케이스 작성이 완료되면 테스트 수행을 위한 ③테스트 데이터 및 테스트 도구를 준비합니다.  기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다.

테스트 구현과 실행
①테스트 구현은 선별한 테스트 케이스에 맞게 자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고 코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.
②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다. 

테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다. 등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다.

테스트 수행이 완료되면 ④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다.

테스트 완료 및 평가
계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여 ①테스트 최종 결과 보고서를 작성합니다. 제품의 출시 가능 여부는 테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다. 

산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다. 첫째, 테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다. 둘째, 전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다. 

테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지 ②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다.

마지막으로 ③완료된 품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다. 테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의 참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는 테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다.

테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem 활동을 진행합니다. 회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은 기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

폭포수모델의 SW 프로세스 글에서 간략히 다루었던 협업 프로세스에서의 테스트 활동에 대해 좀 더 자세히 살펴보겠습니다.&nbsp; 테스트 프로세스테스트 프로세스는, 개발된 소프트웨어의 품질 기준을 만족하기 위한 테스트 수행 절차로 소프트웨어 테스트를 효율적으로 실행하기 위한 테스트 계획과 설계, 조직의 역할과 책임, 필요한 작업 및 절차, 산출물 등 테스트 단계별 활동을 정의한 것입니다.&nbsp;테스트 프로세스를 통해 소프트웨어의 품질 기준과 테스트 범위를 측정하고 개발 구현된 소프트웨어와 요구 사항과의 차이를 판별하며 테스트 진행과정을 관리하기 위해 각 테스트 단계의 활동을 정의하는 것이 목적입니다.&nbsp; 테스트 프로세스는 테스트 계획에 따라 테스트를 수행하기 위한 세부 활동과 테스트 조직의 품질 목표와 기준을 바탕으로 테스트 수행을 모니터링하고 제어하며 테스트 종료 활동을 포함합니다.테스트 수행을 위한 세부 활동은 테스트 설계 및 구현, 테스트 환경 구축, 테스트 실행, 검출된 결함 등록 및 관리, 테스트 산출물(설계서, 테스트 케이스, 준비·진행·완료 보고서 등) 작성 및 관리, 종료 활동으로 구성됩니다.&nbsp; 테스트 프로세스:&nbsp;세부 단계별 활동의 정의와 수행방법테스트 계획테스트 계획은 소프트웨어의 품질 목표를 달성하기 위해 검증에 필요한 활동을 정의하는 단계로 전체 테스트 범위를 포함한 종합적인 계획과 폭포수 모델 단계별 테스트 수행 계획 및 테스트 유형별(기능성, 유지보수성, 사용성 등) 수행 계획으로 설계합니다.&nbsp; ①테스트 수행 계획은&nbsp;테스트 대상 시스템 및 비즈니스 리스크를 식별하고 테스트 주요 요소를 분류하여 테스트 전략을 수립합니다. 수행 계획과 전략 설계 시 프로젝트 계획서와 요구사항을 분석하여 테스트 범위, 테스트 목적, 리스크 분석, 담당자, 일정, 투입 비용, 제약 사항 등을 고려합니다.② 프로젝트 계획서/요구사항을 분석하여 테스트 목적 및 테스트 범위 설정, 테스트 일정을 계획합니다.③ 개발 생명주기 각 단계에 적합한 테스트 유형을 선정하고 테스트 단계별 수행방법을 정의합니다.&nbsp;&nbsp;▶ 개발 생명주기 : waterfall, agile에 따라 테스트 유형과 방법 정의 및 선정&nbsp;&nbsp;&nbsp;▶&nbsp;테스트 유형 : 기능 테스트, 성능 테스트, API 테스트, 네트워크 테스트 등 선정&nbsp;&nbsp;▶ 테스트 방법 선택시 고려사항 : 시스템 복잡도, 중요도, 조직/개발 성숙도, 요구사항, 일정 등 고려④ 테스트 단계별 품질 목표 기준을 선정하고 품질 지표 관리 방안을 정의합니다.&nbsp; ▶ 테스트&nbsp;시작 기준&nbsp; Fail 시 테스트 중단. 수정 후 다음 시작 가능 시기 조율.&nbsp; ▶ 테스트&nbsp;완료 기준&nbsp; 제품 출시를 위한 오픈 가능한 품질 목표 기준을 설정하여 Fail시 출시 일정을 지연하거나 추가 테스트 일정을 조율합니다. 품질 목표를 달성하여 제품 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 QA 판단 결과 오픈 가능 여부를 전달합니다. [테스트 완료 기준 예시] 1. 계획된 품질 보증 활동을 모두 완료2. 위험도가 “중” 이상인 리스크가 없거나 대응 방안이 마련되어야 함3. Major 이상 잔존 결함 없음4. 잔존하는 이슈 / 리스크가 있을 경우 대응 방안이 준비되지 않았다면 테스트 종료 불가함5. 보안 검수 및 성능 검수 결과 권고된 시정 사항이 조치 완료되거나 대응 방안 마련6. 테스트 종료가 불가한 경우 프로젝트 담당자가 모두 참여하여 제품의 품질 상태 확인 및 테스트 종료가 불가한 원인을 확인하여 제품 출시 여부를 결정하도록 함 &amp; 해결되어야 하는 문제에 대한 해결방안 마련 및 추가 일정 협의 ⑤ 테스트 수행 환경 구성 및 구현 테스트를 수행하기 위한 기본 데이터들을 정리하고 어떤 환경에서 테스트를 수행할 지 미리 준비하여 각 프로젝트 목적에 맞는 환경과 자원을 준비하고 문서화합니다.&nbsp;테스트를 위한 데이터의 예로는 테스트 계정, 계정에 따른 권한, 네트워크, 제품 출시 타겟 국가에 따른 조건, 테스트 서버(API, 클라이언트, DB 등) 설정 등이 있습니다.&nbsp; [테스트 환경 예시]▶ Dev : 개발 환경▶ QA : QA 테스트 환경▶ Staging : 실 환경을 복제한 운영 테스트용 환경 (라이브와 동일한 서버/DB 백업)▶ 각각의 환경과 연동된 테스트 빌드&nbsp; ⑥ 테스트 수행 역할 선정⑦ 테스트 단계별 산출물 정의⑧&nbsp;계획된 테스트 전략을 바탕으로 QA Plan 작성&nbsp;QA Plan은 테스트를 하기위해 필요한 자원들을 요약한 것으로 정해진 프로세스대로 업무를 수행하기 위한 청사진 역할을 하며 계획된 방향으로 테스트가 진행될 수 있도록 가이드 역할을 합니다. 테스트 설계테스트 목표와 목적을 테스트 케이스로 변환하는 단계입니다. 테스트 설계는 고객 요구사항 명세서, 기획 문서, 개발 설계서와 시스템 아키텍처 등의 산출물과 리스크 분석 결과를 기반으로 테스트 대상을 식별하고 테스트 범위를 정의하며 테스트 절차에 따른 수행 명세서(테스트 케이스 또는 테스트 시나리오)를 작성하는 활동입니다.&nbsp; 테스트 케이스를 작성하기 위해 먼저&nbsp;①테스트 대상을 분석하고 범위를 선정합니다. 테스트 베이시스를 분석하여 테스트 대상 기능을 선정하고 리스크 분석을 통해 테스트 우선순위를 선정하며 테스트 전략과 총괄 테스트 수행 계획서를 바탕으로 테스트 범위를 결정합니다. 이를 바탕으로 자동화, API, 보안, 성능 등 기술 검증이 필요한 범위를 도출합니다. 테스트 대상 분석 및 테스트 범위가 식별되면 테스트 베이시스를 기반으로&nbsp;②테스트 케이스 또는 테스트 시나리오를 작성합니다. 테스트 케이스 작성 시 명세서와 요구사항에 맞춰 테스트 성공과 실패 기준을 정의하고 테스트 설계 기법을 적용하여 테스트 케이스를 작성합니다. 효율적이고 효과적인 테스트 실행을 위하여 기능 연관성과 유저 흐름을 고려하여 테스트 케이스의 순서를 구성하도록 합니다. 또한 기술 검증에 필요한 테스트 스크립트 작성을 위해 테스트 케이스를 선별합니다. 테스트 케이스 작성이 완료되면 테스트 조직 내부 또는 프로젝트 관련자와 함께 리뷰를 진행하여 작성된 내용을 검토합니다.&nbsp; 테스트 케이스 작성이 완료되면 테스트 수행을 위한&nbsp;③테스트 데이터 및 테스트 도구를 준비합니다. &nbsp;기능 및 기술 검증용 테스트 케이스를 실행하기 위한 데이터와 테스트 대상을 설정하는 데 필요한 데이터, 테스트 케이스에서 요구하는 조건과 상태를 충족하게 만드는 데이터를 준비하고 기술 검증 테스트를 위한 도구(예: Appium, Postman, Jmeter 등)와 결함 보고용 관리 도구(예: JIRA, Redmine 등)를 준비합니다. 테스트 구현과 실행①테스트 구현은&nbsp;선별한 테스트 케이스에 맞게&nbsp;자동화, 성능, API 등 기술 검증용 테스트 코드를 작성하고&nbsp;코드를 실행하여 성공·실패 검증 포인트를 설정하고 무결성을 검증하는 활동입니다.②테스트 실행은 작성한 테스트 케이스를 바탕으로 테스트 활동을 수행하는 단계입니다. 테스트 케이스를 수행하기 전 프로젝트 정책에 따라 수행해야 하는 테스트 환경을 확인합니다. 설정된 환경에서 테스트 케이스에 기술된 단계와 테스트 데이터를 확인하고 해당 기능이 수행 절차에 따라 기대 결과를 만족하는지 실행 결과를 기록하며 테스트를 수행합니다.&nbsp; 테스트 실행 중 기대 결과에 만족하지 못해 실패 처리된 결과는 분석을 통해 테스터의 단순 실수인지 시스템 결함인지 판단하여 수정이 필요한 결함으로 판명되거나 테스트 케이스에 기술되어 있지 않지만 유효한 버그를 발견한 경우 버그 관리 시스템에 ③결함을 기록하고 프로젝트 관계자들에게 이슈를 보고합니다.&nbsp;등록된 버그에 해당되는 테스트 케이스에는 버그의 ID(식별자)를 기록하여 버그 진행 상태를 체크하고 업데이트합니다. 테스트 수행이 완료되면&nbsp;④테스트 결과를 기록하고 검토합니다. 테스트 케이스 실행 결과 및 보고된 결함의 조치 내역을 취합하여 품질 상태에 대한 기록을 작성합니다. 작성된 기록을 확인하여 테스트 진행 상황, 제품 품질 상태, 테스트 활동 품질, 프로젝트 진행 중 논의가 필요한 주제, 주요 결함 내용을 파악하고 테스트 수행에 걸림돌이 되는 부분을 제거하고 계획한 품질 검증 활동을 일정에 맞춰 완료할 수 있도록 필요한 조치를 지원합니다. 테스트 완료 및 평가계획한 품질 보증 활동을 완료하면 테스트 완료 조건과 최종 테스트 수행 결과를 비교하여 출시가 가능한 상태인지 판단하여&nbsp;①테스트 최종 결과 보고서를 작성합니다.&nbsp;제품의 출시 가능 여부는&nbsp;테스트 종료 보고서QA Sign-off로 전달됩니다. 이 보고서를 통해 품질 목표를 달성했는지, 출시가 가능한 상태인지 공유하고 최종 품질 상태에 대한 테스트 담당자의 판단 결과를 전달합니다.&nbsp; 산출물 구성은 테스트 수행 단계별 품질 현황 결과 보고서와 유사하나 내용상 두가지 차이가 있습니다.&nbsp;첫째,&nbsp;테스트 담당자의 테스트 완료 평가와 제품의 출시 가능 여부에 대한 최종 의견을 전달합니다. 출시 불가한 상황일 경우 원인을 공유하고 문제 해결 방안과 출시 여부 결정을 위한 관련자 협의 미팅(오픈 적합성 회의)을 요청합니다.&nbsp;둘째,&nbsp;전체 테스트 기간에 수행된 테스트의 최종 상태를 공유합니다. 총 테스트 케이스 수행 결과, 계획 대비 차이점, 잔존 결함과 리스크, 합의된 논 이슈known-issue를 공유하고 전체 품질 검증 활동 진행 결과를 작성합니다.&nbsp; 테스트를 종료하고 제품의 출시가 결정되면 오픈 예정일에 제품이 고객에게 공개됩니다. 출시 후 테스터는 라이브 환경에서 제품의 주요 기능과 작동에 문제가 발생하지 않는지, 고객의 불편사항과 결함에 대한 피드백이 전달되지 않는지&nbsp;②모니터링을 수행합니다. 모니터링 후 특별한 이슈나 특이사항이 발생하지 않으면 모니터링 보고서를 공유하고 프로젝트를 최종 마무리합니다. 이후 유지보수 담당자에게 제품 및 품질 기록을 이관함으로 테스트 프로세스가 종료됩니다. 마지막으로 ③완료된&nbsp;품질 검증 활동과 프로세스를 평가하고 개선사항을 제안하는 미팅을 진행합니다.&nbsp;테스트 활동에 대한 평가는 완료된 프로젝트에서 수행한 테스트 활동 데이터를 수집하고 각 테스트 단계와 테스트 종류별로 결과를 분석하여 테스트 활동에 대한 객관적인 평가를 기록합니다. 해당 미팅의&nbsp;참여 대상은 프로젝트에 참여한 테스트 담당자(QA, TL, SET, TE) 및 테스트 조직 전체이며 미팅의 주요 의제는&nbsp;테스트 수행 시 발생한 문제점(휴먼 이슈, 테스트 산출물 이슈 등), 수행 절차상 개선사항, 특이 결함 케이스, 프로세스 개선 사항을 공유하여 테스트 지식과 경험을 축적하고 문제점을 개선하는 활동을 수행합니다. 테스트 평가가 완료되면 각 프로젝트 관련자들과 모여 ④프로젝트 회고Post-mortem&nbsp;활동을 진행합니다.&nbsp;회고를 진행하는 목적은 각 직무 담당자의 잘잘못을 가리고 찾아내는 것에 집중하는 것보다 모두가 서로에게 안전하게 이야기할 수 있는 환경을 만들고 회고라는 마침표를 찍음으로 새로운 일을 준비할 수 있도록 하기 위함입니다. 회고의 참여 대상은&nbsp;기획, 개발, 테스터, 마케팅 등 프로젝트 전체 인원이며 미팅의 주요 회고 내용은 프로젝트에서 발생한 잘한 일(Keep), 잘못한 일(Problem), 개선 활동(Try)을 복기하는 것입니다. 잘한 일은 앞으로 더 잘할 수 있도록 프로세스로 정립하고 잘못된 일은 재발을 방지하기 위한 대책을 수립하거나 시스템 또는 프로세스의 개선 방안을 도출하여 이전보다 나은 다음을 준비합니다.

[SW프로세스 III]협업 프로세스 내 테스트 활동

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로 MongoTemplate와 MongoRepository 입니다. 이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다. MongoRepository와 MongoTemplate[MongoRepository] MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와..

Spring Boot의 MongoDB 연동: MongoTemplate vs MongoRepository

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다.

바로 MongoTemplate와 MongoRepository 입니다.
 
이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.
 
[MongoRepository]
MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.
 
장점
 * 기본적인 CRUD 작업을 자동으로 처리
 * 코드가 매우 간결하고 유지보수가 쉬움
 * 메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)
단점
 * 복잡한 쿼리 작업에서는 제한적
 * 커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음
 
[MongoTemplate]
MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.
 
장점
 * 복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능
 * MongoDB와의 깊이 있는 상호작용에 적합
 * 더 세밀한 데이터 처리와 제어가 가능
단점
 * 기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐
 * 레파지토리 패턴보다 다소 비효율적일 수 있음
 
[MongoRepository 사용 예시]

Product 엔티티
@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}

ProductRepository 인터페이스
public interface ProductRepository extends MongoRepository<Product, String> {
 List<Product> findByCategory(String category);
}

MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.
 
CRUD 작업 사용 예시
@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List<Product> getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}

이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.
 
[MongoTemplate 사용 예시]
이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.
 
MongoTemplate으로 복잡한 쿼리 작성
@Autowired
private MongoTemplate mongoTemplate;

public List<Product> findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}

위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.
 
CRUD 작업 처리 
public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}

MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.
 
[어떤 것을 선택해야 할까?]
MongoRepository를 사용해야 할 때:
 * 기본적인 CRUD 작업을 빠르게 처리해야 할 때
 * 코드의 간결함과 유지보수의 용이함이 중요할 때
MongoTemplate을 사용해야 할 때:
 * 복잡한 쿼리나 트랜잭션 처리가 필요한 경우
 * 데이터베이스와의 더 세밀한 상호작용이 필요할 때
 
[결론]
MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.
 
반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.
 
결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

MongoDB는 NoSQL 데이터베이스로, 그 유연성 덕분에 Spring Boot와 자주 함께 사용됩니다. Spring Boot에서는 Spring Data MongoDB를 통해 MongoDB 연동을 쉽게 할 수 있습니다. Spring Data MongoDB는 두 가지 주요 방식을 제공합니다. 바로&nbsp;MongoTemplate와&nbsp;MongoRepository 입니다.&nbsp;이번 포스팅에서는 이 두 가지 방법을 비교하고, 어떤 상황에서 각각을 사용하는 것이 좋은지 살펴보겠습니다.&nbsp;[MongoRepository]MongoRepository는 레파지토리 패턴을 기반으로 한 인터페이스입니다. 기본적인 CRUD 메서드를 자동으로 제공합니다. Spring Data JPA와 비슷하게 작동하며, MongoDB 데이터를 처리하는 데 매우 간단한 방법을 제공합니다.&nbsp;장점<ul ><li>기본적인 CRUD 작업을 자동으로 처리</li><li>코드가 매우 간결하고 유지보수가 쉬움</li><li>메서드 이름만으로 커스텀 쿼리를 작성할 수 있음 (ex. findByCategory)</li></ul>단점<ul ><li>복잡한 쿼리 작업에서는 제한적</li><li>커스터마이징이 어렵고 고급 기능을 구현하기에 한계가 있음</li></ul>&nbsp;[MongoTemplate]MongoTemplate은 Spring의 템플릿 패턴을 사용한 MongoDB 연동 방식입니다. 더 복잡한 MongoDB 제어가 가능하며, 어려운 쿼리 작성에 적합합니다.&nbsp;장점<ul ><li>복잡한 쿼리나 커스텀 작업을 더 쉽게 수행 가능</li><li>MongoDB와의 깊이 있는 상호작용에 적합</li><li>더 세밀한 데이터 처리와 제어가 가능</li></ul>단점<ul ><li>기본적인 CRUD 작업도 코드로 직접 작성해야 하므로 코드가 다소 복잡해짐</li><li>레파지토리 패턴보다 다소 비효율적일 수 있음</li></ul>&nbsp;[MongoRepository 사용 예시] Product 엔티티<pre ><code class="language-java">@Document(collection = "products")
public class Product {
 @Id
 private String id;
 private String name;
 private String category;
}</code></pre>ProductRepository 인터페이스<pre ><code class="language-java">public interface ProductRepository extends MongoRepository&lt;Product, String&gt; {
 List&lt;Product&gt; findByCategory(String category);
}</code></pre>MongoRepository를 확장한 ProductRepository를 정의하였습니다. CRUD 메서드는 기본으로 제공되며, 커스텀으로 findByCategory 같은 메서드를 쉽게 추가할 수 있습니다.&nbsp;CRUD 작업 사용 예시<pre ><code class="language-java">@Autowired
private ProductRepository productRepository;

public void addProduct(Product product) {
 productRepository.save(product);
}

public List&lt;Product&gt; getProductsByCategory(String category) {
 return productRepository.findByCategory(category);
}</code></pre>이처럼 MongoRepository를 사용하면 간단한 CRUD 작업을 매우 직관적으로 처리할 수 있습니다.&nbsp;[MongoTemplate 사용 예시]이번에는 같은 Product 엔티티를 사용하여 MongoTemplate을 이용한 예제를 살펴보겠습니다.&nbsp;MongoTemplate으로 복잡한 쿼리 작성<pre ><code class="language-java">@Autowired
private MongoTemplate mongoTemplate;

public List&lt;Product&gt; findProductsByCategory(String category) {
 Query query = new Query();
 query.addCriteria(Criteria.where("category").is(category));
 return mongoTemplate.find(query, Product.class);
}</code></pre>위 코드에서는 MongoTemplate을 사용하여 MongoDB 쿼리를 직접 사용했습니다. Criteria와 Query 객체를 이용해 더 복잡한 쿼리나 고급 기능을 쉽게 구현할 수 있습니다.&nbsp;CRUD 작업 처리&nbsp;<pre ><code class="language-java">public void addProduct(Product product) {
 mongoTemplate.save(product);
}

public Product getProductById(String id) {
 return mongoTemplate.findById(id, Product.class);
}</code></pre>MongoTemplate을 사용하면 모든 작업을 수동으로 처리해야 하지만, 그만큼 더 세밀하게 제어할 수 있는 장점이 있습니다.&nbsp;[어떤 것을 선택해야 할까?]MongoRepository를 사용해야 할 때:<ul ><li>기본적인 CRUD 작업을 빠르게 처리해야 할 때</li><li>코드의 간결함과 유지보수의 용이함이 중요할 때</li></ul>MongoTemplate을 사용해야 할 때:<ul ><li>복잡한 쿼리나 트랜잭션 처리가 필요한 경우</li><li>데이터베이스와의 더 세밀한 상호작용이 필요할 때</li></ul>&nbsp;[결론]MongoDB와 Spring Boot의 연동에서 MongoRepository와 MongoTemplate은 각각 다른 용도에 맞춰 설계된 도구입니다. 저는 실제 프로젝트에서 bulk upsert 기능이 필요한 상황을 겪었는데, MongoRepository에는 해당 기능이 기본적으로 제공되지 않아, 더 유연한 MongoTemplate을 사용할 수밖에 없었습니다. 물론 upsert를 여러 번 호출하는 방법도 가능하지만, 이는 비효율적이므로 MongoTemplate을 통해 간단히 처리할 수 있었습니다.&nbsp;반면, 단순한 조회 작업에서는 MongoRepository를 사용했습니다. MongoTemplate보다 코드가 훨씬 깔끔하고 유지보수하기가 쉬웠기 때문입니다. 이처럼 MongoRepository는 기본적인 작업에 최적화되어 있고, MongoTemplate은 고급 작업에서 강력한 기능을 제공합니다.&nbsp;결국 중요한 것은 프로젝트의 요구사항에 맞춰 이 두 방식을 적절히 선택하거나 혼합하여 사용하는 것입니다. 각 도구가 제공하는 장점을 최대한 활용해, 프로젝트에 가장 적합한 솔루션을 찾는 것이 성공적인 MongoDB 연동의 핵심입니다.

덕토피아

MongoRepository vs MongoTemplate 차이와 활용

NEXTSTEP에서 개발자들을 위해 디자인된 강의를 수강해보세요.

글쓰기 워크숍

누구나 멋진 글을 쓰고 싶어 하지만, 시작도 전에 남들의 시선을 의식하며 주저하는 순간이 있습니다. 저 역시 그런 부담감에 종종 펜을 내려놓았던 경험이 있었습니다. 하지만, 제 글쓰기 습관과 경험을 근본적으로 변화시킨 방법이 있습니다.

바로 ‘저자 워크숍’ 입니다. 한 줄기 생각의 싹에서 출발해 동료들과 함께 그 생각을 글로 키워나가는 과정입니다. 이 과정을 통해 글쓰기 자체의 즐거움을 발견하게 되었고, 이를 통해 '요즘 개발자'라는 책을 출판할 수 있었습니다.

이런 경험을 더 깊이 있고 재미있게 만들어보고자, '저자 워크숍'을 핵심으로 한 글쓰기 워크숍을 준비했습니다.

이 워크숍은 4가지 큰 장점이 있습니다.

1️⃣ 글의 씨앗을 찾는 연습을 합니다.

모든 훌륭한 글은 하나의 생각에서 출발합니다. 이 워크숍에서는 그러한 생각의 싹을 찾아 문장으로 형성하고, 이를 풍부한 이야기로 발전시키는 연습을 합니다. 정원사가 씨앗에서 거대한 나무를 키워내듯, 나의 경험을 씨앗으로 글로 자라나게 만들어보세요. 나에게 의미 있던 생각과 감정이 글의 초안으로 자연스럽게 펼쳐질 것입니다.

2️⃣ 저자워크숍으로 글을 더 자라나게 만듭니다.

저자 워크숍은 19세기 말 아이오와 대학에서 시작된 글쓰기 과정으로, 작가들이 자신의 작품을 개선하는 데 큰 도움이 되었습니다. 이 방법은 글이 커뮤니티의 피드백을 받으며 성장하도록 도와주며, 여러분의 글도 같은 방식으로 성장할 수 있습니다.

3️⃣ ChatGPT로 미리 독자와 만납니다.

ChatGPT와 같은 대규모 ‘언어’ 모델을 활용하여, 내 글의 디테일과 표현을 개선하고 예상 독자와의 소통을 경험할 수 있습니다. 글쓰기는 단지 글을 쓰는 행위에 그치지 않고, 독자와의 소통에서 진정한 의미를 찾습니다. GPT를 활용해 내 글이 어떻게 다른 사람들에게 영향을 미칠 수 있는지 경험해보세요.

4️⃣ 함께 글을 모아 이북으로 출간합니다.

워크숍의 마지막 단계로, 참가자들의 글을 모아 전자책으로 출간합니다. 이는 글쓰기를 통해 독자와의 연결을 더 깊게 하고, 실제 독자의 피드백을 통해 다음 작품에 대한 영감을 얻을 수 있는 기회입니다. 이런 과정을 통해 내 경험을 동료들과 공유하며 이북으로 출간하는 경험을 하고 싶으신 분이라면, 이 글쓰기 워크숍에서 함께해요~!

🔗 신청링크
https://edu.nextstep.camp/c/81psVr9U

📗 지난 기수가 출간한 이북
어른이들의 세발자전거(https://bookk.co.kr/bookStore/658febd6e571aee94d9b89e6)
이야기 자판기(https://bookk.co.kr/bookStore/667b6f2ea52b96ab870a0aa7)

누구나 멋진 글을 쓰고 싶어 하지만, 시작도 전에 남들의 시선을 의식하며 주저하는 순간이 있습니다. 저 역시 그런 부담감에 종종 펜을 내려놓았던 경험이 있었습니다. 하지만, 제 글쓰기 습관과 경험을 근본적으로 변화시킨 방법이 있습니다. 바로 ‘저자 워크숍’ 입니다. 한 줄기 생각의 싹에서 출발해 동료들과 함께 그 생각을 글로 키워나가는 과정입니다. 이 과정을 통해 글쓰기 자체의 즐거움을 발견하게 되었고, 이를 통해 '요즘 개발자'라는 책을 출판할 수 있었습니다. 이런 경험을 더 깊이 있고 재미있게 만들어보고자, '저자 워크숍'을 핵심으로 한 글쓰기 워크숍을 준비했습니다. 이 워크숍은 4가지 큰 장점이 있습니다. 1️⃣ 글의 씨앗을 찾는 연습을 합니다. 모든 훌륭한 글은 하나의 생각에서 출발합니다. 이 워크숍에서는 그러한 생각의 싹을 찾아 문장으로 형성하고, 이를 풍부한 이야기로 발전시키는 연습을 합니다. 정원사가 씨앗에서 거대한 나무를 키워내듯, 나의 경험을 씨앗으로 글로 자라나게 만들어보세요. 나에게 의미 있던 생각과 감정이 글의 초안으로 자연스럽게 펼쳐질 것입니다. 2️⃣&nbsp;저자워크숍으로 글을 더 자라나게 만듭니다. 저자 워크숍은 19세기 말 아이오와 대학에서 시작된 글쓰기 과정으로, 작가들이 자신의 작품을 개선하는 데 큰 도움이 되었습니다. 이 방법은 글이 커뮤니티의 피드백을 받으며 성장하도록 도와주며, 여러분의 글도 같은 방식으로 성장할 수 있습니다. 3️⃣ ChatGPT로 미리 독자와 만납니다. ChatGPT와 같은 대규모 ‘언어’ 모델을 활용하여, 내 글의 디테일과 표현을 개선하고 예상 독자와의 소통을 경험할 수 있습니다. 글쓰기는 단지 글을 쓰는 행위에 그치지 않고, 독자와의 소통에서 진정한 의미를 찾습니다. GPT를 활용해 내 글이 어떻게 다른 사람들에게 영향을 미칠 수 있는지 경험해보세요. 4️⃣ 함께 글을 모아 이북으로 출간합니다. 워크숍의 마지막 단계로, 참가자들의 글을 모아 전자책으로 출간합니다. 이는 글쓰기를 통해 독자와의 연결을 더 깊게 하고, 실제 독자의 피드백을 통해 다음 작품에 대한 영감을 얻을 수 있는 기회입니다. 이런 과정을 통해 내 경험을 동료들과 공유하며 이북으로 출간하는 경험을 하고 싶으신 분이라면, 이 글쓰기 워크숍에서 함께해요~! 🔗 신청링크https://edu.nextstep.camp/c/81psVr9U 📗 지난 기수가 출간한 이북어른이들의 세발자전거(https://bookk.co.kr/bookStore/658febd6e571aee94d9b89e6)이야기 자판기(https://bookk.co.kr/bookStore/667b6f2ea52b96ab870a0aa7)

edu.nextstep.camp

✍🏻 혹시 글쓰기가 두려우신가요?

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

일 잘하는 개발자는 어떤 개발자 일까요? 흔히 개발자를 평가할 때 코드의 품질이나 기술적 숙련도만을 중요시하는 경향이 있는데요. 토스에서는 '일 잘하는 개발자' 란 코드 작성 외에도 고객에게 실질적인 가치를 제공하는 것이 더 중요하게 생각한다고 합니다. 다음은 토스가 중요하게 여기는 개발자의 자질들입니다:

요구사항을 넘어서는 통찰력
일 잘하는 개발자는 단순히 요구사항을 그대로 구현하는 것에 그치지 않습니다. 대신, 요구사항 속에 숨겨진 진정한 목적을 파악하고, 때로는 구현 없이도 그 목적을 달성할 수 있는 창의적인 방법을 제안합니다. 이는 단순한 '구현'을 넘어선 '문제 해결'에 초점을 맞추는 것입니다.

효율성과 가치의 균형
항상 효율성을 고민합니다. 예를 들어, "이 기능은 이렇게 하면 개발 시간을 절반으로 줄일 수 있을 것 같습니다. 먼저 이 방식으로 시도해보고, 나중에 더 발전시켜 보는 건 어떨까요?"와 같은 제안을 통해 극적인 효율 개선으로 이어질 수 있습니다.

'메이커'로서의 개발자
토스에서는 개발자를 단순한 '엔지니어'가 아닌 '메이커'로 부릅니다. 이는 개발자가 서비스에 대한 깊은 이해를 바탕으로 용기 있게 의견을 내고, 이를 통해 자신과 동료의 시간을 절약하며 제품의 성공에 기여할 수 있습니다.

빠른 런칭과 사용자 피드백의 중요성
제품을 빨리 런칭하고 실제 사용자의 목소리를 듣는 것이 중요합니다. 내부에서 생각하는 사용자의 의견은 실제와 다를 수 있기 때문입니다. 기능을 짧고 빠르게 만들어 출시하는 것이 성공으로 가는 지름길일 수 있습니다.

그렇지만 위와같은 방식이 모든 조직과 제품에 보편적으로 적용되는 것은 아닙니다. 조직의 특성과 제품의 발전 단계에 따라 '일 잘하는 개발자' 정의와 역할은 달라질 수 있습니다. 기능 중심 조직이고, 이미 완성도 높은 단계의 제품이라면 개발 전략과 우선순위가 달라질 수 있습니다.
이 관점은 주로 '사일로' 라는 목적 조직과 제품 초기 단계의 상황에 초점을 맞추고 있습니다.

https://www.youtube.com/watch?v=ZCg8kvtgcUg

일 잘하는 개발자는 어떤 개발자 일까요? 흔히 개발자를 평가할 때 코드의 품질이나 기술적 숙련도만을 중요시하는 경향이 있는데요. 토스에서는 '일 잘하는 개발자' 란 코드 작성 외에도 고객에게 실질적인 가치를 제공하는 것이 더 중요하게 생각한다고 합니다. 다음은 토스가 중요하게 여기는 개발자의 자질들입니다: 요구사항을 넘어서는 통찰력일 잘하는 개발자는 단순히 요구사항을 그대로 구현하는 것에 그치지 않습니다. 대신, 요구사항 속에 숨겨진 진정한 목적을 파악하고, 때로는 구현 없이도 그 목적을 달성할 수 있는 창의적인 방법을 제안합니다. 이는 단순한 '구현'을 넘어선 '문제 해결'에 초점을 맞추는 것입니다. 효율성과 가치의 균형항상 효율성을 고민합니다. 예를 들어, "이 기능은 이렇게 하면 개발 시간을 절반으로 줄일 수 있을 것 같습니다. 먼저 이 방식으로 시도해보고, 나중에 더 발전시켜 보는 건 어떨까요?"와 같은 제안을 통해 극적인 효율 개선으로 이어질 수 있습니다. '메이커'로서의 개발자토스에서는 개발자를 단순한 '엔지니어'가 아닌 '메이커'로 부릅니다. 이는 개발자가 서비스에 대한 깊은 이해를 바탕으로 용기 있게 의견을 내고, 이를 통해 자신과 동료의 시간을 절약하며 제품의 성공에 기여할 수 있습니다. 빠른 런칭과 사용자 피드백의 중요성제품을 빨리 런칭하고 실제 사용자의 목소리를 듣는 것이 중요합니다. 내부에서 생각하는 사용자의 의견은 실제와 다를 수 있기 때문입니다. 기능을 짧고 빠르게 만들어 출시하는 것이 성공으로 가는 지름길일 수 있습니다. 그렇지만 위와같은 방식이 모든 조직과 제품에 보편적으로 적용되는 것은 아닙니다. 조직의 특성과 제품의 발전 단계에 따라 '일 잘하는 개발자' 정의와 역할은 달라질 수 있습니다. 기능 중심 조직이고, 이미 완성도 높은 단계의 제품이라면 개발 전략과 우선순위가 달라질 수 있습니다.이 관점은 주로 '사일로' 라는 목적 조직과 제품 초기 단계의 상황에 초점을 맞추고 있습니다. https://www.youtube.com/watch?v=ZCg8kvtgcUg

www.youtube.com

토스가 바라보는 '일 잘하는 개발자': 코드를 넘어선 가치 창출

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠.

개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요.

여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요.

매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠. 개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요. 여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요. 매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

흑백요리사, 이모카세가 대단한 이유

Facebook

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다.

퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.
책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다.

그런데 회사에 들어가서 보니
구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.
이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다.
이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다.

이 의견에 대해서 설득하지 못했습니다.
데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다.
하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다.

그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다.
고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다.
먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다.

조금씩 고객 규모는 늘어났지만
너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 & 꾸준히 정진하는 사람 & 능동적으로 텍스트를 읽고 이해하려는 사람 & 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다.

물론 반대되는 생각도 있었습니다.
퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다.

일하면서 강하게 하게 된 생각은
'스타트업은 시장 크기가 거의 전부다' 라는 것입니다.
퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다.

퍼블리에서는 열심히 일했지만 한계가 있었습니다.
충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다.
사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다. 퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다. 그런데 회사에 들어가서 보니구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다. 이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다. 이 의견에 대해서 설득하지 못했습니다.데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다. 하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다. 그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다. 고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다. 먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다. 조금씩 고객 규모는 늘어났지만너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 &amp; 꾸준히 정진하는 사람 &amp; 능동적으로 텍스트를 읽고 이해하려는 사람 &amp; 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다. 물론 반대되는 생각도 있었습니다.퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다. 일하면서 강하게 하게 된 생각은'스타트업은 시장 크기가 거의 전부다' 라는 것입니다. 퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다. 퍼블리에서는 열심히 일했지만 한계가 있었습니다.충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다. 사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

www.facebook.com

결국 시장이 제일 중요하다

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 생각합니다:)

그동안 만든 21개의 사이드 프로젝트가 다 실패하고 22번째로 만든 프로젝트가 코로나맵이였습니다.

저는 꾸준한 실패의 힘을 믿습니다 😆

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 생각합니다:) 그동안 만든 21개의 사이드 프로젝트가 다 실패하고 22번째로 만든 프로젝트가 코로나맵이였습니다. 저는 꾸준한 실패의 힘을 믿습니다 😆

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 

나 혼자 몰래 듣고 싶은 네이버 경력 이직 성공기

네이버 경력사원이 다 대답해 드립니다

📎 네이버코드 채용 관련 콘텐츠 3탄! '네이버 경력사원' 분들의 이직 성공기가 공개되었습니다 : )

오늘 공개된 네이버코드 '네이버 경력사원이 다 대답해 드립니다'편에는 다양한 경험과 역량을 보유한 네이버 경력사원분들의 진솔한 인터뷰가 실렸습니다.
콘텐츠에는 아래와 같은 내용이 담겨있으며, 상세 내용은 하단 링크를 통해 확인하실 수 있습니다 🙂

✔︎ 이직을 고민하게 된 동기와 네이버를 선택한 이유는?
✔︎ 채용공고 속 직무와 내 경험 사이의 간극이 있다면 어떻게 해야 할까?
✔︎ 경력 이직에 성공한 사람들은 어떤 식으로 자기 어필을 했을까?
✔︎ 포트폴리오나 경력 기술서에 나만의 '킥'을 보탠다면?
✔︎ 실제 입사해 보니 네이버는 이런 회사였습니다!

📎 네이버코드 채용 관련 콘텐츠 3탄! '네이버 경력사원' 분들의 이직 성공기가 공개되었습니다 : ) 오늘 공개된 네이버코드 '네이버 경력사원이 다 대답해 드립니다'편에는 다양한 경험과 역량을 보유한 네이버 경력사원분들의 진솔한 인터뷰가 실렸습니다. 콘텐츠에는 아래와 같은 내용이 담겨있으며, 상세 내용은 하단 링크를 통해 확인하실 수 있습니다 🙂 ✔︎ 이직을 고민하게 된 동기와 네이버를 선택한 이유는?✔︎ 채용공고 속 직무와 내 경험 사이의 간극이 있다면 어떻게 해야 할까?✔︎ 경력 이직에 성공한 사람들은 어떤 식으로 자기 어필을 했을까?✔︎ 포트폴리오나 경력 기술서에 나만의 '킥'을 보탠다면?✔︎ 실제 입사해 보니 네이버는 이런 회사였습니다!

code.naver.com

경력사원들이 직접 풀어놓는 '네이버 이직 성공기'

코틀린에서 웹소켓에 액터모델을 연결시켜  분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다.

 * more : https://wiki.webnori.com/x/dYGZBQ

코틀린에서 웹소켓에 액터모델을 연결시켜&nbsp; 분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다. <ul ><li>more : https://wiki.webnori.com/x/dYGZBQ</li></ul>

코틀린에서 웹소켓을 우아하게 사용하기

UX/UI 디자인 전문가 우디입니다. UX/UI 디자이너들의 이력서, 포트폴리오 작성부터 면접 준비까지, 실무 중심의 입사 전략을 세우는 데 필요한 조언을 제공합니다. 채용 담당자 입장을 이해하고 구체적이고 명확하게 자신을 어필하는 법을 익히세요!

ChatGPT - 우디의 UX/UI : 포트폴리오/면접/디자인/라이팅 코칭

안녕하세요, 우디입니다.

디자인 취업 준비 관련해 자주 나오는 질문들에 대한 답변을 더 효과적으로 제공하고, 실질적인 인사이트를 드리고 싶어 GPTs를 만들었습니다.

📌 GPTs 링크: https://chatgpt.com/g/g-c1iWakBh2-udiyi-ux-ui-poteupolrio-myeonjeob-dijain-kocing

더 나은 포트폴리오와 커리어를 만들어 가는 데 도움이 되었으면 좋겠네요!

📚 GPTs에 포함된 주요 학습 내용

1. 세 권의 저서 원본 PDF
- 사실은 이것도 디자인입니다 (제품을 보는 눈)
- 사용자를 사로잡는 UX/UI 실전 가이드 (UX/UI 기초)
- GEN Z 인문학 (디자인 윤리)

2. 디자인 포트폴리오 코칭 경험&인사이트
- 실제 코칭에서 얻은 내용을 통해 실용적인 조언을 제공합니다.

3. 제가 운영하는 커뮤니티 아카이빙 및 자주 나오는 질문과 샘플 답변

4. 두 번의 웨비나 PDF 포함
- 채용 담당자를 고려한 포트폴리오 만들기
- 가독성을 고려한 포트폴리오 라이팅

📈 GPTs를 통해 얻을 수 있는 도움
- 취업 준비: 포트폴리오 작성 및 라이팅 팁, 면접 팁
- 디자인 기초: UX/UI 디자인의 기본 개념과 원리
- 논리적 사고 구축: 디자인 논리와 문제 해결 접근법
- 디자인 윤리: 다크 패턴과 윤리를 고려한 기능 구별

🔧 초기 단계 안내
- 아직 초기 단계인 만큼 부족한 부분이 있을 수 있습니다. 계속해서 수정과 보완을 진행할 예정이니, 양해 부탁드립니다.

디자인 여정에 작은 도움이라도 되길 바랍니다.

안녕하세요, 우디입니다. 디자인 취업 준비 관련해 자주 나오는 질문들에 대한 답변을 더 효과적으로 제공하고, 실질적인 인사이트를 드리고 싶어 GPTs를 만들었습니다. 📌 GPTs 링크: https://chatgpt.com/g/g-c1iWakBh2-udiyi-ux-ui-poteupolrio-myeonjeob-dijain-kocing 더 나은 포트폴리오와 커리어를 만들어 가는 데 도움이 되었으면 좋겠네요! 📚 GPTs에 포함된 주요 학습 내용 1. 세 권의 저서 원본 PDF- 사실은 이것도 디자인입니다 (제품을 보는 눈)- 사용자를 사로잡는 UX/UI 실전 가이드 (UX/UI 기초)- GEN Z 인문학 (디자인 윤리) 2. 디자인 포트폴리오 코칭 경험&amp;인사이트- 실제 코칭에서 얻은 내용을 통해 실용적인 조언을 제공합니다. 3. 제가 운영하는 커뮤니티 아카이빙 및 자주 나오는 질문과 샘플 답변 4. 두 번의 웨비나 PDF 포함- 채용 담당자를 고려한 포트폴리오 만들기- 가독성을 고려한 포트폴리오 라이팅 📈 GPTs를 통해 얻을 수 있는 도움- 취업 준비: 포트폴리오 작성 및 라이팅 팁, 면접 팁- 디자인 기초: UX/UI 디자인의 기본 개념과 원리- 논리적 사고 구축: 디자인 논리와 문제 해결 접근법- 디자인 윤리: 다크 패턴과 윤리를 고려한 기능 구별 🔧 초기 단계 안내- 아직 초기 단계인 만큼 부족한 부분이 있을 수 있습니다. 계속해서 수정과 보완을 진행할 예정이니, 양해 부탁드립니다. 디자인 여정에 작은 도움이라도 되길 바랍니다.

ChatGPT

🛠️ 우디의 디자인 GPTs 공유

개발자의 인문학 공부: 인문학 서적 100권 읽기

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추천 도서 목록

SNS 댓글로 받은 추천 도서 목록입니다. 현재 50권이 살짝 넘네요. 누구나 수정 할 수 있게 열어두었으니, 혹시 더 추천해주시고 싶은 책이 있다면 추가해주시면 감사합니다. ☺️

그보다.. 공돌이로써 제목만 봐도 현기증이.. 문돌이 분들이 물리, 수학, 인공지능 기술 도서명 보면 이런 느낌이려나 싶네요..😇🤭

https://docs.google.com/spreadsheets/d/1w4t4HMIXdbI233GXHcOob_MKCnp5hHVyoxax5Nepzt0/edit?usp=sharing

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추천 도서 목록 SNS 댓글로 받은 추천 도서 목록입니다. 현재 50권이 살짝 넘네요. 누구나 수정 할 수 있게 열어두었으니, 혹시 더 추천해주시고 싶은 책이 있다면 추가해주시면 감사합니다. ☺️ 그보다.. 공돌이로써 제목만 봐도 현기증이.. 문돌이 분들이 물리, 수학, 인공지능 기술 도서명 보면 이런 느낌이려나 싶네요..😇🤭 https://docs.google.com/spreadsheets/d/1w4t4HMIXdbI233GXHcOob_MKCnp5hHVyoxax5Nepzt0/edit?usp=sharing

Google Docs

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추

온라인 제조 서비스 ‘에이팀벤처스’, 50억원 투자 유치 - 'Startup's Story Platform’

온라인 제조 서비스 ‘에이팀벤처스’, 50억원 투자 유치

"서비스 중인 ‘크리에이터블’은 3D 도면만 올리면 신속하게 견적이 자동 산출되고 최적의 제조 파트너에 주문이 배정돼 바로 생산까지 가능" 2년만에 40만건이상의 제조와 납품을 완료했다고.

스타트업 스토리 플랫폼 '플래텀(Platum)'

벤처캐피털 TBT 공동대표

임정욱

호기심 많은 관찰자입니다. 매일 아침 조간 신문 뉴스와 IT뉴스를 챙겨보고 흥미로운 내용을 SNS에 메모해 두는 습관을 10년 넘게 유지하고 있습니다. 독서보다 넷플릭스와 유튜브를 너무 많이 보는 것 같아서 걱정입니다. 막 벤처투자자로 커리어를 바꾸는 참입니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필