본문 바로가기

All

 (42)
[개발생각] 스크럼의 진정한 목적이 무엇일까? 스크럼은 가장 값싼 비용으로 유연한 개발문화를 만들수있는 방법중에 하나라고 생각한다. 하지만, 스크럼의 진정한 목적을 모르고, 진행을 하면 그냥 시간잡아먹는 하마와 같이 변할수도있다. 스크럼을 잘하기 위해서는 몇가지 갖추어야할 선제조건들이 필요하다.(값싸지만, 미리 선행되야 하는 조건들은 비싸다!!! ㅋㅋ) 1) 팀원들은 개인의 업무에 대해서 스케줄링을 할수있어야 한다. - 스크럼을 시작할수있는 전제조건은 개개인이 자기가 맡은 역할에 대해서 최선을 다하고, 최선을 다하는것을 넘어서 일정을 철저히 지킬수있는 책임감을 가지고있어야 비로소 스크럼을 할수있는 조건이 된다. 스크럼은 빠르게 토론하고 빠르게 만들고를 반복하는 애자일 전략의 한 방법이다. 따라서 빠르게 ..
[개발생각] REDIS에서 아토믹처리를 하려면 REDIS를 깊게 사용하다보면, 트랜잭션처리 기능에 욕심이 생긴다. read_committed조회, rollback처리 이런것 있으면..이런생각 ㅋ REDIS는 기본적으로 완벽한 트랜잭션을 제공하는 다른 RDS의 성격이 아니다.빠르고 연산을 아토믹하게 처리하는 성격이고 또 그렇게 설계되었기 때문에, RDS에서의 트랜잭션처리를 완벽하게 구현할수도 없고,그렇게 사용하는게 개발메카니즘/철학과도 맞지않는 사용법이라고 생각한다. 다만 우리는 REDIS사용을 할때, 아토믹한 처리의 여러가지 방법이 존재하기에 이 방법은 잘 알고있어야 한다. 아토믹 처리의 방법중에는 크게 MULTI와 LUA SCRIPT방법 2가지가 있다. 1) MULTIMULTI명령어 이후의 명령어는 순서를 보장하고, 다른 명령어가 끼어들지못하게 한..
[개발생각] 붉은사막...펄어비스... 붉은 사막 오픈 하루전이다. 오늘 메타크리점수가 오픈되었고, 78점으로 주식은 하한가 크리를 먹었다..쩝 (주주로써 가슴아프다) 요즘 개발에서 드는 생각와 붉은 사막과 오버랩되는것이 있다.과연, 유저를 위한 시스템인가? 나만의 생각을 유저의 생각이라고 포장하여 만든 시스템인가?서비스를 만들때, 초기 설계/기획을 할때, 가장 주의해야하는 부분이 아닌가 한다.연차 자랑은 아니고, 연차가 많기에 이런 경우를 많이 겪었기에 기우가 생긴다. 대부분의 나의 안좋은 경험은 아래와 같았다. 기획 : "유저들은 이런 기능을 원합니다! 이렇게 해주세요!"개발 : "음.. 어떤 데이터에 기반해서 유저들이 원한다고 판단했을까요?"기획 : "....." 기획 : "이 기능은 유저들이 정말 필요로 하는 기능이고, 요청사항도 많이..
[개발생각] testFixtures에 대해서 테스트코드는 작성해야만 하는것, 하지만 유지보수에 대한 생각은 많이 안해도 되는것으로 생각하기 쉽다. 테스트 코드를 잘 작성해야, 프로젝트의 퀄리티가 올라가는 부분에 대해서는 말하지 않아도 누구나 인지하고 있을듯하다.따라서, 테스트 코드를 어떻게 잘 작성을 하는가에 많은 개발자들은 초점을 맞추고있다. 물론, 이 부분도 정말 중요하지만, 간과하면 안되는 부분이 있다. 테스트 코드를 어떻게 유지보수를 하면서 잘 관리해 나가느냐 또한 잘 작성하느냐와 더불어 엄청나게 중요한 부분이라는 것이다. 실제 비즈니스 코드는 리팩토링을 매번 하지만, 테스트 코드를 쉽게 짜도록 하는 유틸이나, 기능에 대한 부분은 아예 작성하지 않거나, 리팩토링을 하지않으며, 신경을 덜 쓰게 된다. 테스트 코드의 유지보수성을 높이기 위해서는..
[개발생각] 원팀이 무얼까? 원팀이 뭐냐는 질문을 최근 받았다. 평상시 나는 공상을 많이하는 사람이다. 그 여러 공상중에서도 '원팀'에 대한 것도 많이 했었어서, 내생각을 확고히 말할수있었다.다만 평상시 엄청나게 공상했던, 그 답변을 모두 이야기하지못한 부분이 있기에, 그 나머지썰을 풀려고 한다. 개발직군에서 특히, 회사에서의 '원팀'의 개념은 좀더 철저하고 엄격하다랄까??프로에서의 '원팀'은 아무리 누군가가 우리는 '원팀!!', '최고의 팀!'이라고 외친다고 원팀이 되지않는다.약간의 사기충전면에서의 도움정도 된다랄까? '원팀'의 마인드는 모두가 마음속에서 서서히 생겨난다.그 마음속에서 서서히 생겨나는 전제 조건중 가장 중요한건, 각자의 역할에 최선을 다하는 모습을 서로가 보이고, 이부분을 마음속에서 인정해 줄때, 존중의 마음과..
[개발생각] Apache Camel에 대해서 아파치 카멜 처음 잠깐 써본게, 18년 정도 된거같은데... 최근에 각잡고 써보니 쓸만하다!! 인터넷 찾아보니, 최초 릴리즈가 2007년...ㅎㄷㄷ잠깐 사용했을때가, 나온지 1-2년된 따끈따끈한때였구나 ㅋ그때도 어느정도 성숙한 오픈소스여서, 꽤 유용했던것으로 기억한다.특히 간단한 ETL, BATCH 잡에 사용하기 정말 강력했던 기억이다.물론, 스프링배치가 배치쪽은 아직 꽉 잡고있다고는 하지만, 스프링배치는 너무 초기 러닝커브가 있다는 점이 아쉽다.최근에 카멜을 다시 쓸일이 있어서, 좀 자세히 알아봤는데, 실시간 이벤트 처리에 관해서는 꽤 괜찮은 솔류션으로 보인다. 우선 병렬처리에 대한 접근이 쉽다.샤딩을 직접 해서 대상을 만들거나, 파티션으로 데이터를 읽거나 하는 방법을 쓰지않아도 (물론 쓰면 더좋다),..
[개발생각] 오래걸리는 작업에 대한 처리 오래걸리는 외부 API의 결과를 데이터베이스에 저장하는 기능을 개발해야한다면, 어떻게 구현해야할까? 내부 API는 30ms~100ms 내외의 응답속도를 보장해야하기도 해서, 큰부담없이 사용할수있겠지만,외부에서 제공하는 API들은 기능에 따라서 길게는 수초에서 수십초가 걸리는 것도 있다.(스크래핑, 대용량 데이터 응답(빅데이터 조회)등) 이경우 해당 응답을 데이터베이스에 저장을 해야하는 비즈니스 로직이 존재한다면,어떻게 구현을 해야, 개발 잘했다고 소문이날까?!! 우리는 몇가지를 고려해야한다. >>>1) 외부API의 장애에 대한 처리가 있어야 한다. - 외부API의 응답속도가 현저히 떨어지거나, 장애로 인해 접속에 문제가 있는경우는 지속적으로 외부API를 호출하지 않도록,방어장치가 있어야 한다. - 간단..
[개발생각] Kafka 이벤트와 트랜잭션에 대해서 트랜잭션과 비동기 프로세스의 처리에 대해서, 인지하고 있어야 할것이 있다. 가끔 카프카 이벤트와 트랜잭션에 대해서 혼돈이 일어날때가 있어서, 적어두고자 한다. @Transactionalfun saveUser() { userRepository.save(User(id = "test")) kafkaEventPublisher.send(Event("SaveUser"))}@Transactional@KafkaListenerfun listener(event:String) { val user = userRepository.findById("test") user?.let { println("user is not null") } ?: println("user is null")} 이경우..
[개발생각] 우수한 개발 집단이란? 개발력이 우수한 집단에는 공통된 특징이 있다. 기획자 집단과 개발자 집단이 모두 우수하다는 것이다.개발력이 우수하다는것을 일반인들은 단순히 개발자들이 뛰어나서, 뚝딱 무언가를 잘 만들어 낸다는것으로 착각한다.하지만 개발자들이 서비스를 잘 만들기 위해서는,각자의 실력이 뛰어나야 함은 기본이고, 잘 기획된 기획서가 필수가 되어야한다.아무리 우수한 병사들이라도, 이 산,저 산으로 목적성없이 이동하면 힘이 빠지는 경우랄까? 따라서, 잘 만든 서비스를 위해서는,기획자 집단의 서비스에 대한 꼼꼼한 기획서는 필수가 된다.내가 개인적으로 생각하는 각 집단의 역할은 명확하다. 1) 기획자 집단- 만들려는 서비스를 '문서'로 만들어 내는 역할이다.- '문서'를 보면, 서비스가 A-Z까지 모두 파악이 되는 꼼꼼한 기획서..
[개발생각] Webview앱 vs Native앱 앱을 만들때, 웹뷰로 만들지, 네이티브로 만들지는 한번쯤 고민해 보는것 같다. 참고로, 개인프로젝트면 웹뷰가 편하긴 한것같다..ㅋ(Dart, Swift등 또 배우기, 귀찮아...) 웹뷰앱과 네이티브앱 장단점을 생각했을때, 만약 최고의 앱을 만들 목표라면, 너의 선택은? 이라고 누군가 묻는다면, 나는 '네이티브앱'을 선택할듯하다. 외국어도 네이티브가 제일 외국어 잘하지... 앱도 네이티브가 성능, 기능면에서 더 뛰어난건 반론을 할수가 없지 않을까? ㅋ 그렇다면, 네이티브앱이 가장 큰 단점이라고 생각하는것은? 이라고 묻는다면, 배포/장애대응등이지 않을까..하지만, 이걸 단점이라고 생각하기보다는, 장점을 얻기위한 트레이드오프라고 보고, 배포/장애에 대한 대응을 잘 할수있도록, 프로세스를 만들고, 실수를 줄이도..

티스토리툴바